دانلود کتاب آموزشی Docker Certified Associate (DCA) جلد اول

[cdb_course_lessons title=”بخش 1. ارکستراسیون (Orchestration)”][cdb_course_lesson title=”فصل 1. راه‌اندازی و مدیریت کلاسترهای Docker Swarm”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نصب و فعال‌سازی Docker Swarm” subtitle=”توضیحات کامل”]

🔹 Docker Swarm چیست و چرا به آن نیاز داریم؟

Docker Swarm یک ابزار ارکستراسیون کانتینر است که توسط Docker توسعه داده شده و به شما امکان می‌دهد چندین نود Docker را به یکدیگر متصل کرده و به‌عنوان یک کلاستر واحد مدیریت کنید.

✅ در یک محیط Docker Swarm، شما می‌توانید:

• چندین سرور (نود) را در یک کلاستر توزیع‌شده مدیریت کنید.
• کانتینرها را در چندین سرور اجرا کرده و به‌صورت خودکار بار کاری را بین آنها توزیع کنید.
• در صورت خرابی یک نود، کانتینرها را روی نودهای دیگر بازسازی (failover) کنید.
• فرآیند مقیاس‌پذیری (scaling) را به‌راحتی انجام دهید و سرویس‌های خود را در لحظه افزایش یا کاهش دهید.

🔹 چرا باید از Docker Swarm استفاده کنیم؟

• سادگی در مقایسه با Kubernetes: نصب و پیکربندی آن نسبت به Kubernetes ساده‌تر است.
• توزیع خودکار بار کاری: کانتینرها به‌صورت هوشمند بین نودها توزیع می‌شوند.
• پشتیبانی داخلی در Docker Engine: نیازی به نصب ابزارهای اضافی نیست و به‌صورت داخلی در Docker تعبیه شده است.
• مدیریت سرویس‌ها: امکان اجرای سرویس‌های توزیع‌شده با قابلیت self-healing و auto-scaling.
• پایداری بالا: در صورت خرابی یک نود، سرویس‌ها روی نودهای دیگر جایگزین می‌شوند.

---

🔹 پیش‌نیازها برای نصب Docker Swarm

قبل از راه‌اندازی Docker Swarm، باید مطمئن شوید که تمامی نودهای مورد نظر، پیش‌نیازهای زیر را دارا هستند:

✅ 1. نصب Docker Engine
Docker Swarm بخشی از Docker Engine است؛ بنابراین ابتدا باید اطمینان حاصل کنید که Docker روی تمام نودهای شما نصب شده است. برای نصب Docker روی سیستم‌های مبتنی بر Ubuntu/Debian از دستورات زیر استفاده کنید:

sudo apt update
sudo apt install -y docker.io

و در سیستم‌های CentOS/RHEL از دستورات زیر استفاده کنید:

sudo yum update -y
sudo yum install -y docker

پس از نصب Docker، باید سرویس آن را فعال و اجرا کنید:

sudo systemctl enable docker
sudo systemctl start docker

برای بررسی نصب موفقیت‌آمیز Docker، می‌توانید دستور زیر را اجرا کنید:

docker --version

خروجی این دستور باید نسخه‌ای از Docker را نمایش دهد، مانند:

Docker version 24.0.1, build 12345abc

✅ 2. بررسی وضعیت نودها و تنظیم نام آنها
هر سرور یا ماشین مجازی که قرار است به‌عنوان نود در Docker Swarm استفاده شود، باید یک نام مشخص داشته باشد. می‌توانید نام نود را به این شکل تنظیم کنید:

sudo hostnamectl set-hostname manager-node

یا برای نودهای Worker:

sudo hostnamectl set-hostname worker-node1

✅ 3. پیکربندی فایروال و باز کردن پورت‌های مورد نیاز
Docker Swarm برای برقراری ارتباط بین نودها به پورت‌های خاصی نیاز دارد. بنابراین، باید این پورت‌ها را در فایروال باز کنید:

🔸 در سیستم‌های دارای firewalld (مانند CentOS/RHEL):

sudo firewall-cmd --permanent --add-port=2376/tcp
sudo firewall-cmd --permanent --add-port=2377/tcp
sudo firewall-cmd --permanent --add-port=7946/tcp
sudo firewall-cmd --permanent --add-port=7946/udp
sudo firewall-cmd --permanent --add-port=4789/udp
sudo firewall-cmd --reload

🔸 در سیستم‌های دارای ufw (مانند Ubuntu/Debian):

sudo ufw allow 2376/tcp
sudo ufw allow 2377/tcp
sudo ufw allow 7946/tcp
sudo ufw allow 7946/udp
sudo ufw allow 4789/udp
sudo ufw reload

✅ 4. بررسی اتصال شبکه بین نودها
مطمئن شوید که نودها می‌توانند یکدیگر را پینگ کنند. اگر آدرس IP نودهای خود را نمی‌دانید، از دستور زیر استفاده کنید:

ip a

سپس از نود دیگر دستور ping را اجرا کنید:

ping <Manager-IP>

اگر پینگ موفق بود، به مرحله بعد بروید.

---

🔹 ایجاد کلاستر Docker Swarm و اضافه کردن نودها

🔸 1. مقداردهی اولیه کلاستر و تبدیل نود به Manager
بر روی سروری که می‌خواهید به‌عنوان نود مدیر (Manager) عمل کند، دستور زیر را اجرا کنید:

docker swarm init --advertise-addr <Manager-IP>

📌 در این دستور، <Manager-IP> را با آدرس IP نود مدیر جایگزین کنید.

✅ نمونه خروجی دستور:

Swarm initialized: current node (abcd1234) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-abc123... <Manager-IP>:2377

🔸 2. اضافه کردن نودهای Worker به کلاستر
پس از مقداردهی اولیه Swarm، Docker یک توکن تولید می‌کند که برای اضافه کردن نودهای Worker به کلاستر استفاده می‌شود. این توکن در خروجی دستور قبل نمایش داده شد.

📌 حالا برای اضافه کردن نودهای Worker، بر روی هر نود Worker دستور زیر را اجرا کنید:

docker swarm join --token SWMTKN-1-abc123... <Manager-IP>:2377

✅ نمونه خروجی دستور:

This node joined a swarm as a worker.

🔸 3. بررسی وضعیت نودهای کلاستر
برای مشاهده وضعیت تمامی نودهای Swarm، دستور زیر را بر روی نود مدیر (Manager) اجرا کنید:

docker node ls

✅ نمونه خروجی:

ID                            HOSTNAME            STATUS    AVAILABILITY   MANAGER STATUS
abcd1234                      manager-node        Ready     Active         Leader
efgh5678                      worker-node1        Ready     Active         
ijkl9101                      worker-node2        Ready     Active         

🔹 در خروجی بالا:

• نود manager-node دارای نقش Leader است.
• نودهای worker-node1 و worker-node2 به‌عنوان Worker اضافه شده‌اند و در وضعیت Ready قرار دارند.

---

🔹 مدیریت نودهای Docker Swarm

🔸 1. ارتقا یک Worker به Manager
در صورتی که بخواهید یک نود Worker را به مدیر (Manager) ارتقا دهید، از دستور زیر استفاده کنید:

docker node promote worker-node1

🔸 2. کاهش سطح یک Manager به Worker
اگر بخواهید یک Manager را به Worker تبدیل کنید، از این دستور استفاده کنید:

docker node demote manager-node

🔸 3. حذف یک نود از کلاستر
برای حذف یک نود از کلاستر (مثلاً worker-node1)، ابتدا دستور زیر را روی نود Worker اجرا کنید:

docker swarm leave

اگر بخواهید این نود را از سمت Manager حذف کنید، دستور زیر را روی نود مدیر اجرا کنید:

docker node rm worker-node1

---

🔹 جمع‌بندی

در این قسمت، نحوه نصب و فعال‌سازی Docker Swarm را به‌صورت کامل بررسی کردیم. ابتدا پیش‌نیازهای لازم را بررسی کردیم، سپس نود مدیر را مقداردهی اولیه کرده و نودهای Worker را به کلاستر اضافه کردیم. در نهایت، نحوه مدیریت نودها در Docker Swarm را آموزش دادیم.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد یک کلاستر Swarm و مدیریت نودهای آن (Manager و Worker)” subtitle=”توضیحات کامل”]

Docker Swarm و نقش نودها در آن

در Docker Swarm، کلاستر از چندین نود (Node) تشکیل شده که به دو نقش اصلی تقسیم می‌شوند:

• نودهای Manager: وظیفه مدیریت کلاستر، تصمیم‌گیری درباره توزیع کانتینرها، ذخیره اطلاعات مربوط به وضعیت کلاستر، و هماهنگ‌سازی را دارند.
• نودهای Worker: این نودها تنها وظیفه اجرای کانتینرها را بر عهده دارند و دستورات را از نودهای Manager دریافت می‌کنند.

✅ ساختار کلی یک کلاستر Swarm:

+----------------------+
| Manager Node        |
| - Manages cluster   |
| - Deploys services  |
+----------------------+
        |
        | (Commands & Scheduling)
        v
+----------------------+    +----------------------+
| Worker Node 1       |    | Worker Node 2       |
| - Runs containers   |    | - Runs containers   |
+----------------------+    +----------------------+

---

ایجاد کلاستر Docker Swarm

۱. نصب Docker روی همه نودها

ابتدا روی تمامی نودهای Manager و Worker، Docker را نصب کنید:

sudo apt update && sudo apt install docker.io -y

سپس، سرویس Docker را فعال کنید:

sudo systemctl enable --now docker

بررسی کنید که Docker در حال اجرا باشد:

sudo systemctl status docker

---

۲. مقداردهی اولیه کلاستر و تبدیل اولین نود به Manager

روی اولین سرور (که می‌خواهید Manager باشد) دستور زیر را اجرا کنید:

docker swarm init --advertise-addr <MANAGER-IP>

🔹 <MANAGER-IP> را با آدرس IP سرور Manager جایگزین کنید. این IP باید در شبکه‌ای باشد که سایر نودها بتوانند به آن دسترسی داشته باشند.

مثال:

docker swarm init --advertise-addr 192.168.1.100

اگر دستور موفقیت‌آمیز باشد، خروجی مشابه زیر نمایش داده می‌شود:

Swarm initialized: current node (abc123xyz) is now a manager.
To add a worker to this swarm, run the following command:
    docker swarm join --token SWMTKN-1-xyz... 192.168.1.100:2377

🚀 حالا این نود به‌عنوان Manager تنظیم شده است و می‌توان سایر نودها را به آن اضافه کرد.

---

۳. اضافه کردن نودهای Worker به کلاستر

حالا روی هر یک از نودهای Worker، دستور زیر را اجرا کنید. ابتدا باید توکن عضویت را از سرور Manager بگیرید:

docker swarm join-token worker

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

docker swarm join --token SWMTKN-1-xyz... 192.168.1.100:2377

دستور بالا را روی هر نود Worker اجرا کنید تا به کلاستر متصل شوند.

---

۴. بررسی وضعیت نودهای کلاستر

برای اطمینان از اینکه نودهای Worker به کلاستر متصل شده‌اند، روی Manager دستور زیر را اجرا کنید:

docker node ls

نمونه خروجی:

ID                            HOSTNAME        STATUS    AVAILABILITY   MANAGER STATUS
xyz123abc                     manager1        Ready     Active         Leader
abc456def                     worker1         Ready     Active         
ghi789jkl                     worker2         Ready     Active         

📌 توضیح ستون‌ها:

• STATUS: نشان‌دهنده فعال بودن نود در کلاستر است.
• AVAILABILITY: اگر مقدار آن Active باشد، نود آماده اجرای کانتینرها است.
• MANAGER STATUS: فقط برای نودهای Manager مشخص می‌شود که آیا این نود Leader است یا خیر.

---

مدیریت نودهای Docker Swarm

۱. ارتقای یک Worker به Manager

اگر نیاز داشته باشید که یک نود Worker را به Manager تبدیل کنید، روی Manager اصلی این دستور را اجرا کنید:

docker node promote worker1

حالا با اجرای docker node ls خواهید دید که این نود تبدیل به Manager شده است.

---

۲. حذف یک نود از کلاستر

برای حذف یک نود از کلاستر، ابتدا آن را غیرفعال (Drain) کنید تا دیگر کانتینری روی آن اجرا نشود:

docker node update --availability drain worker1

سپس برای حذف نود:

docker node rm worker1

اگر نود همچنان آنلاین است و می‌خواهید خودش از کلاستر خارج شود، روی همان نود دستور زیر را اجرا کنید:

docker swarm leave

---

جمع‌بندی

✅ در این بخش یاد گرفتیم که چگونه یک کلاستر Swarm ایجاد کنیم، نودهای Manager و Worker را اضافه کنیم، وضعیت کلاستر را بررسی کنیم و نودها را مدیریت کنیم.
🚀 حالا شما آماده‌اید تا سرویس‌های خود را در Docker Swarm مستقر کنید![/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تنظیم کلیدهای رمزنگاری برای امنیت کلاستر در Docker Swarm” subtitle=”توضیحات کامل”]

اهمیت رمزنگاری در Docker Swarm

امنیت در کلاستر Docker Swarm یک مسئله مهم است، زیرا نودهای مختلف از طریق یک شبکه توزیع‌شده با یکدیگر ارتباط برقرار می‌کنند. رمزنگاری داده‌ها از طریق کلیدهای رمزنگاری، از حملات Man-in-the-Middle (MITM)، شنود داده‌ها و سوءاستفاده از اطلاعات جلوگیری می‌کند.

ویژگی‌های امنیتی Docker Swarm:
✔ ارتباطات بین نودها با TLS رمزنگاری می‌شود.
✔ اطلاعات مهم مانند توکن‌های نودها و داده‌های سرویس‌ها رمزنگاری می‌شوند.
✔ می‌توان رمزنگاری را برای ذخیره‌سازی داده‌های داخلی فعال کرد.

---

۱. بررسی وضعیت رمزنگاری در Docker Swarm

به‌صورت پیش‌فرض، Docker Swarm از رمزنگاری استفاده می‌کند. برای بررسی وضعیت آن، روی نود Manager دستور زیر را اجرا کنید:

docker swarm inspect

در خروجی، به دنبال بخش “Encryption” باشید. اگر مقدار true باشد، رمزنگاری فعال است.

---

۲. فعال‌سازی رمزنگاری برای ذخیره‌سازی اطلاعات کلاستر

Docker Swarm به‌صورت پیش‌فرض اطلاعات سرویس‌ها، وظایف (tasks) و وضعیت نودها را در Raft logs ذخیره می‌کند. برای افزایش امنیت، می‌توان رمزنگاری این داده‌ها را فعال کرد.

روی نود Manager دستور زیر را اجرا کنید:

docker swarm update --autolock=true

🔹 پس از فعال‌سازی، هنگام راه‌اندازی مجدد Manager، باید کلید رمزنگاری را به‌صورت دستی وارد کنید.

✅ بررسی وضعیت رمزنگاری پس از فعال‌سازی:

docker swarm inspect --format '{{ .Spec.EncryptionConfig.AutoLockManagers }}'

اگر مقدار true بازگردانده شود، رمزنگاری فعال است.

---

۳. دریافت و مدیریت کلید رمزنگاری

وقتی Autolock فعال است، پس از هر ری‌استارت، Docker Swarm یک unlock key تولید می‌کند که برای باز کردن قفل Manager ضروری است.

✅ دریافت کلید:

docker swarm unlock-key

📌 خروجی چیزی شبیه به این خواهد بود:

SWMKEY-1-QwertyUIOPasdfghJKLzxcvbnm1234567890

📝 مهم: این کلید را در جای امنی ذخیره کنید؛ زیرا بدون آن، Manager نمی‌تواند پس از ری‌استارت به کلاستر متصل شود.

---

۴. تغییر یا ایجاد یک کلید رمزنگاری جدید

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

docker swarm unlock-key --rotate

📌 این دستور یک کلید جدید ایجاد می‌کند و باید روی تمامی Managerها اعمال شود.

---

۵. باز کردن قفل Manager پس از ری‌استارت

پس از ری‌استارت سرور Manager، هنگام راه‌اندازی Swarm، Docker از شما می‌خواهد که کلید رمزنگاری را وارد کنید. برای باز کردن قفل، این دستور را اجرا کنید:

docker swarm unlock

سپس کلید را وارد کنید تا نود Manager مجدداً فعال شود.

---

۶. غیرفعال کردن رمزنگاری (در صورت نیاز)

اگر نیاز به غیرفعال کردن Autolock دارید، می‌توانید از دستور زیر استفاده کنید:

docker swarm update --autolock=false

🚨 هشدار: غیرفعال کردن این ویژگی امنیت کلاستر را کاهش می‌دهد، زیرا داده‌های حساس دیگر رمزنگاری‌شده ذخیره نخواهند شد.

---

جمع‌بندی

✅ در این بخش یاد گرفتیم که چگونه رمزنگاری را برای کلاستر Swarm فعال کنیم و از کلیدهای امنیتی برای حفاظت از داده‌ها استفاده کنیم.
✅ همچنین نحوه مدیریت unlock key، تغییر آن و باز کردن قفل نودهای Manager را بررسی کردیم.
🚀 با این روش‌ها، امنیت کلاستر Docker Swarm شما تضمین می‌شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی وضعیت کلاستر با دستورات CLI در Docker Swarm” subtitle=”توضیحات کامل”]مدیریت و نظارت بر کلاستر Swarm بخش مهمی از عملیات DevOps است. برای اطمینان از عملکرد صحیح نودها، سرویس‌ها و وظایف (tasks)، Docker دستورات متعددی برای بررسی وضعیت کلاستر ارائه می‌دهد. در این بخش، نحوه استفاده از دستورات CLI مانند docker node ls و docker info را برای مانیتورینگ کلاستر بررسی می‌کنیم.

---

۱. بررسی وضعیت کلی کلاستر با دستور docker info

دستور docker info اطلاعات کاملی درباره وضعیت Docker و کلاستر Swarm نمایش می‌دهد.

✅ برای مشاهده این اطلاعات، دستور زیر را روی نود Manager یا Worker اجرا کنید:

docker info

📌 بخشی از خروجی مربوط به Swarm شبیه به این خواهد بود:

Swarm: active
 NodeID: abcd123456789
 Is Manager: true
 ClusterID: qwertyuiop09876
 Managers: 1
 Nodes: 3

🔹 تحلیل خروجی:

• Swarm: active → نشان می‌دهد که این نود عضو کلاستر Swarm است.
• NodeID → شناسه یکتای این نود در کلاستر.
• Is Manager → مشخص می‌کند که این نود مدیر (Manager) است یا کارگر (Worker).
• ClusterID → شناسه یکتای کلاستر Swarm.
• Managers → تعداد نودهای Manager در کلاستر.
• Nodes → تعداد کل نودهای عضو کلاستر.

---

۲. نمایش لیست نودهای کلاستر با docker node ls

برای مشاهده لیست نودهای موجود در کلاستر و وضعیت آن‌ها، از دستور docker node ls استفاده کنید. این دستور فقط روی نودهای Manager اجرا می‌شود.

✅ اجرا:

docker node ls

📌 نمونه‌ای از خروجی:

ID                            HOSTNAME            STATUS  AVAILABILITY  MANAGER STATUS
abcd123456789                 manager-1           Ready   Active        Leader
efgh987654321                 worker-1            Ready   Active        
ijkl543216789                 worker-2            Down    Drain         

🔹 تحلیل خروجی:

• ID → شناسه یکتای هر نود در کلاستر.
• HOSTNAME → نام میزبان نود.
• STATUS → وضعیت نود (Ready یعنی فعال، Down یعنی غیرفعال).
• AVAILABILITY → وضعیت دسترسی (Active یعنی نود آماده اجرا، Drain یعنی وظایفی به آن اختصاص داده نمی‌شود).
• MANAGER STATUS → وضعیت نود Manager (Leader یعنی نود اصلی مدیریت، Reachable یعنی Manager در دسترس، Unreachable یعنی ارتباط با سایر Managerها قطع شده).

🚀 مثال: اگر بخواهید بفهمید که کدام نود رهبر (Leader) است، کافی است در خروجی docker node ls به ستون MANAGER STATUS نگاه کنید.

---

۳. بررسی جزئیات هر نود با docker node inspect

برای مشاهده اطلاعات کامل درباره یک نود خاص، از دستور docker node inspect استفاده کنید.

✅ اجرا:

docker node inspect manager-1

📌 این دستور اطلاعات جامعی درباره نود manager-1 نمایش می‌دهد، از جمله وضعیت، آدرس IP، نقش (Manager/Worker)، آخرین زمان مشاهده و غیره.

✅ برای دریافت خروجی به‌صورت خوانا و خلاصه‌تر:

docker node inspect --format '{{json .}}' manager-1 | jq .

(🔹 ابزار jq خروجی JSON را به‌صورت مرتب نمایش می‌دهد.)

---

۴. مشاهده وظایف اجراشده روی یک نود خاص

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

docker node ps worker-1

📌 این دستور لیستی از تسک‌های در حال اجرا روی نود worker-1 را نمایش می‌دهد.

---

۵. بررسی وضعیت سرویس‌های Swarm

برای مشاهده لیست تمام سرویس‌های در حال اجرا در Swarm، دستور زیر را اجرا کنید:

docker service ls

📌 نمونه خروجی:

ID            NAME        MODE        REPLICAS    IMAGE
abcd1234      web-app     replicated  3/3         nginx:latest
efgh5678      database    global      1/1         mysql:5.7

🔹 توضیحات:

• MODE = replicated → سرویس دارای نسخه‌های چندگانه است.
• MODE = global → سرویس روی تمام نودهای Worker اجرا می‌شود.
• REPLICAS = 3/3 → تعداد نسخه‌های اجراشده مطابق با تعداد موردنظر است.

---

۶. مشاهده جزئیات یک سرویس خاص

برای بررسی اطلاعات کامل درباره یک سرویس خاص، از دستور docker service inspect استفاده کنید:

docker service inspect web-app

📌 این دستور اطلاعاتی مانند تعداد نسخه‌های سرویس، ایمیج، تنظیمات شبکه و وضعیت فعلی را نمایش می‌دهد.

✅ برای نمایش اطلاعات خلاصه و خوانا:

docker service inspect --pretty web-app

---

جمع‌بندی

✅ در این بخش، نحوه بررسی وضعیت کلاستر Docker Swarm با استفاده از CLI را یاد گرفتیم.
✅ از docker info برای مشاهده وضعیت کلی Docker و Swarm استفاده کردیم.
✅ از docker node ls برای بررسی وضعیت نودهای Swarm استفاده کردیم.
✅ از docker node inspect برای دریافت اطلاعات دقیق یک نود خاص کمک گرفتیم.
✅ با docker service ls وضعیت سرویس‌های در حال اجرا را بررسی کردیم.

🚀 این دستورات برای نظارت و مدیریت یک کلاستر Swarm پایدار و کارآمد ضروری هستند![/cdb_course_lesson][cdb_course_lesson title=”فصل 2. تفاوت بین اجرای کانتینر و سرویس”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”درک مفهوم سرویس در Docker Swarm” subtitle=”توضیحات کامل”]در Docker Swarm، مفهوم سرویس (Service) یکی از اصلی‌ترین اجزای مدیریت برنامه‌های توزیع‌شده است. سرویس‌ها امکان اجرای کانتینرها را به‌صورت مدیریت‌شده روی چندین نود در کلاستر فراهم می‌کنند.

در این بخش، مفهوم سرویس در Docker Swarm را توضیح می‌دهیم و نحوه ایجاد، مدیریت و بررسی سرویس‌ها را یاد می‌گیریم.

---

۱. سرویس در Docker Swarm چیست؟

سرویس در Docker Swarm یک لایه مدیریتی روی کانتینرها است که نحوه اجرا، تعداد نسخه‌ها (replicas) و استراتژی توزیع کانتینرها را در کلاستر مشخص می‌کند.

✅ سرویس‌ها مدیریت‌شده هستند، به این معنی که Swarm وضعیت مطلوب سرویس را حفظ می‌کند، مثلاً اگر یکی از نودها از دسترس خارج شود، Swarm به‌صورت خودکار کانتینرهای سرویس را روی سایر نودها اجرا می‌کند.

📌 مقایسه سرویس و کانتینر عادی:

ویژگی	کانتینر عادی (docker run)	سرویس در Swarm (docker service create)
تعداد نسخه	فقط یک نمونه اجرا می‌شود	می‌توان تعداد مشخصی از نسخه‌ها را اجرا کرد
توزیع‌شده	فقط روی یک نود اجرا می‌شود	روی چندین نود در کلاستر Swarm توزیع می‌شود
مدیریت خودکار	خیر	بله، Swarm وضعیت سرویس را حفظ می‌کند
امکان Load Balancing	خیر	بله، درخواست‌ها بین نسخه‌های مختلف توزیع می‌شوند

---

۲. انواع سرویس‌ها در Docker Swarm

دو نوع اصلی سرویس در Docker Swarm وجود دارد:

1️⃣ سرویس Replicated → یک سرویس با تعداد مشخصی از نسخه‌ها (Replicas) روی نودهای Worker اجرا می‌شود.
2️⃣ سرویس Global → یک نمونه از سرویس روی تمام نودهای Worker اجرا می‌شود.

📌 تفاوت دو مدل سرویس:

نوع سرویس	نحوه اجرا
Replicated	تعداد مشخصی از کانتینرها روی نودهای Swarm اجرا می‌شود.
Global	یک کانتینر روی هر نود Worker اجرا می‌شود.

✅ مثال:

• اگر بخواهید ۳ نسخه از یک وب‌سرور Nginx اجرا کنید، از Replicated استفاده می‌کنید.
• اگر بخواهید یک کانتینر نظارتی (مثل Metric Collector) روی تمام نودها اجرا شود، از Global استفاده می‌کنید.

---

۳. ایجاد یک سرویس در Docker Swarm

برای ایجاد یک سرویس، از دستور docker service create استفاده می‌شود.

✅ ایجاد سرویس Replicated (چند نسخه‌ای):

docker service create --name web-server --replicas 3 -p 8080:80 nginx

🔹 این دستور یک سرویس با نام web-server ایجاد می‌کند که شامل ۳ نسخه از Nginx است و روی پورت 8080 در دسترس خواهد بود.

✅ ایجاد سرویس Global (روی تمام نودهای Worker):

docker service create --name monitoring --mode global prom/node-exporter

🔹 این دستور، سرویس monitoring را به‌صورت Global اجرا می‌کند، یعنی روی تمام نودهای Worker یک کانتینر از prom/node-exporter اجرا خواهد شد.

---

۴. بررسی وضعیت سرویس‌ها در Docker Swarm

پس از ایجاد سرویس، می‌توان وضعیت آن را بررسی کرد.

✅ لیست کردن تمام سرویس‌های Swarm:

docker service ls

📌 نمونه خروجی:

ID            NAME         MODE        REPLICAS  IMAGE
abcd1234      web-server   replicated  3/3       nginx:latest
efgh5678      monitoring   global      2/2       prom/node-exporter

✅ بررسی جزئیات یک سرویس خاص:

docker service inspect web-server

✅ بررسی وضعیت نسخه‌های یک سرویس:

docker service ps web-server

📌 این دستور لیستی از کانتینرهای در حال اجرا برای سرویس web-server را نمایش می‌دهد.

---

۵. تغییر تعداد نسخه‌های سرویس (Scaling Up/Down)

برای تغییر تعداد نسخه‌های یک سرویس، از docker service scale استفاده کنید.

✅ افزایش تعداد نسخه‌ها به ۵ عدد:

docker service scale web-server=5

✅ کاهش تعداد نسخه‌ها به ۲ عدد:

docker service scale web-server=2

📌 پس از این تغییر، Swarm به‌صورت خودکار تعداد کانتینرهای سرویس را تنظیم می‌کند.

---

۶. به‌روزرسانی یک سرویس

اگر بخواهید ایمیج یک سرویس را آپدیت کنید، از docker service update استفاده کنید.

✅ به‌روزرسانی سرویس به نسخه جدیدتر Nginx:

docker service update --image nginx:latest web-server

📌 این دستور باعث جایگزینی تدریجی نسخه جدید با نسخه قدیمی سرویس می‌شود.

---

۷. حذف یک سرویس از Swarm

اگر بخواهید یک سرویس را از کلاستر حذف کنید، از docker service rm استفاده کنید.

✅ حذف سرویس web-server:

docker service rm web-server

📌 این دستور تمام نسخه‌های در حال اجرا را متوقف و سرویس را از Swarm حذف می‌کند.

---

جمع‌بندی

✅ سرویس در Docker Swarm یک لایه مدیریتی برای اجرای کانتینرها در کلاستر توزیع‌شده است.
✅ دو نوع سرویس داریم: Replicated (چند نسخه‌ای) و Global (روی تمام نودها).
✅ از docker service create برای ایجاد سرویس استفاده می‌کنیم.
✅ با docker service ls و docker service ps وضعیت سرویس را بررسی می‌کنیم.
✅ با docker service scale تعداد نسخه‌های سرویس را تغییر می‌دهیم.
✅ برای به‌روزرسانی سرویس از docker service update و برای حذف آن از docker service rm استفاده می‌کنیم.

🚀 با استفاده از سرویس‌ها در Swarm، می‌توان به‌راحتی برنامه‌های توزیع‌شده و مقیاس‌پذیر اجرا کرد![/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مقایسه بین اجرای کانتینر معمولی با اجرای سرویس‌ها در Docker Swarm” subtitle=”توضیحات کامل”]در این بخش، قصد داریم یک مقایسه مفصل بین اجرای کانتینرهای معمولی (Standalone Containers) و سرویس‌ها در Docker Swarm انجام دهیم. درک این تفاوت‌ها به شما کمک خواهد کرد که بسته به نیاز خود از Docker Swarm و سرویس‌ها به‌طور مؤثر استفاده کنید.

---

۱. مفهوم کانتینر معمولی و سرویس در Docker Swarm

• کانتینر معمولی (Standalone Containers):
  یک کانتینر معمولی به‌صورت یک واحد مستقل اجرا می‌شود که برای اجرای یک برنامه یا سرویس در محیط‌های تک‌نودی (Single Node) طراحی شده است. این نوع کانتینر به‌طور معمول به‌صورت دستی از طریق دستور docker run اجرا می‌شود و معمولاً تنها یک نسخه از کانتینر بر روی یک نود اجرا می‌شود.
• سرویس در Docker Swarm:
  سرویس‌ها در Docker Swarm یک لایه مدیریتی و مقیاس‌پذیر برای کانتینرها هستند که امکان مدیریت و توزیع چندین کانتینر در چندین نود را فراهم می‌کنند. سرویس‌ها به‌طور خودکار تعداد نسخه‌ها (replicas) را کنترل می‌کنند، بار را بین نودهای مختلف توزیع می‌کنند و از ویژگی‌هایی مثل احیای خودکار در صورت خرابی استفاده می‌کنند.

---

۲. مقایسه ویژگی‌ها

ویژگی	کانتینر معمولی (docker run)	سرویس در Docker Swarm (docker service create)
نحوه اجرا	به‌صورت دستی با دستور docker run اجرا می‌شود.	به‌صورت خودکار توسط Docker Swarm مدیریت و اجرا می‌شود.
تعداد نسخه‌ها	فقط یک نسخه از کانتینر در هر نود اجرا می‌شود.	امکان اجرای چندین نسخه (replica) از کانتینر در نودهای مختلف وجود دارد.
توزیع‌شده	فقط روی یک نود اجرا می‌شود.	روی چندین نود در کلاستر Swarm توزیع می‌شود.
مدیریت	مدیریت دستی و بدون قابلیت خودکار.	مدیریت خودکار توسط Swarm، با ویژگی‌هایی مانند Health Check و Load Balancing.
مقیاس‌پذیری	نیاز به تنظیم دستی تعداد کانتینرها.	مقیاس‌پذیری خودکار با امکان تنظیم تعداد نسخه‌ها از طریق دستور docker service scale.
Load Balancing	ندارد.	بله، Swarm به‌طور خودکار درخواست‌ها را بین نسخه‌های مختلف توزیع می‌کند.
حفظ وضعیت	نیاز به مدیریت دستی وضعیت کانتینرها.	Docker Swarm به‌صورت خودکار وضعیت سرویس را حفظ کرده و در صورت خرابی نودها، کانتینرها را روی نودهای دیگر اجرا می‌کند.
استفاده از Volume‌ها	باید به‌صورت دستی Volumeها را ایجاد و مدیریت کرد.	Docker Swarm به‌راحتی Volumeها را بین نودها مدیریت کرده و به سرویس‌ها اختصاص می‌دهد.

---

۳. مقایسه نحوه اجرا و مدیریت کانتینرها

اجرای کانتینر معمولی:

زمانی که شما یک کانتینر معمولی را اجرا می‌کنید، آن را به‌صورت مستقل و بر روی یک نود مشخص راه‌اندازی می‌کنید. برای این کار از دستور docker run استفاده می‌شود که در اینجا یک نمونه از اجرای آن را می‌بینید:

docker run -d --name web-server -p 8080:80 nginx

در این مثال:

• کانتینری از ایمیج nginx اجرا می‌شود.
• پورت ۸۰ کانتینر به پورت ۸۰۸۰ میزبان متصل می‌شود.
• کانتینر به‌صورت مستقل اجرا می‌شود و اگر کانتینر متوقف شود، نیازی به بازگرداندن خودکار نخواهد داشت.

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

اجرای سرویس در Docker Swarm:

در Docker Swarm، برای اجرای سرویس‌ها از دستور docker service create استفاده می‌کنیم. این دستور به‌طور خودکار تعداد نسخه‌ها و توزیع آن‌ها را در نودهای مختلف انجام می‌دهد. برای مثال، برای اجرای یک سرویس از Nginx به‌صورت مقیاس‌پذیر با ۳ نسخه، می‌توان از دستور زیر استفاده کرد:

docker service create --name web-server --replicas 3 -p 8080:80 nginx

در اینجا:

• ۳ نسخه از کانتینر nginx در کلاستر Swarm اجرا می‌شود.
• بار ترافیک به‌طور خودکار بین این نسخه‌ها توزیع می‌شود.
• در صورت خرابی یکی از نودها، Swarm به‌طور خودکار کانتینرها را روی نودهای سالم بازسازی می‌کند.

---

۴. مقایسه مقیاس‌پذیری و مدیریت خودکار

• کانتینر معمولی:
  در این حالت، شما باید به‌صورت دستی تعداد کانتینرها را در هر نود اضافه کنید. برای مثال، اگر بخواهید ۵ نسخه از Nginx اجرا کنید، باید ۵ دستور docker run جداگانه بنویسید و اجرا کنید. همچنین، اگر یکی از کانتینرها از دسترس خارج شود، هیچ فرآیند خودکاری برای بازسازی آن وجود ندارد.

  docker run -d --name web-server1 -p 8080:80 nginx
  docker run -d --name web-server2 -p 8081:80 nginx
  # و همینطور برای باقی کانتینرها...
  

• سرویس در Docker Swarm:
  در حالت سرویس، تعداد نسخه‌ها را می‌توان به‌راحتی با استفاده از دستور docker service scale تغییر داد. Docker Swarm به‌طور خودکار این تعداد را در نودهای مختلف توزیع می‌کند و در صورت خرابی هر نود یا کانتینر، به‌صورت خودکار آن را بازسازی می‌کند.

  docker service scale web-server=5
  

  در اینجا، ۵ نسخه از سرویس web-server به‌صورت خودکار در کلاستر Swarm ایجاد می‌شود و از قابلیت‌های مدیریت خودکار استفاده می‌کند.

---

۵. مقایسه مدیریت Volume‌ها

• کانتینر معمولی:
  در کانتینرهای معمولی، برای استفاده از Volume باید آن را به‌صورت دستی از طریق گزینه -v به کانتینر متصل کنید. همچنین، اگر کانتینر در حال اجرا باشد و نیاز به مقیاس‌پذیری یا جابجایی داده‌ها در چند نود باشد، باید به‌طور دستی این کار را انجام دهید.

  docker run -d --name web-server -v /mydata:/usr/share/nginx/html nginx
  

• سرویس در Docker Swarm:
  در Swarm، می‌توان از Docker Volumes برای اشتراک‌گذاری داده‌ها بین نودها استفاده کرد. Swarm خود این وظیفه را مدیریت می‌کند و لازم نیست برای هر نود به‌صورت دستی Volumeها را ایجاد کنید.

  docker service create --name web-server --mount type=volume,source=myvolume,target=/usr/share/nginx/html nginx
  

---

۶. جمع‌بندی

در این بخش، تفاوت‌های کلیدی بین اجرای کانتینر معمولی و سرویس‌ها در Docker Swarm بررسی شد:

1. اجرای کانتینر معمولی برای محیط‌های تک‌نودی و مدیریت دستی مناسب است.
2. اجرای سرویس‌ها در Docker Swarm برای محیط‌های چند نودی و مقیاس‌پذیر طراحی شده است.
3. سرویس‌ها دارای ویژگی‌های مدیریت خودکار و توزیع بار هستند که کانتینرهای معمولی از این ویژگی‌ها برخوردار نیستند.
4. با استفاده از سرویس‌ها می‌توان مقیاس‌پذیری و مدیریت خودکار را به‌راحتی پیاده‌سازی کرد.

در نتیجه، انتخاب بین کانتینر معمولی و سرویس در Swarm بستگی به نیاز مقیاس‌پذیری، توزیع بار و نیاز به مدیریت خودکار دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تنظیمات سرویس‌ها در Docker Swarm: تعداد Replica، Rolling Updates، و Health Check” subtitle=”توضیحات کامل”]در این بخش به تفصیل درباره سه تنظیم مهم در سرویس‌های Docker Swarm صحبت خواهیم کرد:

• تعداد Replica
• Rolling Updates
• Health Check

این تنظیمات به شما امکان می‌دهند تا سرویس‌ها را مقیاس‌پذیر، قابل مدیریت، و پایدار نگه دارید. هرکدام از این تنظیمات کاربرد خاص خود را دارند و کمک می‌کنند تا سرویس‌ها بتوانند به‌طور خودکار مقیاس‌بندی و مدیریت شوند.

---

۱. تنظیم تعداد Replica در سرویس‌ها

تعداد Replica به تعداد نسخه‌های کانتینری اطلاق می‌شود که شما می‌خواهید از سرویس مورد نظر در کلاستر Swarm اجرا شود. در Docker Swarm، می‌توانید تعداد Replica‌ها را مشخص کنید تا تعداد معینی از نسخه‌های کانتینرهای سرویس شما به‌طور همزمان در نودهای مختلف اجرا شود. این ویژگی باعث می‌شود که سرویس شما مقیاس‌پذیر باشد و بتوانید به‌راحتی تعداد کانتینرهای اجرایی را افزایش یا کاهش دهید.

نحوه پیکربندی تعداد Replica

هنگامی که سرویس را با دستور docker service create ایجاد می‌کنید، می‌توانید تعداد Replicaها را با استفاده از گزینه --replicas تنظیم کنید. به‌طور پیش‌فرض، مقدار Replica برابر با ۱ است. برای تغییر آن به عدد دلخواه، به سادگی از دستور زیر استفاده می‌کنید:

docker service create --name web-server --replicas 5 -p 8080:80 nginx

در این دستور:

• سرویس web-server با ۵ نسخه (Replica) از کانتینر nginx در کلاستر Swarm ایجاد می‌شود.
• پورت ۸۰ کانتینر به پورت ۸۰۸۰ میزبان متصل می‌شود.

مقیاس‌بندی تعداد Replica‌ها

اگر نیاز به افزایش یا کاهش تعداد Replica‌ها داشته باشید، می‌توانید از دستور docker service scale استفاده کنید. این دستور به شما این امکان را می‌دهد که تعداد Replica‌ها را به‌راحتی بدون نیاز به توقف یا ایجاد مجدد سرویس تغییر دهید:

docker service scale web-server=10

این دستور تعداد نسخه‌های سرویس web-server را به ۱۰ افزایش می‌دهد. به‌طور مشابه، برای کاهش تعداد Replica‌ها از دستور مشابه با مقدار دلخواه استفاده می‌کنید:

docker service scale web-server=3

---

۲. Rolling Updates در سرویس‌ها

Rolling Updates روشی است که در آن، Docker Swarm به‌طور مرحله‌ای نسخه‌های جدید از سرویس‌ها را بدون قطعی یا توقف کلی اجرا می‌کند. این ویژگی به شما این امکان را می‌دهد که بدون از دست دادن ترافیک، تغییرات و به‌روزرسانی‌ها را روی سرویس‌های خود اعمال کنید.

نحوه پیکربندی Rolling Updates

برای تنظیمات Rolling Updates، می‌توانید از گزینه‌های --update-parallelism و --update-delay استفاده کنید. این گزینه‌ها به شما این امکان را می‌دهند که تعیین کنید چند Replica به‌طور همزمان بروزرسانی شوند و بین هر بروزرسانی چقدر تأخیر باید وجود داشته باشد.

• --update-parallelism: مشخص می‌کند که چند نسخه از سرویس به‌طور همزمان باید به نسخه جدید بروزرسانی شوند.
• --update-delay: مشخص می‌کند که بین هر بروزرسانی چه مقدار تأخیر باید وجود داشته باشد.

مثال:

docker service update --image nginx:latest --update-parallelism 2 --update-delay 10s web-server

در این دستور:

• سرویس web-server به نسخه جدید از ایمیج nginx:latest بروزرسانی می‌شود.
• حداکثر ۲ نسخه از سرویس به‌طور همزمان بروزرسانی خواهند شد.
• بین هر بروزرسانی ۱۰ ثانیه تأخیر در نظر گرفته شده است.

مزایای Rolling Updates

• بدون توقف: این روش باعث می‌شود که سرویس شما همیشه در حال اجرا باشد و در حین بروزرسانی هیچ ترافیکی از دست نرود.
• کنترل دقیق: با تنظیم تعداد نسخه‌هایی که همزمان بروزرسانی می‌شوند و تأخیر بین بروزرسانی‌ها، می‌توانید از ایجاد مشکلات ناگهانی در سرویس جلوگیری کنید.

---

۳. Health Check در سرویس‌ها

Health Check یکی از ویژگی‌های مهم Docker است که به شما این امکان را می‌دهد که وضعیت سلامت هر کانتینر را بررسی کنید. زمانی که شما یک سرویس را در Docker Swarm راه‌اندازی می‌کنید، Docker به‌طور خودکار وضعیت سلامت کانتینرهای آن را از طریق Health Check بررسی می‌کند. اگر Docker تشخیص دهد که یک کانتینر به‌طور صحیح کار نمی‌کند، آن را مجدداً راه‌اندازی خواهد کرد.

نحوه پیکربندی Health Check در Docker Swarm

در هنگام ایجاد یک سرویس، می‌توانید دستور Health Check را در فایل Dockerfile خود تنظیم کنید تا Docker به‌طور خودکار بررسی کند که آیا سرویس به‌درستی کار می‌کند یا خیر. علاوه بر این، در هنگام ایجاد سرویس، می‌توانید از گزینه‌های --health-cmd، --health-interval، و --health-retries برای تنظیمات Health Check استفاده کنید.

دستور Health Check در Dockerfile:

HEALTHCHECK CMD curl --fail http://localhost:80 || exit 1

این دستور بررسی می‌کند که آیا سرویس وب که در پورت ۸۰ اجرا می‌شود، در دسترس است یا خیر. اگر سرویس در دسترس نباشد، دستور curl خطا خواهد داد و کانتینر به عنوان غیر سالم شناسایی خواهد شد.

تنظیمات Health Check در هنگام ایجاد سرویس:

docker service create --name web-server --health-cmd="curl --fail http://localhost:80 || exit 1" --health-interval=30s --health-retries=3 -p 8080:80 nginx

در این دستور:

• --health-cmd: دستور بررسی سلامت کانتینر است.
• --health-interval: فاصله زمانی بین هر چک سلامت (در اینجا هر ۳۰ ثانیه).
• --health-retries: تعداد دفعات تلاش برای بررسی وضعیت سالم بودن کانتینر (در اینجا ۳ بار).

چگونگی مدیریت خرابی‌ها

زمانی که Docker Swarm تشخیص دهد که یک کانتینر با وضعیت “غير سالم” (Unhealthy) وجود دارد، آن را به‌طور خودکار مجدداً راه‌اندازی خواهد کرد. این ویژگی به‌ویژه در زمان‌های بالا بودن ترافیک یا فشار روی سیستم، بسیار مهم است.

---

جمع‌بندی

در این بخش، تنظیمات مختلف سرویس‌ها در Docker Swarm، شامل تعداد Replica‌ها، Rolling Updates، و Health Check بررسی شد. این تنظیمات از ویژگی‌های قدرتمند Docker Swarm هستند که به شما کمک می‌کنند تا سرویس‌های خود را مقیاس‌پذیر، پایدار و به‌طور خودکار مدیریت کنید.

• تعداد Replica‌ها به شما این امکان را می‌دهد که تعداد نسخه‌های کانتینر را به‌طور دقیق تنظیم کنید و سرویس‌های خود را مقیاس‌پذیر کنید.
• Rolling Updates امکان بروزرسانی بدون قطعی سرویس‌ها را فراهم می‌آورد و از توقف ناگهانی سرویس‌ها جلوگیری می‌کند.
• Health Check به شما این امکان را می‌دهد که وضعیت سلامت سرویس‌ها را نظارت کرده و از مشکلات پیش‌آمده جلوگیری کنید.

این ویژگی‌ها با یکدیگر کمک می‌کنند تا سرویس‌های Docker Swarm به‌طور مؤثر و کارآمد در مقیاس‌های بزرگ اجرا شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مزایای استفاده از سرویس‌ها در محیط‌های تولیدی Docker Swarm” subtitle=”توضیحات کامل”]در محیط‌های تولیدی، نیاز به راه‌حل‌های مقیاس‌پذیر، پایدار و قابل مدیریت برای اجرای اپلیکیشن‌ها و سرویس‌ها امری حیاتی است. Docker Swarm به عنوان یک سیستم مدیریت کلاستر برای داکر، امکانات گسترده‌ای را برای مدیریت و اجرای سرویس‌ها فراهم می‌آورد که می‌تواند بسیاری از چالش‌های معمول در محیط‌های تولیدی را حل کند. در این بخش، به بررسی مزایای استفاده از سرویس‌ها در Docker Swarm در محیط‌های تولیدی خواهیم پرداخت.

---

۱. مقیاس‌پذیری و توزیع بار (Load Balancing)

یکی از بزرگ‌ترین مزایای استفاده از سرویس‌ها در Docker Swarm، مقیاس‌پذیری بالا است. در حالت سرویس، Docker Swarm به‌طور خودکار کانتینرها را روی نودهای مختلف کلاستر توزیع می‌کند و در صورت نیاز می‌توانید تعداد Replica‌ها را تغییر دهید. این ویژگی به شما این امکان را می‌دهد که به‌راحتی بار ترافیکی را بین نودهای مختلف تقسیم کنید و در صورت افزایش ترافیک، تعداد کانتینرها را افزایش دهید.

نحوه مقیاس‌پذیری در Docker Swarm

با استفاده از دستور docker service scale، می‌توانید به راحتی تعداد Replica‌ها را تغییر دهید:

docker service scale web-server=10

این دستور تعداد نسخه‌های سرویس web-server را به ۱۰ افزایش می‌دهد. در صورت کاهش بار، می‌توانید تعداد Replica‌ها را نیز کاهش دهید:

docker service scale web-server=3

با این کار، تعداد کانتینرها برای سرویس به‌طور خودکار تنظیم شده و به‌طور مؤثری مقیاس‌پذیری ایجاد می‌شود.

---

۲. قابلیت اطمینان و تحمل خطا (Fault Tolerance)

در محیط‌های تولیدی، همیشه ممکن است مشکلاتی پیش آید که باعث خرابی برخی از نودها یا کانتینرها شود. در این شرایط، Docker Swarm به‌طور خودکار از ظرفیت‌هایی مانند تکرار (Replica) و نظارت روی سلامت (Health Check) استفاده می‌کند تا از دست رفتن سرویس‌ها جلوگیری کند.

نحوه عملکرد در صورت خرابی

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

همچنین، از آنجا که Docker Swarm به‌طور خودکار وضعیت سلامت کانتینرها را نظارت می‌کند، در صورت عدم پاسخگویی از سوی کانتینر یا خرابی آن، دوباره راه‌اندازی می‌شود و اطمینان حاصل می‌شود که هیچ‌کدام از سرویس‌ها از کار نمی‌افتند.

---

۳. پشتیبانی از Rolling Updates

در محیط‌های تولیدی، به‌روزرسانی‌های نرم‌افزار باید به‌گونه‌ای انجام شوند که هیچ وقفه‌ای در سرویس‌ها ایجاد نشود. Docker Swarm با پشتیبانی از Rolling Updates این امکان را فراهم می‌کند که بدون قطع کردن سرویس‌ها، نسخه‌های جدیدی از اپلیکیشن‌ها و کانتینرها را به‌طور پیوسته و مرحله‌ای روی کلاستر Swarm اعمال کنید.

نحوه عملکرد Rolling Updates

در حالت Rolling Update، Docker به‌طور همزمان فقط تعداد محدودی از Replica‌ها را بروزرسانی می‌کند و تا زمانی که نسخه جدید به‌طور صحیح راه‌اندازی نشود، نسخه‌های قبلی همچنان فعال هستند. این روش باعث می‌شود که سرویس‌ها بدون هیچ وقفه‌ای به کار خود ادامه دهند.

برای اعمال Rolling Update، می‌توانید از دستور زیر استفاده کنید:

docker service update --image nginx:latest --update-parallelism 2 --update-delay 10s web-server

در این دستور:

• --update-parallelism 2: حداکثر دو کانتینر از سرویس به‌طور همزمان بروزرسانی می‌شوند.
• --update-delay 10s: بین هر بروزرسانی ۱۰ ثانیه تأخیر ایجاد می‌شود.

این ویژگی به‌ویژه در محیط‌های تولیدی مهم است، زیرا هیچ‌گاه سرویس‌ها به‌طور کامل متوقف نمی‌شوند و بروزرسانی‌ها به‌طور مؤثر و بدون وقفه انجام می‌شوند.

---

۴. مدیریت آسان و نظارت بر وضعیت

در Docker Swarm، سرویس‌ها به‌طور پیش‌فرض دارای قابلیت‌های نظارتی هستند که به مدیران سیستم این امکان را می‌دهد که به‌طور دقیق وضعیت هر سرویس و کانتینر را مشاهده و مدیریت کنند. از جمله این قابلیت‌ها می‌توان به دستوراتی مانند docker service ps و docker service logs اشاره کرد که به‌راحتی اطلاعات کاملی از وضعیت سرویس‌ها، کانتینرها، و همچنین گزارش‌های خطا و مشکلات را در اختیار شما قرار می‌دهند.

مثال‌هایی از دستورات نظارت

• مشاهده وضعیت سرویس‌ها:

  docker service ps web-server
  

  این دستور اطلاعات کاملی از وضعیت سرویس web-server، از جمله وضعیت هر کانتینر، زمان راه‌اندازی، و مشکلات احتمالی را نمایش می‌دهد.

• مشاهده لاگ‌های سرویس‌ها:

  docker service logs web-server
  

  این دستور لاگ‌های سرویس web-server را به‌طور پیوسته نمایش می‌دهد که برای تشخیص مشکلات و رفع خطاها مفید است.

---

۵. بهبود فرآیند استقرار (Deployment)

استقرار اپلیکیشن‌ها در محیط‌های تولیدی معمولاً به‌عنوان یکی از چالش‌های بزرگ شناخته می‌شود. استفاده از سرویس‌ها در Docker Swarm این فرآیند را ساده و خودکار می‌کند. با استفاده از کلاستر Swarm، شما می‌توانید به‌راحتی اپلیکیشن‌ها را در مقیاس بزرگ استقرار دهید و مدیریت کنید.

Docker Swarm به شما این امکان را می‌دهد که سرویس‌ها را بر روی چندین نود به‌طور همزمان استقرار دهید و آن‌ها را به‌طور مرکزی مدیریت کنید. این ویژگی باعث کاهش پیچیدگی‌های استقرار و مدیریت سرویس‌ها در محیط‌های تولیدی می‌شود.

---

۶. انعطاف‌پذیری در انتخاب منابع (Resource Flexibility)

Docker Swarm به شما این امکان را می‌دهد که منابع سیستم (مانند CPU، حافظه، و فضای دیسک) را برای هر سرویس و کانتینر به‌طور دقیق تعیین کنید. این ویژگی به شما کمک می‌کند تا از منابع سیستم به‌طور بهینه استفاده کنید و بار سنگینی را روی نودها قرار ندهید.

مثال: تخصیص منابع به سرویس

docker service create --name web-server --replicas 3 --limit-cpu 0.5 --limit-memory 512m nginx

در این دستور:

• --limit-cpu 0.5: محدودیت مصرف CPU برای هر کانتینر را ۵۰٪ از یک CPU واحد تعیین می‌کند.
• --limit-memory 512m: محدودیت حافظه برای هر کانتینر را ۵۱۲ مگابایت تعیین می‌کند.

این تنظیمات باعث می‌شود که سرویس‌ها به‌طور کارآمد از منابع سیستم استفاده کنند و بار اضافی ایجاد نکنند.

---

جمع‌بندی

استفاده از سرویس‌ها در Docker Swarm در محیط‌های تولیدی، مزایای متعددی را به همراه دارد که شامل مقیاس‌پذیری، اطمینان از دسترس‌پذیری بالا، مدیریت آسان، و استقرار بدون وقفه می‌شود. این ویژگی‌ها به شما این امکان را می‌دهند که سرویس‌های خود را در مقیاس‌های بزرگ و بدون مشکل مدیریت کرده و تغییرات و به‌روزرسانی‌ها را با حداقل قطعی و اختلال انجام دهید. Docker Swarm ابزار قدرتمندی برای مدیریت و مقیاس‌بندی سرویس‌ها در محیط‌های تولیدی است که می‌تواند فرآیندهای مختلف را ساده‌تر و کارآمدتر کند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. مدیریت استک‌ها (Stacks)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد و اجرای استک‌ها با استفاده از فایل‌های Compose در Docker Swarm” subtitle=”توضیحات کامل”]یکی از ویژگی‌های برجسته Docker Swarm، توانایی ایجاد و مدیریت استک‌ها (Stacks) است. استک‌ها مجموعه‌ای از سرویس‌ها، شبکه‌ها و حجم‌ها هستند که به‌طور سازمان‌یافته در یک کلاستر Docker Swarm اجرا می‌شوند. این استک‌ها به‌ویژه در هنگام استفاده از فایل‌های Docker Compose، که به‌طور گسترده برای تعریف و پیکربندی سرویس‌های مختلف استفاده می‌شود، بسیار مفید هستند.

در این بخش، به بررسی نحوه ایجاد و اجرای استک‌ها با استفاده از فایل‌های Compose در Docker Swarm خواهیم پرداخت.

---

۱. Docker Compose و Swarm

در Docker، فایل‌های docker-compose.yml به‌منظور تعریف سرویس‌ها و تنظیمات آن‌ها مورد استفاده قرار می‌گیرند. این فایل‌ها از زبان YAML برای تعریف سرویس‌ها، شبکه‌ها و حجم‌ها استفاده می‌کنند. اما در Docker Swarm، به‌جای استفاده مستقیم از دستورات Docker Compose برای ایجاد سرویس‌ها، می‌توانیم از قابلیت Stacks بهره ببریم که به‌طور خاص برای Swarm طراحی شده است.

استک‌ها به شما این امکان را می‌دهند که مجموعه‌ای از سرویس‌ها را در یک واحد سازمان‌دهی کنید و آن‌ها را به‌طور همزمان در کلاستر Swarm اجرا کنید. به عبارت دیگر، در حالت Swarm، Docker Compose فایل‌ها به‌صورت استک‌ها اجرا می‌شوند.

---

۲. ساخت فایل Docker Compose برای Swarm

برای استفاده از فایل Compose در Docker Swarm، ابتدا باید یک فایل docker-compose.yml ایجاد کنید که سرویس‌ها، شبکه‌ها و حجم‌ها را تعریف کند. در حالت Swarm، فایل Compose باید شامل تنظیمات خاصی باشد که به آن اجازه می‌دهد در یک کلاستر Swarm اجرا شود. این تنظیمات ممکن است شامل مشخص کردن تعداد Replica‌ها، محدودیت منابع، تنظیمات به‌روزرسانی و ویژگی‌های دیگر باشد.

نمونه یک فایل Docker Compose برای Swarm

version: '3.8'

services:
  web:
    image: nginx:latest
    deploy:
      replicas: 3
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
    networks:
      - webnet
    ports:
      - "80:80"
  
  app:
    image: myapp:latest
    deploy:
      replicas: 2
      resources:
        limits:
          cpus: '1.0'
          memory: 1G
    networks:
      - webnet
    environment:
      - ENV_VAR=value

  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: example
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - webnet

networks:
  webnet:
    driver: overlay

volumes:
  db_data:
    driver: local

در این فایل:

• web: یک سرویس وب از تصویر nginx است که سه Replica از آن اجرا خواهد شد.
• app: سرویس اپلیکیشن با دو Replica است که منابعی همچون CPU و حافظه را محدود کرده‌ایم.
• db: یک سرویس پایگاه داده از تصویر mysql که یک حجم برای ذخیره‌سازی داده‌ها استفاده می‌کند.
• networks: یک شبکه مجازی با استفاده از درایور overlay برای ارتباط سرویس‌ها به یکدیگر ایجاد می‌شود.
• volumes: یک حجم محلی برای پایگاه داده ایجاد می‌شود تا داده‌ها ذخیره شوند.

---

۳. اجرای استک در Docker Swarm

بعد از ساخت فایل Docker Compose، می‌توانید استک را در کلاستر Swarm با استفاده از دستور docker stack deploy اجرا کنید.

دستور اجرای استک

برای استقرار استک، ابتدا باید به‌دستور زیر در مسیر پوشه‌ای که فایل docker-compose.yml در آن قرار دارد، اجرا کنید:

docker stack deploy -c docker-compose.yml my_stack

در این دستور:

• -c docker-compose.yml: فایل Compose که شامل تنظیمات استک است.
• my_stack: نام استک که در کلاستر Swarm ایجاد می‌شود.

این دستور فایل docker-compose.yml را خوانده و استک را در کلاستر Swarm اجرا می‌کند.

---

۴. بررسی وضعیت استک و سرویس‌ها

پس از اجرای دستور بالا، می‌توانید وضعیت استک و سرویس‌های آن را بررسی کنید.

مشاهده وضعیت استک

برای مشاهده وضعیت کلی استک، می‌توانید از دستور زیر استفاده کنید:

docker stack ls

این دستور لیستی از استک‌های در حال اجرا در کلاستر شما را نمایش می‌دهد.

مشاهده وضعیت سرویس‌های استک

برای مشاهده سرویس‌های در حال اجرا در یک استک خاص، از دستور زیر استفاده کنید:

docker stack services my_stack

این دستور اطلاعاتی در مورد سرویس‌ها، وضعیت و تعداد Replica‌ها را نمایش می‌دهد.

---

۵. مدیریت استک‌ها

Docker Swarm به شما این امکان را می‌دهد که استک‌ها را به‌راحتی مدیریت کنید، از جمله به‌روزرسانی، توقف و حذف استک‌ها.

به‌روزرسانی استک

برای به‌روزرسانی استک، کافی است فایل docker-compose.yml را ویرایش کرده و دوباره دستور docker stack deploy را اجرا کنید. Docker Swarm به‌طور خودکار تغییرات را اعمال خواهد کرد.

docker stack deploy -c docker-compose.yml my_stack

حذف استک

برای حذف استک و تمام سرویس‌های مربوط به آن، می‌توانید از دستور زیر استفاده کنید:

docker stack rm my_stack

این دستور تمام سرویس‌ها، شبکه‌ها و حجم‌های مرتبط با استک my_stack را از کلاستر حذف می‌کند.

---

۶. مزایای استفاده از Docker Compose در Docker Swarm

استفاده از Docker Compose در Docker Swarm مزایای متعددی دارد که عبارتند از:

• مدیریت ساده و متمرکز: فایل‌های Compose امکان مدیریت ساده‌تر و متمرکز سرویس‌ها را فراهم می‌کنند. با استفاده از یک فایل YAML، می‌توان تمامی سرویس‌ها، شبکه‌ها و حجم‌ها را به‌طور سازمان‌یافته و یکپارچه تعریف کرد.
• مقیاس‌پذیری: با استفاده از قابلیت‌های Docker Swarm، می‌توان به‌راحتی تعداد Replica‌ها را تغییر داد و سرویس‌ها را در مقیاس‌های مختلف اجرا کرد.
• استقرار ساده: Docker Compose به‌راحتی قابلیت تعریف استک‌ها را فراهم می‌آورد و می‌توان آن‌ها را در کلاستر Swarm استقرار داد.
• میزان انعطاف‌پذیری بالا: امکان تغییر پیکربندی سرویس‌ها به‌طور مستقیم در فایل Compose و استقرار آن‌ها بدون نیاز به توقف کامل سرویس‌ها.

---

جمع‌بندی

ایجاد و اجرای استک‌ها با استفاده از فایل‌های Compose در Docker Swarm، روشی قدرتمند برای استقرار و مدیریت سرویس‌ها در مقیاس بزرگ است. این امکان به شما این اجازه را می‌دهد که به‌راحتی سرویس‌ها را تعریف، مقیاس‌پذیر کنید و بدون وقفه تغییرات را اعمال نمایید. همچنین، استفاده از Docker Compose در محیط Swarm، به‌ویژه برای توسعه‌دهندگانی که با ساختار Docker آشنا هستند، فرآیند استقرار را ساده‌تر و مدیریت آن را کارآمدتر می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی و مدیریت استک‌ها با دستورات CLI مانند docker stack deploy و docker stack ps” subtitle=”توضیحات کامل”]در Docker Swarm، یکی از مهم‌ترین مفاهیم مدیریت استک‌هاست. به کمک استک‌ها، می‌توان سرویس‌ها و منابع مختلف را به‌طور سازمان‌یافته در کلاستر Swarm مدیریت کرد. این فرآیند می‌تواند شامل استقرار، مشاهده وضعیت، مدیریت تغییرات و حذف استک‌ها باشد. برای انجام این کارها، Docker ابزارهای CLI مختلفی را برای کار با استک‌ها در اختیار شما قرار می‌دهد.

در این بخش به بررسی دستورات کاربردی برای بررسی و مدیریت استک‌ها، از جمله docker stack deploy و docker stack ps خواهیم پرداخت.

---

۱. دستور docker stack deploy

دستور docker stack deploy برای استقرار استک‌ها در کلاستر Swarm استفاده می‌شود. این دستور فایل‌های Compose که سرویس‌ها، شبکه‌ها و حجم‌ها را تعریف می‌کنند، خوانده و به‌طور خودکار استک‌ها را در کلاستر Swarm راه‌اندازی می‌کند.

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

نمونه دستور برای استقرار استک

برای استقرار استک، ابتدا باید فایل Compose خود (که معمولاً docker-compose.yml نامیده می‌شود) را آماده کنید. سپس از دستور زیر برای استقرار استک استفاده می‌کنید:

docker stack deploy -c docker-compose.yml my_stack

در این دستور:

• -c docker-compose.yml: فایلی که شامل تنظیمات سرویس‌ها، شبکه‌ها و حجم‌ها است.
• my_stack: نام استکی که قصد دارید در کلاستر Swarm ایجاد کنید. این نام باید منحصر به فرد باشد و برای شناسایی استک استفاده می‌شود.

شرح عملکرد دستور docker stack deploy

هنگامی که دستور docker stack deploy اجرا می‌شود، Docker Compose فایل را تجزیه کرده و سرویس‌ها را در کلاستر Swarm به‌طور خودکار ایجاد می‌کند. این دستور به‌طور مستقیم در کلاستر Swarm استقرار می‌یابد و به‌طور خودکار Replica‌ها را مطابق با پیکربندی مشخص‌شده ایجاد می‌کند. علاوه بر این، اگر استک قبلاً وجود داشته باشد، Docker تغییرات جدید را اعمال می‌کند و سرویس‌ها را به‌روزرسانی می‌کند.

ویژگی‌ها و امکانات دستور docker stack deploy:

• استقرار سرویس‌ها: تمام سرویس‌های موجود در فایل Compose به‌صورت خودکار در کلاستر Swarm استقرار می‌یابند.
• تعریف منابع: می‌توانید منابع هر سرویس (مثل CPU، حافظه و …) را به‌طور دقیق در فایل Compose تعریف کنید.
• مقیاس‌پذیری: تعداد Replica‌ها را برای هر سرویس می‌توانید در فایل Compose مشخص کنید.
• مدیریت شبکه‌ها و حجم‌ها: این دستور به‌طور خودکار شبکه‌ها و حجم‌ها را نیز در کلاستر Swarm مدیریت می‌کند.

---

۲. دستور docker stack ps

دستور docker stack ps برای مشاهده وضعیت سرویس‌ها و وظایف (tasks) در یک استک خاص استفاده می‌شود. این دستور اطلاعاتی مانند وضعیت هر task، نودهایی که سرویس‌ها روی آن‌ها اجرا می‌شوند، و جزئیات دیگری در مورد عملکرد استک ارائه می‌دهد.

نمونه دستور برای مشاهده وضعیت استک

برای مشاهده وضعیت استک و task‌های آن، می‌توانید از دستور زیر استفاده کنید:

docker stack ps my_stack

در این دستور:

• my_stack: نام استک که می‌خواهید وضعیت آن را بررسی کنید.

شرح عملکرد دستور docker stack ps

این دستور به شما امکان می‌دهد که جزئیات دقیق‌تری از سرویس‌های در حال اجرا، task‌ها، وضعیت آن‌ها و هرگونه مشکلات احتمالی در فرآیند استقرار مشاهده کنید.

خروجی دستور docker stack ps

خروجی این دستور شامل جدول زیر می‌شود:

ID	NAME	IMAGE	NODE	DESIRED STATE	CURRENT STATE	ERROR
1b9a73a	my_stack_web.1	nginx:latest	node1	Running	Running 2 minutes ago
2b8c4fe	my_stack_web.2	nginx:latest	node2	Running	Running 1 minute ago
3d7e9a1	my_stack_app.1	myapp:latest	node3	Running	Running 5 minutes ago

در این جدول:

• NAME: نام سرویس و شماره Replica آن را نشان می‌دهد.
• IMAGE: تصویر Docker مورد استفاده برای سرویس.
• NODE: نودی که سرویس روی آن اجرا می‌شود.
• DESIRED STATE: وضعیت دلخواه سرویس (معمولاً “Running” برای سرویس‌های فعال).
• CURRENT STATE: وضعیت فعلی سرویس، شامل اطلاعات زمانی که سرویس در آن وضعیت است.
• ERROR: هرگونه خطای مرتبط با سرویس که ممکن است در زمان اجرا رخ دهد.

---

۳. مشاهده جزئیات بیشتر سرویس‌ها و وظایف

اگر بخواهید جزئیات بیشتری در مورد یک task خاص به‌دست آورید، می‌توانید از شناسه‌ی task (که در ستون ID مشاهده می‌شود) استفاده کنید.

نمونه دستور برای مشاهده جزئیات task

docker inspect task_id

این دستور تمام اطلاعات مربوط به یک task خاص را نمایش می‌دهد، از جمله وضعیت فعلی، مشکلات احتمالی، منابع مصرفی، و موارد دیگر.

---

۴. دستورات دیگر برای مدیریت استک‌ها

علاوه بر دستورات docker stack deploy و docker stack ps، دستورات دیگری برای مدیریت استک‌ها در Docker Swarm وجود دارد که به شما کمک می‌کنند در عملیات‌های روزانه به‌راحتی با استک‌ها کار کنید.

• حذف استک: برای حذف استک از کلاستر Swarm از دستور زیر استفاده کنید:

  docker stack rm my_stack
  

• مشاهده وضعیت کلی استک‌ها: برای مشاهده استک‌های در حال اجرا در کلاستر از دستور زیر استفاده کنید:

  docker stack ls
  

• مشاهده سرویس‌های یک استک خاص: برای مشاهده سرویس‌های در حال اجرا در یک استک از دستور زیر استفاده کنید:

  docker stack services my_stack
  

• مشاهده حجم‌ها و شبکه‌های استک: برای مشاهده حجم‌ها و شبکه‌های مرتبط با استک می‌توانید از دستورات زیر استفاده کنید:

  docker stack volumes my_stack
  docker stack networks my_stack
  

---

جمع‌بندی

مدیریت استک‌ها در Docker Swarm با استفاده از دستورات CLI مانند docker stack deploy و docker stack ps به شما این امکان را می‌دهد که به‌طور مؤثر و کارآمد استک‌ها و سرویس‌های خود را در کلاستر Swarm استقرار، نظارت و مدیریت کنید. دستور docker stack deploy به‌راحتی سرویس‌ها را در کلاستر مستقر کرده و به‌طور خودکار منابع مورد نیاز را تخصیص می‌دهد، در حالی‌که دستور docker stack ps اطلاعات دقیقی از وضعیت سرویس‌ها و task‌ها به شما ارائه می‌دهد. این ابزارها به شما کمک می‌کنند که استک‌ها را به‌طور متمرکز و مقیاس‌پذیر مدیریت کنید.

---

در این بخش تمام جزئیات مربوط به دستورات CLI برای بررسی و مدیریت استک‌ها آورده شده است. امیدوارم این توضیحات به شما کمک کند تا بتوانید به‌طور مؤثر با Docker Swarm و استک‌ها کار کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مدیریت سرویس‌های در حال اجرا در یک استک” subtitle=”توضیحات کامل”]در Docker Swarm، سرویس‌ها بخش اصلی برای اجرای اپلیکیشن‌ها و سرویس‌های مختلف در کلاستر هستند. هر سرویس می‌تواند تعداد زیادی task (کانتینر) داشته باشد که بر روی نودهای مختلف در کلاستر اجرا می‌شوند. مدیریت سرویس‌ها در یک استک، به شما این امکان را می‌دهد که وضعیت سرویس‌ها را نظارت کنید، تغییرات لازم را اعمال کنید و در صورت نیاز آن‌ها را به‌روزرسانی یا اصلاح کنید.

در این بخش، به بررسی نحوه مدیریت سرویس‌های در حال اجرا در یک استک Docker Swarm خواهیم پرداخت و دستوراتی را برای مشاهده وضعیت سرویس‌ها، تغییر تنظیمات و اعمال به‌روزرسانی‌های جدید معرفی خواهیم کرد.

---

۱. مشاهده سرویس‌های موجود در یک استک

اولین قدم برای مدیریت سرویس‌ها، مشاهده وضعیت سرویس‌ها و task‌های آن‌ها است. برای این کار از دستور docker stack services استفاده می‌شود. این دستور لیستی از تمام سرویس‌های موجود در یک استک خاص را نمایش می‌دهد.

نمونه دستور برای مشاهده سرویس‌ها

docker stack services my_stack

در این دستور:

• my_stack: نام استکی که می‌خواهید سرویس‌های آن را مشاهده کنید.

خروجی دستور docker stack services

خروجی این دستور شامل یک جدول از سرویس‌ها به‌همراه وضعیت آن‌ها، تعداد Replica‌ها، و سایر اطلاعات مرتبط با هر سرویس خواهد بود:

NAME	ID	MODE	REPLICAS	IMAGE	PORTS
my_stack_web	abc123	replicated	3/3	nginx:latest	80:80
my_stack_db	def456	replicated	2/2	postgres:latest	5432:5432

در این جدول:

• NAME: نام سرویس.
• ID: شناسه منحصر به‌فرد سرویس.
• MODE: نوع اجرای سرویس، که معمولاً replicated یا global است.
• REPLICAS: تعداد Replica‌های در حال اجرا و تعداد دلخواه (مثال: 3/3 به این معنی است که سه task از سرویس در حال اجرا هستند و این تعداد به‌طور دلخواه مشخص‌شده است).
• IMAGE: تصویر Docker استفاده‌شده برای سرویس.
• PORTS: پورت‌هایی که سرویس به آن‌ها متصل است.

---

۲. تغییر تعداد Replica‌ها برای یک سرویس

یکی از ویژگی‌های مهم Docker Swarm مقیاس‌پذیری سرویس‌ها است. با استفاده از دستور docker service scale می‌توانید تعداد Replica‌ها را برای هر سرویس تغییر دهید.

نمونه دستور برای تغییر تعداد Replica‌ها

docker service scale my_stack_web=5

در این دستور:

• my_stack_web: نام سرویس.
• 5: تعداد جدید Replica‌ها برای سرویس که به ۵ افزایش می‌دهیم.

شرح عملکرد دستور docker service scale

با اجرای این دستور، Docker Swarm به‌طور خودکار تعداد Replica‌های سرویس موردنظر را به مقدار جدید تغییر می‌دهد. اگر تعداد Replica‌ها بیشتر از تعداد موجود باشد، Swarm نودهای جدیدی را برای اجرای task‌های اضافی اضافه خواهد کرد. اگر تعداد Replica‌ها کاهش یابد، برخی از task‌ها متوقف می‌شوند.

---

۳. به‌روزرسانی یک سرویس در Docker Swarm

برای به‌روزرسانی یک سرویس در Docker Swarm از دستور docker service update استفاده می‌شود. این دستور به شما امکان می‌دهد که تنظیمات یک سرویس را تغییر دهید، مانند تغییر تصویر Docker، تنظیمات شبکه، پورت‌ها، منابع، و غیره.

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

docker service update --image nginx:1.19 my_stack_web

در این دستور:

• --image nginx:1.19: تصویر جدید که برای سرویس استفاده می‌شود. این دستور سرویس my_stack_web را با استفاده از تصویر nginx:1.19 به‌روزرسانی می‌کند.
• my_stack_web: نام سرویس که قرار است به‌روزرسانی شود.

ویژگی‌ها و امکانات دستور docker service update:

• تغییر تصویر Docker: شما می‌توانید تصویر Docker سرویس‌ها را برای به‌روزرسانی به یک نسخه جدید تغییر دهید.
• اضافه کردن محدودیت‌های منابع: مانند محدودیت‌های CPU یا حافظه.
• تغییر پورت‌ها یا متغیرهای محیطی: می‌توانید پورت‌ها، حجم‌ها یا متغیرهای محیطی را تغییر دهید.
• تغییر تنظیمات سرویس: مثلاً تعداد Replica‌ها یا استراتژی به‌روزرسانی.

---

۴. نظارت بر وضعیت سرویس‌ها با استفاده از docker service ps

برای نظارت دقیق‌تر بر وضعیت task‌ها و وضعیت اجرای هر سرویس در Docker Swarm از دستور docker service ps استفاده می‌شود. این دستور لیستی از تمام task‌های یک سرویس خاص و وضعیت آن‌ها را نمایش می‌دهد.

نمونه دستور برای مشاهده وضعیت task‌های یک سرویس

docker service ps my_stack_web

در این دستور:

• my_stack_web: نام سرویس که می‌خواهید وضعیت task‌های آن را مشاهده کنید.

خروجی دستور docker service ps

خروجی این دستور شامل جزئیات زیر خواهد بود:

ID	NAME	IMAGE	NODE	DESIRED STATE	CURRENT STATE	ERROR
abc123	my_stack_web.1	nginx:1.18	node1	Running	Running 10 minutes ago
def456	my_stack_web.2	nginx:1.19	node2	Running	Running 5 minutes ago
ghi789	my_stack_web.3	nginx:1.18	node3	Running	Running 3 minutes ago

در این جدول:

• NAME: نام task و شماره Replica آن.
• IMAGE: تصویر Docker استفاده‌شده برای task.
• NODE: نودی که task در آن اجرا می‌شود.
• DESIRED STATE: وضعیت دلخواه task (معمولاً “Running”).
• CURRENT STATE: وضعیت فعلی task و زمان آخرین تغییر.
• ERROR: هرگونه خطا یا مشکل در task.

---

۵. حذف یک سرویس از استک

اگر بخواهید یک سرویس خاص را از استک حذف کنید، می‌توانید از دستور docker service rm استفاده کنید.

نمونه دستور برای حذف سرویس

docker service rm my_stack_web

در این دستور:

• my_stack_web: نام سرویس که قصد دارید آن را حذف کنید.

این دستور سرویس موردنظر را از استک حذف می‌کند و task‌های مربوط به آن سرویس از کلاستر Swarm متوقف و حذف خواهند شد.

---

جمع‌بندی

مدیریت سرویس‌های در حال اجرا در یک استک Docker Swarm امری ضروری است که به شما امکان می‌دهد سرویس‌ها را مقیاس‌پذیر کنید، به‌روزرسانی‌ها را اعمال کنید، و وضعیت اجرای task‌ها را نظارت نمایید. دستورات CLI مانند docker stack services برای مشاهده سرویس‌ها، docker service scale برای تغییر تعداد Replica‌ها، و docker service update برای به‌روزرسانی سرویس‌ها ابزارهای بسیار مفیدی برای این کار هستند. علاوه بر این، دستورات docker service ps و docker service rm به شما این امکان را می‌دهند که وضعیت دقیق‌تری از task‌ها به‌دست آورید و سرویس‌های ناخواسته را حذف کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”عیب‌یابی مشکلات در استک‌ها” subtitle=”توضیحات کامل”]عیب‌یابی یکی از مهم‌ترین مهارت‌ها برای هر کسی است که با Docker Swarm و استک‌ها کار می‌کند. مشکلات ممکن است در هر مرحله‌ای از اجرای استک‌ها رخ دهند، از جمله مشکلات در شروع سرویس‌ها، اتصال نودها، پیکربندی سرویس‌ها و حتی عملکرد خود سرویس‌ها. در این بخش، قصد داریم که چگونگی شناسایی و رفع مشکلات رایج در استک‌های Docker Swarm را با استفاده از دستورات CLI و ابزارهای مختلف بررسی کنیم.

عیب‌یابی در Docker Swarm شامل شناسایی دلایل توقف یا عملکرد غیرعادی سرویس‌ها، مشاهده لاگ‌ها و بررسی وضعیت کلی استک است. در این مسیر، مهم‌ترین نکات برای عیب‌یابی عبارتند از: بررسی وضعیت سرویس‌ها و task‌ها، استفاده از لاگ‌ها، و تحلیل گزارش‌های خطا.

---

۱. بررسی وضعیت کلی استک‌ها و سرویس‌ها

ابتدا باید از وضعیت کلی استک‌ها و سرویس‌ها با استفاده از دستورات Docker آگاه شویم. این دستورات به شما کمک می‌کنند تا درک بهتری از وضعیت کلی سیستم داشته باشید و متوجه شوید که آیا سرویس‌ها در حال اجرا هستند یا مشکلی وجود دارد.

دستور docker stack ps

با استفاده از دستور docker stack ps می‌توان وضعیت دقیق task‌های یک استک خاص را مشاهده کرد. این دستور تمام taskهای یک استک را نمایش داده و وضعیت آن‌ها را نشان می‌دهد.

نمونه دستور برای مشاهده وضعیت taskها

docker stack ps my_stack

در این دستور:

• my_stack: نام استک که قصد دارید وضعیت taskهای آن را مشاهده کنید.

خروجی این دستور به شما کمک می‌کند که متوجه شوید کدام taskها به درستی اجرا می‌شوند و کدام‌ها ممکن است متوقف شده باشند.

خروجی دستور docker stack ps

ID	NAME	IMAGE	NODE	DESIRED STATE	CURRENT STATE	ERROR
abc123	my_stack_web.1	nginx:latest	node1	Running	Running 10 minutes ago
def456	my_stack_db.2	postgres:latest	node2	Shutdown	Failed 5 minutes ago	Error: Failed to start

در این خروجی:

• DESIRED STATE: نشان‌دهنده وضعیت مورد انتظار task است (مثلاً Running).
• CURRENT STATE: وضعیت فعلی task است (مثلاً اگر task متوقف شده یا مشکلی وجود داشته باشد، به‌روزرسانی می‌شود).
• ERROR: هر گونه خطا یا مشکلی که در اجرای task به وجود آمده باشد.

در صورتی که سرویس یا task شما در وضعیت “Failed” یا “Shutdown” قرار دارد، به احتمال زیاد مشکلی در پیکربندی یا منابع وجود دارد که باید بررسی شود.

---

۲. مشاهده لاگ‌های سرویس‌ها

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

دستور docker service logs

برای مشاهده لاگ‌های یک سرویس خاص در Docker Swarm از دستور docker service logs استفاده می‌شود.

نمونه دستور برای مشاهده لاگ‌های یک سرویس

docker service logs my_stack_web

در این دستور:

• my_stack_web: نام سرویس که می‌خواهید لاگ‌های آن را مشاهده کنید.

خروجی دستور docker service logs

خروجی این دستور شامل اطلاعاتی درباره وضعیت سرویس، خطاهای احتمالی و پیام‌های ثبت‌شده در طی اجرای سرویس خواهد بود.

my_stack_web.1.abcd1234xyz: Logging started
my_stack_web.1.abcd1234xyz: Error: Unable to connect to database at 10.0.0.2:5432

در این مثال، سرویس my_stack_web از اتصال به دیتابیس 10.0.0.2:5432 شکست خورده است. این نوع خطا ممکن است به دلیل مشکلات در اتصال شبکه یا پیکربندی نادرست سرویس‌ها باشد.

---

۳. بررسی وضعیت نودها

یکی از دلایل عمده برای مشکلات در استک‌ها می‌تواند وضعیت نودهای موجود در کلاستر باشد. اگر نودها به درستی کار نکنند یا به شبکه متصل نباشند، سرویس‌ها و taskها نیز با مشکلاتی مواجه خواهند شد.

دستور docker node ls

برای مشاهده وضعیت کلی نودها در کلاستر Docker Swarm، می‌توانید از دستور docker node ls استفاده کنید.

نمونه دستور برای مشاهده وضعیت نودها

docker node ls

این دستور لیستی از تمام نودهای موجود در کلاستر Swarm را به شما نمایش می‌دهد و اطلاعاتی مانند وضعیت نود، نقش (Manager یا Worker) و سایر جزئیات مربوط به هر نود را فراهم می‌کند.

خروجی دستور docker node ls

ID	HOSTNAME	STATUS	AVAILABILITY	MANAGER STATUS
abc123	node1	Ready	Active	Leader
def456	node2	Down	Active	Reachable
ghi789	node3	Ready	Active	None

در این جدول:

• STATUS: وضعیت نود در کلاستر را نشان می‌دهد (مثلاً Ready یا Down).
• AVAILABILITY: وضعیت در دسترس بودن نود برای انجام وظایف (مثلاً Active).
• MANAGER STATUS: وضعیت نود به‌عنوان Manager یا Worker را نشان می‌دهد.

اگر نودی که مشکل دارد به‌طور موقت از کلاستر خارج شده باشد (مثلاً وضعیت Down را داشته باشد)، می‌تواند باعث مشکلاتی در اجرای سرویس‌ها شود.

---

۴. بررسی پیکربندی شبکه‌ها

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

دستور docker network ls

با استفاده از دستور docker network ls می‌توانید تمام شبکه‌های موجود در Docker Swarm را مشاهده کنید.

نمونه دستور برای مشاهده شبکه‌ها

docker network ls

خروجی این دستور لیستی از تمام شبکه‌های Docker موجود در کلاستر را به شما نمایش می‌دهد. شما می‌توانید بررسی کنید که آیا شبکه‌ها به‌درستی پیکربندی شده‌اند یا خیر.

---

۵. استفاده از داکر کمپوز برای بازسازی استک‌ها

در صورت بروز مشکلات پیچیده‌تر، گاهی اوقات بازسازی استک با استفاده از فایل‌های Docker Compose و دستورات docker stack deploy می‌تواند مفید باشد.

دستور docker stack deploy

با استفاده از دستور docker stack deploy می‌توانید استک‌های جدید را ایجاد کنید یا استک‌های قبلی را با فایل Compose جدید بازسازی کنید.

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

docker stack deploy -c docker-compose.yml my_stack

در این دستور:

• docker-compose.yml: فایل Compose جدید که پیکربندی جدید استک را مشخص می‌کند.
• my_stack: نام استک که می‌خواهید آن را بازسازی کنید.

---

جمع‌بندی

عیب‌یابی در استک‌های Docker Swarm یک فرآیند مهم و پیچیده است که نیازمند استفاده از ابزارهای مختلف و تحلیل وضعیت سرویس‌ها، نودها و شبکه‌ها است. دستورات مختلف مانند docker stack ps برای مشاهده وضعیت taskها، docker service logs برای مشاهده لاگ‌ها، و docker node ls برای بررسی وضعیت نودها ابزارهای اصلی برای این کار هستند. استفاده از این ابزارها به شما این امکان را می‌دهد که مشکلات مختلف را شناسایی کنید و اقدام به رفع آن‌ها نمایید. با پیگیری این مراحل، می‌توانید استک‌های Docker Swarm خود را به‌طور مؤثر مدیریت کنید و از اجرای بهینه آن‌ها اطمینان حاصل کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. افزایش تعداد رپلیکاها (Replica Scaling)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تغییر تعداد Replicaهای سرویس‌ها در زمان اجرا” subtitle=”توضیحات کامل”]در Docker Swarm، مفهوم Replica به تعداد نسخه‌های یک سرویس اطلاق می‌شود که در کلاستر اجرا می‌شوند. استفاده از Replicaها برای توزیع بار و مقیاس‌پذیری به شما این امکان را می‌دهد که به طور پویا تعداد سرویس‌های در حال اجرا را تغییر دهید، به‌ویژه زمانی که نیاز به منابع بیشتر یا کاهش آن‌ها دارید.

در این بخش، به چگونگی تغییر تعداد Replicaهای یک سرویس در زمان اجرا خواهیم پرداخت، از جمله نحوه تغییر این مقدار با استفاده از دستورات CLI، و مواردی که باید هنگام انجام این کار در نظر داشته باشید.

---

۱. مفاهیم اولیه در مورد Replicaها

در Docker Swarm، سرویس‌ها می‌توانند دارای چندین نسخه از یک کانتینر باشند. این نسخه‌ها به نام Replica شناخته می‌شوند. زمانی که یک سرویس را با تعداد Replica خاصی راه‌اندازی می‌کنید، Swarm به طور خودکار کانتینرهای مورد نیاز را در نودهای مختلف کلاستر توزیع می‌کند.

• Replica به تعداد کانتینرهایی گفته می‌شود که باید از یک سرویس در کلاستر اجرا شوند.
• در حالت معمول، Swarm تعداد Replicaها را به‌طور خودکار کنترل می‌کند تا اطمینان حاصل کند که تعداد مطلوب از سرویس‌ها در هر لحظه در حال اجرا هستند.

---

۲. تغییر تعداد Replicaها به‌صورت پویا

یکی از ویژگی‌های اصلی Docker Swarm این است که می‌توان تعداد Replicaهای یک سرویس را به‌صورت پویا تغییر داد. این امکان بسیار مفید است زمانی که بخواهید بار کاری را در کلاستر افزایش یا کاهش دهید، بدون اینکه نیازی به راه‌اندازی مجدد کامل سرویس‌ها داشته باشید.

دستور برای تغییر تعداد Replicaها

برای تغییر تعداد Replicaهای یک سرویس در Docker Swarm از دستور docker service scale استفاده می‌شود. این دستور به شما این امکان را می‌دهد که تعداد Replicaهای یک سرویس را به‌طور مستقیم تنظیم کنید.

نمونه دستور برای تغییر تعداد Replicaها

فرض کنید که نام سرویس شما my_stack_web است و می‌خواهید تعداد Replicaها را به 5 تغییر دهید.

docker service scale my_stack_web=5

در این دستور:

• my_stack_web: نام سرویس مورد نظر.
• 5: تعداد Replicaهایی که می‌خواهید برای این سرویس تعیین کنید.

با اجرای این دستور، Docker Swarm به‌طور خودکار تعداد کانتینرهای مربوط به سرویس my_stack_web را به 5 افزایش می‌دهد (یا در صورت کاهش، آن‌ها را کاهش می‌دهد).

نتیجه‌گیری

پس از اجرای دستور بالا، تعداد Replicaهای سرویس my_stack_web به 5 تغییر می‌کند. Swarm به‌طور خودکار کانتینرها را در نودهای مختلف توزیع می‌کند تا اطمینان حاصل کند که این تعداد کانتینر در حال اجرا هستند.

---

۳. بررسی وضعیت سرویس پس از تغییر تعداد Replicaها

بعد از اینکه تعداد Replicaها را تغییر دادید، ممکن است بخواهید وضعیت سرویس را بررسی کنید تا مطمئن شوید که تغییرات به درستی اعمال شده‌اند.

دستور برای مشاهده وضعیت سرویس

برای بررسی وضعیت سرویس بعد از اعمال تغییرات، از دستور docker service ps استفاده کنید. این دستور به شما کمک می‌کند که taskهای سرویس را مشاهده کنید و اطمینان حاصل کنید که همه Replicaها به درستی در حال اجرا هستند.

نمونه دستور برای مشاهده وضعیت سرویس

docker service ps my_stack_web

خروجی این دستور نشان‌دهنده وضعیت taskهای مربوط به سرویس my_stack_web خواهد بود و شما می‌توانید ببینید که تمام Replicaها در کجا در حال اجرا هستند.

خروجی دستور docker service ps

ID	NAME	IMAGE	NODE	DESIRED STATE	CURRENT STATE
abc123	my_stack_web.1	nginx:latest	node1	Running	Running 10 minutes ago
def456	my_stack_web.2	nginx:latest	node2	Running	Running 10 minutes ago
ghi789	my_stack_web.3	nginx:latest	node3	Running	Running 10 minutes ago
jkl012	my_stack_web.4	nginx:latest	node1	Running	Running 5 minutes ago
mno345	my_stack_web.5	nginx:latest	node2	Running	Running 5 minutes ago

---

۴. نکات مهم در هنگام تغییر تعداد Replicaها

1. توزیع بار: وقتی تعداد Replicaها را تغییر می‌دهید، Docker Swarm سعی می‌کند کانتینرها را به‌طور مساوی بین نودهای مختلف توزیع کند. این امر باعث افزایش مقیاس‌پذیری و توزیع بهتر بار می‌شود.
2. سرویس‌های مقیاس‌پذیر: در صورتی که سرویس شما به منابع زیاد یا متغیر نیاز دارد، تغییر تعداد Replicaها در زمان اجرا یک راه‌حل مناسب برای پاسخ به نیازهای مقیاس‌پذیری است.
3. پایداری سرویس‌ها: Docker Swarm به‌طور خودکار سعی می‌کند که همه Replicaها را به‌درستی در نودهای مختلف اجرا کند. با این حال، اگر منابع کافی برای اجرای Replicaهای جدید وجود نداشته باشد، ممکن است بعضی از سرویس‌ها نتوانند به درستی راه‌اندازی شوند.
4. بررسی وضعیت سرویس‌ها: پس از اعمال تغییرات، همیشه وضعیت سرویس‌ها را بررسی کنید تا اطمینان حاصل کنید که همه چیز طبق انتظار کار می‌کند.

---

۵. تغییر تعداد Replicaها در فایل‌های Compose

گاهی اوقات ممکن است بخواهید تعداد Replicaها را به‌طور دائم در پیکربندی سرویس‌های Docker Compose تنظیم کنید. در این صورت، می‌توانید تغییرات مورد نظر را در فایل docker-compose.yml اعمال کنید و سپس استک را مجدداً راه‌اندازی کنید.

نمونه فایل docker-compose.yml

version: "3"
services:
  web:
    image: nginx:latest
    deploy:
      replicas: 5
      resources:
        limits:
          cpus: "0.5"
          memory: 50M

در این مثال:

• تعداد Replicaها برای سرویس web به 5 تغییر داده شده است.
• بعد از اعمال تغییرات، می‌توانید استک را مجدداً با دستور docker stack deploy راه‌اندازی کنید.

دستور برای راه‌اندازی استک بعد از تغییرات

docker stack deploy -c docker-compose.yml my_stack

---

جمع‌بندی

تغییر تعداد Replicaها در Docker Swarm یکی از ویژگی‌های مقیاس‌پذیری است که به شما امکان می‌دهد تعداد کانتینرهای یک سرویس را به‌صورت پویا تغییر دهید. با استفاده از دستور docker service scale می‌توانید تعداد Replicaها را افزایش یا کاهش دهید و با دستورات دیگری مانند docker service ps وضعیت آن‌ها را بررسی کنید. این قابلیت به شما این امکان را می‌دهد که به راحتی و بدون هیچ‌گونه اختلالی در عملکرد سرویس، منابع را بهینه‌سازی کنید و مقیاس‌پذیری سیستم خود را بهبود ببخشید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”درک مفاهیم Load Balancing در کلاسترهای Swarm” subtitle=”توضیحات کامل”]در دنیای مدیریت سیستم‌ها و کلاسترها، یکی از جنبه‌های اساسی و حیاتی که می‌تواند عملکرد و مقیاس‌پذیری یک برنامه را بهبود دهد، مفهوم Load Balancing است. در Docker Swarm، Load Balancing به معنی توزیع متعادل درخواست‌ها و بار کاری بین سرویس‌ها و Replicaهای مختلف است که در کلاستر اجرا می‌شوند. این کار باعث می‌شود که هیچ نود و سرویس خاصی دچار اضافه‌بار نشود و سیستم بتواند به طور مؤثرتر و مقیاس‌پذیرتر عمل کند.

در این بخش، ما مفهوم Load Balancing در Docker Swarm را به‌طور کامل بررسی خواهیم کرد، شامل نحوه‌ی کارکرد آن، روش‌های اجرای آن در Swarm، و چگونگی تنظیمات آن برای ایجاد یک سیستم پایدار و مقیاس‌پذیر.

---

۱. مفهوم Load Balancing در کلاسترهای Swarm

در محیط‌های توزیع‌شده، به‌ویژه در کلاسترهای Docker Swarm، هنگامی که یک سرویس دارای چندین Replica است، باید درخواست‌ها به‌طور متوازن و منصفانه بین این Replicaها توزیع شوند تا هیچ یک از آن‌ها بیش از حد بارگذاری نشوند. در غیر این صورت، ممکن است برخی از Replicaها دچار افت عملکرد یا حتی خرابی شوند، در حالی که دیگران با کمبود بار مواجه باشند.

Load Balancing به این معناست که بار کاری (درخواست‌ها، تراکنش‌ها، و غیره) به‌طور مؤثر و یکنواخت بین تمامی سرویس‌های موجود در کلاستر توزیع شود. در Docker Swarm، این کار به‌صورت خودکار انجام می‌شود.

---

۲. نحوه عملکرد Load Balancing در Docker Swarm

در Docker Swarm، Load Balancing به‌طور پیش‌فرض توسط Swarm در سطح سرویس‌ها انجام می‌شود. این به این معنی است که هر درخواست دریافتی برای یک سرویس، به‌طور خودکار به یکی از Replicaهای آن سرویس که در نودهای مختلف اجرا می‌شود، توزیع می‌شود. این پروسه توسط Swarm به طور خودکار و بدون نیاز به تنظیمات پیچیده صورت می‌گیرد.

جزئیات عملکرد Load Balancing

1. آدرس‌دهی درخواست‌ها: هر زمان که یک درخواست به یک سرویس در Swarm ارسال می‌شود، Swarm به‌طور خودکار تصمیم می‌گیرد که این درخواست به کدام Replica از آن سرویس هدایت شود. این کار به‌طور خودکار از طریق Round-Robin انجام می‌شود.
2. Round-Robin: این الگوریتم به‌طور ساده و دورانی، درخواست‌ها را به ترتیب بین Replicaها توزیع می‌کند. به این صورت که پس از ارسال یک درخواست به یک Replica، درخواست بعدی به Replica بعدی ارسال می‌شود و این روند به صورت چرخه‌ای ادامه پیدا می‌کند.
3. پایداری و تحمل خطا: در صورتی که یکی از Replicaها دچار خرابی شود یا نتواند درخواست‌ها را پردازش کند، Swarm به‌طور خودکار درخواست‌ها را به Replicaهای دیگر هدایت می‌کند تا اطمینان حاصل شود که سرویس بدون اختلال به کار خود ادامه می‌دهد.
4. IP-Virtual Load Balancer: Docker Swarm از یک Load Balancer داخلی مبتنی بر IP-Virtual استفاده می‌کند. هر سرویس در Swarm یک IP اختصاصی دارد که برای دسترسی به سرویس‌های آن از خارج از کلاستر استفاده می‌شود. این IP به‌طور خودکار بین Replicaهای مختلف سرویس توزیع می‌شود.

---

۳. چگونگی تنظیم Load Balancing در Docker Swarm

در حالی که Docker Swarm به‌طور پیش‌فرض از Load Balancing استفاده می‌کند، برخی از تنظیمات خاص وجود دارد که می‌تواند برای بهبود عملکرد و مقیاس‌پذیری این ویژگی به کار رود.

تنظیمات پیش‌فرض Load Balancing در Docker Swarm

به طور پیش‌فرض، Swarm از Round-Robin برای توزیع بار استفاده می‌کند. این الگوریتم هیچ نیازی به تنظیمات خاص ندارد و به‌طور خودکار انجام می‌شود. اما برای برخی از نیازهای خاص، ممکن است بخواهید برخی از پارامترها یا ویژگی‌ها را تغییر دهید.

تنظیمات برای درک بهتر Load Balancing

1. تعداد Replicaها و توزیع نودها: یکی از نکاتی که می‌تواند تأثیر زیادی بر عملکرد Load Balancing در Swarm بگذارد، تعداد و توزیع Replicaها در نودهای مختلف است. با تنظیم تعداد Replicaها در سرویس‌ها و اطمینان از توزیع مناسب آن‌ها در نودهای مختلف، می‌توانید بار را به‌طور متعادل‌تری بین نودها توزیع کنید.برای مثال، اگر سرویس شما 5 Replica دارد، Docker Swarm درخواست‌ها را به‌طور یکنواخت بین این 5 Replica توزیع می‌کند.
2. Health Checks و Load Balancing: یکی از مهم‌ترین عوامل تأثیرگذار بر عملکرد Load Balancing، وضعیت سلامت (Health) Replicaها است. اگر یکی از Replicaها در وضعیت سلامت قرار نداشته باشد، Swarm به‌طور خودکار درخواست‌ها را به سایر Replicaهای سالم هدایت می‌کند.برای مثال، می‌توانید در تنظیمات سرویس خود Health Check را فعال کنید:

   services:
     web:
       image: nginx
       deploy:
         replicas: 5
       healthcheck:
         test: ["CMD", "curl", "-f", "http://localhost"]
         interval: 30s
         retries: 3
   

   در این مثال، Docker به‌طور خودکار وضعیت سلامت کانتینرهای web را بررسی می‌کند و اگر یکی از آن‌ها سالم نباشد، درخواست‌ها به دیگر Replicaهای سالم هدایت می‌شوند.

3. Stickiness و Affinity: در برخی از سناریوهای پیچیده، شما ممکن است بخواهید که درخواست‌ها همیشه به همان Replica ارسال شوند. این ویژگی به نام Stickiness یا Session Affinity شناخته می‌شود. Docker Swarm به‌طور پیش‌فرض این ویژگی را ندارد، اما با استفاده از ابزارهای خارجی یا تنظیمات خاص می‌توانید این کار را پیاده‌سازی کنید.

---

۴. مانیتورینگ و عیب‌یابی Load Balancing در Docker Swarm

برای اطمینان از عملکرد صحیح Load Balancing، نیاز به نظارت مستمر دارید. Docker به شما این امکان را می‌دهد که با استفاده از دستورات مختلف، وضعیت سرویس‌ها و Load Balancing را بررسی کنید.

دستورات برای بررسی وضعیت سرویس‌ها

برای بررسی وضعیت سرویس‌ها و تعداد Replicaها، از دستور docker service ps استفاده می‌کنیم:

docker service ps <service_name>

این دستور به شما نشان می‌دهد که کدام Replicaها در حال اجرا هستند و آیا همه‌چیز به‌درستی در حال اجراست یا نه.

بررسی وضعیت Health

برای بررسی وضعیت سلامت سرویس‌ها و اطمینان از اینکه همه Replicaها سالم هستند، از دستور زیر استفاده کنید:

docker ps

این دستور لیستی از تمام کانتینرها را نشان می‌دهد و وضعیت سلامت آن‌ها را نمایش می‌دهد.

---

جمع‌بندی

در Docker Swarm، Load Balancing به‌طور پیش‌فرض به شما این امکان را می‌دهد که بار کاری بین Replicaهای مختلف سرویس‌ها به‌طور خودکار و متوازن توزیع شود. با استفاده از الگوریتم Round-Robin و ویژگی‌هایی مانند Health Checks، Swarm به‌طور مؤثر از درخواست‌ها در کلاستر خود محافظت کرده و سیستم را مقیاس‌پذیرتر می‌کند. همچنین، با استفاده از ابزارهای مختلف Docker می‌توانید وضعیت و عملکرد Load Balancing را به‌دقت مانیتور کنید و در صورت نیاز به بهینه‌سازی، تنظیمات مورد نظر را اعمال کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تنظیم و پیکربندی سرویس‌ها برای دستیابی به قابلیت دسترس‌پذیری بالا (High Availability)” subtitle=”توضیحات کامل”]در دنیای امروز، دسترس‌پذیری بالا (High Availability یا HA) به یکی از ارکان اصلی طراحی سیستم‌های مقیاس‌پذیر و مقاوم تبدیل شده است. زمانی که از HA صحبت می‌کنیم، منظور این است که سرویس‌ها یا برنامه‌ها باید به گونه‌ای پیکربندی شوند که حتی در صورت بروز خرابی یا نقص در بخشی از سیستم، به کار خود ادامه دهند و حداقل میزان قطع خدمات را تجربه کنند.

در Docker Swarm، قابلیت دسترس‌پذیری بالا به‌طور پیش‌فرض با استفاده از ویژگی‌های مقیاس‌پذیری و توزیع بار (Load Balancing) فراهم می‌شود. با این حال، برای دستیابی به دسترس‌پذیری بالا باید تنظیمات خاصی انجام دهیم تا مطمئن شویم سرویس‌ها در برابر خرابی‌های نودها، کانتینرها و یا سرویس‌های منفرد مقاوم باشند.

در این بخش، به بررسی نحوه تنظیم و پیکربندی سرویس‌ها برای دستیابی به قابلیت دسترس‌پذیری بالا در Docker Swarm خواهیم پرداخت. این تنظیمات شامل مقیاس‌پذیری، استفاده از Replicaها، پیکربندی Rolling Updates و تنظیمات مربوط به سلامت سرویس‌ها (Health Checks) می‌شود.

---

۱. اهمیت قابلیت دسترس‌پذیری بالا (High Availability)

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

در Docker Swarm، دسترس‌پذیری بالا با استفاده از ویژگی‌هایی نظیر Replicaها، تنظیمات Health Check، توزیع بار، و Rolling Updates حاصل می‌شود.

---

۲. استفاده از Replicaها برای دسترس‌پذیری بالا

یکی از مهم‌ترین روش‌ها برای دستیابی به قابلیت دسترس‌پذیری بالا در Docker Swarm، استفاده از Replicaها است. Replicaها در واقع نسخه‌های متعدد یک سرویس هستند که در نودهای مختلف کلاستر اجرا می‌شوند. این باعث می‌شود که در صورت خرابی یک نود یا کانتینر، باقی Replicaها به‌طور خودکار درخواست‌ها را دریافت کرده و سرویس بدون وقفه ادامه یابد.

تنظیم تعداد Replicaها برای دسترس‌پذیری بالا

برای داشتن دسترس‌پذیری بالا، باید تعداد کافی از Replicaها را برای سرویس‌ها ایجاد کنید. اگر یک سرویس را با تعداد کمی Replica راه‌اندازی کنید، ممکن است در صورت خرابی یکی از آن‌ها، سرویس به کلی از دسترس خارج شود.

برای مثال، اگر سرویس شما 3 Replica دارد، حتی اگر یکی از Replicaها دچار خرابی شود، 2 Replica دیگر همچنان سرویس را در دسترس نگه می‌دارند.

برای تنظیم تعداد Replicaها در سرویس، می‌توانید از دستور docker service create یا فایل‌های Docker Compose استفاده کنید.

نمونه دستور برای ایجاد سرویس با 3 Replica:

docker service create \
  --name my-web-service \
  --replicas 3 \
  nginx

این دستور سرویس my-web-service را با 3 Replica از تصویر nginx راه‌اندازی می‌کند.

---

۳. توزیع سرویس‌ها بر روی نودهای مختلف

یکی از الزامات دسترس‌پذیری بالا، توزیع مناسب سرویس‌ها در نودهای مختلف است. اگر تمام Replicaهای یک سرویس در یک نود قرار بگیرند، در صورت خرابی آن نود، تمامی Replicaها از دسترس خارج خواهند شد. بنابراین، باید سرویس‌ها را طوری تنظیم کنیم که Replicaها به‌طور متوازن روی نودهای مختلف کلاستر توزیع شوند.

Docker Swarm به‌طور پیش‌فرض سعی می‌کند Replicaها را بر روی نودهای مختلف توزیع کند. اما در صورتی که بخواهید توزیع خاصی داشته باشید، می‌توانید از تنظیمات Placement Constraints استفاده کنید.

مثال دستور برای تنظیم Placement Constraints:

docker service create \
  --name my-web-service \
  --replicas 3 \
  --constraint 'node.role == worker' \
  nginx

این دستور سرویس my-web-service را با 3 Replica راه‌اندازی کرده و اطمینان می‌دهد که همه‌ی Replicaها روی نودهای worker اجرا شوند.

---

۴. Rolling Updates برای به‌روزرسانی بدون وقفه

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

در Docker Swarm، از Rolling Updates برای به‌روزرسانی سرویس‌ها استفاده می‌شود. در این روش، به‌طور خودکار یک Replica جدید از سرویس راه‌اندازی می‌شود و بعد از آن که سالم شد، یک Replica قدیمی حذف می‌شود. این روند برای تمامی Replicaها به‌طور تدریجی تکرار می‌شود.

برای تنظیم Rolling Updates در Docker Swarm، از پارامترهای --update-parallelism و --update-delay استفاده می‌شود.

نمونه دستور برای تنظیم Rolling Updates:

docker service create \
  --name my-web-service \
  --replicas 3 \
  --update-parallelism 1 \
  --update-delay 10s \
  nginx

در این دستور، سرویس my-web-service با 3 Replica راه‌اندازی می‌شود و به‌روزرسانی سرویس به‌صورت یک‌به‌یک انجام می‌شود، به این معنی که یک Replica به‌طور همزمان به‌روزرسانی می‌شود و سپس بعد از آن که سالم شد، Replica بعدی به‌روزرسانی می‌شود.

---

۵. استفاده از Health Checks برای اطمینان از سلامت سرویس‌ها

برای دستیابی به قابلیت دسترس‌پذیری بالا، باید از Health Checks استفاده کنید تا اطمینان حاصل شود که تمامی Replicaها سالم هستند. Docker به شما این امکان را می‌دهد که برای هر سرویس، دستوراتی را برای بررسی سلامت کانتینرها تعریف کنید. در صورتی که یک Replica سالم نباشد، Docker به‌طور خودکار آن را از سرویس خارج کرده و درخواست‌ها را به Replicaهای سالم هدایت می‌کند.

برای اضافه کردن Health Check به سرویس‌ها، می‌توانید از گزینه --health-cmd هنگام ایجاد یا به‌روزرسانی سرویس استفاده کنید.

نمونه دستور برای تنظیم Health Check:

docker service create \
  --name my-web-service \
  --replicas 3 \
  --health-cmd "curl --fail http://localhost || exit 1" \
  --health-interval 30s \
  --health-retries 3 \
  nginx

در این مثال، Docker به‌طور دوره‌ای وضعیت سلامت سرویس را با استفاده از دستور curl بررسی می‌کند. اگر سرویس بیش از سه بار به‌طور متوالی ناسالم باشد، از دسترس خارج می‌شود و درخواست‌ها به Replicaهای سالم هدایت می‌شوند.

---

جمع‌بندی

برای دستیابی به قابلیت دسترس‌پذیری بالا در Docker Swarm، باید از مجموعه‌ای از ویژگی‌ها و تنظیمات استفاده کنید. استفاده از Replicaها، توزیع مناسب سرویس‌ها روی نودهای مختلف، استفاده از Rolling Updates برای به‌روزرسانی بدون وقفه، و افزودن Health Check به سرویس‌ها، همه این موارد می‌توانند کمک کنند تا سرویس‌ها بدون اختلال به کار خود ادامه دهند. با اعمال این تنظیمات، می‌توانید از سیستم‌هایی با قابلیت دسترس‌پذیری بالا بهره‌برداری کنید که حتی در صورت خرابی نودها یا کانتینرها، سرویس‌ها همچنان در دسترس باقی بمانند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. افزودن شبکه‌ها، پورت‌ها و حجم‌ها به سرویس‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد شبکه‌های Overlay برای اتصال سرویس‌ها در کلاستر” subtitle=”توضیحات کامل”]در Docker Swarm، یکی از چالش‌های مهم در مدیریت کلاسترها، اتصال سرویس‌ها به یکدیگر در شرایطی است که سرویس‌ها در نودهای مختلف کلاستر اجرا می‌شوند. Docker برای حل این مشکل از مفهوم شبکه‌های Overlay استفاده می‌کند. شبکه‌های Overlay به شما این امکان را می‌دهند که سرویس‌ها و کانتینرها در نودهای مختلف بتوانند با یکدیگر ارتباط برقرار کنند، بدون اینکه نیازی به تغییر در شبکه‌های فیزیکی و تنظیمات پیچیده داشته باشید.

در این بخش، به بررسی نحوه ایجاد شبکه‌های Overlay در Docker Swarm خواهیم پرداخت و نشان خواهیم داد که چگونه می‌توان از این شبکه‌ها برای اتصال سرویس‌ها در کلاستر استفاده کرد.

---

۱. مفهوم شبکه Overlay در Docker Swarm

شبکه‌های Overlay در Docker به این صورت عمل می‌کنند که یک شبکه مجازی ایجاد می‌کنند که بر روی زیرساخت‌های فیزیکی مختلف (یعنی نودهای کلاستر) قرار می‌گیرد. در واقع، شبکه‌های Overlay مانند یک لایه اضافی عمل کرده که روی شبکه‌های فیزیکی قرار می‌گیرد و به کانتینرها اجازه می‌دهد تا به‌طور شفاف با یکدیگر ارتباط برقرار کنند، حتی اگر بر روی نودهای مختلف اجرا شوند.

در Docker Swarm، این شبکه‌ها به‌طور خاص برای ارتباط میان سرویس‌ها و کانتینرها در یک کلاستر طراحی شده‌اند. به عبارت دیگر، شبکه‌های Overlay به شما این امکان را می‌دهند که سرویس‌هایی که بر روی نودهای مختلف کلاستر اجرا می‌شوند، به‌طور مستقیم و بدون نیاز به پیکربندی پیچیده شبکه‌های زیرساختی، به یکدیگر متصل شوند.

---

۲. نحوه ایجاد یک شبکه Overlay در Docker Swarm

برای ایجاد یک شبکه Overlay در Docker Swarm، باید از دستور docker network create استفاده کنید. در این دستور، گزینه --driver overlay برای تعیین نوع شبکه (Overlay) و گزینه --scope swarm برای مشخص کردن اینکه شبکه در سطح کلاستر (Swarm) باید ایجاد شود، استفاده می‌شود.

نمونه دستور برای ایجاد شبکه Overlay:

docker network create \
  --driver overlay \
  --scope swarm \
  my-overlay-network

در این دستور، شبکه‌ای به نام my-overlay-network ایجاد می‌شود که از نوع Overlay است و در سطح کلاستر Swarm قرار دارد.

---

۳. استفاده از شبکه Overlay برای اتصال سرویس‌ها

پس از ایجاد شبکه Overlay، می‌توانید سرویس‌ها را طوری پیکربندی کنید که از این شبکه برای ارتباط با یکدیگر استفاده کنند. در واقع، وقتی که سرویس‌ها را در Docker Swarm راه‌اندازی می‌کنید، می‌توانید مشخص کنید که سرویس‌ها از چه شبکه‌ای برای ارتباط استفاده کنند.

برای مثال، در هنگام ایجاد سرویس‌ها می‌توانید با استفاده از گزینه --network شبکه‌ای را که قبلاً ایجاد کرده‌اید، به سرویس‌ها اختصاص دهید.

نمونه دستور برای ایجاد سرویس با استفاده از شبکه Overlay:

docker service create \
  --name my-web-service \
  --replicas 3 \
  --network my-overlay-network \
  nginx

در این مثال، سرویس my-web-service با 3 Replica از تصویر nginx راه‌اندازی می‌شود و تمامی Replicaها به شبکه my-overlay-network متصل می‌شوند.

---

۴. ارتباط میان سرویس‌ها در شبکه Overlay

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

برای مثال، اگر دو سرویس به نام‌های web و db داشته باشید و هر دو به شبکه my-overlay-network متصل باشند، می‌توانند به‌راحتی از یکدیگر استفاده کنند. شما می‌توانید از نام سرویس‌ها برای برقراری ارتباط میان آن‌ها استفاده کنید:

• سرویس web می‌تواند از نام سرویس db برای برقراری ارتباط با سرویس پایگاه داده استفاده کند.

این ارتباط به‌صورت DNS-based انجام می‌شود و Docker Swarm به‌طور خودکار نام سرویس‌ها را به آدرس‌های IP مربوطه تبدیل می‌کند.

نمونه ارتباط بین سرویس‌ها:

فرض کنید سرویس web می‌خواهد به پایگاه داده db که در همان شبکه قرار دارد متصل شود. برای این منظور، سرویس web می‌تواند به جای استفاده از IP، از نام سرویس db استفاده کند:

# در سرویس web می‌توانید از db به عنوان نام میزبان استفاده کنید
curl http://db:5432

در اینجا، db نام سرویس پایگاه داده است که از آن استفاده می‌شود.

---

۵. استفاده از شبکه‌های Overlay برای ایزوله‌سازی سرویس‌ها

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

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

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

1. ایجاد شبکه اول:

docker network create \
  --driver overlay \
  --scope swarm \
  network-1

2. ایجاد شبکه دوم:

docker network create \
  --driver overlay \
  --scope swarm \
  network-2

3. ایجاد سرویس‌ها در شبکه‌های مختلف:

docker service create \
  --name service-1 \
  --network network-1 \
  nginx

docker service create \
  --name service-2 \
  --network network-2 \
  nginx

در این مثال، سرویس‌ها service-1 و service-2 در شبکه‌های مختلف قرار دارند و نمی‌توانند به یکدیگر دسترسی داشته باشند.

---

جمع‌بندی

شبکه‌های Overlay در Docker Swarm به‌طور ویژه برای اتصال سرویس‌ها در کلاسترهای توزیع‌شده طراحی شده‌اند. این شبکه‌ها به شما این امکان را می‌دهند که سرویس‌ها و کانتینرهای مختلف در نودهای مختلف کلاستر به‌صورت ایمن و شفاف با یکدیگر ارتباط برقرار کنند. با استفاده از شبکه‌های Overlay، می‌توانید سرویس‌ها را از شبکه‌های فیزیکی جدا کرده و از ویژگی‌های مقیاس‌پذیری و ایزولاسیون بهره‌برداری کنید.

ایجاد شبکه Overlay به‌راحتی انجام می‌شود و می‌توان آن را در هنگام راه‌اندازی سرویس‌ها یا در زمان اجرای سرویس‌ها به آن‌ها اختصاص داد. همچنین با استفاده از این شبکه‌ها، می‌توان از ارتباط نام‌محور بین سرویس‌ها بهره برد و امنیت و ایزولاسیون بیشتری را برای سرویس‌ها فراهم کرد.

شبکه‌های Overlay، در کنار سایر ویژگی‌های Docker Swarm، می‌توانند به‌طور مؤثر به شما کمک کنند تا سیستم‌های مقیاس‌پذیر، مقاوم و امن بسازید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پیکربندی پورت‌ها برای سرویس‌ها به منظور دسترسی خارجی” subtitle=”توضیحات کامل”]در محیط‌های Docker Swarm، یکی از چالش‌های اصلی زمانی که سرویس‌ها به‌طور خودکار بر روی نودهای مختلف کلاستر اجرا می‌شوند، فراهم کردن دسترسی خارجی به این سرویس‌ها است. معمولاً برای برقراری ارتباط با سرویس‌های در حال اجرا در کلاستر، نیاز به نقشه‌برداری پورت‌ها وجود دارد تا ترافیک از بیرون کلاستر بتواند به درستی به سرویس‌های داخلی هدایت شود. این عملیات معمولاً با استفاده از پیکربندی پورت‌ها انجام می‌شود که به سرویس‌ها این امکان را می‌دهد تا از طریق پورت‌های خاصی در دسترس عموم قرار بگیرند.

در این بخش به بررسی نحوه پیکربندی پورت‌ها برای سرویس‌های Docker Swarm به منظور دسترسی به آن‌ها از خارج کلاستر خواهیم پرداخت.

---

۱. پیکربندی پورت‌ها در هنگام ایجاد سرویس

برای پیکربندی پورت‌ها در Docker Swarm و فراهم کردن دسترسی خارجی به سرویس‌ها، می‌توانید هنگام ایجاد سرویس از گزینه --publish استفاده کنید. این گزینه به شما این امکان را می‌دهد که پورت‌های داخلی سرویس را به پورت‌های خارجی نقشه‌برداری کنید، تا بتوانید از بیرون کلاستر به سرویس دسترسی داشته باشید.

دستور عمومی برای نقشه‌برداری پورت‌ها در Docker Swarm:

docker service create \
  --name my-service \
  --publish <external-port>:<internal-port> \
  <image-name>

در این دستور:

• <external-port> پورت خارجی است که از بیرون کلاستر به آن دسترسی خواهید داشت.
• <internal-port> پورت داخلی است که سرویس در داخل کلاستر روی آن در حال اجرا است.
• <image-name> نام تصویر داکری است که می‌خواهید از آن برای راه‌اندازی سرویس استفاده کنید.

نمونه دستور پیکربندی پورت‌ها برای سرویس وب:

docker service create \
  --name my-web-service \
  --publish 8080:80 \
  nginx

در این مثال:

• سرویس my-web-service از تصویر nginx ساخته می‌شود.
• پورت 80 (پورت داخلی سرویس nginx) به پورت 8080 (پورت خارجی) نقشه‌برداری می‌شود.
• اکنون، با دسترسی به پورت 8080 در هر نود از کلاستر، می‌توانید به سرویس وب nginx دسترسی پیدا کنید.

---

۲. پیکربندی چند پورت برای سرویس‌ها

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

نمونه دستور پیکربندی چند پورت برای سرویس‌ها:

docker service create \
  --name my-multi-port-service \
  --publish 8080:80 \
  --publish 443:443 \
  nginx

در این مثال، پورت 80 به پورت 8080 و پورت 443 به پورت 443 در دسترس خارجی قرار می‌گیرد. به این ترتیب، شما می‌توانید از سرویس nginx هم از طریق HTTP (پورت 8080) و هم از طریق HTTPS (پورت 443) دسترسی داشته باشید.

---

۳. پیکربندی پورت‌ها برای سرویس‌های با تعداد Replica بالا

یکی از ویژگی‌های Docker Swarm، مقیاس‌پذیری است، که به شما این امکان را می‌دهد که تعداد زیادی Replica از یک سرویس را در کلاستر خود راه‌اندازی کنید. هنگامی که سرویس‌ها مقیاس‌پذیر هستند، ممکن است تعدادی از Replicaها بر روی نودهای مختلف قرار بگیرند. در این حالت، Docker Swarm به‌طور خودکار Load Balancing را برای توزیع ترافیک به Replicaهای مختلف انجام می‌دهد.

وقتی سرویس‌ها مقیاس‌پذیر هستند، پیکربندی پورت‌ها همچنان برای دسترسی خارجی به آن‌ها کاربرد دارد. Docker Swarm به‌طور خودکار پورت‌ها را به تمام Replicaها و نودهای کلاستر تخصیص می‌دهد.

نمونه دستور برای پیکربندی پورت‌ها در سرویس با تعداد Replica بالا:

docker service create \
  --name my-scale-service \
  --replicas 5 \
  --publish 8080:80 \
  nginx

در این مثال، 5 Replica از سرویس my-scale-service در کلاستر راه‌اندازی می‌شود و پورت 80 به پورت 8080 خارجی نقشه‌برداری می‌شود. Docker Swarm به‌طور خودکار ترافیک دریافتی در پورت 8080 را به تمامی Replicaهای سرویس هدایت می‌کند.

---

۴. استفاده از Port Range برای پیکربندی چند پورت

اگر نیاز دارید که یک بازه از پورت‌ها را برای سرویس خود باز کنید، می‌توانید از بازه پورت‌ها استفاده کنید. برای این کار، می‌توانید بازه پورت‌ها را در دستور --publish به‌صورت زیر وارد کنید:

نمونه دستور برای استفاده از بازه پورت‌ها:

docker service create \
  --name my-service-with-port-range \
  --publish 8000-8010:80 \
  nginx

در این مثال، پورت‌های 8000 تا 8010 در سطح خارجی به پورت 80 داخلی سرویس nginx نقشه‌برداری می‌شوند.

---

۵. پیکربندی پورت‌ها با استفاده از فایل Docker Compose

در صورتی که بخواهید سرویس‌ها را با استفاده از فایل Docker Compose در کلاستر Swarm راه‌اندازی کنید، می‌توانید پیکربندی پورت‌ها را در فایل Compose انجام دهید. برای این منظور، بخش ports را در فایل Compose برای سرویس‌ها تعیین می‌کنید.

نمونه فایل docker-compose.yml برای پیکربندی پورت‌ها:

version: '3.8'

services:
  web:
    image: nginx
    deploy:
      replicas: 3
    ports:
      - "8080:80"

در این فایل Compose، سرویس web از تصویر nginx استفاده می‌کند و پورت 80 داخلی به پورت 8080 خارجی نقشه‌برداری می‌شود. همچنین، این سرویس به‌صورت مقیاس‌پذیر با 3 Replica راه‌اندازی می‌شود.

---

۶. بررسی پیکربندی پورت‌ها در حال اجرا

برای بررسی اینکه پورت‌ها به‌درستی برای سرویس‌ها پیکربندی شده‌اند، می‌توانید از دستور docker service ls و docker service ps استفاده کنید.

برای مشاهده پورت‌های مرتبط با سرویس‌ها، دستور زیر را وارد کنید:

docker service ls

همچنین، برای مشاهده اطلاعات دقیق‌تر در مورد سرویس‌ها و پیکربندی آن‌ها:

docker service ps my-web-service

این دستور به شما نشان می‌دهد که سرویس my-web-service در حال اجرا است و پورت‌های خارجی آن به‌درستی به پورت‌های داخلی سرویس‌ها متصل شده‌اند.

---

 جمع‌بندی

پیکربندی پورت‌ها در Docker Swarm برای دسترسی خارجی به سرویس‌ها یکی از الزامات اساسی در مدیریت سرویس‌های مقیاس‌پذیر است. با استفاده از گزینه --publish می‌توانید پورت‌های داخلی سرویس‌ها را به پورت‌های خارجی نقشه‌برداری کرده و به‌راحتی به سرویس‌ها از بیرون کلاستر دسترسی داشته باشید.

این عملیات می‌تواند برای سرویس‌های با تعداد Replica بالا، شبکه‌های مختلف، یا حتی برای بازه‌های پورت‌ها به کار رود. همچنین، از طریق فایل‌های Docker Compose می‌توانید پیکربندی پورت‌ها را برای سرویس‌های خود تنظیم کرده و آن‌ها را در کلاستر Swarm مستقر کنید.

استفاده از پیکربندی صحیح پورت‌ها و نقشه‌برداری آن‌ها به‌درستی می‌تواند به دسترسی آسان‌تر و مدیریت بهتر سرویس‌ها در کلاسترهای Docker Swarm کمک کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اتصال حجم‌ها (Volumes) به سرویس‌ها برای ذخیره داده‌های پایدار” subtitle=”توضیحات کامل”]در Docker Swarm، یکی از چالش‌های مهم زمانی که سرویس‌ها در حال اجرا هستند، حفظ داده‌های پایدار است. معمولاً کانتینرها به‌طور پیش‌فرض داده‌های خود را در داخل سیستم فایل خود ذخیره می‌کنند، اما این داده‌ها به محض حذف کانتینر از بین می‌روند. در اینجا حجم‌ها (Volumes) وارد می‌شوند؛ حجم‌ها امکان ذخیره داده‌های پایدار را به شما می‌دهند، حتی اگر کانتینرها حذف یا مجدداً راه‌اندازی شوند.

اتصال حجم‌ها به سرویس‌ها در Docker Swarm برای اطمینان از دسترس‌پذیری داده‌ها و ماندگاری آن‌ها بسیار مهم است. این کار با استفاده از ویژگی‌های Docker Volumes انجام می‌شود که امکان ذخیره و به اشتراک‌گذاری داده‌ها بین کانتینرها، حتی در نودهای مختلف کلاستر را فراهم می‌آورد.

در این بخش، نحوه اتصال حجم‌ها به سرویس‌ها برای ذخیره داده‌های پایدار در Docker Swarm توضیح داده خواهد شد.

---

۱. ایجاد حجم (Volume)

قبل از اینکه بخواهید یک حجم را به سرویس‌ها متصل کنید، ابتدا باید حجم مورد نظر را ایجاد کنید. حجم‌ها در Docker به‌طور پیش‌فرض به‌صورت محلی در نودهای Docker ذخیره می‌شوند، اما می‌توان از حجم‌های اشتراکی نیز استفاده کرد که در چند نود کلاستر به اشتراک گذاشته می‌شود.

برای ایجاد یک حجم جدید در Docker از دستور زیر استفاده می‌شود:

docker volume create my-volume

این دستور یک حجم جدید به نام my-volume ایجاد می‌کند که می‌توان آن را به سرویس‌ها یا کانتینرها متصل کرد.

---

۲. اتصال حجم‌ها به سرویس‌ها در هنگام ایجاد سرویس

برای اتصال حجم‌ها به سرویس‌ها در Docker Swarm، می‌توانید از گزینه --mount هنگام ایجاد سرویس استفاده کنید. این گزینه به شما امکان می‌دهد که حجم‌هایی که قبلاً ایجاد کرده‌اید را به سرویس‌های خود متصل کنید.

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

docker service create \
  --name <service-name> \
  --mount type=volume,source=<volume-name>,target=<container-path> \
  <image-name>

در این دستور:

• <service-name> نام سرویس است که می‌خواهید راه‌اندازی کنید.
• <volume-name> نام حجم است که می‌خواهید به سرویس متصل کنید.
• <container-path> مسیر داخل کانتینر است که می‌خواهید حجم را در آنجا نصب کنید.
• <image-name> نام تصویر داکری است که می‌خواهید از آن برای راه‌اندازی سرویس استفاده کنید.

نمونه دستور برای اتصال حجم به سرویس:

docker service create \
  --name my-db-service \
  --mount type=volume,source=my-volume,target=/var/lib/mysql \
  mysql

در این مثال:

• سرویس my-db-service از تصویر mysql راه‌اندازی می‌شود.
• حجم my-volume به مسیر /var/lib/mysql در داخل کانتینر متصل می‌شود.
• این حجم برای ذخیره داده‌های پایدار پایگاه داده MySQL استفاده خواهد شد.

---

۳. اتصال حجم‌ها به سرویس‌ها در Docker Compose

اگر از فایل Docker Compose برای مدیریت سرویس‌های خود استفاده می‌کنید، می‌توانید حجم‌ها را در فایل Compose به راحتی تعریف کرده و آن‌ها را به سرویس‌های مختلف متصل کنید.

نمونه فایل docker-compose.yml برای اتصال حجم به سرویس‌ها:

version: '3.8'

services:
  db:
    image: mysql
    volumes:
      - my-db-volume:/var/lib/mysql

volumes:
  my-db-volume:

در این فایل:

• سرویس db از تصویر mysql استفاده می‌کند.
• حجم my-db-volume به مسیر /var/lib/mysql در داخل کانتینر متصل می‌شود.
• این حجم برای ذخیره داده‌های پایگاه داده MySQL استفاده خواهد شد.
• حجم my-db-volume در بخش volumes فایل Compose تعریف شده است.

برای راه‌اندازی سرویس‌ها با فایل Compose، از دستور زیر استفاده می‌شود:

docker stack deploy -c docker-compose.yml my-stack

---

۴. استفاده از حجم‌های اشتراکی در Docker Swarm

در Docker Swarm، حجم‌های محلی تنها در همان نود قابل دسترس هستند. اگر سرویس شما در چندین نود اجرا می‌شود و نیاز به استفاده از حجم‌های اشتراکی دارید، باید از حجم‌های شبکه‌ای مانند NFS یا GlusterFS استفاده کنید.

برای اتصال حجم‌های اشتراکی به سرویس‌ها، از همان دستور --mount استفاده می‌شود، با این تفاوت که نوع حجم به nfs یا سایر انواع حجم‌های شبکه‌ای تنظیم می‌شود.

نمونه دستور برای استفاده از حجم NFS در سرویس:

docker service create \
  --name my-app-service \
  --mount type=nfs,source=<nfs-server-path>,target=<container-path> \
  nginx

در این دستور:

• <nfs-server-path> مسیر ذخیره‌سازی NFS است که به‌عنوان منبع حجم به Docker داده می‌شود.
• <container-path> مسیر داخلی کانتینر است که حجم باید به آن متصل شود.

---

۵. بررسی وضعیت حجم‌ها و اتصال آن‌ها به سرویس‌ها

برای بررسی اینکه حجم‌ها به‌درستی به سرویس‌ها متصل شده‌اند، می‌توانید از دستور docker service inspect استفاده کنید.

دستور برای بررسی اطلاعات سرویس:

docker service inspect <service-name>

این دستور به شما اطلاعات دقیقی در مورد سرویس و حجم‌های متصل به آن می‌دهد.

دستور برای بررسی حجم‌ها:

docker volume ls

این دستور فهرستی از تمامی حجم‌های موجود در سیستم را نشان می‌دهد.

---

جمع‌بندی

اتصال حجم‌ها (Volumes) به سرویس‌ها در Docker Swarm برای ذخیره داده‌های پایدار امری ضروری است. با استفاده از حجم‌ها می‌توانید داده‌هایی را که بین کانتینرها به اشتراک گذاشته می‌شوند، حفظ کنید، حتی زمانی که کانتینرها از بین می‌روند یا دوباره راه‌اندازی می‌شوند.

اتصال حجم‌ها به سرویس‌ها از طریق گزینه --mount یا در فایل‌های Docker Compose به‌راحتی انجام می‌شود و شما می‌توانید داده‌های پایدار را برای سرویس‌هایی مانند پایگاه داده یا سایر سرویس‌هایی که نیاز به ذخیره داده دارند، فراهم کنید. همچنین در صورت نیاز به حجم‌های اشتراکی، می‌توانید از حجم‌های شبکه‌ای مانند NFS استفاده کنید.

با استفاده صحیح از حجم‌ها، می‌توانید اطمینان حاصل کنید که داده‌ها به‌طور دائم و با قابلیت مقیاس‌پذیری در کلاستر Docker Swarm ذخیره می‌شوند و همیشه در دسترس هستند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اعمال تغییرات به صورت پویا روی سرویس‌های در حال اجرا” subtitle=”توضیحات کامل”]در Docker Swarm، یکی از ویژگی‌های بسیار مهم و مفید این است که شما می‌توانید تغییرات را به صورت پویا و بدون وقفه روی سرویس‌های در حال اجرا اعمال کنید. این ویژگی به ویژه برای محیط‌های تولیدی اهمیت دارد، زیرا به شما این امکان را می‌دهد که بدون ایجاد توقف یا اختلال در سرویس‌ها، تنظیمات جدید را پیاده‌سازی کنید.

در این بخش، چگونگی اعمال تغییرات به صورت پویا بر روی سرویس‌ها در Docker Swarm بررسی خواهد شد. این تغییرات می‌توانند شامل مواردی مانند تغییر تعداد Replicaها، بروزرسانی تصویر کانتینر، تغییر متغیرهای محیطی و پیکربندی‌ها، تغییر پورت‌ها و سایر تنظیمات سرویس باشند.

---

۱. تغییر تعداد Replicaها

یکی از ساده‌ترین و متداول‌ترین تغییرات در هنگام اجرای سرویس‌ها، تغییر تعداد Replicaها (نسخه‌های کانتینر) است. Docker Swarm به شما این امکان را می‌دهد که تعداد کانتینرهای در حال اجرا از یک سرویس را به راحتی تغییر دهید بدون اینکه نیاز به توقف سرویس باشد.

برای تغییر تعداد Replicaها، می‌توانید از دستور docker service update استفاده کنید.

فرمت کلی دستور برای تغییر تعداد Replicaها:

docker service update --replicas <new-replica-count> <service-name>

در این دستور:

• <new-replica-count> تعداد جدید Replicaهایی است که می‌خواهید در سرویس داشته باشید.
• <service-name> نام سرویس مورد نظر است.

نمونه دستور برای تغییر تعداد Replicaها:

docker service update --replicas 5 my-app-service

این دستور تعداد Replicaهای سرویس my-app-service را به ۵ تغییر می‌دهد. به‌طور خودکار Docker Swarm اقدام به راه‌اندازی یا حذف کانتینرها برای همسان‌سازی تعداد Replicaها می‌کند.

---

۲. بروزرسانی تصویر کانتینر (Image Update)

یکی از تغییرات متداول در محیط‌های تولیدی، بروزرسانی سرویس‌ها با استفاده از یک نسخه جدید از تصویر کانتینر است. Docker Swarm به شما این امکان را می‌دهد که بدون متوقف کردن سرویس، یک نسخه جدید از تصویر کانتینر را پیاده‌سازی کنید. این قابلیت در زمان اجرای عملیات Rolling Updates فعال می‌شود.

برای بروزرسانی تصویر کانتینر، دستور زیر استفاده می‌شود:

فرمت کلی دستور برای بروزرسانی تصویر کانتینر:

docker service update --image <new-image-name> <service-name>

در این دستور:

• <new-image-name> نام تصویر جدید است که می‌خواهید از آن برای سرویس استفاده کنید.
• <service-name> نام سرویس مورد نظر است.

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

docker service update --image nginx:latest my-web-service

این دستور باعث می‌شود که تصویر جدید nginx:latest برای سرویس my-web-service پیاده‌سازی شود. Docker Swarm به طور خودکار کانتینرهای قدیمی را از بین می‌برد و کانتینرهای جدید با نسخه جدید تصویر را راه‌اندازی می‌کند.

---

۳. تغییر متغیرهای محیطی (Environment Variables)

گاهی ممکن است نیاز به تغییر متغیرهای محیطی سرویس‌ها در حین اجرای آن‌ها داشته باشید. برای این کار، می‌توانید از دستور docker service update استفاده کنید تا متغیرهای محیطی جدید را به سرویس اضافه کنید یا مقادیر فعلی آن‌ها را تغییر دهید.

فرمت کلی دستور برای تغییر متغیرهای محیطی:

docker service update --env-add <key>=<value> <service-name>

در این دستور:

• <key> نام متغیر محیطی است که می‌خواهید اضافه یا تغییر دهید.
• <value> مقدار جدید متغیر محیطی است.
• <service-name> نام سرویس مورد نظر است.

نمونه دستور برای تغییر یا اضافه کردن یک متغیر محیطی:

docker service update --env-add MYSQL_ROOT_PASSWORD=my-new-password my-db-service

این دستور باعث می‌شود که متغیر محیطی MYSQL_ROOT_PASSWORD برای سرویس my-db-service تغییر کند.

اگر بخواهید یک متغیر محیطی را حذف کنید، می‌توانید از دستور زیر استفاده کنید:

docker service update --env-rm <key> <service-name>

---

۴. تغییر پیکربندی و گزینه‌های سرویس

Docker Swarm به شما این امکان را می‌دهد که پیکربندی‌های مختلف سرویس‌ها مانند محدودیت‌های منابع (CPU و حافظه)، گزینه‌های زمانبندی، تنظیمات استقرار و حتی تنظیمات مربوط به توازن بار (Load Balancing) را به‌صورت پویا تغییر دهید.

برای مثال، برای تغییر محدودیت‌های منابع در هنگام اجرا، از دستور زیر استفاده می‌شود:

فرمت کلی دستور برای تغییر محدودیت‌های منابع:

docker service update --limit-cpu <cpu-limit> --limit-memory <memory-limit> <service-name>

در این دستور:

• <cpu-limit> مقدار جدید محدودیت CPU برای سرویس است.
• <memory-limit> مقدار جدید محدودیت حافظه برای سرویس است.
• <service-name> نام سرویس مورد نظر است.

نمونه دستور برای تغییر محدودیت‌های منابع سرویس:

docker service update --limit-cpu 0.5 --limit-memory 512M my-app-service

این دستور باعث می‌شود که محدودیت CPU و حافظه سرویس my-app-service به ترتیب به ۰.۵ و ۵۱۲ مگابایت تغییر کند.

---

۵. استفاده از Rolling Updates برای تغییرات بدون وقفه

در هنگام اعمال تغییرات در سرویس‌ها، به ویژه بروزرسانی تصاویر کانتینر، می‌توان از ویژگی Rolling Updates برای اطمینان از اینکه سرویس‌ها بدون وقفه در دسترس باقی بمانند، استفاده کرد.

Rolling Update به این صورت عمل می‌کند که Docker Swarm به‌طور تدریجی کانتینرهای قدیمی را حذف و کانتینرهای جدید را راه‌اندازی می‌کند. این فرآیند به شما این اطمینان را می‌دهد که همیشه حداقل یک نسخه از سرویس در حال اجراست.

برای تنظیم ویژگی‌های Rolling Update می‌توانید از دستور زیر استفاده کنید:

فرمت کلی دستور برای تنظیم Rolling Update:

docker service update --update-parallelism <number> <service-name>

در این دستور:

• <number> تعداد کانتینرهایی است که باید به طور هم‌زمان بروزرسانی شوند.
• <service-name> نام سرویس مورد نظر است.

نمونه دستور برای تنظیم Rolling Update:

docker service update --update-parallelism 2 my-app-service

این دستور باعث می‌شود که دو کانتینر از سرویس my-app-service به طور هم‌زمان بروزرسانی شوند، تا توازن و دسترس‌پذیری سرویس حفظ شود.

---

جمع‌بندی

اعمال تغییرات به صورت پویا روی سرویس‌های در حال اجرا در Docker Swarm به شما این امکان را می‌دهد که بدون وقفه و اختلال در سرویس‌ها، تنظیمات و پیکربندی‌های جدید را پیاده‌سازی کنید. این قابلیت برای محیط‌های تولیدی که نیاز به حفظ دسترس‌پذیری و عملکرد مستمر دارند، ضروری است.

تغییرات شامل بروزرسانی تعداد Replicaها، تغییر تصویر کانتینر، تغییر متغیرهای محیطی، تغییر تنظیمات پیکربندی و حتی تنظیمات مربوط به Rolling Updates و محدودیت‌های منابع می‌باشد که می‌توانند بدون توقف سرویس‌ها اعمال شوند. این فرآیند باعث افزایش انعطاف‌پذیری و بهبود مدیریت سرویس‌ها در Docker Swarm می‌شود.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. درک اهمیت کوُروم (Quorum) در کلاسترهای Swarm”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف Quorum و اهمیت آن در کلاسترهای Swarm” subtitle=”توضیحات کامل”]در کلاسترهای Docker Swarm، مفهوم Quorum یکی از اصول کلیدی و مهم در راستای حفظ صحت، همگامی، و در دسترس بودن کلاستر است. Quorum در واقع به حداقل تعداد نودهای Manager که باید در دسترس و آنلاین باشند تا کلاستر بتواند به درستی عمل کند، اشاره دارد. اگر تعداد نودهای Manager که آنلاین و در دسترس هستند به حداقل مقدار مشخص شده (Quorum) نرسد، امکان ادامه عملیات در کلاستر وجود ندارد و کلاستر به حالت «غیرفعال» یا «غیرقابل دسترسی» می‌رود.

مفهوم Quorum در Docker Swarm، به‌ویژه در زمان‌های بروز مشکلات و خرابی‌های شبکه یا قطع شدن نودهای Manager، نقش بسیار مهمی ایفا می‌کند. در این حالت، Docker Swarm باید بتواند تصمیمات هماهنگ و متقنی را در مورد وضعیت کلاستر اتخاذ کند و این تنها در صورتی امکان‌پذیر است که حداقل نودهای Manager به اندازه کافی در دسترس باشند تا بتوانند تصمیمات جمعی را در مورد وضعیت کلاستر اتخاذ کنند.

---

چرا Quorum مهم است؟

Quorum به عنوان یک مکانیسم برای جلوگیری از Split-Brain (وضعیتی که در آن دو بخش از کلاستر به‌طور جداگانه و بدون هماهنگی عمل کنند) طراحی شده است. در صورت عدم وجود Quorum یا کاهش تعداد نودهای Manager زیر حد نصاب، Docker Swarm قادر به انجام تصمیم‌گیری‌های ضروری نخواهد بود و ممکن است کلاستر وارد حالت‌های ناامن یا نامطمئن شود.

بنابراین، اهمیت Quorum به این دلیل است که:

1. پایداری و یکپارچگی کلاستر: Quorum برای اطمینان از یکپارچگی و پایداری کلاستر ضروری است. هنگامی که تعداد کافی از نودهای Manager در دسترس نباشند، Docker Swarm نمی‌تواند تصمیمات صحیح را به درستی اتخاذ کند. این موضوع باعث می‌شود که عملیات‌هایی مانند انتخاب Leader یا به‌روزرسانی‌های مربوط به وضعیت کلاستر به درستی اجرا نشوند.
2. پیشگیری از Split-Brain: یکی از مهم‌ترین دلایلی که Docker Swarm از Quorum استفاده می‌کند، جلوگیری از وضعیت Split-Brain است. در این وضعیت، ممکن است نودهایی از کلاستر قادر به برقراری ارتباط با سایر نودها نباشند و تصمیمات مختلفی در هر بخش از کلاستر گرفته شود که این می‌تواند باعث بروز اختلالات جدی در عملکرد و همگامی کلاستر شود. Quorum مانع از وقوع چنین وضعیتی می‌شود.
3. اطمینان از دسترس‌پذیری سرویس‌ها: Quorum همچنین در تعیین تصمیمات مربوط به در دسترس بودن و توزیع سرویس‌ها نقش مهمی ایفا می‌کند. اگر کلاستر نتواند وضعیت صحیح خود را نگه دارد، ممکن است سرویس‌ها از دسترس خارج شوند یا به طور اشتباه در نودهای مختلف توزیع شوند. این مشکل به ویژه در محیط‌های تولیدی که به در دسترس بودن ۲۴/۷ سرویس‌ها نیاز دارند، می‌تواند بسیار جدی باشد.

---

نحوه محاسبه Quorum

در یک کلاستر Docker Swarm، حداقل تعداد نودهای Manager برای حفظ Quorum به این صورت محاسبه می‌شود:

• اگر تعداد نودهای Manager کلاستر شما n باشد، برای اینکه کلاستر بتواند به‌درستی عمل کند و تصمیمات لازم را بگیرد، حداقل باید (n / 2) + 1 نود Manager آنلاین و در دسترس باشند تا بتوانند تصمیمات جمعی و هماهنگ بگیرند.

به عنوان مثال:

• در کلاستری با ۳ نود Manager، برای حفظ Quorum، حداقل ۲ نود Manager باید در دسترس باشند.
• در کلاستری با ۵ نود Manager، حداقل ۳ نود باید در دسترس باشند.
• در کلاستری با ۷ نود Manager، حداقل ۴ نود باید آنلاین و در دسترس باشند.

---

چگونه Quorum در کلاسترهای Swarm اعمال می‌شود؟

در کلاستر Docker Swarm، اگر تعداد نودهای Manager که از کلاستر خارج شده‌اند، به حد نصاب Quorum نرسد، کلاستر وارد وضعیت متوقف می‌شود و شما نمی‌توانید تغییرات جدیدی در کلاستر اعمال کنید. به طور خاص، دو سناریو می‌تواند رخ دهد:

1. کاهش تعداد نودهای Manager از حد Quorum: اگر تعداد نودهای Manager به حد Quorum برسد یا از آن پایین‌تر بیاید، کلاستر نمی‌تواند تصمیمات جدیدی بگیرد. در این صورت، شما نمی‌توانید سرویس‌ها را به‌روز کنید یا سایر تغییرات مهم را در کلاستر اعمال کنید. Docker Swarm برای جلوگیری از خطاهای احتمالی از ایجاد تغییرات در این وضعیت خودداری می‌کند.
2. افزایش تعداد نودهای Manager از حد Quorum: در صورتی که به طور تصادفی تعداد نودهای Manager در کلاستر زیاد شود (یعنی تعداد نودهای Manager از حد معمول فراتر رود)، Swarm ممکن است تصمیم بگیرد که از یک الگوریتم خاص برای انتخاب Leader استفاده کند تا تنها تعداد معقولی از نودها بتوانند در تصمیم‌گیری‌ها مشارکت داشته باشند. در غیر این صورت، این ممکن است منجر به تداخل در تصمیم‌گیری‌ها و افزایش احتمال مشکلات شبکه شود.

---

چگونه می‌توان وضعیت Quorum را بررسی کرد؟

برای بررسی وضعیت Quorum و تعداد نودهای Manager فعال در کلاستر، می‌توانید از دستور docker node ls استفاده کنید. این دستور تمام نودهای موجود در کلاستر را نمایش می‌دهد و نشان می‌دهد که کدام نودها فعال هستند و در حالت Manager یا Worker قرار دارند.

فرمت دستور برای بررسی وضعیت نودها در کلاستر:

docker node ls

این دستور لیستی از نودها را با وضعیت‌های مختلف (مانند Ready, Pending, Down) نمایش می‌دهد. اگر تعداد نودهای Manager کمتر از حد Quorum باشد، Docker Swarm به شما هشدار خواهد داد.

---

جمع‌بندی

Quorum در کلاسترهای Docker Swarm یک مفهوم حیاتی است که به حفظ یکپارچگی و صحت تصمیم‌گیری‌های کلاستر کمک می‌کند. برای اینکه کلاستر بتواند به درستی کار کند و تصمیمات هماهنگ اتخاذ کند، حداقل تعداد مشخصی از نودهای Manager باید در دسترس باشند تا از بروز مشکلاتی مانند Split-Brain جلوگیری شود. با آگاهی از نحوه محاسبه Quorum و نحوه مدیریت آن، می‌توانید اطمینان حاصل کنید که کلاستر شما پایدار و قابل اعتماد است، به‌ویژه در محیط‌های تولیدی که به در دسترس بودن ۲۴/۷ سرویس‌ها نیاز دارند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نحوه عملکرد Quorum در حفظ پایداری و امنیت کلاستر” subtitle=”توضیحات کامل”]در کلاسترهای Docker Swarm، کوروم یک مکانیزم حیاتی است که به حفظ پایداری، هماهنگی و امنیت کلاستر کمک می‌کند. مفهوم Quorum برای جلوگیری از Split-Brain (وضعیتی که در آن نودهای کلاستر به طور جداگانه تصمیم‌گیری کنند و نتایج متناقضی ایجاد شود) طراحی شده است و به طور کلی، برای تصمیم‌گیری‌های کلیدی در کلاستر ضروری است. در این بخش، به طور دقیق‌تر بررسی خواهیم کرد که Quorum چگونه در حفظ پایداری و امنیت کلاسترهای Docker Swarm تأثیر می‌گذارد.

---

پایداری کلاستر و جلوگیری از Split-Brain

یکی از مهم‌ترین جنبه‌های Quorum این است که با اعمال آن، کلاستر به طور مداوم و دقیق می‌تواند وضعیت خود را کنترل کند و از وقوع Split-Brain جلوگیری نماید. Split-Brain یک وضعیت غیرمطلوب است که در آن دو یا چند بخش از کلاستر به طور مستقل از یکدیگر تصمیم‌گیری می‌کنند، بدون آنکه یک هماهنگی کلی میان بخش‌های مختلف وجود داشته باشد.

مفهوم Split-Brain زمانی بروز می‌کند که نودهای مختلف از کلاستر قادر به برقراری ارتباط صحیح با یکدیگر نباشند (برای مثال، به دلیل خرابی در شبکه یا کاهش تعداد نودهای Manager). در چنین شرایطی، ممکن است دو بخش مختلف از کلاستر به طور جداگانه تصمیماتی برای توزیع سرویس‌ها، اجرای کانتینرها، یا سایر عملیات‌های مهم اتخاذ کنند که این تصمیمات ممکن است با یکدیگر در تضاد باشند و منجر به بروز مشکلات شدید در عملکرد کلاستر شوند.

Quorum برای جلوگیری از این وضعیت ضروری است، زیرا به طور خودکار اطمینان می‌دهد که فقط یک بخش از کلاستر (با حداقل تعداد نودهای Manager آنلاین) تصمیمات کلیدی را اتخاذ می‌کند. هنگامی که تعداد نودهای Manager از حد Quorum پایین‌تر می‌آید، Docker Swarm قادر به اتخاذ تصمیمات جدید نخواهد بود و این به جلوگیری از خطر Split-Brain کمک می‌کند.

---

چگونگی جلوگیری از Split-Brain با استفاده از Quorum

در Docker Swarm، حد نصاب Quorum به این صورت تنظیم می‌شود که در کلاسترهای با تعداد نودهای Manager n، حداقل باید (n / 2) + 1 نود Manager آنلاین و در دسترس باشند تا بتوانند تصمیمات صحیح و هماهنگ اتخاذ کنند. این حداقل تعداد نودها اجازه می‌دهد که تصمیم‌گیری در کلاستر به صورت متمرکز و هماهنگ صورت گیرد.

برای مثال:

• اگر کلاستر شما شامل ۳ نود Manager است، حداقل ۲ نود باید آنلاین باشند تا Quorum حفظ شود.
• اگر کلاستر شما شامل ۵ نود Manager است، حداقل ۳ نود باید آنلاین باشند.
• در یک کلاستر با ۷ نود Manager، حداقل ۴ نود باید آنلاین باشند.

در صورتی که تعداد نودهای Manager به حداقل لازم نرسد، Docker Swarm اجازه نمی‌دهد که تغییرات جدیدی در کلاستر انجام شود. این امر باعث می‌شود که کلاستر در وضعیت “غیرفعال” قرار گیرد و از انجام عملیات‌های مختلف مانند به‌روزرسانی سرویس‌ها، مدیریت کانتینرها یا تغییرات پیکربندی جلوگیری می‌شود. این کار به طور غیرمستقیم از بروز Split-Brain جلوگیری می‌کند، زیرا در صورت پایین آمدن تعداد نودهای Manager، کلاستر به طور خودکار نمی‌تواند تصمیمات متناقضی بگیرد.

---

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

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

نکته مهم این است که در صورتی که نودهای Manager زیادی از دسترس خارج شوند و تعداد نودهای آنلاین به زیر حد نصاب Quorum برسد، کلاستر وارد وضعیت ناکارآمد می‌شود و نمی‌تواند تغییرات جدیدی اعمال کند یا سرویس‌ها را مدیریت کند. این وضعیت ممکن است موقتی باشد و به محض بازگشت نودهای از دست رفته به کلاستر، پایداری آن بازگردد.

---

حفظ امنیت کلاستر با Quorum

یکی از جنبه‌های مهم دیگری که Quorum در کلاسترهای Docker Swarm تضمین می‌کند، حفظ امنیت کلاستر است. اگر کلاستر بدون محدودیت در توانایی تصمیم‌گیری ادامه دهد و بدون در نظر گرفتن حداقل تعداد نودهای Manager، تغییرات اعمال شود، احتمال وقوع حملات به کلاستر یا تصمیمات نادرست افزایش می‌یابد.

Quorum به امنیت کلاستر کمک می‌کند زیرا:

• کنترل دسترسی: تنها زمانی که تعداد کافی از نودهای Manager در دسترس باشد، کلاستر قادر به پذیرش تغییرات و تصمیم‌گیری‌های مهم خواهد بود. این مکانیزم باعث می‌شود که تغییرات نادرست یا حملات به کلاستر از طریق نودهای منفرد غیرمجاز تأثیرگذار نباشد.
• اعتماد به تصمیمات جمعی: در شرایطی که تعداد نودهای Manager به اندازه کافی بالا باشد، تصمیمات به صورت جمعی و با توافق اکثریت اتخاذ می‌شود. این امر از خطر تصمیم‌گیری‌های اشتباه یا مخرب جلوگیری می‌کند.
• حفظ یکپارچگی سیستم: با محدود کردن تغییرات در زمانی که Quorum موجود نیست، Docker Swarm از وقوع مشکلات احتمالی که ممکن است ناشی از تصمیمات غیرقانونی یا مخرب باشد، جلوگیری می‌کند. به این ترتیب، یکپارچگی سیستم حفظ می‌شود.

---

جمع‌بندی

Quorum یکی از اصول کلیدی در حفظ پایداری و امنیت کلاسترهای Docker Swarm است. این مکانیزم از وقوع مشکلاتی مانند Split-Brain جلوگیری می‌کند و اطمینان می‌دهد که فقط زمانی تغییرات در کلاستر اعمال می‌شود که تعداد کافی نودهای Manager آنلاین و در دسترس باشند. با استفاده از Quorum، Docker Swarm قادر است از پایداری کلاستر حتی در شرایط خرابی و کاهش تعداد نودهای Manager حفاظت کند. همچنین، این مکانیزم به حفظ امنیت کلاستر نیز کمک می‌کند، زیرا تنها تصمیمات جمعی و هماهنگ از سوی نودهای معتبر اتخاذ می‌شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مدیریت نودهای Swarm به منظور جلوگیری از از دست دادن Quorum” subtitle=”توضیحات کامل”]در یک کلاستر Docker Swarm، مدیریت صحیح نودها یکی از جنبه‌های حیاتی برای حفظ پایداری و جلوگیری از از دست دادن Quorum است. همانطور که پیشتر توضیح داده شد، Quorum به حداقل تعداد نودهای Manager در کلاستر گفته می‌شود که باید در دسترس باشند تا کلاستر به طور صحیح و هماهنگ عمل کند. هنگامی که تعداد نودهای Manager به حداقل مورد نیاز برای دستیابی به Quorum نرسد، عملیات‌های کلاستر متوقف می‌شود و کلاستر وارد وضعیت ناپایدار می‌شود که می‌تواند مشکلات جدی به همراه داشته باشد.

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

---

درک Quorum و اهمیت آن در مدیریت نودها

برای اینکه یک کلاستر Docker Swarm عملکرد صحیح خود را حفظ کند، حداقل تعداد نودهای Manager باید در دسترس باشد. این نودها مسئول تصمیم‌گیری‌های مهم در کلاستر هستند، مانند مدیریت سرویس‌ها، مقیاس‌پذیری، و استقرار تغییرات. Quorum به این معنا است که برای انجام هرگونه عملیات مدیریتی، حداقل نصف به علاوه یک نود از نودهای Manager باید آنلاین باشند. به این ترتیب، اگر تعداد نودهای Manager کمتر از حد نصاب Quorum باشد، کلاستر قادر به انجام عملیات جدید نخواهد بود.

برای مثال:

• در یک کلاستر با ۳ نود Manager، حداقل ۲ نود باید آنلاین باشند تا Quorum حفظ شود.
• در یک کلاستر با ۵ نود Manager، حداقل ۳ نود باید آنلاین باشند.
• در یک کلاستر با ۷ نود Manager، حداقل ۴ نود باید آنلاین باشند.

هنگامی که تعداد نودهای Manager به کمتر از حد Quorum برسد، تغییرات جدیدی نمی‌توانند در کلاستر اعمال شوند و در نتیجه کلاستر وارد وضعیت غیرقابل اعتماد و ناپایدار می‌شود. این وضعیت می‌تواند بر پایداری و کارایی سیستم تأثیر منفی بگذارد.

---

نحوه مدیریت نودهای Swarm برای جلوگیری از از دست دادن Quorum

برای جلوگیری از از دست دادن Quorum، باید نودهای Manager به درستی مدیریت شوند. در اینجا چند راهکار برای مدیریت نودهای کلاستر Swarm آورده شده است:

1. پیکربندی تعداد کافی نودهای Manager: اولین گام برای جلوگیری از از دست دادن Quorum، پیکربندی تعداد مناسب نودهای Manager است. به طور معمول، باید تعداد نودهای Manager در کلاستر به گونه‌ای باشد که حتی در صورت خرابی تعدادی از نودها، همچنان Quorum حفظ شود. برای مثال، در یک کلاستر با تعداد ۳ نود Manager، اگر یکی از نودها از دسترس خارج شود، Quorum همچنان حفظ می‌شود.در صورتی که به دلیل افزایش مقیاس کلاستر نیاز به نودهای بیشتری دارید، می‌توانید تعداد نودهای Manager را افزایش دهید. برای افزودن نود Manager به کلاستر از دستور زیر استفاده کنید:

   docker swarm join --token <manager-token> <manager-ip>:<manager-port>
   

   با این کار، نود جدید به عنوان یک نود Manager به کلاستر اضافه خواهد شد و Quorum کلاستر افزایش خواهد یافت.

2. نظارت مستمر بر وضعیت نودها: برای جلوگیری از از دست دادن Quorum، باید وضعیت نودهای کلاستر را به طور مستمر نظارت کرد. از دست رفتن ارتباط با یک یا چند نود Manager می‌تواند منجر به کاهش تعداد نودهای آنلاین و در نتیجه از دست دادن Quorum شود.با استفاده از دستورات زیر می‌توانید وضعیت نودها را مشاهده کنید:
   • برای مشاهده وضعیت کلی نودها در کلاستر:

     docker node ls
     

   • برای مشاهده جزئیات بیشتر و وضعیت نودها:

     docker node inspect <node-id>
     

   در این دستورات، می‌توانید وضعیت هر نود را بررسی کنید و در صورتی که مشکلی وجود داشت، اقدام به رفع آن کنید.

3. استفاده از چندین نود Manager در مناطق مختلف: برای بهبود پایداری و کاهش خطر از دست دادن Quorum، می‌توانید نودهای Manager را در مناطق جغرافیایی مختلف توزیع کنید. این کار می‌تواند در برابر خرابی‌های سخت‌افزاری یا مشکلات شبکه که ممکن است باعث از دست رفتن ارتباط با نودهای خاص شود، مقاومت بیشتری فراهم کند.به عنوان مثال، اگر نودهای Manager در یک دیتاسنتر قرار داشته باشند و این دیتاسنتر دچار مشکلاتی شود، ممکن است تمام نودهای Manager از دسترس خارج شوند و در نتیجه Quorum از بین برود. اما اگر نودهای Manager در دیتاسنترهای مختلف پخش شوند، احتمال از دست دادن Quorum کاهش می‌یابد.
4. استفاده از خودکارسازی برای بازسازی نودهای از دست رفته: استفاده از سیستم‌های خودکار برای بازسازی نودهای از دست رفته می‌تواند کمک کند تا Quorum حفظ شود. برای مثال، اگر یک نود Manager از دسترس خارج شود، می‌توان از طریق سیستم‌های مدیریت زیرساخت (مانند Ansible یا Terraform) نود جدیدی را به کلاستر اضافه کرد تا Quorum حفظ شود.برای بازسازی خودکار نودها می‌توانید از Docker Swarm به همراه ابزارهای مدیریت زیرساخت استفاده کنید تا در صورت خرابی نودهای Manager، یک نود جدید به طور خودکار به کلاستر اضافه شود.
5. پیکربندی صحیح فایروال و شبکه‌ها: برای جلوگیری از از دست دادن ارتباط بین نودهای کلاستر که ممکن است منجر به از دست رفتن Quorum شود، لازم است که فایروال‌ها و شبکه‌های کلاستر به درستی پیکربندی شوند. از آنجایی که در Docker Swarm، نودها برای ارتباط با یکدیگر نیاز به پورت‌های خاصی دارند، باید مطمئن شوید که این پورت‌ها برای تمام نودها باز و قابل دسترس هستند.برخی از پورت‌های اصلی مورد نیاز برای کلاستر Docker Swarm عبارتند از:
   • پورت 2377 برای مدیریت کلاستر.
   • پورت 7946 برای ارتباط بین نودها.
   • پورت 4789 برای ارتباط Overlay Network.

   با پیکربندی صحیح این پورت‌ها، از قطعی‌های شبکه که ممکن است باعث قطع ارتباط میان نودهای Manager شوند جلوگیری کنید.

---

چالش‌ها و راهکارها

1. چالش خرابی نودهای Manager: خرابی یک یا چند نود Manager می‌تواند به سرعت منجر به از دست رفتن Quorum شود. برای مقابله با این چالش، باید تعداد نودهای Manager کافی داشته باشید و آن‌ها را در مناطق مختلف پخش کنید.
2. چالش‌های شبکه و ارتباطی: مشکلات شبکه می‌توانند موجب قطع ارتباط میان نودها شوند. برای جلوگیری از این مشکل، باید شبکه‌های Docker را به درستی پیکربندی کرده و از ابزارهای نظارتی برای مانیتور کردن وضعیت شبکه استفاده کنید.
3. چالش‌های منابع و مقیاس‌پذیری: در صورتی که تعداد نودهای Manager در کلاستر افزایش یابد، منابع سرور باید به اندازه کافی مقیاس‌پذیر باشند تا عملکرد کلاستر تحت بار زیاد حفظ شود. برای این منظور می‌توانید از سیستم‌های خودکار مقیاس‌پذیری مانند Kubernetes یا استفاده از ابزارهایی برای تخصیص منابع استفاده کنید.

---

جمع‌بندی

مدیریت نودهای کلاستر Docker Swarm برای جلوگیری از از دست دادن Quorum امری حیاتی است. با استفاده از تکنیک‌های مختلفی مانند پیکربندی تعداد کافی نودهای Manager، نظارت مستمر بر وضعیت نودها، توزیع نودها در مناطق مختلف، استفاده از خودکارسازی برای بازسازی نودهای از دست رفته و پیکربندی صحیح فایروال و شبکه‌ها، می‌توان از از دست رفتن Quorum جلوگیری کرد و پایداری و امنیت کلاستر را حفظ کرد. این اقدامات به طور قابل توجهی موجب می‌شود که کلاستر در برابر خرابی‌ها و مشکلات مختلف مقاوم‌تر شود و از بروز مشکلات جدی جلوگیری گردد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تنظیم تعداد نودهای Manager برای حفظ تعادل و کارایی کلاستر” subtitle=”توضیحات کامل”]یکی از جنبه‌های کلیدی در پیکربندی یک کلاستر Docker Swarm، تنظیم تعداد نودهای Manager است. نودهای Manager مسئول اجرای دستورات مدیریتی و هماهنگی فعالیت‌های دیگر نودها (که نودهای Worker نامیده می‌شوند) هستند. در این بخش، به بررسی نحوه تنظیم تعداد نودهای Manager و تأثیر آن بر عملکرد و کارایی کلاستر می‌پردازیم.

---

نقش نودهای Manager در Docker Swarm

نودهای Manager در کلاستر Docker Swarm وظایف حیاتی و مهمی را بر عهده دارند که شامل موارد زیر می‌شود:

1. مدیریت و هماهنگی سرویس‌ها: نودهای Manager مسئول تصمیم‌گیری‌های مدیریتی مانند راه‌اندازی سرویس‌ها، نظارت بر وضعیت آن‌ها و انجام عملیات‌های مقیاس‌پذیری هستند.
2. تعامل با API Docker: نودهای Manager درخواست‌های API Docker را پردازش کرده و تغییرات در کلاستر را اعمال می‌کنند.
3. حفظ Quorum: نودهای Manager باید به گونه‌ای تنظیم شوند که حداقل تعداد آن‌ها در دسترس باشد تا مفهوم Quorum حفظ شود. بدون Quorum، کلاستر قادر به انجام عملیات مدیریتی نخواهد بود.
4. نگهداری داده‌های Swarm: نودهای Manager داده‌ها و وضعیت کلاستر را در یک پایگاه داده توزیع‌شده (Raft) ذخیره می‌کنند که برای مدیریت وضعیت و هماهنگی فعالیت‌ها ضروری است.

---

چرا تعداد نودهای Manager مهم است؟

تعداد نودهای Manager تأثیر زیادی بر عملکرد، مقیاس‌پذیری و پایداری کلاستر دارد. انتخاب تعداد مناسب نودهای Manager بستگی به چند عامل دارد که در ادامه بررسی می‌کنیم.

1. حفظ Quorum: برای حفظ Quorum در کلاستر، تعداد نودهای Manager باید به گونه‌ای تنظیم شود که حتی در صورت از دست دادن یک یا چند نود، هنوز هم امکان ادامه عملیات در کلاستر وجود داشته باشد. همانطور که قبلاً توضیح داده شد، برای داشتن Quorum باید حداقل نصف به علاوه یک نود از نودهای Manager آنلاین باشند.
   • اگر تعداد نودهای Manager بیش از حد باشد، ممکن است منجر به ترافیک زیاد در کلاستر و کاهش عملکرد شود.
   • اگر تعداد نودهای Manager کمتر از حد نیاز باشد، ممکن است Quorum از دست برود و این باعث قطع فعالیت‌های مدیریتی و توقف عملیات‌های کلاستر خواهد شد.
2. افزایش کارایی و مقیاس‌پذیری: تعداد نودهای Manager در کلاستر به‌طور مستقیم بر عملکرد و کارایی آن تأثیر دارد. با افزایش تعداد نودهای Manager، بار مدیریتی بین نودها توزیع می‌شود و این می‌تواند به کاهش فشار روی هر نود و بهبود مقیاس‌پذیری کلاستر منجر شود. اما باید توجه داشت که افزایش بیش از حد تعداد نودهای Manager نیز می‌تواند باعث افزایش هزینه‌ها و پیچیدگی در مدیریت کلاستر شود.
3. پایداری کلاستر: اگر تعداد نودهای Manager به اندازه کافی تنظیم نشده باشد، خرابی یک یا چند نود می‌تواند منجر به از دست رفتن Quorum و در نتیجه ایجاد ناپایداری در کلاستر شود. تنظیم تعداد مناسب نودهای Manager به گونه‌ای که بتواند در برابر خرابی‌ها مقاوم باشد، از اهمیت بالایی برخوردار است.

---

چگونه تعداد نودهای Manager را برای کلاستر Swarm تنظیم کنیم؟

در Docker Swarm، شما می‌توانید تعداد نودهای Manager را به راحتی تغییر دهید. ابتدا باید تعداد نودهای Manager مورد نیاز خود را بررسی کرده و سپس آن‌ها را به کلاستر اضافه یا از آن حذف کنید.

1. افزودن نود Manager به کلاستر: برای افزودن یک نود جدید به کلاستر به عنوان نود Manager، باید از دستور docker swarm join استفاده کنید. ابتدا باید توکن مخصوص Manager را از یکی از نودهای Manager موجود استخراج کنید و سپس نود جدید را به کلاستر اضافه کنید.گام 1: استخراج توکن Manager از یکی از نودهای Manager موجود:

   docker swarm join-token manager
   

   گام 2: در نود جدید، دستور زیر را اجرا کنید تا به کلاستر پیوسته و به عنوان نود Manager اضافه شود:

   docker swarm join --token <manager-token> <manager-ip>:2377
   

2. حذف نود Manager از کلاستر: برای حذف نود Manager از کلاستر، از دستور docker node demote استفاده می‌کنیم. این دستور باعث می‌شود که نود به یک نود Worker تبدیل شود و دیگر به عنوان نود Manager شناخته نشود.برای حذف نود Manager از کلاستر، دستور زیر را اجرا کنید:

   docker node demote <node-id>
   

   نکته: این دستور تنها نودهایی را که به عنوان Manager هستند از این وضعیت خارج می‌کند و به عنوان نود Worker در می‌آورد. اگر نود به طور کامل از کلاستر حذف شود، از دستور docker node rm <node-id> برای حذف آن استفاده کنید.

3. تعداد نودهای Manager ایده‌آل: برای داشتن یک کلاستر پایدار و کارا، تعداد نودهای Manager باید فرد باشد تا همیشه یک Quorum برای تصمیم‌گیری وجود داشته باشد. تعداد نودهای Manager باید به گونه‌ای انتخاب شود که در صورت خرابی نود، Quorum حفظ شود.
   • برای کلاسترهای کوچک (حدود ۳ تا ۵ نود)، توصیه می‌شود ۳ یا ۵ نود Manager در نظر گرفته شود.
   • برای کلاسترهای بزرگتر با تعداد بیشتری نود، می‌توان تعداد نودهای Manager را به ۷ یا ۹ نود افزایش داد.
   • به طور معمول، تعداد نودهای Manager نباید از ۹ نود بیشتر باشد، زیرا هر چه تعداد نودهای Manager بیشتر شود، تأثیر منفی روی عملکرد کلاستر و تأخیر در عملیات‌ها خواهد داشت.

---

تأثیر تعداد نودهای Manager بر پایداری و کارایی

1. کلاستر با ۳ نود Manager:
   • مزایا: کمترین هزینه برای راه‌اندازی و نگهداری، ساده‌ترین پیکربندی.
   • معایب: در صورت از دست رفتن یکی از نودهای Manager، Quorum از دست خواهد رفت.

   در این حالت، اگر یک نود Manager از دست برود، کلاستر همچنان به کار خود ادامه خواهد داد، اما اگر دو نود Manager از دست بروند، کلاستر وارد وضعیت غیرقابل اطمینان می‌شود.

2. کلاستر با ۵ نود Manager:
   • مزایا: کاهش احتمال از دست رفتن Quorum، افزایش پایداری.
   • معایب: هزینه بیشتر و پیچیدگی بیشتر در مدیریت کلاستر.

   در این حالت، کلاستر قادر است از دست دادن دو نود Manager را تحمل کند و همچنان قادر به انجام عملیات مدیریتی باشد.

3. کلاستر با ۷ یا ۹ نود Manager:
   • مزایا: پایداری بسیار بالا، امکان تحمل خرابی بیشتر.
   • معایب: هزینه‌های بالاتر، تأخیر بیشتر در هماهنگی و عملکرد.

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

---

جمع‌بندی

تنظیم تعداد نودهای Manager در Docker Swarm یکی از جنبه‌های حیاتی برای حفظ تعادل و کارایی کلاستر است. انتخاب تعداد مناسب نودهای Manager باید به گونه‌ای باشد که علاوه بر حفظ Quorum، عملکرد کلاستر را بهبود بخشد و هزینه‌ها و پیچیدگی مدیریت را کنترل کند. با توجه به اندازه و نیازهای کلاستر، باید تعداد نودهای Manager به درستی پیکربندی شود تا کلاستر در برابر خرابی‌ها مقاوم و عملکردی پایدار داشته باشد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. عملیات‌های Rolling Updates و Rollbacks”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نحوه پیاده‌سازی Rolling Updates برای سرویس‌ها” subtitle=”توضیحات کامل”]یکی از ویژگی‌های برجسته Docker Swarm قابلیت Rolling Update است که به شما اجازه می‌دهد تا سرویس‌های خود را به‌طور تدریجی و بدون وقفه به‌روز کنید. این ویژگی به‌ویژه در محیط‌های تولیدی حیاتی است، زیرا به‌روزرسانی‌های نرم‌افزاری باید به گونه‌ای انجام شوند که تأثیری بر عملکرد کلی سیستم نداشته باشند. در این بخش، نحوه پیاده‌سازی Rolling Updates برای سرویس‌ها در Docker Swarm را به تفصیل توضیح خواهیم داد.

---

مفهوم Rolling Update

Rolling Update یک استراتژی برای به‌روزرسانی سرویس‌ها به‌صورت تدریجی است. در این روش، Docker Swarm به‌طور خودکار تعدادی از کانتینرهای سرویس را به‌روز کرده و در عین حال اطمینان حاصل می‌کند که تعداد کافی از کانتینرهای قدیمی برای ارائه سرویس در دسترس باقی بمانند. به این ترتیب، هیچ‌گونه قطعی یا اختلالی در سرویس‌دهی به کاربران ایجاد نمی‌شود.

Rolling Update به‌ویژه در مواقعی که نیاز به بروزرسانی‌های بدون توقف برای سرویس‌های مقیاس‌پذیر داریم، مفید است. برای مثال، زمانی که نسخه جدید یک اپلیکیشن منتشر می‌شود و باید به‌طور تدریجی به‌روز شود تا هیچ یک از کانتینرها از دسترس خارج نشوند.

---

مکانیزم Rolling Update در Docker Swarm

در Docker Swarm، برای اعمال Rolling Update روی سرویس‌ها، از قابلیت‌های داخلی Swarm برای کنترل بروزرسانی استفاده می‌کنیم. این ویژگی به شما این امکان را می‌دهد که تعداد کانتینرهایی که به‌طور همزمان به‌روز می‌شوند را مشخص کنید و حتی شرایط خاصی برای این به‌روزرسانی‌ها تعریف نمایید.

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

---

پیاده‌سازی Rolling Update در Docker Swarm

برای پیاده‌سازی Rolling Update در Docker Swarm، شما باید سرویس خود را به گونه‌ای تنظیم کنید که به‌روزرسانی‌ها به‌طور تدریجی انجام شوند. در ادامه، به بررسی نحوه انجام این کار می‌پردازیم.

1. ایجاد یک سرویس جدید برای پیاده‌سازی Rolling Updateدر ابتدا، باید یک سرویس جدید با استفاده از دستور docker service create ایجاد کنید. برای مثال، یک سرویس از اپلیکیشن Nginx را به‌صورت زیر ایجاد می‌کنیم:

   docker service create --name my_nginx --replicas 3 nginx
   

   در اینجا، سرویس my_nginx با ۳ Replica ایجاد می‌شود که هر یک از آن‌ها یک کانتینر Nginx را اجرا می‌کنند.

2. آغاز Rolling Update برای سرویسهنگامی که نیاز به به‌روزرسانی نسخه اپلیکیشن دارید، می‌توانید از دستور docker service update برای به‌روزرسانی سرویس استفاده کنید. به‌عنوان مثال، اگر بخواهید نسخه جدیدی از تصویر Nginx را به سرویس اضافه کنید، از دستور زیر استفاده می‌کنید:

   docker service update --image nginx:latest my_nginx
   

   این دستور نسخه جدید تصویر Nginx را به سرویس my_nginx اختصاص می‌دهد و به‌طور خودکار شروع به اعمال Rolling Update می‌کند. Swarm به‌طور خودکار تعداد کانتینرهایی را که باید به‌روزرسانی شوند مدیریت کرده و از قطع سرویس‌دهی جلوگیری می‌کند.

---

پیکربندی Rolling Update در Docker Swarm

در هنگام به‌روزرسانی سرویس‌ها در Docker Swarm، می‌توانید رفتار Rolling Update را پیکربندی کنید تا به نیازهای خاص خود برسید. این تنظیمات شامل کنترل تعداد کانتینرهایی است که باید به‌طور همزمان به‌روز شوند و همچنین تنظیم زمان‌بندی برای تأخیر بین به‌روزرسانی‌ها.

1. تنظیم تعداد کانتینرهای همزمان در به‌روزرسانیبا استفاده از گزینه‌های --update-parallelism و --update-delay می‌توانید تعداد کانتینرهایی که به‌طور همزمان به‌روزرسانی می‌شوند را کنترل کنید.
   • --update-parallelism: تعداد کانتینرهایی که به‌طور همزمان به‌روزرسانی می‌شوند را مشخص می‌کند.
   • --update-delay: مدت زمانی که بین به‌روزرسانی هر کانتینر باید صبر کرد را تنظیم می‌کند.

   برای مثال، اگر بخواهید که فقط ۲ کانتینر از ۳ کانتینر به‌طور همزمان به‌روزرسانی شوند و هر ۱۰ ثانیه یکبار یک کانتینر به‌روزرسانی شود، می‌توانید از دستور زیر استفاده کنید:

   docker service update --update-parallelism 2 --update-delay 10s --image nginx:latest my_nginx
   

   این دستور باعث می‌شود که فقط ۲ کانتینر از ۳ کانتینر سرویس به‌طور همزمان به‌روز شوند و بین هر به‌روزرسانی ۱۰ ثانیه تأخیر باشد.

2. تنظیم Rollback در صورت بروز خطایکی از قابلیت‌های جالب دیگر Docker Swarm در هنگام به‌روزرسانی، امکان بازگشت خودکار به نسخه قبلی در صورت بروز مشکل است. اگر در حین Rolling Update مشکلی پیش آید و یک کانتینر جدید نتواند به‌درستی راه‌اندازی شود، Swarm به‌طور خودکار به نسخه قبلی بازگشت می‌کند.

   این ویژگی به شما کمک می‌کند تا از مشکلات احتمالی جلوگیری کرده و از اختلال در سرویس‌دهی جلوگیری کنید.

---

نظارت بر فرآیند Rolling Update

برای نظارت بر وضعیت به‌روزرسانی‌های در حال انجام، می‌توانید از دستور docker service ps استفاده کنید تا وضعیت سرویس‌های در حال به‌روزرسانی را مشاهده کنید.

برای مثال:

docker service ps my_nginx

این دستور وضعیت تمام وظایف (tasks) مرتبط با سرویس my_nginx را نمایش می‌دهد. در صورتی که به‌روزرسانی در حال انجام باشد، در ستون CURRENT STATE وضعیت به‌روزرسانی را مشاهده خواهید کرد.

---

جمع‌بندی

پیاده‌سازی Rolling Update در Docker Swarm به شما این امکان را می‌دهد تا سرویس‌ها را بدون توقف و به‌طور تدریجی به‌روز کنید. این قابلیت به ویژه در محیط‌های تولیدی مفید است، زیرا هیچ‌گونه اختلالی در دسترسی به سرویس‌ها ایجاد نمی‌شود. با استفاده از دستورات مختلف و پیکربندی‌های قابل تنظیم، می‌توانید فرآیند به‌روزرسانی را مطابق با نیازهای خاص خود مدیریت کنید و به این ترتیب از پایداری و کارایی سیستم خود اطمینان حاصل کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مدیریت و مانیتورینگ فرآیند به‌روزرسانی سرویس‌ها” subtitle=”توضیحات کامل”]در یک محیط Docker Swarm، فرآیند به‌روزرسانی سرویس‌ها نقش بسیار مهمی در حفظ عملکرد و پایداری سیستم ایفا می‌کند. به‌روزرسانی‌های بدون وقفه و امن، برای هر سازمانی که قصد دارد سیستم‌های تولیدی خود را مقیاس‌پذیر و بدون نقص نگه دارد، ضروری است. Docker Swarm برای انجام این فرآیند به‌طور مؤثر ویژگی‌های خاصی را فراهم کرده است تا شما بتوانید نه تنها به‌روزرسانی‌ها را انجام دهید، بلکه آن‌ها را مدیریت و نظارت کنید تا از وقوع مشکلات جلوگیری شود.

در این بخش، به نحوه مدیریت و مانیتورینگ فرآیند به‌روزرسانی سرویس‌ها در Docker Swarm پرداخته و ابزارها و تکنیک‌های مورد نیاز را توضیح خواهیم داد.

---

فرآیند به‌روزرسانی سرویس‌ها در Docker Swarm

در Docker Swarm، به‌روزرسانی سرویس‌ها از طریق دستور docker service update انجام می‌شود. این دستور به شما اجازه می‌دهد تا یک یا چند ویژگی سرویس‌های موجود را به‌روزرسانی کنید، از جمله تغییر نسخه تصویر (image) کانتینرها، تنظیمات environment variables، پورت‌ها، و غیره.

یکی از ویژگی‌های کلیدی که Docker Swarm برای به‌روزرسانی سرویس‌ها ارائه می‌دهد، Rolling Update است که در بخش‌های قبلی توضیح دادیم. این روش به‌طور تدریجی و بدون وقفه سرویس‌ها را به‌روز می‌کند و از قطع شدن سرویس جلوگیری می‌کند. با این حال، علاوه بر اعمال به‌روزرسانی، مدیریت و نظارت بر این فرآیند نیز بسیار اهمیت دارد.

---

مدیریت فرآیند به‌روزرسانی سرویس‌ها

برای موفقیت در به‌روزرسانی، مدیریت فرآیند به‌روزرسانی از مهم‌ترین گام‌هاست. در Docker Swarm، این فرآیند می‌تواند شامل موارد زیر باشد:

1. تنظیمات به‌روزرسانی سفارشی:
   • تعداد کانتینرهای همزمان: هنگام به‌روزرسانی، می‌توانید مشخص کنید که چند کانتینر به‌طور همزمان به‌روزرسانی شوند.
   • تأخیر بین به‌روزرسانی‌ها: همچنین می‌توانید تنظیم کنید که بین به‌روزرسانی هر کانتینر چه مقدار تأخیر باید وجود داشته باشد.

   این تنظیمات از طریق گزینه‌های --update-parallelism و --update-delay در دستور docker service update قابل انجام است.

   برای مثال، اگر می‌خواهید ۲ کانتینر از ۵ کانتینر را به‌طور همزمان به‌روز کنید و ۱۵ ثانیه تأخیر بین به‌روزرسانی‌ها وجود داشته باشد، دستور زیر را استفاده می‌کنید:

   docker service update --update-parallelism 2 --update-delay 15s --image nginx:latest my_nginx
   

2. فعال‌سازی قابلیت Rollback: در صورتی که به‌روزرسانی با مشکلی مواجه شود، Swarm به‌طور خودکار به نسخه قبلی برمی‌گردد. شما می‌توانید این ویژگی را از طریق دستور --rollback به‌طور دستی نیز فعال کنید.برای انجام rollback به نسخه قبلی سرویس، می‌توانید از دستور زیر استفاده کنید:

   docker service rollback my_nginx
   

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

---

مانیتورینگ فرآیند به‌روزرسانی سرویس‌ها

پس از اعمال به‌روزرسانی بر روی سرویس‌ها، نظارت بر وضعیت آن‌ها یکی از گام‌های مهم است. Docker Swarm ابزارهایی را فراهم می‌کند که به شما این امکان را می‌دهند تا بررسی کنید که به‌روزرسانی به‌درستی انجام شده است یا خیر و از هر گونه مشکل احتمالی آگاه شوید.

1. مشاهده وضعیت به‌روزرسانی‌ها با docker service ps: این دستور، وضعیت تمامی tasks سرویس‌های در حال اجرا را نمایش می‌دهد و نشان می‌دهد که کدام کانتینرها در حال به‌روزرسانی هستند. همچنین می‌توانید با این دستور زمان‌بندی و وضعیت هر یک از کانتینرها را بررسی کنید.برای مثال، اگر سرویس my_nginx را به‌روزرسانی کرده‌اید، می‌توانید از دستور زیر استفاده کنید تا وضعیت به‌روزرسانی‌ها را مشاهده کنید:

   docker service ps my_nginx
   

   خروجی این دستور شامل جزئیاتی مانند وضعیت هر کانتینر، زمان شروع و پایان و هرگونه خطای موجود خواهد بود.

2. بررسی وضعیت کلی کلاستر با docker info: دستور docker info اطلاعات کاملی از وضعیت کلی Docker Daemon و کلاستر Swarm شما را به نمایش می‌گذارد. این دستور به‌ویژه زمانی که بخواهید وضعیت کلی سیستم و منابع موجود را بررسی کنید، مفید است.برای مثال، دستور زیر را اجرا کنید تا اطلاعات کلی از کلاستر Swarm دریافت کنید:

   docker info
   

   این اطلاعات شامل تعداد نودها، وضعیت کلاستر، تعداد سرویس‌های در حال اجرا و منابع موجود خواهد بود.

3. مشاهده جزئیات عملکرد کانتینرها با docker logs: اگر به‌روزرسانی انجام شده و مشکلی در عملکرد سرویس‌ها به وجود آمد، می‌توانید از دستور docker logs برای مشاهده لاگ‌های مربوط به هر کانتینر استفاده کنید.برای مشاهده لاگ‌ها از یک کانتینر خاص در سرویس my_nginx می‌توانید از دستور زیر استفاده کنید:

   docker logs <container_id>
   

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

4. استفاده از ابزارهای مانیتورینگ خارجی: علاوه بر ابزارهای داخلی Docker، شما می‌توانید از سیستم‌های مانیتورینگ پیشرفته مانند Prometheus، Grafana، یا Datadog برای نظارت دقیق‌تر بر فرآیند به‌روزرسانی استفاده کنید. این ابزارها به شما این امکان را می‌دهند که عملکرد سرویس‌ها و کلاستر را در لحظه مشاهده کرده و هرگونه تغییرات یا مشکلات را به‌سرعت شناسایی کنید.

---

بهترین شیوه‌های مدیریت و مانیتورینگ به‌روزرسانی سرویس‌ها

1. آزمایش در محیط‌های staging: قبل از اعمال به‌روزرسانی در محیط تولید، حتماً تغییرات را در یک محیط staging آزمایش کنید. این کار باعث می‌شود که از بروز مشکلات غیرمنتظره در محیط تولید جلوگیری شود.
2. مستندسازی به‌روزرسانی‌ها: تمام تغییرات و به‌روزرسانی‌ها را مستند کنید. این کار باعث می‌شود که در صورت بروز هرگونه مشکل، تاریخچه دقیق به‌روزرسانی‌ها در دسترس باشد.
3. پیکربندی مناسب تعداد Replica‌ها: برای جلوگیری از هرگونه قطعی، تعداد مناسب Replica‌ها را برای سرویس‌ها پیکربندی کنید. این کار اطمینان می‌دهد که حتی در صورت به‌روزرسانی، تعدادی کانتینر در دسترس باقی می‌مانند.
4. استفاده از قابلیت‌های Auto-Rollback: برای اطمینان از عدم وقوع مشکلات در حین به‌روزرسانی، حتماً از قابلیت Auto-Rollback استفاده کنید. در صورت بروز هرگونه خطا، سرویس به‌طور خودکار به نسخه قبلی باز می‌گردد.

---

جمع‌بندی

مدیریت و مانیتورینگ فرآیند به‌روزرسانی سرویس‌ها در Docker Swarm یک بخش حیاتی از حفظ پایداری و عملکرد کلاستر است. استفاده از ابزارهای مختلف برای نظارت بر وضعیت سرویس‌ها، کنترل به‌روزرسانی‌ها، و پیاده‌سازی بهترین شیوه‌ها در این فرآیند، به شما این امکان را می‌دهد که سرویس‌ها را به‌طور مؤثر و ایمن به‌روز کنید و از مشکلات احتمالی جلوگیری کنید. با انجام صحیح این مراحل، می‌توانید سیستم‌های تولیدی خود را در حین به‌روزرسانی پایدار و در دسترس نگه دارید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بازگرداندن تغییرات (Rollback) در صورت بروز مشکل” subtitle=”توضیحات کامل”]Rollback در Docker Swarm به فرآیندی اطلاق می‌شود که در آن سرویس‌ها یا نودها به نسخه قبلی خود باز می‌گردند در صورتی که تغییرات جدید یا به‌روزرسانی‌های اعمال شده با مشکلی مواجه شوند. این ویژگی در زمانی که به‌روزرسانی‌ها باعث اختلال در عملکرد سرویس‌ها شوند، بسیار حیاتی است و به ادمین‌های سیستم این امکان را می‌دهد که به‌سرعت به وضعیت پایدار و قبلی بازگردند و از بروز مشکلات بیشتر جلوگیری کنند.

بازگرداندن تغییرات به کمک دستور docker service rollback صورت می‌گیرد و با استفاده از این دستور، می‌توانید به سادگی تغییرات و به‌روزرسانی‌هایی که منجر به مشکلات شده‌اند را لغو کنید.

در این بخش، به توضیح نحوه پیاده‌سازی Rollback در Docker Swarm و مدیریت صحیح آن در صورت بروز مشکلات خواهیم پرداخت.

---

فرآیند بازگرداندن تغییرات (Rollback) در Docker Swarm

هنگامی که به‌روزرسانی‌های یک سرویس در Docker Swarm با مشکلاتی مواجه می‌شود، به‌راحتی می‌توان از دستور docker service rollback برای بازگشت به نسخه قبلی سرویس‌ها استفاده کرد. این دستور به‌طور خودکار نسخه قبلی سرویس را به وضعیت اولیه باز می‌گرداند و فرآیند به‌روزرسانی جدید لغو می‌شود.

---

نحوه اجرای Rollback بر روی سرویس‌ها

برای بازگرداندن یک سرویس به نسخه قبلی خود، کافی است از دستور docker service rollback استفاده کنید. این دستور به‌طور خودکار نسخه قبلی سرویس را که آخرین بار موفقیت‌آمیز به‌روزرسانی شده است، به حالت اجرا برمی‌گرداند.

1. دستور بازگرداندن تغییرات برای یک سرویس خاص:برای بازگرداندن به‌روزرسانی‌ها در سرویس my_nginx، دستور زیر را وارد کنید:

   docker service rollback my_nginx
   

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

2. مشاهده وضعیت سرویس پس از Rollback:پس از اجرای دستور rollback، می‌توانید با استفاده از دستور docker service ps وضعیت سرویس را بررسی کنید و مطمئن شوید که سرویس به‌طور صحیح به نسخه قبلی خود برگشته است. دستور زیر این وضعیت را نمایش می‌دهد:

   docker service ps my_nginx
   

   این دستور فهرستی از tasks (وظایف) در سرویس شما را نشان می‌دهد و مشخص می‌کند که کدام کانتینرها در حال اجرا هستند و کدام یک از آن‌ها به نسخه قبلی بازگشته‌اند.

3. بازگشت به یک نسخه خاص از سرویس:در صورتی که بخواهید به نسخه‌ای خاص از یک سرویس بازگردید، می‌توانید از گزینه --revision برای مشخص کردن نسخه خاص استفاده کنید. برای مثال، اگر می‌خواهید سرویس my_nginx را به نسخه ۳ آن بازگردانید، دستور زیر را وارد کنید:

   docker service rollback --revision 3 my_nginx
   

---

چگونگی مدیریت و نظارت بر Rollback

اجرای Rollback یک فرآیند مهم است که باید با دقت مدیریت و نظارت شود. در صورتی که به‌روزرسانی با مشکل مواجه شود و نیاز به بازگشت به نسخه قبلی وجود داشته باشد، مراحل زیر می‌تواند کمک کند تا این فرآیند به‌درستی انجام شود و تأثیری بر پایداری سرویس نگذارد.

1. نظارت بر وضعیت به‌روزرسانی‌ها:قبل از انجام Rollback، بررسی وضعیت سرویس‌ها می‌تواند به شما کمک کند تا مطمئن شوید که مشکل دقیقاً از کجا ناشی شده است. برای این منظور، دستور docker service ps را به‌طور مرتب اجرا کنید و وضعیت سرویس‌ها را نظارت کنید.

   docker service ps my_nginx
   

   خروجی این دستور اطلاعاتی در مورد وضعیت هر کانتینر از سرویس شما ارائه می‌دهد، از جمله کانتینرهایی که در حال به‌روزرسانی هستند و هرگونه خطای احتمالی.

2. دستور docker logs برای بررسی مشکلات:اگر در حین به‌روزرسانی مشکلی رخ دهد، می‌توانید از دستور docker logs برای مشاهده لاگ‌های سرویس استفاده کنید تا علت بروز مشکل مشخص شود. برای مثال:

   docker logs <container_id>
   

   این دستور لاگ‌های مربوط به یک کانتینر خاص را نشان می‌دهد که می‌تواند به شناسایی مشکلات کمک کند.

3. مستندسازی و پیگیری تغییرات:توصیه می‌شود که هرگونه تغییرات و به‌روزرسانی‌ها در سرویس‌ها را مستند کنید تا در صورت بروز مشکل و نیاز به Rollback، تاریخچه دقیق تغییرات در دسترس باشد. این کار به شما کمک می‌کند که روند به‌روزرسانی‌ها را پیگیری کنید و در صورت نیاز به بازگشت به یک نسخه قبلی، بتوانید با سرعت بیشتری عمل کنید.

---

چرا Rollback مهم است؟

Rollback ابزاری ضروری در Docker Swarm است زیرا این امکان را به شما می‌دهد که در مواقع بروز مشکلات، سرویس‌ها و سیستم‌های خود را به سرعت به وضعیت پایدار و قبلی بازگردانید. اهمیت این ویژگی در موارد زیر آشکار می‌شود:

1. پایداری و امنیت: در صورتی که به‌روزرسانی به‌دلیل مشکلات ناشناخته باعث اختلال در سرویس‌ها شود، Rollback به‌سرعت پایداری سیستم را باز می‌گرداند و از مشکلات بیشتر جلوگیری می‌کند.
2. کاهش زمان توقف سرویس‌ها: بازگرداندن سریع سرویس‌ها به نسخه قبلی باعث می‌شود که downtime (زمان قطعی سرویس) کاهش یابد و سیستم‌های حیاتی همیشه در دسترس باقی بمانند.
3. اطمینان از عدم تداخل با سایر سرویس‌ها: Rollback باعث می‌شود که به‌روزرسانی‌های اشتباه یا معیوب نتوانند بر روی سایر سرویس‌های کلاستر تأثیر بگذارند و سیستم به‌طور کلی در حالت کارایی مطلوب باقی بماند.

---

جمع‌بندی

Rollback در Docker Swarm ابزاری قدرتمند و ضروری است که به شما این امکان را می‌دهد تا در صورت بروز هرگونه مشکل در حین به‌روزرسانی سرویس‌ها، تغییرات را لغو کرده و به نسخه قبلی سرویس‌ها بازگردید. این فرآیند با استفاده از دستور docker service rollback قابل انجام است و به‌راحتی می‌توانید سرویس‌های خود را به وضعیت پایدار برگردانید. مدیریت دقیق فرآیندهای به‌روزرسانی، نظارت بر وضعیت سرویس‌ها، و استفاده از Rollback در صورت نیاز، از نکات کلیدی برای حفظ پایداری و کارایی در Docker Swarm هستند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تنظیم مقادیر Parallelism و Update Delay برای کنترل بهتر در Rolling Updates” subtitle=”توضیحات کامل”]Rolling Updates در Docker Swarm به فرآیند به‌روزرسانی تدریجی سرویس‌ها اشاره دارد که در آن به‌جای توقف کل سرویس و اجرای به‌روزرسانی در یک زمان، تغییرات به‌صورت تدریجی در نودها و کانتینرها اعمال می‌شود. این فرآیند به ما کمک می‌کند که سرویس‌ها همیشه در دسترس باشند و میزان downtime (زمان قطعی) در حین به‌روزرسانی به حداقل برسد.

با استفاده از مقادیر Parallelism و Update Delay می‌توانیم نحوه اجرای Rolling Updates را دقیق‌تر و با دقت بیشتری کنترل کنیم. این دو تنظیم به شما اجازه می‌دهند که به‌روزرسانی‌ها را مطابق با نیازهای خود بهینه کنید و اطمینان حاصل کنید که هیچ‌کدام از نودهای شما در طول فرآیند به‌روزرسانی تحت فشار بیش از حد قرار نخواهند گرفت.

---

مفهوم Parallelism و Update Delay

1. Parallelism:
   • Parallelism به تعداد کانتینرهایی که می‌توانند به‌صورت همزمان (parallel) به‌روزرسانی شوند، اشاره دارد.
   • به‌طور پیش‌فرض، Docker Swarm تعداد کانتینرهایی که به‌صورت همزمان به‌روزرسانی می‌شوند را به اندازه‌ای معقول تنظیم می‌کند تا تاثیرات منفی بر عملکرد سیستم نداشته باشد.
   • شما می‌توانید این مقدار را تنظیم کنید تا تعداد کانتینرهای بیشتری به‌طور همزمان به‌روزرسانی شوند یا بالعکس، آن را کاهش دهید تا از بار زیاد بر روی نودها جلوگیری کنید.
2. Update Delay:
   • Update Delay به مدت زمانی اشاره دارد که بین به‌روزرسانی‌های هر کانتینر وجود دارد.
   • به عبارت دیگر، بعد از به‌روزرسانی یک کانتینر، Docker Swarm تا زمانی که وضعیت آن کانتینر به‌طور کامل پایدار نشود، به سراغ به‌روزرسانی کانتینر بعدی نخواهد رفت.
   • این مقدار برای جلوگیری از بار زیاد و مشکلات احتمالی به‌ویژه در زمان‌های فشار بالا اهمیت زیادی دارد. با این تنظیم، می‌توانید مدت‌زمانی بین به‌روزرسانی‌ها در نظر بگیرید که به سرویس‌ها و منابع اجازه می‌دهد تا به وضعیت پایدار بازگردند.

---

تنظیم مقادیر Parallelism و Update Delay در Rolling Updates

برای تنظیم این دو مقدار، از دستور docker service update به همراه گزینه‌های --update-parallelism و --update-delay استفاده می‌کنیم.

1. تنظیم Parallelism

برای کنترل تعداد کانتینرهایی که به‌طور همزمان به‌روزرسانی می‌شوند، از گزینه --update-parallelism استفاده می‌کنیم. به‌طور مثال:

docker service update --update-parallelism 2 my_service

این دستور مشخص می‌کند که به‌طور همزمان تنها ۲ کانتینر از سرویس my_service به‌روزرسانی شوند. مقدار پیش‌فرض این گزینه به‌طور خودکار تنظیم می‌شود تا از ایجاد بار بیش از حد بر روی نودها جلوگیری شود.

2. تنظیم Update Delay

با استفاده از گزینه --update-delay می‌توانیم مدت‌زمانی را که بین به‌روزرسانی هر کانتینر اعمال می‌شود، تعیین کنیم. این تأخیر به‌ویژه در شرایطی که بار زیاد است یا زمانی که مطمئن نیستیم به‌روزرسانی‌ها به‌طور کامل پایدار شده‌اند، بسیار مفید است.

برای مثال، اگر بخواهید ۳۰ ثانیه تأخیر بین به‌روزرسانی هر کانتینر اعمال کنید، دستور به‌صورت زیر خواهد بود:

docker service update --update-delay 30s my_service

این دستور باعث می‌شود که بعد از به‌روزرسانی یک کانتینر، Docker Swarm به مدت ۳۰ ثانیه صبر کند تا وضعیت آن کانتینر تثبیت شود و سپس به سراغ به‌روزرسانی کانتینر بعدی برود.

3. ترکیب Parallelism و Update Delay

شما می‌توانید این دو گزینه را همزمان برای کنترل دقیق‌تر فرآیند Rolling Update به کار ببرید. به‌عنوان مثال:

docker service update --update-parallelism 3 --update-delay 20s my_service

این دستور موجب می‌شود که هم‌زمان ۳ کانتینر به‌روزرسانی شوند و بین هر به‌روزرسانی ۲۰ ثانیه تأخیر وجود داشته باشد.

---

چرا استفاده از Parallelism و Update Delay اهمیت دارد؟

1. کنترل بهتر بر بار سیستم: با تنظیم صحیح مقادیر Parallelism و Update Delay، می‌توانید از فشار ناخواسته بر روی منابع سخت‌افزاری و نودها جلوگیری کنید. به‌ویژه در زمان‌هایی که سیستم تحت فشار است، این تنظیمات می‌توانند کمک کنند تا به‌روزرسانی‌ها به‌طور تدریجی و بدون مشکل انجام شوند.
2. دستیابی به پایداری سریع‌تر: زمانی که از Parallelism و Update Delay به‌طور صحیح استفاده کنید، می‌توانید مطمئن شوید که هر کانتینر به‌طور کامل پایدار می‌شود قبل از آنکه به‌روزرسانی کانتینر بعدی آغاز شود. این باعث می‌شود که سیستم از لحاظ عملکردی همیشه در وضعیت پایدار باقی بماند.
3. پیشگیری از مشکلات دسترسی: در صورتی که بخواهید از Rolling Update در محیط‌های تولیدی استفاده کنید، تنظیم دقیق این مقادیر می‌تواند مانع از دسترسی ناپایدار به سرویس‌ها شود. با استفاده از این تنظیمات، می‌توانید اطمینان حاصل کنید که همیشه تعداد کافی از کانتینرها در حال اجرا و در دسترس هستند.
4. افزایش کنترل بر فرآیند به‌روزرسانی: با کنترل دقیق به‌روزرسانی‌ها می‌توانید از مشکلاتی مانند تداخلات ناخواسته یا عدم سازگاری نسخه‌های مختلف جلوگیری کنید. این مسئله به‌ویژه در محیط‌های پیچیده و در شرایطی که سرویس‌ها دارای ترافیک بالا هستند، حائز اهمیت است.

---

جمع‌بندی

در Docker Swarm، استفاده از مقادیر Parallelism و Update Delay برای کنترل بهتر فرآیند Rolling Update بسیار حیاتی است. این تنظیمات به شما امکان می‌دهند که فرآیند به‌روزرسانی را به‌طور دقیق مدیریت کنید، از فشار اضافی بر روی نودها جلوگیری کنید و اطمینان حاصل کنید که سیستم به‌طور پیوسته و پایدار در حال اجراست. تنظیمات دقیق این مقادیر باعث می‌شود که به‌روزرسانی‌ها به‌طور تدریجی و بدون ایجاد اختلال در عملکرد سرویس‌ها انجام شوند، که این امر به‌ویژه در محیط‌های تولیدی اهمیت زیادی دارد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 8. عیب‌یابی و مانیتورینگ سرویس‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از docker service ps برای بررسی وضعیت سرویس‌ها” subtitle=”توضیحات کامل”]یکی از ابزارهای اصلی و پرکاربرد در Docker Swarm برای نظارت و بررسی وضعیت سرویس‌ها، دستور docker service ps است. این دستور به شما این امکان را می‌دهد که اطلاعات دقیقی از وضعیت سرویس‌های در حال اجرا در کلاستر Swarm بدست آورید. از جمله اطلاعاتی که می‌توان به‌راحتی از طریق این دستور مشاهده کرد، شامل وضعیت کانتینرها، میزان پیشرفت به‌روزرسانی‌ها، تعداد کانتینرهای در حال اجرا و مشکلات احتمالی در کلاستر می‌باشد.

این ابزار بسیار کارآمد است و به شما کمک می‌کند تا به‌طور دقیق و در لحظه وضعیت سرویس‌ها را در کلاستر Swarm بررسی کرده و اقدام به رفع مشکلات احتمالی نمایید.

---

دستور docker service ps چیست؟

دستور docker service ps اطلاعاتی را در مورد تمام taskهای مرتبط با یک سرویس خاص نمایش می‌دهد. در واقع، هر task در Docker Swarm معادل یک کانتینر است که تحت یک سرویس در حال اجرا می‌باشد. این دستور به شما کمک می‌کند که وضعیت هر کانتینر را مشاهده کرده و مطمئن شوید که سرویس شما به درستی در حال اجرا است.

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

docker service ps <service_name>

در این دستور، <service_name> نام سرویس مورد نظر است که وضعیت آن را می‌خواهید بررسی کنید.

---

ورودی‌های خروجی دستور docker service ps

هنگامی که دستور docker service ps را اجرا می‌کنید، خروجی آن اطلاعات مختلفی را نمایش می‌دهد که می‌توانند شامل موارد زیر باشند:

• ID: شناسه یکتای task.
• Name: نام سرویس که این task به آن تعلق دارد.
• Service: نام سرویس.
• Desired State: وضعیت دلخواه سرویس، که معمولاً به “running” (در حال اجرا) یا “shutdown” (خاموش) تغییر می‌کند.
• Current State: وضعیت فعلی task. این وضعیت می‌تواند شامل “Starting”, “Running”, “Completed”, “Failed”, “Shutdown” و غیره باشد.
• Node: نود (سرور) که task در آن اجرا می‌شود.
• Error: اگر خطایی در اجرای task وجود داشته باشد، در این قسمت نمایش داده می‌شود.
• Ports: پورت‌های در دسترس که سرویس از طریق آن‌ها قابل دسترسی است.

---

مثال‌هایی از استفاده از دستور docker service ps

1. نمایش وضعیت سرویس خاص: برای مشاهده وضعیت یک سرویس خاص (برای مثال، سرویس با نام my_service)، می‌توانید دستور زیر را اجرا کنید:

   docker service ps my_service
   

   خروجی این دستور می‌تواند چیزی مشابه به این باشد:

   ID                  NAME              IMAGE               NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
   w7gn7qnbayk7        my_service.1      my_image:latest     node-1              Running             Running 2 seconds ago                       
   i7gn7qnbayk7        my_service.2      my_image:latest     node-2              Running             Running 2 seconds ago                       
   k7gn7qnbayk7        my_service.3      my_image:latest     node-3              Running             Running 2 seconds ago                       
   

   در این مثال، سه task از سرویس my_service در حال اجرا هستند، که هر کدام روی یک نود متفاوت قرار دارند. وضعیت همه taskها “Running” است.

2. مشاهده جزئیات بیشتر: برای دریافت اطلاعات بیشتر و جزئیات دقیق‌تر در مورد وضعیت سرویس‌ها می‌توانید از گزینه -v (verbose) استفاده کنید:

   docker service ps -v my_service
   

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

---

استفاده از docker service ps برای عیب‌یابی مشکلات سرویس

دستور docker service ps برای شناسایی و رفع مشکلات مربوط به سرویس‌های در حال اجرا بسیار مفید است. برخی از مشکلات رایج که می‌توانید با استفاده از این دستور شناسایی کنید عبارتند از:

1. عدم راه‌اندازی task: اگر یکی از taskها نمی‌تواند به‌درستی راه‌اندازی شود، در قسمت Current State به‌جای “Running”، وضعیت‌هایی مانند “Pending”، “Failed” یا “Starting” را مشاهده خواهید کرد. در این صورت، می‌توانید دلیل مشکل را از طریق خطای ثبت‌شده در بخش Error پیدا کنید.
2. مشکلات مربوط به نود: اگر سرویس‌ها روی نودی با مشکل مواجه باشند، این اطلاعات را نیز می‌توانید در ستون Node مشاهده کنید. در صورتی که نود از دسترس خارج شده باشد، Docker قادر نخواهد بود که task جدیدی روی آن راه‌اندازی کند.
3. سرویس‌های ناقص: ممکن است یک سرویس در وضعیت Desired State قرار داشته باشد که “Running” باشد، اما در واقع به دلیل مشکلات مختلف (مانند مشکلات پیکربندی یا کمبود منابع) taskهای آن در وضعیت “Failed” قرار گیرند. این اطلاعات در بخش Current State قابل مشاهده است.
4. توقف ناگهانی سرویس: اگر یک سرویس به طور ناگهانی متوقف شود، می‌توانید با بررسی وضعیت taskهای سرویس از طریق docker service ps علت توقف سرویس را شناسایی کنید. همچنین بررسی Logs سرویس نیز می‌تواند اطلاعات دقیقی درباره دلیل توقف ارائه دهد.

---

استفاده از docker service ps با گزینه‌های اضافی

دستور docker service ps همچنین می‌تواند با گزینه‌های اضافی مختلفی همراه باشد که به شما کمک می‌کند اطلاعات دقیق‌تری دریافت کنید.

• --no-trunc: این گزینه اطلاعات را به‌طور کامل و بدون برش (truncate) نمایش می‌دهد.

  docker service ps --no-trunc my_service
  

• -q: این گزینه تنها شناسه‌های taskها را نمایش می‌دهد و به شما این امکان را می‌دهد که فقط IDهای taskها را مشاهده کنید.

  docker service ps -q my_service
  

• --filter: می‌توانید از این گزینه برای فیلتر کردن خروجی استفاده کنید. به‌عنوان مثال، برای نمایش فقط taskهایی که در وضعیت “Failed” هستند:

  docker service ps --filter "desired-state=running" my_service
  

---

جمع‌بندی

استفاده از دستور docker service ps در Docker Swarm به‌منظور نظارت بر وضعیت سرویس‌ها و شناسایی مشکلات در فرآیند اجرای سرویس‌ها یک ابزار ضروری است. این دستور به شما امکان می‌دهد که به‌طور دقیق وضعیت هر task در یک سرویس را بررسی کرده و در صورت بروز مشکلات، آن‌ها را شناسایی و رفع کنید. از طریق این دستور می‌توانیم جزئیات کاملی از وضعیت سرویس‌ها، کانتینرها و نودهای مرتبط را در اختیار داشته باشیم، که به‌ویژه در شرایط بحرانی یا در زمان به‌روزرسانی سرویس‌ها بسیار کاربردی است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مانیتورینگ لاگ‌های سرویس‌ها با دستور docker service logs” subtitle=”توضیحات کامل”]یکی از مهم‌ترین نیازهای یک مهندس سیستم یا توسعه‌دهنده در محیط‌های تولیدی، دسترسی به لاگ‌های سرویس‌ها به‌منظور عیب‌یابی، نظارت بر عملکرد و اطمینان از سالم بودن سرویس‌ها است. در Docker Swarm، برای این که بتوانید لاگ‌های سرویس‌های در حال اجرا را مشاهده کنید و مشکلات را سریع‌تر شناسایی کنید، دستور docker service logs به کار می‌آید. این دستور به شما اجازه می‌دهد تا لاگ‌های مربوط به سرویس‌ها را مشاهده کنید و در صورت نیاز، از آن‌ها برای تحلیل و رفع مشکلات استفاده کنید.

---

دستور docker service logs چیست؟

دستور docker service logs برای مشاهده لاگ‌های مرتبط با سرویس‌ها در کلاستر Docker Swarm مورد استفاده قرار می‌گیرد. با استفاده از این دستور می‌توانید تمام لاگ‌های مرتبط با taskهای مختلف یک سرویس خاص را بررسی کنید. این اطلاعات بسیار مفید برای تحلیل و رفع مشکلات سرویس‌ها در کلاستر هستند.

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

docker service logs <options> <service_name>

در این دستور، <service_name> نام سرویس است که می‌خواهید لاگ‌های آن را مشاهده کنید. می‌توانید با استفاده از گزینه‌های مختلف، کنترل دقیقی بر نحوه نمایش لاگ‌ها داشته باشید.

---

ورودی‌های خروجی دستور docker service logs

هنگامی که این دستور را اجرا می‌کنید، خروجی آن لاگ‌های مختلفی را نمایش می‌دهد که اطلاعات زیادی از وضعیت سرویس و taskهای آن را شامل می‌شود. هر خط لاگ معمولاً شامل اطلاعات زیر خواهد بود:

• Timestamp: تاریخ و ساعت ثبت لاگ.
• Node: نودی که task یا کانتینر روی آن در حال اجرا است.
• Task ID: شناسه task مربوط به سرویس.
• Log message: پیامی که سرویس یا کانتینر در آن لحظه ایجاد کرده است.

خروجی نمونه‌ای از دستور docker service logs ممکن است به شکل زیر باشد:

2025-02-09T12:00:00.000000000Z node-1 7f8a5e69c0d0 my_service.1 task-1 started
2025-02-09T12:01:00.000000000Z node-2 7f8a5e69c0d0 my_service.2 task-2 started
2025-02-09T12:05:00.000000000Z node-1 7f8a5e69c0d0 my_service.1 task-1 error: Connection timed out
2025-02-09T12:10:00.000000000Z node-3 7f8a5e69c0d0 my_service.3 task-3 completed successfully

در این مثال، شما می‌توانید تاریخ و ساعت دقیق، نودهایی که سرویس در آن‌ها در حال اجرا بوده، شناسه taskها و پیام‌های مربوط به وضعیت آن‌ها را مشاهده کنید.

---

دستور docker service logs با گزینه‌های مختلف

دستور docker service logs می‌تواند با گزینه‌های مختلفی همراه باشد که به شما این امکان را می‌دهد که لاگ‌ها را دقیق‌تر و بهتر مشاهده کنید. برخی از مهم‌ترین این گزینه‌ها عبارتند از:

1. --follow: گزینه --follow برای مشاهده لاگ‌ها به‌صورت زنده و لحظه‌ای استفاده می‌شود. با این گزینه، لاگ‌ها به‌صورت مداوم نمایش داده خواهند شد و شما می‌توانید در زمان واقعی وضعیت سرویس‌ها را دنبال کنید.

   docker service logs --follow my_service
   

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

2. --tail: گزینه --tail به شما این امکان را می‌دهد که تنها تعداد مشخصی از آخرین خطوط لاگ را مشاهده کنید. به‌عنوان مثال، اگر بخواهید فقط 50 خط آخر لاگ را ببینید:

   docker service logs --tail 50 my_service
   

   این دستور فقط 50 خط آخر لاگ‌های سرویس my_service را نمایش خواهد داد.

3. --since: با استفاده از گزینه --since، می‌توانید لاگ‌های سرویس را از یک زمان خاص به بعد مشاهده کنید. برای مثال، اگر بخواهید لاگ‌ها را از زمان خاصی به بعد ببینید:

   docker service logs --since "2025-02-09T12:00:00" my_service
   

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

4. --timestamps: با استفاده از گزینه --timestamps می‌توانید تاریخ و زمان ثبت هر خط لاگ را نیز مشاهده کنید. این گزینه به‌طور پیش‌فرض فعال نیست، اما اگر نیاز به مشاهده تاریخ و زمان دقیق لاگ‌ها دارید، می‌توانید از آن استفاده کنید:

   docker service logs --timestamps my_service
   

   در این صورت، در کنار هر پیامی که در لاگ نمایش داده می‌شود، تاریخ و ساعت آن نیز نمایش داده خواهد شد.

5. --no-task-ids: اگر نیازی به مشاهده شناسه taskها در لاگ‌ها نداشته باشید و بخواهید که فقط پیام‌های مربوط به سرویس‌ها نمایش داده شوند، می‌توانید از گزینه --no-task-ids استفاده کنید:

   docker service logs --no-task-ids my_service
   

   این گزینه شناسه‌های task را از خروجی لاگ‌ها حذف می‌کند و فقط پیام‌ها را نمایش می‌دهد.

6. --details: با استفاده از گزینه --details می‌توانید اطلاعات بیشتری در مورد هر لاگ مشاهده کنید. این اطلاعات ممکن است شامل جزئیات اضافی در مورد نحوه اجرا و پیکربندی task باشد:

   docker service logs --details my_service
   

---

مثال‌های استفاده از docker service logs

1. مشاهده لاگ‌های سرویس خاص: برای مشاهده لاگ‌های مربوط به سرویس خاصی به‌طور پیش‌فرض، دستور زیر را اجرا می‌کنید:

   docker service logs my_service
   

   این دستور لاگ‌های تمامی taskهای سرویس my_service را نمایش خواهد داد.

2. مشاهده لاگ‌های سرویس به‌صورت زنده: برای مشاهده لاگ‌های سرویس در زمان واقعی و به‌صورت مداوم، از گزینه --follow استفاده می‌کنید:

   docker service logs --follow my_service
   

3. مشاهده 100 خط آخر لاگ: برای مشاهده 100 خط آخر لاگ‌های سرویس، دستور زیر را اجرا می‌کنید:

   docker service logs --tail 100 my_service
   

---

مزایای استفاده از دستور docker service logs

• عیب‌یابی سریع‌تر: این دستور به شما این امکان را می‌دهد که به‌سرعت مشکلات در سرویس‌ها را شناسایی کرده و آن‌ها را برطرف کنید.
• تحلیل عملکرد سرویس‌ها: با مشاهده لاگ‌ها می‌توانید عملکرد سرویس‌های خود را در کلاستر Docker Swarm تجزیه و تحلیل کنید و مشکلات احتمالی را رفع نمایید.
• نظارت لحظه‌ای: با استفاده از گزینه --follow می‌توانید لاگ‌ها را به‌صورت لحظه‌ای مشاهده کنید و به‌طور مداوم از وضعیت سرویس‌ها آگاه باشید.

---

جمع‌بندی

دستور docker service logs یک ابزار قدرتمند برای مانیتورینگ لاگ‌های سرویس‌ها در کلاستر Docker Swarm است. این دستور به شما کمک می‌کند تا وضعیت سرویس‌ها را به‌طور دقیق بررسی کنید و در صورت بروز مشکل، از لاگ‌ها برای عیب‌یابی و رفع مشکل استفاده کنید. با استفاده از گزینه‌های مختلف مانند --follow، --tail و --timestamps می‌توانید به‌طور خاص لاگ‌ها را مشاهده کرده و تجربه مدیریت بهتری در کلاستر Docker Swarm داشته باشید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مدیریت مشکلات شبکه و دسترسی در کلاستر” subtitle=”توضیحات کامل”]یکی از چالش‌های اصلی در محیط‌های تولیدی و توزیع‌شده مانند Docker Swarm، مدیریت و رفع مشکلات شبکه و دسترسی است. کلاسترهای Docker Swarm، برای انجام ارتباطات میان سرویس‌ها و نودها نیاز به یک شبکه محلی مناسب دارند که باید به‌درستی پیکربندی و مدیریت شود. در صورتی که مشکلات شبکه‌ای در کلاستر به وجود آید، می‌تواند منجر به کاهش عملکرد سرویس‌ها یا از دست رفتن دسترسی به خدمات شود.

در این بخش، به بررسی روش‌ها و ابزارهایی خواهیم پرداخت که می‌توانند در شناسایی، مدیریت و رفع مشکلات شبکه و دسترسی در کلاستر Docker Swarm مفید باشند.

---

1. درک اهمیت شبکه در Docker Swarm

Docker Swarm از شبکه‌های مجازی برای ارتباط بین نودها و سرویس‌ها در کلاستر استفاده می‌کند. هر نود (چه Manager و چه Worker) می‌تواند از شبکه‌های مختلفی برای ارتباطات داخلی و خارجی استفاده کند. بنابراین، مشکلات شبکه‌ای در کلاستر می‌تواند از مشکلات در پیکربندی شبکه گرفته تا مسائلی مانند اختلال در ارتباطات بین نودها و سرویس‌ها باشد. شبکه‌های مختلفی در Docker Swarm وجود دارد که می‌توانند شامل موارد زیر باشند:

• شبکه‌های Overlay: شبکه‌هایی که برای اتصال سرویس‌ها در نودهای مختلف کلاستر استفاده می‌شوند.
• شبکه‌های Bridge: شبکه‌های داخلی که برای ارتباطات بین کانتینرهای یک نود استفاده می‌شوند.
• شبکه‌های Host: شبکه‌هایی که به‌صورت مستقیم به نودها متصل می‌شوند.

درک دقیق شبکه و نحوه عملکرد آن در کلاستر، اولین قدم برای رفع مشکلات شبکه‌ای است.

---

2. ابزارهای کلیدی برای شناسایی مشکلات شبکه

برای شناسایی مشکلات شبکه‌ای در کلاستر Docker Swarm، ابزارهای مختلفی در دسترس هستند. این ابزارها می‌توانند در تشخیص مشکلات اتصال، بسته‌های از دست رفته، یا پیکربندی اشتباه شبکه کمک کنند.

1. دستور docker network ls: این دستور برای لیست کردن تمامی شبکه‌هایی که در Docker Swarm تعریف شده‌اند، استفاده می‌شود. با استفاده از این دستور می‌توانید وضعیت شبکه‌ها را بررسی کرده و مطمئن شوید که همه شبکه‌ها به‌درستی ایجاد شده‌اند.

   docker network ls
   

   این دستور تمامی شبکه‌های موجود را نشان خواهد داد و شما می‌توانید شبکه‌های فعال و وضعیت آن‌ها را مشاهده کنید.

2. دستور docker network inspect <network_name>: برای بررسی جزئیات شبکه‌ای خاص، از دستور docker network inspect استفاده می‌شود. این دستور اطلاعاتی مانند شناسه شبکه، نودهایی که به شبکه متصل هستند، و تنظیمات IP را نمایش می‌دهد.

   docker network inspect my_overlay_network
   

   با این دستور، جزئیات شبکه‌ای به نام my_overlay_network به‌طور کامل نشان داده خواهد شد.

3. دستور docker service ps <service_name>: برای بررسی وضعیت سرویس‌ها و taskهای آن‌ها می‌توانید از دستور docker service ps استفاده کنید. این دستور می‌تواند نشان دهد که آیا سرویس شما به‌درستی در حال اجرا است یا به دلیل مشکل شبکه، برخی از taskها در حال توقف هستند.

   docker service ps my_service
   

4. دستور docker node ls: برای بررسی وضعیت کلی نودهای کلاستر و اطمینان از سالم بودن آن‌ها، می‌توانید از دستور docker node ls استفاده کنید. این دستور وضعیت نودهای مختلف را نشان می‌دهد، و اگر مشکلی در دسترسی به نودها وجود داشته باشد، از این طریق می‌توانید آن را شناسایی کنید.

   docker node ls
   

---

3. رفع مشکلات شبکه‌ای در Docker Swarm

1. بررسی اتصال نودها به هم (Overlay Network Issues): یکی از مهم‌ترین مشکلات شبکه‌ای در کلاسترهای Docker Swarm می‌تواند قطع ارتباط نودها از یکدیگر باشد. شبکه‌های Overlay به‌طور پیش‌فرض برای برقراری ارتباط بین نودها در کلاستر مورد استفاده قرار می‌گیرند. اگر این شبکه به درستی پیکربندی نشود، ممکن است نودها نتوانند به یکدیگر متصل شوند.
   • راه‌حل: اولین قدم برای رفع این مشکل، بررسی وضعیت شبکه‌های Overlay با دستور docker network ls و docker network inspect است. اطمینان حاصل کنید که شبکه Overlay به‌درستی ایجاد شده باشد و نودها به‌طور صحیح به آن متصل باشند.
   • اگر نودها نمی‌توانند به شبکه Overlay متصل شوند، احتمالاً مشکلاتی مانند پیکربندی اشتباه در فایروال یا VPN وجود دارد. بررسی تنظیمات فایروال و VPN برای اطمینان از عدم مسدود شدن پورت‌های مربوط به Docker Swarm، بسیار حائز اهمیت است.
2. مشکل در اتصال سرویس‌ها: یکی از دلایل رایج مشکلات شبکه‌ای در Docker Swarm، عدم اتصال صحیح سرویس‌ها به یکدیگر است. برای بررسی وضعیت سرویس‌ها و اتصال آن‌ها به شبکه‌ها، از دستورات docker service ps و docker network inspect استفاده کنید.
   • راه‌حل: اگر مشکلی در اتصال سرویس‌ها وجود دارد، ابتدا با بررسی اینکه آیا سرویس‌ها به شبکه درست متصل هستند، شروع کنید. همچنین بررسی کنید که آیا نودهای مربوطه در حالت Healthy هستند یا خیر.
3. مشکلات مربوط به DNS داخلی: در Docker Swarm، DNS داخلی برای نام‌گذاری سرویس‌ها و ارتباط بین سرویس‌ها استفاده می‌شود. گاهی اوقات مشکلات DNS می‌تواند مانع از اتصال صحیح سرویس‌ها به یکدیگر شود.
   • راه‌حل: برای رفع مشکلات DNS، از دستور docker service logs استفاده کنید تا بتوانید به‌راحتی خطاهای مربوط به DNS را شناسایی کنید. اطمینان حاصل کنید که سرویس‌ها به درستی در داخل کلاستر شناسایی می‌شوند.
4. اختلالات در شبکه Bridge (مشکلات محلی نودها): مشکلات شبکه Bridge معمولاً زمانی اتفاق می‌افتند که کانتینرها در نودهای مختلف به‌درستی قادر به ارتباط با یکدیگر نباشند. این نوع مشکلات می‌تواند باعث اختلال در سرویس‌ها و کانتینرهای مختلف شود.
   • راه‌حل: ابتدا از دستور docker network inspect bridge برای بررسی وضعیت شبکه Bridge استفاده کنید. اگر نیاز به تنظیم مجدد شبکه Bridge دارید، می‌توانید آن را با استفاده از دستورات docker network create و docker network connect مجدداً پیکربندی کنید.

---

4. بهینه‌سازی شبکه و دسترسی در Docker Swarm

برای جلوگیری از مشکلات شبکه‌ای در آینده و بهینه‌سازی عملکرد کلاستر Docker Swarm، می‌توانید چند اقدام پیشگیرانه انجام دهید:

• پیکربندی صحیح فایروال: اطمینان حاصل کنید که پورت‌های مورد نیاز Docker Swarm (پورت‌های مدیریتی و ارتباطی بین نودها) در فایروال باز باشند.
• مقیاس‌پذیری شبکه: در صورتی که کلاستر شما گسترش یابد، ممکن است نیاز به شبکه‌های بزرگ‌تر و پیچیده‌تری داشته باشید. شبکه‌های Overlay می‌توانند به‌صورت خودکار مقیاس‌پذیری داشته باشند، اما برای مقیاس‌های بسیار بزرگ‌تر، نیاز به پیکربندی‌های دقیق‌تری خواهید داشت.
• استفاده از شبکه‌های جداگانه برای سرویس‌ها: برای جداسازی ترافیک سرویس‌ها و افزایش امنیت، می‌توانید برای هر سرویس شبکه جداگانه‌ای ایجاد کنید.

---

جمع‌بندی

مشکلات شبکه‌ای در کلاسترهای Docker Swarm می‌تواند تأثیرات زیادی بر عملکرد و دسترسی سرویس‌ها داشته باشد. برای مدیریت این مشکلات، باید ابتدا ابزارهای مناسب مانند docker network ls و docker service ps را برای شناسایی مشکلات استفاده کرد. سپس، با اصلاح تنظیمات شبکه، حل مشکلات DNS، و مدیریت پیکربندی فایروال، می‌توانید مشکلات شبکه‌ای را به حداقل برسانید. توجه به بهینه‌سازی شبکه، از جمله استفاده از شبکه‌های جداگانه برای سرویس‌ها و تنظیمات صحیح فایروال، می‌تواند به افزایش کارایی و امنیت کلاستر شما کمک کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ابزارها و روش‌های بررسی سلامت کلاستر در Docker Swarm” subtitle=”توضیحات کامل”]در یک کلاستر Docker Swarm، نظارت بر سلامت و عملکرد نودها و سرویس‌ها از اهمیت بالایی برخوردار است. اگر مشکلی در کلاستر پیش آید، ممکن است بر عملکرد سرویس‌ها و قابلیت دسترسی به خدمات تأثیر بگذارد. از این‌رو، ابزارها و روش‌های مختلفی وجود دارند که می‌توانند به مدیران سیستم کمک کنند تا از وضعیت سلامت کلاستر آگاه شوند و اقدامات لازم را انجام دهند. در این بخش، به بررسی ابزارها و روش‌های مختلف برای بررسی سلامت کلاستر Docker Swarm خواهیم پرداخت.

---

1. بررسی سلامت نودها با استفاده از دستور docker node ls

دستور docker node ls یکی از ابزارهای اصلی برای بررسی وضعیت نودها در کلاستر Docker Swarm است. این دستور وضعیت تمامی نودها، اعم از نودهای Manager و Worker، را نمایش می‌دهد و اطلاعاتی مانند وضعیت هر نود (Available یا Unavailable)، نقش (Manager یا Worker) و وضعیت سلامت آن‌ها را نشان می‌دهد.

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

docker node ls

در خروجی این دستور، ستون‌های مختلفی وجود دارد که برخی از آن‌ها عبارتند از:

• ID: شناسه یکتا برای هر نود.
• Hostname: نام میزبان نود.
• Status: وضعیت سلامت نود (Ready یا Down).
• Availability: وضعیت دسترسی نود به کلاستر (Active یا Pause).
• Manager: نمایشگر این که آیا نود یک نود Manager است یا خیر.

اگر نودی در وضعیت “Down” باشد یا در وضعیت “Unavailable” قرار داشته باشد، ممکن است نشان‌دهنده وجود مشکلات در آن نود باشد و نیاز به بررسی بیشتر دارد.

---

2. بررسی وضعیت سرویس‌ها با دستور docker service ls

برای بررسی سلامت سرویس‌ها و وضعیت taskهای مربوط به آن‌ها، از دستور docker service ls استفاده می‌شود. این دستور اطلاعاتی مانند تعداد taskهای در حال اجرا، تعداد taskهای سالم، و تعداد taskهای با خطا را نمایش می‌دهد.

با اجرای دستور زیر می‌توانید وضعیت سرویس‌ها را مشاهده کنید:

docker service ls

در خروجی این دستور، می‌توانید موارد زیر را مشاهده کنید:

• ID: شناسه یکتا برای هر سرویس.
• Name: نام سرویس.
• Replicas: تعداد taskهای در حال اجرا و تعداد taskهایی که باید اجرا شوند.
• Image: نام و نسخه تصویر کانتینر استفاده‌شده برای سرویس.
• Ports: پورت‌های در دسترس سرویس.

در صورتی که تعداد taskهای سالم کمتر از تعداد taskهای مورد نظر باشد، نیاز به بررسی وضعیت سرویس و taskهای آن دارید.

---

3. بررسی وضعیت taskها با دستور docker service ps

دستور docker service ps <service_name> برای بررسی وضعیت taskهای مرتبط با یک سرویس خاص در Docker Swarm استفاده می‌شود. این دستور اطلاعات دقیقی در مورد هر task از جمله وضعیت، زمان راه‌اندازی، و پیام‌های خطا ارائه می‌دهد.

برای بررسی وضعیت taskها، از دستور زیر استفاده کنید:

docker service ps <service_name>

در این دستور، <service_name> باید با نام سرویس مورد نظر جایگزین شود. خروجی این دستور شامل اطلاعاتی مانند:

• ID: شناسه task.
• Name: نام task.
• Desired State: وضعیت دلخواه task (Running یا Shutdown).
• Current State: وضعیت فعلی task.
• Error: اگر مشکلی وجود داشته باشد، پیام خطا در این قسمت نمایش داده می‌شود.

در صورتی که یکی از taskها با خطا مواجه شود، لازم است بررسی کنید که آیا این خطا ناشی از مشکلات شبکه، منابع یا پیکربندی اشتباه است.

---

4. بررسی لاگ‌های سرویس‌ها با دستور docker service logs

یکی از راه‌های مفید برای بررسی وضعیت سلامت سرویس‌ها و شناسایی مشکلات، مطالعه لاگ‌های مربوط به سرویس‌ها است. دستور docker service logs به شما اجازه می‌دهد تا لاگ‌های مربوط به سرویس خاصی را مشاهده کنید.

برای مشاهده لاگ‌های سرویس، می‌توانید از دستور زیر استفاده کنید:

docker service logs <service_name>

این دستور تمامی لاگ‌های مربوط به سرویس مشخص‌شده را نمایش می‌دهد. می‌توانید از گزینه‌های اضافی مانند --follow برای پیگیری لاگ‌ها به‌صورت زنده و --tail برای مشاهده آخرین خطوط استفاده کنید:

docker service logs --follow --tail 100 <service_name>

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

---

5. بررسی وضعیت نودها با دستور docker info

دستور docker info اطلاعات کلی در مورد وضعیت Docker Engine و کلاستر شما را نمایش می‌دهد. این دستور می‌تواند اطلاعاتی مانند تعداد نودهای موجود در کلاستر، وضعیت کلاستر، و مشکلات موجود در آن را ارائه دهد.

برای مشاهده وضعیت کلی کلاستر و Docker Engine، از دستور زیر استفاده کنید:

docker info

در این دستور، بخش‌های مختلفی وجود دارد که شامل:

• Swarm: وضعیت کلاستر (Active یا Inactive).
• Nodes: تعداد نودهای کلاستر.
• Cluster: وضعیت کلی کلاستر.

این دستور به شما اطلاعات کاملی در مورد سلامت کلی کلاستر و Docker Engine می‌دهد و می‌تواند برای تشخیص مشکلات کلی کلاستر مفید باشد.

---

6. استفاده از ابزارهای مانیتورینگ خارجی

برای نظارت دقیق‌تر و در زمان واقعی بر روی سلامت کلاستر Docker Swarm، می‌توان از ابزارهای مانیتورینگ مانند Prometheus و Grafana استفاده کرد. این ابزارها امکان نظارت بر وضعیت نودها، سرویس‌ها، و منابع را در یک داشبورد گرافیکی فراهم می‌آورند و می‌توانند هشدارهای مربوط به مشکلات احتمالی را به‌طور خودکار ارسال کنند.

• Prometheus برای جمع‌آوری و ذخیره‌سازی متریک‌ها استفاده می‌شود.
• Grafana برای تجزیه‌وتحلیل و نمایش داده‌های جمع‌آوری‌شده به‌صورت گرافیکی استفاده می‌شود.

این ابزارها به‌ویژه برای محیط‌های بزرگ‌تر و پیچیده‌تر مفید هستند و به شما کمک می‌کنند تا وضعیت سلامت کلاستر را در زمان واقعی نظارت کنید.

---

7. بررسی شبکه با دستور docker network inspect

اگر مشکلات مربوط به شبکه و اتصال سرویس‌ها وجود داشته باشد، می‌توانید از دستور docker network inspect برای بررسی وضعیت شبکه‌های مختلف استفاده کنید. این دستور جزئیاتی مانند وضعیت شبکه‌های Overlay، تعداد نودهایی که به شبکه متصل هستند و آدرس‌های IP را ارائه می‌دهد.

برای بررسی وضعیت یک شبکه خاص، از دستور زیر استفاده کنید:

docker network inspect <network_name>

این دستور اطلاعاتی مانند:

• Containers: کانتینرهای متصل به شبکه.
• IPAM: اطلاعات مربوط به تخصیص آدرس‌های IP.
• Scope: محدوده شبکه (برای شبکه‌های Overlay معمولاً به صورت global است).

---

جمع‌بندی

بررسی سلامت کلاستر Docker Swarm به‌طور مستمر یکی از اقدامات ضروری در مدیریت سیستم‌های توزیع‌شده است. با استفاده از ابزارهای مختلف مانند docker node ls، docker service ls، docker service ps، docker service logs و docker info می‌توان وضعیت نودها، سرویس‌ها و کلاستر را به‌دقت نظارت کرد. علاوه بر این، استفاده از ابزارهای مانیتورینگ پیشرفته مانند Prometheus و Grafana می‌تواند به شما در شناسایی مشکلات شبکه و منابع کمک کند. این ابزارها به شما کمک می‌کنند تا بتوانید کلاستر Docker Swarm را به‌صورت بهینه و پایدار نگهداری کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 9. تعامل بین Docker Swarm و سایر ابزارهای ارکستراسیون”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مقایسه Docker Swarm با Kubernetes” subtitle=”توضیحات کامل”]Docker Swarm و Kubernetes دو ابزار مهم و محبوب برای مدیریت اورکستراسیون کانتینرها هستند که به طور گسترده در محیط‌های تولیدی برای مدیریت کانتینرهای Docker استفاده می‌شوند. هرکدام از این ابزارها ویژگی‌های خاص خود را دارند و بسته به نیاز پروژه و معماری سیستم، می‌توانند انتخاب‌های مناسبی باشند. در این بخش، به مقایسه این دو ابزار از جنبه‌های مختلف می‌پردازیم.

---

1. پیچیدگی و نصب

Docker Swarm

Docker Swarm به‌عنوان ابزار اورکستراسیون پیش‌فرض Docker طراحی شده است و نصب و راه‌اندازی آن نسبتاً ساده است. برای شروع کار با Docker Swarm، کافیست تنها چند دستور ساده در خط فرمان اجرا کنید.

مراحل نصب Docker Swarm به طور ساده عبارتند از:

1. نصب Docker بر روی تمام نودهای کلاستر.
2. استفاده از دستور docker swarm init برای راه‌اندازی اولین نود Manager.
3. پیوستن نودهای Worker به کلاستر با دستور docker swarm join.

این سادگی در نصب و پیکربندی، Docker Swarm را به گزینه‌ای مناسب برای پروژه‌های کوچک‌تر و تیم‌های توسعه‌ که به دنبال یک راه‌حل سریع و راحت هستند تبدیل کرده است.

Kubernetes

Kubernetes یک سیستم اورکستراسیون پیچیده‌تر و مقیاس‌پذیرتر است. نصب Kubernetes به دلیل ویژگی‌های بیشتر و تنظیمات پیشرفته‌تری که ارائه می‌دهد، نسبت به Docker Swarm پیچیده‌تر است. برای نصب Kubernetes نیاز به ابزارهایی مانند kubeadm یا Minikube و تنظیمات بیشتری دارید. همچنین، برای تنظیم Kubernetes نیاز به پیکربندی و مدیریت اجزای مختلفی مانند Master Node، Worker Nodes، و شبکه‌های داخلی دارد.

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

---

2. مقیاس‌پذیری و عملکرد

Docker Swarm

Docker Swarm به‌طور خاص برای کار با مقیاس‌های کوچک و متوسط طراحی شده است. مقیاس‌پذیری آن به اندازه Kubernetes قوی نیست، ولی برای پروژه‌هایی که نیاز به مدیریت تعدادی سرویس دارند، Swarm می‌تواند به خوبی عمل کند. در مقایسه با Kubernetes، Docker Swarm راحت‌تر مقیاس‌پذیر است و شما می‌توانید به راحتی نودهای جدید به کلاستر اضافه کنید.

در Docker Swarm، همه نودها به‌طور خودکار وظایف و بارهای کاری را بین خود تقسیم می‌کنند و تعادل بار به صورت خودکار انجام می‌شود.

Kubernetes

Kubernetes برای مقیاس‌پذیری طراحی شده است و به‌راحتی می‌تواند با تعداد زیادی نود و کانتینر کار کند. در واقع، Kubernetes یک سیستم اورکستراسیون بسیار مقیاس‌پذیر است که می‌تواند صدها یا هزاران نود و کانتینر را مدیریت کند. Kubernetes دارای ویژگی‌هایی مانند Horizontal Pod Autoscaling است که به‌طور خودکار تعداد پادها (Pod) را بر اساس بار کاری تنظیم می‌کند.

Kubernetes از طریق ویژگی‌هایی مانند Cluster Autoscaler و Pod Disruption Budgets مقیاس‌پذیری و عملکرد بهتری را فراهم می‌آورد و در نتیجه برای پروژه‌های بزرگ‌تر و نیازمند مقیاس‌پذیری بالا مناسب‌تر است.

---

3. معماری و ساختار

Docker Swarm

Docker Swarm از معماری ساده‌تری برخوردار است. در این معماری، نودهای کلاستر به دو دسته Manager و Worker تقسیم می‌شوند. نودهای Manager مسئول مدیریت کلاستر و هماهنگی بین نودهای Worker هستند. Swarm از مفهوم Replication برای توزیع کانتینرها بین نودها استفاده می‌کند و بر اساس آن، تعداد نمونه‌های هر سرویس (Replica) را تنظیم می‌کند.

• Manager Nodes: مسئول تصمیم‌گیری، مدیریت وضعیت و نظارت بر کلاستر هستند.
• Worker Nodes: مسئول اجرای taskها و کانتینرها هستند.

این ساختار ساده باعث می‌شود Docker Swarm برای پروژه‌های کوچکتر که پیچیدگی کمتری دارند مناسب باشد.

Kubernetes

Kubernetes از معماری پیچیده‌تری برخوردار است که شامل اجزای مختلفی مانند Master Nodes، Worker Nodes، Pod، ReplicaSet، Deployment و بسیاری دیگر است. در این معماری، یک Master Node مسئول مدیریت کل کلاستر است و Worker Nodeها وظیفه اجرای پادها (Pod) و کانتینرها را دارند.

• Master Node: شامل اجزای مختلفی مانند kube-apiserver، etcd، kube-scheduler و kube-controller-manager است که مدیریت کلاستر و هماهنگی بین اجزا را بر عهده دارند.
• Worker Nodes: شامل kubelet، kube-proxy و container runtime هستند که وظیفه اجرای پادها و کانتینرها را بر عهده دارند.

این معماری پیچیده، Kubernetes را برای پروژه‌های بزرگ و پیچیده‌تر با نیازهای خاص مناسب‌تر می‌کند.

---

4. قابلیت‌ها و ویژگی‌ها

Docker Swarm

Docker Swarm ویژگی‌های اصلی و ساده‌ای برای اورکستراسیون کانتینرها دارد:

• Load Balancing: توزیع بار به‌طور خودکار بین نودها.
• Scaling: افزایش یا کاهش تعداد replicas به‌راحتی.
• Rolling Updates: به‌روزرسانی سرویس‌ها به صورت تدریجی بدون وقفه.
• Self-healing: خود ترمیم‌کننده برای مدیریت مشکلات کانتینرها.

Docker Swarm به دلیل سادگی در استفاده، برای پروژه‌هایی که نیاز به ویژگی‌های اورکستراسیون پایه‌ای دارند، مناسب است.

Kubernetes

Kubernetes دارای ویژگی‌های پیشرفته‌تری است که آن را برای مدیریت محیط‌های پیچیده‌تر مناسب می‌سازد:

• Advanced Load Balancing: امکان استفاده از Load Balancerهای خارجی و داخلی.
• Automatic Scaling: مقیاس‌پذیری اتوماتیک با استفاده از Horizontal Pod Autoscaler و Cluster Autoscaler.
• Self-healing: از طریق ویژگی‌هایی مانند Pod Disruption Budgets و Pod Restarts.
• Rolling Updates & Rollbacks: به‌روزرسانی تدریجی سرویس‌ها و امکان بازگشت به نسخه قبلی.
• StatefulSets: برای مدیریت سرویس‌های با وضعیت (Stateful).
• Namespaces: برای جداسازی منابع و سیاست‌ها در محیط‌های بزرگ.
• Custom Resource Definitions (CRDs): برای افزودن منابع سفارشی به Kubernetes.

این ویژگی‌ها باعث می‌شوند Kubernetes گزینه مناسبی برای پروژه‌های پیچیده و بزرگ با نیاز به ویژگی‌های پیشرفته باشد.

---

5. ابزارهای مدیریت و مانیتورینگ

Docker Swarm

Docker Swarm ابزارهای مدیریتی و مانیتورینگ ساده‌ای را ارائه می‌دهد. این ابزارها شامل دستورات CLI مانند docker node ls و docker service ps برای نظارت بر وضعیت نودها و سرویس‌ها هستند. علاوه بر این، می‌توانید از ابزارهای شخص ثالث برای مانیتورینگ استفاده کنید.

Kubernetes

Kubernetes دارای مجموعه‌ای از ابزارهای پیشرفته برای مانیتورینگ و مدیریت است. ابزارهایی مانند kubectl (CLI)، Kubernetes Dashboard (داشبورد گرافیکی)، Prometheus و Grafana برای جمع‌آوری و تجزیه‌وتحلیل متریک‌ها و وضعیت کلاستر استفاده می‌شوند. Kubernetes همچنین از قابلیت‌های مدیریت وضعیت و نظارت پیشرفته‌تری برخوردار است.

---

6. جامعه و پشتیبانی

Docker Swarm

Docker Swarm از جامعه و مستندات رسمی Docker پشتیبانی می‌کند. با این حال، جامعه آن نسبت به Kubernetes کوچکتر است و منابع آموزشی و پشتیبانی آن محدودتر می‌باشد.

Kubernetes

Kubernetes یک جامعه گسترده و فعال دارد و مستندات رسمی آن به‌طور مداوم به‌روزرسانی می‌شوند. این ابزار به دلیل پیچیدگی‌هایش، منابع آموزشی فراوانی دارد و بسیاری از سازمان‌ها و افراد به‌طور فعال در حال گسترش و پشتیبانی از آن هستند.

---

جمع‌بندی

در نهایت، انتخاب بین Docker Swarm و Kubernetes به نیازها و پیچیدگی‌های پروژه بستگی دارد:

• Docker Swarm: برای پروژه‌های کوچکتر و ساده‌تر مناسب است که نیاز به راه‌حل سریع و ساده دارند.
• Kubernetes: برای پروژه‌های بزرگ‌تر و پیچیده‌تر که نیاز به مقیاس‌پذیری، قابلیت‌های پیشرفته و ابزارهای مانیتورینگ دقیق دارند، گزینه بهتری است.

با در نظر گرفتن این نکات، می‌توانید تصمیم بگیرید که کدام ابزار برای نیازهای خاص شما مناسب‌تر است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ادغام Swarm با CI/CD Pipelines” subtitle=”توضیحات کامل”]یکی از بهترین راه‌ها برای بهره‌برداری از Docker Swarm در پروژه‌های تولیدی، ادغام آن با فرآیندهای CI/CD (Continuous Integration/Continuous Delivery) است. این ادغام به تیم‌های توسعه این امکان را می‌دهد که فرآیندهای استقرار و به‌روزرسانی برنامه‌ها را به‌طور خودکار و بهینه‌تری مدیریت کنند. در این بخش، به نحوه ادغام Docker Swarm با CI/CD Pipelines پرداخته می‌شود و دستورالعمل‌ها و مراحل ضروری برای این ادغام به طور مفصل توضیح داده می‌شود.

---

1. مفاهیم پایه‌ای CI/CD و Docker Swarm

قبل از شروع به ادغام، بهتر است مفاهیم CI/CD و Docker Swarm را مرور کنیم:

• CI (Continuous Integration): فرآیندی است که در آن توسعه‌دهندگان به طور مرتب کدهای خود را به یک مخزن مشترک (مثل GitHub یا GitLab) منتقل می‌کنند. سپس این کدها به‌طور خودکار تست شده و در صورتی که تست‌ها موفق باشند، به محیط‌های مختلف برای استقرار (Deployment) منتقل می‌شوند.
• CD (Continuous Delivery / Continuous Deployment): فرآیند اتوماتیک‌سازی استقرار نرم‌افزار است. Continuous Delivery به معنای استقرار خودکار به محیط‌های آزمایشی و تولید است، اما در برخی موارد نیاز به تایید دستی برای استقرار نهایی وجود دارد. در Continuous Deployment، استقرار نرم‌افزار به صورت کاملاً خودکار انجام می‌شود.
• Docker Swarm: یک ابزار اورکستراسیون برای مدیریت کانتینرهای Docker است که برای مقیاس‌پذیری، دسترس‌پذیری بالا و مدیریت سرویس‌ها در کلاستر طراحی شده است.

---

2. مراحل ادغام Docker Swarm با CI/CD Pipelines

برای ادغام Docker Swarm با CI/CD Pipeline، معمولاً از ابزارهایی مانند GitLab CI، Jenkins، CircleCI و GitHub Actions استفاده می‌شود. در اینجا، مراحل کلی ادغام Docker Swarm با CI/CD Pipeline آورده شده است.

---

2.1. راه‌اندازی محیط CI/CD

اولین مرحله در ادغام، راه‌اندازی محیط CI/CD است که ممکن است شامل انتخاب ابزار CI/CD مناسب و پیکربندی آن برای پروژه شما باشد. برخی از ابزارهای محبوب برای ایجاد CI/CD Pipeline شامل موارد زیر است:

• GitLab CI: یک سیستم CI/CD که به طور کامل با GitLab یکپارچه است.
• Jenkins: یک ابزار رایگان و منبع‌باز برای خودکارسازی فرایندهای توسعه است.
• GitHub Actions: ابزاری برای خودکارسازی فرایندها در GitHub است.
• CircleCI: یک ابزار CI/CD مبتنی بر ابر که پیکربندی آن ساده است.

پس از انتخاب ابزار، شما باید یک pipeline ایجاد کنید که مراحل مختلف ساخت، تست، و استقرار را در آن تعریف کنید. به عنوان مثال، برای Jenkins یک فایل Jenkinsfile خواهید داشت که مراحل مختلف را مشخص می‌کند.

---

2.2. پیکربندی Docker و Docker Swarm در Pipeline

در این مرحله، باید مطمئن شوید که Docker و Docker Swarm روی سیستم‌های CI/CD نصب شده‌اند. برای این کار، می‌توانید مراحل زیر را انجام دهید:

1. نصب Docker در محیط CI/CD:
   • ابتدا، برای اجرای Docker روی ماشین CI، باید Docker را نصب کنید. برای مثال، برای نصب Docker در Jenkins، باید اطمینان حاصل کنید که ماشین Jenkins به Docker دسترسی دارد.

   sudo apt-get update
   sudo apt-get install -y docker.io
   

2. اتصال به Docker Swarm:
   • پس از نصب Docker، شما باید به کلاستر Docker Swarm متصل شوید. برای این کار باید از دستور docker swarm init در نود Manager استفاده کنید یا دستور docker swarm join را برای Worker Nodeها اجرا کنید.
   • در CI/CD Pipeline، می‌توانید از دستورات زیر برای اتصال خودکار به کلاستر Docker Swarm استفاده کنید.

   docker swarm join --token <swarm-token> <manager-ip>:<port>
   

3. پیکربندی Dockerfile:
   • برای ساخت کانتینرها، شما نیاز به یک فایل Dockerfile دارید که نحوه ساخت اپلیکیشن و کانتینر شما را مشخص می‌کند. این فایل باید در مخزن گیت شما قرار داشته باشد تا در فرآیند CI/CD در دسترس باشد.

   نمونه‌ای از Dockerfile:

   FROM node:14
   WORKDIR /app
   COPY . .
   RUN npm install
   EXPOSE 8080
   CMD ["npm", "start"]
   

---

2.3. مراحل در Pipeline CI/CD

حالا که محیط CI/CD و Docker Swarm راه‌اندازی شده‌اند، نوبت به تعریف مراحل Pipeline می‌رسد. در اینجا، به‌طور معمول از مراحل زیر استفاده می‌شود:

1. ساخت (Build):
   • در این مرحله، Pipeline به طور خودکار از کدهای موجود در مخزن گیت، یک Docker image می‌سازد.

   برای این کار، می‌توانید از دستور زیر برای ساخت Docker image استفاده کنید:

   docker build -t <image-name>:<tag> .
   

2. تست (Test):
   • در این مرحله، می‌توانید تست‌هایی مانند Unit Tests و Integration Tests را اجرا کنید. این تست‌ها معمولاً در مراحل اولیه pipeline انجام می‌شوند تا اطمینان حاصل کنید که تغییرات در کد باعث ایجاد خطا نمی‌شوند.
3. Push به Docker Registry:
   • پس از ساخت Docker image، باید آن را به یک Docker Registry (مثل Docker Hub یا GitLab Container Registry) ارسال کنید.

   docker push <image-name>:<tag>
   

4. استقرار (Deploy):
   • در این مرحله، Docker Swarm وارد عمل می‌شود. شما باید از دستوراتی مانند docker stack deploy برای استقرار سرویس‌ها و استک‌ها در کلاستر Docker Swarm استفاده کنید.

   مثال:

   docker stack deploy -c docker-compose.yml <stack-name>
   

   این دستور سرویس‌ها را به‌طور خودکار در کلاستر Docker Swarm راه‌اندازی می‌کند.

---

2.4. پیاده‌سازی استقرار خودکار (Auto-Deployment)

یکی از مهم‌ترین جنبه‌های ادغام Swarm با CI/CD این است که فرآیند استقرار باید به‌طور خودکار انجام شود. پس از این که Docker image به Docker Registry ارسال شد، شما می‌توانید از CI/CD ابزار خود برای پیاده‌سازی استقرار خودکار استفاده کنید.

در مرحله استقرار، Docker Swarm به شما این امکان را می‌دهد که به‌طور خودکار به‌روزرسانی‌ها را روی نودهای کلاستر اعمال کنید. این کار را می‌توان با استفاده از Rolling Updates انجام داد.

برای مثال، در Jenkins یا GitLab CI، می‌توانید یک اسکریپت برای انجام Rolling Update به صورت خودکار تنظیم کنید:

docker service update --image <new-image>:<new-tag> <service-name>

این دستور باعث می‌شود که نسخه جدید از کانتینر به‌طور خودکار بر روی کلاستر Swarm اعمال شود.

---

3. مزایای ادغام Docker Swarm با CI/CD

1. اتوماتیک‌سازی استقرار: استقرار و به‌روزرسانی‌ها به صورت خودکار انجام می‌شود، که باعث کاهش خطاهای انسانی و زمان استقرار می‌شود.
2. استقرار بدون وقفه: با استفاده از Rolling Updates، شما می‌توانید تغییرات را بدون ایجاد وقفه در سرویس‌های در حال اجرا اعمال کنید.
3. مدیریت مقیاس‌پذیری: Swarm به راحتی به شما این امکان را می‌دهد که تعداد نودهای کلاستر را بر اساس نیاز تغییر دهید.
4. اطمینان از پایداری: با توجه به اینکه Docker Swarm به صورت خودکار وضعیت سرویس‌ها را بررسی می‌کند، شما می‌توانید از پایداری سیستم اطمینان حاصل کنید.
5. انعطاف‌پذیری بیشتر: استفاده از Docker Swarm در کنار CI/CD به شما این امکان را می‌دهد که به راحتی سرویس‌ها را تست، به‌روزرسانی و مقیاس‌پذیر کنید.

---

جمع‌بندی

ادغام Docker Swarm با CI/CD Pipelines یک روش موثر و قدرتمند برای خودکارسازی استقرار و به‌روزرسانی‌های نرم‌افزار در پروژه‌های تولیدی است. این فرآیند از طریق ساخت، تست و استقرار خودکار به تیم‌های توسعه این امکان را می‌دهد که به‌طور مداوم تغییرات را وارد محیط‌های تولیدی کنند، بدون اینکه خطاهای انسانی وارد فرآیند شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از ابزارهایی مانند Portainer برای مدیریت گرافیکی کلاسترهای Swarm” subtitle=”توضیحات کامل”]در کلاسترهای Docker Swarm، مدیریت و نظارت بر وضعیت نودها، سرویس‌ها و استک‌ها از طریق دستورات CLI امکان‌پذیر است. اما برای بسیاری از کاربران، کار با خط فرمان ممکن است پیچیده و زمان‌بر باشد. به همین دلیل، ابزارهای گرافیکی مانند Portainer توسعه یافته‌اند تا به کاربران این امکان را بدهند که کلاسترهای Swarm خود را از طریق یک رابط کاربری گرافیکی (GUI) ساده و راحت‌تر مدیریت کنند.

Portainer یک ابزار محبوب و منبع باز برای مدیریت و نظارت بر Docker است که از قابلیت‌های Docker Swarm نیز پشتیبانی می‌کند. این ابزار به شما این امکان را می‌دهد که کلاسترهای Docker Swarm خود را از طریق یک رابط وب گرافیکی مدیریت کرده و با استفاده از آن، نودها، سرویس‌ها، شبکه‌ها، و حجم‌ها (Volumes) را به‌راحتی کنترل کنید.

در این بخش، به شرح چگونگی نصب، راه‌اندازی، و استفاده از Portainer برای مدیریت Docker Swarm پرداخته خواهد شد.

---

1. نصب و راه‌اندازی Portainer

قبل از هر چیز، شما باید Portainer را نصب کنید. نصب این ابزار به‌سادگی و با استفاده از Docker امکان‌پذیر است. مراحل نصب Portainer به شرح زیر است:

1.1. نصب Portainer روی یک نود Manager در کلاستر Docker Swarm

برای نصب Portainer، شما ابتدا باید یک کانتینر Docker برای آن راه‌اندازی کنید. بهترین روش نصب این ابزار استفاده از Docker Compose است تا بتوانید به‌راحتی آن را روی کلاستر Docker Swarm اجرا کنید.

1. ساخت سرویس Portainer با استفاده از Docker Compose:ابتدا فایل docker-compose.yml را ایجاد کرده و محتوای زیر را در آن قرار دهید:

   version: "3.7"
   services:
     portainer:
       image: portainer/portainer-ce:latest
       volumes:
         - /var/run/docker.sock:/var/run/docker.sock
         - portainer_data:/data
       networks:
         - portainer
       ports:
         - "9000:9000"
       deploy:
         replicas: 1
         placement:
           constraints: [node.role == manager]
   networks:
     portainer:
       driver: overlay
   volumes:
     portainer_data:
   

   این فایل docker-compose.yml پیکربندی برای راه‌اندازی Portainer را در Docker Swarm تعریف می‌کند:

   • volume: /var/run/docker.sock:/var/run/docker.sock اجازه می‌دهد Portainer به Docker API دسترسی داشته باشد.
   • ports: پورت 9000 به رابط وب Portainer اختصاص داده شده است.
   • replicas: تعداد کانتینرهای Portainer مشخص شده است (در اینجا یک نمونه از آن).
   • placement: این بخش مشخص می‌کند که Portainer تنها روی نودهای با نقش manager اجرا شود.
   • overlay network: شبکه‌ای برای ارتباطات داخلی بین نودها در کلاستر.
2. راه‌اندازی سرویس با استفاده از Docker Compose:در دایرکتوری‌ای که فایل docker-compose.yml را ذخیره کرده‌اید، دستور زیر را برای استقرار سرویس اجرا کنید:

   docker stack deploy -c docker-compose.yml portainer
   

   این دستور، سرویس Portainer را در کلاستر Docker Swarm شما راه‌اندازی می‌کند.

---

1.2. دسترسی به Portainer از طریق وب‌سایت

پس از راه‌اندازی سرویس Portainer، می‌توانید از طریق مرورگر وب به رابط گرافیکی Portainer دسترسی پیدا کنید. برای این کار، آدرس IP نود Manager و پورت 9000 را وارد کنید:

http://<manager-node-ip>:9000

در اولین بار ورود به Portainer، از شما خواسته می‌شود تا یک رمز عبور برای اکانت مدیر (admin) تنظیم کنید. پس از این تنظیم، وارد داشبورد Portainer خواهید شد که شامل تمام اطلاعات و کنترل‌های مربوط به Docker Swarm است.

---

2. مدیریت کلاستر Swarm با Portainer

Portainer به شما این امکان را می‌دهد که کلاستر Docker Swarm خود را از طریق یک رابط گرافیکی ساده و کاربرپسند مدیریت کنید. در ادامه به برخی از ویژگی‌های اصلی این ابزار و نحوه استفاده از آن در کلاستر Docker Swarm پرداخته می‌شود.

2.1. مدیریت نودها

در داشبورد Portainer، بخش‌های مختلفی برای مدیریت کلاستر وجود دارد. یکی از آن‌ها بخش Nodes است که به شما امکان می‌دهد نودهای Swarm را مشاهده و مدیریت کنید. این بخش اطلاعاتی مانند وضعیت، نقش (Manager یا Worker) و وضعیت سلامت نودها را نشان می‌دهد.

برای مشاهده نودها:

1. از منوی سمت چپ، گزینه Nodes را انتخاب کنید.
2. در این بخش، تمامی نودهای Swarm به نمایش درمی‌آیند. شما می‌توانید اطلاعات دقیقی در مورد هر نود مشاهده کرده و عملیات مختلفی از جمله برداشتن نود، اضافه کردن نود جدید و بررسی وضعیت آن‌ها انجام دهید.

2.2. مدیریت سرویس‌ها

Portainer به شما این امکان را می‌دهد که سرویس‌ها را به‌راحتی ایجاد، حذف و پیکربندی کنید. برای مشاهده و مدیریت سرویس‌ها در کلاستر Docker Swarm، از بخش Services استفاده کنید.

1. از منوی سمت چپ، گزینه Services را انتخاب کنید.
2. در این بخش، تمام سرویس‌های Swarm شما همراه با اطلاعاتی مانند تعداد Replica‌ها، وضعیت سلامت و نودهایی که سرویس‌ها بر روی آن‌ها در حال اجرا هستند، نمایش داده می‌شوند.
3. شما می‌توانید سرویس‌های جدید ایجاد کرده و تنظیمات آن‌ها را تغییر دهید، تعداد Replica‌ها را افزایش یا کاهش دهید، و حتی سرویس‌ها را به‌طور کامل حذف کنید.

2.3. بررسی لاگ‌ها و سلامت سرویس‌ها

Portainer این امکان را به شما می‌دهد که لاگ‌های سرویس‌ها را مشاهده کرده و وضعیت سلامت آن‌ها را بررسی کنید. این ویژگی برای عیب‌یابی و نظارت بر عملکرد سرویس‌ها بسیار مهم است.

1. برای مشاهده لاگ‌ها، ابتدا روی سرویس مورد نظر کلیک کنید.
2. از تب‌های موجود، گزینه Logs را انتخاب کنید تا لاگ‌های سرویس به نمایش درآید.
3. در بخش Health, وضعیت سلامت سرویس‌ها و نودها نمایش داده می‌شود که نشان می‌دهد آیا سرویس‌ها به درستی کار می‌کنند یا خیر.

2.4. مدیریت شبکه‌ها و حجم‌ها (Volumes)

Portainer همچنین به شما این امکان را می‌دهد که شبکه‌ها و حجم‌ها را در کلاستر Docker Swarm مدیریت کنید. برای مدیریت حجم‌ها و شبکه‌ها، از منوی سمت چپ گزینه‌های Volumes و Networks را انتخاب کنید.

• Volumes: در این بخش می‌توانید حجم‌های Docker را ایجاد، حذف یا پیکربندی کنید. این بخش برای مدیریت داده‌های پایدار که به‌طور مستقیم به سرویس‌ها متصل هستند مفید است.
• Networks: شما می‌توانید شبکه‌های Docker Overlay را برای ارتباط سرویس‌ها در کلاستر پیکربندی کرده و مدیریت کنید.

---

3. مزایای استفاده از Portainer برای مدیریت Docker Swarm

1. رابط گرافیکی ساده: Portainer یک رابط کاربری ساده و جذاب دارد که استفاده از آن را برای کاربران تازه‌کار نیز آسان می‌کند.
2. مدیریت ساده سرویس‌ها و نودها: شما می‌توانید به راحتی نودها و سرویس‌ها را در کلاستر خود مدیریت کنید.
3. نظارت بر سلامت سرویس‌ها: مشاهده وضعیت سلامت سرویس‌ها و نودها به شما این امکان را می‌دهد که مشکلات را سریع‌تر شناسایی و حل کنید.
4. ادغام با سایر ابزارها: Portainer به خوبی با Docker و Docker Swarm ادغام شده و به‌راحتی می‌توانید آن را در پروژه‌های خود استفاده کنید.

---

جمع‌بندی

Portainer ابزار قدرتمندی برای مدیریت گرافیکی کلاسترهای Docker Swarm است که فرآیند مدیریت سرویس‌ها، نودها، شبکه‌ها و حجم‌ها را به‌طور قابل توجهی ساده‌تر می‌کند. با استفاده از این ابزار، می‌توانید به راحتی وضعیت کلاستر خود را بررسی کنید و عملیات مختلفی مانند استقرار سرویس‌ها، به‌روزرسانی‌ها، بررسی لاگ‌ها و مدیریت شبکه‌ها را انجام دهید.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 2. ایجاد، مدیریت و رجیستری ایمیج (Image Creation, Management, and Registry)”][cdb_course_lesson title=”فصل 1. نوشتن و ایجاد Dockerfile”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”دستورات پایه مانند FROM, RUN, CMD, ENTRYPOINT, COPY, WORKDIR, و غیره” subtitle=”توضیحات کامل”]Dockerfile یک فایل متنی است که شامل مجموعه‌ای از دستورات برای ایجاد یک ایمیج داکر (Docker Image) است. با استفاده از این فایل، می‌توان محیطی مشخص را برای اجرای برنامه‌ها به صورت کانتینریزه تعریف کرد.

در این بخش، به بررسی ساختار Dockerfile و دستورات پایه‌ای آن پرداخته می‌شود.

---

ساختار کلی Dockerfile

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

مثال یک Dockerfile ساده:

# تعیین ایمیج پایه
FROM ubuntu:latest

# تنظیم دایرکتوری کاری
WORKDIR /app

# کپی فایل‌های پروژه به داخل کانتینر
COPY . .

# اجرای دستورات مورد نیاز برای نصب وابستگی‌ها
RUN apt-get update && apt-get install -y curl

# تعیین دستور پیش‌فرض برای اجرای کانتینر
CMD ["echo", "Hello, Docker!"]

این فایل یک ایمیج بر پایه Ubuntu ایجاد کرده و سپس برخی از وابستگی‌ها را نصب می‌کند. در ادامه، به بررسی دستورات مختلف در Dockerfile پرداخته خواهد شد.

---

دستورات پایه در Dockerfile

۱. FROM – تعیین ایمیج پایه

دستور FROM اولین و مهم‌ترین دستور در یک Dockerfile است. این دستور مشخص می‌کند که ایمیج نهایی بر پایه کدام ایمیج اصلی (Base Image) ساخته شود.

مثال:

FROM node:16

این دستور یک ایمیج بر پایه Node.js نسخه ۱۶ می‌سازد.

---

۲. WORKDIR – تنظیم دایرکتوری کاری

دستور WORKDIR مسیر دایرکتوری‌ای که دستورات بعدی در آن اجرا خواهند شد را مشخص می‌کند.

مثال:

WORKDIR /usr/src/app

این دستور مشخص می‌کند که دایرکتوری /usr/src/app به عنوان دایرکتوری کاری در کانتینر تنظیم شود.

---

۳. COPY – کپی فایل‌ها از سیستم میزبان به داخل کانتینر

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

مثال:

COPY app.py /app/

در این مثال، فایل app.py از سیستم میزبان به مسیر /app/ درون کانتینر کپی می‌شود.

کپی کل دایرکتوری:

COPY . /usr/src/app

این دستور تمام فایل‌های موجود در دایرکتوری پروژه را به مسیر /usr/src/app داخل کانتینر کپی می‌کند.

---

۴. ADD – اضافه کردن فایل‌ها همراه با قابلیت استخراج آرشیوها

دستور ADD مانند COPY است، اما علاوه بر کپی فایل‌ها، می‌تواند فایل‌های فشرده (ZIP, TAR, GZ) را مستقیماً استخراج کند.

مثال:

ADD my_archive.tar.gz /app/

این دستور فایل my_archive.tar.gz را به دایرکتوری /app/ درون کانتینر اضافه کرده و استخراج می‌کند.

---

۵. RUN – اجرای دستورات در زمان ساخت ایمیج

دستور RUN برای اجرای دستورات در حین ساخت ایمیج استفاده می‌شود. این دستورات معمولاً شامل نصب وابستگی‌ها، ایجاد فایل‌ها، تنظیمات محیطی و غیره هستند.

مثال:

RUN apt-get update && apt-get install -y python3

این دستور Python 3 را در حین ساخت ایمیج نصب می‌کند.

استفاده از چندین دستور RUN:

RUN apt-get update \
    && apt-get install -y curl \
    && apt-get clean

در این مثال، چند دستور به‌صورت زنجیره‌ای اجرا می‌شوند تا تعداد لایه‌های ایمیج کاهش یابد.

---

۶. CMD – تعیین دستور پیش‌فرض اجرا هنگام اجرای کانتینر

دستور CMD برای مشخص کردن دستور پیش‌فرضی که هنگام اجرای کانتینر اجرا می‌شود استفاده می‌شود.

مثال:

CMD ["python3", "app.py"]

این دستور هنگام اجرای کانتینر، فایل app.py را با استفاده از Python 3 اجرا می‌کند.

تفاوت CMD و RUN:

• RUN در زمان ساخت ایمیج اجرا می‌شود.
• CMD در زمان اجرای کانتینر اجرا می‌شود.

---

۷. ENTRYPOINT – تعیین یک نقطه ورود ثابت برای کانتینر

دستور ENTRYPOINT مشابه CMD است، اما نمی‌توان آن را در زمان اجرای کانتینر تغییر داد مگر با استفاده از گزینه --entrypoint.

مثال:

ENTRYPOINT ["nginx", "-g", "daemon off;"]

این دستور باعث می‌شود Nginx همیشه هنگام اجرای کانتینر اجرا شود.

تفاوت CMD و ENTRYPOINT:

• CMD را می‌توان هنگام اجرای کانتینر بازنویسی کرد.
• ENTRYPOINT را نمی‌توان به راحتی تغییر داد.

ترکیب ENTRYPOINT و CMD:

ENTRYPOINT ["python3"]
CMD ["app.py"]

در این مثال، اگر هنگام اجرای کانتینر آرگومانی ندهیم، app.py اجرا می‌شود. اما اگر بخواهیم اسکریپت دیگری اجرا کنیم، می‌توانیم هنگام اجرای کانتینر آن را مشخص کنیم:

docker run my_image other_script.py

---

۸. ENV – تنظیم متغیرهای محیطی

دستور ENV متغیرهای محیطی را درون کانتینر تنظیم می‌کند.

مثال:

ENV APP_ENV=production

در این مثال، متغیر APP_ENV مقدار production خواهد داشت.

---

۹. EXPOSE – باز کردن پورت برای ارتباطات خارجی

دستور EXPOSE مشخص می‌کند که کانتینر روی چه پورتی گوش دهد، اما این دستور به‌تنهایی کافی نیست و باید هنگام اجرای کانتینر، پورت را publish کنیم.

مثال:

EXPOSE 80

این دستور مشخص می‌کند که کانتینر روی پورت ۸۰ آماده پذیرش درخواست‌ها خواهد بود.

اجرای کانتینر با پورت مشخص:

docker run -p 8080:80 my_image

---

جمع‌بندی

در این فصل، ساختار کلی Dockerfile و دستورات اصلی آن بررسی شد. این دستورات شامل:

• FROM: تعیین ایمیج پایه
• WORKDIR: تنظیم دایرکتوری کاری
• COPY و ADD: کپی و اضافه کردن فایل‌ها
• RUN: اجرای دستورات در زمان ساخت ایمیج
• CMD و ENTRYPOINT: تعیین دستور پیش‌فرض اجرا
• ENV: تنظیم متغیرهای محیطی
• EXPOSE: باز کردن پورت

در قسمت های بعدی، به بهینه‌سازی Dockerfile و مدیریت بهتر ایمیج‌ها پرداخته خواهد شد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از چندین مرحله در ساخت ایمیج (Multi-Stage Builds) برای بهینه‌سازی” subtitle=”توضیحات کامل”]Docker Multi-Stage Builds یکی از بهترین روش‌ها برای کاهش حجم ایمیج‌های داکر و افزایش کارایی در زمان ساخت است. در این روش، می‌توان از چندین مرحله (Stage) برای ایجاد یک ایمیج استفاده کرد و در نهایت فقط فایل‌های ضروری را به مرحله‌ی نهایی انتقال داد. این کار باعث می‌شود ایمیج نهایی سبک‌تر شده و وابستگی‌های غیرضروری حذف شوند.

---

چرا از Multi-Stage Builds استفاده کنیم؟

• کاهش حجم ایمیج نهایی: تمام فایل‌های اضافی و وابستگی‌های موقت که در مراحل اولیه ساخت ایمیج استفاده شده‌اند، در خروجی نهایی حذف می‌شوند.
• بهبود امنیت و کارایی: از آنجا که فقط فایل‌های لازم در ایمیج نهایی قرار می‌گیرند، احتمال وجود کدهای مخرب و آسیب‌پذیری‌های امنیتی کاهش می‌یابد.
• افزایش سرعت Build و Deployment: حذف وابستگی‌های اضافی باعث کاهش زمان Pull و Push ایمیج‌های داکر می‌شود.

---

نحوه پیاده‌سازی Multi-Stage Builds

برای درک بهتر این موضوع، یک مثال عملی را بررسی می‌کنیم. فرض کنیم که قصد داریم یک برنامه‌ی Go را در یک کانتینر اجرا کنیم. بدون Multi-Stage Builds، ابتدا باید تمام ابزارهای لازم برای کامپایل برنامه را داخل ایمیج قرار دهیم و سپس برنامه را اجرا کنیم. اما در روش Multi-Stage، می‌توانیم کامپایل برنامه را در یک مرحله جداگانه انجام داده و فقط فایل اجرایی نهایی را به ایمیج اصلی انتقال دهیم.

نمونه‌ی Dockerfile با Multi-Stage Builds

# مرحله‌ی اول: Build
FROM golang:1.20 AS builder

# تنظیم مسیر کاری
WORKDIR /app

# کپی فایل‌های پروژه
COPY . .

# کامپایل برنامه
RUN go build -o myapp

# مرحله‌ی دوم: اجرای برنامه در یک ایمیج سبک‌تر
FROM alpine:latest  

WORKDIR /root/

# فقط باینری کامپایل‌شده را کپی می‌کنیم
COPY --from=builder /app/myapp .

# اجرای برنامه
CMD ["./myapp"]

---

بررسی بخش‌های مهم Dockerfile

1. مرحله‌ی اول (builder)
   • در این مرحله از ایمیج golang:1.20 استفاده شده که حاوی ابزارهای لازم برای کامپایل برنامه‌ی Go است.
   • کدهای برنامه به مسیر /app کپی شده‌اند.
   • سپس با استفاده از go build فایل اجرایی ساخته شده است.
2. مرحله‌ی دوم (اجرای نهایی)
   • از یک ایمیج سبک مانند alpine:latest استفاده شده که فقط شامل فایل‌های ضروری است.
   • باینری خروجی از مرحله‌ی قبل به این ایمیج منتقل شده است.
   • در نهایت، فقط فایل اجرایی myapp اجرا می‌شود.

---

مقایسه حجم ایمیج‌ها قبل و بعد از Multi-Stage Builds

اگر برنامه را بدون Multi-Stage Builds اجرا کنیم (یعنی مستقیماً در ایمیج golang)، حجم ایمیج نهایی حدود ۱ گیگابایت خواهد بود. اما با استفاده از Multi-Stage Builds و ایمیج سبک alpine، حجم ایمیج نهایی حدود ۵ مگابایت می‌شود.

بررسی حجم ایمیج قبل و بعد از Multi-Stage

docker images | grep myapp

قبل از Multi-Stage Builds:

golang-app      latest       1.01GB

بعد از Multi-Stage Builds:

myapp           latest       5MB

---

استفاده از Multi-Stage برای برنامه‌های دیگر

این روش فقط مخصوص Go نیست و می‌توان آن را برای زبان‌های دیگر نیز به کار برد. به عنوان مثال، در یک پروژه‌ی Node.js می‌توان ابتدا فایل‌های وابستگی را در یک مرحله نصب کرد و سپس فقط کدهای اجرایی را به ایمیج نهایی انتقال داد.

نمونه‌ی Dockerfile برای Node.js با Multi-Stage Builds

# مرحله‌ی اول: Build
FROM node:18 AS builder
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
RUN npm run build

# مرحله‌ی دوم: اجرای برنامه در یک ایمیج سبک‌تر
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

در این مثال:

• وابستگی‌ها در مرحله‌ی اول نصب می‌شوند.
• فقط فایل‌های کامپایل‌شده و ماژول‌های ضروری به ایمیج سبک node:18-alpine منتقل می‌شوند.

---

بررسی و تست ایمیج ساخته‌شده

پس از نوشتن Dockerfile، باید ایمیج را بسازیم و تست کنیم.

ساخت ایمیج Docker

docker build -t myapp .

اجرای کانتینر ساخته‌شده

docker run --rm myapp

بررسی حجم ایمیج ساخته‌شده

docker images | grep myapp

---

جمع‌بندی

• Multi-Stage Builds یک تکنیک برای بهینه‌سازی حجم ایمیج‌های داکر است.
• با استفاده از مراحل جداگانه می‌توان ابزارهای غیرضروری را از ایمیج نهایی حذف کرد.
• این روش علاوه بر کاهش حجم، باعث افزایش امنیت و بهبود عملکرد نیز می‌شود.
• این روش برای زبان‌های مختلف مانند Go، Node.js، Python و … قابل استفاده است.
• پس از ایجاد ایمیج، می‌توان آن را تست و اجرا کرد.

با این روش، ایمیج‌های داکر سبک‌تر و سریع‌تر ساخته می‌شوند، که در محیط‌های Production بسیار مهم است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بهینه‌سازی Dockerfile: کاهش تعداد لایه‌ها” subtitle=”توضیحات کامل”]یکی از نکات مهم در بهینه‌سازی Dockerfile، کاهش تعداد لایه‌ها (Layers) است. هر دستور در Dockerfile یک لایه مجزا در ایمیج نهایی ایجاد می‌کند و تعداد زیاد لایه‌ها باعث افزایش حجم ایمیج و کاهش سرعت ساخت و اجرای کانتینرها می‌شود. در این بخش، نحوه کاهش تعداد لایه‌ها برای بهینه‌سازی ایمیج‌های Docker را بررسی می‌کنیم.

---

چرا کاهش تعداد لایه‌ها مهم است؟

۱. کاهش حجم ایمیج: تعداد زیاد لایه‌ها باعث افزایش حجم ایمیج می‌شود. با ترکیب دستورات، می‌توان لایه‌های اضافی را حذف کرد.
۲. افزایش سرعت Build و Deployment: حجم کمتر ایمیج باعث کاهش زمان Pull و Push در Registry می‌شود.
3. بهبود کارایی کش Docker: هنگام ایجاد تغییرات در Dockerfile، Docker از کش (Cache) برای سرعت بخشیدن به فرایند Build استفاده می‌کند. کاهش تعداد لایه‌ها می‌تواند به بهینه‌تر شدن کش کمک کند.
۴. بهبود امنیت و کاهش وابستگی‌ها: حذف فایل‌های غیرضروری در یک مرحله و جلوگیری از به جا ماندن آنها در لایه‌های قبلی باعث افزایش امنیت ایمیج می‌شود.

---

روش‌های کاهش تعداد لایه‌ها

۱. ترکیب دستورات RUN

هر دستور RUN یک لایه جداگانه در ایمیج ایجاد می‌کند. بنابراین بهتر است چندین دستور را با && ترکیب کنیم تا فقط یک لایه ایجاد شود.

قبل از بهینه‌سازی (لایه‌های زیاد)

FROM ubuntu:latest

RUN apt-get update
RUN apt-get install -y curl
RUN apt-get install -y vim

بعد از بهینه‌سازی (لایه کمتر)

FROM ubuntu:latest

RUN apt-get update && \
    apt-get install -y curl vim && \
    rm -rf /var/lib/apt/lists/*

✅ مزیت‌ها:

• فقط یک لایه برای نصب بسته‌ها ایجاد شده است.
• با rm -rf /var/lib/apt/lists/* فایل‌های اضافی پس از نصب پاک شده‌اند تا حجم ایمیج کاهش یابد.

---

۲. استفاده از COPY به جای ADD (در موارد غیرضروری)

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

قبل از بهینه‌سازی (استفاده از ADD غیرضروری)

ADD myapp.tar.gz /app/

بعد از بهینه‌سازی (استفاده از COPY)

COPY myapp.tar.gz /app/

✅ مزیت‌ها:

• COPY فقط یک لایه ایجاد می‌کند و سریع‌تر از ADD است.
• کاهش پیچیدگی و جلوگیری از ایجاد لایه‌های اضافی.

---

۳. ترکیب COPY و WORKDIR برای کاهش لایه‌ها

اگر در Dockerfile چندین بار از WORKDIR و COPY استفاده کنیم، می‌توان این دستورات را ترکیب کرد تا تعداد لایه‌ها کاهش یابد.

قبل از بهینه‌سازی (لایه‌های زیاد)

FROM node:18

WORKDIR /app
COPY package.json .
COPY index.js .
COPY config.json .

بعد از بهینه‌سازی (لایه کمتر)

FROM node:18

WORKDIR /app
COPY . .

✅ مزیت‌ها:

• تعداد COPY کمتر شده و فقط یک لایه برای تمام فایل‌ها ایجاد شده است.
• ساده‌تر و خواناتر شده است.

📌 نکته: اگر برخی فایل‌ها تغییرات مداوم دارند، می‌توان ابتدا package.json را کپی کرد، سپس npm install را اجرا کرد و در نهایت بقیه فایل‌ها را کپی کرد. این کار باعث استفاده بهتر از کش Docker می‌شود.

---

۴. حذف فایل‌های موقت در همان لایه

هر فایلی که در یک مرحله ساخته می‌شود، در همان مرحله نیز باید حذف شود تا در ایمیج نهایی باقی نماند. این کار با && در RUN قابل انجام است.

قبل از بهینه‌سازی (لایه‌های اضافی)

RUN wget https://example.com/file.tar.gz
RUN tar -xzf file.tar.gz
RUN rm file.tar.gz

بعد از بهینه‌سازی (لایه کمتر)

RUN wget https://example.com/file.tar.gz && \
    tar -xzf file.tar.gz && \
    rm file.tar.gz

✅ مزیت‌ها:

• کاهش تعداد لایه‌ها.
• جلوگیری از باقی ماندن فایل‌های اضافی.

---

۵. استفاده از .dockerignore برای جلوگیری از کپی فایل‌های غیرضروری

در هنگام استفاده از COPY . . ممکن است فایل‌های غیرضروری مانند فایل‌های لاگ، کش، و فایل‌های موقتی نیز وارد ایمیج شوند. این کار باعث افزایش حجم ایمیج می‌شود. برای جلوگیری از این مشکل، می‌توان از فایل .dockerignore استفاده کرد.

نمونه .dockerignore

node_modules
*.log
.git
.env
__pycache__/

✅ مزیت‌ها:

• جلوگیری از ورود فایل‌های غیرضروری به ایمیج.
• کاهش حجم و افزایش سرعت Build.

---

جمع‌بندی

✅ روش‌های کاهش تعداد لایه‌ها:

1. ترکیب دستورات RUN با استفاده از &&.
2. استفاده از COPY به جای ADD در موارد غیرضروری.
3. ترکیب COPY و WORKDIR برای کاهش تعداد لایه‌ها.
4. حذف فایل‌های موقت در همان مرحله برای جلوگیری از باقی ماندن آنها.
5. استفاده از .dockerignore برای جلوگیری از ورود فایل‌های غیرضروری.

با رعایت این نکات، می‌توان Dockerfile را بهینه کرده و ایمیج‌های سبک‌تر، سریع‌تر و کارآمدتر ایجاد کرد. 🚀[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بهینه‌سازی Dockerfile: استفاده از کش (Cache) برای کاهش زمان ساخت” subtitle=”توضیحات کامل”]کش (Cache) یکی از مهم‌ترین ویژگی‌های Docker برای بهینه‌سازی زمان ساخت ایمیج (Build Time) است. Docker به‌صورت خودکار از کش برای جلوگیری از اجرای مجدد دستورات بدون تغییر استفاده می‌کند. در این بخش، نحوه استفاده بهینه از کش را بررسی خواهیم کرد تا زمان ساخت ایمیج‌ها کاهش یابد و کارایی فرآیند CI/CD بهبود پیدا کند.

---

چرا استفاده از کش مهم است؟

✅ کاهش زمان Build: بدون کش، هر بار که دستور docker build اجرا می‌شود، تمام مراحل از ابتدا پردازش خواهند شد. با استفاده از کش، مراحل بدون تغییر از اجرای مجدد جلوگیری می‌شوند.

✅ بهینه‌سازی CI/CD Pipelines: در محیط‌های DevOps و CI/CD، هر بار که تغییری در کد ایجاد شود، باید یک ایمیج جدید ساخته شود. استفاده از کش باعث می‌شود فقط بخش‌های تغییر‌یافته پردازش شوند و سایر مراحل از کش خوانده شوند.

✅ کاهش مصرف منابع: بدون کش، هر بار تمام بسته‌ها و وابستگی‌ها مجدداً دانلود می‌شوند که باعث افزایش مصرف CPU، حافظه و پهنای باند می‌شود. با استفاده از کش، از دانلودهای اضافی جلوگیری خواهد شد.

✅ افزایش سرعت تست و توسعه: توسعه‌دهندگان می‌توانند ایمیج‌های Docker را سریع‌تر بسازند و تست کنند.

---

روش‌های بهینه‌سازی Dockerfile با استفاده از کش

۱. ترتیب صحیح دستورات برای افزایش کارایی کش

Docker دستورات Dockerfile را به‌صورت مرحله‌ای پردازش می‌کند و هر دستور یک لایه جداگانه در ایمیج ایجاد می‌کند. کش در Docker به این صورت کار می‌کند که اگر یک مرحله تغییری نکند، مراحل بعدی از کش خوانده می‌شوند. بنابراین، ترتیب صحیح دستورات بسیار مهم است.

🔹 قانون کلی: مراحل کم‌تغییر را در ابتدا و مراحل پرتغییر را در انتهای Dockerfile قرار دهید.

قبل از بهینه‌سازی (بدون کش مؤثر)

FROM node:18

WORKDIR /app

COPY . .
RUN npm install
CMD ["node", "index.js"]

✅ مشکل: هر بار که فایل‌های پروژه تغییر کنند، npm install نیز دوباره اجرا خواهد شد که باعث افزایش زمان Build می‌شود.

---

بعد از بهینه‌سازی (استفاده صحیح از کش)

FROM node:18

WORKDIR /app

COPY package.json package-lock.json ./
RUN npm install

COPY . .
CMD ["node", "index.js"]

✅ مزیت:

• تا زمانی که package.json تغییر نکند، npm install از کش خوانده می‌شود.
• فقط در صورت تغییر در کد پروژه، مرحله COPY . . اجرا می‌شود.
• زمان ساخت ایمیج به میزان قابل‌توجهی کاهش می‌یابد.

---

۲. استفاده از --cache-from برای باز استفاده از کش قبلی

در CI/CD Pipelines، معمولاً هنگام اجرای docker build، کش قبلی در دسترس نیست. برای حل این مشکل می‌توان از گزینه --cache-from استفاده کرد تا کش ایمیج قبلی بازیابی شود.

دستور استفاده از کش قبلی در docker build

docker build --cache-from myapp:latest -t myapp:latest .

✅ مزیت:

• کش از نسخه قبلی ایمیج بازیابی می‌شود و نیازی به ساخت مجدد مراحل تکراری نیست.

---

۳. استفاده از mount=type=cache در Multi-Stage Builds

در Multi-Stage Builds، می‌توان از ویژگی --mount=type=cache برای جلوگیری از دانلود مجدد بسته‌ها استفاده کرد.

نمونه استفاده در Dockerfile

# مرحله Build
FROM golang:1.18 AS builder

WORKDIR /app
COPY . .

RUN --mount=type=cache,target=/root/.cache/go-build \
    go build -o myapp

# مرحله نهایی
FROM alpine:latest
COPY --from=builder /app/myapp /usr/local/bin/myapp
CMD ["myapp"]

✅ مزیت:

• جلوگیری از دانلود مجدد وابستگی‌های Golang در هر Build.
• افزایش سرعت ساخت ایمیج در مراحل بعدی.

---

۴. استفاده از docker buildx برای بهینه‌سازی کش در معماری‌های مختلف

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

فعال کردن کش در docker buildx

docker buildx build --cache-to=type=local,dest=./cache --cache-from=type=local,src=./cache -t myapp .

✅ مزیت:

• کش به‌صورت محلی ذخیره شده و در بیلدهای بعدی استفاده می‌شود.
• مناسب برای CI/CD Pipelines و بیلدهای توزیع‌شده.

---

۵. استفاده از .dockerignore برای جلوگیری از کش غیرضروری

زمانی که از COPY . . در Dockerfile استفاده می‌کنیم، ممکن است فایل‌های غیرضروری مانند node_modules یا logs نیز وارد ایمیج شوند. برای جلوگیری از این کار، باید از .dockerignore استفاده کرد.

نمونه .dockerignore برای افزایش کارایی کش

node_modules
.git
logs
.env
__pycache__/

✅ مزیت:

• جلوگیری از تغییرات غیرضروری در کش.
• کاهش حجم و افزایش سرعت Build.

---

جمع‌بندی

✅ روش‌های بهینه‌سازی کش در Dockerfile:
1️⃣ ترتیب صحیح دستورات: ابتدا دستورات کم‌تغییر و سپس پرتغییر.
2️⃣ استفاده از --cache-from برای باز استفاده از کش قبلی در CI/CD Pipelines.
3️⃣ بهره‌گیری از mount=type=cache در Multi-Stage Builds برای جلوگیری از دانلود مجدد.
4️⃣ استفاده از docker buildx برای کش پیشرفته.
5️⃣ افزودن .dockerignore برای جلوگیری از ورود فایل‌های غیرضروری به ایمیج.

✅ نتیجه:
با رعایت این نکات، می‌توان زمان ساخت ایمیج‌ها را کاهش داد، کارایی سیستم را بهبود بخشید و هزینه‌های منابع را کاهش داد. 🚀[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بهینه‌سازی Dockerfile: حذف فایل‌های غیرضروری پس از ساخت” subtitle=”توضیحات کامل”]یکی از روش‌های مهم برای کاهش حجم ایمیج‌های Docker، حذف فایل‌های غیرضروری پس از ساخت است. فایل‌هایی مانند بسته‌های موقت، کش‌ها، لاگ‌ها و وابستگی‌های اضافی می‌توانند حجم ایمیج را افزایش داده و عملکرد آن را کاهش دهند. در این بخش، روش‌های مختلف برای حذف این فایل‌ها و بهینه‌سازی Dockerfile را بررسی می‌کنیم.

---

چرا حذف فایل‌های غیرضروری اهمیت دارد؟

✅ کاهش حجم ایمیج: هرچه ایمیج سبک‌تر باشد، سریع‌تر دانلود و اجرا می‌شود.

✅ افزایش سرعت اجرای کانتینرها: کانتینرهایی که از ایمیج‌های سبک ساخته می‌شوند، سریع‌تر اجرا شده و کارایی بهتری دارند.

✅ کاهش هزینه‌های ذخیره‌سازی و انتقال: ایمیج‌های بزرگ‌تر پهنای باند بیشتری مصرف می‌کنند و هزینه‌های ذخیره‌سازی را افزایش می‌دهند.

✅ افزایش امنیت: حذف فایل‌های غیرضروری می‌تواند نقاط حمله احتمالی را کاهش دهد.

---

روش‌های حذف فایل‌های غیرضروری در Dockerfile

۱. حذف کش بسته‌ها و وابستگی‌ها

زمانی که بسته‌هایی مانند apt-get، yum یا apk را نصب می‌کنید، این ابزارها فایل‌های کش و متادیتا را ذخیره می‌کنند. حذف این کش‌ها باعث کاهش حجم ایمیج می‌شود.

قبل از بهینه‌سازی (بدون حذف کش‌ها)

FROM ubuntu:latest

RUN apt-get update && apt-get install -y \
    curl \
    wget \
    vim

✅ مشکل:

• این روش کش بسته‌های دانلود شده را حفظ می‌کند که باعث افزایش حجم ایمیج می‌شود.

---

بعد از بهینه‌سازی (با حذف کش‌ها)

FROM ubuntu:latest

RUN apt-get update && apt-get install -y \
    curl \
    wget \
    vim \
    && rm -rf /var/lib/apt/lists/*

✅ مزیت:

• با حذف /var/lib/apt/lists/*، فضای ذخیره‌سازی آزاد شده و حجم ایمیج کاهش می‌یابد.

---

۲. ترکیب دستورات RUN برای جلوگیری از ایجاد لایه‌های اضافی

هر دستور RUN یک لایه جدید در ایمیج Docker ایجاد می‌کند. اگر فایل‌های غیرضروری را در یک RUN جداگانه حذف کنیم، این فایل‌ها در لایه‌های قبلی باقی خواهند ماند. بهترین روش، ترکیب دستورات RUN در یک خط است.

قبل از بهینه‌سازی (حذف فایل‌ها در یک مرحله جداگانه – غیربهینه)

FROM ubuntu:latest

RUN apt-get update && apt-get install -y curl wget vim
RUN rm -rf /var/lib/apt/lists/*

✅ مشکل:

• کش apt در لایه‌ای ذخیره شده و همچنان در ایمیج باقی می‌ماند.

---

بعد از بهینه‌سازی (ترکیب دستورات RUN)

FROM ubuntu:latest

RUN apt-get update && apt-get install -y \
    curl \
    wget \
    vim \
    && rm -rf /var/lib/apt/lists/*

✅ مزیت:

• فایل‌های غیرضروری در همان لایه حذف می‌شوند و دیگر در ایمیج باقی نمی‌مانند.

---

۳. حذف فایل‌های موقت پس از استفاده

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

نمونه بهینه‌شده برای حذف فایل‌های موقت

FROM alpine:latest

WORKDIR /app

RUN wget -O temp_file.zip https://example.com/file.zip \
    && unzip temp_file.zip \
    && rm -f temp_file.zip

✅ مزیت:

• پس از استفاده از فایل، آن را حذف می‌کنیم تا فضای اضافی اشغال نشود.

---

۴. استفاده از .dockerignore برای جلوگیری از کپی شدن فایل‌های غیرضروری

هنگام استفاده از COPY . .، ممکن است فایل‌های غیرضروری مانند node_modules، logs، یا فایل‌های تنظیمات IDE وارد ایمیج شوند. استفاده از .dockerignore باعث جلوگیری از این مشکل می‌شود.

نمونه .dockerignore برای افزایش کارایی

node_modules
.git
logs
.env
__pycache__/

✅ مزیت:

• جلوگیری از کپی شدن فایل‌های غیرضروری به داخل ایمیج.
• کاهش حجم ایمیج و افزایش سرعت Build.

---

۵. حذف ابزارهای اضافی پس از استفاده

اگر در مرحله Build نیاز به ابزارهای خاصی دارید که در مرحله اجرا دیگر نیازی به آن‌ها نیست، می‌توانید از Multi-Stage Build استفاده کنید تا این ابزارها در نسخه نهایی ایمیج حذف شوند.

قبل از بهینه‌سازی (بدون حذف ابزارهای اضافی)

FROM golang:1.18

WORKDIR /app
COPY . .

RUN go build -o myapp
CMD ["./myapp"]

✅ مشکل:

• ابزارهای Golang در ایمیج باقی می‌مانند، در حالی که فقط باینری نهایی مورد نیاز است.

---

بعد از بهینه‌سازی (با استفاده از Multi-Stage Build)

# مرحله Build
FROM golang:1.18 AS builder

WORKDIR /app
COPY . .
RUN go build -o myapp

# مرحله نهایی (بدون ابزارهای اضافی)
FROM alpine:latest

COPY --from=builder /app/myapp /usr/local/bin/myapp
CMD ["myapp"]

✅ مزیت:

• فقط باینری نهایی در ایمیج باقی می‌ماند و ابزارهای اضافی Golang حذف می‌شوند.
• حجم ایمیج به‌طور قابل‌توجهی کاهش می‌یابد.

---

جمع‌بندی

✅ روش‌های حذف فایل‌های غیرضروری برای بهینه‌سازی Dockerfile:
1️⃣ حذف کش بسته‌های نصب‌شده (مانند /var/lib/apt/lists/*) پس از نصب.
2️⃣ ترکیب دستورات RUN برای جلوگیری از باقی ماندن فایل‌های غیرضروری در لایه‌های قبل.
3️⃣ حذف فایل‌های موقتی پس از استفاده از آن‌ها.
4️⃣ استفاده از .dockerignore برای جلوگیری از ورود فایل‌های غیرضروری به ایمیج.
5️⃣ استفاده از Multi-Stage Build برای حذف ابزارهای اضافی از نسخه نهایی ایمیج.

✅ نتیجه:
با رعایت این تکنیک‌ها، می‌توان حجم ایمیج‌های Docker را کاهش داد، سرعت اجرای کانتینرها را افزایش داد و هزینه‌های ذخیره‌سازی و انتقال را کاهش داد. 🚀[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”عیب‌یابی (Debugging) در Docker: ابزارها و روش‌ها” subtitle=”توضیحات کامل”]عیب‌یابی در فرآیند ساخت و اجرای کانتینرها یکی از بخش‌های مهم در توسعه با Docker است. در این بخش، به ابزارها و روش‌هایی برای رفع مشکلات و اشکالات رایج در Docker می‌پردازیم. یکی از ابزارهای اصلی برای این منظور، دستور docker build --no-cache است که به شما کمک می‌کند تا مشکلات ساخت ایمیج‌ها را رفع کنید.

---

استفاده از docker build --no-cache برای رفع مشکلات

زمانی که شما از Docker برای ساخت ایمیج‌ها استفاده می‌کنید، Docker به صورت پیش‌فرض از کش (cache) استفاده می‌کند تا فرآیند ساخت سریع‌تر انجام شود. کش به معنای ذخیره نتایج هر مرحله از ساخت است تا در صورت تکرار مراحل مشابه، از آن نتایج قبلی استفاده شود. اما در برخی مواقع، ممکن است کش باعث بروز مشکلات شود. برای مثال، ممکن است تغییرات جدید در Dockerfile اعمال نشوند یا نتایج اشتباهی دریافت کنید.

برای جلوگیری از استفاده از کش و اجبار به ساخت دوباره همه مراحل، می‌توانید از گزینه --no-cache استفاده کنید. این دستور باعث می‌شود که Docker تمام مراحل ساخت را از ابتدا انجام دهد.

ساختار دستور:

docker build --no-cache -t myimage .

توضیحات:

• --no-cache: این گزینه به Docker می‌گوید که کش را نادیده بگیرد و فرآیند ساخت را از ابتدا انجام دهد.
• -t myimage: این گزینه نام ایمیج را تنظیم می‌کند (در اینجا myimage).
• .: نقطه نشان‌دهنده دایرکتوری کنونی است که Dockerfile در آن قرار دارد.

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

---

بررسی لاگ‌های ساخت برای شناسایی مشکلات

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

برای بررسی دقیق‌تر مشکلات، می‌توانید از گزینه --progress در دستور docker build استفاده کنید تا خروجی بیشتری از فرآیند ساخت دریافت کنید.

ساختار دستور:

docker build --progress=plain -t myimage .

توضیحات:

• --progress=plain: این گزینه به Docker می‌گوید که تمام خروجی‌ها را به صورت واضح و با جزئیات نمایش دهد، که برای عیب‌یابی مفید است.

اگر در حین ساخت ایمیج، مشکلی رخ دهد، پیغام‌های خطا به وضوح در این لاگ‌ها نشان داده می‌شوند و شما می‌توانید بر اساس آن‌ها مشکل را شناسایی و رفع کنید.

---

استفاده از docker history برای بررسی لایه‌های ایمیج

دستور docker history به شما این امکان را می‌دهد که تاریخچه لایه‌های یک ایمیج را مشاهده کنید. این ابزار به شما کمک می‌کند تا بفهمید که کدام لایه‌ها ممکن است باعث بروز مشکل شده باشند.

ساختار دستور:

docker history myimage

خروجی نمونه:

IMAGE               CREATED             CREATED BY                                      SIZE
d1a8a6d07a43        2 days ago          /bin/sh -c #(nop)  CMD ["python" "app.py"]      0B
8b4d6f89c798        2 days ago          /bin/sh -c #(nop)  COPY file:7b8b79f7f9f6fdb…   300MB
4a8b6e4b3490        2 days ago          /bin/sh -c #(nop)  RUN apt-get update            1GB
...

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

---

استفاده از دستورات docker logs برای بررسی کانتینرهای در حال اجرا

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

ساختار دستور:

docker logs <container_id>

مثال:

docker logs mycontainer

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

---

استفاده از docker inspect برای بررسی جزئیات کانتینر و ایمیج

دستور docker inspect برای مشاهده اطلاعات جزئی و پیکربندی کامل یک کانتینر یا ایمیج استفاده می‌شود. این دستور می‌تواند به شما کمک کند تا اطلاعات دقیقی درباره کانتینر یا ایمیج مورد نظر خود دریافت کنید و هرگونه تنظیمات اشتباه را شناسایی کنید.

ساختار دستور:

docker inspect <container_id_or_image_name>

مثال:

docker inspect mycontainer

خروجی این دستور شامل تمامی جزئیات کانتینر یا ایمیج از جمله شبکه، محیط‌های متغیر (environment variables)، پورت‌ها و دیگر تنظیمات خواهد بود.

---

جمع‌بندی

• استفاده از docker build --no-cache به شما کمک می‌کند تا مشکلات مربوط به کش را برطرف کرده و فرآیند ساخت را از ابتدا اجرا کنید.
• بررسی لاگ‌ها از طریق دستور docker build --progress=plain و docker logs به شما کمک می‌کند تا پیغام‌های خطا را شناسایی کرده و مشکلات را رفع کنید.
• دستور docker history به شما امکان می‌دهد تا تاریخچه لایه‌های ایمیج‌ها را بررسی کنید.
• دستور docker inspect می‌تواند به شما کمک کند تا جزئیات دقیق‌تری از پیکربندی کانتینرها و ایمیج‌ها بدست آورید.

با استفاده از این ابزارها و روش‌ها، می‌توانید مشکلات را سریع‌تر شناسایی کرده و به طور مؤثر آن‌ها را برطرف کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. مدیریت ایمیج با دستورات CLI”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”دستورات پایه در Docker” subtitle=”توضیحات کامل”]در این بخش، با دستورات پایه‌ای Docker برای کار با ایمیج‌ها آشنا می‌شویم که شامل دستورات docker images، docker rmi و docker tag هستند. این دستورات به شما کمک می‌کنند تا ایمیج‌ها را مشاهده، حذف و برچسب‌گذاری کنید.

---

docker images: نمایش لیست ایمیج‌ها

دستور docker images برای نمایش لیست ایمیج‌های موجود در سیستم شما استفاده می‌شود. این دستور اطلاعاتی از جمله نام، برچسب، شناسه ایمیج، تاریخ ساخت و اندازه ایمیج‌ها را نشان می‌دهد.

ساختار دستور:

docker images

خروجی نمونه:

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
myimage             latest              d1a8a6d07a43        2 days ago          500MB
ubuntu              20.04               4e5021d210f7        2 weeks ago         64.2MB

مفاهیم موجود در خروجی:

• REPOSITORY: نام مخزن یا پروژه.
• TAG: برچسب نسخه ایمیج.
• IMAGE ID: شناسه منحصربه‌فرد ایمیج.
• CREATED: زمان ساخت ایمیج.
• SIZE: اندازه ایمیج.

این دستور به شما کمک می‌کند تا تمامی ایمیج‌های موجود را بررسی کنید و از وضعیت آنها آگاه شوید.

---

docker rmi: حذف ایمیج‌ها

دستور docker rmi برای حذف ایمیج‌های Docker استفاده می‌شود. اگر یک ایمیج دیگر به آن نیازی ندارید یا می‌خواهید فضای دیسک را آزاد کنید، این دستور مفید است. می‌توانید یک یا چند ایمیج را با استفاده از شناسه یا نام آن‌ها حذف کنید.

ساختار دستور:

docker rmi [OPTIONS] IMAGE [IMAGE...]

مثال‌ها:

1. حذف یک ایمیج خاص:

   docker rmi myimage
   

   این دستور ایمیج myimage را حذف می‌کند.

2. حذف چندین ایمیج:

   docker rmi myimage1 myimage2
   

   در این حالت، هر دو ایمیج myimage1 و myimage2 حذف می‌شوند.

3. حذف یک ایمیج با شناسه:

   docker rmi d1a8a6d07a43
   

   در این دستور، ایمیجی که شناسه d1a8a6d07a43 دارد حذف می‌شود.

توجه: اگر یک ایمیج توسط کانتینری در حال اجرا یا متوقف‌شده استفاده می‌شود، Docker از حذف آن جلوگیری می‌کند. برای اجبار به حذف ایمیج‌ها از گزینه -f استفاده کنید:

docker rmi -f myimage

---

docker tag: برچسب‌گذاری ایمیج‌ها

دستور docker tag برای برچسب‌گذاری ایمیج‌ها و افزودن نسخه‌ها یا نام‌های جدید به آنها استفاده می‌شود. این دستور به شما این امکان را می‌دهد که یک ایمیج را با نام‌های مختلف مدیریت کنید.

ساختار دستور:

docker tag SOURCE_IMAGE TARGET_IMAGE

• SOURCE_IMAGE: نام یا شناسه ایمیج اصلی.
• TARGET_IMAGE: نام یا شناسه جدید ایمیج با برچسب (Tag).

مثال‌ها:

1. برچسب‌گذاری ایمیج: فرض کنید شما یک ایمیج با شناسه d1a8a6d07a43 دارید و می‌خواهید به آن یک برچسب جدید v1.0 بدهید:

   docker tag d1a8a6d07a43 myimage:v1.0
   

2. برچسب‌گذاری ایمیج با نام و برچسب جدید: اگر بخواهید ایمیج خود را به یک مخزن جدید (در اینجا Docker Hub) ارسال کنید، باید نام آن را با نام مخزن جدید و برچسب (Tag) مناسب تنظیم کنید:

   docker tag myimage:v1.0 username/myimage:v1.0
   

پس از این کار، می‌توانید این ایمیج را به مخزن Docker Hub یا هر مخزن دیگری ارسال کنید.

---

جمع‌بندی

• docker images: برای نمایش لیست ایمیج‌های موجود استفاده می‌شود. این دستور اطلاعاتی مانند نام، برچسب، شناسه و اندازه ایمیج‌ها را نشان می‌دهد.
• docker rmi: برای حذف ایمیج‌ها به کار می‌رود. می‌توانید ایمیج‌ها را با شناسه یا نام آن‌ها حذف کنید.
• docker tag: برای برچسب‌گذاری ایمیج‌ها و اضافه کردن نسخه‌های مختلف یا نام‌های جدید به آنها استفاده می‌شود.

این دستورات ابزارهای اصلی شما برای مدیریت ایمیج‌ها در Docker هستند و به شما کمک می‌کنند تا بتوانید ایمیج‌ها را مشاهده، حذف یا برچسب‌گذاری کنید و به راحتی آنها را مدیریت نمایید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی جزئیات ایمیج: استفاده از docker inspect برای بررسی اطلاعات متا (Metadata)” subtitle=”توضیحات کامل”]در Docker، یکی از ابزارهای اصلی برای بررسی جزئیات یک کانتینر یا ایمیج، دستور docker inspect است. این دستور اطلاعات متا (metadata) مختلفی را درباره ایمیج‌ها و کانتینرها به شما ارائه می‌دهد که می‌تواند در عیب‌یابی و پیکربندی‌های دقیق به شما کمک کند. اطلاعاتی مانند تنظیمات شبکه، پورت‌ها، متغیرهای محیطی، مقادیر mount و دیگر جزئیات ساختاری از طریق این دستور در دسترس شما قرار می‌گیرد.

این دستور به طور ویژه برای دریافت اطلاعات دقیق و تفصیلی از ایمیج‌ها و کانتینرها طراحی شده است، که در موارد پیشرفته‌تر مانند تجزیه و تحلیل مشکلات یا بررسی تنظیمات به شما کمک می‌کند.

---

ساختار دستور docker inspect

ساختار کلی دستور docker inspect به این صورت است:

docker inspect <container_id_or_image_name>

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

مثال:

docker inspect myimage

در این مثال، اطلاعات کامل مربوط به ایمیج myimage نمایش داده خواهد شد.

---

اطلاعات متای برگشتی از docker inspect

دستور docker inspect اطلاعات زیادی را به صورت JSON برمی‌گرداند. این اطلاعات شامل جزئیات زیر می‌تواند باشد:

1. اطلاعات عمومی ایمیج:
   • Id: شناسه منحصر به فرد ایمیج
   • RepoTags: برچسب‌ها (tags) و نام‌های ذخیره شده ایمیج
   • Created: تاریخ و زمان ایجاد ایمیج
   • Size: اندازه نهایی ایمیج
2. اطلاعات درباره لایه‌ها (Layers):
   • RootFS: شامل اطلاعات مربوط به لایه‌های مختلف ایمیج و لایه‌های فایل سیستم است.
3. اطلاعات شبکه:
   • NetworkSettings: شامل تنظیمات شبکه کانتینر، از جمله پورت‌های باز، آدرس‌های IP، و وضعیت شبکه است.
4. اطلاعات مربوط به دستورات اجرایی:
   • Config: تنظیمات پیکربندی ایمیج، از جمله دستورات اجرایی مانند CMD, ENTRYPOINT, و متغیرهای محیطی (environment variables).
5. اطلاعات Mounts و Volumes:
   • Mounts: اطلاعات مربوط به volumeهایی که به ایمیج متصل شده‌اند و یا هر نوع mount دیگری.
6. اطلاعات امنیتی و صلاحیت‌ها:
   • SecurityOptions: تنظیمات امنیتی مرتبط با ایمیج و کانتینر.

---

مثال از خروجی دستور docker inspect

در اینجا یک نمونه از خروجی دستور docker inspect را مشاهده می‌کنید:

[
    {
        "Id": "sha256:8b4f8cb2b6746d55cfa8122ec053e405c051d63a923e03e2b4bffdbd91e1ff99",
        "RepoTags": [
            "myimage:latest"
        ],
        "Created": "2023-02-15T18:30:26.10616063Z",
        "Size": 10561201,
        "Config": {
            "Env": [
                "APP_ENV=production",
                "DATABASE_URL=mysql://user:password@hostname/dbname"
            ],
            "Cmd": [
                "python",
                "app.py"
            ],
            "Entrypoint": null,
            "ExposedPorts": {
                "80/tcp": {}
            },
            "WorkingDir": "/app"
        },
        "NetworkSettings": {
            "Ports": {
                "80/tcp": [
                    {
                        "HostPort": "8080"
                    }
                ]
            },
            "IPAddress": "172.17.0.2"
        },
        "RootFS": {
            "Layers": [
                "sha256:4d5f42b3a59f206f7d07fdd998e4abdb68d632e3c8c3dbd6b99fe5d16b2415b2",
                "sha256:8d1a6b3d1edfa90ad65e5b7db2b13dfc76f93de9db66b82db2f6d8f945b8cc7b"
            ]
        },
        "Mounts": [
            {
                "Source": "/mnt/data",
                "Destination": "/app/data",
                "Mode": "rw",
                "RW": true
            }
        ]
    }
]

توضیحات خروجی:

• Id: شناسه منحصر به فرد ایمیج.
• RepoTags: برچسب‌هایی که برای ایمیج استفاده شده‌اند (در اینجا myimage:latest).
• Created: تاریخ و زمان ایجاد ایمیج.
• Size: اندازه نهایی ایمیج (در اینجا 10.5 MB).
• Config: شامل تنظیمات پیکربندی ایمیج است، از جمله دستورات اجرایی (Cmd) و متغیرهای محیطی (Env).
• NetworkSettings: تنظیمات شبکه کانتینر که در اینجا پورت 80 باز شده است.
• RootFS: لایه‌های مختلف ایمیج.
• Mounts: اطلاعات مربوط به mount‌های volumeها که به کانتینر متصل هستند.

---

استفاده از docker inspect برای دسترسی به اطلاعات خاص

اگر نیاز دارید تا اطلاعات خاصی از یک ایمیج یا کانتینر را استخراج کنید، می‌توانید از ابزار jq (یک ابزار خط فرمان برای پردازش JSON) استفاده کنید تا فقط بخش مورد نظر خود را نمایش دهید.

برای مثال، برای نمایش فقط متغیرهای محیطی ایمیج از دستور زیر استفاده کنید:

docker inspect --format '{{json .Config.Env}}' myimage

این دستور فقط لیست متغیرهای محیطی (Env) ایمیج را نمایش می‌دهد.

---

جمع‌بندی

• دستور docker inspect یک ابزار قدرتمند برای بررسی جزئیات کامل ایمیج‌ها و کانتینرها است.
• این دستور اطلاعات دقیقی از پیکربندی ایمیج، لایه‌ها، تنظیمات شبکه، متغیرهای محیطی و بسیاری دیگر ارائه می‌دهد.
• با استفاده از گزینه‌های مختلف و پردازش JSON می‌توان به صورت هدفمند اطلاعات خاصی را از یک ایمیج یا کانتینر استخراج کرد.
• این ابزار به ویژه در عیب‌یابی و بهینه‌سازی ایمیج‌ها و کانتینرها کاربرد زیادی دارد.

استفاده از این دستور در توسعه و مدیریت Docker می‌تواند به شما در درک بهتر ساختار ایمیج‌ها و کانتینرها کمک کند و امکان رفع مشکلات و پیکربندی‌های پیچیده را فراهم آورد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مدیریت اندازه ایمیج‌ها: فشرده‌سازی ایمیج‌ها برای کاهش اندازه” subtitle=”توضیحات کامل”]یکی از مسائل مهم در استفاده از Docker، به ویژه در محیط‌های تولیدی و بزرگ، مدیریت اندازه ایمیج‌ها است. ایمیج‌های بزرگ نه تنها موجب افزایش زمان بارگذاری و انتقال داده‌ها می‌شوند بلکه ممکن است منابع زیادی را در سیستم‌های محلی یا سرورهای ذخیره‌سازی مصرف کنند. بنابراین، فشرده‌سازی و کاهش اندازه ایمیج‌ها یکی از اقداماتی است که می‌تواند در بهبود عملکرد و کارایی سیستم‌ها کمک کند.

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

---

روش‌های فشرده‌سازی ایمیج‌ها

1. استفاده از Multi-Stage Builds

   یکی از روش‌های اصلی برای کاهش اندازه ایمیج‌های Docker استفاده از ویژگی Multi-Stage Builds است. در این روش، از چندین مرحله ساخت (Build) برای تقسیم فرآیند به چند بخش استفاده می‌شود. این روش به شما این امکان را می‌دهد که مراحل ساخت را تفکیک کنید و فقط فایل‌های مورد نیاز را در نهایت به ایمیج نهایی اضافه کنید.

   در مراحل اولیه می‌توان از ابزارها و وابستگی‌های مختلف برای ساخت و توسعه استفاده کرد، ولی تنها فایل‌های مورد نیاز در مرحله آخر در ایمیج اصلی قرار می‌گیرند. این روش باعث کاهش قابل توجه اندازه ایمیج‌ها می‌شود.

   مثال:

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

   در اینجا یک نمونه از Multi-Stage Build برای کاهش اندازه ایمیج آورده شده است:

   # مرحله اول: ایجاد وابستگی‌ها
   FROM python:3.9 AS build
   
   WORKDIR /app
   COPY . .
   
   RUN pip install --no-cache-dir -r requirements.txt
   
   # مرحله دوم: ایمیج نهایی
   FROM python:3.9-slim
   
   WORKDIR /app
   COPY --from=build /app /app
   
   CMD ["python", "app.py"]
   

   در اینجا، مرحله اول وابستگی‌ها را نصب می‌کند، ولی در مرحله دوم، تنها کد و فایل‌های نهایی به ایمیج نهایی منتقل می‌شوند. این ایمیج نهایی بسیار سبک‌تر خواهد بود.

---

2. حذف فایل‌ها و وابستگی‌های اضافی

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

   برای کاهش اندازه ایمیج‌ها، می‌توان این فایل‌ها را پس از نصب وابستگی‌ها حذف کرد تا فضای کمتری مصرف شود.

   مثال:

   در صورتی که شما با استفاده از APT یا PIP وابستگی‌ها را نصب می‌کنید، می‌توانید از دستوراتی مانند rm -rf /var/lib/apt/lists/* یا pip cache purge برای حذف فایل‌های cache استفاده کنید.

   FROM ubuntu:20.04
   
   RUN apt-get update && \
       apt-get install -y build-essential && \
       rm -rf /var/lib/apt/lists/* # حذف cache های نصب شده
   

   این دستور، فایل‌های cache که برای نصب پکیج‌ها استفاده شده‌اند را حذف می‌کند و باعث کاهش حجم نهایی ایمیج می‌شود.

---

3. انتخاب نسخه‌های بهینه از ایمیج‌ها (Slim Images)

   Docker به طور پیش‌فرض از نسخه‌های کامل و با قابلیت‌های کامل برای ایمیج‌ها استفاده می‌کند، اما در بیشتر موارد، شما نیازی به تمام قابلیت‌های این نسخه‌ها ندارید. بنابراین، انتخاب نسخه‌های Slim و بهینه‌تر برای ایمیج‌ها می‌تواند تاثیر زیادی در کاهش اندازه ایمیج‌ها داشته باشد.

   به عنوان مثال، به جای استفاده از ایمیج‌های ubuntu یا debian، می‌توانید از نسخه‌های Slim آن‌ها استفاده کنید که حجم کمتری دارند و به صورت پیش‌فرض بهینه‌تر هستند.

   مثال:

   FROM node:14-slim
   

   ایمیج node:14-slim نسبت به node:14 حجم کمتری دارد، زیرا بیشتر ابزارهای غیرضروری در آن حذف شده‌اند.

---

4. استفاده از ابزارهای فشرده‌سازی خارج از Docker

   در برخی از موارد، ممکن است استفاده از ابزارهایی خارج از Docker مانند Upx برای فشرده‌سازی فایل‌های باینری در داخل کانتینر مفید باشد. این ابزار قادر است تا اندازه فایل‌های باینری مانند برنامه‌های کامپایل‌شده را کاهش دهد.

   مثال:

   در صورتی که برنامه شما یک فایل باینری (مثل برنامه‌های C یا Go) باشد، می‌توانید از Upx برای فشرده‌سازی آن استفاده کنید:

   RUN apt-get update && \
       apt-get install -y upx-ucl && \
       upx --best /usr/local/bin/myapp
   

   این دستور باعث می‌شود که فایل باینری myapp به طور قابل توجهی فشرده شود و اندازه ایمیج کاهش یابد.

---

5. استفاده از Multi-Arch و پلتفرم‌های بهینه

   در برخی موارد، ایمیج‌های Docker ممکن است برای چندین معماری (Architecture) ساخته شوند که باعث افزایش حجم ایمیج می‌شود. برای کاهش این مشکل، می‌توان از پلتفرم‌های خاص و بهینه‌شده برای هر معماری استفاده کرد.

   این کار می‌تواند به ویژه در صورتی که فقط به یک معماری خاص نیاز دارید مفید باشد.

   مثال:

   با استفاده از --platform می‌توانید مشخص کنید که ایمیج برای کدام معماری ساخته شود:

   docker build --platform linux/amd64 .
   

   این دستور باعث می‌شود که ایمیج به طور خاص برای معماری amd64 ساخته شود و از سایر معماری‌ها صرف‌نظر کند.

---

جمع‌بندی

• استفاده از Multi-Stage Builds به شما کمک می‌کند تا لایه‌های غیرضروری را حذف کرده و فقط فایل‌های مورد نیاز را در ایمیج نهایی قرار دهید.
• حذف فایل‌ها و وابستگی‌های اضافی بعد از نصب می‌تواند تأثیر زیادی در کاهش حجم ایمیج‌ها داشته باشد.
• انتخاب نسخه‌های Slim از ایمیج‌ها یکی از بهترین روش‌ها برای کاهش اندازه ایمیج‌ها است.
• ابزارهایی مانند Upx برای فشرده‌سازی فایل‌های باینری در داخل کانتینر به کار می‌آیند و می‌توانند حجم نهایی ایمیج را کاهش دهند.
• استفاده از پلتفرم‌های بهینه‌شده برای معماری خاص نیز می‌تواند به کاهش حجم ایمیج کمک کند.

با این روش‌ها می‌توانید ایمیج‌هایی بهینه و کوچک‌تر بسازید که سرعت بارگذاری، انتقال داده‌ها و مدیریت منابع را بهبود می‌بخشد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تمیز کردن ایمیج‌های بدون استفاده (docker image prune)” subtitle=”توضیحات کامل”]در دنیای Docker، زمانی که شما به طور مداوم از ایمیج‌ها برای ایجاد کانتینرها و اجرای پروژه‌ها استفاده می‌کنید، ممکن است ایمیج‌های بدون استفاده و قدیمی در سیستم شما باقی بمانند. این ایمیج‌ها باعث افزایش فضای دیسک مصرفی و پیچیدگی در مدیریت سیستم می‌شوند. به همین دلیل، تمیز کردن ایمیج‌های بدون استفاده یک فرآیند مهم برای حفظ کارایی سیستم است.

در Docker، ابزارهایی برای تمیز کردن و حذف ایمیج‌های غیرضروری و بدون استفاده وجود دارد که یکی از پرکاربردترین آن‌ها دستور docker image prune است. در این بخش، به بررسی نحوه استفاده از این دستور و روش‌های مختلف برای مدیریت ایمیج‌ها پرداخته خواهد شد.

---

استفاده از دستور docker image prune

دستور docker image prune به شما این امکان را می‌دهد که تمامی ایمیج‌های بدون استفاده در سیستم Docker خود را حذف کنید. این دستور به طور پیش‌فرض ایمیج‌هایی که هیچ‌کدام از آن‌ها به یک کانتینر متصل نیستند یا به عنوان یک لایه در هیچ‌کدام از ایمیج‌های دیگر استفاده نمی‌شوند را پاک می‌کند.

این کار باعث می‌شود که فضای دیسک شما آزاد شود و سیستم Docker شما تمیزتر و کارآمدتر عمل کند.

نحوه استفاده:

برای حذف ایمیج‌های بدون استفاده، دستور زیر را وارد کنید:

docker image prune

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

---

گزینه‌های مختلف دستور docker image prune

دستور docker image prune با چندین گزینه مختلف قابل استفاده است که به شما این امکان را می‌دهد که عمل حذف ایمیج‌ها را با دقت بیشتری انجام دهید. در ادامه برخی از این گزینه‌ها معرفی می‌شوند:

1. حذف ایمیج‌های بدون استفاده به صورت خودکار (با تایید خودکار)

   اگر می‌خواهید بدون درخواست تایید، ایمیج‌های بدون استفاده حذف شوند، می‌توانید از گزینه -f یا --force استفاده کنید:

   docker image prune -f
   

   این دستور به طور خودکار همه ایمیج‌های بدون استفاده را حذف می‌کند بدون اینکه از شما تایید بخواهد.

2. حذف ایمیج‌هایی که مدت زمان بیشتری از آن‌ها گذشته است (گزینه --filter)

   اگر بخواهید فقط ایمیج‌هایی که مدت زمان بیشتری از آن‌ها گذشته باشد حذف شوند، می‌توانید از گزینه --filter استفاده کنید. برای مثال، برای حذف ایمیج‌هایی که بیش از 24 ساعت پیش استفاده نشده‌اند:

   docker image prune --filter "until=24h"
   

   این دستور فقط ایمیج‌هایی را حذف می‌کند که حداقل 24 ساعت از زمان آخرین استفاده آن‌ها گذشته باشد.

3. حذف ایمیج‌هایی که به هیچ کانتینری متصل نیستند (گزینه --all)

   به طور پیش‌فرض، دستور docker image prune تنها ایمیج‌هایی را حذف می‌کند که هیچ‌کدام از آن‌ها به کانتینری متصل نباشند. اما اگر بخواهید تمامی ایمیج‌های بدون استفاده را حتی آن‌هایی که هنوز در کانتینرهایی در حال استفاده هستند حذف کنید، می‌توانید از گزینه --all استفاده کنید:

   docker image prune --all
   

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

---

مثال‌هایی از استفاده بهینه از دستور docker image prune

در اینجا چندین مثال از نحوه استفاده از دستور docker image prune برای حذف ایمیج‌های غیرضروری آورده شده است:

1. حذف ایمیج‌های بدون استفاده پس از یک جلسه کاری:

   فرض کنید شما بعد از تمام شدن یک پروژه یا جلسه کاری می‌خواهید تمامی ایمیج‌های غیرضروری و قدیمی را پاک کنید. برای این کار، از دستور زیر استفاده می‌کنید:

   docker image prune -f
   

   این دستور تمامی ایمیج‌های بدون استفاده را به طور خودکار و بدون نیاز به تایید پاک می‌کند.

2. حذف ایمیج‌هایی که بیش از 2 روز از آخرین استفاده آن‌ها گذشته است:

   اگر قصد دارید فقط ایمیج‌هایی که بیش از 48 ساعت از آخرین استفاده آن‌ها گذشته را حذف کنید، دستور زیر را اجرا کنید:

   docker image prune --filter "until=48h"
   

3. حذف تمامی ایمیج‌های بدون استفاده حتی اگر به کانتینرهایی متصل باشند:

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

   docker image prune --all -f
   

---

جمع‌بندی

• دستور docker image prune به شما این امکان را می‌دهد که ایمیج‌های بدون استفاده و قدیمی را از سیستم خود حذف کنید تا فضای دیسک شما آزاد شود.
• با استفاده از گزینه‌های مختلف این دستور مانند -f (برای تایید خودکار) و --filter (برای فیلتر کردن ایمیج‌ها بر اساس زمان استفاده یا دیگر ویژگی‌ها)، می‌توانید عملیات حذف ایمیج‌ها را به دقت بیشتری کنترل کنید.
• استفاده از گزینه --all برای حذف تمامی ایمیج‌های بدون استفاده حتی آن‌هایی که به کانتینرهایی متصل هستند می‌تواند مفید باشد.

با استفاده منظم از این دستور می‌توانید سیستم Docker خود را تمیز و بهینه نگه دارید و از اشغال فضای بی‌جا جلوگیری کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. رجیستری ایمیج‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مفهوم رجیستری: Public registries (مانند Docker Hub) و Private registries” subtitle=”توضیحات کامل”]در دنیای Docker، “رجیستری” به مکانی گفته می‌شود که در آن ایمیج‌های Docker ذخیره می‌شوند و به اشتراک گذاشته می‌شوند. رجیستری‌ها نقشی حیاتی در فرآیند توسعه و استقرار اپلیکیشن‌ها ایفا می‌کنند و به شما امکان می‌دهند ایمیج‌ها را بین ماشین‌های مختلف به اشتراک بگذارید و به راحتی از آن‌ها استفاده کنید.

در این بخش، به بررسی دو نوع اصلی رجیستری‌ها پرداخته می‌شود: Public registries (رجیستری‌های عمومی) و Private registries (رجیستری‌های خصوصی).

---

Public Registries (رجیستری‌های عمومی)

رجیستری‌های عمومی به رجیستری‌هایی اطلاق می‌شود که دسترسی به آن‌ها برای همه افراد آزاد است. در این رجیستری‌ها، شما می‌توانید ایمیج‌های خود را بارگذاری (Push) کرده و همچنین ایمیج‌های دیگران را دانلود (Pull) کنید. مشهورترین نمونه رجیستری عمومی، Docker Hub است که به طور پیش‌فرض به عنوان رجیستری برای Docker در نظر گرفته می‌شود.

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

ویژگی‌ها و مزایای Public Registries:

1. دسترس‌پذیری عمومی:
   • ایمیج‌ها در این رجیستری‌ها برای همه قابل مشاهده و دسترسی هستند.
   • شما می‌توانید ایمیج‌های مختلف را از کاربران دیگر دانلود کنید و از آن‌ها استفاده نمایید.
2. سهولت در به اشتراک‌گذاری:
   • رجیستری‌های عمومی به شما این امکان را می‌دهند که ایمیج‌ها را به سادگی با دیگران به اشتراک بگذارید و آن‌ها را روی سیستم‌های مختلف اجرا کنید.
3. مخزن‌های پیش‌ساخته (Pre-built):
   • Docker Hub و دیگر رجیستری‌های عمومی، ایمیج‌های پیش‌ساخته زیادی از سیستم‌عامل‌ها، ابزارهای مختلف و اپلیکیشن‌های محبوب را برای استفاده در اختیار شما قرار می‌دهند.
4. رایگان و مقیاس‌پذیری:
   • بیشتر رجیستری‌های عمومی مانند Docker Hub به صورت رایگان برای استفاده فردی در دسترس هستند و مقیاس‌پذیری خوبی برای استقرار اپلیکیشن‌ها فراهم می‌کنند.

Docker Hub به عنوان یک نمونه از Public Registry:

Docker Hub یکی از معروف‌ترین و رایج‌ترین رجیستری‌های عمومی است. این رجیستری برای کاربران Docker این امکان را فراهم می‌آورد که به راحتی ایمیج‌های مختلف را از آن دانلود کرده و به اشتراک بگذارند.

برای استفاده از Docker Hub، مراحل زیر را می‌توانید دنبال کنید:

1. ورود به حساب Docker Hub:
   • ابتدا باید وارد حساب خود در Docker Hub شوید. در صورت نداشتن حساب، می‌توانید به راحتی ثبت‌نام کنید.
2. دانلود ایمیج از Docker Hub:
   • برای دانلود یک ایمیج از Docker Hub، از دستور زیر استفاده می‌کنید:

   docker pull <username>/<image-name>:<tag>
   

   به عنوان مثال:

   docker pull ubuntu:latest
   

3. بارگذاری ایمیج به Docker Hub:
   • برای بارگذاری ایمیج به Docker Hub، ابتدا باید ایمیج را ساخته و سپس آن را با استفاده از دستور docker push به رجیستری ارسال کنید.

   ابتدا با دستور زیر وارد حساب خود شوید:

   docker login
   

   سپس ایمیج را به Docker Hub ارسال کنید:

   docker push <username>/<image-name>:<tag>
   

---

Private Registries (رجیستری‌های خصوصی)

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

ویژگی‌ها و مزایای Private Registries:

1. کنترل کامل بر دسترسی‌ها:
   • در رجیستری‌های خصوصی، شما می‌توانید دسترسی به ایمیج‌ها را به کاربران خاصی اختصاص دهید. این ویژگی به ویژه برای ذخیره ایمیج‌های حساس و اختصاصی کاربرد دارد.
2. حفظ امنیت و حریم خصوصی:
   • با استفاده از رجیستری‌های خصوصی، می‌توانید اطمینان حاصل کنید که ایمیج‌ها فقط توسط افرادی که مجوز دسترسی دارند، قابل دانلود یا مشاهده خواهند بود.
3. کاستوم‌سازی بیشتر:
   • شما می‌توانید رجیستری خصوصی خود را بنا به نیازهای سازمان یا پروژه خاص خود راه‌اندازی کرده و تنظیمات سفارشی را اعمال کنید.
4. مدیریت بهتر منابع:
   • بسیاری از سازمان‌ها از رجیستری‌های خصوصی برای کنترل بهتر منابع و مدیریت اپلیکیشن‌ها استفاده می‌کنند. این امکان را فراهم می‌کند که شما بتوانید ایمیج‌ها را به طور خصوصی و دقیق‌تر کنترل کنید.

راه‌اندازی یک Private Registry:

برای راه‌اندازی یک رجیستری خصوصی، شما می‌توانید از Docker Registry استفاده کنید. Docker Registry یک نرم‌افزار متن‌باز است که به شما این امکان را می‌دهد تا یک رجیستری خصوصی روی سرور خود راه‌اندازی کنید.

برای راه‌اندازی یک رجیستری خصوصی از دستور زیر استفاده کنید:

docker run -d -p 5000:5000 --name registry registry:2

این دستور یک Docker Registry در پورت 5000 راه‌اندازی می‌کند. سپس شما می‌توانید ایمیج‌ها را به این رجیستری ارسال کنید.

برای ارسال ایمیج به رجیستری خصوصی:

1. ابتدا برچسب‌گذاری ایمیج خود را انجام دهید:

   docker tag <image-name>:<tag> localhost:5000/<image-name>:<tag>
   

2. سپس ایمیج را به رجیستری خصوصی ارسال کنید:

   docker push localhost:5000/<image-name>:<tag>
   

---

مقایسه Public و Private Registries:

ویژگی	Public Registries	Private Registries
دسترس‌پذیری	برای همه قابل دسترسی	فقط برای کاربران مجاز
امنیت	ایمیج‌ها عمومی هستند	ایمیج‌ها فقط برای کاربران مجاز
مقیاس‌پذیری	مقیاس‌پذیر و رایگان	محدودیت‌های بیشتر در مقیاس‌پذیری
اشتراک‌گذاری	آسان و عمومی	محدود و فقط برای تیم‌ها و سازمان‌ها
نمونه‌ها	Docker Hub	Docker Registry خصوصی

---

جمع‌بندی

• Public Registries مانند Docker Hub به شما این امکان را می‌دهند که ایمیج‌ها را به صورت عمومی به اشتراک بگذارید و از ایمیج‌های عمومی دیگران استفاده کنید.
• Private Registries به شما این امکان را می‌دهند که ایمیج‌ها را به صورت خصوصی ذخیره کنید و دسترسی به آن‌ها را محدود کنید.
• استفاده از Private Registries در محیط‌های حساس و سازمانی بسیار مفید است، زیرا می‌توانید کنترل کامل بر دسترسی‌ها و امنیت ایمیج‌ها داشته باشید.

هر کدام از این نوع رجیستری‌ها مزایا و محدودیت‌های خاص خود را دارند و انتخاب بهترین گزینه به نیازهای پروژه یا سازمان شما بستگی دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ذخیره و بازیابی ایمیج‌ها از رجیستری” subtitle=”توضیحات کامل”]در Docker، رجیستری به عنوان مکانی برای ذخیره‌سازی و توزیع ایمیج‌ها استفاده می‌شود. شما می‌توانید ایمیج‌های خود را به رجیستری‌ها ارسال کرده (Push) و از آن‌ها دریافت (Pull) کنید. این فرآیند به شما کمک می‌کند تا ایمیج‌ها را بین ماشین‌ها و محیط‌های مختلف به اشتراک بگذارید و مدیریت کنید. در این بخش، به بررسی دستورات اصلی برای ارسال و دریافت ایمیج‌ها از رجیستری خواهیم پرداخت.

---

دستور docker push: ارسال ایمیج به رجیستری

دستور docker push به شما این امکان را می‌دهد که یک ایمیج را از روی سیستم خود به یک رجیستری (عمومی یا خصوصی) ارسال کنید. این دستور به‌طور معمول زمانی استفاده می‌شود که شما ایمیج‌های خود را به اشتراک بگذارید یا برای استقرار در محیط‌های مختلف ذخیره کنید.

نحوه استفاده از دستور docker push:

برای ارسال یک ایمیج به رجیستری، باید ابتدا آن ایمیج را با یک برچسب (Tag) خاص علامت‌گذاری کنید تا رجیستری بتواند آن را شناسایی کند. اگر از Docker Hub استفاده می‌کنید، معمولاً فرمت نام‌گذاری به شکل <username>/<image-name>:<tag> خواهد بود. اگر از رجیستری خصوصی استفاده می‌کنید، باید از آدرس IP یا دامنه رجیستری خود در قالب <hostname>/<image-name>:<tag> استفاده کنید.

مراحل ارسال ایمیج به رجیستری:

1. برچسب‌گذاری ایمیج (Tagging): قبل از ارسال ایمیج به رجیستری، شما باید آن را با استفاده از دستور docker tag برچسب‌گذاری کنید. فرض کنید ایمیج شما با نام my-app ساخته شده و می‌خواهید آن را به Docker Hub ارسال کنید.

   برای برچسب‌گذاری ایمیج از دستور زیر استفاده کنید:

   docker tag my-app:latest myusername/my-app:latest
   

   در اینجا:

   • my-app:latest نام و برچسب ایمیج محلی است.
   • myusername/my-app:latest نام و برچسب ایمیج موردنظر برای رجیستری است که در اینجا Docker Hub است.
2. ارسال ایمیج به رجیستری: برای ارسال ایمیج به Docker Hub یا هر رجیستری دیگری، از دستور docker push استفاده کنید:

   docker push myusername/my-app:latest
   

   در اینجا:

   • myusername/my-app:latest نام و برچسب ایمیجی است که به رجیستری ارسال می‌شود.

   پس از اجرای این دستور، Docker شروع به ارسال ایمیج به رجیستری می‌کند و به محض پایان ارسال، ایمیج شما در آن رجیستری ذخیره خواهد شد.

نکات مهم:

• برای ارسال ایمیج‌ها به Docker Hub یا هر رجیستری عمومی، نیاز به ورود (Login) به حساب کاربری خود دارید. برای ورود به Docker Hub از دستور docker login استفاده کنید.
• اگر از یک رجیستری خصوصی استفاده می‌کنید، باید به آن رجیستری وارد شوید (از طریق دستور docker login <hostname>).

---

دستور docker pull: دریافت ایمیج از رجیستری

دستور docker pull به شما این امکان را می‌دهد که یک ایمیج را از یک رجیستری (عمومی یا خصوصی) دریافت کرده و آن را بر روی سیستم خود ذخیره کنید. این دستور به طور معمول زمانی استفاده می‌شود که شما می‌خواهید از ایمیج‌های موجود در رجیستری‌ها استفاده کنید و آن‌ها را به محیط خود دانلود کنید.

نحوه استفاده از دستور docker pull:

برای دریافت یک ایمیج از رجیستری، شما باید نام و برچسب ایمیج موردنظر را بدانید. فرمت کلی دستور به شکل زیر است:

docker pull <image-name>:<tag>

اگر از Docker Hub استفاده می‌کنید و می‌خواهید ایمیجی مانند ubuntu را دانلود کنید، می‌توانید از دستور زیر استفاده کنید:

docker pull ubuntu:latest

در اینجا:

• ubuntu:latest نام و برچسب ایمیج موردنظر است که می‌خواهید از Docker Hub دریافت کنید.

اگر از یک رجیستری خصوصی استفاده می‌کنید، باید آدرس آن رجیستری را نیز مشخص کنید:

docker pull myregistry.local/my-app:latest

در اینجا:

• myregistry.local دامنه یا آدرس IP رجیستری خصوصی شما است.
• my-app:latest نام و برچسب ایمیج موردنظر برای دریافت است.

نکات مهم:

• همانند دستور docker push، برای دریافت ایمیج‌ها از Docker Hub یا هر رجیستری دیگر، شما باید وارد حساب کاربری خود شوید.
• اگر رجیستری خصوصی است، باید با استفاده از دستور docker login <hostname> وارد آن شوید تا دسترسی لازم برای دانلود ایمیج‌ها را داشته باشید.

---

جمع‌بندی

• دستور docker push برای ارسال ایمیج‌ها از سیستم محلی شما به رجیستری‌ها استفاده می‌شود. شما باید ابتدا ایمیج را برچسب‌گذاری کنید و سپس آن را با استفاده از این دستور ارسال کنید.
• دستور docker pull برای دریافت ایمیج‌ها از رجیستری‌ها به سیستم محلی شما استفاده می‌شود. شما باید نام و برچسب ایمیج موردنظر را وارد کرده و سپس آن را دانلود کنید.

این دستورات، ابزارهای اصلی برای ذخیره‌سازی و بازیابی ایمیج‌ها از رجیستری‌ها هستند و به شما این امکان را می‌دهند که ایمیج‌ها را به راحتی در میان ماشین‌ها و محیط‌های مختلف به اشتراک بگذارید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”راه‌اندازی یک رجیستری خصوصی با استفاده از Docker Registry” subtitle=”توضیحات کامل”]در دنیای Docker، شما می‌توانید از رجیستری‌های عمومی مانند Docker Hub برای ذخیره‌سازی و توزیع ایمیج‌ها استفاده کنید. با این حال، در بسیاری از سازمان‌ها، نیاز به یک رجیستری خصوصی برای ذخیره و مدیریت ایمیج‌ها به‌طور ایمن و داخلی وجود دارد. در این بخش، به شما نشان خواهیم داد که چگونه یک رجیستری خصوصی با استفاده از Docker Registry راه‌اندازی کنید و آن را برای ذخیره‌سازی ایمیج‌های خود پیکربندی کنید.

Docker Registry یک اپلیکیشن است که برای ذخیره‌سازی و توزیع ایمیج‌های Docker استفاده می‌شود. در این راهنما، ما نحوه راه‌اندازی یک رجیستری خصوصی با استفاده از Docker Registry را شرح خواهیم داد.

---

پیش‌نیازها

برای راه‌اندازی یک رجیستری خصوصی، شما به موارد زیر نیاز دارید:

1. Docker نصب‌شده: ابتدا باید Docker بر روی سیستم خود نصب شده باشد. برای نصب Docker، می‌توانید از این لینک استفاده کنید.
2. فضای ذخیره‌سازی: باید اطمینان حاصل کنید که سرور یا سیستم شما فضای کافی برای ذخیره‌سازی ایمیج‌ها دارد.
3. IP یا دامنه برای دسترسی به رجیستری: اگر قصد دارید رجیستری را به‌صورت عمومی یا بر روی شبکه محلی در دسترس قرار دهید، به یک IP یا نام دامنه نیاز خواهید داشت.

---

راه‌اندازی Docker Registry

برای راه‌اندازی رجیستری خصوصی، Docker یک تصویر آماده از رجیستری را فراهم کرده است که می‌توانید آن را به راحتی با استفاده از دستور docker run به‌صورت یک کانتینر اجرا کنید.

گام 1: اجرای Docker Registry

1. اجرای رجیستری در حالت پیش‌فرض (محلی):

   برای اجرای Docker Registry در سیستم محلی خود، می‌توانید از دستور زیر استفاده کنید. این دستور یک کانتینر با استفاده از تصویر رسمی registry راه‌اندازی می‌کند:

   docker run -d -p 5000:5000 --name registry registry:2
   

   در اینجا:

   • -d: کانتینر را در پس‌زمینه اجرا می‌کند.
   • -p 5000:5000: پورت 5000 سیستم را به پورت 5000 کانتینر متصل می‌کند (پورت پیش‌فرض برای Docker Registry).
   • --name registry: نام کانتینر را registry تعیین می‌کند.
   • registry:2: از نسخه 2 تصویر رسمی Docker Registry استفاده می‌کند.

   پس از اجرای این دستور، Docker Registry شما بر روی پورت 5000 سیستم شما در دسترس خواهد بود.

گام 2: بررسی وضعیت کانتینر رجیستری

برای اطمینان از اجرای صحیح Docker Registry، می‌توانید وضعیت کانتینر را با استفاده از دستور زیر بررسی کنید:

docker ps

این دستور تمام کانتینرهای در حال اجرای سیستم شما را نمایش می‌دهد. شما باید کانتینر با نام registry را مشاهده کنید که بر روی پورت 5000 در حال اجرا است.

---

ارسال ایمیج‌ها به رجیستری خصوصی

حالا که Docker Registry شما راه‌اندازی شده است، می‌توانید ایمیج‌ها را به آن ارسال کنید.

گام 3: برچسب‌گذاری ایمیج

قبل از ارسال ایمیج به رجیستری، باید آن را برچسب‌گذاری کنید. به‌طور پیش‌فرض، Docker انتظار دارد ایمیج‌ها را با فرمت <hostname>:<port>/<image-name>:<tag> برچسب‌گذاری کنید. در حالت محلی، آدرس رجیستری به‌صورت localhost:5000 خواهد بود.

برای مثال، اگر شما یک ایمیج به نام my-app دارید که می‌خواهید آن را به رجیستری ارسال کنید، باید دستور زیر را برای برچسب‌گذاری آن اجرا کنید:

docker tag my-app localhost:5000/my-app:latest

در اینجا:

• my-app نام ایمیج محلی شما است.
• localhost:5000/my-app:latest نام و برچسبی است که برای ارسال به رجیستری خصوصی شما استفاده می‌شود.

گام 4: ارسال ایمیج به رجیستری

پس از برچسب‌گذاری ایمیج، می‌توانید آن را با استفاده از دستور docker push به رجیستری ارسال کنید:

docker push localhost:5000/my-app:latest

این دستور ایمیج شما را به رجیستری خصوصی در حال اجرا بر روی localhost:5000 ارسال می‌کند.

گام 5: دریافت ایمیج از رجیستری

برای دریافت ایمیج از رجیستری خصوصی، شما می‌توانید از دستور docker pull استفاده کنید. برای مثال، برای دریافت ایمیج my-app از رجیستری، دستور زیر را اجرا کنید:

docker pull localhost:5000/my-app:latest

این دستور ایمیج my-app را از رجیستری خصوصی شما دریافت می‌کند.

---

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

به‌طور پیش‌فرض، Docker Registry شما بر روی HTTP و بدون رمزنگاری اجرا می‌شود که برای محیط‌های تولیدی توصیه نمی‌شود. برای بهبود امنیت رجیستری، می‌توانید از HTTPS و احراز هویت استفاده کنید.

گام 6: راه‌اندازی رجیستری با HTTPS

برای اجرای Docker Registry با HTTPS، شما به گواهی SSL و کلید خصوصی نیاز خواهید داشت. شما می‌توانید گواهی‌های خود را از یک مرجع صدور گواهی (CA) دریافت کنید یا از گواهی‌های خود-امضا شده استفاده کنید.

برای پیکربندی HTTPS، باید گواهی‌ها و کلیدهای SSL خود را در دایرکتوری‌های مناسب قرار داده و Docker Registry را با این گواهی‌ها اجرا کنید:

docker run -d -p 5000:5000 \
  -v /path/to/cert.crt:/etc/registry/certs/domain.crt \
  -v /path/to/cert.key:/etc/registry/certs/domain.key \
  --name registry registry:2

در اینجا:

• /path/to/cert.crt و /path/to/cert.key مسیرهای فایل گواهی و کلید خصوصی شما هستند.

گام 7: پیکربندی احراز هویت

برای محدود کردن دسترسی به رجیستری، می‌توانید از احراز هویت پایه (Basic Authentication) استفاده کنید. برای این کار، باید فایل htpasswd را ایجاد کنید که شامل نام کاربری و رمز عبور است.

برای ساخت این فایل، می‌توانید از ابزار htpasswd استفاده کنید:

htpasswd -c /path/to/htpasswd user1

سپس، باید این فایل را به کانتینر Registry متصل کنید:

docker run -d -p 5000:5000 \
  -v /path/to/htpasswd:/etc/registry/auth/htpasswd \
  --name registry registry:2

---

جمع‌بندی

در این بخش، نحوه راه‌اندازی یک رجیستری خصوصی Docker با استفاده از Docker Registry توضیح داده شد. شما می‌توانید با استفاده از دستورات ساده Docker، یک رجیستری خصوصی راه‌اندازی کرده، ایمیج‌ها را به آن ارسال و از آن دریافت کنید. همچنین، برای امنیت بیشتر، می‌توانید از HTTPS و احراز هویت استفاده کنید.

این فرآیند برای تیم‌ها و سازمان‌هایی که نیاز به ذخیره‌سازی ایمیج‌های Docker به‌صورت داخلی و ایمن دارند، بسیار مناسب است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مدیریت دسترسی‌ها و امنیت رجیستری خصوصی” subtitle=”توضیحات کامل”]در محیط‌های تولیدی، یکی از موارد بسیار مهم در کار با Docker Registry خصوصی، مدیریت دسترسی‌ها و حفظ امنیت است. به‌ویژه زمانی که این رجیستری به‌طور مستقیم از شبکه‌های داخلی یا حتی عمومی قابل دسترسی است، مدیریت صحیح دسترسی‌ها و پیکربندی امنیتی می‌تواند از بسیاری از تهدیدات محافظت کند.

در این بخش، به بررسی نحوه مدیریت دسترسی‌ها و پیکربندی امنیتی برای رجیستری خصوصی Docker خواهیم پرداخت. این تنظیمات شامل موارد مختلفی مانند احراز هویت، کنترل دسترسی، استفاده از HTTPS، و سایر مکانیزم‌های امنیتی است.

---

پیش‌نیازها

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

1. Docker Registry راه‌اندازی شده: شما باید یک Docker Registry خصوصی راه‌اندازی کرده باشید.
2. دسترسی به ابزارهای امنیتی: ابزارهایی مانند htpasswd برای مدیریت احراز هویت و SSL/TLS برای رمزنگاری ارتباطات باید در دسترس باشند.
3. گواهی SSL: برای پیکربندی HTTPS، شما به یک گواهی SSL (که از یک مرجع صدور گواهی معتبر صادر شده باشد یا خود-امضا شده) نیاز دارید.

---

1. پیکربندی HTTPS برای امنیت ارتباطات

برای تأمین امنیت و جلوگیری از دسترسی‌های ناخواسته یا تداخل در داده‌ها، باید ارتباطات بین کلاینت‌ها و سرورهای Docker Registry از طریق پروتکل امن HTTPS انجام شود. به‌طور پیش‌فرض، Docker Registry روی HTTP اجرا می‌شود که برای محیط‌های تولیدی مناسب نیست.

گام 1: دریافت گواهی SSL

اگر از یک مرجع صدور گواهی (CA) معتبر گواهی SSL خریداری کرده‌اید، باید گواهی و کلید خصوصی خود را دریافت کنید. اگر قصد دارید از یک گواهی خود-امضا شده استفاده کنید، می‌توانید با استفاده از ابزار openssl گواهی و کلید را ایجاد کنید:

openssl req -newkey rsa:4096 -nodes -keyout domain.key -x509 -out domain.crt

این دستور یک گواهی SSL خود-امضا شده و کلید خصوصی آن را ایجاد خواهد کرد.

گام 2: اجرای رجیستری با HTTPS

پس از دریافت گواهی و کلید خصوصی، باید آنها را به Docker Registry خود متصل کنید. به این صورت که می‌توانید فایل‌های گواهی و کلید را در دایرکتوری‌های مناسب قرار داده و دستور زیر را اجرا کنید تا رجیستری شما از HTTPS استفاده کند:

docker run -d -p 5000:5000 \
  -v /path/to/domain.crt:/etc/registry/certs/domain.crt \
  -v /path/to/domain.key:/etc/registry/certs/domain.key \
  --name registry registry:2

در اینجا:

• /path/to/domain.crt: مسیر گواهی SSL شما است.
• /path/to/domain.key: مسیر کلید خصوصی شما است.

با این تنظیمات، Docker Registry شما اکنون از HTTPS برای ارتباطات ایمن استفاده می‌کند.

---

2. پیکربندی احراز هویت (Authentication)

برای کنترل دسترسی به Docker Registry، معمولاً از احراز هویت استفاده می‌شود. یکی از رایج‌ترین روش‌ها برای این کار، استفاده از احراز هویت پایه‌ای (Basic Authentication) است که برای هر کاربر نام‌کاربری و رمزعبور مشخص می‌کند.

گام 1: ایجاد فایل htpasswd

برای احراز هویت با استفاده از نام کاربری و رمز عبور، نیاز به یک فایل htpasswd دارید که شامل نام‌کاربری و رمزعبور کاربران است. برای ساخت این فایل، از ابزار htpasswd استفاده می‌شود.

برای نصب ابزار htpasswd در سیستم‌های مبتنی بر Debian (مثل Ubuntu) می‌توانید از دستور زیر استفاده کنید:

sudo apt-get install apache2-utils

پس از نصب ابزار، می‌توانید با استفاده از دستور زیر نام‌کاربری و رمز عبور جدیدی برای فایل htpasswd ایجاد کنید:

htpasswd -c /path/to/htpasswd username

با اجرای این دستور از شما خواسته می‌شود که رمز عبور را وارد کنید. این دستور یک ورودی جدید در فایل htpasswd ایجاد خواهد کرد.

گام 2: راه‌اندازی رجیستری با احراز هویت

پس از ایجاد فایل htpasswd، باید آن را به Docker Registry متصل کنید تا از احراز هویت برای دسترسی به رجیستری استفاده شود. دستور زیر را برای راه‌اندازی Docker Registry با احراز هویت اجرا کنید:

docker run -d -p 5000:5000 \
  -v /path/to/htpasswd:/etc/registry/auth/htpasswd \
  --name registry registry:2

در اینجا:

• /path/to/htpasswd: مسیر فایل htpasswd شما است که حاوی اطلاعات کاربران است.

اکنون وقتی کسی تلاش می‌کند به Docker Registry دسترسی پیدا کند، از او خواسته می‌شود که نام‌کاربری و رمز عبور وارد کند.

---

3. مدیریت دسترسی‌ها (Authorization)

پس از پیکربندی احراز هویت، مرحله بعدی کنترل دسترسی به رجیستری است. شما می‌توانید با استفاده از ابزارهایی مثل Docker Registry Access Control Lists (ACLs) و راه‌اندازی کنترل‌های سطح دسترسی، دسترسی به رجیستری را مدیریت کنید.

گام 1: استفاده از کنترل‌های دسترسی سطحی

برای محدود کردن دسترسی به Docker Registry، می‌توانید از پروکسی‌های HTTP برای مدیریت دسترسی‌ها و اعمال محدودیت‌ها استفاده کنید. به‌طور مثال، می‌توانید دسترسی به رجیستری را به IP‌های خاص محدود کنید یا فقط به کاربران خاص مجوز ارسال ایمیج بدهید.

یکی از راه‌ها برای کنترل دسترسی، استفاده از Nginx به‌عنوان یک پراکسی معکوس است که بین کاربران و Docker Registry قرار می‌گیرد. این کار به شما این امکان را می‌دهد که بتوانید سیاست‌های دسترسی پیچیده‌تری تعریف کنید.

برای این منظور، یک کانفیگ ساده برای Nginx می‌تواند به شکل زیر باشد:

server {
    listen 443 ssl;
    server_name registry.example.com;

    ssl_certificate /path/to/domain.crt;
    ssl_certificate_key /path/to/domain.key;

    location / {
        proxy_pass http://localhost:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

در این پیکربندی، Nginx به‌عنوان یک پراکسی معکوس عمل می‌کند و درخواست‌ها را به Docker Registry ارسال می‌کند. همچنین دسترسی‌ها را می‌توان بر اساس IP یا سایر معیارها مدیریت کرد.

---

4. نظارت و لاگ‌گیری از فعالیت‌ها

یکی دیگر از جنبه‌های امنیتی که باید مدنظر قرار دهید، نظارت بر فعالیت‌ها و لاگ‌گیری است. برای این کار، می‌توانید لاگ‌های Docker Registry را بررسی کنید تا متوجه شوید چه کسانی به رجیستری دسترسی داشته‌اند و چه عملیاتی انجام داده‌اند.

برای مشاهده لاگ‌های Docker Registry، می‌توانید از دستور زیر استفاده کنید:

docker logs registry

همچنین، برای پیکربندی لاگ‌های سفارشی، می‌توانید از تنظیمات Docker Registry برای ارسال لاگ‌ها به فایل‌های خاص یا سیستم‌های لاگ‌گیری استفاده کنید.

---

جمع‌بندی

مدیریت دسترسی‌ها و امنیت در Docker Registry یک بخش حیاتی در ایجاد یک زیرساخت ایمن است. با استفاده از احراز هویت، رمزنگاری ارتباطات با HTTPS، و مدیریت دقیق دسترسی‌ها، می‌توانید اطمینان حاصل کنید که تنها کاربران مجاز قادر به دسترسی و ارسال ایمیج‌ها به رجیستری شما هستند. به‌علاوه، استفاده از ابزارهای نظارتی برای بررسی لاگ‌ها و فعالیت‌ها، به شما کمک می‌کند که امنیت و کارایی رجیستری خود را حفظ کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”سازگاری داکر با دیگر رجیستری‌ها” subtitle=”توضیحات کامل”]در دنیای مدرن DevOps و کانتینریزه‌سازی، استفاده از رجیستری‌های خصوصی و عمومی بسیار متداول است. Docker Registry نه‌تنها به شما این امکان را می‌دهد که ایمیج‌ها را به‌صورت محلی ذخیره و مدیریت کنید، بلکه این امکان را فراهم می‌آورد که ایمیج‌ها را به رجیستری‌های ابری ارسال کرده و از آن‌ها برای فرآیندهای مختلف مانند استقرار در محیط‌های مختلف استفاده کنید. در این بخش، به بررسی سازگاری Docker با سه پلتفرم رایج و بزرگ رجیستری ابری می‌پردازیم: Amazon Elastic Container Registry (ECR)، Google Container Registry (GCR)، و Azure Container Registry (ACR).

---

1. Amazon Elastic Container Registry (ECR)

Amazon Elastic Container Registry (ECR) یک سرویس مدیریت شده از AWS است که برای ذخیره‌سازی، مدیریت و اجرای ایمیج‌های Docker طراحی شده است. این سرویس به‌طور کامل با AWS و سرویس‌هایی مانند Amazon ECS و Amazon EKS یکپارچه شده است. ECR به‌عنوان یک رجیستری خصوصی یا عمومی برای ذخیره و مدیریت ایمیج‌های Docker در فضای ابری AWS عمل می‌کند.

گام 1: ورود به ECR

قبل از ارسال یا دریافت ایمیج‌ها از ECR، باید وارد حساب AWS خود شوید و به‌طور خاص از Docker CLI برای ورود به ECR استفاده کنید. دستور زیر به شما کمک می‌کند که وارد ECR شوید:

aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com

در اینجا:

• <region>: منطقه AWS که ECR شما در آن قرار دارد (مثال: us-west-1).
• <aws_account_id>: شناسه حساب AWS شما.

گام 2: ارسال ایمیج به ECR

برای ارسال یک ایمیج به ECR، ابتدا باید یک مخزن (Repository) در ECR ایجاد کنید. پس از ایجاد مخزن، می‌توانید ایمیج‌ها را به آن ارسال کنید.

1. ابتدا مخزن را در ECR ایجاد کنید:

aws ecr create-repository --repository-name my-repo --region <region>

2. سپس، ایمیج Docker را برچسب‌گذاری کرده و آن را به مخزن ارسال کنید:

docker tag my-image:latest <aws_account_id>.dkr.ecr.<region>.amazonaws.com/my-repo:latest
docker push <aws_account_id>.dkr.ecr.<region>.amazonaws.com/my-repo:latest

گام 3: دریافت ایمیج از ECR

برای دریافت ایمیج‌ها از ECR، کافی است از دستور docker pull استفاده کنید:

docker pull <aws_account_id>.dkr.ecr.<region>.amazonaws.com/my-repo:latest

---

2. Google Container Registry (GCR)

Google Container Registry (GCR) یک سرویس ذخیره‌سازی ایمیج‌های Docker است که به‌طور یکپارچه با سرویس‌های Google Cloud مانند Google Kubernetes Engine (GKE) و Google Cloud Run عمل می‌کند. GCR به کاربران این امکان را می‌دهد که به‌طور ایمن ایمیج‌های Docker را ذخیره کنند و از آن‌ها در محیط‌های مختلف استفاده نمایند.

گام 1: ورود به GCR

برای ارسال و دریافت ایمیج‌ها از GCR، ابتدا باید وارد حساب Google Cloud خود شوید و از ابزار gcloud برای احراز هویت استفاده کنید:

gcloud auth login
gcloud auth configure-docker

با استفاده از این دستورات، شما قادر خواهید بود که به‌طور مستقیم با GCR ارتباط برقرار کنید.

گام 2: ارسال ایمیج به GCR

برای ارسال ایمیج‌ها به GCR، ابتدا باید ایمیج خود را برچسب‌گذاری کنید:

docker tag my-image gcr.io/<project-id>/my-repo:latest

سپس می‌توانید ایمیج را به GCR ارسال کنید:

docker push gcr.io/<project-id>/my-repo:latest

گام 3: دریافت ایمیج از GCR

برای دریافت ایمیج‌ها از GCR، از دستور docker pull به‌صورت زیر استفاده می‌کنید:

docker pull gcr.io/<project-id>/my-repo:latest

---

3. Azure Container Registry (ACR)

Azure Container Registry (ACR) یک سرویس مدیریت شده از Microsoft Azure است که برای ذخیره‌سازی و مدیریت ایمیج‌های Docker طراحی شده است. ACR به‌طور یکپارچه با Azure Kubernetes Service (AKS) و سایر سرویس‌های Azure یکپارچه است و به کاربران این امکان را می‌دهد که ایمیج‌های Docker خود را در فضای ابری Azure ذخیره و مدیریت کنند.

گام 1: ورود به ACR

برای ورود به ACR، ابتدا باید از دستور az acr login استفاده کنید. این دستور به‌طور خودکار شما را به رجیستری Azure متصل می‌کند:

az acr login --name <acr-name>

در اینجا <acr-name> نام رجیستری شما در Azure است.

گام 2: ارسال ایمیج به ACR

قبل از ارسال ایمیج، باید ایمیج خود را برچسب‌گذاری کنید تا آن را به ACR ارسال کنید:

docker tag my-image <acr-name>.azurecr.io/my-repo:latest

سپس با استفاده از دستور docker push، ایمیج خود را به رجیستری ارسال کنید:

docker push <acr-name>.azurecr.io/my-repo:latest

گام 3: دریافت ایمیج از ACR

برای دریافت ایمیج‌ها از ACR، از دستور docker pull استفاده کنید:

docker pull <acr-name>.azurecr.io/my-repo:latest

---

جمع‌بندی

سازگاری Docker با رجیستری‌های ابری بزرگ و معتبر مانند Amazon ECR، Google GCR، و Azure ACR این امکان را به توسعه‌دهندگان می‌دهد که به‌راحتی ایمیج‌های Docker را در فضای ابری ذخیره کنند و از آن‌ها در فرآیندهای مختلف CI/CD و استقرار استفاده نمایند. هرکدام از این رجیستری‌ها امکانات خاص خود را دارند، اما اصول ارسال و دریافت ایمیج‌ها به‌طور کلی مشابه است.

با استفاده از دستورات و ابزارهایی که در اینجا معرفی شد، می‌توانید ایمیج‌های خود را به‌راحتی در این پلتفرم‌ها ذخیره و از آن‌ها استفاده کنید. همچنین، تنظیمات امنیتی و احراز هویت مانند استفاده از HTTPS و احراز هویت در این رجیستری‌ها برای محافظت از داده‌ها و ایمیج‌ها بسیار حیاتی است.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. درک ساختار لایه‌های ایمیج”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی نحوه استفاده Docker از لایه‌ها برای ساخت ایمیج‌ها” subtitle=”توضیحات کامل”]یکی از اصول کلیدی در طراحی و مدیریت ایمیج‌های Docker، استفاده از لایه‌ها (Layers) است. لایه‌ها به‌عنوان اجزای اصلی در فرآیند ساخت ایمیج‌های Docker عمل می‌کنند. هر لایه یک تغییر خاص را در ایمیج ایجاد می‌کند و از آن به بعد قابل استفاده و توزیع مجدد است. این لایه‌ها باعث بهینه‌سازی استفاده از فضای ذخیره‌سازی و زمان ساخت ایمیج‌ها می‌شوند.

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

---

1. مفهوم لایه‌ها در Docker

در Docker، هر دستور در Dockerfile که اجرا می‌شود، به‌طور پیش‌فرض یک لایه جدید در ایمیج ایجاد می‌کند. این لایه‌ها تغییرات اعمال‌شده را به ایمیج اضافه می‌کنند و به‌صورت غیرقابل تغییر (immutable) ذخیره می‌شوند. به‌عنوان مثال، وقتی یک دستور RUN در Dockerfile برای نصب یک نرم‌افزار استفاده می‌شود، Docker یک لایه جدید برای این تغییرات ایجاد می‌کند که شامل فایل‌های جدید یا تغییر یافته است.

همچنین لایه‌ها به Docker این امکان را می‌دهند که از کش (cache) استفاده کند. به‌این‌ترتیب، اگر دستوری در Dockerfile تغییر نکند، Docker از لایه کش‌شده استفاده می‌کند و نیاز به اجرای مجدد دستور ندارد.

---

2. نحوه ایجاد لایه‌ها در Dockerfile

هر دستور در Dockerfile می‌تواند منجر به ایجاد یک لایه جدید شود. به‌طور معمول، دستورات زیر موجب ایجاد لایه‌های جدید می‌شوند:

• FROM: اولین لایه، پایه‌گذاری ایمیج را انجام می‌دهد.
• RUN: دستوراتی که برای نصب بسته‌ها یا تغییرات سیستم انجام می‌دهید، هر کدام یک لایه جدید ایجاد می‌کنند.
• COPY و ADD: کپی یا اضافه کردن فایل‌ها به ایمیج، هرکدام یک لایه جدید ایجاد می‌کنند.
• CMD و ENTRYPOINT: این دستورات مشخص می‌کنند که چه برنامه‌ای باید اجرا شود، اما خود لایه ایجاد نمی‌کنند، زیرا این دستورات فقط در هنگام اجرای کانتینر تاثیر دارند.

مثال Dockerfile:

# لایه 1: استفاده از ایمیج پایه
FROM ubuntu:20.04

# لایه 2: به‌روزرسانی و نصب پکیج‌ها
RUN apt-get update && apt-get install -y curl

# لایه 3: اضافه کردن فایل‌ها به ایمیج
COPY ./my-app /app

# لایه 4: اجرای دستور پیش‌فرض
CMD ["python", "/app/app.py"]

در این مثال، چهار لایه مختلف ایجاد می‌شود:

1. لایه‌ای که ایمیج پایه را مشخص می‌کند.
2. لایه‌ای که پکیج‌ها را نصب می‌کند.
3. لایه‌ای که فایل‌ها را به کانتینر کپی می‌کند.
4. لایه‌ای که دستور پیش‌فرض برای اجرای اپلیکیشن را تعیین می‌کند.

---

3. کش لایه‌ها (Caching Layers)

یکی از مزایای استفاده از لایه‌ها در Docker این است که Docker می‌تواند از کش استفاده کند. این کش به این معنی است که اگر لایه‌ای قبلاً ساخته شده باشد و دستورات قبلی تغییر نکرده باشد، Docker از آن لایه کش‌شده استفاده می‌کند و نیازی به ساخت مجدد آن نیست.

به‌عنوان مثال، اگر در دستور RUN apt-get update هیچ تغییری ایجاد نشود، Docker از لایه کش‌شده استفاده می‌کند و زمان ساخت ایمیج کاهش می‌یابد.

نکته:

هر دستوری که در Dockerfile تغییر می‌کند، باعث می‌شود که Docker از کش استفاده نکند و تمامی لایه‌های بعدی از آن دستور نیز دوباره ساخته شوند. بنابراین، ترتیب دستورات در Dockerfile اهمیت زیادی دارد. دستورات غیرضروری که تغییرات زیادی ندارند باید در بالای Dockerfile قرار گیرند تا از کش بهینه‌تری استفاده شود.

---

4. تاثیر لایه‌ها بر اندازه ایمیج‌ها

لایه‌ها تأثیر زیادی بر اندازه نهایی ایمیج دارند. هر لایه‌ای که داده‌های جدیدی به ایمیج اضافه می‌کند، فضا را اشغال می‌کند. بنابراین، مدیریت لایه‌ها و حذف فایل‌های غیرضروری در پایان فرآیند ساخت می‌تواند به کاهش حجم نهایی ایمیج کمک کند.

نکات بهینه‌سازی لایه‌ها:

• کاهش تعداد لایه‌ها: استفاده از دستورات ترکیبی در یک دستور RUN (مثلاً ترکیب apt-get update و apt-get install در یک دستور) می‌تواند تعداد لایه‌ها را کاهش دهد.
• حذف فایل‌های غیرضروری: پس از نصب پکیج‌ها، بهتر است فایل‌های موقت مانند کش‌ها و فایل‌های اضافی حذف شوند تا فضای کمتری اشغال کنند.

مثال بهینه‌سازی:

RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

در این مثال، پس از نصب پکیج‌ها، کش‌های apt-get حذف می‌شوند تا فضای اشغال‌شده کاهش یابد.

---

5. تاثیر لایه‌ها بر عملکرد

لایه‌ها نه‌تنها تأثیر زیادی بر حجم ایمیج دارند، بلکه بر عملکرد اجرای کانتینرها نیز اثر می‌گذارند. Docker برای هر بار اجرای کانتینر از لایه‌های مربوطه استفاده می‌کند و سرعت راه‌اندازی کانتینرها به تعداد لایه‌ها و اندازه آن‌ها بستگی دارد.

• کاهش تعداد لایه‌ها: هرچقدر لایه‌ها کمتر باشند، Docker سریع‌تر می‌تواند کانتینر را اجرا کند.
• کش لایه‌ها: اگر لایه‌های کش‌شده استفاده شوند، زمان ساخت ایمیج‌ها و اجرای کانتینرها کاهش می‌یابد.

---

6. مدیریت لایه‌ها با دستورات Docker

با استفاده از دستورات خاص Docker می‌توانید اطلاعات مربوط به لایه‌های ایمیج‌ها را مشاهده کرده و لایه‌ها را مدیریت کنید:

• docker history : این دستور تاریخچه لایه‌های یک ایمیج را نشان می‌دهد و اطلاعاتی مانند اندازه، تاریخ ایجاد و دستورات به‌کار رفته را در اختیار شما قرار می‌دهد.

  docker history my-image
  

• docker image prune: برای پاک‌سازی لایه‌ها و ایمیج‌های بدون استفاده از سیستم.

  docker image prune -a
  

---

جمع‌بندی

لایه‌ها جزء اساسی ایمیج‌های Docker هستند و استفاده بهینه از آن‌ها می‌تواند به کاهش حجم ایمیج، بهبود عملکرد و کاهش زمان ساخت ایمیج‌ها کمک کند. مدیریت لایه‌ها باید بخشی از استراتژی بهینه‌سازی در طراحی Dockerfile باشد. توجه به استفاده از کش، حذف فایل‌های غیرضروری و ترکیب دستورات برای کاهش تعداد لایه‌ها، می‌تواند تأثیر زیادی بر روی زمان ساخت و اجرای کانتینرها داشته باشد. از این‌رو، آشنایی با نحوه کارکرد لایه‌ها و روش‌های بهینه‌سازی آن‌ها، جزء مهارت‌های کلیدی در کار با Docker است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”درک اهمیت ترتیب دستورات در Dockerfile برای بهینه‌سازی کش ” subtitle=”توضیحات کامل”]ترتیب دستورات در Dockerfile نه‌تنها تأثیر زیادی بر روی زمان ساخت ایمیج‌ها دارد بلکه به بهینه‌سازی استفاده از کش (cache) نیز کمک می‌کند. اگر دستورات به‌درستی مرتب نشوند، ممکن است Docker نتواند از کش به درستی استفاده کند و مجبور به ساخت مجدد لایه‌های مختلف شود، که این مسئله منجر به افزایش زمان ساخت ایمیج‌ها می‌شود.

در این بخش، به‌طور جامع به بررسی اهمیت ترتیب دستورات در Dockerfile خواهیم پرداخت و روش‌هایی را برای بهینه‌سازی کش و کاهش زمان ساخت ایمیج‌ها معرفی خواهیم کرد.

---

1. مفهوم کش در Docker

Docker از کش برای ذخیره‌سازی لایه‌هایی که قبلاً ساخته شده‌اند، استفاده می‌کند. این کش کمک می‌کند که اگر دستورات در Dockerfile تغییر نکنند، Docker نیازی به ساخت مجدد لایه‌ها نداشته باشد. درواقع، هر دستور در Dockerfile که تغییر نکند، از کش استفاده می‌شود و تنها لایه‌هایی که تغییر کرده‌اند، مجدداً ساخته می‌شوند.

به‌عنوان مثال، اگر یک دستور RUN در Dockerfile برای نصب پکیج‌ها تغییر نکند، Docker از کش لایه‌ی مربوط به آن دستور استفاده می‌کند و زمان ساخت ایمیج کاهش می‌یابد. اما اگر دستور RUN تغییر کند، Docker مجبور به ساخت دوباره لایه می‌شود و این فرآیند زمان‌بر خواهد بود.

---

2. چگونگی تاثیر ترتیب دستورات بر کش

دستورات در Dockerfile به ترتیب اجرا می‌شوند و برای هر دستور یک لایه جدید ساخته می‌شود. اگر تغییرات زیادی در دستورات بالاتر صورت گیرد، باعث می‌شود که دستورات بعدی نیز مجدداً اجرا شوند، حتی اگر تغییرات زیادی در آن‌ها نداشته باشند. این امر باعث می‌شود که Docker نتواند از کش به‌خوبی استفاده کند.

بنابراین، مهم است که دستورات را به‌گونه‌ای تنظیم کنیم که تغییرات کمتری در لایه‌های بالاتر ایجاد شود، تا از کش استفاده بیشتری کنیم و زمان ساخت کاهش یابد.

---

3. بهترین روش‌ها برای بهینه‌سازی کش با ترتیب دستورات

برای بهینه‌سازی کش و کاهش زمان ساخت ایمیج، باید دستورات Dockerfile را به‌طور هوشمندانه‌ای ترتیب‌دهی کنیم. در اینجا برخی از بهترین روش‌ها برای مدیریت ترتیب دستورات آورده شده است:

1. استفاده از دستورات پایدار در بالا

دستورات که احتمال تغییر آن‌ها کمتر است، باید در بالای Dockerfile قرار گیرند. این دستورات معمولاً شامل نصب پکیج‌ها یا به‌روزرسانی سیستم‌عامل هستند که معمولاً تغییرات کمتری در طول زمان دارند.

به‌عنوان مثال، دستور RUN apt-get update && apt-get install -y curl که پکیج‌ها را نصب می‌کند، بهتر است در ابتدا قرار گیرد تا از کش آن استفاده شود.

# دستورات کمتر تغییرپذیر باید اول قرار بگیرند
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y curl

در این مثال، اگر دستورات بعدی تغییر کنند، این دستور از کش استفاده می‌کند و نیازی به اجرای دوباره آن نیست.

2. قرار دادن دستورات متغیر و پرچالش در پایین

دستورات متغیری که بیشتر احتمال تغییر آن‌ها وجود دارد، باید در پایین‌ترین قسمت Dockerfile قرار گیرند. به‌عنوان مثال، دستور COPY که به کد اپلیکیشن اشاره می‌کند، معمولاً نیاز به تغییرات مکرر دارد و بهتر است در انتهای Dockerfile قرار گیرد.

# دستورات که به کد اپلیکیشن و فایل‌ها مرتبط هستند باید در پایین قرار بگیرند
COPY ./my-app /app
RUN cd /app && npm install

با قرار دادن این دستورات در پایین، هر بار که کد تغییر کند، تنها این بخش‌ها دوباره اجرا خواهند شد و سایر لایه‌ها از کش استفاده می‌کنند.

3. ترکیب دستورات مشابه در یک دستور واحد

در صورتی که چند دستور مشابه دارید که تأثیر مشابهی بر روی سیستم دارند، می‌توانید آن‌ها را ترکیب کنید تا تعداد لایه‌ها کاهش یابد. این کار باعث می‌شود که Docker بتواند از کش به‌طور بهینه‌تری استفاده کند.

# ترکیب چند دستور RUN در یک دستور برای کاهش تعداد لایه‌ها
RUN apt-get update && apt-get install -y curl && apt-get install -y vim

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

4. استفاده از .dockerignore برای حذف فایل‌های غیرضروری

در هنگام کپی کردن فایل‌ها به کانتینر با دستور COPY، بهتر است از فایل .dockerignore استفاده کنید تا از کپی شدن فایل‌های غیرضروری جلوگیری شود. این کار نه‌تنها حجم ایمیج را کاهش می‌دهد بلکه از تغییرات غیرضروری در لایه‌های اولیه جلوگیری می‌کند.

# نمونه‌ای از فایل .dockerignore
node_modules/
*.log
*.md

این فایل کمک می‌کند تا فقط فایل‌هایی که به ساخت ایمیج نیاز دارند در نظر گرفته شوند و تغییرات غیرضروری در لایه‌ها ایجاد نشود.

---

4. مثال عملی

در اینجا یک مثال از Dockerfile آورده شده است که ترتیب دستورات آن به‌طور بهینه‌ای تنظیم شده است:

# استفاده از ایمیج پایه
FROM node:14

# نصب وابستگی‌ها که احتمال تغییر آن‌ها کمتر است
RUN apt-get update && apt-get install -y curl

# کپی کردن کد اپلیکیشن (دستور که بیشتر تغییر می‌کند)
COPY ./my-app /app

# نصب وابستگی‌های پروژه
RUN cd /app && npm install

# فرمان پیش‌فرض برای اجرای اپلیکیشن
CMD ["node", "/app/server.js"]

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

---

5. ابزارها و روش‌های بررسی کش

برای بررسی کش و لایه‌های مختلف در Dockerfile، می‌توانید از دستور docker build --no-cache استفاده کنید. این دستور به شما این امکان را می‌دهد که فرآیند ساخت را بدون استفاده از کش انجام دهید و در صورت نیاز تغییرات را بررسی کنید.

docker build --no-cache -t my-app .

همچنین می‌توانید با استفاده از دستور docker history تاریخچه لایه‌های یک ایمیج را بررسی کرده و متوجه شوید که هر لایه از چه دستوری ساخته شده است.

docker history my-app

---

جمع‌بندی

ترتیب دستورات در Dockerfile یک عامل بسیار مهم در بهینه‌سازی کش و زمان ساخت ایمیج‌ها است. با قرار دادن دستورات ثابت و کمتر متغیر در ابتدا و دستورات متغیر در انتها، می‌توان از کش بهینه‌تر استفاده کرد و زمان ساخت را کاهش داد. همچنین ترکیب دستورات مشابه و استفاده از فایل .dockerignore برای حذف فایل‌های غیرضروری، می‌تواند به کاهش حجم ایمیج و بهینه‌سازی فرآیند ساخت کمک کند. آگاهی از این نکات و پیاده‌سازی آن‌ها به شما این امکان را می‌دهد که به‌طور مؤثرتری با Docker کار کنید و زمان و منابع کمتری را صرف ساخت و توزیع ایمیج‌ها کنید.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نحوه اضافه کردن لایه جدید به ایمیج” subtitle=”توضیحات کامل”]یکی از مفاهیم کلیدی در Docker، لایه‌ها (Layers) هستند. هر دستور در Dockerfile به‌طور جداگانه یک لایه جدید ایجاد می‌کند. لایه‌ها در واقع نسخه‌ای از سیستم فایل کانتینر هستند که از تغییرات اعمال‌شده توسط دستورات Dockerfile نشأت می‌گیرند. این لایه‌ها از کش (cache) استفاده می‌کنند تا در صورت عدم تغییرات، از پردازش مجدد جلوگیری کنند. در این بخش، به طور کامل به نحوه اضافه کردن لایه جدید به ایمیج در Docker و تأثیرات آن خواهیم پرداخت.

---

1. مفهوم لایه‌ها در Docker

هر دستور در Dockerfile که اجرا می‌شود، یک لایه جدید به ایمیج Docker اضافه می‌کند. این لایه‌ها می‌توانند شامل تغییراتی در سیستم فایل کانتینر، نصب پکیج‌ها، اضافه کردن فایل‌ها یا تنظیمات دیگر باشند. لایه‌ها معمولاً کش می‌شوند تا زمانی که تغییراتی در دستورات ایجاد نشود، Docker بتواند از لایه‌های قبلی استفاده کند و فرآیند ساخت را سریع‌تر انجام دهد.

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

---

2. اضافه کردن لایه جدید با دستورات مختلف در Dockerfile

در Dockerfile، برای ایجاد لایه جدید به سادگی کافی است که از دستورات مختلف مانند RUN, COPY, ADD, CMD, ENTRYPOINT و دیگر دستورات استفاده کنید. هرکدام از این دستورات باعث ایجاد یک لایه جدید می‌شوند. در اینجا به نحوه استفاده از هر یک برای ایجاد لایه‌های جدید خواهیم پرداخت.

1. دستور RUN

دستور RUN معمولاً برای اجرای دستورات shell در زمان ساخت ایمیج استفاده می‌شود. این دستور به‌طور معمول برای نصب پکیج‌ها، به‌روزرسانی سیستم، و اجرای دستورات مربوط به اپلیکیشن‌ها کاربرد دارد. هر بار که از دستور RUN استفاده می‌کنید، Docker یک لایه جدید ایجاد می‌کند که تغییرات آن دستورات را اعمال می‌کند.

# دستور RUN باعث ایجاد لایه جدید می‌شود
RUN apt-get update && apt-get install -y curl

در این مثال، دستور RUN باعث نصب پکیج‌ها و به‌روزرسانی سیستم می‌شود. این تغییرات در یک لایه جدید ذخیره می‌شود.

2. دستور COPY

دستور COPY برای کپی کردن فایل‌ها یا دایرکتوری‌ها از سیستم میزبان به کانتینر استفاده می‌شود. این دستور نیز یک لایه جدید به ایمیج اضافه می‌کند.

# دستور COPY فایل‌ها به کانتینر و ایجاد یک لایه جدید
COPY ./my-app /app

در این مثال، فایل‌ها و دایرکتوری‌های داخل مسیر ./my-app به دایرکتوری /app داخل کانتینر کپی می‌شوند و یک لایه جدید در ایمیج Docker اضافه می‌شود.

3. دستور ADD

دستور ADD مشابه دستور COPY است، با این تفاوت که علاوه بر کپی کردن فایل‌ها از سیستم میزبان به کانتینر، قابلیت‌های اضافی مانند استخراج فایل‌های فشرده را نیز دارد. این دستور نیز یک لایه جدید ایجاد می‌کند.

# استفاده از ADD برای استخراج یک فایل فشرده به کانتینر
ADD my-app.tar.gz /app

در اینجا، دستور ADD فایل فشرده my-app.tar.gz را به دایرکتوری /app در کانتینر استخراج کرده و یک لایه جدید می‌سازد.

4. دستور CMD یا ENTRYPOINT

دستورات CMD و ENTRYPOINT معمولاً برای تعیین دستوری که باید در زمان اجرای کانتینر اجرا شود، استفاده می‌شوند. این دستورات هم باعث اضافه کردن یک لایه جدید به ایمیج می‌شوند، اما این لایه فقط در هنگام اجرای کانتینر به کار می‌رود.

# دستور CMD برای تعیین فرمان پیش‌فرض در هنگام اجرای کانتینر
CMD ["node", "app.js"]

در این مثال، دستور CMD به ایمیج اضافه می‌شود و مشخص می‌کند که وقتی کانتینر اجرا شد، فایل app.js با استفاده از Node.js اجرا شود.

---

3. تأثیر تغییرات لایه‌ها بر کش

زمانی که تغییراتی در Dockerfile ایجاد می‌شود، این تغییرات تنها در لایه‌هایی که تغییر کرده‌اند، اعمال می‌شوند و دیگر لایه‌ها از کش استفاده می‌کنند. به این معنا که اگر شما لایه‌های بالایی را تغییر دهید، Docker مجبور به ساخت مجدد این لایه‌ها خواهد شد، در حالی که لایه‌های بعدی (که تغییر نکرده‌اند) از کش استفاده می‌کنند.

با درک نحوه تغییرات لایه‌ها و ترتیب دستورات در Dockerfile، می‌توانیم از کش به‌خوبی استفاده کنیم و فرآیند ساخت ایمیج را سریع‌تر کنیم. به‌عنوان مثال، اگر تغییرات زیادی در کد اپلیکیشن ایجاد کنید و دستور COPY را جابه‌جا کنید، Docker می‌تواند تنها این لایه را بازسازی کند و دیگر لایه‌ها از کش استفاده خواهند کرد.

---

4. جلوگیری از ایجاد لایه‌های غیرضروری

هر دستور در Dockerfile باعث ایجاد یک لایه جدید می‌شود. بنابراین، برای کاهش تعداد لایه‌ها و بهبود عملکرد، توصیه می‌شود که دستورات مشابه را با هم ترکیب کنید تا از ایجاد لایه‌های اضافی جلوگیری کنید.

# ترکیب چند دستور RUN برای کاهش تعداد لایه‌ها
RUN apt-get update && apt-get install -y curl vim && apt-get clean

در این مثال، دستور RUN برای به‌روزرسانی سیستم و نصب پکیج‌ها و همچنین پاکسازی کش apt در یک دستور ترکیب شده است تا تعداد لایه‌ها کاهش یابد.

---

5. دستور docker history برای بررسی لایه‌ها

برای بررسی لایه‌ها و تغییراتی که در ایمیج‌ها اعمال شده است، می‌توانید از دستور docker history استفاده کنید. این دستور اطلاعات مربوط به لایه‌ها و اندازه هر لایه را نمایش می‌دهد.

docker history my-app

با اجرای این دستور، شما می‌توانید تاریخچه لایه‌ها، اندازه‌های آن‌ها و زمان ساخت هر لایه را مشاهده کنید.

---

جمع‌بندی

در Docker، هر دستور در Dockerfile یک لایه جدید به ایمیج اضافه می‌کند. این لایه‌ها نه‌تنها تغییرات سیستم فایل کانتینر را ذخیره می‌کنند، بلکه از کش نیز برای تسریع فرآیند ساخت استفاده می‌کنند. با درک نحوه استفاده از لایه‌ها و ترتیب دستورات در Dockerfile، می‌توان زمان ساخت ایمیج‌ها را به طور قابل توجهی کاهش داد. همچنین، با ترکیب دستورات مشابه و اجتناب از ایجاد لایه‌های اضافی، می‌توان به بهینه‌سازی ایمیج‌ها و افزایش کارایی دست یافت.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”روش‌های کاهش حجم ایمیج از طریق مدیریت لایه‌ها” subtitle=”توضیحات کامل”]یکی از مهم‌ترین چالش‌هایی که در استفاده از Docker با آن روبرو هستیم، کاهش حجم ایمیج‌ها است. حجم زیاد ایمیج‌ها می‌تواند باعث افزایش زمان بارگذاری و دانلود ایمیج‌ها، کند شدن عملکرد سیستم و حتی مشکلات در منابع سیستم شود. از آنجایی که هر دستور در Dockerfile یک لایه جدید ایجاد می‌کند، مدیریت صحیح این لایه‌ها می‌تواند به کاهش حجم ایمیج و بهبود عملکرد کمک کند. در این بخش، روش‌های مختلفی برای کاهش حجم ایمیج از طریق مدیریت لایه‌ها بررسی می‌شود.

---

1. استفاده از تصاویر پایه (Base Images) سبک

انتخاب تصویر پایه مناسب یکی از راه‌های مهم برای کاهش حجم ایمیج است. بسیاری از تصاویر پایه موجود در Docker Hub، بسته‌های نرم‌افزاری زیادی را به همراه خود دارند که ممکن است برای پروژه شما ضروری نباشد. به جای استفاده از تصاویر پایه سنگین، می‌توانید از تصاویر سبک‌تری مانند alpine یا busybox استفاده کنید.

• تصویر Alpine: یک سیستم‌عامل لینوکسی سبک است که به‌طور خاص برای محیط‌های Docker بهینه‌سازی شده است. این تصویر تنها حدود 5 مگابایت حجم دارد، که نسبت به سایر تصاویر مانند ubuntu یا debian که به ترتیب حدود 200 مگابایت و بیشتر حجم دارند، بسیار کوچک‌تر است.

FROM alpine

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

---

2. کاهش تعداد لایه‌ها از طریق ترکیب دستورات

هر دستور در Dockerfile که اجرا می‌شود، یک لایه جدید ایجاد می‌کند. یکی از بهترین روش‌ها برای کاهش حجم ایمیج، ترکیب دستورات مشابه و اجرای چندین دستور در یک لایه است. این کار می‌تواند تعداد لایه‌ها را کاهش دهد و حجم نهایی ایمیج را به‌طور قابل توجهی کاهش دهد.

• مثال: ترکیب چند دستور RUN

RUN apt-get update && apt-get install -y curl vim && apt-get clean

در این مثال، چند دستور مختلف مانند apt-get update، apt-get install و apt-get clean به یک دستور RUN ترکیب شده‌اند، که باعث کاهش تعداد لایه‌ها می‌شود.

ترکیب دستورات مختلف در یک دستور RUN به معنای اجرای یک عملیات در یک لایه است و این می‌تواند به‌طور مستقیم بر روی کاهش حجم ایمیج تأثیر بگذارد.

---

3. حذف فایل‌ها و داده‌های غیرضروری پس از نصب

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

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

• مثال: حذف فایل‌های غیرضروری

RUN apt-get update && apt-get install -y curl vim && apt-get clean && rm -rf /var/lib/apt/lists/*

در این مثال، پس از نصب بسته‌ها و تمیز کردن کش apt با دستور apt-get clean، فایل‌های اضافی در مسیر /var/lib/apt/lists/* حذف می‌شوند. این عملیات در همان لایه انجام می‌شود و از اضافه شدن فایل‌های غیرضروری به ایمیج جلوگیری می‌کند.

---

4. استفاده از دستورات COPY به جای ADD

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

• مثال: استفاده از دستور COPY به جای ADD

COPY ./my-app /app

در این مثال، فایل‌ها از مسیر ./my-app در میزبان به دایرکتوری /app در کانتینر کپی می‌شوند.

دستور ADD به دلیل ویژگی‌های اضافی خود می‌تواند حجم بیشتری را به ایمیج شما اضافه کند، به‌خصوص زمانی که فایل‌های فشرده را به کانتینر اضافه کنید.

---

5. استفاده از Multi-Stage Builds برای بهینه‌سازی ایمیج

روش دیگری که می‌تواند به کاهش حجم ایمیج کمک کند، استفاده از Multi-Stage Builds است. در این روش، می‌توانید چندین مرحله ساخت را در یک Dockerfile قرار دهید. این امکان را فراهم می‌آورد که بخش‌هایی از فرایند ساخت که برای اپلیکیشن نهایی ضروری نیستند، از ایمیج نهایی حذف شوند.

• مثال: استفاده از Multi-Stage Build

# مرحله اول: ساخت اپلیکیشن
FROM node:14 AS build
WORKDIR /app
COPY . .
RUN npm install && npm run build

# مرحله دوم: ساخت ایمیج نهایی
FROM nginx:alpine
COPY --from=build /app/build /usr/share/nginx/html

در این مثال، در مرحله اول، اپلیکیشن Node.js ساخته می‌شود و در مرحله دوم، فقط فایل‌های ساخته‌شده (مثل فایل‌های استاتیک) به ایمیج نهایی کپی می‌شود. تمام ابزارهای توسعه و فایل‌های مربوط به ساخت در مرحله اول باقی می‌مانند و در مرحله نهایی حذف می‌شوند، که این امر به کاهش حجم نهایی ایمیج کمک می‌کند.

---

6. بررسی و حذف لایه‌های اضافی با استفاده از دستور docker history

برای تحلیل و بررسی لایه‌های ایمیج خود و شناسایی لایه‌های بزرگ یا غیرضروری، می‌توانید از دستور docker history استفاده کنید. این دستور تاریخچه‌ای از لایه‌ها و تغییرات اعمال‌شده به هر لایه را نمایش می‌دهد.

• مثال: استفاده از دستور docker history

docker history my-app

این دستور اطلاعاتی مانند اندازه هر لایه، دستوراتی که باعث ایجاد آن لایه‌ها شده‌اند و زمان ساخت هر لایه را نمایش می‌دهد.

---

جمع‌بندی

کاهش حجم ایمیج‌های Docker یکی از گام‌های اساسی برای بهینه‌سازی استفاده از منابع و تسریع در فرآیندهای CI/CD است. مدیریت لایه‌ها از طریق انتخاب تصاویر پایه سبک، ترکیب دستورات مشابه، حذف فایل‌های غیرضروری، استفاده از Multi-Stage Builds و استفاده از دستور docker history می‌تواند به‌طور چشمگیری حجم ایمیج‌ها را کاهش دهد. با به‌کارگیری این روش‌ها، می‌توانید به بهینه‌سازی عملکرد، کاهش زمان بارگذاری و صرفه‌جویی در فضای ذخیره‌سازی دست یابید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”نحوه استفاده Docker از کش برای بهینه‌سازی فرآیند ساخت ایمیج” subtitle=”توضیحات کامل”]یکی از ویژگی‌های مهم و کاربردی Docker در فرآیند ساخت ایمیج‌ها، استفاده از کش (cache) برای بهینه‌سازی زمان ساخت است. کش در Docker باعث می‌شود که وقتی تغییری در دستوراتی در Dockerfile ایجاد می‌شود، Docker تنها لایه‌هایی که تغییر کرده‌اند را دوباره بسازد و لایه‌های قبلی که تغییر نکرده‌اند، از کش استفاده کنند. این ویژگی سرعت فرآیند ساخت ایمیج را به‌طور چشمگیری افزایش می‌دهد و می‌تواند در پروژه‌های بزرگ و پیچیده باعث کاهش زمان‌های صرف‌شده در مراحل ساخت و توسعه شود.

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

---

1. درک عملکرد کش در Docker

در Docker، کش لایه‌ها به‌طور پیش‌فرض به این صورت عمل می‌کند که وقتی دستوری در Dockerfile اجرا می‌شود، Docker ابتدا بررسی می‌کند که آیا آن لایه قبلاً ساخته شده است یا خیر. اگر این لایه قبلاً ساخته شده و هیچ تغییری در آن ایجاد نشده باشد، Docker از کش استفاده کرده و دیگر لایه‌های آن دستور را دوباره اجرا نمی‌کند.

کش Docker با توجه به ترتیب دستورات در Dockerfile ایجاد می‌شود. اگر تغییر کوچکی در دستوری اعمال کنید که در یک لایه اولیه قرار دارد، Docker تنها لایه‌هایی را که تحت تاثیر این تغییر قرار گرفته‌اند، مجدداً اجرا می‌کند و بقیه لایه‌ها از کش استفاده می‌کنند.

نکته: زمانی که تغییری در یکی از دستورات بالاتر از دستور تغییر یافته در Dockerfile ایجاد شود، تمامی دستورات پایین‌تر از آن باید دوباره اجرا شوند. به‌طور ساده، کش در Docker به ترتیب دستورات حساس است.

---

2. اثرگذاری ترتیب دستورات در کش

ترتیب دستورات در Dockerfile یکی از عوامل کلیدی در عملکرد کش است. Docker ابتدا دستورات بالا را اجرا کرده و کش آن‌ها را ذخیره می‌کند. بنابراین، اگر دستوراتی که تغییرات کمی ایجاد می‌کنند، در ابتدا قرار گیرند، این دستورات به‌سرعت از کش استفاده خواهند کرد و تغییرات در مراحل پایین‌تر، مجدداً اجرا خواهند شد.

برای بهینه‌سازی کش، بهتر است دستورات کم‌تغییر (مانند نصب پکیج‌ها یا کپی کردن فایل‌های ثابت) در ابتدا و دستورات متغیر (مانند کپی کردن فایل‌های اپلیکیشن که ممکن است تغییر کنند) در انتهای Dockerfile قرار گیرند.

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

# دستورات ثابت
FROM node:14
WORKDIR /app
COPY package*.json ./

# دستوراتی که در صورت تغییر در کد اپلیکیشن، تغییر می‌کنند
COPY . .

RUN npm install
RUN npm run build

در این مثال، Docker ابتدا فایل‌های package.json را کپی می‌کند، بنابراین حتی اگر کد اپلیکیشن تغییر کند، کش برای دستورات مربوط به نصب پکیج‌ها (که کمتر تغییر می‌کنند) استفاده خواهد شد.

---

3. استفاده از دستور docker build –no-cache

گاهی اوقات ممکن است نیاز باشد که فرآیند ساخت ایمیج را بدون استفاده از کش اجرا کنیم. این کار می‌تواند در مواقعی که کش به‌طور غیرمنتظره‌ای باعث ایجاد مشکلاتی می‌شود یا زمانی که می‌خواهیم تغییرات جدید در تمام لایه‌ها اعمال شوند، مفید باشد. دستور docker build --no-cache باعث می‌شود که Docker هیچ‌گونه کشی را در هنگام ساخت استفاده نکند و تمام لایه‌ها را از ابتدا بسازد.

• مثال: استفاده از دستور docker build --no-cache

docker build --no-cache -t my-app .

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

---

4. استفاده از دستور docker build –build-arg

در بعضی موارد، ممکن است نیاز داشته باشیم که برخی متغیرها را در طول ساخت ایمیج تغییر دهیم، اما در عین حال بخواهیم از کش برای قسمت‌هایی که تغییر نکرده‌اند، استفاده کنیم. در این موارد، استفاده از --build-arg می‌تواند مفید باشد. این دستور به ما اجازه می‌دهد که متغیرهایی را هنگام ساخت ایمیج تنظیم کنیم و در صورت تغییر در این متغیرها، تنها لایه‌هایی که تحت تاثیر قرار گرفته‌اند، دوباره ساخته شوند.

• مثال: استفاده از دستور --build-arg

# Dockerfile
FROM node:14
ARG APP_ENV=production
COPY ./src /app

RUN if [ "$APP_ENV" = "production" ]; then npm install --production; else npm install; fi

docker build --build-arg APP_ENV=development -t my-app .

در این مثال، متغیر APP_ENV در طول ساخت ایمیج تنظیم می‌شود و به‌طور هوشمند از کش استفاده می‌شود تا تنها تغییرات لازم در لایه‌های مربوطه اعمال شود.

---

5. بهینه‌سازی کش برای تغییرات فایل‌ها و کاتالوگ‌ها

زمانی که شما از دستور COPY یا ADD برای کپی کردن فایل‌ها به کانتینر استفاده می‌کنید، Docker بررسی می‌کند که آیا فایل‌های کپی شده تغییر کرده‌اند یا خیر. اگر فایل‌ها تغییر کنند، کش برای لایه مربوطه معتبر نخواهد بود و باید دوباره ساخته شود.

برای بهینه‌سازی کش، می‌توانید فقط فایل‌های ضروری و یا فایل‌هایی که تغییر نمی‌کنند را در مراحل اولیه کپی کنید، و فایل‌هایی که تغییرات زیادی دارند (مثل کد اپلیکیشن) را در مراحل آخر قرار دهید.

مثال: استفاده از کش به‌طور هوشمند

# مراحل اولیه کپی
COPY package*.json ./

# مرحله بعدی فقط زمانی که کد اپلیکیشن تغییر می‌کند
COPY . . 

در این مثال، اگر کد اپلیکیشن تغییر کند، تنها لایه‌ای که مربوط به کپی کردن کل کد است مجدداً ساخته می‌شود، در حالی که سایر لایه‌ها از کش استفاده می‌کنند.

---

6. استفاده از دستور docker build –cache-from

دستور docker build --cache-from این امکان را می‌دهد که از کش موجود در ایمیج‌های دیگر استفاده کنیم. این ویژگی به‌ویژه زمانی مفید است که بخواهید از کش یک رجیستری خصوصی یا عمومی برای فرآیند ساخت استفاده کنید، به‌ویژه در زمان‌هایی که شما و تیم شما به‌طور مداوم با یک ایمیج مشترک کار می‌کنید.

• مثال: استفاده از دستور --cache-from

docker build --cache-from=my-repo/my-image:latest -t my-app .

این دستور باعث می‌شود که Docker از کش موجود در ایمیج my-repo/my-image:latest استفاده کند، که می‌تواند زمان ساخت را به‌طور قابل توجهی کاهش دهد.

---

جمع‌بندی

استفاده از کش لایه‌ها در Docker به‌عنوان یکی از ویژگی‌های قدرتمند، می‌تواند زمان ساخت ایمیج‌ها را به‌طور چشمگیری کاهش دهد. مدیریت بهینه کش به‌ویژه با رعایت ترتیب دستورات در Dockerfile، استفاده از دستورات --no-cache و --build-arg، بهینه‌سازی فایل‌های کپی شده و استفاده از دستور --cache-from می‌تواند به افزایش سرعت ساخت ایمیج‌ها و کاهش زمان توسعه کمک کند. به‌طور کلی، استفاده از کش در Docker به یکی از ابزارهای اصلی در بهینه‌سازی فرآیند ساخت و اجرای کانتینرها تبدیل شده است.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. امنیت ایمیج‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”امضای ایمیج‌ها (Image Signing)” subtitle=”توضیحات کامل”]یکی از مسائل حیاتی در مدیریت و استفاده از Docker ایمیج‌ها، اطمینان از امنیت و اصالت آن‌ها است. امضای ایمیج‌ها یکی از روش‌های مؤثر در اطمینان از صحت و اعتبار ایمیج‌های Docker است. Docker Content Trust (DCT) ابزاری است که به کاربران این امکان را می‌دهد تا ایمیج‌ها را به‌صورت دیجیتال امضا کنند و اطمینان حاصل کنند که ایمیج‌ها از منابع معتبر و قابل اعتماد دریافت شده‌اند.

در این بخش، به بررسی نحوه استفاده از Docker Content Trust برای امضای ایمیج‌ها خواهیم پرداخت و مراحل پیاده‌سازی آن را به‌طور کامل توضیح خواهیم داد.

---

1. مفهوم Docker Content Trust (DCT)

Docker Content Trust (DCT) یک ویژگی امنیتی است که در Docker برای تأیید اعتبار و اصالت ایمیج‌های Docker استفاده می‌شود. زمانی که DCT فعال است، Docker تنها به ایمیج‌هایی اجازه می‌دهد که به‌صورت دیجیتال امضا شده باشند و از منابع معتبر منتشر شده باشند. این ویژگی به‌ویژه در سازمان‌ها و محیط‌های حساس به امنیت بسیار کاربردی است، زیرا می‌تواند از ورود ایمیج‌های تغییر یافته یا مخرب جلوگیری کند.

DCT با استفاده از سیستم امضای دیجیتال GPG (GNU Privacy Guard) عمل می‌کند و امضای ایمیج‌ها را بر اساس کلیدهای خصوصی و عمومی انجام می‌دهد. این کلیدها برای اطمینان از اینکه فقط افراد یا سیستم‌های مجاز می‌توانند ایمیج‌ها را منتشر کنند، استفاده می‌شوند.

---

2. فعال‌سازی Docker Content Trust

برای استفاده از Docker Content Trust، باید این ویژگی را به‌صورت دستی فعال کنید. به‌طور پیش‌فرض، DCT غیرفعال است. زمانی که Docker Content Trust فعال باشد، هنگام ارسال (push) یا دریافت (pull) ایمیج‌ها از رجیستری، Docker تنها ایمیج‌های امضا شده را مجاز به بارگذاری خواهد کرد.

برای فعال‌سازی DCT، می‌توانید از متغیر محیطی DOCKER_CONTENT_TRUST استفاده کنید. برای فعال کردن این ویژگی، مقدار این متغیر را روی 1 تنظیم کنید:

• فعال‌سازی Docker Content Trust

export DOCKER_CONTENT_TRUST=1

پس از فعال‌سازی این متغیر، هنگام push یا pull ایمیج‌ها، Docker تنها به ایمیج‌هایی که امضا شده‌اند، اجازه می‌دهد.

• غیرفعال‌سازی Docker Content Trust

export DOCKER_CONTENT_TRUST=0

اگر بخواهید DCT را غیرفعال کنید، می‌توانید از دستور بالا استفاده کنید. در این حالت، Docker به شما اجازه می‌دهد تا ایمیج‌هایی که امضا نشده‌اند را نیز ارسال و دریافت کنید.

---

3. امضای ایمیج‌ها با استفاده از Docker Content Trust

برای امضای یک ایمیج با استفاده از Docker Content Trust، شما نیاز به یک کلید خصوصی برای امضا دارید. این کلید خصوصی به‌طور خودکار توسط Docker ایجاد می‌شود زمانی که اولین‌بار از DCT استفاده می‌کنید.

پس از فعال کردن Docker Content Trust، برای ارسال یک ایمیج به رجیستری (مثلاً Docker Hub)، Docker به‌طور خودکار از کلید خصوصی برای امضای ایمیج استفاده خواهد کرد.

• ارسال (push) ایمیج به رجیستری با استفاده از DCT

docker push my-repo/my-image:tag

وقتی دستور docker push را اجرا می‌کنید، Docker به‌طور خودکار از کلید خصوصی برای امضای ایمیج استفاده خواهد کرد و سپس آن را به رجیستری ارسال می‌کند.

---

4. بررسی امضای ایمیج‌ها

برای بررسی اینکه آیا یک ایمیج امضا شده است یا نه، می‌توانید از دستور docker trust inspect استفاده کنید. این دستور اطلاعات مربوط به امضای ایمیج را نمایش می‌دهد و شما می‌توانید تأیید کنید که ایمیج به‌درستی امضا شده است.

• بررسی امضای ایمیج

docker trust inspect my-repo/my-image:tag

این دستور اطلاعاتی مانند زمان امضا، شخص یا سیستم امضاکننده، و وضعیت امضا را نمایش می‌دهد.

---

5. چرا باید ایمیج‌ها را امضا کنیم؟

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

• اطمینان از اصالت ایمیج‌ها: با استفاده از امضا، می‌توانید از صحت ایمیج‌ها و جلوگیری از حملات مخرب (مانند تغییرات غیرمجاز در ایمیج‌ها) اطمینان حاصل کنید.
• امنیت بیشتر در محیط‌های چندکاربره: زمانی که چندین تیم یا توسعه‌دهنده از یک رجیستری مشترک استفاده می‌کنند، امضای ایمیج‌ها می‌تواند از ورود ایمیج‌های مخرب جلوگیری کند.
• گزارش‌گیری و ردیابی: با استفاده از امضاهای دیجیتال، شما می‌توانید ردیابی کنید که چه کسی یا کدام سیستم ایمیج را امضا کرده است. این امر باعث شفافیت بیشتر در فرآیند مدیریت ایمیج‌ها می‌شود.

---

6. دستور docker trust

Docker برای مدیریت امضاهای ایمیج‌ها دستور جدیدی به نام docker trust معرفی کرده است که به شما این امکان را می‌دهد تا عملیات مختلف مربوط به امضای ایمیج‌ها را انجام دهید. این دستورات می‌توانند برای اضافه کردن کلیدهای عمومی، مشاهده وضعیت امضای ایمیج‌ها، و مدیریت دسترسی‌ها استفاده شوند.

• لیست کلیدهای عمومی موجود در Docker Content Trust

docker trust key list

• افزودن کلید عمومی به ایمیج

docker trust signer add my-repo/my-image:tag <public-key-file>

• حذف یک کلید عمومی

docker trust signer remove my-repo/my-image:tag <public-key>

---

7. امنیت در استفاده از Docker Content Trust

حتی با استفاده از Docker Content Trust برای امضای ایمیج‌ها، هنوز باید به مسائل امنیتی دیگری توجه کنید:

• حفاظت از کلیدهای خصوصی: کلید خصوصی که برای امضای ایمیج‌ها استفاده می‌شود باید به‌طور ایمن نگهداری شود. از دست دادن یا افشای کلید خصوصی می‌تواند امنیت ایمیج‌های شما را به خطر بیندازد.
• مدیریت دسترسی به رجیستری: باید دسترسی به رجیستری و کلیدهای عمومی را محدود کنید تا از استفاده غیرمجاز از ایمیج‌های امضا شده جلوگیری شود.
• بروزرسانی و بازبینی کلیدها: کلیدهای عمومی و خصوصی باید به‌طور دوره‌ای بازبینی و بروزرسانی شوند تا از امنیت بیشتر اطمینان حاصل شود.

---

جمع‌بندی

Docker Content Trust ابزاری بسیار مفید برای اطمینان از امنیت و اصالت ایمیج‌های Docker است. با استفاده از DCT و امضای دیجیتال، می‌توانید از ورود ایمیج‌های مخرب جلوگیری کرده و اعتماد به‌تری به ایمیج‌های خود داشته باشید. فعال‌سازی DCT، امضای ایمیج‌ها، و بررسی آن‌ها با استفاده از دستور docker trust inspect از جمله اقداماتی است که می‌توانید برای حفظ امنیت سیستم‌های Docker خود انجام دهید. همچنین، با رعایت نکات امنیتی و مدیریت دسترسی‌ها، می‌توانید اطمینان حاصل کنید که ایمیج‌های شما در محیط‌های حساس و تولیدی از امنیت بالایی برخوردارند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اسکن آسیب‌پذیری‌ها” subtitle=”توضیحات کامل”]امنیت ایمیج‌های Docker یکی از جنبه‌های حیاتی در عملیات و پیاده‌سازی نرم‌افزار است. از آنجایی که Docker به‌طور گسترده‌ای در محیط‌های تولیدی و حتی برای توسعه استفاده می‌شود، آسیب‌پذیری‌ها و تهدیدات امنیتی می‌توانند تأثیرات زیادی داشته باشند. یکی از روش‌های مؤثر برای شناسایی آسیب‌پذیری‌ها، استفاده از ابزارهایی است که به‌طور خودکار ایمیج‌های Docker را اسکن کرده و مشکلات امنیتی آن‌ها را شناسایی می‌کنند. این ابزارها به توسعه‌دهندگان و تیم‌های امنیتی کمک می‌کنند تا مشکلات امنیتی را پیش از استقرار نرم‌افزار در محیط‌های تولیدی شناسایی کنند.

در این بخش، به بررسی ابزارهایی مانند docker scan و ابزارهای شخص ثالث برای بررسی ایمیج‌ها از نظر امنیت خواهیم پرداخت و نحوه استفاده از آن‌ها را توضیح خواهیم داد.

---

1. ابزار Docker Scan

یکی از ابزارهایی که Docker به‌طور پیش‌فرض برای اسکن آسیب‌پذیری‌ها ارائه می‌دهد، ابزار docker scan است. این ابزار به شما امکان می‌دهد که ایمیج‌های Docker را از نظر آسیب‌پذیری‌های شناخته‌شده بررسی کنید و اطلاعات مربوط به تهدیدات امنیتی را دریافت کنید. این ویژگی از پایگاه داده Snyk برای اسکن و شناسایی آسیب‌پذیری‌ها استفاده می‌کند.

نصب Docker Scan

برای استفاده از دستور docker scan ابتدا باید مطمئن شوید که نسخه Docker شما از این ابزار پشتیبانی می‌کند. در صورتی که Docker شما به‌روز باشد، این ابزار به‌طور پیش‌فرض نصب شده است.

در صورت نیاز به نصب، می‌توانید نسخه‌ی به‌روز Docker را دانلود کرده و نصب کنید.

نحوه استفاده از docker scan

دستور docker scan به‌راحتی از طریق خط فرمان در دسترس است. برای استفاده از این ابزار، تنها کافی است ایمیجی که قصد اسکن آن را دارید به‌عنوان آرگومان به دستور docker scan وارد کنید.

• اسکن یک ایمیج برای آسیب‌پذیری‌ها:

docker scan my-repo/my-image:tag

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

• اسکن یک ایمیج با استفاده از گزینه‌های اضافی:

docker scan --severity high my-repo/my-image:tag

با استفاده از این گزینه، می‌توانید شدت آسیب‌پذیری‌ها را فیلتر کنید و تنها آسیب‌پذیری‌های با سطح شدت بالا را مشاهده کنید.

---

2. جزئیات گزارش اسکن

پس از اجرای دستور docker scan، گزارشی شامل اطلاعات زیر دریافت خواهید کرد:

• آسیب‌پذیری‌های شناسایی‌شده: لیستی از آسیب‌پذیری‌هایی که در ایمیج شناسایی شده‌اند.
• شدت آسیب‌پذیری: سطح خطر آسیب‌پذیری‌ها می‌تواند شامل سه سطح زیر باشد:
  • High: آسیب‌پذیری‌های بحرانی که باید فوراً اصلاح شوند.
  • Medium: آسیب‌پذیری‌هایی که باید مورد بررسی قرار گیرند و اصلاح شوند.
  • Low: آسیب‌پذیری‌های کم‌خطر که معمولاً نیازی به اقدام فوری ندارند.
• راه‌حل‌های پیشنهادی: برای هر آسیب‌پذیری، راه‌حل یا پیشنهاداتی برای رفع آن ارائه می‌شود.
• بروزرسانی‌ها و نسخه‌ها: اگر آسیب‌پذیری‌ها به دلیل نسخه‌های قدیمی کتابخانه‌ها یا نرم‌افزارهای موجود در ایمیج باشد، معمولاً نسخه‌های به‌روزتر پیشنهاد می‌شود.

---

3. ابزارهای شخص ثالث برای اسکن آسیب‌پذیری‌ها

علاوه بر ابزار docker scan که در Docker پیش‌فرض است، ابزارهای شخص ثالث دیگری نیز برای اسکن آسیب‌پذیری‌های ایمیج‌های Docker وجود دارند که امکانات گسترده‌تری را ارائه می‌دهند. در ادامه به معرفی برخی از این ابزارها می‌پردازیم.

Snyk

Snyk یکی از محبوب‌ترین ابزارهای شخص ثالث برای اسکن امنیتی است که به‌طور خاص برای اسکن کردن آسیب‌پذیری‌ها در Docker طراحی شده است. این ابزار می‌تواند به‌طور خودکار ایمیج‌های Docker را بررسی کرده و آسیب‌پذیری‌های موجود در آن‌ها را شناسایی کند.

• ویژگی‌ها:
  • شناسایی آسیب‌پذیری‌های شناخته‌شده در ایمیج‌های Docker.
  • قابلیت اسکن در زمان توسعه (CI/CD).
  • گزارش‌دهی دقیق و پیشنهادات برای رفع آسیب‌پذیری‌ها.
  • پشتیبانی از محیط‌های Docker و Kubernetes.

برای استفاده از Snyk، شما باید ابتدا حساب کاربری بسازید و ابزار را نصب کنید:

npm install -g snyk

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

snyk container test my-repo/my-image:tag

Trivy

Trivy یک ابزار اسکن آسیب‌پذیری رایگان و متن‌باز است که به‌طور ویژه برای Docker و Kubernetes طراحی شده است. Trivy می‌تواند به‌سرعت آسیب‌پذیری‌ها را شناسایی کرده و گزارشی جامع از مشکلات امنیتی ارائه دهد.

• ویژگی‌ها:
  • پشتیبانی از آسیب‌پذیری‌های سیستم‌عامل و نرم‌افزارهای موجود در ایمیج.
  • سرعت بالا در اسکن و دقت بالای شناسایی آسیب‌پذیری‌ها.
  • پشتیبانی از فایل‌های Dockerfile و Kubernetes YAML.

برای نصب Trivy، ابتدا باید آن را از طریق دستور زیر نصب کنید:

brew install aquasecurity/trivy/trivy

برای اسکن یک ایمیج Docker:

trivy image my-repo/my-image:tag

Clair

Clair یک ابزار متن‌باز است که توسط شرکت CoreOS توسعه داده شده است. این ابزار به‌طور ویژه برای شناسایی آسیب‌پذیری‌ها در Docker images طراحی شده است. Clair به‌طور عمده در محیط‌های بزرگ و سازمانی استفاده می‌شود.

• ویژگی‌ها:
  • اسکن آسیب‌پذیری‌های سیستم‌عامل و کتابخانه‌های داخل ایمیج.
  • قابلیت یکپارچه‌سازی با سیستم‌های CI/CD.
  • پشتیبانی از ذخیره‌سازی نتایج اسکن در پایگاه داده‌ها برای تجزیه و تحلیل بیشتر.

---

4. اسکن آسیب‌پذیری‌ها در محیط CI/CD

در بسیاری از سازمان‌ها، ایمیج‌های Docker به‌طور خودکار در یک فرآیند CI/CD ساخته و منتشر می‌شوند. اسکن امنیتی در این فرآیند می‌تواند به‌صورت خودکار اجرا شود تا هرگونه آسیب‌پذیری به محض ساخت یا دریافت ایمیج شناسایی شود.

برای این کار، می‌توانید ابزارهای اسکن مانند docker scan، Snyk، Trivy یا Clair را در pipeline خود گنجانده و مطمئن شوید که هیچ ایمیج آسیب‌پذیر وارد محیط تولید نمی‌شود.

---

جمع‌بندی

اسکن آسیب‌پذیری‌ها یکی از مهم‌ترین گام‌ها در تأمین امنیت ایمیج‌های Docker است. ابزارهایی مانند docker scan و ابزارهای شخص ثالث مانند Snyk، Trivy و Clair می‌توانند به‌طور مؤثری آسیب‌پذیری‌های امنیتی موجود در ایمیج‌های Docker را شناسایی کرده و به شما کمک کنند تا مشکلات امنیتی را پیش از استقرار ایمیج‌ها در محیط‌های تولیدی رفع کنید. استفاده از این ابزارها و گنجاندن آن‌ها در فرآیند CI/CD می‌تواند نقش مهمی در افزایش امنیت و کاهش ریسک‌های حملات سایبری ایفا کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”به‌روزرسانی ایمیج‌ها” subtitle=”توضیحات کامل”]در دنیای نرم‌افزار و DevOps، به‌روزرسانی منظم و مداوم ایمیج‌ها برای رفع مشکلات امنیتی یک گام حیاتی به شمار می‌آید. در صورتی که شما ایمیج‌های Docker خود را به‌طور مداوم به‌روز نکنید، ممکن است آسیب‌پذیری‌های شناخته‌شده‌ای در سیستم‌عامل‌ها یا نرم‌افزارهای موجود در آن‌ها وجود داشته باشد که باعث تهدید امنیتی شود. به همین دلیل، داشتن رویکردی منظم برای به‌روزرسانی ایمیج‌ها، نه تنها عملکرد بهینه را تضمین می‌کند بلکه امنیت کلاستر و محیط تولیدی شما را نیز ارتقا می‌بخشد.

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

---

1. چرا به‌روزرسانی ایمیج‌ها اهمیت دارد؟

با توجه به اینکه Docker از ایمیج‌ها برای ساخت کانتینرها استفاده می‌کند، هرگونه آسیب‌پذیری یا خطا در این ایمیج‌ها می‌تواند به‌طور مستقیم بر عملکرد و امنیت کانتینرها تأثیر بگذارد. به‌روزرسانی منظم ایمیج‌ها برای رفع مشکلات امنیتی، رفع اشکالات نرم‌افزاری و دریافت ویژگی‌های جدید از اهمیت زیادی برخوردار است. در صورتی که آسیب‌پذیری‌ها در ایمیج‌ها نادیده گرفته شوند، ممکن است به تهدیدات امنیتی جدی منجر شود.

مزایای به‌روزرسانی ایمیج‌ها عبارت‌اند از:

• رفع آسیب‌پذیری‌های امنیتی: اکثر نرم‌افزارهای موجود در ایمیج‌ها ممکن است با گذشت زمان دارای آسیب‌پذیری‌هایی شوند که توسط توسعه‌دهندگان یا سازمان‌ها منتشر می‌شود.
• بهبود عملکرد و رفع باگ‌ها: با به‌روزرسانی، ممکن است اشکالات و باگ‌های موجود در نسخه‌های قبلی حل شوند.
• ارتقا به نسخه‌های جدیدتر نرم‌افزار: ویژگی‌ها و بهبودهای جدیدی که در نسخه‌های به‌روزتر نرم‌افزارها اضافه می‌شود.

---

2. روش‌های به‌روزرسانی ایمیج‌ها

برای به‌روزرسانی ایمیج‌ها، چندین روش وجود دارد که می‌تواند به شما کمک کند تا فرآیند به‌روزرسانی به‌طور مؤثر انجام گیرد. این روش‌ها شامل بررسی به‌روزرسانی‌های موجود، اصلاح Dockerfileها و بازسازی ایمیج‌ها می‌باشد.

2.1. چک کردن به‌روزرسانی‌های موجود در Docker Hub

هر زمان که یک نسخه جدید از یک ایمیج در Docker Hub منتشر می‌شود، شما می‌توانید از دستور docker pull برای دریافت نسخه جدید استفاده کنید. برای مثال، اگر شما از یک ایمیج پایه مثل ubuntu استفاده می‌کنید، می‌توانید دستور زیر را برای به‌روزرسانی آن اجرا کنید:

docker pull ubuntu:latest

این دستور آخرین نسخه از ایمیج ubuntu را از Docker Hub دریافت می‌کند. شما می‌توانید نسخه خاصی از هر ایمیج را با تعیین تگ مربوطه نیز بارگیری کنید.

2.2. تغییر نسخه‌ها و به‌روزرسانی Dockerfile

در صورتی که در Dockerfile خود از نسخه خاصی از یک ایمیج پایه استفاده کرده‌اید، باید نسخه جدید آن را وارد کنید. برای مثال، اگر در Dockerfile خود از ایمیج node:14 استفاده کرده‌اید و نسخه جدیدتری از Node.js منتشر شده است، باید نسخه جدید آن را به‌روزرسانی کنید:

FROM node:16

سپس با اجرای دستور docker build، می‌توانید ایمیج جدید را بسازید.

2.3. بازسازی ایمیج‌ها و کانتینرها

پس از انجام تغییرات در Dockerfile، لازم است که ایمیج جدید را بسازید. برای این کار می‌توانید از دستور docker build استفاده کنید:

docker build -t my-image:latest .

سپس، می‌توانید کانتینرهای جدید را از ایمیج به‌روز شده اجرا کنید. اگر از کانتینرهای قدیمی استفاده می‌کنید، باید آن‌ها را متوقف کرده و کانتینرهای جدید را با استفاده از ایمیج جدید راه‌اندازی کنید:

docker run -d --name my-container my-image:latest

---

3. استراتژی‌های به‌روزرسانی مداوم ایمیج‌ها

برای اطمینان از به‌روزرسانی مداوم ایمیج‌ها و عدم وجود آسیب‌پذیری‌های امنیتی در سیستم، می‌توانید از استراتژی‌های مختلف استفاده کنید:

3.1. استفاده از CI/CD برای به‌روزرسانی خودکار

یکی از بهترین روش‌ها برای اطمینان از به‌روزرسانی مداوم ایمیج‌ها، گنجاندن فرآیند به‌روزرسانی در pipelineهای CI/CD است. در این حالت، هر زمان که یک تغییر در کد منبع یا Dockerfile رخ دهد، به‌طور خودکار یک ایمیج جدید ساخته می‌شود و سپس این ایمیج به Docker Registry ارسال می‌شود.

برای مثال، در یک سیستم CI/CD مانند Jenkins، می‌توانید مراحل زیر را برای به‌روزرسانی ایمیج‌ها ایجاد کنید:

1. تغییرات در کد و Dockerfile را شناسایی کنید.
2. با استفاده از دستور docker build ایمیج جدید بسازید.
3. ایمیج جدید را به Docker Registry ارسال کنید با دستور docker push.
4. کانتینرهای قدیمی را متوقف کرده و با استفاده از ایمیج جدید، کانتینرهای جدید را راه‌اندازی کنید.

3.2. اسکن ایمیج‌ها برای آسیب‌پذیری‌ها قبل از به‌روزرسانی

قبل از به‌روزرسانی هر ایمیج، بهتر است آن را از نظر آسیب‌پذیری‌های امنیتی اسکن کنید. این کار می‌تواند به‌صورت خودکار در pipeline CI/CD انجام گیرد. ابزارهایی مانند docker scan یا Trivy می‌توانند برای اسکن ایمیج‌ها از آسیب‌پذیری‌ها به‌کار روند و فقط ایمیج‌هایی که امن هستند برای تولید استفاده شوند.

3.3. استفاده از نسخه‌بندی برای نگهداری نسخه‌های قبلی

به‌جای اینکه تنها نسخه latest را در Dockerfile و سایر بخش‌های پروژه خود استفاده کنید، توصیه می‌شود که از نسخه‌های خاص استفاده کنید. این کار کمک می‌کند تا همیشه بتوانید به نسخه‌های قبلی بازگردید و از ایجاد مشکلات غیرمنتظره جلوگیری کنید. به‌عنوان مثال، به جای ubuntu:latest می‌توانید از ubuntu:20.04 استفاده کنید.

3.4. آموزش و آگاه‌سازی تیم‌ها

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

---

جمع‌بندی

به‌روزرسانی ایمیج‌ها برای رفع مشکلات امنیتی نه‌تنها در محیط‌های توسعه، بلکه در محیط‌های تولیدی نیز اهمیت دارد. استفاده از ابزارهای اسکن آسیب‌پذیری، پیاده‌سازی فرآیندهای CI/CD خودکار برای به‌روزرسانی ایمیج‌ها، و آگاهی از بهترین شیوه‌ها در هنگام استفاده از ایمیج‌های Docker می‌تواند به‌طور قابل توجهی امنیت و کارایی سیستم شما را ارتقا دهد. در نهایت، رعایت این رویکردها و استفاده از به‌روزترین نسخه‌های نرم‌افزارهای پایه می‌تواند به محافظت از سیستم‌ها و جلوگیری از تهدیدات امنیتی کمک کند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. بهترین شیوه‌ها در مدیریت ایمیج‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از ایمیج‌های رسمی (Official Images) در Docker Hub” subtitle=”توضیحات کامل”]در دنیای Docker، ایمیج‌های رسمی (Official Images) به ایمیج‌هایی اطلاق می‌شود که توسط سازندگان نرم‌افزار یا تیم‌های توسعه‌دهنده آن نرم‌افزار ساخته و نگهداری می‌شوند و در Docker Hub به‌طور مستقیم در دسترس قرار دارند. این ایمیج‌ها به دلیل این‌که توسط تیم‌های معتبر و حرفه‌ای توسعه یافته‌اند، از امنیت بالا و پایداری مطلوبی برخوردارند و به‌طور گسترده‌ای برای راه‌اندازی سرویس‌های مختلف در محیط‌های توسعه و تولید استفاده می‌شوند.

در این بخش، ما به بررسی مزایای استفاده از ایمیج‌های رسمی، نحوه یافتن و استفاده از آن‌ها، و همچنین بهترین شیوه‌ها برای استفاده از این ایمیج‌ها خواهیم پرداخت.

---

1. مزایای استفاده از ایمیج‌های رسمی Docker

استفاده از ایمیج‌های رسمی در پروژه‌های Docker می‌تواند مزایای زیادی داشته باشد. این مزایا به توسعه‌دهندگان کمک می‌کند تا با خیالی آسوده‌تری از Docker استفاده کنند و در عین حال از کارایی و امنیت بالاتری بهره‌مند شوند. برخی از این مزایا عبارتند از:

1.1. امنیت بالا

ایمیج‌های رسمی معمولاً توسط تیم‌های توسعه‌دهنده و یا گروه‌های معتبر نظارت می‌شوند. این تیم‌ها اطمینان حاصل می‌کنند که ایمیج‌های منتشر شده از آسیب‌پذیری‌های امنیتی رایج مصون هستند. به‌علاوه، ایمیج‌های رسمی به‌طور مرتب به‌روزرسانی می‌شوند تا آسیب‌پذیری‌های امنیتی جدید برطرف گردند.

1.2. پایداری و سازگاری

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

1.3. پشتیبانی از مستندات کامل

ایمیج‌های رسمی معمولاً مستندات رسمی و جامعی دارند که توضیحاتی در مورد نحوه استفاده، پیکربندی، و حل مشکلات رایج در آن‌ها ارائه می‌دهد. این مستندات می‌تواند به‌ویژه برای مبتدیان مفید باشد.

1.4. عدم نیاز به ساخت ایمیج از صفر

برای بسیاری از نرم‌افزارهای رایج، مانند Redis، MySQL، PostgreSQL، و Node.js، ایمیج‌های رسمی در Docker Hub موجود است. این یعنی دیگر نیازی نیست که شما از صفر ایمیج بسازید؛ فقط کافی است که از ایمیج‌های رسمی استفاده کنید.

1.5. به‌روزرسانی‌ها و تغییرات مرتب

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

---

2. یافتن ایمیج‌های رسمی در Docker Hub

Docker Hub بزرگ‌ترین رجیستری عمومی برای ایمیج‌های Docker است که تعداد زیادی ایمیج رسمی در آن منتشر شده است. برای یافتن ایمیج‌های رسمی، می‌توانید از رابط کاربری Docker Hub یا از دستورات CLI استفاده کنید.

2.1. جستجو در Docker Hub با استفاده از وب‌سایت

1. به آدرس Docker Hub بروید.
2. در کادر جستجو، نام نرم‌افزار یا ایمیجی که به‌دنبال آن هستید را وارد کنید (برای مثال: mysql, redis, nginx).
3. در نتایج جستجو، ایمیج‌های رسمی معمولاً با علامت «Official Image» نمایش داده می‌شوند.

2.2. جستجو با استفاده از دستور CLI

اگر از دستور docker search برای جستجو استفاده کنید، می‌توانید نتایج جستجو را در CLI مشاهده کنید:

docker search mysql

در این دستور، جستجو برای ایمیج‌های مربوط به MySQL انجام می‌شود و در نتایج جستجو، ایمیج‌های رسمی معمولاً با نشان “official” مشخص می‌شوند.

---

3. استفاده از ایمیج‌های رسمی

پس از اینکه ایمیج رسمی مورد نظر خود را پیدا کردید، می‌توانید از آن برای ایجاد کانتینرهای جدید استفاده کنید. برای این کار کافی است که ایمیج را با دستور docker pull دانلود کرده و سپس با دستور docker run کانتینر خود را راه‌اندازی کنید.

3.1. دریافت ایمیج رسمی

فرض کنید می‌خواهید ایمیج رسمی mysql را دریافت کنید:

docker pull mysql:latest

در این دستور، latest نشان‌دهنده نسخه به‌روز ایمیج است. شما می‌توانید نسخه خاصی از ایمیج را نیز انتخاب کنید، برای مثال:

docker pull mysql:5.7

3.2. اجرای کانتینر از ایمیج رسمی

پس از دانلود ایمیج، می‌توانید از آن برای ایجاد یک کانتینر جدید استفاده کنید. برای مثال، برای اجرای کانتینر MySQL از ایمیج رسمی، دستور زیر را وارد کنید:

docker run --name my-mysql-container -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:latest

در این دستور:

• --name نام کانتینر را مشخص می‌کند.
• -e MYSQL_ROOT_PASSWORD=my-secret-pw متغیر محیطی برای تعیین پسورد روت MySQL را تنظیم می‌کند.
• -d کانتینر را در حالت پس‌زمینه اجرا می‌کند.

3.3. استفاده از پارامترهای اضافی

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

docker run --name my-mysql-container -p 3306:3306 --network my-network -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:latest

---

4. بهترین شیوه‌ها برای استفاده از ایمیج‌های رسمی

برای استفاده مؤثر و امن از ایمیج‌های رسمی Docker، برخی بهترین شیوه‌ها وجود دارد که می‌تواند به بهبود کیفیت و امنیت پروژه‌های شما کمک کند:

4.1. استفاده از نسخه‌های ثابت

به‌جای استفاده از نسخه latest برای دانلود ایمیج‌ها، توصیه می‌شود از نسخه‌های خاص استفاده کنید. این کار باعث می‌شود که در صورت بروز تغییرات غیرمنتظره در نسخه‌های جدید، سیستم شما دچار مشکل نشود.

برای مثال، به‌جای استفاده از:

docker pull mysql:latest

از نسخه خاص استفاده کنید:

docker pull mysql:5.7

4.2. بازبینی تغییرات و به‌روزرسانی‌ها

همواره تغییرات و به‌روزرسانی‌های منتشر شده برای ایمیج‌های رسمی را بررسی کنید تا مطمئن شوید از آخرین نسخه‌های ایمن و پایدار استفاده می‌کنید.

4.3. بررسی مستندات ایمیج

قبل از استفاده از هر ایمیج، مستندات رسمی آن را بررسی کنید تا از نحوه پیکربندی، تنظیمات خاص و مشکلات رایج مطلع شوید. این کار به‌ویژه زمانی مهم است که بخواهید ایمیج‌ها را در محیط‌های تولیدی استفاده کنید.

---

جمع‌بندی

استفاده از ایمیج‌های رسمی Docker از Docker Hub مزایای زیادی از جمله امنیت بالا، پایداری، و مستندات جامع را به همراه دارد. این ایمیج‌ها معمولاً توسط تیم‌های توسعه‌دهنده نرم‌افزار ساخته و نگهداری می‌شوند، و بنابراین برای استفاده در محیط‌های تولیدی بسیار مناسب هستند. با استفاده از دستور docker pull می‌توانید به راحتی ایمیج‌های رسمی را دریافت کرده و کانتینرهای خود را راه‌اندازی کنید. رعایت بهترین شیوه‌ها و استفاده از نسخه‌های خاص می‌تواند به بهبود کیفیت و امنیت سیستم شما کمک کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد نسخه‌های مختلف (Tags) از ایمیج‌ها برای مدیریت نسخه‌گذاری” subtitle=”توضیحات کامل”]در Docker، ایمیج‌ها معمولاً با استفاده از برچسب‌ها (Tags) مدیریت می‌شوند تا نسخه‌های مختلف آن‌ها را از یکدیگر متمایز سازند. استفاده از نسخه‌های مختلف ایمیج‌ها برای مدیریت فرآیند به‌روزرسانی، پشتیبانی از ویژگی‌های مختلف، و رفع مشکلات امنیتی بسیار حیاتی است. این برچسب‌ها نه تنها به شما کمک می‌کنند تا نسخه‌های مختلف ایمیج‌ها را مدیریت کنید، بلکه به ساده‌تر شدن فرآیند انتقال و اشتراک‌گذاری این ایمیج‌ها بین تیم‌های مختلف نیز کمک می‌کنند.

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

---

1. برچسب‌ها (Tags) در Docker چیست؟

برچسب‌ها یا Tags در Docker، شناسه‌هایی هستند که به ایمیج‌ها اختصاص داده می‌شوند تا نسخه‌های مختلف آن‌ها از یکدیگر تمایز یابند. به‌طور پیش‌فرض، وقتی شما از دستور docker pull یا docker build استفاده می‌کنید، Docker آخرین نسخه پایدار از ایمیج را دانلود می‌کند. اما می‌توانید از برچسب‌ها برای دسترسی به نسخه‌های خاص استفاده کنید.

1.1. ساختار برچسب‌ها

یک برچسب معمولاً شامل دو بخش است:

1. نام ایمیج: نام نرم‌افزاری که می‌خواهید از آن استفاده کنید، مثلاً nginx یا mysql.
2. نسخه (Tag): نسخه‌ای از نرم‌افزار یا ویژگی خاص آن که می‌خواهید از آن استفاده کنید، مثلاً 1.0, latest, 5.7.

به‌طور مثال:

• nginx:latest نشان‌دهنده نسخه آخرین و پایدار ایمیج Nginx است.
• mysql:5.7 نشان‌دهنده نسخه خاص 5.7 ایمیج MySQL است.
• node:14-alpine نشان‌دهنده نسخه 14 از Node.js است که بر اساس توزیع Alpine ساخته شده است.

---

2. چرا باید از برچسب‌ها (Tags) استفاده کنیم؟

استفاده از برچسب‌ها به دلایل مختلفی اهمیت دارد:

• مدیریت نسخه‌ها: با استفاده از برچسب‌ها می‌توان نسخه‌های مختلف یک ایمیج را به راحتی مدیریت کرد. این امر به شما این امکان را می‌دهد که از نسخه‌های خاصی استفاده کنید و از تغییرات غیرمنتظره در نسخه‌های جدید جلوگیری کنید.
• به‌روزرسانی‌های امن: هنگام استفاده از برچسب‌ها، شما قادر خواهید بود نسخه‌های به‌روز و امن را بدون نیاز به نگرانی در مورد تغییرات غیرمنتظره در ویژگی‌ها یا تنظیمات استفاده کنید.
• مستندسازی و تطابق: استفاده از برچسب‌ها به شما کمک می‌کند تا ایمیج‌هایی با ویژگی‌ها و نسخه‌های خاص را مستند کنید. این امر به تیم‌ها کمک می‌کند تا متوجه شوند کدام نسخه از یک نرم‌افزار برای پروژه خاص مناسب است.

---

3. ایجاد برچسب‌ها (Tags) برای ایمیج‌ها

برای ایجاد برچسب‌ها در Docker، از دستور docker build استفاده می‌شود. این دستور به شما این امکان را می‌دهد که در زمان ساخت ایمیج، نسخه‌های مختلف را به آن اختصاص دهید.

3.1. ساخت ایمیج با برچسب جدید

برای ساخت ایمیج و اختصاص برچسب به آن، می‌توانید از دستور docker build همراه با پارامتر -t استفاده کنید. به‌عنوان مثال:

docker build -t myapp:v1 .

در این دستور:

• myapp:v1 نام ایمیج است که برچسب v1 به آن اختصاص داده شده است.
• . نمایانگر دایرکتوری جاری است که Dockerfile در آن قرار دارد.

شما می‌توانید از هر نوع برچسب دلخواه برای مشخص کردن نسخه‌ها یا ویژگی‌های خاص استفاده کنید، مانند v2, beta, latest و غیره.

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

گاهی اوقات لازم است یک ایمیج را با چندین برچسب مختلف بسازید. برای این کار، می‌توانید از چندین پارامتر -t استفاده کنید:

docker build -t myapp:v1 -t myapp:latest .

در اینجا، ایمیج myapp هم با برچسب v1 و هم با برچسب latest ساخته خواهد شد.

3.3. ساخت ایمیج از Dockerfile با برچسب‌ها

فرض کنید شما یک Dockerfile دارید که یک نرم‌افزار را نصب و پیکربندی می‌کند. برای ساخت ایمیج و برچسب‌گذاری آن می‌توانید به این صورت عمل کنید:

docker build -t myapp:1.0 -f Dockerfile .

در این دستور:

• -t myapp:1.0 به ایمیج برچسب 1.0 داده می‌شود.
• -f Dockerfile فایل Dockerfile که در دایرکتوری جاری است را مشخص می‌کند.

---

4. فروش و به اشتراک‌گذاری ایمیج‌ها با برچسب‌های مختلف

پس از ساخت ایمیج با برچسب‌های مختلف، می‌توانید آن‌ها را به رجیستری Docker مانند Docker Hub ارسال کنید تا دیگران بتوانند از آن‌ها استفاده کنند. به‌طور مثال:

docker push myapp:v1
docker push myapp:latest

این دستورات ایمیج‌های شما را با دو برچسب مختلف به Docker Hub ارسال خواهند کرد.

4.1. انتقال بین نسخه‌های مختلف ایمیج‌ها

اگر شما می‌خواهید نسخه‌های مختلف ایمیج‌ها را برای تست، توسعه، یا رفع مشکل استفاده کنید، می‌توانید هر نسخه از ایمیج را به‌راحتی با برچسب آن بارگیری کنید:

docker pull myapp:v1

این دستور ایمیج نسخه v1 را از Docker Hub دانلود می‌کند. به‌این‌ترتیب، شما می‌توانید به‌راحتی بین نسخه‌های مختلف جابجا شوید.

---

5. بهترین شیوه‌ها برای استفاده از برچسب‌ها (Tags)

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

5.1. استفاده از برچسب‌های خاص برای نسخه‌ها

همیشه از برچسب‌های نسخه‌ای دقیق به‌جای استفاده از latest برای ایمیج‌ها استفاده کنید. این کار باعث می‌شود تا شما بتوانید نسخه‌های مختلف را به‌صورت دقیق‌تری کنترل کنید.

برای مثال:

docker pull nginx:1.21.0

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

تیم‌ها می‌توانند با استفاده از برچسب‌های خاص مانند dev, prod, یا test مشخص کنند که یک ایمیج در چه محیطی قرار است اجرا شود. این کار می‌تواند به‌ویژه در زمان توسعه و تست کمک‌کننده باشد.

5.3. نگهداری و به‌روزرسانی برچسب‌ها

برچسب‌ها باید به‌طور مرتب به‌روزرسانی شوند تا تغییرات در نسخه‌های جدید نرم‌افزار یا به‌روزرسانی‌های امنیتی به‌درستی منعطف شوند. حتماً برچسب‌های خود را با توجه به تغییرات نرم‌افزار تنظیم کنید و به‌طور مداوم نسخه‌ها را به‌روز کنید.

---

جمع‌بندی

ایجاد و استفاده از نسخه‌های مختلف ایمیج‌ها با برچسب‌ها در Docker یک روش مؤثر برای مدیریت و سازمان‌دهی ایمیج‌ها است. برچسب‌ها به شما این امکان را می‌دهند که نسخه‌های مختلف یک نرم‌افزار را به راحتی از یکدیگر تفکیک کنید و آن‌ها را به‌طور دقیق مدیریت کنید. همچنین، استفاده از برچسب‌های دقیق برای نسخه‌ها، مستندات، و محیط‌های مختلف به شما کمک می‌کند که فرآیند توسعه، تست، و تولید را به‌طور مؤثرتر انجام دهید. استفاده صحیح از برچسب‌ها در Docker موجب بهبود سازمان‌دهی و بهره‌وری در پروژه‌های نرم‌افزاری خواهد شد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تمیز نگه داشتن رجیستری از ایمیج‌های قدیمی و غیرضروری” subtitle=”توضیحات کامل”]در هنگام کار با Docker، ممکن است ایمیج‌ها و کانتینرهایی که دیگر به آن‌ها نیازی ندارید در رجیستری ذخیره شوند. این ایمیج‌ها به‌طور غیرضروری فضای ذخیره‌سازی را اشغال کرده و به پیچیدگی مدیریت منابع در محیط‌های تولیدی و توسعه می‌افزایند. بنابراین، نگهداری ایمیج‌های قدیمی و غیرضروری می‌تواند به مشکلاتی نظیر کاهش کارایی، مصرف بالای فضای ذخیره‌سازی، و اختلال در روند کاری شما منجر شود.

در این بخش، به روش‌ها و ابزارهایی خواهیم پرداخت که به شما کمک می‌کنند رجیستری‌های Docker را از ایمیج‌های قدیمی و غیرضروری پاکسازی کنید و فرآیندهای بهینه‌ای را برای نگهداری تنها ایمیج‌های مورد نیاز پیاده‌سازی کنید.

---

1. چرا باید ایمیج‌های قدیمی و غیرضروری را حذف کنیم؟

حذف ایمیج‌های قدیمی و غیرضروری از رجیستری دلایل متعددی دارد:

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

---

2. روش‌های حذف ایمیج‌های قدیمی از رجیستری

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

2.1. استفاده از دستور docker image prune برای حذف ایمیج‌های قدیمی

یکی از ساده‌ترین روش‌ها برای حذف ایمیج‌های بدون استفاده، استفاده از دستور docker image prune است. این دستور تمامی ایمیج‌های بی‌استفاده، که به هیچ کانتینری متصل نیستند، را از سیستم شما حذف می‌کند.

برای حذف ایمیج‌های قدیمی و غیرضروری می‌توانید از دستور زیر استفاده کنید:

docker image prune

این دستور تنها ایمیج‌هایی را حذف می‌کند که به هیچ کانتینری اختصاص نیافته‌اند. همچنین، این دستور از شما تایید می‌خواهد که آیا مطمئن هستید می‌خواهید این ایمیج‌ها را حذف کنید.

اگر می‌خواهید بدون تایید حذف انجام شود، می‌توانید از گزینه -f (force) استفاده کنید:

docker image prune -f

2.2. حذف ایمیج‌های قدیمی و غیرضروری بر اساس تاریخ

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

یک روش برای حذف ایمیج‌های قدیمی از سیستم به‌صورت دستی، استفاده از دستور docker images است تا بتوانید ایمیج‌های قدیمی را شناسایی کنید و سپس آن‌ها را با دستور docker rmi حذف کنید.

docker images

پس از شناسایی ایمیج‌های قدیمی، از دستور زیر برای حذف آن‌ها استفاده کنید:

docker rmi <image_id>

2.3. حذف ایمیج‌ها با استفاده از docker system prune

دستور docker system prune می‌تواند برای حذف تمامی منابع غیرضروری از سیستم، از جمله ایمیج‌ها، کانتینرها، شبکه‌ها و حجم‌ها استفاده شود. این دستور به شما کمک می‌کند تا فضای بیشتری را با حذف تمامی اجزای غیرضروری آزاد کنید.

برای حذف تمامی منابع غیرضروری می‌توانید از دستور زیر استفاده کنید:

docker system prune

این دستور از شما تایید می‌خواهد که آیا می‌خواهید تمامی منابع غیرضروری را حذف کنید.

برای حذف تمامی منابع بدون تایید، می‌توانید از گزینه -f استفاده کنید:

docker system prune -f

همچنین، اگر بخواهید ایمیج‌ها، کانتینرها و حجم‌هایی که بیش از 24 ساعت از آن‌ها استفاده نشده را حذف کنید، می‌توانید از گزینه --all استفاده کنید:

docker system prune --all

---

3. مدیریت ایمیج‌ها در رجیستری‌های خصوصی

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

3.1. استفاده از ابزارهای شخص ثالث برای پاکسازی ایمیج‌ها

در صورتی که از رجیستری‌های خصوصی برای ذخیره‌سازی ایمیج‌ها استفاده می‌کنید، ابزارهایی مانند Portus و Harbor می‌توانند برای مدیریت ایمیج‌ها و به‌ویژه پاکسازی ایمیج‌های قدیمی و غیرضروری مورد استفاده قرار گیرند.

این ابزارها قابلیت‌هایی مانند:

• نمایش تاریخ ساخت ایمیج‌ها
• جستجو و فیلتر ایمیج‌ها
• حذف ایمیج‌های بدون استفاده را دارند.

3.2. حذف دستی ایمیج‌ها از Docker Registry

اگر از Docker Registry (رجیستری خصوصی خودتان) استفاده می‌کنید، ممکن است نیاز به حذف دستی ایمیج‌ها از رجیستری داشته باشید. برای این کار می‌توانید از دستور curl یا APIهای Docker Registry استفاده کنید.

فرآیند حذف ایمیج‌ها از رجیستری خصوصی معمولاً شامل مراحل زیر است:

1. جستجو برای شناسایی ایمیج‌های قدیمی.
2. حذف tag مربوط به ایمیج.
3. پاکسازی نهایی از طریق API.

مثال برای حذف یک ایمیج از Docker Registry:

curl -X DELETE https://<registry>/v2/<image>/manifests/<digest>

در این دستور:

• <registry> آدرس رجیستری شما است.
• <image> نام ایمیج است.
• <digest> شناسه هش ایمیج مورد نظر است.

---

4. بهترین شیوه‌ها برای مدیریت ایمیج‌ها در رجیستری

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

• استفاده از نام‌های مشخص و نسخه‌گذاری دقیق: برچسب‌گذاری دقیق ایمیج‌ها به شما کمک می‌کند که همیشه از نسخه‌های خاص و امن استفاده کنید و نیازی به نگهداری ایمیج‌های قدیمی نباشد.
• ایجاد فرآیند خودکار برای حذف ایمیج‌های قدیمی: از ابزارها و اسکریپت‌های خودکار برای حذف ایمیج‌های قدیمی استفاده کنید. می‌توانید این اسکریپت‌ها را به‌صورت دوره‌ای اجرا کنید تا ایمیج‌های قدیمی به‌طور خودکار حذف شوند.
• محدود کردن تعداد نسخه‌های نگهداری‌شده از ایمیج‌ها: حتماً تعداد نسخه‌های نگهداری‌شده از هر ایمیج را محدود کنید تا فضای ذخیره‌سازی شما اشباع نشود.

---

جمع‌بندی

تمیز نگه داشتن رجیستری از ایمیج‌های قدیمی و غیرضروری یکی از اقدامات مهم برای حفظ کارایی سیستم‌های Docker و کاهش هزینه‌های ذخیره‌سازی است. با استفاده از دستورات مختلف مانند docker image prune و docker system prune می‌توانید ایمیج‌های قدیمی را حذف کرده و فضای ذخیره‌سازی را آزاد کنید. علاوه بر این، ابزارهای مختلف مانند Portus و Harbor می‌توانند به شما در مدیریت ایمیج‌های رجیستری خصوصی کمک کنند. اجرای فرآیندهای خودکار برای پاکسازی و مدیریت نسخه‌های ایمیج‌ها به شما کمک می‌کند تا سیستم Docker خود را بهینه نگه دارید.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 3. نصب و پیکربندی (Installation and Configuration)”][cdb_course_lesson title=”فصل 1. نصب Docker Engine”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نصب Docker بر روی توزیع‌های مختلف لینوکس مانند Ubuntu، CentOS، و Debian” subtitle=”توضیحات کامل”]Docker به‌عنوان یک پلتفرم محبوب برای ساخت و مدیریت کانتینرها، به راحتی بر روی سیستم‌های مختلف قابل نصب است. در این بخش، نصب Docker بر روی سه توزیع معروف لینوکس شامل Ubuntu، CentOS و Debian را بررسی خواهیم کرد. نصب صحیح Docker برای ایجاد محیطی پایدار و عملکردی برای کانتینرها و سرویس‌های Docker ضروری است.

---

نصب Docker بر روی Ubuntu

Ubuntu یکی از توزیع‌های محبوب لینوکس است که توسط بسیاری از توسعه‌دهندگان برای استفاده در سرورها و محیط‌های توسعه انتخاب می‌شود. نصب Docker بر روی Ubuntu از طریق مخازن رسمی آن انجام می‌شود. در این بخش، مراحل نصب Docker را بر روی نسخه‌های مختلف Ubuntu با جزئیات بررسی می‌کنیم.

1. به‌روزرسانی سیستم

قبل از شروع نصب Docker، مهم است که سیستم خود را به‌روزرسانی کنید تا از آخرین بسته‌ها و آپدیت‌های امنیتی استفاده کنید.

sudo apt-get update
sudo apt-get upgrade

2. نصب پیش‌نیازها

برای نصب Docker، ابتدا باید پیش‌نیازهای مورد نیاز را نصب کنید. این پیش‌نیازها شامل ابزارهایی برای پیکربندی مخازن بسته‌ها و دانلود Docker است.

sudo apt-get install apt-transport-https ca-certificates curl software-properties-common

3. افزودن مخزن Docker

برای نصب Docker از مخزن رسمی Docker، باید کلید GPG مربوط به آن را اضافه کنید.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

پس از اضافه کردن کلید، باید مخزن Docker را به لیست منابع APT سیستم اضافه کنید.

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

4. نصب Docker

حالا می‌توانید Docker را نصب کنید. ابتدا فهرست بسته‌ها را به‌روز کنید و سپس Docker را نصب کنید.

sudo apt-get update
sudo apt-get install docker-ce

5. بررسی وضعیت Docker

برای بررسی وضعیت نصب Docker و اطمینان از فعال بودن سرویس، می‌توانید دستور زیر را وارد کنید:

sudo systemctl status docker

اگر همه‌چیز به‌درستی نصب شده باشد، باید پیامی مشابه “active (running)” را مشاهده کنید.

6. راه‌اندازی Docker هنگام بوت

برای اطمینان از اینکه Docker به‌طور خودکار در زمان بوت سیستم شروع به کار می‌کند، دستور زیر را وارد کنید:

sudo systemctl enable docker

---

نصب Docker بر روی CentOS

CentOS یکی دیگر از توزیع‌های محبوب لینوکس است که اغلب در محیط‌های سروری استفاده می‌شود. در این بخش، نصب Docker بر روی CentOS را بررسی خواهیم کرد.

1. به‌روزرسانی سیستم

برای شروع، سیستم خود را به‌روز کنید تا از آخرین بسته‌ها و آپدیت‌های امنیتی استفاده کنید.

sudo yum update -y

2. نصب پیش‌نیازها

نصب ابزارهایی برای مدیریت مخازن بسته‌ها و نصب Docker در CentOS.

sudo yum install -y yum-utils

3. افزودن مخزن Docker

برای نصب Docker، باید مخزن Docker را به‌صورت دستی به سیستم اضافه کنید.

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

4. نصب Docker

پس از افزودن مخزن Docker، Docker را نصب کنید.

sudo yum install docker-ce docker-ce-cli containerd.io

5. راه‌اندازی Docker

پس از نصب Docker، سرویس Docker را راه‌اندازی کنید.

sudo systemctl start docker

6. بررسی وضعیت Docker

برای بررسی وضعیت سرویس Docker، دستور زیر را وارد کنید:

sudo systemctl status docker

7. راه‌اندازی Docker هنگام بوت

برای اطمینان از اینکه Docker به‌طور خودکار در زمان بوت سیستم شروع به کار می‌کند، از دستور زیر استفاده کنید:

sudo systemctl enable docker

---

نصب Docker بر روی Debian

Debian یک توزیع دیگر از لینوکس است که به‌طور گسترده‌ای در سرورها و سیستم‌های توسعه‌ای استفاده می‌شود. نصب Docker بر روی Debian مشابه Ubuntu است، اما در اینجا مراحل نصب را برای Debian بررسی خواهیم کرد.

1. به‌روزرسانی سیستم

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

sudo apt-get update
sudo apt-get upgrade

2. نصب پیش‌نیازها

برای نصب Docker، باید برخی از پیش‌نیازهای مورد نیاز را نصب کنید.

sudo apt-get install apt-transport-https ca-certificates curl software-properties-common

3. افزودن مخزن Docker

برای افزودن مخزن رسمی Docker، ابتدا باید کلید GPG مربوط به آن را اضافه کنید.

curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -

سپس مخزن Docker را به‌صورت دستی به سیستم Debian خود اضافه کنید.

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"

4. نصب Docker

پس از افزودن مخزن Docker، فهرست بسته‌ها را به‌روز کرده و Docker را نصب کنید.

sudo apt-get update
sudo apt-get install docker-ce

5. بررسی وضعیت Docker

برای اطمینان از نصب صحیح Docker، می‌توانید از دستور زیر استفاده کنید:

sudo systemctl status docker

اگر Docker به‌درستی نصب شده باشد، وضعیت سرویس باید “active (running)” باشد.

6. راه‌اندازی Docker هنگام بوت

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

sudo systemctl enable docker

7. نصب داکر از طریق یک اسکریپت

 curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

---

جمع‌بندی

در این بخش، نصب Docker بر روی سه توزیع مختلف لینوکس شامل Ubuntu، CentOS و Debian را بررسی کردیم. مراحل نصب در این توزیع‌ها به‌طور مشابه شامل به‌روزرسانی سیستم، نصب پیش‌نیازها، افزودن مخزن Docker، نصب Docker و راه‌اندازی آن می‌شود. پس از نصب، می‌توانید از دستورات مختلف برای بررسی وضعیت سرویس و اطمینان از اجرای صحیح Docker استفاده کنید. همچنین، تنظیم Docker برای راه‌اندازی خودکار در زمان بوت سیستم نیز به‌طور کامل توضیح داده شد. با انجام این مراحل، شما قادر خواهید بود Docker را به‌راحتی روی سیستم‌عامل‌های مختلف لینوکس نصب کنید و از آن در پروژه‌های خود استفاده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نصب Docker بر روی ویندوز (Windows Server و Windows Desktop)” subtitle=”توضیحات کامل”]Docker در سیستم‌عامل ویندوز نیز به‌طور کامل قابل نصب است، و در این بخش به بررسی نحوه نصب Docker بر روی دو نسخه از ویندوز خواهیم پرداخت: Windows Server و Windows Desktop. نصب Docker در این سیستم‌عامل‌ها به روش‌های مختلفی انجام می‌شود که بستگی به نیاز کاربر و نسخه ویندوز دارد. در ادامه به‌طور کامل، نحوه نصب Docker بر روی هر دو نسخه ویندوز را بررسی خواهیم کرد.

---

نصب Docker بر روی Windows Desktop (ویندوز 10 و ویندوز 11)

برای سیستم‌عامل‌های دسکتاپ ویندوز (ویندوز 10 و ویندوز 11)، Docker Desktop بهترین گزینه است. Docker Desktop یک نرم‌افزار کاربردی است که به شما این امکان را می‌دهد تا Docker را به راحتی در محیط ویندوز نصب و اجرا کنید. این نرم‌افزار برای توسعه‌دهندگان به‌ویژه در محیط‌های توسعه بسیار مفید است.

1. مقدمات نصب Docker Desktop

قبل از نصب Docker Desktop، مطمئن شوید که سیستم شما دارای پیش‌نیازهای زیر است:

• ویندوز 10 یا 11 نسخه 64 بیتی
• فعال بودن ویژگی Hyper-V و Containers در ویندوز
• حداقل 4 گیگابایت RAM
• پشتیبانی از مجازی‌سازی (Virtualization) در BIOS/UEFI

2. دانلود Docker Desktop

برای نصب Docker Desktop ابتدا باید از وب‌سایت رسمی Docker، نسخه مناسب را دانلود کنید. برای این کار به لینک زیر بروید:

دانلود Docker Desktop برای ویندوز

3. نصب Docker Desktop

• پس از دانلود فایل نصب Docker Desktop، آن را اجرا کنید.
• در مرحله اول، ممکن است از شما خواسته شود که مجوزهای مدیر سیستم (Administrator) را وارد کنید.
• در طول فرآیند نصب، باید گزینه Enable Hyper-V را فعال کنید تا Docker بتواند از ویژگی‌های مجازی‌سازی ویندوز استفاده کند.

پس از نصب، سیستم شما ممکن است نیاز به راه‌اندازی مجدد داشته باشد.

4. راه‌اندازی Docker Desktop

پس از نصب Docker Desktop، آن را باز کنید. برای این کار می‌توانید از منوی Start ویندوز “Docker Desktop” را جستجو کرده و روی آن کلیک کنید.

• بعد از راه‌اندازی، Docker Desktop از شما می‌خواهد که وارد حساب Docker شوید (اختیاری).
• Docker Desktop برای اجرا نیاز به Hyper-V و WSL 2 (Windows Subsystem for Linux 2) دارد که به‌طور خودکار نصب می‌شود. اگر این ابزارها نصب نشده باشند، Docker Desktop آن‌ها را نصب می‌کند.

5. بررسی نصب

برای بررسی وضعیت نصب و اطمینان از فعال بودن Docker، از دستور زیر در Command Prompt یا PowerShell استفاده کنید:

docker --version

این دستور نسخه نصب‌شده Docker را نشان می‌دهد. همچنین، می‌توانید با دستور زیر از صحت عملکرد Docker اطمینان حاصل کنید:

docker run hello-world

این دستور یک کانتینر ساده را اجرا می‌کند که پیامی مبنی بر موفقیت‌آمیز بودن نصب Docker نمایش می‌دهد.

---

نصب Docker بر روی Windows Server

برای ویندوز سرور، Docker به‌صورت مستقیم به‌وسیله Docker Engine نصب می‌شود. برخلاف Docker Desktop برای ویندوز دسکتاپ، نصب Docker بر روی ویندوز سرور نیاز به تنظیمات بیشتری دارد و فرآیند نصب پیچیده‌تری دارد.

1. مقدمات نصب Docker Engine

برای نصب Docker بر روی ویندوز سرور، باید ابتدا از پیش‌نیازهای زیر مطمئن شوید:

• ویندوز سرور 2016 یا نسخه‌های بالاتر
• فعال بودن ویژگی‌های Hyper-V و Containers
• مجازی‌سازی باید در BIOS/UEFI فعال باشد.

2. فعال کردن ویژگی‌های Hyper-V و Containers

برای فعال کردن ویژگی‌های مورد نیاز برای Docker، از دستور زیر در PowerShell استفاده کنید:

Install-WindowsFeature -Name Hyper-V, Containers

پس از اجرای این دستور، ویندوز ممکن است از شما بخواهد که سیستم را مجدداً راه‌اندازی کنید.

3. نصب Docker Engine

برای نصب Docker Engine، باید مخزن Docker را به‌صورت دستی به سیستم اضافه کنید. دستورالعمل‌های زیر را دنبال کنید:

1. ابتدا PowerShell را به‌عنوان Administrator اجرا کنید.
2. دستور زیر را برای افزودن مخزن Docker به سیستم وارد کنید:

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri https://get.docker.com/ | Invoke-Expression

3. پس از اضافه کردن مخزن، می‌توانید Docker Engine را با استفاده از دستور زیر نصب کنید:

Install-Package -Name docker -ProviderName DockerMsftProvider

4. راه‌اندازی Docker Engine

پس از نصب Docker، باید سرویس Docker را راه‌اندازی کنید. از دستور زیر برای شروع Docker استفاده کنید:

Start-Service Docker

همچنین، برای تنظیم Docker برای راه‌اندازی خودکار هنگام بوت سیستم، از دستور زیر استفاده کنید:

Set-Service -Name Docker -StartupType Automatic

5. بررسی نصب Docker

برای بررسی وضعیت نصب Docker و اطمینان از فعال بودن سرویس، از دستور زیر استفاده کنید:

docker --version

همچنین، می‌توانید از دستور زیر برای تست عملکرد Docker استفاده کنید:

docker run hello-world

این دستور باید پیامی مشابه “Hello from Docker!” را نشان دهد که به معنای نصب موفق Docker است.

---

جمع‌بندی

در این بخش، نصب Docker بر روی سیستم‌عامل ویندوز شامل Windows Desktop (ویندوز 10 و ویندوز 11) و Windows Server بررسی شد. برای نصب Docker بر روی ویندوز دسکتاپ، از Docker Desktop استفاده می‌شود که به‌طور خودکار ابزارهای مجازی‌سازی مورد نیاز را نصب می‌کند. در ویندوز سرور، باید از Docker Engine استفاده کنید که نیاز به تنظیمات اولیه مانند فعال کردن ویژگی‌های Hyper-V و Containers دارد. پس از نصب، می‌توانید از دستورات مختلف برای بررسی وضعیت نصب Docker و اطمینان از عملکرد صحیح آن استفاده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نصب Docker بر روی مکینتاش (macOS)” subtitle=”توضیحات کامل”]Docker به‌طور کامل در سیستم‌عامل macOS قابل نصب است. برای نصب Docker بر روی مکینتاش، از نسخه Docker Desktop for Mac استفاده می‌شود. این نسخه تمامی ویژگی‌ها و قابلیت‌های Docker را در یک بسته نصب برای macOS ارائه می‌دهد و به‌طور خودکار تمامی ابزارهای مورد نیاز مانند Docker Engine، Docker Compose، و Kubernetes (در صورت نیاز) را نصب می‌کند. در این بخش به‌طور کامل به نحوه نصب و پیکربندی Docker بر روی macOS پرداخته خواهد شد.

---

پیش‌نیازهای نصب Docker بر روی macOS

قبل از شروع نصب، مطمئن شوید که سیستم شما پیش‌نیازهای زیر را دارد:

1. macOS نسخه 10.13 یا بالاتر.
2. حداقل 4 گیگابایت RAM.
3. پشتیبانی از Virtualization در سیستم‌تان (که به‌طور پیش‌فرض در macOS وجود دارد).
4. داشتن حساب کاربری Docker برای استفاده از امکانات Docker Hub (اختیاری).

---

مراحل نصب Docker Desktop برای macOS

1. دانلود Docker Desktop for Mac

برای نصب Docker Desktop بر روی مکینتاش، ابتدا باید فایل نصب را از وب‌سایت رسمی Docker دانلود کنید:

• به لینک زیر بروید: دانلود Docker Desktop برای macOS

در این صفحه، بسته مناسب با نسخه macOS خود (میکرو یا استاندارد) را انتخاب کرده و آن را دانلود کنید.

2. اجرای فایل نصب

پس از دانلود، فایل نصب با پسوند .dmg را باز کرده و دستورالعمل‌های زیر را دنبال کنید:

1. Docker Desktop را به فولدر Applications کشیده و رها کنید تا نصب شود.
2. پس از نصب، Docker را از Applications اجرا کنید.

3. راه‌اندازی Docker Desktop

زمانی که Docker Desktop را برای اولین بار اجرا می‌کنید، ممکن است از شما خواسته شود که مجوزهای Administrator را وارد کنید تا Docker بتواند برخی از تنظیمات سیستم را اعمال کند.

• ممکن است سیستم از شما بخواهد که Apple’s system preferences را برای فعال کردن ویژگی‌های HyperKit (ماشین مجازی مبتنی بر macOS) و Virtualization باز کنید.
• در صورتی که به‌طور خودکار ماشین مجازی تنظیم نشد، Docker خود این فرآیند را تکمیل خواهد کرد.

پس از این مراحل، Docker به‌طور خودکار راه‌اندازی می‌شود و شما می‌توانید آیکون Docker را در قسمت بالا سمت راست صفحه (System Tray) مشاهده کنید.

4. بررسی وضعیت نصب Docker

برای بررسی اینکه Docker به درستی نصب شده است، یک ترمینال جدید باز کرده و دستور زیر را وارد کنید:

docker --version

این دستور نسخه نصب‌شده Docker را نمایش می‌دهد.

همچنین برای تست عملکرد Docker و اطمینان از نصب صحیح، دستور زیر را وارد کنید:

docker run hello-world

اگر همه‌چیز به‌درستی نصب شده باشد، پیامی مشابه این را مشاهده خواهید کرد:

Hello from Docker!
This message shows that your installation appears to be working correctly.

این به این معناست که نصب Docker با موفقیت انجام شده است و Docker آماده استفاده است.

5. پیکربندی Docker برای استفاده بهینه

• Docker Preferences: برای تنظیمات پیشرفته‌تر Docker، می‌توانید روی آیکون Docker در نوار منو کلیک کرده و سپس گزینه Preferences را انتخاب کنید.
  • در این بخش می‌توانید تنظیماتی مانند منابع CPU و RAM، استفاده از Kubernetes، و تنظیمات شبکه را تغییر دهید.
• فعال کردن Kubernetes: اگر به Kubernetes نیاز دارید، می‌توانید از بخش Kubernetes در Preferences آن را فعال کنید.

---

مشکلات رایج و رفع آن‌ها

در صورتی که با مشکلاتی مانند کندی عملکرد یا عدم راه‌اندازی Docker روبه‌رو شدید، ممکن است نیاز به رفع مشکلات زیر داشته باشید:

1. مجازی‌سازی در BIOS: اگر Docker Desktop به‌درستی نصب نمی‌شود، اطمینان حاصل کنید که در BIOS گزینه Virtualization فعال باشد.
2. اختلال در برنامه‌های دیگر: برخی از برنامه‌ها و سرویس‌ها ممکن است با Docker تداخل داشته باشند. برای رفع این مشکل، بررسی کنید که هیچ برنامه دیگری که به مجازی‌سازی نیاز داشته باشد، در حال اجرا نباشد.
3. مشکلات مرتبط با فایروال: در بعضی مواقع، فایروال macOS ممکن است تداخل ایجاد کند. می‌توانید فایروال macOS را بررسی کرده و دسترسی‌های لازم را برای Docker فراهم کنید.

---

جمع‌بندی

در این بخش، نحوه نصب Docker بر روی سیستم‌عامل macOS با استفاده از Docker Desktop for Mac بررسی شد. Docker Desktop برای macOS تمام ابزارهای مورد نیاز برای اجرای Docker را در یک بسته نرم‌افزاری ارائه می‌دهد. پس از نصب و پیکربندی Docker، شما قادر خواهید بود از طریق دستورات مختلف در ترمینال، مانند docker --version و docker run hello-world، از صحت نصب Docker اطمینان حاصل کنید. همچنین، Docker Desktop این امکان را به شما می‌دهد که تنظیمات مختلف مانند Kubernetes را نیز فعال کرده و منابع سیستم را پیکربندی کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نصب Docker Desktop برای توسعه‌دهندگان” subtitle=”توضیحات کامل”]Docker Desktop برای توسعه‌دهندگان ابزاری است که به‌طور ویژه برای سیستم‌های macOS و ویندوز طراحی شده تا محیطی یکپارچه برای ساخت، تست، و اجرای کانتینرها فراهم کند. Docker Desktop شامل تمام قابلیت‌های Docker مانند Docker Engine، Docker Compose، Docker CLI، و Kubernetes (در صورت نیاز) است. این ابزار برای توسعه‌دهندگانی که می‌خواهند اپلیکیشن‌های خود را در کانتینرها اجرا کنند، یک محیط کاربری راحت و بهینه فراهم می‌آورد.

در این بخش، نصب Docker Desktop برای توسعه‌دهندگان روی دو سیستم‌عامل ویندوز و macOS به‌طور کامل توضیح داده خواهد شد.

---

پیش‌نیازهای نصب Docker Desktop

قبل از شروع مراحل نصب Docker Desktop، مطمئن شوید که سیستم شما پیش‌نیازهای زیر را دارد:

1. سیستم‌عامل ویندوز:
   • Windows 10 (Pro، Enterprise، یا Education) یا Windows Server 2016 و بالاتر.
   • برای استفاده از ویژگی‌های مجازی‌سازی، باید قابلیت Hyper-V و Windows Containers فعال باشد.
2. سیستم‌عامل macOS:
   • macOS نسخه 10.13 یا بالاتر.
3. حداقل 4 گیگابایت RAM.
4. اتصال به اینترنت برای دانلود فایل‌های نصب و بروزرسانی‌ها.
5. حساب Docker Hub برای دسترسی به Docker Hub و ارسال یا دریافت ایمیج‌ها (اختیاری).

---

مراحل نصب Docker Desktop برای توسعه‌دهندگان

1. دانلود Docker Desktop

برای شروع نصب Docker Desktop، ابتدا باید فایل نصب را از وب‌سایت رسمی Docker دانلود کنید:

• برای ویندوز: دانلود Docker Desktop برای ویندوز
• برای macOS: دانلود Docker Desktop برای macOS

پس از انتخاب سیستم‌عامل خود و دانلود فایل نصب، می‌توانید مراحل زیر را دنبال کنید.

---

2. نصب Docker Desktop روی ویندوز

1. فایل نصب را که با پسوند .exe دریافت کرده‌اید، اجرا کنید.
2. در پنجره نصب، روی گزینه Install کلیک کنید.
3. هنگام نصب، Docker Desktop از شما درخواست می‌کند که ویژگی‌های Hyper-V و Containers ویندوز را فعال کنید. اگر این ویژگی‌ها از قبل فعال نباشند، دستورالعمل‌های لازم به شما داده خواهد شد.
4. پس از تکمیل نصب، سیستم شما نیاز به راه‌اندازی مجدد خواهد داشت. پس از ریستارت، Docker Desktop به‌طور خودکار اجرا خواهد شد.

---

3. نصب Docker Desktop روی macOS

1. پس از دانلود فایل نصب با پسوند .dmg، آن را باز کنید.
2. در پنجره بازشده، Docker را به پوشه Applications کشیده و رها کنید.
3. پس از نصب، Docker را از پوشه Applications اجرا کنید.
4. در اولین بار اجرا، Docker از شما درخواست دسترسی‌های Administrator خواهد کرد تا بتواند ویژگی‌های مورد نیاز مانند HyperKit را فعال کند.
5. پس از تکمیل فرآیند راه‌اندازی، Docker در نوار منوی macOS در بالا سمت راست صفحه ظاهر می‌شود.

---

4. پیکربندی Docker Desktop

پس از نصب و راه‌اندازی Docker Desktop، می‌توانید تنظیمات مورد نظر خود را انجام دهید:

1. تنظیمات منابع سیستم: Docker Desktop اجازه می‌دهد منابعی مانند CPU و RAM که Docker استفاده می‌کند، تنظیم شوند. این کار می‌تواند برای بهینه‌سازی عملکرد بر اساس نیازهای خاص شما انجام شود.
   • برای تنظیم منابع، روی آیکون Docker در نوار منو کلیک کنید و گزینه Preferences را انتخاب کنید. سپس می‌توانید در بخش Resources، مقدار CPU، Memory، و Disk را تنظیم کنید.
2. فعال کردن Kubernetes: در Docker Desktop، این امکان وجود دارد که Kubernetes را برای استفاده در محیط‌های توسعه‌ای فعال کنید.
   • به بخش Kubernetes در Preferences بروید و گزینه Enable Kubernetes را انتخاب کنید.
3. تنظیمات پروکسی و شبکه: در برخی محیط‌ها، ممکن است لازم باشد که تنظیمات پروکسی یا شبکه را برای دسترسی به اینترنت و رجیستری‌های Docker پیکربندی کنید.

---

بررسی وضعیت نصب Docker

برای اطمینان از نصب درست Docker، یک ترمینال (در ویندوز از PowerShell یا Command Prompt، در macOS از Terminal) باز کنید و دستور زیر را وارد کنید:

docker --version

این دستور باید نسخه نصب‌شده Docker را نمایش دهد.

برای بررسی صحت نصب و عملکرد Docker، دستور زیر را وارد کنید تا پیغام خوشامد از Docker را مشاهده کنید:

docker run hello-world

اگر نصب به‌درستی انجام شده باشد، پیامی مشابه زیر را مشاهده خواهید کرد:

Hello from Docker!
This message shows that your installation appears to be working correctly.

این پیام نشان‌دهنده این است که Docker به‌درستی نصب شده و آماده استفاده است.

---

مشکلات رایج در نصب Docker

در هنگام نصب Docker Desktop ممکن است با مشکلاتی روبه‌رو شوید. در اینجا چند مشکل رایج و نحوه رفع آن‌ها آورده شده است:

1. مشکل در فعال‌سازی Hyper-V (ویندوز):
   • در برخی سیستم‌ها، ممکن است Hyper-V به‌طور پیش‌فرض غیرفعال باشد. برای رفع این مشکل، به تنظیمات BIOS بروید و از فعال بودن گزینه Intel Virtualization Technology اطمینان حاصل کنید.
2. مشکل در دسترسی به Docker پس از نصب (ویندوز):
   • در صورتی که Docker بعد از نصب اجرا نمی‌شود، ممکن است نیاز به راه‌اندازی مجدد سیستم یا بررسی تنظیمات امنیتی ویندوز مانند Windows Defender و Firewall داشته باشید.
3. کندی عملکرد:
   • اگر Docker Desktop کند عمل می‌کند، به تنظیمات منابع رفته و منابع اختصاصی به Docker (CPU و RAM) را بررسی کرده و به مقدار مناسبی افزایش دهید.
4. مشکلات شبکه (macOS):
   • اگر Docker نمی‌تواند به اینترنت یا Docker Hub متصل شود، باید تنظیمات پروکسی macOS یا شبکه خود را بررسی کنید.

---

جمع‌بندی

در این بخش، نصب Docker Desktop برای توسعه‌دهندگان بر روی سیستم‌عامل‌های ویندوز و macOS توضیح داده شد. Docker Desktop ابزارهای مورد نیاز برای اجرای کانتینرها و مدیریت آن‌ها را در یک محیط گرافیکی و یکپارچه فراهم می‌کند. پس از نصب Docker، می‌توانید از طریق دستور docker --version و اجرای دستور docker run hello-world از صحت نصب اطمینان حاصل کنید. در نهایت، با پیکربندی منابع و تنظیمات مورد نیاز، Docker Desktop به شما امکان می‌دهد تا به‌راحتی کانتینرها را در سیستم خود اجرا و مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”راه‌اندازی و تنظیم Docker Engine” subtitle=”توضیحات کامل”]Docker Engine هسته اصلی سیستم Docker است که به‌طور مستقیم مسئول اجرای کانتینرها و مدیریت منابع است. Docker Engine به دو نسخه مختلف موجود است: نسخه‌ی Stable و نسخه‌ی Edge (توسعه‌ای). هر یک از این نسخه‌ها ویژگی‌ها و کاربردهای خاص خود را دارند. در این بخش، نحوه نصب و تنظیم Docker Engine برای هر دو نسخه‌ی Stable و Edge را به‌طور کامل توضیح خواهیم داد.

---

1. نسخه‌ی Stable Docker Engine

نسخه‌ی Stable از Docker Engine به‌طور رسمی و برای استفاده در محیط‌های تولیدی و پایدار عرضه می‌شود. این نسخه به‌خوبی تست شده است و از امنیت و پایداری بالایی برخوردار است.

مراحل نصب Docker Engine نسخه‌ی Stable:

1. نصب Docker Engine در سیستم‌عامل‌های مختلف

   برای نصب Docker Engine نسخه‌ی Stable ابتدا باید منابع Docker را به سیستم خود اضافه کنید و سپس اقدام به نصب Docker نمایید.

   • در لینوکس (Ubuntu):

     ابتدا منابع Docker را به لیست پکیج‌های سیستم اضافه کنید:

     sudo apt-get update
     sudo apt-get install \
         apt-transport-https \
         ca-certificates \
         curl \
         gnupg \
         lsb-release \
         sudo
     

     سپس کلید GPG رسمی Docker را اضافه کنید:

     curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
     

     منابع Docker را به‌صورت رسمی اضافه کنید:

     echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
     

     سپس Docker Engine را نصب کنید:

     sudo apt-get update
     sudo apt-get install docker-ce docker-ce-cli containerd.io
     

     در نهایت، وضعیت سرویس Docker را با دستور زیر بررسی کنید:

     sudo systemctl status docker
     

   • در CentOS:

     ابتدا مخزن Docker را به سیستم اضافه کنید:

     sudo yum install -y yum-utils
     sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
     

     سپس Docker Engine را نصب کنید:

     sudo yum install docker-ce docker-ce-cli containerd.io
     

     سرویس Docker را راه‌اندازی کرده و آن را فعال کنید:

     sudo systemctl start docker
     sudo systemctl enable docker
     

     در نهایت، وضعیت سرویس Docker را با دستور زیر بررسی کنید:

     sudo systemctl status docker
     

2. به‌روزرسانی Docker Engine به نسخه‌ی Stable:

   اگر نسخه‌ی قدیمی‌تری از Docker را نصب کرده‌اید و می‌خواهید به نسخه‌ی Stable به‌روزرسانی کنید، کافیست دستور زیر را اجرا کنید:

   sudo apt-get update
   sudo apt-get install docker-ce docker-ce-cli containerd.io
   

---

2. نسخه‌ی Edge (توسعه‌ای) Docker Engine

نسخه‌ی Edge یا نسخه‌ی توسعه‌ای Docker Engine به‌طور مداوم در حال تغییر است و شامل ویژگی‌های جدیدتر و آزمایشی می‌باشد. این نسخه برای افرادی که می‌خواهند جدیدترین ویژگی‌ها و قابلیت‌ها را قبل از عرضه رسمی تست کنند مناسب است. اما این نسخه ممکن است با مشکلات پایدار بودن روبه‌رو شود و برای محیط‌های تولیدی مناسب نیست.

مراحل نصب Docker Engine نسخه‌ی Edge:

1. نصب Docker Engine نسخه‌ی Edge در سیستم‌عامل‌های مختلف
   • در لینوکس (Ubuntu):

     ابتدا منابع Docker را به‌روزرسانی کرده و نسخه‌ی Edge را نصب کنید. مشابه به نسخه‌ی Stable، ابتدا باید منابع Docker را به سیستم خود اضافه کنید:

     sudo apt-get update
     sudo apt-get install \
         apt-transport-https \
         ca-certificates \
         curl \
         gnupg \
         lsb-release \
         sudo
     

     سپس کلید GPG رسمی Docker را اضافه کنید:

     curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
     

     منابع Docker را به‌صورت رسمی اضافه کنید:

     echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) edge" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
     

     سپس Docker Engine نسخه‌ی Edge را نصب کنید:

     sudo apt-get update
     sudo apt-get install docker-ce docker-ce-cli containerd.io
     

     برای بررسی وضعیت Docker، دستور زیر را وارد کنید:

     sudo systemctl status docker
     

   • در CentOS:

     مشابه به نصب نسخه‌ی Stable، ابتدا باید مخزن Docker را به سیستم اضافه کنید، اما در اینجا باید از مخزن نسخه‌ی Edge استفاده کنید:

     sudo yum install -y yum-utils
     sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce-edge.repo
     

     سپس Docker Engine نسخه‌ی Edge را نصب کنید:

     sudo yum install docker-ce docker-ce-cli containerd.io
     

     سرویس Docker را راه‌اندازی کرده و آن را فعال کنید:

     sudo systemctl start docker
     sudo systemctl enable docker
     

2. به‌روزرسانی Docker Engine به نسخه‌ی Edge:

   اگر نسخه‌ی Stable را نصب کرده‌اید و می‌خواهید به نسخه‌ی Edge به‌روزرسانی کنید، کافیست دستور زیر را وارد کنید:

   sudo apt-get update
   sudo apt-get install docker-ce docker-ce-cli containerd.io
   

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

---

جمع‌بندی

در این بخش، نصب و تنظیم Docker Engine برای نسخه‌های Stable و Edge را بررسی کردیم. نسخه‌ی Stable مناسب برای محیط‌های تولیدی است و در این نسخه به‌طور کامل از پایداری و امنیت استفاده می‌شود. در مقابل، نسخه‌ی Edge برای افرادی که علاقه دارند جدیدترین قابلیت‌ها و ویژگی‌های آزمایشی Docker را امتحان کنند، مناسب است. نصب هر دو نسخه در سیستم‌های لینوکس، به‌ویژه در توزیع‌های محبوبی چون Ubuntu و CentOS، به‌راحتی انجام می‌شود و می‌توان از آن‌ها در محیط‌های توسعه و تولید استفاده کرد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. پیکربندی Docker Daemon”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی Docker Daemon از طریق فایل daemon.json ” subtitle=”توضیحات کامل”]Docker Daemon مسئول اجرای کانتینرها، نظارت بر منابع و مدیریت تمام فعالیت‌های مرتبط با Docker است. برای اینکه Docker Daemon بتواند با نیازهای خاص محیط‌های مختلف منطبق شود، پیکربندی آن از طریق فایل daemon.json انجام می‌شود. در این بخش، به تغییر تنظیمات Docker Daemon از طریق فایل daemon.json و چگونگی تنظیم گزینه‌های مختلف از جمله ذخیره‌سازی، سطح لاگینگ و فعال‌سازی ویژگی‌های آزمایشی خواهیم پرداخت.

---

1. تغییر تنظیمات Docker Daemon از طریق فایل daemon.json

فایل daemon.json برای پیکربندی تنظیمات مختلف Docker Daemon به‌کار می‌رود. این فایل معمولاً در مسیر /etc/docker/daemon.json قرار دارد. در صورتی که این فایل وجود ندارد، شما می‌توانید آن را به‌صورت دستی ایجاد کرده و تنظیمات مورد نظر خود را در آن وارد کنید. برای ویرایش این فایل، به‌عنوان مثال می‌توان از ویرایشگرهای متنی مثل nano یا vim استفاده کرد:

sudo nano /etc/docker/daemon.json

---

2. پیکربندی گزینه‌های ذخیره‌سازی (Storage Options)

یکی از مهم‌ترین بخش‌های پیکربندی Docker Daemon، انتخاب و تنظیم گزینه‌های ذخیره‌سازی است. Docker به‌طور پیش‌فرض از overlay2 به‌عنوان ذخیره‌ساز لایه‌ای برای کانتینرها استفاده می‌کند، اما این امکان را دارید که نوع ذخیره‌ساز را تغییر دهید.

مثال پیکربندی ذخیره‌سازی در daemon.json:

{
    "storage-driver": "overlay2",
    "data-root": "/mnt/docker-data"
}

در اینجا:

• "storage-driver": "overlay2" تنظیم می‌کند که Docker از overlay2 به‌عنوان درایور ذخیره‌سازی استفاده کند. شما می‌توانید گزینه‌های دیگری مثل aufs, btrfs, zfs یا devicemapper را نیز انتخاب کنید، اما overlay2 بهترین عملکرد را در اکثر سیستم‌ها دارد.
• "data-root": "/mnt/docker-data" مسیر ذخیره‌سازی داده‌ها را به پوشه‌ی دلخواه تغییر می‌دهد. این گزینه به شما این امکان را می‌دهد که مکانی دیگر را برای ذخیره داده‌ها تعیین کنید.

---

3. تنظیم سطح لاگینگ (Logging Levels)

یکی دیگر از تنظیمات مهم در Docker Daemon، تعیین سطح لاگینگ است. شما می‌توانید سطح لاگینگ را با استفاده از تنظیمات مختلف در فایل daemon.json پیکربندی کنید تا اطلاعات بیشتری از وضعیت Docker دریافت کنید یا لاگ‌ها را محدودتر کنید.

مقدار پیش‌فرض لاگ‌ها: Docker به‌طور پیش‌فرض از json-file برای ذخیره لاگ‌های کانتینر استفاده می‌کند. شما می‌توانید گزینه‌های مختلفی را برای لاگ‌ها از جمله max-size, max-file و تغییر فرمت خروجی پیکربندی کنید.

مثال پیکربندی لاگینگ در daemon.json:

{
    "log-driver": "json-file",
    "log-opts": {
        "max-size": "10m",
        "max-file": "3"
    }
}

در اینجا:

• "log-driver": "json-file" تعیین می‌کند که Docker از json-file به‌عنوان درایور ذخیره‌سازی لاگ‌ها استفاده کند. در صورتی که بخواهید از دیگر درایورهای لاگینگ استفاده کنید، گزینه‌های دیگری مثل syslog, journald, fluentd, gelf و غیره وجود دارند.
• "max-size": "10m" این گزینه حداکثر اندازه یک فایل لاگ را به ۱۰ مگابایت محدود می‌کند. وقتی اندازه فایل لاگ به این مقدار برسد، فایل جدیدی ایجاد خواهد شد.
• "max-file": "3" تعداد فایل‌های لاگ ذخیره‌شده را محدود می‌کند. در اینجا حداکثر تعداد فایل‌های لاگ که ذخیره می‌شوند ۳ است.

---

4. فعال‌سازی Experimental Features

Docker به شما این امکان را می‌دهد که ویژگی‌های آزمایشی (Experimental Features) را فعال یا غیرفعال کنید. این ویژگی‌ها معمولاً برای تست قابلیت‌های جدیدی در Docker پیش از انتشار رسمی به‌کار می‌روند. برای فعال‌سازی این ویژگی‌ها در Docker، باید گزینه‌ی experimental را در فایل daemon.json به‌صورت زیر تنظیم کنید:

مثال فعال‌سازی Experimental Features در daemon.json:

{
    "experimental": true
}

در اینجا:

• "experimental": true ویژگی‌های آزمایشی را فعال می‌کند. توجه داشته باشید که این ویژگی‌ها ممکن است به‌طور کامل تست نشده باشند و ممکن است باعث ایجاد مشکلات در محیط‌های تولیدی شوند. بنابراین، توصیه می‌شود تنها در محیط‌های آزمایشی از این ویژگی‌ها استفاده کنید.

---

جمع‌بندی

در این بخش، نحوه پیکربندی Docker Daemon از طریق فایل daemon.json را به تفصیل بررسی کردیم. با استفاده از این فایل می‌توان تنظیمات مختلفی مانند گزینه‌های ذخیره‌سازی، سطح لاگینگ و فعال‌سازی ویژگی‌های آزمایشی را انجام داد. به‌طور کلی، پیکربندی صحیح Docker Daemon باعث بهینه‌سازی عملکرد و امنیت Docker می‌شود و به شما این امکان را می‌دهد که Docker را مطابق با نیازهای خود سفارشی کنید. در محیط‌های تولیدی و بزرگ، تنظیمات مناسب می‌تواند تأثیر قابل توجهی در عملکرد سیستم‌های شما داشته باشد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”فعال‌سازی auto-start Docker daemon هنگام بوت سیستم” subtitle=”توضیحات کامل”]یکی از ویژگی‌های مهم Docker، قابلیت راه‌اندازی خودکار (auto-start) Docker daemon هنگام بوت سیستم است. این ویژگی به‌ویژه در محیط‌های تولیدی و سیستم‌های سرور بسیار مهم است، زیرا به‌طور خودکار Docker را پس از راه‌اندازی مجدد سیستم اجرا می‌کند و نیاز به مداخله دستی برای شروع Docker را از بین می‌برد.

در این بخش، نحوه فعال‌سازی Docker daemon برای شروع خودکار در زمان بوت سیستم را در سیستم‌عامل‌های مختلف بررسی خواهیم کرد. این عملیات به‌ویژه در سیستم‌عامل‌های لینوکس بسیار کاربردی است.

---

1. فعال‌سازی auto-start در سیستم‌عامل‌های لینوکس

در سیستم‌های مبتنی بر لینوکس، برای فعال‌سازی auto-start Docker daemon هنگام بوت، می‌توان از systemd که مدیر سیستم و خدمات پیش‌فرض در بیشتر توزیع‌های لینوکس است استفاده کرد.

مراحل فعال‌سازی auto-start Docker daemon:

1. ابتدا باید وضعیت Docker daemon را بررسی کنیم که آیا به‌صورت خودکار راه‌اندازی می‌شود یا خیر. برای این کار، دستور زیر را وارد کنید:

   sudo systemctl is-enabled docker
   

   اگر خروجی این دستور enabled باشد، Docker daemon به‌طور خودکار هنگام بوت سیستم راه‌اندازی می‌شود.

2. در صورتی که Docker daemon به‌طور پیش‌فرض فعال نباشد، می‌توانید آن را با دستور زیر برای شروع خودکار در زمان بوت سیستم فعال کنید:

   sudo systemctl enable docker
   

   این دستور باعث می‌شود که Docker daemon به‌طور خودکار در هنگام بوت سیستم اجرا شود.

3. حالا برای تأیید این‌که Docker daemon به‌طور خودکار شروع می‌شود، می‌توانید مجدداً دستور زیر را وارد کنید:

   sudo systemctl is-enabled docker
   

   این‌بار باید خروجی enabled را مشاهده کنید.

4. در صورت نیاز به غیرفعال کردن auto-start، می‌توانید دستور زیر را وارد کنید:

   sudo systemctl disable docker
   

   این دستور باعث می‌شود Docker daemon در هنگام بوت سیستم به‌طور خودکار راه‌اندازی نشود.

---

2. فعال‌سازی auto-start در سیستم‌عامل‌های ویندوز

در ویندوز، Docker برای شروع خودکار از یک سرویس ویندوزی استفاده می‌کند. Docker Desktop برای ویندوز به‌طور پیش‌فرض به‌گونه‌ای پیکربندی شده است که در زمان بوت سیستم به‌طور خودکار شروع شود.

مراحل فعال‌سازی auto-start در ویندوز:

1. از منوی Start وارد Docker Desktop شوید.
2. در بالای پنجره Docker Desktop، روی آیکن چرخ‌دنده (تنظیمات) کلیک کنید.
3. به تب General بروید.
4. گزینه Start Docker Desktop when you log in را فعال کنید.

این کار باعث می‌شود Docker Desktop در هر بار ورود به سیستم به‌طور خودکار راه‌اندازی شود.

---

3. فعال‌سازی auto-start در سیستم‌عامل macOS

در macOS، Docker Desktop به‌طور پیش‌فرض به گونه‌ای پیکربندی شده است که هنگام ورود به سیستم به‌طور خودکار اجرا شود.

مراحل فعال‌سازی auto-start در macOS:

1. Docker Desktop را باز کنید.
2. از منوی بالای صفحه، گزینه Preferences را انتخاب کنید.
3. در پنجره تنظیمات، به تب General بروید.
4. گزینه Start Docker Desktop when you log in را فعال کنید.

این کار باعث می‌شود که Docker Desktop به‌طور خودکار هنگام ورود به سیستم اجرا شود.

---

جمع‌بندی

فعال‌سازی auto-start برای Docker daemon هنگام بوت سیستم، یک ویژگی حیاتی برای هر محیطی است که نیاز به اطمینان از راه‌اندازی خودکار Docker پس از راه‌اندازی مجدد سیستم دارد. در سیستم‌عامل‌های لینوکس از طریق systemd می‌توان این ویژگی را فعال کرد و در سیستم‌عامل‌های ویندوز و macOS از تنظیمات داخلی Docker Desktop برای این کار استفاده می‌شود. این قابلیت به‌ویژه در سرورهای تولیدی و سیستم‌های خودکار که نیاز به اطمینان از راه‌اندازی بدون دخالت کاربر دارند، بسیار مفید است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی و مدیریت تنظیمات پیش‌فرض Docker” subtitle=”توضیحات کامل”]تنظیمات پیش‌فرض Docker برای بسیاری از ویژگی‌ها و رفتارهای این پلتفرم طراحی شده‌اند، تا کاربران بدون نیاز به پیکربندی دستی، بتوانند از Docker برای ساخت، اجرا و مدیریت کانتینرها استفاده کنند. با این حال، در برخی مواقع نیاز به تغییر این تنظیمات پیش‌فرض برای بهینه‌سازی عملکرد، افزایش امنیت یا تطبیق با نیازهای خاص پروژه وجود دارد.

در این بخش، به بررسی و مدیریت تنظیمات پیش‌فرض Docker خواهیم پرداخت و نحوه تغییر آن‌ها را در سیستم‌عامل‌های مختلف بررسی خواهیم کرد.

---

1. بررسی تنظیمات پیش‌فرض Docker

برای مشاهده تنظیمات پیش‌فرض Docker، می‌توان از دستور docker info استفاده کرد. این دستور اطلاعات کلی در مورد وضعیت Docker، نسخه، تعداد کانتینرها و دیگر جزئیات مربوط به تنظیمات پیش‌فرض را نمایش می‌دهد.

دستور:

docker info

این دستور شامل اطلاعاتی مانند:

• نسخه Docker و پیکربندی‌ها
• تعداد کانتینرها و ایمیج‌های موجود
• تنظیمات شبکه پیش‌فرض
• تنظیمات ذخیره‌سازی پیش‌فرض
• مسیر‌های پیش‌فرض برای ذخیره داده‌ها و کانتینرها

همچنین می‌توانید از دستور docker version برای مشاهده جزئیات نسخه Docker استفاده کنید که شامل نسخه Docker Engine و Docker Compose می‌باشد.

دستور:

docker version

---

2. تغییر تنظیمات پیش‌فرض Docker از طریق فایل daemon.json

Docker از فایل پیکربندی daemon.json برای مدیریت تنظیمات پیش‌فرض خود استفاده می‌کند. این فایل معمولاً در مسیر /etc/docker/daemon.json قرار دارد (در لینوکس). از طریق این فایل، می‌توان تنظیمات مختلفی مانند ذخیره‌سازی، پورت‌ها، تنظیمات شبکه، و دیگر ویژگی‌ها را تغییر داد.

مراحل تغییر تنظیمات پیش‌فرض از طریق فایل daemon.json:

1. ایجاد یا ویرایش فایل daemon.json
   برای ویرایش فایل پیکربندی daemon.json از ویرایشگر متن دلخواه خود استفاده کنید:

   sudo nano /etc/docker/daemon.json
   

2. تنظیمات موجود در daemon.json:
   در این فایل، شما می‌توانید تنظیمات مختلف را تغییر دهید. به عنوان مثال:
   • تغییر تنظیمات ذخیره‌سازی:
     می‌توانید مسیر ذخیره‌سازی داده‌های Docker را تغییر دهید. به‌طور پیش‌فرض، Docker از /var/lib/docker برای ذخیره داده‌ها استفاده می‌کند.

     {
       "data-root": "/mnt/docker-data"
     }
     

   • فعال‌سازی پورت‌ها:
     برای تغییر پورت‌های پیش‌فرض، می‌توانید پیکربندی مربوطه را تغییر دهید.

     {
       "host": "tcp://0.0.0.0:2375"
     }
     

   • فعال‌سازی ویژگی‌های Experimental:
     برای فعال‌سازی ویژگی‌های experimental (توسعه‌ای) که هنوز به‌طور کامل پشتیبانی نمی‌شوند، می‌توانید تنظیمات زیر را اضافه کنید:

     {
       "experimental": true
     }
     

3. ذخیره و بارگذاری مجدد تنظیمات:
   پس از ویرایش فایل، آن را ذخیره کرده و تغییرات را با دستور زیر اعمال کنید:

   sudo systemctl restart docker
   

   این دستور Docker daemon را مجدداً راه‌اندازی می‌کند تا تغییرات اعمال شود.

---

3. تنظیمات پیش‌فرض در Docker Desktop (ویندوز و macOS)

در Docker Desktop برای ویندوز و macOS، تنظیمات پیش‌فرض معمولاً از طریق رابط کاربری گرافیکی (GUI) قابل مدیریت هستند. در اینجا نحوه تغییر برخی از تنظیمات پیش‌فرض در Docker Desktop را بررسی می‌کنیم.

مراحل تغییر تنظیمات پیش‌فرض در Docker Desktop:

1. دسترسی به تنظیمات Docker Desktop:
   ابتدا Docker Desktop را باز کنید و از منوی بالای صفحه، روی آیکن چرخ‌دنده (Settings) کلیک کنید.
2. تغییر تنظیمات ذخیره‌سازی:
   در بخش Resources، می‌توانید تنظیمات مربوط به منابع سیستم مانند حافظه، تعداد CPUها، و فضای دیسک را تنظیم کنید. این بخش به شما این امکان را می‌دهد که منابع مورد استفاده Docker را مدیریت کنید.
3. مدیریت ویژگی‌های پیشرفته:
   در قسمت Daemon، می‌توانید ویژگی‌های پیشرفته Docker مانند فعال‌سازی ویژگی‌های experimental یا تنظیمات پروکسی را پیکربندی کنید.

---

4. برخی تنظیمات رایج پیش‌فرض Docker و نحوه تغییر آن‌ها

• تغییر پورت Docker Daemon: به‌طور پیش‌فرض، Docker از پورت 2375 برای ارتباط با Docker daemon استفاده می‌کند. این پورت را می‌توان به‌دلخواه تغییر داد:

  {
    "host": "tcp://0.0.0.0:2376"
  }
  

• تغییر زمان پیش‌فرض Timeout: اگر نیاز به تغییر مدت زمان Timeout برای کانتینرها یا درخواست‌ها دارید، می‌توانید تنظیمات مربوطه را در فایل daemon.json اعمال کنید:

  {
    "shutdown-timeout": 15
  }
  

• تنظیمات پروکسی: در صورتی که Docker در پشت یک پروکسی قرار دارد، باید تنظیمات مربوط به پروکسی را در فایل پیکربندی قرار دهید:

  {
    "proxies": {
      "default": {
        "httpProxy": "http://proxy.example.com:80",
        "httpsProxy": "http://proxy.example.com:80",
        "noProxy": "localhost,127.0.0.1"
      }
    }
  }
  

---

جمع‌بندی

Docker به‌طور پیش‌فرض با تنظیمات خاصی راه‌اندازی می‌شود که برای بسیاری از کاربران کافی است. با این حال، در بسیاری از سناریوهای پیچیده‌تر، نیاز به تغییر این تنظیمات پیش‌فرض به‌منظور بهینه‌سازی عملکرد، افزایش امنیت یا تطبیق با نیازهای خاص است. تغییر تنظیمات پیش‌فرض Docker می‌تواند از طریق فایل پیکربندی daemon.json انجام شود و در سیستم‌های ویندوز و macOS می‌توان از Docker Desktop برای انجام این تنظیمات استفاده کرد. مدیریت تنظیمات پیش‌فرض به شما این امکان را می‌دهد که Docker را به‌طور دقیق‌تری متناسب با نیازهای خود پیکربندی کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. مدیریت کاربران و تیم‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ایجاد کاربران و گروه‌ها برای دسترسی به Docker” subtitle=”توضیحات کامل”]یکی از مهم‌ترین جنبه‌های امنیتی در استفاده از Docker، مدیریت دسترسی کاربران و گروه‌ها به منابع مختلف Docker است. به‌طور پیش‌فرض، تنها کاربر root یا کاربران با دسترسی‌های مدیریتی می‌توانند به Docker دسترسی پیدا کرده و فرمان‌های آن را اجرا کنند. با این حال، در اکثر سازمان‌ها یا سیستم‌های تولیدی، ممکن است نیاز باشد که دسترسی‌های محدودتری به سایر کاربران اختصاص داده شود تا تنها برخی از آن‌ها توانایی مدیریت Docker و اجرای کانتینرها را داشته باشند.

در این بخش، به نحوه ایجاد کاربران و گروه‌ها برای دسترسی به Docker پرداخته و تنظیمات لازم برای مدیریت دسترسی را بررسی خواهیم کرد.

---

1. ایجاد گروه برای دسترسی به Docker

Docker معمولاً برای دسترسی به خود از گروه docker استفاده می‌کند. با افزودن یک کاربر به این گروه، می‌توانید دسترسی وی را به فرمان‌های Docker مدیریت کنید. به‌طور معمول، اگر کاربری به گروه docker اضافه شود، می‌تواند به‌صورت غیرمستقیم از دستورات Docker استفاده کند بدون اینکه نیاز به دسترسی root داشته باشد.

مراحل ایجاد گروه Docker و اضافه کردن کاربران به آن:

1. ایجاد گروه Docker (در صورت عدم وجود): در اکثر سیستم‌های لینوکسی، گروه docker به‌طور پیش‌فرض ایجاد می‌شود. اما اگر به هر دلیلی این گروه وجود نداشته باشد، می‌توان آن را با دستور زیر ایجاد کرد:

   sudo groupadd docker
   

2. افزودن کاربر به گروه Docker: پس از ایجاد گروه، می‌توانید کاربر موردنظر را به این گروه اضافه کنید. این کار به کاربر اجازه می‌دهد که بدون نیاز به دسترسی root به Docker دسترسی پیدا کند.

   برای اضافه کردن کاربر به گروه docker از دستور زیر استفاده کنید:

   sudo usermod -aG docker username
   

   در اینجا، username نام کاربری است که قصد دارید به گروه docker اضافه کنید. از گزینه -aG برای اضافه کردن کاربر به گروه بدون حذف وی از گروه‌های دیگر استفاده می‌شود.

3. راه‌اندازی مجدد (Log out و Log in): پس از اضافه کردن کاربر به گروه، باید از سیستم خارج شده و دوباره وارد شوید تا تغییرات اعمال شوند. این کار موجب می‌شود که گروه‌های جدیدی که به کاربر اضافه شده‌اند، به‌طور صحیح شناسایی شوند.

   exit
   

   سپس دوباره وارد شوید و بررسی کنید که کاربر توانایی اجرای دستورات Docker را داشته باشد.

---

2. مدیریت دسترسی‌های خاص با استفاده از دستور sudo

اگر شما تمایل دارید که برخی از کاربران تنها به‌صورت موقت یا در شرایط خاص به Docker دسترسی داشته باشند، می‌توانید از دستور sudo برای مدیریت سطح دسترسی‌ها استفاده کنید. برای این کار، ابتدا باید فایل پیکربندی sudoers را ویرایش کنید.

مراحل تنظیم دسترسی با استفاده از دستور sudo:

1. ویرایش فایل sudoers: با استفاده از ویرایشگر متنی visudo به ویرایش فایل sudoers بروید. این فایل برای تعریف سطح دسترسی‌های مدیریتی در سیستم مورد استفاده قرار می‌گیرد.

   sudo visudo
   

2. اضافه کردن دسترسی‌های خاص برای کاربران: برای اعطای دسترسی به دستورات Docker به کاربر خاص، می‌توانید خط زیر را به فایل sudoers اضافه کنید:

   username ALL=(ALL) NOPASSWD: /usr/bin/docker
   

   در اینجا، username باید با نام کاربری که می‌خواهید به آن دسترسی بدهید، جایگزین شود. این دستور به کاربر اجازه می‌دهد تا دستور Docker را بدون وارد کردن رمز عبور اجرا کند.

3. ذخیره و بستن فایل sudoers: پس از اضافه کردن تنظیمات موردنظر، تغییرات را ذخیره کرده و از ویرایشگر خارج شوید.

---

3. مدیریت دسترسی‌ها برای گروه‌های مختلف

برای مدیریت دسترسی‌های پیچیده‌تر، می‌توان از گروه‌ها استفاده کرد تا کاربران با سطوح دسترسی مختلف برای استفاده از Docker مشخص شوند. این کار معمولاً برای محیط‌های بزرگ یا تیم‌های توسعه‌ دهنده که نیاز به تخصیص دسترسی‌های متفاوت دارند، مفید است.

مراحل ایجاد گروه‌های مختلف برای دسترسی به Docker:

1. ایجاد گروه‌های مختلف: ابتدا گروه‌های مختلفی برای سطوح دسترسی مختلف ایجاد کنید. به‌عنوان مثال، ممکن است گروه‌های docker-admin و docker-user را برای مدیریت دسترسی‌های مختلف ایجاد کنید:

   sudo groupadd docker-admin
   sudo groupadd docker-user
   

2. افزودن کاربران به گروه‌ها: سپس کاربران مختلف را به گروه‌های مختلف اضافه کنید. برای مثال، کاربر john را به گروه docker-admin و کاربر jane را به گروه docker-user اضافه کنید:

   sudo usermod -aG docker-admin john
   sudo usermod -aG docker-user jane
   

3. اعطای دسترسی‌های مدیریتی: برای گروه‌های خاص (مثل docker-admin)، می‌توانید دسترسی کامل به Docker بدهید و برای گروه‌های دیگر (مثل docker-user) محدودیت‌هایی اعمال کنید.

   در مثال بالا، گروه docker-admin ممکن است دسترسی کامل به Docker داشته باشد، در حالی که گروه docker-user فقط دسترسی برای مشاهده وضعیت کانتینرها و اجرای دستورات خاص را داشته باشد.

---

4. بررسی دسترسی‌ها و مجوزها

پس از انجام تغییرات و افزودن کاربران به گروه‌های مختلف، لازم است که دسترسی‌های اعمال شده را بررسی کنید تا مطمئن شوید که کاربران توانایی‌های موردنظر را دارند.

برای تست دسترسی‌ها، کافی است که دستور Docker را با کاربری که تغییرات روی آن اعمال شده است، اجرا کنید:

1. بررسی دسترسی به Docker برای یک کاربر:

   به‌عنوان مثال، کاربری که به گروه docker اضافه شده است، می‌تواند دستور docker info را اجرا کند:

   docker info
   

   اگر دسترسی به Docker به‌درستی تنظیم شده باشد، کاربر باید اطلاعات مربوط به Docker daemon را مشاهده کند.

---

جمع‌بندی

ایجاد کاربران و گروه‌ها برای دسترسی به Docker یکی از مهم‌ترین اقدامات برای مدیریت امنیت در سیستم‌های مبتنی بر Docker است. با استفاده از گروه‌ها و تنظیمات خاص، می‌توان دسترسی به Docker را به‌صورت دقیق‌تر و امن‌تری کنترل کرد. از طریق فایل sudoers و گروه‌های مختلف، می‌توان سطوح مختلف دسترسی به منابع Docker را برای کاربران مختلف تعیین کرد. این امکان به شما این اجازه را می‌دهد که دسترسی‌های مدیریتی را به کاربران خاص اختصاص دهید و از هرگونه دسترسی غیرمجاز جلوگیری کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیم مجوزها و نقش‌ها برای کاربران مختلف” subtitle=”توضیحات کامل”]مدیریت دسترسی‌ها و مجوزهای کاربران در Docker یکی از بخش‌های حیاتی در حفظ امنیت و سازمان‌دهی منابع در محیط‌های تولیدی است. هر کاربری که به سیستم Docker دسترسی دارد باید نقش‌ها و مجوزهای مشخصی داشته باشد تا از سوءاستفاده و اختلال در سیستم جلوگیری شود. این قابلیت به‌ویژه در محیط‌های تیمی و سازمانی که چندین توسعه‌دهنده و اپراتور با هم کار می‌کنند، اهمیت زیادی دارد.

در این بخش، به نحوه تنظیم مجوزها و نقش‌ها برای کاربران مختلف در Docker خواهیم پرداخت و روش‌های مدیریت دسترسی‌های کاربران به‌طور جزئی‌تر بررسی خواهد شد.

---

1. نقش‌ها و سطوح دسترسی در Docker

در Docker به‌طور پیش‌فرض، مدیریت دسترسی‌ها از طریق گروه‌ها و سیستم‌های مدیریتی مانند sudoers انجام می‌شود. Docker به‌طور ذاتی نقش‌های مختلفی ندارد، اما با استفاده از مدیریت گروه‌ها و تنظیمات دسترسی‌های خاص، می‌توان نقش‌های مختلفی را برای کاربران ایجاد کرد. این سطوح دسترسی می‌تواند شامل موارد زیر باشد:

1. مدیر Docker (Admin):
   • این نقش دارای دسترسی کامل به تمام دستورهای Docker است. کاربران این نقش می‌توانند سرویس‌ها را مدیریت کرده، کانتینرها را ایجاد و حذف کنند و به پیکربندی‌های Docker دسترسی پیدا کنند.
   • این نقش معمولاً برای کاربرانی که مسئول راه‌اندازی و پشتیبانی سیستم‌های Docker هستند، تخصیص داده می‌شود.
2. کاربر Docker (User):
   • این نقش معمولاً دسترسی‌های محدودتری دارد و به کاربران اجازه می‌دهد تا تنها عملیات خاصی را مانند مشاهده وضعیت کانتینرها، اجرای کانتینرهای خاص یا بررسی وضعیت سیستم انجام دهند.
   • این نقش برای توسعه‌دهندگان یا کاربران غیرمدیریتی مناسب است که نیاز به دسترسی کامل به تمام قابلیت‌های Docker ندارند.
3. گروه‌ها و کنترل دسترسی‌های خاص:
   • همان‌طور که قبلاً ذکر شد، برای مدیریت دسترسی‌ها می‌توان از گروه‌های مختلف استفاده کرد. گروه‌های مختلف به کاربران اجازه می‌دهند تا فقط به برخی از بخش‌های Docker دسترسی پیدا کنند.
   • به‌عنوان مثال، یک گروه به نام docker-admin می‌تواند تمام دسترسی‌ها را به خود اختصاص دهد، در حالی که یک گروه مانند docker-user می‌تواند فقط به مشاهده وضعیت کانتینرها و اجرای برخی دستورات خاص بپردازد.

---

2. مدیریت مجوزها و دسترسی‌ها در سطح گروه

در Docker، معمولاً برای مدیریت دسترسی‌های مختلف از گروه‌ها استفاده می‌شود. با افزودن کاربر به یک گروه خاص، می‌توانید مجوزهای آن کاربر را در مورد دسترسی به Docker کنترل کنید.

1. ایجاد گروه و افزودن کاربر به گروه:

   برای ایجاد یک گروه خاص (مثلاً برای کاربران غیرمدیریتی) و افزودن یک کاربر به آن گروه، از دستورات زیر استفاده کنید:

   sudo groupadd docker-users  # ایجاد گروه جدید
   sudo usermod -aG docker-users username  # افزودن کاربر به گروه
   

2. اعطای دسترسی‌های مختلف به گروه‌ها:

   پس از ایجاد گروه‌ها، می‌توان دسترسی‌های خاصی را برای هر گروه تعیین کرد. برای مثال، می‌توانید به گروه docker-admin دسترسی کامل به Docker بدهید و گروه docker-user را به دسترسی‌های محدودتری اختصاص دهید.

3. کنترل دسترسی‌های بیشتر با استفاده از sudoers:

   در صورتی که بخواهید مجوزهای دقیق‌تری را برای گروه‌ها و کاربران تعیین کنید، می‌توانید از فایل sudoers برای تنظیم این دسترسی‌ها استفاده کنید. در این فایل می‌توانید مشخص کنید که کدام کاربران یا گروه‌ها اجازه استفاده از دستور Docker را دارند و آیا نیاز به وارد کردن رمز عبور دارند یا خیر.

   به‌عنوان مثال، برای اعطای دسترسی به کاربر بدون نیاز به وارد کردن رمز عبور، این خط را به فایل sudoers اضافه کنید:

   username ALL=(ALL) NOPASSWD: /usr/bin/docker
   

---

3. استفاده از ابزارهای گرافیکی برای مدیریت دسترسی‌ها

اگر از Docker به‌صورت حرفه‌ای و در محیط‌های بزرگ استفاده می‌کنید، ممکن است نیاز به ابزارهای گرافیکی برای مدیریت دسترسی‌ها و نقش‌ها داشته باشید. ابزارهایی مانند Portainer می‌توانند در این زمینه مفید باشند.

Portainer به شما این امکان را می‌دهد که از یک رابط کاربری وب برای مدیریت Docker استفاده کنید. با این ابزار می‌توان کاربران مختلف را با نقش‌های مشخص تعریف کرد و دسترسی‌های آن‌ها را محدود یا گسترده کرد.

• تعریف نقش‌ها در Portainer:
  • در Portainer، شما می‌توانید نقش‌هایی مانند Administrator, Editor, Viewer و غیره ایجاد کنید. هر نقش سطوح دسترسی متفاوتی به بخش‌های مختلف Docker دارد.
  • پس از تعریف نقش‌ها، می‌توانید هر کاربر را به یک یا چند نقش اختصاص دهید.

---

4. تخصیص دسترسی‌های خاص برای عملیات مختلف Docker

در بعضی موارد، ممکن است نیاز به تنظیم دسترسی‌های خاص برای کاربران جهت انجام برخی عملیات ویژه در Docker داشته باشید. به‌عنوان مثال، برخی از کاربران ممکن است نیاز داشته باشند که فقط کانتینرها را مشاهده کنند ولی نتوانند آن‌ها را حذف کنند یا تغییر دهند. در این حالت، دستورات خاص می‌تواند به‌طور مستقیم به گروه‌ها اختصاص داده شود.

مثال:

1. مشاهده وضعیت کانتینرها:

   برای دادن دسترسی مشاهده وضعیت کانتینرها، می‌توان از دستور زیر استفاده کرد:

   docker ps  # لیست کردن کانتینرها
   

   این دستور به کاربران اجازه می‌دهد تا کانتینرهای در حال اجرا را مشاهده کنند اما امکان مدیریت آن‌ها را نداشته باشند.

2. اجرای کانتینر خاص:

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

   docker run --name container_name image_name
   

   در این حالت، کاربران می‌توانند تنها کانتینرهایی با پیکربندی‌های مشخص را اجرا کنند و دسترسی به اجرای دیگر کانتینرها نخواهند داشت.

---

جمع‌بندی

مدیریت دسترسی‌ها و تخصیص نقش‌ها برای کاربران مختلف در Docker یکی از ضروری‌ترین کارها در هنگام راه‌اندازی و استفاده از Docker در محیط‌های تولیدی و تیمی است. با استفاده از گروه‌ها و سیستم‌های مدیریت دسترسی مانند sudoers و ابزارهایی مانند Portainer، می‌توانید دسترسی‌های مختلفی برای کاربران مختلف ایجاد کنید و از به‌وجود آمدن مشکلات امنیتی جلوگیری کنید. همچنین، تخصیص دسترسی‌های خاص برای انجام عملیات ویژه در Docker به شما این امکان را می‌دهد که سطح دسترسی‌ها را به‌طور دقیق و در سطح عملیات خاص مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از دستورات CLI برای مدیریت کاربران” subtitle=”توضیحات کامل”]در Docker، به‌طور پیش‌فرض کاربران با دسترسی‌های مختلفی به سیستم Docker اختصاص می‌یابند. این دسترسی‌ها معمولاً از طریق گروه‌ها و سیستم‌های مدیریتی مانند sudoers کنترل می‌شوند، اما برای محیط‌های مختلف و نیازهای خاص می‌توان از دستورات CLI برای مدیریت کاربران و دسترسی‌های آن‌ها استفاده کرد.

مدیریت کاربران در Docker بیشتر حول دسترسی به دایرکتوری‌های خاص، استفاده از Docker CLI، و تنظیمات سطوح دسترسی در گروه‌ها می‌چرخد. در این بخش، به بررسی و توضیح دستورات اصلی CLI برای مدیریت کاربران در Docker خواهیم پرداخت.

---

1. افزودن کاربر به گروه Docker

در Docker، به‌منظور اعطای دسترسی به دستورات Docker بدون نیاز به استفاده از sudo، معمولاً کاربران را به گروه docker اضافه می‌کنند. این گروه به کاربران اجازه می‌دهد که بدون نیاز به دسترسی root، از دستورات Docker استفاده کنند. برای این کار، می‌توان از دستور usermod استفاده کرد.

دستور افزودن کاربر به گروه Docker:

sudo usermod -aG docker username

• usermod: دستور استفاده‌شده برای ویرایش ویژگی‌های یک کاربر.
• -aG: این گزینه به این معنی است که کاربر به گروه اضافه می‌شود (بدون حذف از گروه‌های قبلی).
• docker: نام گروهی است که به آن کاربر افزوده می‌شود.
• username: نام کاربری که باید به گروه اضافه شود.

پس از اجرای این دستور، لازم است که کاربر از سیستم خارج و دوباره وارد شود تا تغییرات اعمال شوند. به‌عنوان مثال، برای ورود مجدد، کاربر می‌تواند از دستور زیر استفاده کند:

exit

سپس دوباره وارد حساب کاربری خود شود.

---

2. حذف کاربر از گروه Docker

اگر بخواهید دسترسی‌های یک کاربر به Docker را لغو کنید، می‌توانید وی را از گروه docker حذف کنید. این کار را با دستور زیر می‌توان انجام داد:

دستور حذف کاربر از گروه Docker:

sudo gpasswd -d username docker

• gpasswd -d: این دستور برای حذف کاربر از یک گروه استفاده می‌شود.
• username: نام کاربری که باید از گروه حذف شود.
• docker: نام گروهی است که کاربر از آن حذف خواهد شد.

---

3. بررسی گروه‌های یک کاربر

برای بررسی گروه‌هایی که یک کاربر عضو آن‌ها است، از دستور groups استفاده می‌شود. این دستور به شما نشان می‌دهد که کاربر در کدام گروه‌ها قرار دارد.

دستور بررسی گروه‌های یک کاربر:

groups username

• username: نام کاربری که می‌خواهید گروه‌های آن را مشاهده کنید.

نتیجه این دستور، لیستی از گروه‌هایی است که کاربر به آن‌ها تعلق دارد. برای مثال، اگر کاربر john به گروه docker افزوده شده باشد، خروجی ممکن است به شکل زیر باشد:

john : john docker

---

4. ایجاد گروه جدید برای مدیریت دسترسی‌های Docker

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

دستور ایجاد گروه جدید:

sudo groupadd docker-viewers

• groupadd: دستور استفاده‌شده برای ایجاد گروه جدید.
• docker-viewers: نام گروه جدید که می‌خواهید ایجاد کنید.

پس از ایجاد گروه، می‌توانید کاربران موردنظر را به آن گروه اضافه کنید:

sudo usermod -aG docker-viewers username

---

5. دستورات مدیریت دسترسی‌ها در فایل sudoers

در صورتی که نیاز دارید دسترسی‌های خاصی به دستورات Docker برای کاربرانی ایجاد کنید (مانند اجازه اجرای Docker بدون نیاز به رمز عبور)، می‌توانید فایل sudoers را ویرایش کنید. برای این کار از دستور visudo استفاده می‌شود تا امنیت فایل sudoers حفظ شود و از ایجاد خطاهای ناخواسته جلوگیری شود.

دستور برای ویرایش فایل sudoers:

sudo visudo

در این فایل، شما می‌توانید دسترسی‌های خاص به دستورات Docker را تنظیم کنید. برای مثال، برای این‌که کاربر خاصی بتواند دستورات Docker را بدون نیاز به وارد کردن رمز عبور اجرا کند، می‌توانید خط زیر را به فایل sudoers اضافه کنید:

username ALL=(ALL) NOPASSWD: /usr/bin/docker

• username: نام کاربری که به آن دسترسی می‌دهید.
• ALL=(ALL): به کاربر اجازه دسترسی به تمام دستورات را می‌دهد.
• NOPASSWD: این گزینه نشان می‌دهد که کاربر نیاز به وارد کردن رمز عبور ندارد.
• /usr/bin/docker: مسیر دقیق دستور Docker که کاربر می‌تواند آن را اجرا کند.

پس از اعمال این تغییرات، کاربر می‌تواند بدون نیاز به وارد کردن رمز عبور، دستورات Docker را اجرا کند.

---

6. استفاده از دستور docker info برای بررسی دسترسی‌ها

برای بررسی اطلاعات مربوط به Docker و دسترسی‌های آن، می‌توانید از دستور docker info استفاده کنید. این دستور اطلاعات مفصلی درباره وضعیت سیستم Docker و گروه‌های مختلف به‌دست می‌دهد.

دستور بررسی اطلاعات سیستم Docker:

docker info

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

---

7. نظارت بر فعالیت‌های کاربران در Docker

برای نظارت و بررسی فعالیت‌های کاربران در Docker، معمولاً از لاگ‌های سیستم یا ابزارهای خارجی استفاده می‌شود. شما می‌توانید از دستور journalctl برای مشاهده لاگ‌های سیستم استفاده کنید و فعالیت‌های مرتبط با Docker را نظارت کنید.

دستور مشاهده لاگ‌ها در سیستم‌های لینوکسی:

sudo journalctl -u docker

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

---

جمع‌بندی

مدیریت دسترسی‌ها و کاربران در Docker یک بخش حیاتی از تنظیمات امنیتی است. با استفاده از دستورات CLI می‌توانید به راحتی کاربران جدید ایجاد کرده و آن‌ها را به گروه‌ها و نقش‌های مختلف اختصاص دهید. همچنین، با ویرایش فایل sudoers، امکان کنترل دقیق‌تری روی دسترسی‌های کاربران و اجرای دستورات خاص فراهم می‌شود. این اقدامات می‌توانند به‌ویژه در محیط‌های تیمی و سازمانی که چندین کاربر و گروه در حال تعامل با Docker هستند، بسیار مفید واقع شوند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. پیکربندی درایورهای ذخیره‌سازی (Storage Drivers)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”انتخاب و پیکربندی درایور ذخیره‌سازی مناسب” subtitle=”توضیحات کامل”]یکی از مراحل کلیدی در تنظیم Docker برای ذخیره‌سازی داده‌ها، انتخاب درایور ذخیره‌سازی (Storage Driver) مناسب است. Docker از درایورهای ذخیره‌سازی مختلفی پشتیبانی می‌کند که هرکدام ویژگی‌ها و محدودیت‌های خاص خود را دارند. انتخاب درایور صحیح می‌تواند تأثیر زیادی بر عملکرد و مقیاس‌پذیری سیستم Docker شما داشته باشد.

در این بخش، به بررسی سه درایور ذخیره‌سازی اصلی Docker خواهیم پرداخت: OverlayFS، Device Mapper و AUFS.

---

1. OverlayFS (توزیع‌های مدرن لینوکس)

OverlayFS یکی از درایورهای ذخیره‌سازی پیشرفته است که در بسیاری از توزیع‌های لینوکس مدرن استفاده می‌شود. این درایور به‌ویژه برای سیستم‌هایی که از هسته لینوکس نسخه 3.18 به بالا استفاده می‌کنند، توصیه می‌شود. OverlayFS از یک مدل لایه‌بندی استفاده می‌کند که به‌طور مؤثر فضای ذخیره‌سازی را مدیریت می‌کند.

ویژگی‌ها و مزایای OverlayFS:

• عملکرد بالا: OverlayFS یکی از سریع‌ترین درایورهای ذخیره‌سازی Docker است و عملکرد بسیار خوبی در نوشتن و خواندن داده‌ها دارد.
• سبک و ساده: OverlayFS نیازی به استفاده از فضای ذخیره‌سازی اضافی ندارد، زیرا از لایه‌های موجود به‌طور بهینه استفاده می‌کند.
• پشتیبانی از توزیع‌های لینوکس مدرن: به‌طور پیش‌فرض در توزیع‌هایی مانند Ubuntu، CentOS و RHEL در دسترس است.

معایب:

• پشتیبانی از نسخه‌های قدیمی‌تر هسته لینوکس: OverlayFS فقط از هسته‌های لینوکس نسخه 3.18 به بعد پشتیبانی می‌کند. بنابراین، اگر از توزیع‌هایی با هسته‌های قدیمی‌تر استفاده می‌کنید، باید درایورهای دیگری را انتخاب کنید.

پیکربندی OverlayFS در Docker:

برای استفاده از OverlayFS در Docker، ابتدا باید اطمینان حاصل کنید که سیستم شما از این درایور پشتیبانی می‌کند و سپس در فایل تنظیمات Docker (/etc/docker/daemon.json) درایور مناسب را تنظیم کنید.

مثال پیکربندی درایور OverlayFS در فایل daemon.json:

{
  "storage-driver": "overlay2"
}

• overlay2 نسخه بهینه‌شده از OverlayFS است که در بسیاری از سیستم‌ها توصیه می‌شود.
• پس از تغییر این تنظیمات، Docker باید مجدداً راه‌اندازی شود:

sudo systemctl restart docker

---

2. Device Mapper (سیستم‌عامل‌های قدیمی‌تر)

Device Mapper یکی از درایورهای ذخیره‌سازی قدیمی است که بیشتر در سیستم‌عامل‌هایی که به هسته‌های قدیمی‌تر لینوکس نیاز دارند، مورد استفاده قرار می‌گیرد. این درایور از فناوری حجمی (LVM) برای مدیریت حجم‌های ذخیره‌سازی استفاده می‌کند و می‌تواند داده‌ها را به‌طور بهینه مدیریت کند.

ویژگی‌ها و مزایای Device Mapper:

• پشتیبانی از حجم‌های مجازی: این درایور به‌طور مؤثری از حجم‌های مجازی (LVM) برای جداسازی داده‌ها استفاده می‌کند.
• پشتیبانی از نسخه‌های قدیمی‌تر لینوکس: این درایور برای نسخه‌های قدیمی‌تر هسته لینوکس طراحی شده است و می‌تواند در سیستم‌های قدیمی که از OverlayFS پشتیبانی نمی‌کنند، استفاده شود.

معایب:

• عملکرد پایین‌تر نسبت به OverlayFS: درایور Device Mapper معمولاً سرعت کمتری نسبت به درایور OverlayFS دارد.
• پیچیدگی بیشتر: پیکربندی و مدیریت این درایور پیچیده‌تر است و نیاز به تنظیمات اضافی دارد.

پیکربندی Device Mapper در Docker:

برای استفاده از Device Mapper، می‌توانید مشابه با تنظیمات OverlayFS، در فایل daemon.json درایور را انتخاب کنید.

مثال پیکربندی درایور Device Mapper:

{
  "storage-driver": "devicemapper"
}

• پس از تغییر تنظیمات، Docker باید دوباره راه‌اندازی شود:

sudo systemctl restart docker

---

3. AUFS (برای نسخه‌های خاص لینوکس)

AUFS (Another Union File System) یکی دیگر از درایورهای ذخیره‌سازی است که بیشتر در نسخه‌های خاصی از لینوکس مانند برخی توزیع‌های قدیمی‌تر Ubuntu مورد استفاده قرار می‌گیرد. AUFS از لایه‌بندی مشابه OverlayFS استفاده می‌کند، اما از لحاظ عملکرد و پیچیدگی، تفاوت‌هایی دارد.

ویژگی‌ها و مزایای AUFS:

• پشتیبانی از لایه‌های پیچیده: AUFS به شما این امکان را می‌دهد که لایه‌های مختلفی را به‌طور پیچیده مدیریت کنید و داده‌ها را در لایه‌های مختلف ذخیره کنید.
• پشتیبانی از توزیع‌های خاص: برخی از توزیع‌های قدیمی‌تر لینوکس و Docker از این درایور پشتیبانی می‌کنند.

معایب:

• پشتیبانی محدود: AUFS به‌طور پیش‌فرض در برخی از توزیع‌ها غیرفعال است و در بسیاری از سیستم‌ها ممکن است مشکلات پشتیبانی ایجاد کند.
• عملکرد پایین‌تر: AUFS معمولاً نسبت به درایورهای دیگر مانند OverlayFS یا Device Mapper عملکرد پایین‌تری دارد.

پیکربندی AUFS در Docker:

برای استفاده از AUFS، می‌توانید در فایل daemon.json درایور را مشخص کنید.

مثال پیکربندی درایور AUFS:

{
  "storage-driver": "aufs"
}

• پس از تغییر تنظیمات، Docker باید دوباره راه‌اندازی شود:

sudo systemctl restart docker

---

جمع‌بندی

انتخاب درایور ذخیره‌سازی مناسب برای Docker بستگی به نیازهای خاص سیستم شما دارد. OverlayFS بهترین گزینه برای سیستم‌های لینوکس مدرن است، چراکه عملکرد بالایی دارد و فضای ذخیره‌سازی بهینه‌ای ارائه می‌دهد. Device Mapper برای سیستم‌های قدیمی‌تر و محیط‌های خاص که نیاز به استفاده از LVM دارند، مناسب است. در نهایت، AUFS برای برخی توزیع‌های خاص لینوکس قابل استفاده است، اما به‌طور کلی در مقایسه با دو درایور دیگر کمتر توصیه می‌شود.

با تنظیم مناسب درایور ذخیره‌سازی، می‌توانید عملکرد Docker را بهینه‌سازی کنید و از منابع سیستم به‌طور بهینه استفاده نمایید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مدیریت فضای ذخیره‌سازی و تنظیم سیستم فایل” subtitle=”توضیحات کامل”]در Docker، یکی از مهم‌ترین بخش‌ها در پیکربندی و مدیریت سیستم، مدیریت فضای ذخیره‌سازی است. این امر به‌ویژه زمانی اهمیت پیدا می‌کند که شما با حجم زیادی از داده‌ها و کانتینرها سروکار دارید و باید مطمئن شوید که داده‌ها به‌طور مؤثر و با حداقل تلفات فضایی ذخیره می‌شوند. در این بخش، نحوه مدیریت فضای ذخیره‌سازی در Docker و تنظیم سیستم فایل بررسی خواهد شد.

---

1. مدیریت فضای ذخیره‌سازی در Docker

Docker برای ذخیره‌سازی داده‌ها از درایورهای ذخیره‌سازی (Storage Drivers) استفاده می‌کند که به‌طور مؤثر لایه‌ها و فایل‌های موجود در کانتینرها را مدیریت می‌کند. انتخاب صحیح درایور ذخیره‌سازی و پیکربندی مناسب آن برای بهینه‌سازی مصرف فضای ذخیره‌سازی بسیار مهم است.

درایورهای مختلفی که Docker از آن‌ها استفاده می‌کند عبارتند از: OverlayFS، Device Mapper، AUFS، Btrfs، و ZFS. این درایورها می‌توانند تفاوت‌هایی در نحوه ذخیره‌سازی، عملکرد، و مصرف فضای دیسک داشته باشند.

مراحل مدیریت فضای ذخیره‌سازی در Docker:

1. بررسی فضای ذخیره‌سازی استفاده‌شده توسط Docker:

   برای بررسی میزان فضای استفاده‌شده توسط Docker می‌توانید از دستور زیر استفاده کنید:

   docker system df
   

   این دستور اطلاعاتی از قبیل میزان فضای اشغال‌شده توسط کانتینرها، تصاویر (Images)، و حجم‌های (Volumes) Docker ارائه می‌دهد.

2. تمیز کردن فایل‌ها و داده‌های اضافی:

   Docker به‌طور خودکار برخی فایل‌ها و داده‌های قدیمی را حذف نمی‌کند. برای کاهش حجم دیسک، می‌توانید از دستور docker system prune برای حذف موارد غیرضروری استفاده کنید:

   docker system prune -a
   

   این دستور تمام کانتینرهای متوقف‌شده، تصاویر بدون استفاده، و حجم‌های بدون استفاده را حذف خواهد کرد.

---

2. تنظیم سیستم فایل در Docker

تنظیمات سیستم فایل در Docker به پیکربندی ذخیره‌سازی و نحوه استفاده از سیستم فایل‌های مختلف بستگی دارد. Docker به‌طور پیش‌فرض از یک سیستم فایل مخصوص به خود برای مدیریت لایه‌ها و کانتینرها استفاده می‌کند. این سیستم فایل در داخل دایرکتوری /var/lib/docker ذخیره می‌شود و می‌توان آن را تنظیم کرد.

تنظیم مسیر ذخیره‌سازی در Docker:

برای تغییر مسیر ذخیره‌سازی Docker، می‌توانید تنظیمات پیش‌فرض را در فایل daemon.json تغییر دهید. این تغییرات به شما این امکان را می‌دهند که مسیر ذخیره‌سازی را به پوشه یا دیسک دیگری انتقال دهید.

مراحل تنظیم مسیر ذخیره‌سازی:

1. ایجاد یا ویرایش فایل daemon.json:

   فایل daemon.json در مسیر /etc/docker/ قرار دارد. در این فایل می‌توانید تنظیمات Docker را تغییر دهید. برای مثال، برای تغییر مسیر ذخیره‌سازی می‌توانید از تنظیمات زیر استفاده کنید:

   {
     "data-root": "/new/path/to/docker"
   }
   

2. ری‌استارت Docker:

   پس از تغییر مسیر ذخیره‌سازی، باید Docker را ری‌استارت کنید تا تغییرات اعمال شود:

   sudo systemctl restart docker
   

3. اطمینان از تغییر مسیر:

   پس از اعمال تغییرات، برای اطمینان از اینکه مسیر ذخیره‌سازی تغییر کرده است، می‌توانید دستور زیر را اجرا کنید:

   docker info | grep "Docker Root Dir"
   

   این دستور مسیر جدید ذخیره‌سازی Docker را نمایش می‌دهد.

---

3. استفاده از Volume برای ذخیره‌سازی دائمی داده‌ها

در Docker، برای ذخیره‌سازی داده‌ها به‌صورت دائمی و در دسترس، از Volume استفاده می‌شود. Volume یک مکان مستقل برای ذخیره داده‌ها است که خارج از کانتینر قرار دارد و به‌طور ویژه برای ذخیره‌سازی داده‌های پایدار و غیرقابل تغییر طراحی شده است.

مزایای استفاده از Volume‌ها:

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

ایجاد و استفاده از Volume:

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

1. ایجاد Volume:

   docker volume create my_volume
   

2. اتصال Volume به کانتینر:

   برای اتصال Volume به یک کانتینر، از دستور زیر استفاده کنید:

   docker run -d -v my_volume:/data my_image
   

   این دستور Volume ایجاد شده را به دایرکتوری /data داخل کانتینر متصل می‌کند.

3. مشاهده Volume‌های موجود:

   برای مشاهده تمام Volume‌های موجود در سیستم خود، از دستور زیر استفاده کنید:

   docker volume ls
   

---

4. مدیریت فضای ذخیره‌سازی با استفاده از درایورهای ذخیره‌سازی مختلف

درایورهای ذخیره‌سازی Docker نقش حیاتی در مدیریت داده‌ها و لایه‌ها ایفا می‌کنند. انتخاب درایور مناسب می‌تواند تأثیر زیادی بر عملکرد و مصرف فضای دیسک داشته باشد.

برخی از درایورهای ذخیره‌سازی Docker:

1. OverlayFS: این درایور به‌طور خاص برای سیستم‌های لینوکس مدرن طراحی شده است و عملکرد بالایی دارد. در صورت استفاده از این درایور، فضای ذخیره‌سازی به‌طور بهینه مدیریت می‌شود.
2. Device Mapper: این درایور بیشتر در سیستم‌های قدیمی‌تر لینوکس یا سیستم‌هایی که از LVM استفاده می‌کنند، کاربرد دارد.
3. AUFS: در سیستم‌های خاص و قدیمی‌تر لینوکس قابل استفاده است، اما در مقایسه با سایر درایورها دارای محدودیت‌هایی است.
4. Btrfs و ZFS: این درایورها برای سیستم‌های خاص و پیشرفته طراحی شده‌اند و می‌توانند ویژگی‌هایی مانند فشرده‌سازی و تهیه Snapshot از داده‌ها را ارائه دهند.

انتخاب درایور مناسب:

• اگر سیستم شما از لینوکس مدرن استفاده می‌کند، OverlayFS معمولاً بهترین گزینه است.
• برای سیستم‌های قدیمی‌تر یا برای استفاده از LVM، Device Mapper مناسب است.
• اگر نیاز به ویژگی‌های پیشرفته مانند فشرده‌سازی و Snapshot دارید، Btrfs یا ZFS گزینه‌های مناسبی هستند.

---

جمع‌بندی

مدیریت فضای ذخیره‌سازی و تنظیم سیستم فایل در Docker از اهمیت بالایی برخوردار است، به‌ویژه زمانی که با حجم زیادی از داده‌ها و کانتینرها سروکار دارید. انتخاب درایور ذخیره‌سازی مناسب، استفاده از Volume‌ها برای ذخیره‌سازی دائمی، و تنظیم سیستم فایل می‌تواند به بهبود عملکرد و کاهش مصرف فضای دیسک کمک کند. در این راستا، استفاده از دستوراتی مانند docker system df و docker volume ls برای نظارت بر فضای ذخیره‌سازی و مدیریت داده‌ها ضروری است. همچنین، انتخاب درایور ذخیره‌سازی مناسب، به‌ویژه برای سیستم‌های مختلف، می‌تواند تأثیر زیادی در بهینه‌سازی عملکرد و مصرف منابع داشته باشد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. تنظیمات لاگینگ (Logging Configuration)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیم مکانیزم‌های لاگینگ Docker” subtitle=”توضیحات کامل”]یکی از بخش‌های مهم در فرآیند مدیریت کانتینرها و سیستم‌های مبتنی بر Docker، نظارت و تجزیه و تحلیل لاگ‌ها است. Docker به‌طور پیش‌فرض از مکانیزم‌های لاگینگ مختلفی برای ذخیره‌سازی اطلاعات و پیام‌ها استفاده می‌کند. این لاگ‌ها می‌توانند شامل پیغام‌های خطا، پیغام‌های اطلاع‌رسانی، و داده‌های ورودی و خروجی باشند که از اجرای کانتینرها و سرویس‌ها به‌دست می‌آید.

در این بخش، به بررسی مکانیزم‌های لاگینگ Docker می‌پردازیم و نحوه تنظیم و استفاده از یکی از پرکاربردترین و پیش‌فرض‌ترین گزینه‌ها، یعنی json-file را توضیح خواهیم داد.

---

1. مکانیزم‌های لاگینگ در Docker

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

• json-file (فرمت پیش‌فرض لاگ): این فرمت ذخیره‌سازی لاگ به‌طور پیش‌فرض برای بیشتر کانتینرها استفاده می‌شود و پیام‌های لاگ را به صورت فایل‌های JSON ذخیره می‌کند.
• syslog: این مکانیزم از پروتکل Syslog برای ارسال لاگ‌ها به سرورهای مرکزی Syslog استفاده می‌کند.
• journald: این گزینه از سیستم لاگینگ systemd برای ذخیره و مدیریت لاگ‌ها استفاده می‌کند.
• fluentd: از این روش برای ارسال لاگ‌ها به سیستم‌های مدیریت لاگ‌های Fluentd استفاده می‌شود.
• gelf (Graylog Extended Log Format): این روش برای ارسال لاگ‌ها به سیستم‌های Graylog یا دیگر سیستم‌های مشابه استفاده می‌شود.
• logentries: این گزینه برای ارسال لاگ‌ها به سرویس‌های Logentries استفاده می‌شود.
• awslogs: این روش برای ارسال لاگ‌ها به سرویس لاگ‌های AWS (Amazon Web Services) استفاده می‌شود.

هرکدام از این مکانیزم‌ها مزایا و کاربردهای خاص خود را دارند. با این حال، json-file به‌عنوان فرمت پیش‌فرض Docker به‌دلیل سادگی، قابلیت جستجوی مناسب و پشتیبانی از تمام ویژگی‌های معمول، به‌طور گسترده‌ای استفاده می‌شود.

---

2. مکانیزم لاگینگ json-file

فرمت json-file در Docker به‌طور پیش‌فرض لاگ‌های تولیدشده توسط کانتینرها را در فایل‌هایی با فرمت JSON ذخیره می‌کند. این فرمت به شما این امکان را می‌دهد که لاگ‌ها را به راحتی تجزیه و تحلیل کرده و از آن‌ها در سیستم‌های دیگر استفاده کنید. هر پیغام لاگ در این فرمت به‌صورت یک شیء JSON ذخیره می‌شود که شامل جزئیاتی مانند زمان، سطح لاگ، و پیام است.

ویژگی‌های اصلی json-file:

• ساده بودن: فرمت JSON به‌طور گسترده‌ای برای ذخیره‌سازی لاگ‌ها مورد استفاده قرار می‌گیرد، به‌ویژه در محیط‌های توسعه و آزمایش.
• قابلیت تجزیه و تحلیل: به دلیل ساختار JSON، تجزیه و تحلیل لاگ‌ها آسان‌تر می‌شود و می‌توان از ابزارهای مختلف مانند jq برای پردازش داده‌های آن استفاده کرد.
• قابلیت پیکربندی: می‌توان گزینه‌های مختلفی مانند محدودیت حجم فایل، نحوه چرخش (rotation) و ذخیره‌سازی فایل‌های لاگ را برای این مکانیزم تنظیم کرد.

ساختار فایل‌های لاگ در json-file:

هر لاگ در این فرمت به‌صورت یک شیء JSON ذخیره می‌شود که معمولاً شامل اطلاعات زیر است:

• log: متن پیام لاگ.
• stream: مشخص‌کننده‌ی اینکه لاگ از کدام جریان آمده است (stdout یا stderr).
• time: زمان تولید پیام لاگ.
• container_id: شناسه کانتینر.
• container_name: نام کانتینر.

مثال یک لاگ در فرمت json-file:

{
  "log": "This is a log message.\n",
  "stream": "stdout",
  "time": "2025-02-09T08:15:12.694698597Z",
  "container_id": "e5f8c3c3f5b2",
  "container_name": "/my_container"
}

---

3. پیکربندی json-file به‌عنوان مکانیزم لاگ پیش‌فرض

شما می‌توانید json-file را به‌عنوان مکانیزم لاگ پیش‌فرض در کانتینرهای Docker خود پیکربندی کنید. برای این کار، می‌توانید از فایل daemon.json استفاده کرده و تنظیمات دلخواه خود را اعمال کنید. به‌طور پیش‌فرض، Docker از این مکانیزم استفاده می‌کند، اما می‌توان تنظیمات خاصی را برای آن مشخص کرد.

مراحل پیکربندی json-file در Docker:

1. ویرایش فایل daemon.json: برای تغییر تنظیمات پیش‌فرض Docker، ابتدا باید فایل daemon.json را ویرایش کنید. این فایل معمولاً در مسیر /etc/docker/ قرار دارد. اگر این فایل وجود ندارد، می‌توانید آن را ایجاد کنید.

   به‌عنوان مثال، برای پیکربندی json-file، می‌توانید تنظیمات زیر را در فایل daemon.json اضافه کنید:

   {
     "log-driver": "json-file",
     "log-opts": {
       "max-size": "10m",
       "max-file": "3"
     }
   }
   

   در این مثال:

   • log-driver: مشخص می‌کند که Docker از مکانیزم لاگ json-file استفاده کند.
   • max-size: حداکثر اندازه فایل لاگ. در اینجا هر فایل لاگ به اندازه 10MB محدود می‌شود.
   • max-file: حداکثر تعداد فایل‌های لاگ حفظ‌شده. در اینجا تعداد فایل‌های لاگ به سه عدد محدود شده است.
2. ری‌استارت Docker Daemon: پس از ویرایش فایل daemon.json و انجام تغییرات، باید Docker Daemon را ری‌استارت کنید تا تنظیمات جدید اعمال شوند:

   sudo systemctl restart docker
   

3. بررسی تنظیمات جدید: پس از اعمال تغییرات، برای اطمینان از اینکه تنظیمات جدید اعمال شده‌اند، می‌توانید از دستور زیر برای بررسی وضعیت استفاده کنید:

   docker info | grep "Logging Driver"
   

---

4. نظارت و مدیریت لاگ‌ها

برای نظارت و مشاهده لاگ‌های تولیدشده توسط کانتینرها، می‌توانید از دستور docker logs استفاده کنید. این دستور به شما امکان می‌دهد تا پیام‌های لاگ را برای یک کانتینر خاص مشاهده کنید.

دستورات کاربردی:

• مشاهده لاگ‌ها برای یک کانتینر خاص:

  docker logs <container_name_or_id>
  

  این دستور پیام‌های لاگ را برای کانتینر مشخص‌شده نمایش می‌دهد.

• مشاهده لاگ‌ها به صورت پیوسته (با -f):

  اگر می‌خواهید لاگ‌ها را به‌صورت زنده و پیوسته مشاهده کنید، از گزینه -f استفاده کنید:

  docker logs -f <container_name_or_id>
  

• مشاهده لاگ‌ها با محدودیت تعداد خطوط:

  برای مشاهده تعداد محدودی از خطوط اول یا آخر لاگ‌ها، می‌توانید از گزینه‌های --tail یا --head استفاده کنید:

  docker logs --tail 100 <container_name_or_id>
  

  این دستور فقط 100 خط آخر از لاگ‌ها را نمایش می‌دهد.

---

جمع‌بندی

تنظیم مکانیزم‌های لاگینگ در Docker به شما این امکان را می‌دهد که به‌طور مؤثر و کارآمد لاگ‌های کانتینرها را ذخیره و نظارت کنید. استفاده از json-file به‌عنوان فرمت پیش‌فرض لاگ‌ها، یکی از بهترین انتخاب‌ها برای محیط‌های توسعه و آزمایش است. با تنظیمات دقیق در فایل daemon.json، می‌توان محدودیت‌هایی برای اندازه فایل‌ها و تعداد فایل‌های ذخیره‌شده اعمال کرد. همچنین، دستورات Docker مانند docker logs به شما این امکان را می‌دهند که به‌طور مؤثر لاگ‌ها را مشاهده و تجزیه و تحلیل کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از log drivers خارجی مانند Fluentd، Syslog، و AWS CloudWatch” subtitle=”توضیحات کامل”]Docker این امکان را به شما می‌دهد که لاگ‌ها را به سیستم‌های خارجی ارسال کنید و از ابزارهای پیشرفته برای مدیریت، تجزیه و تحلیل، و ذخیره‌سازی لاگ‌ها استفاده کنید. این ویژگی با استفاده از log drivers مختلف انجام می‌شود. به‌طور پیش‌فرض، Docker از log driver json-file استفاده می‌کند، اما شما می‌توانید از log driverهای دیگری مانند Fluentd، Syslog و AWS CloudWatch استفاده کنید تا بتوانید لاگ‌ها را به سیستم‌های خارجی ارسال کنید.

در این بخش، به بررسی نحوه استفاده از این log driverهای خارجی می‌پردازیم و نحوه پیکربندی هر یک از آن‌ها در Docker را توضیح خواهیم داد.

---

1. Fluentd

Fluentd یکی از ابزارهای محبوب برای جمع‌آوری، پردازش و ارسال لاگ‌ها است. Fluentd می‌تواند به عنوان یک log driver در Docker برای ارسال لاگ‌ها به سیستم‌های مختلف مانند ذخیره‌سازی داده‌ها، پایگاه‌های داده، یا ابزارهای مانیتورینگ استفاده شود.

ویژگی‌های Fluentd:

• جمع‌آوری و پردازش لاگ‌ها از منابع مختلف.
• ارسال لاگ‌ها به مقصدهای مختلف مانند Elasticsearch، HDFS، یا Amazon S3.
• پشتیبانی از پلاگین‌های مختلف برای ادغام با سیستم‌های مختلف.

پیکربندی Fluentd در Docker:

برای استفاده از Fluentd به‌عنوان log driver در Docker، باید Fluentd را در سیستم خود نصب کرده و آن را پیکربندی کنید. سپس، Docker را طوری تنظیم کنید که از این log driver برای ارسال لاگ‌ها استفاده کند.

مراحل پیکربندی Fluentd:

1. نصب Fluentd:

   ابتدا باید Fluentd را نصب کنید. می‌توانید از دستور زیر برای نصب آن استفاده کنید (در سیستم‌های مبتنی بر Debian):

   sudo apt-get install td-agent
   

2. پیکربندی Docker برای استفاده از Fluentd:

   بعد از نصب Fluentd، باید Docker را طوری پیکربندی کنید که از این log driver استفاده کند. برای این کار، شما می‌توانید از گزینه --log-driver به همراه fluentd در هنگام اجرای کانتینر استفاده کنید:

   docker run --log-driver=fluentd <image_name>
   

   همچنین می‌توانید تنظیمات اضافی را برای ارسال لاگ‌ها به Fluentd اضافه کنید. برای نمونه:

   docker run --log-driver=fluentd --log-opt fluentd-address=localhost:24224 <image_name>
   

   در اینجا، fluentd-address آدرس و پورت Fluentd است که Docker باید به آن متصل شود.

3. نظارت بر لاگ‌ها:

   بعد از راه‌اندازی کانتینر، Fluentd به‌طور خودکار لاگ‌ها را جمع‌آوری و ارسال می‌کند. شما می‌توانید از ابزارهایی مانند Kibana یا Grafana برای نظارت و تجزیه و تحلیل لاگ‌ها استفاده کنید.

---

2. Syslog

Syslog یک پروتکل استاندارد برای ارسال و ذخیره‌سازی لاگ‌ها در سیستم‌های Unix و Linux است. این پروتکل به‌طور گسترده‌ای در سازمان‌ها و سیستم‌های مختلف برای ذخیره‌سازی و مدیریت لاگ‌ها استفاده می‌شود. در Docker، شما می‌توانید از Syslog به‌عنوان یک log driver برای ارسال لاگ‌ها به سرورهای Syslog استفاده کنید.

ویژگی‌های Syslog:

• ارسال لاگ‌ها به سرورهای Syslog مرکزی.
• پشتیبانی از سطوح مختلف لاگ (Info, Warning, Error).
• مناسب برای استفاده در محیط‌های بزرگ و توزیع‌شده.

پیکربندی Syslog در Docker:

برای استفاده از Syslog در Docker، باید پیکربندی‌های لازم را انجام دهید تا لاگ‌ها به سرور Syslog ارسال شوند.

مراحل پیکربندی Syslog:

1. پیکربندی Docker برای استفاده از Syslog:

   برای ارسال لاگ‌ها به سرور Syslog، می‌توانید از دستور --log-driver=syslog در هنگام اجرای کانتینر استفاده کنید:

   docker run --log-driver=syslog <image_name>
   

2. تنظیمات اضافی:

   می‌توانید تنظیمات اضافی برای اتصال به سرور Syslog و تعیین جزئیات مانند پورت، فیلترهای لاگ و غیره اضافه کنید. برای مثال:

   docker run --log-driver=syslog --log-opt syslog-address=udp://localhost:514 <image_name>
   

   در اینجا، syslog-address آدرس و پورت سرور Syslog است که Docker باید به آن متصل شود.

3. نظارت بر لاگ‌ها:

   بعد از ارسال لاگ‌ها به سرور Syslog، می‌توانید از ابزارهایی مانند rsyslog یا syslog-ng برای نظارت بر این لاگ‌ها استفاده کنید.

---

3. AWS CloudWatch

AWS CloudWatch یکی از سرویس‌های ابری شرکت Amazon است که به شما این امکان را می‌دهد که لاگ‌ها، متریک‌ها، و رویدادهای سیستم‌های خود را جمع‌آوری، ذخیره و تحلیل کنید. Docker به شما این امکان را می‌دهد که از CloudWatch Logs به‌عنوان log driver برای ارسال لاگ‌ها به AWS CloudWatch استفاده کنید.

ویژگی‌های AWS CloudWatch:

• ذخیره‌سازی و تجزیه و تحلیل لاگ‌ها در AWS Cloud.
• مقیاس‌پذیری بالا و یکپارچگی با دیگر سرویس‌های AWS.
• نظارت و هشدار برای لاگ‌ها و متریک‌ها.

پیکربندی AWS CloudWatch در Docker:

برای استفاده از AWS CloudWatch به‌عنوان log driver، باید AWS CLI را پیکربندی کنید و اجازه دهید Docker از آن برای ارسال لاگ‌ها به CloudWatch استفاده کند.

مراحل پیکربندی AWS CloudWatch:

1. پیکربندی AWS CLI:

   ابتدا باید AWS CLI را پیکربندی کنید تا Docker بتواند به حساب AWS شما دسترسی پیدا کند. برای این کار از دستور زیر استفاده کنید:

   aws configure
   

2. پیکربندی Docker برای استفاده از CloudWatch Logs:

   برای ارسال لاگ‌ها به CloudWatch، باید از دستور --log-driver=awslogs در هنگام اجرای کانتینر استفاده کنید:

   docker run --log-driver=awslogs --log-opt awslogs-group=<log_group> --log-opt awslogs-stream=<log_stream> <image_name>
   

   در اینجا:

   • awslogs-group: نام گروه لاگ در CloudWatch.
   • awslogs-stream: نام استریم لاگ که Docker باید آن را ایجاد کند.
3. نظارت بر لاگ‌ها در AWS CloudWatch:

   پس از پیکربندی و ارسال لاگ‌ها به CloudWatch، می‌توانید از AWS CloudWatch Console برای مشاهده، تجزیه و تحلیل، و جستجوی لاگ‌ها استفاده کنید.

---

جمع‌بندی

استفاده از log driverهای خارجی مانند Fluentd، Syslog و AWS CloudWatch می‌تواند امکانات پیشرفته‌تری برای جمع‌آوری، پردازش و ذخیره‌سازی لاگ‌ها فراهم کند. این log driverها به شما کمک می‌کنند تا لاگ‌ها را از کانتینرهای Docker به سیستم‌های خارجی ارسال کرده و از ابزارهای پیشرفته‌تر برای تجزیه و تحلیل و نظارت استفاده کنید. Fluentd برای پردازش و ارسال لاگ‌ها به سیستم‌های مختلف، Syslog برای ارسال به سرورهای Syslog، و AWS CloudWatch برای ذخیره‌سازی و تجزیه و تحلیل لاگ‌ها در AWS گزینه‌های محبوب و مفیدی هستند که می‌توانند به شما در بهبود عملکرد و نظارت بر سیستم‌ها کمک کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی لاگ‌های کانتینرها و سرویس‌ها” subtitle=”توضیحات کامل”]لاگ‌ها یکی از ابزارهای مهم در مدیریت و عیب‌یابی سیستم‌ها هستند، به‌ویژه زمانی که از Docker برای اجرای کانتینرها و سرویس‌ها استفاده می‌کنید. با مشاهده لاگ‌ها می‌توانید اطلاعات دقیقی از عملکرد کانتینرها به‌دست آورید، مشکلات را شناسایی کنید، و برای رفع آن‌ها اقدام کنید. Docker این امکان را به شما می‌دهد که از دستورات مختلف برای بررسی لاگ‌ها استفاده کنید. در این بخش، به بررسی دستورات CLI مانند docker logs برای مشاهده لاگ‌های کانتینرها خواهیم پرداخت.

---

1. docker logs

دستور docker logs یکی از دستورات اصلی برای بررسی لاگ‌های کانتینرها است. با استفاده از این دستور، می‌توانید لاگ‌های خروجی یک کانتینر را مشاهده کنید و اطلاعات مهمی در مورد آن به‌دست آورید. این دستور می‌تواند برای کانتینرهای در حال اجرا و همچنین کانتینرهایی که متوقف شده‌اند مورد استفاده قرار گیرد.

ترکیب دستور:

docker logs [OPTIONS] CONTAINER

مفاهیم و پارامترها:

• CONTAINER: نام یا شناسه کانتینری است که می‌خواهید لاگ‌های آن را مشاهده کنید.
• OPTIONS: گزینه‌های اضافی برای فیلتر کردن یا تغییر نحوه نمایش لاگ‌ها.

گزینه‌های مفید:

1. –tail: تعداد خط‌هایی که از انتهای لاگ‌ها نمایش داده می‌شود را مشخص می‌کند. به‌طور پیش‌فرض، تمام لاگ‌ها نمایش داده می‌شوند. اگر بخواهید فقط تعداد خاصی از خطوط انتهایی را مشاهده کنید، از این گزینه استفاده کنید.

   docker logs --tail 50 <container_name>
   

   این دستور تنها آخرین 50 خط از لاگ‌های کانتینر را نمایش می‌دهد.

2. -f / –follow: این گزینه باعث می‌شود که لاگ‌ها به‌صورت زنده (live) و در حال حرکت نمایش داده شوند. این گزینه به‌خصوص برای نظارت بر کانتینرهایی که در حال اجرا هستند بسیار مفید است.

   docker logs -f <container_name>
   

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

3. –since / –until: این گزینه‌ها به شما این امکان را می‌دهند که لاگ‌ها را برای یک بازه زمانی خاص فیلتر کنید. گزینه --since برای نمایش لاگ‌ها از زمان خاصی و --until برای نمایش لاگ‌ها تا یک زمان خاص استفاده می‌شود.

   docker logs --since "2025-02-09T00:00:00" <container_name>
   

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

4. -t / –timestamps: با استفاده از این گزینه، می‌توانید تایم‌استمپ (زمان) هر خط از لاگ‌ها را نیز مشاهده کنید. این ویژگی به شما کمک می‌کند تا بتوانید ترتیب رخدادها را بهتر درک کنید.

   docker logs -t <container_name>
   

   این دستور لاگ‌ها را با زمان‌های دقیق نمایش می‌دهد.

5. –details: این گزینه باعث نمایش اطلاعات اضافی در لاگ‌ها می‌شود، مانند اطلاعات مربوط به کانتینرهای Docker.

   docker logs --details <container_name>
   

---

2. بررسی لاگ‌های سرویس‌ها در Docker Swarm

در محیط‌های توزیع‌شده مانند Docker Swarm، می‌توانید لاگ‌های مربوط به سرویس‌ها را نیز بررسی کنید. برای این منظور، Docker از قابلیت‌های اضافی برای مانیتورینگ و بررسی لاگ‌ها در سطح سرویس استفاده می‌کند. با استفاده از دستورات CLI، می‌توانید وضعیت سرویس‌ها را بررسی کنید و اطلاعات مهمی از لاگ‌ها به‌دست آورید.

دستورات CLI برای بررسی لاگ‌های سرویس‌ها:

1. docker service logs

این دستور برای مشاهده لاگ‌های سرویس‌های در حال اجرا در یک کلاستر Docker Swarm استفاده می‌شود. مشابه دستور docker logs برای کانتینرها، شما می‌توانید از این دستور برای مشاهده لاگ‌های مربوط به سرویس‌ها استفاده کنید.

ترکیب دستور:

docker service logs [OPTIONS] SERVICE

گزینه‌های مهم:

• -f / –follow: این گزینه مشابه گزینه در دستور docker logs است و به شما این امکان را می‌دهد که لاگ‌های سرویس را به‌صورت زنده مشاهده کنید.

  docker service logs -f <service_name>
  

• –tail: مشابه دستور docker logs برای نمایش تعداد محدودی از خطوط اخیر.

  docker service logs --tail 100 <service_name>
  

• -t / –timestamps: برای مشاهده تایم‌استمپ هر خط از لاگ.

  docker service logs -t <service_name>
  

2. docker stack ps

دستور docker stack ps برای نمایش وضعیت سرویس‌ها و کانتینرهای مرتبط با یک استک در Docker Swarm به کار می‌رود. این دستور اطلاعاتی درباره سلامت و وضعیت کانتینرها ارائه می‌دهد و می‌تواند برای عیب‌یابی مفید باشد.

ترکیب دستور:

docker stack ps [OPTIONS] STACK

گزینه‌ها:

• –no-trunc: برای نمایش اطلاعات کامل و بدون کوتاه‌شده.

  docker stack ps --no-trunc <stack_name>
  

این دستور به شما نمایش کامل‌تری از وضعیت سرویس‌ها و کانتینرها در یک استک می‌دهد.

---

3. جمع‌بندی

بررسی لاگ‌ها یکی از مهم‌ترین مراحل در عیب‌یابی و مانیتورینگ سیستم‌های Docker است. با استفاده از دستورات docker logs برای مشاهده لاگ‌های کانتینرها و دستورات docker service logs برای بررسی لاگ‌های سرویس‌ها، می‌توانید اطلاعات مفیدی از عملکرد و مشکلات موجود در سیستم به‌دست آورید.

دستور docker logs ابزار اصلی برای بررسی لاگ‌های کانتینرها است و امکاناتی نظیر مشاهده لاگ‌ها به‌صورت زنده، فیلتر کردن لاگ‌ها بر اساس زمان، و اضافه کردن تایم‌استمپ به لاگ‌ها را فراهم می‌کند. در محیط‌های Docker Swarm، دستور docker service logs برای مشاهده لاگ‌های سرویس‌ها و دستور docker stack ps برای بررسی وضعیت سرویس‌ها و کانتینرها در استک‌ها استفاده می‌شود.

این ابزارها و دستورات به شما کمک می‌کنند تا مشکلات سیستم را شناسایی کنید، عملکرد کانتینرها و سرویس‌ها را به‌طور دقیق نظارت کنید و عملیات عیب‌یابی را با سرعت و دقت بیشتری انجام دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیم سطح لاگ برای دیباگ” subtitle=”توضیحات کامل”]یکی از جنبه‌های حیاتی در فرآیند عیب‌یابی و دیباگ در Docker، توانایی تنظیم سطح لاگینگ (Logging Level) است. با استفاده از تنظیمات سطح لاگ، شما می‌توانید میزان و نوع اطلاعاتی که Docker در حین اجرای کانتینرها و سرویس‌ها در اختیار شما قرار می‌دهد را کنترل کنید. این قابلیت به‌ویژه زمانی که در حال عیب‌یابی یک مشکل پیچیده هستید، بسیار مفید است.

در Docker، تنظیمات لاگ معمولاً از طریق Docker daemon و همچنین در سطح هر کانتینر به‌صورت جداگانه انجام می‌شود. در این بخش، به نحوه تنظیم سطح لاگ و تنظیمات دیباگ خواهیم پرداخت.

---

1. تنظیم سطح لاگ برای Docker Daemon

Docker daemon از روش‌های مختلفی برای مدیریت لاگ‌ها استفاده می‌کند که یکی از آن‌ها تنظیم سطح لاگ در خود daemon است. این تنظیمات به شما این امکان را می‌دهند که میزان اطلاعاتی که Docker daemon ثبت می‌کند را مشخص کنید.

برای تغییر تنظیمات لاگ در Docker daemon، باید فایل پیکربندی daemon.json را ویرایش کنید. این فایل در مسیر /etc/docker/daemon.json قرار دارد (ممکن است در سیستم‌های مختلف مکان آن متفاوت باشد).

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

1. ابتدا فایل daemon.json را باز کنید یا آن را ایجاد کنید (اگر وجود ندارد):

sudo nano /etc/docker/daemon.json

2. سپس تنظیمات سطح لاگ را در این فایل اضافه کنید. یکی از این تنظیمات، مشخص کردن سطح لاگ است که در آن می‌توانید یکی از مقادیر زیر را وارد کنید:

• “debug”: در این حالت Docker تمام اطلاعات دیباگ و اشکال‌زدایی را ثبت می‌کند. این تنظیم بهترین انتخاب برای عیب‌یابی مشکلات پیچیده است.
• “info”: سطح لاگ استاندارد است که اطلاعات کافی در مورد عملکرد Docker را فراهم می‌کند.
• “warn”: فقط هشدارها و خطاها نمایش داده می‌شوند.
• “error”: تنها خطاها ثبت می‌شوند.
• “fatal”: تنها خطاهای بحرانی ثبت می‌شوند که منجر به توقف عملیات می‌شوند.

برای تنظیم سطح لاگ به “debug”، باید فایل daemon.json را به‌صورت زیر پیکربندی کنید:

{
  "log-level": "debug"
}

3. پس از ذخیره تغییرات، Docker daemon را برای اعمال تنظیمات مجدد راه‌اندازی کنید:

sudo systemctl restart docker

---

2. تنظیم سطح لاگ در Docker Container

علاوه بر تنظیم سطح لاگ در Docker daemon، شما می‌توانید تنظیمات لاگ را به‌طور خاص برای هر کانتینر به‌صورت جداگانه تنظیم کنید. به‌طور پیش‌فرض، Docker از لاگ‌درایور json-file برای کانتینرها استفاده می‌کند. این لاگ‌درایور به شما امکان می‌دهد که لاگ‌ها را ذخیره کرده و آن‌ها را برای عیب‌یابی مشاهده کنید.

برای تنظیم سطح لاگ در هنگام اجرای یک کانتینر، می‌توانید از گزینه --log-driver و --log-opt استفاده کنید. همچنین می‌توانید گزینه‌های خاصی مانند max-size و max-file را برای کنترل اندازه لاگ‌ها تنظیم کنید.

مثال دستور برای تنظیم سطح لاگ و ویژگی‌های آن در هنگام اجرای کانتینر:

docker run -d --name mycontainer --log-driver=json-file --log-opt max-size=10m --log-opt max-file=3 myimage

در این دستور:

• --log-driver=json-file: مشخص می‌کند که از لاگ‌درایور json-file استفاده شود.
• --log-opt max-size=10m: تعیین می‌کند که هر فایل لاگ بیش از 10 مگابایت بزرگ نشود.
• --log-opt max-file=3: مشخص می‌کند که تنها سه فایل لاگ نگه‌داشته شوند و قدیمی‌ترین فایل‌ها حذف شوند.

سطوح لاگ در کانتینر:

در صورتی که از لاگ‌درایورهایی مانند fluentd یا syslog استفاده می‌کنید، می‌توانید سطح لاگ را برای این درایورها نیز تنظیم کنید. به‌طور مثال، برای fluentd می‌توانید تنظیمات مشابه زیر را اعمال کنید:

docker run -d --name mycontainer --log-driver=fluentd --log-opt fluentd-address=localhost:24224 --log-opt fluentd-async=true myimage

---

3. مشاهده لاگ‌ها با سطح دیباگ

برای مشاهده لاگ‌ها در سطح دیباگ، معمولاً می‌توانید از دستور docker logs برای مشاهده لاگ‌های کانتینرها و سرویس‌ها استفاده کنید. وقتی سطح لاگ به “debug” تغییر کند، اطلاعات بیشتری به لاگ‌ها اضافه می‌شود که ممکن است شامل جزئیات بیشتری در مورد فرایندهای داخلی Docker باشد.

مثال دستور برای مشاهده لاگ‌ها:

docker logs -f --tail 100 mycontainer

در این دستور:

• -f: نمایش لاگ‌ها به‌صورت زنده.
• --tail 100: نمایش 100 خط آخر از لاگ‌ها.

توجه: با تنظیم سطح لاگ به “debug”، حجم زیادی از اطلاعات به لاگ‌ها افزوده می‌شود، بنابراین مشاهده لاگ‌ها ممکن است بیشتر طول بکشد و فضای ذخیره‌سازی بیشتری نیاز داشته باشد.

---

جمع‌بندی

تنظیم سطح لاگ برای دیباگ در Docker یکی از ابزارهای کلیدی برای شناسایی و حل مشکلات است. با استفاده از تنظیمات مختلف مانند “debug”، “info”، و “error” می‌توانید سطح اطلاعاتی که در طول اجرای کانتینرها و سرویس‌ها جمع‌آوری می‌شود را کنترل کنید.

• در سطح Docker daemon، می‌توانید از فایل پیکربندی daemon.json برای تنظیم سطح لاگ استفاده کنید.
• در سطح کانتینرها، می‌توانید از گزینه‌های مختلف مانند --log-driver و --log-opt برای تنظیم ویژگی‌های لاگینگ استفاده کنید.

این تنظیمات به شما امکان می‌دهند که به‌صورت دقیق‌تری مشکلات را شناسایی کنید و عملیات عیب‌یابی را به‌طور مؤثر انجام دهید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. پیکربندی شبکه (Network Configuration)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیمات اولیه شبکه‌های Docker” subtitle=”توضیحات کامل”]شبکه‌ها یکی از اجزای کلیدی در Docker هستند که به کانتینرها اجازه می‌دهند تا با یکدیگر و با سیستم‌های خارجی ارتباط برقرار کنند. Docker به‌طور پیش‌فرض سه نوع شبکه اصلی را فراهم می‌کند که شامل Bridge، NAT و None می‌شود. هر یک از این شبکه‌ها به منظورهای مختلف و با ویژگی‌های خاص خود طراحی شده‌اند. در این بخش، به بررسی و تنظیم این شبکه‌ها خواهیم پرداخت.

---

1. شبکه Bridge

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

ویژگی‌های شبکه Bridge:

• محیط مجزا: کانتینرها که به شبکه Bridge متصل هستند، در یک محیط شبکه مجزا قرار دارند و تنها از طریق پورت‌ها به یکدیگر و سیستم خارجی می‌توانند ارتباط برقرار کنند.
• IP خصوصی: هر کانتینر در شبکه Bridge یک آدرس IP خصوصی دریافت می‌کند.
• پورت فورواردینگ: برای ارتباط با سیستم‌های خارجی، باید پورت‌های کانتینر را به پورت‌های سیستم میزبان فوروارد کنید.

ایجاد و راه‌اندازی شبکه Bridge:

شما می‌توانید به‌طور دستی شبکه Bridge خود را ایجاد کرده و سپس کانتینرها را به آن متصل کنید. برای این کار از دستور docker network create استفاده می‌شود:

docker network create --driver bridge my_bridge_network

سپس هنگام راه‌اندازی یک کانتینر، آن را به شبکه Bridge جدید متصل می‌کنید:

docker run -d --name my_container --network my_bridge_network my_image

در این حالت، کانتینر شما به شبکه‌ای به نام my_bridge_network متصل خواهد شد.

---

2. شبکه NAT (Network Address Translation)

شبکه NAT یک شبکه مجازی است که برای اتصال کانتینرها به شبکه خارجی و اینترنت استفاده می‌شود. زمانی که یک کانتینر به شبکه Bridge متصل می‌شود، از NAT برای ارسال و دریافت داده‌ها از شبکه‌های خارجی استفاده می‌کند.

ویژگی‌های شبکه NAT:

• ترجمه آدرس شبکه: شبکه NAT به طور خودکار آدرس IP کانتینرها را به آدرس IP میزبان ترجمه می‌کند تا ارتباطات آن‌ها به شبکه‌های خارجی تسهیل شود.
• ایزوله‌سازی: کانتینرها در شبکه NAT به یکدیگر دسترسی ندارند، مگر اینکه پورت‌های خاصی برای برقراری ارتباط فوروارد شود.
• دسترسی به اینترنت: کانتینرهایی که به شبکه NAT متصل هستند، می‌توانند به اینترنت دسترسی داشته باشند، اما از طریق آدرس IP میزبان در اینترنت قابل شناسایی خواهند بود.

ایجاد و راه‌اندازی شبکه NAT:

شبکه NAT به طور پیش‌فرض توسط Docker ایجاد می‌شود و به‌طور خودکار برای کانتینرها استفاده می‌شود، بنابراین معمولاً نیازی به ایجاد دستی آن نیست. با این حال، برای ایجاد یک شبکه NAT جدید می‌توانید از دستور زیر استفاده کنید:

docker network create --driver nat my_nat_network

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

docker run -d --name my_container --network my_nat_network my_image

---

3. شبکه None

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

ویژگی‌های شبکه None:

• بدون ارتباط شبکه: کانتینرهای متصل به این شبکه نمی‌توانند به هیچ‌کدام از شبکه‌های دیگر Docker یا شبکه‌های خارجی دسترسی داشته باشند.
• مناسب برای موارد خاص: این شبکه بیشتر در شرایطی استفاده می‌شود که نیاز به ایزوله کردن کامل کانتینر از دیگر کانتینرها یا شبکه‌ها باشد.

ایجاد و راه‌اندازی شبکه None:

برای متصل کردن کانتینر به شبکه None می‌توانید از دستور زیر استفاده کنید:

docker run -d --name my_container --network none my_image

در این حالت، کانتینر هیچ‌گونه اتصال شبکه‌ای نخواهد داشت.

---

جمع‌بندی

در Docker، شبکه‌ها نقش مهمی در مدیریت ارتباطات بین کانتینرها و سیستم‌های خارجی دارند. تنظیمات پیش‌فرض شبکه‌ها شامل موارد زیر می‌شود:

• Bridge: شبکه پیش‌فرض برای اکثر کانتینرها که به‌طور خودکار هنگام نصب Docker ایجاد می‌شود و برای برقراری ارتباط بین کانتینرها و سیستم میزبان استفاده می‌شود.
• NAT: برای اتصال کانتینرها به اینترنت و ترجمه آدرس‌ها استفاده می‌شود. به‌طور خودکار برای شبکه‌های Bridge مورد استفاده قرار می‌گیرد.
• None: شبکه‌ای که هیچ‌گونه ارتباطی به شبکه‌های دیگر یا اینترنت ندارد و تنها برای ایزوله‌سازی کانتینرها از شبکه‌های خارجی به کار می‌رود.

با استفاده از این شبکه‌ها، می‌توانید انعطاف‌پذیری بیشتری در مدیریت ارتباطات و تنظیمات شبکه‌ای Docker داشته باشید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیمات DNS برای کانتینرها” subtitle=”توضیحات کامل”]در Docker، به‌طور پیش‌فرض، کانتینرها برای ترجمه دامنه‌ها به آدرس‌های IP از DNS سیستم میزبان (host) استفاده می‌کنند. اما در برخی شرایط ممکن است نیاز به پیکربندی خاص DNS برای کانتینرها داشته باشیم. Docker این امکان را فراهم می‌آورد که DNS‌های مختلفی را به کانتینرها تخصیص دهیم تا آن‌ها بتوانند از آن برای انجام درخواست‌های DNS خود استفاده کنند.

---

1. استفاده از DNS پیش‌فرض (سیستم میزبان)

هنگامی که کانتینرها بدون تنظیمات خاص DNS اجرا می‌شوند، Docker به‌طور پیش‌فرض از تنظیمات DNS سیستم میزبان استفاده می‌کند. در این حالت، کانتینر می‌تواند به همان DNSهایی که سیستم میزبان به آن‌ها متصل است، دسترسی داشته باشد. این رفتار معمولاً کافی است مگر در مواقعی که بخواهید DNSهای خاصی را تنظیم کنید.

دستور اجرای کانتینر با استفاده از DNS پیش‌فرض سیستم میزبان:

docker run -d --name my_container my_image

در این حالت، Docker به‌طور خودکار از تنظیمات DNS سیستم میزبان برای کانتینر استفاده می‌کند.

---

2. تنظیم DNS سفارشی برای کانتینرها

گاهی اوقات ممکن است بخواهید از DNS خاصی برای ترجمه دامنه‌ها به IP استفاده کنید. Docker به شما این امکان را می‌دهد که DNS سفارشی را برای کانتینر خود تعیین کنید. برای این کار می‌توانید از گزینه --dns هنگام اجرای کانتینر استفاده کنید.

نحوه استفاده از DNS سفارشی:

docker run -d --name my_container --dns 8.8.8.8 my_image

در این مثال، کانتینر my_container به DNS سرور 8.8.8.8 (که متعلق به Google است) متصل خواهد شد. شما می‌توانید آدرس‌های DNS سرورهای دیگری مانند 1.1.1.1 (Cloudflare) یا DNS داخلی شرکت خود را نیز وارد کنید.

چند DNS سرور:

اگر بخواهید چند DNS سرور را به کانتینر خود اختصاص دهید، می‌توانید از چند گزینه --dns استفاده کنید:

docker run -d --name my_container --dns 8.8.8.8 --dns 1.1.1.1 my_image

در این حالت، کانتینر شما از DNS سرورهای 8.8.8.8 و 1.1.1.1 استفاده خواهد کرد.

---

3. استفاده از DNS Search Domains

گاهی اوقات نیاز است که به DNSهای خاص یک دامنه جستجو (Search Domain) نیز اشاره کنیم تا کانتینر بتواند به‌طور خودکار دامنه‌ها را جستجو کند. Docker به شما اجازه می‌دهد که از گزینه --dns-search برای تعیین دامنه‌های جستجو استفاده کنید.

نحوه تنظیم دامنه جستجو DNS برای کانتینر:

docker run -d --name my_container --dns-search example.com my_image

در این حالت، کانتینر شما هنگام انجام درخواست‌های DNS ابتدا دامنه example.com را جستجو خواهد کرد.

چند دامنه جستجو:

شما می‌توانید چندین دامنه جستجو را به کانتینر خود اضافه کنید:

docker run -d --name my_container --dns-search example.com --dns-search example.org my_image

در این حالت، کانتینر شما دامنه‌ها را به ترتیب از example.com و example.org جستجو خواهد کرد.

---

4. تنظیم DNS از طریق Docker Compose

در صورتی که از Docker Compose برای مدیریت کانتینرهای چندگانه استفاده می‌کنید، می‌توانید تنظیمات DNS را به‌طور مرکزی در فایل docker-compose.yml تعیین کنید. این کار باعث می‌شود که تنظیمات DNS برای تمام سرویس‌ها درون Compose اعمال شود.

نمونه فایل docker-compose.yml با تنظیم DNS:

version: '3'
services:
  my_service:
    image: my_image
    dns:
      - 8.8.8.8
      - 1.1.1.1
    dns_search:
      - example.com

در این مثال، تمام سرویس‌ها در فایل Compose به DNSهای 8.8.8.8 و 1.1.1.1 متصل خواهند شد و دامنه‌های جستجو نیز example.com خواهند بود.

---

5. پیکربندی DNS در فایل Docker Daemon (مستقل از کانتینر)

اگر می‌خواهید تنظیمات DNS برای تمام کانتینرهایی که به Docker Daemon متصل می‌شوند، اعمال شود، می‌توانید این تنظیمات را در فایل پیکربندی Docker Daemon قرار دهید. فایل پیکربندی Docker Daemon معمولاً daemon.json است که در مسیر /etc/docker/ قرار دارد.

نمونه فایل daemon.json:

{
  "dns": ["8.8.8.8", "1.1.1.1"],
  "dns-search": ["example.com"]
}

در این حالت، تنظیمات DNS به‌طور سراسری برای تمام کانتینرهای جدیدی که ایجاد می‌شوند، اعمال خواهد شد.

---

جمع‌بندی

در Docker، تنظیمات DNS برای کانتینرها از اهمیت ویژه‌ای برخوردار است، زیرا به کانتینرها اجازه می‌دهد تا بتوانند با سرویس‌های شبکه و اینترنت ارتباط برقرار کنند. شما می‌توانید از DNS پیش‌فرض سیستم میزبان استفاده کنید یا DNSهای خاصی را برای کانتینرها تنظیم کنید. به‌علاوه، امکاناتی همچون تعیین دامنه‌های جستجو و استفاده از چند DNS سرور، به شما این امکان را می‌دهند که پیکربندی DNS را به‌طور دقیق‌تری کنترل کنید.

• استفاده از DNS پیش‌فرض: زمانی که نیازی به تنظیمات خاص DNS ندارید.
• تنظیم DNS سفارشی: برای استفاده از DNS خاص.
• استفاده از دامنه‌های جستجو: برای جستجو در دامنه‌های خاص.
• Docker Compose: برای تنظیمات مرکزی DNS در محیط‌های چند کانتینری.
• پیکربندی global (daemon): برای اعمال تنظیمات DNS به تمام کانتینرها به‌طور سراسری.

این تنظیمات به شما کمک می‌کنند تا ارتباطات شبکه‌ای کانتینرهای Docker خود را به‌طور مؤثری مدیریت کنید.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”اضافه کردن تنظیمات شبکه سفارشی” subtitle=”توضیحات کامل”]در Docker، شبکه‌ها نقش مهمی در ارتباط بین کانتینرها و منابع مختلف دارند. به‌طور پیش‌فرض، Docker سه نوع شبکه فراهم می‌آورد: Bridge، Host، و None. با این حال، در بسیاری از سناریوها ممکن است نیاز به ایجاد شبکه‌های سفارشی برای کنترل بهتر ارتباطات بین کانتینرها، تنظیمات IP، یا تخصیص منابع داشته باشیم. Docker به‌راحتی به شما امکان می‌دهد که شبکه‌های سفارشی خود را بسازید و از آن‌ها در پروژه‌های مختلف استفاده کنید.

در این بخش، به بررسی چگونگی اضافه کردن تنظیمات شبکه سفارشی در Docker خواهیم پرداخت.

---

1. ایجاد یک شبکه سفارشی

برای ایجاد یک شبکه سفارشی در Docker، از دستور docker network create استفاده می‌کنیم. این دستور به شما امکان می‌دهد که شبکه‌ای با ویژگی‌های خاص مانند نوع شبکه (Bridge، Overlay، Macvlan و غیره)، تنظیمات DNS، یا تنظیمات آدرس‌دهی IP بسازید.

ساخت یک شبکه سفارشی به‌صورت ساده:

docker network create my_custom_network

این دستور یک شبکه به نام my_custom_network ایجاد می‌کند که به‌طور پیش‌فرض از نوع bridge خواهد بود.

---

2. تنظیم نوع شبکه (Network Driver)

در Docker می‌توانید از انواع مختلفی از درایورهای شبکه (Network Drivers) استفاده کنید. در اینجا به چند نوع از مهم‌ترین درایورهای شبکه اشاره می‌کنیم:

• bridge: شبکه پیش‌فرض برای کانتینرها در سیستم محلی.
• overlay: برای ایجاد شبکه‌ای که میان چند میزبان Docker پخش شده باشد (برای کلاسترهای Swarm).
• host: کانتینر به شبکه میزبان متصل می‌شود.
• macvlan: برای تخصیص یک آدرس MAC به کانتینر و اتصال آن به شبکه فیزیکی.

برای استفاده از هرکدام از این نوع‌ها، باید هنگام ایجاد شبکه از گزینه --driver استفاده کنید.

ساخت شبکه Overlay (برای استفاده در Swarm):

docker network create --driver overlay my_overlay_network

ساخت شبکه macvlan (برای اتصال مستقیم به شبکه فیزیکی):

docker network create --driver macvlan --subnet=192.168.1.0/24 my_macvlan_network

---

3. تنظیمات IP و Subnet برای شبکه

هنگامی که شبکه سفارشی خود را ایجاد می‌کنید، می‌توانید تنظیمات IP و Subnet را نیز تعیین کنید. این امکان به شما می‌دهد که دامنه آدرس‌دهی IP شبکه خود را مشخص کرده و آن را مطابق با نیازهای خود تنظیم کنید.

ساخت شبکه با تنظیمات Subnet:

docker network create --subnet=192.168.1.0/24 my_subnet_network

در این حالت، شبکه‌ای به نام my_subnet_network ساخته می‌شود که IPهای آن از محدوده 192.168.1.0/24 خواهد بود.

---

4. اتصال کانتینر به شبکه سفارشی

پس از ایجاد شبکه سفارشی، می‌توانید کانتینرها را به این شبکه متصل کنید. هنگام اجرای کانتینر، می‌توانید از گزینه --network استفاده کنید تا شبکه مورد نظر را به کانتینر اختصاص دهید.

اتصال کانتینر به شبکه سفارشی:

docker run -d --name my_container --network my_custom_network my_image

این دستور کانتینر my_container را به شبکه my_custom_network متصل می‌کند.

---

5. استفاده از DNS سفارشی در شبکه‌های سفارشی

هنگامی که شبکه سفارشی ایجاد می‌کنید، می‌توانید DNS خاصی را نیز برای شبکه خود تنظیم کنید. این تنظیمات معمولاً زمانی مفید هستند که بخواهید به‌طور خودکار از DNS داخلی یا سرورهای DNS خاص استفاده کنید.

ساخت شبکه سفارشی با DNS سفارشی:

docker network create --dns 8.8.8.8 --dns-search example.com my_network_with_dns

در این حالت، شبکه my_network_with_dns با تنظیم DNS سرور 8.8.8.8 و دامنه جستجوی example.com ساخته می‌شود.

---

6. بررسی شبکه‌های موجود

پس از ایجاد شبکه‌های سفارشی، شما می‌توانید با استفاده از دستور docker network ls شبکه‌های موجود را بررسی کنید.

docker network ls

این دستور فهرستی از تمامی شبکه‌ها، شامل شبکه‌های پیش‌فرض و سفارشی، را نمایش خواهد داد.

---

7. حذف شبکه‌های سفارشی

اگر نیازی به یک شبکه سفارشی نداشتید و می‌خواهید آن را حذف کنید، می‌توانید از دستور docker network rm استفاده کنید.

docker network rm my_custom_network

این دستور شبکه my_custom_network را حذف خواهد کرد. توجه داشته باشید که هیچ کانتینری نباید به این شبکه متصل باشد؛ در غیر این صورت، دستور خطا خواهد داد.

---

جمع‌بندی

ایجاد و استفاده از شبکه‌های سفارشی در Docker به شما این امکان را می‌دهد که کنترل بیشتری بر نحوه ارتباط کانتینرها، تخصیص آدرس‌های IP، و استفاده از DNS داشته باشید. با استفاده از درایورهای مختلف شبکه و تنظیمات IP، می‌توانید یک محیط شبکه‌ای انعطاف‌پذیر و ایمن برای کانتینرهای خود ایجاد کنید.

• درایورهای شبکه: شما می‌توانید از درایورهای مختلف مانند bridge، overlay، host و macvlan استفاده کنید تا شبکه‌ای متناسب با نیاز خود بسازید.
• تنظیمات IP و Subnet: شما می‌توانید تنظیمات IP و محدوده‌های Subnet را به‌طور دقیق پیکربندی کنید.
• DNS سفارشی: برای استفاده از DNS خاص، می‌توانید شبکه‌های سفارشی را با DNSهای مورد نظر خود پیکربندی کنید.
• اتصال کانتینرها: کانتینرها می‌توانند به‌راحتی به شبکه‌های سفارشی متصل شوند و به منابع شبکه‌ای دسترسی داشته باشند.

این تنظیمات به شما کمک می‌کنند تا شبکه‌های Docker خود را به‌طور مؤثر مدیریت کرده و نیازهای خاص پروژه‌های خود را برآورده کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. پیکربندی تنظیمات Docker برای محیط تولید (Production Configuration)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از سیستم‌های مانیتورینگ Docker مانند Prometheus و Grafana” subtitle=”توضیحات کامل”]مانیتورینگ و نظارت بر وضعیت سیستم‌های Docker یکی از مهم‌ترین جنبه‌ها برای اطمینان از عملکرد بهینه و ایمن کانتینرها است. در این بخش، به بررسی ابزارهای قدرتمند Prometheus و Grafana می‌پردازیم که برای جمع‌آوری و نمایش داده‌های آماری از سیستم‌های Docker به‌کار می‌روند.

Prometheus و Grafana دو ابزار رایج و قدرتمند در زمینه مانیتورینگ و داشبوردهای تصویری برای نظارت بر سیستم‌ها و زیرساخت‌ها هستند. Prometheus داده‌های مربوط به متریک‌ها را جمع‌آوری می‌کند و Grafana آن‌ها را به‌صورت بصری نمایش می‌دهد.

---

1. معرفی Prometheus

Prometheus یک سیستم مانیتورینگ و جمع‌آوری متریک‌های متن‌باز است که برای نظارت بر عملکرد سیستم‌های توزیع‌شده طراحی شده است. این سیستم می‌تواند به‌صورت خودکار داده‌های متریک را از منابع مختلف از جمله Docker جمع‌آوری کند و آن‌ها را در قالب یک پایگاه‌داده زمانی (time-series database) ذخیره نماید.

یکی از مزایای بزرگ Prometheus این است که می‌تواند به‌صورت خودکار از طریق Prometheus Exporters به جمع‌آوری متریک‌ها از سیستم‌های مختلف مانند Docker، سرورهای لینوکس، دیتابیس‌ها، و غیره بپردازد.

---

2. نصب و پیکربندی Prometheus

برای شروع با Prometheus، ابتدا باید آن را نصب و تنظیم کنید تا بتواند داده‌های متریک از Docker جمع‌آوری کند. در اینجا روند نصب و پیکربندی Prometheus برای Docker آورده شده است.

الف. نصب Prometheus با Docker

در ابتدا، برای راه‌اندازی Prometheus، می‌توانیم از یک Docker container برای اجرا استفاده کنیم. این روش ساده‌ترین و سریع‌ترین روش برای نصب و راه‌اندازی است.

برای شروع، می‌توانید از تصویر رسمی Prometheus در Docker Hub استفاده کنید:

docker run -d --name prometheus \
  -p 9090:9090 \
  -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus

در این دستور:

• -d به معنای اجرای کانتینر در پس‌زمینه است.
• -p 9090:9090 پورت 9090 را برای دسترسی به رابط وب Prometheus منتشر می‌کند.
• -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml فایل پیکربندی Prometheus را به کانتینر متصل می‌کند.

ب. پیکربندی Prometheus برای نظارت بر Docker

برای نظارت بر Docker، شما نیاز دارید که Docker Exporter را برای جمع‌آوری داده‌ها از کانتینرهای Docker نصب و پیکربندی کنید.

ابتدا Docker Exporter را نصب کرده و سپس به فایل پیکربندی Prometheus خود اضافه کنید:

scrape_configs:
  - job_name: 'docker'
    static_configs:
      - targets: ['localhost:9323']

در اینجا، localhost:9323 پورت پیش‌فرض Docker Exporter است.

---

3. معرفی Grafana

Grafana یک پلتفرم متن‌باز است که برای تحلیل و نمایش بصری داده‌ها استفاده می‌شود. Grafana به‌طور گسترده‌ای برای ایجاد داشبوردهای گرافیکی برای مانیتورینگ استفاده می‌شود و می‌تواند داده‌ها را از منابع مختلفی مانند Prometheus، Elasticsearch، و دیگر پایگاه‌داده‌ها دریافت کرده و نمایش دهد.

در ترکیب با Prometheus، Grafana به شما این امکان را می‌دهد که داده‌های جمع‌آوری‌شده را به‌صورت گرافیکی و قابل‌فهم مشاهده کنید.

---

4. نصب و پیکربندی Grafana

برای راه‌اندازی Grafana، می‌توانید از Docker استفاده کنید:

docker run -d --name=grafana \
  -p 3000:3000 \
  -e "GF_SECURITY_ADMIN_PASSWORD=admin" \
  grafana/grafana

در این دستور:

• -d برای اجرای Grafana در پس‌زمینه.
• -p 3000:3000 پورت 3000 برای دسترسی به رابط وب Grafana.
• GF_SECURITY_ADMIN_PASSWORD=admin تنظیم پسورد پیش‌فرض برای حساب کاربری ادمین در Grafana.

پس از راه‌اندازی، شما می‌توانید از طریق مرورگر به http://localhost:3000 دسترسی پیدا کنید.

---

5. اتصال Prometheus به Grafana

برای نمایش داده‌های Prometheus در Grafana، ابتدا باید Prometheus را به‌عنوان یک منبع داده در Grafana اضافه کنید.

الف. اضافه کردن Prometheus به Grafana

1. وارد رابط وب Grafana شوید (در اینجا http://localhost:3000).
2. وارد بخش Data Sources شوید.
3. بر روی Add data source کلیک کنید و Prometheus را از فهرست انتخاب کنید.
4. URL Prometheus را وارد کنید (برای مثال، http://localhost:9090).
5. بر روی Save & Test کلیک کنید تا اتصال بررسی و ذخیره شود.

---

6. ساخت داشبوردهای گرافیکی با Grafana

پس از اتصال Prometheus به Grafana، می‌توانید از داشبوردهای از پیش ساخته‌شده یا داشبوردهای سفارشی برای نظارت بر داده‌های Docker استفاده کنید.

برای نمایش متریک‌ها، می‌توانید از Grafana Dashboards استفاده کنید. Grafana داشبوردهای متعددی دارد که از قبل برای Docker و Prometheus طراحی شده است.

برای مثال، می‌توانید از داشبوردهای آماده برای Docker استفاده کنید. برای وارد کردن داشبوردها در Grafana:

1. وارد بخش Create در Grafana شوید.
2. گزینه Import را انتخاب کنید.
3. شناسه داشبورد آماده برای Docker را وارد کنید، که به‌عنوان مثال برای Docker می‌تواند 179 باشد.
4. بر روی Load کلیک کنید تا داشبورد بارگذاری شود.

این داشبورد به‌صورت گرافیکی وضعیت کانتینرها، مصرف منابع، متریک‌های Docker و سایر داده‌ها را نشان می‌دهد.

---

جمع‌بندی

• Prometheus ابزار قدرتمندی برای جمع‌آوری و ذخیره متریک‌ها است که می‌تواند داده‌ها را از کانتینرهای Docker به‌طور خودکار جمع‌آوری کرده و در یک پایگاه‌داده زمانی ذخیره کند.
• Grafana یک پلتفرم تحلیلی است که داده‌ها را از Prometheus دریافت کرده و به‌صورت داشبوردهای گرافیکی و بصری نمایش می‌دهد.
• با استفاده از ترکیب Prometheus و Grafana، می‌توانید به‌طور مؤثر وضعیت سیستم‌های Docker خود را مانیتور کرده و از آن‌ها گزارش‌های دقیقی تهیه کنید.
• نصب، پیکربندی، و استفاده از این دو ابزار به شما این امکان را می‌دهد که کانتینرها، منابع و عملکرد سیستم‌های Docker خود را به دقت نظارت کنید.

استفاده از این ابزارها برای مانیتورینگ می‌تواند به بهبود کارایی و امنیت کلاسترها و کانتینرهای Docker کمک شایانی کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بهینه‌سازی تنظیمات برای عملکرد بالا در محیط تولید” subtitle=”توضیحات کامل”]در محیط‌های تولیدی، عملکرد و کارایی بالای Docker اهمیت زیادی دارد. بهینه‌سازی تنظیمات Docker می‌تواند تأثیر مستقیمی بر عملکرد، مقیاس‌پذیری، و پایداری سیستم‌ها داشته باشد. در این بخش، به بررسی روش‌ها و تنظیمات مختلفی می‌پردازیم که می‌توانند به بهبود عملکرد در محیط‌های تولید کمک کنند.

---

1. پیکربندی منابع سیستم (CPU و حافظه)

یکی از مهم‌ترین عوامل تأثیرگذار بر عملکرد Docker، تخصیص منابع مانند CPU و حافظه به کانتینرها است. به‌ویژه در محیط‌های تولیدی، ممکن است تعداد زیادی کانتینر در حال اجرا باشند که نیاز به منابع مختلف دارند. مدیریت و بهینه‌سازی استفاده از منابع به‌طور مؤثر، می‌تواند عملکرد کلی سیستم را بهبود بخشد.

الف. تخصیص محدودیت‌های حافظه و CPU برای کانتینرها:

شما می‌توانید با استفاده از گزینه‌های --memory و --cpus در زمان اجرای کانتینرها، منابع مختلف را به آن‌ها اختصاص دهید. این تنظیمات برای جلوگیری از مصرف بیش از حد منابع توسط یک کانتینر و ایجاد مشکل در سایر کانتینرها مفید است.

برای مثال:

docker run -d --name mycontainer --memory="2g" --cpus="1.5" myimage

این دستور حداکثر ۲ گیگابایت حافظه و ۱.۵ واحد CPU را برای کانتینر اختصاص می‌دهد.

ب. استفاده از cgroups:

Docker از cgroups (control groups) برای مدیریت منابع استفاده می‌کند. اطمینان حاصل کنید که تنظیمات cgroup به‌درستی پیکربندی شده‌اند تا منابع به‌طور کارآمد تخصیص یابند.

---

2. استفاده از شبکه‌های مخصوص به هر سرویس (Custom Networks)

شبکه‌های Docker می‌توانند تأثیر زیادی بر عملکرد داشته باشند، به‌ویژه در محیط‌های تولیدی که تعداد زیادی کانتینر به‌طور همزمان اجرا می‌شوند. استفاده از شبکه‌های سفارشی (custom networks) می‌تواند به بهبود ارتباط بین کانتینرها و افزایش عملکرد کمک کند.

الف. استفاده از شبکه‌های Overlay برای مقیاس‌پذیری بیشتر:

شبکه‌های Overlay به شما این امکان را می‌دهند که کانتینرها را در چندین میزبان Docker به‌صورت مجازی به هم متصل کنید. این نوع شبکه‌ها برای محیط‌های کلاستری مانند Docker Swarm یا Kubernetes بسیار مناسب هستند.

docker network create -d overlay my_overlay_network

ب. استفاده از شبکه‌های Bridge برای کاهش پیچیدگی شبکه:

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

---

3. بهینه‌سازی حجم‌ها (Volumes) و ذخیره‌سازی داده‌ها

عملکرد ذخیره‌سازی داده‌ها یکی دیگر از جنبه‌های حیاتی برای بهینه‌سازی در محیط تولید است. Volumes در Docker به‌طور خاص برای ذخیره‌سازی داده‌ها و دسترسی سریع‌تر به آن‌ها طراحی شده‌اند.

الف. استفاده از volumes به جای bind mounts:

برای ذخیره‌سازی داده‌ها در Docker، همیشه از Volumes به جای bind mounts استفاده کنید. Volumes به‌طور بهینه‌تری در سیستم فایل مدیریت می‌شوند و می‌توانند از کش‌های سیستمی بهره‌مند شوند.

docker volume create my_volume
docker run -d -v my_volume:/data my_image

ب. استفاده از ذخیره‌سازی خارجی برای داده‌های پایدار:

برای استفاده از داده‌های پایدار که باید در بین کانتینرها یا حتی میان نودهای مختلف Docker حفظ شوند، استفاده از ذخیره‌سازی خارجی مانند NFS یا Ceph پیشنهاد می‌شود.

---

4. تنظیمات Docker Swarm برای مقیاس‌پذیری

در محیط‌های تولیدی که از Docker Swarm برای مدیریت کانتینرها و سرویس‌ها استفاده می‌کنید، باید تنظیمات خاصی را برای مقیاس‌پذیری بهینه اعمال کنید.

الف. افزایش تعداد نودهای Manager:

در یک کلاستر Swarm، تعداد نودهای Manager تأثیر زیادی بر روی پایداری و مقیاس‌پذیری دارد. معمولاً پیشنهاد می‌شود تعداد نودهای Manager را در حالت سه‌تایی یا پنج‌تایی قرار دهید تا عملکرد و پایداری بهتری داشته باشید.

docker swarm init --advertise-addr <MANAGER-IP>

ب. تنظیم تعداد Replicaهای سرویس‌ها:

برای افزایش دسترس‌پذیری و مقیاس‌پذیری سرویس‌ها، می‌توانید تعداد Replicaهای هر سرویس را افزایش دهید. این کار باعث می‌شود که در صورت بروز مشکلات، سرویس‌ها همچنان در دسترس باشند.

docker service update --replicas 5 my_service

---

5. مراقبت از کش و لایه‌ها

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

الف. کاهش لایه‌ها در Dockerfile:

هر دستور در Dockerfile یک لایه جدید ایجاد می‌کند. با استفاده از دستورات ترکیبی مانند && و \ می‌توانید تعداد لایه‌ها را کاهش دهید. این باعث می‌شود که زمان ساخت و اندازه نهایی ایمیج‌ها کاهش یابد.

ب. بهینه‌سازی کش:

Docker از کش برای سرعت بخشیدن به فرآیند ساخت ایمیج‌ها استفاده می‌کند. با توجه به ترتیب دستورات در Dockerfile، می‌توانید کش را بهینه کرده و از استفاده مجدد آن بهره‌مند شوید.

---

6. استفاده از تنظیمات بهینه امنیتی

یکی از جنبه‌های مهم در محیط‌های تولیدی، امنیت است. Docker به‌طور پیش‌فرض دارای تنظیمات امنیتی معقولی است، اما می‌توان با اعمال تنظیمات خاص، امنیت را در سطح بالاتری حفظ کرد.

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

با استفاده از Docker security options می‌توان دسترسی به منابع سیستم را محدود کرد. به‌عنوان‌مثال، با استفاده از --cap-drop و --cap-add می‌توانید دسترسی کانتینرها به قابلیت‌های خاص سیستم را تنظیم کنید.

ب. استفاده از SELinux و AppArmor:

برای محافظت از کانتینرها در برابر دسترسی‌های غیرمجاز، می‌توانید از ابزارهای امنیتی مانند SELinux و AppArmor استفاده کنید. این ابزارها به شما این امکان را می‌دهند که سیاست‌های امنیتی خاصی را برای کانتینرها تنظیم کنید.

---

7. نظارت و مانیتورینگ برای عملکرد

استفاده از ابزارهای مانیتورینگ برای نظارت بر منابع سیستم و رفتار کانتینرها در زمان واقعی به شما این امکان را می‌دهد که عملکرد سیستم را در محیط تولید بررسی کرده و مشکلات احتمالی را پیش از وقوع شناسایی کنید.

الف. استفاده از Prometheus و Grafana:

ابزارهایی مانند Prometheus برای جمع‌آوری متریک‌ها و Grafana برای نمایش بصری آن‌ها به‌طور گسترده‌ای در نظارت بر عملکرد Docker استفاده می‌شوند.

ب. نظارت بر لاگ‌ها:

بررسی لاگ‌ها می‌تواند به شما در تشخیص سریع مشکلات کمک کند. از ابزارهایی مانند ELK Stack یا Fluentd برای جمع‌آوری و تجزیه‌وتحلیل لاگ‌ها استفاده کنید.

---

جمع‌بندی

بهینه‌سازی Docker در محیط تولید نیازمند تنظیمات دقیق و تخصصی است. تخصیص منابع، استفاده از شبکه‌های مناسب، مدیریت حجم‌ها، بهینه‌سازی کش و لایه‌ها، افزایش مقیاس‌پذیری از طریق Docker Swarm و اعمال تنظیمات امنیتی می‌تواند تأثیر زیادی بر عملکرد کلی سیستم‌ها داشته باشد. همچنین، استفاده از ابزارهای مانیتورینگ و نظارت مانند Prometheus و Grafana به شما این امکان را می‌دهد که وضعیت سیستم را در زمان واقعی بررسی کرده و از بروز مشکلات پیشگیری کنید. این موارد باعث بهبود کارایی، پایداری و امنیت در محیط‌های تولیدی Docker خواهند شد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از امنیت پیشرفته در تنظیمات Docker” subtitle=”توضیحات کامل”]در محیط‌های تولیدی، امنیت یکی از مهم‌ترین اولویت‌ها برای اطمینان از پایداری و حفاظت از سیستم‌ها است. Docker به‌عنوان یک فناوری مجازی‌سازی برای کانتینرها، به کاربران این امکان را می‌دهد که برنامه‌ها و سرویس‌های خود را به‌صورت ایزوله اجرا کنند. با این حال، این ایزوله‌سازی نیاز به تنظیمات امنیتی دقیق برای جلوگیری از دسترسی‌های غیرمجاز، حفاظت از داده‌ها و سیستم‌ها، و جلوگیری از حملات مختلف دارد.

در این بخش، به بررسی تنظیمات امنیتی پیشرفته‌ای خواهیم پرداخت که می‌توانند به تقویت امنیت محیط‌های Docker کمک کنند.

---

1. محدود کردن دسترسی‌ها و اجازه‌های سیستم با استفاده از Capabilities

Capabilities در Linux به شما امکان می‌دهند تا کنترل دقیقی بر روی سطح دسترسی‌ها در سطح سیستم‌عامل داشته باشید. Docker این قابلیت‌ها را به‌طور پیش‌فرض به کانتینرها اعطا می‌کند، اما شما می‌توانید این قابلیت‌ها را برای محدود کردن دسترسی‌ها به منابع سیستم، کاهش دهید.

الف. دستورات محدودکننده قابلیت‌ها:

با استفاده از گزینه --cap-drop می‌توانید قابلیت‌های اضافی را از کانتینر حذف کنید و با گزینه --cap-add می‌توانید فقط قابلیت‌های خاصی را اضافه کنید.

برای مثال، می‌توانید قابلیت SYS_ADMIN که معمولاً برای دسترسی به سطح مدیریتی سیستم‌عامل نیاز است، از کانتینر حذف کنید:

docker run --cap-drop=SYS_ADMIN mycontainer

این دستور باعث می‌شود کانتینر بدون قابلیت‌های مدیریتی سیستم اجرا شود.

ب. استفاده از seccomp:

Seccomp (Secure Computing Mode) به شما این امکان را می‌دهد که دستورات سیستم‌عامل را که کانتینرها می‌توانند از آن‌ها استفاده کنند محدود کنید. استفاده از پروفایل‌های seccomp به‌طور پیش‌فرض می‌تواند سطح امنیت کانتینرها را بهبود بخشد. Docker به‌طور پیش‌فرض از یک پروفایل seccomp محدود استفاده می‌کند، اما شما می‌توانید پروفایل‌های سفارشی ایجاد کرده و به کانتینرها اعمال کنید.

برای اجرای یک کانتینر با پروفایل seccomp محدود، می‌توانید از دستور زیر استفاده کنید:

docker run --security-opt seccomp=seccomp-profile.json mycontainer

---

2. استفاده از AppArmor و SELinux برای کنترل دسترسی‌ها

AppArmor و SELinux دو ابزار امنیتی مهم در لینوکس هستند که به‌طور پیش‌فرض در بسیاری از توزیع‌ها فعال شده‌اند. این ابزارها برای تعریف سیاست‌های امنیتی برای منابع سیستم (مانند فایل‌ها، پروسس‌ها، و شبکه‌ها) استفاده می‌شوند و به شما امکان می‌دهند که محدودیت‌های دقیقی برای دسترسی کانتینرها به منابع سیستم ایجاد کنید.

الف. AppArmor:

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

برای فعال‌سازی AppArmor برای یک کانتینر، می‌توانید از دستور زیر استفاده کنید:

docker run --security-opt apparmor=my-apparmor-profile mycontainer

ب. SELinux:

SELinux (Security-Enhanced Linux) یک سیستم امنیتی مبتنی بر برچسب‌ها است که از کنترل دسترسی مبتنی بر سیاست برای محدود کردن دسترسی کانتینرها به منابع مختلف استفاده می‌کند. شما می‌توانید سیاست‌های امنیتی SELinux را برای هر کانتینر به‌طور جداگانه تنظیم کنید.

برای فعال‌سازی SELinux برای یک کانتینر، از دستور زیر استفاده کنید:

docker run --security-opt label:type:mylabel_t mycontainer

این دستور به‌طور پیش‌فرض استفاده از پروفایل SELinux برای کانتینر را فعال می‌کند.

---

3. استفاده از Docker Content Trust (DCT) برای امضای ایمیج‌ها

Docker Content Trust (DCT) ابزاری است که به شما این امکان را می‌دهد تا ایمیج‌های Docker را امضا کنید و صحت آن‌ها را تضمین کنید. این ویژگی برای جلوگیری از اجرای ایمیج‌های تغییر یافته یا غیرقابل اعتماد بسیار مفید است. با فعال کردن DCT، Docker تنها اجازه می‌دهد که ایمیج‌های امضا شده اجرا شوند.

برای فعال‌سازی Docker Content Trust، می‌توانید متغیر محیطی DOCKER_CONTENT_TRUST را به 1 تنظیم کنید:

export DOCKER_CONTENT_TRUST=1

این کار باعث می‌شود که هنگام استفاده از دستور docker pull یا docker push، فقط ایمیج‌های معتبر امضا شده دانلود یا ارسال شوند.

---

4. تنظیم محدودیت‌های شبکه برای جلوگیری از حملات

الف. استفاده از شبکه‌های ایزوله و سفارشی:

با استفاده از شبکه‌های سفارشی، می‌توانید دسترسی کانتینرها به منابع شبکه را به‌طور دقیق کنترل کنید. Docker به‌طور پیش‌فرض از شبکه‌های Bridge و Host برای ارتباط بین کانتینرها استفاده می‌کند، اما شما می‌توانید شبکه‌های سفارشی برای هر سرویس ایجاد کنید که موجب می‌شود کانتینرها تنها با کانتینرهایی که باید ارتباط داشته باشند، ارتباط برقرار کنند.

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

docker network create --driver=bridge my_network

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

docker run --network my_network mycontainer

ب. استفاده از فایروال و قوانین iptables:

برای مدیریت ترافیک شبکه و جلوگیری از دسترسی غیرمجاز به کانتینرها، می‌توانید از قوانین فایروال استفاده کنید. iptables ابزاری است که می‌توانید از آن برای کنترل ترافیک شبکه، جلوگیری از حملات DDoS، و محدود کردن دسترسی به سرویس‌ها استفاده کنید.

---

5. ایمن‌سازی Docker Daemon

Docker Daemon مسئول مدیریت کانتینرها و ارتباط با سیستم‌عامل است. ایمن‌سازی Docker Daemon از اهمیت بالایی برخوردار است، زیرا در صورت نقص امنیتی در آن، حملات می‌توانند به سطح سیستم‌عامل نفوذ کنند.

الف. پیکربندی Docker Daemon برای استفاده از HTTPS:

برای افزایش امنیت، توصیه می‌شود که Docker Daemon تنها از طریق اتصال امن (HTTPS) قابل دسترسی باشد. برای این کار باید یک گواهی SSL/TLS ایجاد کرده و آن را به Docker Daemon متصل کنید.

برای پیکربندی HTTPS، می‌توانید فایل تنظیمات Docker Daemon (/etc/docker/daemon.json) را به‌صورت زیر ویرایش کنید:

{
  "hosts": ["tcp://0.0.0.0:2376", "unix:///var/run/docker.sock"],
  "tls": true,
  "tlscert": "/etc/docker/cert.pem",
  "tlskey": "/etc/docker/key.pem",
  "tlsverify": true
}

ب. محدود کردن دسترسی به Docker Daemon با استفاده از UNIX socket:

برای جلوگیری از دسترسی‌های غیرمجاز، می‌توانید Docker Daemon را تنها از طریق UNIX socket (که به‌طور پیش‌فرض در /var/run/docker.sock قرار دارد) دسترسی دهید. این کار به‌ویژه زمانی که در یک محیط محلی یا توسعه‌ای کار می‌کنید مفید است.

---

6. اسکن آسیب‌پذیری‌ها برای ایمیج‌ها

برای شناسایی آسیب‌پذیری‌های امنیتی در ایمیج‌های Docker، می‌توانید از ابزارهای اسکنر مانند Docker Scan یا ابزارهای شخص ثالث استفاده کنید. این ابزارها به‌طور خودکار ایمیج‌ها را برای آسیب‌پذیری‌های امنیتی و مشکلات موجود بررسی می‌کنند.

برای استفاده از Docker Scan، دستور زیر را اجرا کنید:

docker scan myimage

این ابزار آسیب‌پذیری‌های موجود در ایمیج را شناسایی کرده و گزارشی از آن‌ها ارائه می‌دهد.

---

جمع‌بندی

استفاده از امنیت پیشرفته در تنظیمات Docker برای حفاظت از سیستم‌ها و داده‌ها در برابر تهدیدات مختلف از اهمیت بالایی برخوردار است. با اعمال محدودیت‌های دقیق بر قابلیت‌ها، استفاده از ابزارهای امنیتی مانند AppArmor و SELinux، و اطمینان از اعتبار ایمیج‌ها از طریق Docker Content Trust می‌توان امنیت سیستم‌ها را افزایش داد. همچنین، تنظیمات دقیق شبکه، ایمن‌سازی Docker Daemon و اسکن آسیب‌پذیری‌ها از دیگر اقداماتی هستند که به شما در تقویت امنیت محیط‌های Docker کمک خواهند کرد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 8. مدیریت پلاگین‌ها (Plugins Management)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نصب و مدیریت پلاگین‌های Docker” subtitle=”توضیحات کامل”]در Docker، پلاگین‌ها ابزارهایی هستند که به شما این امکان را می‌دهند تا قابلیت‌های اضافی به Docker اضافه کنید. این پلاگین‌ها می‌توانند عملکردهای مختلفی مانند مدیریت شبکه، ذخیره‌سازی، و یا حتی ویژگی‌های امنیتی جدید را ارائه دهند. در این بخش، به نصب و مدیریت پلاگین‌ها در Docker خواهیم پرداخت و نحوه استفاده از آن‌ها را توضیح خواهیم داد.

---

1. پلاگین‌ها در Docker چیستند؟

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

• پلاگین‌های ذخیره‌سازی (Storage Plugins): این پلاگین‌ها به شما اجازه می‌دهند که از سیستم‌های ذخیره‌سازی خارجی برای نگهداری داده‌ها استفاده کنید.
• پلاگین‌های شبکه (Network Plugins): این پلاگین‌ها به شما این امکان را می‌دهند که شبکه‌های پیچیده‌تر و امن‌تری برای کانتینرها ایجاد کنید.
• پلاگین‌های مدیریت امنیت (Security Plugins): این پلاگین‌ها به‌طور خاص برای مدیریت امنیت و محدود کردن دسترسی‌ها طراحی شده‌اند.

پلاگین‌ها در Docker به‌طور معمول از استانداردهای Open Container Initiative (OCI) پیروی می‌کنند.

---

2. نصب پلاگین‌های Docker

نصب پلاگین‌های Docker فرآیند نسبتاً ساده‌ای دارد. شما می‌توانید پلاگین‌ها را از Docker Hub یا از منابع شخص ثالث نصب کنید.

الف. نصب پلاگین از Docker Hub:

Docker Hub یک مخزن عمومی است که می‌توانید پلاگین‌های مختلف را از آنجا دانلود کنید. برای نصب یک پلاگین از Docker Hub، کافیست از دستور زیر استفاده کنید:

docker plugin install <plugin-name>

به‌عنوان مثال، برای نصب یک پلاگین ذخیره‌سازی از Docker Hub، دستور زیر را اجرا کنید:

docker plugin install vieux/sshfs

این دستور پلاگین sshfs را که به شما اجازه می‌دهد تا از SSH برای متصل کردن سیستم‌های فایل استفاده کنید، نصب می‌کند.

ب. نصب پلاگین از فایل‌های محلی:

اگر پلاگین را از یک منبع شخص ثالث دانلود کرده‌اید یا به‌صورت محلی دارید، می‌توانید آن را به‌طور دستی نصب کنید. برای نصب پلاگین از فایل‌های محلی، باید از دستور زیر استفاده کنید:

docker plugin install /path/to/plugin.tgz

این دستور پلاگین مورد نظر شما را از فایل محلی نصب می‌کند.

---

3. پیکربندی پلاگین‌ها

پس از نصب پلاگین، ممکن است نیاز به پیکربندی آن بسته به نوع پلاگین داشته باشید. بسیاری از پلاگین‌ها نیاز دارند که برخی تنظیمات خاص (مانند مسیرها یا کلیدهای امنیتی) برای عمل‌کرد صحیح در Docker تنظیم شوند. این تنظیمات معمولاً در فایل پیکربندی پلاگین قرار دارند یا می‌توانند از طریق متغیرهای محیطی یا پارامترهای خاص هنگام نصب یا راه‌اندازی کانتینر تنظیم شوند.

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

بعضی از پلاگین‌ها دارای پارامترهای پیکربندی هستند که می‌توانند در هنگام نصب یا راه‌اندازی به‌طور مستقیم وارد شوند. به‌طور مثال:

docker plugin install vieux/sshfs:latest \
  --alias my-sshfs \
  --grant-all-permissions \
  --disable

در این مثال:

• --alias my-sshfs نام مستعاری برای پلاگین ایجاد می‌کند.
• --grant-all-permissions به پلاگین اجازه دسترسی کامل به Docker Daemon می‌دهد.
• --disable باعث غیرفعال شدن پلاگین پس از نصب می‌شود.

ب. پیکربندی پلاگین با فایل پیکربندی:

برخی پلاگین‌ها نیاز به فایل پیکربندی دارند که در آن تنظیمات خاص وارد می‌شود. به‌طور معمول، این فایل‌ها باید در پوشه‌ای مخصوص داخل دایرکتوری Docker قرار گیرند. پس از نصب پلاگین، مسیر فایل پیکربندی معمولاً در مستندات پلاگین ذکر می‌شود.

---

4. مدیریت پلاگین‌های Docker

مدیریت پلاگین‌های نصب‌شده در Docker به شما این امکان را می‌دهد که پلاگین‌ها را به‌راحتی غیرفعال کنید، حذف کنید، یا بروزرسانی کنید.

الف. مشاهده پلاگین‌های نصب‌شده:

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

docker plugin ls

این دستور لیستی از پلاگین‌های نصب‌شده و وضعیت فعال بودن آن‌ها را نشان می‌دهد. اگر پلاگین‌ها فعال نباشند، وضعیت disabled را مشاهده خواهید کرد.

ب. فعال یا غیرفعال کردن پلاگین‌ها:

برای فعال یا غیرفعال کردن یک پلاگین، می‌توانید از دستور زیر استفاده کنید:

docker plugin enable <plugin-name>
docker plugin disable <plugin-name>

برای مثال، برای فعال‌سازی یک پلاگین خاص:

docker plugin enable vieux/sshfs

ج. حذف پلاگین‌ها:

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

docker plugin rm <plugin-name>

این دستور پلاگین انتخابی را از Docker حذف خواهد کرد.

---

5. به‌روزرسانی پلاگین‌ها

با توجه به اینکه پلاگین‌ها ممکن است به‌روزرسانی‌هایی دریافت کنند، مدیریت نسخه‌ها نیز از اهمیت بالایی برخوردار است. برای به‌روزرسانی پلاگین‌ها، می‌توانید از دستور زیر استفاده کنید:

docker plugin update <plugin-name>

این دستور پلاگین را به نسخه جدیدتر موجود در Docker Hub به‌روزرسانی می‌کند.

---

6. بهترین شیوه‌ها برای استفاده از پلاگین‌های Docker

• استفاده از پلاگین‌های رسمی: همیشه سعی کنید از پلاگین‌های رسمی و تاییدشده توسط Docker یا توسعه‌دهندگان معتبر استفاده کنید.
• بررسی مستندات پلاگین‌ها: قبل از نصب هر پلاگینی، مستندات آن را به دقت مطالعه کنید تا از قابلیت‌ها و نیازمندی‌های آن آگاه شوید.
• به‌روزرسانی مرتب: پلاگین‌ها ممکن است به‌روزرسانی‌های امنیتی و بهبود عملکرد دریافت کنند، بنابراین از به‌روزرسانی آن‌ها غافل نشوید.
• مدیریت مجوزها: برای حفظ امنیت، اطمینان حاصل کنید که پلاگین‌ها تنها دسترسی‌های ضروری را دارند و از اعطای دسترسی‌های اضافی خودداری کنید.
• پشتیبانی از پلاگین‌ها: در صورتی که از پلاگین‌های شخص ثالث استفاده می‌کنید، اطمینان حاصل کنید که پشتیبانی مناسبی از آن‌ها در صورت بروز مشکل وجود دارد.

---

جمع‌بندی

پلاگین‌ها ابزارهای قدرتمندی هستند که می‌توانند به شما این امکان را بدهند که قابلیت‌های اضافی به Docker اضافه کنید و آن را به نیازهای خاص خود تطبیق دهید. نصب و مدیریت پلاگین‌ها یک فرآیند ساده است، اما نیازمند دقت در پیکربندی و مدیریت پلاگین‌ها برای حفظ امنیت و عملکرد بهینه سیستم است. استفاده از پلاگین‌های Docker در پروژه‌ها می‌تواند به افزایش بهره‌وری، بهبود قابلیت‌های ذخیره‌سازی، شبکه، و حتی امنیت کمک کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از پلاگین‌های ذخیره‌سازی و شبکه در Docker” subtitle=”توضیحات کامل”]پلاگین‌های ذخیره‌سازی و شبکه در Docker به شما این امکان را می‌دهند که قابلیت‌های پیشرفته‌تری در زمینه ذخیره‌سازی داده‌ها و مدیریت شبکه کانتینرها را در محیط‌های مختلف پیاده‌سازی کنید. این پلاگین‌ها به‌ویژه در محیط‌های بزرگ و پیچیده که نیاز به انعطاف‌پذیری بیشتر دارند، اهمیت زیادی دارند. در این بخش، به بررسی پلاگین‌های ذخیره‌سازی و شبکه و نحوه استفاده از آن‌ها در Docker خواهیم پرداخت.

---

1. پلاگین‌های ذخیره‌سازی در Docker

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

الف. نصب پلاگین ذخیره‌سازی

برای نصب پلاگین‌های ذخیره‌سازی از Docker Hub، از دستور زیر استفاده کنید:

docker plugin install <plugin-name>

برای مثال، اگر بخواهید از پلاگین vieux/sshfs استفاده کنید که به شما اجازه می‌دهد داده‌ها را از طریق SSH به اشتراک بگذارید، می‌توانید دستور زیر را اجرا کنید:

docker plugin install vieux/sshfs

این دستور پلاگین SSHFS را نصب می‌کند که امکان متصل کردن و مدیریت سیستم‌های فایل از طریق پروتکل SSH را فراهم می‌کند.

ب. پیکربندی پلاگین ذخیره‌سازی

بسیاری از پلاگین‌های ذخیره‌سازی برای عملکرد بهتر به پیکربندی نیاز دارند. به‌عنوان‌مثال، پلاگین vieux/sshfs نیاز دارد که شما دسترسی به سرور مقصد را با استفاده از کلید SSH فراهم کنید. در این حالت، هنگام نصب پلاگین یا راه‌اندازی آن، باید تنظیمات متغیرهای محیطی را مطابق نیاز خود پیکربندی کنید.

ج. انواع پلاگین‌های ذخیره‌سازی محبوب

• NFS (Network File System): پلاگین‌های NFS امکان اشتراک‌گذاری سیستم‌های فایل از راه دور را در شبکه فراهم می‌کنند.
• Ceph: پلاگین‌های Ceph به شما اجازه می‌دهند از سیستم‌های ذخیره‌سازی توزیع‌شده و مقیاس‌پذیر استفاده کنید.
• Amazon EBS: پلاگین‌های AWS EBS به شما این امکان را می‌دهند که از سرویس ذخیره‌سازی ابری AWS برای ذخیره‌سازی داده‌ها در Docker استفاده کنید.

---

2. پلاگین‌های شبکه در Docker

پلاگین‌های شبکه در Docker به شما این امکان را می‌دهند که شبکه‌های پیچیده‌تری را برای ارتباط بین کانتینرها، درگاه‌ها و دیگر سرویس‌ها ایجاد کنید. این پلاگین‌ها می‌توانند شبکه‌های مجازی ایجاد کرده و به‌طور خودکار قوانین دسترسی و امنیت شبکه را مدیریت کنند. برای استفاده از این پلاگین‌ها، باید شبکه‌های مخصوصی را برای کانتینرها پیکربندی کرده و از ویژگی‌هایی مانند VLAN، VPN یا حتی تنظیمات پیچیده‌تر مانند امنیت و QoS استفاده کنید.

الف. نصب پلاگین‌های شبکه

برای نصب یک پلاگین شبکه از Docker Hub، می‌توانید از دستور زیر استفاده کنید:

docker plugin install <plugin-name>

مثال زیر نصب پلاگین weave را نشان می‌دهد که یک شبکه مقیاس‌پذیر و انعطاف‌پذیر برای Docker فراهم می‌کند:

docker plugin install weaveworks/net-plugin:latest

پلاگین weave به شما این امکان را می‌دهد که شبکه‌های Docker را به‌صورت پویا ایجاد و مدیریت کنید و همچنین از ویژگی‌های امنیتی مانند encryption استفاده کنید.

ب. پیکربندی پلاگین شبکه

پلاگین‌های شبکه معمولاً برای اتصال به شبکه‌های خارجی یا مدیریت شبکه‌های مقیاس‌پذیر به پیکربندی خاصی نیاز دارند. به‌عنوان مثال، شما باید اطلاعات مربوط به زیرساخت شبکه، دامنه‌های IP، و پروتکل‌های مورد استفاده را هنگام نصب یا راه‌اندازی پلاگین شبکه وارد کنید. در صورت استفاده از پلاگین‌های پیچیده‌تر، مانند calico برای مدیریت شبکه‌های ابری، ممکن است نیاز به تنظیمات بیشتر داشته باشید.

ج. انواع پلاگین‌های شبکه محبوب

• Weave: یک شبکه Docker مقیاس‌پذیر برای کانتینرها است که ویژگی‌های امنیتی و مقیاس‌پذیری بالا را ارائه می‌دهد.
• Calico: این پلاگین برای مدیریت شبکه‌های ابری و ایجاد شبکه‌های قابل مقیاس‌پذیر برای کانتینرها و سرویس‌ها استفاده می‌شود.
• Flannel: یک پلاگین شبکه ساده برای ایجاد شبکه‌های مقیاس‌پذیر برای کانتینرهای Docker در یک کلاستر است.
• Bridge Networks: شبکه‌های پیش‌فرض Docker که از L2 Ethernet برای اتصال کانتینرها در یک ماشین استفاده می‌کنند.

---

3. پیکربندی شبکه‌های سفارشی با پلاگین‌ها

Docker به شما این امکان را می‌دهد که شبکه‌های پیچیده‌تر و سفارشی‌تری برای کانتینرها بسازید که می‌تواند از ویژگی‌های شبکه‌های پیشرفته مانند VLANs یا VPNs استفاده کند. برای ایجاد شبکه سفارشی با استفاده از پلاگین شبکه، دستور زیر را می‌توانید استفاده کنید:

docker network create \
  --driver <plugin-name> \
  --subnet <subnet> \
  <network-name>

به‌عنوان مثال، برای ایجاد یک شبکه سفارشی با استفاده از پلاگین weave، دستور زیر را اجرا می‌کنید:

docker network create \
  --driver weaveworks/net-plugin:latest \
  --subnet 10.0.0.0/16 \
  my-custom-network

این دستور یک شبکه جدید به نام my-custom-network با استفاده از پلاگین weave و زیرشبکه‌ی 10.0.0.0/16 ایجاد می‌کند.

---

4. مدیریت امنیت با استفاده از پلاگین‌های ذخیره‌سازی و شبکه

یکی از ویژگی‌های کلیدی پلاگین‌های ذخیره‌سازی و شبکه، قابلیت افزایش امنیت است. به‌طور معمول، این پلاگین‌ها ویژگی‌های امنیتی مانند رمزگذاری داده‌ها در هنگام انتقال (TLS/SSL) و اعمال محدودیت‌های دسترسی برای اتصال‌های ورودی و خروجی را فراهم می‌کنند. برای مثال، با استفاده از پلاگین‌های شبکه مانند Calico، می‌توانید قوانین فایروال پیچیده‌تری برای کانتینرها تنظیم کنید تا ترافیک غیرمجاز از شبکه‌های خارجی جلوگیری شود.

---

5. بهترین شیوه‌ها برای استفاده از پلاگین‌های ذخیره‌سازی و شبکه

• پلاگین‌های سازگار با نیازهای پروژه: انتخاب پلاگین مناسب بستگی به نیاز پروژه شما دارد. برای پروژه‌های ابری، پلاگین‌های مبتنی بر AWS یا Google Cloud مناسب‌تر خواهند بود.
• نگهداری و پشتیبانی: برخی از پلاگین‌ها ممکن است به‌طور رسمی پشتیبانی نشوند، بنابراین مهم است که از پلاگین‌هایی استفاده کنید که جامعه پشتیبانی فعال و مستندات کافی دارند.
• ملاحظات مقیاس‌پذیری: در صورتی که پروژه شما به مقیاس بزرگ نیاز دارد، باید از پلاگین‌هایی استفاده کنید که قادر به مدیریت حجم بالای داده‌ها و ترافیک شبکه باشند.
• امنیت: همواره به امنیت شبکه‌ها و داده‌ها توجه کنید و از پلاگین‌هایی استفاده کنید که قابلیت رمزگذاری و مدیریت دسترسی پیشرفته را فراهم کنند.

---

جمع‌بندی

پلاگین‌های ذخیره‌سازی و شبکه در Docker ابزارهای قدرتمندی هستند که به شما این امکان را می‌دهند که Docker را به محیط‌های پیچیده‌تر و مقیاس‌پذیرتری گسترش دهید. با استفاده از این پلاگین‌ها می‌توانید قابلیت‌های شبکه‌ای پیشرفته مانند VPN، VLAN و رمزگذاری داده‌ها را به Docker اضافه کرده و از سیستم‌های ذخیره‌سازی پیچیده برای مدیریت داده‌های کانتینرها استفاده کنید. استفاده صحیح از پلاگین‌های ذخیره‌سازی و شبکه می‌تواند به‌طور چشمگیری کارایی و امنیت محیط Docker شما را بهبود بخشد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیم و پیکربندی پلاگین‌ها برای اهداف خاص” subtitle=”توضیحات کامل”]پلاگین‌ها در Docker ابزارهای قدرتمندی هستند که به شما امکان گسترش قابلیت‌های Docker را در زمینه‌های مختلف مانند ذخیره‌سازی، شبکه، و امنیت می‌دهند. برای دستیابی به اهداف خاص، می‌توانید پلاگین‌های مختلف را نصب و پیکربندی کنید. این پیکربندی‌ها می‌توانند شامل تنظیمات خاص برای هر پلاگین باشند که به شما کمک می‌کنند تا Docker را بر اساس نیازهای خاص خود شخصی‌سازی کنید. در این بخش، به نحوه تنظیم و پیکربندی پلاگین‌ها برای اهداف خاص خواهیم پرداخت.

---

1. تنظیم و پیکربندی پلاگین‌های ذخیره‌سازی برای اهداف خاص

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

الف. پیکربندی پلاگین NFS برای ذخیره‌سازی داده‌ها به اشتراک گذاشته‌شده

پلاگین‌های NFS (Network File System) به شما این امکان را می‌دهند که یک سیستم فایل مشترک میان کانتینرها یا میان کانتینر و ماشین میزبان ایجاد کنید. برای استفاده از پلاگین NFS، باید سرویس NFS را در ماشین‌های میزبان راه‌اندازی کرده و سپس از پلاگین NFS در Docker برای اتصال به آن استفاده کنید.

برای نصب پلاگین NFS، دستور زیر را اجرا کنید:

docker plugin install vieux/sshfs

پس از نصب پلاگین، می‌توانید آن را با دستور زیر پیکربندی کنید:

docker volume create \
  --driver vieux/sshfs \
  --opt share=host:/path/to/shared/directory \
  --opt IdentityFile=/path/to/ssh/key \
  shared_volume

در اینجا، share مسیر دایرکتوری مشترک روی سرور NFS است که داده‌ها از آنجا به اشتراک گذاشته می‌شود.

ب. استفاده از پلاگین Ceph برای ذخیره‌سازی مقیاس‌پذیر

Ceph یک سیستم ذخیره‌سازی توزیع‌شده است که برای مدیریت مقیاس‌پذیر داده‌ها استفاده می‌شود. برای استفاده از Ceph با Docker، ابتدا باید سرویس Ceph را راه‌اندازی کرده و پلاگین مربوطه را نصب کنید.

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

docker plugin install ceph/ceph-docker-plugin

پس از نصب، می‌توانید حجم‌های Docker را با استفاده از Ceph به‌صورت زیر ایجاد کنید:

docker volume create \
  --driver ceph/ceph-docker-plugin \
  --opt ceph.pool=rados \
  --opt ceph.cluster_name=ceph_cluster \
  ceph_volume

این پیکربندی امکان ایجاد حجم‌های ذخیره‌سازی مقیاس‌پذیر از سیستم Ceph را فراهم می‌آورد.

---

2. تنظیم و پیکربندی پلاگین‌های شبکه برای اهداف خاص

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

الف. استفاده از پلاگین Weave برای شبکه‌های مقیاس‌پذیر

پلاگین Weave به شما این امکان را می‌دهد که شبکه‌های مقیاس‌پذیر برای کانتینرها ایجاد کنید و در محیط‌های توزیع‌شده آن‌ها را مدیریت کنید. Weave از ویژگی‌های پیشرفته‌ای مانند رمزگذاری داده‌ها و شبکه‌بندی L2 پشتیبانی می‌کند.

برای نصب پلاگین Weave، از دستور زیر استفاده کنید:

docker plugin install weaveworks/net-plugin:latest

پس از نصب پلاگین، می‌توانید شبکه‌های مقیاس‌پذیر را با استفاده از Weave ایجاد کنید:

docker network create \
  --driver weaveworks/net-plugin:latest \
  --subnet 10.0.0.0/16 \
  weave_network

این دستور یک شبکه جدید به نام weave_network با زیرشبکه‌ی 10.0.0.0/16 ایجاد می‌کند که از پروتکل‌های امنیتی و مقیاس‌پذیر Weave استفاده می‌کند.

ب. استفاده از پلاگین Calico برای امنیت شبکه

پلاگین Calico به شما این امکان را می‌دهد که از ویژگی‌های امنیتی پیشرفته برای مدیریت شبکه‌های Docker استفاده کنید. به‌ویژه، Calico به شما این امکان را می‌دهد که قوانین فایروال پیچیده و سیاست‌های امنیتی را اعمال کنید.

برای نصب پلاگین Calico، از دستور زیر استفاده کنید:

docker plugin install calico/calico-plugin:latest

پس از نصب، می‌توانید شبکه‌ای با استفاده از Calico ایجاد کنید و قوانین فایروال برای مدیریت ترافیک ورودی و خروجی کانتینرها تعریف کنید:

docker network create \
  --driver calico/calico-plugin:latest \
  --subnet 192.168.1.0/24 \
  calico_network

این شبکه‌ی جدید از ویژگی‌های امنیتی پیشرفته Calico برای محافظت از شبکه‌های Docker شما بهره می‌برد.

---

3. پیکربندی پلاگین‌های شبکه و ذخیره‌سازی برای محیط‌های ابری

در محیط‌های ابری، شما معمولاً از پلاگین‌های ذخیره‌سازی و شبکه برای ایجاد اتصال پایدار و مقیاس‌پذیر بین کانتینرها و سرویس‌های مختلف استفاده می‌کنید. به‌ویژه در صورتی که از سرویس‌های ابری مانند AWS، Google Cloud یا Azure استفاده می‌کنید، پلاگین‌های ذخیره‌سازی و شبکه این سرویس‌ها می‌توانند به شما کمک کنند تا حجم‌های ذخیره‌سازی و شبکه‌های ابری را به‌طور یکپارچه با Docker استفاده کنید.

الف. استفاده از پلاگین Amazon EBS برای ذخیره‌سازی ابری

Amazon EBS (Elastic Block Store) یک سرویس ذخیره‌سازی مقیاس‌پذیر و قابل مدیریت است که برای ذخیره‌سازی داده‌های کانتینرها در Docker به‌ویژه در محیط‌های AWS استفاده می‌شود.

برای نصب پلاگین EBS از Docker Hub، دستور زیر را اجرا کنید:

docker plugin install rexray/ebs

پس از نصب، می‌توانید یک حجم EBS را برای استفاده در کانتینرها به‌طور زیر پیکربندی کنید:

docker volume create \
  --driver rexray/ebs \
  --opt volumeID=vol-12345678 \
  ebs_volume

این پلاگین از داده‌های ذخیره‌شده در Amazon EBS برای کانتینرها استفاده می‌کند.

ب. استفاده از پلاگین Google Cloud برای شبکه‌های ابری

پلاگین‌های Google Cloud می‌توانند به شما این امکان را بدهند که شبکه‌های Docker را در محیط Google Cloud ایجاد و مدیریت کنید. شما می‌توانید از پلاگین‌های شبکه مانند google-cloud برای اتصال به شبکه‌های GCP استفاده کنید.

برای نصب پلاگین Google Cloud، از دستور زیر استفاده کنید:

docker plugin install google-cloud/google-cloud-plugin:latest

پس از نصب، می‌توانید شبکه‌های Docker را با استفاده از ویژگی‌های Google Cloud ایجاد کنید.

---

4. تنظیم و پیکربندی پلاگین‌ها برای اهداف امنیتی

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

الف. استفاده از پلاگین‌های امنیتی برای رمزگذاری

پلاگین‌هایی مانند Weave و Calico می‌توانند رمزگذاری داده‌ها را هنگام انتقال فراهم کنند. این ویژگی به‌ویژه در محیط‌هایی که کانتینرها و داده‌ها بین چندین ماشین توزیع‌شده هستند، اهمیت دارد.

برای فعال‌سازی رمزگذاری در Weave، از دستور زیر استفاده کنید:

docker network create \
  --driver weaveworks/net-plugin:latest \
  --opt encryption=true \
  secure_network

این تنظیمات باعث رمزگذاری ترافیک بین کانتینرها در شبکه secure_network می‌شود.

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

پلاگین‌هایی مانند Calico می‌توانند به شما این امکان را بدهند که قوانین فایروال پیچیده‌ای برای

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

---

جمع‌بندی

تنظیم و پیکربندی پلاگین‌ها برای اهداف خاص به شما این امکان را می‌دهد که Docker را مطابق با نیازهای خود تنظیم کنید و از امکانات پیشرفته‌تری در زمینه ذخیره‌سازی، شبکه، و امنیت بهره‌برداری کنید. استفاده از پلاگین‌ها برای اهداف خاص به‌ویژه در محیط‌های مقیاس‌پذیر، ابری، یا توزیع‌شده بسیار مؤثر است و می‌تواند بهره‌وری، امنیت و کارایی Docker را به‌طور قابل‌توجهی افزایش دهد.[/cdb_course_lesson][/cdb_course_lessons]