docker-build - Online w chmurze

PROGRAM:

IMIĘ

docker-build — Zbuduj nowy obraz z kodu źródłowego w PATH

STRESZCZENIE

doker budować [--build-arg[=[]]] [--udziały-procesora[=0]] [--cgrupa-rodzic[=CGROUP-PARENT]]
[--help] [-f|--plik[=PATH/plik Dockera]] [--force-rm] [--izolacja[=domyślnym]] [--brak pamięci podręcznej]
[--ciągnąć] [-q|--cichy] [--rm[=prawdziwy]] [-t|--etykietka[=[]]] [-m|--pamięć[=PAMIĘĆ]]
[--wymiana-pamięci[=LIMIT]] [--rozmiar shm[=ROZMIAR SHM]] [--procesor-okres[=0]] [--procesor-kwota[=0]]
[--cpuset-cpus[=CPUSET-CPU]] [--cpuset-mems[=CPUSET-MEMS]] [--ulimit[=[]]] ŚCIEŻKA | Adres URL | -

OPIS

Spowoduje to odczytanie pliku Dockerfile z katalogu określonego w PATH. Wysyła również dowolne
inne pliki i katalogi znalezione w bieżącym katalogu do demona Docker. The
zawartość tego katalogu będzie używana przez DODAJ polecenia znalezione w pliku Dockerfile.

Ostrzeżenie, spowoduje to wysłanie dużej ilości danych do demona Dockera, w zależności od zawartości
bieżący katalog. Kompilację uruchamia demon Docker, a nie CLI, więc całość
kontekst musi zostać przesłany do demona. Interfejs CLI platformy Docker zgłasza „Wysyłanie kontekstu kompilacji
do demona Docker”, gdy kontekst zostanie wysłany do demona.

Gdy podany jest adres URL archiwum tar lub pojedynczego pliku Docker, nie jest wysyłany żaden kontekst
od klienta do demona Docker. W tym przypadku plik Docker w katalogu głównym pliku
Archive, a reszta archiwum zostanie wykorzystana jako kontekst kompilacji. Kiedy Git
repozytorium jest ustawione jako URL, repozytorium jest klonowane lokalnie, a następnie wysyłane jako plik
kontekst.

OPCJE

-f, --plik=PATH/plik Dockera
Ścieżka do pliku Docker, którego chcesz użyć. Jeśli ścieżka jest ścieżką względną, a Ty nią jesteś
budowanie z katalogu lokalnego, ścieżka musi być względem niego względna
informator. Jeśli budujesz ze zdalnego adresu URL wskazującego na a
tar lub repozytorium Git, ścieżka musi odnosić się do katalogu głównego
odległy kontekst. We wszystkich przypadkach plik musi znajdować się w kontekście kompilacji.
Wartość domyślna to Dockerfile.

--build-arg=zmienna
nazwa i wartość a argument budowlany.

Na przykład, jeśli chcesz przekazać wartość dla http Proxy, Stosowanie
--build-arg=http_proxy="http://some.proxy.url"

Użytkownicy przekazują te wartości w czasie kompilacji. Docker używa argumenty konstrukcyjne jak
kontekst środowiskowy dla poleceń uruchamianych za pośrednictwem pliku Dockerfile BIEGAĆ instrukcja
lub do rozszerzania zmiennych w innych instrukcjach Dockerfile. To nie jest na myśli
do przekazywania tajnych wartości. ⟨/reference/builder/#arg⟩

--force-rm=prawdziwy|fałszywy
Zawsze usuwaj kontenery pośrednie, nawet po nieudanych kompilacjach. Wartość domyślna to
fałszywy.

--izolacja="domyślnym"
Izolacja określa rodzaj technologii izolacji stosowanej w kontenerach.

--brak pamięci podręcznej=prawdziwy|fałszywy
Nie używaj pamięci podręcznej podczas budowania obrazu. Wartość domyślna to fałszywy.

--help
Wydrukuj oświadczenie o użyciu

--ciągnąć=prawdziwy|fałszywy
Zawsze próbuj pobrać nowszą wersję obrazu. Wartość domyślna to fałszywy.

-q, --cichy=prawdziwy|fałszywy
Pomiń dane wyjściowe kompilacji i wydrukuj identyfikator obrazu, jeśli się powiedzie. Wartość domyślna to fałszywy.

--rm=prawdziwy|fałszywy
Usuń kontenery pośrednie po pomyślnej kompilacji. Wartość domyślna to prawdziwy.

-t, --etykietka= „”
Nazwy repozytoriów (i opcjonalnie ze znacznikami), które mają zostać zastosowane do wynikowego obrazu w
przypadek sukcesu.

-m, --pamięć=PAMIĘĆ
Limit pamięci

--wymiana-pamięci=LIMIT
Wartość graniczna równa pamięci plus zamiana. Należy używać z -m (--pamięć) flaga. The
zamiana LIMIT powinien być zawsze większy niż -m (--pamięć) wartość.

Format LIMIT is [ ]. Jednostka może być b (bajty), k (kilobajty), m
(megabajty) lub g (gigabajty). Jeśli nie określisz jednostki, b Jest używane. Ustaw LIMIT na -1 do
włączyć nieograniczoną wymianę.

--rozmiar shm=ROZMIAR SHM
Rozmiar /dev/shm. Format to . numer musi być większa niż 0.
Jednostka jest opcjonalna i może być b (bajty), k (kilobajty), m (megabajty) lub g (gigabajty).
Jeśli pominiesz jednostkę, system użyje bajtów.
Jeśli całkowicie pominiesz rozmiar, system go użyje 64m.

--udziały-procesora=0
Udziały procesora (waga względna).

Domyślnie wszystkie kontenery otrzymują tę samą proporcję cykli procesora.
Udziały procesora to „waga względna” w stosunku do domyślnego ustawienia wynoszącego 1024.
Ta wartość domyślna jest zdefiniowana tutaj:

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

Możesz zmienić tę proporcję, dostosowując udział procesora w kontenerze
ważenie w stosunku do ważenia wszystkich innych działających kontenerów.

Aby zmienić proporcję z domyślnej wartości 1024, użyj metody --udziały-procesora
flagę, aby ustawić wagę na 2 lub wyższą.

Flaga udziału procesora kontenera
{C0} 60% procesora --cpu-shares=614 (614 to 60% z 1024)
{C1} 40% procesora --cpu-shares=410 (410 to 40% z 1024)

Proporcja jest stosowana tylko wtedy, gdy uruchomione są procesy intensywnie obciążające procesor.
Gdy zadania w jednym kontenerze są bezczynne, inne kontenery mogą korzystać z
pozostały czas procesora. Rzeczywista ilość wykorzystanego czasu procesora różni się w zależności od
liczba kontenerów działających w systemie.

Rozważmy na przykład trzy kontenery, z których jeden ma --cpu-shares=1024 i
dwaj inni mają --cpu-shares=512. Kiedy procesy we wszystkich trzech
kontenery próbują wykorzystać 100% procesora, pierwszy kontener otrzyma
50% całkowitego czasu procesora. Jeśli dodasz czwarty pojemnik z --cpu-shares=1024,
pierwszy kontener otrzymuje tylko 33% procesora. Pozostałe pojemniki
otrzymują 16.5%, 16.5% i 33% procesora.

Udział procesora kontenera Oznacz czas procesora
{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%

W systemie wielordzeniowym udziały czasu procesora są rozdzielone pomiędzy procesor
rdzenie. Nawet jeśli kontener jest ograniczony do mniej niż 100% czasu procesora, jest to możliwe
wykorzystaj 100% każdego rdzenia procesora.

Rozważmy na przykład system z więcej niż trzema rdzeniami. Jeśli zaczniesz
pojemnik {C0} w --cpu-shares=512 uruchamiając jeden proces i inny kontener
{C1} w --cpu-shares=1024 uruchomieniem dwóch procesów, może to spowodować następujące skutki
podział udziałów CPU:

Udział procesora procesora kontenera PID
100 {C0} 0 100% CPU0
101 {C1} 1 100% CPU1
102 {C1} 2 100% CPU2

--procesor-okres=0
Ogranicz okres CFS procesora (Completely Fair Scheduler).

Ogranicz użycie procesora przez kontener. Ta flaga powoduje, że jądro ogranicza
wykorzystanie procesora kontenera do określonego okresu.

--procesor-kwota=0
Ogranicz limit procesora CFS (Completely Fair Scheduler).

Domyślnie kontenery działają z pełnymi zasobami procesora. Ta flaga powoduje, że jądro
ogranicz użycie procesora przez kontener do określonego przydziału.

--cpuset-cpus=CPUSET-CPU
Procesory, w których należy umożliwić wykonanie (0-3, 0,1).

--cpuset-mems=CPUSET-MEMS
Węzły pamięci (MEM), w których można wykonać (0-3, 0,1). Skuteczne tylko na
systemy NUMA.

Na przykład, jeśli masz w systemie cztery węzły pamięci (0-3), użyj --cpuset-mems=0,1 do
upewnij się, że procesy w kontenerze Docker używają tylko pamięci z pierwszych dwóch pamięci
węzły

--cgrupa-rodzic=CGROUP-PARENT
Ścieżka do cgrupy pod którym znajduje się kontener cgrupa są tworzone.

Jeśli ścieżka nie jest bezwzględna, uważa się ją za względną cgrupy ścieżka
proces inicjowania. Tworzone są grupy C, jeśli jeszcze nie istnieją.

--ulimit=[]
Opcje Ulimitu

Więcej informacji na temat ulimit widzieć
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

PRZYKŁADY

Budowanie an obraz za pomocą a Dockerfile usytuowany wewnątrz dotychczasowy aktualne katalog

Obrazy Dockera można tworzyć za pomocą polecenia build i pliku Dockerfile:

kompilacja dokera.

Podczas procesu kompilacji Docker tworzy obrazy pośrednie. Aby je zachować, ty
musi być wyraźnie ustawione --rm=fałsz.

kompilacja dokera --rm=false .

Dobrą praktyką jest utworzenie podkatalogu o powiązanej nazwie i utworzenie pliku Dockerfile
w tym katalogu. Na przykład katalog o nazwie mongo może zawierać plik Dockerfile
utwórz obraz Docker MongoDB. Podobnie można użyć innego katalogu o nazwie httpd
przechowuj pliki Dockerfiles dla obrazów serwerów WWW Apache.

Dobrą praktyką jest także dodanie do podkatalogu plików potrzebnych do wykonania obrazu.
Pliki te zostaną następnie określone z rozszerzeniem KOPIA or DODAJ instrukcje w Dockerfile.

Uwaga: Jeśli dołączysz plik tar (dobra praktyka), Docker automatycznie go rozpakuje
zawartość pliku tar określona w pliku DODAJ instrukcja do określonego
target.

Budowanie an obraz i nazywania że obraz

Dobrą praktyką jest nadanie nazwy budowanemu obrazowi. Pamiętaj, że tylko a-z0-9-_.
należy stosować dla zachowania spójności. Nie ma tu sztywnych zasad, ale najlepiej jest dać
rozważenie nazw.

Połączenia -t/--etykietka flaga służy do zmiany nazwy obrazu. Oto kilka przykładów:

Chociaż nie jest to dobra praktyka, nazwy obrazów mogą być dowolne:

docker build -t myimage .

Lepszym podejściem jest zapewnienie w pełni kwalifikowanego i znaczącego repozytorium, nazwy i znacznika
(gdzie tag w tym kontekście oznacza kwalifikator po „:”). W tym przykładzie my
zbuduj obraz JBoss dla repozytorium Fedory i nadaj mu wersję 1.0:

docker build -t fedora/jboss:1.0 .

Następny przykład dotyczy repozytorium użytkowników „whenry” i używa Fedory oraz JBossa i daje
to wersja 2.1:

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

Jeśli nie podasz znacznika wersji, Docker go przypisze firmy:

docker build -t kiedyry/fedora-jboss .

Gdy dodasz obrazy do listy, powyższy obraz będzie miał tag firmy.

Do obrazu można zastosować wiele tagów. Można na przykład zastosować firmy tag do
nowo zbudowany obraz i dodaj kolejny tag odwołujący się do konkretnej wersji. Na przykład do
otaguj obraz jako kiedyry/fedora-jboss:najnowsze i kiedyry/fedora-jboss:v2.1, Użyj
Następujące:

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

Zatem zmiana nazwy obrazu jest dowolna, ale należy wziąć pod uwagę użyteczną konwencję
ma to sens dla konsumentów i powinno również uwzględniać społeczność Docker
konwencje.

Budowanie an obraz za pomocą a URL

Spowoduje to sklonowanie określonego repozytorium GitHub z adresu URL i użycie go jako kontekstu. The
Dockerfile w katalogu głównym repozytorium jest używany jako Dockerfile. Działa to tylko wtedy, gdy
Repozytorium GitHub jest repozytorium dedykowanym.

kompilacja okna dokowanego github.com/scollier/purpletest

Uwaga: Możesz ustawić dowolne repozytorium Git poprzez git:// schemat.

Budowanie an obraz za pomocą a URL do a spakowane w formacie tar kontekst

Spowoduje to wysłanie samego adresu URL do demona Docker. Demon pobierze archiwum tar
archiwum, rozpakuj je i użyj jego zawartości jako kontekstu kompilacji. Plik Dockerfile w
katalog główny archiwum i reszta archiwum zostaną wykorzystane jako kontekst kompilacji.
Jeśli przejdziesz -f PATH/plik Dockera opcję, system będzie szukać tego pliku
wewnątrz zawartości archiwum tar.

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

Uwaga: obsługiwane formaty kompresji to „xz”, „bzip2”, „gzip” i „tożsamość” (nie
kompresja).

Sprecyzować izolacja technologia dla pojemnik (--izolacja)

Ta opcja jest przydatna w sytuacjach, gdy uruchamiasz kontenery Docker w systemie Windows.
Połączenia --izolacja= opcja ustawia technologię izolacji kontenera. W systemie Linux tylko
obsługiwany jest domyślnym opcja korzystająca z przestrzeni nazw Linuksa. W systemie Microsoft Windows jest to możliwe
określ te wartości:

· domyślnym: Użyj wartości określonej przez demona Docker --exec-opcja , Jeśli Demon robi
nie określa technologii izolacji, z której korzysta system Microsoft Windows wygląda tak jako domyślne
wartość.

· wygląda tak: Tylko izolacja przestrzeni nazw.

· hiperw: Izolacja hiperwizora Hyper-V oparta na partycjach.

Określanie --izolacja flaga bez wartości jest równoznaczna z ustawieniem
--isolation="domyślny".

HISTORIA

Marzec 2014, pierwotnie opracowane przez Williama Henry'ego (gdy pracował w redhat dot com) na podstawie
materiał źródłowy docker.com i prace wewnętrzne. Czerwiec 2014, aktualizacja Sven Dowideit
⟨[email chroniony]⟩ Czerwiec 2015, aktualizacja: Sally O'Malley ⟨[email chroniony]⟩

Skorzystaj z narzędzia docker-build online, korzystając z usług onworks.net