Ito ang una sa isang serye ng mga post tungkol sa mga pagbabago, pagpapahusay, at mga karagdagan sa paparating na Red Hat OpenShift platform 4.0 update na makakatulong sa iyong maghanda para sa paglipat sa bagong bersyon.
Mula sa sandaling unang nagtipon ang bagong komunidad ng Kubernetes sa opisina ng Google sa Seattle noong taglagas ng 2014, malinaw na ang proyekto ng Kubernetes ay nakatakdang baguhin ang paraan ng pagbuo at pag-deploy ng software ngayon. Kasabay nito, ang mga pampublikong tagapagbigay ng serbisyo sa cloud ay patuloy na aktibong namumuhunan sa pagbuo ng mga imprastraktura at serbisyo, na ginawang mas madali at mas madaling ma-access ang pagtatrabaho sa IT at paglikha ng software, at ginawa silang hindi kapani-paniwalang naa-access, na maaaring naisip ng iilan sa simula ng ang dekada.
Siyempre, ang pag-anunsyo ng bawat bagong serbisyo sa cloud ay sinamahan ng maraming mga talakayan sa mga eksperto sa Twitter, at ang mga debate ay isinagawa sa iba't ibang mga paksa - kabilang ang pagtatapos ng open source na panahon, ang pagbaba ng on-premise na IT, at ang hindi maiiwasang ng isang bagong monopolyo ng software. sa cloud, at kung paano papalitan ng bagong paradigm X ang lahat ng iba pang paradigm.
Hindi na kailangang sabihin, ang lahat ng mga pagtatalo na ito ay napakatanga
Ang katotohanan ay walang mawawala, at ngayon ay makikita natin ang isang exponential growth sa mga end products at ang paraan ng pagde-develop ng mga ito, dahil sa patuloy na paglitaw ng bagong software sa ating buhay. At sa kabila ng katotohanan na ang lahat sa paligid ay magbabago, sa parehong oras, sa esensya, ang lahat ay mananatiling hindi nagbabago. Ang mga developer ng software ay magsusulat pa rin ng code na may mga error, ang mga operations engineer at mga reliability specialist ay lalakad pa rin kasama ang mga pager at makakatanggap ng mga awtomatikong alerto sa Slack, ang mga manager ay gagana pa rin sa mga tuntunin ng OpEx at CapEx, at sa tuwing may mabibigo, ang senior na developer ay malungkot na buntong-hininga sa mga salitang: "Sinabi ko na sa iyo"...
Oh talaga dapat pag-usapan, ay kung anong mga tool ang maaari nating gamitin upang lumikha ng mas mahusay na mga produkto ng software, at kung paano nila mapapahusay ang seguridad at gawing mas madali at mas maaasahan ang pag-unlad. Habang nagiging mas kumplikado ang mga proyekto, lumalabas ang mga bagong panganib, at ngayon ang buhay ng mga tao ay nakadepende sa software na kailangan lang ng mga developer na subukang gawin ang kanilang mga trabaho nang mas mahusay.
Ang Kubernetes ay isa sa gayong tool. Ang trabaho ay isinasagawa upang pagsamahin ang Red Hat OpenShift sa iba pang mga tool at serbisyo sa isang solong platform na gagawing mas maaasahan, mas madaling pamahalaan, at mas ligtas ang software para sa mga user.
Sa sinabi nito, ang OpenShift team ay nagtatanong ng isang simpleng tanong:
Paano mo mapapadali at mas maginhawa ang pagtatrabaho sa Kubernetes?
Ang sagot ay nakakagulat na halata:
- i-automate ang mga kumplikadong aspeto ng deployment sa cloud o sa labas ng cloud;
- tumuon sa pagiging maaasahan habang itinatago ang pagiging kumplikado;
- patuloy na patuloy na nagtatrabaho upang maglabas ng simple at secure na mga update;
- makamit ang controllability at auditability;
- magsikap sa una na matiyak ang mataas na seguridad, ngunit hindi sa kapinsalaan ng kakayahang magamit.
Ang susunod na release ng OpenShift ay dapat isaalang-alang ang parehong karanasan ng mga tagalikha at ang karanasan ng iba pang mga developer na nagpapatupad ng software sa malaking sukat sa pinakamalaking kumpanya sa mundo. Bilang karagdagan, dapat itong isaalang-alang ang lahat ng naipon na karanasan ng mga bukas na ekosistema na sumasailalim sa modernong mundo ngayon. Kasabay nito, kinakailangan na iwanan ang lumang kaisipan ng amateur developer at lumipat sa isang bagong pilosopiya ng isang awtomatikong hinaharap. Kailangan nitong tulay ang agwat sa pagitan ng luma at bagong mga paraan ng pag-deploy ng software, at samantalahin nang husto ang lahat ng magagamit na imprastraktura—na-host man ito ng pinakamalaking provider ng cloud o tumatakbo sa maliliit na system sa gilid.
Paano makamit ang resultang ito?
Sa Red Hat, kaugalian na gumawa ng nakakainip at walang pasasalamat na trabaho sa loob ng mahabang panahon upang mapangalagaan ang itinatag na komunidad at maiwasan ang pagsasara ng mga proyekto kung saan kasangkot ang kumpanya. Ang open-source na komunidad ay naglalaman ng isang malaking bilang ng mga mahuhusay na developer na lumikha ng mga pinakapambihirang bagay - nakakaaliw, nakapagtuturo, nagbubukas ng mga bagong pagkakataon at simpleng maganda, ngunit, siyempre, walang sinuman ang umaasa sa lahat na lumipat sa parehong direksyon o ituloy ang mga karaniwang layunin. . Ang paggamit ng enerhiya na ito at pag-redirect nito sa tamang direksyon ay minsan kinakailangan upang bumuo ng mga lugar na makikinabang sa ating mga user, ngunit sa parehong oras dapat nating subaybayan ang pag-unlad ng ating mga komunidad at matuto mula sa kanila.
Sa simula ng 2018, nakuha ng Red Hat ang proyekto ng CoreOS, na may mga katulad na pananaw sa hinaharap - mas ligtas at maaasahan, na nilikha sa mga prinsipyo ng open-source. Ang kumpanya ay nagtrabaho upang higit pang bumuo ng mga ideyang ito at ipatupad ang mga ito, na inilalagay ang aming pilosopiya sa pagsasanay - sinusubukang tiyakin na ang lahat ng software ay tumatakbo nang ligtas. Ang lahat ng gawaing ito ay binuo sa Kubernetes, Linux, mga pampublikong ulap, pribadong ulap, at libu-libong iba pang mga proyekto na sumusuporta sa aming modernong digital ecosystem.
Ang bagong release ng OpenShift 4 ay magiging malinaw, awtomatiko at mas natural
Ang OpenShift platform ay gagana sa pinakamahusay at pinaka-maaasahang Linux operating system, na may bare-metal na suporta sa hardware, maginhawang virtualization, awtomatikong pagprograma ng imprastraktura at, siyempre, mga lalagyan (na sa pangkalahatan ay mga imahe ng Linux).
Kailangang maging secure ang platform sa simula, ngunit pinapayagan pa rin ang mga developer na madaling umulit—iyon ay, maging flexible at secure na sapat habang pinapayagan pa rin ang mga administrator na i-audit at pamahalaan ito nang madali.
Dapat nitong payagan ang software na patakbuhin "bilang isang serbisyo" at hindi humantong sa hindi mapamahalaang paglago ng imprastraktura para sa mga operator.
Papayagan nito ang mga developer na tumuon sa paglikha ng mga tunay na produkto para sa mga user at customer. Hindi mo na kailangang dumaan sa kagubatan ng mga setting ng hardware at software, at lahat ng hindi sinasadyang komplikasyon ay magiging isang bagay ng nakaraan.
OpenShift 4: NoOps platform na hindi nangangailangan ng maintenance
В inilarawan ang mga gawaing iyon na tumulong sa paghubog ng pananaw ng kumpanya para sa OpenShift 4. Ang layunin ng koponan ay pasimplehin ang mga pang-araw-araw na gawain ng pagpapatakbo at pagpapanatili ng software hangga't maaari, upang gawing madali at maluwag ang mga prosesong ito - kapwa para sa mga espesyalistang kasangkot sa pagpapatupad at para sa mga developer. Ngunit paano ka makakalapit sa layuning ito? Paano lumikha ng isang platform para sa pagpapatakbo ng software na nangangailangan ng kaunting interbensyon? Ano ang ibig sabihin ng NoOps sa kontekstong ito?
Kung susubukan mong mag-abstract, para sa mga developer ang mga konsepto ng "serverless" o "NoOps" ay nangangahulugang mga tool at serbisyo na nagbibigay-daan sa iyong itago ang "operational" na bahagi o bawasan ang pasanin na ito para sa developer.
- Hindi gumana sa mga system, ngunit sa mga interface ng application (mga API).
- Huwag mag-abala sa pagpapatupad ng software - hayaan ang provider na gawin ito para sa iyo.
- Huwag agad na gumawa ng malaking balangkas - magsimula sa pamamagitan ng pagsulat ng maliliit na piraso na magsisilbing "mga bloke ng gusali", subukang gawing gumagana ang code na ito sa data at mga kaganapan, at hindi sa mga disk at database.
Ang layunin, tulad ng dati, ay upang pabilisin ang mga pag-ulit sa pagbuo ng software, magbigay ng pagkakataon na lumikha ng mas mahusay na mga produkto, at upang ang developer ay hindi kailangang mag-alala tungkol sa mga system kung saan tumatakbo ang kanyang software. Alam na alam ng isang makaranasang developer na ang pagtutuon sa mga user ay maaaring mabilis na mabago ang larawan, kaya hindi ka dapat maglagay ng labis na pagsisikap sa pagsulat ng software maliban kung talagang sigurado kang kailangan ito.
Para sa mga propesyonal sa pagpapanatili at pagpapatakbo, ang salitang "NoOps" ay maaaring medyo nakakatakot. Ngunit kapag nakikipag-usap sa mga field engineer, nagiging malinaw na ang mga pattern at diskarte na ginagamit nila ay naglalayong tiyakin ang pagiging maaasahan at pagiging maaasahan (Site Reliability Engineering, SRE) ay may maraming pagkakatulad sa mga pattern na inilarawan sa itaas:
- Huwag pamahalaan ang mga system - i-automate ang kanilang mga proseso sa pamamahala.
- Huwag magpatupad ng software - gumawa ng pipeline para i-deploy ito.
- Iwasang pagsama-samahin ang lahat ng iyong serbisyo at hayaan ang pagkabigo ng isa na maging sanhi ng pagkabigo ng buong system—pagkalat ang mga ito sa iyong buong imprastraktura gamit ang mga tool sa automation, at ikonekta ang mga ito sa mga paraan na masusubaybayan at masusubaybayan.
Alam ng mga SRE na may maaaring magkamali at kailangan nilang subaybayan at ayusin ang problema—para i-automate nila ang nakagawiang gawain at magtakda ng mga error na badyet nang maaga para handa silang unahin at gumawa ng mga desisyon kapag may problema. .
Ang Kubernetes sa OpenShift ay isang platform na idinisenyo upang malutas ang dalawang pangunahing problema: sa halip na pilitin kang unawain ang mga virtual machine o load balancer API, gumagana ito sa mga abstraction na may mas mataas na pagkakasunud-sunod - mga proseso at serbisyo sa pag-deploy. Sa halip na mag-install ng mga ahente ng software, maaari kang magpatakbo ng mga lalagyan, at sa halip na magsulat ng iyong sariling monitoring stack, gamitin ang mga tool na magagamit na sa platform. Kaya, ang lihim na sarsa ng OpenShift 4 ay talagang walang lihim - ito ay isang bagay lamang ng pagkuha ng mga prinsipyo ng SRE at mga konseptong walang server at dalhin ang mga ito sa kanilang lohikal na konklusyon upang matulungan ang mga developer at mga inhinyero ng operasyon:
- I-automate at i-standardize ang imprastraktura na ginagamit ng mga application
- I-link ang deployment at mga proseso ng development nang magkasama nang hindi nililimitahan ang mga developer mismo
- Ang pagtiyak na ang paglulunsad, pag-audit, at pag-secure ng ika-XNUMX na serbisyo, feature, application, o buong stack ay hindi mas mahirap kaysa sa una.
Ngunit ano ang pagkakaiba sa pagitan ng OpenShift 4 platform at mga nauna nito at mula sa "standard" na diskarte sa paglutas ng mga naturang problema? Ano ang nagtutulak ng sukat para sa pagpapatupad at mga pangkat ng pagpapatakbo? Dahil sa katotohanan na ang hari sa sitwasyong ito ay ang kumpol. Kaya,
- Tinitiyak namin na malinaw ang layunin ng mga kumpol (Mahal na ulap, kinuha ko ang kumpol na ito dahil kaya ko)
- Umiiral ang mga makina at operating system para magsilbi sa cluster (Kamahalan)
- Pamahalaan ang estado ng mga host mula sa cluster, i-minimize ang kanilang muling pagtatayo (drift).
- Para sa bawat mahalagang elemento ng system, kailangan ng nanny (mekanismo) na susubaybay at mag-aalis ng mga problema
- Ang kabiguan ng *bawat* aspeto o elemento ng isang sistema at mga nauugnay na mekanismo ng pagbawi ay isang normal na bahagi ng buhay
- Ang buong imprastraktura ay dapat na i-configure sa pamamagitan ng API.
- Gamitin ang Kubernetes upang patakbuhin ang Kubernetes. (Oo, oo, hindi iyon isang typo)
- Ang mga update ay dapat na madali at walang problema sa pag-install. Kung aabutin ng higit sa isang pag-click upang mag-install ng update, maliwanag na may ginagawa kaming mali.
- Ang pagsubaybay at pag-debug ng anumang bahagi ay hindi dapat maging isang problema, at samakatuwid ang pagsubaybay at pag-uulat sa buong imprastraktura ay dapat ding maging madali at maginhawa.
Gustong makita ang mga kakayahan ng platform sa pagkilos?
Ang isang preview na bersyon ng OpenShift 4 ay naging available sa mga developer. Sa isang madaling gamitin na installer, maaari kang magpatakbo ng isang cluster sa AWS sa ibabaw ng Red Had CoreOS. Para magamit ang preview, kailangan mo lang ng AWS account para ibigay ang imprastraktura at isang set ng mga account para ma-access ang mga preview na larawan.
- Upang makapagsimula, pumunta sa at i-click ang “Magsimula”.
- Mag-log in sa iyong Red Hat account (o gumawa ng bago) at sundin ang mga tagubilin para i-set up ang iyong unang cluster.
Pagkatapos ng matagumpay na pag-install, tingnan ang aming mga tutorial upang makakuha ng mas malalim na pag-unawa sa mga system at konsepto na ginagawang madali at maginhawang paraan ang OpenShift 4 platform para patakbuhin ang Kubernetes.
Subukan ang bagong release ng OpenShift at ibahagi ang iyong opinyon. Kami ay nakatuon sa paggawa ng pakikipagtulungan sa Kumbernetes bilang naa-access at walang hirap hangga't maaari—ang kinabukasan ng NoOps ay magsisimula ngayon.
Pansin ngayon!
Sa kumperensya Sa Abril 20, isa sa mga developer ng OpenShift, si Vadim Rutkovsky, ay hahawak ng isang master class - sisirain niya ang sampung kumpol at pipilitin silang ayusin ang mga ito. Ang kumperensya ay binabayaran, ngunit sa promotional code na #RedHat makakakuha ka ng 37% na diskwento
Master class sa 17:15 - 18:15, at ang stand ay bukas buong araw. Mga T-shirt, sumbrero, sticker - ang karaniwan!
Hall #2
"Dito kailangang baguhin ang buong sistema: kinukumpuni namin ang mga sirang k8s cluster kasama ng mga certified mechanics."
Pinagmulan: www.habr.com