Что нужно знать и как это реализовать
Это сообщение в блоге - одно из трех технических подробностей об определенном типе архитектуры для бессерверных пакетных заданий на AWS. Основная предпосылка архитектуры заключается в том, что мы хотим использовать управляемые сервисы AWS для выполнения пакетных заданий. Если вы хотите узнать больше об этой архитектуре, перейдите здесь для получения более подробной информации. Общая картина этой архитектуры выглядит так:
Короче говоря, архитектура состоит из одного компонента для разработки и другого для выполнения пакетного задания с помощью триггера Cloudwatch. В этом сообщении блога мы сосредоточимся только на сетевых аспектах этой архитектуры. Также существует публичный репозиторий кода, который позволяет воспроизводить полный сервис и все его части на основе скриптов Cloudformation.
С точки зрения сети, служба Fargate - разновидность Elastic Container Service (ECS) AWS - и ее взаимодействие с Elastic Container Registry (ECR) требует особого внимания. Это два основных требования, которым должна соответствовать сетевая конфигурация:
- Он должен обеспечивать связь между всеми службами, используемыми в этой архитектуре.
- Он должен защищать сервис от несанкционированного доступа. Самое главное, чтобы весь трафик проходил в пределах охраняемого периметра. Открытые двери в Интернет через общедоступные IP-адреса или другими способами недопустимы.
Прежде чем перейти к общей картине сети, давайте начнем с небольшого учебника по скриптам CloudFormation. Если у вас уже есть опыт работы с CloudFormation или аналогичными концепциями, вы можете просмотреть или пропустить следующие три абзаца.
CloudFormation - это разновидность AWS Инфраструктура как код. То есть вы определяете целевую инфраструктуру, отправляете ее в AWS, а AWS подготавливает ее для вас. Вы заказываете свои ресурсы в так называемых стопках. Они позволяют очень легко настраивать, отслеживать или удалять их.
Вы можете писать сценарии CloudFormation в файлах JSON или YAML. Все примеры здесь и в репозитории кода представляют собой файлы YAML, но вы можете сделать то же самое в JSON.
Вам также доступен набор специальных команд CloudFormation. В следующих примерах я использую три из них:
- ! Ref - это внутренняя ссылка; то есть CloudFormation вставляет значение из того же скрипта.
- ! Sub используется для замены переменных в строки.
- ! GetAtt похож на «! Ref», но указывает на конкретный атрибут ресурса, а не на его общую ссылку.
Большая картинка
Вот обзор компонентов, составляющих сетевую настройку:
Как видите, задействованы четыре службы:
- Виртуальное частное облако (VPC) логически отделяет вашу учетную запись AWS от других. Он предоставляет набор адресов для используемых служб.
- Подсети принадлежат только одной зоне доступности (AZ). Они часто используются для обеспечения отказоустойчивости в случае выхода из строя одной зоны доступности. В нашем случае мы пропустим этот шаг для простоты и построили все только в одной подсети.
- Группы безопасности - это способ ограничить тип трафика, который вы хотите разрешить между различными службами. Например, если вы хотите, чтобы службы могли взаимодействовать только друг с другом, вы можете поместить их в одну группу безопасности. Затем вы можете использовать эту группу безопасности, чтобы заблокировать весь трафик извне.
- Конечные точки бывают двух видов. Во-первых, это интерфейсы конечных точек, которые обеспечивают прямой доступ к сервису через частный IP-адрес. Во-вторых, есть шлюзы конечных точек. Они, в отличие от интерфейсов, полагаются на маршрутизацию через таблицу маршрутизации.
В нашем примере нам нужны конечные точки для использования эластичного реестра контейнеров (ECR) и для записи информации в CloudWatch Logs. Как указано, здесь нет общедоступного IP-адреса или доступа к Интернету.
Детали реализации
Позвольте мне провести вас через каждый из трех аспектов этой реализации: уровни безопасности, три конечных точки интерфейса и шлюз. конечная точка.
Уровни безопасности
Для работы VPC в этой конфигурации необходимы две настройки:
- Блок CIDR описывает адресное пространство в вашем VPC. Это комбинация IP-адресов и необходимого вам количества масок подсети. Чем меньше цифра за косой чертой, тем больше масок подсети доступно.
- Нам также необходимо включить имена хостов DNS и поддержку DNS. Они поддерживают использование конечными точками частных функций DNS позже.
Вот как VPC выглядит в сценарии CloudFormation:
Связанная подсеть имеет две части конфигурации:
- Он определяет блок CIDR, который находится в блоке, предоставляемом VPC. В нашем случае подсеть использует все адресное пространство VPC.
- Если вы хотите быть в безопасности, убедитесь, что вы явно отключили сопоставление общедоступного IP-адреса при запуске подсети.
Опять же, вот соответствующая часть сценария CloudFormation:
Группа безопасности принадлежит VPC и не имеет дополнительной конфигурации. Вместо этого дополнительное правило входа содержит важные ограничения трафика. Это правило ограничивает трафик для связи внутри группы безопасности по протоколу HTTPS. Вот конфигурация для обоих ресурсов:
Примечание. также можно настроить обе части как один ресурс в Cloudformation. Однако разделение на два ресурса позволяет избежать циклических ссылок между ними.
Подсеть и группа безопасности - это два компонента, на которые в дальнейшем будут напрямую ссылаться другие части архитектуры. Вот почему скрипт в публичном репозитории экспортирует их ссылки. Теперь мы можем продолжить реализацию необходимых конечных точек.
Конечные точки интерфейса
Как правило, конечные точки интерфейса на AWS работают благодаря AWS PrivateLink. Помните, что Fargate определяет, какие интерфейсы нам здесь нужны. Дополнительные услуги или более сложные архитектуры могут потребовать других конфигураций. Единственное различие между тремя конечными точками интерфейса - это их имя службы. Остальные параметры идентичны:
- ID соответствующего VPC, подсети и группы безопасности.
- Тип конечной точки VPC - это интерфейс.
- Параметр Частный DNS создает конечную точку с именем службы по умолчанию вместо специфичного для конечной точки имени хоста DNS.
Давайте кратко поговорим о роли, которую каждая из этих конечных точек интерфейса играет в более широком контексте:
- * .ecr.dkr - это конечная точка реестра для использования команд Docker.
- * .ecr.api - это универсальный доступ к API реестра.
- *. журналы позволяет передавать данные из Fargate в журналы Cloudwatch.
Вот сценарий CloudFormation для всех трех интерфейсов:
Как видите, эта конфигурация очень проста. К сожалению, нам нужно создать еще один тип конечной точки: шлюз.
Конечная точка шлюза
Только два сервиса AWS по-прежнему полагаются на конечные точки шлюза: S3 и DynamoDB. ECR использует S3 в фоновом режиме для хранения изображений и слоев контейнеров. В отличие от конечных точек интерфейса, конечные точки шлюза также должны напрямую взаимодействовать с так называемой таблицей маршрутов .
Таблицы маршрутов управляют потоком трафика, относящимся к VPC. Чтобы использовать его, мы должны создать таблицу и впоследствии связать ее с подсетью. Конфигурация довольно проста, поэтому позвольте мне показать вам сценарий CloudFormation здесь:
Имея эти ресурсы, мы можем настроить конечную точку шлюза S3. Единственный новый параметр - это идентификатор маршрутизатора, ответственного за организацию трафика внутри подсети. Опять же, сравните подробности сценария CloudFormation:
Как видите, конфигурация конечной точки шлюза реже, чем конечная точка интерфейса. Однако нам нужны два дополнительных ресурса, чтобы охватить его функции.
Я надеюсь, что это резюме помогло вам разобраться в сетевой конфигурации, необходимой для задач Fargate. Опять же, если вы хотите узнать больше об архитектуре, обратитесь к концептуальному посту. Если вы собираетесь его перестроить, обратитесь к общедоступному репозиторию кода. Кроме того, вскоре будут опубликованы еще два поста, в которых обсуждение будет затронуто необходимыми ролями и политиками IAM, а также конкретными строительными блоками для всего сервиса.
Поделитесь своими мыслями и опытом в комментариях. Я также рад подключиться к Twitter и LinkedIn. Спасибо за чтение!
