Назад | Перейти на главную страницу

Как автоматизировать обновление OS / ECS-агента на инстансе EC2 в среде ECS Auto Scaling?

Во-первых: мне кажется, что я до сих пор не понимаю некоторых фундаментальных концепций AWS, поэтому, пожалуйста, потерпите меня, если этот вопрос нубический.

У меня в AWS настроена следующая конфигурация:

1 кластер ECS с 1 отдельной службой
Кластер настроен на использование одного экземпляра EC2.
Этот экземпляр EC2 является частью группы AutoScaling, основанной на определенной конфигурации запуска. (Настройка кластера настроила это так, что, я думаю, имеет смысл.)

У меня сложилось несколько предубеждений / условий

Меня не волнует экземпляр EC2, потому что моя служба работает независимо от машины
Моя служба должна запускаться только на одном экземпляре за раз. Я использую ECS только для простого запуска докеризованного приложения.
Меня не волнуют простои в определенное время.
Существует предопределенный эластичный IP-адрес, который должен использоваться со службой.
Я хочу, чтобы этот сервис был максимально автоматизирован. Когда что-то пойдет не так, мы можем что-то исправить (время безотказной работы не так критично), но я никогда не хочу подключаться к экземпляру EC2 по SSH или что-то в этом роде.

С помощью CloudWatch и Лямбда, Я поставил перед собой следующие задачи:

Экземпляр идентифицируется по имени кластера, которое автоматически добавляется в тег Name.

Раз в неделю, экземпляр кластера перезагружается. Это обновляет сертификаты и конфигурацию, потому что служба делает это при запуске. (Я, вероятно, также мог бы как-то запланировать отключение и перезапуск службы внутри кластера ...)
Каждый раз, когда запускается новый экземпляр кластера EC2, ему будет присвоен предопределенный эластичный IP-адрес.
Раз в месяц, Экземпляр EC2 завершается и автоматически заменяется новым, запущенным группой Auto Scaling Group.

Теперь я надеялся, что, как только Auto Scaling Group создаст новый экземпляр, он будет иметь последний и лучший AMI, включая последний агент ECS.

Поправьте меня, если я ошибаюсь, но когда я посмотрел на конфигурацию запуска для этой группы автоматического масштабирования, я понял, что это не так, потому что она всегда использует настроенный AMI.

Мой общий вопрос: Какая польза от этой настройки, когда мне нужно время от времени вручную проверять (когда именно?), Чтобы обновить AMI в конфигурации запуска, а затем завершить работу экземпляра, чтобы заменить его новым?

Я понимаю, что многие люди, вероятно, не хотят автоматизировать обновления ОС в производственном кластере, потому что они хотят сначала протестировать это. Но все же может потребоваться промежуточная среда, в которой обновления ОС применяются автоматически. Почему я использую платформу с высокой степенью автоматизации, если мне все еще нужно вручную запускать обновления ОС. Это концептуальное недоразумение с моей стороны?

Я создал лямбда-функцию для обновления агента экземпляра во всех моих кластерах ECS:

var AWS = require('aws-sdk');
AWS.config.update({ region: 'sa-east-1' });

exports.handler = async(event, context) => {
    var ecs = new AWS.ECS();

    var responseArray = [];

    const clusters = await ecs.listClusters({}).promise();

    for (var i = 0; i < clusters.clusterArns.length; i++) {
        const clusterArn = clusters.clusterArns[i];

        const clusterInstances = await ecs.listContainerInstances({
            cluster: clusterArn
        }).promise();

        for (var j = 0; j < clusterInstances.containerInstanceArns.length; j++) {
            const containerInstanceArn = clusterInstances.containerInstanceArns[j];

            try {
                const response = await ecs.updateContainerAgent({
                    containerInstance: containerInstanceArn,
                    cluster: clusterArn
                }).promise();

                responseArray.push({
                    cluster: clusterArn,
                    containerInstance: containerInstanceArn,
                    response: response
                });
            }
            catch (e) {
                responseArray.push({
                    cluster: clusterArn,
                    containerInstance: containerInstanceArn,
                    response: e
                });
            }
        }
    }

    return responseArray;
};

Затем я создал правило события CloudWatch для ежедневного выполнения лямбда-функции. У меня работает хорошо.