დარწმუნებული ვარ ბევრს გქონიათ შეხება ისეთ აპლიკაციებთან რომლებსაც ბევრი დამოკიდებულება აქვთ. ესაუბრებიან 2-3 შიდა სერვისს, აქვთ რამდენიმე ინფრასტრუქტურასთან, რედისთან, SQL Server თან, Rabbit თან კავშირი და ზოგადად კომლექსურები არიან. Aspire ს სანამ გავეცნობოდი რომ გეკითხათ ჩემთვის მსგავსი აპლიკაციის გამართვა და დანერგვა რამდენად რთულიაო, გეტყოდით რომ ძნელია და დევოპსსა და დეველოპერს შორის
კარგ კოორდინაციას მოითხოვს, მაგრამ იგივეს თუ მკითხვთ ახლა გეტყვით რომ ძალიან მარტივია და იმდენი კომუნიკაცია და ძალისხმევაც აღარაა საჭირო.

What and Why

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

.NET Aspire არის გამოცდილების ჯამი, რომელიც Microsoft მა და სხვა დიდმა კომპანიებმა მიიღეს მაღალი წვდომადობის, დისტრიბუციულ აპლიკაციებზე მუშაობის შედეგად. რას ვგულისხმობ ამაში? Aspire არის მიდგომების, იდეებისა და ხელსაწყოების ერთობლიობა, რომელიც საჭირო იყო ამ აპლიკაციების დეველოპმენტისას და უკვე კარგად გამოიცადა PROD ზე მაღალი მოთხოვნადობის აპლიკაციებში, რომლებიც 24x7 ზე მუშაობენ. თუნდაც თიმსი ავიღოთ მაგალითად.

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

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

Briefly about core concepts

ალაგ-ალაგ ძირითად მომენტებს მოგიყვებით .NET Aspire ის შესახებ:

Orchestration

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

.NET Aspire components

.NET Aspire კომპონენტები NuGet პაკეტებია, რომელთა მიზანია პოპულარულ სერვისების ჩვენს პროექტში ინტეგრირების გამარტივება და მათთან კავშირის უწყვეტობის უზრუნველყოფა. კომპონენტები იგივე ინტერფეისებს გვაწვდიან რასაც ორიგინალი ბიბლიოთეკები, თუმცა ამატებენ ზემოდან მუდმივი კავშირის უზრუნველსაყოფ და მონიტორინგისთვის საჭირო კონფიგურაციებს.
ანუ კომპონენტები უზრუნველყოფენ, Aspire ში ჩამოყალიბებული მიდგომებისთვის საჭირო კონფიგურაციების გავრცელებას სხვადასხვა პოპულარულ ბიბლიოთეკებში. ასეთი სერვისებია Redis/StackExchangeRedis, Postgres/EFPostgre, SQL Server/EFSQLServer;

Project templates and tooling

.NET Aspire ს მოყვება თავისი შაბლონები ისევე როგორც სხვა .NET პროექტების აქვთ. მისი შაბლონი შედგება:

• MyFirstAspireApp: დანერგვადი პროექტი, რომელიც შეიძლება იყოს Api, Worker, Blazor Web app ან ნებისმიერი სხვა. შეგვიძლია
  პროექტში დავამატოთ სხვა პროექტებიც და AppHost სა და ServiceDefault ების დახმარებით Aspire ს აღვაქმევინოთ ისინი.
• MyFirstAspireApp.AppHost: პროექტი .AppHost ზედა დონის ორკესტრაციის დასაკონფიგურირებლად გამოიყენება.
• MyFirstAspireApp.ServiceDefaults: პროექტი .ServiceDefaults შეიცავს default კონფიგურაციებს, რომელბიც გაზიარდება ჩვენს აპლიკაციებს შორის.
  აქ შედის მაგალითად Health Check ების, OpenTelemetry და სხვა კონფიგურაციები.

Let's start with visuals (something people notice first) - Dashboard

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

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

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

ასევე ხელთ გვაქვს ტრეისების ნახვის საშუალება. .NET Aspire default ად აკონფიგურირებს ტრეისინგს ყველა პროექტში.
თუ არ ვიცით მაინც ვახსენებ, რომ Distributed tracing არის ფართოდ გამოყენებული დიაგნოსტიკის ტექნიკა, რომელიც
გვეხმარება სხვადასხვა აპლიკაციებს შორის მოძრავი რექვესთის tracking ში. იგი განსაკუთრებით მაშინაა გამოსადეგი, როცა ჩვენი აპლიკაციები სხვადასხვა მანქანებზეა რამდენიმე რეპლიკად გაშვებული. შევასრულოთ ერთი სატესტო რექვესთი და მის ტრეისს გავყვეთ. როგორც ხედავთ ტრეისებში კარგად ჩანს
რა აპლიკაციამ რა გამოძახა და შესაბამისად რა დრო დასჭირდა თითოეულ რექვესთს. ასევე სადმე თუ რექვესთი დაფეილდებოდა ეგეც აქ გამოჩნდებოდა კარგად.
თუ დაგვჭირდა კონკრეტული ტრეისის ლოგების ნახვა ესეც მარტივად შეგვიძლია, პირდაპირ ტრეისიდან გადავალთ ლოგებში და
ავტომატურად შესაბამისი ტრეის აიდით გაფილტრული ლოგები გაგვეხსნება. ანუ ფაქტობრივად გვაქვს მინი დაინაც.

Aspire ის მიდგომების შესაბამისად Demo აპლიკაციის თითოეულ პროექტში კონფიგურირებულია OpenTelemetry ის მეტრიკები.
ამ კონფიგურაციით მიღებულ ინფორმაციას ვიხილავთ Metrics გვერდზე. შეგვიძლია დავაკვირდეთ აპლიკაციის მდგომარეობას
Runtime ში, ვნახოთ CPU/Memory გამოყენება, დავაკვირდეთ GC როგორ მუშაობს და ასევე ვნახოთ როგორი Response Time გვაქვს.
ყველა ზემოთ ჩამოთვლილი საკმაოდ მნიშვნელოვანი მეტრიკაა, რომელიც ძალიან გამოსადეგია პერფორმანს ტესტის დროს.

სურვილისამებრ შეგვიძლია დეშბორდი დამოუკიდებლად გავუშვათ, როგორც standalone აპლიკაცია. ვინაიდან დეშბორდი კარგი მონიტორინგის ხელსაწყოა
და უფასო ალტერნატივებს შორის მართლაც რომ ვალიდურია, შეგვიძლია იგი გამოვიყენოთ როგორც standalone აპლიკაცია მონიტორინგისთვის.
ამისთვის შეგვიძლია aspire-dashboard დოკერ იმიჯი გამოვიყენოთ. როგორც უკვე ვახსენეთ აპლიკაციები დეშბორდზე ინფორმაციას OTLP პროტოკოლით გზავნიან
და შესაბამისად standalone დეშბორდსაც მსგავსად შეგვიძლია სასურველი აპლიკაციებიდან გავუგზავნოთ ტელემეტრიის დატა და მივიღოთ ის კარგი გამოცდილება
რასაც დეშბორდი გვთავაზობს მონიტორინგში.

---

Was it impressive? how was that possible?

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

Language

სანამ განვაგრძობთ მოდი გავეცნოთ საერთო ტერმინოლოგიას, რომელიც .NET Aspire ში გამოიყენება:

• აპლიკაციის მოდელი (App Model) - რესურსების კრებული, რომლისგანაც ჩვენი სოლუშენი შედგება
• რესურსი - რესურსი წარმოადგენს სოლუშენის/პროექტის ნაწილს, რომელიც შეიძლება იყოს .NET პროექტი, გაშვებადი exe ფაილი,
  კონტეინერი, ან სხვა გარე რესურსი, როგორიცაა ბაზა, რედისის ქეში ან რაიმე ქლაუდ სერვისი.
• აპლიკაციის ჰოსტი/ორკესტრატორი (AppHost) - .NET პროექტი, რომელიც უზრუნველყოფს აპლიკაციის მოდელის ორკესტრაციას
  მისი სახელი შეთანხმების მიხედვით უნდა სრულდებოდეს *.AppHost სუფიქსით.
• კავშირი? (Reference) - რეფერენსი აღწერს კავშირს რესურსებს შორის.

AppModel

Aspire ის ერთ-ერთი საუკეთესო feature არის ის, რომ დეველოპმენტის დასრულების შემდეგ შედეგად გვაძლევს ჩვენი სოლუშენის დამოკიდებულებების სრულ აღწერას. ამ სუპერ ფუნქციონალის გამოყენების საშუალებას გვაძლევს აპლიკაციის მოდელი. მიუხედავად იმისა რომ ზოგ კომპანიაში მსგავს დამოკიდებულებების აღწერას აკეთებენ საქმე საქმეზე რომ მიდის იშვიათად ახსენდებათ ხოლმე ეს აღწერები. მაგალითად როცა ახალ სატესტო გარემოზე ჩვენს ფუნქციონალს მართავენ მაშინ. და ამ დროს იწყება ერთი დიდი მკითხაობა რომელი სერვისი რას მიმართავს, რომელ სერვისს რომელ ინფრაზე სჭირდება წვდომა და ა.შ. ApplicationModel ზუსტად ამ პრობლემას აგვარებს. ვინაიდან მასში უკვე ყველაფერი აღწერილია და Aspire ის დახმარებით აპლიკაციის მოდელი შეგვიძლია გამოსადეგ კონფიგურაციის ფაილში/ფაილებში გადმოვთარგმნოთ. ფაქტობრივად აპლიკაციის დასანერგად ნახევარი გზა უკვე გავლილი გვაქვს. ყველა Aspire აპლიკაციაში არის AppHost პროექტი, რომელშიც იქმნება აპლიკაციის მოდელის აღწერა IDistributedApplicationBuilder ის და მისი მეთოდების დახმარებით.

AppHost

AppHost პროექტი ის მინი ორკესტრატორია, რომელიც ჩვენი აპლიკაციის ყველა პროექტს უშვებს და ხელმძღვანელობს.
მაგალითად დავაკვირდეთ ჩვენს დემო AppHost ს. AppHost პროექტში ხდება აპლიკაციის მოდელის აღწერა. კონკრეტულად აღწერა იწერება Program.cs ფაილში. მოდი ჩავხედოთ მას. ერთი შეხედვითვე მარტივად აღსაქმელია ეს ჩვენი აპლიკაციის მოდელი. ვხედავთ რომ მაგალითად მესიჯინგი მაქვს დარეგისტრირებული ჩემს აპლიკაციის მოდელში AddRabbitMQ მეთოდით, ხოლო SQL Server ი AddSqlServer მეთოდით. შემდეგ ვხედავთ რომ UserManagerApi მაქვს დარეგისტრირებული როგორც პროექტი. AddProject მეთოდი ჯენერიკია და ტიპად იღებს პროექტის ტიპის კლასებს. ეს კლასი ავტომატურად დაგენერირებულია, იგი იქმნება ყველა იმ პროექტისთვის რომელიც AppHost თან არის დარეფერენსებული. აქვე ძალიან კარგად ჩანს რომელი სერვისი რაზეა დამოკიდებული, მაგალითად UserManagerApi დამოკიდებულია RabbitMq ზე ვინაიდან შესაბამისი მეთოდით ამ ორ რესურსს ერთმანეთთან ვაკავშირებთ (WithReference(messaging)). ამ ლოგიკური აღწერით და იგება ჩვენი აპლიკაციის მოდელი, რომელსაც შემდეგ Aspire ის AppHost პროექტი იყენებს საორკესტრაციოდ. იგი უშვებს ყველა პროექტს რომელსაც ამ აღწერაში მოვაქცევთ, ქაჩავს ყველა image ს და უშვებს შესაბამის კონტეინერებს, რომელსაც აღვუწერთ/ან ეძებს ლოკალურად და შედეგად გვაძლევს გამართულ, მუშა მთლიან პროექტს თავისი დამოკიდებულებებიანად. კონტეინერები ვახსენე და დავამატებ რომ AddRabbitMQ ც და AddSQLServer იც ამჟამად ამ კონფიგურაციით დოკერ იმიჯს პულავენ და შესაბამისი კონტეინერების დახმარებით გვთავაზობენ rabbit სა და sql სერვერის ფუნქციონალებს. ანუ ექსტრა შრომის ჩადება არ გვიწევს ცალკე erlang ის დაყენებაში და ცალკე რებითის კონფიგურაციაში, ისევე როროგრც ცალკე sql სერვერის ლოკალურად ინსტალაციაში.

.NET Aspire ში გვაქვს სამი ძირითადი ტიპის რესურსები:

• პროექტები (AddProject/ProjectResource) - .NET პროექტი, მაგალითად UserManagerApi
• კონტეინერები (AddContainer/ContainerResource) - კონტეინერის იმიჯები, მაგალითად დოკერი.
• გაშვებადი ფაილები (AddExecutable/ExecutableResource) - გაშვებადი ფაილი.

რესურსებს შორის კავშირი გამოიხატება WithReference მეთოდით. მაგალითად .WithReference(UserManagerDb) გვეუბნება რომ userManagerApi ს აქვს დამოკიდებულება userManager ბაზასთან. დამოკიდებულებები შეიძლება აღწერილი იყოს როგორც Connection string ები ან როგორც ServiceDiscovery ინფორმაცია. ჩვენ მაგალითში ეს დამოკიდებულება გარდაიქმნება როგორც Connection String ენვაირონმენტ ცვლადი (ConnectionStrings__UserManagerDb) რომელიც ჩაეწოდება UserManagerApi პროექტს. ასევე ჩვენს მაგალითში UserManagerAdmin დაკავშირებულია UserMangerApi თან. პროექტებს შორის კავშირები უფრო სხვანაირად მუშავდება ვიდრე ისეთ რესურსებთან კავშირები რომლებსაც ჩამოყალიბებული ქონექშენ სტრინგები აქვთ. ასეთ შემთხვევაში ქონექშენ სტრინგის მაგივრად იქმნება ენვაირონმენტ ცვლადები, რომლებიც Service Discovery თვის არის საჭირო იმ აპლიკაციაში სადაც ამ კავშირს ვამატებთ.

services__usermanagerapi__http__0="http://localhost:5455" services__usermanagerapi__https__0="https://localhost:7356"

კონკრეტულ შემთხვევებში თუ გვინდა რომ ხელით დავაკონფიგურიროთ რესურსის საკომუნიკაციო ენდპოინტი შეგვიძლია კიდეც WithEndpoint მეთოდის დახმარებით.

var customContainer = builder.AddContainer("myapp", "mycustomcontainer")
                             .WithHttpEndpoint(port: 9043, name: "endpoint");

var endpoint = customContainer.GetEndpoint("endpoint");

var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
                        .WithReference(endpoint);

ამჟამად Aspire ს ასევე დამატებული აქვს არაერთი სხვა სახის ხშირად გამოყენებადი რესურსი როგორებიცაა SqlServer, Mongo, Postgres, Redis, Rabbit და კიდევ სხვა მრავალი რომელთა სია შეგიძლიათ დოკუმენტაციაში იხილოთ.

Components

როგორც უკვე ვახსენეთ Aspire component ები ნაგეტ პაკეტებია რომელთა ძირითადი დანიშნულებაა ჩვენთვის საჭირო სერვისებთან კავშირის დამყარების გამარტივება და ამ კავშირის უწყვეტობის უზრუნველყოფაა. ამას კომპონენტები რამდენიმე გზით აღწევენ, ერთ-ერთია კონფიგურაციების მოშორება ჩვენი აპლიკაციის ფაილებიდან. მაგალითად მიუხედავად იმისა რომ userManagerApi ში ვიყენებ SQL Server ს Connection String არსადაა მითითებული. როგორც უკვე აღვნიშნეთ Aspire ლოკალური დეველოპმენტის გამოცდილების გაუმჯობესებას ემსახურება და ამის მიღწევის ერთ-ერთ გზად ჩვენი აპლიკაციის კონფიგურირების გამარტივება აქვს მიზნად დასახული. ამ მიზნის შესრულებაში მას კომპონენტები ეხმარებიან. გამომდინარე აქედან ბევრ კონფიგურაციას თავად აკეთებს Aspire გარემოს ცვლადებში. როგორც უკვე ვახსენეთ როცა SQL სერვერს ან რაიმე სხვა Connection String იან რესურსს ვირეფერენსებთ Aspire ში, შესაბამისი რესურსის Connection string გარემოს ცვლადად გარდაიქმნება. DbContext ის სერვისებში რეგისტრაციისას საკმარისია მივუთითოთ ბაზის რესურსის სახელი, იმისათვის რომ შესაბამისი Connection String მოიპოვოს EF SQL Server ის კომპონენტმა. მსგავსადვე იქცევა HttpClient. აღარაა საჭირო ლოკალურად რომელი აპლიკაცია რა პორტზეა გაშვებული ამის მკითხაობა. საკმარისია HttpClient ის base url ში გავწეროთ შესაბამისი რესურსის სახელი და Service Discovery თავისით მიხედავს საქმეს. თუმცა აქვე უნდა აღვნიშნო რომ სურვილისამებრ შეგვიძლია ისევ კლასიკურად Connection String გამოვიყენოთ და გარე რესურსს დავუკავშირდეთ დოკერის გარეშე. ბიბლიოთეკა რომელიც ბაზის connection string ის მოპოვებაში გვეხმარება Aspire.Microsoft.EntityFrameworkCore.SqlServer ია. მას და მის მსგავს ბიბლიოთეკებს .NET Aspire ში ეწოდება კომპონენტები.

ყველაზე მნიშვნელოვანი რასაც კომპონენტები გვთავაზობენ სტანდარტიზაციაა. იმისათვის რომ Nuget Package ჩაითვალოს კომპონენტად მან რამდენიმე მოთხოვნა უნდა დააკმაყოფილოს:

• სტანდარტულ ფორმატში მოქცეული სეტინგები უნდა ჰქონდეს
• უნდა დააკონფიგურიროს ლოგირება, ტრეისინგი და მეტრიკები
• უნდა ჰქონდეს health check
• სადაც რელევანტურია უნდა ჰქონდეს Resiliency დაკონფიგურირებული

უკვე არსებული კომპონენტები რომლებიც ჩვენ გამოგვადგება:

• Aspire.Microsoft.Data.SqlClient - SQL Server თან წვდომისთვის
• Aspire.Microsoft.EntityFrameworkCore.SqlServer - SQL Server თან წვდომისთვის EF ით
• Aspire.StackExchange.Redis - რედის ქეშთან სამუშაოდ
• Aspire.RabbitMQ.Client - Rabbit თან სამუშაოდ
• Aspire.Npgsql - Postgre თან სამუშაოდ
• Aspire.Npgsql.EntityFrameworkCore.PostgreSQL - Postgre EF
• etc...

შესაბამისად ჩვენ თუ ყველა კომპონენტი default მოგვაწვდის Logging, Tracing და Metric ს კონგიურაციებს, გამოვა რომ Pillars Of Observability უკვე ხელთ გვექნება, რაც საკმაოდ გაამარტივებს ჩვენს საქმეს პრობლემების კვლევისას თუ სხვა პროცესში და მეტ ინფოს მოგვცემს ჩვენი აპლიკაციის შესახებ.

Example

Health Check ების კონფიგურაციაც საკმაოდ მნიშვნელოვანია, ვინაიდან მის შედეგებს გავლენა ექნება Load balancer ის Orchestrator ისა და API Gateway ის გადაწყვეტილებებზე. მაგალითად თუ რომელიმე კომპონენტი დააბრუნებს პასუხს Unhealthy კონკრეტული პოდისთვის ბალანსერი ამ პოდზე რექვესთებს აღარ გაუშვებს.

Aspire ის კომპონენტები როგორც აღვნიშნეთ Resiliency საც აკონფიგურირებენ. ანუ ყველა კომპონენტში გვექნება Connection Retry ის მცდელობები როცა სერვისთან კავშირი დაიკარგება, ასევე Timeout ები.

Service Binding and Reverse Proxy (app replicas), Launch Profiles

რამდენიმე მაგალითი ვნახეთ იმისა თუ როგორ შეგვიძლია პროექტები და ჩვენი სოლუშენის სხვა რესურსები დავაკავშიროთ ერთმანეთთან თუმცაღა Networking ის ამბავს ჯერ არ შევხებივართ. მოდი გავეცნოთ როგორ იყენებს Aspire პროქსიებს, რა არის სერვის ბაინდინგი, ენდპოინტ კონფიგურაციები და Launch Profile ები. .NET Aspire ნეთვორქინგის კონფიგურაციის პროცესის გასამარტივებლად რამდენიმე ხელსაწყოს იყენებს:

• Launch Profiles: მათ დარწმუნებული ვარ ყველა იცნობთ უკვე. ამ ფაილებში აღწერილია, თუ როგორ გაეშვას ჩვენი აპლიკაცია ლოკალურად, მასში შეგვიძლია აღვწეროთ ენვაირონმენტ ცვლადები, გავწეროთ პორტები http და https თვის.
• Service bindings/Endpoint configurations: Service Binding ები არის კავშირები ჩვენს აპლიკაციებსა და იმ სხვა სერვისებს/აპლიკაციებს შორის რომლებზეც ისინი დამოკიდებულნი არიან. Service bindings provide information such as the service name, host port, scheme, and environment variable.
• Proxies: .NET Aspire ავტომატურად უშვებს პროექსის ყველა სერვის ბაინდინგისთვის, რომელიც ჩვენს აპლიკაციის მოდელში აღწერილია. პროქსი ეშვება შესაბამის ენდპოინტზე რომელიც მაგალითად launch settings შია გაწერილი და შემდეგ რექვესთებს გადაამისამართებს აპლიკაციისთვის რენდომად მინიჭებულ პორტზე. ეს საშუალებას გვაძლევს თავი ავარიდოთ კონფლიქტებს პორტთან დაკავშირებით, ასევე რაც მთავარია ქმნის შესაძლებლობას აპლიკაციის რამდნეიმე რეპლიკად გაშვებისა.

როგორ მუშაობს Service Binding

Service binding აკავშირებს ჩვენს აპლიკაციის მოდელში აღწერილ პროექტებს გარე რესურსებთან. Aspire ში ორი სახის binding არსებობს:

1. implicit - ავტომატურად იქმნება launchprofile ების დახმარებით
2. explicit - ხელით იწერება WithEndpoints მეთოდის დახმარებით

Binding ის შექმნის შემდეგ მიუხედავად იმისა implicit ია თუ explicit .NET Aspire უშვებს მსუბუქ reverse proxy ის პროფილში ან ხელით გაწერილ პორტზე, რომელიც როუტინგსა და დატვირთვის განაწილებას (Load balancing) ს აკეთებს. თავად პროქსი .NET Aspire შია იმპლემენტირებული და არ საჭიროებს რაიმე სახის კონფიგურაციას. რაში გვეხმარება ეს ყველაფერი? ერთი შეხედვით თითქოს ზედმეტი თავისტკივილია; რეალურ გარემოზე არასდროს კლიენტი არ მოდის პირდაპირ ჩვენს აპლიკაციასთან. ყოველთვის რექვესთი მოდის რაღაც პროქსის გავლით ჩვენ ამას დეველოპერები არასდროს ვამოწმებდით ლოკალურად. შესაბამისად შეიძლება რაღაც ქეისები ამის გამო გაგვპარვოდა, ან გამოგვრჩენოდა რომ ჩვენი აპლიკაცია რამდენიმე პოდზე ერთდროულად იმუშავებს და შესაბამისად ამ ქეისზე უნდა იყოს გათვლილი. თუ .NET Aspire ს გამოვიყენებთ ამ ქეისს ლოკალური ტესტირებისას დავფარავთ.

launch profile ებს რაც შეეხება, როდესაც AddProject მეთოდს ვიძახებთ AppHost ამ მეთოდში გადაცემულ პროექტში ეძებს launchSettings.json ფაილს და იმის მიხედვით ადგენს binding ს. ვინაიდან launchSetting ში შეიძლება ბევრი ვერსია გვქონდეს აპლიკაციის გასაშვებად შექმნილი, აპსეტინგების მსგავსად აქაც პატარა შიდა მექანიზმია ჩადებული იმის გადასაწყვეტად თუ რომელი launchSetting profile იქნება გამოყენებული სერვის ბაინდინგისთვის:

1. თუ AddProject მეთოდში ჰარდადაა გადაცემული profile ის სახელი
2. თუ გაწერილია DOTNET_LAUNCH_PROFILE ცვლადი
3. პირველივე launch profile

Ports and proxies

როდესაც ვქმნით Service Binding ს launchSetting ში გაეწრილი თუ ხელით მითითებული პორტი ყოველთვის Proxy ზე ჯდება ხოლმე. ეს საშუალებას იძლევა აპლიკაციის რამდენიმე რეპლიკა უპრობლემოდ გავუშვათ. მოდი ჩვენი UserManagerApi გავუშვად 3 რეპლიკად. ამისთვის უნდა გამოვიყენოთ .WithReplicas(3) მეთოდი აპლიკაციის მოდელში შედეგად მივიღებთ იმას რასაც ველოდით ჩვენი აპლიკაცია მართლაც 3 რეპლიკად გაეშვება, თუმცა მისი მისამართი Admin თვის იგივე დარჩება, ანუ პროქსის მისამართი იქნება. სურვილისამებრ შეგვიძლია საერთოდ მოვხსნათ პორტის კონფიგურაცია და Host პორტიც რომლიდანაც რექვესთები შემოვა და რეპლიკების პორტიც გავხადოთ რენდომი. ამისათვის გამოვიყენებთ WithHttpEndpoint() ცარიელ მეთოდს.

Service Defaults

როგორც უკვე აღვნიშნეთ .NET Aspire არა მხოლოდ ახალი ტექნოლოგიაა, არამედ მიდგომების და იდეების ერთიანობაცაა. შესაბამისად ამ მიდგომების სტანდარტში მოქცევისთვის Aspire გვთავაზობს ServiceDefaults პროექტს. იგი ბიბლიოთეკის სახის პროექტია და შეიცავს OpenTelemetry, Logging, Health Check, ServiceDiscovery, HttpClient config და სხვა default კონფიგურაციებს, რომლებიც Aspire ში მიიჩნევა როგორც საჭიროდ და გამოსადეგად ყველა პროექტისთვის. შეგვიძლია ამ პროექტის კოდსაც გავეცნოთ. პროექტში გვაქვს ერთი Extensions.cs კლასი რომელიც შეიცავს დეფოლტ სერვისების კონფიგურაციას. მაგალითად დავინახავთ რომ დასაწყისში კონფიგურირდება OpenTelemetry, ემატება შესაბამისი მეტრიკები და კონფიგურირდება OTLP Exporter ები. რომელთა დახმარებითაც შემდეგ დეშბორდზე გვიჩანს საინტერესო და ლამაზი მეტრიკები. ახალი აპლიკაციის დამატებისას იმისათვის რომ .NET Aspire ის მიდგომებში ჩავჯდეთ და ასევე დეშბორდის ფუნქციონალი სრულად გამოვიყენოთ საჭიროა builder.AddServiceDefautls() გამოვიძახოთ და ასევე app.MapDefaultEndpoints() Health Check ების ენდპოინტების დასაკონფიგურირებლად.

Manifest and docker compose generation using aspirate

ბოლოს აუცილებლად მინდა ვისაუბრო .NET Aspire ის ერთ-ერთ საუკეთესო feature ზე. იმ ფუნქციონალზე, რომელმაც წესით უნდა გაგვიმარტივოს ბევრი რამ აპლიკაციის დანერგვის ნაწილში. ესაა Aspire-Manifest. aspire ს შეუძლია ჩვენი აპლიკაციის აღწერის დაგენერირება სტანდარტულ ფორმატში, რომელიც შემდეგ შეგვიძლია გადავთარგმნოთ თუნდაც docker compose ფაილებში ან k8s თვის საჭირო დასანერგ ფაილებში. დარწმუნებული ვარ რაიმე ახალ პროექტზე თუ გიმუშავიათ სადაც CI-CD უკვე გამართული არაა, მისი პირველი გამართვისას ბევრ პრობლემას შეეჩეხებოდით. აღმოჩნდებოდა რომ უი სატესტოზე ამ და ამ სერვისზე წვდომა არ არის, უი SQL Server ის user დაგვავიწყდა, უი ეს უი ის. მთლად უარესი თუ ეს ყველაფერი პროდზე მოხდება და არა სატესტოზე. Aspire manifest ამ პრობლემებისგან დაგვაზღვევს, გამომდინარე იქიდან რომ გვექნება ზუსტი აღწერა იმისა თუ რა სერვისსა თუ ინფრასტრუქტურაზე სჭირდება ჩვენს აპლიკაციას წვდომა, მექანიკური და ადამიანური შეცდომები დავა მინიმუმამდე.

cd ../*AppHost.csproj

 dotnet run --publisher manifest --output-path ../aspire-manifest.json

ვნახოთ რა გვაქვს მასში. გვაქვს დიდი რესურსების ობიექტი, რომელშიც მოქცეულია აპლიკაციის მოდელში აღწერილი ყველა რესურსი. მაგალითად თავშივე გვაქვს RabbitMQ ს რესურსის აღწერა. გვიწერია მისი ქონექშენ სტრინგი. მასში საჭირო ცვლადები მოცემულია ფიგურულ ფრჩხილებში. აქვე ვხედავთ საჭირო environment ცვლადებს, რომელთა ნაწილშიც მნიშნველობა უკვე შევსებულია, ხოლო სადაც საჭიროა მნიშვნელობის შემოწოდება, მაგალითად default user ის პაროლში, შესაბამისი ცვლადის აღმნიშვნელი მნიშვნელობაა შევსებული. ახლა მანიფესტში RabbitMQ ს რესურსი აღწერილია როგორც კონტეინერი, თუმცა ეს შეგვიძლია შევცვალოთ და მივანიშნოთ Aspire ს რომ მაფისეტის გენერირებისას ეს რესურსი გამოაჩინოს როგორც უბრალოდ connection-string.

 dotnet run --publisher manifest --output-path ../aspire-manifest-updated.json

შევამჩნევთ რომ ბევრად განსხვავებულია messaging რესურსის კონფიგურაცია ახლა მანიფესტში. იგივე შეგვიძლია გავაკეთოთ SQL Server ზეც და სხვა საჭირო რესურსებზეც.

აქვე დავაკვირდეთ პროექტების კონფიგურაციას. შევამჩნევთ რომ გაწერილია შესაბამისი environment ცვლადები, მათ შორის Connection string ები და სხვა სერვისების მისამართები (binding template ით).

აქვე უცებ შეგვიძლია გავეცნოთ ძალიან კარგ თულს რომელიც Aspire თან ერთად ვითარდება, მისი სახელია Aspirate. იგი საშუალებას იძლევა manifest პირდაპირ docker compose ში ან k8s ის yaml ფაილებში გადავთარგმნოთ.

მის დასაინსტალირებლად შეგიძლიათ გაუშვათ

dotnet tool install -g aspirate --prerelease

შემდეგ დავდგებით ჩვენთვის საჭირო AppHost პროექტში და გავუშვებთ

aspirate generate

ან თუ მხოლოდ docker compose ფაილის შექმნა გვინდა

aspirate generate --output-format compose