Docker как пробросить порты

Запуск команды в контейнере:

docker exec -it mytarantool bash

здесь mytarantool - имя контейнера, bash - команда

docker stop mytarantool

docker rm mytarantool

Чтобы docker for windows имел доступ к дискам, нужно сделать диск доступным в меню Settings -> Shared Drives

Просмотр всех созданных контейнеров

Запуск консоли в контейнере винды:

docker run -it microsoft/windowsservercore cmd

Искать образы удобнее в консоли:

docker search rabbitmq

Найдя нужный образ, качаем его:

docker pull rabbitmq

Сохранение образа в файл:

docker save -o myfile.tar busybox:latest

Загрузка образа из файла:

docker load -i myfile.tar

Удаление образа с диска:

docker rmi busybox

Удаление всех образов с тэгом none:

docker rmi $(docker images -f 'dangling=true' -q)

Удаление всех образов с rancher в названии:

docker rmi $(docker images | gren 'rancher' | tr -s ' ' | cut -d ' ' -f 3)

Вывод инфы об контейнере:

Выдастся большой json, если нужен его определенный узел, то можно через -f указать узел, пример:

docker inspect -f ">" bmweb выдаст все мапы волюмов

docker inspect -f ">" bmweb аналогично, но более подробно

Построение образа из Dockerfile:

docker build -t dia_ch3/dockerfile:latest ch3_dockerfile

-t - имя полученного образа. По умолчанию будет установлен в локальный регистр с указанным именем.

последний аргумент - папка, в которой лежит Dockerfile и все сопутствующие файлы

Волюмы бывают двух типов:

bind mount - обычный, где папка контейнера мапится на пользовательскую папку хоста

docker-managed volume - папка контейнера маппится на папку хоста, созданную демоном докера ( /var/lib/docker/vfs/dir/ )

Быстрое поднятие веб-сервера, раздающего папку с файлами с локального диска:

docker run -d --name bmweb -v c:\userfiles:/usr/local/apache2/htdocs -p 80:80 httpd:latest**

Volume container - контейнер, предоставляющий волюм, чтобы остальные контейнерымогли использовать его в флаге --volumes-from. Так же позволяет избежать orphane volume, когда на волюм не осталось ссылок и его никто не удалил и он занимает место на диске.

Data-packed volume container - это такой контейнер, который не содержит в себе никакого приложения, но содержит контент, который при старте копируется в шаренный волюм.

Полиформный контейнер - такой контейнер, поведение которого определяется содержимым его волюма. Например, контейнер содержит NodeJS и запускает приложение по адресу /app/app.js, а это волюм и определяется хостом.

А вот так можно задавать разные конфиги одному и тому же приложению в образе:

docker run --name devConfig -v /config dockerinaction/ch4_packed_config:latest /bin/sh -c 'cp /development/* /config/' docker run --name prodConfig -v /config dockerinaction/ch4_packed_config:latest /bin/sh -c 'cp /production/* /config/' docker run --name devApp --volumes-from devConfig dockerinaction/ch4_polyapp docker run --name prodApp --volumes-from prodConfig dockerinaction/ch4_polyapp

4 архетипа контейнеров по отношению к закрытости сети:

Может общаться только с собой через loopback-интерфейс. Создается, используя --net none при создании контейнера

Дефолтный вариант. Имеет loopback-интерфейс и приватный интерфейс, соединенный с хостом через мост. Создается, используя --net bridge .

docker port - показывает список всех замапленных портов.

--hostname - задает имя хоста, видимое только изнутри этого же самого контейнера.

--dns - задает главный DNS-сервер. Можно задать несколько таких серверов, а еще можно этот флаг задать демону dockerd и эти сервера будут по умолчанию заданы всем создаваемым контейнерам.

--dns-search - позволяет задать задать домен, по которому будут искаться все адреса, для которых не указан домен. Таким образом можно, например, различать тестовое и продакшн-окружение.

--add-host - позволяет задать ip для определенного хоста (как запись в hosts в Windows)

-p/--publish - позволяет задать порт-форвардинг

-P//--publish-all - паблишит все порты, которые заданы через EXPOSE

--expose - заэкспоузить дополнительный порт

--icc=false - отключает inter-container communication

--bip - позволяет задать IP-адрес контейнера и его subnet range, пример: --bip "192.168.0.128/25"

--mtu - задает MTU, максимальный размер пакета в байтах

-b/--bridge - позволяет задать собственный интерфейс моста

Это несколько контейнеров, которые шарят общий сетевой стэк.

Docker в этом случае предоставляет интерфейсы, созданные специально для одного контейнера, другим контейнерам.

Для этого типа соединения первый контейнер создается как угодно, а затем к нему присоединяются остальные.

Присоединяются так: docker run --net container: .

Полезно, когда нужно чтобы 2 контейнера могли общаться меж собой, но не могли общаться с внешним миром. Тогда создаем первый закрытым и присоединяем к нему второй.

--net host Никакой изоляции, видит все те же сетевые интерфейсы, что и хост.

Можно связать контейнеры однонаправленной связью через --link.

docker run -d --name a mysql

docker run -d --name b --link a:db

При этом в контейнер b будут добавлены:

- переменные окружения для связи с a

- запись в dns, сопоставляющая ip контейнера a с хостом db

- если icc=false, то будут также добавлены правила в фаерволлы контейнеров для сетевого взаимодействия между ними

Сценарий использования: в контейнере b сервис ожидает, что по адресу tcp://db:3306 будет база данных. Или же он может брать порт базы из переменной окружения DB_PORT. Когда делаем --link оба этих значения будут автоматически заполнены.

Хорошей практикой считается на старте контейнера проверять, что заданы все необходимые переменные окружения/записи днс. Пример такого скрипта:

if [ -z $ ] then echo "Link alias 'database' was not set!" exit else exec "$@" fi 

Список переменных окружения, задаваемых при линке:

docker run -d --name mydb --expose 2222 --expose 3333 --expose 4444/udp alpine:latest nc -l 0.0.0.0:2222 docker run -it --rm --link mydb:database dockerinaction/ch5_ff env DATABASE_PORT=tcp://172.17.0.23:3333 - любой из полных адресов для exposed-портов DATABASE_PORT_3333_TCP=tcp://172.17.0.23:3333 DATABASE_PORT_2222_TCP=tcp://172.17.0.23:2222 DATABASE_PORT_4444_UDP=udp://172.17.0.23:4444 DATABASE_PORT_2222_TCP_PORT=2222 DATABASE_PORT_3333_TCP_PORT=3333 DATABASE_PORT_4444_UDP_PORT=4444 DATABASE_PORT_3333_TCP_ADDR=172.17.0.23 DATABASE_PORT_2222_TCP_ADDR=172.17.0.23 DATABASE_PORT_4444_UDP_ADDR=172.17.0.23 DATABASE_PORT_2222_TCP_PROTO=tcp DATABASE_PORT_3333_TCP_PROTO=tcp DATABASE_PORT_4444_UDP_PROTO=udp DATABASE_NAME=/furious_lalande/database - имя текущего контейнера + / + имя алиаса

Проблема с линками в том, что если контейнер-зависимость перезапустится, то у него будет новый Ip и все эти переменные станут неактуальными. Решением может быть использование DNS, либо же включение nter-process communication.

Вывод всех образов в приватном репозитории:

curl -X GET gitlab.factory.vocord.ru:5000/v2/_catalog

-m/--memory - ограничение по памяти, пример --memory 256m \--cpu-shares - относительное ограничение CPU. Если одному связанному контейнеру указать 512, а другому 256, то второй будет получать 1 цикл на каждые 2цикла первого. \--cpuset-cpus - указывает контейнерам, что они должны выполняться только на определенных ядрах \--device /dev/video0:/dev/video0 - маппит девайсы внутрь контейнера \--ipc container: \- шарит shared memory с указанным контейнером \--ipc host - шарить всю память с хостом

docker run --rm --entrypoint "" busybox:latest whoami - вывод дефолтного пользователя внутри контейнера

-u/--user - указывает пользователя, под которым запустить контейнер

Пример: docker run -u nobody:default - устанавливает юзера nobody и группу default

Создание образа из контейнера:**

1. Скачиваем образ
2. Делаем изменения в его файловой системе docker run --name hw_container ubuntu:latest touch /HelloWorld
3. Коммитим эти изменения как новый контейнер docker commit hw_container hw_image

-a - подписывает образ авторской строкой

-m - commit message

-c --change - позволяет дописывать строки в Dockerfile, пример: docker commit -c "CMD /notebook.sh" notebook notebook-my

docker commit -a "@dockerinaction" -m "Added git" image-dev ubuntu-git

entrypoint - Это программа, которая будет запущена при старте. Она тоже коммитится в образ.

docker run --name cmd-git --entrypoint git ubuntu-git

Кроме этого коммитятся:

• все переменные окружения
• рабочая директория
• открытые порты
• объявления волюмов
• точка входа в контейнер
• сама команда и все ее аргументы

docker diff - выводит список изменений в файловой системе контейнера относительно образа, из которого он создан. A - added, C - changed, D - deleted.

Union file system

В докере используется UFS, в которой файловая система представляется в виде объединения слоев. Редактируемый слой - только верхний, остальные все read-only. Новый слой сохраняется при коммите образа.

Благодаря такой системе, слои могут переиспользоваться в нескольких контейнерах, вместо того чтобы каждый раз копироваться. Однако есть и недостаток - старые слои никогда не удаляются, а значит образ может только увеличиваться в размерах и никогда не уменьшаться.

Максимальное количество слоев - 42.

docker history - выводит все коммиты/слои файловой системы

docker export --output export.tar ubuntu - сохраняет всю файловую систему контейнера в архив на хосте

docker import -c "ENTRYPOINT [\"/hello\"]" hello.tar dockerinaction/ch7_static - берет .tar с файлами и создает из них образ

FROM ubuntu:latest MAINTAINER "dockerinaction@allingeek.com" RUN apt-get update RUN apt-get install -y git ENTRYPOINT ["git"] 

docker build --tag ubuntu-git:auto . - точка на конце означает текущую директорию

Все команды, описанные в докерфайле (включая RUN ) будут выполнены на этапе построения образа.

Первая команда всегда должна быть FROM . Если нужен пустой родитель, то можно указать FROM scratch .

Каждая инструкция в докерфайле создает новый слой в образе. Поэтому лучше эти инструкции по максимуму объединять, чтобы уменьшить размер образа. Если возникла ошибка на шаге N, то при повторной попытке шаги 1..N-1 будут взяты из кэша. Но если хочется не юзать кэш, то можно указать флаг --no-cache .

Всего есть 14 инструкций Dockerfile.

В файле .dockerignore можно перечислить, какие файлы не включать в образ.

ENV - задает переменные окружения, пример: ENV APPROOT="/app" APP="mailer.sh" VERSION="0.6" (здесь задается 3 переменных). Заданные переменные окружения можно использовать в последующих инструкциях, используя синтаксис $

** LABEL** - дополнительные пары ключ-значение, записываемые в метаданные образа. Пример: LABEL base.name="Mailer Archetype" base.version="$"

WORKDIR- задает working directory, то есть ту директорию, в которой начнется исполнение образа. Пример: WORKDIR $APPROOT

EXPOSE- Открывает порт. Пример: EXPOSE 33333

ENTRYPOINT- команда, которую запускать при старте образа. Можно либо задать команду консоли (shell form), либо массив строк, в котором первая строка - путь к исполняемому файлу, а остальные - аргументы запуска (exec form). shell form при этом менее гибок, так как не позволяет задавать последний аргумент в docker run или предоставлять дополнительные аргументы в инструкции CMD. Дефолтный entrypoint - /bin/sh

COPY - копирует файлы в образ. Принимает массив строк, где последний аргумент - папка назначения, а все остальные - копируемые файлы. Пример: COPY ["./log-impl", "$"]

VOLUME- создает волюм, то же самое что и --volume. Только нельзя задать bind-mount или read-only волюм. В массиве аргументов для каждого значения будет создан волюм. Пример: VOLUME ["/var/log"] .

CMD- задает аргументы для entrypoint. Если entrypoint не задан, либо задан в shell-форме, то это может быть команда для шелла, так как будет использован дефолтный entrypoint.

ONBUILD- инструкция, которая будет выполняться, если текущий образ будет использован как базовый для другого образа. Эти инструкции записываются в метаданные текущего образа. С их помощью можно, например, сбилдить программу, предоставляемую образом-потомком. ONBUILD-инструкции выполняются сразу после FROM в потомке.

Docker file system

Используется файловая система overlay2.

Слои для каждого контейнера перечислены здесь:

Там есть 3 файла:

• init-id - это идентификатор слоя, используемый при создании контейнера
• mount-id - идентификатор слоя, который был образован в процессе работы контейнера
• parent - какой-то идентификатор, видимо, родительского слоя

По идентификатору слоя можно получить его содержимое так:

Если во всех образах перестала работать сеть, то можно пересоздать мост:

pkill docker iptables -t nat -F ifconfig docker0 down ip link del docker0 systemctl start docker

Если ifconfig не найден, то apt install net-tools

Автоматическая очистка места на диске

По адресу /etc/cron.daily/docker-gc создаем скрипт следующего содержания:

#!/bin/sh -e # Delete all stopped containers (including data-only containers). docker ps -a -q --no-trunc --filter "status=exited" | xargs --no-run-if-empty docker rm -v # Delete all tagged images more than a month old docker images --no-trunc --format '> >' | grep ' months' | awk '< print $1 >' | xargs --no-run-if-empty docker rmi -f || true # Delete all 'untagged/dangling' () images # Those are used for Docker caching mechanism. docker images -q --no-trunc --filter dangling=true | xargs --no-run-if-empty docker rmi # Delete all dangling volumes. docker volume ls -qf dangling=true | xargs --no-run-if-empty docker volume rm

sudo chmod +x /etc/cron.daily/docker-gc

Добавляем новый джоб в crontab :

crontab -e

Открывается текстовый редактор, нужно в него добавить строчку:

0 0 * * * /etc/cron.daily/docker-gc

не забыть последнюю строчку сделать пустой (иначе кронтаб ругаться будет) и выйти с сохранением

Файловая система докера

По умолчанию находится в папке /var/lib/docker

Структура файловой системы зависит от используемого драйвера хранилища. У меня на Debian это по уомлчанию overlay2, поэтому дальнейшая информация справедлива для него. Узнать свой драйвер можно командой docker info в графе Storage Driver

В /var/lib/docker можем найти следующие подпапки:

• builder
• buildkit
• containerd
• containers
• image
• network
• overlay2
• plugins
• runtimes
• swarm
• tmp
• trust
• volumes

Описания образов лежат по адресу: /var/lib/docker/image/overlay2/imagedb/content/sha256 .

Например, если мы ходим посмотреть описание образа с идентификатором ebaee1a37cda. , то нам нужно в текстовом редакторе открыть файл /var/lib/docker/image/overlay2/imagedb/content/sha256/ebaee1a37cda. . В этом текстовом файле лежит в основном та же инфа, которую мы получаем через docker inspect ebaee1a37cda , только иначе структурирована.

Но в этом файле мы не найден идентификаторы слоев образа для overlay2, те идентификаторы которые там указаны - они для RootFS (так и не понял, зачем нужны). Полезные идентификаторы будем брать из вывода docker inspect ebaee1a37cda :

"GraphDriver": < "Data": < "LowerDir": "/var/lib/docker/overlay2/1ef930458b9b7c4b107589bfa8708a5a905c0bff78fe82c04db1b65908ca356f/diff:/var/lib/docker/overlay2/990d47bc6c20549415caca3a6f6cfffc43b34491f128eeafffc2a8214c86ff1a/diff:/var/lib/docker/overlay2/6465e9cbb477e85f312139fd430c82649d5559190f2eed4fe32d1b2c2ca9bd9b/diff:/var/lib/docker/overlay2/7a924b04842adb199e077c02c4661955fb318d5d276c5c66b2e07628a69fc49d/diff:/var/lib/docker/overlay2/b4cf7f55f924b2167262f246ecdd8d2400adfbac69d0258049c619293228b6f0/diff", "MergedDir": "/var/lib/docker/overlay2/cf7ef417035f8dcbaabecdb4897a94ef1ad00b0919ddf4f7af0b1150b9c7bd8f/merged", "UpperDir": "/var/lib/docker/overlay2/cf7ef417035f8dcbaabecdb4897a94ef1ad00b0919ddf4f7af0b1150b9c7bd8f/diff", "WorkDir": "/var/lib/docker/overlay2/cf7ef417035f8dcbaabecdb4897a94ef1ad00b0919ddf4f7af0b1150b9c7bd8f/work" >, "Name": "overlay2" >,

Верхний слой описан в поле MergedDir . Пройдем по этому адресу:

$ cd /var/lib/docker/overlay2/cf7ef417035f8dcbaabecdb4897a94ef1ad00b0919ddf4f7af0b1150b9c7bd8f/ $ ls diff link lower work 

В файле link содержится сокращенный идентификатор слоя:

$ cat link HRKAB26PG22YEF25QW3DFUSPVO

В lower - сокращенные идентификаторы нижних слоев, разделенные двоеточием:

$ cat lower l/ZJPNNPNGB2QUT7UHS6FGJAJEXS:l/ITT6VDHHVLTL4XSV4MKXFARWZX:l/D73DFE6U73XW47KLW2IWYFN3X4:l/GPI73DKAIBG4M4HEPH22KTQBLS:l/AIQ55Z4PNLZZZTY5PWAD7EY74K

В папке /var/lib/docker/overlay2/l содержатся симлинки от сокращенных идентификаторов слоев к нормальным:

y# ls /var/lib/docker/overlay2/l/ZJPNNPNGB2QUT7UHS6FGJAJEXS -l lrwxrwxrwx 1 root root 72 Jan 22 11:17 /var/lib/docker/overlay2/l/ZJPNNPNGB2QUT7UHS6FGJAJEXS -> ../1ef930458b9b7c4b107589bfa8708a5a905c0bff78fe82c04db1b65908ca356f/diff

Как видим, второй сверху слой нашего образа ZJPNNPNGB2QUT7UHS6FGJAJEXS соответствует слою 1ef930458b9b7c4b107589bfa8708a5a905c0bff78fe82c04db1b65908ca356f . А его содержимое можем посмотреть в папке diff (посмотрим самый нижний слой нашего образа, содержащий файловую систему базового образа):

y# ls /var/lib/docker/overlay2/l/AIQ55Z4PNLZZZTY5PWAD7EY74K bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var