Iepazīšanās ar Amazon Fargate: kas tas ir, kāpēc tas ir lieliski (un ne) un kad to izmantot.

Kad Amazon 2017. gada beigās paziņoja par Fargate AWS re: Invent (kopā ar EKS), tas patiešām nokrita zem radara. Neviens no emuāriem vai ietekmētājiem, kuriem es tajā laikā sekoju, par to īsti nerunāja, izņemot kaut ko līdzīgu:

Ak, jā, un ir šī jaunā lieta, kas ļaus ECS lietotājiem palaist konteinerus tieši mākonī.

Man kā izstrādātājam tas tiešām sagādāja prātu. Apskatīsim, kāpēc.

Produktivitātes bums

Man šķiet , ka programmatūras izstrādes pasaulē ir notikušas piecas lielas revolūcijas, kas dramatiski palielināja izstrādātāju produktivitāti un spēju ar maksimālu efektivitāti rakstīt un izvietot ražošanas līmeņa lietojumprogrammas.

Viņi visi arī atrisināja galvenos jautājumus. Šis ir mans revolūciju sadalījums un jautājumi, kurus viņi atrisināja:

  • Mākoņpakalpojumu (IaaS) parādīšanās

    Infrastruktūras izmaksas un mērogojamība

  • Atvērtā koda kopiena, konferences, semināri, tehniskie emuāri, kaudzes pārpilde utt

    Ierobežota piekļuve zināšanām

  • Versiju sistēmas, sadarbības rīki, nepārtrauktas integrācijas rīki

    Vienlaicīga inženierijaSistēmu neatbilstība un integrācijas elle

  • Konteinerizēta arhitektūra

    Grūtības veidot lietojumprogrammas nekonsekventā vidē

  • Bezserveru skaitļošanas pakalpojumi (PaaS)

    Serveru un sistēmu administrēšana

Katrai no šīm revolūcijām ir viena kopīga iezīme: tās visas dod lielāku kontroli programmatūras inženieriem. Viņi to dara, veicinot labu praksi un kodu koplietošanu, izmantojot kopīgu darbplūsmu, kā arī samazina vajadzību pēc dārgiem speciālajiem serveriem, sistēmas administratoriem, DevOps, IT atbalsta utt.

Lieliski, bet pagaidiet - kur visā šajā atrodas Fargate ?

Jūsu kuģis ir jautājums

Skatiet, kad Dokers atnesa konteinerus masām, tas ātri kļuva par jaunu attīstības standartu un tika plaši pieņemts.

Drīz pēc Kubernetes panākumiem AWS uzsāka savu (pamata) konteineru pārvaldības pakalpojumu: Amazon Elastic Container Service (ECS). Tas ieviesa uzdevumu jēdzienu.

Uzdevums var būt jebkurš konteineru kopdarbs. Sākot ar tīmekļa lietojumprogrammu, kas vada tīmekļa serveri, vairākus mikropakalpojumus, datu bāzi un apgriezto starpniekserveri, līdz čaulas skriptu partiju sarakstam, kas darbosies periodiski.

Būdams agrīns ECS lietotājs, man tas ļoti patika, un tas kādu laiku darbojās lieliski. Bet galu galā šo papildu slāņu (uzdevumu un konteineru) pārvaldīšana, nevis tikai EC2 gadījumi, kļuva arvien sarežģītāka.

Man arī nebija mierā ar tā drošību . Jo vairāk slāņu jums ir jūsu kaudzē, jo vairāk jums jābūt modriem. Katrs no šiem slāņiem rada lielāku sarežģītību, kā arī palielina nepareizas drošības konfigurācijas un ievainojamības iespējamību.

Patiešām, izmantojot ECS, jūsu konteineri darbojas EC2 konteineru gadījumos klasterī , kuru konfigurēsit automātiskai mērogošanai. Katrā instancē var uzņemt vairākus dažādus uzdevumus. Katrs uzdevums var palaist vairākus konteinerus.

Tā kā jūsu uzdevumi tiks izvietoti nejauši (pēc noklusējuma) tāda paša veida EC2 gadījumos ar pieejamiem resursiem , jūs sastopaties ar šādām problēmām:

  • Viena kopa ievēro tos pašus automātiskās mērogošanas noteikumus un automātiski nodrošina tāda paša veida EC2 gadījumus.
  • Dažiem konteineriem būs nepieciešami pilnīgi atšķirīgi resursi, taču tiem joprojām ir jāstrādā kopā.
  • Daži konteineri ne vienmēr ievēro tos pašus automātiskās mērogošanas noteikumus.
  • Dažreiz vairākiem konteineriem vienā un tajā pašā uzdevumā ir nepieciešams savs kravas balansētājs, un vienam un tam pašam uzdevumam nav iespējams izmantot vairākus kravas balansētājus.

Vēlamais risinājums, risinot šos jautājumus, bija:

  • manuāli izvietot dažus savus gadījumus ar dažādiem resursiem, pamatojoties uz nepieciešamību
  • pievienojiet šos gadījumus savai kopai
  • palaist vienu konteineru pēc uzdevuma
  • saistiet EC2 gadījumus manuāli
  • uzrakstiet sarežģītus stratēģijas izvietošanas ierobežojumus ECS, lai pārliecinātos, ka pareizais uzdevums bija pareizajā mašīnā, kurai bija atbilstošs resurss atkarībā no tā, ko tā darīja

Tas ir daudz darba, tas ir diezgan garlaicīgs , un to ir grūti uzturēt. Un tas kaut kā pārspēj darbu ar konteineriem.

Kādam bija jānāk klajā ar labāku ideju.

Ļaujiet viņiem peldēt

Kā izrādās, AWS komandai bija tādi paši jautājumi. Viņi domāja par to pagājušajā gadā un strādāja pie šīs problēmas risināšanas:

Kā mēs varētu palaist konteinerus, neraizējoties par serveriem un kopām?

Un tieši par to ir AWS Fargate . Tas pilnīgi attēlo pamatā esošo infrastruktūru, un jūs redzat katru savu konteineru kā vienu mašīnu.

Jums vienkārši jānorāda, kāds resurss jums nepieciešams katram konteineram, un tas jums smagi pacels. Jums vairs nav jāpārvalda daudzslāņu piekļuves kārtulas. Varat precīzi pielāgot atļaujas starp konteineriem, tāpat kā jūs darītu starp atsevišķiem EC2 gadījumiem.

Tas ir tāpat kā jūsu konteineri kļūst par kuģiem ar savu buru, stūri un apkalpi un paši spēj peldēt līdz galamērķim.

Konteineri kā pakalpojums (CaaS)

Es faktiski uzskatu, ka Containers as a Service (CaaS) ir īstā PaaS, kuru izstrādātāji gaida jau gadiem ilgi. Tas ļauj izstrādātājiem izvietot savus konteinerus tieši mākonī, neuztraucoties par visu starplaikos.

Protams, jau ir daudz tehnoloģiju, kas ļauj nevainojami palaist kodu mākonī, neraizējoties par mēroga vai servera administrēšanu (piemēram, apbrīnojamo Heroku , Lambda vai pat savā veidā Google lietotņu dzinēju) . Bet visiem ir ierobežojumi.

  • Jums jāizvēlas starp mazliet elastības zaudēšanu
  • Jums ir jāievēro atbalstītās valodas
  • Jūs nevarat izmantot atbalstītās valodas, jo jūsu projektam ir nepieciešama dzimtā zema līmeņa bibliotēka, kas ir pieejama tikai ļoti specifiskās sistēmās
  • Jūsu projektā tiek izmantota vismodernākā tehnoloģija, kas tuvākajos gados nebūs pieejama masām
  • Dažas no šīm platformām ir ļoti (ļoti) dārgas, it īpaši, ja tiek palielināta

Fargate (vai CaaS) sniedz jums labāko no abām pasaulēm.

Konteinerizētā arhitektūra nodrošina jums nepieciešamo elastību un kontroli. Tas ļauj jums izmantot jebkura veida tehnoloģiju, kas darbojas jebkura veida sistēmā, kuru vēlaties. Konteinera aspekts nodrošinās, ka ar katru saimniekdatoru izturēsieties vienādi, neatkarīgi no tā, vai tā ir izstrādes, testēšanas, iestudēšanas vai ražotāja vide.

Es uzskatu, ka šis punkts ir kritisks daudziem tehnoloģiju jaunuzņēmumiem. Patiesībā dažreiz viena no jūsu konkurences priekšrocībām ir mūsdienīgas tehnoloģijas izmantošana, kuras izstrādē esat piedalījies, vai citas tehnoloģijas gudra atkārtota izmantošana pilnīgi jaunā un revolucionārā kontekstā.

Izvietošana bez servera ļauj koncentrēties uz lieliska koda rakstīšanu. Nav nodrošinājuma, ērta mērogošana.

Limiti

CaaS vs PaaS

Ir taisnība, ka jūs atsakāties no dažiem īstajiem PaaS aspektiem. Jā, jums joprojām būs manuāli jāatjaunina konteinera attēli, un dažreiz jums būs jāraksta paši savi Docker attēli. Sākumā tā var būt cīņa, ja nezināt sistēmas administrēšanas pamatus .

Bet tas arī nozīmē, ka jūs varat darīt gandrīz visu, ko varat domāt, un jums ir pilnīga elastība un brīvība sistēmās, valodās, rīkos, bibliotēkās un versijās, kuras vēlaties izmantot.

Izmaksas

Atzīsim, ka mākoņpakalpojumi (IaaS) ir dārgāki nekā sava infrastruktūra (ja jūs to varētu palielināt un samazināt pēc pieprasījuma). Tā paša iemesla dēļ, ja nav nepieciešams nodrošināt, pārvaldīt un mērogot serverus, ir jāmaksā. Varbūt tas vēl nav labākais risinājums dažiem jūsu vienkāršākajiem lietošanas gadījumiem.

Cerēsim, ka viņi strādās pie izmaksu samazināšanas. Lai cik labs būtu produkts, ir grūti attaisnot gandrīz četras reizes lielāku cenu par pieprasījuma ekvivalentu EC2 gadījumu (piemēram, t2.medium).

Vai man visi ECS uzdevumi jāpārslēdz uz Fargate?

Vēl nē. Kā minēts iepriekš, dažos gadījumos jūs vairāk nekā trīskārt palielināsiet savas izmaksas. Kamēr tie nesamazinās izmaksas, jums var būt labāk izmantot standarta EC2 instanes.

Tomēr Fargate var būt izdevīgāka jums šādos lietošanas gadījumos:

  • Ja jums ir problēmas ar efektīvu ECS uzdevumu mērogošanu un bieži rodas daudz neizmantota procesora vai atmiņas . Izmantojot Fargate, jūs maksājat tikai par resursiem, kurus esat definējis savos uzdevumos .
  • Jūsu uzdevumiem, kas darbosies pēc pieprasījuma vai pēc grafika un kuriem nav nepieciešama īpaša EC2 instance. Izmantojot Fargate, jūs maksājat tikai tad, kad jūsu uzdevums tiek izpildīts.
  • Jūsu uzdevumiem, kuru maksimālais atmiņas un / vai procesora lietojums . Tikai tāpēc, ka tas ietaupīs jums laiku un grūtības ar šādu lietu konfigurēšanu un pārvaldību.

Bonuss

Tiem, kas dod priekšroku Kubernetes, nevis ECS , Fargate drīz varēs palaist Kubernetes elastīgo konteineru pakalpojumu.