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

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

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

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

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

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

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

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

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

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

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

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

Жоба

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

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

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

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

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

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

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

Екінші кезең

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

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

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

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

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

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

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

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

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

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

Сахналау іс жүзінде өндірісті толығымен қайталайды. Dev - бұл негізінен виртуалды жабдықта жасалған қатты жойылған көшірме. Жаңа көзқарас үшін тамаша жағдай. Егер мен өткізген уақытты жалпы процестен оқшаулайтын болсам, онда менің ойымша, жұмыс 2 аптадан аспады. Негізгі уақыт – екінші тарапты күтіп, проблемаларды бірге іздеу. Үшінші тараптың іске асырылуы басқалардың назарынан тыс қалды. Тіпті бірдеңе үйренуге және Хабреге бірнеше мақала жазуға уақыт болды :)

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

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

  • Конфигурацияны өзгерту үшін тек конфигурация параметрлері бар қарапайым, анық құрылымды YAML файлын өзгерту керек. Мен питон сценарийін ешқашан өзгертпеймін және өте сирек (қате болса ғана) 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-мен жұмыс істегендер бұл ғажайыпты (және жақсы жағынан да) сетевойшылар жасамағанын біледі :). Желі туралы білетіндердің барлығын ұмытыңыз - бұл сізге пайдалы болмайды!
Бұл аздап асыра айтылған, бірақ бұл менің соңғы 3 жыл бойы ACI-мен жұмыс істеп келе жатқан сезімімді білдіреді.

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

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

  • NIP бір файлда
  • клиентке қарауға жағымды әдемі белгілер
  • кейбір excel құралдарын пайдалануға болады

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

ACY шын мәнінде мен үшінші тарап үшін ACI конфигурациялау үшін пайдаланған тәсілдердің қолданбасы болып табылады.

Ақпарат көзі: www.habr.com

пікір қалдыру