Divagazioni elettroniche

Mi rendo conto che Docker è stato progettato per gestire un solo processo per container (difatti non ha un processo di init come un sistema operativo "normale"), però io preferisco avere sempre una porta aperta per potermi collegare a un container per vedere cosa sta succedendo. C'è un altro caso in cui ho bisogno di più di un processo: uno dei siti web che amministro si basa su un server node.js a cui Apache passa le richieste tramite mod_proxy. Per ottenere una maggiore alta affidabilità avvio due processi node.js contemporaneamente che si pongono in ascolto su due porte differenti. Trovo che Monit sia comodo per ottenere questo risultato. L'esempio che segue mostra come costruire un'immagine che avvia Monit per gestire solo un demone SSH. Come ho descritto in un  precedente articolo , io utilizzo uno script di setup per svolgere tutte le operazioni e per mantenere il Dockerfile più piccolo possibile. Non riporterò qui l'intero Dockerfile , ma solo le

Creando un po' di immagini in Docker mi sono reso conto che è possibile avere un Dockerfile con una struttura che cambia poco tra un'immagine e l'altra in modo da avere un ambiente di "build" uniforme. Inoltre di solito faccio fare la maggior parte del lavoro a uno script di shell che viene eseguito nel containter invece che al Dockerfile; questo ha qualche vantaggio: si può utilizzare tutta la potenza della shell e si mantiene basso il numero di livelli. Tenete presente che Docker può gestire al massimo 127 livelli usando il devicemapper, mentre con AUFS il massimo scende a circa 42. Struttura del Dockerfile I miei Dockerfile sono divisi in quattro sezioni principali: 1) copia dei file nel container; 2) esecuzione del setup; 3) pubblicazione delle porte; 4) impostazione del comando di start. Copia dei file Come prima cosa si copiano tutti i file necessari nel container. Se i file sono numerosi è meglio chiuderli in un archivio tgz per avere il numer