Введение в систему управления конфигурацией Ansible 0:01 Обсуждение системы управления конфигурацией Ansible и её применения. Упоминание о контексте использования Ansible и различных подходах к дизайну инфраструктуры проектов.
Личный опыт и критика 0:48 Автор делится своим личным опытом и видением ситуации. Призыв к конструктивной критике для улучшения знаний.
Выбор между облаками и физическими серверами 1:21 Вопросы, возникающие при строительстве инфраструктуры: использование публичных облаков или физических серверов. Примеры популярных облаков: Amazon Web Services, Google Cloud Platform, Microsoft Azure.
Инфраструктура как сервис IaaS 2:18 Объяснение подхода IaaS: покупка ресурсов виртуальных машин в облаке.
Управляемые сервисы SaaS 3:42 Описание управляемых сервисов: базы данных, брокеры сообщений, Kubernetes. Преимущества управляемых сервисов: минимизация издержек, накопленный опыт.
Компромиссы между облаками и собственными серверами 6:36 Тенденция использования облаков для важных сервисов. Возможность использования облаков для сложных сервисов при наличии собственных серверов.
Критически важные и менее критичные сервисы 7:22 Примеры использования управляемых сервисов: Kubernetes-кластеры, базы данных. Разделение инфраструктуры на критически важную и менее критичную.
Тестовые среды и автоматизация 8:20 Установка тестовых сред на собственных серверах или в облаке без использования дорогостоящих технологий. Важность автоматизации для быстрого восстановления инфраструктуры.
Оценка рисков и возможностей 9:48 Необходимость оценки рисков и возможностей команды при выборе между облаками и управляемыми сервисами.
Будущее виртуальных машин 10:18 Вопрос о будущем виртуальных машин в эпоху облаков и Kubernetes. Роль виртуальных машин как уровня абстракции в системах.
Современные тенденции в разработке 12:06 Необходимость погружения разработчиков в контекст инфраструктуры. Сложности для инфраструктурных инженеров при игнорировании уровня виртуальных машин.
Экономические аспекты 13:00 Сравнение стоимости использования облаков и собственных систем виртуализации. Подчёркивание важности выбора между облачными и самостоятельными решениями.
Введение в Ansible 15:18 Обсуждение запуска команд на удалённых серверах. Введение понятия файла инвентория и абстракции модуля. Использование распределённых потоков для параллельного выполнения.
Автоматизация процессов 15:47 Ansible позволяет автоматизировать сложные процессы. Введение новой абстракции — плейбука, аналога скрипта на специальном метаязыке.
Структура плейбука 16:40 Пример простого плейбука в формате YAML. Метаинформация настраивает общий контекст исполнения. Свойства: хост — группа серверов, сериал — максимальное количество потоков, ремонт юзер — имя пользователя для подключения.
Блок заданий 19:35 Список модулей, которые будут запускаться в указанном порядке. Возможность указания аргументов для каждого модуля. Примеры модулей: ping и shell.
Запуск плейбука 22:08 Использование утилиты ansible-playbook для запуска плейбука. Указание пути к приватному SSH-ключу и файлу инвентория. Процесс сбора фактов о серверах.
Сбор фактов 24:30 Модуль setup для сбора информации о серверах. Анализ каждого сервера и возврат метаинформации в формате JSON.
Документация и примеры 26:25 Важность документации для понимания функционала модулей. Примеры использования модулей ping и shell.
Вывод результатов 28:44 Использование модуля debug для вывода результатов на экран. Регистрация переменной для сохранения результатов команд.
Фильтрация результатов 31:59 Вывод значения переменной на экран с помощью модуля debug. Фильтрация результатов для использования только интересующей информации. Результат исполнения команды сохранён в переменной как строка.
Структура плейбука 33:34 Плейбук состоит из трёх модулей. После завершения исполнения отображается сводка с количеством обработанных этапов и изменений на каждом сервере. Модуль «шел» вернул статус «ченшт», остальные модули не изменили состояние серверов.
Особенности первого запуска 34:49 Первое исполнение плейбука обычно самое длинное, большинство этапов имеют статус «ченшт». При повторном запуске применяются только необходимые изменения, исполнение становится быстрее.
Параллельное исполнение модулей 35:24 Каждый модуль исполняется параллельно на разных серверах, но ждёт завершения предыдущего перед запуском. Такой подход упрощает разработку плейбуков и гарантирует последовательное выполнение команд.
Синхронное ожидание и свободный режим 36:26 Синхронное ожидание может замедлять исполнение, особенно если это не всегда необходимо. Свободный режим позволяет не ждать завершения этапов, что полезно для критически важных серверов.
Модуль «эпи» для установки ПО 37:41 Модуль «эпи» используется для установки программного обеспечения на серверах, аналогичен команде «apt get» в дистрибутивах Debian. Примеры использования модуля: обновление всех пакетов до последней версии, установка конкретного пакета.
Использование директивы «вен» 40:05 Директива «вен» позволяет пропускать исполнение модулей на основе условий. В примере условие проверяется на переменную «резалт», что позволяет исключить сервер «сервер шесть» из установки пакета.
Запуск плейбука и результаты 41:30 При запуске плейбука все сервера, кроме одного, устанавливают пакет. Повторный запуск подтверждает, что сервер «сервер шесть» игнорируется.
Установка пакета с помощью однострочной команды 43:57 Создание файла инвентория на лету, указание IP-адреса сервера и аргументов модуля. Модуль выводит процесс установки пакета на экран.
Сложный сценарий использования 47:03 Пример установки и настройки веб-приложения на серверах с использованием Python и Flask. Использование группы «сайт вэб» для двух серверов.
Структура плейбука для веб-приложения 50:06 Плейбук включает множество этапов и модулей, таких как «апт», «юзер», «гид» и другие. Хорошая документация Ansible помогает разобраться в многообразии модулей и их аргументов.
Введение в модули 52:27 Модуль позволяет устанавливать пакеты из пакетного менеджера дистрибутива. Примеры использования модулей «юзер» и «гид». Функционал модулей повторяет команды операционной системы.
Структура плейбука 54:49 Каждый этап обрамляется свойством «нейм». Определение имён этапов опционально, но желательно для удобства отслеживания. После имени этапа указывается используемый модуль.
Аргументы модулей 56:08 Аргументы модуля легко ищутся в документации. Модуль «эпити» устанавливает пакеты с состоянием «презент». Аргумент «апдейт кэш» обновляет кэш пакетного менеджера.
Добавление пользователя 58:40 Добавление нового пользователя в систему. Принцип импотентности: пользователь добавляется только один раз.
Клонирование репозитория 59:48 Клонирование проекта из публичного репозитория. Использование тегов вместо веток для предотвращения обновлений.
Настройка прав доступа 1:02:31 Установка правильных прав доступа для файлов проекта. Рекурсивное изменение владельца и группы файлов на созданного пользователя.
Установка зависимостей 1:03:58 Установка питоновских зависимостей проекта с помощью модуля «пайп». Установка Flask-фреймворка и других необходимых пакетов.
Сервис uwsgi 1:05:15 uwsgi управляет сервисом, запущенным на Python. Преимущества uwsgi: многопоточность, распределение нагрузки, мониторинг.
Копирование конфигурации 1:08:15 Копирование конфигурации сервиса на все сервера с помощью модуля «копия». Пример конфигурации: запуск сервиса в 10 процессов с 5 потоками каждый. Модуль автоматически заменяет изменённые файлы.
Конфигурационные файлы и их использование 1:09:26 Конфигурационные файлы можно включать в репозиторий напрямую, но это не всегда удобно. Некоторые файлы, например, для Yoda Blue, относятся к настройке всей инфраструктуры, а не конкретного проекта. Разработчики могут не знать о настройках сервисов в продакшне, поэтому удобно выделять конфигурационные файлы в отдельный проект.
Копирование системного скрипта 1:11:04 Копируется системный скрипт инициализации сервиса для встраивания в автозагрузку системы. Модуль SystemD используется для запуска сервиса и добавления его в автозагрузку. Модуль позволяет описать и применить оба свойства одновременно.
Настройка Yoda Blue 1:12:26 Yoda Blue запускает питоновский скрипт на основе конфигурационного файла. Процесс Yoda Blue читает конфигурационный файл и запускает скрипт с указанными настройками.
Настройка Nginx 1:13:22 Nginx настраивается для проксирования трафика на Yoda Blue. Рекомендуется использовать юник-сокет для коммуникации между Yoda Blue и Nginx. Nginx интегрируется с юник-сокетом через доступный модуль.
Добавление пользователя и настройка Nginx 1:14:47 Пользователь Yoda Blue добавляется в группу пользователя для чтения сокета. Копируется конфигурационный файл Nginx для настройки виртуального хоста. Путь к сокету Yoda Blue указывается в конфигурационном файле.
Запуск Nginx и добавление его в автозагрузку 1:16:44 После настройки файла конфигурации запускается Nginx и добавляется в автозагрузку.
Исполнение плейбука 1:17:29 Плейбук поэтапно настраивает систему, создавая файлы конфигурации и запуская сервисы. Процесс установки инкапсулируется, создавая впечатление локальной работы.
Завершение работы плейбука 1:19:17 Плейбук завершает работу, возвращая статус «changed» для изменённых этапов. Система выводит статистику о завершении этапов и возможных ошибках.
Повторное исполнение плейбука 1:20:34 Повторное исполнение плейбука занимает несколько секунд и не требует дополнительной настройки. Механизм проверки необходимости изменений важен для критически важных систем.
Взаимодействие с настроенным сервисом 1:22:51 Для взаимодействия с сервисом используется утилита curl. Заголовок H позволяет Nginx определить, на какой виртуальный хост отправить запрос. После настройки DNS-записи необходимость в заголовках отпадёт.
Перезагрузка конфигурации 1:28:24 Перезагрузка сервиса через перезапуск неэффективна для высоконагруженных сервисов. Enjinix и UDS поддерживают режим рело для перезагрузки файла конфигурации без перезагрузки процесса.
Обработка изменений в плейбуке 1:29:07 Этапы, влияющие на поведение сервиса, должны определять параметр notify для корректного применения изменений. Обработчики активируются только при наличии изменений в конфигурации.
Пример работы плейбука 1:30:01 Добавление нового доменного имени в файл конфигурации Enjinix активирует обработчик. Новая версия конфигурационного файла переписывается на сервер, обработчик выполняется в конце исполнения плейбука.
Безопасность Ansible 1:32:03 Ansible предотвращает ненужные и деструктивные действия, обеспечивая безопасность автоматизированных процессов. Следование стандартным практикам и примерам способствует правильному и безопасному написанию плейбуков.
Настройка распределителя нагрузки 1:33:04 Плейбук для инициализации распределителя нагрузки состоит из трёх этапов и одного обработчика. Используются модули apt, copy и system для установки пакетов, копирования файла конфигурации и старта сервиса HTTP-прокси.
Проверка работы распределителя 1:35:18 Запуск плейбука подтверждает успешную установку и настройку распределителя. Проверка доступности сервиса через распределитель показывает чередование ответов с разных серверов.
Преимущества распределителя нагрузки 1:36:44 Распределитель нагрузки может обслуживать десятки тысяч пользователей благодаря простой логике. Возможность горизонтального масштабирования веб-сервисов и распределителей нагрузки.
Мониторинг и отказоустойчивость 1:38:19 HTTP-прокси мониторит работоспособность серверов, перебрасывая запросы на доступные серверы. При недоступности сервера прокси убирает его из распределения, обеспечивая примитивную отказоустойчивость.
Динамическая настройка конфигурации 1:40:15 Проблема жёсткой настройки списка серверов в конфигурационном файле решается с помощью движка шаблонирования Jinja2. Jinja2 позволяет динамически создавать файлы конфигурации на лету, используя пользовательские переменные и циклы.
Пример использования Jinja2 1:42:10 Модуль template используется вместо модуля copy для динамического создания списка серверов. Обновление файла инвентаря приводит к автоматической настройке новых серверов и обновлению конфигурации сервисов.
Проверка работы шаблона 1:44:23 Удаление существующего файла конфигурации и запуск плейбука подтверждают корректность работы шаблона. Конфигура
Введение в исполнение модулей по условию 1:46:44 Обсуждение важности механизма исполнения модулей по условию в Ansible. Упоминание о его использовании в будущих примерах.
Пример плейбука с условиями 1:47:22 Два этапа плейбука устанавливают пакет vim. Первый этап запускается только на Debian, используя модуль apt. Второй этап запускается только на CentOS, используя модуль yum.
Сбор фактов и условия 1:48:19 Этап сбора фактов определяет дистрибутив. Переменная проверяется в каждом этапе с помощью свойств. Если условие истинно, модуль выполняется, если ложно — игнорируется.
Запуск плейбука 1:49:11 Запуск плейбука на всех машинах из файла инвентория. Использование метагруппы ol для управления исполнением.
Отображение исполнения модуля 1:49:36 Ansible отображает исполнение модуля. Если условие не выполняется, модуль помещается как «скипт».
Заключение и анонс следующего видео 1:49:48 Подведение итогов по возможностям Ansible для автоматизации инфраструктуры. Анонс следующего видео о ролях и расширении возможностей Ansible.
Пример использования Ansible 1:50:40 Пример развёртывания отказоустойчивого кластера MongoDB. Демонстрация возможности самостоятельного развёртывания системы промышленного уровня без помощи третьих лиц.
