جوابی که مدیر شرکت در جویای عدم درگیری و وجود اختلاف بکندکار و فرانتکار میگیره


جدا از طنز دو کارگردان وودی آلن و کریستوفر نولان شاهکار هستند


#fun

@code_crafters

برای بررسی لاگ‌ها در سرور معمولا دو ابزار قدرتمند وجود دارد grafana loki و ELK

در ریپوی مربوط به grafana که در گیتهاب کانال با عنوان sysadmin_monitoring موجود می باشد، loki رو داکرایز کردیم و با ابزارهای دیگه و پلتفرم‌های دیگه میتونید بالا بیارید

در این ریپو هم ELK رو داکرایز و کانفیگ کردم
که با کلون کردنش میتونید ازش استفاده کنید یک فایل زیپ شده هم برای تمرین و تست گذاشتم براتون

خب بین دو پلتفرم loki و ELK کدوم رو اسفاده کنیم؟؟؟
پلتفرم loki برای پروژه‌های متوسط و سرورهای معمولی مناسب هست ELK هم برای سیستم‌های بزرگ و معمولا میکروسرویسی

خود ELK مخفف elastic logstash kibana هستش

لینک ریپو رو در زیر براتون گذاشتم

https://github.com/CodeCrafters-ir/ELK.git


#devops
#monitoring

@code_crafters

وقتی ربات رو‌ جهت تست روی هاست مشتری اجرا میکنی ، و همون لحظه مشتری پسورد یوزر هاست رو تغییر میده


#fun

@code_crafters

از خاطرات دنیای فریلنسری بهتون بگم

یبار یک‌ موتور جستجوی تصویر برای مشتری نوشتم با opencv که مبلغش بالا بود

کدهارو جهت تست روی سرور گذاشتم و بعد از گرفتن اولین خروجی ،مشتری پسورد رو تغییر داد و من رو بلاک کرد

اما من یک باگ داخل کدهام گذاشته بودم متاسفانه که باعث شد یکماه مشتری التماسم کنه

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


اول اینکه نوع پایتون رو هم خودش براتون بالا میاره حین ساخت محیط و شما دیگه درگیر پیچیدگی و هندل کردن نصب و مدیریت چند نسخه مختلف پایتون نمیشید و حتی کار کردن باهاش از pyenv راحت تره و عوض کردن نسخه پایتونش هم راحت تره

conda create -n MyENV python=3.8

دوم اینکه محیطی که براتون میسازه رو داخل home شما و در دایرکتوری مخصوص خودش میسازه و نه در مسیر جاری شما خب این مزیتش این هست که شما راحت هرجا باشید میتونید ۱-سریع فعال و ۲-غیرفعال و یا محیط خودتون رو تغییر بدید و یا بدون دغدغه نسبت به محل قرارگیریش محیط جدید بسازید و ۳-حذف هم کنید و بین محیط‌های مختلف راحت سویچ کنید

1- conda activate my_env

2- conda deactivate

3- conda env remove -n MyENV

مورد بعدی هم اینکه:
۱-نصب پکیج هم داخلش راحته
۲-و علاوه بر خودش میتونید از pip هم استفاده کنید
۳- همچنین بروز رسانی پکیج

1- conda install PackName

2- pip install PackName

3- conda update PackName

۱-لیست پکیج‌های نصب شده رو هم میتونید ببینید
۲-و یا یک فایل حاوی ادرس‌های آن جهت نصب بسازید
۳-و یا بصورت yaml براتون قرار میده که از دو بخش تشکیل شده پکیج‌هایی که خودش نصب کرده و پکیج‌هایی که با pip نصب شده

1- conda list

2- conda list --explicit

3- conda env export  > requirements.yml

که بالطبع میتونید اون رو هم در یک محیط دیگه نصب کنید

conda create -f requirements.yml

conda create -n MyENV -f requirements.yml

گفتیم همه محیط‌ها رو در یک مسیر قرار میده که با دستور زیر هم میتونید لیست همه محیط هاتون رو ببینید

conda env list

۱- اگه بخواید یک‌محیط رو‌حذف کنید ۲-یا یک پکیج رو حذف کنید

1- conda env remove -n MyENV --all

2- conda remove PackName

برای دیدن اطلاعات مربوط به محیط تون

conda info

جهت تست و بررسی سلامت محیط

conda doctor

جهت تغییر نام محیط با شرط فعال نبودن محیط تون(فراموش نکنید conda یک محیط base داره که با دستور اولی فعال میشه)

conda activate

conda rename -n OldName NewName

۱-جستجوی پکیج با نمایش تاریخچه تگ آن
۲-مشاهده وابستگی های آن
۳-مشاهده پکیج‌ها استفاده کننده آن

1- conda search PackName

2- conda repoquery depends PackName

3- conda repoquery whoneeds PackName

ادغام محیط شل با conda

conda init bash

پاک کردن پکیج‌های نا استفاده

conda clean

برای کانفیگ از قبیل محیط نصب، پکیج‌ها محدودیت دانلود و ...

conda config

conda config --help

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


داخل کامنت ها هم نحوه نصبش رو در اوبونتو میزارم

#conda
#pip
#env

@code_crafters

خب بریم سراغ داکرایز کردن پروژه با conda

عجله نکنید
بیاید قبلش یکم راجب محیط‌های conda حرف بزنیم و بیشتر باهاش آشنا بشیم و درک‌ کنیم conda چجوری باهاش کار میکنه


نکته هنگام نصب conda یک‌ محیط خودش بصورت پیش فرض میسازه با نام base

با دستور زیر میتونید محیط‌ها رو ببینید

conda env list

این رو فراموش نکنید خیلی بکارمون میاد بعدا


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

conda env create -n venv

conda activate venv

conda install django

حالا ما یک‌ محیط با اسم venv داریم و یکسری پکیج داخلش نصب هست


میدونیم با دستور زیر یک فایل که حاوی پکیچ‌ها هست رو میسازیم

conda env export > requirements.yml

خروجی اون بشکل تصویر خواهد بود(تصویر رو در کامنت براتون میزارم حتما ببینید و بعد ادامه بدید)
خط آخر رو پاک کنید یعنی prefix

حال اگه بخوایم این فایل رو‌ مجدد نصب کنیم خطا میده

conda env create -f requirements.yml

چرا؟؟؟
خط اول رو ببینید مقدار name این دقیقا اسم محیطمون هست

نکته conda میاد هم محیط رو میسازه و هم پکیچ‌هاش رو نصب میکنه

قبلا گفتیم conda تمام محیط‌ها رو در یک مسیر خاص قرار میده و‌ میسازه (این مسیر کجاست مقدار prefix انتهای فایل که گفتیم پاک‌ کنید) و خوب ما نمیتونیم دوتا محیط با یک اسم داشته باشیم (اگه محیط قبلی رو حذف کنید و دستور رو بزنید اجرا میشه) یا یکار باحال‌تر مقدار name رو داخل فایل بصورت دستی تغییر بدید و دستور رو بزنید باز هم کار خواهد کرد

تنها نکته باید بدونید این هست محیط تکراری نمیتونیم داشته باشیم، در ابتدای فایل اون name در واقع اسم محیطمون هست

اگه ما بخوایم پکیچ‌های این فایل رو در یک محیط دیگه نصب کنیم چکاری باید انجام بدیم؟؟؟

تصور کنید ما یک محیط دیگه با نام test داریم و میخوایم پکیچ‌های فایل requirements.yml رو‌ داخلش نصب کنیم

داخل همین فایل مقدار name رو به test(اسم‌ محیط مقصدمون) تغییر میدیم و دستور زیر رو میزنیم

conda env update -f requirements.yml

میره و این پکیج‌هارو در محیط test که داریم نصب میکنه داخلش


چیارو‌فهمیدیم؟؟؟

یک‌ محیط داریم همیشه با اسم base 

وقتی فایل requirements.ymlرو‌ میسازیم قسمت prefix رو‌ پاک میکنیم و کنترل کردن مقدار name در فایل خیلی مهم هست که بتونیم با دستورات create و update کار کنیم

نمیتونیم محیط با اسم تکراری داشته باشیم

و اینکه conda با دستور create محیط رو هم برامون میسازه و با دستور update به محیطی که داریم وصل میشه

حالا که محیط ها رو درک کردیم و فهمیدیم conda چجوری باهاشون رفتار میکنه ذره ذره آماده میشیم برای قدم اصلی

#conda
#pip
#env

@code_crafters

خب برسیم به قسمت جالب کار چطور از conda داخل داکر استفاده کنیم

سناریو از این قرار هست ما یک محیط ساخته و میخوایم الزامات راه اندازی جنگو رو داشته باشیم

conda env create -n venv python=3.10 django gunicorn gevent

conda activate venv

django-admin startproject config .

conda env export > requirements.yml

بریم واسه داکرایز کردنش

اول از همه ایمیج مدنظرمون رو از داکرهاب میگیریم

docker pull continuumio/miniconda3

ما ایمیج رو گرفتیم و داخل Dockerfile ازش استفاده میکنیم

این ایمیج محتوی conda و python3.11 هست هر دو رو داخل خودش داره

ما میخوایم پکیج‌های خودمون رو که داخل فایل requirements.yml هست نصب کنیم

میدونیم از دوتا دستور میشه استفاده کرد

conda env create -f requirements.yml

conda env update -f requirements.yml

اولی محیط رو هم برامون ایجاد میکرد
دومی روی یک محیط از قبل موجود پکیج‌هارو نصب میکرد

تو پست قبل بهتون گفتم یادتون بمونه که conda همیشه خودش یک محیط درست میکنه با اسم base

تو ایمیجش هم این ماجرا صحت داره پس ما میتونیم که از دستور دومی استفاده کنیم

منتها یک قاعده داشتیم اون هم این بود مقدار name در فایل requirements.yml رو به base تغییر بدیم

با فرض بر این که میخوایم یک اپلیکیشن جنگویی ساده رو بالا بیاریم داکرفایل رو مینویسیم

پس داکر فایل ما به شکل زیر خواهد بود

FROM continuumio/miniconda3
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
WORKDIR /code
COPY . /code/
RUN /bin/bash -c "conda env update -f requirements.yml"
EXPOSE 8000

خب ادامه بدیم و یک داکر کامپوز ساده هم بنویسیم براش

ما داریم از gunicorn با gevent استفاده میکنیم و برای اجرای اپ جنگویی لازم هست که دستور مربوطه رو در شل کانتینر اجرا کنیم

اما سوال پیش میاد ما الان پکیج‌هامون رو داخل محیط base داریم و شل هم یجای دیگه کار میکنه خب چطور اینارو باهم ارتباط بدیم

در پست اول راجب conda یک دستور خوندیم

conda run 

کارش هم این بود که دستور شل رو با یک محیط conda ترکیب کنه

نکته جالب هروقت جایی لازم بود داخل دستور conda محیط رو مشخص کنید با سویچ n myenv- و اینکار رو نکنید conda پیش فرض محیط base رو در نظر میگیره

جالب شد همین کار مارو راه میندازه

حالا یک داکر فایل ساده مینویسیم

version: '3'

services:
  conda:
    build: .
    image: conda-test
    hostname: conda
    container_name: conda
    restart: on-failure
    command: sh -c "conda run gunicorn -k gevent --workers 4 config.wsgi:application -b 0.0.0.0:8000"
    expose:
      - 8000
    ports:
      - 8000:8000

حالا بریم واسه اجرا کردنش

docker compose up -d

یکم صبر کنید تا کار تموم بشه

docker ps

docker logs conda

کانتینر در حال اجراست و لاگ هم اروری نداریم بریم داخل کانتینر یچیز جالب رو باهم نگاه کنیم

docker exec -it conda bash

python

چه چیزی رو میبینید؟؟؟
پایتون نسخه 3.10 مگه ما اول کار نگفتیم این ایمیج پایتون نسخه 3.11 هست

درسته داخل دپندنسی فایل requirements.yml هر نسخه از پایتون باشه conda وضعیت رو تغییر میده برامون


حالا از پایتون بیایم بیرون و پکیج هارو نگاه کنیم

conda env list

همه پکیج‌ها نصب هستش

کار تمومه کانتینر ما داره کار میکنه و تونستیم با درک شیوه کار کرد conda کارمون رو راه بندازیم

یک سوال ازتون میپرسم اگر ما مقدار name در فایل requirements.yml رو به base تغییر ندیم شیوه کاریمون چجوری میشد؟؟؟


#conda
#pip
#env

@code_crafters

امیدواریم هرچه سریعتر سیستم مالیاتی جامع کشوری راه اندازی بشه و در کنارش سیستم نظارت بر درآمدزایی هم رشد کنه

با این واقعیت کنار بیاید که سیستم مالیاتی به نفع همه و بالاخص قشر ضعیف و دهک پایین جامعه خواهد بود، بخودتون سخت نگیرید شما بعنوان کارمند نهایتا در ازای هر ده میلیون تومن فراتر از پایه حقوق ده میلیون تومن یک میلیون مالیات خواهید داد

چیزی از جیب شما کم نخواهد شد اما در مقابل افراد با درامد ناسالم شناسایی میشن ،هرکسی از روی هوا و کارهای ضد اجتماعی مثه فروش مواد مخدر پولدار نخواهد شد


از سیستم یکپارچه مالیات کشوری حمایت کنید و امیدوارم طرح بعدی سیستم نظارت جامع بر املاک و مستقلات کشوری راه اندازی بشه

قابلیت TTL در MongoDb: راه حلی ساده و هوشمندانه برای مدیریت اطلاعات موقتی

ذخیره سازی اطلاعات موقتی، چالشی همیشگی در برنامه نویسی بوده است.

دو راه حل رایج برای این چالش عبارتند از:

استفاده از Redisو Session: که برای ذخیره سازی داده های کوتاه مدت مانند اطلاعات مربوط به سشن کاربر مناسب است.
ساخت مدل و حذف دوره ای با cron job: که برای داده های موقتی که نیاز به ساختار پیچیده تری دارند، مانند سبد خرید، مناسب است.

اما راه حل سومی هم وجود دارد که ساده تر و کارآمدتر است: TTL در MongoDb

در واقع TTL مخفف Time To Live است و به قابلیتی در MongoDb اشاره می کند که به شما امکان می دهد اسناد را پس از گذشت زمان مشخصی به طور خودکار حذف کنید.

مزایای استفاده از TTL:

حذف خودکار اطلاعات: دیگر نیازی به نوشتن کد برای حذف دستی اطلاعات منسوخ نیست. TTL این کار را به طور خودکار برای شما انجام می دهد.
کاهش حجم داده ها: با حذف خودکار اطلاعات غیرضروری، فضای ذخیره سازی پایگاه داده شما آزاد می شود.
افزایش کارایی و عملکرد: حذف خودکار اطلاعات، بهینه سازی و سرعت بخشیدن به عملکرد پایگاه داده شما کمک می کند.

معایب استفاده از TTL:

پیچیدگی جزئی کد: استفاده از TTL نیازمند ایجاد ایندکس TTL روی فیلد زمانی است. (مثلا یک فیلد با اسم CreateAt از DateTime)
مصرف رم و CPU: حذف خودکار اطلاعات به طور مداوم، می تواند رم و CPU بیشتری را مصرف کند. (البته خوب استفاده از cron job هم همین استفاده بیشتر از رم و CPU را میخواهد)

در کل TTL در MongoDb راه حلی ساده و کارآمد برای ذخیره سازی اطلاعات موقتی است.

با وجود معایبی مانند پیچیدگی جزئی کد و مصرف رم و CPU، مزایای TTL مانند حذف خودکار اطلاعات، کاهش حجم داده ها و افزایش کارایی و عملکرد، آن را به انتخابی ایده آل برای بسیاری از برنامه ها تبدیل می کند.

برای کسب اطلاعات بیشتر از لینک زیر استفاده کنید :
https://www.mongodb.com/docs/manual/core/index-ttl/

#mongodb
@Code_Crafters

داکر ، پلتفرم اوپن سورسی که به ما در توسعه دادن (Develop) ، انتقال دادن (Ship) و اجرا (Run) کمک میکنه، یکی از فواید داکر ، ایزوله سازی اپ ها هستش این بدین معنی است که شما میتوانید اپ های خود را مستقل از سیستم عامل اجرا کنید.

🔆 ساختار داکر چگونه است؟

🔅 داکر دارای یک هسته و دو Application می باشد ، داکر کلاینت و داکر Cli ، که هردو آنها به هسته یعنی Docker-Daemon درخواست میدهند ، اگر شما میخواید یک ایمیج را Pull کنید یا حتی یک ایمیج را اجرا کنید ، باید به هسته دستور اجرا شدن را بدید. نوع ارتباط بین کلاینت و هسته با Rest Api می باشد.


🔆 ماشین مجازی یا داکر؟

🔅داکر بر خلاف ماشین مجازی (Virtual Machine) نیازی به Hypervisor ندارد و کانتینر شمارو بصورت مستقیم روی سیستم عامل و همچنین با پراسس جدیدی اجرا میکند که باعث سبک تر بودن اپ (چه از لحاظ مصرفی و چه از لحاظ سرعت ) نسبت به ماشین مجازی میشود.


🔆 اپ ما چگونه در داکر اجرا میشود؟

🔹 1- در ابتدا شما باید بوسیله ی Docker Image یک ایمیج برای خودتون بسازید ، این ایمیج خود ، ساختار چند لایه دارد ، اپ شما و ایمیج های دیگر استفاده شده بصورت جدا جدا گرفته و در مجموع یک ایمیج را شکل میدهند.

🔸2 - بعد از ساختن ایمیج ، شما میتوانید آن را اجرا کنید ، داکر قابلیت اجرای چندین Instance از یک ایمیج را دارد که آن هارا بصورت کانتینر از هم مجزا میکند. که این یعنی شما میتوانید 4 پراسس از یک اپلیکیشن را اجرا کنید.

🔹3 - همانطور که در مورد دوم گفته شد ، شما بعد از اجرای ایمیج خود در اصل یک کانیتنر می سازید ، این کانتینر بصورت کاملا ایزوله از ایمیج ساخته میشود و بصورت پراسس اجرا میشود اینجوری تمامی تغییرات اعمال شده در کانتینر روی ایمیج تاثیری نمیزارد.


♦️ داکر سرویس ، یک ابزار برای مدیریت چندین کانیتنر بصورت همزمان است ، همچنین با داکر سرویس میتوانید از قابلیت های داکر Swram نیز استفاده کنید که در پست های آینده راجب آن توضیح میدهیم.

#Docker
#Guide
#Beginner

@code_crafters

خب بیاید راجب یک‌ موضوع دیگه خیلی سریع در چند پست باهم بررسی و یاد بگیریم


اتومیشن کردن پروژه (ما از یک پروژه جنگویی استفاده میکنیم اما جز در قسمت داکرایز کردن آن تفاوتی در سایر مراحل ندارد)در گیتهاب با استفاده از github actions


خب قبل از هرچیزی بیایم سناریویی که میخوایم انجام بدیم رو با هم بچینیم و پیاده سازیش کنیم


ما یک اپلیکیشن داریم که داخل گیتهاب در ریپوزیتوری خصوصی با نام test-action قرار دادیم


دوتا سرور داریم

یک سرور جهت تست با نام server-develope
یک سرور جهت اجرا با نام server-production

ما از رانر خودمون استفاده میکنیم که کار کردن و تنظیم کردن اون رو هم یاد بگیریم

دوستانی که سرور ندارن میتونن از environment خود گیتهاب جهت تست و تمرین استفاده کنن

سناریو به چه شکل خواهد بود
ما پروژه رو با داکرایز کردن پیاده سازی میکنیم پس در هر دو سرور تست و اجرا با این رویکرد پیش خواهیم رفت

در مبحث مربوط به cd برای سرور تست delivery و برای سرور اجرا deployment پیش خواهیم رفت

چرا از دو رویکرد برای cd استفاده میکنیم

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

خب ما یک پروژه با جنگو رو شروع میکنیم

conda env create -n tetstaction-venv python=3.10 django gunicorn gevent

conda activate tetstaction-venv

mkdir my_project 

cd my_project

django-admin startproject config .

داکرایز کردن آن:
در همان مسیر دایرکتوری my_project

nano Dockerfile

مقدار زیر را داخل آن بزارید

FROM continuumio/miniconda3
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
WORKDIR /code
COPY . /code/
RUN /bin/bash -c "conda env update -f requirements.yml"
EXPOSE 8000

فایل داکرکامپوز

nano docker-compose.yml

محتویات آن

ser version: '3'

services:
  conda:
    build: .
    image: conda-test
    hostname: conda
    container_name: conda
    restart: on-failure
    command: sh -c "conda run gunicorn -k gevent --workers 4 config.wsgi:application -b 0.0.0.0:8000"
    expose:
      - 8000
    ports:
      - 8000:8000

خب تا اینجای کار آماده شدیم

دوتا سرور تست و اجرا داریم

یک پروژه جنگویی داریم

اون رو داکرایز کردیم

و در یک ریپوی خصوصی گیتهاب گذاشتیم

از پست بعد بریم سراغ github action


#git
#actions


@code_crafters

خب میریم سراغ رانرهامون

اینکه رانر چیه و توضیحات مربوط به اون رو برید از Gemini گوگول بپرسید از تعاریف عبور می‌کنیم

ما دو نوع رانر داریم

رانر میزبانی شده توسط گیتهاب(اگه سرور ندارید میتونید ازین مورد استفاده کنید)
رانر خود میزبانی شده که بهش self hosted میگیم و روی سرور بالا میاریم(میتونید روی لپتاپ خودتون هم بالا بیارید)

به اکانت خود و ریپوی مدنظرتون برید و مسیر زیر رو دنبال کنید
Settings > Actions > Runners > New self-hosted runner

در کامنت‌ها تصویر اول رو ببینید

تو این صفحه دستورالعمل مربوط به اجرا کردن رانر را میبینید مطابق آن پیش بروید من از سیستم عامل لینوکس بهره میبرم

در کامنت‌ها تصویر دوم را ببینید


دستورات مربوطه در این صفحه با حفظ نکته زیر در سرور server-developer اجرا کنید

در بخش configure هنگام اجرا کردن بش اسکریپت config.sh/. موارد رو مطابق زیر پر کنید

دستور اول مربوط به ساخت دایرکتوری می باشد در هر مسیری که دوست دارید آنرا اجرا کنید و بخاطر بسپارید تمامی دستورات ما جهت پیکربندی رانر در این مسیر این دایرکتوری انجام خواهیم داد 

در مرحله اول کلید enter را بزنید تا پیش فرض بماند

در مرحله دوم هم مقدار server-developer را وارد کنید

در مرحله بعدی لیبل server-developer را وارد کنید

در مرحله بعدی کلید enter را بزنید 

رانر ما اکنون آماده کار میباشد

دستور زیر را بزنید تا رانر شروع بکار کند

./run.sh

اکنون صفحه گیتهاب خود در مسیر زیر را اگر رفرش کنید با تصویر سوم در کامنت ها روبرو میشید

Settings > Actions > Runners


یک رانر با نام و برچسب server-developer می بینید این یک self-hosted هست این نام رو فراموش نکنید


نکته قابل توجه:
دستور run.sh/. ترمینال رو مشغول نگه داشته و اگه این دستور رو خاتمه بدید و به همان صفحه رانرها برگردید میبینید که رانر به حالت offline رفته

ما باید رانر رو به یک سرویس تبدیل کنیم تا همیشه به حالت کار قرار گیرد دستورات زیر را در همان مسیر دایرکتوری که رانر در ان قرار دارد اجرایی کنید (actions-runner) اجرایی کنید

sudo ./svc.sh install

systemctl start action<کلید tab را جهت کامل کردن بزنید>

اکنون اگر بجای start در دستور دوم بالا مقدار status را بزارید میبینید که رانر ما بصورت سرویس بالا آمده و در حال اجرا قرار گرفته است

برای سرور server-deployment به همان صفحه رانرها رفته و یک رانر جدید دیگر راه بندازید

Settings > Settings > Actions > New self-hosted runner 

همان مراحل بالا را انجام بدید منتها نام و لیبل رو به server-deployment تغییر دهید

اکنون صفحه رانرها را رفرش کنید رانر server-deployment رو با server-developer  میبینید 

هر دو رانر ما آماده شدن

#git
#actions


@code_crafters

خب بریم سراغ نوشتن workflows ها

یک دایرکتوری در مسیر root پروژه خود بسازید و اسم آن را github. بزارید و داخل آن نیز یک دایرکتوری دیگر با اسم workflows بسازید هر فایلی با پسوند yml. بعنوان یک flow شناخته میشه و به رانر برای اجرا داده میشود

در سناریوی پست اول گفتیم که دو سرور خواهیم داشت server-develope با server-deployment


در این دایرکتوری دوتا فایل خواهیم ساخت 
develop.yml
deployment.yml

ابتدا میریم سراغ فایل develope.yml و ذره ذره آنرا توضیح خواهیم داد

ابتدا برای آن یک نام تعیین میکینیم تا در هنگام اجرا شدن در صفحه گیتهاب مربوط به نشان دادن بتوانیم آنرا تفکیک کنیم

name: develope application 

نام را ست کردیم


در مرحله بعد ما مشخص میکنیم این flow چه هنگامی اجرا شود

on:
     push:
          branches:
                - main

مشخص کردیم هنگامیکه پوش داشتیم و روی برنچ main این پوش صورت گرفته بود این flow اجرا گردد


در سناریوی اولی ما دو سرور داشتیم و هر سرور هم یک رانر داشت رانر مربوط به تست و توسعه رو با اسم server-develope لیبل آنرا نیز با نام server-develope گذاشتیم ما از اسم لیبل استفاده میکنیم میکنیم تا به گیتهاب بفهمونیم میخواهیم flow با اسم develope.yml را روی روی سرور و با رانر server-develope اجرا کند

env:
      TARGET_SERVER: server-developer

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


بریم سراغ نوشتن jobها هر flow میتونه چندین job داشته باشه که در بلاک jobs نوشته میشه هر job یک مشخصه و چندین step و env و رانر متصل و ... میتونه داشته باشه

ما سه job خواهیم داشت
Pull
Dockerize
Push

قبل از ادامه در سرور

۱-در مسیر var/www/ پروژه رو‌clone میکنیم

۲-نصب و پیکربندی داکر و داکرکامپوز

خب بریم سراغ جاب pull

pull:
        runs-on: self-hosted
        steps:
            - name: pull from github
              env:
                USERNAME: "CodeCrafters-ir"
                TOKEN: ${{ secrets.TOKEN }}
              run: |
                cd /var/www/test-action
                git config --global user.email "[email protected]"
                git config --global user.name "behzad azadi"
                git pull https://$USERNAME:$[email protected]/CodeCrafters-ir/test-actions.git

اسم job رو گذاشتیم ،جهت گرفتن تغییرات ریپو بر روی سرور

این جاب روی رانر خود میزبان اجرا خواهد شد و چون در ابتدا برای این flow ما مقدار TARGET_SERVER تعریف کردیم پس این جاب و گامهای اون روی سروری اجرا میشه که رانر با لیبل server-developer قرار گرفته است

در گام اول ما یک نام با عنوان pull from github گذاشتیم

درون env ما دو مقدار متغییر قرار دادیم username برای نام کاربری در گیت‌هاب و TOKEN که توکن دسترسی به ریپوی پرایویت و اکانت گیتهاب ما می باشد و چون این مقدار امنیتی می باشد آنرا داخل سکرت ریپومون در مسیر زیر گذاشته و از آنجا دریافت میکنیم
Settings > Secrets and Varibles > Secret > New repository secret

تصویر اول در کامنت‌ها

در قسمت run دستورات مربوط رو مینویسیم

ابتدا به مسیر دایرکتوری پروژه میریم معمولا در جامعه توسعه دهندگان و لینوکس مسیر آن در var/www/ می باشد

مقادیر نام و ایمیل رو برای گیت تنظیم میکنیم 

و سپس جهت دریافت کدها و تغییرات pull میکنیم به نحوه جا دادن username و token دقت کنید

بریم سراغ جاب بعدی dockerize

dockerize:
        runs-on: self-hosted
        needs:
            - pull
        steps:            
            - name: Create image
              run: |
                echo $SUDO_PASSWORD | sudo -Sv
                cd /var/www/test-action
                sudo docker build . -t conda-test --no-cache

            - name: Run container
              run: |
                echo $SUDO_PASSWORD | sudo -Sv
                cd /var/www/test-action
                sudo docker compose down
                sudo docker compose up -d

در این جاب مقدار need رو میبینید که به جاب pull رفرنس داده ،ما تا زمانیکه کدهارو نگرفتیم نمیتونیم داکرایز کنیم بابت همین نیاز هست منتظر بمونیم pull تموم بشه و بعد

داخل هر گام مقدار کد 
echo $SUDO_PASSWORD | sudo -Sv
رو میبینیم چون نیاز هست در کامندها از sudo استفاده کنیم اینگونه براش پسورد رو میگذاریم 

مقدار متغییر 
$SUDO_PASSWORD 
رو هم در env گلوبال میزاریم
env:
    TARGET_SERVER: server-developer
    SUDO_PASSWORD: ${{ secrets.SUDO_PASSWORD }}
در بالاتر یاد گرفتیم چطوری متغییر امنیتی رو تنظیم کنیم

#git
#actions

@code_crafters

خب بریم سراغ جاب push


ابتدا به اکانت داکرهاب خودمون میریم یدونه ریپوزیتوری پرایویت میسازی با اسم conda-test

push-image:
        runs-on: self-hosted
        env:
          USERNAME: 'behzadazadi2693'
          DOCKER_PASSWORD: $"{{ secrets.DOCKER_PASSWORD }}"
        needs:
          - dockerize
        steps:
          - name: push image to docker account
            run: |
              echo $SUDO_PASSWORD | sudo -Sv
              sudo docker login -u $USERNAME -p $DOCKER_PASSWORD
              sudo docker tag conda-test $USERNAME/conda-test:v1
              sudo docker push $USERNAME/conda-test:v1

خب نیاز داریم اول جاب dockerize تموم بشه بعد ،پس needs رو براش مینویسیم

برای لاگین در داکر هاب نام کاربری و پسورد لازم داخل env تعریف میکنیم و پسورد رو میبریم داخل سکرت ریپومون

دستورات run:

پسورد ران برای دستور sudo تنظیم میکنیم 

ابتدا لاگین میکنیم

طبق قاعده خاص داکر ایمیج رو نام گذاری میکنیم برای ریپوزیتوری پرایویتمون در داکر هاب 
و سپس پوش میکنیم داخل داکر هاب

خب بریم سراغ flow مربوط به deployment

نکته: ابتدا در سرور server-deployment داکر و داکرکامپوز رو نصب میکنیم 

خب برگردیم سر طراحی این flow

ابتدا یک نام بهش میدیم

name: deployment application

در مرحله بعدی مشخص میکنیم چه وقتی این flow کار کنه؟؟؟

یادتون هست در تعریف سناریو گفتیم که برای سرور دیپلوی بیام بصورت دستیش کنیم؟؟؟

درسته پس این مقدار باید بشکل زیر باشه

on:
     Workflow_dispatch

حالا باید مشخص کنیم که این flow در کدوم سرور بوسیله کدوم رانر اجرا بشه(پسورد sudo رو هم بزاریم براش)

env:
    TARGET_SERVER: server-deployment
    SUDO_PASSWORD: ${{ secrets.SUDO_PASSWORD }}

در جاب اول ایمیج رو pull میکنیم

pull-image:
        runs-on: self-hosted
        steps:
            - name: pull image
              env:
                USERNAME_HUB: "behzad-azadi2693"
                PASSWORD_HUB: ${{ secrets.TOKEN }}
              run: |
                echo $SUDO_PASSWORD | sudo -Sv
                sudo docker login -u $USERNAME -p $DOCKER_PASSWORD
                sudo docker push $USERNAME/conda-test:v1

خب همه چی مشخص هست درسته؟؟؟

در جاب دوم لازم هست ایمیج رو اجرا کنید تا اینجای کار اومدیم پس یاد گرفتین خودتون این جاب رو چجوری بنویسید


چندتا نکته:

شما میتونید روی یک سرور کار کنید 

در قسمت runs-on اگر مقدار ubuntu-latest رو قرار بدید روی رانرهای خود گیتهاب کار خواهد کرد

اگرهم تغییر ندید و به هر دلیلی رانرتون ارور بده گیتهاب بازم میبره روی رانر خودش اما بدلیل دستور sudo و پسورد بهتون خطا خواهد داد

ایا میشه از این ساده تر هم نوشت؟؟بله action های آماده وجود داره که برید بخونید راجبشون 

در قسمت on هم میتونید علاوه push و dispatch حتی cronjob ,pull request هم تنظیم کنید

پروژه و کدها رو میتونید در گیتهاب ببینید
https://github.com/CodeCrafters-ir/test-actions.git


خب سوال:
اگه بخوایم همین سناریو رو در گیتلب هم یاد بگیریم چی؟؟؟
اموزش بچه‌های دواپس هابیز رو در یوتیوب ببینید

https://youtube.com/playlist?list=PLYrn63eEqAzannVocQrddqsBK-C17e-Sm&si=F_C_OiGw6i3l4aoN


#git
#actions

@code_crafters

در ادامه مباحث مربوط به github action

تست پروژه و کدها

ما قبل از اینکه بخواهیم پروژه رو pull و داکرایز کنیم نیاز هست ابتدا تست‌هایی که توسط تیم توسعه صورت گرفته رو انجام دهیم و در صورت پایان بدون خطا اقدام به انجام جاب‌های دیگر کنیم

پس ما یک جاب test مینویسیم و دیگر جاب‌ها رو الزام میکنیم بعد از آن اجرا شوند

در فریمورک جنگو میدانیم که برای تست

 نیاز به نصب جنگو 

و سپس اجرای دستور 
python manage.py test 
می باشیم

جاب test ما بشکل زیر خواهد بود

test:
    runs-on: self-hosted
    container:
      image: python:slim-bullseye
    steps:
      - name: Run Django tests
        run: |
          pip install django
          python manage.py test

یک نکته جالب میبینیم که از مقدار :container در جاب استفاده شده است

در واقع در اینجا به مطرح کردیم که یک کانتینر از یک ایمیج برام بالا بیار دستورات زیر رو داخلش اجرا کن برام ،اتفاق جالبی که میافته این هست پس از اتمام دستورات کانتینر رو برامون پایین میاره

یک کانتینر از ایمیج python:slim-bullsey بالا بیار جنگو‌رو نصب کن ،کدهارو تست کن و کانتینر رو برام حذف کن
دیگر لازم نیست برای قسمت تست هم یک کانتینر نگهداریم

حالا کافیست داخل دیگر جاب‌ها با استفاده از :needs همه جاب ها رو موظف کنیم که در انتظار بمونن تا تست با موفقیت به اتمام برسد


#git
#actions


@code_crafters