O artigo a seguir fala um pouco sobre o cloud-init e os problemas que ele tem, e como o código-fonte aberto não significa necessariamente liberdade. Se você quiser usar o cloud-init para configurar imagens-nuvem, basta rolar para baixo até o ponto número 3.

1. O que faz?

Você já se perguntou como os provedores de VPS configuram suas VMs, adicionam suas chaves SSH, criam usuários e instalam pacotes toda vez que você ativa uma nova VM na 'nuvem'? Bem, a resposta para a maioria dos fornecedores é o cloud-init. A maioria dos sistemas operacionais e distribuições enviam imagens de disco virtual com seus respectivos sistemas operacionais instalados na imagem. A instalação é mínima e pode servir como um modelo para o sistema de arquivos raiz do sistema operacional. Os mantenedores do sistema operacional também são gentis o suficiente para fornecer a imagem do disco virtual para todos os vários formatos, desde imagens de disco bruto até qcow2 e até mesmo vmdk, vdi e vhd.

A imagem também tem um pacote extra pré-instalado, que é o cloud-init. É o trabalho do cloud-init inicializar a VM (normalmente dentro de um serviço de hospedagem em nuvem como DigitalOcean, AWS ou Azure) fala com o provedor de hospedagem fonte de dados e obter as informações de configuração que ele usa para configurar a VM.

As informações de configuração podem incluir dados do usuário como chaves SSH, nome do host da instância, usuários e senhas junto com qualquer outro comando arbitrário que o usuário deseja executar.

2. O problema com Cloud-Init

Cloud-init é uma ótima ferramenta se você é um usuário de nuvem, se você está girando VMs ou contêineres e seu provedor de nuvem é gentil o suficiente para pedir uma configuração de nuvem, é ótimo! Com um arquivo de configuração em nuvem, também conhecido como seus dados de usuário, você pode adicionar usuários, executar comandos arbitrários e instalar pacotes no momento em que a VM está sendo criada. O processo pode ser repetido indefinidamente sem que comandos tediosos sejam digitados continuamente. Em breve você terá uma frota de VMs, todas com configuração idêntica.

No entanto, se você cavar um pouco mais fundo e ver como a salsicha está sendo feita, você começará a questionar alguns dos aspectos do cloud-init. Por exemplo, por padrão, a fonte de dados é como um endpoint REST e estes são essencialmente codificados no próprio pacote cloud-init. Claro, você pode configurar uma fonte de dados sozinho, mas o processo é complicado e demorado. A documentação para fazer isso é quase inexistente.

A documentação oficial nada mais é do que um manual do usuário para usuários finais que contam com serviços em nuvem preexistentes. Não diz como você pode configurar sua própria fonte de dados de inicialização em nuvem, caso você seja um fornecedor futuro. Até mesmo a documentação do usuário final é pobre, e eu recomendaria às pessoas que usassem o excelente tutorial do DigitalOcean.

Para piorar a situação, os usuários com laboratórios de virtualização domésticos e pequenas inicialização de VPS acham difícil se beneficiar dessas imagens de nuvem leves. Você não pode realmente iniciar uma VM fora desses modelos sem uma fonte de dados de inicialização em nuvem ou algum hackery que é difícil de automatizar e escalar. Em outras palavras, você não pode nem mesmo escolher ignorar o cloud-init a menos que queira criar seus próprios modelos.

De uma maneira clássica do systemd, está se libertando de suas funções predefinidas e começando a bagunçar a rede e outras partes do sistema operacional, o que confunde os usuários. Ele é empacotado no Ubuntu 18.04 ISO do servidor que não faz absolutamente nenhum sentido (pelo menos não para mim).

3. Solução alternativa para laboratórios domésticos

Todas as reclamações à parte, eu ainda tenho que lidar com o cloud-init no meu uso diário. Eu tenho uma instalação mínima do Debian 9 em hardware x86_64, que uso como um hipervisor KVM. Eu realmente queria usar as imagens de disco qcow2 fornecidas pelo Ubuntu e CentOS. Essas imagens de disco têm o sistema operacional pré-instalado e, para usá-las, você simplesmente precisa:

1. Copie-os como imagem de disco rígido virtual da sua VM.
2. Redimensione o tamanho virtual do sistema de arquivos raiz para o tamanho desejado (pelo menos 10 GB é recomendado). Isso não aumentará o tamanho físico da sua VM, mas a imagem do disco pode crescer com o tempo, conforme a VM adiciona mais dados a ela.
3. Configure as VMs usando cloud-init. O requisito mínimo é definir a senha do usuário root ou as chaves SSH, mas você pode fazer praticamente tudo que o cloud-init é capaz.

As seguintes etapas são seguidas:

1. Baixe a imagem da nuvem do seu sistema operacional favorito e salve-a no diretório / var / lib / libvirt / boot:

$ cd / var / lib / libvirt / boot
$ curl -O https: // cloud-images.ubuntu.com / xenial / current / xenial-server-cloudimg-
amd64-disk1.img
$ cd / var / lib / libvirt / images

2. Crie um disco rígido virtual vazio com o tamanho desejado e expanda a imagem qcow2 baixada nele. Eu gosto de armazenar os discos rígidos da VM no diretório / var / lib / libvirt / images /, você pode escolher um diretório diferente. O que você escolher, execute os comandos abaixo no mesmo diretório:

$ qemu-img create -f qcow2 myVM.qcow2 8G ## Crie um disco rígido com
tamanho do disco virtual de 8 GB
$ virt-resize --expand / dev / sda1 / var / lib / libvirt / boot / xenial-server-
cloudimg-amd64-disk1.img
./ myVM.qcow2

3. Crie arquivos de inicialização em nuvem. Estes são arquivos de dados e metadados do usuário:

meta-dados $ vim
id da instância: myVM
local-hostname: myVM

$ vim user-data
# cloud-config
Comercial:
- nome: root
chpasswd:
lista: |
root: myPassword
expira: Falso

O único usuário que tenho aqui é o usuário root. Se você não mencionar nenhum usuário, o usuário padrão com nome ubuntu é criado. O nome de usuário padrão difere de um sistema operacional para outro, por isso recomendo especificar um usuário, mesmo que seja apenas raiz. A próxima parte do arquivo de dados do usuário diz ao cloud-init para configurar a senha para todos os usuários aos quais deseja atribuir uma senha. Novamente, estou apenas definindo a senha apenas para o usuário root, e é minha senha. Certifique-se de que não haja espaço entre os dois pontos e a string da senha.

Melhor ainda, você pode usar chaves SSH em vez de ter senhas codificadas por aí.

$ vim user-data
# cloud-config
Comercial:
- nome: root
ssh_pwauth: True
ssh_authorized_keys:
- ssh-rsa

4. Incorpore os arquivos de dados e metadados do usuário em um iso.

$ genisoimage -output cidata-myVM.iso -volid cidata -joliet -rock user-data meta-data

Certifique-se de que o arquivo cidata-myVM.iso está situado em / var / lib / libvirt / images /

5. Vá para o diretório / var / lib / libvirt / images e inicialize a VM com o comando virt-install: $ virt-install --import --name myVM --memory 2048 --vcpus 2 --cpu host
   --disco myVM.qcow2, format = qcow2, bus = virtio --disk myVM-cidata.iso, dispositivo = cdrom
   --ponte de rede = virbr0, modelo = virtio --os-type = linux
   --os-variant = ubuntu16.04 - noautoconsole

   Agora você pode tentar fazer login na VM usando o comando virsh console myVM e usando o nome de usuário root e sua senha correspondente para fazer o login. Para sair do console, basta digitar Ctrl +]

Conclusão

As imagens de nuvem que a maioria dos fornecedores fornece são realmente eficientes em termos de utilização de recursos e também parecem muito rápidas e responsivas. O fato de que precisamos lidar com a configuração estranha do cloud-init como ponto de partida apenas impede a adoção pela comunidade de KVM e tecnologias relacionadas.

A comunidade pode aprender muito com a maneira como o Docker constrói e envia suas imagens. Eles são realmente fáceis de gerenciar, tanto como contêineres em execução quanto modelos fáceis de distribuir e usar.z