58 lines
5.7 KiB
Markdown
58 lines
5.7 KiB
Markdown
|
---
|
|||
|
|
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]]
|
|||
|
|
**Автор**::
|
|||
|
|
### Дополнительные материалы
|
|||
|
|
-
|
|||
|
|
|
|||
|
|
### Дочерние заметки
|
|||
|
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
|||
|
|
|