Banki.ru порталынын операциялар боюнча директору Андрей Никольский былтыркы конференцияда сөз сүйлөдү жетимдерге кызмат көрсөтүү жөнүндө: инфраструктурада жетим баланы кантип аныктоо керек, жетимдик кызмат эмне үчүн начар, алар менен эмне кылуу керек жана эч нерсе жардам бербесе эмне кылуу керек.
Кесилген ылдыйда отчеттун тексттик версиясы бар.
Салам кесиптештер! Менин атым Андрей, мен Banki.ru сайтында операцияларды жетектейм.
Бизде чоң кызматтар бар, бул ушундай монолиттүү кызматтар, классикалык мааниде кызмат көрсөтүүлөр бар, өтө кичинекейлери бар. Жумушчу-дыйкан терминологиямда, эгерде кызмат жөнөкөй жана кичине болсо, анда ал микро, ал эми өтө жөнөкөй жана кичине болбосо, анда бул жөн эле кызмат деп айтам.
Кызматтардын жакшы жактары
Мен тез арада кызматтардын артыкчылыктарын карап чыгам.
Биринчиси - масштабдоо. Тез арада кызмат боюнча бир нерсе кылып, өндүрүштү баштасаңыз болот. Сиз трафикти алдыңыз, кызматты клондуңуз. Сизде көбүрөөк трафик бар, сиз аны клондуңуз жана аны менен жашайсыз. Бул жакшы бонус жана, негизи, биз баштаганда, биз мунун баарын эмне үчүн жасап жатканыбыз эң маанилүү деп эсептелген.
Экинчиден, обочолонгон өнүгүү, сизде бир нече иштеп чыгуучу командалар болгондо, ар бир командада бир нече түрдүү иштеп чыгуучулар жана ар бир команда өзүнүн кызматын иштеп чыгат.
Командалар менен бир нюанс бар. Иштеп чыгуучулар ар кандай. Жана бар, мисалы, . Мен муну биринчи жолу Максим Дорофеевден көрдүм. Кээде кар бүртүкчөлөрү кээ бир командаларда болуп, башкаларында эмес. Бул компания боюнча колдонулган ар кандай кызматтарды бир аз бирдей эмес кылат.
Сүрөттү караңыз: бул жакшы иштеп чыгуучу, анын колу чоң, ал көп нерсени жасай алат. Эң негизги маселе бул колдордун кайдан келгенинде.
Кызматтар ар кандай тапшырмалар үчүн ылайыктуу болгон ар кандай программалоо тилдерин колдонууга мүмкүндүк берет. Кээ бир кызматтар Go'до, кээ бирлери Эрлангта, кээ бирлери Rubyде, бир нерсе PHPде, бир нерсе Pythonдо. Жалпысынан алганда, сиз абдан кеңири жайыла аласыз. Бул жерде да нюанстар бар.
Кызматка багытталган архитектура биринчи кезекте devops жөнүндө. Башкача айтканда, эгер сизде автоматизация жок болсо, жайылтуу процесси жок, эгер сиз аны кол менен конфигурацияласаңыз, конфигурацияларыңыз кызмат инстанциясынан инстанцияга өзгөрүшү мүмкүн жана бир нерсе кылуу үчүн ал жакка барышыңыз керек, анда сиз тозоктосуз.
Мисалы, сизде 20 кызмат бар жана сиз кол менен жайгаштырышыңыз керек, сизде 20 консол бар жана бир эле учурда ниндзя сыяктуу "enter" баскычын басыңыз. Бул абдан жакшы эмес.
Эгерде сизде тестирлөөдөн кийин кызматыңыз болсо (эгер тестирлөө болсо, албетте) жана сиз аны дагы эле өндүрүштө иштеши үчүн файл менен бүтүрүшүңүз керек болсо, менде дагы сизге жаман жаңылык бар.
Эгер сиз белгилүү Amazon кызматтарына таянсаңыз жана Орусияда иштесеңиз, анда эки ай мурун сизде "Айлананын баары күйүп жатат, мен жакшымын, баары сонун".
Биз жайылтууну автоматташтыруу үчүн Ansible, конвергенция үчүн куурчак, жайылтууну автоматташтыруу үчүн бамбук жана баарын сүрөттөп берүү үчүн Confluence колдонобуз.
Мен бул жөнүндө майда-чүйдөсүнө чейин токтолбойм, анткени отчетто техникалык ишке ашыруу эмес, өз ара аракеттенүү практикасы көбүрөөк.
Мисалы, сервердеги куурчак Ruby 2 менен иштегенде бизде көйгөйлөр болду, бирок кээ бир тиркемелер Ruby 1.8 үчүн жазылган жана алар чогуу иштебейт. Ал жерде бир нерсе туура эмес болуп жатат. Жана сиз Rubyдин бир нече версиясын бир машинада иштетишиңиз керек болгондо, адатта сизде көйгөйлөр жарала баштайт.
Мисалы, биз ар бир иштеп чыгуучуга платформаны беребиз, анда бизде бардын бардыгы, иштеп чыгууга мүмкүн болгон бардык кызматтар бар, ал обочолонгон чөйрөгө ээ, ал аны бузуп, каалагандай кура алат.
Ал жерде кандайдыр бир нерсени колдоо менен атайын түзүлгөн пакет керек болот. Бул абдан катаал. Мен Докер сүрөтүнүн салмагы 45 ГБ болгон отчетту уктум. Linuxта, албетте, жөнөкөй, ал жерде баары кичине, бирок дагы эле орун жетишсиз болот.
Ооба, карама-каршы көз карандылыктар бар, эгерде долбоордун бир бөлүгү бир версиянын китепканасынан көз каранды болсо, долбоордун башка бөлүгү башка версиядан көз каранды жана китепканалар такыр эле чогуу орнотулбайт.
Бизде PHP 5.6да сайттар жана кызматтар бар, биз алардан уялабыз, бирок эмне кылсак болот? Бул биздин бир сайт. PHP 7де сайттар жана сервистер бар, алар дагы көп, биз алардан уялбайбыз. Жана ар бир иштеп чыгуучунун өзүнүн базасы бар, ал жерде ал бактылуу арааланат.
Эгер сиз компанияда бир тилде жазсаңыз, анда бир иштеп чыгуучуга үч виртуалдык машина нормалдуу угулат. Эгерде сизде ар кандай программалоо тилдери бар болсо, анда абал ого бетер начарлайт.
Сизде бул боюнча сайттар жана кызматтар бар, бул боюнча, андан кийин Go үчүн дагы бир сайт, Ruby үчүн бир сайт жана тарапта башка Redis. Натыйжада, мунун баары колдоо үчүн чоң талаага айланат жана ар дайым анын бир бөлүгү сынып калышы мүмкүн.
Ошондуктан, биз программалоо тилинин артыкчылыктарын ар кандай алкактарды колдонуу менен алмаштырдык, анткени PHP алкактары такыр башкача, алардын мүмкүнчүлүктөрү ар түрдүү, жамааттар жана ар кандай колдоо бар. Жана сиз буга чейин бир нерсе даяр болушу үчүн кызмат жаза аласыз.
Ар бир кызматтын өзүнүн командасы бар
Бир нече жылдан бери кристаллдашкан биздин негизги артыкчылыгыбыз – ар бир кызматтын өзүнүн командасы бар. Бул чоң долбоор үчүн ыңгайлуу, документацияга убакытты үнөмдөөгө болот, менеджерлер өз долбоорун жакшы билишет.
Колдоо кызматынан тапшырмаларды оңой тапшыра аласыз. Мисалы, камсыздандыруу кызматы иштебей калды. Ошол замат камсыздандыруу менен алектенген топ аны оңдоого барат.
Жаңы функциялар тез түзүлүүдө, анткени сизде бир атомдук кызмат болгондо, ага бир нерсени бат эле бура аласыз.
Кызматыңызды үзгөндө жана бул сөзсүз түрдө болот, сиз башкалардын кызматтарына таасир эткен жоксуз жана башка командалардын иштеп чыгуучулары сизге чуркап келип: "Ай-ий, андай кылба" деп айтышпайт.
Адаттагыдай эле, нюанстар бар. Бизде туруктуу командалар бар, командага менеджерлер кадалган. Так документтер бар, жетекчилер баарын тыкыр көзөмөлдөп турушат. Менеджери бар ар бир команданын бир нече кызматтары бар жана белгилүү бир компетенттүүлүк бар.
Эгерде командалар калкып жүрсө (биз да кээде муну колдонобуз), "жылдыз картасы" деген жакшы ыкма бар.
Сизде кызматтардын жана адамдардын тизмеси бар. Жылдызча адамдын бул кызматтын адиси экенин, китеп деген адам бул кызматты окуп жатканын билдирет. Адамдын милдети китепчени жылдызчага алмаштыруу. Кызматтын алдында эч нерсе жазылбаса, анда мен андан ары сүйлөшө турган көйгөйлөр башталат.
Жетим кызматтар кантип пайда болот?
Биринчи көйгөй, сиздин инфраструктураңызда жетим кызматты алуунун биринчи жолу - адамдарды жумуштан кетирүү. Тапшырмалар бааланганга чейин кимдир бирөө бизнестин мөөнөттөрүн аткарды беле? Кээде мөөнөтү тар болуп, документтештирүү үчүн убакыт жетишсиз болуп калат. "Биз кызматты өндүрүшкө өткөрүп беришибиз керек, анан аны кошобуз."
Эгерде команда кичинекей болсо, анда бардыгын жазган бир иштеп чыгуучу бар, калгандары канатта. "Мен негизги архитектураны жаздым, интерфейстерди кошолу." Анан бир учурда менеджер, мисалы, кетип калат. Ал эми бул мезгилде, менеджер кетип, жаңысы дайындала элек болсо, иштеп чыгуучулар кызмат кайда кетип жатканын жана ал жерде эмне болуп жатканын өздөрү чечет. Ал эми биз билгендей (келгиле, бир нече слайдга кайрылалы), кээ бир командаларда кар бүртүкчөлөрү бар, кээде кар бүртүкчөлөрү командасын жетектейт. Анан ал жумуштан кетет, биз жетим кызматыбызды алабыз.
Ошол эле учурда, колдоо жана бизнестин милдеттери алар артта калууда жок эмес; Кызматты иштеп чыгууда кандайдыр бир архитектуралык каталар болсо, алар да артта калууда. Кызмат акырындык менен начарлап баратат.
Жетимди кантип аныктоого болот?
Бул тизме кырдаалды жакшы сүрөттөйт. Алардын инфраструктурасы жөнүндө ким билди?
Документтештирилген иш-аракеттер жөнүндө: кызмат бар жана жалпысынан ал иштейт, аны менен кантип иштөө керектиги боюнча эки барактан турган колдонмо бар, бирок анын ичинде кандай иштээрин эч ким билбейт.
Же, мисалы, шилтеме кыскартуучу кандайдыр бир бар. Мисалы, бизде учурда ар кандай кызматтарда ар кандай максаттарда колдонулуп жаткан үч шилтеме кыскарткычтар бар. Бул жөн гана кесепеттери.
Эми мен ачыктардын капитаны болом. Эмне кылуу керек? Биринчиден, кызматты башка менеджерге, башка командага өткөрүп беришибиз керек. Эгерде сиздин командаңыздын лидери али кете элек болсо, анда бул башка командада, кызмат жетимдей экенин түшүнгөндө, жок дегенде бир нерсени түшүнгөн адамды кошуу керек.
Эң негизгиси: которуу процедуралары кан менен жазылган болушу керек. Биздин учурда мен муну көбүнчө көзөмөлдөйм, анткени мага баары иштеши керек. Жетекчилерге аны тез жеткирүү керек жана кийинчерээк аны менен эмне болгону алар үчүн анчалык деле маанилүү эмес.
Жетим кылуунун кийинки жолу - "Биз муну аутсорсинг менен жасайбыз, ал тезирээк болот, анан аны командага өткөрүп беребиз". Ар кимдин коллективде кандайдыр бир пландары, кезеги бар экени анык. Көбүнчө бизнес-кардар аутсорсер компаниянын техникалык бөлүмү сыяктуу эле нерсени жасайт деп ойлойт. Алардын мотиваторлору ар кандай болсо да. Аутсорсингде кызыктай технологиялык чечимдер жана кызыктай алгоритмдик чечимдер бар.
Мисалы, бизде ар кандай күтүлбөгөн жерлерде Sphinx болгон кызмат бар болчу. Мен эмне кылышым керек экенин кийин айтам.
Аутсорсерлердин өз алдынча жазылган алкактары бар. Бул жөн гана мурунку долбоордон көчүрүп чаптоо менен жылаңач PHP, анда сиз ар кандай нерселерди таба аласыз. Кээ бир файлдагы бир нече саптарды өзгөртүү үчүн кээ бир татаал Bash скрипттерин колдонуу керек болгондо, жайылтуу скрипттери чоң кемчилик болуп саналат жана бул жайылтуу скрипттери кандайдыр бир үчүнчү скрипт тарабынан чакырылат. Натыйжада, сиз жайылтуу тутумун өзгөртөсүз, башка нерсени тандайсыз, секилесиз, бирок кызматыңыз иштебейт. Анткени ал жерде ар кандай папкалардын ортосуна дагы 8 шилтеме коюу керек болчу. Же миң жазуу иштейт, бирок жүз миңи иштебей калат.
Мен капитандыкты улантам. Аутсорсингдик кызматты кабыл алуу милдеттүү процедура болуп саналат. Кимдир бирөө аутсорсинг кызматы келип, эч жерде кабыл алынбай калдыбы? Бул, албетте, жетим кызмат катары популярдуу эмес, бирок дагы эле.
Кызматты текшерүү керек, кызматты карап чыгуу керек, сырсөздөрдү өзгөртүү керек. Бизде алар бизге кызмат көрсөткөн учур болгон, “эгер логин == 'admin' && пароль == 'admin'...” деген администратор панели бар, ал коддо так жазылган. Биз олтуруп ойлонуп, эл 2018-жылы ушуну жазып?
Сактагычтын сыйымдуулугун текшерүү да зарыл нерсе. Сиз бул кызматты бир жерде өндүрүшкө киргизерден мурун, жүз миң жазууда эмне болорун карап чыгышыңыз керек.
Кызматты жакшыртуу үчүн жөнөтүүдө уят болбошу керек. “Биз бул кызматты кабыл албайбыз, 20 тапшырмабыз бар, ошону аткаргыла, анан кабыл алабыз” десеңер, бул нормалдуу көрүнүш. Сиздин абийириңизди жетекчи орнотуп жатканыңыз же бизнесиңиз акчаны ысырап кылып жатканы үчүн оорутпашы керек. Андан кийин бизнес көбүрөөк сарптайт.
Бизде пилоттук долбоорду аутсорсингге берүүнү чечкен учур болгон.
Ал өз убагында жеткирилди жана бул сапаттын бирден бир критерийи болчу. Ошондуктан биз дагы бир пилоттук долбоорду жасадык, ал эми чындап эле пилоттук эмес. Бул кызматтар кабыл алынып, административдик жол менен бул жерде сиздин кодуңуз, мына командаңыз, мына сиздин менеджериңиз дешти. Кызматтар чынында эле киреше ала баштады. Ошол эле учурда, чындыгында, алар дагы эле жетим, алардын кандай иштегенин эч ким түшүнбөйт, жетекчилер алардын тапшырмаларынан баш тартуу үчүн колунан келгендин баарын кылышат.
Дагы бир улуу түшүнүк бар – партизандык өнүгүү. Кээ бир бөлүм, адатта маркетинг бөлүмү, гипотезаны сынап көргүсү келгенде жана бүт кызматка аутсорсингге буйрук бергенде. Трафик агып баштайт, документтерин жаап, подрядчы менен документтерге кол коюп, ишке киришип: “Улуулар, бул жерде кызматыбыз бар, ансыз деле трафик бар, бизге акча алып келет, кабыл алалы” дешет. Биз: "Оппа, бул кантип болсун" деп калдык.
Жетимдик кызматты алуунун дагы бир жолу: кандайдыр бир команда күтүлбөгөн жерден ашыкча жүк болуп калганда, жетекчилик: "Бул команданын кызматын башка командага өткөрүп берели, анын жүгү азыраак" дейт. Анан үчүнчү командага өткөрүп, менеджерди алмаштырабыз. Анан дагы акыры жетим балабыз.
Жетимдердин көйгөйү эмнеде?
Ким билбейт, бул Швецияда өстүрүлгөн Васа согуштук кемеси сууга түшкөндөн кийин 5 мүнөттөн кийин чөгүп кеткени менен белгилүү. Ал эми Швециянын королу, демекчи, бул үчүн эч кимди өлүм жазасына тарткан эмес. Аны мындай кемелерди жасоону билбеген эки муундагы инженерлер курушкан. Табигый эффект.
Баса, кеме мындан да жаман жол менен чөгүп кетиши мүмкүн эле, мисалы, падыша бороон-чапкында бир жерде минип жүргөндө. Ошентип, ал дароо чөгүп кетти, Agile айтымында, эрте ийгиликке жетпеген жакшы.
Эрте иштебей калсак, адатта эч кандай көйгөйлөр болбойт. Мисалы, кабыл алуу учурунда кайра карап чыгууга жиберилген. Бирок, эгерде биз акча салынгандан кийин өндүрүштө ийгиликсиз болсок, анда көйгөйлөр болушу мүмкүн. Натыйжалар, алар бизнес деп аталат.
Жетим кызматтар эмне үчүн коркунучтуу:
- Кызмат күтүлбөгөн жерден бузулушу мүмкүн.
- Кызмат оңдоого көп убакыт талап кылынат же такыр эле оңдолбойт.
- Коопсуздук көйгөйлөрү.
- Жакшыртуулар жана жаңыртуулар менен көйгөйлөр.
- Маанилүү кызмат иштебей калса, компаниянын аброюна доо кетет.
Жетим кызматтар менен эмне кылуу керек?
Мен дагы эмне кылууну кайталайм. Биринчиден, документтер болушу керек. Banki.ruдагы 7 жыл мага тестирлөөчүлөр иштеп чыгуучулардын сөзүн, ал эми операциялар ар бир адамдын сөзүн кабыл албашы керектигин үйрөттү. Биз текшеришибиз керек.
Экинчиден, өз ара аракеттенүү диаграммаларын жазуу керек, анткени анча жакшы алынбаган кызматтарда эч ким айтпаган көз карандылыктар болот. Мисалы, иштеп чыгуучулар кызматты кээ бир Yandex.Maps же Dadata үчүн ачкычтарына орнотушкан. Эркин чекиңиз түгөнүп калды, баары бузулду жана эмне болгонун такыр билбейсиз. Мындай тырмоолордун бардыгын сүрөттөш керек: кызмат Dadata, SMS, башка нерсени колдонот.
Үчүнчүдөн, техникалык карыз менен иштөө. Кандайдыр бир балдактарды жасаганда же кызматты кабыл алып, бир нерсе кылыш керек деп айтканда, анын аткарылганына ынануу керек. Анткени анда кичинекей тешик анчалык деле кичинекей эмес экени билинип калышы мүмкүн, андан түшүп каласың.
Архитектуралык тапшырмалар менен биз Sphinx жөнүндө окуя болгон. Кызматтардын бири тизмелерди киргизүү үчүн Сфинксти колдонгон. Жөн гана тизмеленген тизме, бирок ал күн сайын кечинде кайра индекстелди. Ал эки индекстен чогултулган: бир чоңу ар бир түнү индекстелчү, жана ага буралган кичинекей индекс да бар болчу. Күн сайын, 50% ыктымалдык менен бомбалоо же жок, индекс эсептөө учурунда кыйроого учурады жана биздин жаңылыктар башкы бетте жаңыланбай калды. Адегенде индексти кайра индекстөө үчүн 5 мүнөт талап кылынса, андан кийин индекс өсүп, бир учурда кайра индекстөө үчүн 40 мүнөт талап кылына баштады. Муну кесип салганда, биз жеңил дем алдык, анткени дагы бир аз убакыт өтүп, биздин индекс толук убакытта кайра индекстелери анык болчу. Бул биздин портал үчүн ийгиликсиз болуп калат, сегиз сааттан бери эч кандай жаңылык жок - болду, бизнес токтоп калды.
Жетим кызматы менен иштөө планы
Чындыгында, муну жасоо абдан кыйын, анткени devops баарлашууга байланыштуу. Сиз кесиптештериңиз менен жакшы мамиледе болгуңуз келет жана сиз кесиптештериңизди жана менеджерлериңизди эрежелер менен башыңызга урганыңызда, алар муну жасаган адамдарга карата карама-каршы сезимдерге ээ болушу мүмкүн.
Бардык ушул пункттардан тышкары, дагы бир маанилүү нерсе бар: конкреттүү адамдар ар бир конкреттүү кызмат үчүн, жайылтуу процедурасынын ар бир конкреттүү бөлүмү үчүн жооптуу болушу керек. Эл жок болгондо жана башка адамдарды тартуу керек болгондо, бул маселенин баарын изилдөө кыйын болуп калат.
Мунун баары жардам бербесе жана сиздин жетим кызматыңыз дагы эле жетим болсо, аны эч ким өз мойнуна алгысы келбесе, документация жазылбаган болсо, бул кызматка чакырылган команда эч нерсе кылуудан баш тартса, жөнөкөй жолу бар - кайра жасоо баары.
Башкача айтканда, сиз кызматка болгон талаптарды жаңыдан кабыл алып, кызыктай технологиялык чечимдерсиз, жакшыраак платформада жаңы кызматты жазасыз. Жана силер ага согушта хижрат кыласыңар.
Yii 1де кызматты алып, андан ары өнүктүрө албасыбызды түшүндүк, анткени Yii 1де жакшы жаза турган иштеп чыгуучулар түгөндү. Бардык иштеп чыгуучулар Symfony XNUMXте жакшы жазат. Эмне кылуу керек? Убакытты бөлүп, команда бөлүп, менеджерди бөлүп, долбоорду кайра жазып, ага трафикти оңой эле өткөрүп алдык.
Андан кийин, эски кызмат жок кылынышы мүмкүн. Бул менин сүйүктүү процедурам, сиз конфигурацияны башкаруу тутумунан кандайдыр бир кызматты алып, тазалап, андан кийин иштеп чыгуучуларда эч кандай издер калбашы үчүн өндүрүштөгү бардык унаалар өчүрүлгөнүн көрүшүңүз керек. Репозиторий Гитте калат.
Мунун баары мен сүйлөшкүм келди, мен талкуулоого даярмын, тема голивар, аны көптөр сүзүшкөн.
Слайдтарда тилдерди бириктиргениңди айтышты. Мисалы, сүрөттөрдүн өлчөмүн өзгөртүү. Аны бир тил менен гана чектеш керекпи? Анткени PHPде сүрөттүн өлчөмүн өзгөртүү, чынында, Голангда жасалышы мүмкүн.
Чынында, бул бардык практикалар сыяктуу эле милдеттүү эмес. Балким, кээ бир учурларда, ал тургай, жагымсыз болуп саналат. Бирок сиз түшүнүшүңүз керек, эгерде сизде 50 адамдан турган компанияда техникалык бөлүм болсо, алардын 45и PHP адистери, дагы 3ү Python, Ansible, Puppet жана башка ушул сыяктуу нерселерди билген devops жана алардын бирөө гана кээ бир тилдерде жазат. тилдин бир түрү. Ошол эле учурда, сиз бул тилди билген, өзгөчө, сейрек кездешүүчү рыноктук иштеп чыгуучуну издешиңиз керек болот. Башкача айтканда, уюштуруу жагынан алганда бул көйгөйлүү. Devops көз карашынан алганда, сиз жөн гана кызматтарды жайылтуу үчүн колдонгон кээ бир даяр окуу китептеринин топтомун клондоштуруунун кереги жок, бирок аларды кайра кайра жазууга туура келет.
Учурда биз Node.js кызматын куруп жатабыз жана бул ар бир иштеп чыгуучу үчүн өзүнчө тили бар жакын жердеги платформа гана болот. Бирок биз оюндун шамына татыктуу деп отуруп калдык. Тактап айтканда, бул сиз отуруп ойлоно турган суроо.
Кызматтарыңызды кантип көзөмөлдөйсүз? Журналдарды кантип чогултуп, көзөмөлдөйсүз?
Биз Elasticsearch'те журналдарды чогултуп, аларды Кибанага коебуз жана бул өндүрүш же сыноо чөйрөсүнө жараша, ал жерде ар кандай коллекторлор колдонулат. Бир жерде Lumberjack, башка жерде дагы бир нерсе, эсимде жок. Кээ бир кызматтарда дагы эле Telegraf орнотуп, башка жерде өзүнчө тарта турган жерлер бар.
Куурчак жана Ansible менен бир чөйрөдө кантип жашаш керек?
Чынында, азыр бизде эки чөйрө бар, бири куурчак, экинчиси Ansible. Аларды гибриддештирүүнүн үстүндө иштеп жатабыз. Ansible - баштапкы орнотуу үчүн жакшы алкак, Куурчак - баштапкы орнотуу үчүн начар алкак, анткени ал платформада түздөн-түз практикалык ишти талап кылат, ал эми Куурчак конфигурациянын конвергенциясын камсыздайт. Бул платформа өзүн актуалдуу абалда кармап турат дегенди билдирет жана ансибилизацияланган машина жаңыртылган болушу үчүн, анда ар дайым кандайдыр бир жыштык менен ойнотуу китептерин иштетүү керек. Айырмасы ушунда.
Кантип шайкештикти сактайсыз? Ansible жана Puppetте конфигурацияларыңыз барбы?
Бул биздин чоң азап, биз колубуз менен шайкештикти сактайбыз жана мунун баарынан азыр бир жерге кантип өтүүнү ойлонобуз. Көрсө, куурчак пакеттерди чыгарат жана ал жерде кээ бир шилтемелерди кармап турат, ал эми Ansible, мисалы, кодду чыгарып, ал жерде эң акыркы колдонмо конфигурацияларын тууралайт.
Презентация Rubyдин ар кандай версиялары тууралуу болду. Кандай чечим?
Биз муну бир жерден жолуктурдук жана аны дайыма башыбызда кармап турушубуз керек. Биз жөн гана Rubyде иштеген тиркемелерге туура келбеген бөлүгүн өчүрүп, аны өзүнчө сактап калдык.
Быйылкы конференция 7-декабрда Технополисте өтөт. Отчетторго арыздарды 11-ноябрга чейин кабыл алып жатабыз. сүйлөгүң келсе бизге.
Катышуучуларга каттоо ачык, бизге кошулуңуз!
Source: www.habr.com