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

از دیتابیس MySQL بک آپ گرفتیم به صورتی که این دیتابیس توی یک Docker Container بود که دیتای اون مپ شده به آدرس زیر. بنابراین با بک آپ از /var/lib/mysql تمامی دیتای این دیتابیس بک آپ گرفته میشه و میتونیم بعدا برداریم.

علاوه بر اون با استفاده از mysqldump هم از کل دیتابیس ها یک بک آپ توی فرمت sql گرفتم برای محکم کاری.

از طرفی این دیتا مربوط به یک وب اپلیکیشن هست که فایلهای آپلود شده و آواتارها و هر چیزی که آدرسش توی دیتابیس هست اما خود فایل توی /project/uploads ذخیره شده. بنابراین باید از این مسیر هم یک بک آپ بگیریم. نتیجه شد اسکریپت زیر:

دپلوی React و Django در Docker

برای دپلوی کردن یک پروژه Django و React در داکر با کانفیگ زیر کار میکنیم:

فایل بالا compose است و فایل backend/shiftsupervisor/Dockerfile

و فایل frontend/shiftfront/Dockerfile

و فایل nginx/nginx.conf

در ضمن تنظیمات مهم برای settings.py

فایل axiosConfig.jsx

و فایل vite.config.js

تنظیمات ssl روی Nginx

برای اینکه سرویس از https استفاده کند باید چند کار انجام دهیم.

1.فایل های certificate را در سرور بسازیم

2.درخواستهای http را به https ارجاع دهیم

3.تنظیمات https را در nginx تنظیم کنیم

4.در برنامه هرجا لازم است تغییراتی انجام میدهیم مثلا اگر تا الان از وب سوکت ws استفاده میشده باید الان از wss استفاده شود.

حواسمون باشه فایل های cert و key کلیدها باید با رشته های زیر تعریف شوند:

برای این تنظیمات در داکری که یه سری سرویس دارد از تنظیمات زیر استفاده میکنیم:

nginx.conf

فایل compose داکر

Docker base commands

مجموعه دستورات پر استفاده کار با داکر

پیاده سازی Odoo روی داکر Docker

برای پیاده سازی Odoo توی داکر باید اول docker-compose.yml رو داشته باشیم:

داکرفایل postgress:

یه فایل init.sql هم استفاده شده:

فایل odoo17.conf

از همه مهمتر Dockerfile خود Odoo:

سایز هدر و timeout توی پروژه وب

در نرم افزاری طول URL از حدی که بیشتر میشد سرور ارور بر میگردوند. با بررسی لاگ Nginx و uWSIG متوجه شدم که سایز هدری که مرورگر میفرسته از حدی بیشتره و سرور قبول نمیکنه. از طرفی اون عملیات زمان بر هم بود و وقتی که سایز هدر را هم بیشتر کردم باز هم چون طول میکشید سرور کانکشن رو میبست. با تنظیمات Nginx زیر تونستم هم طول هدر رو بیشتر کنم هم مدت زمان کانکشن ها:

فایل compose کل سرویس ها هم مثل زیره:

تغییر مسیر ذخیره فایلهای داکر

بعد از نصب داکر فایلهای مورد استفاده خود داکر از قبلی image هایی که load میکنید توی مسیر /var/lib/docker ذخیره میشه که میتونه بعد از مدتی پر شه یا اصلا شاید بخاید جای دیگه ای ذخیره بشه. من خودم چون پارتیشن دیگه ای با حجم بیشتر دارم خواستم یه دایرکتوری دیگه رو map کنم به این دایرکتوری. البته روش های مختلفی وجود داره برای تغییر مسیر اما بهترین روش با کمترین impact این روشه:

کامل ترش رو میشه توی این لینک ببینیم.

تنظیمات SElinux و مشکلاتی که برای داکر داره

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

توی اینترنت گفته بودن که درایور رو عوض کنیم و … اما در نهایت متوجه شدم چون selinux روی premisive بوده به داکر اجازه داده نمیشه که از دیسک با LVM کانفیگ شده استفاده کنه. اروری که نشون میده:

این ارور رو باید با کامند dockerd --debug ببینید

چطور فهمیدم که مشکل از selinux هست. سرور به دلایلی ریبوت شده بود و دیگه داکر بالا نیومده بود. قبلا یکی از دوستان selinux رو فعال کرده بود و طبیعتا تا بعد از ریبوت اعمال نمیشه. متوجه شدم احتمالا مشکل از اینه.

حالا توی فایل /etc/selinux/config کافیه اونو disable کنی و ریبوت. داکر دوباره start میشه.

استقرار پروژه جنگو با بهینگی بالا

در پروژه ای که در بستر داکر روی لینوکس پیاده سازی شده است نرم افزار از performance قابل قبولی برخوردار نیست. بخشی از نرم افزار با websocket کار میکند اما اکثرا در بستر http. دیتابیس، و بخشهای دیگر مثل celery, rabbitMQ و … هر کدام یک کانتینر هستند.

ایرادات استقرار یا deployment:

جنگو در یک کانتینر با دستور runserver اجرا شده است.

کل پروژه از Daphne به عنوان اپلیکیشن وب سرور ASGI استفاده میکند در حالی که بخش کوچکی از نرم افزار asyn است و با websocket کار میکند.

وب سروری مثل Nginx یا Apache وجود ندارد که فایلهای استاتیک را ارائه دهد.

بهتر بود در بخشهای Sync از اپلیکیشن سروری مثل uWSGI که یک WSGI هست استفاده میشد.

بنابراین معماری به شکل زیر تغییر یافت:

NGINX درخواست های websocket رو به Daphne و سایر درخواست ها را به uWSGI ارسال میکند. فایل های کانفیگ از قرار زیر است.

compose.yml

nginx.conf

DockerfileNginx

DockerfileNasim

لینک های مرتبط:

لینک 1

لینک 2

لینک 3

لینک 4

لینک 5

افزایش ظرفیت پارتیشن ها توی LVM

توی یه سرور RHEL که از LVM برای مدیریت دیسک و پارتیشن استفاده میشه، لازم شد که حجم رو افزایش بدیم. یه دیسک sdb داریم که میخایم به 2 تا پارتیشن اضافه اش کنیم. LVM این کار رو انجام میده بدون اینکه پارتیشن ها نیاز به فرمت داشته باشن و داده های قدیمی از دست برن. یه چیزی مثل سرویس های ابری که هر وقت بخایم منابع اضافه میکنیم.

قبل از افزایش حجم وضعیت اینطور بود:

همینطور که میبینید /home و / هر کدوم 40 گیگابایت هستن که باید زیاد بشن.

میبینیم که /dev/sdb به دیکسها اضافه شده اما پارتیشن بندی نشده.

همینطور که میبینیم sdb اصلا به هیچ volume group ای از LVM اضافه نشده پس معلومه که قابل استفاده است.

میبینیم که یه logical volume داریم vg0 که یه دونه pv هم داره که در واقع همون sda3 هست که قبلا دیدیم و بازم مطمثن شدیم که sdb استفاده نمیشه

یه نگاه مجدد به logical volume ها میندازیم.

با دستور بالا sdb رو به یه phisical volume تعریف کردیم که بتونیم توی LVM ازش استفاده کنیم. در وا

میبینیم که sdb اضافه شده.

حالا sdb رو به volume group vg0 اضافه میکنیم که بتونیم به logical volume ها اضافه اش کنیم.

همینطور که میبینیم اضافه شده. الان vg0 حدود یک ترابایت خالی داره.

حالا 512 گیگابایتش رو به / یا همون root اضافه کردیم.

از فضای خالی باقیمانده بقیه شو به /home اضافه کردیم.

همینطور که میبینید / و /home حجمشون زیاد شده.