Cycle de vie des messages Amazon SQS

Les messages stockés dans Amazon SQS ont un cycle de vie facile à gérer, mais qui garantit le traitement de tous les messages.

Un système qui doit envoyer un message sélectionne une file d'attente Amazon SQS et utilise SendMessage pour lui envoyer un nouveau message.
Un autre système traitant des messages doit traiter plus de messages : il appelle donc ReceiveMessage, et ce message est renvoyé.
Dès lors qu'un message est renvoyé par ReceiveMessage, il ne sera pas renvoyé par une autre demande ReceiveMessage avant que le délai de visibilité ne soit expiré. Ainsi, plusieurs destinataires peuvent traiter le même message simultanément.
Si le système de traitement des messages termine avec succès le traitement de ce message, il appelle DeleteMessage, ce qui supprime le message de la file d'attente pour que personne d'autre ne le traite. Si ce système ne réussit pas à traiter le message, il sera alors lu par un autre appel ReceiveMessage dès que le délai de visibilité sera expiré.
Si vous avez associé une file d'attente de lettre morte à une file d'attente source, les messages seront déplacés vers la file d'attente de lettre morte lorsque le nombre de tentatives d'envoi que vous avez défini aura été atteint.

import logging
logging.basicConfig(filename='log.txt', format=logging.BASIC_FORMAT)
logging.error('OH NO!')
try:
raise Exception('Foo')
except:
logging.exception("Oops:")

Beanstalk ne permet pas de définir un trigger basé sur le nombre d'éléments dans la queue SQS pour l'auto scaling des environements de type worker

Pourtant c'est possible mais il y a un peu de boulot :

• créer des scaling policies qui vont ajouter ou enlever des instances
• créer des alarmes cloudwatch qui vont se déclencher par rapport au nb d'éléments dans la queue et appeler les scaling policies..

http://docs.aws.amazon.com/autoscaling/latest/userguide/as-using-sqs-queue.html
https://forums.aws.amazon.com/thread.jspa?messageID=722589

On peut surement intégrer ça à beanstalk avec les .ebextensions (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html)

En plus d'être un peu complexe et pas vraiment intégrer à beanstalk, ça n'a pas l'air très réactif, cet article en parle et donne une solution :
Rapid Auto Scaling with Amazon SQS : https://aws.amazon.com/blogs/aws/auto-scaling-with-sqs/

Depuis hier le 22 Février 2017

seems cool and powerful

Since December 22th 2016 you are able to configure application version lifecycle in Beanstalk.

Very convenient, we can trash our custom api cleaning scripts :-)

docker stop command send SIGTERM to pid1 inside the container to let a chance to stop gracefully (https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/)
Unfortunatly some software ignore SIGTERM and need to be stopped by their own command (hello opendj)

To do so, in the Dockerfile, in the CMD, I use a script like this :
/thecommand/tostart/thesoftware/inbackground
trap "/thecommand/tostop/thesoftware" SIGTERM
while true; do sleep 1; done

so my script is run with PID1, docker stop sends SIGTERM, my script catch (trap) the signal, and run the command to stop gracefully

cat prepare-commit-msg
NAME=$(git branch | grep '' | sed 's/ //'|cut -d'/' -f2|cut -d'-' -f1,2)
echo "$NAME $(cat "$1")" > "$1"

for dir in $(ls); do cp prepare-commit-msg $dir/.git/hooks/prepare-commit-msg; done

!/bin/sh

text=" [FIX] ()
🔄 [MOD] ()
✅5 [ADD] ()
🔀 [TEST] ()
[DOC] ()"

echo "$text $(cat "$1")" > "$1"

aws <3

Pour avoir une vue globale des crins qui tournent sur différents serveurs