🥇Желілік инфрақұрылымыңызды қалай басқаруға болады. Төртінші тарау. Автоматтандыру. Үлгілер

Бұл мақала «Желілік инфрақұрылымды қалай басқаруға болады» атты мақалалар топтамасының алтыншы мақаласы. Сериядағы барлық мақалалардың мазмұнын және сілтемелерді табуға болады осында.

Бірнеше тақырыпты артқа тастап, жаңа тарауды бастауды жөн көрдім.

Мен қауіпсіздікке сәл кейінірек ораламын. Бұл жерде мен қарапайым, бірақ тиімді әдісті талқылағым келеді, оны көптеген адамдар бір түрде немесе басқа түрде пайдалы деп табатынына сенімдімін. Бұл автоматтандыру инженердің өмірін қалай өзгертетіні туралы қысқаша әңгіме. Мен үлгілерді пайдалануға назар аударамын. Соңында мен өз жобаларымды тізімдеймін, мұнда сипатталғанның бәрі қалай жұмыс істейтінін көре аласыз.

Желіге арналған DevOps

Сценарий арқылы конфигурацияларды жасау, АТ инфрақұрылымындағы өзгерістерді басқару үшін GIT пайдалану және қашықтан итеру — бұл DevOps әдісін техникалық енгізуді қарастырған кезде ойға келетін алғашқы идеялар. Артықшылықтары анық. Бірақ, өкінішке орай, кемшіліктер де бар.

5 жылдан астам уақыт бұрын біздің әзірлеушілер бізге, сетевойшыларға осы ұсыныстармен келгенде, біз қуанбадық.

Айта кету керек, біз 10-ға жуық әртүрлі жеткізушілерден құралған жабдықтардан тұратын өте әртүрлі желіні мұра еттік. Кейбір конфигурациялар біздің сүйікті CLI арқылы ыңғайлы өңделді, бірақ басқалары үшін GUI пайдалануды жөн көрдік. Сонымен қатар, ток өткізетін жабдықтағы ауқымды жұмыс бізді нақты уақыт режимінде басқаруға дағдыландырды. Мысалы, өзгертулер енгізу кезінде мен тікелей CLI арқылы жұмыс істеуді әлдеқайда ыңғайлы сезінемін. Осылайша, мен бірдеңе дұрыс емес екенін тез көріп, өзгерістерді қайтара аламын. Мұның бәрі олардың идеяларына біршама қайшы болды.

Басқа мәселелер туындайды, мысалы, интерфейс бағдарламалық жасақтаманың нұсқасына қарай сәл өзгеруі мүмкін. Бұл, сайып келгенде, сценарийіңіздің қате конфигурация жасауына әкеледі. Мен тестілеу мақсатында өндірісті пайдаланғым келмейді.

Немесе конфигурация пәрмендерінің дұрыс қолданылғанын қалай анықтауға болады және қате орын алса не істеу керек?

Мен бұл мәселелердің барлығы шешілмейді деп айтпаймын. Жаңа ғана «А» деп айтқаннан кейін, «Б» деп айту орынды болар. Әзірлеудегідей өзгертуді басқару процестерін пайдаланғыңыз келсе, өндіріске қосымша әзірлеу және орнату орталары болуы керек. Сонда бұл тәсіл аяқталған сияқты. Бірақ бұл қанша тұрады?

Бірақ жағымсыз жақтары іс жүзінде жойылып, тек жақсы жақтарын қалдыратын бір жағдай бар. Мен дизайн жұмысы туралы айтып отырмын.

Жоба

Соңғы екі жыл бойы мен ірі провайдер үшін деректер орталығы жобасында жұмыс істеп жатырмын. Мен F5 және Пало Альто үшін жауаптымын. Cisco көзқарасы бойынша бұл «үшінші тарап жабдығы».

Жеке мен үшін бұл жобаның екі бөлек кезеңі бар.

Бірінші кезең

Бірінші жыл өте тығыз болды, түнгі және демалыс күндері жұмыс істедім. Мен басымды көтере алмадым. Басшылық пен клиент тарапынан қысым қарқынды және тұрақты болды. Тұрақты жұмыста мен процесті оңтайландыруға тырыса алмадым. Бұл жабдықты конфигурациялау туралы ғана емес, сонымен қатар конструкторлық құжаттаманы құрастыру туралы болды.

Алғашқы сынақтар басталып, қаншама болмашы қателер мен дәлсіздіктерге таң қалдым. Әрине, бәрі жұмыс істеді, бірақ атауында әріп жоқ, командада бір жол жоқ ... Сынақтар жалғасты және мен қателермен, сынақтармен және құжаттамамен үнемі, күнделікті күресте болдым.

Бұл бір жылға созылды. Менің түсінуімше, жоба барлығы үшін қиын болды, бірақ бірте-бірте тапсырыс берушіні қанағаттандыра бастады, бұл күнделікті жұмыстардың кейбірін өз мойнына алатын қосымша инженерлерді жалдауға мүмкіндік берді.

Енді аздап жан-жаққа қарауға болатын еді.
Ал бұл екінші кезеңнің басы еді.

Екінші кезең

Мен процесті автоматтандыруды шештім.

Сол кездегі әзірлеушілермен әңгімемнен түсінгенім (және олардың арқасында бізде мықты команда болған) мәтін пішімі бір қарағанда DOS операциялық жүйесі әлемінен бір нәрсе сияқты көрінгенімен, бірқатар құнды қасиеттерге ие.
Мысалы, егер сіз GIT және оның барлық туындыларын толық пайдаланғыңыз келсе, мәтін пішімі пайдалы болады. Мен жасадым.

Конфигурацияны немесе пәрмендер тізімін жай ғана сақтауға болатын сияқты, бірақ оған өзгертулер енгізу өте ыңғайсыз. Сонымен қатар, дизайн кезінде тағы бір маңызды тапсырма бар. Сізде жалпы дизайнды (төмен деңгейлі дизайн) және нақты іске асыруды (желілік енгізу жоспары) сипаттайтын құжаттама болуы керек. Бұл жағдайда үлгілерді пайдалану өте қолайлы нұсқа болып көрінеді.

Сонымен, YAML және Jinja2 пайдалану кезінде IP мекенжайлары, BGP AS нөмірлері және т.б. сияқты конфигурация параметрлері бар YAML файлы NIP рөлін тамаша орындайды, ал Jinja2 үлгілері дизайнға сәйкес синтаксисті қамтиды, яғни мәні бойынша ол LLD көрінісі болып табылады.

YAML және Jinja2 тілін үйрену екі күнге созылды. Оның қалай жұмыс істейтінін түсіну үшін бірнеше жақсы мысалдар жеткілікті болды. Содан кейін дизайнымызға сәйкес келетін барлық үлгілерді жасауға шамамен екі апта қажет болды: Пало Альто үшін бір апта және F5 үшін тағы бір апта. Мұның бәрі корпоративті GitHub сайтында жарияланған.

Енді өзгерту процесі келесідей болды:

YAML файлын өзгертті
шаблонды пайдаланып конфигурация файлын жасады (Jinja2)
қашықтағы репозиторийде сақталады
жасалған конфигурацияны жабдыққа жүктеп салды
Мен қате көрдім
YAML файлын немесе Jinja2 үлгісін өзгертті
шаблонды пайдаланып конфигурация файлын жасады (Jinja2)
...

Бастапқыда өңдеуге көп уақыт кететіні анық, бірақ бір-екі аптадан кейін бұл сирек кездесетін жағдайға айналды.

Жақсы сынақ және барлығын дәл баптау мүмкіндігі клиенттің атау конвенциясын өзгертуге деген ұмтылысы болды. F5-пен жұмыс істеген кез келген адам бұл жағдайдың қиындығын түсінеді. Бірақ мен үшін бұл өте қарапайым болды. Мен YAML файлындағы атауларды өзгерттім, жабдықтан барлық конфигурацияны жойдым, жаңасын жасап, жүктеп салдым. Қателерді түзетуді қоса алғанда, бүкіл процесс төрт күнге созылды: әр технология үшін екі күн. Осыдан кейін мен келесі қадамға дайын болдым: DEV және Staging деректер орталықтарын құру.

Әзірлеу және сахналау

Сахналау негізінен өндірістің толық көшірмесі болып табылады. Dev - бұл негізінен виртуалды жабдықта жасалған қатты жойылған нұсқа. Бұл жаңа көзқарас үшін тамаша жағдай. Егер мен бүкіл процеске жұмсалған уақытымды есептейтін болсам, менің ойымша, жұмыс екі аптадан аспады. Уақыттың көп бөлігі екінші тарапты күтіп, ақауларды бірлесіп жоюға жұмсалды. Үшінші тараптың іске асыруы дерлік байқалмады. Мен тіпті бірнеше нәрсені үйреніп, Хабр туралы бірнеше мақала жазуға уақыт таптым.

Қорытындылайық

Сонымен, менде қорытынды ретінде не бар?

Конфигурацияны өзгертуге қажет нәрсе - конфигурация параметрлері бар қарапайым, анық құрылымдалған YAML файлы. Мен Python сценарийін ешқашан өзгертпеймін және өте сирек (қате болса ғана) Jinja2 жылу картасын өзгертпеймін.
Құжаттама тұрғысынан бұл тамаша жағдайға жақын. Сіз құжаттаманы өзгертесіз (YAML файлдары NIP ретінде әрекет етеді) және бұл конфигурацияны аппараттық құралға жүктейсіз. Осылайша, сіздің құжаттамаңыз әрқашан жаңартылған.

Мұның бәрі осыған әкелді

қате деңгейі 0-ге дейін төмендеді
Күн тәртібінің 90 пайызы жойылды
жүзеге асыру жылдамдығы айтарлықтай артты

PAY, F5Y, ACY

Мен оның қалай жұмыс істейтінін түсіну үшін бірнеше мысал жеткілікті екенін айттым.
Міне, менің жұмысымның барысында жасалған нәрсенің қысқаша (әрине өзгертілген) нұсқасы.

PAY = орналастыру Pсәлем Aбастап Yaml = Ямлдан Пало Альто
F5Y = орналастыру F5 -дан Yaml = F5 -дан Yaml (жақында)
ACY = орналастыру ACжәне бастап Yaml = F5 -дан Yaml

Мен ACY туралы бірнеше сөз қосамын (ACI-мен шатастырмау үшін).

ACI-мен жұмыс істегендер бұл ғажайыпты (және жақсы жағынан да) сетевойшылар жасамағанын біледі :). Желі құру туралы білгеннің бәрін ұмытыңыз — бұл сізге ешқандай пайда әкелмейді!
Бұл сәл асыра айтылған, бірақ бұл менің ACI-мен жұмыс істеген кезде 3 жыл бойы үнемі бастан кешіп жүрген сезімімді білдіреді.

Және бұл жағдайда ACY тек өзгерістерді басқару процесін құру мүмкіндігі ғана емес (бұл ACI жағдайында әсіресе маңызды, себебі ол деректер орталығының орталық және ең маңызды бөлігі болып саналады), сонымен қатар конфигурацияны жасау үшін пайдаланушыға ыңғайлы интерфейс береді.

Осы жобадағы инженерлер ACI-ді бірдей мақсаттарда конфигурациялау үшін YAML орнына Excel пайдаланады. Excel бағдарламасын пайдаланудың артықшылықтары бар: