Приемаме 10 000 събития в Yandex.Cloud. Част 1

Здравейте на всички приятели!

* Тази статия е базирана на отворения семинар на REBRAIN & Yandex.Cloud, ако предпочитате да гледате видеоклипа, можете да го намерите на тази връзка - https://youtu.be/cZLezUm0ekE

Наскоро имахме възможност да изпробваме Yandex.Cloud на живо. Тъй като искахме да изследваме дълго и упорито, веднага се отказахме от идеята да стартираме прост блог на Wordpress с облачна база - беше твърде скучно. След известен размисъл решихме да внедрим нещо подобно на архитектура на производствена услуга за получаване и анализиране на събития в режим почти в реално време.

Абсолютно съм сигурен, че по-голямата част от онлайн (и не само) бизнеси по някакъв начин събират планина от информация за своите потребители и техните действия. Като минимум, това е необходимо за вземане на определени решения - например, ако управлявате онлайн игра, можете да погледнете статистиката на кое ниво потребителите най-често се забиват и изтриват вашата играчка. Или защо потребителите напускат вашия сайт, без да купят нищо (здравей, Yandex.Metrica).

И така, нашата история: как написахме приложение на golang, тествахме kafka срещу rabbitmq срещу yqs, написахме поточно предаване на данни в клъстер Clickhouse и визуализирахме данните с помощта на yandex datalens. Естествено, всичко това беше подправено с инфраструктурни изкушения под формата на docker, terraform, gitlab ci и, разбира се, prometheus. Да тръгваме!

Бих искал веднага да направя резервация, че няма да можем да конфигурираме всичко наведнъж - за това ще ни трябват няколко статии от поредицата. Малко за структурата:

Част 1 (вие я четете). Ние ще вземем решение относно спецификациите и архитектурата на решението и също така ще напишем приложение на golang.
Част 2. Пускаме нашето приложение в производство, правим го мащабируемо и тестваме натоварването.
Част 3. Нека се опитаме да разберем защо трябва да съхраняваме съобщенията в буфер, а не във файлове, и също така да сравним услугата kafka, rabbitmq и yandex queue.
част 4 Ще внедрим клъстер Clickhouse, ще напишем услуга за стрийминг за прехвърляне на данни от буфера там и ще настроим визуализация в datalens.
част 5 Нека приведем цялата инфраструктура в правилна форма - настройте ci/cd с помощта на gitlab ci, свържете мониторинг и откриване на услуги с помощта на prometheus и consul.

TK

Първо, нека формулираме техническото задание - какво точно искаме да получим като резултат.

1. Искаме да имаме крайна точка като events.kis.im (kis.im е тестовият домейн, който ще използваме във всички статии), която трябва да получава събития чрез HTTPS.
2. Събитията са обикновен json като: {“event”: “view”, “os”: “linux”, “browser”: “chrome”}. На последния етап ще добавим още малко полета, но това няма да играе голяма роля. Ако желаете, можете да преминете към protobuf.
3. Услугата трябва да може да обработва 10 000 събития в секунда.
4. Трябва да е възможно хоризонтално мащабиране чрез просто добавяне на нови екземпляри към нашето решение. И ще бъде хубаво, ако можем да преместим предната част на различни геолокации, за да намалим забавянето на клиентските заявки.
5. Толерантност към грешки. Решението трябва да е достатъчно стабилно и да може да оцелее при падане на всякакви части (до определен брой, разбира се).

архитектура

По принцип за този тип задачи отдавна са измислени класически архитектури, които позволяват ефективно мащабиране. Фигурата показва пример за нашето решение.

И така, какво имаме:

1. Отляво са нашите устройства, които генерират различни събития, било то играчи, завършващи ниво в играчка на смартфон или създаване на поръчка в онлайн магазин чрез обикновен браузър. Събитието, както е посочено в спецификацията, е обикновен json, който се изпраща до нашата крайна точка - events.kis.im.

2. Първите два сървъра са прости балансьори, основните им задачи са:

• Бъдете постоянно на разположение. За да направите това, можете да използвате например keepalived, който ще превключва виртуалния IP между възлите в случай на проблеми.
• Прекратете TLS. Да, ние ще прекратим TLS на тях. Първо, така че нашето решение да отговаря на техническите спецификации, и второ, за да се облекчи тежестта на установяване на криптирана връзка от нашите сървъри в задната част.
• Балансирайте входящите заявки към наличните бекенд сървъри. Ключовата дума тук е достъпна. Въз основа на това стигаме до разбирането, че балансьорите на натоварването трябва да могат да наблюдават нашите сървъри с приложения и да спрат да балансират трафика към повредени възли.

3. След балансьорите имаме сървъри за приложения, работещи с доста просто приложение. Трябва да може да приема входящи заявки чрез HTTP, да валидира изпратения json и да поставя данните в буфер.

4. Диаграмата показва kafka като буфер, въпреки че, разбира се, други подобни услуги могат да се използват на това ниво. Ще сравним Kafka, rabbitmq и yqs в третата статия.

5. Предпоследната точка на нашата архитектура е Clickhouse - колонна база данни, която ви позволява да съхранявате и обработвате огромно количество данни. На това ниво трябва да прехвърлим данни от буфера към самата система за съхранение (повече за това в статия 4).

Този дизайн ни позволява да мащабираме всеки слой независимо хоризонтално. Бекенд сървърите не могат да се справят - нека добавим още нещо - в крайна сметка те са приложения без състояние и следователно това може да се направи дори автоматично. Буферът в стил Kafka не работи - нека добавим още сървъри и да прехвърлим някои от дяловете на нашата тема към тях. Clickhouse не може да се справи - невъзможно е :) Всъщност ние също ще свържем сървърите и ще разделим данните.

Между другото, ако искате да внедрите незадължителната част от нашите технически спецификации и мащаб в различни геолокации, тогава няма нищо по-просто:

Във всяка геолокация разполагаме балансьор на натоварването с приложение и kafka. Като цяло са достатъчни 2 сървъра на приложения, 3 възела kafka и облачен балансьор, например cloudflare, който ще проверява наличието на възли на приложения и заявки за баланс чрез геолокация въз основа на IP адреса на източника на клиента. По този начин данните, изпратени от американски клиент, ще кацнат на американски сървъри. И данните от Африка са на африкански.

След това всичко е съвсем просто - използваме огледалния инструмент от комплекта Kafka и копираме всички данни от всички места в нашия централен център за данни, разположен в Русия. Вътрешно анализираме данните и ги записваме в Clickhouse за последваща визуализация.

И така, подредихме архитектурата - нека започнем да разклащаме Yandex.Cloud!

Писане на молба

Преди Cloud все още трябва да сте малко търпеливи и да напишете доста проста услуга за обработка на входящи събития. Ще използваме golang, защото той се е доказал много добре като език за писане на мрежови приложения.

След като прекараме един час (може би няколко часа), получаваме нещо подобно: https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/main.go.

Кои са основните точки, които бих искал да отбележа тук:

1. Когато стартирате приложението, можете да зададете два флага. Единият отговаря за порта, на който ще слушаме входящите http заявки (-addr). Второто е за адреса на kafka сървъра, където ще записваме нашите събития (-kafka):

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

2. Приложението използва библиотеката sarama ([] github.com/Shopify/sarama), за да изпращате съобщения до клъстера kafka. Веднага задаваме настройките, насочени към максимална скорост на обработка:

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

3. Нашето приложение също има вграден клиент prometheus, който събира различни показатели, като например:

• брой заявки към нашето приложение;
• брой грешки при изпълнение на заявката (невъзможно четене на заявка за публикуване, повреден json, невъзможно писане на Kafka);
• време за обработка на една заявка от клиента, включително времето за писане на съобщение до Kafka.

4. Три крайни точки, които нашето приложение обработва:

• /статус - просто връща ok, за да покаже, че сме живи. Въпреки че можете да добавите някои проверки, като например наличността на клъстера Kafka.
• /metrics - според този url клиентът prometheus ще върне събраните от него показатели.
• /post е основната крайна точка, където ще се изпращат POST заявки с json вътре. Нашето приложение проверява json за валидност и ако всичко е наред, записва данните в клъстера Kafka.

Ще направя уговорка, че кодът не е идеален - той може (и трябва!) да бъде завършен. Например, можете да спрете да използвате вградения net/http и да преминете към по-бързия fasthttp. Или можете да спечелите време за обработка и ресурси на процесора, като преместите проверката за валидност на json на по-късен етап - когато данните се прехвърлят от буфера към клъстера clickhouse.

В допълнение към развойната страна на проблема, веднага помислихме за нашата бъдеща инфраструктура и решихме да внедрим нашето приложение чрез докер. Последният Dockerfile за изграждане на приложението е https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/Dockerfile. Като цяло е доста просто, единствената точка, на която бих искал да обърна внимание, е многоетапното сглобяване, което ни позволява да намалим окончателното изображение на нашия контейнер.

Първи стъпки в облака

На първо място, регистрирайте се на cloud.yandex.ru. След като попълним всички необходими полета, ще ни бъде създаден акаунт и ще ни бъде даден грант за определена сума пари, която може да се използва за тестване на облачни услуги. Ако искате да повторите всички стъпки от нашата статия, тази субсидия трябва да ви е достатъчна.

След регистрация за вас ще бъде създаден отделен облак и директория по подразбиране, в която можете да започнете да създавате облачни ресурси. Като цяло в Yandex.Cloud връзката на ресурсите изглежда така:

Можете да създадете няколко облака за един акаунт. И вътре в облака направете различни директории за различни фирмени проекти. Можете да прочетете повече за това в документацията - https://cloud.yandex.ru/docs/resource-manager/concepts/resources-hierarchy. Между другото, често ще го споменавам по-долу в текста. Когато създадох цялата инфраструктура от нулата, документацията ми помогна повече от веднъж, така че ви съветвам да я проучите.

За да управлявате облака, можете да използвате както уеб интерфейса, така и конзолната помощна програма - 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 token за управление на облака, да изберете облака и папката, която ще използвате.

Ако имате няколко акаунта или папки в един и същи облак, можете да създадете допълнителни профили с отделни настройки чрез yc config profile create и да превключвате между тях.

В допълнение към горните методи, екипът на Yandex.Cloud написа много добър плъгин за terraform за управление на облачни ресурси. От своя страна подготвих git хранилище, където описах всички ресурси, които ще бъдат създадени като част от статията - https://github.com/rebrainme/yandex-cloud-events/. Интересуваме се от главния клон, нека го клонираме локално:

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/

Всички основни променливи, които се използват в terraform, са записани във файла main.tf. За да започнете, създайте файл private.auto.tfvars в папката terraform със следното съдържание:

# 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 списъка, тъй като вече сме конфигурирали конзолната помощна програма. Съветвам ви незабавно да добавите private.auto.tfvars към .gitignore, за да не публикувате случайно лични данни.

В private.auto.tfvars също посочихме данни от Cloudflare - за създаване на DNS записи и прокси на основния домейн events.kis.im към нашите сървъри. Ако не искате да използвате cloudflare, премахнете инициализацията на доставчика на cloudflare в main.tf и файла dns.tf, който е отговорен за създаването на необходимите dns записи.

В нашата работа ще комбинираме и трите метода - уеб интерфейса, помощната програма на конзолата и terraform.

Виртуални мрежи

Честно казано, можете да пропуснете тази стъпка, тъй като когато създавате нов облак, автоматично ще имате създадена отделна мрежа и 3 подмрежи - по една за всяка зона на достъпност. Но все пак бихме искали да направим отделна мрежа за нашия проект със собствено адресиране. Общата диаграма за това как работи мрежата в Yandex.Cloud е показана на фигурата по-долу (честно взета от https://cloud.yandex.ru/docs/vpc/concepts/)

Така създавате обща мрежа, в която ресурсите могат да комуникират помежду си. За всяка зона на достъпност се създава подмрежа със собствено адресиране и се свързва към общата мрежа. В резултат на това всички облачни ресурси в него могат да комуникират, дори ако са в различни зони на достъпност. Ресурсите, свързани към различни облачни мрежи, могат да се виждат един друг само чрез външни адреси. Между другото, как действа тази магия вътре, беше добре описан на Хабре.

Създаването на мрежа е описано във файла network.tf от хранилището. Там създаваме една обща вътрешна вътрешна мрежа и свързваме към нея три подмрежи в различни зони на достъпност - вътрешна-a (172.16.1.0/24), вътрешна-b (172.16.2.0/24), вътрешна-c (172.16.3.0/24 ).

Инициализирайте terraform и създайте мрежи:

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.

Страхотен! Създадохме нашата мрежа и вече сме готови да създадем нашите вътрешни услуги.

Създавайте виртуални машини

За да тестваме приложението, ще трябва да създадем само две виртуални машини – първата ще ни трябва за изграждане и стартиране на приложението, втората за стартиране на 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) 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) $

В папката ansible има примерен конфигурационен файл .ansible.cfg, който използвам. Може да е полезно.

Преди да създадете виртуални машини, уверете се, че имате работещ ssh-агент и добавен ssh ключ, в противен случай terraform няма да може да се свърже със създадените машини. Разбира се, попаднах на грешка в os x: https://github.com/ansible/ansible/issues/32499#issuecomment-341578864. За да предотвратите това да се случи отново, добавете малка променлива към env, преди да стартирате Terraform:

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

Ако всичко приключи успешно (и трябва да бъде), тогава ще имаме три виртуални машини:

1. build - машина за тестване и изграждане на приложение. Docker беше инсталиран автоматично от Ansible.
2. мониторинг - машина за наблюдение - prometheus & grafana, инсталирана на нея. Стандартно влизане / парола: admin / admin
3. 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) 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

Това ще бъде полезно за нас, за да посочим на приложението крайната точка с kafk.

Сглобяване на приложението

Страхотно, има сървъри, има приложение - остава само да го сглобим и публикуваме. За изграждането ще използваме обичайната докер компилация, но като хранилище за изображения ще използваме услуга от Yandex - регистър на контейнери. Но на първо място.

Копираме приложението в машината за изграждане, влизаме чрез ssh и сглобяваме изображението:

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

Половината битка е свършена - сега можем да проверим функционалността на нашето приложение, като го стартираме и изпратим на 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) $

Приложението отговори с успех на записа и посочи идентификатора на дяла и отместването, в което е включено съобщението. Всичко, което остава да направите, е да създадете регистър в Yandex.Cloud и да качите нашето изображение там (как да направите това с помощта на три реда е описано във файла registry.tf). Създайте хранилище:

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.

Има няколко начина за удостоверяване в регистъра на контейнера - с помощта на oauth токен, iam токен или ключ на акаунт за услуга. Повече подробности за тези методи можете да намерите в документацията. https://cloud.yandex.ru/docs/container-registry/operations/authentication. Ще използваме ключа на акаунта на услугата, така че създаваме акаунт:

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.

Сега всичко, което остава, е да направите ключ за него:

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

Получаваме информация за идентификатора на нашето хранилище, прехвърляме ключа и влизаме:

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:~$

За да качите изображението в регистъра, имаме нужда от идентификатора на регистъра на контейнера, вземаме го от помощната програма 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
The push refers to repository [cr.yandex/crpdgj6c9umdhgaqjfmm/events]
8c286e154c6e: Pushed
477c318b05cb: Pushed
beee9f30bc1f: Pushed
v1: digest: sha256:1dd5aaa9dbdde2f60d833be0bed1c352724be3ea3158bcac3cdee41d47c5e380 size: 946

Можем да проверим дали изображението е заредено успешно:

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

Между другото, ако инсталирате помощната програма yc на Linux машина, можете да използвате командата

yc container registry configure-docker

за конфигуриране на докер.

Заключение

Свършихме много упорита работа и в резултат на това:

1. Измислихме архитектурата на нашата бъдеща услуга.
2. Написахме приложение на golang, което прилага нашата бизнес логика.
3. Събрахме го и го изсипахме в частен регистър на контейнери.

В следващата част ще преминем към интересните неща - ще пуснем нашето приложение в производство и накрая ще стартираме натоварването върху него. Не превключвайте!

Този материал е във видеозаписа на отворения семинар REBRAIN & Yandex.Cloud: Приемаме 10 000 заявки в секунда в Yandex Cloud - https://youtu.be/cZLezUm0ekE

Ако се интересувате да посещавате такива събития онлайн и да задавате въпроси в реално време, свържете се с канал DevOps от REBRAIN.

Бихме искали да кажем специални благодарности на Yandex.Cloud за възможността да бъде домакин на такова събитие. Линк към тях - https://cloud.yandex.ru/prices

Ако трябва да преминете към облака или имате въпроси относно вашата инфраструктура, не се колебайте да оставите заявка.

PS Имаме 2 безплатни одита на месец, може би вашият проект ще бъде един от тях.

Източник: www.habr.com