Настройка докеров

Ответ 1

docker заставляет вас думать очень тяжело о том, какие неизменяемые и изменчивые части вашего приложения. неизменяемые части создаются как базовые изображения, в то время как изменяемые части создаются в виде контейнеров (и, возможно, сохраняются как изображения). например, вы можете решить заблокировать версию ОС и версию Java для определенного цикла разработки. это неотъемлемая часть, поэтому вы строите базовое изображение своего приложения на основе этого. ваш код приложения добавляется к базовому изображению и запускается как контейнер.

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

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

Ответ 2

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

Вот что я сделал, чтобы справиться с той же ситуацией.

1) Для начала мы создаем образ (скажем, myimage), который включает в себя все зависимости db, java и т.д. Это изображение является нашим базовым изображением и может использоваться несколькими разработчиками раз в несколько раз.

2) Разработчик может создать свой код и слить его в git.

3) Создайте задание jenkins, которое создает файл моментального снимка (например:.zip), который включает все зависимости, такие как банки и пакет.

4) Этот zip перемещается в назначенный сервер, используя плагин ssh в докере.

5) Затем Дженкинс должен запустить Dockerfile, который перемещает файл (.zip) в контейнер myimage и запускает ваш веб-приложение.

6) Включите все виды своих тестов в каталог внутри докеры и сделайте Dockerfile для их запуска.

7) Убедитесь, что при запуске новой сборки в Jenkins предыдущий контейнер Docker остановлен.

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

Надеюсь, этот ответ помог вам во всем, что вы ищете. Это сработало для меня. Сообщите нам, если это сработает и для вас. Все лучшее

Ответ 3

Курс краха

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

Изображение докера похоже на шаблон виртуальной машины. Контейнеры - это живые экземпляры изображения. Мы указываем, как создать изображение с помощью Dockerfile, как и vagrantfile. Он содержит библиотеки, программы и конфигурацию, необходимые для запуска любого приложения, которое мы хотели бы запускать в контейнере.

Рассмотрим этот упрощенный пример из nginx:

# Choose base image (in this case ubuntu OS)
FROM dockerfile/ubuntu

# Install nginx
RUN apt-get update && apt-get install nginx

# Define default command to run when the container starts.
# i.e the nginx webserver
CMD ["nginx"]

# Expose ports. Allowing our webserver to be accessible outside the container.
EXPOSE 80
EXPOSE 443

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

Почему изображения полезны?

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

Материал JVM

Изображения докеров похожи на блоки, которые разделяют части, которые являются одинаковыми, и только добавление новых битов (что означает меньшее использование дискового пространства для нас!). Если у вас несколько приложений, для которых требуется JVM, вы должны использовать базовое изображение java. Это означает, что несколько экземпляров JVM работают, но это проблема компромисса/дизайна, которую вы бы делали при выборе докера.

Контейнеры данных

Они сбивают с толку, они в основном позволяют переносить ваши данные так же, как ваши контейнеры приложений. Они не нужны, просто другое дизайнерское решение. Вы все равно можете экспортировать данные DB в CSV и все обычные способы перемещения изнутри вашего контейнера приложений. Я лично не использую контейнеры данных в своем рабочем процессе, так как я имею дело с ТБ данных и переносимость данных, это не вызывает большого беспокойства. Вместо этого я использую volumes, вы можете указать докере использовать каталог файловой системы хоста для хранения своих данных. Таким образом, данные сохраняются постоянно на хосте, независимо от времени жизни контейнера докера или изображения.

Постройте

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

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

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

Workflow

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

Наконец, самый простой совет для работы с контейнерами:) Чтобы войти в контейнер и изучить, что происходит, вы можете запустить docker exec -it container-name bash

Отказ

Я знаю некоторые из упрощений в моих объяснениях. Моя цель заключалась в том, чтобы добавить как можно меньше путаницы и новых условий. Я считаю, что это только усложняет задачу, отделяющую основные идеи, варианты использования и т.д., Которые, по-видимому, наиболее волнует OP.