Docker palvelimella: milloin kontit kannattavat
Kehittäjä sanoi ”laita se Dockeriin”, ja nyt palvelimella pyörii kuusi konttia, eikä kukaan tiedä tarkalleen, mitä kukin niistä tekee. Tai päinvastoin: sovellus asennettiin palvelimelle käsin vuosia sitten, ja jokainen päivitys pelottaa, koska kukaan ei muista, mistä kirjastoista ja asetuksista se riippuu.
Docker ei ole itsessään hyvä eikä huono. Se on työkalu, joka ratkaisee yhden tietyn ongelman — sovellus ja sen ympäristö kulkevat yhdessä — ja tuo mukanaan pari uutta. Alla kerron, milloin suosittelen sitä ja milloin en.
Lyhyt vastaus: Docker kannattaa, kun palvelimella on useita sovelluksia eri versiovaatimuksin, kun sovellus täytyy asentaa toistuvasti ja samalla tavalla tai kun vanha sovellus pitää eristää uudesta järjestelmästä. Yhdelle yksinkertaiselle sivustolle, jota kukaan ei päivitä, se tuo yleensä vain lisää monimutkaisuutta.
Milloin kontit oikeasti auttavat
- Useita sovelluksia, eri vaatimukset. Yksi tarvitsee vanhan Java- tai PHP-version, toinen uuden. Ilman kontteja se tarkoittaa versiosotkua palvelimella; kontissa jokaisella sovelluksella on oma ympäristönsä.
- Päivitys ja paluu. Uusi versio on uusi image. Jos jokin menee pieleen, käynnistät edellisen imagen ja olet minuuteissa takaisin lähtöpisteessä.
- Siirto. Kun sovellus on kontissa ja data selvästi erillään, siirto uudelle palvelimelle on paljon ennustettavampi. Sama pätee uuteen Ubuntu LTS -versioon siirryttäessä — isäntäjärjestelmän päivitys ei riko sovelluksen sisäisiä kirjastoja.
- Toistettava asennus. Kehitys-, testi- ja tuotantoympäristö rakennetaan saman kuvauksen pohjalta, ei käsin ”suunnilleen samanlaisiksi”.
Milloin Docker on vain lisämonimutkaisuutta
- Palvelimella on yksi yksinkertainen sovellus, joka toimii ja jota muutetaan harvoin.
- Kukaan ei valvo eikä päivitä kontteja. Kontti ei päivity itsestään — vanha image pysyy vanhana, vaikka isäntä olisi paikattu.
- Sovellus on tiukasti sidoksissa itse palvelimeen (laitteisto, tiedostojärjestelmä, erityiset palvelut), ja kontittaminen tarkoittaisi isoa uudelleentyötä ilman selvää hyötyä.
Mikä konttien myötä muuttuu
Päivitykset. Käyttöjärjestelmän lisäksi myös imaget pitää päivittää. Vanha latest-tagilla merkitty image, jota ei ole haettu uudelleen kuukausiin, voi sisältää yhtä vanhentunutta ohjelmistoa kuin laiminlyöty palvelin. Sovin aina, kuka päivittää imaget ja kuinka usein.
Varmuuskopiot — tässä tehdään eniten virheitä. Kontti on kertakäyttöinen, data ei saa olla. Tietokannan, ladattujen tiedostojen ja asetusten pitää olla volumeissa tai isännällä, ja varmuuskopioiden pitää kattaa juuri ne. Jos tietokanta elää kontissa ilman volumea, se katoaa kontin mukana. Varmuuskopioin tietokannan aina sen omalla työkalulla (esimerkiksi PostgreSQL- tai MySQL/MariaDB-dump), en kopioimalla volumen tiedostoja kesken käytön.
Lokit. Konttien lokit pitää ohjata paikkaan, jossa niitä voi lukea ja jossa ne eivät täytä levyä. Muuten löydät puolen vuoden päästä gigatavuittain lokeja, joita kukaan ei ole katsonut.
Tietoturva. Kontti ei ole itsessään turvaraja. Älä aja sovellusta root-käyttäjänä, älä avaa tietokannan porttia julkisesti äläkä laita salasanoja imageen. Itse palvelimen suojaaminen pysyy samana — katso myös Linux-palvelimen suojaamisen tarkistuslista.
Tyypillinen rakenne
Pienyrityksen sovelluksessa käytän yleensä tätä mallia:
- Nginx edessä — ottaa vastaan HTTPS-yhteydet ja ohjaa pyynnöt oikealle kontille. Nginx voi itse olla kontissa tai isännällä.
- Sovellus kontissa — omilla versioillaan, häiritsemättä muita.
- Tietokanta — joko omassa kontissaan volumen kanssa tai suoraan isännällä. Kun dataa on paljon ja suorituskyky on tärkeä, suosin usein tietokantaa isännällä: sitä on helpompi valvoa, säätää ja varmuuskopioida.
Sama logiikka pätee raskaampiin osiin, kuten Tomcatiin, Elasticsearchiin tai OpenSearchiin — kukin omassa kontissaan selvästi rajatuin datakansioin.
Vanhan sovelluksen siirto kontteihin vaihe vaiheelta
Kaikkea ei tarvitse tehdä uudelleen kerralla. Teen sen yleensä näin:
- Kartoitan, mitä palvelimella oikeasti pyörii: versiot, asetukset, ajastetut työt, missä data on.
- Laitan sovelluksen konttiin, tietokanta pysyy toistaiseksi ennallaan. Testaan erillisessä ympäristössä.
- Vaihdan, kun testit menevät läpi — vanha asennus jää varalle.
- Vasta sitten päätetään, siirtyvätkö tietokanta ja muut osat myös kontteihin.
Jos sovellus itse tarvitsee varsinaista uudistamista, katso myös kirjoitus vanhan ohjelmiston modernisoinnista tai uusimisesta ja palvelu ohjelmistojen modernisointi. Jos samalla vaihtuu palvelin, apuna on palvelimen siirron opas.
Jos palvelimellasi pyörii Docker, jota kukaan ei enää ylläpidä, tai mietit, kannattaako sovellus kontittaa, kirjoita minulle. Kerro parilla lauseella täällä, mitä palvelimella pyörii — vastaan yhden arkipäivän kuluessa ja sanon rehellisesti, hyötyisitkö konteista. Lisää palvelinten ylläpidosta löydät Linux-palvelinten ylläpidon sivulta.
Usein kysytyt kysymykset
Tekeekö Docker palvelimesta nopeamman?
Ei huomattavasti. Kontin lisäkuorma on pieni, mutta se ei ole suorituskykyhyöty. Docker on asennuksen ja ylläpidon työkalu, ei kiihdytin.
Pitäisikö tietokannan olla kontissa?
Voi olla, kun data on volumessa ja varmuuskopiot ovat kunnossa. Suuremmilla datamäärillä ja korkeammilla vaatimuksilla suosin usein tietokantaa suoraan isännällä.
Riittääkö Docker Compose vai tarvitaanko Kubernetes?
Pienyrityksen yhden palvelimen sovelluksiin Docker Compose riittää yleensä. Kubernetes on järkevä vasta, kun palvelimia ja palveluja on paljon ja niitä pitää skaalata automaattisesti.
Päivittyvätkö kontit itse?
Eivät. Imaget pitää päivittää säännöllisesti ja kontit käynnistää uudelleen — se on yksi ensimmäisistä asioista, joista ylläpitosopimuksessa sovin.
