Мы используем Ansible для развертывания обновлений безопасности на всех наших экземплярах EC2, на которых запущены службы с отслеживанием состояния, такие как базы данных, поисковые системы и т. д. Это отлично работает.
Мне интересно, как лучше всего делать обновления безопасности для экземпляров ECS (которые запускают веб-приложения без сохранения состояния в контейнерах Docker). Благодаря автоматическому масштабированию наблюдается большая динамика количества экземпляров и их IP-адресов. Ansible использует жестко запрограммированный список IP-адресов (файл hosts), поэтому он, похоже, не совсем подходит для цели.
Это вообще хорошая идея - обновлять эти экземпляры или нам лучше удалять их и время от времени создавать новые?
Есть ли какие-нибудь лучшие практики от разработчиков DevOps?
Обновить:
Я выяснил, что Ansible поддерживает динамическую инвентаризацию. Там есть скрипт который получает информацию о хостах из AWS и генерирует динамический инвентарь для Ansible, это отлично работает.
Однако остается одна проблема. При появлении нового хоста, к которому я раньше не подключался, отображается следующее сообщение, которое необходимо подтвердить вручную.
The authenticity of host '10.0.1.247 (10.0.1.247)' can't be established.
ECDSA key fingerprint is SHA256:GSogs6P6CzbOzLm9ByWsXkfz7/2A4qwj4PDvczApS/I.
Are you sure you want to continue connecting (yes/no)? yes
Это очень раздражает, так как я хочу реализовать полностью автоматический механизм обновления. Есть решение этой проблемы?
Обновление контейнера на месте - это полный антипаттерн. Это громоздко, так как вам нужно обновить каждый из них и, возможно, зафиксировать каждый из них.
Вместо этого обновите образ, используемый для создания ваших контейнеров. Обычно это делается с помощью раздела на вашем Dockerfile чтобы убедиться, что образ обновлен, поэтому процесс исправления в основном перестраивает образ. Например:
FROM centos:7.2.1511
MAINTAINER Jane Doe <j.doe@foo.com>
RUN yum update -y && \
yum install -y \
bar \
foo && \
yum clean all
# The rest of your Dockerfile
Однако в развертывании нового образа я обнаружил, что ECS не хватает. Вам нужно самостоятельно разработать стратегию, чтобы избежать простоев.
Также рекомендуется иметь службу, сканирующую образы в вашем реестре на наличие уязвимостей.
Исправление хост-ОС (которое может потребовать перезагрузки) без простоя - это еще одна область, в которой я обнаружил, что ECS не хватает возможностей оркестровки, так как в продукт не встроено ничего из коробки, кроме балансировки ELB между узлами.
Другие контейнерные платформы (например, OpenShift) имеют возможность эвакуации контейнеров (контейнеров, поскольку это кубернеты) из узлов, и планирование их в другом месте. Балансировщик нагрузки знает об этих изменениях, обеспечение нулевого времени простоя. Кроме того, ОС, обычно используемая с OpenShift имеет улучшенный механизм исправления на основе RPM OSTree это значительно снижает сложность установки исправлений для операционной системы хоста.
Каждый раз, когда появляется новый хост, к которому я раньше не подключался, отображается следующее сообщение, которое необходимо подтвердить вручную. [] Есть ли решение этой проблемы?
Измените ssh_connection из ansible.cfg, так что он содержит -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null аргументы.
Например:
[ssh_connection]
ssh_args = -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -o ControlMaster=auto -o ControlPersist=60s