102.6 Lição 1

Certificação:

LPIC-1

Versão:

5.0

Tópico:

102 Instalação do Linux e gerenciamento de pacotes

Objetivo:

102.6 O Linux como máquina virtual

Lição:

1 de 1

Introdução

Um dos maiores pontos fortes do Linux é sua versatilidade. Um aspecto dessa versatilidade é a possibilidade de usar o Linux como meio de hospedar outros sistemas operacionais, ou aplicativos individuais, em um ambiente completamente isolado e seguro. Esta lição será dedicada aos conceitos de virtualização e tecnologias de contêiner, juntamente com alguns detalhes técnicos que devem ser levados em conta ao se implementar uma máquina virtual em uma plataforma de nuvem.

O que é virtualização?

A virtualização é uma tecnologia que permite que uma plataforma de software, chamada de hipervisor, execute processos que contêm um sistema inteiramente emulado (virtual). O hipervisor é responsável por gerenciar os recursos do hardware físico que podem ser usados por máquinas virtuais individuais. Essas máquinas virtuais são chamadas de guests (convidados) do hypervisor. Muitos dos aspectos de um computador físico são emulados por software na máquina virtual, como a BIOS do sistema e os controladores de disco rígido. Uma máquina virtual geralmente usa imagens de disco rígido que são armazenadas como arquivos individuais e tem acesso à RAM e à CPU da máquina hospedeira por meio do software hipervisor. O hipervisor divide o acesso aos recursos de hardware do sistema hospedeiro entre os convidados, permitindo assim que vários sistemas operacionais sejam executados em um único sistema hospedeiro.

Dentre os hipervisores mais comumente usados no Linux, podemos citar:

Xen: O Xen é um hipervisor de código aberto de Tipo 1, o que significa que ele não depende de um sistema operacional subjacente para funcionar. Um hipervisor desse tipo é conhecido como hipervisor bare-metal, pois o computador pode inicializar diretamente no hipervisor.
KVM: O Kernel Virtual Machine é um módulo de virtualização do kernel do Linux. O KVM é um hipervisor de Tipo 1 e também de Tipo 2 porque, embora precise de um sistema operacional Linux genérico para funcionar, é capaz de agir perfeitamente bem como hipervisor integrando-se a uma instalação Linux em execução. As máquinas virtuais implementadas com o KVM usam o daemon libvirt e utilitários de software associados para serem criadas e gerenciadas.
VirtualBox: Um aplicativo desktop popular que facilita a criação e o gerenciamento de máquinas virtuais. O Oracle VM VirtualBox é multiplataforma e funciona em Linux, macOS e Microsoft Windows. Como o VirtualBox requer um sistema operacional subjacente para ser executado, ele é um hipervisor de Tipo 2.

Alguns hipervisores permitem a realocação dinâmica de uma máquina virtual. O processo de mover uma máquina virtual de uma instalação do hipervisor para outra é chamado de migração e as técnicas envolvidas são diferentes conforme as implementações do hipervisor. Algumas migrações só podem ser realizadas quando o sistema convidado está completamente desligado e outras podem ser feitas com o convidado em execução (é o que chamamos migração ao vivo). Essas técnicas podem ser úteis durante a manutenção dos hipervisores, ou ainda para garantir a resiliência do sistema quando um hipervisor para de funcionar, sendo possível mover o convidado para outro.

Tipos de máquina virtual

Existem três tipos principais de máquinas virtuais, o convidado totalmente virtualizado, o convidado paravirtualizado e o convidado híbrido.

Totalmente virtualizado: Todas as instruções que um sistema operacional convidado precisa executar devem poder rodar em uma instalação de sistema operacional totalmente virtualizada. A razão para isso é que nenhum driver de software adicional é instalado na máquina virtual para traduzir as instruções para o hardware simulado ou real. O convidado totalmente virtualizado (ou HardwareVM) não sabe que é uma instância de máquina virtual em execução. Para que esse tipo de virtualização seja possível com hardware baseado em x86, as extensões de CPU Intel VT-x ou AMD-V devem ser habilitadas no sistema no qual o hipervisor está instalado. Isso pode ser feito a partir de um menu de configuração de firmware na BIOS ou UEFI.
Paravirtualizado: Um convidado paravirtualizado (ou PVM) é aquele que está ciente de ser uma instância de máquina virtual em execução. Esses tipos de convidados fazem uso de um kernel modificado e drivers especiais (conhecidos como drivers convidados) que ajudam o sistema operacional convidado a utilizar os recursos de software e hardware do hipervisor. O desempenho de um convidado paravirtualizado costuma ser melhor do que o de um convidado totalmente virtualizado devido à vantagem oferecida por esses drivers de software.
Híbrido: A paravirtualização e a virtualização total podem ser combinadas para permitir que sistemas operacionais não modificados tenham um desempenho de E/S quase nativo usando drivers paravirtualizados em sistemas operacionais totalmente virtualizados. Os drivers paravirtualizados contêm drivers de dispositivos de armazenamento e de rede com desempenho aprimorado de E/S de disco e de rede.

As plataformas de virtualização geralmente fornecem drivers convidados para os sistemas operacionais virtualizados. O KVM utiliza drivers do projeto Virtio, enquanto o Oracle VM VirtualBox usa Extensões de Convidado disponíveis em um arquivo de imagem ISO de CD-ROM para download.

Exemplo de máquina virtual `libvirt`

Veremos um exemplo de máquina virtual que é gerenciada por libvirt e usa o hipervisor KVM. Uma máquina virtual geralmente consiste em um grupo de arquivos, principalmente um arquivo XML que define a máquina virtual (sua configuração de hardware, conectividade de rede, recursos de exibição etc.) e um arquivo de imagem de disco rígido associado contendo a instalação do sistema operacional e seu software.

Primeiro, vamos examinar um exemplo de arquivo de configuração XML para uma máquina virtual e seu ambiente de rede:

$ ls /etc/libvirt/qemu
total 24
drwxr-xr-x 3 root root 4096 Oct 29 17:48 networks
-rw------- 1 root root 5667 Jun 29 17:17 rhel8.0.xml

Note

A parte qemu do caminho do diretório se refere ao software subjacente do qual dependem as máquinas virtuais baseadas em KVM. O projeto QEMU fornece software para o hipervisor para emular os dispositivos de hardware que serão usados pela máquina virtual, como controladores de disco, acesso à CPU do host, emulação de placa de rede e muito mais.

Observe que existe um diretório chamado networks. Esse diretório contém arquivos de definição (que também usam XML) que criam configurações de rede utilizáveis pelas máquinas virtuais. Este hipervisor está usando apenas uma rede e, portanto, há apenas um arquivo de definição contendo uma configuração para um segmento de rede virtual que será usado por esses sistemas.

$ ls -l /etc/libvirt/qemu/networks/
total 8
drwxr-xr-x 2 root root 4096 Jun 29 17:15 autostart
-rw------- 1 root root  576 Jun 28 16:39 default.xml
$ sudo cat /etc/libvirt/qemu/networks/default.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit default
or other application using the libvirt API.
-->

<network>
  <name>default</name>
  <uuid>55ab064f-62f8-49d3-8d25-8ef36a524344</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:b8:e0:15'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

Esta definição inclui uma rede privada Classe C e um dispositivo de hardware emulado que age como um roteador para esta rede. Também vemos um intervalo de endereços IP que o hipervisor, junto com com uma implementação de servidor DHCP, pode atribuir às máquinas virtuais que usam esta rede. Essa configuração de rede também utiliza a tradução de endereços de rede (NAT) para encaminhar pacotes para outras redes, como a LAN do hipervisor.

Veremos a seguir um arquivo de definição de máquina virtual Red Hat Enterprise Linux 8 (as seções mais importantes estão em negrito):

$ sudo cat /etc/libvirt/qemu/rhel8.0.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit rhel8.0
or other application using the libvirt API.
-->

<domain type='kvm'>
  <name>rhel8.0</name>
  <uuid>fadd8c5d-c5e1-410e-b425-30da7598d0f6</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://redhat.com/rhel/8.0"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel8'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x10'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='2' port='0x11'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x12'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0x13'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0x14'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0x15'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
    </controller>
    <controller type='pci' index='7' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='7' port='0x16'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:50:a7:18'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <video>
      <model type='virtio' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </rng>
  </devices>
</domain>

Este arquivo define uma série de configurações de hardware que são usadas por este convidado, como a quantidade de RAM que lhe será atribuída, o número de núcleos da CPU do hipervisor a que o convidado terá acesso, o arquivo de imagem de disco rígido associado a este convidado (na estrofe disk), seus recursos de exibição (por meio do protocolo SPICE) e o acesso do convidado a dispositivos USB, bem como o teclado emulado e a entrada de mouse.

Exemplo de armazenamento em disco de uma máquina virtual

A imagem de disco rígido desta máquina virtual reside em /var/lib/libvirt/images/rhel8. Eis a imagem de disco em si neste hipervisor:

$ sudo ls -lh /var/lib/libvirt/images/rhel8
-rw------- 1 root root 5.5G Oct 25 15:57 /var/lib/libvirt/images/rhel8

O tamanho atual desta imagem de disco consome apenas 5,5 GB de espaço no hipervisor. No entanto, o sistema operacional deste convidado vê um disco de 23,3 GB, conforme evidenciado pela saída do seguinte comando lançado dentro da máquina virtual em execução:

$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda           252:0    0 23.3G  0 disk
├─vda1        252:1    0    1G  0 part /boot
└─vda2        252:2    0 22.3G  0 part
  ├─rhel-root 253:0    0   20G  0 lvm  /
  └─rhel-swap 253:1    0  2.3G  0 lvm  [SWAP]

Isso se deve ao tipo de provisionamento de disco usado para este convidado. Existem vários tipos de imagens de disco que uma máquina virtual pode usar, mas os dois principais são:

COW: Copy-on-write ou cópia na gravação (também conhecida como thin-provisioning ou sparse images) é um método em que um arquivo de disco é criado com um limite máximo de tamanho predefinido. O tamanho da imagem do disco só aumenta quando novos dados são gravados no disco. Como no exemplo anterior, o sistema operacional convidado vê o limite de disco predefinido de 23,3 GB, mas gravou apenas 5,5 GB de dados no arquivo de disco. O formato de imagem de disco usado para a máquina virtual de exemplo é qcow2, um formato de arquivo QEMU COW.
RAW: Um tipo de disco raw ou full é um arquivo que tem todo o seu espaço pré-alocado. Por exemplo, um arquivo de imagem de disco raw de 10 GB consome 10 GB de espaço em disco real no hipervisor. Esse estilo de disco permite um ganho de desempenho, pois todo o espaço em disco necessário já existe, de modo que o hipervisor subjacente pode simplesmente gravar dados no disco sem o impacto no desempenho que seria causado pela necessidade de monitorar a imagem do disco para garantir que ele não atingiu seu limite e de estender o tamanho do arquivo à medida que novos dados são gravados nele.

Existem outras plataformas de gerenciamento de virtualização, como o Red Hat Enterprise Virtualization e o oVirt, que podem lançar mão de discos físicos como locais de armazenamento secundários para o sistema operacional de uma máquina virtual. Esses sistemas utilizam dispositivos de rede de área de armazenamento (SAN) ou de armazenamento conectado à rede (NAS) para gravar seus dados, e o hipervisor controla quais locais de armazenamento pertencem a quais máquinas virtuais. Esses sistemas de armazenamento podem usar tecnologias como o gerenciamento de volume lógico (LVM) para aumentar ou diminuir o tamanho do armazenamento em disco de uma máquina virtual conforme necessário e para auxiliar na criação e gerenciamento de instantâneos de armazenamento.

Trabalhando com modelos de máquina virtual

Como as máquinas virtuais são, tipicamente, apenas arquivos em execução em um hipervisor, é fácil criar modelos que podem ser personalizados para cenários específicos de implantação. Freqüentemente, uma máquina virtual contém uma instalação básica de sistema operacional e algumas configurações de autenticação predefinidas para facilitar futuras inicializações do sistema. Isso diminui o tempo necessário para construir um novo sistema, reduzindo a quantidade de trabalho repetitivo, como a instalação de pacotes básicos e as configurações de localidade.

Esse modelo de máquina virtual pode ser copiado posteriormente para um novo sistema convidado. Nesse caso, o novo convidado receberia um novo nome e um novo endereço MAC para sua interface de rede, além de outras modificações dependendo do uso pretendido.

O D-Bus Machine ID

Muitas instalações do Linux utilizam um número de identificação de máquina gerado no momento da instalação, chamado de D-Bus machine ID. No entanto, se uma máquina virtual for clonada para ser usada como modelo para outras instalações de máquina virtual, um novo D-Bus machine ID precisará ser criado para garantir que os recursos do sistema do hipervisor sejam direcionados ao sistema convidado correto.

O comando a seguir serve para validar se existe um D-Bus machine ID para o sistema em execução:

$ dbus-uuidgen --ensure

Se nenhuma mensagem de erro for exibida, é porque já existe um ID para o sistema. Para visualizar o D-Bus machine ID atual, execute o seguinte:

$ dbus-uuidgen --get
17f2e0698e844e31b12ccd3f9aa4d94a

A sequência de caracteres exibida é o número de ID atual. Dois sistemas Linux em execução em um hipervisor não devem ter o mesmo D-Bus machine ID.

O D-Bus machine ID localiza-se em /var/lib/dbus/machine-id e está simbolicamente ligado a /etc/machine-id. Não é recomendável alterar esse número de ID em um sistema em execução, pois isso pode acarretar instabilidades e travamentos do sistema. Se duas máquinas virtuais tiverem o mesmo D-Bus machine ID, siga o procedimento abaixo para gerar um novo:

$ sudo rm -f /etc/machine-id
$ sudo dbus-uuidgen --ensure=/etc/machine-id

Se por acaso /var/lib/dbus/machine-id não for um link simbólico que remete a /etc/machine-id, /var/lib/dbus/machine-id terá de ser removido.

Implementação de máquinas virtuais na nuvem

Muitos provedores de IaaS (infraestrutura como serviço) executam sistemas de hipervisor e podem implantar imagens de máquinas virtuais para uma empresa. Praticamente todos esses provedores oferecem ferramentas que permitem a um administrador construir, implementar e configurar máquinas virtuais personalizadas com base em uma variedade de distribuições Linux. Muitos deles também possuem sistemas que permitem a implementação e migração de máquinas virtuais construídas de dentro da empresa de um cliente.

Ao avaliar a implementação de um sistema Linux em um ambiente IaaS, existem alguns elementos-chave que um administrador deve conhecer:

Instâncias de computação: Muitos provedores de nuvem cobram taxas de uso com base em “instâncias de computação”, ou o tempo de CPU que será usado por uma infraestrutura baseada em nuvem. O planejamento cuidadoso do tempo de processamento real exigido por cada aplicativo ajuda a manter gerenciáveis os custos de uma solução em nuvem.

As instâncias de computação também se referem ao número de máquinas virtuais provisionadas em um ambiente de nuvem. Também neste caso o maior número de instâncias de sistemas em execução ao mesmo tempo influencia no tempo geral de CPU que uma empresa terá de pagar.
Armazenamento em bloco: Os provedores de nuvem também oferecem diversos níveis de armazenamento em bloco para uso empresarial. Algumas ofertas consistem simplesmente em armazenamento de rede baseado na web para arquivos; outras oferecem armazenamento externo para uma máquina virtual provisionada em nuvem e usada para hospedar arquivos.

O custo dessas ofertas varia de acordo com a quantidade de armazenamento usada e a velocidade do armazenamento nos data centers do provedor. Um acesso mais rápido ao armazenamento normalmente custa mais e, inversamente, os dados "em repouso" (como no caso do arquivamento de dados) costumam ser bem baratos.
Rede: Um dos principais componentes do trabalho com um provedor de soluções em nuvem é a maneira como a rede virtual será configurada. Muitos provedores de IaaS oferecem alguma forma de utilitários baseados na web que podem ser utilizados para o projeto e implementação de diferentes rotas de rede, sub-redes e configurações de firewall. Alguns fornecem até mesmo soluções de DNS para ser possível atribuir FQDN (nomes de domínio absolutos) publicamente acessíveis aos sistemas de Internet do cliente. Existem também soluções “híbridas” capazes de conectar uma infraestrutura de rede local existente a uma infraestrutura baseada em nuvem por meio de uma VPN (rede privada virtual), unindo assim as duas infraestruturas

Acessando convidados na nuvem com segurança

O método mais comum para acessar uma máquina virtual remota em uma plataforma de nuvem é por meio do software OpenSSH. Um sistema Linux residente na nuvem teria o servidor OpenSSH em execução, enquanto um administrador usaria um cliente OpenSSH com chaves pré-compartilhadas para acesso remoto.

Um administrador executaria o seguinte comando:

$ ssh-keygen

seguindo as instruções para criar um par de chaves SSH públicas e privadas. A chave privada permanece no sistema local do administrador (armazenada em ~/.ssh/) e a chave pública é copiada para o sistema de nuvem remoto, exatamente o mesmo método que se usaria ao trabalhar com máquinas em rede em uma LAN corporativa.

O administrador então executaria o seguinte comando:

$ ssh-copy-id -i <public_key> user@cloud_server

Ele copia a chave SSH pública do par que acaba de ser gerado para o servidor de nuvem remoto. A chave pública é gravada no arquivo ~/.ssh/authorized_keys do servidor na nuvem e define as permissões apropriadas no arquivo.

Note	Se houver apenas um arquivo de chave pública no diretório `~/.ssh/`, então a opção `-i` pode ser omitida, pois o comando `ssh-copy-id` será o padrão para o arquivo de chave pública no diretório (normalmente o arquivo que termina com a extensão `.pub`).

Alguns provedores de nuvem geram automaticamente um par de chaves quando um novo sistema Linux é provisionado. O administrador precisa então baixar a chave privada para o novo sistema do provedor de nuvem e armazená-la em seu sistema local. Observe que as permissões para chaves SSH devem ser 0600 para uma chave privada e 0644 para uma chave pública.

Pré-configurando sistemas em nuvem

Uma ferramenta útil que simplifica as implementações de máquina virtual baseada em nuvem é o utilitário cloud-init. Esse comando, junto com os arquivos de configuração associados e a imagem de máquina virtual predefinida, é um método neutro (independente de fornecedor) para implementar um convidado Linux em uma infinidade de provedores de IaaS. Utilizando arquivos de texto simples YAML (YAML Ain’t Markup Language), o administrador pode pré-configurar as definições de rede, a seleção de pacotes de software, a configuração de chave SSH, a criação de contas de usuário e as configurações de localidade, além de uma série de outras opções para criar novos sistemas rapidamente.

Durante a inicialização de um novo sistema, o cloud-init lê as definições dos arquivos de configuração YAML e as aplica. Basta efetuar esse processo na configuração inicial de um sistema e a implantação de uma frota de novos sistemas em uma plataforma de provedor de nuvem ficará muito mais fácil.

A sintaxe do arquivo YAML usado com cloud-init se chama cloud-config. Eis um exemplo de arquivo cloud-config:

#cloud-config
timezone: Africa/Dar_es_Salaam
hostname: test-system

# Update the system when it first boots up
apt_update: true
apt_upgrade: true

# Install the Nginx web server
packages:
 - nginx

Observe que na linha superior não há espaço entre o símbolo hash (#) e o termo cloud-config.

Note	`cloud-init` não é apenas para máquinas virtuais. O conjunto de ferramentas `cloud-init` também pode ser usado para pré-configurar contêineres (como contêineres LXD Linux) antes da implementação.

Contêiners

A tecnologia de contêiner lembra uma máquina virtual em certos aspectos: eles proporcionam um ambiente isolado para implementar facilmente um aplicativo. Ao passo que, com uma máquina virtual, um computador inteiro é emulado, um contêiner usa apenas o software suficiente para executar um aplicativo. Dessa forma, há muito menos sobrecarga.

Os contêineres permitem uma maior flexibilidade em relação a uma máquina virtual. Um contêiner de aplicativo pode ser migrado de um hospedeiro para outro, assim como uma máquina virtual pode ser migrada de um hipervisor para outro. No entanto, às vezes, uma máquina virtual precisa ser desligada antes de poder ser migrada, enquanto no contêiner o aplicativo permanece em execução enquanto está sendo migrado. Os contêineres também facilitam a implementação de novas versões de aplicativos em conjunto com uma versão existente. Conforme os usuários fecham suas sessões com contêineres em execução, esses contêineres podem ser removidos automaticamente do sistema pelo software de orquestração de contêineres e substituídos pela nova versão, reduzindo assim o tempo de inatividade.

Note	Existem várias tecnologias de contêiner disponíveis para Linux, como Docker, Kubernetes, LXD / LXC, systemd-nspawn, OpenShift e outros. A implementação exata de um pacote de software contêiner está além do escopo do exame LPIC-1.

Os contêineres usam o mecanismo de grupos de controle (mais conhecido como cgroups) no kernel do Linux. O cgroup é uma forma de particionar os recursos do sistema, como memória, tempo do processador, bem como disco e largura de banda da rede, para um aplicativo individual. Um administrador pode usar cgroups diretamente para definir os limites de recursos do sistema em um aplicativo ou um grupo de aplicativos existentes em um único cgroup. Em essência, é isso o que o software de contêiner faz para o administrador, além de fornecer ferramentas que facilitam o gerenciamento e a implementação de cgroups.

Note	Atualmente, o conhecimento de cgroups não é necessário para prestar o exame LPIC-1. O conceito de cgroup é mencionado aqui para que o candidato tenha pelo menos algum conhecimento prévio de como um aplicativo é segregado para fins de utilização dos recursos do sistema.

Exercícios Guiados

Quais extensões de CPU são necessárias em uma plataforma de hardware baseada em x86 para rodar convidados totalmente virtualizados?
Uma instalação de servidor de missão crítica, que exige um desempenho mais rápido, provavelmente usará que tipo de virtualização?
Duas máquinas virtuais que foram clonadas a partir do mesmo modelo e que utilizam o D-Bus apresentam desempenho irregular. Ambas têm nomes de host e definições de configuração de rede separadas. Qual comando seria usado para determinar se cada uma das máquinas virtuais tem diferentes D-Bus Machine IDs?

Exercícios Exploratórios

Execute o seguinte comando para ver se seu sistema já tem extensões de CPU habilitadas para rodar uma máquina virtual (os resultados podem variar dependendo de sua CPU):

+ grep --color -E "vmx|svm" /proc/cpuinfo

+ Dependendo da saída, vmx pode estar realçado (para CPUs habilitadas com Intel VT-x) ou, ainda, svm (para CPUs habilitadas com AMD SVM). Se não obtiver resultados, consulte as instruções da BIOS ou da UEFI sobre como habilitar a virtualização para o seu processador.

Se o seu processador suporta virtualizações, procure a documentação da sua distribuição para executar um hipervisor KVM.
- Instale os pacotes necessários para executar um hipervisor KVM.
- Se estiver usando um ambiente de desktop gráfico, é recomendado instalar também o aplicativo virt-manager, um front-end gráfico que pode ser usado em uma instalação KVM. Isso ajudará na instalação e gerenciamento da máquina virtual.
- Baixe a imagem ISO de uma distribuição Linux à sua escolha e, seguindo a documentação da distribuição, crie uma nova máquina virtual usando essa ISO.

Resumo

Nesta lição, cobrimos os conceitos básicos de máquinas virtuais e contêineres e como essas tecnologias podem ser usadas com o Linux.

Descrevemos resumidamente os seguintes comandos:

dbus-uuidgen: Usado para verificar e visualizar a ID DBus de um sistema.
ssh-keygen: Usado para gerar um par de chaves SSH públicas e privadas para uso ao acessar sistemas remotos baseados em nuvem.
ssh-copy-id: Usado para copiar a chave SSH pública de um sistema para um sistema remoto para facilitar a autenticação remota.
cloud-init: Usado para auxiliar na configuração e implementação de máquinas virtuais e contêiners em um ambiente de nuvem.

Respostas aos Exercícios Guiados

Quais extensões de CPU são necessárias em uma plataforma de hardware baseada em x86 para rodar convidados totalmente virtualizados?

VT-x para as CPUs Intel ou AMD-V para CPUs AMD
Uma instalação de servidor de missão crítica, que exige um desempenho mais rápido, provavelmente usará que tipo de virtualização?

Um sistema operacional que faz uso de paravirtualização, como o Xen, pois o sistema operacional convidado poderá fazer melhor uso dos recursos de hardware disponíveis com drivers de software projetados para funcionar com o hipervisor.
Duas máquinas virtuais que foram clonadas a partir do mesmo modelo e que utilizam o D-Bus apresentam desempenho irregular. Ambas têm nomes de host e definições de configuração de rede separadas. Qual comando seria usado para determinar se cada uma das máquinas virtuais tem diferentes D-Bus Machine IDs?

dbus-uuidgen --get

Respostas aos Exercícios Exploratórios

Execute o seguinte comando para ver se seu sistema já tem extensões de CPU habilitadas para rodar uma máquina virtual (os resultados podem variar dependendo de sua CPU): grep --color -E "vmx|svm" /proc/cpuinfo. Dependendo da saída, vmx pode estar realçado (para CPUs habilitadas com Intel VT-x) ou, ainda, svm (para CPUs habilitadas com AMD SVM). Se não obtiver resultados, consulte as instruções da BIOS ou da UEFI sobre como habilitar a virtualização para o seu processador.

Os resultados variam dependendo da sua CPU. Eis um exemplo de saída de um computador com uma CPU Intel com extensões de virtualização habilitadas no firmware UEFI:

$ grep --color -E "vmx|svm" /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

Se o seu processador suporta virtualizações, procure a documentação da sua distribuição para executar um hipervisor KVM.
- Instale os pacotes necessários para executar um hipervisor KVM.
  
  O método vai variar de acordo com a distribuição, mas aqui estão alguns pontos de partida:
  
  Ubuntu — https://help.ubuntu.com/lts/serverguide/libvirt.html
  
  Fedora — https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-virtualization/
  
  Arch Linux — https://wiki.archlinux.org/index.php/KVM
- Se estiver usando um ambiente de desktop gráfico, é recomendado instalar também o aplicativo virt-manager, um front-end gráfico que pode ser usado em uma instalação KVM. Isso ajudará na instalação e gerenciamento da máquina virtual.
  
  Mais uma vez, o método vai depender da distribuição. Eis um exemplo usando o Ubuntu:
  $ sudo apt install virt-manager
- Baixe a imagem ISO de uma distribuição Linux à sua escolha e, seguindo a documentação da distribuição, crie uma nova máquina virtual usando essa ISO.
  
  O pacote virt-manager facilita muito essa tarefa. No entanto, uma máquina virtual pode ser criada a partir da linha de comando usando o comando virt-install. Experimente os dois métodos para entender como as máquinas virtuais são implementadas.