IL BLOG DEGLI RHCE ITALIANI

Build riproducibili di RPM

Marco Tizzoni

lazyness

Creare e compilare RPM custom e’ un’esperienza piuttosto noiosa per i lazy sysadmin. Rendiamo quindi la vita più semplice e interessante pensando una soluzione aziendale che ci faccia lavorare meno lasciando più tempo da dedicare ad attività decisamente più interessanti e proficue. Inoltre, se ci si trova in un contesto enterprise, la creazione di un banale RPM apre una serie di problemi. Analizziamoli uno per uno:

  1. Conoscenza dispersa: La mancanza di un repository centralizzato dove tutti gli RPM custom sono disponibili, versionati e facilmente accessibile rende difficile uniformare le prassi e costruire una conoscenza condivisa. In poco tempo si hanno centinaia di RPM tutti diversi senza il rispetto di nessun standard;
  2. Task manuali ripetitivi: la compilazione manuale di RPM richiede una serie di passi che possono essere automatizzati (build, sign, rpmlint, push, …) risparmiando tempo ed energie mentali;
  3. Build non consistenti su piattaforme diverse: lo stesso SPEC file produce due RPM differenti se compilato su piattaforme differenti (ad esempio RHEL 5 e RHEL 6 ma anche tra stesse major version). E’ fondamentale essere in grado di riprodurre la build in maniera consistente nel tempo cosi’ da evitare effetti imprevedibili sui sistemi.

Prerequisiti

Da qui in avanti do per scontato che il lettore abbia familiarità con Spacewalk/Satellite, amministrazione di sistemi RHEL/Fedora e la compilazione di RPM.

Ho previsto i seguenti sistemi virtuali per mostrare un esempio minimale ma completo. Nulla vieta comunque di installare tutti i componenti su un solo host.

Una soluzione

Iniziamo col risolvere il problema della conoscenza dispersa. Senza un singolo repository, facilmente accessibile dove poter guardare cosa gli altri colleghi hanno fatto prima di me, imparare, migliorarlo e contribuire facilmente. Questo mi aiuta a costruire un modo comune di lavorare, standardizzare, migliorare la qualità e mantenere memoria storica.

La prima cosa e’ quindi avere un repository centralizzato dove avere tutto il software aziendale e gli SPEC possano essere versionati e accessibili a chiunque. La scelta e’ stata semplice: git. E’ moderno, open e supporta un modello di sviluppo distribuito. In realta’ quello che volevo non era soltanto un Version Control System ma un sistema collaborativo stile di github. Non potendo usare github ho cercato una soluzione simile ma installabile in locale e ho trovato gitlab. gitlab e’ di fatto un clone di github, se avete un account su github nulla di nuovo, altrimenti avete scoperto il nuovo mondo. Ecco cosa fa gitlab:

gitlab e’ un’applicazione RoR (Ruby on Rails) che usa redis e altri componenti. L’installazione non e’ banale e ci sono almeno tre opzioni:

  1. Installare tutto manualmente (enjoy…)
  2. Usare il cookbook chef già pronto
  3. Usare l’installazione omnibus con il pacchetto RPM già pronto per RHEL

Noi seguiremo quest’ultima opzione.

GitLabControl-Full-Light

Installare gitlab

  1. Dal Satellite creare due nuovi repository: EPEL e PUIAS (https://access.redhat.com/site/solutions/308983) . Quest’ultimo ci servira’ per installare una versione piu’ recente di git.
  2. Agganciare i software channels a tutti i sistemi.
  3. Importare le chiavi dei due repository su tutti i sistemi:
# rpm --import http://puias.princeton.edu/data/puias/6/x86_64/os/RPM-GPG-KEY-puias
# rpm -import http://www.fedoraproject.org/static/0608B895.txt
gitlab # yum -y install openssh-server postfix git
gitlab # chkconfig ssh on
gitlab # chkconfig postfix on
gitlab # wget https://downloads-packages.s3.amazonaws.com/centos-6.5/gitlab-6.9.2_omnibus.1-1.el6.x86_64.rpm
gitlab # rpm -ivh gitlab-6.9.2_omnibus.1-1.el6.x86_64.rpm
gitlab # gitlab-ctl reconfigure

L’installazione completa porta con se’ tutto quanto e’ necessario in un unico bundle, ruby compreso, e si trova in /opt/gitlab. Logs e file di configurazione sono nelle posizioni standard. L’operazione di reconfigure applica un cookbook chef che ne assicura la corretta configurazione e’ quindi piu’ di un suggerimento quello di non modificare alcun file in /opt/gitlab.

#### /etc/gitlab/gitlab.rb #####
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_host'] = 'activedirectory.example.com'
gitlab_rails['ldap_port'] = 389
gitlab_rails['ldap_uid'] = 'sAMAccountName'
gitlab_rails['ldap_method'] = 'plain' # 'ssl' or 'plain'
gitlab_rails['ldap_bind_dn'] = 'CN=user,CN=Users,DC=example,DC=com'
gitlab_rails['ldap_password'] = 'password'
gitlab_rails['ldap_allow_username_or_email_login'] = true
gitlab_rails['ldap_base'] = 'DC=example,DC=com'

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.example.com"
gitlab_rails['smtp_port'] = 456
gitlab_rails['smtp_user_name'] = "smtp_user"
gitlab_rails['smtp_password'] = "smtp_password"
gitlab_rails['smtp_domain'] = "example.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true

# limit backup lifetime to 7 days - 604800 seconds
gitlab_rails['backup_keep_time'] = 604800

external_url "https://gitlab.example.com:2443"
nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.key"

Le prime righe configurano l’autenticazione su un dominio Active Directory, LDAP funziona analogamente, occorre modificare l’ldap_uid in

gitlab_rails['ldap_uid'] = 'sAMAccountName'

Segue la configurazione dell’SMTP server per le notifiche via email, la retetion del backup e la configurazione dell’SSL. Per semplificare la creazioni dei certificati e’ possibile installare il pacchett gnutls-utils e usare l’utility certtool.

Il comando di backup

$ sudo gitlab-rake gitlab:backup:create

crea un export completo di tutti i dati e i repository nella directory /var/opt/gitlab/backups.

Riavviamo gitlab con:

# service gitlab-ctl restart

Cosa resta se non accedere alla console di gitlab all’URL https://gitlab.example.com con ‘root/5iveL!fe‘?

Abbiamo adesso un’installazione funzionante di gitlab, il nostro repository git. Basta? La brutta notizia e’ che no, non basta. Non basta avere un nuovo tool installato perche’ tutto funzioni meglio. Il tool puo’ supportare un cambiamento nel modo di lavorare e aumentare la produttivita’ riducendo i task noiosi ma e’ fondamentale investire del tempo nel cambiare l’organizzazione e imparare passo dopo passo come lavorare meglio. Ecco dunque alcuni suggerimenti:

  1. Rendi, per quanto possibile, il repository pubblico
  2. Incoraggia la partecipazione: qualcosa non funziona? Hai la possibilita’ di vedere il codice (il repository e’ pubblico!) e di sistemarla da te! Gitlab ci viene in aiuto con le pull-request, uno strumento essenziale che permette a qualsiasi utente di fare una copia privata del repository, approntare le proprie modifiche e, una volta pronte, inviare una richiesta di merge (pull-request, perche’ e’ il repository originario che fa pull delle modifiche) al proprietario del repository originario
  3. Adotta un workflow per lo sviluppo, un buon punto di partenza e’: http://nvie.com/posts/a-successful-git-branching-model/ ma può essere troppo complesso per iniziare, meglio partire con qualcosa di più semplice.
  4. Fai l’enforcing della code-review, ovvero come ti miglioro il codice, riduco gli incident, e costruisco uno standard aziendale. Prima di mandare qualsiasi cosa in produzione le modifiche devono essere riviste da 2 componenti del team
  5. Usa tool che controllano la qualità del codice e il rispetto degli standard (ad esempio, rpmlint per gli RPM)
  6. Automatizza l’impossibile per rendere ridurre i task manuali e ripetitivi. Una buona regola e’, “l’ho fatto tre volte? Va automatizzato”.
  7. Traccia quello che non puoi migliorare da subito. gitlab ha un wiki ed e’ anche un issue tracker.

Nel prossimo articolo della serie vedremo come automatizzare le build.

A presto!

Info about author

Marco Tizzoni

Prenota subito il tuo corso ufficiale Red Hat

GUARDA I CORSI