2016-01-29 15 views
5

Il mio modello CloudFormation è diventato piuttosto lungo. Uno dei motivi è perché la mia sezione AWS::CloudFormation::Init è diventata abbastanza grande. Questo è un piccolo esempio di quello che ho:Quali sono i vantaggi di cfn-init rispetto ai dati utente?

"ConfigDisk": { 
    "commands": { 
     "01formatFS": { 
      "command": "/sbin/mkfs.ext4 /dev/xvdf" 
     }, 
     "02mountFS": { 
      "command": "/bin/mount /dev/xvdf /var/lib/jenkins" 
     }, 
     "03changePerms": { 
      "command": "/bin/chown jenkins:jenkins /var/lib/jenkins" 
     }, 
     "04updateFStab": { 
      "command": "/bin/echo /dev/xvdf /var/lib/jenkins ext4 defaults 1 1 >> /etc/fstab" 
     } 
    } 
}, 

Non sarebbe meglio mettere proprio questo nella sezione userdata come un gruppo di comandi?

/sbin/mkfs.ext4 /dev/xvdf 
/bin/mount /dev/xvdf /var/lib/jenkins 
/bin/chown jenkins:jenkins /var/lib/jenkins 
/bin/echo /dev/xvdf /var/lib/jenkins ext4 defaults 1 1 >> /etc/fstab 

Quali sono i vantaggi di lasciare questo in Init sopra userdata?

risposta

3

Il più grande vantaggio è che non si sta inquinando i dati dell'utente se lo si utilizza anche per altri scopi. Quindi questo vive nello stack CloudFormation vs che vive in ognuno dei dati utente di Istanza.

cfn-init in pratica preleva questi dati da CloudFormation e semplicemente esegue il comando.

A seconda di come questo è complicato, si potrebbe prendere in considerazione la cottura di questo nell'AMI e semplicemente chiamarlo in un unico comando rispetto a una serie di comandi.

Un'altra differenza è che cfn-init deve essere inserito nell'AMI che si sta utilizzando per avviare la macchina. Questo è il caso di quasi tutte le AMI al giorno d'oggi quindi non è davvero una causa di grande preoccupazione.

Problemi correlati