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

#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

project/tasks/main.yml فایل

- name: create directory if they don't exist
  file:
    path: "{{ item }}"
    state: directory
    owner: root
    group: root
    mode: 0777
  loop:
    - /var/www/backend/
    - /var/www/frontend/


- name: clone backend project from git
  git:
    repo: "https://{{ GIT_USER }}:{{ GIT_TOKEN }}@{{ URL_BACKEND }}"  
    dest: /var/www/backend/
    version: "{{ GIT_VERSION }}"
    clone: yes


- name: clone frontend project from git
  git:
    repo: "https://{{ GIT_USER }}:{{ GIT_TOKEN }}@{{ URL_FRONTEND }}" 
    dest: /var/www/frontend/
    version: "{{ GIT_VERSION }}"
    clone: yes

git/tasks/main.yml فایل

- name: Install Git
  apt:
    name: git
    state: present
    update_cache: yes


- name: Set Git user name
  command: git config --global user.name "{{ GIT_USERNAME }}"


- name: Set Git user email
  command: git config --global user.email "{{ GIT_EMAIL }}"

system/tasks/main.yml فایل

- name: install packages
  apt:
    name: "{{ item }}"
    state: present
    update_cache: yes
  loop:
    - htop
    - ufw

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

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

به تغییر شکل loop دقت کنید در بخش system با project 

کنار موارد قبلی apt و ... بلوک command هم اضافه شده (در پست بعد سراغ این موردها میریم) 

منغییرها هم کامل واضح هست و گفتیم باید در دایرکتوری vars و بالطبع فایل main.yml نوشته شود

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

برای مشاهده پست در وب هم بر روی لینک زیر بزنید (سایت کانال)
https://codecrafters.ir/topic/describe/12/

#ansible
#CM

@code_crafters

در این قسمت میرسیم به مبحث module ها در انسیبل

در قسمتهای قبل هنگام نوشتن بلوک tasks داخل بدنه این بلوک شاهد حضور apt, git, command , ... بودیم که بهشون میگیم ماژول

- name: install nginx
  apt:
       name: nginx
       state: present

یک ماژول انسیبل که با apt اقدام به نصب nginx میکند

در تعریف ماژول میتونیم بگیم واحدهای(کار، وظیفه‌، تسک) اصلی هستند هر ماژول وظیفه خاصی داره مثه نصب کردن یک نرم افزار،راه اندازی سرویس، کپی کردن یا درست کردن فایل ،اجرا کردن یک دستور و ...

ویژگی ماژول‌ها چیه:

کوچیک و مستقل: هر ماژول یک وظیفه خاص انجام میده

قابل استفاده مجدد

قابل توسعه:بیشتر با زبان bash , python نوشته شده

پشتیبانی از انواع سیستم عامل‌ها

انواع ماژول

ماژول هسته‌ای: توسعه داده شده توسط تیم انسیبل

ماژول توسعه داده شده توسط جامعه انسیبل

ماژول‌های توسعه داده شده تپسط شما

ماژول‌ها تعدادشون زیاده تقریبا در حدی که برای هر کاری ما یک ماژول داریم که میتونیم لیست اونهارو و اشنایی باهاشون رو در این لینک ببینیم

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


در طی اموزش‌های قبلی ما درکی از task ، role, playbook. پیدا کردیم و اکنون راحتتر میتونیم جایگاه و استفاده از ماژول‌هارو بفهمیم


میتونید جهت راحت کردن کار برای هر تسک مدنظرتون در گوگل سرچ کنید یا از chat bot ها بپرسید


#ansible
#CM

@code_crafters

بریم سراغ variable در انسیبل

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

در سری پست‌های قبلی ما به دفعات از متغیر در انسیبل استفاده کردیم که نحوه استفاده از اون به شکل "{{ name_var }}" میباشد


متغیرهارو میشه در بخش‌های مختلفی بکار برد در inventory, role,playbook,template ،task و ...

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

در inventory

deployment:
      ansible_host:"{{ server_ip }}"

در task

  tasks:
    - name: Install required packages
      apt:
        name: "{{ item }}"
        state: present
      with_items:
        - htop
        - ufw

متغیرهارو میتونیم در جایگاه‌های خاصی نوشت درون هر tasks (مانند مثال بالا) ، بصورت گروه بندی، بصورت هاست‌بندی و یا در داخل role

در دایرکتوری کاریمون(base-ansible) دو دایرکتوری group_vars ,host_vars ایجاد میکنیم

در داخل group_vars برای هر دسته بندی موجودیتمون یک فایل yaml میسازیم که ما all.yml میسازیم (میتونیم برای موجودیت develope, deployment هم بیازیم) به این ترتیب مقادیر متغییر گروهی رو میتونیم داخلش بنویسیم


و در host_vars برای هر موجودیت یک فایل yaml با اسم موجودیتمون میسازیم که طبق سناریوی خودمون develope.yml , deployment.yml

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

base-ansible
├── ansible.cfg
├── group_vars
│   ├── all.yml
├── host_vars
│   ├── develope.yml
│   ├── fdeployment.yml
├── inventory
│   └── main.yml
├── roles
│   └── ...
├── playbooks
│   ├── ....

در طی پست‌های قبلی نیز دیدیم داخل role هامون یک دایکرتوری vars داشتیم که داخلش یک فایل با نام main.yml میسازیم


داخل فایل‌های yml به این شکل میتونیم متغییرهامون رو تعریف کنیم

name: "value"

که در هرجایی که خواستیم ازش استفاده کنیم مقدار name رو صدا میزنیم "{{ name }}"


که هرکدوم رو در صورت استفاده در جایگاه خودش در دایرکتوری مدنظرمون مقداردهی میکنیم برای مثال در role هامون در دایرکتوری vars , در موجودیت هامون در host_vars و اگه یک متغییر داشتیم که در جاهای مختلف و دسته مختلف مورد استفاده بود در group_vars میزاریم

نکته بسیار مهم انسیبل از داخلی ترین به بیرونی ترین دنبال متغییرها میگرده تصور کنید داخل یک تسک از متغییر استفاده کردیم ،انسیبل ابتدا در خود task ،سپس در دایرکتوری vars ،سپس در دایرکتوری host_vars و فایل مربوط به اسم موجودیتمون (اگر داخل playbook موجودیت develope رو برای اون تسک ست کرده باشیم ،انسیبل داخل host_vars درون develope.yml دنبال اون متغییر میگرده) و سپس داخل group_vars به همون منوال در اولین مسیری که اون متغییر رو پیدا کنه از مقدار اون استفاده خواهد کرد


#ansible
#CM

@code_crafters