Esperienza di migrazione di un intero sistema informativo da VM a container, utilizzando Docker, Rancher e ZFS. Durante lo speech verrà mostrato come abbiamo ristrutturato il nostro sistema informativo aziendale affrontando tematiche di disaster recovery, monitoraggio e backup. Saranno illustrati i vantaggi ottenuti e le sfide che abbiamo dovuto affrontare durante la migrazione di Alfresco, Gitlab, Redmine, SemanticMediaWiki. Migrando a container abbiamo ottenuto backup online 24x7, la possibilità di creare ambienti on-demand per le migrazioni e l'indipendenza dal provider dell'infrastruttura.

1. La nostra infrastruttura di produzione
Un’esperienza concreta in un contesto di produzione
Filippo Bosi
fbosi
@imolainformatica.it
Vincenzo Laudizio
vlaudizio
@imolainformatica.it
Gabriele Morlini
gmorlini
@imolainformatica.it

2. 2
Situazione precedente
• Quantitàconsiderevoledi risorse non dedicateai servizi
• Staticitàdell’infrastruttura
• Backup voluminosi
• Non riproducibilità
• Dilatazionedei tempi
• Attivitàmanuali
Produzione
Imola
Enterprise Management
Tools
Virtualization Layer
VM
Servizio X
VM
Servizio Y
...
VM
Servizio Z
VM
Reverse Proxy
Limiti:

3. 3
Attività ed Obiettivi
Outsourcing dell’infrastruttura di
produzione
• Presidio 24/7
• Affidabilità
• Prestazioni
• Sicurezza
Transitorio senza soluzione di
continuità
Abbattimento dei costi di esercizio
Svecchiamento Tecnologico
Indipendenza dal fornitore
dell’infrastruttura
• Cloud first
Opensource
Disaster Recovery
Backup in-house

4. 4
Svecchiamento Tecnologico
Problematiche riscontrate:
• Eterogeneità delle VM e vincoli
• Mismatch tra l’installato e le immagini
pubbliche
• Migrazione dei dati
• Processo di rilascio
• Governo e monitoraggio
Migrazione a Container (N Stack tecnologici differenti):
• Estendibilità & Versionamento
• Più efficienti rispetto VM
• Maggiore densità
• Flessibilità & Elasticità

5. 5
Principi
• Stack isolati ed Autocontenuti → Suddivisione netta programma da dati (stato)
• Upgrade di versione automatici → Vincoli su Applicazione e Processo
• Affidabilitàe DR dei servizi piuttosto che ridondanza → Facile replicare ambiente
Terminologia:
Stack → insieme di componenti che
permettono erogazione servizio
Stato:
• Parametri di configurazione delle
Componenti
• Dati dell'applicazione
➢ Unico per stack (e ambiente)
Vincoli:
▪ Applicazione in grado di aggiornare la
propria base dati in maniera automatica
▪ Processo (Sistema) in grado di gestire
eventuali cambi di configurazione:
▪ Immagini parametriche
▪ Inclusione automatismi
▪ Possibilità di fare cloni e snapshot

6. 6
Gestione e Orchestrazione
Perchè Rancher:
• Effort minimo per definizione di uno stack
(docker-compose)
• Semplifica:
• Gestione rete
• Accesso e monitoraggio container
• API Rest «pronte all’uso»
Orchestratore infrastrutturale
• Versione 1.6
Architettura Master-Slave
Concetti ed Astrazioni:
• environment:raggruppamenti di risorse
• service: unità di deploy -> un container
• stack: un gruppo di servizi ( tramite docker-
compose)
• catalog: repository di stack pronti all’uso
• gli application stacks
• gli infrastructure services

7. 7
Definizione Stack – Docker Compose
Descrive:
▪ Versione servizi
▪ Dipendenze tra servizi
▪ Parametri di configurazione
servizi
▪ Legame Volumi (stato)dei servizi
e volumi su Host
https://docs.docker.com/compose/
Possibile utilizzo in Locale e Remoto (tramite Rancher)
Isolamento di rete fra stack applicativi distinti
Agent
docker-compose.yml
services:
tcp 80 tcp 5432
/var/opt/gitlab
Volumes
/etc/gitlab
postgres
gitlab
/var/lib/
postgresql/data
link
VM
Master
Datacenter
Imola
IaaS (X)

8. 11
Gestione Stato
→ OpenZFS
• Creazione Snapshot
• Cloni da Snapshot
• Trasferimento di Snapshot
• Disaccoppiamentofra datasete
device
• Supporta crittografia
Esigenza:
• Ottimizzazione spazio disco
• File System Sicuro e Versatile
Agent
dev dev
...dataset dataset
zpool
/var/opt/gitlab
volumes:
/etc/gitlab
postgres
gitlab
/var/lib/
postgresql/data
link
Stack
ZFS

9. 12
ZnapZend 1
• Tool per l’automazione di
procedure ZFS
• Creazione Snapshot
• Invio remoto
• Retention policy (locale &
remota)
Backup
Esigenza
Backup remoto
non invasivo
1 https://github.com/oetiker/znapzend
Agent dev dev
...dataset dataset
zpool
/var/opt/gitlab
volumes:
/etc/gitlab
postgres
gitlab
/var/lib/
postgresql/data
link
ZFS
VM
dev dev
...dataset dataset
zpool
ZFS
DataCenter
Imola
IaaS (X)
DataCenter
R&D Imola
dev dev
...dataset dataset
zpool
ZFS
•Intervallo di creazione Snapshot
•Destinazioni remote
•Retention policy (locale & remoto)

10. 13
VM
Master
Datacenter
Imola
Agent
Stack
tcp 80
Volumes
postgres
redmine
link
IaaS (X)
rancher-compose rancher-compose
Agent
Stack
tcp 80
Volumes
postgres
redmine
link
docker-compose.yml
Versionamento
• Git (Codice)
• Registry Gitlab (Artefatti)
Build & Delivery Servizi
• Jenkins e Gitlab CI/CD (Automazione)
• Docker e Pipeline (Riproducibilità)
Build & Delivery Infrastrutturale
• Ansible (Riproducibilità)
Gestione Ambienti
• Outsourcing+ DR (Produzione)
• Imola/Outsoucing(Test)
• Locale (Sviluppo)
Processo & Servizi a supporto

11. 14
Build & Delivery Infrastrutturale - Ansible
VM
VM
...
VM
IaaS (X) IaaS (Y)
DataCenter
Imola
Mgmt
Node
Playbooks
Host
Inventory
RANCHER
Agent
RANCHER
Agent
RANCHER
Master
RANCHER
Agent
RANCHER
Agent
RANCHER
Agent
Playbook Ansible per:
• Setup Docker-engine
• Setup e configurazione Rancher
• Ruoli
Limite: Prima configurazione manuale
✓ IaaS (Utenze/Chiavi per accesso ssh)
✓ Nodo di Gestione Ansible con visibilità di rete
totale

12. 15
Esposizione su internet - Proxy
Reverse Proxy a Container
➢ Unico punto di accesso Internet per Nodo /
DataCenter / Region
➢ Terminatore SSL
+PLUS nel processo di Automazione
➢ Utilizzo di Rancher Active Proxy 1
• Reverse Proxy su base NGINX
• Analisi Dinamica dei Servizi per la
costruzione della tabella di routing
• Utilizzo delle label associate ai servizi per
indicare i virtual host
Agent
Stack
tcp 80 tcp 5432
link
Stack
tcp 443
Volumes
rap
/etc/nginx/certs
tcp 443
https://git.imolinfo.it
git.imolinfo.it
1 https://github.com/adi90x/rancher-active-proxy

13. 16
Esposizione su internet – Sistema di nomi
CloudFlare DNS
➢ Esposizione di API per il governo
remoto del DNS
+PLUS nel processo di Automazione
➢ Utilizzo del Servizio CloudFlare DNS
fornito dal Catalog di Rancher1
• Analisi Dinamica dei Servizi per la
registrazione dei record su DNS
• Label dei Servizi
per indicare il dominio
1 https://github.com/rancher/community-catalog
Agent
Stack
tcp 80 tcp 5432
link
Stack
tcp 443
Volumes
rap
/etc/nginx/certs
tcp 443
git.imolinfo.it
https://git.imolinfo.it
«resolve»
git.imolinfo.it
81.208.42.178
«access»
Stack
«bind»
2
1 3
git.imolinfo.it :=81.208.42.178

14. 17
Disaster Recovery
Allineamento tramite ZnapZend
Volumi allineati a ultimo snapshot
Switch DNS
Cloudflare
Agent dev dev
...dataset dataset
zpool
/var/opt/gitlab
volumes:
/etc/gitlab
postgres
gitlab
/var/lib/
postgresql/data
link
ZFS
Datacenter
ImolaIaaS (X)
VM
Agent
dev dev
...dataset dataset
zpool
/var/opt/gitlab
Volumes
/etc/gitlab
postgres
gitlab
/var/lib/
postgresql/data
link
Stack
ZFS

15. 18
Monitoraggio
Risorse Servizi
http
Spazio
disco
Cpu … Alert Mail SMS …
...
RANCHERAgent
Agent
...
RANCHERAgent
Agent
IaaS (X) IaaS (Y)
Datacenter
Imola
VM
Server
...
RANCHERAgent
Agent
VM
... ...
......

16. 19
Migrazione
• Completare per tutti servizi esistenti
• Utilizzo diversi Datacenter
• Migrazione non invasiva del
Rancher Master
• Automazione configurazione di
rete
Architettura
• Gestione centralizzata log ed eventi
• Test automatici dei servizi
• Centralizzazione configurazioni ZFS
• Block device distribuito e storage
distribuito
Sicurezza
• Analisi di sicurezza proattiva
• Crittografia su ZFS
What’s Next

17. Grazie
Domande?

18. www.twitter.com/imolinfo
www.facebook.com/imolinfo
www.linkedin.com/company/imola-informatica
Imola Informatica S.P.A.· via Selice 66/a · Imola (BO)
www.imolainformatica.it - blog.imolainformatica.it