توسعه برنامه و استقرار آبی-سبز، بر اساس روش برنامه دوازده عاملی با مثال هایی در 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 سرور فیزیکی با کد، برنامه، پروژه کاملاً یکسان و یک روتر (بالانسر) وجود دارد.
• روتر ابتدا تمام درخواست ها را به یکی از سرورها هدایت می کند (سبز).
• در لحظه ای که نیاز به انتشار مجدد دارید، کل پروژه در سرور دیگری به روز می شود (синий) که در حال حاضر هیچ درخواستی را پردازش نمی کند.
• بعد از اینکه کد روشن شد آبی سرور به طور کامل به روز شده است، به روتر دستور تعویض داده می شود سبز بر синий سرور
• اکنون همه کلاینت‌ها نتیجه اجرای کد را می‌بینند آبی سرور
• برای یک مدتی، سبز سرور در صورت استقرار ناموفق به عنوان یک نسخه پشتیبان عمل می کند синий سرور و در صورت خرابی و باگ، روتر جریان کاربر را به آن سوئیچ می کند سبز سرور با نسخه پایدار قدیمی و کد جدید برای بازبینی و تست ارسال می شود.
• و در پایان پروسه به همین ترتیب آپدیت می شود سبز سرور و پس از به روز رسانی آن، روتر جریان درخواست را به آن سوئیچ می کند سبز سرور

همه چیز بسیار خوب به نظر می رسد و در نگاه اول نباید هیچ مشکلی با آن وجود داشته باشد.
اما از آنجایی که ما در دنیای مدرن زندگی می کنیم، گزینه سوئیچینگ فیزیکی همانطور که در طرح کلاسیک نشان داده شده است مناسب ما نیست. فعلاً اطلاعات را ثبت کنید، بعداً به آن باز خواهیم گشت.

نصیحت بد و خوب

سلب مسئولیت: مثال‌های زیر ابزارها/روش‌هایی را که من استفاده می‌کنم نشان می‌دهد، شما می‌توانید مطلقاً از هر جایگزینی با عملکردهای مشابه استفاده کنید.

بیشتر نمونه ها به یک شکل با توسعه وب (این یک تعجب است)، با PHP و Docker تلاقی می کنند.

پاراگراف‌های زیر با استفاده از مثال‌های خاص، توضیح عملی ساده‌ای از استفاده از عوامل ارائه می‌دهند؛ اگر می‌خواهید نظریه بیشتری در مورد این موضوع کسب کنید، پیوندهای بالا را به منبع اصلی دنبال کنید.

1. Codebase

از FTP و FileZilla برای آپلود فایل ها در سرورها یکبار استفاده کنید، کد را در جایی غیر از سرور تولید ذخیره نکنید.

پروژه همیشه باید یک پایه کد واحد داشته باشد، یعنی همه کدها از یک کد می آیند رفتن مخزن سرورها (تولید، مرحله بندی، test1، test2...) از کدهای شاخه های یک مخزن مشترک استفاده می کنند. به این ترتیب ما به سازگاری کد می رسیم.

2. وابستگی ها

تمام کتابخانه های موجود در پوشه ها را مستقیماً در ریشه پروژه دانلود کنید. به سادگی با انتقال کد جدید به پوشه ای با نسخه فعلی کتابخانه، به روز رسانی کنید. تمام ابزارهای ضروری را مستقیماً روی سرور میزبان نصب کنید که در آن 20 سرویس دیگر در حال اجرا هستند.

یک پروژه همیشه باید فهرستی از وابستگی ها به وضوح قابل درک داشته باشد (منظورم از وابستگی ها محیط زیست نیز هست). همه وابستگی ها باید به صراحت تعریف و جدا شوند.
بیایید به عنوان مثال آهنگساز и کارگر بارانداز.

آهنگساز - یک مدیر بسته که به شما امکان می دهد کتابخانه ها را در PHP نصب کنید. Composer به شما این امکان را می دهد که نسخه ها را به طور دقیق یا آزاد مشخص کنید و آنها را به صراحت تعریف کنید. می تواند 20 پروژه مختلف روی سرور وجود داشته باشد و هر کدام یک لیست شخصی از بسته ها و کتابخانه ها مستقل از دیگری داشته باشند.

کارگر بارانداز - ابزاری که به شما امکان می دهد محیطی را که برنامه در آن اجرا می شود را تعریف و جدا کنید. بر این اساس، درست مانند آهنگساز، اما به طور دقیق تر، می توانیم تعیین کنیم که برنامه با چه چیزی کار می کند. یک نسخه خاص از PHP را انتخاب کنید، فقط بسته های لازم برای کار پروژه را نصب کنید، بدون اینکه چیز اضافی اضافه کنید. و از همه مهمتر بدون تداخل با بسته ها و محیط ماشین میزبان و پروژه های دیگر. یعنی تمام پروژه های روی سرور که از طریق Docker اجرا می شوند می توانند کاملاً از هر مجموعه ای از بسته ها و یک محیط کاملاً متفاوت استفاده کنند.

3. پیکربندی

تنظیمات را به صورت ثابت مستقیماً در کد ذخیره کنید. ثابت های جداگانه برای سرور آزمایشی، جدا برای تولید. عملکرد برنامه را بسته به محیط به طور مستقیم در منطق تجاری پروژه با استفاده از ساختار if else گره بزنید.

پیکربندی - این تنها راهی است که استقرار پروژه باید متفاوت باشد. در حالت ایده آل، تنظیمات باید از طریق متغیرهای محیطی (env vars) منتقل شوند.

یعنی حتی اگر چندین فایل پیکربندی .config.prod .config.local را ذخیره کنید و در زمان استقرار آنها را به .config تغییر نام دهید (پیکربندی اصلی که برنامه داده ها را از آن می خواند) - این رویکرد درستی نخواهد بود، زیرا در این صورت اطلاعات پیکربندی ها به صورت عمومی برای همه توسعه دهندگان برنامه در دسترس خواهد بود و داده های سرور تولید به خطر می افتد. تمام تنظیمات باید مستقیماً در سیستم استقرار (CI/CD) ذخیره شوند و برای محیط‌های مختلف با مقادیر مختلف لازم برای یک محیط خاص در زمان استقرار تولید شوند.

4. خدمات شخص ثالث

به شدت به محیط وابسته باشید، از اتصالات مختلف برای خدمات یکسان در محیط های خاص استفاده کنید.

در واقع، این نقطه به شدت با نکته مربوط به تنظیمات همپوشانی دارد، زیرا بدون این نقطه، داده های پیکربندی معمولی نمی توانند ایجاد شوند و به طور کلی، توانایی پیکربندی به هیچ وجه کاهش می یابد.

همه اتصالات به سرویس‌های خارجی، مانند سرورهای صف، پایگاه‌های داده، سرویس‌های ذخیره‌سازی باید هم برای محیط محلی و هم برای محیط تولید شخص ثالث یکسان باشند. به عبارت دیگر، در هر زمان، با تغییر رشته اتصال، می توانم بدون تغییر کد برنامه، تماس های پایگاه شماره 1 را با پایه شماره 2 جایگزین کنم. یا، به عنوان مثال، با نگاه کردن به آینده، هنگام مقیاس‌بندی سرویس، مجبور نخواهید بود اتصال را به روش خاصی برای یک سرور کش اضافی مشخص کنید.

5. ساخت، رها کردن، اجرا کردن

فقط نسخه نهایی کد را روی سرور داشته باشید، بدون هیچ شانسی برای بازگرداندن نسخه. نیازی به پر کردن فضای دیسک نیست. هر کس فکر می کند که می تواند کد را با خطا به تولید برساند، برنامه نویس بدی است!

تمام مراحل استقرار باید از یکدیگر جدا شوند.

فرصتی برای عقب نشینی داشته باشید. نسخه هایی را با نسخه های قدیمی برنامه (از قبل مونتاژ شده و آماده برای نبرد) که در دسترسی سریع ذخیره شده اند ایجاد کنید تا در صورت بروز خطا بتوانید نسخه قدیمی را بازیابی کنید. یعنی به صورت مشروط یک پوشه وجود دارد انتشار و پوشه جاری، و پس از استقرار و مونتاژ موفق پوشه جاری با یک پیوند نمادین به نسخه جدید که در داخل قرار دارد، مرتبط است انتشار با نام معمولی شماره انتشار.

اینجاست که به یاد می‌آییم استقرار سبز-آبی، که به شما امکان می‌دهد نه تنها بین کدها جابجا شوید، بلکه بین همه منابع و حتی محیط‌ها با قابلیت بازگرداندن همه چیز سوئیچ کنید.

6. فرآیندها

داده های وضعیت برنامه را مستقیماً در خود برنامه ذخیره کنید. از جلسات در رم خود برنامه استفاده کنید. تا حد امکان از اشتراک گذاری بین سرویس های شخص ثالث استفاده کنید. به این واقعیت تکیه کنید که برنامه فقط می تواند یک فرآیند داشته باشد و اجازه مقیاس گذاری را نمی دهد.

در مورد جلسات، داده‌ها را فقط در حافظه پنهانی که توسط سرویس‌های شخص ثالث کنترل می‌شود (memcached، redis) ذخیره کنید، بنابراین حتی اگر 20 فرآیند برنامه در حال اجرا دارید، هر یک از آنها با دسترسی به حافظه پنهان، می‌توانند به کار با مشتری در همان حالتی که در آن کاربر در فرآیند دیگری با برنامه کار می کرد. با این رویکرد، مشخص می‌شود که مهم نیست از چند نسخه از خدمات شخص ثالث استفاده می‌کنید، همه چیز به طور عادی و بدون مشکل در دسترسی به داده‌ها کار می‌کند.

7. اتصال بندر

فقط وب سرور باید بداند که چگونه با خدمات شخص ثالث کار کند. یا بهتر از آن، خدمات شخص ثالث را مستقیماً در وب سرور نصب کنید. به عنوان مثال، به عنوان یک ماژول PHP در آپاچی.
همه سرویس های شما باید از طریق دسترسی به برخی از آدرس ها و پورت ها (localgost:5432، localhost:3000، nginx:80، php-fpm:9000) برای یکدیگر قابل دسترسی باشند، یعنی از nginx می توانم به هر دو php-fpm و به postgres و از php-fpm گرفته تا postgres و nginx و در واقع از هر سرویس می توانم به سرویس دیگری دسترسی داشته باشم. به این ترتیب، دوام یک سرویس با قابلیت دوام یک سرویس دیگر مرتبط نیست.

8. موازی سازی

با یک پروسه کار کنید وگرنه چندین پروسه با هم کنار نمی آیند!

فضایی برای پوسته پوسته شدن بگذارید. ازدحام Docker برای این کار عالی است.
Docker Swarm ابزاری برای ایجاد و مدیریت دسته‌هایی از کانتینرها بین ماشین‌های مختلف و دسته‌ای از کانتینرها در یک ماشین است.

با استفاده از swarm، می توانم تعیین کنم که چه تعداد منبع به هر فرآیند اختصاص می دهم و چه تعداد فرآیند از همان سرویس را راه اندازی خواهم کرد، و متعادل کننده داخلی که داده ها را در یک پورت معین دریافت می کند، به طور خودکار آن را به فرآیندها پراکسی می کند. بنابراین، با دیدن اینکه بار روی سرور افزایش یافته است، می توانم فرآیندهای بیشتری را اضافه کنم و در نتیجه بار روی فرآیندهای خاص را کاهش دهم.

9. یکبار مصرف

از صف برای کار با فرآیندها و داده ها استفاده نکنید. از بین بردن یک فرآیند باید بر کل برنامه تأثیر بگذارد. اگر یک سرویس پایین بیاید، همه چیز از بین می رود.

هر فرآیند و سرویسی را می توان در هر زمان خاموش کرد و این نباید روی سرویس های دیگر تأثیر بگذارد (البته این بدان معنا نیست که سرویس برای سرویس دیگری در دسترس نخواهد بود، بلکه بعد از این سرویس دیگری خاموش نمی شود). تمام فرآیندها باید با ظرافت خاتمه داده شوند تا در صورت پایان یافتن، هیچ داده ای آسیب نبیند و دفعه بعد که آن را روشن کردید، سیستم به درستی کار کند. یعنی حتی در صورت خاتمه اضطراری، داده ها نباید آسیب ببینند (مکانیسم تراکنش در اینجا مناسب است، پرس و جوها در پایگاه داده فقط به صورت گروهی کار می کنند، و اگر حداقل یک پرس و جو از گروه با شکست مواجه شود یا با یک پرس و جو اجرا شود. خطا، پس هیچ پرس و جوی دیگری از گروه در نهایت در واقع شکست نمی خورد).

10. برابری توسعه/عملیات برنامه

تولید، مرحله بندی و نسخه محلی برنامه باید متفاوت باشد. در تولید ما از چارچوب Yii Lite و به صورت محلی Yii استفاده می کنیم تا در تولید سریعتر کار کند!

در واقعیت، همه استقرارها و کار با کد باید تقریباً در یک محیط یکسان باشد (ما در مورد سخت افزار فیزیکی صحبت نمی کنیم). همچنین، هر کارمند توسعه باید بتواند در صورت لزوم کد را برای تولید مستقر کند، نه برخی از بخش‌های توسعه‌دهنده آموزش‌دیده که تنها به لطف قدرت ویژه می‌توانند برنامه را به تولید برسانند.

داکر نیز در این زمینه به ما کمک می کند. اگر تمام نکات قبلی رعایت شود، استفاده از داکر فرآیند استقرار محیط را هم در تولید و هم در ماشین محلی به وارد کردن یک یا دو دستور می‌آورد.

11. سیاهههای مربوط

ما در فایل ها و پایگاه های داده لاگ می نویسیم! ما فایل ها و پایگاه های داده را از لاگ ها پاک نمی کنیم. بیایید فقط یک هارد دیسک با 9000 پتا بایت بخریم و این خوب است.

همه لاگ ها باید به عنوان جریانی از رویدادها در نظر گرفته شوند. خود برنامه نباید درگیر پردازش گزارش‌ها باشد. لاگ ها باید یا به stdout خروجی شوند یا از طریق پروتکلی مانند udp ارسال شوند تا کار با لاگ ها مشکلی برای برنامه ایجاد نکند. خاکستری برای این خوب است. Graylog دریافت همه گزارش ها از طریق udp (این پروتکل نیازی به انتظار برای پاسخ در مورد دریافت موفقیت آمیز بسته ندارد) به هیچ وجه در برنامه تداخلی ایجاد نمی کند و فقط با ساختار و پردازش گزارش ها سروکار دارد. منطق برنامه برای کار با چنین رویکردهایی تغییر نمی کند.

12. وظایف اداری

برای به روز رسانی داده ها، پایگاه های داده و غیره، از یک نقطه پایانی ایجاد شده جداگانه در API استفاده کنید، اجرای آن 2 بار پشت سر هم باعث می شود همه چیز تکراری شود. اما شما احمق نیستید، دوبار کلیک نمی کنید و ما به مهاجرت نیازی نداریم.

تمام وظایف مدیریت باید در محیطی مشابه با همه کدها، در سطح انتشار انجام شود. یعنی اگر نیاز به تغییر ساختار پایگاه داده داشته باشیم، با تغییر نام ستون ها و اضافه کردن موارد جدید از طریق برخی ابزارهای مدیریت پایگاه داده بصری، این کار را به صورت دستی انجام نمی دهیم. برای چنین مواردی، ما اسکریپت های جداگانه - مهاجرت ایجاد می کنیم که در همه جا و در همه محیط ها به یک شکل با یک نتیجه مشترک و قابل درک اجرا می شوند. برای تمام وظایف دیگر، مانند پر کردن پروژه با داده ها، باید از روش های مشابه استفاده شود.

اجرای مثال در PHP، Laravel، Laradock، Docker-Compose

P.S همه نمونه ها در MacOS ساخته شده اند. اکثر آنها برای لینوکس نیز مناسب هستند. کاربران ویندوز، مرا ببخشید، اما من مدت زیادی است که با ویندوز کار نکرده ام.

بیایید شرایطی را تصور کنیم که در آن هیچ نسخه ای از PHP روی رایانه شخصی خود نصب نشده باشد و اصلاً هیچ چیزی وجود نداشته باشد.
آخرین نسخه docker و docker-compose را نصب کنید. (این را می توان در اینترنت یافت)

docker -v && 
docker-compose -v

1. قرار دهید لارادوک

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

در مورد لارادوک می گویم که چیز بسیار باحالی است که حاوی ظروف و چیزهای کمکی زیادی است. اما من استفاده از Laradock را بدون تغییرات در تولید توصیه نمی‌کنم، زیرا این کار اضافی است. بهتر است کانتینرهای خود را بر اساس نمونه هایی در Laradock ایجاد کنید، این بسیار بهینه تر خواهد بود، زیرا هیچ کس به همه چیزهایی که در همان زمان وجود دارد نیاز ندارد.

2. Laradock را برای اجرای برنامه ما پیکربندی کنید.

cd laradock && 
cp env-example .env

2.1. دایرکتوری habr (پوشه والد که laradock در آن کلون شده است) را در یک ویرایشگر باز کنید. (در مورد PHPStorm من)

در این مرحله ما فقط به پروژه یک نام می دهیم.

2.2. تصویر فضای کاری را اجرا کنید. (در مورد شما، ساختن تصاویر کمی طول می کشد)
Workspace یک تصویر ویژه برای کار با فریم ورک از طرف توسعه دهنده است.

با استفاده از داخل ظرف می رویم

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

2.3. نصب لاراول

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

2.4. پس از نصب، بررسی می کنیم که آیا دایرکتوری با پروژه ایجاد شده است یا خیر و compose را می کشیم.

ls
exit
docker-compose down

2.5. بیایید به PHPStorm برگردیم و مسیر صحیح برنامه laravel خود را در فایل env.

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 استفاده کنید، در مورد من اینطور است گیت کراکن. (اینم لینک ارجاع)

4. راه اندازی کنیم!

قبل از شروع، مطمئن شوید که چیزی روی پورت های 80 و 443 آویزان نیست.

docker-compose up -d nginx php-fpm

بنابراین، پروژه ما شامل 3 سرویس جداگانه است:

• nginx - وب سرور
• php-fpm - php برای دریافت درخواست از یک وب سرور
• فضای کاری - php برای توسعه دهندگان

در حال حاضر، ما به این نتیجه رسیده ایم که یک برنامه کاربردی ایجاد کرده ایم که 4 امتیاز از 12 را دارد، یعنی:

1. پایگاه کد - همه کدها در یک مخزن هستند (نکته کوچک: ممکن است درست باشد که داکر را در پروژه لاراول اضافه کنید، اما این مهم نیست).

2. وابستگی ها - تمام وابستگی های ما به صراحت در application/composer.json و در هر Dockerfile هر ظرف نوشته شده است.

3. خدمات پشتیبان — هر یک از سرویس ها (php-fom، niignx، workspace) زندگی خود را می گذراند و از بیرون متصل می شود و هنگام کار با یک سرویس، سرویس دیگر تحت تأثیر قرار نمی گیرد.

4. فرایندها - هر سرویس یک فرآیند است. هر یک از خدمات حالت داخلی را حفظ نمی کند.

5. اتصال بندر

docker ps

همانطور که می بینیم، هر سرویس در پورت خود اجرا می شود و برای سایر سرویس ها قابل دسترسی است.

6. همزمانی

Docker به ما امکان می دهد چندین فرآیند از یک سرویس را با تعادل بار خودکار بین آنها ایجاد کنیم.

بیایید کانتینرها را متوقف کنیم و آنها را از طریق پرچم عبور دهیم -- مقیاس

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

همانطور که می بینیم، کپی هایی از ظرف php-fpm ایجاد شده است. در کار با این ظرف نیازی به تغییر چیزی نداریم. ما همچنین دسترسی به آن را در پورت 9000 ادامه می دهیم و داکر بار بین کانتینرها را برای ما تنظیم می کند.

7. یکبار مصرف - هر ظرف را می توان بدون آسیب رساندن به دیگری کشت. توقف یا راه اندازی مجدد کانتینر بر عملکرد برنامه در طول راه اندازی های بعدی تأثیری نخواهد داشت. همچنین هر ظرف را می توان در هر زمان بلند کرد.

8. برابری توسعه برنامه/عملیات - همه محیط های ما یکسان است. با اجرای سیستم بر روی سرور در حال تولید، نیازی به تغییر چیزی در دستورات خود نخواهید داشت. همه چیز به همین ترتیب بر اساس داکر خواهد بود.

9. ورود به سیستم - همه گزارش‌های موجود در این کانتینرها به جریان می‌روند و در کنسول Docker قابل مشاهده هستند. (در این مورد، در واقع، در مورد سایر ظروف خانگی، اگر از آن مراقبت نکنید، ممکن است اینطور نباشد)

 docker-compose logs -f

اما نکته ای وجود دارد که مقادیر پیش فرض در PHP و Nginx نیز لاگ را در یک فایل می نویسند. برای برآوردن 12 عامل، لازم است قطع ارتباط نوشتن گزارش ها در یک فایل در تنظیمات هر ظرف به طور جداگانه.

Docker همچنین امکان ارسال گزارش‌ها را نه فقط به stdout، بلکه به مواردی مانند graylog که در بالا ذکر کردم را نیز فراهم می‌کند. و در داخل خاکستری، ما می توانیم سیاهههای مربوط را به دلخواه خود اجرا کنیم و برنامه ما به هیچ وجه متوجه این موضوع نخواهد شد.

10. وظایف اداری - تمام وظایف مدیریت توسط laravel به لطف ابزار artisan دقیقاً همانطور که سازندگان برنامه 12 فاکتور می خواهند حل می شود.

به عنوان مثال، نحوه اجرای برخی از دستورات را نشان خواهم داد.
وارد ظرف می شویم.

 
docker-compose exec workspace bash
php artisan list

اکنون می توانیم از هر دستوری استفاده کنیم. (لطفاً توجه داشته باشید که ما پایگاه داده و کش را پیکربندی نکرده ایم، بنابراین نیمی از دستورات به درستی اجرا نمی شوند، زیرا برای کار با کش و پایگاه داده طراحی شده اند).

11. پیکربندی و 12 بسازید، رها کنید، اجرا کنید

من می خواستم این قسمت را به استقرار سبز-آبی اختصاص دهم، اما برای این مقاله بسیار گسترده بود. در این مورد مقاله جداگانه ای خواهم نوشت.

به طور خلاصه، این مفهوم بر اساس سیستم های CI/CD مانند است جنکینز и Gitlab CI. در هر دو، می توانید متغیرهای محیطی مرتبط با یک محیط خاص را تنظیم کنید. بر این اساس، در این شرایط، نقطه ج برآورده خواهد شد پیکربندی.

و نکته در مورد بسازید، رها کنید، اجرا کنید توسط توابع داخلی با نام حل می شود خط لوله.

خط لوله به شما امکان می دهد فرآیند استقرار را به چندین مرحله تقسیم کنید و مراحل مونتاژ، انتشار و اجرا را برجسته کنید. همچنین در Pipeline، می توانید پشتیبان گیری کنید، و در واقع هر چیزی. این یک ابزار با پتانسیل بی حد و حصر است.

کد برنامه در است گیتهاب.
هنگام شبیه سازی این مخزن فراموش نکنید که زیر ماژول را مقداردهی اولیه کنید.

P.S.: همه این رویکردها را می توان با سایر ابزارها و زبان های برنامه نویسی استفاده کرد. نکته اصلی این است که ماهیت متفاوت نیست.

منبع: www.habr.com