Ne zhvilluam DevOps sa më mirë që mundëm. Ishim 8 veta, dhe Vasya ishte më e lezetshme në Windows. Papritmas Vasya u largua dhe unë kisha për detyrë të nisja një projekt të ri që u furnizua nga zhvillimi i Windows. Kur hodha të gjithë grumbullin e zhvillimit të Windows në tryezë, kuptova se situata ishte një dhimbje...
Kështu fillon historia Alexandra Sinchinova mbi . Kur specialisti kryesor i Windows u largua nga kompania, Aleksandri mendoi se çfarë të bënte tani. Kalo në Linux, sigurisht! Alexander do t'ju tregojë se si ai arriti të krijojë një precedent dhe të transferojë një pjesë të zhvillimit të Windows në Linux duke përdorur shembullin e një projekti të përfunduar për 100 përdorues fundorë.
Si të dorëzoni me lehtësi dhe pa mundim një projekt në RPM duke përdorur bërthamën TFS, Puppet, Linux .NET? Si të mbështetet versioni i bazës së të dhënave të projektit nëse ekipi i zhvillimit dëgjon fjalët Postgres dhe Flyway për herë të parë dhe afati përfundimtar është pasnesër? Si të integroheni me Docker? Si të motivoni zhvilluesit e .NET që të braktisin Windows dhe smoothies në favor të Puppet dhe Linux? Si të zgjidhen konfliktet ideologjike nëse nuk ka as forcë, as dëshirë, as burime për të mbajtur Windows në prodhim? Për këtë, si dhe për vendosjen e uebit, testimin, CI, për praktikat e përdorimit të TFS në projektet ekzistuese dhe, natyrisht, për patericat e thyera dhe zgjidhjet e punës, në transkriptin e raportit të Alexander.
Pra, Vasya u largua, detyra është mbi mua, zhvilluesit po presin me padurim me pirunët. Kur më në fund kuptova që Vasya nuk mund të kthehej, u nisa për biznes. Për të filluar, unë vlerësova përqindjen e Win VM në flotën tonë. Rezultati nuk ishte në favor të Windows.
Meqenëse po zhvillojmë në mënyrë aktive DevOps, kuptova se diçka duhet ndryshuar në qasjen për ofrimin e një aplikacioni të ri. Kishte vetëm një zgjidhje - nëse është e mundur, transferoni gjithçka në Linux. Google më ndihmoi - në atë kohë .Net tashmë ishte transferuar në Linux, dhe kuptova se kjo ishte zgjidhja!
Pse bërthama .NET në lidhje me Linux?
Kishte disa arsye për këtë. Midis "paguaj para" dhe "mos paguaj", shumica do të zgjedhë të dytën - si unë. Një licencë për MSDB kushton rreth 1 dollarë; mirëmbajtja e një flote makinash virtuale Windows kushton qindra dollarë. Për një kompani të madhe ky është një shpenzim i madh. Kjo është arsyeja pse kursime - arsyeja e parë. Jo më e rëndësishmja, por një nga më të rëndësishmet.
Makinat virtuale Windows marrin më shumë burime sesa vëllezërit e tyre Linux - ato janë të rënda. Duke pasur parasysh shkallën e kompanisë së madhe, ne zgjodhëm Linux.
Sistemi është thjesht i integruar në CI ekzistuese. Ne e konsiderojmë veten DevOps progresive, përdorim Bamboo, Jenkins dhe GitLab CI, kështu që shumica e punës sonë funksionon në Linux.
Arsyeja e fundit është shoqërim i përshtatshëm. Na duhej të ulnim pengesën e hyrjes për "shoqëruesit" - djemtë që kuptojnë pjesën teknike, siguronin shërbim të pandërprerë dhe ruanin shërbimet nga linja e dytë. Ata tashmë ishin të njohur me grupin Linux, kështu që është shumë më e lehtë për ta të kuptojnë, mbështesin dhe mirëmbajnë një produkt të ri sesa të shpenzojnë burime shtesë për të kuptuar të njëjtin funksionalitet të softuerit për platformën Windows.
Kërkesat
Para së gjithash - komoditeti i zgjidhjes së re për zhvilluesit. Jo të gjithë ishin gati për ndryshim, veçanërisht pasi u fol fjala Linux. Zhvilluesit duan Visual Studio e tyre të preferuar, TFS me autoteste për montime dhe smoothie. Mënyra se si ndodh dorëzimi në prodhim nuk është e rëndësishme për ta. Prandaj, vendosëm të mos ndryshojmë procesin e zakonshëm dhe të lëmë gjithçka të pandryshuar për zhvillimin e Windows.
Nevojitet projekt i ri integrohen në CI ekzistuese. Binarët ishin tashmë aty dhe e gjithë puna duhej bërë duke marrë parasysh parametrat e sistemit të menaxhimit të konfigurimit, standardet e pranuara të dorëzimit dhe sistemet e monitorimit.
Lehtësia e mbështetjes dhe funksionimit, si kusht për pragun minimal të hyrjes për të gjithë pjesëmarrësit e rinj nga divizione të ndryshme dhe departamenti mbështetës.
Afati - dje.
Win Development Group
Me çfarë punonte atëherë ekipi i Windows?
Tani mund ta them me bindje këtë IdentityServer4 është një alternativë e lezetshme falas për ADFS me aftësi të ngjashme, ose çfarë Bërthama e Kornizës së Entitetit - një parajsë për një zhvillues, ku nuk duhet të shqetësoheni për të shkruar skriptet SQL, por përshkruani pyetjet në bazën e të dhënave në terma OOP. Por më pas, gjatë diskutimit të planit të veprimit, e shikova këtë pirg sikur të ishte kuneiformë sumeriane, duke njohur vetëm PostgreSQL dhe Git.
Në atë kohë ne përdornim në mënyrë aktive kukull si një sistem i menaxhimit të konfigurimit. Në shumicën e projekteve tona kemi përdorur GitLab CI, Elastik, duke përdorur shërbime të balancuara me ngarkesë të lartë HAProxy monitoruar gjithçka me Zabbix, ligamentet grafana и Prometeu, Jaeger, dhe e gjithë kjo rrotullohej mbi copa hekuri HP c ESXi mbi VMware. Të gjithë e dinë - një klasik i zhanrit.
Le të shohim dhe të përpiqemi të kuptojmë se çfarë po ndodhte përpara se të fillonim të gjitha këto ndërhyrje.
Cfare ndodhi
TFS është një sistem mjaft i fuqishëm që jo vetëm që shpërndan kodin nga zhvilluesi në makinën përfundimtare të prodhimit, por gjithashtu ka një grup për integrim shumë fleksibël me shërbime të ndryshme - për të ofruar CI në një nivel ndër-platformë.
Më parë, këto ishin dritare të forta. TFS përdori disa agjentë Build, të cilët u përdorën për të mbledhur shumë projekte. Çdo agjent ka 3-4 punëtorë për të paralelizuar detyrat dhe për të optimizuar procesin. Më pas, sipas planeve të lëshimit, TFS dorëzoi Build-in e sapopjekur në serverin e aplikacionit Windows.
Çfarë donim të arrinim?
Ne përdorim TFS për shpërndarje dhe zhvillim, dhe e ekzekutojmë aplikacionin në një server të aplikacionit Linux, dhe ka një lloj magjie mes tyre. Kjo Kutia Magjike dhe atje është kripa e punës përpara. Përpara se ta shkëput, do të bëj një hap mënjanë dhe do të them disa fjalë për aplikacionin.
Projekt
Aplikacioni ofron funksionalitet për trajtimin e kartave me parapagesë.
klient
Kishte dy lloje përdoruesish. I parë fitoi akses duke u identifikuar duke përdorur një certifikatë SSL SHA-2. U e dyta kishte akses duke përdorur një hyrje dhe fjalëkalim.
HAProxy
Pastaj kërkesa e klientit shkoi në HAProxy, e cila zgjidhi problemet e mëposhtme:
- autorizimi primar;
- Përfundimi SSL;
- akordimi i kërkesave HTTP;
- kërkesat për transmetim.
Certifikata e klientit u verifikua përgjatë zinxhirit. ne - autoritet dhe ne mund ta përballojmë këtë, pasi ne vetë lëshojmë certifikata për klientët e shërbimit.
Kushtojini vëmendje pikës së tretë, do t'i kthehemi pak më vonë.
backend
Ata planifikonin të bënin backend-in në Linux. Backend-i ndërvepron me bazën e të dhënave, ngarkon listën e nevojshme të privilegjeve dhe më pas, në varësi të privilegjeve që ka përdoruesi i autorizuar, siguron akses për të nënshkruar dokumente financiare dhe për t'i dërguar ato për ekzekutim, ose për të gjeneruar një lloj raporti.
Kursime me HAProxy
Përveç dy konteksteve që lundronte secili klient, kishte edhe një kontekst identiteti. IdentityServer4 thjesht ju lejon të identifikoheni, ky është një analog falas dhe i fuqishëm për ADFS - Shërbimet e Federatës Active Directory.
Kërkesa për identitetin u përpunua në disa hapa. Hapi i parë - klient u fut në fund, i cili komunikoi me këtë server dhe kontrolloi praninë e një token për klientin. Nëse nuk gjendej, kërkesa kthehej përsëri në kontekstin prej nga vinte, por me ridrejtim dhe me ridrejtimin shkonte në identitet.
Hapi i dytë - kërkesa u pranua në faqen e autorizimit në IdentityServer, ku klienti u regjistrua dhe ai token i shumëpritur u shfaq në bazën e të dhënave IdentityServer.
Hapi i tretë - klienti u ridrejtua prapa në kontekstin nga erdhi.
IdentityServer4 ka një veçori: kthen përgjigjen në kërkesën e kthimit nëpërmjet HTTP. Pa marrë parasysh se sa shumë kemi luftuar me vendosjen e serverit, pa marrë parasysh sa ndriçoheshim me dokumentacionin, sa herë merrnim një kërkesë fillestare të klientit me një URL që vinte nëpërmjet HTTPS dhe IdentityServer kthente të njëjtin kontekst, por me HTTP. Ne ishim të tronditur! Dhe ne i transferuam të gjitha këto përmes kontekstit të identitetit në HAProxy, dhe në titujt duhej të modifikonim protokollin HTTP në HTTPS.
Cili është përmirësimi dhe ku keni kursyer?
Kemi kursyer para duke përdorur një zgjidhje falas për autorizimin e një grupi përdoruesish, burimesh, pasi nuk e vendosëm IdentityServer4 si një nyje të veçantë në një segment të veçantë, por e përdorëm atë së bashku me backend-in në të njëjtin server ku funksionon backend-i i aplikacionit. .
Si duhet të funksionojë
Pra, siç premtova - Kutia Magjike. Ne tashmë e kuptojmë se jemi të garantuar të shkojmë drejt Linux. Le të formulojmë detyra specifike që kërkonin zgjidhje.
Manifestohet kukulla. Për të ofruar dhe menaxhuar konfigurimin e shërbimit dhe aplikacionit, duhej të shkruheshin receta interesante. Një rrotull lapsi tregon në mënyrë elokuente sa shpejt dhe me efikasitet është bërë.
Metodat e dërgesës. Standardi është RPM. Të gjithë e kuptojnë që në Linux nuk mund të bësh pa të, por vetë projekti, pas montimit, ishte një grup skedarësh DLL të ekzekutueshëm. Ishin rreth 150 të tillë, projekti ishte mjaft i vështirë. Zgjidhja e vetme harmonike është paketimi i këtij binar në RPM dhe vendosja e aplikacionit prej tij.
Versionimi. Na duhej të lëshonim shumë shpesh dhe duhej të vendosnim se si të formonim emrin e paketës. Kjo është një çështje e nivelit të integrimit me TFS. Ne kishim një agjent ndërtimi në Linux. Kur TFS i dërgon një detyrë një menaxheri - punonjësi - te agjenti Build, ai gjithashtu i kalon asaj një grup variablash që përfundojnë në mjedisin e procesit të mbajtësit. Këto variabla të mjedisit përmbajnë emrin e ndërtimit, emrin e versionit dhe variabla të tjerë. Lexoni më shumë rreth kësaj në seksionin "Ndërtimi i një pakete RPM".
Konfigurimi i TFS erdhi deri te ngritja e Pipeline. Më parë, ne mblodhëm të gjitha projektet e Windows në agjentët e Windows, por tani shfaqet një agjent Linux - një agjent Build, i cili duhet të përfshihet në grupin e ndërtimit, të pasurohet me disa artefakte dhe të tregohet se çfarë lloj projektesh do të ndërtohen në këtë agjent Build. , dhe modifikoni disi tubacionin.
IdentityServer. ADFS nuk është rruga jonë, ne po shkojmë për Open Source.
Le të kalojmë nëpër komponentët.
Kutia Magjike
Përbëhet nga katër pjesë.
Agjent Linux Build. Linux, sepse ne ndërtojmë për të - është logjike. Kjo pjesë është bërë në tre hapa.
- Konfiguro punëtorët dhe jo vetëm, pasi pritej puna e shpërndarë në projekt.
- Instaloni .NET Core 1.x. Pse 1.x kur 2.0 është tashmë i disponueshëm në depon standarde? Sepse kur filluam zhvillimin, versioni stabil ishte 1.09 dhe u vendos që të bëhej projekti në bazë të tij.
- Git 2.x.
RPM-depo. Paketat RPM duhej të ruheshin diku. Supozohej se do të përdornim të njëjtin depo të korporatës RPM që është i disponueshëm për të gjithë hostet Linux. Kështu bënë. Serveri i depove është konfiguruar grep uebi i cili shkarkoi paketën e kërkuar RPM nga lokacioni i specifikuar. Versioni i paketës u raportua në webhook nga agjenti Build.
GitLab Kujdes! GitLab këtu nuk përdoret nga zhvilluesit, por nga departamenti i operacioneve për të kontrolluar versionet e aplikacionit, versionet e paketave, monitorimin e statusit të të gjitha makinave Linux dhe ruan recetën - të gjitha manifestimet e Puppet.
kukull — zgjidh të gjitha çështjet e diskutueshme dhe jep saktësisht konfigurimin që duam nga Gitlab.
Ne fillojmë të zhytemi. Si funksionon dorëzimi i DLL në RPM?
Dorëzimi i DDL në RPM
Le të themi se kemi një rockstar të zhvillimit .NET. Ai përdor Visual Studio dhe krijon një degë lëshimi. Pas kësaj, ai e ngarkon atë në Git, dhe Git këtu është një entitet TFS, domethënë është depoja e aplikacionit me të cilën punon zhvilluesi.
Pas së cilës TFS sheh që ka mbërritur një komision i ri. Cilin aplikacion? Në cilësimet TFS ka një etiketë që tregon se çfarë burimesh ka një agjent i veçantë Build. Në këtë rast, ai sheh që ne po ndërtojmë një projekt .NET Core dhe zgjedh një agjent Linux Build nga grupi.
Agjenti Build merr burimet dhe shkarkon të nevojshme varësi nga depoja .NET, npm, etj. dhe pas ndërtimit të vetë aplikacionit dhe paketimit pasues, dërgon paketën RPM në depo RPM.
Nga ana tjetër, ndodh si më poshtë. Inxhinieri i departamentit të operacioneve është i përfshirë drejtpërdrejt në prezantimin e projektit: ai ndryshon versionet e paketave Hiera në depon ku ruhet receta e aplikimit, pas së cilës Puppet aktivizohet Yum, merr paketën e re nga depoja dhe versioni i ri i aplikacionit është gati për t'u përdorur.
Gjithçka është e thjeshtë me fjalë, por çfarë ndodh brenda vetë agjentit Build?
RPM i paketimit DLL
Marrë burimet e projektit dhe ndërtimin e detyrës nga TFS. Ndërtimi i agjentit fillon ndërtimin e vetë projektit nga burimet. Projekti i montuar është në dispozicion si një grup Skedarët DLL, të cilat janë të paketuara në një arkiv zip për të reduktuar ngarkesën në sistemin e skedarëve.
Arkivi ZIP është hedhur tutje në drejtorinë e ndërtimit të paketës RPM. Më pas, skripti Bash inicializon variablat e mjedisit, gjen versionin Build, versionin e projektit, shtegun për në direktorinë e ndërtimit dhe ekzekuton RPM-build. Pasi të përfundojë ndërtimi, paketa publikohet në depo lokale, i cili ndodhet në agjentin Build.
Më pas, nga agjenti Build në server në depon e RPM Kërkesa JSON është dërguar duke treguar emrin e versionit dhe të ndërtimit. Webhook, për të cilin fola më herët, shkarkon pikërisht këtë paketë nga depoja lokale në agjentin Build dhe e vë në dispozicion për instalim asamblenë e re.
Pse kjo skemë e veçantë e dorëzimit të paketës në depon e RPM? Pse nuk mund ta dërgoj menjëherë paketën e montuar në depo? Fakti është se ky është një kusht për të garantuar sigurinë. Ky skenar kufizon mundësinë e njerëzve të paautorizuar të ngarkojnë paketa RPM në një server që është i aksesueshëm për të gjitha makinat Linux.
Versionimi i bazës së të dhënave
Në një konsultim me ekipin e zhvillimit, doli që djemtë ishin më afër MS SQL, por në shumicën e projekteve jo-Windows ne po përdornim tashmë PostgreSQL me gjithë fuqinë e tyre. Meqenëse kishim vendosur tashmë të braktisnim gjithçka që paguhet, filluam të përdorim PostgreSQL edhe këtu.
Në këtë pjesë dua t'ju tregoj se si e kemi versionuar bazën e të dhënave dhe si kemi zgjedhur midis Flyway dhe Entity Framework Core. Le të shohim të mirat dhe të këqijat e tyre.
Cons
Flyway shkon vetëm në një drejtim, ne nuk mund të tërhiqemi - ky është një disavantazh i rëndësishëm. Mund ta krahasoni atë me Entity Framework Core në mënyra të tjera - për sa i përket komoditetit të zhvilluesit. Ju kujtohet se ne e vendosëm këtë në krye dhe kriteri kryesor ishte të mos ndryshonim asgjë për zhvillimin e Windows.
Për Flyway us nevojitej një lloj mbështjellësinë mënyrë që djemtë të mos shkruajnë Pyetjet SQL. Ata janë shumë më afër funksionimit në terma të OOP. Ne shkruam udhëzime për të punuar me objektet e bazës së të dhënave, krijuam një pyetje SQL dhe e ekzekutuam atë. Versioni i ri i bazës së të dhënave është gati, i testuar - gjithçka është në rregull, gjithçka funksionon.
Entity Framework Core ka një minus - atë nën ngarkesa të rënda ndërton pyetje nënoptimale SQL, dhe tërheqja në bazën e të dhënave mund të jetë e rëndësishme. Por duke qenë se ne nuk kemi një shërbim me ngarkesë të lartë, ne nuk e llogarisim ngarkesën në qindra RPS, ne i pranuam këto rreziqe dhe ia deleguam problemin neve të ardhmes.
Rekuizitë
Bërthama e Kornizës së Entitetit punon jashtë kutisë dhe është e lehtë për t'u zhvilluar, dhe Flyway Integrohet lehtësisht në CI ekzistuese. Por ne e bëjmë atë të përshtatshëm për zhvilluesit :)
Procedura e përmbledhjes
Puppet sheh se një ndryshim në versionin e paketës po vjen, duke përfshirë atë që është përgjegjës për migrimin. Së pari, ai instalon një paketë që përmban skriptet e migrimit dhe funksionalitetin e lidhur me bazën e të dhënave. Pas kësaj, aplikacioni që punon me bazën e të dhënave riniset. Më pas vjen instalimi i komponentëve të mbetur. Rendi në të cilin instalohen paketat dhe lëshohen aplikacionet përshkruhet në manifestin e Kukullave.
Aplikacionet përdorin të dhëna të ndjeshme, të tilla si argumentet, fjalëkalimet e bazës së të dhënave, e gjithë kjo tërhiqet në konfigurimin nga Puppet Master, ku ruhen në formë të koduar.
Problemet e TFS
Pasi vendosëm dhe kuptuam se gjithçka po funksiononte vërtet për ne, vendosa të shikoja se çfarë po ndodhte me asambletë në TFS në tërësi për departamentin e zhvillimit të Win në projekte të tjera - nëse po ndërtonim/lëshonim shpejt apo jo, dhe zbuloi probleme të rëndësishme me shpejtësinë.
Një nga projektet kryesore merr 12-15 minuta për t'u mbledhur - kjo është një kohë e gjatë, nuk mund të jetosh kështu. Një analizë e shpejtë tregoi një ulje të tmerrshme në I/O, dhe kjo ishte në vargje.
Pasi e analizova komponent pas komponenti, identifikova tre vatra. Së pari - "Kaspersky antivirus", i cili skanon burimet në të gjithë agjentët e Windows Build. E dyta - Dritaret Indeksues. Nuk u çaktivizua dhe gjithçka u indeksua në kohë reale në agjentët e Build gjatë procesit të vendosjes.
E treta - Instaloni Npm. Doli që në shumicën e tubacioneve ne përdorëm pikërisht këtë skenar. Pse është i keq? Procedura e instalimit Npm ekzekutohet kur formohet pema e varësisë paketë-kyç.json, ku regjistrohen versionet e paketave që do të përdoren për të ndërtuar projektin. E keqja është se instalimi Npm nxjerr çdo herë versionet më të fundit të paketave nga Interneti, dhe kjo kërkon shumë kohë në rastin e një projekti të madh.
Zhvilluesit ndonjëherë eksperimentojnë në një makinë lokale për të testuar se si funksionon një pjesë e caktuar ose e tërë projekti. Ndonjëherë doli që gjithçka ishte e freskët në vend, por ata e montuan atë, e rrokullisnin dhe asgjë nuk funksionoi. Ne fillojmë të kuptojmë se cili është problemi - po, versione të ndryshme të paketave me varësi.
vendim
- Burimet në përjashtimet AV.
- Çaktivizo indeksimin.
- Shko te npm ci.
Përparësitë e npm ci janë se ne Ne mbledhim pemën e varësisë një herë, dhe ne kemi mundësinë t'i ofrojmë zhvilluesit lista aktuale e paketave, me të cilën ai mund të eksperimentojë në nivel lokal sa të dojë. Kjo kursen kohë zhvilluesit që shkruajnë kodin.
konfiguracion
Tani pak për konfigurimin e depove. Historikisht ne përdorim Lidhje për menaxhimin e depove, duke përfshirë REPO e brendshme. Kjo depo e brendshme përmban të gjithë komponentët që ne përdorim për qëllime të brendshme, për shembull, monitorimin e shkruar vetë.
Ne gjithashtu përdorim NuGet, pasi ka caching më të mirë në krahasim me menaxherët e tjerë të paketave.
Result
Pasi optimizuam Build Agents, koha mesatare e ndërtimit u reduktua nga 12 minuta në 7.
Nëse numërojmë të gjitha makinat që mund të kishim përdorur për Windows, por kaluam në Linux në këtë projekt, ne kemi kursyer rreth 10 dollarë.Dhe kjo është vetëm për licencat, dhe më shumë nëse marrim parasysh përmbajtjen.
Planet
Për tremujorin e ardhshëm, ne kemi planifikuar të punojmë në optimizimin e shpërndarjes së kodit.
Kalimi në një imazh të para-ndërtuar Docker. TFS është një gjë interesante me shumë shtojca që ju lejojnë të integroheni në Pipeline, duke përfshirë montimin e bazuar në shkas të, të themi, një imazh Docker. Ne duam ta bëjmë këtë shkas për të njëjtin paketë-kyç.json. Nëse përbërja e komponentëve të përdorur për të ndërtuar projektin ndryshon disi, ne ndërtojmë një imazh të ri Docker. Më vonë përdoret për të vendosur kontejnerin me aplikacionin e montuar. Ky nuk është rasti tani, por ne po planifikojmë të kalojmë në një arkitekturë mikroservice në Kubernetes, e cila po zhvillohet në mënyrë aktive në kompaninë tonë dhe i ka shërbyer zgjidhjeve të prodhimit për një kohë të gjatë.
Përmbledhje
I inkurajoj të gjithë të hedhin Windows-in, por jo sepse nuk di ta gatuaj. Arsyeja është se shumica e zgjidhjeve Opensource janë Stack Linux. A je mirë kurseni në burime. Sipas mendimit tim, e ardhmja i përket zgjidhjeve me burim të hapur në Linux me një komunitet të fuqishëm.
Profili i folësit të Alexander Sinchinov .
është një konferencë mbi integrimin e proceseve të zhvillimit, testimit dhe funksionimit për profesionistë nga profesionistë. Ja pse projekti për të cilin foli Aleksandri? implementuar dhe funksionuar, dhe në ditën e shfaqjes pati dy publikime të suksesshme. Aktiv Në datat 27 dhe 28 maj do të ketë edhe më shumë raste të ngjashme nga praktikuesit. Ju ende mund të hidheni në karrocën e fundit dhe ose merrni kohën tuaj biletë. Na takoni në Skolkovo!
Burimi: www.habr.com