← Containers / containers / platform-details
Životní cyklus kontejneru
Nasazení
Po nasazení aplikace s Container se váš image nahraje do Cloudflare Registry a globálně distribuován do sítě Cloudflare. Cloudflare předem naplánuje instance a po celém světě předem stáhne obrazy, aby zajistil rychlé časy spuštění při navyšování počtu souběžných instancí kontejneru.
Kód Workeru se stane aktivním ihned po nasazení. Instance kontejneru se aktualizují s rollout. Viz Nasaďte Containers.
Životní cyklus požadavku
Klient na Worker
Připomeňme, že Containers využívají jako podklad Durable Objects a Workers. Požadavky jsou nejprve směrovány přes Worker, o který se obvykle stará datacentrum v lokalitě s nejlepší latencí mezi sebou a uživatelem, který požadavek odeslal. Pro optimalizaci celkové latence může být vybráno jiné datacentrum, pokud Smart Placement je aktivní, nebo pokud je nejbližší lokalita přetížená.
Protože všechny požadavky na Container procházejí přes Worker, koncoví uživatelé nemohou vůči instanci Container provádět jiné než HTTP požadavky TCP nebo UDP. Pokud potřebujete případ použití, který vyžaduje příchozí TCP nebo UDP od koncového uživatele, obraťte se na dejte nám vědět ↗.
Worker k Durable Object
Z Worker prochází požadavek přes instanci Durable Object ( Třída Container rozšiřuje třídu Durable Object). Každá instance Durable Object je globálně směrovatelný izolát, který dokáže spouštět kód a ukládat stav. Díky tomu mohou vývojáři snadno adresovat konkrétní instance kontejnerů a směrovat k nim provoz (bez ohledu na to, kde jsou umístěny), definovat a spouštět hooky při změnách stavu kontejneru, provádět opakované kontroly instance a ukládat trvalý stav spojený s každou instancí.
Spuštění kontejneru
Když instance Durable Object vyžádá spuštění nové instance kontejneru, nejbližší lokalita s předem načteným image je vybráno.
Spuštění dalších instancí kontejneru využije jiné lokality s předem staženými image a Cloudflare na pozadí automaticky začne připravovat další stroje pro další škálování a rychlé cold starty. Protože počet předehřátých lokalit je omezený, některé instance kontejneru se mohou spustit v lokalitách vzdálenějších od koncového uživatele. Děje se to proto, aby instance kontejneru naběhla rychle. Platíte pouze za aktivně běžící instance, ne za nevyužité předehřáté image.
Studené starty
Studený start nastává, když se instance kontejneru spouští z úplně zastaveného stavu.
Pokud zavoláte env.MY_CONTAINER.get(id) s zcela novým ID a tuto instanci
spustíte poprvé, dojde ke cold startu.
Tím se poprvé spustí obraz kontejneru od jeho entrypointu. V závislosti
na tom, co tento entrypoint dělá, bude spuštění trvat různě dlouho.
Studené starty kontejneru se často pohybují v rozmezí 1 až 3 sekund, což ale závisí na velikosti obrazu a době běhu kódu i na dalších faktorech.
Požadavky na běžící Containers
Když požadavek spouští se novou instanci kontejneru, vybere se nejbližší lokalita s předem staženým obrazem. Následné požadavky na konkrétní instanci, bez ohledu na to, odkud pocházejí, budou směrovány do této lokality, dokud instance zůstane aktivní.
Jakmile se však tato instance kontejneru zastaví a restartuje, budoucí požadavky mohou být směrovány na jiný lokalitě. Tato lokalita bude opět nejbližší lokalitou k původnímu požadavku, která má image již stažený.
Runtime kontejneru
Každá instance Container běží ve vlastním VM, což zajišťuje silnou
izolaci od ostatních úloh běžících v síti Cloudflare. Containers
by měly být vytvořeny pro linux/amd64 architektuře a měl by zůstat v rámci
limity velikosti.
Protokolování, sběr metrik a síťování se automaticky nastaví na každém kontejneru podle konfigurace vývojáře.
Vypnutí kontejneru
Třída Container nastavuje sleepAfter na výchozích 10 minut. Jeho výchozí onActivityExpired() implementace signalizuje kontejneru, aby se po tomto období nečinnosti zastavil. Délku tohoto období můžete změnit nebo hook přepsat vlastní implementací.
Instanci kontejneru můžete sami zastavit pomocí stop() nebo destroy().
Předtím, než platforma zastaví instanci kontejneru, provede následující:
- Odešle
SIGTERMhlavnímu procesu v kontejneru. - Čeká až 15 minut, než se tento proces ukončí.
- Odešle
SIGKILLpokud proces stále běží.
Zpracování SIGTERM ve vašem image, pokud před ukončením potřebujete provést úklid. Stejná posloupnost proběhne i při rollout nahradí instanci kontejneru novým image.
Hooky životního cyklu
Container třída poskytuje hooky, které spustí kód Workeru při změně stavu kontejneru:
onStart(): Spustí se po spuštění kontejneru.onStop(): Spustí se po ukončení procesu kontejneru. Přijímá návratový kód a důvod zastavení.onActivityExpired(): Spustí se, kdyžsleepAfterčasovač vyprší bez příchozích požadavků. Výchozí implementace volástop()k vypnutí kontejneru. Toto můžete použít k tomu, aby se kontejner zastavil pouze za určitých podmínek.onError(): Spustí se, když kontejner skončí s chybou.
Viz příklad status hooks pro úplnou implementaci.
Trvalý disk
Veškerý disk je dočasný. Když instance Container přejde do režimu spánku, při dalším spuštění bude mít nový disk podle definice v image kontejneru.
Snapshoty budou brzy k dispozici. Umožní uživatelům rychle uložit a obnovit disk celého kontejneru nebo adresáře.
Můžete také použít FUSE k trvalému uložení disku na R2 nebo jiná úložiště typu object storage. Nečekejte však při použití FUSE nativní výkon podobný SSD.
Ukázkový požadavek
- Vývojář nasadí Container. Cloudflare automaticky připraví instance v celé své síti.
- Požadavek odešle klient z Bariloche v Argentině. Dorazí na Worker v blízké lokalitě Cloudflare v Neuquenu v Argentině.
- Tento požadavek Workeru volá
getContainer(env.MY_CONTAINER, "session-1337"). Pod kapotou se tím spustí Durable Object, který následně voláthis.ctx.container.start. - Tím se vyžádá nejbližší volná instance Containeru. Cloudflare rozpozná, že volná instance je v Buenos Aires v Argentině, a spustí ji tam.
- Jiný uživatel potřebuje směrovat požadavek do stejného kontejneru. Jeho požadavek dorazí na Worker běžící v lokalitě Cloudflare v San Diegu v USA.
- Worker znovu volá
getContainer(env.MY_CONTAINER, "session-1337"). - Pokud stále běží počáteční instance kontejneru, požadavek se přesměruje do původního umístění v Buenos Aires. Jakmile počáteční kontejner usne, Cloudflare se znovu pokusí najít nejbližší „volnou“ instanci kontejneru, pravděpodobně v Severní Americe, a spustí instanci tam.