Ola a todos, amigos!
* Este artigo está baseado no obradoiro aberto REBRAIN e Yandex.Cloud, se prefires ver o vídeo, podes atopalo nesta ligazón -
Recentemente tivemos a oportunidade de probar Yandex.Cloud en directo. Como queriamos investigar moito e moito, abandonamos inmediatamente a idea de lanzar un simple blog de Wordpress cunha base de nube - era demasiado aburrido. Despois de pensar un pouco, decidimos implementar algo similar a unha arquitectura de servizo de produción para recibir e analizar eventos en modo case en tempo real.
Estou absolutamente seguro de que a gran maioría das empresas en liña (e non só) recollen dalgún xeito unha montaña de información sobre os seus usuarios e as súas accións. Como mínimo, isto é necesario para tomar determinadas decisións; por exemplo, se xestionas un xogo en liña, podes consultar as estatísticas en que os usuarios de nivel quedan atascados con máis frecuencia e eliminar o teu xoguete. Ou por que os usuarios abandonan o teu sitio sen mercar nada (ola, Yandex.Metrica).
Entón, a nosa historia: como escribimos unha aplicación en golang, probamos kafka vs rabbitmq vs yqs, escribimos a transmisión de datos nun clúster de Clickhouse e visualizamos os datos usando yandex datalens. Por suposto, todo isto estivo aderezado con delicias de infraestrutura en forma de docker, terraform, gitlab ci e, por suposto, prometheus. Imos!
Gustaríame facer unha reserva inmediatamente de que non poderemos configurar todo dunha vez; para iso necesitaremos varios artigos da serie. Un pouco sobre a estrutura:
Parte 1 (está lendo). Decidiremos as especificacións e a arquitectura da solución, e tamén escribiremos unha aplicación en golang.
Parte 2. Lanzamos a nosa aplicación en produción, facémola escalable e probamos a carga.
Parte 3. Tentemos descubrir por que necesitamos almacenar as mensaxes nun búfer e non en ficheiros, e tamén comparemos os servizos de filas de kafka, rabbitmq e yandex.
Parte 4 Implementaremos un clúster Clickhouse, escribiremos un servizo de streaming para transferir datos do búfer alí e configuraremos a visualización en datalens.
Parte 5 Imos poñer toda a infraestrutura en forma correcta: configure ci/cd usando gitlab ci, conecte o seguimento e o descubrimento de servizos usando prometheus e consul.
TK
En primeiro lugar, imos formular os termos de referencia: o que queremos obter exactamente como resultado.
- Queremos ter un punto final como events.kis.im (kis.im é o dominio de proba que usaremos en todos os artigos), que debería recibir eventos mediante HTTPS.
- Os eventos son un simple json como: {“event”: “view”, “os”: “linux”, “browser”: “chrome”}. Na fase final engadiremos un pouco máis de campos, pero isto non terá un gran papel. Se queres, podes cambiar a protobuf.
- O servizo debe ser capaz de procesar 10 eventos por segundo.
- Debería ser posible escalar horizontalmente simplemente engadindo novas instancias á nosa solución. E sería bo que poidamos mover a parte frontal a diferentes xeolocalizacións para reducir a latencia das solicitudes dos clientes.
- Tolerancia a fallos. A solución debe ser o suficientemente estable e poder sobrevivir á caída de calquera parte (ata un número determinado, por suposto).
Arquitectura
En xeral, para este tipo de tarefas, hai tempo que se inventan arquitecturas clásicas que permiten un escalado eficiente. A figura mostra un exemplo da nosa solución.
Entón o que temos:
1. Á esquerda están os nosos dispositivos que xeran diversos eventos, xa sexan xogadores que completan un nivel nun xoguete nun smartphone ou que crean un pedido nunha tenda en liña a través dun navegador normal. Un evento, como se especifica na especificación, é un simple json que se envía ao noso punto final - events.kis.im.
2. Os dous primeiros servidores son equilibradores simples, as súas tarefas principais son:
- Estar sempre dispoñible. Para iso, podes usar, por exemplo, keepalived, que cambiará a IP virtual entre nodos en caso de problemas.
- Finalizar TLS. Si, cancelaremos o TLS neles. En primeiro lugar, para que a nosa solución cumpra coas especificacións técnicas e, en segundo lugar, para aliviar a carga de establecer unha conexión cifrada desde os nosos servidores backend.
- Equilibrar as solicitudes entrantes aos servidores backend dispoñibles. A palabra clave aquí é accesible. En base a isto, chegamos ao entendemento de que os equilibradores de carga deben poder supervisar os nosos servidores con aplicacións e deixar de equilibrar o tráfico aos nodos fallidos.
3. Despois dos equilibradores, temos servidores de aplicacións que executan unha aplicación bastante sinxela. Debería poder aceptar solicitudes entrantes a través de HTTP, validar o json enviado e poñer os datos nun búfer.
4. O diagrama mostra a kafka como un buffer, aínda que, por suposto, pódense utilizar outros servizos similares neste nivel. Compararemos Kafka, rabbitmq e yqs no terceiro artigo.
5. O penúltimo punto da nosa arquitectura é Clickhouse, unha base de datos en columnas que che permite almacenar e procesar unha gran cantidade de datos. Neste nivel, necesitamos transferir datos do búfer ao propio sistema de almacenamento (máis sobre isto no artigo 4).
Este deseño permítenos escalar cada capa de forma independente horizontalmente. Os servidores de backend non poden facer fronte -engademos unha cousa máis-, despois de todo, son aplicacións sen estado e, polo tanto, pódese facer incluso automaticamente. O búfer de estilo Kafka non funciona; engadímoslles máis servidores e trasladámoslles algunhas das particións do noso tema. Clickhouse non pode xestionalo, é imposible :) De feito, tamén conectaremos os servidores e dividiremos os datos.
Por certo, se queres implementar a parte opcional das nosas especificacións técnicas e escalar en diferentes xeolocalizacións, non hai nada máis sinxelo:
En cada xeolocalización implantamos un equilibrador de carga con aplicación e kafka. En xeral, son suficientes 2 servidores de aplicacións, 3 nodos kafka e un equilibrador de nube, por exemplo, cloudflare, que comprobará a dispoñibilidade dos nodos de aplicacións e equilibrará as solicitudes por xeolocalización en función do enderezo IP de orixe do cliente. Así, os datos enviados por un cliente estadounidense aterrarán en servidores estadounidenses. E os datos de África están en africano.
Entón, todo é bastante sinxelo: usamos a ferramenta de espello do conxunto de Kafka e copiamos todos os datos de todas as localizacións ao noso centro de datos central situado en Rusia. Internamente, analizamos os datos e rexistrámolos en Clickhouse para a súa posterior visualización.
Entón, solucionamos a arquitectura; empecemos a axitar Yandex.Cloud!
Redacción dunha aplicación
Antes da nube, aínda tes que ser un pouco paciente e escribir un servizo bastante sinxelo para procesar os eventos entrantes. Usaremos golang porque demostrou ser unha linguaxe moi ben para escribir aplicacións de rede.
Despois de pasar unha hora (quizais un par de horas), temos algo así: .
Cales son os puntos principais que me gustaría destacar aquí:
1. Ao iniciar a aplicación, pode especificar dúas bandeiras. Un é o responsable do porto no que escoitaremos as solicitudes http entrantes (-addr). O segundo é para o enderezo do servidor kafka onde gravaremos os nosos eventos (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. A aplicación usa a biblioteca sarama () para enviar mensaxes ao clúster kafka. Inmediatamente establecemos a configuración dirixida á máxima velocidade de procesamento:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. A nosa aplicación tamén ten un cliente prometheus integrado, que recolle varias métricas, como:
- número de solicitudes á nosa aplicación;
- número de erros ao executar a solicitude (imposible ler a solicitude de publicación, json roto, imposible escribir a Kafka);
- tempo de procesamento dunha solicitude do cliente, incluído o tempo de escribir unha mensaxe a Kafka.
4. Tres puntos finais que procesa a nosa solicitude:
- /status - simplemente volve ok para mostrar que estamos vivos. Aínda que pode engadir algunhas comprobacións, como a dispoñibilidade do clúster Kafka.
- /metrics - segundo este URL, o cliente de prometheus devolverá as métricas que recompilou.
- /post é o punto final principal onde se enviarán as solicitudes POST con json dentro. A nosa aplicación comproba a validez do json e, se todo está ben, escribe os datos no clúster de Kafka.
Vou facer unha reserva de que o código non é perfecto: pode (e debería!) completarse. Por exemplo, pode deixar de usar o net/http integrado e cambiar ao máis rápido http. Ou pode gañar tempo de procesamento e recursos da CPU movendo a comprobación de validez de json a unha fase posterior, cando os datos se transfiran desde o búfer ao clúster de clickhouse.
Ademais do lado do desenvolvemento do problema, de inmediato pensamos na nosa futura infraestrutura e decidimos implantar a nosa aplicación a través de Docker. O Dockerfile final para crear a aplicación é . En xeral, é bastante sinxelo, o único punto no que me gustaría prestar atención é a montaxe multietapa, que nos permite reducir a imaxe final do noso recipiente.
Primeiros pasos na nube
Primeiro de todo, rexistrarte . Despois de cubrir todos os campos necesarios, crearémonos unha conta e darémonos unha subvención por unha determinada cantidade de diñeiro, que se pode usar para probar os servizos na nube. Se queres repetir todos os pasos do noso artigo, esta subvención debería ser suficiente para ti.
Despois do rexistro, crearase unha nube separada e un directorio predeterminado, no que pode comezar a crear recursos na nube. En xeral, en Yandex.Cloud, a relación dos recursos é así:
Podes crear varias nubes para unha conta. E dentro da nube, fai diferentes directorios para diferentes proxectos da empresa. Podes ler máis sobre isto na documentación - . Por certo, a miúdo referireime a el a continuación no texto. Cando configurei toda a infraestrutura dende cero, a documentación axudoume máis dunha vez, polo que aconsello que o estudes.
Para xestionar a nube, pode usar tanto a interface web como a utilidade da consola - yc. A instalación realízase cun comando (para Linux e Mac Os):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashSe o teu especialista en seguridade interna está furioso por executar scripts desde Internet, en primeiro lugar, podes abrir o script e lelo e, en segundo lugar, executámolo baixo o noso usuario, sen dereitos de root.
Se queres instalar un cliente para Windows, podes usar as instrucións e despois executar yc initpara personalizala completamente:
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 principio, o proceso é sinxelo: primeiro cómpre obter un token de auth para xestionar a nube, seleccionar a nube e o cartafol que vai usar.
Se tes varias contas ou cartafoles na mesma nube, podes crear perfís adicionais con configuracións separadas mediante yc config profile create e cambiar entre eles.
Ademais dos métodos anteriores, o equipo de Yandex.Cloud escribiu un moi bo para xestionar recursos na nube. Pola miña banda, preparei un repositorio git, onde describín todos os recursos que se crearán como parte do artigo - . Interésanos a rama mestra, clonémola localmente:
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/Todas as variables principais que se usan en terraform están escritas no ficheiro main.tf. Para comezar, cree un ficheiro private.auto.tfvars no cartafol terraform co seguinte contido:
# 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 = ""Pódense sacar todas as variables da lista de configuración yc, xa que xa temos configurada a utilidade da consola. Aconsélloche que engada inmediatamente private.auto.tfvars a .gitignore, para non publicar accidentalmente datos privados.
En private.auto.tfvars tamén especificamos datos de Cloudflare: para crear rexistros DNS e proxy do dominio principal events.kis.im aos nosos servidores. Se non queres usar cloudflare, elimina a inicialización do provedor de cloudflare en main.tf e o ficheiro dns.tf, que se encarga de crear os rexistros dns necesarios.
No noso traballo combinaremos os tres métodos: a interface web, a utilidade da consola e terraform.
Redes virtuais
Para ser honesto, podes omitir este paso, xa que cando crees unha nova nube, terás automaticamente unha rede separada e 3 subredes creadas, unha para cada zona de dispoñibilidade. Pero aínda así gustaríanos facer unha rede separada para o noso proxecto co seu propio enderezo. O diagrama xeral de como funciona a rede en Yandex.Cloud móstrase na figura a continuación (sinceramente tomado de )
Así, crea unha rede común dentro da cal os recursos poden comunicarse entre si. Para cada zona de dispoñibilidade créase unha subrede co seu propio enderezo e conéctase á rede xeral. Como resultado, todos os recursos da nube que nel poden comunicarse, aínda que estean en zonas de dispoñibilidade diferentes. Os recursos conectados a diferentes redes na nube só poden verse a través de enderezos externos. Por certo, como funciona esta maxia por dentro, .
A creación da rede descríbese no ficheiro network.tf do repositorio. Alí creamos unha rede privada común interna e conectamos a ela tres subredes en diferentes zonas de dispoñibilidade: interna-a (172.16.1.0/24), interna-b (172.16.2.0/24), interna-c (172.16.3.0/24). ).
Inicializa terraform e crea redes:
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! Creamos a nosa rede e agora estamos preparados para crear os nosos servizos internos.
Creación de máquinas virtuais
Para probar a aplicación, só necesitaremos crear dúas máquinas virtuais: necesitaremos a primeira para construír e executar a aplicación, a segunda para executar kafka, que utilizaremos para almacenar as mensaxes entrantes. E crearemos outra máquina onde configuraremos prometheus para supervisar a aplicación.
As máquinas virtuais configuraranse mediante ansible, polo que antes de iniciar terraform, asegúrate de ter unha das últimas versións de ansible. E instala os papeis necesarios con ansible galaxy:
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) $Dentro do cartafol ansible hai un exemplo de ficheiro de configuración .ansible.cfg que eu uso. Pode ser útil.
Antes de crear máquinas virtuais, asegúrese de ter ssh-agent en execución e de engadir unha clave ssh, se non, terraform non poderá conectarse ás máquinas creadas. Por suposto, atopei un erro en os x: . Para evitar que isto volva ocorrer, engade unha pequena variable a env antes de iniciar Terraform:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESNo cartafol con terraform creamos os recursos necesarios:
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 ...Se todo rematou con éxito (e debería ser), entón teremos tres máquinas virtuais:
- build - unha máquina para probar e construír unha aplicación. Docker foi instalado automaticamente por Ansible.
- monitoring - unha máquina de monitorización - prometheus & grafana instalada nela. Estándar de inicio de sesión/contrasinal: admin/admin
- kafka é unha pequena máquina con kafka instalado, accesible no porto 9092.
Asegurémonos de que estean todos no seu lugar:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Os recursos están no seu lugar, e desde aquí podemos obter os seus enderezos IP. Ao longo do que segue utilizarei enderezos IP para conectarme mediante ssh e probar a aplicación. Se tes unha conta de Cloudflare conectada a terraform, non dubides en usar nomes DNS recén creados.
Por certo, ao crear unha máquina virtual, dáse unha IP interna e un nome DNS interno, para que poida acceder aos servidores da rede polo nome:
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 msIsto será útil para indicarlle á aplicación o punto final con kafk.
Montaxe da aplicación
Xenial, hai servidores, hai unha aplicación, só queda montala e publicala. Para a compilación usaremos a compilación docker habitual, pero como almacenamento de imaxes usaremos un servizo de Yandex: rexistro de contedores. Pero primeiro o primeiro.
Copiamos a aplicación na máquina de compilación, iniciamos sesión mediante ssh e montamos a imaxe:
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:latestA metade da batalla está feita; agora podemos comprobar a funcionalidade da nosa aplicación lanzándoa e enviándoa 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) $A aplicación respondeu con éxito da gravación e indicando o id da partición e offset no que se incluíu a mensaxe. Todo o que queda por facer é crear un rexistro en Yandex.Cloud e cargar alí a nosa imaxe (como facelo usando tres liñas descríbese no ficheiro registry.tf). Crear un almacenamento:
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.Hai varias formas de autenticarse no rexistro de contedores: usando un token de auth, un token iam ou unha clave de conta de servizo. Podes atopar máis detalles sobre estes métodos na documentación. . Usaremos a clave da conta de servizo, polo que creamos unha conta:
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.Agora só queda facerlle unha chave:
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_2048Recibimos información sobre o ID do noso almacenamento, transferimos a clave e iniciamos sesión:
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:~$Para cargar a imaxe ao rexistro, necesitamos o ID do rexistro do contedor, tomámolo da utilidade yc:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Despois diso, etiquetamos a nosa imaxe cun novo nome e subimos:
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: 946Podemos verificar que a imaxe se cargou correctamente:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Por certo, se instalas a utilidade yc nunha máquina Linux, podes usar o comando
yc container registry configure-dockerpara configurar docker.
Conclusión
Fixemos moito traballo e como resultado:
- Creamos a arquitectura do noso futuro servizo.
- Escribimos unha aplicación en golang que implementa a nosa lóxica empresarial.
- Recollimos e vertemos nun rexistro privado de contedores.
Na seguinte parte, pasaremos ás cousas interesantes: lanzaremos a nosa aplicación en produción e, finalmente, lanzaremos a carga nela. Non cambies!
Este material está na gravación de vídeo do obradoiro aberto REBRAIN e Yandex.Cloud: aceptamos 10 solicitudes por segundo en Yandex Cloud -
Se estás interesado en asistir a este tipo de eventos en liña e facer preguntas en tempo real, conéctate a.
Queremos darlle un agradecemento especial a Yandex.Cloud pola oportunidade de organizar un evento deste tipo. Ligazón a eles -
Se precisas pasar á nube ou tes dúbidas sobre a túa infraestrutura, .
PS Temos 2 auditorías gratuítas ao mes, quizais o teu proxecto sexa unha delas.
Fonte: www.habr.com