Арван хоёр хүчин зүйлийн хэрэглүүрийн арга зүйд тулгуурлан php болон docker дээрх жишээн дээр суурилсан програм хөгжүүлэлт ба Цэнхэр-Ногоон хэрэглээ.

Нэгдүгээрт, бага зэрэг онол. Юу болов Арван хоёр хүчин зүйлийн програм?

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

Энэхүү баримт бичгийг Heroku платформын хөгжүүлэгчид бүтээжээ.

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

Энэхүү аргачлалд үндэслэсэн хүчин зүйлсийн талаар товч дурдвал:

1. Кодын сан – Хувилбарын удирдлагад хянагддаг нэг кодын бааз – олон байршуулалт
2. Хараат байдал – Хараат байдлыг тодорхой зарлаж, тусгаарлах
3. Тохиргоо - Ажиллах хугацаанд тохиргоог хадгалах
4. Туслах үйлчилгээ – Дэмжлэгийн үйлчилгээг залгаасуудын эх үүсвэр гэж үзэх
5. Барилга, суллах, ажиллуулах – Угсрах болон гүйцэтгэх үе шатыг хатуу тусгаарла
6. Үйл явц – Програмыг нэг буюу хэд хэдэн харьяалалгүй процесс хэлбэрээр ажиллуул
7. Порт холбох – Порт холболтоор дамжуулан үйлчилгээг экспортлох
8. Зэрэгцээ байдал – Процессыг ашиглан програмаа томруулна уу
9. Нэг удаагийн хэрэглээ – Хурдан эхлүүлэх, цэвэр унтрах зэргээр найдвартай байдлыг дээд зэргээр нэмэгдүүлэх
10. Хэрэглээний хөгжүүлэлт/үйл ажиллагааны паритет – Өөрийн хөгжүүлэлт, үе шат, үйлдвэрлэлийн орчинг аль болох ижил байлгах
11. Мод бэлтгэх – Бүртгэлийг үйл явдлын урсгал хэлбэрээр харах
12. Захиргааны даалгавар – Түр зуурын процессуудыг ашиглан удирдлага/удирдлагын ажлыг гүйцэтгэх

Та дараах эх сурвалжаас 12 хүчин зүйлийн талаар дэлгэрэнгүй мэдээлэл авах боломжтой.

• Албан ёсны эх сурвалж - заавал унших ёстой
• Habr-ийн тухай нийтлэл. Арван хоёр хүчин зүйлийн програм - албан ёсны орчуулга
• Habr-ийн тухай нийтлэл. 7 хүчин зүйлийн аппликейшнд дутагдаж буй 12 хүчин зүйл - 12 хүчин зүйлийг сайжруулах зорилгоор шинэлэг байдлаар харах.

Цэнхэр-Ногоон байршуулалт гэж юу вэ?

Цэнхэр-Ногоон байршуулалт нь програмыг хүргэх арга юм үйлдвэрлэл эцсийн үйлчлүүлэгч өөрийн зүгээс ямар нэгэн өөрчлөлтийг харахгүй байхаар. Өөрөөр хэлбэл, тэгтэй програмыг байршуулах цаг хугацаа.

Сонгодог BG Deploy схем нь доорх зурагт үзүүлсэн шиг харагдаж байна.

• Эхэндээ яг ижил код, програм, төсөл бүхий 2 физик сервер, чиглүүлэгч (тэнцвэржүүлэгч) байдаг.
• Чиглүүлэгч нь эхлээд бүх хүсэлтийг серверүүдийн аль нэгэнд чиглүүлдэг (ногоон).
• Та дахин гаргах шаардлагатай үед төслийг бүхэлд нь өөр сервер дээр шинэчилж байна (цэнхэр), одоогоор ямар ч хүсэлтийг боловсруулаагүй байна.
• Код асаалттай болсны дараа цэнхэр сервер бүрэн шинэчлэгдсэн тул чиглүүлэгчид шилжих командыг өгнө ногоон тухай цэнхэр сервер.
• Одоо бүх үйлчлүүлэгчид ажиллаж байгаа кодын үр дүнг харж байна цэнхэр сервер.
• Хэсэг хугацаанд, ногоон сервер нь амжилтгүй байршуулсан тохиолдолд нөөц хуулбараар үйлчилнэ цэнхэр сервер бөгөөд алдаа, алдаа гарсан тохиолдолд чиглүүлэгч нь хэрэглэгчийн урсгалыг буцаан шилжүүлдэг ногоон серверийг хуучин тогтвортой хувилбартай, шинэ кодыг засварлаж, туршихаар илгээдэг.
• Мөн үйл явцын төгсгөлд энэ нь ижил аргаар шинэчлэгддэг ногоон сервер. Үүнийг шинэчилсэний дараа чиглүүлэгч нь хүсэлтийн урсгалыг буцаан шилжүүлдэг ногоон сервер.

Энэ бүхэн маш сайхан харагдаж байгаа бөгөөд эхлээд харахад ямар ч асуудал гарах ёсгүй.
Гэхдээ бид орчин үеийн ертөнцөд амьдарч байгаа тул сонгодог схемд заасан физик солих сонголт бидэнд тохирохгүй байна. Одоогоор мэдээллийг бичээрэй, бид дараа нь буцах болно.

Муу, сайн зөвлөгөө

Disclaimer: Доорх жишээнүүд нь миний ашигладаг хэрэгслүүд/арга зүйг харуулж байгаа тул та ижил төстэй функцтэй ямар ч хувилбарыг ашиглаж болно.

Ихэнх жишээнүүд нь вэб хөгжүүлэлттэй (энэ бол гэнэтийн зүйл), PHP болон Docker-тэй огтлолцох болно.

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

1. Кодын сан

Файлуудыг серверт нэг нэгээр нь оруулахын тулд FTP болон FileZilla ашиглана уу, кодыг үйлдвэрлэлийн серверээс өөр газар бүү хадгал.

Төсөл нь үргэлж нэг кодын суурьтай байх ёстой, өөрөөр хэлбэл бүх код нэгээс ирдэг явах хадгалах газар. Серверүүд (үйлдвэрлэл, үе шат, тест1, тест2...) нэг нийтлэг репозиторийн салбаруудын кодыг ашигладаг. Ингэснээр бид кодын тогтвортой байдалд хүрдэг.

2. Хамааралтай байдал

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

Төсөл нь үргэлж ойлгомжтой хамааралтай хамааралтай жагсаалттай байх ёстой (хамаарал гэж би мөн хүрээлэн буй орчныг хэлж байна). Бүх хамаарлыг тодорхой тодорхойлж, тусгаарлах ёстой.
Үүнийг жишээ болгон авч үзье хөгжмийн зохиолч и Docker.

хөгжмийн зохиолч — PHP дээр номын санг суулгах боломжийг олгодог багц менежер. Composer нь хувилбаруудыг хатуу эсвэл чөлөөтэй зааж өгөх, тэдгээрийг тодорхой тодорхойлох боломжийг олгодог. Сервер дээр 20 өөр төсөл байж болох бөгөөд тус бүр нь нөгөөгөөсөө хамааралгүй багц, номын сангийн хувийн жагсаалттай байх болно.

Docker — програмыг ажиллуулах орчныг тодорхойлж, тусгаарлах боломжийг олгодог хэрэгсэл. Үүний дагуу, хөгжмийн зохиолчтой адил боловч програм нь юутай ажилладагийг илүү нарийвчлан тодорхойлох боломжтой. PHP-ийн тодорхой хувилбарыг сонгоод, нэмэлт зүйл нэмэхгүйгээр зөвхөн төсөлд шаардлагатай багцуудыг суулгаарай. Хамгийн гол нь хост машин болон бусад төслүүдийн багц, орчинд саад учруулахгүйгээр. Өөрөөр хэлбэл, Docker-ээр ажилладаг сервер дээрх бүх төслүүд нь ямар ч багц багц, огт өөр орчинг ашиглаж болно.

3. Тохиргоо

Тохиргоог шууд кодод тогтмол болгон хадгална. Туршилтын серверт зориулж тусдаа тогтмолуудыг үйлдвэрлэхэд тусад нь. Орчноос хамаарч программын ажиллагааг if else Builds ашиглан төслийн бизнесийн логикт шууд холбоно.

Тохиргоо - Энэ бол төслийн байршуулалт ялгаатай байх цорын ганц арга зам юм. Хамгийн тохиромжтой нь тохиргоог орчны хувьсагчаар (env vars) дамжуулсан байх ёстой.

Өөрөөр хэлбэл, та хэд хэдэн .config.prod .config.local тохиргооны файлуудыг хадгалж, тэдгээрийг байршуулах үед .config (програмын өгөгдлийг уншдаг үндсэн тохиргоо) болгон нэрийг нь өөрчилсөн ч энэ нь зөв хандлага биш байх болно. Энэ тохиолдолд тохиргооны мэдээлэл нь бүх програм хөгжүүлэгчдэд нээлттэй байх бөгөөд үйлдвэрлэлийн серверийн өгөгдөл алдагдах болно. Бүх тохиргоог шууд байршуулах системд (CI/CD) хадгалж, байршуулах үед тодорхой орчинд шаардлагатай өөр өөр утгууд бүхий өөр өөр орчинд зориулж үүсгэсэн байх ёстой.

4. Гуравдагч этгээдийн үйлчилгээ

Хүрээлэн буй орчинтойгоо нягт холбоотой байх, тодорхой орчинд ижил үйлчилгээнд өөр өөр холболт ашиглах.

Үнэн хэрэгтээ энэ цэг нь тохиргооны тухай цэгтэй маш их давхцаж байгаа тул энэ цэггүйгээр ердийн тохиргооны өгөгдлийг хийх боломжгүй бөгөөд ерөнхийдөө тохируулах чадвар нь юу ч биш болно.

Дарааллын серверүүд, мэдээллийн сан, кэшийн үйлчилгээ зэрэг гадаад үйлчилгээтэй холбогдох бүх холболтууд нь дотоод орчин болон гуравдагч талын / үйлдвэрлэлийн орчинд ижил байх ёстой. Өөрөөр хэлбэл, би хүссэн үедээ холболтын мөрийг өөрчилснөөр програмын кодыг өөрчлөхгүйгээр 1-р бааз руу залгасан дуудлагыг 2-р суурь болгон сольж болно. Эсвэл, жишээ болгон, үйлчилгээгээ өргөжүүлэхдээ нэмэлт кэш серверийн холболтыг тусгай аргаар зааж өгөх шаардлагагүй болно.

5. Бүтээх, гаргах, гүйцэтгэх

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

Байршуулах бүх үе шатууд бие биенээсээ тусгаарлагдсан байх ёстой.

Буцах боломж олдоно. Шуурхай хандалтад хадгалсан програмын хуучин хуулбаруудыг (аль хэдийн угсарсан, тулалдаанд бэлэн) гаргаж, алдаа гарсан тохиолдолд хуучин хувилбараа сэргээх боломжтой. Өөрөөр хэлбэл, нөхцөлт хавтас байдаг хувилбарууд болон хавтас одоогийн, мөн хавтсыг амжилттай байрлуулж, угсарсны дараа одоогийн дотор байгаа шинэ хувилбартай бэлгэдлийн холбоосоор холбогдсон хувилбарууд хувилбарын дугаарын уламжлалт нэрээр.

Энд бид Blue-Green deployment-ийг санаж байгаа бөгөөд энэ нь танд зөвхөн код хооронд шилжих төдийгүй бүх нөөц, тэр ч байтугай бүх зүйлийг буцаах чадвартай орчин хооронд шилжих боломжийг олгодог.

6. Процессууд

Програмын төлөвийн өгөгдлийг програмын дотор шууд хадгалах. Програмын RAM-д сешнүүдийг ашиглана уу. Гуравдагч талын үйлчилгээнүүдийн хооронд аль болох их хуваалцахыг ашигла. Аппликешн нь зөвхөн нэг процесстой байж болох ба масштабыг нэмэгдүүлэхийг зөвшөөрөхгүй гэдэгт найдаж байна.

Сеансуудын тухайд, өгөгдлийг зөвхөн гуравдагч талын үйлчилгээнүүдийн (memcached, redis) хянадаг кэшэд хадгалаарай, тиймээс танд 20 програмын процесс ажиллаж байгаа ч тэдгээрийн аль нэг нь кэш рүү нэвтэрсэн тохиолдолд клиенттэй үргэлжлүүлэн ажиллах боломжтой болно. Хэрэглэгч өөр процесст програмтай ажиллаж байсан ижил төлөв. Энэ аргын тусламжтайгаар та гуравдагч талын үйлчилгээг хичнээн хувь ашиглаж байгаагаас үл хамааран бүх зүйл хэвийн, өгөгдөлд хандахад асуудалгүй ажиллах болно.

7. Порт холбох

Зөвхөн вэб сервер гуравдагч талын үйлчилгээтэй хэрхэн ажиллахаа мэддэг байх ёстой. Эсвэл гуравдагч талын үйлчилгээг вэб сервер дотор шууд суулгаарай. Жишээлбэл, Apache дахь PHP модулийн хувьд.
Таны бүх үйлчилгээ зарим хаяг, порт руу нэвтрэх замаар бие биедээ хандах боломжтой байх ёстой (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), өөрөөр хэлбэл nginx-ээс би php-fpm болон postgres, мөн php-fpm-ээс postgres, nginx хүртэл, үнэндээ үйлчилгээ бүрээс би өөр үйлчилгээнд хандах боломжтой. Ингэснээр үйлчилгээний оршин тогтнох чадвар нь өөр үйлчилгээний амьдрах чадвартай холбоотой биш юм.

8. Зэрэгцээ байдал

Нэг процесстой ажилла, эс тэгвээс хэд хэдэн процесс бие биетэйгээ нийцэхгүй байх болно!

Томруулах зай үлдээгээрэй. Docker swarm нь үүнд тохиромжтой.
Docker Swarm нь өөр өөр машинууд болон нэг машин дээрх олон тооны контейнеруудын хооронд кластер үүсгэх, удирдах хэрэгсэл юм.

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

9. Нэг удаагийн хэрэглээ

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

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

10. Хэрэглээний хөгжүүлэлт/үйл ажиллагааны паритет

Програмын үйлдвэрлэл, үе шат, орон нутгийн хувилбар нь өөр байх ёстой. Үйлдвэрлэлд бид Yii Lite хүрээг ашигладаг ба дотооддоо Yii, ингэснээр үйлдвэрлэлд илүү хурдан ажилладаг!

Бодит байдал дээр бүх байршуулалт, кодтой ажиллах нь бараг ижил орчинд байх ёстой (бид физик техник хангамжийн тухай яриагүй). Түүнчлэн, аливаа хөгжүүлэлтийн ажилтан шаардлагатай бол кодыг үйлдвэрлэлд нэвтрүүлэх боломжтой байх ёстой бөгөөд тусгайлан бэлтгэгдсэн devops хэлтэс биш, зөвхөн тусгай хүч чадлын ачаар програмыг үйлдвэрлэлд өргөжүүлэх боломжтой байх ёстой.

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

11. Бүртгэл

Бид файлууд болон мэдээллийн санд бүртгэл бичдэг! Бид бүртгэлээс файл, мэдээллийн санг цэвэрлэдэггүй. Зүгээр л 9000 Пета байт хатуу диск худалдаж авцгаая, энэ нь зүгээр юм.

Бүх бүртгэлийг үйл явдлын урсгал гэж үзэх хэрэгтэй. Програм нь өөрөө бүртгэлийг боловсруулахад оролцох ёсгүй. Логуудыг stdout руу гаргах эсвэл udp гэх мэт протоколоор илгээх ёстой бөгөөд ингэснээр бүртгэлтэй ажиллах нь програмд ​​ямар нэгэн асуудал үүсгэхгүй. graylog нь үүнд тохиромжтой. Graylog нь udp-ээр дамжуулан бүх бүртгэлийг хүлээн авдаг (энэ протокол нь пакетийг амжилттай хүлээн авсан тухай хариу хүлээх шаардлагагүй) програмд ​​ямар ч байдлаар саад учруулахгүй бөгөөд зөвхөн логуудыг бүтэц, боловсруулалтад оролцуулдаг. Ийм хандлагатай ажиллахын тулд хэрэглээний логик өөрчлөгддөггүй.

12. Захиргааны үүрэг даалгавар

Өгөгдөл, өгөгдлийн сан гэх мэтийг шинэчлэхийн тулд API-д тусад нь үүсгэсэн төгсгөлийн цэгийг ашиглан 2 удаа дараалан ажиллуулснаар бүх зүйл давхардах болно. Гэхдээ та тэнэг биш, хоёр удаа товшихгүй, бидэнд шилжих шаардлагагүй.

Удирдлагын бүх ажлыг бүх кодтой ижил орчинд, хувилбарын түвшинд гүйцэтгэх ёстой. Өөрөөр хэлбэл, хэрэв бид мэдээллийн сангийн бүтцийг өөрчлөх шаардлагатай бол баганын нэрийг өөрчлөх, өгөгдлийн сангийн удирдлагын зарим хэрэгслээр шинээр нэмэх замаар гараар хийхгүй. Ийм зүйлсийн хувьд бид тусдаа скриптүүдийг бий болгодог - шилжилт хөдөлгөөнүүд нь хаа сайгүй, бүх орчинд ижил аргаар нийтлэг бөгөөд ойлгомжтой үр дүнд хүрдэг. Төслийг мэдээллээр дүүргэх гэх мэт бусад бүх ажилд ижил төстэй аргачлалыг ашиглах ёстой.

PHP, Laravel, Laradock, Docker-Compose-д хэрэгжүүлэх жишээ

Жич Бүх жишээг MacOS дээр хийсэн. Тэдгээрийн ихэнх нь Линуксд тохиромжтой. Windows хэрэглэгчид, намайг уучлаарай, гэхдээ би Windows-тэй удаан хугацаанд ажиллаагүй.

Манай компьютер дээр PHP-ийн ямар ч хувилбар суулгаагүй, юу ч байхгүй нөхцөл байдлыг төсөөлөөд үз дээ.
Docker болон docker-compose програмын хамгийн сүүлийн хувилбаруудыг суулгана уу. (үүнийг интернетээс олж болно)

docker -v && 
docker-compose -v

1. тавих Ларадок

git clone https://github.com/Laradock/laradock.git && 
ls

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

2. Манай програмыг ажиллуулахын тулд Laradock-г тохируулна уу.

cd laradock && 
cp env-example .env

2.1. Зарим засварлагч дээр habr лавлахыг (laradock-ыг хувилсан эх хавтас) нээнэ үү. (Миний PHPStorm тохиолдолд)

Энэ үе шатанд бид зөвхөн төсөлд нэр өгдөг.

2.2. Ажлын талбарын зургийг ажиллуул. (Таны хувьд зураг бүтээхэд хэсэг хугацаа шаардагдана)
Ажлын талбар нь хөгжүүлэгчийн нэрийн өмнөөс хүрээтэй ажиллахад зориулж тусгайлан бэлтгэсэн зураг юм.

Бид савыг ашиглан сав руу ордог

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. Laravel суулгаж байна

composer create-project --prefer-dist laravel/laravel application

2.4. Суулгасны дараа бид төсөл бүхий лавлах үүсгэсэн эсэхийг шалгаж, бичихийг устгана.

ls
exit
docker-compose down

2.5. PHPStorm руу буцаж очоод .env файл доторх laravel програмын зөв замыг тохируулцгаая.

3. Бүх кодыг Git-д нэмнэ.

Үүнийг хийхийн тулд бид Github (эсвэл өөр газар) дээр хадгалах газар үүсгэх болно. Терминал дахь habr лавлах руу ороод дараах кодыг ажиллуулъя.

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

Бүх зүйл эмх цэгцтэй байгаа эсэхийг шалгацгаая.

Тохиромжтой болгохын тулд би Git-ийн зарим визуал интерфейсийг ашиглахыг зөвлөж байна, миний хувьд энэ нь тийм юм GitKraken. (энд лавлах холбоос байна)

4. Эхлүүлцгээе!

Эхлэхээсээ өмнө 80 ба 443 портууд дээр юу ч өлгөөгүй эсэхийг шалгаарай.

docker-compose up -d nginx php-fpm

Тиймээс манай төсөл 3 тусдаа үйлчилгээнээс бүрдэнэ.

• nginx - вэб сервер
• php-fpm - вэб серверээс хүсэлт хүлээн авах php
• ажлын талбар - хөгжүүлэгчдэд зориулсан php

Одоогийн байдлаар бид 4 онооноос 12 оноог хангасан программыг бий болголоо.

1. Кодын сан — бүх код нэг агуулахад байна (жижиг тэмдэглэл: laravel төсөл дотор докер нэмэх нь зөв байж болох ч энэ нь чухал биш).

2. Хараат байдал - Бидний бүх хамаарал нь application/composer.json болон контейнер бүрийн Dockerfile дээр тодорхой бичигдсэн байдаг.

3. Туслах үйлчилгээ — Үйлчилгээ бүр (php-fom, nigx, ажлын талбар) өөрийн гэсэн амьдралаар амьдардаг бөгөөд гаднаас холбогдсон бөгөөд нэг үйлчилгээтэй ажиллахад нөгөө үйлчилгээ нь нөлөөлөхгүй.

4. Үйл явц - үйлчилгээ бүр нэг процесс юм. Үйлчилгээ бүр дотоод байдлыг хадгалахгүй.

5. Порт холбох

docker ps

Бидний харж байгаагаар үйлчилгээ бүр өөрийн порт дээр ажилладаг бөгөөд бусад бүх үйлчилгээнд хандах боломжтой.

6. Зэрэгцээ байдал

Докер нь нэг үйлчилгээний олон процессыг хооронд нь автоматаар ачааллыг тэнцвэржүүлэх боломжийг олгодог.

Контейнерүүдийг зогсоож, тугны дундуур явуулцгаая - масштаб

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

Бидний харж байгаагаар php-fpm контейнерийн хуулбарыг үүсгэсэн. Бид энэ савтай ажиллахдаа юу ч өөрчлөх шаардлагагүй. Бид мөн 9000 порт дээр үргэлжлүүлэн ханддаг бөгөөд Docker бидний хувьд чингэлэг хоорондын ачааллыг зохицуулдаг.

7. Нэг удаагийн хэрэглээ - сав бүрийг нөгөөдөө хор хөнөөл учруулахгүйгээр алж болно. Савыг зогсоох эсвэл дахин эхлүүлэх нь дараагийн эхлүүлэх үед програмын үйл ажиллагаанд нөлөөлөхгүй. Мөн сав бүрийг хүссэн үедээ өргөж болно.

8. Хэрэглээний хөгжүүлэлт/үйл ажиллагааны паритет - Бидний бүх орчин ижил. Системийг үйлдвэрлэлийн сервер дээр ажиллуулснаар та тушаалууддаа юу ч өөрчлөх шаардлагагүй болно. Бүх зүйл Docker дээр суурилсан байх болно.

9. Мод бэлтгэх — эдгээр савнуудын бүх бүртгэлүүд урсгал руу орох ба Docker консол дээр харагдана. (энэ тохиолдолд, үнэндээ, бусад гар хийцийн савны хувьд, хэрэв та үүнийг анхаарч үзэхгүй бол тийм биш байж магадгүй юм)

 docker-compose logs -f

Гэхдээ PHP болон Nginx-ийн өгөгдмөл утгууд нь файлд лог бичдэгтэй холбоотой нэг зүйл бий. 12 хүчин зүйлийг хангахын тулд зайлшгүй шаардлагатай салгах Контейнер бүрийн тохиргоонд тус тусад нь файл руу бүртгэл бичих.

Docker нь зөвхөн stdout руу төдийгүй дээр дурдсан graylog гэх мэт зүйлс рүү лог илгээх боломжийг олгодог. Graylog дотор бид логуудыг хүссэнээрээ ажиллуулж болох бөгөөд манай програм үүнийг ямар ч байдлаар анзаарахгүй.

10. Захиргааны даалгавар - 12 хүчин зүйлийн програмыг бүтээгчдийн хүссэнээр гар урлалын хэрэгслийн ачаар удирдлагын бүх ажлыг laravel шийддэг.

Жишээ болгон би зарим тушаалуудыг хэрхэн гүйцэтгэдэгийг харуулах болно.
Бид саванд ордог.

 
docker-compose exec workspace bash
php artisan list

Одоо бид ямар ч тушаалыг ашиглаж болно. (Бид мэдээллийн сан болон кэшийг тохируулаагүй тул командуудын тал хувь нь зөв ажиллахгүй, учир нь тэдгээр нь кэш болон мэдээллийн сантай ажиллахад зориулагдсан гэдгийг анхаарна уу).

11. Тохиргоо 12. Барилга, суллах, ажиллуулах

Би энэ хэсгийг Цэнхэр-Ногоон байршуулалтад зориулахыг хүссэн боловч энэ нийтлэлд хэтэрхий өргөн хүрээтэй санагдсан. Би энэ талаар тусдаа нийтлэл бичих болно.

Товчхондоо энэ үзэл баримтлал нь CI/CD системүүд дээр суурилдаг Jenkins и Gitlab CI. Аль алинд нь та тодорхой орчинтой холбоотой орчны хувьсагчдыг тохируулж болно. Үүний дагуу энэ нөхцөлд c цэг биелэгдэнэ Тохиргоо.

Тэгээд гол зүйл Барилга, суллах, ажиллуулах нэртэй суурилагдсан функцуудаар шийдэгддэг Дамжуулах хоолой.

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

Хэрэглээний код дараах хаягаар байна Github.
Энэ агуулахыг клончлохдоо дэд модулийг эхлүүлэхээ бүү мартаарай.

Жич: Эдгээр бүх аргыг өөр ямар ч хэрэгсэл, програмчлалын хэлээр ашиглаж болно. Хамгийн гол нь мөн чанар нь ялгаатай биш юм.

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