Освежим память по-быстрому
В первой части я утверждал, что работа инженера DevOps заключается в создании полностью автоматизированных цифровых конвейеров, которые перемещают код от машины разработчика к производству. Для эффективного выполнения этой работы требуется понимание основ, которыми являются ОС, язык программирования и облачный сервис хранения данных, а также хорошее понимание базирующихся на этой основе инструментов и навыков.
Напомню, что ваша цель состоит в том, чтобы сначала слева направо изучить вещи синего цвета, а затем также слева направо изучить вещи фиолетового цвета. Сейчас мы рассмотрим первый из 6 месяцев обучения, посвященный конфигурированию.
Что же происходит на этапе конфигурирования? Поскольку код, который мы создаем, нуждается в машинах для запуска, этап конфигурирования фактически создает инфраструктуру, которая и выполняет наш код.
В прошлом создание инфраструктуры обеспечения было длительным, трудоемким и подверженным ошибкам испытанием. Теперь, поскольку у нас есть наше потрясающее облако, вся подготовка может быть выполнена одним нажатием кнопки. Или, по крайней мере, несколькими нажатиями. Однако оказывается, что нажимать кнопки для выполнения этих задач — плохая идея, потому что это означает:
- склонность к ошибкам (а люди совершают ошибки);
- игнорирование версий (нажатия кнопок не могут храниться в Git-репозитории);
- невоспроизводимость и неповторяемость (больше машин = больше кликов);
- невозможность проверки на лету (я без понятия, будут ли мои клики действительно работать или наоборот все испортят).
Например, подумайте обо всей работе, необходимой для обеспечения вашей среды разработки… затем среды int… затем QA… затем staging… затем prod в США… затем prod в ЕС… это очень быстро станет довольно утомительным и раздражающим. Поэтому вместо механических кликов кнопкой мыши используется новый способ под названием «infrastructure-as-code», и именно об этом пойдет речь на данном этапе конфигурирования вашей системы. «Инфраструктура как код» означает конфигурирование системы с помощью файлов конфигурации, а не через ручное редактирование конфигураций на серверах или интерактивное взаимодействие. Данный способ может представлять собой как декларативное, так и скриптовое описание инфраструктуры. В соответствии с передовой практикой DevOps, «infrastructure-as-code» требует, чтобы любая работа, необходимая для предоставления вычислительных ресурсов, выполнялась только с помощью кода. Под «вычислительными ресурсами» я подразумеваю все необходимое для правильного запуска приложения в prod: собственное вычислительные ресурсы, хранилище, сеть, базы данных и т. д. Отсюда и название — «инфраструктура как код”.
Кроме того, это означает, что вместо того, чтобы «прощелкать» наш путь через механическое развертывание инфраструктуры, мы будем:
- описывать желаемое состояние инфраструктуры в Terraform;
- хранить его в нашей системе управления версиями Source Code Control;
- проходить через формальный процесс Pull Request, чтобы получать обратную связь;
- тестировать работоспособность;
- выполнять конфигурирование с целью обеспечить работу системы всеми необходимыми ресурсами.
Почему это, а не то?
Очевидный вопрос: „Почему именно Terraform? Почему не Chef, Puppet, Ansible, CFEngine, Salt или CloudFormation?”. Хороший вопрос! При его обсуждении были пролиты целые бочки виртуальных чернил. Я думаю, что вы должны изучить Terraform, потому что:
- это очень модно, поэтому у вас будет куча возможностей для трудоустройства;
- это легче усваивается;
- это кроссплатформенный продукт.
Конечно, вы можете выбрать любой другой вариант и тоже добиться успеха. Но я вынужден заметить следующее. Данная отрасль быстро и достаточно хаотично развивается, но я вижу такое развитие событий: традиционно такие вещи, как Terraform и CloudFormation использовались для обеспечения инфраструктуры, в то время как Ansible и ему подобные системы использовались для ее настройки.
Поэтому вы можете считать Terraform инструментом для создания фундамента, а Ansible – подъемным краном для возведения дома на этом фундаменте, с последующим развертыванием приложения в качестве крыши (развертывание тоже возможно осуществить с помощью Ansible).
Другими словами, вы создаете свои виртуальные машины с помощью Terraform, а затем используете Ansible для настройки серверов, а также развертывания своих приложений. Традиционно эти вещи используются именно таким образом.
Однако Ansible может сделать многое из того (если не все), что может сделать Terraform, но верно и обратное утверждение. Пусть это вас не беспокоит. Просто знайте, что Terraform является одним из лидирующих инструментов отрасли «infrastructure-as-code», поэтому я настоятельно рекомендую вам начать именно с него.
На самом деле, опыт работы со связкой Terraform+AWS является одним из самых востребованных навыков DevOps – инженера. Но даже если вы собираетесь пожертвовать Ansible в пользу Terraform, вам все равно нужно знать, как программно настроить большое количество серверов, не так ли? Оказывается, что это вовсе не обязательно!
Неизменяемое развертывание
Я предсказываю, что инструменты управления конфигурацией, такие как Ansible, будут терять свою важность, в то время как инструменты подготовки инфраструктуры, такие как Terraform или CloudFormation, будут ее наращивать. И все это из-за того, что называется “неизменяемым развертыванием“. Проще говоря, это означает практику никогда не изменять развернутую инфраструктуру, то есть ваша единица развертывания — это виртуальная машина или контейнер Docker, а не фрагмент кода.
При этом вы не развертываете код на набор статических виртуальных машин, а развертываете целые виртуальные машины вместе с «запеченным» в них кодом. Вы не меняете способ настройки виртуальных машин, а на месте развертываете новые виртуальные машины с нужной конфигурацией. Вы не исправляете машины prod, вы развертываете новые, уже исправленные машины.
Вы не запускаете один набор виртуальных машин в dev, а другой набор машин в prod, они все одинаковы. На самом деле вы можете совершенно безопасно отключить весь SSH- доступ ко всем машинам prod, потому что там нечего делать -нет настроек для изменения, нет журналов для просмотра (подробнее я расскажу о журналах позже). При правильном использовании это очень мощный шаблон, который я настоятельно рекомендую использовать!
Неизменяемые развертывания требуют, чтобы конфигурация была отделена от вашего кода. Пожалуйста, прочитайте манифест The Twelve-Factor App, который подробно описывает это (и другие удивительные идеи!) в мельчайших подробностях. Это обязательное чтение для практикующих DevOps.
Отсоединение кода от конфигурации очень важно, ведь вы же не хотите повторно развертывать весь стек приложений каждый раз, когда вы «ворошите» пароли своей базы данных. Вместо этого убедитесь, что приложения извлекают его из внешнего хранилища конфигураций (SSM/Consul/etc.). Кроме того, вы легко увидите, как с появлением неизменяемых развертываний такие инструменты, как Ansible, начинают играть менее заметную роль. Причина в том, что вам нужно настроить только один сервер и развернуть его целую кучу раз в составе вашей группы автоматического масштабирования.
Если вы создаете контейнеры, то вам по определению нужны неизменяемые развертывания. Вы же не хотите, чтобы ваш dev-контейнер отличался от контейнера QA, который к тому же будет отличаться от prod-контейнера. Вам нужен совершенно одинаковый контейнер во всех средах, так как это позволяет избежать смещения конфигурации и упрощает откат в случае возникновения проблем.
Помимо контейнеров, для тех людей, которые только начинают свою работу, подготовка инфраструктуры AWS с использованием Terraform представляет собой хорошую учебную модель DevOps и то, что вам действительно нужно освоить.
Но подождите… что делать, если вам нужно посмотреть журналы, чтобы устранить проблему? В этом случае для просмотра журналов не нужно входить в машины, достаточно просмотреть централизованную инфраструктуру ведения журналов для всех ваших логов. Какой-то парень уже опубликовал на данном ресурсе подробную статью, как развернуть стек ELK в AWS ECS, можете ее прочитать, чтобы узнать, как это делается на практике. Опять же, вы можете полностью отключить удаленный доступ и чувствовать себя намного безопаснее, чем большинство присутствующих там людей.
Подводя итог, можно сказать, что наше полностью автоматизированное путешествие “DevOps» начинается с подготовки вычислительных ресурсов, необходимых для выполнения этапа настройки кода. И лучший способ добиться этого — использовать неизменяемые развертывания. Если вас интересует, с чего следует начинать, возьмите за отправную точку комбинацию Terraform+AWS!
Вот и все, что касается этапа конфигурации, в следующей статье мы рассмотрим второй этап — версии.
Продолжение будет совсем скоро…
Немного рекламы :)
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Комментариев нет:
Отправить комментарий