Docker - где находятся тома докеров?

Подготовка собственного образа

Создание и публикация собственного образа не сложнее его использования. Весь процесс делится на три шага:

Создается файл в корне проекта. Внутри описывается процесс создания образа.
Выполняется сборка образа командой
Выполняется публикация образа в Registry командой

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

То есть достаточно запустить контейнер из этого образа, подключив каталог с файлами js для проверки как Volume во внутреннюю директорию /app.

1. Конечная структура директории, на основе файлов которой соберется образ, выглядит так:

Файл eslintrc.yml содержит конфигурацию линтера. Он автоматически прочитывается, если лежит в домашней директории под именем .eslintrc.yml. То есть этот файл должен попасть под таким именем в директорию /root внутрь образа.

2. Создание Dockerfile

Dockerfile имеет довольно простой формат. На каждой строчке указывается инструкция (директива) и её описание.

FROM

Инструкция FROM нужна для указания образа, от которого происходит наследование. Здесь необходимо оговориться, что образы строятся на базе друг друга и все вместе образуют большое дерево.

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

RUN

Основная инструкция в Dockerfile. Фактически здесь указывается sh команда, которая будет выполнена в рамках окружения, указанного во FROM при сборке образа. Так как по умолчанию всё выполняется от пользователя root, то использовать sudo не нужно (и скорее всего его нет в базовом образе). К тому же учтите, что сборка образа — процесс не интерактивный. В тех ситуациях, когда вы используете команду, которая может запросить что-то от пользователя, необходимо подавлять этот вывод. Например, в случае пакетных менеджеров делают так: . Флаг как раз говорит о том что нужно производиться установку без дополнительных вопросов.

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

COPY

В соответствии со своим названием команда COPY берет файл или директорию из основной файловой системы и копирует её внутрь образа. У команды есть ограничение. То, что копируется, должно лежать в той же директории, где и Dockerfile. Именно эту команду используют при разработке когда необходимо упаковать приложение внутрь образа.

WORKDIR

Инструкция, устанавливающая рабочую директорию. Все последующие инструкции будут считать, что они выполняются именно внутри неё. По инструкция действует, как команда . Кроме того, когда мы запускаем контейнер, то он также стартует из рабочей директории. Например, запустив bash, вы окажетесь внутри неё.

CMD

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

3. Сборка

Для сборки образа используется команда . С помощью флага передается имя образа, включая имя аккаунта и тег. Как обычно, если не указывать тег, то подставляется latest.

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

Зарегистрироваться на Docker Cloud и создать там репозиторий для образа.
Залогиниться в cli интерфейсе используя команду .

Linux vs Windows

Где работает эта магия?

Родной операционной системой для docker является OS Linux, но время не стоит на месте и в текущий момент есть возможность запускать контейнеры и на операционной системе Windows/ Причем, появились и контейнеры на базе операционной системы Windows

В настоящее время в Windows реализована функция WSL2 – поддержка Windows Subsystem for Linux. Она поддерживается с версии сборки 19041 и позволяет полноценно работать с Linux-оболочкой в ОС Windows.

Если вы хотите попробовать поработать с Docker на Windows, есть два варианта:

поставить виртуальную машину с Linux на Windows и устанавливать Docker в нем;
либо поставить WSL2 и разобраться, как в ней работать с Docker. В WSL2 решено большое количество проблем, она работает более стабильно. Если вы работаете в VS Code – там есть классные плагины поддержки WSL прямо внутри среды. Вы можете работать с файловой системой виртуальной машины внутри VS Code.

Рекомендация простая — если работаете на Windows – используйте WSL2.

В продуктивной среде, правильнее работать с Docker на Linux – так как его родная операционная система, и на ней будет минимальное количество проблем.

Еще один момент, который стоит отметить: контейнеры бывают двух вариантов – на базе образов операционных систем Windows и Linux.

В интернете размещено большое количество уже собранных образов и исходников для Linux-контейнеров.

Windows-контейнеры тоже появляются, но там есть свои проблемы:

Windows-контейнеры не содержат графической оболочки, поэтому работа с приложениями, имеющими завязку на GUI, будет вызывать проблемы. Например, при запуске клиента 1С вы не увидите, что происходит внутри контейнера и дополнительная установка, например, VNC проблему не решит.
Windows требует, чтобы версия ОС хоста соответствовала версии ОС контейнера. Если вы хотите запустить контейнер на основе новой сборки Windows, убедитесь, что у вас есть эквивалентная сборка хоста
Требования наличия лицензии на запуск. Вы не можете использовать образ контейнера, если у вас нет лицензии на соответствующую версию ОС

Стоит отметить, что на текущий момент Windows позволяет запускать как линуксовые, так и Windows-контейнеры, но на OS Linux можно запустить только Linux-контейнеры.

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

Docker Swarm

При преобразовании хостов в кластер нужно воспользоваться утилитой кластеризации Docker Swarm. Хост, находящийся в его составе, называется «узлом» (node), который бывает управляющим или рабочим. Один кластер содержит только один управляющий «узел».

Некоторые возможности утилиты

Управление нагрузочными характеристиками — осуществляется оптимизация рассылки запросов между хостами, обеспечивая на них равномерную нагрузку.
Динамическое управление — допускается добавление элементов в swarm-кластер без дальнейшего его перезапуска.
Возможность масштабирования — позволяет добавлять или удалять docker-образ для автоматического создания контейнера.
Восстановление «узла» после сбоя — работоспособность каждого хоста постоянно контролируется управляющим «узлом». При сбое кластера происходит его восстановление и перезапуск.
Rolling-update — выполняет обновление контейнеров. Процедура может выполняться в определенной последовательности и с временной задержкой для запуска другого контейнера. Параметр указывается в настройках. Если произойдет сбой обновления, то Docker Swarm выдаст ошибку и процесс повторится заново.

Общие сведения о контейнерах Docker

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

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

Постоянная доступность, которую обеспечивает использование контейнеров Docker с такими инструментами, как Kubernetes, — еще одна причина популярности контейнеров. Это позволяет создавать несколько версий контейнера приложения в разное время. Вместо того чтобы останавливать всю систему для обновления или обслуживания, каждый контейнер (и определенные микрослужбы) можно заменить на лету. Вы можете подготовить новый контейнер со всеми обновлениями, настроить его для рабочей среды и просто указать новый контейнер после его готовности. Можно также архивировать различные версии вашего приложения, используя контейнеры, и при необходимости поддерживать их работу в качестве резервного ресурса.

Дополнительные сведения см. в разделе Введение в контейнеры DOCKER на Microsoft Learn.

Что такое Docker

Docker (Докер) — программное обеспечение с открытым исходным кодом, применяемое для разработки, тестирования, доставки и запуска веб-приложений в средах с поддержкой контейнеризации. Он нужен для более эффективного использование системы и ресурсов, быстрого развертывания готовых программных продуктов, а также для их масштабирования и переноса в другие среды с гарантированным сохранением стабильной работы.

Разработка Docker была начата в 2008 году, а в 2013 году он был опубликован как свободно распространяемое ПО под лицензией Apache 2.0. В качестве тестового приложения Docker был включен в дистрибутив Red Hat Enterprise Linux 6.5. В 2017 году была выпущена коммерческая версия Docker с расширенными возможностями.

Docker работает в Linux, ядро которых поддерживает cgroups, а также изоляцию пространства имен. Для инсталляции и использования на платформах, отличных от Linux, существуют специальные утилиты Kitematic или Docker Machine.

Основной принцип работы Docker — контейнеризация приложений. Этот тип виртуализации позволяет упаковывать программное обеспечение по изолированным средам — контейнерам. Каждый из этих виртуальных блоков содержит все нужные элементы для работы приложения. Это дает возможность одновременного запуска большого количества контейнеров на одном хосте.

Docker-контейнеры работают в разных средах: локальном центре обработки информации, облаке, персональных компьютерах и т. д.

Другие Типы Монтирования

Есть два других типа томов Docker, которые мы еще не обсуждали: bind mount и tempfs mount.

Bind Mount

Bind mount используются для монтирования существующего пути на хосте в контейнер. Используя —mount совместно с <host path>:<container path>, вы можете указать существующие каталоги, которые будут монтироваться в контейнер. Это очень удобно при использовании информации о конфигурации, такой как каталоги внутри /etc. Это также полезно, когда у вас есть информация, которую вы хотите использовать в контейнере, например, существующие наборы данных или статические файлы веб-сайта.

Tempfs Mount

Задача tempfs монтирования состоит в том, чтобы обеспечить доступное для записи расположение, которое специально не сохраняет информацию после окончания срока службы контейнера. Возможно, вы думаете: «зачем это нужно?” В контейнере, который не имеет подключенного тома, все записи идут в тонкий слой R/W, вставленный во время выполнения. Любая запись, направленная на этот слой, влияет на файловую систему, поскольку эти записи выполняются на базовом хосте. Обычно это не является проблемой, если вы не пишете значительные объемы одноразовых данных (таких как журналы). В этом случае вы можете наблюдать снижение производительности, так как файловая система должна обрабатывать все эти вызовы write. tempfs монтирование было создано для предоставления контейнерам временного пути записи, который не влияет на операции файловой системы. В частности, tempfs это эфемерное монтирование, которое записывается непосредственно в память. Этот том можно создать с помощью —tempfs аргумента.

Драйвера Томов

По умолчанию тома хранят информацию о базовой хост-системе. Docker также имеет концепцию, называемую драйверами томов, которая позволяет указать, как и где хранить тома. Например, вы можете хранить том Docker внутри корзины Amazon S3. Это может быть удобно, если вы хотите, чтобы информация сохранялась не только за пределами срока службы контейнера, но и за пределами срока службы хоста.

Разворачивание контейнера с Jenkins

Это выглядит так – у нас есть файл docker-compose.yml, который поднимает сервис Jenkins.

Traefik просматривает все существующие Docker-контейнеры и ищет лейблы. Если он находит лейбл с указанием traefik.enable=true, он включается и начинает маршрутизировать трафик, который на него идет.

В частности, публикует этот сервис по от указанному URL.

Чтобы запустить Jenkins, мне нужно вызвать команду:

Контейнер с Jenkins запустился и работает, а на сайте ci.demoncat.ru выводится приглашение Jenkins.

Как видите, я развернул Jenkins с нуля за 20 минут – все запустилось одной командой.

Взаимодействие с другими частями системы

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

Interactive mode

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

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

Дело в том, что запускает интерактивную сессию внутри контейнера. Для взаимодействия с ней нужно оставить открытым поток STDIN и запустить TTY (псевдо-терминал). Поэтому для запуска интерактивных сессий нужно не забыть добавить опции и . Как правило их добавляют сразу вместе как . Поэтому правильный способ запуска баша выглядит так: .

Ports

Если запустить nginx такой командой , то nginx не сможет принять ни один запрос, несмотря на то, что внутри контейнера он слушает 80 порт (напомню, что каждый контейнер по умолчанию живет в своей собственной сети). Но если запустить его так , то nginx начнет отвечать на порту 8080.

Флаг позволяет описывать как и какой порт выставить наружу. Формат записи расшифровывается так: пробросить порт 8080 снаружи контейнера в контейнер на порт 80. Причем, по умолчанию, порт 8080 слушается на , то есть на всех доступных интерфейсах. Поэтому запущенный таким образом контейнер доступен не только через , но и снаружи машины (если доступ не запрещен как-нибудь еще). Если нужно выполнить проброс только на loopback, то команда меняется на такую: .

Docker позволяет пробрасывать столько портов, сколько нужно. Например, в случае nginx часто требуется использовать и порт, и для HTTPS. Сделать это можно так: Про остальные способы пробрасывать порты можно прочитать в официальной документации.

Volumes

Другая частая задача связана с доступом к основной файловой системе. Например, при старте nginx-контейнера ему можно указать конфигурацию, лежащую на основной фс. Докер прокинет её во внутреннюю фс, и nginx сможет её читать и использовать.

При работе с Volumes есть несколько важных правил, которые надо знать:

Путь до файла во внешней системе должен быть абсолютным.
Если внутренний путь (то, что идет после ) не существует, то Докер создаст все необходимые директории и файлы. Если существует, то заменит старое тем, что было проброшено.

Кроме пробрасывания части фс снаружи, Докер предоставляет еще несколько вариантов создания и использования Volumes. Подробнее — в официальной документации.

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

Конфигурирование приложения внутри контейнера, как правило, осуществляется с помощью переменных окружения в соответствии с 12factors. Существует два способа их установки:

Флаг . Используется он так:
Специальный файл, содержащий определения переменных окружения, который пробрасывается внутрь контейнера опцией .

Как использовать ресурсы контейнера ¶

По умолчанию контейнер закрыт от любых контактов извне. Вы не можете ни скопировать в него файл, ни подключиться к сокету. Он закрыт. Но при запуске контейнера можно пробросить порт или папку. Тогда к нему можно будет подключиться, добавить файл или что-то скачать. Всё это делается при создании (запуске) контейнера через аргументы.

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

Для примера запустим контейнер с Debian 9 и пробросим локальный порт 3132 на 80 порт контейнера:

Пояснения к команде:

— создаёт и запускает новый контейнер.
— подключает виртуальную консоль. Это нужно, чтобы команда не завершала работу, иначе контейнер остановится.
— запускает выполнение контейнера в фоне. Без этого аргумента консоль будет ждать, когда контейнер остановится (для остановки придётся использовать другую консоль).
— использовать в качестве процесса системную утилиту . Просто потому, что она не завершится пока не закроется stdin, а значит и контейнер будет работать.
— уникальное имя, которое используется для управления контейнером. Если его не указывать, то докер сам придумает какое-нибудь имя.
— проброс портов. Сначала надо указать порт машины (можно указать вместе с IP), потом порт в контейнере.

Общий принцип запуска контейнеров довольно простой:

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

Теперь давайте рассмотрим, как выполнять команды внутри контейнера. Для примера установим и запустим консольный сервер php 7:

Пояснения к команде:

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

Чтобы проверить, работает сервер или нет, нужно подключиться на 3132 порт основной машины, например так:

В этом примере я использовал две разные консоли. На одной я запускал сервер, а на другой curl. Ещё можно использовать браузер, если докер установлен у вас в системе.

Проброс папки

В предыдущем примере я создал index.php прямо в контейнере. Это не самый удобный способ разработки проектов в через докер. Во-первых, много файлов так не создашь, во-вторых ими сложно управлять, а, в-третьих, если удалить контейнер, они тоже удалятся. Чтобы решить эти проблемы, можно пробросить (примонтировать) папку из реальной машины в виртуальный контейнер. Делается это, как всегда, при создании контейнера, через аргумент .

Прежде, чем начать что-то менять, надо удалить старый контейнер:

Теперь подготовим наш «проект»:

А теперь запускаем контейнер с пробросом папки проекта:

Если вы помните, я удалил контейнер, в котором был установлен php, а это значит, что мне заново придётся установить пакет php7.0-cli:

Теперь в контейнере есть и проект, и php, можно запускать сервер:

Теперь проверяем, как работает наш проект:

Для наглядности давайте создадим ещё один файл в «проекте», чтобы удостовериться, что всё работает как надо:

Должно вывести что-то вроде этого:

Если у вас получилось, смело пишите в резюме, что владеете докером!

Репозиторий для localhost

Для начала мы развернем репозиторий, который сможет обслуживать только локальный сервер (о том, как развернуть сетевое хранилище образов Docker будет ).

Чтобы запустить сервис, который сможет принимать запросы docker push и docker pull, вводим команду:

docker run -d -p 5000:5000 —restart=always —name registry registry:2

* в данном примере мы поднимает контейнер Docker с именем registry из образа registry:2. Он будет слушать сетевые запросы на порту 5000. Параметр —restart=always позволит автоматически запускаться контейнеру после перезагрузки сервера.

Проверяем, что на порту 5000 у нас запустился контейнер docker:

ss -tunlp | grep :5000

Мы должны увидеть что-то на подобие:

tcp LISTEN 0 4096 *:5000 *:* users:((«docker-proxy»,pid=484238,fd=4))

Попробуем проверить работу нашего репозитория. На том же сервере сначала загрузим из облака докер-хаба образ, например, для python:

docker pull python:latest

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

docker tag python:latest localhost:5000/python

* в данном примере мы указываем тег localhost:5000/python, в названии которого мы видим localhost:5000 — локальный сервер, порт 5000.

Загружаем образ питона на наш сервер:

docker push localhost:5000/python

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

docker image remove python:latest

… и образ, который мы загрузили в наш локальный репозиторий:

docker image remove localhost:5000/python

Теперь снова загрузим образ python, но на этот раз из нашего собственного репозитория:

docker pull localhost:5000/python

Мы должны увидеть процесс загрузки:

Using default tag: latest
latest: Pulling from python
8bf9c589d5f9: Pull complete
4c70e46d8b5f: Pull complete
ea848ad42f0d: Pull complete
48fe137f8d26: Pull complete
4b13f6ed9b0c: Extracting 56.82MB/192.3MB
ba85279f50e0: Download complete
59a18d8c3680: Download complete
c610993f70c6: Download complete
a9afc028cd66: Download complete

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

Digest: sha256:1e3b89f69bb6ada672153256bd88d74ae60571f6755703369a108c76595ea00f
Status: Downloaded newer image for localhost:5000/python:latest
localhost:5000/python:latest

Наш репозиторий Docker готов и работает для локального сервера.

Другие Типы Монтирования

Есть два других типа томов Docker, которые мы еще не обсуждали: bind mount и tempfs mount.

Bind Mount

Tempfs Mount

Драйвера Томов

Куда отправляются данные, когда они записываются в контейнер?

Предположим, что мы заходим в оболочку внутри busybox контейнера:

Затем, давайте запишем некоторые данные, скажем, в /tmp:

Мы видим, что данные определенно записываются. Но куда же на самом деле идут эти данные? Как мы узнали ранее, образы Docker состоят из слоев, уложенных друг на друга, чтобы привести к окончательному образу. Каждый из этих слоев содержит данные, измененные в такой операции, как установка инструмента, добавление исходного кода и т.д. Каждый из этих слоев становится доступным только для чтения после его создания. Когда контейнер создается из образа, тонкий R/W слой добавляется поверх предыдущих слоев образа. Этот слой обрабатывает все вызовы записи из контейнера, которые, в противном случае, были бы направлены на слои ниже, доступные только для чтения. Помните, что контейнеры эфемерны по своей природе. Они предназначены для того, чтобы иметь определенную продолжительность жизни и умереть в какой-то момент, как и любой процесс. Тонкий слой чтения/записи также эфемерен — он исчезает вместе с контейнером. Таким образом, любые записи, которые мы выполняем в контейнере, ограничены временем жизни этого контейнера. Они исчезнут, когда контейнер будет уничтожен. Это очевидное ограничение, которое не способствует хранению статусной информации. Итак, как разработчики и администраторы работают с этим? Они используют Тома Docker.

Плюсы и минусы инструмента

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

Преимущества

Начать лучше с преимуществ. Среди них выделяют:

Открытый исходный код. Разработчики делятся друг с другом собственными разработками на специализированных площадках.
Низкий уровень потребления ресурсов. Изолированные пространства не предусматривают виртуализацию всей ОС. Они задействуют исключительно ядро хоста, после чего изолируют нужное приложение на уровне процессов.
Скорость развертывания. Она достаточно быстрая. Можно использовать базовый образ Docker для дальнейшей работы.
Простое скрытие процессов. Контейнеризация – то, что позволяет использовать всевозможные средства и способы обработки информации. Фоновые процессы легко скрываются от «посторонних глаз».
Поддержка работы с небезопасными кодами. Технологии изолирования позволяют запускать совершенно разные машинные коды. За целостность приложений переживать не нужно. Связано это с тем, что за счет Докер контейнера осуществляется изоляция утилиты.
Простое масштабирование. Проекты могут расширяться только за счет того, что пользователь решил устанавливать новые контейнеры.
Простой и удобный запуск. Docker Run предоставляет возможность активации любой утилиты внутри изолированного пространства в пределах одного и того же хоста.

Не нужно забывать о том, что рассматриваемый инструментарий поддерживает оптимизацию файловой системы. Образ состоит из слоев, которые отвечают за оптимальное и эффективное использование ОС и ее файловых компонентов.

Недостатки

Управлять образами и контейнерами при определенной сноровке достаточно легко. Хотя кажется, что соответствующий софт не имеет недостатков, это вовсе не так.

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

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

Установка

Чтобы начать пользоваться Докером, необходимо установить движок — Docker Engine. На странице https://docs.docker.com/engine/install/ доступны ссылки для скачивания под все популярные платформы. Выберите вашу и установите Докер.

В работе Докера есть одна деталь, которую важно знать при установке на Mac и Linux. По умолчанию Докер работает через unix сокет

В целях безопасности сокет закрыт для пользователей, не входящих в группу docker. И хотя установщик добавляет текущего пользователя в эту группу автоматически, Докер сразу не заработает. Дело в том, что если пользователь меняет группу сам себе, то ничего не изменится до тех пор, пока пользователь не перелогинится. Такова особенность работы ядра. Для проверки того, в какие группы входит ваш пользователь, можно набрать команду .

Проверить успешность установки можно командой :

Она выдаёт довольно много информации о конфигурации самого Докера и статистику работы.