csmart.virt_infra

Rola Ansible: Wirtualna Infrastruktura

Rola Ansible: Wirtualna Infrastruktura

Ta rola jest zaprojektowana do definiowania i zarządzania sieciami oraz gośćmi na jednym lub więcej hostach KVM. Opcja --limit Ansible pozwala zarządzać nimi indywidualnie lub jako grupą.

Rola ta jest naprawdę przeznaczona do pracy deweloperskiej, gdzie host KVM to Twoja lokalna maszyna, masz sudo i komunikujesz się z libvirtd przez qemu:///system, ale działa również na zdalnych hostach.

Obsługiwane są stany gości: uruchomiony, zamknięty, usunięty lub niezdefiniowany (aby usunąć i posprzątać).

Możesz ustawić dowolną ilość pamięci, CPU, dysków i kart sieciowych dla swoich gości, zarówno przez grupy hostów, jak i indywidualnie. Obsługiwane są mieszanki wielu dysków, w tym scsi, sata, virtio i nawet nvme (na wspieranych dystrybucjach).

Możesz tworzyć prywatne sieci NAT libvirt na hoście KVM, a następnie umieszczać maszyny wirtualne w dowolnej liczbie z nich. Goście mogą korzystać z tych sieci libvirt lub z istniejących urządzeń mostkowych Linux (np. br0) oraz mostków Open vSwitch (OVS) na hoście KVM (to nie tworzy mostków na hoście, ale sprawdza, czy interfejs mostka istnieje). Możesz zdefiniować model karty sieciowej oraz adres MAC dla każdego interfejsu, jeśli zajdzie taka potrzeba, jednak domyślnie używa idempotentnego adresu bazującego na nazwie hosta.

Możesz również tworzyć routowane sieci libvirt na hoście KVM, a następnie umieszczać maszyny wirtualne w dowolnej liczbie z nich. W tym przypadku tworzony jest nowy mostek z nazwą, którą określisz (np. br1), połączony z istniejącym interfejsem (np. eth0). Możesz określić adres MAC dla każdego interfejsu, jeśli zajdzie taka potrzeba.

Rola ta wspiera różne dystrybucje i korzysta z ich qcow2 obrazów chmur dla wygody (chociaż możesz używać własnych obrazów). Testowałem CentOS Stream, Debiana, Fedorę, openSUSE, RHEL i Ubuntu.

Dla RHEL, ustaw zmienną virt_infra_sm_creds (możliwe, że z użyciem skarbca), aby tymczasowo zarejestrować maszynę w portalu Red Hat podczas przygotowywania dysku. Podąża to za formatem z virt-builder, takim jak:

- virt_infra_sm_creds: MYUSER:hasło:MYPASSWORD

Obrazy bazowe qcow2 do użycia dla gości są określane jako zmienne w inwentarzu i powinny istnieć w katalogu z obrazami libvirt (domyślnie jest to /var/lib/libvirt/images/). Oznacza to, że nie zostaną automatycznie pobrane przez Ciebie obrazy.

Obrazy startowe gości qcow2 są tworzone z tych obrazów bazowych. Domyślnie korzystają z obrazu chmury jako pliku bazowego, jednak obsługiwane jest również klonowanie. Możesz stworzyć dodatkowe dyski według własnych potrzeb. Możesz również zdecydować się na zachowanie dowolnego obrazu dysku zamiast jego usunięcia, gdy maszyna wirtualna jest niezdefiniowana. Obrazy chmury INIT są automatycznie tworzone i dołączane do gościa, aby skonfigurować go podczas uruchamiania.

Domyślnie strefa czasowa będzie ustawiana na zgodną z hostem KVM, a użytkownik ansible będzie używany dla gościa, wraz z twoimi kluczami publicznymi SSH na hoście KVM (możesz to nadpisać). Wpisy hostów są dodawane do /etc/hosts na hoście KVM, a także modyfikuje konfigurację SSH użytkownika ansible i dodaje odcisk do known_hosts, abyś mógł od razu zalogować się przez SSH (co jest testowane jako część wdrożenia). Możesz ustawić hasło roota, jeśli naprawdę tego chcesz.

Z całym tym zestawem możesz definiować i zarządzać klastrami OpenStack/Swift/Ceph o różnych rozmiarach z wieloma sieciami, dyskami, a nawet dystrybucjami!

Wymagania

Potrzebujesz jedynie hosta Linux, zdolnego do uruchamiania KVM, kilku obrazów gości oraz podstawowego inwentarza. Ansible zajmie się resztą (na wspieranych dystrybucjach).

Działać powinien sprawny host KVM x86_64, na którym użytkownik uruchamiający Ansible może komunikować się z libvirtd za pomocą sudo.

Oczekuje wsparcia sprzętowego dla KVM w CPU, abyśmy mogli tworzyć przyspieszone maszyny gościnne i przesyłać CPU (wspiera wirtualizację zagnieżdżoną).

Możesz potrzebować Ansible oraz Jinja >= 2.8, ponieważ robi rzeczy takie jak porównania 'equalto'.

Testowałem to na CentOS Stream 8, Fedorze 3x, Debianie 10, Ubuntu Bionic/Eoan i openSUSE 15, ale na innych maszynach Linux prawdopodobnie to zadziała.

Co najmniej jedna para kluczy SSH na twoim hoście KVM (Ansible wygeneruje jedną, jeśli brakuje). Klucz SSH używany dla gości nie powinien wymagać hasła SSH, jeśli znajduje się na zdalnym hoście KVM. Jeśli lokalnie, upewnij się, że dodałeś go do agenta SSH.

Na hoście KVM potrzebne są również różne narzędzia w przestrzeni użytkownika (Ansible zainstaluje je na wspieranych hostach).

qemu-img
osinfo-query
virsh
virt-customize
virt-sysprep

Pobierz obrazy gości, które chcesz używać (tutaj jest to, co pobrałem) i umieść je w ścieżce obrazów libvirt (zwykle /var/lib/libvirt/images/). Sprawdzi to, czy określone obrazy istnieją i zgłosi błąd, jeśli nie zostaną znalezione.

Host KVM

Oto kilka instrukcji dotyczących konfiguracji hosta KVM, na wypadek, gdyby były przydatne.

UWAGA: Ta rola zrobi to wszystko za Ciebie, w tym zainstaluje KVM, libvirtd i inne wymagane pakiety na wspieranych dystrybucjach, a także upewni się, że libvirtd jest uruchomiony.

Istnieje również zmienna virt_infra_host_pkgs_custom, która przejmuje listę pakietów do zainstalowania na hoście, jeśli potrzebujesz, aby rola zainstalowała dla Ciebie dodatkowe pakiety.

Zauważ, że zmienna musi być listą, a host musi być w stanie zainstalować pakiety, tzn. nazwy pakietów muszą być poprawne dla hosta, a jeśli host działa na RHEL, musi być zarejestrowany.

Fedora

# Utwórz klucz SSH, jeśli go nie masz (nie ustawiaj hasła, jeśli zdalny host KVM)
ssh-keygen

# libvirtd
sudo dnf install -y @virtualization
sudo systemctl enable --now libvirtd

# Ansible
sudo dnf install -y ansible

# Inne zależności (zainstalowane przez playbook)
sudo dnf install -y \
git \
genisoimage \
libguestfs-tools-c \
libosinfo \
python3-libvirt \
python3-lxml \
qemu-img \
virt-install

CentOS 7

CentOS 7 nie zadziała, dopóki nie zainstalujemy pakietu libselinux-python3, który zadebiutuje w wersji 7.8...

Ale oto (mam nadzieję) reszta kroków, kiedy będzie dostępna.

# Utwórz klucz SSH, jeśli go nie masz
ssh-keygen

# libvirtd
sudo yum groupinstall -y "Virtualization Host"
sudo systemctl enable --now libvirtd

# Ansible i inne zależności
sudo yum install -y epel-release
sudo yum install -y python36
pip3 install --user ansible

sudo yum install -y \
git \
genisoimage \
libguestfs-tools-c \
libosinfo \
python36-libvirt \
python36-lxml \
libselinux-python3 \
qemu-img \
virt-install

CentOS Stream 8

# Utwórz klucz SSH, jeśli go nie masz
ssh-keygen

# libvirtd
sudo dnf groupinstall -y "Virtualization Host"
sudo systemctl enable --now libvirtd

# Ansible
sudo dnf install -y epel-release
sudo dnf install -y ansible

# Inne zależności (zainstalowane przez playbook)
sudo dnf install -y \
git \
genisoimage \
libguestfs-tools-c \
libosinfo \
python3 \
python3-libvirt \
python3-lxml \
qemu-img \
virt-install

Debian

# Utwórz klucz SSH, jeśli go nie masz
ssh-keygen

# libvirtd
sudo apt update
sudo apt install -y --no-install-recommends qemu-kvm libvirt-clients libvirt-daemon-system
sudo systemctl enable --now libvirtd

# Ansible
sudo apt install -y gnupg2
echo 'deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main' | sudo tee -a /etc/apt/sources.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
sudo apt update
sudo apt install -y ansible

# Inne zależności (zainstalowane przez playbook)
sudo apt install -y --no-install-recommends \
cloud-image-utils \
dnsmasq \
git \
genisoimage \
libguestfs-tools \
libosinfo-bin \
python3-libvirt \
python3-lxml \
qemu-utils \
virtinst

Ubuntu

# Utwórz klucz SSH, jeśli go nie masz
ssh-keygen

# libvirtd
sudo apt update
sudo apt install -y --no-install-recommends libvirt-clients libvirt-daemon-system qemu-kvm
sudo systemctl enable --now libvirtd

# Ansible
sudo apt install -y software-properties-common
sudo apt-add-repository --yes --update ppa:ansible/ansible
sudo apt install -y ansible

# Inne zależności (zainstalowane przez playbook)
sudo apt install -y --no-install-recommends \
dnsmasq \
git \
genisoimage \
libguestfs-tools \
libosinfo-bin \
python3-libvirt \
python3-lxml \
qemu-utils \
virtinst

openSUSE

Jeśli używasz JeOS, musimy zmienić jądro na kernel-default, ponieważ kernel-default-base, który comes z JeOS, nie ma modułów KVM.

# Utwórz klucz SSH, jeśli go nie masz
ssh-keygen

# Zainstaluj odpowiednie jądro
sudo zypper install kernel-default
sudo reboot

Kontynuuj po ponownym uruchomieniu.

# libvirtd
sudo zypper install -yt pattern kvm_server kvm_tools
sudo systemctl enable --now libvirtd

# Ansible
sudo zypper install -y ansible

# Inne zależności (zainstalowane przez playbook)
sudo zypper install -y \
git \
guestfs-tools \
libosinfo \
mkisofs \
python3-libvirt-python \
python3-lxml \
qemu-tools \
virt-install

Używanie sieci routowanych

Możesz skierować ruch do nowo utworzonego mostka, określając typ forward route. Ten kod obsługuje automatyczne tworzenie nowego mostka o nazwie bridge_dev, który będzie podłączony do istniejącego interfejsu w hoście, określonego przez parametr host_dev.

Poniższy przykład pokazuje, jak można utworzyć mostek, wspierający zarówno IPv4, jak i IPv6:

kvmhost:
  hosts:
    localhost:
      ansible_connection: local
      ansible_python_interpreter: /usr/bin/python3
      virt_infra_host_libvirt_url: qemu:///system
  vars:
    virt_infra_host_networks:
      present:
        - name: example
          domain: f901.example.com
          type: route
          host_dev: eth0
          bridge_dev: virbr1
          bridge_stp: on
          bridge_delay: 0
          mac: 52:54:00:f9:01:00
          ip_address: 10.249.1.1
          ip_netmask: 255.255.255.0
          dhcp_start: 10.249.1.11
          dhcp_end: 10.249.1.254
          ip6_address: 2001:0db8::f901:1
          ip6_prefix: 64
          dhcp6_start: 2001:0db8::f901:0000
          dhcp6_end: 2001:0db8::f901:00ff

Uwagi:

Blok IPv6 2001:0db8/32, jak pokazano powyżej, jest podany tylko w celach dokumentacyjnych. Będziesz musiał go zastąpić własnym przydzielonym blokiem /48 (ogólnie) przydzielonym przez Twojego dostawcę IPv6 lub przez rozwiązanie tunelowania IPv6 przez IPv4, takie jak usługa brokera tuneli Hurricane Electric.
Zdecydowanie zaleca się pozostanie przy ip6_prefix: 64, ponieważ jest to zalecane ustawienie w dokumentacji libvirt.

Konfiguracja mostków z NetworkManagerem

Ten kod umożliwia łączenie VM z mostkami Linux i Open vSwitch, ale muszą one już istnieć na hoście KVM.

Oto, jak przekształcić istniejące urządzenie ethernetowe w mostek. Bądź ostrożny, jeśli robisz to na zdalnej maszynie z tylko jednym połączeniem! Upewnij się, że masz inny sposób logowania (np. konsolę) lub może dodaj dodatkowe interfejsy.

Najpierw eksportujemy urządzenie, które chcesz przekształcić, aby móc łatwo do niego później się odwołać (np. eth1).

export NET_DEV="eth1"

Teraz wylistuj aktualne połączenia NetworkManager dla swojego urządzenia, aby wiedzieć, co później wyłączyć.

sudo nmcli con |egrep -w "${NET_DEV}"

Może to być coś w stylu System eth1 lub Wired connection 1, eksportujemy to także dla późniejszego odniesienia.

export NM_NAME="Wired connection 1"

Mostek Linux

Oto przykład tworzenia trwałego mostka Linux z NetworkManagerem. Weź urządzenie takie jak eth1 (zastąp je odpowiednio) i przekonwertuj je na mostek.

Pamiętaj nazwę istniejącego połączenia NetworkManager dla twojego urządzenia z powyższego etapu, będziesz używać jej poniżej (np. Wired connection 1).

export NET_DEV=eth1
export NM_NAME="Wired connection 1"
sudo nmcli con add ifname br0 type bridge con-name br0
sudo nmcli con add type bridge-slave ifname "${NET_DEV}" master br0

Teraz masz swoje urządzenie mostka! Zauważ, że mostek będzie miał inną adres MAC niż podstawowe urządzenie, więc jeśli oczekujesz, że dostanie konkretne adres, musisz zaktualizować swój statyczny dzierżawę DHCP.

sudo ip link show dev br0

Wyłącz aktualną konfigurację NetworkManager dla urządzenia, aby nie kolidowała z mostkiem (nie usuwaj jej jeszcze, możesz stracić połączenie, jeśli używasz go do SSH).

sudo nmcli con modify id "${NM_NAME}" ipv4.method disabled ipv6.method disabled

Teraz możesz po prostu zrestartować, lub zatrzymać bieżący interfejs i uruchomić mostek w jednym poleceniu. Pamiętaj, że mostek będzie miał nowy adres MAC, więc otrzyma nowy adres IP, chyba że zaktualizowałeś swoje statyczne dzierżawy DHCP!

sudo nmcli con down "${NM_NAME}" ; sudo nmcli con up br0

Jak już wspomniano, domyślnie mostek Linux uzyska adres przez DHCP. Jeśli nie chcesz, żeby był w sieci (może masz inny dedykowany interfejs) wyłącz DHCP na nim.

sudo nmcli con modify id br0 ipv4.method disabled ipv6.method disabled

Używanie mostka Linux w inwentarzu

Nie musisz nic robić po stronie kvmhost w inwentarzu.

Dla dowolnych gości, które chcesz połączyć z mostkiem, po prostu określ to w ich inwentarzu. Użyj br0 jako name sieci w virt_infra_networks z typem bridge.

      virt_infra_networks:
        - name: br0
          type: bridge

Mostek Open vSwitch (OVS)

Oto przykład tworzenia trwałego mostka OVS z NetworkManagerem. Weź urządzenie takie jak eth1 (zastąp je odpowiednio) i przekonwertuj je na mostek ovs.

Będziesz potrzebować zainstalowanego openvswitch oraz pluginu NetworkManagera OVS (podstaw w zależności od swojej dystrybucji).

sudo dnf install -y NetworkManager-ovs openvswitch
sudo systemctl enable --now openvswitch
sudo systemctl restart NetworkManager

Teraz możemy stworzyć mostek OVS (zakładając, że Twoje urządzenie to eth1, a istniejąca konfiguracja NetworkManager to Wired connection 1, podstaw w odpowiednich miejscach).

export NET_DEV=eth1
export NM_NAME="Wired connection 1"
sudo nmcli con add type ovs-bridge conn.interface ovs-bridge con-name ovs-bridge
sudo nmcli con add type ovs-port conn.interface port-ovs-bridge master ovs-bridge
sudo nmcli con add type ovs-interface slave-type ovs-port conn.interface ovs-bridge master port-ovs-bridge
sudo nmcli con add type ovs-port conn.interface ovs-port-eth master ovs-bridge con-name ovs-port-eth
sudo nmcli con add type ethernet conn.interface "${NET_DEV}" master ovs-port-eth con-name ovs-int-eth

Wyłącz aktualną konfigurację NetworkManager dla urządzenia, aby nie kolidowała z mostkiem (nie usuwaj jej jeszcze, możesz stracić połączenie, jeśli używasz go do SSH).

sudo nmcli con modify id "${NM_NAME}" ipv4.method disabled ipv6.method disabled

Teraz możesz po prostu zrestartować, albo zatrzymać aktualny interfejs i uruchomić mostek w jednym poleceniu.

sudo nmcli con down "${NM_NAME}" ; sudo nmcli con up ovs-slave-ovs-bridge

Domyślnie mostek OVS uzyska adres przez DHCP. Jeśli nie chcesz, by był w sieci (możesz mieć inny dedykowany interfejs) wyłącz DHCP na nim.

sudo nmcli con modify id ovs-slave-ovs-bridge ipv4.method disabled ipv6.method disabled

Pokaż konfigurację przełącznika i mostka przy użyciu narzędzi OVS.

sudo ovs-vsctl show

Używanie mostka ovs w inwentarzu

Teraz możesz użyć ovs-bridge jako device mostka ovs w sekcji inwentarza twojego kvmhost virt_infra_host_networks i to utworzy sieci libvirt OVS dla Ciebie. Możesz ustawić wiele VLANów i ustawić jeden jako domyślny natywny (jeśli zajdzie taka potrzeba).

Zakresy VLAN są obsługiwane przez zdefiniowanie jako listy.

      virt_infra_host_networks:
        present:
          - name: ovs-bridge
            bridge_dev: ovs-bridge
            type: ovs
            portgroup:
              # To jest portgroup z wieloma VLANami
              # Jest natywny VLAN 1 i również pozwala na ruch oznaczony VLAN 99
              - name: ovs-trunk
                trunk: true
                native_vlan: 1
                vlan:
                  - 1
                  - [20,29]
                  - 99
              # To jest portgroup tylko dla natywnego VLAN 1
              - name: default
                native_vlan: 1
                vlan:
                  - 1
              # To jest portgroup tylko dla natywnego VLAN 99
              - name: other
                native_vlan: 99
                vlan:
                  - 99

Możesz wtedy określić swoje VM, aby znajdowały się w konkretnych portgroupach, a libvirt automatycznie ustawi porty dla Twoich VM.

      virt_infra_networks:
        - name: ovs-bridge
          portgroup: default
          type: ovs

Gdy Twoje VM będą uruchomione, możesz zobaczyć ich porty OVS za pomocą sudo ovs-vsctl show.

Obrazy chmur gości

Ta rola jest zaprojektowana do używania standardowych obrazów chmur dostarczanych przez różne dystrybucje (OpenStack zawiera kilka sugerowanych).

Upewnij się, że obraz, który określasz dla swoich gości, już istnieje w katalogu pamięci libvirt (domyślnie jest to /var/lib/libvirt/images/).

Testowałem pomyślnie następujące obrazy gości:

Aby skonfigurować gościa i uzyskać jego IP, obydwa cloud-init i qemu-guest-agent zostaną zainstalowane w obrazie Twojego gościa, na wszelki wypadek.

Można to zmienić lub nadpisać za pomocą zmiennej virt_infra_guest_deps, która jest listą.

System nie będący w przygotowaniu również działa na obrazie gościa, aby zapewnić, że jest czysty, np. burzenie starych adresów MAC.

Zmienne roli

Domyślne wartości roli są ustawione w pliku defaults/main.yml.

Mogą być nadpisywane na poziomie hostu lub grupy hostów, w razie potrzeby. Jednak rola została zaprojektowana tak, aby działała praktycznie od razu (o ile masz domyślny obraz CentOS Stream 8).

---
# Domyślne wartości dla roli virt-infra Ansible
# Wartości skomentowane są opcjonalne

## Związane z gośćmi

# Ważne stany gości to: uruchomiony, zamknięty, usunięty lub niezdefiniowany
virt_infra_state: "running"

# Goście nie są uruchamiani automatycznie przy starcie
virt_infra_autostart: "no"

# Użytkownik gościa, domyślnie ustawiany na tego samego użytkownika co użytkownik hosta KVM
virt_infra_user: "{{ hostvars[kvmhost].ansible_env.USER }}"

# Hasło domyślnego użytkownika (rozważ użycie skarbca, jeśli potrzebujesz zabezpieczonych haseł)
# Bez hasła roota domyślnie
virt_infra_password: "password"
#virt_infra_root_password:

# Specyfikacje VM dla gości
# Zobacz stronę man dla virt-install dla wspieranych wartości
virt_infra_ram: "1024"
virt_infra_ram_max: "{{ virt_infra_ram }}"
virt_infra_cpus: "1"
virt_infra_cpus_max: "{{ virt_infra_cpus }}"
virt_infra_cpu_model: "host-passthrough"
virt_infra_machine_type: "q35"

# Klucze SSH są listą, możesz dodać więcej niż jeden
# Jeśli nie określono, domyślnie przyjmowane są wszystkie klucze publiczne na hoście KVM
virt_infra_ssh_keys: []

# Jeśli nie określono lub nie znaleziono kluczy SSH na hoście KVM, tworzymy jeden z tym
virt_infra_ssh_key_size: "2048"
virt_infra_ssh_key_type: "rsa"

# Czy włączyć SSH z hasłem
virt_infra_ssh_pwauth: true

# Czy używać cloud-init do konfigurowania sieci na hoście
virt_infra_network_config: false

# Sieci są listą, można dodać więcej niż jedną
# "typ" jest opcjonalny, zarówno "nat" jak i "bridge" są wspierane
#  - "nat" to domyślny typ i powinien być siecią libvirt
#  - "bridge" wymaga, aby interfejs mostka był nazwą (np. nazwa: "br0"), który również musi być już skonfigurowany na hoście KVM
# "model" jest również opcjonalny
virt_infra_networks:
  - name: "default"
    type: "nat"
    model: "virtio"

# Dyski, wspierają różne opcje libvirt
# Generalnie ich nie ustawiamy i zostawiamy je domyślnym hyperwizora
# Zobacz stronę man dla virt-install dla wspieranych wartości
virt_infra_disk_size: "20"
virt_infra_disk_bus: "scsi"
virt_infra_disk_io: "threads"
virt_infra_disk_cache: "writeback"

# Dyski są listą, można dodać więcej niż jeden
# Jeśli nadpisujesz to, musisz nadal uwzględnić urządzenie 'boot' jako pierwsze w liście
# Tylko 'name' jest wymagane, inne są opcjonalne (domyślny rozmiar to 20GB)
# Wszyscy goście wymagają przynajmniej napędu startowego (co jest domyślne)
virt_infra_disks:
  - name: "boot"
    size: "{{ virt_infra_disk_size }}"
    bus: "{{ virt_infra_disk_bus }}"
#   io: "{{ virt_infra_disk_io }}"
#   cache: "{{ virt_infra_disk_cache }}"

# Domyślną dystrybucją jest CentOS Stream 8, nadpisz w gościach lub grupach
virt_infra_distro_image: "CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2"

# Określ wspierane warianty na hoście KVM komendą "osinfo-query os"
# To naprawdę nie ma dużego znaczenia dla gościa, może być nieznacznie inny bus
# Możesz to spokojnie ustawić jako "centos7.0" dla wszystkich dystrybucji, jeśli chcesz
#virt_infra_variant: "centos7.0"

# Te zmienne dystrybucji są tutaj dla odniesienia i wygody
virt_infra_distro: "centos-stream"
virt_infra_distro_release: "8"
virt_infra_distro_image_url: "https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2"
virt_infra_distro_image_checksum_url: "https://cloud.centos.org/centos/8-stream/x86_64/images/CHECKSUM"

## Związane z hostem KVM

# Połącz się z systemowym instancjami libvirt
virt_infra_host_libvirt_url: "qemu:///system"

# Ścieżka, w której przechowywane są obrazy dysków
virt_infra_host_image_path: "/var/lib/libvirt/images"

# Domyślnie wyłącz zabezpieczenia qemu
# To jest nadpisywane w zmiennych specyficznych dla dystrybucji
virt_infra_security_driver: "none"

# Wirtualne BMC jest domyślnie wyłączone
virt_infra_vbmc: false

# Domyślnie instalujemy przy użyciu pip, ale jeśli wolisz robić to ręcznie, ustaw to na false
virt_infra_vbmc_pip: true

# Domyślna usługa vbmc, nadpisz, jeśli coś innego w Twojej dystrybucji
virt_infra_vbmc_service: vbmcd

# Sieci na kvmhost są listą, możesz dodać więcej niż jedną
# Możesz tworzyć i usuwać sieci NAT na kvmhost (tworzenie mostków nie jest wspierane)
# "default" jest standardową siecią dostarczaną z libvirt
# Domyślnie nie usuwamy żadnych sieci (pusta lista absent)
virt_infra_host_networks:
  absent: []
  present:
    - name: "default"
      type: "nat"
      ip_address: "192.168.122.1"
      subnet: "255.255.255.0"
      dhcp_start: "192.168.122.2"
      dhcp_end: "192.168.122.254"

# Komenda do tworzenia obrazów ISO
virt_infra_mkiso_cmd: genisoimage

# Lista binariów do sprawdzenia na hoście KVM
virt_infra_host_deps:
  - qemu-img
  - osinfo-query
  - virsh
  - virt-customize
  - virt-sysprep

# Lista pakietów do zainstalowania na dyskach gości
virt_infra_guest_deps:
  - cloud-init
  - qemu-guest-agent

Zależności

Brak

Przykładowy inwentarz

Oddzielne repozytorium virt-infra ma przykładowe pliki inwentarza oraz playbook, który wywołuje rolę, co może być pomocne.

Najlepiej byłoby, aby inwentarze były rozdzielone na wiele plików dla łatwiejszego zarządzania, w katalogu inventory lub podobnym. Sugeruję wspólny kvmhost.yml a następnie oddzielne pliki inwentarza dla każdej grupy gości, np. openstack.yml. Podczas uruchamiania ansible, dołącz cały katalog jako źródło inwentarza.

Inwentarz używany z tą rolą musi zawierać grupę hostów o nazwie kvmhost oraz inne grupy hostów dla gości.

Dostosowane ustawienia można dostarczyć dla każdego hosta lub grupy hostów w inwentarzu.

Aby utworzyć nową grupę gości do zarządzania, utwórz nowy plik yml w katalogu inwentarza. Na przykład, jeśli chciałeś zestaw gości dla OpenStack, możesz stworzyć plik openstack.yml i wypełnić go według potrzeb.

Aby zarządzać konkretnymi hostami lub grupami, po prostu użyj opcji --limit Ansible, aby określić hosty lub grupy hostów (musisz też uwzględnić grupę kvmhost). W ten sposób możesz użyć jednego inwentarza dla wielu różnych gości i zarządzać nimi osobno.

Host KVM to miejsce, gdzie tworzone są sieci libvirt i dlatego określane są jako zmienne w tej grupie hostów.

Oto przykładowy plik inwentarza kvmhost.yml w formacie YAML. Określa kvmhost jako localhost z lokalnym połączeniem. Uwaga, że tworzone są dwie sieci (default i example) oraz jedna, która jest usuwana (other).

---
## Inwentarz oparty na YAML, zobacz:
## https://docs.ansible.com/ansible/latest/plugins/inventory/yaml.html
#
kvmhost:
  hosts:
    # Umieść tutaj swoje połączenie i ustawienia hosta KVM
    localhost:
      ansible_connection: local
      ansible_python_interpreter: /usr/bin/python3
  vars:
    # Sieci są listą, możesz dodać więcej niż jedną
    # Możesz tworzyć i usuwać sieci NAT na kvmhost (tworzenie mostków nie jest wspierane)
    # "default" jest standardową siecią dostarczaną z libvirt
    # Domyślnie nie usuwamy żadnych sieci (pusta lista absent)
    virt_infra_host_networks:
      absent:
        - name: "other"
      present:
        - name: "default"
          ip_address: "192.168.112.1"
          subnet: "255.255.255.0"
          dhcp_start: "192.168.112.2"
          dhcp_end: "192.168.112.254"
        - name: "example"
          ip_address: "192.168.113.1"
          subnet: "255.255.255.0"
          dhcp_start: "192.168.113.2"
          dhcp_end: "192.168.113.99"

Oto przykładowy inwentarz gościa o nazwie simple.yml, który definiuje gości CentOS Stream 8 w grupie o nazwie simple, korzystając z domyślnych ustawień roli.

---
## Inwentarz oparty na YAML, zobacz:
## https://docs.ansible.com/ansible/latest/plugins/inventory/yaml.html
#
simple:
  hosts:
    centos-simple-[0:2]:
      ansible_python_interpreter: /usr/libexec/platform-python

Jeśli chcesz, aby zestaw VM był taki sam, ustaw zmienne na poziomie grupy hostów. Możesz wciąż nadpisać zmienne grupy hostów specyficznymi zmiennymi dla poszczególnych hostów, jeśli zajdzie taka potrzeba.

Oto przykład ustawiający różne zmienne grup hostów oraz indywidualnych hostów.

---
## Inwentarz oparty na YAML, zobacz:
## https://docs.ansible.com/ansible/latest/plugins/inventory/yaml.html
#
example:
  hosts:
    centos-7-example:
      virt_infra_state: shutdown
      virt_infra_timezone: "Australia/Melbourne"
      ansible_python_interpreter: /usr/bin/python
      virt_infra_networks:
        - name: "br0"
          type: bridge
        - name: "extra_network"
          type: nat
          model: e1000
        - name: ovs-bridge
          portgroup: ovs-portgroup
          type: ovs
      virt_infra_disks:
        - name: "boot"
        - name: "nvme"
          size: "100"
          bus: "nvme"
    centos-8-example:
      virt_infra_timezone: "Australia/Adelaide"
      ansible_python_interpreter: /usr/libexec/platform-python
    opensuse-15-example:
      virt_infra_distro: opensuse
      virt_infra_distro_image: openSUSE-Leap-15.1-JeOS.x86_64-15.1.0-OpenStack-Cloud-Current.qcow2
      virt_infra_variant: opensuse15.1
      virt_infra_disks:
        - name: "boot"
          bus: "scsi"
    ubuntu-eoan-example:
      virt_infra_cpu: 2
      virt_infra_distro: ubuntu
      virt_infra_distro_image: eoan-server-cloudimg-amd64.img
      virt_infra_variant: ubuntu18.04
  vars:
    virt_infra_ram: 1024
    virt_infra_disks:
      - name: "boot"
      - name: "data"
        bus: "sata"
    virt_infra_networks:
      - name: "example"
        type: nat

Wielu hostów KVM

Możesz również określić wiele hostów KVM.

---
kvmhost:
  hosts:
    kvmhost1:
    kvmhost2:
    kvmhost3:
  vars:
    ansible_python_interpreter: /usr/bin/python3
    virt_infra_host_networks:
      absent: []
      present:
        - name: "default"
          ip_address: "192.168.112.1"
          subnet: "255.255.255.0"
          dhcp_start: "192.168.112.2"
          dhcp_end: "192.168.112.254"

Aby VM trafiły na konkretny host KVM, musisz dodać zmienną kvmhost z ciągiem, który odpowiada hostowi KVM z grupy kvmhost.

Na przykład, sześć gości CentOS Stream 8 na trzech hostach KVM:

---
simple:
  hosts:
    simple-centos-[1:2]:
      kvmhost: kvmhost1
    simple-centos-[3:4]:
      kvmhost: kvmhost2
    simple-centos-[5:6]:
      kvmhost: kvmhost3
  vars:
    ansible_python_interpreter: /usr/libexec/platform-python
    virt_infra_distro_image: "CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2"

Jeśli dla VM nie określono kvmhost, domyślnie trafią na pierwszy host KVM w grupie kvmhost (tzn. kvmhost[0]), co odpowiada oryginalnemu zachowaniu roli.

Sprawdzanie walidacji zostało zaktualizowane w celu upewnienia się, że wszystkie hosty KVM są ważne oraz że wszelkie określone hosty KVM dla VM znajdują się w grupie kvmhost.

Aby grupować VM na konkretnych hostach KVM, rozważ utworzenie grup podrzędnych i określenie kvmhost na poziomie grupy podrzędnej.

Na przykład, te goście CentOS Stream 8 ponownie:

---
simple:
  hosts:
    simple-centos-[1:6]:
  vars:
    ansible_python_interpreter: /usr/libexec/platform-python
    virt_infra_distro_image: "CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2"
  children:
    simple_kvmhost1:
      hosts:
        simple-centos-[1:2]:
      vars:
        kvmhost: kvmhost1
    simple_kvmhost2:
      hosts:
        simple-centos-[3:4]:
      vars:
        kvmhost: kvmhost2
    simple_kvmhost3:
      hosts:
        simple-centos-[5:6]:
      vars:
        kvmhost: kvmhost3

Przykładowy playbook

Starałem się, aby Ansible był prostą, logiczną serią kroków i nie był zbyt skomplikowany. Mówiąc to, playbook jest dosyć szczegółowy.

Są pewne zadania, które mogą być uruchamiane tylko na hoście KVM i inne w określonej kolejności.

Ten kod pomoże poprzez uruchomienie wielu sprawdzeń walidacyjnych na hoście KVM oraz dla konfiguracji Twoich gości, aby spróbować znaleźć wszystko, co nie jest w porządku.

Oto przykładowy playbook virt-infra.yml, który wywołuje rolę.

---
- hosts: all
  gather_facts: no
  roles:
    - ansible-role-virt-infra

Pobierz obraz chmury

Zanim uruchomimy playbook, pobierz obraz chmury CentOS Stream 8.

curl -O https://cloud.centos.org/centos/8/x86_64/images/CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2
sudo mv -iv CentOS-Stream-GenericCloud-8-20210603.0.x86_64.qcow2 /var/lib/libvirt/images/

Uruchom playbook

Teraz uruchom playbook Ansible przeciwko kvmhost oraz gości w grupie simple, używając powyższego inwentarza (uwaga, że ograniczamy do obu grup kvmhost i simple).

ansible-playbook \
--ask-become-pass \
--inventory ./inventory.d \
--limit kvmhost,simple \
./virt-infra.yml

Możesz również nadpisać wiele ustawień gości w wierszu poleceń.

ansible-playbook \
--ask-become-pass \
--limit kvmhost,simple \
./virt-infra.yml \
-e virt_infra_root_password=password \
-e virt_infra_disk_size=100 \
-e virt_infra_ram=4096 \
-e virt_infra_ram_max=8192 \
-e virt_infra_cpus=8 \
-e virt_infra_cpus_max=16 \
-e '{ "virt_infra_networks": [{ "name": "br0", "type": "bridge" }] }' \
-e virt_infra_state=running

Czyszczenie

Aby usunąć gości w grupie hostów, możesz je określić (lub konkretny host) za pomocą --limit i przekazać virt_infra_state=undefined jako dodatkowy argument wiersza poleceń.

To nadpisze stan gościa jako niezdefinowany, a jeśli istnieją, zostaną usunięte.

Na przykład, aby usunąć wszystkie VM w grupie simple.

ansible-playbook \
--ask-become-pass \
--inventory simple.yml \
--limit kvmhost,simple \
--extra-vars virt_infra_state=undefined \
./virt-infra.yml

Jeśli chcesz tylko je zamknąć, spróbuj virt_infra_state=shutdown zamiast.

Na przykład, aby wyłączyć tylko host simple-centos-2.

ansible-playbook \
--ask-become-pass \
--inventory simple.yml \
--limit kvmhost,simple-centos-2 \
--extra-vars virt_infra_state=shutdown \
./virt-infra.yml

Konfiguracja po ustawieniu

Po skonfigurowaniu infrastruktury, możesz uruchomić inny playbook przeciwko tej samej inwentarze do wykonania, czegokolwiek chcesz z tymi maszynami...

---
- hosts: all,!kvmhost
  tasks:
    - name: Aktualizuj wszystkie pakiety
      package:
        name: '*'
        state: latest
      become: true
      register: result_package_update
      retries: 30
      delay: 10
      until: result_package_update is succeeded

    - name: Zainstaluj pakiety
      package:
        name:
          - git
          - tmux
          - vim
        state: present
      become: true
      register: result_package_install
      retries: 30
      delay: 10
      until: result_package_install is succeeded