Як DevOps-інженер, нашим пріоритетом №1 є забезпечення доступності нашого сервісу, а також можливості для відновлення даних клієнтами Rewind цілодобово. Зручність обслуговування, доступність та масштабованість завжди є нашими пріоритетами та мають великий вплив на архітектуру нашого програмного забезпечення. З цієї причини ми нещодавно почали переробляти інфраструктуру одного з наших сервісів, щоб краще відповідати цим пріоритетам.
Давайте заглибимося в проблему, як ми її вирішили та які уроки ми отримали з цього процесу.
Проблема:
У Rewind одна з послуг, які ми надавали, працювала в межах одного Amazon Екземпляр Elastic Compute Cloud (EC2) з використанням docker-compose. Для збереження даних ми використовували AmazonElastic Block Store (EBS), що приєднує том EBS до нашого екземпляра EC2. Том був змонтований Docker та доступний для нашого контейнерного сервісу. Хоча він добре працював у невеликому масштабі, йому бракувало кількох аспектів:
Сервісне обслуговування
Щоразу, коли з'являлося оновлення безпеки або системи, оновлення екземпляра хоста вимагало багато часу. Стек створення змін доводилося зупиняти вручну, потім нам доводилося оновлювати екземпляр і перезапускати стек. Це було рутинне завдання, яке вимагало багато зусиль і впливало на доступність.
доступність
Ще одним аспектом ручного виконання цього рішення було розгортання. Розгортання нового коду також вимагало ручної зупинки стеку для оновлення образу Docker. Це запобігало безперервному розгортанню, і для розгортання змін завжди доводилося планувати вікно обслуговування. Оскільки це зменшувало доступність сервісів Rewind, це було визначено як проблему.
масштабованість
Через обмеження EBS та залежність нашого тома від типу, наш том міг бути підключений лише до одного екземпляра EC2 одночасно. Це означало, що ми могли масштабувати розмір нашого екземпляра лише вертикально, щоб обробляти піки трафіку. Крім того, ми не могли масштабувати наші контейнери, оскільки міг працювати лише один екземпляр нашого стеку створення. Це означало, що нашій системі бракувало резервування.
Рішення:
Тож виникло питання — як зробити наш сервіс легшим для оновлення та масштабування, з меншим часом простою? Зверніть увагу, що наші дані неможливо було перенести, тому наше рішення мало підтримувати EBS.
ECS та REX-Ray
Нам потрібен був інструмент для оркестрації контейнерів, який би забезпечував автоматичне масштабування та спрощене розгортання. Якщо ви працюєте в цій сфері, то знаєте, що існує багато варіантів: k8s, Docker Swarm, Rancher тощо. Для нас, Служба еластичних контейнерів Amazon (ECS) відповідав більшості наших вимог.
Завдяки ECS багато наших проблем зникли. Обслуговування або вертикальне масштабування екземпляра хоста стало таким же простим, як створення нового шаблону запуску з оновленим... AMI (образ машини Amazon) або різний розмір екземпляра. Група автомасштабування потім створила б новий екземпляр для розгортання нашого коду. ECS також дозволяв ковзне або синьо-зелене розгортання, що зменшило час простою. Нарешті, до наших контейнерів можна було б застосувати політику автомасштабування, щоб відповідно реагувати на стрибки трафіку.
На жаль, єдиним обмеженням ECS була відсутність вбудованої підтримки томів EBS. Саме тут і знадобився плагін Docker. REX-Ray з'являється. Як механізм оркестрації сховища, незалежний від постачальника, він забезпечує збереження даних між життєвими циклами контейнерів. Нижче ми описуємо, як ми використовували REX-Ray та ECS, а також розгортали наші зміни в Terraform.
Тераформінг
Ми надамо деякі Terraform фрагменти коду, поки ми працюємо над рішенням для монтування наших томів EBS до кластера ECS. Щоб побачити повну реалізацію, перегляньте мій репозиторій! Під час виконання не забувайте резервне копіювання на GitHub по ходу, щоб не втратити свій прогрес.
Шаблон запуску
Почніть зі створення шаблону даних користувача для завантаження екземплярів контейнера EC2. Він буде використаний для встановлення REX-Ray та налаштування агента ECS. Ми назвали наш user_data.config.tpl:
#!/bin/bash echo ECS_CLUSTER=${ECS_CLUSTER} >> /etc/ecs/ecs.config
# встановити плагін томів REX-Ray Docker встановити плагін docker rexray/ebs REXRAY_PREEMPT=true EBS_REGION=${EBS_REGION} --grant-all-permissions
# перезапустіть агент ECS. Це гарантує, що плагін активний та розпізнається після запуску агента. sudo systemctl restart ecs
Потім передайте шаблон даних користувача (user_data.config.tpl) до шаблону запуску, щоб розкрутити екземпляри контейнера:
дані "template_file" "user_data" { шаблон = файл("user_data.config.tpl") vars = { ECS_CLUSTER = aws_ecs_cluster.ecs_cluster.name EBS_REGION = var.region } } ресурс "aws_launch_template" "ecs_launch_template" { ім'я = "ecs-lt" зображення_id = "ami-028f238814e34dfdc" # зображення, оптимізоване для amz linux 2 ecs instance_type = "t2.micro" vpc_security_group_ids = [aws_security_group.ecs_sg.id] user_data = base64encode(data.template_file.user_data.rendered) iam_instance_profile { ім'я = aws_iam_instance_profile.ecs_iam_ip.name } }
Ви побачите профіль екземпляра, на який посилаються в останньому рядку вище. У нашому файлі ми використали дозволи, запропоновані Документація REX-Ray, але не всі з них можуть знадобитися для вашого конкретного випадку використання. Ви можете експериментувати з ними залежно від ваших потреб.
Обсяг EBS
Ми створили окремий том EBS у Terraform та посилалися на нього у визначенні завдання ECS. Ви також можете «автоматично підготувати» том у визначенні. Це створить том, якщо його не існує, або змонтує існуючий том, якщо він уже створений. Обов’язково встановіть для «scope» значення «shared», щоб забезпечити збереження. В іншому випадку том буде знищено в кінці життєвого циклу контейнера.
ресурс "aws_ecs_task_definition" "ecs_td" { сімейство = "ecs-task-definition" container_definitions = data.template_file.td_template.rendered том { назва = "ecs-ebs-volume" docker_volume_configuration { область дії = "спільний" autoprovision = true драйвер = "rexray/ebs" driver_opts = { volumetype = "gp2" розмір = 5 } } }
Після монтування тома EBS, зіставте шляхи у визначенні контейнера. Наше визначення називається task_definition.json.tpl:
[{ "essential": true, "memory": 100, "name": "${container_name}", "cpu": 1, "image": "${image}", "environment": [], "portMappings": [{ "hostPort": 80, "containerPort": ${container_port} } ], "mountPoints": [{ "sourceVolume": "${source_volume}", "containerPath": "${container_path}" } ] } ] дані "template_file" "td_template" { template = file("task_definition.json.tpl") vars = { container_name = var.container_name image = var.image_url container_port = var.container_port source_volume = "ecs-ebs-volume" container_path = "https://rewind.com/mnt/ecs-ebs-volume" } }
Перевірка монтування тома
Молодець! Ви визначили та змонтували свій том EBS. Тепер перевірте, чи все пройшло за планом. Перевірте консоль AWS, щоб переконатися, що з’явився новий екземпляр із підключеними томами. Потім виконайте такі дії, щоб перевірити, чи зберігаються ваші дані між новими завданнями або екземплярами:
SSH (або SSM як це робимо ми, користувачі Rewinder!) у ваш екземпляр ECS, використовуючи вашу існуючу пару ключів.
ssh -iec2-користувач@
Далі, отримайте ідентифікатор запущеного контейнера за допомогою команди:
Докер ПС
І 'exec' у контейнер з отриманим вами ідентифікатором контейнера:
docker exec -it/ Бен / ш
Нарешті, ми створимо тестовий файл, щоб переконатися, що все працює. Ви можете «відобразити» будь-що у файл у папці контейнера:
echo "тест" > /mnt/ecs-ebs-vl/файл.txt
Перезапустіть визначення завдання для екземпляра EC2. Воно має автоматично змонтувати існуючий том EBS, і тестовий файл все ще має бути там.
Недоліки
Є кілька застережень щодо цього підходу.
- Томи Docker є підтримується лише при використанні типу запуску EC2 в ECSНаразі підтримки для Фаргейта немає.
- Якщо том не змонтовано лише для читання, одночасний запис кількох контейнерів на один том може призвести до неузгодженості даних. Щоб забезпечити стійкість даних, ваша програма повинна забезпечувати порядок запису. Або ж використовуйте кластерна файлова система такий як GlusterFS.
- Наразі лише томи io1 та io2 підтримують EBS. Мульти-приєднання, що дозволяє підключити один том до 16 екземплярів Linux в одній зоні доступності. Однак, REX-Ray наразі не має підтримки для цих типів томів. Таким чином, автоматичне масштабування може відбуватися лише на рівні контейнера, оскільки лише один екземпляр EC2 може монтувати том. Якщо/коли це стане доступним, слід також зазначити, що в Terraform все ще триває робота над Увімкнути багатоетапне підключення для томів io2 через API AWS. У нашому прикладі використовується тип тома gp2.
Висновок
Будь-який фахівець з DevOps знає, що зручність обслуговування, доступність та масштабованість є вирішальними для створення застосунку, який забезпечує користувачам безперебійний та надійний досвід роботи. Використання Amazon ECS спрощує процес розгортання контейнерних сервісів і може бути налаштований для роботи з EBS без особливих зусиль.
Якщо ви зацікавлені у вирішенні інших подібних проблем, вам варто ознайомитися Відкриті вакансії Rewind щоб розпочати свою кар'єру в DevOps, безпеці, інженерії тощо.
