راه‌اندازی گیت‌لب با استفاده از داکر و استفاده از آن

کارگاه سوم داکرمی:

سلام روزتون بخیر. این متن سومین کارگاه آموزشی داکرمی می‌باشد که کلا دیگه به صورت آنلاین برگذار می‌شود. در این کارگاه قراره در مورد گیت‌لب و نحوه‌ی راه‌اندازی آن صحبت کنیم. برنامه‌ی کارگاه به این صورت است که ابتدا در مورد اینکه CI/CD چیست و چرا استفاده از آن باعث پایداری سرویس‌ ما می شود صحبت میکنیم. بعد از آن شروع به پیاده‌سازی GitLab با استفاده از داکر و برخی از کانفیگ‌های مهم آن خواهیم کرد. پس از آن gitlab-runner را راه‌اندازی می‌کنیم و سپس در مورد نحوه‌ی عملکرد آن صحبت می‌کنیم. بعد از پیاده‌سازی این دو تا موضوع روی گیت‌لب خود یک پروژه ایجاد می‌کنیم که برای آن با استفاده از gitlab-ci یک pipeline ساده آماده می‌کنیم.

این کارگاه قرار است که ۲۹ خرداد ماه روز پنج‌شنبه ساعت ۱۶ تا ۱۸ برگذار شود.

راستی گیت‌لب بیشترین رای رو در نظرسنجی سال ۹۹ داکرمی دریافت کرد که پیاده‌سازی بشه برای همین انتخابش کردیم.

خوبه که همراهمون باشید.

همه می‌توانند داکرمی رو حمایت کنند:

راستی پیرو پیگیری برخی از دوستان درگاه پرداخت برای حمایت مالی داکرمی آماده کردیم که می‌توانید اینجا و از داکرمی حمایت مالی کنید. حتما اگر توانش رو دارید از داکرمی حمایت کنید تا در پیشرفت آن سهیم باشید.

توضیح CI/CD چیست؟

حتما این چند وقته خیلی در مورد DevOps شنیدید و سازمان‌های خیلی بزرگی از این فرهنگ و راه و روش صحبت می‌کنند. DevOps به شما این امکان را می‌دهد که در یک چرخه‌ی مداوم پیشرفت قرار بگیرید و به صورت روز افزون خود را بهبود داده و همواره رو به رشد و پیشرفت باشید.

حالا CI/CD یکی از مهمترین موارد DevOps است که به شما این امکان را می‌دهد که فرآیند Build, Test و Deploy شما به خوبی پیش برود و تکرارپذیر شود. CI مخفف عبارت Continuous Integration و CD مخفف Continuous Delivery یا Continuous Deployment می‌باشد که تفاوت این دو در دیپلوی خودکار و اتوماتیک در سرورهای عملیاتی خواهد بود.

همان‌طور که مشخص است به ما این امکان را می‌دهد که بتوانیم به صورت مداوم فرآیند تولید نرم‌افزار، تست و پیاده‌سازی آن را به صورت کاملا خودکار و تکرارپذیر داشته باشیم.

به صورت خلاصه شما بعد از هر بار که کد خود را داخل مخزن کد ارسال کردید می‌توانید اقدامات مختلفی را انجام دهید. همان‌طور که در تصویر بالا اشاره شده است بعد از اینکه کد commit و push شد بعد از اعمال code review آن را build و سپس unit test و integration test از آن گرفته می‌شود و بعد از نهایی شدن این موارد که در CI انجام می شود، به سمت قسمت CD می‌رود که شامل staging (ایجاد آزمایشگاه همانند سرورهای عملیاتی با سایز کوچیک) و پیاده‌سازی در سرورهای عملیاتی می‌باشد. دقت کنید که می‌توان تست‌های متنوع‌تر و بیشتری نیز از محصول خود انجام داد که موارد دیگر رو هم پوشش دهد.

ضرورت استفاده از CI/CD:

استفاده از CI/CD به شما این امکان را می‌دهد که در سرورهای عملیاتی از وقوع اتفاقات ناگوار که منجر به Downtime خواهد شد، جلوگیری کرد و برای ما مزایای خیلی زیادی را به همراه دارد که به برخی از آنها اشاره می‌کنیم:

• جلوگیری از رخداد خطا در سرورهای عملیاتی
• انجام خودکار و اتوماتیک فرآیند‌ build, test و depoy
• مشاهده‌ی خطا در سرویس‌های تستی و مواجه با آن
• افزایش سرعت دیپلویمنت در پروداکشن و استیج
• می‌توانیم خیلی سریع‌تر Release بدیم
• اعمال تغییرات ما سریع‌تر است برای همین باعث افزایش رضایت مشتری می‌شود
• کم کردن Downtimeها و در نتیجه بالاتر بردن کیفیت سرویس
• بالاتر بردن کیفیت کارهای افراد تیم و کم کردن چالش‌های بین آنها
• کاهش چشمگیر هزینه‌های تغییر

و خیلی از مزایای دیگه که خودتون حتما سرچ کنید و در موردش بخونید. بهتون پیشنهاد می‌کنم این مقاله رو بخونید که خیلی خوب این موضوع رو توضیح داده.

چرا از GitLab استفاده کنیم؟

همان‌طور که می‌دونید ابزارهای مختلفی هستن که امکان CI/CD رو در اختیار ما قرار می‌دهند. حالا ما گیت‌لب رو انتخاب کردیم و این سوال پیش می‌آید که چرا از GitLab استفاده می‌کنیم در ادامه به برخی از این موارد اشاره میکنیم.

• متن باز هست و جامعه‌ی فعالی دارد
• یک‌پارچگی تمام موراد مربوط به DevOps رو می‌تونید در یک ابزار داشته باشید
• به شدت داکیومنت کامل و قابل دسترسی دارد و به راحتی می‌توانید مشکلات خودتون رو حل کنید
• امکانات زیادی رو برای پیاده‌سازی در اختیار ما قرار می‌دهد

تو سایت گیت‌لب می‌توانید تو این لینک مقایسه‌ی خوبی بین گیت‌لب و دیگر ابزارها داشته باشید که حتما پیشنهاد می‌کنم بررسی کنید.

مفهوم رانر:

همان‌طور که در تصویر بالا مشاهده می‌کنید سرویس گیت‌لب کنار خودش مفهومی ایجاد کرده است به نام رانر که با استفاده از آن به صورت کاملا تمام تسک‌ها و کارها را روی آن اجرا می‌کند و نتیجه‌ی آن به سمت گیت‌لب برگردانده می‌شود که این موضوع کمک می‌کند تا انجام تسک‌ها اختلالی در عملکرد سرویس اصلی ایجاد نکند. البته مزایای دیگری هم دارد که در این جا به همین نکته اکتفا خواهیم کرد. رانرها انواع مختلفی دارند که می‌توان برای کارهای مختلفی از آنها استفاده کرد.

می‌توانید اینجا اطلاعات کامل‌تری در مورد رانر بدست بیاورید.

نحوه‌ی راه‌اندازی سرویس GitLab:

برای راه‌اندازی سرویس گیت‌لب روش‌های مختلفی وجود دارد که ما در اینجا می‌خواهیم گیت‌لب را با استفاده از داکر راه‌اندازی کنیم. برای این کار نیاز داریم که یک داکر کامپوز داشته باشیم که قبلا من این رو ایجاد کرده ام که شما می‌تونید با استفاد از دستور زیر این فایل رو دریافت کنید.

git clone https://gitlab.com/scenario1/docker/gitlab.git

بعد از دریافت این پروژه داکر کامپوز آن را باز کنید و محتویات آن را بر حسب نیاز خودتون ویرایش کنید. این کامپوز فایل طوری نوشته شده که داخل سروری را‌ه‌اندازی می‌شود که یک reverse proxy همانند traefik اونجا وجود دارد و اینجا از آن استفاده می‌کند. اگر شما nginx یا traefik نداشتید به راحتی می‌تونید از این فایل استفاده کنید تنها باید پورت ۸۰ رو هم همانند ۲۲ پابلیش کنید و اینکه لیبل‌های مربوط به traefik را نیز حذف کنید.

بعد از دریافت کامپوز فایل "DOMAIN" داخل آن را به domain خودتون عوض کنید و بعد از بررسی و چک کردن فایل کامپوز آن را راه‌اندازی کنید. همان‌طور که در کامپوز فایل مشاهده می‌کنید یک کانتینر هم با عنوان gitlab-runner برای استفاده runner راه‌اندازی می‌شود.

با استفاده از دستور زیر می‌توانید فایل کامپوز رو بررسی کنید که مشکل syntax نداشته باشد:

docker-compose config

سپس با استفاده از دستور زیر آن را راه‌اندازی کنید.

docker-compose up -d

با استفاده از دستورهای زیر می‌توانید وضعیت کانتینرهای آن و لاگ آن را مشاهده کنید:

docker-compose ps

docker-compose logs -f

همان طور که مشاهده کردید کانتیر gitlab دارای health check می‌باشد از این رو باید صبر کنید که از وضعیت starting به وضعیت healthy تبدیل شود. بعد از این وضعیت سرویس گیت‌لب آماده‌ی استفاده می‌باشد.

بعد از اینکه سرویس گیت‌لب آماده‌ی استفاده شد با باز کردن صفحه‌ی آن در browser خود ابتدا می‌توانید پسورد مربوط به root رو مشخص کنید. بعد از آن می‌توانید با همان یوزر root لاگین کنید و وارد سرویس گیت‌لب شوید.

حالا سرویس شما آماده‌ی استفاده می‌باشد.

نحوه‌ی رجیستر Gitlab-runner:

بعد از اینکه دو تا کانتینر ما به خوبی راه‌اندازی شدند و سرویس گیت‌لب آماده‌ی سرویس دهی شد ابتدا گیت‌لب رانری که ایجاد کردیم را به اصطلاح داخل گیت‌لب رجیستر می‌کنیم.

برای این کار دو تا داده‌ی مهم رو باید داشته باشیم. اول اینکه یک token برای رجیستر شدن رانر نیاز داریم و سپس domain گیت‌لب خودمون که دومی به راحتی در دسترس است و برای پیدا کردن اولی باید به مسیر زیر مراجعه کنیم.

Admin Area --> Overview --> Runner

اینجا هم token و هم url مشخص است و ما می‌توانیم آنها را کپی کنیم. بعد از اینکه این اطلاعات رو داشتیم، با استفاده از دستور زیر گیت‌لب رانر ایجاد شده را داخل گیت رجیستر می‌کنیم.

docker exec -it runner \
  gitlab-runner register \
    --non-interactive \
    --registration-token GITLAB_TOKEN \
    --locked=false \
    --description docker-stable \
    --url GITLAB_DOMAIN \
    --executor docker \
    --docker-image docker:stable \
    --docker-volumes &quot/var/run/docker.sock:/var/run/docker.sock&quot

دقت کنید که GITLAB_TOKEN و GITLAB_DOMAIN را با اطلاعات خودتون جایگذاری کنید.

بعد از اعمال این دستور شما مشاهده خواهید کرد که در قسمت Runner یک رانر جدید به آن اضافه شده است. حالا در صورتی که شما یک پروژه ایجاد کنید و در آن pipeline داشته باشید می‌تواند تسک‌های خودش رو روی این Runner اجرا نماید.

نوشتن gitlab-ci برای پروژه و ایجاد pipeline:

برای نوشتن یک gitlab-ci دونستن این موارد ضروری است:

مفهوم job: کاری که ما انتظار داریم انجام شود را می‌گویند.

مفهوم stage: هر job می‌تواند در یک stage اجرا شود. می‌تواند jobهای داخل یک stage به صورت همزمان اجرا شوند.

مفهوم pipeline: یک چتری بالای سر job و stage می‌باشد. که تمام jobها و stageها تحت یک pipeline قرار می‌گیرند.

ایجاد یک pipeline با استفاده از gitlab-ci.yml

حالا ما می‌خواهیم یک pipeline ایجاد کنیم که داخل آن تعدادی stage به همراه تعدادی job خواهد بود.

برای ایجاد pipeline داخل سرویس گیت‌لب می‌بایست یک فایل yaml ایجاد کنیم که داخل آن می‌توانیم به صورت کامل شرح دهیم که چه pipeline را نیاز داریم و در stage چه jobهایی ایجاد و راه‌اندازی شوند.

اطلاعات کامل مربوط به ایجاد pipeline و نحوه‌ی کار با آن را می‌توانید اینجا ببینید و از آن استفاده کنید.

ما در این سناریو یک سرویس mysql در حال کار داریم که در stage اول که ایجاد backup می‌باشد از آن backup گرفته خواهد شد و در stage دوم آن را بر روی یک رانر restore می‌کنیم و چند تا query تست خواهیم زد که از صحت restore شدن آن اطمینان پیدا کنیم

فایل مربوط به gitlab-ci.yml را در ادامه مشاهده می‌کنید که می‌توانید آنرا از اینجا نیز دریافت کنید.

stages:
  - backup
  - restore

variables: 
  MYSQL_USER: wordpress
  MYSQL_PASSWORD: salamdonya

create_backup:
  stage: backup
  image: docker:stable
  tags:
    - dind
  script:
    - docker exec -i db_dockerme mysqldump -u$MYSQL_USER -p$MYSQL_PASSWORD wordpress -r /tmp/DockerMe-Mysql.sql
    - docker cp db_dockerme:/tmp/DockerMe-Mysql.sql .
  only:
    - master
  artifacts:
    paths:
      - ${PWD}/DockerMe-Mysql.sql

test_backup:
  stage: restore
  tags:
    - dind
  before_script:
    - apk add --no-cache bash curl
  script:
    - bash Mysql-restore.sh
  only:
    - master

در ابتدا معرفی stageها را خواهیم داشت که در این مثال دو تا stage داریم.

stages:

- backup

- restore

ترتیب stageها در pipeline به ترتیب قرارگیری آنها در اینجا بستگی دارد.

create_backup:

پس از آن ما variables‌های خود را تعریف کرده‌ایم که این variableها در کل pipeline ما معتبر می‌باشد

variables:

MYSQL_USER: wordpress

MYSQL_PASSWORD: salamdonya

نکته‌ی مهم: این سرویس‌ها داخل یک سرور private و بدون هیچ دسترسی از بیرون راه‌اندازی شده است از این رو پسوردها به صورت ساده انتخاب شده. تحت هیچ شرایطی از این نوع پسوردها در سرورهای عملیاتی خود استفاده نکنید زیرا به راحتی دچار مخاطره شده و به آن نفوذ می‌شود.

پس از آن نوبت به ایجاد job و موارد پیرامون آن می‌باشد که توضیحات آنها به صورت زیر است

نام job که در ابتدای آن قرار داده شده است.

create_backup:

سپس stage که job در آن اجرا می‌شود مشخص می‌گردد.

stage: backup

پس از آن اگر از رانر داکر برای انجام پروژه استفاده شده باشید اینجا می‌توان ایمیج آن را مشخص کنیم که از چه ایمیجی استفاده کند. در مثال ما از ایمیج docker:stable استفاده شده است.

image: docker:stable

سپس با استفاده از tag می‌توانیم مشخص کنیم که job ما در چه stage راه‌اندازی و اجرا شود. که نام‌گذاری آن کاملا بر اساس سلیقه‌ی ما می‌باشد و ما می‌توانیم به این صورت مدیریت کنیم که job ما در چه stage اجرا شود.

tags:

- dind

حالا نوبت کاری است که می‌خواهیم داخل این job انجام دهیم. این موضوع با script مشخص می‌شود که برای این کار ما before_script و after_script را برای استفاده داریم. معمولا از آنها برای اماده‌سازی رانر قبل از اجرا script و پاک‌سازی رانر بعد از اجرای آن استفاده می‌شود. در این قسمت می‌توان یک script را فراخوانی کرد که طی آن دستورالعمل‌های متعددی را اجرا نماید.

script:
    - docker exec -i db_dockerme mysqldump -u$MYSQL_USER -p$MYSQL_PASSWORD wordpress -r /tmp/DockerMe-Mysql.sql
    - docker cp db_dockerme:/tmp/DockerMe-Mysql.sql .

می‌توان به صورت کامل مشخص کرد که بعد از push داخل کدام branch این job اجرا شود که در این مثال ما master را برای این کار انتخاب کرده‌ایم.

only:

- master

به صورت کلی هیچ ارتباطی بین stageهای مختلف در یک pipeline وجود ندارد و اگر قرار است فایل‌ یا لاگ‌ و یا هرچیز دیگری از یک stage به stage دیگری منتقل شود می‌بایست ابتدا در stage قبلی به artifacts تبدیل شود و در stage بعدی آن را فراخوانی کند. به صورت پیش‌فرض هر artifacts زمان انقضا دارد که تقریبا یک ماه می‌باشد که می‌توان زمان آن را کم و یا زیاد کرد و یا اینکه کلا گفت دیگه این artifacts منقض نشود.

artifacts:

paths:

- ${PWD}/DockerMe-Mysql.sql

البته می‌تواند ترتیب قرارگیری این موارد متفاوت باشد.

بعد از نگارش فایل gitlab-ci خود می‌توانید آن را با استفاده از checkerهای که وجود دارد و خود گیت‌لب هم یک ابزار خوب برای این کار دارد بررسی کنید که خطای syntax نداشته باشید.

بعد از این مرحله هر زمانی که این فایل را داخل پروژه خود push کنید pipeline شما ایجاد می‌شود که می‌توانید ان را در مسیر زیر مشاهده کنید.

CI / CD ---> Pipeline

و اگر بر روی ان کلیک کنید می‌توانید jobهای داخل ان را نیز مشاهده کنید.

در صورتی که نیاز داشتید تا این پروژه‌ی تستی را در اختیار داشته باشید می‌توانید از مسیر زیر آن را دریافت کنید که شامل فایل gitlab-ci و اسکریپت restore می‌باشد.

در اولین فرصت ویدئوی کارگاه سوم داکرمی که پیاده‌سازی این سناریو می‌باشد در اینجا قرار داده می‌شود.