Егер сіздің АТ-инфрақұрылымыңыз тым тез өсетін болса, сіз ерте ме, кеш пе таңдауға тап боласыз: оны қолдау үшін адам ресурстарын сызықты түрде көбейту немесе автоматтандыруды бастау. Белгілі бір уақытқа дейін біз бірінші парадигмада өмір сүрдік, содан кейін Инфраструктура-кодқа дейінгі ұзақ жол басталды.
Әрине, NSPK стартап емес, бірақ мұндай атмосфера компанияның алғашқы жылдарында болды және бұл өте қызықты жылдар болды. Менің атым , Мен 10 жылдан астам қолжетімділік талаптары жоғары Linux инфрақұрылымына қолдау көрсетіп келемін. Ол NSPK командасына 2016 жылдың қаңтарында қосылды және, өкінішке орай, компанияның өмір сүруінің ең басын көрмеді, бірақ үлкен өзгерістер кезеңіне келді.
Жалпы, біздің ұжым компанияға 2 өнім жеткізеді деп айта аламыз. Біріншісі – инфрақұрылым. Пошта жұмыс істеуі керек, DNS жұмыс істеуі керек және домен контроллері бұзылмауы керек серверлерге кіруге мүмкіндік беруі керек. Компанияның IT ландшафты өте үлкен! Бұл бизнес пен миссия үшін маңызды жүйелер, кейбіреулері үшін қолжетімділік талаптары 99,999. Екінші өнім - серверлердің өздері, физикалық және виртуалды. Қолданыстағыларды бақылап отыру керек, ал жаңалары көптеген бөлімдерден тұтынушыларға үнемі жеткізілуі керек. Бұл мақалада мен сервердің өмірлік цикліне жауап беретін инфрақұрылымды қалай дамытқанымызға тоқталғым келеді.
Жолды бастау
Саяхатымыздың басында біздің технологиялық стек келесідей болды:
ОЖ CentOS 7
FreeIPA домен контроллері
Автоматтандыру - Ansible(+Tower), Cobbler
Мұның бәрі бірнеше деректер орталықтарына таралған 3 доменде орналасқан. Бір деректер орталығында кеңсе жүйелері мен сынақ алаңдары, қалғандарында PROD бар.
Бір уақытта серверлерді жасау келесідей болды:
VM үлгісінде CentOS минималды және қажетті минимум дұрыс /etc/resolv.conf сияқты, қалғаны Ansible арқылы келеді.
CMDB - Excel.
Егер сервер физикалық болса, онда виртуалды машинаны көшірудің орнына оған ОЖ Cobbler көмегімен орнатылды - мақсатты сервердің MAC мекенжайлары Cobbler конфигурациясына қосылады, сервер DHCP арқылы IP мекенжайын алады, содан кейін ОЖ қосылады.
Алдымен біз Cobbler-де конфигурацияны басқарудың қандай да бір түрін жасауға тырыстық. Бірақ уақыт өте келе бұл басқа деректер орталықтарына да, VM дайындауға арналған Ansible кодына да конфигурациялардың тасымалдануымен байланысты проблемаларды әкеле бастады.
Сол кезде көпшілігіміз Ansible-ді Bash-тың ыңғайлы кеңейтімі ретінде қабылдадық және shell және sed қолданатын дизайнды үнемдемедік. Жалпы Bashsible. Бұл, сайып келгенде, егер ойын кітабы қандай да бір себептермен серверде жұмыс істемесе, серверді жою, ойын кітабын жөндеу және оны қайта іске қосу оңайырақ болды. Негізінде сценарийлердің нұсқалары, конфигурациялардың тасымалдануы болмады.
Мысалы, біз барлық серверлердегі кейбір конфигурацияларды өзгерткіміз келді:
- Біз логикалық сегменттегі/деректер орталығындағы бар серверлердегі конфигурацияны өзгертеміз. Кейде бір күнде емес - қол жетімділік талаптары және үлкен сандар заңы барлық өзгерістерді бірден қолдануға мүмкіндік бермейді. Ал кейбір өзгерістер ықтимал деструктивті болып табылады және бір нәрсені қайта іске қосуды талап етеді - қызметтерден бастап ОЖ-ның өзіне дейін.
- Оны Ansible бағдарламасында түзету
- Біз оны Cobbler бағдарламасында түзетеміз
- Әрбір логикалық сегмент/деректер орталығы үшін N рет қайталаңыз
Барлық өзгерістер біркелкі жүруі үшін көптеген факторларды ескеру қажет болды және өзгерістер үнемі болып тұрады.
- Ансибилді кодты, конфигурация файлдарын қайта өңдеу
- Ішкі озық тәжірибелерді өзгерту
- Оқиғаларды/аварияларды талдау нәтижелері бойынша өзгерістер
- Ішкі және сыртқы қауіпсіздік стандарттарын өзгерту. Мысалы, PCI DSS жыл сайын жаңа талаптармен жаңартылып отырады
Инфрақұрылымның өсуі және саяхаттың басталуы
Серверлердің/логикалық домендердің/деректер орталықтарының саны өсті және олармен бірге конфигурациялардағы қателер саны өсті. Бір сәтте біз конфигурацияны басқаруды дамыту қажет үш бағытқа келдік:
- Автоматтандыру. Қайталанатын операцияларда адам қателігінен мүмкіндігінше аулақ болу керек.
- Қайталану мүмкіндігі. Инфрақұрылымды болжауға болатын болса, оны басқару оңайырақ. Серверлердің конфигурациясы және оларды дайындау құралдары барлық жерде бірдей болуы керек. Бұл өнім топтары үшін де маңызды - сынақтан кейін қолданба сынақ ортасына ұқсас конфигурацияланған өндірістік ортада аяқталатынына кепілдік беру керек.
- Конфигурацияны басқаруға өзгертулер енгізудің қарапайымдылығы мен ашықтығы.
Бірнеше құралдарды қосу қалды.
Біз GitLab CE-ті код репозиторийі ретінде таңдадық, ең бастысы оның кірістірілген CI/CD модульдері үшін.
Құпиялар қоймасы - Hashicorp қоймасы, соның ішінде. тамаша API үшін.
Тестілеу конфигурациялары және маңызды рөлдер – Molecule+Testinfra. Ансибилді митогенге қосылсаңыз, сынақтар әлдеқайда жылдам өтеді. Сонымен бірге, біз өзіміздің CMDB және автоматты орналастыру үшін оркестрді жаза бастадық (Cobbler жоғарыдағы суретте), бірақ бұл менің әріптесім және осы жүйелердің негізгі әзірлеушісі болашақта айтатын мүлдем басқа оқиға.
Біздің таңдау:
Молекула + Testinfra
Ansible + Tower + AWX
Серверлер әлемі + DITNET (жеке әзірлеу)
Өтірік
Gitlab + GitLab жүгіргіші
Hashicorp қоймасы
Айтпақшы, ансибилді рөлдер туралы. Бастапқыда бір ғана болды, бірақ бірнеше рефакторингтерден кейін олардың саны 17 болды.Мен монолитті кейін бөлек іске қосуға болатын идемпотентті рөлдерге бөлуді ұсынамын, қосымша тегтерді қосуға болады. Біз рөлдерді функционалдылық бойынша бөлдік - желі, журнал жүргізу, пакеттер, аппараттық құрал, молекула және т.б. Жалпы, біз төмендегі стратегияны ұстандық. Мен бұл жалғыз шындық деп талап етпеймін, бірақ ол біз үшін жұмыс істеді.
- Серверлерді «алтын кескіннен» көшіру – зұлымдық!Негізгі кемшілігі - сіз қазір кескіндердің қандай күйде екенін білмейсіз және барлық өзгерістер барлық виртуализация фермаларындағы барлық кескіндерге келеді.
- Әдепкі конфигурация файлдарын минимумға дейін пайдаланыңыз және негізгі жүйелік файлдарға жауапты басқа бөлімдермен келісіңіз, мысалы:
- /etc/sysctl.conf бос қалдырыңыз, параметрлер тек /etc/sysctl.d/ ішінде болуы керек. Бір файлдағы әдепкі, басқа файлдағы қолданба үшін теңшелетін.
- Жүйе бірліктерін өңдеу үшін қайта анықтау файлдарын пайдаланыңыз.
- Барлық конфигурациялардың үлгісін жасаңыз және оларды толығымен қосыңыз; мүмкін болса, ойын кітаптарында sed немесе оның аналогтары жоқ
- Конфигурацияны басқару жүйесінің кодын қайта өңдеу:
- Тапсырмаларды логикалық нысандарға бөліп, монолитті рөлдерге қайта жазыңыз
- Линтерлерді қолданыңыз! Ansible-lint, yaml-lint және т.б
- Тәсіліңізді өзгертіңіз! Қиындық жоқ. Жүйенің күйін сипаттау қажет
- Барлық Ansible рөлдері үшін молекулада сынақтар жазып, күніне бір рет есептерді жасау керек.
- Біздің жағдайда сынақтарды дайындағаннан кейін (оның ішінде 100-ден астам) шамамен 70000 XNUMX қате анықталды. Оны жөндеуге бірнеше ай қажет болды.
Біздің жүзеге асыру
Сонымен, анссильді рөлдер дайын болды, шаблондар жасалды және линтерлер арқылы тексерілді. Тіпті гиттер де барлық жерде өсіріледі. Бірақ кодты әртүрлі сегменттерге сенімді жеткізу мәселесі ашық қалды. Біз сценарийлермен синхрондауды шештік. Мынадай көрінеді:
Өзгеріс келгеннен кейін CI іске қосылады, сынақ сервері жасалады, рөлдер шығарылады және молекула арқылы сыналады. Егер бәрі дұрыс болса, код өнім тармағына өтеді. Бірақ біз жаңа кодты құрылғыдағы бар серверлерге қолданбаймыз. Бұл біздің жүйелеріміздің жоғары қолжетімділігі үшін қажет тығынның бір түрі. Ал инфрақұрылым үлкен болған кезде, үлкен сандар заңы күшіне енеді - бұл өзгерістің зиянсыз екеніне сенімді болсаңыз да, бұл ауыр зардаптарға әкелуі мүмкін.
Сондай-ақ серверлерді құрудың көптеген нұсқалары бар. Біз пайдаланушы Python сценарийлерін таңдадық. Ал CI ansible үшін:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Міне, осыған жеттік, жүйе өмір сүріп, дамып келеді.
- 17 Серверді орнатуға арналған жауапты рөлдер. Рөлдердің әрқайсысы жеке логикалық тапсырманы шешуге арналған (тіркеу, аудит, пайдаланушыны авторизациялау, бақылау және т.б.).
- Рөлдік тестілеу. Molecule + TestInfra.
- Жеке даму: CMDB + Оркестр.
- Серверді құру уақыты ~30 минут, автоматтандырылған және іс жүзінде тапсырмалар кезегінен тәуелсіз.
- Барлық сегменттердегі инфрақұрылымның бірдей күйі/атауы – ойын кітаптары, репозиторийлер, виртуализация элементтері.
- Стандартқа сәйкессіздіктер туралы есептерді құру арқылы сервер күйін күнделікті тексеру.
Менің әңгімем саяхаттың басында тұрғандарға пайдалы болады деп сенемін. Сіз қандай автоматтандыру стекін пайдаланасыз?
Ақпарат көзі: www.habr.com