خب بریم سراغ نوشتن 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

تصور برخی دوستان از دنیای فریلنسری

#fun

@code_crafters

بچه‌ها نظرتون چیه یک وبسایت داشته باشیم برای کانال و در اون شروع کنیم گذاشتن مطالب آموزشی؟؟؟


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

Configuration management???

یا به اختصار cm

ما تا اینجا مدام کد زدیم سرویس بالا آورده و در توسعه نرم افزار عمل کردیم این رو در دنیای IT با عنوان saas میشناسن و در چندپست قبل نیز راجب ci cd حرف زدیم که این ابزار رو اوردیم و در این بخش مورد استفاده قرار دادیم


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

Terraform
Ansible

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


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

راجب انسیبل بیشتر بدونیم

انسیبل (Ansible) یک ابزار متن‌باز و قدرتمند برای مدیریت و پیکربندی سیستم‌ها، استقرار برنامه‌ها، اتوماسیون وظایف و هماهنگی آنهاست. به عبارت دیگر، انسیبل یک ابزار Remote Administration بسیار قوی با امکانات بسیار کارآمد است که از پروتکل SSH برای برقراری ارتباط و مدیریت سیستم‌ها و دستگاه‌ها استفاده می‌کند. 

برخی از مزایای استفاده از انسیبل:

سادگی: انسیبل از زبان یام‌ال (YAML) برای نوشتن Playbookها استفاده می‌کند که یادگیری آن آسان است.

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

انعطاف‌پذیری: انسیبل می‌تواند برای مدیریت انواع مختلف سیستم‌ها، از جمله سرورها، روترها، سوئیچ‌ها و دستگاه‌های ذخیره‌سازی استفاده شود.

مقیاس‌پذیری: انسیبل می‌تواند برای مدیریت تعداد زیادی از سیستم‌ها به طور همزمان استفاده شود.

رایگان: انسیبل یک ابزار متن‌باز و رایگان است.

برخی از کاربردهای انسیبل:

مدیریت پیکربندی: انسیبل می‌تواند برای پیکربندی سیستم‌ها، نصب نرم‌افزار، به‌روزرسانی سیستم‌عامل و تنظیمات امنیتی استفاده شود.

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

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

هماهنگی: انسیبل می‌تواند برای هماهنگی وظایف بین چندین سیستم استفاده شود.

اگر به دنبال یک ابزار قدرتمند و کارآمد برای مدیریت و اتوماسیون وظایف IT خود هستید، انسیبل یک گزینه عالی است

سناریو به چه صورت خواهد بود ما دوتا سرور داریم توسعه و استقرار و میخوایم هر کدوم رو مختص به کاربردش پیکربندی کنیم

ابتدا انسیبل رو روی سیستم خود نصب کنید Link

در یک مسیر دلخواه خودتون یک دایرکتوری با اسم base-ansible بسازید و داخل اون برید (این اسم الزامی و ما فقط جهت پیش بردن این دسته پیام‌ها میسازیم)

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

بعد از نصب انسیبل

وارد دایرکتوری base-ansible بشید 

یک فایل با اسم info.yml بسازید 

این متن رو بصورت دقیق داخل ان بنویسید و ذخیره کنید

- hosts: localhost
  tasks:
    - name: FACTS
      debug:
        msg: "{{ ansible_facts }}"

در دایرکتوری خط فرمان رو باز کنید و دستور زیر رو بزنید

ansible-playbook info.yml


در خروجی این دستور در خروجی این دستور مهمترین اطلاعات مربوط به سیستم خودتون رو میبینید درسته؟؟؟

حالا کافیه همین رو تنظیم کنیم جهت اجرا روی سرور خودمون

عجله نکنید ذره ذره پیش میریم و یاد میگیریم

#ansible
#CM

@code_crafters

وضعیت واقعی بوت کمپ‌های آموزشی در حوزه برنامه نویسی


#fun

@code_crafters

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


(تلفیق موسیقی کوردی و اسپانیایی)

#fun

@code_crafters

از این ببعد دسترسی به gpt بدون شماره و با ایمیل می باشد

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


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

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

بر روی سرور استقرار اما نیاز به گیت نداریم 

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



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

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

دغدغه ما در این سطح 

ما نیاز داریم دو سرور توسعه و استقرار رو‌ در یک جاهایی جدا از هم داشته باشیم و پیکربندی هرکدوم رو جداگانه بزنیم 


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

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


inventory directory

دایرکتوری inventory در Ansible راهی قدرتمند برای سازماندهی و مدیریت داده‌های موجودی شما ارائه می‌دهد. این به شما امکان می‌دهد چندین منبع موجودی را در یک مکان واحد ادغام کنید و مقیاس‌پذیری و قابلیت نگهداری را بهبود ببخشید.

نکته:ما در انسیبل از ساختار yaml نویسی استفاده میکنیم

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

در دایرکتوری کاری خودمون که در پست قبل ساختیم یک دایرکتوری با نام inventory ایجاد میکنیم


در داخل inventory یک فایل با نام main.yml میسازیم و کدهای زیر رو داخل اون میزاریم

all:
  hosts:
    develope:
      ansible_host: server_ip
    deployment:
      ansible_host: server_ip
    

develope:
  hosts:
    develope_server:
      ansible_host: server_ip


deployment:
  hosts:
    deployment_server:
      ansible_host: server_ip

ما سه گروه ایجاد کرده‌ایم تا بتونیم سناریوی خودمون رو پیش ببریم


توضیحات

گروه all
جهت نصب همه پیکربندی های یکسان و یکدست در همه میزبان‌ها(داکر و داکرکامپوز)

گروه develop
جهت نصب و پیکربندی سرور تست و توسعه

گروه deployment
جهت نصب و پیکربندی سرور استقرار

در هر گروه با بلوک hosts موجودیت‌های خودمون رو در اون بخش مشخص میکنیم 

یک اسم براش در نظر  میگیریم

و در ansible_host آدرس اون موجودیت رو بهش میدیم 

نکته
مقدار ip سرور خود را در server_ip جاساز کنید

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

گام اول ما برای سناریوی مدنظرمون به اتمام رسید

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

#ansible
#CM

@code_crafters

یکی از موضوعات دوست داشتنی در هوش مصنوعی ریاضیاتش هست که همه از دستش فرار میکنیم از بس که جذاب هست

یکی ازین کتاب‌ها با عنوان جبرخطی شناخته میشه که از خود ریاضیات بیشتر دوست داشتنی تره😅😅😅

یک مهندس عزیز در اینترنت سعی کرده که این مورد رو با زبان ساده آموزش بده تا شیرینیش رو ازش بگیره براتون

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

https://chistio.ir/%D8%AF%D9%88%D8%B1%D9%87-%D8%AC%D8%A8%D8%B1-%D8%AE%D8%B7%DB%8C-linear-algebra-%DB%8C%D8%A7%D8%AF%DA%AF%DB%8C%D8%B1%DB%8C-%D8%B9%D9%85%DB%8C%D9%82/

#AI
#ML

@code_crafters

گویا یک مهندس دیگر هم در یوتیوب زحمت کشیده و داره دوره جامعی رو براش منتشر میکنه


https://www.youtube.com/playlist?list=PLe_DUrcBPdbIRye6Dw_UdhR8a7Zqvb_BA

رزومه شخصی chat gpt قبل از استخدام شدنش در شرکت openai


#fun

@code_crafters

پروفایل کردن چیست؟؟؟

در طی طراحی یک برنامه همیشه این سوال برامون پیش میاد که کد و کوئری ما بهینه هست یا نه ،چقدر منابع مصرف میکنه(حافظه ، cpu ، i/o و ...) ،از لحاظ تایمینگ چطور ، و یا حتی تعداد کوئری‌هامون و ...

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

پروفایلینگ در توسعه نرم افزار به فرآیند تجزیه و تحلیل رفتاری زمان اجرای یک سیستم یا برنامه میگیم ،تا ازین طریق بتوان نقاط ضعف و مورد دار سیستم رو پیدا کنیم و در جهت بهبود اون اقدام به بازنویسی موارد مدنظرمون کنیم


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

۱-پروفایلینگ زمان:
مقدار زمان صرف شده بخش‌های مختلف کد رو اندازه گیری میکنیم


۲-پروفایلینگ حافظه:
تحلیل نحوه استفاده از حافظه توسط یک برنامه (مدیریت ناکارآمد، مصرف غیر ضروری و ...)

۳-پروفایلینگ cpu:
نحوه استفاده از پردازنده، شناسایی عملیات‌های محدود به cpu و نقاطی که بهینه سازی شود


۴-پروفایلینگ i/o:
دسترسی به فایلها یا کوئری‌های دیتابیس،شناسایی نقاط محدود کننده و بهبود آن

۵-پروفایلینگ پوششی کد:
کدام بخش کد در طول یک جریان ،اجرا شدند کمک به تست و شناسایی کدام بخش کد اجرا نشده است


۶-پروفایلینگ فراخوانی تابع:
ردیابی فراوانی و مدت زمان فراخوانی تابع، درک سلسله مراتب فراخوانی و شناسایی توابع با تاثیر بالا

نکته قابل توجه:

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

در فریمورک جنگو هم دو پکیج محبوب وجود دارد django-debug-toolbar و django-silk می باشد


خب بیاید django-silk رو پیکربندی و نصب کنیم


نصب

pip install django-silk

تنظیمات در settings.py

INSTALLED_APPS = [
    ...
    'silk'
]


MIDDLEWARE = [
    ...
    'silk.middleware.SilkyMiddleware',
]

در urls اصلی پروژه

from django.contrib import admin
from django.urls import path, include
from django.conf import settings


urlpatterns = [
    path('admin/', admin.site.urls),
]

if settings.DEBUG:
    urlpatterns += [path('silk/', include('silk.urls', namespace='silk'))]

در نهایت

python manage.py makemigrations

python manage.py migrate

python manage.py collectstatic

python manage.py runserver

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

https://localhost:8000/silk

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

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

#monitoring

@code_crafters

در ادامه پست‌های مربوط به انسیبل میرسیم به موضوع بعدی

در پست‌های قبلی

تعریفی از cm و انسیبل داشتیم

 یک سناریو جهت اجرا شدن تعیین کردیم

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

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


به قسمت دوم این بخش در انسیبل میگیم tasks یا وظایف انجام کار شامل هرچیزی میشه که ما خواهان انجام شدن اون در هاست‌ها هستیم مثه نصب و پیکربندی ابزارهای os ساخت و کپی کردن فایل و دایرکتوری در هاست ،ست کردن و تغییر دادن مقادیر کانفیگ‌هامون و ...


در انسیبل این وظایف انجام کار رو به دو حالت میشه انجام داد در دایرکتوری playbooks و در مفهومی با عنوان roles

ما ابتدا به دایرکتوری playbooks میپردازیم


Playbooks directory

در واقع playbooks این بخش از کار رو هندل میکنه که چه تسکی یا چه وظیفه انجام کاری در کدام میزبان یا گروه میزبان جهت اجرا و ران شدن ارسال بشه 

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

برای مثال در دسته بندی all که شامل همه موجودیت‌هامون(هاست‌هامون) هست داکر و دامرکامپوز رو نصب کن و پیکربندی کن

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

پس لازم هست در ادامه کار این دایرکتوری رو در داخل دایرکتوری کاری خودمون در کنار inventory ایجاد کنیم

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

base-ansible
├── inventory
│   └── main.yml
├── playbooks

در ادامه میریم سراغ انجام دادن بخش‌های کوچکی در اون

نکته:برای هر وظیفه مشخص در دایرکتوری playbooks یک فایل با پسوند .yml میسازیم که ما میخواهیم git،docker,docker compose, ... و یکسری پکیج os دیگه که با apt نصب میشه مانند htop ,ufw و ...


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

├── playbooks
    │   ├── main.yml
    │   ├── docker-compose.yml
    │   ├── docker.yml
    │   ├── git.yml
    │   ├── nginx.yml
    │   ├── system.yml
    │   ├── project.yml
    │   ├── sysadmin_monitoring.yml
    │   └── test.yml

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

- hosts: all
  tasks:
    - name: Install Git
      apt:
        name: git
        state: present
        update_cache: yes
      become: yes
    - name: local directory exists
      file:
        path: /path/to/destination
        state: directory
        mode: 0755
      become: yes
    - name: Clone repository
      git:
        repo: github_url
        dest: /path/to/destination
      become: yes

خب این یک نمونه ساده بابت عملیات گیت هستش که در سه وظیفه و تسک صورت میگیره
ابتدا گیت رو از ریپوزیتوری‌های apt نصب میکنه
در مرحله دوم چک میکنه مسیر مدنظر ما وجود داره
و در تسک سوم هم گیت رو کلون میکنه

در قسمت hosts به نام یکی از گروهای موجودیت‌هامون که در inventory مشخص کردیم قرار میدیم که در اینجا به all اشاره شده 

به هر تسک یک name میدیم

مقدار update_cache همان دستور معروف apt update جهت بروز رسانی ریپوها میباشد

مقدار become به معنای اجرای دستور با دسترسی sudo است

مقدار path مسیر فعلی رو‌مشخص میکنه که گفتیم ما اپ هامون رو در var/www/ میزاریم

مقدار mode همان مقدار دسترسی فایلی لینوکسی هست بصورت عددی

مقدار repo هم که لینک دسترسی به گیتهاب می باشد

مقدار dest هم مسیر جهت کلون کردن پروژه 


و مقدار state جهت چک‌کردن می باشد که در اولی نصب بودن پکیج و در دومی چک‌کردن وجود داشتن مسیر مدنظر ما

به این معنا که در تمام موجودیت‌ها و هاست‌هامون که در inventory مشخص کردیم سه وظیفه مشخص شده رو انجام بده

طبق سناریوی اولیه ما باید موارد مربوطه در سرور تست و توسعه اجرا بشه لذا مقدار all رو با develop تعویض کنید

با دستور زیر میتونید این playbook رو اجرا کنید

در دایرکتوری کاری خط فرمان رو باز کنید 

ansible-playbook playbooks/git.yml

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

ssh-keygen -t rsa

ssh-copy-id username@server_address

ssh username@server_address

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

#ansible
#CM

@code_crafters

یک فایل دیگه رو هم باهم بررسی کنیم که یک نکته اموزشی دیگه رو هم پوشش بدیم به فایل system.yml توجه کنید ما داخل این فایل ابزارهای سیستمی رو جهت نصب قرار میدیم برای مثال htop , ufw به دو صورت میشه انجام داد یک نوشتن دو تسک و یا استفاده از حلقه در انسیبل هردو روش رو در زیر میبینید

روش اول:
- name: Install and configure
  hosts: all
  tasks:
    - name: Install htop
      apt:
        name: htop
        state: present
      become: yes
    - name: install ufw
      apt:
        name: ufw
        state: present
      become: yes

روش دوم با حلقه:
- name: Install and configure
  hosts: all
  become: yes
  tasks:
    - name: Install required packages
      apt:
        name: "{{ item }}"
        state: present
      with_items:
        - htop
        - ufw

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

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

نکته بعدی{{ item }} اینجا متغیر هست و حلقه انسیبل مقادیر لیست شده رو در with_items به ترتیب داخلش میزاره جهت اجرا عجله نکنید ما یک بخش متغییر هم داریم که باید راجبش حرف بزنیم

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


- name: Install required packages
  hosts: all
  become: yes 

  tasks:
    - name: Install required packages (yum)
      yum:
        name: "{{ item }}"
        state: present
      loop:
        - htop
        - ufw
      when: ansible_os_family == 'RedHat' 

    - name: Install required packages (apt)
      apt:
        name: "{{ item }}"
        state: present
      loop:
        - htop
        - ufw
      when: ansible_os_family == 'Debian'

مقدار when چک میکنه یک شرطی رو و در صورت درست بودن اون بخش از تسک‌هارو اجرا میکنه

اما سوالی که براتون پیش اومده این هست ansible_os_family از کجا اومده؟؟؟ باز هم میگم صبر کنید به مرور باهاش آشنا میشیم
--------------------

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


خب این یک مقداری کار اضافه هست بازم برای ما

انسیبل برامون راه حل گذاشته

بهتون گفته بودم برای هر قسمت که میخواهیم وظایفی انجام بدهیم یک اسم منطقی نسبت به اون بزاریم مثلا git.yml , docker.yml و ...

اما من یک فایل دیگه هم گذاشتم با اسم main.yml راه حل انسیبل رو من در این قسمت گذاشتم شما میتونید هر اسم دیگه با پسوند yml بسازید (site.yml یا config.yml یا playbook.yml و ...)

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

- import_playbook: git.yml
- import_playbook: docker.yml
- import_playbook: nginx.yml
- import_playbook: package.yml
.
.
.

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

حال کافیست دستور اجرایی رو اینبار برای main.yml بزنیم

ansible-playbook playbooks/main.yml

اینبار تمامی تسک‌ها در تمامی فایل‌ها import شده به فایل main با ترتیبی که قرار داده‌اید روی موجودیت‌هامون اجرا میشن

در توضیح تسک‌های بالا سه مقدار رو فراموش کردیم apt, file, git عجله نکنید بعدا باهاشون اشنا میشیم و موارد بیشتر ازین هم با این اسامی موجود هستند

و اما فایل test.yml چیست؟؟
در پست قبلی مطرح کردیم و گفتیم با اجرای این playbook تمامی اطلاعات مربوط به هاست یا موجودیت مدنظرمون رو میگیریم که حاوی اطلاعات جامع و البته حساس نیز میباشد

نکته پایانی که بخوام بگم ساختار بندی با اسامی درست گذاشتن روی دایرکتوری و فایل‌های yaml در انسیبل بسیار حائز اهمیت می باشد تا قابل درک برای مابقی مدیران سیستمی هم باشد
#ansible
#CM

@code_crafters

در ادامه پست های مربوط به ansible میرسیم به بحث بعدیمون

یک مرور سریع داشته باشم

ما تعریف CM ,ansible رو داشتیم و کاربردشون در دنیای مهندسی

تعریفی از inventory داشتیم و گفتیم که موجودیت‌هامون رو در اون میزاریم

تعریفی از playbooks داشتیم و گفتیم که کارش برقراری ارتباط بین موجودیت‌ها و تسک‌هامون هست ،چه وظایفی یا تسکی روی چه موجودیتی اجرا شود

در این پست میرسیم به به مفهوم roles

خب roles روشی جهت سازماندهی و اشتراک‌ گذاری وظایف هستش ، در واقع ما وظایفمون رو از داخل playbooks هامون در میاریم و در یک مفهوم به نام roles قرار میدیم که موجب قابل استفاده شدن مجدد، قابل اشتراک گذاری، قابل نگهداری، قابل آزمایش و خودکارسازی وظایف رایج در چند سرور میشه


خود roles از چند بخش مختلف تشکیل شده تا با استفاده از اونها بتونیم به نحوی کارآمدتر وظایفمون رو بچینیم و پایه ریزی کنیم براشون

برای ادامه مباحث دو‌ کار زیر رو انجام میدهیم
۱- در دایرکتوری کاریمون یک دایرکتوری به اسم roles میسازیم

۲-داخل این دایرکتوری roles برای هر playbookمون در دایرکتوری playbooks یک دایرکتوری با همون اسم میسازیم تا تفکیک سازی برامون راحت تر صورت بگیرد

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

base-ansible
├── inventory
│   └── main.yml
├── playbooks
│   ├── main.yml
│   ├── docker-compose.yml
│   ├── docker.yml
│   ├── git.yml
│   ├── nginx.yml
│   ├── system.yml
│   ├── project.yml
│   ├── sysadmin_monitoring.yml
│   └── info.yml
├── roles
│   ├── docker
│   ├── docker-compose
│   ├── git
│   ├── nginx
│   ├── system
│   ├── project
│   ├── ssh
│   └── sysadmin_monitoring

گفتیم که ساختار داخلی roles از بخش های متفاوتی ساخته شده ، خب بیایم با هر کدوم ازین بخش‌ها آشنا بشیم

دایرکتوری tasks شامل وظایف پیش فرضی میشه که در اون role اجرا میشه

دایرکتوری default و vars شامل مقادیر متغییرهای مورد استفاده در اون role خواهد شد میتوان از vars برای متغییرهای خاص استفاده میشه متغییرهای تعریف شده توسط خودمون و از default برای متغییرهای پیش فرض سیستمی استفاده میشه برای مثال پورت ssh


دایرکتوری templates مورد استفاده برای تسک‌هایی که در اون از متغییر استفاده میکنیم برای مثال فایل پیکربندی nginx.conf

دایرکتوری files مورد استفاده برای فایل‌های استاتیک مورد استفاده برای مثال پیکربندی فایل sshd_config

دایرکتوری meta جهت استفاده در تسک‌های متفاوت (در واقع تسکهامون رو ورژن بندی میکنیم)

دایرکتوری handlers جهت تعریف یک تسک یکبار مصرف برای مثال ریستارت کردن و اکتیو کردن یک سرویس در هاستمون مثه nginx

دایرکتوری common جهت استفاده در تسک‌هایی که قابلیت تغییر مجدد رو دارن , handlers ورودی خودش رو ازین دایرکتوری میگیره


ما با ترکیب قسمت‌های مورد استفاده از دایرکتوری های بالا role مدنظر خودمون رو پیاده سازی میکنیم

نکته در دو دایرکتوری templates , files مسیر دقیق تسکتون رو بسازید تا مدیران سیستم دقیقا آکان بشن که دارید چکاری انجام میدید برای مثال ما فایل کانفیگ nginx رو در سرور در مسیر etc/nginx/sites-enable/ قرار میدیم این مسیر رو دقیق در templates بسازید


کا گفتیم که تسک‌ها رو‌ از playbook بر میداریم و در مفهومی با عنوان role قرار میدیدم خب بیاید این کار رو با git.yml و system.yml که قبلا در playbook نوشتیم انجام بدیم دقیقا باید قسمت tasks رو ازش برداریم و تغییراتمون بشکل زیر در بیاد

برای playbooksهامون

در git.yml
- name: install git
  hosts: all
  become: True
  gather_facts: false
  roles:
    - git


در  system.yml
- name: install multi package in linux
  hosts: all
  become: True
  gather_facts: false
  roles:
    - system

گفتیم برای هر playbook یک دایرکتوری در داخل roles با همون اسم بسازیم ، در داخل بلوک roles بالا اسم این دایرکتوری هارو میزاریم و انسیبل در اون دایرکتوری به دنبال دایرکتوری‌های که بالاتر تعریف کردیم میگرده و نقش هرکدوم رو میدونه پس ما بیاد تسک‌هامون رو در داخل دایرکتوری tasks و فایل main.yml بنویسیم

ساختار دایرکتوری roles بشکل زیر خواهد بود

roles
├── git
│   ├── tasks
│   │   └── main.yml
│   └── vars
│       └── main.yml
├── project
│   ├── tasks
│   │   └── main.yml
│   └── vars
│       └── main.yml
└── system
    ├── tasks
    │   └── main.yml
    └── vars

داخل فایلهای main هر کدام تسک مربوطه میزاریم

#ansible
#CM

@code_crafters