You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »




Overview


Usiamo un meccanismo di CI/CD per cui:

  • Esiste un git repo 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' 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 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) 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 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):



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



Download del repo git



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










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:


$ 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):


git crypt unlock ~/Workdir/KeyRepoEpoxyTesting



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


 # 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


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


  • Creo un nuovo branch (a partire da testing)
  • Faccio le modifiche su questo branch
  • Se mi serve la cloud di test per testare questi sviluppi
    • Avverto tutti (chiedendo che nessuno committi in testing se non strettamente necessario)
    • Metto in /var/puppet/puppet_epoxy_env_test quanto sta ne branch xxx)
      • Occhio che se qualcuno 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):


  • Faccio PR da branch di devel verso testing
    • Questo triggera il deployment della modifica  sulla cloud di test
  • Verifico che sulla cloud di test funzioni tutto e non si sia rotto nulla
  • Faccio PR da testing a main
    • Questo triggera il deployment della modifica  sulla cloud di produzione
  • Cancello il branch di devel








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:


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



$ git diff main..testing controller_epoxy/manifests/configure_ec2.pp
diff --git a/controller_epoxy/manifests/configure_ec2.pp b/controller_epoxy/manifests/configure_ec2.pp
index abcbb1a..5bc9adf 100644
--- a/controller_epoxy/manifests/configure_ec2.pp
+++ b/controller_epoxy/manifests/configure_ec2.pp
@@ -8,6 +8,7 @@ class controller_epoxy::configure_ec2 inherits controller_epoxy::params {
 
 ##
 # FF aggiungo questa riga di test
+# e anche un'altra
 ##
 
 file { ['/var/lib/ec2-api',







  • No labels