Hei alle sammen, venner!
* Denne artikkelen er basert på REBRAIN & Yandex.Cloud åpne verksted, hvis du foretrekker å se videoen, kan du finne den på denne lenken -
Vi hadde nylig muligheten til å prøve Yandex.Cloud live. Siden vi ønsket å undersøke lenge og hardt, forlot vi umiddelbart ideen om å lansere en enkel Wordpress-blogg med en skybase - det var for kjedelig. Etter litt omtanke bestemte vi oss for å distribuere noe som ligner på en produksjonstjenestearkitektur for å motta og analysere hendelser i nesten sanntidsmodus.
Jeg er helt sikker på at det store flertallet av nettbaserte (og ikke bare) virksomheter på en eller annen måte samler et berg av informasjon om brukerne og handlingene deres. Dette er som et minimum nødvendig for å ta visse avgjørelser – hvis du for eksempel administrerer et nettspill, kan du se på statistikken på hvilket nivå brukere oftest setter seg fast og sletter leken din. Eller hvorfor brukere forlater nettstedet ditt uten å kjøpe noe (hei Yandex.Metrica).
Så, historien vår: hvordan vi skrev en applikasjon i golang, testet kafka vs rabbitmq vs yqs, skrev datastrømming i en Clickhouse-klynge og visualiserte dataene ved hjelp av yandex datalens. Naturligvis ble alt dette krydret med infrastrukturfryd i form av docker, terraform, gitlab ci og, selvfølgelig, prometheus. La oss gå!
Jeg vil umiddelbart ta forbehold om at vi ikke vil være i stand til å konfigurere alt på en gang - for dette trenger vi flere artikler i serien. Litt om strukturen:
Del 1 (du leser den). Vi vil ta stilling til spesifikasjoner og arkitektur for løsningen, og også skrive en søknad i golang.
Del 2. Vi slipper applikasjonen vår i produksjon, gjør den skalerbar og tester belastningen.
Del 3. La oss prøve å finne ut hvorfor vi trenger å lagre meldinger i en buffer og ikke i filer, og også sammenligne kafka, rabbitmq og yandex køtjeneste.
Del 4 Vi vil distribuere en Clickhouse-klynge, skrive en strømmetjeneste for å overføre data fra bufferen der, og sette opp visualisering i datalens.
Del 5 La oss bringe hele infrastrukturen i riktig form - sett opp ci/cd ved hjelp av gitlab ci, koble til overvåking og tjenesteoppdagelse ved hjelp av prometheus og konsul.
TK
Først, la oss formulere referansevilkårene - nøyaktig hva vi ønsker å få som et resultat.
- Vi ønsker å ha et endepunkt som events.kis.im (kis.im er testdomenet som vi skal bruke gjennom alle artiklene), som skal motta hendelser ved hjelp av HTTPS.
- Hendelser er en enkel json som: {“event”: “view”, “os”: “linux”, “browser”: “chrome”}. På sluttfasen vil vi legge til litt flere felt, men dette vil ikke spille noen stor rolle. Hvis du ønsker det, kan du bytte til protobuf.
- Tjenesten skal kunne behandle 10 000 hendelser per sekund.
- Det skal være mulig å skalere horisontalt ved ganske enkelt å legge til nye instanser i løsningen vår. Og det vil være fint om vi kan flytte frontdelen til forskjellige geolokasjoner for å redusere ventetiden for klientforespørsler.
- Feiltoleranse. Løsningen må være stabil nok og kunne overleve fall av alle deler (selvfølgelig inntil et visst antall).
arkitektur
Generelt, for denne typen oppgaver, har klassiske arkitekturer lenge blitt oppfunnet som tillater effektiv skalering. Figuren viser et eksempel på vår løsning.
Så det vi har:
1. Til venstre er enhetene våre som genererer ulike arrangementer, det være seg spillere som fullfører et nivå i et leketøy på en smarttelefon eller lager en bestilling i en nettbutikk gjennom en vanlig nettleser. En hendelse, som spesifisert i spesifikasjonen, er en enkel json som sendes til vårt endepunkt - events.kis.im.
2. De to første serverne er enkle balansere, hovedoppgavene deres er:
- Vær konstant tilgjengelig. For å gjøre dette kan du for eksempel bruke keepalived, som vil bytte den virtuelle IP-en mellom noder i tilfelle problemer.
- Avslutt TLS. Ja, vi avslutter TLS på dem. For det første slik at vår løsning overholder de tekniske spesifikasjonene, og for det andre for å lette byrden med å etablere en kryptert tilkobling fra våre backend-servere.
- Balanser innkommende forespørsler til tilgjengelige backend-servere. Stikkordet her er tilgjengelig. Basert på dette kommer vi til forståelsen av at lastbalansere må kunne overvåke serverne våre med applikasjoner og slutte å balansere trafikk til mislykkede noder.
3. Etter balanserne har vi applikasjonsservere som kjører en ganske enkel applikasjon. Den skal kunne akseptere innkommende forespørsler via HTTP, validere den sendte jsonen og legge dataene inn i en buffer.
4. Diagrammet viser kafka som en buffer, selv om selvfølgelig andre lignende tjenester kan brukes på dette nivået. Vi vil sammenligne Kafka, rabbitmq og yqs i den tredje artikkelen.
5. Det nest siste punktet i arkitekturen vår er Clickhouse - en kolonneformet database som lar deg lagre og behandle en enorm mengde data. På dette nivået må vi overføre data fra bufferen til selve lagringssystemet (mer om dette i artikkel 4).
Denne designen lar oss skalere hvert lag uavhengig horisontalt. Backend-servere kan ikke takle - la oss legge til en ting til - tross alt er de statsløse applikasjoner, og derfor kan dette gjøres til og med automatisk. Kafka-bufferen fungerer ikke - la oss legge til flere servere og overføre noen av partisjonene av emnet vårt til dem. Clickhouse kan ikke håndtere det - det er umulig :) Faktisk vil vi også koble til serverne og dele dataene.
Forresten, hvis du vil implementere den valgfrie delen av våre tekniske spesifikasjoner og skalere i forskjellige geolokasjoner, så er det ikke noe enklere:
I hver geolokasjon distribuerer vi en lastbalanser med applikasjon og kafka. Generelt er 2 applikasjonsservere, 3 kafka-noder og en skybalanserer, for eksempel cloudflare, nok, som vil sjekke tilgjengeligheten til applikasjonsnoder og balanseforespørsler etter geolokalisering basert på klientens kilde-IP-adresse. Dermed vil data sendt av en amerikansk klient lande på amerikanske servere. Og data fra Afrika er på afrikansk.
Da er alt ganske enkelt - vi bruker speilverktøyet fra Kafka-settet og kopierer all data fra alle lokasjoner til vårt sentrale datasenter i Russland. Internt analyserer vi dataene og registrerer dem i Clickhouse for påfølgende visualisering.
Så, vi har sortert ut arkitekturen - la oss begynne å riste Yandex.Cloud!
Vi skriver en søknad
Før skyen må du fortsatt være litt tålmodig og skrive en ganske enkel tjeneste for å behandle innkommende hendelser. Vi vil bruke golang fordi det har vist seg veldig godt som et språk for å skrive nettverksapplikasjoner.
Etter å ha brukt en time (kanskje et par timer), får vi noe slikt: .
Hva er hovedpunktene jeg vil merke meg her:
1. Når du starter applikasjonen, kan du angi to flagg. Den ene er ansvarlig for porten som vi vil lytte til innkommende http-forespørsler på (-addr). Den andre er for kafka-serveradressen der vi vil registrere våre hendelser (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. Applikasjonen bruker sarama-biblioteket () for å sende meldinger til kafka-klyngen. Vi angir umiddelbart innstillingene rettet mot maksimal behandlingshastighet:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Vår applikasjon har også en innebygd prometheus-klient, som samler inn ulike beregninger, for eksempel:
- antall forespørsler til vår søknad;
- antall feil ved utføring av forespørselen (umulig å lese postforespørsel, ødelagt json, umulig å skrive til Kafka);
- behandlingstid for én forespørsel fra klienten, inkludert tid for å skrive en melding til Kafka.
4. Tre endepunkter som vår søknad behandler:
- /status - bare returner ok for å vise at vi lever. Selv om du kan legge til noen sjekker, for eksempel tilgjengeligheten til Kafka-klyngen.
- /metrics - i henhold til denne url'en vil prometheus-klienten returnere metrikkene den har samlet inn.
- /post er hovedendepunktet der POST-forespørsler med json inne vil bli sendt. Vår applikasjon sjekker json for gyldighet, og hvis alt er ok, skriver den dataene til Kafka-klyngen.
Jeg tar forbehold om at koden ikke er perfekt – den kan (og bør!) fullføres. Du kan for eksempel slutte å bruke det innebygde nett/http og bytte til raskere http. Eller du kan få behandlingstid og cpu-ressurser ved å flytte json-validitetskontrollen til et senere stadium - når dataene overføres fra bufferen til clickhouse-klyngen.
I tillegg til utviklingssiden av problemet, tenkte vi umiddelbart på vår fremtidige infrastruktur og bestemte oss for å distribuere applikasjonen vår via docker. Den siste Dockerfilen for å bygge applikasjonen er . Generelt er det ganske enkelt, det eneste punktet jeg vil være oppmerksom på er flertrinnsmonteringen, som lar oss redusere det endelige bildet av beholderen vår.
Første steg i skyen
Først av alt, registrer deg . Etter å ha fylt ut alle nødvendige felt, vil vi få opprettet en konto og gitt et tilskudd for en viss sum penger, som kan brukes til å teste skytjenester. Hvis du vil gjenta alle trinnene fra artikkelen vår, bør dette tilskuddet være nok for deg.
Etter registrering vil det opprettes en egen sky og en standardkatalog for deg, der du kan begynne å lage skyressurser. Generelt, i Yandex.Cloud, ser forholdet mellom ressurser slik ut:
Du kan opprette flere skyer for én konto. Og inne i skyen, lag forskjellige kataloger for forskjellige bedriftsprosjekter. Du kan lese mer om dette i dokumentasjonen - . Jeg vil forresten ofte referere til det nedenfor i teksten. Da jeg satte opp hele infrastrukturen fra bunnen av, hjalp dokumentasjonen meg mer enn én gang, så jeg anbefaler deg å studere den.
For å administrere skyen kan du bruke både nettgrensesnittet og konsollverktøyet - yc. Installasjonen utføres med én kommando (for Linux og Mac Os):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashHvis internsikkerhetsspesialisten din raser om å kjøre skript fra Internett, kan du for det første åpne skriptet og lese det, og for det andre kjører vi det under brukeren vår - uten rotrettigheter.
Hvis du vil installere en klient for Windows, kan du bruke instruksjonene og deretter utføre yc initfor å tilpasse det fullt ut:
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 prinsippet er prosessen enkel – først må du få et oauth-token for å administrere skyen, velg skyen og mappen du skal bruke.
Hvis du har flere kontoer eller mapper innenfor samme sky, kan du opprette flere profiler med separate innstillinger via yc config profile create og bytte mellom dem.
I tillegg til metodene ovenfor, skrev Yandex.Cloud-teamet en veldig god for å administrere skyressurser. For min del utarbeidet jeg et git-depot, der jeg beskrev alle ressursene som vil bli opprettet som en del av artikkelen - . Vi er interessert i mastergrenen, la oss 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 hovedvariablene som brukes i terraform er skrevet i main.tf-filen. For å komme i gang, lag en private.auto.tfvars-fil i terraform-mappen med følgende innhold:
# 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 hentes fra yc-konfigurasjonslisten, siden vi allerede har konfigurert konsollverktøyet. Jeg anbefaler deg å umiddelbart legge private.auto.tfvars til .gitignore, for ikke å publisere private data ved et uhell.
I private.auto.tfvars spesifiserte vi også data fra Cloudflare - for å lage DNS-poster og proxy-servere hoveddomenet events.kis.im til våre servere. Hvis du ikke vil bruke cloudflare, fjern initialiseringen av cloudflare-leverandøren i main.tf og dns.tf-filen, som er ansvarlig for å lage de nødvendige dns-postene.
I arbeidet vårt vil vi kombinere alle tre metodene - webgrensesnittet, konsollverktøyet og terraform.
Virtuelle nettverk
For å være ærlig, kan du hoppe over dette trinnet, siden når du oppretter en ny sky, vil du automatisk ha et eget nettverk og 3 undernett opprettet - ett for hver tilgjengelighetssone. Men vi vil likevel lage et eget nettverk for vårt prosjekt med egen adressering. Det generelle diagrammet over hvordan nettverket fungerer i Yandex.Cloud er vist i figuren nedenfor (ærlig tatt fra )
Så du oppretter et felles nettverk der ressursene kan kommunisere med hverandre. For hver tilgjengelighetssone opprettes et subnett med egen adressering og kobles til det generelle nettverket. Som et resultat kan alle skyressurser i den kommunisere, selv om de er i forskjellige tilgjengelighetssoner. Ressurser koblet til forskjellige skynettverk kan bare se hverandre gjennom eksterne adresser. Forresten, hvordan fungerer denne magien innvendig, .
Oppretting av nettverk er beskrevet i network.tf-filen fra depotet. Der lager vi ett felles privat nettverk internt og kobler tre subnett til det i forskjellige tilgjengelighetssoner - intern-a (172.16.1.0/24), intern-b (172.16.2.0/24), intern-c (172.16.3.0/24) ).
Initialiser terraform og lag nettverk:
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.Flott! Vi har opprettet vårt nettverk og er nå klare til å lage våre interne tjenester.
Opprette virtuelle maskiner
For å teste applikasjonen trenger vi bare å lage to virtuelle maskiner - vi trenger den første for å bygge og kjøre applikasjonen, den andre for å kjøre kafka, som vi skal bruke til å lagre innkommende meldinger. Og vi lager en annen maskin der vi konfigurerer prometheus til å overvåke applikasjonen.
De virtuelle maskinene vil bli konfigurert med ansible, så før du starter terraform, sørg for at du har en av de nyeste versjonene av ansible. Og installer de nødvendige rollene med mulig 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) $Inne i ansible-mappen er det en eksempel .ansible.cfg-konfigurasjonsfil som jeg bruker. Det kan komme godt med.
Før du oppretter virtuelle maskiner, sørg for at du har ssh-agent kjørende og en ssh-nøkkel lagt til, ellers vil ikke terraform kunne koble til de opprettede maskinene. Jeg kom selvfølgelig over en feil i os x: . For å forhindre at dette skjer igjen, legg til en liten variabel i env før du starter Terraform:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESI mappen med terraform lager vi de nødvendige ressursene:
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 vellykket (og det burde være), vil vi ha tre virtuelle maskiner:
- bygge - en maskin for å teste og bygge en applikasjon. Docker ble installert automatisk av Ansible.
- overvåking - en overvåkingsmaskin - prometheus & grafana installert på den. Innlogging / passord standard: admin / admin
- kafka er en liten maskin med kafka installert, tilgjengelig på port 9092.
La oss sørge for at alle er på plass:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Ressursene er på plass, og herfra kan vi hente IP-adressene deres. Gjennom det følgende vil jeg bruke IP-adresser for å koble til via ssh og teste applikasjonen. Hvis du har en cloudflare-konto koblet til terraform, bruk gjerne nyopprettede DNS-navn.
Forresten, når du oppretter en virtuell maskin, gis en intern IP og et internt DNS-navn, slik at du kan få tilgang til servere i nettverket 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 nyttig for oss å indikere til applikasjonen endepunktet med kafk.
Montering av søknaden
Flott, det er servere, det er en applikasjon - alt som gjenstår er å sette det sammen og publisere det. For byggingen vil vi bruke den vanlige docker-bygningen, men som bildelagring vil vi bruke en tjeneste fra Yandex - container registry. Men først ting først.
Vi kopierer applikasjonen til byggemaskinen, logger på via ssh og setter sammen bildet:
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:latestHalve kampen er unnagjort - nå kan vi sjekke funksjonaliteten til applikasjonen vår ved å 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) $Applikasjonen svarte med suksess for innspillingen og indikerte ID-en til partisjonen og forskyvningen der meldingen var inkludert. Alt som gjenstår å gjøre er å opprette et register i Yandex.Cloud og laste opp bildet vårt der (hvordan du gjør dette med tre linjer er beskrevet i registry.tf-filen). Opprett en lagringsplass:
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.Det er flere måter å autentisere i beholderregisteret - ved å bruke et oauth-token, et iam-token eller en tjenestekontonøkkel. Mer informasjon om disse metodene finnes i dokumentasjonen. . Vi vil bruke tjenestekontonøkkelen, så vi oppretter 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.Nå gjenstår det bare å lage en nøkkel 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 mottar informasjon om IDen til lageret vårt, overfører nøkkelen og logger inn:
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 å laste opp bildet til registret trenger vi containerregister-IDen, vi tar den fra yc-verktøyet:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Etter det merker vi bildet vårt med et nytt navn og laster opp:
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 bekrefte at bildet ble lastet inn:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Forresten, hvis du installerer yc-verktøyet på en Linux-maskin, kan du bruke kommandoen
yc container registry configure-dockerfor å konfigurere docker.
Konklusjon
Vi har gjort mye hardt arbeid og som et resultat:
- Vi kom opp med arkitekturen for vår fremtidige tjeneste.
- Vi skrev en applikasjon i golang som implementerer forretningslogikken vår.
- Vi samlet det og helte det inn i et privat beholderregister.
I neste del går vi videre til de interessante tingene - vi slipper applikasjonen vår i produksjon og til slutt starter belastningen på den. Ikke bytt!
Dette materialet er i videoopptaket av det åpne verkstedet REBRAIN & Yandex.Cloud: Vi aksepterer 10 000 forespørsler per sekund på Yandex Cloud -
Hvis du er interessert i å delta på slike arrangementer online og stille spørsmål i sanntid, koble til.
Vi vil gjerne si en spesiell takk til Yandex.Cloud for muligheten til å være vertskap for et slikt arrangement. Link til dem -
Hvis du trenger å flytte til skyen eller har spørsmål om infrastrukturen din, .
PS Vi har 2 gratis revisjoner per måned, kanskje prosjektet ditt blir en av dem.
Kilde: www.habr.com