This is backposted, as always.

As I've written previously, my client has django-q deployed at AWS Elastic Beanstalk aka “boring tech”. It works, so why the hell not, except for deploys and scale up/down events. You see, despite the fact that app/VM can die anytime, despite small and idempotent tasks, we wanted to be as nice as possible and to let django-q finish whatever it was doing.

Elastic Beanstalk platform has a few hooks which allow you to execute custom scripts at various stages of application's lifecycle. Unfortunately, it doesn't have pre-delete or pre-destroy hook. I've asked in AWS forums and the answer was, if I remember correctly, somewhere between DIY and random. Disappointing, but somewhat expected. Luckily, there is a predeploy hook. And this hook, together with AWS Systems Manager Automation, will just do the trick we need.

The plan:

• Expose django-q cluster metrics through HTTP API endpoint. We went with metrics in Prometheus format. This can be implemented in many ways and you don't even need any kind of metrics and such.
• Make sure SIGTERM signal reaches django-q as per docs. Small fix was needed, because su and Shell won't forward signals to subprocess(es).
• Write a small script which:
  • Obtains ID of running container.
  • Checks whether container has a specific label which means django-q should be running inside.
  • Executes docker kill -s TERM … which in turn sends SIGTERM to django-q.
  • Waits for django-q to stop by periodically querying HTTP endpoint and evaluating received response.
• Deploy script as .platform/hooks/predeploy/myscript.ext.
• Set aws:elasticbeanstalk:command:Timeout. Downside is this will fail deploy on timeout.

This sets us up for deploys. As for auto-scaling, we will need:

• AWS::AutoScaling::LifecycleHook when autoscaling:EC2_INSTANCE_TERMINATING
• AWS::SSM::Document which defines what, where and how to execute, namely our predeploy script
• AWS::Events::Rule in order to trigger AWS::SSM::Document on event

Now, auto-scaling documentation states that:

To signal Amazon EC2 Auto Scaling when the lifecycle action is complete, you must add the CompleteLifecycleAction API call to the script

However, I'm not sure whether this just applies to some cases or whether it's handled as part of AWS::SSM::Document. It's possible to set DefaultResult: “CONTINUE” in AWS::AutoScaling::LifecycleHook after HeartbeatTimeout is up. Also, there is action: aws:executeAwsApi as part of AWS::SSM::Document and the final script has no AWS API calls. Of course, you don't want to wait for timeout to happen, if you don't have to. Time is money in AWS.

References:

• Automate instance hygiene with AWS SSM
• Using AWS Systems Manager Automation and AWS CloudFormation together
• Avoid downtime during the auto-scaling scale-out event
• Run code before terminating an EC2 Auto Scaling instance

and probably some others.

— Zdenek Styblik 2022/07/10 11:40

Some (longer) time ago I've bought Spigen Rugged Armor for Google Pixel 2 XL from 2017. Sadly, it cracked couple months later. As for why it could be due to multiple reasons:

1. Qi wireless charger receiver
2. phone holder(“clamp”) in the car
3. 5#17 like that just happens

It can be anything, although I've found comments which support “it just happens” theory.

It kept soldiering on until it cracked even more. Maybe phone falling on the ground had something to do with that. Thus search for replacement begun and I've settled on Spigen Thin Fit Designed for Google Pixel 2 XL Case.

Spigen? Again? To be honest, there aren't that many choices for a product released 5 years ago. It probably would be easier to buy just a new phone with all “peripherals” :) Can you spot small typo on the back of the box? :)

One word about protection. I don't think anything will protect phone screen from cracking and cracks when phone falls to the ground, realistically speaking. All one can do is to increase chances of survival, but that's it.

— Zdenek Styblik 2022/07/14 11:06