Ahojte všetci, priatelia!
* Tento článok je napísaný na základe otvoreného praktika REBRAIN & Yandex.Cloud, ak radšej sledujete video, môžete ho nájsť na tomto odkaze —
Nedávno sme mali možnosť zažiť Yandex.Cloud naživo. Keďže sme chceli skúmať dlhodobo a podrobne, okamžite sme sa vzdali myšlienky spustiť jednoduchý blog na WordPresse s cloudovou databázou — to by bolo príliš nudné. Po krátkom zamyslení sme sa rozhodli rozbehnúť niečo podobné produkčnej architektúre služby na prijímanie a analýzu udalostí v režime takmer reálneho času.
Som úplne presvedčený, že drvivá väčšina online (ale aj offline) biznisov zbiera množstvo informácií o svojich používateľoch a ich činnostiach. Minimálne je to potrebné na prijímanie určitých rozhodnutí — napríklad, ak spravujete online hru — môžete si pozrieť štatistiku, na ktorej úrovni sa používatelia najčastejšie zaseknú a odstránia vašu hru. Alebo prečo používatelia odchádzajú z vašich stránok, a to aniž by si niečo kúpili (ahoj, Yandex.Metrika).
Takže, náš príbeh: ako sme vytvorili aplikáciu v golangu, testovali kafka vs rabbitmq vs yqs, spracovávali streaming dát do klastru Clickhouse a vizualizovali dáta pomocou Yandex Datalens. Samozrejme, všetko to bolo obohatené o infraštruktúrne zložitosti v podobe dockeru, terraformu, gitlab ci a, samozrejme, prometheusa. Poďme na to!
Je potrebné poznamenať, že nastaviť všetko na prvýkrát nedokážeme — na to budeme potrebovať niekoľko článkov v sérii. Trochu o štruktúre:
1. časť (túto práve čítate). Určíme si technické požiadavky a architektúru riešenia a tiež napíšeme aplikáciu v golangu.
2. časť. Nasadíme našu aplikáciu do produkcie, spravíme ju škálovateľnou a otestujeme záťaž.
3. časť. Pokúsime sa zistiť, prečo je potrebné uchovávať správy v buffri, a nie v súboroch, a porovnáme medzi sebou kafka, rabbitmq a Yandex Queue Service.
4. časť. Budeme rozbiehať klaster Clickhouse, vytvoríme streaming pre prenášanie dát z buffra tam a nastavíme vizualizáciu v Datalens.
5. časť. Upravíme celú infraštruktúru do poriadku — nastavíme ci/cd pomocou gitlab ci, pripojíme monitoring a službu discovery s pomoci prometheusa a consulu.
TS
Najprv formulujeme technické zadanie — čo presne chceme získať na výstupe.
- Chceme mať endpoint vo forme events.kis.im (kis.im — testovacia doména, ktorú budeme používať počas všetkých článkov), ktorý by mal prijímať udalosti cez HTTPS.
- Udalosti sú jednoduchý JSON vo forme: {"event": "view", "os": "linux", "browser": "chrome"}. Na konečnej etape pridáme trochu viac polí, ale to nebude mať veľký význam. Ak máte záujem, môžete prejsť na protobuf.
- Služba by mala zvládnuť spracovať 10 000 udalostí za sekundu.
- Musí byť možnosť horizontálneho škálovania — jednoduchým pridávaním nových inštancií do našich riešení. Bolo by dobré, ak by sme mohli presunúť front-end do rôznych geografických lokalít na zníženie latencie pri požiadavkách klientov.
- Odolnosť voči zlyhaniu. Riešenie by malo byť dostatočne stabilné a schopné prežiť zlyhanie akýchkoľvek častí (do určitého počtu, samozrejme).
Architektúra
Vo všeobecnosti pre takéto úlohy existujú už dávno klasické architektúry, ktoré umožňujú efektívne škálovanie. Na obrázku je uvedený príklad nášho riešenia.
Takže, čo máme:
1. Naľavo sú znázornené naše zariadenia, ktoré generujú rôzne udalosti, či už ide o prechody úrovní hráčov v hre na smartfóne alebo vytvorenie objednávky v internetovom obchode cez bežný prehliadač. Udalosť, ako je uvedené v technickej špecifikácii, je jednoduchý JSON, ktorý sa posiela na náš endpoint — events.kis.im.
2. Prvé dva servery sú jednoduché vyvažovače, ich hlavné úlohy sú:
- Byť neustále dostupné. Na to môžeme použiť napríklad keepalived, ktorý prepne virtuálnu IP medzi uzlami v prípade problémov.
- Termínovať TLS. Áno, TLS budeme termínovať práve na nich. Po prvé, aby naše riešenie vyhovovalo technickej špecifikácii, a po druhé, aby sa znížila záťaž pri nastavovaní šifrovaného pripojenia na našich backend serveroch.
- Vyvažovať prichádzajúce požiadavky na dostupné backend servery. Kľúčové slovo je tu — dostupné. Na základe toho prichádzame k pochopeniu, že vyvažovače záťaže by mali byť schopné monitorovať naše servery s aplikáciami a prestať vyvažovať prenos na zlyhané uzly.
3. Za vyvažovačmi sú naše aplikačné servery, na ktorých beží dostatočne jednoduchá aplikácia. Tá by mala byť schopná prijímať prichádzajúce požiadavky cez HTTP, validovať zaslaný JSON a ukladať údaje do vyrovnávacej pamäte.
4. Ako vyrovnávaciu pamäť na schéme je zobrazená kafka, hoci samozrejme na tejto úrovni môžeme použiť aj iné podobné služby. Kafka, rabbitmq a yqs porovnáme v treťom článku.
5. Predposledným bodom našej architektúry je Clickhouse — stĺpcová databáza, ktorá umožňuje ukladať a spracovávať obrovské objemy dát. Na tejto úrovni je potrebné preniesť dáta z vyrovnávacej pamäte do samotného úložiska (o tom — v 4. článku).
Takáto schéma nám umožňuje nezávisle horizontálne škálovať každú vrstvu. Ak si neporadí backend server — pridáme ďalšie — veď sú to stateless aplikácie, a preto to môžeme urobiť aj automaticky. Ak vyrovnávacia pamäť v podobe kafky nezvládne — pridáme ďalšie servery a presunieme na ne časť partition nášho topicu. Ak si Clickhouse neporadí — to je nemožné 🙂 V skutočnosti pridáme servery a shardujeme dáta.
Mimochodom, ak chcete realizovať voliteľnú časť našich požiadaviek a robiť škálovanie v rôznych geografických lokalitách, nie je to nič zložité:
V každej geografickej lokalite rozbehneme load balancer s aplikáciou a kafka. Vo všeobecnosti stačia 2 application servery, 3 kafka nody a cloudový balancer, napríklad cloudflare, ktorý bude kontrolovať dostupnosť nod aplikácie a vyvažovať požiadavky podľa geografických lokalít na základe pôvodnej IP adresy klienta. Týmto spôsobom dáta zaslané americkým klientom sa dostanú na americké servery. A dáta z Afriky — na africké.
Potom je všetko veľmi jednoduché — použijeme mirror tool z balíka kafky a kopírujeme všetky dáta zo všetkých lokalít do nášho centrálneho dátového centra, ktoré sa nachádza v Rusku. Vo vnútri analyzujeme dáta a zapisujeme ich do Clickhouse pre následnú vizualizáciu.
Takže, architektúru máme pokrytú — začíname skúšať Yandex.Cloud!
Píšeme aplikáciu
Na Cloud ešte potrebujeme chvíľu počkať a napísať dosť jednoduchú službu na spracovanie prichádzajúcich udalostí. Použijeme golang, pretože sa veľmi dobre osvedčil ako jazyk na písanie sieťových aplikácií.
Počas hodiny (možno aj dvoch) získavame približne takýto výsledok: .
Aké hlavné body tu chceme zdôrazniť:
1. Pri spustení aplikácie je možné zadať dva flagy. Jeden z nich určuje port, na ktorom budeme počúvať prichádzajúce http požiadavky (-addr). Druhý - adresu kafka servera, kam budeme zapisovať naše udalosti (-kafka):
addr = flag.String("addr", ":8080", "TCP adresa na počúvanie")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka koncové body")2. Aplikácia používa knižnicu sarama () na odosielanie správ do kafka klastru. Okamžite sme nastavili konfigurácie orientované na maximálnu rýchlosť spracovania:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Náš program tiež obsahuje klienta prometheus, ktorý zbiera rôzne metriky, ako napríklad:
- počet požiadaviek na našu aplikáciu;
- počet chýb pri spracovaní požiadavky (impossibility to read post request, broken json, trouble writing to kafka);
- čas spracovania jednej požiadavky od klienta, vrátane času zápisu správy do kafka.
4. Tri endpointy, ktoré spracováva naša aplikácia:
- /status — просто возвращаем ok, чтобы показать, что мы живы. Хотя можно и добавить некоторые проверки, типа доступности кафка кластера.
- /metrics — по этому url prometheus client будет возвращать собранные им метрики.
- /post — основной endpoint, куда будут приходить POST запросы с json внутри. Наше приложение проверяет json на валидность и если все ок — записывает данные в кафка-кластер.
Mali by sme poznamenať, že kód nie je ideálny - dá sa (a treba!) ho doladiť. Napríklad, je možné vzdať sa použitia zabudovaného net/http a prepnúť sa na rýchlejší fasthttp. Alebo získať čas spracovania a CPU zdroje presunutím overovania platnosti json na neskorší krok - keď budú údaje umiestňované z bufferu do klikhouse klastra.
Okrem vývojového aspektu sme hneď mysleli na našu budúcu infraštruktúru a rozhodli sme sa nasadiť našu aplikáciu prostredníctvom dockeru. Konečný Dockerfile na zostavenie aplikácie - . Celkovo je dosť jednoduchý, jediný moment, na ktorý sa treba zamerať, - je multistage zostavenie, ktoré umožňuje zmenšiť konečný obraz nášho kontajnera.
Prvé kroky v cloude
Najprv sa zaregistrujeme na . Po vyplnení všetkých potrebných polí nám vytvoria účet a poskytnú grant na určitú sumu peňazí, ktorú môžeme použiť na testovanie služieb cloudu. Ak by ste chceli zopakovať všetky kroky z nášho článku, tento grant by vám mal stačiť.
Po registrácii bude pre vás vytvorené samostatné cloud a adresár default, v ktorom môžete začať vytvárať cloudové zdroje. Vo všeobecnosti v Yandex.Cloud vzájomnosť zdrojov vyzerá nasledovne:
Na jeden účet môžete vytvoriť niekoľko cloudov. A vo vnútri cloudu vytvoriť rôzne priečinky pre rôzne projekty spoločnosti. Viac o tom sa dá prečítať v dokumentácii — . Mimochodom, nižšie v texte na ňu budem často odkazovať. Keď som nastavoval celú infraštruktúru od nuly — dokumentácia ma viackrát zachránila, takže odporúčam jej priestudovať.
Na správu cloudu môžete použiť ako webové rozhranie, tak aj konzolovú utilitu — yc. Inštalácia sa vykoná jedným príkazom (pre Linux a Mac OS):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashAk vo vás ohľadom spúšťania skriptov z internetu podráždil vnútorný bezpečnostný pracovník — tak, po prvé, môžete otvoriť skript a prečítať si ho, a po druhé, spúšťame ho pod naším používateľom — bez administrátorských práv.
Ak chcete nainštalovať klienta pre Windows, môžete využiť pokyny a potom vykonať yc init, aby ste ho úplne nakonfigurovali:
vozerov@mba:~ $ yc init
Vitajte! Tento príkaz vás prevedie procesom konfigurácie.
Prosím, prejdite na https://oauth.yandex.ru/authorize?response_type=token&client_id= na získanie OAuth tokenu.
Zadajte prosím OAuth token:
Vyberte cloud, ktorý chcete použiť:
[1] cloud-b1gv67ihgfu3bp (id = b1gv67ihgfu3bpt24o0q)
[2] fevlake-cloud (id = b1g6bvup3toribomnh30)
Zadajte svoj číselný výber: 2
Váš aktuálny cloud bol nastavený na 'fevlake-cloud' (id = b1g6bvup3toribomnh30).
Vyberte priečinok, ktorý chcete použiť:
[1] default (id = b1g5r6h11knotfr8vjp7)
[2] Vytvoriť nový priečinok
Zadajte svoj číselný výber: 1
Váš aktuálny priečinok bol nastavený na 'default' (id = b1g5r6h11knotfr8vjp7).
Chcete nakonfigurovať predvolenú výpočtovú zónu? [Y/n]
Ktorú zónu chcete používať ako predvolený profil?
[1] ru-central1-a
[2] ru-central1-b
[3] ru-central1-c
[4] Nezriaďovať predvolenú zónu
Zadajte svoj číselný výber: 1
Vaša predvolená výpočtová zóna profilu bola nastavená na 'ru-central1-a'.
vozerov@mba:~ $V zásade proces nie je zložitý — najprv je potrebné získať oauth token na správu cloudu, vybrať cloud a priečinok, ktorý budete používať.
Ak máte viac účtov alebo priečinkov v jednom cloude, môžete vytvoriť ďalšie profily s oddelenými nastaveniami cez yc config profile create a prepínať medzi nimi.
Okrem uvedených spôsobov tím Yandex.Cloud napísal veľmi dobrý na správu cloudových zdrojov. Z mojej strany som pripravil git-repozitár, kde som opísal všetky zdroje, ktoré budú vytvorené v rámci článku — . Zaujíma nás vetva master, poďme ju sklonovať lokálne:
vozerov@mba:~ $ git clone https://github.com/rebrainme/yandex-cloud-events/ events
Klonovanie do 'events'...
remote: Enumerovanie objektov: 100, hotovo.
remote: Počítanie objektov: 100% (100/100), hotovo.
remote: Kompresia objektov: 100% (68/68), hotovo.
remote: Celkom 100 (delta 37), opätovne použitých 89 (delta 26), pack-opätovne použitých 0
Prijímanie objektov: 100% (100/100), 25.65 KiB | 168.00 KiB/s, hotovo.
Riešenie deltas: 100% (37/37), hotovo.
vozerov@mba:~ $ cd events/terraform/Všetky hlavné premenné, ktoré sa používajú v Terraform, sú uvedené v súbore main.tf. Pre začatie práce vytvoríme v priečinku terraform súbor private.auto.tfvars s nasledujúcim obsahom:
# Yandex Cloud Oauth token
yc_token = ""
# Yandex Cloud ID
yc_cloud_id = ""
# Yandex Cloud folder ID
yc_folder_id = ""
# Default Yandex Cloud Region
yc_region = "ru-central1-a"
# Cloudflare email
cf_email = ""
# Cloudflare token
cf_token = ""
# Cloudflare zone id
cf_zone_id = ""Všetky premenné môžeme získať z yc config list, keďže príkazový nástroj sme už nastavili. Odporúčam hneď pridať private.auto.tfvars do .gitignore, aby sme náhodou nezverejnili súkromné údaje.
V private.auto.tfvars sme tiež uviedli údaje od Cloudflare — na vytvorenie dns-záznamov a proxy hlavného domény events.kis.im na naše servery. Ak Cloudflare nechcete používať, odstráňte inicializáciu poskytovateľa Cloudflare v main.tf a súbor dns.tf, ktorý je zodpovedný za vytvorenie potrebných dns záznamov.
V našej práci budeme kombinovať všetky tri spôsoby — a webové rozhranie, a príkazový nástroj, a Terraform.
Virtuálne siete
Úprimne povedané, tento krok by sa dal aj preskočiť, pretože pri vytváraní nového cloudu sa automaticky vytvorí samostatná sieť a 3 podsiete — jedna pre každú zónu dostupnosti. No aj tak by sme chceli vytvoriť pre náš projekt samostatnú sieť so svojím adresovaním. Celková schéma fungovania siete v Yandex.Cloud je uvedená na obrázku nižšie (úprimne prevzatá z )
Takže vytvárate spoločnú sieť, v rámci ktorej si môžu zdroje navzájom komunikovať. Pre každú zónu dostupnosti sa vytvára podsieť so svojím adresovaním a pripája sa k spoločnej sieti. V dôsledku toho si môžu všetky cloudové zdroje v nej komunikovať, aj keď sa nachádzajú v rôznych zónach dostupnosti. Zdroje pripojené k rôznym cloudovým sieťam sa môžu vidieť iba cez externé adresy. Mimochodom, ako táto mágia funguje vo vnútri, .
Vytvorenie siete je popísané v súbore network.tf z repozitára. Tam vytvárame jednu spoločnú súkromnú sieť internal a pripájame k nej tri podsiete v rôznych zónach dostupnosti — internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24).
Inicializujeme Terraform a vytvárame siete:
vozerov@mba:~\/events\/terraform (master) $ terraform init
... preskočeno ...
vozerov@mba:~\/events\/terraform (master) $ terraform apply -target yandex_vpc_subnet.internal-a -target yandex_vpc_subnet.internal-b -target yandex_vpc_subnet.internal-c
... preskočeno ...
Plán: 4 na pridanie, 0 na zmenu, 0 na zničenie.
Chcete vykonať tieto akcie?
Terraform vykoná vyššie opísané akcie.
Na schválenie bude prijaté iba 'áno'.
Zadajte hodnotu: áno
yandex_vpc_network.internal: Vytváranie...
yandex_vpc_network.internal: Vytvorenie dokončené po 3s [id=enp2g2rhile7gbqlbrkr]
yandex_vpc_subnet.internal-a: Vytváranie...
yandex_vpc_subnet.internal-b: Vytváranie...
yandex_vpc_subnet.internal-c: Vytváranie...
yandex_vpc_subnet.internal-a: Vytvorenie dokončené po 6s [id=e9b1dad6mgoj2v4funog]
yandex_vpc_subnet.internal-b: Vytvorenie dokončené po 7s [id=e2liv5i4amu52p64ac9p]
yandex_vpc_subnet.internal-c: Stále sa vytvára... [10s uplynulo]
yandex_vpc_subnet.internal-c: Vytvorenie dokončené po 10s [id=b0c2qhsj2vranoc9vhcq]
Aplikácia dokončená! Zdroje: 4 pridané, 0 zmenené, 0 zničené.Skvele! Vytvorili sme našu sieť a teraz sme pripravení na vytváranie našich interných služieb.
Vytvorenie virtuálnych strojov
Na testovanie aplikácie nám bude stačiť vytvoriť dve virtuálne stroje — prvý potrebujeme na zostavenie a spustenie aplikácie, druhý — na spustenie Kafka, ktorú budeme používať na ukladanie prichádzajúcich správ. A vytvoríme ešte jeden stroj, na ktorom nastavíme Prometheus na monitorovanie aplikácie.
Virtuálne stroje sa nakonfigurujú pomocou Ansible, takže pred spustením Terraform sa uistite, že máte jednu z najnovších verzií Ansible. A nainštalujte potrebné roly pomocou Ansible Galaxy:
vozerov@mba:~\/events\/terraform (master) $ cd ..\/ansible\/\nvozerov@mba:~\/events\/ansible (master) $ ansible-galaxy install -r requirements.yml\n- cloudalchemy-prometheus (master) je už nainštalovaný, preskočené.\n- cloudalchemy-grafana (master) je už nainštalovaný, preskočené.\n- sansible.kafka (master) je už nainštalovaný, preskočené.\n- sansible.zookeeper (master) je už nainštalovaný, preskočené.\n- geerlingguy.docker (master) je už nainštalovaný, preskočené.\nvozerov@mba:~\/events\/ansible (master) $Vnútri priečinka ansible je príklad konfiguračného súboru .ansible.cfg, ktorý používam. Možno sa zíde.
Pred vytvorením virtuálnych strojov sa uistite, že máte spustený ssh-agent a pridaný ssh kľúč, inak sa Terraform nebude môcť pripojiť k vytvoreným strojom. Samozrejme, narazil som na chybu v OS X: . Aby sa vám nestalo to isté, pred spustením Terraform pridajte malú premennú do env:
vozerov@mba:~\/events\/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESV priečinku s Terraform vytvárame potrebné zdroje:
vozerov@mba:~\/events\/terraform (master) $ terraform apply -target yandex_compute_instance.build -target yandex_compute_instance.monitoring -target yandex_compute_instance.kafka
yandex_vpc_network.internal: Refreshing state... [id=enp2g2rhile7gbqlbrkr]
data.yandex_compute_image.ubuntu_image: Refreshing state...
yandex_vpc_subnet.internal-a: Refreshing state... [id=e9b1dad6mgoj2v4funog]
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
... skipped ...
Plan: 3 to add, 0 to change, 0 to destroy.
... skipped ...Ak všetko prebehlo úspešne (a malo by), budeme mať tri virtuálne stroje:
- build — stroj na testovanie a zostavovanie aplikácie. Docker bol nainštalovaný automaticky pomocou ansible.
- monitoring — stroj na monitoring — má nainštalovaný prometheus & grafana. Prihlasovacie údaje sú štandardné: admin / admin
- kafka — malý stroj s nainštalovaným kafkom, dostupný na porte 9092.
Overíme, či sú všetky na mieste:
vozerov@mba:~\/events (master) $ yc compute instance list
+----------------------+------------+---------------+---------+---------------+-------------+
| ID | NAME | ZONE ID | STATUS | EXTERNAL IP | INTERNAL IP |
+----------------------+------------+---------------+---------+---------------+-------------+
| fhm081u8bkbqf1pa5kgj | monitoring | ru-central1-a | RUNNING | 84.201.159.71 | 172.16.1.35 |
| fhmf37k03oobgu9jmd7p | kafka | ru-central1-a | RUNNING | 84.201.173.41 | 172.16.1.31 |
| fhmt9pl1i8sf7ga6flgp | build | ru-central1-a | RUNNING | 84.201.132.3 | 172.16.1.26 |
+----------------------+------------+---------------+---------+---------------+-------------+ Zdroje sú na mieste a odtiaľ môžeme získať ich IP adresy. Všetky ďalšie pripojenia budem robiť pomocou IP adries cez SSH a na testovanie aplikácie. Ak máte účet na cloudflare pripojený k terraformu, smelo použite novo vytvorené DNS mená.
Mimochodom, pri vytváraní virtuálnej mašiny sa vygeneruje interná IP adresa a interné DNS meno, takže k serverom v sieti môžeme pristupovať pomocou mien:
ubuntu@build:~$ ping kafka.ru-central1.internal
PING kafka.ru-central1.internal (172.16.1.31) 56(84) bytes of data.
64 bytes from kafka.ru-central1.internal (172.16.1.31): icmp_seq=1 ttl=63 time=1.23 ms
64 bytes from kafka.ru-central1.internal (172.16.1.31): icmp_seq=2 ttl=63 time=0.625 ms
^C
--- kafka.ru-central1.internal ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.625/0.931/1.238/0.308 msTo nám pomôže určiť aplikácii endpoint s kafkou.
Zostavujeme aplikáciu
Skvelé, servery sú pripravené, aplikácia je pripravená — zostáva ju len zostaviť a publikovať. Na zostavenie použijeme bežný docker build a ako úložisko obrazov použijeme službu od Yandexu — container registry. Ale po poriadku.
Skopírujeme aplikáciu na stroj build, pripojíme sa cez SSH a zostavíme obraz:
vozerov@mba:~\/events\/terraform (master) $ cd ..
vozerov@mba:~\/events (master) $ rsync -av app\/ ubuntu@84.201.132.3:app\/\n\n... preskočené ...\n\nsent 3849 bytes received 70 bytes 7838.00 bytes\/sec
total size is 3644 speedup is 0.93\n\nvozerov@mba:~\/events (master) $ ssh 84.201.132.3 -l ubuntu
ubuntu@build:~$ cd app
ubuntu@build:~\/app$ sudo docker build -t app .\nSending build context to Docker daemon 6.144kB\nStep 1\/9 : FROM golang:latest AS build\n... preskočené ...\n\nSuccessfully built 9760afd8ef65\nSuccessfully tagged app:latestPolovica práce je hotová — teraz môžeme skontrolovať funkčnosť našej aplikácie jej spustením a smerovaním na kafka:
ubuntu@build:~\/app$ sudo docker run --name app -d -p 8080:8080 app \/app\/app -kafka=kafka.ru-central1.internal:9092\n\nZ lokálneho stroja môžeme poslať testovací event a pozrieť sa na odpoveď:\n\nvozerov@mba:~\/events (master) $ curl -D - -s -X POST -d '{"key1":"data1"}' http:\/\/84.201.132.3:8080\/post\nHTTP\/1.1 200 OK\nContent-Type: application\/json\nDate: Mon, 13 Apr 2020 13:53:54 GMT\nContent-Length: 41\n\n{"status":"ok","partition":0,"Offset":0}\nvozerov@mba:~\/events (master) $Aplikácia odpovedala úspechom zápisu a uvedením id partitície a offsetu, do ktorého sa správa dostala. Teraz len vytvoriť registry v Yandex.Cloud a nahrať naše image (ako to urobiť pomocou troch riadkov, je popísané v súbore registry.tf). Vytvárame úložisko:
vozerov@mba:~\/events\/terraform (master) $ terraform apply -target yandex_container_registry.events\n\n... preskočené ...\n\nPlan: 1 to add, 0 to change, 0 to destroy.\n\n... preskočené ...\n\nApply complete! Resources: 1 added, 0 changed, 0 destroyed.Na autentifikáciu v container registry existuje niekoľko spôsobov — pomocou oauth tokenu, iam tokenu alebo kľúča servisného účtu. Podrobnejšie informácie o týchto metódach nájdete v dokumentácii. . Použijeme kľúč servisného účtu, preto vytvoríme účet:
vozerov@mba:~\/events\/terraform (master) $ terraform apply -target yandex_iam_service_account.docker -target yandex_resourcemanager_folder_iam_binding.puller -target yandex_resourcemanager_folder_iam_binding.pusher\n\n... preskočené ...\n\nApply complete! Resources: 3 added, 0 changed, 0 destroyed.Teraz zostáva vytvoriť preň kľúč:
vozerov@mba:~\/events\/terraform (master) $ yc iam key create --service-account-name docker -o key.json\nid: ajej8a06kdfbehbrh91p\nservice_account_id: ajep6d38k895srp9osij\ncreated_at: "2020-04-13T14:00:30Z"\nkey_algorithm: RSA_2048Získavame informácie o id našej úložiska, prenášame kľúč a autentifikujeme sa:
vozerov@mba:~\/events\/terraform (master) $ scp key.json ubuntu@84.201.132.3:\nkey.json 100% 2392 215.1KB\/s 00:00\n\nvozerov@mba:~\/events\/terraform (master) $ ssh 84.201.132.3 -l ubuntu\n\nubunt@build:~$ cat key.json | sudo docker login --username json_key --password-stdin cr.yandex\nWARNING! Your password will be stored unencrypted in \/home\/ubuntu\/.docker\/config.json.\nConfigure a credential helper to remove this warning. See\nhttps:\/\/docs.docker.com\/engine\/reference\/commandline\/login\/#credentials-store\n\nLogin Succeeded\nubunt@build:~$Na nahratie image do registry budeme potrebovať ID container registry, berieme ho z utilitiy yc:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Potom označíme náš obraz novým názvom a nahrajeme ho:
ubuntu@build:~$ sudo docker tag app cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1
ubuntu@build:~$ sudo docker push cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1
The push refers to repository [cr.yandex/crpdgj6c9umdhgaqjfmm/events]
8c286e154c6e: Pushed
477c318b05cb: Pushed
beee9f30bc1f: Pushed
v1: digest: sha256:1dd5aaa9dbdde2f60d833be0bed1c352724be3ea3158bcac3cdee41d47c5e380 size: 946Môžeme si overiť, že obraz bol úspešne nahraný:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Mimochodom, ak si nainštalujete nástroj yc na stroj s linuxom, môžete použiť príkaz
yc container registry configure-dockerna nastavenie dokera.
Záver
Urobili sme veľkú a náročnú prácu a ako výsledok:
- Vytvorili sme architektúru našej budúcej služby.
- Napísali sme aplikáciu v golangu, ktorá implementuje našu obchodnú logiku.
- Zostavili sme ju a uvoľnili do súkromného registry kontajnerov.
V ďalšej časti prejdeme k zaujímavému — uvoľníme našu aplikáciu do produkcie a konečne na ňu spustíme zaťaženie. Nepreladzujte sa!
Tento materiál je k dispozícii vo videozázname otvoreného praktika REBRAIN & Yandex.Cloud: Prijímame 10 000 požiadaviek za sekundu na Yandex Cloud —
Ak máte záujem zúčastniť sa takýchto akcií online a klásť otázky v reálnom čase, pripojte sa k.
Osobitné poďakovanie patrí Yandex.Cloud za možnosť uskutočniť takéto podujatie. Odkaz na nich —
Ak potrebujete presun do cloudu alebo máte otázky týkajúce sa vašej infraštruktúry, .
P.S. Máme 2 bezplatné audity mesačne, možno práve váš projekt bude v ich počte.
Zdroj: habr.com
