Kontitettu sovellus tarvitsee sopivan käyttömallin. Docker Compose voi riittää tuotantopalvelulle, jonka monimutkaisuus on hallittavissa. Kubernetesia kannattaa arvioida, kun sovellusten on toimittava useilla koneilla ja käyttöönotto tarvitsee koordinoitua ohjausta. Päätös alkaa sovelluksen vaatimuksista.
Yksi yritys käyttää sisäistä portaalia, johon kuuluvat verkkokäyttöliittymä, tietokanta ja taustakäsittely. Sillä on huoltoikkuna, hallittava kuorma ja nimetty ylläpitäjä. Toinen yritys julkaisee useiden palvelujen uusia versioita monta kertaa viikossa ja tarvitsee käytettävyyttä myös suunnitellun huollon aikana. Molemmat käyttävät kontteja, mutta niille voivat sopia erilaiset käyttömallit.
Dockerilla, Composella ja Kubernetesilla on eri tehtävät
Konttien suoritusympäristö suorittaa kontit. Docker Engine on tähän laajalti käytetty alusta. Docker Compose kuvaa sovelluksen palvelut YAML-tiedostossa. Siihen voidaan koota konttikuvat, verkot, pysyvät taltiot ja asetukset. Compose-työkalut luovat ja hallitsevat sovelluksen sillä Docker-isännällä, johon ne on yhdistetty.
Kubernetes hallitsee työkuormien tavoitetilaa klusterissa. Se sijoittaa Podit sopiville solmuille ja voi korvata hallittuja instansseja tai päivittää niitä vaiheittain. Jokainen solmu tarvitsee edelleen sopivan konttien suoritusympäristön. Compose-tiedosto ja Kubernetes-resurssit kuvaavat käyttöönoton eri tavoin, joten migraatio on muutakin kuin tiedoston uudelleennimeäminen.
Yrityksen koko kertoo päätöksestä vähän. Pieni ohjelmistotiimi, jolla on usein julkaisuja, voi hyötyä orkestroinnista. Paljon suuremmalle yritykselle yksi asianmukaisesti ylläpidetty isäntä voi olla hyvä ratkaisu yhden tuetun liiketoimintasovelluksen palveluun.
Docker Compose on tarkoitettu myös tuotantokäyttöön
Docker dokumentoi Composen käytön tuotannossa nimenomaisesti, erityisesti yhdellä palvelimella. Kehitys- ja tuotantoasetukset voidaan erottaa tai niitä voidaan täydentää tarpeen mukaan. Uudelleenkäynnistyskäytäntöjen, julkaistujen porttien, lokituksen ja päivitysprosessin on sovittava tuotantoympäristöön.
Sisäiselle asiakirjaportaalille tämä voi olla selkeä järjestely: hallittava palvelujoukko, dokumentoidut versiot, suojatut tiedot ja testattu palautus. Isäntäkoneen vikaantuminen tarvitsee silti erillisen suunnitelman. Uudelleenkäynnistyskäytäntö ei siirrä sovellusta toiselle koneelle. Myös taustalla olevan virtualisointialustan redundanssi ja sovelluksen varmuuskopiot ovat eri kerroksia.
Myös ohjelmistotoimittajan tukema asennustapa merkitsee. Virallisesti ylläpidetty Compose-käyttöönotto voi olla ylläpidossa arvokkaampi kuin oma klusteriasennus ilman luotettavaa päivityspolkua.
Päätösmatriisi ylläpitoon
| Kysymys | Docker Compose yhdellä isännällä | Kubernetes |
|---|---|---|
| Kuinka laaja ympäristö on? | Sopii yksittäisille sovelluksille, joissa palvelujoukko on hallittava. | Useita työkuormia ja solmuja voidaan hallita yhteisillä alustakäytännöillä. |
| Mitä isäntäkoneen vikaantuessa tapahtuu? | Palautus tai infrastruktuurin redundanssi järjestetään Composen ulkopuolella. | Korvaaminen muilla solmuilla on mahdollista, kun sovellus, kapasiteetti, ohjaustaso ja pääsy tietoihin on valmisteltu siihen. |
| Miten julkaisut otetaan käyttöön? | Tarvittavat palvelut korvataan dokumentoidulla ja tarvittaessa automatisoidulla prosessilla. | Käyttöönottokäytännöt tukevat hallittuja julkaisuja. Tietomuutokset ja toiminnalliset testit tarvitsevat oman suunnitelman. |
| Mihin yritystiedot tallennetaan? | Taltioihin tai ulkoisiin palveluihin, joilla on omat varmuuskopiointi- ja palautusmenettelyt. | Pysyvään tallennukseen tai ulkoisiin palveluihin, joiden vikasietoisuus ja varmuuskopiointi on edelleen arvioitava. |
| Kuka ylläpitää alustaa? | Vastuu kattaa isännän, suoritusympäristön, konttikuvat ja sovelluksen. | Lisäksi vastuuseen kuuluvat klusteri, verkko- ja tallennusintegraatiot sekä niiden elinkaaret. |
| Miten palvelun tila arvioidaan? | Isäntää, palveluja ja liiketoimintaprosesseja valvotaan. | Myös klusteria ja alustakomponenttien yhteistoimintaa valvotaan; pelkkä käynnissä oleva Pod ei riitä. |
| Mitä toimittaja tukee? | Tuettu asennustapa ja sen päivityspolku ratkaisevat. | Ylläpidettävän Kubernetes-käyttöönoton ja sopivan toimittajatuen on oltava saatavilla. |
Milloin Kubernetes tarjoaa konkreettista hyötyä
Hyvä peruste voi olla tarve hallita monia samankaltaisia käyttöönottoja yhtenäisesti tai jakaa laskentakapasiteettia useiden palvelujen kesken. Myös usein toistuvat päivitykset selkeillä julkaisukäytännöillä ja eri sovellusalueiden erillisillä vastuilla voivat puoltaa sitä. Tämä edellyttää sovellusta, joka toimii useina instansseina, sekä ihmisiä, jotka hallitsevat alustan lisätyön.
Selvitä ennen palvelun valintaa, ylläpitääkö tarjoaja ohjaustasoa, mitä komponentteja ylläpidät itse ja mitkä häiriötilanteen tehtävät jäävät sinulle. Hallittu klusteri vähentää tiettyjä alustatehtäviä. Vastuu sovelluksista, käyttöoikeuksista, tiedoista ja kustannuksista säilyy.
Oletukset jaetuista tiedoista ovat yleinen kompastuskivi. Toimiiko liiketoimintasovellus useilla aktiivisilla instansseilla? Mihin se kirjoittaa tiedostoja? Missä istunnot säilyvät? Voiko taustatehtävän suorittaa turvallisesti uudelleen? Näihin kysymyksiin on vastattava ennen migraatiota. Tavoitettava kontti ei osoita, että tilaukset käsitellään oikein.
Työ kattaa koko elinkaaren
Pelkkä palvelin- tai pilvilasku ei riitä vertailuun. Myös toteutus, dokumentointi, päivitykset, valvonta, varmuuskopiot ja häiriöihin käytetty aika lasketaan mukaan. Kubernetes vaatii lisäksi alustaosaamista sekä klusteri-, verkko- ja tallennuskomponenttien yhteensovittamista. Vakioitu ylläpito voi vähentää toistuvaa työtä, mutta standardi on ensin luotava ja pidettävä ajan tasalla.
Hyödyllinen kustannusvertailu sisältää kolme vaihtoehtoa: nykyisen sovelluksen asianmukaisen ylläpidon jatkaminen, vakiointi Composelle tai Kubernetes-alustan käyttöönotto. Käytä samoja liiketoimintavaatimuksia jokaisessa vaihtoehdossa. Muuten yksittäistä yksinkertaista palvelinta verrataan helposti paljon korkeampaan käytettävyystavoitteeseen selittämättä eroa.
Näin syntyy perusteltu päätös
- Määritä käyttövaatimukset: kuvaa hyväksyttävät katkokset, huoltoikkunat, tietohävikki ja odotettavat muutokset.
- Arvioi sovellus: kirjaa tuetut asennustavat, monen instanssin tuki, tiedostot, istunnot ja ulkoiset rajapinnat.
- Jaa vastuut: nimeä huollosta, hälytyksistä, palautuksesta ja poissaolojen sijaisuuksista vastaavat henkilöt.
- Testaa yksi palvelu: harjoittele ehdotetussa ympäristössä päivitys, vika ja palautus sekä dokumentoi työmäärä.
- Laajenna vasta sen jälkeen: arvioi muut sovellukset samoilla kriteereillä.
DAXS yhdistää sovelluksen ja sen rajapintojen arvioinnin infrastruktuurin suunnitteluun ja sopivaan ylläpitomalliin. Alkuarvioon riittävät konkreettinen palvelu, sen riippuvuudet ja tarvittavat toiminnalliset tulokset. Henkilökohtainen keskustelu alkaa tästä.
Lähteet: Docker: Composen sovellusmalli · Docker Compose tuotannossa · Kubernetes: komponentit ja vastuut · Kubernetes: Deploymentit ja vaiheittaiset käyttöönotot · Kubernetes-tuotantoympäristön suunnittelu
