Docker: come ho dockerizzato il mio sito
Oggi vi parlerò di come Docker ha cambiato il mio modo di gestire i web server. Chi si trova spesso a configurare web server con Apache o Nginx, magari in una nuova macchina, sa bene quanto tempo sia necessario per preparare un ambiente LAMP (Linux Apache MySQL PHP). Di norma è sempre la stessa storia: installa la distribuzione Linux di turno, installa Apache, installa PHP, installa MySQL, configura il tutto (magari anche due orette) e si prepara a rendere disponibile il servizio che gli interessa… quando si accorgo che c’è qualcosa che non funziona e… ah, diamine, si è dimenticato che serviva la versione X di PHP e la versione Y di MySQL, ma nella versione Z della distribuzione che ha installato ovviamente non ci sono! Ed ecco ore di lavoro sprecato!
Siamo sinceri, a chi non è mai capitata una situazione del genere?
Ecco perché ho deciso di migrare tutto il mio sito in un ambiente con Docker, dove ogni “servizio” gira in un proprio “container“. Praticamente, dopo aver fatto un backup di tutto quanto, ho reinstallato l’ultima distribuzione LTS di Ubuntu e ho installato Docker.
A questo punto, grazie a Docker Compose (un sistema per unire più container sotto un unico servizio), non ho fatto altro che scrivere il seguente file di configurazione (ovvero il servizio di tutto il mio sito) con tutti i container che mi interessavano:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 |
nginx-proxy: image: jwilder/nginx-proxy container_name: nginx-proxy ports: - 80:80 volumes: - /var/run/docker.sock:/tmp/docker.sock:ro restart: always wordpress: image: wordpress container_name: wordpress links: - db:mysql ports: - 8001:80 restart: always volumes: - ~/wordpress/:/var/www/html/ environment: WORDPRESS_DB_USER: utente WORDPRESS_DB_PASSWORD: password WORDPRESS_DB_NAME: database VIRTUAL_HOST: www.brisma.it,brisma.it db: image: mariadb container_name: db restart: always volumes: - ~/mariadb/:/var/lib/mysql/ environment: MYSQL_ROOT_PASSWORD: password MYSQL_USER: utente MYSQL_PASSWORD: password MYSQL_DATABASE: database phpmyadmin: image: phpmyadmin/phpmyadmin container_name: phpmyadmin links: - db:db restart: always ports: - 8002:80 environment: VIRTUAL_HOST: phpmyadmin.brisma.it jenkins: image: jenkins:alpine container_name: jenkins restart: always ports: - 8003:8080 - 50000:50000 volumes: - ~/jenkins/:/var/jenkins_home environment: VIRTUAL_HOST: jenkins.brisma.it VIRTUAL_PORT: 8080 watchtower: image: centurylink/watchtower container_name: watchtower restart: always volumes: - /var/run/docker.sock:/var/run/docker.sock |
E l’ho lanciato con un semplice:
|
1 |
docker-compose up -d |
Ed in circa due minuti Docker ha fatto tutto quello che avrei fatto io in circa 2 ore, comprese le configurazioni di database, nomi utente, password tra i vari container come WordPress, Mariadb (fork di MySQL), PhpMyAdmin e Jenkins. Infine ho ripristinato il backup precedentemente effettuato.
Ognuno di questi container, anziché girare sulla canonica porta 80, gira in ordine crescente dalla porta 8001 in su (scelta mia, poteva essere qualsiasi porta) in modo da poter aggiungere sempre nuovi container qualora mi servano.
Tutti i container girano dietro un proxy Nginx (con cui sono mappati tramite una variabile VIRTUAL_HOST) e l’intero ambiente viene controllato da un container chiamato WatchTower che si occupa di tenere aggiornate le immagini dei vari container con le ultime disponibili nel caso esca una nuova immagine.
Per intenderci: domani esce l’aggiornamento X di Mariadb? Ecco, non devo fare nulla, il container si aggiornerà da solo all’ultima release e si configurerà in automatico in tutti gli altri container ad esso collegati senza che abbia problemi di dipendenze o distribuzione.
Geniale, vero?