موږ به زموږ بلاګ زموږ د تخنیکي رییس د وروستیو ویناوو پراساس د خپرونو سره پیل کړو (دمیتري ستولیاروف). دا ټول په 2016 کې په بیلابیلو مسلکي پیښو کې ترسره شوي او د DevOps او Docker موضوع ته وقف شوي. د بدو په دفتر کې د ډاکر مسکو غونډې څخه یوه ویډیو، موږ لا دمخه لرو آنلاین. نوي به د هغو مقالو سره وي چې د راپورونو جوهر بیانوي. نو…
د می په 31 په کنفرانس کې د "روسی انټرنیټ ټیکنالوژۍ" (RIT++ 2016) فستیوال د یوې برخې په توګه ترسره شوی، د "دوامداره ځای پرځای کول او ځای پرځای کول" برخه د "ډاکر سره د دوامداره تحویلي غوره عمل" راپور سره پرانستل شوه. دې د ډاکر او نورو خلاصې سرچینې محصولاتو په کارولو سره د دوامداره تحویلۍ (CD) پروسې رامینځته کولو لپاره غوره عملونه لنډیز او سیسټم کړي. موږ په تولید کې د دې حلونو سره کار کوو، کوم چې موږ ته اجازه راکوي چې په عملي تجربو تکیه وکړو.
که تاسو فرصت لرئ یو ساعت مصرف کړئ ، موږ وړاندیز کوو چې دا په بشپړ ډول وګورو. که نه نو، لاندې د متن بڼه کې اصلي لنډیز دی.
د ډاکر سره دوامداره تحویلي
د دوامداره تحویلي موږ د پیښو سلسله د پایلې په توګه پوهیږو چې د Git ذخیره څخه د غوښتنلیک کوډ لومړی تولید ته راځي، او بیا په آرشیف کې پای ته رسیږي. هغه داسې ښکاري: Git → جوړونه → ازموینه → خوشې کول → عملیات.
د راپور ډیری برخه د جوړونې مرحلې ته وقف شوې (د غوښتنلیک مجلس) ، او د خپریدو او فعالیت موضوعات په لنډه توګه په ګوته شوي. موږ به د ستونزو او نمونو په اړه وغږیږو چې تاسو ته اجازه درکوي حل کړئ، او د دې نمونو ځانګړي تطبیق ممکن توپیر ولري.
ولې دلته ډاکر ته اړتیا ده؟ دا د هیڅ شی لپاره ندي چې موږ پریکړه وکړه چې د دې خلاصې سرچینې وسیلې په شرایطو کې د دوامداره تحویلي کړنو په اړه وغږیږو. که څه هم ټول راپور د هغې کارولو ته وقف شوی، ډیری دلایل څرګند شوي کله چې د غوښتنلیک کوډ رول آوټ اصلي نمونې په پام کې نیولو سره.
اصلي رول آوټ بیلګه
نو، کله چې موږ د غوښتنلیک نوې نسخې وړاندې کوو، موږ یقینا ورسره مخ یو د بند وخت ستونزه، د تولید سرور بدلولو پرمهال رامینځته شوی. د غوښتنلیک له زاړه نسخې څخه نوي ته ترافیک سمدلاسه نشي بدلیدلی: لومړی موږ باید ډاډ ترلاسه کړو چې نوې نسخه نه یوازې په بریالیتوب سره ډاونلوډ شوې ، بلکه "ګرم اپ" (د بیلګې په توګه د غوښتنو خدمت کولو لپاره بشپړ چمتو دی).
پدې توګه ، د یو څه وخت لپاره د غوښتنلیک دواړه نسخې (زاړه او نوي) به په ورته وخت کې کار وکړي. کوم چې په اتوماتيک ډول پرمخ ځي د ګډو سرچینو شخړه: شبکه، د فایل سیسټم، IPC، او نور. د ډاکر سره ، دا ستونزه په جلا کانټینرونو کې د غوښتنلیک مختلف نسخو چلولو سره په اسانۍ سره حل کیږي ، د کوم لپاره چې د سرچینې انزوا په ورته کوربه (سرور / مجازی ماشین) کې تضمین شوی. البته، تاسو کولی شئ د ځینې چلونو سره پرته له موصلیت څخه ترلاسه کړئ، مګر که چیرې یو چمتو شوی او مناسب وسیله وي، نو بیا برعکس دلیل شتون لري - دا غفلت مه کوئ.
کانټینر کول د ګمارل کیدو پرمهال ډیری نورې ګټې چمتو کوي. هر غوښتنلیک پورې اړه لري ځانګړې نسخه (یا د نسخې لړۍ) ترجماند ماډلونو/توسیعاتو شتون، او همدارنګه د دوی نسخې. او دا نه یوازې د سمدستي اجرا وړ چاپیریال باندې پلي کیږي ، بلکه په ټول چاپیریال کې هم پلي کیږي سیسټم سافټویر او د هغې نسخه (د لینکس ویش پورې کارول کیږي). د دې حقیقت له امله چې کانټینرونه نه یوازې د غوښتنلیک کوډ لري ، بلکه د اړتیا وړ نسخو دمخه نصب شوي سیسټم او غوښتنلیک سافټویر هم لري ، تاسو کولی شئ د انحصار سره ستونزې هیر کړئ.
راځئ چې لنډیز وکړو اصلي رول آوټ بیلګه نوې نسخې لاندې عوامل په پام کې نیولو سره:
- په لومړي سر کې، د غوښتنلیک زوړ نسخه په لومړي کانټینر کې پرمخ ځي.
- نوې نسخه بیا په دوهم کانټینر کې راپورته کیږي او "ګرم اپ" کیږي. دا د یادونې وړ ده چې دا نوې نسخه پخپله نه یوازې د اپلیکیشن کوډ تازه کولی شي، بلکې د هغې کوم انحصار، او همدارنګه د سیسټم برخې (د بیلګې په توګه، د OpenSSL نوې نسخه یا ټول ویش).
- کله چې نوې نسخه د غوښتنو خدمت کولو لپاره په بشپړه توګه چمتو وي، ټرافيک له لومړي کانټینر څخه دویم ته بدلیږي.
- زوړ نسخه اوس بند کیدی شي.
په جلا کانټینرونو کې د غوښتنلیک د مختلف نسخو ځای په ځای کولو دا طریقه یو بل اسانتیا چمتو کوي - چټک رول بیک زاړه نسخې ته (په هرصورت، دا د مطلوب کانټینر ته د ټرافیک بدلولو لپاره کافي ده).
وروستی لومړی وړاندیز د یو څه په څیر ښکاري چې حتی کیپټن پدې کې غلطي نشي موندلی: "[کله چې د ډاکر سره دوامداره تحویل تنظیم کړئ] Docker وکاروئ [او پوه شئ چې دا څه ورکوي]" په یاد ولرئ، دا د سپینو زرو ګولۍ نه ده چې هره ستونزه به حل کړي، مګر یوه وسیله چې په زړه پورې بنسټ چمتو کوي.
د تولید وړتیا
د "تجارتي وړتیا" په واسطه زموږ معنی د ستونزو عمومي سیټ دی چې د غوښتنلیکونو چلولو پرمهال ورسره مخ کیږي. موږ د داسې قضیو په اړه خبرې کوو:
- د سټینګ لپاره د کیفیت ډیپارټمنټ لخوا چک شوي سکریپټونه باید په تولید کې په دقت سره تولید شي.
- غوښتنلیکونه په سرورونو کې خپاره شوي چې کولی شي د مختلف ذخیره کولو عکسونو څخه کڅوړې ترلاسه کړي (د وخت په تیریدو سره دوی تازه کیږي ، او د دوی سره د نصب شوي غوښتنلیکونو نسخې).
- "هرڅه زما لپاره په محلي توګه کار کوي!" (...او پراختیا کونکو ته د تولید اجازه نه ورکول کیږي.)
- تاسو اړتیا لرئ په زاړه (آرشيف شوي) نسخه کې یو څه وګورئ.
- ...
د دوی عمومي جوهر پدې حقیقت پورې اړه لري چې د کارول شوي چاپیریال بشپړ اطاعت (او همدارنګه د انساني فاکتور نشتوالی) اړین دی. څنګه کولای شو د تولید وړتیا تضمین کړو؟ د ډاکر عکسونه جوړ کړئ د Git څخه د کوډ پراساس، او بیا یې د هر کار لپاره وکاروئ: د ازموینې سایټونو کې، په تولید کې، د پروګرامرانو په محلي ماشینونو کې ... په ورته وخت کې، دا مهمه ده چې ترسره شوي عملونه کم کړئ после د انځور راټولول: څومره چې دا ساده وي، د غلطیو احتمال لږ وي.
زیربنا کوډ دی
که د زیربنا اړتیاوې (د سرور سافټویر شتون، د هغې نسخه، او نور) رسمي نه وي او "پروګرام شوي" وي، نو د هر ډول غوښتنلیک تازه کولو رول کولی شي ناوړه پایلې ولري. د مثال په توګه ، په سټینګ کې تاسو دمخه PHP 7.0 ته تللي یاست او د دې مطابق کوډ یې بیا لیکلی - بیا د ځینې زاړه PHP (5.5) سره په تولید کې د دې ظهور به یقینا یو څوک حیران کړي. تاسو ممکن د ژباړونکي نسخه کې د لوی بدلون په اړه هیر نکړئ ، مګر "شیطان په توضیحاتو کې دی": حیرانتیا ممکن د هر ډول انحصار په کوچني تازه کې وي.
د دې ستونزې د حل لپاره یوه طریقه پیژندل کیږي IaC (د کوډ په توګه زیربنا، "د کوډ په توګه زیربنا") او د غوښتنلیک کوډ سره د زیربنا اړتیاو ذخیره کول شامل دي. د دې په کارولو سره ، پراختیا کونکي او د DevOps متخصصین کولی شي د ورته Git غوښتنلیک ذخیره سره کار وکړي ، مګر د دې مختلف برخو کې. د دې کوډ څخه، په ګیټ کې د ډاکر عکس رامینځته شوی، په کوم کې چې غوښتنلیک د زیربنا ټول ځانګړتیاوې په پام کې نیولو سره ځای پرځای شوي. په ساده ډول ، د عکسونو راټولولو لپاره سکریپټونه (قواعد) باید د سرچینې کوډ سره په ورته ذخیره کې وي او یوځای سره یوځای شي.
د څو پرت غوښتنلیک جوړښت په حالت کې - د مثال په توګه ، نګینکس شتون لري ، کوم چې د غوښتنلیک مخې ته ولاړ دی چې دمخه د ډاکر کانټینر دننه روان دی - د ډاکر عکسونه باید د هر پرت لپاره په ګیټ کې له کوډ څخه رامینځته شي. بیا به لومړی عکس د ژباړونکي او نورو "نږدې" انحصارونو سره یو غوښتنلیک ولري ، او دوهم عکس به د اپ سټریم نګینکس ولري.
د ډاکر عکسونه، د Git سره اړیکه
موږ د ګیټ څخه راټول شوي ټول ډاکر عکسونه په دوه کټګوریو ویشو: لنډمهاله او خوشې کول. لنډمهاله انځورونه په Git کې د څانګې په نوم ټګ شوی ، د راتلونکي ژمنې لخوا لیکل کیدی شي او یوازې د مخکتنې لپاره راپورته کیږي (نه د تولید لپاره). دا د خوشې کیدو څخه د دوی کلیدي توپیر دی: تاسو هیڅکله نه پوهیږئ کوم ځانګړي ژمنې په دوی کې دي.
دا په لنډمهاله عکسونو کې راټولول معنی لري: د ماسټر څانګه (تاسو کولی شئ دا په اتوماتيک ډول جلا سایټ ته واستوئ ترڅو په دوامداره توګه د ماسټر اوسنۍ نسخه وګورئ) ، د خپرونو سره څانګې ، د ځانګړي نوښتونو څانګې.
وروسته له دې چې د لنډمهاله عکسونو مخکتنه په تولید کې د ژباړې اړتیا ته راځي ، پراختیا کونکي یو مشخص ټاګ ولګوي. په اتوماتيک ډول د ټګ لخوا راټول شوي انځور خپور کړئ (د دې ټاګ د ګیټ څخه ټاګ سره مطابقت لري) او د سټینګ کولو لپاره رول شوی. که دا په بریالیتوب سره د کیفیت څانګې لخوا تایید شي، دا تولید ته ځي.
ډپ
هر څه چې تشریح شوي (رول آوټ، د عکس مجلس، ورپسې ساتنه) د بش سکریپټونو او نورو "اصلاح شوي" وسیلو په کارولو سره په خپلواکه توګه پلي کیدی شي. مګر که تاسو دا کار کوئ، نو بیا په یو وخت کې پلي کول به د لوی پیچلتیا او ضعیف کنټرول لامل شي. د دې په پوهیدو سره، موږ د CI/CD جوړولو لپاره د خپل ځانګړي کاري فلو یوټیلیټ رامینځته کولو ته راغلو - ډپ.
د دې سرچینې کوډ په روبي کې لیکل شوی، خلاص سرچینه او خپور شوی . له بده مرغه، اسناد اوس مهال د وسیلې ترټولو ضعیف ټکی دی، مګر موږ په دې کار کوو. او موږ به د ډیپ په اړه له یو ځل څخه ډیر ولیکئ او خبرې وکړو، ځکه چې ... موږ په صادقانه توګه انتظار نشو کولی د دې وړتیاوې د ټولې علاقې ټولنې سره شریک کړو ، مګر په ورته وخت کې ، خپلې مسلې واستوئ او غوښتنې راوباسئ او / یا په GitHub کې د پروژې پراختیا تعقیب کړئ.
د اګست 13، 2019 تازه شوی: اوس مهال یوه پروژه ډپ په نوم بدل شوی ، د دې کوډ په بشپړ ډول په Go کې لیکل شوی ، او اسناد یې د پام وړ ښه شوي.
کوبنیټس
بل چمتو شوی د خلاصې سرچینې وسیله چې دمخه یې په مسلکي چاپیریال کې د پام وړ پیژندنه ترلاسه کړې ده کوبنیټسد ډاکر مدیریت کلستر. په ډاکر کې رامینځته شوي پروژو په عملیاتو کې د دې کارولو موضوع د راپور له دائرې څخه بهر ده ، نو پریزنټشن د ځینې په زړه پورې ځانګړتیاو کتنې پورې محدود دی.
د رول آوټ لپاره، Kubernetes وړاندیز کوي:
- د چمتووالي پلټنه - د غوښتنلیک د نوي نسخې چمتووالي معاینه کول (د ټرافیک بدلولو لپاره)؛
- رولینګ تازه کول - د کانټینرونو په کلستر کې د ترتیب عکس تازه کول (بندول، تازه کول، د پیل لپاره چمتو کول، د ټرافیک بدلول)؛
- همغږي تازه کول - د مختلف طریقې سره په کلستر کې د عکس تازه کول: لومړی په نیمه کانټینرونو کې ، بیا په پاتې برخه کې؛
- کانري ریلیزونه - د بې نظمیو څارلو لپاره په محدود (کوچني) کانټینرونو کې د نوي عکس پیل کول.
څرنګه چې دوامداره تحویلي نه یوازې د نوې نسخې خوشې کول دي ، نو کوبرنیټس د راتلونکي زیربنا ساتنې لپاره یو شمیر وړتیاوې لري: د ټولو کانټینرونو لپاره جوړ شوی نظارت او ننوتل ، اتوماتیک پیمانه کول ، او داسې نور ستاسو په پروسو کې پلي کول.
وروستنۍ سپارښتنې
- Docker وکاروئ.
- ستاسو د ټولو اړتیاو لپاره د غوښتنلیکونو ډاکر عکسونه جوړ کړئ.
- اصول تعقیب کړئ "بنسټیز کوډ دی."
- ګیټ ډاکر ته لینک کړئ.
- د رول آوټ ترتیب تنظیم کړئ.
- د چمتو شوي پلیټ فارم څخه کار واخلئ (Kubernetes یا بل).
ویډیوګانې او سلایډونه
د فعالیت څخه ویډیو (شاوخوا یو ساعت) (رپوټ پخپله د 5 دقیقې څخه پیل کیږي - د دې شیبې څخه د لوبې کولو لپاره لینک تعقیب کړئ).
د راپور وړاندې کول:
PS
زموږ په بلاګ کې د موضوع په اړه نور راپورونه:
- «» (دیمیتري سټولیاروف؛ د می 27، 2019 په DevOpsConf کې);
- «» (دیمیتري سټولیاروف؛ د نومبر 8، 2018 په HighLoad++);
- «» (دیمیتري سټولیاروف؛ د نومبر 7، 2017 په HighLoad++);
- «» (دیمیتري سټولیاروف؛ د جون 6، 2017 په RootConf کې).
سرچینه: www.habr.com