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:
- Arrêter l'instance EC2 et détacher le volume EBS
- Faire un snapshot au cas où
- Attacher le volume à une autre instance EC2
- Resizer la partition avec parted
- Resizer le FS si nécessaire (resize2fs ou autre)
- Lancer un FSCK sur la partition au cas ou
- Arrêter l'instance EC2 et détacher le volume EBS
- 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...
Cas d'utilisation d'une infra AWS / Docker / ECS
Un dashboard Kibana pour analyser les logs Cloudtrails sur AWS
Un outils pour exporter son infra AWS existante en format Terraform
(via https://github.com/jeekajoo)
Un script en python qui permet de se connecter en SSH sur une instance EC2 ou un membre d'un autoscaling group à partir de ces metadatas AWS (nom, instance id, ...)
Un script en python pour automatiser le snapshot des volumes EBS possédant un tag spécifique
Une image docker qui permet de sauvegarder des containers dans s3.
exemple:
$ docker run --rm --env-file env.txt --volumes-from mysql --name dockup borja/dockup
$ cat env.txt
AWS_ACCESS_KEY_ID=<key_here>
AWS_SECRET_ACCESS_KEY=<secret_here>
AWS_DEFAULT_REGION=us-east-1
BACKUP_NAME=mysql
PATHS_TO_BACKUP=/etc/mysql /var/lib/mysql
S3_BUCKET_NAME=docker-backups.example.com
Pour gérer en ligne de commande les zones DNS route53 et exporter/importer des zones DNS à partir d'un fichier de zone au format bind standard
La doc officielle du SDK AWS for Python
Un tuto pour manipuler AWS avec le SDK Python Boto3
Merci iMil
Un tuto pour utiliser AWS Lambda pour redimensionner automatiquement les images uploadées dans un bucket S3
Un tuto pour créer un cluster wordpress en autoscaling en utilisant Elastic File System (NFS AWS). Ce tuto commence par un rappel sur la création des ressources réseaux de bases (VPC, Security Group, Internet Gateway, ...)
Plugin Jenkins pour uploader les artifacts dans S3
Un classement de tutos pour différents langages (ruby, python, ...) et outils (git, puppet, chef, aws ec2, ...)
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
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
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
Exemple de déploiement automatique d'une application avec docker, chef et amazon opswork.