Kuinka tulla DevOps-insinööriksi kuudessa kuukaudessa tai vähemmän, osa 4: Paketti

Chuttersnap “Packages” on Unsplash

Nopea kertaus

Osassa 1 puhuimme DevOps-kulttuurista ja tarvittavista perusteista:

Osassa 2 keskustelimme siitä, miten luodaan perustan tuleville koodin käyttöönottoille:

Osassa 3 puhuimme siitä, kuinka käyttöönotetut koodisi voidaan järjestää:

Tässä puhutaan siitä, kuinka koodata koodi helppoa käyttöönottoa ja myöhempää suoritusta varten.

Viitteeksi siitä, että olemme täällä matkallamme:

Paketti

HUOMAUTUS: Voit nähdä, kuinka jokainen osa rakentuu edelliselle osalle ja asettaa perustan seuraavalle osalle. Tämä on tärkeää ja tehdään tarkoituksella.

Syynä on, että puhutte sitten nykyisten tai tulevien työnantajien kanssa, sinun on kyettävä kertomaan, mikä DevOps on ja miksi se on tärkeää.

Ja teet niin kertomalla johdonmukaisen tarinan - tarinan kuinka nopeasti ja tehokkaasti lähettää koodi kehittäjän kannettavasta tietokoneesta rahaa tuottavan tuotteen käyttöönottoon.

Siksi emme ole oppineet joukko irrotettuja, trendikkäitä DevOps-työkaluja. Olemme opiskelleet joukon taitoja, joita liiketoiminnan tarpeet ohjaavat ja joita tukevat tekniset työkalut.

Ja muista, että jokainen vaihe on noin kuukauden mittainen oppiminen, yhteensä kuusi kuukautta.

Okei, riittää juttelua, päästämme siihen!

Pohjustus virtualisoinnista

Muistatko fyysiset palvelimet? Ne, jotka jouduit odottamaan viikkoja saadaksesi PO-hyväksynnän, lähettämisen, tietokeskuksen hyväksymisen, telakoinnin, verkottamisen, käyttöjärjestelmän asentamisen ja korjaamisen?

Kyllä, ne. He tulivat ensin.

Periaatteessa kuvittele, jos ainoa tapa saada asuinpaikka on rakentaa uusi talo. Tarvitsetko asuinpaikkaa? Odota kuinka kauan se vie! Tavallaan siistiä, koska kaikki saavat talon, mutta ei oikeastaan, koska talon rakentaminen vie kauan. Tässä analogiassa fyysinen palvelin on kuin talo.

Sitten ihmiset ärsyivät siitä, kuinka kauan kaikki kesti, ja jotkut todella älykkäät ihmiset keksivät ajatuksen virtualisoinnista: kuinka ajaa joukko teeskennellä “koneita” yhdellä fyysisellä koneella ja saada jokainen väärennetty kone teeskentelemään todellinen kone. Nero!

Joten, jos halusit todella taloa, voit rakentaa oman ja odottaa kuusi viikkoa. Tai voit mennä asumaan kerrostalossa ja jakaa resursseja muiden vuokralaisten kanssa. Ehkä ei niin mahtava, mutta tarpeeksi hyvä! Ja mikä tärkeintä, ei ole odotettavissa!

Tämä jatkui jonkin aikaa, ja yritykset (ts. VMWare) tappoivat sen ehdottomasti.

Ennen kuin muut älykkäät ihmiset päättivät, että joukon virtuaalikoneita ei tarvitse täyttää fyysiseen koneeseen, se ei ole tarpeeksi hyvä: tarvitsemme kompaktaisemman pakkauksen useammista prosesseista vähemmän resursseja.

Tässä vaiheessa talo on liian kallis ja huoneisto on edelleen liian kallis. Entä jos tarvitsen vain vuokratavan huoneen väliaikaisesti? Se on ihmeellistä, voin liikkua sisään ja ulos hetkessä!

Pohjimmiltaan se on Docker.

HUOMAUTUS: Joulukuusta 2018 alkaen

Dockerin syntymä

Docker on uusi, mutta idea Dockerin takana on hyvin vanha. FreeBSD-nimisessä käyttöjärjestelmässä oli vankiloiden käsite, joka juontaa juurensa 2000! Todella kaikki uusi on vanhaa.

Ideana silloin ja nyt oli eristää yksittäiset prosessit samassa käyttöjärjestelmässä, ns. ”Käyttöjärjestelmätason virtualisointi”.

HUOMAUTUS: Tämä ei ole sama asia kuin ”täydellinen virtualisointi”, joka suorittaa virtuaalikoneita rinnakkain samassa fyysisessä koneessa.

Mitä tämä tarkoittaa käytännössä?

Käytännössä tämä tarkoittaa, että Dockerin suosion nousu heijastaa siististi mikropalvelujen nousua - ohjelmistosuunnittelumenetelmää, jossa ohjelmisto hajoaa moniin yksittäisiin komponentteihin.

Ja nämä komponentit tarvitsevat kodin. Niiden käyttöönotto erikseen erillisinä Java-sovelluksina tai binaarisina suoritettavina tiedostoina on valtava tuska: Java-sovelluksen hallitseminen eroaa siitä, miten hallitset C ++ -sovellusta, ja erilainen kuin hallitset Golang-sovellusta.

Sen sijaan Docker tarjoaa yhden hallintarajapinnan, jonka avulla ohjelmistosuunnittelijat voivat pakata (!), Ottaa käyttöön ja käyttää erilaisia ​​sovelluksia johdonmukaisella tavalla.

Se on valtava voitto!

OK, puhutaanpa enemmän Dockerin eduista ja haitoista.

Dockerin edut

Prosessin eristäminen

Docker mahdollistaa kaikkien palveluiden täydellisen prosessieristyksen. Palvelu A asuu omassa pienessä kontissaan kaikilla riippuvuuksillaan. Palvelu B asuu kontinsa, kaikki riippuvuudet. Ja nämä kaksi eivät ole ristiriidassa!

Lisäksi jos yksi säiliö kaatuu, se vaikuttaa vain siihen. Loput jatkavat (pitäisi!) Jatkaa juoksemista onnellisina.

Tämä hyödyttää myös turvallisuutta. Jos säiliö on vaarantunut, on erittäin vaikeaa (mutta ei mahdotonta!) Päästä pois siitä säiliöstä ja hakkeroida perusjärjestelmä.

Viimeinkin, jos säiliö toimii huonosti (kuluttaa liian paljon prosessoria tai muistia), on mahdollista “sisältää” räjähdyssäde vain siihen säiliöön vaikuttamatta muuhun järjestelmään.

käyttöönotto

Ajattele kuinka erilaiset sovellukset rakennetaan käytännössä.

Jos se on Python-sovellus, siinä on joukko erilaisia ​​Python-paketteja. Jotkut asennetaan pip-moduuleiksi, toiset ovat rpm tai deb-paketteja, ja toiset ovat yksinkertaisia ​​git-klooni-asennuksia. Tai, jos se tehdään virtualenvin kanssa, se on zip-tiedosto kaikista virtualenv-hakemiston riippuvuuksista.

Toisaalta, jos se on Java-sovellus, siinä on rypälerakenne, jossa kaikki riippuvuudet vedetään ja sirotellaan sopiviin paikkoihin.

Saat pisteen. Erilaiset sovellukset, rakennukset eri kielillä ja erilaiset käyttöajat muodostavat haasteen näiden sovellusten käyttöönotolle tuotantoa varten.

Kuinka voimme pitää kaikki riippuvuudet tyytyväisinä?

Lisäksi ongelma on pahempaa, jos on konflikteja. Entä jos palvelu A riippuu Python-kirjastosta v1, mutta palvelu B riippuu Python-kirjastosta v2? Nyt on ristiriita, koska sekä v1 että v2 eivät voi esiintyä samanaikaisesti samassa koneessa.

Kirjoita Docker.

Docker mahdollistaa prosessien täydellisen eristämisen, mutta myös täydellisen riippuvuuden eristämisen. On täysin mahdollista ja yleistä, että useat säilytysastiat kulkevat vierekkäin samassa käyttöjärjestelmässä, jokaisella on omat ja ristiriitaiset kirjastot ja paketit.

Runtime Management

Tapa, kuinka hallitsemme erilaisia ​​sovelluksia, eroaa taas sovelluksista. Java-koodi lokit eri tavalla, käynnistetään eri tavoin ja seurataan eri tavalla kuin Python. Ja Python eroaa Golangista jne.

Dockerin avulla saamme yhden, yhtenäisen hallintarajapinnan, jonka avulla voimme käynnistää, seurata, keskittää lokit, pysäyttää ja käynnistää monenlaisia ​​sovelluksia.

Tämä on valtava voitto ja vähentää huomattavasti käynnissä olevien tuotantojärjestelmien toimintakustannuksia.

HUOMAUTUS: Joulukuusta 2018 alkaen sinun ei enää tarvitse tehdä valintaa Dockerin nopean käynnistyksen ja automaattisen automaation suojauksen välillä. Projekti Firecracker, joka on Amazonin suostu, yrittää sulauttaa molempien maailmojen parhaat puolet. Tämä on silti hyvin uusi tekniikka, jota ei pidä ottaa käyttöön vielä tuottamaan.

Kuitenkin niin mahtava kuin Docker, sillä on myös epäkohtia.

Kirjoita Lambda

Ensinnäkin, Dockerin suorittaminen on edelleen palvelimien käynnissä. Palvelimet ovat hauraita ja hiutaleita. Niitä on hallittava, korjattava ja muuten hoidettava.

Toiseksi, Docker ei ole 100% turvallinen. Ei ainakaan kuten VM. On syytä, miksi isäntäkontteja ajavat valtavat yritykset tekevät niin VM: ssä, eivät paljaan metallin päällä. He haluavat nopeita konttien käynnistysaikoja ja automaattien turvallisuutta!

Kolmanneksi, kukaan ei oikeastaan ​​aja Dockeria sellaisena kuin se on. Sen sijaan sitä käytetään lähes aina osana monimutkaista konttiorkesterikangasta, kuten Kubernetes, ECS, docker-swarm tai Nomad. Nämä ovat melko monimutkaisia ​​alustoja, jotka vaativat omistautunutta henkilöstöä toimimaan (lisää näistä ratkaisuista myöhemmin).

Jos olen kuitenkin kehittäjä, haluan vain kirjoittaa koodin ja pyytää joku muu käyttämään sitä minulle. Docker, Kubernetes ja kaikki tuo jazz eivät ole yksinkertaisia ​​opittavaa asioita - pitääkö minun todellakin tehdä?!

Lyhyt vastaus on, se riippuu!

Ihmisille, jotka vain haluavat jonkun muun suorittavan koodinsa, AWS Lambda (ja muut sen kaltaiset ratkaisut) ovat vastaus:

AWS Lambda antaa sinun suorittaa koodia ylläpitämättä tai hallitsemalla palvelimia. Maksat vain kulutustasi laskennallisesta ajasta - maksua ei tarvita, kun koodisi ei ole käynnissä.

Jos olet kuullut koko "palvelimettomasta" liikkeestä, niin se on! Ei enää suoritettavia palvelimia tai hallittavissa olevia säilöjä. Kirjoita vain koodi, pakata se zip-tiedostoon, lähetä Amazoniin ja anna heidän hoitaa päänsärky!

Lisäksi, koska lambdat ovat lyhytaikaisia, siinä ei ole mitään hakkerointia - lambdat ovat suunnittelusta melko varmoja.

Hienoa, eikö niin?

On, mutta (yllätys!) On huomautuksia.

Ensinnäkin Lambdas voi ajaa enintään 15 minuuttia (marraskuusta 2018 alkaen). Tämä tarkoittaa, että pitkät käynnissä olevat prosessit, kuten Kafkan kuluttajat tai numeroiden murskaussovellukset, eivät voi toimia Lambdassa.

Toiseksi, lambdat ovat funktioita palveluna, mikä tarkoittaa, että sovelluksesi on hajotettava kokonaan mikropalveluiksi ja organisoitava muiden monimutkaisten PaaS-palveluiden, kuten AWS Step Functions, kanssa. Kaikki yritykset eivät ole tällä mikropalveluarkkitehtuurin tasolla.

Kolmanneksi Lambdan vianmääritys on vaikeaa. Ne ovat pilvi-luontaisia ​​juoksuaikoja, ja kaikki virheiden korjaukset tapahtuvat Amazonin ekosysteemissä. Tämä on usein haastavaa ja ei-intuitiivista.

Lyhyesti sanottuna ei ole ilmaista lounasta.

HUOMAUTUS: Nyt on olemassa myös "palvelimettomia" pilvisäiliöratkaisuja. AWS Fargate on yksi tällainen lähestymistapa. Mekaniikka on suurelta osin samanlainen. Itse asiassa, jos olet vasta aloittamassa, suosittelen todella Fargagen kokeilua - se on uskomattoman helppo tapa saada kontteja toimimaan "oikealla tavalla".

PÄIVITYS 13.1.2019: AWS ilmoitti juuri Fargaten merkittävästä hinnanalennuksesta, mikä tekee siitä nyt erittäin houkuttelevan valinnan "palvelimettomien" konttien ajamiseen.

Yhteenveto

Docker ja Lambda ovat kaksi suosituinta nykyaikaista pilvimaista lähestymistapaa pakkaamiseen, tuotannon sovellusten ajamiseen ja hallintaan.

Ne ovat usein ilmaisia, joista kukin soveltuu hieman erilaisiin käyttötapoihin ja sovelluksiin.

Siitä huolimatta nykyaikaisen DevOps-insinöörin on oltava hyvin perehtynyt molempiin. Siksi Dockerin ja Lambdan oppiminen ovat hyviä lyhyen ja keskipitkän aikavälin tavoitteita.

HUOMAUTUS: Tähän mennessä sarjaamme on käsitelty aiheita, jotka nuorten ja keskitason DevOps-insinöörien odotetaan tietävän. Seuraavissa osissa aloitamme keskustelun tekniikoista, jotka sopivat paremmin keskitason ja vanhempien DevOps-insinöörien kesken. Kuten aina, kokemukseen ei kuitenkaan ole pikakuvakkeita!

Seuraava

Lue kaikki nykyaikaisista käyttöönoton parhaista käytännöistä lukemalla!