Бид блогоо техникийн захирлынхаа сүүлийн үеийн хэлсэн үгэнд үндэслэсэн нийтлэлүүдээр эхлүүлэх болно (Дмитрий Столяров). Эдгээр нь бүгд 2016 онд мэргэжлийн янз бүрийн арга хэмжээнд болсон бөгөөд DevOps болон Docker-ийн сэдэвт зориулагдсан байв. Badoo оффис дээр болсон Докер Москвагийн уулзалтын нэг видеог бид аль хэдийн авсан Онлайн. Шинэ мэдээг тайлангийн мөн чанарыг агуулсан нийтлэлүүд дагалдуулна. Тиймээс…
31-р сарын XNUMX-ний чуулган дээр , "Оросын Интернет Технологи" (RIT++ 2016) наадмын хүрээнд зохион байгуулагдсан "Тасралтгүй байршуулалт ба байршуулалт" хэсгийг "Докер ашиглан тасралтгүй хүргэх шилдэг туршлага" илтгэлээр нээв. Энэ нь Docker болон бусад Нээлттэй эхийн бүтээгдэхүүнийг ашиглан тасралтгүй хүргэх (CD) үйл явцыг бий болгох шилдэг туршлагуудыг нэгтгэн дүгнэж, системчилсэн. Бид эдгээр шийдлүүдтэй үйлдвэрлэлд ажилладаг бөгөөд энэ нь практик туршлагад найдах боломжийг бидэнд олгодог.
Хэрэв танд нэг цаг зарцуулах боломж байгаа бол , бид үүнийг бүрэн эхээр нь үзэхийг зөвлөж байна. Үгүй бол текст хэлбэрээр гол хураангуйг доор харуулав.
Docker-тэй тасралтгүй хүргэлт
Нь Тасралтгүй хүргэлт Git репозитороос програмын код эхлээд үйлдвэрлэлд орж, дараа нь архивт дуусдаг үйл явдлын гинжин хэлхээг бид ойлгож байна. Энэ нь дараах байдалтай харагдаж байна. Git → Build → Test → Release → Operate.
Тайлангийн ихэнх хэсэг нь бүтээх үе шатанд (хэрэглээний угсралт) зориулагдсан бөгөөд гаргах, ажиллуулах сэдвүүдийг товчхон хөндсөн болно. Бид тэдгээрийг шийдвэрлэх боломжийг олгодог асуудал, хэв маягийн талаар ярих бөгөөд эдгээр хэв маягийн тодорхой хэрэгжилт өөр байж болно.
Докер яагаад энд хэрэгтэй байна вэ? Бид энэхүү Нээлттэй эхийн хэрэглүүрийн хүрээнд Тасралтгүй хүргэх практикийн талаар ярихаар шийдсэн нь хоосон биш юм. Хэдийгээр бүх тайлан нь түүний хэрэглээнд зориулагдсан боловч програмын кодыг нэвтрүүлэх үндсэн хэв маягийг авч үзэхэд олон шалтгаан илчлэгддэг.
Дамжуулах үндсэн загвар
Тиймээс, бид програмын шинэ хувилбаруудыг гаргах үед бид мэдээж тулгардаг сул зогсолтын асуудал, үйлдвэрлэлийн серверийг солих үед үүссэн. Аппликешны хуучин хувилбараас шинэ хувилбар руу шилжих хөдөлгөөн шууд шилжих боломжгүй: эхлээд бид шинэ хувилбарыг амжилттай татаж аваад зогсохгүй "дулаацсан" (жишээ нь хүсэлтэд бүрэн бэлэн болсон) эсэхийг шалгах хэрэгтэй.
Тиймээс хэсэг хугацаанд програмын хоёр хувилбар (хуучин ба шинэ) нэгэн зэрэг ажиллах болно. Энэ нь автоматаар хүргэдэг хуваалцсан нөөцийн зөрчил: сүлжээ, файлын систем, IPC гэх мэт. Docker-ийн тусламжтайгаар програмын өөр өөр хувилбаруудыг тусад нь саванд ажиллуулснаар энэ асуудлыг хялбархан шийддэг бөгөөд эдгээрийн хувьд нэг хост (сервер/виртуал машин) дотор нөөц тусгаарлалтыг баталгаажуулдаг. Мэдээжийн хэрэг, та ямар нэгэн заль мэхийг ямар ч дулаалгагүйгээр даван туулж чадна, гэхдээ бэлэн, тохиромжтой хэрэгсэл байгаа бол үүнийг үл тоомсорлож болохгүй гэсэн эсрэг шалтгаан бий.
Контейнержуулалт нь ашиглалтад орсноор бусад олон давуу талыг өгдөг. Аливаа програм нь үүнээс хамаарна тодорхой хувилбар (эсвэл хувилбарын хүрээ) орчуулагч, модулиуд/өргөтгөл гэх мэт боломжууд, түүнчлэн тэдгээрийн хувилбарууд. Энэ нь зөвхөн шууд гүйцэтгэх боломжтой орчинд төдийгүй бүхэл бүтэн хүрээлэн буй орчинд хамаарна системийн програм хангамж болон түүний хувилбар (ашигласан Линукс түгээлт хүртэл). Контейнер нь зөвхөн програмын код төдийгүй шаардлагатай хувилбаруудын урьдчилан суулгасан систем, хэрэглээний программ хангамжийг агуулдаг тул хамааралтай холбоотой асуудлуудыг мартаж болно.
Дүгнэлт үндсэн танилцуулах загвар дараах хүчин зүйлсийг харгалзан шинэ хувилбарууд:
- Эхлээд програмын хуучин хувилбар нь эхний саванд ажилладаг.
- Дараа нь шинэ хувилбарыг өнхрүүлж, хоёр дахь саванд "дулаацуулна". Энэхүү шинэ хувилбар нь зөвхөн шинэчлэгдсэн програмын кодыг төдийгүй түүний хамаарал, системийн бүрэлдэхүүн хэсгүүдийг (жишээлбэл, OpenSSL-ийн шинэ хувилбар эсвэл бүхэл бүтэн түгээлт) агуулж болох нь анхаарал татаж байна.
- Шинэ хувилбар нь хүсэлт гаргахад бүрэн бэлэн болмогц урсгал эхний контейнерээс хоёр дахь руу шилжинэ.
- Хуучин хувилбарыг одоо зогсоож болно.
Тусдаа саванд програмын янз бүрийн хувилбаруудыг байрлуулах энэхүү арга нь өөр нэг ая тухыг хангадаг. хурдан буцаах хуучин хувилбар руу (эцэст нь урсгалыг хүссэн контейнер рүү шилжүүлэхэд хангалттай).
Эцсийн эхний зөвлөмж нь ахмад хүртэл буруугаа олж чадаагүй мэт санагдаж байна: "[Docker-тэй тасралтгүй хүргэлтийг зохион байгуулах үед] Docker ашиглах [мөн юу өгч байгааг ойлгох]" Энэ бол асуудал бүрийг шийдэх мөнгөн сум биш, харин гайхалтай суурийг бүрдүүлдэг хэрэгсэл гэдгийг санаарай.
Дахин үржих чадвар
"Дахин давтагдах чадвар" гэж бид програмуудыг ажиллуулахад тулгардаг ерөнхий асуудлуудыг хэлнэ. Бид ийм тохиолдлын талаар ярьж байна:
- Чанарын хэлтсээс шалгасан скриптүүд нь үйлдвэрлэлд үнэн зөв хуулбарлагдсан байх ёстой.
- Програмууд нь өөр өөр репозиторын толин тусгалуудаас багц хүлээн авах боломжтой серверүүд дээр нийтлэгддэг (цаг хугацааны явцад тэдгээр нь шинэчлэгдэж, суулгасан програмуудын хувилбарууд байдаг).
- "Орон нутагт бүх зүйл миний төлөө ажилладаг!" (...болон хөгжүүлэгчдийг үйлдвэрлэлд оруулахыг хориглоно.)
- Та хуучин (архивлагдсан) хувилбарт ямар нэг зүйлийг шалгах хэрэгтэй.
- ...
Тэдний ерөнхий мөн чанар нь ашигласан орчныг бүрэн дагаж мөрдөх (мөн хүний хүчин зүйл байхгүй) зайлшгүй шаардлагатай гэсэн үг юм. Бид нөхөн үржихүйн баталгааг хэрхэн хангах вэ? Docker-ийн зураг хийх Git-ийн код дээр тулгуурлан, дараа нь тэдгээрийг ямар ч ажилд ашиглах: туршилтын сайтууд, үйлдвэрлэл, програмистуудын орон нутгийн машинууд ... Үүний зэрэгцээ гүйцэтгэсэн үйлдлүүдийг багасгах нь чухал юм. после зургийг угсарч байна: энэ нь энгийн байх тусам алдаа гарах магадлал бага байна.
Дэд бүтэц бол код юм
Хэрэв дэд бүтцийн шаардлага (серверийн програм хангамжийн бэлэн байдал, түүний хувилбар гэх мэт) албан ёсоор тодорхойлогдоогүй бөгөөд "програмчлаагүй" бол аливаа програмын шинэчлэлтийг нэвтрүүлэх нь гамшигт үр дагаварт хүргэж болзошгүй юм. Жишээлбэл, та PHP 7.0 руу шилжиж, кодыг нь дахин бичсэн байх жишээтэй - хуучин PHP (5.5) дээр гарч ирэх нь хэн нэгнийг гайхшруулах нь гарцаагүй. Орчуулагчийн хувилбарт гарсан томоохон өөрчлөлтийг та мартаж болохгүй, гэхдээ "чөтгөр нь нарийн ширийн зүйлд байдаг": гэнэтийн зүйл нь аливаа хараат байдлын жижиг шинэчлэлт байж магадгүй юм.
Энэ асуудлыг шийдэх арга барил гэж нэрлэгддэг IaC (Дэд бүтэц нь код, "дэд бүтэц нь код") мөн дэд бүтцийн шаардлагыг програмын кодын хамт хадгалахыг хамарна. Үүнийг ашигласнаар хөгжүүлэгчид болон DevOps-ийн мэргэжилтнүүд ижил Git програмын репозитортой ажиллах боломжтой, гэхдээ түүний өөр өөр хэсгүүд дээр. Энэ кодоос Git дээр Docker дүрсийг үүсгэсэн бөгөөд үүнд дэд бүтцийн бүх онцлогийг харгалзан програмыг байрлуулдаг. Энгийнээр хэлэхэд, зураг угсрах скриптүүд (дүрэм) нь эх кодтой нэг репозиторт байх ёстой бөгөөд нэгтгэсэн байх ёстой.
Олон давхаргат програмын архитектурын хувьд - жишээлбэл, Docker контейнер дотор аль хэдийн ажиллаж байгаа програмын өмнө байрладаг nginx байдаг - Докерын зургийг давхарга бүрт Git дэх кодоос үүсгэх ёстой. Дараа нь эхний зураг нь орчуулагч болон бусад "ойр" хамаарлууд бүхий програмыг агуулж байх бөгөөд хоёр дахь зураг нь дээд талын nginx-г агуулна.
Докерын зургууд, Git-тэй харилцах
Бид Git-ээс цуглуулсан бүх Docker зургийг түр зуурын болон хувилбар гэсэн хоёр ангилалд хуваадаг. Түр зуурын зургууд Гит дэх салбарын нэрээр тэмдэглэгдсэн, дараагийн амлалтаар дарж бичих боломжтой бөгөөд зөвхөн урьдчилан үзэх зорилгоор (үйлдвэрлэлийн зориулалтаар биш) гаргадаг. Энэ бол тэдний гаргасан хувилбаруудаас гол ялгаа нь: та тэдгээрийн дотор ямар үүрэг даалгавар байгааг хэзээ ч мэдэхгүй.
Түр зуурын зургуудыг цуглуулах нь утга учиртай: мастер салбар (мастерын одоогийн хувилбарыг байнга харахын тулд үүнийг автоматаар тусдаа сайт руу шилжүүлж болно), хувилбарууд бүхий салбарууд, тодорхой шинэлэг зүйлүүдийн салбарууд.
Түр зуурын зургуудыг урьдчилж үзээд үйлдвэрлэл рүү орчуулах хэрэгцээ гарч ирсний дараа хөгжүүлэгчид тодорхой шошго тавьдаг. Шошгоор автоматаар цуглуулдаг зураг гаргах (түүний шошго нь Git-ийн шошготой тохирч байна) ба тайз руу шилжүүлсэн. Чанарын хэлтсээс амжилттай шалгагдвал үйлдвэрлэлд ордог.
дап
Тайлбарласан бүх зүйлийг (өнхрөх, зургийн угсралт, дараагийн засвар үйлчилгээ) Bash скрипт болон бусад "бичмэл" хэрэгслийг ашиглан бие даан хэрэгжүүлж болно. Гэхдээ хэрэв та үүнийг хийвэл хэзээ нэгэн цагт хэрэгжилт нь маш нарийн төвөгтэй байдал, хяналт муутай байх болно. Үүнийг ойлгосноор бид CI/CD бүтээх өөрийн тусгай ажлын урсгалын хэрэгслийг бий болгохоор ирсэн. дап.
Түүний эх код нь Ruby хэл дээр бичигдсэн, нээлттэй эх сурвалж бөгөөд дээр нийтлэгдсэн . Харамсалтай нь баримтжуулалт нь одоогоор хэрэгслийн хамгийн сул тал боловч бид үүн дээр ажиллаж байна. Тэгээд бид даппын талаар нэг бус удаа бичиж, ярих болно, учир нь ... Бид түүний чадавхийг сонирхсон олон нийттэй хуваалцахыг тэсэн ядан хүлээж байна, гэхдээ энэ хооронд асуудлаа илгээж, хүсэлтээ хүлээн авах ба/эсвэл GitHub дээрх төслийн хөгжлийг дагана уу.
13 оны 2019-р сарын XNUMX-нд шинэчлэгдсэн: одоогоор төсөл дап гэж өөрчилсөн , түүний кодыг Go программ дээр бүрэн шинэчилсэн бөгөөд баримтжуулалт нь мэдэгдэхүйц сайжирсан.
Kubernetes
Мэргэжлийн орчинд нэлээд нэр хүндтэй болсон өөр нэг бэлэн Нээлттэй эхийн хэрэгсэл юм Kubernetes, Docker удирдлагын кластер. Докер дээр бүтээгдсэн төслүүдийн үйл ажиллагаанд ашиглах сэдэв нь тайлангийн хамрах хүрээнээс гадуур байгаа тул танилцуулга нь зарим сонирхолтой шинж чанаруудын тоймоор хязгаарлагддаг.
Дамжуулахын тулд Kubernetes санал болгож байна:
- бэлэн байдлын шалгалт - програмын шинэ хувилбарын бэлэн байдлыг шалгах (түүн рүү урсгалыг шилжүүлэх);
- гулсмал шинэчлэлт - контейнерийн кластер дахь дараалсан зургийн шинэчлэлт (унтраах, шинэчлэх, хөөргөх бэлтгэл, хөдөлгөөнийг солих);
- синхрон шинэчлэлт - кластер дахь зургийг өөр арга барилаар шинэчлэх: эхлээд савны тал дээр, дараа нь үлдсэн хэсэгт;
- канарын хувилбарууд - хэвийн бус байдлыг хянахын тулд хязгаарлагдмал (бага) тооны саванд шинэ зураг гаргах.
Тасралтгүй хүргэлт нь зөвхөн шинэ хувилбар биш тул Кубернетес нь дараагийн дэд бүтцийн засвар үйлчилгээ хийх хэд хэдэн боломжуудтай: бүх контейнерт суурилуулсан хяналт, бүртгэл, автомат масштабтай гэх мэт. Энэ бүхэн аль хэдийн ажиллаж байгаа бөгөөд зүгээр л тохирохыг хүлээж байна. үйл явцдаа хэрэгжүүлэх.
Эцсийн зөвлөмжүүд
- Docker ашиглах.
- Өөрийн бүх хэрэгцээнд нийцүүлэн Docker-ийн аппликешны зургийг үүсгэ.
- “Дэд бүтэц бол код” гэсэн зарчмыг баримтал.
- Git-г Docker руу холбоно уу.
- Дамжуулах дарааллыг зохицуулах.
- Бэлэн платформыг ашиглана уу (Кубернетес эсвэл өөр).
Видео болон слайд
Тоглолтын видео (нэг цаг орчим) (мэдээлэл өөрөө 5 дахь минутаас эхэлдэг - энэ мөчөөс эхлэн тоглохын тулд холбоосыг дагана уу).
Илтгэлийн танилцуулга:
PS
Манай блог дээрх сэдвийн талаархи бусад тайлангууд:
- «» (Дмитрий Столяров; 27 оны 2019-р сарын XNUMX-нд DevOpsConf дээр);
- «» (Дмитрий Столяров; 8 оны 2018-р сарын XNUMX, HighLoad++ дээр);
- «» (Дмитрий Столяров; 7 оны 2017-р сарын XNUMX, HighLoad++ дээр);
- «» (Дмитрий Столяров; 6 оны 2017-р сарын XNUMX-нд RootConf дээр).
Эх сурвалж: www.habr.com