لومړی، یو کوچنی نظر. څه شوي دي ?
په ساده ټکو کې ، دا سند د SaaS غوښتنلیکونو پراختیا ساده کولو لپاره ډیزاین شوی ، د پراختیا کونکو او DevOps انجینرانو سره د ستونزو او کړنو په اړه د معلوماتو ورکولو سره مرسته کوي چې ډیری وختونه د عصري غوښتنلیکونو پراختیا کې ورسره مخ کیږي.
دا سند د هیروکو پلیټ فارم پراختیا کونکو لخوا رامینځته شوی.
دولس فکتور اپلیکیشن په هر پروګرامینګ ژبه لیکل شوي غوښتنلیکونو او د ملاتړ خدماتو هر ترکیب کارولو (ډیټابیسز ، پیغام کتارونه ، کیچونه او نور) کارول کیدی شي.
په لنډه توګه د هغه فکتورونو په اړه چې دا میتودولوژي اساس لري:
- کوډبیس - یو کوډبیس په نسخه کنټرول کې تعقیب شوی - ډیری ځای پرځای کول
- انحصارونه - په ښکاره توګه د انحصار اعلان او جلا کول
- شکل بندي - د چلولو په وخت کې تشکیلات خوندي کړئ
- د ملاتړ خدمتونه - د ملاتړ خدمتونه د پلگ ان سرچینو په توګه په پام کې ونیسئ
- جوړول، خوشې کول، چلول - د مجلس او اجرا مرحلې په کلکه سره جلا کړئ
- پروسې - غوښتنلیک د یو یا ډیرو بې ریاستي پروسو په توګه پرمخ وړئ
- د بندر پابند - د بندر پابندۍ له لارې صادرات خدمتونه
- موازي کول - د پروسو په کارولو سره خپل غوښتنلیک اندازه کړئ
- بې ځایه کیدل - د ګړندي پیل او پاک بندیدو سره اعتبار اعظمي کړئ
- د غوښتنلیک پراختیا / عملیاتي برابري - د امکان تر حده خپل پرمختګ ، سټینګ او تولید چاپیریال وساتئ
- ننوتل - لاګ د پیښو د جریان په توګه وګورئ
- اداري دندې - د اډ هاک پروسو په کارولو سره د ادارې / مدیریت دندې ترسره کړئ
تاسو کولی شئ د لاندې سرچینو څخه د 12 فکتورونو په اړه نور معلومات ترلاسه کړئ:
- - لوستل یې اړین دي
- - رسمي ژباړه
- - 12 فکتورونو ته یوه نوې کتنه د دوی د ښه کولو په هدف.
د نیلي شنه ګمارنه څه ده؟
د نیلي شنه ګمارل د غوښتنلیک وړاندې کولو یوه طریقه ده تولید په دې ډول چې وروستی پیرودونکي په خپله برخه کې هیڅ بدلون نه ګوري. په بل عبارت، د صفر سره د غوښتنلیک ځای پرځای کول د لنډ وخت وخت.
د کلاسیک BG ډیپلای سکیم داسې ښکاري چې په لاندې عکس کې ښودل شوي.
- په پیل کې 2 فزیکي سرورونه شتون لري چې په بشپړ ډول ورته کوډ، غوښتنلیک، پروژه، او یو روټر (بیانسر) شتون لري.
- روټر په پیل کې ټولې غوښتنې یو سرور ته لارښوونه کوي (شنه).
- په اوس وخت کې کله چې تاسو بیا خوشې کولو ته اړتیا لرئ، ټوله پروژه په بل سرور کې تازه کیږي (نیل)، کوم چې اوس مهال هیڅ ډول غوښتنې نه پروسس کوي.
- وروسته له دې چې کوډ فعال دی آبي سرور په بشپړ ډول تازه شوی، روټر ته د بدلولو قومانده ورکړل شوې شنه په نیل سرور
- اوس ټول پیرودونکي د کوډ سره د چلولو پایله ګوري نیل سرور
- د یو څه وخت لپاره، شنه سرور د ناکامې ګمارنې په صورت کې د بیک اپ کاپي په توګه کار کوي نیل سرور او د ناکامۍ او بګونو په صورت کې ، روټر د کارونکي جریان بیرته ته واړوي شنه سرور د زاړه مستحکم نسخې سره، او نوی کوډ د بیاکتنې او ازموینې لپاره لیږل کیږي.
- او د پروسې په پای کې، دا په ورته ډول تازه کیږي شنه سرور او د دې تازه کولو وروسته ، روټر د غوښتنې جریان بیرته ته واړوي شنه سرور
دا ټول خورا ښه ښکاري او په لومړي نظر کې باید ورسره کومه ستونزه ونلري.
مګر له هغه ځایه چې موږ په عصري نړۍ کې ژوند کوو، د فزیکي بدلولو اختیار لکه څنګه چې په کلاسیک سکیم کې ښودل شوي موږ ته مناسب نه دی. د اوس لپاره معلومات ثبت کړئ، موږ به وروسته بیرته راوګرځو.
بد او ښه مشوره
دادعا: لاندې مثالونه هغه اسانتیاوې/میتودولوژي ښیي چې زه یې کاروم، تاسو کولی شئ د ورته دندو سره بالکل هر ډول بدیل وکاروئ.
ډیری مثالونه به په یو ډول یا بل ډول د ویب پراختیا سره وصل شي (دا حیرانتیا ده) ، د پی ایچ پی او ډاکر سره.
لاندې پراګرافونه د ځانګړو مثالونو په کارولو سره د فکتورونو کارولو ساده عملي توضیحات وړاندې کوي؛ که تاسو غواړئ پدې موضوع نور تیوري ترلاسه کړئ، اصلي سرچینې ته پورته لینکونه تعقیب کړئ.
1. کوډبیس
په یو وخت کې سرورونو ته د فایلونو اپلوډ کولو لپاره FTP او FileZilla وکاروئ ، کوډ د تولید سرور پرته بل چیرې مه ذخیره کوئ.
پروژه باید تل د یو واحد کوډ اساس ولري، دا دی، ټول کوډ له یو څخه راځي Git ذخیره سرورونه (تولید، سټیګینګ، ټیسټ 1، ټیسټ 2 ...) د یو عام ذخیره د څانګو څخه کوډ کاروي. پدې توګه موږ د کوډ ثبات ترلاسه کوو.
2. انحصار
ټول کتابتونونه په فولډر کې ډاونلوډ کړئ مستقیم د پروژې ریښې ته. په ساده ډول د کتابتون اوسني نسخه سره فولډر ته د نوي کوډ په لیږدولو سره تازه معلومات چمتو کړئ. ټولې اړینې اسانتیاوې مستقیم په کوربه سرور کې نصب کړئ چیرې چې 20 نور خدمتونه روان دي.
یوه پروژه باید تل د انحصاراتو په روښانه ډول د پوهیدو وړ لیست ولري (د انحصار په واسطه زه د چاپیریال معنی هم لرم). ټول انحصارونه باید په واضح ډول تعریف او جلا شي.
راځئ چې د مثال په توګه واخلو کمپوز и ډاکر.
کمپوز - د کڅوړې مدیر چې تاسو ته اجازه درکوي په PHP کې کتابتونونه نصب کړئ. کمپوزر تاسو ته اجازه درکوي چې نسخې په کلکه یا نرمه توګه مشخص کړئ، او په واضح ډول یې تعریف کړئ. په سرور کې 20 مختلف پروژې کیدی شي او هر یو به د بل څخه خپلواک د کڅوړو او کتابتونونو شخصي لیست ولري.
ډاکر - یو افادیت چې تاسو ته اجازه درکوي چاپیریال تعریف او جلا کړئ چیرې چې غوښتنلیک به پرمخ ځي. په دې اساس، لکه د کمپوزر سره، مګر په بشپړ ډول، موږ کولی شو معلومه کړو چې غوښتنلیک د څه سره کار کوي. د PHP ځانګړی نسخه غوره کړئ، یوازې د پروژې کار کولو لپاره اړین کڅوړې نصب کړئ، پرته له کوم اضافي اضافه کولو. او تر ټولو مهم، د کوربه ماشین او نورو پروژو کڅوړو او چاپیریال سره د مداخلې پرته. دا دی ، په سرور کې ټولې پروژې د ډاکر له لارې پرمخ وړي کولی شي په بشپړ ډول د کڅوړو هر ډول سیټ او په بشپړ ډول مختلف چاپیریال وکاروي.
3. ترتیب کول
ترتیبونه په مستقیم ډول په کوډ کې د ثابت په توګه ذخیره کړئ. د ازموینې سرور لپاره جلا جلا، د تولید لپاره جلا. د غوښتنلیک عملیات په مستقیم ډول د پروژې سوداګرۍ منطق کې د چاپیریال پورې اړه لري که چیرې نور جوړ شي په کارولو سره.
CONFIGURACII - دا یوازینۍ لار ده چې د پروژې پلي کول باید توپیر ولري. په عین حال کې، تشکیلات باید د چاپیریال متغیرونو (env vars) له لارې تیر شي.
دا دی، حتی که تاسو د ترتیب کولو ډیری فایلونه .config.prod .config.local ذخیره کړئ او د ځای پرځای کولو په وخت کې یې نوم .config ته بدل کړئ (اصلي تشکیل چې غوښتنلیک یې ډاټا لوستل کوي) - دا به سمه لاره نه وي، ځکه چې پدې حالت کې د ترتیبونو څخه معلومات به په عامه توګه د ټولو غوښتنلیک پراختیا کونکو ته شتون ولري او د تولید سرور ډیټا به موافق وي. ټول تشکیلات باید په مستقیم ډول د پلي کولو سیسټم (CI/CD) کې زیرمه شي او د مختلف چاپیریالونو لپاره تولید شوي مختلف ارزښتونو سره د ځای په ځای کولو په وخت کې د ځانګړي چاپیریال لپاره اړین دي.
4. د دریمې ډلې خدمتونه
د چاپیریال سره په کلکه تړلی اوسئ، په ځانګړو چاپیریالونو کې د ورته خدماتو لپاره مختلف اړیکې وکاروئ.
په حقیقت کې ، دا ټکی په کلکه د تشکیلاتو په اړه ټکي سره تیریږي ، ځکه چې د دې نقطې پرته ، د تنظیم کولو نورمال ډیټا نشي رامینځته کیدی او په عموم کې ، د تنظیم کولو وړتیا به هیڅ شی ته راټیټ شي.
د بهرنیو خدماتو سره ټولې اړیکې، لکه قطار سرورونه، ډیټابیسونه، د کیشینګ خدمتونه، باید د محلي چاپیریال او دریمې ډلې / تولید چاپیریال لپاره یو شان وي. په بل عبارت، په هر وخت کې، د پیوستون تار بدلولو سره، زه کولی شم د غوښتنلیک کوډ بدلولو پرته د بیس # 1 سره بیس # 2 ته زنګونه بدل کړم. یا، مخکې لټول، د بیلګې په توګه، کله چې د خدمت اندازه کول، تاسو اړتیا نلرئ د اضافي کیچ سرور لپاره په کوم ځانګړي ډول پیوستون مشخص کړئ.
5. جوړول، خوشې کول، اجرا کول
په سرور کې د کوډ وروستۍ نسخه ولرئ، پرته له دې چې د خوشې کولو بیرته راګرځولو چانس شتون ولري. د ډیسک ځای ډکولو ته اړتیا نشته. هرڅوک چې فکر کوي چې دوی کولی شي د غلطۍ سره تولید ته کوډ خوشې کړي یو خراب پروګرامر دی!
د ګمارنې ټولې مرحلې باید له یو بل څخه جلا شي.
د بیرته راګرځیدو فرصت ولرئ. د غوښتنلیک د زړو کاپيونو سره ریلیزونه جوړ کړئ (دمخه راټول شوي او د جګړې لپاره چمتو شوي) په ګړندي لاسرسي کې خوندي شوي ، نو د غلطیو په صورت کې تاسو کولی شئ زوړ نسخه بحال کړئ. دا دی، په مشروط ډول یو فولډر شتون لري خوشې او فولډر اوسني، او د فولډر بریالیتوب او تنظیم کولو وروسته اوسني د نوي خوشې کولو لپاره د سمبولیک لینک لخوا تړل شوی چې دننه پروت دی خوشې د خوشې شمیرې دودیز نوم سره.
دا هغه ځای دی چې موږ د نیلي - شنه پلي کول په یاد لرو ، کوم چې تاسو ته اجازه درکوي نه یوازې د کوډ ترمینځ تیر کړئ ، بلکه د ټولو سرچینو او حتی چاپیریالونو ترمینځ د هرڅه بیرته راګرځولو وړتیا سره تیر کړئ.
6. پروسې
د غوښتنلیک حالت ډاټا مستقیم په غوښتنلیک کې ذخیره کړئ. پخپله د غوښتنلیک په RAM کې ناستې وکاروئ. د امکان تر حده د دریمې ډلې خدماتو تر مینځ ډیر شریک وکاروئ. په دې حقیقت تکیه وکړئ چې غوښتنلیک یوازې یوه پروسه لري او د اندازه کولو اجازه مه ورکوئ.
د غونډو په اړه، ډاټا یوازې په هغه کیچ کې ذخیره کړئ چې د دریمې ډلې خدماتو لخوا کنټرول کیږي (میمکیچ، ریډیس)، نو حتی که تاسو د غوښتنلیک 20 پروسې پرمخ وړئ، د دوی هر یو، چې کیچ ته السرسی لري، به وکوالی شي د پیرودونکي سره کار ته دوام ورکړي. په ورته حالت کې چې کارونکي په بل پروسې کې د غوښتنلیک سره کار کاوه. د دې تګلارې سره، دا معلومه شوه چې د دریمې ډلې خدماتو څومره کاپي چې تاسو یې کاروئ، هرڅه به په نورمال ډول کار وکړي او ډیټا ته د لاسرسي ستونزې پرته.
7. د پورټ پابند
یوازې د ویب سرور باید پوه شي چې څنګه د دریمې ډلې خدماتو سره کار وکړي. یا تر اوسه غوره، د دریمې ډلې خدمتونه مستقیم د ویب سرور دننه نصب کړئ. د مثال په توګه، په اپاچي کې د پی ایچ پی ماډل په توګه.
ستاسو ټول خدمتونه باید یو بل ته د ځینې پتې او بندر ته د لاسرسي له لارې د لاسرسي وړ وي (localgost: 5432, localhost: 3000, nginx: 80, php-fpm: 9000) ، دا د nginx څخه زه کولی شم دواړه php-fpm ته لاسرسی ومومئ postgres، او له php-fpm څخه postgres او nginx ته او په حقیقت کې له هر خدمت څخه زه کولی شم بل خدمت ته لاسرسی ومومم. په دې توګه، د خدمت وړتیا د بل خدمت د وړتیا سره تړاو نلري.
8. موازي
د یوې پروسې سره کار وکړئ، که نه نو څو پروسې به د یو بل سره یوځای نشي!
د اندازه کولو لپاره خونه پریږدئ. د ډاکر سوارم د دې لپاره عالي دی.
ډاکر سوارم د کانټینرونو کلسترونو رامینځته کولو او اداره کولو لپاره یوه وسیله ده چې دواړه د مختلف ماشینونو ترمینځ او په ورته ماشین کې د کانټینرونو ډله ده.
د swarm په کارولو سره، زه کولی شم وټاکم چې څومره سرچینې به زه هرې پروسې ته تخصیص کړم او د ورته خدمت څومره پروسې به پیل کړم، او داخلي بیلانسر، په ورکړل شوي بندر کې ډاټا ترلاسه کوي، دا به په اتوماتيک ډول پروسو ته پراکسي کړي. په دې توګه، دا لیدل چې په سرور کې بار زیات شوی، زه کولی شم نورې پروسې اضافه کړم، په دې توګه په ځینو پروسو باندې بار کم کړم.
9. بې ځایه کیدل
د پروسو او معلوماتو سره کار کولو لپاره قطارونه مه کاروئ. د یوې پروسې وژل باید ټول غوښتنلیک اغیزمن کړي. که یو خدمت ټیټ شي، هر څه ټیټ کیږي.
هره پروسه او خدمت په هر وخت کې بند کیدی شي او دا باید په نورو خدماتو اغیزه ونلري (البته ، دا پدې معنی ندي چې خدمت به د بل خدمت لپاره شتون ونلري ، مګر دا چې بل خدمت به له دې وروسته بند نشي). ټولې پروسې باید په زړه پورې پای ته ورسیږي، نو کله چې دوی وتړل شي، هیڅ معلومات به زیانمن نشي او سیسټم به په سمه توګه کار وکړي کله چې تاسو یې بل کړئ. دا دی، حتی د بیړني پای ته رسیدو په صورت کې، ډاټا باید زیانمن نشي (د راکړې ورکړې میکانیزم دلته مناسب دی، په ډیټابیس کې پوښتنې یوازې په ګروپونو کې کار کوي، او که لږترلږه د ګروپ څخه یوه پوښتنه ناکامه شي یا د یو سره اعدام شي. تېروتنه، نو بیا د ډلې څخه بله پوښتنه په حقیقت کې ناکامه کیږي).
10. د غوښتنلیک پراختیا/ عملیاتي برابري
د غوښتنلیک تولید، سټینګ او محلي نسخه باید توپیر ولري. په تولید کې موږ د Yii لایټ چوکاټ کاروو، او په محلي توګه Yii، نو دا په تولید کې ګړندی کار کوي!
په واقعیت کې، د کوډ سره ټول ګومارنې او کار باید نږدې ورته چاپیریال کې وي (موږ د فزیکي هارډویر په اړه خبرې نه کوو). همچنان ، هر پرمختیایی کارمند باید وړتیا ولري که اړتیا وي تولید ته کوډ ځای په ځای کړي ، او نه د ځانګړي روزل شوي ډیپوس ډیپارټمنټ ، کوم چې یوازې د ځانګړي ځواک څخه مننه کولی شي غوښتنلیک تولید ته پورته کړي.
ډاکر هم پدې کې زموږ سره مرسته کوي. که ټول پخواني ټکي مشاهده شي، د ډاکر کارول به د چاپیریال ځای پرځای کولو پروسه دواړه په تولید او محلي ماشین کې یو یا دوه کمانډونو ته ننوځي.
11. ننوتل
موږ فایلونو او ډیټابیسونو ته لاګونه لیکو! موږ د لاګونو څخه فایلونه او ډیټابیسونه نه پاکوو. راځئ چې یوازې د 9000 پیټا بایټ سره هارډ ډرایو واخلو او دا ښه دی.
ټول لاګونه باید د پیښو د جریان په توګه وګڼل شي. غوښتنلیک پخپله باید د لاګ پروسس کولو کې ښکیل نه وي. لاګونه باید یا stdout ته تولید شي یا د پروتوکول لکه udp له لارې لیږل شوي وي ، نو د لاګونو سره کار کول د غوښتنلیک لپاره کومه ستونزه رامینځته نه کړي. graylog د دې لپاره ښه دی. ګریلوګ د udp له لارې ټول لاګونه ترلاسه کوي (دا پروتوکول د پاکټ بریالي استقبال په اړه ځواب ته انتظار ته اړتیا نلري) په هیڅ ډول غوښتنلیک کې مداخله نه کوي او یوازې د جوړښت او پروسس کولو لاګونو سره معامله کوي. د غوښتنلیک منطق د داسې طریقو سره کار کولو لپاره بدلون نه کوي.
12. اداري دندې
د ډیټا، ډیټابیسونو او نورو تازه کولو لپاره، په API کې په جلا توګه جوړ شوی پای ټکی وکاروئ، په پرله پسې توګه 2 ځله اجرا کول به د هرڅه د نقل کیدو لامل شي. مګر تاسو احمق نه یاست، تاسو به دوه ځله کلیک ونکړئ، او موږ مهاجرت ته اړتیا نلرو.
د ادارې ټولې دندې باید په ورته چاپیریال کې د ټولو کوډ په څیر ترسره شي، د خوشې کولو په کچه. دا دی، که موږ د ډیټابیس جوړښت بدلولو ته اړتیا ولرو، نو موږ به دا په لاسي ډول د کالمونو نوم بدلولو او د ځینې بصري ډیټابیس مدیریت وسیلو له لارې نوي اضافه کولو سره ترسره نه کړو. د داسې شیانو لپاره، موږ جلا سکریپټونه رامینځته کوو - مهاجرتونه، چې په هر ځای او ټولو چاپیریالونو کې په ورته ډول د عام او پوهیدو وړ پایلې سره اجرا کیږي. د نورو ټولو دندو لپاره، لکه د معلوماتو سره د پروژې ډکول، ورته میتودونه باید وکارول شي.
په PHP، Laravel، Laradock، Docker-compose کې د مثال پلي کول
PS ټول مثالونه په MacOS کې جوړ شوي. ډیری یې د لینکس لپاره هم مناسب دي. د وینډوز کاروونکو، ما بخښنه وکړه، مګر ما د اوږدې مودې لپاره د وینډوز سره کار نه دی کړی.
راځئ چې یو داسې حالت تصور کړو چیرې چې موږ په خپل کمپیوټر کې د PHP هیڅ نسخه نلرو او هیڅ شی نشته.
د ډاکر او ډاکر - کمپوز وروستي نسخې نصب کړئ. (دا په انټرنیټ کې موندل کیدی شي)
docker -v &&
docker-compose -v
1. اچول
git clone https://github.com/Laradock/laradock.git &&
ls
د لاراډاک په اړه، زه به ووایم چې دا خورا ښه شی دی، چې ډیری کانټینرونه او مرستندویه شیان لري. مګر زه به د دې بې ځایه کیدو له امله په تولید کې له تعدیلاتو پرته د لاراډاک کارولو وړاندیز ونه کړم. دا غوره ده چې په لارډاک کې د مثالونو پراساس خپل کانټینرونه رامینځته کړئ ، دا به خورا ډیر مطلوب وي ، ځکه چې هیڅ څوک په ورته وخت کې هرڅه ته اړتیا نلري.
2. زموږ د غوښتنلیک چلولو لپاره لاراډاک تنظیم کړئ.
cd laradock &&
cp env-example .env
2.1. په ځینې مدیر کې د هابر ډایرکټر خلاص کړئ (د اصلي فولډر په کوم کې چې لارډاک کلون شوی وي). (زما د 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 فایل کې زموږ لارویل غوښتنلیک ته سمه لاره وټاکو.
3. Git ته ټول کوډ اضافه کړئ.
د دې کولو لپاره ، موږ به په ګیتوب (یا بل چیرې) کې ذخیره جوړه کړو. راځئ چې په ترمینل کې د 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
راځئ وګورو چې ایا هرڅه سم دي.
د اسانتیا لپاره، زه د ګیټ لپاره د ځینې بصری انٹرفیس کارولو وړاندیز کوم، زما په قضیه کې دا دی . (دلته د راجع کولو لینک دی)
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، nignx، workspace) خپل ژوند کوي او له بهر څخه وصل دی او کله چې د یو خدمت سره کار کوي، بل به اغیزمن نشي.
4. پروسې - هر خدمت یوه پروسه ده. هر یو خدمت داخلي حالت نه ساتي.
5. د بندر پابند
docker ps
لکه څنګه چې موږ لیدلی شو، هر خدمت په خپل بندر کې پرمخ ځي او نورو ټولو خدماتو ته د لاسرسي وړ دی.
6. موازي کول
ډاکر موږ ته اجازه راکوي چې د ورته خدماتو ډیری پروسې د دوی ترمینځ د اتوماتیک بار توازن سره رامینځته کړو.
راځئ چې کانټینرونه ودروو او د بیرغ له لارې یې وګرځوو -- پیمانه
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
لکه څنګه چې موږ لیدلی شو، نقلونه د php-fpm کانټینر څخه جوړ شوي. موږ د دې کانټینر سره کار کولو کې هیڅ بدلون ته اړتیا نلرو. موږ دې ته په 9000 بندر کې لاسرسي ته هم دوام ورکوو ، او ډاکر زموږ لپاره د کانټینرونو ترمینځ بار تنظیموي.
7. بې ځایه کیدل - هر کانټینر بل ته زیان رسولو پرته وژل کیدی شي. د کانټینر ودرول یا بیا پیل کول به د راتلونکو لانچونو په جریان کې د غوښتنلیک عملیات اغیزه ونکړي. هر کانټینر هم په هر وخت کې پورته کیدی شي.
8. د غوښتنلیک پراختیا / عملیاتي برابري - زموږ ټول چاپیریال یو شان دی. په تولید کې په سرور کې د سیسټم چلولو سره، تاسو اړتیا نلرئ په خپلو حکمونو کې هیڅ شی بدل کړئ. هرڅه به په ورته ډول د ډاکر پراساس وي.
9. ننوتل - په دې کانټینرونو کې ټولې لاګونه جریان ته ځي او د ډاکر کنسول کې لیدل کیږي. (په دې حالت کې، په حقیقت کې، د نورو کور جوړ شوي کانټینرونو سره، دا ممکن قضیه نه وي که تاسو ورته پاملرنه ونه کړئ)
docker-compose logs -f
مګر پدې کې یو کیچ شتون لري چې په PHP او Nginx کې ډیفالټ ارزښتونه هم فایل ته لاګونه لیکي. د 12 فکتورونو پوره کولو لپاره، دا اړینه ده معلول د هر کانټینر په ترتیب کې په جلا توګه فایل ته د لاګونو لیکل.
ډاکر د لاګونو لیږلو وړتیا هم چمتو کوي چې نه یوازې سټډاوټ ته ، بلکه داسې شیانو ته هم لکه ګریلوګ ، کوم چې ما پورته یادونه وکړه. او په ګریلوګ کې دننه، موږ کولی شو لاګونه لکه څنګه چې وغواړو چلولی شو او زموږ غوښتنلیک به دا په هیڅ ډول پام ونه کړي.
10. اداري دندې - ټولې ادارې دندې د لارویل لخوا حل کیږي د هنرمند وسیلې څخه مننه په سمه توګه لکه څنګه چې د 12 فاکتور غوښتنلیک جوړونکي غواړي.
د مثال په توګه، زه به وښیم چې څنګه ځینې حکمونه اجرا کیږي.
موږ کانتینر ته ځو.
docker-compose exec workspace bash
php artisan list
اوس موږ کولی شو هر ډول کمانډ وکاروو. (مهرباني وکړئ په یاد ولرئ چې موږ ډیټابیس او کیچ نه دی تنظیم کړی، نو نیمایي کمانډونه به په سمه توګه اجرا نشي، ځکه چې دوی د کیچ او ډیټابیس سره کار کولو لپاره ډیزاین شوي).
11. CONFIGURACII او 12. جوړول، خوشې کول، چلول
ما غوښتل دا برخه د نیلي - شنه پلي کولو ته وقف کړم ، مګر دا د دې مقالې لپاره خورا پراخه وګرځید. زه به په دې اړه جلا مقاله ولیکم.
په لنډه توګه، مفهوم د CI/CD سیسټمونو پر بنسټ والړ دی لکه جینکنز и Gitlab CI. په دواړو کې، تاسو کولی شئ د یو ځانګړي چاپیریال سره تړلي چاپیریال متغیرات تنظیم کړئ. په دې اساس، پدې حالت کې، نقطه c به پوره شي تشکیلات.
او په اړه ټکی جوړول، خوشې کول، چلول د نوم سره د جوړ شوي افعال لخوا حل کیږي پایپ لاین.
پایپ لاین تاسو ته اجازه درکوي د ګمارنې پروسه په ډیری مرحلو ویشئ، د غونډې، خوشې کولو او اجرا کولو مرحلې په ګوته کول. همدارنګه په پایپ لاین کې، تاسو کولی شئ بیک اپ جوړ کړئ، او په حقیقت کې هر څه. دا د لامحدود ظرفیت سره یوه وسیله ده.
د غوښتنلیک کوډ په کې دی .
د دې ذخیره کلون کولو پرمهال د فرعي ماډل پیل کول مه هیروئ.
PS: دا ټولې لارې د نورو اسانتیاوو او پروګرام کولو ژبو سره کارول کیدی شي. اصلي شی دا ده چې جوهر توپیر نلري.
سرچینه: www.habr.com