nix

Плюсы: сообщество любит именно эти образы, как "оригинальные". При этом например 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?

четверг, 25 мая 2023 г.

gitlab cicd + telegram

Можно взять готовое, вроде интересное

https://hub.docker.com/r/upagge/gitlab-telegram-notify

Можно взять яндекс хостинг и поднять на serverless технологиях

https://cloud.yandex.ru/docs/tutorials/serverless/telegram-bot-serverless

Как получить chat_id и опционально thread_id, чтобы послать туда сообщение?

1) https://api.telegram.org/bot<YourBOTToken>/getUpdates

Не сработает, если уже где-то развернули бота с вебхуком, будет

{"ok":false,"error_code":409,"description":"Conflict: can't use getUpdates method while webhook is active; use deleteWebhook to delete the webhook first"}

2) в нужном чате копируем ссылку на сообщение, будет типа https://t.me/c/1234567890/4/5 - большое число (добавить минус в начало) это ид чата, второе - тред, третье - номер сообщения и нам не важно. Если тредов нет то среднего числа не будет.

3) всякие боты типа https://t.me/getmyid_bot - но там нужна всякая магия, треды оно не умеет итд.

Делаем тестовую отправку

curl -X POST -H "Content-Type: application/json" -d "{\"chat_id\": \"<YourGroupID>\", \"text\": \"===ТЕСТ===\"}" https://api.telegram.org/bot<YourBOTToken>/sendMessage

Если нужно в тред (топик) то после значения чата в chat_id добавляем

\"message_thread_id\": \"<THREAD>\",

И тут прикол: офдока содержит кривое поле top_msg_id, а message_thread_id там вообще нет:

https://core.telegram.org/method/messages.sendMessage

Вот с таким Г нам приходится работать, что гугл точнее чем офдока. Печалька.

ЗЫ оба поля проверены, первое не работает, второе работает...

воскресенье, 21 мая 2023 г.

ansible: некоторые особенности with_fileglob

Типовое применение: из templates/nginx/sites-available/ нужно скопировать с заменой переменных ряд конфигов. Вариант "в лоб":

- name: install sites
   template:
     src: "{{ item }}"
     dest: "/etc/nginx/sites-enabled/{{ item }}"
   with_items:
     - nginx/sites-available/site1.conf
     - nginx/sites-available/site2.conf

Дальше »

среда, 17 мая 2023 г.

ssh виды ключей

а что выбрать? Можно по привычке просто ssh-keygen, но будет создан id_rsa с длиной ключа 1024, что в современном мире откровенно мало.

ssh-keygen -b 4096 - и это будет работать и будет достаточно безопасно. Но что такое остальные виды?

Сразу про -sk: это security key, для FIDO/U2F (например YubiKey)

EC* ключи - основаны на эллиптических кривых

https://habr.com/ru/articles/335906/

ecdsa (elliptic curve dsa) это очень небольшой ключ, основанный на эллиптических кривых, но при этом более безопасный чем обычный -t rsa -n 1024

Как я понимаю, ed25519 по надёжности как ecdsa, но более быстый:

https://security.stackexchange.com/questions/50878/ecdsa-vs-ecdh-vs-ed25519-vs-curve25519

https://latacora.singles/2018/04/03/cryptographic-right-answers.html

Итог: лучше всего взять ed25519

вторник, 16 мая 2023 г.

sentry

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

Можно воспользоваться как облачным решением с шансом что удалят инстанс, лимитами по интенсивности, месту итд.

Можно поднять на своём сервере, примерно так

https://develop.sentry.dev/self-hosted/

будет собран набор докер образов, доступ через порт 9000.

Дальше »

понедельник, 15 мая 2023 г.

How to find your IP address in Linux

https://opensource.com/article/18/5/how-find-ip-address-linux

curl ifconfig.me

curl -4/-6 icanhazip.com

curl ipinfo.io/ip

curl api.ipify.org

curl checkip.dyndns.org

dig +short myip.opendns.com @resolver1.opendns.com

host myip.opendns.com resolver1.opendns.com

curl ident.me

curl bot.whatismyipaddress.com

curl ipecho.net/plain

воскресенье, 14 мая 2023 г.

частые проблемы при смене версии mysql

Первым делом проверять:

sql_mode (тут вообще разброд и шатание, самое простое но не очень правильное делать sql_mode = "")

innodb_strict_mode - та же мария 10.1 - офф, 10.5 - он. Выставляется

[mysqld]

innodb_strict_mode = OFF

https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-innodb/

суббота, 6 мая 2023 г.

Ansible Role: Raspberry Pi (geerlingguy)

Ansible Role: Raspberry Pi

https://galaxy.ansible.com/geerlingguy/raspberry-pi

вторник, 2 мая 2023 г.

Методы обновления сертификатов lets encrypt (certbot)

Классика:

certbot renew

но есть и готовый сервис

systemctl status certbot.timer

...

Triggers: ● certbot.service

systemctl status certbot

○ certbot.service - Certbot

Loaded: loaded (/lib/systemd/system/certbot.service; static)

Active: inactive (dead) since Tue 2023-05-02 13:11:37 MSK; 1s ago

TriggeredBy: ● certbot.timer

Сервис, запускаемый по таймеру и обновляющий сертификаты.

Но нужно проверять: бывает что certbot renew работает, а сервис завершается с ошибкой.

PS можно доработать сервис (edit --full) и добавить в Exec в конец

--post-hook "nginx -t && systemctl reload nginx"

тогда не надо ничего придумывать с перезапуском nginx. При необходимости заменить на нужный сервис.

воскресенье, 23 апреля 2023 г.

rsync со сменой юзера

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

rsync -avz --rsync-path="sudo rsync" from to

Важное замечание, для корректной работы юзеру которым вошли нужно прописать NOPASSWD в sudoers

Если требуется работать без NOPASSWD то есть несколько вариантов ниже (не проверялось)

https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

среда, 19 апреля 2023 г.

Довольно полное описание для nginx vts

https://nginx-extras.getpagespeed.com/modules/vts/

четверг, 29 июня 2023 г.

понедельник, 26 июня 2023 г.

среда, 21 июня 2023 г.

суббота, 10 июня 2023 г.

четверг, 8 июня 2023 г.

четверг, 25 мая 2023 г.

воскресенье, 21 мая 2023 г.

среда, 17 мая 2023 г.

вторник, 16 мая 2023 г.

понедельник, 15 мая 2023 г.

воскресенье, 14 мая 2023 г.

суббота, 6 мая 2023 г.

вторник, 2 мая 2023 г.

воскресенье, 23 апреля 2023 г.

среда, 19 апреля 2023 г.

четверг, 29 июня 2023 г.

понедельник, 26 июня 2023 г.

среда, 21 июня 2023 г.

суббота, 10 июня 2023 г.

четверг, 8 июня 2023 г.