Жаңа жыл жақындап қалды. Елдің түкпір-түкпіріндегі балалар Аяз атаға хат жіберіп немесе өздеріне сыйлық жасап үлгерді, ал олардың негізгі орындаушысы, ірі сауда орындарының бірі сатылымға апотеозға дайындалды. Желтоқсан айында оның деректер орталығына жүктеме бірнеше есе артады. Сондықтан компания дата орталығын жаңартып, қызмет ету мерзімі біткен жабдықтың орнына бірнеше ондаған жаңа серверлерді пайдалануға беру туралы шешім қабылдады. Бұл ертегіні бұралған снежинкалар фонында аяқтайды және триллер басталады.
Жабдық сатылым шыңына дейін бірнеше ай бұрын сайтқа келді. Операциялық қызмет, әрине, оларды өндірістік ортаға енгізу үшін серверлерде қалай және нені конфигурациялау керектігін біледі. Бірақ біз мұны автоматтандырып, адам факторын жоюымыз керек еді. Сонымен қатар, серверлер компания үшін маңызды болып табылатын SAP жүйелерін көшіру алдында ауыстырылды.
Жаңа серверлерді іске қосу қатаң түрде белгіленген мерзімге байланысты болды. Ал оны жылжыту миллиардтаған сыйлықтың жөнелтілуіне де, жүйелердің миграциясына да қауіп төндірді. Тіпті Аяз Ата мен Аяз атадан тұратын команда да күнді өзгерте алмады - SAP жүйесін қойманы басқаруға жылына бір рет қана беруге болады. 31 желтоқсан мен 1 қаңтар аралығында бөлшек саудагердің жалпы көлемі 20 футбол алаңы бар үлкен қоймалары 15 сағатқа жұмысын тоқтатады. Бұл жүйені жылжытуға арналған жалғыз уақыт кезеңі. Серверлерді енгізу кезінде бізде қателік орын болмады.
Ашық айтайын: менің әңгімем біздің команда қолданатын құралдар мен конфигурацияны басқару процесін көрсетеді.
Конфигурацияны басқару кешені бірнеше деңгейден тұрады. Негізгі компоненті CMS жүйесі болып табылады. Өнеркәсіптік пайдалануда деңгейлердің бірінің болмауы сөзсіз жағымсыз кереметтерге әкеледі.
ОЖ орнатуды басқару
Бірінші деңгей – физикалық және виртуалды серверлерде операциялық жүйелерді орнатуды басқару жүйесі. Ол адам факторын жоя отырып, негізгі ОЖ конфигурацияларын жасайды.
Осы жүйені пайдалана отырып, біз одан әрі автоматтандыру үшін қолайлы ОЖ бар стандартты сервер данасын алдық. «Құю» кезінде олар жергілікті пайдаланушылардың ең аз жиынтығын және жалпыға қолжетімді SSH кілттерін, сондай-ақ жүйелі ОЖ конфигурациясын алды. Біз серверлерді CMS арқылы басқаруға кепілдік бердік және ОЖ деңгейінде «төменде» тосынсыйлар болмайтынына сенімді болдық.
Орнатуды басқару жүйесі үшін «максималды» тапсырма серверлерді BIOS/микробағдарлама деңгейінен ОЖ деңгейіне дейін автоматты түрде конфигурациялау болып табылады. Мұнда көп нәрсе жабдық пен орнату тапсырмаларына байланысты. Гетерогенді жабдық үшін сіз қарастыра аласыз . Егер барлық жабдық бір жеткізушіден болса, онда көбінесе дайын басқару құралдарын (мысалы, HP ILO күшейткіші, DELL OpenManage және т.б.) пайдалану ыңғайлы болады.
ОЖ-ны физикалық серверлерге орнату үшін біз операциялық қызметпен келісілген орнату профильдерінің жиынтығын анықтайтын белгілі Cobbler пайдаландық. Инфрақұрылымға жаңа серверді қосқанда, инженер сервердің MAC мекенжайын Cobbler бағдарламасындағы қажетті профильге байланыстырды. Желі арқылы бірінші рет жүктелген кезде сервер уақытша мекенжай мен жаңа ОЖ алды. Содан кейін ол мақсатты VLAN/IP мекенжайына ауыстырылды және сол жерде жұмысын жалғастырды. Иә, VLAN желісін өзгерту уақытты қажет етеді және үйлестіруді қажет етеді, бірақ ол серверді өндірістік ортада кездейсоқ орнатудан қосымша қорғауды қамтамасыз етеді.
Біз HashiСorp Packer көмегімен дайындалған үлгілер негізінде виртуалды серверлерді жасадық. Мұның себебі бірдей болды: ОЖ орнату кезінде мүмкін болатын адам қателерінің алдын алу. Бірақ физикалық серверлерден айырмашылығы, Packer PXE, желіні жүктеу және VLAN өзгерістері қажеттілігін жояды. Бұл виртуалды серверлерді жасауды жеңілдетеді және жеңілдетеді.
Күріш. 1. Операциялық жүйелерді орнатуды басқару.
Құпияларды басқару
Кез келген конфигурацияны басқару жүйесі қарапайым пайдаланушылардан жасырылуы керек, бірақ жүйелерді дайындау үшін қажет деректерді қамтиды. Бұл жергілікті пайдаланушылар мен қызмет тіркелгілеріне арналған құпия сөздер, сертификат кілттері, әртүрлі API токендері және т.б. Олар әдетте «құпиялар» деп аталады.
Егер сіз осы құпияларды қайда және қалай сақтау керектігін басынан бастап анықтамасаңыз, онда ақпараттық қауіпсіздік талаптарының ауырлығына байланысты сақтаудың келесі әдістері болуы мүмкін:
- тікелей конфигурацияны басқару кодында немесе репозиторийдегі файлдарда;
- мамандандырылған конфигурацияны басқару құралдарында (мысалы, Ansible Vault);
- CI/CD жүйелерінде (Jenkins/TeamCity/GitLab/т.б.) немесе конфигурацияны басқару жүйелерінде (Ansible Tower/Ansible AWX);
- құпияларды «қолмен» де беруге болады. Мысалы, олар белгіленген жерде орналасады, содан кейін оларды конфигурацияны басқару жүйелері пайдаланады;
- жоғарыда аталғандардың әртүрлі комбинациясы.
Әрбір әдістің өзіндік кемшіліктері бар. Ең бастысы - құпияларға қол жеткізу саясатының жоқтығы: белгілі бір құпияларды кім пайдалана алатынын анықтау мүмкін емес немесе қиын. Тағы бір кемшілігі – қолжетімділік аудитінің және толық өмірлік циклдің болмауы. Мысалы, кодта және бірқатар байланысты жүйелерде жазылған ашық кілтті қалай тез ауыстыруға болады?
Біз HashiCorp Vault орталықтандырылған құпия қоймасын қолдандық. Бұл бізге мүмкіндік берді:
- құпияларды сақтаңыз. Олар шифрланған және біреу Vault дерекқорына қол жеткізсе де (мысалы, оны сақтық көшірмеден қалпына келтіру арқылы), олар онда сақталған құпияларды оқи алмайды;
- құпияларға қол жеткізу саясатын ұйымдастырады. Пайдаланушылар мен қолданбаларға тек оларға «бөлінген» құпиялар ғана қолжетімді;
- құпияға қол жеткізу аудиті. Құпиялары бар кез келген әрекеттер Vault аудит журналында жазылады;
- құпиялармен жұмыс істеудің толыққанды «өмірлік циклін» ұйымдастыру. Оларды жасауға, жоюға, жарамдылық мерзімін белгілеуге және т.б.
- құпияларға қол жеткізуді қажет ететін басқа жүйелермен оңай біріктіру;
- сонымен қатар түпкілікті шифрлауды, ОЖ мен деректер базасына бір реттік парольдерді, уәкілетті орталықтардың сертификаттарын және т.б.
Енді орталық аутентификация және авторизация жүйесіне көшейік. Онсыз да жасауға болатын еді, бірақ көптеген байланысты жүйелерде пайдаланушыларды басқару тым тривиальды емес. LDAP қызметі арқылы аутентификация мен авторизацияны конфигурацияладық. Әйтпесе, Vault пайдаланушылар үшін аутентификация таңбалауыштарын үздіксіз шығарып, қадағалап отыруы керек еді. Ал пайдаланушыларды жою және қосу «Мен бұл пайдаланушы тіркелгісін барлық жерде жасадым/жойдым ба?» деген квестке айналады.
Біз жүйеге тағы бір деңгейді қосамыз: құпияларды басқару және орталық аутентификация/авторизация:
Күріш. 2. Құпияларды басқару.
Конфигурацияны басқару
Біз өзегін – CMS жүйесіне жеттік. Біздің жағдайда бұл Ansible және Red Hat Ansible AWX комбинациясы.
Ansible орнына Chef, Puppet, SaltStack қолдануға болады. Біз Ansible-ді бірнеше критерийлер негізінде таңдадық.
- Біріншіден, бұл жан-жақтылық. Басқаруға арналған дайын модульдер жинағы . Егер сізде бұл жеткіліксіз болса, GitHub және Galaxy арқылы іздеуге болады.
- Екіншіден, басқарылатын жабдыққа агенттерді орнатудың және қолдаудың, олардың жүктемеге кедергі келтірмейтінін дәлелдеудің және «бетбелгілердің» жоқтығын растаудың қажеті жоқ.
- Үшіншіден, Ansible кіруге кедергісі төмен. Құзыретті инженер өніммен жұмыс істеудің бірінші күнінде жұмыс кітабын жазады.
Бірақ Ansible тек өндірістік ортада бізге жеткіліксіз болды. Әйтпесе, кіруді шектеу және әкімшілердің әрекеттерін тексеру кезінде көптеген мәселелер туындауы мүмкін. Қол жеткізуді қалай шектеуге болады? Өйткені, әрбір бөлімге серверлердің «өз» жиынтығын басқару (оқыңыз: Ansible ойын кітабын іске қосу) қажет болды. Белгілі бір қызметкерлерге нақты Ansible ойын кітаптарын іске қосуға қалай рұқсат беруге болады? Немесе Ansible іске қосылған серверлер мен жабдықтарда көптеген жергілікті білімді орнатпай, ойын кітабын кім іске қосқанын қалай бақылауға болады?
Мұндай мәселелердің ең көп бөлігін Red Hat шешеді , немесе оның ашық бастапқы бастапқы жобасы . Сондықтан біз оны тұтынушы үшін таңдадық.
Біздің CMS жүйеміздің портретіне тағы бір түрту. Ansible ойын кітабы код репозиторийін басқару жүйелерінде сақталуы керек. Бізде бар .
Сонымен, конфигурациялардың өзі Ansible/Ansible AWX/GitLab комбинациясы арқылы басқарылады (3-суретті қараңыз). Әрине, AWX/GitLab бір аутентификация жүйесімен біріктірілген, ал Ansible ойын кітабы HashiCorp Vault бағдарламасымен біріктірілген. Конфигурациялар өндірістік ортаға тек Ansible AWX арқылы кіреді, онда барлық «ойын ережелері» көрсетілген: кім нені конфигурациялай алады, CMS конфигурациясын басқару кодын қайдан алуға болады және т.б.
Күріш. 3. Конфигурацияны басқару.
Сынақты басқару
Біздің конфигурациямыз код түрінде ұсынылған. Сондықтан біз бағдарламалық жасақтаманы әзірлеушілер сияқты ережелермен ойнауға мәжбүрміз. Бізге конфигурация кодын әзірлеу, үздіксіз тестілеу, жеткізу және өндірістік серверлерге қолдану процестерін ұйымдастыру қажет болды.
Егер бұл дереу орындалмаса, конфигурация үшін жазылған рөлдер қолдауды және өзгертуді тоқтатады немесе өндірісте іске қосылуын тоқтатады. Бұл ауырсынудың емі белгілі және бұл жобада өзін дәлелдеді:
- әрбір рөл бірлік сынақтарымен қамтылған;
- конфигурацияларды басқаратын кодта кез келген өзгеріс болған кезде сынақтар автоматты түрде орындалады;
- конфигурацияны басқару кодындағы өзгерістер барлық сынақтар мен кодты қарап шығудан сәтті өткеннен кейін ғана өндіріс ортасына шығарылады.
Кодты әзірлеу және конфигурацияны басқару тыныш және болжамды болды. Үздіксіз тестілеуді ұйымдастыру үшін біз GitLab CI/CD құралдар жинағын қолдандық және алдық .
Конфигурацияны басқару кодында өзгеріс болған кезде, GitLab CI/CD Molecule шақырады:
- ол код синтаксисін тексереді,
- Docker контейнерін көтереді,
- жасалған контейнерге өзгертілген кодты қолданады,
- идемпотенттілікке қатысты рөлді тексереді және осы код үшін сынақтарды іске қосады (мұндағы түйіршіктілік маңызды рөл деңгейінде, 4-суретті қараңыз).
Біз Ansible AWX көмегімен конфигурацияларды өндірістік ортаға жеткіздік. Операция инженерлері алдын ала анықталған үлгілер арқылы конфигурация өзгерістерін қолданды. AWX GitLab негізгі филиалынан кодтың соңғы нұсқасын әр пайдаланған сайын дербес «сұрады». Осылайша, біз өндірістік ортада тексерілмеген немесе ескірген кодты пайдалануды болдырмас едік. Әрине, код тестілеуден, қараудан және мақұлданғаннан кейін ғана негізгі филиалға енді.
Күріш. 4. GitLab CI/CD-де рөлдерді автоматты түрде тестілеу.
Өндірістік жүйелердің жұмысына байланысты мәселе де бар. Шынайы өмірде тек CMS коды арқылы конфигурацияға өзгертулер енгізу өте қиын. Төтенше жағдайлар инженер кодты өңдеуді, тестілеуді, бекітуді және т.
Нәтижесінде қолмен жасалған өзгертулерге байланысты бір типті жабдықта конфигурацияда сәйкессіздіктер пайда болады (мысалы, sysctl параметрлері HA кластер түйіндерінде басқаша конфигурацияланады). Немесе жабдықтағы нақты конфигурация CMS кодында көрсетілгеннен ерекшеленеді.
Сондықтан, үздіксіз тестілеуден басқа, біз конфигурациядағы сәйкессіздіктерге өндірістік орталарды тексереміз. Біз ең қарапайым опцияны таңдадық: CMS конфигурация кодын «құрғақ іске қосу» режимінде, яғни өзгерістерді қолданбай, бірақ жоспарланған және нақты конфигурация арасындағы барлық сәйкессіздіктер туралы хабарлау арқылы іске қосу. Біз мұны өндірістік серверлердегі «—тексеру» опциясы бар барлық Ansible оқу кітаптарын мерзімді түрде іске қосу арқылы жүзеге асырдық. Әдеттегідей, Ansible AWX ойын кітабын іске қосуға және оны жаңартуға жауапты (5-суретті қараңыз):
Күріш. 5. Ansible AWX конфигурациясының сәйкессіздіктерін тексереді.
Тексерулерден кейін AWX әкімшілерге сәйкессіздік туралы есепті жібереді. Олар проблемалық конфигурацияны зерттейді, содан кейін оны реттелген ойын кітаптары арқылы түзетеді. Біз өндірістік ортадағы конфигурацияны осылай сақтаймыз және CMS әрқашан жаңартылып, үндестіріледі. Бұл CMS коды «өндіріс» серверлерінде пайдаланылған кезде жағымсыз «ғажайыптарды» жояды.
Бізде қазір Ansible AWX/GitLab/Молекуладан тұратын маңызды сынақ қабаты бар (6-сурет).
Күріш. 6. Тесттерді басқару.
Қиын ба? Дауласпаймын. Бірақ конфигурацияны басқарудың мұндай кешені сервер конфигурациясын автоматтандыруға қатысты көптеген сұрақтарға жан-жақты жауап болды. Енді сатушының стандартты серверлері әрқашан қатаң анықталған конфигурацияға ие. CMS, инженерден айырмашылығы, қажетті параметрлерді қосуды, пайдаланушыларды жасауды және ондаған немесе жүздеген қажетті параметрлерді орындауды ұмытпайды.
Бүгінгі күні серверлер мен орталардың параметрлерінде «құпия білім» жоқ. Барлық қажетті мүмкіндіктер ойын кітапшасында көрсетілген. Енді шығармашылық пен түсініксіз нұсқаулар жоқ: «Оны кәдімгі Oracle сияқты орнатыңыз, бірақ сізге бірнеше sysctl параметрлерін көрсету және қажетті UID идентификаторы бар пайдаланушыларды қосу қажет. Операциядағы жігіттерден сұраңыз, олар біледі«.
Конфигурациядағы сәйкессіздіктерді анықтау және оларды белсенді түрде түзету мүмкіндігі жан тыныштығын қамтамасыз етеді. Конфигурацияны басқару жүйесі болмаса, бұл әдетте басқаша көрінеді. Мәселелер бір күнге дейін өндіріске «атылғанша» жинақталады. Содан кейін дебифинг жүргізіледі, конфигурациялар тексеріледі және түзетіледі. Және цикл қайтадан қайталанады
Әрине, біз серверлерді іске қосуды бірнеше күннен сағатқа дейін жылдамдаттық.
Жаңа жыл қарсаңында балалар сыйлықтарды қуанышпен ашып жатқанда, ал ересектер қоңырау соғылып, тілектерін айтып жатқанда, біздің инженерлер SAP жүйесін жаңа серверлерге көшірді. Тіпті Аяз ата да ең жақсы ғажайыптар жақсы дайындалғандар деп айтады.
PS Біздің команда тұтынушылардың конфигурацияны басқару мәселелерін мүмкіндігінше оңай шешкісі келетінін жиі кездестіреді. Ең дұрысы, сиқырлы сияқты - бір құралмен. Бірақ өмірде бәрі күрделірек (иә, күміс оқтар қайтадан жеткізілмеді): тұтынушы командасына ыңғайлы құралдарды пайдаланып, бүкіл процесті жасау керек.
Авторы: Сергей Артемов, бөлім сәулетшісі «Jet Infosystems»
Ақпарат көзі: www.habr.com