Photon OS - od VMware vSphere po kontenery, Dockera i Pi‑hole

W ostatnim czasie miałem sporo przygód z z vCSA vCenter, który jako system operacyjny wykorzystuje autorskie rozwiązanie VMware - Photon OS. Sam wpis miał być krótki... nagle zrobił się z tego duży, rozwodniony wyrzut myśli o o wirtualizacji, konteneryzacji, historii vSphere (...). No ale zdecydowałem nie dzielić tego na kilka części.

VMware vCenter - by rządzić wszystkimi

vCenter to flagowy produkt VMware - jeden z podstawowych składników infrastruktury vSphere, służący do zarządzania wirtualizacją od tego producenta. W skrócie: samo oprogramowanie do wirtualizacji hiperwizorów typu pierwszego (zwanych też hipernadzorcami - uwielbiam to określenie) jest darmowe. Ma oczywiście pewne ograniczenia: do 8 vCPU na wirtualną maszynę, bez możliwości zarządzania centralnego. Później wchodzą licencje (które też ostatnio się zmieniły w zależności od ilości fizycznych corów/socketów). Licencje te różnią się i w zależności od potrzeb środowiska umożlliwiają wykorzystanie potencjału vSphere, tj. HA (High Availability), DRS i sDRS ((Storage) Distributed Resource Scheduler), vMotion, FT (Fault Tolerance), VDS (switchami dystrybucyjnymi), aktualizacjami. Po dodaniu odpowiednich licencji dodatkowymi funkcjami, jak np. elementy hiperkonwergencji (vSAN, HCX, NSX).

Wracając do vCenter - to centralny, najważniejszy punkt zarządzania infrastrukturą opartą o produkty VMware. Rozbudowany, skomplikowany skurczybyk, który potrafi dostarczyć geekowi IT zarówno ogromnej satysfakcji, jak i nerwów i dodatkowych pięciu lat doświadczenia w jeden weekend (jak sprawia problemy).

Oprogramowanie pojawiło się w pod koniec 2007 roku (wtedy jeszcze jako "VirtualCenter"), przez lata ewaluowało dając ogromne możliwości. Problemem było (a nawet jeszcze jest) natomiast to, co zarówno nie za bardzo to tolerowali sami administratorzy systemu, jak i wendor (VMware): zbyt mocne zależności od MS Windows. O tyle, o ile integracja z Active Directory to świetna sprawa przy zarządzaniu tożsamością, o tyle samo instalowanie vCenter na serwerach Windows na dłuższą metę przysparzało problemów:

• dodatkowe koszta licencjonowania,
• serwer bazy danych najlepiej na osobnej maszynie wirtualnej (zarządzenie MS SQLem na nim, kopia zapasowa),
• pilnowanie aktualizacji samego OS (gdzie niektóre łatki potrafiły uszkodzić uruchamianie i konfigurację serwisów vCenter),
• cykl życia OS w firmie (koniec wsparcia dla danej wersji Windows),
• rzeczy związane z technicznymi uwarunkowaniami w firmie - bezpieczeństwo Windows (specyficzne ustawienia, antywirusy, agenty monitoringu), którego ustawienia potrafią "przeszkadzać" w pracy dedykowanej aplikacji).

vCenter ma swoich serwisów sporo, zależnych od siebie, nie jest wcale skomplikowane "uceglić" go:

VMware chyba nigdy nie był wielkim fanem rozwiązania na Windowsie, szczególnie że wsparcie techniczne czasem było związane z rozwiązaniem problemów systemu operacyjnego a nie samego oprogramowania. Od wersji 5.0 vCenter pojawiła się więc opcja instalacji na vCSA (vCenter Server Appliance). Jest dostarczany w otwartym formacie OVA jako paczka do "prostej" instalacji - "prosta" instalacja specjalnie w cudzysłowie, ponieważ wymaga intalacji na ESX, sporych zasobów (w najnowszym 7.0 12GB RAM), oraz spełnionych innych wymagań (np. jest bardzo czuły nawet już przy samej instalacji na poprawną konfigurację DNSów, w tym rekordów PTR).  Sam appliance (vCSA) nie był bardzo popularny, powodów może być kilka: zarówno przyzwyczajenia do "starego" modelu bazującego na Windows, jak i może też ten drugi: administratorom VMware są najczęściej bliżej Windowsa, niż rozwiązań *nix. To się jednak zaczęło zmieniać pewnie gdzieś od wersji 6.0 - szczególnie jest to istotne teraz, gdzie vCenter 6.7 był ostatnim produktem umożliwiającą korzystanie "pod spodem" z Windows, 7.0 to już tylko VCSA.  Jak wspomniałem, OVF to taka "paczka" zawierająca prekonfigurowany dysk z systemem operacyjnym, oraz jak ją uruchamiać - między innymi ile przydzielić pamięci (vRAM), procesorów (vCPU), oraz ile kart sieciowych (vNIC). Na początku VMware używało zmodyfikowanego SUSE, gdzie były zaimplementowane wymagane komponenty, w tym podsystem bazy danych (Postgres). W międzyczasie pracowało nad własnym rozwiązaniem, które zarówno będzie ułatwiało zarządzanie vCSA, jak i da nowe możliwości przy zmieniającym się bardzo dynamicznie IT: otwarciem się na konteneryzację. Tak też powstał projekt Photon OS: w miarę lekki OS (Open Source) bazujący na jądrze Linux zoptymalizowanym pod bezpieczeństwo VMware, ze wsparciem "z pudełka" dla Dockera, frameworków typu Kubernetes, Mesos, oraz w miarę prostą aktualizacją. Dochodzą jeszcze nowe pomysły VMware jak "Photon Platform", o tym może kiedy indziej:

Sam Photon OS doczekał się obecnie stabilnej wersji 3.0. Od miesiąca jest też dostępna wersja 4.0 beta: wspominając już o wersji testowej poza kosmetyką w stylu jądra 5.9, czy nowszego glibc, doszło wsparcie dla Amazon AMI, Google GCE, Azure VHD: ale co najważniejsze, dla ARM64 (~100MB paczka dla Raspberry Pi). Jako już całkowita ciekawostka: ESXi można zainstalować na "malince":

Sam Photon OS w stabilnej wersji dostępny jest w kilku wersjach: skupiłem się na "minimalnej":

OVA jest dostarczane w wersji "sprzętowej" VMWare 11 (czyli min. ESX 6.0 / Workstation 11.x), lub dla UEFI HW 13 (ESX 6.5 / Workstation 14.x). Wymagania dla wersji "małej" to zalecane około 0.5GB miejsca na dysku i 2GB vRAM:

Po instalacji nie zabiera bardzo dużo zasobów:

Na co zwróciłem szczególnie uwagę przy instalacji OVA vs ISO: w wersji OVA domyślna instalacja daje dostęp do loogowania na konto root przez SSH:

Jest to może wygodne do szybkiego podłączenia się do wirtualnej maszyny z sieci, natomiast pod kątem bezpieczeństwa jest to rzecz bardzo dyskusyjna. Instalacja z ISO nie ma tej opcji jako domyślnej:

Instalacja PhotonOS

Jak wcześniej wspomniałem: instalacja jest możliwa z OVA, jak i z ISO - wersja "z pudełka" zostanie zainstalowana z domyślnym hasłem root 'changeme'. Spróbujmy jednak zainstalować z ISO. Po pobraniu odpowiedniego obrazu, należy utworzyć maszynę wirtualną. W przypadku VMware ESXi należy wybrać (jak jest taka możliwość) komatybliność z ESXi 6.7 (hardware 14), lub wyższym - w tej wersji pojawia się wsparcie (optymalizacja) dla Photon OS:

Warto przydzielić chociaż 2GB vRAM, dysk sugerowany to 16GB, natomiast przy instalacji 'thin' nie powinien zająć więcej, niż 1GB rzeczywistego miejsca.

Sama instalacja z ISO nie jest jakoś bardzo skomplkowana i raczej znana osobie, która kiedykolwiek miała styczność z systemem *nix - praktycznie sprowadza się do zatwierdzania domyślnych ustawień:

• wybór podziału na partycje (domyślnie pojedyncza partycja, bez wydzialania przestrzeni na plik wymiany (swap), czy katalogi domowe)

• wybór konfiguracji sieci - pozostawię domyślną (automatyczną): tak też jest przy instalacji z OVA domyślnie

• wybór jądra - wersja dla VMware jest zoptymalizowana własnie pod ten hiperwizor, oraz "obcięta" o elementy spowalniające system

• możliwa zmiana nazwy system ('hostname', z którego między innymi będzie się 'przedstawiał' do serwerów DNS)

System instaluje się bardzo szybko, przy dysku SSD nie powinno to zając więcej, niż 10‑20s:

Na koniec pozostaje kosmetyka: trochę dobrych praktyk, jak odpięcie pliku ISO, czy zrobienie snapshota, ponieważ zaraz będziemy trochę 'customizować' nasz system:

Podstawowe ustawienia systemu operacyjnego

System po instalacji pobiera sobie adres z serwera DHCP (jeżeli taki jest dostępny dla jego sieci), oraz jak widać alokuje bardzo mało zasobów: 40MB vRAM, homeopatyczne wartości procesora:

Po instalacji należy zalogować się (przez konsolę hiperwizora) loginem 'root' i ustalonym hasłem (jak już wspominałem: przy instalacji z OVF hasło to 'changme').

Instalacja z ISO nie zezwala na logowanie ssh root, więc można jak dobre praktyki nakazują utworzyć nowego użytkownika, logować się na niego i później dopiero wykonywać operacje z uprawnieniami administratora (su, sudo):

# utworzenie nowego użytkownika 'dpuser' wraz z katalogiem domowym
useradd -m dpuser

# nadanie hasła nowemu użytkownikowi 'dpuser'
passwd dpuser

To już zezwoli na podłączenie po ssh (domyślnie serwis sshd jest uruchomiony):

Druga opcja, dla leni takich jak ja, to zezwolenie na loogowanie 'root' (wtedy nie trzeba tworzyć 'dpuser'). Należy otworzyć plik konfiguracji sshd, odnaleźć linię 'PermitRootLogin No' i zastąpić 'Permit RootLogin Yes':

vi /etc/ssh/sshd_config

Hint dla Windowsowców: po przejściu do odowieniej linii nacisnąć "i" (insert), zastąpić odpowiedni fragment, następnie nacisnąć "Esc", oraz ":wq!" (write-quit). Operacja ta zapisze plik konfiguracji, został jkeszcze restart serwisu sshd, lub restart całego OS:

# restart serwera sshd:
systemctl restart sshd

# druga opcja to restart całego serwera
reboot

Jako że nie bardzo jestem fanem DHCP, ustalam statyczny adres IP. System "trzyma" konfigurację sieci w katalogu /etc/systemd/network/ gdzie pliki konfiguracji (im niższa pierwsza liczba, tym wyższy priorytet): obecny jest jedynie wpis dotyczący DHCP dla wszystkich interfejsów zaczynających się literą "e" (ethernetX):

Utwórzmy więc plik dla eth0: pierwsza opcja to za pomocą edytora 'vi':

# utworzenie pliku
touch /etc/systemd/network/10-static-en.network

# edycja nowej konfiguracji
vi /etc/systemd/network/10-static-en.network

Przykładowa treść:

[Match]
Name=eth0

[Network]
DHCP=no
Address=192.168.10.108/24
Gateway=192.168.10.1
DNS=192.168.10.111 192.168.10.112

Konfiguracja ta utworzy ustawienia dla intefejsu eth0, z IP 192.168.10.108, maskę 24‑bitową (255.255.255.0), bramę domyślną 192.168.10.1, oraz serwery DNS 192.168.10.111 i 192.168.10.112). Tu mała uwaga: jeżeli z jakiś powodów dodamy do maszyny wirtulanej dodatkowe interfejsy, to domyślnie skorzystają z serwera DHCP (plik konfiguracji 99‑dhcp-en.network). Następnie nadanie uprawnień dla startu i restart usługi sieciowej:

# nadanie uprawnienia do wykonywania przez demona networkd
chmod 644 /etc/systemd/network/10-static-en.network

#zrestartowanie demona sieciowego
systemctl restart systemd-networkd

Jeżeli operację wykonujemy będąc podłączeni zdalnie (ssh), zostaniemy rozłączeni - serwer otrzymał nowy adres IP.

Kopiując ten skrypt utworzymy to za pomocą jednej komendy:

cat > /etc/systemd/network/10-static-en.network << "EOF"
[Match]
Name=eth0

[Network]
DHCP=no
Address=192.168.10.108/24
Gateway=192.168.10.1
DNS=192.168.10.111 192.168.10.112
EOF

chmod 644 /etc/systemd/network/10-static-en.network
systemctl restart systemd-networkd

System jest gotowy do pracy.

Kontenery, dockery - świat IT się zmienia

Niektórym pewnie nie jest znany jest koncept wirtualizacji i konteneryzacji usług.

Ostatnie około 15 lat to przejście z serwerów fizycznych na wirtualne. Stary model zakładał, że fizyczny serwer miał zainstalowany system operacyjny, aplikację (jedną, lub kilka), odpowiednie biblioteki do jego uruchomienia. Wirtualizacja systemów operacyjnych dała nowe możliwości, w tym lepsze wykorzystanie zasobów serwerów (pamięci, procesorów, zasobów dyskowych), uproszczenie zarządzaniami nimi (np. kopie bezpieczeństwa), oraz ułatwione wsparcie dla systemów wysokodostępnych (HA, FT), czy zarządzanie DR i cyklem życia serwerów i ich aktualizacji (np. VMware technologie vMotion, replikacji):

Natomiast popularny obecnie model uruchamiania aplikacji wykorzystuje tzw. "kontenery". Jeszcze kilka lat temu była to ciekawostka, dzisiaj zaczyna być standardem i trzeba temu się przyglądać modelowi mikroserwisów, bo to jest przyszłość, szczególnie przy tak ogromnej popularności 'chmury'. Kontenery są proste do przenoszenia, nie mają zależności od danego środowiska, łatwiejsze zarządzanie aplikacją.

Należy pamiętać, że kontener to nie maszyna wirtualna. Zacytuję fragment komentarza z bloga Tomasza Jangasa, który nawiązuje do konferencji "Dockercon 2017":

Dla VMware temat konteneryzacji też jest obecnie bardzo ważny: w tym roku miala premiera vCenter 7, która poza wieloma zmianami ogromny nacisk miała na tajemniczo brzmiący "Project Pacific". Kontenery oczywiście można uruchamiać na systemach operacyjnych (np. Windows, czy bazujących na Linux) - zyskujemy dzięki temu odpowiednie wykorzystanie zasobów, licencji, zarządzanie mikroserwisami.

VMware pokazał w marcu tego roku wspomniany wyżej nowy vCenter, gdzie najważniejszy jest Tanzu (Kubernetes Grid Service), oferujący wsparcie dla Kubernetes, czyli orechstratora Dockera.

O VMware Tanzu, oraz porównanie trzech modeli uruchamiania aplikacji napiszę w najbliższym czasie.

Kontener uruchomiony na Photon OS

W Photon OS Docker jest domyślnie zainstalowany (wersja 19.03.10), jednak nie uruchomiony:

Dockera uruchomimy za pomocą polecenia 'systemctl start docker', natomiast automatyczne uruchamianie przy starcie systemu 'systemctl enable docker':

systemctl start docker
systemctl enable docker

O tyle, o ile zainstalowany jest sam Docker, brakuje orchestratora, którm zainstalujemy kontener 'Docker Compose'. Docker Compose to narzędzię znacząco ułatwiające pracę z kontenerami za pomocą za pomocą pliku konfiguracji YAML (.yml), który definuje poszczególne czynności i zależności w ustruktruralizowany sposób: np. w przypadku kontenera nazwę, porty jakie chcemy dla niego otworzyć itd.:

Instalacja sprowadza się do pobrania odpowiedniego builda: wg. dokumentacji jest to poniższa komenda:

sudo curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

Następnie możliwość wykonywania:

chmod +x /usr/local/bin/docker-compose

Po instalacji można sprawdzić, czy poprawnie pobrał się plik, oraz czy system ma do niego ścieżkę ('docker-compose --version'):

Photon OS bez problemu odnajduje, natomiast w innych systemach może być konieczne zrobienie linku symbolicznego do lokalizacji przeszukiwania:

ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

Pi-hole jako kontener

Za przykład może nam posłuszyć projekt "PiHole": projektu (aplikacji...), który służy w za serwer DNS, przy okazji starając się pracować jak aplikacja typu ADblocker - odsiewać zapytania do serwisów świadczących reklamy i inne niechciane treści (prosty "blacklisting"). Po instalacji wystarczy wskazać w urządzeniu korzystającym z internetu adres IP jako pierwszy serwer DNS. Z racji tego, że urządzeń sieciowych w domu potrafi być kilkanaście (laptopy, smartfony, odkurzacze, lodówki itd.), skonfigurowanie takiego rozwiązania może być wygodne (lub przy złym używaniu przeszkadzać, blokując niepotrzebnie niektóre usługi). Jak ktoś jest ciekawy jak to działa, odsyłam do do strony projektu (https://pi-hole.net). Rozwiązanie jest bardzo popularne wśród użytkowników Raspberry Pi, łącznie z rozbudową o wyświetlacz:

Utwórzmy projekt: najpierw nowy katalog, gdzie będziemy trzymać konfigurację naszego kontenera (docker-compose.yml):

mkdir pihole
touch docker-compose.yml

Przykładowy kontener będzie nazywać się 'pihole1':

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole1
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "80:80/tcp"
      - "443:443/tcp"
    environment:
      TZ: 'America/Chicago'
      # WEBPASSWORD: 'set a secure password here or it will be random'
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole/:/etc/pihole/'
      - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    # Recommended but not required (DHCP needs NET_ADMIN)
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    cap_add:
      - NET_ADMIN
    restart: unless-stopped

Spróbujmy, co nam z tego wyszło, czyli uruchomić kontener:

docker-compose up --detach

Composer najpierw sobie sprawdzi, że nie ma odpowiedniego obrazu (kontenera pihole), pobierze go sobie z githuba i następnie spróbuje uruchomić:

To mu się nie uda, ponieważ stwierdzi, że nie może użyć portu 53 (DNS), ponieważ "jest zajęty":

Co ciekawe, nie ma go w wykazie używanych portów:

netstat -tlpn

Winny jest jest temu serwis systemd lokalnego resolwera nazw (127.0.0.53). Wyłączmy go:

# zatrzymanie systemd-resolved
systemctl stop systemd-resolved

# wyłączenie automatycznego uruchamiania 
systemctl disable systemd-resolved.service

Spróbujmy jeszcze raz uruchomić nowy kontener:

docker-compose up --detach

Sprawdźmy, czy kontener działa:

Nasłuchuje na portach http/https, więc można sprawdzić, czy otwiera się interfejs (https://192.168.10.108):

Pozostaje nam jeszcze automatyczne uruchamianie kontenera wraz ze startem dockera: https://docs.docker.com/config/containers/start-containers-automatical...

Można też posłużyć się różnymi gotowymi skryptami, które nie wymagają pliku konfiguracji (.yml). Przykładowy plik:

#!/bin/bash

# https://github.com/pi-hole/docker-pi-hole/blob/master/README.md

PIHOLE_BASE="${PIHOLE_BASE:-$(pwd)}"
[[ -d "$PIHOLE_BASE" ]] || mkdir -p "$PIHOLE_BASE" || { echo "Couldn't create storage directory: $PIHOLE_BASE"; exit 1; }

# Note: ServerIP should be replaced with your external ip.
docker run -d \
    --name pihole \
    -p 53:53/tcp -p 53:53/udp \
    -p 80:80 \
    -p 443:443 \
    -e TZ="America/Chicago" \
    -v "${PIHOLE_BASE}/etc-pihole/:/etc/pihole/" \
    -v "${PIHOLE_BASE}/etc-dnsmasq.d/:/etc/dnsmasq.d/" \
    --dns=127.0.0.1 --dns=1.1.1.1 \
    --restart=unless-stopped \
    --hostname pi.hole \
    -e VIRTUAL_HOST="pi.hole" \
    -e PROXY_LOCATION="pi.hole" \
    -e ServerIP="127.0.0.1" \
    pihole/pihole:latest

printf 'Starting up pihole container '
for i in $(seq 1 20); do
    if [ "$(docker inspect -f "{{.State.Health.Status}}" pihole)" == "healthy" ] ; then
        printf ' OK'
        echo -e "\n$(docker logs pihole 2> /dev/null | grep 'password:') for your pi-hole: https://${IP}/admin/"
        exit 0
    else
        sleep 3
        printf '.'
    fi

    if [ $i -eq 20 ] ; then
        echo -e "\nTimed out waiting for Pi-hole start, consult your container logs for more info (\`docker logs pihole\`)"
        exit 1
    fi
done;

Dla osób znających Pihole może pojawić się pytanie: a co z intepreterem poleceń, który jest dostępny przy instalacji bez kontenera? Jest dostępne przekazywanie poleceń przez dockera:

Podsumowując, bo już sam pogubiłem się czego dotyczył ten wpis: uruchomiliśmy Pi‑Hole jako kontener na Photon OS uruchomionym na VMware ESXi.

W przyszłych wpisach postaram się mniej mieszać tematy, tj. napisać trochę o hiperkonwergencji (HCI), vSAN i rozwiązaniach pokrewnych (np. co oferuje Nutanix w tym temacie), oraz rozwiązaniach do infrastruktury hybrydowej, np. VMware HCX.

---------------------------------------------------------------- Linki:

Uruchomienie kontenera PiHole: https://github.com/pi-hole/docker-pi-hole/#running-pi-hole-docker

Dokumentacja Photon OS:

https://vmware.github.io/photon/assets/files/html/3.0/index.html

Dokumentacja Dockera: https://docs.docker.com https://docs.docker.com/compose/ https://docs.docker.com/engine/install/linux-postinstall/#configure-do...

Start / stop kontener:

https://phoenixnap.com/kb/how-to-list-start-stop-docker-containers

VMware:

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/prod... https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/prod...

https://blogs.vmware.com/vsphere/2020/03/vsphere-7-features.html

https://www.virten.net/vmware/vcenter-release-and-build-number-history/  https://vmware.github.io/photon/assets/files/photon-os-datasheet.pdf

-------------------------------------------------------------