Dit is de eerste in een reeks berichten over de veranderingen, verbeteringen en toevoegingen in de komende Red Hat OpenShift platform 4.0-update die je zal helpen bij de voorbereiding op de overgang naar de nieuwe versie.
Vanaf het moment dat de jonge Kubernetes-gemeenschap zich voor het eerst verzamelde in het Google-kantoor in Seattle in de herfst van 2014, was het duidelijk dat het Kubernetes-project voorbestemd was om een revolutie teweeg te brengen in de manier waarop software vandaag de dag wordt ontwikkeld en geïmplementeerd. Tegelijkertijd bleven aanbieders van publieke clouddiensten actief investeren in de ontwikkeling van infrastructuur en diensten, waardoor het werken met IT en het creëren van software veel eenvoudiger en toegankelijker werd, en deze ongelooflijk toegankelijk werd, wat weinigen zich aan het begin van de crisis hadden kunnen voorstellen. de eeuw.
Uiteraard ging de aankondiging van elke nieuwe clouddienst gepaard met talloze discussies tussen experts op Twitter, en werden er debatten gevoerd over een verscheidenheid aan onderwerpen, waaronder het einde van het open source-tijdperk, de teloorgang van IT op locatie en de onvermijdelijkheid van een nieuw softwaremonopolie in de cloud, en hoe het nieuwe paradigma X alle andere paradigma’s zal vervangen.
Het behoeft geen betoog dat al deze geschillen erg dom waren
De realiteit is dat niets zal verdwijnen, en vandaag de dag kunnen we een exponentiële groei zien in eindproducten en de manier waarop ze worden ontwikkeld, als gevolg van de voortdurende opkomst van nieuwe software in ons leven. En ondanks het feit dat alles rondom zal veranderen, zal tegelijkertijd alles in wezen onveranderd blijven. Softwareontwikkelaars zullen nog steeds code met fouten schrijven, operations engineers en betrouwbaarheidsspecialisten zullen nog steeds met pagers rondlopen en automatische waarschuwingen ontvangen in Slack, managers zullen nog steeds werken in termen van OpEx en CapEx, en elke keer dat er een fout optreedt, zal de senior van de ontwikkelaar zucht verdrietig met de woorden: “Ik zei het je toch”...
echt waar besproken moeten worden, is welke hulpmiddelen we tot onze beschikking kunnen hebben om betere softwareproducten te maken, en hoe deze de beveiliging kunnen verbeteren en de ontwikkeling eenvoudiger en betrouwbaarder kunnen maken. Naarmate projecten complexer worden, ontstaan er nieuwe risico's, en tegenwoordig zijn de levens van mensen zo afhankelijk van software dat ontwikkelaars gewoon moeten proberen hun werk beter te doen.
Kubernetes is zo’n tool. Er wordt gewerkt aan het combineren van Red Hat OpenShift met andere tools en diensten in één platform dat de software betrouwbaarder, eenvoudiger te beheren en veiliger voor gebruikers zou maken.
Dat gezegd hebbende, stelt het OpenShift-team één simpele vraag:
Hoe kunt u het werken met Kubernetes eenvoudiger en handiger maken?
Het antwoord ligt verrassend voor de hand:
- automatiseer complexe aspecten van implementatie in de cloud of buiten de cloud;
- focus op betrouwbaarheid en verberg de complexiteit;
- voortdurend blijven werken aan het vrijgeven van eenvoudige en veilige updates;
- beheersbaarheid en controleerbaarheid realiseren;
- streven ernaar om in eerste instantie een hoge veiligheid te garanderen, maar dit mag niet ten koste gaan van de bruikbaarheid.
De volgende release van OpenShift zou rekening moeten houden met zowel de ervaring van de makers als de ervaring van andere ontwikkelaars die software op grote schaal implementeren bij de grootste bedrijven ter wereld. Bovendien moet het rekening houden met alle opgebouwde ervaringen met open ecosystemen die ten grondslag liggen aan de moderne wereld van vandaag. Tegelijkertijd is het noodzakelijk om de oude mentaliteit van de amateurontwikkelaar los te laten en over te stappen op een nieuwe filosofie van een geautomatiseerde toekomst. Het moet de kloof overbruggen tussen oude en nieuwe manieren om software te implementeren en optimaal profiteren van alle beschikbare infrastructuur, of deze nu wordt gehost door de grootste cloudprovider of op kleine systemen aan de rand draait.
Hoe dit resultaat te bereiken?
Bij Red Hat is het gebruikelijk om lange tijd saai en ondankbaar werk te doen om de gevestigde gemeenschap te behouden en de sluiting van projecten waarbij het bedrijf betrokken is te voorkomen. De open-sourcegemeenschap bevat een groot aantal getalenteerde ontwikkelaars die de meest buitengewone dingen creëren: vermakelijk, leerzaam, nieuwe kansen biedend en gewoonweg mooi, maar niemand verwacht natuurlijk dat iedereen in dezelfde richting beweegt of gemeenschappelijke doelen nastreeft . Het benutten van deze energie en het in de goede richting sturen ervan is soms nodig om gebieden te ontwikkelen die onze gebruikers ten goede komen, maar tegelijkertijd moeten we de ontwikkeling van onze gemeenschappen monitoren en van hen leren.
Begin 2018 verwierf Red Hat het CoreOS-project, dat vergelijkbare visies op de toekomst had: veiliger en betrouwbaarder, gecreëerd op basis van open-sourceprincipes. Het bedrijf heeft gewerkt aan de verdere ontwikkeling van deze ideeën en de implementatie ervan, waarbij onze filosofie in de praktijk is gebracht: we proberen ervoor te zorgen dat alle software veilig werkt. Al dit werk is gebouwd op Kubernetes, Linux, publieke clouds, private clouds en duizenden andere projecten die ten grondslag liggen aan 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, handige virtualisatie, automatische infrastructuurprogrammering en uiteraard containers (die in wezen gewoon Linux-images zijn).
Het platform moet vanaf het begin veilig zijn, maar ontwikkelaars toch in staat stellen om eenvoudig te herhalen, dat wil zeggen flexibel en veilig genoeg zijn, terwijl beheerders het nog steeds gemakkelijk kunnen controleren en beheren.
Het moet het mogelijk maken dat software ‘as a service’ wordt uitgevoerd en mag niet leiden tot een onbeheersbare groei van de infrastructuur voor operators.
Het stelt ontwikkelaars in staat zich te concentreren op het creëren van echte producten voor gebruikers en klanten. U hoeft niet meer door de jungle van hardware- en software-instellingen te waden en alle onbedoelde complicaties behoren tot het verleden.
OpenShift 4: NoOps-platform dat geen onderhoud nodig heeft
В beschreef de taken die de bedrijfsvisie voor OpenShift 4 hielpen vormgeven. Het doel van het team is om de dagelijkse taken van het bedienen en onderhouden van software zoveel mogelijk te vereenvoudigen, om deze processen eenvoudig en ontspannen te maken - zowel voor specialisten die betrokken zijn bij de implementatie als voor ontwikkelaars. Maar hoe kun je dichter bij dit doel komen? Hoe creëer je een platform voor het draaien van software dat minimale tussenkomst vereist? Wat betekent NoOps eigenlijk in deze context?
Als je probeert te abstraheren, dan betekenen de concepten ‘serverless’ of ‘NoOps’ voor ontwikkelaars tools en services waarmee je de ‘operationele’ component kunt verbergen of deze last voor de ontwikkelaar kunt minimaliseren.
- Werk niet met systemen, maar met applicatie-interfaces (API's).
- Doe geen moeite om software te implementeren; laat de provider het voor u doen.
- Begin niet meteen met het creëren van een groot raamwerk - begin met het schrijven van kleine stukjes die als "bouwstenen" zullen fungeren. Probeer deze code te laten werken met gegevens en gebeurtenissen, en niet met schijven en databases.
Het doel is, net als voorheen, om iteraties in de softwareontwikkeling te versnellen, de mogelijkheid te bieden betere producten te maken en zodat de ontwikkelaar zich geen zorgen hoeft te maken over de systemen waarop zijn software draait. Een ervaren ontwikkelaar is zich er terdege van bewust dat het focussen op gebruikers het beeld snel kan veranderen, dus je moet niet te veel moeite doen in het schrijven van software tenzij je er absoluut zeker van bent dat het nodig is.
Voor onderhouds- en operationele professionals klinkt het woord ‘NoOps’ misschien een beetje eng. Maar bij communicatie met veldingenieurs wordt het duidelijk dat de patronen en technieken die zij gebruiken om betrouwbaarheid en betrouwbaarheid te garanderen (Site Reliability Engineering, SRE) veel overeenkomsten vertonen met de hierboven beschreven patronen:
- Beheer geen systemen, maar automatiseer hun beheerprocessen.
- Implementeer geen software, maar creëer een pijplijn om deze te implementeren.
- Vermijd het bundelen van al uw services en laat het falen van één ervan ervoor zorgen dat het hele systeem faalt. Verspreid ze over uw hele infrastructuur met behulp van automatiseringstools en verbind ze op manieren die kunnen worden gemonitord en gemonitord.
SRE's weten dat er iets mis kan gaan en dat ze het probleem moeten opsporen en oplossen. Daarom automatiseren ze routinewerk en stellen ze vooraf foutenbudgetten in, zodat ze klaar zijn om prioriteiten te stellen en beslissingen te nemen als er zich een probleem voordoet.
Kubernetes in OpenShift is een platform dat is ontworpen om twee hoofdproblemen op te lossen: in plaats van u te dwingen virtuele machines of load balancer-API's te begrijpen, werkt het met abstracties van hogere orde: implementatieprocessen en services. In plaats van softwareagents te installeren, kunt u containers uitvoeren en in plaats van uw eigen monitoringstack te schrijven, de tools gebruiken die al op het platform beschikbaar zijn. Het geheime sausje van OpenShift 4 is dus eigenlijk geen geheim - het is gewoon een kwestie van SRE-principes en serverloze concepten meenemen naar hun logische conclusie om ontwikkelaars en operations engineers te helpen:
- Automatiseer en standaardiseer de infrastructuur waar applicaties gebruik van maken
- Koppel implementatie- en ontwikkelingsprocessen aan elkaar zonder ontwikkelaars zelf te beperken
- Ervoor zorgen dat het lanceren, controleren en beveiligen van de XNUMXe service, functie, applicatie of volledige stack niet moeilijker is dan de eerste.
Maar wat is het verschil tussen het OpenShift 4-platform en zijn voorgangers en van de ‘standaard’-aanpak voor het oplossen van dergelijke problemen? Wat drijft de schaalgrootte voor implementatie- en operationele teams? Vanwege het feit dat de koning in deze situatie het cluster is. Dus,
- We zorgen ervoor dat het doel van de clusters duidelijk is (Beste wolk, ik heb dit cluster opgepakt omdat het kon)
- Er bestaan machines en besturingssystemen om het cluster te bedienen (Majesteit)
- Beheer de status van hosts vanuit het cluster, minimaliseer het opnieuw opbouwen ervan (drift).
- Voor elk belangrijk element van het systeem is een oppas (mechanisme) nodig die problemen monitort en elimineert
- Het falen van *elk* aspect of element van een systeem en de bijbehorende herstelmechanismen zijn een normaal onderdeel van het leven
- De gehele infrastructuur moet via API worden geconfigureerd.
- Gebruik Kubernetes om Kubernetes uit te voeren. (Ja, ja, dat is geen typefout)
- Updates moeten eenvoudig en probleemloos te installeren zijn. Als er meer dan één klik nodig is om een update te installeren, doen we duidelijk iets verkeerd.
- Het monitoren en debuggen van welk onderdeel dan ook zou geen probleem moeten zijn, en daarom zou het volgen en rapporteren over de gehele infrastructuur ook eenvoudig en handig moeten zijn.
Wilt u de mogelijkheden van het platform in actie zien?
Er is een previewversie van OpenShift 4 beschikbaar gekomen voor ontwikkelaars. Met een eenvoudig te gebruiken installatieprogramma kunt u een cluster op AWS draaien bovenop Red Had CoreOS. Om de preview te gebruiken, heeft u alleen een AWS-account nodig om de infrastructuur in te richten en een set accounts om toegang te krijgen tot de preview-afbeeldingen.
- Ga naar om aan de slag te gaan en klik op “Aan de slag”.
- Log in op uw Red Hat-account (of maak een nieuw account) en volg de instructies om uw eerste cluster in te stellen.
Bekijk na een succesvolle installatie onze tutorials om een dieper inzicht te krijgen in de systemen en concepten die het OpenShift 4-platform zo'n gemakkelijke en handige manier maken om Kubernetes uit te voeren.
Probeer de nieuwe OpenShift-release en deel uw mening. We willen het werken met Kumbernetes zo toegankelijk en moeiteloos mogelijk maken: de toekomst van NoOps begint vandaag.
En nu aandacht!
Op de conferentie Op 20 april zal een van de OpenShift-ontwikkelaars, Vadim Rutkovsky, een masterclass houden - hij zal tien clusters breken en ze dwingen ze te repareren. De conferentie is betaald, maar met de actiecode #RedHat krijg je 37% korting
Masterclass van 17 - 15 uur en de stand is de hele dag geopend. T-shirts, hoeden, stickers - het gebruikelijke!
Hal #2
“Hier moet het hele systeem veranderd worden: kapotte k8s-clusters repareren we samen met gecertificeerde monteurs.”
Bron: www.habr.com