Biz DevOps-u bacardığımız qədər inkişaf etdirdik. Biz 8 nəfər idik və Vasya Windows-un ən yaxşısı idi. Birdən Vasya getdi və mənim qarşımda Windows inkişafı tərəfindən təmin edilən yeni bir layihəyə başlamaq vəzifəsi var idi. Bütün Windows inkişaf yığınını masaya tökəndə vəziyyətin ağrılı olduğunu başa düşdüm ...
Hekayə belə başlayır Aleksandra Sinçinova haqqında . Windows-un aparıcı mütəxəssisi şirkətdən ayrılanda İskəndər indi nə edəcəyini düşündü. Əlbəttə ki, Linux-a keçin! Alexander, 100 son istifadəçi üçün həyata keçirilən layihənin nümunəsindən istifadə edərək, bir presedent yaratmağı və Windows inkişafının bir hissəsini Linux-a köçürməyi necə bacardığını izah edəcək.
TFS, Puppet, Linux .NET nüvəsindən istifadə edərək layihəni RPM-ə asanlıqla necə çatdırmaq olar? İnkişaf Postgres və Flyway sözlərini ilk dəfə eşidirsə və son tarix sabahdan sonrakı gündürsə, layihə verilənlər bazası versiyasını necə saxlamaq olar? Docker ilə necə inteqrasiya etmək olar? .NET tərtibatçılarını Kukla və Linux-un xeyrinə Windows və smoothies-dən uzaqlaşmağa necə həvəsləndirmək olar? İstehsalda Windows-a xidmət etmək üçün güc, istək, resurs yoxdursa, ideoloji münaqişələri necə həll etmək olar? Bu barədə, həmçinin Web Deploy, sınaq, CI, mövcud layihələrdə TFS-dən istifadə təcrübələri və əlbəttə ki, sınıq qoltuq dəyənəkləri və iş həlləri haqqında, İskəndərin hesabatının stenoqramında.
Beləliklə, Vasya ayrıldı, vəzifə mənim üzərimdədir, tərtibatçılar səbirsizliklə çəngəllərlə gözləyirlər. Nəhayət ki, Vasyanın geri qaytarıla bilməyəcəyini anlayanda işə başladım. Başlamaq üçün donanmamızda Win VM-nin faizini təxmin etdim. Hesab Windows-un xeyrinə olmadı.
DevOps-u fəal şəkildə inkişaf etdirdiyimiz üçün yeni bir tətbiqin çıxarılmasına yanaşmada nəyisə dəyişdirmək lazım olduğunu başa düşdüm. Yalnız bir həll var idi - mümkünsə, hər şeyi Linux-a köçürün. Google mənə kömək etdi - o vaxt .Net artıq Linux-a köçürülmüşdü və mən başa düşdüm ki, həll yolu budur!
Niyə .NET nüvəsi Linux ilə birlikdə?
Bunun bir neçə səbəbi var idi. "Pul ödəmək" və "ödəməmək" arasında əksəriyyət ikincini seçəcək - mənim kimi. MSDB lisenziyası təxminən 1 dollara başa gəlir və Windows virtual maşınları parkının saxlanması yüzlərlə dollara başa gəlir. Böyük bir şirkət üçün bu, böyük xərcdir. Buna görə də qənaət - birinci səbəb. Ən vacib deyil, ən əhəmiyyətlilərindən biridir.
Windows virtual maşınları Linux qardaşlarından daha çox resurs tutur - ağırdırlar. Böyük bir şirkətin ölçüsünü nəzərə alaraq Linux-u seçdik.
Sistem sadəcə mövcud CI-yə inteqrasiya olunub. Biz özümüzü mütərəqqi DevOps hesab edirik, biz Bamboo, Jenkins və GitLab CI istifadə edirik, ona görə də çoxumuz Linux-dayıq.
Son səbəb rahat müşayiət. Texniki hissəni başa düşən, fasiləsizliyi təmin edən və xidmətlərə ikinci cərgədən xidmət göstərən uşaqlar üçün "xidmətçilər" üçün giriş həddini aşağı salmalı olduq. Onlar artıq Linux yığını ilə tanış idilər, ona görə də Windows platforması üçün proqram təminatının oxşar funksionallığı ilə məşğul olmaq üçün əlavə resurslar sərf etməkdənsə, yeni məhsulu başa düşmək, onu dəstəkləmək və ona qulluq etmək onlar üçün daha asandır.
Tələblər
Hər şeydən əvvəl - tərtibatçılar üçün yeni həllin rahatlığı. Onların heç də hamısı dəyişməyə hazır deyildi, xüsusən də şifahi Linux sözündən sonra. Tərtibatçılar öz sevimli Visual Studio-nu, qurma avtotestləri və smoothies ilə TFS istəyirlər. İstehsalata çatdırılmanın necə baş verdiyi onlar üçün önəmli deyil. Buna görə də, biz adi prosesi dəyişdirməməyə və Windows inkişafı üçün hər şeyi dəyişmədən buraxmağa qərar verdik.
Yeni layihə lazımdır mövcud CI-yə daxil edin. Relslər artıq orada idi və bütün işlər konfiqurasiya idarəetmə sisteminin parametrləri, qəbul edilmiş çatdırılma standartları və monitorinq sistemləri nəzərə alınmaqla görülməli idi.
Baxım və istismar asanlığı, müxtəlif şöbələrdən və dəstək departamentindən olan bütün yeni iştirakçılar üçün minimum giriş həddinin şərti kimi.
Son tarix - dünən.
İnkişaf komandası qazanın
Windows komandası o zaman nə edirdi?
İndi bunu əminliklə deyə bilərəm Identity Server4 oxşar xüsusiyyətlərə malik olan ADFS-ə sərin pulsuz alternativdir və ya hər hansı Entity Framework Core - SQL skriptlərini yazmaqla məşğul ola bilməyəcəyiniz, lakin verilənlər bazasındakı sorğuları OOP baxımından təsvir edən bir tərtibatçı üçün cənnət. Ancaq sonra, fəaliyyət planını müzakirə edərkən, bu yığına şumer mixi yazısı kimi baxdım, yalnız PostgreSQL və Git-i tanıyırdım.
O vaxt biz fəal şəkildə istifadə edirdik kukla konfiqurasiya idarəetmə sistemi kimi. Əksər layihələrimizdə istifadə etmişik GitLab CI, Elastik, yüksək yüklənmiş xidmətlərin balanslaşdırılması HAProxy hər şeyi izləyirdi Zabbix, paketlər Qrafana и Prometey, Jaeger, və bütün bunlar dəmir parçaları üzərində fırlanırdı HP c ESXi haqqında VMware. Hər kəs bilir - janrın klassiki.
Bütün bu müdaxilələrə başlamazdan əvvəl nə baş verdiyinə baxaq və anlamağa çalışaq.
Nə olub
TFS kifayət qədər güclü bir sistemdir ki, o, yalnız tərtibatçıdan son istehsal maşınına kodu çatdırır, həm də müxtəlif xidmətlərlə çox çevik inteqrasiya üçün dəstə malikdir - platformalararası səviyyədə CI təmin etmək üçün.
Əvvəllər bunlar möhkəm havalandırma kanalları idi. TFS bir çox layihə quran bir neçə Quraşdırma Agentindən istifadə etdi. Tapşırıqları paralelləşdirmək və prosesi optimallaşdırmaq üçün hər agentin 3-4 işçisi var. Bundan əlavə, buraxılış planlarına əsasən, TFS təzə bişmiş Build-i Windows proqram serverinə çatdırdı.
Hara getmək istəyirdik
Biz çatdırılma və inkişaf üçün TFS-dən istifadə edirik və tətbiqi Linux Tətbiq serverində işlədirik və onların arasında bəzi sehr var. Bu Sehrli qutu və qarşıda işin duzu var. Onu ayırmadan əvvəl bir addım kənara atıb proqram haqqında bir neçə söz deyəcəyəm.
Layihə
Tətbiq əvvəlcədən ödənilmiş kartlarla işləmək üçün funksionallıq təmin edir.
Müştəri
İki növ istifadəçi var idi. Ilk SSL SHA-2 sertifikatı ilə daxil olmaqla əldə edilir. At ikincisi istifadəçi adı və şifrə ilə daxil olub.
HAProxy
Sonra müştəri sorğusu aşağıdakı vəzifələri həll edən HAProxy-ə getdi:
- ilkin icazə;
- SSL-in ləğvi;
- HTTP sorğularının tənzimlənməsi;
- tərcümə tələb edin.
Müştəri sertifikatının yoxlanılması zəncir boyunca getdi. Biz - səlahiyyət və biz bunu ödəyə bilərik, çünki özümüz xidmətin müştərilərinə sertifikatlar veririk.
Üçüncü məqama diqqət yetirin, bir az sonra ona qayıdacağıq.
Arxa
Backendin Linux-da hazırlanması planlaşdırılırdı. Backend verilənlər bazası ilə qarşılıqlı əlaqədə olur, tələb olunan imtiyazlar siyahısını yükləyir və sonra səlahiyyətli istifadəçinin hansı imtiyazlara malik olmasından asılı olaraq, maliyyə sənədlərini imzalamaq və onları icraya göndərmək və ya bir növ hesabat yaratmaq imkanı verir.
HAProxy ilə qənaət
Müştərilərin hər birinin getdiyi iki kontekstdən əlavə, şəxsiyyət konteksti də var idi. Identity Server4 sadəcə daxil olmağa imkan verir, bu pulsuz və güclü analoqdur ADFS - Active Directory Federasiyası xidmətləri.
Şəxsiyyət sorğusu bir neçə mərhələdə işlənib. İlk addım - müştəri arxa tərəfə vurun, bu serverlə əlaqə saxlayan və müştəri üçün işarənin olub-olmadığını yoxladı. Əgər onu tapmasa, sorğu gəldiyi kontekstə qayıtdı, lakin yönləndirmə ilə və yönləndirmə ilə şəxsiyyətə getdi.
İkinci addım - sorğu alındı IdentityServer-də avtorizasiya səhifəsinə, müştərinin qeydiyyatdan keçdiyi yer və çoxdan gözlənilən nişan IdentityServer verilənlər bazasında göründü.
Üçüncü addım - müştəri geri yönləndirildi hansı kontekstdən gəldiyinə.
IdentityServer4 bir xüsusiyyətə malikdir: HTTP vasitəsilə geri qaytarma sorğusuna cavabı qaytarır. Serveri qurmaqda nə qədər mübarizə aparsaq da, sənədlər nə qədər aydın olsa da, hər dəfə HTTPS vasitəsilə gələn URL ilə ilkin müştəri sorğusunu aldıq və IdentityServer eyni konteksti qaytardı, lakin HTTP ilə. Biz şok olduq! Və biz bütün bunları şəxsiyyət kontekstindən HAProxy-ə köçürdük və başlıqlarda HTTP protokolunu HTTPS-ə dəyişməli olduq.
Təkmilləşdirmə nədir və harada qənaət etdiniz?
Biz IdentityServer4-ü ayrıca seqmentdə ayrıca bir qovşaq kimi çıxarmadıq, lakin proqramın arxa hissəsinin işlədiyi eyni serverdə backend ilə birlikdə istifadə etdiyimiz üçün bir qrup istifadəçiyə, resurslara icazə vermək üçün pulsuz həll yolu ilə pula qənaət etdik. .
Necə işləməlidir
Beləliklə, söz verdiyim kimi - Sehrli qutu. Artıq başa düşürük ki, Linux-a doğru irəliləyəcəyimizə zəmanət verilir. Həll edilməli olan konkret vəzifələri formalaşdıraq.
Kukla təzahür edir. Xidmətin və tətbiqin konfiqurasiyasını çatdırmaq və idarə etmək üçün sərin reseptlər yazmalı idiniz. Qələm rulonu bunun nə qədər tez və səmərəli edildiyini gözəl şəkildə göstərir.
Çatdırılma üsulu. Standart RPM-dir. Hər kəs başa düşür ki, Linux-da onsuz bir yol yoxdur, lakin montajdan sonra layihənin özü icra edilə bilən DLL faylları toplusu idi. Onların təxminən 150-si var idi, layihə kifayət qədər ağırdır. Yeganə ahəngdar həll bu ikili faylı RPM-ə yığmaq və ondan tətbiqi yerləşdirməkdir.
Versiyalaşdırma. Çox tez-tez buraxmalı olduq və paket adını necə formalaşdıracağımıza qərar verməli olduq. Söhbət TFS ilə inteqrasiya səviyyəsindən gedir. Linux-da qurma agentimiz var idi. TFS Quraşdırma agentində işçiyə - işçiyə tapşırığı göndərdikdə, o, həm də ona işləyici prosesinin mühitinə düşən dəyişənlər dəstəsini ötürür. Bu mühit dəyişənlərinə Quraşdırma adı, versiya adı və digər dəyişənlər ötürülür. Bu barədə daha çox "RPM paketinin yaradılması" bölməsində oxuyun.
TFS-nin qurulması Boru Kəmərinin qurulmasına gəldi. Əvvəllər biz bütün Windows layihələrini Windows agentlərində topladıq və indi Linux agenti görünür - bu Quraşdırma agentində hansı tip layihələrin qurulacağını söyləmək üçün bəzi artefaktlarla zənginləşdirilərək qurma qrupuna daxil edilməli olan Quraşdırma agenti, və bir şəkildə Boru Kəmərini dəyişdirin.
Identity Server. ADFS bizim yolumuz deyil, biz Open Source üçün boğuluruq.
Gəlin komponentləri nəzərdən keçirək.
Sehrli qutu
Dörd hissədən ibarətdir.
Linux Quraşdırma Agenti. Linux, çünki biz bunun üçün qururuq - bu məntiqlidir. Bu hissə üç mərhələdə həyata keçirildi.
- İşçiləri təyin edin və bir deyil, çünki layihə üzrə paylanmış iş nəzərdə tutulurdu.
- .NET Core 1.x quraşdırın. 1 standart repozitoriyada mövcud olduqda niyə 2.0.x? Çünki biz inkişafa başlayanda stabil versiya 1.09 idi və layihəni onun üçün etmək qərara alındı.
- Git 2.x.
RPM anbarı. RPM paketləri bir yerdə saxlanmalı idi. Biz bütün Linux hostları üçün mövcud olan eyni korporativ RPM deposundan istifadə etməli idik. Və belə etdilər. Repozitor serveri konfiqurasiya edilib veb qarmaq müəyyən edilmiş yerdən tələb olunan RPM paketini endirmişdir. Webhookun paket versiyası Build agenti tərəfindən bildirildi.
gitlab. Diqqət! GitLab burada tərtibatçılar tərəfindən deyil, əməliyyatlar şöbəsi tərəfindən proqram versiyalarına, paket versiyalarına nəzarət etmək, bütün Linux maşınlarının vəziyyətinə nəzarət etmək üçün istifadə olunur və resepti saxlayır - bütün Kukla manifestləri.
kukla - bütün mübahisəli məqamları həll edir və Gitlab-dan istədiyimiz konfiqurasiyanı tam olaraq çatdırır.
Dalmağa başlayırıq. DLL RPM-ə necə çatdırılır?
DDL-nin RPM-ə çatdırılması
Tutaq ki, bizdə .NET inkişaf rockstar var. O, Visual Studio istifadə edir və buraxılış filialı yaradır. Bundan sonra onu Git-ə yükləyir və Git burada bir TFS varlığıdır, yəni tərtibatçının işlədiyi proqram repozitoriyasıdır.
Sonra TFS yeni bir öhdəlik gəldiyini görür. Hansı proqram? TFS parametrlərində bu və ya digər Build agentinin hansı resurslara malik olduğu ilə bağlı etiket var. Bu halda, bizim .NET Core layihəsini qurduğumuzu görür və hovuzdan Linux Build agentini seçir.
Build-agent mənbələri alır, lazım olanı yükləyir bağımlılıkları .NET deposundan, npm və s. və proqramın özünü və sonrakı qablaşdırmanı qurduqdan sonra RPM paketini RPM deposuna təqdim edir.
Digər tərəfdən, aşağıdakılar baş verir. Əməliyyat şöbəsinin mühəndisi layihənin həyata keçirilməsində birbaşa iştirak edir: paketlərin versiyalarını dəyişdirir. Hiera proqram reseptinin saxlandığı depoda, bundan sonra Kukla tetikler Yum, depodan yeni paketi çıxarır və tətbiqin yeni versiyası istifadəyə hazırdır.
Sözlə, hər şey sadədir, lakin Build agentinin özündə nə baş verir?
DLL RPM-lərin qablaşdırılması
TFS-dən layihə mənbələri və qurmaq tapşırığı alındı. Quruluş agenti mənbələrdən layihənin özünü qurmağa başlayır. Yığılmış layihə komplekt şəklində mövcuddur dll faylları, fayl sistemindəki yükü azaltmaq üçün zip arxivinə yığılır.
ZIP arxivi atılır RPM paketinin qurma qovluğuna. Sonra, Bash skripti mühit dəyişənlərini işə salır, Quraşdırma versiyasını, layihə versiyasını, qurma qovluğuna gedən yolu tapır və RPM-build-i işə salır. Quraşdırma tamamlandıqda, paket dərc olunur yerli depo, Quraşdırma agentində yerləşir.
Bundan əlavə, Quraşdırma agentindən RPM deposundakı serverə qədər JSON sorğusu göndərildi versiyanın adı və qurun. Daha əvvəl qeyd etdiyim Webhook, eyni paketi Build agentindəki yerli depodan endirir və yeni quruluşu quraşdırma üçün əlçatan edir.
Paketi RPM deposuna çatdırmaq üçün niyə belə bir sxem var? Niyə qurulmuş paketi dərhal depoya itələyə bilmirsiniz? Fakt budur ki, bu, təhlükəsizliyin təmin edilməsi üçün şərtdir. Bu ssenari icazəsiz insanların RPM paketlərini bütün Linux maşınları üçün əlçatan olan serverə yükləmək imkanını məhdudlaşdırır.
Verilənlər bazasının versiyalaşdırılması
İnkişaf üzrə məsləhətləşmədə məlum oldu ki, uşaqlar MS SQL-ə daha yaxındırlar, lakin Windows olmayan layihələrin əksəriyyətində PostgreSQL-dən güc və əsas istifadə etdik. Artıq ödənilən hər şeyi tərk etmək qərarına gəldiyimiz üçün PostgreSQL-dən burada da istifadə etməyə başladıq.
Bu hissədə sizə verilənlər bazasını necə versiyalaşdırdığımızı və Flyway və Entity Framework Core arasında necə seçim etdiyimizi söyləmək istəyirəm. Onların müsbət və mənfi cəhətlərini nəzərdən keçirin.
Eksiler
Flyway yalnız bir tərəfə gedir, biz geri dönə bilmərik əhəmiyyətli çatışmazlıqdır. Entity Framework Core ilə başqa yollarla müqayisə edə bilərsiniz - tərtibatçının rahatlığı baxımından. Xatırlayırsınız ki, biz bunu ön plana qoymuşuq və əsas meyar Windows inkişafı üçün heç nəyi dəyişməmək idi.
Uçuş yolu bizim üçün bir növ sarğı lazımdırki, uşaqlar yazmasınlar SQL sorğuları. Onlar OOP baxımından işləməyə daha yaxındırlar. Verilənlər bazası obyektləri ilə işləmək üçün təlimatlar yazdıq, SQL sorğusunu formalaşdırdıq və icra etdik. Verilənlər bazasının yeni versiyası hazırdır, yuvarlanır - hər şey yaxşıdır, hər şey işləyir.
Entity Framework Core-un mənfi cəhətləri var - ağır yüklər altında qeyri-optimal SQL sorğuları qurur, və verilənlər bazasında azalma əhəmiyyətli ola bilər. Amma yüksək yüklənmiş xidmətimiz olmadığı üçün yüzlərlə RPS-də yükü hesablamırıq, bu riskləri qəbul edib problemi gələcəyimizə həvalə etdik.
Pros
Entity Framework Core qutudan kənarda işləyir və inkişaf etdirmək asandır, və Flyway asanlıqla mövcud CI-yə inteqrasiya olunur. Amma biz bunu tərtibatçılar üçün rahat edirik :)
Roll-on proseduru
Kukla paketlərin versiyasında dəyişikliyin gəldiyini görür, bunlar arasında miqrasiyadan məsul olan da var. Birincisi, o, miqrasiya skriptlərini və verilənlər bazası ilə əlaqəli funksiyaları ehtiva edən bir paket quraşdırır. Bundan sonra verilənlər bazası ilə işləyən proqram yenidən işə salınır. Sonra qalan komponentlərin quraşdırılması gəlir. Paketlərin quraşdırılması və tətbiqlərin işə salınma sırası Kukla manifestində təsvir edilmişdir.
Tətbiqlər tokenlər, verilənlər bazası parolları kimi həssas məlumatlardan istifadə edir, bütün bunlar Kukla ustasından konfiqurasiyaya çəkilir, burada şifrələnmiş formada saxlanılır.
TFS Problemləri
Qərara gəldik və hər şeyin həqiqətən bizim üçün işlədiyini başa düşdükdən sonra, digər layihələrdə Win inkişaf şöbəsi üçün ümumiyyətlə TFS-dəki məclislərdə nə baş verdiyini görmək qərarına gəldim - tez getməyimiz / buraxmağımızdan asılı olmayaraq və əhəmiyyətli problemlər tapdıq. sürət.
Əsas layihələrdən biri 12-15 dəqiqəyə gedir - bu uzun müddətdir, belə yaşaya bilməzsən. Sürətli təhlil I / O-da dəhşətli bir azalma göstərdi və bu massivlərdədir.
Komponent-komponenti təhlil etdikdən sonra üç ocaq müəyyən etdim. Birinci - kaspersky antivirus, bütün Windows Build agentlərində mənbələri skan edir. İkinci - Windows indeksləşdirici. O, söndürülmədi və yerləşdirmə prosesi zamanı hər şey real vaxtda Build agentlərində indeksləşdirildi.
üçüncü - npm quraşdırın. Məlum oldu ki, əksər boru kəmərlərində biz bu ssenaridən istifadə etmişik. O niyə pisdir? Npm quraşdırma proseduru asılılıq ağacını qurarkən icra olunur package-lock.json, burada layihənin qurulması üçün istifadə ediləcək paketlərin versiyaları sabitdir. İşin mənfi tərəfi odur ki, Npm install hər dəfə paketlərin ən son versiyalarını İnternetdən çıxarır və bu, böyük bir layihə üçün çox vaxt tələb edir.
Tərtibatçılar bəzən müəyyən bir hissənin və ya bütöv bir layihənin performansını yoxlamaq üçün yerli maşın üzərində təcrübə aparırlar. Bəzən yerli olaraq hər şeyin sərin olduğu ortaya çıxdı, amma onu topladılar, yuvarladılar - heç nə alınmadı. Problemin nə olduğunu anlamağa başlayırıq - bəli, asılılıqları olan paketlərin müxtəlif versiyaları.
qərar
- AV istisnalarındakı mənbələr.
- İndeksləşdirməni söndürün.
- Keçid npm ci.
Npm ci-nin üstünlüyü ondan ibarətdir ki, biz asılılıq ağacını bir dəfə toplayın, və biz tərtibatçı təmin etmək imkanı əldə edirik paketlərin ən son siyahısı, bununla o, istədiyi qədər yerli təcrübə edə bilər. Bu vaxta qənaət edir kodu yazan tərtibatçılar.
Konfiqurasiya
İndi depo konfiqurasiyası haqqında bir az. Tarixən istifadə etmişik Nexus o cümlədən depoları idarə etmək Daxili REPO. Bu daxili depo daxili məqsədlər üçün istifadə etdiyimiz bütün komponentlərlə, məsələn, öz-özünə yazılmış monitorinqlə birlikdə gəlir.
Biz də istifadə edirik NuGet, çünki o, digər paket menecerlərindən daha yaxşı yaddaş saxlayır.
Nəticə
Quraşdırma agentlərini optimallaşdırdıqdan sonra orta qurma müddəti 12 dəqiqədən 7-yə endirildi.
Windows üçün istifadə edə bildiyimiz, lakin bu layihədə Linux-a keçdiyimiz bütün maşınları hesablasaq, təxminən 10 dollar qənaət etmişik.Və bu, yalnız lisenziyalarda, məzmunu əlavə etsəniz, daha çox.
Planlar
Növbəti rüb üçün kodun çatdırılmasını optimallaşdırmaq üzərində işləməyi planlaşdırdıq.
Əvvəlcədən qurulmuş Docker şəklinə keçid. TFS, məsələn, Docker təsviri kimi trigger üzərində qurmaq da daxil olmaqla, Pipeline-a inteqrasiya etməyə imkan verən bir çox plaginləri olan gözəl bir şeydir. Biz də bu tətiyi eyni şəkildə etmək istəyirik package-lock.json. Layihəni qurmaq üçün istifadə olunan komponentlərin tərkibi bir şəkildə dəyişirsə, biz yeni Docker şəklini qururuq. Daha sonra qurulmuş proqram ilə konteyneri yerləşdirmək üçün istifadə olunur. İndi belə deyil, lakin şirkətimizdə aktiv şəkildə inkişaf edən və uzun müddətdir istehsal həllərinə xidmət göstərən Kubernetes-də mikroservis arxitekturasına keçməyi planlaşdırırıq.
Xülasə
Mən hamını Windows-u atmağa çağırıram, amma bu, onu bişirə bilmədiyim üçün deyil. Səbəb, Opensource həllərinin əksəriyyətinin olmasıdır Linux yığını. Yaxşısan resurslara qənaət edin. Fikrimcə, gələcək güclü icma ilə Linux-da Açıq Mənbə həllərinə aiddir.
Spiker Profili Alexander Sinchinov .
peşəkarlardan peşəkarlar üçün inkişaf, sınaq və əməliyyat proseslərinin inteqrasiyası üzrə konfransdır. Buna görə İsgəndərin danışdığı layihə? həyata keçirilir və işləyir və tamaşanın keçirildiyi gün iki uğurlu buraxılış hazırlanıb. Aktiv Mayın 27 və 28-də praktikantlardan belə hallar daha çox olacaq. Siz hələ də son avtomobilə atlaya bilərsiniz və ya da tələsmə bilet. Skolkovoda görüşənədək!
Mənbə: www.habr.com