GoProg

 
Топ хэштегов


Архив

Методология 12 факторов представляет собой популярный набор принципов созда­ния облачных приложений, составленный разработчиками облачной платформы Heroku и формленная в виде манифеста.

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

Давайте теперь рассмотрим, эти самые факторы:

1. Кодовая база

Весь код приложения должен быть в системе контроля версий. И разворачиваться для разработки, тестирования и на рабочих серверах из одного репозитория. Что впрочем, не исключает, что в развертываниях может быть код в различных ветках, которые еще не добавлены в релиз.

II. Зависимости

Приложения не должны иметь неявных зависимостей. Во-первых, все зависимости как системные, так и библиотеки должны быть прописаны в манифесте зависимостей. Все современные языки предоставляю менеджер пакетов с манифестом зависимостей. Кроме этого зависимости должны быть изолированные, чтобы системная библиотека «не просочилась» в приложений.

Для реализации данного фактора используются такие средства как gradle, maven, npm, bower и т. п. в зависимости от используемых языков программирования.

III. Конфигурация

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

Если вы можете опубликовать свой код в открытый доступ без компрометации персональных учетных записей – вы все делаете правильно.

IV. Сторонние сервисы

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

V. Сборка, релиз, выполнение

Каждый этап сборки, создания артефактов релиза и развертывания контура должны быть разделены и описаны в конфигурации и файлах сценариев.

VI. Процессы

Приложение должно запускать как один или несколько процессов, которые не сохраняют свое внутреннее состояние. Приложение может использовать данные в оперативной памяти или на диске как временное хранилище.

Для сохранения состояния должна использоваться либо внешняя БД, либо кэш. Иначе, если какой-либо компонент сохраняет в себе состояние, то это приводит к невозможности масштабирования данного компонента

VII. Привязка портов

Компоненты системы публикуют свои сервисы, доступные другим компонентам и внешним системам используя порты TCP/IP и простые протоколы взаимодействия (HTTP, gRPC, WebSockets). При этом компоненты создаются как полностью автономные приложения и не требуют наличия внешнего окружения или программного обеспечения.

VIII. Параллелизм

Правильно разработанная с помощью 12 факторов система поддерживает горизонтальное масштабирование просто добавлением аналогичного экземпляра компонента системы. Задача распределения нагрузки решается либо внешним компонентом (например, Kubernetes) либо с использованием компонента, который является частью системы.

IX. Утилизируемость

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

X. Паритет разработки/работы приложения

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

Результатом этого является уменьшения количества ошибок при переносе новой функциональности на тестовые и промышленные контуры.

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

Также использования технологии контейнеризации (Docker) позволяет запускать одинаковые внешние компоненты как в разработке, так и на промышленном контуре.

XI. Журналирование (логирование)

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

Журналы должны быть внешними артефактами конкретного контура системы. Желательно настройка компонентов системы с перенаправлением журналов на систему агрегации логов (ELK, Splunk).

XII. Задачи администрирования

Разовые процессы администрирования (миграции, исправления базы) должны подчиняться тем же правилам, что и остальные процессы.

#12факторов #IT #методология #разработка #системныйдизайн



Новый комментарий: