Início / unix / Perguntas / 433426
Accepted
pdns
Asked: 2018-03-26 06:34:18 +0800 CST

Como executar scripts userdata no Custom FreeBSD AMI?

  • 772

Eu li que você só pode executar userdata uma vez em um EC2 AMI. Se você criar uma AMI personalizada a partir de uma instância do EC2, não poderá executar o script userdata nessa AMI personalizada. Em instâncias do Ubuntu, você pode remover /var/lib/cloud/* , criar uma AMI personalizada e executar userdata na AMI personalizada. Não consigo encontrar um equivalente a /var/lib/cloud/* no FreeBSD.

Existe uma maneira de executar userdata no FreeBSD AMI personalizado ou uma alternativa para criar um AMI para que você possa executar scripts de userdata novamente?

Existe #cloud-boothook para Linux, mas para FreeBSD, só encontrei o configinit que não faz o que preciso. Passamos argumentos para os scripts userdata da linha de comando ao iniciar instâncias.

freebsd amazon-ec2

2 respostas

  1. Best Answer

    O FreeBSD AMI na AWS não fornece o mesmo nível de suporte para scripts user_data como outros AMIs. Como você apontou, ele não suporta #cloud-boothookuser_data e ignora qualquer user_data passado após a inicialização.

    Uma solução simples é a seguinte:

    sed -i '' '/KEYWORD: *firstboot$/d' /usr/local/etc/rc.d/ec2_configinit

    Isso é um hack - sua instância agora executará todos os scripts user_data, mesmo aqueles sem a #cloud-boothooktag, mas na minha opinião é muito melhor do que o comportamento padrão do script. Observe que sempre é possível desabilitar o ec2_configinitscript completamente desativando-o em /etc/rc.conf.

    • 2

  2. Eu forneço minha própria resposta, pois a resposta aceita é muito grosseira.

    ATUALIZAÇÃO: Achei a resposta aceita muito grosseira, mas no final, estou usando de qualquer maneira , pois funciona melhor para mim. O restante aqui fornecerá apenas alguns antecedentes adicionais que alguém pode achar útil. A resposta aceita funciona melhor para mim no final porque: (1) me permite sempre executar um script de shell, (2) não faz nada além de processar o arquivo de dados do usuário da maneira que explico abaixo, ( 3) Ainda posso desativá-lo no rc.conf se eu quiser.

    O problema é que, mesmo no Amazon Linux, o script de dados do usuário é executado apenas na primeira inicialização, exceto se você usar o truque MIME multipart/mixed. Você pode procurar https://cloudinit.readthedocs.io/en/latest/topics/format.html , mas estou dando um exemplo de algo que ultrapassa o limite:

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

--schnipp-schnapp
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]

--schnipp-schnapp
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="user-data.sh"

#!/bin/bash
echo "Hello World." >> /etc/motd

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

#!/bin/bash
echo "Kilroy was here." >> /etc/motd

--schnipp-schnapp
Content-Type: image/jpeg
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="imput64-8503-small.jpg"

/9j/4AAQSkZJRgABAQEAlgCWAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU
FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo
...
JFSUkfQjjHr9yT2T9SSSdLS15R/qM64pbLRUcsExOk6axzpxhiQATFSDIB6E68K/c6WlrzEoTypl
JoceL9zq7NbXis8oopa6RRNUQovmNlCM5IIzxQLkgkD0wQCAFLYaXzKkSSVEkzOZXqJJOUjsfXkf
cknJOMk++lpa9u+AGkJwsuJACiqCeJGm5pJiZJXBr4Sx04IfzZiS3I9r3/TQakADkD260tLWjxQk
hE9/tVFgPm8K/9k=

--schnipp-schnapp--

    O que descobri foi que os dois scripts são executados em ordem alfabética e a parte da imagem foi simplesmente ignorada.

    A menos que os mantenedores do FreeBSD AMI implementem esse material de várias partes e todas as coisas que ele envolve

    • gancho de texto/nuvem
    • text/cloud-config
    • text/cloud-config-archive
    • texto/jinja2
    • manipulador de texto/parte
    • text/upstart-job
    • text/x-include-once-url
    • text/x-include-url
    • text/x-shellscript

    por que você deseja que todas as outras coisas que o ec2-cloudinit executa sempre assim? Em última análise, você está sozinho.

    Não há realmente nenhum problema em apenas buscar os dados do usuário e decidir o que fazer com eles. Aqui está como você buscá-lo:

    fetch -q -o - http://169.254.169.254/latest/user-data

    e assim, se você quiser executá-lo, basta colocá-lo em rc.local:

    fetch -q -o - http://169.254.169.254/latest/user-data |sh

    ou

    fetch -q -o /tmp/user-data.sh http://169.254.169.254/latest/user-data
mkdir 700 /tmp/user-data.sh
/tmp/user-data.sh

    não é grande coisa realmente. Não tenho certeza se vale a pena suportar a complexa estrutura de várias partes. O FreeBSD AMI faz isso de maneira muito diferente, mais simples e, sem dúvida, muito bem.

    • se começar com hash-bang #! ele será salvo e executado
    • se começar com ">/var/tmp/here" será gravado no destino especificado
    • se começar com ">>/var/tmp/here" será anexado ao destino especificado
    • caso contrário, ele é tratado como um arquivo tar descompactado de scripts de shell, expandido e, em seguida, cada um dos arquivos é executado usando as regras acima.

    Como não é o padrão da AWS, eu simplesmente não me incomodaria com isso. Basta ter um único script e forçá-lo a ser executado em rc.local, ou nem mesmo executado, apenas inspecionado para encontrar algum parâmetro que controle o comportamento de alguma forma.

    • 1

relate perguntas