Birincisi, bir az nəzəriyyə. Nə baş verdi ?
Sadə sözlə, bu sənəd tərtibatçılara və DevOps mühəndislərinə müasir proqramların hazırlanmasında ən çox rast gəlinən problemlər və təcrübələr haqqında məlumat verməklə, SaaS proqramlarının işlənib hazırlanmasını sadələşdirmək üçün nəzərdə tutulmuşdur.
Sənəd Heroku platformasının tərtibatçıları tərəfindən hazırlanıb.
On iki faktorlu Tətbiq istənilən proqramlaşdırma dilində yazılmış və dəstək xidmətlərinin (verilənlər bazası, mesaj növbələri, keşlər və s.) istənilən kombinasiyasından istifadə edən proqramlara tətbiq oluna bilər.
Bu metodologiyanın əsaslandığı amillər haqqında qısaca:
- Kod bazası – Versiya nəzarətində izlənilən bir kod bazası – çoxlu yerləşdirmə
- Asılılıqlar – Asılılıqları açıq şəkildə elan edin və təcrid edin
- Konfiqurasiya - İş vaxtında konfiqurasiyanı yadda saxla
- Dəstək Xidmətləri – Yardım xidmətlərini plug-in resursları kimi nəzərdən keçirin
- Qurmaq, buraxmaq, qaçmaq – Quraşdırma və icra mərhələlərini ciddi şəkildə ayırın
- Proseslər – Tətbiqi bir və ya daha çox vətəndaşlığı olmayan proses kimi işə salın
- Port bağlama – Port bağlama vasitəsilə ixrac xidmətləri
- Paralellik - Proseslərdən istifadə edərək tətbiqinizi miqyaslandırın
- Birdəfəlik istifadə – Sürətli işə salma və təmiz söndürmə ilə etibarlılığı maksimuma çatdırın
- Proqram inkişafı/əməliyyat pariteti – İnkişaf, səhnələşdirmə və istehsal mühitinizi mümkün qədər oxşar saxlayın
- Giriş – Qeydə hadisələr axını kimi baxın
- İdarəetmə vəzifələri – Ad hoc proseslərdən istifadə edərək idarəetmə/idarəetmə tapşırıqlarını yerinə yetirin
Aşağıdakı mənbələrdən 12 amil haqqında daha çox məlumat əldə edə bilərsiniz:
- - mütləq oxumaq lazımdır
- - rəsmi tərcümə
- - 12 amili təkmilləşdirmək məqsədi ilə yeni baxış.
Mavi-Yaşıl yerləşdirmə nədir?
Mavi-Yaşıl yerləşdirmə tətbiqin çatdırılma üsuludur istehsal elə bir şəkildə ki, son müştəri öz tərəfində heç bir dəyişiklik görməsin. Başqa sözlə, sıfır olan bir tətbiqin yerləşdirilməsi aşağı vaxt.
Klassik BG Deploy sxemi aşağıdakı şəkildə göstərildiyi kimi görünür.
- Başlanğıcda tamamilə eyni kod, proqram, layihə ilə 2 fiziki server var və marşrutlaşdırıcı (balansator) var.
- Router əvvəlcə bütün sorğuları serverlərdən birinə yönəldir (yaşıl).
- Yenidən buraxmaq lazım olan anda, bütün layihə başqa bir serverdə yenilənir (mavi), hazırda heç bir sorğunu emal etmir.
- Kod işə salındıqdan sonra mavi server tamamilə yenilənir, marşrutlaşdırıcıya keçid əmri verilir yaşıl haqqında mavi server.
- İndi bütün müştərilər kodun nəticəsini görür mavi server.
- Bir müddət yaşıl server uğursuz yerləşdirmə vəziyyətində ehtiyat nüsxə kimi xidmət edir mavi server və nasazlıq və səhvlər halında, marşrutlaşdırıcı istifadəçi axınını geri qaytarır yaşıl server köhnə stabil versiyaya malikdir və yeni kod təftiş və sınaq üçün göndərilir.
- Və prosesin sonunda eyni şəkildə yenilənir yaşıl server. Və onu yenilədikdən sonra marşrutlaşdırıcı sorğu axınını geri qaytarır yaşıl server.
Hər şey çox yaxşı görünür və ilk baxışdan onunla heç bir problem olmamalıdır.
Ancaq müasir dünyada yaşadığımız üçün klassik sxemdə göstərildiyi kimi fiziki keçid ilə seçim bizə uyğun deyil. Məlumatı indilik qeyd edin, daha sonra ona qayıdacağıq.
Pis və yaxşı məsləhət
Məsuliyyətdən imtina: Aşağıdakı nümunələr mənim istifadə etdiyim kommunal proqramları/metodologiyaları göstərir, siz oxşar funksiyaları olan hər hansı alternativlərdən istifadə edə bilərsiniz.
Nümunələrin əksəriyyəti bu və ya digər şəkildə veb inkişafı ilə (bu sürprizdir), PHP və Docker ilə kəsişir.
Aşağıdakı paraqraflar konkret nümunələrdən istifadə etməklə faktorların istifadəsinin sadə praktik təsvirini təqdim edir; bu mövzuda daha çox nəzəriyyə əldə etmək istəyirsinizsə, orijinal mənbəyə yuxarıdakı keçidləri izləyin.
1. Kod bazası
Faylları bir-bir serverlərə yükləmək üçün FTP və FileZilla istifadə edin, kodu istehsal serverindən başqa heç bir yerdə saxlamayın.
Layihədə həmişə tək kod bazası olmalıdır, yəni bütün kodlar birdən gəlir get anbar. Serverlər (istehsal, quruluş, test1, test2...) bir ümumi deponun filiallarından kod istifadə edir. Bu yolla biz kod ardıcıllığına nail oluruq.
2. Asılılıqlar
Qovluqlardakı bütün kitabxanaları birbaşa layihənin kökünə endirin. Sadəcə yeni kodu kitabxananın cari versiyası olan qovluğa köçürməklə yeniləmələr edin. Bütün lazımi yardım proqramlarını birbaşa daha 20 xidmətin işlədiyi host serverinə quraşdırın.
Layihədə həmişə aydın başa düşülən asılılıqlar siyahısı olmalıdır (asılılıqlar dedikdə mən həm də ətraf mühiti nəzərdə tuturam). Bütün asılılıqlar açıq şəkildə müəyyən edilməli və təcrid olunmalıdır.
Nümunə kimi götürək bəstələmək и yükvuran.
bəstələmək — PHP-də kitabxana qurmağa imkan verən paket meneceri. Composer sizə versiyaları ciddi və ya sərbəst şəkildə müəyyən etməyə və onları açıq şəkildə müəyyən etməyə imkan verir. Serverdə 20 müxtəlif layihə ola bilər və hər birində digərindən asılı olmayaraq paketlərin və kitabxanaların şəxsi siyahısı olacaq.
yükvuran — proqramın işləyəcəyi mühiti müəyyən etməyə və təcrid etməyə imkan verən yardım proqramı. Müvafiq olaraq, bəstəkarda olduğu kimi, lakin daha ətraflı şəkildə tətbiqin nə ilə işlədiyini müəyyən edə bilərik. PHP-nin xüsusi versiyasını seçin, əlavə heç nə əlavə etmədən yalnız layihənin işləməsi üçün lazım olan paketləri quraşdırın. Və ən əsası, ana maşının və digər layihələrin paketlərinə və mühitinə müdaxilə etmədən. Yəni, Docker vasitəsilə işləyən serverdəki bütün layihələr tamamilə hər hansı bir paket dəstindən və tamamilə fərqli mühitdən istifadə edə bilər.
3. Konfiqurasiya
Konfiqurasiyaları birbaşa kodda sabitlər kimi saxlayın. Test serveri üçün ayrıca sabitlər, istehsal üçün ayrı. Tətbiqin işini mühitdən asılı olaraq birbaşa if else konstruksiyalarından istifadə edərək layihənin biznes məntiqinə bağlayın.
Konfiqurasiyalar - bu, layihə yerləşdirmələrinin fərqli olmasının yeganə yoludur. İdeal olaraq, konfiqurasiyalar mühit dəyişənlərindən (env vars) keçməlidir.
Yəni bir neçə konfiqurasiya faylı .config.prod .config.local saxlasanız və yerləşdirmə zamanı onların adını .config (tətbiqin məlumatları oxuduğu əsas konfiqurasiya) olaraq dəyişdirsəniz belə - bu düzgün yanaşma olmayacaq, çünki bu halda, konfiqurasiyalardakı məlumatlar bütün proqram tərtibatçıları üçün açıq olacaq və istehsal serverindən gələn məlumatlar təhlükə altına düşəcək. Bütün konfiqurasiyalar birbaşa yerləşdirmə sistemində (CI/CD) saxlanmalı və yerləşdirmə zamanı xüsusi mühit üçün lazım olan müxtəlif dəyərlərə malik müxtəlif mühitlər üçün yaradılmalıdır.
4. Üçüncü Şəxs Xidmətləri
Ətraf mühitə ciddi şəkildə bağlı olun, müəyyən mühitlərdə eyni xidmətlər üçün müxtəlif əlaqələrdən istifadə edin.
Əslində, bu nöqtə konfiqurasiyalarla bağlı nöqtə ilə güclü şəkildə üst-üstə düşür, çünki bu nöqtə olmadan normal konfiqurasiya məlumatları hazırlana bilməz və ümumiyyətlə konfiqurasiya qabiliyyəti heç bir şeyə düşəcəkdir.
Növbə serverləri, verilənlər bazası, keşləmə xidmətləri kimi xarici xidmətlərə bütün bağlantılar həm yerli mühit, həm də üçüncü tərəf/istehsal mühiti üçün eyni olmalıdır. Başqa sözlə, istənilən vaxt əlaqə sətirini dəyişdirərək, mən proqram kodunu dəyişmədən №1 bazaya edilən zəngləri №2 baza ilə əvəz edə bilərəm. Və ya, nümunə olaraq, xidmətin ölçüsünü artırarkən, əlavə bir önbellek serveri üçün əlaqəni xüsusi bir şəkildə təyin etməli olmayacaqsınız.
5. Qurmaq, buraxmaq, icra etmək
Serverdə kodun yalnız son versiyası var, buraxılışı geri qaytarmaq şansı yoxdur. Disk yerini doldurmağa ehtiyac yoxdur. Səhvlə kodu istehsala buraxa biləcəyini düşünən hər kəs pis proqramçıdır!
Yerləşdirmənin bütün mərhələləri bir-birindən ayrılmalıdır.
Geri dönmək şansınız var. Sürətli girişdə saxlanan tətbiqin köhnə nüsxələri (artıq yığılmış və döyüşə hazır) ilə buraxılışlar hazırlayın ki, səhvlər olarsa köhnə versiyanı bərpa edə biləsiniz. Yəni şərti olaraq bir qovluq var relizlər və qovluq cari, və qovluğu müvəffəqiyyətlə yerləşdirmə və montaj etdikdən sonra cari içərisində olan yeni buraxılışla simvolik bir əlaqə ilə əlaqələndirilir relizlər buraxılış nömrəsinin şərti adı ilə.
Bu, Mavi-Yaşıl yerləşdirməni xatırladığımız yerdir ki, bu da sizə təkcə kodlar arasında keçid etməyə deyil, həm də hər şeyi geri qaytarmaq imkanı ilə bütün resurslar və hətta mühitlər arasında keçid etməyə imkan verir.
6. Proseslər
Tətbiq vəziyyəti məlumatlarını birbaşa tətbiqin özündə saxlayın. Proqramın özünün RAM-da seanslardan istifadə edin. Üçüncü tərəf xidmətləri arasında mümkün qədər çox paylaşımdan istifadə edin. Tətbiqin yalnız bir prosesi ola biləcəyinə və miqyasına icazə verilməməsinə etibar edin.
Sessiyalara gəldikdə, məlumatları yalnız üçüncü tərəf xidmətləri (memcached, redis) tərəfindən idarə olunan bir keşdə saxlayın, beləliklə, işləyən 20 tətbiq prosesiniz olsa belə, onlardan hər hansı biri keşə daxil olaraq müştəri ilə işləməyə davam edə biləcək. istifadəçinin başqa bir prosesdə proqramla işlədiyi eyni vəziyyət. Bu yanaşma ilə məlum olur ki, üçüncü tərəf xidmətlərinin nə qədər nüsxəsindən istifadə etməyinizdən asılı olmayaraq, hər şey normal və məlumatlara giriş problemi olmadan işləyəcək.
7. Port bağlama
Yalnız veb server üçüncü tərəf xidmətləri ilə işləməyi bilməlidir. Və ya daha yaxşısı, üçüncü tərəf xidmətlərini birbaşa veb server daxilində quraşdırın. Məsələn, Apache-də PHP modulu kimi.
Bütün xidmətləriniz hansısa ünvana və porta (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) çıxış vasitəsilə bir-biriniz üçün əlçatan olmalıdır, yəni nginx-dən mən həm php-fpm, həm də postgres və php-fpm-dən postgres və nginx-ə qədər və əslində hər bir xidmətdən başqa bir xidmətə daxil ola bilirəm. Beləliklə, bir xidmətin həyat qabiliyyəti digər xidmətin canlılığı ilə əlaqələndirilmir.
8. Paralellik
Bir proseslə işləyin, əks halda bir neçə proses bir-biri ilə uzlaşa bilməyəcək!
Ölçmək üçün yer buraxın. Docker swarm bunun üçün əladır.
Docker Swarm həm müxtəlif maşınlar, həm də eyni maşındakı bir dəstə konteyner arasında konteyner qruplarını yaratmaq və idarə etmək üçün bir vasitədir.
Swarm-dan istifadə edərək, hər bir prosesə nə qədər resurs ayıracağımı və eyni xidmətin neçə prosesini işə salacağımı müəyyən edə bilərəm və daxili balanslaşdırıcı, müəyyən bir portda məlumatları qəbul edərək, avtomatik olaraq proseslərə proksi edəcək. Beləliklə, serverdə yükün artdığını görüb daha çox proses əlavə edə bilirəm və bununla da müəyyən proseslərin yükünü azalda bilirəm.
9. Birdəfəlik istifadə
Proseslər və verilənlərlə işləmək üçün növbələrdən istifadə etməyin. Bir prosesin öldürülməsi bütün tətbiqə təsir etməlidir. Bir xidmət sönürsə, hər şey azalır.
Hər bir proses və xidmət istənilən vaxt söndürülə bilər və bu, digər xidmətlərə təsir etməməlidir (əlbəttə, bu o demək deyil ki, xidmət başqa xidmət üçün əlçatan olmayacaq, lakin bundan sonra başqa xidmət sönməyəcək). Bütün proseslər zərif şəkildə dayandırılmalıdır ki, onlar dayandırıldıqda heç bir məlumat zədələnməsin və növbəti dəfə onu yandırdığınız zaman sistem düzgün işləsin. Yəni, fövqəladə xitam zamanı belə məlumatlar zədələnməməlidir (burada tranzaksiya mexanizmi uyğundur, verilənlər bazasındakı sorğular yalnız qruplar şəklində işləyir və qrupdan ən azı bir sorğu uğursuz olarsa və ya bir sorğu ilə yerinə yetirilirsə). səhv olarsa, qrupdan başqa heç bir sorğu nəticədə uğursuz olmur).
10. Proqram inkişafı/əməliyyat pariteti
Tətbiqin istehsalı, quruluşu və yerli versiyası fərqli olmalıdır. İstehsalda biz Yii Lite çərçivəsini və yerli olaraq Yii-dən istifadə edirik ki, istehsalda daha sürətli işləyir!
Əslində, bütün yerləşdirmələr və kodla iş demək olar ki, eyni mühitdə olmalıdır (biz fiziki avadanlıqdan danışmırıq). Həmçinin, hər hansı bir inkişaf işçisi, yalnız xüsusi güc sayəsində tətbiqi istehsala qaldıra bilən bəzi xüsusi təlim keçmiş devops şöbəsi deyil, lazım olduqda kodu istehsala yerləşdirə bilməlidir.
Docker də bu işdə bizə kömək edir. Bütün əvvəlki nöqtələrə əməl edilərsə, docker-dən istifadə həm istehsalda, həm də yerli maşında mühitin yerləşdirilməsi prosesini bir və ya iki əmr daxil etməyə gətirəcəkdir.
11. Qeydlər
Fayllara və verilənlər bazasına loglar yazırıq! Biz faylları və verilənlər bazalarını loglardan təmizləmirik. Gəlin sadəcə 9000 Peta baytı olan sərt disk alaq və bu yaxşıdır.
Bütün qeydlər hadisələrin axını kimi qəbul edilməlidir. Tətbiqin özü logların işlənməsinə cəlb edilməməlidir. Jurnallar ya stdout-a çıxarılmalı, ya da udp kimi protokol vasitəsilə göndərilməlidir ki, qeydlərlə işləmək proqram üçün heç bir problem yaratmasın. graylog bunun üçün yaxşıdır. Bütün qeydləri udp vasitəsilə qəbul edən Graylog (bu protokol paketin uğurlu qəbulu haqqında cavab gözləməyi tələb etmir) tətbiqə heç bir şəkildə müdaxilə etmir və yalnız logların strukturlaşdırılması və işlənməsi ilə məşğul olur. Tətbiq məntiqi bu cür yanaşmalarla işləmək üçün dəyişmir.
12. İdarəetmə vəzifələri
Məlumatları, verilənlər bazalarını və s. yeniləmək üçün API-də ayrıca yaradılmış son nöqtədən istifadə edin, onu ardıcıl olaraq 2 dəfə yerinə yetirmək hər şeyin təkrarlanması ilə nəticələnəcək. Amma sən axmaq deyilsən, iki dəfə klikləməyəcəksən və miqrasiyaya ehtiyacımız yoxdur.
Bütün idarəetmə tapşırıqları bütün kodlarla eyni mühitdə, buraxılış səviyyəsində yerinə yetirilməlidir. Yəni, əgər verilənlər bazasının strukturunu dəyişmək lazımdırsa, o zaman bəzi vizual verilənlər bazası idarəetmə vasitələri vasitəsilə sütunların adlarını dəyişdirərək və yenilərini əlavə etməklə bunu əl ilə etməyəcəyik. Belə şeylər üçün biz ayrı-ayrı skriptlər - miqrasiya yaradırıq ki, onlar hər yerdə və bütün mühitlərdə eyni şəkildə ümumi və başa düşülən nəticə ilə icra olunur. Layihənin məlumatlarla doldurulması kimi bütün digər vəzifələr üçün oxşar metodologiyalardan istifadə edilməlidir.
PHP, Laravel, Laradock, Docker-Compose proqramlarında tətbiq nümunəsi
P.S Bütün nümunələr MacOS-da hazırlanmışdır. Onların əksəriyyəti Linux üçün də uyğundur. Windows istifadəçiləri, məni bağışlayın, lakin mən uzun müddətdir ki, Windows ilə işləmirəm.
Gəlin elə bir vəziyyəti təsəvvür edək ki, bizim kompüterimizdə PHP-nin heç bir versiyası quraşdırılmayıb və ümumiyyətlə heç nə yoxdur.
Docker və docker-compose proqramlarının ən son versiyalarını quraşdırın. (bunu internetdə tapmaq olar)
docker -v &&
docker-compose -v
1. Qoyun
git clone https://github.com/Laradock/laradock.git &&
ls
Laradokla bağlı deyim ki, bu, çox gözəl bir şeydir, tərkibində çoxlu qablar və köməkçi əşyalar var. Lakin mən Laradock-un ehtiyatsızlığına görə istehsalda dəyişiklik etmədən istifadə etməyi məsləhət görməzdim. Laradock-dakı nümunələr əsasında öz konteynerlərinizi yaratmaq daha yaxşıdır, bu, daha optimallaşdırılacaq, çünki heç kimə eyni anda orada olan hər şey lazım deyil.
2. Tətbiqimizi işə salmaq üçün Laradock-u konfiqurasiya edin.
cd laradock &&
cp env-example .env
2.1. Bəzi redaktorda habr qovluğunu (laradokun klonlandığı ana qovluq) açın. (PHPStorm işimdə)
Bu mərhələdə biz layihəyə yalnız ad veririk.
2.2. İş sahəsinin şəklini işə salın. (Sizin vəziyyətinizdə, şəkillərin qurulması bir az vaxt aparacaq)
İş sahəsi, tərtibatçının adından çərçivə ilə işləmək üçün xüsusi hazırlanmış bir şəkildir.
İstifadə edərək konteynerin içərisinə giririk
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Laravel quraşdırılması
composer create-project --prefer-dist laravel/laravel application
2.4. Quraşdırıldıqdan sonra layihə ilə qovluğun yaradılıb-yaradılmadığını yoxlayırıq və kompozisiyanı öldürürük.
ls
exit
docker-compose down
2.5. PHPStorm-a qayıdaq və .env faylında laravel tətbiqimizə doğru yolu təyin edək.
3. Bütün kodu Git-ə əlavə edin.
Bunun üçün biz Github-da (və ya başqa yerdə) repozitoriya yaradacağıq. Terminaldakı habr kataloquna keçək və aşağıdakı kodu icra edək.
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
Hər şeyin qaydasında olub olmadığını yoxlayaq.
Rahatlıq üçün Git üçün bəzi vizual interfeysdən istifadə etməyi məsləhət görürəm, mənim vəziyyətimdə belədir . (burada istinad linki var)
4. Gəlin başlayaq!
Başlamazdan əvvəl 80 və 443 portlarında heç bir şeyin asılmadığından əmin olun.
docker-compose up -d nginx php-fpm
Beləliklə, layihəmiz 3 ayrı xidmətdən ibarətdir:
- nginx - veb server
- php-fpm - veb serverdən sorğuların qəbulu üçün php
- iş sahəsi - tərtibatçılar üçün php
Hal-hazırda, 4 baldan 12-nə cavab verən bir tətbiq yaratmağımıza nail olduq, yəni:
1. Kod bazası — bütün kodlar bir depodadır (kiçik qeyd: laravel layihəsinin içərisinə docker əlavə etmək düzgün ola bilər, lakin bu vacib deyil).
2. Asılılıqlar - Bütün asılılıqlarımız açıq şəkildə application/composer.json-da və hər konteynerin hər bir Dockerfile-də yazılmışdır.
3. Dəstək Xidmətləri — Xidmətlərin hər biri (php-fom, nigx, iş sahəsi) öz həyatını yaşayır və kənardan bağlıdır və bir xidmətlə işləyərkən digərinə təsir etməyəcək.
4. Proseslər — hər xidmət bir prosesdir. Xidmətlərin hər biri daxili vəziyyəti saxlamır.
5. Port bağlama
docker ps
Gördüyümüz kimi, hər bir xidmət öz portunda işləyir və bütün digər xidmətlər üçün əlçatandır.
6. Paralellik
Docker bizə eyni xidmətlərin birdən çox prosesini, onlar arasında avtomatik yük balansını yaratmağa imkan verir.
Gəlin konteynerləri dayandıraq və bayraqdan keçirək --miqyaslı
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Gördüyümüz kimi, php-fpm konteynerinin surətləri yaradılmışdır. Bu konteynerlə işləyərkən heç nəyi dəyişməyə ehtiyacımız yoxdur. Biz həmçinin 9000 portunda ona daxil olmağa davam edirik və Docker bizim üçün konteynerlər arasında yükü tənzimləyir.
7. Birdəfəlik istifadə - hər bir konteyner digərinə zərər vermədən öldürülə bilər. Konteynerin dayandırılması və ya yenidən işə salınması proqramın sonrakı işə salınması zamanı işinə təsir etməyəcək. Hər bir konteyner istənilən vaxt qaldırıla bilər.
8. Proqram inkişafı/əməliyyat pariteti - bütün mühitlərimiz eynidir. Sistemi istehsalda olan bir serverdə işlətməklə, əmrlərinizdə heç nəyi dəyişməli olmayacaqsınız. Hər şey eyni şəkildə Docker-ə əsaslanacaq.
9. Giriş — bu konteynerlərdəki bütün qeydlər axına gedir və Docker konsolunda görünür. (bu halda, əslində, digər evdə hazırlanmış qablarda, qayğı göstərməsəniz, belə olmaya bilər)
docker-compose logs -f
Ancaq PHP və Nginx-də Defolt dəyərlərin də fayla qeydlər yazması ilə bağlı bir məqam var. 12 amili qarşılamaq üçün bu lazımdır ləğv et ayrı-ayrılıqda hər bir konteynerin konfiqurasiyasında fayla logların yazılması.
Docker həmçinin qeydləri təkcə stdout-a deyil, yuxarıda qeyd etdiyim graylog kimi şeylərə də göndərmək imkanı verir. Graylog daxilində biz logları istədiyimiz kimi işlədə bilərik və tətbiqimiz bunu heç bir şəkildə hiss etməyəcək.
10. İdarəetmə vəzifələri — 12 faktorlu tətbiqin yaradıcılarının istədiyi kimi, sənətkar alət sayəsində bütün idarəetmə tapşırıqları laravel tərəfindən həll edilir.
Nümunə olaraq bəzi əmrlərin necə yerinə yetirildiyini göstərəcəyəm.
Konteynerə giririk.
docker-compose exec workspace bash
php artisan list
İndi istənilən əmrdən istifadə edə bilərik. (nəzərə alın ki, verilənlər bazası və önbelleği konfiqurasiya etməmişik, ona görə də əmrlərin yarısı düzgün yerinə yetirilməyəcək, çünki onlar keş və verilənlər bazası ilə işləmək üçün nəzərdə tutulub).
11. Konfiqurasiyalar və 12. Qurmaq, buraxmaq, qaçmaq
Mən bu hissəni Mavi-Yaşıl Yerləşdirməyə həsr etmək istədim, lakin bu məqalə üçün çox geniş olduğu ortaya çıxdı. Bu barədə ayrıca məqalə yazacam.
Bir sözlə, konsepsiya kimi CI/CD sistemlərinə əsaslanır Jenkins и Gitlab CI. Hər ikisində siz xüsusi mühitlə əlaqəli mühit dəyişənlərini təyin edə bilərsiniz. Müvafiq olaraq, bu vəziyyətdə c nöqtəsi yerinə yetiriləcəkdir Konfiqurasiyalar.
Və mövzu haqqında Qurmaq, buraxmaq, qaçmaq adı ilə daxili funksiyalar tərəfindən həll edilir Kəmər.
Kəmər montaj, buraxılış və icra mərhələlərini vurğulayaraq, yerləşdirmə prosesini bir çox mərhələlərə bölməyə imkan verir. Həmçinin, Pipeline-da siz ehtiyat nüsxələri yarada bilərsiniz və həqiqətən də hər şey. Bu, sonsuz potensiala malik bir vasitədir.
Tətbiq kodu bu ünvandadır .
Bu deponu klonlayarkən alt modulu işə salmağı unutmayın.
P.S.: Bütün bu yanaşmalar istənilən digər utilitlər və proqramlaşdırma dilləri ilə istifadə edilə bilər. Əsas odur ki, mahiyyət fərqlənmir.
Mənbə: www.habr.com