.nh
.TH "DOCKER" "1" "JUNE 2014" "Docker Community" "Docker User Manuals"

.SH "نام (NAME)"
docker-build \- ساخت یک ایمیج از یک Dockerfile


.SH "خلاصه دستور (SYNOPSIS)"
\fBdocker build\fP
[\fB--add-host\fP[=\fI[]\fP]]
[\fB--build-arg\fP[=\fI[]\fP]]
[\fB--cache-from\fP[=\fI[]\fP]]
[\fB-c\fP|\fB--cpu-shares\fP[=\fI0\fP]]
[\fB--cgroup-parent\fP[=\fICGROUP-PARENT\fP]]
[\fB--help\fP]
[\fB--iidfile\fP[=\fIIIDFILE\fP]]
[\fB-f\fP|\fB--file\fP[=\fIPATH/Dockerfile\fP]]
[\fB-squash\fP] \fIExperimental\fP
[\fB--force-rm\fP]
[\fB--isolation\fP[=\fIdefault\fP]]
[\fB--label\fP[=\fI[]\fP]]
[\fB--no-cache\fP]
[\fB--pull\fP]
[\fB--compress\fP]
[\fB-q\fP|\fB--quiet\fP]
[\fB--rm\fP[=\fItrue\fP]]
[\fB-t\fP|\fB--tag\fP[=\fI[]\fP]]
[\fB-m\fP|\fB--memory\fP[=\fIMEMORY\fP]]
[\fB--memory-swap\fP[=\fILIMIT\fP]]
[\fB--network\fP[=\fI"default"\fP]]
[\fB--shm-size\fP[=\fISHM-SIZE\fP]]
[\fB--cpu-period\fP[=\fI0\fP]]
[\fB--cpu-quota\fP[=\fI0\fP]]
[\fB--cpuset-cpus\fP[=\fICPUSET-CPUS\fP]]
[\fB--cpuset-mems\fP[=\fICPUSET-MEMS\fP]]
[\fB--target\fP[=\fI[]\fP]]
[\fB--ulimit\fP[=\fI[]\fP]]
PATH | URL | -


.SH "شرح (DESCRIPTION)"
این دستور \fBDockerfile\fP را از دایرکتوری مشخص‌شده در \fBPATH\fP می‌خواند\&.
همچنین هر فایل و دایرکتوری دیگری که در دایرکتوری جاری یافت شود را به دیمن Docker ارسال می‌کند. محتویات این دایرکتوری توسط دستورات \fBADD\fP موجود در \fBDockerfile\fP استفاده خواهد شد.

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

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


.SH "گزینه‌ها (OPTIONS)"
\fB-f\fP, \fB--file\fP \fIPATH/Dockerfile\fP
   مسیر \fBDockerfile\fP مورد استفاده. اگر مسیر نسبی باشد و شما از یک دایرکتوری محلی عملیات ساخت را انجام می‌دهید، مسیر باید نسبت به آن دایرکتوری سنجیده شود. اگر ساخت را از یک URL دوردست اشاره‌کننده به یک tarball یا یک مخزن Git انجام می‌دهید، مسیر باید نسبت به ریشه بافت دوردست باشد. در تمام موارد، فایل باید درون بافت ساخت (build context) قرار داشته باشد. مقدار پیش‌فرض \fIDockerfile\fP است\&.

.PP
\fB--squash\fP \fItrue\fP|\fIfalse\fP
   \fBتنها به صورت آزمایشی (Experimental Only)\fP
   پس از ساخت ایمیج، لایه‌های جدید را در یک لایه واحد درون یک ایمیج تازه ادغام می‌کند (squash). ادغام کردن هیچ‌یک از ایمیج‌های موجود را از بین نمی‌برد، بلکه یک ایمیج جدید با محتوای لایه‌های ادغام‌شده ایجاد می‌کند. این کار عملاً به گونه‌ای جلوه می‌دهد که گویی تمام دستورات \fBDockerfile\fR در قالب یک لایه ایجاد شده‌اند. با این روش، حافظه موقت ساخت (build cache) حفظ می‌شود.

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

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

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

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

.PP
\fB--build-arg\fP \fIvariable\fP
   نام و مقدار یک \fBbuildarg\fP\&.

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

.PP
کاربران این مقادیر را در زمان ساخت ارسال می‌کنند. داکر از \fBbuildargs\fR به عنوان بافت محیطی برای دستور(های) اجرا شده از طریق دستورالعمل \fBRUN\fR در Dockerfile یا برای بسط متغیرها در سایر دستورالعمل‌های Dockerfile استفاده می‌کند. این گزینه برای ارسال مقادیر محرمانه مناسب نیست. اطلاعات بیشتر درباره دستورالعمل buildargs:
\[la]https://docs.docker.com/engine/reference/builder/#arg\[ra]

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

.PP
\fB--force-rm\fP \fItrue\fP|\fIfalse\fP
   حذف همیشگی کانتینرهای میانی، حتی پس از ساخت‌های ناموفق. مقدار پیش‌فرض \fIfalse\fP است\&.

.PP
\fB--isolation\fP "\fIdefault\fP"
   نوع فناوری ایزوله‌سازی مورد استفاده توسط کانتینرها را تعیین می‌کند.

.PP
\fB--label\fP \fIlabel\fP
   تنظیم متادیتا برای یک ایمیج

.PP
\fB--no-cache\fP \fItrue\fP|\fIfalse\fP
   عدم استفاده از کش هنگام ساخت ایمیج. مقدار پیش‌فرض \fIfalse\fP است\&.

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

.PP
\fB--help\fP
  چاپ راهنمای نحوه استفاده

.PP
\fB--pull\fP \fItrue\fP|\fIfalse\fP
   تلاش همیشگی برای دریافت نسخه جدیدتر ایمیج (pull). مقدار پیش‌فرض \fIfalse\fP است\&.

.PP
\fB--compress\fP \fItrue\fP|\fIfalse\fP
   فشرده‌سازی بافت ساخت با استفاده از gzip. مقدار پیش‌فرض \fIfalse\fP است\&.

.PP
\fB-q\fP, \fB--quiet\fP \fItrue\fP|\fIfalse\fP
   بی‌صدا کردن خروجی ساخت و چاپ شناسه ایمیج در صورت موفقیت. مقدار پیش‌فرض \fIfalse\fP است\&.

.PP
\fB--rm\fP \fItrue\fP|\fIfalse\fP
   حذف کانتینرهای میانی پس از یک ساخت موفقیت‌آمیز. مقدار پیش‌فرض \fItrue\fP است\&.

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

.PP
\fB-m\fP, \fB--memory\fP \fIMEMORY\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 است\&. برای فعال‌سازی سواپ نامحدود، مقدار را روی \fB-1\fP تنظیم کنید.

.PP
\fB--network\fP \fItype\fP
  تنظیم حالت شبکه برای دستورالعمل‌های RUN در طول ساخت. مقادیر استاندارد پشتیبانی‌شده عبارتند از: \fBnone\fP، \fBbridge\fP، \fBhost\fP و \fBcontainer:\fP<\fIname\fP|\fIid\fP>. هر مقدار دیگری به عنوان نام یا شناسه یک شبکه سفارشی در نظر گرفته می‌شود که این کانتینر باید به آن متصل گردد.

.PP
در لینوکس، مقدار پیش‌فرض \fBbridge\fP است\&.

.PP
\fB--shm-size\fP \fISHM-SIZE\fP
  اندازه \fB/dev/shm\fR\&. قالب به صورت \fB<number><unit>\fR است\&. \fBnumber\fR باید بزرگ‌تر از \fB0\fR باشد\&.
  واحد اختیاری است و می‌تواند \fBb\fR (بایت)، \fBk\fR (کیلوبایت)، \fBm\fR (مگابایت) یا \fBg\fR (گیگابایت) باشد. اگر واحد را حذف کنید، سیستم از بایت استفاده می‌کند.
  اگر اندازه را به طور کامل حذف کنید، سیستم از \fB64m\fR استفاده می‌کند\&.

.PP
\fB-c\fP, \fB--cpu-shares\fP \fI0\fP
  سهم‌های پردازنده (وزن نسبی).

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

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

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

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

.EX
  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)
.EE

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

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

.EX
  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%
.EE

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

.PP
به عنوان مثال، سیستمی با بیش از سه هسته را در نظر بگیرید. اگر یک کانتینر \fB{C0}\fP را با \fB--cpu-shares 512\fP و در حال اجرای یک فرایند شروع کنید، و کانتینر دیگری \fB{C1}\fP را با \fB--cpu-shares 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--cpu-period\fP \fI0\fP
  محدود کردن دوره زمان‌بند کاملاً عادلانه (CFS) پردازنده.

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

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

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

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

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

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

.PP
\fB--cgroup-parent\fP \fICGROUP-PARENT\fP
  مسیری به \fBcgroup\fRها که \fBcgroup\fR کانتینر تحت آن ایجاد می‌شود.

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

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

.PP
\fB--ulimit\fP []
  گزینه‌های ulimit

.PP
برای اطلاعات بیشتر درباره \fBulimit\fR بخش Setting ulimits in a container را ببینید:
\[la]https://docs.docker.com/engine/reference/commandline/run/#set\-ulimits\-in\-container\-\-\-ulimit\[ra]


.SH "مثال‌ها (EXAMPLES)"
.SH "ساخت یک ایمیج با استفاده از Dockerfile موجود در دایرکتوری جاری (Building an image using a Dockerfile located inside the current directory)"
ایمیج‌های داکر را می‌توان با استفاده از دستور build و یک Dockerfile ساخت:

.EX
docker build .
.EE

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

.EX
docker build --rm false .
.EE

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

.PP
همچنین یک شیوه کاری مناسب این است که فایل‌های مورد نیاز ایمیج را به زیردایرکتوری اضافه کنید. این فایل‌ها سپس با دستورالعمل‌های \fBCOPY\fR یا \fBADD\fR در \fBDockerfile\fR مشخص خواهند شد\&.

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

.SH "ساخت یک ایمیج و نام‌گذاری آن (Building an image and naming that image)"
یک شیوه کاری مناسب این است که به ایمیجی که می‌سازید نام اختصاص دهید. توجه داشته باشید که برای حفظ سازگاری فقط باید از a-z0-9-_. استفاده شود. قانون سختی در اینجا وجود ندارد، اما بهتر است به نام‌گذاری‌ها توجه کافی داشته باشید.

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

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

.EX
docker build -t myimage .
.EE

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

.EX
docker build -t fedora/jboss:1.0 .
.EE

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

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

.PP
اگر تگ نسخه ارائه ندهید، داکر تگ \fBlatest\fR را اختصاص خواهد داد:

.EX
docker build -t whenry/fedora-jboss .
.EE

.PP
هنگامی که لیست ایمیج‌ها را مشاهده می‌کنید، ایمیج بالا دارای تگ \fBlatest\fR خواهد بود\&.

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

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

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

.SH "ساخت یک ایمیج با استفاده از نشانی اینترنتی (Building an image using a URL)"
این کار مخزن مشخص‌شده GitHub را از نشانی URL کلون کرده و از آن به عنوان بافت استفاده می‌کند. فایل Dockerfile در ریشه مخزن به عنوان Dockerfile استفاده می‌شود. این قابلیت تنها در صورتی کار می‌کند که مخزن GitHub یک مخزن اختصاصی باشد.

.EX
docker build github.com/scollier/purpletest
.EE

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

.SH "ساخت یک ایمیج با استفاده از نشانی اینترنتی به یک کانتکست فشرده tar (Building an image using a URL to a tarball'ed context)"
این دستور خودِ نشانی URL را به دیمن Docker ارسال می‌کند. دیمن بایگانی tarball را دریافت کرده، آن را از حالت فشرده خارج می‌کند و از محتویات آن به عنوان بافت ساخت استفاده می‌نماید. فایل Dockerfile در ریشه بایگانی و بقیه محتویات به عنوان بافت ساخت استفاده خواهند شد. اگر گزینه \fB-f PATH/Dockerfile\fP را نیز ارسال کنید، سیستم به دنبال آن فایل در میان محتویات فایل tarball خواهد گشت.

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

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

.SH "مشخص کردن فناوری ایزوله‌سازی برای کانتینر (\-\-isolation) (Specify isolation technology for container (--isolation))"
این گزینه در شرایطی کاربرد دارد که کانتینرهای Docker را روی ویندوز اجرا می‌کنید. گزینه \fB--isolation <value>\fR فناوری ایزوله‌سازی کانتینر را تعیین می‌کند. در لینوکس، تنها گزینه پشتیبانی‌شده گزینه \fBdefault\fR است که از namespaceهای لینوکس استفاده می‌کند. در مایکروسافت ویندوز، می‌توانید این مقادیر را مشخص کنید:
.IP \(bu 2
\fBdefault\fR: استفاده از مقدار مشخص‌شده توسط گزینه \fB--exec-opt\fR دیمن Docker. اگر \fBdaemon\fR فناوری ایزوله‌سازی را مشخص نکرده باشد، مایکروسافت ویندوز از \fBprocess\fR به عنوان مقدار پیش‌فرض خود استفاده می‌کند.
.IP \(bu 2
\fBprocess\fR: تنها ایزوله‌سازی از طریق فضای نام (Namespace).
.IP \(bu 2
\fBhyperv\fR: ایزوله‌سازی مبتنی بر افرازهای هایپروایزر Hyper-V.


.SH "تاریخچه (HISTORY)"
مارس ۲۰۱۴، در ابتدا توسط William Henry (whenry at redhat dot com) بر اساس مستندات مبدأ docker.com و کارهای داخلی تدوین شد.
ژوئن ۲۰۱۴، به‌روزرسانی توسط 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]
اوت ۲۰۲۰، به‌روزرسانی توسط Des Preston despreston@gmail.com
\[la]mailto:despreston@gmail.com\[ra]