Ако ваша ИТ инфраструктура расте пребрзо, пре или касније ћете бити суочени са избором: линеарно повећати људске ресурсе који ће је подржавати или започети аутоматизацију. До неког тренутка смо живели у првој парадигми, а онда је почео дуг пут ка Инфраструктури-као-Коду.
Наравно, НСПК није стартап, али таква атмосфера је владала у компанији првих година постојања, а то су биле веома занимљиве године. Моје име је , Подржавам Линук инфраструктуру са захтевима високе доступности више од 10 година. Тиму НСПК се придружио у јануару 2016. године и, нажалост, није видео сам почетак постојања компаније, али је дошао у фазу великих промена.
Генерално, можемо рећи да наш тим испоручује 2 производа за компанију. Први је инфраструктура. Пошта би требало да ради, ДНС би требало да ради, а контролори домена би требало да вас пусте на сервере који не би требало да се сруше. ИТ пејзаж компаније је огроман! Ово су пословни и критични системи, а захтеви за доступност за неке су 99,999. Други производ су сами сервери, физички и виртуелни. Постојеће треба пратити, а нове редовно достављати купцима из многих одељења. У овом чланку желим да се фокусирам на то како смо развили инфраструктуру која је одговорна за животни циклус сервера.
Почетак путовање
На почетку нашег путовања, наш технолошки скуп је изгледао овако:
ОС ЦентОС 7
ФрееИПА контролери домена
Аутоматизација - Ансибле(+Торањ), Обућар
Све ово се налазило у 3 домена, распоређених у неколико центара података. У једном дата центру се налазе канцеларијски системи и тестне локације, у осталим је ПРОД.
Креирање сервера је у једном тренутку изгледало овако:
У ВМ шаблону, ЦентОС је минималан и захтевани минимум је као исправан /етц/ресолв.цонф, остало долази преко Ансибле-а.
ЦМДБ - Екцел.
Ако је сервер физички, онда је уместо копирања виртуелне машине на њега инсталиран ОС помоћу Цобблер-а - МАЦ адресе циљног сервера се додају у Цобблер конфигурацију, сервер добија ИП адресу преко ДХЦП-а, а затим ОС се додаје.
У почетку смо чак покушали да урадимо неку врсту управљања конфигурацијом у Цобблеру. Али током времена, ово је почело да доноси проблеме са преносивости конфигурација и на друге центре података и на Ансибле код за припрему ВМ-а.
У то време, многи од нас су доживљавали Ансибле као погодно проширење Басх-а и нису штедели на дизајну који користи схелл и сед. Овералл Басхсибле. Ово је на крају довело до чињенице да ако плаибоок из неког разлога није радио на серверу, било је лакше избрисати сервер, поправити плаибоок и поново га покренути. У суштини није било верзионисања скрипти, нити преносивости конфигурација.
На пример, желели смо да променимо неку конфигурацију на свим серверима:
- Мењамо конфигурацију на постојећим серверима у логичком сегменту/центру података. Понекад не у једном дану – захтеви за приступачност и закон великих бројева не дозвољавају да се све промене примењују одједном. А неке промене су потенцијално деструктивне и захтевају поновно покретање нечега – од услуга до самог ОС.
- Поправљам то у Ансиблеу
- Поправљамо у Цобблеру
- Поновите Н пута за сваки логички сегмент/центар података
Да би све промене текле глатко, било је потребно узети у обзир многе факторе, а промене се дешавају константно.
- Рефакторисање ансибле кода, конфигурационих датотека
- Промена најбоље интерне праксе
- Промене на основу резултата анализе инцидената/акцидената
- Промена безбедносних стандарда, како унутрашњих тако и екстерних. На пример, ПЦИ ДСС се сваке године ажурира новим захтевима
Раст инфраструктуре и почетак путовања
Порастао је број сервера/логичких домена/центра података, а са њима и број грешака у конфигурацијама. У неком тренутку смо дошли до три правца у којима је потребно развити управљање конфигурацијом:
- Аутоматизација. Људску грешку у операцијама које се понављају треба избегавати што је више могуће.
- Поновљивост. Много је лакше управљати инфраструктуром када је она предвидљива. Конфигурација сервера и алата за њихову припрему треба да буду свуда иста. Ово је такође важно за тимове производа – након тестирања, мора се гарантовати да ће апликација завршити у производном окружењу које је конфигурисано слично као у окружењу за тестирање.
- Једноставност и транспарентност уношења промена у управљање конфигурацијом.
Остаје додати неколико алата.
Изабрали смо ГитЛаб ЦЕ као наше складиште кода, не само због својих уграђених ЦИ/ЦД модула.
Трезор тајни - Хасхицорп Ваулт, укљ. за одличан АПИ.
Тестирање конфигурација и ансибле улога – Молецуле+Тестинфра. Тестови иду много брже ако се повежете на ансибле митоген. Истовремено смо почели да пишемо сопствени ЦМДБ и оркестратор за аутоматско постављање (на слици изнад Цобблер-а), али ово је сасвим друга прича, коју ће мој колега и главни програмер ових система испричати у будућности.
Наш избор:
Молецуле + Тестинфра
Ансибле + Товер + АВКС
Свет сервера + ДИТНЕТ (сопствени развој)
Пахуљац
Гитлаб + ГитЛаб тркач
Хасхицорп Ваулт
Узгред, о анзибилним улогама. У почетку је била само једна, али након неколико рефакторинга било их је 17, топло препоручујем да се монолит разбије на идемпотентне улоге, које се онда могу додатно покренути, можете додати ознаке. Поделили смо улоге према функционалности - мрежа, логовање, пакети, хардвер, молекул итд. Генерално, следили смо стратегију испод. Не инсистирам да је то једина истина, али је радила за нас.
- Копирање сервера са „златне слике“ је зло!Главни недостатак је што не знате тачно у каквом су стању слике сада и што ће све промене доћи на све слике у свим фармама виртуелизације.
- Користите подразумеване конфигурационе датотеке на минимум и договорите се са другим одељењима да сте одговорни за главне системске датотеке, на пример:
- Оставите /етц/сисцтл.цонф празним, подешавања би требало да буду само у /етц/сисцтл.д/. Ваша подразумевана вредност у једној датотеци, прилагођена апликацији у другој.
- Користите датотеке за замену за уређивање системских јединица.
- Шаблонирајте све конфигурације и укључите их у потпуности ако је могуће, без сед-а или његових аналога у плаибоокс
- Рефакторисање кода система за управљање конфигурацијом:
- Разбијте задатке на логичке целине и препишите монолит у улоге
- Користите линтере! Ансибле-линт, иамл-линт итд
- Промените свој приступ! Но басхсибле. Неопходно је описати стање система
- За све Ансибле улоге морате писати тестове у молекулу и генерисати извештаје једном дневно.
- У нашем случају, након припреме тестова (којих има више од 100), пронађено је око 70000 грешака. Требало је неколико месеци да се то поправи.
Наша имплементација
Дакле, ансибле улоге су биле спремне, шаблонизоване и проверене од стране линтера. Чак се и гитови одгајају свуда. Али питање поуздане испоруке кода у различите сегменте остало је отворено. Одлучили смо да се синхронизујемо са скриптама. изгледа овако:
Након што промена стигне, покреће се ЦИ, креира се тест сервер, улоге се уводе и тестирају од стране молекула. Ако је све у реду, код иде у грану прод. Али не примењујемо нови код на постојеће сервере у машини. Ово је врста граничника која је неопходна за високу доступност наших система. А када инфраструктура постане огромна, ступа на снагу закон великих бројева – чак и ако сте сигурни да је промена безопасна, може довести до страшних последица.
Такође постоји много опција за креирање сервера. На крају смо изабрали прилагођене Питхон скрипте. А за ЦИ ансибле:
- 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 Доступне улоге за подешавање сервера. Свака од улога је дизајнирана да решава посебан логички задатак (регистровање, ревизија, ауторизација корисника, праћење, итд.).
- Тестирање улога. Молецуле + ТестИнфра.
- Сопствени развој: ЦМДБ + Орцхестратор.
- Време креирања сервера је ~30 минута, аутоматизовано и практично независно од реда задатака.
- Исто стање/именовање инфраструктуре у свим сегментима - плаибоокс, репозиторијуми, елементи виртуелизације.
- Дневна провера статуса сервера са генерисањем извештаја о одступањима од стандарда.
Надам се да ће моја прича бити корисна онима који су на почетку свог пута. Који стек за аутоматизацију користите?
Извор: ввв.хабр.цом