CodeDeploy RESTART: do 6,1-krat hitrejši ponovni zagon

AWS je v objavi z dne 5. oktobra 2026 predstavil način RESTART za CodeDeploy: pri floti 50 instanc EC2 za uravnalnikom obremenitve ALB in reviziji velikosti 1 GB je postopek v njegovem preizkusu trajal 82,6 sekunde namesto 507,4 sekunde, kar pomeni do 6,1-krat hitrejši ponovni zagon. To je rezultat merjenja ponudnika v določeni konfiguraciji, ne zagotovljen čas za druge flote.

RESTART je namenjen aplikacijam na instancah EC2 in lokalnih strežnikih, kadar mora skupina za namestitev znova uporabiti svojo zadnjo uspešno revizijo. CodeDeploy pri tem vodi ponovni zagon kot namestitev: uporabi nastavitev za zaporedje instanc, izvede preverjanje delovanja, spremlja nastavljene alarme in ohrani pravila za povrnitev. Skrbnikom tako ni treba izbirati novega paketa samo zato, da bi aplikacija znova prebrala zunanjo konfiguracijo ali si opomogla po težavi s procesom.

Ista revizija, nov potek namestitve

Način RESTART ne izvede zgolj ukaza za ustavitev in zagon procesa. CodeDeploy iz zgodovine skupine določi zadnjo uspešno revizijo in ustvari nov zapis namestitve. Na izbranih instancah nato tečejo koraki ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart in ValidateService. Korak Install ponovno uporabi vsebino revizije, zato lahko odpravi tudi odstopanja v datotekah, ki jih upravlja CodeDeploy.

Pri koraku DownloadBundle je odločilna lokalna kopija arhiva. Dokumentacija agenta CodeDeploy navaja, da različica 2.1.0 uporablja kopijo revizije na instanci, manjkajoč ali nepopoln arhiv pa prenese znova. Starejši podprti agenti lahko izvedejo RESTART, vendar revizijo prenesejo in zato ne pridobijo prihranka zaradi lokalne ponovne uporabe. Nadgradnja na serijo 2.x je izbirna, njena razpoložljivost pa se še širi po regijah AWS.

Za aplikacijo, ki streže zahtevam prek uravnalnika obremenitve, je pomembna še sprememba pri prometu. RESTART preskoči koraka BlockTraffic in AllowTraffic, instanca pa med ustavitvijo in ponovnim zagonom aplikacije ostane registrirana. Zato mora ApplicationStop prenehati sprejemati novo delo in ustrezno zaključiti zahteve, ki že tečejo. ValidateService nato preveri, ali je aplikacija po zagonu pripravljena, preden CodeDeploy nadaljuje po floti.

Od kod prihranek časa

Največji prihranek v objavljenem preizkusu je nastal pri floti za ALB, kjer se združita ponovna uporaba lokalnega arhiva in izpuščeno upravljanje prometa. Pri običajni namestitvi se koraki za promet ponavljajo skozi zaporedne skupine instanc; pri RESTART jih ni. V preizkušenih flotah brez ALB je bila razlika praviloma manjša, saj tega dela postopka ni bilo mogoče preskočiti.

Primerjava zajema različne velikosti flot in nastavitve zaporedja, zato najvišji rezultat ne opisuje vseh primerov uporabe. Trajanje v posameznem okolju bodo spreminjali še skripti v datoteki AppSpec, hitrost zagona aplikacije, velikost revizije in delež instanc z uporabno lokalno kopijo. Na novo dodana ali zamenjana instanca bo morda morala arhiv prenesti; tudi zanjo se uporabi ista revizija, določena iz zadnje uspešne namestitve skupine.

Kdaj izbrati RESTART in kdaj novo namestitev

Ključno vprašanje je, ali mora na instancah ostati ista aplikacijska revizija. Neodvisna evidenca spremembe API z dne 27. avgusta 2026 beleži RESTART kot vrednost polja deploymentMode v klicu CreateDeployment za flote EC2 in lokalnih strežnikov. Vrednost STANDARD je namenjena namestitvi določene revizije.

RESTART: primeren je, ko je zadnja uspešna revizija skupine še vedno želena, proces pa je treba znova zagnati, denimo po spremembi zunanje konfiguracije. Skupina mora že imeti uspešno namestitev, iz katere lahko CodeDeploy prevzame revizijo.
Običajna namestitev: potrebna je, ko se spreminja aplikacijski paket ali ko želi ekipa izrecno izbrati drugo revizijo. Zahtevku RESTART se nova revizija ne priloži.
Zunanji skript: pride v poštev, če zahtevano zaporedje presega možnosti CodeDeploy. V tem primeru mora ekipa sama urediti omejevanje sočasnih ustavitev, preverjanje zdravja, odziv na alarme in sledljivost.

RESTART velja za namestitve na mestu na EC2 in lokalnih strežnikih, ne za skupine Amazon ECS ali AWS Lambda. Prav tako ni združljiv z možnostjo updateOutdatedInstancesOnly, ki izbira instance glede na zastarelo revizijo. Ker se ciljna revizija določi iz zgodovine skupine, je njena zadnja uspešna namestitev pomembnejša od paketa, ki ga ima skrbnik trenutno pripravljenega za naslednjo izdajo.

Alarmi in povrnitev med ponovnim zagonom

Pred zagonom flote nastavitev namestitve določa, koliko instanc se lahko obdeluje hkrati in koliko jih mora ostati zdravih. CodeDeployDefault.OneAtATime omeji poseg na eno instanco naenkrat; hitrejše zaporedje lahko hkrati prizadene večji del zmogljivosti. Preverjanje ValidateService mora zaznati dejansko pripravljenost konkretne aplikacije, saj uspešen zagon procesa sam po sebi še ne pomeni, da lahko sprejema delo.

Pregled alarmov CloudWatch je posebej pomemben med odpravljanjem incidenta. Če je alarm že v stanju ALARM, lahko CreateDeployment ustvari zapis namestitve, CodeDeploy pa postopek ustavi, ko med spremljanjem zazna stanje alarma. Možnost ignorePollAlarmFailure tega stanja ne prezre; nanaša se na primer, ko CodeDeploy ne more pridobiti stanja alarma.

Za posamezno namestitev je mogoče spremljanje alarmov izklopiti, vendar ta izbira izključi vse alarme skupine za ta poseg in zahteva dodatno dovoljenje codedeploy:UpdateDeploymentGroup. Takšna izjema je smiselna le v postopku za incident, ki že zagotavlja drug zanesljiv signal o zdravju storitve. Samodejna povrnitev deluje po pravilih skupine za ustrezne napake, ne more pa odpraviti zunanje spremembe konfiguracije, zaradi katere se aplikacija ni zagnala.

Izvedba in spremljanje

Za začetek je potreben klic CreateDeployment z imenom aplikacije, skupino za namestitev in vrednostjo RESTART v polju deploymentMode; polje za novo revizijo se izpusti. V AWS CLI temu ustreza ukaz aws deploy create-deployment z možnostmi --application-name, --deployment-group-name in --deployment-mode RESTART. Če zahtevek ne določi druge konfiguracije namestitve, se uporabi nastavitev skupine. Izbira Restart je na voljo tudi pri ustvarjanju namestitve v konzoli CodeDeploy.

Pred sprožitvijo so odločilni zadnja uspešna revizija skupine, delujoč agent na ciljnih instancah, njegova različica ter nastavitve alarmov in samodejne povrnitve. Po sprožitvi je mogoče prek identifikatorja namestitve spremljati njen status in rezultat posameznih korakov. Pri floti za uravnalnikom obremenitve ostaja najobčutljivejši trenutek ustavitev aplikacije na registrirani instanci: če storitev takrat še prejema zahteve, mora njeno varno praznjenje zagotoviti aplikacijski postopek.

Preberite tudi: