Сколько из вас использует контейнеры на производстве?
Со времени DockerCon 2014 я слышал этот вопрос много раз. Принятие Docker было стремительным явлением в течение последних трех лет, но производство контейнеров все еще остается проблемой. В декабре 2015 года компания Robin Systems опросила 200 представителей различных отраслей на предмет их статуса принятия контейнеров. 36% респондентов используют контейнеры в производстве, а 59% планируют принять решение, все еще проводят расследование или просто играют с контейнерами.
В Demonware мы используем Docker более двух лет. Тем не менее, мы все еще находимся в категории «планируем принять, все еще исследовать или просто играть с контейнерами». Почему переход к производству так сложно? Есть ли способ втиснуть контейнеры в производство с низким уровнем риска и низкой стоимостью?
Будучи членом команды Build Engineering (BE), я работал с командами разработчиков над Dockerize их конвейерами непрерывной интеграции (CI). Когда команда BE начала использовать Docker в сентябре 2013 года, мы почти единодушно согласились с тем, что мы можем использовать контейнеры в средах сборки, тестирования и разработки без жестких требований для запуска контейнеров в производстве. Наше отношение с тех пор изменилось.
Преимущества контейнеризации наших конвейеров CI, инструментов, инфраструктуры построения и инфраструктуры тестирования были огромны. Мы хотели бы видеть эти аналогичные преимущества в производстве. Так что же нам мешает?
Большинство барьеров не являются техническими. В некоторых кругах по-прежнему существует обеспокоенность тем, что контейнеры не являются подходящей технологией для использования. Мы хотели двигаться вперед, заверяя заинтересованные стороны в том, что мы делаем это контролируемым образом и с низким уровнем риска.
Двойное Развертывание
План состоял в том, чтобы настроить существующий конвейер непрерывной доставки (CD) для перемещения контейнеров ближе к производству без какого-либо риска для существующих развертываний. У нас уже было несколько разрозненных конвейеров сборки, отвечающих за сборку сервисных пакетов (RPM), сервисных контейнеров (Docker) и Amazon Machine Images (AMI).
Мы объединили эти конвейеры для создания артефакта AMI «двойного развертывания». Этот артефакт AMI создан с использованием Packer . Packer — это замечательный инструмент для создания и предоставления изображений любого типа, который поддерживает широкий спектр провайдеров и провайдеров. Упаковщик является полностью бесплатным и предоставляет надежные, воспроизводимые изображения на основе шаблона формата JSON. Образец шаблона можно найти здесь .
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
{ "variables": { "base_image": "change me with the '-var base_image=whatever' arg", "new_image": "change me with the '-var new_image=whatever' arg", "access_key": "change me with the '-var access_key=whatever' arg", "secret_key": "change me with the '-var secret_key=whatever' arg", "script": "change me with the '-var script=whatever' arg", "script_args": "change me with the '-var script_args=whatever' arg" }, "builders": [{ "type": "amazon-ebs", "region": "us-west-2", "vpc_id": "", "subnet_id": "", "instance_type": "t2.micro", "access_key": "{{user `access_key`}}", "secret_key": "{{user `secret_key`}}", "ssh_username": "centos", "ami_name": "{{user `new_image`}} {{timestamp}}", "source_ami": "{{user `base_image`}}", "ami_block_device_mappings": [ { "device_name": "/dev/sda1", "volume_size": 30 } ], "ssh_pty" : "true", "tags": { "project": "demo" }, "run_tags":{ "project": "demo" } }], "provisioners": [ { "type": "shell", "execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo -E '{{ .Path }}' {{user `script_args`}}", "scripts": "{{user `script`}}" }, { "type": "shell", "inline": [ "echo 'Rebooting for bootstrap changes to take effect.';sudo systemctl reboot" ] }, { "type": "shell", "execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo -E '{{ .Path }}'", "scripts": "install_service_rpm.sh" }, { "type": "shell", "execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo -E '{{ .Path }}'", "scripts": "build_service_container.sh" } ]} |
Сборка AMI «двойного развертывания» состоит из двух частей.
- Пакет обслуживания (RPM) установлен, настроен и готов к работе при запуске экземпляра EC2.
- Контейнер сервисов, основанный на том же источнике, что и наш пакет сервисов, создается на этапе сборки AMI.
Выгоды
Это позволяет нам развертывать наш сервис обычным способом, но также имеет возможность направлять трафик через сервисный контейнер для целей тестирования. Это потребовало небольшой настройки шаблона AMI Packer и увеличило время сборки на несколько минут.
Это метод низкого риска для запуска контейнеров в производство путем совмещения существующего конвейера CD. Запуск сервисного контейнера по-прежнему выполняется вручную, и в настоящее время мы используем его для тестирования контейнера. Когда мы запускаем контейнер, мы используем опцию --host docker run для маршрутизации трафика через сервисный контейнер.
Давайте рассмотрим, как может выглядеть пример потока и пример шаблона Packer для AWS.
Пример двойного развертывания
В этом примере наш сервис установлен на экземпляре EC2 (Centos 7) и может обрабатывать трафик с использованием интерфейса VM. Этот же код находится в контейнере и доступен для обработки трафика с использованием интерфейса хоста (ВМ). В настоящее время мы вручную перенаправляем трафик для целей тестирования.
Создание среды двойного развертывания с использованием Packer
Шаблон Packer aws.json используется для создания образа машины Amazon. Этот образ будет загружен, наш сервис будет установлен как RPM, а наш сервисный контейнер собран.
bootstrap.sh может быть настолько простым или сложным, насколько вам нужно. Мы используем его для установки некоторых вспомогательных инструментов и установки Docker.
container.sh извлекает код контейнера службы из GitHub и создает образы контейнеров как часть сборки AMI. Шаблон aws.json поддерживает шесть аргументов:
|
1
2
3
4
5
6
|
base_image : The AMI ID of the base image you want to build from. new_image : The name of the new AMI you are building. access_key : AWS access key secret_key : AWS secret key script : The name of the script you want to run to bootstrap the base image. script_args: Pass in additional arguments to the script. |
Создайте Primed Centos 7 AMI, который включает и сервис, и сервисный контейнер:
|
1
|
packer build -var 'base_image=ami-c7d092f7' -var 'new_image=CentOS-7-x86_64 (Demo)' -var 'script=bootstrap.sh' -var 'access_key=12345674345456454' -var 'secret_key=erewrwrw2424esfsfdfwrwerwe2423wer' -var 'script_args=' aws.centos.json |
Когда команда сборки завершится успешно, у вас будет AMI с установленной службой и с собранным контейнером службы.
Наш конвейер CD некоторое время поддерживал сборки AMI и RPM-сервисы. Мы хотели запустить один контейнерный сервис с минимальным нарушением работы существующего конвейера. Настроив шаблоны Packer, мы получили простой способ с низким риском запустить наши контейнерные сервисы в производство.
Вывод
В настоящее время мы находимся на стадии тестирования наших контейнерных сервисов в этих средах «двойного развертывания». Некоторая часть страха и стигмы, связанной с введением контейнеров в производство, была устранена Мы лучше разбираемся в развертывании контейнеров и работаем над четко определенным конвейером CD.
Этот пост не направлен на устранение каких-либо технических препятствий для развертывания контейнеров в производстве. Он просто предлагает способ использования существующих процессов для внедрения контейнеров в конвейер CD с низким уровнем риска.
Так часто первый шаг самый трудный; этот подход может обеспечить менее пугающий способ приблизить ваши услуги к контейнеризованному будущему в Production.
| Ссылка: | Двойное развертывание: низкий риск запуска контейнеров в производстве от нашего партнера JCG Тома Шоу в блоге Codeship Blog . |