Hello mindenkinek, barátok!
* Ez a cikk a REBRAIN & Yandex.Cloud nyílt műhelyén alapul, ha inkább megnézné a videót, ezen a linken találhatja meg -
Nemrég lehetőségünk nyílt élőben kipróbálni a Yandex.Cloudot. Mivel hosszan és keményen akartunk szondázni, azonnal elvetettük az ötletet, hogy indítsunk egy egyszerű Wordpress blogot felhőalappal – túl unalmas volt. Némi gondolkodás után úgy döntöttünk, hogy egy éles szolgáltatási architektúrához hasonlót telepítünk az események közel valós idejű fogadására és elemzésére.
Teljesen biztos vagyok benne, hogy az online (és nem csak) vállalkozások túlnyomó többsége valamilyen módon rengeteg információt gyűjt a felhasználóiról és tevékenységeikről. Ez legalább bizonyos döntések meghozatalához szükséges – például ha Ön online játékot menedzsel, megnézheti a statisztikákat, hogy a felhasználók melyik szinten akadnak el leggyakrabban, és törlik a játékot. Vagy miért hagyják el a felhasználók webhelyét anélkül, hogy vásárolnának (helló, Yandex.Metrica).
Szóval, a mi történetünk: hogyan írtunk egy alkalmazást golang nyelven, teszteltük a kafka vs rabbitmq vs yqs-t, hogyan írtunk adatfolyamot egy Clickhouse fürtbe, és vizualizáltuk az adatokat a yandex datalens segítségével. Mindezt természetesen infrastrukturális élvezetekkel fűszerezték, a docker, a terraform, a gitlab ci és természetesen a prométheusz formájában. Gyerünk!
Szeretnék azonnal leszögezni, hogy nem tudunk mindent egy ülésben konfigurálni - ehhez több cikkre lesz szükségünk a sorozatban. Egy kicsit a szerkezetről:
1. rész (ezt olvasod). Döntjük a megoldás specifikációiról és architektúrájáról, valamint golang nyelven írunk egy pályázatot.
2. rész. Alkalmazásunkat éles forgalomba bocsátjuk, méretezhetővé tesszük és teszteljük a terhelést.
3. rész Próbáljuk meg kitalálni, hogy miért kell pufferben tárolnunk az üzeneteket, nem pedig fájlokban, és hasonlítsuk össze a kafka, a rabbitmq és a yandex queue szolgáltatást is.
4. rész Telepítünk egy Clickhouse-fürtöt, írunk egy streaming szolgáltatást az ott található pufferből való adatok átviteléhez, és beállítjuk a vizualizációt a datalensben.
5. rész Hozzuk megfelelő formába a teljes infrastruktúrát – állítsuk be a ci/cd-t a gitlab ci segítségével, kössük össze a megfigyelést és a szolgáltatáskeresést a prometheus és a consul segítségével.
TK
Először is fogalmazzuk meg a feladatkört – hogy pontosan mit is szeretnénk ennek eredményeként kapni.
- Olyan végpontot szeretnénk, mint az események.kis.im (a kis.im az a teszttartomány, amelyet minden cikkben használni fogunk), amely HTTPS-en keresztül fogadja az eseményeket.
- Az események egy egyszerű json, például: {"event": "view", "os": "linux", "browser": "chrome"}. Az utolsó szakaszban még egy kis mezőt adunk hozzá, de ennek nem lesz nagy szerepe. Ha akarod, válthatsz protobuf-ra.
- A szolgáltatásnak képesnek kell lennie másodpercenként 10 000 esemény feldolgozására.
- Lehetővé kell tenni a vízszintes méretezést úgy, hogy egyszerűen hozzáadunk új példányokat a megoldásunkhoz. És jó lesz, ha az elülső részt különböző földrajzi helyekre mozgathatjuk, hogy csökkentsük az ügyfélkérések késleltetését.
- Hibatűrés. A megoldásnak kellően stabilnak kell lennie, és képesnek kell lennie túlélni bármely alkatrész leesését (természetesen egy bizonyos számig).
építészet
Általában az ilyen típusú feladatokhoz a klasszikus architektúrákat régóta feltalálták, amelyek lehetővé teszik a hatékony skálázást. Az ábra példát mutat megoldásunkra.
Tehát amink van:
1. A bal oldalon különböző eseményeket generáló készülékeink láthatók, legyen szó akár egy játékban pályát teljesítő játékosról okostelefonon, vagy rendelésről egy online áruházban egy normál böngészőn keresztül. Az esemény a specifikációban meghatározottak szerint egy egyszerű JSON, amely a végpontunkra – events.kis.im – kerül elküldésre.
2. Az első két szerver egyszerű egyensúlyozó, fő feladataik:
- Legyen folyamatosan elérhető. Ehhez használhatja például a keepalivedet, amely probléma esetén váltja a virtuális IP-t a csomópontok között.
- Szüntesse meg a TLS-t. Igen, megszüntetjük rajtuk a TLS-t. Egyrészt azért, hogy megoldásunk megfeleljen a műszaki előírásoknak, másodsorban pedig azért, hogy tehermentesítse a titkosított kapcsolat létesítését backend szervereinkről.
- Egyensúlyozza a bejövő kéréseket az elérhető háttérkiszolgálók felé. A kulcsszó itt elérhető. Ennek alapján arra a felismerésre jutottunk, hogy a terheléselosztóknak képesnek kell lenniük a szervereink alkalmazásainak megfigyelésére, és le kell állítaniuk a forgalom kiegyensúlyozását a meghibásodott csomópontokhoz.
3. A kiegyenlítők után olyan alkalmazásszervereink vannak, amelyek egy meglehetősen egyszerű alkalmazást futtatnak. Képesnek kell lennie fogadni a HTTP-n keresztül bejövő kéréseket, érvényesíteni az elküldött json-t, és el kell helyezni az adatokat egy pufferbe.
4. A diagram pufferként mutatja a kafkát, bár természetesen ezen a szinten más hasonló szolgáltatások is használhatók. Kafkát, rabbitmq-t és yq-t fogunk összehasonlítani a harmadik cikkben.
5. Architektúránk utolsó előtti pontja a Clickhouse – egy oszlopos adatbázis, amely hatalmas mennyiségű adat tárolását és feldolgozását teszi lehetővé. Ezen a szinten adatokat kell átvinnünk a pufferből magához a tárolórendszerhez (erről bővebben a 4. cikkben).
Ez a kialakítás lehetővé teszi, hogy minden réteget egymástól függetlenül vízszintesen méretezzünk. A háttérkiszolgálók nem tudnak megbirkózni - tegyük még hozzá -, elvégre állapot nélküli alkalmazások, ezért ez akár automatikusan is megtehető. A Kafka-stílusú puffer nem működik – adjunk hozzá több szervert, és vigyük át rájuk a témánk egyes partícióit. A Clickhouse nem tudja kezelni – lehetetlen :) Sőt, a szervereket is összekapcsoljuk, és az adatokat is szilánkokra vágjuk.
Egyébként, ha a műszaki specifikációnk és a méretarányunk opcionális részét szeretné megvalósítani különböző földrajzi helyeken, akkor nincs egyszerűbb:
Minden földrajzi helyen egy terheléselosztót helyezünk el alkalmazással és kafkával. Általában elegendő 2 alkalmazásszerver, 3 kafka csomópont és egy felhőkiegyenlítő, például a cloudflare, amely a kliens forrás IP-címe alapján geolokáció szerint ellenőrzi az alkalmazáscsomópontok elérhetőségét és az egyensúlyi kéréseket. Így az amerikai kliens által küldött adatok amerikai szervereken landolnak. Az afrikai adatok pedig afrikai nyelvűek.
Ezután minden nagyon egyszerű - a Kafka készlet tüköreszközét használjuk, és minden helyről átmásoljuk az összes adatot Oroszországban található központi adatközpontunkba. Belsőleg elemezzük az adatokat, és rögzítjük a Clickhouse-ban a későbbi megjelenítéshez.
Tehát megoldottuk az architektúrát – kezdjük megrázni a Yandex.Cloudot!
Pályázat írása
A Felhő előtt még egy kicsit türelmesnek kell lennie, és egy meglehetősen egyszerű szolgáltatást kell írnia a bejövő események feldolgozásához. Golangot fogunk használni, mert nagyon jól bevált nyelvként a hálózati alkalmazások írására.
Egy óra (talán pár óra) eltöltöttsége után valami ilyesmit kapunk: .
Melyek a főbb pontok, amelyeket itt szeretnék megjegyezni:
1. Az alkalmazás indításakor két zászlót adhat meg. Az egyik felelős azért a portért, amelyen meghallgatjuk a bejövő http kéréseket (-addr). A második a kafka szerver címére vonatkozik, ahol az eseményeinket rögzítjük (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. Az alkalmazás a sarama könyvtárat használja () üzenetek küldéséhez a kafka klaszternek. Azonnal beállítjuk a maximális feldolgozási sebességet célzó beállításokat:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Alkalmazásunk beépített prometheus klienssel is rendelkezik, amely különféle mutatókat gyűjt, mint például:
- az alkalmazásunkhoz érkezett kérések száma;
- hibák száma a kérés végrehajtása során (nem olvasható a bejegyzéskérés, hibás json, lehetetlen Kafkának írni);
- az ügyféltől érkező egy kérés feldolgozási ideje, beleértve a Kafkának szóló üzenet írásának idejét is.
4. Az alkalmazásunk által feldolgozott három végpont:
- /status - egyszerűen adja vissza az OK-t, hogy megmutassa, hogy élünk. Bár hozzáadhat néhány ellenőrzést, például a Kafka-fürt elérhetőségét.
- /metrics - ennek az URL-nek megfelelően a prometheus kliens visszaadja az általa összegyűjtött mérőszámokat.
- A /post a fő végpont, ahová a json-t tartalmazó POST-kérések elküldésre kerülnek. Alkalmazásunk ellenőrzi a json érvényességét, és ha minden rendben van, kiírja az adatokat a Kafka-fürtbe.
Foglalkozom azzal, hogy a kód nem tökéletes – lehet (és kell is!) kitölteni. Például abbahagyhatja a beépített net/http használatát, és átválthat a gyorsabb fasthttp-re. Vagy feldolgozási időt és processzorerőforrást nyerhet, ha a json érvényességi ellenőrzését egy későbbi szakaszba helyezi át – amikor az adatok a pufferből a clickhouse-fürtbe kerülnek.
A probléma fejlesztési oldala mellett azonnal átgondoltuk jövőbeli infrastruktúránkat, és úgy döntöttünk, hogy alkalmazásunkat dockeren keresztül telepítjük. Az utolsó Docker-fájl az alkalmazás elkészítéséhez . Általánosságban elmondható, hogy ez nagyon egyszerű, az egyetlen pont, amire szeretnék figyelni, az a többlépcsős összeszerelés, amely lehetővé teszi a konténerünk végső képének csökkentését.
Első lépések a felhőben
Először is regisztráljon . Az összes szükséges mező kitöltése után fiókot hozunk létre, és egy bizonyos összegű támogatást kapunk, amelyet a felhőszolgáltatások tesztelésére fordíthatunk. Ha meg szeretné ismételni cikkünk összes lépését, akkor ez a támogatás elegendő lesz Önnek.
A regisztráció után egy külön felhő és egy alapértelmezett könyvtár jön létre számodra, amelyben elkezdheted a felhő erőforrások létrehozását. Általában a Yandex.Cloudban az erőforrások kapcsolata így néz ki:
Egy fiókhoz több felhőt is létrehozhat. A felhőn belül pedig készítsen különböző könyvtárakat a különböző vállalati projektekhez. Erről bővebben a dokumentációban olvashat - . Mellesleg az alábbiakban gyakran hivatkozom rá a szövegben. Amikor a teljes infrastruktúrát a semmiből beállítottam, a dokumentáció nem egyszer segített, ezért azt tanácsolom, hogy tanulmányozza át.
A felhő kezeléséhez használhatja a webes felületet és a konzol segédprogramot is - yc. A telepítés egy paranccsal történik (Linux és Mac OS esetén):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashHa az Ön belső biztonsági szakembere azon tombol, hogy szkripteket futtasson az internetről, akkor először is megnyithatja a szkriptet és elolvashatja, másodszor pedig a felhasználónk alatt futtatjuk - root jogok nélkül.
Ha Windows-ügyfelet szeretne telepíteni, kövesse az utasításokat majd végrehajtani yc initteljes testreszabásához:
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:~ $Elvileg a folyamat egyszerű - először be kell szereznie egy oauth tokent a felhő kezeléséhez, ki kell választania a felhőt és a használni kívánt mappát.
Ha több fiókkal vagy mappával rendelkezik ugyanabban a felhőben, további profilokat hozhat létre külön beállításokkal az yc config profile Create és válthat közöttük.
A fenti módszerek mellett a Yandex.Cloud csapata nagyon jót írt felhő erőforrások kezeléséhez. A magam részéről elkészítettem egy git tárat, ahol leírtam a cikk részeként létrejövő összes erőforrást - . Érdekel minket a master ág, klónozzuk helyben:
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/A terraformban használt összes fő változó a main.tf fájlba van írva. A kezdéshez hozzon létre egy private.auto.tfvars fájlt a terraform mappában a következő tartalommal:
# 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 = ""Minden változó kivehető az yc konfigurációs listából, mivel a konzol segédprogramot már beállítottuk. Azt tanácsolom, hogy azonnal add hozzá a private.auto.tfvars fájlt a .gitignore-hoz, nehogy véletlenül privát adatokat tegyen közzé.
A private.auto.tfvars fájlban a Cloudflare adatait is megadtuk – DNS-rekordok létrehozásához és az events.kis.im fő tartomány proxyjához a szervereinkhez. Ha nem szeretné használni a cloudflare-t, akkor távolítsa el a cloudflare szolgáltató inicializálását a main.tf-ben és a dns.tf fájlban, amely a szükséges dns rekordok létrehozásáért felelős.
Munkánk során mindhárom módszert kombináljuk - a webes felületet, a konzol segédprogramot és a terraformot.
Virtuális hálózatok
Őszintén szólva kihagyhatja ezt a lépést, mivel amikor új felhőt hoz létre, automatikusan létrejön egy külön hálózat és 3 alhálózat – minden rendelkezésre állási zónához egy. De továbbra is szeretnénk egy külön hálózatot létrehozni a projektünk számára, saját címzéssel. A hálózat működésének általános diagramja a Yandex.Cloudban az alábbi ábrán látható (őszintén: )
Tehát létrehoz egy közös hálózatot, amelyen belül az erőforrások kommunikálhatnak egymással. Minden rendelkezésre állási zónához egy alhálózat jön létre saját címzéssel, és csatlakozik az általános hálózathoz. Ennek eredményeként az összes felhő-erőforrás képes kommunikálni, még akkor is, ha különböző rendelkezésre állási zónákban vannak. A különböző felhőhálózatokhoz kapcsolódó erőforrások csak külső címeken keresztül láthatják egymást. Egyébként hogyan működik ez a varázslat belül, .
A hálózat létrehozását a tárolóból származó network.tf fájl írja le. Ott létrehozunk egy közös belső magánhálózatot, és három alhálózatot csatlakoztatunk hozzá különböző rendelkezésre állási zónákban - belső-a (172.16.1.0/24), belső-b (172.16.2.0/24), belső-c (172.16.3.0/24). ).
A terraform inicializálása és hálózatok létrehozása:
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.Nagy! Létrehoztuk hálózatunkat, és készen állunk belső szolgáltatásaink létrehozására.
Virtuális gépek létrehozása
Az alkalmazás teszteléséhez mindössze két virtuális gépet kell létrehoznunk - az elsőre az alkalmazás felépítéséhez és futtatásához, a másodikhoz a kafka futtatásához lesz szükségünk, amelyet a bejövő üzenetek tárolására fogunk használni. És létrehozunk egy másik gépet, ahol beállítjuk a Prometheust az alkalmazás figyelésére.
A virtuális gépek az ansible használatával lesznek konfigurálva, ezért a terraform elindítása előtt győződjön meg arról, hogy az ansible egyik legújabb verziójával rendelkezik. És telepítse a szükséges szerepeket az ansible galaxy segítségével:
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) $Az ansible mappában van egy példa .ansible.cfg konfigurációs fájl, amit használok. Jól jöhet.
A virtuális gépek létrehozása előtt győződjön meg arról, hogy fut az ssh-agent, és hozzáadott egy ssh-kulcsot, különben a terraform nem tud csatlakozni a létrehozott gépekhez. Természetesen egy hibára bukkantam az OS x-ben: . Hogy ez ne ismétlődhessen meg, adjon hozzá egy kis változót az env-hez a Terraform elindítása előtt:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESA terraform mappában létrehozzuk a szükséges erőforrásokat:
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 ...Ha minden sikeresen végződött (és annak kell lennie), akkor három virtuális gépünk lesz:
- build - egy gép egy alkalmazás tesztelésére és felépítésére. A Dockert az Ansible automatikusan telepítette.
- monitorozás - felügyeleti gép - prometheus & grafana telepítve rá. Bejelentkezés / jelszó szabvány: admin / admin
- A kafka egy kis gép kafkával, amely a 9092-es porton érhető el.
Győződjön meg arról, hogy mindegyik a helyén van:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Az erőforrások a helyükön vannak, és innen kapjuk meg az IP-címüket. A következőkben mindvégig IP-címeket fogok használni az ssh-n keresztüli csatlakozáshoz és az alkalmazás teszteléséhez. Ha a terraformhoz kapcsolódik egy cloudflare-fiók, nyugodtan használjon frissen létrehozott DNS-neveket.
A virtuális gép létrehozásakor egyébként egy belső IP-címet és egy belső DNS-nevet adnak meg, így név szerint érheti el a hálózaton belüli szervereket:
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 msEz hasznos lesz, ha az alkalmazásnak a kafk végpontot jelzi.
Az alkalmazás összeállítása
Remek, vannak szerverek, van egy alkalmazás – már csak össze kell rakni és közzé kell tenni. A felépítéshez a szokásos docker buildet használjuk, de képtárként a Yandex - konténer-nyilvántartás szolgáltatását fogjuk használni. De először a dolgok.
Másoljuk az alkalmazást a build gépre, bejelentkezünk ssh-n keresztül és összeállítjuk a képet:
vozerov@mba:~/events/terraform (master) $ cd ..
vozerov@mba:~/events (master) $ rsync -av app/ [email protected]:app/
... skipped ...
sent 3849 bytes received 70 bytes 7838.00 bytes/sec
total size is 3644 speedup is 0.93
vozerov@mba:~/events (master) $ ssh 84.201.132.3 -l ubuntu
ubuntu@build:~$ cd app
ubuntu@build:~/app$ sudo docker build -t app .
Sending build context to Docker daemon 6.144kB
Step 1/9 : FROM golang:latest AS build
... skipped ...
Successfully built 9760afd8ef65
Successfully tagged app:latestA fél csata kész – most már ellenőrizhetjük az alkalmazásunk működőképességét úgy, hogy elindítjuk és elküldjük a kafkának:
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) $Az alkalmazás sikeresen válaszolt a rögzítésre, és megadta annak a partíciónak az azonosítóját és az eltolást, amelyben az üzenet szerepel. Nem kell mást tenni, mint létrehozni egy registry-t a Yandex.Cloudban, és oda feltölteni a képünket (a registry.tf fájlban van leírva, hogyan kell ezt három sorral megtenni). Tárhely létrehozása:
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.Számos módja van a hitelesítésnek a tároló-nyilvántartásban – egy oauth-jogkivonat, egy iam-token vagy egy szolgáltatásfiókkulcs használatával. Ezekről a módszerekről további részletek a dokumentációban találhatók. . A szolgáltatási fiók kulcsát fogjuk használni, így létrehozunk egy fiókot:
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.Most már csak egy kulcsot kell készíteni hozzá:
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_2048Tájékoztatást kapunk tárhelyünk azonosítójáról, átadjuk a kulcsot és bejelentkezünk:
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:~$A kép regisztrációs adatbázisba való feltöltéséhez szükségünk van a konténer regisztrációs azonosítójára, amelyet az yc segédprogramból veszünk:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Ezt követően új névvel látjuk el a képünket, és feltöltjük:
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: 946Ellenőrizhetjük, hogy a kép sikeresen betöltődött:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Egyébként, ha az yc segédprogramot Linuxos gépre telepíted, használhatod a parancsot
yc container registry configure-dockerdokkoló konfigurálásához.
Következtetés
Nagyon kemény munkát végeztünk, és ennek eredményeként:
- Megtaláltuk jövőbeli szolgáltatásunk architektúráját.
- Golang nyelven írtunk egy alkalmazást, amely megvalósítja az üzleti logikánkat.
- Összegyűjtöttük és egy privát konténernyilvántartásba öntöttük.
A következő részben rátérünk az érdekes dolgokra – kiadjuk az alkalmazásunkat éles üzembe, és végül elindítjuk rajta a betöltést. Ne válts!
Ez az anyag a REBRAIN & Yandex.Cloud nyílt workshop videófelvételén található: A Yandex Cloudon másodpercenként 10 000 kérést fogadunk el -
Ha szeretne online részt venni az ilyen eseményeken, és valós időben szeretne kérdéseket feltenni, csatlakozzon.
Szeretnénk külön köszönetet mondani a Yandex.Cloudnak a lehetőségért, hogy egy ilyen eseményt rendezhetett. Link hozzájuk -
Ha át kell térnie a felhőre, vagy kérdései vannak az infrastruktúrával kapcsolatban, .
PS Havonta 2 ingyenes auditunk van, talán az Ön projektje lesz az egyik ilyen.
Forrás: will.com