Есть два основных хороших подхода к этому, в зависимости от того, сколько настроек вам нужно сделать.
Если вы просто заменяете конфигурационные файлы и внедряете альтернативные изображения, вы можете использовать Docker bind mounts для этого. Типичный файл Docker Compose для этого может выглядеть так (я немного придумываю пути):
version: '3'
services:
kibana:
image: 'kibana:6.6.2'
volumes:
- ./kibana.yml:/etc/kibana/kibana.yml
- ./kibana.png:/usr/share/kibana/assets/kibana.png
Затем вы можете проверить docker-compose.yml, файл конфигурации и все, что вы вводите таким образом в систему контроля версий. Эти файлы заменяют соответствующие файлы с изображения по указанным путям. (И если процесс контейнера выполняет запись в эти файлы, файлы хоста также изменятся.)
Если вам нужно внести более сложные изменения, создание собственного изображения имеет смысл. (Официальное руководство по Docker по созданию и запуску пользовательских образов полезно, если оно более ориентировано на приложения.) Вы можете запустить изображение FROM любого другого изображения. Эквивалент Dockerfile вышеуказанному может выглядеть как
FROM kibana:6.6.2
COPY kibana.yml /etc/kibana
COPY kibana.png /usr/share/kibana/assets
# Keep base image's ENTRYPOINT/CMD
и соответствующий файл docker-compose.yml может быть просто
version: '3'
services:
kibana:
build: .
Оба эти подхода ставят вас в положение, при котором вы можете проверить все, что было добавлено в изображение / контейнер, в систему управления исходным кодом, а также на случай, если ваша система умрет (или новый коллега пробует проект, или * 1020). * повреждается, или Amazon отключает ваши экземпляры EC2, или ...) вы можете просто вывести артефакты из-под контроля исходного кода и запустить их снова. Если вам нужна более новая версия Kibana, вы можете просто поменять тег изображения и запустить все заново.