Нацыянальная інфармацыйная служба спадарожнікавых дадзеных аб навакольным асяроддзі (NESDIS) на 35% знізіла свае выдаткі на кіраванне канфігурацыяй Red Hat Enterprise Linux (RHEL), перайшоўшы з Puppet Enterprise на Ansible Tower. У гэтым відэа катэгорыі "як мы гэта зрабілі" сістэмны інжынер Майкл Рау абгрунтоўвае выкананне гэтай міграцыі, дзеліцца карыснымі парадамі і вопытам, атрыманым у выніку пераходу з адной SCM на іншую.
З гэтага відэа вы даведаецеся:
- як абгрунтаваць кіраўніцтву мэтазгоднасць пераходу з Puppet Enterprise на Ansible Tower;
- якія стратэгіі выкарыстоўваць для максімальна плыўнага пераходу;
- парады па транскадаванні PE маніфестаў у Ansible Playbook;
- рэкамендацыі па аптымальнай усталёўцы Ansible Tower.
Вітаю ўсіх, мяне клічуць Майкл Рау, я старэйшы сістэмны інжынер кампаніі ActioNet, якая працуе на Нацыянальнае ўпраўленне акіянічных і атмасферных даследаванняў (NOAA) службы NESDIS. Сёння мы пагаворым пра абразанне радкоў - мой уласны досвед міграцыі з Puppet Enterprise на Ansible Tower. Тэма гэтай прэзентацыі складаецца ў тым, каб "зірнуць на мае шнары", якія засталіся пасля таго, як я здзейсніў гэты пераход у пачатку года. Я хачу расказаць, што даведаўся падчас гэтага працэсу. Так што калі вы возьмецеся за падобнае, выкарыстоўваючы мой досвед, то зможаце зрабіць пераход без лішняй працы.
Вы бачыце слайды, аналагічныя гэтаму, у пачатку кожнай прэзентацыі на Ansible Fest. На гэтым слайдзе выкладзена гісторыя аўтаматызацыі маёй кампаніі. Я не навічок у гэтай справе, таму што карыстаюся Puppet/Puppet Enterprise з 2007 года. Я пачаў працаваць з Ansible з 2016 года, і мяне, як мноства іншых карыстальнікаў гэтага прадукта, прыцягнула магчымасць "трукаў" з дапамогай каманднага радка і простыя сцэнары (playbooks). У канцы 2017 года я звярнуўся да свайго кіраўніцтва наконт сур'ёзных падстаў для пераходу на Ansible Tower. Праз хвіліну я раскажу аб прычынах, якія заахвоцілі мяне на гэты крок. Пасля атрымання згоды кіраўніцтва запатрабавалася яшчэ некалькі месяцаў, каб выканаць задуманае, і я ажыццявіў пераход у студзені-лютым гэтага года. Такім чынам, мы цалкам адмовіліся ад Puppet на карысць Ansible, і гэта вялікае справа.
Больш за ўсё ў Ansible мяне вабіць магчымасць пісаць і выкарыстоўваць ролі (roles) і сцэнары (playbooks). Ролі выдатна падыходзяць для стварэння розных, але ўзаемазлучаных задач (tasks) і размяшчэнні ўсіх дадзеных, якія адносяцца да гэтых задач, у адным месцы. Playbook - гэта сінтаксіс YAML, файл-сцэнар, які апісвае дзеянні для аднаго або некалькіх хастоў. Я расказваю пра гэтыя магчымасці карыстальнікам, у першую чаргу распрацоўшчыкам ПЗ. Ansible Tower дае магчымасць сказаць: "не, у вас няма доступу да абалонкі shell access, але я даю вам магчымасць запусціць усе працэсы Tower і перазагрузіць сэрвіс, калі гэта вам спатрэбіцца". Я распавяду вам аб працоўным асяроддзі і выкарыстоўваным намі абсталяванні.
Гэта федэральная LAN, 7 фізічных сайтаў, падлучаных праз хмарнае MPLS, 140 сервераў RHEL, 99% якіх віртуальныя (vSphere), апаратнае забеспячэнне SuperMicro, сеткавае сховішча NexentaStore, набор свіцей Cisco, Arista і Cumulus і сродкі уніфікаванага кіравання пагрозамі Fortinet UTM. .
Федэральная сетка азначае, што я мушу выкарыстоўваць усе сродкі абароны інфармацыі, прадугледжаныя заканадаўчымі актамі. Вы павінны мець на ўвазе, што Puppet Enterprise не падтрымлівае большую частку выкарыстоўванага ў нас абсталявання. Мы вымушаны выкарыстоўваць бюджэтнае апаратнае забеспячэнне, паколькі дзяржаўныя структуры маюць праблемы з фінансаваннем гэтага артыкула выдаткаў. Таму мы купляем жалеза класа SuperMicro і збіраем наша абсталяванне з асобных частак, тэхнічнае абслугоўванне якіх гарантавана ўрадавымі кантрактамі. Мы выкарыстоўваем Linux, і гэта адна з важных прычын пераходу на Ansible.
Наша гісторыя працы з Puppet такая.
У 2007 годзе мы мелі маленькую сетку з 20-25 вузлоў, у якой і разгарнулі Puppet. У асноўным гэтыя вузлы ўяўлялі сабой проста "скрынкі" RedHat. У 2010 годзе мы пачалі выкарыстоўваць вэб-інтэрфейс Puppet Dashboard для 45 вузлоў. Паколькі сетка працягвала пашырацца, у 2014 годзе мы перайшлі на PE 3.3, ажыццявіўшы поўны пераход з перапісваннем маніфесту для 75 вузлоў. Гэта прыйшлося зрабіць, таму што Puppet любіць мяняць правілы гульні, і ў дадзеным выпадку яны цалкам памянялі мову. Праз год, калі спынілася падтрымка 3-й версіі Puppet Enterprise, мы змушаныя былі міграваць на PE 2015.2. Прыйшлося зноў перапісаць маніфест пад новыя серверы і набыць ліцэнзію з запасам на 100 вузлоў, хоць на той момант у нас было ўсяго 85 вузлоў.
Прайшло ўсяго 2 гады, і нам зноў прыйшлося правесці вялікую працу па пераходзе на новую версію PE 2016.4/300. Мы купілі ліцэнзію на 130 вузлоў, маючы ўсяго 2015. Нам зноў прыйшлося ўносіць сур'ёзныя змены ў маніфест, таму што новая версія мовы мела сінтаксіс, адрозны ад мовы версіі XNUMX года. У выніку нашая SCM перайшла з сістэмы кантролю версій SVN на Bitbucket (Git). Такія былі нашы "ўзаемаадносіны" з Puppet.
Такім чынам, мне прыйшлося растлумачыць кіраўніцтву, чаму нам трэба пераходзіць на іншую SCM, выкарыстоўваючы наступныя аргументы. Першы - высокі кошт сэрвісу. Я размаўляў з рабятамі з RedHat, і яны сказалі, што кошт абслугоўвання сеткі з 300 вузлоў пры дапамозе Ansible Tower складае палову кошту Puppet Enterprise. Калі набыць яшчэ Ansible Engine, кошт будзе прыкладна аднолькавая, але пры гэтым вы атрымаеце нашмат больш функцый, чым у PE. Паколькі мы з'яўляемся дзяржаўнай кампаніяй, якая фінансуецца з федэральнага бюджэту, гэта даволі важкі аргумент.
Другі аргумент - гэта ўніверсальнасць. Puppet падтрымлівае толькі тое абсталяванне, на якім ёсць агент Puppet. Гэта значыць, што на ўсе скруткі трэба ўсталяваць агент, прычым ён павінен быць апошняй версіі. І калі частка вашых світак падтрымлівае адну версію, а частка - іншую, вам спатрэбіцца ўсталяваць на іх новую версію агента PE, каб усе яны маглі працаваць у адной сістэме SCM.
Сістэма Ansible Tower працуе па-іншаму, таму што ў яе няма ніякіх агентаў, але затое маюцца модулі, якія падтрымліваюць світкі Cisco і ўсе астатнія світкі. Гэта SCM падтрымлівае Qubes OS, Linux і 4.NET UTM. Ansible Tower таксама падтрымлівае кантролеры сеткавых сховішчаў NexentaStore, заснаваныя на ядры Illumos - open-source аперацыйнай сістэме на аснове Unix. Гэта вельмі невялікая падтрымка, але Ansible Tower усё роўна яе здзяйсняе.
Трэці аргумент, вельмі важны як для мяне, так і для нашай адміністрацыі, гэта прастата ў засваенні. Я на працягу 10 гадоў асвойваў модулі і код маніфестаў Puppet, але Ansible вывучыў на працягу тыдня, таму што з гэтай SCM нашмат прасцей працаваць. Калі вы запускаеце выкананыя файлы, вядома, калі вы не робіце гэтага без неабходнасці, то з імі працуюць разумныя і спагадныя апрацоўшчыкі. Сцэнары playbooks, заснаваныя на YAML, характарызуецца лёгкім вывучэннем і хуткасцю выкарыстання. Тыя, хто ніколі раней не чуў пра YAML, могуць проста прачытаць сцэнары і лёгка зразумець, як ен працуе.
Шчыра кажучы, Puppet нашмат ускладняе вашу працу як распрацоўніка, таму што заснаваны на выкарыстанні Puppet Master. Гэта адзіная машына, якая мае права мець зносіны з агентамі Puppet. Калі вы ўнеслі нейкія змены ў маніфест і жадаеце пратэставаць свой код, вы павінны перапісаць код для Puppet Master, гэта значыць наладзіць файл Puppet-майстра /etc/hosts для падлучэння ўсіх кліентаў і запусціць службу Puppet Server. Толькі пасля гэтага вы зможаце выпрабаваць працу сеткавага абсталявання на адным хасце. Гэта дастаткова балючая працэдура.
У Ansible усё нашмат прасцей. Усё, што трэба зрабіць - гэта распрацаваць код для машыны, якая мае магчымасць звязацца па пратаколе SSH з тэстоўваным хастом. З гэтым нашмат прасцей працаваць.
Наступны вялікі плюс Ansible Tower - гэта магчымасць задзейнічаць ужо наяўную ў вас сістэму падтрымкі і захаваць існуючую канфігурацыю абсталявання. Гэта SCM без якіх-небудзь дадатковых дзеянняў выкарыстоўвае ўсю наяўную інфармацыю аб вашай інфраструктуры і абсталяванні, віртуальных машынах, серверах і г.д. Яна можа мець зносіны з вашымі RH Satellite серверамі, калі такія маюцца, і дае вам такую інтэграцыю, якую вы ніколі не атрымаеце, працуючы з Puppet.
Яшчэ адной важнай рэччу з'яўляецца дэталёвы кантроль. Вы ведаеце, што Puppet з'яўляецца модульнай сістэмай, гэта кліент-сервернае дадатак, таму вы павінны вызначыць існуючыя аспекты працы ўсіх вашых машын у адным доўгім маніфесце. Пры гэтым стан кожнага асобнага элемента сістэмы трэба тэставаць кожныя паўгадзіны - гэта перыяд па змаўчанні. Вось як працуе Puppet.
Tower пазбаўляе вас ад гэтага. Вы можаце без абмежаванняў выконваць самыя розныя працэсы на самым розным абсталяванні, можаце рабіць асноўную працу, запускаць іншыя важныя працэсы, настройваць сістэму бяспекі, працаваць з базамі даных. Вы можаце рабіць усё тое, што ў Puppet Enterprise злучана з вызначанымі цяжкасцямі. Так, калі вы правялі наладу на адным хасце, спатрэбіцца час, каб змены ўступілі ў сілу на астатніх хастах. У Ansible усе змены ўступаюць у сілу адначасова.
Нарэшце, разгледзім модуль бяспекі. У Ansible Tower ён рэалізаваны проста ўзрушаюча, з вялікай дакладнасцю і дбайнасцю. Вы можаце прадастаўляць карыстальнікам доступ да канкрэтных службаў або да канкрэтных хастаў. Я раблю так са сваімі супрацоўнікамі, якія звыкнуліся працаваць на Windows, абмяжоўваючы ім доступ да абалонкі Linux. Я забяспечваю ім такі доступ да Tower, каб яны маглі выконваць толькі тую працу і запускаць толькі тыя службы, якія адносяцца да іх кампетэнцыі.
Давайце разгледзім рэчы, якія трэба прарабіць загадзя, каб аблегчыць пераход на Ansible Tower. У першую чаргу неабходна падрыхтаваць ваша абсталяванне. Калі нейкія элементы вашай інфраструктуры яшчэ адсутнічаюць у базе даных, іх трэба туды дадаць. Існуюць сістэмы, якія не змяняюць сваіх характарыстык і таму адсутнічаюць у БД Puppet, але калі вы не занясеце іх туды перад пераходам на Tower, то пазбавіцеся шэрагу пераваг. Гэта можа быць "брудная", папярэдняя БД, але яна павінна ўтрымоўваць у сабе звесткі аб усім наяўным у вас абсталяванні. Таму вам варта напісаць дынамічны скрыпт абсталявання, які аўтаматычна будзе ўносіць усе змены інфраструктуры ў базу дадзеных, тады Ansible будзе ведаць, якія хасты павінны быць у новай сістэме. Вам не трэба будзе паведамляць гэтай SCM, якія хасты вы дадалі і якіх хастоў больш не існуе, таму што ўсё гэта яна даведаецца аўтаматычна. Чым больш дадзеных будзе ў БД, тым карыснейшым і гнуткім будзе Ansible. Ён працуе так, як быццам проста счытвае з базы дадзеных штрых-код стану абсталявання.
Выдаткуйце некаторы час на знаёмства з працай каманднага радка ў Ansible. Запусціце якія-небудзь спецыяльныя каманды, каб праверыць працу скрыпту абсталявання, напішыце і запусціце якія-небудзь простыя, але карысныя сцэнары playbook, выкарыстоўвайце шаблоны Jinja2 там, дзе гэта дарэчы. Паспрабуйце напісаць ролю і сцэнар для комплекснага шматэтапнага працэсу, выкарыстоўваючы стандартную, часта сустракаемую канфігурацыю абсталявання. Пагуляйце з гэтымі рэчамі, пратэстуйце, як гэта працуе. Такім чынам вы навучыцеся працаваць з інструментамі для стварэння бібліятэк, якія выкарыстоўваюцца ў Tower. Я ўжо казаў, што ў мяне падрыхтоўка да пераходу заняла каля 3-х месяцаў. Думаю, што абапіраючыся на мой досвед, вам атрымаецца прарабіць гэта хутчэй. Не лічыце гэты час страчаным, паколькі пазней вы адчуеце ўсе перавагі праведзенай працы.
Далей трэба вырашыць, чаго вы чакаеце ад Ansible Tower, што менавіта гэтая сістэма павінна вам зрабіць.
Ці трэба вам разгортванне сістэмы на пустым абсталяванні, на пустых віртуальных машынах? Ці вы хочаце захаваць зыходныя ўмовы працы і наладкі існуючага абсталявання? Гэта вельмі важны аспект для працы дзяржаўных кампаній, таму вы павінны быць упэўнены, што вам удасца здзейсніць міграцыю і разгарнуць Ansible на існуючай канфігурацыі. Вызначыце руцінныя адміністрацыйныя працэсы, якія жадаеце аўтаматызаваць. Высветліце, ці трэба вам разгортваць на новай сістэме спецыфічныя прыкладанні і сэрвісы. Складзіце спіс таго, што вы хочаце зрабіць, і расстаўце прыярытэты.
Затым прыступайце да напісання кода сцэнарыяў і роляў, якія забяспечаць выкананне запланаваных вамі задач. Аб'яднайце іх у Projects, лагічную калекцыю адпаведных сцэнарыяў playbooks. Кожны Project будзе ставіцца да асобнага рэпазітара Git або іншаму рэпазітару ў залежнасці ад таго, які менеджэр кода вы карыстаецеся. Вы можаце кіраваць сцэнарамі playbook і каталогамі playbook, змясціўшы іх уручную ў Project Base Path на серверы Tower, або змясціўшы playbook у любую сістэму кіравання зыходным кодам (SCM), якая падтрымліваецца Tower, уключаючы Git, Subversion, Mercurial і Red Hat Insights. Унутры аднаго Project вы можаце размясціць столькі сцэнарыяў, колькі захочаце. Напрыклад, я стварыў адзін базавы Project, у якім размясціў сцэнар для асноўных элементаў RedHat, сцэнар для асновы Linux, сцэнары для астатніх базавых паказчыкаў. Такім чынам, у адным праекце прысутнічалі самыя розныя ролі і сцэнары, якія кіраваліся з аднаго Git-рэпазітара.
Запускайце ўсе гэтыя штукі праз камандны радок, гэта добры спосаб праверкі іх працаздольнасці. Такім чынам вы падрыхтуецеся да ўстаноўкі Tower.
Давайце крыху пагаворым аб транскадаванні маніфеста Puppet, таму што я выдаткаваў на гэта шмат часу, пакуль не сцяміў, што сапраўды неабходна зрабіць.
Як я ўжо казаў, Puppet захоўвае ўсе наладкі і параметры абсталявання ў адным доўгім маніфесце, і ў гэтым маніфесце захоўваецца ўсё, што павінна рабіць гэтая SCM. Пры пераходзе вам не трэба запіхваць усе вашыя задачы ў адзін спіс, замест гэтага падумайце аб структуры новай сістэмы: ролях, сцэнарах, тэгах, групах і аб тым, што туды павінна ўвайсці. Некаторыя з аўтаномных элементаў сеткі трэба аб'яднаць у групы, для якіх можна стварыць сцэнары. Больш складаныя элементы інфраструктуры, якія задзейнічаюць вялікую колькасць рэсурсаў, у тым ліку ўключаюць у сябе аўтаномныя класы, можна аб'яднаць у ролях. Перад міграцыяй вам трэба з гэтым вызначыцца. Калі вы ствараеце аб'ёмныя ролі ці сцэнары, якія не змяшчаюцца на адным экране, вам варта выкарыстоўваць тэгі, каб мець магчымасць захопліваць асобныя часткі інфраструктуры.
18:00
Крыху рэкламы 🙂
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com