Ötənilki konfransda Banki.ru portalının əməliyyat direktoru Andrey Nikolski çıxış edib yetim xidmətləri haqqında: infrastrukturda yetim uşağı necə müəyyən etmək olar, yetim xidmətləri niyə pisdir, onlarla nə etməli və heç bir şey kömək etmədikdə nə etməli.
Kesimin altında hesabatın mətn versiyası var.
Salam həmkarlar! Mənim adım Andrey, Banki.ru-da əməliyyatları idarə edirəm.
Bizdə böyük xidmətlər var, bunlar belə monolit xidmətlərdir, daha klassik mənada xidmətlər var, çox kiçik olanlar var. Fəhlə-kəndli terminologiyamda deyirəm ki, əgər xidmət sadə və kiçikdirsə, o, mikro, çox sadə və kiçik deyilsə, sadəcə bir xidmətdir.
Xidmətlərin peşəkarları
Mən tez bir zamanda xidmətlərin üstünlüklərini nəzərdən keçirəcəyəm.
Birincisi miqyasdır. Siz tez bir zamanda xidmətdə nəsə düzəldə və istehsala başlaya bilərsiniz. Trafik aldınız, xidməti klonladınız. Daha çox trafik gəldi, siz klonlaşdırdınız və onunla yaşayırsınız. Bu, yaxşı bir bonusdur və prinsipcə, biz işə başlayanda bizim üçün ən vacib hesab olunurdu, niyə bütün bunları ümumiyyətlə edirik.
İkincisi, təcrid olunmuş inkişaf, bir neçə inkişaf komandanız olduqda, hər komandada bir neçə fərqli tərtibatçı və hər bir komanda bir növ xidmət üzərində işləyir.
Əmrlərlə bir nüans var. Tərtibatçılar fərqlidir. Və var, məsələn, . Mən bunu ilk dəfə Maksim Dorofeyevdə görmüşəm. Bəzən qar dənəciyi bəzi komandalarda olur, bəziləri isə yox. Bu, şirkətdə istifadə olunan müxtəlif xidmətləri bir qədər qeyri-bərabər edir.
Şəkilə baxın: bu yaxşı tərtibatçıdır, böyük əlləri var, çox şey edə bilər. Əsas problem bu əllərin haradan böyüməsidir.
Xidmətlər müxtəlif tapşırıqlar üçün daha uyğun olan müxtəlif proqramlaşdırma dillərindən istifadə etməyə imkan verir. Bəzi xidmətlər Go-da, bəziləri Erlanqda, bəziləri Ruby-də, bəziləri PHP-də, bəziləri Python-da. Ümumiyyətlə, çox geniş şəkildə dönə bilərsiniz. Burada da nüanslar var.
Xidmət yönümlü arxitektura ilk növbədə devoplara aiddir. Yəni avtomatlaşdırma yoxdursa, yerləşdirmə prosesi yoxdur, əgər onu əl ilə qurursansa, konfiqurasiyaların xidmət instansiyasından instansiyaya dəyişə bilər və nəsə etmək üçün ora getməlisən, deməli cəhənnəmdəsən.
Məsələn, 20 xidmətiniz var və əl ilə yerləşdirməlisiniz, 20 konsolunuz var və ninja kimi eyni anda enter düyməsini basırsınız. Çox yaxşı deyil.
Əgər testdən sonra bir xidmətiniz varsa (təbii ki, test varsa) və hələ də istehsalda işləməsi üçün bir fayl ilə bitirmək lazımdırsa, sizə pis xəbərim də var.
Əgər siz konkret Amazon xidmətlərinə güvənirsinizsə və Rusiyada işləyirsinizsə, onda iki ay əvvəl sizdə də “Hər şey yanır, mən yaxşıyam, hər şey sərindir”.
Biz yerləşdirmənin avtomatlaşdırılması üçün Ansible, konvergensiya üçün Kukla, yerləşdirmə avtomatlaşdırılması üçün Bamboo, hamısını bir şəkildə təsvir etmək üçün Confluence istifadə edirik.
Mən bu barədə ətraflı danışmayacağam, çünki hesabat daha çox qarşılıqlı fəaliyyət təcrübələri haqqındadır, nəinki texniki icra.
Məsələn, serverdəki Puppet proqramının Ruby 2 ilə işləməsi və bəzi proqramların Ruby 1.8 altında yazılması ilə bağlı problemlərimiz var və onlar birlikdə işləmir. Bir növ səhv gedir. Ruby-nin bir neçə versiyasını eyni maşında saxlamaq lazım olduqda, adətən problemlərlə üzləşirsiniz.
Məsələn, biz hər bir tərtibatçıya əlimizdə olan hər şeyə, inkişaf etdirilə bilən bütün xidmətlərə malik platforma veririk ki, onun təcrid olunmuş mühiti olsun, onu sındırıb istədiyi kimi qura bilsin.
Bəzən, orada bir şey üçün dəstək olan bəzi xüsusi tərtib edilmiş paketə ehtiyacınız var. Kifayət qədər sərtdir. Docker şəklinin 45 GB ağırlığında olduğu bir hesabata qulaq asdım. Linux-da, əlbəttə ki, daha sadədir, orada hər şey daha kiçikdir, amma yenə də kifayət qədər yer olmayacaq.
Yaxşı, ziddiyyətli asılılıqlar var, layihənin bir parçası olduqda, bir versiyanın kitabxanasından, layihənin başqa bir hissəsi başqa bir versiyadan asılıdır və kitabxanalar ümumiyyətlə birləşdirilmir.
PHP 5.6-da saytlarımız və xidmətlərimiz var, onlardan utanırıq, amma nə edək. Bu, bizim tək platformamızdır. PHP 7-də saytlar və xidmətlər var, onlardan daha çoxu var, biz onlardan utanmırıq. Və hər bir tərtibatçının xoşbəxtliklə gördüyü öz bazası var.
Bir şirkətdə bir dildə yazsanız, hər bir tərtibatçıya üç virtual maşın normal səslənir. Fərqli proqramlaşdırma dilləriniz varsa, vəziyyət daha da pisləşir.
Bununla bağlı saytlarınız və xidmətləriniz var, bu barədə, sonra Go üçün başqa bir sayt, Ruby üçün bir sayt, yan tərəfdə bir az daha Redis. Nəticədə, bütün bunlar dəstək üçün böyük bir sahəyə çevrilir və hər zaman bundan bir şey qıra bilər.
Buna görə də, biz proqramlaşdırma dilinin yaxşı cəhətlərini fərqli çərçivələrin istifadəsi ilə əvəz etdik, çünki PHP çərçivələri tamamilə fərqli olduğundan, fərqli imkanlara, fərqli icmalara, fərqli dəstəyə malikdirlər. Və bir xidmət yaza bilərsiniz ki, artıq buna hazır bir şeyiniz var.
Hər bir xidmətin öz komandası var
Bir neçə il ərzində kristallaşan əsas üstünlüyümüz hər bir xidmətin öz komandasının olmasıdır. Bu, böyük bir layihə üçün əlverişlidir, sənədləşməyə vaxta qənaət edə bilərsiniz, menecerlər öz layihələrini yaxşı bilirlər.
Dəstəkdən gələn tapşırıqlar mükəmməl şəkildə atıla bilər. Məsələn, sığorta xidməti sıradan çıxıb. Və dərhal sığorta ilə məşğul olan komanda onu təmir etməyə gedir.
Yeni funksiyalar tez hazırlanır, çünki bir növ atom xidmətiniz olduqda, ona nəyisə tez bir zamanda vura bilərsiniz.
Xidmətinizi pozduğunuzda və bu, qaçılmaz olaraq baş verəndə, başqalarının xidmətlərinə zərər verməmisiniz və digər komandaların bitləri olan tərtibatçılar sizə qaçaraq: "Ay-ay, bunu etmə."
Həmişə olduğu kimi, nüanslar var. Sabit komandalarımız var, menecerlər komandaya mıxlanıb. Aydın sənədlər var, idarəçilər bütün bunları diqqətlə izləyirlər. Meneceri olan hər bir komandanın bir neçə xidməti var və müəyyən bir səlahiyyət nöqtəsi var.
Əmrlər üzəndirsə (bunu bəzən biz də istifadə edirik), "ulduz xəritəsi" adlı yaxşı bir üsul var.
Sizdə xidmətlərin və insanların siyahısı var. Ulduz işarəsi insanın bu xidmətdə mütəxəssis olduğunu, kitab insanın bu xidməti öyrəndiyini bildirir. Bir insanın vəzifəsi kitabı ulduza dəyişdirməkdir. Xidmətin qarşısında heç bir şey yazılmırsa, danışmağa davam edəcəyim problemlər başlayır.
Yetim xidmətləri necə görünür?
Birinci problem, infrastrukturunuzda yetim xidməti almağın ilk yolu insanların işdən çıxarılmasıdır. Tapşırıqlar təxmin edilməzdən əvvəl bir işdən son tarixlərin gəldiyi zaman hər kəs təcrübə etdimi? Bəzən elə olur ki, son tarixlər sıx olur və sadəcə olaraq sənədlər üçün kifayət qədər vaxt olmur. "Xidməti istehsala təhvil verməliyik, sonra əlavə edəcəyik."
Komanda kiçikdirsə, hər şeyi yazan bir tərtibatçı var, qalanları qanadlardadır. "Mən əsas arxitekturanı yazdım, siz mənə interfeysləri verin." Sonra bir anda menecer, məsələn, ayrılır. Və bu müddətdə, menecer getdiyi və yenisi hələ təyin edilmədiyi zaman, tərtibatçılar özləri xidmətin hara hərəkət etdiyinə, orada nə baş verdiyinə qərar verirlər. Və bildiyimiz kimi (bir neçə slayddan geri qayıdaq), bəzi komandalarda qar dənəciyi olan insanlar var, bəzən bir komandada qar dənəciyi var. Sonra işdən çıxır, xidmət yetimini alırıq.
Eyni zamanda, dəstək və biznesdən gələn vəzifələr getmir, geridə qalırlar. Xidmətin inkişafı zamanı hər hansı memarlıq səhvləri varsa, onlar da geridə qalırlar. Xidmət yavaş-yavaş pisləşir.
Yetimi necə tanımaq olar?
Bu siyahı vəziyyəti yaxşı təsvir edir. Kimsə infrastruktur haqqında nəsə öyrənibmi?
Sənədləşdirilmiş iş yolları haqqında: bir xidmət var və ümumiyyətlə işləyir, onunla necə işləmək barədə iki səhifəlik təlimat var, amma içəridə heç kim onun necə işlədiyini bilmir.
Və ya, məsələn, bir növ link qısaldıcı var. Məsələn, hazırda müxtəlif xidmətlərdə müxtəlif məqsədlər üçün istifadə edilən üç link qısaldıcımız var. Bunlar sadəcə nəticələrdir.
İndi mən aşkar olanın kapitanı olacağam. Nə etmək lazımdır? Birincisi, xidməti başqa menecerə, başqa komandaya köçürməlisiniz. Əgər komanda rəhbəriniz hələ də işdən çıxmayıbsa, o zaman xidmətin yetim kimi olduğunu başa düşdüyünüz zaman, bu digər komandaya bu barədə heç olmasa bir şey anlayan birini daxil etməlisiniz.
Əsas odur ki, qanla yazılmış köçürmə prosedurları olmalıdır. Bizim vəziyyətimizdə adətən buna əməl edirəm, çünki işləmək üçün mənə lazımdır. Menecerlərə onu tez təhvil vermək lazımdır və sonradan nə olacağı onlar üçün o qədər də önəmli deyil.
Yetim etmənin növbəti yolu “Gəlin bunu autsorsing edək, daha sürətli olacaq, sonra onu komandaya köçürəcəyik”. Aydın məsələdir ki, hər kəsin komandada hansısa planları var, dön. Çox vaxt işgüzar müştəri hesab edir ki, autsorser şirkətin texniki şöbəsi ilə eyni şeyi edəcək. Baxmayaraq ki, onların motivasiyası fərqlidir. Outsorsinqdə qəribə texnoloji həllər və qəribə alqoritmik həllər var.
Məsələn, müxtəlif gözlənilməz yerlərdə Sfenks olan bir xidmətimiz var idi. Nə etməli olduğumu sonra deyəcəyəm.
Xarici şirkətlərin öz-özünə yazılmış çərçivələri var. Bu, hər şeyi tapa biləcəyiniz əvvəlki layihədən kopyalanıb yapışdırılmış sadə PHP-dir. Bu yerləşdirmə skriptləri bəzi üçüncü skript tərəfindən çağırıldığı halda, bəzi mürəkkəb Bash skriptləri ilə bəzi faylda bir neçə sətir dəyişdirmək lazım olduqda, yerləşdirmə skriptlərində böyük qoltuqaltılar. Nəticədə siz yerləşdirmə sistemini dəyişdirirsiniz, başqa bir şey seçirsiniz, hoppanırsınız, lakin xidmət sizin üçün işləmir. Çünki orada müxtəlif atalar arasında daha 8 əlaqə qoymaq lazım idi. Yaxud elə olur ki, min yazı işləyir, amma yüz mini artıq yoxdur.
Mən kapitanlığa davam edəcəyəm. Outsorsinqdən xidmətin qəbulu məcburi prosedurdur. Xarici xidmətin gəldiyini, lakin heç bir yerdə qəbul edilmədiyini kim yaşayıb? Bu, əlbəttə ki, yetimlərə xidmət kimi populyar deyil, amma yenə də.
Xidmət yoxlanılmalıdır, xidmət nəzərdən keçirilməlidir, parollar dəyişdirilməlidir. Bizdə belə bir hal olmuşdu ki, bizə bir xidmət atıldı, orada “giriş == 'admin' && parol == 'admin'…” admin paneli var, bu kodda düz yazılıb. Oturub fikirləşirik və insanlar bunu 2018-ci ildə yazır?
Saxlama həcmini yoxlamaq da zəruri bir şeydir. Bu xidməti bir yerə istehsal etməzdən əvvəl, yüz min qeyddə nə baş verəcəyinə baxmaq lazımdır.
Xidməti yenidən nəzərdən keçirmək üçün göndərmək ayıb olmamalıdır. “Biz bu xidməti qəbul etməyəcəyik, 20 vəzifəmiz var, onları yerinə yetirin, sonra qəbul edəcəyik” deyəndə, bu normaldır. Menecer qurmağınıza və ya bir işin pul xərcləməsinə vicdan zərər verməməlidir. Biznes daha çox xərcləyəcək.
Pilot layihəni autsorsing etmək qərarına gəldiyimiz bir halımız oldu.
Vaxtında təhvil verildi və bu, yeganə keyfiyyət meyarı idi. Ona görə də biz daha bir pilot layihə həyata keçirdik, hətta pilot layihəni belə etdik. Bu xidmətləri qəbul etdilər, inzibati yollarla dedilər, bura sənin kodun, bax, komandan, menecerin budur. Xidmətlər artıq qazanc əldə etməyə başlayıb. Eyni zamanda, əslində onlar hələ də yetimdirlər, onların necə işlədiyini heç kim başa düşmür və menecerlər hər cür şəkildə onların tapşırıqlarını inkar edirlər.
Başqa bir böyük konsepsiya var - partizan inkişafı. Bəzi şöbə, bir qayda olaraq, marketinq şöbəsi olduqda, onlar bir fərziyyəni yoxlamaq və tamamilə kənardan bir xidmət sifariş etmək istəyirlər. Oraya maşınlar axışmağa başlayır, sənədləri bağlayırlar, podratçı ilə akt imzalayırlar, işə düşürlər və deyirlər: “Aylar, bizim burada xidmətimiz var, artıq trafik var, bizə pul gətirir, qəbul edək”. Biz “Oppa, necə olur” deyirik.
Və yetim xidmətini əldə etməyin daha bir yolu: hansısa komanda birdən yükləndiyi üzə çıxanda rəhbərlik deyir: “Gəlin bu komandanın xidmətini başqa komandaya keçirək, onun daha az yükü var”. Sonra onu üçüncü komandaya keçirib, meneceri dəyişəcəyik. Və sonda yenə bir yetimimiz var.
Yetimlərin problemi nədir?
Kim bilmir, bu, İsveçdə yetişdirilmiş Wasa döyüş gəmisidir, suya atıldıqdan 5 dəqiqə sonra boğulması ilə məşhurdur. İsveç kralı, yeri gəlmişkən, buna görə heç kimi edam etmədi. Onu bu cür gəmilərin necə qurulacağını bilməyən iki nəsil mühəndislər tikiblər. Daimi təsir.
Gəmi, yeri gəlmişkən, daha da pisləşə bilərdi, məsələn, padşah artıq fırtınada haradasa onun üzərinə minəndə. Beləliklə, o, dərhal boğuldu, çevikliyə görə, erkən uğursuz olmaq yaxşıdır.
Erkən uğursuz olsaq, adətən problem olmur. Məsələn, qəbul zamanı onlar təftiş üçün göndəriliblər. Əgər biz pul yatırılanda istehsalda uğursuzluğa düçar olmuşuqsa, o zaman problemlər yarana bilər. Nəticələr, biznesdə deyildiyi kimi.
Yetim xidmətləri niyə təhlükəlidir:
- Xidmət qəfil pozula bilər.
- Xidmət uzun müddətdir təmir olunur və ya heç təmir edilmir.
- Təhlükəsizlik problemləri.
- Təkmilləşdirmələr və yeniləmələrlə bağlı problemlər.
- Vacib bir xidmət xarab olarsa, şirkətin reputasiyası zədələnir.
Yetim xidmətləri ilə nə etmək lazımdır?
Nə edəcəyimi bir daha təkrar edirəm. Birincisi, sənədlər olmalıdır. Banki.ru-da 7 il mənə öyrətdi ki, testerlər tərtibatçıların sözünü, əməliyyat isə hər kəsin sözünü qəbul etməməlidir. Yoxlamalıyıq.
İkincisi, qarşılıqlı əlaqə diaqramlarını yazmalısınız, çünki yaxşı qəbul edilməyən xidmətlərdə heç kimin demədiyi asılılıqlar olur. Məsələn, tərtibatçılar xidməti bəzi Yandex.Maps və ya Dadata açarlarına qoyurlar. Sərbəst limitiniz bitdi, hər şey pozuldu və nə baş verdiyini heç bilmirsiniz. Bütün bu cür tırmıklar təsvir edilməlidir: xidmət Dadata, Sms, başqa bir şey istifadə edir.
Üçüncüsü, texniki borcla işləmək. Bir növ qoltuq dəyənəyi düzəldəndə və ya bir xidməti qəbul edərkən və bir şey etmək lazım olduğunu söyləyərkən, onların bunu etdiyinə əmin olmalısınız. Çünki o zaman belə çıxa bilər ki, balaca dəlik elə də kiçik deyil və siz ora düşəcəksiniz.
Memarlıq tapşırıqları ilə Sfenks haqqında bir hekayəmiz var idi. Xidmətlərdən birində Sfenks siyahıları daxil etmək üçün istifadə olunurdu. Sadəcə səhifələmə ilə siyahı, lakin hər gecə yenidən indeksləşdirilirdi. O, iki indeksdən yığılırdı: biri hər gecə böyük bir indekslə indekslənirdi və ona əlavə edilmiş kiçik bir indeks də var idi. Hər gün 50% ehtimalla ya bombardman olub-olmamasına baxmayaraq, indeks hesablama zamanı mübarizə apardı və xəbərlər əsas səhifəmizdə yenilənməyi dayandırdı. İndeks yenidən indeksləşdirilərkən əvvəlcə 5 dəqiqə idi, sonra indeks böyüdü və bir anda 40 dəqiqə yenidən indeksləşdirməyə başladı. Bunu görəndə rahat bir nəfəs aldıq, çünki bir az daha vaxt keçəcəyi və indeksimiz tam zamanlı olaraq yenidən indeksləşdiriləcəyi aydın idi. Bu, portalımız üçün uğursuz olacaq, səkkiz saat xəbər yoxdur - bu qədər, iş yüksəldi.
Yetimlərə Xidmət Planı
Əslində bunu etmək çox çətindir, çünki devops ünsiyyətdən ibarətdir. Siz həmkarlarınızla yaxşı münasibətdə olmaq istəyirsiniz və siz həmkarlarınız və menecerlərin başına nizamnamələrlə vurduğunuzda, onlar bunu edən insanlara qarşı ziddiyyətli hisslər yaşaya bilərlər.
Bütün bu məqamlara əlavə olaraq, başqa bir vacib şey var: hər bir xüsusi xidmətə, yerləşdirmə prosedurunun hər bir xüsusi bölməsinə görə konkret insanlar məsuliyyət daşımalıdır. İnsanlar olmadıqda və başqa insanları cəlb etməli olduqda, hər şeyi öyrənmək çətinləşir.
Bütün bunlar kömək etməyibsə və yetim xidmətiniz hələ də yetimdirsə, heç kim onu özünə götürmək istəmirsə, sənədləşmə yazılmayıbsa, bu xidmətə çağırılan komanda nəsə etməkdən imtina edir, sadə bir yol var - hər şeyi yenidən etmək.
Yəni, siz yenidən xidmətə olan tələbləri götürürsünüz və qəribə texnoloji həllər olmadan yeni, daha yaxşı, daha yaxşı platformada bir xidmət yazırsınız. Və döyüşdə ona hicrət edin.
Yii 1-də bir xidmət götürdükdə və Yii 1-də yaxşı yaza bilən developerlərimiz tükəndiyi üçün onu daha da inkişaf etdirə bilməyəcəyimizi başa düşdük. Bütün tərtibatçılar üçüncü Symfony-də yaxşı yazır. Nə etməli? Vaxt ayırdıq, komanda ayırdıq, menecer ayırdıq, layihəni yenidən yazdıq və rəvan şəkildə trafiki ona keçirdik.
Bundan sonra köhnə xidmət silinə bilər. Bu, konfiqurasiya idarəetmə sistemindən bəzi xidmətlər götürmək və təmizləmək və sonra tərtibatçıların heç bir iz buraxmaması üçün bütün istehsal avtomobillərinin ləğv edildiyini görmək üçün keçməli olduğunuz zaman mənim sevimli prosedurumdur. Gitdəki repozitoriya qalır.
Danışmaq istədiyim bu idi, müzakirə etməyə hazıram, mövzu qaynar, çoxları onun içində üzdü.
Slaydlar dilləri birləşdirdiyinizdən bəhs edirdi. Bir nümunə şəklin ölçüsünü dəyişdirmək idi. Həqiqətən bir dilə qədər ciddi olmaq lazımdırmı? Çünki PHP-də təsvirin ölçüsünü dəyişdirmək, həqiqətən də, Golang-da edilə bilər.
Əslində, bütün təcrübələr kimi isteğe bağlıdır. Bəlkə də bəzi hallarda arzuolunmazdır. Ancaq başa düşmək lazımdır ki, şirkətinizdə texniki şöbədə 50 nəfər varsa, onlardan 45-i PHP mütəxəssisi, daha 3-ü Python, Ansible, Puppet və buna bənzər bir şeydən istifadə edə bilən devoplardır və onlardan yalnız biri yazır. bəzi Go image ölçüsünü dəyişdirmə xidməti, sonra ayrıldıqda, ekspertiza onunla birlikdə ayrılır. Və bunu edərkən, bu dili bilən, xüsusən də nadir hallarda, bazara xas bir tərtibatçı axtarmalı olacaqsınız. Yəni təşkilati baxımdan problemlidir. Devops nöqteyi-nəzərindən, xidmətləri yerləşdirmək üçün istifadə etdiyiniz bəzi hazır oyun kitablarını klonlaşdırmaqla kifayətlənməyəcəksiniz, həm də onları yenidən yazmalı olacaqsınız.
Biz indi Node.js-də bir xidmət görürük və bu, hər bir tərtibatçı üçün ayrıca dilə malik yaxınlıqdakı platforma olacaq. Amma biz oturub fikirləşdik ki, oyun şama dəyər. Yəni burada sual oturub düşünməkdir.
Xidmətlərinizə necə nəzarət edirsiniz? Qeydləri necə toplayır və izləyirsiniz?
Elasticsearch-də logları toplayıb Kibana qoyuruq və istehsal və ya sınaq mühitindən asılı olaraq orada müxtəlif kollektorlardan istifadə olunur. Bir yerdə Odunçu, başqa yerdə, xatırlamıram. Müəyyən xidmətlərdə daha bir neçə yer var ki, biz Teleqrafı quraşdırırıq və ayrı yerdə başqa yerdə çəkirik.
Puppet və Ansible ilə eyni mühitdə necə yaşamaq olar?
Əslində, indi iki mühitimiz var, biri Kukla, digəri Ansible. Biz onların hibridləşdirilməsi üzərində işləyirik. Ansible ilkin quraşdırma üçün yaxşı mühitdir, Kukla ilkin quraşdırma üçün pis bir şeydir, çünki o, saytla birbaşa əl işi tələb edir və Kukla konfiqurasiya konvergensiyasını təmin edir. Bu o deməkdir ki, sayt özünü aktual saxlayır və ansible maşının yenilənməsi üçün siz hər zaman müəyyən bir tezlikdə oyun kitablarını işlətməlisiniz. Burada belə bir fərq var.
Uyğunluğu necə qoruyursunuz? Həm Ansible, həm də Kuklada konfiqurasiyalarınız varmı?
Bu bizim böyük ağrımızdır, biz əllərimizlə uyğunluğu dəstəkləyirik və bütün bunlardan indi harasa necə keçəcəyimizi düşünürük. Məlum oldu ki, Kukla paketləri yuvarlayır və orada bəzi bağlantıları saxlayır və məsələn, Ansible kodu yuvarlayır və orada təzə tətbiq konfiqurasiyalarını düzəldir.
Təqdimat Ruby-nin müxtəlif versiyaları haqqında idi. Hansı həll yolu?
Biz bununla bir yerdə qarşılaşdıq və bunu hər zaman ağlımızda saxlamalıyıq. Biz sadəcə olaraq Ruby-də işləyən və tətbiqlərlə uyğun gəlməyən hissəni söndürdük və onu ayrı saxladıq.
Builki konfrans dekabrın 7-də Texnopolisdə keçiriləcək. Noyabrın 11-dək hesabatlar üçün müraciətləri qəbul edirik. danışmaq istəsəniz bizə.
İştirakçılar üçün qeydiyyat açıqdır, bizə qoşulun!
Mənbə: www.habr.com