Tämä on ensimmäinen viestisarjassa, jossa käsitellään muutoksia, parannuksia ja lisäyksiä tulevaan Red Hat OpenShift 4.0 -alustan päivitykseen, joka auttaa sinua valmistautumaan uuteen versioon siirtymiseen.
Siitä hetkestä lähtien, kun aloitteleva Kubernetes-yhteisö kokoontui ensimmäisen kerran Googlen Seattlen toimistoon syksyllä 2014, Kubernetes-projektin tarkoitus oli mullistaa ohjelmistojen kehittäminen ja käyttöönotto nykyään. Samaan aikaan julkiset pilvipalveluntarjoajat jatkoivat aktiivista panostusta infrastruktuurin ja palvelujen kehittämiseen, mikä helpotti ja helpotti huomattavasti IT:n kanssa työskentelyä ja ohjelmistojen luomista sekä teki niistä uskomattoman edullisia, mitä harva olisi voinut kuvitella vuoden alussa. vuosikymmentä.
Tietysti jokaisen uuden pilvipalvelun julkistamisen yhteydessä käytiin lukuisia keskusteluja asiantuntijoiden kesken Twitterissä, ja keskusteluja käytiin useista eri aiheista – muun muassa avoimen lähdekoodin aikakauden päättymisestä, paikan päällä olevan IT:n taantumisesta ja väistämättömyydestä. uudesta ohjelmistomonopolista pilvessä ja kuinka uusi paradigma X korvaa kaikki muut paradigmat.
Tarpeetonta sanoa, että kaikki nämä kiistat olivat erittäin typeriä
Todellisuus on, että mikään ei katoa, ja tänään voimme nähdä räjähdysmäisen kasvun lopputuotteiden ja niiden kehitystapojen osalta, koska elämäämme tulee jatkuvasti uusia ohjelmistoja. Ja huolimatta siitä, että kaikki ympärillä muuttuu, samaan aikaan, pohjimmiltaan, kaikki pysyy muuttumattomana. Ohjelmistokehittäjät kirjoittavat edelleen virheitä sisältävää koodia, käyttöinsinöörit ja luotettavuusasiantuntijat kävelevät edelleen hakulaitteiden kanssa ja saavat automaattisia hälytyksiä Slackin kautta, johtajat toimivat edelleen OpEx- ja CapEx-konsepteissa, ja aina kun vika ilmenee, vanhempi kehittäjä huokaa surullisesti sanoin: "Minä sanoin sinulle niin"...
Todellako pitäisi keskustella, kertoo, mitä työkaluja meillä voi olla parempien ohjelmistotuotteiden luomiseen ja miten ne voivat parantaa turvallisuutta ja tehdä kehityksestä helpompaa ja luotettavampaa. Projektien monimutkaisuuden kasvaessa uudet riskit lisääntyvät, ja nykyään ihmisten elämä on niin riippuvaista ohjelmistoista, että kehittäjien on yksinkertaisesti yritettävä tehdä parempaa työtä.
Kubernetes on yksi tällainen työkalu. Red Hat OpenShift yhdistetään muihin työkaluihin ja palveluihin yhdeksi alustaksi, joka tekisi ohjelmistosta luotettavamman, helpommin hallittavan ja turvallisemman käyttäjille.
Tämän sanottuaan OpenShift-tiimi kysyy yhden yksinkertaisen kysymyksen:
Kuinka voit tehdä Kubernetesin kanssa työskentelystä helpompaa ja mukavampaa?
Vastaus on yllättävän selvä:
- automatisoida pilvessä tai pilven ulkopuolella tapahtuvan käyttöönoton monimutkaiset näkökohdat;
- keskittyä luotettavuuteen piilottaen samalla monimutkaisuuden;
- jatkaa jatkuvaa työtä yksinkertaisten ja turvallisten päivitysten julkaisemiseksi;
- saavuttaa valvottavuus ja tarkastettavuus;
- Pyri aluksi varmistamaan korkea turvallisuus, mutta ei käytettävyyden kustannuksella.
Seuraavassa OpenShift-julkaisussa tulisi ottaa huomioon sekä tekijöiden että muiden kehittäjien kokemukset, jotka toteuttavat ohjelmistoja suuressa mittakaavassa maailman suurimmissa yrityksissä. Lisäksi sen on otettava huomioon kaikki kertynyt kokemus avoimista ekosysteemeistä, jotka ovat nykymaailman taustalla. Samalla on hylättävä vanha amatöörikehittäjän mentaliteetti ja siirryttävä uuteen automatisoidun tulevaisuuden filosofiaan. Sen on kurottava umpeen vanhojen ja uusien ohjelmistojen käyttöönottotapojen välinen kuilu ja hyödynnettävä täysimääräisesti kaikkea saatavilla olevaa infrastruktuuria – olipa se sitten suurimman pilvipalvelun tarjoajan isännöimä tai pienissä järjestelmissä reunalla.
Miten tämä tulos saavutetaan?
Red Hatilla on tapana tehdä pitkästä aikaa tylsää ja kiittämätöntä työtä vakiintuneen yhteisön säilyttämiseksi ja yrityksen mukana olevien projektien sulkemisen estämiseksi. Avoimen lähdekoodin yhteisössä on valtava määrä lahjakkaita kehittäjiä, jotka luovat mitä erikoisimpia asioita - viihdyttäviä, opettavia, uusia mahdollisuuksia avaavia ja yksinkertaisesti kauniita, mutta tietysti kukaan ei odota kaikkien osallistujien liikkuvan samaan suuntaan tai pyrkivän yhteiseen. tavoitteet. Tämän energian valjastaminen ja suuntaaminen oikeaan suuntaan on joskus tarpeellista kehittääksemme käyttäjiämme hyödyttäviä alueita, mutta samalla meidän on seurattava yhteisöjemme kehitystä ja opittava niistä.
Vuoden 2018 alussa Red Hat osti CoreOS-projektin, jolla oli samanlainen näkemys tulevaisuudesta - turvallisempi ja luotettavampi, avoimen lähdekoodin periaatteilla luotu. Yritys on työskennellyt kehittääkseen näitä ideoita edelleen ja toteuttaakseen niitä soveltaen filosofiaamme käytäntöön - pyrkien varmistamaan, että kaikki ohjelmistot toimivat turvallisesti. Kaikki tämä työ on rakennettu Kubernetesille, Linuxille, julkisille pilville, yksityisille pilville ja tuhansille muille projekteille, jotka tukevat nykyaikaista digitaalista ekosysteemiämme.
OpenShift 4:n uusi julkaisu on selkeä, automatisoitu ja luonnollisempi
OpenShift-alusta toimii parhaiden ja luotettavimpien Linux-käyttöjärjestelmien kanssa, ja siinä on pelkkä metallituki, kätevä virtualisointi, automaattinen infrastruktuuriohjelmointi ja tietysti kontit (jotka ovat pohjimmiltaan vain Linux-kuvia).
Alustan on oltava suojattu alusta alkaen, mutta silti sen on sallittava kehittäjien helppo iteroida – eli olla riittävän joustava ja turvallinen, mutta silti antaa järjestelmänvalvojille mahdollisuuden tarkastaa ja hallita sitä helposti.
Sen pitäisi mahdollistaa ohjelmistojen käyttäminen "palveluna" eikä se saa johtaa operaattorien hallitsemattomaan infrastruktuurin kasvuun.
Sen avulla kehittäjät voivat keskittyä todellisten tuotteiden luomiseen käyttäjille ja asiakkaille. Sinun ei tarvitse kahlata läpi laitteisto- ja ohjelmistoasetusten viidakon, ja kaikki tahattomat komplikaatiot jäävät menneisyyteen.
OpenShift 4: NoOps-alusta, joka ei vaadi ylläpitoa
В kuvaili niitä tehtäviä, jotka auttoivat muotoilemaan yrityksen näkemystä OpenShift 4:stä. Tiimin tavoitteena on yksinkertaistaa ohjelmistojen päivittäisiä käyttö- ja ylläpitotehtäviä mahdollisimman paljon, tehdä näistä prosesseista helppoa ja rentoa - niin käyttöönottoon osallistuville asiantuntijoille kuin kehittäjille. Mutta kuinka voit päästä lähemmäksi tätä tavoitetta? Kuinka luoda alusta ohjelmistojen käyttämiselle, joka vaatii vähän väliintuloa? Mitä NoOps edes tarkoittaa tässä yhteydessä?
Jos yrität abstraktia, niin kehittäjille "palvelinton" tai "NoOps" tarkoittaa työkaluja ja palveluita, joiden avulla voit piilottaa "toiminnallisen" komponentin tai minimoida tämän kehittäjän taakan.
- Älä työskentele järjestelmien, vaan sovellusliittymien (API) kanssa.
- Älä vaivaudu asentamaan ohjelmistoja – anna palveluntarjoajan tehdä se puolestasi.
- Sinun ei pitäisi hypätä heti suuren kehyksen luomiseen - aloita kirjoittamalla pieniä palasia, jotka toimivat "rakennuspalikoina", yritä saada tämä koodi toimimaan tietojen ja tapahtumien kanssa, ei levyjen ja tietokantojen kanssa.
Tavoitteena on entiseen tapaan nopeuttaa iteraatioita ohjelmistokehityksessä, tarjota mahdollisuus luoda parempia tuotteita ja jotta kehittäjän ei tarvitse huolehtia järjestelmistä, joissa hänen ohjelmistonsa toimii. Kokenut kehittäjä tietää hyvin, että käyttäjiin keskittyminen voi muuttaa kuvaa nopeasti, joten sinun ei pitäisi vaivautua liikaa ohjelmistojen kirjoittamiseen, ellet ole täysin varma sen tarpeellisuudesta.
Kunnossapidon ja käytön ammattilaisille sana "NoOps" saattaa kuulostaa hieman pelottavalta. Mutta kun kommunikoimme kenttäinsinöörien kanssa, tulee ilmeiseksi, että heidän käyttämänsä luotettavuuden ja luotettavuuden varmistamiseen tähtäävillä malleilla ja tekniikoilla (Site Reliability Engineering, SRE) on monia yhtäläisyyksiä yllä kuvattujen mallien kanssa:
- Älä hallitse järjestelmiä – automatisoi niiden hallintaprosessit.
- Älä ota ohjelmistoa käyttöön – luo putki sen käyttöönottoa varten.
- Vältä yhdistämästä kaikkia palvelujasi ja antamasta yhden epäonnistumisen aiheuttaa koko järjestelmän epäonnistumisen – hajauttaa ne koko infrastruktuuriisi automaatiotyökalujen avulla ja yhdistä ne tavoilla, joita voidaan seurata ja valvoa.
SRE:t tietävät, että jokin voi mennä pieleen, ja heidän on löydettävä ja korjattava ongelma – joten he automatisoivat rutiinityöt ja asettavat virhebudjetit etukäteen, jotta he ovat valmiita priorisoimaan ja tekemään päätöksiä, kun ongelma ilmenee .
OpenShiftin Kubernetes on alusta, joka on suunniteltu ratkaisemaan kaksi pääongelmaa: sen sijaan, että se pakottaisi sinut ymmärtämään virtuaalikoneita tai kuormituksen tasapainotussovellusliittymiä, se toimii korkeamman asteen abstraktioiden - käyttöönottoprosessien ja -palvelujen kanssa. Ohjelmistoagenttien asentamisen sijaan voit ajaa säilöjä ja oman valvontapinon kirjoittamisen sijaan käyttää alustassa jo saatavilla olevia työkaluja. OpenShift 4:n salainen kastike ei siis todellakaan ole mikään salaisuus – on vain otettava SRE-periaatteet ja palvelimettomat konseptit ja viedä ne loogiseen lopputulokseen kehittäjien ja käyttösuunnittelijoiden auttamiseksi:
- Automatisoi ja standardoi sovellusten käyttämä infrastruktuuri
- Yhdistä käyttöönotto- ja kehitysprosessit toisiinsa rajoittamatta itse kehittäjiä
- Sen varmistaminen, että XNUMX. palvelun, ominaisuuden, sovelluksen tai koko pinon käynnistäminen, tarkastaminen ja suojaaminen ei ole vaikeampaa kuin ensimmäinen.
Mutta mitä eroa on OpenShift 4 -alustan ja sen edeltäjien välillä sekä "standardi" lähestymistavasta tällaisten ongelmien ratkaisemiseen? Mikä ohjaa toteutus- ja toimintatiimien mittakaavaa? Johtuen siitä, että kuningas tässä tilanteessa on klusteri. Niin,
- Varmistamme, että klustereiden tarkoitus on selvä (Rakas pilvi, otin tämän klusterin, koska pystyin)
- Koneita ja käyttöjärjestelmiä on olemassa palvelemaan klusteria (Teidän Majesteettinne)
- Hallitse klusterin isäntien tilaa, minimoi niiden uudelleenrakentaminen (ajautuminen).
- Jokaiselle tärkeälle järjestelmän elementille tarvitaan lastenhoitaja (mekanismi), joka valvoo ja poistaa ongelmia
- Järjestelmän *kaikkien* osien tai elementtien epäonnistuminen ja siihen liittyvät palautusmekanismit ovat normaali osa elämää
- Koko infrastruktuuri on määritettävä API:n kautta.
- Käytä Kubernetesia Kubernetesin suorittamiseen. (Kyllä, kyllä, se ei ole kirjoitusvirhe)
- Päivitysten asentamisen tulee olla helppoa ja vaivatonta. Jos päivityksen asentaminen kestää useamman kuin yhden napsautuksen, teemme ilmeisesti jotain väärin.
- Minkään komponentin tarkkailu ja vianetsintä ei saisi olla ongelma, ja siksi koko infrastruktuurin seurannan ja raportoinnin pitäisi myös olla helppoa ja kätevää.
Haluatko nähdä alustan ominaisuudet toiminnassa?
OpenShift 4:n esikatseluversio on tullut kehittäjien saataville. Helppokäyttöisen asennusohjelman avulla voit suorittaa klusterin AWS:ssä Red Had CoreOS:n päällä. Jotta voit käyttää esikatselua, tarvitset vain AWS-tilin infrastruktuurin luomiseen ja joukon tilejä esikatselukuvien käyttämiseen.
- Aloita siirtymällä kohtaan ja napsauta "Aloita".
- Kirjaudu sisään Red Hat -tilillesi (tai luo uusi) ja seuraa ohjeita ensimmäisen klusterin määrittämiseksi.
Kun asennus on onnistunut, tutustu opetusohjelmiimme saadaksesi syvemmän ymmärryksen järjestelmistä ja käsitteistä, jotka tekevät OpenShift 4 -alustasta niin helpon ja kätevän tavan käyttää Kubernetesia.
Kokeile uutta OpenShift-julkaisua ja kerro mielipiteesi. Olemme sitoutuneet tekemään Kumbernetesin kanssa työskentelystä mahdollisimman helppoa ja vaivatonta – NoOpsin tulevaisuus alkaa tänään.
Nyt huomio!
Konferenssissa 20. huhtikuuta yksi OpenShift-kehittäjistä, Vadim Rutkovsky, pitää mestarikurssin - hän rikkoo kymmenen klusteria ja pakottaa ne korjaamaan ne. Konferenssi on maksullinen, mutta tarjouskoodilla #RedHat saat 37% alennuksen
Mestarikurssi klo 17:15 - 18:15 ja osasto on auki koko päivän. T-paidat, hatut, tarrat - tavallista!
Hall nro 2
"Tässä koko järjestelmä on vaihdettava: korjaamme rikkinäisiä k8s-klustereita yhdessä sertifioitujen mekaanikkojen kanssa."
Lähde: will.com