Запуск рабочих нагрузок в Azure

Что это такое

Рабочая нагрузка в Azure собирается из тех же категорий, что и везде: вычисления (виртуальные машины, контейнеры, функции), хранилище (диски, блобы, управляемые базы данных), сети и платформенные сервисы, которые оборачивают эти три. Отличает сборку то, насколько полно через неё проходит слой идентичности: веб-приложение, его база данных и его секреты доступны только через идентичности, выданные каталогом, поэтому схема разрешений и схема архитектуры — одна и та же картинка.

Почему это важно

Сервисы во многом сопоставимы по возможностям с другими крупными провайдерами, и построчное сравнение редко оказывается решающим. Решает то, сколько окружающего корпоративного парка нагрузка может переиспользовать: конвейер развёртывания, который уже гоняет команда эксплуатации, мониторинг, который уже читает команда безопасности, лицензию, которую уже платит финансовая служба. Изучение сборки ещё и учит общей форме — вычисления плюс состояние плюс идентичность плюс сеть, — так что следующий провайдер оказывается в основном упражнением в словаре.

Ключевые идеи

Управляемая идентичность убирает учётные данные из нагрузки

Нагрузке, которой управляет платформа, можно выдать идентичность каталога, и она будет получать токены без секрета в конфигурации или коде. Следствие: вопрос «где пароль» перестаёт существовать, а ротация учётных данных перестаёт быть задачей. Это тот же принцип, что роли у других провайдеров, выраженный в собственной системе идентичности этой платформы.

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

Группы ресурсов — единица владения

Ресурсы группируют по жизненному циклу, а не по типу: всё, что нужно одному приложению, развёртывается и удаляется вместе. Группа ресурсов становится естественной границей для разрешений, отчётности о затратах и очистки, поэтому смешивание несвязанных ресурсов в одной группе — ошибка, которая затрудняет все три сразу.

Платформа предлагает инфраструктурные и платформенные формы вместе

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

Гибрид — случай первого класса

Azure исходит из того, что часть систем останется на собственных мощностях, и даёт сетевые, идентификационные и управляющие средства, чтобы рассматривать оба парка как один. Для организации в середине миграции это часто и есть настоящий решающий фактор: один каталог управляет сервером в стойке и сервером в регионе, а инструментам всё равно, где он.

Затраты считаются на ресурс и на группу

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

Практика

Соберите одну нагрузку без секрета

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

Готово, когда: вы можете назвать все учётные данные в проекте и показать, что ни одни из них не долгоживущий секрет.

Спланируйте жизненный цикл группы ресурсов

Возьмите небольшое приложение и перечислите всё, что ему нужно, в одной группе ресурсов, затем опишите, что удалит удаление группы.

Готово, когда: в списке нет ресурса, общего с другим приложением, и удаление безопасно по построению.

Частые ошибки

  • Несвязанные ресурсы в одной группе ресурсов — разрешения, затраты и очистку нельзя разграничить; исправить: группируйте по приложению и жизненному циклу.
  • Учётные данные в конфигурации приложения — секреты утекают, а ротация становится проектом; исправить: используйте управляемую идентичность и получайте токены во время работы.
  • Одна подписка на всё — границы сред исчезают, и ошибка в песочнице доходит до продакшена; исправить: разделяйте подписки по средам.
  • Гибрид как временная помеха — миграция буксует без плана по сети и идентичности; исправить: проектируйте соединение осознанно с самого начала.
  • Сравнение сервисов по функциям — решение принимается по несущественной оси; исправить: решайте по парку, а потом выбирайте равноценный сервис.

Что читать дальше