xelbot.com

Всё. Даже куплена новая тема на themeforest.net. Периодически происходят набеги к новому движку этого блога, который пишется на Golang (с марта 😅).

А вообще, в разные периоды времени, я переделывал свой блог на Python (Django), Phalcon Framework, Clojure (Luminus), Java (Ninja Framework и Spark),Common Lisp (Hunchentoot), Elixir (Phoenix). Но так ни разу и не довёл дело до конца, максимум добирался до пажинатора страниц. Да и на Golang это уже не первая попытка. Но будет последняя. Или сейчас, или уже никогда 💩 Всё равно не веду эти страницы, только за VPS плачу.

Спустя почти год моей моральной подготовки контейнерная революция докатилась и до этого бложика. Хотя в разработке docker использую как раз таки этот самый год, крайне удобная штука, теперь вообще любой новый проект делаю только с ним.

Пришлось немного подумать кроне. Варианта виделось три:

1. Залепить крон в тот же контейнер, где крутится веб-приложение. А вебсервер и процесс крона запускать через supervisord, как делают некоторые (раз и два). Но это как-то не docker way, поэтому не захотелось :)
2. Отдельный контейнер, где бы жил и крутился крон. Этот вариант делать не стал из-за перерасхода ресурсов, пусть и минимального.
3. И третий вариант, который прижился. Просто запускаю docker run из хост-системы её же кроном. Прекрасно работает :)

Вроде такого:

1

/usr/local/bin/docker-compose -f /path/to/docker-compose.yml run --rm myweb /path/to/cronscript

Это будет запись близнец к предыдущему посту :)

Для начала определяем 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;

Готово.

Если возникнет необходимость подключиться из докер-контейнера к серверу 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';

Очередная заметка для самого себя, чтобы не искать. Вроде бы всё до ужаса элементарно, но не запомню, пока не напишу об этом :)

Первым делом добавляем remote-репозиторий, ссылающийся на оригинальный, назовём его, к примеру upstream¹. Список удалённых репозиториев можно посмотреть командой git remote -v, чтобы убедиться, что всё верно.

После вытягиваем все изменения, произошедшие в репозитории upstream² и сливаем их со своим репозиторием³.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# шаг 1

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

# шаг 2

git fetch upstream

# шаг 3

git checkout master
git merge upstream/master