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:
- augmenter la taille des EBS pour bénéficier de d'un nombre d'IOPS plus important (nb IOPS = 3 x nb GB)
- passer sur des EBS de type io1 pour bénéficier d'un nombre d'IOPS garanti (souvent moins intéressant en terme de coûts)
- utiliser des instances disposant de SSD internes à la place des EBS (ex: c5d ou m5d instances)
Amazon permet désormais d'ouvrir un shell sur les instances EC2 sans passer par SSH via la console web ou la cli AWS.
Plus besoin de recréer une instance ec2 pour lui attribuer un rôle IAM.
Hack AWS pour gérer les clés SSH des users dans IAM et permettre aux instances EC2 de récupérer les clés SSH automatiquement
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, ...)