Как мне распределить промежуточные версии общих сервисов между VPC? - PullRequest
Новая
       23

Как мне распределить промежуточные версии общих сервисов между VPC?

2 голосов
/ 08 января 2020

Это распространенный шаблон проектирования, в котором отдельные VPC для каждой среды используются в AWS:

  • prod
  • staging
  • dev
  • shared (например, CI, метрики, ведение журнала)

Если я напишу новую прикладную службу, у меня будет 1 копия в каждом из VPC {prod, staging, dev}.

Тем не менее, что мне делать для промежуточных / промежуточных версий общих служб (например, метрик)? Если это прямо из коробки, я мог бы просто поместить одну копию в shared VP C. Но если это какая-то собственная внутренняя версия, и я хочу заняться ее разработкой, я должен поместить и промежуточную, и промежуточную версии этой общей службы в одну shared VP C?

Ответы [ 2 ]

0 голосов
/ 17 января 2020

Сначала ответьте на ваш вопрос напрямую. Вам нужна среда платформы. Эта среда будет для всей разработки и конфигурации, на которой вы строите свое приложение. Он будет включать вашу собственную систему показателей, а также всю инфраструктуру, включающую AWS сервисы, такие как VPC, облачные часы, ведение журналов и т. Д. c.

Ваша среда рабочего процесса будет выглядеть следующим образом.

platform -> dev -> staging -> prod

В зависимости от процесса на вашей платформе это может быть 1 среда (платформа dev) или 2 (платформа dev и подготовка платформы). И платформа prod - это среда разработки ваших приложений.

Большая картина

Вам необходимо поднять свое окружение на уровень и сделать это на уровне аккаунта. Таким образом, у вас будет 4 разных AWS учетных записи.

  • платформа разработчика
  • подготовка платформы (необязательно)
  • разработка приложения
  • подготовка приложения
  • application prod
  • управление для общего доступа (например, CI, метрики, ведение журнала)
  • AWS учетная запись управления (AWS Control Tower и организации)

Это имеет несколько преимуществ:

  • Вы можете настроить каждую среду одинаково с облачной или терраформированной средой. Вы автоматизируете каждую среду записи? Просто скажите «да».
  • Вы получаете более качественный контроль доступа и вам не нужно беспокоиться о среде своего продукта при работе в dev.
  • У вас будет доступ VP C от VP C управления к каждому VP C в вашей среде prod / staging / dev, тогда вы можете использовать пиринг VP C для VP C.

AWS предоставляет 2 услуги для управления несколькими учетными записями.
AWS Control Tower AWS Организации Начните с Control Tower as она настроит вашу Организацию для вас.

И если вы хотите масштабировать это для нескольких приложений, вам нужно всего лишь дублировать среду разработки / разработки приложений.

0 голосов
/ 13 января 2020

Каждая среда должна быть в отдельном VP C для обеспечения безопасности и простоты обслуживания

  • dev
  • staging
  • production

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

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

В идеале инструменты контроля журналов и мониторинга приложений могут находиться в shared VPC, большинство журналы времени и метрики, отправленные через агента, установленного с хост-компьютера по протоколу https or UDP/TCP, поэтому работа в сети не будет проблемой.

В случае инструмента CI его можно разместить в общем VP C с развертыванием для обработки всех сред путем разделения представлений для заданий развертывания и управления доступом с помощью плагина управления ролями для нескольких V команды. Однако всегда лучше иметь dev / standby и производственное развертывание / Jenkins, чтобы тестировать разработку и тестирование новых вещей с точки зрения обновления плагинов и зависимостей, а не применять их непосредственно на производстве.

...