Informação para distribuição apoiadas pela comunidade e não endossadas

Aplica-se a: ✔️ Conjuntos de escala flexível Linux VMs ✔️

A plataforma Azure SLA aplica-se a máquinas virtuais que executam o Sistema Linux apenas quando uma das distribuições endossadas é utilizada. Para estas distribuições endossadas, as imagens Linux pré-configuradas são fornecidas no Azure Marketplace.

Todas as outras distribuições não Azure Marketplace, que estão a decorrer no Azure têm vários pré-requisitos. Este artigo não pode ser abrangente, pois cada distribuição é diferente. Mesmo que cumpra todos os critérios abaixo, poderá ter de ajustar significativamente o seu sistema Linux para que possa funcionar corretamente.

Este artigo centra-se na orientação geral para executar a sua distribuição Linux no Azure.

Notas de instalação gerais do Linux

  1. O formato de disco rígido virtual Hyper-V (VHDX) não é suportado em Azure, apenas VHD fixo. Pode converter o disco em formato VHD utilizando o Hyper-V Manager ou o cmdlet Convert-VHD . Se estiver a utilizar a VirtualBox, selecione tamanho fixo em vez do padrão (atribuído dinamicamente) ao criar o disco.

  2. Azure suporta máquinas virtuais Gen1 (bota BIOS) & Gen2 (bota UEFI).

  3. O tamanho máximo permitido para o VHD é de 1.023 GB.

  4. Ao instalar o sistema Linux, recomendamos que utilize divisórias padrão, em vez de Logical Volume Manager (LVM), que é o padrão para muitas instalações. A utilização de divisórias padrão evitará conflitos de nome LVM com VMs clonados, especialmente se um disco de SO for alguma vez ligado a outro VM idêntico para resolução de problemas. LVM ou RAID podem ser usados em discos de dados.

  5. É necessário suporte kernel para a montagem de sistemas de ficheiros UDF. No início, a configuração de provisionamento é passada para o Linux VM utilizando meios formatados pela UDF que estão ligados ao hóspede. O agente Azure Linux deve montar o sistema de ficheiros UDF para ler a sua configuração e a provisionar o VM.

  6. As versões de kernel Linux antes de 2.6.37 não suportam UMA em Hyper-V com tamanhos VM maiores. Esta emissão afeta principalmente as distribuições mais antigas utilizando o núcleo a montante do chapéu vermelho 2.6.32, e foi fixada em Red Hat Enterprise Linux (RHEL) 6.6 (kernel-2.6.32-504). Os sistemas que executam núcleos personalizados com mais de 2.6.37, ou núcleos baseados em RHEL com mais de 2.6.32-504 devem definir o parâmetro numa=off de arranque na linha de comando do núcleo em grub.conf. Para mais informações, consulte o Red Hat KB 436883.

  7. Não configuure uma partição de troca no disco SO. O agente Linux pode ser configurado para criar um ficheiro de troca no disco de recursos temporários, conforme descrito nos passos seguintes.

  8. Todos os VHDs em Azure devem ter um tamanho virtual alinhado a 1 MB (1024 × bytes 1024). Ao converter de um disco cru para VHD deve certificar-se de que o tamanho do disco bruto é um múltiplo de 1 MB antes da conversão, conforme descrito nos passos seguintes.

  9. Utilize a versão de distribuição mais atualizada, pacotes e software.

  10. Remova os utilizadores e contas do sistema, chaves públicas, dados sensíveis, software e aplicação desnecessários.

Instalação de módulos de núcleo sem Hiper-V

O Azure funciona no hipervisor Hiper-V, por isso o Linux requer certos módulos de núcleo para funcionar em Azure. Se tiver um VM que foi criado fora do Hyper-V, os instaladores Linux podem não incluir os controladores de Hiper-V no ramdisk inicial (initrd ou initramfs), a menos que o VM detete que está a funcionar num ambiente Hiper-V. Ao utilizar um sistema de virtualização diferente (como VirtualBox, KVM, e assim por diante) para preparar a sua imagem Linux, poderá ter de reconstruir o initrd para que pelo menos os módulos de kernel hv_vmbus e hv_storvsc estejam disponíveis no ramdisco inicial. Esta questão conhecida é para sistemas baseados na distribuição a montante do Red Hat, e possivelmente outros.

O mecanismo de reconstrução da imagem initrd ou initramfs pode variar dependendo da distribuição. Consulte a documentação ou suporte da sua distribuição para o procedimento adequado. Aqui está um exemplo para a reconstrução do initrd utilizando a mkinitrd utilidade:

  1. Apoie a imagem initrd existente:

    cd /boot
    sudo cp initrd-`uname -r`.img  initrd-`uname -r`.img.bak
    
  2. Reconstruir com initrd os hv_vmbus módulos e hv_storvsc kernel:

    sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-`uname -r`.img `uname -r`
    

Redimensionamento VHDs

As imagens VHD em Azure devem ter um tamanho virtual alinhado a 1 MB. Normalmente, os VHDs criados com Hiper-V estão alinhados corretamente. Se o VHD não estiver corretamente alinhado, poderá receber uma mensagem de erro semelhante à seguinte quando tentar criar uma imagem a partir do seu VHD.

The VHD http:\//\<mystorageaccount>.blob.core.windows.net/vhds/MyLinuxVM.vhd has an unsupported virtual size of 21475270656 bytes. The size must be a whole number (in MBs).

Neste caso, redimensione o VM utilizando a consola Hyper-V Manager ou o cmdlet Resize-VHD PowerShell. Se não estiver a funcionar num ambiente Windows, recomendamos que se converta qemu-img (se necessário) e redimensione o VHD.

Nota

Existe um bug conhecido nas versões >qemu-img =2.2.1 que resulta num VHD inadequadamente formatado. A questão foi corrigida no QEMU 2.6. Recomendamos a utilização de qemu-img 2.2.0 ou inferior, ou 2.6 ou superior.

  1. Redimensionar o VHD diretamente utilizando ferramentas como qemu-img ou vbox-manage podem resultar num VHD insaciável. Recomendamos primeiro a conversão do VHD para uma imagem de disco RAW. Se a imagem VM foi criada como uma imagem de disco RAW (o padrão para alguns hipervisores como o KVM), então pode saltar este passo.

    qemu-img convert -f vpc -O raw MyLinuxVM.vhd MyLinuxVM.raw
    
  2. Calcular o tamanho necessário da imagem do disco de modo a que o tamanho virtual esteja alinhado a 1 MB. O seguinte script de concha de bash usa qemu-img info para determinar o tamanho virtual da imagem do disco e, em seguida, calcula o tamanho para o próximo 1 MB.

    rawdisk="MyLinuxVM.raw"
    vhddisk="MyLinuxVM.vhd"
    
    MB=$((1024*1024))
    size=$(qemu-img info -f raw --output json "$rawdisk" | \
    gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}')
    
    rounded_size=$(((($size+$MB-1)/$MB)*$MB))
    
    echo "Rounded Size = $rounded_size"
    
  3. Redimensione o disco cru utilizando $rounded_size como definido acima.

    qemu-img resize MyLinuxVM.raw $rounded_size
    
  4. Agora, converta o disco RAW de volta para um VHD de tamanho fixo.

    qemu-img convert -f raw -o subformat=fixed -O vpc MyLinuxVM.raw MyLinuxVM.vhd
    

    Ou, com a versão qemu 2.6+, incluir a opção force_size .

    qemu-img convert -f raw -o subformat=fixed,force_size -O vpc MyLinuxVM.raw MyLinuxVM.vhd
    

Requisitos de Kernel Linux

Os controladores linux integration services (LIS) para Hyper-V e Azure são contribuídos diretamente para o kernel linux a montante. Muitas distribuições que incluem uma versão recente do kernel do Linux (como 3.x) já têm estes controladores disponíveis, ou de outra forma fornecem versões backported destes condutores com os seus núcleos. Estes controladores estão constantemente a ser atualizados no núcleo a montante com novas correções e funcionalidades, pelo que, quando possível, recomendamos a execução de uma distribuição endossada que inclua estas correções e atualizações.

Se estiver a executar uma variante das versões Red Hat Enterprise Linux 6.0 a 6.3, então terá de instalar os mais recentes controladores LIS para Hyper-V. A partir do RHEL 6.4+ (e derivados), os condutores lis já estão incluídos com o núcleo e, por isso, não são necessários pacotes de instalação adicionais.

Se for necessário um núcleo personalizado, recomendamos uma versão recente do núcleo (como 3.8+). Para distribuições ou fornecedores que mantenham o seu próprio núcleo, você precisará de apoiar regularmente os condutores LIS do núcleo a montante para o seu núcleo personalizado. Mesmo que já esteja a executar uma versão de kernel relativamente recente, recomendamos vivamente que se mantenha atento a quaisquer correções a montante nos condutores lis e os apoie conforme necessário. As localizações dos ficheiros de origem do condutor LIS estão especificadas no ficheiro KEEPERS na árvore de origem do núcleo Linux:

    F:    arch/x86/include/asm/mshyperv.h
    F:    arch/x86/include/uapi/asm/hyperv.h
    F:    arch/x86/kernel/cpu/mshyperv.c
    F:    drivers/hid/hid-hyperv.c
    F:    drivers/hv/
    F:    drivers/input/serio/hyperv-keyboard.c
    F:    drivers/net/hyperv/
    F:    drivers/scsi/storvsc_drv.c
    F:    drivers/video/fbdev/hyperv_fb.c
    F:    include/linux/hyperv.h
    F:    tools/hv/

As seguintes manchas devem ser incluídas no núcleo. Esta lista não pode estar completa para todas as distribuições.

O Agente Azure Linux

O Agente waagentAzure Linux fornece uma máquina virtual Linux em Azure. Pode obter a versão mais recente, problemas de ficheiros ou enviar pedidos de pull no repo do Agente Linux GitHub.

  • O agente Linux é libertado sob a licença Apache 2.0. Muitas distribuições já fornecem pacotes de RPM ou .deb para o agente, e estes pacotes podem ser facilmente instalados e atualizados.
  • O agente Azure Linux requer Python v2.6+.
  • O agente também requer o módulo python-pyasn1. A maioria das distribuições fornece este módulo como um pacote separado para ser instalado.
  • Em alguns casos, o Agente Azure Linux pode não ser compatível com o NetworkManager. Muitos dos pacotes RPM/deb fornecidos pelas distribuições configuram o NetworkManager como um conflito para o pacote waagent. Nestes casos, irá desinstalar o NetworkManager quando instalar o pacote de agente Linux.
  • O Agente Azure Linux deve estar na versão mínima suportada.

Nota

Certifique-se de que os módulos 'udf' (cloud-init >= 21.2) e 'vfat' estão ativas. A bloqueamento do módulo UDF causará uma falha no provisionamento e o módulo vfat de backlist irá causar falhas no provisionamento e no arranque. O cloud-init < 21.2 não é afetado e não requer esta alteração.

Requisitos gerais do sistema Linux

  1. Modifique a linha de arranque do núcleo em GRUB ou GRUB2 para incluir os seguintes parâmetros, de modo a que todas as mensagens de consola sejam enviadas para a primeira porta em série. Estas mensagens podem ajudar suporte do Azure a depurar quaisquer problemas.

    GRUB_CMDLINE_LINUX="rootdelay=300 console=ttyS0 earlyprintk=ttyS0 net.ifnames=0"
    

    Recomendamos também a remoção dos seguintes parâmetros, se existirem.

    rhgb quiet crashkernel=auto
    

    A bota gráfica e silenciosa não é útil num ambiente em nuvem, onde queremos que todos os registos enviados para a porta em série. A crashkernel opção pode ser deixada configurada se necessário, mas note que este parâmetro reduz a quantidade de memória disponível no VM em pelo menos 128 MB, o que pode ser problemático para tamanhos de VM menores.

  2. Depois de ter terminado a edição /etc/predefinição/comida, executar o seguinte comando para reconstruir a configuração da larva:

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg
    
  3. Adicione os módulos Hiper-V tanto initrd como initramfs (Dracut).

  4. Reconstruir initramfs initramfs

    cp /boot/initramfs-$(uname -r).img /boot/initramfs-[latest kernel version ].img.bak 
    dracut -f -v /boot/initramfs-[latest kernel version ].img  [depending on the version of grub] 
    grub-mkconfig -o /boot/grub/grub.cfg 
    grub2-mkconfig -o /boot/grub2/grub.cfg 
    

    Initrd

    mv /boot/[initrd kernel] /boot/[initrd kernel]-old 
    mkinitrd /boot/initrd.img-[initrd kernel]-generic /boot/[initrd kernel]-generic-old 
    update-initramfs -c -k [initrd kernel] 
    update-grub 
    
  5. Certifique-se de que o servidor SSH está instalado e configurado para começar na hora de arranque. Esta configuração é geralmente o padrão.

  6. Instale o Agente Azure Linux. O agente Azure Linux é necessário para o fornecimento de uma imagem Linux em Azure. Muitas distribuições fornecem o agente como um pacote RPM ou .deb (o pacote é tipicamente chamado WALinuxAgent ou walinuxagent). O agente também pode ser instalado manualmente seguindo os passos no Guia de Agente Linux.

    Instale o Agente Azure Linux, cloud-init e outros utilitários necessários executando o seguinte comando:

    Redhat/Centos

    sudo yum install -y [waagent] cloud-init cloud-utils-growpart gdisk hyperv-daemons
    

    Ubuntu/Debian

    sudo apt install walinuxagent cloud-init cloud-utils-growpart gdisk hyperv-daemons
    

    Suse

    sudo zypper install python-azure-agent cloud-init cloud-utils-growpart gdisk hyperv-daemons
    

    Em seguida, ative o agente e o cloud-init em todas as distribuições utilizando:

    sudo systemctl enable waagent.service
    sudo systemctl enable cloud-init.service
    
  7. Não crie espaço de troca no disco so. O Agente Azure Linux pode configurar automaticamente o espaço de troca utilizando o disco de recursos local que é ligado ao VM após o provisionamento no Azure. O disco de recursos local é um disco temporário, e pode ser esvaziado quando o VM é desprovisionado. Depois de instalar o Agente Azure Linux, modifique os seguintes parâmetros em /etc/waagent.conf conforme necessário.

    ResourceDisk.Format=y
    ResourceDisk.Filesystem=ext4
    ResourceDisk.MountPoint=/mnt/resource
    ResourceDisk.EnableSwap=y
    ResourceDisk.SwapSizeMB=2048    ## NOTE: Set this to your desired size.
    
  8. Configure a nuvem para lidar com o provisionamento:

    1. Configure waagent para cloud-init:
      sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-init/g' /etc/waagent.conf
      sed -i 's/ResourceDisk.Format=y/ResourceDisk.Format=n/g' /etc/waagent.conf
      sed -i 's/ResourceDisk.EnableSwap=y/ResourceDisk.EnableSwap=n/g' /etc/waagent.conf
      
      Se estiver a migrar uma máquina virtual específica e não pretender criar uma imagem generalizada, definida Provisioning.Agent=disabled no /etc/waagent.conf config.
    2. Suportes de configuração:
      echo "Adding mounts and disk_setup to init stage"
      sed -i '/ - mounts/d' /etc/cloud/cloud.cfg
      sed -i '/ - disk_setup/d' /etc/cloud/cloud.cfg
      sed -i '/cloud_init_modules/a\\ - mounts' /etc/cloud/cloud.cfg
      sed -i '/cloud_init_modules/a\\ - disk_setup' /etc/cloud/cloud.cfg
      
    3. Configurar fonte de dados Azure:
      echo "Allow only Azure datasource, disable fetching network setting via IMDS"
      cat > /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg <<EOF
      datasource_list: [ Azure ]
      datasource:
         Azure:
           apply_network_config: False
      EOF
      
    4. Se configurado, remova o ficheiro de swap existente:
      if [[ -f /mnt/resource/swapfile ]]; then
      echo "Removing swapfile" #RHEL uses a swapfile by defaul
      swapoff /mnt/resource/swapfile
      rm /mnt/resource/swapfile -f
      fi
      
  9. Configure a madeira de nuvem::

    echo "Add console log file"
    cat >> /etc/cloud/cloud.cfg.d/05_logging.cfg <<EOF
    
    # This tells cloud-init to redirect its stdout and stderr to
    # 'tee -a /var/log/cloud-init-output.log' so the user can see output
    # there without needing to look on the console.
    output: {all: '| tee -a /var/log/cloud-init-output.log'}
    EOF
    
  10. Troca de configuração. Não crie espaço de troca no disco do sistema operativo. Anteriormente, o Agente Azure Linux configurava automaticamente o espaço de troca utilizando o disco de recursos local que é ligado à máquina virtual após a aprovisionamento da máquina virtual no Azure. No entanto, isto agora é tratado por cloud-init, não deve usar o Agente Linux para formatar o disco de recursos criar o ficheiro swap, modificar os seguintes parâmetros em /etc/waagent.conf adequadamente:

    ResourceDisk.Format=n
    ResourceDisk.EnableSwap=n
    

    Se quiser montar, formatar e criar uma troca, pode: 1. Passar isto como um config de nuvem sempre que criar um VM através customdata. Este é o método recomendado. 2. Utilize uma diretiva de entrada em nuvem cozida na imagem que o fará sempre que o VM for criado.

           echo 'DefaultEnvironment="CLOUD_CFG=/etc/cloud/cloud.cfg.d/00-azure-swap.cfg"' >> /etc/systemd/system.conf
           cat > /etc/cloud/cloud.cfg.d/00-azure-swap.cfg << EOF
           #cloud-config
           # Generated by Azure cloud image build
           disk_setup:
             ephemeral0:
               table_type: mbr
               layout: [66, [33, 82]]
               overwrite: True
           fs_setup:
             - device: ephemeral0.1
               filesystem: ext4
             - device: ephemeral0.2
               filesystem: swap
           mounts:
             - ["ephemeral0.1", "/mnt"]
             - ["ephemeral0.2", "none", "swap", "sw,nofail,x-systemd.requires=cloud-init.service,x-systemd.device-timeout=2", "0", "0"]
           EOF
    
         ```
    
    
  11. Deprovision.

    Atenção

    Se estiver a migrar uma máquina virtual específica e não pretender criar uma imagem generalizada, ignore o passo de desprovisionamento. Executar o comando waagent -force -deprovision+user tornará a máquina de origem inutilizável, este passo destina-se apenas a criar uma imagem generalizada.

    Executar os seguintes comandos para desprovisionar a máquina virtual.

    # sudo rm -f /var/log/waagent.log
    # sudo cloud-init clean
    # waagent -force -deprovision+user
    # rm -f ~/.bash_history
    # export HISTSIZE=0
    # logout
    

    Nota

    Na Virtualbox pode ver o seguinte erro depois de executar waagent -force -deprovision que diz [Errno 5] Input/output error. Esta mensagem de erro não é crítica e pode ser ignorada.

  12. Desligue a máquina virtual e carreque o VHD para Azure.

Passos Seguintes

Crie um Linux VM a partir de um disco personalizado com o Azure CLI.