Управляемые услуги — основная причина, по которой мы предпочитаем облако другим способам хостинга. Никто не выбирает AWS только для того, чтобы загрузить инстанс EC2 и запустить в нем сервер apache. Мы хотим воспользоваться преимуществами высокодоступного облачного хранилища, такого как S3, или полностью управляемой реляционной базы данных через RDS. И каждому продукту нужно несколько нестандартных логик, которые требуют целой комнаты для написания миньонов. Эти созданные вручную приложения, называемые микросервисами, должны взаимодействовать со всеми другими облачными компонентами, которые мы выбрали в нашей архитектуре. Вместе они будут творить чудеса, которые наши старые ржавые монолиты не смогли сделать.
Я уверен, что вы, возможно, провели несколько бессонных ночей, разрываясь между AWS и GCP. Вы здесь «Нео», потому что сделали мудрый выбор. Поэтому я пишу эту историю, чтобы помочь вам принять следующее важное решение. Как интегрировать микросервис Spring Boot с AWS.
Зачем нам нужно интегрировать наши микросервисы с AWS?
Если вы не используете какие-либо управляемые сервисы AWS, значит, вы неправильно работаете с облаком. Так что в конечном итоге вы будете использовать S3 или Simple Notification Service или Simple Queue Service, чтобы раскрыть весь потенциал облака.
Во всех этих случаях вы должны аутентифицировать свое приложение и управлять разрешениями, чтобы разрешать или запрещать определенные управляемые сервисы AWS.
Почему использование роли экземпляра EC2 — плохая идея?
Кто-то может возразить, что запуск нашего микросервиса внутри EC2 и использование ролей EC2 — это правильный путь. Spring boot может взять на себя те же роли, что и базовый экземпляр EC2.
Но у микросервиса на основе ролей EC2 есть следующие недостатки:
- Нет четкого разделения разрешений между различными микросервисами, работающими в одном экземпляре EC2.
- Конкретный контрольный журнал микросервиса невозможен
Пользователь IAM для каждого микросервиса
Итак, как же нам решить две вышеупомянутые опасные проблемы? Мы создаем пользователя IAM и включаем программный доступ. Для каждой микрослужбы создайте пользователя IAM с именем службы и сузьте разрешения. Включите программный доступ, чтобы получить ключ доступа и секретный ключ для настройки загрузки Spring.
Если служба должна иметь доступ только к S3, мы можем включить только это. Другому сервису может понадобиться Simple Queue Service для обмена сообщениями и Simple Notification Service для электронной почты, мы можем ограничить доступ только к этим сервисам.
И лучше всего автоматизировать создание стека микросервисов с помощью облачного формирования, даже если сервису нужен только IAM. Ключ доступа можно создать вручную из консоли, чтобы упростить работу вместо использования шифрования или секретов.
Интеграция Spring Boot с AWS
После создания секретного ключа все, что нам нужно сделать в нашем микросервисе загрузки Spring, — это добавить зависимость maven org.springframework.cloud:spring-cloud-aws-context. Затем добавьте следующие свойства в переменные среды приложения.
cloud.aws.credentials.accessKey=ABCD0123456789
cloud.aws.credentials.secretKey=127812HAHJS2727272
cloud.aws.region.static=ap-south-1
Создайте AwsConfig, как показано ниже, и все готово.
Чтобы настроить приложение для разных сред, запустите стек cloudformation, создайте ключ доступа и настройте вышеуказанные свойства в среде docker микросервиса.
Настройка нескольких регионов
При запуске микросервиса в нескольких регионах мы можем просто установить свойство cloud.aws.region.static.
Включение поиска региона на основе EC2 означает, что нам нужно объявить некоторые bean-компоненты, чтобы приложение работало в локальной среде. Что, по моему скромному мнению, излишне.
Пример кода можно найти в приведенном ниже репозитории github.
Попробуйте эти статьи, которые могут помочь вам в вашем путешествии по микросервисам.
