CodeCrafters

بریم سراغ 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

در این قسمت میرسیم به مبحث 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

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

در ادامه پست های مربوط به 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

معرفی کتاب خب کتاب از کتابهای معروف و از انتشاراتی بین الملل و نامداری هست که ترجمه شده کتاب بابت مقدمات هست و این جلد از کتاب ده فصل از کتاب اصلی رو پوشش داده فصل اول اون واقعا شاهکار بود در حدی که ازش عکس گرفتم و قبلا براتون در کانال گذاشتم زیاد به مسائل ریاضیات نپرداخته ولی جایی لازم بوده مطرح کرده خودش بصورت آموزش محور پیش میره و از دیتاست‌های همیشگی و معروف استفاده کرده کدها کاملا بروز و کار میکنن سعی کرده تا جای ممکن مطالب رو پوشش بده در خصوص گرادیان مطالبی گفته که معمولا در هر آموزشی نمیگن ، در یک جاهایی کم کاری دیده شده یعنی میتونست موارد بیشتری رو بگه بهمون ،یجاهایی هم واقعا گیج میشی که چه اتفاقی افتاد و دلیلش رو شاید من بتونم بگم بابت توضیح ندادن جامع چند مورد در یکجا هست یعنی ذره ذره رفته جلو و گفته موارد رو تک به تک برامون ، اما مجدد میگم مطالبی رو گفته که خیلی جاها شاید نگن راجبش کتاب خوبیه و توصیه میکنم یک آموزش ویدیویی هم ببینید کنارش جلد دوم کتاب که در خصوص یادگیری عمیق هست رو نخوندم هنوز ،یک پروژه رو شروع کردم و مجبور شدم سویچ کنم رو یک کتاب دیگه #book #ML @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

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

تعریفی از 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

پروفایل کردن چیست؟؟؟ در طی طراحی یک برنامه همیشه این سوال برامون پیش میاد که کد و کوئری ما بهینه هست یا نه ،چقدر منابع مصرف میکنه(حافظه ، 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
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

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

http://localhost:8000/silk

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

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

گویا یک مهندس دیگر هم در یوتیوب زحمت کشیده و داره دوره جامعی رو براش منتشر میکنه https://www.youtube.com/playlist?list=PLe_DUrcBPdbIRye6Dw_UdhR8a7Zqvb_BA

یکی از موضوعات دوست داشتنی در نوش مصنوعی ریاضیاتش هست که همه از دستش فرار میکنیم از بس که جذاب هست یکی ازین کتاب‌ها با عنوان جبرخطی شناخته میشه که از خود ریاضیات بیشتر دوست داشتنی تره😅😅😅 یک مهندس عزیز در اینترنت سعی کرده که این مورد رو با زبان ساده آموزش بده تا شیرینیش رو ازش بگیره براتون لینکش رو در زیر براتون میزارم 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 @code_crafters

وبینار مقایسه پلتفرم‌های ابری VMware و OpenStack ☁️ مواردی که در این وبینار به آنها خواهیم پرداخت: - Network - API - Deployment - Multi-Tenancy - Disaster Recovery - Security - Cloud Compatibility - Q&A - ... 📆 یکشنبه ۲۹ بهمن ۱۴۰۲ ⏰ ساعت ۱۹ الی ۲۱ ✅ ثبت‌نـام رایگان وبیـنار ‌ @xaascloud | ابـر زَس ‌

در پست قبلی اومدیم انسیبل رو معرفی کردیم اندکی هم راجب 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

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

دوستان عزیزم جوین شید کم کم که چهار پنج دیقه دیگه شروع میکنیم ❤️🙏 https://meet.google.com/uui-wqur-vrr?authuser=0

بچه‌ها وعده‌ی ما امشب ساعت 8 ان شالله در خدمتتون هستیم. اگر دوست داشتید توسط لینک زیر میتونید توی گوگل کلندر خودتون اضافه اش کنید: https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MWJwOGozdDl2OGVoM2xtcnAwbGlmZnQwNXIgYWxpLnZpc3VhbC5zdHVkaW9AbQ&tmsrc=ali.visual.studio%40gmail.com

موضوعاتی که توی جلسه ی بعدی میخوایم پیگیری کنیم: 1. چالش‌هایی که توی هرکدوم (میکروسرویس و مونولیت) میخوریم؟ 2.کارهایی که توی Easy microservices انجام دادیم؟ 3.چطوری یک معمار بشیم؟ چطوری نرم افزارهای بزرگ رو معماری کنیم؟ 4. چقدر و چطوری درگیر دیتابیس‌ها بشیم؟ 5. از چت جی پی تی استفاده کنیم؟ نکنیم؟ چطوری؟ 6. مهارت های نرم و سافت اسکیل هامون رو چطوری تقویت کنیم؟ مهارت های ارتباطی.

سنیور به کسی میگن که بلده ساز خوب بزنه اما اکسپرت کسی هست که ساز خودش رو خوب میزنه (تلفیق موسیقی کوردی و اسپانیایی) #fun @code_crafters

روابط در پایگاه داده ها انواع روابط به طور کلی، سه نوع رابطه در پایگاه داده ها داریم: رابطه یک به یک: مانند رابطه هر فرد با شناسنامه اش. هر فرد یک شناسنامه دارد و هر شناسنامه فقط برای یک نفر است. رابطه یک به چند: مانند رابطه مادر و فرزندانش. هر فرزند فقط یک مادر دارد، ولی هر مادر می تواند چند فرزند داشته باشد. رابطه چند به چند: مانند رابطه دانش آموز و درس. هر دانش آموز می تواند چند درس را انتخاب کند و هر درس می تواند توسط چند دانش آموز انتخاب شود. الان مسئله اصلی مطرح میشود چه فرقی بین رابطه Foreign Key (کلید خارجی ) با رابطه یک به چند وجود دارد ؟؟؟ بهتر این طوری شروع کنیم : هر رابطه کلید خارجی یک رابطه یک به چند است، اما هر رابطه یک به چند یک رابطه کلید خارجی نیست. =) کمی در ابتدا گیچ کننده است .

چشمها را بايد شست جور ديگر بايد ديد

ما هم باید از دید پایگاه داده ها این مورد ببینیم آیا وقتی شما رابطه یک به چند می زنید بر روی جدول هایی شما چیزی اضافه میشود؟؟ شاید ندانید ولی در حقیقت خیر !! شاید شما بگید ما داریم اینجا زحمت میکشم 😂 پس این رابطه یک به چند ما چی شده است باید به ارزتان برسانم . وجود دارند ولی بر روی جدول ها چیزی اضافه نمی شود و در بیرون جدول ها قرار میگیرند. یک چیزی مثل قانون هستند به برنامه خود دستور میدهید که این جدول با این جدول به این صورت رفتار کند و کاری به ستون ها در پایگاه داده ندارید ولی در رابطه کلید خارجی قدمی جلوتر میروید و بروی جدول یک ستون ایجاد میکند

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

استفاده از کلید خارجی سرعت بیشتری دارد و موجب راحت تر دسترسی به داده ها می شود و مهم ترین نکته آن این است که اجازه نمیدهد که همین طوری داده ای وارد پایگاه داده کنید و یا از آن حذف کنید. با این حال، استفاده از کلید خارجی همیشه ضروری نیست قرار نیست با یادگیری هر چیزی از آن حتما استفاده کنید. در برخی موارد، ممکن است استفاده از روش‌های دیگر برای پیاده‌سازی رابطه یک به چند مناسب‌تر باشد. به عنوان مثال، اگر تعداد رکوردها در جدول فرزند کم باشد شما با استفاده از کلید خارجی موجب افزایش حجم جدول والد با اضافه شدن یک ستون دیگر مشکل در آپدیت اطلاعات فرزند و عدم انعطاف پذیری (نمی توان همین طوری اطلاعات را وارد یا حذف کنید) خلاصه همین طوری ازش استفاده نکنید و اگه استفاده کردید فرق آن را بدانید . #Database @Code_Crafters

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