„Amazon Fargate“ įvadas: kas tai yra, kodėl tai nuostabu (ir ne) ir kada jį naudoti.

Kai „Amazon“ 2017 m. Pabaigoje paskelbė „Fargate“ „AWS re: Invent“ (kartu su EKS), ji tikrai pateko po radaru. Nė vienas iš tinklaraščių ar įtakingų autorių, kuriuos tuo metu stebėjau, apie tai tikrai nekalbėjo, išskyrus kažką panašaus:

Taip, ir yra šis naujas dalykas, kuris leis ECS vartotojams paleisti konteinerius tiesiai į debesį.

Man, kaip kūrėjui, tai tikrai sukėlė galvą. Pažiūrėkime, kodėl.

Produktyvumo bumas

Manau , kad programinės įrangos kūrimo pasaulyje įvyko penkios pagrindinės revoliucijos, kurios smarkiai padidino kūrėjų produktyvumą ir galimybes rašyti ir diegti gamybos lygio programas maksimaliai efektyviai.

Jie visi taip pat sprendė pagrindinius klausimus. Štai mano revoliucijų ir jų išspręstų klausimų suskirstymas:

  • Debesų paslaugų (IaaS) atsiradimas

    Infrastruktūros kaina ir mastelis

  • Atvirojo kodo bendruomenė, konferencijos, dirbtuvės, „Tech Blogs“, „Stack overflow“ ir pan

    Ribota prieiga prie žinių

  • Versijų sistemos, bendradarbiavimo įrankiai, nuolatinės integracijos įrankiai

    Sistemų neatitikimas ir integracijos pragaras

  • Konteinerių architektūra

    Sunku kurti programas skirtingose ​​aplinkose

  • Be serverio skaičiavimo paslaugos (PaaS)

    Serverių ir sistemų administravimas

Kiekviena iš šių revoliucijų turi vieną bendrą bruožą: jos visos suteikia daugiau galimybių valdyti programinės įrangos inžinierius. Jie tai daro skatindami gerą praktiką ir dalijimąsi kodais naudodami bendrą darbo eigą, taip pat sumažina brangių dedikuotų serverių, sistemos administratorių, „DevOps“, IT palaikymo ir pan.

Puiku, bet palaukite - kur visame tame yra Fargate ?

Jūsų laivas yra problema

Pažiūrėk, kai „Docker“ atnešė konteinerius į mases, tai greitai tapo nauju standartu ir buvo plačiai pritaikytas.

Netrukus ir po „ Kubernetes “ sėkmės AWS pristatė savo (paprastesnę) konteinerių tvarkymo paslaugą: „Amazon Elastic Container Service“ (ECS). Jame pristatyta užduočių samprata.

Užduotis gali būti bet koks konteinerių, dirbančių kartu, egzempliorius. Nuo žiniatinklio programos, kurioje veikia žiniatinklio serveris, kelios mikro paslaugos, duomenų bazė ir atvirkštinis tarpinis serveris, iki „shell“ scenarijų paketų, kurie bus vykdomi periodiškai, sąrašo.

Būdamas ankstyvas ECS pritaikytojas, man tai labai patiko ir kurį laiką jis puikiai veikė. Tačiau galų gale, tereikia valdyti šiuos papildomus sluoksnius (užduotis ir sudėtinius rodinius), o ne tik EC2 egzempliorius.

Man taip pat nepatiko jo saugumas . Kuo daugiau sluoksnių turite savo kamino, tuo daugiau turite būti budrūs. Kiekvienas iš šių sluoksnių padidina sudėtingumą ir padidina neteisingų saugos konfigūracijų ir pažeidžiamumų tikimybę.

Iš tiesų, naudojant ECS, jūsų konteineriai veikia EC2 konteinerių egzemplioriuose, esančiuose grupėje, kurią sukonfigūruosite automatiniam mastelio keitimui. Kiekvienas egzempliorius gali atlikti kelias skirtingas užduotis. Kiekviena užduotis gali paleisti kelis konteinerius.

Kadangi jūsų užduotys bus paskirstytos atsitiktinai (pagal numatytuosius nustatymus) to paties tipo EC2 egzemplioriams su turimais ištekliais , susiduriate su šiomis problemomis:

  • Vienas klasteris laikosi tų pačių automatinio mastelio keitimo taisyklių ir automatiškai pateikia tos pačios rūšies EC2 egzempliorius.
  • Kai kuriems konteineriams reikės visiškai skirtingų išteklių, tačiau jie vis tiek turės dirbti kartu.
  • Kai kuriuose konteineriuose nebūtinai taikomos tos pačios automatinio keitimo taisyklės.
  • Kartais keliems konteineriams, atliekantiems tą pačią užduotį, reikia savo apkrovos balansatoriaus, o tai pačiai užduočiai turėti kelių krovinių balansatorių neįmanoma.

Pageidautinas būdas išspręsti šias problemas buvo:

  • rankiniu būdu įdėkite kai kuriuos egzempliorius naudodami skirtingus išteklius, atsižvelgdami į poreikį
  • pridėkite šiuos egzempliorius prie savo grupės
  • paleiskite vieną konteinerį pagal užduotį
  • susieti EC2 egzempliorius rankiniu būdu
  • parašykite sudėtingus strategijos išdėstymo apribojimus ECS, kad įsitikintumėte, jog teisinga užduotis buvo tinkamoje mašinoje, turinčioje atitinkamus išteklius, atsižvelgiant į tai, ką ji padarė

Tai yra daug darbo, jis gana varginantis ir jį sunku išlaikyti. Tai tarsi pranoksta darbo su konteineriais tikslą.

Kažkas turėjo sugalvoti geresnę idėją.

Leisk jiems plaukti

Kaip paaiškėjo, AWS komanda turėjo tuos pačius klausimus. Jie galvojo apie tai praėjusiais metais ir dirbo toliau išsprendę problemą:

Kaip mes galėtume paleisti konteinerius, nesijaudindami dėl serverių ir grupių?

Apie tai ir yra „AWS Fargate“ . Tai visiškai apibendrina pagrindinę infrastruktūrą ir jūs matote kiekvieną savo konteinerį kaip vieną mašiną.

Jūs tiesiog turite nurodyti, kokių išteklių jums reikia kiekvienam konteineriui, ir jis jums sunkiai pakels. Nebereikia tvarkyti daugiasluoksnių prieigos taisyklių. Galite tikslinti leidimus tarp savo talpyklų, kaip tai darytumėte tarp atskirų EC2 egzempliorių.

Tarsi jūsų konteineriai taptų laivais su savo burėmis, vairu ir įgula ir galėtų patys nuplaukti į paskirties vietą.

Konteineriai kaip paslauga (CaaS)

Aš iš tikrųjų tikiu, kad „ Containers as a Service“ (CaaS) yra tikrasis „PaaS“, kurio kūrėjai laukė ne vienerius metus. Tai leidžia kūrėjams dislokuoti savo konteinerius tiesiai į debesį, nesijaudinant dėl ​​visko, kas yra tarp jų.

Žinoma, jau yra daugybė technologijų, leidžiančių sklandžiai paleisti kodą debesyje, nesijaudinant dėl ​​mastelio ar serverio administravimo (pvz., Nuostabus „ Heroku“ , „ Lambda“ ar net savaip „ Google“ programų variklis) . Bet visi turi apribojimų.

  • Turite pasirinkti, ar prarasti šiek tiek lankstumo
  • Turite laikytis palaikomų kalbų
  • Negalite naudoti palaikomų kalbų, nes jūsų projektui reikia savosios žemo lygio bibliotekos, kuri prieinama tik labai specifinėse sistemose
  • Jūsų projekte naudojama pažangiausia technologija, kurios per ateinančius kelerius metus nebus galima įsigyti masėms
  • Kai kurios iš šių platformų yra labai (labai) brangios, ypač didinant

Fargate (Arba CaaS) suteikia jums geriausius iš abiejų pasaulių.

Konteinerių architektūra suteikia jums reikiamą lankstumą ir kontrolę. Tai leidžia naudoti bet kokią technologiją, veikiančią bet kokioje norimoje sistemoje . Sudėtinio rodinio aspektas užtikrins, kad su visais pagrindiniais kompiuteriais elgsitės vienodai, nesvarbu, ar tai būtų programinės įrangos kūrėjas, bandymai, etapai ar prod.

Manau, kad šis momentas yra kritiškas daugeliui technologijų pradedančiųjų. Tiesą sakant, kartais vienas iš jūsų konkurencinių pranašumų yra pažangiausios technologijos, kurią dalyvavote kurdami, naudojimas arba sumanus kitos technologijos pakartotinis naudojimas visiškai naujame ir revoliuciniame kontekste.

Diegimas be serverio leidžia sutelkti dėmesį į puikų kodą. Nėra jokių atsarginių dalių, lengva keisti mastelį.

Ribos

„CaaS“ ir „PaaS“

Tiesa, jūs atsisakote kai kurių tikrų „PaaS“ aspektų. Taip, vis tiek turėsite rankiniu būdu atnaujinti savo talpyklos vaizdus, ​​o kartais turėsite parašyti savo „Docker“ vaizdus. Iš pradžių tai gali būti kova, jei nežinote sistemos administravimo pagrindų .

Bet tai taip pat reiškia, kad galite padaryti beveik viską, ką galite galvoti, ir turėti visišką lankstumą bei laisvę sistemose, kalbose, įrankiuose, bibliotekose ir versijose, kurias norite naudoti.

Kaina

Pripažinkime, kad debesijos paslaugos (IaaS) yra brangesnės nei turėti savo infrastruktūrą (jei pagal poreikį galėtum ją didinti ir mažinti). Dėl tos pačios priežasties nereikia mokėti, tvarkyti ir keisti savo serverių. Tai gali būti dar ne geriausias sprendimas kai kuriems jūsų paprasčiausiems naudojimo atvejams.

Tikėkimės, kad jie stengsis sumažinti išlaidas. Kad ir koks geras produktas yra, sunku pagrįsti beveik 4 kartus didesnę kainą, lyginamą pagal pareikalavimą ekvivalentiško EC2 egzemplioriaus (pavyzdžiui, t2.medium).

Ar turėčiau visas savo ECS užduotis perjungti į „Fargate“?

Dar ne. Kaip minėta pirmiau, kai kuriais atvejais savo išlaidas padengsite daugiau nei trigubai. Kol jie nesumažins išlaidų, jums gali būti geriau naudotis standartinėmis EC2 instancijomis.

Tačiau „Fargate“ gali būti naudingesnė šiais atvejais:

  • Jei kyla problemų efektyviai keičiant ECS užduotis ir dažnai gaunama daug nenaudojamo procesoriaus ar atminties . Naudodamiesi „Fargate“ mokate tik už išteklius, kuriuos apibrėžėte vykdydami užduotis .
  • Jūsų užduotims, kurios bus vykdomos pagal pareikalavimą arba pagal tvarkaraštį ir kurioms nereikia specialaus EC2 egzemplioriaus. Naudodami „Fargate“ mokate tik tada, kai vykdoma jūsų užduotis.
  • Užduotims, kurių atminties ir (arba) procesoriaus naudojimas yra didžiausias . Vien todėl, kad sutaupysite laiko ir rūpesčių dėl tokių atvejų konfigūravimo ir valdymo.

Premija

Tiems, kurie labiau mėgsta „ Kubernetes“, o ne „ ECS“ , „Fargate“ netrukus galės valdyti „Kubernetes“ skirtą „Elastic Container Service“.