Продолжаем серию статей по бесперебойному развёртыванию сервиса в AWS при помощи Ansible . В предыдущей статье мы разобрали Blue-Green deployment.
На этот раз мы рассмотрим более долгий, но и более экономный деплоймент - Rolling deployment.
Rolling Deployment
Идея заключается в следующем:
- У нас есть несколько инстансов на которых работает приложение версии 2.21 и лоад балансер.
- Добавляем по одной виртуалке с версией 2.22 и подключаем к балансеру.
- Отключаем одну старую ноду с версией 2.21 от лоад балансера и удаляем её.
- Повторяем шаги 2 и 3 пока не заменим все виртуалки.
Этот вид развёртывания неприемлем, если есть калечащие изменения в базе данных при переходе на новую версию приложения.
Реализация
На этот раз я решил упростить архитектуру, ведь для иллюстрации принципа работы достаточно иметь несколько серверов и лоад балансер, поэтому не будет использоваться RDS и дополнительные подсети. В качестве приложения будет использоваться nginx, который будет возвращать версию приложения и hostname инстанса, на котором работает nginx.
Сразу оставлю ссылку на репозиторий с полным кодом , для тех, кто хочет самостоятельно разобраться.
Как же реализовать rolling-deployment на ansible.
0. Используемые переменные
region: eu-west-1
version: 2.22
instance_num: 3
region: - регион AWS, в этом примере используется регион в Ирландии
version: - версия приложения
instance_num: - окончательное число виртуалок, с нашей версией.
1. Находим предыдущие инстансы.
1.1. Смотрим есть ли инстансы нужной нам версии
Перед тем, как создавать новые виртуальные машины, убедимся, сколько их уже было создано с нужной версией и все остальные, таким образом прерванный деплой этого же приложения пе будет повторяться, а продолжиться..
Собираем данные о виртуалках с нужной версией.
- name: Get new instances
ec2_remote_facts:
filters:
vpc_id: "{{ vpc.vpc.id }}"
instance-state-name: running
"tag:Name": MyTestApp
"tag:Environment": MyTest
"tag:Version": "{{ version }}"
region: "{{ region }}"
register: new_instances
- name: set new instances ids if not found previously created
set_fact:
new_instances: []
when: new_instances.instances is not defined
- name: set new instances ids if found previously created
set_fact:
new_instances: "{{ new_instances.instances|map(attribute='id')|list }}"
when: new_instances.instances is defined
Так как из всей собранной информации нам нужны только айдишники, то в переменную new_instances записывается только список айдишников виртуалок или пустой список если ничего не нашли.
1.2. Находим все инстансы, включая найденные выше
В этот список будут включены инстансы из п. 1.1., поэтому отдельно удаляем их из этого списка
- name: Get old instances
ec2_remote_facts:
filters:
vpc_id: "{{ vpc.vpc.id }}"
instance-state-name: running
"tag:Name": MyTestApp
"tag:Environment": MyTest
region: "{{ region }}"
register: old_instances
- name: set old instances ids if not found previously created
set_fact:
old_instances: []
when: old_instances.instances is not defined
- name: set old instances ids if found previously created
set_fact:
old_instances: "{{ old_instances.instances|map(attribute='id')|list }}"
when: old_instances.instances is defined
- name: Remove new instances from old ones
set_fact:
old_instances: "{{old_instances|difference(new_instances)}}"
Точно также записываем список айдишников.
2. Создаём виртуалки (по очереди)
2.1. Стартовый скрипт виртуальной машины
Как уже упоминалось раннее, сервис был упрощён, теперь скрипт при старте виртуалки выглядит следующим образом.
#!/bin/bash
yum install nginx -y
# nginx configuration
echo '
server {
listen 8081 default_server;
location = /healthcheck {
add_header Content-Type text/plain;
return 200 '{{ version }}';
}
location = /stack {
add_header Content-Type text/plain;
return 200 '$(hostname)';
}
}' > /etc/nginx/conf.d/virtual.conf
service nginx restart
Создаётся два эндпоинта:
- /healthcheck - по нему лоад балансер определяет жива ли нода. Так же он показывает версию, с которой был продеплоен инстанс
- /stack - показывает имя хоста
2.2. По очереди создаём виртуальные машины
Так как в Ansible нельзя просто обьеденить несколько тасков в цикл, то с версии 2.1 добавили возможность запустить группу тасков циклом, обьеденённых в один файл. Выглядит эта конструкция примерно так:
- include: add_remove.yaml
with_sequence: start=1 end={{ instance_num }}
loop_control:
loop_var: instance_counter
Получается мы вызываем список заданий add_remove.yaml столько раз, сколько планируем запустить новых инстансов(здесь будет запущено instance_num раз).
instance_counter - это переменная, которая будет передаваться внутрь списка заданий.
Заглянем внутрь add_remove.yaml, там происходит следующее:
2.3. Создаётся виртуалка и добавляется в конец списка old_instances
- set_fact:
new_instances_num: "{{new_instances|length|int}}"
- name: Create EC2 server
ec2:
image: ami-41505fab
wait: yes
instance_type: t2.micro
region: "{{ region }}"
group_id: "{{ app_sg.group_id }}"
vpc_subnet_id: "{{ app_subnet.subnet.id }}"
key_name: "{{ keypair.key.name }}"
user_data: "{{ lookup('file', './setup.sh') }}"
instance_tags:
Environment: MyTest
Name: MyTestApp
Version: "{{ version }}"
register: ec2
when: new_instances_num|int < instance_num
- name: add newly create instance id to new_instances list
set_fact:
new_instances: "{{new_instances}}+{{ec2.instance_ids}}"
new_instances_num: "{{new_instances|int + 1}}"
when: ec2.changed == True
Условие используется для того, чтобы не создавать лишние инстансы.
2.2 Добавляем в Elastic Load Balancer и ждём, когда виртуалка запустится
- name: Create ELB with all instances
ec2_elb_lb:
name: "app-rolling-lb"
state: present
security_group_ids:
- "{{ elb_sg.group_id }}"
region: "{{ region }}"
instance_ids: "{{ new_instances|union ( old_instances)}}"
subnets:
- "{{ app_subnet.subnet.id}}"
listeners:
- protocol: http
load_balancer_port: 80
instance_port: 8081
health_check:
ping_protocol: http # options are http, https, ssl, tcp
ping_port: 8081
ping_path: "/healthcheck" # not required for tcp or ssl
response_timeout: 15 # seconds
interval: 30 # seconds
unhealthy_threshold: 2
healthy_threshold: 2
tags:
Environment: MyTest
- name: Waiting for instances to become ready
ec2_elb_facts:
region: "{{ region }}"
names: app-rolling-lb
register: elb_facts
until: elb_facts.elbs[0].instances_inservice_count == (new_instances|union ( old_instances)|length)
retries: 10
delay: 15
Добавляем старые и новые инстансы в балансер, на случай если они не были добавлены раньше. Затем ждём когда все смогут ответить на запросы балансера.
2.3 Самое хитрое место
- name: Terminate instances that were previously launched
ec2:
state: 'absent'
instance_ids: '{{ old_instances.0 }}'
region: "{{ region }}"
group_id: "{{ app_sg.group_id }}"
vpc_subnet_id: "{{ app_subnet.subnet.id }}"
when: ec2.changed == True and old_instances.0 is defined
- name: remove instance_id from old_instances list
set_fact:
old_instances: "{{old_instances[1:]}}"
when: ec2.changed == True and old_instances.0 is defined
Удаляем первую виртуалку физически и её айдишник из списка old_instances, если новая была создана.
При удалении виртуалки, она автоматически удаляется из лоад балансера, поэтому отдельный таск под это не создавался.
Запускаем ansible
Ещё раз продублирую ссылку на полный плейбук.
Проще всего будет клонировать весь репозиторий и запустить скрипт:
git clone https://github.com/korney4eg/rolling-deployment-ansible
cd rolling-deployment-ansible/
ansible-playbook provision.yaml -v
Чтобы вам долго не мучиться с удалением только что созданных ресурсов я подготовил скрипт, который удаляет всё в обратном порядке, для этого нужно выполнить следующую команду:
ansible-playbook destroy.yaml -v
Что можно сделать лучше
- Разбить один большой файл на несколько мелких, это бы дало лучшую читабельность (как советуют в Ansible).
Заключение
На этом примере был рассмотрен один из видов беспрерывного развёртывания (Zero-downtime deployment) - Поэтапное развёртывание (Rolling Deployment). Как уже было сказано выше, этот способ экономит деньги(немного), потому что в один момент времени используется n+1 виртуалок, в то время как при Blue-Green Deployment - 2*n.
К недостаткам этого метода можно отнести следующие пункты:
- Медленный, занимает времени больше, чем при Blue-Green Deployment в N раз, где N - количество виртуалок.
- Если что-то сломается в середине процесса, например на 3-й виртуалке из 5-ти, то придётся заранее думать, как всё починить и идти дальше. Хотя можно поставить деплоить виртуалки со старой версией.
Не смотря на недостатки этот способ используется по-умолчанию в оркестраторах контейнеров (например kubernetes ).