Модель зрелости инфраструктуры как кода

Примечание переводчика. В «Экспресс 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. Управление сборкой и непрерывная интеграция.

2. Окружения и развёртывание.

3. Управление релизами и комплаенс.

4. Тестирование.

5. Управление данными.

6. Управление конфигурацией.

Уровни зрелости в модели непрерывной доставки

Модель зрелости непрерывной доставки определяет пять уровней зрелости по возрастанию (от −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.

Читайте также в нашем блоге:

• Наш опыт интеграции внешних DevOps-команд в команды клиента: этапы, процессы, трудности, неочевидные нюансы

• CNCF White Paper по observability: инструменты, виды, стратегии и проблемы

• Один YAML до катастрофы: «детские» ошибки администраторов Kubernetes