This article provides a summary of the object storage services of the three biggest cloud providers: AWS, Azure and GCP.
AWS EKS gère désormais les node groups de workers en tant que ressources managées (avant il fallait gérer soit même les ASG de workers nodes).
En plus c'est déjà géré par la nouvelle version du provider terraform-aws
For future reference.
Here are the links for getting Public IPv4 on various clouds.
Azure
curl -H Metadata:true "http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-08-01&format=text"
AWS
curl http://169.254.169.254/latest/meta-data/public-ipv4
GCP
curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip
Since 169.254.169.254 is a global metadata server for these above cloud vendors, no need to use different domain names.
Les jobs CI peuvent être très consomateurs en IOPS, notamment lors des phases de téléchargement des artifacts (maven :) ou docker par exemple...) ou lors du build. Une CI déployée sur des instances EC2 avec des volumes EBS standards (gp2) peut connaitre des temps de réponse particulièrement dégradés lorsqu'elle à dépassé sa capacité de burst et qu'elle est limité en IOPS.
Il est interessant dans ce contexte de monitorer l'EBS Burst Balance sur ces volumes.
En cas de performance limitée par les IOPS EBS, il y a 3 solutions:
Quelques optimisations pour utiliser EKS en production
Les prérequis a connaitre pour utiliser K8S avec le cloud provider AWS qui permet de provisionner automatiquement de ressources ELB et EBS pour les services de type Load balancer et les PersistentVolumes
Le getting started officiel Hashicorp pour déployer un cluster EKS avec Terraform.
Le code est ici: https://github.com/terraform-providers/terraform-provider-aws/tree/master/examples/eks-getting-started
EDIT:
NOTE: The usage of the specific kubernetes.io/cluster/ resource tags below are required for EKS and Kubernetes to discover and manage networking resources.
NOTE: The usage of the specific kubernetes.io/cluster/ resource tag below is required for EKS and Kubernetes to discover and manage compute resources.
voir également: https://github.com/kubernetes/cloud-provider-aws/blob/8f6e1e3d2cfa20a0deac088b9c4022d433500369/pkg/cloudprovider/providers/aws/tags.go#L30-L52
Je n'ai pas trouvé de doc officielle claire indiquant les tags à mettre en place sur les ressources AWS, mais après avoir passé 2 jours à débugguer pourquoi mes ELB ne se provisionnaient pas, puis pourquoi mes Nodes n'arrivaient pas à joindre le cluster EKS, je confirme que ces tags sont très importants à ajouter sur les ressources suivantes:
Une liste exhaustive de bonnes pratiques à mettre en place avant de déployer une infrastructure en production sur AWS
Firecracker est un VMM (Virtual Machine Manager) open source light qui s'interface avec KVM pour créer des microvm qui démarrent en moins de 125ms. Le but de Firecracker est de pouvoir bénéficier de la rapidité d'instanciation d'un container avec l'isolation d'une VM. C'est développé par AWS qui l'utilise en interne pour faire tourner AWS Lambda et AWS Fargate.
L'article propose d'optimiser les coûts d'infrastructures et de bénéficier d'un pseudo chaos engineering sur les clusters k8s en utilisant des spots instances aws (ou équivalent dans les autres clouds).
Amazon permet désormais d'ouvrir un shell sur les instances EC2 sans passer par SSH via la console web ou la cli AWS.
La doc de l'API S3 avec pour chaque endpoint les permissions IAM nécessaires.
C'est super utile quand on essaie de debugger un provisionning de bucket avec terraform qui plante parce qu'il manque des droits:
TF_LOG=debug terraform apply --target aws_s3_bucket.mon_bucket
puis on cherche l'appel qui plante et on va voir dans la doc les permissions à ajouter à sa policy IAM.
Le simulateur de policy AWS IAM, url à garder sous le coude
La liste des actions possibles par ressources dans les policy IAM
Une liste des équivalences entre les services AWS et Azure
Une cli pour créer des clusters AWS EKS en une ligne de commande
Procédure pour utiliser le MFA avec la cli AWS
AWS propose désormais un gestionaire de secrets intégré avec KMS
3 méthodes différentes permettant de prendre le contrôle d'un cluster kubernetes à partir d'un pod avec une installation de kops par défaut et comment les sécuriser. Il faudrait vérifier si ces failles existent également par défaut avec les autres outils de provisioning kubernetes (kubespray...).
Topologies Terraform pour déployer la configurations IAM nécessaire pour accéder à un compte AWS depuis un autre compte (assume-role) dans une architecture AWS multi-comptes.
Comment utiliser AWS KMS pour chiffrer des données de plus de 4Ko avec la technique de l'envelope encryption
Des scripts pour réaliser une sauvegarde consistente (FS + DB) de Nextcloud sur AWS S3 où Backblaze B2.
Synthèse des nouveaux services EKS et Fargate annoncés aux AWS Re-Invent Summit cette année.
EKS (AWS Kubernetes managed solution) permet de déployer un cluster Kubernetes sur AWS en ne gérant que les workers nodes (masters nodes managés par AWS).
Fargate va plus loin en fournissant une solution 100% managée (workers nodes managés) pour ECS dans un premier temps puis EKS en 2018. Cette solution permet de déployer des containers sans ce soucier des instances EC2 sur lesquels ils tourneront et de payer uniquement pour les containers déployés (facturation par container au lieu de la facturation par instances EC2 démarrées dans le cluster).
Amazon GuardDuty analyse plusieurs sources de données AWS (Logs Cloudtrail, VPC Flow & DNS) et détecte les comportements suspects (instances EC2 se connectant à un domaine lié aux bitcoins ou prenant part à une attaque brute force par ex...).
Méthode pour faire du blue-green deployment sur AWS avec des scripts python utilisant boto3 et fabric.
Un rappel des différentes étapes pour scaler une application web de 1 à 10 millions d'utilisateurs sur une infra AWS.
Il est inutile de designer une architecture ultra-résiliente dès le début:
Un outils de restore point-in-time pour les buckets S3 bucket qui ont le versioning activé
Une command-line améliorée pour awscli: pip install aws-shell
Il est possible de tester le failover d'une base RDS Multi-AZ en la rebootant avec l'option force-failover
.
aws rds reboot-db-instance \
--db-instance-identifier dbInstanceID \
--force-failover
Attention le changement d'AZ (AZ primary devient AZ secondary et vice versa) n'est pas visible instantanément (10 min max) dans la console AWS.
Pour vérifier que le changement a bien eu lieu, il faut vérifier que l'alias DNS de l'instance a changé:
while true; do host <my-rds-endpoint.amazonaws.com> | grep alias ; sleep 1; done
kops get cluster ${CLUSTER_NAME} -o yaml --full > cluster.yml
kops get ig nodes -o yaml > nodes.yml
kops get ig masters -o yaml > master.yml
cat cluster.yml > cluster_spec.yml
echo --- >> cluster_spec.yml
cat nodes.yml >> cluster_spec.yml
echo --- >> cluster_spec.yml
cat master.yml >> cluster_spec.yml
kops create -f cluster_spec.yml
route53-kubernetes permet d'automatiser la création d'enregistrement DNS quand on configure son Ingress.
C'est intégré sous forme d'addon à KOPS.
Attention: Après quelques tests, si route53-kubernetes gère bien la création des nouveaux enregistrements DNS, je n'ai pas l'impression qu'il gère la modification ou suppression des enregistrements créés précédemment. Il doit donc falloir faire du ménage manuellement de temps en temps.
A noter qu'il existe aussi ExternalDNS qui semble être la future méthode standard pour manipuler les DNS externes (Route53, Google Cloud DNS, ...) mais qui semble moins mature.
Pour installer un cluster Kubernetes privé avec KOPS sur une infra AWS déjà existante (DNS, VPC, Subnets, ...)
EDIT
en complement un tuto qui permet de faire quasimment la même chose mais en utilisant KOPS pour exporter une configuration Terraform pour ceux qui utilisent déjà Terraform pour le reste de leur infrastructure:
https://ryaneschinger.com/blog/kubernetes-aws-vpc-kops-terraform/
With AWS Organizations we can now automate the creation of new AWS account to have fully isolated resources from your main account while keeping consolidate bills, shared policy and being able to switch roles from the main accounts to the new accounts with the same credentials.
Kops permet de créer un cluster Kubernetes complet et haute-dispo sur AWS.
Parmi les nombreuses features intéressantes:
L'article explique comment streamer des logs de Cloudwatch logs dans un cluster Amazon ElasticSearch
Plus besoin de recréer une instance ec2 pour lui attribuer un rôle IAM.
(via https://jeekajoo.eu/links/?0lPOgQ)
Pour automatiser la sauvegarde de volumes Docker sur S3 avec Duplicity:
docker run -v /var/run/docker.sock:/var/run/docker.sock:ro --rm -ti \
-e CONPLICITY_FULL_IF_OLDER_THAN="90D" \
-e CONPLICITY_REMOVE_OLDER_THAN="365D" \
-e CONPLICITY_TARGET_URL=s3://s3-eu-west-1.amazonaws.com/<s3-bucket>/<directory> \
-e AWS_ACCESS_KEY_ID=XXXXXXXXXX \
-e AWS_SECRET_ACCESS_KEY=XXXXXXXXXX \
camptocamp/conplicity
Un guide très complet pour monter une archi HAproxy en HA derrière un ELB avec la terminaison SSL au niveau du HAproxy (utile pour avoir plusieurs certificats SSL sur le même HAproxy par exemple).
Parmi les points importants:
ProxyProtocolPolicyType
) et HAproxy (accept-proxy
) pour récupérer les IP sources dans les logs HAproxyÉgalement pas mal d'autres astuces pour ajouter des fonctions de sécurité basiques au niveau HAproxy (URL filtering, Rate limiting, DDOS protection...)
Les slides de Gruntwork qui résument toutes les bonnes pratiques Terraform présentés dans leur série d'article
Cf. liens précédents:
Workflow proposé par Gruntwork pour les changements d'infrastructure avec Terraform:
terraform plan
terraform apply
terraform apply
Des astuces pour utiliser des boucles et des conditions avec Terraform en utilisant le paramètre count
au sein des ressources:
On peut ensuite utiliser la fonction element
pour récupérer l'élément d'une liste correspondant à l'indice de count
ou utiliser la fonction replace
pour remplacer 0 ou 1 par des valeurs différentes par exemple.
C'est plutôt tricky mais ça à l'air de faire le job.
Best practices pour Terraform:
ex:
- infrastructure-live-repo
| - dev
| | - app1
| | - app2
| | - db1
| | - vpc
| - test
| | - ...
| - prod
| | - ...
| - mgmt
| | - bastion
| | - ...
| - global
| | - iam
| | - route53
| | - ...
- infrastructure-modules-repo (tags v0.0.1, v0.0.2, ...)
| - app1
| - app2
| - db1
| - vpc
| - bastion
| - ...
Comment centraliser les logs des containers Docker dans Cloudwatch en utilisant awslogs et comment les envoyer par la suite dans une stack ELK en passant par un export S3.
Terraform 0.8 est sorti.
Au menu:
Attention, certains changements provoquent des incompatibilités avec les versions précédentes. Lire la partie upgrade de la release note pour vérifier les changements nécessaires.
Des bonnes pratiques pour gérer son infrastructure avec terraform:
(via: https://jeekajoo.eu/links/?XvEgyg)
Un script Python pour générer les serveurs et rôles utilisé par Fabric de façon dynamique en utilisant l'API AWS.
Ce script génère les rôles en se basant sur le nom de l'instance.
Je préfère une approche utilisant les tags AWS pour gérer les rôles.
C'est plus compliqué à gérer, mais ça laisse beaucoup plus de flexibilité.
Le calculateur de coûts AWS
Bees crée des instances EC2 à la volée et lance des tests de charge distribués
Alternative à Cloudformation et Terraform pour gérer le provisioning sur AWS
Un script python pour télécharger les logs d'une instance RDS PostgreSQL afin de les analyser avec pgbadger (https://github.com/dalibo/pgbadger)