Арга барил IaC (Дэд бүтэц нь код) нь зөвхөн хадгалах санд хадгалагдаж буй кодоос гадна энэ кодыг тойрсон хүмүүс болон процессуудаас бүрддэг. Програм хангамж боловсруулахаас эхлээд дэд бүтцийн удирдлага, тайлбар хүртэлх арга барилыг дахин ашиглах боломжтой юу? Өгүүллийг уншиж байхдаа энэ санааг санаж байх нь зүйтэй болов уу.

Англи хувилбар

Энэ бол миний хуулбар юм тоглолтууд тухай DevopsConf 2019-05-28.

Слайд, видео

• Англи хувилбар
• Орос хувилбар
• Хуурай гүйлт 2019-04-24 SpbLUG
• DevopsConf-ийн 2019-05-28-ны өдрийн видео (RU).
• DINS DevOps EVENING 2019-06-20-ны видео(RU).
• слайд

Дэд бүтэц нь bash түүх шиг

Та шинэ төсөл дээр ирсэн гэж бодъё, тэд танд: "Бидэнд байна Дэд бүтэц нь код". Бодит байдал дээр энэ нь харагдаж байна Дэд бүтэц нь bash түүх шиг эсвэл жишээ нь Баримтжуулалт нь bash түүх юм. Энэ бол маш бодит нөхцөл байдал, жишээлбэл, үүнтэй төстэй тохиолдлыг Денис Лысенко илтгэлдээ дурджээ Хэрхэн дэд бүтцийг бүхэлд нь сольж, тайван унтаж эхлэх вэ, тэр bash түүхээс төслийн уялдаа холбоотой дэд бүтцийг хэрхэн олж авсан тухайгаа хэлэв.

Хүслээр бид үүнийг хэлж чадна Дэд бүтэц нь bash түүх шиг Энэ нь кодтой адил юм:

1. давтах чадвар: Та bash түүхийг авч, тэндээс командуудыг ажиллуулж болох бөгөөд дашрамд хэлэхэд та ажлын тохиргоог гаралт болгон авах боломжтой.
2. хувилбар гаргах: хэн орж ирснийг, тэд юу хийснийг та мэднэ, энэ нь таныг гарц дээр ажиллах тохиргоо руу хөтөлнө гэсэн баримт биш юм.
3. түүх: хэн юу хийсэн тухай түүх. Хэрэв та серверээ алдсан тохиолдолд л үүнийг ашиглах боломжгүй болно.

Би яах ёстой вэ?

Дэд бүтэц нь код

Ийм хачирхалтай тохиолдол ч гэсэн Дэд бүтэц нь bash түүх шиг чи чихнээс нь татаж болно Дэд бүтэц нь код, гэхдээ бид хуучин сайн LAMP серверээс илүү төвөгтэй зүйл хийхийг хүсэх үед бид энэ кодыг ямар нэгэн байдлаар өөрчлөх, өөрчлөх, сайжруулах шаардлагатай гэсэн дүгнэлтэд хүрэх болно. Дараа нь бид хоорондоо параллель байдлыг авч үзэхийг хүсч байна Дэд бүтэц нь код болон програм хангамж хөгжүүлэх.

ХУУРАЙ

Хадгалах системийг хөгжүүлэх төсөл дээр дэд даалгавар байсан SDS-г үе үе тохируулах: бид шинэ хувилбар гаргаж байна - үүнийг цаашдын туршилтанд оруулах шаардлагатай. Даалгавар нь маш энгийн:

• энд ssh-ээр нэвтэрч командыг гүйцэтгэнэ.
• файлыг тэнд хуулна.
• тохиргоог энд засна уу.
• тэнд үйлчилгээг эхлүүлнэ үү
• ...
• АШИГ!

Тайлбарласан логикийн хувьд bash нь ялангуяа төслийн эхний шатанд, дөнгөж эхэлж байгаа үед хангалттай юм. Энэ Та bash ашигладаг нь муу биш юм, гэхдээ цаг хугацаа өнгөрөхөд үүнтэй төстэй, гэхдээ арай өөр зүйл байршуулах хүсэлт ирдэг. Хамгийн түрүүнд санаанд орж ирдэг зүйл бол copy-paste юм. Одоо бид бараг ижил зүйлийг хийдэг хоёр ижил төстэй скрипттэй болсон. Цаг хугацаа өнгөрөхөд скриптүүдийн тоо нэмэгдэж, бид өөр өөр скриптүүдийн хооронд синхрончлох шаардлагатай суулгацыг байрлуулах бизнесийн тодорхой логиктой тулгарсан бөгөөд энэ нь нэлээд төвөгтэй юм.

DRY (Өөрийгөө бүү давт) гэх мэт дасгал байдаг нь харагдаж байна. Гол санаа нь одоо байгаа кодыг дахин ашиглах явдал юм. Энэ нь энгийн сонсогдож байгаа ч бид шууд ийм зүйлд хүрээгүй. Манай тохиолдолд тохиргоог скриптээс салгах гэсэн утгагүй санаа байсан. Тэдгээр. Суулгацыг тусад нь хэрхэн байрлуулах, тохиргоог тусад нь хийх бизнесийн логик.

CFM-д зориулсан SOLID

Цаг хугацаа өнгөрөхөд төсөл нь томорч, байгалийн үргэлжлэл Ансибл бий болсон явдал байв. Түүний гарч ирсэн гол шалтгаан нь багийн туршлага байгаа бөгөөд bash нь нарийн төвөгтэй логикт зориулагдаагүй явдал юм. Ansible мөн нарийн төвөгтэй логикийг агуулж эхэлсэн. Нарийн төвөгтэй логик эмх замбараагүй байдал болон хувирахаас урьдчилан сэргийлэхийн тулд програм хангамж боловсруулахад кодыг зохион байгуулах зарчмууд байдаг ХАТУУ Түүнчлэн, жишээлбэл, Григорий Петров "Мэдээллийн технологийн мэргэжилтэнд яагаад хувийн брэнд хэрэгтэй вэ" гэсэн илтгэлдээ тухайн хүн зарим нийгмийн байгууллагуудтай ажиллахад хялбар байхаар бүтээгдсэн гэсэн асуултыг тавьсан. объектууд юм. Хэрэв бид энэ хоёр санааг нэгтгэж, үргэлжлүүлэн хөгжүүлбэл бид ч бас ашиглаж болохыг анзаарах болно ХАТУУ ирээдүйд энэ логикийг хадгалах, өөрчлөхөд хялбар болгох.

Ганц хариуцлагын зарчим

Анги бүр зөвхөн нэг даалгавар гүйцэтгэдэг.

Кодыг хольж, цул бурханлаг спагетти мангасуудыг хийх шаардлагагүй. Дэд бүтэц нь энгийн тоосгоноос бүрдэх ёстой. Хэрэв та Ansible тоглоомын номыг жижиг хэсгүүдэд хувааж, Ansible дүрүүдийг уншвал тэдгээрийг арчлахад хялбар байх болно.

Нээлттэй хаалттай зарчим

Нээлттэй/хаалттай зарчим.

• Нээлттэй өргөтгөл: аж ахуйн нэгжийн шинэ төрлийг бий болгосноор тухайн байгууллагын зан төлөвийг өргөтгөж болно гэсэн үг.
• Өөрчлөлтөд хаалттай: Аж ахуйн нэгжийн үйл ажиллагааг өргөжүүлсний үр дүнд тэдгээр аж ахуйн нэгжийг ашигладаг кодонд өөрчлөлт оруулах ёсгүй.

Эхэндээ бид туршилтын дэд бүтцийг виртуал машинууд дээр байрлуулсан боловч байршуулах бизнесийн логик нь хэрэгжилтээс тусдаа байсан тул baremetall-д ямар ч асуудалгүйгээр эргэлдэхийг нэмсэн.

Лисковын орлуулах зарчим

Барбара Лисковын орлуулах зарчим. Програм дахь объектуудыг програмын зөв гүйцэтгэлийг өөрчлөхгүйгээр тэдгээрийн дэд төрлүүдийн жишээнүүдээр сольж болох ёстой.

Хэрэв та үүнийг илүү өргөн хүрээнд авч үзвэл, энэ нь ямар нэгэн тодорхой төслийн онцлог шинж чанар биш юм ХАТУУ, энэ нь ерөнхийдөө CFM-ийн тухай юм, жишээлбэл, өөр төсөл дээр янз бүрийн Java, програмын сервер, мэдээллийн сан, үйлдлийн систем гэх мэт хайрцагласан Java програмыг байрлуулах шаардлагатай. Энэ жишээг ашиглан би цаашдын зарчмуудыг авч үзэх болно ХАТУУ

Манай тохиолдолд хэрэв бид imbjava эсвэл oraclejava үүргийг суулгасан бол бид java хоёртын executable програмтай болно гэсэн дэд бүтцийн баг дотор тохиролцсон байдаг. Энэ нь зайлшгүй шаардлагатай, учир нь Дээд талын үүрэг нь энэ зан төлөвөөс хамаардаг бөгөөд тэд java-г хүлээж байдаг; Үүний зэрэгцээ, энэ нь програмын байршуулалтын логикийг өөрчлөхгүйгээр нэг java хувилбарыг өөр хувилбараар солих боломжийг олгодог.

Энд байгаа асуудал нь үүнийг Ansible-д хэрэгжүүлэх боломжгүй байгаа бөгөөд үүний үр дүнд баг дотор зарим гэрээ хэлэлцээрүүд гарч ирдэг.

Интерфэйсийг тусгаарлах зарчим

Интерфэйсийг салгах зарчим: “Үйлчлүүлэгчид зориулсан олон интерфейс нь нэг ерөнхий зориулалтын интерфейсээс илүү сайн байдаг.

Эхэндээ бид програмыг байршуулах бүх өөрчлөлтийг нэг Ansible тоглоомын номонд оруулахыг хичээсэн боловч үүнийг дэмжихэд хэцүү байсан бөгөөд гадаад интерфейсийг зааж өгсөн үед (үйлчлүүлэгч порт 443 хүлээж байна) дараа нь дэд бүтцийг хувь хүнээс угсарч болно. тодорхой хэрэгжилтэнд зориулсан тоосго.

Хамааралтай урвуу байдлын зарчим

Хамааралтай урвуу байдлын зарчим. Дээд түвшний модуль нь доод түвшний модулиудаас хамаарах ёсгүй. Хоёр төрлийн модуль нь хийсвэрлэлээс хамаарах ёстой. Хийсвэрлэл нь нарийн ширийн зүйлээс хамаарах ёсгүй. Дэлгэрэнгүй мэдээлэл нь хийсвэрлэлээс хамаарах ёстой.

Энд жишээ нь эсрэг загвар дээр суурилсан болно.

1. Үйлчлүүлэгчдийн нэг нь хувийн үүлтэй байсан.
2. Бид үүлэн доторх виртуал машин захиалсан.
3. Гэхдээ үүлний шинж чанараас шалтгаалан програмын байршуулалт нь VM асаалттай байгаа гипервизортой холбоотой байв.

Тэдгээр. Өндөр түвшний програмыг байршуулах логик нь гипервизорын доод түвшний хамаарлаар урссан бөгөөд энэ нь энэ логикийг дахин ашиглахад асуудал үүсгэдэг гэсэн үг юм. Ингэж болохгүй.

харилцан үйлдэл

Кодын хувьд дэд бүтэц нь зөвхөн кодын тухай биш, харин код ба хүмүүсийн хоорондын харилцаа, дэд бүтцийг хөгжүүлэгчид хоорондын харилцан үйлчлэлийн тухай юм.

Автобусны хүчин зүйл

Таны төсөл дээр Вася байгаа гэж бодъё. Вася танай дэд бүтцийн талаар бүгдийг мэддэг, Вася гэнэт алга болвол юу болох вэ? Энэ бол үнэхээр бодит байдал, учир нь түүнийг автобус мөргөж магадгүй юм. Заримдаа ийм зүйл тохиолддог. Хэрэв ийм зүйл тохиолдвол код, түүний бүтэц, хэрхэн ажилладаг, гадаад төрх байдал, нууц үгийн талаархи мэдлэгийг багийн дунд түгээдэггүй бол та хэд хэдэн таагүй нөхцөл байдалтай тулгарч магадгүй юм. Эдгээр эрсдлийг багасгах, багийн доторх мэдлэгийг түгээхийн тулд та янз бүрийн аргыг ашиглаж болно

Хос Девопсинг

Тийм биш байна онигоо шиг, админууд шар айраг ууж, нууц үгээ сольж, хос програмчлалын аналог. Тэдгээр. Хоёр инженер нэг компьютер, нэг гар дээр суугаад дэд бүтцийг хамтад нь тохируулж эхэлнэ: сервер тохируулах, Ansible үүрэг бичих гэх мэт. Энэ нь сайхан сонсогдож байгаа ч энэ нь бидэнд тус болсонгүй. Гэхдээ энэ практикийн онцгой тохиолдлууд үр дүнд хүрсэн. Шинэ ажилтан ирлээ, түүний зөвлөгч түүнтэй хамт бодит ажлыг хийж, ажиллаж, мэдлэгээ шилжүүлдэг.

Өөр нэг онцгой тохиолдол бол ослын дуудлага юм. Асуудлын үеэр жижүүр болон холбогдох хүмүүс цугларч, дэлгэцээ хуваалцаж, сэтгэлгээний галт тэрэгний дуу хоолойг нэг удирдагч томилдог. Бусад оролцогчид удирдагчийн бодлыг дагаж, консолоос заль мэхийг тагнах, бүртгэлийн мөрийг алдаагүй эсэхийг шалгаж, системийн талаар шинэ зүйл сурдаг. Энэ арга нь ихэвчлэн ажилладаг байсан.

Код тойм

Субъектив байдлаар, дэд бүтцийн талаарх мэдлэгийг түгээх, кодын хяналтыг ашиглан хэрхэн ажилладаг талаар илүү үр дүнтэй байсан.

• Дэд бүтцийг хадгалах сан дахь кодоор тайлбарласан болно.
• Өөрчлөлтүүд нь тусдаа салбарт тохиолддог.
• Нэгтгэх хүсэлтийн үед та дэд бүтцийн өөрчлөлтийн гурвалжин хэсгийг харж болно.

Энд онцлох зүйл бол тоймчдыг хуваарийн дагуу нэг нэгээр нь сонгосон, i.e. тодорхой хэмжээгээр та дэд бүтцийн шинэ хэсэг рүү авирах магадлалтай.

Кодын хэв маяг

Цаг хугацаа өнгөрөхөд шүүмжлэлийн үеэр хэрүүл маргаан гарч эхэлсэн, учир нь... Шүүмжлэгчид өөрсдийн гэсэн хэв маягтай байсан бөгөөд шүүмжлэгчдийн ээлж нь тэдгээрийг өөр өөр хэв маягаар давхарласан: 2 зай эсвэл 4, camelCase эсвэл snake_case. Үүнийг шууд хэрэгжүүлэх боломжгүй байсан.

• Эхний санаа бол линтер ашиглахыг зөвлөсөн, эцэст нь хүн бүр инженер, хүн бүр ухаалаг байдаг. Гэхдээ өөр өөр редакторууд, OS нь тийм ч тохиромжтой биш юм
• Энэ нь асуудалтай үйлдэл болгоныг суллахын тулд бичиж, линтерийн гаралтыг хавсаргадаг робот болж хувирав. Гэхдээ ихэнх тохиолдолд хийх ёстой илүү чухал зүйлүүд байсан бөгөөд код нь засаагүй хэвээр байв.

Ногоон байгууламжийн мастер

Цаг хугацаа өнгөрч, бид тодорхой шалгалтыг даваагүй үйлдлийг мастерт оруулах боломжгүй гэсэн дүгнэлтэд хүрсэн. Voila! Бид програм хангамж боловсруулахад удаан хугацааны турш дадлагажсан Green Build Master-ийг зохион бүтээсэн:

• Тусдаа салбараар бүтээн байгуулалт өрнөж байна.
• Энэ сэдэв дээр туршилтууд явагдаж байна.
• Хэрэв туршилт амжилтгүй болвол код нь мастер руу орохгүй.

Энэ шийдвэрийг гаргах нь маш их зовлонтой байсан, учир нь... маш их маргаан үүсгэсэн, гэхдээ энэ нь үнэ цэнэтэй байсан, учир нь ... Шүүмж нь хэв маягийн ялгаагүйгээр нэгдэх хүсэлтийг хүлээн авч эхэлсэн бөгөөд цаг хугацаа өнгөрөхөд асуудалтай газруудын тоо буурч эхэлсэн.

IaC туршилт

Загварын шалгалтаас гадна та бусад зүйлсийг ашиглаж болно, жишээлбэл, таны дэд бүтцийг бодитоор ашиглаж чадах эсэхийг шалгах боломжтой. Эсвэл дэд бүтцийн өөрчлөлт нь мөнгө алдахад хүргэхгүй гэдгийг шалгаарай. Энэ яагаад хэрэгтэй байж болох вэ? Асуулт нь нарийн төвөгтэй бөгөөд философийн шинж чанартай тул ямар нэгэн байдлаар Powershell дээр хилийн нөхцөлийг шалгаагүй автомат масштаблагч байсан гэсэн түүхээр хариулсан нь дээр юм => шаардлагатай хэмжээнээс илүү олон VM бий болсон => үйлчлүүлэгч төлөвлөснөөс илүү их мөнгө зарцуулсан. Энэ нь тийм ч таатай биш боловч эхний үе шатанд энэ алдааг олж мэдэх боломжтой юм.

Яагаад нарийн төвөгтэй дэд бүтцийг улам нарийн төвөгтэй болгох ёстой гэж хэн нэгэн асууж магадгүй юм. Кодын нэгэн адил дэд бүтцийн туршилтууд нь хялбаршуулах тухай биш, харин дэд бүтэц тань хэрхэн ажиллах ёстойг мэдэх зорилготой юм.

IaC туршилтын пирамид

IaC тест: Статик шинжилгээ

Хэрэв та бүхэл бүтэн дэд бүтцийг нэг дор байрлуулж, ажиллаж байгаа эсэхийг шалгавал энэ нь маш их цаг хугацаа, маш их цаг хугацаа шаарддаг болохыг олж мэдэх болно. Тиймээс суурь нь хурдан ажилладаг зүйл байх ёстой, энэ нь маш их байдаг, энэ нь маш олон эртний газрыг хамардаг.

Баш бол төвөгтэй

Өчүүхэн жишээ авч үзье. одоогийн директор доторх бүх файлыг сонгоод өөр байршил руу хуулна уу. Хамгийн түрүүнд санаанд орж ирдэг зүйл:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Файлын нэрэнд хоосон зай байвал яах вэ? За, бид ухаалаг, бид ишлэлийг хэрхэн ашиглахаа мэддэг:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Сайн хийлээ? Үгүй! Хэрэв лавлахад юу ч байхгүй бол яах вэ, i.e. глобинг ажиллахгүй.

find . -type f -exec mv -v {} dst/{}.bak ;

Одоо сайн байна уу? Үгүй ээ... Файлын нэрэнд юу байж болохыг мартсан байна n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Статик шинжилгээний хэрэгслүүд

Өмнөх алхамын асуудал нь бид ишлэлийг мартсан үед баригдаж магадгүй тул үүнийг арилгах олон арга байдаг. Shellcheck, ерөнхийдөө тэдгээр нь маш олон байдаг бөгөөд та IDE-ийн доор стекдээ зориулж линтер олох боломжтой.

хэл
арга хэрэгсэл

bash
Shellcheck

Ruby
RuboCop

Python
Пилинт

ойлгомжгүй
Ansible Lint

IaC туршилт: Нэгжийн туршилтууд

Өмнөх жишээнээс харахад линтер нь бүхнийг чадагч биш бөгөөд бүх асуудлын талбарыг зааж чадахгүй. Цаашилбал, програм хангамжийн хөгжүүлэлтийн туршилттай адилтгах замаар бид нэгжийн тестүүдийг эргэн санах боломжтой. Тэр даруй санаанд орж ирдэг зүйл үүнийгт, харш, rspec, питест. Гэхдээ ansible, тогооч, saltstack болон бусад хүмүүстэй юу хийх вэ?

Хамгийн эхэнд бид ярилцсан ХАТУУ мөн манай дэд бүтэц жижиг тоосгоноос бүрдэх ёстой. Тэдний цаг ирлээ.

1. Дэд бүтэц нь жижиг тоосгонуудад хуваагддаг, жишээлбэл, Ansible үүрэг.
2. Докер эсвэл VM гэх мэт зарим төрлийн орчинг байрлуулсан.
3. Бид энэ туршилтын орчинд Ansible үүргээ хэрэгжүүлдэг.
4. Бүх зүйл бидний бодож байсан шиг ажиллаж байгаа эсэхийг шалгадаг (бид туршилт явуулдаг).
5. Бид зүгээр үү, үгүй ​​юу гэдгээ шийднэ.

IaC тест: Нэгжийн туршилтын хэрэгслүүд

Асуулт, CFM-ийн шинжилгээ гэж юу вэ? Та зүгээр л скриптийг ажиллуулж болно, эсвэл үүнд бэлэн шийдлүүдийг ашиглаж болно:

CFM
арга хэрэгсэл

Алгасах
Testinfra

дарга
Шалгах

дарга
Серверийн онцлог

давсны сав
Хов жив

Хэрэглэгчдийг шалгаж байгаа testinfra-ийн жишээ test1, test2 байдаг ба бүлэгт байдаг sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Юу сонгох вэ? Асуулт нь төвөгтэй бөгөөд хоёрдмол утгатай тул 2018-2019 оны github дээрх төслүүдэд гарсан өөрчлөлтүүдийн жишээг энд харуулав.

IaC Туршилтын хүрээ

Асуулт гарч ирнэ: яаж бүгдийг нь нэгтгэж, эхлүүлэх вэ? Чадах үүнийг аваад өөрөө хий хангалттай тооны инженер байгаа бол. Эсвэл та бэлэн шийдлүүдийг авч болно, гэхдээ тэдгээр нь тийм ч олон биш юм.

CFM
арга хэрэгсэл

Алгасах
Молекул

дарга
Туршилтын гал тогоо

Терраформ
Терратест

2018-2019 оны github дээрх төслүүдийн өөрчлөлтийн жишээ:

Молекул vs. Туршилтын гал тогоо

Эхэндээ бид testkitchen ашиглаж үзсэн:

1. Зэрэгцээ VM үүсгэх.
2. Ansible дүрүүдийг ашиглах.
3. Шалгалт явуулах.

25-35 дүрд 40-70 минут ажилласан нь урт байсан.

Дараагийн алхам бол jenkins/docker/ansible/molecule руу шилжих явдал байв. Үзэл санааны хувьд бүх зүйл адилхан

1. Lint тоглоомын дэвтэр.
2. Дүрүүдийг жагсаа.
3. Контейнер хөөргөх
4. Ansible дүрүүдийг ашиглах.
5. Testinfra ажиллуулна уу.
6. Идэвхгүй байдлыг шалгах.

40 дүрд линтинг, арваад дүрд зориулсан туршилтууд 15 минут орчим үргэлжилж эхлэв.

Юу сонгох нь ашигласан стек, багийн туршлага гэх мэт олон хүчин зүйлээс хамаарна. Энд хүн бүр Нэгжийн тестийн асуултыг хэрхэн хаахыг өөрөө шийддэг

IaC тест: Интеграцийн тестүүд

Дэд бүтцийн туршилтын пирамидын дараагийн алхам нь интеграцийн туршилтууд байх болно. Эдгээр нь нэгжийн тесттэй төстэй:

1. Дэд бүтэц нь жижиг тоосгонуудад хуваагддаг, жишээлбэл Ansible үүрэг.
2. Докер эсвэл VM гэх мэт зарим төрлийн орчинг байрлуулсан.
3. Энэ туршилтын орчинд хэрэглэнэ баглаа Хариуцлагатай дүрүүд.
4. Бүх зүйл бидний бодож байсан шиг ажиллаж байгаа эсэхийг шалгадаг (бид туршилт явуулдаг).
5. Бид зүгээр үү, үгүй ​​юу гэдгээ шийднэ.

Товчоор хэлбэл, бид нэгжийн туршилтын нэгэн адил системийн бие даасан элементийн гүйцэтгэлийг шалгадаггүй, сервер бүхэлдээ хэрхэн тохируулагдсаныг шалгадаг.

IaC Туршилт: Төгсгөл хүртэлх туршилтууд

Пирамидын оройд биднийг Төгсгөл хүртэл тестүүд угтаж байна. Тэдгээр. Бид тусдаа сервер, тусдаа скрипт эсвэл дэд бүтцийн тусдаа тоосгоны гүйцэтгэлийг шалгадаггүй. Бид олон серверүүд хоорондоо холбогдсон эсэхийг шалгадаг бөгөөд манай дэд бүтэц бидний бодож байгаагаар ажилладаг. Харамсалтай нь, би хэзээ ч бэлэн хайрцагтай шийдлүүдийг харж байгаагүй, магадгүй ... Дэд бүтэц нь ихэвчлэн өвөрмөц бөгөөд загварчлах, туршилтын хүрээг бий болгоход хэцүү байдаг. Үүний үр дүнд хүн бүр өөр өөрийн шийдлийг бий болгодог. Шаардлага байгаа ч хариу алга. Тиймээс, бүх зүйлийг эрт дээр үеэс биднээс өмнө зохион бүтээсэн гэж бусдыг бодлуудад түлхэх эсвэл хамраа үрэхийн тулд юу байдгийг би танд хэлье.

Арвин түүхтэй төсөл. Энэ нь томоохон байгууллагуудад хэрэглэгддэг бөгөөд магадгүй та бүгд шууд бусаар зам хөндлөн огтлолцсон байх. Энэхүү програм нь олон мэдээллийн сан, интеграцчлал гэх мэтийг дэмждэг. Дэд бүтэц ямар харагдахыг мэдэх нь олон тооны докер-бүрдүүлэх файлууд, ямар орчинд ямар тест ажиллуулахыг Женкинс гэдгийг мэдэх явдал юм.

Энэ схем нь нэлээд удаан хугацаанд, хүрээн доторх хүртэл ажилласан судалгаа Бид үүнийг Openshift руу шилжүүлэх гэж оролдоогүй. Савнууд нь ижил хэвээр байгаа боловч хөөргөх орчин өөрчлөгдсөн (дахин сайн уу DRY).

Судалгааны санаа улам урагшилж, нээлттэй ээлжинд тэд APB (Ansible Playbook Bundle) гэх мэт зүйлийг олсон бөгөөд энэ нь дэд бүтцийг контейнерт хэрхэн байрлуулах талаархи мэдлэгийг багцлах боломжийг олгодог. Тэдгээр. дэд бүтцийг хэрхэн байршуулах талаар дахин давтагдах, шалгах боломжтой мэдлэгийн цэг байдаг.

Бид нэг төрлийн бус дэд бүтцэд орох хүртэл энэ бүхэн сайн сонсогдож байсан: туршилт хийхэд Windows хэрэгтэй байсан. Үүний үр дүнд юуг, хаана, хэрхэн байрлуулах, турших тухай мэдлэг Женкинст байдаг.

Дүгнэлт

Код шиг дэд бүтэц

• Хадгалах газар дахь код.
• Хүний харилцан үйлчлэл.
• Дэд бүтцийн туршилт.

холбоосууд

• Англи хувилбар
• Хувийн блогоос хөндлөн нийтлэл
• Хуурай гүйлт 2019-04-24 SpbLUG
• DevopsConf-ийн 2019-05-28-ны өдрийн видео (RU).
• DINS DevOps EVENING 2019-06-20-ны видео(RU).
• Дэд бүтцийн кодыг 300,000 гаруй мөр бичихээс авсан сургамж & текст хувилбар
• Дэд бүтцийг код болгон тасралтгүй нийлүүлэх хоолойд нэгтгэх
• Дэд бүтцийг код болгон турших
• Ansible-ийн үүргийг үр дүнтэй хөгжүүлэх, засвар үйлчилгээ хийх
• Ansible бол bash биш!

Эх сурвалж: www.habr.com