[Перевод] Модель зрелости инфраструктуры как кода
Примечание переводчика. В «Экспресс 42» мы предоставляем DevOps-консалтинг: проводим аудит существующих в компании клиента процессов разработки и инфраструктурных практик, выявляем узкие места и недостатки, а затем помогаем их устранить. В своих аналитических отчётах мы нередко ссылаемся на модель зрелости инфраструктуры как кода, описанную Гэри Стаффордом ещё в далёком 2016 году. Она помогает определить, на каком уровне сейчас находятся инфраструктурные практики компании, и организовать их систематическое развитие.
Несмотря на то, что статья не нова, она по-прежнему полезна компаниям и инженерам, ведь ключевые концепции инфраструктуры как кода за это время не изменились. Мы перевели материал для внутренних целей, но подумали, что он может быть интересен сообществу. Если вы уже знакомы с идеями IaC, можно сразу перейти в раздел с описанием уровней зрелости. На этом передаю слово Гэри.
Команды разработчиков инфраструктуры и программного обеспечения всё чаще создают и управляют инфраструктурой с помощью автоматизированных инструментов. Этот подход также известен как «инфраструктура как код» (Киф Моррис. Инфраструктура как код).
Подход для управления и описания инфраструктуры через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах или интерактивное взаимодействие (Википедия).
Конвергенция CD, облачных технологий и IaC
В 2011 году Джез Хамбл, бывший сотрудник ThoughtWorks, и Дэвид Фарли опубликовали революционную книгу «Непрерывное развёртывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ». В книге ставится задача автоматизировать «болезненный, рискованный и трудоёмкий процесс сборки, развёртывания и тестирования программного обеспечения».
В течение следующих пяти лет «Непрерывное развёртывание» Хамбла и Фарли внесла значительный вклад в развитие современного феномена DevOps. Согласно Википедии, DevOps — это «культура, движение или практика, которая акцентирует внимание на сотрудничестве и коммуникации разработчиков программного обеспечения и других специалистов по информационным технологиям, автоматизируя при этом процесс доставки программного обеспечения и изменения инфраструктуры».
Параллельно с развитием DevOps продолжался взрывной рост облачных технологий. Amazon стал пионером современных облачных вычислений, запустив в 2006 году Elastic Compute Cloud. Через два года к нему присоединилась компания Microsoft с платформой Azure. В 2010 году Rackspace запустила OpenStack.
Сегодня поставщиков облачных услуг — великое множество. Их предложения делятся на три основные модели: инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS). Поскольку речь пойдёт об инфраструктуре, мы сосредоточимся на IaaS и PaaS. Лидерами в этой области являются Google Cloud Platform, Red Hat, Oracle Cloud, Pivotal Cloud Foundry, CenturyLink Cloud, Apprenda, IBM SmartCloud Enterprise и Heroku, и это лишь некоторые из участников рынка.
Наконец, в июне 2016 года O’Reilly выпускает «Инфраструктура как код. Управление серверами в облаке» Кифа Морриса из ThoughtWorks. Эта важнейшая работа связывает многие концепции, впервые представленные в книге Хамбла и Фарли «Непрерывное развёртывание», с развивающимися процессами и практиками поддержки облачных вычислений.
В этой статье рассматривается применение принципов, заложенных в модели зрелости непрерывной доставки (Continuous Delivery Maturity Model) — инструмента анализа, подробно описанного в книге Хамбла и Фарли «Непрерывное развёртывание», — к лучшим практикам, изложенным в книге Морриса «Инфраструктура как код».
Инфраструктура как код
Прежде чем продолжить, стоит пару слов сказать о том, что такое инфраструктура как код. Ниже приведены четыре примера IaC-определений (как пишет Википедия, «машинообрабатываемых, декларативных файлов»). Код был написан под четыре популярных инструмента: HashiCorp Packer, Docker, AWS CloudFormation и HashiCorp Terraform. На базе этих описаний перечисленные инструменты закажут виртуализированную инфраструктуру в облаке.
HashiCorp Packer
Packer-определение для образа виртуальной машины AWS (AMI) на базе Ubuntu, который хранится в EBS:
{
"variables": {
"aws_access_key": "",
"aws_secret_key": ""
},
"builders": [{
"type": "amazon-ebs",
"access_key": "{{user `aws_access_key`}}",
"secret_key": "{{user `aws_secret_key`}}",
"region": "us-east-1",
"source_ami": "ami-fce3c696",
"instance_type": "t2.micro",
"ssh_username": "ubuntu",
"ami_name": "packer-example {{timestamp}}"
}]
}Docker
Dockerfile для сборки Docker-образа с инстансом MongoDB:
FROM ubuntu:16.04
MAINTAINER Docker
RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927
RUN echo "deb http://repo.mongodb.org/apt/ubuntu" \
$(cat /etc/lsb-release | grep DISTRIB_CODENAME | cut -d= -f2)/mongodb-org/3.2 multiverse" | \
tee /etc/apt/sources.list.d/mongodb-org-3.2.list
RUN apt-get update && apt-get install -y mongodb-org
RUN mkdir -p /data/db
EXPOSE 27017
ENTRYPOINT ["/usr/bin/mongod"]AWS CloudFormation
Настраиваем три сервиса в инстансе. Определение в формате AWS CloudFormation:
services:
sysvinit:
nginx:
enabled: "true"
ensureRunning: "true"
files:
- "/etc/nginx/nginx.conf"
sources:
- "/var/www/html"
php-fastcgi:
enabled: "true"
ensureRunning: "true"
packages:
yum:
- "php"
- "spawn-fcgi"
sendmail:
enabled: "false"
ensureRunning: "false"HashiCorp Terraform
Terraform-определение для создания AWS-инстанса m1.small EC2 на базе Ubuntu, в котором запущен NGINX:
resource "aws_instance" "web" {
connection { user = "ubuntu" }
instance_type = "m1.small"
Ami = "${lookup(var.aws_amis, var.aws_region)}"
Key_name = "${aws_key_pair.auth.id}"
vpc_security_group_ids = ["${aws_security_group.default.id}"]
Subnet_id = "${aws_subnet.default.id}"
provisioner "remote-exec" {
inline = [
"sudo apt-get -y update",
"sudo apt-get -y install nginx",
"sudo service nginx start",
]
}
}Облачная инфраструктура как услуга
Предыдущие примеры дают лишь скромное представление о потенциале инфраструктуры как кода. Ведущие облачные провайдеры, такие как Amazon и Microsoft, предлагают сотни уникальных решений, большинство из которых можно определить и управлять ими через код — инфраструктуру как код.
Какую инфраструктуру можно описать кодом
Многие задаются вопросом: какие типы инфраструктуры можно описать кодом? Хотя поставщики и провайдеры облачных услуг имеют свои уникальные названия и описания, в большинстве случаев инфраструктура делится на несколько общих категорий:
вычислительные ресурсы;
базы данных, кэширование и обмен сообщениями;
хранение, резервное копирование и доставка контента;
сетевое взаимодействие;
безопасность и идентификация;
мониторинг, логирование и аналитика;
инструменты управления.
Модель зрелости непрерывной доставки
Нам также потребуется общее понимание модели зрелости непрерывной доставки. Согласно Хамблу и Фарли, модель зрелости непрерывной доставки (CD) «помогает понять, на каком этапе находится организация с точки зрения зрелости её процессов и практик, и определяет последовательность действий, необходимых для её роста и развития».
Сама модель представляет собой матрицу 5×6, включающую шесть практических направлений и пять уровней зрелости. Каждый из 30 элементов матрицы определяет необходимую дисциплину, которой должна следовать организация, чтобы считаться достигшей опредёленного уровня зрелости в рамках данной практической области.
Практические области
Модель зрелости непрерывной доставки рассматривает шесть широких практических направлений, характерных для большинства организаций, которые занимаются разработкой корпоративного программного обеспечения:
Управление сборкой и непрерывная интеграция.
Окружения и развёртывание.
Управление релизами и комплаенс.
Тестирование.
Управление данными.
Управление конфигурацией.
Уровни зрелости в модели непрерывной доставки
Модель зрелости непрерывной доставки определяет пять уровней зрелости по возрастанию (от −1 до 3) от регрессивного до оптимизационного:
Уровень 3: Оптимизированный — фокус на совершенствовании процессов.
Уровень 2: Количественно управляемый — процессы покрыты метриками и поставлены на мониторинг.
Уровень 1: Согласованный — автоматизированные процессы применяются на протяжении всего жизненного цикла приложения.
Уровень 0: Повторяемый — процесс документирован и частично автоматизирован.
Уровень −1: Регрессивный — процессы не повторяемы, слабо контролируемы и реактивны.
Используем модели зрелости для анализа
Модель зрелости непрерывной доставки — это инструмент анализа. По моему опыту, организации используют модель зрелости одним из двух способов. В первом сначала проводится беспристрастная оценка существующего уровня зрелости во всех практических областях. Затем компания фокусируется на повышении общего уровня зрелости, пытаясь достичь единого уровня во всех практических областях. Второй способ — организация концентрируется на подмножестве наиболее ценных для бизнеса практик или тех направлениях, которые из-за своей относительной незрелости наносят наибольший ущерб другим практическим областям.
Уровни модели зрелости инфраструктуры как кода
Хотя инфраструктура как код прямо не упоминается в модели зрелости непрерывной доставки, многие из её лучших практик входят в последнюю. Например, предписываются автоматический заказ окружений, управляемое развёртывание и использование метрик для постоянного совершенствования.
Вместо того чтобы пытаться вписать инфраструктуру как код в существующую модель зрелости непрерывной доставки, более эффективно, на мой взгляд, просто применить её пять уровней зрелости к инфраструктуре как коду. Для этого я выбрал лучшие практики из книги «Инфраструктура как код», а также добавил кое-что из своего опыта. Практики были распределены по пяти уровням зрелости.
В результате получился первый вариант новой модели зрелости инфраструктуры как кода. Она может применяться как вместе с более широкой моделью зрелости непрерывной доставки, так и отдельно для оценки и дальнейшего развития инфраструктурных практик организации.
IaC уровень −1: Регрессивный
Процессы не повторяемы, слабо контролируемы и реактивны:
часть инфраструктуры развёрнута и управляется кодом;
инфраструктурное развёртывание сопровождается большим количеством действий, выполняемых вручную;
инфраструктурный код написан без использования инструментов и подходов, которые уже устоялись в отрасли разработки программного обеспечения;
инфраструктурный код, процессы и процедуры плохо документированы и не доступны для всех заинтересованных сторон.
IaC уровень 0: Повторяемый
Процессы задокументированы и частично автоматизированы:
весь инфраструктурный код и конфигурации расположены в системе контроля версий;
тестирование, развёртывание и управление инфраструктурой выполняются в рамках автоматизированного пайплайна;
инфраструктура деплоится в виде самостоятельных компонентов;
физические объекты инфраструктуры представлены в виде программных интерфейсов;
реализованы автоматическая проверка безопасности компонент и контроль их зависимостей;
самообслуживание в виде консольного приложения или API-сервиса для использования внутренними потребителями;
весь код, процессы и процедуры задокументированы и доступны;
неизменяемость (immutable) инфраструктуры и процессов.
IaC уровень 1: Согласованный
Автоматизированные процессы применяются на протяжении всего жизненного цикла приложений:
полностью автоматизированные развёртывание и управление инфраструктурой;
минимальное использование неподдерживаемых или самописных инструментов для работы с инфраструктурой;
модульные тесты применяются в объёме, соответствующем требованиям к покрытию кода тестами;
код постоянно тестируется при каждой регистрации в системе контроля версий;
используются шаблоны конфигурационных файлов;
безопасное хранение секретов;
автомасштабирование на основе параметров работы нагрузки, задаваемых пользователями.
IaC уровень 2: Количественно управляемый
Процессы покрыты метриками и поставлены на мониторинг:
используются файлы описания инфраструктуры (Terraform и другие);
реализована возможность выполнения автоматизированного отката (rollback) изменений;
инфраструктура и сервисы сопровождения развёрнуты с поддержкой высокой доступности и устойчивостью к сбоям;
использование сервисов для хранения внешней конфигурации с понятными механизмами внесения изменений;
инфраструктура покрыта мониторингом с настраиваемыми алертами;
весь код, процессы и процедуры хорошо документированы в системе управления знаниями;
инфраструктурный код использует декларативную, а не императивную модель программирования.
IaC уровень 3: Оптимизированный
Фокус — на улучшении процессов:
самовосстанавливающаяся, самонастраиваемая, самооптимизирующаяся инфраструктура;
производительность тестируется и отслеживается на основании бизнес-KPI;
уровень загрузки инфраструктуры оптимально высокий, инфраструктура используется максимально эффективно;
компания придерживается подходов -as-a-service с ориентацией на облако;
создаваемый инфраструктурный код инвариантен относительно поставщика (-ов) облачных услуг.
P. S.
Читайте также в нашем блоге:
