در داکر، تقریباً هر نرم‌افزار یا اپلیکیشنی که روی یک سیستم عامل (معمولاً لینوکس یا ویندوز) اجرا شود، می‌تواند داکرایز شود. اما به طور کلی، موارد زیر از جمله پرکاربردترین چیزهایی هستند که می‌توان آن‌ها را داکرایز کرد:

1. برنامه‌های وب
سرورهای وب مانند Apache، Nginx، IIS.
برنامه‌های تحت وب مانند WordPress، Drupal، Joomla.
اپلیکیشن‌های توسعه داده شده با زبان‌های مختلف مانند Node.js، Django (پایتون)، Ruby on Rails.
2. پایگاه‌های داده
دیتابیس‌های رابطه‌ای مثل MySQL، PostgreSQL، SQL Server.
دیتابیس‌های NoSQL مثل MongoDB، Redis، Cassandra.
3. میکروسرویس‌ها
میکروسرویس‌هایی که با زبان‌های مختلف مانند Go، Java، Python، C# توسعه داده شده‌اند.
سیستم‌های مدیریت میکروسرویس مثل Kubernetes، Docker Swarm.
4. ابزارهای مدیریت لاگ و مانیتورینگ
ابزارهایی مانند Elasticsearch، Logstash، Kibana (مجموعه ELK).
ابزارهای مانیتورینگ مثل Prometheus، Grafana، Uptime Kuma.
5. ابزارهای توسعه و تست
محیط‌های توسعه مانند Jenkins، GitLab CI، CircleCI.
ابزارهای تست اتوماتیک مانند Selenium.
6. سرورهای پیام و صف‌ها
سیستم‌های پیام‌رسان و صف‌بندی مانند RabbitMQ، Kafka.
ابزارهای انتقال پیام و ارتباطات بین‌سرویسی.
7. ابزارهای امنیتی
فایروال‌ها، VPNها، ابزارهای مانیتورینگ امنیت مانند Suricata، Snort.
8. برنامه‌های دسکتاپ
برنامه‌هایی که می‌توانند بدون رابط کاربری یا با کمک رابط‌های وب اجرا شوند، مثل LibreOffice، GIMP.
9. پروژه‌های علمی و یادگیری ماشین
ابزارهای تحلیلی و علمی مانند Jupyter Notebooks.
محیط‌های یادگیری ماشین مانند TensorFlow، PyTorch.
10. سیستم‌های مدیریت فایل و بکاپ
ابزارهایی مانند Nextcloud، Syncthing، Veeam (اگر نسخه داکری داشته باشد).
موارد مهم در داکرایز کردن:
وابستگی‌ها و کتابخانه‌ها: داکر می‌تواند تمامی وابستگی‌ها، کتابخانه‌ها، و ابزارهای مورد نیاز اپلیکیشن شما را در یک تصویر (Image) محصور کند.
پیکربندی شبکه: سرویس‌ها و اپلیکیشن‌هایی که به ارتباطات شبکه نیاز دارند، می‌توانند به صورت ایزوله در داکر اجرا شوند.
امنیت و دسترسی‌ها: با کانتینر کردن نرم‌افزارها می‌توان سطح دسترسی آن‌ها را محدود کرد و در عین حال امنیت بیشتری ایجاد کرد.
چه چیزی را نباید داکرایز کرد؟
سیستم‌عامل‌های کامل: اگرچه برخی افراد از داکر برای اجرای سیستم‌عامل‌های کامل استفاده می‌کنند، این کار معمولاً بهترین کاربرد داکر نیست.
برنامه‌هایی که به منابع سخت‌افزاری خاصی نیاز دارند: مثلاً درایورهای سخت‌افزاری ممکن است در کانتینر به خوبی کار نکنند.
با توجه به گستردگی قابلیت‌های داکر، گزینه‌های زیادی برای داکرایز کردن وجود دارد، و انتخاب آن بسته به نیاز و کاربرد شماست.

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

1. تعامل با قفل سخت‌افزاری (Dongle)
قفل‌های سخت‌افزاری (dongles) معمولاً به صورت فیزیکی به پورت USB سیستم متصل می‌شوند و به درایورها و کتابخانه‌های خاصی نیاز دارند تا نرم‌افزار مربوطه بتواند آن‌ها را شناسایی و اعتبارسنجی کند.
کانتینرهای داکر به طور معمول با سخت‌افزار فیزیکی به صورت مستقیم تعامل ندارند، مگر اینکه پیکربندی خاصی انجام دهید تا دسترسی به دستگاه‌های USB را برای کانتینر فراهم کنید. این کار ممکن است از طریق پیکربندی‌های خاص پاس‌ثرو (pass-through) برای USB صورت گیرد، اما این روش پیچیدگی‌هایی دارد و همیشه با نرم‌افزارهای مختلف سازگار نیست.
2. برنامه‌های دسکتاپی
داکر به طور معمول برای اپلیکیشن‌های سروری یا سرویس‌های پس‌زمینه (background services) طراحی شده است و اجرای اپلیکیشن‌های دسکتاپی که به رابط کاربری نیاز دارند، در داکر کارکرد مستقیم ندارد. اگرچه می‌توانید از ابزارهایی مثل X11 forwarding یا RDP برای اجرای رابط‌های گرافیکی استفاده کنید، اما این رویکرد پیچیده‌تر و ناپایدارتر از نصب مستقیم روی ویندوز است.
3. محدودیت‌های ویندوزی در کانتینرها
در حال حاضر، کانتینرهای داکر بر روی ویندوز (Windows Containers) به طور کامل مانند یک ماشین مجازی کامل رفتار نمی‌کنند و برخی از قابلیت‌های سطح پایین سیستم عامل مانند درایورها یا تعامل با سخت‌افزار فیزیکی به خوبی پشتیبانی نمی‌شود.
حتی در کانتینرهای ویندوزی، برخی برنامه‌ها به APIهای خاص ویندوز یا درایورهایی که نیاز به دسترسی مستقیم به سیستم دارند، وابسته هستند. بنابراین اجرای آن‌ها در کانتینر ممکن است مشکل‌ساز باشد.
4. مجازی‌سازی به جای داکرایز کردن
اگر هدف شما مجازی‌سازی نرم‌افزاری است که به قفل سخت‌افزاری نیاز دارد، ممکن است بهتر باشد به جای استفاده از داکر، از ماشین‌های مجازی (VM) مثل VMware، VirtualBox، یا حتی Hyper-V استفاده کنید. در این حالت، می‌توانید به سیستم‌عامل ویندوز کامل دسترسی داشته باشید و قفل سخت‌افزاری را به صورت مستقیم از طریق USB به ماشین مجازی متصل کنید.

5. گزینه‌های دیگر برای قفل‌های نرم‌افزاری
اگر نرم‌افزار شما به قفل سخت‌افزاری وابسته است و نمی‌خواهید با مشکلات سخت‌افزاری مواجه شوید، برخی از شرکت‌ها جایگزین‌های قفل سخت‌افزاری مانند قفل‌های نرم‌افزاری (software dongles) یا اعتبارسنجی‌های آنلاین ارائه می‌دهند. این راهکارها می‌توانند کمک کنند تا برنامه‌ها بدون نیاز به قفل فیزیکی اجرا شوند.

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

nicolaka/netshoot
یک ابزار کاربردی و مفید برای عیب‌یابی شبکه در محیط‌های Docker و Kubernetes است. این کانتینر به عنوان یک جعبه ابزار شبکه عمل می‌کند و شامل مجموعه‌ای از ابزارهای شبکه برای عیب‌یابی، تست و مانیتورینگ شبکه‌ها در داخل کانتینرها است.

قابلیت‌ها و ابزارهای موجود در netshoot:
آشنایی با شبکه: برای عیب‌یابی مشکلات شبکه مثل DNS، مسیریابی، دسترسی‌پذیری و مشکلات ارتباطی بین کانتینرها بسیار مفید است.
ابزارهای شبکه: netshoot شامل بسیاری از ابزارهای شبکه‌ای است، مانند:
curl, dig, traceroute, ping, tcpdump, ip, ifconfig, netstat, nmap, nslookup, wireshark, iptables, conntrack
ابزارهای بیشتر مثل jq, tshark, telnet, iperf3, netcat, ethtool و غیره.
این ابزارها برای تحلیل و بررسی ترافیک شبکه، رفع مشکلات اتصال بین کانتینرها، بررسی قوانین فایروال و دیگر موارد مربوط به شبکه‌های Docker و Kubernetes بسیار مفید هستند.

نحوه استفاده:
برای استفاده از netshoot کافی است آن را به عنوان یک کانتینر اجرا کنید. به عنوان مثال:

docker run -it --rm nicolaka/netshoot

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

مثال‌هایی از کاربردهای netshoot:
بررسی اتصال بین کانتینرها: فرض کنید دو کانتینر در حال اجرا هستند و شما می‌خواهید بررسی کنید آیا ارتباط بین آنها برقرار است یا خیر:

docker run -it --rm --network container:<container_name> nicolaka/netshoot ping <target_container>

تحلیل ترافیک شبکه با tcpdump: برای ضبط ترافیک شبکه داخل یک کانتینر:

docker run -it --rm --network container:<container_name> nicolaka/netshoot tcpdump -i eth0

بررسی تنظیمات DNS: اگر مشکلی در دسترسی به DNS دارید، می‌توانید از dig یا nslookup استفاده کنید:

docker run -it --rm nicolaka/netshoot dig google.com

موارد استفاده اصلی:
حل مشکلات مربوط به اتصال شبکه در کانتینرهای Docker.
تحلیل ترافیک شبکه و بررسی ترافیک ورودی و خروجی کانتینرها.
بررسی فایروال‌ها و تنظیمات iptables.
تست‌های مربوط به سرعت شبکه و عملکرد.
nicolaka/netshoot یک ابزار همه‌کاره برای ادمین‌های شبکه و سیستم‌عامل‌ها در محیط‌های کانتینری است و به عیب‌یابی سریع مشکلات شبکه کمک شایانی می‌کند.

چرا کانتینر پس از توقف دستی ری‌استارت نمی‌شود؟
سیاست always به این شکل کار می‌کند:

اگر کانتینر به‌صورت غیرمنتظره متوقف شود (مثلاً به‌خاطر خطا یا خاموش شدن سیستم)، Docker آن را مجدداً استارت می‌کند.
اما اگر شما به‌صورت دستی و از طریق دستور docker stop یا docker kill کانتینر را متوقف کنید، Docker کانتینر را مجدداً استارت نمی‌کند، زیرا فرض می‌کند که شما به‌طور عمدی آن را متوقف کرده‌اید.

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

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

اسکریپت ساده:
#!/bin/bash

CONTAINER_NAME="<container_name_or_id>"

while true; do
STATUS=$(docker inspect -f '{{.State.Status}}' $CONTAINER_NAME)

if [ "$STATUS" != "running" ]; then
echo "Container $CONTAINER_NAME is not running. Starting it now..."
docker start $CONTAINER_NAME
fi

sleep 10 # بررسی وضعیت هر ۱۰ ثانیه یکبار
done

توضیحات:
اسکریپت هر ۱۰ ثانیه وضعیت کانتینر را بررسی می‌کند.
اگر کانتینر در وضعیت running نباشد، دستور docker start اجرا شده و کانتینر استارت می‌شود.
متغیر CONTAINER_NAME را به نام یا ID کانتینر موردنظر تغییر بده.
نحوه اجرای اسکریپت:
اسکریپت را در یک فایل ذخیره کن. مثلاً به نام container-watch.sh.
به فایل دسترسی اجرایی بده:
chmod +x container-watch.sh
اسکریپت را اجرا کن:
./container-watch.sh

این اسکریپت کانتینر را به‌طور مداوم مانیتور می‌کند و اگر متوقف شد (حتی به‌صورت دستی)، آن را مجدداً استارت می‌کند.

برای این‌که این اسکریپت به عنوان یک سرویس سیستم‌عامل (systemd service) همیشه در بک‌گراند اجرا شود، می‌توانید آن را به‌صورت یک سرویس systemd تنظیم کنید. این روش به شما اجازه می‌دهد که اسکریپت به‌صورت خودکار با بوت شدن سیستم شروع شود و در صورت نیاز به‌سادگی مدیریت شود.

مراحل ایجاد سرویس systemd:
1. ایجاد فایل سرویس:
ابتدا فایل اسکریپت را در یک دایرکتوری مناسب مثل /usr/local/bin کپی کنید. مثلاً:
sudo cp container-watch.sh /usr/local/bin/
سپس یک فایل سرویس جدید در دایرکتوری systemd ایجاد کنید:
sudo nano /etc/systemd/system/container-watch.service
2. محتوای فایل سرویس:
فایل سرویس را به‌صورت زیر تنظیم کنید:
[Unit]
Denoscription=Container Watch Service
After=docker.service
Requires=docker.service

[Service]
ExecStart=/usr/local/bin/container-watch.sh
Restart=always
User=root

[Install]
WantedBy=multi-user.target

توضیحات:
ExecStart: مسیر کامل اسکریپت شما.
Restart=always: به سرویس می‌گوید اگر اسکریپت متوقف شد، آن را دوباره اجرا کند.
User=root: اسکریپت به عنوان کاربر root اجرا می‌شود. (در صورت نیاز می‌توانید کاربر دیگری را انتخاب کنید)
After=docker.service و Requires=docker.service: این خطوط تضمین می‌کنند که سرویس بعد از اجرای Docker شروع می‌شود.
3. ریلود و فعال‌سازی سرویس:
بعد از ایجاد فایل سرویس، systemd را ریلود کنید تا تغییرات اعمال شوند:
sudo systemctl daemon-reload
4. بررسی وضعیت سرویس:
برای مشاهده وضعیت سرویس می‌توانید از دستور زیر استفاده کنید:
sudo systemctl status container-watch.service

Webmin

sudo apt update
sudo apt upgrade
sudo apt install software-properties-common apt-transport-https wget

wget -q http://www.webmin.com/jcameron-key.asc -O- | sudo apt-key add -

echo "deb http://download.webmin.com/download/repository sarge contrib" | sudo tee /etc/apt/sources.list.d/webmin.list

sudo apt update
sudo apt install webmin

https://localhost:10000/

نصب Webmin روی اوبنتو 20.04

:local logTime [/system clock get time];
:local logDate [/system clock get date];
:local interfaceName Dubai;
:local event UP;
:local logFileName "interface-logs.txt";
:local logMessage ("$logDate $logTime - Interface: $interfaceName - Event: $event");
:local fileCount [:len [/file find name="$logFileName"]];
:if ($fileCount = 0) do={/file print file="$logFileName"};
/file set "$logFileName" contents=([/file get "$logFileName" contents] . "\n$logMessage");

برای خروجی لاگ قطعی و وصلی اینترفیس ها
د ر ادامه :
/tool netwatch
add host=8.8.8.8 interval=1m up-noscript="/system noscript run LogInterfaceEvent ether1 up" down-noscript="/system noscript run LogInterfaceEvent ether1 down"

میاد توی netwatch که بگه اگر قطعی بود چه کن و اگر وصل بود چه کن