Struchkov Mark
ffd249fc10
All checks were successful
continuous-integration/drone/push Build is passing
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) -->
|
||
|