Возможно ли повторно войти в существующий выданный контейнер докера, который уже закрыт?

Question

Справочная информация:

Мне нужно разработать Dockerfile.

Но перед этим я хочу выбрать базовый образ и запустить базу контейнеров на этом базовом образе.

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

Проблема:

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

Но, к сожалению, контейнер уже не может быть запущен из-за неправильной настройки приложения в контейнере.

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

Далее приведен минимальный пример, показывающий мой случай:

Dockerfile:

FROM alpine

ADD ./docker-entrypoint.sh .
RUN chmod 777 ./docker-entrypoint.sh

ENTRYPOINT ["./docker-entrypoint.sh"]

docker-entrypoint.sh:

#!/bin/sh

touch /tmp/app.log
tail -f /tmp/app.log

Что я буду делать с выше:

docker build --no-cache -t try .
docker run -idt --name me try
docker exec -it me /bin/sh

Изменить docker-entrypoint.sh на следующее:

#!/bin/sh

exit 0
touch /tmp/app.log
tail -f /tmp/app.log

Тогда:

docker stop me
docker start me # the container will not start

А теперь я знаю, exit 0 может быть, неправильная команда или неправильная конфигурация, я хочу повторить попытку с другими вещами, но без шансов.

Снова хочу отметить :

Я не хочу перезагружать контейнер, потому что в старом контейнере я уже многое сделал вручную, не только exit 0.

И, supervisord тоже не то, что мне было нужно в моем жизненном цикле разработки, я просто хочу упростить ситуацию. Что-то вроде изменения entrypoint for an already existed container (кажется, просто работает для docker run)

Есть ли у меня какие-либо предложения по упрощению этапа разработки?

Answer 1

Просто напишите свой Dockerfile. Редактировать, запустить docker build, повторить.

В Dockerfile нет ничего особенно волшебного. Если вы подходите, но решаете делать подробные заметки в текстовом файле: я хочу запустить FROM некоторое базовое изображение, затем RUN некоторую команду, COPY некоторые файлы и RUN некоторую другую команду: это Dockerfile. Его преимущество заключается в том, что он всегда начинается с чистой окружающей среды и всегда воспроизводим.

Например, скажем, вы пытаетесь скомпилировать какой-то пакет вручную, но не совсем правильно настроили параметры конфигурации.

FROM ubuntu:18.04
RUN apt-get update && apt-get install build-essential
WORKDIR /package
COPY some-package.tar.gz ./
RUN tar xzf some-package.tar.gz
WORKDIR /package/some-package
RUN ./config --wrong-option
RUN make
RUN make install
CMD ["some-command"]

Теперь вы можете запустить docker build ., и он будет проходить через эту последовательность команд. Возможно, когда он достигнет RUN ./config, он потерпит неудачу (потому что скрипт на самом деле называется ./configure). Вы можете отредактировать Dockerfile и повторно запустить docker build, и Docker начнёт сначала, где он потерпел неудачу раньше. Точно так же, когда вы обнаружите, что --wrong-option неверно, вы можете изменить его, и docker build перезапустится с измененной строки.

Если вам нужно выполнить дальнейшую отладку на неисправной стадии (возможно, --wrong-option проходит через этап настройки, но сборка не удалась), вывод docker build включает идентификатор изображения для каждого слоя, и вы можете docker run --rm -it 0123456789ab sh получить оболочка на частичном изображении до шага, у которого возникают проблемы.

Существуют оптимизации, такие как объединение RUN линий вместе и многоэтапные сборки, которые полезны, но вы можете сохранить их до последнего.

docker exec не предназначен для того, чтобы быть основным способом взаимодействия с Docker. Вы столкнетесь точно с проблемами, с которыми сталкиваетесь: нет постоянной записи о том, что вы сделали, это не особенно воспроизводимо, и если контейнер когда-либо будет удален, вы потеряете всю свою работу.

Answer 2

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

Как насчет того, чтобы попробовать следующее:

1. Зафиксируйте свой контейнер как другое изображение.

   Docker коммит мне / оснастка: v001

2. Запустите bash, используя образ.

   docker run -it --name me2 me / snap: v001 bash

3. Исправьте код своей точки входа.