Здравейте на всички, приятели!
* Тази статия е написана вдъхновена от открития практикум REBRAIN & Yandex.Cloud. Ако предпочитате да гледате видео, можете да го намерите на този линк —
Наскоро имахме възможност да опитаме Яндекс.Облако на живо. Тъй като искахме да опитаме дълго и обстойно, веднага се отказахме от идеята да стартираме прост wordpress блог с облачна база — твърде скучно. След кратки размисли решихме да развернем нещо, което прилича на продукционна архитектура на услуга за прием и анализ на събития в near real time режим.
Абсолютно съм уверен, че огромното мнозинство от онлайн (и не само) бизнеси по един или друг начин събират куп информация за своите потребители и техните действия. Минимум, това е необходимо за вземане на определени решения — например, ако управлявате онлайн игра — можете да видите статистиката, на кой етап потребителите най-често затъват и изтриват играта ви. Или защо потребителите напускат сайта ви, без да купят нищо (привет, Яндекс.Метрика).
И така, нашата история: как написахме приложение на golang, тествали jsme kafka срещу rabbitmq срещу yqs, писахме стрийминг на данни в Clickhouse кластер и визуализирахме данните с помощта на yandex datalens. Естествено, всичко това беше подправено с инфраструктурни изненади под формата на docker, terraform, gitlab ci и, разбира се, prometheus. Да започнем!
Веднага искам да уточня, че не можем да настроим всичко за един такт — за това ще ни трябват няколко статии в серия. Малко за структурата:
1 част (вие я четете). Ще определим ТЗ и архитектура на решението, а също така ще напишем приложение на golang.
2 част. Изпускаме приложението на продукция, правим го мащабируемо и тестваме натоварването.
3 част. Ще се опитаме да разберем защо трябва да съхраняваме съобщения в буфер, а не в файлове, а също така ще сравним kafka, rabbitmq и yandex queue service помежду им.
4 част. Ще развернем Clickhouse кластер, ще пишем стрийминг за прехвърляне на данни от буфера там, ще настроим визуализация в datalens.
5 част. Ще приведем цялата инфраструктура в ред — ще настроим ci/cd, използвайки gitlab ci, ще свържем мониторинг и service discovery с помощта на prometheus и consul.
ТЗ
Първо, ще формулираме техническото задание — какво точно искаме да получим на изхода.
- Искаме да имаме endpoint вида events.kis.im (kis.im — тестов домейн, който ще използваме през всички статии), който трябва да приема събития чрез HTTPS.
- Събитията са проста json структура: {"event": "view", "os": "linux", "browser": "chrome"}. На финалния етап ще добавим малко повече полета, но това няма да е от голямо значение. Ако желаете, можете да преминете на protobuf.
- Сервисът трябва да може да обработва 10 000 събития в секунда.
- Трябва да има възможност за хоризонтално мащабиране — чрез просто добавяне на нови инстанции в нашето решение. И ще е добре, ако можем да изнесем фронт частта в различни геолокации, за да намалим закъснението при запитвания от клиенти.
- Отказоустойчивост. Решението трябва да бъде достатъчно стабилно и да може да оцелее при падането на произволни части (до определен брой, разбира се).
Архитектура
Всъщност, за такъв тип задачи отдавна са измислени класически архитектури, които позволяват ефективно мащабиране. На изображението е показан пример на нашето решение.
И така, какво имаме:
1. Вляво са показани нашите устройства, които генерират различни събития, било то преминаване на нива на играчите в игра на смартфон или създаване на поръчка в интернет магазин чрез обикновен браузър. Събитието, както е посочено в ТЗ, е прост json, който се изпраща на нашия endpoint — events.kis.im.
2. Първите два сървъра са простички балансировачи, основните им задачи са:
- Да бъдат постоянно налични. За това можем да използваме, например, keepalived, който ще превключва виртуалния IP между нодовете при проблеми.
- Да терминират TLS. Да, ще терминираме TLS именно на тях. Първо, за да нашето решение отговаря на ТЗ, а второ, за да свалим натоварването по установяване на криптирано връзка от нашите back-end сървъри.
- Да балансират входящите запитвания към наличните back-end сървъри. Ключовото слово тук е налични. На базата на това стигаме до разбирането, че балансирите трябва да умеят да наблюдават нашите сървъри с приложенията и да спрат да балансират трафика към падналите нодове.
3. Зад балансирите имаме application сървъри, на които е инсталирано достатъчно просто приложение. То трябва да може да приема входящи запитвания по HTTP, да валидира изпратения json и да съхранява данните в буфер.
4. Като буфер в схемата е изобразена kafka, въпреки че на това ниво могат да се използват и други подобни услуги. Ще сравним Kafka, rabbitmq и yqs в третата статия.
5. Предпоследната точка в архитектурата ни е Clickhouse — колонообразна база данни, която позволява съхранението и обработката на огромно количество данни. На това ниво е необходимо да прехвърлим данните от буфера в самата система за съхранение (за това ще говорим в четвъртата статия).
Тази схема ни позволява независимо хоризонтално да мащабираме всеки слой. Ако задните сървъри не се справят — добавяме още — тъй като те са stateless приложения, следователно, това може да се направи дори автоматично. Ако буферът в вида на Kafka не се справя — добавяме още сървъри и прехвърляме част от партициите на нашия топик на тях. Ако Clickhouse не се справя — това е невъзможно 🙂 Всъщност, ще добавим сървъри и ще шардируем данните.
Между другото, ако искате да реализирате опционалната част на нашето ТЗ и да направите мащабиране в различни геолокации, няма нищо по-лесно:
Във всяка геолокация разгръщаме load balancer с приложение и Kafka. Общо взето, достатъчни са 2 приложения, 3 Kafka възли и облачен балансировач, например, Cloudflare, който ще проверява достъпността на приложенията и ще балансира заявките по геолокации на базата на изходящия IP адрес на клиента. Така данните, изпратени от американски клиент, ще се обработват на американски сървъри. А данните от Африка — на африканските.
Следващото е абсолютно просто — използваме mirror tool от комплекта на Kafka и копираме всичките данни от всички локации в нашия централен дата център, разположен в Русия. Вътре разбирано обработваме данните и ги записваме в Clickhouse за последваща визуализация.
И така, разбрахме архитектурата — започваме да се справяме с Yandex.Cloud!
Пишем приложение
Още малко ще трябва да почакате преди Облака и да напишем достатъчно прост сервиз за обработка на входящи събития. Ще използваме Golang, защото той се е доказал много добре като език за писане на мрежови приложения.
След като прекараме един час (може би и два) време, получаваме нещо подобно: .
Кои са основните моменти, които би следвало да се отбележат тук:
1. При стартиране на приложението можете да зададете два флага. Единият отговаря за порта, на който ще слушаме входящи http заявки (-addr). Вторият — за адреса на kafka сървъра, където ще записваме нашите събития (-kafka):
addr = flag.String("addr", ":8080", "TCP адрес за слушане")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka крайни точки")2. Приложението използва библиотеката sarama () за изпращане на съобщения в kafka клъстера. Незабавно зададохме настройки, ориентирани към максимална скорост на обработка:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Също така в нашето приложение е вграден клиент prometheus, който събира различни метрики, като:
- броя на заявките към нашето приложение;
- броя на грешките при изпълнението на заявка (невъзможност за прочит на post заявка, повреден json, невъзможност за запис в кафка);
- времето за обработка на една заявка от клиента, включително времето за запис на съобщението в кафка.
4. Три крайни точки, които обработва нашето приложение:
- /status — просто возвращаем ok, чтобы показать, что мы живы. Хотя можно и добавить некоторые проверки, типа доступности кафка кластера.
- /metrics — по этому url prometheus client будет возвращать собранные им метрики.
- /post — основной endpoint, куда будут приходить POST запросы с json внутри. Наше приложение проверяет json на валидность и если все ок — записывает данные в кафка-кластер.
Искам да кажа, че кодът не е идеален — може (и трябва!) да бъде усъвършенстван. Например, можете да се откажете от вграденото net/http и да преминете към по-бързо fasthttp. Или да спестите време за обработка и cpу ресурси, като прехвърлите проверката на валидността на json на по-късен етап — когато данните бъдат прехвърляни от буфера в клъстера на clickhouse.
Освен разработческата страна на въпроса, ние вече помислихме за нашата бъдеща инфраструктура и взехме решение да разгръщаме нашето приложение чрез docker. Крайният Dockerfile за изграждане на приложението — . Общото му е достатъчно просто, единственото нещо, на което искам да обърна внимание, е multistage изграждането, което позволява да намалим крайния образ на контейнера.
Първи стъпки в облака
Първо се регистрираме на . След попълване на всички необходими полета ще ни създадат акаунт и ще ни предоставят грант на определена сума, която може да се използва за тестване на облачните услуги. Ако решите да повторите всички стъпки от нашата статия, този грант би трябвало да ви бъде достатъчен.
След регистрацията за вас ще бъде създадено отделно облако и каталог default, в който можете да започнете да създавате облачни ресурси. Всъщност, в Yandex.Cloud взаимовръзката на ресурсите изглежда по следния начин:
С един акаунт можете да създадете няколко облака. А вътре в облака можете да направите различни каталози за различни проекти на компанията. Повече подробности можете да прочетете в документацията — . Между другото, по-долу в текста ще се позовавам на него често. Когато конфигурирах цялата инфраструктура от нулата — документацията ми помагаше много пъти, така че съветвам да я изучите.
За управление на облака можете да използвате както уеб интерфейс, така и конзолна утилита — yc. Инсталацията се извършва с една команда (за Linux и Mac Os):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashАко вътре във вас се е разразил вътрешен защитник относно стартирането на скриптове от интернет — на първо място, можете да отворите скрипта и да го прочетете, а на второ — ние го стартираме под собствен потребител — без права на root.
Ако искате да инсталирате клиента за Windows, можете да се възползвате от инструкциите и след това да изпълните yc init, за да го настроите напълно:
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:~ $В принципе, процесът не е сложен — първо трябва да получите oauth токен за управление на облака, после да изберете облака и папката, която ще използвате.
Ако имате няколко акаунта или папки вътре в един облак, можете да създадете допълнителни профили с отделни настройки чрез yc config profile create и да превключвате между тях.
Освен изброените по-горе методи, екипът на Яндекс.Облака е написал много добър за управление на облачни ресурси. От своя страна, аз подготвих git-репозитори, където описах всички ресурси, които ще бъдат създадени в рамките на статията — . Интересува ни клонът master, нека да го клонираме локално:
vozerov@mba:~ $ git clone https://github.com/rebrainme/yandex-cloud-events/ events
Клониране в 'events'...
remote: Изброяване на обекти: 100, готово.
remote: Преброяване на обекти: 100% (100/100), готово.
remote: Компресиране на обекти: 100% (68/68), готово.
remote: Общо 100 (delta 37), повторно използвани 89 (delta 26), пак-реуиз 0
Получаване на обекти: 100% (100/100), 25.65 KiB | 168.00 KiB/s, готово.
Разрешаване на делти: 100% (37/37), готово.
vozerov@mba:~ $ cd events/terraform/Всички основни променливи, които се използват в terraform, са записани в файла main.tf. За да започнете работа, създайте в папката terraform файла private.auto.tfvars с следното съдържание:
# 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 = ""Всички променливи можете да вземете от yc config list, тъй като конзолната утилита вече е настроена. Препоръчвам веднага да добавите private.auto.tfvars в .gitignore, за да не публикувате по погрешка лични данни.
В private.auto.tfvars също сме указали данните от Cloudflare — за създаване на dns-записи и проксирване на основния домейн events.kis.im на нашите сървъри. Ако не искате да използвате cloudflare, изтрийте инициализацията на провайдера cloudflare в main.tf и файла dns.tf, който отговаря за създаването на необходимите dns записи.
В работата си ще комбинираме всичките три метода — и уеб-интерфейс, и конзолна утилита, и terraform.
Виртуални мрежи
Честно казано, тази стъпка можеше и да се пропусне, тъй като при създаване на ново облако автоматично ще създадете отделна мрежа и 3 подсети — по една за всяка зона на наличност. Все пак, бихме искали да направим за нашия проект отделна мрежа с наша адресация. Общата схема на работа на мрежата в Яндекс.Облака е представена на схемата по-долу (искрено взета от )
И така, създавате обща мрежа, в която ресурсите могат да комуникират помежду си. За всяка зона на наличност се прави подсет с своя адресация и се свързва към общата мрежа. В крайна сметка, всички облачни ресурси в нея могат да комуникират, дори като са в различни зони на наличност. Ресурси, свързани към различни облачни мрежи, могат да се видят помежду си само чрез външни адреси. Между другото, как тази магия работи вътре, .
Създаването на мрежа е описано във файла network.tf от репозитория. Там създаваме една обща частна мрежа internal и свързваме към нея три подсети в различни зони на наличност — internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24).
Инициализираме terraform и създаваме мрежи:
vozerov@mba:~\/events\/terraform (master) $ terraform init
... пропущено ..
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
... пропущено ...
План: 4 для добавления, 0 для изменения, 0 для удаления.
Искате ли да изпълните тези действия?
Terraform ще извърши действията, описани по-горе.
Само 'да' ще бъде прието за одобрение.
Въведете стойност: да
yandex_vpc_network.internal: Създаване...
yandex_vpc_network.internal: Създаването приключи след 3s [id=enp2g2rhile7gbqlbrkr]
yandex_vpc_subnet.internal-a: Създаване...
yandex_vpc_subnet.internal-b: Създаване...
yandex_vpc_subnet.internal-c: Създаване...
yandex_vpc_subnet.internal-a: Създаването приключи след 6s [id=e9b1dad6mgoj2v4funog]
yandex_vpc_subnet.internal-b: Създаването приключи след 7s [id=e2liv5i4amu52p64ac9p]
yandex_vpc_subnet.internal-c: Все още се създава... [10s изминали]
yandex_vpc_subnet.internal-c: Създаването приключи след 10s [id=b0c2qhsj2vranoc9vhcq]
Приложението завърши! Ресурси: 4 добавени, 0 променени, 0 унищожени.Отлично! Създадохме нашата мрежа и сега сме готови да изградим нашите вътрешни услуги.
Създаване на виртуални машини
За тестване на приложението ни ще бъде достатъчно да създадем две виртуални машини — първата ще ни е необходима за компилиране и стартиране на приложението, а втората — за стартиране на kafka, която ще използваме за съхранение на входящите съобщения. Освен това ще създадем още една машина, на която ще настроим prometheus за мониторинг на приложението.
Виртуалните машини ще бъдат настроени с помощта на ansible, така че преди да стартирате terraform, уверете се, че имате една от последните версии на ansible. И инсталирайте необходимите роли от ansible galaxy:
vozerov@mba:~\/events\/terraform (master) $ cd ..\/ansible\/
vozerov@mba:~\/events\/ansible (master) $ ansible-galaxy install -r requirements.yml
- cloudalchemy-prometheus (master) вече е инсталиран, пропускаме.
- cloudalchemy-grafana (master) вече е инсталиран, пропускаме.
- sansible.kafka (master) вече е инсталиран, пропускаме.
- sansible.zookeeper (master) вече е инсталиран, пропускаме.
- geerlingguy.docker (master) вече е инсталиран, пропускаме.
vozerov@mba:~\/events\/ansible (master) $В папката ansible има примерен конфигурационен файл .ansible.cfg, който използвам аз. Може да е полезен.
Преди да създадете виртуалните машини, уверете се, че ssh-agent е стартиран и добавен ssh ключ, иначе terraform няма да може да се свърже с създадените машини. Разбира се, аз се натъкнах на бъг в os x: . За да не се повтори такава история, преди стартиране на Terraform добавете малка променлива в env:
vozerov@mba:~\/events\/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESВ папката с 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: Обновление состояния... [id=enp2g2rhile7gbqlbrkr]
data.yandex_compute_image.ubuntu_image: Обновление состояния...
yandex_vpc_subnet.internal-a: Обновление состояния... [id=e9b1dad6mgoj2v4funog]
План выполнения был сгенерирован и приведен ниже.
Действия с ресурсами обозначены следующими символами:
+ создать
... пропущено ...
План: 3 для добавления, 0 для изменения, 0 для удаления.
... пропущено ...Ако всичко е приключило успешно (как и трябва), ще имаме три виртуални машини:
- build — машина за тестване и сглобяване на приложението. Docker беше инсталиран автоматично от ansible.
- monitoring — машина за мониторинг — на нея е инсталиран prometheus & grafana. Логин / парола стандартен: admin / admin
- kafka — малка машина с инсталиран kafka, достъпна на порт 9092.
Нека се уверим, че всичките са на място:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+ Ресурсите са на място, и отсега можем да извлечем техните IP адреси. По-нататък ще използвам IP адресите за свързване чрез ssh и тестване на приложението. Ако имате акаунт в cloudflare, свързан с terraform, смело използвайте новосъздадените DNS имена.
Между другото, при създаване на виртуалната машина получавате вътрешен IP и вътрешно DNS име, така че можете да се свържете с сървърите в мрежата по имената:
ubuntu@build:~$ ping kafka.ru-central1.internal
PING kafka.ru-central1.internal (172.16.1.31) 56(84) байтови данни.
64 байта от kafka.ru-central1.internal (172.16.1.31): icmp_seq=1 ttl=63 време=1.23 ms
64 байта от kafka.ru-central1.internal (172.16.1.31): icmp_seq=2 ttl=63 време=0.625 ms
^C
--- статистика на ping за kafka.ru-central1.internal ---
2 пакета предадени, 2 получени, 0% загуба на пакети, време 1001ms
rtt min/avg/max/mdev = 0.625/0.931/1.238/0.308 msТова ще ни е полезно за указване на стойност с kafk’а на приложението.
Сглобяване на приложението
Отлично, серверите са на място, приложението е налично — остава само да го сглобим и публикуваме. За сглобяване ще използваме стандартно docker build, а за хранилище на образи ще вземем услугата на яндекс — container registry. Но всичко по реда си.
Копираме приложението на машината build, влизаме чрез ssh и сглобяваме образа:
vozerov@mba:~\/events\/terraform (master) $ cd ..
vozerov@mba:~\/events (master) $ rsync -av app\/ ubuntu@84.201.132.3:app\/
... пропущено ...
отправлено 3849 байт получено 70 байт 7838.00 байт\/сек
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 .
Отправка контекста сборки в Docker демон 6.144kB
Шаг 1\/9 : FROM golang:latest AS build
... пропущено ...
Успешная сборка 9760afd8ef65
Успешно помечен app:latestПолдела сделано — теперь можно проверить работоспособность нашего приложения, запустив его и направив на kafka:
ubuntu@build:~\/app$ sudo docker run --name app -d -p 8080:8080 app \/app\/app -kafka=kafka.ru-central1.internal:9092<\/code>
С локальной машины можно отправить тестовое событие и посмотреть на ответ:
<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) $Приложение ответило успехом записи и указанием id партиции и оффсета, в который попало сообщение. Дело за малым — создать реестр в Яндекс.Облаке и загрузить туда наш образ (как это сделать с помощью трех строчек, описано в файле registry.tf). Создаем хранилище:
vozerov@mba:~\/events\/terraform (master) $ terraform apply -target yandex_container_registry.events
... пропущено ...
План: 1 добавить, 0 изменить, 0 уничтожить.
... пропущено ...
Применение завершено! Ресурсы: 1 добавлено, 0 изменено, 0 уничтожено.Для аутентификации в реестре контейнеров есть несколько способов — с помощью oauth токена, iam токена или ключа сервисного аккаунта. Более подробно об этих методах — в документации. . Мы будем использовать ключ сервисного аккаунта, поэтому создаем аккаунт:
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
... пропущено ...
Применение завершено! Ресурсы: 3 добавлено, 0 изменено, 0 уничтожено.Теперь осталось сделать для него ключ:
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Получаем информацию об id нашего хранилища, перекидываем ключ и авторизуемся:
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! Ваш пароль будет храниться в незашифрованном виде в \/home\/ubuntu\/.docker\/config.json.
Настройте помощник для хранения учетных данных, чтобы устранить это предупреждение. См.
https:\/\/docs.docker.com\/engine\/reference\/commandline\/login\/#credentials-store
Вход выполнен успешно
ubuntu@build:~$Для загрузки образа в реестр нам понадобится ID реестра контейнеров, берем его из утилиты yc:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"След това етикетираме нашето изображение с ново име и го качваме:
ubuntu@build:~$ sudo docker tag app cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1
ubuntu@build:~$ sudo docker push cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1
Качването се отнася до хранилище [cr.yandex/crpdgj6c9umdhgaqjfmm/events]
8c286e154c6e: Качено
477c318b05cb: Качено
beee9f30bc1f: Качено
v1: дайджест: sha256:1dd5aaa9dbdde2f60d833be0bed1c352724be3ea3158bcac3cdee41d47c5e380 размер: 946Можем да се уверим, че изображението е успешно качено:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Между другото, ако инсталирате утилитата yc на машина с linux, можете да използвате командата
yc container registry configure-dockerза конфигуриране на docker.
Заключение
Направили сме голяма и трудна работа и в резултат на това:
- Измислихме архитектурата на нашия бъдещ сервиз.
- Написахме приложение на golang, което реализира нашата бизнес логика.
- Събрахме го и го качихме в частен контейнерен регистър.
В следващата част ще преминем към интересното — ще качим нашето приложение в продукция и накрая ще го подложим на натоварване. Не се изключвайте!
Този материал е наличен в запис на открит практикум REBRAIN & Yandex.Cloud: Приемаме 10 000 запитвания в секунда на Яндекс Облак —
Ако ви интересува да посещавате такива събития онлайн и да задавате въпроси в реално време, присъединявайте се към.
Особено благодарим на Yandex.Cloud за възможността да проведем такова събитие. Ссылка на тях —
Ако ви е нужен преход към облака или имате въпроси относно вашата инфраструктура, .
P.S. Имаме 2 безплатни одита на месец, възможно е точно вашият проект да е в техния списък.
Източник: habr.com
