Zdravím všechny, přátelé!
* Tento článek je založen na otevřeném workshopu REBRAIN & Yandex.Cloud, pokud se raději díváte na video, najdete ho na tomto odkazu -
Nedávno jsme měli možnost vyzkoušet Yandex.Cloud naživo. Protože jsme chtěli zkoumat dlouho a tvrdě, okamžitě jsme opustili myšlenku spustit jednoduchý blog Wordpress s cloudovou základnou - bylo to příliš nudné. Po chvíli přemýšlení jsme se rozhodli nasadit něco podobného jako architektura produkčních služeb pro příjem a analýzu událostí v téměř reálném čase.
Jsem si naprosto jistý, že naprostá většina online (nejen) firem nějakým způsobem shromažďuje hory informací o svých uživatelích a jejich činech. Minimálně je to nutné pro určitá rozhodnutí – pokud například spravujete online hru, můžete se podívat na statistiky, na jaké úrovni se uživatelé nejčastěji zaseknou a vaši hračku smažou. Nebo proč uživatelé opouštějí váš web, aniž by si něco koupili (ahoj, Yandex.Metrica).
Takže náš příběh: jak jsme napsali aplikaci v golangu, testovali kafka vs rabbitmq vs yqs, napsali streamování dat v clusteru Clickhouse a vizualizovali data pomocí datalens yandex. To vše bylo samozřejmě okořeněno infrastrukturními lahůdkami v podobě docker, terraform, gitlab ci a samozřejmě prometheus. Pojďme!
Okamžitě bych si chtěl rezervovat, že nebudeme schopni nakonfigurovat vše na jedno sezení - k tomu budeme potřebovat několik článků v sérii. Něco málo o struktuře:
Část 1 (čtete ji). Rozhodneme o specifikacích a architektuře řešení a také napíšeme aplikaci v golangu.
Část 2. Uvolňujeme naši aplikaci do výroby, činíme ji škálovatelnou a testujeme zátěž.
Část 3. Zkusme přijít na to, proč potřebujeme ukládat zprávy do vyrovnávací paměti a ne do souborů, a také porovnat službu fronty kafka, rabbitmq a yandex.
Část 4 Nasadíme Clickhouse cluster, napíšeme streamovací službu pro přenos dat z tamního bufferu a nastavíme vizualizaci v datalens.
Část 5 Pojďme uvést celou infrastrukturu do patřičného tvaru – nastavit ci/cd pomocí gitlab ci, propojit monitorování a zjišťování služeb pomocí prometheus a consul.
TK
Nejprve si zformulujme zadání – čeho přesně chceme dosáhnout.
- Chceme mít koncový bod jako events.kis.im (kis.im je testovací doména, kterou budeme používat ve všech článcích), který by měl přijímat události pomocí HTTPS.
- Události jsou jednoduchý json jako: {“event“: „view“, „os“: „linux“, „browser“: „chrome“}. V konečné fázi přidáme trochu více polí, ale to nebude hrát velkou roli. Pokud chcete, můžete přejít na protobuf.
- Služba musí být schopna zpracovat 10 000 událostí za sekundu.
- Mělo by být možné horizontálně škálovat jednoduchým přidáním nových instancí do našeho řešení. A bylo by hezké, kdybychom mohli přesunout přední část do různých geolokací, abychom snížili latenci požadavků klientů.
- Odolnost proti chybám. Řešení musí být dostatečně stabilní a umět přežít pád jakýchkoli částí (samozřejmě do určitého počtu).
architektura
Obecně platí, že pro tento typ úloh byly již dlouho vynalezeny klasické architektury, které umožňují efektivní škálování. Obrázek ukazuje příklad našeho řešení.
Takže co máme:
1. Vlevo jsou naše zařízení, která generují různé události, ať už jde o hráče dokončující úroveň v hračce na smartphonu nebo vytváření objednávky v internetovém obchodě prostřednictvím běžného prohlížeče. Událost, jak je specifikováno ve specifikaci, je jednoduchý json, který je odeslán do našeho koncového bodu – events.kis.im.
2. První dva servery jsou jednoduché balancery, jejich hlavní úkoly jsou:
- Buďte neustále k dispozici. K tomu lze použít například keepalived, který v případě problémů přepne virtuální IP mezi uzly.
- Ukončete TLS. Ano, ukončíme na nich TLS. Jednak proto, aby naše řešení vyhovovalo technickým specifikacím, a jednak proto, abychom odlehčili od navazování šifrovaného spojení z našich backendových serverů.
- Vyvažte příchozí požadavky na dostupné backend servery. Klíčové slovo je zde dostupné. Na základě toho jsme dospěli k pochopení, že nástroje pro vyrovnávání zátěže musí být schopny monitorovat naše servery s aplikacemi a zastavit vyrovnávání provozu na neúspěšné uzly.
3. Po balancérech tu máme aplikační servery, na kterých běží docela jednoduchá aplikace. Měl by být schopen přijímat příchozí požadavky přes HTTP, ověřovat odeslaný json a ukládat data do vyrovnávací paměti.
4. Diagram ukazuje kafku jako buffer, i když na této úrovni lze samozřejmě využít i jiné podobné služby. Kafku, rabbitmq a yqs porovnáme ve třetím článku.
5. Předposledním bodem naší architektury je Clickhouse – sloupcová databáze, která umožňuje ukládat a zpracovávat obrovské množství dat. Na této úrovni potřebujeme přenést data z vyrovnávací paměti do samotného úložného systému (více v článku 4).
Tento design nám umožňuje měnit měřítko každé vrstvy nezávisle vodorovně. Backendové servery to nezvládnou – dodejme ještě jednu věc – přeci jen jsou to bezstavové aplikace, a proto to lze dělat i automaticky. Vyrovnávací paměť ve stylu Kafky nefunguje – přidejte další servery a přeneste na ně některé oddíly našeho tématu. Clickhouse to nezvládne – to je nemožné :) Ve skutečnosti také propojíme servery a data rozstříháme.
Mimochodem, pokud chcete implementovat volitelnou část našich technických specifikací a měřítka v různých geolokacích, pak není nic jednoduššího:
V každé geolokaci nasadíme load balancer s aplikací a kafkou. Obecně stačí 2 aplikační servery, 3 kafka nody a cloud balancer, například cloudflare, který zkontroluje dostupnost aplikačních uzlů a vyrovná požadavky podle geolokace na základě zdrojové IP adresy klienta. Data odeslaná americkým klientem tak přistanou na amerických serverech. A data z Afriky jsou v Africe.
Pak je vše celkem jednoduché – používáme zrcadlový nástroj ze sady Kafka a všechna data ze všech lokalit zkopírujeme do našeho centrálního datového centra v Rusku. Interně data analyzujeme a zaznamenáme v Clickhouse pro následnou vizualizaci.
Takže jsme vyřešili architekturu - začněme třást Yandex.Cloud!
Psaní aplikace
Před Cloudem se musíte ještě trochu obrnit trpělivostí a napsat celkem jednoduchou službu na zpracování příchozích událostí. Použijeme golang, protože se velmi dobře osvědčil jako jazyk pro psaní síťových aplikací.
Po hodině (možná několika hodinách) dostaneme něco takového: .
Jaké jsou hlavní body, které bych zde rád poznamenal:
1. Při spouštění aplikace můžete zadat dva příznaky. Jeden je zodpovědný za port, na kterém budeme naslouchat příchozím požadavkům http (-addr). Druhý je pro adresu serveru kafka, kam budeme zaznamenávat naše události (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. Aplikace používá knihovnu sarama () k odesílání zpráv do clusteru kafka. Okamžitě jsme nastavili nastavení zaměřená na maximální rychlost zpracování:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Naše aplikace má také vestavěného klienta prometheus, který shromažďuje různé metriky, jako například:
- počet požadavků na naši aplikaci;
- počet chyb při provádění požadavku (nelze přečíst požadavek na příspěvek, nefunkční json, nelze zapisovat do Kafky);
- doba zpracování jednoho požadavku od klienta, včetně času na napsání zprávy Kafkovi.
4. Tři koncové body, které naše aplikace zpracovává:
- /status - jednoduše vraťte ok, abyste ukázali, že jsme naživu. I když můžete přidat nějaké kontroly, jako je dostupnost clusteru Kafka.
- /metrics - podle této adresy URL klient prometheus vrátí metriky, které nasbíral.
- /post je hlavní koncový bod, kam budou odesílány požadavky POST s json uvnitř. Naše aplikace zkontroluje platnost json a pokud je vše v pořádku, zapíše data do Kafka clusteru.
Udělám výhradu, že kód není dokonalý - může (a měl by!) být dokončen. Můžete například přestat používat vestavěný net/http a přejít na rychlejší fasthttp. Nebo můžete získat čas na zpracování a zdroje procesoru tím, že přesunete kontrolu platnosti json na pozdější fázi – když se data přenesou z vyrovnávací paměti do clusteru clickhouse.
Kromě vývojové stránky problému jsme okamžitě přemýšleli o naší budoucí infrastruktuře a rozhodli jsme se nasadit naši aplikaci přes docker. Konečným souborem Dockerfile pro sestavení aplikace je . Obecně je to docela jednoduché, jediný bod, kterému bych chtěl věnovat pozornost, je vícestupňová montáž, která nám umožňuje zmenšit konečný obraz našeho kontejneru.
První kroky v cloudu
Nejprve se zaregistrujte . Po vyplnění všech potřebných polí nám bude vytvořen účet a přidělen grant na určitou finanční částku, kterou lze využít k testování cloudových služeb. Pokud si chcete zopakovat všechny kroky z našeho článku, tento grant by vám měl stačit.
Po registraci se vám vytvoří samostatný cloud a výchozí adresář, ve kterém můžete začít vytvářet cloudové prostředky. Obecně platí, že v Yandex.Cloud vypadá vztah zdrojů takto:
Pro jeden účet můžete vytvořit několik cloudů. A v cloudu vytvořte různé adresáře pro různé firemní projekty. Více si o tom můžete přečíst v dokumentaci - . Mimochodem, budu na to často odkazovat níže v textu. Když jsem nastavil celou infrastrukturu od začátku, dokumentace mi pomohla více než jednou, takže vám doporučuji, abyste si ji prostudovali.
Ke správě cloudu můžete využít jak webové rozhraní, tak konzolovou utilitu – yc. Instalace se provádí jedním příkazem (pro Linux a Mac OS):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashPokud váš interní bezpečnostní specialista zuří na spouštění skriptů z internetu, pak za prvé můžete skript otevřít a přečíst si ho a zadruhé ho spustíme pod naším uživatelem – bez práv root.
Pokud chcete nainstalovat klienta pro Windows, můžete použít pokyny a poté provést yc initpro úplné přizpůsobení:
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:~ $V principu je proces jednoduchý – nejprve je potřeba získat oauth token pro správu cloudu, vybrat cloud a složku, kterou budete používat.
Pokud máte několik účtů nebo složek ve stejném cloudu, můžete vytvořit další profily se samostatným nastavením pomocí yc config profile create a přepínat mezi nimi.
Kromě výše uvedených metod napsal tým Yandex.Cloud velmi dobrý pro správu cloudových zdrojů. Z mé strany jsem připravil git repozitář, kde jsem popsal všechny zdroje, které budou v rámci článku vytvořeny - . Zajímá nás hlavní větev, naklonujme ji lokálně:
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/Všechny hlavní proměnné, které se používají v terraformu, jsou zapsány v souboru main.tf. Chcete-li začít, vytvořte ve složce terraform soubor private.auto.tfvars s následujícím obsahem:
# 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 = ""Všechny proměnné lze převzít ze seznamu konfigurace yc, protože jsme již nakonfigurovali obslužný program konzoly. Radím vám okamžitě přidat private.auto.tfvars do .gitignore, abyste náhodou nezveřejnili soukromá data.
V private.auto.tfvars jsme také specifikovali data z Cloudflare - pro vytvoření DNS záznamů a proxy hlavní domény events.kis.im na naše servery. Pokud nechcete používat cloudflare, odeberte inicializaci poskytovatele cloudflare v main.tf a souboru dns.tf, který je zodpovědný za vytvoření potřebných dns záznamů.
V naší práci zkombinujeme všechny tři metody – webové rozhraní, konzolovou utilitu a terraform.
Virtuální sítě
Abych byl upřímný, můžete tento krok přeskočit, protože když vytvoříte nový cloud, budete mít automaticky vytvořenu samostatnou síť a 3 podsítě – jednu pro každou zónu dostupnosti. Ale i tak bychom pro náš projekt rádi udělali samostatnou síť s vlastním adresováním. Obecné schéma fungování sítě v Yandex.Cloud je znázorněno na obrázku níže (upřímně převzato z )
Vytvoříte tak společnou síť, v rámci které mohou prostředky mezi sebou komunikovat. Pro každou zónu dostupnosti je vytvořena podsíť s vlastním adresováním a připojena k obecné síti. Díky tomu mohou všechny cloudové zdroje v něm komunikovat, i když jsou v různých zónách dostupnosti. Zdroje připojené k různým cloudovým sítím se navzájem vidí pouze prostřednictvím externích adres. Mimochodem, jak to kouzlo funguje uvnitř, .
Vytvoření sítě je popsáno v souboru network.tf z úložiště. Tam vytvoříme jednu společnou privátní síť interní a připojíme k ní tři podsítě v různých zónách dostupnosti – interní-a (172.16.1.0/24), interní-b (172.16.2.0/24), interní-c (172.16.3.0/24 ).
Inicializujte terraform a vytvořte sítě:
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.Skvělý! Vytvořili jsme naši síť a nyní jsme připraveni vytvořit naše interní služby.
Vytvořte virtuální stroje
K otestování aplikace nám bude stačit vytvořit dva virtuální stroje – první budeme potřebovat pro sestavení a spuštění aplikace, druhý pro spuštění kafka, který budeme používat k ukládání příchozích zpráv. A vytvoříme další stroj, kde nakonfigurujeme prometheus pro sledování aplikace.
Virtuální stroje budou konfigurovány pomocí ansible, takže před spuštěním terraformu se ujistěte, že máte jednu z nejnovějších verzí ansible. A nainstalujte potřebné role s ansible galaxií:
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) $Uvnitř složky ansible je příklad konfiguračního souboru .ansible.cfg, který používám. Může se to hodit.
Před vytvořením virtuálních strojů se ujistěte, že máte spuštěného ssh-agenta a přidaný ssh klíč, jinak se terraform nebude moci připojit k vytvořeným strojům. Samozřejmě jsem narazil na chybu v OS x: . Abyste tomu zabránili, přidejte před spuštěním Terraformu do env malou proměnnou:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESVe složce s terraformem vytvoříme potřebné zdroje:
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 ...Pokud vše skončilo úspěšně (a mělo by být), pak budeme mít tři virtuální stroje:
- build - stroj pro testování a sestavení aplikace. Docker byl nainstalován automaticky společností Ansible.
- monitoring - na něm nainstalovaný monitorovací stroj - prometheus & grafana. Standardní přihlašovací jméno / heslo: admin / admin
- kafka je malý stroj s nainstalovanou kafkou, přístupný na portu 9092.
Ujistěte se, že jsou všechny na svém místě:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Zdroje jsou na místě a odtud můžeme získat jejich IP adresy. V následujícím budu používat IP adresy pro připojení přes ssh a testování aplikace. Pokud máte cloudflare účet připojený k terraformu, klidně použijte čerstvě vytvořené DNS názvy.
Mimochodem, při vytváření virtuálního počítače se zadává interní IP a interní název DNS, takže můžete přistupovat k serverům v síti podle názvu:
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 msTo se nám bude hodit k tomu, abychom aplikaci označili koncový bod s kafk.
Sestavení aplikace
Skvělé, existují servery, existuje aplikace - zbývá ji pouze sestavit a publikovat. Pro sestavení použijeme obvyklé sestavení dockeru, ale jako úložiště obrázků použijeme službu od Yandex - kontejnerový registr. Ale nejdřív.
Zkopírujeme aplikaci do sestavovacího stroje, přihlásíme se přes ssh a sestavíme obrázek:
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:latestPolovina bitvy je hotová – nyní můžeme zkontrolovat funkčnost naší aplikace jejím spuštěním a odesláním do kafky:
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) $Aplikace odpověděla úspěšností záznamu a uvedením ID oddílu a offsetu, ve kterém byla zpráva zahrnuta. Zbývá pouze vytvořit registr na Yandex.Cloud a nahrát tam náš obrázek (jak to udělat pomocí tří řádků je popsáno v souboru registry.tf). Vytvořte úložiště:
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.Existuje několik způsobů ověření v registru kontejnerů – pomocí tokenu oauth, tokenu iam nebo klíče účtu služby. Více podrobností o těchto metodách lze nalézt v dokumentaci. . Použijeme klíč servisního účtu, takže vytvoříme účet:
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.Nyní zbývá pouze vytvořit klíč:
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_2048Obdržíme informace o id našeho úložiště, přeneseme klíč a přihlásíme se:
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:~$K nahrání obrázku do registru potřebujeme ID registru kontejneru, které vezmeme z nástroje yc:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Poté označíme náš obrázek novým názvem a nahrajeme:
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: 946Můžeme ověřit, že se obrázek úspěšně načetl:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Mimochodem, pokud nainstalujete nástroj yc na počítač se systémem Linux, můžete použít příkaz
yc container registry configure-dockerpro konfiguraci dockeru.
Závěr
Udělali jsme hodně tvrdé práce a výsledkem je:
- Přišli jsme s architekturou naší budoucí služby.
- Napsali jsme aplikaci v golangu, která implementuje naši obchodní logiku.
- Shromáždili jsme to a nalili do soukromého registru kontejnerů.
V příštím díle přejdeme k zajímavostem – uvolníme naši aplikaci do produkce a konečně spustíme její zatížení. Nepřepínejte!
Tento materiál je na videozáznamu otevřeného workshopu REBRAIN & Yandex.Cloud: Na Yandex Cloud přijímáme 10 000 požadavků za sekundu -
Pokud máte zájem navštěvovat takové akce online a klást otázky v reálném čase, připojte se na.
Rádi bychom vyjádřili zvláštní poděkování společnosti Yandex.Cloud za příležitost uspořádat takovou událost. Odkaz na ně -
Pokud potřebujete přejít do cloudu nebo máte dotazy týkající se vaší infrastruktury, .
PS Máme 2 bezplatné audity měsíčně, možná bude váš projekt jedním z nich.
Zdroj: www.habr.com