Plugin Jenkins pour uploader les artifacts dans S3
Utilisation de Docker sur MacOS X avec Docker Machine à la place de Boot2Docker.
L'install passe par Docker Toolbox mais on peut aussi utiliser brew:
brew cask install dockertoolbox
Oh-my-ZSH framework for bash
Un livre blanc qui recense les bonnes pratiques des acteurs du web:
de la culture devops aux architectures big data/nosql en passant par le déploiement continu, l'organisation des équipes et la conception d'api ouvertes à l'extérieur
Pour le télécharger sans s'enregistrer: https://julien.mailleret.fr/pub/octo-les-geants-du-web.pdf
Comment déployer des application python en créant des packages .deb avec dh-virtualenv
Une plateforme de crowdfunding pour financer des projets liés aux énergies renouvelable
Un outils pour générer des fichiers siteconfig pour récupérer le contenu d'une page web dans Wallabag ou dans certains agrégateurs RSS
Un classement de tutos pour différents langages (ruby, python, ...) et outils (git, puppet, chef, aws ec2, ...)
Comment forcer le mode lecture dans Firefox sur les sites qui ne le proposent pas
Un script python qui permet d'afficher un dashboard en ligne de commandes avec toutes les infos d'un AutoScaling Group (status des instances...)
Forkable sur GitHub: https://github.com/osalkk/autoscaling-cli-dashboard
Les paramètres about:config pour rendre firefox plus respectueux de notre intimité.
Generation of diagram and flowchart from text in a similar manner as markdown
Un utilitaire en python pour sauvegarder le contenu de sa boite mail en IMAP
Un guide des bonnes pratiques Python écrit sur GitHub :https://github.com/kennethreitz/python-guide
1: Enable AWS VPC Flow Logs for your VPC or Subnet or ENI level
2: Use AWS Identity and Access Management (IAM) to control who in your organization has permission to create and manage security groups and network ACLs (NACL)
3: Enable AWS Cloud Trail logs for your account
4: Enable AWS App Config for your AWS account. App records all events related to your security group changes and can even send emails
5: Have proper naming conventions for the Amazon Web Services security group
7: Periodically detect, alert or delete AWS Security groups not following the organization naming standards strictly
8: Have automation in place to detect all EC2,ELB and other AWS assets associated with Security groups
9: Create your own security groups and specify them when you launch your instances
10: Alerts by email and cloud management dash board should be triggered whenever critical security groups or rules are added/modified/deleted in production
11 : Have automated programs detecting EC2 associated with multiple SG/rules and alert the SOC/MS periodically. Condense the same manually to 1-3 rules max as part of your operations.
12 : Do not create least restrictive security groups like 0.0.0.0/0 which is open to every one
13: Have a security policy not to launch servers with default ports like 3306, 1630, 1433, 11211, 6379 etc
15: Detection, alert and actions can be taken by parsing the AWS Cloud Trail logs based on usual patterns observed in your production environment. Detect anomalies on how long a change effected and reverted in security groups in production.
16: In case ports have to be opened in Amazon Web Services security groups or a permissive AWS security group needs to be applied, Automate this entire process as part of your operations
17: Make sure SSH/RDP connection is open in AWS Security Group only for jump box/bastion hosts for your VPC/subnets. Have stricter controls/policies avoid opening SSH/RDP to other instances of production environment
18: It is a bad practice to have SSH open to the entire Internet for emergency or remote support
20: Avoid allowing UDP or ICMP for private instances in Security groups
21: Open only specific ports, Opening range of ports in a security group is not a good practice.
22: Private Subnet instances can be accessed only from the VPC CIDR IP range
23: AWS CloudTrail log captures the events related security. AWS lambda events or automated programs should trigger alerts to operations when abnormal activities are detected
24: In case you are an enterprise make sure all security groups related activities of your production are part of your change management process. In case you are an agile Startup or SMB and do not have complicated Change management process, then automate most of the security group related tasks and events as illustrated above on various best practices
26: For some tiers of your application, use ELB in front your instance as a security proxy with restrictive security groups
Dans un contexte d'architecture microservices utilisant des containers et le concept ImmutableServer, l'utilisation d'un serveur d'application java (tomcat...) fournit uniquement le framework (servlets, ...) nécessaire à l'application java.
Les fonctionnalités de gestion des applications (plusieurs applis dans la même JVM, déploiement à chaud, ...) sont en effet directement gérées au niveau containers (1 applis = 1 JVM = 1 container, déploiement d'un nouveau container en cas de mise à jour de l'applis).
En fin d'article, il est également question de SpringBoot (http://projects.spring.io/spring-boot/) et CamelBoot (https://camel.apache.org/camel-boot) qui permettent de démarrer directement une JVM avec son framework sans toute la lourdeur du serveur d'application.
Recensement des design patterns existantes pour AWS.
Dans le même genre:
http://www.cloudcomputingpatterns.org/
http://cloudpatterns.org/
Comment tirer partie des fonctions d'AWS pour faire du Blue/Green Deployment:
- Créer une nouvelle stack (green) avec l'application mise à jour identique à la stack de production (blue) (Si on utilise Amazon OpsWork, il est possible de directement cloner une stack)
- Faire tous les tests nécessaires sur la nouvelle stack (green)
- Quand tous est OK, utiliser Amazon Route53 (DNS AWS) pour rediriger le traffic de la stack blue vers la stack green (nécessite d'avoir un TTL le plus bas possible au niveau DNS, paramétrer le TTL à 60s sur Route53)
En bonus, il est possible d'utiliser la technique Canary Release:
- Route53 permet de faire du routage pondéré: on commence par rediriger seulement 10% du traffic sur la nouvelle stack, puis 20%, ...
Cela permet de limiter le nombre de users impactés en cas de problème et de vérifier le comportement en charge de façon plus lissée dans le temps. - Si les stack blue et green utilisent l'autoscaling, la stack blue va se réduire et la stack green grossir au fur et à mesure que le routage pondéré amènera plus d'utilisateurs sur la nouvelle stack.
Suite de l'article qui parle notamment des problématique de modification de schema BDD dans le cadre du Blue/Green Deployment:
https://medium.com/aws-activate-startup-blog/upgrades-without-tears-part-2-blue-green-deployment-step-by-step-on-aws-29c0ffe99c60?source=rss----dad75eb79ad5---4
Le Feature Flipping permet de livrer en production des fonctions désactivées qui pourront ensuite être activé pour tout ou partie des utilisateurs.
Les cas d'utilisation sont multiples:
- livraison en prod de fonctionnalités non terminées lorsque les développeurs commitent sur le trunk (best practices pour le continuous deployment)
- rollback plus rapide (en cas de bug sur une nouvelle fonctionnalité, il suffit de la désactiver sans relivrer)
- tests sur des sous-population (A/B testing)
- proposer des fonctionnalités payantes
- Passer en mode dégradé en cas de problèmes de perfs (en desactivant les fonctions - critique mais + gourmandes en ressources)
3 tips for DevOps teams:
- Try to go from commit to live in production automatically.
- Use feature flags or flippers instead of branching
- Run a bunch of really small production tests, performing real interactions with your live site, such as creating new user accounts, using Selenium, or just curling some URLs. Then add them to your deployment pipeline. If any of the tests fail, just deploy the old version.