DOCKER(1) Docker User Manuals DOCKER(1)

docker-build - ساخت یک ایمیج از یک Dockerfile

docker build [--add-host[=[]]] [--build-arg[=[]]] [--cache-from[=[]]] [-c|--cpu-shares[=0]] [--cgroup-parent[=CGROUP-PARENT]] [--help] [--iidfile[=IIDFILE]] [-f|--file[=PATH/Dockerfile]] [-squash] Experimental [--force-rm] [--isolation[=default]] [--label[=[]]] [--no-cache] [--pull] [--compress] [-q|--quiet] [--rm[=true]] [-t|--tag[=[]]] [-m|--memory[=MEMORY]] [--memory-swap[=LIMIT]] [--network[="default"]] [--shm-size[=SHM-SIZE]] [--cpu-period[=0]] [--cpu-quota[=0]] [--cpuset-cpus[=CPUSET-CPUS]] [--cpuset-mems[=CPUSET-MEMS]] [--target[=[]]] [--ulimit[=[]]] PATH | URL | -

این دستور Dockerfile را از دایرکتوری مشخص‌شده در PATH می‌خواند. همچنین هر فایل و دایرکتوری دیگری که در دایرکتوری جاری یافت شود را به دیمن Docker ارسال می‌کند. محتویات این دایرکتوری توسط دستورات ADD موجود در Dockerfile استفاده خواهد شد.

هشدار: بسته به محتویات دایرکتوری جاری، این کار حجم زیادی از داده‌ها را به دیمن Docker ارسال خواهد کرد. فرایند ساخت توسط دیمن Docker اجرا می‌شود نه توسط CLI، بنابراین کل بافت (context) باید به دیمن منتقل شود. ابزار CLI داکر هنگام ارسال بافت به دیمن عبارت "Sending build context to Docker daemon" را گزارش می‌دهد.

هنگامی که یک نشانی URL به بایگانی tarball یا یک Dockerfile تکی ارائه شود، هیچ بافتی از سمت کلاینت به دیمن Docker ارسال نمی‌شود. در این حالت، Dockerfile موجود در ریشه بایگانی و بقیه محتویات بایگانی به عنوان بافت ساخت استفاده می‌شوند. هنگامی که یک مخزن Git به عنوان URL تعیین شود، مخزن به صورت محلی clone شده و سپس به عنوان بافت ارسال می‌گردد.

-f, --file PATH/Dockerfile
مسیر Dockerfile مورد استفاده. اگر مسیر نسبی باشد و شما از یک دایرکتوری محلی عملیات ساخت را انجام می‌دهید، مسیر باید نسبت به آن دایرکتوری سنجیده شود. اگر ساخت را از یک URL دوردست اشاره‌کننده به یک tarball یا یک مخزن Git انجام می‌دهید، مسیر باید نسبت به ریشه بافت دوردست باشد. در تمام موارد، فایل باید درون بافت ساخت (build context) قرار داشته باشد. مقدار پیش‌فرض Dockerfile است.

--squash true|false
تنها به صورت آزمایشی (Experimental Only)
پس از ساخت ایمیج، لایه‌های جدید را در یک لایه واحد درون یک ایمیج تازه ادغام می‌کند (squash). ادغام کردن هیچ‌یک از ایمیج‌های موجود را از بین نمی‌برد، بلکه یک ایمیج جدید با محتوای لایه‌های ادغام‌شده ایجاد می‌کند. این کار عملاً به گونه‌ای جلوه می‌دهد که گویی تمام دستورات Dockerfile در قالب یک لایه ایجاد شده‌اند. با این روش، حافظه موقت ساخت (build cache) حفظ می‌شود.

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

توجه: با استفاده از این گزینه ممکن است به دلیل ذخیره دو نسخه از ایمیج (یکی برای کش ساخت با تمام لایه‌های کش دست‌نخورده، و دیگری نسخه ادغام‌شده)، فضای بسیار بیشتری مصرف شود.

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

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

--build-arg variable
نام و مقدار یک buildarg.

به عنوان مثال، اگر می‌خواهید مقداری را برای http_proxy ارسال کنید، از گزینه زیر استفاده کنید:
--build-arg=http_proxy="http://some.proxy.url"

کاربران این مقادیر را در زمان ساخت ارسال می‌کنند. داکر از buildargs به عنوان بافت محیطی برای دستور(های) اجرا شده از طریق دستورالعمل RUN در Dockerfile یا برای بسط متغیرها در سایر دستورالعمل‌های Dockerfile استفاده می‌کند. این گزینه برای ارسال مقادیر محرمانه مناسب نیست. اطلاعات بیشتر درباره دستورالعمل buildargs: ⟨https://docs.docker.com/engine/reference/builder/#arg⟩

--cache-from ""
تعیین ایمیجی که به عنوان منبع کش ساخت استفاده خواهد شد.

--force-rm true|false
حذف همیشگی کانتینرهای میانی، حتی پس از ساخت‌های ناموفق. مقدار پیش‌فرض false است.

--isolation "default"
نوع فناوری ایزوله‌سازی مورد استفاده توسط کانتینرها را تعیین می‌کند.

--label label
تنظیم متادیتا برای یک ایمیج

--no-cache true|false
عدم استفاده از کش هنگام ساخت ایمیج. مقدار پیش‌فرض false است.

--iidfile ""
نوشتن شناسه (ID) ایمیج در فایل

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

--pull true|false
تلاش همیشگی برای دریافت نسخه جدیدتر ایمیج (pull). مقدار پیش‌فرض false است.

--compress true|false
فشرده‌سازی بافت ساخت با استفاده از gzip. مقدار پیش‌فرض false است.

-q, --quiet true|false
بی‌صدا کردن خروجی ساخت و چاپ شناسه ایمیج در صورت موفقیت. مقدار پیش‌فرض false است.

--rm true|false
حذف کانتینرهای میانی پس از یک ساخت موفقیت‌آمیز. مقدار پیش‌فرض true است.

-t, --tag ""
نام‌های مخزن (و در صورت تمایل همراه با تگ‌ها) برای اعمال به ایمیج حاصل در صورت موفقیت. برای اطلاعات بیشتر درباره نام‌های معتبر تگ، به docker-tag(1) مراجعه کنید.

-m, --memory MEMORY
محدودیت حافظه

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

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

--network type
تنظیم حالت شبکه برای دستورالعمل‌های RUN در طول ساخت. مقادیر استاندارد پشتیبانی‌شده عبارتند از: none، bridge، host و container:<name|id>. هر مقدار دیگری به عنوان نام یا شناسه یک شبکه سفارشی در نظر گرفته می‌شود که این کانتینر باید به آن متصل گردد.

در لینوکس، مقدار پیش‌فرض bridge است.

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

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

به طور پیش‌فرض، همه کانتینرها سهم یکسانی از چرخه‌های پردازنده دریافت می‌کنند.
سهم پردازنده یک «وزن نسبی» است که نسبت به تنظیم پیش‌فرض ۱۰۲۴ سنجیده می‌شود.
این مقدار پیش‌فرض در اینجا تعریف شده است:

cat /sys/fs/cgroup/cpu/cpu.shares
1024

می‌توانید این نسبت را با تنظیم وزن سهم پردازنده کانتینر نسبت به وزن تمام کانتینرهای دیگر در حال اجرا تغییر دهید.

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

Container   CPU share    Flag
{C0}        60% of CPU  --cpu-shares 614 (614 is 60% of 1024)
{C1}        40% of CPU  --cpu-shares 410 (410 is 40% of 1024)

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

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

Container   CPU share   Flag                CPU time
{C0}        100%        --cpu-shares 1024   33%
{C1}        50%         --cpu-shares 512    16.5%
{C2}        50%         --cpu-shares 512    16.5%
{C4}        100%        --cpu-shares 1024   33%

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

به عنوان مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر یک کانتینر {C0} را با --cpu-shares 512 و در حال اجرای یک فرایند شروع کنید، و کانتینر دیگری {C1} را با --cpu-shares 1024 و در حال اجرای دو فرایند اجرا نمایید، این امر می‌تواند منجر به تقسیم زیر در سهم‌های پردازنده شود:

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

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

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

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

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

--cpuset-cpus CPUSET-CPUS
پردازنده‌هایی که اجرای کانتینر در آن‌ها مجاز است (0-3, 0,1).

--cpuset-mems CPUSET-MEMS
گره‌های حافظه (MEMها) که اجازه اجرا در آن‌ها وجود دارد (0-3, 0,1). تنها روی سیستم‌های NUMA مؤثر است.

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

--cgroup-parent CGROUP-PARENT
مسیری به cgroupها که cgroup کانتینر تحت آن ایجاد می‌شود.

اگر مسیر مطلق نباشد، مسیر نسبت به مسیر cgroups فرایند init سنجیده می‌شود. اگر cgroupها از قبل وجود نداشته باشند، ایجاد خواهند شد.

--target ""
تنظیم نام مرحله هدف ساخت (target build stage).

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

برای اطلاعات بیشتر درباره ulimit بخش Setting ulimits in a container را ببینید: ⟨https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit⟩

ایمیج‌های داکر را می‌توان با استفاده از دستور build و یک Dockerfile ساخت:

docker build .

در طول فرایند ساخت، داکر ایمیج‌های میانی ایجاد می‌کند. برای نگه‌داشتن آن‌ها، باید صراحتاً --rm false را تنظیم کنید.

docker build --rm false .

یک شیوه کاری خوب این است که یک زیردایرکتوری با نام مرتبط بسازید و Dockerfile را در آن دایرکتوری ایجاد کنید. به عنوان مثال، دایرکتوری به نام mongo می‌تواند حاوی یک Dockerfile برای ساخت یک ایمیج داکر MongoDB باشد. به همین ترتیب، دایرکتوری دیگری با نام httpd می‌تواند برای ذخیره Dockerfileهای ایمیج‌های وب‌سرور Apache استفاده شود.

همچنین یک شیوه کاری مناسب این است که فایل‌های مورد نیاز ایمیج را به زیردایرکتوری اضافه کنید. این فایل‌ها سپس با دستورالعمل‌های COPY یا ADD در Dockerfile مشخص خواهند شد.

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

یک شیوه کاری مناسب این است که به ایمیجی که می‌سازید نام اختصاص دهید. توجه داشته باشید که برای حفظ سازگاری فقط باید از a-z0-9-_. استفاده شود. قانون سختی در اینجا وجود ندارد، اما بهتر است به نام‌گذاری‌ها توجه کافی داشته باشید.

فلگ -t/--tag برای نام‌گذاری مجدد یا تگ‌گذاری یک ایمیج استفاده می‌شود. در اینجا چند مثال آورده شده است:

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

docker build -t myimage .

رویکرد بهتر این است که یک نام مخزن کامل، معنی‌دار و تگ مشخص ارائه دهید (که تگ در این زمینه به معنای مشخص‌کننده بعد از ":" است). در این مثال ما یک ایمیج JBoss برای مخزن Fedora می‌سازیم و نسخه 1.0 را به آن اختصاص می‌دهیم:

docker build -t fedora/jboss:1.0 .

مثال بعدی برای مخزن کاربری "whenry" است که از Fedora و JBoss استفاده می‌کند و به آن نسخه 2.1 را اختصاص می‌دهد:

docker build -t whenry/fedora-jboss:v2.1 .

اگر تگ نسخه ارائه ندهید، داکر تگ latest را اختصاص خواهد داد:

docker build -t whenry/fedora-jboss .

هنگامی که لیست ایمیج‌ها را مشاهده می‌کنید، ایمیج بالا دارای تگ latest خواهد بود.

می‌توانید چندین تگ را به یک ایمیج اختصاص دهید. به عنوان مثال، می‌توانید تگ latest را به یک ایمیج تازه‌ساخته‌شده اختصاص دهید و تگ دیگری اضافه کنید که به یک نسخه خاص اشاره کند. به عنوان مثال، برای تگ‌گذاری یک ایمیج هم به عنوان whenry/fedora-jboss:latest و هم whenry/fedora-jboss:v2.1، از دستور زیر استفاده کنید:

docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 .

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

این کار مخزن مشخص‌شده GitHub را از نشانی URL کلون کرده و از آن به عنوان بافت استفاده می‌کند. فایل Dockerfile در ریشه مخزن به عنوان Dockerfile استفاده می‌شود. این قابلیت تنها در صورتی کار می‌کند که مخزن GitHub یک مخزن اختصاصی باشد.

docker build github.com/scollier/purpletest

توجه: می‌توانید یک مخزن Git دلخواه را از طریق طرح‌واره git:// تعیین کنید.

این دستور خودِ نشانی URL را به دیمن Docker ارسال می‌کند. دیمن بایگانی tarball را دریافت کرده، آن را از حالت فشرده خارج می‌کند و از محتویات آن به عنوان بافت ساخت استفاده می‌نماید. فایل Dockerfile در ریشه بایگانی و بقیه محتویات به عنوان بافت ساخت استفاده خواهند شد. اگر گزینه -f PATH/Dockerfile را نیز ارسال کنید، سیستم به دنبال آن فایل در میان محتویات فایل tarball خواهد گشت.

docker build -f dev/Dockerfile https://10.10.10.1/docker/context.tar.gz

توجه: فرمت‌های فشرده‌سازی پشتیبانی‌شده عبارتند از 'xz'، 'bzip2'، 'gzip' و 'identity' (بدون فشرده‌سازی).

این گزینه در شرایطی کاربرد دارد که کانتینرهای Docker را روی ویندوز اجرا می‌کنید. گزینه --isolation <value> فناوری ایزوله‌سازی کانتینر را تعیین می‌کند. در لینوکس، تنها گزینه پشتیبانی‌شده گزینه default است که از namespaceهای لینوکس استفاده می‌کند. در مایکروسافت ویندوز، می‌توانید این مقادیر را مشخص کنید:

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

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

JUNE 2014 Docker Community