Ещё один MQ?

Выбор MQ для высоконагруженного проекта

Брокер сообщений NATS: как мы решали проблему скоростной и стабильной доставки сообщений

https://docs.nats.io/

gitlab: The pipeline failed due to the user not being verified

https://about.gitlab.com/blog/2021/05/17/prevent-crypto-mining-abuse/

the team member will need to validate their account or alternatively you can disable shared runners in the related projects.

python: logging

 Очень неплохое видео про "особенности" модуля logging

https://www.youtube.com/watch?v=qqdgynJ5ATU&list=PLlWXhlUMyooYC3js8JEdQk4kYD1cnSaWo&index=2

Интересно было бы и остальные видео увидеть..

PS https://boosty.to/omolchanov/posts/20b11a20-1b42-415e-b93d-2b9d0104e023

telegram+mint

Даже в свежем минте ставится очень старая версия 3.6.1+ds-2build1, и автообновление не работает. Удалим

apt remove telegram-desktop

Поставим нормальную версию

sudo add-apt-repository ppa:atareao/telegram

sudo apt update && sudo apt install -y telegram

Docker + php - что брать за основу?

 Из-за ряда особенностей alpine тут не лучший выбор (и см ниже), хотя и он будет работать.

1) FROM php:8.2-fpm и вариации

Плюсы: сообщество любит именно эти образы, как "оригинальные". При этом например FROM php:5.4 сам образ скачает, но что-то поставить туда уже не выйдет, всё дропнуто давно (впрочем, пока ещё можно взять centos:7 и там как раз 5.4 штатно, но об этом дальше)

Докерфайл под нужный движок гуглится за несколько минут

Минусы: 

- лютое неудобство писать докерфайлы, потому что какие-то модули уже стоят (mbstring) и попытка их собрать обламывается (нет модуля онигурама), но об этом надо или просто знать, или гуглить, сама установка требует чтения док на тему docker-php-ext-configure + docker-php-ext-install, то есть опять чтения доков что конкретно надо на каждый модуль... Конечно всё решаемо, но можно легко потерять несколько дней на полной ерунде.

- Нагугленные версии файлов часто не собирают, нужно править ошибки, например

docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr --with-webp-dir=/usr 

а потом оказывается что и путь не нужен, и -dir пропадает (--with-png), и один из with в принципе.. Иногда нужно -dev пакетов докидывать и так далее.

А ещё полно таких приколов:

&& git clone -b php7 https://github.com/phpredis/phpredis.git /usr/src/php/ext/redis && docker-php-ext-install redis \ ....

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

2) FROM ubuntu:22.04, вариант debian:11 или вообще centos:7

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

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

Возможность ставить конкретную версию, если оказалось что последняя версия нам что-то ломает, как минимум на время исправления нашего/их кода, возможность сделать фриз нужных пакетов

Минусы: штатно в дистрибутиве есть только одна версия, если нужно другую то нужно подключать того же Ondrej. Но при условии что платформа уже была где-то развёрнута - всё нужное и так известно. И даже нужные модули, собранные руками, просто копируем отдельным шагом и получаем тот же результат.

3) FROM composer:2

Подвид п.1, только на базе alpine, c docker-php-ext-install и подобным. Иногда вылезают косяки с заменой libc.

С другой стороны, очень хороший вариант, если сначала собрали все нужные модули, подготовили vendor/ итд, и потом COPY --from= перенесли только нужное в новый пустой альпин образ. Это будет меньше обычного и достаточно безопасно.

4) брать уже готовые образы, типа FROM octobercms/october-dev, но именно с октобером вообще прикол - у оф образа 4 звезды, а у "левого" aspendigital/octobercms - 41. И что брать? Хотя и тут понятно, у aspendigital последняя версия пхп 7.4, а уже желательно 8.0 и выше.

Итого: попытки поднять вопрос "что брать за основу" по чатам показали, что нет явного преимущества ни у одного метода. Обычно говорили про скорость сборки (вот только компиляция из п.1 конечно "быстрее" чем apt install уже собранного, да), размеры (именно в данном случае итоговый образ обычно выходит больше гигабайта в обоих случаях, и опять же, компилятор со всеми библиотеками никогда не будет занимать меньше места чем минимальная версия дистрибутива, куда сделали apt install --no-install-recommends), безопасность - но никто не смог объяснить в чём тут безопасность.. При этом помним важное правило безопасности - нужно брать именно проверенные слои в прод. И тут первый метод самый слабый, если в случае п.2 мы обнаружили проблему - можем явно указать рабочую версию и пересобрать контейнер, то в п.1 нужно зарываться в гит-версии и прочее, если мы свои промежуточные сборки не версионировали и всё было latest.

А если погрузиться в multi-stage builds, кэширование слоёв и прочее - всё становится ещё сложнее. И опять без какого-то значительного преимущества одного решения.

И я например с давних лет придерживаюсь политики "компиляторов в проде быть не должно", что исключает п.1 для меня. Сильно больше векторов атаки. Впрочем, п.3 при этом весьма неплох, пока нет деплоя в "мульти-окружения", то есть хост+докер, там я выбираю п.2

И да, можно взять php:8.2-alpine, доставить композер и см выше, но смысл если есть п.3?