Page History

Work in progress

Table of Contents

Overview

Usiamo un meccanismo di CI/CD per cui:

Esiste un git repo (xxx) unico sia per la parte controller che per la parte compute con 2 branch principali:
- Il branch 'main' viene usato nella cloud di produzione (environment 'production' di puppet)
- Il branch 'testing' viene usato nella cloud di test (environment 'testing' di puppet' dove vanno riportate tutte e sole le cose gia' testate che devono andare in produzione
Oltre a questi 2 branch principali, esistono dei branch creati ad hoc che vengono usati per lo sviluppo di nuove funzionalita'/bug fix (vedi sotto)
- Quando il codice relativo e' stato testato e si ritiene che sia pronto per andare in produzione, si riporta tale codice in testing.

Il codice puppet che viene usato sta in cld-config
- Per la cloud di produzione sta in cld-config
. ma non si deve MAI modificare i sorgenti puppet direttamente su cld-config
- nella directory /var/puppet/puppet_epoxy
  - Questo codice viene automaticamente sincronizzato dal branch main
  - Non si deve MAI modificare i sorgenti puppet della directory /var/puppet/puppet_epoxy di cld-config
- Per la cloud di test sta in cld-config nella directory /var/puppet/puppet_epoxy_env_test
  - Un webhook fa un "git checkout" da testing ogni volta che c'e' un commit su questo branch
  - Quindi solitamente il codice che sta in questa directory corrisponde a quanto sta nel branch testing (salvo quando si devono testare nuovi sviluppi: v. sotto)

Modifiche al codice vanno implementate:
- Per cloud di test committando (lavorando sulla propria postazione di lavoro) committando sul branch testing. Queste vengono apoi utomaticamente "scaricate" in cld-config
- Per cloud di produzione (quindi branch main) solo come pull request lavorando sulla propria postazione di lavoro. Una volta che sono approvate (e quindi mergiate nel branch main
/testing
- ) queste vengono automaticamente "scaricate" in cld-config
Prima si modifica sul branch testing e poi (dopo una fase di testing) la modifica deve finire anche in main
- Modifiche solo in main non devono essere fatte

Setup iniziale dell'ambiente

...

Installare git-crypto

Copiare da cld-confi

xxxx

Verifica preliminare obbligatoria

Verificare che i repo di test e di produzione siano aggiornati

- cd /var/puppet/puppet_caracal_env_test/
- git status
  - se c'e' qualcosa non committato nel repo centrale (web) va chiesto a chi ha fatto le modifiche e in caso committato
- git pull
- cd /var/puppet/puppet_caracal
- git status
  - se c'e' qualcosa non committato nel repo centrale (web) va chiesto a chi ha fatto le modifiche e in caso committato
- git pull

Per modifiche in env test

Se devi modificare file nell'ambiente di test

sulla propria postazione di lavoro

Installazione git-crypt

Va installato git-crypt

Per i sistemi RHEL compliant esiste in EPEL (quindi 'yum install git-crypt')

Se non c'e' il pacchetto per la propria distribuzione, si puo' installare da sorgente (dipendenze: gcc-c++ e openssl-devel):

Code Block
git clone https://github.com/AGWA/git-crypt.git make make install PREFIX=/usr/local

Download del repo git

Code Block
mkdir ~/Workdir cd ~/Workdir git clone https://github.com/CloudPadovana/puppet_epoxy.git

Scaricare la chiave per il crypting dei file params.pp

Scarico da cld-config il file /var/puppet/KeyRepoEpoxyTesting e copiarlo ad esempio in ~/Workdir

Code Block

Workflows

Modifica semplice, non pericolosa, da riportare in produzione

Esempi in questa categoria:

cambio del valore di un parametro in params.pp
Aggiunta di un nodo per cui non si applica l'overcommitment

Chi fa la modifica committa in testing dalla sua postazione di lavoro.

Per prima cosa si verifica che il proprio repo locale sia aggiornato:

Code Block
$ cd ~/Workdir/puppet_epoxy/ $ git checkout testing Switched to branch 'testing' Your branch is up to date with 'origin/testing'. $ git pull Already up to date.

Se serve modificare anche un file params.pp, farne prima il decrypt (decrypt che avviene solo locamente: sul repo i file restano cryptati):

Code Block
git crypt unlock ~/Workdir/KeyRepoEpoxyTesting

A questo punto si fa la modifica sul branch testing, che poi si committa e si pusha:

Code Block
# fai modifiche git add <files modificati> git commit -m "Messaggio" <files modificati> git push

Se la cloud di test era usata per test di una nuova funzionalita' (vedi sotto) si avverte il relativo utente perche' si resetteranno le sue modifiche in

...

/var/puppet/puppet_

...

epoxy_env_test di cld-config

...

Si verifica che a seguito della modifica non viene rotto nulla nella cloud di test (dove la modifica viene automaticamente propagata)

Si apre una PR per mettere la modifica in produzione

- Si va in: https://github.com/CloudPadovana/puppet_epoxy → Pull requests e poi "New pull requests"
- Si seleziona in alto "main" come base e "testing" come compare e si clicca su "Create pull request"

Occhio che la PR conterra' anche eventuali altre modifiche fatte in testing da altri utenti

Quando la PR viene approvata, la modifica viene automaticamente installata in produzione

Sviluppo e testing di una nuova funzionalita'/bug fix

Si crea un nuovo branch ad hoc a partire da testing. Come nome del branch scegliere un nome che sia significativo con la modifica che si sta facendo:

Code Block
$ cd ~/Workdir/puppet_epoxy/ $ git checkout testing Switched to branch 'testing' Your branch is up to date with 'origin/testing'. $ git pull Already up to date. $ git checkout -b <nome-del-branch>

Fare le modifiche del caso e poi committare e pushare:

Code Block
git add . git commit -m "Your detailed description of your changes." git push origin <nome-del-branch>

Se serve usare la cloud di test per testare questi sviluppi per prima cosa si avvertono tutti (chiedendo che nessuno committi in testing se non strettamente necessario)

Poi si mette in /var/puppet/puppet_epoxy_env_test di cld-config quanto sta ne branch di sviluppo

Occhio che se qualcuno nel frattempo committa in testing, il contenuto di /var/puppet/puppet_epoxy_env_test sara' automaticamente sincronizzato con il branch testing

Messa in produzione di una nuova funzionalita'/bug fixing

Dopo che la modifica e' stata fatta (su un branch ad-hoc di devel) e testata (v. punto precedente):

Si apre una PR da questi branch di devel creato ad hoc a testing:

- Si va in: https://github.com/CloudPadovana/puppet_epoxy → Pull requests e poi "New pull requests"
- Si seleziona in alto "testing" come base e il branch di devel come compare e si clicca su "Create pull request"

Questo triggera il deployment della modifica sulla cloud di test

Si verifica che a seguito della modifica non viene rotto nulla nella cloud di test (dove la modifica viene automaticamente propagata)

Si apre una PR per mettere la modifica in produzione

git push WARNING: Since August 2021 for the commit is required the personal token instead of the password! Follow this instruction to create a personal token and remember to save it. Then use the token instead of the old password otherwise you will get the message:

...

- Si va in:

- https://github.com/CloudPadovana/puppet_

...

Per modifiche in env di produzione

Se devi modificare file nell'ambiente di produzione

...

git push WARNING: Since August 2021 for the commit is required the personal token instead of the password! Follow this instruction to create a personal token and remember to save it. Then use the token instead of the old password otherwise you will get the message:

- epoxy → Pull requests e poi "New pull requests"
- Si seleziona in alto "main" come base e "testing" come compare e si clicca su "Create pull request"

Occhio che la PR conterra' anche eventuali altre modifiche fatte in testing da altri utenti

Quando la PR viene approvata, la modifica viene automaticamente installata in produzione

Sincronizzazione tra main e testing

In generale quello che e' su testing e' roba gia' testata (almeno singolarmente) o una modifica semplice e che voglio che finisca in produzione.

Quindi deve finire anche su main (dopo la fase di testing delle modifiche fatte sulla cloud di test).

La "sincronizzazione tra main e testing va gestita "a mano" (v. sopra)

Per vedere i file che differiscono tra main e testing:

Code Block

$ git diff --stat main..testing 
 .gitattributes                              | 3 +++
 README.md                                   | 1 -
 compute_epoxy/manifests/neutron.pp          | 1 +
 compute_epoxy/manifests/nova.pp             | 1 +
 controller_epoxy/manifests/configure_ec2.pp | 1 +
 5 files changed, 6 insertions(+), 1 deletion(-)

Per vedere le differenze in un file: