Docker serveris: millal konteinerid tasuvad ära

Arendaja ütles, et „pane see Dockerisse“, ja nüüd töötab serveris kuus konteinerit, millest keegi täpselt ei tea, mida igaüks teeb. Või vastupidi: rakendus on aastaid käsitsi serverisse paigaldatud ja iga uuendus on hirmutav, sest keegi ei mäleta, mis teegid ja seadistused selle taga on.

Docker ei ole iseenesest hea ega halb. See on tööriist, mis lahendab ühe kindla probleemi — rakendus ja tema keskkond liiguvad koos — ja toob kaasa paar uut. Allpool on kirjas, millal ma seda soovitan ja millal mitte.

Lühivastus: Docker tasub ära, kui serveris on mitu rakendust eri versiooninõuetega, kui rakendust on vaja korduvalt ja ühtemoodi paigaldada või kui vana rakendus tuleb eraldada uuest süsteemist. Ühe lihtsa veebilehe jaoks, mida keegi ei uuenda, lisab see enamasti ainult keerukust.

Millal konteinerid päriselt aitavad

• Mitu rakendust, eri nõuded. Üks vajab vana Java- või PHP-versiooni, teine uut. Ilma konteineriteta tähendab see serveris versioonide segadust; konteineris on igal rakendusel oma keskkond.
• Uuendus ja tagasipööramine. Uus versioon on uus pilt (image). Kui midagi läheb valesti, käivitad eelmise pildi ja oled minutitega tagasi seal, kus olid.
• Kolimine. Kui rakendus on konteineris ja andmed on selgelt eraldatud, on uude serverisse kolimine palju etteaimatavam. Sama kehtib uue Ubuntu LTS-i peale minekul — host-süsteemi uuendus ei lõhu rakenduse sees olevaid teeke.
• Korratav paigaldus. Arendus-, test- ja töökeskkond on sama kirjelduse põhjal tehtud, mitte käsitsi „umbes samasugused“.

Millal Docker on lihtsalt lisakeerukus

• Serveris on üks lihtne rakendus, mis töötab ja mida harva muudetakse.
• Kedagi ei ole, kes konteinereid jälgiks ja uuendaks. Konteiner ei uuenda end ise — vana pilt jääb vanaks, isegi kui host-süsteem on lapitud.
• Rakendus on väga tihedalt seotud serveri endaga (riistvara, failisüsteem, spetsiifilised teenused) ja konteinerisse viimine tähendaks suurt ümbertegemist ilma selge kasuta.

Mis konteineritega muutub

Uuendused. Lisaks operatsioonisüsteemile tuleb uuendada ka pilte. Vana latest-sildiga pilt, mida pole kuude kaupa uuesti tõmmatud, võib sisaldada sama vana tarkvara nagu hooletusse jäetud server. Lepin alati kokku, kes ja kui tihti pilte uuendab.

Varundus — siin tehakse kõige rohkem vigu. Konteiner on ühekordne, andmed ei tohi seda olla. Andmebaas, üleslaaditud failid ja seadistused peavad olema köidetes (volumes) või hostis, ja varundus peab katma just neid. Kui andmebaas elab konteineris ilma köiteta, kaob see koos konteineriga. Andmebaasi varundan alati andmebaasi enda tööriistaga (näiteks PostgreSQL-i või MySQL-i/MariaDB dump), mitte köite failide pealt töö ajal kopeerides.

Logid. Konteineri logid tuleb suunata kuhugi, kus neid on võimalik lugeda ja kus need ei täida ketast. Muidu leiad pool aastat hiljem gigabaitide kaupa logisid, mida keegi pole vaadanud.

Turvalisus. Konteiner ei ole turvatsoon iseenesest. Ära käivita rakendust juurkasutajana, ära ava andmebaasi porti avalikult ja ära pane paroole pildi sisse. Serveri enda turvamine jääb samaks — vaata ka minu Linuxi serveri turvamise kontroll-loendit.

Tüüpiline ülesehitus

Väikeettevõtte rakenduse puhul kasutan enamasti sellist mustrit:

1. Nginx ees — võtab vastu HTTPS-ühendused ja suunab päringud õigele konteinerile. Nginx võib ise olla konteineris või hostis.
2. Rakendus konteineris — oma versioonidega, ilma et see segaks teisi.
3. Andmebaas — kas eraldi konteineris koos köitega või otse hostis. Kui andmeid on palju ja jõudlus on oluline, eelistan sageli andmebaasi hostis: seda on lihtsam jälgida, häälestada ja varundada.

Sama loogika kehtib ka raskemate komponentide puhul nagu Tomcat, Elasticsearch või OpenSearch — igaüks oma konteineris, selgelt piiritletud andmekaustadega.

Vana rakenduse viimine konteinerisse samm-sammult

Kõike korraga ümber teha ei ole vaja. Teen seda tavaliselt nii:

1. Kaardista, mis serveris päriselt töötab: versioonid, seadistused, ajastatud tööd, kus andmed asuvad.
2. Pane rakendus konteinerisse, andmebaas jääb esialgu samaks. Testi eraldi keskkonnas.
3. Lülita ümber, kui test on läbitud — vana paigaldus jääb tagavaraks.
4. Alles seejärel otsusta, kas andmebaas ja teised osad lähevad samuti konteineritesse.

Kui rakendus ise vajab sisulist uuendamist, vaata ka postitust vana tarkvara uuendamisest või uuesti ehitamisest ning teenust tarkvara uuendamine ja edasiarendus. Kui samaga kaasneb serveri vahetus, aitab serveri kolimise juhend.

Kui sinu serveris töötab Docker, mida keegi enam ei halda, või kaalud, kas rakendus tasuks konteinerisse viia, kirjuta mulle. Kirjelda paari lausega siin, mis serveris töötab — vastan ühe tööpäeva jooksul ja ütlen ausalt, kas konteinerid sinu olukorras midagi võidavad. Rohkem serverihalduse kohta leiad Linuxi serverite teenuselehelt.

Korduma kippuvad küsimused

Kas Docker teeb serveri kiiremaks?

Mitte märgatavalt. Konteineri lisakulu on väike, aga see ei ole jõudlusvõit. Docker on paigalduse ja hoolduse tööriist, mitte kiirendaja.

Kas andmebaas peaks olema konteineris?

Võib, kui andmed on köites ja varundus on korras. Suurema andmemahu ja kõrgemate nõudmiste korral eelistan sageli andmebaasi otse hostis.

Kas Docker Compose'ist piisab või on vaja Kubernetest?

Väikeettevõtte ühe serveri rakenduste jaoks piisab enamasti Docker Compose'ist. Kubernetes on mõistlik alles siis, kui servereid ja teenuseid on palju ning neid on vaja automaatselt skaleerida.

Kas konteinerid uuenevad ise?

Ei. Pilte tuleb regulaarselt uuendada ja konteinerid uuesti käivitada — see on üks esimesi asju, mille hoolduses kokku lepin.