بروزرسانی پروژه با CI/CD - قسمت دوم

از اونجایی که بنا دارم CI/CD رو با Docker و docker compose توضیح بدم، در صورتی که با داکر آشنایی ندارید، حتما قبلش قسمت اول رو بخونید.

در CI/CD ، هدف اینه که، توسعه دهنده بتونه بدون دسترسی مستقیم به سرور، پروژه ی خودش بروزرسانی بکنه. برای این منظور، اول از همه باید ببینیم چه کاری قراره دقیقا صورت بگیره. ما اینجا یک نماینده از repository خودمون روی سرور ثبت میکنیم. برای مثال فرض میکنیم پروژه مون روی gitlab قرار داره. پس باید یه gitlab-runner روی سرور خودمون ثبت کنیم. این رانر وظیفه داره که از جانب شما پروژه تون رو بیلد و ران کنه. برای نصب رانر گیت لب روی سرور لینوکسیتون از این لینک استفاده کنید:

https://docs.gitlab.com/runner/install/linux-manually.html

بعد از اینکه رانر رو نصب کردید، باید روی سرور یه رانر بسازید یا اصطلاحا، Register کنید. برای اینکار به آدرس زیر برید:

https://docs.gitlab.com/runner/register/

در مراحل ثبت نام از شما آدرس و token درخواست میکنه. برای اینکه این مقادیر رو بدید به runner، در پروژه ی گیت لبتون برید به این آدرس:

در این صفحه، قسمت runners رو expand کنید. و مطابق شکل زیر، آدرس و توکن مد نظر خودتون رو پیدا می کنید:

فقط در حواستون باشه، در مرحله ی آخر، وقتی ازتون میخواد executor رو مشخص کنید، حتما shell رو انتخاب کنید.

اگر مراحلی که در دو لینک بالا آمده رو درست انجام بدید، gitlab runner شما رجیستر و فعال میشه. از اینجا به بعد باید بریم سراغ پروژه و ببینیم در پروژه چه تنظیماتی رو باید انجام بدیم. اول از همه شما به یه فایل با نام gitlab-ci.yml. نیاز دارید. این فایل به صورت پیش فرض توسط گیت لب به عنوان فایل اجرایی Pipeline شناسایی میشه. مطابق قطعه کد زیر، این فایل رو استفاده کنید:

image: docker:latest
stages:
  - deploy

services:
  - docker:dind

deploy_production:
  stage: deploy
  script:
    - docker-compose -f docker-compose-production.yml up -d --build
  only:
    - master
  when: manual
  tags:
    - runner

در خط اول، معرفی میکنید که از آخرین ورژن داکر برای دیپلوی استفاده بشه. در قسمت stages ، بیان میکنید که قراره چه کاری صورت بگیره که خب ما میخوایم ورژن جدید رو دیپلوی کنیم. و در سرویس هم معرفی میکنیم که ابزار مورد استفاده ی ما docker هست.

هر قسمت از این فایل، باید یه نام داشته باشه. مثلا ما برای دیپلوی کردن پروژه ی جدیدمون، اسم deploy_production رو انتخاب می کنیم. هر اسمی رو انتخاب کنید، در قسمت Pipeline گیت بهتون نمایش داده میشه. در خط بعد، stage این قسمت رو مشخص میکنید، که برای کار ما میشه همون deploy.
خط بعد از شما میخواد، script هایی که قراره به ترتیب صورت بگیره رو بیان کنید. ما برای ران کردن پروژه و کمتر دردسر کشیدن، به جای استفاده ی مستقیم از docker، سعی می کنیم از docker-compose استفاده کنیم. وقتی اینکار رو میکنید، نیاز نیست ورژن قبلی رو stop کنید و به سرور بگید ورژن جدید رو run کن. خود رانر ، ورژن قبلی که با همین docker-compose نوشته شده رو براتون، با image جدید restart می کنه. پس در این قسمت بهش میگیم که فایل docker-compose ما رو که اسمش هست docker-compose-production.yml رو ران کنه. در نظر داشته باشید که حتما flag هایی که می بینید وجود داشته باشه. --build به docker-compose میگه که حتما یه بیلد جدید از پروژه بگیر.

قسمت بعدی only هست. این قسمت به رانر میگیم فقط روی برنچ هایی که لیست شدن حساس باش، اگر کامیت جدیدی روی این برنچ ها دیدی، یه رکورد جدید برای پایپلاین در نظر بگیر. ما اینجا حساسیت رو میزاریم روی master چون هدفمون بروزرسانی پروداکشن هست. اما میتونید با همین روش، روی develop هم Pipeline ست کنید.

قسمت when به رانر میگه که به صورتی دستی ، پایپلاین رو استارت کنه یا اتوماتیک. بدون هیچ سوالی، این رو بزارید روی manual. آفرین، سوال نپرسید :))

مهم ترین قسمت، همین tags هست. شما در این قسمت، tag ای که برای رانرتون روی سرور انتخاب کردین رو میدین و میگین من میخوام این رانر نماینده ی دیپلوی من باشه.

خب این قسمت تنظیمات ابتدایی فایل ci انجام میشه. در مرحله ی بعد باید بریم سراغ docker-compose و ببینیم اونجا چه تنظیماتی نیاز داره. به قسمت زیر دقت کنید:

version: '3.7'
services:
  production-test:
    build: .
    container_name: production-test
    restart: always
    environment:
      - NODE_ENV=production
    ports:
      - 8080:80

ورژن که مشخصه، توضیح نمی خواد.
در بخش services شما میتونید چندتا container رو یه جا معرفی کنید. اینکار باعث میشه بتونید با یه بار ران کردن ci، چندتا image مختلف رو ران کنید. این کار برای مواقعی که اپ شما روی پورت های مختلف و با ورژن های مختلف ران میشه مناسبه. ما فعلا همین یه ورژن رو میخوایم بسازیم.

خط بعد اسم container ما رو تعیین می کنه. ما اینجا اسمش رو میزاریم production-test

قسمت restart یک flag برای docker ست میکنه، به این صورت که اگر به هر دلیلی، پروژه به خطا خورد و استاپ شد، شما همینجوری الکی دوباره استارتش کن. در واقع ریستارتش کن.

در environment هر variable ای که نیازه در build تایم معرفی بشه، می تونید ست کنید. مثل همین NODE_ENV

قسمت آخر هم همون port ای هست که مقاله ی قبلی گفتم. اینجا یعنی پورت ۸۰ داخل داکر رو به پورت ۸۰۸۰ روی سرور مپ کن.

خب این هم از docker-compose. فقط در نظر بگیرید که داکر و داکر کامپوز، هر دو باید روی سرور نصب باشن.

وقتی این دو تا فایل رو به فایل های پروژه اضافه کنید، Dockerfile هم که از قبل موجوده. ترکیب تنظیمات مورد نیاز برای ران شدن Pipeline کامل میشه. حالا با هر کامیتی که میکنید و هر پوشی که روی مستر صورت میگه یه رکورد برای Play شدن در قسمت CI/CD => Pipelines اضافه میشه. مثل شکل زیر:

طریقه ی کار کردن این قسمت رو خودتون می تونید بخونید. وقتی Pipeline رو ران کنید و با موفقیت تا انتها بره، همچین لاگی رو میبینید:

این یعنی image شما ساخته شد و روی پورتی که تنظیم کردین ران شده. اگر تنظیمات وب سرور روی سرور اصلی، درست ست شده باشه، باید بتونید ورژن جدید رو روی آدرس دامنه دریافت کنید.

موفق باشید...