--- aliases: - двенадцатифакторное приложение tags: - maturity/🌱 - content/experience date: 2024-12-08 --- **Двенадцатифакторное приложение (12-Factor App)** — это методология разработки приложений, предложенная инженерами Heroku. Она описывает набор из 12 принципов, которые помогают создавать программное обеспечение, подходящее для облачных сред. Основные цели этой методологии: - Простое масштабирование. - Портативность между средами. - Упрощение разработки и развертывания. Эти принципы применимы ко всем видам приложений, но особенно полезны для веб-приложений и микросервисов. **Принципы двенадцатифакторного приложения** **Единая кодовая база** должна управляться в системе контроля версий и использоваться во всех средах. Все ветки и деплойменты одного микросервиса привязаны к одному репозиторию. Не должно быть такого, чтобы на один стенд деплой происходил из одного репозитория, а на другой из другого. > Думал, а как можно нарушить этот принцип. И вспомнил случай. После переименования сервиса в GitLab пришлось сделать для одного стенда форк репозитория, чтобы собраться со старым названием для фикса. Это было связано с тем, что все стенды зависели от названия репозитория, поэтому было невозможно переименовать сервис только для одного стенда. **Зависимости**. Явное объявление и изоляция зависимостей. Используйте менеджеры зависимостей. **Конфигурация**. Храните конфигурацию отдельно от кода. Используйте переменные окружения для настройки среды. Пример: URL базы данных, секреты или ключи API задаются через ENV, а не в коде. **Внешние ресурсы**. Базы данных, очереди, файловые хранилища рассматриваются как прикрепляемые ресурсы. Пример: База данных PostgreSQL или очередь RabbitMQ могут быть заменены без изменения кода. **Сборка, выпуск, выполнение**. Четкое разделение стадий: сборка приложения, создание релиза и его выполнение. **Процессы**. Приложение должно быть построено из одного или нескольких независимых процессов. Каждый процесс приложения отвечает за свою задачу (например, обработка HTTP-запросов, фоновые задания). **Stateless**. Приложение не должно хранить данные или состояние внутри процессов. Все состояния хранятся во внешних ресурсах. Пример: Сессии пользователей сохраняются в Redis, а не в оперативной памяти приложения. Если процесс падает или перезапускается, состояние не теряется, так как оно хранится в Redis, базе данных или другой внешней системе. **Привязка портов**. Приложение экспортирует HTTP (или другой) сервис через привязанный порт. **Параллелизм**. Процессы должны быть разделены на масштабируемые модули. **Среда разработки = среда продакшена**. Минимизируйте различия между стендами разработки и продакшеном. **Журналирование**. Приложение пишет события в поток вывода (stdout), а обработкой логов занимается внешняя система. Пример: Логи собираются через Elasticsearch или Datadog. **Административные задачи**. Запускайте административные задачи, такие как миграции базы данных, вместе с запуском сервиса. *** ## Мета информация **Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]] **Родитель**:: **Источник**:: **Создана**:: [[2024-12-08]] **Автор**:: ### Дополнительные материалы - ### Дочерние заметки