Как стать автором
Обновить
Флант
DevOps-as-a-Service, Kubernetes, обслуживание 24×7

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

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров3.5K
Автор оригинала: Gary Stafford

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

Используем модели зрелости для анализа

Модель зрелости непрерывной доставки — это инструмент анализа. По моему опыту, организации используют модель зрелости одним из двух способов. В первом сначала проводится беспристрастная оценка существующего уровня зрелости во всех практических областях. Затем компания фокусируется на повышении общего уровня зрелости, пытаясь достичь единого уровня во всех практических областях. Второй способ — организация концентрируется на подмножестве наиболее ценных для бизнеса практик или тех направлениях, которые из-за своей относительной незрелости наносят наибольший ущерб другим практическим областям.

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

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

Хотя инфраструктура как код прямо не упоминается в модели зрелости непрерывной доставки, многие из её лучших практик входят в последнюю. Например, предписываются автоматический заказ окружений, управляемое развёртывание и использование метрик для постоянного совершенствования.

Вместо того чтобы пытаться вписать инфраструктуру как код в существующую модель зрелости непрерывной доставки, более эффективно, на мой взгляд, просто применить её пять уровней зрелости к инфраструктуре как коду. Для этого я выбрал лучшие практики из книги «Инфраструктура как код», а также добавил кое-что из своего опыта. Практики были распределены по пяти уровням зрелости.

В результате получился первый вариант новой модели зрелости инфраструктуры как кода. Она может применяться как вместе с более широкой моделью зрелости непрерывной доставки, так и отдельно для оценки и дальнейшего развития инфраструктурных практик организации.

IaC уровень −1: Регрессивный

Процессы не повторяемы, слабо контролируемы и реактивны:

  • часть инфраструктуры развёрнута и управляется кодом;

  • инфраструктурное развёртывание сопровождается большим количеством действий, выполняемых вручную;

  • инфраструктурный код написан без использования инструментов и подходов, которые уже устоялись в отрасли разработки программного обеспечения;

  • инфраструктурный код, процессы и процедуры плохо документированы и не доступны для всех заинтересованных сторон.

IaC уровень 0: Повторяемый

Процессы задокументированы и частично автоматизированы:

  • весь инфраструктурный код и конфигурации расположены в системе контроля версий;

  • тестирование, развёртывание и управление инфраструктурой выполняются в рамках автоматизированного пайплайна;

  • инфраструктура деплоится в виде самостоятельных компонентов;

  • физические объекты инфраструктуры представлены в виде программных интерфейсов;  

  • реализованы автоматическая проверка безопасности компонент и контроль их зависимостей;

  • самообслуживание в виде консольного приложения или  API-сервиса для использования внутренними потребителями;

  • весь код, процессы и процедуры задокументированы и доступны;

  • неизменяемость (immutable) инфраструктуры и процессов.

IaC уровень 1: Согласованный

Автоматизированные процессы применяются на протяжении всего жизненного цикла приложений:

  • полностью автоматизированные развёртывание и управление инфраструктурой;

  • минимальное использование неподдерживаемых или самописных инструментов для работы с инфраструктурой;

  • модульные тесты применяются в объёме, соответствующем требованиям к покрытию кода тестами;

  • код постоянно тестируется при каждой регистрации в системе контроля версий;

  • используются шаблоны конфигурационных файлов;

  • безопасное хранение секретов;

  • автомасштабирование на основе параметров работы нагрузки, задаваемых пользователями.

IaC уровень 2: Количественно управляемый

Процессы покрыты метриками и поставлены на мониторинг:

  • используются файлы описания инфраструктуры (Terraform и другие);

  • реализована возможность выполнения автоматизированного отката (rollback) изменений;

  • инфраструктура и сервисы сопровождения развёрнуты с поддержкой высокой доступности и устойчивостью к сбоям;

  • использование сервисов для хранения внешней конфигурации с понятными механизмами внесения изменений;

  • инфраструктура покрыта мониторингом с настраиваемыми алертами;

  • весь код, процессы и процедуры хорошо документированы в системе управления знаниями;

  • инфраструктурный код использует декларативную, а не императивную модель программирования.

IaC уровень 3: Оптимизированный 

Фокус — на улучшении процессов:

  • самовосстанавливающаяся, самонастраиваемая, самооптимизирующаяся инфраструктура;

  • производительность тестируется и отслеживается на основании бизнес-KPI;

  • уровень загрузки инфраструктуры оптимально высокий, инфраструктура используется максимально эффективно;

  • компания придерживается подходов -as-a-service с ориентацией на облако;

  • создаваемый инфраструктурный код инвариантен относительно поставщика(-ов) облачных услуг.

Источник: IaC_Maturity_Model v2.1
Источник: IaC_Maturity_Model v2.1

P. S.

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

Теги:
Хабы:
+30
Комментарии0
2

Публикации

Информация

Сайт
flant.ru
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия
Представитель
Александр Лукьянов