Есть много опенсорсных разработок, которые подходят для установки на VPS. Среди них универсальные решения вроде b1gMail, который работает на любом дистрибутиве и может интегрироваться с Postfix. Или emailwiz — баш-скрипт для полной автоматизации установки серверов Postfix/Dovecot/SpamAssassin/OpenDKIM на Debian. Есть и готовые контейнеры с конфигами, как docker-mailserver, там уже всё настроено.

Kubernetes-операторы давно стали привычным инструментом автоматизации и управления сложными системами. Однако на практике их поведение далеко не такое предсказуемое, как в примерах из документации. Небольшие отклонения в логике цикла согласования, обработке ошибок или обновлении статуса быстро превращаются в зацикливание, дублирование ресурсов и прочие сюрпризы, которые трудно отладить. Новичкам полезно понимать, почему так происходит, а опытным разработчикам — помнить, какие принципы стоит держать в голове при проектировании оператора.

apt-get update
sudo !!

diff <(sort a.txt) <(sort b.txt)sort a.txt) <(sort b.txt)

{ echo "starting job"; date; run_job; } >run.log 2>&1echo "starting job"; date; run_job; } >run.log 2>&1

cut -d',' -f1,4 users.csv | tr ',' '\t' | column -t

systemctl list-unit-files --type=service --state=enabled

При анализе артефактов с Linux систем journal являются источником огромного количества полезной информации. Из журналов можно достать:

🚀 название машины;

🚀 идентификатор события;

🚀 тип события;

🚀 критичность события;

🚀 сообщение;

🚀 объект породивший событие;

🚀 и многое другое.

Существует множество утилит которые позволяют парсить журналы:

🚀 встроенный во многие дистрибутивы linux journalctl;

🚀 кроссплатформенный go-journalctl от Velocidex;

🚀 библиотека go-systemd;

🚀 и т.д.

Однако, у всех этих утилит есть свои минусы. Так go-systemd и journalctl не имеют встроенной кроссплатформенности, а go-journalctl не может парсить все файлы находящиеся в директории рекурсивно.

Нашему веб-серверу Angie исполнилось три года. Становится хорошей традицией, что к этой дате выходит текст, в котором мы — основатели Angie Software — описываем, как прожили последний год, немного говорим про состояние опенсорс проекта и его места в отрасли и мире. Надеемся, что и в этой простыне вы найдете для себя много чего интересного.

В прошлом году текст «Два года Angie», кажется, вам понравился. В нем мы более-менее подробно писали о том, как именно создавалась компания Angie Software, почему вообще мы стартовали с опенсорса, какую роль в появлении Angie сыграли китайские товарищи, и как мы, сообразив, что заработать на опенсорс проекте мы не можем, стремительно переобулись в сторону производства целой линейки продуктов. Ну и еще немного плевались в сторону F5, которая вымарала наших коллег из истории Nginx. Кому интересно, как все начиналось, почитайте.

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

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

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