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


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

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


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

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

مرحله اول:
ابتدا یک بات تلگرامی میسازیم

به بات پدر @BotFather رفته  و استارت رو میزنیم
درخواست newbot/ رو میزنیم
از ما یک اسم میخواد که اسمش رو میزاریم backup
از ما یوزرنیم میخواد که با bot اتمام شود که ترکیبی مینویسیم bakup<projectname>bot

و بعد از اتمام پیغام موفقیت و در آن token bot رو میگیریم و نگه میداریم و این توکن رو با نام BOT_TOKEN میشناسیم

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

به ربات @raw_data_bot رفته استارت رو میزنیم سپس chat رو انتخاب میکنیم و از میان لیست باز شده گروه خصوصی ساخته شده رو بهش میدیم و chat id رو ازش میگیریم و نگه میداریم و با نام CHAT_ID اون رو میشناسیم

اماده سازی سرور
مراحل رو گام بگام پیش میریم

مرحله اول:
با دستور docker ps نام کانتینر پستگرس رو نگه میداریم و با نام CONTAINER_NAME میشناسیم

نام دیتابیس ما در پستگرس رو هم با DB_NAME میشناسیم

اگر پسورد شما با نام دیتابیس متفاوت هست اون رو هم نگه دارید و اگه پورت پیش فرض رو هم تغییر داده‌اید اون رو هم لازم دارید(ما تصور میکنیم که پورت پیش فرض و پسورد دیتابیس با نام اون یکسان است)

مرحله دوم:
ساخت یک دایرکتوری برای بکاپ‌ها

در یک مسیر دلخواه در سرور یک دایرکتوری با اسم backups میسازیم 
mkdir backups
chmod 777 backups
cd backups

سپس مسیر آنرا با دستور زیر خواهیم گرفت
pwd 
این مسیر رو نگه میداریم و با نام PATH میشناسیم

مرحله سوم:
ساخت یک فایل حاوی کدهای بش اسکریپت
یک فایل با نام backup.sh ساخته و کدهای زیر رو در اون قرار میدیم

sudo nano backup.sh

کدهای زیر رو در اون بزارید

#!/bin/bash

docker exec -t <CONTAINER_NAME> pg_dumpall -c -U <DB_NAME> > <PATH> backup_$(date +%Y%m%d-%H%M).sql


curl -s -X POST -F chat_id=<CHAT_ID> -F caption=<CAPTION> -F document=@$(ls -t <PATH> backup_*.sql | head -1) https://api.telegram.org/bot<BOT_TOKEN>/sendDocument


find <PATH> -type f -name "backup_*.sql" -mtime +7 -exec rm {} \;

توضیحات کد
در خط اول به کانتینر وصل شده و فایل بکاپ رو گرفته و در دایرکتوری backups ذخیره میکنیم درون اسم فایل بکاپ تایم رو هم میگذاریم

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

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

نکته: درون فایل بش اسکریپتی مقادیری رو که گفتیم با این نام میشناسیم رو با مقدار مطابق خودشون در این فایل جابجا کرده و فایل رو ذخیره میکنیم در مقدار <CAPTION> متن دلخواه خود را بزارید


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

sudo ./backup.sh

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

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

دستور crontab -e رو میزنیم

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

و مقدار زیر رو به فایل اصافه کرده و ذخیره میکنم
0 24 * * * <PATH>backup.sh

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


#postgresql

@code_crafters

اسکریپت اصلاح شده توسط سعید(کاکوی گروه)

پروکسی اضافه شد(برای استفاده در کشورهای جهان اولی فیلتری و تحریمی)
فایل زیپ شد(از تغییر ناگهانی هنگام انتقال و نگهداری فایل‌ بکاپ جلوگیری میکنه و سبکتر هم جهت ارسال ارسال میشه)
متغییرها کاملتر و بهتر کنترل شده
چندین بار جهت اطمینان از ارسال فایل چک میکنه برامون

-----------------

#!/bin/bash


CONTAINER_NAME=<your_container_name>
DB_NAME=<your_database_name>
PATH=<your_backup_path>
CHAT_ID=<your_chat_id>
CAPTION=<your_caption>
BOT_TOKEN=<your_bot_token>
PROXY_URL=<your_proxy_url>
 


docker exec -t $CONTAINER_NAME pg_dumpall -c -U $DB_NAME | gzip > $PATH/backup_$(date +%Y%m%d-%H%M).sql.gz


send_backup() {
    curl -s -X POST \
         -F chat_id=$CHAT_ID \
         -F caption=$CAPTION \
         -F document=@$(ls -t $PATH backup_*.sql.gz | head -1) \
         --proxy $PROXY_URL 
         https://api.telegram.org/bot$BOT_TOKEN/sendDocument
}


MAX_RETRIES=3
for ((i=1; i<=MAX_RETRIES; i++)); do
    send_backup && break || sleep 5  # Retry with 5-second delay
done

# Remove files older than a week
find $PATH -type f -name "backup_*.sql.gz" -mtime +7 -exec rm {} \;


--------------

حالا که خوشتون اومده یکم‌ بهتر تر اش کنیم
- هم وضعیت هر تسک رو لاگ کنه
- هم چک کنه اگر بکاپ‌ای تنبلی کرده نرفته جایی که باید بره 😁 مجدد بفرسته در اجرای بعدی تا برههه
- عملیات رفته توی یک فانکشن.
- پراکسی اختیاری برای سرورای ایران که تلگرام فیلتره
- هندل خطا و retry در صورت ناموفق بودن
ابتدای فایل متغیر های محلی رو تمیز تر تعریف کردیم که خوانا و منطبق با فرمایشات آنکل باب باشه:

dbBackupSyncScript.sh:

-------------

#!/bin/bash

# Configuration (replace with your details)
CONTAINER_NAME=<your_container_name>
DB_NAME=<your_database_name>
PATH=<your_backup_path>
CHAT_ID=<your_chat_id>
CAPTION=<your_caption>
BOT_TOKEN=<your_bot_token>
PROXY_URL=<your_proxy_url>  # Optional for limited network environments

# Function to send backup with retries and logging
send_backup() {
    local filename=$(ls -t $PATH backup_*.sql.gz | head -1)
    for ((i=1; i<=MAX_RETRIES; i++)); do
        if curl -s -X POST \
             -F chat_id=$CHAT_ID \
             -F caption="$CAPTION (Attempt $i)" \
             -F document=@"$filename" \
             --proxy $PROXY_URL \  # Uncomment if using proxy
             https://api.telegram.org/bot$BOT_TOKEN/sendDocument; then
            echo "$(date +%Y-%m-%d-%H:%M): Backup $filename sent successfully." >> $PATH/backup_log.txt
            return 0
        else
            echo "$(date +%Y-%m-%d-%H:%M): Error sending backup $filename (Attempt $i): $?" >> $PATH/backup_log.txt
            sleep 5
        fi
    done
    return 1
}

# Constants
MAX_RETRIES=3
LOG_FILE="$PATH/backup_log.txt"

# Create log file if it doesn't exist
touch "$LOG_FILE"

# Make compressed database backup dump file
docker exec -t $CONTAINER_NAME pg_dumpall -c -U $DB_NAME | gzip > $PATH/backup_$(date +%Y%m%d-%H%M).sql.gz

# Send backup and handle retries
send_backup || echo "$(date +%Y-%m-%d-%H:%M): Failed to send backup after $MAX_RETRIES attempts. See $LOG_FILE for details."

# Check and resend undelivered backups (if any)
unsent_files=$(find $PATH -type f -name "backup_*.sql.gz" ! -name "$(tail -n 1 $LOG_FILE | cut -d ':' -f 2- | cut -d ' ' -f 2)")
if [[ ! -z "$unsent_files" ]]; then
    echo "$(date +%Y-%m-%d-%H:%M): Found undelivered backups. Retrying..." >> $LOG_FILE
    for file in $unsent_files; do
        send_backup "$file" && echo "$(date +%Y-%m-%d-%H:%M): Undelivered backup $file sent successfully." >> $LOG_FILE
    done
fi

# Remove files older than a week
find $PATH -type f -name "backup_*.sql.gz" -mtime +7 -exec rm {} \;

-----------

ریلیز 1.1.2

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

و ریلیز 1.1.4 با قابلیت تست بکاپ بصورت اتومات در کانتینر پستگرس

@code_crafters

بخونید جالبه.
چرا کلادفلیر تصمیم گرفت استفاده از nginx رو کنار بزاره و خودش یک ریورس پراکسی خیلی بهینه تر با rust بنویسه (که گویا یک سوم طراحی قبلی شون مصرف منابع داره و منعطف تره، بعلاوه حل بسیاری از ضعف ها و چالش هاشون با nginx مثل کامیونیتی نه چندان فعال که گویا زیاد اجازه بهتر کردنش رو بهشون نمیداده، با زبان C خالص بودن و ریسک و مشکلات حافظه ای، توسعه خیلی پیچیده بخاطر زبان C، مشکلات مقیاس پذیری، ورکر پراسس ها کانکشن های زیاد، retry، load balance و ... )در مقیاس یک cdn واقعا بزرگ حرف میزنیم!))
واقعا rust قابل تحسینه 👌 (و پروژه کلادفلیر)

https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet

Physics

#free

@code_crafters

بچه‌هایی که بهم نزدیک هستند و میشناسن من رو میدونن که من هیچ علاقه‌ای به کامپیوتر و رشته‌ام ندارم ، علاقه وافر من در واقع به منطق کلام هست بابت همین بیشتر کتاب‌های فلسفه و روانشناسی میخونم (بگذریم)


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

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


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

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


#book
#free

@code_crafters

در ادامه مبحث انسیبل بریم سراغ کانفیگ کردنش

در پست‌های قبلی ما راجب inventory ,eole, playbook , task و ... خوندیم

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

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

ansible-playbook playbooks/main.yml

که با معرفی مسیر inventory به شکل زیر میتونیم این مشکل رو برطرف کنیم

ansible-playbook -i inventory/main.yml playbooks/main.yml

اما بازهم خطای شناخت roles هارو داریم

ما باید مسیر هرکدوم رو برای انسیبل مشخص کنیم که اینکار رو در فایلی با نام ansible.cfg در دایرکتوری کاریمون(base-ansible) انجام میدهیم

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

[defaults]
inventory           = ./inventory/main.yml
remote_tmp          = /tmp
forks               = 150
sudo_user           = root
remote_user         = root
roles_path          = ./roles
host_key_checking   = False
log_path            = ./log/ansible.log

[privilage_escalation]
#become=True
#become_method      = sudo
#become_user        = root
#become_ask_pass    = False

[ssh_connection]
scp_if_ssh  = True

توضیحات مربوط به این پیکربندی

در قسمت default

در قسمت inventory مسیر موجودیت‌هامون رو مشخص میکنیم

در قسمت remote temp مسیر نگه داشتن فایل‌های موقت در طول زمان احرا در سرور

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

در قسمت sudo user مشخص میکنیم که انسیبل با چه سطح دسترسی وظایف رو در سرورها اجرا کند که با دسترسی sido کاربر root براش معین کردیم 

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

در قسمت roles هم مسیر roles رو مشخص کردیم 

در قسمت host key checking مشخص میکنیم آیا انسیبل کلید ssh بررسی کند که در اینجا غیرفعال هست چون تو محیط یادگیری و تست هستیم

در قسمت log path مشخص کردیم که انسیبل لاگ‌های حین اجرا رو در کجا بزاره (بنابراین دایرکتوری با نام log در مسیر دایرکتوری کاریمون base-ansible میسازیم و داخل اون یک فایل ansible.log میسازیم ازین ببعد لاگ خروجی رو میتونیم در این فایل مشاهده کنیم بعد هربار اجرا کردن انسیبل)

در بخش privilege escalation رو داریم که کامیت شده و دلیل اون استفاده از کاربر root در بخش قبلی بود اگر کاربر دیگه رو انتخاب میکردیم در این بخش مشخص میکردیم که هر playbook ی که دارای مقدار become بود با سطح دسترسی چه کاربری این تسک رو انجام بده

و در نهایت در بخش سوم هم اجازه استفاده از s p جهت انتقال فایل‌هامون از طریق ssh رو به انسیبل داده‌ایم (برای مثال فایل‌هایی که در بخش files و ... در role هامون مشخص کرده بودیم)

و در نهایت ساختار این فایلمون هم بصورنچت init میباشد

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

ansible-playbook playbooks/git.yml

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

ssh-keygen -t rsa

ssh-copy-id username@server_address

ssh username@server_address

حالا کافیه که دستور زیر رو بزنیم تا بدون مشکل انسیبل اجرا بشه و لاگ رو هم در مسیر log و فایل ansible.log که داخلش ساختیم هم ببینیم و نگه داریم برای بعدا

ansible-playbook playbooks/main.yml

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

#ansible
#CM

@code_crafters

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

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



سعی میکنم تا جای ممکن کامل و جامع توضیحات اون رو بهتون برسونم


لینک وبسایت

#book
#concurrency

@code_crafters

Top 5 #Caching Strategies


https://www.linkedin.com/posts/isharanimicrosoftleader_%3F%3F%3F-5-%3F%3F%3F%3F%3F%3F%3F-%3F%3F%3F%3F%3F%3F%3F%3F%3F%3F-activity-7110477190512721920-AVBG?trk=public_profile_like_view