Аннотация

В статье рассматриваются базовые отличия системы изоляции приложений docker и системы виртуализации (см. Виртуализация QEMU/KVM в Astra Linux), и вытекающие из этих отличий ограничения применения, разъясняется базовая терминология, применяемая к объектам docker.

Ограничения применения

Якорь
термины термины

Термины

Виртуализация — технология, позволяющая запускать экземпляры операционных систем (гостевые машины) параллельно и изолированно на единственной хост-машине. При этом каждой гостевой операционной системе предоставляется полноценная виртуальная машина, имеющая собственные виртуальные аппаратные ресурсы, и гостевая операционная система использует собственное ядро. При этом гостевая виртуальная машина может отличаться по архитектуре от хост-машины, а гостевая операционная система может быть полностью отличной от операционной системы хост-машины. Виртуализация обеспечивает полное моделирование используемого оборудования полностью индивидуальное для каждой гостевой ОС. Гостевые ОС полностью изолированы друг от друга, и каждая гостевая ОС работает в собственной виртуальной программно-аппаратной среде, полностью копирующей реальное оборудование и содержащей полную копию всех необходимых ресурсов;

Изоляция приложений (контейнерная изоляция) — технология, позволяющая выполнять экземпляры приложений (групп приложений) в изолированной среде внутри операционной системы хост-машины. Традиционно контейнерная изоляция приложений обозначается термином "контейнерная виртуализация", хотя в самом деле полноценной виртуализацией не является. Из-за этого "контейнер" иногда рассматривают в качестве аналога "виртуальной машины", хотя он ей не является. Контейнерная изоляция - технология, обеспечивающая совместное использование ресурсов операционной системы хост-машины гостевыми приложениями. Экземпляры приложений, выполняющихся в контейнерах, изолированы друг от друга и (насколько это возможно) от хостовой операционной системы, но при этом аппаратные и программные ресурсы хостовой ОС используются ими совместно;

Гипервизор — программное обеспечение, позволяющее запускать множественные гостевые (виртуальные) машины или контейнеры на единственной физической машине (хост-машине), обеспечивающее  предоставление ресурсов виртуальным машинам и обеспечивающее ограничение и разграничение прав доступа;

Гостевая машина — виртуальная машина, запускаемая в изолированной среде системы виртуализации внутри хостовой операционной системы;

Гостевая операционная система — операционная система, работающая на гостевой машине. Термин "гостевая операционная система" неприменим к контейнерам, так как контейнеры не предоставляют полноценную операционную систему, а в разной мере используют хостовую операционную систему;

Контейнер (container) — изолированная среда выполнения приложений (групп приложений), работающая в хостовой операционной системе;

Образ (image) — набор данных (файлов, инструкций) для создания контейнеров. Может рассматриваться как моментальный снимок состояния виртуальной машины, с которого начинается её работа;

Хостовая операционная система, хостовая ОС - операционная система хост-машины;

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

Графическое сравнение технологий виртуализации и контейнерной изоляции на примере QEMU/KVM (виртуализация) и docker (изоляция) приведено на рисунке:

Системы виртуализации и контейнерной изоляции в Astra Linux

В составе Astra Linux поддерживаются следующие системы виртуализации и контейнерной изоляции:

• QEMU/KVM - полноценная система виртуализации. См. Виртуализация QEMU/KVM в Astra Linux;
• lxc - система контейнерной изоляции, ориентированная на работу с приложениями - операционными системами  (см. Система контейнерной изоляции уровня ОС LXC);
• docker - система контейнерной изоляции, ориентированная на работу с приложениями  - системными службами (рассматривается далее в настоящей статье);
• firejail - система контейнерной изоляции пользовательского уровня, ориентированная на работу с пользовательскими приложениями (см. Система изоляции пользовательских приложений FireJail).

Система контейнерной виртуализации Docker

Назначение

Традиционный способ развертывания подобных приложений без использования Docker предполагает следующие шаги:

• передача администратору целевой ОС инструкций по установке и комплекта неких файлов приложения, как правило, в форме debian-пакета, содержащего:
  • исполнимые файлы;
  • конфигурационные файлы;
  • сценарии установки и удаления.
• выполнение администратором целевой ОС предоставленных инструкций на целевой машине с целью развёртывания устанавливаемого приложения.

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

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

Помимо этого Docker может применяться для изоляции пользовательских приложений, хотя в первую очередь для это предназначен firejail (см. Система изоляции пользовательских приложений FireJail).

Рекомендованный сценарий применения Docker

Рекомендованный сценарий применения Docker учитывает основное назначение Docker: быстрое развертывание приложений. Порядок действий

1. Создать (загрузить) исходный образ;
2. Создать из этого образа контейнер, работая в котором выполнить и сохранить дополнительные настройки, то есть настройки запуска нужного приложения в ограниченной среде Docker;
3. Конвертировать контейнер с выполненными настройками в новый образ;
4. Скопировать новый образ на целевые машины для использования;
5. На целевых машинах дальнейшее использование зависит от поставленных задач:
   1. Можно использовать контейнеры, сохраняющие возникающие при эксплуатации изменения в этих контейнерах;
   2. Можно использовать образ, монтируя к нему внешние каталоги, в которых сохраняются изменения, не сохраняя изменения в контейнерах;
   3. Можно комбинировать указанные варианты;
6. В любом из выбранных вариантов использования далее установленное приложение эксплуатируется на целевой машине в контейнере.

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

Главное преимущество контейнеров в том, что по сравнению с системами виртуализации запуск контейнеров требует значительно меньших вычислительных ресурсов, чем запуск полноценной виртуальной машины.

Кроме этого, Docker для экономии ресурсов поддерживает систему повторного использования "слоев". "Слой" в терминологии Docker - это некий моментальный снимок состояния системы, а "образ" - это итоговое состояние системы, полученное из базовой системы наложением (применением) всех слоев. При этом "слои" могут использоваться повторно разными "образами":

Дополнительным эффектом от повторного использования "слоев" является снижение объемов передаваемых данных при передаче подготовленных в виде образов прикладных программ: при использовании реестра образов Docker передаваться будет только новые слои, в примере выше - слой "Базовая система Astra Linux SE" будет загружен из реестра образов только один раз, далее загружаться будут только новые слои.

Термины Docker

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

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

Образ - основа контейнеров. Контейнер не имеет состояний и не изменяется. Контейнер состоит из:

1. Базовой файловой системы;
2. Упорядоченного набора изменений ("слоев") в этой файловой системе;
3. Базовых параметров исполнения, применяемых при запуске контейнеров. 

Контейнер - образ, находящийся в работе, то есть образ с новым изменяющимся слоем. При работе контейнера все изменения сохраняются в новом слое, а образ (т.е. все предыдущие слои) остаётся неизменным;

Контекст - набор файлов в указанной локации;

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

См. далее:

Установка и администрирование Docker в Astra Linux 1.7

Создание собственного образа Astra Linux для использования в Docker

Термины

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

Гипервизор - программное обеспечение, позволяющее запускать множественные гостевые (виртуальные) машины на единственной физической машине (хост-машине), а также обеспечивающее  предоставление ресурсов виртуальным машинам;

Гостевая машина - виртуальная машина, запускаемая в изолированной среде системы виртуализации внутри хост-машины;

Гостевая операционная система - операционная система, работающая на гостевой машине;

Хост-машина - машина, в операционной системе которой запущена система виртуализации, под управлением которой работают гостевые машины.

Типы виртуализации в ОС СН

Программное обеспечение входящее в состав ОС СН поддерживает два типа виртуализации:

Системы виртуализации  в ОС СН

В состав ОС СН входят две системы виртуализации, поддерживающие два описанных выше типа виртуализации:

• libvirt - система полной виртуализации;
• docker - система контейнерной виртуализации.

Система контейнерной виртуализации Docker

Термины

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

Контейнер - образ, находящийся в работе, то есть образ с новым изменяющимся слоем. При работе контейнера все изменения сохраняются в новом слое, а образ (т.е. все предыдущие слои) остаётся неизменным;

Образ - основа контейнеров. Представляет собой 1) базовую файловую систему, 2) упорядоченный набор изменений ("слоёв") в этой файловой системе и 3) базовые параметры исполнения, применяемые при запуске контейнеров. Не имеет состояний и не изменяется;

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

Реестр образов - сетевое хранилище подготовленных образов, доступных для загрузки на целевые машины.

Особенности

Система контейнерной виртуализации Docker позиционируется не только как система виртуализации, но как система быстрого распространения и развёртывания приложений.

Традиционный способ развёртывания приложений предполагает:

• передачу пользователю приложения комплекта неких файлов приложения как правило:
  • исполнимый файл;
  • конфигурационный файл;
  • сценарии установки и удаления;
  • инструкции по установке;
• выполнение пользователем для развёртывания предоставленных сценариев и инструкций на целевой машине.

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

Docker предлагает альтернативный вариант развёртывания приложений: поставщик приложений передаёт пользователям приложений предварительно настроенные контейнеры с приложениями. Эти контейнеры просто запускаются пользователем на целевой машине, предоставляя каждому приложению изолированное преварительно настроенное окружение для работы. Таким образом исключается существенная часть ошибок, связанных с предварительной настройкой нестандартных пользовательских систем. Хорошим примером использования возможностей Docker по быстрому развёртыванию приложений является пример развёртывания собственного реестра образов, выполняемого путём простого скачивания подготовленного образа (см. раздел "Администрирование" - "Создание собственного реестра образов").

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

Дополнительным эффектом от повторного использования "слоёв" является снижение объёмов передаваемых данных при передаче подготовленных в виде образов прикладных программ: при использовании реестра образов Docker передаваться будет только новые слои, в примере выше - слой "Базовая система Astra Linux SE" будет загружен из реестра образов только один раз, далее загружаться будут только новые слои.

Ограничения Docker

Администрирование Docker

Установка Docker

Установка Docker для работы в привилегированном режиме (не рекомендуется)

В ОС СН Смоленск 1.7 Docker представлен пакетом docker.io и может быть установлен с помощью графического менеджера пакетов или из командной строки командой:

Установка выполняется от имени пользователя, являющегося администратором системы, и после установки Docker рекомендуется предоставить этому пользователю право работать с контейнерами не используя sudo. Для этого пользователя нужно включить в группу docker:

Изменение вступит в силу после перезапуска пользовательской сессии.

Для более ранних версий Astra Linux см. статью: Установка и настройка Docker в ОС Astra Linux

Установка, включение и применение Docker для работы в непривилегированном (rootless) режиме (рекомендованый режим)

Для использования Docker в rootless режиме следует установить пакет rootless-helper-astra:

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

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

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

От команд, описанных в Создание собственного образа для использования в Docker, приведённая выше команда отличается только использованием rootlessenv для выполнения команды docker import.  При этом стандартная команда 

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

запустит пользовательский образ. Далее примеры команд приводятся от имени sudo, для работы в rootless режиме sudo может быть везде земенено на rootlessenv.

Создание собственного реестра образов

Загрузить подготовленный образ Docker, содержащий приложение "Реестр образов Docker". Образ "Реестр образов Docker" загружается из реестра образов Docker:

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

Удаление реестра:

Создание и модификация собственных образов

Создание простого образа из chroot-окружения

Простой пример создания собственного образа см. в статье Создание собственного образа для использования в Docker

Модификация образа с помощью докерфайла

Подробное описание структуры и работы с докерфайлами доступно в справочной системе man:

Докер может создавать образы автоматически, получая инструкции из докерфайла. Докерфайл представляет собой текстовый файл содержащий все инструкции которые понадобилось бы выполнить пользователю создавая образ. Используя команду docker build пользователи могут использовать для создания образов автоматические сценарии, содержащие множество команд. Команда docker build создаёт образ из докерфайла и контекста. Контекст представляет набор файлов в указанной локации. Локация контекста может быть задана как путь (PATH) в файловой системе или как ссылка (URL) на сетевой репозиторий Git. По умолчанию используется докерфайл с именем Dockerfile, расположенный в корне контекста.

Команда docker build выполняется службой (демоном) dockerd, при этом полное содержимое контекста рекурсивно пересылается службе dockerd и может по мере надобности копироваться в создаваемый образ. Копирование выполняется командами, указанными в докерфайле.

в первой инструкции команда pwd будет выполнена в каталоге /home, во второй инструкции команда pwd будет выполнена в рабочем каталоге, заданном по умолчанию.

Далее приведён пример сборки образа с помощью команды docker build. Сборка выполняется на основе ранее созданного образа wiki/astralinux:orel (см. Создание собственного образа для использования в Docker). Порядок действий:

Создать каталог контекста сборки и файлы этом каталоге:

В файл build-orel/Dockerfile внести следующие данные:

# указание из какого образа выполнять сборку
FROM wiki/astralinux:orel
# скопировать файл data-to-import из контекста сборки в образ
COPY /data-to-import /srv
# создать в образе пустой файл /srv/created-file
RUN touch /srv/created-file
# вывести на печать содержимое скопированного файла 
RUN cat /srv/data-to-import
# вывести на печать рабочий каталог
RUN echo Current work directory is $(pwd)

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

Убедиться, что образ test появился в списке образов:

Запустить контейнер из образа и проверить содержимое:

Управление Docker-ом

Подробная справка по командному интерфейсу Docker представлена на сайте разработчиков: https://docs.docker.com/engine/reference/commandline/docker/. При работе в системе список команд можно получить с помощью команды:

Более подробную справку по аргументам команд можно получить с помощью ключа --help, или с помощью справочной системы man, например:

Часто употребимые команды (аргументы команд для краткости не указаны):

docker attach

Управление контейнерами:

Управление образами:

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

Загрузка образа в реестр

Получить список доступных на локальной машине образов:

Пометить загружаемый образ тегом (tag) для загрузки в нужный реестр:

Перепроверить список доступных образов, чтобы убедиться, что тег присвоен верно:

В примере выше первые две строки сообщают об одном и том же образе (идентификатор образа 5d69ce8720a7). При этом образ помечен как размещённый в двух локациях - на локальной машине wiki/astralinux и сетевом реестре на локальной машине localhost:5000.

Загрузить образ в реестр:

Использование Docker

Получение образа из реестра

Пример получения образа Docker из реестра описан выше (см. "Создание собственного реестра образов"). При этом для получения образа используется просто команда запуска контейнера (docker run), которая, не найдя на локальной машине указанный образ, ищет образ в реестре образов, и, если образ найден, автоматически загружает и запускает его.

Образ также можно просто загрузить из реестра с помощью команды docker pull, например:

Копирование образа без использования реестра

Образ, хранящийся на локальной машине может быть скопирован (например, на другую (целевую) машину) без использования реестра образов. Далее для примера используется стандартный образ hello-world из реестра образов Docker. Перенос образа на другую машину:

Или, как вариант, выполнить все указанные выше шаги одной командой, скопировав создаваемый файл через SSH (естественно, на целевом компьютере для этого должен быть настроен SSH):

Где:

• docker save hello-world - команда выгрузки образа с именем hello-world. В отличие от примера выше команда используется без указания файла, то есть выводит в стандартный вывод (stdout);
• bzip2 - программа сжатия данных (архиватор);
• ssh user@host 'bunzip2 | docker load' - подключение через SSH к компьютеру с именем host от имени пользователя user и запуск команды загрузки образа из стандартного ввода (stdin). Пользователь user на целевом компьютере должен иметь право работать с Docker без использования sudo.

Создание контейнеров из образов и основы работы с контейнерами

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

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

Исходное состояние: в локальном репозитори имеются образы hello-world и busybox:

И нет ни одного контейнера:

Создание нового контейнера из образа busybox и его запуск выполняется одной командой:

Где:

• --name run-busybox - присвоить создаваемому контейнеры имя run-busybox. Имя можно не указывать, тогда оно будет создано автоматически.
• --rm - уничтожить контейнер после завершения его работы;
• -i - запустить контейнер в интерактивном режиме;
• -t - создать терминал;
• /# - приглашение интерактивного режима запущенного контейнера и ожидание ввода.

Проверим из отдельной терминальной сессии список контейнеров:

В списке появился новый контейнер с именем run-busibox.

Вернёмся в первую терминальную сессию, и выйдем из интерактивного контейнера командой exit. Повторная проверка командой docker container ls -a покажет, что список контейнеров пуст (опция --rm указывает удалить контейнер после завершения работы).

Повторно запустим контейнер, уже без опции --rm, и, для примера, не задавая имя контейнера:

Снова проверим список контейнеров из отдельной сессии:

В списке появился новый контейнер с автоматически созданным именем amazing_morse.
Снова вернёмся в первую терминальную сессию, и выйдем из интерактивного контейнера командой exit. Повторная проверка покажет, что теперь в списке контейнеров сохранился контейнер:

Повторно выполним команду docker run:

И из отдельной терминальной сессии увидим, что контейнеров теперь стало 2: 1) ранее созданный amazing_morse (неактивный) и 2) новый admiring_murdock (активный):

То есть:

Для запуска созданного и сохранённого контейнера используется команда docker start (обратите внимание, используется не образ, а контейнер):

опции -ai задают подключение в интерактивном режиме, но контейнер можно можно запустить и в фоновом режиме:

К контейнеру работающему в фоновом режиме можно подключиться командой docker attach:

Отключиться от конейнера, не останавливая его, можно нажав последовательно клавиши Ctrl+p Ctrl+q, можно также остановить контейнер, введя команду exit.

Выше описано, как работать с контейнерами, в том числе сохраняя сделанные изменения. То есть, первоначальный образ можно "изменить" (естественно, не сам образ, который неизменен, изменения регистрируются в контейнере), и далее контейнер можно преобразовать в образ с помощью команды docker container commit:

Проверим список образов:

Монтирование файловых ресурсов хост-машины

Docker поддерживает следующие варианты монтирования файловых ресурсов хост-машины:

bind - монтирование файла или каталога хост-машины в контейнер. Примонтированный ресурс доступен по его абсолютному пути на хост машине.

Опции монтирования задаются при создании контейнеров из образов, и сохраняются в параемтрах контейнера. Опции монтирования могут задаваться в двух альтернативных форматах: "формат -v" и "формат --mount". Значение "формат -v" состоит их трех фиксированных полей, разделённых символами двоеточия: ресурс монтирования, точка монтирования, опции монтирования. Значение "формат --mount" состоит из списка пар вида "опция=значение", разделённых запятыми, см. примеры далее. Опции монтирования в варианте bind фактически отличается от опция монтирования в варианте mount названием монтируемого ресурса: в первом случае это путь к файловому объекту, во втором - имя заранее созданного тома монтирования. Если точка монтирования внутри контейнера не существует то она создаётся автоматически, причём всегда в виде каталога.

Опции монтировниния "формат --mount":

Запуск контейнера с bind-монтированием текущего каталога на хост-машине в каталог /app контейнера:

Создание тома с именем my-vol для последующего монтирования:

Запуск контейнера с mount-монтированием тома my-vol на хост-машине в каталог /app контейнера:

Запуск контейнера с tmpfs-монтированием:

Рекомендации по контролю безопасности контейнеров

По материалам: https://www.stackrox.com/post/2017/08/hardening-docker-containers-and-hosts-against-vulnerabilities-a-security-toolkit/

При запуске контейнеров, требующих доступ к ним через сеть, используются параметры запуска, указывающие сетевые порты, через которые разрешен доступ (опция -p команды doсker run), например:

В примере приведён вывод команды для единственного ранее запущенного контейнера  registry:2, доступ к которому разрешен через порт 5000.

В Astra Linux возможно монтирование файловых ресурсов в режимах "разделяемый" (shared), "подчинённый" (slave) или "частный" (private). При монтировании в режиме "разделяемый" изменения, сделанные через любую точку монтирования распространяются на все точки монтирования, что может привести нарушению работы контейнеров из-за нежелательных изменений файловых объектов другими контейнерами.
Следует избегать монтирования с опцией ":shared", т.е команд запуска контейнеров вида:

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

Возможный сценарий применения Docker

Таким образом, возможный сценарий применения Docker: