docker run rm v что за команды

Docker — краткая справка по основам и базовым командам

В этой инструкии, не будет описания по установке docker — всю эту информацию можно найти на официальном сайте, только базовые понятия и основные команды.

Docker контейнеры создаются на основе docker images.
Для создания собственных docker images необходимо:

Docker основные команды

docker build — создает свой общественный docker образ.

НО при выполнении данной команды необходимо, что бы в директории выполнения (текущей) был Docker файл.
т.е. файл без расширения с названием Dockerfile в котором будут описаны все инструкции по созданию образа.

Пример dockerfile

Для данного примеры мы заранее создали python приложение app.py
В котором расположен обычный скрипт print(«hello world») и теперь мы хотим упаковать наше приложение в образ.

Итак пример dockerfile’a:

Далее если выполнить команду: docker images
Мы увидим, что у нас появился наш новый образ: my-supper-image и скаченный образ python, т.к. его мы использовали при сборке.

Запуск образа в контейнере

docker run my-supper-image — Запускает образ в контейнере, после run передаем имя приложения.

Важно понимать, что в таком случае контейнер работает до тех пор пока работает приложение.
В нашем случае, запуститься python и наш скрипт app.py который выполнить print(), после чего работа контейнер будет остановлена.

В таблице в поле name мы увидим:
blablabla_lala — имя контейнера запущенного в 1-ый раз
my-new-name — имя контейнера запущенного с директивой name
т.е. по факту мы уже имеем уже 2 контейнера на основании 1-го образа.

Запуск контейнера в фоновом режиме

Удаление контейнеров

docker rm — удалит выбранный контейнер, принимает или имя контейнера или его ID
docker rm blablabla_lala

Как удалить 50-100-200 контейнеров за раз

Остановка контейнера

docker stop имя_контейнера(или id)

Авто удаление контейнера после остановки

Как запустить контейнер, что бы после принудительной остановки(stop), либо после того как он отработает,
он автоматически удалился. Для этого в параметры запуска необходимо передать флаг —rm

Пример упаковки приложения

Упаковка приложения на flask в контейнер.
Подразумеваем, что мы создали небольшое приложение на flask и разместили его код, в файле app.py.
Далее мы создали файл с зависимостями requirements.txt
Соответсвенно в dockerfile необходимо прописать команду для установки всех зависимостей из requirements.txt в образ

Запустим образ с упакованным flask приложением в контейнере:
docker run —rm —name web web-hello

Проброска портов

При выполнении этой команды, мы не сможем достучаться до web приложения т.к. не проброшены порты.
По умолчанию flask запускается на порту 8080.
По этому в dockerfile добавим команду:
EXPOSE 8080
которая говорит о том, что при запуске контейнера, у нас есть возможность(разрешение) пробросить порт 8080.

Запускаем контейнер еще раз с флагом —p
который принимает 2 параметра:
1-ый порт на нашей машине
2-ой порт в самом контейнере

docker run —rm —name web —p 8080:8080 web-hello

Docker volume и обмен данными с контейнером

Как прикрутить(обмениваться) данными с контейнером.

Способ №1 — монтирование папки к контейнеру.

Для этого необходимо запустить контейнер с флагом -v
-v принимает 2 параметра:
1 — абсолютный путь к папке на локальном компьютере
2 — абсолютный путь в докер контейнере

Соответсвеноо в папке на локальном компьютере мы можем создать файл, условно readmy.txt
содержимое файла будет выводится flask-ом на страницу, соответсвенно при изменении файла
в этом случае фласк будет выводить разный текст.

Способ №2 Docker Volume

По своей сути Volume — эта таже папкка но уже с доп надстройками.
т.е. мы создаем docker volume и его присоединяем к контейнеру.

Для того что бы посмотреть какие volum-ы доступны, необходимо выполнить команду :

docker volume ls

Создание Volume

Для создания volume используется команда create имя_volume

docker volume create web

Запуск DOCKER с подключенным VOLUME

Для запуска контейнера с подключенным VOLUME необходимо добавить флаг:
-v имя_созданного_volume:абсолютный_путь

Теперь после запуска вся информация из папки /usr/src/app/temp будет храниться в volume
Соответственно при остановке контейнера с информацией ничего не случиться т.к. она хранится в volume
это, актуально для баз данных или для файловых серверов. В дальнейшем мы даже можем привязать этот volume к
другому контейнеру

Как удалить image

Выполняем команду:
docker images — получаем весь список images

Удаление:
docker rmi имя_images

Docker compose

Так вот, что бы каждый раз не писать docker run с кучей параметров, все это можно прописать в специальном файле который будет запускать все контейнеры с нужными параметрами.

Создаем файл: docker-compose.yaml
…

Источник

Изучаем Docker, часть 5: команды

Сегодняшняя часть цикла материалов по Docker, перевод которого мы публикуем, посвящена командам Docker. Документация Docker содержит подробнейшее описание великого множества команд, но тот, кто только начинает работу с этой платформой, может в них и потеряться, поэтому здесь приведены почти два десятка самых важных команд для работы с Docker. Продолжая сложившуюся традицию, мы сравним команды с россыпью ягод.

Обзор

Давайте вспомним о том, что образы Docker создают на основе файлов Dockerfile, описывающих всё то, что нужно для сборки образов. Кроме того, не будем забывать и о том, что контейнер — это образ Docker, вызванный к жизни. Для того чтобы эффективно пользоваться командами Docker, в первую очередь нужно выяснить — с чем вы имеете дело — с образом или с контейнером. Если подумать об образах и контейнерах, то можно понять, что образ Docker может либо существовать, либо не существовать. То же самое можно сказать и о контейнерах Docker. Существующий контейнер Docker, кроме того, может пребывать либо в работающем, либо в неработающем состоянии.

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

Общие сведения о командах Docker

Вот кое-что, о чём полезно знать тем, кто хочет работать с Docker:

Цель этого материала заключается в том, чтобы дать вам общие сведения о командах Docker. Так вы, имея общее представление о них и зная о возможностях платформы, доступных благодаря этим командам, сможете, при необходимости, найти подробные сведения о них. Команды, о которых пойдёт речь, испытаны на ОС семейства Linux с использованием движка Docker версии 18.09.1 и API версии 1.39.

Примечание о командах, поддерживаемых Docker CLI 1.13

Сначала мы посмотрим на команды, предназначенные для управления контейнерами, затем обсудим управление образами.

Команды для управления контейнерами

Общая схема команд для управления контейнерами выглядит так:

Вот команды, которые могут быть подставлены туда, где мы использовали my_command :

Команды для управления образами

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

Вот некоторые из команд этой группы:

Разные команды

Контейнеры

▍Начало существования контейнера

Вот команда для создания контейнера из образа:

После того, как контейнер создан, его можно запустить следующей командой:

Теперь взглянем на команду, которая позволяет создать и запустить контейнер:

Эта команда тоже способна принимать множество аргументов командной строки. Рассмотрим некоторые из них на примере такой конструкции:

Рассмотрим ещё некоторые примеры команды run :

Вот ещё один пример работы с командой run :

▍Проверка состояния контейнера

Если у вас имеются запущенные контейнеры Docker и вы хотите узнать о том, что это за контейнеры, вам понадобится вывести их список. Сделать это можно такой командой:

Эта команда выводит список выполняющихся контейнеров и снабжает этот список некоторыми полезными сведениями о них. Вот ещё один пример этой команды:

Вот команда, которая выводит подробные сведения о контейнере:

Вот команда, выводящая логи контейнера:

▍Завершение работы контейнера

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

Она позволяет останавливать работающие контейнеры, позволяя им корректно завершить работу. У контейнера есть, по умолчанию, 10 секунд, на то, чтобы завершить работу.

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

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

Для удаления остановленного контейнера можно воспользоваться такой командой:

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

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

Образы

▍Создание образов

Вот команда, которая позволяет собирать образы Docker:

Точка в конце команды указывает на то, что образ надо собрать с использованием файла Dockerfile, находящегося в текущей рабочей директории.

После того, как образ собран, его можно отправить в удалённый реестр. Благодаря этому им смогут воспользоваться другие люди, его можно будет загрузить и запустить на другом компьютере. Предположим, вы хотите использовать Docker Hub. Если так — вам понадобится завести там учётную запись. Пользоваться этим ресурсом можно бесплатно.

После того, как вы зарегистрируетесь на Docker Hub, вам нужно войти в систему. И хотя команда, которая для этого используется, напрямую к командам, предназначенным для работы с образами, не относится, её полезно будет рассмотреть именно здесь. Речь идёт о следующей команде:

Она позволяет войти в учётную запись на Docker Hub. Для входа в систему вам понадобится ввести имя пользователя и пароль.

После входа в систему можно будет отправлять образы в реестр. Делается это так:

Теперь, когда у вас наберётся несколько образов, вы можете их исследовать с помощью специальных команд.

▍Исследование образов

Вот команда, которая выводит список образов, выводя, в том числе, и сведения об их размере:

Следующая команда позволяет вывести сведения о промежуточных образах, входящих в состав образа, в частности — данные об их размерах и о том, как они были созданы:

Вот команда, которая выводит подробные сведения об образе, в том числе — данные о слоях, из которых состоит образ:

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

▍Удаление образов

Вот команда, которая позволяет удалить указанный образ:

Если образ хранится в удалённом репозитории, он оттуда удалён не будет.

Вот команда, которая позволяет удалить все локальные образы:

Пользоваться этой командой стоит с осторожностью, но надо заметить, что при её использовании образы, хранящиеся в удалённом репозитории, удалены не будут. В этом заключается одно из преимуществ хранения образов в репозиториях.

Мы рассмотрели основные команды, используемые для управления контейнерами и образами. Поговорим теперь ещё о некоторых командах.

Разные команды

Вот команда, которая выводит сведения о версиях клиента и сервера Docker:

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

Такая команда позволяет удалить неиспользуемые контейнеры, сети и образы, которым не назначено имя и тег:

Вот пример её использования:

Итоги

В этом материале мы рассмотрели полезные команды Docker. Если вы только начинаете работать с Docker, то вам стоит обратить внимание на три следующих важнейших команды:

Создание и запуск контейнера:

Отправка образа в удалённый репозиторий:

В следующий раз мы поговорим о работе с данными в Docker.

Уважаемые читатели! Если вы работаете с Docker, то у вас, наверняка, есть собственный список часто используемых команд. Если это так — просим вас этим списком поделиться.

Источник

Запуск контейнера Docker

Технология Docker набирает всё большую популярность среди разработчиков и DevOps-специалистов в наши дни, поскольку позволяет без особого труда настроить различные окружения один раз, а затем воспроизводить их на, казалось бы, совсем не совместимом оборудовании. Но начнём мы наш цикл статей о Docker с азов.

В сегодняшней статье мы поговорим о создании контейнеров и, соответственно, об их запуске. В Docker контейнер представляет собой окружение для выполнения какого-либо одного процесса. Это изолированная среда, в которой есть всё необходимое для выполнения нужного процесса, и нет ничего лишнего. Создание контейнера Docker выполняется в момент его запуска, и эти процессы запускаются с помощью команды docker run. Давайте сначала рассмотрим её синтаксис и опции.

Синтаксис и опции docker run

Синтаксис команды docker run похож на синтаксис других команд Linux и выглядит следующим образом:

$ docker run опции образ команда

Утилите обязательно надо передать образ, на основе которого будет создан контейнер. Образ может быть локальным или указывать на образ, который надо загрузить из сети. Мы рассмотрим это в примерах ниже. Опции позволяют настроить контейнер и параметры его запуска более детально. Сама команда позволяет переопределить программу, которая выполняется после запуска контейнера. Например, выполнив /bin/bash, вы можете подключится к самому контейнеру.

Рассмотрим основные опции утилиты, которые мы будем использовать. Опций очень много, поэтому я не могу перечислить их все:

Это основные опции, которые мы будем использовать в этой статье, а теперь давайте рассмотрим на примерах, как создать контейнер Docker в Linux.

Создание контейнера Docker

1. Обычный контейнер

Чтобы создать и запустить контейнер с параметрами, заданными в образе по умолчанию, просто запустите команду без параметров. Давайте воспользуемся контейнером hello-world, который как раз для этого и предназначен:

docker run hello-world

После запуска контейнера Docker будет выведено сообщение с приветствием, и процесс в контейнере завершится.

Для поиска уже готовых образов для контейнеров можно использовать веб-сайт DockerHub. Здесь есть образы для большинства дистрибутивов и системных сервисов, таких, как Nginx, Apache, PHP-FPM, PhpMyAdmin и многих других.

2. Подключение к контейнеру

Образ Ubuntu 18.04, на основе которого мы создали контейнер выше, не содержит команды, которая бы постоянно выполнялась, поэтому если вы попытаетесь подключится к нему с помощью команды docker exec, то получите ошибку: You cannot attach to a stopped container, start it first:

docker attach Ubuntu1804

Так происходит потому, что окружение не может работать без основного процесса, для которого и создан контейнер. Пока работает процесс, будет работать и контейнер. Как только процесс завершён, контейнер завершается, и созданный нами ранее контейнер полностью бесполезен. Вы не сможете к нему подключится, потому что он будет падать сразу же после старта, а к упавшему контейнеру подключится нельзя. Его можно удалить:

docker rm Ubuntu1804

А нам надо создать контейнер с командой, которая будет выполняться. Для этого просто передайте команду после имени образа, например /bin/bash. Чтобы контейнер был доступен интерактивно, создавайте его с опциями -i и -t:

Теперь вы в контейнере и можете выполнять действия прямо в изолированном окружении.

3. Переменные окружения

Очень часто для изменения настроек контейнера используются переменные окружения. Вы задаёте какую-нибудь переменную окружения, а затем её значение используется вашей программой в самом контейнере для выполнения различных действий. Для задания переменных окружения используется опция -e. Запуск контейнера Docker:

4. Монтирование папок и хранилищ

/test_docker в контейнер:

Хранилища позволяют монтировать в контейнер виртуальный диск, который не удаляется при удалении контейнера. Такое хранилище будет автоматически создано, если передать не существующую папку, а имя для нового хранилища:

Напоминаю, что опция —rm удаляет контейнер сразу же после того, как он завершит свою работу. Посмотреть список доступных хранилищ можно командой:

docker volume list

5. Порты контейнера

Если вам нужно получить доступ к какому-либо сервису контейнера по порту, например к веб-интерфейсу, этот порт надо пробросить в хост-систему. Для этого используется опция -p. Давайте установим Nginx и пробросим его порт в хост-систему:

6. Связывание контейнеров

Связывание контейнеров позволяет настроить взаимодействие между ними. Связанный контейнер будет доступен по сети по его имени. Соответствующая строчка будет автоматически добавлена в файл /etc/hosts контейнера. Для связывания используется опция —link. Чтобы закрепить знания, полученные выше, давайте создадим контейнер с базой данных MySQL, а затем свяжем его с PhpMyAdmin.

Затем создаём контейнер с PhpMyAdmin для доступа к этой базе данных и связываем с ним контейнер MySQL под именем db:

Также здесь мы пробрасываем порт 80 в хост-систему, чтобы получить доступ к веб-интерфейсу. Теперь можно проверять в браузере. Всё работает.

7. Сеть для контейнеров

Контейнеры можно не связывать. Если надо объединить три и больше контейнеров между собой, то куда удобнее сразу связать их в одну общую сеть, чем создавать множество подключений для каждого из этих контейнеров. Все объекты в одной сети будут иметь доступ к друг другу по их имени. Сначала необходимо создать сеть:

Посмотреть список созданных сетей можно командой:

docker network list

Теперь можно её использовать. Объединим с помощью сети наш MySQL- и PhpMyAdmin-сервера. Для этого надо их остановить и удалить:

docker stop MySQL
docker stop PhpMyAdmin

docker rm MySQL
docker rm PhpMyadmin

А для PhpMyAdmin теперь надо передать хост, на котором расположена база данных в переменной окружения PMA_HOST:

Выводы

В этой статье мы рассмотрели, как запустить контейнер Docker и настроить его параметры. Как видите, Docker может быть очень полезным для быстрого разворачивания рабочих окружений. Но редко для этих целей используют саму команду docker run. Обычно используется инструмент docker-compose. Интересно ли вам прочитать об этом инструменте? Напишите в комментариях!

Источник

Docker run reference

This page details how to use the docker run command to define the containerвЂ™s resources at runtime.

General form

The basic docker run command takes this form:

The docker run command must specify an IMAGE to derive the container from. An image developer can define image defaults related to:

With the docker run [OPTIONS] an operator can add to or override the image defaults set by a developer. And, additionally, operators can override nearly all the defaults set by the Docker runtime itself. The operatorвЂ™s ability to override image and Docker runtime defaults is why run has more options than any other docker command.

Operator exclusive options

Only the operator (the person executing docker run ) can set the following options.

Detached vs foreground

When starting a Docker container, you must first decide if you want to run the container in the background in a вЂњdetachedвЂќ mode or in the default foreground mode:

Detached (-d)

Do not pass a service x start command to a detached container. For example, this command attempts to start the nginx service.

This succeeds in starting the nginx service inside the container. However, it fails the detached container paradigm in that, the root process ( service nginx start ) returns and the detached container stops as designed. As a result, the nginx service is started but could not be used. Instead, to start a process such as the nginx web server do the following:

To do input/output with a detached container use network connections or shared volumes. These are required because the container is no longer listening to the command line where docker run was run.

To reattach to a detached container, use docker attach command.

Foreground

A process running as PID 1 inside a container is treated specially by Linux: it ignores any signal with the default action. As a result, the process will not terminate on SIGINT or SIGTERM unless it is coded to do so.

Container identification

Name (—name)

The operator can identify a container in three ways:

Identifier type	Example value
UUID long identifier	вЂњf78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778вЂќ
UUID short identifier	вЂњf78375b1c487вЂќ
Name	вЂњevil_ptolemyвЂќ

Containers on the default bridge network must be linked to communicate by name.

PID equivalent

Finally, to help with automation, you can have Docker write the container ID out to a file of your choosing. This is similar to how some programs might write out their process ID to a file (youвЂ™ve seen them as PID files):

Image[:tag]

Image[@digest]

Images using the v2 or later image format have a content-addressable identifier called a digest. As long as the input used to generate the image is unchanged, the digest value is predictable and referenceable.

The following example runs a container from the alpine image with the sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 digest:

PID settings (—pid)

By default, all containers have the PID namespace enabled.

PID namespace provides separation of processes. The PID Namespace removes the view of the system processes, and allows process ids to be reused including pid 1.

Example: run htop inside a container

Create this Dockerfile:

Build the Dockerfile and tag the image as myhtop :

Use the following command to run htop inside a container:

Joining another containerвЂ™s pid namespace can be used for debugging that container.

Example

Start a container running a redis server:

Debug the redis container by running another container that has strace in it:

UTS settings (—uts)

You may wish to share the UTS namespace with the host if you would like the hostname of the container to change as the hostname of the host changes. A more advanced use case would be changing the hostвЂ™s hostname from a container.

IPC settings (—ipc)

The following values are accepted:

Value	Description
вЂќвЂќ	Use daemonвЂ™s default.
вЂњnoneвЂќ	Own private IPC namespace, with /dev/shm not mounted.
вЂњprivateвЂќ	Own private IPC namespace.
вЂњshareableвЂќ	Own private IPC namespace, with a possibility to share it with other containers.
вЂњcontainer: «	Join another (вЂњshareableвЂќ) containerвЂ™s IPC namespace.
вЂњhostвЂќ	Use the host systemвЂ™s IPC namespace.

IPC (POSIX/SysV IPC) namespace provides separation of named shared memory segments, semaphores and message queues.

Shared memory segments are used to accelerate inter-process communication at memory speed, rather than through pipes or through the network stack. Shared memory is commonly used by databases and custom-built (typically C/OpenMPI, C++/using boost libraries) high performance applications for scientific computing and financial services industries. If these types of applications are broken into multiple containers, you might need to share the IPC mechanisms of the containers, using «shareable» mode for the main (i.e. вЂњdonorвЂќ) container, and «container: » for other containers.

Network settings

Publishing ports and linking to other containers only works with the default (bridge). The linking feature is a legacy feature. You should always prefer using Docker network drivers over linking.

Network	Description
none	No networking in the container.
bridge (default)	Connect the container to the bridge via veth interfaces.
host	Use the host’s network stack inside the container.
container:	Use the network stack of another container, specified via its name or id.
NETWORK	Connects the container to a user created network (using docker network create command)

Network: none

With the network is none a container will not have access to any external routes. The container will still have a loopback interface enabled in the container but it does not have any routes to external traffic.

Network: bridge

Containers can communicate via their IP addresses by default. To communicate by name, they must be linked.

Network: host

Compared to the default bridge mode, the host mode gives significantly better networking performance since it uses the hostвЂ™s native networking stack whereas the bridge has to go through one level of virtualization through the docker daemon. It is recommended to run containers in this mode when their networking performance is critical, for example, a production Load Balancer or a High Performance Web Server.

—network=»host» gives the container full access to local system services such as D-bus and is therefore considered insecure.

Network: container

Example running a Redis container with Redis binding to localhost then running the redis-cli command and connecting to the Redis server over the localhost interface.

User-defined network

You can create a network using a Docker network driver or an external network driver plugin. You can connect multiple containers to the same network. Once connected to a user-defined network, the containers can communicate easily using only another containerвЂ™s IP address or name.

For overlay networks or custom plugins that support multi-host connectivity, containers connected to the same multi-host network but launched from different Engines can also communicate in this way.

The following example creates a network using the built-in bridge network driver and running a container in the created network

Managing /etc/hosts

If a container is connected to the default bridge network and linked with other containers, then the containerвЂ™s /etc/hosts file is updated with the linked containerвЂ™s name.

Since Docker may live update the containerвЂ™s /etc/hosts file, there may be situations when processes inside the container can end up reading an empty or incomplete /etc/hosts file. In most cases, retrying the read again should fix the problem.

Restart policies (—restart)

Docker supports the following restart policies:

Policy	Result
no	Do not automatically restart the container when it exits. This is the default.
on-failure[:max-retries]	Restart only if the container exits with a non-zero exit status. Optionally, limit the number of restart retries the Docker daemon attempts.
always	Always restart the container regardless of the exit status. When you specify always, the Docker daemon will try to restart the container indefinitely. The container will also always start on daemon startup, regardless of the current state of the container.
unless-stopped	Always restart the container regardless of the exit status, including on daemon startup, except if the container was put into a stopped state before the Docker daemon was stopped.

If a container is successfully restarted (the container is started and runs for at least 10 seconds), the delay is reset to its default value of 100 ms.

Or, to get the last time the container was (re)started;

Examples

This will run the redis container with a restart policy of always so that if the container exits, Docker will restart it.

This will run the redis container with a restart policy of on-failure and a maximum restart count of 10. If the redis container exits with a non-zero exit status more than 10 times in a row Docker will abort trying to restart the container. Providing a maximum restart limit is only valid for the on-failure policy.

Exit Status

The exit code from docker run gives information about why the container failed to run or why it exited. When docker run exits with a non-zero code, the exit codes follow the chroot standard, see below:

125 if the error is with Docker daemon itself

126 if the contained command cannot be invoked

127 if the contained command cannot be found

Exit code of contained command otherwise

Clean up (—rm)

Security configuration

Option	Description
—security-opt=»label=user:USER»	Set the label user for the container
—security-opt=»label=role:ROLE»	Set the label role for the container
—security-opt=»label=type:TYPE»	Set the label type for the container
—security-opt=»label=level:LEVEL»	Set the label level for the container
—security-opt=»label=disable»	Turn off label confinement for the container
—security-opt=»apparmor=PROFILE»	Set the apparmor profile to be applied to the container
—security-opt=»no-new-privileges:true»	Disable container processes from gaining new privileges
—security-opt=»seccomp=unconfined»	Turn off seccomp confinement for the container
—security-opt=»seccomp=profile.json»	White-listed syscalls seccomp Json file to be used as a seccomp filter

Automatic translation of MLS labels is not currently supported.

If you want a tighter security policy on the processes within a container, you can specify an alternate type for the container. You could run a container that is only allowed to listen on Apache ports by executing the following command:

You would have to write policy defining a svirt_apache_t type.

If you want to prevent your container processes from gaining additional privileges, you can execute the following command:

This means that commands that raise privileges such as su or sudo will no longer work. It also causes any seccomp filters to be applied later, after privileges have been dropped which may mean you can have a more restrictive set of filters. For more details, see the kernel documentation.

Specify an init process

The default init process used is the first docker-init executable found in the system path of the Docker daemon process. This docker-init binary, included in the default installation, is backed by tini.

Specify custom cgroups

Runtime constraints on resources

The operator can also adjust the performance parameters of the container:

User memory constraints

We have four ways to set user memory usage:

Always set the memory reservation value below the hard limit, otherwise the hard limit takes precedence. A reservation of 0 is the same as setting no reservation. By default (without reservation set), memory reservation is the same as the hard memory limit.

Memory reservation is a soft-limit feature and does not guarantee the limit wonвЂ™t be exceeded. Instead, the feature attempts to ensure that, when memory is heavily contended for, memory is allocated based on the reservation hints/setup.

Under this configuration, when the container consumes memory more than 200M and less than 500M, the next system memory reclaim attempts to shrink container memory below 200M.

The following example set memory reservation to 1G without a hard memory limit.

The container can use as much memory as it needs. The memory reservation setting ensures the container doesnвЂ™t consume too much memory for long time, because every memory reclaim shrinks the containerвЂ™s consumption to the reservation.

The following example limits the memory to 100M and disables the OOM killer for this container:

The following example, illustrates a dangerous way to use the flag:

Kernel memory constraints

Kernel memory is fundamentally different than user memory as kernel memory canвЂ™t be swapped out. The inability to swap makes it possible for the container to block system services by consuming too much kernel memory. Kernel memory includesпјљ

You can setup kernel memory limit to constrain these kinds of memory. For example, every process consumes some stack pages. By limiting kernel memory, you can prevent new processes from being created when the kernel memory usage is too high.

Kernel memory is never completely independent of user memory. Instead, you limit kernel memory in the context of the user memory limit. Assume вЂњUвЂќ is the user memory limit and вЂњKвЂќ the kernel limit. There are three possible ways to set limits:

We set memory and kernel memory, so the processes in the container can use 500M memory in total, in this 500M memory, it can be 50M kernel memory tops.

We set kernel memory without -m, so the processes in the container can use as much memory as they want, but they can only use 50M kernel memory.

Swappiness constraint

For example, you can set:

CPU share constraint

By default, all containers get the same proportion of CPU cycles. This proportion can be modified by changing the containerвЂ™s CPU share weighting relative to the weighting of all other running containers.

The proportion will only apply when CPU-intensive processes are running. When tasks in one container are idle, other containers can use the left-over CPU time. The actual amount of CPU time will vary depending on the number of containers running on the system.

For example, consider three containers, one has a cpu-share of 1024 and two others have a cpu-share setting of 512. When processes in all three containers attempt to use 100% of CPU, the first container would receive 50% of the total CPU time. If you add a fourth container with a cpu-share of 1024, the first container only gets 33% of the CPU. The remaining containers receive 16.5%, 16.5% and 33% of the CPU.

On a multi-core system, the shares of CPU time are distributed over all CPU cores. Even if a container is limited to less than 100% of CPU time, it can use 100% of each individual CPU core.

CPU period constraint

If there is 1 CPU, this means the container can get 50% CPU worth of run-time every 50ms.

Cpuset constraint

We can set cpus in which to allow execution for containers.

This means processes in container can be executed on cpu 1 and cpu 3.

This means processes in container can be executed on cpu 0, cpu 1 and cpu 2.

We can set mems in which to allow execution for containers. Only effective on NUMA systems.

This example restricts the processes in the container to only use memory from memory nodes 1 and 3.

This example restricts the processes in the container to only use memory from memory nodes 0, 1 and 2.

CPU quota constraint

Block IO bandwidth (Blkio) constraint

The blkio weight setting is only available for direct IO. Buffered IO is not currently supported.

If you do block IO in the two containers at the same time, by, for example:

YouвЂ™ll find that the proportion of time is the same as the proportion of blkio weights of the two containers.

Additional groups

By default, the docker container process runs with the supplementary groups looked up for the specified user. If one wants to add more to that list of groups, then one can use this flag:

Runtime privilege and Linux capabilities

By default, Docker containers are вЂњunprivilegedвЂќ and cannot, for example, run a Docker daemon inside a Docker container. This is because by default a container is not allowed to access any devices, but a вЂњprivilegedвЂќ container is given access to all devices (see the documentation on cgroups devices).

Capability Key	Capability Description
AUDIT_WRITE	Write records to kernel auditing log.
CHOWN	Make arbitrary changes to file UIDs and GIDs (see chown(2)).
DAC_OVERRIDE	Bypass file read, write, and execute permission checks.
FOWNER	Bypass permission checks on operations that normally require the file system UID of the process to match the UID of the file.
FSETID	DonвЂ™t clear set-user-ID and set-group-ID permission bits when a file is modified.
KILL	Bypass permission checks for sending signals.
MKNOD	Create special files using mknod(2).
NET_BIND_SERVICE	Bind a socket to internet domain privileged ports (port numbers less than 1024).
NET_RAW	Use RAW and PACKET sockets.
SETFCAP	Set file capabilities.
SETGID	Make arbitrary manipulations of process GIDs and supplementary GID list.
SETPCAP	Modify process capabilities.
SETUID	Make arbitrary manipulations of process UIDs.
SYS_CHROOT	Use chroot(2), change root directory.

The next table shows the capabilities which are not granted by default and may be added.

Capability Key	Capability Description
AUDIT_CONTROL	Enable and disable kernel auditing; change auditing filter rules; retrieve auditing status and filtering rules.
AUDIT_READ	Allow reading the audit log via multicast netlink socket.
BLOCK_SUSPEND	Allow preventing system suspends.
BPF	Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more.
CHECKPOINT_RESTORE	Allow checkpoint/restore related operations. Introduced in kernel 5.9.
DAC_READ_SEARCH	Bypass file read permission checks and directory read and execute permission checks.
IPC_LOCK	Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2)).
IPC_OWNER	Bypass permission checks for operations on System V IPC objects.
LEASE	Establish leases on arbitrary files (see fcntl(2)).
LINUX_IMMUTABLE	Set the FS_APPEND_FL and FS_IMMUTABLE_FL i-node flags.
MAC_ADMIN	Allow MAC configuration or state changes. Implemented for the Smack LSM.
MAC_OVERRIDE	Override Mandatory Access Control (MAC). Implemented for the Smack Linux Security Module (LSM).
NET_ADMIN	Perform various network-related operations.
NET_BROADCAST	Make socket broadcasts, and listen to multicasts.
PERFMON	Allow system performance and observability privileged operations using perf_events, i915_perf and other kernel subsystems
SYS_ADMIN	Perform a range of system administration operations.
SYS_BOOT	Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution.
SYS_MODULE	Load and unload kernel modules.
SYS_NICE	Raise process nice value (nice(2), setpriority(2)) and change the nice value for arbitrary processes.
SYS_PACCT	Use acct(2), switch process accounting on or off.
SYS_PTRACE	Trace arbitrary processes using ptrace(2).
SYS_RAWIO	Perform I/O port operations (iopl(2) and ioperm(2)).
SYS_RESOURCE	Override resource Limits.
SYS_TIME	Set system clock (settimeofday(2), stime(2), adjtimex(2)); set real-time (hardware) clock.
SYS_TTY_CONFIG	Use vhangup(2); employ various privileged ioctl(2) operations on virtual terminals.
SYSLOG	Perform privileged syslog(2) operations.
WAKE_ALARM	Trigger something that will wake up the system.

The default seccomp profile will adjust to the selected capabilities, in order to allow use of facilities allowed by the capabilities, so you should not have to adjust this.

Logging drivers (—log-driver)

The docker logs command is available only for the json-file and journald logging drivers. For detailed information on working with logging drivers, see Configure logging drivers.

Overriding Dockerfile image defaults

When a developer builds an image from a Dockerfile or when she commits it, the developer can set a number of default parameters that take effect when the image starts up as a container.

CMD (default command or options)

Recall the optional COMMAND in the Docker commandline:

ENTRYPOINT (default command to execute at runtime)

or two examples of how to pass more parameters to that ENTRYPOINT:

You can reset a containers entrypoint by passing an empty string, for example:

EXPOSE (incoming ports)

The following run command options work with container networking:

ENV (environment variables)

Docker automatically sets some environment variables when creating a Linux container. Docker does not set any environment variables when creating a Windows container.

The following environment variables are set for Linux containers:

Variable	Value
HOME	Set based on the value of USER
HOSTNAME	The hostname associated with the container
PATH	Includes popular directories, such as /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM	xterm if the container is allocated a pseudo-TTY

Источник