Aceitamos 10.000 eventos em Yandex.Cloud. Parte 1

Olá a todos, amigos!



* Este artigo foi escrito com base no workshop aberto REBRAIN & Yandex.Cloud, se você gosta de assistir ao vídeo, pode encontrá-lo neste link - https://youtu.be/cZLezUm0ekE



Recentemente tivemos a oportunidade de sentir o Yandex.Cloud ao vivo. Como queríamos sentir isso há muito tempo e com firmeza, abandonamos imediatamente a ideia de lançar um blog simples de wordpress com base em nuvem - é muito chato. Após alguma deliberação, decidimos implantar algo semelhante à arquitetura de produção de um serviço para receber e analisar eventos em modo quase em tempo real.



Estou absolutamente certo de que a grande maioria das empresas online (e não apenas), de uma forma ou de outra, coleta uma montanha de informações sobre seus usuários e suas ações. No mínimo, isso é necessário para tomar certas decisões - por exemplo, se você estiver gerenciando um jogo online - você pode ver estatísticas em que nível os usuários têm maior probabilidade de travar e excluir seu brinquedo. Ou por que os usuários saem do seu site sem comprar nada (olá, Yandex.Metrica).



Então, nossa história: como escrevemos um aplicativo em golang, testamos kafka vs rabbitmq vs yqs, escrevemos streaming de dados para um cluster Clickhouse e visualizamos dados usando datalens yandex. Naturalmente, tudo isso foi temperado com delícias de infraestrutura na forma de docker, terraform, gitlab ci e, é claro, prometheus. Vamos!



Gostaria de fazer uma reserva desde já que não poderemos configurar tudo de uma só vez - para isso precisamos de vários artigos da série. Um pouco sobre a estrutura:



Parte 1 (você está lendo). Vamos definir a especificação técnica e arquitetura da solução, e também escrever uma aplicação em golang.

Parte 2. Lançamos nosso aplicativo para produção, o tornamos escalonável e testamos a carga.

Parte 3. Vamos tentar descobrir por que precisamos armazenar mensagens em um buffer, e não em arquivos, e também comparar os serviços de fila kafka, rabbitmq e yandex entre si.

Parte 4. Vamos implantar o cluster Clickhouse, escrever streaming para transferir dados do buffer de lá, configurar a visualização em datalens.

Parte 5. Vamos colocar toda a infraestrutura na forma adequada - configurar ci / cd usando gitlab ci, conectar o monitoramento e a descoberta de serviço usando prometheus e consul.



TK



Primeiro, formularemos os termos de referência - o que exatamente queremos obter na saída.



  1. Queremos ter um endpoint do formulário events.kis.im (kis.im é o domínio de teste que usaremos em todos os artigos), que deve aceitar eventos usando HTTPS.
  2. Os eventos são um json simples no formato: {"event": "view", "os": "linux", "browser": "chrome"}. No estágio final, adicionaremos um pouco mais de campos, mas isso não terá um grande papel. Se desejar, você pode alternar para protobuf.
  3. O serviço deve ser capaz de processar 10.000 eventos por segundo.
  4. Ele deve ser capaz de escalar horizontalmente simplesmente adicionando novas instâncias à nossa solução. E será bom se pudermos mover o front-end para diferentes geolocalização para reduzir a latência para solicitações do cliente.
  5. Tolerância ao erro. A solução deve ser estável o suficiente e ser capaz de sobreviver quando alguma peça cair (até uma certa quantidade, é claro).


Arquitetura



Em geral, para este tipo de tarefas, arquiteturas clássicas foram inventadas há muito tempo que permitem que você dimensione com eficácia. A figura mostra um exemplo de nossa solução.







Assim, o que temos:



1. À esquerda estão os nossos dispositivos que geram vários eventos, seja a passagem do nível dos jogadores num brinquedo num smartphone ou a criação de uma encomenda numa loja online através de um navegador normal. O evento, conforme indicado no TOR, é um json simples que é enviado ao nosso endpoint - events.kis.im.



2. Os primeiros dois servidores são balanceadores simples, suas principais tarefas são:



  • . , , keepalived, IP .
  • TLS. , TLS . -, , -, , backend .
  • backend . — . , , load balancer’ .


3. Depois dos balanceadores, temos os servidores de aplicativos executando um aplicativo bastante simples. Ele deve ser capaz de aceitar solicitações HTTP de entrada, validar o json enviado e armazenar os dados em um buffer.



4. O diagrama mostra o kafka como um buffer, embora, é claro, outros serviços semelhantes possam ser usados ​​nesse nível. Compararemos Kafka, rabbitmq e yqs no terceiro artigo.



5. O penúltimo ponto de nossa arquitetura é Clickhouse - um banco de dados colunar que permite armazenar e processar uma grande quantidade de dados. Neste nível, precisamos transferir dados do buffer para, de fato, o sistema de armazenamento (sobre isso - no artigo 4).



Esse arranjo nos permite dimensionar independentemente cada camada horizontalmente. Os servidores de back-end não suportam - vamos adicionar mais - porque são aplicativos sem estado e, portanto, isso pode ser feito até mesmo no modo automático. Ele não puxa um buffer na forma de um kafka - adicionaremos mais servidores e transferiremos algumas das partições de nosso tópico para eles. O clickhouse falha - é impossível :) Na verdade, também vamos descartar os servidores e compartilhar os dados.



A propósito, se você deseja implementar a parte opcional de nossa especificação técnica e escalonar em diferentes geolocalização, nada mais fácil:







Em cada geolocalização, implantamos um balanceador de carga com aplicativo e kafka. Em geral, são suficientes 2 servidores de aplicativos, 3 nós kafka e um balanceador de nuvem, por exemplo, cloudflare, que irá verificar a disponibilidade dos nós de aplicativos e balancear as solicitações por geolocalização com base no endereço IP original do cliente. Assim, os dados enviados pelo cliente americano pousarão nos servidores americanos. E dados da África - na África.



Então, tudo é muito simples - usamos a ferramenta de espelho do conjunto kafka e copiamos todos os dados de todos os locais para nosso data center central localizado na Rússia. Dentro, analisamos os dados e os gravamos em Clickhouse para visualização subsequente.



Então, descobrimos a arquitetura - vamos começar a sacudir o Yandex.Cloud!



Escrevendo um aplicativo



Antes da nuvem, você ainda tem que aguentar um pouco e escrever um serviço bastante simples para processar eventos de entrada. Usaremos o golang, porque ele se provou muito bem como uma linguagem para escrever aplicativos de rede.



Depois de passar uma hora (talvez algumas horas), obtemos algo assim: https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/main.go .



Quais são os principais pontos que eu gostaria de observar:



1. Ao iniciar o aplicativo, você pode especificar dois sinalizadores. Um é responsável pela porta na qual escutaremos as solicitações HTTP de entrada (-addr). O segundo é para o endereço do servidor kafka onde registraremos nossos eventos (-kafka):



addr     = flag.String("addr", ":8080", "TCP address to listen to")
kafka    = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)


2. O aplicativo usa a biblioteca sarama ( [] github.com/Shopify/sarama ) para enviar mensagens ao cluster kafka. Definimos imediatamente as configurações com foco na velocidade máxima de processamento:



config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true


3. Além disso, nosso aplicativo tem um cliente prometheus integrado que coleta várias métricas, como:



  • o número de solicitações ao nosso aplicativo;
  • o número de erros ao executar o pedido (é impossível ler o pedido de postagem, json quebrado, é impossível escrever no kafka);
  • tempo de processamento de uma solicitação de um cliente, incluindo o tempo de gravação de uma mensagem para kafka


4. Três endpoints que nosso aplicativo processa:



  • / status - basta retornar ok para mostrar que estamos vivos. Embora você possa adicionar algumas verificações, como a disponibilidade do cluster Kafka.
  • / metrics - de acordo com este url, o cliente prometheus retornará as métricas que coletou.
  • /post — endpoint, POST json . json — -.


Vou fazer uma reserva de que o código não é perfeito - pode (e deve!) Ser concluído. Por exemplo, você pode parar de usar o net / http integrado e mudar para o fasthttp mais rápido. Ou você pode ganhar tempo de processamento e recursos de CPU levando a verificação de validação json para um estágio posterior - quando os dados serão transferidos do buffer para o cluster clickhouse.



Além do lado do desenvolvimento do problema, pensamos imediatamente em nossa infraestrutura futura e decidimos implantar nosso aplicativo via docker. O Dockerfile final para construir o aplicativo é https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/Dockerfile . Em geral é bastante simples, o único ponto que quero chamar a atenção é a montagem multiestágio, que nos permite reduzir a imagem final do nosso container.



Primeiros passos na nuvem



Em primeiro lugar, nos registramos em cloud.yandex.ru . Depois de preencher todos os campos obrigatórios, criaremos uma conta e concederemos uma concessão de uma certa quantia em dinheiro que pode ser usada para testar serviços em nuvem. Se você quiser repetir todas as etapas do nosso artigo, esta concessão deve ser suficiente para você.



Após o registro, uma nuvem separada e um diretório padrão serão criados para você, no qual você pode começar a criar recursos de nuvem. Em geral, em Yandex.Cloud, a relação de recursos é a seguinte:







Você pode criar várias nuvens para uma conta. E dentro da nuvem, crie diferentes diretórios para diferentes projetos da empresa. Você pode ler mais sobre isso na documentação - https://cloud.yandex.ru/docs/resource-manager/concepts/resources-hierarchy... A propósito, abaixo no texto irei freqüentemente me referir a ele. Quando montei toda a infraestrutura do zero, a documentação me ajudou mais de uma vez, então aconselho você a estudar.



Para gerenciar a nuvem, você pode usar a interface da web e o utilitário de console - yc. A instalação é realizada com um comando (para Linux e Mac Os):



curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash


Se um oficial de segurança interna estava furioso com a execução de scripts da Internet, então, em primeiro lugar, você pode abrir o script e lê-lo e, em segundo lugar, nós o executamos sob nosso usuário - sem direitos de root.



Se você deseja instalar o cliente para Windows, pode usar as instruções aqui e seguir yc initpara configurá-lo 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:~ $


Em princípio, o processo é simples - primeiro você precisa obter o token oauth para gerenciamento de nuvem, selecionar a nuvem e a pasta que você usará.



Se você tiver várias contas ou pastas na mesma nuvem, poderá criar perfis adicionais com configurações separadas por meio de yc config profile create e alternar entre eles.



Além dos métodos acima, a equipe Yandex.Cloud escreveu um plug-in de terraform muito bom para gerenciar recursos de nuvem. De minha parte, preparei um repositório git, onde descrevi todos os recursos que serão criados no âmbito do artigo - https://github.com/rebrainme/yandex-cloud-events/ . Estamos interessados ​​no branch master, vamos cloná-lo 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 variáveis ​​principais usadas no terraform são escritas no arquivo main.tf. Para começar, crie um arquivo private.auto.tfvars na pasta terraform com o seguinte conteúdo:



# 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 = ""


Todas as variáveis ​​podem ser obtidas da lista de configuração yc, uma vez que já configuramos o utilitário do console. Aconselho você a adicionar private.auto.tfvars imediatamente a .gitignore para não publicar dados privados inadvertidamente.



Em private.auto.tfvars, também especificamos dados do Cloudflare - para a criação de registros DNS e proxy do domínio principal events.kis.im para nossos servidores. Se você não quiser usar o cloudflare, remova a inicialização do provedor cloudflare em main.tf e o arquivo dns.tf, que é responsável por criar os registros dns necessários.



Em nosso trabalho, combinaremos todos os três métodos - a interface da web, o utilitário do console e o terraform.



Redes virtuais



Honestamente, esta etapa pode ser ignorada, porque ao criar uma nova nuvem, você terá automaticamente uma rede separada e 3 sub-redes - uma para cada zona de disponibilidade. Ainda assim, gostaria de fazer uma rede separada para nosso projeto com endereçamento próprio. O esquema geral da rede em Yandex.Cloud é mostrado na figura abaixo (tirado honestamente de https://cloud.yandex.ru/docs/vpc/concepts/ )







Portanto, você cria uma rede comum dentro da qual os recursos podem se comunicar uns com os outros. Para cada zona de disponibilidade, é feita uma sub-rede com endereçamento próprio e conectada à rede pública. Como resultado, todos os recursos de nuvem nele podem se comunicar, mesmo estando em zonas de disponibilidade diferentes. Recursos conectados a diferentes redes em nuvem só podem se ver por meio de endereços externos. Aliás, como essa magia funciona por dentro foi bem descrito no Habré .



A criação da rede é descrita no arquivo network.tf do repositório. Lá, criamos uma rede privada comum interna e conectamos a ela três sub-redes em diferentes zonas de disponibilidade - internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24 )



Inicializamos o terraform e criamos 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.


Excelente! Fizemos nossa rede e agora estamos prontos para criar nossos serviços internos.



Criação de máquinas virtuais



Para testar o aplicativo, bastará criarmos duas máquinas virtuais - precisaremos da primeira para construir e executar o aplicativo, a segunda - para executar o kafka, que usaremos para armazenar as mensagens recebidas. E criaremos outra máquina, onde configuraremos o prometheus para monitorar o aplicativo.



As máquinas virtuais serão configuradas usando o ansible, portanto, antes de iniciar o terraform, certifique-se de ter uma das versões mais recentes do ansible. E instale as funções necessárias com 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) $


Dentro da pasta ansible, há um arquivo de configuração .ansible.cfg de amostra que estou usando. Talvez seja útil.



Antes de criar máquinas virtuais, certifique-se de ter o ssh-agent rodando e uma chave ssh adicionada, caso contrário, o terraform não será capaz de se conectar às máquinas criadas. Eu me deparei com um bug no OS x, é claro: https://github.com/ansible/ansible/issues/32499#issuecomment-341578864 . Para evitar a repetição dessa história, adicione uma pequena variável a env antes de iniciar o Terraform:



vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES


Crie os recursos necessários na pasta terraform:



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 tudo terminou bem (e deve ser), teremos três máquinas virtuais:



  1. build - uma máquina para testar e construir um aplicativo. O Docker foi instalado automaticamente pelo ansible.
  2. monitoramento - máquina para monitoramento - prometheus & grafana está instalado nele. Login / senha é padrão: admin / admin
  3. kafka é um carro pequeno com kafka instalado, disponível na porta 9092.


Vamos ter certeza de que estão todos no 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ão disponíveis e, a partir daqui, podemos obter seus endereços IP. Em todos os lugares abaixo, vou usar endereços IP para me conectar via ssh e testar o aplicativo. Se você tiver uma conta cloudflare conectada ao terraform, sinta-se à vontade para usar os nomes DNS recém-criados.

A propósito, ao criar uma máquina virtual, um ip interno e um nome DNS interno são emitidos, para que você possa se referir aos servidores dentro da rede por nomes:



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 ms


Isso será útil para indicarmos ao aplicativo um endpoint com kafk.



Juntando o aplicativo



Ótimo, existem servidores, existe um aplicativo - tudo o que resta é coletá-lo e publicá-lo. Para a montagem, usaremos o build usual do docker, mas como armazenamento de imagens, usaremos o serviço do Yandex - o registro do contêiner. Mas as primeiras coisas primeiro.



Copie o aplicativo para a máquina de construção, vá para ssh e colete a imagem:



vozerov@mba:~/events/terraform (master) $ cd ..
vozerov@mba:~/events (master) $ rsync -av app/ ubuntu@84.201.132.3: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:latest


Metade da batalha acabou - agora você pode verificar a funcionalidade de nosso aplicativo executando-o e apontando para 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) $


O aplicativo respondeu com o sucesso da gravação e indicando o id da partição e o deslocamento em que a mensagem caiu. A única coisa a fazer é criar um registro em Yandex.Cloud e carregar nossa imagem lá (como fazer isso usando três linhas está descrito no arquivo registry.tf). Criamos um repositório:



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.


Existem várias maneiras de autenticar no registro do contêiner - usando token oauth, token iam ou chave de conta de serviço. Para obter mais informações sobre esses métodos, consulte a documentação https://cloud.yandex.ru/docs/container-registry/operations/authentication . Usaremos a chave da conta de serviço, portanto, criamos uma 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 resta fazer uma chave para ele:



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_2048


Recebemos informações sobre a id do nosso armazenamento, vire a chave e faça login:



vozerov@mba:~/events/terraform (master) $ scp key.json ubuntu@84.201.132.3:
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 carregar a imagem no registro, precisamos do ID do registro do contêiner, obtido do utilitário yc:



vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"


Depois disso, marcamos nossa imagem com um novo nome e carregamos:



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: 946


Podemos verificar se a imagem foi inicializada com sucesso:



vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
|          ID          |            NAME             |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+


A propósito, se você instalar o utilitário yc em uma máquina Linux, você pode usar o comando



yc container registry configure-docker


para configuração do docker.



Conclusão



Fizemos um trabalho excelente e difícil e, como resultado:



  1. .
  2. golang, -.
  3. container registry.


Na próxima parte, passaremos para a parte interessante - colocaremos nosso aplicativo em produção e, finalmente, lançaremos a carga nele. Não mude!



Este material está no vídeo do workshop aberto REBRAIN & Yandex.Cloud: Aceitamos 10.000 solicitações por segundo no Yandex Cloud - https://youtu.be/cZLezUm0ekE





Se você estiver interessado em participar de tais eventos online e fazer perguntas em tempo real, conecte-se ao canal DevOps por REBRAIN .



Gostaríamos de agradecer especialmente a Yandex.Cloud pela oportunidade de realizar tal evento. Um link para eles é https://cloud.yandex.ru/prices



Se você precisar mudar para a nuvem ou tiver dúvidas sobre sua infraestrutura, fique à vontade para deixar uma solicitação .



P.S. 2 , , .



All Articles