Как стать инженером DevOps за шесть месяцев или меньше, часть 2: конфигурация

контейнер Программа перевода самородков Эксплуатация и техническое обслуживание Ansible

фотоReto SimonetОпубликовано вUnsplash

Примечание. Это вторая часть серии «Как стать инженером DevOps за шесть месяцев или меньше». Нажмите здесь, чтобы просмотреть первую часть.здесь.

Давайте сделаем краткий обзор предыдущей проблемы.

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

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

Базовая вводная схема DevOps

И хорошее понимание инструментов и навыков, основанных на этих основах (см. изображение ниже).

Совет: Ваша цель — сначала выучить синюю часть шрифта слева направо, а затем фиолетовую часть шрифта слева направо.

Хорошо, вернемся к нашей теме. В этой статье мы представим маршрут обучения на приведенной выше диаграмме.ПервыйЭтап: Настройка.

Диаграмма введения этапа настройки

Что происходит на этапе настройки?

Поскольку код, который мы создаем, должен выполняться на машине, этап настройки фактически создает инфраструктуру для запуска кода.

В прошлом настройка инфраструктуры была длительным, трудоемким и подверженным ошибкам испытанием.

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

Однако оказывается, что выполнять эти задачи кликами — плохая идея.

Почему ты это сказал?

Потому что кнопка нажата:

  1. склонность к ошибкам (человеческая ошибка),
  2. нет управления версиями (клики не могут храниться в git),
  3. неповторяемость (больше машин = больше кликов),
  4. и не подлежит тестированию (не знаю, действительно ли мои клики работают или идут не так).

Например, подумайте обо всей работе, необходимой для настройки среды разработки... затем инициализации среды... затем системного тестирования... затем подготовки... затем развертывания рабочей среды в США... затем развертывания рабочей среды в ЕС. Окружающая среда... это может стать очень утомительным и раздражающим очень быстро.

Поэтому нужен новый подход. Этот новый способАрхитектура как код, вот что такое эта фаза конфигурации.

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

Примечание. «Вычислительные ресурсы» — это все, что необходимо для правильной работы приложения в продукте: вычислительные ресурсы, хранилище, сеть, база данных и т. д. Отсюда и название «Архитектура как код».

Кроме того, это означает, что мы будем развертывать через архитектуру как код, а не «укажи и щелкни»:

  1. существуетTerraformзапишите желаемое состояние инфраструктуры в
  2. сохранить его в нашем исходном контроле,
  3. через формальныйPull RequestПроцесс получения обратной связи,
  4. есть тест,
  5. Выполнение предоставляет все необходимые ресурсы контейнера.

Теперь возникает очевидный вопрос: «Почему Terraform? Почему не Chef, Puppet, Ansible, CFEngine, Salt, CloudFormation или что-то еще?»

хороший вопрос!

Короче говоря, я считаю, что вам следует изучить Terraform по следующим причинам:

  1. Это модно, поэтому есть много возможностей для работы
  2. легче учиться, чем другие
  3. это кроссплатформенный

Теперь, вы можете выбрать один из них и добиться успеха? Абсолютно!

ПРИМЕЧАНИЕ. Эта область быстро развивается и очень запутана. Я хотел бы потратить несколько минут, чтобы поговорить о недавней истории и о том, как я видел ее развитие. Такие вещи, как Terraform и CloudFormation, используются для обеспечения инфраструктуры, а такие вещи, как Ansible, используются для настройки инфраструктуры.

Как правило, такие вещи, как Terraform и CloudFormation, использовались для обеспеченияинфраструктура, а для настройки используется что-то вроде Ansibleинфраструктура.

Вы можете думать о Terraform как об инструменте для создания фундамента, Ansible кладет дом на вершину, а затем развертывает приложения (например, Ansible) в соответствии с вашими потребностями.

Как понять эти схемы введения инструментов

Другими словами, вы используете Terraform для создания виртуальной машины, затем используете Ansible для настройки сервера и, возможно, развертывания с его помощью своего приложения.

Эти инструменты часто используются вместе.

Однако то, что может сделать Ansible (если не все), может и Terraform. Обратное также верно.

Не позволяйте этому беспокоить вас. Просто знайте, что Terraform — один из лучших инструментов в пространстве кода инфраструктуры, поэтому я настоятельно рекомендую вам начать именно с него.

Фактически, опыт работы с Terraform + AWS — один из самых востребованных навыков прямо сейчас!

Однако, если вы хотите отложить поддержку Ansible для Terraform, вам все равно нужно знать, как программно настраивать серверы массово, верно?

ненужный!

Вообще-то я предсказываю что-то вроде AnsibleУправление конфигурациейИнструменты будут менее важны, в то время как такие инструменты, как Terraform или CloudFormationБазовая конфигурацияРоль инструментов будет возрастать.

Почему ты так говоришь?

из-за так называемого "Неизменяемое развертывание".

Короче говоря, это относится к практике не изменять развернутую инфраструктуру. Другими словами, ваша единица развертывания — это виртуальная машина или контейнер Docker, а не фрагмент кода.

Поэтому вместо развертывания кода в кластере виртуальных машин вы развертываете всю виртуальную машину с уже скомпилированным кодом.

Вы не меняете настройку виртуальной машины, вы развертываете новую виртуальную машину с измененной конфигурацией.

Вместо исправления рабочих машин вы развертываете новые машины, на которые уже установлены исправления.

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

Вы должны видеть, что я имею в виду.

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

Примечание. Неизменяемое развертывание требует, чтобы конфигурация была отделена от вашего кода. Пожалуйста, прочтите [Приложение 12 Factor](12factor.net/), где это подробно описано.(и другие замечательные идеи!). Это обязательное чтение для практиков DevOps.

Разделение кода и конфигурации имеет важное значение — вы не хотите повторно развертывать все приложение каждый раз, когда вы меняете пароль базы данных. Вместо этого убедитесь, что приложение может получить его из внешнего хранилища конфигурации (SSM/Consul/и т. д.).

Кроме того, вы можете легко увидеть, что с ростом неизменяемого развертывания такие инструменты, как Ansible, начинают играть менее заметную роль.

Потому что вам нужно только настроитьодинserver и развернуть его несколько раз как часть автоматически масштабируемого кластера.

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

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

Помимо контейнеров, для тех, кто только начинает работать с Terraform, предоставление инфраструктуры AWS с помощью Terraform — это шаблон DevOps из учебника, который вам действительно нужно освоить.

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

На самом деле какие-то умники написали подробную статью о том, как развернуть ELK-кластер в AWS.статья- Если вы хотите увидеть, как это делается на практике, щелкните ссылку выше, чтобы увидеть это.

Кроме того, вы можете полностью отключить удаленный доступ, что более безопасно, чем большинство людей, которые этого не делают!

Таким образом, наше полностью автоматизированное путешествие «DevOps» начинается с предоставления вычислительных ресурсов, необходимых для запуска кода, — этапа предоставления. И лучший способ добиться этого — неизменяемое развертывание.

Наконец, если вам интересно, с чего начать, комбинация Terraform + AWS — отличное место для начала вашего пути!

Это все, что нужно сделать на этапе «настроить».

Содержание третьей части [здесь](GitHub.com/rare earth/gold-no…-less-part-3-version.face)!

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

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллекти другие поля, если вы хотите видеть больше качественных переводов, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории