Toto je prvá publikácia v sérii materiálov, ktoré sa zaoberajú zmenami, vylepšeniami a doplnkami v nadchádzajúcej aktualizácii platformy Red Hat OpenShift na verziu 4.0, ktoré pomôžu pripraviť sa na prechod na novú verziu.
Od momentu, keď sa zástupcovia len sa formujúceho spoločenstva Kubernetes po prvýkrát stretli na jeseň 2014 v kancelárii Google v Seattli, bolo jasné, že projektu Kubernetes je súdené zásadne zmeniť moderné prístupy k vývoju a nasadzovaniu softvéru. Zároveň verejní poskytovatelia cloudových služieb naďalej aktívne investovali do rozvoja infraštruktúry a služieb, čo výrazne uľahčilo a zjednodušilo prácu s IT a vytváranie softvéru a sprístupnilo ich, čo si málokto dokázal predstaviť ešte na začiatku desaťročia.
Samozrejme, oznámenie každého nového cloudového servisu bolo sprevádzané početnými diskusiami odborníkov na Twitteri, pričom spory sa viedli na rôzne témy – vrátane konca éry otvorených zdrojových kódov, úpadku IT na strane klientov (on-premises IT), nevyhnutnosti novej softvérovej monopolizácie v cloude, a o tom, ako nová paradigma X nahradí všetky ostatné paradigmy.
Nestojí za to hovoriť, že všetky tieto spory boli dosť hlúpe.
Realita je taká, že nič nikam nezmizne, a dnes môžeme pozorovať exponenciálny rast konečných produktov a spôsobov ich vývoja, čo súvisí s neustálym objavovaním nového softvéru v našich životoch. A aj keď sa všetko okolo mení, v podstate všetko zostáva nezmenené. Vývojári softvéru budú naďalej písať kód s chybami, prevádzkoví inžinieri a odborníci na spoľahlivosť budú naďalej nosiť pagery a prijímať automatické upozornenia v Slacku, manažéri budú rovnako používať pojmy OpEx a CapEx, a zakaždým, keď dôjde k poruche, starší vývojár bude smutne vzdychať slovami: „Hovoril som ti to“...
Čo naozaj by sa malo prediskutovať, to je to, aké nástroje máme k dispozícii na vytváranie kvalitnejších softvérových produktov, a ako nám umožňujú zvýšiť bezpečnosť a uľahčiť a zefektívniť vývoj. S rastúcou zložitosti projektov sa objavujú aj nové riziká, a dnes sú životy ľudí do veľkej miery závislé od softvéru, takže vývojári sú jednoducho povinní snažiť sa vykonávať svoju prácu lepšie.
Kubernetes je jedným z takýchto nástrojov. Pracuje sa na tom, aby sa v rámci Red Hat OpenShift spojil s ďalšími nástrojmi a službami do jednej platformy, ktorá by učinila softvér spoľahlivejším, jednoduchým na správu a bezpečným pre používateľov.
S ohľadom na uvedené sa tím OpenShift pýta jednu jednoduchú otázku:
Ako môžeme zjednodušiť a spríjemniť prácu s Kubernetes?
Odpoveď je prekvapivo očividná:
- automatizovať zložité aspekty nasadenia na cloude alebo mimo neho;
- sústrediť sa na spoľahlivosť, pritom skryť zložitosti;
- pokračovať v neustálom uvoľňovaní jednoduchých a bezpečných aktualizácií;
- dosiahnuť kontrolovateľnosť a možnosť auditu;
- usilovať sa o zabezpečenie vysokej úrovne bezpečnosti od samého začiatku, ale nie na úkor použiteľnosti.
Ďalšie vydanie OpenShift by malo zohľadniť skúsenosti jeho tvorcov aj skúsenosti iných vývojárov, ktorí vo veľkom zavádzajú softvér v najväčších spoločnostiach na svete. Okrem toho je potrebné zohľadniť celú nahromadenú skúsenosť otvorených ekosystémov, ktoré dnes tvoria základ moderného sveta. Zároveň je potrebné vzdať sa starého mentality hobistu a prejsť na novú filozofiu automatizovanej budúcnosti. Musí to byť "most" medzi starými a novými spôsobmi nasadenia softvéru a plne využiť všetku dostupnú infraštruktúru – bez ohľadu na to, či ju spravuje najväčší poskytovateľ cloudu alebo je spustená na malých systémoch na periférii.
Ako dosiahnuť takýto výsledok?
V Red Hat je bežné vykonávať dlhé, nudné a nevďačné úlohy, aby sme udržali existujúce komunity a zabránili zániku projektov, na ktorých sa spoločnosť podieľa. V open-source komunite je množstvo talentovaných vývojárov, ktorí vytvárajú najneobyčajnejšie veci – zábavné, vzdelávacie, otvárajúce nové možnosti a jednoducho krásne. Samozrejme, nikto neočakáva, že všetci účastníci budú kráčať jedným smerom alebo sledovať spoločné ciele. Využitie tejto energie, jej preorientovanie správnym smerom, je niekedy potrebné na rozvoj oblastí, ktoré by boli užitočné našim používateľom, no zároveň musíme sledovať vývoj našich komunít a učiť sa od nich.
Na začiatku roka 2018 Red Hat odkúpila projekt CoreOS, ktorý mal podobné názory na budúcnosť – bezpečnejšiu a spoľahlivejšiu, vytvorenú na princípoch open-source. Spoločnosť pracovala na ďalšom rozvoji týchto myšlienok a ich realizácii, uskutočňujúc našu filozofiu – snažiť sa o bezpečnú prevádzku všetkého softvéru. Celá táto práca je postavená na Kubernetes, Linuxe, verejných clouder, súkromných clouder a tisíckach ďalších projektov, ktoré tvoria základ našej modernej digitálnej ekosystém.
Nová verzia OpenShift 4 bude intuitívna, automatizovaná a prirodzenejšia.
Platforma OpenShift bude fungovať s najlepšími a najspoľahlivejšími operačnými systémami Linux, s bare-metal hardvérovou podporou, pohodlnou virtualizáciou, automatizovaným programovaním infraštruktúry a, samozrejme, kontajnermi (ktoré sú v podstate len obrazmi Linuxu).
Platforma by mala byť bezpečná od samého začiatku, ale zároveň umožniť pohodlné iterácie pre vývojárov – teda mať dostatočnú flexibilitu a spoľahlivosť, pričom stále umožňuje administrátorom vykonávať audit a zabezpečovať pohodlie pri správe.
Mala by umožniť spúšťanie softvéru „vo forme služby“ a nezapričiniť neprimeraný rast infraštruktúry pre operátorov.
Umožní vývojárom sústrediť sa na vytváranie skutočných produktov pre používateľov a klientov. Nebudú musieť preniknúť cez množstvo nastavení hardvéru a softvéru, a všetky náhodné komplikácie zostanú minulosťou.
OpenShift 4: NoOps platforma, ktorá nevyžaduje údržbu
V Boli opísané úlohy, ktoré pomohli formovať víziu spoločnosti týkajúcu sa OpenShift 4. Tím má za úlohu maximálne zjednodušiť každodenné úlohy spojené s prevádzkou a údržbou softvéru, urobiť tieto procesy jednoduchými a bezproblémovými – tak pre odborníkov, ktorí sa zaoberajú implementáciou, ako aj pre vývojárov. Akým spôsobom je však možné priblížiť sa k tomuto cieľu? Ako vytvoriť platformu na spúšťanie softvéru, ktorá si vyžaduje minimálny zásah? Čo vlastne znamená NoOps v tomto kontexte?
Ak sa pokúsite abstrahovať, pre vývojárov pojmy „serverless“ alebo „NoOps“ znamenajú nástroje a služby, ktoré umožňujú skryť „prevádzkovú“ zložku alebo minimalizovať toto bremeno pre vývojára.
- Pracujte nie so systémami, ale s aplikačnými rozhraniami (API).
- Nestarajte sa o implementáciu softvéru – nech to robí za vás poskytovateľ.
- Nemali by ste sa vrhnúť na vytváranie veľkého rámca – začnite písaním malých fragmentov, ktoré budú slúžiť ako „stavebné bloky“, snažte sa, aby tento kód pracoval s dátami a udalosťami, a nie s diskami a databázami.
Úloha zostáva rovnaká ako predtým: urýchliť iterácie pri vývoji softvéru, zabezpečiť možnosť vytvárania kvalitnejších produktov, a aby sa pritom vývojár nemusel obávať o systémy, na ktorých sa jeho softvér spúšťa. Skúsený vývojár veľmi dobre chápe, že ak sa sústredí na používateľov, môže sa situácia rýchlo zmeniť, preto by sa nemal vkladať príliš veľa úsilia do písania softvéru, ak nemáte absolútnu istotu o jeho potrebe.
Pre odborníkov zameraných na podporu a údržbu môže slovo „NoOps“ znieť trochu desivo. Ale počas rozhovorov s operačnými inžiniermi sa stáva jasným, že vzory a metodiky, ktoré používajú na zabezpečenie spoľahlivosti (Site Reliability Engineering, SRE), majú mnoho spoločného s vyššie uvedenými vzormi:
- Nezvládajte systémy – automatizujte procesy ich správy.
- Nezameriavajte sa na zavádzanie softvéru – vytvorte pipeline na jeho nasadenie.
- Snažte sa nespojiť všetky vaše služby dohromady a nedovoľte, aby zlyhanie jednej z nich viedlo k zlyhaniu celého systému – rozmiestnite ich po celej infraštruktúre s použitím automatizačných nástrojov a prepojte ich tak, aby ste mali možnosť kontroly a sledovania.
SRE odborníci vedia, že niečo môže ísť zle, a budú musieť sledovať a riešiť problém – preto automatizujú rutinnú prácu a vopred stanovujú prípustné odchýlky (error budgets), aby sa mohli pripraviť na prioritizáciu a rozhodovanie pri vzniku problémov.
Kubernetes v OpenShift je platforma navrhnutá na to, aby riešila dve hlavné úlohy: namiesto nútenia vás, aby ste sa zaoberali virtuálnymi strojmi alebo API rozhraním vyvážovacích zariadení, sa pracuje s abstrakciami vyššej úrovne – s procesmi nasadenia a službami. Namiesto inštalácie softvérových agentov môžete spustiť kontajnery a namiesto písania vlastného monitorovacieho stacku môžete využiť už dostupné nástroje na platforme. Takže tajomný ingredienciou OpenShift 4 v skutočnosti není žiadna záhada – stačí si vziať za základ princípy SRE a bezserverové koncepcie a doplniť ich až do logického záveru, na pomoc developerom a operačným inžinierom:
- Automatizovať a štandardizovať infraštruktúru, ktorá sa používa aplikáciami
- Prepojiť procesy nasadenia a vývoja, bez obmedzovania samotných developerov
- Dosiahnuť, aby spustenie, audit a zabezpečenie stého servisu, funkcie, aplikácie alebo celého stacku bolo rovnako jednoduché, ako pre prvý.
Aké sú rozdiely medzi platformou OpenShift 4 a jej predchodcami, ako aj medzi „štandardným“ prístupom k riešeniu podobných problémov? Ako sa dosahuje škálovanie pre tím, ktorý sa zaoberá nasadzovaním a prevádzkou? Kľúčovým prvkom tu je klaster. Takže,
- Zabezpečme, aby účel klastrov bol jasný (Drahé cloudové riešenie, tento klaster som postavil, pretože som vedel ako).
- Stroje a operačné systémy existujú, aby slúžili klastrom (Vaša Veličenstvo).
- Spravujte stav hostiteľov z klastrov a minimalizujte ich transformácie.
- Pre každý dôležitý prvok systému je potrebný „opatrovateľ“ (mechanizmus), ktorý bude sledovať a odstraňovať problémy.
- Zlyhanie *akéhokoľvek* aspektu alebo prvku systému zodpovedajúce mechanizmy obnovy – to je bežná súčasť života.
- Celá infraštruktúra by mala byť konfigurovaná prostredníctvom API.
- Použite Kubernetes na spustenie Kubernetes. (Áno, nie je to preklep).
- Aktualizácie by sa mali inštalovať jednoducho a bez námahy. Ak na inštaláciu aktualizácie potrebujete viac ako jedno kliknutie myši, očividne niečo robíme zle.
- Monitorovanie a ladenie akéhokoľvek komponentu by nemalo predstavovať problém, a preto by sledovanie a hlásenie celej infraštruktúry malo byť taktiež jednoduché a pohodlné.
Chcete vidieť schopnosti platformy v akcii?
Predbežná verzia OpenShift 4 je teraz dostupná pre vývojárov. S pomocou jednoduchého inštalátora môžete spustiť klaster na AWS nad Red Hat CoreOS. Na využitie predbežnej verzie potrebujete iba účet AWS na poskytnutie infraštruktúry a súbor účtov na prístup k obrazom predbežnej verzie.
- Ak chcete začať, prejdite na a kliknite na "Začať".
- Prihláste sa do svojho účtu Red Hat (alebo si vytvorte nový) a riadte sa pokynmi na nastavenie vášho prvého klastrového prostredia.
Po úspešnej inštalácii si pozrite naše školiace materiály , aby ste získali podrobnejší prehľad o systémoch a konceptoch, ktoré robia platformu OpenShift 4 tak jednoduchým a pohodlným nástrojom na spustenie Kubernetes.
Vyskúšajte novú verziu OpenShift a podeľte sa o svoje názory. Snažíme sa sprístupniť prácu s Kubernetes čo najviac a bez námahy – budúcnosť NoOps začína už dnes.
A teraz pozor!
Na konferencii 20. apríla jeden z vývojárov OpenShift, Vadim Rutkovský, usporiada workshop – rozbije desať klastrov a nechá ich opraviť. Konferencia je spoplatnená, ale s promo kódom #RedHat zľava 37%.
Workshop je od 17:15 do 18:15 a stánok funguje celý deň. Tričká, čiapky, nálepky – ako obvykle!
Sála #2
„Celý systém treba zmeniť: opravujeme rozbité k8s klastre spoločne so certifikovanými technikmi.“
Zdroj: habr.com
