ИНТЕРВЬЮ: Понимание модели конвейера выпуска

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

Чтобы избежать таких катастроф, вам нужна надежная и простая в использовании модель процесса для тестирования и внедрения изменений конфигурации в вашу производственную среду. Одним из коллег, активно работавших в этой области, является Тим Минтнер, основатель компании Continuoso, которая специализируется на оптимизации и автоматизации ИТ-операций. Тим ранее работал разработчиком в команде Microsoft Deployment Toolkit и провел более 20 лет карьеры, консультируя некоторые из крупнейших компаний в мире по автоматизации и развертыванию ИТ. Тим выступал на конференциях Microsoft по всему миру, в настоящее время он живет в Остине, штат Техас, и является членом совета директоров Central Texas Systems Management User Group. С Тимом можно связаться в твиттере, используя его никнейм @tmintner. Недавно я подробно брал интервью у Тима о модели конвейера выпуска, которая использует конвейерную модель непрерывной интеграции/непрерывной доставки (CI/CD) DevOps и применяет ее к доставке кода инфраструктуры в центрах обработки данных и облачных средах для упрощения крупномасштабного управления серверами.

IT-ужастик

МИТЧ: Тим, представь нам воображаемый сценарий, объясняющий, почему что-то вроде модели конвейера выпуска необходимо для современных ИТ-отделов.

ТИМ: Сейчас почти полночь в среду, и вы зашли на сервер, ожидая, пока тикают секунды, чтобы внести изменения в вашу производственную среду. Было решено, что лучшее время для отключения сервера — с полуночи до двух часов ночи. Вы устали, проработав целый день, хотя у вас должен был быть выходной после обеда, потому что вы работали допоздна. Однако в три часа дня возникла проблема, из-за которой вы работали почти до шести вечера. Вы смогли провести несколько драгоценных часов со своей семьей, прежде чем уложить их всех спать, и теперь вы пьете кофе с 22:00, чтобы не спать. Вы надеетесь на быстрое изменение в полночь, которое может длиться десять минут, а затем вы можете лечь спать, чтобы вы могли выспаться, чтобы сделать телефонную конференцию в 8 утра утром. Изменение было одобрено, несмотря на то, что комиссии по изменениям было предоставлено мало информации об испытаниях. Команда проекта «протестировала» изменение в своей локальной среде, но на самом деле не было никакого тестирования, которое точно отражало бы производственную среду. Им удалось убедить Совет по изменениям в том, что риск для изменения невелик, поэтому изменение было одобрено.

Часы тикают до полуночи, и вы готовите сервер к внесению изменений. Похоже, все настроено правильно, поэтому вы нажимаете кнопку «Применить», а затем запускаете перезагрузку сервера. Сервер загружается обратно, и вы можете войти в систему. Вы заходите на веб-сайт, видите экран входа и предполагаете, что все работает, потому что у вас нет пароля для входа в систему. Вы считаете, что изменение завершено, выходите из системы и ложитесь спать, надеясь, что сможете немного поспать. Через два часа твой телефон начинает звонить. Менеджер проекта звонит по телефону, лихорадочно сообщает вам, что веб-сайт не работает, и спрашивает, какие изменения вы внесли. После некоторого обсуждения вы можете определить, что пользователи могут войти на сайт, но после входа возникает ошибка, что они не могут найти данные. Итак, в 2:30 утра вы возвращаетесь на сервер и лихорадочно ищете что-то, что могло вызвать проблему. На самом деле нет никакой документации об изменениях, поэтому вы должны прибегнуть к журналам, чтобы увидеть, что произошло. Проходит еще два часа и вот уже ваш менеджер занимается вопросом. Они определяют, что вам нужно отменить изменение, которое вы сделали в полночь. Вы откатываете изменение, перезагружаете сервер, а приложение все равно ломается. Покопавшись в журналах событий, вы можете увидеть, что двумя днями ранее было установлено довольно много патчей, но сервер так и не был перезапущен. Один из этих патчей обновил версию.Net framework на сервере. Изменение не вступит в силу, пока вы не перезапустите сервер в первый раз. Вы решаете удалить этот патч и перезапустить сервер, и приложение начинает работать. Сейчас 6 утра, и через два часа вам позвонят, чтобы обсудить изменения. Вы понимаете, что сегодня больше не уснете, поэтому начинаете пить больше кофе, чтобы пережить следующий день.

Как ИТ-специалист или системный администратор, вы можете легко заменить эту историю чем-то похожим, с которым вы столкнулись лично. За последние несколько лет отрасль начала учиться у крупных технологических компаний, таких как Microsoft, Amazon, Netflix и Google, а также у многих других интернет-стартапов, которым приходится управлять сотнями или тысячами серверов с очень небольшим количеством ИТ-персонала. Эти знания привели к движению DevOps и, в частности, к инфраструктуре как коду. С помощью Infrastructure as Code вы можете преобразовать изменения вашей инфраструктуры с щелчков мышью в сценарии, которые можно изменять и повторять по мере необходимости. Инфраструктура как код позволяет изменениям инфраструктуры быть:

• Версии
• Тестируемый
• Повторяемый

Майкл Грин из Microsoft и Стив Муравски из Chef Software составили отличный технический документ под названием «Модель конвейера выпуска», в котором описаны некоторые практические методы использования инфраструктуры как кода ИТ-специалистом или системным администратором. Давайте углубимся в модель конвейера выпуска.

Обзор модели конвейера выпуска

МИТЧ: Можете ли вы нарисовать нам общую картину того, что представляет собой Модель конвейера выпуска?

TIM: Модель конвейера выпуска берет концепции DevOps модели конвейера непрерывной интеграции/непрерывной доставки (CI/CD) и переводит их в механизм доставки инфраструктуры как кода. Основная концепция заключается в том, что ВСЕ изменения в вашей инфраструктурной среде должны быть доставлены через какой-либо код или интерфейс командной строки.

Модель конвейера выпуска состоит из четырех основных этапов и отвечает на следующие вопросы о нашей инфраструктуре. Они включают:

Источник

• Кто меняет среду?
• Что именно они изменили?
• Когда произошло изменение?

Строить

• Как я буду обнаруживать проблемы в самый ранний момент?
• Могут ли элементы четко сочетаться для получения правильных результатов?
• Как я буду уведомлен о проблеме?

Тест

• Как мы проверяем регуляторные вопросы?
• Откуда мне знать, что это изменение не приведет к сбою?
• Будет ли это изменение работать во всех вариантах моей среды?
• Соответствует ли эта конфигурация требованиям вашего бизнеса?

Выпускать

• Как внести изменения без предоставления долгосрочного административного доступа?
• Нужно ли кому-нибудь выходить из системы перед развертыванием?
• Как обеспечить согласованность служб в моей среде?
• Могу ли я интегрировать управление услугами?

МИТЧ: Хорошо, как насчет распаковки каждой из этих четырех стадий для нас более подробно, начиная со стадии исходного кода.

Исходный этап

ТИМ: Контроль версий чрезвычайно важен для ИТ-операций. В «Руководстве по DevOps» есть отличная цитата: «В отчете Puppet Labs о состоянии DevOps за 2014 год использование контроля версий операционным отделом было самым высоким предиктором как производительности ИТ, так и эффективности организации. На самом деле то, использовал ли Ops контроль версий, было более важным предиктором как производительности ИТ, так и организационной эффективности, чем то, использовал ли Dev контроль версий».

Посмотрим правде в глаза: предоставленные нашим собственным устройствам, мы часто получаем систему управления версиями, которая выглядит примерно так:

• ВажноPowerShellScript_Old.ps1
• ВажноPowerShellScript_latest.ps1
• ВажноPowerShellScript.ps1

Глядя на эти три файла, какой из них вы должны запустить? Система управления исходным кодом сообщит нам, какую версию следует использовать, и даст нам описание всех изменений в этом сценарии.

Есть много отличных систем управления исходным кодом, которые доступны. Велика вероятность, что ваша организация уже имеет систему контроля версий в своей среде разработки, которую вы могли бы использовать. Я настоятельно рекомендую вам использовать систему управления исходным кодом на основе Git. Если вы хотите узнать больше о git и системе управления версиями, я подготовил эту презентацию Sway для нашей локальной группы пользователей в Остине. Если вам нужно создать собственную среду управления исходным кодом, вам следует рассмотреть несколько вариантов, включая Visual Studio Team Foundation Server, Visual Studio Team Services, Github и Gitlab.

Итак, что вы должны включить в свой контроль версий? ВСЕ, кроме паролей или сертификатов. Каждый сценарий PowerShell, файл конфигурации DSC, текстовый файл конфигурации Cisco и т. д. должны находиться в системе управления версиями.

Возвращаясь к нашей предыдущей истории, если бы система управления исходным кодом была на месте, мы бы знали, какие исправления были установлены, кто их установил и почему они были установлены. Это сэкономило бы несколько часов на устранении неполадок в случае возникновения сбоя.

Стадия сборки

Концепция сборки немного сложнее для понимания ИТ-специалистом. Когда я думаю о сборке, я думаю о процессе, который возвращает файл EXE или MSI, который затем может быть выполнен на машине. В этом случае сборка — это, по сути, процесс оркестровки, который берет вашу систему управления версиями по мере ее регистрации, запускает тесты для этой системы управления версиями, а затем запускает этот источник в среде.

Доступно несколько отличных систем сборки, включая Visual Studio Team Services, Jenkins и Team City. Однако все, что нам действительно нужно, чтобы наша система сборки могла делать, это читать из нашей среды управления исходным кодом и запускать сценарий PowerShell. Существует разработанное сообществом решение для создания скриптов сборки под названием Psake (произносится как напиток саке). Ваша система сборки просто должна иметь возможность читать выходные данные Psake, чтобы определить, успешно ли завершена сборка.

Ниже перечислены элементы, которые следует включить в сценарий сборки.

• Линтинг — проверка вашего кода на наличие проблем с форматированием или кода, который не соответствует стандартам вашей организации.
• Тестирование — как модульные тесты ваших скриптов, так и интеграционные тесты для развертывания тестовой среды и проверки результатов.
• Развертывание/выпуск — вызов сценария развертывания, если результаты тестов проходят успешно.

Вот пример скрипта сборки, доступный здесь:

Тестовый этап

Тестирование — самый важный этап конвейера релизов. Без надлежащего тестирования вы, по сути, создаете более эффективный способ создания сбоев в своей среде. Вы должны выполнить четыре типа тестов:

• Linting — проверка синтаксиса или проверка правил, чтобы убедиться, что вы соблюдаете стандарты своей организации. Например, вы можете проверить, есть ли пароли внутри вашего кода или правильно ли установлены комментарии для ваших функций.
• Модульное тестирование — это тест, чтобы убедиться, что весь код в вашем скрипте работает так, как вы думаете. Хороший модульный тест будет включать в себя как положительное тестирование (условия успеха), так и отрицательное тестирование (условия ошибки).
• Интеграционное тестирование — создает тестовую среду и проверяет функциональность, которую можно автоматизировать. Это может включать такие элементы, как аутентификация, доступ к данным, извлечение данных с других серверов и т. д.
• Приемочное тестирование — сюда входят тесты, которые должны запускаться вручную владельцем приложения или службы. Если ручной элемент можно автоматизировать, его следует перенести в интеграционное тестирование.

Pester — это еще один инструмент PowerShell, предоставленный сообществом, который можно использовать для Linting, модульного и интеграционного тестирования. Pester включен как в Windows 10, так и в Windows Server 2016. Pester предоставляет платформу для выполнения ваших тестов и стал стандартом для тестирования с помощью PowerShell. Pester можно даже использовать для проверки работоспособности вашей среды после развертывания. Вот отличный пример использования Pester для проверки работоспособности Active Directory.

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

Стадия выпуска

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

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

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

Пересматривая историю ужасов

МИТЧ: Отлично, спасибо! Теперь, как все это применяется на практике?

ТИМ: Как история ужасов, с которой мы начали, могла измениться с помощью конвейера релизов?

Надлежащее интеграционное тестирование могло выявить проблему с исправлением до развертывания в рабочей среде.
Совет по изменениям мог бы получить более точное представление о влиянии изменения посредством тестирования.
Вам не нужно было бы просыпаться в полночь, чтобы внести изменения. Конвейер развернул бы изменение в запланированные сроки и отправил бы результаты.
Если бы во время развертывания произошел сбой, конвейер мог бы автоматически откатить изменение и отправить результаты команде проекта.
Таким образом, вы могли бы немного поспать и не беспокоиться об изменениях, которые происходили, и бодрствовать для звонка о статусе в 8 утра, чтобы просмотреть результаты изменения!

Начиная

МИТЧ: Хорошо, все это звучит потрясающе, но как те из нас, кто занимается информационными технологиями, могут начать с этого?

ТИМ: Переход от ручного процесса выпуска к автоматизированному может показаться сложной задачей. Вот несколько шагов, которые помогут вам начать работу:

Изучайте PowerShell! Если вы еще этого не сделали, изучите PowerShell. Это имеет решающее значение для будущего вашей карьеры
Начните использовать систему управления версиями. Выберите систему контроля версий и начните использовать ее для всех своих скриптов.
Изучите инструменты сообщества, такие как Psake, Pester и PSDeploy.
При запуске этого процесса начните с простой рабочей нагрузки и полностью автоматизируйте процесс для этой рабочей нагрузки. Разработайте минимально жизнеспособный продукт для своего конвейера релизов, а затем стройте его поверх него. Вам не нужны все возможные тестовые примеры изначально. Вы можете добавить дополнительные тесты по мере необходимости.

Наконец, получайте удовольствие от автоматизации вашей среды! Приложив некоторые усилия, вы уже на пути к возвращению всех своих ночей и выходных!