När du arbetar inom IT börjar du märka att system har sin egen karaktär. De kan vara flexibla, tysta, excentriska och stränga. De kan attrahera eller stöta bort. På ett eller annat sätt måste du "förhandla" med dem, manövrera mellan "fallgropar" och bygga kedjor av deras interaktion.
Så vi hade äran att bygga en molnplattform, och för detta behövde vi "övertala" ett par delsystem att arbeta med oss. Som tur är har vi ett "API-språk", direkta händer och mycket entusiasm.
Den här artikeln kommer inte att vara tekniskt hård, men kommer att beskriva de problem vi stötte på när vi byggde molnet. Jag bestämde mig för att beskriva vår väg i form av en lätt teknisk fantasi om hur vi letade efter ett gemensamt språk med system och vad som kom ut ur det.
Välkommen till katten.
Början på en resa
För en tid sedan fick vårt team i uppdrag att lansera en molnplattform för våra kunder. Vi hade ledningsstöd, resurser, hårdvarustack och frihet att välja teknik för att implementera mjukvarudelen av tjänsten.
Det fanns också ett antal krav:
- tjänsten behöver ett bekvämt personligt konto;
- plattformen måste integreras i det befintliga faktureringssystemet;
- mjukvara och hårdvara: OpenStack + Tungsten Fabric (Open Contrail), som våra ingenjörer har lärt sig att "laga" ganska bra.
Vi kommer att berätta en annan gång om hur teamet sattes ihop, det personliga kontogränssnittet utvecklades och designbeslut togs, om Habra-gemenskapen är intresserad.
Verktygen vi bestämde oss för att använda:
- Python + Flask + Swagger + SQLAlchemy - en helt standard Python-uppsättning;
- Vue.js för frontend;
- Vi bestämde oss för att göra interaktionen mellan komponenter och tjänster med Selleri över AMQP.
Jag kommer att förutse frågor om att välja Python, jag ska förklara. Språket har hittat sin nisch i vårt företag och en liten men ändå kultur har utvecklats kring det. Därför beslutades det att börja bygga tjänsten på den. Dessutom är hastigheten i utvecklingen av sådana problem ofta avgörande.
Så, låt oss börja vår bekantskap.
Silent Bill - fakturering
Vi har känt den här killen länge. Han satt alltid bredvid mig och räknade tyst något. Ibland vidarebefordrade han användarförfrågningar till oss, utfärdade kundfakturor och hanterade tjänster. En vanlig hårt arbetande kille. Det var sant att det fanns svårigheter. Han är tyst, ibland eftertänksam och ofta i sitt eget sinne.
Fakturering är det första systemet vi försökte bli vän med. Och den första svårigheten vi stötte på var när vi bearbetade tjänster.
Till exempel, när en uppgift skapas eller tas bort hamnar den i den interna faktureringskön. Således implementeras ett system för asynkront arbete med tjänster. För att bearbeta våra tjänstetyper behövde vi "sätta" våra uppgifter i den här kön. Och här stötte vi på ett problem: brist på dokumentation.
Att döma av beskrivningen av mjukvaru-API:t är det fortfarande möjligt att lösa detta problem, men vi hade inte tid att göra reverse engineering, så vi tog logiken utanför och organiserade en uppgiftskö ovanpå RabbitMQ. En operation på en tjänst initieras av klienten från hans personliga konto, förvandlas till en Celery "uppgift" på backend och utförs på fakturerings- och OpenStack-sidan. Selleri gör det ganska bekvämt att hantera uppgifter, organisera upprepningar och övervaka status. Du kan läsa mer om "selleri", till exempel, .
Fakturering stoppade inte heller ett projekt som tog slut på pengar. När vi kommunicerade med utvecklarna fick vi reda på att när vi beräknar statistik (och vi måste implementera exakt den här typen av logik) finns det ett komplext samband mellan stoppregler. Men dessa modeller passar inte bra med vår verklighet. Vi implementerade det också genom uppgifter på Selleri, och tog tjänstehanteringslogiken till backend-sidan.
Båda ovanstående problem ledde till att koden blev lite uppsvälld och i framtiden kommer vi att behöva refaktorera för att flytta logiken för att arbeta med uppgifter till en separat tjänst. Vi behöver också lagra viss information om användare och deras tjänster i våra tabeller för att stödja denna logik.
Ett annat problem är tystnaden.
Billy svarar tyst "Ok" på några API-förfrågningar. Det var till exempel fallet när vi gjorde betalningar av utlovade betalningar under testet (mer om det senare). Förfrågningarna utfördes korrekt och vi såg inga fel.
Jag var tvungen att studera loggarna medan jag arbetade med systemet via användargränssnittet. Det visade sig att fakturering själv utför liknande förfrågningar, ändrar omfattningen till en specifik användare, till exempel admin, skickar den i su-parametern.
I allmänhet, trots luckorna i dokumentationen och mindre API-brister, gick allt ganska bra. Loggar kan läsas även under hög belastning om du förstår hur de är uppbyggda och vad du ska leta efter. Strukturen i databasen är utsmyckad, men ganska logisk och på vissa sätt till och med attraktiv.
Så, för att sammanfatta, är de viktigaste problemen som vi stötte på i interaktionsstadiet relaterade till implementeringsfunktionerna i ett specifikt system:
- odokumenterade "funktioner" som påverkade oss på ett eller annat sätt;
- sluten källa (fakturering skrivs i C++), som ett resultat - det är omöjligt att lösa problem 1 på något annat sätt än "trial and error".
Lyckligtvis har produkten ett ganska omfattande API och vi har integrerat följande delsystem i vårt personliga konto:
- teknisk supportmodul - förfrågningar från ditt personliga konto "proxys" till fakturering transparent för tjänstekunder;
- finansiell modul - låter dig utfärda fakturor till nuvarande kunder, göra avskrivningar och generera betalningsdokument;
- servicekontrollmodul - för detta var vi tvungna att implementera vår egen hanterare. Systemets utbyggbarhet spelade oss i händerna och vi "lärde" Billy en ny typ av tjänst.
Det var lite jobbigt, men på ett eller annat sätt tror jag att Billy och jag kommer att komma överens.
Att gå genom volframfält – Tungsten Fabric
Volframfält prickade med hundratals ledningar, som passerar tusentals bitar av information genom dem. Information samlas in i "paket", analyseras och bygger komplexa rutter, som genom ett trollslag.
Detta är domänen för det andra systemet som vi var tvungna att bli vänner med - Tungsten Fabric (TF), tidigare OpenContrail. Dess uppgift är att hantera nätverksutrustning och tillhandahålla en mjukvaruabstraktion till oss som användare. TF - SDN, kapslar in den komplexa logiken i att arbeta med nätverksutrustning. Det finns en bra artikel om själva tekniken, t.ex. .
Systemet är integrerat med OpenStack (diskuterat nedan) via Neutron-plugin.
Interaktion mellan OpenStack-tjänster.
Killarna från operationsavdelningen introducerade oss till det här systemet. Vi använder systemets API för att hantera nätverksstacken för våra tjänster. Det har inte orsakat oss några allvarliga problem eller olägenheter ännu (jag kan inte tala för killarna från OE), men det har varit några konstigheter i interaktionen.
Det första såg ut så här: kommandon som krävde att mata ut en stor mängd data till instanskonsolen när man ansluter via SSH "hängde på" helt enkelt anslutningen, medan via VNC allt fungerade korrekt.
För de som inte är bekanta med problemet ser det ganska roligt ut: ls /root fungerar korrekt, medan till exempel toppen "fryser" helt. Som tur är har vi stött på liknande problem tidigare. Det bestämdes genom att ställa in MTU på rutten från beräkningsnoderna till routrarna. Detta är förresten inget TF-problem.
Nästa problem var precis runt hörnet. I ett "vackert" ögonblick försvann magin med routing, precis som det. TF har slutat hantera routing på utrustningen.
Vi arbetade med Openstack från administratörsnivå och flyttade efter det till önskad användarnivå. SDN verkar "kapa" omfattningen av användaren som åtgärderna utförs av. Faktum är att samma adminkonto används för att koppla TF och OpenStack. I steget att byta till användaren försvann "magin". Det beslutades att skapa ett separat konto för att arbeta med systemet. Detta gjorde att vi kunde arbeta utan att bryta integrationsfunktionen.
Silicon Lifeforms - OpenStack
En bisarrt formad silikonvarelse bor nära volframfält. Mest av allt ser det ut som ett övervuxet barn som kan krossa oss med en sväng, men det kommer ingen uppenbar aggression från honom. Det orsakar inte rädsla, men dess storlek inspirerar till rädsla. Liksom komplexiteten i det som händer runt omkring.
OpenStack är kärnan i vår plattform.
OpenStack har flera delsystem, av vilka vi för närvarande använder Nova, Glance och Cinder mest aktivt. Var och en av dem har sitt eget API. Nova ansvarar för beräkningsresurser och skapandet av instanser, Cinder ansvarar för att hantera volymer och deras ögonblicksbilder, Glance är en bildtjänst som hanterar OS-mallar och metainformation på dem.
Varje tjänst körs i en container, och meddelandeförmedlaren är den "vita kaninen" - RabbitMQ.
Detta system gav oss de mest oväntade problem.
Och det första problemet lät inte vänta på sig när vi försökte ansluta en extra volym till servern. Cinder API vägrade bestämt att utföra denna uppgift. Närmare bestämt, om du tror på OpenStack själv, upprättas anslutningen, men det finns ingen diskenhet inuti den virtuella servern.
Vi bestämde oss för att ta en omväg och begärde samma åtgärd från Nova API. Resultatet är att enheten ansluter korrekt och är tillgänglig inom servern. Det verkar som om problemet uppstår när block-lagring inte svarar på Cinder.
En annan svårighet väntade oss när vi arbetade med diskar. Systemvolymen kunde inte kopplas bort från servern.
Återigen, OpenStack själv "svär" att den har förstört anslutningen och nu kan du korrekt arbeta med volymen separat. Men API:et ville kategoriskt inte utföra operationer på disken.
Här bestämde vi oss för att inte slåss särskilt, utan att ändra vår syn på logiken i tjänsten. Om det finns en instans måste det också finnas en systemvolym. Därför kan användaren ännu inte ta bort eller inaktivera systemets "disk" utan att ta bort "servern".
OpenStack är en ganska komplex uppsättning system med sin egen interaktionslogik och utsmyckade API. Vi har hjälp av ganska detaljerad dokumentation och naturligtvis trial and error (var skulle vi vara utan den).
Provkörning
Vi genomförde en testlansering i december förra året. Huvuduppgiften var att testa vårt projekt i stridsläge från den tekniska sidan och från UX-sidan. Publiken bjöds in selektivt och testningen avslutades. Men vi har även lämnat alternativet att begära tillgång till testning på vår webbplats.
Själva testet var naturligtvis inte utan sina roliga ögonblick, för det är här våra äventyr bara börjar.
För det första bedömde vi något felaktigt intresset för projektet och var tvungna att snabbt lägga till beräkningsnoder direkt under testet. Ett vanligt fall för ett kluster, men det fanns en del nyanser även här. Dokumentationen för en specifik version av TF anger den specifika versionen av kärnan som arbetet med vRouter testades på. Vi bestämde oss för att lansera noder med nyare kärnor. Som ett resultat tog TF inte emot rutter från noderna. Jag var tvungen att snabbt rulla tillbaka kärnorna.
En annan kuriosa är relaterad till funktionen hos knappen "Ändra lösenord" på ditt personliga konto.
Vi bestämde oss för att använda JWT för att organisera åtkomst till vårt personliga konto för att inte arbeta med sessioner. Eftersom systemen är mångfaldiga och spridda hanterar vi vår egen token, där vi "lindar" sessioner från fakturering och en token från OpenStack. När lösenordet ändras, "blir naturligtvis token dåligt", eftersom användardata inte längre är giltiga och det måste utfärdas på nytt.
Vi tappade denna punkt ur sikte, och det fanns helt enkelt inte tillräckligt med resurser för att snabbt avsluta det här stycket. Vi var tvungna att stänga av funktionaliteten precis innan testet startade.
För närvarande loggar vi ut användaren om lösenordet har ändrats.
Trots dessa nyanser gick testet bra. På ett par veckor var cirka 300 personer förbi. Vi kunde titta på produkten genom användarnas ögon, testa den i praktiken och samla in högkvalitativ feedback.
Fortsättning
För många av oss är detta det första projektet i denna skala. Vi lärde oss ett antal värdefulla lektioner om hur man arbetar som ett team och fattar arkitektoniska och designbeslut. Hur man integrerar komplexa system med små resurser och rullar in dem i produktion.
Naturligtvis finns det något att jobba på både kodmässigt och i systemintegrationens gränssnitt. Projektet är ganska ungt, men vi är fulla av ambitioner att utveckla det till en pålitlig och bekväm tjänst.
Vi har redan kunnat övertala systemen. Bill hanterar plikttroget räkning, fakturering och användarförfrågningar i sin garderob. Volframfältens "magi" ger oss stabil kommunikation. Och bara OpenStack blir ibland nyckfull och ropar något i stil med "'WSREP har ännu inte förberett noden för applikationsanvändning." Men det är en helt annan historia...
Vi lanserade nyligen tjänsten.
Du kan ta reda på alla detaljer på vår .
CLO utvecklingsteam
Användbara länkar
Openstack
Tungsten tyg
Källa: will.com