Git → Git-хуки
Решил на днях починить автотесты в админке этого блога и в процессе их восстановления начал обнаруживать и баги, которые появились с тех пор, как тесты были заброшены, включая и недавние изменения. Не то, что бы и баги, здесь не так много функциональности, чтобы поломка прошла незамеченной, скорее некорректное поведение системы, вроде неправильного часового пояса в контейнере приложения и т.п.
Чтобы обойтись без внешних CI-сервисов, решил запускать тесты локально перед каждый пушем, автоматически, для чего в системе контроля версий Git предусмотрены хуки, ниже как раз приведён пример подобного pre-push хука (в папке .git/hooks их на разные случаи жизни):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | #!/usr/bin/env bash
echo -e "Start pre-push hook\n"
docker compose run --rm --remove-orphans -T rhinoceros bash -c "bin/phpspec run"
retVal=$?
if [ $retVal -ne 0 ]; then
echo -e "\e[31m phpspec error\e[0m\n"
exit 1
else
echo -e "\e[32m phpspec OK\e[0m\n"
fi
exit 0
|
News → Переехал в контейнер :)
Спустя почти год моей моральной подготовки контейнерная революция докатилась и до этого бложика. Хотя в разработке docker использую как раз таки этот самый год, крайне удобная штука, теперь вообще любой новый проект делаю только с ним.
Пришлось немного подумать кроне. Варианта виделось три:
- Залепить крон в тот же контейнер, где крутится веб-приложение. А вебсервер и процесс крона запускать через supervisord, как делают некоторые (раз и два). Но это как-то не docker way, поэтому не захотелось :)
- Отдельный контейнер, где бы жил и крутился крон. Этот вариант делать не стал из-за перерасхода ресурсов, пусть и минимального.
- И третий вариант, который прижился. Просто запускаю docker run из хост-системы её же кроном. Прекрасно работает :)
Вроде такого:
1 | /usr/local/bin/docker-compose -f /path/to/docker-compose.yml run --rm myweb /path/to/cronscript
|
Docker → Подключение к локальному PostgreSQL из Docker-контейнера
Это будет запись близнец к предыдущему посту :)
Для начала определяем IP, к которому будем подключаться из контейнера:
1 | ip addr show
|
Смотрим, находим, запоминаем. Далее настроим PostgreSQL. Для начала в /etc/postgresql/9.3/main/postgresql.conf (путь в конфигам может быть и другой, в зависимости от версии БД и дистрибутива вашего линукса, или что вы там используете) находим и редактируем директиву listen_addresses, чтобы сервер БД прослушивал все адреса, а не только localhost:
1 2 | # /etc/postgresql/9.3/main/postgresql.conf
listen_addresses = '*'
|
Далее разрешим пользователю из докера подключаться в БД. Для этого необходимо добавить строку в /etc/postgresql/9.3/main/pg_hba.conf:
1 2 | # /etc/postgresql/9.3/main/pg_hba.conf
host all all 0.0.0.0/0 password
|
И напоследок создадим базу данных и пользователя:
1 2 3 4 5 6 | CREATE DATABASE pupkin_db;
CREATE USER pupkin WITH password 'qwerty';
GRANT ALL privileges ON DATABASE pupkin_db TO pupkin;
-- добавим возможность создавать базы данных
ALTER ROLE pupkin CREATEDB;
|
Готово.
Docker → Подключение к локальному MySQL из Docker-контейнера
Если возникнет необходимость подключиться из докер-контейнера к серверу MySQL, установленному на хост-машине, то сделать это можно следующим образом. Для начала определяем IP-адрес хоста:
1 | ip addr show
|
Выбираем из появившейся кучи букв и цифр искомый адрес. У меня получилось, к примеру, 192.168.1.176. К нему и будем подключаться из докера. Адрес желательно иметь фиксированный, чтобы не менять его в настройках подключения от перезагрузки к перезагрузке, у себя привязку IP к MAC-адресу сделал сто лет в настройках роутера.
Далее поднастроим MySQL. Для начала в /etc/mysql/my.cnf находим и редактируем директиву bind-address, чтобы сервер БД прослушивал все адреса, а не только localhost:
1 2 | # /etc/mysql/my.cnf
bind-address = 0.0.0.0
|
И создадим базу данных и пользователя, который будет подключаться из докера:
1 2 3 4 5 6 | CREATE DATABASE pupkin_db;
CREATE USER pupkin IDENTIFIED BY 'secret_password';
GRANT ALL PRIVILEGES ON pupkin_db.* TO pupkin;
-- сразу обновим права доступа
FLUSH PRIVILEGES;
|
Готово 🙂
А если используется MySQL 8, в котором по умолчанию используется метод аутентификации caching_sha2_password и приложение такой не поддерживает, например не самые свежайшие PHP, то чтобы не наблюдать ошибки вроде SQLSTATE[HY000] [2054] The server requested authentication method unknown to the client необходимо сменить метод аутентификации на более старый:
1 | ALTER USER pupkin IDENTIFIED WITH mysql_native_password BY 'secret_password';
|