docker-build - Dalam talian dalam Awan

JADUAL:

NAMA

docker-build - Bina imej baharu daripada kod sumber di PATH

SINOPSIS

docker membina [--build-arg[=[]]] [--cpu-kongsi[=0]] [--cgroup-ibu bapa[=KUMPULAN-IBU BAPA]]
[- membantu] [-f|--fail[=PATH/Fail Docker]] [--paksa-rm] [--pengasingan[=lalai]] [--tiada-cache]
[--tarik] [-q|--senyap] [--rm[=benar]] [-t|--tag[=[]]] [-m|--ingatan[=MEMORY]]
[--pertukaran-memori[=HAD]] [--shm-saiz[=SAIZ SHM]] [--cpu-tempoh[=0]] [--cpu-kuota[=0]]
[--cpuset-cpus[=CPUSET-CPUS]] [--cpuset-mems[=CPUSET-MEMS]] [--ulimit[=[]]] LALUAN | URL | -

DESCRIPTION

Ini akan membaca Dockerfile dari direktori yang dinyatakan dalam PATH. Ia juga menghantar apa-apa
fail dan direktori lain yang terdapat dalam direktori semasa kepada daemon Docker. The
kandungan direktori ini akan digunakan oleh MASUKKAN arahan yang terdapat dalam Dockerfile.

Amaran, ini akan menghantar banyak data kepada daemon Docker bergantung pada kandungan
direktori semasa. Binaan dijalankan oleh daemon Docker, bukan oleh CLI, jadi keseluruhannya
konteks mesti dipindahkan ke daemon. CLI Docker melaporkan "Menghantar konteks binaan
kepada daemon Docker" apabila konteks dihantar kepada daemon.

Apabila URL ke arkib tarball atau satu Dockerfile diberikan, tiada konteks dihantar
daripada pelanggan kepada daemon Docker. Dalam kes ini, fail Docker pada akar fail
arkib dan arkib yang lain akan digunakan sebagai konteks binaan. Apabila Git
repositori ditetapkan sebagai URL, repositori diklon secara tempatan dan kemudian dihantar sebagai
konteks.

PILIHAN

-f, --fail=PATH/Fail Docker
Laluan ke Dockerfile untuk digunakan. Jika laluan itu adalah laluan relatif dan anda
membina daripada direktori tempatan, maka laluan itu mestilah relatif kepada itu
direktori. Jika anda membina dari URL jauh yang menunjuk ke a
tarball atau repositori Git, maka laluan mestilah relatif kepada punca
konteks jauh. Dalam semua kes, fail mestilah dalam konteks binaan.
Lalai adalah Dockerfile.

--build-arg=berubah-ubah
nama dan nilai a buildarg.

Sebagai contoh, jika anda ingin menghantar nilai untuk http_proxy, Gunakan
--build-arg=http_proxy="http://some.proxy.url"

Pengguna melepasi nilai ini pada masa binaan. Docker menggunakan buildargs sebagai
konteks persekitaran untuk arahan yang dijalankan melalui fail Docker RUN arahan
atau untuk pengembangan berubah dalam arahan Dockerfile yang lain. Ini tidak dimaksudkan
untuk melepasi nilai rahsia. ⟨/rujukan/pembina/#arg⟩

--paksa-rm=benar|palsu
Sentiasa keluarkan bekas perantaraan, walaupun selepas pembinaan yang tidak berjaya. Lalainya ialah
palsu.

--pengasingan="lalai"
Pengasingan menentukan jenis teknologi pengasingan yang digunakan oleh bekas.

--tiada-cache=benar|palsu
Jangan gunakan cache semasa membina imej. Lalainya ialah palsu.

- membantu
Cetak kenyataan penggunaan

--tarik=benar|palsu
Sentiasa cuba tarik versi imej yang lebih baharu. Lalainya ialah palsu.

-q, --senyap=benar|palsu
Sekat output binaan dan cetak ID imej apabila berjaya. Lalainya ialah palsu.

--rm=benar|palsu
Keluarkan bekas perantaraan selepas binaan berjaya. Lalainya ialah benar.

-t, --tag=""
Nama repositori (dan secara pilihan dengan tag) untuk digunakan pada imej yang terhasil
kes kejayaan.

-m, --ingatan=MEMORY
Had ingatan

--pertukaran-memori=HAD
Nilai had yang sama dengan memori ditambah swap. Mesti digunakan dengan -m (--ingatan) bendera. The
swap HAD hendaklah sentiasa lebih besar daripada -m (--ingatan) nilai.

Format HAD is [ ]. Unit boleh b (bait), k (kilobait), m
(megabait), atau g (gigabait). Jika anda tidak menentukan unit, b digunakan. Tetapkan LIMIT kepada -1 kepada
dayakan pertukaran tanpa had.

--shm-saiz=SAIZ SHM
Saiz /dev/shm. Formatnya ialah . nombor mesti lebih besar daripada 0.
Unit adalah pilihan dan boleh b (bait), k (kilobait), m (megabait), atau g (gigabait).
Jika anda meninggalkan unit, sistem menggunakan bait.
Jika anda meninggalkan saiz sepenuhnya, sistem akan menggunakan 64m.

--cpu-kongsi=0
Bahagian CPU (berat relatif).

Secara lalai, semua bekas mendapat bahagian kitaran CPU yang sama.
Perkongsian CPU ialah 'berat relatif', berbanding tetapan lalai 1024.
Nilai lalai ini ditakrifkan di sini:

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

Anda boleh menukar perkadaran ini dengan melaraskan bahagian CPU bekas
pemberat berbanding dengan pemberat semua bekas berjalan lain.

Untuk mengubah suai perkadaran daripada lalai 1024, gunakan --cpu-kongsi
bendera untuk menetapkan pemberat kepada 2 atau lebih tinggi.

Bendera bahagian CPU kontena
{C0} 60% daripada CPU --cpu-shares=614 (614 ialah 60% daripada 1024)
{C1} 40% daripada CPU --cpu-shares=410 (410 ialah 40% daripada 1024)

Perkadaran hanya digunakan apabila proses intensif CPU sedang berjalan.
Apabila tugasan dalam satu bekas terbiar, bekas lain boleh menggunakan
baki masa CPU. Jumlah sebenar masa CPU yang digunakan berbeza-beza bergantung pada
bilangan bekas yang berjalan pada sistem.

Sebagai contoh, pertimbangkan tiga bekas, di mana satu mempunyai --cpu-shares=1024 and
dua lagi ada --cpu-shares=512. Apabila proses dalam ketiga-tiga
bekas cuba menggunakan 100% CPU, bekas pertama akan menerima
50% daripada jumlah masa CPU. Jika anda menambah bekas keempat dengan --cpu-shares=1024,
bekas pertama hanya mendapat 33% daripada CPU. Bekas yang tinggal
menerima 16.5%, 16.5% dan 33% daripada CPU.

Kongsi CPU kontena Masa CPU Bendera
{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%

Pada sistem berbilang teras, bahagian masa CPU diagihkan ke seluruh CPU
teras. Walaupun bekas dihadkan kepada kurang daripada 100% masa CPU, ia boleh
gunakan 100% daripada setiap teras CPU individu.

Sebagai contoh, pertimbangkan sistem dengan lebih daripada tiga teras. Jika anda memulakan satu
bekas {C0} bersama --cpu-shares=512 menjalankan satu proses, dan bekas lain
{C1} bersama --cpu-shares=1024 menjalankan dua proses, ini boleh mengakibatkan perkara berikut
pembahagian saham CPU:

Bahagian CPU bekas PID CPU
100 {C0} 0 100% daripada CPU0
101 {C1} 1 100% daripada CPU1
102 {C1} 2 100% daripada CPU2

--cpu-tempoh=0
Hadkan tempoh CPU CFS (Penjadual Sepenuhnya Adil).

Hadkan penggunaan CPU bekas. Bendera ini menyebabkan kernel menyekat
penggunaan CPU kontena kepada tempoh yang anda tentukan.

--cpu-kuota=0
Hadkan kuota CPU CFS (Completely Fair Scheduler).

Secara lalai, bekas dijalankan dengan sumber CPU penuh. Bendera ini menyebabkan kernel
hadkan penggunaan CPU bekas kepada kuota yang anda tentukan.

--cpuset-cpus=CPUSET-CPUS
CPU yang membenarkan pelaksanaan (0-3, 0,1).

--cpuset-mems=CPUSET-MEMS
Nod memori (MEM) yang membenarkan pelaksanaan (0-3, 0,1). Hanya berkesan pada
sistem NUMA.

Contohnya, jika anda mempunyai empat nod memori pada sistem anda (0-3), gunakan --cpuset-mems=0,1 kepada
pastikan proses dalam bekas Docker anda hanya menggunakan memori daripada dua memori pertama
nod.

--cgroup-ibu bapa=KUMPULAN-IBU BAPA
Laluan ke kumpulan di bawah mana bekas itu cgroup diciptakan.

Jika laluan itu tidak mutlak, laluan itu dianggap relatif kepada kumpulan laluan yang
proses init. Cgroups dicipta jika mereka belum wujud.

--ulimit=[]
Ulimi pilihan

Untuk maklumat lanjut mengenai had lihat
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

CONTOH

Bangunan an gambar menggunakan a Dockerfile terletak di dalam yang semasa direktori

Imej Docker boleh dibina menggunakan arahan bina dan fail Docker:

binaan buruh pelabuhan .

Semasa proses binaan Docker mencipta imej perantaraan. Untuk mengekalkan mereka, anda
mesti ditetapkan secara eksplisit --rm=salah.

binaan docker --rm=false .

Amalan yang baik ialah membuat sub-direktori dengan nama yang berkaitan dan mencipta Dockerfile
dalam direktori itu. Sebagai contoh, direktori yang dipanggil mongo mungkin mengandungi Dockerfile to
buat imej Docker MongoDB. Begitu juga, direktori lain yang dipanggil httpd boleh digunakan untuk
simpan Dockerfiles untuk imej pelayan web Apache.

Ia juga merupakan amalan yang baik untuk menambah fail yang diperlukan untuk imej ke sub-direktori.
Fail-fail ini kemudiannya akan ditentukan dengan SALINAN or MASUKKAN arahan di Dockerfile.

Nota: Jika anda memasukkan fail tar (amalan yang baik), maka Docker akan mengekstrak secara automatik
kandungan fail tar yang dinyatakan dalam MASUKKAN arahan ke dalam yang ditentukan
sasaran.

Bangunan an gambar and menamakan Bahawa gambar

Amalan yang baik ialah memberi nama kepada imej yang anda sedang bina. Ambil perhatian bahawa hanya a-z0-9-_.
harus digunakan untuk konsistensi. Tiada peraturan keras di sini tetapi yang terbaik adalah memberikannya
pertimbangan nama.

. -t/--tag bendera digunakan untuk menamakan semula imej. Berikut adalah beberapa contoh:

Walaupun ia bukan amalan yang baik, nama imej boleh sewenang-wenangnya:

docker build -t myimage .

Pendekatan yang lebih baik ialah menyediakan repositori, nama dan teg yang layak dan bermakna
(di mana teg dalam konteks ini bermaksud penentu kelayakan selepas ":"). Dalam contoh ini kita
bina imej JBoss untuk repositori Fedora dan berikannya versi 1.0:

docker build -t fedora/jboss:1.0 .

Contoh seterusnya adalah untuk repositori pengguna "whenry" dan menggunakan Fedora dan JBoss dan memberi
ia versi 2.1:

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

Jika anda tidak memberikan teg versi maka Docker akan menetapkan Terkini:

docker build -t whenry/fedora-jboss .

Apabila anda menyenaraikan imej, imej di atas akan mempunyai teg Terkini.

Anda boleh menggunakan berbilang tag pada imej. Sebagai contoh, anda boleh memohon Terkini tag kepada a
imej yang baru dibina dan tambahkan teg lain yang merujuk versi tertentu. Contohnya, kepada
tag imej kedua-duanya sebagai whenry/fedora-jboss:terkini and whenry/fedora-jboss:v2.1, menggunakan
Berikut:

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

Jadi menamakan semula imej adalah sewenang-wenangnya tetapi pertimbangan harus diberikan kepada konvensyen yang berguna
yang masuk akal untuk pengguna dan juga harus mengambil kira komuniti Docker
konvensyen.

Bangunan an gambar menggunakan a URL

Ini akan mengklon repositori GitHub yang ditentukan daripada URL dan menggunakannya sebagai konteks. The
Fail Docker pada akar repositori digunakan sebagai Fail Docker. Ini hanya berfungsi jika
Repositori GitHub ialah repositori khusus.

docker membina github.com/scollier/purpletest

Nota: Anda boleh menetapkan repositori Git sewenang-wenangnya melalui git:// skema.

Bangunan an gambar menggunakan a URL kepada a tarball'ed konteks

Ini akan menghantar URL itu sendiri kepada daemon Docker. Daemon akan mengambil bola tar
arkib, nyahmampatkannya dan gunakan kandungannya sebagai konteks binaan. Fail Docker di
akar arkib dan arkib yang lain akan digunakan sebagai konteks binaan.
Jika anda lulus an -f PATH/Fail Docker pilihan juga, sistem akan mencari fail itu
di dalam kandungan tarball.

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

Nota: format mampatan yang disokong ialah 'xz', 'bzip2', 'gzip' dan 'identity' (tidak
pemampatan).

Tentukan pengasingan teknologi Untuk bekas (--pengasingan)

Pilihan ini berguna dalam situasi di mana anda menjalankan bekas Docker pada Windows.
. --pengasingan= pilihan menetapkan teknologi pengasingan bekas. Di Linux, satu-satunya
disokong ialah lalai pilihan yang menggunakan ruang nama Linux. Pada Microsoft Windows, anda boleh
nyatakan nilai ini:

· lalai: Gunakan nilai yang ditentukan oleh daemon Docker --exec-opt . Jika daemon tidak
tidak menyatakan teknologi pengasingan, Microsoft Windows menggunakan proses sebagai lalainya
nilai.

· proses: Pengasingan ruang nama sahaja.

· hiper: Pengasingan berasaskan partition hyper-V hypervisor.

Menyatakan --pengasingan bendera tanpa nilai adalah sama seperti tetapan
--isolation="default".

SEJARAH

Mac 2014, Asalnya disusun oleh William Henry (whenry di redhat dot com) berdasarkan
bahan sumber dan kerja dalaman docker.com. Jun 2014, dikemas kini oleh Sven Dowideit
⟨[e-mel dilindungi]⟩ Jun 2015, dikemas kini oleh Sally O'Malley ⟨[e-mel dilindungi]⟩

Gunakan docker-build dalam talian menggunakan perkhidmatan onworks.net