🥇ჩვენ ვიღებთ 10 ღონისძიებას Yandex.Cloud-ში. ნაწილი 000

გამარჯობა ყველას, მეგობრებო!

* ეს სტატია ეფუძნება REBRAIN & Yandex.Cloud ღია სახელოსნოს, თუ ვიდეოს ყურება გირჩევნიათ, შეგიძლიათ იპოვოთ იგი ამ ბმულზე - https://youtu.be/cZLezUm0ekE

ჩვენ ცოტა ხნის წინ გვქონდა შესაძლებლობა გვეცადა Yandex.Cloud პირდაპირ ეთერში. მას შემდეგ, რაც გვინდოდა ხანგრძლივი და რთული გამოკვლევა, მაშინვე მივატოვეთ იდეა, რომ გამოგვექმნა მარტივი Wordpress ბლოგი ღრუბლოვანი ბაზით - ეს ძალიან მოსაწყენი იყო. გარკვეული ფიქრის შემდეგ, ჩვენ გადავწყვიტეთ გამოგვეყენებინა წარმოების სერვისის არქიტექტურის მსგავსი რამ მოვლენების თითქმის რეალურ დროში მიღებისა და ანალიზისთვის.

მე აბსოლუტურად დარწმუნებული ვარ, რომ ონლაინ (და არა მხოლოდ) ბიზნესის დიდი უმრავლესობა როგორღაც აგროვებს უამრავ ინფორმაციას მათი მომხმარებლებისა და მათი ქმედებების შესახებ. მინიმუმ, ეს აუცილებელია გარკვეული გადაწყვეტილებების მისაღებად - მაგალითად, თუ თქვენ მართავთ ონლაინ თამაშს, შეგიძლიათ ნახოთ სტატისტიკა, რომელ დონეზე ჩერდებიან მომხმარებლები ყველაზე ხშირად და წაშლიან თქვენს სათამაშოს. ან რატომ ტოვებენ მომხმარებლები თქვენს საიტს არაფრის შეძენის გარეშე (გამარჯობა, Yandex.Metrica).

მაშ ასე, ჩვენი ისტორია: როგორ დავწერეთ აპლიკაცია golang-ში, შევამოწმეთ kafka vs rabbitmq vs yqs, დავწერეთ მონაცემთა ნაკადი Clickhouse კლასტერში და ვიზუალურად ვაჩვენეთ მონაცემები Yandex datalens-ის გამოყენებით. ბუნებრივია, ეს ყველაფერი გაჟღენთილი იყო ინფრასტრუქტურული სიამოვნებით დოკერის, ტერაფორმის, გიტლაბის სიის და, რა თქმა უნდა, პრომეთეს სახით. Წავედით!

მსურს დაუყოვნებლივ გავაკეთო დათქმა, რომ ჩვენ ვერ შევძლებთ ყველაფრის კონფიგურაციას ერთ სხდომაზე - ამისათვის დაგვჭირდება სერიის რამდენიმე სტატია. ცოტა სტრუქტურის შესახებ:

ნაწილი 1 (თქვენ კითხულობთ მას). ჩვენ გადავწყვეტთ გადაწყვეტის სპეციფიკაციებსა და არქიტექტურას, ასევე დავწერთ აპლიკაციას გოლანგში.
Მე -2 ნაწილი. ჩვენ ვაძლევთ ჩვენს აპლიკაციას წარმოებაში, ვაქცევთ მას მასშტაბურს და ვამოწმებთ დატვირთვას.
ნაწილი 3. შევეცადოთ გაერკვნენ, რატომ გვჭირდება შეტყობინებების შენახვა ბუფერში და არა ფაილებში, ასევე შევადაროთ kafka, rabbitmq და yandex queue სერვისი.
ნაწილი 4 ჩვენ განვათავსებთ Clickhouse კლასტერს, დავწერთ სტრიმინგ სერვისს, რათა გადავიტანოთ მონაცემები იქ ბუფერიდან და დავაყენოთ ვიზუალიზაცია datalens-ში.
ნაწილი 5 მოდით მივიყვანოთ მთელი ინფრასტრუქტურა სათანადო ფორმაში - დავაყენოთ ci/cd gitlab ci-ს გამოყენებით, დავაკავშიროთ მონიტორინგი და სერვისის აღმოჩენა პრომეთესა და კონსულის გამოყენებით.

ТЗ

პირველ რიგში, მოდით ჩამოვაყალიბოთ მითითების პირობები - კონკრეტულად რა გვინდა მივიღოთ შედეგად.

ჩვენ გვინდა გვქონდეს ისეთი საბოლოო წერტილი, როგორიცაა events.kis.im (kis.im არის სატესტო დომენი, რომელსაც ჩვენ გამოვიყენებთ ყველა სტატიაში), რომელიც უნდა მიიღოს მოვლენები HTTPS-ის გამოყენებით.
მოვლენები არის მარტივი json, როგორიცაა: {“event”: “view”, “os”: “linux”, “browser”: “chrome”}. ფინალურ ეტაპზე კიდევ ცოტა ველს დავამატებთ, მაგრამ ეს დიდ როლს არ ითამაშებს. თუ გსურთ, შეგიძლიათ გადახვიდეთ პროტობუფზე.
სერვისს უნდა შეეძლოს წამში 10 მოვლენის დამუშავება.
შესაძლებელი უნდა იყოს ჰორიზონტალურად მასშტაბირება, უბრალოდ ახალი ინსტანციების დამატებით ჩვენს გადაწყვეტაში. და კარგი იქნება, თუ ჩვენ შევძლებთ წინა ნაწილის გადატანას სხვადასხვა გეოლოკაციებზე, რათა შევამციროთ კლიენტის მოთხოვნების შეყოვნება.
შეცდომის ტოლერანტობა. გამოსავალი უნდა იყოს საკმარისად სტაბილური და შეეძლოს გადარჩეს ნებისმიერი ნაწილის დაცემას (რა თქმა უნდა, გარკვეულ რაოდენობამდე).

არქიტექტურა

ზოგადად, ამ ტიპის ამოცანებისთვის დიდი ხანია გამოიგონეს კლასიკური არქიტექტურები, რომლებიც ეფექტური მასშტაბის საშუალებას იძლევა. ფიგურაში ნაჩვენებია ჩვენი გადაწყვეტის მაგალითი.

ასე რომ, რაც გვაქვს:

1. მარცხნივ არის ჩვენი მოწყობილობები, რომლებიც წარმოქმნიან სხვადასხვა მოვლენებს, იქნება ეს მოთამაშეები, რომლებიც ასრულებენ დონეს სათამაშოში სმარტფონზე ან შეკვეთას ონლაინ მაღაზიაში ჩვეულებრივი ბრაუზერის საშუალებით. ღონისძიება, როგორც სპეციფიკაციაშია მითითებული, არის მარტივი json, რომელიც იგზავნება ჩვენს ბოლო წერტილში - events.kis.im.

2. პირველი ორი სერვერი არის მარტივი ბალანსერი, მათი ძირითადი ამოცანებია:

იყავი მუდმივად ხელმისაწვდომი. ამისათვის შეგიძლიათ გამოიყენოთ, მაგალითად, keepalived, რომელიც პრობლემების შემთხვევაში გადართავს ვირტუალურ IP კვანძებს შორის.
TLS-ის შეწყვეტა. დიახ, ჩვენ შევწყვეტთ მათ TLS-ს. ჯერ ერთი, რათა ჩვენი გადაწყვეტა შეესაბამებოდეს ტექნიკურ მახასიათებლებს და მეორეც, რათა განვთავისუფლდეთ დაშიფრული კავშირის დამყარების ტვირთი ჩვენი backend სერვერებიდან.
დაბალანსება შემომავალი მოთხოვნები ხელმისაწვდომი backend სერვერებზე. საკვანძო სიტყვა აქ ხელმისაწვდომია. ამის საფუძველზე მივდივართ იმის გაგებამდე, რომ დატვირთვის ბალანსერებს უნდა შეეძლოთ ჩვენი სერვერების მონიტორინგი აპლიკაციებით და შეაჩერონ ტრაფიკის დაბალანსება წარუმატებელ კვანძებთან.

3. ბალანსერების შემდეგ გვაქვს აპლიკაციის სერვერები, რომლებიც საკმაოდ მარტივ აპლიკაციას აწარმოებენ. მას უნდა შეეძლოს HTTP-ით შემომავალი მოთხოვნების მიღება, გაგზავნილი json-ის ვალიდაცია და მონაცემების ბუფერში შეტანა.

4. დიაგრამაზე ნაჩვენებია კაფკა, როგორც ბუფერი, თუმცა, რა თქმა უნდა, სხვა მსგავსი სერვისების გამოყენება შესაძლებელია ამ დონეზე. კაფკას, rabbitmq-ს და yqs-ს შევადარებთ მესამე სტატიაში.

5. ჩვენი არქიტექტურის ბოლო წერტილი არის Clickhouse – სვეტოვანი მონაცემთა ბაზა, რომელიც საშუალებას გაძლევთ შეინახოთ და დაამუშავოთ უზარმაზარი მონაცემები. ამ დონეზე, ჩვენ უნდა გადავიტანოთ მონაცემები ბუფერიდან თავად შენახვის სისტემაში (დაწვრილებით ამის შესახებ მე-4 სტატიაში).

ეს დიზაინი საშუალებას გვაძლევს თითოეული ფენის დამოუკიდებლად ჰორიზონტალურად მასშტაბირება. Backend სერვერები ვერ უმკლავდებიან - მოდით დავამატოთ კიდევ ერთი რამ - ბოლოს და ბოლოს, ისინი მოქალაქეობის არმქონე აპლიკაციებია და, შესაბამისად, ეს შეიძლება გაკეთდეს თუნდაც ავტომატურად. კაფკას სტილის ბუფერი არ მუშაობს - მოდით დავამატოთ მეტი სერვერი და გადავიტანოთ ჩვენი თემის ზოგიერთი დანაყოფი მათზე. Clickhouse ვერ უმკლავდება - ეს შეუძლებელია :) ფაქტობრივად, ჩვენ ასევე დავაკავშირებთ სერვერებს და გავანაწილებთ მონაცემებს.

სხვათა შორის, თუ გსურთ ჩვენი ტექნიკური მახასიათებლებისა და მასშტაბის არასავალდებულო ნაწილის დანერგვა სხვადასხვა გეოლოკაციებში, მაშინ არაფერია მარტივი:

თითოეულ გეოლოკაციაში ჩვენ ვაყენებთ დატვირთვის ბალანსერს აპლიკაციით და კაფკათი. ზოგადად, საკმარისია 2 აპლიკაციის სერვერი, 3 კაფკა კვანძი და ღრუბლოვანი ბალანსერი, მაგალითად, cloudflare, რომელიც შეამოწმებს აპლიკაციის კვანძების ხელმისაწვდომობას და ბალანსის მოთხოვნებს გეოლოკაციის მიხედვით, კლიენტის წყაროს IP მისამართის მიხედვით. ამრიგად, ამერიკელი კლიენტის მიერ გაგზავნილი მონაცემები ამერიკულ სერვერებზე მოხვდება. ხოლო მონაცემები აფრიკიდან არის აფრიკული.

მაშინ ყველაფერი საკმაოდ მარტივია - ჩვენ ვიყენებთ სარკის ხელსაწყოს კაფკას ნაკრებიდან და ვაკოპირებთ ყველა მონაცემს ყველა ადგილიდან ჩვენს ცენტრალურ მონაცემთა ცენტრში, რომელიც მდებარეობს რუსეთში. შიდა, ჩვენ ვაანალიზებთ მონაცემებს და ჩავწერთ Clickhouse-ში შემდგომი ვიზუალიზაციისთვის.

ასე რომ, ჩვენ დავახარისხეთ არქიტექტურა - დავიწყოთ Yandex.Cloud-ის შერყევა!

განაცხადის დაწერა

Cloud-მდე მაინც უნდა იყოთ ცოტა მოთმინება და დაწეროთ საკმაოდ მარტივი სერვისი შემომავალი მოვლენების დასამუშავებლად. ჩვენ გამოვიყენებთ golang-ს, რადგან მან კარგად დაამტკიცა თავი, როგორც ქსელური აპლიკაციების ჩაწერის ენა.

ერთი საათის (შესაძლოა რამდენიმე საათის) გატარების შემდეგ მივიღებთ ასეთ რაღაცას: https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/main.go.

რა არის ის ძირითადი პუნქტები, რომლებიც მინდა აღვნიშნო აქ:

1. აპლიკაციის გაშვებისას შეგიძლიათ მიუთითოთ ორი დროშა. ერთი პასუხისმგებელია პორტზე, რომელზეც ჩვენ მოვუსმენთ შემომავალ http მოთხოვნებს (-addr). მეორე არის kafka სერვერის მისამართი, სადაც ჩვენ ჩავწერთ ჩვენს მოვლენებს (-kafka):

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

2. აპლიკაცია იყენებს sarama ბიბლიოთეკას ([] github.com/Shopify/sarama) შეტყობინებების გაგზავნა კაფკას კლასტერში. ჩვენ დაუყოვნებლივ დავაყენეთ პარამეტრები, რომლებიც მიმართულია დამუშავების მაქსიმალურ სიჩქარეზე:

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

3. ჩვენს აპლიკაციას ასევე აქვს ჩაშენებული პრომეთე კლიენტი, რომელიც აგროვებს სხვადასხვა მეტრიკას, როგორიცაა:

ჩვენს აპლიკაციაზე მოთხოვნის რაოდენობა;
შეცდომების რაოდენობა მოთხოვნის შესრულებისას (შეუძლებელია პოსტის მოთხოვნის წაკითხვა, გატეხილი json, შეუძლებელია კაფკას მიწერა);
კლიენტის ერთი მოთხოვნის დამუშავების დრო, კაფკასთვის შეტყობინების დაწერის დროის ჩათვლით.

4. სამი საბოლოო წერტილი, რომელსაც ჩვენი აპლიკაცია ამუშავებს:

/ სტატუსი - უბრალოდ დაბრუნდით ok, რათა აჩვენოთ, რომ ცოცხლები ვართ. თუმცა შეგიძლიათ დაამატოთ რამდენიმე შემოწმება, როგორიცაა კაფკას კლასტერის ხელმისაწვდომობა.
/metrics - ამ url-ის მიხედვით პრომეთეუსის კლიენტი დააბრუნებს მის მიერ შეგროვებულ მეტრებს.
/post არის მთავარი საბოლოო წერტილი, სადაც გაიგზავნება POST მოთხოვნები შიგნით json-ით. ჩვენი აპლიკაცია ამოწმებს json-ს ვალიდობაზე და თუ ყველაფერი წესრიგშია, ის მონაცემებს წერს კაფკას კლასტერში.

მე გავაკეთებ დათქმას, რომ კოდი არ არის სრულყოფილი - ის შეიძლება (და უნდა!) დასრულდეს. მაგალითად, შეგიძლიათ შეწყვიტოთ ჩაშენებული net/http-ის გამოყენება და გადახვიდეთ სწრაფ სწრაფ http-ზე. ან შეგიძლიათ მიიღოთ დამუშავების დრო და პროცესორის რესურსები json ვალიდობის შემოწმების შემდგომ ეტაპზე გადატანით - როდესაც მონაცემები გადაიცემა ბუფერიდან clickhouse კლასტერში.

საკითხის განვითარების მხარის გარდა, ჩვენ მაშინვე ვიფიქრეთ ჩვენს მომავალ ინფრასტრუქტურაზე და გადავწყვიტეთ ჩვენი აპლიკაციის განთავსება დოკერის საშუალებით. საბოლოო Dockerfile განაცხადის შესაქმნელად არის https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/Dockerfile. ზოგადად, ეს საკმაოდ მარტივია, ერთადერთი პუნქტი, რომელზეც მინდა ყურადღება გავამახვილო, არის მრავალსაფეხურიანი შეკრება, რომელიც საშუალებას გვაძლევს შევამციროთ ჩვენი კონტეინერის საბოლოო გამოსახულება.

პირველი ნაბიჯები ღრუბელში

პირველ რიგში, დარეგისტრირდით cloud.yandex.ru. ყველა საჭირო ველის შევსების შემდეგ შეგვექმნება ანგარიში და მოგვცემს გრანტს გარკვეული თანხის სანაცვლოდ, რომელიც შეიძლება გამოვიყენოთ ღრუბლოვანი სერვისების შესამოწმებლად. თუ გსურთ გაიმეოროთ ჩვენი სტატიიდან ყველა ნაბიჯი, ეს გრანტი საკმარისი უნდა იყოს თქვენთვის.

რეგისტრაციის შემდეგ თქვენთვის შეიქმნება ცალკე ღრუბელი და ნაგულისხმევი დირექტორია, რომელშიც შეგიძლიათ დაიწყოთ ღრუბლოვანი რესურსების შექმნა. ზოგადად, Yandex.Cloud-ში რესურსების ურთიერთობა ასე გამოიყურება:

თქვენ შეგიძლიათ შექმნათ რამდენიმე ღრუბელი ერთი ანგარიშისთვის. და ღრუბლის შიგნით შექმენით სხვადასხვა დირექტორიები სხვადასხვა კომპანიის პროექტებისთვის. ამის შესახებ მეტი შეგიძლიათ წაიკითხოთ დოკუმენტაციაში - https://cloud.yandex.ru/docs/resource-manager/concepts/resources-hierarchy. სხვათა შორის, ხშირად მივმართავ მას ქვემოთ ტექსტში. როდესაც მთელი ინფრასტრუქტურა ნულიდან დავაყენე, დოკუმენტაციამ არაერთხელ დამეხმარა, ამიტომ გირჩევთ, შეისწავლოთ იგი.

ღრუბლის სამართავად, შეგიძლიათ გამოიყენოთ როგორც ვებ ინტერფეისი, ასევე კონსოლის პროგრამა - yc. ინსტალაცია ხორციელდება ერთი ბრძანებით (Linux-ისთვის და Mac Os-ისთვის):

curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash

თუ თქვენი შიდა უსაფრთხოების სპეციალისტი ბრაზობს სკრიპტების ინტერნეტიდან გაშვებაზე, მაშინ, პირველ რიგში, შეგიძლიათ გახსნათ სკრიპტი და წაიკითხოთ იგი, მეორეც, ჩვენ მას ვაწარმოებთ ჩვენი მომხმარებლის ქვეშ - root უფლებების გარეშე.

თუ გსურთ დააინსტალიროთ კლიენტი Windows-ისთვის, შეგიძლიათ გამოიყენოთ ინსტრუქციები აქ და შემდეგ შეასრულეთ yc initმისი სრულად მორგებისთვის:

vozerov@mba:~ $ yc init
Welcome! This command will take you through the configuration process.
Please go to https://oauth.yandex.ru/authorize?response_type=token&client_id= in order to obtain OAuth token.

Please enter OAuth token:
Please select cloud to use:
 [1] cloud-b1gv67ihgfu3bp (id = b1gv67ihgfu3bpt24o0q)
 [2] fevlake-cloud (id = b1g6bvup3toribomnh30)
Please enter your numeric choice: 2
Your current cloud has been set to 'fevlake-cloud' (id = b1g6bvup3toribomnh30).
Please choose folder to use:
 [1] default (id = b1g5r6h11knotfr8vjp7)
 [2] Create a new folder
Please enter your numeric choice: 1
Your current folder has been set to 'default' (id = b1g5r6h11knotfr8vjp7).
Do you want to configure a default Compute zone? [Y/n]
Which zone do you want to use as a profile default?
 [1] ru-central1-a
 [2] ru-central1-b
 [3] ru-central1-c
 [4] Don't set default zone
Please enter your numeric choice: 1
Your profile default Compute zone has been set to 'ru-central1-a'.
vozerov@mba:~ $

პრინციპში, პროცესი მარტივია - ჯერ უნდა მიიღოთ oauth ჟეტონი ღრუბლის სამართავად, შეარჩიოთ ღრუბელი და საქაღალდე, რომელსაც გამოიყენებთ.

თუ თქვენ გაქვთ რამდენიმე ანგარიში ან საქაღალდე იმავე ღრუბელში, შეგიძლიათ შექმნათ დამატებითი პროფილები ცალკეული პარამეტრებით yc config პროფილის შექმნისა და მათ შორის გადართვის მეშვეობით.

ზემოაღნიშნული მეთოდების გარდა, Yandex.Cloud-ის გუნდმა დაწერა ძალიან კარგი მოდული ტერაფორმისთვის ღრუბლის რესურსების მართვისთვის. ჩემი მხრივ, მე მოვამზადე git საცავი, სადაც აღვწერე ყველა რესურსი, რომელიც შეიქმნება სტატიის ნაწილი - https://github.com/rebrainme/yandex-cloud-events/. ჩვენ გვაინტერესებს სამაგისტრო ფილიალი, მოდით კლონირება მოვახდინოთ ადგილობრივად:


vozerov@mba:~ $ git clone https://github.com/rebrainme/yandex-cloud-events/ events
Cloning into 'events'...
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (100/100), done.
remote: Compressing objects: 100% (68/68), done.
remote: Total 100 (delta 37), reused 89 (delta 26), pack-reused 0
Receiving objects: 100% (100/100), 25.65 KiB | 168.00 KiB/s, done.
Resolving deltas: 100% (37/37), done.
vozerov@mba:~ $ cd events/terraform/

ყველა ძირითადი ცვლადი, რომელიც გამოიყენება terraform-ში, ჩაწერილია main.tf ფაილში. დასაწყებად შექმენით private.auto.tfvars ფაილი terraform საქაღალდეში შემდეგი შინაარსით:

# Yandex Cloud Oauth token
yc_token = ""
# Yandex Cloud ID
yc_cloud_id = ""
# Yandex Cloud folder ID
yc_folder_id = ""
# Default Yandex Cloud Region
yc_region = "ru-central1-a"
# Cloudflare email
cf_email = ""
# Cloudflare token
cf_token = ""
# Cloudflare zone id
cf_zone_id = ""

ყველა ცვლადის აღება შესაძლებელია yc კონფიგურაციის სიიდან, რადგან ჩვენ უკვე დავაკონფიგურირეთ კონსოლის პროგრამა. გირჩევთ, დაუყოვნებლივ დაამატოთ private.auto.tfvars .gitignore-ზე, რათა შემთხვევით არ გამოქვეყნდეს პირადი მონაცემები.

private.auto.tfvars-ში ჩვენ ასევე დავაზუსტეთ მონაცემები Cloudflare-დან - DNS ჩანაწერების შესაქმნელად და მთავარი დომენის events.kis.im პროქსის ჩვენ სერვერებზე. თუ არ გსურთ გამოიყენოთ cloudflare, მაშინ წაშალეთ cloudflare პროვაიდერის ინიციალიზაცია main.tf-ში და dns.tf ფაილში, რომელიც პასუხისმგებელია საჭირო dns ჩანაწერების შექმნაზე.

ჩვენს მუშაობაში ჩვენ გავაერთიანებთ სამივე მეთოდს - ვებ ინტერფეისს, კონსოლის უტილიტას და ტერაფორმს.

ვირტუალური ქსელები

მართალი გითხრათ, შეგიძლიათ გამოტოვოთ ეს ნაბიჯი, რადგან ახალი ღრუბლის შექმნისას ავტომატურად გექნებათ ცალკე ქსელი და 3 ქვექსელი შექმნილი - ერთი ხელმისაწვდომობის ზონისთვის. მაგრამ ჩვენ მაინც გვსურს შევქმნათ ცალკე ქსელი ჩვენი პროექტისთვის საკუთარი მისამართით. ზოგადი დიაგრამა, თუ როგორ მუშაობს ქსელი Yandex.Cloud-ში ნაჩვენებია ქვემოთ მოცემულ ფიგურაში (გულწრფელად აღებულია https://cloud.yandex.ru/docs/vpc/concepts/)

ასე რომ, თქვენ ქმნით საერთო ქსელს, რომლის ფარგლებშიც რესურსებს შეუძლიათ ერთმანეთთან კომუნიკაცია. თითოეული ხელმისაწვდომობის ზონისთვის იქმნება ქვექსელი თავისი მისამართით და დაკავშირებულია ზოგად ქსელთან. შედეგად, მასში არსებული ღრუბლის ყველა რესურსს შეუძლია კომუნიკაცია, მაშინაც კი, თუ ისინი სხვადასხვა ხელმისაწვდომობის ზონაში არიან. სხვადასხვა ღრუბლოვან ქსელთან დაკავშირებულ რესურსებს შეუძლიათ ერთმანეთის დანახვა მხოლოდ გარე მისამართების საშუალებით. სხვათა შორის, როგორ მუშაობს ეს მაგია შიგნით, კარგად იყო აღწერილი ჰაბრეზე.

ქსელის შექმნა აღწერილია network.tf ფაილში საცავიდან. იქ ჩვენ ვქმნით ერთ საერთო კერძო ქსელს შიდა და ვუკავშირდებით მას სამ ქვექსელს სხვადასხვა ხელმისაწვდომობის ზონაში - შიდა-a (172.16.1.0/24), შიდა-b (172.16.2.0/24), შიდა-c (172.16.3.0/24). ).

ტერაფორმის ინიცირება და ქსელების შექმნა:

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.

დიდი! ჩვენ შევქმენით ჩვენი ქსელი და ახლა მზად ვართ შევქმნათ ჩვენი შიდა სერვისები.

ვირტუალური მანქანების შექმნა

აპლიკაციის შესამოწმებლად დაგვჭირდება მხოლოდ ორი ვირტუალური აპარატის შექმნა - პირველი დაგვჭირდება აპლიკაციის შესაქმნელად და გასაშვებად, მეორეს კაფკას გასაშვებად, რომელსაც გამოვიყენებთ შემომავალი შეტყობინებების შესანახად. და ჩვენ შევქმნით სხვა მანქანას, სადაც დავაკონფიგურირებთ პრომეთეს აპლიკაციის მონიტორინგისთვის.

ვირტუალური მანქანების კონფიგურაცია მოხდება ansible-ის გამოყენებით, ამიტომ ტერაფორმის დაწყებამდე დარწმუნდით, რომ გაქვთ ansible-ის ერთ-ერთი უახლესი ვერსია. და დააინსტალირეთ საჭირო როლები ansible galaxy-ით:

vozerov@mba:~/events/terraform (master) $ cd ../ansible/
vozerov@mba:~/events/ansible (master) $ ansible-galaxy install -r requirements.yml
- cloudalchemy-prometheus (master) is already installed, skipping.
- cloudalchemy-grafana (master) is already installed, skipping.
- sansible.kafka (master) is already installed, skipping.
- sansible.zookeeper (master) is already installed, skipping.
- geerlingguy.docker (master) is already installed, skipping.
vozerov@mba:~/events/ansible (master) $

ansible საქაღალდის შიგნით არის მაგალითი .ansible.cfg კონფიგურაციის ფაილი, რომელსაც მე ვიყენებ. ეს შეიძლება გამოდგება.

ვირტუალური მანქანების შექმნამდე დარწმუნდით, რომ თქვენ გაქვთ ssh-agent გაშვებული და დამატებული გაქვთ ssh გასაღები, წინააღმდეგ შემთხვევაში terraform ვერ შეძლებს შექმნილ მანქანებთან დაკავშირებას. მე, რა თქმა უნდა, წავაწყდი შეცდომას os x-ში: https://github.com/ansible/ansible/issues/32499#issuecomment-341578864. ამის თავიდან ასაცილებლად, Terraform-ის გაშვებამდე დაამატეთ env მცირე ცვლადი:

vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

საქაღალდეში terraform ჩვენ ვქმნით საჭირო რესურსებს:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_compute_instance.build -target yandex_compute_instance.monitoring -target yandex_compute_instance.kafka
yandex_vpc_network.internal: Refreshing state... [id=enp2g2rhile7gbqlbrkr]
data.yandex_compute_image.ubuntu_image: Refreshing state...
yandex_vpc_subnet.internal-a: Refreshing state... [id=e9b1dad6mgoj2v4funog]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

... skipped ...

Plan: 3 to add, 0 to change, 0 to destroy.

... skipped ...

თუ ყველაფერი წარმატებით დასრულდა (და ასეც უნდა იყოს), მაშინ გვექნება სამი ვირტუალური მანქანა:

build - მანქანა ტესტირებისა და განაცხადის შესაქმნელად. Docker დაინსტალირდა ავტომატურად Ansible-ის მიერ.
მონიტორინგი - მასზე დამონტაჟებული მონიტორინგის მანქანა - პრომეთე და გრანა. შესვლა / პაროლი სტანდარტი: admin / admin
კაფკა არის პატარა მანქანა დაყენებული კაფკათი, წვდომა 9092 პორტზე.

მოდით დავრწმუნდეთ, რომ ისინი ყველა ადგილზეა:

vozerov@mba:~/events (master) $ yc compute instance list
+----------------------+------------+---------------+---------+---------------+-------------+
|          ID          |    NAME    |    ZONE ID    | STATUS  |  EXTERNAL IP  | INTERNAL IP |
+----------------------+------------+---------------+---------+---------------+-------------+
| fhm081u8bkbqf1pa5kgj | monitoring | ru-central1-a | RUNNING | 84.201.159.71 | 172.16.1.35 |
| fhmf37k03oobgu9jmd7p | kafka      | ru-central1-a | RUNNING | 84.201.173.41 | 172.16.1.31 |
| fhmt9pl1i8sf7ga6flgp | build      | ru-central1-a | RUNNING | 84.201.132.3  | 172.16.1.26 |
+----------------------+------------+---------------+---------+---------------+-------------+

რესურსები ადგილზეა და აქედან შეგვიძლია მივიღოთ მათი IP მისამართები. შემდგომში მე გამოვიყენებ IP მისამართებს ssh-ის საშუალებით დასაკავშირებლად და აპლიკაციის შესამოწმებლად. თუ თქვენ გაქვთ cloudflare ანგარიში დაკავშირებული terraform-თან, მოგერიდებათ გამოიყენოთ ახლად შექმნილი DNS სახელები.
სხვათა შორის, ვირტუალური მანქანის შექმნისას მოცემულია შიდა IP და შიდა DNS სახელი, ასე რომ თქვენ შეგიძლიათ დაუკავშირდეთ სერვერებს ქსელში სახელით:

ubuntu@build:~$ ping kafka.ru-central1.internal
PING kafka.ru-central1.internal (172.16.1.31) 56(84) bytes of data.
64 bytes from kafka.ru-central1.internal (172.16.1.31): icmp_seq=1 ttl=63 time=1.23 ms
64 bytes from kafka.ru-central1.internal (172.16.1.31): icmp_seq=2 ttl=63 time=0.625 ms
^C
--- kafka.ru-central1.internal ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.625/0.931/1.238/0.308 ms

ეს სასარგებლო იქნება ჩვენთვის, რომ მივუთითოთ აპლიკაციას ბოლო წერტილი კაფქით.

აპლიკაციის აწყობა

შესანიშნავია, არის სერვერები, არის აპლიკაცია - რჩება მხოლოდ მისი აწყობა და გამოქვეყნება. კონსტრუქციისთვის ჩვენ გამოვიყენებთ ჩვეულ დოკერის კონსტრუქციას, მაგრამ გამოსახულების შესანახად გამოვიყენებთ სერვისს Yandex - კონტეინერის რეესტრიდან. მაგრამ პირველ რიგში.

ჩვენ ვაკოპირებთ აპლიკაციას build მანქანაში, შევდივართ ssh-ის საშუალებით და ვაწყობთ სურათს:

vozerov@mba:~/events/terraform (master) $ cd ..
vozerov@mba:~/events (master) $ rsync -av app/ [email protected]:app/

... skipped ...

sent 3849 bytes  received 70 bytes  7838.00 bytes/sec
total size is 3644  speedup is 0.93

vozerov@mba:~/events (master) $ ssh 84.201.132.3 -l ubuntu
ubuntu@build:~$ cd app
ubuntu@build:~/app$ sudo docker build -t app .
Sending build context to Docker daemon  6.144kB
Step 1/9 : FROM golang:latest AS build
... skipped ...

Successfully built 9760afd8ef65
Successfully tagged app:latest

ნახევარი ბრძოლა დასრულებულია - ახლა ჩვენ შეგვიძლია შევამოწმოთ ჩვენი აპლიკაციის ფუნქციონირება მისი გაშვებით და კაფკაზე გაგზავნით:

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) $

აპლიკაციამ წარმატებით უპასუხა ჩაწერას და მიუთითა დანაყოფის ID და ოფსეტი, რომელშიც შედიოდა შეტყობინება. დარჩენილია მხოლოდ Yandex.Cloud-ში რეესტრის შექმნა და იქ ატვირთვა ჩვენი სურათი (როგორ გავაკეთოთ ეს სამი ხაზის გამოყენებით აღწერილია registry.tf ფაილში). შექმენით საცავი:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_container_registry.events

... skipped ...

Plan: 1 to add, 0 to change, 0 to destroy.

... skipped ...

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

კონტეინერის რეესტრში ავთენტიფიკაციის რამდენიმე გზა არსებობს - oauth ნიშნის, iam ტოკენის ან სერვისის ანგარიშის გასაღების გამოყენებით. დამატებითი დეტალები ამ მეთოდების შესახებ შეგიძლიათ იხილოთ დოკუმენტაციაში. https://cloud.yandex.ru/docs/container-registry/operations/authentication. ჩვენ გამოვიყენებთ სერვისის ანგარიშის გასაღებს, ამიტომ ვქმნით ანგარიშს:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_iam_service_account.docker -target yandex_resourcemanager_folder_iam_binding.puller -target yandex_resourcemanager_folder_iam_binding.pusher

... skipped ...

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

ახლა რჩება მხოლოდ ამისთვის გასაღების გაკეთება:

vozerov@mba:~/events/terraform (master) $ yc iam key create --service-account-name docker -o key.json
id: ajej8a06kdfbehbrh91p
service_account_id: ajep6d38k895srp9osij
created_at: "2020-04-13T14:00:30Z"
key_algorithm: RSA_2048

ჩვენ ვიღებთ ინფორმაციას ჩვენი საცავის ID-ის შესახებ, გადავცემთ გასაღებს და შევდივართ:

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

სურათის რეესტრში ასატვირთად, ჩვენ გვჭირდება კონტეინერის რეესტრის ID, ჩვენ მას ვიღებთ yc კომუნალურიდან:

vozerov@mba:~ $ yc container registry get events
id: crpdgj6c9umdhgaqjfmm
folder_id:
name: events
status: ACTIVE
created_at: "2020-04-13T13:56:41.914Z"

ამის შემდეგ, ჩვენ ავწერთ ჩვენს სურათს ახალი სახელით და ვტვირთავთ:

ubuntu@build:~$ sudo docker tag app cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1
ubuntu@build:~$ sudo docker push cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1
The push refers to repository [cr.yandex/crpdgj6c9umdhgaqjfmm/events]
8c286e154c6e: Pushed
477c318b05cb: Pushed
beee9f30bc1f: Pushed
v1: digest: sha256:1dd5aaa9dbdde2f60d833be0bed1c352724be3ea3158bcac3cdee41d47c5e380 size: 946

ჩვენ შეგვიძლია დავადასტუროთ, რომ სურათი წარმატებით ჩაიტვირთა:

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

სხვათა შორის, თუ თქვენ დააინსტალირებთ yc პროგრამას Linux აპარატზე, შეგიძლიათ გამოიყენოთ ბრძანება

yc container registry configure-docker

დოკერის კონფიგურაციისთვის.

დასკვნა

ჩვენ ბევრი ვიშრომეთ და შედეგად:

ჩვენ მივიღეთ ჩვენი მომავალი სერვისის არქიტექტურა.
ჩვენ დავწერეთ განცხადება გოლანგში, რომელიც ახორციელებს ჩვენს ბიზნეს ლოგიკას.
ჩვენ შევაგროვეთ და ჩავასხათ კერძო კონტეინერების რეესტრში.

შემდეგ ნაწილში, ჩვენ გადავალთ საინტერესო საკითხებზე - ჩვენ გამოვუშვებთ ჩვენს აპლიკაციას წარმოებაში და საბოლოოდ დავიწყებთ მასზე დატვირთვას. ნუ გადართავ!

ეს მასალა განთავსებულია ღია სახელოსნოს REBRAIN & Yandex.Cloud-ის ვიდეო ჩანაწერში: ჩვენ ვიღებთ 10 მოთხოვნას წამში Yandex Cloud-ზე - https://youtu.be/cZLezUm0ekE

თუ გაინტერესებთ მსგავს ღონისძიებებზე დასწრება ონლაინ და კითხვების დასმა რეალურ დროში, დაუკავშირდით არხი DevOps by REBRAIN.

გვინდა განსაკუთრებული მადლობა გადავუხადოთ Yandex.Cloud-ს ასეთი ღონისძიების მასპინძლობის შესაძლებლობისთვის. ბმული მათთან - https://cloud.yandex.ru/prices

თუ გჭირდებათ ღრუბელზე გადასვლა ან გაქვთ შეკითხვები თქვენი ინფრასტრუქტურის შესახებ, მოგერიდებათ დატოვოთ მოთხოვნა.

PS თვეში 2 უფასო აუდიტი გვაქვს, ალბათ თქვენი პროექტი იქნება ერთ-ერთი მათგანი.

წყარო: www.habr.com

ჩვენ ვიღებთ 10 ღონისძიებას Yandex.Cloud-ში. Ნაწილი 000

ТЗ

არქიტექტურა

განაცხადის დაწერა

პირველი ნაბიჯები ღრუბელში

ვირტუალური ქსელები

ვირტუალური მანქანების შექმნა

აპლიკაციის აწყობა

დასკვნა

ახალი კომენტარის დამატება

ჩვენ ვიღებთ 10 ღონისძიებას Yandex.Cloud-ში. Ნაწილი 000

ТЗ

არქიტექტურა

განაცხადის დაწერა

პირველი ნაბიჯები ღრუბელში

ვირტუალური ქსელები

ვირტუალური მანქანების შექმნა

აპლიკაციის აწყობა

დასკვნა

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება