د پیرودونکي په پلیټ فارم کې زموږ د دوامداره ګمارنې پلي کول

موږ په ریښتیني انجینرۍ کې د پیرودونکو سرورونو ته د دوامداره تازه معلوماتو رسولو لپاره پروسه جوړه کړې او غواړو دا تجربه شریک کړو.

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

پدې مقاله کې به موږ د دوامداره ګمارنې (CD) پروسې یا د پیرودونکي پلیټ فارم ته د تازه معلوماتو رسولو ټولو مرحلو په اړه وغږیږو:

1. دا پروسه څنګه پیل کیږي؟
2. د پیرودونکي Git ذخیره سره همغږي کول ،
3. د شاته او مخکینۍ برخې راټولول
4. د ازموینې چاپیریال کې د اتوماتیک غوښتنلیک ځای په ځای کول ،
5. د تولید لپاره اتوماتیک ځای پرځای کول.

موږ به د لارې په اوږدو کې د تنظیم توضیحات شریک کړو.

1. CD پیل کړئ

دوامداره ګمارنه د پراختیا کونکي سره زموږ د Git ذخیره خوشې څانګې ته د بدلونونو فشار ورکولو سره پیل کیږي.

زموږ غوښتنلیک د مایکرو سرویس جوړښت پرمخ ځي او د هغې ټولې برخې په یوه ذخیره کې زیرمه شوي. د دې څخه مننه، ټول مایکرو خدمتونه راټول شوي او نصب شوي، حتی که یو یې بدل شوی وي.

موږ د څو دلیلونو لپاره د یوې ذخیره کولو له لارې کار تنظیم کړ:

• د پراختیا اسانتیا - غوښتنلیک په فعاله توګه وده کوي ، نو تاسو کولی شئ په یوځل کې د ټولو کوډونو سره کار وکړئ.
• یو واحد CI/CD پایپ لاین چې تضمین کوي ​​​​چې غوښتنلیک د یو واحد سیسټم په توګه ټولې ازموینې تیریږي او د پیرودونکي تولید چاپیریال ته سپارل کیږي.
• موږ په نسخو کې ګډوډي له منځه یوسو - موږ اړتیا نلرو چې د مایکرو سرویس نسخو نقشه ذخیره کړو او د هر مایکرو سرویس لپاره د هغې ترتیب په هیلم سکریپټونو کې تشریح کړو.

2. د پیرودونکي سرچینې کوډ د Git ذخیره سره همغږي کول

جوړ شوي بدلونونه په اوتومات ډول د پیرودونکي Git ذخیره سره همغږي کیږي. هلته د غوښتنلیک مجلس تنظیم شوی ، کوم چې د څانګې تازه کولو وروسته پیل کیږي ، او دوام ته ګمارل کیږي. دواړه پروسې د دوی په چاپیریال کې د Git ذخیره څخه سرچینه اخلي.

موږ نشو کولی مستقیم د پیرودونکي ذخیره سره کار وکړو ځکه چې موږ د پراختیا او ازموینې لپاره خپل چاپیریال ته اړتیا لرو. موږ د دې موخو لپاره زموږ د Git ذخیره کاروو - دا د دوی د Git ذخیره سره همغږي کیږي. هرڅومره ژر چې یو پرمخ وړونکی پوسټ زموږ د ذخیره کولو مناسب څانګې ته بدل شي ، GitLab سمدلاسه دا بدلونونه پیرودونکي ته فشار ورکوي.

له دې وروسته تاسو اړتیا لرئ مجلس ترسره کړئ. دا څو مرحلې لري: شاته او مخکني مجلس، ازموینې او تولید ته سپارل.

3. د شاته او مخکینۍ برخې راټولول

د شالید او فرنټ اینډ جوړول دوه موازي دندې دي چې د GitLab رنر سیسټم کې ترسره کیږي. د دې اصلي مجلس ترتیب په ورته ذخیره کې موقعیت لري.

په GitLab کې د جوړولو لپاره د YAML سکریپټ لیکلو لپاره لارښود.

GitLab Runner د اړین ذخیره کولو څخه کوډ اخلي، دا د جاوا غوښتنلیک جوړونې کمانډ سره راټولوي او د ډاکر راجستر ته لیږي. دلته موږ شاته او مخکینۍ برخه راټولوو ، د ډاکر عکسونه ترلاسه کوو ، کوم چې موږ د پیرودونکي اړخ کې ذخیره کې ایښودو. د ډاکر عکسونو اداره کولو لپاره موږ کاروو Gradle پلگ ان.

موږ د خپلو عکسونو نسخې د خوشې شوي نسخې سره همغږي کوو چې په ډاکر کې به خپره شي. د اسانه عملیاتو لپاره موږ ډیری سمونونه کړي دي:

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

2. د هیلم له لارې د اپلیکیشن تازه کولو لپاره، تاسو باید د هغې نسخه مشخص کړئ. موږ بیک انډ ، فرنټ اینډ او اپلیکیشن تازه کوو - دا درې مختلف دندې دي ، نو دا مهمه ده چې د غوښتنلیک ورته نسخه هرچیرې وکاروئ. د دې کار لپاره، موږ د Git تاریخ څخه ډاټا کاروو، ځکه چې زموږ د K8S کلستر ترتیب او غوښتنلیکونه په ورته Git ذخیره کې دي.

موږ د کمانډ اجرا کولو پایلو څخه د غوښتنلیک نسخه ترلاسه کوو
git describe --tags --abbrev=7.

4. د ازموینې چاپیریال کې د ټولو بدلونونو اتوماتیک ځای پرځای کول (UAT)

د دې جوړ شوي سکریپټ بل ګام په اتوماتيک ډول د K8S کلستر تازه کول دي. دا واقع کیږي په دې شرط چې ټول غوښتنلیک جوړ شوی وي او ټول آثار د ډاکر راجستر ته خپاره شوي وي. له دې وروسته، د ازموینې چاپیریال تازه کول پیل کیږي.

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

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

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

5. په تولید کې د ټولو بدلونونو اتوماتیک ځای پرځای کول

د تولید چاپیریال ته د تازه کولو ځای په ځای کولو لپاره ، تاسو اړتیا لرئ په GitLab کې یوازې یو تڼۍ کلیک وکړئ - او کانټینرونه سمدلاسه د تولید چاپیریال ته سپارل کیږي.

ورته غوښتنلیک کولی شي په مختلف چاپیریالونو کې کار وکړي - ازموینې او تولید - پرته له بیا جوړونې. موږ په غوښتنلیک کې د هیڅ شی بدلولو پرته ورته اثار کاروو ، او موږ په بهر کې پیرامیټونه تنظیم کوو.

د غوښتنلیک ترتیباتو انعطاف وړ پیرامیټریزیشن په چاپیریال پورې اړه لري چیرې چې غوښتنلیک به اجرا شي. موږ د چاپیریال ټول ترتیبات بهر ته لیږدولي دي: هرڅه د K8S ترتیب او هیلم پیرامیټونو له لارې پیرامیټر شوي. کله چې هیلم د ازموینې چاپیریال ته مجلس ځای په ځای کوي ، د ازموینې تنظیمات پدې باندې پلي کیږي ، او د محصول تنظیمات د تولید چاپیریال کې پلي کیږي.

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

د غوښتنلیک ترتیبات د چاپیریال تغیرات کاروي. د دوی ارزښتونه د K8S configmap په کارولو سره په کانټینرونو کې تنظیم شوي ، کوم چې د Go ټیمپلیټونو په کارولو سره ټیمپلیټ شوی. د مثال په توګه، د ډومین نوم ته د چاپیریال متغیر ترتیب کول د دې په څیر ترسره کیدی شي:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

ارزښتونه.ګلوبل.env - دا متغیر د چاپیریال نوم ذخیره کوي (پروډ، مرحله، UAT).
.values.app.properties.app_external_domain - په دې متغیر کې موږ غوښتل شوي ډومین په .values.yaml فایل کې تنظیم کړو

کله چې یو اپلیکیشن تازه کوي، هیلم د ټیمپلیټونو څخه یو configmap.yaml فایل جوړوي او د APP_EXTERNAL_DOMAIN ارزښت د مطلوب ارزښت سره ډکوي په هغه چاپیریال پورې اړه لري چیرې چې د غوښتنلیک تازه کول پیل کیږي. دا متغیر لا دمخه په کانټینر کې تنظیم شوی. دا د غوښتنلیک څخه لاسرسی کیدی شي، نو د هر غوښتنلیک چاپیریال به د دې متغیر لپاره مختلف ارزښت ولري.

په نسبي ډول پدې وروستیو کې ، د K8S ملاتړ په پسرلي کلاوډ کې څرګند شو ، پشمول د configMaps سره کار کول: د پسرلي بادل Kubernetes. پداسې حال کې چې پروژه په فعاله توګه وده کوي او په بنسټیز ډول بدلون کوي، موږ نشو کولی دا په تولید کې وکاروو. مګر موږ په فعاله توګه د دې حالت څارنه کوو او د DEV ترتیبونو کې یې کاروو. هرڅومره ژر چې دا ثبات ومومي ، موږ به دې ته د چاپیریال متغیرونو کارولو څخه تیر کړو.

ټول

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

راتلونکي پلانونه: د اتوماتیک ډیټابیس مهاجرت

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

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

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

موږ پلان لرو چې د K8S دندې له لارې د ډیټابیس مهاجرت اتومات کړو ، دا د CD پروسې کې مدغم کړو. او موږ به خامخا دا تجربه په هابري کې شریک کړو.

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