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

🌐 مفهوم اصلی داکر

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

🛠 کاربردهای داکر

1️⃣ توسعه نرم‌افزار: داکر به توسعه‌دهندگان امکان می‌دهد تا برنامه‌های کاربردی را در محیطی یکسان اجرا کنند، صرف‌نظر از محیط‌های محلی که روی آن‌ها کار می‌کنند.

2️⃣ تضمین قابلیت اجرا: با بسته‌بندی برنامه‌ها و وابستگی‌هایشان درون کانتینرها، تضمین می‌شود که برنامه در هر محیطی به یک شکل اجرا می‌شود.

3️⃣ مقیاس‌پذیری و انعطاف‌پذیری: داکر اجرای چندین نمونه از یک برنامه را به صورت موازی و با استفاده از منابع کمتر ممکن می‌سازد.

4️⃣ جداسازی و امنیت: کانتینرها از یکدیگر و از سیستم‌عامل میزبان جدا هستند، که این امر امنیت برنامه‌های کاربردی را افزایش می‌دهد.

🏗 ساختار داکر

داکر از چندین مؤلفه کلیدی تشکیل شده است:

🔸داکر انجین (Docker Engine):موتور اپلیکیشنی که کانتینرها را ایجاد و اجرا می‌کند.

🔸داکر هاب (Docker Hub): یک سرویس ابری برای به اشتراک‌گذاری و مدیریت Images کانتینر.

🔸تصاویر داکر (Docker Images): بسته‌های نرم‌افزاری قابل حمل که شامل همه چیز لازم برای اجرای یک برنامه هستند.

🔸کانتینرها (Containers): نمونه‌های اجرایی از تصاویر داکر که می‌توانند بر روی محیط‌های مختلفی اجرا شوند.

💡 نکته‌های کلیدی

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

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

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



📁 #Docker

✅ کانال تخصصی لاراول
📌 @PapiDon_state

☕️ اتاق برنامه‌نویسی
📌 @PapiDon_coding

🎓 تفاوت بین تعریف Volume در Dockerfile و استفاده از v- هنگام اجرای کانتینر

سلام دوستان ! 👋

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

🔍 تعریف Volume در Dockerfile

وقتی شما یک Volume را در داخل Dockerfile تعریف می‌کنید، در حقیقت دارید به داکر می‌گویید که این دایرکتوری‌ها باید به عنوان نقاط ذخیره‌سازی پایدار (Persistent Storage) عمل کنند. به عبارت دیگر، وقتی یک کانتینر از روی این ایمیج ساخته می‌شود، آن دایرکتوری‌هایی که به عنوان Volume تعریف کرده‌اید، از کانتینر جدا شده و داده‌های آنها حفظ می‌شود، حتی اگر کانتینر متوقف شود یا از بین برود.

🔧 مثال:

FROM ubuntu:latest
VOLUME /data

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

✅ مزیت :

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

🔍 استفاده از v- هنگام اجرای کانتینر

حالا فرض کنید شما یک ایمیج داکر دارید و می‌خواهید هنگام اجرای کانتینر، یک دایرکتوری خاص از سیستم فایل میزبان (Host) خود را به داخل کانتینر Mount کنید. اینجاست که v- به کار می‌آید. این گزینه به شما اجازه می‌دهد یک Volume را دینامیک (در زمان اجرا) ایجاد کنید و یک دایرکتوری میزبان را به دایرکتوری کانتینر متصل کنید.

🔧 مثال:

docker run -v /path/on/host:/path/in/container myimage

در اینجا، /path/on/host
(که روی سیستم میزبان است) به /path/in/container (که داخل کانتینر است) متصل می‌شود. هر تغییری که در این مسیرها رخ دهد، بین میزبان و کانتینر به اشتراک گذاشته می‌شود.


✅ مزیت:

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

🎯 نتیجه‌گیری: تفاوت کلیدی

- تعریف Volume در Dockerfile بیشتر به معنای تعیین مکان‌های پیش‌فرض برای ذخیره‌سازی پایدار در هنگام ساخت ایمیج است.

- استفاده از v- به شما اجازه می‌دهد در زمان اجرا، به صورت پویا دایرکتوری‌های میزبان و کانتینر را به یکدیگر متصل کنید.

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


📌 توجه داشته باشید که تعریف VOLUME در Dockerfile الزاما به معنای این نیست که این مسیرها به طور خودکار به بیرون (میزبان) پاس داده می‌شوند یا به اشتراک گذاشته می‌شوند. این تنها به داکر اعلام می‌کند که این مسیرها باید به صورت پایدار و مستقل از چرخه زندگی کانتینر ذخیره شوند. اینکه این Volume‌ها به یک دایرکتوری در میزبان متصل شوند یا نه، به زمان اجرای کانتینر و نحوه استفاده از v- بستگی دارد.


📁 #Docker

✅ کانال تخصصی لاراول
📌 @PapiDon_state

☕️ اتاق برنامه‌نویسی
📌 @PapiDon_coding

🎓 تفاوت بین CMD و ENTRYPOINT در Dockerfile

امروز می‌خواهیم به یکی از موضوعات پرکاربرد در دنیای داکر بپردازیم: تفاوت بین دو دستور مهم CMD و ENTRYPOINT. اگر تا به حال با Dockerfile کار کرده باشید، احتمالاً با این دو دستور مواجه شده‌اید و شاید برایتان سوال شده باشد که تفاوت آنها در چیست و چه زمانی باید از هرکدام استفاده کرد. بیایید این موضوع را با چند مثال واقعی و ملموس بررسی کنیم.

🔍 CMD: تنظیم فرمان پیش‌فرض (قابل تغییر)

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

🔧 مثال

فرض کنید شما یک Dockerfile برای اجرای یک وب‌سرور ساده با Python می‌نویسید:

FROM python:3.9-slim
WORKDIR /app
COPY . /app
CMD ["python", "-m", "http.server", "8080"]

در این مثال، فرمان CMD به طور پیش‌فرض وب‌سرور پایتون را روی پورت 8080 اجرا می‌کند. حالا اگر کسی کانتینر شما را بدون هیچ فرمان اضافه‌ای اجرا کند، این وب‌سرور راه‌اندازی خواهد شد. اما اگر کاربر بخواهد یک فرمان متفاوت (مثلاً اجرای یک اسکریپت پایتون دیگر) را اجرا کند، می‌تواند این فرمان را هنگام اجرای کانتینر مشخص کند و فرمان جدید جایگزین CMD خواهد شد:

docker run myimage python my_script.py

✅ ویژگی کلیدی: CMD به شما امکان می‌دهد یک فرمان پیش‌فرض تنظیم کنید که کاربر در صورت نیاز می‌تواند آن را تغییر دهد.

🔍 ENTRYPOINT: فرمان اصلی و ثابت (غیرقابل تغییر)

در Dockerfile در واقع ENTRYPOINT به شما این امکان را می‌دهد که یک فرمان اصلی و غیرقابل تغییر تعیین کنید. هر فرمان دیگری که در زمان اجرای کانتینر مشخص شود، به عنوان آرگومان به این فرمان ااصلی اضافه می‌شود.

🔧 مثال :

فرض کنید شما یک Dockerfile برای یک ابزار خط فرمان (CLI) می‌نویسید که همیشه باید از یک دستور خاص برای اجرا استفاده شود:

FROM ubuntu:20.04
WORKDIR /app
COPY . /app
ENTRYPOINT ["curl"]

در اینجا، ENTRYPOINT فرمان curl را به عنوان فرمان اصلی تنظیم می‌کند. هر چیزی که کاربر در زمان اجرای کانتینر وارد کند، به عنوان آرگومان به curl اضافه می‌شود. مثلاً:

docker run mycurlimage https://example.com

این دستور باعث می‌شود کانتینر curl https://example.com را اجرا کند.


✅ ویژگی کلیدی: ENTRYPOINT به شما اجازه می‌دهد یک فرمان اصلی تنظیم کنید که همیشه اجرا می‌شود و فرمان‌های دیگر به عنوان آرگومان به آن اضافه می‌شوند.


🎯 ترکیب CMD و ENTRYPOINT: ایجاد فرمان‌های قابل تنظیم

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


🔧 مثال:

فرض کنید یک Dockerfile برای یک اسکریپت پایتون دارید که به طور پیش‌فرض باید با یک آرگومان خاص اجرا شود، اما کاربر می‌تواند آن آرگومان را تغییر دهد:

FROM python:3.9-slim
WORKDIR /app
COPY . /app
ENTRYPOINT ["python", "my_script.py"]
CMD ["--default-arg"]

در این حالت، وقتی کانتینر را بدون فرمان اضافی اجرا می‌کنید، اسکریپت my_script.py با آرگومان --default-arg اجرا می‌شود:

docker run myimage

اما اگر کاربر بخواهد آرگومان را تغییر دهد:

docker run myimage --custom-arg

در این حالت، اسکریپت با آرگومان --custom-arg اجرا می‌شود.


🎯 نتیجه‌گیری: تفاوت کلیدی

🔹CMD:
برای تنظیم یک فرمان پیش‌فرض که در صورت عدم تعیین فرمان در زمان اجرا، اجرا می‌شود. این فرمان قابل تغییر است و می‌تواند توسط کاربر در زمان اجرا با فرمان دیگری جایگزین شود.

🔸ENTRYPOINT:
برای تنظیم یک فرمان اصلی و غیرقابل تغییر که همیشه اجرا می‌شود. فرمان‌های دیگر به عنوان آرگومان به این فرمان اضافه می‌شوند.

با دانستن این تفاوت‌ها، می‌توانید بهتر تصمیم بگیرید که در هر سناریو از کدام دستور استفاده کنید. اگر نیاز دارید فرمان اصلی همیشه اجرا شود، از ENTRYPOINT استفاده کنید؛ و اگر می‌خواهید یک فرمان پیش‌فرض داشته باشید که در صورت نیاز قابل تغییر باشد، CMD را انتخاب کنید.




📁 #Docker

✅ کانال تخصصی لاراول
📌 @PapiDon_state

☕️ اتاق برنامه‌نویسی
📌 @PapiDon_coding

✨ بررسی Docker: containerd، runc و shim

🐳 داکر دیمون (Docker Daemon) :

- داکر دیمون فرآیند اصلی‌ای است که وظیفه مدیریت کانتینرها را برعهده دارد. این دیمون درخواست‌هایی را که از طریق رابط خط فرمان (CLI) یا API دریافت می‌کند، اجرا می‌کند.

🛠 وظایف:
🔸 مدیریت چرخه زندگی کانتینرها شامل ایجاد، توقف، راه‌اندازی مجدد و حذف کانتینرها.

🔹 مدیریت image کانتینر (کپی کردن، کش کردن و بارگذاری).

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

🔹 مدیریت وضعیت (State) هر کانتینر و ارتباط آن با سیستم.


📦 سیستم مدیریت کانتینر containerd :

- ابزار containerd برای مدیریت چرخه زندگی کانتینرها طراحی شده است. این سیستم به‌طور مستقیم با Docker کار می‌کند و درخواست‌ها را از Docker Daemon دریافت و پردازش می‌کند.

🛠 وظایف:
- مدیریت چرخه زندگی کانتینرها شامل عملیات‌هایی مانند اجرا، توقف، راه‌اندازی مجدد و مکث کانتینرها.

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

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

ارتباط با داکر:
- این ابزار به‌عنوان لایه مدیریتی زیر داکر دیمون عمل می‌کند تا وظایف مدیریتی کانتینرها را به‌صورت مستقیم انجام دهد.


⚙️ اجرای کانتینر با runc :

- ابزاری برای اجرای مستقیم کانتینرها است که با استفاده از ویژگی‌های هسته لینوکس مانند cgroups و namespaces، کانتینرها را ایزوله کرده و اجرا می‌کند.

🛠 وظایف:
- ایزوله‌سازی کانتینرها از طریق مدیریت منابع (با استفاده از cgroups) و جداسازی فرآیندها (با استفاده از namespaces) .

- اجرای کانتینرها بر اساس تنظیمات داده شده توسط سیستم مدیریت کانتینرها.

ارتباط با containerd:
- سیستم containerd درخواست‌های اجرایی کانتینرها را به runc ارسال می‌کند تا این ابزار کانتینرها را به‌صورت واقعی اجرا کند.

🔗 واسط مدیریتی containerd-shim:

- به‌عنوان یک واسطه بین containerd و runc عمل می‌کند. این واسطه بعد از اجرای کانتینر توسط runc، مدیریت کانتینر را به‌عهده می‌گیرد تا منابع سیستم بهینه‌تر مصرف شود.

🛠وظایف:
- مدیریت ورودی و خروجی کانتینرها (I/O) شامل استانداردهای ورودی و خروجی (stdin، stdout و stderr).

- مدیریت فرآیندهای کانتینر به‌صورت مستقل پس از اجرا و بدون نیاز به نظارت مستقیم containerd.

✨ مزایا:
- کاهش مصرف منابع به دلیل انتقال مدیریت کانتینرها به shim پس از اجرا.

- حفظ استقلال کانتینرها حتی در صورت توقف containerd، کانتینرها همچنان به‌کار خود ادامه می‌دهند.

🚀 فرآیند کامل اجرای کانتینر :

1️⃣ Docker Daemon
دستور اجرای یک کانتینر را از طریق CLI یا API دریافت می‌کند.

2️⃣ containerd
درخواست را پردازش می‌کند و وضعیت چرخه زندگی کانتینر را مدیریت می‌کند (ایجاد، اجرا، توقف و غیره).

3️⃣ runc
کانتینر را با استفاده از cgroups و namespaces اجرا می‌کند.

4️⃣ پس از اجرای کانتینر، shim مدیریت ورودی و خروجی و فرآیندهای کانتینر را برعهده می‌گیرد و کانتینر به‌صورت مستقل از containerd عمل می‌کند.


نتیجه‌گیری 📌:

این معماری با استفاده از ابزارهای containerd، runc و shim، به بهینه‌سازی مصرف منابع سیستم و فراهم کردن اجرای مستقل کانتینرها کمک می‌کند. shim باعث می‌شود که کانتینرها پس از اجرا به‌صورت مستقل به کار خود ادامه دهند، و runc با ایزوله‌سازی کانتینرها، مدیریت اجرایی آن‌ها را برعهده دارد.



📁 #Docker


✅ کانال تخصصی لاراول
📌 @PapiDon_state

☕️ اتاق برنامه‌نویسی
📌 @PapiDon_coding

در دنیای مدیریت پکیج‌ها و مخازن (ریپازیتوری‌ها) در ابزارهایی مثل Nexus Repository Manager یا Artifactory، سه نوع اصلی ریپازیتوری وجود دارد:

1️⃣ (میزبان‌شده) Hosted

2️⃣ (پراکسی) Proxy

3️⃣ (گروهی) Group

🔥حالا هرکدام را خیلی ساده توضیح می‌دهم و می‌گویم در چه زمانی باید از آن‌ها استفاده کنیم.

1️⃣ (ریپازیتوری میزبان‌شده) Hosted Repository

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

🔹چه زمانی استفاده می‌شود؟

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

وقتی نیاز دارید از یک فضای امن برای ذخیره‌ی artifactها (خروجی‌های بیلد، مثل فایل‌های jar یا Docker images) استفاده کنید.

اگر تیم شما پکیج‌های داخلی دارد که نمی‌خواهید در اینترنت عمومی منتشر شوند.

🔹 مثال کاربردی:
فرض کنید شما در شرکت خودتان یک کتابخانه‌ی PHP یا جاوا اسکریپت نوشته‌اید که فقط اعضای شرکت باید از آن استفاده کنند. می‌توانید این کتابخانه را در یک Hosted Repository قرار دهید تا فقط همکارانتان به آن دسترسی داشته باشند.

2️⃣ (ریپازیتوری پراکسی) Proxy Repository

این نوع ریپازیتوری مثل یک واسطه عمل می‌کند. یعنی هر درخواست برای دریافت یک پکیج از یک ریپازیتوری عمومی (مثلاً Maven Central یا Docker Hub) را دریافت کرده، آن را دانلود و ذخیره می‌کند. بعداً اگر دوباره به همان پکیج نیاز داشتید، به‌جای دانلود مجدد از اینترنت، از کش (cache) خود استفاده می‌کند.

🔹 چه زمانی استفاده می‌شود؟

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

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

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

🔹مثال کاربردی:

فرض کنید تیم شما دائماً از npm برای دانلود پکیج‌های جاوا اسکریپت استفاده می‌کند. اگر هر توسعه‌دهنده هر بار همه‌ی پکیج‌ها را مستقیماً از اینترنت دانلود کند، هم زمان زیادی هدر می‌رود و هم اینترنت زیادی مصرف می‌شود. اما اگر یک Proxy Repository برای npmjs.com داشته باشید، فقط اولین درخواست از اینترنت دریافت می‌شود و بعداً برای همه‌ی افراد داخل شرکت از نسخه‌ی کش‌شده استفاده می‌شود.

3️⃣ (ریپازیتوری گروهی) Group Repository

این نوع ریپازیتوری ترکیبی از چند ریپازیتوری مختلف (Hosted، Proxy، یا حتی دیگر Groupها) است و آن‌ها را در یک نقطه‌ی دسترسی واحد ارائه می‌دهد.

🔹چه زمانی استفاده می‌شود؟

وقتی می‌خواهید همه‌ی کاربران فقط یک URL را بدانند، بدون اینکه بدانند یک پکیج از Hosted می‌آید یا از Proxy.

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

🔹مثال کاربردی:

فرض کنید در یک شرکت کار می‌کنید که توسعه‌دهندگان از Maven Central، یک ریپازیتوری خصوصی داخلی (Hosted)، و یک Proxy Repository برای یک منبع خارجی دیگر استفاده می‌کنند. به‌جای اینکه سه مسیر مختلف تنظیم کنید، یک Group Repository می‌سازید که شامل هر سه ریپازیتوری باشد. حالا کاربران فقط با یک آدرس به همه‌ی این ریپازیتوری‌ها دسترسی دارند.


✨این سه نوع ریپازیتوری در کنار هم یک اکوسیستم کامل را برای مدیریت بسته‌ها فراهم می‌کنند. مثلاً شما ممکن است یک Proxy برای دانلود پکیج‌های عمومی، یک Hosted برای بسته‌های اختصاصی، و یک Group برای ترکیب این دو داشته باشید.




📁#Docker

✅ کانال تخصصی لاراول
📌 @PapiDon_state

☕️ اتاق برنامه‌نویسی
📌 @PapiDon_coding