Мени

Управљање конфигурацијом у пракси ДевОпс

configuration management devops practices

Испробајте Наш Инструмент За Елиминисање Проблема

Шта је управљање конфигурацијом у пракси ДевОпс?

Концепт Континуирано тестирање у ДевОпс-у је детаљно објашњено у нашем претходном водичу.

Кључни нагласак управљања конфигурацијом у ДевОпс-у је пружање,

  1. Инфраструктура као код
  2. Конфигурација као код

Морам прочитати => Ексклузивна серија водича за ДевОпс

програм за преузимање видео записа са било које веб локације

Управљање конфигурацијом у пракси ДевОпс

Бројне су предности „Инфраструктура као код“ и „Конфигурација као код“ у пракси ДевОпс.

    • Конфигурације се контролишу верзијом
    • Аутоматизовано и стандардизовано
    • Уклања зависност
    • Инфра поставке без грешака
    • Појачава сарадњу између Оперативног и Развојног тима
    • Исправљање одступања конфигурације
    • Третирање инфраструктуре као флексибилног ресурса
    • Аутоматизовано скалирање инфраструктуре
    • Одржавање доследности у поставкама

ВИДЕО 4. део, блок 1: Управљање конфигурацијом- 23 минута 7 секунди

Препис:

У овом делу ћемо научити о Управљање конфигурацијом, управљање издањима и праћење перформанси апликација у ДевОпс-у.

Овде, у блоку 1, фокусираћемо се на управљање конфигурацијом и разумећемо шта је управљање конфигурацијом и како се разликује у ДевОпс-у и традиционалним методама.

За почетак, знајмо шта је управљање конфигурацијом?

Управљање конфигурацијом, како и само име објашњава, није ништа друго него управљање свим конфигурацијама окружења на којима софтверска апликација хостује.

Као што знамо, имамо различита окружења широм СДЛЦ-а у ДевОпс-у, почевши од Унит тестирања, тестирања интеграције, тестирања система, тестирања прихватања и тестирања крајњег корисника.

Такође сам објаснио у својим ранијим водичима да би окружење постављено за ове тестове постепено постајало све сложеније како се креће ка предпродукцијском и производном окружењу.

Дакле, у основи је управљање конфигурацијом аутоматизовани процес за управљање свим конфигурацијама сваког од ових окружења.

У чему је онда разлика између традиционалног управљања конфигурацијом и управљања конфигурацијом ДевОпс?

У нашим традиционалним методама управљања конфигурацијом, тим се користио за управљање овим конфигурацијама различитих окружења путем формалне документације, при чему је свака од конфигурација била забележена у документима, а тим за конфигурацију или менаџер који се користио за управљање верзијама ових докумената.

А како и када се претрпи промене, он би такође преузео одговорност за подешавање окружења и ручно управљање конфигурацијама

Сада су у ДевОпсу обично сви ови процеси управљања конфигурацијом прилично аутоматизовани, а конфигурације су инкапсулиране у облику кода или скрипти и контролисане помоћу алата за контролу верзија.

У том контексту можемо назвати да је Оперативни тим интегрисан са Развојем у управљање окружењима кроз алат за контролу једне верзије.

Дакле, кључни нагласак управљања конфигурацијом у ДевОпс-у је пружање,

      1. Инфраструктура као код
      2. Конфигурација као код

Шта заправо значи „Инфраструктура као код“? То је дефинисање целокупне дефиниције окружења као кода или скрипте, уместо да се снима у формалном документу.

Шта онда укључује дефиниција животне средине? Дефиниција окружења обично укључује, подешавање сервера, конфигурисање мрежа и подешавање других рачунарских ресурса, који су део постављене ИТ инфраструктуре. Дакле, сви ови детаљи би били записани у датотеку или у облику кода и пријављени у алат за контролу верзија.

Ова скрипта или код који се проверавају у контроли верзија постаће јединствени извор дефинисања окружења или чак ажурирања тих окружења.

Само да дам једноставан Пример , ако морамо да додамо сервер у одређено окружење, све што бисмо урадили је да ажурирамо ове информације у скрипте окружења и покренимо довод испоруке, уместо да ручно идемо и вртимо ново окружење са доданим сервером или да тражимо помоћ људи администратора система да то ураде.

Дакле, лепота је у томе што програмер или тестер не мора бити стручњак за системске администраторе да би подесио своје сервере за развојне или тестне активности.

Дакле, инфраструктура постављена у ДевОпс-у биће потпуно аутоматизована и у основи следи скрипту која се проверава у контроли верзија почев од инсталирања сервера, њиховог конфигурисања, инсталирања ОС-а, док се не успоставе комуникациони канали ових инстанци са распоређеним софтвер.

Каква је конфигурација као код?

Конфигурација као код није ништа друго него дефинисање свих конфигурација сервера или било којих других ресурса као кода или скрипте и њихово проверавање у контролу верзија.

Ове скрипте за конфигурацију које се проверавају у контроли верзија покрећу се као део цевовода за размештање како би се аутоматизовано поставила инфраструктура и њене конфигурације.

Па, дефинисање конфигурација укључује параметре који дефинишу препоручене поставке за успешан рад софтвера. Или скуп наредби које треба покренути у почетку за подешавање софтверске апликације. Или то могу бити конфигурације сваке од компоненти софтвера које треба поставити или одређене корисничке улоге, корисничке привилегије итд.,

Једноставно Пример би било постављање преклопних функција, где су подразумеване вредности постављене као део конфигурационог параметра.

Додавање још једног порта у заштитни зид било би још једно Пример , који се могу ажурирати у скрипти, а касније се те скрипте покрећу као део цевовода за испоруку.

На располагању је неколико алата за аутоматизацију инфраструктуре на тржишту. Мало их је Кувар, Лутка, Тераформ итд., Кувар и Лутка су алат за управљање конфигурацијом на бази рубина, док је Терраформ алат за обезбеђивање.

Такође, ових дана пошто ће готово све апликације бити хостоване у облаку, АВС, они сами нуде РЕСТАПИ-је, који се могу искористити у ову сврху.

Имам огромну листу предности управљања конфигурацијом у ДевОпс-у, уместо да дефинишем инфраструктуру и конфигурације као код.

Кренимо редом кроз њих.

Све детаље о конфигурацији и инфраструктури контролишу верзије, што је велика предност у примени ДевОпс-а.

# 1) Ово помаже тиму да аутоматизовано управља променама на серверима и конфигурацији и помаже у брзом отклањању грешака ако било шта не успије, у кратком временском распону, а такође омогућава брзо враћање на претходну верзију, без наношења прекида купцима.

#два) Пошто су ове скрипте смештене на централном серверу и сви у тиму знају шта се налази у свакој од ових скрипти и које су промене направљене у свакој од ових верзија. Ово такође омогућава тиму да се врати на старију верзију, ако постоји проблем у најновијим верзијама.

Замислите, ако дође до пада сервера, колико би времена било потребно да га ручно вратите. А сада дефинишући инфраструктуру као контролу скрипти и верзије, можемо одмах да је вратимо преласком на ранију верзију.

# 3) Управљање конфигурацијама као кодом такође спречава некога да случајно мења систем и спречава било какву штету која настане касније у производњи.

Будући да је управљање конфигурацијом потпуно аутоматизовано, ручна интервенција за подешавање или ажурирање је потпуно елиминисана.

Замислите утицај на трошкове, квалитет и време када су људи раније зависили од људских ресурса да би ручно изводили ове конфигурације и када су одређене конфигурације пропуштене или нису постављене по потреби.

Дакле, аутоматизација управљања конфигурацијом није само имала користи у уштеди времена већ и у уклањању таквих људских грешака и побољшању квалитета. Такође, стандард кодирања помогао је тиму да следи наведени стандард у кодирању и аутоматизацији, уместо да следи фантазију сваке особе која пише водич за конфигурисање.

Као што је раније речено, конфигурације које се испоручују као код уклониле су зависност од једне особе или тима који се назива цонфиг манагер или цонфиг теам. Развојни тим не мора чекати да тим за конфигурисање дође и поправи било који инфра или конфигурацијски проблем.

Или чак за подешавање инфра и конфигурација, које су потпуно аутоматизоване и под контролом верзије. Дакле, било ко у тиму, било да је програмер или тестер, може да окреће сервер и врши конфигурације у своје сврхе развоја и тестирања. Стога је постављање сервера и конфигурација постало неовисно о особи.

Ово такође осигурава да исти сервери не користе и развојни и КА тимови за своје активности, што је обично био случај раније.

Инфраструктура и конфигурације дефинисане као заједнички код, заједно са аутоматизацијом и контролом верзија, стандардизују сва окружења и подешавања. Дакле, ово не само да олакшава задатак отклањања грешака програмерима већ и елиминише људске грешке које резултирају инфра поставкама без грешака, иначе које би могле нанети велику штету, ако се не открију рано.

Овде можемо јасно видети јасну сарадњу између Дев-а и Опс-а, ​​где се обојица ослањају на један извор за спровођење инфра-инсталације, а оба тима су активно укључена у аутоматизацију и подешавање целокупног управљања конфигурацијом.

Ово заједничко деловање на постизању заједничког циља појачава сарадњу између оба тима, Развој и операције.

Исправљање конфигурационог одступања

Шта је Цонфигуратион Дрифт?

Мале разлике и недоследности између сервера, које се понекад дешавају због ручног ажурирања, које се акумулира током одређеног временског периода, називају се конфигурационим заносом.

Ово није добра ситуација, јер ова недоследност на серверима оставља одређене програмске датотеке као што су манифест, плаибоок да не раде поуздано на свим серверима и отуда доводи до неуспеха аутоматизације. Дакле, ово треба избегавати да би тим натерао ефикасну употребу аутоматизације конфигурација.

Управљање инфром и конфигурацијом као кодом и верзијом која их контролише помогло је тиму да избегне или исправи било какву конфигурацију одступања између различитих окружења или између развојних и производних поставки доследним одржавањем конфигурација на свим серверима.

Дакле, тим се може најбоље уверити у слична подешавања конфигурације на развоју постављеном као у производњи. Ово им такође помаже да симулирају производне проблеме у развојном окружењу.

Дакле, ово помаже у спречавању било каквих неочекиваних промена које би било који од чланова тима могао покушати да уради на инфра, што би могло прекинути поставку, а такође и приморати тим да не врши промене у поставци уколико није пријављен као код спремишта.

Испорука инфраструктуре и њене конфигурације као кода омогућили су тиму да њоме управља као флексибилним ресурсом који задовољава динамичне пословне потребе купаца.

То је нека врста плуг анд плаиа сада. Тим може посебно да уђе на одређени сервер или мрежу и да на њима изврши промене. То може бити само ажурирање сервера за обезбеђивање или додавање или модификовање складишта у одређеној мрежи, или чак ажурирање ОС-а, и све се може самостално ажурирати као флексибилни ресурс.

Раније је за промену једног конфигурационог параметра требало пуно времена, посебно док је било потребно ажурирање на свим серверима, али сада је то само један потез. Ажурирајте скрипту и отпремите је у алат за контролу верзија и све је готово.

Постоји флексибилност да се у потпуности укине постојећа инфраструктура и потпуно отвори још једна. Дакле, управљање инфраструктуром и конфигурацијама постало је прилично лако сада. Па, решења заснована на облаку омогућила су инфраструктури да се аутоматски увећава додавањем додатних рачунарских ресурса или ресурса за складиштење по потреби и смањењем када нису потребни.

Ово је омогућило оптимизацију коришћења ресурса на основу потражње. Ако желимо да повећамо инфраструктуру повећањем величине машине, то можемо учинити одмах. Слично томе, ако желимо да умањимо величину или можда додамо другу поставку или додамо још предњих крајева, то можемо учинити за неколико секунди једноставним ажурирањем у коду и покретањем аутоматизованог цевовода.

На крају, али не најмање важно, инфраструктура, испорука као код у контролисаном окружењу помаже у одржавању доследности окружења у различитим поставкама. Ово такође помаже у отклањању грешака у проблему. И ову тему сам донекле обрађивао, говорећи о померању конфигурације.

То је то и ово завршава наш разговор о управљању конфигурацијом у ДевОпс-у, о томе шта је инфраструктура и конфигурације као код и које су његове предности.

У нашем предстојећем упутству ћемо разговарати аспекти управљања издањима у ДевОпс-у.

ПРЕВ Туториал |. | СЛЕДЕЋА Лекција

Препоручено читање

^