Капитан грузового судна, или как начать использовать docker в своих проектах

Загрузка образов

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

# docker login

У вас будут запрошены имя пользователя и пароль, введите их для получения доступа.

Теперь мы можем приступить к работе. Допустим, нам требуется образ Ubuntu. Сначала выполним поиск при помощи команды search:

# docker search ubuntu

Выбрав нужный образ, загрузите его на свою машину при помощи команды pull. В данном примере будет загружен официальный образ Ubuntu:

# docker pull ubuntu

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

# docker images

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

# docker rmi ubuntu

Часть 0.2 Процессы в контейнерах

Контейнер живет, пока живет процесс, вокруг которого рождается контейнер.
Внутри контейнера этот процесс имеет pid=1
Рядом с процессом с pid=1 можно порождать сколько угодно других процессов (в пределах возможностей ОС, естественно), но убив (рестартовав) именно процесс с pid=1, контейнер выходит. (см п.1)
Внутри контейнера вы увидите привычное согласно стандартам FHS расположение директорий. Расположение это идентично исходному дистрибутиву (с которого взят контейнер).
Данные, создаваемые внутри контейнера остаются в контейнере и нигде более не сохраняются (ну, еще к этому слою есть доступ из хостовой ОС). удалив контейнер — потеряете все ваши изменения. Поэтому данные в контейнерах не хранят, а выносят наружу, на хостовую ОС.

Docker Registry

Где хранятся образы.

Если вы собрали образ из исходников сами, он будет храниться у вас на локальной машине. Или образ можно скачать из Docker Registry – это хаб, предназначенный для хранения образов. Они хранятся там в виде слоев, чтобы экономить пространство.

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

Часть 0.2 Процессы в контейнерах

Контейнер живет, пока живет процесс, вокруг которого рождается контейнер.
Внутри контейнера этот процесс имеет pid=1
Рядом с процессом с pid=1 можно порождать сколько угодно других процессов (в пределах возможностей ОС, естественно), но убив (рестартовав) именно процесс с pid=1, контейнер выходит. (см п.1)
Внутри контейнера вы увидите привычное согласно стандартам FHS расположение директорий. Расположение это идентично исходному дистрибутиву (с которого взят контейнер).
Данные, создаваемые внутри контейнера остаются в контейнере и нигде более не сохраняются (ну, еще к этому слою есть доступ из хостовой ОС). удалив контейнер — потеряете все ваши изменения. Поэтому данные в контейнерах не хранят, а выносят наружу, на хостовую ОС.

Сборка Docker-образа для любого проекта на Python (CPU)

Чаще всего системы машинного обучения делают на Python, поэтому важно эффективно создавать любые Docker-образы на основе этого языка

Одноэтапная сборка

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

Пример одноэтапной сборки Docker:

Для демонстрации я использовал эти пакеты:

После запуска команды размер образа был 1,64 Гб:

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

Важно c apt использовать флаг , а с pip — флаг. Нам не надо сохранять кэш, потому что он не нужен ни для среды разработки, ни для эксплуатационной среды

Если вы используете какую-нибудь CI/CD-платформу (вроде Github action) с ограниченным размером хранилища, то она будет работать только при таком методе.

Библиотеки Python из коробки не работают, сначала их нужно скомпилировать на С. Нас интересует лишь скомпилированная часть библиотек, остальное не нужно. При выполнении все библиотеки сначала скачиваются, а затем компилируются.

Нужно удалить все промежуточные и дополнительные компоненты, созданные при установке библиотек. Для этого можно использовать bash-команды. Если сделать неправильно, то будет много неприятностей или даже сломается библиотека. Это довольно сложно, многие стараются этого избежать и пускают в эксплуатацию более громоздкие образы. Но нам на помощь приходит многоэтапная сборка образа (Docker multi-stage builds).

Многоэтапная сборка

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

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

Давайте посмотрим на примере:

При таком способе размер Docker-образа стал 1,61 Гб вместо 1,64. Вроде бы разница невелика, но на самом деле отличий много. Пробежимся по ним.

Строки с 1 по 5 относятся к первому этапу — компилированию, когда мы устанавливаем библиотеки Python: они сначала скачиваются, а затем компилируются на С, поэтому мы даже установили gcc. Затем мы просто копируем скомпилированные библиотеки из первого этапа во второй (runtime) с помощью этой команды:

Но, как видно на скриншоте, размер уменьшился не сильно. С другими языками разница будет огромной, но у Python есть несколько фокусов в запасе:

Сейчас многие библиотеки распространяются в виде предварительно скомпилированных .whl-файлов, это формат wheel из PyPi, поэтому компилировать их не требуется.
То есть многоэтапной сборке негде развернуться в случае с проектами на Python? Совершенно верно! Однако не каждый пакет из PyPi предварительно скомпилирован в .whl, многие поставляются в устаревшем формате tar.gz (сжатые с помощью tarballs), и их нужно сначала скомпилировать. Здесь многоэтапная сборка будет работать по-своему.
Кроме того, многоэтапность применима, если вы собираете Python-пакет из исходника, либо с помощью setup.py используете локальный пакет, поскольку опять же их нужно компилировать.
Настаиваю, чтобы вы прочитали эту статью, в которой объясняется формат wheels в Python.
В файле req.txt, который я использовал для демонстрации, только вышеприведенные пакеты представлены не в формате wheel, а также они очень малы. Но если какой-то пакет не скомпилирован предварительно и занимает много места, то вы потеряете много места на диске.

Уменьшение размеров образов

▍Многоступенчатая сборка образов

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

документации

здесьздесь

▍Файл .dockerignore

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

Предварительные требования

Убедитесь, что на компьютере установлена ОС Windows 10, обновлена до версии 2004, Сборка 18362 или более поздняя версия.
Включите WSL, установите дистрибутив Linux и обновите его до версии WSL 2.
.
Установите Visual Studio Code (необязательно). Это обеспечит лучшие возможности, включая возможность кодирования и отладки в удаленном контейнере DOCKER и подключения к дистрибутиву Linux.
Установите терминал Windows (необязательно). Это обеспечит лучшие возможности, включая возможность настройки и открытия нескольких терминалов в одном интерфейсе (включая Ubuntu, Debian, PowerShell, Azure CLI или то, что вы предпочитаете использовать).
Зарегистрируйте идентификатор DOCKER в DOCKER Hub (необязательно).

Примечание

WSL может запускать дистрибутивы в режиме WSL версии 1 или WSL 2. Это можно проверить, открыв PowerShell и введя: . Убедитесь, что дистрибутив настроен на использование WSL 2, введя: . Замените на имя дистрибутив (например, Ubuntu 18,04).

В WSL версии 1 из-за фундаментальных различий между Windows и Linux подсистема DOCKER не смогла запуститься непосредственно внутри WSL, поэтому Группа DOCKER разработала альтернативное решение с использованием виртуальных машин Hyper-V и Линукскит. Однако поскольку WSL 2 теперь работает в ядре Linux с полной емкостью системных вызовов, Docker можно полностью запустить в WSL 2. Это означает, что контейнеры Linux могут работать изначально без эмуляции, что обеспечивает лучшую производительность и совместимость со средствами Windows и Linux.

Устранение неполадок

Нерекомендуемый контекст DOCKER WSL

Если вы использовали предварительную ознакомительную версию DOCKER для WSL, возможно, у вас есть контекст DOCKER с именем «WSL», который теперь устарел и больше не используется. Можно проверить с помощью команды: . Вы можете удалить контекст «WSL», чтобы избежать ошибок с помощью команды: так, как вы хотите использовать контекст по умолчанию для Windows и WSL2.

Возможные ошибки, которые могут возникнуть при работе с этим нерекомендуемым контекстом WSL, включают: или

Дополнительные сведения об этой ошибке см. в статье Настройка DOCKER в Windows System для Linux (WSL2) в Windows 10.

Не удается найти папку хранилища образов DOCKER

DOCKER создает две папки дистрибутив для хранения данных:

\WSL $ \доккер-десктоп
\WSL $ \доккер-десктоп-Дата

Эти папки можно найти, открыв дистрибутив WSL Linux и введя: для просмотра папки в проводнике Windows. Введите: замените именем вашего распространения (IE. Ubuntu-20,04) для просмотра этих папок.

Дополнительные сведения о поиске расположений хранилищ DOCKER в WSL см. в этой статье из РЕПОЗИТОРИЯ WSL или этой стакковерлов записи.

Дополнительные сведения об устранении общих проблем в WSL см. в документации по устранению неполадок .

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

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

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

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

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

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

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

Отладка .NET приложения запущенного в контейнере

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

Далее запустим redis и подключим его к ранее созданной сети. Благодаря параметру процесс в контейнере будет запущен в фоновом режиме

Далее с помощью Visual Studio 2019 создадим новый проект ASP.NET Core Web API, который будет использован для демонстрации отладки

Добавим для взаимодействия с Redis пакет StackExchange.Redis через Package Manager Console

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

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

Добавим файл RedisRepository.cs, где будет находится служба кеширования сформированных прогнозов

Зарегистрируем созданные службы в классе Startup

И наконец, изменим созданный автоматически единственный контроллер WeatherForecastController следующим образом

Помимо прочего в проект автоматически был добавлен файл Dockerfile с инструкциями для Docker. Оставим его без изменений

В результате получим следующую структуру проекта

Если по какой-то невероятной причине Вам понадобятся исходники, то они здесь

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

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

После убедимся, что все необходимые контейнеры находятся в одной сети

Далее установим Breakpoint в единственном методе контроллера и пошлем запрос через Postman, или через любой браузер

Кстати, используемый порт в Вашем случае может отличаться и его можно посмотреть в окне Containers

Результат в окне Postman

Дополнительно убедимся, что значение зафиксировано в redis, подключившись с помощью консоли redis-cli

Что такое Dockerfile

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

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

Файл Docker имеет следующую форму:

не чувствительна к регистру, но по соглашению для ее имен используется ЗАПИСЬ.

Ниже приведен список с кратким описанием некоторых из наиболее часто используемых инструкций Dockerfile:

ARG — эта инструкция позволяет вам определять переменные, которые могут быть переданы во время сборки. Вы также можете установить значение по умолчанию.
FROM — базовое изображение для построения нового изображения. Эта инструкция должна быть первой инструкцией без комментариев в Dockerfile. Единственное исключение из этого правила — когда вы хотите использовать переменную в аргументе . В этом случае может предшествовать одна или несколько инструкций .
LABEL — используется для добавления метаданных к изображению, таких как описание, версия, автор и т. Д. Вы можете указать несколько , и каждая инструкция представляет собой пару «ключ-значение».
RUN — команды, указанные в этой инструкции, будут выполняться в процессе сборки. Каждая инструкция создает новый слой поверх текущего изображения.
ДОБАВИТЬ — используется для копирования файлов и каталогов из указанного источника в указанное место назначения в образе докера. Источником могут быть локальные файлы, каталоги или URL. Если источником является локальный tar-архив, он автоматически распаковывается в образ Docker.
КОПИРОВАТЬ — аналогично но источником может быть только локальный файл или каталог.
ENV — Эта инструкция позволяет вам определить переменную среды.
CMD — используется для указания команды, которая будет выполняться при запуске контейнера. Вы можете использовать только одну инструкцию в своем Dockerfile.
ENTRYPOINT — аналогично , эта инструкция определяет, какая команда будет выполняться при запуске контейнера.
WORKDIR — эта директива устанавливает текущий рабочий каталог для инструкций , , , и .
ПОЛЬЗОВАТЕЛЬ — Установите имя пользователя или для использования при выполнении любых следующих инструкций , , , и .
VOLUME — позволяет подключить каталог хост-машины к контейнеру.
EXPOSE — используется для указания порта, на котором контейнер прослушивает во время выполнения.

Чтобы исключить добавление файлов и каталогов в образ, создайте файл в контекстном каталоге. Синтаксис аналогичен файла Git.

Что происходит, когда запускается контейнер?

Или с помощью программы , или с помощью RESTful API, docker клиент говорит docker демону запустить контейнер.

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

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

Что же происходит под капотом, когда мы запускаем эту команду?

Docker, по порядку, делает следующее:

скачивает образ ubuntu: docker проверяет наличие образа на локальной машине, и если его нет — то скачивает его с Docker Hub. Если же образ есть, то использует его для создания контейнера;
создает контейнер: когда образ получен, docker использует его для создания контейнера;
инициализирует файловую систему и монтирует read-only уровень: контейнер создан в файловой системе и read-only уровень добавлен образ;
инициализирует сеть/мост: создает сетевой интерфейс, который позволяет docker-у общаться хост машиной;
Установка IP адреса: находит и задает адрес;
Запускает указанный процесс: запускает ваше приложение;
Обрабатывает и выдает вывод вашего приложения: подключается и логирует стандартный вход, вывод и поток ошибок вашего приложения, что бы вы могли отслеживать как работает ваше приложение.

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

Docker Compose

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

На слайде показан пример из официального репозитория GitLab: здесь через командную строку запускается Docker-контейнер GitLab.

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

Поэтому и придумали Docker Compose – файлик в формате YAML, который описывает запуск контейнера и сервисов, взаимосвязь этих контейнеров между собой.

Вы берете готовый Docker Compose либо открываете текстовый редактор и декларативно описываете, как должен выглядеть ожидаемое вами развертывание.

В тексте Docker Compose описываете:

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

После того как манифест docker-compose будет готов, сервис запускается одной командой:

Эти файлики Docker Compose вы можете хранить в своей инфраструктуре и так же их версионировать, меняя какие-то параметры.

Сборка нового образа

Сборка начинается с создания файла Dockerfile — он содержит инструкции того, что должно быть в контейнере. В качестве примера, соберем свой веб-сервер nginx.

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

mkdir -p /opt/docker/mynginx

* где /opt/docker/mynginx — полный путь до каталога, где будем создавать образ.

… переходим в данный каталог:

cd /opt/docker/mynginx

… и создаем Dockerfile:

vi Dockerfile

FROM centos:7
MAINTAINER Dmitriy Mosk <master@dmosk.ru>
ENV TZ=Europe/Moscow
RUN yum install -y epel-release && yum install -y nginx
RUN yum clean all
RUN echo «daemon off;» >> /etc/nginx/nginx.conf
RUN sed -i «0,/nginx/s/nginx/docker-nginx/i» /usr/share/nginx/html/index.html
CMD

* в данном файле мы:

используем базовый образ centos 7;
в качестве автора образа указываем Dmitriy Mosk;
задаем временную зону внутри контейнера Europe/Moscow.
устанавливаем epel-release и nginx;
чистим систему от метаданных и кэша пакетов после установки;
указываем nginx запускаться на переднем плане (daemon off);
в индексном файле меняем первое вхождение nginx на docker-nginx;
запускаем nginx.

* подробное описание инструкций Dockerfile смотрите .

Запускаем сборку:

docker build -t dmosk/nginx:v1 .

* где dmosk — имя автора; nginx — название для сборки; v1 — тег с указанием версии. Точка на конце указывает, что поиск Dockerfile выполняем в текущей директории.

… начнется процесс сборки образа — после его завершения мы должны увидеть что-то на подобие:

Successfully built eae801eaeff2
Successfully tagged dmosk/nginx:v1

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

docker images

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

docker run -d -p 8080:80 dmosk/nginx:v1

* в данном примере мы запустим контейнер из образа dmosk/nginx:v1 и укажем, что необходимо опубликовать внешний порт 8080, который будет перенаправлять трафик на порт 80 внутри контейнера.

Открываем браузер и переходим по адресу http://<IP-адрес нашего докера>:8080 — мы должны увидеть страницу приветствия с нашим docker-nginx:

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

docker ps -a

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

docker stop 5fe78aca2e1d

docker start 5fe78aca2e1d

* где 5fe78aca2e1d — идентификатор контейнера.

Docker

Dockerfile

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

Для начала попробуем написать Dockerfile «в лоб» (сразу скажу, что это плохой способ, не делайте так):

Здесь мы используем базовый образ на основе Alpine с уже установленным JDK для сборки нашего проекта. Командой ADD мы добавляем в образ текущую директорию src, отмечаем ее рабочей (WORKDIR) и запускаем сборку. Команда EXPOSE 8080 сигнализирует докеру, что приложение в контейнере будет использовать его порт 8080 (это не сделает приложение доступным извне, но позволит обратиться к приложению, например, из другого контейнера в той же сети докера).

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

В результате получаем образ размером в 456 Мбайт (из них базовый образ JDK 340 занял Мбайт). И все притом, что классов в нашем проекте по пальцем пересчитать. Чтобы уменьшить размер нашего образа:

Используем многошаговую сборку. На первом шаге соберем проект, на втором установим JRE, а третим шагом скопируем все это в новый чистый Alpine образ. Итого в финальном образе окажутся только необходимые компоненты.
Воспользуемся модуляризацией java. Начиная с Java 9, можно с помощью инструмента jlink создать JRE только из нужных модулей

Для любознательных, вот хорошая статья про подходы уменьшения размеров образа https://habr.com/ru/company/ruvds/blog/485650/.

Итоговый Dockerfile:

Пересоздаем образ, и он в итоге похудел в 6 раз, составив 77 МБайт. Неплохо. После, готовые образы можно загрузить в реестр образов, чтобы ваши образы были доступны для скачивания из интернета.

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

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

Далее запустим контейнер бекенда с именем ‘backend’ с образом microservices-backend:1.0.0:

Запускаем шлюз:

В этой команде мы указываем, что мы пробрасываем 80 порт нашего хоста на 8080 порт контейнера. Опции env мы используем для установки переменных среды, которые автоматически будут вычитаны спрингом и переопределят свойства из application.properties.

Шаг 1: установка Docker

Сначала нужно удалить все пакеты Docker, которые, возможно, были установлены ранее:

$ sudo apt-get remove docker docker-engine docker.io

А затем уже перейти к установке самого Docker:

$ sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -$ sudo apt-key fingerprint 0EBFCD88$ sudo add-apt-repository "deb  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"$ sudo apt-get update$ sudo apt-get install -y docker-ce

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

$ docker info

Она показывает информацию о Docker Engine, развернутом в окружении. А для того, чтобы посмотреть версию Docker Engine и Tools, введите:

$ docker version

Извлечение и запуск образа контейнера

Откройте терминал bash в Linux или Mac либо сеанс PowerShell с повышенными привилегиями в Windows.

Извлеките образ контейнера Linux с SQL Server 2017 из центра Docker.

Совет
В рамках этого руководства примеры команд Docker приводятся как для оболочки bash (Linux/Mac), так и для PowerShell (Windows).

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

Важно!
Сопоставление томов узла для Docker в Windows в настоящее время не поддерживает сопоставление полного каталога. Однако можно сопоставить подкаталог, например , с хост-компьютером.
На данный момент не поддерживается сопоставление томов узла для Docker на Mac с образом SQL Server на Linux

Вместо этого следует использовать контейнеры томов данных. Это ограничение относится только к каталогу . Операции чтения из подключенного каталога осуществляются в нормальном режиме. Например, вы можете подключить каталог узла с помощью команды -v на Mac и восстановить резервную копию из файла с расширением BAK, который находится на узле.

Эта команда создает контейнер SQL Server 2017 с выпуском Developer (по умолчанию). Порт SQL Server 1433 доступен на узле как порт 1401. Необязательный параметр создает контейнер томов данных с именем sql1ddata. Он используется для сохранения данных, созданных SQL Server.

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

Для просмотра ваших контейнеров Docker используйте команду .

Если в столбце STATUS (состояние) отображается состояние Up (запущен), то SQL Server выполняется в контейнере и прослушивает порт, указанный в столбце PORTS (порты). Если в столбце STATUS контейнера с SQL Server отображается Exited (завершен), см.руководство Устранение неполадок конфигурации.

Откройте терминал bash в Linux или Mac либо сеанс PowerShell с повышенными привилегиями в Windows.

Извлеките образ контейнера Linux с SQL Server 2019 из центра Docker.

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

Эта команда создает контейнер SQL Server 2019 с выпуском Developer (по умолчанию). Порт SQL Server 1433 доступен на узле как порт 1401. Необязательный параметр создает контейнер томов данных с именем sql1ddata. Он используется для сохранения данных, созданных SQL Server.

Для просмотра ваших контейнеров Docker используйте команду .

Установка Docker на Windows 10

Существует два варианта установки Docker на Windows:

Приложение «Docker Toolbox for Windows».

Приложение «Docker for Windows».

Примечание: Обратите внимание, что «Docker Toolbox for Windows» является устаревшим решением, которым вы можете воспользоваться, если ваш компьютер не удовлетворяет требованиям установки «Docker for Windows». Более детально об установке Docker Toolbox вы можете прочитать здесь

На этом уроке мы установим Docker через приложение «Docker for Windows», так как это решение является наиболее стабильным и надежным. Итак, сначала нам нужно скачать установщик.

Далее запускаем инсталлятор . Следуйте инструкциям мастера установки, дайте установщику разрешение на использование прав администратора и дождитесь окончания установки.

Примечание: Приложению Docker права администратора нужны для того, чтобы установить сетевые компоненты, создать ссылки на само приложение и дать возможность Hyper-V управлять виртуальными машинами.

Чтобы запустить Docker Desktop, воспользуйтесь поиском в Windows:

Индикатором запуска Docker является иконка «кита», появившаяся в системном трее:

Если иконка «кита» скрыта в системном трее, то нажмите на стрелочку вверх, чтобы посмотреть все иконки. После установки Docker Desktop вы также получите всплывающее уведомление о том, что Docker установлен и готов к работе:

После того, как инициализация закончена, нажмите на иконку «кита» в системном трее и выберите пункт , чтобы проверить, что вы используете последнюю версию Docker.

Поздравляю! Вы успешно установили Docker Desktop на Windows.

6.2 Общие команды

команда	эффект
FROM image_name:tag	Определяет, какой базовый образ используется для запуска процесса сборки
MAINTAINER user_name	Объявить создателя изображения
ENV key value	Установите переменные среды (вы можете написать несколько записей)
RUN command	Это основная часть Dockerfile (можно записать несколько записей)
ADD source_dir/file dest_dir/file	Скопируйте файл с главного компьютера в контейнер. Если это сжатый файл, он будет автоматически распакован после копирования.
COPY source_dir/file dest_dir/file	Аналогично ADD, но не может распаковываться, если есть сжатые файлы.
WORKDIR path_dir	Установить рабочий каталог

Создание Docker образа

Этот процесс требует Dockerfile. Мы можем рассматривать Dockerfile как руководство по эксплуатации, которое говорит Docker, что собирать (подобие requirements.txt в python). Короче говоря, это файл конфигурации, в котором хранится инструкция по сборке.

Как это работает?

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

Создайте Dockerfile, который определяет конфигурацию нашего приложения.

Примечание. Имя файла должно быть Dockerfile с большой латинской буквы D.

Давайте посмотрим на некоторые важные ключевые слова, используемые в Dockerfile

Мы можем использовать символы #, чтобы добавить комментарий в Dockerfile
Ключевое слово FROM определяет базовый образ, которое будет использоваться.
Ключевое слово MAINTAINER — это пользователь, который будет поддерживать этот образ.
Ключевое слово RUN используется для запуска инструкции, приведенной для образа. В нашем случае сначала обновите систему, а затем установите MySQL.
Ключевое слово CMD используется для выполнения команды после запуска контейнера.
Ключевое слово COPY можно использовать для копирования файла из нашей хост операционной системы в док-контейнер.
Ключевое слово EXPOSE используется для указания номера порта, на котором контейнер будет выполнять свой процесс.

Запустите команду ниже, чтобы создать наш образ Docker

Синтаксис

docker build -t /repo-name

В приведенной выше команде имя изображения и символ точка « . » указывает текущий рабочий каталог. Это означает, что Docker ищет текущий каталог файла Docker. Опция « -t » используется для обозначения образа.

Вывод будет похожий на:

Теперь давайте проверим наш образ, запустив его с помощью команды запуска docker.

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

Пространство имен(namespaces)

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

Это создает изолированный уровень, каждый аспект контейнера запущен в своем простанстве имен, и не имеет доступ к внешней системе.

Список некоторых пространств имен, которые использует docker:

pid: для изоляции процесса;
net: для управления сетевыми интерфейсами;
ipc: для управления IPC ресурсами. (ICP: InterProccess Communication);
mnt: для управления точками монтирования;
utc: для изолирования ядра и контроля генерации версий(UTC: Unix timesharing system).

Часть 0.6 Ладно, все это чужие контейнеры, а как мне сделать свое, с нуля?

Каждая законченная команда — создает слой файловой системы с результатами изменений, порожденными этой командой. т.е. например выполнив команду apt install htop, вы создадите слой, который будет содержать результат выполения этой команды — бинарники, библиотеки итд. в конечном итоге каждый такой слой будет наложен друг на друга, а затем на исходный (образ операционной системы) и вы получите конечный результат. Отсюда проистекают несколько ограничений:
Слои независимы друг от друга. это значит что запущенная в процессе сборки какая-нибудь служба внутри контейнера существует только в пределах своего слоя. Яркий пример — попытка залить базу в mysql. Как это обычно происходит? нужно запустить mysql-сервер и следующей командой залить базу. Здесь это так не сработает. Создастся слой, который сохранит результаты запуска mysql (логи, итп) и потом mysql просто завершится. в следующем слою (при выполнении команды заливки базы) мускуль уже не будет запущен и будет ошибка. Решение этой проблемы — всего-навсего объединять команды через &&.
3) А вот постоянные данные будут накладываться от первой команды до последней друг на друга и храниться постоянно от слоя к слою. Поэтому, создав какой-либо файл первой командой, вы сможете к нему обратиться и в последней команде.