Оставлю это тут на память. Когда интерес немного перевешивает лень или, скорее, безразличие.

Работы над новым бложиком идут полным ходом. Позавчера вот первый запрос к БД выполнил, например 😏. Такими темпами до конца семилетнего карантина движок и будет как раз закончен. Ну а пока оставлю тут пару скриншотов пиписькомеров, чтобы было куда равняться, потому как показатели новой версии должны быть, как минимум, не хуже.

GTmetrix раз:

И аудит из Chrome DevTools два:

Всё зелёненькое и хорошо. На этом пока всё.

Всё. Даже куплена новая тема на 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 из хост-системы её же кроном. Прекрасно работает :)

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

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

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

Для начала определяем IP, к которому будем подключаться из контейнера:

ip addr show

Смотрим, находим, запоминаем. Далее настроим PostgreSQL. Для начала в /etc/postgresql/9.3/main/postgresql.conf (путь в конфигам может быть и другой, в зависимости от версии БД и дистрибутива вашего линукса, или что вы там используете) находим и редактируем директиву listen_addresses, чтобы сервер БД прослушивал все адреса, а не только localhost:

# /etc/postgresql/9.3/main/postgresql.conf
listen_addresses = '*'

Далее разрешим пользователю из докера подключаться в БД. Для этого необходимо добавить строку в /etc/postgresql/9.3/main/pg_hba.conf:

# /etc/postgresql/9.3/main/pg_hba.conf
host	all	all	0.0.0.0/0	password

И напоследок создадим базу данных и пользователя:

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-адрес хоста:

ip addr show

Выбираем из появившейся кучи букв и цифр искомый адрес. У меня получилось, к примеру, 192.168.1.166. К нему и будем подключаться из докера. Адрес желательно иметь фиксированный, чтобы не менять его в настройках подключения от перезагрузки к перезагрузке, у себя привязку IP к MAC-адресу сделал сто лет в настройках роутера.

Далее поднастроим MySQL. Для начала в /etc/mysql/my.cnf находим и редактируем директиву bind-address, чтобы сервер БД прослушивал все адреса, а не только localhost:

# /etc/mysql/my.cnf
bind-address = 0.0.0.0

И создадим базу данных и пользователя, который будет подключаться из докера:

CREATE DATABASE pupkin_db;
CREATE USER pupkin IDENTIFIED BY 'secret_password';
GRANT ALL PRIVILEGES ON pupkin_db.* TO pupkin;

-- сразу обновим права доступа
FLUSH PRIVILEGES;

Готово.

Потребовалось как-то обновить на сервере SSL-сертификат, который я и заполучил. Только вот не оказалось ключа шифрования, без которого установить сертификат не представляется возможным. Однако ни о каких ключах клиент и слыхом и не слыхивал, зато скинул какой-то PFX-файл, к ключу и сертификату имеющий непосредственное отношение. Оставалось только извлечь их оттуда.

openssl pkcs12 -in domain.pfx -clcerts -nokeys -out domain.pem
openssl pkcs12 -in domain.pfx -nocerts -nodes -out server.key

Вжух и готово, domain.pem - клиентский сертификат, server.key - ключ шифрования. На вид, конечно, решение простое и так оно и есть, только ему предшествовали часы гугления и борьба с ошибкой вроде "Unable to load Private Key... ANY PRIVATE KEY", я несколько раз даже было усомнился, что искомый ключ в PFX-файле имеется :)

Три месяца уже работаю работником на новой работе, в Zfort Group. В общем и целом всё норм. Есть плюсы и минусы, конечно.

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

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

Вот, собственно, и всё.

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

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

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

# шаг 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

Установил на ноутбук последнюю LTS версию Убунты в экспериментальных целях и был слегка разочарован тем, что не обнаружил в инсталляторе возможность выбора файловой системы F2FS, которая изначально разрабатывалась для flash-памяти и просто доктор прописал использовать её с SSD-накопителями. Однако немного поразмыслил и решил поместить домашнюю директорию на отдельный раздел с F2FS, ведь почти все мои файлы и манипуляции с ними происходят именно в этой папке.

Для начала нужно загрузиться с LiveCD, или, скорее, с LiveUSB, и отбить свободное место от основного корневого раздела, если это не было сделано при инсталляции. Делается довольно просто с использованием того же GParted. Сразу отформатировать в F2FS, скорее всего, не получится. Я оставил раздел неотформатированным. После перезагружаемся обратно в установленную Ubuntu.