Hallo almal, vriende!
* Hierdie artikel is gebaseer op die REBRAIN & Yandex.Cloud oop werkswinkel, as jy meer daarvan hou om video's te kyk, kan jy dit by hierdie skakel vind -
Onlangs het ons die geleentheid gehad om Yandex.Cloud regstreeks te voel. Aangesien ons vir 'n lang tyd en styf wou voel, het ons dadelik die idee laat vaar om 'n eenvoudige wordpress-blog met 'n wolkbasis te begin - dit is te vervelig. Na 'n paar oorwegings het ons besluit om iets soortgelyk aan die produksie-argitektuur van die diens te ontplooi vir die ontvangs en ontleding van gebeure in byna intydse modus.
Ek is absoluut seker dat die oorgrote meerderheid aanlyn (en nie net) besighede op een of ander manier 'n berg inligting oor hul gebruikers en hul optrede versamel. Dit is ten minste nodig om sekere besluite te neem - byvoorbeeld as jy 'n aanlyn speletjie bestuur - kan jy statistieke sien op watter vlak gebruikers die meeste geneig is om vas te sit en jou speelding te verwyder. Of hoekom gebruikers jou webwerf verlaat sonder om iets te koop (hallo, Yandex.Metrica).
Dus, ons storie: hoe ons 'n toepassing in golang geskryf het, kafka vs rabbitmq vs yqs getoets het, datastroom na die Clickhouse-groepering geskryf het en data met behulp van yandex-datalens gevisualiseer het. Natuurlik is dit alles gesout met infrastruktuur-lekkernye in die vorm van docker, terraform, gitlab ci en natuurlik prometheus. Kom ons gaan!
Ek wil dadelik 'n bespreking maak dat ons nie alles in een sitting sal kan opstel nie - hiervoor benodig ons verskeie artikels in 'n reeks. 'n Bietjie oor die struktuur:
Deel 1 (jy lees dit). Ons sal die opdrag en die argitektuur van die oplossing definieer, asook 'n toepassing in golang skryf.
2 deel. Ons laai ons toepassing op na produksie, maak dit skaalbaar en toets die vrag.
3 deel. Kom ons probeer uitvind hoekom ons boodskappe in 'n buffer moet stoor, en nie in lêers nie, en ook kafka-, rabbitmq- en yandex-toudiens met mekaar vergelyk.
4 deel. Ons sal 'n Clickhouse-kluster ontplooi, stroming skryf om data vanaf die buffer daarheen oor te dra, en visualisering in datalense opstel.
5 deel. Kom ons bring die hele infrastruktuur in behoorlike vorm - stel ci / cd op met behulp van gitlab ci, verbind monitering en diensontdekking met behulp van prometheus en konsul.
TK
Kom ons formuleer eers die opdrag – wat presies ons by die uitset wil kry.
- Ons wil 'n eindpunt hê soos events.kis.im (kis.im is die toetsdomein wat ons regdeur die artikels sal gebruik) wat gebeurtenisse met HTTPS moet aanvaar.
- Gebeurtenisse is 'n eenvoudige json van die vorm: {"event": "view", "os": "linux", "browser": "chrome"}. Op die finale stadium sal ons 'n bietjie meer velde byvoeg, maar dit sal nie 'n groot rol speel nie. As jy wil, kan jy oorskakel na protobuf.
- Die diens moet 10 000 gebeurtenisse per sekonde kan verwerk.
- Dit behoort moontlik te wees om horisontaal te skaal deur eenvoudig nuwe gevalle by ons oplossing te voeg. En dit sal lekker wees as ons die voorste deel na verskillende geo-liggings kan skuif om latensie vir kliëntversoeke te verminder.
- Fout verdraagsaamheid. Die oplossing moet stabiel genoeg wees en kan oorleef wanneer enige dele val (tot 'n sekere hoeveelheid natuurlik).
Argitektuur
Oor die algemeen, vir hierdie tipe taak, is klassieke argitekture lank reeds uitgevind wat doeltreffende skaal moontlik maak. Die figuur toon 'n voorbeeld van ons oplossing.
So wat het ons:
1. Aan die linkerkant word ons toestelle gewys wat verskeie gebeurtenisse genereer, of dit nou die vlak van spelers in 'n speelding op 'n slimfoon slaag of 'n bestelling in 'n aanlynwinkel deur 'n gewone blaaier skep. Die gebeurtenis, soos gespesifiseer in die TOR, is 'n eenvoudige json wat na ons eindpunt gestuur word - events.kis.im.
2. Die eerste twee bedieners is eenvoudige balanseerders, hul hooftake is:
- Wees voortdurend beskikbaar. Om dit te doen, kan jy byvoorbeeld keepalived gebruik, wat die virtuele IP tussen nodusse sal verander in geval van probleme.
- Beëindig TLS. Ja, ons sal TLS op hulle beëindig. Eerstens, sodat ons oplossing aan die TOR voldoen, en tweedens, om die las van die vestiging van 'n geënkripteerde verbinding vanaf ons backend-bedieners te verwyder.
- Balanseer inkomende versoeke na beskikbare backend-bedieners. Die sleutelwoord hier is toeganklik. Op grond hiervan kom ons tot die begrip dat lasbalanseerders ons bedieners met toepassings moet kan monitor en ophou om verkeer na mislukte nodusse te balanseer.
3. Agter die balanseerders het ons toepassingsbedieners wat 'n redelik eenvoudige toepassing laat loop. Dit moet in staat wees om inkomende versoeke via HTTP te aanvaar, die gestuurde json te bekragtig en die data te buffer.
4. Die diagram toon kafka as 'n buffer, alhoewel natuurlik ander soortgelyke dienste op hierdie vlak gebruik kan word. Ons sal Kafka, rabbitmq en yqs in die derde artikel vergelyk.
5. Die voorlaaste punt van ons argitektuur is Clickhouse - 'n kolomdatabasis wat jou toelaat om 'n groot hoeveelheid data te stoor en te verwerk. Op hierdie vlak moet ons data van die buffer na, in werklikheid, die stoorstelsel oordra (meer hieroor in artikel 4).
Hierdie skema stel ons in staat om elke laag onafhanklik horisontaal te skaal. Backend-bedieners kan dit nie hanteer nie - kom ons voeg meer by - omdat dit staatlose toepassings is, en daarom kan dit ten minste outomaties gedoen word. Die buffer in die vorm van kafka trek nie - kom ons voeg meer bedieners by en dra 'n deel van die partisies van ons onderwerp na hulle oor. Die klikhuis kan dit nie hanteer nie - dit is onmoontlik 🙂 Trouens, ons sal ook die bedieners koppel en die data versplinter.
Terloops, as jy 'n opsionele deel van ons tegniese taak en skaal in verskillende geo-liggings wil implementeer, dan is daar niks makliker nie:
By elke geoligging ontplooi ons 'n lasbalanseerder met toepassing en kafka. Oor die algemeen is 2 toepassingsbedieners, 3 kafka-nodusse en 'n wolkbalanseerder, soos cloudflare, genoeg, wat die beskikbaarheid van toepassingsnodusse en balansversoeke volgens geoligging sal kontroleer op grond van die kliënt se bron-IP-adres. Op hierdie manier sal data wat deur die Amerikaanse kliënt gestuur word, op Amerikaanse bedieners beland. En die data van Afrika is in Afrikaans.
Dan is alles redelik eenvoudig - ons gebruik die spieëlinstrument van die Kafka-stel en kopieer al die data van alle liggings na ons sentrale datasentrum in Rusland. Binne, ontleed ons die data en skryf dit na Clickhouse vir daaropvolgende visualisering.
So, ons het die argitektuur uitgepluis - ons begin Yandex.Cloud skud!
Die skryf van 'n aansoek
Voor die Wolk moet jy nog 'n bietjie geduldig wees en 'n redelik eenvoudige diens skryf vir die verwerking van inkomende gebeure. Ons sal golang gebruik, want dit het homself baie goed bewys as 'n taal vir die skryf van netwerktoepassings.
Nadat ons 'n uur se tyd spandeer het (miskien 'n paar uur), kry ons iets soos hierdie: .
Wat is die hoofpunte wat hier opgemerk moet word:
1. Wanneer u die toepassing begin, kan u twee vlae spesifiseer. Een is verantwoordelik vir die poort waarop ons sal luister vir inkomende http-versoeke (-addr). Die tweede is vir die adres van die kafka-bediener waar ons ons gebeure (-kafka) sal skryf:
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. Die toepassing gebruik die sarama-biblioteek () om boodskappe na die kafka-kluster te stuur. Ons stel onmiddellik die instellings gefokus op die maksimum verwerkingspoed:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Die prometheus-kliënt is ook ingebou in ons toepassing, wat verskeie maatstawwe versamel, soos:
- die aantal versoeke vir ons aansoek;
- die aantal foute tydens die uitvoering van die versoek (dit is onmoontlik om die posversoek te lees, gebreekte json, dit is onmoontlik om na kafka te skryf);
- verwerkingstyd van een versoek van die kliënt, insluitend die tyd van die skryf van die boodskap aan kafka.
4. Drie eindpunte wat ons aansoek verwerk:
- /status - keer net terug ok om te wys dat ons lewe. Alhoewel jy 'n paar tjeks kan byvoeg, soos die beskikbaarheid van 'n kafka-kluster.
- /metrics — deur hierdie url te gebruik, sal die prometheus-kliënt die maatstawwe terugstuur wat hy ingesamel het.
- /post - die hoofeindpunt waar POST-versoeke met json binne sal kom. Ons toepassing kontroleer json vir geldigheid en as alles in orde is, skryf dit die data na die kafka-groepering.
Ek sal 'n bespreking maak dat die kode nie perfek is nie - dit kan (en moet!) voltooi word. Byvoorbeeld, jy kan ophou om die ingeboude net/http te gebruik en oorskakel na die vinniger vinnige http. Of jy kan verwerkingstyd en cpu-hulpbronne wen deur die json-geldigheidskontrole na 'n latere stadium te skuif - wanneer die data van die buffer na die klikhuisgroep oorgedra sal word.
Benewens die ontwikkelingskant van die kwessie, het ons dadelik aan ons toekomstige infrastruktuur gedink en besluit om ons toepassing deur docker te ontplooi. Die finale Dockerfile vir die bou van die toepassing is − . Oor die algemeen is dit redelik eenvoudig, die enigste punt waaraan ek aandag wil gee, is die meerfase-samestelling, wat ons in staat stel om die finale beeld van ons houer te verminder.
Eerste stappe in die wolk
Eerstens, registreer vir . Nadat al die vereiste velde ingevul is, sal 'n rekening vir ons geskep word en 'n toekenning sal uitgereik word vir 'n sekere bedrag geld wat gebruik kan word om wolkdienste te toets. As jy al die stappe van ons artikel wil herhaal, behoort hierdie toekenning vir jou genoeg te wees.
Na registrasie sal 'n aparte wolk en 'n verstekgids vir jou geskep word, waarin jy wolkhulpbronne kan begin skep. Oor die algemeen, in Yandex.Cloud, lyk die verhouding van hulpbronne soos volg:
Jy kan verskeie wolke per rekening skep. En binne die wolk, maak verskillende gidse vir verskillende projekte van die maatskappy. Jy kan meer hieroor lees in die dokumentasie - . Terloops, hieronder in die teks sal ek dikwels daarna verwys. Toe ek die hele infrastruktuur van nuuts af opgestel het, het die dokumentasie my meer as een keer gehelp, so ek raai jou aan om dit te bestudeer.
Om die wolk te bestuur, kan jy beide die webkoppelvlak en die konsole-hulpmiddel gebruik - yc. Installasie word uitgevoer met een opdrag (vir Linux en Mac O's):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashAs jou interne sekuriteit gewoed het oor die uitvoer van skrifte vanaf die internet, dan kan jy eerstens die script oopmaak en dit lees, en tweedens, ons laat dit onder ons gebruiker hardloop - sonder wortelregte.
As jy 'n kliënt vir Windows wil installeer, kan jy die instruksies gebruik en dan uitvoer yc initom dit volledig aan te pas:
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:~ $In beginsel is die proses eenvoudig - eers moet jy 'n oauth-token kry om die wolk te bestuur, kies die wolk en die vouer wat jy gaan gebruik.
As jy verskeie rekeninge of vouers binne dieselfde wolk het, kan jy bykomende profiele skep met aparte instellings via yc config profile create en wissel tussen hulle.
Benewens die bogenoemde metodes, het die Yandex.Cloud-span 'n baie goeie geskryf om wolkbronne te bestuur. Ek het vir my deel 'n git-bewaarplek voorberei, waar ek al die hulpbronne beskryf wat as deel van die artikel geskep sal word - . Ons stel belang in die meestertak, kom ons kloon dit plaaslik:
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/Al die hoofveranderlikes wat in terraform gebruik word, word in die main.tf-lêer geregistreer. Om te begin, skep 'n private.auto.tfvars-lêer in die terraform-lêergids met die volgende inhoud:
# 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 = ""Alle veranderlikes kan uit die yc-konfigurasielys geneem word, aangesien ons reeds die konsolehulpmiddel gekonfigureer het. Ek raai jou aan om dadelik private.auto.tfvars by .gitignore te voeg om nie per ongeluk private data te publiseer nie.
In private.auto.tfvars het ons ook data van Cloudflare gespesifiseer - om dns-rekords te skep en die hoof events.kis.im-domein na ons bedieners te stuur. As jy nie cloudflare wil gebruik nie, verwyder dan die inisialisering van die cloudflare-verskaffer in main.tf en die dns.tf-lêer, wat verantwoordelik is vir die skep van die nodige dns-rekords.
In ons werk sal ons al drie metodes kombineer - die webkoppelvlak, die konsolenutsmiddel en terraform.
Virtuele netwerke
Om eerlik te wees, kon hierdie stap oorgeslaan gewees het, want wanneer jy 'n nuwe wolk skep, sal jy outomaties 'n aparte netwerk en 3 subnette skep - een vir elke beskikbaarheidsone. Maar tog wil ek graag 'n aparte netwerk vir ons projek maak met sy eie adressering. Die algemene skema van die netwerk in Yandex.Cloud word in die onderstaande figuur getoon (eerlik geneem uit )
So, jy skep 'n gemeenskaplike netwerk waarbinne hulpbronne met mekaar kan kommunikeer. Vir elke beskikbaarheidsone word 'n subnet gemaak met sy eie adressering en aan 'n gemeenskaplike netwerk gekoppel. As gevolg hiervan kan alle wolkbronne daarin kommunikeer, selfs in verskillende beskikbaarheidsones. Hulpbronne wat aan verskillende wolknetwerke gekoppel is, kan mekaar slegs deur eksterne adresse sien. Terloops, hoe werk hierdie magie binne, .
Netwerkskepping word beskryf in die netwerk.tf-lêer vanaf die bewaarplek. Daar skep ons een gemeenskaplike privaat netwerk intern en verbind drie subnette daaraan in verskillende beskikbaarheidsones - intern-a (172.16.1.0/24), intern-b (172.16.2.0/24), intern-c (172.16.3.0/24) ).
Inisialiseer terraform en skep netwerke:
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.Puik! Ons het ons netwerk gemaak en is nou gereed om ons interne dienste te skep.
Skep virtuele masjiene
Om die toepassing te toets, sal dit vir ons genoeg wees om twee virtuele masjiene te skep - ons het die eerste een nodig om die toepassing te bou en te laat loop, die tweede een - om kafka te laat loop, wat ons sal gebruik om inkomende boodskappe te stoor. En ons sal 'n ander masjien skep waar ons prometheus sal opstel om die toepassing te monitor.
Virtuele masjiene sal met ansible gekonfigureer word, dus maak seker dat jy een van die nuutste weergawes van ansible het voordat jy terraform hardloop. En installeer die nodige rolle met 'n moontlike sterrestelsel:
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) $Binne die ansible-lêergids is daar 'n voorbeeld .ansible.cfg-konfigurasielêer wat ek gebruik. Miskien nuttig.
Voordat u virtuele masjiene skep, maak seker dat u ssh-agent loop en ssh-sleutel bygevoeg het, anders sal terraform nie aan die geskepde masjiene kan koppel nie. Ek het natuurlik op 'n fout in os x afgekom: . Om te verhoed dat so 'n storie homself herhaal, voeg 'n klein veranderlike by env voordat Terraform begin:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESIn die gids met die terraform skep ons die nodige hulpbronne:
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 ...As alles suksesvol geëindig het (soos dit moet), dan sal ons drie virtuele masjiene hê:
- bou - 'n masjien vir die toets en bou van 'n toepassing. Docker is outomaties deur ansible geïnstalleer.
- monitering - moniteringsmasjien - prometheus & grafana is daarop geïnstalleer. Aanmelding / wagwoord standaard: admin / admin
- kafka is 'n klein masjien met kafka geïnstalleer, beskikbaar op poort 9092.
Kom ons maak seker dat hulle almal in plek is:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Die hulpbronne is in plek, en van hier af kan ons hul ip-adresse uithaal. Oral hieronder sal ek ip-adresse gebruik om via ssh te koppel en die toepassing te toets. As jy 'n cloudflare-rekening het wat aan terraform gekoppel is, gebruik gerus nuutgeskepte DNS-name.
Terloops, wanneer u 'n virtuele masjien skep, word 'n interne ip en 'n interne DNS-naam uitgereik, sodat u toegang tot bedieners binne die netwerk kan kry met die naam:
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 msDit is nuttig vir ons om die eindpunt met kafk aan die toepassing te spesifiseer.
Die samestelling van die toepassing
Wonderlik, daar is bedieners, daar is 'n toepassing - dit bly net om dit te versamel en te publiseer. Vir samestelling sal ons die gewone docker-bou gebruik, maar as 'n beeldbewaarplek sal ons 'n diens van Yandex - houerregister neem. Maar eerste dinge eerste.
Ons kopieer die toepassing na die boumasjien, gaan via ssh en bou die prent:
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:latestDie helfte van die werk is gedoen - nou kan ons die werkverrigting van ons toepassing toets deur dit te laat loop en dit na kafka te wys:
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) $Die aansoek het gereageer met 'n skryfsukses en 'n aanduiding van die id van die partisie en die afwyking waarin die boodskap geval het. Die enigste ding wat oorbly om te doen, is om 'n register in Yandex.Cloud te skep en ons prent daar op te laai (hoe om dit met drie reëls te doen, word in die registry.tf-lêer beskryf). Skep berging:
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.Daar is verskeie maniere om te verifieer in die houerregister - deur 'n oauth-token, 'n iam-token of 'n diensrekeningsleutel te gebruik. Meer besonderhede oor hierdie metodes kan in die dokumentasie gevind word. . Ons sal die diensrekeningsleutel gebruik, dus skep ons 'n rekening:
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.Nou bly dit om 'n sleutel daarvoor te maak:
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_2048Ons kry inligting oor die ID van ons berging, dra die sleutel oor en meld aan:
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:~$Om die prent na die register op te laai, benodig ons die houerregister-ID, ons neem dit van die yc-hulpprogram:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Daarna merk ons ons prent met 'n nuwe naam en laai dit:
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: 946Ons kan verifieer dat die prent suksesvol gelaai is:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Terloops, as jy die yc-hulpprogram op 'n Linux-masjien installeer, kan jy die opdrag gebruik
yc container registry configure-dockerom docker te konfigureer.
Gevolgtrekking
Ons het baie harde werk gedoen en gevolglik:
- Ons het met die argitektuur van ons toekomstige diens vorendag gekom.
- Ons het 'n toepassing in golang geskryf wat ons besigheidslogika implementeer.
- Ons het dit versamel en in 'n private houerregister gegooi.
Kom ons gaan in die volgende deel aan na die interessante deel - ons sal ons toepassing in produksie gooi en uiteindelik die las daarop begin. Moenie oorskakel nie!
Hierdie materiaal is in die video van die REBRAIN & Yandex.Cloud oop werkswinkel: Ons aanvaar 10 000 versoeke per sekonde na Yandex Cloud -
As jy belangstel om sulke geleenthede aanlyn by te woon en vrae intyds te vra, skakel in by.
Ons wil spesiaal dankie sê aan Yandex.Cloud vir die geleentheid om so 'n geleentheid te hou. Skakel na hulle -
As jy na die wolk moet skuif of vrae het oor jou infrastruktuur, .
NS Ons het 2 gratis oudits per maand, miskien sal jou projek een van hulle wees.
Bron: will.com