Differences

This shows you the differences between two versions of the page.

--- bloglike:2022-07 [2022/07/09 02:42] – created stybla
+++ bloglike:2022-07 [2022/07/14 06:06] (current) – Spigen replaced by Spigen stybla
@@ Line 1: / Line 1: @@
 ====== Issue 2022 - July ======
+===== Make django-q AWS Elastic Beanstalk and auto-scaling friendly =====
+This is backposted, as always.
+As I've written previously, my client has [[https://github.com/Koed00/django-q|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 [[https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/custom-platform-hooks.html|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 [[https://django-q.readthedocs.io/en/latest/cluster.html?highlight=SIGTERM#cluster|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, [[https://docs.aws.amazon.com/autoscaling/ec2/userguide/prepare-for-lifecycle-notifications.html|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:
+  * [[https://jdheyburn.co.uk/blog/automate-instance-hygiene-with-aws-ssm-0/|Automate instance hygiene with AWS SSM]]
+  * [[https://aws.amazon.com/blogs/infrastructure-and-automation/using-aws-systems-manager-automation-and-aws-cloudformation-together/|Using AWS Systems Manager Automation and AWS CloudFormation together]]
+  * [[https://blog.auberginesolutions.com/avoid-downtime-during-the-auto-scaling-scale-out-event/|Avoid downtime during the auto-scaling scale-out event]]
+  * [[https://aws.amazon.com/blogs/infrastructure-and-automation/run-code-before-terminating-an-ec2-auto-scaling-instance/|Run code before terminating an EC2 Auto Scaling instance]]
+and probably some others.
+ --- //[[stybla@turnovfree.net|Zdenek Styblik]] 2022/07/10 11:40//
+===== Spigen replaced by Spigen =====
+Some (longer) time ago I've bought [[https://www.amazon.com/dp/B07475TXJQ|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:
+  - Qi wireless charger receiver
+  - phone holder("clamp") in the car
+  - 5#17 like that just happens
+It can be anything, although I've found comments which support "it just happens" theory.
+{{:bloglike:img_20220402_185835578e.jpg?200|Cracked Spigen Rugged Armor}}
+{{:bloglike:img_20220402_190025994e.jpg?200|Cracked Spigen Rugged Armor}}
+{{:bloglike:img_20220402_190109246e.jpg?200|Cracked Spigen Rugged Armor}}
+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 [[https://www.amazon.com/Spigen-Thin-Designed-Google-Pixel/dp/B07475C1VT|Spigen Thin Fit Designed for Google Pixel 2 XL Case]].
+{{:bloglike:img_20220402_185708856e.jpg?200|Spigen Thin Fit Designed front}}
+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? :)
+{{:bloglike:img_20220402_185725960e.jpg?200|Spigen Thin Fit Designed back}}
+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.
+ --- //[[stybla@turnovfree.net|Zdenek Styblik]] 2022/07/14 11:06//