Hallo allemaal, vrienden!
* Dit artikel is gebaseerd op de open workshop REBRAIN & Yandex.Cloud. Als je liever de video bekijkt, kun je deze vinden via deze link -
We hebben onlangs de kans gehad om Yandex.Cloud live te proberen. Omdat we lang en hard wilden onderzoeken, lieten we onmiddellijk het idee varen om een eenvoudige Wordpress-blog met een cloudbasis te lanceren - het was te saai. Na enig nadenken hebben we besloten om iets vergelijkbaars met een productieservicearchitectuur in te zetten voor het ontvangen en analyseren van gebeurtenissen in bijna realtimemodus.
Ik ben er absoluut zeker van dat de overgrote meerderheid van online (en niet alleen) bedrijven op de een of andere manier een berg informatie verzamelen over hun gebruikers en hun acties. Dit is op zijn minst nodig om bepaalde beslissingen te nemen. Als u bijvoorbeeld een online game beheert, kunt u in de statistieken kijken op welk niveau gebruikers het vaakst vastlopen en uw speelgoed verwijderen. Of waarom gebruikers uw site verlaten zonder iets te kopen (hallo, Yandex.Metrica).
Dus ons verhaal: hoe we een applicatie in Golang schreven, kafka versus konijnmq versus yqs testten, datastreaming in een Clickhouse-cluster schreven en de gegevens visualiseerden met behulp van yandex datalens. Uiteraard werd dit alles op smaak gebracht met infrastructurele hoogstandjes in de vorm van docker, terraform, gitlab ci en uiteraard prometheus. Laten we gaan!
Ik wil meteen reserveren dat we niet alles in één keer kunnen configureren - hiervoor hebben we meerdere artikelen uit de serie nodig. Iets over de structuur:
Deel 1 (je leest het). We beslissen over de specificaties en architectuur van de oplossing, en schrijven ook een applicatie in golang.
Deel 2. We brengen onze applicatie in productie, maken deze schaalbaar en testen de belasting.
Deel 3. Laten we proberen erachter te komen waarom we berichten in een buffer moeten opslaan en niet in bestanden, en ook de wachtrijservice Kafka, RabbitMQ en Yandex vergelijken.
Deel 4 We gaan een Clickhouse-cluster inzetten, een streamingdienst schrijven om data uit de buffer daar over te zetten, en visualisatie in datalens opzetten.
Deel 5 Laten we de hele infrastructuur in de juiste vorm brengen - zet ci/cd op met gitlab ci, verbind monitoring en service-ontdekking met behulp van prometheus en consul.
TK
Laten we eerst de referentievoorwaarden formuleren: wat we precies als resultaat willen bereiken.
- We willen een eindpunt hebben zoals events.kis.im (kis.im is het testdomein dat we in alle artikelen zullen gebruiken), dat gebeurtenissen zou moeten ontvangen via HTTPS.
- Gebeurtenissen zijn een eenvoudige json zoals: {“event”: “view”, “os”: “linux”, “browser”: “chrome”}. In de laatste fase zullen we nog wat meer velden toevoegen, maar dit zal geen grote rol spelen. Als u wilt, kunt u overschakelen naar protobuf.
- De dienst moet 10 gebeurtenissen per seconde kunnen verwerken.
- Het zou mogelijk moeten zijn om horizontaal te schalen door simpelweg nieuwe instances aan onze oplossing toe te voegen. En het zou leuk zijn als we het voorste gedeelte naar verschillende geolocaties kunnen verplaatsen om de latentie voor klantverzoeken te verminderen.
- Fouttolerantie. De oplossing moet stabiel genoeg zijn en de val van eventuele onderdelen kunnen overleven (uiteraard tot een bepaald aantal).
Architectuur
Over het algemeen zijn voor dit soort taken al lang klassieke architecturen uitgevonden die efficiënte schaalvergroting mogelijk maken. De afbeelding toont een voorbeeld van onze oplossing.
Dus wat we hebben:
1. Aan de linkerkant staan onze apparaten die verschillende evenementen genereren, of het nu spelers zijn die een level in speelgoed op een smartphone voltooien of een bestelling plaatsen in een online winkel via een gewone browser. Een gebeurtenis, zoals gespecificeerd in de specificatie, is een eenvoudige json die naar ons eindpunt wordt verzonden: events.kis.im.
2. De eerste twee servers zijn eenvoudige balancers, hun belangrijkste taken zijn:
- Wees constant beschikbaar. Om dit te doen, kunt u bijvoorbeeld keepalived gebruiken, dat bij problemen het virtuele IP-adres tussen knooppunten schakelt.
- TLS beëindigen. Ja, we zullen TLS voor hen beëindigen. Ten eerste zodat onze oplossing voldoet aan de technische specificaties, en ten tweede om de last van het tot stand brengen van een gecodeerde verbinding vanaf onze backend-servers te verlichten.
- Verdeel inkomende verzoeken over beschikbare backend-servers. Het sleutelwoord hier is toegankelijk. Op basis hiervan komen we tot het inzicht dat load balancers onze servers met applicaties moeten kunnen monitoren en moeten stoppen met het balanceren van verkeer naar defecte knooppunten.
3. Na de balancers hebben we applicatieservers waarop een vrij eenvoudige applicatie draait. Het moet inkomende verzoeken via HTTP kunnen accepteren, de verzonden json kunnen valideren en de gegevens in een buffer kunnen plaatsen.
4. Het diagram toont kafka als buffer, hoewel er uiteraard ook andere soortgelijke diensten op dit niveau kunnen worden gebruikt. We zullen Kafka, konijnmq en yqs vergelijken in het derde artikel.
5. Het voorlaatste punt van onze architectuur is Clickhouse: een kolomvormige database waarmee u een enorme hoeveelheid gegevens kunt opslaan en verwerken. Op dit niveau moeten we gegevens van de buffer naar het opslagsysteem zelf overbrengen (meer hierover in artikel 4).
Met dit ontwerp kunnen we elke laag onafhankelijk horizontaal schalen. Backend-servers kunnen dit niet aan - laten we er nog één ding aan toevoegen - het zijn tenslotte staatloze applicaties en daarom kan dit zelfs automatisch worden gedaan. De buffer in Kafka-stijl werkt niet. Laten we meer servers toevoegen en enkele partities van ons onderwerp ernaar overbrengen. Clickhouse kan het niet aan - het is onmogelijk :) Sterker nog, we zullen ook de servers verbinden en de gegevens delen.
Trouwens, als je het optionele deel van onze technische specificaties wilt implementeren en in verschillende geolocaties wilt schalen, dan is er niets eenvoudiger:
In elke geolocatie zetten we een load balancer in met applicatie en kafka. Over het algemeen zijn 2 applicatieservers, 3 kafka-knooppunten en een cloudbalancer, bijvoorbeeld cloudflare, voldoende, die de beschikbaarheid van applicatieknooppunten controleert en verzoeken balanceert op basis van geolocatie op basis van het bron-IP-adres van de klant. Gegevens die door een Amerikaanse klant worden verzonden, komen dus op Amerikaanse servers terecht. En gegevens uit Afrika zijn in het Afrikaans.
Dan is alles heel eenvoudig: we gebruiken de mirror-tool uit de Kafka-set en kopiëren alle gegevens van alle locaties naar ons centrale datacenter in Rusland. Intern parseren we de gegevens en leggen deze vast in Clickhouse voor latere visualisatie.
Dus we hebben de architectuur uitgezocht - laten we Yandex.Cloud gaan schudden!
Een aanvraag schrijven
Vóór de Cloud moet je nog een beetje geduld hebben en een vrij eenvoudige service schrijven om inkomende gebeurtenissen te verwerken. We zullen golang gebruiken omdat het zich zeer goed heeft bewezen als taal voor het schrijven van netwerkapplicaties.
Na een uur (misschien een paar uur) te hebben doorgebracht, krijgen we zoiets als dit: .
Wat zijn de belangrijkste punten die ik hier wil opmerken:
1. Bij het starten van de applicatie kunt u twee vlaggen opgeven. Eén is verantwoordelijk voor de poort waarop we zullen luisteren naar inkomende http-verzoeken (-addr). De tweede is voor het kafka-serveradres waar we onze evenementen zullen opnemen (-kafka):
addr = flag.String("addr", ":8080", "TCP address to listen to")
kafka = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints”)2. De applicatie maakt gebruik van de sarama-bibliotheek () om berichten naar het kafka-cluster te verzenden. We stellen direct de instellingen in gericht op maximale verwerkingssnelheid:
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForLocal
config.Producer.Compression = sarama.CompressionSnappy
config.Producer.Return.Successes = true3. Onze applicatie heeft ook een ingebouwde prometheus-client, die verschillende statistieken verzamelt, zoals:
- aantal verzoeken aan onze applicatie;
- aantal fouten bij het uitvoeren van het verzoek (onmogelijk om postverzoek te lezen, kapotte json, onmogelijk om naar Kafka te schrijven);
- verwerkingstijd voor één verzoek van de opdrachtgever, inclusief de tijd voor het schrijven van een bericht aan Kafka.
4. Drie eindpunten die onze applicatie verwerkt:
- /status - retourneer eenvoudigweg ok om aan te geven dat we nog leven. Al kun je wel wat controles toevoegen, zoals de beschikbaarheid van het Kafka-cluster.
- /metrics - volgens deze url retourneert de prometheus-client de verzamelde statistieken.
- /post is het belangrijkste eindpunt waar POST-verzoeken met json erin worden verzonden. Onze applicatie controleert de json op geldigheid en als alles in orde is, schrijft hij de data naar het Kafka-cluster.
Ik zal een voorbehoud maken dat de code niet perfect is; deze kan (en moet!) worden ingevuld. U kunt bijvoorbeeld stoppen met het gebruik van de ingebouwde net/http en overschakelen naar het snellere fasthttp. Of u kunt verwerkingstijd en CPU-bronnen winnen door de json-validiteitscontrole naar een later stadium te verplaatsen - wanneer de gegevens worden overgedragen van de buffer naar het clickhouse-cluster.
Naast de ontwikkelingskant van het vraagstuk hebben we meteen nagedacht over onze toekomstige infrastructuur en besloten om onze applicatie via docker uit te rollen. Het laatste Dockerbestand voor het bouwen van de applicatie is . Over het algemeen is het vrij eenvoudig, het enige punt waar ik op zou willen letten is de meertrapsmontage, waarmee we het uiteindelijke beeld van onze container kunnen verkleinen.
Eerste stappen in de cloud
Schrijf je eerst in op . Nadat we alle benodigde velden hebben ingevuld, krijgen we een account aangemaakt en krijgen we een subsidie voor een bepaald bedrag, dat kan worden gebruikt om clouddiensten te testen. Als u alle stappen uit ons artikel wilt herhalen, zou deze subsidie voldoende voor u moeten zijn.
Na registratie wordt er een aparte cloud en een standaardmap voor u aangemaakt, waarin u kunt beginnen met het maken van cloudbronnen. Over het algemeen ziet de relatie tussen bronnen er in Yandex.Cloud als volgt uit:
U kunt meerdere clouds voor één account maken. En maak in de cloud verschillende mappen voor verschillende bedrijfsprojecten. U kunt hierover meer lezen in de documentatie - . Overigens zal ik er hieronder in de tekst vaak naar verwijzen. Toen ik de hele infrastructuur helemaal opnieuw opzette, heeft de documentatie me meer dan eens geholpen, dus ik raad je aan om deze te bestuderen.
Om de cloud te beheren, kunt u zowel de webinterface als het consolehulpprogramma gebruiken - yc. De installatie wordt uitgevoerd met één commando (voor Linux en Mac Os):
curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bashAls uw interne beveiligingsspecialist tekeergaat over het uitvoeren van scripts vanaf internet, dan kunt u ten eerste het script openen en lezen, en ten tweede kunnen we het onder onze gebruiker uitvoeren - zonder rootrechten.
Als u een client voor Windows wilt installeren, kunt u de instructies gebruiken en dan uitvoeren yc initom het volledig aan te passen:
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:~ $In principe is het proces eenvoudig: eerst moet u een oauth-token verkrijgen om de cloud te beheren, de cloud en de map selecteren die u wilt gebruiken.
Als u meerdere accounts of mappen binnen dezelfde cloud heeft, kunt u via yc config extra profielen met afzonderlijke instellingen aanmaken en hiertussen schakelen.
Naast de bovenstaande methoden schreef het Yandex.Cloud-team een zeer goede voor het beheren van cloudbronnen. Van mijn kant heb ik een git-repository voorbereid, waarin ik alle bronnen heb beschreven die als onderdeel van het artikel zullen worden gemaakt - . We zijn geïnteresseerd in de master branch, laten we deze lokaal klonen:
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/Alle hoofdvariabelen die in terraform worden gebruikt, worden in het bestand main.tf geschreven. Om aan de slag te gaan, maakt u een private.auto.tfvars-bestand in de terraform-map met de volgende inhoud:
# 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 = ""Alle variabelen kunnen uit de yc-configuratielijst worden gehaald, aangezien we het consolehulpprogramma al hebben geconfigureerd. Ik raad u aan om private.auto.tfvars onmiddellijk toe te voegen aan .gitignore, om niet per ongeluk privégegevens te publiceren.
In private.auto.tfvars hebben we ook gegevens van Cloudflare gespecificeerd - om DNS-records te creëren en het hoofddomein events.kis.im naar onze servers te proxyen. Als u cloudflare niet wilt gebruiken, verwijder dan de initialisatie van de cloudflare-provider in main.tf en het bestand dns.tf, dat verantwoordelijk is voor het maken van de benodigde DNS-records.
In ons werk zullen we alle drie de methoden combineren: de webinterface, het consolehulpprogramma en terraform.
Virtuele netwerken
Eerlijk gezegd kunt u deze stap overslaan, omdat u bij het maken van een nieuwe cloud automatisch een apart netwerk en drie subnetten krijgt: één voor elke beschikbaarheidszone. Maar toch willen wij graag voor ons project een apart netwerk maken met een eigen adressering. Het algemene diagram van hoe het netwerk werkt in Yandex.Cloud wordt weergegeven in de onderstaande afbeelding (eerlijk gezegd overgenomen van )
Je creëert dus een gemeenschappelijk netwerk waarbinnen bronnen met elkaar kunnen communiceren. Voor elke beschikbaarheidszone wordt een subnet aangemaakt met een eigen adressering en verbonden met het algemene netwerk. Hierdoor kunnen alle cloudbronnen daarin communiceren, zelfs als ze zich in verschillende beschikbaarheidszones bevinden. Bronnen die met verschillende cloudnetwerken zijn verbonden, kunnen elkaar alleen via externe adressen zien. Trouwens, hoe werkt deze magie vanbinnen? .
Het maken van een netwerk wordt beschreven in het bestand network.tf uit de repository. Daar creëren we één gemeenschappelijk privénetwerk intern en verbinden er drie subnetten mee in verschillende beschikbaarheidszones: internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24) ).
Initialiseer terraform en creëer netwerken:
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.Geweldig! We hebben ons netwerk gecreëerd en zijn nu klaar om onze interne diensten te creëren.
Virtuele machines maken
Om de applicatie te testen, hoeven we slechts twee virtuele machines te maken: de eerste hebben we nodig om de applicatie te bouwen en uit te voeren, de tweede om kafka uit te voeren, die we zullen gebruiken om inkomende berichten op te slaan. En we zullen een andere machine maken waarop we Prometheus zullen configureren om de applicatie te monitoren.
De virtuele machines worden geconfigureerd met behulp van ansible. Zorg er dus voor dat u over een van de nieuwste versies van ansible beschikt voordat u terraform start. En installeer de nodige rollen met weerwortstelsel:
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) $In de ansible-map bevindt zich een voorbeeld van een .ansible.cfg-configuratiebestand dat ik gebruik. Het kan van pas komen.
Voordat u virtuele machines maakt, moet u ervoor zorgen dat de ssh-agent actief is en dat er een ssh-sleutel is toegevoegd, anders kan terraform geen verbinding maken met de gemaakte machines. Ik kwam natuurlijk een bug tegen in os x: . Om te voorkomen dat dit opnieuw gebeurt, voegt u een kleine variabele toe aan env voordat u Terraform start:
vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YESIn de map met terraform creëren we de benodigde bronnen:
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 ...Als alles succesvol is geëindigd (en dat zou zo moeten zijn), dan hebben we drie virtuele machines:
- build - een machine voor het testen en bouwen van een applicatie. Docker werd automatisch geïnstalleerd door Ansible.
- monitoring - een monitoringmachine - prometheus & grafana erop geïnstalleerd. Login / wachtwoord standaard: admin / admin
- kafka is een kleine machine waarop kafka is geïnstalleerd, toegankelijk via poort 9092.
Laten we ervoor zorgen dat ze allemaal op hun plaats staan:
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 |
+----------------------+------------+---------------+---------+---------------+-------------+
De bronnen zijn aanwezig en vanaf hier kunnen we hun IP-adressen verkrijgen. In wat volgt zal ik IP-adressen gebruiken om verbinding te maken via ssh en de applicatie te testen. Als u een cloudflare-account hebt aangesloten op terraform, kunt u vers aangemaakte DNS-namen gebruiken.
Bij het aanmaken van een virtuele machine worden overigens een intern IP-adres en een interne DNS-naam opgegeven, zodat je op naam toegang kunt krijgen tot servers binnen het netwerk:
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 msDit is handig voor ons om het eindpunt met kafk aan de toepassing aan te geven.
Het samenstellen van de applicatie
Geweldig, er zijn servers, er is een applicatie - het enige dat overblijft is het samenstellen en publiceren ervan. Voor de build gebruiken we de gebruikelijke docker-build, maar als beeldopslag gebruiken we een service van Yandex - containerregister. Maar eerst dingen eerst.
We kopiëren de applicatie naar de bouwmachine, loggen in via ssh en stellen de image samen:
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:latestDe helft van de strijd is gestreden - nu kunnen we de functionaliteit van onze applicatie controleren door deze te starten en naar Kafka te sturen:
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) $De applicatie reageerde met succes op de opname en gaf de ID aan van de partitie en de offset waarin het bericht was opgenomen. Het enige dat u nog hoeft te doen is een register aan te maken in Yandex.Cloud en onze afbeelding daar te uploaden (hoe u dit doet met behulp van drie regels, wordt beschreven in het register.tf-bestand). Maak een opslag aan:
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.Er zijn verschillende manieren om te authenticeren in het containerregister: met behulp van een oauth-token, een iam-token of een serviceaccountsleutel. Meer details over deze methoden vindt u in de documentatie. . We gebruiken de serviceaccountsleutel, dus we maken een account aan:
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.Nu hoeft er alleen nog een sleutel voor te worden gemaakt:
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_2048Wij ontvangen informatie over het id van onze opslag, dragen de sleutel over en loggen in:
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:~$Om de afbeelding naar het register te uploaden, hebben we de containerregister-ID nodig. Deze halen we uit het yc-hulpprogramma:
vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"Daarna taggen we onze afbeelding met een nieuwe naam en uploaden we:
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: 946We kunnen verifiëren dat de afbeelding succesvol is geladen:
vozerov@mba:~/events/terraform (master) $ yc container repository list
+----------------------+-----------------------------+
| ID | NAME |
+----------------------+-----------------------------+
| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |
+----------------------+-----------------------------+Trouwens, als je het yc-hulpprogramma op een Linux-machine installeert, kun je de opdracht gebruiken
yc container registry configure-dockerDocker configureren.
Conclusie
We hebben hard gewerkt en als resultaat:
- We bedachten de architectuur van onze toekomstige dienst.
- We hebben een applicatie in Golang geschreven die onze bedrijfslogica implementeert.
- We hebben het verzameld en in een particulier containerregister geplaatst.
In het volgende deel gaan we verder met de interessante dingen: we brengen onze applicatie in productie en lanceren er uiteindelijk de lading op. Niet overstappen!
Dit materiaal staat in de video-opname van de open workshop REBRAIN & Yandex.Cloud: We accepteren 10 verzoeken per seconde op Yandex Cloud -
Als u geïnteresseerd bent om dergelijke evenementen online bij te wonen en in realtime vragen te stellen, maak dan verbinding met.
We willen Yandex.Cloud speciaal bedanken voor de mogelijkheid om een dergelijk evenement te organiseren. Link ernaar -
Als u naar de cloud moet verhuizen of vragen heeft over uw infrastructuur, .
PS We hebben 2 gratis audits per maand, wellicht is jouw project daar één van.
Bron: www.habr.com