Что нам стоит cloud построить
Тема облачных услуг и облачных сред популярна уже довольно давно. Мы используем облака в своих проектах, арендуем облачные ресурсы. Однако, не все инженеры и архитекторы хорошо знают, что лежит в основе облачных сред.
В этой статье мы рассмотрим облачную основу — модульную и масштабируемую конфигурацию, позволяющую заказчикам использовать облака как своих бизнес‑потребностей.
Рекомендации по построению этой облачной основы, приведенные в статье, базируются на материалах одного западного гиганта облакостроения, но я полагаю, что они будут полезны и при использовании других облачных сред.
Cloud landing zone
Итак, для начала давайте разберемся с так называемыми посадочными зонами (landing zone). Посадочная зона, также называемая облачной основой, представляет собой модульную и масштабируемую конфигурацию, которая позволяет организациям использовать облака для своих бизнес‑потребностей. Посадочная зона часто является необходимым условием для развертывания корпоративных рабочих нагрузок в облачной среде.
Здесь сразу следует отметить, что посадочная зона не имеет никакого отношения к региональному распределению ресурсов. Так, у некоторых облачных провайдеров есть понятия региональных зон, но сегодня мы будем говорить не про это.
С создания посадочной зоны обычно начинается наше взаимодействие с облачным провайдером. Чтобы ее развернуть, необходимо сначала создать ресурс организации и создать биллинговый счет, с которого будет оплачиваться использование ресурсов в облаке. При этом важно помнить, что посадочные зоны динамичны и расширяются по мере того, как ваше предприятие со временем внедряет все больше облачных рабочих нагрузок.
После привязки платежных инструментов мы можем приступать к подготовке инфраструктуры для развертывания наших приложений в облаке. Здесь не стоит пытаться развернуть сразу все модули целевой системы. Так, если первое развертывание нашего приложения не требует доступа к локальным сетевым ресурсам, мы можем подключиться к локальной среде позже.
Однако, важно сразу развернуть все основные элементы, связанные с обеспечением безопасности. Это прежде всего компоненты управления доступом, идентификации и аутентификации. Также, необходимо развернуть те сетевые компоненты, без которых взаимодействие модулей приложения в облачной среде в принципе невозможно.
При этом важно учитывать, что в зависимости от особенностей вашей организации и типа нагрузок, которые вы планируете выполнять в облаке, некоторые рабочие нагрузки могут иметь совершенно другие требования. Например, некоторые рабочие нагрузки могут иметь уникальные требования к масштабируемости или соответствию нормативным требованиям (требования по хранению персональных данных).
В таких случаях для организации может потребоваться несколько посадочных зон: одна зона для размещения большинства нагрузок и отдельная зона для размещения уникальных рабочих нагрузок. Некоторые элементы, такие как идентификаторы, биллинг и организационный ресурс, можно совместно использовать в разных зонах. Однако другие элементы, такие как настройка сети, механизмы развертывания и политики на уровне папок, могут различаться.
Независимо от того, когда вы будете размещать компоненты вашего приложения в облаке, на первой итерации или позже, нам важно понимать какие задачи выполняет каждый из них. Поэтому далее мы рассмотрим подробнее основные элементы нашей посадочной зоны.
Идентификация
Начнем с идентификации. Приложение, размещенное в облаке практически всегда предполагает взаимодействие с большим количеством пользователей и здесь важна надежная система идентификации пользователей.
Конечно, создание собственных «велосипедов» это одно из любимых занятий многих разработчиков, но лучше для идентификации использовать проверенные временем решения от облачных провайдеров. Например, можно воспользоваться теми средствами, которые предлагает Yandex.
Здесь важно определиться с тем, какую модель идентификации вы в принципе хотите использовать. Возможно, в вашей организации уже развернуто какое‑то LDAP решение и в таком случае, возможно лучше использовать его, а не пытаться с болью внедрят ь что‑то новое.
Более сложный случай это, когда мы хотим интегрировать пользовательские аккаунты в облачный сервис идентификации. Типичный пример, это когда в организации уже имеется свой домен AD, но руководство хочет интегрировать все эти аккаунты в облачную систему.
При этом, объединить учетные записи мы можем различными способами. Прежде всего можно выполнить миграцию всех учетных записей. Этот способ хорош, когда мы точно знаем, у кого из наших пользователей должны быть какие права. При таком переносе есть риск того, что после миграции многие могут лишиться своих доступов.
Поэтому, при переносе аккаунтов их обычно мигрируют по частям, разбивая на подмножества. Например, отдельно пользователи с доступом к определенным компонентам, затем с доступом к другим компонентам. В завершении миграции переносятся административные учетные записи.
При таком подходе мы снижаем риск того, что перенеся учетные данные в облачную систему идентификации мы разом лишим доступа большое количество пользователей.
Иерархия ресурсов
При построении иерархии ресурсов в облаке важно учитывать, что все организации разные, не существует единого и оптимального подхода к иерархии ресурсов. Так, не рекомендуется привязывать корпоративную организационную структуру к иерархии ресурсов. Вместо этого сосредоточьтесь на потребностях вашего бизнеса и операциях, выполняемых приложением в облачной среде.
Иерархия ресурсов в облачной среде начинается с корневого узла, который обычно называется организацией. Далее, вы определяете нижние уровни иерархии с помощью папок и проектов, а также создаете папки внутри папок для построения иерархии. Проекты, в которых размещаются рабочие нагрузки, можно создавать на любом уровне иерархии.
На следующей схеме показан корневой узел «Организация» и папки на первом, втором и третьем уровнях. Проекты и вложенные папки создаются в папках второго уровня.
Дизайн сети
Далее мы рассмотрим одну из наиболее важных тем — дизайне сети. Выбор дизайна сети зависит от целого ряда факторов. Но прежде всего нам необходимо определиться с тем, какая модель управления у нас будет использоваться: централизованная или децентрализованная.
Централизованная модель предполагает единую точку контроля над сетью, включая IP‑адресацию, маршрутизацию и межсетевое экранирование между различными рабочими нагрузками.
Децентрализованная модель предоставляет командам большую автономию в управлении собственными средами и самостоятельном создании сетевых элементов в своих средах.
Помимо модели управления, необходимо также определиться с вариантами подключения к нашему облачному приложению. Проще говоря, как пользователи в принципе могут взаимодействовать с нашим приложением.
Конечно, в большинстве случаев, если мы говорим о десктопном приложении, то для взаимодействия скорее всего будет использоваться веб интерфейс. Тогда все относительно просто: в размещаемом в облаке приложении необходимо рассмотреть наличие веб сервера в отказоустойчивой конфигурации.
Но что делать, если для взаимодействия необходимо использовать какие‑то более специфичные протоколы. В таком случае для обеспечения безопасности передаваемых данных может потребоваться развертывание VPN серверов. В простейшем случае, мы можем в облаке развернуть OpenVPN или аналогичное решение. В случае, если требуется сертифицированная криптография, нам потребуются коммерческие решения, имеющие сертификат ФСБ.
Также, продолжая тему безопасности, при планировании сетевой топологии важно учитывать выбранную ранее модель централизации. Так, при централизованной модели весь трафик будет проходить через централизованные сетевые устройства, например NGFW.
В случае, если используется децентрализованная модель, трафик может ходить в облако по различным маршрутам, и здесь уже необходимо, что на каждом из этих маршрутов применялись единые политики контроля доступа.
Также важным условием при построении сетевой топологии является наличие проверок трафика на уровне приложений. В случае, если нам необходима инспекция на L7, необходима топология hub‑and‑spoke. То есть в центре топологии находится NGFW и или аналогичное устройство для проверки трафика, и весь трафик, идущий в или из облака проверяется этим устройством.
Заключение
Современные приложения, размещаемые в облаках, как правило, имеют достаточно сложную архитектуру, и состоят из множества различных компонентов. Поэтому при формировании cloud landing zone важно правильно определиться с основными элементами облачной инфраструктуры, которые будут использоваться для работы вашего приложения. Так как в случае неверного выбора можно столкнуться с ситуацией, когда вы потратите лишние средства на аренду ненужных ресурсов в облаке.
В этой статье мы рассмотрели некоторые основные моменты связанные с использованием облачных ресурсов для размещения приложений. Мы рассмотрели необходимость использования систем идентификации, предлагаемых облачными провайдерами. Также, поговорили о том, как лучше построить сетевую топологию и управлять ресурсами.
Terraform — видимый инструмент для управления инфраструктурой в виде кодом (IaC), который позволяет автоматизировать развертывание, управление и масштабирование облачных ресурсов.
19 марта на открытом уроке в Otus мы разберем, как эффективно использовать Terraform для работы с Яндекс Облаком, минимизируя рутинные операции и повышая надежность работы. Если тема актуальна, записывайтесь по ссылке.
