Hej alle sammen, venner!
* Denne artikel er baseret på REBRAIN & Yandex.Cloud open workshop, hvis du foretrækker at se videoen, kan du finde den på dette link -
Vi har for nylig haft mulighed for at prøve Yandex.Cloud live. Da vi ville sondere længe og hårdt, opgav vi straks ideen om at lancere en simpel Wordpress-blog med en cloudbase - det var for kedeligt. Efter nogle overvejelser besluttede vi at implementere noget, der ligner en produktionsservicearkitektur til modtagelse og analyse af hændelser i næsten realtidstilstand.
Jeg er helt sikker på, at langt de fleste online (og ikke kun) virksomheder på en eller anden måde samler et bjerg af information om deres brugere og deres handlinger. Dette er som minimum nødvendigt for at træffe bestemte beslutninger – hvis du for eksempel administrerer et onlinespil, kan du se på statistikken, på hvilket niveau brugere oftest går i stå og sletter dit legetøj. Eller hvorfor brugere forlader dit websted uden at købe noget (hej Yandex.Metrica).
Så vores historie: hvordan vi skrev en applikation i golang, testede kafka vs rabbitmq vs yqs, skrev datastreaming i en Clickhouse-klynge og visualiserede dataene ved hjælp af yandex datalens. Alt dette var naturligvis krydret med infrastruktur-glæder i form af docker, terraform, gitlab ci og selvfølgelig prometheus. Lad os gå!
Jeg vil gerne straks tage forbehold for, at vi ikke vil være i stand til at konfigurere alt på én gang - til dette skal vi bruge flere artikler i serien. Lidt om strukturen:
Del 1 (du læser den). Vi vil tage stilling til specifikationerne og arkitekturen for løsningen, og også skrive en ansøgning i golang.
Del 2. Vi frigiver vores applikation i produktion, gør den skalerbar og tester belastningen.
Del 3. Lad os prøve at finde ud af, hvorfor vi skal gemme meddelelser i en buffer og ikke i filer, og også sammenligne kafka, rabbitmq og yandex køtjeneste.
Del 4 Vi vil implementere en Clickhouse-klynge, skrive en streamingtjeneste til at overføre data fra bufferen der, og opsætte visualisering i datalens.
Del 5 Lad os bringe hele infrastrukturen i ordentlig form - opsæt ci/cd ved hjælp af gitlab ci, tilslut overvågning og serviceopdagelse ved hjælp af prometheus og konsul.
TK
Lad os først formulere kommissoriet - hvad præcist vi ønsker at få som et resultat.
- Vi ønsker at have et slutpunkt som events.kis.im (kis.im er testdomænet, som vi vil bruge gennem alle artiklerne), som skal modtage hændelser ved hjælp af HTTPS.
- Hændelser er en simpel json som: {“event”: “view”, “os”: “linux”, “browser”: “chrome”}. På den sidste fase vil vi tilføje lidt flere felter, men det kommer ikke til at spille den store rolle. Hvis du ønsker det, kan du skifte til protobuf.
- Tjenesten skal kunne behandle 10 hændelser i sekundet.
- Det skulle være muligt at skalere horisontalt ved blot at tilføje nye instanser til vores løsning. Og det vil være rart, hvis vi kan flytte den forreste del til forskellige geolokationer for at reducere latens for klientanmodninger.
- Fejltolerance. Løsningen skal være stabil nok og kunne overleve faldet af alle dele (selvfølgelig op til et vist antal).
arkitektur
Generelt til denne type opgaver er klassiske arkitekturer længe blevet opfundet, der tillader effektiv skalering. Figuren viser et eksempel på vores løsning.
Så hvad har vi:
1. Til venstre er vores enheder, der genererer forskellige begivenheder, hvad enten det er spillere, der gennemfører et niveau i et stykke legetøj på en smartphone eller opretter en ordre i en online butik gennem en almindelig browser. En hændelse, som specificeret i specifikationen, er en simpel json, der sendes til vores slutpunkt - events.kis.im.
2. De to første servere er simple balancere, deres hovedopgaver er:
- Vær konstant tilgængelig. For at gøre dette kan du for eksempel bruge keepalived, som vil skifte den virtuelle IP mellem noder i tilfælde af problemer.
- Afslut TLS. Ja, vi afslutter TLS på dem. For det første for at vores løsning overholder de tekniske specifikationer, og for det andet for at lette byrden med at etablere en krypteret forbindelse fra vores backend-servere.
- Balancer indgående anmodninger til tilgængelige backend-servere. Nøgleordet her er tilgængeligt. På baggrund af dette kommer vi til den forståelse, at load balancere skal være i stand til at overvåge vores servere med applikationer og stoppe afbalancering af trafik til mislykkede noder.
3. Efter balancerne har vi applikationsservere, der kører en ret simpel applikation. Den skal kunne acceptere indgående anmodninger via HTTP, validere den sendte json og lægge dataene i en buffer.
4. Diagrammet viser kafka som en buffer, selvom der selvfølgelig kan bruges andre lignende tjenester på dette niveau. Vi vil sammenligne Kafka, rabbitmq og yqs i den tredje artikel.
5. Næstsidste punkt i vores arkitektur er Clickhouse - en søjleformet database, der giver dig mulighed for at gemme og behandle en enorm mængde data. På dette niveau skal vi overføre data fra bufferen til selve lagersystemet (mere om dette i artikel 4).
Dette design giver os mulighed for at skalere hvert lag uafhængigt vandret. Backend-servere kan ikke klare sig - lad os tilføje en ting mere - de er trods alt statsløse applikationer, og derfor kan dette gøres endda automatisk. Kafka-lignende buffer virker ikke - lad os tilføje flere servere og overføre nogle af partitionerne i vores emne til dem. Clickhouse kan ikke klare det - det er umuligt :) Faktisk vil vi også forbinde serverne og sønderdele dataene.
Forresten, hvis du ønsker at implementere den valgfri del af vores tekniske specifikationer og skalere i forskellige geolokationer, så er der ikke noget enklere:
I hver geolocation installerer vi en load balancer med applikation og kafka. Generelt er 2 applikationsservere, 3 kafka-noder og en cloud balancer, for eksempel cloudflare, nok, som vil kontrollere tilgængeligheden af applikationsknudepunkter og balanceanmodninger ved geolokation baseret på klientens kilde-IP-adresse. Data sendt af en amerikansk klient vil således lande på amerikanske servere. Og data fra Afrika er på afrikansk.
Så er alt ganske enkelt - vi bruger spejlværktøjet fra Kafka-sættet og kopierer alle data fra alle lokationer til vores centrale datacenter i Rusland. Internt parser vi dataene og registrerer dem i Clickhouse til efterfølgende visualisering.
Så vi har ordnet arkitekturen - lad os begynde at ryste Yandex.Cloud!
At skrive en ansøgning
Inden skyen skal du stadig være lidt tålmodig og skrive en ret simpel service til at behandle indkommende begivenheder. Vi vil bruge golang, fordi det har vist sig meget godt som et sprog til at skrive netværksapplikationer.
Efter at have brugt en time (måske et par timer), får vi noget som dette: .
Hvad er de vigtigste punkter, jeg gerne vil bemærke her:
1. Når du starter applikationen, kan du angive to flag. Den ene er ansvarlig for den port, som vi lytter til indkommende http-anmodninger på (-addr). Den anden er til kafka-serveradressen, hvor vi optager vores begivenheder (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. Applikationen bruger sarama-biblioteket () for at sende beskeder til kafka-klyngen. Vi indstiller straks indstillingerne rettet mod maksimal behandlingshastighed:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Vores applikation har også en indbygget prometheus-klient, som indsamler forskellige metrikker, såsom:
- antal anmodninger til vores ansøgning;
- antal fejl ved udførelse af anmodningen (umuligt at læse postanmodning, ødelagt json, umuligt at skrive til Kafka);
- behandlingstid for én anmodning fra klienten, herunder tid til at skrive en besked til Kafka.
4. Tre endepunkter, som vores ansøgning behandler:
- /status - returner blot ok for at vise, at vi er i live. Selvom du kan tilføje nogle kontroller, såsom tilgængeligheden af Kafka-klyngen.
- /metrics - ifølge denne url vil prometheus-klienten returnere de metrics, den har indsamlet.
- /post er hovedslutpunktet, hvor POST-anmodninger med json inde vil blive sendt. Vores applikation tjekker json for gyldighed, og hvis alt er ok, skriver den dataene til Kafka-klyngen.
Jeg vil tage forbehold for, at koden ikke er perfekt – den kan (og bør!) udfyldes. Du kan for eksempel stoppe med at bruge det indbyggede net/http og skifte til den hurtigere hurtige http. Eller du kan vinde behandlingstid og cpu-ressourcer ved at flytte json-validitetskontrollen til et senere trin - når dataene overføres fra bufferen til clickhouse-klyngen.
Ud over udviklingssiden af problemet tænkte vi straks på vores fremtidige infrastruktur og besluttede at implementere vores applikation via docker. Den sidste Dockerfile til at bygge applikationen er . Generelt er det ret simpelt, det eneste punkt, som jeg gerne vil være opmærksom på, er flertrinssamlingen, som giver os mulighed for at reducere det endelige billede af vores beholder.
Første skridt i skyen
Først og fremmest tilmeld dig . Efter at have udfyldt alle de nødvendige felter, vil vi få oprettet en konto og givet et tilskud til en vis sum penge, som kan bruges til at teste cloud-tjenester. Hvis du vil gentage alle trinene fra vores artikel, burde dette tilskud være nok for dig.
Efter registreringen oprettes en separat sky og en standardmappe til dig, hvor du kan begynde at oprette skyressourcer. Generelt i Yandex.Cloud ser forholdet mellem ressourcer sådan ud:
Du kan oprette flere skyer for én konto. Og inde i skyen, lav forskellige mapper til forskellige virksomhedsprojekter. Du kan læse mere om dette i dokumentationen - . Det vil jeg i øvrigt ofte referere til nedenfor i teksten. Da jeg satte hele infrastrukturen op fra bunden, hjalp dokumentationen mig mere end én gang, så jeg råder dig til at studere den.
For at administrere skyen kan du bruge både webgrænsefladen og konsolværktøjet - yc. Installationen udføres med én kommando (til Linux og Mac Os):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashHvis din interne sikkerhedsspecialist raser om at køre scripts fra internettet, så kan du for det første åbne scriptet og læse det, og for det andet kører vi det under vores bruger - uden root-rettigheder.
Hvis du vil installere en klient til Windows, kan du bruge instruktionerne og derefter udføre yc initfor at tilpasse det fuldt ud:
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:~ $I princippet er processen enkel – først skal du have et oauth-token til at administrere skyen, vælge skyen og den mappe, du vil bruge.
Hvis du har flere konti eller mapper inden for samme sky, kan du oprette yderligere profiler med separate indstillinger via yc config profile create og skifte mellem dem.
Ud over de ovennævnte metoder skrev Yandex.Cloud-teamet en meget god til styring af cloud-ressourcer. For mit vedkommende har jeg udarbejdet et git repository, hvor jeg beskrev alle de ressourcer, der vil blive oprettet som en del af artiklen - . Vi er interesserede i mastergrenen, lad os klone den lokalt:
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/Alle de vigtigste variabler, der bruges i terraform, er skrevet i main.tf-filen. For at komme i gang skal du oprette en private.auto.tfvars-fil i terraform-mappen med følgende indhold:
# 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 variabler kan tages fra yc config-listen, da vi allerede har konfigureret konsolværktøjet. Jeg råder dig til straks at tilføje private.auto.tfvars til .gitignore, for ikke at udgive private data ved et uheld.
I private.auto.tfvars specificerede vi også data fra Cloudflare - for at oprette DNS-poster og proxy for hoveddomænet events.kis.im til vores servere. Hvis du ikke ønsker at bruge cloudflare, så fjern initialiseringen af cloudflare-udbyderen i main.tf og dns.tf-filen, som er ansvarlig for at oprette de nødvendige dns-poster.
I vores arbejde vil vi kombinere alle tre metoder - webgrænsefladen, konsolværktøjet og terraform.
Virtuelle netværk
For at være ærlig kan du springe dette trin over, da når du opretter en ny sky, vil du automatisk have et separat netværk og 3 undernet oprettet - et for hver tilgængelighedszone. Men vi vil stadig gerne lave et separat netværk til vores projekt med egen adressering. Det generelle diagram over, hvordan netværket fungerer i Yandex.Cloud, er vist i figuren nedenfor (helt ærligt taget fra )
Så du skaber et fælles netværk, inden for hvilket ressourcer kan kommunikere med hinanden. For hver tilgængelighedszone oprettes et undernet med sin egen adressering og tilsluttes det generelle netværk. Som et resultat kan alle cloud-ressourcer i den kommunikere, selvom de er i forskellige tilgængelighedszoner. Ressourcer forbundet til forskellige cloud-netværk kan kun se hinanden gennem eksterne adresser. Forresten, hvordan virker denne magi indeni, .
Oprettelse af netværk er beskrevet i filen network.tf fra lageret. Der opretter vi ét fælles privat netværk internt og forbinder tre undernet til det i forskellige tilgængelighedszoner - intern-a (172.16.1.0/24), intern-b (172.16.2.0/24), intern-c (172.16.3.0/24) ).
Initialiser terraform og skab netværk:
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.Store! Vi har skabt vores netværk og er nu klar til at skabe vores interne tjenester.
Opret virtuelle maskiner
For at teste applikationen skal vi kun oprette to virtuelle maskiner - vi skal bruge den første til at bygge og køre applikationen, den anden til at køre kafka, som vi skal bruge til at gemme indgående beskeder. Og vi vil oprette en anden maskine, hvor vi konfigurerer prometheus til at overvåge applikationen.
De virtuelle maskiner vil blive konfigureret ved hjælp af ansible, så før du starter terraform, skal du sørge for, at du har en af de nyeste versioner af ansible. Og installer de nødvendige roller med ansible galakse:
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) $Inde i ansible-mappen er der et eksempel på .ansible.cfg-konfigurationsfil, som jeg bruger. Det kan være nyttigt.
Før du opretter virtuelle maskiner, skal du sørge for, at du har ssh-agent kørende og en ssh-nøgle tilføjet, ellers vil terraform ikke være i stand til at oprette forbindelse til de oprettede maskiner. Jeg stødte selvfølgelig på en fejl i os x: . For at forhindre, at dette sker igen, skal du tilføje en lille variabel til env, før du starter Terraform:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESI mappen med terraform opretter vi de nødvendige ressourcer:
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 ...Hvis alt endte med succes (og det burde være), så har vi tre virtuelle maskiner:
- build - en maskine til at teste og bygge en applikation. Docker blev installeret automatisk af Ansible.
- overvågning - en overvågningsmaskine - prometheus & grafana installeret på den. Login / adgangskode standard: admin / admin
- kafka er en lille maskine med kafka installeret, tilgængelig på port 9092.
Lad os sørge for, at de alle er på plads:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Ressourcerne er på plads, og herfra kan vi få deres IP-adresser. I det følgende vil jeg bruge IP-adresser til at oprette forbindelse via ssh og teste applikationen. Hvis du har en cloudflare-konto forbundet til terraform, er du velkommen til at bruge nyoprettede DNS-navne.
Forresten, når du opretter en virtuel maskine, gives en intern IP og et internt DNS-navn, så du kan få adgang til servere på netværket ved navn:
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 msDette vil være nyttigt for os at indikere til applikationen slutpunktet med kafk.
Samling af applikationen
Fantastisk, der er servere, der er en applikation - det eneste, der er tilbage, er at samle det og udgive det. Til build vil vi bruge den sædvanlige docker build, men som billedlager vil vi bruge en service fra Yandex - container registry. Men først ting først.
Vi kopierer applikationen til byggemaskinen, logger ind via ssh og samler billedet:
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:latestHalvdelen er overstået - nu kan vi tjekke funktionaliteten af vores applikation ved at starte den og sende den til kafka:
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) $Applikationen svarede med succes for optagelsen og angav id'et for den partition og offset, hvori meddelelsen var inkluderet. Alt, der er tilbage at gøre, er at oprette et register i Yandex.Cloud og uploade vores billede der (hvordan man gør dette ved hjælp af tre linjer er beskrevet i registry.tf-filen). Opret et lager:
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.Der er flere måder at godkende i containerregistret - ved hjælp af et oauth-token, et iam-token eller en servicekontonøgle. Flere detaljer om disse metoder kan findes i dokumentationen. . Vi bruger servicekontonøglen, så vi opretter en konto:
vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_iam_service_account.docker -target yandex_resourcemanager_folder_iam_binding.puller -target yandex_resourcemanager_folder_iam_binding.pusher
... skipped ...
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.Nu er der kun tilbage at lave en nøgle til det:
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_2048Vi modtager information om id på vores lager, overfører nøglen og logger ind:
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:~$For at uploade billedet til registreringsdatabasen skal vi bruge containerregistrerings-id'et, vi tager det fra yc-værktøjet:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Derefter tagger vi vores billede med et nyt navn og uploader:
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: 946Vi kan bekræfte, at billedet blev indlæst:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Forresten, hvis du installerer yc-værktøjet på en Linux-maskine, kan du bruge kommandoen
yc container registry configure-dockerfor at konfigurere docker.
Konklusion
Vi har gjort meget hårdt arbejde og som følge heraf:
- Vi fandt på arkitekturen for vores fremtidige service.
- Vi skrev en applikation i golang, der implementerer vores forretningslogik.
- Vi samlede det og hældte det i et privat containerregister.
I den næste del går vi videre til de interessante ting - vi frigiver vores applikation i produktion og starter endelig belastningen på den. Skift ikke!
Dette materiale er i videooptagelsen af den åbne workshop REBRAIN & Yandex.Cloud: Vi accepterer 10 anmodninger i sekundet på Yandex Cloud -
Hvis du er interesseret i at deltage i sådanne begivenheder online og stille spørgsmål i realtid, skal du oprette forbindelse til.
Vi vil gerne sige en særlig tak til Yandex.Cloud for muligheden for at være vært for en sådan begivenhed. Link til dem -
Hvis du har brug for at flytte til skyen eller har spørgsmål om din infrastruktur, .
PS Vi har 2 gratis revisioner om måneden, måske bliver dit projekt et af dem.
Kilde: www.habr.com