Når du arbejder med IT, begynder du at bemærke, at systemer har deres egen karakter. De kan være fleksible, lydløse, excentriske og strenge. De kan tiltrække eller frastøde. På en eller anden måde skal du "forhandle" med dem, manøvrere mellem "faldgruber" og bygge kæder af deres interaktion.
Så vi havde æren af at bygge en cloud-platform, og til dette var vi nødt til at "overtale" et par undersystemer til at arbejde sammen med os. Heldigvis har vi et "API-sprog", direkte hænder og en masse entusiasme.
Denne artikel vil ikke være teknisk hardcore, men vil beskrive de problemer, vi stødte på, mens vi byggede skyen. Jeg besluttede at beskrive vores vej i form af en let teknisk fantasi om, hvordan vi ledte efter et fælles sprog med systemer, og hvad der kom ud af det.
Velkommen til kat.
Begyndelsen af en rejse
For noget tid siden fik vores team til opgave at lancere en cloud-platform til vores kunder. Vi havde ledelsessupport, ressourcer, hardwarestak og frihed til at vælge teknologier til at implementere softwaredelen af tjenesten.
Der var også en række krav:
- tjenesten har brug for en praktisk personlig konto;
- platformen skal integreres i det eksisterende faktureringssystem;
- software og hardware: OpenStack + Tungsten Fabric (Open Contrail), som vores ingeniører har lært at "tilberede" ganske godt.
Vi fortæller dig en anden gang om, hvordan holdet blev samlet, den personlige kontogrænseflade blev udviklet og designbeslutninger blev truffet, hvis Habra-fællesskabet er interesseret.
De værktøjer, vi besluttede at bruge:
- Python + Flask + Swagger + SQLAlchemy - et helt standard Python-sæt;
- Vue.js til frontend;
- Vi besluttede at udføre interaktionen mellem komponenter og tjenester ved at bruge Selleri over AMQP.
Foregribe spørgsmål om valg af Python, jeg vil forklare. Sproget har fundet sin niche i vores virksomhed og en lille, men stadig kultur, har udviklet sig omkring det. Derfor blev det besluttet at begynde at bygge tjenesten på den. Desuden er hastigheden af udviklingen i sådanne problemer ofte afgørende.
Så lad os begynde vores bekendtskab.
Silent Bill - fakturering
Vi har kendt denne fyr i lang tid. Han sad altid ved siden af mig og talte tavst noget. Nogle gange videresendte han brugeranmodninger til os, udstedte kundefakturaer og administrerede tjenester. En almindelig hårdtarbejdende fyr. Sandt nok var der vanskeligheder. Han er tavs, nogle gange eftertænksom og ofte i sit eget sind.
Fakturering er det første system, vi forsøgte at blive venner med. Og den første vanskelighed, vi stødte på, var ved behandling af tjenester.
For eksempel, når en opgave oprettes eller slettes, går den ind i den interne faktureringskø. Således implementeres et system med asynkront arbejde med tjenester. For at behandle vores servicetyper var vi nødt til at "sætte" vores opgaver i denne kø. Og her løb vi ind i et problem: manglende dokumentation.
At dømme efter beskrivelsen af software-API'en er det stadig muligt at løse dette problem, men vi havde ikke tid til at lave reverse engineering, så vi tog logikken udenfor og organiserede en opgavekø oven på RabbitMQ. En operation på en tjeneste initieres af klienten fra hans personlige konto, bliver til en Selleri "opgave" på backend og udføres på fakturerings- og OpenStack-siden. Selleri gør det ret praktisk at administrere opgaver, organisere gentagelser og overvåge status. Du kan læse mere om “selleri”, f.eks. .
Også fakturering stoppede ikke et projekt, der løb tør for penge. Ved at kommunikere med udviklerne fandt vi ud af, at når vi beregner statistik (og vi skal implementere præcis denne form for logik), er der en kompleks sammenhæng mellem stopregler. Men disse modeller passer ikke godt til vores virkelighed. Vi implementerede det også gennem opgaver på Selleri, og tog servicestyringslogikken til backend-siden.
Begge de ovenstående problemer førte til, at koden blev lidt oppustet, og i fremtiden bliver vi nødt til at refaktorere for at flytte logikken for at arbejde med opgaver til en separat tjeneste. Vi skal også gemme nogle oplysninger om brugere og deres tjenester i vores tabeller for at understøtte denne logik.
Et andet problem er stilhed.
Billy svarer lydløst "Ok" på nogle API-anmodninger. Dette var for eksempel tilfældet, da vi foretog betalinger af lovede betalinger under testen (mere om det senere). Anmodningerne blev udført korrekt, og vi så ingen fejl.
Jeg var nødt til at studere logfilerne, mens jeg arbejdede med systemet gennem brugergrænsefladen. Det viste sig, at fakturering i sig selv udfører lignende anmodninger, ændrer omfanget til en bestemt bruger, for eksempel admin, og sender det i su-parameteren.
Generelt gik alt ganske godt på trods af hullerne i dokumentationen og mindre API-fejl. Logs kan læses selv under hård belastning, hvis du forstår, hvordan de er opbygget, og hvad du skal kigge efter. Strukturen af databasen er udsmykket, men ret logisk og på nogle måder endda attraktiv.
Så for at opsummere er de vigtigste problemer, vi stødte på på interaktionsstadiet, relateret til implementeringsfunktionerne i et specifikt system:
- udokumenterede "træk", der påvirkede os på den ene eller anden måde;
- lukket kildekode (fakturering er skrevet i C++), som et resultat - det er umuligt at løse problem 1 på anden måde end "trial and error".
Heldigvis har produktet en ret omfattende API, og vi har integreret følgende undersystemer i vores personlige konto:
- teknisk support modul - anmodninger fra din personlige konto "proxy" til fakturering gennemsigtigt for servicekunder;
- finansmodul - giver dig mulighed for at udstede fakturaer til nuværende kunder, foretage afskrivninger og generere betalingsdokumenter;
- servicekontrolmodul - til dette skulle vi implementere vores egen handler. Systemets udvidelsesmuligheder spillede os i hænderne, og vi "lærte" Billy en ny type service.
Det var lidt besværligt, men på en eller anden måde tror jeg, at Billy og jeg vil komme sammen.
Gå gennem wolframfelter – Tungsten Fabric
Wolframfelter oversået med hundredvis af ledninger, der fører tusindvis af informationsbidder igennem dem. Oplysninger samles i "pakker", analyseres og bygger komplekse ruter, som ved et trylleslag.
Dette er domænet for det andet system, som vi var nødt til at blive venner med - Tungsten Fabric (TF), tidligere OpenContrail. Dens opgave er at administrere netværksudstyr og levere en softwareabstraktion til os som brugere. TF - SDN, indkapsler den komplekse logik ved at arbejde med netværksudstyr. Der er en god artikel om selve teknologien, f.eks. .
Systemet er integreret med OpenStack (omtalt nedenfor) via Neutron plugin.
Interaktion mellem OpenStack-tjenester.
Fyrene fra operationsafdelingen introducerede os til dette system. Vi bruger systemets API til at administrere netværksstakken af vores tjenester. Det har ikke givet os nogen alvorlige problemer eller besvær endnu (jeg kan ikke tale på vegne af fyrene fra OE), men der har været nogle mærkværdigheder i samspillet.
Den første så sådan ud: kommandoer, der krævede at udsende en stor mængde data til instanskonsollen, når der oprettedes forbindelse via SSH, "lagde" simpelthen forbindelsen på, mens alt via VNC fungerede korrekt.
For dem, der ikke er bekendt med problemet, ser det ret sjovt ud: ls /root fungerer korrekt, mens f.eks. top "fryser" helt. Heldigvis er vi stødt på lignende problemer før. Det blev besluttet ved at tune MTU'en på ruten fra beregningsknuderne til routerne. Det er i øvrigt ikke et TF-problem.
Det næste problem var lige om hjørnet. I et "smukt" øjeblik forsvandt magien ved routing, bare sådan. TF er stoppet med at styre routing på udstyret.
Vi arbejdede med Openstack fra admin-niveau og flyttede derefter til det krævede brugerniveau. SDN ser ud til at "kapre" omfanget af den bruger, som handlingerne udføres af. Faktum er, at den samme admin-konto bruges til at forbinde TF og OpenStack. Ved skiftet til brugeren forsvandt "magien". Det blev besluttet at oprette en separat konto for at arbejde med systemet. Dette gav os mulighed for at arbejde uden at bryde integrationsfunktionaliteten.
Silicon Lifeforms - OpenStack
Et bizart formet silikonevæsen lever i nærheden af wolframmarker. Mest af alt ligner det et forvokset barn, der kan knuse os med én gynge, men der kommer ingen åbenlys aggression fra ham. Det forårsager ikke frygt, men dets størrelse inspirerer til frygt. Det samme gør kompleksiteten af det, der sker rundt omkring.
OpenStack er kernen i vores platform.
OpenStack har flere undersystemer, hvoraf vi i øjeblikket bruger Nova, Glance og Cinder mest aktivt. Hver af dem har sin egen API. Nova er ansvarlig for computerressourcer og oprettelse af instanser, Cinder er ansvarlig for at administrere volumener og deres snapshots, Glance er en billedtjeneste, der administrerer OS-skabeloner og metainformation på dem.
Hver tjeneste kører i en container, og meddelelsesmægleren er den "hvide kanin" - RabbitMQ.
Dette system gav os de mest uventede problemer.
Og det første problem lod ikke vente på sig, da vi forsøgte at tilslutte en ekstra volumen til serveren. Cinder API nægtede blankt at udføre denne opgave. Mere præcist, hvis du tror på OpenStack selv, er forbindelsen etableret, men der er ingen diskenhed inde i den virtuelle server.
Vi besluttede at tage en omvej og anmodede om samme handling fra Nova API. Resultatet er, at enheden forbinder korrekt og er tilgængelig på serveren. Det ser ud til, at problemet opstår, når bloklagring ikke reagerer på Cinder.
En anden vanskelighed ventede os, når vi arbejdede med diske. Systemvolumenet kunne ikke afbrydes fra serveren.
Igen "sværger" OpenStack selv, at den har ødelagt forbindelsen, og nu kan du korrekt arbejde med volumen separat. Men API'et ønskede kategorisk ikke at udføre operationer på disken.
Her besluttede vi ikke at kæmpe specielt, men at ændre vores syn på tjenestens logik. Hvis der er en instans, skal der også være en systemvolumen. Derfor kan brugeren endnu ikke fjerne eller deaktivere systemets "disk" uden at slette "serveren".
OpenStack er et ret komplekst sæt systemer med sin egen interaktionslogik og udsmykkede API. Vi er hjulpet af ret detaljeret dokumentation og selvfølgelig trial and error (hvor ville vi være uden det).
Test løb
Vi gennemførte en testlancering i december sidste år. Hovedopgaven var at teste vores projekt i kamptilstand fra den tekniske side og fra UX-siden. Publikum blev inviteret selektivt, og testen blev afsluttet. Vi har dog også efterladt muligheden for at anmode om adgang til test på vores hjemmeside.
Selve testen var selvfølgelig ikke uden sjove øjeblikke, for det er her, vores eventyr lige er begyndt.
For det første vurderede vi noget forkert interessen for projektet og måtte hurtigt tilføje compute noder lige under testen. Et almindeligt tilfælde for en klynge, men der var også nogle nuancer her. Dokumentationen for en specifik version af TF angiver den specifikke version af kernen, som arbejde med vRouter blev testet på. Vi besluttede at starte noder med nyere kerner. Som følge heraf modtog TF ikke ruter fra knudepunkterne. Jeg var nødsaget til at rulle kernerne tilbage.
En anden nysgerrighed er relateret til funktionaliteten af knappen "Skift adgangskode" på din personlige konto.
Vi besluttede at bruge JWT til at organisere adgangen til vores personlige konto for ikke at arbejde med sessioner. Da systemerne er mangfoldige og vidt spredte, administrerer vi vores eget token, hvor vi "pakker" sessioner fra fakturering og et token fra OpenStack. Når adgangskoden ændres, "går tokenet selvfølgelig dårligt", da brugerdataene ikke længere er gyldige, og de skal genudstedes.
Vi mistede dette punkt af syne, og der var simpelthen ikke ressourcer nok til hurtigt at afslutte dette stykke. Vi var nødt til at afbryde funktionaliteten lige før lanceringen af testen.
I øjeblikket logger vi brugeren ud, hvis adgangskoden er blevet ændret.
På trods af disse nuancer gik testen godt. På et par uger var omkring 300 mennesker forbi. Vi var i stand til at se på produktet gennem brugernes øjne, teste det i aktion og indsamle feedback af høj kvalitet.
Fortsættes
For mange af os er dette det første projekt i denne skala. Vi lærte en række værdifulde lektioner om, hvordan man arbejder som et team og træffer arkitektoniske og designmæssige beslutninger. Hvordan man integrerer komplekse systemer med få ressourcer og ruller dem i produktion.
Der er selvfølgelig noget at arbejde med både i forhold til kode og på grænsefladerne for systemintegration. Projektet er ret ungt, men vi er fulde af ambitioner om at udvikle det til en pålidelig og bekvem service.
Vi har allerede været i stand til at overtale systemerne. Bill håndterer pligtopfyldende optælling, fakturering og brugeranmodninger i sit skab. Wolframfelternes "magi" giver os stabil kommunikation. Og kun OpenStack bliver nogle gange lunefuld og råber noget som "'WSREP har endnu ikke forberedt node til applikationsbrug." Men det er en helt anden historie...
Vi lancerede for nylig tjenesten.
Du kan finde ud af alle detaljerne på vores .
CLO udviklingsteam
Nyttige links
OpenStack
Wolfram stof
Kilde: www.habr.com