#amazon-web-services #aws-fargate
#amazon-web-services #aws-fargate
Вопрос:
Какой самый простой способ предоставить один или несколько внешних файлов конфигурации приложению, работающему как задача AWS Fargate?
- Файлы не могут быть частью образа Docker, поскольку они зависят от среды stage и могут содержать секреты.
- Создание тома EFS только для этого кажется чрезмерно сложным (нам нужен только доступ для чтения к некоторым КБ свойств).
- Использование AWS SDK для доступа к корзине S3 при запуске означает, что приложение зависит от SDK, и нужно управлять корзинами S3.*
- Использование AWS AppConfig все равно потребует, чтобы приложение использовало AWS SDK для доступа к значениям конфигурации.*
- Наличие сотен пар ключ-значение в хранилище параметров было бы некрасиво.
* Важным аспектом наших приложений является то, чтобы они не зависели от AWS SDK, потому что нам нужна возможность развертывания на разных облачных платформах, поэтому предпочтительнее решения, позволяющие избежать этого.
Было бы неплохо просто иметь возможность определить это в определении задачи, чтобы Fargate монтировал пару файлов в контейнер. Доступно ли это или аналогичное простое решение?
Ответ №1:
Для этой цели в AWS Systems Manager есть специальная функция, которая называется AWS AppConfig. Это помогает вам развертывать конфигурацию приложения точно так же, как при развертывании кода, но без необходимости повторного развертывания кода при изменении значения конфигурации.
Следующая статья иллюстрирует интеграцию между контейнерами и AWS AppConfig: развертывание конфигурации приложения для рабочих нагрузок контейнера с использованием AWS AppConfig.
Комментарии:
1. Спасибо, но для доступа к службе AppConfig все еще требуется AWS SDK. Я обновлю свой вопрос, чтобы объяснить, почему это недостаток.
2. Если вы хотите иметь возможность развертывания на нескольких платформах, вам придется придерживаться наименьшего общего знаменателя. Это означает, что вы не можете использовать преимущества какой-либо облачной платформы и, вероятно, должны создавать практически все самостоятельно. Это всегда компромисс: хотите ли вы иметь в наличии все строительные блоки и использовать преимущества широты и глубины высокоинтегрированных сервисов AWS, или вы хотите не зависеть от платформы и использовать облако как еще один центр обработки данных, который должен создавать, управлять и обслуживатьвсе самостоятельно.
3. Не поймите меня неправильно, оба варианта допустимы. Один из них требует гораздо больше работы. Если ваша возможность потенциального развертывания на другой платформе в будущем оправдывает выполнение всей недифференцированной тяжелой работы самостоятельно, вы можете это сделать. Но тогда вы не сможете использовать простые инструменты, доступные в облаке.
4. @Деннис Трауб, очевидно, что оставаться сторонником платформы очень важно в данном случае, рассматривая вопрос. Я полностью понимаю, хотят ли проекты оставаться независимыми от платформы в максимально возможной степени, и фактически попытаюсь сделать это для проектов, над которыми я работаю. Если бы то же самое решение было реализовано, например, с использованием Azure, мы могли бы использовать AzureAppConfigurationBuilder или AzureKeyVaultConfigBuilder. Проблема в том, что нет реализации конструктора конфигурации для AWS. Для такой простой задачи, как эта, вам не нужно полагаться на сервисы, зависящие от конкретной платформы.
Ответ №2:
Не ответ на вопрос, но на случай, если кто-то придет сюда в поисках решений, у нас были те же требования, но мы не нашли простого решения для развертывания файла конфигурации непосредственно в экземпляре ECS для чтения контейнером. Я уверен, что это возможно, просто было бы сложно настроить, поэтому мы не увидели достойных усилий.
Что мы сделали:
- Добавлен EnvironmentConfigBuilder, как описано в MS docs здесь
- Передаются значения конфигурации с использованием переменных среды, как описано в документах AWS здесь .
Ответ №3:
Вы можете указать свою зависимость AWS AppConfig в виде отдельного контейнера. AWS предоставляет вам возможность задавать условия выполнения зависимостей контейнера в определении задачи. Смотрите: https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDependency.html
Вы можете установить статус зависимости вашего контейнера на COMPLETE
для контейнера, который извлекает файлы конфигурации из AppConfig, а затем просто обрабатывать файлы как немое монтирование, полностью отделяя зависимость от AWS. Например:
"containerDefinitions": [
{
"name": "app-config-script",
"image": "1234567890.dkr.ecr.SOME_REGION.amazonaws.com/app-config-script:ver",
"essential": false,
"mountPoints": [
{
"sourceVolume": "config",
"containerPath": "/data/config/nginx",
"readOnly": ""
}
],
"dependsOn": null,
"repositoryCredentials": {
"credentialsParameter": ""
}
},
{
"name": "nginx",
"image": "nginx",
"essential": true,
"portMappings": [
{
"containerPort": "80",
"protocol": "tcp"
},
{
"containerPort": "443",
"protocol": "tcp"
}
],
"mountPoints": [
{
"sourceVolume": "config",
"containerPath": "/etc/nginx",
"readOnly": true
}
],
"dependsOn": [
{
"containerName": "app-config-script",
"condition": "COMPLETE"
}
],
"repositoryCredentials": {
"credentialsParameter": ""
}
}
],
Тогда ваш сценарий Entrypoint / CMD в контейнере начальной загрузки будет выглядеть примерно так:
#!/bin/sh
token=$(aws appconfigdata start-configuration-session --application-identifier "${APPLICATION_ID}" --environment-identifier "${ENVIRONMENT_ID}" --configuration-profile-identifier "${CONFIGURATION_ID}" | jq -r .InitialConfigurationToken)
aws appconfigdata get-latest-configuration --configuration-token "${token}" /data/config/nginx/nginx.conf