.nh .TH "DOCKERFILE" "5" "MAY 2014" "Docker Community" "Docker User Manuals" .SH "نام (NAME)" Dockerfile \- خودکارسازی مراحل ایجاد ایمیج Docker .SH "مقدمه (INTRODUCTION)" پرونده \fBDockerfile\fP یک فایل پیکربندی است که مراحل ایجاد یک ایمیج Docker را خودکار می‌کند. این فایل مشابه Makefile است. Docker دستورالعمل‌ها را از \fBDockerfile\fP می‌خواند تا مراحلی را که در غیر این صورت برای ایجاد ایمیج به صورت دستی انجام می‌شدند، خودکار سازد. برای ساخت یک ایمیج، فایلی به نام \fBDockerfile\fP ایجاد کنید. .PP پرونده \fBDockerfile\fP مراحل انجام‌شده برای سرهم‌بندی ایمیج را توصیف می‌کند. پس از ایجاد \fBDockerfile\fP\&، دستور \fBdocker build\fR را فراخوانی کنید و مسیر دایرکتوری حاوی \fBDockerfile\fP را به عنوان آرگومان به آن بدهید. .SH "خلاصه دستور (SYNOPSIS)" INSTRUCTION arguments .PP برای مثال: .PP FROM image .SH "شرح (DESCRIPTION)" پرونده Dockerfile فایلی است که مراحل ایجاد یک ایمیج Docker را خودکار می‌کند. یک Dockerfile شبیه به یک Makefile است. .SH "نحوه استفاده (USAGE)" docker build . .PP \-\- مراحل را اجرا کرده و آنها را کامیت می‌کند، و یک ایمیج نهایی می‌سازد. مسیر منتهی به مخزن مبدأ مشخص می‌کند زمینه (context) ساخت کجا پیدا شود. ساخت توسط دیمن Docker اجرا می‌شود، نه CLI. کل زمینه باید به دیمن منتقل شود. هنگامی که زمینه به دیمن ارسال می‌شود، Docker CLI پیام \fB"Sending build context to Docker daemon"\fR را گزارش می‌دهد. .EX docker build -t repository/tag . .EE .PP \-\- یک مخزن و یک برچسب (tag) را مشخص می‌کند که ایمیج جدید در صورت موفقیت‌آمیز بودن فرآیند ساخت در آن ذخیره شود. دیمن Docker مراحل را یکی پس از دیگری اجرا کرده، در صورت لزوم نتیجه را در یک ایمیج جدید کامیت می‌کند و در نهایت شناسه (ID) ایمیج جدید را در خروجی نمایش می‌دهد. دیمن Docker به طور خودکار زمینه‌ای را که دریافت کرده پاکسازی می‌کند. .PP Docker هر زمان که ممکن باشد از ایمیج‌های میانی مجدداً استفاده می‌کند. این کار فرآیند \fIdocker build\fP را به طور چشمگیری سریع‌تر می‌کند. .SH "قالب (FORMAT)" \fBFROM image\fR .PP \fBFROM image:tag\fR .PP \fBFROM image@digest\fR .PP \-\- دستورالعمل \fBFROM\fP ایمیج پایه را برای دستورالعمل‌های بعدی مشخص می‌کند. یک Dockerfile معتبر باید \fBFROM\fP را به عنوان نخستین دستورالعمل خود داشته باشد. ایمیج می‌تواند هر ایمیج معتبری باشد. شروع کار با دریافت (pull) یک ایمیج از مخازن عمومی آسان است. .PP \-\- دستورالعمل \fBFROM\fP باید نخستین دستورالعمل غیرکامنت در Dockerfile باشد. .PP \-\- دستورالعمل \fBFROM\fP می‌تواند چندین بار در یک Dockerfile ظاهر شود تا چندین ایمیج ایجاد کند. شناسه آخرین ایمیج تولیدشده توسط کامیت را قبل از هر دستور جدید \fBFROM\fP یادداشت کنید. .PP \-\- اگر هیچ برچسبی (tag) به دستورالعمل \fBFROM\fP داده نشود، Docker تگ \fBlatest\fR را اعمال می‌کند. اگر تگ استفاده‌شده وجود نداشته باشد، یک خطا برگردانده می‌شود. .PP \-\- اگر هیچ دایجستی (digest) به دستورالعمل \fBFROM\fP داده نشود، Docker تگ \fBlatest\fR را اعمال می‌کند. اگر تگ استفاده‌شده وجود نداشته باشد، یک خطا برگردانده می‌شود. .PP \fBMAINTAINER\fP \-\- فیلد Author را برای ایمیج‌های تولیدشده تنظیم می‌کند. برای ارائه یک ایمیل یا آدرس اینترنتی (URL) جهت پشتیبانی به کاربران مفید است. .PP \fBRUN\fP \-\- دستورالعمل \fBRUN\fP دارای دو شکل است: .EX # the command is run in a shell - /bin/sh -c RUN # Executable form RUN ["executable", "param1", "param2"] .EE .PP \-\- دستورالعمل \fBRUN\fP هر دستوری را در یک لایه جدید روی ایمیج فعلی اجرا کرده و نتایج را کامیت می‌کند. ایمیج کامیت‌شده برای مرحله بعدی در Dockerfile استفاده می‌شود. .PP \-\- لایه‌بندی دستورالعمل‌های \fBRUN\fP و ایجاد کامیت‌ها با مفاهیم اصلی Docker مطابقت دارد، جایی که کامیت‌ها کم‌هزینه هستند و کانتینرها را می‌توان از هر نقطه‌ای در تاریخچه یک ایمیج ایجاد کرد. این شبیه به سیستم‌های کنترل نسخه است. فرمت exec امکان جلوگیری از دگرگونی رشته شل (shell string munging) را فراهم می‌کند. فرمت exec امکان اجرای دستورات \fBRUN\fP را با استفاده از یک ایمیج پایه که فاقد \fB/bin/sh\fR است فراهم می‌سازد. .PP توجه داشته باشید که فرمت exec به عنوان یک آرایه JSON تجزیه می‌شود، به این معنی که باید از نقل‌قول دوگانه (") در اطراف کلمات استفاده کنید نه نقل‌قول تکی ('). .PP \fBCMD\fP \-\- دستورالعمل \fBCMD\fP سه شکل دارد: .EX # Executable form CMD ["executable", "param1", "param2"] # Provide default arguments to ENTRYPOINT CMD ["param1", "param2"] # the command is run in a shell - /bin/sh -c CMD command param1 param2 .EE .PP \-\- باید تنها یک دستورالعمل \fBCMD\fP در یک Dockerfile وجود داشته باشد. اگر بیش از یک \fBCMD\fP درج شود، تنها آخرین \fBCMD\fP اعمال خواهد شد. هدف اصلی یک \fBCMD\fP ارائه مقادیر پیش‌فرض برای یک کانتینر در حال اجرا است. این پیش‌فرض‌ها ممکن است شامل یک فایل اجرایی باشند، یا می‌توانند فایل اجرایی را حذف کنند. اگر فایل اجرایی را حذف کنند، باید یک \fBENTRYPOINT\fP مشخص شود. هنگامی که در قالب‌های shell یا exec استفاده می‌شود، دستورالعمل \fBCMD\fP دستوری را که باید هنگام اجرای ایمیج اجرا شود تعیین می‌کند. اگر از فرم شل \fBCMD\fP استفاده کنید، \fB\fR در \fB/bin/sh -c\fR اجرا می‌شود: .PP توجه داشته باشید که فرمت exec به عنوان یک آرایه JSON تجزیه می‌شود، به این معنی که باید از نقل‌قول دوگانه (") در اطراف کلمات استفاده کنید نه نقل‌قول تکی ('). .EX FROM ubuntu CMD echo "This is a test." | wc - .EE .PP \-\- اگر \fBcommand\fP را بدون شل اجرا می‌کنید، باید دستور را به صورت یک آرایه JSON بنویسید و مسیر کامل به فایل اجرایی را ارائه دهید. این فرم آرایه‌ای، شکل ارجح \fBCMD\fP\& است. تمام پارامترهای اضافی باید به صورت جداگانه به عنوان رشته در آرایه مشخص شوند: .EX FROM ubuntu CMD ["/usr/bin/wc","--help"] .EE .PP \-\- برای اینکه کانتینر هر بار همان فایل اجرایی یکسان را اجرا کند، از \fBENTRYPOINT\fP در ترکیب با \fBCMD\fP استفاده کنید. اگر کاربر آرگومان‌هایی را برای \fBdocker run\fR مشخص کند، دستورات مشخص‌شده مقادیر پیش‌فرض را در \fBCMD\fP بازنویسی می‌کنند. \fBRUN\fP را با \fBCMD\fP اشتباه نگیرید. \fBRUN\fP یک دستور را اجرا کرده و نتیجه را کامیت می‌کند. \fBCMD\fP در زمان ساخت هیچ چیزی اجرا نمی‌کند، بلکه دستور مورد نظر را برای ایمیج تعیین می‌نماید. .PP \fBLABEL\fP \-\- \fBLABEL = [= ...]\fR یا .EX LABEL [ ] LABEL [ ] ... .EE .PP دستورالعمل \fBLABEL\fP متادیتا را به یک ایمیج اضافه می‌کند. یک \fBLABEL\fP یک جفت کلید-مقدار (key-value) است. برای مشخص کردن یک \fBLABEL\fP بدون مقدار، کافی است از یک رشته خالی استفاده کنید. برای گنجاندن فاصله درون مقدار یک \fBLABEL\fP\&، از نقل‌قول و بک‌اسلش همان‌طور که در پردازش خط فرمان انجام می‌دهید استفاده کنید. .EX LABEL com.example.vendor="ACME Incorporated" LABEL com.example.vendor "ACME Incorporated" LABEL com.example.vendor.is-beta "" LABEL com.example.vendor.is-beta= LABEL com.example.vendor.is-beta="" .EE .PP یک ایمیج می‌تواند بیش از یک برچسب (label) داشته باشد. برای مشخص کردن چندین برچسب، هر جفت کلید-مقدار را با یک فاصله جدا کنید. .PP برچسب‌ها خاصیت افزایشی دارند، از جمله \fBLABEL\fRها در ایمیج‌های \fBFROM\fR\&. هنگامی که سیستم با یک برچسب جدید مواجه شده و آن را اعمال می‌کند، \fBkey\fRهای جدید جایگزین هر برچسب قبلی با کلیدهای یکسان می‌شوند. .PP برای نمایش برچسب‌های یک ایمیج، از دستور \fBdocker inspect\fR استفاده کنید. .PP \fBSTOPSIGNAL\fP .PP \-\- \fBSTOPSIGNAL \fR دستورالعمل \fBSTOPSIGNAL\fP سیگنال فراخوانی سیستمی را تنظیم می‌کند که برای خروج به کانتینر ارسال خواهد شد. این سیگنال می‌تواند یک نام سیگنال در قالب \fBSIG\fP\&، برای مثال \fBSIGKILL\fP\&، یا یک عدد بدون علامت باشد که با موقعیتی در جدول syscall هسته مطابقت دارد، برای مثال \fB9\fP\&. در صورت عدم تعیین، مقدار پیش‌فرض \fBSIGTERM\fP است. .PP سیگنال خروج پیش‌فرض ایمیج را می‌توان به ازای هر کانتینر با استفاده از پرچم \fB--stop-signal\fP در \fBdocker-run(1)\fP و \fBdocker-create(1)\fP بازنویسی کرد. .PP \fBEXPOSE\fP \-\- \fBEXPOSE [...]\fR دستورالعمل \fBEXPOSE\fP به Docker اطلاع می‌دهد که کانتینر در زمان اجرا به پورت‌های شبکه مشخص‌شده گوش می‌دهد. Docker از این اطلاعات برای برقراری ارتباط متقابل میان کانتینرها با استفاده از لینک‌ها و تنظیم بازهدایت پورت (port redirection) روی سیستم میزبان استفاده می‌کند. .PP \fBENV\fP \-\- \fBENV \fR دستورالعمل \fBENV\fP متغیر محیطی را روی مقدار \fB\fR تنظیم می‌کند. این مقدار به تمام دستورالعمل‌های بعدی \fBRUN\fP\&، \fBENTRYPOINT\fP و \fBCMD\fP ارسال می‌شود. این از نظر عملکرد معادل پیشوند قرار دادن \fB=\fR قبل از دستور است. متغیرهای محیطی که با \fBENV\fP تنظیم می‌شوند، هنگام اجرای یک کانتینر از ایمیج حاصل پایدار می‌مانند. از \fBdocker inspect\fR برای بررسی این مقادیر استفاده کنید و با استفاده از \fBdocker run --env =\fR آنها را تغییر دهید. .PP توجه داشته باشید که تنظیم "\fBENV DEBIAN_FRONTEND=noninteractive\fR" ممکن است عواقب ناخواسته‌ای داشته باشد، زیرا هنگام اجرای تعاملی کانتینر، مانند دستور زیر، پایدار خواهد ماند: \fBdocker run -t -i image bash\fR .PP \fBADD\fP \-\- دستورالعمل \fBADD\fP دو شکل دارد: .EX ADD # Required for paths with whitespace ADD ["",... ""] .EE .PP دستورالعمل \fBADD\fP فایل‌ها، دایرکتوری‌های جدید یا URLهای فایل‌های راه دور را در فایل‌سیستم کانتینر در مسیر \fB\fR کپی می‌کند. منابع چندگانه \fB\fR را می‌توان مشخص کرد، اما اگر آنها فایل یا دایرکتوری باشند باید نسبت به دایرکتوری مبدأ که در حال ساخت است (زمینه ساخت) نسبی باشند. مقدار \fB\fR یک مسیر مطلق یا مسیر نسبی به \fBWORKDIR\fP است که مبدأ در داخل کانتینر مقصد در آن کپی می‌شود. اگر آرگومان \fB\fR یک فایل محلی در یک فرمت فشرده‌سازی شناخته‌شده (tar, gzip, bzip2 و غیره) باشد، در مسیر \fB\fR مشخص‌شده در فایل‌سیستم کانتینر باز (unpack) می‌شود. توجه داشته باشید که تنها فایل‌های فشرده محلی باز خواهند شد، به این معنی که ویژگی‌های دانلود URL و باز کردن آرشیو نمی‌توانند با هم استفاده شوند. تمام دایرکتوری‌های جدید با مجوز 0755 و با uid و gid برابر با \fB0\fP ایجاد می‌شوند. .PP \fBCOPY\fP \-\- دستورالعمل \fBCOPY\fP دو شکل دارد: .EX COPY # Required for paths with whitespace COPY ["",... ""] .EE .PP دستورالعمل \fBCOPY\fP فایل‌های جدید را از \fB\fR کپی کرده و به فایل‌سیستم کانتینر در مسیر مشخص‌شده اضافه می‌کند. مقدار \fB\fR باید مسیر یک فایل یا دایرکتوری نسبی به دایرکتوری مبدأ باشد که در حال ساخت است (زمینه ساخت) یا یک URL فایل راه دور. مقدار \fB\fR یک مسیر مطلق یا مسیر نسبی به \fBWORKDIR\fP است که مبدأ در داخل کانتینر مقصد در آن کپی خواهد شد. اگر یک فایل آرشیو را \fBCOPY\fP کنید، دقیقاً همان‌طور که در زمینه ساخت ظاهر می‌شود در کانتینر قرار می‌گیرد، بدون اینکه تلاشی برای باز کردن آن انجام شود. تمام فایل‌ها و دایرکتوری‌های جدید با مجوز \fB0755\fP و با uid و gid برابر با \fB0\fP ایجاد می‌شوند. .PP \fBENTRYPOINT\fP \-\- دستورالعمل \fBENTRYPOINT\fP دو شکل دارد: .EX # executable form ENTRYPOINT ["executable", "param1", "param2"] # run command in a shell - /bin/sh -c ENTRYPOINT command param1 param2 .EE .PP \-\- یک \fBENTRYPOINT\fP به شما کمک می‌کند کانتینری را پیکربندی کنید که بتواند به عنوان یک فایل اجرایی اجرا شود. هنگامی که یک \fBENTRYPOINT\fP را مشخص می‌کنید، کل کانتینر طوری اجرا می‌شود که گویی فقط همان فایل اجرایی است. دستورالعمل \fBENTRYPOINT\fP یک دستور ورودی اضافه می‌کند که با ارسال آرگومان‌ها به docker run بازنویسی نمی‌شود. این متفاوت از رفتار \fBCMD\fP است. این امر اجازه می‌دهد تا آرگومان‌ها به entrypoint ارسال شوند، به عنوان مثال \fBdocker run -d\fR آرگومان -d را به \fBENTRYPOINT\fP ارسال می‌کند. پارامترها را یا در آرایه JSON دستورالعمل \fBENTRYPOINT\fP (همانند فرم ارجح exec در بالا)، یا با استفاده از یک عبارت \fBCMD\fP مشخص کنید. پارامترهای درون \fBENTRYPOINT\fP توسط آرگومان‌های docker run بازنویسی نمی‌شوند. پارامترهای مشخص‌شده از طریق \fBCMD\fP توسط آرگومان‌های docker run بازنویسی می‌شوند. یک رشته ساده را برای \fBENTRYPOINT\fP مشخص کنید، و آن همانند یک دستورالعمل \fBCMD\fP در \fB/bin/sh -c\fR اجرا خواهد شد: .EX FROM ubuntu ENTRYPOINT wc -l - .EE .PP این بدان معناست که ایمیج این Dockerfile همیشه ورودی استاندارد (stdin) را به عنوان ورودی می‌گیرد (این معنای "-" است)، و تعداد خطوط را چاپ می‌کند (این معنای "-l" است). برای اینکه این رفتار اختیاری اما پیش‌فرض باشد، از یک \fBCMD\fP استفاده کنید: .EX FROM ubuntu CMD ["-l", "-"] ENTRYPOINT ["/usr/bin/wc"] .EE .PP \fBVOLUME\fP \-\- \fBVOLUME ["/data"]\fR دستورالعمل \fBVOLUME\fP یک نقطه اتصال (mount point) با نام مشخص‌شده ایجاد می‌کند و آن را به عنوان نگه‌دارنده حجم‌های متصل‌شده خارجی از میزبان بومی یا از سایر کانتینرها نشانه‌گذاری می‌نماید. .PP \fBUSER\fP \-\- \fBUSER daemon\fR نام کاربری یا UID مورد استفاده برای اجرای دستورات بعدی را تنظیم می‌کند. .PP دستورالعمل \fBUSER\fP را می‌توان به صورت اختیاری برای تنظیم گروه یا GID استفاده کرد. مثال‌های زیر همگی معتبر هستند: .EX USER [user | user:group | uid | uid:gid | user:gid | uid:group ] .EE .PP تا زمانی که دستورالعمل \fBUSER\fP تنظیم نشده باشد، دستورالعمل‌ها به عنوان root اجرا خواهند شد. دستورالعمل USER را می‌توان هر چند بار در یک Dockerfile استفاده کرد، و تنها بر دستورات بعدی تأثیر می‌گذارد. .PP \fBWORKDIR\fP \-\- \fBWORKDIR /path/to/workdir\fR دستورالعمل \fBWORKDIR\fP دایرکتوری کاری را برای دستورات \fBRUN\fP\&، \fBCMD\fP\&، \fBENTRYPOINT\fP\&، \fBCOPY\fP و \fBADD\fP در Dockerfile که پس از آن می‌آیند تنظیم می‌کند. می‌توان از آن چندین بار در یک Dockerfile استفاده کرد. مسیرهای نسبی نسبت به مسیر دستورالعمل \fBWORKDIR\fP قبلی تعریف می‌شوند. برای مثال: .EX WORKDIR /a WORKDIR b WORKDIR c RUN pwd .EE .PP در مثال بالا، خروجی دستور \fBpwd\fP برابر با \fBa/b/c\fP است. .PP \fBARG\fP \-\- ARG [=] .PP دستورالعمل \fBARG\fR متغیری را تعریف می‌کند که کاربران می‌توانند در زمان ساخت با دستور \fBdocker build\fR با استفاده از پرچم \fB--build-arg =\fR به سازنده ارسال کنند. اگر کاربر یک آرگومان ساخت را مشخص کند که در Dockerfile تعریف نشده است، فرآیند ساخت یک هشدار صادر می‌کند. .EX [Warning] One or more build-args [foo] were not consumed .EE .PP نویسنده Dockerfile می‌تواند با یک بار مشخص کردن \fBARG\fR یک متغیر واحد تعریف کند یا با مشخص کردن \fBARG\fR به دفعات، متغیرهای متعددی را تعریف نماید. به عنوان مثال، یک Dockerfile معتبر: .EX FROM busybox ARG user1 ARG buildno ... .EE .PP یک نویسنده Dockerfile ممکن است به صورت اختیاری یک مقدار پیش‌فرض برای یک دستورالعمل \fBARG\fR مشخص کند: .EX FROM busybox ARG user1=someuser ARG buildno=1 ... .EE .PP اگر یک مقدار \fBARG\fR دارای پیش‌فرض باشد و مقداری در زمان ساخت ارسال نشود، سازنده از مقدار پیش‌فرض استفاده می‌کند. .PP تعریف یک متغیر \fBARG\fR از خطی که در آن در \fBDockerfile\fR تعریف شده است اعمال می‌شود، نه از زمان استفاده از آرگومان در خط فرمان یا جای دیگر. برای مثال، این Dockerfile را در نظر بگیرید: .EX 1 FROM busybox 2 USER ${user:-some_user} 3 ARG user 4 USER $user ... .EE .PP کاربر این فایل را با فراخوانی دستور زیر می‌سازد: .EX $ docker build --build-arg user=what_user Dockerfile .EE .PP دستور \fBUSER\fR در خط ۲ به \fBsome_user\fR ارزیابی می‌شود، زیرا متغیر \fBuser\fR در خط ۳ تعریف شده است. دستور \fBUSER\fR در خط ۴ به \fBwhat_user\fR ارزیابی می‌شود، زیرا \fBuser\fR تعریف شده و مقدار \fBwhat_user\fR در خط فرمان ارسال شده بود. پیش از تعریف آن توسط یک دستورالعمل \fBARG\fR\&، هرگونه استفاده از متغیر منجر به یک رشته خالی می‌شود. .PP .RS .PP \fBهشدار:\fP استفاده از متغیرهای زمان ساخت برای انتقال داده‌های محرمانه و اسرار مانند کلیدهای github، اعتبارنامه‌های کاربری و غیره توصیه نمی‌شود. مقادیر متغیرهای زمان ساخت با دستور \fBdocker history\fR برای هر کاربری که به ایمیج دسترسی دارد قابل مشاهده است. .RE .PP می‌توانید از یک دستورالعمل \fBARG\fR یا یک دستورالعمل \fBENV\fR برای مشخص کردن متغیرهایی که در دسترس دستورالعمل \fBRUN\fR هستند استفاده کنید. متغیرهای محیطی تعریف‌شده با دستورالعمل \fBENV\fR همیشه یک دستورالعمل \fBARG\fR هم‌نام را بازنویسی می‌کنند. این Dockerfile را با یک دستورالعمل \fBENV\fR و \fBARG\fR در نظر بگیرید. .EX 1 FROM ubuntu 2 ARG CONT_IMG_VER 3 ENV CONT_IMG_VER=v1.0.0 4 RUN echo $CONT_IMG_VER .EE .PP سپس، فرض کنید این ایمیج با این دستور ساخته شود: .EX $ docker build --build-arg CONT_IMG_VER=v2.0.1 Dockerfile .EE .PP در این حالت، دستورالعمل \fBRUN\fR به جای تنظیمات \fBARG\fR ارسال‌شده توسط کاربر یعنی \fBv2.0.1\fR\&، از \fBv1.0.0\fR استفاده می‌کند. این رفتار مشابه یک اسکریپت شل است که در آن متغیری با محدوده محلی، از نقطه تعریف خود، متغیرهای ارسال‌شده به عنوان آرگومان یا به ارث رسیده از محیط را بازنویسی می‌کند. .PP با استفاده از مثال بالا اما با تعریف متفاوتی از \fBENV\fR می‌توانید تعاملات مفیدتری میان دستورالعمل‌های \fBARG\fR و \fBENV\fR ایجاد کنید: .EX 1 FROM ubuntu 2 ARG CONT_IMG_VER 3 ENV CONT_IMG_VER=${CONT_IMG_VER:-v1.0.0} 4 RUN echo $CONT_IMG_VER .EE .PP برخلاف دستورالعمل \fBARG\fR\&، مقادیر \fBENV\fR همیشه در ایمیج ساخته‌شده پایدار می‌مانند. ساخت داکر را بدون فلگ --build-arg در نظر بگیرید: .EX $ docker build Dockerfile .EE .PP با استفاده از این مثال Dockerfile، مقدار \fBCONT_IMG_VER\fR همچنان در ایمیج پایدار می‌ماند، اما مقدار آن \fBv1.0.0\fR خواهد بود زیرا پیش‌فرضی است که در خط ۳ توسط دستورالعمل \fBENV\fR تنظیم شده است. .PP تکنیک بسط متغیر در این مثال به شما امکان می‌دهد آرگومان‌ها را از خط فرمان ارسال کرده و با بهره‌گیری از دستورالعمل \fBENV\fR آنها را در ایمیج نهایی پایدار سازید. بسط متغیر تنها برای مجموعه محدودی از دستورالعمل‌های Dockerfile پشتیبانی می‌شود. .PP Docker مجموعه‌ای از متغیرهای از پیش تعریف‌شده \fBARG\fR دارد که می‌توانید بدون یک دستورالعمل \fBARG\fR متناظر در Dockerfile از آنها استفاده کنید. .IP \(bu 2 \fBHTTP_PROXY\fR .IP \(bu 2 \fBhttp_proxy\fR .IP \(bu 2 \fBHTTPS_PROXY\fR .IP \(bu 2 \fBhttps_proxy\fR .IP \(bu 2 \fBFTP_PROXY\fR .IP \(bu 2 \fBftp_proxy\fR .IP \(bu 2 \fBNO_PROXY\fR .IP \(bu 2 \fBno_proxy\fR .IP \(bu 2 \fBALL_PROXY\fR .IP \(bu 2 \fBall_proxy\fR .PP برای استفاده از این موارد، آنها را در خط فرمان با استفاده از پرچم \fB--build-arg\fR ارسال کنید، به عنوان مثال: .EX $ docker build --build-arg HTTPS_PROXY=https://my-proxy.example.com . .EE .PP \fBONBUILD\fP \-\- \fBONBUILD [INSTRUCTION]\fR دستورالعمل \fBONBUILD\fP یک دستورالعمل محرک (trigger) به یک ایمیج اضافه می‌کند. این محرک در زمان دیگری اجرا می‌شود، زمانی که ایمیج به عنوان پایه برای ساخت دیگری استفاده شود. Docker محرک را در زمینه ساخت پایین‌دستی اجرا می‌کند، درست مانند اینکه محرک بلافاصله پس از دستورالعمل \fBFROM\fP در Dockerfile پایین‌دستی قرار داشته باشد. .PP می‌توانید هر دستورالعمل ساخت را به عنوان یک محرک ثبت کنید. یک محرک زمانی مفید است که در حال تعریف یک ایمیج به عنوان پایه برای ساخت سایر ایمیج‌ها هستید. به عنوان مثال، اگر در حال تعریف یک محیط ساخت برنامه یا یک دیمن هستید که با پیکربندی مخصوص کاربر سفارشی‌سازی می‌شود. .PP ایمیجی را در نظر بگیرید که به عنوان یک سازنده قابل استفاده مجدد برای برنامه‌های python طراحی شده است. این ایمیج باید کد مبدأ برنامه را به یک دایرکتوری خاص اضافه کند، و ممکن است بعد از آن به فراخوانی یک اسکریپت ساخت نیاز داشته باشد. اکنون نمی‌توانید صرفاً \fBADD\fP و \fBRUN\fP را فراخوانی کنید، زیرا هنوز به کد مبدأ برنامه دسترسی ندارید و این کد برای ساخت هر برنامه متفاوت است. .PP \-\- ارائه یک Dockerfile الگو (boilerplate) به توسعه‌دهندگان برنامه برای کپی و جای‌گذاری در برنامه‌شان ناکارآمد، مستعد خطا و به‌روزرسانی آن دشوار است، زیرا با کدهای اختصاصی برنامه ترکیب می‌شود. راه‌حل استفاده از \fBONBUILD\fP برای ثبت پیشاپیش دستورالعمل‌ها است تا بعداً در طول مرحله ساخت بعدی اجرا شوند. .SH "تاریخچه (HISTORY)" * مه ۲۰۱۴، گردآوری‌شده توسط Zac Dover (zdover at redhat dot com) بر اساس مستندات Dockerfile در docker.com. * فوریه ۲۰۱۵، به‌روزرسانی‌شده توسط Brian Goff (cpuguy83@gmail.com) جهت خوانایی بیشتر. * سپتامبر ۲۰۱۵، به‌روزرسانی‌شده توسط Sally O'Malley (somalley@redhat.com). * اکتبر ۲۰۱۶، به‌روزرسانی‌شده توسط Addam Hardy (addam.hardy@gmail.com).