Gli script di dati utente non sono in esecuzione sulla mia AMI personalizzata, ma funzionano in Amazon Linux standard

Question

Ho cercato un sacco di argomenti su "script di dati utente non funziona" in questi pochi giorni, ma fino ad ora, non ho Ho ancora qualche idea sul mio caso, per favore aiutami a capire cosa è successo, grazie mille!

Secondo AWS User-data spiegazione:

Quando si avvia un caso in Amazon EC2, si ha la possibilità di passare i dati degli utenti per l'istanza che può essere utilizzato per eseguire le attività di configurazione automatizzate comuni e gli script anche correre dopo l'inizio dell'istanza.

Così ho cercato di passare il mio user-dati quando lancio esempio, questo è il mio user-dati:

#!/Bin/bash

echo 'test'>/home! /ec2-user/user-script-output.txt

Ma non c'è alcun file in questo percorso: /home/ec2-user/user-script-output.txt

Ho controllato /var/lib/cloud/instance/user-data.txt, il file esiste e lo stesso del mio script di dati utente.

Inoltre ho controllato il log in /var/log/cloud-init.log, non ci sono messaggi di errore.

Ma lo script di dati utente funziona se lancio una nuova istanza con Amazon linux (2014.09.01), ma non sono sicuro della differenza tra il mio AMI (basato su Amazon linux) e Amazon linux.

L'unica parte diversa che ho visto è che se ho eseguito questo script:

sudo yum elenco installato | grep cloud-init

mio AMI:

cloud init.noarch 0.7.2-8.33.amzn1 @ AMZN-principale

Amazon Linux:

cloud-init.noarch 0.7.2-8.33.amzn1 installato

Non sono sicuro che questo sia il motivo?

Se avete bisogno di ulteriori informazioni, sono lieto di fornire, per favore fatemi sapere cosa è successo nella mia AMI personale e come risolverlo?

molte grazie

Aggiornamento

appena trovato una risposta da questo post,

Se aggiungo # cloud-boothook nella parte superiore del file di dati utente, funziona!

#cloud-boothook 
#!/bin/bash 
echo 'test' > /home/ec2-user/user-script-output.txt 

Ma ancora non sono sicuro del perché.

Answer 1

Dati utente devono essere eseguiti correttamente senza utilizzare #cloud-boothook (che viene utilizzato per attivare i dati utente il più presto possibile durante il processo di avvio).

ho iniziato un nuovo Amazon Linux AMI e usate il vostro User Data, oltre a un po 'in più:

#!/bin/bash 

echo 'bar' > /tmp/bar 
echo 'test' > /home/ec2-user/user-script-output.txt 
echo 'foo' > /tmp/foo 

Questo ha creato con successo tre file.

Gli script di dati utente vengono eseguiti come root, quindi è necessario disporre dell'autorizzazione per creare file in qualsiasi posizione.

Noto che nel codice fornito, un esempio fa riferimento a /home/ec2-user/user-script/output.txt (con una sottodirectory) e un esempio fa riferimento a /home/ec2-user/user-script-output.txt (nessuna sottodirectory). Il comando sarebbe comprensibilmente fallito se si tenta di creare un file in una directory inesistente, ma il tuo esempio di "Aggiornamento" sembra mostrare che effettivamente ha funzionato.

Answer 2

Come ho provato, c'erano alcuni dati di bootstrap nella directory /var/lib/cloud. Dopo aver eliminato quella directory, lo script Dati utente funzionava normalmente.

rm -rf /var/lib/cloud/* 

Answer 3

User_data viene eseguito solo al primo avvio. Poiché la tua immagine è personalizzata, suppongo che sia già stata avviata una volta e quindi user_data sia disattivato.

Per Windows, è possibile farlo selezionando una casella in Ec2 Services Properties. Sto guardando al momento come farlo in modo automatico alla fine della creazione dell'immagine personalizzata.

Per Linux, suppongo che il meccanismo sia lo stesso, e user_data deve essere riattivato sull'immagine personalizzata.

Il #cloud-boothook funziona perché modifica lo script da un meccanismo user_data a uno cloud-boothook uno che viene eseguito ad ogni avvio.

---

EDIT:

Ecco il codice di riattivare avvio su Windows utilizzando PowerShell:

$configFile = "C:\\Program Files\\Amazon\\Ec2ConfigService\\Settings\\Config.xml" 
[xml] $xdoc = get-content $configFile 
$xdoc.SelectNodes("//Plugin") |?{ $_.Name -eq "Ec2HandleUserData"} |%{ $_.State = "Enabled" } 
$xdoc.SelectNodes("//Plugin") |?{ $_.Name -eq "Ec2SetComputerName"} |%{ $_.State = "Enabled" } 
$xdoc.OuterXml | Out-File -Encoding UTF8 $configFile 

$configFile = "C:\\Program Files\\Amazon\\Ec2ConfigService\\Settings\\BundleConfig.xml" 
[xml] $xdoc = get-content $configFile 
$xdoc.SelectNodes("//Property") |?{ $_.Name -eq "AutoSysprep"} |%{ $_.Value = "Yes" } 
$xdoc.OuterXml | Out-File -Encoding UTF8 $configFile 

(So che la domanda focale Linux, ma potrebbe aiutare gli altri ...)

Answer 4

Sto usando CentOS e la logica per userdata è semplice:

• Nel file /etc/rc.local c'è una chiamata per uno script initial.sh, ma sembra per una bandiera prima:

  if [ -f /var/tmp/initial ]; then 
      /var/tmp/initial.sh & 
  fi 
  

initial.sh è il file che esegue l'esecuzione dei dati dell'utente, ma alla fine cancella il flag.Quindi, se si desidera che il nuovo AMI per eseguire di nuovo user-dati, basta creare la bandiera di nuovo prima di creare l'immagine:

touch /var/tmp/initial 

Answer 5

ho anche affrontato lo stesso problema su Ubuntu 16.04 HVM AMI. Ho sollevato il problema con il supporto AWS ma ancora non sono riuscito a trovare il motivo/errore esatto che lo riguarda.

Ma ho ancora qualcosa che potrebbe aiutarti.

Prima di prendere AMI rimuovere la directory/var/lib/cloud (ogni volta). Quindi durante la creazione dell'immagine, impostalo su no-reboot.

Se queste cose continuano a non funzionare, è possibile testarlo ulteriormente forzando l'esecuzione manuale dei dati dell'utente. Anche tailf /var/log/cloud-init-output.log per lo stato di cloud-init. Dovrebbe finire con qualcosa come i moduli: final per far funzionare i dati dell'utente. Non dovrebbe rimanere bloccato sui moduli: config.

sudo rm -rf /var/lib/cloud/* sudo cloud-init init sudo cloud-init modules -m final

Non ho idea molto se i comandi di cui sopra lavorerà su CentOS o no. L'ho provato su Ubuntu.

Nel mio caso, ho anche provato a rimuovere la directory/var/lib/cloud, ma ancora non è riuscito a eseguire i dati dell'utente nel nostro scenario. Ma ho trovato una soluzione diversa per questo. Quello che abbiamo fatto è che abbiamo creato uno script con i comandi precedenti e fatto in modo che lo script venga eseguito mentre il sistema si avvia.

Ho aggiunto sotto la riga in /etc/rc.local per farlo accadere.

sudo bash /home/ubuntu/force-user-data.sh || exit 1

Ma qui è la cattura, viene eseguito lo script su ogni avvio in modo che renderà i vostri dati utente per funzionare su ogni singolo avvio, proprio come # cloud-boothook. Non preoccuparti, puoi semplicemente modificarlo rimuovendo lo stesso force-user-data.sh alla fine. Così il vostro force-user-data.sh sarà simile

#!/bin/bash sudo rm -rf /var/lib/cloud/* sudo cloud-init init sudo cloud-init modules -m final sudo rm -f /home/ubuntu/force-user-data.sh exit 0

Io apprezzo se qualcuno può mettere alcune luci sul perché non è in grado di eseguire i-dati degli utenti.

Answer 6

Ho avuto un sacco di problemi con questo. Fornirò dettagliate walk-though.

La mia ruga aggiunta è che sto usando terraform per istanziare gli host tramite una configurazione di avvio e un gruppo di scalabilità automatica.

non ho potuto farlo funzionare con l'aggiunta del Inline script nella lc.tf

user_data     = DATA << 
" 
#cloud-boothook 
#!/bin/bash 
echo 'some crap'\' 
" 
DATA 

ho potuto prenderlo dai dati degli utenti,

wget http://169.254.169.254/latest/user-data 

ma ho notato mi è stato sempre con il citazioni ancora in esso.

Ecco come ho fatto a funzionare: mi sono trasferito a tirarlo da un modello, poiché ciò che vedi è ciò che ottieni.

user_data     = "${data.template_file.bootscript.rendered}" 

Questo significa Ho anche bisogno di dichiarare il mio file di modello in questo modo:

data "template_file" "bootscript" { 
    template = "${file("bootscript.tpl")}" 

} 

ma ero ancora ottenendo un errore nei registri di init nube /var/log/cloud-init.log [ATTENZIONE]: non gestita non multipart (text/x-non-multipart) userdata: 'Content-Type: text/cloud ...'

Poi ho trovato this article about user data formatting user che ha senso, se userdata può venire in più parti, forse cloud-init necessita di comandi di cloud-init in un posto e la sceneggiatura nell'altro.

Quindi il mio bootscript.tpl assomiglia a questo:

Content-Type: multipart/mixed; boundary="//" 
MIME-Version: 1.0 

--// 
Content-Type: text/cloud-config; charset="us-ascii" 
MIME-Version: 1.0 
Content-Transfer-Encoding: 7bit 
Content-Disposition: attachment; filename="cloud-config.txt" 

#cloud-config 
cloud_final_modules: 
- [scripts-user, always] 

--// 
Content-Type: text/x-shellscript; charset="us-ascii" 
MIME-Version: 1.0 
Content-Transfer-Encoding: 7bit 
Content-Disposition: attachment; filename="userdata.txt" 

#!/bin/bash 
echo "some crap" 
--//