Меню

Управление на конфигурацията в практиките на DevOps

configuration management devops practices

Опитайте Нашия Инструмент За Премахване На Проблемите

Какво представлява управлението на конфигурацията в практиките на DevOps?

Концепцията на Непрекъснато тестване в DevOps беше обяснено подробно в предишния ни урок.

Ключовият акцент в управлението на конфигурацията в DevOps е предоставянето,

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

Трябва да се прочете => Ексклузивна серия уроци за DevOps

swf файлов плейър не е инсталиран флаш обект на ударна вълна

Управление на конфигурацията в практиките на DevOps

В практиката на DevOps има многобройни предимства на „Инфраструктура като код“ и „Конфигурация като код“.

    • Конфигурациите се контролират от версията
    • Автоматизирани и стандартизирани
    • Премахва зависимостта
    • Инфра настройки без грешки
    • Засилва сътрудничеството между екипа за операции и разработка
    • Коригиране на отклонението на конфигурацията
    • Третиране на инфраструктурата като гъвкав ресурс
    • Автоматизирано мащабиране на инфраструктурата
    • Поддържане на последователност в настройките

ВИДЕО Част 4 Блок 1: Управление на конфигурацията- 23 минути 7 секунди

Стенограма:

В тази част ще научим за Управление на конфигурацията, управление на издания и мониторинг на изпълнението на приложенията в DevOps.

Тук, в блок 1, ще се съсредоточим върху управлението на конфигурацията и ще разберем какво е управление на конфигурацията и как е различно в DevOps и традиционните методи.

Като начало нека да знаем какво е управление на конфигурацията?

Управлението на конфигурацията, както обяснява самото име, не е нищо друго освен управление на всички конфигурации на средите, на които хоства софтуерното приложение.

Както знаем, имаме различни среди в SDLC в DevOps, започвайки с тестване на модули, тестване на интеграция, тестване на системата, тестване за приемане и тестване на крайния потребител.

И аз също обясних в по-ранните си уроци, че създадената среда за тези тестове постепенно ще става по-сложна, докато се придвижва към предварителна и производствена среда.

Така че основно управлението на конфигурацията е автоматизиран процес за управление на всички конфигурации на всяка от тези среди.

Тогава каква е разликата между традиционното управление на конфигурацията и управлението на конфигурацията на DevOps?

В нашите традиционни методи за управление на конфигурацията екипът използваше управлението на тези конфигурации на различни среди чрез официална документация, при което всяка от конфигурациите се записваше в документите, а екипът за конфигурация или мениджър, използвани за управление на контрола на версиите на тези документи.

И когато и когато претърпи промени, той също така ще поеме отговорността за настройка на средата и ръчно управление на конфигурациите

Сега в DevOps обикновено всички тези процеси за управление на конфигурацията са доста добре автоматизирани и конфигурациите се капсулират под формата на код или скриптове и се контролират чрез инструмента за контрол на версиите.

В този контекст можем да наречем, че екипът на Operations е интегриран с Development при управлението на средите чрез единния инструмент за контрол на версиите.

И така, ключовият акцент в управлението на конфигурацията в DevOps е предоставянето,

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

Какво всъщност означава „Инфраструктура като, като код“? Той дефинира цялата дефиниция на средата като код или скрипт, вместо да записва в официален документ.

Тогава какво включва определението за околна среда? Определението на средата обикновено включва, настройка на сървъри, конфигуриране на мрежи и настройка на други изчислителни ресурси, които са част от създадената ИТ инфраструктура. Така че всички тези подробности ще бъдат записани като файл или под формата на код и ще бъдат проверени в инструмента за контрол на версиите.

Този скрипт или код, който се проверява в контрола на версиите, ще се превърне в единствения източник за дефиниране на средата или дори за актуализиране на тези среди.

Само за да се даде просто Пример , ако трябва да добавим сървър към конкретната среда, всичко, което бихме направили, е да актуализираме тази информация в скриптовете на средата и да стартираме тръбопровода за доставка, вместо ръчно да вървим и завъртаме нова среда с добавения сървър или да търсим помощта на системния администратор за това.

Така че, красотата тук е, че разработчикът или тестващият не е задължително да бъде експерт на системния администратор, за да настрои своите сървъри за разработка или тестване.

И така, инфраструктурата, създадена в DevOps, ще бъде напълно автоматизирана и основно следва скрипта, който се проверява за контрол на версиите, започвайки от инсталирането на сървърите, конфигурирането им, инсталирането на операционната система, докато комуникационните канали на тези екземпляри не бъдат установени с внедреното софтуер.

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

Конфигурацията като код не е нищо друго освен дефиниране на всички конфигурации на сървърите или всякакви други ресурси като код или скрипт и проверката им в контрола на версиите.

Тези скриптове за конфигурация, които се проверяват в контрола на версиите, се изпълняват като част от конвейера за внедряване, за да се настрои инфраструктурата и нейните конфигурации по автоматизиран начин.

Е, дефинирането на конфигурации включва параметри, които определят препоръчителните настройки за успешно стартиране на софтуера. Или набор от команди, които трябва да бъдат изпълнени първоначално за настройка на софтуерното приложение. Или дори може да са конфигурации на всеки от компонентите на софтуера, които трябва да бъдат зададени, или конкретни потребителски роли, потребителски привилегии и т.н.,

Просто Пример би било да зададете превключватели на функциите, където стойностите по подразбиране се настройват като част от конфигурационния параметър.

Добавянето на друг порт към защитна стена би било друго Пример , които могат да бъдат актуализирани в скрипта и по-късно тези скриптове се изпълняват като част от конвейера за доставка.

На разположение са няколко инструмента за автоматизиране на инфраструктурата на пазара. Малко от тях са Chef, Puppet, Terraform и др., Chef и Puppet са инструмент за управление на конфигурация, базиран на рубин, докато Terraform е инструмент за осигуряване.

Също така, тъй като почти всички приложения ще бъдат хоствани в облака, AWS, те сами предоставят RESTAPI, които могат да бъдат използвани за тази цел.

Имам огромен списък с предимствата на управлението на конфигурацията в DevOps, вместо да определям инфраструктурата и конфигурациите като код.

Да ги разгледаме един по един.

Всички конфигурации и подробности за инфраструктурата са контролирани от версията, което е голяма полза при внедряването на DevOps.

# 1) Това помага на екипа да управлява автоматизирано промените в сървърите и конфигурацията и помага за бързо отстраняване на грешки, ако нещо се провали, в рамките на кратък период от време, а също така позволява бързо връщане към предишната версия, без да причинява прекъсвания на клиентите.

# две) Тъй като тези скриптове се намират на централния сървър и всички в екипа знаят какво има във всеки от тези скриптове и какви са промените, направени във всяка от тези версии. Това също така дава възможност на екипа да се върне към по-старата версия, ако има някакъв проблем в най-новите версии.

Представете си, ако има срив на сървъра, колко време би отнело ръчното му възстановяване. И сега, като дефинираме инфраструктурата като скрипт и контрол на версиите, можем незабавно да възстановим, като преминем към по-ранната версия.

# 3) Управлението на конфигурациите като код също предотвратява случайни промени в системата и предотвратява всякакви щети, причинени по-късно в производството.

Тъй като управлението на конфигурацията е напълно автоматизирано, ръчната намеса или за настройка или актуализация е напълно елиминирана.

Представете си въздействието върху разходите, качеството и времето, когато по-рано хората са разчитали на човешките ресурси, за да извършват тези конфигурации ръчно и когато някои конфигурации са пропуснати или не са зададени според изискванията.

Така че автоматизацията на управлението на конфигурацията не само е спечелила от спестяване на време, но и от елиминиране на такива човешки грешки и подобряване на качеството. Също така стандартът за кодиране е помогнал на екипа да спазва посочения стандарт при кодиране и автоматизиране, вместо да следва фантазията на всеки от човека, който пише ръководството за конфигуриране.

Както беше обсъдено по-рано, конфигурациите, доставяни като код, премахнаха зависимостта от един човек или екип, наречен config manager или config team. Екипът на разработчиците не трябва да чака да дойде екипът за конфигуриране и да поправи някакъв проблем с инфра или конфиг.

Или дори за настройка на инфрачервените и конфигурациите, които са напълно автоматизирани и контролирани от версията. Така че всеки в екипа, независимо дали е разработчик или тестер, може да върти сървър и да извършва конфигурациите за целите на тяхното разработване и тестване. Следователно настройката на сървъра и конфигурациите е станала независима от човека.

Това също така гарантира, че едни и същи сървъри не се използват както от екипите за разработка, така и от екипа за осигуряване на качеството за техните дейности, което обикновено беше по-рано.

Инфраструктурата и конфигурациите, дефинирани като общ код, заедно с автоматизация и контрол на версиите стандартизират всички среди и настройките. Така че това не само улеснява задачата за отстраняване на грешки за разработчиците, но също така елиминира човешките грешки, водещи до инфра настройки без грешки, в противен случай, които биха причинили огромни щети, ако не бъдат открити рано.

Тук можем ясно да видим ясното сътрудничество между Dev и Ops, където и двамата разчитат на един източник за извършване на инфра настройката и двата екипа участват активно в автоматизирането и настройването на цялото управление на конфигурацията.

Тази съвместна работа за постигане на обща цел засилва сътрудничеството между двата екипа, разработката и операциите.

Коригиране на отклонението на конфигурацията

Какво е Configuration Drift?

Малки разлики и несъответствия между сървърите, което понякога се случва поради ръчно актуализиране, което се натрупва за определен период от време, се наричат ​​Configuration drift.

Това не е добра ситуация, тъй като тази несъвместимост в сървърите оставя определени програмни файлове като manifest, playbook да не работят надеждно на всички сървъри и следователно води до неуспех на автоматизацията. Така че, това трябва да се избягва, за да накара екипът да използва ефективно автоматизацията на конфигурациите.

Управлението на инфра и конфигурирането като код и версия, която ги контролира, помогна на екипа да избегне или коригира всякакъв вид отклонения в конфигурацията между различни среди или между разработчици и производствени настройки, като последователно поддържа конфигурациите на всички сървъри.

По този начин екипът може да бъде най-добре уверен в подобни конфигурационни настройки на разработката, създадена като тази в производството. Това също им помага да симулират производствените проблеми в разработващата среда.

Така че, това помага да се предотвратят всякакви неочаквани промени, които някой от членовете на екипа може да се опита да направи в инфрачервения режим, което може да наруши настройката и също така да принуди екипа да не прави промени в настройката, освен ако не са влезли като код към хранилището.

Предоставянето на инфраструктура и нейната конфигурация като код позволи на екипа да я управлява като гъвкав ресурс, за да отговори на динамичните бизнес нужди на клиента.

Това е един вид plug and play сега. Екипът може конкретно да влезе в конкретния сървър или мрежа и да направи промените в тях. Това може да бъде просто актуализиране на сървъра за предоставяне или добавяне или модифициране на хранилището в определена мрежа или дори актуализиране на операционната система и всичко може да се актуализира независимо като гъвкав ресурс.

Преди това, за да промените един конфигурационен параметър, наистина отнемаше много време, особено докато се изискваше да се актуализира във всички сървъри, но сега това е само едно движение. Актуализирайте скрипта и качете в инструмента за контрол на версиите и всичко е готово.

Налице е гъвкавост за пълно премахване на съществуващата инфраструктура и изцяло извеждане на друга. Така че управлението на инфраструктурата и конфигурациите стана доста лесно сега. Е, облачните решения позволиха на инфраструктурата да се разшири автоматично, като добави допълнителните изчислителни ресурси или ресурси за съхранение, както се изисква, и мащабира, когато не са необходими.

Това даде възможност за оптимизиране на използването на ресурси въз основа на търсенето. Ако искаме да разширим инфраструктурата чрез увеличаване на размера на машината, можем да го направим веднага. По същия начин, ако искаме да мащабираме или може би да добавим друга настройка или да добавим още предни краища, можем просто да го направим за секунди, като просто го актуализираме в кода и стартираме автоматизирания конвейер.

И накрая, но не на последно място, инфраструктурата, предоставянето като код в контролирана среда помага за поддържане на последователността на средите в различни настройки. Това помага и за отстраняване на грешки в проблема. Този момент съм разгледал и по-рано, до известна степен, докато говорим за отклонение на конфигурацията.

Това е и това завършва разговора ни за управлението на конфигурацията в DevOps, относно това какво представлява инфраструктурата и конфигурациите като код и какви са предимствата му.

В нашия предстоящ урок ще обсъдим аспектите на Release Management в DevOps.

PREV Урок | СЛЕДВАЩ урок

Препоръчително четене

^