Hei kaikille, ystävät!
* Tämä artikkeli perustuu REBRAIN & Yandex.Cloud avoimeen työpajaan, jos haluat katsoa videon, löydät sen tästä linkistä -
Meillä oli äskettäin mahdollisuus kokeilla Yandex.Cloudia livenä. Koska halusimme tutkia pitkään ja hartaasti, hylkäsimme heti ajatuksesta käynnistää yksinkertainen Wordpress-blogi pilvipohjaisella pohjalla - se oli liian tylsää. Hetken harkinnan jälkeen päätimme ottaa käyttöön jotain tuotantopalveluarkkitehtuurin kaltaista tapahtumien vastaanottamista ja analysointia lähes reaaliajassa.
Olen täysin varma, että valtaosa verkkoyrityksistä (eikä vain) kerää jollain tavalla joukon tietoja käyttäjistään ja heidän toimistaan. Tämä on vähintään välttämätöntä tiettyjen päätösten tekemiseksi - esimerkiksi jos hallitset online-peliä, voit tarkastella tilastoja, millä tasolla käyttäjät useimmiten juuttuvat ja poistavat lelusi. Tai miksi käyttäjät poistuvat sivustostasi ostamatta mitään (hei, Yandex.Metrica).
Joten, meidän tarinamme: kuinka kirjoitimme sovelluksen golangilla, testasimme kafka vs rabbitmq vs yqs, kirjoitimme datan suoratoistoa Clickhouse-klusteriin ja visualisoimme tiedot yandex-tietolinssien avulla. Luonnollisesti kaikki tämä maustettiin infrastruktuurin herkuilla dockerin, terraformin, gitlab ci:n ja tietysti prometheuksen muodossa. Mennään!
Haluaisin heti tehdä varauksen, että emme voi määrittää kaikkea yhdellä istumalla - tätä varten tarvitsemme useita artikkeleita sarjassa. Vähän rakenteesta:
Osa 1 (luet sitä). Päätämme ratkaisun spesifikaatioista ja arkkitehtuurista sekä kirjoitamme myös hakemuksen golangilla.
Osa 2. Julkaisemme sovelluksemme tuotantoon, teemme siitä skaalautuvan ja testaamme kuormitusta.
Osa 3. Yritetään selvittää, miksi meidän täytyy tallentaa viestejä puskuriin eikä tiedostoihin, ja vertailla myös kafka-, rabbitmq- ja yandex-jonopalveluita.
Osa 4 Otamme käyttöön Clickhouse-klusterin, kirjoitamme suoratoistopalvelun datan siirtämiseksi puskurista sinne ja asetamme visualisoinnin datalinsseihin.
Osa 5 Laitetaan koko infrastruktuuri oikeaan kuntoon - määritetään ci/cd gitlab ci:n avulla, yhdistetään valvonta ja palvelunhaku prometheuksen ja consulin avulla.
TK
Ensin muotoillaan toimeksianto - mitä tarkalleen haluamme saada tuloksena.
- Haluamme päätepisteen, kuten events.kis.im (kis.im on testialue, jota käytämme kaikissa artikkeleissa), jonka pitäisi vastaanottaa tapahtumia HTTPS:n avulla.
- Tapahtumat ovat yksinkertaisia json-tiedostoja, kuten: {"event": "view", "os": "linux", "browser": "chrome"}. Viimeisessä vaiheessa lisäämme hieman lisää kenttiä, mutta tällä ei ole suurta merkitystä. Halutessasi voit vaihtaa protobufiin.
- Palvelun tulee pystyä käsittelemään 10 000 tapahtumaa sekunnissa.
- Vaakasuuntaisen skaalauksen pitäisi olla mahdollista yksinkertaisesti lisäämällä uusia esiintymiä ratkaisuumme. Ja olisi mukavaa, jos voimme siirtää etuosan eri maantieteellisiin paikkoihin vähentääksemme asiakkaiden pyyntöjen latenssia.
- Vikasietoisuus. Ratkaisun on oltava riittävän vakaa ja kestettävä minkä tahansa osien putoaminen (tietysti tiettyyn määrään asti).
Arkkitehtuuri
Yleisesti ottaen tämän tyyppisiin tehtäviin on jo pitkään keksitty klassisia arkkitehtuureja, jotka mahdollistavat tehokkaan skaalauksen. Kuvassa on esimerkki ratkaisustamme.
Eli mitä meillä on:
1. Vasemmalla ovat laitteemme, jotka luovat erilaisia tapahtumia, olipa kyseessä sitten pelaajat suorittamassa tasoa lelussa älypuhelimella tai tekemässä tilausta verkkokaupassa tavallisen selaimen kautta. Spesifikaatiossa määritetty tapahtuma on yksinkertainen json, joka lähetetään päätepisteeseemme - events.kis.im.
2. Kaksi ensimmäistä palvelinta ovat yksinkertaisia tasapainottajia, niiden päätehtävät ovat:
- Ole jatkuvasti saatavilla. Tätä varten voit käyttää esimerkiksi Keepalived-toimintoa, joka vaihtaa virtuaalisen IP:n solmujen välillä ongelmatilanteissa.
- Lopeta TLS. Kyllä, lopetamme niiden TLS:n. Ensinnäkin, jotta ratkaisumme vastaa teknisiä vaatimuksia, ja toiseksi, jotta kevennetään salatun yhteyden muodostamista taustapalvelimistamme.
- Tasaa saapuvat pyynnöt käytettävissä oleville taustapalvelimille. Avainsana tässä on saavutettavissa. Tämän perusteella tulemme ymmärtämään, että kuormituksen tasapainottajien on kyettävä valvomaan palvelimiamme sovelluksilla ja lopettamaan liikenteen tasapainottaminen epäonnistuneisiin solmuihin.
3. Tasapainottimien jälkeen meillä on sovelluspalvelimet, jotka pyörittävät melko yksinkertaista sovellusta. Sen pitäisi pystyä hyväksymään saapuvat pyynnöt HTTP:n kautta, vahvistamaan lähetetty json ja sijoittamaan tiedot puskuriin.
4. Kaavio näyttää kafkan puskurina, vaikka tällä tasolla voidaan tietysti käyttää muita vastaavia palveluita. Vertailemme Kafkaa, rabbitmq:ää ja yq:a kolmannessa artikkelissa.
5. Arkkitehtuurimme toiseksi viimeinen kohta on Clickhouse - saraketietokanta, jonka avulla voit tallentaa ja käsitellä valtavan määrän tietoa. Tällä tasolla meidän on siirrettävä tiedot puskurista itse tallennusjärjestelmään (lisätietoja artikkelissa 4).
Tämän suunnittelun avulla voimme skaalata jokaisen kerroksen itsenäisesti vaakasuunnassa. Taustapalvelimet eivät kestä - lisätään vielä yksi asia - ne ovat loppujen lopuksi tilattomia sovelluksia, ja siksi tämä voidaan tehdä jopa automaattisesti. Kafka-tyylinen puskuri ei toimi – lisätään enemmän palvelimia ja siirretään osa aiheemme osioista niihin. Clickhouse ei kestä sitä - se on mahdotonta :) Itse asiassa yhdistämme myös palvelimet ja sirpaloimme tiedot.
Muuten, jos haluat toteuttaa valinnaisen osan teknisistä eritelmistämme ja mittakaavasta eri maantieteellisissä paikoissa, mikään ei ole yksinkertaisempaa:
Jokaisessa maantieteellisessä sijainnissa otamme käyttöön kuormantasauslaitteen, jossa on sovellus ja kafka. Yleisesti ottaen 2 sovelluspalvelinta, 3 kafka-solmua ja pilvitasapainotin, esimerkiksi cloudflare, riittävät, jotka tarkistavat sovellussolmujen saatavuuden ja tasapainottavat pyynnöt maantieteellisen sijainnin mukaan asiakkaan lähde-IP-osoitteen perusteella. Näin ollen amerikkalaisen asiakkaan lähettämät tiedot päätyvät amerikkalaisille palvelimille. Ja tiedot Afrikasta ovat afrikkalaisia.
Sitten kaikki on melko yksinkertaista - käytämme Kafka-sarjan peilityökalua ja kopioimme kaikki tiedot kaikista paikoista Venäjällä sijaitsevaan keskuspalvelinkeskukseemme. Sisäisesti jäsennämme tiedot ja tallennamme ne Clickhouseen myöhempää visualisointia varten.
Joten, olemme selvittäneet arkkitehtuurin - aloitetaan ravistelemaan Yandex.Cloudia!
Hakemuksen kirjoittaminen
Ennen Pilviä sinun on vielä oltava hieman kärsivällinen ja kirjoitettava melko yksinkertainen palvelu saapuvien tapahtumien käsittelemiseksi. Käytämme golangia, koska se on osoittautunut erittäin hyvin verkkosovellusten kirjoituskieleksi.
Vietettyämme tunnin (ehkä muutaman tunnin) saamme jotain tällaista: .
Mitkä ovat tärkeimmät kohdat, jotka haluaisin tässä huomioida:
1. Kun käynnistät sovelluksen, voit määrittää kaksi lippua. Yksi on vastuussa portista, jolla kuuntelemme saapuvia http-pyyntöjä (-addr). Toinen on kafka-palvelimen osoite, johon tallennamme tapahtumamme (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. Sovellus käyttää sarama-kirjastoa () lähettääksesi viestejä kafka-klusteriin. Asetamme välittömästi asetukset, joiden tavoitteena on suurin käsittelynopeus:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Sovelluksessamme on myös sisäänrakennettu prometheus-asiakas, joka kerää erilaisia mittareita, kuten:
- hakemusten määrä;
- virheiden määrä pyyntöä suoritettaessa (postipyyntöä ei voi lukea, json on rikki, Kafkaan ei voi kirjoittaa);
- yhden asiakkaan pyynnön käsittelyaika, mukaan lukien Kafkalle viestin kirjoittamisen aika.
4. Kolme päätepistettä, jotka sovelluksemme käsittelee:
- /status - vain palauttaa ok osoittaaksesi, että olemme elossa. Vaikka voit lisätä joitain tarkistuksia, kuten Kafka-klusterin saatavuus.
- /metrics - tämän URL-osoitteen mukaan prometheus-asiakas palauttaa keräämänsä mittarit.
- /post on pääpäätepiste, johon lähetetään POST-pyynnöt, joissa on json. Sovelluksemme tarkistaa jsonin kelvollisuuden ja jos kaikki on kunnossa, se kirjoittaa tiedot Kafka-klusteriin.
Teen varauksen, että koodi ei ole täydellinen - se voidaan (ja pitäisi!) täydentää. Voit esimerkiksi lopettaa sisäänrakennetun net/http:n käytön ja vaihtaa nopeampaan fasthttp:ään. Tai voit saada käsittelyaikaa ja prosessoriresursseja siirtämällä json-kelpoisuustarkistuksen myöhempään vaiheeseen - kun tiedot siirretään puskurista clickhouse-klusteriin.
Asian kehityspuolen lisäksi mietimme heti tulevaa infrastruktuuriamme ja päätimme ottaa sovelluksemme käyttöön dockerin kautta. Viimeinen Docker-tiedosto sovelluksen rakentamiseen on . Yleisesti ottaen se on melko yksinkertainen, ainoa asia, johon haluaisin kiinnittää huomiota, on monivaiheinen kokoonpano, jonka avulla voimme pienentää konttimme lopullista kuvaa.
Ensimmäiset askeleet pilvessä
Ensinnäkin, rekisteröidy . Kun kaikki tarvittavat kentät on täytetty, meille luodaan tili ja myönnetään tietylle rahasummalle apuraha, jolla voidaan testata pilvipalveluita. Jos haluat toistaa kaikki artikkelimme vaiheet, tämän apurahan pitäisi riittää sinulle.
Rekisteröinnin jälkeen sinulle luodaan erillinen pilvi ja oletushakemisto, jossa voit aloittaa pilviresurssien luomisen. Yleensä Yandex.Cloudissa resurssien suhde näyttää tältä:
Voit luoda useita pilviä yhdelle tilille. Ja tee pilven sisällä erilaisia hakemistoja eri yritysprojekteille. Voit lukea tästä lisää dokumentaatiosta - . Muuten, viittaan siihen usein alla tekstissä. Kun perustin koko infrastruktuurin tyhjästä, dokumentaatio auttoi minua useammin kuin kerran, joten suosittelen tutkimaan sitä.
Pilven hallintaan voit käyttää sekä verkkokäyttöliittymää että konsoliapuohjelmaa - yc. Asennus suoritetaan yhdellä komennolla (Linuxille ja Mac OS:lle):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashJos sisäisen turvallisuuden asiantuntijasi raivoaa skriptien suorittamisesta Internetistä, voit ensinnäkin avata skriptin ja lukea sen, ja toiseksi, suoritamme sen käyttäjämme alla - ilman pääkäyttäjän oikeuksia.
Jos haluat asentaa Windows-asiakkaan, voit käyttää ohjeita ja sitten suorittaa yc initmuokataksesi sitä täysin:
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:~ $Periaatteessa prosessi on yksinkertainen - sinun on ensin hankittava oauth-tunnus pilven hallintaan, valittava pilvi ja käytettävä kansio.
Jos sinulla on useita tilejä tai kansioita samassa pilvessä, voit luoda lisäprofiileja erillisillä asetuksilla käyttämällä yc config profile create ja vaihtaa niiden välillä.
Yllä olevien menetelmien lisäksi Yandex.Cloud-tiimi kirjoitti erittäin hyvän pilviresurssien hallintaan. Omalta osaltani valmistelin git-arkiston, jossa kuvailin kaikki artikkelin osana luotavat resurssit - . Meitä kiinnostaa päähaara, kloonataan se paikallisesti:
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/Kaikki tärkeimmät terraformissa käytetyt muuttujat kirjoitetaan main.tf-tiedostoon. Aloita luomalla terraform-kansioon private.auto.tfvars-tiedosto, jossa on seuraava sisältö:
# 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 = ""Kaikki muuttujat voidaan ottaa yc-asetusluettelosta, koska olemme jo määrittäneet konsoliapuohjelman. Suosittelen lisäämään välittömästi private.auto.tfvars .gitignore-tiedostoon, jotta et julkaise yksityisiä tietoja vahingossa.
Kohdassa private.auto.tfvars määritimme myös tiedot Cloudflaresta DNS-tietueiden luomiseksi ja pääverkkotunnuksen events.kis.im välityspalvelimelle. Jos et halua käyttää cloudflarea, poista cloudflare-palveluntarjoajan alustus main.tf:stä ja dns.tf-tiedostosta, joka vastaa tarvittavien dns-tietueiden luomisesta.
Yhdistämme työssämme kaikki kolme menetelmää - verkkokäyttöliittymän, konsoliapuohjelman ja terraformin.
Virtuaaliset verkot
Ollakseni rehellinen, voit ohittaa tämän vaiheen, koska kun luot uuden pilven, sinulle luodaan automaattisesti erillinen verkko ja 3 aliverkkoa - yksi jokaiselle saatavuusvyöhykkeelle. Mutta silti haluaisimme tehdä projektiimme erillisen verkon omalla osoitteellaan. Yleinen kaavio verkon toiminnasta Yandex.Cloudissa näkyy alla olevassa kuvassa (rehellisesti otettuna )
Joten luot yhteisen verkon, jossa resurssit voivat kommunikoida keskenään. Jokaiselle käytettävyysvyöhykkeelle luodaan aliverkko omalla osoitteellaan ja yhdistetään yleiseen verkkoon. Tämän seurauksena kaikki sen pilviresurssit voivat kommunikoida, vaikka ne olisivat eri saatavuusvyöhykkeillä. Eri pilviverkkoihin yhdistetyt resurssit voivat nähdä toisensa vain ulkoisten osoitteiden kautta. Muuten, kuinka tämä taika toimii sisällä, .
Verkon luominen on kuvattu arkiston network.tf-tiedostossa. Siellä luodaan yksi yhteinen yksityinen sisäinen verkko ja liitetään siihen kolme aliverkkoa eri käytettävyysvyöhykkeillä - sisäinen-a (172.16.1.0/24), sisäinen-b (172.16.2.0/24), sisäinen-c (172.16.3.0/24). ).
Alusta terraform ja luo verkostoja:
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.Loistava! Olemme luoneet verkostomme ja olemme nyt valmiita luomaan sisäiset palvelumme.
Virtuaalikoneiden luominen
Sovelluksen testaamiseksi tarvitsemme vain kaksi virtuaalikoneen - tarvitsemme ensimmäisen rakentamaan ja suorittamaan sovelluksen, toisen suorittamaan kafkan, jota käytämme saapuvien viestien tallentamiseen. Ja luomme toisen koneen, jossa määritämme prometheuksen valvomaan sovellusta.
Virtuaalikoneet konfiguroidaan ansiblen avulla, joten ennen terraformin aloittamista varmista, että sinulla on jokin uusimmista ansible-versioista. Ja asenna tarvittavat roolit ansible galaxylla:
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-kansion sisällä on käyttämäni esimerkki .ansible.cfg-määritystiedosto. Se voi tulla tarpeeseen.
Ennen kuin luot virtuaalikoneita, varmista, että ssh-agent on käynnissä ja ssh-avain lisätty, muuten terraform ei pysty muodostamaan yhteyttä luotuihin koneisiin. Tietysti törmäsin virheeseen os x:ssä: . Jotta tämä ei toistu, lisää env:hen pieni muuttuja ennen Terraformin käynnistämistä:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESTerraformin kansioon luomme tarvittavat resurssit:
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 ...Jos kaikki päättyi onnistuneesti (ja sen pitäisi olla), meillä on kolme virtuaalikonetta:
- build - kone sovelluksen testaamiseen ja rakentamiseen. Ansible asensi Dockerin automaattisesti.
- valvonta - valvontakone - prometheus & grafana asennettuna siihen. Kirjautumis- / salasanastandardi: admin / admin
- kafka on pieni kone, johon on asennettu kafka, ja siihen pääsee portista 9092.
Varmistetaan, että ne ovat kaikki paikoillaan:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
Resurssit ovat paikoillaan, ja täältä saamme heidän IP-osoitteensa. Seuraavassa käytän IP-osoitteita yhteyden muodostamiseen ssh:n kautta ja sovelluksen testaamiseen. Jos sinulla on terraformiin yhdistetty cloudflare-tili, voit käyttää juuri luotuja DNS-nimiä.
Muuten, virtuaalikoneen luomisen yhteydessä annetaan sisäinen IP-osoite ja sisäinen DNS-nimi, joten voit käyttää verkon palvelimia nimellä:
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 msTästä on hyötyä, kun voimme osoittaa sovellukselle päätepisteen kafk:lla.
Sovelluksen kokoaminen
Hienoa, on palvelimia, on sovellus - jäljellä on vain koota se ja julkaista se. Rakennuksessa käytämme tavallista Docker-rakennusta, mutta kuvatallennustilana käytämme Yandex-konttirekisterin palvelua. Mutta ensin asiat ensin.
Kopioimme sovelluksen rakennuskoneelle, kirjaudumme sisään ssh:n kautta ja kokoamme kuvan:
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:latestPuolet taistelusta on tehty - nyt voimme tarkistaa sovelluksemme toimivuuden käynnistämällä sen ja lähettämällä sen kafkalle:
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) $Sovellus vastasi onnistuneesti tallennuksessa ja ilmoitti sen osion tunnuksen ja offsetin, johon viesti sisältyi. Sinun tarvitsee vain luoda rekisteri Yandex.Cloudiin ja ladata kuvamme sinne (kuten tämä tehdään kolmella rivillä, on kuvattu registry.tf-tiedostossa). Luo tallennustila:
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.Säilörekisterissä on useita tapoja todentaa - käyttämällä oauth-tunnusta, iam-tunnusta tai palvelutilin avainta. Lisätietoja näistä menetelmistä löytyy dokumentaatiosta. . Käytämme palvelutilin avainta, joten luomme tilin:
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.Nyt ei jää muuta kuin tehdä avain sille:
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_2048Saamme tiedon varastomme tunnuksesta, siirrämme avaimen ja kirjaudumme sisään:
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:~$Kuvan lataamiseksi rekisteriin tarvitsemme säilön rekisteritunnuksen, otamme sen yc-apuohjelmasta:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Sen jälkeen merkitsemme kuvamme uudella nimellä ja lataamme:
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: 946Voimme varmistaa, että kuvan lataus onnistui:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Muuten, jos asennat yc-apuohjelman Linux-koneeseen, voit käyttää komentoa
yc container registry configure-dockertelakan määrittämiseen.
Johtopäätös
Olemme tehneet paljon kovaa työtä ja tuloksena:
- Löysimme tulevaisuuden palvelumme arkkitehtuurin.
- Kirjoitimme golangilla sovelluksen, joka toteuttaa liiketoimintalogiikkaamme.
- Keräsimme sen ja kaadimme sen yksityiseen konttirekisteriin.
Seuraavassa osassa siirrymme mielenkiintoisiin asioihin - julkaisemme sovelluksemme tuotantoon ja viimein käynnistämme sen lataamisen. Älä vaihda!
Tämä materiaali on avoimen työpajan REBRAIN & Yandex.Cloud videotallenteessa: Otamme vastaan 10 000 pyyntöä sekunnissa Yandex Cloudissa -
Jos olet kiinnostunut osallistumaan tällaisiin tapahtumiin verkossa ja esittämään kysymyksiä reaaliajassa, ota yhteyttä.
Haluamme kiittää erityisesti Yandex.Cloudia mahdollisuudesta isännöidä tällainen tapahtuma. Linkki niihin -
Jos sinun on siirryttävä pilveen tai sinulla on kysyttävää infrastruktuuristasi, .
PS Meillä on 2 ilmaista auditointia kuukaudessa, ehkä projektisi on yksi niistä.
Lähde: will.com