Quandu travagliate in l'IT, cuminciate à nutà chì i sistemi anu u so propiu caratteru. Puderanu esse flexible, silenziu, eccentricu è severu. Puderanu attruvarà o ripiglià. In un modu o un altru, avete da "negozià" cun elli, maneuver trà "pitfalls" è custruisce catene di a so interazzione.
Allora avemu avutu l'onore di custruisce una piattaforma di nuvola, è per questu avemu bisognu di "persuadisce" un paru di sottosistemi per travaglià cun noi. Fortunatamente, avemu una "lingua API", mani dirette è assai entusiasmu.
Questu articulu ùn serà micca tecnicumente hardcore, ma descriverà i prublemi chì avemu scontru mentre custruiscenu u nuvulu. Aghju decisu di discrive a nostra strada in a forma di una fantasia tecnica ligera nantu à cumu avemu cercatu una lingua cumuna cù i sistemi è ciò chì hè surtitu.
Benvenuti à u ghjattu.
U principiu di a strada
Qualchì tempu fà, a nostra squadra hè stata incaricata di lancià una piattaforma cloud per i nostri clienti. Avemu avutu supportu di gestione, risorse, pila di hardware è libertà in a scelta di tecnulugia per implementà a parte di u software di u serviziu.
Ci era ancu una quantità di esigenze:
- u serviziu hà bisognu di un contu persunale cunvene;
- a piattaforma deve esse integrata in u sistema di fattura esistenti;
- software è hardware: OpenStack + Tungsten Fabric (Open Contrail), chì i nostri ingegneri anu amparatu à "coccu" abbastanza bè.
Vi diciaremu un altru tempu nantu à cumu a squadra hè stata assemblata, l'interfaccia di u contu persunale hè stata sviluppata è e decisioni di cuncepimentu sò state prese, se a cumunità Habra hè interessata.
I strumenti chì avemu decisu di utilizà:
- Python + Flask + Swagger + SQLAlchemy - un set di Python cumpletamente standard;
- Vue.js per u frontend;
- Avemu decisu di fà l'interazzione trà cumpunenti è servizii cù Celery sopra AMQP.
Anticipando e dumande nantu à a scelta di Python, spiegheraghju. A lingua hà trovu u so nichulu in a nostra cumpagnia è una cultura chjuca, ma sempre, hà sviluppatu intornu à ella. Per quessa, hè statu decisu di cumincià à custruisce u serviziu nantu à questu. Inoltre, a velocità di u sviluppu in tali prublemi hè spessu decisiva.
Allora, cuminciamu a nostra cunniscenza.
Silent Bill - fattura
Cunnisciamu stu tippu da tantu tempu. Si pusava sempre accantu à mè è cuntava in silenziu qualcosa. A volte ci hà trasmessu e dumande di l'utilizatori, emessu fatture di i clienti, è servizii amministrati. Un omu ordinariu chì travaglia duru. True, ci sò stati difficultà. Hè silenziu, qualchì volta pensativu è spessu in a so mente.
A fatturazione hè u primu sistema chì avemu pruvatu à fà amici. È a prima difficultà chì avemu scontru hè stata quandu i servizii di trasfurmazioni.
Per esempiu, quandu hè creatu o sguassatu, un compitu entra in a fila di fattura interna. Cusì, un sistema di travagliu asincronu cù servizii hè implementatu. Per processà i nostri tipi di serviziu, avemu bisognu di "mette" i nostri compiti in questa fila. È quì avemu avutu un prublema: mancanza di ducumentazione.
A ghjudicà da a descrizzione di l'API di u software, hè sempre pussibule di risolve stu prublema, ma ùn avemu micca u tempu di fà l'ingegneria inversa, cusì avemu pigliatu a logica fora è urganizatu una fila di compiti nantu à RabbitMQ. Una operazione nantu à un serviziu hè iniziata da u cliente da u so contu persunale, si trasforma in un "task" di Celery in u backend è hè realizatu nantu à a fattura è OpenStack. L'api hè abbastanza cunvene per gestisce i travaglii, urganizà ripetizioni è monitorizà u statutu. Pudete leghje più nantu à "api", per esempiu, .
Inoltre, a fatturazione ùn hà micca impeditu un prughjettu chì hà scappatu di soldi. A cumunicazione cù i sviluppatori, avemu scupertu chì quandu u calculu di statistiche (è avemu bisognu di implementà esattamente stu tipu di logica), ci hè una interrelazione cumplessa di reguli di stopping. Ma sti mudelli ùn sò micca bè cù e nostre realità. L'avemu ancu implementatu per mezu di i travaglii nantu à Celery, purtendu a logica di gestione di serviziu à u backend.
I dui prublemi di sopra anu purtatu à u codice diventendu un pocu gonfiatu è in u futuru averemu da refactor per trasfurmà a logica per travaglià cù i travaglii in un serviziu separatu. Avemu ancu bisognu di guardà qualchì infurmazione nantu à l'utilizatori è i so servizii in i nostri tavulini per sustene sta logica.
Un altru prublema hè u silenziu.
Billy risponde in silenziu "Ok" à alcune richieste API. Questu era u casu, per esempiu, quandu avemu fattu pagamentu di pagamentu prumessi durante a prova (più nantu à questu dopu). E dumande sò state eseguite currettamente è ùn avemu micca vistu alcun errore.
Aviu avutu à studià i logs mentre travagliava cù u sistema attraversu l'UI. Ci hè stata chì a fattura stessu eseguisce richieste simili, cambiendu u scopu à un utilizatore specificu, per esempiu, admin, passendu in u paràmetru su.
In generale, malgradu i lacune in a documentazione è i difetti minuri di l'API, tuttu hè andatu abbastanza bè. I logs ponu esse leghjiti ancu sottu una carica pisanti si capisce cumu sò strutturati è ciò chì cercanu. A struttura di a basa di dati hè ornata, ma abbastanza logica è in certi modi ancu attrattiva.
Dunque, per riassume, i prublemi principali chì avemu scontru in u stadiu di l'interazzione sò ligati à e caratteristiche di implementazione di un sistema specificu:
- "caratteristiche" senza documentu chì ci anu affettatu in un modu o un altru;
- surghjente chjusu (a fattura hè scritta in C ++), com'è u risultatu - hè impussibile di risolve u prublema 1 in ogni modu altru ch'è "prova è errore".
Fortunatamente, u pruduttu hà una API abbastanza larga è avemu integratu i seguenti sottosistemi in u nostru contu persunale:
- Modulu di supportu tecnicu - e dumande da u vostru contu persunale sò "proxy" per a fatturazione in modu trasparente per i clienti di serviziu;
- modulu finanziariu - permette di emette fatture à i clienti attuali, fà scrive è generà documenti di pagamentu;
- modulu di cuntrollu di serviziu - per questu avemu avutu à implementà u nostru propiu gestore. L'espansione di u sistema hà ghjucatu in e nostre mani è avemu "insignatu" à Billy un novu tipu di serviziu.
Era un pocu fastidiu, ma d'una manera o di l'altru, pensu chì Billy è eiu andemu.
Camminendu per i campi di tungstenu - Tessutu di tungstenu
Campi di tungstenu puntellatu da centinaie di fili, chì passanu millaie di pezzi d'infurmazioni attraversu. L'infurmazioni sò cullate in "pacchetti", analizati, custruendu rotte cumplessi, cum'è per magia.
Questu hè u duminiu di u sicondu sistema cù quale avemu avutu per fà amici - Tungsten Fabric (TF), prima OpenContrail. U so compitu hè di gestisce l'equipaggiu di rete, chì furnisce una astrazione di software per noi cum'è utilizatori. TF - SDN, incapsula a logica cumplessa di travaglià cù l'equipaggiu di rete. Ci hè un bonu articulu nantu à a tecnulugia stessu, per esempiu, .
U sistema hè integratu cù OpenStack (discussu sottu) via u plugin Neutron.
Interazione di servizii OpenStack.
I picciotti di u dipartimentu di l'operazioni ci anu introduttu à stu sistema. Utilizemu l'API di u sistema per gestisce a pila di rete di i nostri servizii. Ùn ci hà micca causatu ancu prublemi serii o inconvenienze (ùn possu micca parlà per i picciotti di l'OE), ma ci sò stati certi strani in l'interazzione.
U primu s'assumigliava cusì: cumandamenti chì necessitavanu di trasmette una grande quantità di dati à a cunsola d'istanza quandu si cunnessu via SSH semplicemente "impiccatu" a cunnessione, mentre chì via VNC tuttu funzionava bè.
Per quelli chì ùn sò micca familiarizati cù u prublema, pare assai divertente: ls /root funziona bè, mentre chì, per esempiu, top "freezes" cumpletamente. Fortunatamente, avemu scontru prublemi simili prima. Hè statu decisu per sintonizà u MTU nantu à a strada da i nodi di compute à i routers. Per via, questu ùn hè micca un prublema TF.
U prublema dopu era ghjustu intornu à u cantonu. In un mumentu "bellu", a magia di u routing hè sparita, cusì cusì. TF hà cessatu di gestisce u routing nantu à l'equipaggiu.
Avemu travagliatu cù Openstack da u nivellu di amministratore è dopu si trasfirìu à u livellu d'utilizatore necessariu. SDN pare chì "jack" u scopu di l'utilizatore da quale l'azzioni sò realizati. U fattu hè chì u stessu contu amministratore hè utilizatu per cunnette TF è OpenStack. À u passu di cambià à l'utilizatore, a "magia" hè sparita. Hè statu decisu di creà un contu separatu per travaglià cù u sistema. Questu ci hà permessu di travaglià senza rompe a funziunalità di integrazione.
Silicon Lifeforms - OpenStack
Una criatura di silicone di forma strana vive vicinu à i campi di tungstenu. A maiò parte di tuttu, s'assumiglia à un zitellu ingrossu chì ci pò sfracicà cun un swing, ma ùn ci hè micca una aggressione evidenti chì vene da ellu. Ùn causa micca paura, ma a so dimensione inspira timore. Cum'è a cumplessità di ciò chì succede intornu.
OpenStack hè u core di a nostra piattaforma.
OpenStack hà parechji sottosistemi, di i quali avemu aduprà Nova, Glance è Cinder più attivamente. Ognunu di elli hà u so propiu API. Nova hè rispunsevule per e risorse di compute è a creazione di istanze, Cinder hè rispunsevule per a gestione di volumi è i so snapshots, Glance hè un serviziu d'imaghjini chì gestisce mudelli di OS è metainformazioni nantu à elli.
Ogni serviziu funziona in un containeru, è u broker di messagi hè u "cunigliu biancu" - RabbitMQ.
Stu sistema ci hà datu u prublema più inespettatu.
È u primu prublema ùn era micca longu quandu avemu pruvatu à cunnette un voluminu supplementu à u servitore. L'API Cinder hà rifiutatu categoricamente di fà sta attività. Più precisamente, se crede OpenStack stessu, a cunnessione hè stabilita, ma ùn ci hè micca un dispositivu di discu in u servitore virtuale.
Avemu decisu di piglià un detour è dumandatu a listessa azione da l'API Nova. U risultatu hè chì u dispusitivu cunnetta currettamente è hè accessibile in u servitore. Sembra chì u prublema si trova quandu u block-storage ùn risponde micca à Cinder.
Un'altra difficultà ci aspittava quandu u travagliu cù i dischi. U voluminu di u sistema ùn pò micca esse disconnected from the server.
In novu, OpenStack stessu "ghjura" chì hà distruttu a cunnessione è avà pudete travaglià currettamente cù u voluminu separatamente. Ma l'API categuricamente ùn vulia micca fà operazioni nantu à u discu.
Quì avemu decisu micca di cummattiri particularmente, ma di cambià a nostra vista di a logica di u serviziu. Se ci hè un esempiu, ci deve ancu esse un voluminu di u sistema. Dunque, l'utilizatore ùn pò ancu sguassà o disattivà u "discu" di u sistema senza sguassà u "servitore".
OpenStack hè un inseme abbastanza cumplessu di sistemi cù a so propria logica d'interazione è API ornata. Semu aiutati da una documentazione abbastanza dettagliata è, sicuru, prucessu è errore (induve seremu senza ellu).
Test run
Avemu realizatu un lanciu di prova in dicembre di l'annu passatu. U compitu principale era di pruvà u nostru prughjettu in modu di cummattimentu da u latu tecnicu è da u latu UX. L'audienza hè stata invitata selettivamente è a prova hè stata chjusa. Tuttavia, avemu ancu lasciatu l'opzione di dumandà l'accessu à a prova in u nostru situ web.
A prova stessa, di sicuru, ùn era micca senza i so mumenti divertenti, perchè hè quì chì e nostre avventure sò appena cuminciate.
Prima, avemu valutatu un pocu incorrectamente l'interessu in u prugettu è duvemu aghjustà rapidamente i nodi di calculu ghjustu durante a prova. Un casu cumunu per un cluster, ma ci sò ancu qualchi sfumature quì. A documentazione per una versione specifica di TF indica a versione specifica di u kernel nantu à quale u travagliu cù vRouter hè statu pruvatu. Avemu decisu di lancià nodi cù kernels più recenti. In u risultatu, TF ùn hà micca ricevutu rotte da i nodi. Aviu avutu à rinvià urgentemente i kernels.
Un'altra curiosità hè ligata à a funziunalità di u buttone "cambià password" in u vostru contu persunale.
Avemu decisu di utilizà JWT per urganizà l'accessu à u nostru contu persunale per ùn travaglià cù sessioni. Siccomu i sistemi sò diversi è largamente spargugliati, gestionemu u nostru propiu token, in quale "invecemu" sessioni da a fatturazione è un token da OpenStack. Quandu a password hè cambiata, u token, di sicuru, "va male", postu chì i dati di l'utilizatori ùn sò più validi è deve esse reissued.
Avemu persu di vista di questu puntu, è simpricimenti ùn ci era micca abbastanza risorse per finisce rapidamente stu pezzu. Avemu avutu à tagliate a funziunalità ghjustu prima di lancià a prova.
Attualmente, uscitemu l'utilizatore se a password hè stata cambiata.
Malgradu queste sfumature, a prova hè andata bè. In un paru di settimane, circa 300 persone si fermanu. Pudemu guardà u pruduttu à traversu l'ochji di l'utilizatori, pruvà in l'azzione è raccoglie feedback di alta qualità.
Per esse continuatu
Per parechji di noi, questu hè u primu prughjettu di sta scala. Avemu amparatu una quantità di lezioni preziose nantu à cumu travaglià in squadra è piglià decisioni architettoniche è di cuncepimentu. Cumu integrà i sistemi cumplessi cù pocu risorse è mette in a produzzione.
Di sicuru, ci hè qualcosa per travaglià in quantu à u codice è à l'interfaccia di l'integrazione di u sistema. U prugettu hè abbastanza ghjovanu, ma simu chini di ambizioni per cresce in un serviziu affidabile è cunvene.
Avemu digià pussutu cunvince i sistemi. Bill gestisce debitamente i cunti, a fattura è e richieste di l'utilizatori in u so armariu. A "magia" di i campi di tungstenu ci furnisce una cumunicazione stabile. È solu OpenStack qualchì volta diventa capricciusu, gridendu qualcosa cum'è "'WSREP ùn hà ancu preparatu un nodu per l'usu di l'applicazione". Ma hè una storia completamente diversa...
Recentemente avemu lanciatu u serviziu.
Pudete truvà tutti i dettagli nantu à u nostru .
Squadra di sviluppu CLO
E ligami utili
OpenStack
Tissu tungstènu
Source: www.habr.com