docker-build - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

docker-build - Створення нового образу з вихідного коду за адресою PATH

СИНТАКСИС

Докер будувати [--build-arg[=[]]] [--спільні ресурси процесора[=0]] [--cgroup-parent[=CGROUP-PARENT]]
[--допомога] [-f|--файл[=PATH/файл Docker]] [--force-rm] [--ізоляція[=дефолт]] [--без кешу]
[--тягнути] [-q|--спокійно] [--пом[=правда]] [-t|--тег[=[]]] [-m|--пам'ять[=ПАМ'ЯТЬ]]
[--зміна пам'яті[=МЕЖА]] [--shm-розмір[=РОЗМІР SHM]] [--період процесора[=0]] [-- квота процесора[=0]]
[--cpuset-cpus[=CPUSET-CPU]] [--cpuset-mems[=CPUSET-MEMS]] [--ліміт[=[]]] ШЛЯХ | URL | -

ОПИС

Це зчитує файл Docker з каталогу, зазначеного в PATH. Він також надсилає будь-який
інші файли та каталоги, знайдені в поточному каталозі, до демона Docker. The
вміст цього каталогу буде використовуватися ДОДАТИ команд, знайдених у файлі Docker.

Попередження, це надішле багато даних до демона Docker залежно від вмісту
поточний каталог. Збірка виконується демоном Docker, а не інтерфейсом командної команди
контекст необхідно передати демону. CLI Docker повідомляє «Відправлення контексту збірки
до демона Docker", коли контекст надсилається демону.

Коли вказано URL-адресу архіву tar-архіву або окремого файлу Docker, контекст не надсилається
від клієнта до демона Docker. У цьому випадку файл Docker в корені файлу
архів, а решта архіву використовуватимуться як контекст збірки. Коли Git
репозиторій встановлюється як URL, сховище клонується локально, а потім надсилається як файл
контексті.

ВАРІАНТИ

-f, --файл=PATH/файл Docker
Шлях до файлу Docker для використання. Якщо шлях відносний, а ви
створення з локального каталогу, то шлях має бути відносно цього
каталог. Якщо ви створюєте віддалену URL-адресу, яка вказує на a
tarball або репозиторій Git, тоді шлях має бути відносно кореня
віддалений контекст. У всіх випадках файл повинен знаходитися в контексті збірки.
За замовчуванням - Докер-файл.

--build-arg=змінна
назва та значення a buildarg.

Наприклад, якщо ви хочете передати значення для http_proxy, Використовуйте
--build-arg=http_proxy="http://some.proxy.url"

Користувачі передають ці значення під час складання. Docker використовує будівельники в якості
контекст середовища для команд, які запускаються через файл Docker RUN інструкція
або для розширення змінної в інших інструкціях Dockerfile. Це не мається на увазі
для передачі секретних значень. ⟨/reference/builder/#arg⟩

--force-rm=правда|false
Завжди видаляйте проміжні контейнери, навіть після невдалої збірки. За замовчуванням є
false.

--ізоляція="дефолт"
Ізоляція визначає тип технології ізоляції, яку використовують контейнери.

--без кешу=правда|false
Не використовуйте кеш під час створення образу. За замовчуванням є false.

--допомога
Роздрукувати заяву про використання

--тягнути=правда|false
Завжди намагайтеся отримати новішу версію зображення. За замовчуванням є false.

-q, --спокійно=правда|false
Придушіть вихідні дані збірки та роздрукуйте ідентифікатор зображення в разі успіху. За замовчуванням є false.

--пом=правда|false
Видаліть проміжні контейнери після успішної збірки. За замовчуванням є правда.

-t, --тег=""
Назви сховищ (і, за бажанням, з тегами), які будуть застосовані до отриманого зображення
випадок успіху.

-m, --пам'ять=ПАМ'ЯТЬ
Обмеження пам'яті

--зміна пам'яті=МЕЖА
Граничне значення, рівне пам'яті плюс обмін. Необхідно використовувати з -m (--пам'ять) прапор. The
обмін МЕЖА завжди має бути більше ніж -m (--пам'ять) значення.

Формат МЕЖА is [ ]. Одиниця може бути b (байти), k (кілобайти), m
(мегабайти), або g (гігабайти). Якщо ви не вкажете одиницю, b використовується. Установіть LIMIT на -1 до
увімкнути необмежений обмін.

--shm-розмір=РОЗМІР SHM
Розмір / dev / shm. Формат такий . номер має бути більше, ніж 0.
Одиниця необов'язкова і може бути b (байти), k (кілобайти), m (мегабайти), або g (гігабайти).
Якщо ви опустите одиницю, система використовує байти.
Якщо ви повністю опустите розмір, система використовує 64m.

--спільні ресурси процесора=0
Частки ЦП (відносна вага).

За замовчуванням усі контейнери отримують однакову частку циклів ЦП.
Частки CPU — це «відносна вага» відносно значення за замовчуванням 1024.
Це значення за замовчуванням визначається тут:

як /sys/fs/cgroup/cpu/cpu.shares
1024

Ви можете змінити цю пропорцію, налаштувавши частку ЦП контейнера
зважування відносно ваги всіх інших робочих контейнерів.

Щоб змінити пропорцію з 1024 за замовчуванням, скористайтеся --спільні ресурси процесора
прапорець, щоб встановити вагу 2 або вище.

Прапор спільного використання ЦП контейнера
{C0} 60% ЦП --cpu-shares=614 (614 це 60% від 1024)
{C1} 40% ЦП --cpu-shares=410 (410 це 40% від 1024)

Пропорція застосовується лише тоді, коли запущені процеси з інтенсивним процесом.
Коли завдання в одному контейнері неактивні, інші контейнери можуть використовувати
залишок ЦП. Фактична кількість використовуваного процесорного часу залежить від
кількість контейнерів, що працюють у системі.

Наприклад, розглянемо три контейнери, де є один --cpu-shares=1024 та
двоє інших мають --cpu-shares=512. Коли процеси у всіх трьох
контейнери намагаються використовувати 100% ЦП, перший контейнер отримає
50% загального часу процесора. Якщо додати четверту ємність с --cpu-shares=1024,
перший контейнер отримує лише 33% ЦП. Решта ємності
отримують 16.5%, 16.5% і 33% ЦП.

Контейнер CPU share Позначте час CPU
{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%

У багатоядерній системі частка часу ЦП розподіляється між ЦП
ядра. Навіть якщо контейнер обмежений менш ніж 100% часу процесора, він може
використовувати 100% кожного окремого ядра ЦП.

Наприклад, розглянемо систему з більш ніж трьома ядрами. Якщо ви почнете один
контейнер {C0} з --cpu-shares=512 запуск одного процесу, а іншого контейнера
{C1} з --cpu-shares=1024 запуск двох процесів, це може призвести до наступного
поділ акцій ЦП:

Контейнер PID Спільний ресурс ЦП ЦП
100 {C0} 0 100% CPU0
101 {C1} 1 100% CPU1
102 {C1} 2 100% CPU2

--період процесора=0
Обмежте період CPU CFS (повністю справедливий планувальник).

Обмежте використання ЦП контейнера. Цей прапор змушує ядро ​​обмежувати
використання ЦП контейнера до зазначеного вами періоду.

-- квота процесора=0
Обмежте квоту CPU CFS (Completely Fair Scheduler).

За замовчуванням контейнери запускаються з повним ресурсом ЦП. Цей прапор змушує ядро
обмежити використання ЦП контейнера заданою вами квотою.

--cpuset-cpus=CPUSET-CPU
ЦП, у яких можна дозволити виконання (0-3, 0,1).

--cpuset-mems=CPUSET-MEMS
Вузли пам’яті (MEM), в яких можна дозволити виконання (0-3, 0,1). Ефективний тільки на
Системи NUMA.

Наприклад, якщо у вашій системі є чотири вузли пам’яті (0-3), використовуйте --cpuset-mems=0,1 до
переконайтеся, що процеси у вашому контейнері Docker використовують пам’ять лише з перших двох пам’яті
вузли.

--cgroup-parent=CGROUP-PARENT
Шлях до групи під яким контейнер cgroup створюються.

Якщо шлях не є абсолютним, він розглядається відносно групи шлях
процес ініціалізації. Cgroups створюються, якщо вони ще не існують.

--ліміт=[]
Варіанти Ulimit

Для отримання додаткової інформації про Ulimit побачити
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

ПРИКЛАДИ

Створюємо an зображення використання a Докер-файл розташований всередині ток каталог

Образи Docker можна створити за допомогою команди build і файлу Docker:

збірка докера.

Під час процесу збірки Docker створює проміжні образи. Щоб зберегти їх, ви
необхідно вказати явно --rm = помилка.

docker build --rm=false .

Хорошою практикою є створення підкаталогу з пов’язаною назвою та створення файлу Dockerfile
в цьому каталозі. Наприклад, каталог під назвою mongo може містити файл Docker
створити образ Docker MongoDB. Так само можна використовувати інший каталог під назвою httpd
зберігати файли Docker для зображень веб-сервера Apache.

Також корисно додати файли, необхідні для зображення, до підкаталогу.
Ці файли потім будуть вказані за допомогою КОПІЯ or ДОДАТИ інструкції в Докер-файл.

Примітка: якщо ви включите файл tar (гарна практика), Docker автоматично розпакує
вміст файлу tar, зазначеного в файлі ДОДАТИ інструкції в зазначене
мета.

Створюємо an зображення та іменування Що зображення

Хороша практика — дати назву образу, який ви створюєте. Зауважте, що тільки a-z0-9-_.
слід використовувати для консистенції. Тут немає жорстких правил, але краще надати їх
розгляд імен.

Команда -t/--тег прапорець використовується для перейменування зображення. Ось кілька прикладів:

Хоча це не є гарною практикою, назви зображень можуть бути довільними:

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 .

Якщо ви не вкажете тег версії, Docker призначить останній:

docker build -t whenry/fedora-jboss .

Коли ви перераховуєте зображення, зображення вище матиме тег останній.

Ви можете застосувати кілька тегів до зображення. Наприклад, ви можете застосувати останній тег до a
нещодавно створене зображення та додайте інший тег, який посилається на певну версію. Наприклад, до
позначте зображення як whenry/fedora-jboss: останні та whenry/fedora-jboss: v2.1, використовувати
наступні:

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

Тому перейменування зображення є довільним, але слід враховувати корисну конвенцію
це має сенс для споживачів і також має враховувати спільноту Docker
конвенції.

Створюємо an зображення використання a URL

Це клонує вказаний репозиторій GitHub з URL-адреси та використовуватиме його як контекст. The
Dockerfile в корені репозиторію використовується як Dockerfile. Це працює лише в тому випадку, якщо
Репозиторій GitHub — це спеціальне сховище.

збірка докера github.com/scollier/purpletest

Примітка: Ви можете встановити довільне сховище Git за допомогою git: // схеми.

Створюємо an зображення використання a URL до a заархівовано контекст

Це надішле саму URL-адресу до демона Docker. Демон забере tar-архів
архівуйте, розпакуйте його та використовуйте його вміст як контекст збірки. Файл Docker на
корінь архіву, а решта архіву використовуватимуться як контекст збірки.
Якщо ви передаєте -f PATH/файл Docker також, система шукатиме цей файл
всередині вмісту архіву.

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

Примітка: підтримувані формати стиснення: 'xz', 'bzip2', 'gzip' та 'identity' (ні
стиснення).

Вказувати ізоляція technology та цінності контейнер (--ізоляція)

Цей параметр корисний у ситуаціях, коли ви використовуєте контейнери Docker у Windows.
Команда --ізоляція= параметр встановлює технологію ізоляції контейнера. На Linux єдиний
підтримується дефолт параметр, який використовує простір імен Linux. У Microsoft Windows ви можете
вкажіть ці значення:

· дефолт: Використовуйте значення, визначене демоном Docker --exec-opt , Якщо демон робить
не вказувати технологію ізоляції, яку використовує Microsoft Windows процес як його за замовчуванням
value.

· процес: лише ізоляція простору імен.

· hyperv: ізоляція гіпервізора Hyper-V на основі розділів.

Визначення --ізоляція прапор без значення те саме, що і налаштування
--isolation="за замовчуванням".

ІСТОРІЯ

Березень 2014 р., спочатку складено Вільямом Генрі (whenry at redhat dot com) на основі
вихідний матеріал docker.com і внутрішня робота. Червень 2014, оновлено Свеном Довідейтом
⟨[захищено електронною поштою]⟩ Червень 2015, оновлено Саллі О'Меллі ⟨[захищено електронною поштою]⟩

Використовуйте docker-build онлайн за допомогою служб onworks.net