Kaixo guztioi, lagunak!
* Artikulu hau REBRAIN & Yandex.Cloud tailer irekian oinarritzen da, bideoa ikusi nahi baduzu, esteka honetan aurki dezakezu -
Duela gutxi Yandex.Cloud zuzenean probatzeko aukera izan dugu. Luze eta gogor ikertu nahi genuenez, berehala utzi genuen Wordpress blog soil bat hodei oinarri batekin abiarazteko ideia - aspergarria zen. Zenbait gogoeta egin ondoren, ekoizpen-zerbitzuen arkitektura baten antzeko zerbait zabaltzea erabaki genuen, gertaerak denbora errealean ia denbora errealean jasotzeko eta aztertzeko.
Ziur nago lineako negozio gehienek (eta ez bakarrik) nolabait informazio pila biltzen dutela euren erabiltzaileei eta haien ekintzei buruz. Gutxienez, erabaki batzuk hartzeko beharrezkoa da; adibidez, lineako joko bat kudeatzen baduzu, erabiltzaileek gehien trabatuta dauden estatistikak aztertu eta jostailua ezabatu dezakezu. Edo zergatik uzten duten erabiltzaileek zure webgunea ezer erosi gabe (kaixo, Yandex.Metrica).
Beraz, gure istorioa: nola idatzi genuen aplikazio bat golang-en, kafka vs rabbitmq vs yqs probatu, Clickhouse kluster batean datuen streaming idatzi eta datuak yandex datalens erabiliz bistaratu genituen. Jakina, hori guztia azpiegituren gozamenez ondu zen docker, terraform, gitlab ci eta, noski, prometheus moduan. Goazen!
Berehala erreserba bat egin nahiko nuke, ezin izango dugula dena eserleku batean konfiguratu - horretarako serieko hainbat artikulu beharko ditugu. Egiturari buruz apur bat:
1. zatia (irakurtzen ari zara). Soluzioaren zehaztapenak eta arkitekturak erabakiko ditugu, eta aplikazio bat golang-en ere idatziko dugu.
2. zatia. Gure aplikazioa produkziora askatzen dugu, eskalagarria egiten dugu eta karga probatzen dugu.
3. zatia. Saia gaitezen asmatzen zergatik gorde behar ditugun mezuak buffer batean eta ez fitxategietan, eta konparatu ere kafka, rabbitmq eta yandex ilara zerbitzua.
4. zatia Clickhouse kluster bat zabalduko dugu, streaming zerbitzu bat idatziko dugu han bufferreko datuak transferitzeko eta bistaratzea datalens-en konfiguratuko dugu.
5. zatia Jar dezagun azpiegitura osoa forma egokian - konfiguratu ci/cd gitlab ci erabiliz, konektatu monitorizazioa eta zerbitzuen aurkikuntza prometheus eta consul erabiliz.
TK
Lehenik eta behin, formula ditzagun erreferentzia-baldintzak - zer lortu nahi dugun zehazki.
- Events.kis.im bezalako amaiera puntu bat izan nahi dugu (kis.im artikulu guztietan erabiliko dugun proba-domeinua da), HTTPS erabiliz gertaerak jaso beharko lituzkeena.
- Gertaerak json sinpleak dira: {βgertaeraβ: βikusiβ, βosβ: βlinuxβ, βarakatzaileaβ: βchromeβ}. Azken fasean eremu apur bat gehiago gehituko ditugu, baina honek ez du garrantzi handirik izango. Nahi baduzu, protobuf-era alda dezakezu.
- Zerbitzuak segundoko 10 gertaera prozesatu ahal izan behar ditu.
- Posible izan beharko litzateke horizontalki eskalatzea gure soluzioari instantzia berriak gehituz. Eta polita izango da aurrealdea geokokapen desberdinetara mugitzen badugu, bezeroen eskaeren latentzia murrizteko.
- Akatsen tolerantzia. Irtenbideak nahikoa egonkorra izan behar du eta edozein zatiren erorketari (kopuru jakin bateraino, noski) bizirik irauteko gai izan behar du.
arkitektura
Oro har, zeregin mota honetarako, aspalditik asmatu dira eskalatze eraginkorra ahalbidetzen duten arkitektura klasikoak. Irudiak gure irtenbidearen adibide bat erakusten du.
Beraz, zer daukagu:
1. Ezkerrean, hainbat gertakari sortzen dituzten gure gailuak daude, izan jokalariak telefonoz jostailu batean maila bat osatzea edo lineako denda batean eskaera bat sortzea ohiko nabigatzaile baten bidez. Gertaera bat, zehaztapenean zehazten den bezala, gure amaierako puntura bidaltzen den json soil bat da - events.kis.im.
2. Lehenengo bi zerbitzariak orekatzaile sinpleak dira, haien zeregin nagusiak hauek dira:
- Etengabe egon eskuragarri. Horretarako, adibidez, keepalived erabil dezakezu, IP birtuala nodoen artean arazoen kasuan aldatuko duena.
- Amaitu TLS. Bai, TLS amaitu egingo dugu. Lehenik eta behin, gure irtenbideak zehaztapen teknikoak bete ditzan eta, bigarrenik, gure backend zerbitzarietatik konexio enkriptatu bat ezartzearen zama arintzeko.
- Orekatu sarrerako eskaerak backend erabilgarri dauden zerbitzarietara. Hemen gakoa eskuragarri dago. Horretan oinarrituta, karga-orekatzaileek gure zerbitzariak aplikazioekin kontrolatu eta huts egin duten nodoetarako trafikoa orekatzeari utzi behar diotela ulertzen dugu.
3. Balantzaileen ondoren, aplikazio-zerbitzariak ditugu aplikazio nahiko sinple bat martxan jartzen. HTTP bidez sarrerako eskaerak onartu, bidalitako json balioztatu eta datuak buffer batean jarri behar ditu.
4. Diagraman kafka buffer gisa ageri da, nahiz eta, noski, maila honetan antzeko beste zerbitzu batzuk erabil daitezkeen. Kafka, rabbitmq eta yqs alderatuko ditugu hirugarren artikuluan.
5. Gure arkitekturaren azkenaurreko puntua Clickhouse da - datu-kopuru itzela gordetzeko eta prozesatzeko aukera ematen duen zutabe datu-basea. Maila honetan, datuak bufferretik biltegiratze-sistemara helarazi behar ditugu (hori buruz gehiago 4. artikuluan).
Diseinu honek geruza bakoitza modu independentean horizontalki eskalatzeko aukera ematen digu. Backend zerbitzariek ezin dute aurre egin - gehi dezagun gauza bat gehiago - azken finean, estaturik gabeko aplikazioak dira eta, beraz, automatikoki ere egin daiteke. Kafka estiloko buffer-ak ez du funtzionatzen; gehi ditzagun zerbitzari gehiago eta transferi ditzagun gure gaiaren partizio batzuk. Clickhouse-k ezin du kudeatu - ezinezkoa da :) Izan ere, zerbitzariak ere konektatuko ditugu eta datuak zatituko ditugu.
Bide batez, gure zehaztapen teknikoen aukerako zatia eta geokokapen ezberdinetan eskalatu nahi baduzu, ez dago ezer sinpleagorik:
Geokokapen bakoitzean karga-orekatzaile bat zabaltzen dugu aplikazioarekin eta kafkarekin. Oro har, 2 aplikazio-zerbitzari, 3 kafka nodo eta hodei-balantzaile bat, adibidez, cloudflare, nahikoa dira, aplikazio-nodoen erabilgarritasuna eta eskaerak orekatuko dituen geokokapenaren arabera, bezeroaren iturriko IP helbidean oinarrituta. Horrela, bezero amerikar batek bidalitako datuak zerbitzari amerikarretara iritsiko dira. Eta Afrikako datuak Afrikan daude.
Orduan dena nahiko erraza da: Kafka multzoko ispilu tresna erabiltzen dugu eta kokapen guztietako datu guztiak Errusian dagoen gure datu-zentro zentralera kopiatzen ditugu. Barruan, datuak analizatzen ditugu eta Clickhouse-n grabatzen ditugu, gero bistaratzeko.
Beraz, arkitektura konpondu dugu - has gaitezen Yandex.Cloud astintzen!
Aplikazio bat idaztea
Hodeiaren aurretik, oraindik pazientzia pixka bat izan behar duzu eta sarrerako gertaerak prozesatzeko nahiko zerbitzu sinple bat idatzi behar duzu. Golang erabiliko dugu sareko aplikazioak idazteko hizkuntza gisa oso ondo frogatu duelako.
Ordu bat eman ondoren (agian ordu pare bat), honelako zerbait lortzen dugu: .
Zeintzuk dira hemen adierazi nahi ditudan puntu nagusiak:
1. Aplikazioa abiaraztean, bi bandera zehaztu ditzakezu. Bata da sarrerako http eskaerak (-addr) entzungo ditugun atakaren arduraduna. Bigarrena gure gertaerak grabatuko ditugun kafka zerbitzariaren helbidea da (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpointsβ)2. Aplikazioak sarama liburutegia erabiltzen du () kafka klusterera mezuak bidaltzeko. Berehala ezarri ditugu prozesatzeko abiadura maximora zuzendutako ezarpenak:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Gure aplikazioak prometheus bezero bat ere badu, hainbat metrika biltzen dituena, hala nola:
- gure aplikaziorako eskaera kopurua;
- akats kopurua eskaera exekutatzen denean (ezin da mezu eskaera irakurri, json hautsita, ezinezkoa Kafkari idatzi);
- Bezeroaren eskaera bat prozesatzeko denbora, Kafkari mezu bat idazteko denbora barne.
4. Gure aplikazioak prozesatzen dituen hiru puntu:
- /status - besterik gabe itzuli ok bizirik gaudela erakusteko. Egiaztapen batzuk gehi ditzakezun arren, adibidez, Kafka klusterraren erabilgarritasuna.
- /metrics - url honen arabera, prometheus bezeroak bildu dituen metrikak itzuliko ditu.
- /post barruan json duten POST eskaerak bidaliko diren amaierako puntu nagusia da. Gure aplikazioak json baliozkotasuna egiaztatzen du eta dena ondo badago, datuak Kafka klusterean idazten ditu.
Erreserba bat egingo dut kodea ez dela perfektua - bete daiteke (eta behar da!). Adibidez, integratutako net/http erabiltzeari utzi eta http azkarrago azkarra alda dezakezu. Edo prozesatzeko denbora eta CPU baliabideak lor ditzakezu json baliozkotasun-egiaztapena geroagoko fase batera eramanez, datuak bufferetik clickhouse klusterera transferitzen direnean.
Arazoaren garapenaz gain, berehala pentsatu genuen gure etorkizuneko azpiegituraz eta gure aplikazioa docker bidez zabaltzea erabaki genuen. Aplikazioa eraikitzeko azken Dockerfile da . Oro har, nahiko sinplea da, arreta jarri nahiko nukeen puntu bakarra etapa anitzeko muntaia da, gure edukiontziaren azken irudia murrizteko aukera ematen duena.
Lehen urratsak hodeian
Lehenik eta behin, eman izena . Beharrezko eremu guztiak bete ondoren, kontu bat sortuko zaigu eta diru kopuru jakin baterako diru-laguntza bat emango zaigu, hodeiko zerbitzuak probatzeko erabili ahal izateko. Gure artikuluko urrats guztiak errepikatu nahi badituzu, diru-laguntza hau nahikoa izan beharko litzateke zuretzat.
Erregistratu ondoren, hodei bereizi bat eta direktorio lehenetsi bat sortuko dira, eta bertan hodeiko baliabideak sortzen has zaitezke. Oro har, Yandex.Cloud-en, baliabideen arteko erlazioa honelakoa da:
Kontu baterako hainbat hodei sor ditzakezu. Eta hodei barruan, egin direktorio desberdinak enpresa proiektu ezberdinetarako. Dokumentazioan honi buruzko informazio gehiago irakur dezakezu - . Bide batez, sarritan aipatuko dut behean testuan. Azpiegitura osoa hutsetik konfiguratu nuenean, dokumentazioak behin baino gehiagotan lagundu zidan, horregatik aztertzea gomendatzen dizut.
Hodeia kudeatzeko, web interfazea eta kontsolaren erabilgarritasuna erabil ditzakezu - yc. Instalazioa komando batekin egiten da (Linux eta Mac Osentzat):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashZure barne-segurtasuneko espezialista Internetetik scriptak exekutatzeko haserre badago, lehenik eta behin, scripta ireki eta irakurri dezakezu, eta, bigarrenik, gure erabiltzailearekin exekutatzen dugu - root eskubiderik gabe.
Windows-erako bezero bat instalatu nahi baduzu, argibideak erabil ditzakezu eta gero exekutatu yc initguztiz pertsonalizatzeko:
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:~ $Printzipioz, prozesua erraza da - lehenik eta behin oauth token bat lortu behar duzu hodeia kudeatzeko, hautatu hodeia eta erabiliko duzun karpeta.
Hodei berean hainbat kontu edo karpeta badituzu, profil gehigarriak sor ditzakezu ezarpen bereiziekin yc config profile create eta haien artean aldatzeko.
Goiko metodoez gain, Yandex.Cloud taldeak oso ona idatzi zuen hodeiko baliabideak kudeatzeko. Nire aldetik, git biltegi bat prestatu nuen, non artikuluaren zati gisa sortuko diren baliabide guztiak deskribatu nituen - . Adar maisua interesatzen zaigu, lokalean klona dezagun:
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/Terraform-en erabiltzen diren aldagai nagusi guztiak main.tf fitxategian idatzita daude. Hasteko, sortu private.auto.tfvars fitxategi bat terraform karpetan eduki honekin:
# 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 = ""Aldagai guztiak yc config zerrendatik har daitezke, dagoeneko konfiguratu baitugu kontsolaren utilitatea. Private.auto.tfvars berehala gehitzea gomendatzen dizut .gitignore-ra, datu pribatuak ustekabean ez argitaratzeko.
Private.auto.tfvars-en Cloudflare-ren datuak ere zehaztu ditugu - DNS erregistroak sortzeko eta events.kis.im domeinu nagusia gure zerbitzarietara proxy egiteko. Cloudflare erabili nahi ez baduzu, kendu cloudflare hornitzailearen hasierako main.tf eta dns.tf fitxategia, beharrezko dns erregistroak sortzeaz arduratzen dena.
Gure lanean hiru metodoak konbinatuko ditugu: web interfazea, kontsolaren erabilgarritasuna eta terraform.
Sare birtualak
Egia esateko, urrats hau salta dezakezu, hodei berri bat sortzen duzunean automatikoki sare bereizi bat eta 3 azpisare sortuko dituzu - erabilgarritasun-eremu bakoitzeko bat. Baina, hala ere, gure proiekturako sare bereizia egin nahiko genuke helbide propioarekin. Sareak Yandex.Cloud-en funtzionatzen duenaren diagrama orokorra beheko irudian ageri da (zintzotasunez hartuta )
Beraz, sare komun bat sortzen duzu, baliabideak elkarren artean komunikatzeko. Erabilgarritasun-eremu bakoitzeko, azpisare bat sortzen da helbide propioarekin eta sare orokorrera konektatuta. Ondorioz, hodeiko baliabide guztiak komunika daitezke, erabilgarritasun-eremu ezberdinetan egon arren. Hodei-sare ezberdinetara konektatutako baliabideek kanpoko helbideen bidez soilik ikus dezakete elkar. Bide batez, nola funtzionatzen du magia honek barruan, .
Sarearen sorrera biltegiko network.tf fitxategian deskribatzen da. Bertan barneko sare pribatu komun bat sortzen dugu eta hiru azpisare konektatzen ditugu erabilgarritasun-eremu ezberdinetan - internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24). ).
Hasieratu terraform eta sortu sareak:
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.Bikaina! Gure sarea sortu dugu eta orain gure barne zerbitzuak sortzeko prest gaude.
Makina birtualak sortzea
Aplikazioa probatzeko, bi makina birtual soilik sortu beharko ditugu: lehenengoa beharko dugu aplikazioa eraiki eta exekutatzeko, bigarrena kafka exekutatzeko, sarrerako mezuak gordetzeko erabiliko duguna. Eta beste makina bat sortuko dugu non prometheus aplikazioa kontrolatzeko konfiguratuko dugun.
Makina birtualak ansible erabiliz konfiguratuko dira, beraz, terraform hasi aurretik, ziurtatu ansibleren azken bertsioetako bat duzula. Eta instalatu beharrezko rolak ansible galaxiarekin:
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 karpetaren barruan erabiltzen dudan .ansible.cfg konfigurazio fitxategi adibide bat dago. Baliteke ondo etortzea.
Makina birtualak sortu baino lehen, ziurtatu ssh-agent exekutatzen duzula eta ssh gako bat gehituta duzula, bestela terraform ezin izango da sortutako makinetara konektatu. Os x-en akats bat topatu nuen, noski: . Hau berriro gerta ez dadin, gehitu aldagai txiki bat env-era Terraform abiarazi aurretik:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESTerraform duen karpetan beharrezko baliabideak sortzen ditugu:
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 ...Dena arrakastaz amaitu bada (eta izan beharko luke), orduan hiru makina birtual izango ditugu:
- build - aplikazio bat probatzeko eta eraikitzeko makina. Docker automatikoki instalatu zuen Ansiblek.
- monitoring - monitorizazio makina bat - prometheus & grafana bertan instalatuta. Saioa hasteko / pasahitz estandarra: admin / admin
- kafka kafka instalatuta duen makina txiki bat da, 9092 atakan eskuragarria.
Ziurta dezagun denak lekuan daudela:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Baliabideak martxan daude, eta hemendik haien IP helbideak lor ditzakegu. Jarraian, IP helbideak erabiliko ditut ssh bidez konektatzeko eta aplikazioa probatzeko. Terraform-era konektatuta dagoen cloudflare kontu bat baduzu, sortu berri diren DNS izenak erabil ditzakezu.
Bide batez, makina birtual bat sortzean, barne IP bat eta barneko DNS izena ematen dira, sare barruko zerbitzarietara izenaren arabera sar zaitezke:
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 msBaliagarria izango zaigu aplikazioari kafk-rekin amaiera-puntua adierazteko.
Aplikazioa muntatzea
Bikaina, zerbitzariak daude, aplikazio bat dago, muntatu eta argitaratzea besterik ez da geratzen. Eraikuntzarako ohiko docker eraikuntza erabiliko dugu, baina irudien biltegiratze gisa Yandex-eko zerbitzu bat erabiliko dugu - edukiontzien erregistroa. Baina lehenik eta behin.
Aplikazioa eraikitzeko makinara kopiatzen dugu, ssh bidez saioa hasi eta irudia muntatzen dugu:
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:latestBorroka erdia eginda dago - orain gure aplikazioaren funtzionaltasuna egiaztatu dezakegu abiarazi eta kafka-ra bidaliz:
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) $Aplikazioak grabazioaren arrakastarekin erantzun zuen eta mezua sartu zen partizioaren eta desplazamenduaren IDa adieraziz. Egin behar dena Yandex.Cloud-en erregistro bat sortzea eta gure irudia bertan igotzea da (hau hiru lerro erabiliz nola egin registry.tf fitxategian azaltzen da). Sortu biltegiratze bat:
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.Edukiontzien erregistroan autentifikatzeko hainbat modu daude: oauth token bat, iam token bat edo zerbitzu-kontuaren gako bat erabiliz. Metodo hauei buruzko xehetasun gehiago dokumentazioan aurki daitezke. . Zerbitzu-kontuaren gakoa erabiliko dugu, beraz, kontu bat sortuko dugu:
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.Orain giltza bat egitea besterik ez da geratzen:
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_2048Gure biltegiratzeko IDari buruzko informazioa jasotzen dugu, gakoa transferitu eta saioa hasi:
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:~$Irudia erregistrora igotzeko, edukiontziaren erregistroko IDa behar dugu, yc utilitatetik hartzen dugu:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Horren ostean, gure irudia izen berri batekin etiketatu eta igotzen dugu:
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: 946Irudia ondo kargatu dela egiaztatu dezakegu:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Bide batez, yc utilitatea Linux makina batean instalatzen baduzu, komandoa erabil dezakezu
yc container registry configure-dockerdocker konfiguratzeko.
Ondorioa
Lan handia egin dugu eta ondorioz:
- Gure etorkizuneko zerbitzuaren arkitektura asmatu genuen.
- Gure negozio-logika inplementatzen duen golang-en aplikazio bat idatzi dugu.
- Bildu eta edukiontzien erregistro pribatu batera bota genuen.
Hurrengo zatian, gauza interesgarrietara joango gara - gure aplikazioa produkziora aterako dugu eta, azkenik, haren karga abiaraziko dugu. Ez aldatu!
Material hau REBRAIN eta Yandex tailer irekiko bideo-grabazioan dago.Cloud: 10 eskaera onartzen ditugu segundoko Yandex Cloud-en -
Horrelako ekitaldietara linean parte hartzeko eta denbora errealean galderak egiteko interesa baduzu, konektatu.
Esker berezia eman nahi diogu Yandex.Cloud-i horrelako ekitaldi bat antolatzeko aukeragatik. Esteka haiekin -
Hodeira joan behar baduzu edo zure azpiegiturei buruzko galderarik baduzu, .
PS Hilean 2 doako auditoria ditugu, agian zure proiektua horietako bat izango da.
Iturria: www.habr.com