Bevezetés az Amazon Fargate-be: mi ez, miért félelmetes (és nem), és mikor kell használni.

Amikor az Amazon 2017 végén bejelentette a Fargate-t az AWS re: Inventnél (az EKS-szel együtt), valóban a radar alá esett. Az általam akkor követett blogok és befolyásolók egyike sem beszélt erről igazán, csak valamiről a következők szerint:

Ja, és van egy új dolog, amely lehetővé teszi az ECS-felhasználók számára, hogy a tárolókat közvetlenül a felhőben futtassák.

Fejlesztőként ez nagyon megrobbant. Lássuk miért.

A termelékenység fellendülése

Úgy érzem, hogy öt nagy forradalom történt a szoftverfejlesztési világban, amely drámai módon megnövelte a fejlesztők termelékenységét és képességét arra, hogy maximális hatékonysággal írhassanak és telepítsenek gyártási szintű alkalmazásokat.

Mindannyian megoldották a főbb kérdéseket is. Íme a forradalmak lebontása és az általuk megoldott kérdések:

  • A felhőszolgáltatások (IaaS) megjelenése

    Infrastruktúra költsége és méretezhetősége

  • Nyílt forráskódú közösség, konferenciák, műhelyek, technikai blogok, verem túlcsordulás stb

    Korlátozott hozzáférés az ismeretekhez

  • Verziós rendszerek, Együttműködési eszközök, Folyamatos integrációs eszközök

    A rendszerek eltérései és az integráció a pokolban vannak

  • Konténeres architektúra

    Nehézség az alkalmazások összeépítésében inkonzisztens környezetekben

  • Szerver nélküli számítási szolgáltatások (PaaS)

    Szerverek és rendszerek adminisztrációja

Ezeknek a forradalmaknak mindegyiküknek egy közös vonása van: mindegyik nagyobb irányítást ad a szoftvermérnökök számára. Teszik ezt a jó gyakorlatok és a kódmegosztás ösztönzésével egy együttműködő munkafolyamat segítségével, és csökkentik a drága dedikált szerverek, a rendszergazdák, a DevOps, az informatikai támogatás és így tovább szükségességét.

Remek, de várjon - hol van a Fargate ebben az egészben?

A hajód a kérdés

Lásd, amikor a Docker konténereket hozott a tömegek felé, ez gyorsan új szabványsá vált a fejlesztésben, és széles körben elfogadták.

Nem sokkal később és a Kubernetes sikere nyomán az AWS elindította saját (alaposabb) konténerkezelő szolgáltatását: az Amazon Elastic Container Service (ECS) szolgáltatást. Bevezette a Tasks fogalmát.

Feladat lehet a konténerek együttes működése. A webkiszolgálót futtató webalkalmazástól, számos mikrotovábbítási szolgáltatástól, egy adatbázistól és egy fordított proxytól kezdve a rendszeresen futó shell script kötegek listájáig.

Mivel az ECS korai alkalmazója voltam, nagyon tetszett, és egy ideig kiválóan működött. Végül azonban egyre bonyolultabbá vált az extra rétegek (feladatok és tárolók) kezelése az EC2 példányok helyett.

Nekem sem volt kényelmes a biztonsága . Minél több réteg van a veremben, annál inkább ébernek kell lenned. Ezen rétegek mindegyike összetettebbé teszi a biztonsági hibás konfigurációk és a sebezhetőségek fokozott valószínűségét.

Valójában az ECS használatával a tárolók EC2 tároló példányokban futnak egy olyan fürtben , amelyet automatikus méretezésre konfigurál. Minden példány több különböző feladatot is otthont adhat. Minden feladat több tárolót is futtathat.

Mivel a feladatait véletlenszerűen (alapértelmezés szerint) telepítik ugyanazon típusú EC2 példányokra, rendelkezésre álló erőforrásokkal , a következő problémákkal kell szembenéznie:

  • Egy fürt ugyanazokat a szabályokat követi az automatikus méretezésnél, és automatikusan létrehozza az azonos típusú EC2 példányokat.
  • Egyes tárolóknak teljesen más erőforrásokra lesz szükségük, de mégis együtt kell működniük.
  • Egyes tárolók nem feltétlenül követik ugyanazokat a szabályokat az automatikus skálázáshoz.
  • Előfordul, hogy több, ugyanabban a feladatban lévő tárolónak saját terheléselosztójára van szüksége, és több terheléselosztó megléte ugyanahhoz a feladathoz nem lehetséges.

A problémák megoldása során az előnyben részesített megoldás a következő volt:

  • néhány példányt manuálisan telepítsen különböző erőforrásokkal, a szükségletek alapján
  • csatolja ezeket a példányokat a fürtjéhez
  • futtasson egy konténert feladat szerint
  • manuálisan kapcsolja össze az EC2 példányokat
  • írjon komplex stratégia-elhelyezési korlátozásokat az ECS-re, hogy megbizonyosodjon arról, hogy a megfelelő feladat volt-e a megfelelő gépen, amely rendelkezik a megfelelő erőforrással, attól függően, hogy mit tett

Ez sok munka, elég unalmas és nehéz fenntartani. És ez valahogy legyőzi a konténerekkel való munka célját.

Valakinek jobb ötlettel kellett előállnia.

Hadd lebegjenek

Mint kiderült, az AWS csapatának ugyanazok a kérdései voltak. Gondoltak rá az elmúlt évben, és az alábbi probléma megoldásán dolgoztak:

Hogyan futtathatnánk tárolókat anélkül, hogy aggódnunk kellene a szerverek és a fürtök miatt?

És erről szól az AWS Fargate . Teljesen kivonja a mögöttes infrastruktúrát, és minden egyes konténerét egyetlen gépként látja.

Csak meg kell adnia, milyen erőforrásra van szüksége minden konténerhez, és ez elvégzi az Ön számára a nehéz emelést. Többé nem kell kezelnie a többrétegű hozzáférési szabályokat. A tárolók közötti engedélyeket úgy finomhangolhatja, mint az egyes EC2 példányok között.

Ez olyan, mintha a konténereid saját vitorlájukkal, kormányukkal és legénységükkel válnának a hajókká, és képesek lennének önállóan úszni a rendeltetési helyükre.

Konténerek szolgáltatásként (CaaS)

Valójában úgy gondolom, hogy a Containers as a Service (CaaS) az igazi PaaS, amelyre a fejlesztők évek óta várnak. Ez lehetővé teszi a fejlesztők számára, hogy közvetlenül a felhőbe telepítsék tárolóikat, anélkül, hogy aggódniuk kellene a kettő között.

Természetesen már sok olyan technológia létezik odakinn, amelyek lehetővé teszik a kód zökkenőmentes futtatását a felhőben anélkül, hogy aggódnod kellene a méretarány vagy a szerver adminisztráció miatt (például a csodálatos Heroku , Lambda, vagy akár a maga módján a Google alkalmazás motorja) . De mindnek vannak korlátai.

  • Válasszon a kissé rugalmasság elvesztése között
  • Ragaszkodnia kell a támogatott nyelvekhez
  • Nem használhatja a támogatott nyelveket, mert a projektjének natív, alacsony szintű könyvtárra van szüksége, amely csak nagyon specifikus rendszereken érhető el
  • A projekt olyan élvonalbeli technológiát használ, amely a következő években nem lesz elérhető a tömegek számára
  • Ezen platformok némelyike ​​nagyon (nagyon) drága, különösen nagyításkor

A Fargate (vagy a CaaS) mindkét világ legjavát nyújtja Önnek.

A konténeres architektúra biztosítja a szükséges rugalmasságot és irányítást. Lehetővé teszi bármilyen , bármilyen típusú rendszerben futó technológia használatát . A tároló szempont biztosítja, hogy minden hoszton azonos viselkedést folytasson, legyen szó fejlesztőről, tesztelésről, stádiumról vagy prod környezetről.

Ezt a pontot kritikusnak tartom sok tech startup esetében. Valójában néha az egyik versenyelőnye egy olyan korszerű technológia használata, amelynek kidolgozásában részt vett, vagy egy másik okos újrafelhasználása egy teljesen új és forradalmi kontextusban.

A kiszolgáló nélküli telepítés lehetővé teszi, hogy a nagyszerű kód írására összpontosítson. Nincs kiépítés, könnyű méretezés.

Határértékek

CaaS vs PaaS

Igaz, hogy feladja a valódi PaaS néhány jó szempontját. Igen, akkor is manuálisan kell frissítenie a tároló képeit, és néha meg kell írnia a saját Docker képeit. Ez eleinte küzdelem lehet, ha nem ismeri a rendszeradminisztráció alapjait .

De ez azt is jelenti, hogy nagyjából bármit megtehet, amire csak gondolhat, és teljes rugalmassággal és szabadsággal rendelkezik a használni kívánt rendszerekben, nyelvekben, eszközökben, könyvtárakban és verziókban.

Költség

Valljuk be, a felhőszolgáltatások (IaaS) drágábbak, mint a saját infrastruktúrája (ha igény szerint fel és le tudná méretezni). Ugyanezen okból költsége van annak, ha nem kell kiszolgálnia, kezelnie és méreteznie a szervereit. Lehet, hogy ez még nem a legjobb megoldás néhány legegyszerűbb felhasználási esetre.

Reméljük, hogy dolgoznak a költségek csökkentésén. Bármennyire is jó a termék, nehéz megalapozni az igény szerinti ekvivalens EC2 példány árának csaknem négyszeresét (például a t2.medium esetében).

Át kell állítanom az összes ECS-feladatot Fargate-re?

Még nem. Mint fentebb említettük, bizonyos esetekben több mint háromszorosára növeli költségeit. Amíg nem csökkentik a költségeket, lehet, hogy jobban jársz a szokásos EC2 instanszok használatával.

A Fargate azonban előnyösebb lehet az Ön számára a következő felhasználási esetekben:

  • Ha problémái vannak az ECS-feladatok hatékony automatikus méretezésével, és gyakran sok használaton kívüli CPU-val vagy memóriával rendelkezik . A Fargate szolgáltatással csak azokért az erőforrásokért fizet, amelyeket a feladatokban definiált .
  • Azokhoz a feladatokhoz, amelyek igény szerint vagy ütemezés szerint futnak , és nincs szükség külön EC2 példányra. A Fargate szolgáltatással csak akkor fizet, ha a feladata fut.
  • Azoknak a feladatoknak, amelyek csúcsminőségűek a memóriában és / vagy a CPU-ban . Csak azért, mert ezzel időt és gondot takaríthat meg az ilyen esetek konfigurálásával és kezelésével.

Bónusz

Azok számára, akik a Kubernetes- t részesítik előnyben az ECS helyett, a Fargate hamarosan futtathatja az Elastic Container Service for Kubernetes szolgáltatást.