هیوادار -

پشتیبانگیری از کانتینر و volume داکر MySQL

یک اسکریپت نوشتم که هر روز از volume کانتینر MySQL پشتیبان بگیره و ذخیره کنه و برای تست هم خود کانتینر با volume اش رو پاک کردم و و دوباره بک آپ رو برگردوندم و تمامی جدول ها و داده های توی اون هم برگشت.

کامند پشتیبان گیری:

docker run --rm --volumes-from mysql_test -v /c/code/msyqltest/backup:/backup busybox tar cvfz /backup/mysql_data_backup.tar --directory=/var/lib/mysql .
docker run --rm --volumes-from mysql_test -v /c/code/msyqltest/backup:/backup busybox tar cvfz /backup/mysql_config_backup.tar --directory=/etc/mysql/conf.d  .

docker run --rm --volumes-from mysql_test -v /c/code/msyqltest/backup:/backup busybox tar cvfz /backup/mysql_data_backup.tar --directory=/var/lib/mysql .

docker run --rm --volumes-from mysql_test -v /c/code/msyqltest/backup:/backup busybox tar cvfz /backup/mysql_config_backup.tar --directory=/etc/mysql/conf.d .

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

docker run --rm --volumes-from mysql_test -v /c/code/msyqltest/backup:/backup busybox sh -c "cd /var/lib/mysql && tar xvf /backup/mysql_data_backup.tar --strip 1"
docker run --rm --volumes-from mysql_test -v /c/code/msyqltest/backup:/backup busybox sh -c "cd /etc/mysql/conf.d && tar xvf /backup/mysql_config_backup.tar --strip 1"

docker run --rm --volumes-from mysql_test -v /c/code/msyqltest/backup:/backup busybox sh -c "cd /var/lib/mysql && tar xvf /backup/mysql_data_backup.tar --strip 1"

docker run --rm --volumes-from mysql_test -v /c/code/msyqltest/backup:/backup busybox sh -c "cd /etc/mysql/conf.d && tar xvf /backup/mysql_config_backup.tar --strip 1"

لازمه که بدونیم که خود کانتینر با compose زیر ساخته شده و دو تا volume داره:

version: '3.8'

services:
    mysql:
        image: mysql
        container_name: mysql_test
        restart: always
        hostname: mysql.local
        environment:
            discovery.type: single-node
            MYSQL_ROOT_PASSWORD: test
            MYSQL_DATABASE: test_database
        ports:
            - 3306:3306
        volumes:
          - mysql_data:/var/lib/mysql     
          - mysql_config:/etc/mysql/conf.d 

volumes:
  mysql_data:
    driver: local
  mysql_config:
    driver: local

version: '3.8'

services:

mysql:

image: mysql

container_name: mysql_test

restart: always

hostname: mysql.local

environment:

discovery.type: single-node

MYSQL_ROOT_PASSWORD: test

MYSQL_DATABASE: test_database

ports:

- 3306:3306

volumes:

- mysql_data:/var/lib/mysql

- mysql_config:/etc/mysql/conf.d

volumes:

mysql_data:

driver: local

mysql_config:

driver: local

فایل Compose برای MySQL

میخایم یه کانتینر از MySQL بسازیم به صورتی که فایلهای دیتابیس شامل کانفیگ هاش توی یک volume ذخیره بشه.

برای این کار باید فایل compose به صورت زیر باشه:

version: '3.8'

services:
    mysql:
        image: mysql
        container_name: mysql_test
        restart: always
        hostname: mysql.local
        environment:
            discovery.type: single-node
            MYSQL_ROOT_PASSWORD: test
            MYSQL_DATABASE: test_database
        ports:
            - 3306:3306
        volumes:
          - mysql_data:/var/lib/mysql     
          - mysql_config:/etc/mysql/conf.d 

volumes:
  mysql_data:
    driver: local
  mysql_config:
    driver: local

version: '3.8'

services:

mysql:

image: mysql

container_name: mysql_test

restart: always

hostname: mysql.local

environment:

discovery.type: single-node

MYSQL_ROOT_PASSWORD: test

MYSQL_DATABASE: test_database

ports:

- 3306:3306

volumes:

- mysql_data:/var/lib/mysql

- mysql_config:/etc/mysql/conf.d

volumes:

mysql_data:

driver: local

mysql_config:

driver: local

مقایسه docker volume و bind mount

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

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

توی داکر میشه بجای volume از bind mount هم استفاده کرد. bind mount ساده است مثل اینکه یک فولدر رو بین کانتینر و هاست فعلی به اشتراک بزاریم.

حالت بعدی استفاده از tmpfs هست که فقط در صورتی که هاست لینوکس باشه قابل استفاده است. و این دیتا توی حافظه memory ذخیره میشه بنابراین دائمی نیست.

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

پشتیبانگیری از docker containers

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

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

docker rm -v

اگر همه کانتینرهایی که با یک volume کار میکنن رو پاک کنیم، پاک کردن و دسترسی به اون volume سخت میشه. به این volume ها میگن dangling volume. برای اینکه dangling volume وجود نداشته باشه بهتره همیشه یک کانتینر مرتبط با اون volume بسازیم.

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

image های داکر

از کانتینرهای داکر

از volume های موجود

نصب gitlab روی داکر

میخایم gitlab رو روی داکر بالا بیاریم. برای این کار از docker compose استفاده میکنیم. فایل compose.yml زیر رو مینویسیم:

version: '3.6'
services:
  gitlab:
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'localhost'
    environment:
        discovery.type: single-node              
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - '$GITLAB_HOME/config:/etc/gitlab'
      - '$GITLAB_HOME/logs:/var/log/gitlab'
      - '$GITLAB_HOME/data:/var/opt/gitlab'
      
    shm_size: '256m'

version: '3.6'

services:

gitlab:

image: 'gitlab/gitlab-ce:latest'

restart: always

hostname: 'localhost'

environment:

discovery.type: single-node

ports:

- '80:80'

- '443:443'

volumes:

- '$GITLAB_HOME/config:/etc/gitlab'

- '$GITLAB_HOME/logs:/var/log/gitlab'

- '$GITLAB_HOME/data:/var/opt/gitlab'

shm_size: '256m'

این یه کانتینر از gitlab-ce میسازه که پورتهاش رو به هم مپ میکنه.

environment variable ای که استفاده شده GITLAB_HOME رو لازمه با دستور زیر تعریف کنیم

extport GITLAB_HOME=/path/to/it

1	extport GITLAB_HOME=/path/to/it

یا کار بهتر اینه که فایل custom.sh رو توی /etc/profile.d/ میسازیم و اون اکسپورت رو توش میزاریم.

قسمت environment توی فایل کامپوز برای متغیرهای توی خود کانتینر هست و ربطی به سرور اصلی نداره.

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

docker compose up -d

1	docker compose up -d

دستورات اولیه نصب Odoo

دستورات تست شده برای نصب Odoo رو توی این پست میارم:

sudo apt update
sudo apt install 

git 
python3-pip 
build-essential 
wget 
python3-dev 
python3-venv
python3-wheel
libfreetype6-dev
libxml2-dev
libzip-dev
libldap2-dev
libsasl2-dev
python3-setuptools
node-less
libjpeg-dev
zlib1g-dev
libpq-dev
libxslt1-dev
libldap2-dev
libtiff5-dev
libjpeg8-dev
libopenjp2-7-dev
liblcms2-dev
libwebp-dev
libharfbuzz-dev
libfribidi-dev
libxcb1-dev




useradd -m -d /opt/odoo17 -U -r -s /bin/bash odoo17

su - postgres -c "createuser -s odoo17"

wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6-1/wkhtmltox_0.12.6-1.bionic_amd64.deb
sudo apt install ./wkhtmltox_0.12.6-1.bionic_amd64.deb


sudo su - odoo17
cd /opt/odoo17/

git clone https://www.github.com/odoo/odoo --depth 1 --branch 17.0 /opt/odoo17/odoo

python3 -m venv odoo-venv
source odoo-venv/bin/activate


pip3 install wheel
pip3 install -r odoo/requirements.txt


deactivate

mkdir /opt/odoo17/odoo-custom-addons

exit 


vim /etc/odoo17.conf

[options]  ; This is the password that allows database operations:
admin_passwd = amir
db_host = False
db_port = False
db_user = odoo17
db_password = False
addons_path = /opt/odoo17/odoo/addons,/opt/odoo17/odoo-custom-addons


vim /etc/systemd/system/odoo17.service

[Unit]  
Description=Odoo17  
Requires=postgresql.service  
After=network.target postgresql.service    

[Service]  
Type=simple  
SyslogIdentifier=odoo17  
PermissionsStartOnly=true  
User=odoo17  
Group=odoo17  
ExecStart=/opt/odoo17/odoo-venv/bin/python3 /opt/odoo17/odoo/odoo-bin -c /etc/odoo17.conf  
StandardOutput=journal+console    

[Install]
WantedBy=multi-user.target


systemctl daemon-reload

sudo systemctl start odoo17
systemctl enable --now odoo17

systemctl status odoo17

journalctl -u odoo17

http://192.168.142.135:8069/

100

101

102

103

sudo apt update

sudo apt install

git

python3-pip

build-essential

wget

python3-dev

python3-venv

python3-wheel

libfreetype6-dev

libxml2-dev

libzip-dev

libldap2-dev

libsasl2-dev

python3-setuptools

node-less

libjpeg-dev

zlib1g-dev

libpq-dev

libxslt1-dev

libldap2-dev

libtiff5-dev

libjpeg8-dev

libopenjp2-7-dev

liblcms2-dev

libwebp-dev

libharfbuzz-dev

libfribidi-dev

libxcb1-dev

useradd -m -d /opt/odoo17 -U -r -s /bin/bash odoo17

su - postgres -c "createuser -s odoo17"

wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6-1/wkhtmltox_0.12.6-1.bionic_amd64.deb

sudo apt install ./wkhtmltox_0.12.6-1.bionic_amd64.deb

sudo su - odoo17

cd /opt/odoo17/

git clone https://www.github.com/odoo/odoo --depth 1 --branch 17.0 /opt/odoo17/odoo

python3 -m venv odoo-venv

source odoo-venv/bin/activate

pip3 install wheel

pip3 install -r odoo/requirements.txt

deactivate

mkdir /opt/odoo17/odoo-custom-addons

exit

vim /etc/odoo17.conf

[options] ; This is the password that allows database operations:

admin_passwd = amir

db_host = False

db_port = False

db_user = odoo17

db_password = False

addons_path = /opt/odoo17/odoo/addons,/opt/odoo17/odoo-custom-addons

vim /etc/systemd/system/odoo17.service

[Unit]

Description=Odoo17

Requires=postgresql.service

After=network.target postgresql.service

[Service]

Type=simple

SyslogIdentifier=odoo17

PermissionsStartOnly=true

User=odoo17

Group=odoo17

ExecStart=/opt/odoo17/odoo-venv/bin/python3 /opt/odoo17/odoo/odoo-bin -c /etc/odoo17.conf

StandardOutput=journal+console

[Install]

WantedBy=multi-user.target

systemctl daemon-reload

sudo systemctl start odoo17

systemctl enable --now odoo17

systemctl status odoo17

journalctl -u odoo17

http://192.168.142.135:8069/

Coroutine و Awaitables

Coroutine در واقع یک تابع هست که میتونیم اونو pause کنیم. فرض کنیم دو تا تابع داریم و میخایم کنترل اجرا بین این دو تا جابجا بشه مثل ping pong مثلا تابع اول چند خط رو اجرا کنه بعد کنترل رو به تابع دوم بده و اون چند خط اجرا کنه و … در واقع دو تا routine که اینجا بهشون میگیم تابع با هم cooperate کنن.

برای تریفش توی پایتون از async کلیدواژه استفاده میکنیم. که اون وقت اون تابع coroutine میشه. میتونیم هر جای کد coroutine ازش بخایم وایسه تا اجرای یه تابع دیگه تموم شه برای این کار await میکنیم.

مقایسه Celery و Channels و Singnal

در جدول زیر مقایسه Celery و Django Channels و Django Signals رو میبینیم

Here’s a comparison of Django Channels, Django Signals, and Celery, presented in a tabular format, focusing on their use cases, features, and suitable scenarios:

Feature/Aspect	Django Channels	Django Signals	Celery
Primary Use Case	Real-time communication, WebSockets, and long-lived connections	Decoupled event handling within Django applications	Asynchronous task queue/job queue for running background tasks
Communication	WebSockets, HTTP2, server-sent events	In-process communication within the same Django app	Distributed communication, allowing task distribution across multiple workers
Concurrency	Handles concurrent connections and async processing	Synchronous, works within the Django request-response cycle	Handles concurrent tasks, designed for parallel processing
Scalability	Scalable for handling many concurrent connections	Limited by the Django process	Highly scalable, can distribute tasks across multiple servers
Real-time Updates	Yes, supports real-time updates	No	No, tasks are run asynchronously but not in real-time
Event Handling	Handles real-time events	Handles events within the Django lifecycle (e.g., model save, user login)	Handles events as background tasks
Persistent Connections	Yes, supports long-lived connections (e.g., chat apps)	No, operates within the request-response cycle	No, designed for discrete, short-lived tasks
Integration	Integrates with WebSockets, WebRTC, etc.	Integrates with Django ORM and lifecycle hooks	Integrates with message brokers (RabbitMQ, Redis, etc.)
Typical Use Cases	Chat applications, live notifications, live dashboards	Sending signals on model changes, user actions	Sending emails, processing data, generating reports, scheduled tasks
Example	Live chat app with instant messaging	Logging changes to models when saved	Sending periodic email reports, processing user-uploaded files in the background
Fault Tolerance	Basic fault tolerance, relies on infrastructure	Basic, depends on Django’s fault tolerance	High fault tolerance, can retry failed tasks, distributed task execution
Dependencies	Redis, RabbitMQ (for channel layers)	None beyond Django	Message broker (e.g., RabbitMQ, Redis), result backend (optional)
Ease of Use	Requires understanding of asynchronous programming	Simple to use with Django	Requires setup of a message broker and understanding of task queues

Detailed Use Case Examples

Django Channels:
- Chat Application: Users can send and receive messages in real-time, with updates being pushed to all connected clients instantly.
- Live Notifications: Real-time notifications for events such as new comments, likes, or mentions in a social media application.
- Live Dashboard: Real-time updates of metrics and analytics in a monitoring dashboard.
Django Signals:
- Model Change Notifications: Automatically trigger a function to log changes or send an email when a model instance is saved or deleted.
- User Activity Tracking: Capture user login, logout, or profile update events to maintain an activity log.
- Post-Processing: Perform additional actions after saving a model, such as updating related records or sending a confirmation email.
Celery:
- Email Sending: Send emails asynchronously to avoid blocking the main thread during the request-response cycle.
- Data Processing: Handle large data processing tasks, such as generating reports or processing user-uploaded files, in the background.
- Scheduled Tasks: Run periodic tasks like clearing expired sessions, generating nightly reports, or updating external APIs.

By comparing these tools, you can choose the most appropriate solution based on the specific requirements and characteristics of your project.

database_sync_to_async و async_to_sync

کاربرد این دوتابع در django channels هست. به طور کلی وقتی توی یه consumer که به صورت Asynchronous تعریف شده بخایم از یک تابع Synchronous استفاده کنیم باید اون رو به Asynchronous تبدیل کنیم و برعکس و کاربرد این دو تابع همینه.

میدونیم که ORM جنگو Synchronous هست بنابراین وقتی توی یه کانسومر Asynchronous ازش استفاده میکنیم باید اونو توی database_sync_to_async بزاریمو

میدونیم که Channel Layer ها ذاتا Asynchronous هستند و همه متدهای اون مثل self.send group_send و group_add همگی Async هستند بنابراین اگر بخایم توی یه کلاس sync ازشون استفاده کنیم باید از async_to_syn استفاده بشه.

لازم به ذکر است که channels.db.database_sync_to_async یک wrapper از asgiref.sync.sync_to_async هست که بعد از کانکشن دیتابیس رو هم clean میکنه

برای استفاده از اون بهتره اول خود query رو توی یه تابع بنویسیم بعد اون تابع رو بدیم به این تابع مثل:

from channels.db import database_sync_to_async

async def connect(self):
    self.username = await database_sync_to_async(self.get_name)()

def get_name(self):
    return User.objects.all()[0].name

from channels.db import database_sync_to_async

async def connect(self):

self.username = await database_sync_to_async(self.get_name)()

def get_name(self):

return User.objects.all()[0].name

یا

from channels.db import database_sync_to_async

async def connect(self):
    self.username = await self.get_name()

@database_sync_to_async
def get_name(self):
    return User.objects.all()[0].name

from channels.db import database_sync_to_async

async def connect(self):

self.username = await self.get_name()

@database_sync_to_async

def get_name(self):

return User.objects.all()[0].name

Channel Layers توی Django Channels چیه؟

توی Django Channels هر instance توی یک پروسه اجرا میشه. اگر بخایم پیامی بین پروسه های مختلف برنامه یعنی به instance های مختلف ارسال بشه باید از مکانیسم Channels layer استفاده کنیم. یعنی اگر بخایم پیامی به شخصی دیگه ارسال بشه یا به گروه خاصی ارسال بشه باید از این مکانیسم استفاده کرد.

یعنی اگر بخایم بخش های مختلف برنامه یا consumer های مختلف با هم صحبت کنن باید از Layers استفاده کنیم.