Гэта расшыфроўка выступу на и .
Гэта гісторыя праекту, на якім выкарыстоўвалася самапісная сістэма кіравання канфігурацыямі і чаму пераезд на Ansible зацягнуўся на 18 месяцаў.
Дзень №-ХХХ: Before the beginning
Першапачаткова інфраструктура ўяўляла сабой мноства асобна стаячых хастоў пад кіраваннем Hyper-V. Стварэнне віртуальнай машыны патрабавала мноства дзеянняў: пакласці дыскі ў патрэбнае месца, прапісаць DNS, зарэзерваваць DHCP, пакласці канфігурацыю ВМ у git рэпазітар. Гэты працэс быў часткова механізаваны, але напрыклад ВМ размяркоўваліся паміж хастамі рукамі. Але, напрыклад, распрацоўнікі маглі паправіўшы канфігурацыю ВМ у git ужыць яе перазагрузіўшы ВМ.
Custom Configuration Management Solution
Першапачатковая ідэю, падазраю, задумвалі як IaC: мноства stateless ВМ, якія пры перазагрузцы абнулялі свой стан. Што з сябе ўяўляла кіраванне канфігурацыямі ВМ? Схематычна выглядае проста:
- Для ВМ прыбівалі статычны MAC.
- Да ВМ падлучалі ISO з CoreOS і загрузны дыск.
- CoreOS запускае скрыпт кастамізацыі запампаваўшы яго з WEB сервера на падставе свайго IP.
- Скрыпт выпампоўвае праз SCP канфігурацыю ВМ засноўваючыся на IP адрасе.
- Запускаецца парцянка systemd unit файлаў і парцянка bash скрыптоў.
У гэтага рашэння было мноства відавочных праблем:
- ISO у CoreOS было deprecated.
- Мноства складана аўтаматызаваных дзеянняў і магіі пры міграцыі / стварэнні ВМ.
- Складанасць з абнаўленнем і калі неабходна ПЗ нейкай версіі. Яшчэ весялей з модулямі ядра.
- ВМ не такія ўжо без дадзеных атрымліваліся, г.зн. з'явіліся ВМ у якіх змантаваны дыск з карыстацкімі дадзенымі дадаткова.
- Увесь час хтосьці касячыў з залежнасцямі systemd unit і пры перазагрузцы CoreOS завісала. Наяўнымі сродкамі ў CoreOS адлавіць гэта было праблемна.
- Упраўленне сакрэтамі.
- CM не было лічы. Быў bash і YML канфігі CoreOS.
Што б ужыць канфігурацыю ВМ неабходна яе перазагрузіць, але яна магла не перазагрузіцца. Накшталт відавочная праблема, але персістэнтных дыскаў няма - логі захоўваць няма куды. Ну ок, давайце паспрабуем дадаць опцыі загрузка ядра што б логі перасылалі. Але не, як гэта складана ўсё.
Дзень №0: Прызнанне праблемы
Гэта была звычайная распрацоўчая інфраструктура: jenkins, тэставыя асяроддзі, маніторынгі, registry. CoreOS задумвалася для хостынгу k8s кластараў, г.зн. праблема была ў тым, як выкарыстоўвалася CoreOS. Першым крокам быў выбар стэка. Мы спыніліся на:
- CentOS як базавы дыстрыбутыў, т.я. гэта найбольш блізкі дыстрыбутыў да production асяроддзем.
- анзибль для кіравання канфігурацыямі, т.я. па ім была шырокая экспертыза.
- Джэнкінс як фрэймворк аўтаматызацыі існуючых працэсаў, т.я. ён ужо актыўна выкарыстоўваўся для працэсаў распрацоўкі
- Hyper-V, як платформа віртуалізацыі. Ёсць шэраг прычын, якія выходзяць за рамкі апавядання, але калі коратка - мы не можам выкарыстоўваць аблокі, павінны выкарыстоўваць сваё жалеза.
Дзень №30: Фіксуем існуючыя дамоўленасці — Agreements as Code
Калі быў зразумелы стэк, пачалася падрыхтоўка да пераезду. Фіксаванне існуючых дамоўленасцей у выглядзе кода (Agreements as Code!). Пераход ручная праца -> механізацыя -> аўтаматызацыя.
1. Configure VMs
Ansible добра спраўляецца з гэтай задачай. З мінімум рухаў цела можна ўзяць пад кіраванне канфігурацыямі ВМ:
- Ствараем git рэпазітар.
- Складаем спіс ВМ у inventory, канфігурацыі ў плэйбукі і ролі.
- Наладжваем спецыяльны jenkins slave з якога можна будзе запускаць ansible.
- Ствараем job, наладжваем Jenkins.
Першы працэс готаў. Дамоўленасці зафіксаваны.
2. Create new VM
Тут усё не надта зручна было. З лінукс не вельмі зручна ствараць ВМ на Hyper-V. Адной са спробаў механізаваць гэты працэс было:
- Ansbile падключаецца праз WinRM да windows хасту.
- Ansible запускае powershell скрыпт.
- Powershell скрыпт стварае новую ВМ.
- Сродкамі Hyper-V/ScVMM пры стварэнні вм у гасцявой АС наладжваецца hostname.
- ВМ пры абнаўленне DHCP lease адсылае свой hostname.
- Штатная інтэграцыя ddns & dhcp на баку Domain Controller наладжвае DNS запіс.
- Можна дадаваць ВМ у інвентары і наладжваць яе Ansible.
3. Create VM template
Тут не сталі нічога вынаходзіць - узялі packer.
- У git рэпазітар складаем канфіг packer, kickstart.
- Наладжваем спецыяльны jenkins slave з hyper-v і Packer.
- Ствараем job, наладжваем Jenkins.
Як працуе гэты звязак:
- Packer стварае пустую ВМ, падчапляе ISO.
- ВМ загружаецца, Packer ўводзіць у загрзучик каманду выкарыстоўваць наш kickstart файл з дыскеты ці http.
- Запускаецца anaconda з нашым канфігам, робіцца першасная настройка АС.
- Packer чакае даступнасці ВМ.
- Packer ўнутры ВМ запускае ansible у лакальным рэжыме.
- Ansible выкарыстоўваючы роўна тыя ж ролі што за крок № 1 адпрацоўвае.
- Packer экспартуе шаблон ВМ.
Дзень №75: Рэфактарым дамоўленасці не ломячы = Test ansible + Testkitchen
Зафіксаваць дамоўленасці ў кодзе можа быць нядосыць. Бо калі ў паднаготнай працэсе ты захочаш нешта памяняць - ты можаш нешта зламаць. Таму ў выпадку інфраструктуру з'яўляецца тэсціраванне гэтай самай інфраструктуры. Што б сінхранізаваць веды ў рамках каманды сталі тэсціраваць Ansible ролі. Не буду паглыбляць т.я. ёсць артыкул якія апісваюць падзеі ў той момант часу (спойлер гэта быў не фінальны варыянт і пазней усё стала складаней ).
Дзень №130: А можа CentOS+ansible не патрэбен? можа openshift?
Трэба разумець, што працэс унясення інфраструктуры быў не адзіным і былі пабочныя падпраекты. Напрыклад, прыйшоў запыт на запуск нашага прыкладання ў openshift і гэта вылілася ў даследаванні не на адзін тыдзень што затармазіла працэс пераезду. Вынікам аказалася, што openshift не закрывае ўсіх патрэбаў, неабходна рэальнае жалеза, ну ці хаця б магчымасць гуляцца з ядром.
Дзень №170: Openshift не падыходзіць, рызыкнем з Windows Azure Pack?
Hyper-V не вельмі прыязны, SCVMM не робіць яго моцна лепш. Але ёсць такая штука Windows Azure Pack, якая з'яўляецца надбудовай над SCVMM і мімікруе пад Azure. Але ў рэальнасці прадукт выглядае закінутым: дакументацыя з бітымі спасылкамі і вельмі бедная. Але ў рамках даследавання варыянтаў спрашчэння жыцця нашага аблокі глядзелі і на яго таксама.
Дзень №250: Windows Azure Pack не вельмі. Застаемся на SCVMM
Windows Azure Pack выглядаў шматабяцальным, але было вырашана не прыўносіць WAP c яго складанасцямі ў сістэму дзеля непатрэбных фіч і засталіся на SCVMM.
Дзень №360: Ямо слана па частках
Толькі праз год была гатова платформа куды пераязджаць і пачаўся працэс пераезду. Для гэтага была пастаўлена SMART задача. Выпісалі ўсе ВМ і пачалі па адной разбірацца з канфігурацыяй, апісваць яе на Ansible, пакрываць цестамі.
Дзень №450: Якая сістэма атрымалася?
Сам працэс не цікавы. Ён руцінны, можна адзначыць, што большасць канфігурацый былі адносна простымі або ізаморфнымі і па прынцыпе Парэта 80% канфігурацый вам запатрабавала 20% часу. Па тым жа прынцыпу 80% часу спатрэбілася на падрыхтоўку пераезду і толькі 20% на сам пераезд.
Дзень №540: Фінал
Што ж адбылося за 18 месяцаў?
- Дамоўленасці сталі кодам.
- Ручная праца -> Механізацыя -> Аўтаматызацыя.
сувязі
Крыніца: habr.com