د کانټینر عکسونو د "سمارټ" پاکولو ستونزه او په ویرف کې د هغې حل

د کانټینر عکسونو د "سمارټ" پاکولو ستونزه او په ویرف کې د هغې حل

مقاله د عکسونو پاکولو ستونزې په اړه بحث کوي چې د کانټینر راجسټری (ډاکر راجسټری او د هغې انلاګونه) کې راټول شوي د کلاوډ اصلي غوښتنلیکونو لپاره د عصري CI/CD پایپ لاینونو واقعیتونو کې کوبرنیټس ته سپارل شوي. د عکسونو مطابقت لپاره اصلي معیارونه او د پاکولو اتومات کولو ، د ځای خوندي کولو او د ټیمونو اړتیاو پوره کولو کې رامینځته شوي ستونزې ورکړل شوي. په نهایت کې ، د یوې ځانګړې خلاصې سرچینې پروژې مثال په کارولو سره ، موږ به تاسو ته ووایو چې دا ستونزې څنګه لرې کیدی شي.

پېژندنه

د کانټینر ثبت کې د عکسونو شمیر په چټکۍ سره وده کولی شي ، د ذخیره کولو ډیر ځای نیسي او پدې توګه د پام وړ لګښت زیاتوي. په ثبت کې نیول شوي ځای د منلو وړ ودې کنټرول، محدودولو یا ساتلو لپاره، دا منل کیږي:

  1. د انځورونو لپاره د ټګونو یو ثابت شمیر وکاروئ؛
  2. انځورونه په یو ډول پاک کړئ.


لومړی محدودیت کله ناکله د کوچنیو ټیمونو لپاره د منلو وړ وي. که پراختیا کونکي کافي دایمي ټاګونه ولري (latest, main, test, boris او داسې نور)، راجستر به په اندازې کې پړسوب نه وي او د اوږدې مودې لپاره تاسو اړتیا نلرئ د دې پاکولو په اړه فکر وکړئ. په هرصورت، ټول غیر مساوي انځورونه له منځه وړل شوي، او د پاکولو لپاره هیڅ کار پاتې نه دی (هر څه د منظم کثافاتو راټولونکي لخوا ترسره کیږي).

په هرصورت، دا طریقه په پراخه کچه پراختیا محدودوي او په ندرت سره د عصري CI/CD پروژو لپاره پلي کیږي. د پرمختګ یوه مهمه برخه وه اتومات، کوم چې تاسو ته اجازه درکوي چې کاروونکو ته ډیر ګړندي ازموینه ، ځای په ځای او نوي فعالیت وړاندې کړئ. د مثال په توګه ، زموږ په ټولو پروژو کې ، د CI پایپ لاین په اوتومات ډول د هرې ژمنې سره رامینځته کیږي. پدې کې ، عکس راټول شوی ، ازمول شوی ، د ډیبګ کولو او پاتې چکونو لپاره مختلف کوبرنیټس سرکټونو ته رسول شوی ، او که هرڅه سم وي ، بدلونونه وروستي کارونکي ته رسي. او دا نور د راکټ ساینس نه دی، مګر د ډیری لپاره ورځنۍ پیښه ده - ډیری احتمال ستاسو لپاره، ځکه چې تاسو دا مقاله لوستلئ.

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

مګر تاسو څنګه دا هم معلومولی شئ چې ایا یو انځور اړوند دی؟

د انځور د تړاو لپاره معیارونه

په ډیری قضیو کې، اصلي معیارونه به دا وي:

1. لومړی (د ټولو څخه خورا څرګند او خورا مهم) هغه انځورونه دي چې اوس مهال په Kubernetes کې کارول کیږي. د دې عکسونو لرې کول کولی شي د پام وړ تولید کم وخت لګښتونو پایله ولري (د مثال په توګه ، عکسونه ممکن د نقل لپاره اړین وي) یا په کوم لوپس کې د ټیم ډیبګ کولو هڅې رد کړي. (د دې دلیل لپاره موږ حتی یو ځانګړی جوړ کړ Prometheus صادرونکی، کوم چې په هر کوبرنیټس کلستر کې د داسې عکسونو نشتوالی تعقیبوي.)

2. دوهم (لږ څرګند، مګر خورا مهم او بیا د استحصال سره تړاو لري) - هغه انځورونه چې د جدي ستونزو موندلو په صورت کې د رول بیک لپاره اړین دی په اوسني نسخه کې. د مثال په توګه، د هیلم په قضیه کې، دا هغه انځورونه دي چې د خوشې کولو په خوندي نسخو کې کارول کیږي. (په هرصورت، په هیلم کې د ډیفالټ حد 256 بیاکتنې دي، مګر دا امکان نلري چې څوک واقعیا خوندي کولو ته اړتیا ولري لکه د نسخو لوی شمیر؟..) په هرصورت، موږ، په ځانګړې توګه، نسخې ذخیره کوو ترڅو وروسته یې وکاروو، د بیلګې په توګه. که اړتیا وي دوی ته "بیا راوګرځوئ".

3. دریم - پراختیا کونکي اړتیاوې: ټول هغه انځورونه چې د دوی د اوسني کار سره تړاو لري. د مثال په توګه ، که موږ د PR په اړه فکر کوو ، نو دا معنی لري چې د وروستي ژمنې سره ورته عکس پریږدئ او ووایئ ، پخوانۍ ژمنې: پدې توګه پراختیا کونکی کولی شي ژر تر ژره هرې دندې ته راستون شي او د وروستي بدلونونو سره کار وکړي.

4. څلورم - هغه انځورونه چې زموږ د غوښتنلیک نسخو سره مطابقت لري، i.e. وروستی محصول دي: v1.0.0، 20.04.01/XNUMX/XNUMX، سیرا، او داسې نور.

نوټ: دلته تعریف شوي معیارونه د مختلفو شرکتونو څخه د لسګونو پرمختیایي ټیمونو سره د تجربې پراساس جوړ شوي. په هرصورت، البته، د پراختیایي پروسو په ځانګړتیاو پورې اړه لري او زیربنا کارول کیږي (د مثال په توګه، Kubernetes نه کارول کیږي)، دا معیارونه ممکن توپیر ولري.

وړتیا او شته حلونه

د کانټینر راجسترونو سره مشهور خدمتونه ، د یوې قاعدې په توګه ، د دوی د عکس پاکولو پالیسۍ وړاندیز کوي: په دوی کې تاسو کولی شئ هغه شرایط تعریف کړئ چې له مخې یې ټاګ له راجسټری څخه لرې کیږي. په هرصورت، دا شرایط د پیرامیټونو لخوا محدود دي لکه نومونه، د جوړولو وخت، او د ټګونو شمیر*.

* د ځانګړي کانټینر راجسټري پلي کولو پورې اړه لري. موږ د لاندې حلونو امکانات په پام کې نیولي: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab کانټینر راجسټری, Harbor Registry, JFrog Artifactory, Quay.io - د سپتمبر 2020 پورې.

د پیرامیټونو دا سیټ د څلورم معیار پوره کولو لپاره کافي دی - دا د هغه عکسونو غوره کول دي چې د نسخو سره مطابقت لري. په هرصورت، د نورو ټولو معیارونو لپاره، یو څوک باید یو ډول جوړجاړی حل غوره کړي (یو سخت یا، په برعکس، ډیر نرمه پالیسي) - د توقعاتو او مالي وړتیاوو پورې اړه لري.

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

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

په ګیټ کې د کاري فلو مثال

راځئ چې ووایو تاسو په ګیټ کې داسې یو څه کار کوئ:

د کانټینر عکسونو د "سمارټ" پاکولو ستونزه او په ویرف کې د هغې حل

په ډیاګرام کې د سر سره عکس د کانټینر عکسونه په ګوته کوي چې اوس مهال د هر کارونکي (د پای کارونکي ، ټیسټرانو ، مدیرانو او نورو) لپاره په کوبرنیټس کې ځای په ځای شوي یا د ډیبګ کولو او ورته اهدافو لپاره د پراختیا کونکو لخوا کارول کیږي.

څه پیښیږي که چیرې د پاکولو پالیسي یوازې د عکسونو ساتلو ته اجازه ورکړي (نه حذف شوي) د ورکړل شوي ټګ نومونو سره?

د کانټینر عکسونو د "سمارټ" پاکولو ستونزه او په ویرف کې د هغې حل

په ښکاره ډول، دا ډول سناریو به هیڅوک خوشحاله نه کړي.

څه به بدلون ومومي که چیرې پالیسۍ اجازه ورکړي چې عکسونه حذف نشي؟ د ټاکل شوي وخت وقفې / د وروستي ژمنو شمیر سره سم?

د کانټینر عکسونو د "سمارټ" پاکولو ستونزه او په ویرف کې د هغې حل

پایله خورا ښه شوې ، مګر لاهم له مثالي څخه لرې ده. په هرصورت ، موږ لاهم پراختیا کونکي لرو چې د بګونو د خلاصولو لپاره په راجسټري کې عکسونو ته اړتیا لري (یا حتی په K8s کې ګمارل شوي) ...

د اوسني بازار وضعیت لنډیز کولو لپاره: د کانټینر راجسترونو کې موجود دندې د پاکولو پرمهال کافي انعطاف نه وړاندې کوي ، او د دې اصلي لامل دا دی. د بهرنۍ نړۍ سره د تعامل لپاره هیڅ لاره نشته. دا معلومه شوه چې هغه ټیمونه چې ورته انعطاف ته اړتیا لري مجبور دي په خپلواکه توګه د عکس حذف کول "له بهر څخه" پلي کړي ، د ډاکر راجسټري API (یا د ورته پلي کولو اصلي API) په کارولو سره.

په هرصورت ، موږ د یو نړیوال حل په لټه کې یو چې د مختلف راجسټریو په کارولو سره د مختلف ټیمونو لپاره د عکس پاکول اتومات کړي ...

د نړیوال عکس پاکولو لپاره زموږ لاره

دا اړتیا له کوم ځای څخه راځي؟ حقیقت دا دی چې موږ د پراختیا کونکو جلا ګروپ نه یو، مګر یو ټیم چې ډیری یې په یو وخت کې خدمت کوي، د CI/CD مسلو په هر اړخیزه توګه حل کولو کې مرسته کوي. او د دې لپاره اصلي تخنیکي وسیله د خلاصې سرچینې افادیت دی werf. د دې ځانګړتیا دا ده چې دا یو واحد فعالیت نه کوي، مګر په ټولو مرحلو کې د دوامداره تحویلي پروسو سره یوځای کیږي: له مجلس څخه تر ګمارلو پورې.

ثبت ته د عکسونو خپرول (د جوړیدو سمدلاسه وروسته) د داسې یوټیلټي یو څرګند فعالیت دی. او څنګه چې عکسونه هلته د ذخیره کولو لپاره ځای په ځای شوي ، نو - که ستاسو ذخیره لامحدود نه وي - تاسو اړتیا لرئ د دوی راتلونکي پاکولو مسؤلیت ولرئ. موږ څنګه په دې کې بریالیتوب ترلاسه کړ، د ټولو ټاکل شویو معیارونو په پوره کولو سره به نور بحث وشي.

* که څه هم پخپله راجسټرې ممکن توپیر ولري (د ډاکر راجسټری ، د ګیټ لیب کانټینر راجسټری ، هاربر ، او داسې نور) ، د دوی کارونکي د ورته ستونزو سره مخ دي. زموږ په قضیه کې نړیوال حل د راجسټری پلي کولو پورې اړه نلري ، ځکه چې پخپله د راجسترونو څخه بهر تیریږي او د هرچا لپاره ورته چلند وړاندیز کوي.

که څه هم موږ werf د مثال پلي کولو په توګه کاروو، موږ هیله لرو چې کارول شوي طریقې به د نورو ټیمونو لپاره ګټورې وي چې د ورته ستونزو سره مخ دي.

نو موږ بوخت شو باندنۍ د عکسونو پاکولو لپاره د میکانیزم پلي کول - د هغه وړتیاو پرځای چې دمخه د کانټینرونو لپاره راجسترونو کې رامینځته شوي. لومړی ګام د ډاکر راجسټری API کارول و ترڅو د ټاګونو شمیر او د دوی رامینځته کولو وخت لپاره ورته لومړني پالیسۍ رامینځته کړي (پورته ذکر شوی). په دوی کې اضافه شوي د ګمارل شوي زیربنا کې کارول شوي عکسونو پراساس لیست ته اجازه ورکړئ, i.e. Kubernetes. د وروستي لپاره، دا د ټولو ګمارل شویو سرچینو له لارې تکرارولو او د ارزښتونو لیست ترلاسه کولو لپاره د Kubernetes API کارولو لپاره کافي و. image.

دې کوچني حل خورا جدي ستونزه حل کړه (معیار نمبر 1) ، مګر یوازې د پاکولو میکانیزم ښه کولو لپاره زموږ د سفر پیل و. بل - او ډیر په زړه پورې - ګام پریکړه وه خپاره شوي عکسونه د Git تاریخ سره شریک کړئ.

د نښه کولو سکیمونه

د پیل کولو لپاره، موږ یو داسې طریقه غوره کړه چې په هغه کې وروستی عکس باید د پاکولو لپاره اړین معلومات ذخیره کړي، او د ټیګ کولو سکیمونو پروسه جوړه کړي. کله چې یو انځور خپور کړئ، کارونکي د ځانګړي نښه کولو اختیار غوره کړی (git-branch, git-commit او یا git-tag) او اړونده ارزښت یې کارولی. د CI سیسټمونو کې، دا ارزښتونه په اتوماتيک ډول د چاپیریال متغیرونو پر بنسټ ټاکل شوي. په حقیقت کی وروستی عکس د ځانګړي ګیټ ابتدايي سره تړاو درلودپه لیبلونو کې د پاکولو لپاره اړین معلومات ذخیره کول.

دا کړنلاره د پالیسیو یوه سیټ پایله درلوده چې Git ته یې اجازه ورکړه چې د ریښتیا واحد سرچینې په توګه وکارول شي:

  • کله چې په ګیټ کې د څانګې / ټاګ حذف کول ، په راجسټري کې اړوند عکسونه په اوتومات ډول حذف شوي.
  • د Git ټاګونو او ژمنو سره تړلي عکسونو شمیر په ټاکل شوي سکیما کې د کارول شوي ټاګونو شمیر او هغه وخت چې اړوند ژمنې رامینځته شوې کنټرول کیدی شي.

په ټولیز ډول، د پایلې پلي کولو زموږ اړتیاوې پوره کړې، مګر ډیر ژر یوه نوې ننګونه زموږ په تمه ده. حقیقت دا دی چې د ګیټ پریمیټیو پراساس د ټاګ کولو سکیمونو کارولو پرمهال ، موږ د یو شمیر نیمګړتیاو سره مخ شو. (ځکه چې د دوی توضیحات د دې مقالې له دائرې څخه بهر دي ، هرڅوک کولی شي ځان له توضیحاتو سره آشنا کړي دلته.) له همدې امله، پریکړه وکړه چې د ټاګ کولو (د مینځپانګې پراساس ټاګ کولو) لپاره ډیر اغیزمن چلند ته لاړشئ ، موږ باید د عکس پاکولو پلي کولو باندې له سره غور وکړو.

نوی الګوریتم

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

د نوي پاکولو الګوریتم لپاره، پریکړه وشوه چې د ټیګ کولو سکیمونو څخه لیرې او جوړ شي د میټا عکس پروسه، چې هر یو یې یوه ډله ذخیره کوي:

  • هغه ژمنې چې خپرونه یې ترسره کړې وه (دا مهمه نده چې ایا عکس اضافه شوی ، بدل شوی یا د کانټینر ثبت کې ورته پاتې شوی)؛
  • او زموږ داخلي پیژندونکی د راټول شوي عکس سره مطابقت لري.

په بل عبارت، دا چمتو شوی په Git کې د ژمنو سره خپاره شوي ټاګونه وصل کول.

وروستی ترتیب او عمومي الګوریتم

کله چې د پاکولو ترتیب کول، کاروونکي اوس هغو پالیسیو ته لاسرسی لري چې اوسني انځورونه غوره کوي. دا ډول پالیسي هر یو تعریف شوي:

  • ډیری حوالې، i.e. Git tags یا Git څانګې چې د سکین کولو پرمهال کارول کیږي؛
  • او د سیټ څخه د هرې حوالې لپاره د لټون شوي عکسونو حد.

د روښانه کولو لپاره، دا هغه څه دي چې د ډیفالټ پالیسۍ ترتیب داسې ښکاري:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

دا ترتیب درې پالیسۍ لري چې د لاندې مقرراتو سره مطابقت لري:

  1. د وروستي 10 Git ټاګونو لپاره عکس خوندي کړئ (د ټګ جوړولو نیټې سره).
  2. په تیره اونۍ کې له 2 څخه ډیر عکسونه خوندي نه کړئ په تیره اونۍ کې د فعالیت سره له 10 څخه ډیر موضوعاتو لپاره.
  3. د څانګو لپاره 10 انځورونه خوندي کړئ main, staging и production.

وروستی الګوریتم لاندې مرحلو ته ځي:

  • د کانټینر راجسټری څخه څرګندونه ترلاسه کول.
  • په Kubernetes کې کارول شوي عکسونو پرته، ځکه موږ دمخه د K8s API رایه ورکولو سره دوی دمخه غوره کړي دي.
  • د Git تاریخ سکین کول او د مشخصو پالیسیو پراساس د عکسونو ایستل.
  • د پاتې انځورونو لرې کول.

زموږ انځور ته راستنیدل، دا هغه څه دي چې د ویرف سره پیښیږي:

د کانټینر عکسونو د "سمارټ" پاکولو ستونزه او په ویرف کې د هغې حل

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

پایلې

  • ډیر ژر یا وروسته، ډیری ټیمونه د راجسټری ډیریدو ستونزې سره مخ کیږي.
  • کله چې د حل په لټه کې وي، نو لومړی اړینه ده چې د انځور د تړاو لپاره معیارونه وټاکئ.
  • د مشهور کانټینر راجسټری خدماتو لخوا وړاندیز شوي وسیلې تاسو ته اجازه درکوي خورا ساده پاکول تنظیم کړئ چې "بهرنۍ نړۍ" په پام کې نه نیسي: په کوبرنیټس کې کارول شوي عکسونه او د ټیم کاري جریان ځانګړتیاوې.
  • یو انعطاف منونکی او موثر الګوریتم باید د CI/CD پروسو پوهه ولري او نه یوازې د ډاکر عکس ډیټا سره کار وکړي.

PS

زموږ په بلاګ کې هم ولولئ:

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

Add a comment