Контейнеры с докером

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

Мы можем запустить наш первый контейнер с:

Первое, что он покажет, это то, что у вас нет образа hello-world поэтому он скачает его. Но откуда это изображение? В Docker есть сервис Docker Hub который хранит и редактирует образы Docker Hub . Это в основном GitHub для докера.

После загрузки образа Docker создаст новый контейнер, запустит приложение и остановит контейнер, когда все будет сделано:

Это очень простая вещь, и я думаю, что мы можем добиться большего. Как насчет запуска веб-сервера? Запускаем docker run -p 8080:80 nginx и ждем загрузки образа.

И тогда мы можем получить доступ к http://localhost:8080 и мы увидим страницу приветствия Nginx. Но подождите: на этот раз мы передали новый флаг ( -p ) с некоторыми числами. Что они имеют в виду?

порт

При работе с контейнерами, которые работают через порты, мы должны привязать локальный порт к контейнеру. Как и все веб-серверы, Nginx всегда работает на порту 80. Если мы хотим получить к нему доступ, нам нужно привязать этот порт к localhost. Идея связывания порта заключается в следующем:

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

Управление контейнерами и изображениями

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

• docker ps : Показать запущенные контейнеры. Добавьте флаг -a чтобы показать остановленные контейнеры.
• docker rm <contaier id or name> : удалить контейнер.
• docker images : Показать загруженные изображения.
• docker rmi <image id> : удалить изображение.

Теперь мы можем вести домашнюю работу на наших изображениях.

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

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

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

Пример из реального мира

Лучший способ чему-то научиться — это сломать производство, и теперь идея состоит в том, чтобы использовать docker-compose в реальной жизни.

У нас есть Java-приложение, где мы можем добавлять и извлекать пользователей через RESTful API.

Эти пользователи хранятся в базе данных PostgreSQL, но мы не хотим устанавливать Postgres. Поэтому мы собираемся использовать docker-compose для предоставления Postgres всем, кто клонирует приложение.

Анатомия docker-compose скрипта

• Тег version указывает минимальную версию docker-compose которую можно использовать со скриптом
• services : здесь будут объявлены наши контейнеры. Мы даем название нашему сервису и указываем, что мы хотим для этого сервиса. В этом случае у нас есть образ PostgreSQL 10. postgres:10 — имя изображения и версия, разделенные двоеточием.
• ports : мы связываем порт 5432 в контейнере с 5432 в нашем локальном хосте, как мы делали это ранее с контейнером nginx.
• environment : установите переменные окружения, такие как POSTGRES_PASSWORD и POSTGRES_DB чтобы определить пароль и создать базу данных с именем realworld . Обычно вы можете увидеть возможные переменные в документации к образу Docker в Docker Hub.

Теперь, если мы запустим docker-compose up -d (флаг -d означает отсоединение, поэтому процесс продолжается в фоновом режиме), мы сможем увидеть запущенный экземпляр Postgres.

Поэтому, если мы создадим флягу приложения, можно будет без проблем запустить приложение.

Теперь мы можем получить доступ к http://localhost.com:4321/database и должны увидеть Tables created! если все работает. Мы можем дважды проверить доступ к контейнеру и проверить, видим ли мы таблицу в базе данных.

Сначала мы проверяем идентификатор контейнера:

Затем мы получаем доступ к контейнеру и используем приложение psql для подключения к базе данных, и мы можем перечислить таблицы.

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

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

Сначала мы начинаем создавать наш Dockerfile , указав базовый образ. Этот базовый образ может быть Ubuntu или образом Java. Для нашего приложения мы будем использовать adoptopenjdk/openjdk11-openj9 , который является реализацией OpenJ9 Eclipse Foundation.

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

У нас есть источники; нам нужно создать наше приложение сейчас, поэтому нам нужно RUN команду, чтобы сгенерировать толстый jar со всеми зависимостями.

Это веб-приложение, которое получает запросы через порт TCP. Чтобы иметь возможность получать запросы в контейнере, мы EXPOSE порт, который нам нужен. EXPOSE скажет, какой порт должен предоставить контейнер для сети docker-compose , которую создаст docker-compose , а также будет работать как документация, чтобы увидеть, какой порт необходимо связать при запуске контейнера.

Наконец, мы можем запустить приложение, передав CMD для запуска

Когда готов Dockerfile , мы можем создать образ и создать из него контейнер.

Флаг --tag должен дать изображению имя. Вы также можете указать тег как dev или staging .

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

.dockerignore

Как и в git с .gitignore , в docker есть .dockerignore , файл, который исключает файлы из копии вашего контейнера. Давайте создадим одну, чтобы не копировать специфичные для IDE и выходные папки, чтобы мы быстрее собирались.

Мы создаем образ докера со всем нашим исходным кодом, и, поскольку мы просто хотим запустить наше приложение, нам не нужно распространять их с нашим последним jar-файлом. Исходный код приложения находится внутри контейнера, его может увидеть любой, у кого есть доступ к изображению, и это увеличит наше изображение без необходимости. Чтобы решить эту проблему, мы собираемся сделать multi-stage сборку.

Что такое multi-stage сборка?

Многоэтапная сборка — это способ разделения процесса построения изображения между несколькими контейнерами с различными этапами, что-то вроде сборки CI. Преобразовать вашу обычную сборку в multi-stage легко, вам просто нужно добавить еще один FROM в ваш Dockerfile .

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

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

• Дать имя для стадии сборки. Мы делаем это, добавляя as <name> перед базовым образом.
• Затем мы должны удалить вещи, которые должны запускать приложение. Для этого мы удаляем EXPOSE и CMD из файла, но не удаляем, мы собираемся использовать его позже.

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

• Определение изображения. Нам не нужно полное изображение с Gradle или Maven. На самом деле, нам даже не нужен JDK, нам просто нужен JRE, поэтому мы можем использовать adoptopenjdk/openjdk11:jre-11.0.2.9-alpine изображение adoptopenjdk/openjdk11:jre-11.0.2.9-alpine которое имеет только среду выполнения Java. Он основан на легком дистрибутиве Linux под названием Alpine.
• У нас может быть тот же самый WORKDIR из предыдущего этапа.
• Теперь мы собираемся скопировать jar, который мы создаем. В этом случае мы собираемся скопировать jar из контейнера на предыдущем этапе, используя --from=build перед тем как файлы, которые мы хотим скопировать.
• Теперь нам осталось только выставить EXPOSE и CMD которые мы сохранили ранее.

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

Добавьте изображение в docker-compose.yml

Теперь у нас есть правильно построенный образ, который мы можем добавить в наш docker-compose.yml , но в отличие от уже имеющегося образа postgres, мы хотим построить образ на основе Dockerfile а также нам нужно настроить некоторые переменные окружения, чтобы подключиться к базе данных.

Поэтому мы добавляем новый файл в файл. Вместо использования image мы собираемся использовать build и передавать относительный путь к Dockerfile который мы хотим построить.

Мы сопоставляем порт и добавляем переменную окружения для DB_HOST указывающую на наш сервис db и порт postgres. И, наконец, мы добавляем depends_on говоря, что мы зависим от службы db .

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

Это важная часть наших журналов: depends_on ожидает готовности контейнера, но не ожидает запуска объектов после инициализации.

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

Самое основное, что мы можем сделать, чтобы убедиться, что это порождать контейнеры и запускать приложение вручную, но как мы можем подключиться к контейнеру с помощью docker-compose ?

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

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

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

Взломать наш путь через

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

Современные проблемы, требующие современных решений.

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

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

Первое, что нам нужно сделать, это поместить скрипт в контейнер, мы уже создали изображение, поэтому мы не можем снова использовать COPY , в этом случае мы можем создать том внутри нашего контейнера.

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

Мы изменили docker-compose.yml чтобы добавить наши новые функции:

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

Прямо сейчас приложение выставляет порт «4321», который очень негибкий. Если требуется какое-либо изменение, единственным способом сделать это было бы сопоставление в файле docker-compose для сопоставления с другим портом. Это можно сделать более гибким, используя ARG в Dockerfile .

Какие изменения необходимы для этого?

Установите ключевое слово ARG в Dockerfile . Это получит имя аргумента и значение по умолчанию. Хорошо установить значение по умолчанию на тот случай, если вы не хотите каждый раз передавать значение во время сборки.

При использовании ARG следует позаботиться о другом. Вы не можете использовать ARG который объявлен в FROM после того, с которым вы работаете. Думайте как переменные во время кода: вы не можете использовать переменную до ее объявления или использовать переменную, которая была объявлена ​​внутри другой функции.

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

Наконец, мы должны изменить ключевое слово EXPOSE чтобы использовать ARG вместо жестко заданного значения.

Окончательный результат будет:

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

Чтобы проверить, работает ли контейнер с правильным портом, вы можете увидеть открытые порты с помощью docker ps

Вы можете увидеть в столбце PORTS что он представляет 4332/tcp как это было передано в аргументах сборки, но что если вы захотите сделать это с помощью docker-compose ? Есть ли способ передать build-arg через файл yml? Конечно.

Измените docker-compose.yaml чтобы передать аргумент в части сборки, используя тег args . Теперь эта build будет иметь несколько значений. Ключевой context должен быть добавлен, чтобы указать место, где будет находиться ваш Dockerfile .

После внесения всех изменений просто запустите docker-compose up и можно проверить, все ли работает в нужном порту, пытаясь создать таблицы.

CMD — не единственный способ запуска контейнера в Docker, фактически до запуска CMD контейнер имеет ENTRYPOINT . Иногда вы хотите, чтобы ваш контейнер выполнял более сложный запуск и выполнял несколько команд или сценариев перед запуском вашего приложения. Docker объединит ENTRYPOINT с CMD переданным в контейнер, поэтому в случае, если мы имеем в docker-compose.yml , команда, которая только что wait-for-db.sh могла быть отделена от команды java .

Итак, если Dockerfile выглядел так:

Это будет выполнено как wait-for-db.sh java -jar realworldkata-1.0-SNAPSHOT-all.jar . Сценарий может сделать несколько вещей и в конце выполнить приложение.

Postgres делает что-то вроде этого. Вместо того, чтобы использовать команду postgres в качестве точки запуска, он выполняет сценарий, который устанавливает папку, в которой будут храниться данные, устанавливает пароль в правильной переменной среды и проверяет, есть ли .sql либо файл .sql или .sh который нужно запустить до запуск базы данных.

Построение одинакового образа докера на каждой машине — не самая интуитивно понятная вещь. Возможно, вы захотите использовать образ на другом компьютере, не имея всего исходного кода, а просто с помощью docker-compose.yml .

Прежде всего, необходимо зарегистрировать учетную запись в Docker Hub и войти в систему с этой учетной записью в командной строке:

После входа в систему вы можете отправить изображения в репозитории. Репозиторий основан на имени тега, которое вы даете при создании изображения. При создании первого изображения был флаг --tag для присвоения имени изображению; хранилище в Docker Hub будет использовать то же имя. Вы можете иметь несколько версий одного и того же изображения в репозитории, добавив в него версию.

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

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

Теперь вместо создания с нуля, вы можете просто использовать образ из Docker Hub в вашем docker-compose.yml и запускать, docker-compose.yml не отправляя исходные файлы.

И с этим изменением и работающими контейнерами мы можем закончить этот пост.