Dockerize / wait-for-it.sh
Для ошибок:
Invalid argument: ./wait-for-it.sh
и
Invalid argument: dockerize
Это потому, что точка входа для контейнера Flyway - это исполняемый файл flyway, а содержимое указанной вами команды добавляется к точке входа в качестве аргументов.Таким образом, в действительности контейнер выполняет следующее:
flyway dockerize ...
или
flyway wait-for-it.sh ...
Ни один из этих аргументов не является допустимым аргументом командной строки Flyway .
Точка входа должна быть обновлена, как вы сделали в P.S.5.Однако затем вы нажали ошибку:
"wait-for-it.sh": executable file not found in $PATH"
Это потому, что wait-for-it.sh (и dockerize) недоступны в контейнере Flyway.
Вы можете создать Dockerfile, который расширяет контейнер Flyway, затем ADD или COPY сценарии, например:
FROM boxfuse/flyway:latest
RUN mkdir /flyway/bin
ADD wait-for-it.sh /flyway/bin/wait-for-it.sh
RUN chmod 755 /flyway/bin/wait-for-it.sh
, или смонтировать том, содержащий скрипт / исполняемый файл:
version: '3'
services:
...
migration:
image: boxfuse/flyway:latest
container_name: flyway_migration
volumes:
- ../sql:/flyway/sql
- ../bin:/flyway/bin
entrypoint: ["/flyway/bin/dockerize", "-wait", "tcp://my_sql_db:3306", "-timeout", "15s", "--", "flyway"]
...
, где локальный каталог ../bin содержит dockerize (или wait-for-it.sh).
Этого должно быть достаточно, чтобы получить dockerize / wait-for-it.ш работает.Однако оба инструмента только проверяют, что порт доступен, а не то, что сама база данных фактически готова для обслуживания запросов.
Compose v2.1
При этом используется docker-compose v2.Синтаксис 1 depends_on: condition может быть разумным подходом.Как вы упомянули в комментариях, этот синтаксис был удален в v3, и многие недовольны этим .
Однако, как говорит один из разработчиков Docker в прокомментируйте эту проблему :
Нет смысла использовать формат v3, если вы не собираетесь использовать службы роя.
Настраиваемый сценарий проверки работоспособности
Другой подход заключается в расширении контейнера Flyway для добавления настраиваемого сценария проверки работоспособности MySQL, аналогичного Postgres, показанному в документации по докеру , :
#!/bin/bash
# wait-for-mysql.sh
set -e
host="$1"
shift
cmd="$@"
until MYSQL_PWD=$MYSQL_ROOT_PASSWORD /usr/bin/mysql --host="$host" --user="root" --execute "SHOW DATABASES;"; do
>&2 echo "MySQL is unavailable - sleeping"
sleep 1
done
>&2 echo "MySQL is up - executing command"
exec $cmd
Затем создайтеDockerfile для расширения Flyway, установки клиента MySQL и добавления этого сценария:
FROM boxfuse/flyway:latest
RUN apt-get update && \
apt-get install -y mysql-client && \
mkdir /flyway/bin
ADD wait-for-mysql.sh /flyway/bin/wait-for-mysql.sh
RUN chmod 755 /flyway/bin/wait-for-mysql.sh
Затем вы можете использовать пользовательский образ Flyway в вашем файле компоновки:
version: '3'
services:
my_sql_percona:
...
migration:
build: ./flyway_mysql_client
container_name: flyway_migration
environment:
MYSQL_ROOT_PASSWORD: password
volumes:
- ../sql:/flyway/sql
entrypoint: ["bash", "/flyway/bin/wait-for-mysql.sh", "my_sql_percona", "--", "flyway"]
command: -url=jdbc:mysql://my_sql_db:3306/abhs?useUnicode=true&characterEncoding=utf8&useSSL=false -user=root -password=password migrate
depends_on:
- my_sql_percona
Недостатки этогоПодход заключается в том, что вам необходимо расширить каждый контейнер с помощью специального сценария проверки работоспособности для каждой из его зависимостей.
стек докера
Синтаксис v2.1 depends_on: condition, похоже, был удален вв пользу перезапустить политику в v3.Однако они вложены в раздел deploy , который:
вступает в силу только при развертывании в рой с развертыванием стека докеров, а игнорируется docker-compose up и docker-compose run.
Итак, еще один вариант - отменить docker-compose и запустить на docker swarm следующим образом:
Добавить on-failureперезапустите политику для контейнера Flyway:
version: '3'
services:
my_sql_percona:
...
migration:
image: boxfuse/flyway:latest
...
depends_on:
- my_sql_percona
deploy:
restart_policy:
condition: on-failure
Создание кластера роя (в данном случае это один узел):
docker swarm init --advertise-addr <your-ip-address>
Развертывание служб:
docker stack deploy --compose-file docker-compose.yml flyway_mysql
Контейнер Flyway будет перезапускаться роем при каждом выходе из системы с ошибкой, пока он не завершится успешно.
Хотя это, похоже, работает, я не уверен, что это лучший подход в этом случае,Например, если контейнер Flyway завершает работу из-за ошибки в сценарии миграции, Swarm продолжит перезапуск контейнера, даже если он никогда не удастся.
Сводка
Я создал репозиторий с этими пятью различными подходами.
Лично я думаю, что я бы использовал подход v2.1, поскольку проверка работоспособности сохраняется в самом контейнере базы данных, а не дублируется в каждом контейнере, который зависит от него.Мне не нужно пользоваться услугами роя, так что выбирайте то, что работает для вас.: -)