Перевірка Docker-Compose, якщо підключення mysql готове

Question 1

Я намагаюся переконатись, що мій контейнер додатків не запускає міграції / старт, поки контейнер db не буде запущений і ГОТОВИЙ прийняти підключення.

Тому я вирішив скористатися перевіркою працездатності та залежить від опції у файлі складання docker v2.

У додатку я маю таке

app:
    ...
    depends_on:
      db:
      condition: service_healthy

З іншого боку, db має таку перевірку стану здоров'я

db:
  ...
  healthcheck:
    test: TEST_GOES_HERE
    timeout: 20s
    retries: 10

Я спробував кілька підходів, таких як:

переконавшись, що створено db DIR test: ["CMD", "test -f var/lib/mysql/db"]
Отримання версії mysql: test: ["CMD", "echo 'SELECT version();'| mysql"]
Пінг адміністратора (позначає контейнер db як здоровий, але, здається, не є дійсним тестом) test: ["CMD", "mysqladmin" ,"ping", "-h", "localhost"]

Хтось має рішення цього?

Question 2

version: "2.1"
services:
    api:
        build: .
        container_name: api
        ports:
            - "8080:8080"
        depends_on:
            db:
                condition: service_healthy
    db:
        container_name: db
        image: mysql
        ports:
            - "3306"
        environment:
            MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
            MYSQL_USER: "user"
            MYSQL_PASSWORD: "password"
            MYSQL_DATABASE: "database"
        healthcheck:
            test: ["CMD", "mysqladmin" ,"ping", "-h", "localhost"]
            timeout: 20s
            retries: 10

Контейнер api не запускатиметься, доки контейнер db не стане здоровим (в основному, доки mysqladmin не вийде і не прийме підключення.)

Question 3

Якщо ви використовуєте docker-compose v3 + , conditionяк варіант depends_onбуло видалено .

Рекомендований шлях полягає у використанні , а wait-for-it, dockerizeабо wait-for. У своєму docker-compose.ymlфайлі змініть свою команду на:

command: sh -c 'bin/wait-for db:3306 -- bundle exec rails s'

Я особисто віддаю перевагу, wait-forоскільки він може працювати в альпійському контейнері ( shсумісний, не залежить bash). Недоліком є те, що це залежить від netcat, тому, якщо ви вирішите використовувати його, переконайтесь, що ви netcatвстановили його в контейнер, або встановіть його у своєму Dockerfile, наприклад за допомогою:

RUN apt-get -q update && apt-get -qy install netcat

Я також роздвоївwait-for проект, щоб він міг перевірити здоровий статус HTTP (він використовує wget). Тоді ви можете зробити щось подібне:

command: sh -c 'bin/wait-for http://api/ping -- jest test'

PS: PR також готовий до об’єднання, щоб додати цю спроможність до wait-forпроектування.

Question 4

Цього має бути достатньо

version: '2.1'
services:
  mysql:
    image: mysql
    ports: ['3306:3306']
    environment:
      MYSQL_USER: myuser
      MYSQL_PASSWORD: mypassword
    healthcheck:
      test: mysqladmin ping -h 127.0.0.1 -u $$MYSQL_USER --password=$$MYSQL_PASSWORD

Question 5

Якщо ви можете змінити контейнер, дочекавшись готовності mysql, зробіть це.

Якщо у вас немає контролю над контейнером, до якого ви хочете підключити базу даних, спробуйте зачекати на певний порт.

З цією метою я використовую невеликий скрипт, щоб зачекати, поки певний порт буде виставлений іншим контейнером.

У цьому прикладі, MyServer чекатиме порту 3306 від MyDB контейнера досяжним.

# Your database
mydb:
  image: mysql
  ports:
    - "3306:3306"
  volumes:
    - yourDataDir:/var/lib/mysql

# Your server
myserver:
  image: myserver
  ports:
    - "....:...."
  entrypoint: ./wait-for-it.sh mydb:3306 -- ./yourEntryPoint.sh

Ви можете знайти документацію скрипт поживе для щось тут

Question 6

Привіт для простої перевірки стану здоров'я за допомогою docker-compose v2.1 , я використав:

/usr/bin/mysql --user=root --password=rootpasswd --execute \"SHOW DATABASES;\"

В основному він запускає просту mysqlкоманду, SHOW DATABASES;використовуючи як приклад користувача rootз паролем rootpasswd у базі даних.

Якщо команда успішна, db буде готовий, тому шлях перевірки працездатності. Ви можете використовувати intervalтак, щоб він тестував через інтервал

Видаляючи інше поле для видимості, ось як це могло б виглядати у вашому docker-compose.yaml.

version: '2.1'

  services:
    db:
      ... # Other db configuration (image, port, volumes, ...)
      healthcheck:
        test: "/usr/bin/mysql --user=root --password=rootpasswd --execute \"SHOW DATABASES;\""
        interval: 2s
        timeout: 20s
        retries: 10

     app:
       ... # Other app configuration
       depends_on:
         db:
         condition: service_healthy

Question 7

Я змінив файл docker-compose.ymlзгідно з наступним прикладом, і він спрацював.

  mysql:
    image: mysql:5.6
    ports:
      - "3306:3306"
    volumes:       
      # Preload files for data
      - ../schemaAndSeedData:/docker-entrypoint-initdb.d
    environment:
      MYSQL_ROOT_PASSWORD: rootPass
      MYSQL_DATABASE: DefaultDB
      MYSQL_USER: usr
      MYSQL_PASSWORD: usr
    healthcheck:
      test:  mysql --user=root --password=rootPass -e 'Design your own check script ' LastSchema

У моєму випадку ../schemaAndSeedDataмістить декілька схем та даних, що засівають файли sql. Design your own check scriptможе бути подібним до наступного select * from LastSchema.LastDBInsert.

Поки код веб-контейнера був залежним

depends_on:
  mysql:
    condition: service_healthy

Question 8

Додавання оновленого рішення для підходу до перевірки стану здоров’я. Простий фрагмент:

healthcheck:
  test: out=$$(mysqladmin ping -h localhost -P 3306 -u foo --password=bar 2>&1); echo $$out | grep 'mysqld is alive' || { echo $$out; exit 1; }

Пояснення : Оскільки mysqladmin pingповертає помилкові спрацьовування (особливо для неправильного пароля), я зберігаю вихідні дані до тимчасової змінної, а потім використовую grepдля пошуку очікуваного результату ( mysqld is alive). Якщо знайдено, він поверне код помилки 0. Якщо його не знайдено, я друкую ціле повідомлення та повертаю код помилки 1.

Розширений опис:

version: "3.8"
services:
  db:
    image: linuxserver/mariadb
    environment:
      - FILE__MYSQL_ROOT_PASSWORD=/run/secrets/mysql_root_password
      - FILE__MYSQL_PASSWORD=/run/secrets/mysql_password
    secrets:
      - mysql_root_password
      - mysql_password
    healthcheck:
      test: out=$$(mysqladmin ping -h localhost -P 3306 -u root --password=$$(cat $${FILE__MYSQL_ROOT_PASSWORD}) 2>&1); echo $$out | grep 'mysqld is alive' || { echo $$out; exit 1; }

secrets:
  mysql_root_password:
    file: ${SECRETSDIR}/mysql_root_password
  mysql_password:
    file: ${SECRETSDIR}/mysql_password

Пояснення : Я використовую секрети docker замість змінних env (але цього можна досягти і за допомогою звичайних env vars). Використання $$є для буквального $знака, який позбавляється при передачі в контейнер.

Результати з docker inspect --format "{{json .State.Health }}" db | jqрізних випадків:

Все добре:

{
  "Status": "healthy",
  "FailingStreak": 0,
  "Log": [
    {
    {
      "Start": "2020-07-20T01:03:02.326287492+03:00",
      "End": "2020-07-20T01:03:02.915911035+03:00",
      "ExitCode": 0,
      "Output": "mysqld is alive\n"
    }
  ]
}

БД ще не встановлений:

{
  "Status": "starting",
  "FailingStreak": 1,
  "Log": [
    {
      "Start": "2020-07-20T01:02:58.816483336+03:00",
      "End": "2020-07-20T01:02:59.401765146+03:00",
      "ExitCode": 1,
      "Output": "\u0007mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 \"No such file or directory\")' Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!\n"
    }
  ]
}

Неправильний пароль:

{
  "Status": "unhealthy",
  "FailingStreak": 13,
  "Log": [
    {
      "Start": "2020-07-20T00:56:34.303714097+03:00",
      "End": "2020-07-20T00:56:34.845972979+03:00",
      "ExitCode": 1,
      "Output": "\u0007mysqladmin: connect to server at 'localhost' failed error: 'Access denied for user 'root'@'localhost' (using password: YES)'\n"
    }
  ]
}

Question 9

У мене була та сама проблема, я створив для цього зовнішній скрипт bash (натхненний відповіддю Максима). Замініть mysql-container-nameна ім'я вашого контейнера MySQL, а також потрібен пароль / користувач:

bin / wait-for-mysql.sh :

#!/bin/sh
until docker container exec -it mysql-container-name mysqladmin ping -P 3306 -proot | grep "mysqld is alive" ; do
  >&2 echo "MySQL is unavailable - waiting for it... 😴"
  sleep 1
done

У своєму MakeFile я викликаю цей сценарій відразу після мого docker-composeвиклику:

wait-for-mysql: ## Wait for MySQL to be ready
    bin/wait-for-mysql.sh

run: up wait-for-mysql reload serve ## Start everything...

Тоді я можу викликати інші команди, не маючи помилки:

У драйвері стався виняток: SQLSTATE [HY000] [2006] Сервер MySQL зник

Приклад виходу:

docker-compose -f docker-compose.yaml up -d
Creating network "strangebuzzcom_default" with the default driver
Creating sb-elasticsearch ... done
Creating sb-redis              ... done
Creating sb-db                 ... done
Creating sb-app                ... done
Creating sb-kibana             ... done
Creating sb-elasticsearch-head ... done
Creating sb-adminer            ... done
bin/wait-for-mysql.sh
MySQL is unavailable - waiting for it... 😴
MySQL is unavailable - waiting for it... 😴
MySQL is unavailable - waiting for it... 😴
MySQL is unavailable - waiting for it... 😴
MySQL is unavailable - waiting for it... 😴
MySQL is unavailable - waiting for it... 😴
MySQL is unavailable - waiting for it... 😴
MySQL is unavailable - waiting for it... 😴
mysqld is alive
php bin/console doctrine:cache:clear-metadata
// Clearing all Metadata cache entries
[OK] Successfully deleted cache entries.

Я видалив перевірку стану здоров’я, оскільки при такому підході це марно.

Question 10

ПЕРЕЗАПУСК ПРИ ПОМИЛКІ

Оскільки v3 condition: service_healthyбільше не доступний. Ідея полягає в тому, що розробник повинен впровадити механізм відновлення збоїв у самому додатку. Однак для простих випадків використання простим способом вирішення цієї проблеми є використання restartопції.

Якщо статус служби mysql викликає вашу програму, exited with code 1ви можете використовувати один із restartдоступних варіантів політики. наприклад,on-failure

version: "3"

services:

    app:
      ...
      depends_on:
        - db:
      restart: on-failure