تاسو اوس کولی شئ د منظم ډاکر فایل په کارولو سره په ویرف کې د ډاکر عکسونه جوړ کړئ

د هیڅکله نه ناوخته ښه. یا څنګه موږ د غوښتنلیک عکسونو جوړولو لپاره د منظم ډاکر فایلونو ملاتړ نه کولو سره نږدې جدي غلطي کړې.

موږ به په اړه خبرې وکړو werf - د GitOps افادیت چې د هر ډول CI/CD سیسټم سره مدغم کیږي او د ټول غوښتنلیک د ژوند دورې مدیریت چمتو کوي ، اجازه ورکوي:

• انځورونه راټول او خپاره کړئ،
• په Kubernetes کې غوښتنلیکونه ځای په ځای کړئ،
• د ځانګړو پالیسیو په کارولو سره نه کارول شوي عکسونه حذف کړئ.

د پروژې فلسفه په یو واحد متحد سیسټم کې د ټیټ کچې وسیلې راټولول دي چې د DevOps انجینرانو ته په غوښتنلیکونو کنټرول ورکوي. که امکان ولري، موجوده اسانتیاوې (لکه هیلم او ډاکر) باید وکارول شي. که د یوې ستونزې حل نه وي، موږ کولی شو د دې لپاره اړین هرڅه رامینځته او ملاتړ وکړو.

پس منظر: ستاسو خپل عکس راټولونکی

دا هغه څه دي چې په ویرف کې د عکس راټولونکي سره پیښ شوي: معمول ډاکر فایل زموږ لپاره کافي نه و. که تاسو د پروژې تاریخ ته یو ګړندی نظر واچوئ ، دا ستونزه دمخه د werf په لومړیو نسخو کې راڅرګنده شوې وه (بیا بیا هم د ډیپ په نوم پیژندل کیږي).

پداسې حال کې چې د ډاکر عکسونو کې د غوښتنلیکونو رامینځته کولو لپاره وسیله رامینځته کړه ، موږ په چټکۍ پوه شو چې ډاکرفایل زموږ لپاره د ځینې خورا مشخصو دندو لپاره مناسب نه و:

1. د لاندې معیاري سکیم مطابق د عادي کوچني ویب غوښتنلیکونو جوړولو ته اړتیا:
   • د سیسټم په کچه د غوښتنلیک انحصار نصب کړئ،
   • د غوښتنلیک انحصار کتابتونونو بنډل نصب کړئ،
   • د شتمنیو راټولول
   • او تر ټولو مهم، په عکس کې کوډ په چټکه او اغیزمنه توګه تازه کړئ.
2. کله چې د پروژې فایلونو کې بدلونونه رامینځته شي ، جوړونکی باید په بدل شوي فایلونو کې د پیچ ​​په پلي کولو سره ژر تر ژره نوی پرت رامینځته کړي.
3. که ځینې فایلونه بدل شوي وي، نو اړینه ده چې د اړونده مرحلې بیا رغونه وشي.

نن ورځ زموږ راټولونکی نور ډیر امکانات لري، مګر دا لومړنۍ غوښتنې او غوښتنې وې.

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

په روبي کې د ډیپ لپاره زوړ ترتیب

په YAML کې د werf لپاره اوسنی ترتیب

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

NB: په اوس وخت کې، زموږ راټولونکی، چې د خپل ترتیب سره کار کوي (په YAML کې) او د سټیپیل راټولونکی په نوم یادیږي، لا دمخه په کافي ځواکمن وسیله کې وده کړې. د دې تفصيلي توضیحات د جلا مقالو مستحق دي، او لومړني توضیحات په کې موندل کیدی شي اسناد.

د ستونزې په اړه پوهاوی

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

د دې پوښتنې د ځواب پر ځای، موږ یو حل وړاندې کوو. څه که تاسو دمخه د Dockerfile (یا د Dockerfiles سیټ) لرئ او غواړئ werf وکاروئ؟

NB: په خواشینۍ سره، ولې تاسو حتی د ویرف کارول غواړئ؟ اصلي ځانګړتیاوې په لاندې ډول دي:

• د بشپړ غوښتنلیک مدیریت دورې په شمول د عکس پاکول؛
• د یو واحد ترتیب څخه په یوځل کې د څو عکسونو مجلس اداره کولو وړتیا؛
• د هیلم سره مطابقت لرونکي چارټونو لپاره د ګمارلو پروسه ښه شوې.

د دوی یو بشپړ لیست په کې موندل کیدی شي د پروژې پاڼه.

نو ، که دمخه موږ وړاندیز کړی وای چې زموږ په تشکیل کې د ډاکر فایل بیا لیکلو لپاره ، اوس به موږ په خوښۍ سره ووایو: "راځئ چې خپل ډاکر فایلونه جوړ کړئ!"

څنګه کارول کیږي؟

د دې خصوصیت بشپړ تطبیق په خوشې کې څرګند شو werf v1.0.3-beta.1. عمومي اصول ساده دی: کارونکي په werf ترتیب کې موجود Dockerfile ته لاره مشخصوي، او بیا کمانډ چلوي werf build... او دا دی - ویرف به عکس راټول کړي. راځئ چې یو خلاص مثال وګورو.

راځئ چې راتلونکی اعلان کړو Dockerfile د پروژې په ریښه کې:

FROM ubuntu:18.04
RUN echo Building ...

او موږ به اعلان وکړو werf.yamlکوم چې دا کاروي Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

ټول! کیڼ منډه وړه werf build:

سربیره پردې، تاسو کولی شئ لاندې اعلان کړئ werf.yaml په یوځل کې د مختلف ډاکر فایلونو څخه ډیری عکسونه رامینځته کول:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

په نهایت کې ، دا د اضافي جوړونې پیرامیټونو تیرولو ملاتړ هم کوي ، لکه --build-arg и --add-host - د werf config له لارې. د Dockerfile عکس ترتیب بشپړ توضیحات شتون لري د اسنادو پاڼه.

دا څنګه کار کوي؟

د جوړونې پروسې په جریان کې ، په ډاکر کې د ځایی پرتونو معیاري زیرمه کار کوي. په هرصورت، هغه څه چې مهم دي هغه هم werf دي د ډاکرفایل ترتیب په دې زیربنا کې مدغم کوي. دا څه مانا لري؟

1. هر عکس د Dockerfile څخه جوړ شوی د یوې مرحلې څخه جوړ دی چې ویل کیږي dockerfile (تاسو کولی شئ په دې اړه نور ولولئ چې کوم پړاوونه په ویرف کې دي دلته).
2. د مرحلې لپاره dockerfile werf یو لاسلیک محاسبه کوي چې د Dockerfile تشکیلاتو مینځپانګې پورې اړه لري. کله چې د Dockerfile ترتیب بدل شي، د مرحلې لاسلیک بدلیږي dockerfile او werf د دې مرحلې بیا رغونه د نوي Dockerfile ترتیب سره پیل کوي. که لاسلیک بدل نه شي، نو بیا werf انځور د کیچ څخه اخلي (په ویرف کې د لاسلیکونو کارولو په اړه نور توضیحات په کې تشریح شوي دا راپور).
3. بیا، راټول شوي انځورونه د کمانډ سره خپاره کیدی شي werf publish (يا werf build-and-publish) او دا د کبرنیټس ته د ګمارلو لپاره وکاروئ. د ډاکر راجسټری ته خپاره شوي عکسونه به د معیاري ویرف پاکولو وسیلو په کارولو سره پاک شي ، د بیلګې په توګه. زاړه عکسونه (د N ورځو څخه زاړه) ، د غیر موجود Git څانګو سره تړلي عکسونه ، او نورې پالیسۍ به په اوتومات ډول پاک شي.

دلته د بیان شویو ټکو په اړه نور جزیات په اسنادو کې موندل کیدی شي:

• د خپرولو بهیر;
• د Kubernetes د ځای پرځای کولو پروسې سره یوځای کول;
• د پاکولو پروسه.

یادښتونه او احتیاطي تدابیر

1. بهرنۍ URL په ADD کې نه ملاتړ کیږي

اوس مهال دا په لارښود کې د بهرني URL کارولو ملاتړ نه کوي ADD. Werf به بیا رغونه پیل نکړي کله چې په ټاکل شوي URL کې سرچینه بدله شي. موږ پلان لرو چې دا فیچر ډیر ژر اضافه کړو.

2. تاسو نشئ کولی .git په عکس کې اضافه کړئ

په عمومي توګه خبرې کول، یو لارښود اضافه کول .git په عکس کې - یو ناوړه ناوړه عمل او دلته یې ولې:

1. که .git په وروستي عکس کې پاتې کیږي، دا د اصولو څخه سرغړونه کوي د 12 فکتور ایپ: څرنګه چې وروستی عکس باید د یوې ژمنې سره وصل شي، نو دا باید ممکنه نه وي git checkout خپلمنځي ژمنې
2. .git د عکس اندازه ډیروي (پوزیټوري د دې حقیقت له امله لوی کیدی شي چې لوی فایلونه یوځل پکې اضافه شوي او بیا حذف شوي). د کاري ونې اندازه یوازې د ځانګړي ژمنې سره تړاو لري په ګیټ کې د عملیاتو تاریخ پورې اړه نلري. په دې حالت کې، اضافه کول او وروسته لرې کول .git د وروستي عکس څخه به کار ونکړي: عکس به لاهم اضافي پرت ترلاسه کړي - دا دا دی چې ډاکر کار کوي.
3. ډاکر کولی شي غیر ضروري بیا رغونه پیل کړي ، حتی که ورته ژمنې رامینځته کیږي ، مګر د مختلف کاري ونو څخه. د مثال په توګه ، GitLab په جلا جلا کلون شوي لارښودونه رامینځته کوي /home/gitlab-runner/builds/HASH/[0-N]/yourproject کله چې موازي مجلس فعال شي. اضافي reassembly به د دې حقیقت له امله وي چې لارښود .git د ورته ذخیره کولو مختلف کلون شوي نسخو کې توپیر لري، حتی که ورته ژمنې جوړې شوې وي.

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

ټولیزه یوازې ځینې اړین فایلونه اضافه کول د لارښوونو له لارې ADD په هر حالت کې د لیکلو موثریت او اعتبار زیاتوي Dockerfile، او د دې لپاره راټول شوي کیچ ثبات هم ښه کوي Dockerfileپه Git کې غیر ضروري بدلونونو ته.

نتیجه

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

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

نو ، که تاسو ناڅاپه یو څو ډاکر فایلونه شاوخوا پراته وي ... هڅه وکړئ werf!

PS د موضوع په اړه د اسنادو لیست

• د چټک پیل لپاره لارښوونې;
• د ډاکر فایل جوړونکي تشکیلات;
• په werf کې د مرحلو وسیله;
• د انځور خپرولو بهیر;
• د Kubernetes د ځای پرځای کولو پروسې سره یوځای کول;
• د پاکولو پروسه;
• د ډاکرفایل د بدیل په توګه سټیپل جوړونکی.

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

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