'\" t .nh .TH "DOCKER" "1" "JUNE 2014" "Docker Community" "Docker User Manuals" .SH "نام (NAME)" docker-run \- ایجاد و اجرای یک کانتینر جدید از یک ایمیج .SH "خلاصه (SYNOPSIS)" \fBdocker run\fP [\fB-a\fP|\fB--attach\fP[=\fI[]\fP]] [\fB--add-host\fP[=\fI[]\fP]] [\fB--annotation\fP[=\fI[]\fP]] [\fB--blkio-weight\fP[=\fI[BLKIO-WEIGHT]\fP]] [\fB--blkio-weight-device\fP[=\fI[]\fP]] [\fB-c\fP|\fB--cpu-shares\fP[=\fI0\fP]] [\fB--cap-add\fP[=\fI[]\fP]] [\fB--cap-drop\fP[=\fI[]\fP]] [\fB--cgroupns\fP[=\fI[]\fP]] [\fB--cgroup-parent\fP[=\fICGROUP-PATH\fP]] [\fB--cidfile\fP[=\fICIDFILE\fP]] [\fB--cpu-count\fP[=\fI0\fP]] [\fB--cpu-percent\fP[=\fI0\fP]] [\fB--cpu-period\fP[=\fI0\fP]] [\fB--cpu-quota\fP[=\fI0\fP]] [\fB--cpu-rt-period\fP[=\fI0\fP]] [\fB--cpu-rt-runtime\fP[=\fI0\fP]] [\fB--cpus\fP[=\fI0.0\fP]] [\fB--cpuset-cpus\fP[=\fICPUSET-CPUS\fP]] [\fB--cpuset-mems\fP[=\fICPUSET-MEMS\fP]] [\fB-d\fP|\fB--detach\fP] [\fB--detach-keys\fP[=\fI[]\fP]] [\fB--device\fP[=\fI[]\fP]] [\fB--device-cgroup-rule\fP[=\fI[]\fP]] [\fB--device-read-bps\fP[=\fI[]\fP]] [\fB--device-read-iops\fP[=\fI[]\fP]] [\fB--device-write-bps\fP[=\fI[]\fP]] [\fB--device-write-iops\fP[=\fI[]\fP]] [\fB--dns\fP[=\fI[]\fP]] [\fB--dns-option\fP[=\fI[]\fP]] [\fB--dns-search\fP[=\fI[]\fP]] [\fB--domainname\fP[=\fIDOMAINNAME\fP]] [\fB-e\fP|\fB--env\fP[=\fI[]\fP]] [\fB--entrypoint\fP[=\fIENTRYPOINT\fP]] [\fB--env-file\fP[=\fI[]\fP]] [\fB--expose\fP[=\fI[]\fP]] [\fB--group-add\fP[=\fI[]\fP]] [\fB-h\fP|\fB--hostname\fP[=\fIHOSTNAME\fP]] [\fB--help\fP] [\fB--init\fP] [\fB-i\fP|\fB--interactive\fP] [\fB--ip\fP[=\fIIPv4-ADDRESS\fP]] [\fB--ip6\fP[=\fIIPv6-ADDRESS\fP]] [\fB--ipc\fP[=\fIIPC\fP]] [\fB--isolation\fP[=\fIdefault\fP]] [\fB-l\fP|\fB--label\fP[=\fI[]\fP]] [\fB--label-file\fP[=\fI[]\fP]] [\fB--link\fP[=\fI[]\fP]] [\fB--link-local-ip\fP[=\fI[]\fP]] [\fB--log-driver\fP[=\fI[]\fP]] [\fB--log-opt\fP[=\fI[]\fP]] [\fB-m\fP|\fB--memory\fP[=\fIMEMORY\fP]] [\fB--mac-address\fP[=\fIMAC-ADDRESS\fP]] [\fB--memory-reservation\fP[=\fIMEMORY-RESERVATION\fP]] [\fB--memory-swap\fP[=\fILIMIT\fP]] [\fB--memory-swappiness\fP[=\fIMEMORY-SWAPPINESS\fP]] [\fB--mount\fP[=\fI[MOUNT]\fP]] [\fB--name\fP[=\fINAME\fP]] [\fB--network-alias\fP[=\fI[]\fP]] [\fB--network\fP[=\fI"bridge"\fP]] [\fB--oom-kill-disable\fP] [\fB--oom-score-adj\fP[=\fI0\fP]] [\fB-P\fP|\fB--publish-all\fP] [\fB-p\fP|\fB--publish\fP[=\fI[]\fP]] [\fB--pid\fP[=\fI[PID]\fP]] [\fB--userns\fP[=\fI[]\fP]] [\fB--pids-limit\fP[=\fIPIDS_LIMIT\fP]] [\fB--privileged\fP] [\fB--read-only\fP] [\fB--restart\fP[=\fIRESTART\fP]] [\fB--rm\fP] [\fB--security-opt\fP[=\fI[]\fP]] [\fB--storage-opt\fP[=\fI[]\fP]] [\fB--stop-signal\fP[=\fISIGNAL\fP]] [\fB--stop-timeout\fP[=\fITIMEOUT\fP]] [\fB--shm-size\fP[=\fI[]\fP]] [\fB--sig-proxy\fP[=\fItrue\fP]] [\fB--sysctl\fP[=\fI[]\fP]] [\fB-t\fP|\fB--tty\fP] [\fB--tmpfs\fP[=\fI[CONTAINER-DIR[:OPTIONS]\fP]] [\fB-u\fP|\fB--user\fP[=\fIUSER\fP]] [\fB--ulimit\fP[=\fI[]\fP]] [\fB--uts\fP[=\fI[]\fP]] [\fB-v\fP|\fB--volume\fP[=\fI[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]\fP]] [\fB--volume-driver\fP[=\fIDRIVER\fP]] [\fB--volumes-from\fP[=\fI[]\fP]] [\fB-w\fP|\fB--workdir\fP[=\fIWORKDIR\fP]] IMAGE [COMMAND] [ARG...] .SH "شرح (DESCRIPTION)" اجرای یک پردازش در یک کانتینر جدید. دستور \fBdocker run\fP پردازشی را با فایل‌سیستم مخصوص به خود، شبکه اختصاصی و درخت پردازش ایزوله شده خود آغاز می‌کند. ایمیج (IMAGE) که پردازش را آغاز می‌کند ممکن است مقادیر پیش‌فرضی مربوط به پردازشی که در کانتینر اجرا خواهد شد، شبکه‌ای که اکسپوز می‌شود و موارد دیگر تعیین کند، اما \fBdocker run\fP کنترل نهایی را به مجری یا مدیری می‌دهد که کانتینر را از آن ایمیج شروع می‌کند. به همین دلیل \fBdocker run\fP گزینه‌های بیشتری نسبت به هر دستور دیگر Docker دارد. .PP اگر ایمیج (IMAGE) قبلاً بارگیری نشده باشد، \fBdocker run\fP پیش از آغاز کانتینر از آن ایمیج، ایمیج و تمامی وابستگی‌های آن را درست همانند اجرای دستور \fBdocker pull\fP IMAGE از مخزن دریافت می‌کند. .SH "گزینه‌ها (OPTIONS)" \fB-a\fP, \fB--attach\fP=[] متصل شدن به STDIN، STDOUT یا STDERR. .PP در حالت پیش‌زمینه (حالت پیش‌فرض زمانی که \fB-d\fP مشخص نشده باشد)، \fBdocker run\fP می‌تواند پردازش را در کانتینر آغاز کرده و کنسول را به ورودی استاندارد، خروجی استاندارد و خطای استاندارد پردازش متصل کند. حتی می‌تواند خود را مانند یک TTY شبیه‌سازی کند (چیزی که اکثر فایل‌های اجرایی خط فرمان انتظار دارند) و سیگنال‌ها را منتقل نماید. گزینه \fB-a\fP می‌تواند برای هر یک از stdin، stdout و stderr تنظیم شود. .PP \fB--add-host\fP=[] افزودن یک نگاشت سفارشی میزبان به IP (به صورت host=ip یا host:ip). .PP افزودن یک خط به /etc/hosts. قالب به صورت hostname=ip یا hostname:ip است. گزینه \fB--add-host\fP می‌تواند چندین بار مشخص شود. .PP \fB--annotation\fP=[] افزودن یک یادداشت (annotation) به کانتینر (ارسال به محیط زمان اجرای OCI). .PP این یادداشت‌ها به زمان اجرای OCI تحویل داده می‌شوند. .PP \fB--blkio-weight\fP=\fI0\fP وزن ورودی/خروجی بلوکی (وزن نسبی)؛ مقداری بین 10 تا 1000 می‌پذیرد. .PP \fB--blkio-weight-device\fP=[] وزن ورودی/خروجی بلوکی (وزن نسبی دستگاه، با قالب: \fBDEVICE_NAME:WEIGHT\fR). .PP \fB-c\fP, \fB--cpu-shares\fP=\fI0\fP سهم پردازنده (وزن نسبی) .PP به طور پیش‌فرض، همه کانتینرها سهم یکسانی از چرخه‌های پردازنده دریافت می‌کنند. این سهم می‌تواند با تغییر دادن وزن سهم پردازنده کانتینر نسبت به وزن سایر کانتینرهای در حال اجرا، تغییر یابد. .PP برای تغییر دادن این سهم از مقدار پیش‌فرض 1024، از گزینه \fB-c\fP یا \fB--cpu-shares\fP برای تنظیم وزن به 2 یا بیشتر استفاده کنید. .PP این سهم تنها هنگامی اعمال می‌شود که پردازش‌های نیازمند توان پردازشی بالا در حال اجرا باشند. زمانی که وظایف در یک کانتینر بیکار باشند، سایر کانتینرها می‌توانند از زمان پردازنده باقیمانده استفاده کنند. مقدار واقعی زمان پردازنده بسته به تعداد کانتینرهای در حال اجرا در سیستم متفاوت خواهد بود. .PP برای مثال، سه کانتینر را در نظر بگیرید که یکی سهم پردازنده 1024 و دو کانتینر دیگر سهم 512 دارند. هنگامی که پردازش‌ها در هر سه کانتینر برای استفاده از ۱۰۰٪ توان پردازنده تلاش کنند، کانتینر اول ۵۰٪ از کل زمان پردازنده را دریافت خواهد کرد. اگر کانتینر چهارمی با سهم 1024 اضافه کنید، کانتینر اول تنها ۳۳٪ پردازنده را می‌گیرد و کانتینرهای باقیمانده ۱۶.۵٪، ۱۶.۵٪ و ۳۳٪ دریافت خواهند کرد. .PP در یک سیستم چند‌هسته‌ای، سهم زمان پردازنده روی تمام هسته‌های پردازنده توزیع می‌شود. حتی اگر یک کانتینر به کمتر از ۱۰۰٪ زمان کلی پردازنده محدود شده باشد، می‌تواند از ۱۰۰٪ هر هسته مجزا استفاده کند. .PP برای مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر یک کانتینر \fB{C0}\fP را با \fB-c=512\fP که یک پردازش را اجرا می‌کند، و کانتینر دیگری \fB{C1}\fP را با \fB-c=1024\fP که دو پردازش را اجرا می‌کند آغاز کنید، می‌تواند به تقسیم سهم پردازنده زیر منجر شود: .EX PID container CPU CPU share 100 {C0} 0 100% of CPU0 101 {C1} 1 100% of CPU1 102 {C1} 2 100% of CPU2 .EE .PP \fB--cap-add\fP=[] افزودن قابلیت‌های لینوکس (Linux capabilities) .PP \fB--cap-drop\fP=[] حذف قابلیت‌های لینوکس (Linux capabilities) .PP \fB--cgroupns\fP="" تنظیم حالت فضای‌نام cgroup برای کانتینر: \fBhost\fP: اجرای کانتینر در فضای‌نام cgroup میزبان \fBprivate\fP: اجرای کانتینر در فضای‌نام cgroup خصوصی خودش \fB""\fP: (تنظیم‌نشده) استفاده از پیکربندی پیش‌فرض دیمن (\fBhost\fP در cgroup v1، \fBprivate\fP در cgroup v2) .PP \fB--cgroup-parent\fP="" مسیر cgroups که cgroup کانتینر در زیر آن ایجاد خواهد شد. اگر مسیر مطلق نباشد، نسبت به مسیر cgroups پردازش init در نظر گرفته می‌شود. در صورت عدم وجود cgroups، ایجاد خواهند شد. .PP \fB--cidfile\fP="" نوشتن شناسه کانتینر در فایل مشخص‌شده .PP \fB--cpu-count\fP=\fI0\fP محدود کردن تعداد پردازنده‌های در دسترس برای اجرا توسط کانتینر. .PP در کانتینرهای Windows Server، این مقدار به صورت درصدی از کل مصرف پردازنده تقریب زده می‌شود. در کانتینرهای Windows Server، کنترل‌های منابع پردازنده ناسازگار با یکدیگر (mutually exclusive) هستند و ترتیب اولویت ابتدا CPUCount، سپس CPUShares و در نهایت CPUPercent است. .PP \fB--cpu-percent\fP=\fI0\fP محدود کردن درصد پردازنده در دسترس برای اجرا توسط کانتینری که روی دیمن ویندوز اجرا می‌شود. .PP در کانتینرهای Windows Server، کنترل‌های منابع پردازنده ناسازگار با یکدیگر هستند و ترتیب اولویت ابتدا CPUCount، سپس CPUShares و در نهایت CPUPercent است. .PP \fB--cpu-period\fP=\fI0\fP محدود کردن دوره CFS (زمان‌بند کاملاً عادلانه) پردازنده .PP محدود کردن مصرف پردازنده کانتینر. این فلگ به کرنل دستور می‌دهد که مصرف پردازنده کانتینر را به دوره‌ای که مشخص می‌کنید محدود سازد. .PP \fB--cpuset-cpus\fP="" پردازنده‌هایی که اجازه اجرا در آنها داده می‌شود (مثلاً 0-3، 0,1) .PP \fB--cpuset-mems\fP="" گره‌های حافظه (MEMs) که اجازه اجرا در آنها داده می‌شود (0-3، 0,1). فقط در سیستم‌های NUMA موثر است. .PP اگر چهار گره حافظه در سیستم خود دارید (0-3)، استفاده از \fB--cpuset-mems=0,1\fR باعث می‌شود پردازش‌ها در کانتینر داکر شما تنها از حافظه دو گره نخست استفاده کنند. .PP \fB--cpu-quota\fP=\fI0\fP محدود کردن سهمیه (quota) دوره CFS (زمان‌بند کاملاً عادلانه) پردازنده .PP محدود کردن مصرف پردازنده کانتینر. به طور پیش‌فرض، کانتینرها با منابع کامل پردازنده اجرا می‌شوند. این فلگ به کرنل دستور می‌دهد مصرف پردازنده کانتینر را به سهمیه‌ای که مشخص می‌کنید محدود کند. .PP \fB--cpu-rt-period\fP=0 محدود کردن دوره بلادرنگ (real-time) پردازنده بر حسب میکروثانیه .PP محدود کردن مصرف پردازنده بلادرنگ کانتینر. این فلگ به کرنل دستور می‌دهد که مصرف پردازنده بلادرنگ کانتینر را به دوره‌ای که مشخص می‌کنید محدود سازد. .PP \fB--cpu-rt-runtime\fP=0 محدود کردن زمان اجرای بلادرنگ (real-time runtime) پردازنده بر حسب میکروثانیه .PP محدود کردن مصرف پردازنده بلادرنگ کانتینر. این فلگ به کرنل می‌گوید میزان زمانی را که وظایف بلادرنگ در یک دوره زمانی مشخص می‌توانند مصرف کنند محدود سازد. برای مثال، دوره ۱,۰۰۰,۰۰۰ میکروثانیه و زمان اجرای ۹۵۰,۰۰۰ میکروثانیه بدین معناست که این کانتینر می‌تواند ۹۵٪ از پردازنده در دسترس را مصرف کرده و ۵٪ باقیمانده را برای وظایف با اولویت عادی بگذارد. .PP مجموع کل زمان‌های اجرا در میان تمامی کانتینرها نمی‌تواند از مقدار اختصاص‌یافته به cgroup والد فراتر رود. .PP \fB--cpus\fP=0.0 تعداد پردازنده‌ها. مقدار پیش‌فرض \fI0.0\fP است که به معنای عدم محدودیت است. .PP \fB-d\fP, \fB--detach\fP=\fItrue\fP|\fIfalse\fP حالت جداشده (Detached): اجرای کانتینر در پس‌زمینه و چاپ شناسه کانتینر جدید. مقدار پیش‌فرض \fIfalse\fP است. .PP در هر زمان می‌توانید \fBdocker ps\fP را در یک پوسته دیگر برای مشاهده فهرست کانتینرهای در حال اجرا اجرا کنید. می‌توانید با \fBdocker attach\fP دوباره به یک کانتینر جداشده متصل شوید. .PP هنگامی که در حالت tty متصل هستید، می‌توانید با استفاده از یک توالی کلید قابل‌پیکربندی از کانتینر جدا شوید (و بگذارید در حال اجرا بماند). توالی پیش‌فرض \fBCTRL-p CTRL-q\fR است. می‌توانید توالی کلید را با استفاده از گزینه \fB--detach-keys\fP یا یک فایل پیکربندی تنظیم کنید. برای مستندات استفاده از فایل پیکربندی به \fBconfig-json(5)\fP مراجعه کنید. .PP \fB--detach-keys\fP=\fIkey\fP بازنویسی توالی کلید برای جدا شدن از یک کانتینر؛ \fIkey\fP یک کاراکتر منفرد از محدوده [a-Z]، یا به صورت \fBctrl\fP-\fIvalue\fP است، که در آن \fIvalue\fP یکی از مقادیر روبرو است: \fBa-z\fP، \fB@\fP، \fB^\fP، \fB[\fP، \fB,\fP، یا \fB_\fP. .PP \fB--device\fP=\fIonhost\fP:\fIincontainer\fP[:\fImode\fP] افزودن دستگاه میزبان \fIonhost\fP به داخل کانتینر با نام \fIincontainer\fP. پارامتر اختیاری \fImode\fP می‌تواند برای تعیین دسترسی‌های دستگاه استفاده شود؛ این پارامتر ترکیبی از \fBr\fP (برای خواندن)، \fBw\fP (برای نوشتن)، و \fBm\fP (برای \fBmknod\fP(2)) است. .PP برای مثال، \fB--device=/dev/sdc:/dev/xvdc:rwm\fP به کانتینر تمامی دسترسی‌ها را برای دستگاه میزبان \fB/dev/sdc\fP می‌دهد، که در داخل کانتینر به عنوان \fB/dev/xvdc\fP دیده می‌شود. .PP \fB--device-cgroup-rule\fP="\fItype\fP \fImajor\fP:\fIminor\fP \fImode\fP" افزودن یک قانون به فهرست دستگاه‌های مجاز cgroup. قانون باید در قالبی باشد که در مستندات کرنل لینوکس مشخص شده است (Documentation/cgroup-v1/devices.txt): - \fItype\fP: شامل \fBa\fP (همه)، \fBc\fP (کاراکتری)، یا \fBb\fP (بلوکی)؛ - \fImajor\fP و \fIminor\fP: یک عدد، یا \fB*\fP برای همه؛ - \fImode\fP: ترکیبی از \fBr\fP (خواندن)، \fBw\fP (نوشتن)، و \fBm\fP (\fBmknod\fP(2)). .PP مثال: \fB--device-cgroup-rule "c 1:3 mr"\fP: اجازه می‌دهد دستگاه کاراکتری با مشخصه \fB1:3\fP ایجاد و خوانده شود. .PP \fB--device-read-bps\fP=[] محدود کردن نرخ خواندن از یک دستگاه (مثلاً --device-read-bps=/dev/sda:1mb) .PP \fB--device-read-iops\fP=[] محدود کردن نرخ خواندن از یک دستگاه (مثلاً --device-read-iops=/dev/sda:1000) .PP \fB--device-write-bps\fP=[] محدود کردن نرخ نوشتن در یک دستگاه (مثلاً --device-write-bps=/dev/sda:1mb) .PP \fB--device-write-iops\fP=[] محدود کردن نرخ نوشتن در یک دستگاه (مثلاً --device-write-iops=/dev/sda:1000) .PP \fB--dns-search\fP=[] تنظیم دامنه‌های جستجوی سفارشی DNS (اگر نمی‌خواهید دامنه جستجو تنظیم کنید از --dns-search=. استفاده کنید) .PP \fB--dns-option\fP=[] تنظیم گزینه‌های سفارشی DNS .PP \fB--dns\fP=[] تنظیم سرورهای سفارشی DNS .PP این گزینه می‌تواند برای بازنویسی پیکربندی DNS ارسالی به کانتینر استفاده شود. این امر معمولاً زمانی ضروری است که پیکربندی DNS میزبان برای کانتینر نامعتبر باشد (مثلاً 127.0.0.1). در چنین شرایطی فلگ‌های \fB--dns\fP برای هر بار اجرا لازم است. .PP \fB--domainname\fP="" نام دامنه NIS کانتینر .PP نام دامنه NIS کانتینر (همچنین به \fBsetdomainname(2)\fP مراجعه کنید) را که در داخل کانتینر در دسترس است تنظیم می‌کند. .PP \fB-e\fP, \fB--env\fP=[] تنظیم متغیرهای محیطی .PP این گزینه به شما امکان می‌دهد متغیرهای محیطی دلخواهی را مشخص کنید که در دسترس پردازشی که درون کانتینر اجرا خواهد شد قرار گیرند. .PP \fB--entrypoint\fP="" بازنویسی ENTRYPOINT پیش‌فرض ایمیج .PP این گزینه به شما اجازه می‌دهد نقطه ورود پیش‌فرض ایمیج را که در Dockerfile تعیین شده بازنویسی کنید. نقطه ورود (ENTRYPOINT) یک ایمیج مشابه COMMAND است زیرا مشخص می‌کند هنگام آغاز کانتینر چه فایل اجرایی باید اجرا شود، اما (عامدانه) بازنویسی آن دشوارتر است. نقطه ورود، ماهیت یا رفتار پیش‌فرض کانتینر را شکل می‌دهد، به طوری که وقتی یک ENTRYPOINT تنظیم می‌کنید می‌توانید کانتینر را درست مانند اجرای آن برنامه باینری همراه با گزینه‌های پیش‌فرضش اجرا نمایید، و گزینه‌های بیشتر را از طریق COMMAND منتقل کنید. اما گاهی ممکن است مدیر بخواهد چیز دیگری را درون کانتینر اجرا کند؛ بنابراین می‌توانید ENTRYPOINT پیش‌فرض را در زمان اجرا با استفاده از \fB--entrypoint\fP و یک رشته برای مشخص کردن ENTRYPOINT جدید بازنویسی کنید. .PP \fB--env-file\fP=[] خواندن متغیرهای محیطی از یک فایل خط‌به‌خط .PP \fB--expose\fP=[] اکسپوز کردن یک درگاه یا محدوده‌ای از درگاه‌ها (مثلاً --expose=3300-3310) به دیمن داکر اطلاع می‌دهد که کانتینر در زمان اجرا روی درگاه‌های شبکه مشخص‌شده گوش فرا می‌دهد. دیمن داکر از این اطلاعات برای متصل کردن متقابل کانتینرها با استفاده از پیوندها (links) و راه‌اندازی هدایت درگاه روی سیستم میزبان استفاده می‌کند. .PP \fB--group-add\fP=[] افزودن گروه‌های اضافی برای اجرا تحت عنوان آنها .PP \fB-h\fP, \fB--hostname\fP="" نام میزبان کانتینر .PP نام میزبان کانتینر را که در داخل کانتینر در دسترس است تنظیم می‌کند. .PP \fB--help\fP چاپ راهنمای نحوه استفاده .PP \fB--init\fP اجرای یک پردازش init درون کانتینر که سیگنال‌ها را هدایت کرده و پردازش‌های زامبی را پاکسازی می‌کند .PP \fB-i\fP, \fB--interactive\fP=\fItrue\fP|\fIfalse\fP باز نگه داشتن STDIN حتی اگر متصل نشده باشد. مقدار پیش‌فرض \fIfalse\fP است. .PP زمانی که روی true تنظیم شود، ورودی استاندارد را حتی در صورت عدم اتصال باز نگه می‌دارد. .PP \fB--ip\fP="" نشانی IPv4 رابط شبکه کانتینر را تنظیم می‌کند (مثلاً 172.23.0.9) .PP این گزینه تنها همراه با \fB--network\fP برای شبکه‌های تعریف‌شده توسط کاربر قابل استفاده است. .PP \fB--ip6\fP="" نشانی IPv6 رابط شبکه کانتینر را تنظیم می‌کند (مثلاً 2001:db8::1b99) .PP این گزینه تنها همراه با \fB--network\fP برای شبکه‌های تعریف‌شده توسط کاربر قابل استفاده است. .PP \fB--ipc\fP="" حالت IPC را برای کانتینر تنظیم می‌کند. مقادیر زیر پذیرفته می‌شوند: .TS allbox; l l l l . \fBمقدار\fP \fBشرح\fP (خالی) استفاده از مقدار پیش‌فرض دیمن. \fBnone\fP T{ فضای‌نام IPC اختصاصی خودش، بدون سوار شدن /dev/shm. T} \fBprivate\fP فضای‌نام IPC اختصاصی خودش. \fBshareable\fP T{ فضای‌نام IPC اختصاصی خودش، با امکان اشتراک‌گذاری با سایر کانتینرها. T} \fBcontainer:\fP\fIname-or-ID\fP T{ پیوستن به فضای‌نام IPC کانتینر دیگر (از نوع "shareable"). T} \fBhost\fP T{ استفاده از فضای‌نام IPC سیستم میزبان. T} .TE .PP در صورت عدم تعیین، مقدار پیش‌فرض دیمن استفاده می‌شود که بسته به نگارش و پیکربندی دیمن، می‌تواند \fBprivate\fP یا \fBshareable\fP باشد. .PP \fB--isolation\fP="\fIdefault\fP" جداسازی (Isolation) نوع فناوری جداسازی مورد استفاده کانتینرها را تعیین می‌کند. توجه داشته باشید که مقدار پیش‌فرض در سرور ویندوز \fBprocess\fR است، و پیش‌فرض در کلاینت ویندوز \fBhyperv\fR می‌باشد. لینوکس تنها از \fBdefault\fR پشتیبانی می‌کند. .PP \fB-l\fP, \fB--label\fP \fIkey\fP=\fIvalue\fP تنظیم متاداده روی کانتینر (برای مثال، \fB--label com.example.key=value\fP). .PP \fB--label-file\fP=[] خواندن برچسب‌ها از یک فایل خط‌به‌خط .PP \fB--link\fP=\fIname-or-id\fP[:\fIalias\fP] افزودن پیوند به کانتینر دیگر. .PP اگر مجری هنگام شروع کانتینر کلاینت جدید از \fB--link\fP استفاده کند، کانتینر کلاینت می‌تواند از طریق یک رابط شبکه خصوصی به درگاه اکسپوز شده دسترسی یابد. داکر برخی متغیرهای محیطی را در کانتینر کلاینت تنظیم می‌کند تا نشان دهد از کدام رابط و درگاه باید استفاده شود. .PP \fB--link-local-ip\fP=[] افزودن یک یا چند نشانی IPv4/IPv6 پیوند-محلی (link-local) به رابط شبکه کانتینر .PP \fB--log-driver\fP="\fIjson-file\fP|\fIsyslog\fP|\fIjournald\fP|\fIgelf\fP|\fIfluentd\fP|\fIawslogs\fP|\fIsplunk\fP|\fIetwlogs\fP|\fIgcplogs\fP|\fInone\fP" درایور ثبت وقایع (لاگ) برای کانتینر. پیش‌فرض توسط فلگ \fB--log-driver\fP دیمن تعریف می‌شود. \fBهشدار\fP: دستور \fBdocker logs\fR تنها برای درایورهای \fBjson-file\fR و \fBjournald\fR کار می‌کند. .PP \fB--log-opt\fP=[] گزینه‌های اختصاصی درایور لاگ. .PP \fB-m\fP, \fB--memory\fP=\fInumber\fP[*S] محدودیت حافظه؛ \fIS\fP پسوند اختیاری است که می‌تواند یکی از \fBb\fP، \fBk\fP، \fBm\fP یا \fBg\fP باشد. .PP به شما امکان می‌دهد حافظه در دسترس کانتینر را محدود کنید. اگر میزبان از حافظه معاوضه (swap) پشتیبانی کند، تنظیم حافظه \fB-m\fP می‌تواند بزرگتر از RAM فیزیکی باشد. اگر محدودیت 0 مشخص شود (عدم استفاده از \fB-m\fP)، حافظه کانتینر محدود نمی‌شود. محدودیت واقعی ممکن است به مضربی از اندازه صفحه سیستم‌عامل گرد شود (مقدار بسیار بزرگی خواهد بود). .PP \fB--memory-reservation\fP=\fInumber\fP[*S] محدودیت نرم حافظه؛ \fIS\fP پسوند اختیاری است که می‌تواند یکی از \fBb\fP، \fBk\fP، \fBm\fP یا \fBg\fP باشد. .PP پس از تنظیم رزرو حافظه، هنگامی که سیستم رقابت حافظه یا کمبود حافظه را شناسایی کند، کانتینرها مجبور می‌شوند مصرف خود را به میزان رزرو شده محدود کنند. بنابراین همیشه باید مقدار را کمتر از \fB--memory\fP تنظیم کنید، در غیر این صورت حد سخت اولویت خواهد داشت. به طور پیش‌فرض، رزرو حافظه برابر با محدودیت حافظه خواهد بود. .PP \fB--memory-swap\fP=\fInumber\fP[\fIS\fP] مجموع محدودیت حافظه به همراه معاوضه (swap)؛ \fIS\fP یک پسوند اختیاری است که می‌تواند یکی از \fBb\fP، \fBk\fP، \fBm\fP یا \fBg\fP باشد. .PP این گزینه فقط همراه با \fB--memory\fP قابل استفاده است. مقدار آرگومان باید همیشه بزرگتر از \fB--memory\fP باشد. پیش‌فرض دو برابر مقدار \fB--memory\fP است. برای فعال کردن swap نامحدود، مقدار را روی \fB-1\fP قرار دهید. .PP \fB--mac-address\fP="" نشانی MAC کانتینر (مثلاً \fB92:d0:c6:0a:29:33\fP) .PP به یاد داشته باشید که نشانی MAC در یک شبکه اترنت باید یکتا باشد. نشانی link-local از نوع IPv6 بر اساس نشانی MAC دستگاه مطابق با RFC4862 خواهد بود. .PP \fB--mount\fP \fBtype=\fP\fITYPE\fP,\fITYPE-SPECIFIC-OPTION\fP[,...] متصل کردن یک سوارشدن سیستم‌فایل به کانتینر .PP انواع سوارشدن (\fBTYPES\fR) پشتیبانی‌شده کنونی شامل \fBbind\fR، \fBvolume\fR و \fBtmpfs\fR هستند. .PP برای مثال: .PP \fBtype=bind,source=/path/on/host,destination=/path/in/container\fR .PP \fBtype=volume,source=my-volume,destination=/path/in/container,volume-label="color=red"\fR .PP \fBtype=tmpfs,tmpfs-size=512M,destination=/path/in/container\fR .PP گزینه‌های مشترک: .IP \(bu 2 \fBsrc\fR, \fBsource\fR: مشخصه منبع سوارشدن برای \fBbind\fR و \fBvolume\fR. برای \fBbind\fR اجباری است. .IP \(bu 2 \fBdst\fR, \fBdestination\fR, \fBtarget\fR: مشخصه مقصد سوارشدن. .IP \(bu 2 \fBro\fR, \fBreadonly\fR: به صورت \fBtrue\fR یا \fBfalse\fR (پیش‌فرض). .PP \fBنکته\fP: تنظیم \fBreadonly\fR برای یک bind mount بسته به نگارش کرنل ممکن است زیرمجموعه‌های آن را فقط‌خواندنی نکند. همچنین به \fBbind-recursive\fR مراجعه کنید. .PP گزینه‌های اختصاصی \fBbind\fR: .IP \(bu 2 \fBbind-propagation\fR: به صورت \fBshared\fR، \fBslave\fR، \fBprivate\fR، \fBrshared\fR، \fBrslave\fR یا \fBrprivate\fR (پیش‌فرض). همچنین به \fBmount(2)\fR مراجعه کنید. .IP \(bu 2 \fBconsistency\fR: به صورت \fBconsistent\fR (پیش‌فرض)، \fBcached\fR یا \fBdelegated\fR. در حال حاضر فقط برای Docker for Mac موثر است. .IP \(bu 2 \fBbind-recursive\fR: به صورت \fBenabled\fR (پیش‌فرض)، \fBdisabled\fR، \fBwritable\fR یا \fBreadonly\fR: اگر روی \fBenabled\fR تنظیم شود، زیرمجموعه‌ها به صورت بازگشتی bind mount شده و تلاش می‌شود به صورت بازگشتی فقط‌خواندنی شوند. اگر روی \fBdisabled\fR تنظیم شود، زیرمجموعه‌ها به صورت بازگشتی bind mount نمی‌شوند. اگر روی \fBwritable\fR تنظیم شود، زیرمجموعه‌ها به صورت بازگشتی bind mount شده اما فقط‌خواندنی نمی‌شوند. اگر روی \fBreadonly\fR تنظیم شود، زیرمجموعه‌ها به صورت بازگشتی bind mount شده و اجباراً به صورت بازگشتی فقط‌خواندنی می‌شوند. .PP گزینه‌های اختصاصی \fBvolume\fR: .IP \(bu 2 \fBvolume-driver\fR: نام پلاگین volume-driver. .IP \(bu 2 \fBvolume-label\fR: متاداده سفارشی. .IP \(bu 2 \fBvolume-nocopy\fR: به صورت \fBtrue\fR (پیش‌فرض) یا \fBfalse\fR. اگر روی \fBfalse\fR تنظیم شود، موتور داکر فایل‌ها و دایرکتوری‌های موجود زیر مسیر سوارشدن را به درون حجم کپی می‌کند و به میزبان اجازه دسترسی به آنها را می‌دهد. .IP \(bu 2 \fBvolume-opt\fR: مختص یک درایور حجم مشخص. .PP گزینه‌های اختصاصی \fBtmpfs\fR: .IP \(bu 2 \fBtmpfs-size\fR: اندازه سوارشدن tmpfs بر حسب بایت. به طور پیش‌فرض در لینوکس نامحدود است. .IP \(bu 2 \fBtmpfs-mode\fR: حالت فایل (file mode) مربوط به tmpfs در مبنای هشت (اکتال) (مانند \fB700\fR یا \fB0700\fR). در لینوکس به طور پیش‌فرض \fB1777\fR است. .PP \fB--name\fP="" تخصیص یک نام به کانتینر .PP مجری می‌تواند یک کانتینر را به سه روش شناسایی کند: .IP \(bu 2 \fBشناسه طولانی (long ID)\fP: \fBf78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778\fR .IP \(bu 2 \fBشناسه کوتاه (short ID)\fP: \fBf78375b1c487\fR .IP \(bu 2 \fBنام (Name)\fP: \fBevil_ptolemy\fR .PP شناسه‌ها از دیمن داکر می‌آیند، و اگر نامی با \fB--name\fP به کانتینر اختصاص داده نشود، دیمن یک نام رشته‌ای تصادفی تولید خواهد کرد. نام هنگام تعریف پیوندها (به \fB--link\fP مراجعه کنید) (یا هر جای دیگری که نیاز به شناسایی کانتینر دارید) مفید است. این قابلیت هم برای کانتینرهای پس‌زمینه و هم پیش‌زمینه داکر کار می‌کند. .PP \fB--network\fP=\fItype\fP تنظیم حالت شبکه برای کانتینر. مقادیر پشتیبانی‌شده عبارتند از: .TS allbox; l l l l . \fBمقدار\fP \fBشرح\fP \fBnone\fP T{ عدم وجود شبکه در کانتینر. T} \fBbridge\fP T{ اتصال کانتینر به پل پیش‌فرض داکر از طریق رابط‌های veth. T} \fBhost\fP T{ استفاده از پشته شبکه میزبان درون کانتینر. T} \fBcontainer:\fP\fIname\fP|\fIid\fP T{ استفاده از پشته شبکه کانتینری دیگر، که با \fIname\fP یا \fIid\fP آن مشخص می‌شود. T} \fInetwork-name\fP|\fInetwork-id\fP T{ اتصال کانتینر به شبکه ایجادشده توسط کاربر (با دستور \fBdocker network create\fR). T} .TE .PP پیش‌فرض \fBbridge\fP است. .PP \fB--network-alias\fP=[] افزودن نام مستعار در حوزه شبکه برای کانتینر .PP \fB--oom-kill-disable\fP=\fItrue\fP|\fIfalse\fP غیرفعال کردن یا نکردن OOM Killer برای کانتینر. .PP \fB--oom-score-adj\fP="" تنظیم ترجیحات OOM میزبان برای کانتینرها (مقداری بین -1000 تا 1000 می‌پذیرد) .PP \fB-P\fP, \fB--publish-all\fP=\fItrue\fP|\fIfalse\fP انتشار تمامی درگاه‌های اکسپوز شده به درگاه‌های تصادفی در رابط‌های میزبان. پیش‌فرض \fIfalse\fP است. .PP در صورت تنظیم روی true، تمام درگاه‌های اکسپوز شده را روی رابط‌های میزبان منتشر می‌کند. پیش‌فرض false است. اگر کاربر از -P (یا -p) استفاده کند، داکر درگاه اکسپوز شده را روی میزبان قابل دسترسی می‌سازد و درگاه‌ها برای هر کلاینتی که بتواند به میزبان برسد در دسترس خواهند بود. هنگام استفاده از -P، داکر هر درگاه اکسپوز شده را به یک درگاه تصادفی روی میزبان درون یک \fIمحدوده درگاه زودگذر (ephemeral port range)\fP که توسط \fB/proc/sys/net/ipv4/ip_local_port_range\fR تعریف شده متصل می‌کند. برای یافتن نگاشت میان درگاه‌های میزبان و درگاه‌های اکسپوز شده، از \fBdocker port\fR(1) استفاده کنید. .PP \fB-p\fP, \fB--publish\fP \fIip\fP:[\fIhostPort\fP]:\fIcontainerPort\fP | [\fIhostPort\fP:]\fIcontainerPort\fP انتشار درگاه یا محدوده‌ای از درگاه‌های کانتینر روی میزبان. .PP هر دو مقدار \fIhostPort\fP و \fIcontainerPort\fP می‌توانند به صورت یک محدوده مشخص شوند. هنگام تعیین محدوده برای هر دو، تعداد درگاه‌ها در هر دو محدوده باید برابر باشد. .PP مثال‌ها: \fB-p 1234-1236:1222-1224\fP، \fB-p 127.0.0.1:$HOSTPORT:$CONTAINERPORT\fP. .PP از \fBdocker port\fR(1) برای مشاهده نگاشت واقعی استفاده کنید، مثلاً \fBdocker port CONTAINER $CONTAINERPORT\fR. .PP \fB--pid\fP="" تنظیم حالت PID برای کانتینر پیش‌فرض ایجاد یک فضای‌نام PID اختصاصی برای کانتینر است 'container:\&': پیوستن به فضای‌نام PID کانتینر دیگر 'host': استفاده از فضای‌نام PID میزبان برای کانتینر. نکته: حالت host به کانتینر دسترسی کامل به PID محلی می‌دهد و بنابراین ناامن تلقی می‌شود. .PP \fB--userns\fP="" تنظیم حالت usernamespace برای کانتینر در زمانی که گزینه \fBuserns-remap\fR فعال است. \fBhost\fP: استفاده از فضای‌نام کاربری میزبان و فعال‌سازی تمامی گزینه‌های با دسترسی بالا (مانند \fBpid=host\fR یا \fB--privileged\fR). .PP \fB--pids-limit\fP="" تنظیم محدودیت تعداد شناسه پردازش‌های کانتینر (pids). مقدار را روی \fB-1\fR تنظیم کنید تا کانتینر بدون محدودیت pid باشد. .PP \fB--uts\fP=\fItype\fP تنظیم حالت UTS برای کانتینر. تنها \fItype\fP ممکن \fBhost\fP است، به معنای استفاده از فضای‌نام UTS میزبان درون کانتینر. .PP نکته: حالت host به کانتینر امکان دسترسی برای تغییر نام میزبانِ سیستم میزبان را می‌دهد و به همین دلیل ناامن در نظر گرفته می‌شود. .PP \fB--privileged\fP [\fBtrue\fP|\fBfalse\fP] اعطای امتیازات گسترده به این کانتینر. به یک کانتینر دارای امتیاز (privileged)، دسترسی به تمام دستگاه‌ها داده می‌شود. .PP هنگامی که مجری دستور \fBdocker run --privileged\fP را اجرا می‌کند، داکر دسترسی به تمامی دستگاه‌های روی میزبان را فعال کرده و همچنین پیکربندی‌هایی در AppArmor اعمال می‌کند تا به کانتینر تقریباً همان دسترسی‌هایی داده شود که پردازش‌های در حال اجرا در خارج از کانتینر روی میزبان دارند. .PP \fB--read-only\fP=\fBtrue\fP|\fBfalse\fP سوار کردن فایل‌سیستم ریشه کانتینر به صورت فقط‌خواندنی. .PP به طور پیش‌فرض فایل‌سیستم ریشه کانتینر قابل‌نوشتن است که به پردازش‌ها اجازه می‌دهد در هر جایی فایل بنویسند. با تعیین فلگ \fB--read-only\fR فایل‌سیستم ریشه کانتینر به صورت فقط‌خواندنی سوار شده و هرگونه نوشتن ممنوع می‌گردد. .PP \fB--restart\fP \fIpolicy\fP سیاست راه‌اندازی مجدد برای اعمال هنگام خروج کانتینر. مقادیر پشتیبانی‌شده عبارتند از: .TS allbox; l l l l . \fBسیاست\fP \fBنتیجه\fP \fBno\fP T{ هنگام خروج کانتینر، آن را به طور خودکار دوباره راه‌اندازی نکن. T} \fBon-failure\fP[:\fImax-retries\fP] T{ راه‌اندازی مجدد تنها در صورتی که کانتینر با وضعیت غیرصفر خارج شود. به صورت اختیاری، تعداد تلاش‌های مجدد دیمن داکر را محدود کنید. T} \fBalways\fP T{ صرف‌نظر از وضعیت خروج، همیشه کانتینر را دوباره راه‌اندازی کن. هنگامی که always را تعیین می‌کنید، دیمن داکر سعی می‌کند کانتینر را برای همیشه دوباره راه‌اندازی کند. کانتینر بدون در نظر گرفتن وضعیت فعلی آن، همیشه هنگام بالا آمدن دیمن آغاز به کار می‌کند. T} \fBunless-stopped\fP T{ همیشه کانتینر را بدون در نظر گرفتن وضعیت خروج دوباره راه‌اندازی کن، اما اگر کانتینر قبلاً در وضعیت متوقف قرار گرفته باشد، هنگام بالا آمدن دیمن آن را آغاز نکن. T} .TE .PP پیش‌فرض \fBno\fP است. .PP \fB--rm\fP \fBtrue\fP|\fBfalse\fP حذف خودکار کانتینر و حجم‌های ناشناس وابسته به آن هنگام خروج. پیش‌فرض \fBfalse\fP است. فلگ \fB--rm\fR می‌تواند همراه با \fB-d\fR کار کند و حذف خودکار در سمت دیمن انجام خواهد شد. توجه داشته باشید که این گزینه با هر سیاست راه‌اندازی مجددی به جز \fBnone\fR ناسازگار است. .PP \fB--security-opt\fP \fIvalue\fP[,...] گزینه‌های امنیتی برای کانتینر. گزینه‌های زیر می‌توانند ارائه شوند: .TS allbox; l l l l . \fBگزینه\fP \fBشرح\fP "label=user:USER" T{ تنظیم برچسب کاربر برای کانتینر T} "label=role:ROLE" T{ تنظیم برچسب نقش برای کانتینر T} "label=type:TYPE" T{ تنظیم برچسب نوع برای کانتینر T} "label=level:LEVEL" T{ تنظیم برچسب سطح برای کانتینر T} "label=disable" T{ غیرفعال کردن محدودیت برچسب برای کانتینر T} "no-new-privileges" T{ جلوگیری از کسب امتیازات اضافی توسط پردازش‌های کانتینر T} "seccomp=unconfined" T{ غیرفعال کردن محدودیت seccomp برای کانتینر T} "seccomp=profile.json" T{ فایل Json فیلتر seccomp با فراخوانی‌های سیستمی مجاز T} "apparmor=unconfined" T{ غیرفعال کردن محدودیت apparmor برای کانتینر T} "apparmor=your-profile" T{ تنظیم نمایه محدودیت apparmor برای کانتینر T} .TE .PP \fB--storage-opt\fP گزینه‌های درایور فضای ذخیره‌سازی برای هر کانتینر .PP $ docker run -it --storage-opt size=120G fedora /bin/bash .PP این گزینه (size) اجازه می‌دهد اندازه rootfs کانتینر در زمان ایجاد روی 120G تنظیم شود. این گزینه فقط برای درایورهای گراف \fBbtrfs\fR، \fBoverlay2\fR و \fBzfs\fR در دسترس است. برای درایورهای ذخیره‌سازی \fBbtrfs\fR و \fBzfs\fR، کاربر نمی‌تواند اندازه‌ای کمتر از Default BaseFS Size تعیین کند. برای درایور ذخیره‌سازی \fBoverlay2\fR، گزینه size تنها در صورتی در دسترس است که سیستم‌فایل زیرین \fBxfs\fR بوده و با گزینه \fBpquota\fR سوار شده باشد. تحت این شرایط، کاربر می‌تواند هر اندازه‌ای کمتر از اندازه سیستم‌فایل زیرین را وارد نماید. .PP \fB--stop-signal\fP="" سیگنال توقف کانتینر. .PP فلگ \fB--stop-signal\fR سیگنال فراخوانی سیستمی را که برای خروج به کانتینر ارسال می‌شود تنظیم می‌کند. این سیگنال می‌تواند یک نام سیگنال با قالب \fBSIG\fR باشد، برای مثال \fBSIGKILL\fR، یا یک عدد نامنفی که مطابق با موقعیتی در جدول syscall کرنل است، برای مثال \fB9\fR. .PP پیش‌فرض توسط \fBSTOPSIGNAL\fR در ایمیج تعیین می‌شود، یا اگر در ایمیج هیچ \fBSTOPSIGNAL\fR تعریف نشده باشد، \fBSIGTERM\fR خواهد بود. .PP \fB--stop-timeout\fP مدت‌زمان انتظار (بر حسب ثانیه) برای توقف کانتینر، یا \fB-1\fP برای غیرفعال کردن مهلت زمانی. .PP فلگ \fB--stop-timeout\fR تعداد ثانیه‌های انتظار برای توقف کانتینر پس از ارسال سیگنال فراخوانی سیستمی از پیش تعریف‌شده (به \fB--stop-signal\fR مراجعه کنید) را تنظیم می‌کند. اگر کانتینر پس از پایان این مهلت خارج نشود، با ارسال سیگنال \fBSIGKILL\fR به اجبار متوقف می‌شود. .PP اگر \fB--stop-timeout\fR روی \fB-1\fP تنظیم شود، هیچ مهلت زمانی اعمال نشده و دیمن برای همیشه منتظر خروج کانتینر خواهد ماند. .PP مقدار پیش‌فرض توسط دیمن تعیین می‌شود که ۱۰ ثانیه برای کانتینرهای لینوکس و ۳۰ ثانیه برای کانتینرهای ویندوز است. .PP \fB--shm-size\fP="" اندازه \fB/dev/shm\fR. قالب به صورت \fB\fR است. مقدار \fBnumber\fR باید بزرگتر از \fB0\fR باشد. واحد اختیاری است و می‌تواند \fBb\fR (بایت)، \fBk\fR (کیلوبایت)، \fBm\fR (مگابایت) یا \fBg\fR (گیگابایت) باشد. اگر واحد را حذف کنید، سیستم از بایت استفاده می‌کند. اگر مقدار اندازه را کلاً حذف کنید، سیستم از \fB64m\fR استفاده می‌کند. .PP \fB--sysctl\fP=SYSCTL پیکربندی پارامترهای کرنل دارای فضای‌نام در زمان اجرا .PP فضای‌نام IPC - مقادیر مجاز کنونی sysctl: .PP kernel.msgmax, kernel.msgmnb, kernel.msgmni, kernel.sem, kernel.shmall, kernel.shmmax, kernel.shmmni, kernel.shm_rmid_forced, and sysctls beginning with fs.mqueue.* .PP اگر از گزینه \fB--ipc=host\fR استفاده کنید این sysctlها مجاز نخواهند بود. .PP فضای‌نام شبکه - مقادیر مجاز کنونی sysctl: Sysctls beginning with net.* .PP اگر از گزینه \fB--network=host\fR استفاده کنید این sysctlها مجاز نخواهند بود. .PP \fB--sig-proxy\fP=\fItrue\fP|\fIfalse\fP انتقال سیگنال‌های دریافتی به پردازش (فقط در حالت غیر-TTY). سیگنال‌های SIGCHLD، SIGSTOP و SIGKILL هدایت نمی‌شوند. مقدار پیش‌فرض \fItrue\fP است. .PP \fB--memory-swappiness\fP="" تنظیم رفتار swappiness حافظه کانتینر. عددی صحیح بین 0 تا 100 می‌پذیرد. .PP \fB-t\fP, \fB--tty\fP=\fItrue\fP|\fIfalse\fP اختصاص یک شبه-TTY. مقدار پیش‌فرض \fIfalse\fP است. .PP هنگامی که روی true تنظیم شود، داکر می‌تواند یک pseudo-tty تخصیص داده و به ورودی استاندارد هر کانتینری متصل شود. این مورد می‌تواند مثلاً برای اجرای یک پوسته تعاملی یک‌بارمصرف استفاده شود. مقدار پیش‌فرض false است. .PP گزینه \fB-t\fP با تغییر مسیر (redirection) ورودی استاندارد کلاینت داکر ناسازگار است. .PP \fB--tmpfs\fP=[] ایجاد یک سوارشدن tmpfs .PP سوار کردن یک سیستم‌فایل موقت (\fBtmpfs\fR) در داخل کانتینر، برای مثال: .PP $ docker run -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image .PP این دستور یک \fBtmpfs\fR را در مسیر \fB/tmp\fR درون کانتینر سوار می‌کند. گزینه‌های پشتیبانی‌شده همان فلگ‌های پیش‌فرض \fBmount\fR لینوکس هستند. اگر هیچ گزینه‌ای تعیین نکنید، سیستم از گزینه‌های روبرو استفاده می‌کند: \fBrw,noexec,nosuid,nodev,size=65536k\fR. .PP همچنین به \fB--mount\fR مراجعه کنید که جانشین \fB--tmpfs\fR و \fB--volume\fR است. اگرچه برنامه‌ای برای منسوخ کردن \fB--tmpfs\fR وجود ندارد، استفاده از \fB--mount\fR توصیه می‌شود. .PP \fB-u\fP, \fB--user\fP="" تنظیم نام کاربری یا UID مورد استفاده و به صورت اختیاری نام گروه یا GID برای دستور مشخص‌شده. .PP مثال‌های زیر همگی معتبر هستند: --user [user | user:group | uid | uid:gid | user:gid | uid:group ] .PP بدون این آرگومان، دستور با دسترسی ریشه (root) در کانتینر اجرا خواهد شد. .PP \fB--ulimit\fP=[] گزینه‌های Ulimit .PP \fB-v\fP|\fB--volume\fP[=\fI[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]\fP] ایجاد یک bind mount. اگر \fB-v /HOST-DIR:/CONTAINER-DIR\fR را مشخص کنید، داکر مسیر \fB/HOST-DIR\fR در میزبان را به \fB/CONTAINER-DIR\fR در کانتینر داکر bind mount می‌کند. اگر 'HOST-DIR' حذف شود، داکر به طور خودکار حجم جدید را روی میزبان ایجاد می‌کند. بخش \fBOPTIONS\fR فهرستی با جداکننده کاما است و می‌تواند شامل موارد زیر باشد: .IP \(bu 2 [rw|ro] .IP \(bu 2 [z|Z] .IP \(bu 2 [\fB[r]shared\fR|\fB[r]slave\fR|\fB[r]private\fR] .IP \(bu 2 [\fBdelegated\fR|\fBcached\fR|\fBconsistent\fR] .IP \(bu 2 [nocopy] .PP مقدار \fBCONTAINER-DIR\fR باید یک مسیر مطلق مانند \fB/src/docs\fR باشد. مقدار \fBHOST-DIR\fR می‌تواند یک مسیر مطلق یا یک مقدار \fBname\fR باشد. مقدار \fBname\fR باید با یک کاراکتر حرفی-عددی شروع شود و در ادامه می‌تواند شامل \fBa-z0-9\fR، \fB_\fR (خط زیرین)، \fB\&.\fR (نقطه) یا \fB-\fR (خط تیره) باشد. یک مسیر مطلق با \fB/\fR (اسلش) شروع می‌شود. .PP اگر یک \fBHOST-DIR\fR ارائه دهید که یک مسیر مطلق باشد، داکر به مسیری که مشخص کرده‌اید bind-mount انجام می‌دهد. اگر یک \fBname\fR وارد کنید، داکر یک حجم نام‌گذاری‌شده با آن \fBname\fR ایجاد می‌کند. برای مثال، می‌توانید \fB/foo\fR یا \fBfoo\fR را برای مقدار \fBHOST-DIR\fR مشخص کنید. اگر مقدار \fB/foo\fR را بدهید، داکر یک bind mount ایجاد می‌کند. اگر مقدار \fBfoo\fR را وارد کنید، داکر یک حجم نام‌گذاری‌شده می‌سازد. .PP می‌توانید چندین گزینه \fB-v\fP برای سوار کردن یک یا چند حجم در یک کانتینر مشخص کنید. برای استفاده از همین موارد در کانتینرهای دیگر، گزینه \fB--volumes-from\fP را نیز مشخص نمایید. .PP می‌توانید گزینه‌های بیشتری را برای هر bind mount پس از یک دونقطه دیگر مشخص کنید. پسوند \fB:ro\fR یا \fB:rw\fR حجم را به ترتیب در حالت فقط‌خواندنی یا خواندن-نوشتن سوار می‌کند. به طور پیش‌فرض، حجم‌ها در حالت خواندن-نوشتن سوار می‌شوند. همچنین می‌توانید الزامات سازگاری سوارشدن را مشخص کنید: \fB:consistent\fR (پیش‌فرض)، \fB:cached\fR یا \fB:delegated\fR. گزینه‌های متعدد با کاما از هم جدا می‌شوند، مثلاً \fB:ro,cached\fR. .PP سیستم‌های برچسب‌گذاری مانند SELinux نیاز دارند که برچسب‌های مناسب روی محتوای حجمِ سوارشده در کانتینر قرار گیرند. بدون برچسب، سیستم امنیتی ممکن است از استفاده پردازش‌های درون کانتینر از محتوا جلوگیری کند. به طور پیش‌فرض، داکر برچسب‌های تنظیم‌شده توسط سیستم‌عامل را تغییر نمی‌دهد. .PP برای تغییر دادن برچسب در بافت کانتینر، می‌توانید یکی از دو پسوند \fB:z\fR یا \fB:Z\fR را به سوارشدن حجم اضافه کنید. این پسوندها به داکر می‌گویند اشیای فایلی موجود در حجم‌های اشتراکی را مجدداً برچسب‌گذاری کند. گزینه \fBz\fR به داکر می‌گوید که دو کانتینر محتوای حجم را به اشتراک می‌گذارند. در نتیجه، داکر محتوا را با یک برچسب محتوای اشتراکی برچسب‌گذاری می‌کند. برچسب‌های حجم اشتراکی به تمام کانتینرها اجازه خواندن/نوشتن محتوا را می‌دهند. گزینه \fBZ\fR به داکر می‌گوید که محتوا را با یک برچسب اختصاصی غیرقابل‌اشتراک برچسب‌گذاری کند. تنها کانتینر فعلی می‌تواند از یک حجم اختصاصی استفاده کند. .PP به طور پیش‌فرض حجم‌های bind mount شده از نوع \fBprivate\fR هستند. این بدان معناست که هر سوارشدنی در داخل کانتینر روی میزبان قابل مشاهده نخواهد بود و بالعکس. می‌توان این رفتار را با تعیین ویژگی انتشار سوارشدن حجم (volume mount propagation) تغییر داد. تنظیم یک حجم به صورت \fBshared\fR باعث می‌شود سوارشدن‌های انجام‌شده زیر آن حجم در کانتینر، روی میزبان قابل مشاهده باشند و بالعکس. تنظیم حجم به صورت \fBslave\fR تنها انتشار یک‌طرفه را فعال می‌کند، به این معنی که سوارشدن‌های انجام‌شده روی میزبان زیر آن حجم در داخل کانتینر قابل مشاهده خواهند بود اما عکس آن صادق نیست. .PP برای کنترل ویژگی انتشار حجم می‌توان از فلگ‌های انتشار \fB:[r]shared\fR، \fB:[r]slave\fR یا \fB:[r]private\fR استفاده کرد. ویژگی انتشار تنها برای حجم‌های bind mount شده قابل تعیین است و نه برای حجم‌های داخلی یا حجم‌های نام‌گذاری‌شده. برای کارکرد صحیح انتشار، نقطه سوارشدن منبع (نقطه‌ای که دایرکتوری منبع روی آن سوار است) باید ویژگی‌های انتشار درستی داشته باشد. برای حجم‌های اشتراکی، نقطه سوارشدن منبع باید shared باشد. و برای حجم‌های slave، نقطه منبع باید shared یا slave باشد. .PP از دستور \fBdf \fR برای پیدا کردن نقطه سوارشدن منبع و سپس از دستور \fBfindmnt -o TARGET,PROPAGATION \fR برای مشاهده ویژگی‌های انتشار نقطه سوارشدن منبع استفاده کنید. اگر ابزار \fBfindmnt\fR در دسترس نیست، می‌توانید به ورودی سوارشدن برای نقطه منبع در \fB/proc/self/mountinfo\fR نگاه کنید. بخش \fBoptional fields\fR را بررسی کنید تا ببینید آیا هیچ ویژگی انتشاری مشخص شده است یا خیر. مقدار \fBshared:X\fR یعنی نقطه سوارشدن \fBshared\fR است، \fBmaster:X\fR یعنی \fBslave\fR است و اگر چیزی نباشد یعنی نقطه سوارشدن \fBprivate\fR است. .PP برای تغییر دادن ویژگی‌های انتشار یک نقطه سوارشدن از دستور \fBmount\fR استفاده کنید. برای مثال، اگر کسی بخواهد دایرکتوری منبع \fB/foo\fR را bind mount کند می‌تواند دستورات \fBmount --bind /foo /foo\fR و \fBmount --make-private --make-shared /foo\fR را اجرا نماید. این کار /foo را به یک نقطه سوارشدن \fBshared\fR تبدیل می‌کند. متناوباً می‌توان مستقیماً ویژگی‌های نقطه منبع را تغییر داد. فرض کنید \fB/\fR نقطه منبع برای \fB/foo\fR است، در این صورت از \fBmount --make-shared /\fR برای تبدیل \fB/\fR به یک نقطه سوارشدن \fBshared\fR استفاده کنید. .PP .RS .PP \fBنکته\fP: هنگام استفاده از systemd برای مدیریت شروع و توقف دیمن داکر، در فایل واحد systemd گزینه‌ای برای کنترل انتشار سوارشدن برای خود دیمن داکر وجود دارد که \fBMountFlags\fR نامیده می‌شود. مقدار این تنظیم ممکن است باعث شود داکر تغییرات انتشار سوارشدن ایجادشده روی نقطه سوارشدن را نبیند. برای مثال، اگر این مقدار \fBslave\fR باشد، ممکن است نتوانید از انتشار \fBshared\fR یا \fBrshared\fR روی یک حجم استفاده کنید. .RE .PP برای غیرفعال کردن کپی خودکار داده‌ها از مسیر کانتینر به حجم، از فلگ \fBnocopy\fR استفاده کنید. فلگ \fBnocopy\fR را می‌توان روی bind mountها و حجم‌های نام‌گذاری‌شده تنظیم کرد. .PP همچنین به \fB--mount\fR مراجعه کنید که جانشین \fB--tmpfs\fR و \fB--volume\fR است. اگرچه برنامه‌ای برای منسوخ کردن \fB--volume\fR وجود ندارد، استفاده از \fB--mount\fR توصیه می‌شود. .PP \fB--volume-driver\fP="" درایور حجم کانتینر. این درایور حجم‌هایی را ایجاد می‌کند که از دستورالعمل \fBVOLUME\fR در Dockerfile یا از فلگ \fBdocker run -v\fR مشخص شده‌اند. برای جزئیات کامل به \fBdocker-volume-create(1)\fP مراجعه کنید. .PP \fB--volumes-from\fP=[] سوار کردن حجم‌ها از کانتینر (یا کانتینرهای) مشخص‌شده .PP حجم‌های قبلاً سوارشده از یک کانتینر منبع را روی یک کانتینر دیگر سوار می‌کند. باید شناسه کانتینر منبع را وارد کنید. برای اشتراک‌گذاری یک حجم، هنگام اجرای کانتینر هدف از گزینه \fB--volumes-from\fP استفاده کنید. حتی اگر کانتینر منبع در حال اجرا نباشد نیز می‌توانید حجم‌ها را به اشتراک بگذارید. .PP به طور پیش‌فرض، داکر حجم‌ها را در همان حالتی سوار می‌کند (خواندن-نوشتن یا فقط‌خواندنی) که در کانتینر منبع سوار شده بودند. به صورت اختیاری، می‌توانید این وضعیت را با افزودن کلمه کلیدی \fB:ro\fR یا \fB:rw\fR به انتهای شناسه کانتینر تغییر دهید. .PP اگر محل حجم از کانتینر منبع با داده‌های موجود در کانتینر مقصد هم‌پوشانی داشته باشد، حجم آن داده‌ها را در کانتینر مقصد پنهان می‌کند. .PP \fB-w\fP, \fB--workdir\fP="" دایرکتوری کاری درون کانتینر .PP دایرکتوری کاری پیش‌فرض برای اجرای فایل‌های باینری درون کانتینر، دایرکتوری ریشه (/) است. توسعه‌دهنده می‌تواند با دستورالعمل WORKDIR در Dockerfile یک پیش‌فرض متفاوت تنظیم کند. مدیر می‌تواند با استفاده از گزینه \fB-w\fP دایرکتوری کاری را بازنویسی نماید. .SH "وضعیت خروج (EXIT STATUS)" کد خروج از \fBdocker run\fR اطلاعاتی درباره دلیل عدم موفقیت در اجرای کانتینر یا دلیل خروج آن ارائه می‌دهد. هنگامی که \fBdocker run\fR با کدی غیرصفر خارج می‌شود، کدهای خروج از استاندارد \fBchroot\fR پیروی می‌کنند، به شرح زیر: .PP \fB\fI125\fP\fP اگر خطا از سمت خود دیمن داکر (\fB\fIitself\fP\fP) باشد .EX $ docker run --foo busybox; echo $? # flag provided but not defined: --foo See 'docker run --help'. 125 .EE .PP \fB\fI126\fP\fP اگر دستور درون کانتینر (\fB\fIcontained command\fP\fP) قابل فراخوانی نباشد .EX $ docker run busybox /etc; echo $? # exec: "/etc": permission denied docker: Error response from daemon: Contained command could not be invoked 126 .EE .PP \fB\fI127\fP\fP اگر دستور درون کانتینر (\fB\fIcontained command\fP\fP) یافت نشود .EX $ docker run busybox foo; echo $? # exec: "foo": executable file not found in $PATH docker: Error response from daemon: Contained command not found or does not exist 127 .EE .PP در غیر این صورت، \fB\fIکد خروج\fP\fP مربوط به دستور درون کانتینر (\fB\fIcontained command\fP\fP) بازگردانده می‌شود .EX $ docker run busybox /bin/sh -c 'exit 3' # 3 .EE .SH "مثال‌ها (EXAMPLES)" .SH "اجرای کانتینر در حالت فقط‌خواندنی (Running container in read-only mode)" در طول توسعه ایمیج کانتینر، کانتینرها اغلب نیاز دارند در محتوای ایمیج بنویسند؛ برای مثال نصب بسته‌ها در usr/. در محیط عملیاتی (production)، برنامه‌ها به ندرت نیاز به نوشتن در ایمیج دارند. برنامه‌های درون کانتینر اگر اصلاً نیاز به نوشتن در سیستم‌فایل داشته باشند، درون حجم‌ها (volumes) می‌نویسند. با اجرای برنامه‌ها در حالت فقط‌خواندنی با استفاده از فلگ --read-only می‌توان امنیت آنها را افزایش داد. این کار از تغییر ایمیج کانتینرها محافظت می‌کند. کانتینرهای فقط‌خواندنی ممکن است همچنان نیاز به نوشتن داده‌های موقت داشته باشند. بهترین راه برای مدیریت این مورد، سوار کردن دایرکتوری‌های tmpfs روی run/ و tmp/ است. .EX # docker run --read-only --tmpfs /run --tmpfs /tmp -i -t fedora /bin/bash .EE .SH "هدایت پیام‌های گزارش از کانتینر به گزارش‌های میزبان (Exposing log messages from the container to the host's log)" اگر می‌خواهید پیام‌هایی که در کانتینر شما لاگ می‌شوند در syslog/journal میزبان نمایش داده شوند، باید دایرکتوری dev/log/ را به صورت bind mount مطابق زیر سوار کنید: .EX # docker run -v /dev/log:/dev/log -i -t fedora /bin/bash .EE .PP از داخل کانتینر می‌توانید این مورد را با ارسال یک پیام به لاگ آزمایش کنید: .EX (bash)# logger "Hello from my container" .EE .PP سپس خارج شوید و journal را بررسی نمایید: .EX # exit # journalctl -b | grep Hello .EE .PP این دستور باید پیامی را که به logger ارسال شده بود فهرست کند. .SH "اتصال به یک یا چند مورد از STDIN، STDOUT، STDERR (Attaching to one or more from STDIN, STDOUT, STDERR)" اگر گزینه -a را مشخص نکنید داکر همه چیز (stdin,stdout,stderr) را متصل می‌کند. می‌توانید مشخص کنید که در عوض می‌خواهید به کدام یک از سه جریان استاندارد متصل شوید، مانند: .EX # docker run -a stdin -a stdout -i -t fedora /bin/bash .EE .SH "اشتراک‌گذاری IPC میان کانتینرها (Sharing IPC between containers)" با استفاده از shm_server.c موجود در: https://www.cs.cf.ac.uk/Dave/C/node27.html .PP آزمایش حالت \fB--ipc=host\fR: .PP میزبان یک بخش حافظه اشتراکی با ۷ پردازش متصل را نشان می‌دهد، که متعلق به httpd است: .EX $ sudo ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x01128e25 0 root 600 1000 7 .EE .PP حال یک کانتینر معمولی را اجرا کنید؛ این کانتینر به درستی بخش حافظه اشتراکی میزبان را نمی‌بیند: .EX $ docker run -it shm ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status .EE .PP یک کانتینر با گزینه جدید \fB--ipc=host\fR اجرا کنید، اکنون بخش حافظه اشتراکی میزبان از httpd را می‌بیند: .EX $ docker run -it --ipc=host shm ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x01128e25 0 root 600 1000 7 .EE .PP آزمایش حالت \fB--ipc=container:CONTAINERID\fR: .PP شروع یک کانتینر همراه با برنامه‌ای برای ایجاد یک بخش حافظه اشتراکی: .EX $ docker run -it shm bash $ sudo shm/shm_server & $ sudo ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x0000162e 0 root 666 27 1 .EE .PP ایجاد یک کانتینر دوم به درستی نشان می‌دهد که هیچ بخش حافظه اشتراکی از کانتینر اول دیده نمی‌شود: .EX $ docker run shm ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status .EE .PP ایجاد کانتینر سوم با استفاده از گزینه جدید --ipc=container:CONTAINERID؛ اکنون بخش حافظه اشتراکی کانتینر اول را نشان می‌دهد: .EX $ docker run -it --ipc=container:ed735b2264ac shm ipcs -m $ sudo ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x0000162e 0 root 666 27 1 .EE .SH "پیوند دادن کانتینرها (Linking Containers)" .PP .RS .PP \fBنکته\fP: این بخش پیوند میان کانتینرها روی شبکه پیش‌فرض (bridge) را شرح می‌دهد، که به عنوان "پیوندهای سنتی (legacy links)" نیز شناخته می‌شود. استفاده از \fB--link\fR روی شبکه‌های تعریف‌شده توسط کاربر از کشف مبتنی بر DNS استفاده می‌کند، که ورودی‌هایی به \fB/etc/hosts\fR اضافه نمی‌کند و متغیرهای محیطی برای کشف تنظیم نمی‌نماید. .RE .PP قابلیت link به چندین کانتینر اجازه می‌دهد با یکدیگر ارتباط برقرار کنند. برای مثال، کانتینری که در Dockerfile آن درگاه 80 اکسپوز شده است می‌تواند به صورت زیر اجرا و نام‌گذاری شود: .EX # docker run --name=link-test -d -i -t fedora/httpd .EE .PP کانتینر دومی که در این مورد linker نامیده می‌شود، می‌تواند با استفاده از \fB--link=:\fP با کانتینر httpd با نام link-test ارتباط برقرار کند: .EX # docker run -t -i --link=link-test:lt --name=linker fedora /bin/bash .EE .PP اکنون کانتینر linker با نام مستعار lt به کانتینر link-test پیوند داده شده است. اجرای دستور \fBenv\fP در کانتینر linker متغیرهای محیطی با پیشوند LT (نام مستعار) (\fBLT_\fP) را نمایش می‌دهد: .EX # env HOSTNAME=668231cb0978 TERM=xterm LT_PORT_80_TCP=tcp://172.17.0.3:80 LT_PORT_80_TCP_PORT=80 LT_PORT_80_TCP_PROTO=tcp LT_PORT=tcp://172.17.0.3:80 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/ LT_NAME=/linker/lt SHLVL=1 HOME=/ LT_PORT_80_TCP_ADDR=172.17.0.3 _=/usr/bin/env .EE .PP هنگام پیوند دادن دو کانتینر، داکر از درگاه‌های اکسپوز شده کانتینر برای ایجاد یک تونل امن جهت دسترسی والد استفاده می‌کند. .PP اگر یک کانتینر به شبکه پل (bridge) پیش‌فرض متصل باشد و با کانتینرهای دیگر \fBlinked\fR شده باشد، فایل \fB/etc/hosts\fR کانتینر با نام کانتینر پیوندیافته به‌روزرسانی می‌شود. .PP .RS .PP \fBنکته\fP: از آنجا که ممکن است داکر فایل \fB/etc/hosts\fR کانتینر را به صورت زنده به‌روزرسانی کند، ممکن است شرایطی پیش بیاید که پردازش‌های درون کانتینر یک فایل \fB/etc/hosts\fR خالی یا ناقص را بخوانند. در اغلب موارد، تلاش مجدد برای خواندن باید مشکل را برطرف کند. .RE .SH "نگاشت درگاه‌ها برای استفاده خارجی (Mapping Ports for External Usage)" درگاه اکسپوز شده یک برنامه می‌تواند با استفاده از فلگ \fB-p\fP به یک درگاه میزبان نگاشت شود. برای مثال، درگاه 80 مربوط به httpd می‌تواند با استفاده از دستور زیر به درگاه 8080 میزبان نگاشت شود: .EX # docker run -p 8080:80 -d -i -t fedora/httpd .EE .SH "ایجاد و سوار کردن کانتینر داده (Creating and Mounting a Data Volume Container)" بسیاری از برنامه‌ها نیاز به اشتراک‌گذاری داده‌های ماندگار در میان چندین کانتینر دارند. داکر به شما اجازه می‌دهد یک Data Volume Container ایجاد کنید که سایر کانتینرها بتوانند از آن سوار شوند. برای مثال، یک کانتینر نام‌گذاری‌شده ایجاد کنید که شامل دایرکتوری‌های var/volume1/ و tmp/volume2/ باشد. ایمیج باید شامل این دایرکتوری‌ها باشد بنابراین ممکن است چند دستور RUN mkdir برای ایمیج fedora-data نیاز باشد: .EX # docker run --name=data -v /var/volume1 -v /tmp/volume2 -i -t fedora-data true # docker run --volumes-from=data --name=fedora-container1 -i -t fedora bash .EE .PP پارامترهای چندگانه --volumes-from چندین حجم داده را از چندین کانتینر گرد هم می‌آورد. و امکان سوار کردن حجم‌هایی که از کانتینر DATA آمده‌اند در یک کانتینر دیگر از طریق کانتینر واسط fedora-container1 وجود دارد، که امکان تفکیک منبع داده واقعی از کاربران آن داده را فراهم می‌سازد: .EX # docker run --volumes-from=fedora-container1 --name=fedora-container2 -i -t fedora bash .EE .SH "سوار کردن حجم‌های خارجی (Mounting External Volumes)" برای سوار کردن یک دایرکتوری میزبان به عنوان حجم کانتینر، مسیر مطلق دایرکتوری و مسیر مطلق دایرکتوری کانتینر را که با دونقطه از هم جدا شده‌اند مشخص کنید: .EX # docker run -v /var/db:/data1 -i -t fedora bash .EE .PP هنگام استفاده از SELinux، توجه داشته باشید که میزبان اطلاعی از سیاست SELinux کانتینر ندارد. بنابراین در مثال بالا، اگر سیاست SELinux اعمال شده باشد، دایرکتوری \fB/var/db\fR برای کانتینر قابل نوشتن نخواهد بود. یک پیام "Permission Denied" و یک پیام :avc در syslog میزبان رخ خواهد داد. .PP برای رفع این مشکل، در زمان نگارش این صفحه راهنما، دستور زیر باید اجرا شود تا برچسب نوع سیاست SELinux مناسب به دایرکتوری میزبان متصل گردد: .EX # chcon -Rt svirt_sandbox_file_t /var/db .EE .PP اکنون، نوشتن در حجم data1/ درون کانتینر مجاز خواهد بود و تغییرات نیز در var/db/ روی میزبان منعکس می‌شود. .SH "استفاده از برچسب‌گذاری امنیتی جایگزین (Using alternative security labeling)" می‌توانید طرح برچسب‌گذاری پیش‌فرض برای هر کانتینر را با مشخص کردن فلگ \fB--security-opt\fR بازنویسی کنید. برای مثال، می‌توانید سطح MCS/MLS را که یک الزام برای سیستم‌های MLS است مشخص نمایید. تعیین سطح در دستور زیر به شما امکان می‌دهد محتوای یکسانی را میان کانتینرها به اشتراک بگذارید: .EX # docker run --security-opt label=level:s0:c100,c200 -i -t fedora bash .EE .PP یک مثال MLS می‌تواند چنین باشد: .EX # docker run --security-opt label=level:TopSecret -i -t rhel7 bash .EE .PP برای غیرفعال کردن برچسب‌گذاری امنیتی برای این کانتینر در مقایسه با اجرا با فلگ \fB--permissive\fR، از دستور زیر استفاده کنید: .EX # docker run --security-opt label=disable -i -t fedora bash .EE .PP اگر سیاست امنیتی سخت‌گیرانه‌تری روی پردازش‌های درون یک کانتینر می‌خواهید، می‌توانید یک نوع جایگزین برای کانتینر مشخص کنید. می‌توانید کانتینری را اجرا کنید که تنها مجاز باشد به درگاه‌های آپاچی گوش فرا دهد: .EX # docker run --security-opt label=type:svirt_apache_t -i -t centos bash .EE .PP نکته: .PP شما باید سیاستی را بنویسید که یک نوع \fBsvirt_apache_t\fR را تعریف کند. .SH "تنظیم وزن دستگاه (Setting device weight)" اگر می‌خواهید وزن دستگاه \fB/dev/sda\fR را روی \fB200\fR تنظیم کنید، می‌توانید وزن دستگاه را با فلگ \fB--blkio-weight-device\fR تعیین کنید. از دستور زیر استفاده نمایید: .EX # docker run -it --blkio-weight-device "/dev/sda:200" ubuntu .EE .SH "تعیین فناوری جداسازی برای کانتینر (--isolation) (Specify isolation technology for container (--isolation))" این گزینه در شرایطی مفید است که کانتینرهای داکر را روی Microsoft Windows اجرا می‌کنید. گزینه \fB--isolation \fR فناوری جداسازی کانتینر را تنظیم می‌کند. در لینوکس، تنها گزینه پشتیبانی‌شده \fBdefault\fR است که از فضاهای نام لینوکس استفاده می‌کند. این دو دستور در لینوکس معادلند: .EX $ docker run -d busybox top $ docker run -d --isolation default busybox top .EE .PP در Microsoft Windows، این گزینه می‌تواند هر یک از این مقادیر را بپذیرد: .IP \(bu 2 \fBdefault\fR: استفاده از مقدار مشخص‌شده توسط \fB--exec-opt\fR در دیمن داکر. اگر \fBdaemon\fR فناوری جداسازی را مشخص نکند، Microsoft Windows از \fBprocess\fR به عنوان مقدار پیش‌فرض استفاده می‌کند. .IP \(bu 2 \fBprocess\fR: فقط جداسازی فضای‌نام (Namespace isolation). .IP \(bu 2 \fBhyperv\fR: جداسازی مبتنی بر افراز هایپروایزر Hyper-V. .PP در عمل، هنگام اجرا در Microsoft Windows بدون تنظیم گزینه \fBdaemon\fR، این دو دستور معادلند: .EX $ docker run -d --isolation default busybox top $ docker run -d --isolation process busybox top .EE .PP اگر گزینه \fB--exec-opt isolation=hyperv\fR را روی دیمن داکر تنظیم کرده باشید، هر یک از این دستورات نیز به جداسازی \fBhyperv\fR منجر می‌شوند: .EX $ docker run -d --isolation default busybox top $ docker run -d --isolation hyperv busybox top .EE .SH "تنظیم پارامترهای کرنل دارای فضای‌نام (Sysctls) (Setting Namespaced Kernel Parameters (Sysctls))" گزینه \fB--sysctl\fR پارامترهای کرنل دارای فضای‌نام (sysctls) را در کانتینر تنظیم می‌کند. برای مثال، جهت فعال‌سازی هدایت IP (IP forwarding) در فضای‌نام شبکه کانتینرها، این دستور را اجرا کنید: .EX $ docker run --sysctl net.ipv4.ip_forward=1 someimage .EE .PP نکته: .PP همه sysctlها دارای فضای‌نام نیستند. داکر از تغییر دادن آن دسته از sysctlها درون کانتینر که سیستم میزبان را نیز تغییر می‌دهند پشتیبانی نمی‌کند. با تکامل کرنل انتظار می‌رود sysctlهای بیشتری دارای فضای‌نام شوند. .PP برای فهرست کنونی sysctlهای پشتیبانی‌شده، شرح گزینه \fB--sysctl\fR را در بالا ببینید. .SH "تاریخچه (HISTORY)" آوریل ۲۰۱۴، گردآوری اولیه توسط ویلیام هنری William Henry (whenry at redhat dot com) بر اساس منابع docker.com و کارهای داخلی. ژوئن ۲۰۱۴، به‌روزرسانی توسط Sven Dowideit SvenDowideit@home.org.au \[la]mailto:SvenDowideit@home.org.au\[ra] ژوئیه ۲۰۱۴، به‌روزرسانی توسط Sven Dowideit SvenDowideit@home.org.au \[la]mailto:SvenDowideit@home.org.au\[ra] نوامبر ۲۰۱۵، به‌روزرسانی توسط Sally O'Malley somalley@redhat.com \[la]mailto:somalley@redhat.com\[ra] .SH "ببینید (SEE ALSO)" \fBdocker(1)\fP, \fBdocker-container-run(1)\fP, \fBdocker-create(1)\fP