Eu tinha uma pergunta um pouco mais específica do que o OP, mas demorei um pouco para descobrir o que estava fazendo de errado. Eu pensei em postar aqui para ajudar qualquer outra pessoa a ficar com dificuldades.
Eu queria configurações de rede estática para um contêiner LXC / LXD Ubuntu 16.04 hospedado no Ubuntu 16.04. Comecei tentando o que Stéphane escreveu , mas não estava funcionando. Tudo o que consegui foi o contêiner de tentativa de DHCP padrão com um link IPv6 local, já que não há DHCP sendo servido na minha configuração.
Meu YAML inicial parecia (algo) como o seguinte (tirado da nuvem -init docs).
network:
version: 1
config:
- type: physical
name: eth0
subnets:
- type: static
address: 192.168.23.14/27
gateway: 192.168.23.1
dns_nameservers:
- 192.168.23.2
- 8.8.8.8
dns_search:
- exemplary.maas
E eu estava carregando isso em user.user-data
, conforme descrito acima.
lxc config set CONTAINER user.user-data - < CONTAINER.cloud-init-config.yml
Não foi até que encontrei a documentação do Stéphane na fonte LXC / LXD que percebi que precisava carregar esse valor em user.network-config
.
Então meu YAML final olhou (algo) assim.
version: 1
config:
- type: physical
name: eth0
subnets:
- type: static
address: 192.168.23.14/27
gateway: 192.168.23.1
dns_nameservers:
- 192.168.23.2
- 8.8.8.8
dns_search:
- exemplary.maas
Em seguida, carreguei isso em user.network-config
.
lxc config set CONTAINER user.network-config - < CONTAINER.network-config.yaml
Parece que precisarei manter dois arquivos diferentes por contêiner: um para que as configurações de rede sejam carregadas para user.network-config
; e um para outra configuração para carregar em user.user-data
a menos que eu possa encontrar uma maneira de usar um único arquivo para tudo.
Outro problema que encontrei e que não era óbvio para mim foi tentar configurar automaticamente componentes que não são de rede.
lxc config set CONTAINER user.user-data - < CONTAINER.user-data.yaml
O seguinte YAML aplicado com o comando acima (apesar de parecer correto usando lxc config show CONTAINER
) não criou nada dentro do meu contêiner.
write_files:
- content: |
# My new /etc/foo.bar file
Foo
Bar
path: /etc/foo.bar
A pista enterrada em Formatos de entrada de dados do usuário, item 5: Cloud Config Data , diz:
começa com "#cloud-config"
ou "Content-Type: text/cloud-config"
Este conteúdo é "cloud-config". Veja os exemplos de um exemplo comentado de formatos de configuração suportados.
Eu não acredito que esta documentação seja muito clara. Eu não consegui nada para trabalhar usando o formulário "Content-Type: text / cloud-config", mas eu encontrei se você colocar #cloud-config
na primeira linha, o YAML é analisado. Eu só posso supor que algo não está certo, seja o meu entendimento ou a programação de alguém. Não faz sentido para mim que o YAML que você carregou explicitamente como o valor da chave user.user-data
deva ser usado como algo diferente de dados de configuração da nuvem. Por que mais alguém faria isso se não fosse a configuração da nuvem e, portanto, por que um comentário (que nem sequer usa a sintaxe normal da shebang) seria obrigatório ?
Então, sem sentido, a sintaxe que funcionou para user.user-data
é:
#cloud-config
write_files:
- content: |
# My new /etc/foo.bar file
Foo
Bar
path: /etc/foo.bar