Spring Cloud AWS и Fargate - PullRequest
Новая
       17

Spring Cloud AWS и Fargate

0 голосов
/ 27 марта 2019

Я переместил приложение с помощью Spring Cloud AWS (2.1.0.RELEASE) из экземпляра ECS / EC2 в ECS / Fargate, и оно зависало при загрузке, не смог получить учетные данные из экземпляра.

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

Может кто-нибудь подтвердить, что это должно работать / работает должным образом? Я не уверен, что отлаживать в противном случае.

Редактировать : у меня спрашивают образец кода. Я не написал никакого Java-кода, так что дело до конфигурации, которой я поделюсь ниже.

My pom.xml включает в себя: 

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-aws-parameter-store-config</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-aws-autoconfigure</artifactId>
        </dependency>

В пределах src/main/resources/bootstrap.yml У меня есть: 

spring:
  application:
    name: myapp
  cloud:
    consul:
      enabled: false
      config:
        enabled: false
aws:
  paramstore:
    enabled: false
cloud:
  aws:
    stack:
      auto: false
    credentials:
      instance-profile: false
    region:
      static: eu-west-2
      auto: false

В src/main/resources/bootstrap-aws.yml (активируется через профиль aws в командной строке): 

aws:
  paramstore:
    prefix: /services/app
    default-context: common
    profile-separator: '_'
    fail-fast: true
    enabled: true

1 Ответ

0 голосов
/ 28 марта 2019

Теперь я работаю с Фаргейтом. Это не имело никакого отношения к приложению Java, оно было связано с правами на развертывание ECS, как я попытаюсь объяснить.

ECS: EC2

ECS по умолчанию использует экземпляры EC2 для развертывания задач (хранения контейнеров). Для этого он использует агента ECS в каждом экземпляре EC2, который, в свою очередь, связывается с механизмом Docker; этот агент ECS по умолчанию не имеет прав, что означает, что он не может загружать личные изображения (например, из ECR) и записывать журналы в CloudWatch (например).

Чтобы исправить это, мы создаем роль IAM и запускаем задачу с ExecutionRoleArn (в CloudFormation), ссылающейся на это. Роль IAM требует прав ecr и прав на запись в журнал.

Теперь, в спешке, я добавил права на хранилище параметров к этому, не задумываясь об этом, и эй, прежде чем мое приложение успешно работало и получало значения хранилища параметров. Оказывается , что в режиме EC2 права, предоставленные агенту ECS, наследуются работающим контейнером (мое приложение).

ECS: Fargate

Переключитесь на Фаргейт, перерывы выше. ExecutionRoleArn остается релевантным, но не наследуется работающим контейнером. Так что нет смысла предоставлять ему права на хранилище параметров.

Добавьте в определение задачи TaskRoleArn и укажите его на другую роль. На этот раз предоставьте права в этой новой роли для вызова сервисов AWS, которые нужны вашему контейнеру (приложению) - хранилище параметров, S3, SQS и т. Д.

С этим сделано, мое приложение доволен. Не стесняйтесь обновлять с любыми исправлениями, поскольку это написано моим пониманием и опытом пока.

Возможно, было бы лучше назвать ExecutionRoleArn как AgentRoleArn и TaskRoleArn как ApplicationRoleArn, но это только моя точка зрения.

...