Dette er den første publikation i en serie af materialer, der omhandler ændringer, forbedringer og tilføjelser i den kommende opdatering af Red Hat OpenShift til version 4.0, som vil hjælpe med at forberede overgangen til den nye version.
Siden det øjeblik, hvor repræsentanterne fra det stadigvæk dannende Kubernetes-samfund første gang mødtes i efteråret 2014 i Googles kontor i Seattle, kunne man allerede sige, at Kubernetes-projektet var bestemt til fundamentalt at ændre de moderne tilgange til udvikling og implementering af software. Samtidig fortsatte de offentlige leverandører af cloud-tjenester aktivt med at investere i udviklingen af infrastruktur og tjenester, hvilket gjorde arbejdet med IT og softwareudvikling betydeligt lettere og mere tilgængeligt, noget som få kunne forestille sig i begyndelsen af årtiet.
Selvfølgelig var annonceringen af hver ny cloud-tjeneste ledsaget af adskillige diskussioner blandt eksperter på Twitter, hvor debatterne dækkede mange emner – herunder slutningen på æraen med open source, nedgangen af on-premises IT, uundgåeligheden af en ny softwaremonopol i skyen, og hvordan den nye X-paradigme ville erstatte alle de øvrige paradigmer.
Det er værd at nævne, at alle disse diskussioner var temmelig tåbelige.
Realiteten er, at intet forsvinder, og vi ser i dag en eksponentiel vækst i slutprodukter og måder at udvikle dem på, hvilket skyldes den kontinuerlige fremkomst af ny software i vores liv. Og selvom alt omkring os vil ændre sig, vil essensen forblive uændret. Softwareudviklere vil stadig skrive kode med fejl, driftsingeniører og specialister i drift vil fortsætte med at bære pagere og modtage automatiske notifikationer i Slack, og ledere vil fortsat arbejde med begreberne OpEx og CapEx. Hver gang der opstår en fejl, vil den senior udvikler sukke trist og sige: "Jeg sagde det..."
Hvad der virkelig burde diskuteres, så dette er, hvilke værktøjer vi kan få til rådighed for at skabe kvalitetssoftwareprodukter, og hvordan de kan forbedre sikkerheden og gøre udviklingen enklere og mere pålidelig. Med stigende kompleksitet i projekter opstår nye risici, og i dag afhænger menneskers liv i så høj grad af software, at udviklere simpelthen er nødt til at gøre deres arbejde bedre.
Kubernetes er et af disse værktøjer. Der arbejdes på at integrere det i Red Hat OpenShift sammen med andre værktøjer og tjenester til en samlet platform, der gør software mere pålidelig, nemt at administrere og sikker for brugerne.
Med dette in mente stiller OpenShift-teamet sig selv et simpelt spørgsmål:
Hvordan kan vi gøre arbejdet med Kubernetes enklere og mere bekvemt?
Svaret er overraskende indlysende:
- at automatisere de komplekse aspekter ved distribution i skyen eller uden for skyen;
- at fokusere på pålidelighed ved at skjule kompleksiteten;
- at fortsætte med at levere enkle og sikre opdateringer regelmæssigt;
- at opnå kontrol og mulighed for revision;
- at sigte mod at sikre høj sikkerhed fra starten uden at gå på kompromis med brugervenligheden.
Den næste version af OpenShift skal tage højde for både erfaringerne fra skaberne og erfaringerne fra andre udviklere, der implementerer software i stor skala i verdens største virksomheder. Desuden skal den tage hensyn til al den erfaring, der er opbygget indenfor åbne økosystemer, som i dag danner grundlaget for den moderne verden. Det er nødvendigt at overgive det tidligere mindset hos amatørudviklere og bevæge sig mod en ny filosofi om et automatiseret fremtid. Det skal være en 'bro' mellem de gamle og nye måder at distribuere software på og udnytte al tilgængelig infrastruktur – uanset om den drives af den største cloud-udbyder eller kører på små systemer i kanten.
Hvordan opnår vi dette resultat?
I Red Hat er det almindeligt at udføre langtrukken og utaknemmelig arbejde for at bevare det etablerede fællesskab og for at undgå lukning af projekter, som virksomheden deltager i. Open-source fællesskaberne rummer et væld af talentfulde udviklere, der skaber de mest eventyrlige ting – underholdende, lærende, nye muligheder og simpelthen smukke. Men selvfølgelig forventer ingen, at alle deltagere bevæger sig i samme retning eller forfølger fælles mål. Nogle gange er det nødvendigt at bruge denne energi og omdirigere den til de relevante retninger for at udvikle områder, som ville være nyttige for vores brugere, men samtidig skal vi holde øje med udviklingen i vores fællesskaber og lære af dem.
I begyndelsen af 2018 købte Red Hat projektet CoreOS, som havde en lignende vision for fremtiden – en mere sikker og pålidelig fremtid baseret på open-source principper. Virksomheden arbejdede videre med udviklingen af disse ideer og deres implementering, mens vi realiserede vores filosofi – stræbte efter en sikker drift af al software. Alt dette arbejde er baseret på Kubernetes, Linux, offentlige skyer, private skyer og tusindvis af andre projekter, der danner grundlaget for vores moderne digitale økosystem.
Den nye version af OpenShift 4 vil være forståelig, automatiseret og mere naturlig.
OpenShift-platformen vil arbejde sammen med de bedste og mest pålidelige Linux-operativsystemer, med bare-metal hardware support, bekvem virtualisering, automatisk infrastrukturprogrammering og naturligvis containere (som i bund og grund blot er Linux-billeder).
Platformen skal være sikker fra starten, samtidig med at den giver mulighed for nemme iterationer for udviklerne – det vil sige have tilstrækkelig fleksibilitet og pålidelighed, mens den stadig tillader administratorer at udføre revision og sikre nem håndtering.
Den skal muliggøre drift af software 'som en tjeneste' og ikke føre til ukontrolleret vækst af infrastrukturen for operatørerne.
Det vil give udviklere mulighed for at fokusere på at skabe reelle produkter til brugere og kunder. Man behøver ikke at kæmpe med en jungle af hardware- og softwareindstillinger, og alle uventede komplikationer vil være en saga blot.
OpenShift 4: En NoOps platform, der ikke kræver vedligeholdelse
I De opgaver, der blev beskrevet, hjalp med at danne virksomhedens vision for OpenShift 4. Teamet har som mål at forenkle daglige opgaver i forhold til drift og vedligeholdelse af software så meget som muligt, så disse processer bliver lette og ubesværede – både for specialister i implementering og for udviklere. Men hvordan kan man nærme sig dette mål? Hvordan skaber man en softwareplatform, der kræver minimal indgriben? Hvad betyder NoOps i denne sammenhæng?
Hvis man forsøger at abstrahere, betyder begreberne 'serverless' eller 'NoOps' for udviklere værktøjer og tjenester, der skjuler den 'driftsmæssige' komponent eller minimerer denne byrde for udvikleren.
- Arbejd ikke med systemer, men med applikationsgrænseflader (API'er).
- Engager jer ikke i softwareimplementering – lad udbyderen tage sig af det.
- Start ikke med at skabe et stort framework – begynd med at skrive små fragmenter, der fungerer som 'byggesten'; sørg for, at denne kode arbejder med data og begivenheder, ikke med diske og databaser.
Opgaven, som før, er at accelerere iterationerne i softwareudvikling, muliggøre skabelsen af mere kvalitetsprodukter, og samtidig give udvikleren ro omkring de systemer, på hvilke hans software kører. En erfaren udvikler forstår udmærket, at hvis man fokuserer på brugerne, kan situationen hurtigt ændre sig, så man bør ikke investere for meget tid i at skrive software, medmindre man har absolut tillid til dets nødvendighed.
For specialists involved in maintenance and operation, the term 'NoOps' might sound somewhat daunting. However, during conversations with operations engineers, it becomes clear that the patterns and methodologies they use, aimed at ensuring reliability (Site Reliability Engineering, SRE), greatly resonate with the aforementioned patterns.
- Don’t manage systems – automate the processes that manage them.
- Don’t focus on software implementation – create a pipeline for its deployment.
- Try not to consolidate all your services together and avoid having the failure of one service lead to the failure of the entire system – distribute them across the infrastructure using automation tools, and connect them with the possibility for control and monitoring.
SRE specialists know that things can go wrong, and they will need to track and resolve issues – therefore, they automate routine tasks and proactively define acceptable deviations (error budgets) to be prepared for prioritizing and decision-making when problems arise.
Kubernetes in OpenShift is a platform designed to address two main challenges: instead of forcing you to deal with virtual machines or load balancer APIs, it works with higher-order abstractions – with deployment processes and services. Instead of installing software agents, you can launch containers, and instead of writing your own monitoring stack, you can use the tools already available on the platform. Thus, the secret ingredient of OpenShift 4 is not really a secret – it’s simply about adopting SRE principles and serverless concepts and bringing them to fruition to assist developers and operations engineers.
- Automate and standardize the infrastructure used by applications.
- Connect deployment and development processes together without restricting the developers themselves.
- Ensure that launching, auditing, and securing the hundredth service, function, application, or entire stack is no more complex than the first.
Men hvad er forskellen på OpenShift 4-platformen i forhold til dens forgængere og den "standard" tilgang til at løse sådanne problemer? Hvordan opnås skalering for teams, der arbejder med implementering og drift? Det er, fordi kongen i denne situation er klyngen. Således,
- Lad os sørge for, at formålet med klynger er klart (Kostnadseffektivt sky, jeg oprettede denne klynge, fordi jeg kunne)
- Maskiner og operativsystemer findes for at betjene klyngen (Deres Majestæt)
- Administrer tilstanden på værterne fra klyngen og minimer deres drift.
- For hvert vigtigt element i systemet er der brug for en "barnepige" (mekanisme), der overvåger og løser problemer.
- Fejl i *enhver* aspekt eller element i systemet med de relevante genoprettelsesmekanismer er en normal del af livet.
- Hele infrastrukturen skal konfigureres via API.
- Brug Kubernetes til at køre Kubernetes. (Ja, det er ikke en trykfejl)
- Opdateringer skal installeres nemt og bekvemt. Hvis installationen af en opdatering kræver mere end ét musetryk, gør vi tydeligvis noget forkert.
- Overvågning og fejlfinding af enhver komponent bør ikke være et problem, og tilsvarende skal overvågning og rapportering på hele infrastrukturen også være enkelt og brugervenligt.
Vil du se platformens muligheder i aktion?
Den tidlige version af OpenShift 4 er blevet tilgængelig for udviklere. Med en brugervenlig installationsprogram kan du lancere en klynge på AWS oven på Red Hat CoreOS. For at bruge den tidlige version kræves der kun en AWS-konto for at levere infrastrukturen og et sæt konti for at få adgang til de tidlige versionsbilleder.
- For at komme i gang, gå til og klik på "Get Started".
- Log ind på din Red Hat-konto (eller opret en ny) og følg instruktionerne for at konfigurere din første klynge.
Efter en vellykket installation, kig på vores uddannelsesmaterialer , for at få en mere detaljeret forståelse af de systemer og koncepter, der gør OpenShift 4-platformen så enkel og brugervenlig til at køre Kubernetes.
Prøv den nye version af OpenShift og del din mening. Vi stræber efter at gøre arbejdet med Kubernetes så nemt som muligt – fremtiden for NoOps starter allerede i dag.
Og nu, vær opmærksom!
På konferencen Den 20. april vil en af udviklerne af OpenShift, Vadim Rutkovskiy, afholde en workshop – han vil bryde ti klynger og få dem til at reparere. Konferencen koster penge, men med promo-koden #RedHat får du 37% rabat.
Workshopen finder sted fra 17:15 til 18:15, og standen er åben hele dagen. T-shirts, hatte, klistermærker – som sædvanligt!
Saal #2
«Her skal hele systemet ændres: vi reparerer de ødelagte k8s klynger sammen med certificerede mekanikere».
Kilde: habr.com
