Pystytin hiljattain Amazonin AWS-pilveen Docker-ympäristön ja törmäsin ensimmäistä kertaa tilanteeseen, jossa Docker-palvelimen levy pääsi täyttymään. Tämä aiheutti /var/lib/docker-hakemiston sisältämän monimutkaisen rakenteen korruptoitumisen, jolloin osa Docker-levykuvista (imageista) meni rikki, eikä Docker suostunut edes käynnistämään uusia kontteja (containereita).

Ongelma ratkesi lopulta kopioimalla vanha sisältö talteen (/olddata-hakemistoon) ja luomalla kokonaan uusi /var/lib/docker-hakemisto. Tällöin Dockerin levykuvat ja kontit voi luoda tyhjästä uudelleen, mikä on helppoa, kun ne on jo ennestään määritelty Figillä fig.yml-tiedostoon. Omassa tapauksessani käynnistyvät tällöin uudet MongoDB- ja Postgres-kontit, joissa on tyhjä tietokanta.

Vanhan sisällön palauttaminen edellyttää seuraavia askeleita:

  • Sammutetaan Docker-palvelin (service docker stop).
  • Etsitään /olddata/var/lib/docker/vfs/dir -hakemiston alta vanha sisältö, esimerkiksi MongoDB:n datatiedostot sisältävä hakemisto.
  • Etsitään /var/lib/docker/vfs/dir -hakemiston alta uusi sisältö, jossa on uuden tyhjän MongoDB:n sisältö.
  • Kopioidaan vanhat datatiedostot raa'asti uusien päälle.
  • Käynnistetään Docker-palvelin (service docker start) ja MongoDB-kontti.

Tämän jälkeen alkuperäisen tietokannan sisällön pitäisi näkyä MongoDB:ssä. Vastaava operaatio toimii myös Postgresissä ja periaatteessa missä tahansa tietokannassa, kunhan kaikki datatiedostot ovat samassa paikassa ja voidaan palauttaa kopioimalla paikoilleen.

Ovatko sisältökontit turvallisia?

Yllä kuvattu operaatio oli tarpeen sen vuoksi, että olin käyttänyt Dockerissa sisältökontteja (data containereita). Kaikki data on silloin tallennettu konttien sisään eli käytännössä jonnekin /var/lib/docker-hakemiston alle. Tämä on kätevää ja yhteensopivaa, koska kontit eivät ole riippuvaisia tietyistä hakemistopoluista. Docker sijoittaa datan automaattisesti oikeaan paikkaan.

Näyttää kuitenkin siltä, että kriisitilanteessa sisältökonttien palauttaminen on nykyisellään turhan hankalaa ja epämääräistä. /var/lib/docker-hakemiston sisällön käsittelyyn ei ole kunnollisia apuvälineitä, kuten varmuuskopiointi- ja palautustyökaluja. On luultavasti järkevämpää tallentaa sisältö erillisiin host-volumeihin, jotka voivat olla Amazonin pilviympäristössä erillisiä EBS-levyjä. Tällöin EBS-levy kiinnitetään esimerkiksi hakemistoon /data/mongodb, ja Dockerille annetaan MongoDB-konttia käynnistäessä valitsin -v /data/mongodb:/data/db.

Jos kaikki hajoaa käsiin, Docker-ympäristö voidaan luoda Figillä tyhjästä uudelleen ja sisällöt ovat turvassa omilla EBS-levyillään.

Oma toivomuslistani Dockerin kehittämiseksi tässä suhteessa on seuraava:

  • Sisältökonttien merkitseminen "never delete" -lipulla, joka varmistaisi, että vaikka kontti vahingossa tuhottaisiin, sen sisältöä ei poisteta. (Tai sisältökonttia ei anneta tuhota, ennen kuin lippu on poistettu.)
  • Apuvälineitä /var/lib/docker -hakemistorakenteen käsittelyyn silloin, kun Docker-palvelin ei syystä tai toisesta toimi. Esimerkiksi offline-työkalu, joka varmuuskopioi kontin sisällön talteen, ja osaa palauttaa sen myöhemmin uuteen konttiin, kun Docker-ympäristö on luotu uudelleen.
  • Mahdollisuus sijoittaa halutun Docker-kontin kaikki VOLUME-sisällöt automaattisesti tiettyyn paikkaan (esimerkiksi EBS-levylle). Nykyisellään VOLUME-sisältöjen polut pitää luetella erikseen -v -parametrien yhteydessä tai fig.yml:ssä, mikä aiheuttaa turhaa käsityötä ja virheiden mahdollisuuksia.