Дима пишет | Дмитрий Смотров: заметки с тегом ОтказоустойчивоеПО

12 факторов. Часть 4

Sun, 14 Sep 2025 22:57:25 +0300

10) Паритет разработки/работы приложения. Держим среду разработки идентичной среде развертывания. Если на проде используется Postgres, то локально мы тоже используем Postgres, никаких SQLite/Oracle/MySQL, иначе вы очень рискуете стать тем самым «а у меня локально все работает» парнем. На моей практике различие версии одной зависимости между стейджем и продом привели к двухнедельному кранчу. Фактор обеспечивает способность непрерывного развертывания приложения за счет минимизации различий между средами разработки и исполнения.
11) Журналирование. Логи как поток событий. Приложение отдает контроль за своими логами на аутсорс стороннему инструментарию(привет ELK, а если точнее, то logstash). Каждый процесс пишет логи в стандартный вывод, а там оно уже как-нибудь «само». Почему? Опять же: для простоты масштабирования. Еще важно подчеркнуть — логи рассматриваются как поток событий(одна строка логов — одно событие системы), из которых формируется журнал. Журнал — это поток агрегированных, упорядоченных по времени событий, собранных из потоков вывода всех запущенных процессов и вспомогательных сервисов. По сути это такой же текстовый файл, но его можно визуализировать для удобства(привет Kibana).
12) Администрирование. Выполняем администрирование в разовых процессах, причем среда выполнения таких процессов идентична среде выполнения всего приложения. К администрированию относится выполнение миграций, запуск разовых скриптов(например пользака с админскими правами создать), и тому подобное. Очень сильно перекликается с 10 пунктом и нужно по тем же причинам: если мы будем запускать приложение в одной среде, а администрировать приложение в другой, мы точно в конечном итоге нарвемся на рассогласование конфигураций. Хранить разовые скрипты рекомендуется рядом с основным кодом приложения.

12 факторов. Часть 3

Thu, 04 Sep 2025 16:42:49 +0300

7) Привязки портов. Сервисы экспортируются через бинд порта — то есть сервис тусит на порту и слушает запросы. Тут камень в огород способа развертывания приложения как дополнительного модуля к веб серверу, существовавшему ранее. Сейчас же будьте добры делать приложение самодостаточным, идущем в комплекте с собственным веб-сервером(который вы объявите в зависимостях), а не подсовывайте сервер извне.
8) Параллельное выполнение команд. И для параллельного выполнения используются процессы. За основу взяли все хорошее из модели Unix процессов + разделение на типы процессов: если сервис будет обрабатывать HTTP-запросы и выполнять задачи в фоне, то сервис должен быть разделен на веб-процесс и процесс фоновых задач. Таким образом, если увеличивается нагрузка на веб-процесс, то мы докидываем дополнительный веб процесс. Аналогично для процесса фоновых задач. На картинке можно наглядно посмотреть. Вот тут пост сооснователя heroku с предложением данной концепции.
9) Утилизируемость. Приложение должно запускаться и останавливать свою работу в любой момент, когда это потребуется. В идеале мы минимизируем время запуска, а процесс завершения делаем безопасным — завершаем текущую сессию с БД, чтобы соединения не текли, завершаем все фоновые задачи, только после этого процесс умирает. Хорошо бы еще добавить устойчивость к внезапной смерти оборудования, но подобное событие считается менее вероятным, чем простое завершение работы по SIGTERM. Весь этот фактор направлен на то, чтобы автомасштабирование работало по принципу «включил/выключил», как свет на кухне: нужно — добавили подов, ненужно — убрали.

12 факторов. Часть 2

Wed, 06 Aug 2025 09:49:43 +0300

Прошлый пост

4) Сторонние службы. Это службы, доступные приложению по сети. База данных, очереди сообщений, кеши — все это сторонние службы и они должны быть *подключаемыми ресурсами*, доступными по URL-адресу, который в свою очередь заносится через параметры конфигурации. В случае, если сервер сторонней службы начинает барахлить, служба переносится на другой сервер и приложению дают URL с новым сервером.
5) Сборка, релиз и выполнение. Жесткое разделение этапов развертывания приложения на сборку(берем код и «компилируем» его: ставим зависимости в окружение; реально компилируем, если ЯП проекта компилируемый), релиз(к «собранной» программе докидываются конфиги) и выполнение(непосредственно запуск программы) позволяет контролировать то, какой код был развернут на сервере с помощью систем контроля релиза(например Jenkins), которые в случае чего позволят откатить релиз и проанализировать проблемный релиз на предмет ошибок.
6) Процессы. Приложение запускается как один, либо как несколько процессов, без сохранения внутреннего состояния(сервис без состояния — *stateless*). Так же между процессами не должно быть разделяемых данных. Это нужно для упрощения горизонтального масштабирования — просто добавь ~~воды~~ еще один процесс. В случае, если у сервиса есть состояние(допустим, он кеш хранит в глобальном словаре), то нужно это состояние распространить и держать согласованным между всеми инстансами приложения. Состояние, если оно у вас есть, должно быть вынесено во внешнюю службу(для нашего примера для кеша использовать Redis/Memcached).

12 факторов. Часть 1

Sun, 03 Aug 2025 21:25:44 +0300

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

Так как появились стандартизированные инструменты, появились и рекомендации для разработки приложений с той целью, чтобы минимизировать проблемы с деплоем с помощью этих инструментов. Рекомендации эти обозвали «12 факторные приложения» или же «12 шагов к куберу».

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

Предлагаю рассмотреть часть пунктов и разберемся чем они полезны.

1) Кодовая база. Одна кодовая база — одно приложение. Кодовая база ведется с помощью системы контроля версий, любой, на ваш вкус. Каждый разработчик в команде работает с одним и тем же кодом(изменения, внесенные разработчиком во время работы не противоречат этому пункту), на серверах запускается этот же код. Представьте, что у вас есть N друзей близняшек, одевающихся почти одинаково. Отличать их друг от друга смогут разве что родители(а смогут ли?).
2) Зависимости. Приложения явно указывает пакеты, которые нужны ему для работы через манифесты декларации зависимостей и менеджер зависимостей. Таким образом мы избегаем ситуаций, когда в одной среде приложение работает корректно, а при запуске на другом компьютере приложение падает из-за отсутствия нужной библиотеки.
3) Конфигурация. Должна подкидываться приложению из переменных окружения. Если вы прибьете гвоздями креды для подключения к БД в коде, а потом поменяете пароль на сервере базы или же переместите базу на другой хост, то без патча в исходном коде приложения вы банально не заведетесь.

В последующих постах пройдемся и по остальным 9 пунктам :)