زه وړاندیز کوم چې تاسو د انوینټوس څخه د الیګزانډر سیګاچیف لخوا د راپور لیږد ولولئ "د ډاکر + ګیټلاب CI سره پراختیا او ازموینې پروسې"
هغه څوک چې یوازې د Docker + Gitlab CI پراساس د پراختیا او ازموینې پروسې پلي کولو پیل کوي ډیری وختونه لومړني پوښتنې کوي. له کومه ځایه پیل کړو؟ څنګه تنظیم کول؟ څنګه ازموینه وکړو؟
دا راپور ښه دی ځکه چې دا د Docker او Gitlab CI په کارولو سره د پراختیا او ازموینې پروسې په اړه په منظم ډول خبرې کوي. راپور پخپله د 2017 څخه دی. زه فکر کوم چې د دې راپور څخه تاسو کولی شئ اساسات، میتودولوژي، مفکوره، او د کارولو تجربه راټول کړئ.
د هر چا لپاره چې علاقه لري ، مهرباني وکړئ بلی وګورئ.
زما نوم الکساندر سیګاچیف دی. زه د Inventos لپاره کار کوم. زه به تاسو ته د ډاکر کارولو زما تجربې په اړه ووایم او دا چې څنګه موږ په تدریجي ډول دا په شرکت کې په پروژو پلي کوو.
د راپور موضوع: د Docker او Gitlab CI په کارولو سره د پراختیا پروسه.
دا د ډاکر په اړه زما دویمه خبرې دي. د لومړي راپور په وخت کې ، موږ ډاکر یوازې د پراختیا کونکي ماشینونو په پراختیا کې کارولی. د کارمندانو شمیر چې ډاکر یې کارولی شاوخوا 2-3 کسان وو. په تدریج سره، تجربه ترلاسه شوه او موږ یو څه نور حرکت وکړ. زموږ سره لینک .
په دې راپور کې به څه وي؟ موږ به خپلې تجربې شریکې کړو چې موږ کوم ریکونه راټول کړل، کومې ستونزې مو حل کړې. دا هر ځای ښکلی نه و، مګر دا موږ ته اجازه راکړه چې حرکت وکړو.
زموږ شعار: هر هغه څه چې موږ یې لاس ته راوړو ډک کړئ.
موږ کومې ستونزې حل کوو؟
کله چې یو شرکت څو ټیمونه ولري، پروګرامر یوه شریکه سرچینه ده. داسې مرحلې شتون لري کله چې یو پروګرامر د یوې پروژې څخه ایستل کیږي او د یو څه وخت لپاره بلې پروژې ته ورکول کیږي.
د دې لپاره چې یو پروګرامر ژر تر ژره پوه شي، هغه اړتیا لري چې د پروژې سرچینې کوډ ډاونلوډ کړي او ژر تر ژره یو چاپیریال پیل کړي، کوم چې هغه ته اجازه ورکوي چې د دې پروژې ستونزې حل کولو کې نور پرمختګ وکړي.
عموما، که تاسو له پیل څخه پیل کوئ، په پروژه کې لږ اسناد شتون لري. یوازې زاړه وختونه د دې تنظیم کولو څرنګوالي په اړه معلومات لري. کارمندان په یوه یا دوه ورځو کې خپل کاري ځای پخپله تنظیموي. د دې ګړندي کولو لپاره ، موږ ډاکر کارولی.
بل دلیل په پراختیا کې د ترتیباتو معیاري کول دي. زما په تجربه کې، پراختیا کونکي تل نوښت کوي. په هر پنځم حالت کې، یو دودیز ډومین داخلیږي، د بیلګې په توګه vasya.dev. زما تر څنګ ناست زما ګاونډی پیټیا دی، چې ډومین یې petya.dev دی. دوی د دې ډومین نوم په کارولو سره ویب پاڼه یا ځینې سیسټم برخې رامینځته کوي.
کله چې سیسټم وده کوي او دا ډومین نومونه په ترتیب کې شاملول پیل کوي، د پراختیا چاپیریال کې شخړه رامینځته کیږي او د سایټ لاره بیا لیکل کیږي.
ورته شی د ډیټابیس ترتیباتو سره پیښیږي. ځینې خلک د امنیت سره اندیښنه نه کوي او د خالي روټ پاسورډ سره کار کوي. د نصبولو په مرحله کې، مای ایس کیو ایل له چا څخه د پاسورډ غوښتنه وکړه او پاسورډ 123 وګرځید. ډیری وختونه داسې پیښیږي چې د ډیټابیس ترتیب په دوامداره توګه د پراختیا کونکي ژمنې پورې اړه لري. چا تصحیح کړه، چا یې تشکیل سم نه کړ. دلته چلونه شتون درلود کله چې موږ د ازموینې ځینې ترتیبونه دننه کړل .gitignore او هر پرمخ وړونکي باید ډیټابیس نصب کړي. دا د پیل پروسه نوره هم ستونزمنه کړه. د نورو شیانو په منځ کې، تاسو باید د ډیټابیس په اړه یاد وساتئ. ډیټابیس باید پیل شي، یو پټنوم باید ثبت شي، یو کاروونکي باید راجستر شي، نښه باید رامینځته شي، او داسې نور.
بله ستونزه د کتابتونونو مختلف نسخې دي. دا ډیری وختونه پیښیږي چې یو پراختیا کونکي په بیلابیلو پروژو کار کوي. د میراث پروژه ده، چې پنځه کاله وړاندې پیل شوې (د 2017 څخه - د مدیر یادښت). په پیل کې موږ د MySQL 5.5 سره پیل کړ. دلته عصري پروژې هم شتون لري چیرې چې موږ هڅه کوو د MySQL نورې عصري نسخې پلي کړو، د بیلګې په توګه 5.7 یا زاړه (په 2017 کې - د مدیر یادونه)
هرڅوک چې د MySQL سره کار کوي پوهیږي چې دا کتابتونونه انحصار لري. د 2 ډیټابیسونو یوځای چلول خورا ستونزمن دي. لږترلږه، دا ستونزمنه ده چې زاړه پیرودونکي نوي ډیټابیس سره وصل کړئ. دا په خپل وار سره د څو ستونزو لامل ګرځي.
بله ستونزه دا ده کله چې یو پرمخ وړونکی په محلي ماشین کار کوي، هغه محلي سرچینې، محلي فایلونه، محلي رام کاروي. د ستونزو د حل په وخت کې ټول تعامل د دې حقیقت په چوکاټ کې ترسره کیږي چې دا په یوه ماشین کې کار کوي. یو مثال به هغه وخت وي کله چې موږ په تولید 3 کې بیک انډ سرورونه ولرو، او پراختیا کونکی فایلونه روټ ډایرکټر ته خوندي کوي او له هغه ځایه nginx غوښتنې ته د ځواب ویلو لپاره فایلونه اخلي. کله چې دا ډول کوډ تولید ته ورسیږي، نو دا معلومه شوه چې فایل په 3 سرورونو کې شتون لري.
د مایکرو خدماتو لار اوس مهال وده کوي. کله چې موږ خپل لوی غوښتنلیکونه په ځینو کوچنیو برخو ویشو چې یو له بل سره اړیکه لري. دا تاسو ته اجازه درکوي د ځانګړي کاري سټیک لپاره ټیکنالوژي غوره کړئ. دا تاسو ته اجازه درکوي د پراختیا کونکو تر مینځ د کار او مسؤلیت ساحه تقسیم کړئ.
د فرنټ اینډ پراختیا کونکی، په JS کې وده کوي، په حقیقت کې په پس منظر کې هیڅ اغیزه نلري. د بیک انډ پراختیا کونکی ، په بدل کې ، زموږ په قضیه کې ، روبی آن ریلونو ته وده ورکوي او د فرنډینډ سره مداخله نه کوي. تعامل د API په کارولو سره ترسره کیږي.
د بونس په توګه ، د ډاکر په کارولو سره موږ وکولی شو په سټیجینګ کې سرچینې ریسایکل کړو. هره پروژه، د هغې د ځانګړتیاوو له امله، ځینې ترتیباتو ته اړتیا لري. په فزیکي توګه، دا اړینه وه چې یا یو مجازی سرور تخصیص کړي او دوی په جلا توګه ترتیب کړي، یا یو ډول متغیر چاپیریال ویش او پروژې کولی شي یو بل اغیزه وکړي، د کتابتونونو نسخه پورې اړه لري.
وسیلې. موږ څه کاروو؟
- پخپله ډاکر. A Dockerfile د یو واحد غوښتنلیک انحصار بیانوي.
- د ډاکر-کمپوز یو بنډل دی چې زموږ ډیری ډاکر غوښتنلیکونه یوځای راوړي.
- موږ د سرچینې کوډ ذخیره کولو لپاره GitLab کاروو.
- موږ د سیسټم ادغام لپاره GitLab-CI کاروو.
راپور له دوو برخو جوړ دی.
لومړۍ برخه به تاسو ته ووایي چې څنګه د پراختیا کونکو ماشینونو کې ډاکر چلوي.
دویمه برخه به د ګیټ لیب سره د متقابل عمل څرنګوالي په اړه وغږیږي ، موږ څنګه ازموینې پرمخ وړو او څنګه سټیګینګ ته راوځو.
ډاکر یوه ټیکنالوژي ده چې اجازه ورکوي (د اعلاناتي طریقې په کارولو سره) اړین برخې تشریح کړي. دا یو مثال دی Dockerfile. دلته موږ اعلان کوو چې موږ د روبي رسمي ډاکر عکس څخه په میراث اخلو: 2.3.0. دا د روبي نسخه 2.3 نصب لري. موږ اړین مجلس کتابتونونه او نوډ جے ایس نصب کوو. موږ تشریح کوو چې موږ یو لارښود جوړوو /app. موږ د ایپ لارښود د کاري لارښود په توګه ګمارو. پدې لارښود کې موږ اړین لږترلږه Gemfile او Gemfile.lock ځای په ځای کوو. بیا موږ هغه پروژې رامینځته کوو چې دا انحصاري عکس نصبوي. موږ په ډاګه کوو چې کانټینر به په بهرني بندر 3000 کې اوریدلو ته چمتو وي. وروستی کمانډ هغه کمانډ دی چې مستقیم زموږ غوښتنلیک پیلوي. که موږ د پروژې چلولو کمانډ اجرا کړو، نو غوښتنلیک به هڅه وکړي چې ټاکل شوي کمانډ چل او چل کړي.
دا د ډاکر - کمپوز فایل لږترلږه مثال دی. په دې حالت کې، موږ وښیو چې د دوو کانټینرونو ترمنځ اړیکه شتون لري. دا په مستقیم ډول د ډیټابیس خدمت او ویب خدمت کې دی. زموږ ویب غوښتنلیکونه په ډیری قضیو کې د ډیټا ذخیره کولو لپاره یو ډول ډیټابیس ته اړتیا لري. څرنګه چې موږ MySQL کاروو، مثال یې د MySQL سره دی - مګر هیڅ شی موږ د نورو ډیټابیس کارولو مخه نه نیسي (PostgreSQL، Redis).
موږ د ډاکر مرکز څخه د رسمي سرچینې څخه بدلون پرته د MySQL 5.7.14 عکس اخلو. موږ هغه عکس راټولوو چې زموږ د ویب غوښتنلیک لپاره مسؤل دی له اوسني لارښود څخه. د لومړي لانچ په جریان کې ، هغه زموږ لپاره یو عکس راټولوي. بیا دا هغه قومانده پرمخ وړي چې موږ یې دلته اجرا کوو. که موږ بیرته لاړ شو، موږ به وګورو چې د لانچ قومانده د پوما له لارې تعریف شوې وه. پوما یو خدمت دی چې په روبي کې لیکل شوی. په دویمه قضیه کې موږ بیرته راګرځوو. دا قومانده زموږ د اړتیاو یا دندو پورې اړه لري په خپل سر وي.
موږ دا هم تشریح کوو چې موږ اړتیا لرو بندر زموږ د پراختیا کونکي کوربه ماشین کې له 3000 څخه تر 3000 کانټینر بندر ته واستوو. دا په اوتومات ډول د iptables او د دې خپل میکانیزم په کارولو سره ترسره کیږي ، کوم چې په مستقیم ډول په ډاکر کې ځای په ځای شوی.
پرمخ وړونکی کولی شي د پخوا په څیر هر ډول موجود IP پتې ته لاسرسی ومومي، د بیلګې په توګه، د ماشین 127.0.0.1 محلي یا بهرنی IP پته.
وروستۍ کرښه وايي چې ویب کانټینر د db کانټینر پورې اړه لري. کله چې موږ د پیل کولو لپاره ویب کانټینر ته زنګ ووهو، ډاکر-کمپوز به لومړی زموږ لپاره ډیټابیس پیل کړي. دمخه د ډیټابیس په پیل کې (په حقیقت کې ، د کانټینر له پیل وروسته! دا د ډیټابیس چمتووالي تضمین نه کوي) دا به زموږ غوښتنلیک ، زموږ شاته پیل کړي.
دا موږ ته اجازه راکوي چې د غلطیو څخه مخنیوی وکړو کله چې ډیټابیس نه وي او موږ ته اجازه راکوي چې سرچینې خوندي کړو کله چې موږ د ډیټابیس کانټینر ودروو، په دې توګه د نورو پروژو لپاره سرچینې خالي کوو.
په پروژه کې د ډیټابیس ډاکر کولو کارول موږ ته څه راکوي؟ موږ د ټولو پراختیا کونکو لپاره د MySQL نسخه ثبت کوو. دا تاسو ته اجازه درکوي د ځینو غلطیو څخه مخنیوی وکړئ چې ممکن واقع شي کله چې نسخې توپیر وکړي، کله چې نحو، ترتیب، او ډیفالټ ترتیبات بدل شي. دا تاسو ته اجازه درکوي چې د ډیټابیس، ننوتلو، پټنوم لپاره یو عام کوربه نوم مشخص کړئ. موږ په ترتیب فایلونو کې د نومونو او شخړو له زو څخه لیرې یو چې مخکې شتون درلود.
موږ فرصت لرو چې د پرمختیایي چاپیریال لپاره ډیر غوره ترتیب وکاروو، کوم چې به د ډیفالټ څخه توپیر ولري. MySQL د ضعیف ماشینونو لپاره په ډیفالټ ترتیب شوی او د بکس څخه بهر یې فعالیت خورا ټیټ دی.
ډاکر تاسو ته اجازه درکوي د مطلوب نسخه پایتون ، روبي ، نوډ جے ایس ، پی ایچ پی ترجمان وکاروئ. موږ د یو ډول نسخه مدیر کارولو اړتیا لرې کوو. مخکې، د روبي لپاره د rpm کڅوړه کارول کیده، کوم چې تاسو ته اجازه درکوي چې د پروژې پر بنسټ نسخه بدله کړئ. د ډاکر کانټینر څخه مننه ، دا تاسو ته اجازه درکوي په اسانۍ سره کوډ مهاجر کړئ او د انحصار سره یې نسخه کړئ. موږ د ژباړونکي او کوډ دواړو نسخو په پوهیدو کې کومه ستونزه نلرو. د نسخې تازه کولو لپاره، تاسو اړتیا لرئ چې زاړه کانټینر ټیټ کړئ او نوی کانټینر پورته کړئ. که یو څه غلط شي، موږ کولی شو نوی کانټینر ښکته کړو، زاړه کانټینر پورته کړو.
د عکس د جوړولو وروسته، د پراختیا او تولید دواړه کانتینرونه به ورته وي. دا په ځانګړې توګه د لویو تاسیساتو لپاره ریښتیا ده.
په Frontend کې موږ JavaScipt او NodeJS کاروو.
اوس موږ په ReacJS کې زموږ وروستۍ پروژه لرو. پراختیا کونکي هرڅه په کانټینر کې پیل کړل او د ګرم ریلوډ په کارولو سره یې وده وکړه.
بیا، د جاواسکپټ د راټولولو دنده پیل شوې او په ثابت ډول راټول شوي کوډ د نګینکس له لارې لیږل کیږي، سرچینې خوندي کوي.
دلته ما زموږ د وروستي پروژې ډیاګرام چمتو کړی دی.
کومې ستونزې مو حل کړې؟ موږ د داسې سیسټم جوړولو ته اړتیا درلوده چې د ګرځنده وسیلو سره اړیکه ونیسي. دوی معلومات ترلاسه کوي. یو له امکاناتو څخه دا دی چې دې وسیلې ته د فشار خبرتیاوې لیږل کیږي.
موږ د دې لپاره څه کړي دي؟
موږ غوښتنلیک په لاندې برخو ویشلی: په JS کې د اډمین برخه، یو بیکینډ چې د REST انٹرفیس له لارې د روبي آن ریلز لاندې کار کوي. بیک اینډ د ډیټابیس سره اړیکه لري. هغه پایله چې تولید کیږي پیرودونکي ته ورکول کیږي. اډمین پینل د REST انٹرفیس له لارې د شالید او ډیټابیس سره تعامل کوي.
موږ د پش خبرتیاو لیږلو ته هم اړتیا درلوده. مخکې له دې، موږ یوه پروژه درلوده په کوم کې چې یو میکانیزم پلي شوی و چې د ګرځنده پلیټ فارمونو ته د خبرتیاو رسولو مسولیت درلود.
موږ لاندې سکیم رامینځته کړی: د براوزر څخه آپریټر د اډمین پینل سره تعامل کوي ، د اډمین پینل د شاته سره تعامل کوي ، دنده د پش خبرتیاو لیږل دي.
د فشار خبرتیاوې د بلې برخې سره اړیکه لري چې په NodeJS کې پلي کیږي.
کتارونه جوړ شوي او خبرتیاوې د خپل میکانیزم سره سم لیږل کیږي.
دلته دوه ډیټابیسونه جوړ شوي دي. اوس مهال ، د ډاکر په کارولو سره ، موږ 2 خپلواک ډیټابیسونه کاروو چې په هیڅ ډول یو له بل سره تړلي ندي. د دې حقیقت سربیره چې دوی یو عام مجازی شبکه لري، او فزیکي معلومات د پراختیا کونکي ماشین کې په مختلفو لارښوونو کې زیرمه شوي.
ورته شی مګر په شمیر کې. د کوډ بیا کارول دلته مهم دي.
که مخکې موږ د کتابتونونو په بڼه د کوډ د بیا کارولو په اړه خبرې وکړې، نو پدې مثال کې زموږ خدمت، چې د Push خبرتیاو ته ځواب ورکوي، د بشپړ سرور په توګه بیا کارول کیږي. دا یو API وړاندې کوي. او زموږ نوی پرمختګ ورسره اړیکه لري.
په هغه وخت کې موږ د نوډ جے ایس 4 نسخه کاروو. اوس (په 2017 کې - د مدیر یادښت) زموږ په وروستي پرمختګونو کې موږ د نوډ جے ایس 7 نسخه کاروو. د کتابتونونو نوې نسخې شاملولو لپاره په نوي برخو کې کومه ستونزه نشته.
که اړتیا وي، تاسو کولی شئ د Push خبرتیا خدمت NodeJS نسخه بیاکتنه او پورته کړئ.
او که موږ د API مطابقت ساتلی شو، نو دا به ممکنه وي چې دا د نورو پروژو سره بدله کړو چې مخکې کارول شوي.
تاسو د ډاکر اضافه کولو لپاره څه ته اړتیا لرئ؟ موږ زموږ ذخیره کې ډاکر فایل اضافه کوو ، کوم چې اړین انحصار بیانوي. په دې مثال کې، اجزا په منطقي ډول ویشل شوي. دا د بیک انډ پراختیا کونکي لپاره لږترلږه کټ دی.
کله چې یوه نوې پروژه رامینځته کړئ ، موږ یو ډاکر فایل رامینځته کوو او اړین ایکوسیستم تشریح کوو (Python, Ruby, NodeJS). په ډاکر - کمپوز کې، دا اړین انحصار بیانوي - ډیټابیس. موږ تشریح کوو چې موږ د داسې او داسې نسخو ډیټابیس ته اړتیا لرو، ترڅو هلته او هلته ډاټا ذخیره کړو.
موږ د جامد مینځپانګې خدمت کولو لپاره د نګینکس سره جلا دریم کانټینر کاروو. دا ممکنه ده چې انځورونه پورته کړئ. پس منظر دوی له مخکې چمتو شوي حجم کې اچوي، کوم چې د نګینکس سره په کانټینر کې هم نصب شوی، کوم چې جامد ډاټا چمتو کوي.
د nginx او mysql تشکیلاتو ذخیره کولو لپاره ، موږ د ډاکر فولډر اضافه کړ په کوم کې چې موږ اړین تشکیلات ذخیره کوو. کله چې یو پراختیا کونکی په خپل ماشین کې د ذخیره کولو ګیټ کلون رامینځته کوي ، هغه دمخه د ځایی پراختیا لپاره یوه پروژه چمتو کړې. پدې اړه هیڅ پوښتنه نشته چې کوم بندر یا کوم تنظیمات پلي کیږي.
بیا موږ ډیری برخې لرو: اډمین، معلومات-API، خبرتیاوې.
د دې ټولو په لاره اچولو لپاره، موږ یو بل ذخیره جوړه کړه چې نوم یې د dockerized-app. موږ اوس مهال د هرې برخې لپاره ډیری ذخیره کاروو. دوی په ساده ډول په منطقي ډول توپیر لري - په GitLab کې دا د فولډر په څیر ښکاري، مګر د پراختیا کونکي ماشین کې دا د یوې ځانګړې پروژې لپاره د فولډر په څیر ښکاري. لاندې یوه کچه هغه برخې دي چې یوځای کیږي.
دا د dockerized-app د مینځپانګې یوه بیلګه ده. موږ دلته د ډاکر لارښود هم ځای په ځای کوو ، په کوم کې چې موږ د ټولو برخو تعاملاتو لپاره اړین تشکیلات ډکوو. یو README.md شتون لري چې په لنډ ډول تشریح کوي چې څنګه پروژه پیل کړئ.
دلته موږ دوه ډاکر کمپوز فایلونه پلي کړي دي. دا د دې لپاره ترسره کیږي چې په مرحلو کې پیل شي. کله چې یو پراختیا کونکی د کرنل سره کار کوي ، نو هغه د پش خبرتیاو ته اړتیا نلري ، هغه په ساده ډول د ډاکر - کمپوز فایل پیلوي او په وینا یې سرچینې خوندي کیږي.
که چیرې د پش خبرتیاو سره ادغام ته اړتیا وي ، نو بیا docker-compose.yaml او docker-compose-push.yaml پیل کیږي.
څرنګه چې docker-compose.yaml او docker-compose-push.yaml په فولډر کې دي، یو واحد مجازی شبکه په اوتومات ډول رامینځته کیږي.
د اجزاوو تفصیل. دا یو ډیر پرمختللی فایل دی چې د اجزاوو راټولولو مسولیت لري. دلته څه د پام وړ دي؟ دلته موږ د توازن برخه معرفي کوو.
دا د چمتو شوي ډاکر عکس دی چې نګینکس چلوي او یو غوښتنلیک چې د ډاکر ساکټ ته غوږ نیسي. متحرک، لکه څنګه چې کانټینرونه فعال او بند شوي، د نګینکس ترتیب بیا تولید شوی. موږ د دریمې کچې ډومین نومونو په کارولو سره د اجزاو اداره کول توزیع کوو.
د پرمختیایي چاپیریال لپاره موږ د .dev ډومین - api.informer.dev کاروو. د .dev ډومین سره غوښتنلیکونه د پراختیا کونکي محلي ماشین کې شتون لري.
بیا ترتیبونه هرې پروژې ته لیږدول کیږي او ټولې پروژې په ورته وخت کې پیل کیږي.
که موږ دا په ګرافیک ډول انځور کړو، نو دا معلومه شوه چې پیرودونکي زموږ براوزر یا یو ډول وسیله ده چې موږ یې د بیلانس لپاره غوښتنه کوو.
بیلانس ټاکي چې کوم کانټینر ته د ډومین نوم پراساس لاسرسی ته اړتیا ده.
دا کیدای شي نګینکس وي، کوم چې د اډمین پینل ته JS چمتو کوي. دا د nginx لخوا ترسره کیدی شي، کوم چې API، یا جامد فایلونه چمتو کوي، کوم چې د nginx لخوا د انځورونو د پورته کولو په بڼه چمتو شوي.
ډیاګرام ښیې چې کانټینرونه د مجازی شبکې سره وصل دي او د پراکسي تر شا پټ دي.
د پراختیا کونکي ماشین کې، تاسو کولی شئ د IP په پوهیدو سره کانټینر ته لاسرسی ومومئ، مګر په اصولو کې موږ دا نه کاروو. په عملي توګه مستقیم تماس ته اړتیا نشته.
زما د غوښتنلیک ډکولو لپاره باید کوم مثال وګورم؟ زما په اند، یو ښه مثال د MySQL لپاره رسمي ډاکر عکس دی.
دا خورا پیچلې ده. ډیری نسخې شتون لري. مګر د دې فعالیت تاسو ته اجازه درکوي ډیری اړتیاوې پوښي چې ممکن د نور پرمختګ په پروسه کې رامینځته شي. که تاسو وخت ونیسئ او پوه شئ چې دا ټول څنګه تعامل کوي، نو زه فکر کوم چې تاسو به د دې پخپله پلي کولو کې کومه ستونزه ونه لرئ.
Hub.docker.com معمولا د github.com سره لینکونه لري ، چیرې چې خام ډیټا مستقیم چمتو کیږي چې تاسو کولی شئ پخپله عکس جوړ کړئ.
نور په دې ذخیره کې یو سکریپټ docker-endpoint.sh شتون لري، کوم چې د غوښتنلیک د پیل کولو د پیل کولو او نور پروسس کولو مسولیت لري.
همدارنګه پدې مثال کې د چاپیریال متغیرونو په کارولو سره د ترتیب کولو امکان شتون لري. د چاپیریال متغیر تعریف کولو سره کله چې یو واحد کانټینر چلول یا د ډاکر - کمپوز له لارې ، موږ کولی شو ووایو چې موږ اړتیا لرو په MySQL کې د روټ لپاره د ډاکر لپاره خالي پاسورډ تنظیم کړو یا هر هغه څه چې موږ یې غواړو.
د تصادفي رمز جوړولو لپاره یو اختیار شتون لري. موږ وایو چې موږ یو کارونکي ته اړتیا لرو، موږ اړتیا لرو چې د کارونکي لپاره پاسورډ تنظیم کړو، او موږ اړتیا لرو چې یو ډیټابیس جوړ کړو.
زموږ په پروژو کې، موږ د ډاکر فایل یو څه متحد کړی، کوم چې د پیل کولو مسولیت لري. هلته موږ دا زموږ اړتیاو سره تنظیم کړی ترڅو په ساده ډول د کارونکي حقونه پراخه کړي چې غوښتنلیک یې کاروي. دې دا ممکنه کړه چې په راتلونکي کې د غوښتنلیک کنسول څخه په ساده ډول ډیټابیس رامینځته کړي. د روبي غوښتنلیکونه د ډیټابیسونو رامینځته کولو ، بدلولو او حذف کولو امرونه لري.
دا یوه بیلګه ده چې د مای ایس کیو ایل ځانګړی نسخه په github.com کې څه ښکاري. تاسو کولی شئ د ډاکر فایل خلاص کړئ او وګورئ چې هلته نصب څنګه ترسره کیږي.
docker-endpoint.sh سکریپټ د ننوتلو نقطې لپاره مسؤل دی. د پیل کولو په جریان کې، د چمتو کولو ځینې کړنو ته اړتیا ده او دا ټولې کړنې د پیل کولو سکریپټ کې شاملې دي.
راځئ چې دویمې برخې ته لاړ شو.
موږ د سرچینې کوډونو ذخیره کولو لپاره ګیټلاب ته لاړو. دا یو کافي ځواکمن سیسټم دی چې بصری انٹرفیس لري.
د Gitlab اجزاو څخه یو د Gitlab CI دی. دا تاسو ته اجازه درکوي یو لړ حکمونه تشریح کړئ چې وروسته به د کوډ تحویلي سیسټم تنظیم کولو یا د اتوماتیک ازموینې پرمخ وړلو لپاره وکارول شي.
د Gitlab CI 2 په اړه راپور - د روبي روسیه کلب راپور خورا مفصل دی او ممکن ستاسو لپاره علاقه ولري.
اوس موږ به وګورو چې د ګیتلاب CI فعالولو لپاره څه ته اړتیا ده. د Gitlab CI په لاره اچولو لپاره، موږ یوازې د پروژې په ریښه کې د gitlab-ci.yml فایل کېښودو ته اړتیا لرو.
دلته موږ تشریح کوو چې موږ غواړو د ریاستونو لړۍ ترسره کړو لکه ازموینه، ځای پرځای کول.
موږ هغه سکریپټونه اجرا کوو چې په مستقیم ډول زموږ د غوښتنلیک ډاکر - کمپوز جوړونې ته زنګ ووهي. دا یوازې د پس منظر یوه بیلګه ده.
بیا موږ وایو چې د ډیټابیس بدلولو او ازموینې پرمخ وړلو لپاره د مهاجرت چلولو ته اړتیا ده.
که سکریپټونه په سمه توګه اجرا شوي وي او د خطا کوډ بیرته نه راولي، نو سیسټم د ځای پرځای کولو دویم پړاو ته ځي.
د ګمارنې مرحله اوس مهال د سټینګ لپاره پلي کیږي. موږ د بې ځنډه وخت بیا پیل تنظیم نه کړ.
موږ په زور سره ټول کانټینرونه اورو، او بیا موږ ټول کانټینرونه بیا پورته کوو، د ازموینې په جریان کې په لومړي مرحله کې راټول شوي.
راځئ چې د ډیټابیس مهاجرتونه پرمخ یوسو چې د اوسني متغیر چاپیریال لپاره د پراختیا کونکو لخوا لیکل شوي.
یو یادونه شتون لري چې دا باید یوازې په ماسټر څانګه کې پلي شي.
د نورو څانګو بدلولو په وخت کې کار نه کوي.
دا ممکنه ده چې د څانګو په اوږدو کې رولونه تنظیم کړئ.
د دې نور تنظیم کولو لپاره ، موږ اړتیا لرو د ګیټلاب رنر نصب کړو.
دا افادیت په ګولنګ لیکل شوی. دا یو واحد فایل دی لکه څنګه چې د ګولنګ نړۍ کې عام دی، کوم چې کوم انحصار ته اړتیا نلري.
په پیل کې موږ د ګیټلاب رنر راجستر کوو.
موږ د ګیټلاب ویب انٹرفیس کې کیلي ترلاسه کوو.
بیا موږ د کمانډ لاین کې د ابتدایی کمانډ غږ کوو.
د ډیالوګ حالت کې د ګیټلاب رنر تنظیم کول (شیل، ډاکر، ورچوئل بکس، SSH)
د ګیټلاب رنر کوډ به د .gitlab-ci.yml ترتیب پورې اړوند په هر ژمنې اجرا شي.
دا څنګه په ویب انٹرفیس کې ګیټلاب کې په لید کې ښکاري. د GItlab CI سره وصل کیدو وروسته ، موږ یو بیرغ لرو چې ښیې دا مهال جوړ په کوم حالت کې دی.
موږ ګورو چې 4 دقیقې دمخه یوه ژمنه شوې وه چې ټولې ازموینې یې پاس کړې او هیڅ ستونزه یې نه رامینځته کړې.
موږ کولی شو جوړونه په ډیر تفصیل سره وګورو. دلته موږ ګورو چې دوه دولتونه دمخه تیر شوي دي. په مرحله کې د ازموینې وضعیت او د ګمارنې حالت.
که موږ په یو ځانګړي جوړ باندې کلیک وکړو، نو د کمانډونو کنسول محصول به وي چې د gitlab-ci.yml مطابق په پروسه کې پیل شوي.
دا هغه څه دي چې زموږ د محصول کیسه ورته ښکاري. موږ ګورو چې بریالي هڅې شوي دي. کله چې ازموینې وسپارل شي، دوی بل ګام ته نه ځي او د سټینګ کوډ تازه شوی نه دی.
کله چې موږ ډاکر پلي کړو په مرحله کې موږ کومې ستونزې حل کړې؟ زموږ سیسټم د اجزاو څخه جوړ دی او موږ اړتیا درلوده چې یوازې ځینې برخې بیا پیل کړو چې په ذخیره کې تازه شوي، نه ټول سیسټم.
د دې کولو لپاره، موږ باید هرڅه په جلا فولډرونو کې جلا کړو.
وروسته لدې چې موږ دا وکړل ، موږ د دې حقیقت سره ستونزه درلوده چې ډاکر - کمپوز د هر فولډر لپاره خپل د شبکې ځای رامینځته کوي او د خپل ګاونډي اجزا نه ګوري.
د شاوخوا کیدو لپاره ، موږ شبکه په لاسي ډول په ډاکر کې رامینځته کړه. په ډاکر کمپوز کې دا لیکل شوي چې تاسو باید د دې پروژې لپاره دا ډول شبکه وکاروئ.
په دې توګه، هره برخه چې د دې میش سره پیل کیږي د سیسټم په نورو برخو کې اجزا ګوري.
بله ستونزه د څو پروژو تر منځ د پړاو ویش دی.
د دې لپاره چې دا ټول ښکلي ښکاري او د امکان تر حده تولید ته نږدې وي ، نو دا ښه ده چې د 80 یا 443 پورټ وکاروئ ، کوم چې په ویب کې هرچیرې کارول کیږي.
موږ دا څنګه حل کړو؟ موږ ټولو لویو پروژو ته یو ګیټلاب رنر ګمارلی.
ګیټلاب تاسو ته اجازه درکوي څو توزیع شوي ګیټلاب چلونکي په لاره واچوي ، کوم چې به په ساده ډول ټولې دندې یو په بل پسې په ګډوډي ترتیب کې ترسره کړي او پرمخ بوځي.
د کور ستونزو څخه مخنیوي لپاره ، موږ د خپلو پروژو ګروپ یو ګیټلاب رنر ته محدود کړ ، کوم چې پرته له ستونزو زموږ حجمونو سره مقابله کوي.
موږ nginx-proxy په جلا لانچ سکریپټ کې حرکت وکړ او د ټولو پروژو ګریډونه یې په کې لیکلي.
زموږ پروژه یو گرډ لري، او بیلانسر د پروژې نومونو پراساس څو گرډونه لري. دا د ډومین نومونو لخوا نور پراکسي کولی شي.
زموږ غوښتنې په پورټ 80 کې د ډومین له لارې راځي او د کانټینرونو یوې ډلې ته حل کیږي چې دې ډومین ته خدمت کوي.
نورې کومې ستونزې وې؟ دا هغه څه دي چې ټول کانټینرونه د ډیفالټ په واسطه د روټ په توګه پرمخ ځي. دا د سیسټم غیر مساوي ریښه کوربه ده.
په هرصورت، که تاسو کانټینر ته ننوځئ، دا به روټ وي او هغه فایل چې موږ په دې کانټینر کې جوړوو د روټ حقونه ترلاسه کوي.
که یو پرمخ وړونکي کانټینر ته ننوځي او هلته یې ځینې کمانډونه کړي چې فایلونه یې تولید کړي، بیا کانټینر پریږدي، نو د هغه په کاري لارښود کې هغه یو فایل لري چې هغه ته لاسرسی نلري.
دا څنګه حل کیدی شي؟ تاسو کولی شئ هغه کاروونکي اضافه کړئ چې په کانتینر کې وي.
کله چې موږ کاروونکي اضافه کړل کومې ستونزې رامینځته شوې؟
کله چې یو کارن جوړ کړئ، د ګروپ ID (UID) او د کاروونکي ID (GID) اکثرا سره سمون نه لري.
په کانټینر کې د دې ستونزې حل کولو لپاره موږ کاروونکي د ID 1000 سره کاروو.
زموږ په قضیه کې، دا د دې حقیقت سره سمون لري چې نږدې ټول پراختیا کونکي د اوبنټو OS کاروي. او په اوبنټو OS کې لومړی کارونکی ID 1000 لري.
ایا موږ پلانونه لرو؟
د ډاکر اسناد بیا ولولئ. پروژه په فعاله توګه وده کوي، اسناد بدلیږي. هغه معلومات چې دوه یا درې میاشتې مخکې ترلاسه شوي وو ورو ورو زاړه کیږي.
ځینې ستونزې چې موږ یې حل کړې ممکن دمخه د معیاري وسیلو لخوا حل شوي وي.
زه واقعیا غواړم حرکت وکړم او مستقیم آرکیسټریشن ته لاړ شم.
یوه بیلګه د Docker جوړ شوی میکانیزم دی چې د Docker Swarm په نوم یادیږي، کوم چې د بکس څخه بهر راځي. زه غواړم د ډاکر سوارم ټیکنالوژۍ پراساس په تولید کې یو څه پیل کړم.
د کانتینرونو سپون کول د لاګونو سره کار کول ناشونی کوي. اوس لاګونه جلا شوي دي. دوی په کانتینرونو کې ویشل شوي دي. یو له دندو څخه دا دی چې د ویب انٹرفیس له لارې لاګونو ته اسانه لاسرسی رامینځته کړي.
سرچینه: www.habr.com