Tere kõigile, sõbrad!
* See artikkel on kirjutatud avatud praktikumist REBRAIN & Yandex.Cloud; kui teile meeldib rohkem video vaadata, leiate selle siit —
Hiljuti tekkis meil võimalus käega katsuda Yandex.Cloud'i. Kuna tahtsime seda põhjalikult uurida, loobusime kohe idee järgi käivitada lihtsat WordPressi blogi pilves — see oleks liiga igav. Pärast lühikest mõtlemist otsustasime käivitada midagi, mis meenutab tootmisarhitektuuri teenusele sündmuste vastuvõtmiseks ja analüüsimiseks peaaegu reaalajas.
Olen täiesti kindel, et üliühel enamik veebis (ja mitte ainult) ettevõtteid kogub paratamatult tohutul hulgal teavet oma kasutajate ja nende tegevuste kohta. See on vajalik vähemalt mõningate otsuste tegemiseks — näiteks, kui haldad veebimängu, saad vaadata statistikat, millisel tasemel kasutajad kõige sagedamini kinni jäävad ja sinu mängu kustutavad. Või miks kasutajad lahkuvad sinu veebisaidilt, nii ka mitte midagi ostmata (tere, Yandex.Metrica).
Nii et meie lugu: kuidas me kirjutasime rakenduse golangis, testisime kafka vs rabbitmq vs yqs, kirjutasime andmevoogude striimingut Clickhouse'i klastrisse ja visualiseerisime andmeid Yandex.Datalens'i abil. Loomulikult oli see kõik maitsestatud infrastruktuuriliste valikute, nagu docker, terraform, gitlab ci ja loomulikult prometheus, abil. Lähme!
Tahaksin kohe mainida, et me ei saa kõike ühe korra ära seadistada — selleks on meil vaja mitmeid artikleid. Veidi struktuurist:
1. osa (sa loed seda). Me määratleme TEx ja lahenduse arhitektuuri ning kirjutame rakenduse golangis.
2. osa. Toome meie rakenduse tootmisse, teeme selle skaleeritavaks ja testime koormust.
3. osa. Proovime välja selgitada, miks peame sõnumeid hoidma vahemikus, mitte failides, ning võrreldame kafka, rabbitmq ja Yandex Queue Service'i.
4. osa. Et hakkame seadistama Clickhouse'i klastrit, kirjutame andmevoo, et sinna andmeid vahemikust üle viia, ja seadistame visualiseerimise Datalens'is.
5. osa. Viime kogu infrastruktuuri korda — seadistame ci/cd, kasutades gitlab ci, ühendame jälgimise ja teenuste avastamise Prometheuse ja Consuliga.
TEx
Esiteks sõnastame tehnilise ülesande — mida täpselt soovime tulemuseks saada.
- Me soovime, et meil oleks endpoint, mis näeb välja nagu events.kis.im (kis.im on testdomeen, mida kasutame kõikide artiklite jooksul), mis peab saama event'e HTTPS-i kaudu.
- Sündmused on lihtne JSON-i struktuur: {"event": "view", "os": "linux", "browser": "chrome"}. Lõppstaadiumis lisame veidi rohkem välju, kuid see ei mängi suurt rolli. Kui soovite, saate minna üle protobuf'i peale.
- Teenusel peab olema võimalus töödelda 10 000 sündmust sekundis.
- Peab olema võimalik horisontaalselt skaleerida – lihtsalt lisades uusi instantsse meie lahendusele. Ja oleks tore, kui saaksime viia esiosade eri geolokatsioonidesse, et vähendada klientide päringute latentsust.
- Vea taluvus. Lahendus peab olema piisavalt stabiilne ja suudma ellu jääda, kui mis tahes osa langeb (loomulikult teatud piirini).
Arhitektuur
Tegelikult on selliste ülesannete jaoks juba ammu välja mõeldud klassikalised arhitektuurid, mis võimaldavad tõhusalt skaleerida. Joonisel on toodud näide meie lahendusest.
Nii et, mis meil on:
1. Vasakul on meie seadmed, mis genereerivad erinevaid sündmusi, olgu need mängijate taseme ületamised nutitelefonimängus või tellimuse loomine veebipoes tavalise brauseri kaudu. Sündmus, nagu on märgitud ülesandes, on lihtne JSON, mis saadetakse meie endpoint'ile — events.kis.im.
2. Esimesed kaks serverit on lihtsad koormuse tasakaalustajad, nende peamised ülesanded:
- Olla pidevalt kergesti kättesaadavad. Selle tagamiseks saab kasutada näiteks keepalived'i, mis lülitab virtuaalse IP-aadressi sõlmede vahel probleemide korral.
- TLS-i lõpetamine. Jah, me lõpetame TLS-i just nendel serveritel. Esiteks, et meie lahendus vastaks ülesande nõudmistele, ja teiseks, et vähendada šifreeritud ühenduse loomise koormust meie taustateenuste serveritelt.
- Tasakaalustada sissetulevaid päringuid kergesti kätte saadavatele taustateenuste serveritele. Siin on võtmesõna — kergesti kätte saadavad. Selle põhjal mõistame, et koormuse tasakaalustajad peavad suutma jälgida meie rakendusega servereid ja lõpetama liikluse tasakaalu langemine ebaõnnestunud sõlmedele.
3. Koormuse tasakaalustajate taga meil on rakenduse serverid, millel on käivitatud üsna lihtne rakendus. See peab suutma vastu võtta sissetulevaid päringuid HTTP kaudu, valideerima saadetud JSON-i ja salvestama andmed vahemälu.
4. Scheemal on pufferina kujutatud kafka, kuigi loomulikult on sellel tasemel võimalik kasutada ka teisi sarnaseid teenuseid. Kafka, rabbitmq ja yqs võrdleme kolmandas artiklis.
5. Meie arhitektuuri eelviimane punkt on Clickhouse — veergude andmebaas, mis võimaldab salvestada ja töödelda tohutuid andmemahtusid. Sel tasandil peame andmed puffrist tegelikult andmesüsteemi viima (sellest räägitakse 4. artiklis).
Selline skeem võimaldab meil igat kihti sõltumatult horisontaalselt skaleerida. Kui backend-serverid ei suuda hakkama saada — lisame juurde, kuna need on stateless rakendused, mida saab isegi automaatselt teha. Kui kafka puffer ei suuda hakkama saada — lisame veel servereid ja kanname osa meie teema partitsioonidest neile üle. Kui clickhouse ei suuda hakkama saada — see ei ole võimalik 🙂 Tegelikult lisame ka servereid ja jaotame andmed shardideks.
Muide, kui soovite ellu viia meie tehniliste nõuete valikuliselt ja teha skaleerimist erinevates geolokatsioonides, pole midagi lihtsamat:
Igas geolokatsioonis seadistame load balancer'i koos rakenduse ja kafka'ga. Üldiselt piisab kahest rakenduse serverist, kolmest kafka nodest ja pilve tasakaalustajast, näiteks cloudflare, mis kontrollib rakenduse nodede kättesaadavust ja tasakaalustab päringuid geolokatsioonide põhjal lähtuva kliendi IP-aadressi alusel. Seega, andmed, mis on saadetud Ameerika kliendilt, jõuavad Ameerika serveritesse. Ja Aafrikast saadetud andmed — Aafrika serveritesse.
Edasi on kõik väga lihtne — kasutame kafka komplekti peeglitööriista ja kopeerime kõik andmed kõikidest asukohtadest meie kesksesse andmekeskusesse Venemaal. Sees me töötleme andmeid ja salvestame need Clickhouse'i hilisemaks visualiseerimiseks.
Nii et arhitektuuriga saime hakkama — alustame Yandex.Cloudi raputamist!
Kirjutame rakenduse
Pilve jaoks tuleb veel natuke oodata ja kirjutada piisavalt lihtne teenus sissetulevate sündmuste töötlemiseks. Kasutame go lang'i, kuna see on väga hästi tõestanud end võrgurakenduste kirjutamise keeles.
Veidi aega kulutades (võib-olla paar tundi) saame enam-vähem sellise asja: .
Millised peamised punktid siin tähele panna?
1. Rakenduse käivitamisel saab määrata kaks lippu. Üks neist määrab pordi, millel kuulame sissetulevaid http päringuid (-addr). Teine - kafka serveri aadress, kuhu salvestame meie sündmused (-kafka):
addr = flag.String("addr", ":8080", "TCP aadress, mida kuulata")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka lõpp-punktid")2. Rakendus kasutab raamatukogu sarama () sõnumite saatmiseks kafka klastrisse. Oleme kohe seadnud seadistused, mis on suunatud maksimaalse töötlemise kiiruseni:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Meie rakendusse on integreeritud ka prometheuse klient, mis kogub erinevaid mõõdikuid, nagu:
- päringute arv meie rakendusele;
- vea arv päringu täitmise ajal (ei suudeta lugeda post päringut, vigane json, ei suudeta kirjutada kafkasse);
- ühe kliendi päringu töötlemise aeg, sealhulgas sõnumi kirjutamise aeg kafkasse.
4. Kolm lõpp-punkti, mida meie rakendus käsitleb:
- /status — просто возвращаем ok, чтобы показать, что мы живы. Хотя можно и добавить некоторые проверки, типа доступности кафка кластера.
- /metrics — по этому url prometheus client будет возвращать собранные им метрики.
- /post — основной endpoint, куда будут приходить POST запросы с json внутри. Наше приложение проверяет json на валидность и если все ок — записывает данные в кафка-кластер.
Tahan märkida, et kood ei ole ideaalne - seda saab (ja tuleb!) täiustada. Näiteks saab loobuda sisseehitatud net/http kasutamisest ja minna üle kiiremale fasthttp-ile. Või võita töötlemisaega ja CPU ressursse, viies jsoni valideerimise kontrolli hilisemasse etappi, kui andmed kantakse mälu kihtide vaheline klikkhausi klastrisse.
Lisaks arenduslikule poolele mõtlesime kohe meie tulevasele infrastruktuurile ja otsustasime kasutada meie rakenduse käitamiseks dockerit. Lõplik Dockerfile rakenduse ehitamiseks - . Üldiselt on see piisavalt lihtne, ainus punkt, millele tahaks tähelepanu juhtida, on multistage ehitus, mis võimaldab vähendada meie konteineri lõplikku mahtu.
Esimesed sammud pilves
Esmalt registreerime end . Pärast kõigi vajalike väljade täitmist luuakse meile konto ja antakse grant teatud rahasummale, mida saab kasutada pilveteenuste testimiseks. Kui soovite meie artiklis kirjeldatud samme korrata, peaks see grant olema piisav.
Pärast registreerimist luuakse teile eraldi pilv ja kataloog default, kus saate alustada pilveressursside loomist. Üldiselt näeb Yandex.Cloudis ressursside omavaheline seos välja järgmine:
Ühe konto alla saate luua mitu pilve. Ja pilve sees saate teha erinevaid katalooge erinevate ettevõtte projektide jaoks. Rohkem teavet selle kohta leiate dokumentatsioonist — . Üksikasjaliku teabe puhul viitan sellele tekstile sageli. Kui ma seadistin kogu infrastruktuuri nullist, tuli dokumentatsioon mulle korduvalt appi, seega soovitan seda tutvuda.
Pilve haldamiseks saab kasutada nii veebiliidest kui ka käsurea tööriista — yc. Paigaldamine toimub ühe käsuga (Linuxi ja Mac OS-i jaoks):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashKui teie sees on askeldav sisemine turvatöötaja, kes on mures Interneti-skriptide käivitamise pärast, siis esiteks, saate skripti avada ja lugeda seda ning teiseks, käivitame selle oma kasutajana — ilma juurõigusteta.
Kui soovite Windows jaoks kliendi installida, siis võite kasutada juhendit ja seejärel täita yc init, et täielikult seda seadistada:
vozerov@mba:~ $ yc init
Tere tulemast! See käsk viib teid konfiguratsiooni protsessist läbi.
Palun minge https://oauth.yandex.ru/authorize?response_type=token&client_id= aadressile, et saada OAuth token.
Palun sisestage OAuth token:
Palun valige kasutamiseks pilv:
[1] cloud-b1gv67ihgfu3bp (id = b1gv67ihgfu3bpt24o0q)
[2] fevlake-cloud (id = b1g6bvup3toribomnh30)
Palun sisestage oma numbriline valik: 2
Teie praegune pilv on seadistatud 'fevlake-cloud' (id = b1g6bvup3toribomnh30).
Palun valige kasutatav kaust:
[1] default (id = b1g5r6h11knotfr8vjp7)
[2] Looge uus kaust
Palun sisestage oma numbriline valik: 1
Teie praegune kaust on seadistatud 'default' (id = b1g5r6h11knotfr8vjp7).
Kas soovite seadistada vaikimisi arvutusala? [Y/n]
Millist ala soovite kasutada profiili vaikimisi?
[1] ru-central1-a
[2] ru-central1-b
[3] ru-central1-c
[4] Ärge seadistage vaikimisi ala
Palun sisestage oma numbriline valik: 1
Teie profiili vaikimisi arvutusala on seadistatud 'ru-central1-a'.
vozerov@mba:~ $Põhimõtteliselt on protsess lihtne — kõigepealt tuleb saada oauth token pilve haldamiseks, valida pilv ja kaust, mida kavatsete kasutada.
Kui teil on mitu kontot või kausta ühes pilves, võite luua täiendavaid profiile eraldi seadistustega käsu yc config profile create kaudu ja vahetada nende vahel.
Lisaks eespool nimetatud viisidele on Yandex.Cloudi meeskond kirjutanud väga hea pilve ressursside haldamiseks. Minu poolt olen valmistanud git-repositooriumi, kus olen kirjeldanud kõiki ressursse, mis artikli raames loodakse — . Meid huvitab haru master, kloonime selle endale kohalikult:
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 põhivaraablid, mida kasutatakse terraformis, on määratud failis main.tf. Alustamiseks looge kataloogis terraform fail private.auto.tfvars järgmise sisuga:
# 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 on saadaval yc config list, kuna oleme juba konsooli utiliiti seadistanud. Soovitan kohe lisada private.auto.tfvars .gitignore faili, et kogemata mitte avaldada privaatandmeid.
Failis private.auto.tfvars oleme samuti määranud Cloudflare’i andmed — dns-kirjete loomise ja põhiteenuse domeeni events.kis.im suunamise jaoks meie serveritele. Kui te ei soovi Cloudflare’i kasutada, eemaldage main.tf failist ja dns.tf failist, mis vastutab vajalike dns-kirjete loomise eest, Cloudflare’i pakkuja initsiatsioon.
Oleme oma töös kombinatsioonis kasutama kõiki kolme meetodit — nii veebiliidest, konsooli utiliiti kui ka terraformi.
Virtuaalsed võrgud
Ausalt öeldes oleks selle sammu võinud vahele jätta, kuna uue pilve loomisel luuakse automaatselt eraldi võrk ja 3 alamvõrku — igaühele iga kättesaadavuse tsooni kohta. Kuid siiski sooviksime luua meie projekti jaoks eraldi võrgustiku oma aadressiga. Yandex.Cloudi võrgustiku üldine tööplaan on esitatud alloleval joonisel (ausalt öeldud, võetud )
Nii et loote üldvõrgu, mille sees ressursid saavad omavahel suhelda. Iga kättesaadavuse tsooni jaoks luuakse alamvõrk oma aadressiga ja see ühendatakse üldvõrguga. Seetõttu saavad kõik pilveressursid selles omavahel suhelda, isegi kui nad asuvad erinevates kättesaadavuse tsoonides. Ressursid, mis on ühendatud erinevatesse pilvevõrkudesse, saavad üksteist näha ainult väliste aadresside kaudu. Muide, kuidas see maagia töötab sees, .
Võrgu loomine on kirjeldatud faili network.tf, mis asub repozitooriumis. Seal loome ühe ühise privaatvõrgu internal ja ühendame selle kolme alamvõrguga erinevates kättesaadavuse tsoonides — internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24).
Initsialiseerime terraformi ja loome võrgud:
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 ...
Plaan: 4 lisatakse, 0 muudetakse, 0 hävitatakse.
Kas soovite neid toiminguid teostada?
Terraform viib läbi eespool kirjeldatud toimingud.
Ainult 'jah' võetakse heakskiiduks.
Sisestage väärtus: jah
yandex_vpc_network.internal: Loomine...
yandex_vpc_network.internal: Loomine lõpetatud 3s pärast [id=enp2g2rhile7gbqlbrkr]
yandex_vpc_subnet.internal-a: Loomine...
yandex_vpc_subnet.internal-b: Loomine...
yandex_vpc_subnet.internal-c: Loomine...
yandex_vpc_subnet.internal-a: Loomine lõpetatud 6s pärast [id=e9b1dad6mgoj2v4funog]
yandex_vpc_subnet.internal-b: Loomine lõpetatud 7s pärast [id=e2liv5i4amu52p64ac9p]
yandex_vpc_subnet.internal-c: Veel loomas... [10s möödunud]
yandex_vpc_subnet.internal-c: Loomine lõpetatud 10s pärast [id=b0c2qhsj2vranoc9vhcq]
Kohandamine lõpetatud! Ressursid: 4 lisatud, 0 muudetud, 0 hävitatud.Suurepärane! Me oleme oma võrgu teinud ja nüüd oleme valmis looma meie siseteenuseid.
Virtuaalmasinate loomine
Rakenduse testimiseks piisab, kui luua kaks virtuaalmasinat — esimene on vajalik rakenduse koostamiseks ja käitamiseks, teine — kafka käitamiseks, mida kasutame sissetulevate sõnumite salvestamiseks. Loome veel ühe masina, kuhu seadistame prometheuse rakenduse jälgimiseks.
Virtuaalmasinad seadistatakse ansible'i abil, nii et enne terraform'i käivitamist veenduge, et teil on üks viimane versioon ansiblist. Ja installige vajalikud rollid ansible galaxy's:
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'i kaustas on näidis konfiguratsioonifail .ansible.cfg, mida mina kasutan. See võib olla kasulik.
Enne virtuaalmasinate loomist veenduge, et ssh-agent on käivitatud ja ssh võti on lisatud, muidu ei saa terraform loodud masinatele ühendust luua. Ma sattusin OS X-s viga: . Et teil selline lugu ei korduks, lisage enne Terraform'i käivitamist väike muutuja keskkonda:
vozerov@mba:~\/events\/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESTerraform'i 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äks hästi (nagu see peaks olema), siis on meil kolm virtuaalmasinat:
- build — rakenduse testimise ja kokkupanemise masin. Docker on automaatselt paigaldatud ansible’i kaudu.
- monitoring — jälgimise masin — sellele on paigaldatud prometheus & grafana. Logi sisse / parool on standardsed: admin / admin.
- kafka — väike masin, millel on paigaldatud kafka, saadaval porti 9092 kaudu.
Veendume, et kõik on kohal:
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 kohal ja sealt saame nende ip-aadressid välja võtta. Jätkuvalt kasutan kõikjal ip-aadresse ssh kaudu ühendamiseks ja rakenduse testimiseks. Kui sul on cloudflare'i konto, mis on ühendatud terraformiga, siis julgelt kasuta värskelt loodud DNS-nimesid.
Muide, virtuaalmasina loomisel antakse välja sisemine ip ja sisevõrgu DNS-nimi, nii et serveritele sissevõrgus saab viidata nimedega:
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 msSee on meile kasulik, et määrata rakendusele kafkaga lõpp-punkt.
Kogume rakenduse kokku
Suurepärane, serverid on olemas, rakendus on olemas — jääb vaid see kokku panna ja avaldada. Kogumiseks kasutame tavalist docker build’i, aga kui pildihoiustame, kasutame Yandexi teenust — container registry. Kuid kõigest järjest.
Kopeerime rakenduse build masinasse, siseneme ssh kaudu ja kogume pildi kokku:
vozerov@mba:~ /events /terraform (master) $ cd ..
vozerov@mba:~ /events (master) $ rsync -av app / ubuntu@84.201.132.3:app /
... пропущено ...
отправлено 3849 байт получено 70 байт 7838,00 байт / сек
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 .
Отправка контекста сборки в Docker daemon 6.144kB
Шаг 1 / 9 : FROM golang:latest AS build
... пропущено ...
Успешно построен 9760afd8ef65
Успешно помечен app:latestПолдела сделано — теперь можно проверить работоспособность нашего приложения, запустив его и направив на kafka:
ubuntu@build:~ /app$ sudo docker run --name app -d -p 8080:8080 app /app /app -kafka=kafka.ru-central1.internal:9092
С локальной машинки можно отправить тестовый event и посмотреть на ответ:
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) $Приложение ответило успехом записи и указанием id партиции и оффсета, в который попало сообщение. Дело за малым — создать registry в Яндекс.Облаке и закинуть туда наш образ (как это сделать при помощи трех строчек, описано в registry.tf файле). Создаем хранилище:
vozerov@mba:~ /events /terraform (master) $ terraform apply -target yandex_container_registry.events
... пропущено ...
План: 1 добавить, 0 изменить, 0 уничтожить.
... пропущено ...
Применение завершено! Ресурсы: 1 добавлено, 0 изменено, 0 уничтожено.Для аутентификации в container registry есть несколько способов — с помощью oauth токена, iam токена или ключа сервисного аккаунта. Более подробно об этих способах — в документации . Мы будем использовать ключ сервисного аккаунта, поэтому создаем аккаунт:
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
... пропущено ...
Применение завершено! Ресурсы: 3 добавлено, 0 изменено, 0 уничтожено.Теперь осталось сделать для него ключик:
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Получаем информацию об id нашего хранилища, перекидываем ключ и авторизуемся:
vozerov@mba:~ /events /terraform (master) $ scp key.json ubuntu@84.201.132.3:
key.json 100% 2392 215.1KB / сек 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! Ваш пароль будет храниться незашифрованным в /home/ubuntu/.docker/config.json.
Настройте помощника по учётным данным, чтобы устранить это предупреждение. Смотрите
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Вход выполнен
ubuntu@build:~$Для загрузки образа в реестр нам понадобится ID container registry, берем его из утилиты yc:
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 meie pildi uue nimega ja laadime selle üles:
ubuntu@build:~$ sudo docker tag app cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1
ubuntu@build:~$ sudo docker push cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1
Üleminek viitab hoiule [cr.yandex/crpdgj6c9umdhgaqjfmm/events]
8c286e154c6e: Laaditud
477c318b05cb: Laaditud
beee9f30bc1f: Laaditud
v1: digesti: sha256:1dd5aaa9dbdde2f60d833be0bed1c352724be3ea3158bcac3cdee41d47c5e380 suurus: 946Saame veenduda, et pilt laaditi edukalt üles:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Muide, kui installite yc utiliidi Linux masina peale, saate kasutada käsku
yc container registry configure-dockerDocker'i seadistamiseks.
Kokkuvõte
Oleme teinud mahuka ja keerulise töö ning tulemusena:
- Kujundasime meie tulevase teenuse arhitektuuri.
- Kirjutasime rakenduse golang'is, mis rakendab meie äri loogikat.
- Kogusime selle kokku ja laadisime privaatsele container registry'le.
Järgmises osas liigume huvitava juurde — laadime oma rakenduse tootmisse ja lõpuks viime selle alla koormuse. Ärge vahetage kanalit!
See materjal on saadaval REBRAIN & Yandex.Cloud avatud praktikum video salvestusena: Võtame vastu 10 000 päringut sekundis Yandex Cloudis —
Kui olete huvitatud sellistest üritustest veebis osalemisest ja reaalajas küsimuste esitamisest, liituge.
Erilise tänu tahame öelda Yandex.Cloud'le sellise ürituse korraldamise võimaluse eest. Link neile —
Kui vajate üleminekut pilve või teil on küsimusi oma infrastruktuuri kohta, .
P.S. Meil on iga kuu 2 tasuta auditi võimalust, võib-olla on just teie projekt nende seas.
Allikas: habr.com
