Võtame vastu 10 000 sündmust Yandexi pilves. Osa 1

Tere kõigile, sõbrad!

* See artikkel on kirjutatud REBRAINi ja Yandex.Cloudi avaliku praktikaainete põhjal, kui teile meeldib rohkem vaadata videot, saate seda leida sellest lingist — https://youtu.be/cZLezUm0ekE

Hiljuti saime võimaluse Yandex.Cloudiga lähemalt tutvuda. Kuna soovisime seda põhjalikult uurida, loobusime peagi ideest käivitada lihtne WordPressi blogi pilvebaasil — liiga igav. Pärast lühikest kaalumist otsustasime luua midagi sarnast tootmisarhitektuurile, mis oleks mõeldud sündmuste vastuvõtmiseks ja analüüsimiseks peaaegu reaalajas.

Ma olen täiesti kindel, et suurem enamus online (ja mitte ainult) ettevõtteid kogub igal juhul tohutult teavet oma klientide ja nende tegevuse kohta. Vähemalt on see vajalik teatud otsuste tegemiseks — näiteks, kui haldate online-mängu — saate vaadata statistikat, millisel tasemel kasutajad tihti kinni jäävad ja teie mängu kustutavad. Või miks inimesed lahkuvad teie veebisaidilt, ostmata midagi (tere, Yandex.Metrica).

Nii, meie lugu on järgmine: kuidas me kirjutasime rakenduse golangis, testisime kafka vs rabbitmq vs yqs, kirjutasime andmevoogu Clickhouse klastrisse ja visualiseerisime andmeid Yandex DataLens'i abil. Loomulikult oli kogu see tegevus rikastatud infrastruktuuri võtmetega nagu docker, terraform, gitlab ci ja muidugi prometheus. Lähme!

Tuleb kohe märkida, et me ei saa kõike seadistada ühe korraga — selle jaoks on meil vaja mitmeid artikleid seerias. Natuke struktuurist:

1. osa (te loete seda). Kehtestame nõudeid ja lahenduse arhitektuuri ning kirjutame rakenduse golangis.
2. osa. Paneme meie rakenduse tootmisse, teeme selle skaleeritavaks ja testime koormust.
3. osa. Proovime aru saada, miks peame sõnumeid salvestama puhvris, mitte failides, ning võrreldame omavahel kafka, rabbitmq ja yandex queue service'i.
4. osa. Hakkame tõstma Clickhouse klastrit, kirjutama andmevoogu andmete ülekandmiseks puhvrist sinna ning seadistame visualiseerimise datalens'is.
5. osa. Viime kogu infrastruktuuri korrasolekusse — seadistame ci/cd, kasutades gitlab ci-d, ühendame jälgimise ja teenuste avastamise prometheuse ja consul'i abil.

TTP

Esite täpsustame tehnilist ülesannet — mida me täpselt soovime saavutada.

  1. Me soovime, et olemas oleks endpoint, mille kuju on events.kis.im (kis.im — testdomeen, mida kasutame kogu artiklite vältel), mis peaks võtma vastu sündmusi HTTPS kaudu.
  2. Sündmused on lihtne JSON, mille vorm on: {"event": "view", "os": "linux", "browser": "chrome"}. Lõppfaasis lisame veidi rohkem välju, kuid see ei muuda suurt osa. Kui soov on olemas, siis võiksime minna üle protobufile.
  3. Teenuse peab suutma töödelda 10 000 sündmust sekundis.
  4. Peab olema võimalus horisontaalselt skaleerida — lihtsalt lisades uusi instantsse meie lahendusele. Ja oleks tore, kui saame viia esindusosa erinevatesse geolokatsioonidesse, et vähendada latentsust kliendi päringutes.
  5. Vigade taluvus. Lahendus peab olema piisavalt stabiilne ja suutma ellu jääda, kui miski osa kokku kukub (kuni teatud arvuni, loomulikult).

Arhitektuur

Selliste ülesannete jaoks on juba ammu välja mõeldud klassikalised arhitektuurid, mis võimaldavad efektiivselt skaleeruda. Joonisel on näidatud meie lahenduse näide.

Võtame vastu 10 000 sündmust Yandexi pilves. Osa 1

Nii, mida meil on:

1. Vasakul on kujutatud meie seadmed, mis genereerivad erinevaid sündmusi, olgu need siis mängijate tasemete ületamised nutitelefonis või tellimuste loomine veebipoes tavalise brauseri kaudu. Sündmus, nagu on sätestatud tehnilises ülesandes, on lihtne json, mis edastatakse meie endpoint'ile — events.kis.im.

2. Esimesed kaks serverit on lihtsad tasakaalustajad, nende põhijookseks on:

  • Olla pidevalt kättesaadavad. Selle saavutamiseks võib kasutada näiteks keepalived'i, mis lülitab virtuaalse IP aadressi nodide vahel probleemide korral.
  • TLS-i lõpetamine. Jah, me lõpetame TLS-i nende serverite peal. Esiteks, et meie lahendus vastaks tehnilisele ülesandele, ja teiseks, et vähendada meie tagaplaanide serverite koormust, mis tuleneb salajase ühenduse loomise protsessist.
  • Sisse tulevate päringute tasakaalustamine kättesaadavate tagaplaanide serverite vahel. Siin on võtmesõna — kättesaadavad. Selle põhjal jõuame mõistmisele, et tasakaalustajad peavad olema võimelised jälgima meie rakendusi ja lõpetama liikluse tasakaalustamise ebaõnnestunud nodide puhul.

3. Meie tasakaalustajate taga on rakenduste serverid, kus on käimas piisavalt lihtne rakendus. See peab olema võimeline vastu võtma sisenevaid päringuid HTTP kaudu, valideerima saadetud json-i ja salvestama andmed puhvrisse.

4. Diagrammil on puhvrina kujutatud kafka, kuigi loomulikult võib sellel tasemel kasutada ka teisi sarnaseid teenuseid. Võrdleme Kafka, rabbitmq ja yqs kolme artikli raames.

5. Meie arhitektuuri eelviimane punkt on Clickhouse — veergude andmebaas, mis võimaldab talletada ja töödelda tohutut andmemahtu. Selles etapis peab meil olema vaja andmed puhvrist viia, tegelikult, salvestussüsteemi (sellest on juttu 4. artiklis).

Selline skeem võimaldab meil sõltumatult horisontaalselt skaleerida iga taset. Kui backend serverid ei suuda, lisame veel — kuna need on stateless rakendused, on seda võimalik teha ka automaatselt. Kui kafka kujul olev puhver ei suuda, lisame servereid ja jagame osa meie teema partiidest nende peale. Kui clickhouse ei suuda — see on võimatu 🙂 Tegelikult lisame ka servereid ja shardime andmed.

Kui te soovite meie tehniliste nõuete volitusosa ellu viia ja laieneda erinevates geolokatsioonides, siis pole selleks midagi lihtsamat:

Võtame vastu 10 000 sündmust Yandexi pilves. Osa 1

Igas geolokatsioonis seadistame koormuse tasakaalustaja koos rakenduse ja kafka'ga. Üldiselt piisab kahe rakenduste serveri, kolme kafka sõlme ja pilve tasakaalustaja, näiteks cloudflare'i, paigaldamisest, mis kontrollib rakenduse sõlmede kättesaadavust ja tasakaalustab päringud geolokatsioonide vahel vastavalt kliendi algsele IP-aadressile. Nii jõuavad Ameerika klientide edastatud andmed Ameerika serveritesse. Ja Aafrika andmed — Aafrika serveritesse.

Edasi on kõik veelgi lihtsam — kasutame kafka tööriista mirror ja kopeerime kõik andmed kõikidest asukohtadest meie keskandmekeskusesse, mis asub Venemaal. Seal anname andmed edasi ja salvestame need Clickhouse'i edasise visualiseerimise jaoks.

Nii et arhitektuurist saime aru — hakkame raputama Yandex.Cloud'i!

Kirjutame rakenduse

Pilve jaoks tuleb veel veidi oodata ja kirjutada piisavalt lihtne teenus sissetulevate sündmuste töötlemiseks. Kasutame golang'i, kuna see on osutunud väga usaldusväärseks keeleks võrgurakenduste loomisel.

Veetnud tunni aega (võib-olla ka paar tundi) saame umbes sellise tulemuse: https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/main.go.

Millised on peamised punktid, mida siinkohal märkida:

1. Rakenduse käivitamisel saab määrata kaks lippu. Üks vastutab sadama eest, millel me kuulame sissetulevaid http päringuid (-addr). Teine - kafka serveri aadressi eest, kuhu me oma sündmusi kirjutame (-kafka):

addr     = flag.String("addr", ":8080", "TCP aadress, millele kuulata")
kafka    = flag.String("kafka", "127.0.0.1:9092", "Kafka lõpp-punktid")

2. Rakendus kasutab teeki sarama ([] github.com/Shopify/sarama) sõnumite saatmiseks kafka klastrisse. Oleme kohe seadnud optimeeritud seaded maksimaalse töötlemise kiirusel:

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

3. Samuti on meie rakendusse integreeritud prometheuse klient, mis kogub erinevaid mõõdikuid, nagu:

  • päringute arv meie rakendusele;
  • vigade arv päringu töötlemisel (ei suuda lugeda postipäringut, katki json, ei suuda kafka'sse kirjutada);
  • ühe päringu töötlemise aeg kliendilt, sealhulgas sõnumi kirjutamise aeg kafka'sse.

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

  • /status — просто возвращаем ok, чтобы показать, что мы живы. Хотя можно и добавить некоторые проверки, типа доступности кафка кластера.
  • /metrics — по этому url prometheus client будет возвращать собранные им метрики.
  • /post — основной endpoint, куда будут приходить POST запросы с json внутри. Наше приложение проверяет json на валидность и если все ок — записывает данные в кафка-кластер.

Tulen mainitsemaan, että koodi ei ole täydellinen — sitä voi (ja pitää!) kehittää eteenpäin. Esimerkiksi voi luopua sisäänrakennetun net/http:n käytöstä ja siirtyä nopeampaan fasthttp:hen. Tai sitten voi säästää käsittelyaikaa ja CPU-resursseja siirtämällä JSON-validointitarkistuksen myöhemmäksi vaiheeksi — kun tiedot siirretään välimuistista ClickHouse-klusteriin.

Kehityksellisestä näkökulmasta ajatellen, ajattelimme heti tulevaa infrastruktuuria ja päätimme käyttää Dockeria sovelluksen käyttöönottoon. Loppullinen Dockerfile sovelluksen kokoamiseksi on — https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/Dockerfile. Yhteenvetona se on melko yksinkertainen, ainoa asia, johon haluan kiinnittää huomiota, on multistage-kokoaminen, joka mahdollistaa säiliömme loppukoon pienentämisen.

Ensimmäiset askeleet pilvessä

Ensimmäiseksi rekisteröidymme osoitteessa cloud.yandex.ru. Kun kaikki tarvittavat kentät on täytetty, meille luodaan tili ja annetaan tuki tietyn summan verran, jota voi käyttää pilvipalveluiden testaamiseen. Jos päätät toistaa kaikki artikkelimme vaiheet, tuo tuki riittää sinulle.

Registreerimise järel luuakse teile eraldi pilv ja kaust default, kus saate alustada pilveteenuste loomist. Üldiselt näeb Yandex.Cloudis ressursside omavaheline seos välja järgmiselt:

Võtame vastu 10 000 sündmust Yandexi pilves. Osa 1

Ühe konto alla saate luua mitu pilve. Ja pilve sees teha erinevaid kaustu erinevate projektide jaoks. Lisainfot selle kohta leiate dokumentatsioonist — https://cloud.yandex.ru/docs/resource-manager/concepts/resources-hierarchy. Üksikasjalikumalt viitan ma sellele allpool. Kui ma seadistasin kogu infrastruktuuri nullist — aitas dokumentatsioon mind mitmel korral, seega soovitan seda uurida.

Pilve haldamiseks saate kasutada nii veebiliidest kui ka konsooli utiliiti — yc. Installimine toimub ühe käsuga (Linuxi ja Mac Osi jaoks):

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

Kui teie sisemine turvaspetsialist on internetist skriptide käivitamise suhtes mures — siis, esiteks, saate skripti avada ja lugeda, ja teiseks, käivitame selle oma kasutajana — ilma juurõigusteta.

Kui soovite Windowsi klienti installida, saate kasutada juhendit siit ja siis käivitada yc init, et see täielikult seadistada:

vozerov@mba:~ $ yc init
Tere! See käsk aitab teid konfiguratsiooniprotsessis.
Palun minge aadressile https://oauth.yandex.ru/authorize?response_type=token&client_id= teie OAuth tokeni saamiseks.

Palun sisestage OAuth token:
Palun valige kasutatav pilv:
 [1] cloud-b1gv67ihgfu3bp (id = b1gv67ihgfu3bpt24o0q)
 [2] fevlake-cloud (id = b1g6bvup3toribomnh30)
Palun sisestage oma numbriline valik: 2
Teie praegune pilv on määratud '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 määratud 'default' (id = b1g5r6h11knotfr8vjp7).
Kas soovite konfigureerida vaikimisi Compute tsooni? [Y/n]
Millist tsooni soovite kasutada profiili vaikimisi?
 [1] ru-central1-a
 [2] ru-central1-b
 [3] ru-central1-c
 [4] Ärge seadke vaikimisi tsooni
Palun sisestage oma numbriline valik: 1
Teie profiili vaikimisi Compute tsoon on määratud 'ru-central1-a'.
vozerov@mba:~ $

Põhimõtteliselt pole protsess keeruline — kõigepealt on vaja saada oauth token, et hallata pilve, valida pilv ja kaust, mida soovite kasutada.

Kui teil on mitu kasutajakontot või kausta ühes pilves, saate luua täiendavaid profiile eraldi seadistustega, kasutades yc config profile create ja vahetada nende vahel.

Lisaks eeltoodud meetoditele on Yandex.Cloudi meeskond kirjutanud väga hea plugin'i terraformile pilviteenuste haldamiseks. Olen oma poolt valmistanud git-repo, kus on kirjeldatud kõiki ressursse, mis luuakse artikli käigus — https://github.com/rebrainme/yandex-cloud-events/. Meid huvitab master haru, kloonime selle nüüd endale kohalikult:


vozerov@mba:~ $ git clone https://github.com/rebrainme/yandex-cloud-events/ events
Kloonimine kausta 'events'...
remote: Objekti loendamine: 100, valmis.
remote: Objektide loendamine: 100% (100/100), valmis.
remote: Objektide tihendamine: 100% (68/68), valmis.
remote: Kokku 100 (delta 37), taaskasutatud 89 (delta 26), pakett taaskasutatud 0
Objektide vastuvõtt: 100% (100/100), 25,65 KiB | 168,00 KiB/s, valmis.
Delta lahendamine: 100% (37/37), valmis.
vozerov@mba:~ $ cd events/terraform/

Kõik põhilised muutujad, mida terraformis kasutatakse, on määratud failis main.tf. Alustamiseks loome katalooge terraform failiga 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 saab võtta yc config list, kuna oleme juba konsooli utiliidi seadistanud. Soovitan kohe lisada private.auto.tfvars .gitignore, et juhuslikult privaatseid andmeid ei avaldataks.

Failis private.auto.tfvars oleme samuti määranud Cloudflare'i andmed — dns-kirjete loomiseks ja põhivalimi events.kis.im suunamiseks meie serveritesse. Kui te ei soovi Cloudflare'i kasutada, siis kustutage provider cloudflare initsialiseerimine failist main.tf ja failist dns.tf, mis vastutab vajalike dns kirje loomise eest.

Meie töös kombineerime kõiki kolme meetodit — nii veebiliidest, käsurea utiliiti kui ka terraform'i.

Virtuaalsed võrgud

Ausalt öeldes võiks selle sammu vahele jätta, kuna uue pilve loomisel luuakse automaatselt eraldi võrk ja 3 alamvõrku — igaühe jaoks ühes kättesaadavuse tsoonis. Kuid sooviksime siiski luua meie projektile eraldi võrgu oma aadresside määramisega. Üldine võrgutöö skeem Yandex.Cloudis on esitatud alloleval joonisel (ausalt öeldes on see võetud https://cloud.yandex.ru/docs/vpc/concepts/)

Võtame vastu 10 000 sündmust Yandexi pilves. Osa 1

Nii et loote ühise võrgu, mille sees saavad ressursid omavahel suhelda. Iga kättesaadavuse tsooni jaoks tehakse alamvõrk oma aadressi määramisega ja see ühendatakse ühise võrguga. Lõppkokkuvõttes saavad kõik pilveressursid selles omavahel suhelda, isegi kui nad asuvad erinevates kättesaadavuse tsoonides. Ressursid, mis on ühendatud erinevatesse pilveneetidesse, saavad üksteist näha ainult väliste aadresside kaudu. Muide, kuidas see värk seal sees töötab, on hästi kirjeldatud Habr'is.

Võrgu loomine on kirjeldatud repos oleva failis network.tf. Seal loome ühe ühise privaatse võrgu internal ja ühendame selle kolme alamvõrguga erinevates kättesaadavuspiirkondades — internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24).

Käivitame terraformi ja loome võrgud:

vozerov@mba:~/events/terraform (master) $ terraform init
... jõud on vahele jäänud ..

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

... jõud on vahele jäänud ...

Plaan: 4 lisada, 0 muuta, 0 hävitada.

Kas soovite neid toiminguid teostada?
  Terraform teostab ülaltoodud kirjeldatud toimingud.
  Ainult 'jah' aktsepteeritakse heakskiitmiseks.

  Sisestage väärtus: jah

yandex_vpc_network.internal: Loomine...
yandex_vpc_network.internal: Loomine lõpetatud 3 sekundi 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 6 sekundi pärast [id=e9b1dad6mgoj2v4funog]
yandex_vpc_subnet.internal-b: Loomine lõpetatud 7 sekundi pärast [id=e2liv5i4amu52p64ac9p]
yandex_vpc_subnet.internal-c: Jätkub loomine... [10 sekundi möödunud]
yandex_vpc_subnet.internal-c: Loomine lõpetatud 10 sekundi pärast [id=b0c2qhsj2vranoc9vhcq]

Rakendamine lõpetatud! Ressursid: 4 lisatud, 0 muudetud, 0 hävitatud.

Suurepärane! Oleme oma võrgu loonud ja nüüd valmis oma siseteenuste loomiseks.

Virtuaalmasinate loomine

Rakenduse testimiseks piisab, kui loome kaks virtuaalset masinat — esimest vajame rakenduse koostamiseks ja käivitamiseks, teist aga kafka käivitamiseks, mida kasutame sissetulevate sõnumite salvestamiseks. Loodame veel ühe masin, kuhu seadistame prometheuse rakenduse jälgimiseks.

Virtuaalsed masinad seadistatakse ansible'i abil, seega veenduge enne terraformi käivitamist, et teil on installitud üks viimaseid ansible'i versioone. 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) juba installitud, järgitakse.
- cloudalchemy-grafana (master) juba installitud, järgitakse.
- sansible.kafka (master) juba installitud, järgitakse.
- sansible.zookeeper (master) juba installitud, järgitakse.
- geerlingguy.docker (master) juba installitud, järgitakse.
vozerov@mba:~/events/ansible (master) $

Ansible'i kaustas on näidis konfiguratsioonifail .ansible.cfg, mida mina kasutan. See võib osutuda kasulikuks.

Enne virtuaalsete masinate loomist veenduge, et ssh-agent on käivitatud ja ssh-võti on lisatud, vastasel juhul ei saa terraform loodud masinatega ühendust. Ma sattusin loomulikult os x-i vea otsa: https://github.com/ansible/ansible/issues/32499#issuecomment-341578864. Et ettearvamatusi ei korduks, lisage enne Terraformi käivitamist keskkonda väike muutuja:

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

Loome Terraformi kaustas 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: Oleme värskendamas olekut... [id=enp2g2rhile7gbqlbrkr]
data.yandex_compute_image.ubuntu_image: Oleme värskendamas olekut...
yandex_vpc_subnet.internal-a: Oleme värskendamas olekut... [id=e9b1dad6mgoj2v4funog]

Täitmisplaane on genereeritud ja need on näidatud allpool.
Resursi toimingud on tähistatud järgmiste sümbolitega:
  + luuakse

... vahele jäetud ...

Plaani: 3 lisada, 0 muuta, 0 hävitada.

... vahele jäetud ...

Kui kõik läks plaanipäraselt (ja nii peab olema), siis on meil kolm virtuaalset masinat:

  1. build — masin rakenduse testimiseks ja koostamiseks. Docker installiti automaatselt ansible'i kaudu.
  2. monitoring — masin seire tegemiseks — sellele on installitud prometheus & grafana. Sisselogimise / parooli standardsed andmed: admin / admin
  3. kafka — väike masin koos installitud kafka'ga, mis on saadaval porti 9092 kaudu.

Kontrollime, et kõik on 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 kohal, ja siit saame nende ip-aadressid välja tuua. Edasi kasutan ip-aadresse ssh-ühenduseks ja rakenduse testimiseks. Kui teil on cloudflare'i konto, mis on ühendatud terraformiga, kasutage julgesti äsja loodud DNS-nimesid.
Muide, virtuaalmasina loomisel antakse sisemine ip ja sisemine DNS-nimi, nii et serveritele sisevõ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 ms

See tuleb meile kasuks rakenduse endpoint'i määramisel koos kafk'aga.

Kogume rakenduse

Suurepärane, serverid olemas, rakendus samuti — jäänud on vaid see kokku panna ja avaldada. Kokkupanekuks kasutame tavapärast docker build'i, ent piltide salvestamiseks võtame Yandexi teenuse — container registry. Aga räägime kõigest järjekorras.

Kopeerime rakenduse build-masinasse, siseneme ssh kaudu ja kogume pildi:

vozerov@mba:~/events/terraform (master) $ cd ..
vozerov@mba:~/events (master) $ rsync -av app/ ubuntu@84.201.132.3:app/

... vahele jäetud ...

saadetud 3849 baiti  saanud 70 baiti  7838.00 baiti/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 .
Saatmine ehitus konteksti Docker daemon'ile  6.144 kB
Samm 1/9 : FROM golang:latest AS build
... vahele jäetud ...

Edukas ehitamine 9760afd8ef65
Edukas sildistamine app:latest

Pool tööd on tehtud — nüüd võime kontrollida, kas meie rakendus töötab, käivitades selle ja suunates kafka peale:

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

Kohalikust masinast saab saata testürituse ja näha vastust:

<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 eduka salvestamisega ja andis edasi partitsiooni ja offset'i id, kuhu sõnum pani. Jääb veel väike samm — luua registry Yandex.Cloud'is ja panna sinna meie pilt (kuidas seda kolme rea abil teha, on kirjeldatud registry.tf failis). Loome salvestusruumi:

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

... vahele jäetud ...

Plaan: 1 lisada, 0 muuta, 0 hävitada.

... vahele jäetud ...

Rakendamine on lõpule viidud! Ressursid: 1 lisatud, 0 muudetud, 0 hävitatud.

Container registry'st autentimiseks on mitu viisi — oauth tokeni, iam tokeni või teenusekonto võtme abil. Täiendavate detailide kohta nende meetodite kohta — vaata dokumentatsiooni. 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

... vahele jäetud ...

Rakendamine on lõpule viidud! Ressursid: 3 lisatud, 0 muudetud, 0 hävitatud.

Nüüd jääb vaid luua võtme:

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 teavet meie salvestusruumi ID kohta, edastame võtme ja autentime end:

vozerov@mba:~/events/terraform (master) $ scp key.json ubuntu@84.201.132.3:
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! Teie parool salvestatakse dešifreerimata asukohta /home/ubuntu/.docker/config.json.
Konfigureerige mandaadi abiline, et seda hoiatust eemaldada. Vaata
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Logimine õnnestus
ubuntu@build:~$

Kujundi laadimiseks registreerimisse on meil vaja konteineri registri ID-d, saame 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 kujundi 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
Push viitab ladustamisele [cr.yandex/crpdgj6c9umdhgaqjfmm/events]
8c286e154c6e: Edastatud
477c318b05cb: Edastatud
beee9f30bc1f: Edastatud
v1: digesti: sha256:1dd5aaa9dbdde2f60d833be0bed1c352724be3ea3158bcac3cdee41d47c5e380 suurus: 946

Saame veenduda, et kujund on edukalt üles laaditud:

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

Muide, kui paigaldad yc tööriista Linuxi masinale, saad kasutada käsku

yc konteineri registri seadistamine-docker

dockeri seadistamiseks.

Kokkuvõte

Oleme teinud suure ja keerulise töö ning tulemuseks:

  1. Kujundasime meie tulevase teenuse arhitektuuri.
  2. Kirjutasime rakenduse golangis, mis rakendab meie äriloogikat.
  3. Kokku kogusime selle ja panime privaatsele konteineri registrile.

Järgmisel osal liigume huvitava juurde — suuname meie rakenduse tootmisse ja viime lõpuks selle alla koormuse. Ära vaheta kanalit!

See materjal on saadaval REBRAIN & Yandex.Cloud avatud praktika videoregistris: Vastame 10 000 päringule sekundis Yandex Cloudis — https://youtu.be/cZLezUm0ekE

Kui sulle meeldib selliseid üritusi veebis jälgida ja reaalajas küsimusi esitada, liitu kanaliga DevOps by REBRAIN.

Eriline tänu Yandex.Cloudile sellise ürituse korraldamise võimaluse eest. Link neile — https://cloud.yandex.ru/prices

Kui vajate pilve kolimist või teil on küsimusi oma infrastruktuuri kohta, võite julgelt jätta taotluse.

P.S. Meil on kuus 2 tasuta auditi võimalust, ehk just teie projekt on nende seas.

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster