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:
- 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;
- 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;
- 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.
- 4 sistemi base RHEL 6 o Fedora 19+:
- Satellite/Spacewalk up & running
- Tutti i sistemi registrati su Satellite
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:
- Gestisce i repository git
- Interfaccia grafica web ai repository
- Code review
- Issue tracking
- Wiki
- Feeds
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:
- Installare tutto manualmente (enjoy…)
- Usare il cookbook chef già pronto
- Usare l’installazione omnibus con il pacchetto RPM già pronto per RHEL
Noi seguiremo quest’ultima opzione.
Installare gitlab
- 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.
- Agganciare i software channels a tutti i sistemi.
- 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
- Installare gitlab:
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.
- Configurare gitlab: editiamo il file /etc/gitlab/gitlab.rb per customizzare le impostazioni di default.
#### /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:
- Rendi, per quanto possibile, il repository pubblico
- 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
- 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.
- 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
- Usa tool che controllano la qualità del codice e il rispetto degli standard (ad esempio, rpmlint per gli RPM)
- Automatizza l’impossibile per rendere ridurre i task manuali e ripetitivi. Una buona regola e’, “l’ho fatto tre volte? Va automatizzato”.
- 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!
