Hej alla vänner!
* Den här artikeln är baserad på REBRAIN & Yandex.Cloud open workshop, om du föredrar att titta på videon kan du hitta den på den här länken -
Vi hade nyligen möjlighet att prova Yandex.Cloud live. Eftersom vi ville sondera länge och hårt, övergav vi omedelbart tanken på att lansera en enkel Wordpress-blogg med en molnbas - det var för tråkigt. Efter lite funderande bestämde vi oss för att distribuera något som liknar en produktionstjänstarkitektur för att ta emot och analysera händelser i nästan realtidsläge.
Jag är helt säker på att de allra flesta online (och inte bara) företag på något sätt samlar in ett berg av information om sina användare och deras handlingar. Detta är åtminstone nödvändigt för att fatta vissa beslut - om du till exempel hanterar ett onlinespel kan du titta på statistiken på vilken nivå användare oftast fastnar och raderar din leksak. Eller varför användare lämnar din webbplats utan att köpa något (hej Yandex.Metrica).
Så vår historia: hur vi skrev en applikation i golang, testade kafka vs rabbitmq vs yqs, skrev dataströmning i ett Clickhouse-kluster och visualiserade data med yandex datalens. Naturligtvis var allt detta kryddat med infrastruktur nöjen i form av docker, terraform, gitlab ci och, naturligtvis, prometheus. Nu går vi!
Jag vill omedelbart reservera att vi inte kommer att kunna konfigurera allt på en gång - för detta kommer vi att behöva flera artiklar i serien. Lite om strukturen:
Del 1 (du läser den). Vi kommer att besluta om specifikationer och arkitektur för lösningen, och även skriva en ansökan i golang.
Del 2. Vi släpper vår applikation i produktion, gör den skalbar och testar belastningen.
Del 3. Låt oss försöka ta reda på varför vi behöver lagra meddelanden i en buffert och inte i filer, och även jämföra kafka, rabbitmq och yandex kötjänst.
Del 4 Vi kommer att distribuera ett Clickhouse-kluster, skriva en streamingtjänst för att överföra data från bufferten dit, och ställa in visualisering i datalens.
Del 5 Låt oss föra hela infrastrukturen i rätt form - ställ in ci/cd med gitlab ci, anslut övervakning och tjänsteupptäckt med prometheus och konsul.
TK
Låt oss först formulera referensvillkoren - exakt vad vi vill få som ett resultat.
- Vi vill ha en slutpunkt som events.kis.im (kis.im är testdomänen som vi kommer att använda i alla artiklar), som ska ta emot händelser med HTTPS.
- Händelser är en enkel json som: {“event”: “view”, “os”: “linux”, “browser”: “chrome”}. I slutskedet kommer vi att lägga till lite fler fält, men detta kommer inte spela någon större roll. Om du vill kan du byta till protobuf.
- Tjänsten ska kunna hantera 10 000 händelser per sekund.
- Det ska vara möjligt att skala horisontellt genom att helt enkelt lägga till nya instanser i vår lösning. Och det kommer att vara trevligt om vi kan flytta den främre delen till olika geolokaliseringar för att minska latensen för klientförfrågningar.
- Feltolerans. Lösningen måste vara tillräckligt stabil och kunna överleva fall av vilka delar som helst (upp till ett visst antal förstås).
Arkitektur
I allmänhet, för denna typ av uppgifter, har klassiska arkitekturer länge uppfunnits som möjliggör effektiv skalning. Bilden visar ett exempel på vår lösning.
Så vad vi har:
1. Till vänster finns våra enheter som genererar olika händelser, vare sig det är spelare som slutför en nivå i en leksak på en smartphone eller skapar en beställning i en onlinebutik via en vanlig webbläsare. En händelse, som specificeras i specifikationen, är en enkel json som skickas till vår slutpunkt - events.kis.im.
2. De två första servrarna är enkla balanserare, deras huvudsakliga uppgifter är:
- Var ständigt tillgänglig. För att göra detta kan du till exempel använda keepalived, som byter den virtuella IP-adressen mellan noder vid problem.
- Avsluta TLS. Ja, vi kommer att avsluta TLS på dem. För det första så att vår lösning överensstämmer med de tekniska specifikationerna, och för det andra för att avlasta bördan med att etablera en krypterad anslutning från våra backend-servrar.
- Balansera inkommande förfrågningar till tillgängliga backend-servrar. Nyckelordet här är tillgängligt. Utifrån detta kommer vi till insikten att lastbalanserare måste kunna övervaka våra servrar med applikationer och sluta balansera trafik till misslyckade noder.
3. Efter balanserarna har vi applikationsservrar som kör en ganska enkel applikation. Den ska kunna acceptera inkommande förfrågningar via HTTP, validera den skickade json och lägga in data i en buffert.
4. Diagrammet visar kafka som en buffert, även om naturligtvis andra liknande tjänster kan användas på denna nivå. Vi kommer att jämföra Kafka, rabbitmq och yqs i den tredje artikeln.
5. Den näst sista punkten i vår arkitektur är Clickhouse - en kolumnformad databas som låter dig lagra och bearbeta en enorm mängd data. På denna nivå behöver vi överföra data från bufferten till själva lagringssystemet (mer om detta i artikel 4).
Denna design tillåter oss att skala varje lager oberoende horisontellt. Backend-servrar klarar sig inte - låt oss lägga till en sak till - trots allt är de tillståndslösa applikationer, och därför kan detta göras till och med automatiskt. Kafka-liknande buffert fungerar inte - låt oss lägga till fler servrar och överföra några av partitionerna i vårt ämne till dem. Clickhouse kan inte hantera det - det är omöjligt :) Faktum är att vi också kopplar upp servrarna och delar data.
Förresten, om du vill implementera den valfria delen av våra tekniska specifikationer och skala i olika geolokaliseringar, så finns det inget enklare:
I varje geolokalisering använder vi en lastbalanserare med applikation och kafka. I allmänhet räcker det med 2 applikationsservrar, 3 kafka-noder och en molnbalanserare, till exempel cloudflare, som kontrollerar tillgängligheten av applikationsnoder och balansförfrågningar genom geolokalisering baserat på klientens IP-adress för källan. Således kommer data som skickas av en amerikansk klient att landa på amerikanska servrar. Och data från Afrika är afrikanska.
Sedan är allt ganska enkelt - vi använder spegelverktyget från Kafka-setet och kopierar all data från alla platser till vårt centrala datacenter i Ryssland. Internt analyserar vi data och registrerar dem i Clickhouse för efterföljande visualisering.
Så, vi har sorterat ut arkitekturen - låt oss börja skaka Yandex.Cloud!
Att skriva en ansökan
Innan molnet måste du ändå ha lite tålamod och skriva en ganska enkel tjänst för att hantera inkommande händelser. Vi kommer att använda golang eftersom det har visat sig mycket väl som ett språk för att skriva nätverksapplikationer.
Efter att ha spenderat en timme (kanske ett par timmar) får vi något sånt här: .
Vilka är de viktigaste punkterna jag skulle vilja notera här:
1. När du startar programmet kan du ange två flaggor. En är ansvarig för porten på vilken vi kommer att lyssna på inkommande http-förfrågningar (-addr). Den andra är för kafka-serveradressen där vi kommer att spela in våra händelser (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. Applikationen använder sarama-biblioteket () för att skicka meddelanden till kafka-klustret. Vi ställer omedelbart in inställningarna som syftar till maximal bearbetningshastighet:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Vår applikation har också en inbyggd prometheus-klient, som samlar in olika mätvärden, såsom:
- antal förfrågningar till vår ansökan;
- antal fel vid exekvering av begäran (omöjligt att läsa postbegäran, trasig json, omöjligt att skriva till Kafka);
- handläggningstid för en begäran från klienten, inklusive tiden för att skriva ett meddelande till Kafka.
4. Tre slutpunkter som vår ansökan behandlar:
- /status - returnera helt enkelt ok för att visa att vi lever. Även om du kan lägga till några kontroller, till exempel tillgängligheten för Kafka-klustret.
- /metrics - enligt denna url kommer prometheus-klienten att returnera mätvärdena som den har samlat in.
- /post är huvudslutpunkten dit POST-förfrågningar med json inuti kommer att skickas. Vår applikation kontrollerar json för giltighet och om allt är ok skriver den data till Kafka-klustret.
Jag kommer att reservera att koden inte är perfekt – den kan (och bör!) fyllas i. Du kan till exempel sluta använda det inbyggda nätet/http och byta till den snabbare fasthttp. Eller så kan du vinna bearbetningstid och cpu-resurser genom att flytta json-validitetskontrollen till ett senare skede - när data överförs från bufferten till klickhusklustret.
Förutom utvecklingssidan av problemet tänkte vi omedelbart på vår framtida infrastruktur och beslutade att distribuera vår applikation via docker. Den sista Dockerfilen för att bygga applikationen är . I allmänhet är det ganska enkelt, den enda punkten som jag skulle vilja uppmärksamma är flerstegsmonteringen, vilket gör att vi kan minska den slutliga bilden av vår behållare.
Första stegen i molnet
Först av allt, registrera dig . Efter att ha fyllt i alla nödvändiga fält kommer vi att skapa ett konto och beviljas ett bidrag för en viss summa pengar, som kan användas för att testa molntjänster. Om du vill upprepa alla steg från vår artikel borde detta bidrag vara tillräckligt för dig.
Efter registrering skapas ett separat moln och en standardkatalog för dig, där du kan börja skapa molnresurser. I allmänhet, i Yandex.Cloud, ser förhållandet mellan resurser ut så här:
Du kan skapa flera moln för ett konto. Och inuti molnet, skapa olika kataloger för olika företagsprojekt. Du kan läsa mer om detta i dokumentationen - . För övrigt kommer jag ofta att referera till det nedan i texten. När jag satte upp hela infrastrukturen från grunden hjälpte dokumentationen mig mer än en gång, så jag råder dig att studera den.
För att hantera molnet kan du använda både webbgränssnittet och konsolverktyget - yc. Installationen utförs med ett kommando (för Linux och Mac Os):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashOm din interna säkerhetsspecialist rasar om att köra skript från Internet, så kan du för det första öppna skriptet och läsa det, och för det andra kör vi det under vår användare - utan roträttigheter.
Om du vill installera en klient för Windows kan du använda instruktionerna och sedan köra yc initför att helt anpassa det:
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 princip är processen enkel – först måste du skaffa en oauth-token för att hantera molnet, välj molnet och mappen du ska använda.
Om du har flera konton eller mappar inom samma moln kan du skapa ytterligare profiler med separata inställningar via yc config profile create och växla mellan dem.
Utöver ovanstående metoder skrev Yandex.Cloud-teamet en mycket bra för att hantera molnresurser. För min del förberedde jag ett git-förråd, där jag beskrev alla resurser som kommer att skapas som en del av artikeln - . Vi är intresserade av mastergrenen, låt oss klona 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/Alla huvudvariabler som används i terraform skrivs i main.tf-filen. För att komma igång, skapa en private.auto.tfvars-fil i terraform-mappen med följande innehåll:
# 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 = ""Alla variabler kan hämtas från yc config-listan, eftersom vi redan har konfigurerat konsolverktyget. Jag råder dig att omedelbart lägga till private.auto.tfvars till .gitignore, för att inte av misstag publicera privata data.
I private.auto.tfvars specificerade vi också data från Cloudflare - för att skapa DNS-poster och proxy för huvuddomänen events.kis.im till våra servrar. Om du inte vill använda cloudflare, ta sedan bort initieringen av cloudflare-leverantören i main.tf och dns.tf-filen, som är ansvarig för att skapa de nödvändiga dns-posterna.
I vårt arbete kommer vi att kombinera alla tre metoderna - webbgränssnittet, konsolverktyget och terraform.
Virtuella nätverk
För att vara ärlig kan du hoppa över det här steget, eftersom när du skapar ett nytt moln kommer du automatiskt att ha ett separat nätverk och 3 subnät skapade - ett för varje tillgänglighetszon. Men vi skulle ändå vilja göra ett separat nätverk för vårt projekt med egen adressering. Det allmänna diagrammet över hur nätverket fungerar i Yandex.Cloud visas i figuren nedan (ärligt taget från )
Så du skapar ett gemensamt nätverk inom vilket resurser kan kommunicera med varandra. För varje tillgänglighetszon skapas ett subnät med egen adressering och kopplas till det allmänna nätverket. Som ett resultat kan alla molnresurser i den kommunicera, även om de är i olika tillgänglighetszoner. Resurser anslutna till olika molnnätverk kan endast se varandra via externa adresser. Förresten, hur fungerar denna magi inuti, .
Skapandet av nätverk beskrivs i filen network.tf från arkivet. Där skapar vi ett gemensamt privat nätverk internt och ansluter tre subnät till det i olika tillgänglighetszoner - intern-a (172.16.1.0/24), intern-b (172.16.2.0/24), intern-c (172.16.3.0/24) ).
Initiera terraform och skapa nätverk:
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.Bra! Vi har skapat vårt nätverk och är nu redo att skapa våra interna tjänster.
Skapa virtuella maskiner
För att testa applikationen behöver vi bara skapa två virtuella maskiner - vi kommer att behöva den första för att bygga och köra applikationen, den andra för att köra kafka, som vi kommer att använda för att lagra inkommande meddelanden. Och vi kommer att skapa en annan maskin där vi konfigurerar prometheus för att övervaka applikationen.
De virtuella maskinerna kommer att konfigureras med ansible, så innan du startar terraform, se till att du har en av de senaste versionerna av ansible. Och installera de nödvändiga rollerna med ansible galax:
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) $Inuti ansible-mappen finns ett exempel på .ansible.cfg-konfigurationsfil som jag använder. Det kan komma väl till pass.
Innan du skapar virtuella maskiner, se till att du har ssh-agent igång och en ssh-nyckel lagt till, annars kommer terraform inte att kunna ansluta till de skapade maskinerna. Jag stötte förstås på en bugg i os x: . För att förhindra att detta händer igen, lägg till en liten variabel i env innan du startar Terraform:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESI mappen med terraform skapar vi nödvändiga resurser:
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 ...Om allt slutade framgångsrikt (och det borde vara), kommer vi att ha tre virtuella maskiner:
- build - en maskin för att testa och bygga en applikation. Docker installerades automatiskt av Ansible.
- övervakning - en övervakningsmaskin - prometheus & grafana installerad på den. Inloggning / lösenord standard: admin / admin
- kafka är en liten maskin med kafka installerad, tillgänglig på port 9092.
Låt oss se till att alla är på plats:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Resurserna är på plats, och härifrån kan vi få deras IP-adresser. Under det följande kommer jag att använda IP-adresser för att ansluta via ssh och testa applikationen. Om du har ett cloudflare-konto kopplat till terraform, använd gärna nyskapade DNS-namn.
Förresten, när du skapar en virtuell maskin ges en intern IP och ett internt DNS-namn, så att du kan komma åt servrar inom nätverket med namn:
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 msDetta kommer att vara användbart för oss att indikera för applikationen slutpunkten med kafk.
Montering av applikationen
Bra, det finns servrar, det finns en applikation - allt som återstår är att sätta ihop det och publicera det. För bygget kommer vi att använda det vanliga dockerbygget, men som bildlagring kommer vi att använda en tjänst från Yandex - container registry. Men först till kvarn.
Vi kopierar applikationen till byggmaskinen, loggar in via ssh och sätter ihop bilden:
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:latestHalva striden är klar - nu kan vi kontrollera funktionaliteten hos vår applikation genom att starta den och skicka den till 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 svarade med framgång för inspelningen och angav ID:t för partitionen och offseten i vilken meddelandet ingick. Allt som återstår att göra är att skapa ett register i Yandex.Cloud och ladda upp vår bild där (hur man gör detta med tre rader beskrivs i filen registry.tf). Skapa en lagring:
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 finns flera sätt att autentisera i behållarregistret - med en oauth-token, en iam-token eller en tjänstkontonyckel. Mer information om dessa metoder finns i dokumentationen. . Vi kommer att använda tjänstkontonyckeln, så vi skapar ett 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 återstår bara att göra en nyckel till 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 får information om ID för vårt lager, överför nyckeln och loggar in:
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:~$För att ladda upp bilden till registret behöver vi behållarens register-ID, vi tar det från yc-verktyget:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Efter det taggar vi vår bild med ett nytt namn och laddar upp:
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 verifiera att bilden har laddats:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Förresten, om du installerar verktyget yc på en Linux-maskin kan du använda kommandot
yc container registry configure-dockerför att konfigurera docker.
Slutsats
Vi har gjort mycket hårt arbete och som ett resultat:
- Vi kom på arkitekturen för vår framtida tjänst.
- Vi skrev en applikation i golang som implementerar vår affärslogik.
- Vi samlade in det och hällde det i ett privat containerregister.
I nästa del går vi vidare till det intressanta - vi släpper vår applikation i produktion och startar slutligen belastningen på den. Byt inte!
Detta material finns i videoinspelningen av den öppna verkstaden REBRAIN & Yandex.Cloud: Vi accepterar 10 000 förfrågningar per sekund på Yandex Cloud -
Om du är intresserad av att delta i sådana evenemang online och ställa frågor i realtid, anslut till.
Vi vill rikta ett speciellt tack till Yandex.Cloud för möjligheten att vara värd för ett sådant evenemang. Länk till dem -
Om du behöver flytta till molnet eller har frågor om din infrastruktur, .
PS Vi har 2 gratis revisioner per månad, kanske ditt projekt blir en av dem.
Källa: will.com