Comment puis-je configurer cloud-init sur la coutume AMIs dans AWS? (CentOS)

cloud-init est un très puissant, mais très sans-papiers de l'outil. Même une fois qu'il est installé, il y a beaucoup de modules active par défaut qui écrasent les choses que vous avez déjà défini sur votre AMI. Voici les instructions pour une quantité minimale d'installation à partir de zéro:

Instructions

1. Installer cloud-init à partir d'un référentiel standard. Si vous êtes inquiet au sujet de PCI, vous ne voulez probablement pas à utiliser AWS personnalisée de dépôts.

   # rpm -Uvh https://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
   # yum install cloud-init
   

2. Modifier /etc/cloud/cloud.cfg, un fichier yaml, afin de refléter la configuration de votre choix. Ci-dessous est une configuration minimale à la documentation de chaque module.

   #If this is not explicitly false, cloud-init will change things so that root
   #login via ssh is disabled. If you don't want it to do anything, set it false.
   disable_root: false
   
   #Set this if you want cloud-init to manage hostname. The current
   #/etc/hosts file will be replaced with the one in /etc/cloud/templates.
   manage_etc_hosts: true
   
   #Since cloud-init runs at multiple stages of boot, this needs to be set so
   #it can log in all of them to /var/log/cloud-init.
   syslog_fix_perms: null
   
   #This is the bit that makes userdata work. You need this to have userdata
   #scripts be run by cloud-init.
   datasource_list: [Ec2]
   datasource:
     Ec2:
       metadata_urls: ['http://169.254.169.254']
   
   #modules that run early in boot
   cloud_init_modules:
    - bootcmd  #for running commands in pre-boot. Commands can be defined in cloud-config userdata.
    - set-hostname  #These 3 make hostname setting work
    - update-hostname
    - update-etc-hosts
   
   #modules that run after boot
   cloud_config_modules:
    - runcmd  #like bootcmd, but runs after boot. Use this instead of bootcmd unless you have a good reason for doing so.
   
   #modules that run at some point after config is finished
   cloud_final_modules:
    - scripts-per-once  #all of these run scripts at specific events. Like bootcmd, can be defined in cloud-config.
    - scripts-per-boot
    - scripts-per-instance
    - scripts-user
    - phone-home  #if defined, can make a post request to a specified url when done booting
    - final-message  #if defined, can write a specified message to the log
    - power-state-change  #can trigger stuff based on power state changes
   
   system_info:
     #works because amazon's linux AMI is based on CentOS
     distro: amazon
   

3. Si il y a un defaults.cfg dans /etc/cloud/cloud.cfg.d/, de le supprimer.

4. De prendre avantage de cette configuration, définissez les paramètres suivants userdata pour les nouvelles instances:

   #cloud-config
   hostname: myhostname
   fqdn: myhostname.mydomain.com
   runcmd:
    - echo "I did this thing post-boot"
    - echo "I did this too"
   

   Vous pouvez aussi tout simplement exécuter un script bash en remplaçant #cloud-config avec #!/bin/bash et de mettre le script bash dans le corps, mais si vous le faites, vous devez supprimer tous les nom d'hôte modules de cloud_init_modules.

Notes Complémentaires

Noter que c'est une configuration minimale, et le cloud-init est capable de gérer les utilisateurs, les clés ssh, les points de montage, etc. Regardez les références ci-dessous pour plus de documentation sur les fonctions en question.

En général, il semble que le cloud-init ne la substance basée sur les modules spécifiés. Certains modules, comme "disable-ec2-métadonnées", faire des trucs tout simplement par le fait d'être spécifié. D'autres, comme "runcmd", seulement de faire des trucs si leurs paramètres sont spécifiés, soit dans le cloud.cfg, ou dans le cloud-config userdata. La plupart de la documentation ci-dessous seulement vous dire ce que les paramètres sont possibles pour chaque module, pas ce que le module est appelé, mais le nuage par défaut.cfg doit avoir un module complet de la liste pour commencer. Le meilleur moyen que j'ai trouvé pour désactiver un module est tout simplement de le supprimer de la liste.

Dans certains cas, "rhel" peut travailler mieux pour la "distribution" de la balise que "amazon". Je n'ai pas vraiment compris quand.

Références

• Comment installer cloud-init: http://web.archive.org/web/20140925130743/http://docs.openstack.org/grizzly/openstack-image/content/centos-image.html
• Modules de référence (incomplet): http://cloudinit.readthedocs.org/en/latest/topics/examples.html
• Modules de référence (incomplet): https://github.com/number5/cloud-init/blob/master/doc/examples/cloud-config.txt
• Instructions de configuration générale: http://web.archive.org/web/20150110200930/http://www.scalehorizontally.com/2013/02/24/introduction-to-cloud-init
• Nom d'hôte de gestion: http://web.archive.org/web/20140805225413/http://docs.openstack.org/user-guide/content/user-data.html

Voici un bref tutoriel sur la façon d'exécuter des scripts au démarrage à l'aide de cloud-init sur AWS EC2 (CentOS).

Ce tutoriel vous explique:

• comment fixer le fichier de configuration /etc/cloud/cloud.cfg
• comment le nuage chemin /var/lib/cloud/scripts ressemble
• les fichiers de script sous le nuage chemin à l'aide d'un exemple, et
• comment vérifier si les fichiers de script sont exécutés au démarrage de l'instance

Fichier de Configuration

Le fichier de configuration ci-dessous est sur AWS CentOS6. Pour Amazon Linux, voir ici.

# cat /etc/cloud/cloud.cfg
manage_etc_hosts: localhost
user: root
disable_root: false
ssh_genkeytypes: [ rsa, dsa ]

cloud_init_modules:
 - resizefs
 - update_etc_hosts
 - ssh

cloud_final_modules:
 - scripts-per-once
 - scripts-per-boot
 - scripts-per-instance
 - scripts-user

Arborescence De Répertoire

Ici est ce que le cloud chemin /var/lib/cloud/scripts ressemble:

# cd /var/lib/cloud/scripts
# tree `pwd`
/var/lib/cloud/scripts
├── per-boot
│     └── per-boot.sh
├── per-instance
│     └── per-instance.sh
└── per-once
       └── per-once.sh

Contenu des Fichiers de Script

Voici le contenu de l'exemple des fichiers de script.

Les fichiers doivent être en vertu de l'utilisateur root. Voir mon chemin sur créer le script de démarrage.

# cat /var/lib/cloud/scripts/per-boot/per-boot.sh
#!/bin/sh
echo per-boot: `date` >> /tmp/per-xxx.txt

# cat /var/lib/cloud/scripts/per-instance/per-instance.sh
#!/bin/sh
echo per-instance: `date` >> /tmp/per-xxx.txt

# cat /var/lib/cloud/scripts/per-once/per-once.sh   
#!/bin/sh
echo per-once: `date` >> /tmp/per-xxx.txt

Résultat de l'Exécution

Dans le cas de démarrage initial

# cat /tmp/per-xxx.txt
per-once: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:30:16 JST 
per-instance: 1 January 3, 2013 Thursday 17:30:16 JST

Dans le cas d'un redémarrage

# cat /tmp/per-xxx.txt
per-once: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:30:16 JST 
per-instance: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:32:24 JST

Dans le cas de démarrage à partir de l'AMI

# cat /tmp/per-xxx.txt
per-once: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:30:16 JST 
per-instance: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:32:24 JST 
per-boot: 1 January 3, 2013 Thursday 17:44:08 JST

Référence

Le moment où le script est exécuté dans le cloud-init (CentOS6) a été examiné (traduit)