نام (NAME)

docker-run - ایجاد و اجرای یک کانتینر جدید از یک ایمیج

خلاصه (SYNOPSIS)

docker run [-a|--attach[=[]]] [--add-host[=[]]] [--annotation[=[]]] [--blkio-weight[=[BLKIO-WEIGHT]]] [--blkio-weight-device[=[]]] [-c|--cpu-shares[=0]] [--cap-add[=[]]] [--cap-drop[=[]]] [--cgroupns[=[]]] [--cgroup-parent[=CGROUP-PATH]] [--cidfile[=CIDFILE]] [--cpu-count[=0]] [--cpu-percent[=0]] [--cpu-period[=0]] [--cpu-quota[=0]] [--cpu-rt-period[=0]] [--cpu-rt-runtime[=0]] [--cpus[=0.0]] [--cpuset-cpus[=CPUSET-CPUS]] [--cpuset-mems[=CPUSET-MEMS]] [-d|--detach] [--detach-keys[=[]]] [--device[=[]]] [--device-cgroup-rule[=[]]] [--device-read-bps[=[]]] [--device-read-iops[=[]]] [--device-write-bps[=[]]] [--device-write-iops[=[]]] [--dns[=[]]] [--dns-option[=[]]] [--dns-search[=[]]] [--domainname[=DOMAINNAME]] [-e|--env[=[]]] [--entrypoint[=ENTRYPOINT]] [--env-file[=[]]] [--expose[=[]]] [--group-add[=[]]] [-h|--hostname[=HOSTNAME]] [--help] [--init] [-i|--interactive] [--ip[=IPv4-ADDRESS]] [--ip6[=IPv6-ADDRESS]] [--ipc[=IPC]] [--isolation[=default]] [-l|--label[=[]]] [--label-file[=[]]] [--link[=[]]] [--link-local-ip[=[]]] [--log-driver[=[]]] [--log-opt[=[]]] [-m|--memory[=MEMORY]] [--mac-address[=MAC-ADDRESS]] [--memory-reservation[=MEMORY-RESERVATION]] [--memory-swap[=LIMIT]] [--memory-swappiness[=MEMORY-SWAPPINESS]] [--mount[=[MOUNT]]] [--name[=NAME]] [--network-alias[=[]]] [--network[="bridge"]] [--oom-kill-disable] [--oom-score-adj[=0]] [-P|--publish-all] [-p|--publish[=[]]] [--pid[=[PID]]] [--userns[=[]]] [--pids-limit[=PIDS_LIMIT]] [--privileged] [--read-only] [--restart[=RESTART]] [--rm] [--security-opt[=[]]] [--storage-opt[=[]]] [--stop-signal[=SIGNAL]] [--stop-timeout[=TIMEOUT]] [--shm-size[=[]]] [--sig-proxy[=true]] [--sysctl[=[]]] [-t|--tty] [--tmpfs[=[CONTAINER-DIR[:OPTIONS]]] [-u|--user[=USER]] [--ulimit[=[]]] [--uts[=[]]] [-v|--volume[=[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]]] [--volume-driver[=DRIVER]] [--volumes-from[=[]]] [-w|--workdir[=WORKDIR]] IMAGE [COMMAND] [ARG...]

شرح (DESCRIPTION)

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

اگر ایمیج (IMAGE) قبلاً بارگیری نشده باشد، docker run پیش از آغاز کانتینر از آن ایمیج، ایمیج و تمامی وابستگی‌های آن را درست همانند اجرای دستور docker pull IMAGE از مخزن دریافت می‌کند.

گزینه‌ها (OPTIONS)

-a, --attach=[]
متصل شدن به STDIN، STDOUT یا STDERR.

در حالت پیش‌زمینه (حالت پیش‌فرض زمانی که -d مشخص نشده باشد)، docker run می‌تواند پردازش را در کانتینر آغاز کرده و کنسول را به ورودی استاندارد، خروجی استاندارد و خطای استاندارد پردازش متصل کند. حتی می‌تواند خود را مانند یک TTY شبیه‌سازی کند (چیزی که اکثر فایل‌های اجرایی خط فرمان انتظار دارند) و سیگنال‌ها را منتقل نماید. گزینه -a می‌تواند برای هر یک از stdin، stdout و stderr تنظیم شود.

--add-host=[]
افزودن یک نگاشت سفارشی میزبان به IP (به صورت host=ip یا host:ip).

افزودن یک خط به /etc/hosts. قالب به صورت hostname=ip یا hostname:ip است. گزینه --add-host می‌تواند چندین بار مشخص شود.

--annotation=[]
افزودن یک یادداشت (annotation) به کانتینر (ارسال به محیط زمان اجرای OCI).

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

--blkio-weight=0
وزن ورودی/خروجی بلوکی (وزن نسبی)؛ مقداری بین 10 تا 1000 می‌پذیرد.

--blkio-weight-device=[]
وزن ورودی/خروجی بلوکی (وزن نسبی دستگاه، با قالب: DEVICE_NAME:WEIGHT).

-c, --cpu-shares=0
سهم پردازنده (وزن نسبی)

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

برای تغییر دادن این سهم از مقدار پیش‌فرض 1024، از گزینه -c یا --cpu-shares برای تنظیم وزن به 2 یا بیشتر استفاده کنید.

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

برای مثال، سه کانتینر را در نظر بگیرید که یکی سهم پردازنده 1024 و دو کانتینر دیگر سهم 512 دارند. هنگامی که پردازش‌ها در هر سه کانتینر برای استفاده از ۱۰۰٪ توان پردازنده تلاش کنند، کانتینر اول ۵۰٪ از کل زمان پردازنده را دریافت خواهد کرد. اگر کانتینر چهارمی با سهم 1024 اضافه کنید، کانتینر اول تنها ۳۳٪ پردازنده را می‌گیرد و کانتینرهای باقیمانده ۱۶.۵٪، ۱۶.۵٪ و ۳۳٪ دریافت خواهند کرد.

در یک سیستم چند‌هسته‌ای، سهم زمان پردازنده روی تمام هسته‌های پردازنده توزیع می‌شود. حتی اگر یک کانتینر به کمتر از ۱۰۰٪ زمان کلی پردازنده محدود شده باشد، می‌تواند از ۱۰۰٪ هر هسته مجزا استفاده کند.

برای مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر یک کانتینر {C0} را با -c=512 که یک پردازش را اجرا می‌کند، و کانتینر دیگری {C1} را با -c=1024 که دو پردازش را اجرا می‌کند آغاز کنید، می‌تواند به تقسیم سهم پردازنده زیر منجر شود:

PID    container	CPU	CPU share
100    {C0}		0	100% of CPU0
101    {C1}		1	100% of CPU1
102    {C1}		2	100% of CPU2

--cap-add=[]
افزودن قابلیت‌های لینوکس (Linux capabilities)

--cap-drop=[]
حذف قابلیت‌های لینوکس (Linux capabilities)

--cgroupns=""
تنظیم حالت فضای‌نام cgroup برای کانتینر:
host: اجرای کانتینر در فضای‌نام cgroup میزبان
private: اجرای کانتینر در فضای‌نام cgroup خصوصی خودش
"": (تنظیم‌نشده) استفاده از پیکربندی پیش‌فرض دیمن (host در cgroup v1، private در cgroup v2)

--cgroup-parent=""
مسیر cgroups که cgroup کانتینر در زیر آن ایجاد خواهد شد.
اگر مسیر مطلق نباشد، نسبت به مسیر cgroups پردازش init در نظر گرفته می‌شود.
در صورت عدم وجود cgroups، ایجاد خواهند شد.

--cidfile=""
نوشتن شناسه کانتینر در فایل مشخص‌شده

--cpu-count=0
محدود کردن تعداد پردازنده‌های در دسترس برای اجرا توسط کانتینر.

در کانتینرهای Windows Server، این مقدار به صورت درصدی از کل مصرف پردازنده تقریب زده می‌شود. در کانتینرهای Windows Server، کنترل‌های منابع پردازنده ناسازگار با یکدیگر (mutually exclusive) هستند و ترتیب اولویت ابتدا CPUCount، سپس CPUShares و در نهایت CPUPercent است.

--cpu-percent=0
محدود کردن درصد پردازنده در دسترس برای اجرا توسط کانتینری که روی دیمن ویندوز اجرا می‌شود.

در کانتینرهای Windows Server، کنترل‌های منابع پردازنده ناسازگار با یکدیگر هستند و ترتیب اولویت ابتدا CPUCount، سپس CPUShares و در نهایت CPUPercent است.

--cpu-period=0
محدود کردن دوره CFS (زمان‌بند کاملاً عادلانه) پردازنده

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

--cpuset-cpus=""
پردازنده‌هایی که اجازه اجرا در آنها داده می‌شود (مثلاً 0-3، 0,1)

--cpuset-mems=""
گره‌های حافظه (MEMs) که اجازه اجرا در آنها داده می‌شود (0-3، 0,1). فقط در
سیستم‌های NUMA موثر است.

اگر چهار گره حافظه در سیستم خود دارید (0-3)، استفاده از --cpuset-mems=0,1 باعث می‌شود پردازش‌ها در کانتینر داکر شما تنها از حافظه دو گره نخست استفاده کنند.

--cpu-quota=0
محدود کردن سهمیه (quota) دوره CFS (زمان‌بند کاملاً عادلانه) پردازنده

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

--cpu-rt-period=0
محدود کردن دوره بلادرنگ (real-time) پردازنده بر حسب میکروثانیه

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

--cpu-rt-runtime=0
محدود کردن زمان اجرای بلادرنگ (real-time runtime) پردازنده بر حسب میکروثانیه

محدود کردن مصرف پردازنده بلادرنگ کانتینر. این فلگ به کرنل می‌گوید میزان زمانی را که وظایف بلادرنگ در یک دوره زمانی مشخص می‌توانند مصرف کنند محدود سازد. برای مثال، دوره ۱,۰۰۰,۰۰۰ میکروثانیه و زمان اجرای ۹۵۰,۰۰۰ میکروثانیه بدین معناست که این کانتینر می‌تواند ۹۵٪ از پردازنده در دسترس را مصرف کرده و ۵٪ باقیمانده را برای وظایف با اولویت عادی بگذارد.

مجموع کل زمان‌های اجرا در میان تمامی کانتینرها نمی‌تواند از مقدار اختصاص‌یافته به cgroup والد فراتر رود.

--cpus=0.0
تعداد پردازنده‌ها. مقدار پیش‌فرض 0.0 است که به معنای عدم محدودیت است.

-d, --detach=true|false
حالت جداشده (Detached): اجرای کانتینر در پس‌زمینه و چاپ شناسه کانتینر جدید.
مقدار پیش‌فرض false است.

در هر زمان می‌توانید docker ps را در یک پوسته دیگر برای مشاهده فهرست کانتینرهای در حال اجرا اجرا کنید. می‌توانید با docker attach دوباره به یک کانتینر جداشده متصل شوید.

هنگامی که در حالت tty متصل هستید، می‌توانید با استفاده از یک توالی کلید قابل‌پیکربندی از کانتینر جدا شوید (و بگذارید در حال اجرا بماند). توالی پیش‌فرض CTRL-p CTRL-q است. می‌توانید توالی کلید را با استفاده از گزینه --detach-keys یا یک فایل پیکربندی تنظیم کنید. برای مستندات استفاده از فایل پیکربندی به config-json(5) مراجعه کنید.

--detach-keys=key
بازنویسی توالی کلید برای جدا شدن از یک کانتینر؛ key یک کاراکتر منفرد از
محدوده [a-Z]، یا به صورت ctrl-value است، که در آن value
یکی از مقادیر روبرو است: a-z، @، ^، [، ,، یا _.

--device=onhost:incontainer[:mode]
افزودن دستگاه میزبان onhost به داخل کانتینر با نام incontainer.
پارامتر اختیاری mode می‌تواند برای تعیین دسترسی‌های دستگاه استفاده شود؛
این پارامتر ترکیبی از r (برای خواندن)، w (برای نوشتن)، و m
(برای mknod(2)) است.

برای مثال، --device=/dev/sdc:/dev/xvdc:rwm به کانتینر تمامی دسترسی‌ها را برای دستگاه میزبان /dev/sdc می‌دهد، که در داخل کانتینر به عنوان /dev/xvdc دیده می‌شود.

--device-cgroup-rule="type major:minor mode"
افزودن یک قانون به فهرست دستگاه‌های مجاز cgroup. قانون باید در قالبی باشد که
در مستندات کرنل لینوکس مشخص شده است (Documentation/cgroup-v1/devices.txt):
- type: شامل a (همه)، c (کاراکتری)، یا b (بلوکی)؛
- major و minor: یک عدد، یا * برای همه؛
- mode: ترکیبی از r (خواندن)، w (نوشتن)، و m (mknod(2)).

مثال: --device-cgroup-rule "c 1:3 mr": اجازه می‌دهد دستگاه کاراکتری با مشخصه 1:3 ایجاد و خوانده شود.

--device-read-bps=[]
محدود کردن نرخ خواندن از یک دستگاه (مثلاً --device-read-bps=/dev/sda:1mb)

--device-read-iops=[]
محدود کردن نرخ خواندن از یک دستگاه (مثلاً --device-read-iops=/dev/sda:1000)

--device-write-bps=[]
محدود کردن نرخ نوشتن در یک دستگاه (مثلاً --device-write-bps=/dev/sda:1mb)

--device-write-iops=[]
محدود کردن نرخ نوشتن در یک دستگاه (مثلاً --device-write-iops=/dev/sda:1000)

--dns-search=[]
تنظیم دامنه‌های جستجوی سفارشی DNS (اگر نمی‌خواهید دامنه جستجو تنظیم کنید از --dns-search=. استفاده کنید)

--dns-option=[]
تنظیم گزینه‌های سفارشی DNS

--dns=[]
تنظیم سرورهای سفارشی DNS

این گزینه می‌تواند برای بازنویسی پیکربندی DNS ارسالی به کانتینر استفاده شود. این امر معمولاً زمانی ضروری است که پیکربندی DNS میزبان برای کانتینر نامعتبر باشد (مثلاً 127.0.0.1). در چنین شرایطی فلگ‌های --dns برای هر بار اجرا لازم است.

--domainname=""
نام دامنه NIS کانتینر

نام دامنه NIS کانتینر (همچنین به setdomainname(2) مراجعه کنید) را که در داخل کانتینر در دسترس است تنظیم می‌کند.

-e, --env=[]
تنظیم متغیرهای محیطی

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

--entrypoint=""
بازنویسی ENTRYPOINT پیش‌فرض ایمیج

این گزینه به شما اجازه می‌دهد نقطه ورود پیش‌فرض ایمیج را که در Dockerfile تعیین شده بازنویسی کنید. نقطه ورود (ENTRYPOINT) یک ایمیج مشابه COMMAND است زیرا مشخص می‌کند هنگام آغاز کانتینر چه فایل اجرایی باید اجرا شود، اما (عامدانه) بازنویسی آن دشوارتر است. نقطه ورود، ماهیت یا رفتار پیش‌فرض کانتینر را شکل می‌دهد، به طوری که وقتی یک ENTRYPOINT تنظیم می‌کنید می‌توانید کانتینر را درست مانند اجرای آن برنامه باینری همراه با گزینه‌های پیش‌فرضش اجرا نمایید، و گزینه‌های بیشتر را از طریق COMMAND منتقل کنید. اما گاهی ممکن است مدیر بخواهد چیز دیگری را درون کانتینر اجرا کند؛ بنابراین می‌توانید ENTRYPOINT پیش‌فرض را در زمان اجرا با استفاده از --entrypoint و یک رشته برای مشخص کردن ENTRYPOINT جدید بازنویسی کنید.

--env-file=[]
خواندن متغیرهای محیطی از یک فایل خط‌به‌خط

--expose=[]
اکسپوز کردن یک درگاه یا محدوده‌ای از درگاه‌ها (مثلاً --expose=3300-3310) به دیمن
داکر اطلاع می‌دهد که کانتینر در زمان اجرا روی درگاه‌های شبکه مشخص‌شده گوش فرا می‌دهد.
دیمن داکر از این اطلاعات برای متصل کردن متقابل کانتینرها با استفاده از پیوندها (links)
و راه‌اندازی هدایت درگاه روی سیستم میزبان استفاده می‌کند.

--group-add=[]
افزودن گروه‌های اضافی برای اجرا تحت عنوان آنها

-h, --hostname=""
نام میزبان کانتینر

نام میزبان کانتینر را که در داخل کانتینر در دسترس است تنظیم می‌کند.

--help
چاپ راهنمای نحوه استفاده

--init
اجرای یک پردازش init درون کانتینر که سیگنال‌ها را هدایت کرده و پردازش‌های زامبی را پاکسازی می‌کند

-i, --interactive=true|false
باز نگه داشتن STDIN حتی اگر متصل نشده باشد. مقدار پیش‌فرض false است.

زمانی که روی true تنظیم شود، ورودی استاندارد را حتی در صورت عدم اتصال باز نگه می‌دارد.

--ip=""
نشانی IPv4 رابط شبکه کانتینر را تنظیم می‌کند (مثلاً 172.23.0.9)

این گزینه تنها همراه با --network برای شبکه‌های تعریف‌شده توسط کاربر قابل استفاده است.

--ip6=""
نشانی IPv6 رابط شبکه کانتینر را تنظیم می‌کند (مثلاً 2001:db8::1b99)

این گزینه تنها همراه با --network برای شبکه‌های تعریف‌شده توسط کاربر قابل استفاده است.

--ipc=""
حالت IPC را برای کانتینر تنظیم می‌کند. مقادیر زیر پذیرفته می‌شوند:

در صورت عدم تعیین، مقدار پیش‌فرض دیمن استفاده می‌شود که بسته به نگارش و پیکربندی دیمن، می‌تواند private یا shareable باشد.

--isolation="default"
جداسازی (Isolation) نوع فناوری جداسازی مورد استفاده کانتینرها را تعیین می‌کند. توجه داشته باشید که مقدار پیش‌فرض در سرور ویندوز process است، و پیش‌فرض در کلاینت ویندوز hyperv می‌باشد. لینوکس تنها از default پشتیبانی می‌کند.

-l, --label key=value
تنظیم متاداده روی کانتینر (برای مثال، --label com.example.key=value).

--label-file=[]
خواندن برچسب‌ها از یک فایل خط‌به‌خط

--link=name-or-id[:alias]
افزودن پیوند به کانتینر دیگر.

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

--link-local-ip=[]
افزودن یک یا چند نشانی IPv4/IPv6 پیوند-محلی (link-local) به رابط شبکه کانتینر

--log-driver="json-file|syslog|journald|gelf|fluentd|awslogs|splunk|etwlogs|gcplogs|none"
درایور ثبت وقایع (لاگ) برای کانتینر. پیش‌فرض توسط فلگ --log-driver دیمن تعریف می‌شود.
هشدار: دستور docker logs تنها برای درایورهای json-file و
journald کار می‌کند.

--log-opt=[]
گزینه‌های اختصاصی درایور لاگ.

-m, --memory=number[*S]
محدودیت حافظه؛ S پسوند اختیاری است که می‌تواند یکی از b، k، m یا g باشد.

به شما امکان می‌دهد حافظه در دسترس کانتینر را محدود کنید. اگر میزبان از حافظه معاوضه (swap) پشتیبانی کند، تنظیم حافظه -m می‌تواند بزرگتر از RAM فیزیکی باشد. اگر محدودیت 0 مشخص شود (عدم استفاده از -m)، حافظه کانتینر محدود نمی‌شود. محدودیت واقعی ممکن است به مضربی از اندازه صفحه سیستم‌عامل گرد شود (مقدار بسیار بزرگی خواهد بود).

--memory-reservation=number[*S]
محدودیت نرم حافظه؛ S پسوند اختیاری است که می‌تواند یکی از b، k، m یا g باشد.

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

--memory-swap=number[S]
مجموع محدودیت حافظه به همراه معاوضه (swap)؛ S یک پسوند اختیاری است که می‌تواند
یکی از b، k، m یا g باشد.

این گزینه فقط همراه با --memory قابل استفاده است. مقدار آرگومان باید همیشه بزرگتر از --memory باشد. پیش‌فرض دو برابر مقدار --memory است. برای فعال کردن swap نامحدود، مقدار را روی -1 قرار دهید.

--mac-address=""
نشانی MAC کانتینر (مثلاً 92:d0:c6:0a:29:33)

به یاد داشته باشید که نشانی MAC در یک شبکه اترنت باید یکتا باشد. نشانی link-local از نوع IPv6 بر اساس نشانی MAC دستگاه مطابق با RFC4862 خواهد بود.

--mount type=TYPE,TYPE-SPECIFIC-OPTION[,...]
متصل کردن یک سوارشدن سیستم‌فایل به کانتینر

انواع سوارشدن (TYPES) پشتیبانی‌شده کنونی شامل bind، volume و tmpfs هستند.

برای مثال:

type=bind,source=/path/on/host,destination=/path/in/container

type=volume,source=my-volume,destination=/path/in/container,volume-label="color=red"

type=tmpfs,tmpfs-size=512M,destination=/path/in/container

گزینه‌های مشترک:

• src, source: مشخصه منبع سوارشدن برای bind و volume. برای bind اجباری است.
• dst, destination, target: مشخصه مقصد سوارشدن.
• ro, readonly: به صورت true یا false (پیش‌فرض).

نکته: تنظیم readonly برای یک bind mount بسته به نگارش کرنل ممکن است زیرمجموعه‌های آن را فقط‌خواندنی نکند. همچنین به bind-recursive مراجعه کنید.

گزینه‌های اختصاصی bind:

• bind-propagation: به صورت shared، slave، private، rshared، rslave یا rprivate (پیش‌فرض). همچنین به mount(2) مراجعه کنید.
• consistency: به صورت consistent (پیش‌فرض)، cached یا delegated. در حال حاضر فقط برای Docker for Mac موثر است.
• bind-recursive: به صورت enabled (پیش‌فرض)، disabled، writable یا readonly:
  اگر روی enabled تنظیم شود، زیرمجموعه‌ها به صورت بازگشتی bind mount شده و تلاش می‌شود به صورت بازگشتی فقط‌خواندنی شوند.
  اگر روی disabled تنظیم شود، زیرمجموعه‌ها به صورت بازگشتی bind mount نمی‌شوند.
  اگر روی writable تنظیم شود، زیرمجموعه‌ها به صورت بازگشتی bind mount شده اما فقط‌خواندنی نمی‌شوند.
  اگر روی readonly تنظیم شود، زیرمجموعه‌ها به صورت بازگشتی bind mount شده و اجباراً به صورت بازگشتی فقط‌خواندنی می‌شوند.

گزینه‌های اختصاصی volume:

• volume-driver: نام پلاگین volume-driver.
• volume-label: متاداده سفارشی.
• volume-nocopy: به صورت true (پیش‌فرض) یا false. اگر روی false تنظیم شود، موتور داکر فایل‌ها و دایرکتوری‌های موجود زیر مسیر سوارشدن را به درون حجم کپی می‌کند و به میزبان اجازه دسترسی به آنها را می‌دهد.
• volume-opt: مختص یک درایور حجم مشخص.

گزینه‌های اختصاصی tmpfs:

• tmpfs-size: اندازه سوارشدن tmpfs بر حسب بایت. به طور پیش‌فرض در لینوکس نامحدود است.
• tmpfs-mode: حالت فایل (file mode) مربوط به tmpfs در مبنای هشت (اکتال) (مانند 700 یا 0700). در لینوکس به طور پیش‌فرض 1777 است.

--name=""
تخصیص یک نام به کانتینر

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

• شناسه طولانی (long ID): f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778
• شناسه کوتاه (short ID): f78375b1c487
• نام (Name): evil_ptolemy

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

--network=type
تنظیم حالت شبکه برای کانتینر. مقادیر پشتیبانی‌شده عبارتند از:

پیش‌فرض bridge است.

--network-alias=[]
افزودن نام مستعار در حوزه شبکه برای کانتینر

--oom-kill-disable=true|false
غیرفعال کردن یا نکردن OOM Killer برای کانتینر.

--oom-score-adj=""
تنظیم ترجیحات OOM میزبان برای کانتینرها (مقداری بین -1000 تا 1000 می‌پذیرد)

-P, --publish-all=true|false
انتشار تمامی درگاه‌های اکسپوز شده به درگاه‌های تصادفی در رابط‌های میزبان. پیش‌فرض false است.

در صورت تنظیم روی true، تمام درگاه‌های اکسپوز شده را روی رابط‌های میزبان منتشر می‌کند. پیش‌فرض false است. اگر کاربر از -P (یا -p) استفاده کند، داکر درگاه اکسپوز شده را روی میزبان قابل دسترسی می‌سازد و درگاه‌ها برای هر کلاینتی که بتواند به میزبان برسد در دسترس خواهند بود. هنگام استفاده از -P، داکر هر درگاه اکسپوز شده را به یک درگاه تصادفی روی میزبان درون یک محدوده درگاه زودگذر (ephemeral port range) که توسط /proc/sys/net/ipv4/ip_local_port_range تعریف شده متصل می‌کند. برای یافتن نگاشت میان درگاه‌های میزبان و درگاه‌های اکسپوز شده، از docker port(1) استفاده کنید.

-p, --publish ip:[hostPort]:containerPort | [hostPort:]containerPort
انتشار درگاه یا محدوده‌ای از درگاه‌های کانتینر روی میزبان.

هر دو مقدار hostPort و containerPort می‌توانند به صورت یک محدوده مشخص شوند. هنگام تعیین محدوده برای هر دو، تعداد درگاه‌ها در هر دو محدوده باید برابر باشد.

مثال‌ها: -p 1234-1236:1222-1224، -p 127.0.0.1:$HOSTPORT:$CONTAINERPORT.

از docker port(1) برای مشاهده نگاشت واقعی استفاده کنید، مثلاً docker port CONTAINER $CONTAINERPORT.

--pid=""
تنظیم حالت PID برای کانتینر
پیش‌فرض ایجاد یک فضای‌نام PID اختصاصی برای کانتینر است
'container:': پیوستن به فضای‌نام PID کانتینر دیگر
'host': استفاده از فضای‌نام PID میزبان برای کانتینر. نکته: حالت host به کانتینر دسترسی کامل به PID محلی می‌دهد و بنابراین ناامن تلقی می‌شود.

--userns=""
تنظیم حالت usernamespace برای کانتینر در زمانی که گزینه userns-remap فعال است.
host: استفاده از فضای‌نام کاربری میزبان و فعال‌سازی تمامی گزینه‌های با دسترسی بالا (مانند pid=host یا --privileged).

--pids-limit=""
تنظیم محدودیت تعداد شناسه پردازش‌های کانتینر (pids). مقدار را روی -1 تنظیم کنید تا کانتینر بدون محدودیت pid باشد.

--uts=type
تنظیم حالت UTS برای کانتینر. تنها type ممکن host است،
به معنای استفاده از فضای‌نام UTS میزبان درون کانتینر.

نکته: حالت host به کانتینر امکان دسترسی برای تغییر نام میزبانِ سیستم میزبان را می‌دهد و به همین دلیل ناامن در نظر گرفته می‌شود.

--privileged [true|false]
اعطای امتیازات گسترده به این کانتینر. به یک کانتینر دارای امتیاز (privileged)، دسترسی به تمام دستگاه‌ها داده می‌شود.

هنگامی که مجری دستور docker run --privileged را اجرا می‌کند، داکر دسترسی به تمامی دستگاه‌های روی میزبان را فعال کرده و همچنین پیکربندی‌هایی در AppArmor اعمال می‌کند تا به کانتینر تقریباً همان دسترسی‌هایی داده شود که پردازش‌های در حال اجرا در خارج از کانتینر روی میزبان دارند.

--read-only=true|false
سوار کردن فایل‌سیستم ریشه کانتینر به صورت فقط‌خواندنی.

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

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

پیش‌فرض no است.

--rm true|false
حذف خودکار کانتینر و حجم‌های ناشناس وابسته به آن هنگام خروج. پیش‌فرض false است.
فلگ --rm می‌تواند همراه با -d کار کند و حذف خودکار در سمت دیمن انجام خواهد شد.
توجه داشته باشید که این گزینه با هر سیاست راه‌اندازی مجددی به جز none ناسازگار است.

--security-opt value[,...]
گزینه‌های امنیتی برای کانتینر. گزینه‌های زیر می‌توانند ارائه شوند:

--storage-opt
گزینه‌های درایور فضای ذخیره‌سازی برای هر کانتینر

$ docker run -it --storage-opt size=120G fedora /bin/bash

این گزینه (size) اجازه می‌دهد اندازه rootfs کانتینر در زمان ایجاد روی 120G تنظیم شود. این گزینه فقط برای درایورهای گراف btrfs، overlay2 و zfs در دسترس است. برای درایورهای ذخیره‌سازی btrfs و zfs، کاربر نمی‌تواند اندازه‌ای کمتر از Default BaseFS Size تعیین کند. برای درایور ذخیره‌سازی overlay2، گزینه size تنها در صورتی در دسترس است که سیستم‌فایل زیرین xfs بوده و با گزینه pquota سوار شده باشد. تحت این شرایط، کاربر می‌تواند هر اندازه‌ای کمتر از اندازه سیستم‌فایل زیرین را وارد نماید.

--stop-signal=""
سیگنال توقف کانتینر.

فلگ --stop-signal سیگنال فراخوانی سیستمی را که برای خروج به کانتینر ارسال می‌شود تنظیم می‌کند. این سیگنال می‌تواند یک نام سیگنال با قالب SIG<NAME> باشد، برای مثال SIGKILL، یا یک عدد نامنفی که مطابق با موقعیتی در جدول syscall کرنل است، برای مثال 9.

پیش‌فرض توسط STOPSIGNAL در ایمیج تعیین می‌شود، یا اگر در ایمیج هیچ STOPSIGNAL تعریف نشده باشد، SIGTERM خواهد بود.

--stop-timeout
مدت‌زمان انتظار (بر حسب ثانیه) برای توقف کانتینر، یا -1 برای غیرفعال کردن مهلت زمانی.

فلگ --stop-timeout تعداد ثانیه‌های انتظار برای توقف کانتینر پس از ارسال سیگنال فراخوانی سیستمی از پیش تعریف‌شده (به --stop-signal مراجعه کنید) را تنظیم می‌کند. اگر کانتینر پس از پایان این مهلت خارج نشود، با ارسال سیگنال SIGKILL به اجبار متوقف می‌شود.

اگر --stop-timeout روی -1 تنظیم شود، هیچ مهلت زمانی اعمال نشده و دیمن برای همیشه منتظر خروج کانتینر خواهد ماند.

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

--shm-size=""
اندازه /dev/shm. قالب به صورت <number><unit> است.
مقدار number باید بزرگتر از 0 باشد. واحد اختیاری است و می‌تواند b (بایت)،
k (کیلوبایت)، m (مگابایت) یا g (گیگابایت) باشد. اگر واحد را حذف کنید،
سیستم از بایت استفاده می‌کند. اگر مقدار اندازه را کلاً حذف کنید، سیستم از 64m استفاده می‌کند.

--sysctl=SYSCTL
پیکربندی پارامترهای کرنل دارای فضای‌نام در زمان اجرا

فضای‌نام IPC - مقادیر مجاز کنونی sysctl:

kernel.msgmax, kernel.msgmnb, kernel.msgmni, kernel.sem, kernel.shmall, kernel.shmmax, kernel.shmmni, kernel.shm_rmid_forced, and sysctls beginning with fs.mqueue.*

اگر از گزینه --ipc=host استفاده کنید این sysctlها مجاز نخواهند بود.

فضای‌نام شبکه - مقادیر مجاز کنونی sysctl:
Sysctls beginning with net.*

اگر از گزینه --network=host استفاده کنید این sysctlها مجاز نخواهند بود.

--sig-proxy=true|false
انتقال سیگنال‌های دریافتی به پردازش (فقط در حالت غیر-TTY). سیگنال‌های SIGCHLD، SIGSTOP
و SIGKILL هدایت نمی‌شوند. مقدار پیش‌فرض true است.

--memory-swappiness=""
تنظیم رفتار swappiness حافظه کانتینر. عددی صحیح بین 0 تا 100 می‌پذیرد.

-t, --tty=true|false
اختصاص یک شبه-TTY. مقدار پیش‌فرض false است.

هنگامی که روی true تنظیم شود، داکر می‌تواند یک pseudo-tty تخصیص داده و به ورودی استاندارد هر کانتینری متصل شود. این مورد می‌تواند مثلاً برای اجرای یک پوسته تعاملی یک‌بارمصرف استفاده شود. مقدار پیش‌فرض false است.

گزینه -t با تغییر مسیر (redirection) ورودی استاندارد کلاینت داکر ناسازگار است.

--tmpfs=[] ایجاد یک سوارشدن tmpfs

سوار کردن یک سیستم‌فایل موقت (tmpfs) در داخل کانتینر، برای مثال:

$ docker run -d --tmpfs /tmp:rw,size=787448k,mode=1777 my_image

این دستور یک tmpfs را در مسیر /tmp درون کانتینر سوار می‌کند. گزینه‌های پشتیبانی‌شده همان فلگ‌های پیش‌فرض mount لینوکس هستند. اگر هیچ گزینه‌ای تعیین نکنید، سیستم از گزینه‌های روبرو استفاده می‌کند: rw,noexec,nosuid,nodev,size=65536k.

همچنین به --mount مراجعه کنید که جانشین --tmpfs و --volume است. اگرچه برنامه‌ای برای منسوخ کردن --tmpfs وجود ندارد، استفاده از --mount توصیه می‌شود.

-u, --user=""
تنظیم نام کاربری یا UID مورد استفاده و به صورت اختیاری نام گروه یا GID برای دستور مشخص‌شده.

مثال‌های زیر همگی معتبر هستند:
--user [user | user:group | uid | uid:gid | user:gid | uid:group ]

بدون این آرگومان، دستور با دسترسی ریشه (root) در کانتینر اجرا خواهد شد.

--ulimit=[]
گزینه‌های Ulimit

-v|--volume[=[[HOST-DIR:]CONTAINER-DIR[:OPTIONS]]]
ایجاد یک bind mount. اگر -v /HOST-DIR:/CONTAINER-DIR را مشخص کنید، داکر
مسیر /HOST-DIR در میزبان را به /CONTAINER-DIR در کانتینر داکر bind mount
می‌کند. اگر 'HOST-DIR' حذف شود، داکر به طور خودکار حجم جدید را روی میزبان ایجاد
می‌کند. بخش OPTIONS فهرستی با جداکننده کاما است و می‌تواند شامل موارد زیر باشد:

• [rw|ro]
• [z|Z]
• [[r]shared|[r]slave|[r]private]
• [delegated|cached|consistent]
• [nocopy]

مقدار CONTAINER-DIR باید یک مسیر مطلق مانند /src/docs باشد. مقدار HOST-DIR می‌تواند یک مسیر مطلق یا یک مقدار name باشد. مقدار name باید با یک کاراکتر حرفی-عددی شروع شود و در ادامه می‌تواند شامل a-z0-9، _ (خط زیرین)، . (نقطه) یا - (خط تیره) باشد. یک مسیر مطلق با / (اسلش) شروع می‌شود.

اگر یک HOST-DIR ارائه دهید که یک مسیر مطلق باشد، داکر به مسیری که مشخص کرده‌اید bind-mount انجام می‌دهد. اگر یک name وارد کنید، داکر یک حجم نام‌گذاری‌شده با آن name ایجاد می‌کند. برای مثال، می‌توانید /foo یا foo را برای مقدار HOST-DIR مشخص کنید. اگر مقدار /foo را بدهید، داکر یک bind mount ایجاد می‌کند. اگر مقدار foo را وارد کنید، داکر یک حجم نام‌گذاری‌شده می‌سازد.

می‌توانید چندین گزینه -v برای سوار کردن یک یا چند حجم در یک کانتینر مشخص کنید. برای استفاده از همین موارد در کانتینرهای دیگر، گزینه --volumes-from را نیز مشخص نمایید.

می‌توانید گزینه‌های بیشتری را برای هر bind mount پس از یک دونقطه دیگر مشخص کنید. پسوند :ro یا :rw حجم را به ترتیب در حالت فقط‌خواندنی یا خواندن-نوشتن سوار می‌کند. به طور پیش‌فرض، حجم‌ها در حالت خواندن-نوشتن سوار می‌شوند. همچنین می‌توانید الزامات سازگاری سوارشدن را مشخص کنید: :consistent (پیش‌فرض)، :cached یا :delegated. گزینه‌های متعدد با کاما از هم جدا می‌شوند، مثلاً :ro,cached.

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

برای تغییر دادن برچسب در بافت کانتینر، می‌توانید یکی از دو پسوند :z یا :Z را به سوارشدن حجم اضافه کنید. این پسوندها به داکر می‌گویند اشیای فایلی موجود در حجم‌های اشتراکی را مجدداً برچسب‌گذاری کند. گزینه z به داکر می‌گوید که دو کانتینر محتوای حجم را به اشتراک می‌گذارند. در نتیجه، داکر محتوا را با یک برچسب محتوای اشتراکی برچسب‌گذاری می‌کند. برچسب‌های حجم اشتراکی به تمام کانتینرها اجازه خواندن/نوشتن محتوا را می‌دهند. گزینه Z به داکر می‌گوید که محتوا را با یک برچسب اختصاصی غیرقابل‌اشتراک برچسب‌گذاری کند. تنها کانتینر فعلی می‌تواند از یک حجم اختصاصی استفاده کند.

به طور پیش‌فرض حجم‌های bind mount شده از نوع private هستند. این بدان معناست که هر سوارشدنی در داخل کانتینر روی میزبان قابل مشاهده نخواهد بود و بالعکس. می‌توان این رفتار را با تعیین ویژگی انتشار سوارشدن حجم (volume mount propagation) تغییر داد. تنظیم یک حجم به صورت shared باعث می‌شود سوارشدن‌های انجام‌شده زیر آن حجم در کانتینر، روی میزبان قابل مشاهده باشند و بالعکس. تنظیم حجم به صورت slave تنها انتشار یک‌طرفه را فعال می‌کند، به این معنی که سوارشدن‌های انجام‌شده روی میزبان زیر آن حجم در داخل کانتینر قابل مشاهده خواهند بود اما عکس آن صادق نیست.

برای کنترل ویژگی انتشار حجم می‌توان از فلگ‌های انتشار :[r]shared، :[r]slave یا :[r]private استفاده کرد. ویژگی انتشار تنها برای حجم‌های bind mount شده قابل تعیین است و نه برای حجم‌های داخلی یا حجم‌های نام‌گذاری‌شده. برای کارکرد صحیح انتشار، نقطه سوارشدن منبع (نقطه‌ای که دایرکتوری منبع روی آن سوار است) باید ویژگی‌های انتشار درستی داشته باشد. برای حجم‌های اشتراکی، نقطه سوارشدن منبع باید shared باشد. و برای حجم‌های slave، نقطه منبع باید shared یا slave باشد.

از دستور df <source-dir> برای پیدا کردن نقطه سوارشدن منبع و سپس از دستور findmnt -o TARGET,PROPAGATION <source-mount-dir> برای مشاهده ویژگی‌های انتشار نقطه سوارشدن منبع استفاده کنید. اگر ابزار findmnt در دسترس نیست، می‌توانید به ورودی سوارشدن برای نقطه منبع در /proc/self/mountinfo نگاه کنید. بخش optional fields را بررسی کنید تا ببینید آیا هیچ ویژگی انتشاری مشخص شده است یا خیر. مقدار shared:X یعنی نقطه سوارشدن shared است، master:X یعنی slave است و اگر چیزی نباشد یعنی نقطه سوارشدن private است.

برای تغییر دادن ویژگی‌های انتشار یک نقطه سوارشدن از دستور mount استفاده کنید. برای مثال، اگر کسی بخواهد دایرکتوری منبع /foo را bind mount کند می‌تواند دستورات mount --bind /foo /foo و mount --make-private --make-shared /foo را اجرا نماید. این کار /foo را به یک نقطه سوارشدن shared تبدیل می‌کند. متناوباً می‌توان مستقیماً ویژگی‌های نقطه منبع را تغییر داد. فرض کنید / نقطه منبع برای /foo است، در این صورت از mount --make-shared / برای تبدیل / به یک نقطه سوارشدن shared استفاده کنید.

برای غیرفعال کردن کپی خودکار داده‌ها از مسیر کانتینر به حجم، از فلگ nocopy استفاده کنید. فلگ nocopy را می‌توان روی bind mountها و حجم‌های نام‌گذاری‌شده تنظیم کرد.

همچنین به --mount مراجعه کنید که جانشین --tmpfs و --volume است. اگرچه برنامه‌ای برای منسوخ کردن --volume وجود ندارد، استفاده از --mount توصیه می‌شود.

--volume-driver=""
درایور حجم کانتینر. این درایور حجم‌هایی را ایجاد می‌کند که از دستورالعمل VOLUME در Dockerfile
یا از فلگ docker run -v مشخص شده‌اند.
برای جزئیات کامل به docker-volume-create(1) مراجعه کنید.

--volumes-from=[]
سوار کردن حجم‌ها از کانتینر (یا کانتینرهای) مشخص‌شده

حجم‌های قبلاً سوارشده از یک کانتینر منبع را روی یک کانتینر دیگر سوار می‌کند. باید شناسه کانتینر منبع را وارد کنید. برای اشتراک‌گذاری یک حجم، هنگام اجرای کانتینر هدف از گزینه --volumes-from استفاده کنید. حتی اگر کانتینر منبع در حال اجرا نباشد نیز می‌توانید حجم‌ها را به اشتراک بگذارید.

به طور پیش‌فرض، داکر حجم‌ها را در همان حالتی سوار می‌کند (خواندن-نوشتن یا فقط‌خواندنی) که در کانتینر منبع سوار شده بودند. به صورت اختیاری، می‌توانید این وضعیت را با افزودن کلمه کلیدی :ro یا :rw به انتهای شناسه کانتینر تغییر دهید.

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

-w, --workdir=""
دایرکتوری کاری درون کانتینر

دایرکتوری کاری پیش‌فرض برای اجرای فایل‌های باینری درون کانتینر، دایرکتوری ریشه (/) است. توسعه‌دهنده می‌تواند با دستورالعمل WORKDIR در Dockerfile یک پیش‌فرض متفاوت تنظیم کند. مدیر می‌تواند با استفاده از گزینه -w دایرکتوری کاری را بازنویسی نماید.

وضعیت خروج (EXIT STATUS)

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

125 اگر خطا از سمت خود دیمن داکر (itself) باشد

$ docker run --foo busybox; echo $?
# flag provided but not defined: --foo
  See 'docker run --help'.
  125

126 اگر دستور درون کانتینر (contained command) قابل فراخوانی نباشد

$ docker run busybox /etc; echo $?
# exec: "/etc": permission denied
  docker: Error response from daemon: Contained command could not be invoked
  126

127 اگر دستور درون کانتینر (contained command) یافت نشود

$ 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

در غیر این صورت، کد خروج مربوط به دستور درون کانتینر (contained command) بازگردانده می‌شود

$ docker run busybox /bin/sh -c 'exit 3'
# 3

مثال‌ها (EXAMPLES)

اجرای کانتینر در حالت فقط‌خواندنی (Running container in read-only mode)

در طول توسعه ایمیج کانتینر، کانتینرها اغلب نیاز دارند در محتوای ایمیج بنویسند؛ برای مثال نصب بسته‌ها در usr/. در محیط عملیاتی (production)، برنامه‌ها به ندرت نیاز به نوشتن در ایمیج دارند. برنامه‌های درون کانتینر اگر اصلاً نیاز به نوشتن در سیستم‌فایل داشته باشند، درون حجم‌ها (volumes) می‌نویسند. با اجرای برنامه‌ها در حالت فقط‌خواندنی با استفاده از فلگ --read-only می‌توان امنیت آنها را افزایش داد. این کار از تغییر ایمیج کانتینرها محافظت می‌کند. کانتینرهای فقط‌خواندنی ممکن است همچنان نیاز به نوشتن داده‌های موقت داشته باشند. بهترین راه برای مدیریت این مورد، سوار کردن دایرکتوری‌های tmpfs روی run/ و tmp/ است.

# docker run --read-only --tmpfs /run --tmpfs /tmp -i -t fedora /bin/bash

هدایت پیام‌های گزارش از کانتینر به گزارش‌های میزبان (Exposing log messages from the container to the host's log)

اگر می‌خواهید پیام‌هایی که در کانتینر شما لاگ می‌شوند در syslog/journal میزبان نمایش داده شوند، باید دایرکتوری dev/log/ را به صورت bind mount مطابق زیر سوار کنید:

# docker run -v /dev/log:/dev/log -i -t fedora /bin/bash

از داخل کانتینر می‌توانید این مورد را با ارسال یک پیام به لاگ آزمایش کنید:

(bash)# logger "Hello from my container"

سپس خارج شوید و journal را بررسی نمایید:

# exit
# journalctl -b | grep Hello

این دستور باید پیامی را که به logger ارسال شده بود فهرست کند.

اتصال به یک یا چند مورد از STDIN، STDOUT، STDERR (Attaching to one or more from STDIN, STDOUT, STDERR)

اگر گزینه -a را مشخص نکنید داکر همه چیز (stdin,stdout,stderr) را متصل می‌کند. می‌توانید مشخص کنید که در عوض می‌خواهید به کدام یک از سه جریان استاندارد متصل شوید، مانند:

# docker run -a stdin -a stdout -i -t fedora /bin/bash

اشتراک‌گذاری IPC میان کانتینرها (Sharing IPC between containers)

با استفاده از shm_server.c موجود در: https://www.cs.cf.ac.uk/Dave/C/node27.html

آزمایش حالت --ipc=host:

میزبان یک بخش حافظه اشتراکی با ۷ پردازش متصل را نشان می‌دهد، که متعلق به httpd است:

$ sudo ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x01128e25 0          root       600        1000       7

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

$ docker run -it shm ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

یک کانتینر با گزینه جدید --ipc=host اجرا کنید، اکنون بخش حافظه اشتراکی میزبان از httpd را می‌بیند:

$ docker run -it --ipc=host shm ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x01128e25 0          root       600        1000       7

آزمایش حالت --ipc=container:CONTAINERID:

شروع یک کانتینر همراه با برنامه‌ای برای ایجاد یک بخش حافظه اشتراکی:

$ 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

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

$ docker run shm ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

ایجاد کانتینر سوم با استفاده از گزینه جدید --ipc=container:CONTAINERID؛ اکنون بخش حافظه اشتراکی کانتینر اول را نشان می‌دهد:

$ 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

پیوند دادن کانتینرها (Linking Containers)

قابلیت link به چندین کانتینر اجازه می‌دهد با یکدیگر ارتباط برقرار کنند. برای مثال، کانتینری که در Dockerfile آن درگاه 80 اکسپوز شده است می‌تواند به صورت زیر اجرا و نام‌گذاری شود:

# docker run --name=link-test -d -i -t fedora/httpd

کانتینر دومی که در این مورد linker نامیده می‌شود، می‌تواند با استفاده از --link=: با کانتینر httpd با نام link-test ارتباط برقرار کند:

# docker run -t -i --link=link-test:lt --name=linker fedora /bin/bash

اکنون کانتینر linker با نام مستعار lt به کانتینر link-test پیوند داده شده است. اجرای دستور env در کانتینر linker متغیرهای محیطی با پیشوند LT (نام مستعار) (LT_) را نمایش می‌دهد:

# 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

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

اگر یک کانتینر به شبکه پل (bridge) پیش‌فرض متصل باشد و با کانتینرهای دیگر linked شده باشد، فایل /etc/hosts کانتینر با نام کانتینر پیوندیافته به‌روزرسانی می‌شود.

نگاشت درگاه‌ها برای استفاده خارجی (Mapping Ports for External Usage)

درگاه اکسپوز شده یک برنامه می‌تواند با استفاده از فلگ -p به یک درگاه میزبان نگاشت شود. برای مثال، درگاه 80 مربوط به httpd می‌تواند با استفاده از دستور زیر به درگاه 8080 میزبان نگاشت شود:

# docker run -p 8080:80 -d -i -t fedora/httpd

ایجاد و سوار کردن کانتینر داده (Creating and Mounting a Data Volume Container)

بسیاری از برنامه‌ها نیاز به اشتراک‌گذاری داده‌های ماندگار در میان چندین کانتینر دارند. داکر به شما اجازه می‌دهد یک Data Volume Container ایجاد کنید که سایر کانتینرها بتوانند از آن سوار شوند. برای مثال، یک کانتینر نام‌گذاری‌شده ایجاد کنید که شامل دایرکتوری‌های var/volume1/ و tmp/volume2/ باشد. ایمیج باید شامل این دایرکتوری‌ها باشد بنابراین ممکن است چند دستور RUN mkdir برای ایمیج fedora-data نیاز باشد:

# 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

پارامترهای چندگانه --volumes-from چندین حجم داده را از چندین کانتینر گرد هم می‌آورد. و امکان سوار کردن حجم‌هایی که از کانتینر DATA آمده‌اند در یک کانتینر دیگر از طریق کانتینر واسط fedora-container1 وجود دارد، که امکان تفکیک منبع داده واقعی از کاربران آن داده را فراهم می‌سازد:

# docker run --volumes-from=fedora-container1 --name=fedora-container2 -i -t fedora bash

سوار کردن حجم‌های خارجی (Mounting External Volumes)

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

# docker run -v /var/db:/data1 -i -t fedora bash

هنگام استفاده از SELinux، توجه داشته باشید که میزبان اطلاعی از سیاست SELinux کانتینر ندارد. بنابراین در مثال بالا، اگر سیاست SELinux اعمال شده باشد، دایرکتوری /var/db برای کانتینر قابل نوشتن نخواهد بود. یک پیام "Permission Denied" و یک پیام :avc در syslog میزبان رخ خواهد داد.

برای رفع این مشکل، در زمان نگارش این صفحه راهنما، دستور زیر باید اجرا شود تا برچسب نوع سیاست SELinux مناسب به دایرکتوری میزبان متصل گردد:

# chcon -Rt svirt_sandbox_file_t /var/db

اکنون، نوشتن در حجم data1/ درون کانتینر مجاز خواهد بود و تغییرات نیز در var/db/ روی میزبان منعکس می‌شود.

استفاده از برچسب‌گذاری امنیتی جایگزین (Using alternative security labeling)

می‌توانید طرح برچسب‌گذاری پیش‌فرض برای هر کانتینر را با مشخص کردن فلگ --security-opt بازنویسی کنید. برای مثال، می‌توانید سطح MCS/MLS را که یک الزام برای سیستم‌های MLS است مشخص نمایید. تعیین سطح در دستور زیر به شما امکان می‌دهد محتوای یکسانی را میان کانتینرها به اشتراک بگذارید:

# docker run --security-opt label=level:s0:c100,c200 -i -t fedora bash

یک مثال MLS می‌تواند چنین باشد:

# docker run --security-opt label=level:TopSecret -i -t rhel7 bash

برای غیرفعال کردن برچسب‌گذاری امنیتی برای این کانتینر در مقایسه با اجرا با فلگ --permissive، از دستور زیر استفاده کنید:

# docker run --security-opt label=disable -i -t fedora bash

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

# docker run --security-opt label=type:svirt_apache_t -i -t centos bash

نکته:

شما باید سیاستی را بنویسید که یک نوع svirt_apache_t را تعریف کند.

تنظیم وزن دستگاه (Setting device weight)

اگر می‌خواهید وزن دستگاه /dev/sda را روی 200 تنظیم کنید، می‌توانید وزن دستگاه را با فلگ --blkio-weight-device تعیین کنید. از دستور زیر استفاده نمایید:

# docker run -it --blkio-weight-device "/dev/sda:200" ubuntu

تعیین فناوری جداسازی برای کانتینر (--isolation) (Specify isolation technology for container (--isolation))

این گزینه در شرایطی مفید است که کانتینرهای داکر را روی Microsoft Windows اجرا می‌کنید. گزینه --isolation <value> فناوری جداسازی کانتینر را تنظیم می‌کند. در لینوکس، تنها گزینه پشتیبانی‌شده default است که از فضاهای نام لینوکس استفاده می‌کند. این دو دستور در لینوکس معادلند:

$ docker run -d busybox top
$ docker run -d --isolation default busybox top

در Microsoft Windows، این گزینه می‌تواند هر یک از این مقادیر را بپذیرد:

• default: استفاده از مقدار مشخص‌شده توسط --exec-opt در دیمن داکر. اگر daemon فناوری جداسازی را مشخص نکند، Microsoft Windows از process به عنوان مقدار پیش‌فرض استفاده می‌کند.
• process: فقط جداسازی فضای‌نام (Namespace isolation).
• hyperv: جداسازی مبتنی بر افراز هایپروایزر Hyper-V.

در عمل، هنگام اجرا در Microsoft Windows بدون تنظیم گزینه daemon، این دو دستور معادلند:

$ docker run -d --isolation default busybox top
$ docker run -d --isolation process busybox top

اگر گزینه --exec-opt isolation=hyperv را روی دیمن داکر تنظیم کرده باشید، هر یک از این دستورات نیز به جداسازی hyperv منجر می‌شوند:

$ docker run -d --isolation default busybox top
$ docker run -d --isolation hyperv busybox top

تنظیم پارامترهای کرنل دارای فضای‌نام (Sysctls) (Setting Namespaced Kernel Parameters (Sysctls))

گزینه --sysctl پارامترهای کرنل دارای فضای‌نام (sysctls) را در کانتینر تنظیم می‌کند. برای مثال، جهت فعال‌سازی هدایت IP (IP forwarding) در فضای‌نام شبکه کانتینرها، این دستور را اجرا کنید:

$ docker run --sysctl net.ipv4.ip_forward=1 someimage

نکته:

همه sysctlها دارای فضای‌نام نیستند. داکر از تغییر دادن آن دسته از sysctlها درون کانتینر که سیستم میزبان را نیز تغییر می‌دهند پشتیبانی نمی‌کند. با تکامل کرنل انتظار می‌رود sysctlهای بیشتری دارای فضای‌نام شوند.

برای فهرست کنونی sysctlهای پشتیبانی‌شده، شرح گزینه --sysctl را در بالا ببینید.

تاریخچه (HISTORY)

آوریل ۲۰۱۴، گردآوری اولیه توسط ویلیام هنری William Henry (whenry at redhat dot com) بر اساس منابع docker.com و کارهای داخلی. ژوئن ۲۰۱۴، به‌روزرسانی توسط Sven Dowideit SvenDowideit@home.org.au ⟨mailto:SvenDowideit@home.org.au⟩ ژوئیه ۲۰۱۴، به‌روزرسانی توسط Sven Dowideit SvenDowideit@home.org.au ⟨mailto:SvenDowideit@home.org.au⟩ نوامبر ۲۰۱۵، به‌روزرسانی توسط Sally O'Malley somalley@redhat.com ⟨mailto:somalley@redhat.com⟩

ببینید (SEE ALSO)

docker(1), docker-container-run(1), docker-create(1)