Біз DevOps-ті қолдан келгенше әзірледік. Біз 8 адам едік, ал Вася Windows жүйесіндегі ең керемет еді. Кенеттен Вася кетіп қалды, менде Windows әзірлеген жаңа жобаны іске қосу міндеті тұрды. Мен бүкіл Windows әзірлеу стегін үстелге тастаған кезде, жағдайдың ауыр екенін түсіндім ...
Әңгіме осылай басталады Александра Синчинова туралы . Жетекші Windows маманы компаниядан кеткенде, Александр енді не істеу керектігін ойлады. Әрине, Linux жүйесіне ауысыңыз! Александр сізге 100 000 түпкілікті пайдаланушыға арналған аяқталған жобаның мысалын қолдана отырып, прецедентті қалай жасағанын және Windows дамуының бір бөлігін Linux-қа қалай көшіргенін айтып береді.
TFS, Puppet, Linux .NET ядросын пайдаланып жобаны RPM-ге қалай оңай және қиындықсыз жеткізуге болады? Егер әзірлеушілер тобы Postgres және Flyway сөздерін бірінші рет естісе және соңғы мерзім ертеңгі күні болса, жоба дерекқорының нұсқасын қалай қолдауға болады? Docker-пен қалай біріктіруге болады? .NET әзірлеушілерін Windows пен смузилерден қуыршақ пен Linux пайдасына бас тартуға қалай ынталандыруға болады? Windows жүйесін өндірісте ұстауға күш те, тілек те, ресурстар да болмаса, идеологиялық қақтығыстарды қалай шешуге болады? Бұл туралы, сондай-ақ Web Deploy, тестілеу, CI, бар жобаларда TFS пайдалану тәжірибелері туралы және, әрине, сынған балдақтар мен жұмыс шешімдері туралы Александр баяндамасының стенограммасында.
Сонымен, Вася кетіп қалды, тапсырма менде, әзірлеушілер шанышқылармен тағатсыздана күтуде. Васяны қайтару мүмкін емес екенін түсінгенде, мен іске кірістім. Алдымен мен флоттағы Win VM-нің пайызын бағаладым. Есеп Windows пайдасына болмады.
Біз DevOps-ті белсенді түрде дамытып жатқандықтан, мен жаңа қосымшаны жеткізуде бір нәрсені өзгерту керек екенін түсіндім. Бір ғана шешім болды - мүмкін болса, барлығын Linux жүйесіне көшіріңіз. Google маған көмектесті - сол кезде .Net Linux жүйесіне көшірілген болатын, мен бұл шешім екенін түсіндім!
Неліктен .NET ядросы Linux-пен бірге?
Бұған бірнеше себеп болды. «Ақша төлеу» мен «төлемеу» арасында басым көпшілігі мен сияқты екіншісін таңдайды. MSDB лицензиясы шамамен $1 тұрады; Windows виртуалды машиналарының паркін ұстау жүздеген доллар тұрады. Үлкен компания үшін бұл үлкен шығын. Сондықтан жинақ - бірінші себеп. Ең маңыздысы емес, маңыздыларының бірі.
Windows виртуалды машиналары Linux бауырларына қарағанда көбірек ресурстарды алады - олар ауыр. Үлкен компанияның ауқымын ескере отырып, біз Linux-ті таңдадық.
Жүйе жай ғана бар CI-ге біріктірілген. Біз өзімізді прогрессивті DevOps деп санаймыз, біз Bamboo, Jenkins және GitLab CI пайдаланамыз, сондықтан жұмысымыздың көп бөлігі Linux жүйесінде жұмыс істейді.
Соңғы себеп ыңғайлы сүйемелдеу. Бізге техникалық бөлікті түсінетін, үзіліссіз қызмет көрсетуді қамтамасыз ететін және екінші желіден қызмет көрсететін жігіттер үшін «эскорттар» үшін кіруге кедергіні төмендету керек болды. Олар Linux стекімен бұрыннан таныс болды, сондықтан оларға жаңа өнімді түсіну, қолдау және қолдау Windows платформасы үшін бағдарламалық жасақтаманың бірдей функционалдығын түсіну үшін қосымша ресурстарды жұмсаудан әлдеқайда оңайырақ.
талаптар
Ең алдымен - әзірлеушілер үшін жаңа шешімнің ыңғайлылығы. Олардың бәрі өзгеруге дайын емес еді, әсіресе Linux сөзі айтылғаннан кейін. Әзірлеушілер өздерінің сүйікті Visual Studio, жинақтар мен смузилерге арналған автотесттері бар TFS-ті қалайды. Олар үшін өндіріске қалай жеткізілетіні маңызды емес. Сондықтан біз әдеттегі процесті өзгертпеуді және Windows әзірлеу үшін барлығын өзгеріссіз қалдыруды шештік.
Жаңа жоба қажет қолданыстағы CI-ге біріктіру. Рельстер қазірдің өзінде болды және барлық жұмыс конфигурацияны басқару жүйесінің параметрлерін, қабылданған жеткізу стандарттарын және бақылау жүйелерін ескере отырып жасалуы керек еді.
Қолдау және пайдаланудың қарапайымдылығы, әртүрлі бөлімшелер мен қолдау бөлімінен барлық жаңа қатысушылар үшін ең төменгі кіру шегінің шарты ретінде.
Мерзімі - кеше.
Жеңіс дамыту тобы
Windows командасы сол кезде немен жұмыс істеді?
Енді мен мұны сенімді түрде айта аламын IdentityServer4 ұқсас мүмкіндіктері бар ADFS-ке керемет тегін балама немесе не Entity Framework Core - әзірлеушіге арналған жұмақ, мұнда SQL сценарийлерін жазудың қажеті жоқ, бірақ деректер қорындағы сұрауларды OOP терминдерінде сипаттаңыз. Бірақ содан кейін, әрекет жоспарын талқылау кезінде мен бұл стекке тек PostgreSQL және Git-ті танитын шумер сына жазуы сияқты қарадым.
Ол кезде біз белсенді түрде қолданатынбыз Қуыршақ конфигурацияны басқару жүйесі ретінде. Біздің жобаларымыздың көпшілігінде біз қолдандық GitLab CI, серпімді, теңдестірілген жоғары жүктеме қызметтерін пайдалану HAProxy барлығын бақылап отырды Zabbix, байламдар Графана и Прометей, Джейгер, және мұның бәрі темір бөліктерінде айналды HP c ESXi туралы VMware. Оны бәрі біледі - жанрдың классикасы.
Осы араласуды бастамас бұрын не болғанын қарастырайық және түсінуге тырысайық.
Не болды
TFS - бұл әзірлеушіден соңғы өндірістік машинаға кодты жеткізіп қана қоймай, сонымен қатар әртүрлі қызметтермен өте икемді интеграцияға арналған жиынтыққа ие - кросс-платформа деңгейінде CI қамтамасыз ететін жеткілікті қуатты жүйе.
Бұрын бұл қатты терезелер болатын. TFS көптеген жобаларды құрастыру үшін пайдаланылған бірнеше Build агенттерін пайдаланды. Тапсырмаларды параллельдеу және процесті оңтайландыру үшін әр агентте 3-4 жұмысшы бар. Содан кейін, шығару жоспарларына сәйкес, TFS Windows қолданбасының серверіне жаңадан пісірілген құрастыруды жеткізді.
Біз неге қол жеткізгіміз келді?
Біз жеткізу және әзірлеу үшін TFS қолданамыз және қолданбаны Linux қолданбасының серверінде іске қосамыз және олардың арасында қандай да бір сиқыр бар. Бұл Magic Box және алда жұмыстың тұзы бар. Мен оны бөлшектемес бұрын, мен бір қадам шетке шығып, қолданба туралы бірнеше сөз айтамын.
Жоба
Қолданба алдын ала төленген карталармен жұмыс істеуге мүмкіндік береді.
клиент
Пайдаланушылардың екі түрі болды. бірінші SSL SHA-2 сертификатын пайдаланып кіру арқылы қол жеткізді. У секунд логин мен пароль арқылы кіру болды.
HAProxy
Содан кейін клиенттің сұрауы HAProxy қызметіне жіберілді, ол келесі мәселелерді шешті:
- бастапқы рұқсат;
- SSL тоқтату;
- HTTP сұрауларын реттеу;
- хабар тарату сұраулары.
Клиент сертификаты тізбек бойынша тексерілді. Біз - орган және біз мұны төлей аламыз, өйткені біз өзіміз қызмет көрсететін клиенттерге сертификаттар береміз.
Үшінші тармаққа назар аударыңыз, біз оған сәл кейінірек ораламыз.
Тетік бағдарламасы
Олар Linux жүйесінде сервер жасауды жоспарлады. Бэкэнд дерекқормен өзара әрекеттеседі, артықшылықтардың қажетті тізімін жүктейді, содан кейін уәкілетті пайдаланушының қандай артықшылықтары бар екеніне байланысты қаржылық құжаттарға қол қоюға және оларды орындауға жіберуге рұқсат береді немесе есептің қандай да бір түрін жасайды.
HAProxy көмегімен үнемдеу
Әрбір клиент шарлаған екі контекстен басқа, сәйкестік контексті де болды. IdentityServer4 кіруге мүмкіндік береді, бұл тегін және қуатты аналогы ADFS - Active Directory федерациясының қызметтері.
Сәйкестендіру сұрауы бірнеше қадаммен өңделді. Алғашқы қадам - клиент артқы жағына кірді, ол осы сервермен байланысып, клиент үшін таңбалауыштың болуын тексерді. Егер ол табылмаса, сұрау қайтып келген мәтінмәнге қайтарылды, бірақ қайта бағыттаумен және қайта бағыттаумен сәйкестендіруге өтті.
Екінші қадам – сұраныс қабылданды IdentityServer ішіндегі авторизация бетіне, клиент тіркелген және сол көптен күткен таңбалауыш IdentityServer дерекқорында пайда болды.
Үшінші қадам - клиент кері бағытталды келген контекстке.
IdentityServer4 мүмкіндігі бар: ол HTTP арқылы қайтару сұрауына жауапты қайтарады. Серверді орнатуда қанша қиналғанымызбен, құжаттамамен қаншалықты түсіндірсек те, HTTPS арқылы келетін URL мекенжайы бар бастапқы клиенттік сұрауды алған сайын және IdentityServer бірдей контекстті қайтарды, бірақ HTTP. Біз таң қалдық! Біз мұның барлығын сәйкестендіру контексті арқылы HAProxy-ге тасымалдадық, ал тақырыптарда HTTP протоколын HTTPS-ке өзгертуге тура келді.
Жақсарту дегеніміз не және сіз қайда үнемдедіңіз?
Біз пайдаланушылар тобын, ресурстарды авторизациялаудың ақысыз шешімін пайдалану арқылы ақшаны үнемдедік, өйткені біз IdentityServer4-ті бөлек сегментте бөлек түйін ретінде орналастырмадық, бірақ оны қолданбаның сервері жұмыс істейтін сол серверде сервермен бірге пайдаландық. .
Ол қалай жұмыс істеуі керек
Сонымен, мен уәде еткенімдей - Сиқырлы қорап. Біз Linux жүйесіне көшуге кепілдік берілгенін түсіндік. Шешімдерді қажет ететін нақты тапсырмаларды құрастырайық.
Қуыршақ көріністері. Қызмет пен қолданба конфигурациясын жеткізу және басқару үшін керемет рецепттер жазу керек болды. Бір орам қарындаш оның қаншалықты тез және тиімді жасалғанын көрсетеді.
Жеткізу әдісі. Стандарт - RPM. Linux жүйесінде онсыз жасай алмайтыныңызды бәрі түсінеді, бірақ жобаның өзі құрастырудан кейін орындалатын DLL файлдарының жиынтығы болды. Олардың саны 150-ге жуық болды, жоба өте қиын болды. Жалғыз үйлесімді шешім - бұл екілік файлды RPM-ге буып, одан қолданбаны орналастыру.
Нұсқа жасау. Бізге өте жиі шығаруға тура келді және пакет атауын қалай қалыптастыру керектігін шешуге тура келді. Бұл TFS-пен интеграция деңгейі туралы мәселе. Бізде Linux жүйесінде құрастыру агенті болды. TFS тапсырманы өңдеушіге - жұмысшыға - Құрастыру агентіне жібергенде, ол өңдеуші процесінің ортасында аяқталатын айнымалылар жиынын да жібереді. Бұл орта айнымалы мәндері Құрастыру атауын, нұсқа атауын және басқа айнымалы мәндерді қамтиды. Бұл туралы толығырақ «RPM пакетін құру» бөлімінде оқыңыз.
TFS орнату Құбырды орнатуға келді. Бұрын біз Windows агенттеріндегі барлық Windows жобаларын жинадық, бірақ қазір Linux агенті пайда болды - құрастыру тобына қосылуы керек, кейбір артефактілермен байытылуы және осы Құрастыру агентінде қандай жобалар түрі құрылатынын айту керек Build агенті , және қандай да бір жолмен Құбырды өзгертіңіз.
IdentityServer. ADFS біздің жолымыз емес, біз ашық бастапқы кодты қолданамыз.
Құрамдас бөліктерге тоқталайық.
Magic Box
Төрт бөліктен тұрады.
Linux құрастыру агенті. Linux, өйткені біз ол үшін құрастырамыз - бұл қисынды. Бұл бөлім үш кезеңмен орындалды.
- Жұмысшыларды конфигурациялау және жалғыз емес, өйткені жоба бойынша бөлінген жұмыс күтілді.
- .NET Core 1.x орнатыңыз. Неліктен 1 стандартты репозиторийде қолжетімді болса, 2.0.x керек? Өйткені біз әзірлеуді бастаған кезде тұрақты нұсқасы 1.09 болатын және жобаны соның негізінде жасау туралы шешім қабылданды.
- Git 2.x.
RPM-репозиторий. RPM пакеттерін бір жерде сақтау керек болды. Біз барлық Linux хосттары үшін қолжетімді бірдей корпоративтік RPM репозиторийін пайдаланамыз деп болжанған болатын. Олар осылай істеді. Репозиторий сервері конфигурацияланған веб -ілмек ол көрсетілген жерден қажетті RPM бумасын жүктеп алды. Бума нұсқасы туралы Build агенті вебхукқа хабарлады.
GitLab. Назар аударыңыз! Мұнда GitLab әзірлеушілермен емес, операциялық бөліммен қолданба нұсқаларын, пакет нұсқаларын басқару, барлық Linux машиналарының күйін бақылау үшін пайдаланылады және рецептті сақтайды - барлық қуыршақ манифесттері.
Қуыршақ — барлық даулы мәселелерді шешеді және Gitlab-тен біз қалаған конфигурацияны дәл жеткізеді.
Біз суға түсуді бастаймыз. RPM-ге DLL жеткізу қалай жұмыс істейді?
RPM дейін DDL жеткізу
Бізде .NET әзірлеуші рок жұлдызы бар делік. Ол Visual Studio бағдарламасын пайдаланады және шығарылым тармағын жасайды. Осыдан кейін ол оны Git-ке жүктейді, ал Git бұл жерде TFS нысаны болып табылады, яғни бұл әзірлеуші жұмыс істейтін қолданбалар репозиторийі.
Осыдан кейін TFS жаңа міндеттеме келгенін көреді. Қай қолданба? TFS параметрлерінде белгілі бір Құрастыру агентінде қандай ресурстар бар екенін көрсететін белгі бар. Бұл жағдайда ол .NET Core жобасын жасап жатқанымызды көреді және пулдан Linux Build агентін таңдайды.
Құрастыру агенті көздерді алады және қажеттіні жүктейді тәуелділіктер .NET репозиторийінен, npm және т.б. және қолданбаның өзін және кейінгі орамды құрастырғаннан кейін RPM бумасын RPM репозиторийіне жібереді.
Екінші жағынан, келесі жағдай орын алады. Операциялар бөлімінің инженері жобаны шығаруға тікелей қатысады: ол пакеттердің нұсқаларын өзгертеді Хиера қолданба рецепті сақталатын репозиторийде, содан кейін Қуыршақ іске қосылады Yum, репозиторийден жаңа буманы алады және қолданбаның жаңа нұсқасы пайдалануға дайын.
Сөзбен айтқанда бәрі қарапайым, бірақ Build агентінің өзінде не болады?
DLL RPM бумасы
TFS жүйесінен жоба көздері және құрастыру тапсырмасы алынды. Құрастыру агенті көздерден жобаның өзін құруды бастайды. Жиналған жоба жиынтық түрінде қол жетімді DLL файлдары, олар файлдық жүйедегі жүктемені азайту үшін zip мұрағатында оралған.
ZIP мұрағаты лақтырылды RPM бумасының құрастыру каталогына. Содан кейін Bash сценарийі ортаның айнымалы мәндерін инициализациялайды, Құрастыру нұсқасын, жоба нұсқасын, құрастыру каталогына жолды табады және RPM-build іске қосады. Құрастыру аяқталғаннан кейін бума жарияланады жергілікті репозиторий, ол Құрастыру агентінде орналасқан.
Әрі қарай, Құрастыру агентінен RPM репозиторийіндегі серверге JSON сұрауы жіберілді нұсқа мен құрастырудың атын көрсетеді. Мен бұрын айтқан Webhook осы пакетті Build агентіндегі жергілікті репозиторийден жүктеп алады және жаңа жинақты орнату үшін қолжетімді етеді.
Неліктен бұл пакетті RPM репозиторийіне жеткізу схемасы? Неліктен жинақталған буманы бірден репозиторийге жібере алмаймын? Өйткені, бұл қауіпсіздікті қамтамасыз етудің шарты. Бұл сценарий рұқсат етілмеген адамдардың RPM бумаларын барлық Linux машиналарына қолжетімді серверге жүктеп салу мүмкіндігін шектейді.
Мәліметтер базасының нұсқасын жасау
Әзірлеушілер тобымен кеңескенде, жігіттер MS SQL-ге жақынырақ екені белгілі болды, бірақ Windows емес жобалардың көпшілігінде біз PostgreSQL-ті бар күшімен қолданып жүрміз. Біз барлық төленгеннен бас тартуды шешкендіктен, біз PostgreSQL-ті осында да пайдалана бастадық.
Бұл бөлімде мен сізге дерекқорды қалай нұсқалағанымызды және Flyway және Entity Framework Core арасында қалай таңдағанымызды айтқым келеді. Олардың оң және теріс жақтарын қарастырайық.
Минусы
Flyway тек бір жолмен жүреді, біз кері айналдыра алмаймыз - бұл айтарлықтай кемшілік. Оны Entity Framework Core бағдарламасымен басқа жолдармен салыстыруға болады - әзірлеушіге ыңғайлылық тұрғысынан. Естеріңізде болса, біз мұны бірінші орынға қойдық, ал негізгі критерий Windows әзірлеу үшін ештеңені өзгертпеу болды.
Flyway біз үшін қандай да бір қаптама қажет болдыжігіттер жазбау үшін SQL сұраулары. Олар OOP шарттарында жұмыс істеуге әлдеқайда жақын. Мәліметтер қоры объектілерімен жұмыс істеу нұсқауларын жаздық, SQL сұранысын жасап, оны орындадық. Дерекқордың жаңа нұсқасы дайын, сынақтан өтті - бәрі жақсы, бәрі жұмыс істейді.
Entity Framework Core минустары бар - ауыр жүктемелерде оңтайлы емес SQL сұрауларын құрастырады, және дерекқордағы азаю маңызды болуы мүмкін. Бірақ бізде жоғары жүктеме қызметі болмағандықтан, біз жүздеген RPS жүктемесін есептемейміз, біз бұл тәуекелдерді қабылдап, мәселені болашаққа тапсырдық.
Плюсы
Entity Framework Core қораптан тыс жұмыс істейді және әзірлеуге оңай, және Flyway Қолданыстағы CI-ге оңай біріктіріледі. Бірақ біз оны әзірлеушілерге ыңғайлы етеміз :)
Жинақтау процедурасы
Қуыршақ бума нұсқасының, соның ішінде көші-қонға жауапты нұсқасының өзгеретінін көреді. Біріншіден, ол тасымалдау сценарийлері мен дерекқорға қатысты функционалдылықты қамтитын буманы орнатады. Осыдан кейін дерекқормен жұмыс істейтін қолданба қайта іске қосылады. Одан кейін қалған компоненттерді орнату басталады. Бумаларды орнату және қолданбаларды іске қосу реті Қуыршақ манифестінде сипатталған.
Қолданбалар таңбалауыштар, дерекқор құпия сөздері сияқты құпия деректерді пайдаланады, мұның бәрі Puppet шеберінен конфигурацияға алынады, онда олар шифрланған түрде сақталады.
TFS мәселелері
Біз шешіп, бәрі біз үшін жұмыс істеп жатқанын түсінгеннен кейін, мен басқа жобалар бойынша Win әзірлеу бөлімі үшін тұтастай TFS-тегі жинақтармен не болып жатқанын - біз тез құрастырдық/шығарып жатырмыз ба, жоқ па, қарауды шештім. жылдамдыққа қатысты маңызды проблемаларды анықтады.
Негізгі жобалардың бірін құрастыруға 12-15 минут кетеді - бұл ұзақ уақыт, сіз бұлай өмір сүре алмайсыз. Жылдам талдау енгізу/шығарудағы қорқынышты төмендеуді көрсетті және бұл массивтерде болды.
Оны компонент бойынша талдағаннан кейін мен үш ошақты анықтадым. Бірінші - «Касперский антивирусы», ол барлық Windows Build агенттеріндегі көздерді сканерлейді. Екінші - Windows Индексатор. Ол өшірілмеді және орналастыру процесі кезінде барлығы Құрастыру агенттерінде нақты уақытта индекстелді.
Үшінші - Npm орнату. Көптеген құбыр желілерінде біз дәл осы сценарийді қолданғанымыз белгілі болды. Ол неге жаман? Npm орнату процедурасы тәуелділік ағашы құрылған кезде орындалады package-lock.json, мұнда жобаны құру үшін пайдаланылатын пакеттердің нұсқалары жазылады. Кемшілігі - Npm орнатуы Интернеттен пакеттердің соңғы нұсқаларын әр уақытта шығарып алады және бұл үлкен жоба жағдайында көп уақытты алады.
Әзірлеушілер кейде белгілі бір бөліктің немесе бүкіл жобаның қалай жұмыс істейтінін тексеру үшін жергілікті машинада тәжірибе жасайды. Кейде жергілікті жерде бәрі салқын болып шықты, бірақ олар оны жинап, оны айналдырды және ештеңе істемеді. Біз мәселенің не екенін анықтай бастаймыз - иә, тәуелділіктері бар пакеттердің әртүрлі нұсқалары.
шешім
- AV ерекшеліктеріндегі көздер.
- Индекстеуді өшіру.
- Ауысу npm ci.
npm ci артықшылығы мынада: біз Тәуелділік ағашын бір рет жинаймыз, және біз әзірлеушімен қамтамасыз ету мүмкіндігін аламыз пакеттердің ағымдағы тізімі, онымен ол қалағанынша жергілікті тәжірибе жасай алады. Бұл уақытты үнемдейді кодты жазатын әзірлеушілер.
Конфигурация
Енді репозиторий конфигурациясы туралы аздап. Тарихи түрде қолданамыз Nexus репозиторийлерді басқаруға арналған, соның ішінде Ішкі РЕПО. Бұл ішкі репозиторийде біз ішкі мақсаттар үшін қолданатын барлық құрамдас бөліктер бар, мысалы, өздігінен жазылған бақылау.
Біз де қолданамыз NuGet, өйткені басқа пакет менеджерлерімен салыстырғанда жақсы кэштеу бар.
нәтиже
Құрастыру агенттерін оңтайландырғаннан кейін орташа құрастыру уақыты 12 минуттан 7 минутқа дейін қысқартылды.
Егер біз Windows үшін қолдануға болатын, бірақ осы жобада Linux жүйесіне ауысқан барлық машиналарды есептесек, біз шамамен $10 000 үнемдедік.Ал бұл тек лицензияларға қатысты, ал егер мазмұнды ескерсек, одан да көп.
жоспарлары
Келесі тоқсанда біз кодты жеткізуді оңтайландыру бойынша жұмыс істеуді жоспарладық.
Алдын ала құрастырылған Docker кескініне ауысу. TFS - бұл Pipeline жүйесіне біріктіруге мүмкіндік беретін көптеген плагиндері бар керемет нәрсе, соның ішінде, мысалы, Docker кескінін триггерге негізделген құрастыру. Біз бұл триггерді дәл сол үшін жасағымыз келеді package-lock.json. Егер жобаны құру үшін пайдаланылған компоненттердің құрамы қандай да бір түрде өзгерсе, біз жаңа Docker кескінін жасаймыз. Ол кейінірек жиналған қолданбамен контейнерді орналастыру үшін пайдаланылады. Бұл қазір олай емес, бірақ біз компаниямызда белсенді дамып келе жатқан және ұзақ уақыт бойы өндірістік шешімдерге қызмет етіп келе жатқан Кубернетестегі микросервис архитектурасына ауысуды жоспарлап отырмыз.
Резюме
Мен барлығын Windows-ты тастауға шақырамын, бірақ бұл оны қалай пісіруді білмегендіктен емес. Себебі Opensource шешімдерінің көпшілігі Linux стегі. Сіз жақсы ресурстарды үнемдеу. Менің ойымша, болашақ қуатты қауымдастығы бар Linux жүйесіндегі Open Source шешімдеріне тиесілі.
Александр Сынчиновтың спикер профилі .
кәсіби мамандар үшін әзірлеу, тестілеу және пайдалану процестерін біріктіру бойынша конференция болып табылады. Сондықтан Александр айтқан жоба? енгізілді және жұмыс істейді, ал спектакль күні екі сәтті шығарылым болды. Қосулы 27 және 28 мамырда тәжірибешілер тарапынан осындай жағдайлар бұдан да көп болады. Сіз әлі де соңғы вагонға секіре аласыз және немесе уақытыңызды алыңыз билет. Бізді Сколковода қарсы алыңыз!
Ақпарат көзі: www.habr.com