fbpx
La formazione ufficiale Red Hat

Openshift 4.3.8 UPI su oVirt – parte 2

Avatar
Valentino Uberti
RHCA, RHCX, RHCI - Red Hat Certified Instructor

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:

https://docs.openshift.com/container-platform/4.3/installing/installing_bare_metal/installing-bare-metal.html

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 wheel

e che il file /etc/sudoers delle due vm contenga la seguente linea:

%wheel   ALL=(ALL) NOPASSWD: ALL

Come 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:

https://docs.openshift.com/container-platform/4.1/installing/installing_bare_metal/installing-bare-metal.html#installation-obtaining-installer_installing-bare-metal

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.yaml

la 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

Info about author
Avatar

Valentino Uberti

RHCA, RHCI, RHCX and consultant