docker-build - عبر الإنترنت في السحابة

برنامج:

اسم

docker-build - بناء صورة جديدة من الكود المصدري في PATH

موجز

عامل ميناء نساعدك في بناء [--بناء - أرج[=[]]] [- وحدة المعالجة المركزية سهم[=0]] [- مجموعة الوالدين[=CGROUP-أحد الوالدين]]
[--مساعدة] [-f|--ملف[=PATH / Dockerfile]] [- القوة- جمهورية مقدونيا] [--عزل[=الافتراضي]] [--لا مخبأ]
[--يحذب] [-q|--هادئ] [--rm[=صحيح]] [-t|--بطاقة شعار[=[]]] [-m|--ذاكرة[=الذاكرة ]]
[--مبادلة الذاكرة[=مما سيحدث]] [- حجم shm[=SHM- الحجم]] [- وحدة المعالجة المركزية[=0]] [- حصة وحدة المعالجة المركزية[=0]]
[--cpuset-cpus[=وحدة المعالجة المركزية-وحدة المعالجة المركزية]] [--cpuset-mems[=وحدة المعالجة المركزية-MEMS]] [--وليميت[=[]]] المسار | URL | -

الوصف

سيؤدي هذا إلى قراءة ملف Dockerfile من الدليل المحدد في PATH. كما أنها ترسل أي ملفات
الملفات والأدلة الأخرى الموجودة في الدليل الحالي لبرنامج Docker daemon. ال
سيتم استخدام محتويات هذا الدليل بواسطة أضف تم العثور على أوامر داخل Dockerfile.

تحذير ، سيؤدي هذا إلى إرسال الكثير من البيانات إلى Docker daemon اعتمادًا على محتويات
الدليل الحالي. يتم تشغيل الإنشاء بواسطة Docker daemon ، وليس بواسطة CLI ، وبالتالي فإن الكل
يجب نقل السياق إلى البرنامج الخفي. يُبلغ Docker CLI عن "إرسال سياق الإنشاء
إلى Docker daemon "عندما يتم إرسال السياق إلى البرنامج الخفي.

عند تقديم عنوان URL لأرشيف tarball أو ملف Dockerfile واحد ، لا يتم إرسال أي سياق
من العميل إلى Docker daemon. في هذه الحالة ، يكون ملف Docker في جذر ملف
الأرشيف وسيتم استخدام باقي الأرشيف كسياق للبناء. عندما يكون Git
تم تعيين المستودع باسم URL، يتم استنساخ المستودع محليًا ثم يتم إرساله كملف
سياق الكلام.

OPTIONS

-f, --ملف=PATH / Dockerfile
المسار إلى Dockerfile المراد استخدامه. إذا كان المسار هو مسار نسبي وأنت
بناء من دليل محلي ، فيجب أن يكون المسار متعلقًا بذلك
الدليل. إذا كنت تقوم بالبناء من عنوان URL بعيد يشير إلى أحد ملفات
tarball أو مستودع Git ، فيجب أن يكون المسار نسبيًا لجذر
السياق البعيد. في جميع الحالات ، يجب أن يكون الملف ضمن سياق البناء.
الافتراضي هو Dockerfile.

--بناء - أرج=متغير
اسم وقيمة buildarg.

على سبيل المثال ، إذا كنت تريد تمرير قيمة لـ الموقع الوكيل، استخدم
--build-arg = http_proxy = "http://some.proxy.url"

يمرر المستخدمون هذه القيم في وقت الإنشاء. يستخدم Docker ملف بناء كما
سياق البيئة للأوامر التي يتم تشغيلها عبر Dockerfile's RUN تعليمات
أو للتوسع المتغير في تعليمات Dockerfile الأخرى. هذا ليس المقصود
لتمرير القيم السرية. ⟨/ مرجع / باني / # arg

- القوة- جمهورية مقدونيا=صحيح|زائف
قم دائمًا بإزالة الحاويات الوسيطة ، حتى بعد عمليات الإنشاء غير الناجحة. الافتراضي هو
زائف.

--عزل="الافتراضي"
يحدد العزل نوع تقنية العزل التي تستخدمها الحاويات.

--لا مخبأ=صحيح|زائف
لا تستخدم ذاكرة التخزين المؤقت عند بناء الصورة. الافتراضي هو زائف.

--مساعدة
طباعة بيان الاستخدام

--يحذب=صحيح|زائف
حاول دائمًا سحب نسخة أحدث من الصورة. الافتراضي هو زائف.

-q, --هادئ=صحيح|زائف
قم بإيقاف إخراج البناء وطباعة معرف الصورة عند النجاح. الافتراضي هو زائف.

--rm=صحيح|زائف
قم بإزالة الحاويات الوسيطة بعد بناء ناجح. الافتراضي هو صحيح.

-t, --بطاقة شعار= ""
يتم تطبيق أسماء المستودعات (اختياريًا مع العلامات) على الصورة الناتجة بتنسيق
حالة النجاح.

-m, --ذاكرة=الذاكرة
حد الذاكرة

--مبادلة الذاكرة=مما سيحدث
قيمة حد تساوي الذاكرة بالإضافة إلى المبادلة. يجب استخدامه مع ملف -m (--ذاكرة) علَم. ال
مقايضة مما سيحدث يجب أن يكون دائمًا أكبر من -m (--ذاكرة) القيمة.

شكل مما سيحدث is [ ]. يمكن أن تكون الوحدة b (بايت) ، k (كيلوبايت) ، m
(ميغا بايت) ، أو g (جيجا بايت). إذا لم تحدد وحدة ، b يستخدم. اضبط LIMIT على -1 إلى
تمكين مقايضة غير محدودة.

- حجم shm=SHM- الحجم
حجم / ديف / shm. التنسيق هو . عدد يجب أن تكون أكبر من 0.
الوحدة اختيارية ويمكن أن تكون كذلك b (بايت) ، k (كيلوبايت) ، m (ميغا بايت) ، أو g (جيجا بايت).
إذا حذفت الوحدة ، فسيستخدم النظام وحدات البايت.
إذا حذفت الحجم بالكامل ، فسيستخدم النظام 64m.

- وحدة المعالجة المركزية سهم=0
حصص وحدة المعالجة المركزية (الوزن النسبي).

بشكل افتراضي ، تحصل جميع الحاويات على نفس النسبة من دورات وحدة المعالجة المركزية.
تعد مشاركات وحدة المعالجة المركزية "وزنًا نسبيًا" ، بالنسبة إلى الإعداد الافتراضي البالغ 1024.
يتم تحديد هذه القيمة الافتراضية هنا:

قط /sys/fs/cgroup/cpu/cpu.shares
1024

يمكنك تغيير هذه النسبة عن طريق ضبط حصة وحدة المعالجة المركزية للحاوية
الترجيح بالنسبة إلى أوزان جميع الحاويات الجارية الأخرى.

لتعديل النسبة من الافتراضي 1024 ، استخدم - وحدة المعالجة المركزية سهم
علامة لضبط الترجيح على 2 أو أعلى.

حاوية حصة وحدة المعالجة المركزية العلم
{C0} 60٪ من مشاركات CPU - CPU = 614 (614 تمثل 60٪ من 1024)
{C1} 40٪ من مشاركات CPU - CPU = 410 (410 تمثل 40٪ من 1024)

يتم تطبيق النسبة فقط عند تشغيل العمليات كثيفة الاستخدام لوحدة المعالجة المركزية.
عندما تكون المهام في إحدى الحاوية خاملة ، يمكن للحاويات الأخرى استخدام ملف
الوقت المتبقي لوحدة المعالجة المركزية. المقدار الفعلي لوقت وحدة المعالجة المركزية المستخدم يختلف باختلاف
عدد الحاويات التي تعمل على النظام.

على سبيل المثال ، ضع في اعتبارك ثلاث حاويات ، حيث يوجد واحد - مشاركات وحدة المعالجة المركزية = 1024 و
اثنان آخران - مشاركات وحدة المعالجة المركزية = 512. عندما العمليات في كل ثلاثة
تحاول الحاويات استخدام 100٪ من وحدة المعالجة المركزية ، وستتلقى الحاوية الأولى
50٪ من إجمالي وقت وحدة المعالجة المركزية. إذا قمت بإضافة حاوية رابعة مع - مشاركات وحدة المعالجة المركزية = 1024,
الحاوية الأولى تحصل فقط على 33٪ من وحدة المعالجة المركزية. الحاويات المتبقية
تتلقى 16.5٪ و 16.5٪ و 33٪ من وحدة المعالجة المركزية.

حصة وحدة المعالجة المركزية الحاوية علم وقت وحدة المعالجة المركزية
{C0} 100٪ - مشاركات وحدة المعالجة المركزية = 1024 33٪
{C1} 50٪ - مشاركات وحدة المعالجة المركزية = 512 16.5٪
{C2} 50٪ - مشاركات وحدة المعالجة المركزية = 512 16.5٪
{C4} 100٪ - مشاركات وحدة المعالجة المركزية = 1024 33٪

في نظام متعدد النواة ، يتم توزيع حصة وقت وحدة المعالجة المركزية عبر وحدة المعالجة المركزية
النوى. حتى إذا كانت الحاوية محدودة بأقل من 100٪ من وقت وحدة المعالجة المركزية ، فيمكن ذلك
استخدام 100٪ من كل نواة وحدة معالجة مركزية فردية.

على سبيل المثال ، ضع في اعتبارك نظامًا به أكثر من ثلاثة مراكز. إذا بدأت واحدة
حاوية {C0} مع - مشاركات وحدة المعالجة المركزية = 512 تشغيل عملية واحدة وحاوية أخرى
{C1} مع - مشاركات وحدة المعالجة المركزية = 1024 تشغيل عمليتين ، يمكن أن يؤدي هذا إلى ما يلي
تقسيم أسهم وحدة المعالجة المركزية:

PID حاوية وحدة المعالجة المركزية CPU
100 {C0} 0 100٪ من CPU0
101 {C1} 1 100٪ من CPU1
102 {C1} 2 100٪ من CPU2

- وحدة المعالجة المركزية=0
تحديد فترة CFS لوحدة المعالجة المركزية (جدولة منصفة تمامًا).

الحد من استخدام وحدة المعالجة المركزية للحاوية. تتسبب هذه العلامة في قيام kernel بتقييد الامتداد
استخدام وحدة المعالجة المركزية للحاوية إلى الفترة التي تحددها.

- حصة وحدة المعالجة المركزية=0
تحديد حصة CPU CFS (جدولة عادلة تمامًا).

بشكل افتراضي ، يتم تشغيل الحاويات باستخدام مورد وحدة المعالجة المركزية بالكامل. هذا العلم يتسبب في kernel إلى
تقييد استخدام وحدة المعالجة المركزية للحاوية إلى الحصة التي تحددها.

--cpuset-cpus=وحدة المعالجة المركزية-وحدة المعالجة المركزية
وحدات المعالجة المركزية التي تسمح بالتنفيذ (0-3 ، 0,1،XNUMX).

--cpuset-mems=وحدة المعالجة المركزية-MEMS
عقد الذاكرة (MEMs) التي تسمح بالتنفيذ (0-3 ، 0,1،XNUMX). فقط فعالة على
نظم NUMA.

على سبيل المثال ، إذا كان لديك أربع عقد ذاكرة على نظامك (0-3) ، فاستخدم --cpuset-mems = 0,1،XNUMX إلى
تأكد من أن العمليات في حاوية Docker لا تستخدم سوى الذاكرة من أول ذاكرتين
العقد.

- مجموعة الوالدين=CGROUP-أحد الوالدين
الطريق إلى مجموعات cgroups تحتها الحاوية جروب تم انشاؤها.

إذا لم يكن المسار مطلقًا ، فسيتم اعتبار المسار متعلقًا بـ مجموعات cgroups مسار
عملية البدء. يتم إنشاء مجموعات C إذا لم تكن موجودة بالفعل.

--وليميت= []
خيارات Ulimit

لمزيد من المعلومات حول ulimit انظر تعريف
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

أمثلة

ابني an صورة استخدام a Dockerfile تقع في الداخل ال تيار دليل

يمكن إنشاء صور Docker باستخدام أمر build وملف Docker:

بناء عامل ميناء.

أثناء عملية البناء ، يقوم Docker بإنشاء صور وسيطة. من أجل الاحتفاظ بهم ، أنت
يجب أن تحدد صراحة --rm = خطأ.

بناء عامل ميناء --rm = خطأ.

من الممارسات الجيدة إنشاء دليل فرعي باسم ذي صلة وإنشاء Dockerfile
في هذا الدليل. على سبيل المثال ، قد يحتوي دليل يسمى mongo على Dockerfile لـ
إنشاء صورة Docker MongoDB. وبالمثل ، يمكن استخدام دليل آخر يسمى httpd
تخزين Dockerfiles لصور خادم الويب Apache.

من الممارسات الجيدة أيضًا إضافة الملفات المطلوبة للصورة إلى الدليل الفرعي.
سيتم بعد ذلك تحديد هذه الملفات بامتداد COPY or أضف تعليمات في Dockerfile.

ملاحظة: إذا قمت بتضمين ملف tar (ممارسة جيدة) ، فسيستخرج Docker تلقائيًا
محتويات ملف tar المحدد داخل أضف تعليمات في المحدد
استهداف.

ابني an صورة و تسمية أن صورة

من الممارسات الجيدة إعطاء اسم للصورة التي تقوم ببنائها. لاحظ أن فقط a-z0-9-_.
يجب استخدامها لتحقيق الاتساق. لا توجد قواعد صارمة هنا ولكن من الأفضل إعطاء
النظر في الأسماء.

• -t/--بطاقة شعار العلم يستخدم لإعادة تسمية الصورة. وهنا بعض الأمثلة:

على الرغم من أنها ليست ممارسة جيدة ، إلا أن أسماء الصور يمكن أن تكون عشوائية:

عامل بناء -t myimage.

تتمثل الطريقة الأفضل في توفير مستودع واسم وعلامة مؤهلة بالكامل وذات مغزى
(حيث تعني العلامة في هذا السياق المصنف بعد ":"). في هذا المثال نحن
قم ببناء صورة JBoss لمستودع Fedora ومنحها الإصدار 1.0:

بناء عامل ميناء -t فيدورا / jboss: 1.0.

المثال التالي هو لمستودع المستخدم "whenry" ويستخدم Fedora و JBoss ويعطي
هو الإصدار 2.1:

بناء عامل ميناء -t whenry / فيدورا- jboss: v2.1.

إذا لم تقدم علامة إصدار ، فسيقوم Docker بتعيينها آخر:

بناء عامل ميناء -t whenry / فيدورا-jboss.

عندما تقوم بإدراج الصور ، فإن الصورة أعلاه ستحتوي على العلامة آخر.

يمكنك تطبيق علامات متعددة على صورة. على سبيل المثال ، يمكنك تطبيق آخر علامة إلى أ
الصورة المبنية حديثًا وإضافة علامة أخرى تشير إلى إصدار معين. على سبيل المثال ، ل
وضع علامة على صورة على حد سواء عندماري / فيدورا-جبوس: الأحدث و عندماري / فيدورا-جبوس: v2.1، استخدم
التالية:

docker build -t whenry / fedora-jboss: الأحدث -t whenry / fedora-jboss: v2.1.

لذا فإن إعادة تسمية الصورة أمر تعسفي ولكن يجب مراعاة اتفاقية مفيدة
هذا أمر منطقي بالنسبة للمستهلكين ويجب أن يأخذ في الاعتبار أيضًا مجتمع Docker
الاتفاقيات.

ابني an صورة استخدام a URL

سيؤدي هذا إلى استنساخ مستودع GitHub المحدد من عنوان URL واستخدامه كسياق. ال
يتم استخدام Dockerfile الموجود في جذر المستودع كملف Dockerfile. هذا يعمل فقط إذا كان
مستودع GitHub هو مستودع مخصص.

بناء عامل ميناء github.com/scollier/purpletest

ملاحظة: يمكنك تعيين مستودع Git تعسفي عبر ملف شخص سخيف:// مخطط.

ابني an صورة استخدام a URL إلى a تربل سياق الكلام

سيؤدي هذا إلى إرسال عنوان URL نفسه إلى Docker daemon. سيحضر البرنامج الخفي كرة القطران
أرشفة وفك ضغطها واستخدام محتوياتها كسياق للبناء. ملف Dockerfile في
سيتم استخدام جذر الأرشيف وبقية الأرشيف كسياق للبناء.
إذا قمت بتمرير -f PATH / Dockerfile الخيار أيضًا ، سيبحث النظام عن هذا الملف
داخل محتويات كرة القطران.

بناء عامل ميناء -f dev / Dockerfile https://10.10.10.1/docker/context.tar.gz

ملاحظة: تنسيقات الضغط المدعومة هي "xz" و "bzip2" و "gzip" و "الهوية" (لا
ضغط).

تحديد عزل التكنلوجيا For حاوية (--عزل)

هذا الخيار مفيد في المواقف التي تقوم فيها بتشغيل حاويات Docker على Windows.
• - العزلة = يحدد الخيار تقنية عزل الحاوية. على لينكس ، الوحيد
المدعومة هي الافتراضي الخيار الذي يستخدم لينكس مساحات الأسماء. في Microsoft Windows ، يمكنك ذلك
حدد هذه القيم:

· الافتراضي: استخدم القيمة المحددة بواسطة Docker daemon's --exec-opt . إذا كان الخفي هل
لا تحدد تقنية العزل ، يستخدمها Microsoft Windows عملية المعالجة كإعداد افتراضي
.

· عملية المعالجة : عزل مساحة الاسم فقط.

· هاييرف: عزل قائم على قسم Hyper-V hypervisor.

تحديد --عزل العلم بدون قيمة هو نفس الإعداد
- العزلة = "افتراضي".

التاريخ

مارس 2014 ، تم تجميعه في الأصل بواسطة ويليام هنري (whenry at redhat dot com) بناءً على
مادة مصدر docker.com والعمل الداخلي. يونيو 2014 ، تم التحديث بواسطة سفين دويديت
⟨[البريد الإلكتروني محمي]⟩ يونيو 2015 ، تم التحديث بواسطة Sally O'Malley ⟨[البريد الإلكتروني محمي]⟩

استخدم docker-build عبر الإنترنت باستخدام خدمات onworks.net