V Yandex.Cloud sprejemamo 10 dogodkov. 000. del

Pozdravljeni vsi, prijatelji!

* Ta članek temelji na odprti delavnici REBRAIN & Yandex.Cloud, če si raje ogledate videoposnetek, ga najdete na tej povezavi - https://youtu.be/cZLezUm0ekE

Nedavno smo imeli priložnost preizkusiti Yandex.Cloud v živo. Ker smo želeli dolgo in trdo sondirati, smo takoj opustili zamisel o zagonu preprostega bloga Wordpress z oblačno bazo - bilo je preveč dolgočasno. Po premisleku smo se odločili uvesti nekaj podobnega arhitekturi produkcijskih storitev za sprejemanje in analiziranje dogodkov v skoraj realnem času.

Popolnoma sem prepričan, da velika večina spletnih (pa ne samo) podjetij nekako zbira goro informacij o svojih uporabnikih in njihovih dejanjih. To je potrebno vsaj za sprejemanje določenih odločitev - če na primer upravljate spletno igro, lahko pogledate statistiko, na kateri stopnji se uporabniki najpogosteje zataknejo in izbrišejo vašo igračo. Ali zakaj uporabniki zapustijo vaše spletno mesto, ne da bi kaj kupili (pozdravljeni, Yandex.Metrica).

Torej, naša zgodba: kako smo napisali aplikacijo v golangu, preizkusili kafko proti rabbitmq proti yqs, zapisali pretakanje podatkov v gručo Clickhouse in vizualizirali podatke z uporabo yandex datalens. Seveda je bilo vse to začinjeno z infrastrukturnimi poslasticami v obliki dockerja, terraforma, gitlaba ci in seveda prometheusa. Pojdimo!

Rad bi takoj rekel, da ne bomo mogli konfigurirati vsega v eni seji - za to bomo potrebovali več člankov v seriji. Malo o strukturi:

1. del (berete ga). Odločili se bomo o specifikacijah in arhitekturi rešitve ter napisali aplikacijo v golangu.
2. del. Našo aplikacijo izdamo v produkcijo, jo naredimo razširljivo in testiramo obremenitev.
3. del Poskusimo ugotoviti, zakaj moramo sporočila shranjevati v medpomnilniku in ne v datotekah, ter primerjajmo kafko, rabbitmq in storitev čakalne vrste yandex.
4. del Razmestili bomo gručo Clickhouse, napisali pretočno storitev za prenos podatkov iz medpomnilnika tja in nastavili vizualizacijo v datalensu.
5. del Spravimo celotno infrastrukturo v pravo obliko - nastavimo ci/cd z uporabo gitlab ci, povežimo spremljanje in odkrivanje storitev z uporabo prometheusa in consul.

TK

Najprej oblikujmo nalogo - kaj točno želimo dobiti kot rezultat.

  1. Želimo imeti končno točko, kot je events.kis.im (kis.im je testna domena, ki jo bomo uporabljali v vseh člankih), ki bi morala prejemati dogodke prek HTTPS.
  2. Dogodki so preprost json, kot je: {“event”: “view”, “os”: “linux”, “brskalnik”: “chrome”}. V končni fazi bomo dodali še nekaj polj, vendar to ne bo imelo velike vloge. Če želite, lahko preklopite na protobuf.
  3. Storitev mora biti sposobna obdelati 10 dogodkov na sekundo.
  4. Možno bi moralo biti vodoravno prilagajanje s preprostim dodajanjem novih primerkov naši rešitvi. In lepo bi bilo, če bi lahko sprednji del premaknili na različne geolokacije, da zmanjšamo zakasnitev za zahteve strank.
  5. Toleranca napak. Rešitev mora biti dovolj stabilna in sposobna preživeti padec poljubnih delov (seveda do določenega števila).

arhitektura

Na splošno so za tovrstne naloge že dolgo izumljene klasične arhitekture, ki omogočajo učinkovito skaliranje. Slika prikazuje primer naše rešitve.

V Yandex.Cloud sprejemamo 10 dogodkov. 000. del

Torej, kaj imamo:

1. Na levi strani so naše naprave, ki generirajo različne dogodke, pa naj gre za igralce, ki dokončajo stopnjo v igrači na pametnem telefonu ali ustvarijo naročilo v spletni trgovini prek običajnega brskalnika. Dogodek, kot je določeno v specifikaciji, je preprost json, ki se pošlje naši končni točki - events.kis.im.

2. Prva dva strežnika sta enostavna balanserja, njune glavne naloge so:

  • Bodite nenehno dosegljivi. Za to lahko uporabite na primer keepalived, ki bo v primeru težav preklapljal virtualni IP med vozlišči.
  • Prekini TLS. Da, preklicali bomo TLS na njih. Prvič, da bo naša rešitev skladna s tehničnimi specifikacijami, in drugič, da se razbremenimo vzpostavljanja šifrirane povezave z našimi zalednimi strežniki.
  • Uravnotežite dohodne zahteve z razpoložljivimi zalednimi strežniki. Ključna beseda tukaj je dostopna. Na podlagi tega smo ugotovili, da morajo imeti izravnalniki obremenitve možnost nadzorovati naše strežnike z aplikacijami in ustaviti uravnoteženje prometa do okvarjenih vozlišč.

3. Za izravnalniki imamo aplikacijske strežnike, ki izvajajo dokaj preprosto aplikacijo. Moral bi biti sposoben sprejemati dohodne zahteve prek HTTP, preverjati poslani json in shraniti podatke v medpomnilnik.

4. Diagram prikazuje kafko kot medpomnilnik, čeprav je seveda mogoče na tej ravni uporabljati tudi druge podobne storitve. Kafko, rabbitmq in yqs bomo primerjali v tretjem članku.

5. Predzadnja točka naše arhitekture je Clickhouse – stolpična baza podatkov, ki omogoča shranjevanje in obdelavo ogromne količine podatkov. Na tem nivoju moramo prenesti podatke iz medpomnilnika v sam sistem za shranjevanje (več o tem v 4. členu).

Ta zasnova nam omogoča neodvisno vodoravno skaliranje vsake plasti. Zaledni strežniki se ne morejo spopasti - dodajmo še eno stvar - navsezadnje so aplikacije brez stanja, zato je to mogoče storiti celo samodejno. Medpomnilnik v slogu Kafke ne deluje - dodajmo več strežnikov in nanje prenesimo nekaj particij naše teme. Clickhouse tega ne zmore - to je nemogoče :) Pravzaprav bomo tudi povezali strežnike in razdelili podatke.

Mimogrede, če želite implementirati izbirni del naših tehničnih specifikacij in obsega na različnih geolokacijah, potem ni nič preprostejšega:

V Yandex.Cloud sprejemamo 10 dogodkov. 000. del

Na vsaki geolokaciji postavimo izravnalnik obremenitve z aplikacijo in kafko. Na splošno sta dovolj 2 aplikacijska strežnika, 3 kafka vozlišča in cloud balancer, na primer cloudflare, ki bo preverjal razpoložljivost aplikacijskih vozlišč in zahteve za uravnoteženje z geolokacijo glede na odjemalčev izvorni IP naslov. Tako bodo podatki, ki jih pošlje ameriški odjemalec, pristali na ameriških strežnikih. In podatki iz Afrike so v afriškem jeziku.

Potem je vse povsem preprosto – uporabimo orodje za zrcalo iz nabora Kafka in kopiramo vse podatke z vseh lokacij v naš centralni podatkovni center, ki se nahaja v Rusiji. Interno razčlenimo podatke in jih zabeležimo v Clickhouse za kasnejšo vizualizacijo.

Torej, uredili smo arhitekturo - začnimo tresti Yandex.Cloud!

Pisanje vloge

Pred Cloudom je treba še malo potrpeti in napisati dokaj preprosto storitev za obdelavo prihajajočih dogodkov. Uporabili bomo golang, ker se je zelo izkazal kot jezik za pisanje omrežnih aplikacij.

Po porabi ene ure (morda nekaj ur) dobimo nekaj takega: https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/main.go.

Na katere glavne točke bi rad opozoril:

1. Ob zagonu aplikacije lahko določite dve zastavici. Eden je odgovoren za vrata, na katerih bomo poslušali dohodne http zahteve (-addr). Drugi je za naslov strežnika kafka, kjer bomo beležili naše dogodke (-kafka):

addr     = flag.String("addr", ":8080", "TCP address to listen to")
kafka    = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)

2. Aplikacija uporablja knjižnico sarama ([] github.com/Shopify/sarama) za pošiljanje sporočil v gručo kafka. Takoj nastavimo nastavitve za največjo hitrost obdelave:

config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true

3. Naša aplikacija ima vgrajen tudi odjemalec prometheus, ki zbira različne metrike, kot so:

  • število zahtev za našo aplikacijo;
  • število napak pri izvajanju zahteve (nemogoče prebrati post zahtevo, pokvarjen json, nemogoče pisati v Kafko);
  • čas obdelave ene zahteve naročnika, vključno s časom pisanja sporočila Kafki.

4. Tri končne točke, ki jih naša aplikacija obdeluje:

  • /status - preprosto vrne ok, da pokaže, da smo živi. Čeprav lahko dodate nekaj preverjanj, na primer razpoložljivost gruče Kafka.
  • /metrics - glede na ta url bo odjemalec prometheus vrnil metrike, ki jih je zbral.
  • /post je glavna končna točka, kamor bodo poslane zahteve POST z json. Naša aplikacija preveri veljavnost jsona in če je vse v redu, zapiše podatke v gručo Kafka.

Pridržal se bom, da koda ni popolna - jo je mogoče (in mora!) dokončati. Na primer, lahko prenehate uporabljati vgrajeni net/http in preklopite na hitrejši fasthttp. Ali pa lahko pridobite čas obdelave in vire procesorja tako, da premaknete preverjanje veljavnosti json na poznejšo stopnjo – ko se podatki prenesejo iz medpomnilnika v gručo clickhouse.

Poleg razvojne plati vprašanja smo takoj pomislili na našo prihodnjo infrastrukturo in se odločili, da bomo svojo aplikacijo uvedli prek dockerja. Končna datoteka Docker za izdelavo aplikacije je https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/Dockerfile. Na splošno je precej preprosto, edina točka, na katero bi rad pozoren, je večstopenjska montaža, ki nam omogoča, da zmanjšamo končno podobo naše posode.

Prvi koraki v oblaku

Najprej se registrirajte na cloud.yandex.ru. Ko izpolnimo vsa obvezna polja, nam bo ustvarjen račun in dodeljena dotacija za določeno vsoto denarja, ki jo lahko uporabimo za testiranje storitev v oblaku. Če želite ponoviti vse korake iz našega članka, vam bo ta nepovratna sredstva zadostovala.

Po registraciji se za vas ustvari ločen oblak in privzeti imenik, v katerem lahko začnete ustvarjati vire v oblaku. Na splošno je v Yandex.Cloudu razmerje virov videti takole:

V Yandex.Cloud sprejemamo 10 dogodkov. 000. del

Za en račun lahko ustvarite več oblakov. In znotraj oblaka ustvarite različne imenike za različne projekte podjetja. Več o tem si lahko preberete v dokumentaciji - https://cloud.yandex.ru/docs/resource-manager/concepts/resources-hierarchy. Mimogrede, nanj se bom pogosto skliceval spodaj v besedilu. Ko sem postavljal celotno infrastrukturo iz nič, mi je dokumentacija večkrat pomagala, zato vam svetujem, da jo preučite.

Za upravljanje oblaka lahko uporabite tako spletni vmesnik kot konzolni pripomoček - yc. Namestitev se izvede z enim ukazom (za Linux in Mac OS):

curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash

Če vaš strokovnjak za notranjo varnost besni zaradi izvajanja skriptov iz interneta, potem, prvič, lahko odprete skript in ga preberete, in drugič, izvajamo ga pod našim uporabnikom - brez korenskih pravic.

Če želite namestiti odjemalca za Windows, lahko uporabite navodila tukaj in nato izvedite yc initda ga popolnoma prilagodite:

vozerov@mba:~ $ yc init
Welcome! This command will take you through the configuration process.
Please go to https://oauth.yandex.ru/authorize?response_type=token&client_id= in order to obtain OAuth token.

Please enter OAuth token:
Please select cloud to use:
 [1] cloud-b1gv67ihgfu3bp (id = b1gv67ihgfu3bpt24o0q)
 [2] fevlake-cloud (id = b1g6bvup3toribomnh30)
Please enter your numeric choice: 2
Your current cloud has been set to 'fevlake-cloud' (id = b1g6bvup3toribomnh30).
Please choose folder to use:
 [1] default (id = b1g5r6h11knotfr8vjp7)
 [2] Create a new folder
Please enter your numeric choice: 1
Your current folder has been set to 'default' (id = b1g5r6h11knotfr8vjp7).
Do you want to configure a default Compute zone? [Y/n]
Which zone do you want to use as a profile default?
 [1] ru-central1-a
 [2] ru-central1-b
 [3] ru-central1-c
 [4] Don't set default zone
Please enter your numeric choice: 1
Your profile default Compute zone has been set to 'ru-central1-a'.
vozerov@mba:~ $

Načeloma je postopek preprost – najprej morate pridobiti oauth token za upravljanje oblaka, izbrati oblak in mapo, ki jo boste uporabljali.

Če imate več računov ali map v istem oblaku, lahko ustvarite dodatne profile z ločenimi nastavitvami prek yc config profile create in preklapljate med njimi.

Poleg zgornjih metod je ekipa Yandex.Cloud napisala zelo dobro vtičnik za terraform za upravljanje virov v oblaku. Sam sem pripravil git repozitorij, kjer sem opisal vse vire, ki bodo ustvarjeni v okviru članka - https://github.com/rebrainme/yandex-cloud-events/. Zanima nas glavna veja, klonirajmo jo lokalno:


vozerov@mba:~ $ git clone https://github.com/rebrainme/yandex-cloud-events/ events
Cloning into 'events'...
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (100/100), done.
remote: Compressing objects: 100% (68/68), done.
remote: Total 100 (delta 37), reused 89 (delta 26), pack-reused 0
Receiving objects: 100% (100/100), 25.65 KiB | 168.00 KiB/s, done.
Resolving deltas: 100% (37/37), done.
vozerov@mba:~ $ cd events/terraform/

Vse glavne spremenljivke, ki se uporabljajo v terraformu, so zapisane v datoteki main.tf. Za začetek ustvarite datoteko private.auto.tfvars v mapi terraform z naslednjo vsebino:

# 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 = ""

Vse spremenljivke lahko vzamete s seznama yc config, saj smo že konfigurirali pripomoček konzole. Svetujem vam, da private.auto.tfvars takoj dodate v .gitignore, da slučajno ne objavite zasebnih podatkov.

V private.auto.tfvars smo določili tudi podatke iz Cloudflare – za ustvarjanje zapisov DNS in proxy glavne domene events.kis.im do naših strežnikov. Če ne želite uporabljati cloudflare, odstranite inicializacijo ponudnika cloudflare v main.tf in datoteko dns.tf, ki je odgovorna za ustvarjanje potrebnih zapisov dns.

Pri našem delu bomo združili vse tri metode - spletni vmesnik, konzolni pripomoček in terraform.

Navidezna omrežja

Če sem iskren, bi lahko ta korak preskočili, saj boste, ko ustvarite nov oblak, samodejno ustvarili ločeno omrežje in 3 podomrežja – eno za vsako območje razpoložljivosti. A vseeno bi radi naredili ločeno omrežje za naš projekt z lastnim naslavljanjem. Splošni diagram delovanja omrežja v Yandex.Cloudu je prikazan na spodnji sliki (pošteno vzeto iz https://cloud.yandex.ru/docs/vpc/concepts/)

V Yandex.Cloud sprejemamo 10 dogodkov. 000. del

Torej ustvarite skupno omrežje, znotraj katerega lahko viri komunicirajo med seboj. Za vsako območje razpoložljivosti je ustvarjeno podomrežje z lastnim naslovom in povezano s splošnim omrežjem. Posledično lahko vsi viri oblaka v njem komunicirajo, tudi če so v različnih območjih razpoložljivosti. Viri, povezani v različna omrežja v oblaku, se lahko vidijo le prek zunanjih naslovov. Mimogrede, kako ta čarovnija deluje znotraj, je bil dobro opisan na Habréju.

Ustvarjanje omrežja je opisano v datoteki network.tf iz repozitorija. Tam ustvarimo eno skupno zasebno omrežje interno in vanj povežemo tri podomrežja v različnih območjih razpoložljivosti - interno-a (172.16.1.0/24), interno-b (172.16.2.0/24), interno-c (172.16.3.0/24). ).

Inicializirajte terraform in ustvarite omrežja:

vozerov@mba:~/events/terraform (master) $ terraform init
... skipped ..

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

... skipped ...

Plan: 4 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

yandex_vpc_network.internal: Creating...
yandex_vpc_network.internal: Creation complete after 3s [id=enp2g2rhile7gbqlbrkr]
yandex_vpc_subnet.internal-a: Creating...
yandex_vpc_subnet.internal-b: Creating...
yandex_vpc_subnet.internal-c: Creating...
yandex_vpc_subnet.internal-a: Creation complete after 6s [id=e9b1dad6mgoj2v4funog]
yandex_vpc_subnet.internal-b: Creation complete after 7s [id=e2liv5i4amu52p64ac9p]
yandex_vpc_subnet.internal-c: Still creating... [10s elapsed]
yandex_vpc_subnet.internal-c: Creation complete after 10s [id=b0c2qhsj2vranoc9vhcq]

Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

Super! Ustvarili smo naše omrežje in zdaj smo pripravljeni na ustvarjanje naših internih storitev.

Ustvarjanje virtualnih strojev

Za testiranje aplikacije bomo morali ustvariti le dva virtualna stroja – prvega bomo potrebovali za gradnjo in poganjanje aplikacije, drugega za poganjanje kafke, ki jo bomo uporabljali za shranjevanje dohodnih sporočil. In ustvarili bomo še en stroj, kjer bomo konfigurirali prometheus za spremljanje aplikacije.

Virtualni stroji bodo konfigurirani z uporabo ansible, zato se pred začetkom terraforma prepričajte, da imate eno od najnovejših različic ansible. In namestite potrebne vloge z ansible galaxy:

vozerov@mba:~/events/terraform (master) $ cd ../ansible/
vozerov@mba:~/events/ansible (master) $ ansible-galaxy install -r requirements.yml
- cloudalchemy-prometheus (master) is already installed, skipping.
- cloudalchemy-grafana (master) is already installed, skipping.
- sansible.kafka (master) is already installed, skipping.
- sansible.zookeeper (master) is already installed, skipping.
- geerlingguy.docker (master) is already installed, skipping.
vozerov@mba:~/events/ansible (master) $

Znotraj mape ansible je primer konfiguracijske datoteke .ansible.cfg, ki jo uporabljam. Morda pride prav.

Pred ustvarjanjem virtualnih strojev se prepričajte, da imate zagnan ssh-agent in dodan ssh ključ, sicer se terraform ne bo mogel povezati z ustvarjenimi stroji. Seveda sem naletel na napako v os x: https://github.com/ansible/ansible/issues/32499#issuecomment-341578864. Če želite preprečiti, da bi se to ponovilo, dodajte majhno spremenljivko v env, preden zaženete Terraform:

vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

V mapi s terraform ustvarimo potrebne vire:

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 ...

Če se je vse končalo uspešno (in bi moralo biti), bomo imeli tri virtualne stroje:

  1. build - stroj za testiranje in gradnjo aplikacije. Docker je samodejno namestil Ansible.
  2. monitoring - na njem nameščen nadzorni stroj - prometheus & grafana. Standardno prijavo / geslo: admin / admin
  3. kafka je majhen stroj z nameščeno kafko, dostopen na vratih 9092.

Prepričajmo se, da so vsi na svojem mestu:

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 |
+----------------------+------------+---------------+---------+---------------+-------------+

Viri so na voljo in od tu lahko dobimo njihove naslove IP. V nadaljevanju bom uporabljal naslove IP za povezovanje prek ssh in testiranje aplikacije. Če imate račun cloudflare povezan s terraformom, lahko uporabite sveže ustvarjena imena DNS.
Mimogrede, pri ustvarjanju navideznega stroja sta podana notranji IP in notranje ime DNS, tako da lahko do strežnikov v omrežju dostopate po imenu:

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 ms

To nam bo koristilo, da aplikaciji navedemo končno točko s kafk.

Sestavljanje aplikacije

Super, strežniki so, aplikacija je - ostalo je le še sestaviti in objaviti. Za gradnjo bomo uporabili običajno gradnjo dockerja, kot shrambo slik pa bomo uporabili storitev Yandex - register vsebnikov. Ampak najprej.

Aplikacijo skopiramo na gradbeni stroj, se prijavimo preko ssh in sestavimo sliko:

vozerov@mba:~/events/terraform (master) $ cd ..
vozerov@mba:~/events (master) $ rsync -av app/ [email protected]:app/

... skipped ...

sent 3849 bytes  received 70 bytes  7838.00 bytes/sec
total size is 3644  speedup is 0.93

vozerov@mba:~/events (master) $ ssh 84.201.132.3 -l ubuntu
ubuntu@build:~$ cd app
ubuntu@build:~/app$ sudo docker build -t app .
Sending build context to Docker daemon  6.144kB
Step 1/9 : FROM golang:latest AS build
... skipped ...

Successfully built 9760afd8ef65
Successfully tagged app:latest

Polovica bitke je narejena - zdaj lahko preverimo funkcionalnost naše aplikacije tako, da jo zaženemo in pošljemo kafki:

ubuntu@build:~/app$ sudo docker run --name app -d -p 8080:8080 app /app/app -kafka=kafka.ru-central1.internal:9092</code>

С локальной машинки можно отправить тестовый event и посмотреть на ответ:

<code>vozerov@mba:~/events (master) $ curl -D - -s -X POST -d '{"key1":"data1"}' http://84.201.132.3:8080/post
HTTP/1.1 200 OK
Content-Type: application/json
Date: Mon, 13 Apr 2020 13:53:54 GMT
Content-Length: 41

{"status":"ok","partition":0,"Offset":0}
vozerov@mba:~/events (master) $

Aplikacija se je odzvala z uspehom snemanja in navedbo ID-ja particije in odmika, v katerem je bilo sporočilo vključeno. Vse, kar morate storiti, je ustvariti register v Yandex.Cloud in tja naložiti našo sliko (kako to storiti s tremi vrsticami je opisano v datoteki registry.tf). Ustvarite shrambo:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_container_registry.events

... skipped ...

Plan: 1 to add, 0 to change, 0 to destroy.

... skipped ...

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Obstaja več načinov za preverjanje pristnosti v registru vsebnika – z uporabo žetona oauth, žetona iam ali ključa storitvenega računa. Več podrobnosti o teh metodah najdete v dokumentaciji. https://cloud.yandex.ru/docs/container-registry/operations/authentication. Uporabili bomo ključ storitvenega računa, zato ustvarimo račun:

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

... skipped ...

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Zdaj ostane le še narediti ključ zanj:

vozerov@mba:~/events/terraform (master) $ yc iam key create --service-account-name docker -o key.json
id: ajej8a06kdfbehbrh91p
service_account_id: ajep6d38k895srp9osij
created_at: "2020-04-13T14:00:30Z"
key_algorithm: RSA_2048

Prejmemo informacijo o ID-ju našega skladišča, prenesemo ključ in se prijavimo:

vozerov@mba:~/events/terraform (master) $ scp key.json [email protected]:
key.json                                                                                                                    100% 2392   215.1KB/s   00:00

vozerov@mba:~/events/terraform (master) $ ssh 84.201.132.3 -l ubuntu

ubuntu@build:~$ cat key.json | sudo docker login --username json_key --password-stdin cr.yandex
WARNING! Your password will be stored unencrypted in /home/ubuntu/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
ubuntu@build:~$

Za nalaganje slike v register potrebujemo ID registra vsebnika, vzamemo ga iz pripomočka yc:

vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"

Nato svojo sliko označimo z novim imenom in naložimo:

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: 946

Lahko preverimo, ali se je slika uspešno naložila:

vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
|          ID          |            NAME             |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+

Mimogrede, če namestite pripomoček yc na stroj Linux, lahko uporabite ukaz

yc container registry configure-docker

za konfiguracijo dockerja.

Zaključek

Opravili smo veliko trdega dela in kot rezultat:

  1. Prišli smo do arhitekture naše prihodnje storitve.
  2. Napisali smo aplikacijo v golangu, ki implementira našo poslovno logiko.
  3. Zbrali smo ga in zlili v zasebni register zabojnikov.

V naslednjem delu bomo prešli na zanimive stvari - našo aplikacijo bomo izdali v produkcijo in jo končno naložili. Ne menjaj!

To gradivo je v video posnetku odprte delavnice REBRAIN & Yandex.Cloud: V oblaku Yandex sprejmemo 10 zahtev na sekundo - https://youtu.be/cZLezUm0ekE

Če vas zanima udeležba na takšnih dogodkih prek spleta in postavljanje vprašanj v realnem času, se povežite z kanal DevOps podjetja REBRAIN.

Še posebej bi se radi zahvalili Yandex.Cloudu za priložnost gostiti tak dogodek. Povezava do njih - https://cloud.yandex.ru/prices

Če se morate preseliti v oblak ali imate vprašanja o vaši infrastrukturi, pustite prošnjo.

PS Imamo 2 brezplačni reviziji na mesec, morda bo vaš projekt ena izmed njih.

Vir: www.habr.com

Dodaj komentar