Når du jobber med IT, begynner du å legge merke til at systemene har sin egen karakter. De kan være fleksible, lydløse, eksentriske og strenge. De kan tiltrekke seg eller avvise. På en eller annen måte må du "forhandle" med dem, manøvrere mellom "fallgruver" og bygge kjeder av deres samhandling.
Så vi hadde æren av å bygge en skyplattform, og for dette trengte vi å "overtale" et par undersystemer til å samarbeide med oss. Heldigvis har vi et "API-språk", direkte hender og mye entusiasme.
Denne artikkelen vil ikke være teknisk hardcore, men vil beskrive problemene vi møtte mens vi bygde skyen. Jeg bestemte meg for å beskrive veien vår i form av en lett teknisk fantasi om hvordan vi så etter et felles språk med systemer og hva som kom ut av det.
Velkommen til katt.
Begynnelsen av en reise
For en tid siden fikk teamet vårt i oppgave å lansere en skyplattform for våre kunder. Vi hadde ledelsesstøtte, ressurser, maskinvarestabel og frihet til å velge teknologier for å implementere programvaredelen av tjenesten.
Det var også en rekke krav:
- tjenesten trenger en praktisk personlig konto;
- plattformen må integreres i det eksisterende faktureringssystemet;
- programvare og maskinvare: OpenStack + Tungsten Fabric (Open Contrail), som våre ingeniører har lært å "koke" ganske bra.
Vi vil fortelle deg en annen gang om hvordan teamet ble satt sammen, det personlige kontogrensesnittet ble utviklet og designbeslutninger ble tatt, hvis Habra-fellesskapet er interessert.
Verktøyene vi bestemte oss for å bruke:
- Python + Flask + Swagger + SQLAlchemy - et helt standard Python-sett;
- Vue.js for frontend;
- Vi bestemte oss for å gjøre interaksjonen mellom komponenter og tjenester ved å bruke Selleri over AMQP.
I påvente av spørsmål om valg av Python, vil jeg forklare. Språket har funnet sin nisje i selskapet vårt og en liten, men fortsatt kultur, har utviklet seg rundt det. Derfor ble det besluttet å begynne å bygge tjenesten på den. Dessuten er utviklingshastigheten i slike problemer ofte avgjørende.
Så la oss begynne å bli kjent.
Silent Bill - fakturering
Vi har kjent denne fyren lenge. Han satt alltid ved siden av meg og telte noe stille. Noen ganger videresendte han brukerforespørsler til oss, utstedte kundefakturaer og administrerte tjenester. En vanlig hardtarbeidende fyr. Riktignok var det vanskeligheter. Han er taus, noen ganger gjennomtenkt og ofte i sitt eget sinn.
Fakturering er det første systemet vi prøvde å bli venner med. Og den første vanskeligheten vi møtte var ved behandling av tjenester.
For eksempel, når en oppgave opprettes eller slettes, går den inn i den interne faktureringskøen. Dermed implementeres et system for asynkront arbeid med tjenester. For å behandle tjenestetypene våre, trengte vi å "sette" oppgavene våre i denne køen. Og her møtte vi et problem: mangel på dokumentasjon.
Etter beskrivelsen av programvare-APIen å dømme er det fortsatt mulig å løse dette problemet, men vi hadde ikke tid til å gjøre omvendt utvikling, så vi tok logikken utenfor og organiserte en oppgavekø på toppen av RabbitMQ. En operasjon på en tjeneste initieres av klienten fra hans personlige konto, blir til en Selleri-"oppgave" på backend og utføres på fakturerings- og OpenStack-siden. Selleri gjør det ganske praktisk å administrere oppgaver, organisere repetisjoner og overvåke status. Du kan lese mer om "selleri", for eksempel, .
Fakturering stoppet heller ikke et prosjekt som gikk tom for penger. Ved å kommunisere med utviklerne fant vi ut at når vi beregner statistikk (og vi må implementere akkurat denne typen logikk), er det en kompleks sammenheng mellom stoppregler. Men disse modellene passer dårlig med vår virkelighet. Vi implementerte det også gjennom oppgaver på Selleri, og tok tjenesteadministrasjonslogikken til backend-siden.
Begge de ovennevnte problemene førte til at koden ble litt oppblåst og i fremtiden må vi refaktorere for å flytte logikken for å jobbe med oppgaver inn i en egen tjeneste. Vi må også lagre noe informasjon om brukere og deres tjenester i tabellene våre for å støtte denne logikken.
Et annet problem er stillhet.
Billy svarer stille "Ok" på noen API-forespørsler. Dette var for eksempel tilfellet da vi betalte ut lovede betalinger under testen (mer om det senere). Forespørslene ble utført korrekt og vi så ingen feil.
Jeg måtte studere loggene mens jeg jobbet med systemet gjennom brukergrensesnittet. Det viste seg at selve faktureringen utfører lignende forespørsler, og endrer omfanget til en spesifikk bruker, for eksempel admin, og sender det i su-parameteren.
Generelt, til tross for hull i dokumentasjonen og mindre API-feil, gikk alt ganske bra. Logger kan leses selv under stor belastning hvis du forstår hvordan de er bygget opp og hva du skal se etter. Strukturen til databasen er utsmykket, men ganske logisk og på noen måter til og med attraktiv.
Så, for å oppsummere, er hovedproblemene vi møtte på interaksjonsstadiet relatert til implementeringsfunksjonene til et spesifikt system:
- udokumenterte «trekk» som påvirket oss på en eller annen måte;
- lukket kildekode (fakturering er skrevet i C++), som et resultat - det er umulig å løse problem 1 på noen annen måte enn "prøving og feiling".
Heldigvis har produktet et ganske omfattende API, og vi har integrert følgende undersystemer i vår personlige konto:
- teknisk støttemodul - forespørsler fra din personlige konto blir "proksert" til fakturering på en transparent måte for tjenestekunder;
- finansmodul - lar deg utstede fakturaer til nåværende kunder, foreta avskrivninger og generere betalingsdokumenter;
- servicekontrollmodul - for dette måtte vi implementere vår egen behandler. Utvidbarheten til systemet spilte i våre hender, og vi "lærte" Billy en ny type tjeneste.
Det var litt mas, men på en eller annen måte tror jeg at Billy og jeg kommer til å komme overens.
Gå gjennom wolframfelt – Tungsten Fabric
Wolfram-felter oversådd med hundrevis av ledninger, som sender tusenvis av informasjonsbiter gjennom dem. Informasjon samles inn i "pakker", analyseres, og bygger komplekse ruter, som ved magi.
Dette er domenet til det andre systemet vi måtte bli venner med - Tungsten Fabric (TF), tidligere OpenContrail. Dens oppgave er å administrere nettverksutstyr, og gi en programvareabstraksjon til oss som brukere. TF - SDN, innkapsler den komplekse logikken ved å jobbe med nettverksutstyr. Det er en god artikkel om selve teknologien, f.eks. .
Systemet er integrert med OpenStack (diskutert nedenfor) via Neutron-plugin.
Interaksjon av OpenStack-tjenester.
Gutta fra operasjonsavdelingen introduserte oss for dette systemet. Vi bruker systemets API for å administrere nettverksstabelen til tjenestene våre. Det har ikke forårsaket oss noen alvorlige problemer eller ulemper ennå (jeg kan ikke snakke for gutta fra OE), men det har vært noen merkeligheter i samhandlingen.
Den første så slik ut: kommandoer som krevde å sende ut en stor mengde data til instanskonsollen når du koblet til via SSH, "hengte på" tilkoblingen, mens alt fungerte riktig via VNC.
For de som ikke er kjent med problemet, ser det ganske morsomt ut: ls /root fungerer riktig, mens for eksempel toppen "fryser" helt. Heldigvis har vi støtt på lignende problemer før. Det ble bestemt ved å stille inn MTU på ruten fra beregningsnodene til ruterne. Dette er forresten ikke et TF-problem.
Det neste problemet var rett rundt hjørnet. I et "vakkert" øyeblikk forsvant magien med ruting, akkurat som det. TF har sluttet å administrere ruting på utstyret.
Vi jobbet med Openstack fra admin-nivå og flyttet deretter til det nødvendige brukernivået. SDN ser ut til å "kapre" omfanget til brukeren som handlingene utføres av. Faktum er at den samme admin-kontoen brukes til å koble TF og OpenStack. Ved trinnet med å bytte til brukeren forsvant "magien". Det ble besluttet å opprette en egen konto for å jobbe med systemet. Dette tillot oss å jobbe uten å ødelegge integrasjonsfunksjonaliteten.
Silicon Lifeforms - OpenStack
En bisarr formet silikonskapning lever i nærheten av wolframfelt. Mest av alt ser det ut som et forvokst barn som kan knuse oss med en sving, men det kommer ingen åpenbar aggresjon fra ham. Det forårsaker ikke frykt, men størrelsen inspirerer til frykt. Det samme gjør kompleksiteten i det som skjer rundt omkring.
OpenStack er kjernen i plattformen vår.
OpenStack har flere undersystemer, hvorav vi for tiden bruker Nova, Glance og Cinder mest aktivt. Hver av dem har sin egen API. Nova er ansvarlig for dataressurser og opprettelse av forekomster, Cinder er ansvarlig for å administrere volumer og deres øyeblikksbilder, Glance er en bildetjeneste som administrerer OS-maler og metainformasjon på dem.
Hver tjeneste kjører i en container, og meldingsmegleren er den "hvite kaninen" - RabbitMQ.
Dette systemet ga oss de mest uventede problemer.
Og det første problemet lot ikke vente på seg da vi prøvde å koble et ekstra volum til serveren. Cinder API nektet blankt å utføre denne oppgaven. Mer presist, hvis du tror på OpenStack selv, er forbindelsen etablert, men det er ingen diskenhet inne i den virtuelle serveren.
Vi bestemte oss for å ta en omvei og ba om samme handling fra Nova API. Resultatet er at enheten kobles til riktig og er tilgjengelig på serveren. Det ser ut til at problemet oppstår når blokklagring ikke reagerer på Cinder.
En annen vanskelighet ventet oss når vi jobbet med disker. Systemvolumet kunne ikke kobles fra serveren.
Igjen, OpenStack selv "sverger" at den har ødelagt forbindelsen, og nå kan du riktig jobbe med volum separat. Men API-en ønsket kategorisk ikke å utføre operasjoner på disken.
Her bestemte vi oss for ikke å kjempe spesielt, men å endre vårt syn på logikken i tjenesten. Hvis det er en forekomst, må det også være et systemvolum. Derfor kan brukeren ennå ikke fjerne eller deaktivere systemets "disk" uten å slette "serveren".
OpenStack er et ganske komplekst sett med systemer med sin egen interaksjonslogikk og utsmykkede API. Vi får hjelp av ganske detaljert dokumentasjon og selvfølgelig prøving og feiling (hvor ville vi vært uten den).
Prøvekjøring
Vi gjennomførte en testlansering i desember i fjor. Hovedoppgaven var å teste prosjektet vårt i kampmodus fra den tekniske siden og fra UX-siden. Publikum ble invitert selektivt og testingen ble avsluttet. Vi har imidlertid også overlatt muligheten til å be om tilgang til testing på nettsiden vår.
Selve testen var selvfølgelig ikke uten morsomme øyeblikk, for det er her eventyrene våre bare begynner.
For det første vurderte vi interessen for prosjektet noe feil og måtte raskt legge til beregningsnoder rett under testen. En vanlig sak for en klynge, men det var noen nyanser også her. Dokumentasjonen for en spesifikk versjon av TF angir den spesifikke versjonen av kjernen som arbeidet med vRouter ble testet på. Vi bestemte oss for å lansere noder med nyere kjerner. Som et resultat mottok ikke TF ruter fra nodene. Jeg måtte raskt rulle tilbake kjernene.
En annen nysgjerrighet er relatert til funksjonaliteten til "endre passord"-knappen på din personlige konto.
Vi bestemte oss for å bruke JWT for å organisere tilgang til vår personlige konto for ikke å jobbe med økter. Siden systemene er mangfoldige og vidt spredt, administrerer vi vårt eget token, der vi "pakker inn" økter fra fakturering og et token fra OpenStack. Når passordet endres, "blir selvfølgelig tokenet dårlig", siden brukerdataene ikke lenger er gyldige og må utstedes på nytt.
Vi mistet dette punktet av syne, og det var rett og slett ikke nok ressurser til raskt å fullføre dette stykket. Vi måtte kutte ut funksjonaliteten rett før vi lanserte testen.
For øyeblikket logger vi ut brukeren hvis passordet er endret.
Til tross for disse nyansene gikk testingen bra. I løpet av et par uker var rundt 300 personer innom. Vi var i stand til å se på produktet gjennom brukernes øyne, teste det i aksjon og samle høykvalitets tilbakemeldinger.
Skal videreføres
For mange av oss er dette det første prosjektet i denne skalaen. Vi lærte en rekke verdifulle leksjoner om hvordan man kan jobbe som et team og ta arkitektoniske og designbeslutninger. Hvordan integrere komplekse systemer med lite ressurser og rulle dem inn i produksjon.
Selvfølgelig er det noe å jobbe med både når det gjelder kode og i grensesnittene til systemintegrasjon. Prosjektet er ganske ungt, men vi er fulle av ambisjoner om å vokse det til en pålitelig og praktisk tjeneste.
Vi har allerede klart å overtale systemene. Bill håndterer pliktoppfyllende telling, fakturering og brukerforespørsler i skapet sitt. "Magien" av wolframfelt gir oss stabil kommunikasjon. Og bare OpenStack blir noen ganger lunefull og roper noe sånt som "'WSREP har ennå ikke forberedt node for applikasjonsbruk." Men det er en helt annen historie...
Vi lanserte nylig tjenesten.
Du kan finne ut alle detaljene på vår .
CLO utviklingsteam
Nyttige lenker
Openstack
Tungsten stoff
Kilde: www.habr.com