werf - په Kubernetes کې د CI / CD لپاره زموږ وسیله (کتنې او ویډیو راپور)

د می په 27 د DevOpsConf 2019 کنفرانس په اصلي تالار کې ، د فستیوال د یوې برخې په توګه ترسره شو RIT++ 2019, د "دوامداره تحویلي" برخې برخې په توګه، یو راپور ورکړل شو "werf - زموږ وسیله په کوبرنیټس کې د CI/CD لپاره". دا د هغو په اړه خبرې کوي ستونزې او ننګونې چې هرڅوک ورسره مخ کیږي کله چې کبرنیټس ته ګمارل کیږي، او همدارنګه د باریکیو په اړه چې ممکن سمدلاسه د پام وړ نه وي. د ممکنه حلونو تحلیل، موږ وښیو چې دا څنګه د خلاصې سرچینې وسیلې کې پلي کیږي werf.

د پریزنټشن راهیسې، زموږ افادیت (پخوا د ډیپ په نوم پیژندل شوی) یو تاریخي پړاو ته رسیدلی په GitHub کې 1000 ستوري - موږ امید لرو چې د دې د کاروونکو وده کونکي ټولنه به د ډیری DevOps انجینرانو لپاره ژوند اسانه کړي.

نو، راځئ چې معرفي کړو د راپور ویډیو (~ 47 دقیقې، د مقالې په پرتله خورا ډیر معلوماتي) او د متن په بڼه یې اصلي استخراج. لاړ شه!

Kubernetes ته کوډ سپارل

خبرې به نور د werf په اړه نه وي، مګر په Kubernetes کې د CI/CD په اړه، پدې معنی چې زموږ سافټویر په ډاکر کانټینرونو کې بسته شوی (ما په دې اړه خبرې وکړې د 2016 راپور)، او K8s به په تولید کې د چلولو لپاره وکارول شي (په دې اړه نور معلومات په کې 2017 کال).

تحویلي په کبرنیټس کې څه ډول ښکاري؟

• د دې جوړولو لپاره د کوډ او لارښوونو سره د Git ذخیره شتون لري. غوښتنلیک د ډاکر عکس کې جوړ شوی او د ډاکر راجسټری کې خپور شوی.
• ورته ذخیره د غوښتنلیک د ځای پرځای کولو او چلولو څرنګوالي په اړه لارښوونې هم لري. د ګمارلو په مرحله کې، دا لارښوونې Kubernetes ته لیږل کیږي، کوم چې د راجستر څخه غوښتل شوي عکس ترلاسه کوي او په لاره اچوي.
• برسیره پردې، معمولا ازموینې شتون لري. ځینې ​​​​یې د عکس خپرولو په وخت کې ترسره کیدی شي. تاسو کولی شئ (د ورته لارښوونو په تعقیب) د غوښتنلیک یوه کاپي ځای په ځای کړئ (په جلا K8s نوم ځای یا جلا کلستر کې) او هلته ازموینې پرمخ وړئ.
• په نهایت کې ، تاسو د CI سیسټم ته اړتیا لرئ چې د Git څخه پیښې ترلاسه کوي (یا د تڼۍ کلیکونه) او ټول ټاکل شوي مرحلې غږوي: جوړول ، خپرول ، ځای په ځای کول ، ازموینه.

دلته یو څو مهم یادښتونه شتون لري:

1. ځکه چې موږ د بدلون وړ زیربنا لرو (د بدلون وړ زیربناوې)، د اپلیکیشن عکس چې په ټولو مرحلو کې کارول کیږي (مقام کول ، تولید ، او نور) ، هلته باید یو وي. ما په دې اړه په تفصیل او مثالونو سره خبرې وکړې. دلته.
2. ځکه چې موږ د کوډ طریقې په توګه زیربنا تعقیبوو (IAC)د غوښتنلیک کوډ، د راټولولو او پیل کولو لارښوونې باید وي دقیقا په یوه ذخیره کې. په دې اړه د نورو معلوماتو لپاره، وګورئ ورته راپور.
3. د سپارلو سلسله (تولید) موږ معمولا دا د دې په څیر ګورو: غوښتنلیک راټول شوی ، ازمول شوی ، خپور شوی (د خوشې کولو مرحله) او دا دی - تحویل شوی دی. مګر په حقیقت کې، کاروونکي هغه څه ترلاسه کوي چې تاسو یې راوباسئ، نه بیا کله چې تاسو تولید ته وسپارل او کله چې هغه وکولی شو هلته لاړ شي او دا تولید کار وکړي. نو زه باور لرم چې د تحویلي سلسله پای ته رسیږي یوازې په عملیاتي مرحله کې (چلول)، یا ډیر دقیق، حتی په هغه وخت کې چې کوډ د تولید څخه لیرې شوی و (د نوي سره یې ځای په ځای کول).

راځئ چې په کبرنیټس کې پورتني تحویلي سکیم ته راستون شو: دا نه یوازې زموږ لخوا اختراع شوی ، بلکه په حقیقت کې د هر چا لخوا چې له دې ستونزې سره معامله کوي. په حقیقت کې، دا نمونه اوس د GitOps په نوم یادیږي (تاسو کولی شئ د اصطلاح او د هغې تر شا د نظرونو په اړه نور ولولئ دلته). راځئ چې د سکیم مرحلې وګورو.

د جوړولو مرحله

داسې بریښي چې تاسو کولی شئ په 2019 کې د ډاکر عکسونو جوړولو په اړه وغږیږئ ، کله چې هرڅوک پوهیږي چې څنګه د ډاکر فایلونه ولیکئ او چل کړئ docker build؟.. دلته هغه لنډیزونه دي چې زه غواړم ورته پام وکړم:

1. د انځور وزن مهمه ده، نو کارول څو مرحلېپه عکس کې یوازې هغه غوښتنلیک پریږدئ چې واقعیا د عملیاتو لپاره اړین دی.
2. د پرتونو شمیر د زنځیرونو په یوځای کولو سره باید کم شي RUN- د معنی سره سم حکمونه.
3. په هرصورت، دا ستونزې زیاتوي ډیبګ کول، ځکه چې کله مجلس خرابیږي ، تاسو باید د زنځیر څخه سم کمانډ ومومئ چې ستونزه یې رامینځته کړې.
4. د مجلس سرعت مهم ځکه چې موږ غواړو ژر تر ژره بدلونونه راوباسئ او پایلې یې وګورو. د مثال په توګه، تاسو نه غواړئ هرکله چې تاسو غوښتنلیک جوړ کړئ د ژبې په کتابتونونو کې انحصار بیا جوړ کړئ.
5. ډیری وختونه د یو Git ذخیره څخه چې تاسو ورته اړتیا لرئ ډیری انځورونه، کوم چې د ډاکر فایلونو سیټ (یا په یوه فایل کې نومول شوي مرحلې) او د دوی ترتیب شوي مجلس سره د بش سکریپټ لخوا حل کیدی شي.

دا یوازې د یخ کندې یوه برخه وه چې هرڅوک ورسره مخ دي. مګر نورې ستونزې هم شتون لري، په ځانګړې توګه:

1. ډیری وختونه د مجلس په مرحله کې موږ یو څه ته اړتیا لرو mount (د مثال په توګه، د کمانډ پایله کیش کړئ لکه د دریمې ډلې لارښود کې apt).
2. موږ غواړو ناڅاپي په شیل کې د لیکلو پرځای.
3. موږ غواړو د ډاکر پرته جوړ کړئ (ولې موږ اضافي مجازی ماشین ته اړتیا لرو په کوم کې چې موږ د دې لپاره هرڅه تنظیم کولو ته اړتیا لرو ، کله چې موږ دمخه د کوبرنیټس کلستر لرو چې پکې موږ کانټینر چلولی شو؟).
4. موازي مجلس، کوم چې په بیلابیلو لارو پوهیدل کیدی شي: د ډاکر فایل څخه مختلف کمانډونه (که څو مرحلې کارول کیږي) ، د ورته ذخیره څو ژمنې ، څو ډاکر فایلونه.
5. ویشل شوی مجلس: موږ غواړو هغه شیان په پوډونو کې راټول کړو چې "لنډ مهاله" دي ځکه د دوی زیرمه ورکیږي ، پدې معنی چې دا باید په جلا توګه زیرمه شي.
6. په نهایت کې ، ما د هیلو پای ته نوم ورکړ اتوماتیک: دا به غوره وي چې ذخیره ته لاړ شئ، یو څه کمانډ ټایپ کړئ او یو چمتو شوی عکس ترلاسه کړئ، د دې پوهیدلو سره چې څنګه او څه باید په سمه توګه ترسره شي. په هرصورت، زه په شخصي توګه ډاډه نه یم چې ټول باریکونه په دې توګه اټکل کیدی شي.

او دلته پروژې دي:

• moby/buildkit - د Docker Inc څخه جوړونکی (د ډاکر اوسني نسخو کې مدغم شوی)، کوم چې هڅه کوي دا ټولې ستونزې حل کړي؛
• کانیکو - د ګوګل څخه یو جوړونکی چې تاسو ته اجازه درکوي پرته له ډاکر څخه جوړ کړئ؛
• Buildpacks.io - د CNCF هڅه د اتوماتیک جادو رامینځته کولو لپاره او په ځانګړي توګه د پرتونو لپاره د بیا رغونې سره په زړه پوري حل؛
• او د نورو اسانتیاوو یوه ډله، لکه جوړ, genuinetools/img...

او وګورئ چې دوی په GitHub کې څومره ستوري لري. یعنی له یوې خوا، docker build شتون لري او یو څه کولی شي، مګر په واقعیت کې مسله په بشپړه توګه نه ده حل شوې - د دې ثبوت د بدیل راټولونکو موازي پرمختګ دی، چې هر یو یې د ستونزو ځینې برخې حل کوي.

په werf کې مجلس

نو موږ دې ته ورسېدو werf (مخکې مشهور لکه dapp) - د فلانټ شرکت څخه د خلاصې سرچینې افادیت، کوم چې موږ د ډیرو کلونو لپاره جوړوو. دا ټول 5 کاله دمخه د بش سکریپټونو سره د ډاکر فایلونو مجلس اصلاح کولو سره پیل شوي ، او د تیرو 3 کلونو لپاره بشپړ پرمختګ د یوې پروژې په چوکاټ کې د خپل Git ذخیره کولو سره ترسره شوی. (لومړی په روبی کې، او بیا بیا لیکل شوی لاړ شه، او په ورته وخت کې نوم بدل شو). په ورف کې د مجلس کومې ستونزې حل کیږي؟

په نیلي سیوري شوي ستونزې لا دمخه پلي شوي ، موازي جوړونه په ورته کوربه کې ترسره شوې ، او په ژیړ کې روښانه شوي مسلې پلان شوي چې د دوبي په پای کې بشپړ شي.

په ثبت کې د خپرولو مرحله (خپرول)

موږ ډایل کړ docker push... - راجسټری ته د عکس اپلوډ کولو په اړه څه مشکل کیدی شي؟ او بیا پوښتنه راپورته کیږي: "زه باید په عکس کې کوم ټګ ولګوم؟" دا د هغه دلیل لپاره رامینځته کیږي چې موږ یې لرو Gitflow (یا نور Git ستراتیژي) او Kubernetes، او صنعت هڅه کوي چې ډاډ ترلاسه کړي چې په Kubernetes کې څه پیښیږي هغه څه تعقیبوي چې په ګیټ کې پیښیږي. په هرصورت، Git زموږ د حقیقت یوازینۍ سرچینه ده.

په دې کې څه مشکل دی؟ د تولید وړتیا ډاډمن کړئ: په ګیټ کې د ژمنې څخه، کوم چې په طبیعت کې نه بدلیدونکی دی (نه بدلیدونکی)، د ډاکر عکس ته ، کوم چې باید ورته وساتل شي.

دا زموږ لپاره هم مهم دی اصليت ټاکل، ځکه چې موږ غواړو پوه شو چې کوم کمیټ په کوبرنیټس کې روان غوښتنلیک رامینځته شوی (بیا موږ کولی شو توپیرونه او ورته شیان ترسره کړو).

د نښه کولو ستراتیژی

لومړی ساده دی git ټګ. موږ یو راجسټری لرو چې د عکس سره په نښه شوي 1.0. Kubernetes مرحله او تولید لري، چیرته چې دا انځور پورته شوی. په ګیټ کې موږ ژمنې کوو او په یو وخت کې موږ ټګ کوو 2.0. موږ دا د ذخیره کولو لارښوونو سره سم راټولوو او د ټګ سره یې په راجسټری کې ځای په ځای کوو 2.0. موږ دا مرحلې ته رسوو او که هرڅه سم وي نو بیا تولید ته.

د دې تګلارې سره ستونزه دا ده چې موږ لومړی ټاګ کېښودو، او یوازې بیا یې ازموینه او رول ولوبوو. ولې؟ لومړی، دا په ساده ډول غیر منطقي دی: موږ د سافټویر یوه نسخه خپروو چې موږ یې حتی آزموینه هم نه ده کړې (موږ بل ډول نشو کولی، ځکه چې د چک کولو لپاره، موږ اړتیا لرو چې یو ټاګ ولګوو). دوهم، دا لاره د Gitflow سره مطابقت نلري.

دوهم اختیار دی git ژمنه + ټاګ. ماسټر څانګه یو ټاګ لري 1.0; د دې لپاره په راجستر کې - یو عکس چې تولید ته ځای په ځای شوی. برسېره پردې، د Kubernetes کلستر د مخکتنې او سټینګ شکلونه لري. بیا موږ د Gitflow تعقیب کوو: د پراختیا لپاره په اصلي څانګه کې (develop) موږ نوې ځانګړتیاوې رامینځته کوو، چې پایله یې د پیژندونکي سره ژمنه ده #c1. موږ دا راټولوو او د دې پیژندونکي په کارولو سره یې په راجسټری کې خپروو (#c1). د ورته پیژندونکي سره موږ مخکتنې ته راووځو. موږ د ژمنو سره ورته کوو #c2 и #c3.

کله چې موږ پوه شو چې کافي ځانګړتیاوې شتون لري، موږ د هرڅه ثبات پیل کوو. په Git کې یوه څانګه جوړه کړئ release_1.1 (په اډه کې #c3 د develop). د دې خوشې کولو راټولولو ته اړتیا نشته، ځکه چې ... دا په تیرو ګامونو کې ترسره شوی. له همدې امله، موږ کولی شو په ساده ډول دا د سټینګ کولو لپاره راوګرځوو. موږ په کې کیګونه حل کوو #c4 او په ورته ډول د سټیج کولو لپاره رول ولوبوي. په ورته وخت کې، د پرمختګ په حال کې دی develop، چیرې چې بدلونونه په دوره توګه اخیستل کیږي release_1.1. په ځینو وختونو کې، موږ یو ژمنتیا ترلاسه کوو او سټیجینګ ته اپلوډ کوو، کوم چې موږ خوښ یو (#c25).

بیا موږ د خوشې کولو څانګې (چټک سره) یوځای کوو (release_1.1) په ماسټر کې. موږ پدې ژمنې کې د نوي نسخې سره ټاګ کیښود (1.1). مګر دا عکس دمخه په راجسټری کې راټول شوی ، نو د دې لپاره چې دا بیا راټول نشي ، موږ په ساده ډول موجوده عکس ته دوهم ټاګ اضافه کوو (اوس دا په راجسټری کې ټاګونه لري #c25 и 1.1). له هغې وروسته، موږ دا تولید ته واړوو.

یو نیمګړتیا شتون لري چې یوازې یو عکس سټیجینګ ته پورته کیږي (#c25)، او په تولید کې دا ډول ډول دی (1.1)، مګر موږ پوهیږو چې "فزیکي پلوه" دا د راجستر څخه ورته عکس دی.

اصلي نیمګړتیا دا ده چې د ادغام ژمنو لپاره هیڅ ملاتړ شتون نلري ، تاسو باید ګړندي پرمخ لاړشئ.

موږ کولی شو نور هم لاړ شو او یو چل وکړو ... راځئ چې د ساده ډاکر فایل مثال وګورو:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

راځئ چې د لاندې اصولو سره سم له دې څخه فایل جوړ کړو:

• SHA256 د کارول شوي عکسونو پیژندونکو څخه (ruby:2.3 и nginx:alpine)، کوم چې د دوی د منځپانګې چک سمونه دي؛
• ټول ټیمونه (RUN, CMD او همداسی پسی.)؛
• SHA256 د فایلونو څخه چې اضافه شوي.

او د داسې فایل څخه چکسم (بیا SHA256) واخلئ. دا لاسلیک هرڅه چې د ډاکر عکس مینځپانګې تعریفوي.

راځئ چې بیرته ډیاګرام ته لاړ شو او د ژمنو پرځای به موږ دا ډول لاسلیکونه وکاروو, i.e. انځورونه د لاسلیکونو سره ټګ کړئ.

اوس، کله چې اړین وي، د بیلګې په توګه، د خوشې کولو څخه ماسټر ته د بدلونونو یوځای کولو لپاره، موږ کولی شو د ریښتینې ضمیمه ژمنې ترسره کړو: دا به یو بل پیژندونکی ولري، مګر ورته لاسلیک. د ورته پیژندونکي سره به موږ عکس تولید ته واړوو.

نیمګړتیا دا ده چې اوس به دا امکان ونلري چې دا معلومه کړي چې کوم ډول ژمنې تولید ته اړ ایستل شوي - چیکسم یوازې په یو لوري کار کوي. دا ستونزه د میټاډاټا سره د اضافي پرت لخوا حل شوې - زه به تاسو ته نور وروسته ووایم.

په werf کې نښه کول

په ویرف کې موږ نور هم لاړو او د یوې زیرمې سره د توزیع شوي جوړونې لپاره چمتووالی نیسو چې په یوه ماشین کې نه زیرمه کیږي ... نو موږ دوه ډوله ډاکر عکسونه جوړوو ، موږ ورته وایو پړاو и انځور.

د werf Git ذخیره د جوړونې ځانګړي لارښوونې ذخیره کوي چې د جوړیدو مختلف مرحلې بیانوي (د نصبولو دمخه, لګول, د تنظیم کولو دمخه, چمتو کول). موږ د لومړي مرحلې عکس د لاسلیک سره راټولوو چې د لومړي مرحلو چیکسم په توګه تعریف شوی. بیا موږ د سرچینې کوډ اضافه کوو، د نوي پړاو عکس لپاره موږ د هغې چکسم حساب کوو ... دا عملیات د ټولو مرحلو لپاره تکرار کیږي، چې په پایله کې موږ د سټیج عکسونو سیټ ترلاسه کوو. بیا موږ وروستی عکس جوړوو، کوم چې د هغې د اصل په اړه میټاډاټا هم لري. او موږ دا عکس په بیلابیلو لارو ټګ کوو (تفصیل وروسته).

فرض کړئ چې له دې وروسته یوه نوې ژمنه څرګندیږي په کوم کې چې یوازې د غوښتنلیک کوډ بدل شوی. څه به وشي؟ د کوډ بدلونونو لپاره، یو پیچ به جوړ شي او د نوي پړاو عکس به چمتو شي. د دې لاسلیک به د زاړه مرحلې عکس او نوي پیچ چیکسم په توګه وټاکل شي. د دې عکس څخه به یو نوی وروستی عکس جوړ شي. ورته چلند به په نورو مرحلو کې د بدلونونو سره پیښ شي.

پدې توګه ، د مرحلې عکسونه یوه زیرمه ده چې په توزیع کې زیرمه کیدی شي ، او له دې څخه رامینځته شوي عکسونه د ډاکر راجسټری ته اپلوډ شوي.

د راجسټری پاکول

موږ د پرتونو حذف کولو په اړه خبرې نه کوو چې د حذف شوي ټاګونو وروسته ځړول پاتې دي - دا پخپله د ډاکر راجسټری معیاري ب featureه ده. موږ د داسې وضعیت په اړه خبرې کوو کله چې ډیری ډاکر ټاګونه راټولیږي او موږ پوهیږو چې موږ نور دوی ته اړتیا نلرو ، مګر دوی ځای نیسي (او/یا موږ د هغې لپاره تادیه کوو).

د پاکولو تګلارې څه دي؟

1. تاسو یوازې هیڅ نه شی کولی پاک مه کوئ. ځینې ​​​​وختونه دا واقعیا اسانه ده چې د اضافي ځای لپاره لږ پیسې ورکړئ په پرتله د ټاګونو لوی پیچلتیا راوباسي. مګر دا یوازې تر یوې ټاکلې نقطې پورې کار کوي.
2. بشپړ بیا تنظیمول. که تاسو ټول عکسونه حذف کړئ او یوازې د CI سیسټم کې اوسني عکسونه بیا جوړ کړئ ، ستونزه رامینځته کیدی شي. که کانټینر په تولید کې بیا پیل شي ، نو د دې لپاره به یو نوی عکس پورته شي - یو هغه چې لاهم د چا لخوا نه دی ازمول شوی. دا د نه بدلیدونکي زیربنا مفکوره وژني.
3. شین. یو راجسټری ډیریدل پیل کړل - موږ عکسونه بل ته اپلوډ کوو. ورته ستونزه لکه څنګه چې په تیر میتود کې: ​​په کوم وخت کې تاسو کولی شئ هغه راجسټری پاک کړئ چې ډیریدل پیل شوي؟
4. د وخت په تیریدو سره. له یوې میاشتې څخه زاړه ټول عکسونه حذف کړئ؟ مګر یقینا یو خدمت به وي چې د یوې میاشتې لپاره تازه شوی نه وي ...
5. په سمه توګه معلوم کړئ چې څه دمخه حذف کیدی شي.

دلته دوه واقعیا د پام وړ اختیارونه شتون لري: پاک مه کوئ یا په لاسي ډول د نیلي شنه + ترکیب. په وروستي حالت کې، موږ د لاندې په اړه خبرې کوو: کله چې تاسو پوهیږئ چې دا د راجستر پاکولو وخت دی، تاسو یو نوی جوړ کړئ او ټول نوي عکسونه د بیلګې په توګه، د یوې میاشتې په اوږدو کې اضافه کړئ. او یوه میاشت وروسته، وګورئ چې په کوبرنیټس کې کوم پوډونه لاهم زاړه راجسټری کاروي، او نوي راجستر ته یې لیږدوي.

موږ څه ته راغلي یو werf؟ موږ راټولوو:

1. د ګیټ سر: ټول ټاګونه ، ټولې څانګې - داسې انګیرل چې موږ هر هغه څه ته اړتیا لرو چې په ګیټ کې په عکسونو کې ټګ شوي وي (او که نه ، نو بیا موږ اړتیا لرو دا پخپله ګیټ کې حذف کړو)؛
2. ټول پوډونه چې اوس مهال Kubernetes ته پمپ شوي؛
3. زوړ ReplicaSets (هغه څه چې پدې وروستیو کې خپاره شوي)، او موږ هم پالن لرو چې د هیلم ریلیز سکین کړو او هلته وروستي انځورونه وټاکو.

او له دې سیټ څخه سپین لیست جوړ کړئ - د عکسونو لیست چې موږ به یې حذف نه کړو. موږ نور هرڅه پاکوو، وروسته له هغه چې موږ د یتیم مرحلې انځورونه پیدا کوو او هغه یې هم حذف کوو.

د ځای پرځای کولو مرحله

د باور وړ اعالمیه

لومړی ټکی چې زه غواړم په ګمارلو کې ورته پام واړوم د تازه شوي سرچینې تشکیلاتو رول آوټ دی ، چې په اعالمیه توګه اعلان شوی. اصلي YAML سند چې د Kubernetes سرچینې تشریح کوي تل د پایلې څخه خورا توپیر لري چې واقعیا په کلستر کې پرمخ ځي. ځکه چې Kubernetes په ترتیب کې اضافه کوي:

1. پیژندونکي
2. د خدماتو معلومات
3. ډیری ډیفالټ ارزښتونه؛
4. د اوسني حالت سره برخه؛
5. د داخلې ویب هک برخې په توګه رامینځته شوي بدلونونه؛
6. د مختلف کنټرولرانو د کار پایله (او مهالویش کونکي).

نو ځکه، کله چې د نوي سرچینې ترتیب ښکاره شي (نوي)، موږ نشو کولی یوازې د دې سره اوسنی، "ژوندی" ترتیب واخلو او له سره ولیکو (ژوند). د دې کولو لپاره موږ باید پرتله کړو نوي د وروستي پلي شوي ترتیب سره (وروستی تطبیق شوی) او راوګرځوئ ژوند پیچ ترلاسه کړ.

دا طریقه ویل کیږي 2-طریقه یوځای کول. دا کارول کیږي، د بیلګې په توګه، په هیلم کې.

هم شته 3-طریقه یوځای کول، کوم چې پدې کې توپیر لري:

• پرتله کول وروستی تطبیق شوی и نويموږ ګورو چې څه حذف شوي دي؛
• پرتله کول نوي и ژوند، موږ ګورو چې څه اضافه شوي یا بدل شوي؛
• لنډ شوی پیچ په کې پلي کیږي ژوند.

موږ د هیلم سره 1000+ غوښتنلیکونه ځای په ځای کوو، نو موږ په حقیقت کې د 2-طریقې یوځای کولو سره ژوند کوو. په هرصورت، دا یو شمیر ستونزې لري چې موږ د خپلو پیچونو سره حل کړي، کوم چې هیلم سره په نورمال ډول کار کولو کې مرسته کوي.

د اصلي رول آوټ حالت

وروسته له دې چې زموږ د CI سیسټم د راتلونکي پیښې پراساس د کبرنیټس لپاره نوی ترتیب رامینځته کوي ، دا د کارولو لپاره لیږدوي (غوښتنه) کلستر ته - د هیلم په کارولو سره یا kubectl apply. بیا ، دمخه تشریح شوی N-way ادغام پیښیږي ، کوم چې د کوبرنیټس API د CI سیسټم ته په تصویب سره ځواب ورکوي ، او دا د دې کارونکي ته.

په هرصورت، یوه لویه ستونزه شتون لري: وروسته له دې بریالي غوښتنلیک د بریالي رول آوټ معنی نلري. که Kubernetes پوهیږي چې کوم بدلونونه باید پلي شي او پلي یې کړي، موږ لاهم نه پوهیږو چې پایله به یې څه وي. د مثال په توګه، په مخکینۍ برخه کې د پوډونو تازه کول او بیا پیل کول ممکن بریالي وي، مګر په پس منظر کې نه، او موږ به د چلولو غوښتنلیک انځورونو مختلف نسخې ترلاسه کړو.

د هرڅه په سمه توګه ترسره کولو لپاره، دا سکیم اضافي لینک ته اړتیا لري - یو ځانګړی تعقیبونکی چې د کوبرنیټس API څخه به د وضعیت معلومات ترلاسه کړي او د شیانو اصلي حالت نور تحلیل لپاره یې لیږدوي. موږ په Go کې د خلاصې سرچینې کتابتون جوړ کړ - cubedog (دا اعلان وګورئ دلته)، کوم چې دا ستونزه حل کوي او په ویرف کې رامینځته کیږي.

د werf په کچه د دې ټریکر چلند د تشریحاتو په کارولو سره تنظیم شوی چې په ډیپلومینټونو یا StatefulSets کې ځای په ځای شوي. اصلي تبصره - fail-mode - په لاندې معنی پوهیږي:

• IgnoreAndContinueDeployProcess - موږ د دې برخې د پلي کولو ستونزې له پامه غورځوو او پلي کولو ته دوام ورکوو؛
• FailWholeDeployProcessImmediately - په دې برخه کې یوه تېروتنه د ځای پرځای کولو پروسه ودروي؛
• HopeUntilEndOfDeployProcess - موږ هیله لرو چې دا برخه به د ځای پرځای کولو په پای کې کار وکړي.

د مثال په توګه، د سرچینو او تشریح ارزښتونو دا ترکیب fail-mode:

کله چې موږ د لومړي ځل لپاره ځای په ځای کوو، ډیټابیس (MongoDB) ممکن لاهم چمتو نه وي - ځای پرځای کول به ناکام شي. مګر تاسو کولی شئ د دې پیل لپاره د شیبې انتظار وکړئ، او ګمارل به لاهم ترسره شي.

په werf کې د کوبیډوګ لپاره دوه نور تشریحات شتون لري:

• failures-allowed-per-replica - د هرې نقل لپاره د اجازه ورکوونکو شمیر؛
• show-logs-until - هغه شیبه تنظیموي تر څو چې werf د ټولو راولډ شوي پوډونو څخه لاګونه (په stdout کې) ښکاره کړي. ډیفالټ دی PodIsReady (د هغه پیغامونو څخه سترګې پټول چې موږ شاید نه غواړو کله چې ټرافيک پوډ ته راشي)، مګر ارزښتونه هم د اعتبار وړ دي: ControllerIsReady и EndOfDeploy.

موږ له ګمارنې څخه نور څه غواړو؟

د دوه ټکو سربیره چې دمخه تشریح شوي ، موږ غواړو:

• لیدل لوګو - او یوازې اړین دي، او هر څه په قطار کې نه؛
• تعقیب پرمختګځکه چې که دنده د څو دقیقو لپاره "خاموش" ودرول شي، نو دا مهمه ده چې پوه شئ چې هلته څه پیښیږي؛
• باید ولري اتوماتیک رول بیک په هغه صورت کې چې یو څه غلط شوي وي (او له همدې امله د ګمارنې اصلي حالت پوهیدل خورا مهم دي). رول آوټ باید اټومي وي: یا دا پای ته ځي، یا هرڅه خپل پخواني حالت ته راستانه کیږي.

پایلې

زموږ لپاره د یو شرکت په توګه ، د تحویلي مختلف مرحلو کې د ټولو تشریح شوي باریکیو پلي کولو لپاره (جوړول ، خپرول ، ځای پرځای کول) ، د CI سیسټم او افادیت کافي دي werf.

د یوې پایلې پرځای:

د werf په مرسته، موږ د DevOps انجینرانو لپاره د لوی شمیر ستونزو په حل کې ښه پرمختګ کړی او خوشحاله به یو که چیرې پراخه ټولنه لږترلږه دا کار په عمل کې هڅه وکړي. دا به اسانه وي چې یوځای ښه پایله ترلاسه کړئ.

ویډیوګانې او سلایډونه

د فعالیت څخه ویډیو (~ 47 دقیقې):

د راپور وړاندې کول:

PS

زموږ په بلاګ کې د کبرنیټس په اړه نور راپورونه:

• «په کبرنیټس کې د اتوماتیک کولو او سرچینو مدیریت» (دیمیتري سټولیاروف؛ د اپریل 27، 2019 په "اعتصاب" کې);
• «د Kubernetes پراخول او تکمیل کول» (انډری پولوف؛ د اپریل 8، 2019 په سینټ های لوډ++ کې);
• «ډیټابیسونه او کبرنیټس» (دیمیتري سټولیاروف؛ د نومبر 8، 2018 په HighLoad++);
• «څارنه او Kubernetes» (دیمیتري سټولیاروف؛ د می 28، 2018 په RootConf کې);
• «CI/CD د Kubernetes او GitLab سره غوره تمرینونه» (دیمیتري سټولیاروف؛ د نومبر 7، 2017 په HighLoad++);
• «په کوچنیو پروژو کې د کوبرنیټس سره زموږ تجربه» (دیمیتري سټولیاروف؛ د جون 6، 2017 په RootConf کې).

سرچینه: www.habr.com