Pager Duty vient de publier ses procédures de gestion d'incident en Open Source.
Voire également les slides ici: https://response.pagerduty.com/training/courses/incident_response/

Une liste exhaustive de bonnes pratiques à mettre en place avant de déployer une infrastructure en production sur AWS

Quelques règles pour mettre en place un système d'alerting de la production pertinent dans le cadre d'astreintes 24/24.

1. Privilégiez les alertes sur les symptômes (disponibilité du service pour les utilisateurs, temps de réponse...) plutôt que les alertes sur les causes techniques (CPU, RAM, process, erreur 500, ...)

2. Scripter toutes les actions sur alertes qui peuvent être automatisée

3. Ne déclencher l'astreinte que pour les alertes qui nécessitent une action immédiate ne pouvant pas être automatisée

Le livre de Google qui explique le concept de SRE et comment ils gèrent leur prod est disponible en consultation en ligne

(via https://www.journalduhacker.net/)

Always set the -Xmx parameter when you run a JVM inside a container:

• if not specified, the JVM will try to use up to 1/4 of the total memory of the container host
• if you only specify container memory limits, docker will kill the JVM process if it tries to grow above the container limits

Kops permet de créer un cluster Kubernetes complet et haute-dispo sur AWS.

Parmi les nombreuses features intéressantes:

• instances EC2 basées sur Debian
• instances dans des ASG (master et nodes)
• possibilité de créer un VPC dédié ou d'en utiliser un existant
• possibilité d'exporter la config au format terraform pour provisionner le cluster avec terraform

• Évènements à tracer en Production:
  • Changes (who/what/when/type)
  • Incidents (when/TTD/TTR/severity/root cause)
• Métriques résultantes:
  • déploiements applicatif par jour
  • déploiements de config par jour
  • migrations de schémas DB par jour
  • lignes de codes changés par déploiements
  • change / incident ratio (pour chaque type de changement)

Une explication du concept SRE (Site Reliability Engineering) qui est utilisée pour gérer la production chez Google.

Parmi les points marquant par rapport à DevOps:

1. Error Budget:
   • tant qu'on est dans les SLA (99.999...), les devs peuvent mettre en prod de nouvelles features
   • dès que les SLA ne sont plus respectés, les devs ne peuvent plus mettre en prod de nouvelles features
   • Les devs ont le droit à 3 "silver bullet" (et pas une de plus) pour livrer de nouvelles features en dehors des SLA.
   • Pour utiliser 1 silver bullet, il faut convaincre le responsable des équipes dev
2. En cas d'incident, la restoration du service est prioritaire, le troubleshooting vient après. tous les logs, traces, métriques, ... permettant de diagnostiquer l'incident doivent donc collectées automatiquement.
3. La résolution des incidents connus doit être réalisée automatiquement par des bots sans intervention humaine

EDIT: en complément, l'interview du Vice President Engineering de Google qui donne plus de détails sur le fonctionnement chez Google
https://landing.google.com/sre/interview/ben-treynor.html

Procédure pour étendre un volume EBS sur AWS.
Pour étendre un root disk partitionné, il faut aussi aller voir de ce côté: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/storage_expand_partition.html

TLDR:

1. Arrêter l'instance EC2 et détacher le volume EBS
2. Faire un snapshot au cas où
3. Attacher le volume à une autre instance EC2
4. Resizer la partition avec parted
5. Resizer le FS si nécessaire (resize2fs ou autre)
6. Lancer un FSCK sur la partition au cas ou
7. Arrêter l'instance EC2 et détacher le volume EBS
8. Rattacher le volume EBS à l'instance d'origine et la redémarrer

Il va falloir que je me créé des AMI avec LVM ça simplifieras légèrement les choses...

Une présentation des différentes solutions pour gérer la partie service discovery avec docker-compose, docker-swarm et ecs.
A partir de la Slide 49, Jérôme Petazzoni présente le concept d'ambassador qui permet de créer des containers "proxy" pour abstaire la connexion entre les différents services

Pour supprimer tous les volumes docker orphelins:

docker run -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker:/var/lib/docker --rm martin/docker-cleanup-volumes

Conseil: lancer un dry-run avant et comparer avec la liste des volumes utilisés par des containers existants:

$ for d in $(docker ps -aq ); do docker inspect $d | awk -F\" '/Source/ {print $4}' | awk -F\/ '{print $6}'; done | sort > volumes-in-use
$ docker run -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker:/var/lib/docker --rm martin/docker-cleanup-volumes --dry-run | awk '/deleted/ {print $4}' | sort > volumes-not-used
$ comm -1 -2 volumes-in-use volumes-not-used

Un script en python pour automatiser le snapshot des volumes EBS possédant un tag spécifique