Hej alle sammen, venner!
* Denne artikel er skrevet baseret på det åbne praktikum REBRAIN & Yandex.Cloud, hvis du foretrækker at se videoen, kan du finde den via dette link —
For nylig fik vi mulighed for at opleve Yandex.Cloud i praksis. Da vi ønskede en grundig tilgang, opgav vi straks ideen om at starte en simpel WordPress-blog med en cloud-database — alt for kedeligt. Efter en kort overvejelse besluttede vi os for at implementere noget, der minder om en produktionsarkitektur til at modtage og analysere events i næsten realtid.
Jeg er helt sikker på, at langt størstedelen af online (og andre) virksomheder indsamler enorme mængder information om deres brugere og deres handlinger. Mindst, det er nødvendigt for at træffe bestemte beslutninger — for eksempel, hvis du driver et online-spil, kan du se statistikken for, hvor brugerne ofte sidder fast og afinstallerer dit spil. Eller hvorfor brugerne forlader din hjemmeside uden at købe noget (hej, Yandex.Metrica).
Så her er vores historie: hvordan vi skrev en applikation i Golang, testede Kafka vs RabbitMQ vs Yandex Queue Service, skrev datastreaming til Clickhouse-klyngen og visualiserede data med Yandex Datalens. Naturligvis var alt dette krydret med infrastrukturelle finesser i form af Docker, Terraform, GitLab CI og selvfølgelig Prometheus. Lad os komme i gang!
Med det samme vil jeg understrege, at vi ikke kan sætte alt op i én omgang — til dette vil vi have brug for flere artikler i serien. Lidt om strukturen:
Del 1 (denne du læser). Vi vil definere kravspecifikationen og arkitekturen for løsningen samt skrive applikationen i Golang.
Del 2. Vi tager vores applikation live, gør den skalerbar og tester belastningen.
Del 3. Vi forsøger at forstå, hvorfor vi skal gemme beskeder i en buffer og ikke i filer, samt sammenligne Kafka, RabbitMQ og Yandex Queue Service.
Del 4. Vi vil implementere en Clickhouse-klynge, skrive datastreaming til at overføre data derfra til bufferen og opsætte visualisering i Datalens.
Del 5. Vi vil bringe hele infrastrukturen i orden — opsætte CI/CD ved hjælp af GitLab CI, tilføje overvågning og service discovery med Prometheus og Consul.
Kravspecifikation
Først udformer vi kravspecifikationen — hvad præcist vi ønsker at opnå.
- Vi ønsker at have et endpoint som events.kis.im (kis.im er en testdomæne, som vi vil bruge gennem alle artikler), som skal modtage events via HTTPS.
- Events er en simpel JSON-struktur af typen: {"event": "view", "os": "linux", "browser": "chrome"}. På det endelige trin vil vi tilføje lidt flere felter, men det vil ikke have stor betydning. Hvis man ønsker det, kan man skifte til protobuf.
- Tjenesten skal kunne håndtere 10.000 events per sekund.
- Der skal være mulighed for at skalere horisontalt ved blot at tilføje nye instanser til vores løsning. Det ville også være godt, hvis vi kunne placere frontend-delen i forskellige geolokationer for at reducere latency ved kundehenvendelser.
- Failover. Løsningen skal være tilstrækkelig stabil og kunne overleve nedbrud af enhver del (op til et vist antal, naturligvis).
Arkitektur
Overordnet set er der længe blevet udviklet klassiske arkitekturer til sådanne opgaver, som gør det muligt at skalere effektivt. På billedet vises et eksempel på vores løsning.
Så, hvad har vi:
1. Til venstre er vores enheder, der genererer forskellige events, uanset om det er niveauer, som spillere gennemfører i et mobilspil, eller oprettelse af en ordre i en webbutik via en almindelig browser. Et event, som nævnt i teknisk specifikation, er en simpel JSON, der sendes til vores endpoint – events.kis.im.
2. De første to servere er enkle balancere, og deres primære opgaver er:
- At være konstant tilgængelige. For dette kan man eksempelvis bruge keepalived, som vil skifte den virtuelle IP mellem noderne i tilfælde af problemer.
- At terminere TLS. Ja, vi vil terminere TLS netop på dem. Først og fremmest for at vores løsning overholder teknisk specifikation, og for det andet for at aflaste vores backend-servere for etablering af krypterede forbindelser.
- At balancere indkommende anmodninger til tilgængelige backend-servere. Nøgleordet her er tilgængelige. Baseret på det, når vi til forståelse af, at load balancere skal kunne overvåge vores servere med applikationer og stoppe med at balancere trafikken til nedbrudte noder.
3. Bag balancerne har vi applikationsservere, hvor et ret simpelt program kører. Det skal kunne modtage indkommende anmodninger via HTTP, validere den tilsendte JSON og gemme data i en buffer.
4. Som buffer er Kafka vist på diagrammet, 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 kolonnebaseret database, der gør det muligt at gemme og bearbejde enorme mængder data. På dette niveau skal vi overføre data fra bufferen til selve lagringssystemet (dette vil blive behandlet i den fjerde artikel).
Denne opsætning gør det muligt for os at uafhængigt skalere hvert lag horisontalt. Hvis backend-serverne ikke kan håndtere belastningen, tilføjer vi flere — da de er stateless-applikationer, kan dette gøres selv i automatisk tilstand. Hvis bufferet i form af Kafka ikke kan klare det, tilføjer vi flere servere og flytter nogle af partitionerne af vores emne til dem. Hvis Clickhouse ikke kan følge med — det er umuligt 🙂 Reelt tilføjer vi også servere og sharder dataene.
Forresten, hvis du vil implementere den valgfrie del af vores specificering og gøre skaleringsmuligheder i forskellige geografiske placeringer, er der ikke noget enklere:
I hver geografisk placering opsætter vi en load balancer med applikationen og Kafka. Generelt er 2 applikationsservere, 3 Kafka-noder og en cloud load balancer, f.eks. Cloudflare, tilstrækkeligt. Denne vil kontrollere tilgængeligheden af applikationsnoderne og balancere anmodninger baseret på klientens oprindelige IP-adresse. På den måde vil data sendt af amerikanske kunder lande på amerikanske servere. Og data fra Afrika — på afrikanske.
Dernæst er alt meget enkelt — vi bruger mirror tool fra Kafka-sættet og kopierer alle data fra alle lokationer til vores centrale datacenter beliggende i Rusland. Inden i analyserer vi dataene og gemmer dem i Clickhouse til videre visualisering.
Så vi har forstået arkitekturen — lad os begynde at ryste Yandex.Cloud!
Vi skriver applikationen
Vi skal vente lidt længere på Cloud og skrive en ret simpel service til behandling af indkommende hændelser. Vi vil bruge Golang, fordi det har vist sig at være et fantastisk sprog til at skrive netværksapplikationer.
Efter at have brugt en time (måske to) får vi noget, der ligner dette: .
Hvilke hovedpunkter ville jeg gerne fremhæve her:
1. Når du starter applikationen, kan du angive to flag. Det første bestemmer den port, vi vil lytte til indkommende HTTP-anmodninger på (-addr). Det andet angiver adressen til Kafka-serveren, hvor vi vil skrive vores begivenheder (-kafka):
addr = flag.String("addr", ":8080", "TCP-adresse til at lytte til")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka-endepunkter")2. Applikationen bruger biblioteket sarama () til at sende meddelelser til Kafka-klyngen. Vi har straks sat konfigurationer, der er orienteret 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 integreret Prometheus-klient, som indsamler forskellige målinger, såsom:
- antallet af anmodninger til vores applikation;
- antallet af fejl ved behandlingen af anmodningen (kan ikke læse POST-anmodning, beskadiget JSON, kan ikke skrive til Kafka);
- tiden til behandling af en enkelt anmodning fra klienten, inklusive tiden til at skrive meddelelsen til Kafka.
4. Tre endepunkter, som vores applikation håndterer:
- /status — просто возвращаем ok, чтобы показать, что мы живы. Хотя можно и добавить некоторые проверки, типа доступности кафка кластера.
- /metrics — по этому url prometheus client будет возвращать собранные им метрики.
- /post — основной endpoint, куда будут приходить POST запросы с json внутри. Наше приложение проверяет json на валидность и если все ок — записывает данные в кафка-кластер.
Jeg vil bemærke, at koden ikke er perfekt — den kan (og skal!) forbedres. For eksempel kan man undgå at bruge den indbyggede net/http og i stedet skifte til den hurtigere fasthttp. Eller man kan spare behandlingstid og CPU-ressourcer ved at flytte JSON-valideringen til et senere trin — når dataene overføres fra buffer til ClickHouse-klyngen.
Udover den udviklingsmæssige side af spørgsmålet har vi straks tænkt på vores fremtidige infrastruktur og besluttet at implementere vores applikation via Docker. Den endelige Dockerfile til bygning af applikationen — . Generelt set er den ret simpel, det eneste, man bør være opmærksom på, er multistage-bygningen, som reducerer den endelige størrelse af vores containers billede.
Første skridt i skyen
Først registrerer vi os på . Efter at have udfyldt alle nødvendige felter, vil vi få oprettet en konto og modtage et grant på et bestemt beløb, som kan bruges til at teste cloudtjenesterne. Hvis du ønsker at gentage alle trinene i vores artikel, burde dette grant være tilstrækkeligt.
Efter registreringen vil der blive oprettet en separat sky til dig, og en standardkatalog, hvor du kan begynde at oprette skyressourcer. Generelt ser relationerne mellem ressourcerne i Yandex.Cloud således ud:
På en konto kan du oprette flere skyer. Inden for en sky kan du lave forskellige mapper til forskellige projekter i virksomheden. Du kan læse mere om dette i dokumentationen — . For øvrigt vil jeg ofte henvise til det nedenfor. Da jeg satte hele infrastrukturen op fra bunden — hjalp dokumentationen mig gang på gang, så jeg anbefaler at studere den.
Til at administrere skyen kan du bruge både webgrænsefladen og kommandolinjeværktøjet — yc. Installationen udføres med en enkelt kommando (til Linux og Mac OS):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashHvis du har indre betænkeligheder om at køre scripts fra internettet — kan du for det første åbne scriptet og læse det, og for det andet kører vi det under vores egen bruger — uden root-rettigheder.
Hvis du vil installere klienten til Windows, kan du følge instruktionerne og derefter udføre yc init, for at konfigurere det fuldstændigt:
vozerov@mba:~ $ yc init
Velkommen! Denne kommando vil tage dig gennem konfigurationsprocessen.
Gå venligst til https://oauth.yandex.ru/authorize?response_type=token&client_id= for at få OAuth-token.
Indtast venligst OAuth-token:
Vælg sky at bruge:
[1] cloud-b1gv67ihgfu3bp (id = b1gv67ihgfu3bpt24o0q)
[2] fevlake-cloud (id = b1g6bvup3toribomnh30)
Indtast dit numeriske valg: 2
Din nuværende sky er blevet indstillet til 'fevlake-cloud' (id = b1g6bvup3toribomnh30).
Vælg mappe at bruge:
[1] default (id = b1g5r6h11knotfr8vjp7)
[2] Opret en ny mappe
Indtast dit numeriske valg: 1
Din nuværende mappe er blevet indstillet til 'default' (id = b1g5r6h11knotfr8vjp7).
Vil du konfigurere en standard Compute-zone? [Y/n]
Hvilken zone vil du bruge som standardprofil?
[1] ru-central1-a
[2] ru-central1-b
[3] ru-central1-c
[4] Sæt ikke standardzone
Indtast dit numeriske valg: 1
Din profilstandard Compute-zone er blevet indstillet til 'ru-central1-a'.
vozerov@mba:~ $I princippet er processen ikke svær — først skal du få en OAuth-token til at administrere skyen, vælge skyen og den mappe, du vil bruge.
Hvis du har flere konti eller mapper inden for en sky, kan du oprette yderligere profiler med separate indstillinger via yc config profile create og skifte mellem dem.
Udover de nævnte metoder har Yandex.Cloud-teamet skrevet en rigtig god til at administrere cloud-ressourcer. På min side har jeg forberedt et git-repositorium, hvor jeg har beskrevet alle de ressourcer, der vil blive oprettet i artiklen — . Vi er interesserede i master-grenen, lad os klone den lokalt:
vozerov@mba:~ $ git clone https://github.com/rebrainme/yandex-cloud-events/ events
Klone til 'events'...
remote: Enumerer objekter: 100, færdig.
remote: Tæller objekter: 100% (100/100), færdig.
remote: Komprimerer objekter: 100% (68/68), færdig.
remote: Total 100 (delta 37), genbrugt 89 (delta 26), pakke-genbrugt 0
Modtager objekter: 100% (100/100), 25.65 KiB | 168.00 KiB/s, færdig.
Løser deltas: 100% (37/37), færdig.
vozerov@mba:~ $ cd events/terraform/Alle de vigtigste variabler, der bruges i terraform, er angivet i filen main.tf. For at komme i gang opretter vi en fil private.auto.tfvars i mappen terraform 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 list, da vi allerede har konfigureret kommandolinjeværktøjet. Jeg anbefaler at tilføje private.auto.tfvars til .gitignore, så vi ikke ved en fejltagelse offentliggør private data.
I private.auto.tfvars har vi også angivet oplysninger fra Cloudflare — til oprettelse af dns-poster og til at proxy hoveddomænet events.kis.im til vores servere. Hvis du ikke vil bruge Cloudflare, skal du fjerne initialiseringen af Cloudflare-udbyderen i main.tf og filen dns.tf, som er ansvarlig for at oprette de nødvendige dns-poster.
I vores arbejde vil vi kombinere alle tre metoder — både webgrænsefladen, kommandolinjeværktøjet og terraform.
Virtuelle netværk
Ærligt talt kunne dette trin springes over, da der automatisk vil blive oprettet et separat netværk og 3 undernet, når et nyt cloud oprettes — et for hver tilgængelighedszone. Men jeg vil stadig gerne lave et separat netværk med sin egen adressering til vores projekt. Den overordnede skema for netværksarbejdet i Yandex.Cloud er præsenteret på billedet nedenfor (ærligst hentet fra )
Så du opretter et fælles netværk, hvor ressourcerne kan kommunikere med hinanden. For hver tilgængelighedszone oprettes et undernet med sin egen adressering og tilsluttes det fælles netværk. Som resultat kan alle cloud-ressourcer i det kommunikere, selv når de befinder sig i forskellige tilgængelighedszoner. Ressourcer, der er tilsluttet forskellige cloud-netværk, kan kun se hinanden via eksterne adresser. Forresten, hvordan denne magi fungerer indeni, .
Oprettelse af netværket er beskrevet i filen network.tf fra depotet. Der opretter vi et fælles privat netværk internal og tilslutter tre undernet i forskellige tilgængelighedszoner — internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24).
Initialiser terraform og opret netværkene:
vozerov@mba:~\/events\/terraform (master) $ terraform init
... oversprunget ..
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
... oversprunget ...
Plan: 4 tilføjet, 0 ændret, 0 slettet.
Vil du udføre disse handlinger?
Terraform vil udføre de beskrevne handlinger.
Kun 'yes' vil blive accepteret for at godkende.
Indtast en værdi: yes
yandex_vpc_network.internal: Oprettelse...
yandex_vpc_network.internal: Oprettelse færdig efter 3s [id=enp2g2rhile7gbqlbrkr]
yandex_vpc_subnet.internal-a: Oprettelse...
yandex_vpc_subnet.internal-b: Oprettelse...
yandex_vpc_subnet.internal-c: Oprettelse...
yandex_vpc_subnet.internal-a: Oprettelse færdig efter 6s [id=e9b1dad6mgoj2v4funog]
yandex_vpc_subnet.internal-b: Oprettelse færdig efter 7s [id=e2liv5i4amu52p64ac9p]
yandex_vpc_subnet.internal-c: Fortsat oprettelse... [10s gået]
yandex_vpc_subnet.internal-c: Oprettelse færdig efter 10s [id=b0c2qhsj2vranoc9vhcq]
Anvendelse færdig! Ressourcer: 4 tilføjet, 0 ændret, 0 slettet.Fantastisk! Vi har lavet vores netværk og er nu klar til at oprette vores interne tjenester.
Oprettelse af virtuelle maskiner
Til at teste applikationen vil det være tilstrækkeligt at oprette to virtuelle maskiner: den første til at bygge og køre applikationen, den anden til at køre Kafka, som vi vil bruge til at gemme indkommende beskeder. Vi laver også en ekstra maskine, hvor vi opsætter Prometheus til overvågning af applikationen.
De virtuelle maskiner vil blive konfigureret med Ansible, så sørg for, at du har en af de nyeste versioner af Ansible installeret, før du kører Terraform. Installer de nødvendige roller fra Ansible Galaxy:
vozerov@mba:~\/events\/terraform (master) $ cd ..\/ansible\/\nvozerov@mba:~\/events\/ansible (master) $ ansible-galaxy install -r requirements.yml
- cloudalchemy-prometheus (master) er allerede installeret, springer over.
- cloudalchemy-grafana (master) er allerede installeret, springer over.
- sansible.kafka (master) er allerede installeret, springer over.
- sansible.zookeeper (master) er allerede installeret, springer over.
- geerlingguy.docker (master) er allerede installeret, springer over.
vozerov@mba:~\/events\/ansible (master) $Inden i mappen Ansible er der et eksempel på konfigurationsfilen .ansible.cfg, som jeg bruger. Det kan muligvis være nyttigt.
Før du opretter virtuelle maskiner, skal du sikre dig, at du har ssh-agent kørende og din ssh-nøgle tilføjet, ellers vil Terraform ikke kunne oprette forbindelse til de oprettede maskiner. Jeg stødte selvfølgelig på en fejl i OS X: . For at undgå at du får samme oplevelse, skal du tilføje en lille variabel til env, før du kører 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: Opdaterer tilstand... [id=enp2g2rhile7gbqlbrkr]
data.yandex_compute_image.ubuntu_image: Opdaterer tilstand...
yandex_vpc_subnet.internal-a: Opdaterer tilstand... [id=e9b1dad6mgoj2v4funog]
En udførelsesplan er blevet genereret og vises nedenfor.
Ressourcehandlinger er angivet med følgende symboler:
+ opret
... springet over ...
Plan: 3 tilføjelser, 0 ændringer, 0 sletninger.
... springet over ...Hvis alt er gået godt (hvilket det burde), har vi tre virtuelle maskiner:
- build — maskinen til test og opbygning af applikationen. Docker blev automatisk installeret af ansible.
- monitoring — maskinen til overvågning — den har prometheus & grafana installeret. Login / kodeord er standard: admin / admin
- kafka — en lille maskine med installeret kafka, tilgængelig via port 9092.
Lad os sikre os, 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 hente deres ip-adresser. Jeg vil bruge ip-adresserne til at oprette forbindelse via ssh og teste applikationen. Hvis du har en konto på cloudflare, der er tilsluttet terraform, så brug frit de nyligt oprettede DNS-navne.
Forresten, når du opretter en virtuel maskine, tildeles der en intern ip og et internt DNS-navn, så serverne i netværket kan tilgås ved hjælp af navne:
ubuntu@build:~$ ping kafka.ru-central1.internal
PING kafka.ru-central1.internal (172.16.1.31) 56(84) bytes data.
64 bytes fra kafka.ru-central1.internal (172.16.1.31): icmp_seq=1 ttl=63 time=1.23 ms
64 bytes fra kafka.ru-central1.internal (172.16.1.31): icmp_seq=2 ttl=63 time=0.625 ms
^C
--- kafka.ru-central1.internal ping-statistik ---
2 pakker sendt, 2 modtaget, 0% tab, tid 1001ms
rtt min/avg/max/mdev = 0.625/0.931/1.238/0.308 msDette vil være nyttigt til at angive endpoint'et til applikationen med kafka.
Vi samler applikationen
Fremragende, serverne er på plads, applikationen er der — vi skal blot samle og offentliggøre den. Vi vil bruge almindelig docker build til opbygningen, og som lager for billederne tager vi Yandex' service — container registry. Men lad os tage det i rækkefølge.
Vi kopierer applikationen til build-maskinen, logger ind via ssh og samler billedet:
vozerov@mba:~\/events\/terraform (master) $ cd ..
vozerov@mba:~\/events (master) $ rsync -av app\/ ubuntu@84.201.132.3:app\/\n
... skipped ...\n
sent 3849 bytes received 70 bytes 7838.00 bytes\/sec\ntotal size is 3644 speedup is 0.93\n
vozerov@mba:~\/events (master) $ ssh 84.201.132.3 -l ubuntu
ubuntu@build:~$ cd app
ubuntu@build:~\/app$ sudo docker build -t app .\nSending build context to Docker daemon 6.144kB\nStep 1\/9 : FROM golang:latest AS build\n... skipped ...\n
Successfully built 9760afd8ef65\nSuccessfully tagged app:latestHalvdelen af arbejdet er gjort — nu kan vi teste vores applikation ved at starte den op og pege den mod kafka:
ubuntu@build:~\/app$ sudo docker run --name app -d -p 8080:8080 app \/app\/app -kafka=kafka.ru-central1.internal:9092\n
Fra den lokale maskine kan vi sende en test-event og se svaret:\n
vozerov@mba:~\/events (master) $ curl -D - -s -X POST -d '{"key1":"data1"}' http:\/\/84.201.132.3:8080\/post\nHTTP\/1.1 200 OK\nContent-Type: application\/json\nDate: Mon, 13 Apr 2020 13:53:54 GMT\nContent-Length: 41\n\n{"status":"ok","partition":0,"Offset":0}\nvozerov@mba:~\/events (master) $Applikationen svarede med succesfuld registrering og angivelse af partitionens id og offset, hvor beskeden havnede. Nu skal vi blot oprette et register i Yandex.Cloud og uploade vores billede der (hvordan man gør det med tre linjer, er beskrevet i registry.tf-filen). Opretter lager:
vozerov@mba:~\/events\/terraform (master) $ terraform apply -target yandex_container_registry.events\n
... skipped ...\n
Plan: 1 atføje, 0 ændre, 0 slette.\n
... skipped ...\n
Anvendelse fuldført! Ressourcer: 1 tilføjet, 0 ændret, 0 slettet.Der er flere måder at autentificere sig i container registry — ved hjælp af oauth-token, iam-token eller servicekonto-nøgle. Mere om disse metoder findes i dokumentationen. . Vi vil bruge servicekonto-nø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\n
... skipped ...\n
Anvendelse fuldført! Ressourcer: 3 tilføjet, 0 ændret, 0 slettet.Nu mangler vi blot at lave en nøgle til den:
vozerov@mba:~\/events\/terraform (master) $ yc iam key create --service-account-name docker -o key.json\nid: ajej8a06kdfbehbrh91p\nservice_account_id: ajep6d38k895srp9osij\ncreated_at: "2020-04-13T14:00:30Z"\nkey_algorithm: RSA_2048Vi henter oplysninger om id'et på vores lager, overfører nøglen og logger ind:
vozerov@mba:~\/events\/terraform (master) $ scp key.json ubuntu@84.201.132.3:\nkey.json 100% 2392 215.1KB\/s 00:00\n
vozerov@mba:~\/events\/terraform (master) $ ssh 84.201.132.3 -l ubuntu\n
ubuntu@build:~$ cat key.json | sudo docker login --username json_key --password-stdin cr.yandex\nWARNING! Your password will be stored unencrypted in \/home\/ubuntu\/.docker\/config.json.\nConfigure a credential helper to remove this warning. See\nhttps:\/\/docs.docker.com\/engine\/reference\/commandline\/login\/#credentials-store\n\nLogin Succeeded\nubuntu@build:~$For at uploade billedet til registry, har vi brug for ID'et på container registry, som vi henter fra værktøjet yc:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Efter dette 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 sikre os, at billedet blev uploadet med succes:
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-dockertil at konfigurere Docker.
Konklusion
Vi har lavet et stort og hårdt arbejde og resultatet er:
- Vi har opfundet arkitekturen til vores kommende service.
- Vi har skrevet en applikation i golang, der implementerer vores forretningslogik.
- Vi har samlet den og uploaded til det private container registry.
I næste del går vi til det spændende — vi uploader vores applikation til produktion og endelig kører belastningstest på den. Bliv hængende!
Dette materiale findes som en optagelse af det åbne praktik REBRAIN & Yandex.Cloud: Håndterer 10.000 forespørgsler pr. sekund på Yandex Cloud —
Hvis du er interesseret i at deltage i sådanne arrangementer online og stille spørgsmål i realtid, tilslut dig.
Vi vil gerne sige en særlig tak til Yandex.Cloud for muligheden for at afholde et så stort arrangement. Link til dem —
Hvis du har brug for at migrere til skyen eller har spørgsmål til din infrastruktur, .
P.S. Vi har 2 gratis audits om måneden, måske er det netop dit projekt, der vil være blandt dem.
Kilde: habr.com
