Dit is de eerste publicatie in een serie artikels die zijn gewijd aan de veranderingen, verbeteringen en aanvullingen in de komende update van het Red Hat OpenShift-platform naar 4.0, die zullen helpen bij de overgang naar de nieuwe versie.
Sinds het moment dat vertegenwoordigers van de zich net ontwikkelende Kubernetes-gemeenschap voor het eerst bijeenkwamen in de herfst van 2014 in het Google-kantoor in Seattle, was al duidelijk dat het Kubernetes-project destined was om de moderne benaderingen van softwareontwikkeling en -implementatie ingrijpend te veranderen. Tegelijkertijd bleven publieke cloudproviders actief investeren in de ontwikkeling van infrastructuur en diensten, wat het werken met IT en het creƫren van software aanzienlijk vergemakkelijkte en toegankelijker maakte, iets wat nog maar een paar jaar geleden moeilijk voorstelbaar was.
Natuurlijk ging de aankondiging van elke nieuwe cloudservice vergezeld van talloze discussies onder experts op Twitter, waarbij debatten over de meest uiteenlopende onderwerpen werden gevoerd - waaronder het einde van het tijdperk van open source, het verval van on-premises IT, de onvermijdelijkheid van een nieuwe softwaremonopolie in de cloud, en hoe het nieuwe paradigma X alle andere paradigma's zal vervangen.
Het spreekt voor zich dat al deze debatten behoorlijk onzinnig waren.
De realiteit is dat niets verloren gaat, en we vandaag de dag een exponentiƫle groei van eindproducten en de manieren waarop ze worden ontwikkeld, kunnen zien, dit alles gerelateerd aan de constante opkomst van nieuwe software in ons leven. En hoewel alles om ons heen zal veranderen, zal in wezen alles hetzelfde blijven. Softwareontwikkelaars zullen nog steeds code schrijven met fouten, operationele ingenieurs en betrouwbaarheidsspecialisten zullen nog steeds met pagers rondlopen en automatische meldingen in Slack ontvangen, en managers zullen nog steeds de termen OpEx en CapEx gebruiken, en telkens als er een storing optreedt, zal de senior ontwikkelaar treurig zuchten met de woorden: 'Ik heb het toch gezegd'...
Wat echt besproken zou moeten worden, dat zijn de tools die we tot onze beschikking hebben om kwalitatief betere softwareproducten te creƫren, en hoe ze de veiligheid verhogen en de ontwikkeling toegankelijker en betrouwbaarder maken. Met de toenemende complexiteit van projecten komen ook nieuwe risico's, en vandaag de dag hangt het leven van mensen zo sterk af van software dat ontwikkelaars er gewoon voor moeten zorgen dat ze hun werk beter doen.
Kubernetes is zo'n tool. Er wordt gewerkt aan de integratie ervan met andere tools en diensten binnen Red Hat OpenShift in Ć©Ć©n platform, dat software betrouwbaarder, gemakkelijker te beheren en veiliger voor de gebruikers moet maken.
Gezien dit alles stelt het OpenShift-team zichzelf Ć©Ć©n simpele vraag:
Hoe kunnen we het werken met Kubernetes eenvoudiger en gebruiksvriendelijker maken?
Het antwoord is verrassend voor de hand liggend:
- automatiseren van de complexe aspecten van implementatie in de cloud of on-premise;
- zich richten op betrouwbaarheid terwijl de complexiteit verborgen blijft;
- continu zorgen voor eenvoudige en veilige updates;
- streven naar controleerbaarheid en mogelijkheid tot audit;
- van meet af aan hoge beveiliging waarborgen, zonder in te boeten op gebruiksvriendelijkheid.
De volgende release van OpenShift moet rekening houden met zowel de ervaringen van de makers als met de ervaringen van andere ontwikkelaars die op grote schaal software implementeren in de grootste bedrijven ter wereld. Bovendien moet het al de opgedane ervaring van open ecosystemen in aanmerking nemen, die vandaag de dag de basis vormen van de moderne wereld. Het is ook noodzakelijk om afstand te nemen van de eerdere mentaliteit van de hobbyontwikkelaar en over te schakelen naar een nieuwe filosofie van een geautomatiseerde toekomst. Dit moet een 'brug' zijn tussen de oude en nieuwe manieren van software-implementatie en moet gebruik maken van alle beschikbare infrastructuur - ongeacht of deze wordt beheerd door de grootste cloudleverancier of draait op kleine systemen aan de rand.
Hoe bereiken we dit resultaat?
Bij Red Hat is het gebruikelijk om langdurig saaie en ondankbare taken uit te voeren, om de gevormde gemeenschap te behouden en te voorkomen dat projecten waaraan het bedrijf deelneemt worden gesloten. In de open-source gemeenschap zijn er talloze getalenteerde ontwikkelaars die de meest bijzondere dingen creƫren - vermakelijke, leerzame, mogelijkheden openende en gewoon mooie dingen. Natuurlijk verwacht niemand dat alle deelnemers in dezelfde richting bewegen of gezamenlijke doelen nastreven. Het gebruik van deze energie en het soms heroriƫnteren ervan is noodzakelijk voor de ontwikkeling van richtingen die nuttig zouden zijn voor onze gebruikers, maar tegelijkertijd moeten we de ontwikkeling van onze gemeenschappen volgen en van hen leren.
Begin 2018 kocht Red Hat het project CoreOS, dat vergelijkbare opvattingen had over de toekomst - veiliger en betrouwbaarder, gebaseerd op open-source principes. Het bedrijf werkte aan de verdere ontwikkeling van deze ideeƫn en hun uitvoering, met het doel onze filosofie te realiseren - proberen veilige werking van alle software te bereiken. Al dit werk is gebaseerd op Kubernetes, Linux, publieke clouds, private clouds en duizenden andere projecten die de basis vormen van ons moderne digitale ecosysteem.
De nieuwe release van OpenShift 4 zal duidelijk, geautomatiseerd en natuurlijker zijn.
Het OpenShift-platform zal werken met de beste en meest betrouwbare Linux-besturingssystemen, met bare-metal hardware-ondersteuning, gebruiksvriendelijke virtualisatie, automatische infrastructuurprogrammering en natuurlijk containers (die in feite gewoon Linux-images zijn).
Het platform moet vanaf het begin veilig zijn, maar tegelijkertijd de mogelijkheid bieden van gebruiksvriendelijke iteraties voor ontwikkelaars - dat wil zeggen, het moet voldoende flexibiliteit en betrouwbaarheid hebben, terwijl het nog steeds administrateurs in staat stelt tot auditing en het beheer eenvoudig te maken.
Het moet mogelijk maken om software "als een service" uit te voeren, zonder dat dit leidt tot onbeheerste groei van de infrastructuur voor operators.
Het stelt ontwikkelaars in staat om zich te concentreren op het maken van echte producten voor gebruikers en klanten. Ze hoeven zich niet door een doolhof van hardware- en software-instellingen te worstelen, en onverwachte complicaties zullen tot het verleden behoren.
OpenShift 4: Een NoOps-platform dat geen ondersteuning vereist
In werden de taken beschreven die hielpen om de visie van het bedrijf met betrekking tot OpenShift 4 te vormen. Het team heeft als taak om de dagelijkse operationele en onderhoudstaken voor software zoveel mogelijk te vereenvoudigen. Deze processen moeten soepel en moeiteloos zijn, zowel voor de implementatiespecialisten als voor de ontwikkelaars. Maar hoe kunnen we dit doel bereiken? Hoe creƫren we een platform voor het draaien van software dat minimaal ingrijpen vereist? Wat betekent NoOps in deze context?
Als we ons even kunnen abstraheren, dan betekenen de begrippen "serverless" of "NoOps" voor ontwikkelaars tools en diensten die de operationele component verbergen of de last voor de ontwikkelaar minimaliseren.
- Werk niet met systemen, maar met toepassingsinterfaces (API's).
- Zorg niet voor de software-implementatie ā laat het aan de provider over.
- Begin niet meteen met het creĆ«ren van een groot framework ā start met het schrijven van kleine fragmenten die als 'bouwstenen' fungeren. Zorg ervoor dat deze code werkt met gegevens en gebeurtenissen, en niet met schijven en databases.
De taak is, zoals altijd, om de iteraties in de softwareontwikkeling te versnellen, de mogelijkheid te bieden om kwalitatief betere producten te maken, en ervoor te zorgen dat de ontwikkelaar zich geen zorgen hoeft te maken over de systemen waarop zijn software draait. Een ervaren ontwikkelaar begrijpt goed dat als je je op de gebruikers richt, de situatie snel kan veranderen, daarom moet je niet te veel moeite steken in het schrijven van software als je niet absoluut zeker bent van de noodzaak ervan.
Voor specialisten die zich bezighouden met ondersteuning en exploitatie kan het woord 'NoOps' wat ontmoedigend klinken. Maar tijdens gesprekken met systeembeheerders wordt het duidelijk dat de patronen en methoden die zij gebruiken voor het waarborgen van betrouwbaarheid (Site Reliability Engineering, SRE) veel overeenkomsten vertonen met de hierboven beschreven patronen:
- Beheer geen systemen ā automatiseer het beheer van deze systemen.
- Geen software-implementatie ā creĆ«er een pipeline voor de uitrol ervan.
- Probeer niet al uw diensten samen te voegen en voorkom dat de storing van Ć©Ć©n dienst leidt tot de storing van het hele systeem ā verspreid ze over de hele infrastructuur met behulp van automatisering en verbind ze met de mogelijkheid tot controle en observatie.
SRE-specialisten weten dat er altijd iets mis kan gaan en dat ze problemen moeten opsporen en oplossen ā daarom automatiseren ze routinetaken en stellen ze vooraf acceptabele afwijkingen (error budgets) vast om voorbereid te zijn op prioritering en besluitvorming wanneer zich een probleem voordoet.
Kubernetes in OpenShift is een platform dat is ontworpen om twee belangrijke taken op te lossen: in plaats van dat u zich moet bezighouden met virtuele machines of API's van load balancers, werkt u met hoogwaardigere abstracties ā met implementatieprocessen en diensten. In plaats van softwareagents te installeren, kunt u containers starten, en in plaats van uw eigen monitoringstack te schrijven, kunt u gebruikmaken van de al beschikbare tools op het platform. Het geheim van OpenShift 4 is dus eigenlijk geen geheim ā het is gewoon een kwestie van de principes van SRE en serverloze concepten als basis te nemen en deze verder uit te werken, ter ondersteuning van ontwikkelaars en systeembeheerders:
- Automatiseer en standaardiseer de infrastructuur die door applicaties wordt gebruikt.
- Verbind de uitrol- en ontwikkelingsprocessen zonder de ontwikkelaars hierin te beperken.
- Zorg ervoor dat de lancering, controle en beveiliging van de honderdste dienst, functie, applicatie of gehele stack niet moeilijker zijn dan van de eerste.
Wat is het verschil tussen het OpenShift 4-platform en zijn voorgangers en de 'standaard'-benadering van dergelijke problemen? Hoe wordt schaling voor teams die zich bezighouden met implementatie en exploitatie bereikt? Het antwoord is dat de koning in deze situatie de cluster is. Dus,
- We zorgen ervoor dat de functie van clusters duidelijk is (Dure cloud, deze cluster heb ik opgezet omdat het me lukte)
- Machines en besturingssystemen bestaan om de cluster te ondersteunen (Uw Koninklijke Hoogheid)
- Beheer de status van hosts vanuit de cluster, minimaliseer hun drift.
- Voor elk belangrijk element van het systeem is er een nanny (mechanisme) nodig die problemen opspoort en oplost.
- De storing van *elke* aspect of element van het systeem vereist de bijbehorende herstelmechanismen - dit is een normaal onderdeel van het leven.
- Infrastructuur moet worden geconfigureerd via API.
- Gebruik Kubernetes om Kubernetes te draaien. (Ja, dit is geen typfout)
- Updates moeten eenvoudig en zonder moeite worden geĆÆnstalleerd. Als het meer dan Ć©Ć©n klik vereist om een update te installeren, doen we duidelijk iets verkeerd.
- Monitoring en debugging van elk component mogen geen probleem zijn, en bijgevolg moet het volgen en rapporteren over de hele infrastructuur ook eenvoudig en gebruiksvriendelijk zijn.
Wilt u de mogelijkheden van het platform in actie zien?
De bĆØtaversie van OpenShift 4 is beschikbaar voor ontwikkelaars. Met een gebruiksvriendelijke installateur kan een cluster op AWS bovenop Red Hat CoreOS worden gestart. Voor toegang tot de bĆØtaversie is alleen een AWS-account nodig om de infrastructuur te leveren en een set accounts om toegang te krijgen tot de bĆØtabeelden.
- Om aan de slag te gaan, gaat u naar en klik op 'Aan de slag'.
- Log in op uw Red Hat-account (of maak een nieuwe aan) en volg de instructies om uw eerste cluster in te stellen.
Na een succesvolle installatie, bekijk onze leeringsmaterialen , om een beter inzicht te krijgen in de systemen en concepten die het OpenShift 4-platform zo'n eenvoudig en gebruiksvriendelijk hulpmiddel maken voor het uitvoeren van Kubernetes.
Probeer de nieuwe release van OpenShift en deel je mening. We streven ernaar om het werken met Kubernetes zo toegankelijk en moeiteloos mogelijk te maken ā de toekomst van NoOps begint vandaag al.
Let nu op!
Op de conferentie Op 20 april geeft een van de ontwikkelaars van OpenShift, Vadim Rutkovsky, een masterclass ā hij gaat tien clusters kapotmaken en laat ze repareren. De conferentie is betaald, maar met de promotiecode #RedHat krijg je 37% korting.
De masterclass is van 17:15 tot 18:15, en de stand is de hele dag geopend. T-shirts, hoeden, stickers ā zoals altijd!
Zaal #2
"Hier moet het hele systeem veranderd worden: we repareren gebroken k8s-clusters samen met gecertificeerde monteurs."
Bron: habr.com
