Võtame Yandex.Cloudis vastu 10 000 sündmust. 1. osa

Tere kõigile, sõbrad!

* See artikkel põhineb REBRAIN & Yandex.Cloud avatud töötoal, kui eelistate videot vaadata, leiate selle sellelt lingilt - https://youtu.be/cZLezUm0ekE

Meil oli hiljuti võimalus proovida Yandex.Cloudi otseülekandes. Kuna tahtsime pikalt ja kõvasti sondeerida, siis loobusime kohe mõttest käivitada lihtne Wordpressi ajaveebi koos pilvebaasiga – see oli liiga igav. Pärast mõningast mõtlemist otsustasime sündmuste peaaegu reaalajas vastuvõtmiseks ja analüüsimiseks juurutada midagi tootmisteenuse arhitektuuri sarnast.

Olen täiesti kindel, et valdav enamus veebiettevõtteid (ja mitte ainult) kogub oma kasutajate ja nende tegevuste kohta mingil moel mäetippu teavet. See on minimaalselt vajalik teatud otsuste tegemiseks – näiteks kui haldate mõnda võrgumängu, saate vaadata statistikat, millisel tasemel kasutajad kõige sagedamini jänni jäävad ja teie mänguasja kustutada. Või miks kasutajad lahkuvad teie saidilt midagi ostmata (tere, Yandex.Metrica).

Niisiis, meie lugu: kuidas me kirjutasime rakenduse golangis, testisime kafka vs rabbitmq vs yqs, kirjutasime andmete voogesituse Clickhouse klastris ja visualiseerisime andmeid yandexi andmeläätsede abil. Loomulikult maitsestati seda kõike infrastruktuurirõõmudega dockeri, terraformi, gitlab ci ja loomulikult prometheuse näol. Lähme!

Tahaksin kohe teha reservatsiooni, et me ei saa kõike ühe korraga konfigureerida - selleks vajame sarja mitut artiklit. Natuke struktuurist:

1. osa (loed seda). Otsustame lahenduse spetsifikatsioonide ja arhitektuuri üle ning kirjutame ka taotluse golangis.
2. osa. Anname oma rakenduse tootmisse, muudame selle skaleeritavaks ja testime koormust.
3. osa. Proovime välja mõelda, miks on vaja sõnumeid puhvrisse, mitte failidesse salvestada, ning võrrelda ka kafka, rabbitmq ja yandexi järjekorrateenust.
4. osa Juurutame Clickhouse'i klastri, kirjutame voogedastusteenuse sinna puhvrist andmete edastamiseks ja seadistame visualiseerimise andmeobjektiivis.
5. osa Viime kogu taristu õigesse vormi – seadistame ci/cd gitlab ci abil, ühendame jälgimise ja teenusetuvastuse prometheuse ja consuli abil.

TK

Esiteks sõnastame lähteülesande – mida me selle tulemusel täpselt tahame saada.

  1. Soovime lõpp-punkti, nagu events.kis.im (kis.im on testdomeen, mida kasutame kõigis artiklites), mis peaks HTTPS-i abil sündmusi vastu võtma.
  2. Sündmused on lihtsad json-vormingud, näiteks: {"event": "view", "os": "linux", "browser": "chrome"}. Viimases etapis lisame veidi rohkem väljasid, kuid see ei mängi suurt rolli. Soovi korral saate lülituda protobufile.
  3. Teenus peab suutma töödelda 10 000 sündmust sekundis.
  4. Peaks olema võimalik skaleerida horisontaalselt, lisades meie lahendusele lihtsalt uusi eksemplare. Ja oleks tore, kui saame esiosa liigutada erinevatesse geograafilistesse asukohtadesse, et vähendada klientide päringute latentsust.
  5. Veataluvus. Lahendus peab olema piisavalt stabiilne ja suutma üle elada mis tahes osade kukkumise (muidugi kuni teatud arvuni).

arhitektuur

Üldiselt on seda tüüpi ülesannete jaoks juba ammu leiutatud klassikalised arhitektuurid, mis võimaldavad tõhusat skaleerimist. Joonisel on näide meie lahendusest.

Võtame Yandex.Cloudis vastu 10 000 sündmust. 1. osa

Mis meil siis on:

1. Vasakul on meie seadmed, mis genereerivad erinevaid sündmusi, olgu selleks siis nutitelefonis mänguasjas taseme läbivad mängijad või tavalise brauseri kaudu veebipoes tellimuse koostamine. Spetsifikatsiooni kohaselt on sündmus lihtne json, mis saadetakse meie lõpp-punkti - events.kis.im.

2. Esimesed kaks serverit on lihtsad tasakaalustajad, nende peamised ülesanded on:

  • Olge pidevalt kättesaadav. Selleks saab kasutada näiteks keepalived’i, mis probleemide korral virtuaalset IP-d sõlmede vahel vahetab.
  • Lõpetage TLS. Jah, me lõpetame nende TLS-i. Esiteks selleks, et meie lahendus vastaks tehnilistele spetsifikatsioonidele ja teiseks, et vabastada meie taustaserveritest krüpteeritud ühenduse loomise koormus.
  • Tasakaalustage sissetulevad päringud saadaolevatele taustaserveritele. Võtmesõna on siin kättesaadav. Sellest lähtuvalt jõuame arusaamisele, et koormuse tasakaalustajad peavad suutma meie servereid rakendustega jälgida ja lõpetama liikluse tasakaalustamise ebaõnnestunud sõlmedele.

3. Peale tasakaalustajaid on meil rakendusserverid, mis töötavad üsna lihtsa rakendusega. See peaks suutma vastu võtta HTTP kaudu sissetulevaid päringuid, valideerida saadetud jsoni ja sisestada andmed puhvrisse.

4. Diagrammil on puhvrina kafka, kuigi loomulikult saab sellel tasemel kasutada ka muid sarnaseid teenuseid. Kolmandas artiklis võrdleme Kafkat, rabbitmq-d ja yq-sid.

5. Meie arhitektuuri eelviimane punkt on Clickhouse – veeruline andmebaas, mis võimaldab salvestada ja töödelda tohutul hulgal andmeid. Sellel tasemel peame andmed puhvrist salvestussüsteemi endasse üle kandma (selle kohta lähemalt artiklis 4).

See disain võimaldab meil iga kihti iseseisvalt horisontaalselt skaleerida. Taustaserverid ei saa hakkama – lisame veel ühe asja – lõppude lõpuks on need olekuta rakendused ja seetõttu saab seda teha isegi automaatselt. Kafka-stiilis puhver ei tööta – lisame rohkem servereid ja teisaldame neile mõned meie teema partitsioonid. Clickhouse ei saa sellega hakkama – see on võimatu :) Tegelikult ühendame ka serverid ja killustame andmed.

Muide, kui soovite rakendada meie tehniliste kirjelduste ja skaala valikulist osa erinevates geograafilistes asukohtades, siis pole midagi lihtsamat:

Võtame Yandex.Cloudis vastu 10 000 sündmust. 1. osa

Igas geograafilises asukohas kasutame koormuse tasakaalustajat koos rakenduse ja kafkaga. Üldiselt piisab 2 rakenduseserverist, 3 kafka sõlmest ja pilve tasakaalustajast, näiteks cloudflare'ist, mis kontrollib rakenduse sõlmede saadavust ja tasakaalustab päringuid geograafilise asukoha järgi kliendi lähte IP-aadressi alusel. Seega jõuavad Ameerika kliendi saadetud andmed Ameerika serveritesse. Ja Aafrika andmed on Aafrika andmed.

Siis on kõik üsna lihtne – kasutame Kafka komplekti kuuluvat peegeltööriista ja kopeerime kõik andmed kõikidest asukohtadest meie Venemaal asuvasse kesksesse andmekeskusesse. Sisemiselt sõelume andmed ja salvestame need Clickhouse'i hilisemaks visualiseerimiseks.

Niisiis, lahendasime arhitektuuri – alustame Yandex.Cloudi raputamist!

Avalduse kirjutamine

Enne Pilve tuleb veel veidi kannatlik olla ja sissetulevate sündmuste töötlemiseks üsna lihtne teenus kirjutada. Kasutame golangi, sest see on end võrgurakenduste kirjutamise keelena väga hästi tõestanud.

Pärast tunni (võib-olla paari tunni) veetmist saame midagi sellist: https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/main.go.

Millised on peamised punktid, mida tahaksin siinkohal märkida:

1. Rakenduse käivitamisel saate määrata kaks lippu. Üks vastutab pordi eest, mille kaudu me sissetulevaid http-päringuid kuulame (-addr). Teine on kafka serveri aadress, kuhu me oma sündmusi salvestame (-kafka):

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

2. Rakendus kasutab sarama raamatukogu ([] github.com/Shopify/sarama), et saata sõnumeid kafka klastrisse. Seadsime kohe maksimaalsele töötlemiskiirusele suunatud sätted:

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

3. Meie rakendusel on ka sisseehitatud prometheuse klient, mis kogub erinevaid mõõdikuid, näiteks:

  • meie rakendusele esitatud taotluste arv;
  • päringu täitmisel esinevate vigade arv (postitustaotlust ei saa lugeda, json on katki, Kafkale pole võimalik kirjutada);
  • ühe kliendi päringu töötlemise aeg, sealhulgas Kafkale sõnumi kirjutamise aeg.

4. Kolm lõpp-punkti, mida meie rakendus töötleb:

  • /status – naaske lihtsalt OK, et näidata, et oleme elus. Kuigi saate lisada mõningaid kontrolle, näiteks Kafka klastri saadavust.
  • /metrics – selle URL-i järgi tagastab prometheuse klient kogutud mõõdikud.
  • /post on peamine lõpp-punkt, kuhu saadetakse POST-päringud, mille sees on json. Meie rakendus kontrollib jsoni kehtivust ja kui kõik on korras, kirjutab see andmed Kafka klastrisse.

Teen reservatsiooni, et kood pole täiuslik – seda saab (ja peaks!) täiendama. Näiteks võite lõpetada sisseehitatud net/http kasutamise ja lülituda kiiremale fasthttp-le. Või saate töötlemisaega ja protsessoriressursse suurendada, kui teisaldate json-i kehtivuse kontrolli hilisemasse etappi – kui andmed kantakse puhvrist Clickhouse-klastrisse.

Lisaks probleemi arenduspoolele mõtlesime kohe ka oma tulevasele infrastruktuurile ja otsustasime oma rakenduse juurutada dokkeri kaudu. Viimane Dockeri fail rakenduse koostamiseks on https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/Dockerfile. Üldiselt on see üsna lihtne, ainus punkt, millele tahaksin tähelepanu pöörata, on mitmeastmeline kokkupanek, mis võimaldab meil oma konteineri lõplikku pilti vähendada.

Esimesed sammud pilves

Kõigepealt registreeruge cloud.yandex.ru. Pärast kõigi vajalike väljade täitmist luuakse meile konto ja antakse teatud rahasumma eest toetus, millega saab pilveteenuseid testida. Kui soovite korrata kõiki meie artikli samme, peaks sellest toetusest teile piisama.

Peale registreerimist luuakse Sinu jaoks eraldi pilv ja vaikimisi kataloog, milles saad alustada pilveressursside loomisega. Üldiselt näeb Yandex.Cloudis ressursside suhe välja selline:

Võtame Yandex.Cloudis vastu 10 000 sündmust. 1. osa

Ühe konto jaoks saate luua mitu pilve. Ja pilve sees tehke erinevate ettevõtte projektide jaoks erinevaid katalooge. Selle kohta saate rohkem lugeda dokumentatsioonist - https://cloud.yandex.ru/docs/resource-manager/concepts/resources-hierarchy. Muide, ma viitan sellele sageli allpool tekstis. Kui ma kogu infrastruktuuri nullist üles seadsin, aitas dokumentatsioon mind mitu korda välja, seega soovitan teil seda uurida.

Pilve haldamiseks saab kasutada nii veebiliidest kui ka konsooli utiliiti – yc. Installimine toimub ühe käsuga (Linux ja Mac OS jaoks):

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

Kui teie siseturvalisuse spetsialist märatseb Internetist skriptide käivitamise pärast, saate esiteks skripti avada ja seda lugeda ning teiseks käivitame selle oma kasutaja all - ilma juurõigusteta.

Kui soovite installida Windowsi kliendi, võite kasutada juhiseid siin ja seejärel teostada yc initselle täielikuks kohandamiseks:

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:~ $

Põhimõtteliselt on protsess lihtne – esmalt tuleb hankida pilve haldamiseks oauth token, valida pilv ja kaust, mida kasutada.

Kui teil on samas pilves mitu kontot või kausta, saate yc konfiguratsiooniprofiili loomise ja nende vahel vahetamise kaudu luua eraldi seadetega täiendavaid profiile.

Lisaks ülaltoodud meetoditele kirjutas Yandex.Cloudi meeskond väga hea terraformi pistikprogramm pilveressursside haldamiseks. Omalt poolt valmistasin ette git-hoidla, kus kirjeldasin kõiki artikli osana loovaid ressursse - https://github.com/rebrainme/yandex-cloud-events/. Oleme huvitatud põhiharust, kloonime selle kohapeal:


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/

Kõik peamised terraformis kasutatavad muutujad on kirjutatud main.tf faili. Alustamiseks looge terraformi kaustas järgmise sisuga fail private.auto.tfvars:

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

Kõik muutujad saab võtta yc konfiguratsiooniloendist, kuna oleme konsooli utiliidi juba konfigureerinud. Soovitan kohe lisada faili private.auto.tfvars kausta .gitignore, et mitte kogemata privaatseid andmeid avaldada.

Aadressil private.auto.tfvars täpsustasime ka Cloudflare'i andmed – DNS-kirjete loomiseks ja põhidomeeni events.kis.im puhverserveriks meie serveritesse. Kui te ei soovi cloudflare'i kasutada, siis eemaldage main.tf-s cloudflare'i pakkuja lähtestamine ja fail dns.tf, mis vastutab vajalike dns-kirjete loomise eest.

Oma töös ühendame kõik kolm meetodit – veebiliidese, konsooli utiliidi ja terraformi.

Virtuaalsed võrgud

Ausalt öeldes võite selle sammu vahele jätta, kuna uue pilve loomisel luuakse automaatselt eraldi võrk ja 3 alamvõrku – üks iga saadavustsooni jaoks. Kuid ikkagi tahaksime oma projekti jaoks teha eraldi võrgu, millel on oma aadress. Võrgu toimimise üldskeem Yandex.Cloudis on näidatud alloleval joonisel (ausalt võetud https://cloud.yandex.ru/docs/vpc/concepts/)

Võtame Yandex.Cloudis vastu 10 000 sündmust. 1. osa

Seega loote ühise võrgustiku, milles ressursid saavad üksteisega suhelda. Iga saadavuse tsooni jaoks luuakse oma aadressiga alamvõrk ja ühendatakse see üldvõrguga. Selle tulemusena saavad kõik selles olevad pilveressursid suhelda, isegi kui need asuvad erinevates saadavustsoonides. Erinevate pilvevõrkudega ühendatud ressursid näevad üksteist ainult väliste aadresside kaudu. Muide, kuidas see maagia sees töötab, oli Habrel hästi kirjeldatud.

Võrgu loomist kirjeldatakse hoidlast võrgu.tf failis. Seal loome ühe ühise sisemise privaatvõrgu ja ühendame sellega kolm alamvõrku erinevates kättesaadavustsoonides - sisemine-a (172.16.1.0/24), sisemine-b (172.16.2.0/24), sisemine-c (172.16.3.0/24). ).

Terraformi lähtestamine ja võrkude loomine:

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.

Suurepärane! Oleme loonud oma võrgustiku ja oleme nüüd valmis looma siseteenuseid.

Virtuaalsete masinate loomine

Rakenduse testimiseks peame looma vaid kaks virtuaalmasinat – esimest vajame rakenduse ehitamiseks ja käitamiseks, teist kafka käivitamiseks, mida kasutame sissetulevate sõnumite salvestamiseks. Ja me loome teise masina, kus konfigureerime prometheuse rakenduse jälgimiseks.

Virtuaalsed masinad konfigureeritakse ansible abil, nii et enne terraformi käivitamist veenduge, et teil oleks üks ansible uusimatest versioonidest. Ja installige ansible galaxy abil vajalikud rollid:

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) $

Ansible kaustas on konfiguratsioonifaili .ansible.cfg näide, mida ma kasutan. See võib kasuks tulla.

Enne virtuaalmasinate loomist veenduge, et ssh-agent töötab ja ssh-võti on lisatud, vastasel juhul ei saa terraform loodud masinatega ühendust. Muidugi avastasin os x-i vea: https://github.com/ansible/ansible/issues/32499#issuecomment-341578864. Selle kordumise vältimiseks lisage enne Terraformi käivitamist env-le väike muutuja:

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

Terraformiga kaustas loome vajalikud ressursid:

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

Kui kõik lõppes edukalt (ja peaks olema), on meil kolm virtuaalset masinat:

  1. build – masin rakenduse testimiseks ja ehitamiseks. Ansible installis Dockeri automaatselt.
  2. monitooring - jälgimismasin - sellele paigaldatud prometheus & grafana. Sisselogimise / parooli standard: admin / admin
  3. kafka on väike masin, kuhu on paigaldatud kafka ja millele pääseb juurde pordist 9092.

Veenduge, et need kõik oleksid paigas:

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

Ressursid on paigas ja siit saame nende IP-aadressid kätte. Alljärgnevas kasutan ssh kaudu ühenduse loomiseks ja rakenduse testimiseks IP-aadresse. Kui teil on terraformiga ühendatud cloudflare'i konto, kasutage värskelt loodud DNS-i nimesid.
Muide, virtuaalse masina loomisel antakse sisemine IP ja sisemine DNS-nimi, nii et pääsete võrgus olevatele serveritele juurde nime järgi:

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

See on meile kasulik, kui näitame rakendusele lõpp-punkti kafk-iga.

Rakenduse kokkupanek

Suurepärane, serverid on olemas, rakendus on olemas – jääb üle vaid see kokku panna ja avaldada. Ehitamiseks kasutame tavalist dokkeri ehitamist, kuid pildisalvestusena kasutame Yandexi - konteinerregistri teenust. Aga kõigepealt asjad kõigepealt.

Kopeerime rakenduse ehitusmasinasse, logime ssh kaudu sisse ja paneme pildi kokku:

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

Pool võitlust on tehtud – nüüd saame oma rakenduse funktsionaalsust kontrollida, käivitades selle ja saates selle kafkale:

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) $

Rakendus vastas edukalt salvestades ja märkides partitsiooni ID ja nihke, kuhu sõnum kuulus. Jääb üle vaid Yandex.Cloudis register luua ja sinna meie pilt üles laadida (kuidas seda kolme rea abil teha, kirjeldatakse registry.tf failis). Looge salvestusruum:

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.

Konteinerregistris on autentimiseks mitu võimalust – kasutades oauth-luba, iam-luba või teenusekonto võtit. Lisateavet nende meetodite kohta leiate dokumentatsioonist. https://cloud.yandex.ru/docs/container-registry/operations/authentication. Kasutame teenusekonto võtit, seega loome konto:

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.

Nüüd jääb üle vaid teha sellele võti:

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

Saame teabe oma salvestusruumi ID kohta, edastame võtme ja logime sisse:

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:~$

Pildi registrisse üleslaadimiseks vajame konteineri registri ID-d, võtame selle yc utiliidist:

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

Pärast seda märgistame oma pildi uue nimega ja laadime üles:

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

Saame kontrollida, kas pildi laadimine õnnestus:

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

Muide, kui installite yc utiliidi Linuxi masinasse, saate kasutada käsku

yc container registry configure-docker

dokkeri konfigureerimiseks.

Järeldus

Oleme teinud palju rasket tööd ja selle tulemusel:

  1. Mõtlesime välja oma tulevase teenuse arhitektuuri.
  2. Kirjutasime golangi keeles rakenduse, mis rakendab meie äriloogikat.
  3. Kogusime selle kokku ja valasime erakonteinerite registrisse.

Järgmises osas liigume edasi huvitavate asjade juurde – laseme oma rakenduse tootmisse ja lõpuks käivitame selle laadimise. Ära vaheta!

See materjal on avatud töötoa REBRAIN & Yandex.Cloud videosalvestisel: Yandex Cloudis võtame vastu 10 000 päringut sekundis - https://youtu.be/cZLezUm0ekE

Kui olete huvitatud sellistel üritustel veebis osalemisest ja reaalajas küsimusi esitamisest, võtke ühendust DevOps by REBRAIN kanal.

Erilist tänu tahaksime öelda Yandex.Cloudile võimaluse eest sellist üritust korraldada. Link neile - https://cloud.yandex.ru/prices

Kui teil on vaja pilve üle minna või teil on oma infrastruktuuri kohta küsimusi, Esitage taotlus julgelt.

PS Meil ​​on 2 tasuta auditit kuus, võib-olla on teie projekt üks neist.

Allikas: www.habr.com

Lisa kommentaar