Dette er det første i en række indlæg om ændringer, forbedringer og tilføjelser i den kommende Red Hat OpenShift-platform 4.0-opdatering, der vil hjælpe dig med at forberede overgangen til den nye version.
Fra det øjeblik, det spæde Kubernetes-fællesskab først samledes på Googles kontor i Seattle i efteråret 2014, var det klart, at Kubernetes-projektet var bestemt til at revolutionere den måde, software udvikles og implementeres på i dag. Samtidig fortsatte offentlige cloud-tjenesteudbydere med at investere aktivt i udviklingen af infrastruktur og tjenester, hvilket gjorde arbejdet med it og skabe software meget nemmere og mere tilgængeligt, og gjorde dem utroligt tilgængelige, hvilket de færreste kunne have forestillet sig i starten af årtiet.
Offentliggørelsen af hver ny cloud-tjeneste blev naturligvis ledsaget af adskillige diskussioner blandt eksperter på Twitter, og debatter blev ført om en række forskellige emner - herunder slutningen af open source-æraen, tilbagegangen af on-premises IT og uundgåeligheden af et nyt softwaremonopol i skyen, og hvordan det nye paradigme X vil erstatte alle andre paradigmer.
Det er overflødigt at sige, at alle disse stridigheder var meget dumme
Virkeligheden er, at intet vil forsvinde, og i dag kan vi se en eksponentiel vækst i slutprodukter og måden, de udvikles på, på grund af den konstante fremkomst af ny software i vores liv. Og på trods af, at alt omkring vil ændre sig, vil alt på samme tid i det væsentlige forblive uændret. Softwareudviklere vil stadig skrive kode med fejl, driftsingeniører og pålidelighedsspecialister vil stadig gå rundt med personsøgere og modtage automatiske advarsler i Slack, ledere vil stadig operere i koncepterne OpEx og CapEx, og hver gang der opstår en fejl, er den senior udvikleren. vil sukke trist med ordene: "Jeg sagde det til dig"...
virkelig bør diskuteres, er hvilke værktøjer vi kan have til rådighed for at skabe bedre softwareprodukter, og hvordan de kan forbedre sikkerheden og gøre udviklingen nemmere og mere pålidelig. I takt med at projektkompleksiteten øges, stiger nye risici også, og i dag er menneskers liv så afhængige af software, at udviklere simpelthen er nødt til at forsøge at gøre et bedre stykke arbejde.
Kubernetes er et sådant værktøj. Der arbejdes på at kombinere Red Hat OpenShift med andre værktøjer og tjenester til en enkelt platform, der vil gøre softwaren mere pålidelig, lettere at administrere og mere sikker for brugerne.
Når det er sagt, stiller OpenShift-teamet et enkelt spørgsmål:
Hvordan kan du gøre arbejdet med Kubernetes nemmere og mere bekvemt?
Svaret er overraskende indlysende:
- automatisere komplekse aspekter af implementering i skyen eller uden for skyen;
- fokus på pålidelighed og samtidig skjule kompleksitet;
- fortsætte med at arbejde på at frigive enkle og sikre opdateringer;
- opnå kontrollerbarhed og auditerbarhed;
- bestræbe sig på i første omgang at sikre høj sikkerhed, men ikke på bekostning af brugervenlighed.
Den næste udgivelse af OpenShift bør tage højde for både skabernes erfaring og erfaringerne fra andre udviklere, der implementerer software i stor skala i de største virksomheder i verden. Derudover skal den tage højde for al den akkumulerede erfaring med åbne økosystemer, der ligger til grund for den moderne verden i dag. Samtidig er det nødvendigt at opgive amatørudviklerens gamle mentalitet og flytte til en ny filosofi om en automatiseret fremtid. Den skal bygge bro mellem gamle og nye måder at implementere software på og drage fuld fordel af al tilgængelig infrastruktur – uanset om den hostes af den største cloud-udbyder eller kører på små systemer i kanten.
Hvordan opnår man dette resultat?
Hos Red Hat er det kutyme at lave kedeligt og utaknemmeligt arbejde i lang tid for at bevare det etablerede samfund og forhindre lukning af projekter, som virksomheden er involveret i. Open source-fællesskabet indeholder et stort antal talentfulde udviklere, der skaber de mest ekstraordinære ting - underholdende, lærerige, åbne op for nye muligheder og simpelthen smukke, men selvfølgelig er der ingen, der forventer, at alle deltagere bevæger sig i samme retning eller forfølger fælles mål. At udnytte denne energi og omdirigere den i den rigtige retning er nogle gange nødvendigt for at udvikle områder, der vil gavne vores brugere, men samtidig skal vi overvåge udviklingen af vores samfund og lære af dem.
I begyndelsen af 2018 købte Red Hat CoreOS-projektet, som havde lignende syn på fremtiden - mere sikkert og pålideligt, skabt efter open source-principper. Virksomheden har arbejdet på at videreudvikle disse ideer og implementere dem, og omsætte vores filosofi i praksis - forsøge at sikre, at al software kører sikkert. Alt dette arbejde er bygget på Kubernetes, Linux, offentlige skyer, private skyer og tusindvis af andre projekter, der understøtter vores moderne digitale økosystem.
Den nye udgivelse af OpenShift 4 vil være klar, automatiseret og mere naturlig
OpenShift-platformen vil fungere med de bedste og mest pålidelige Linux-operativsystemer, med bar-metal hardware-understøttelse, praktisk virtualisering, automatisk infrastrukturprogrammering og selvfølgelig containere (som i det væsentlige kun er Linux-billeder).
Platformen skal være sikker fra starten, men stadig give udviklere mulighed for nemt at iterere – det vil sige være fleksibel og sikker nok, mens den stadig giver administratorer mulighed for nemt at revidere og administrere den.
Det skal gøre det muligt at køre software "som en tjeneste" og ikke føre til uoverskuelig infrastrukturvækst for operatører.
Det vil give udviklere mulighed for at fokusere på at skabe rigtige produkter til brugere og kunder. Du behøver ikke at vade gennem junglen af hardware- og softwareindstillinger, og alle utilsigtede komplikationer vil være fortid.
OpenShift 4: NoOps platform, der ikke kræver vedligeholdelse
В beskrev de opgaver, der var med til at forme virksomhedens vision for OpenShift 4. Teamets mål er at forenkle de daglige opgaver med drift og vedligeholdelse af software så meget som muligt, for at gøre disse processer nemme og afslappede – både for specialister involveret i implementering og for udviklere. Men hvordan kan du komme tættere på dette mål? Hvordan skaber man en platform til at køre software, der kræver minimal indgriben? Hvad betyder NoOps overhovedet i denne sammenhæng?
Hvis du forsøger at abstrahere, så betyder begreberne "serverløs" eller "NoOps" for udviklere værktøjer og tjenester, der giver dig mulighed for at skjule den "operative" komponent eller minimere denne byrde for udvikleren.
- Arbejd ikke med systemer, men med applikationsgrænseflader (API'er).
- Lad være med at implementere software - lad udbyderen gøre det for dig.
- Du skal ikke springe ud i at skabe en stor ramme med det samme - start med at skrive små stykker, der vil fungere som "byggeklodser", prøv at få denne kode til at fungere med data og hændelser, og ikke med diske og databaser.
Målet er som tidligere at fremskynde iterationer i softwareudvikling, give mulighed for at skabe bedre produkter, og så udvikleren ikke skal bekymre sig om de systemer, som hans software kører på. En erfaren udvikler er godt klar over, at fokus på brugerne hurtigt kan ændre billedet, så du skal ikke lægge for mange kræfter i at skrive software, medmindre du er helt sikker på, at det er nødvendigt.
For fagfolk i vedligeholdelse og drift kan ordet "NoOps" lyde lidt skræmmende. Men når man kommunikerer med feltingeniører, bliver det indlysende, at de mønstre og teknikker, de bruger med det formål at sikre pålidelighed og pålidelighed (Site Reliability Engineering, SRE) har mange ligheder med mønstrene beskrevet ovenfor:
- Administrer ikke systemer – automatiser deres ledelsesprocesser.
- Implementer ikke software - opret en pipeline til at implementere den.
- Undgå at samle alle dine tjenester sammen og lade fejlen i en få hele systemet til at svigte – spred dem på tværs af hele din infrastruktur ved hjælp af automatiseringsværktøjer, og tilslut dem på måder, der kan overvåges og overvåges.
SRE'er ved, at noget kan gå galt, og de bliver nødt til at spore og løse problemet – så de automatiserer rutinearbejde og sætter fejlbudgetter på forhånd, så de er klar til at prioritere og træffe beslutninger, når der opstår et problem.
Kubernetes i OpenShift er en platform designet til at løse to hovedproblemer: i stedet for at tvinge dig til at forstå virtuelle maskiner eller load balancer API'er, fungerer den med abstraktioner af højere orden - implementeringsprocesser og tjenester. I stedet for at installere softwareagenter kan du køre containere, og i stedet for at skrive din egen overvågningsstack, kan du bruge de værktøjer, der allerede er tilgængelige på platformen. Så den hemmelige sauce af OpenShift 4 er virkelig ingen hemmelighed - det er bare et spørgsmål om at tage SRE-principper og serverløse koncepter og tage dem til deres logiske konklusion for at hjælpe udviklere og driftsingeniører:
- Automatiser og standardiser den infrastruktur, som applikationer bruger
- Knyt implementerings- og udviklingsprocesser sammen uden at begrænse udviklerne selv
- At sikre, at lancering, revision og sikring af den XNUMX. tjeneste, funktion, applikation eller hele stakken ikke er sværere end den første.
Men hvad er forskellen mellem OpenShift 4-platformen og dens forgængere og fra "standard"-tilgangen til at løse sådanne problemer? Hvad driver skalaen for implementerings- og driftsteams? På grund af det faktum, at kongen i denne situation er klyngen. Så,
- Vi sørger for, at formålet med klyngerne er klart (Kære sky, jeg hentede denne klynge, fordi jeg kunne)
- Maskiner og operativsystemer findes til at betjene klyngen (Deres Majestæt)
- Administrer status for værter fra klyngen, minimer deres genopbygning (drift).
- For hvert vigtigt element i systemet er der behov for en barnepige (mekanisme), der vil overvåge og eliminere problemer
- Svigt af *hvert* aspekt eller element af et system og tilhørende genopretningsmekanismer er en normal del af livet
- Hele infrastrukturen skal konfigureres via API.
- Brug Kubernetes til at køre Kubernetes. (Ja, ja, det er ikke en tastefejl)
- Opdateringer skal være nemme og problemfri at installere. Hvis det tager mere end et klik at installere en opdatering, så gør vi åbenbart noget forkert.
- Overvågning og fejlretning af enhver komponent bør ikke være et problem, og derfor bør sporing og rapportering på tværs af hele infrastrukturen også være let og bekvemt.
Vil du se platformens muligheder i aktion?
En forhåndsvisningsversion af OpenShift 4 er blevet tilgængelig for udviklere. Med et brugervenligt installationsprogram kan du køre en klynge på AWS oven på Red Had CoreOS. For at bruge forhåndsvisningen behøver du kun en AWS-konto til at klargøre infrastrukturen og et sæt konti for at få adgang til forhåndsvisningsbillederne.
- Gå til for at komme i gang og klik på "Kom i gang".
- Log ind på din Red Hat-konto (eller opret en ny), og følg instruktionerne for at konfigurere din første klynge.
Efter vellykket installation, tjek vores tutorials at få en dybere forståelse af de systemer og koncepter, der gør OpenShift 4-platformen til en så nem og bekvem måde at køre Kubernetes på.
Prøv den nye OpenShift-udgivelse og del din mening. Vi er forpligtet til at gøre arbejdet med Kumbernetes så tilgængeligt og ubesværet som muligt – fremtiden for NoOps starter i dag.
Og nu opmærksomhed!
På konferencen Den 20. april afholder en af OpenShift-udviklerne, Vadim Rutkovsky, en mesterklasse – han vil bryde ti klynger og tvinge dem til at rette dem. Konferencen er betalt, men med kampagnekoden #RedHat får du 37% rabat
Master class kl 17:15 - 18:15, og standen er åben hele dagen. T-shirts, hatte, klistermærker - det sædvanlige!
Hal #2
"Her skal hele systemet ændres: vi reparerer ødelagte k8s-klynger sammen med certificerede mekanikere."
Kilde: www.habr.com