Эта статья была спонсирована AppFog . Спасибо за поддержку спонсоров, которые делают возможным использование SitePoint.
В современном мире SaaS-продуктов появилась общая методология с целью обеспечения структуры для построения хорошо структурированных и масштабируемых приложений. Она называется методологией «12-факторное приложение» и собирается изменить подход к архитектуре вашего следующего приложения.
Если у вас был большой опыт развертывания приложений, вы, возможно, хорошо знаете, что процесс развертывания может быть сложным и обширным, если не сказать больше. Виртуализация, сетевое взаимодействие и настройка сред выполнения — это лишь некоторые из проблем, с которыми приходится сталкиваться. Методология 12-факторного приложения не устраняет всю сложность в целом, но она создает основу для организации процесса с целью поддержания работоспособного и масштабируемого приложения.
Но как следует обрабатывать эти сложные архитектурные требования таким образом, чтобы каждый из принципов 12-факторного приложения мог быть удовлетворен? В следующих параграфах объясняется, как вы можете соответствовать стандартам методологии 12-факторного приложения, в то же время легко преодолевая сложные реальности, связанные с инфраструктурой приложения и настройкой развертывания.
Ключевым инструментом в этом процессе является AppFog, продукт Platform-as-a-Service, предлагаемый CenturyLink Cloud, который позволяет разработчикам приложений создавать программное обеспечение без необходимости фокусироваться на инфраструктуре.
12 факторов
Как видно из названия, методология 12-факторного приложения представляет собой список принципов, каждый из которых объясняет идеальный способ обработки подмножества вашего приложения. 12 факторов следующие:
1. Кодовая база — одна кодовая база отслеживается в контроле версий, многие развертывается
Первый принцип методологии 12-факторного приложения связан с базой кода вашего приложения. Наиболее важным моментом здесь является обеспечение того, чтобы ваше приложение отслеживалось с помощью контроля версий, и чтобы оно находилось в центральном хранилище, доступном для ваших разработчиков. Чаще всего это делается с помощью Git или SVN для хранения вашего кода.
2. Зависимости — явно объявлять и изолировать зависимости
Там нет места для предположений, когда дело доходит до зависимостей. Все, что ваши приложения используют для запуска, должно контролироваться и управляться так, чтобы минимизировать — если не полностью устранить — конфликты.
3. Конфигурация — сохранение конфигурации в среде
Конфигурация, связанная с ключами API, службами и учетными данными базы данных, никогда не должна быть жестко закодирована. Это предотвращает риск для вашего приложения из-за утечек производственных данных и производственных ошибок. Вместо того, чтобы жестко кодировать эту информацию, используйте переменные среды для обработки этой конфиденциальной информации.
4. Службы поддержки — относитесь к службам поддержки как к прикрепленным ресурсам.
Служба поддержки — это та, для работы которой требуется сетевое соединение. Это очень популярная парадигма в современной разработке приложений, особенно распространенная с ростом популярности микросервисной архитектуры. Методология 12-факторного приложения рекомендует разработчикам относиться к этим сервисам независимо, что означает, что изменения или модификации должны происходить без внесения каких-либо изменений в код.
Как правило, этот фактор лучше всего обрабатывается путем вызова каждой резервной службы через API с учетными данными, хранящимися в файле конфигурации, который находится в вашей среде выполнения.
5. Сборка, выпуск, запуск — строго разделить этапы сборки и запуска
Этапы сборки, выпуска и запуска должны рассматриваться как полностью отличные друг от друга. Автоматизация и инструменты помогут упростить этот принцип.
Это может быть достигнуто с помощью существующих инструментов, чтобы полностью автоматизировать процесс сборки. Такой инструмент, как Github, можно использовать для маркировки вашей последней сборки, а Jenkins — для автоматизации этапа выпуска.
6. Процессы — Запустите приложение как один или несколько процессов без сохранения состояния.
Приложения без состояния предназначены для постепенного ухудшения. Это означает, что если зависимость не удается, само приложение не становится отказом. Отдельные точки отказа могут быть трудными, но не невозможными, чтобы избежать. Методология 12-факторного приложения рекомендует хранить данные вне выполняемого кода, чтобы избежать операционных проблем и отладки ночных кошмаров.
7. Привязка порта — Экспорт услуг через привязку порта
Все сервисы приложений должны быть доступны через URL. Для веб-приложений этот процесс происходит автоматически. Это позволяет 12-факторным приложениям быть полностью автономными, избегая необходимости полагаться на различные методы внедрения времени выполнения для создания веб-служб.
8. Параллельность — масштабирование через модель процесса
Каждый процесс в вашем заявлении должен рассматриваться как первоклассный гражданин. Это означает, что каждый процесс должен иметь возможность масштабировать, перезапускать или клонировать себя при необходимости. Такой подход улучшит устойчивость и масштабируемость вашего приложения в целом.
9. Одноразовость — максимальная надежность благодаря быстрому запуску и плавному выключению
Как отмечалось в предыдущем факторе, обращение с процессами как с первоклассными гражданами означает более легкий процесс запуска и завершения работы. Сравните это с приложением, в котором все процессы объединены вместе, где процессы запуска и завершения могут занимать до нескольких минут в зависимости от их размера.
Чтобы обеспечить бесперебойную работу процессов запуска и завершения работы, воспользуйтесь проверенными и надежными услугами, оптимизированными по скорости и производительности. Базы данных и кэши, такие как RabbitMQ, Redis, Memcached и собственный Orchestrate CenturyLink, — это всего лишь несколько сервисов, которые созданы, чтобы помочь с этим фактором.
10. Dev / prod Parity — Делайте разработку, постановку и производство как можно более схожими
Последовательность является ключом для удовлетворения этого фактора. Когда ваши среды похожи, тестирование и разработка становятся намного проще. Подобные среды означают, что такие области, как стек вашей инфраструктуры, процессы управления конфигурациями, версии программного обеспечения и среды выполнения, а также инструменты развертывания везде одинаковы.
При таком подходе меньшее количество ошибок попадет в вашу производственную среду, поскольку ваши тестовые примеры могут быть применены к данным производственного уровня.
11. Журналы — Рассматривайте журналы как потоки событий.
Ведение журнала важно для отладки и проверки общего состояния вашего приложения. В то же время ваше приложение не должно заботиться о хранении этой информации. Вместо этого эти журналы должны рассматриваться как непрерывный поток, который захватывается и сохраняется отдельной службой.
12. Администрирование процессов — запуск задач администрирования / управления как одноразовых процессов.
Одноразовые административные процессы — это, по сути, задания по сбору данных, которые используются для сбора ключевой информации о вашем приложении. Эта информация понадобится для оценки состояния вашей производственной среды, поэтому важно обеспечить, чтобы эти одноразовые процессы происходили в вашей производственной среде. Таким образом, не может быть никаких расхождений между данными, которые вам нужны, и данными, поступающими из видимого давно работающего производственного приложения.
На сайте методологии 12-факторных приложений каждый из этих факторов связан с разделом, где доступен подробный обзор темы. Хотя впечатляюще видно, насколько хорошо продумана методология 12-фактора, мало информации о том, как именно можно лучше всего настроить инфраструктуру, которая лучше всего справится с такими строгими требованиями.
Но есть способ сделать это эффективно с помощью инструмента, созданного с учетом методологии 12-факторного приложения: AppFog
AppFog, приложения и вы
AppFog — это PaaS, разработанный для предоставления вам инструментов, необходимых для удовлетворения методологии 12-факторного приложения. AppFog управляет сетевыми ресурсами, промежуточным программным обеспечением, операционными системами, виртуализацией, серверами, хранилищем и средой выполнения. Все, что вам нужно сделать, это сосредоточиться на написании кода. AppFog, предлагаемый CenturyLink Cloud, использует универсальную платформу Cloud Foundry с открытым исходным кодом.
Начать работу с AppFog так же просто, как войти в свою панель управления CenturyLink и включить службу AppFog, добавив регион, который определяет, где будет размещаться ваш код. Оттуда вы можете развернуть свое приложение в AppFog, используя CLI Cloud Foundry.
Затем Cloud Foundry управляет средами выполнения, промежуточного программного обеспечения и операционной системы ваших приложений. Кроме того, такие задачи, как балансировка нагрузки, время выполнения приложений и ведение журнала потоковых приложений, абстрагируются от процесса разработки и полностью решаются облачной инфраструктурой, которую предоставляет Cloud Foundry.
Это весь процесс. Как только ваше приложение будет развернуто в AppFog, все ваши проблемы с инфраструктурой пройдены. Теперь вы можете сосредоточиться на кодовой базе приложения.
Связывание AppFog с 12-факторной методологией приложений
Ваша кодовая база, зависимости, конфигурация и сервисы поддержки — это 12-факторные принципы, относящиеся к вашему приложению и его данным. Это означает, что ими лучше всего управлять вами, разработчиком.
Почти все остальное в вашем приложении может быть обработано через AppFog, так как AppFog был создан с учетом методологии 12-факторного приложения. Например, параллелизм, доступность и ведение журнала все управляются AppFog автоматически, как только вы развернули свою кодовую базу. Фактически AppFog управляет всем оборудованием, исправлениями программного обеспечения, обновлениями, физической и программной безопасностью, а также повседневными повседневными операционными задачами.
В то время как некоторые из принципов 12-факторного приложения могут потребовать небольшого количества обдумывания и настройки, большинство из них легко обрабатываются при развертывании приложения в AppFog. AppFog не только упрощает этот процесс, но и предлагает множество документации и поддержки по любым вопросам, которые могут у вас возникнуть. Вы можете найти всю соответствующую документацию в Базе знаний CenturyLink .
Создание 12-факторных приложений может быть сложным процессом, но AppFog сделала большую часть тяжелой работы за вас. Вам остается только написать свой код и развернуть.
Для получения дополнительных ресурсов по 12-факторной методологии приложений и тому, как AppFog облегчает ее, обязательно ознакомьтесь с подробным объяснением AppFog .
Вывод
12-факторная методология приложения — это исключительный проект, который обеспечивает все необходимые шаги для развертывания надежного продукта SaaS. Несмотря на то, что управление всеми этими шагами (и выбор правильных служб, которые делают это) может быть изнурительным, AppFog PaaS делает процесс более плавным, заботясь о таких аспектах вашего приложения, как параллелизм и возможность утилизации, так что вы можете сосредоточиться на написании хорошего кода, который предлагает что-то особенное для ваших пользователей.
Не хотите ли вы сосредоточиться на создании своего приложения и доставлять удовольствие своим клиентам, а AppFog позаботится обо всем остальном?