Hola a tots, amics!
* Aquest article es basa en el taller obert REBRAIN & Yandex.Cloud, si preferiu veure el vídeo, el trobareu en aquest enllaç -
Recentment hem tingut l'oportunitat de provar Yandex.Cloud en directe. Com que volíem investigar molt i molt, de seguida vam abandonar la idea de llançar un simple bloc de Wordpress amb una base de núvol: era massa avorrit. Després d'una reflexió, vam decidir implementar alguna cosa semblant a una arquitectura de servei de producció per rebre i analitzar esdeveniments en mode gairebé en temps real.
Estic absolutament segur que la gran majoria de les empreses en línia (i no només) recullen d'alguna manera una muntanya d'informació sobre els seus usuaris i les seves accions. Com a mínim, això és necessari per prendre determinades decisions; per exemple, si gestioneu un joc en línia, podeu consultar les estadístiques en què els usuaris s'enganxen amb més freqüència i suprimir la vostra joguina. O per què els usuaris abandonen el vostre lloc sense comprar res (hola, Yandex.Metrica).
Així doncs, la nostra història: com vam escriure una aplicació en golang, vam provar kafka vs rabbitmq vs yqs, vam escriure la transmissió de dades en un clúster de Clickhouse i vam visualitzar les dades mitjançant Yandex Datalens. Naturalment, tot això estava amanit amb delícies d'infraestructura en forma de docker, terraform, gitlab ci i, per descomptat, prometheus. Som-hi!
M'agradaria fer una reserva immediatament que no podrem configurar-ho tot d'una sola vegada; per això necessitarem diversos articles de la sèrie. Una mica sobre l'estructura:
Part 1 (l'estàs llegint). Decidirem les especificacions i l'arquitectura de la solució, i també escriurem una aplicació en golang.
Part 2. Llencem la nostra aplicació a producció, la fem escalable i provem la càrrega.
Part 3. Intentem esbrinar per què hem d'emmagatzemar els missatges en una memòria intermèdia i no en fitxers, i també comparem el servei de cua kafka, rabbitmq i yandex.
Part 4 Desplegarem un clúster Clickhouse, escriurem un servei de transmissió per transferir dades del buffer allà i configurarem la visualització a datalens.
Part 5 Posem la infraestructura sencera a la forma adequada: configureu ci/cd amb gitlab ci, connecteu el monitoratge i el descobriment de serveis mitjançant prometheus i consul.
TK
Primer, formulem els termes de referència: què volem obtenir exactament com a resultat.
- Volem tenir un punt final com events.kis.im (kis.im és el domini de prova que utilitzarem en tots els articles), que hauria de rebre esdeveniments mitjançant HTTPS.
- Els esdeveniments són un simple json com: {“event”: “view”, “os”: “linux”, “browser”: “chrome”}. En l'etapa final afegirem una mica més de camps, però això no tindrà un paper important. Si voleu, podeu canviar a protobuf.
- El servei ha de poder processar 10 esdeveniments per segon.
- Hauria de ser possible escalar horitzontalment simplement afegint noves instàncies a la nostra solució. I estarà bé si podem moure la part frontal a diferents geolocalitzacions per reduir la latència de les sol·licituds dels clients.
- Falta de tolerància. La solució ha de ser prou estable i poder sobreviure a la caiguda de qualsevol part (fins a un nombre determinat, és clar).
arquitectura
En general, per a aquest tipus de tasques, fa temps que s'inventen arquitectures clàssiques que permeten un escalat eficient. La figura mostra un exemple de la nostra solució.
Així que el que tenim:
1. A l'esquerra hi ha els nostres dispositius que generen diversos esdeveniments, ja siguin jugadors que completen un nivell en una joguina amb un telèfon intel·ligent o que creen una comanda en una botiga en línia mitjançant un navegador normal. Un esdeveniment, tal com s'especifica a l'especificació, és un simple json que s'envia al nostre punt final: events.kis.im.
2. Els dos primers servidors són simples equilibradors, les seves tasques principals són:
- Estar disponible constantment. Per fer-ho, podeu utilitzar, per exemple, keepalived, que canviarà la IP virtual entre nodes en cas de problemes.
- Finalitzar TLS. Sí, cancel·larem el TLS en ells. En primer lloc, perquè la nostra solució compleixi amb les especificacions tècniques, i en segon lloc, per alleujar la càrrega d'establir una connexió xifrada des dels nostres servidors backend.
- Equilibra les sol·licituds entrants als servidors backend disponibles. La paraula clau aquí és accessible. A partir d'això, arribem a entendre que els equilibradors de càrrega han de ser capaços de supervisar els nostres servidors amb aplicacions i deixar d'equilibrar el trànsit als nodes fallits.
3. Després dels equilibradors, tenim servidors d'aplicacions que executen una aplicació bastant senzilla. Hauria de poder acceptar sol·licituds entrants mitjançant HTTP, validar el json enviat i posar les dades en un buffer.
4. El diagrama mostra kafka com a buffer, encara que, per descomptat, es poden utilitzar altres serveis similars en aquest nivell. Compararem Kafka, rabbitmq i yqs al tercer article.
5. El penúltim punt de la nostra arquitectura és Clickhouse: una base de dades de columna que us permet emmagatzemar i processar una gran quantitat de dades. En aquest nivell, hem de transferir dades de la memòria intermèdia al propi sistema d'emmagatzematge (més sobre això a l'article 4).
Aquest disseny ens permet escalar cada capa de manera independent horitzontalment. Els servidors backend no poden fer front, afegim una cosa més, després de tot, són aplicacions sense estat i, per tant, això es pot fer fins i tot automàticament. La memòria intermèdia d'estil Kafka no funciona: afegim més servidors i transferim-hi algunes de les particions del nostre tema. Clickhouse no ho pot gestionar, és impossible :) De fet, també connectarem els servidors i fragmentarem les dades.
Per cert, si voleu implementar la part opcional de les nostres especificacions tècniques i escalar en diferents geolocalitzacions, no hi ha res més senzill:
A cada geolocalització despleguem un equilibrador de càrrega amb aplicació i kafka. En general, n'hi ha prou amb 2 servidors d'aplicacions, 3 nodes kafka i un equilibrador de núvol, per exemple, cloudflare, que comprovarà la disponibilitat dels nodes d'aplicació i equilibrarà les sol·licituds per geolocalització en funció de l'adreça IP d'origen del client. Així, les dades enviades per un client nord-americà arribaran als servidors americans. I les dades d'Àfrica són a l'Àfrica.
Aleshores, tot és bastant senzill: fem servir l'eina de mirall del conjunt de Kafka i copiem totes les dades de totes les ubicacions al nostre centre de dades central situat a Rússia. Internament, analitzem les dades i les registrem a Clickhouse per a la seva posterior visualització.
Per tant, hem resolt l'arquitectura: comencem a sacsejar Yandex.Cloud!
Redacció d'una sol·licitud
Abans del núvol, encara heu de tenir una mica de paciència i escriure un servei bastant senzill per processar els esdeveniments entrants. Farem servir golang perquè s'ha demostrat molt bé com a llenguatge per escriure aplicacions de xarxa.
Després de passar una hora (potser un parell d'hores), obtenim alguna cosa com això: .
Quins són els punts principals que m'agradaria destacar aquí:
1. Quan inicieu l'aplicació, podeu especificar dos indicadors. Un és responsable del port on escoltarem les sol·licituds http entrants (-addr). El segon és per a l'adreça del servidor kafka on registrarem els nostres esdeveniments (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. L'aplicació utilitza la biblioteca sarama () per enviar missatges al clúster kafka. Immediatament establim la configuració orientada a la velocitat màxima de processament:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. La nostra aplicació també té un client prometheus integrat, que recull diverses mètriques, com ara:
- nombre de sol·licituds a la nostra aplicació;
- nombre d'errors en executar la sol·licitud (impossible llegir la sol·licitud de publicació, json trencat, impossible escriure a Kafka);
- temps de processament d'una sol·licitud del client, inclòs el temps per escriure un missatge a Kafka.
4. Tres punts finals que processa la nostra aplicació:
- /status: simplement torna bé per mostrar que estem vius. Encara que podeu afegir algunes comprovacions, com ara la disponibilitat del clúster Kafka.
- /metrics - segons aquesta URL, el client prometheus retornarà les mètriques que ha recollit.
- /post és el punt final principal on s'enviaran les sol·licituds POST amb json dins. La nostra aplicació comprova la validesa del json i, si tot està bé, escriu les dades al clúster Kafka.
Faré una reserva que el codi no és perfecte: es pot (i s'ha de completar!). Per exemple, podeu deixar d'utilitzar el net/http integrat i canviar al fasthttp més ràpid. O podeu guanyar temps de processament i recursos de CPU movent la comprovació de validesa de json a una etapa posterior, quan les dades es transfereixen de la memòria intermèdia al clúster de clics.
A més de la part de desenvolupament del problema, de seguida vam pensar en la nostra futura infraestructura i vam decidir desplegar la nostra aplicació mitjançant Docker. El Dockerfile final per crear l'aplicació és . En general, és força senzill, l'únic punt al qual m'agradaria parar atenció és el muntatge multietapa, que ens permet reduir la imatge final del nostre contenidor.
Primers passos al núvol
En primer lloc, registra't . Després d'omplir tots els camps necessaris, se'ns crearà un compte i se'ns donarà una subvenció per una determinada quantitat de diners, que es pot utilitzar per provar els serveis al núvol. Si voleu repetir tots els passos del nostre article, aquesta subvenció hauria de ser suficient per a vosaltres.
Després del registre, es crearà un núvol separat i un directori predeterminat, en el qual podeu començar a crear recursos al núvol. En general, a Yandex.Cloud, la relació dels recursos és així:
Podeu crear diversos núvols per a un compte. I dins del núvol, fer diferents directoris per a diferents projectes d'empresa. Podeu llegir més sobre això a la documentació - . Per cert, sovint m'hi referiré a continuació al text. Quan vaig muntar tota la infraestructura des de zero, la documentació m'ha ajudat més d'una vegada, així que us aconsello que l'estudieu.
Per gestionar el núvol, podeu utilitzar tant la interfície web com la utilitat de la consola - yc. La instal·lació es realitza amb una ordre (per a Linux i Mac Os):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashSi el vostre especialista en seguretat interna s'enfada per executar scripts des d'Internet, en primer lloc, podeu obrir l'script i llegir-lo i, en segon lloc, l'executem amb el nostre usuari, sense drets d'arrel.
Si voleu instal·lar un client per a Windows, podeu utilitzar les instruccions i després executar yc initper personalitzar-lo completament:
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:~ $En principi, el procés és senzill: primer heu d'obtenir un testimoni d'auth per gestionar el núvol, seleccioneu el núvol i la carpeta que utilitzareu.
Si teniu diversos comptes o carpetes dins del mateix núvol, podeu crear perfils addicionals amb paràmetres separats mitjançant yc config profile create i canviar entre ells.
A més dels mètodes anteriors, l'equip de Yandex.Cloud va escriure una molt bona per gestionar els recursos del núvol. Per la meva banda, vaig preparar un repositori git, on vaig descriure tots els recursos que es crearan com a part de l'article - . Ens interessa la branca mestra, clonem-la localment:
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/Totes les variables principals que s'utilitzen a terraform estan escrites al fitxer main.tf. Per començar, creeu un fitxer private.auto.tfvars a la carpeta terraform amb el contingut següent:
# 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 = ""Totes les variables es poden extreure de la llista yc config, ja que ja hem configurat la utilitat de la consola. Us recomano que afegiu immediatament private.auto.tfvars a .gitignore, per no publicar dades privades accidentalment.
A private.auto.tfvars també vam especificar dades de Cloudflare: per crear registres DNS i enviar el domini principal events.kis.im als nostres servidors. Si no voleu utilitzar cloudflare, elimineu la inicialització del proveïdor de cloudflare a main.tf i el fitxer dns.tf, que s'encarrega de crear els registres dns necessaris.
En el nostre treball combinarem els tres mètodes: la interfície web, la utilitat de la consola i el terraform.
Xarxes virtuals
Per ser honest, podeu ometre aquest pas, ja que quan creeu un núvol nou, automàticament tindreu una xarxa independent i 3 subxarxes creades, una per a cada zona de disponibilitat. Però encara ens agradaria fer una xarxa separada per al nostre projecte amb el seu propi adreçament. El diagrama general de com funciona la xarxa a Yandex.Cloud es mostra a la figura següent (sincerament extret de )
Per tant, creeu una xarxa comuna dins de la qual els recursos es poden comunicar entre ells. Per a cada zona de disponibilitat, es crea una subxarxa amb el seu propi adreçament i es connecta a la xarxa general. Com a resultat, tots els recursos del núvol es poden comunicar, fins i tot si es troben en zones de disponibilitat diferents. Els recursos connectats a diferents xarxes de núvol només es poden veure a través d'adreces externes. Per cert, com funciona aquesta màgia per dins, .
La creació de la xarxa es descriu al fitxer network.tf del repositori. Allà creem una xarxa privada comuna interna i hi connectem tres subxarxes en diferents zones de disponibilitat: interna-a (172.16.1.0/24), interna-b (172.16.2.0/24), interna-c (172.16.3.0/24). ).
Inicialitzar terraform i crear xarxes:
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.Genial! Hem creat la nostra xarxa i ara estem preparats per crear els nostres serveis interns.
Creació de màquines virtuals
Per provar l'aplicació, només haurem de crear dues màquines virtuals: necessitarem la primera per construir i executar l'aplicació, la segona per executar kafka, que utilitzarem per emmagatzemar els missatges entrants. I crearem una altra màquina on configurarem prometheus per supervisar l'aplicació.
Les màquines virtuals es configuraran amb ansible, així que abans d'iniciar terraform, assegureu-vos que teniu una de les últimes versions d'ansible. I instal·leu els rols necessaris amb la galàxia ansible:
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) $Dins de la carpeta ansible hi ha un exemple de fitxer de configuració .ansible.cfg que faig servir. Pot ser que sigui útil.
Abans de crear màquines virtuals, assegureu-vos que teniu ssh-agent en execució i una clau ssh afegit, en cas contrari, terraform no es podrà connectar a les màquines creades. Per descomptat, em vaig trobar amb un error a os x: . Per evitar que això torni a passar, afegiu una petita variable a env abans de llançar Terraform:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESA la carpeta amb terraform creem els recursos necessaris:
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 ...Si tot va acabar amb èxit (i hauria de ser), llavors tindrem tres màquines virtuals:
- build: una màquina per provar i crear una aplicació. Docker va ser instal·lat automàticament per Ansible.
- monitoring - una màquina de monitorització - prometheus & grafana instal·lada en ella. Inici de sessió / contrasenya estàndard: admin / admin
- kafka és una petita màquina amb kafka instal·lat, accessible al port 9092.
Assegurem-nos que estiguin tots al seu lloc:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Els recursos estan al seu lloc, i des d'aquí podem obtenir les seves adreces IP. Al llarg del que segueix, utilitzaré adreces IP per connectar-me mitjançant ssh i provar l'aplicació. Si teniu un compte de Cloudflare connectat a terraform, no dubteu a utilitzar noms DNS acabats de crear.
Per cert, quan es crea una màquina virtual, es dóna una IP interna i un nom DNS intern, de manera que podeu accedir als servidors de la xarxa per nom:
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 msAixò ens serà útil per indicar a l'aplicació el punt final amb kafk.
Muntatge de l'aplicació
Genial, hi ha servidors, hi ha una aplicació; només queda muntar-la i publicar-la. Per a la compilació utilitzarem la compilació docker habitual, però com a emmagatzematge d'imatges utilitzarem un servei de Yandex: registre de contenidors. Però primer és el primer.
Copiem l'aplicació a la màquina de compilació, iniciem sessió mitjançant ssh i muntem la imatge:
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:latestLa meitat de la batalla està acabada; ara podem comprovar la funcionalitat de la nostra aplicació llançant-la i enviant-la a 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) $L'aplicació va respondre amb èxit de la gravació i va indicar l'identificador de la partició i el desplaçament en què s'incloïa el missatge. Tot el que queda per fer és crear un registre a Yandex.Cloud i penjar-hi la nostra imatge (com fer-ho amb tres línies es descriu al fitxer registry.tf). Crea un emmagatzematge:
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.Hi ha diverses maneres d'autenticar-se al registre del contenidor: utilitzant un testimoni d'auth, un testimoni iam o una clau de compte de servei. Podeu trobar més detalls sobre aquests mètodes a la documentació. . Utilitzarem la clau del compte de servei, així que creem un compte:
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.Ara només queda fer-ne una clau:
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_2048Rebem informació sobre l'identificador del nostre emmagatzematge, transferim la clau i iniciem sessió:
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:~$Per pujar la imatge al registre, necessitem l'ID del registre del contenidor, l'agafem de la utilitat yc:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Després d'això, etiquetem la nostra imatge amb un nom nou i pugem:
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: 946Podem comprovar que la imatge s'ha carregat correctament:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Per cert, si instal·leu la utilitat yc en una màquina Linux, podeu utilitzar l'ordre
yc container registry configure-dockerper configurar Docker.
Conclusió
Hem fet molta feina i com a resultat:
- Hem creat l'arquitectura del nostre futur servei.
- Hem escrit una aplicació en golang que implementa la nostra lògica empresarial.
- El vam recollir i el vam abocar en un registre de contenidors privat.
A la següent part, passarem a les coses interessants: llançarem la nostra aplicació en producció i, finalment, llançarem la càrrega. No canvieu!
Aquest material es troba a la gravació de vídeo del taller obert REBRAIN & Yandex.Cloud: acceptem 10 sol·licituds per segon a Yandex Cloud -
Si esteu interessats a assistir a aquests esdeveniments en línia i fer preguntes en temps real, connecteu-vos a.
Ens agradaria donar un agraïment especial a Yandex.Cloud per l'oportunitat d'acollir aquest esdeveniment. Enllaç a ells -
Si necessiteu passar al núvol o teniu preguntes sobre la vostra infraestructura, .
PS Tenim 2 auditories gratuïtes al mes, potser el vostre projecte serà una d'elles.
Font: www.habr.com