Создание собственного образа Docker
Docker позволяет не только загружать и использовать готовые контейнеры, но создавать свои. В данной инструкции мы пошагово разберем установку Docker на Linux, создание собственного образа и загрузку его на Docker Hub.
Установка Docker
Рассмотрим примеры установки на базе операционных систем Red Hat/CentOS и Debian/Ubuntu.
Red Hat/CentOS
Устанавливаем репозиторий — для этого загружаем файл с настройками репозитория:
* если система вернет ошибку, устанавливаем wget командой yum install wget.
. и переносим его в каталог yum.repos.d:
mv docker-ce.repo /etc/yum.repos.d/
yum install docker-ce docker-ce-cli containerd.io
Если система вернет ошибку Необходимо: container-selinux >= . , переходим на страницу пакетов CentOS, находим нужную версию container-selinux и копируем на него ссылку:
. с помощью данной ссылки выполняем установку:
yum install http://mirror.centos.org/centos/7/extras/x86_64/Packages/container-selinux-2.99-1.el7_6.noarch.rpm
После повторяем команду на установку докера:
yum install docker-ce docker-ce-cli containerd.io
Debian/Ubuntu
В deb-системе ставится командой:
apt-get install docker docker.io
После установки
Разрешаем запуск сервиса docker:
systemctl enable docker
. и запускаем его:
systemctl start docker
docker run hello-world
. мы должны увидеть:
.
Hello from Docker!
This message shows that your installation appears to be working correctly.
.
Сборка нового образа
Сборка начинается с создания файла Dockerfile — он содержит инструкции того, что должно быть в контейнере. В качестве примера, соберем свой веб-сервер nginx.
И так, чтобы создать свой образ с нуля, создаем каталог для размещения Dockerfile:
mkdir -p /opt/docker/mynginx
* где /opt/docker/mynginx — полный путь до каталога, где будем создавать образ.
. переходим в данный каталог:
. и создаем Dockerfile:
FROM centos:7
MAINTAINER Dmitriy Mosk
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 [ «nginx» ]
* в данном файле мы:
- используем базовый образ centos 7;
- в качестве автора образа указываем Dmitriy Mosk;
- устанавливаем 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 run -d -p 8080:80 dmosk/nginx:v1
* в данном примере мы запустим контейнер из образа dmosk/nginx:v1 и укажем, что необходимо опубликовать внешний порт 8080, который будет перенаправлять трафик на порт 80 внутри контейнера.
Открываем браузер и переходим по адресу http:// :8080 — мы должны увидеть страницу приветствия с нашим docker-nginx:
Посмотреть созданные контейнеры можно командой:
Запустить или остановить контейнеры можно командами:
docker stop 5fe78aca2e1d
docker start 5fe78aca2e1d
* где 5fe78aca2e1d — идентификатор контейнера.
Редактирование образа
В примере выше мы рассмотрели создание нового образа с нуля. Также, мы можем взять любой другой образ, отредактировать его и сохранить под своим названием.
Скачаем образ операционной системы CentOS:
docker pull centos:latest
Войдем в скачанный образ для его изменения:
docker run -t -i centos:latest /bin/bash
Внесем небольшие изменения, например, создадим учетную запись:
[root@8f07ef93918f /]# useradd dmosk -G wheel -m
[root@8f07ef93918f /]# passwd dmosk
* в данном примере мы создали пользователя dmosk и задали ему пароль.
docker commit -m «Add user dmosk» -a «Dmitry Mosk» 8f07ef93918f centos:my
* где -m — параметр для указания комментария; -a — указывает автора; 8f07ef93918f — идентификатор контейнера, который был нами изменен (его можно было увидеть в приглашении командной строки); centos:my — название нашего нового образа.
Новый образ создан.
Загрузка образа на Docker Hub
Заходим на Docker Hub страницу регистрации. Создаем пользователя:
На следующей странице также заполняем данные профиля. После переходим в почтовый ящик, который был указан при регистрации и переходим по ссылке Confirm Your Email With Docker для подтверждения регистрации. Регистрация закончена.
Переходим на страницу Repositories и создаем свой репозиторий, например, dmosk. Теперь можно загрузить наши образы в репозиторий.
Сначала авторизуемся в Linux под нашим зарегистрированным пользователем:
docker login —username dmosk
Задаем тег для одного из образов и загружаем его в репозиторий:
docker tag centos:my dmosk/dmosk:centos
docker push dmosk/dmosk:centos
Загрузим второй образ:
docker tag dmosk/nginx:v1 dmosk/dmosk:nginx
docker push dmosk/dmosk:nginx
В Docker Hub должны появиться наш образы:
Чтобы воспользоваться образом на другом компьютере, также авторизуемся под зарегистрированным пользователем docker:
docker login —username dmosk
docker pull dmosk/dmosk:nginx
docker run -d -p 8080:80 dmosk/dmosk:nginx
Описание инструкций Dockerfile
| Инструкция | Описание | Пример |
|---|---|---|
| FROM | Указывает, какой базовый образ нужно использовать. Обязательная инструкция для Dockerfile | FROM ubuntu:16.04 |
| MAINTAINER | Автор образа. | MAINTAINER DMosk |
| RUN | Выполняет команду в новом слое при построении образа. | RUN apt-get install python |
| CMD | Запускает команду каждый раз при запуске контейнера. Может быть вызвана только один раз. Если в Dockerfile указать несколько таких инструкций, то выполнена будет последняя. | CMD [«openvpn»] |
| LABEL | Добавляет метаданные. | LABEL version=»2″ |
| EXPOSE | Указывает, какой порт должно использовать приложение внутри контейнера. | EXPOSE 8080 |
| ENV | Задает переменные окружения в образе. | ENV PGPASSWORD pass |
| ADD | Добавляет файлы/папки из текущего окружения в образ. Если в качестве копируемого файла указать архив, то он будет добавлен в образ в распакованном виде. Также в качестве источника принимает URL. | ADD /root/.ssh/ |
| COPY | Также как и ADD добавляет файлы в образ, но обладает меньшими функциями — не принимает URL и не распаковывает архивы. Рекомендован для использования в случаях, где не требуются возможности ADD или когда нужно перенести архив, как архив. | COPY ./mypasswd /root/ |
| ENTRYPOINT | Указывает команду, которой будет передаваться параметр при запуске контейнера. | ENTRYPOINT [«/sbin/apache2»] |
| VOLUME | Добавляет том в контейнер. | VOLUME [«/opt/myapp»] |
| USER | Задает пользователя, от которого будет запущен образ. | USER user:group |
| WORKDIR | Можно задать каталог, откуда будут запускаться команды ENTRYPOINT и CMD. | WORKDIR /opt/apps |
| ARG | Создает переменную, которую может использовать сборщик. | ARG folder=/opt/apps WORKDIR $folder |
| ONBUILD | Действия, которые выполняются, если наш образ используется как базовый для другой сборки. | ONBUILD ADD . /app/src |
| STOPSIGNAL | Переопределяет сигнал SIGTERM для завершения контейнера. | STOPSIGNAL SIGINT |
| HEALTHCHECK | Команда, которая будет проверять работоспособность контейнера. | HEALTHCHECK —interval=5m —timeout=3s CMD curl -f http://localhost/ || exit 1 |
| SHELL | Позволяет заменить стандартную оболочку для выполнения команд на пользовательскую. | SHELL [«/bin/sh», «-c»] |
Резервное копирование и восстановление контейнера
Созданный нами контейнер можно сохранить в виде архива и, при необходимости, перенести на другой сервер или оставить как бэкап.
Создание резерва
И так, для создания резервной копии контейнера, смотрим их список:
. и для нужного выполняем команду:
docker save -o /backup/docker/container.tar
* в данном примере мы создаем архив контейнера в файл /backup/docker/container.tar.
Чтобы уменьшить размер, занимаемый созданным файлом, раархивиркем его командой:
* в итоге, мы получим файл container.tar.gz.
Восстановление
Сначала распаковываем архив:
После восстанавливаем контейнер:
docker load -i container.tar
Смотрим, что нужный нам контейнер появился:
Windows контейнеры и Docker
Начиная с Windows Server 2016 в операционной системе от Microsoft включена нативная поддержка контейнеров. Это не Linux контейнеры, это контейнеры, которые работают на Windows, и запускают Windows внутри себя.
Данный факт является результатом присоединения Microsoft к Open Container Initiative (OCI). Контейнеры в Windows позволяют запускать приложения, которые изолированы от остальной части системы в переносимых контейнерах. Эти контейнеры включают в себя все, чтобы ваше приложение было полностью функциональным. Так же как это произошло с Linux, Microsoft надеется, что контейнеры изменят характер поставки программного обеспечения для пользователей и в Windows.
Контейнеры являлись основой вычислений в Linux в течение целого ряда лет. Google, например, уже очень давно использует решения, основанные на контейнерах по всей своей империи, чтобы предоставлять распределенные приложения не только своим сотрудникам, но и своим пользователям по всему миру.
Тем не менее, Google не был долгое время одинок в своем увлечении контейнерными вычислениями. В какой-то момент из ниоткуда появился Docker, который в отличии от Google стандартизировал процессы доставки контейнеров, а также управления ими. Более того, Docker развивался сообществом энтузиастов в мире открытого исходного кода, что сделало его простым и очень популярным решением. С развитием проекта Docker буквально у каждого желающего появилась возможность получить скорость, гибкость и простоту управления программным обеспечением и инфраструктурой, которую предоставляют контейнеры.
Docker революция стала настолько значительной, что даже Microsoft присоединился к этой инициативе в первую очередь за счет поддержки Docker и Linux в Azure, а теперь и за счет интеграции этой технологии в Windows Server 2016. Самое интересное это то, что контейнеры Windows Server не основаны на Linux, это нечто совершенно новое. Windows контейнеры — это контейнеры, которые работают в Windows и запускают Windows внутри себя.
Причем Microsoft настолько серьезно стала относится к контейнерам, что сейчас активно участвует в Open Container Initiative (OCI), пытаясь перетягивать одеяло на себя так, как будто бы она сама придумала эту технологию.
Контейнер в Windows имеет много общего с его аналогом в Linux. Оба обеспечивают изолированную среду для запуска приложений. И там и там контейнеры используют передовые технологии изоляции для обеспечения портативной, но одновременно ограниченной среды, которая включает в себя практически все, чтобы приложение могло быть полностью функциональным.
Контейнер очень похож на виртуальную машину (ВМ) и часто рассматривается как отдельный тип виртуализации, но это два совершенно разные понятия. Да, каждый работает под управлением операционной системы (ОС), предоставляет внутри себя локальную файловую систему и может быть доступен по сети так же как физический компьютер. Тем не менее, при использовании ВМ вы имеете дело с полной и независимой ОС вместе с виртуальными драйверами устройств, управлением памятью и другими компонентами, которые добавляют к накладные расходы.
Контейнер переиспользует большее количество общих ресурсов хост-системы нежели виртуальная машина, а значит, он более легкий, быстрее разворачивается и проще масштабируется между различными датацентрами. Таким образом, контейнер может предложить более эффективный механизм для инкапсулирования приложения, обеспечивая ему при этом необходимые интерфейсы хост-системы — все из этого приводит к более эффективному использованию ресурсов и улучшению переносимости приложений.
Microsoft планирует предложить два типа контейнеров в Windows Server 2016: контейнер Windows Server и Hyper-V контейнер. Оба типа функционируют одинаковым образом, и могут быть созданы и управляются одинаково. Там, где они различаются — это в уровне изоляции, который каждый из них обеспечивает.
Контейнер Windows Server разделяет ядро с ОС работает на хост-машине, что означает, что все контейнеры, работающие на этой машине, разделяют одно и то же ядро. В то же время, каждый контейнер поддерживает свой собственный вид на операционную систему, реестр, файловую систему, IP-адреса и другие компоненты, сочетая это с изоляцией, предоставляемой каждому контейнеру при помощи процессов, пространства имен и технологий управления ресурсами.
Контейнер Windows Server хорошо подходит для ситуаций, в которых и основная ОС, и приложения в контейнерах лежат в пределах той же зоны доверия, например для приложений, которые охватывают несколько контейнеров или образуют общую службу. Тем не менее, контейнеры Windows Server обсуждаются в связи с их зависимостью от процесса обновления ОС хост-системы, который может осложнить обслуживание и препятствовать процессам. Например, патч примененный к хосту может сломать приложение, работающее в контейнере. Что еще более важно, в таких ситуациях, как многопользовательские среды, модель разделяемого ядра может раскрыть систему для уязвимостей приложений и кросс-контейнерных атак.
Hyper-V контейнер решает эти проблемы, предоставляя виртуальную машину, в которой нужно запустить контейнер Windows. При таком подходе контейнер больше не разделяет ядро хост-машины и не имеет зависимости от патчей ОС этой машины. Конечно, такой подход означает некоторую потерю скорости и эффективности упаковки, которые вы получаете с обычным контейнером в Windows Server, но взамен вы получаете более изолированную и безопасную среду.
Вне зависимости от типа контейнера, который вы используете, теперь у вас есть возможность использовать контейнеры с такими технологиями Windows как .NET или PowerShell, что не было возможно раньше. Контейнер для Windows предоставляет все необходимое для обеспечения работы приложения на любом компьютере под управлением Windows Server 2016, давая вам тот уровень переносимости, который был не доступен на протяжении большей части истории Windows. Вы можете создавать свои контейнеры локально, делать их доступными процессов для тестирования и контроля качества, а затем отправить их в команде, занимающейся продуктивом, без необходимости беспокоиться о сложных установках и конфигурациях на каждом шаге этого пути.
