In questa seconda parte del blog andremo ad insallare Openshift su oVirt. Questo è lo schema del laboratorio che andremo a creare:
Nella prima parte del blog abbiamo creato la virtual network per openshift, abbiamo creato le vm bastion.example.com e lb.example.com e copiato la chiave pubblica ssh della nostra utenza utilizzata nella workstation alle rispettive vm.
Per l’installazione di openshift utilizzeremo un playbook Ansible creato ad hoc che automatizza le fasi descritte nella guida ufficiale:
Siccome il playbook verrà lanciato dalla workstation e utilizzarà l’utente regolare ‘vale’, dobbiamo assicurarci di inserire in /etc/sudoers la possibilità per questo utente di effettuare l’escalation dei privilegi con ‘sudo’ senza richiedere la password. Sia nella vm bastion.example.com che nella vm lb.example.com assicuriamoci che l’utente ‘vale’ sia nel gruppo ‘wheel’:
#usermod -aG vale wheele che il file /etc/sudoers delle due vm contenga la seguente linea:
%wheel ALL=(ALL) NOPASSWD: ALLCome nome del cluster è stato scelto ‘myocp’ e come dominio il classico ‘example.com’
Creiamo le vm per accogliere openshift in questa configurazione:
3 nodi masters
3 nodi workers
1 nodo di bootstrap
Tutte queste vm devo essere collegate solo alla rete interna ‘openshift_net’ e devono utilizzare il PXE boot. Questo è l’esempio per la creazione della vm master-0
Nella descrizione del nome della vm usiamo pure il nome completo master-0.myocp.example.com
Questo è utile perchè oVirt ci permette di filtrare le vm tramite il nome, quindi nel nostro caso mettendo ‘example’ nella barra di ricerca ‘Vms’ vedremo solo tutte le vm di questo dominio
Anche qui scegliamo ‘Server’ per il campo ‘Optimized for’.
Come unico disco ho inserito 100Gb e scelto 20Gb di Ram e 4 Cpu
Assicuriamoci di selezionare PXE come boot options
Ripetiamo questa operazione per tutte le vm e prendiamo nota del MAC address assegnato ad ognuna. Il MAC address ci servirà più avanti.
Fatto questo possiamo finalmente iniziare la configurazione delle due vm bastion e lb.
Cloniamo la repo git da questo url:
https://git.extraordy.com/cloudnative/openshift-ansible-ovirt.git
Il playbook principale ‘connected_install.yaml’ racchiude tutte le fasi ed in più, a fine installazione, crea lo storage necessario per il registro interno di Openshift e un utenza ‘admin’ con i massimi privilegi.
Dalla guida ufficiale di installazione UPI possiamo ricavare questi macro-passaggi:
- Configurazione server dns (con record A,PRT per i nodi masters e workers, configurazione record SRV per il servizio etcd
- Configurazione server dhcp
- Configurazione PXE boot
- Configurazione load balancer
- Creazione dei file manifest di installazione
- Esecuzione del playbook
- Boot dei nodi
- Completamento installazione
Configurazione DHCP e DNS server
Questa è la parte in cui dobbiamo fare più attenzione. Per il laboratorio è stato scelto il servizio DNSMASQ per la sua semplicità di configurazione ma non è assolutamente da utilizzare in ambiti produttivi. DNSMASQ fornisce i servizi DHCP, DNS e di PXE boot.
Ad ogni nodo Openshift viene assegnato lo stesso hostname grazie a questo procedimento:
- Durante la fase di PXE boot ad ogni nodo verrà assegnato lo stesso indirizzo ip ricavato dal MAC address dal nostro server DHCP.
- Durante la fase di pre-installazione viene effettuato un reverse-lookup (interrogando il record PTR del server DNS)
- Il nodo riceve l’hostname collegato al suo indirizzo ip
La configurazione di DNSMASQ (verrà creata in automatico dal playbook) per il nostro laboratorio è la seguente:
## External dns ##
server=192.168.1.77
## External dns end ##
## LoadBalancer ##
address=/lb.myocp.example.com/172.17.1.2
dhcp-host=56:6f:9c:ac:00:04,172.17.1.2
## LoadBalancer end ##
## Required fqdn and wildcard for OCP ##
address=/api.myocp.example.com/172.17.1.2
address=/apps.myocp.example.com/172.17.1.2
address=/api-int.myocp.example.com/172.17.1.2
## Required fqdn and wildcard for OCP end ##
## Bootstrap ##
address=/bootstrap.myocp.example.com/172.17.1.3
ptr-record=3.1.17.172.in-addr.arpa,bootstrap.myocp.example.com
dhcp-host=56:6f:9c:ac:00:06,172.17.1.3
## Bootstrap end ##
## Masters ##
address=/master-0.myocp.example.com/172.17.1.9
ptr-record=9.1.17.172.in-addr.arpa,master-0.myocp.example.com
dhcp-host=56:6f:9c:ac:00:0a,172.17.1.9
address=/master-1.myocp.example.com/172.17.1.8
ptr-record=8.1.17.172.in-addr.arpa,master-1.myocp.example.com
dhcp-host=56:6f:9c:ac:00:0b,172.17.1.8
address=/master-2.myocp.example.com/172.17.1.7
ptr-record=7.1.17.172.in-addr.arpa,master-2.myocp.example.com
dhcp-host=56:6f:9c:ac:00:0c,172.17.1.7
## Masters end ##
## Etcd ##
address=/etcd-0.myocp.example.com/172.17.1.9
address=/etcd-1.myocp.example.com/172.17.1.8
address=/etcd-2.myocp.example.com/172.17.1.7
## Etcd end ##
## Workers ##
address=/worker-0.myocp.example.com/172.17.1.6
ptr-record=6.1.17.172.in-addr.arpa,worker-0.myocp.example.com
dhcp-host=56:6f:9c:ac:00:07,172.17.1.6
address=/worker-1.myocp.example.com/172.17.1.5
ptr-record=5.1.17.172.in-addr.arpa,worker-1.myocp.example.com
dhcp-host=56:6f:9c:ac:00:08,172.17.1.5
address=/worker-2.myocp.example.com/172.17.1.4
ptr-record=4.1.17.172.in-addr.arpa,worker-2.myocp.example.com
dhcp-host=56:6f:9c:ac:00:09,172.17.1.4
## SRV records for etcd service. Priority must be 0 and Weight must be 10 ###
srv-host=_etcd-server-ssl._tcp.myocp.example.com,etcd-0.myocp.example.com,2380,0,10
srv-host=_etcd-server-ssl._tcp.myocp.example.com,etcd-1.myocp.example.com,2380,0,10
srv-host=_etcd-server-ssl._tcp.myocp.example.com,etcd-2.myocp.example.com,2380,0,10
## SRV records end ##
## PXE ##
enable-tftp
tftp-root=/var/lib/tftpboot,ens4
dhcp-boot=pxelinux.0
## PXE end ##
## DHCP ##
dhcp-option=101,"Europe/Rome"
domain=example.com
no-dhcp-interface=ens3
interface=ens4
dhcp-option=option:netmask,255.255.255.0
dhcp-option=option:dns-server,172.17.1.1
dhcp-option=option:ntp-server,204.11.201.10
dhcp-range=ens4,172.17.1.2,172.17.1.50,12h
## DHCP end ##
Come si vede ogni indirizzo MAC è associato ad un indirizzo IP che a sua volta è associato sempre ad un determinato hostname.
Configurazione PXE boot
Openshift utilizza Red Hat CoreOS come sistema operativo (obbligatoriamente per i nodi masters).
Per approfondimenti: http://coreos.com/
I nodi vengono configurati grazie a file di configurazione chiamati ignition. Questi file di ignition vengono creati dall’installer di openshift ‘openshift-install’ il quale legge le configurazioni dal file ‘install-config.yaml’ che richiede l’editing manuale. E’ in questo file per esempio dove inseriamo il nome del dominio, del cluster, del pull secret (vedremo più avanti cos’è) e della nostra chiave pubblica ssh).
Siccome i file di ignition generati sono 3 (uno per configurare il nodo bootstrap, uno per configurare i nodi masters e uno per configurare i nodi workers) il menù del PXE boot deve presentare queste 3 scelte, più una per effettuare il boot da disco (scelta di default).
La configurazione del menu PXE boot per il laboratorio (anch’essa creata in automatico dal playbook) è la seguente:
UI menu.c32
DEFAULT LOCAL
PROMPT 0
TIMEOUT 200
ONTIMEOUT LOCAL
MENU TITLE PXE BOOT MENU
LABEL MASTER NODE
MENU LABEL ^1 MASTER
KERNEL rhcos/rhcos-4.3.8-x86_64-installer-kernel-x86_64
APPEND rd.neednet=1 initrd=rhcos/rhcos-4.3.8-x86_64-installer-initramfs.x86_64.img console=tty0 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.ignition_url=http://172.17.1.1/metal/master.ign coreos.inst.image_url=http://172.17.1.1/metal/rhcos-4.3.8-x86_64-metal.x86_64.raw.gz ip=dhcp
LABEL WORKER NODE
MENU LABEL ^2 WORKER
KERNEL rhcos/rhcos-4.3.8-x86_64-installer-kernel-x86_64
APPEND rd.neednet=1 initrd=rhcos/rhcos-4.3.8-x86_64-installer-initramfs.x86_64.img console=tty0 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.ignition_url=http://172.17.1.1/metal/worker.ign coreos.inst.image_url=http://172.17.1.1/metal/rhcos-4.3.8-x86_64-metal.x86_64.raw.gz ip=dhcp
LABEL BOOTSTRAP NODE
MENU LABEL ^3 BOOTSTRAP
KERNEL rhcos/rhcos-4.3.8-x86_64-installer-kernel-x86_64
APPEND rd.neednet=1 initrd=rhcos/rhcos-4.3.8-x86_64-installer-initramfs.x86_64.img console=tty0 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.ignition_url=http://172.17.1.1/metal/bootstrap.ign coreos.inst.image_url=http://172.17.1.1/metal/rhcos-4.3.8-x86_64-metal.x86_64.raw.gz ip=dhcp
LABEL LOCAL
MENU LABEL ^4 Boot from local disk
MENU DEFAULT
KERNEL /chain.c32
APPEND hd0 0
Utilizzando questa configurazione, quando effettuiamo il boot dei nodi, ci troveremo in questa situazione:
A seconda del ruolo del nodo andremo a scegliere il menù adeguato
Una volta scelto il tipo di boot, verranno scaricati dalla vm bastion i file di ignition di riferimento oltre che all’immagine di CoreOS, del kernel e dell’installer. Questi ultimi devono essere scaricati precedentemente dalle url ufficiali: i link li trovate nella guida Red Hat.
Per il laboratorio è stato scelto ngnix come web server per mettere a disposizione i file di ignition creati e l’immagine di CoreOS.
Configurazione load balancer
Come load balancer è stato scelto HAProxy.
La configurazione per il nostro lab è la seguente (viene mostrata solo la parte che ci interessa):
frontend openshift-api-server
bind *:6443
default_backend openshift-api-server
mode tcp
option tcplog
backend openshift-api-server
balance source
mode tcp
server master-0.myocp.example.com 172.17.1.9:6443 check
server master-1.myocp.example.com 172.17.1.8:6443 check
server master-2.myocp.example.com 172.17.1.7:6443 check
server bootstrap.myocp.example.com 172.17.1.3:6443 check
frontend machine-config-server
bind *:22623
default_backend machine-config-server
mode tcp
option tcplog
backend machine-config-server
balance source
mode tcp
server master-0.myocp.example.com 172.17.1.9:22623 check
server master-1.myocp.example.com 172.17.1.8:22623 check
server master-2.myocp.example.com 172.17.1.7:22623 check
server bootstrap.myocp.example.com 172.17.1.3:22623 check
frontend ingress-http
bind *:80
default_backend ingress-http
mode tcp
option tcplog
backend ingress-http
balance source
mode tcp
server worker-0.myocp.example.com 172.17.1.6:80 check
server worker-1.myocp.example.com 172.17.1.5:80 check
server worker-2.myocp.example.com 172.17.1.4:80 check
frontend ingress-https
bind *:443
default_backend ingress-https
mode tcp
option tcplog
backend ingress-https
balance source
mode tcp
server worker-0.myocp.example.com 172.17.1.6:443 check
server worker-1.myocp.example.com 172.17.1.5:443 check
server worker-2.myocp.example.com 172.17.1.4:443 check
Durante la fase di installazione il primo nodo configurato è il nodo di bootstrap. A fine installazione questa vm deve essere spenta e possiamo rimuovere i suoi riferimenti dalla configurazione di HAProxy.
Anche questa fase è automatizzata dal playbook.
Creazione dei file manifest di installazione
Abbiamo bisogno di un account gratuito Red Hat per poter scaricare il programma di generazione dei file ignition, del client ‘oc’ e del pull secret. Il Pull secret contiene le autorizzazioni necessarie per poter installare Openshift per un periodo di prova di 60 giorni.
Qui si trovano i passaggi da seguire:
Normalmente il pull secret lo inseriremo nel file install-config.yaml ma per utilizzare il playbook deve essere inserito nel file group_vars/all/vars.yaml
workspace_directory:
base_path: /home/vale/ocpInstallerFile
config_dir: config
networking:
internal_network: 172.17.1.0
internal_network_ip: 172.17.1.1
internal_network_netmask: 255.255.255.0
external_dns: 192.168.1.77
domain_name: example.com
dhcp:
timezone: "Europe/Rome"
start: 172.17.1.2
end: 172.17.1.50
ntp: 204.11.201.10
lb:
lb_internal_network_ip: 172.17.1.2
internal_interface_mac: "56:6f:9c:ac:00:04"
name: lb
cluster:
name: myocp
ocp_user: admin
ocp_pass: mypass
bootstrap:
- mac: "56:6f:9c:ac:00:06"
masters:
- mac: "56:6f:9c:ac:00:0a"
- mac: "56:6f:9c:ac:00:0b"
- mac: "56:6f:9c:ac:00:0c"
workers:
- mac: "56:6f:9c:ac:00:07"
- mac: "56:6f:9c:ac:00:08"
- mac: "56:6f:9c:ac:00:09"
pullSecret: '<my_pull_secret>'Come si vede in questo file andiamo a configurare tutto quello che ci serve:
Il nome del cluster, del dominio, gli indirizzi MAC dei nodi etc…
I dettagli dei file da scaricare vengono configurati invece nel file group_vars/all/downloads.yaml
skip_download: no
downloads:
ngnix_document_root: /usr/share/nginx/html
tftp_boot_root: /var/lib/tftpboot
tftp_workspace_dir: rhcos
nginix_workspace_dir: metal
utils:
base_url: https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/
ocp_oc_cli: openshift-client-linux.tar.gz
ocp_installer: openshift-install-linux.tar.gz
boot:
base_url: https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/latest/latest/
initramfs: rhcos-4.3.8-x86_64-installer-initramfs.x86_64.img
kernel: rhcos-4.3.8-x86_64-installer-kernel-x86_64
coreos: rhcos-4.3.8-x86_64-metal.x86_64.raw.gz
disconnected:
product_repo: 'openshift-release-dev'
release_name: 'ocp-release'
ocp_release: '4.3.0-x86_64'
local_repository: 'ocp4/openshift4'
local_secret_json: '/tmp/disconnected.json'
branch: 'ocp-v4.0-art-dev'Il dizionario ‘disconnected’ è per una versione futura del playbook che automatizzerà l’installazione di Openshift in un ambiente disconnesso da internet.
Esecuzione del playbook
Una volta configurato correttamente il file vars.yaml possiamo lanciare il playbook dalla nostra workstation. Il pacchetto python3-netaddr deve essere installato sulla workstation perchè Ansible ne utilizza alcune funzioni per i filtri.
Lanciamo il playbook ‘connected_install.yaml’ dalla nostra workstation:
$ansible-playbook connected_install.yamlla versione di ansible utilizzata è la ansible 2.9.6
Verranno configurati tutti i servizi sulla vm bastion e lb, configurati i relativi firewall, scaricati i file necessari e creati i file ignition. Durante l’ultima fase verrà richiesto di effettuare il boot dei nodi scegliendo il menù corretto.
La procedura richiede un tempo piuttosto lungo (per ogni nodo vengono scaricati circa 5Gb). Nel mio caso parliamo di circa 2 ore e 30 minuti con una comune connessione ADSL 20 Mega ‘dichiarati’.
A fine esecuzione avremmo un cluster OCP 4.3.8 attivo, il registry interno collegato tramite PVC e PV ad uno storage NFS e un utente ‘admin’ con i privilegi di cluster-admin.
A fine blog trovate il link al video della completa installazione (sono stati rimossi i tempi ‘morti’…)
Lo sviluppo futuro prevede il provisiong in automatico dell’infrastruttura tramite Ansible per poter ridurre ulteriolmente l’intervento manuale della creazione e boot delle vm.
Volevo ringraziare per tutti i consigli e miglioramenti Alessandro Rossi, Gianluca Cecchi e Stefano Stagnaro.
Buona visione
Valentino
