Биз DevOps'ту колдон келишинче иштеп чыктык. Биз 8 киши болчубуз, Вася болсо Windowsтун эң сонуну болчу. Күтүлбөгөн жерден Вася кетип калды, менде Windows иштеп чыгуусу тарабынан берилген жаңы долбоорду ишке киргизүү милдети турду. Мен Windows иштеп чыгуу стекинин баарын үстөлдүн үстүнө таштаганда, абалдын оор экенин түшүндүм...
Окуя ушинтип башталат Александра Синчинова боюнча . Windowsтун жетектөөчү адиси компаниядан кеткенде, Александр эми эмне кыларын ойлонду. Албетте, Linux'ка өтүңүз! Александр 100 000 акыркы колдонуучу үчүн аяктаган долбоордун мисалын колдонуп, прецедентти кантип түзүүгө жана Windows өнүктүрүүнүн бир бөлүгүн Linux'ка которууга жетишкенин айтып берет.
TFS, Puppet, Linux .NET өзөгүн колдонуп RPMге долбоорду кантип оңой жана оңой жеткирүү керек? Эгерде иштеп чыгуучу топ Postgres жана Flyway деген сөздөрдү биринчи жолу укса жана акыркы мөөнөтү эртеңки күнү болсо, долбоордун маалымат базасын версиялоону кантип колдоо керек? Docker менен кантип интеграциялоо керек? .NET иштеп чыгуучуларын Windows жана Smoothies'ден баш тартууга кантип түрткү берсе болот? 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 менен интеграциялоо. Рельстер мурунтан эле бар болчу жана бардык иштер конфигурацияны башкаруу тутумунун параметрлерин, кабыл алынган жеткирүү стандарттарын жана мониторинг системаларын эске алуу менен аткарылышы керек болчу.
Колдоо жана иштетүү жеңил, ар кандай бөлүмдөрдөн жана колдоо бөлүмүнөн бардык жаңы катышуучулар үчүн минималдуу кирүү босогосунун шарты катары.
Мөөнөтү - кечээ.
Win Development Group
Анда Windows командасы эмне менен иштешкен?
Эми мен муну ишенимдүү айта алам IdentityServer4 окшош мүмкүнчүлүктөрү менен ADFS үчүн сонун акысыз альтернатива болуп саналат, же эмне Entity Framework Core - иштеп чыгуучу үчүн бейиш, анда сиз SQL скрипттерин жазуу менен убара болбойсуз, бирок маалымат базасындагы сурамдарды OOP терминдеринде сүрөттөп бериңиз. Бирок, андан кийин, иш-чаралардын планын талкуулоо учурунда, мен бул стекке PostgreSQL жана Gitти гана тааныган шумер клинописиндей карадым.
Ал кезде биз активдүү пайдаланып жатканбыз куурчак конфигурацияларды башкаруу системасы катары. Көпчүлүк долбоорлорубузда биз колдонгон GitLab CI, ийкемдүү, балансташтырылган жогорку жүктөө кызматтарын колдонуу HAProxy менен баарын көзөмөлдөп турду Апенди, байламталар Графана и Prometheus, Джагер, Мунун баары темир кесимдердин үстүндө айланып жатты HP c ESXi боюнча VMware. Аны баары билет - жанрдын классикасы.
Келгиле, карап көрөлү жана бул кийлигишүүлөрдүн баарын баштаардан мурун эмне болгонун түшүнүүгө аракет кылалы.
Эмне болду эле
TFS - бул абдан күчтүү система, ал кодду иштеп чыгуучудан акыркы өндүрүш машинасына жеткирбестен, ошондой эле ар кандай кызматтар менен абдан ийкемдүү интеграциялоо үчүн топтому бар - платформалар аралык деңгээлде CI менен камсыз кылуу.
Буга чейин бул катуу терезелер болгон. TFS көптөгөн долбоорлорду чогултуу үчүн колдонулган бир нече Build агенттерин колдонгон. Ар бир агентте тапшырмаларды параллелдаштыруу жана процессти оптималдаштыруу үчүн 3-4 жумушчу бар. Андан кийин, чыгаруу пландарына ылайык, TFS жаңы бышырылган Buildти Windows колдонмо серверине жеткирди.
Биз эмнеге жетүүнү кааладык?
Биз жеткирүү жана өнүктүрүү үчүн TFS колдонобуз жана Linux Колдонмо серверинде тиркемени иштетебиз жана алардын ортосунда кандайдыр бир сыйкыр бар. Бул Magic Box жана алдыда иштин тузу бар. Мен аны бөлүп алуудан мурун, мен бир кадам четке кагып, колдонмо жөнүндө бир нече сөз айтам.
долбоору
Тиркеме алдын ала төлөнгөн карталарды иштетүү үчүн функцияларды камсыз кылат.
керектөөчү
Колдонуучулардын эки түрү болгон. биринчи SSL SHA-2 сертификатын колдонуу менен кирүү мүмкүнчүлүгүнө ээ болду. У экинчи логин жана сырсөз аркылуу кирүү болгон.
HAProxy
Андан кийин кардардын суроо-талабы HAProxyге кетти, ал төмөнкү көйгөйлөрдү чечти:
- баштапкы уруксат;
- SSL токтотуу;
- HTTP сурамдарын тууралоо;
- берүү өтүнүчтөрү.
Кардардын сертификаты чынжыр боюнча текшерилди. Биз - бийлик жана биз муну көтөрө алабыз, анткени биз кардарларды тейлөөгө сертификаттарды беребиз.
Үчүнчү пунктка көңүл буруңуз, ага бир аздан кийин кайрылабыз.
Backend
Алар Linux'та backend жасоону пландаштырышкан. Backend маалымат базасы менен өз ара аракеттенет, артыкчылыктардын керектүү тизмесин жүктөйт жана андан кийин ыйгарым укуктуу колдонуучу кандай артыкчылыктарга ээ экендигине жараша, финансылык документтерге кол коюуга жана аларды аткарууга жөнөтүүгө же кандайдыр бир отчетту түзүүгө мүмкүндүк берет.
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 тапшырманы иштеп чыгуучуга - жумушчуга - Build агентине жөнөткөндө, ал ошондой эле иштеткич процессинин чөйрөсүндө аяктаган өзгөрмөлөрдүн бир тобун өткөрүп берет. Бул чөйрө өзгөрмөлөрү Build аталышын, версиянын аталышын жана башка өзгөрмөлөрдү камтыйт. Бул тууралуу кененирээк "RPM пакетин түзүү" бөлүмүнөн окуңуз.
TFS орнотуу куурду орнотууга келди. Мурда биз Windows агенттеринде бардык Windows долбоорлорун чогултканбыз, бирок азыр Linux агенти пайда болду - Build агенти, ал куруу тобуна киргизилиши керек, кээ бир артефакттар менен байытылган жана бул Build агентинде кандай типтеги долбоорлор курулаарын айтып берген. , жана кандайдыр бир жол менен Pipeline өзгөртүү.
IdentityServer. ADFS биздин жол эмес, биз Ачык булак үчүн бара жатабыз.
Келгиле, компоненттерди карап көрөлү.
Magic Box
Төрт бөлүктөн турат.
Linux Build агенти. 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 жөндөөлөрүндө белгилүү бир Build агентинин кандай ресурстары бар экенин көрсөткөн белги бар. Бул учурда, ал биз .NET Core долбоорун куруп жатканыбызды көрүп, бассейнден Linux Build агентин тандайт.
Build агенти булактарды алып, керектүүсүн жүктөйт көзкаранды .NET репозиторийинен, npm ж.б. жана колдонмонун өзүн жана андан кийинки таңгагын кургандан кийин, RPM пакетин RPM репозиторийине жөнөтөт.
Башка жагынан алганда, төмөнкүдөй болот. Операция бөлүмүнүн инженери долбоорду ишке ашырууга түздөн-түз катышат: ал пакеттердин версияларын өзгөртөт Hiera тиркеме рецепти сакталган репозиторийде, андан кийин Куурчак ишке кирет Yum, репозиторийден жаңы топтомду алат жана колдонмонун жаңы версиясы колдонууга даяр.
Баары сөз менен жөнөкөй, бирок Build агенттин ичинде эмне болот?
Packaging DLL RPM
TFSден долбоордун булактары жана куруу тапшырмасы алынды. Build агент булактардан долбоорду өзү кура баштайт. Чогулган долбоор комплект катары жеткиликтүү DLL файлдары, алар файл тутумундагы жүктү азайтуу үчүн zip архивинде топтолгон.
ZIP архив ыргытылат RPM пакетин куруу каталогуна. Андан кийин, Bash скрипти айлана-чөйрөнүн өзгөрмөлөрүн инициализациялайт, Build версиясын, долбоордун версиясын, куруу каталогуна жолду табат жана RPM-build иштетет. Куруу аяктагандан кийин, пакет жарыяланат жергиликтүү репозиторий, Build агентинде жайгашкан.
Андан кийин, 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ге оңой интеграцияланат. Бирок биз аны иштеп чыгуучуларга ыңгайлуу кылабыз :)
Тартуу процедурасы
Куурчак пакеттин версиясында, анын ичинде миграция үчүн жооптуу болгон өзгөртүү келе жатканын көрөт. Биринчиден, ал миграциялык скрипттерди жана маалымат базасына тиешелүү функцияларды камтыган пакетти орнотот. Андан кийин, маалымат базасы менен иштеген тиркеме кайра иштетилет. Андан кийин калган компоненттерди орнотуу келет. Пакеттердин орнотулушу жана тиркемелерди ишке киргизүү тартиби Куурчак манифестинде сүрөттөлөт.
Тиркемелер токендер, маалымат базасынын сырсөздөрү сыяктуу купуя маалыматтарды колдонушат, мунун баары Куурчак мастерден конфигурацияга тартылып, алар шифрленген түрдө сакталат.
TFS көйгөйлөр
Биз чечип, баары чындап эле биз үчүн иштеп жатканын түшүнгөндөн кийин, мен TFSдеги ассамблеялар менен бүтүндөй Win өнүктүрүү бөлүмү үчүн башка долбоорлор боюнча эмне болуп жатканын карап көрүүнү чечтим - биз тез эле куруп жатабызбы же жокпу, жана ылдамдык менен олуттуу көйгөйлөр табылган.
Негизги долбоорлордун бири чогултуу үчүн 12-15 мүнөт талап кылынат - бул көп убакыт, сен минтип жашай албайсың. Ыкчам талдоо I/Oдо коркунучтуу кыскарууну көрсөттү жана бул массивдерде болгон.
Аны компонент боюнча талдап чыккандан кийин мен үч очокту аныктадым. Алгачкы - "Касперский антивирусу", бардык Windows Build агенттериндеги булактарды сканерлейт. Экинчи - Windows Индексатор. Ал өчүрүлгөн эмес жана жайгаштыруу процессинде бардыгы Build агенттеринде реалдуу убакытта индекстелген.
Үчүнчү - Npm орнотуу. Көпчүлүк түтүктө биз дал ушул сценарийди колдонгон экенбиз. Эмне үчүн ал жаман? Npm орнотуу процедурасы көз карандылык дарагы түзүлгөндө иштетилет package-lock.json, мында долбоорду куруу үчүн колдонула турган пакеттердин версиялары жазылат. Кемчилиги - Npm орнотуу пакеттердин акыркы версияларын Интернеттен ар дайым чыгарып турат жана бул чоң долбоордо көп убакытты талап кылат.
Иштеп чыгуучулар кээде белгилүү бир бөлүктүн же бүтүндөй долбоордун кантип иштээрин текшерүү үчүн жергиликтүү машинада эксперимент жүргүзүшөт. Кээде жер-жерлерде баары муздак экен, бирок алар аны чогултуп, тоголоктоп, эч нерсе болгон эмес. Биз көйгөй эмнеде экенин түшүнө баштайбыз - ооба, көз карандылыгы бар пакеттердин ар кандай версиялары.
чечим
- AV өзгөчөлүктөрүндөгү булактар.
- Индекстештирүүнү өчүрүү.
- Баруу npm ci.
нпм ci-нин артыкчылыгы бизде Биз көз карандылык дарагын бир жолу чогултабыз, жана биз иштеп чыгуучу менен камсыз кылуу мүмкүнчүлүгүн алабыз пакеттердин учурдагы тизмеси, аны менен ал өзү каалагандай жергиликтүү эксперимент жасай алат. Бул убакытты үнөмдөйт кодду жазган иштеп чыгуучулар.
тарам
Эми репозиторийдин конфигурациясы жөнүндө бир аз. Тарыхта биз колдонобуз Nexus анын ичинде репозиторийлерди башкаруу үчүн Ички РЕПО. Бул ички репозиторий биз ички максаттар үчүн колдонгон бардык компоненттерди камтыйт, мисалы, өз алдынча жазылган мониторинг.
Биз да колдонобуз NuGet, анткени ал башка пакет менеджерлерине салыштырмалуу жакшыраак кэшке ээ.
жыйынтык
Куруу агенттерин оптималдаштыргандан кийин, куруунун орточо убактысы 12 мүнөттөн 7ге чейин кыскарды.
Эгерде биз Windows үчүн колдонсок, бирок бул долбоордо Linux-ка өткөн бардык машиналарды эсептесек, анда биз болжол менен 10 000 доллар үнөмдөп алдык.А бул жөн гана лицензияларда жана мазмунун эске алсак, андан да көп.
пландар
Кийинки чейрек үчүн биз кодду жеткирүүнү оптималдаштыруунун үстүндө иштөөнү пландаштырдык.
Алдын ала түзүлгөн Docker сүрөтүнө которулууда. TFS - бул Pipeline менен интеграциялоого мүмкүндүк берген көптөгөн плагиндери бар сонун нерсе, анын ичинде триггерге негизделген монтаж, айталы, Докер сүрөтү. Биз бул триггерди ошол эле үчүн жасагыбыз келет package-lock.json. Долбоорду куруу үчүн колдонулган компоненттердин курамы кандайдыр бир түрдө өзгөрсө, биз жаңы Docker сүрөтүн курабыз. Ал кийинчерээк чогултулган колдонмо менен контейнерди жайылтуу үчүн колдонулат. Азыр андай эмес, бирок биз компаниябызда жигердүү өнүгүп келе жаткан жана көптөн бери өндүрүштүк чечимдерди тейлеген Кубернетестеги микросервис архитектурасына өтүүнү пландап жатабыз.
на
Мен бардыгын Windowsту ыргытууга чакырам, бирок бул аны кантип бышырганды билбегенимден эмес. Себеби, көпчүлүк Opensource чечимдери болуп саналат Linux стек. сен жакшы элесиңби ресурстарды үнөмдөө. Менин оюмча, келечек күчтүү коомчулугу бар Linux боюнча Open Source чечимдерине таандык.
Спикер Александр Сынчиновдун профили .
профессионалдар тарабынан профессионалдар үчүн иштеп чыгуу, тестирлөө жана иштетүү процесстерин интеграциялоо боюнча конференция болуп саналат. Александр айткан долбоор эмне үчүн? ишке ашырылды жана иштеп жатат, ал эми спектакль күнү эки ийгиликтүү чыгарылыш болду. Күйүк 27 жана 28-майда практиктерден дагы ушундай учурлар болот. Сиз дагы эле акыркы вагонго секирип алат жана же убактыңызды алыңыз билет. Бизди Сколководо тосуп алыңыз!
Source: www.habr.com