hledat

Začněte vyhledáváním výše

  1. Domů
  2. Články
  3. Síla kontejnerizace. Bezpečně na vlastním písku

Síla kon­te­jner­izace. Bezpečně na vlast­ním písku

Karel Smutný
Síla kontejnerizace. Bezpečně na vlastním písku

Pátý díl ser­iálu o agilním řízení, který se zaměřu­je na tech­niky, jež dokážou proměnit velké týmy a složité pro­jek­ty v efek­tivní a spolupracu­jící sys­témy. Jako další přichází na řadu meto­da zvaná kon­te­jner­izace vývo­jového prostředí.

Větší firmy, které ještě použí­va­jí lega­cy architek­tu­ry, se potýka­jí s jed­ním prob­lémem: jejich sys­témy jsou všech­ny navzá­jem propo­jené, a pokud je potře­ba je testo­vat end-to-end, musí jich najed­nou běžet velký počet, všech­ny musí být naplněné daty a všech­ny musí běžet v určitém stavu. Tomu se říká prostředí.

Každý takový sys­tém má své pro­dukční prostředí – to, co běží v reálu pro skutečné zákazníky – a potom určitý počet testo­vacích, inte­gračních a vývo­jových prostředí. Na těch běží kopie daného soft­waru a pro různé úče­ly exis­tu­jí v různých nastaveních.

Rozbitost jako setr­valý stav

Pokud se tohle všech­no má blížit pro­dukční­mu prostředí, a tedy, jak jsme řek­li, toho musí běžet spous­ta, prostředí trpí. Jeho provoz je drahý a firmy větši­nou také postrá­da­jí dostateč­nou kapac­i­tu. Je běžné, že prostředí se neustále nachází v určitém stup­ni rozbitosti a nespolehlivosti. Pohy­bu­je se v něm totiž velké množství různých týmů, které v různých časech na různá mís­ta vklá­da­jí roz­man­ité a navzá­jem nekom­pat­i­bil­ní poža­davky a změny.

Nezmeške­jte žád­né novinky ITT

Výsledek? Pro­dražu­je se inte­grace, testování a vlast­ně i pouhé uvě­domění si toho, zda daná věc fun­gu­je tak, jak má. Ruku v ruce s tím jde i druhá záleži­tost: vývo­jová prostředí, v nichž nejde pouze o běh samot­né aplikace nebo sys­té­mu, ale i o vývo­jové nástro­je, vše­možné měřiče či kom­pilá­to­ry. Ty vyžadu­jí spous­tu různých nas­tavení, což větši­nou vývo­jáři udržu­jí na svých vlast­ních počí­tačích – na každém oper­ačním sys­té­mu trochu jinak, v různých verzích a podob­ně. Zmatek.

Jak z něj ven?

Jed­nou ces­tou je kon­te­jner­izace vývo­jového prostředí.
Takový kon­te­jn­er je vir­tuál­ní prostředí, které může běžet buď na lokál­ním počí­tači, nebo v cloudu. Obsahu­je buď konkrét­ní přes­né nas­tavení běhové aplikace, kter­ou vyvíjíme, nebo jde o takz­vaný vývo­jový kon­te­jn­er, v němž máme celé své vývo­jové prostředí.
Velk­ou výhodou takového kon­te­jneru je, že jej lze velice snad­no rep­liko­vat, lze ho držet v libo­vol­ném poč­tu instancí – každý vývo­jář nebo tým tak mohou mít svou vlast­ní instan­ci kon­te­jneru, která zák­lad­ní nas­tavení napros­to přes­ně replikuje.

V pří­padě vyví­jených aplikací jsme tím­to způ­sobem schop­ni vytvořit celé velké vývo­jové prostředí lev­něji, než jak na to jde ona výše pop­saná tradiční meto­da, a snáz jej naplnit pro­tokolo­vatel­ný­mi daty (která pocho­pitel­ně i tady musí něk­do udržovat). 

Cílem je pomo­ci týmům, které tes­tu­jí aplikaci end-to-end v nějakém větším prostředí, aby měly svou vlast­ní kopii a nemuse­ly se bát, že jim jejich prá­ci kdosi v nepřed­ví­datel­né chvíli rozbije.

Málo pros­toru pro spory

Zároveň vývo­jáři mohou mít své vlast­ní vývo­jové kon­te­jn­ery, ve kterých mají i nas­tavení vešk­erých vývo­jových nástro­jů – všich­ni ste­jné. To elimin­u­je neustálé spory o to, proč něko­mu něco nefun­gu­je nebo fun­gu­je jinak, pro­tože má něco nas­tavené odlišně, klid­ně i jen mal­ičko odlišně než ostatní.

V kon­te­jneru to je všech­no ste­jné. Jak už zazně­lo, kon­te­jn­er běží buď na lokál­ním počí­tači v nějakém vir­tuál­ním stro­ji, nebo v cloudu.
Ke kon­te­jneru se pak připo­jím z jakéhoko­liv počí­tače odkud­ko­liv, a jak­mile mám hoto­vo, zas­tavím ho a výpočet­ní výkon může využí­vat zase něk­do jiný.

Tohle je ces­ta, jak usnad­nit přípravu vývo­jového prostředí, jak usnad­nit jeho správu a elim­i­no­vat zbytečné prob­lémy ply­noucí z toho, že něk­do má něco nas­tavené trochu jinak. A co se aplikačních prostředí týká, mělo by to usnad­nit i inte­graci a testování, a tím pádem zrych­lit i smyčku zpět­ných rozběhů u zákazníků.

Zde se nabízí i propo­jení s trunk-based devel­op­mentem, který jsme probírali dříve. Jed­ná se pocho­pitel­ně o dvě nezávis­lé tech­niky, ale pokud máme vysok­ou míru autom­a­ti­zace, testování, a tudíž onen žádoucí con­tin­u­ous-inte­gra­tion trunk-based devel­op­ment, můžeme udržo­vat svou aplikaci neustále ve funkčním stavu, můžeme aktu­al­i­zo­vat i kon­te­jn­ery na nejnovější verze a usnad­nit tím testování i ostat­ním týmům, které daný kon­te­jn­er využí­va­jí pro testování svých věcí.

Mohlo by vás také zajímat

Síla kontejnerizace. Bezpečně na vlastním písku