{"id":33654,"date":"2019-10-31T21:53:58","date_gmt":"2019-10-31T18:53:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/deploj-prilozhenij-v-vm-nomad-i-kubernetes\/"},"modified":"2019-10-31T21:53:58","modified_gmt":"2019-10-31T18:53:58","slug":"deploj-prilozhenij-v-vm-nomad-i-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","title":{"rendered":"Distribusjon av applikasjoner til VM, Nomad og Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hei alle sammen! Jeg heter Pavel Agaletksy. Jeg jobber som teamleder i gruppen som utvikler Lamoda's leveringssystem. I 2018 deltok jeg p\u00e5 konferansen HighLoad++, og i dag \u00f8nsker jeg \u00e5 presentere transkripsjonen av mitt foredrag.<\/p>\n

Temaet mitt handler om erfaringene v\u00e5re med \u00e5 distribuere systemer og tjenester til ulike milj\u00f8er. Fra de f\u00f8rste tidene v\u00e5re, da vi distribuerte alle systemene til vanlige virtuelle servere, til den gradvise overgangen fra Nomad til distribusjon i Kubernetes. Jeg vil fortelle om hvorfor vi gjorde det og hvilke problemer vi m\u00f8tte underveis.<\/p>\n

\r\n \"Spill\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

Distribusjon av applikasjoner p\u00e5 VM<\/h1>\n

\nLa oss begynne med at for 3 \u00e5r siden ble alle systemene og tjenestene i selskapet distribuert p\u00e5 vanlige virtuelle servere. Teknisk sett var det lagt til rette slik at all koden for systemene v\u00e5re ble plassert og bygget ved hjelp av automatisert bygging, med jenkins. Gjennom Ansible ble det rullet ut fra v\u00e5rt versjonskontrollsystem til de virtuelle serverne. Hver av systemene i selskapet ble distribuerte minst p\u00e5 to servere: den ene p\u00e5 head, den andre p\u00e5 tail. Disse to systemene var helt identiske n\u00e5r det gjaldt alle innstillinger, kapasitet, konfigurasjon og s\u00e5 videre. Forskjellen mellom dem var bare at head-mottok brukertrafikk, mens tail aldri fikk brukertrafikk. <\/p>\n

Hva var hensikten med dette? <\/p>\n

N\u00e5r vi distribuerte nye versjoner av applikasjonen v\u00e5r, \u00f8nsket vi \u00e5 sikre s\u00f8ml\u00f8s utrulling, det vil si uten merkbare konsekvenser for brukerne. Dette ble oppn\u00e5dd ved at den nyeste bygde versjonen ble rullet ut til tail ved hjelp av Ansible. Der kunne folk som jobbet med distribusjonen sjekke og forsikre seg om at alt fungerte: alle m\u00e5linger, seksjoner og applikasjoner var operative; n\u00f8dvendige skript ble kj\u00f8rt. F\u00f8rst etter at de forsikret seg om at alt var i orden, ble trafikken omdirigert. Den begynte \u00e5 g\u00e5 til den serveren som tidligere var tail. Og serveren som tidligere var head, forble uten brukertrafikk, men med den eksisterende eldre versjonen av applikasjonen v\u00e5r.<\/p>\n

Dermed var det s\u00f8ml\u00f8st for brukerne. Fordi overgangen er \u00f8yeblikkelig, ettersom det bare er en bytte av lastbalansereren. Det er veldig enkelt \u00e5 rulle tilbake til forrige versjon ved \u00e5 bare bytte lastbalansereren tilbake. Vi kunne ogs\u00e5 bekrefte applikasjonens evne til produksjon f\u00f8r brukertrafikken kom inn, noe som var ganske praktisk. <\/p>\n

Hva s\u00e5 vi som fordeler med alt dette?<\/p>\n

    \n
  1. F\u00f8rst og fremst er det enkelthen som fungerer.<\/b> Alle forst\u00e5r hvordan en slik distribusjonsordning fungerer, fordi de fleste har deployert p\u00e5 vanlige virtuelle servere.<\/li>\n
  2. Det er relativt<\/b>sikkert, ettersom distribusjonsteknologien er enkel og har blitt testet av tusenvis av selskaper. Millioner av servere distribueres p\u00e5 denne m\u00e5ten. Det er vanskelig \u00e5 bryte noe. <\/li>\n
  3. Og til slutt kunne vi f\u00e5 atom\u00e6re distribusjoner.<\/b>Distribusjoner som skjer \u00f8yeblikkelig for brukere, uten merkbare mellomtrinn mellom den gamle versjonen og den nye. <\/li>\n<\/ol>\n

    \nMen i alt dette s\u00e5 vi ogs\u00e5 noen ulemper: <\/p>\n

      \n
    1. I tillegg til produksjonsmilj\u00f8et og utviklingsmilj\u00f8et, finnes det ogs\u00e5 andre milj\u00f8er. For eksempel QA og preproduksjon. P\u00e5 den tiden hadde vi mange servere og rundt 60 tjenester. Derfor m\u00e5tte vi oppdatere den gjeldende versjonen <\/b>av den virtuelle maskinen for hver tjeneste. Og hvis du vil oppdatere biblioteker eller installere nye avhengigheter, m\u00e5 du gj\u00f8re det i alle milj\u00f8ene. Det var ogs\u00e5 n\u00f8dvendig \u00e5 synkronisere tidspunktet du planlegger \u00e5 distribuere den nye versjonen av applikasjonen din med tidspunktet devops-teamet ville utf\u00f8re de n\u00f8dvendige milj\u00f8innstillingene. I slike tilfeller er det lett \u00e5 havne i en situasjon der milj\u00f8et v\u00e5rt varierer noe mellom alle milj\u00f8ene. For eksempel kan det v\u00e6re \u00e9n versjon av bibliotekene i QA-milj\u00f8et, mens det er en annen i produksjon, noe som vil f\u00f8re til problemer. <\/li>\n
    2. Vanskeligheten med \u00e5 oppdatere avhengighetene<\/b> til applikasjonen din. Dette avhenger ikke av deg, men av et annet team. Nemlig devops-teamet som vedlikeholder serverne. Du m\u00e5 gi dem en passende oppgave og beskrive hva du \u00f8nsker \u00e5 oppn\u00e5.<\/li>\n
    3. P\u00e5 den tiden \u00f8nsket vi ogs\u00e5 \u00e5 dele de store monolittene v\u00e5re opp i separate sm\u00e5 tjenester, ettersom vi forsto at antallet bare ville \u00f8ke. P\u00e5 det tidspunktet hadde vi allerede over 100 av dem. Det var n\u00f8dvendig \u00e5 opprette en ny virtuell maskin for hver ny tjeneste, som ogs\u00e5 m\u00e5tte vedlikeholdes og distribueres. I tillegg trengte vi ikke bare \u00e9n maskin, men minst to. P\u00e5 toppen av det hele m\u00e5tte vi ogs\u00e5 ha et QA-milj\u00f8. Dette skaper problemer og gj\u00f8r opprettelsen og lanseringen av nye systemer mer komplisert, kostbart og tidkrevende.<\/b><\/li>\n<\/ol>\n

      \nDerfor besluttet vi at det ville v\u00e6re mer praktisk \u00e5 g\u00e5 fra \u00e5 distribuere vanlige virtuelle maskiner til \u00e5 distribuere appene v\u00e5re i en Docker-container. Med Docker trenger man et system som kan kj\u00f8re applikasjonen i et klynge, siden man ikke bare kan l\u00f8fte en container. Man vil vanligvis overv\u00e5ke hvor mange containere som er oppe, for at de skal starte automatisk. Av den grunn m\u00e5tte vi velge et administrasjonssystem. <\/p>\n

      Vi har tenkt mye over hvilke vi kan bruke. Saken er at p\u00e5 det tidspunktet var deploy-stacken for vanlige virtuelle servere litt utdatert, siden det var ikke de nyeste versjonene av operativsystemene. P\u00e5 et tidspunkt hadde vi til og med FreeBSD, som var litt upraktisk \u00e5 vedlikeholde. Vi forsto at vi m\u00e5tte migrere til Docker s\u00e5 raskt som mulig. V\u00e5re DevOps s\u00e5 p\u00e5 sin eksisterende erfaring med forskjellige l\u00f8sninger og valgte et system som Nomad. <\/p>\n

      Overgangen til Nomad<\/h1>\n

      \nNomad er et produkt fra selskapet \u201cHashiCorp\u201d. De er ogs\u00e5 kjent for sine andre l\u00f8sninger:<\/p>\n

      \"Distribusjon
      \n
      \n\u00abConsul\u00bb<\/b> \u2014 et verkt\u00f8y for tjenesteregistrering.<\/p>\n

      \u00abTerraform\u00bb<\/b> \u2014 et system for serveradministrasjon som lar deg konfigurere dem via kode, s\u00e5kalt infrastruktur-som-kode.<\/p>\n

      \u00abVagrant\u00bb<\/b> lar deg distribuere virtuelle maskiner lokalt eller i skyen ved hjelp av spesifikke konfigurasjonsfiler. <\/p>\n

      Nomad virket p\u00e5 den tiden som en ganske enkel l\u00f8sning som man raskt kunne g\u00e5 over til uten \u00e5 endre hele infrastrukturen. I tillegg er det lett \u00e5 l\u00e6re. Derfor valgte vi det som v\u00e5rt system for filtrering av containere. <\/p>\n

      Hva trenger man for egentlig \u00e5 distribuere systemet ditt i Nomad? <\/p>\n

        \n
      1. F\u00f8rst og fremst trenger man docker image<\/b> din applikasjonen. Det er n\u00f8dvendig \u00e5 bygge den og plassere den i et docker-bilde-lager. I v\u00e5rt tilfelle er dette artifactory \u2014 et system som lar deg laste opp ulike artefakter av forskjellige typer. Det kan lagre arkiver, docker-bilder, composer-pakker for PHP, NPM-pakker og s\u00e5 videre. <\/li>\n
      2. Det er ogs\u00e5 n\u00f8dvendig konfigurasjonsfilen<\/b>, som vil fortelle Nomad hva, hvor og i hvilken mengde du \u00f8nsker \u00e5 deployere. <\/li>\n<\/ol>\n

        \nN\u00e5r vi snakker om Nomad, bruker det HCL-spr\u00e5ket i som format for informasjonsfilen, som st\u00e5r for HashiCorp Configuration Language<\/i>. Dette er et oversett sett over Yaml som lar deg beskrive tjenestene dine i termer av Nomad. <\/p>\n

        \"Distribusjon
        \n
        \nDet lar deg angi hvor mange containere du \u00f8nsker \u00e5 deployere, fra hvilke bilder og hvilke forskjellige parametere du vil sende til dem under deployeringen. P\u00e5 denne m\u00e5ten gir du denne filen til Nomad, og den starter containerne i produksjon i samsvar med den. <\/p>\n

        I v\u00e5rt tilfelle har vi innsett at det ikke ville v\u00e6re veldig praktisk \u00e5 skrive helt identiske HCL-filer for hver tjeneste, fordi det er mange tjenester, og det kan noen ganger v\u00e6re n\u00f8dvendig \u00e5 oppdatere dem. Det hender at en tjeneste ikke er deployert i ett enkelt eksemplar, men i mange forskjellige. For eksempel har ett av systemene v\u00e5re i produksjon mer enn 100 instanser i produksjon. De kj\u00f8rer fra samme bilder, men har forskjellige konfigurasjonsinnstillinger og konfigurasjonsfiler. <\/p>\n

        Derfor bestemte vi oss for at det ville v\u00e6re praktisk \u00e5 lagre alle konfigurasjonsfilene v\u00e5re for deployering i et felles repository. P\u00e5 denne m\u00e5ten ble de mer oversiktlige: de var enkle \u00e5 vedlikeholde, og man kunne se hvilke systemer vi hadde. Ved behov kunne man ogs\u00e5 enkelt oppdatere eller endre noe. \u00c5 legge til et nytt system ville heller ikke v\u00e6re vanskelig \u2014 det er nok \u00e5 opprette en konfigurasjonsfil innenfor en ny mappe. Inne i den ligger filene: service.hcl, som inneholder beskrivelsen av tjenesten v\u00e5r, og noen env-filer som lar deg konfigurere denne tjenesten n\u00e5r den er deployert i produksjon. <\/p>\n

        \"Distribusjon
        \n
        \nImidlertid er noen av systemene v\u00e5re deployert i produksjon ikke i ett enkelt eksemplar, men i flere samtidig. Derfor bestemte vi oss for at det ville v\u00e6re mer praktisk \u00e5 lagre ikke konfigurasjonene i ren form, men i en malform. Som malingsspr\u00e5k valgte vi jinja 2<\/i>. I denne formen lagrer vi b\u00e5de konfigurasjoner for tjenesten og env-filer som den trenger. <\/p>\n

        I tillegg har vi plassert et felles deploy-script for alle prosjekter i depotet, som lar deg starte og deployere tjenesten din i produksjon, til \u00f8nsket milj\u00f8 og m\u00e5l. N\u00e5r vi konverterte v\u00e5r HCL-konfigurasjon til en mal, begynte HCL-filen som tidligere var en vanlig Nomad-konfigurasjon \u00e5 se litt annerledes ut.<\/p>\n

        \"Distribusjon
        \n
        \nDet vil si at vi har erstattet noen variable plasser i konfigurasjonen med innsettinger for variabler som hentes fra env-filer eller andre kilder. I tillegg har vi f\u00e5tt muligheten til \u00e5 generere HCL-filer dynamisk, slik at vi kan bruke ikke bare vanlige variable innsettinger. Siden jinja st\u00f8tter sl\u00f8yfer og betingelser, kan vi ogs\u00e5 lage konfigurasjonsfiler som endres avhengig av hvor du faktisk deployerer applikasjonene dine. <\/p>\n

        For eksempel, hvis du \u00f8nsker \u00e5 deployere tjenesten din til preproduksjon og produksjon. La oss si at i preproduksjonen \u00f8nsker du ikke \u00e5 kj\u00f8re cron-skript, men bare ser tjenesten p\u00e5 et eget domene for \u00e5 forsikre deg om at den fungerer. For alle som deployerer en tjeneste, ser prosessen veldig enkel og gjennomsiktig ut. Det er bare \u00e5 kj\u00f8re filen deploy.sh, angi hvilken tjeneste du \u00f8nsker \u00e5 deployere og til hvilket m\u00e5l. For eksempel, hvis du vil deployere et system til Russland, Hviterussland eller Kasakhstan. Da er det bare \u00e5 endre ett av parameterne, s\u00e5 blir riktig konfigurasjonsfil generert. <\/p>\n

        N\u00e5r Nomad-tjenesten allerede er deployert i klyngen din, ser den slik ut.<\/p>\n

        \"Distribusjon
        \n
        \nFor det f\u00f8rste trenger du en balancerer utenfor, som vil ta imot all brukertrafikken. Den vil jobbe sammen med Consul og sp\u00f8rre hvor, p\u00e5 hvilken node, hvilken IP-adresse<\/a> spesifikk tjeneste som samsvarer med det eller det domenenavnet ligger. Tjenester i Consul kommer fra Nomad selv. Siden de er produkter fra samme selskap, er de godt knyttet sammen. Man kan si at Nomad som standard kan registrere alle tjenester som kj\u00f8res i den i Consul. <\/p>\n

        N\u00e5r den eksterne balansef\u00f8reren har funnet ut hvilken tjeneste den skal sende trafikken til, omdirigerer den trafikken til den aktuelle beholderen eller flere beholdere som er relatert til applikasjonen din. Det er selvsagt n\u00f8dvendig \u00e5 tenke p\u00e5 sikkerheten ogs\u00e5. Selv om alle tjenester kj\u00f8rer p\u00e5 de samme virtuelle maskinene i beholdere, er det vanligvis n\u00f8dvendig \u00e5 forby fri tilgang fra en tjeneste til en annen. Dette oppn\u00e5dde vi gjennom segmentering. Hver tjeneste ble kj\u00f8rt i sitt eget virtuelle nettverk, hvor routingsregler og regler for tilgangsforbud\/ -tillatelse til andre systemer og tjenester var spesifisert. De kunne v\u00e6re b\u00e5de innenfor og utenfor denne klyngen. For eksempel, hvis du vil forby en tjeneste \u00e5 koble seg til en bestemt database, kan dette gj\u00f8res ved \u00e5 segmentere p\u00e5 nettverksniv\u00e5. Det vil si at du selv ved en feil ikke kan koble deg fra testmilj\u00f8et til produksjonsdatabasen din.<\/p>\n

        Hva kostet overgangen oss i menneskelige ressurser? <\/p>\n

        Overgangen av hele selskapet til Nomad tok omtrent 5-6 m\u00e5neder. Vi gjorde det tjenestevis, men i et tilstrekkelig raskt tempo. Hver gruppe m\u00e5tte lage sine egne beholdere for tjenestene. <\/p>\n

        Vi har en tiln\u00e6rming der hver gruppe er ansvarlig for docker-bildene til sine egne systemer. DevOps gir n\u00f8dvendig felles infrastruktur for distribusjon, alts\u00e5 st\u00f8tte for selve klyngen, st\u00f8tte for CI-systemet og s\u00e5 videre. P\u00e5 det tidspunktet hadde over 60 systemer migrert til Nomad, noe som resulterte i omtrent 2000 beholdere. <\/p>\n

        DevOps er ansvarlige for den felles infrastrukturen for alt relatert til distribusjon og servere. Hver utviklingsteam er igjen ansvarlig for implementeringen av beholdere for sitt spesifikke system, siden det er teamet som vet hva de faktisk trenger i den eller den beholderen.<\/p>\n

        \u00c5rsaker til \u00e5 forlate Nomad<\/h1>\n

        \nHvilke fordeler fikk vi ved \u00e5 g\u00e5 over til distribusjon ved hjelp av Nomad og Docker?<\/p>\n

          \n
        1. Vi vi sikret like forhold<\/b> for all environments. In development, QA environments, pre-production, and production, the same container images with the same dependencies are used. Consequently, you have almost no chance that what ends up in production is different from what you previously tested locally or in a test environment. <\/li>\n
        2. We also found that it is quite easy to add a new service<\/b>. Any new systems from a deployment perspective launch very simply. You just need to go to the repository storing the configs, add another config for your system there, and you are ready. You can deploy your system to production without any additional efforts from DevOps. <\/li>\n
        3. Alle configuration files<\/b> in a common repository turned out to be reviewable<\/b>. At the moment we deployed our systems using virtuelle servere<\/a>, we used Ansible, where the configs were stored in the same repository. However, it was somewhat more complicated for most developers to work with this. The amount of configs and code you need to add to deploy the service became much smaller. Plus, it is very easy for DevOps to fix or change it. In the case of transitions, for example, to a new version of Nomad, they can easily mass-update all operational files stored in the same place.<\/li>\n<\/ol>\n

          \nBut we also encountered several drawbacks: <\/p>\n

          It turned out that we could not achieve seamless deployments <\/b>in the case of Nomad. When rolling out containers from different conditions, it could happen that it was running, and Nomad recognized it as ready to accept traffic container. This happened even before the application inside it managed to start. For this reason, the system would start returning 500 errors for a short period because traffic began flowing to a container that was not yet ready to accept it. <\/p>\n

          We faced some bugs<\/b>. Den mest betydelige buggen er at Nomad ikke h\u00e5ndterer store klynger spesielt godt, hvis du har mange systemer og containere. N\u00e5r du \u00f8nsker \u00e5 ta en av serverne som er inkludert i Nomad-klyngen ut av drift, er det en ganske stor sjanse for at klyngen vil reagere d\u00e5rlig og bryte sammen. Noen av containerne kan for eksempel krasje og ikke komme opp igjen - noe som vil koste deg mye hvis alle systemene dine i produksjon befinner seg i klyngen som administreres av Nomad. <\/p>\n

          Derfor har vi bestemt oss for \u00e5 tenke p\u00e5 hvor vi skal g\u00e5 videre. P\u00e5 det tidspunktet hadde vi blitt mye mer bevisste p\u00e5 hva vi \u00f8nsket \u00e5 oppn\u00e5. Nemlig: vi vil ha p\u00e5litelighet, litt flere funksjoner enn det Nomad tilbyr, og et mer modent, mer stabilt system. <\/p>\n

          I denne hensikten falt valget v\u00e5rt p\u00e5 Kubernetes som den mest popul\u00e6re plattformen for \u00e5 kj\u00f8re klynger. Spesielt gitt at st\u00f8rrelsen og antallet av containerne v\u00e5re var ganske stort. For slike form\u00e5l virket Kubernetes som det mest passende systemet av de vi kunne vurdere. <\/p>\n

          Overgangen til Kubernetes<\/h1>\n

          \nLa meg fortelle litt om hvilke grunnleggende begreper Kubernetes har og hvordan de skiller seg fra Nomad. <\/p>\n

          \"Distribusjon
          \n
          \nDet f\u00f8rste og mest grunnleggende begrepet i Kubernetes er begrepet pod. Pod<\/b> \u2014 det er en gruppe med \u00e9n eller flere containere som alltid kj\u00f8res sammen. Og de fungerer som om de alltid er p\u00e5 en og samme virtuelle maskin. De er tilgjengelige for hverandre via IP-adressen 127.0.0.1 p\u00e5 forskjellige porter. <\/p>\n

          La oss anta at du har en PHP-applikasjon som best\u00e5r av nginx og php-fpm \u2013 en klassisk ordning. Sannsynligvis vil du at b\u00e5de nginx- og php-fpm-containerne alltid skal v\u00e6re sammen. Kubernetes gj\u00f8r det mulig \u00e5 oppn\u00e5 dette ved \u00e5 beskrive dem som en felles pod. Akkurat dette klarte vi ikke \u00e5 oppn\u00e5 med Nomad.<\/p>\n

          Det andre begrepet er deployment<\/b>. Poenget er at en pod i seg selv er en flyktig ting, den startes og forsvinner. \u00d8nsker du \u00e5 f\u00f8rst drepe alle dine tidligere containere, og s\u00e5 starte opp nye versjoner med en gang, eller \u00f8nsker du \u00e5 rulle dem ut gradvis \u2013 nettopp denne prosessen er det begrepet deployment ansvarlig for. Det beskriver hvordan du distribuerer dine pods, i hvilken mengde og hvordan du oppdaterer dem. <\/p>\n

          Det tredje begrepet er tjeneste<\/b>. Tjenesten din er faktisk systemet ditt, som mottar en viss trafikk, og deretter sender den til en eller flere pod-er som tilsvarer tjenesten din. Dette betyr at den lar deg spesifisere at all innkommende trafikk til en bestemt tjeneste med et bestemt navn m\u00e5 sendes til nettopp disse pod-ene. I tillegg gir den deg trafikkbalansering. Dette betyr at du kan starte to pod-er av applikasjonen din, og all innkommende trafikk vil bli jevnt balansert mellom de pod-ene som er tilknyttet denne tjenesten.<\/p>\n

          Og det fjerde hovedbegrepet \u2014 Ingress<\/b>. Dette er en tjeneste som kj\u00f8rer i et Kubernetes-kluster. Den fungerer som en ekstern belastningsbalanserer som h\u00e5ndterer alle foresp\u00f8rslene. Gjennom Kubernetes API kan Ingress bestemme hvor disse foresp\u00f8rslene skal sendes. Dessuten gj\u00f8r den dette veldig fleksibelt. Du kan si at alle foresp\u00f8rslene til denne vertsnavnet og den spesifikke URL-en skal sendes til denne tjenesten. Og de foresp\u00f8rslene som kommer til dette vertsnavnet og en annen URL sendes til en annen tjeneste. <\/p>\n

          Det mest fantastiske for utvikleren av applikasjonen er at du kan administrere alt dette selv. Ved \u00e5 sette opp Ingress-konfigurasjonen kan du sende all trafikk som kommer til en viss API til separate containere, for eksempel skrevet i Go. Og denne trafikken som kommer til samme domene, men til en annen URL, kan sendes til containere skrevet i PHP, hvor det er mye logikk, men de er ikke veldig raske.<\/p>\n

          Hvis vi sammenligner alle disse begrepene med Nomad, kan vi si at de tre f\u00f8rste begrepene utgj\u00f8r en samlet Tjeneste. Det siste begrepet finnes ikke i selve Nomad. Vi brukte en ekstern belastningsbalanserer som kan v\u00e6re haproxy, nginx, nginx+ og s\u00e5 videre. I tilfelle med Kubernetes trenger du ikke \u00e5 introdusere dette ekstra begrepet separat. Men hvis du ser p\u00e5 Ingress, kan det v\u00e6re enten nginx, haproxy eller traefik, men integrert i Kubernetes. <\/p>\n

          Alle de begrepene jeg har beskrevet er i bunn og grunn ressurser som eksisterer innenfor et Kubernetes-kluster. For deres beskrivelse i Kubernetes brukes yaml-formatet, som er mer lesbart og kjent enn HCL-filer i tilfelle med Nomad. Men strukturelt beskriver de i eksempelvis en pod det samme. De sier \u2013 jeg vil distribuere disse pod-ene dit, med disse bildene, i dette antallet. <\/p>\n

          \"Distribusjon
          \n
          \nI tillegg forsto vi at vi ikke \u00f8nsket \u00e5 opprette hver enkelt ressurs manuelt: deployment, tjenester, Ingress og s\u00e5 videre. I stedet \u00f8nsket vi \u00e5 beskrive hvert system vi har ved distribusjon i termer av Kubernetes, slik at vi ikke m\u00e5tte rekonstruere alle n\u00f8dvendige avhengigheter i riktig rekkef\u00f8lge for h\u00e5nd. For et slikt system ble Helm valgt. <\/p>\n

          Grunnleggende konsepter i Helm<\/h1>\n

          \nHelm er en pakkeh\u00e5ndterer pakkeadministrator<\/b> for Kubernetes. Det ligner veldig p\u00e5 hvordan pakkeh\u00e5ndterere fungerer i programmeringsspr\u00e5k. De lar deg lagre tjenester, for eksempel en nginx deployment, en php-fpm deployment, konfigurasjon for Ingress, configmaps (som er en enhet som lar deg angi milj\u00f8variabler og andre parametere for systemet ditt) i s\u00e5kalte charts. Helm opererer over Kubernetes<\/b>. Det vil si at det ikke er et system som st\u00e5r p\u00e5 siden, men bare en annen tjeneste som kj\u00f8rer inne i klyngen. Du kommuniserer med det via API-et gjennom kommandolinjen. Den st\u00f8rste fordelen er at selv om helm krasjer eller du fjerner det fra klyngen, s\u00e5 forsvinner ikke tjenestene dine, siden helm i bunn og grunn bare brukes til \u00e5 starte systemet. Funksjonalitet og tilstand til tjenestene videre anses av Kubernetes selv. <\/p>\n

          Vi forsto ogs\u00e5 at malbasert programmering<\/b>, som vi tidligere var n\u00f8dt til \u00e5 gj\u00f8re selv ved \u00e5 implementere jinja i konfigurasjonene v\u00e5re, er en av de viktigste funksjonene til helm. Alle konfigurasjoner du lager for systemene dine lagres i helm som maler, som ligner litt p\u00e5 jinja, men faktisk bruker Go-spr\u00e5kets malbaserte system, som helm er skrevet p\u00e5, akkurat som Kubernetes. <\/p>\n

          Helm gir oss ogs\u00e5 flere andre konsepter. <\/p>\n

          Chart<\/b> er en beskrivelse av tjenesten din. I andre pakkeh\u00e5ndterere ville det bli kalt en pakke, et bundt eller noe lignende. Her kalles det chart. <\/p>\n

          Values <\/b>er variablene du \u00f8nsker \u00e5 bruke for \u00e5 bygge konfigurasjonene dine fra malene. <\/p>\n

          Release<\/b>Hver gang en tjeneste som deployeres med helm, f\u00e5r en inkrementell versjon av utgivelsen. Helm husker hvordan tjenesten var konfigurert ved forrige, forrige forrige utgivelse, og s\u00e5 videre. Derfor, hvis du m\u00e5 rulle tilbake, er det bare \u00e5 utf\u00f8re kommandoen helm callback, og spesifisere forrige versjon av utgivelsen. Selv om den tilsvarende konfigurasjonen ikke er tilgjengelig i ditt depot ved tidspunktet for tilbakef\u00f8ringen, husker helm fortsatt hvordan den var, og vil tilbakef\u00f8re systemet ditt til tilstanden det var i ved den forrige utgivelsen. <\/p>\n

          N\u00e5r vi bruker helm, blir vanlige konfigurasjoner for Kubernetes ogs\u00e5 til maler der det er mulig \u00e5 bruke variabler, funksjoner og anvende betingede operatorer. P\u00e5 denne m\u00e5ten kan du bygge konfigurasjonen av tjenesten din avhengig av milj\u00f8et.<\/p>\n

          \"Distribusjon
          \n
          \nI praksis har vi besluttet \u00e5 gj\u00f8re det litt annerledes enn vi gjorde med Nomad. Hvis i Nomad ble konfigurasjoner for deployering og n-variabler som er n\u00f8dvendige for \u00e5 deployere tjenesten v\u00e5r lagret i ett depot, s\u00e5 har vi her valgt \u00e5 dele dem opp i to separate depoter. I depoten 'deploy' lagres kun n-variabler som er n\u00f8dvendige for deployering, mens i depoten 'helm' lagres konfigurasjoner eller diagrammer.<\/p>\n

          \"Distribusjon
          \n
          \nHva fikk vi ut av dette? <\/p>\n

          Selv om vi ikke oppbevarer noen virkelig sensitive data i selve konfigurasjonsfilene, for eksempel passord til databaser, som lagres som secrets i Kubernetes, er det fortsatt separate ting som vi ikke vil gi tilgang til alle. Derfor er tilgangen til depoten 'deploy' mer begrenset, mens depoten 'helm' bare inneholder en beskrivelse av tjenesten. Av denne grunn kan tilgang gis til et st\u00f8rre antall personer p\u00e5 en sikker m\u00e5te. <\/p>\n

          Siden vi har ikke bare produksjon, men ogs\u00e5 andre milj\u00f8er, kan vi takket v\u00e6re denne oppdelingen gjenbruke helm-diagrammene v\u00e5re for \u00e5 deployere tjenester ikke bare i produksjon, men ogs\u00e5 for eksempel i QA-milj\u00f8et. Selv for \u00e5 kj\u00f8re dem lokalt ved \u00e5 bruke Minikube<\/i> \u2014 det er en slik ting for lokal kj\u00f8ring av Kubernetes. <\/p>\n

          Inni hvert repositorium har vi gjort en inndeling i separate mapper for hver tjeneste. Det vil si at innvendig hver mappe finnes maler som er relatert til den aktuelle charten og beskriver de ressursene som m\u00e5 distribueres for \u00e5 starte systemet v\u00e5rt. I repositoriet \u00abdeploy\u00bb har vi kun inkludert env-filer. I dette tilfellet har vi ikke brukt templatisering med jinja, fordi helm selv gir templatisering \u00about of the box\u00bb \u2013 dette er en av kjernene funksjonene. <\/p>\n

          Vi har inkludert et skript for distribusjon \u2013 deploy.sh, som forenkler og standardiserer oppstarten for distribusjon ved hjelp av helm. Dermed ser distribusjonsgrensesnittet akkurat det samme ut for alle som vil distribuere, som i tilfellet med distribusjon via Nomad. Samme deploy.sh, navnet p\u00e5 tjenesten din, og hvor du \u00f8nsker \u00e5 distribuere den. Dette f\u00f8rer til at helm startes internt. Det samler konfigurasjonene fra malene, setter inn de n\u00f8dvendige values-filene, og distribuerer dem s\u00e5 inn i Kubernetes. <\/p>\n

          Konklusjoner<\/h1>\n

          \nKubernetes-tjenesten ser mer kompleks ut enn Nomad. <\/p>\n

          \"Distribusjon
          \n
          \nHer kommer den utg\u00e5ende trafikken inn i Ingress. Dette er nettopp frontend-kontrolleren som tar imot alle foresp\u00f8rslene og deretter sender dem til de aktuelle tjenestene basert p\u00e5 foresp\u00f8rselen. Den bestemmer dem basert p\u00e5 konfigurasjoner som er en del av beskrivelsen av applikasjonen din i helm og som utviklerne angi selv. Tjenesten sender foresp\u00f8rslene til sine pods, det vil si spesifikke containere, og balanserer den innkommende trafikken mellom alle containerne som tilh\u00f8rer denne tjenesten. Og selvf\u00f8lgelig b\u00f8r vi ikke glemme at vi ikke kan forlate sikkerheten p\u00e5 nettverksniv\u00e5. Derfor fungerer segmenteringen i Kubernetes-klyngen basert p\u00e5 merking. Alle tjenester har bestemte merker, som er knyttet til rettighetene til tjenestene til ulike eksterne\/intern ressurser inne i eller utenfor klyngen. <\/p>\n

          N\u00e5r vi gjorde overgangen, s\u00e5 vi at Kubernetes hadde alle funksjonene til Nomad, som vi hadde brukt tidligere, og flere nye tillegg. Det kan utvides via plugins, og faktisk ved hjelp av egendefinerte ressurs typer. Det vil si at du har mulighet til ikke bare \u00e5 bruke det som f\u00f8lger med Kubernetes, men ogs\u00e5 til \u00e5 lage din egen ressurs og tjeneste som kan lese denne ressursen. Dette gir ekstra muligheter for \u00e5 utvide systemet ditt uten \u00e5 m\u00e5tte reinstallere Kubernetes og uten \u00e5 m\u00e5tte endre noe. <\/p>\n

          Et eksempel p\u00e5 slik bruk er Prometheus, som kj\u00f8rer i klyngen v\u00e5r av Kubernetes. For at det skal begynne \u00e5 samle inn m\u00e5linger fra en bestemt tjeneste, m\u00e5 vi legge til en ekstra ressurs type i tjenestebeskrivelsen, kalt en tjenestemonitor. Takket v\u00e6re at Prometheus kan lese egendefinerte ressurs typer n\u00e5r det kj\u00f8res i Kubernetes, begynner det automatisk \u00e5 samle inn m\u00e5linger fra det nye systemet. Dette er ganske praktisk. <\/p>\n

          Den f\u00f8rste deployeringen vi gjorde i Kubernetes var i mars 2018. Og i l\u00f8pet av denne tiden har vi aldri opplevd noen problemer med det. Det fungerer ganske stabilt uten betydelige feil. I tillegg kan vi utvide det videre. I dag er vi forn\u00f8yd med de mulighetene som finnes, og vi liker utviklingstakten til Kubernetes. For tiden er det over 3000 containere i Kubernetes. Klyngen best\u00e5r av flere noder. Den er selvbetjent, stabil og sv\u00e6rt kontrollerbar.
          \n
          Kilde:           habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

          \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Deployering av applikasjoner i VM, Nomad og Kubernetes | ProHoster","description":"Hei alle sammen! Jeg heter Pavel Agaletzki. Jeg jobber som teamleder i gruppen som utvikler leveringssystemet for Lamoda.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u043f\u043b\u043e\u0439 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0432 VM, Nomad \u0438 Kubernetes | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda.","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:53:58+00:00","article:modified_time":"2019-10-31T18:53:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33654","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-08 20:38:40","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:36:34","updated":"2026-02-08 20:38:40","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}