21 задача из опыта DevOps-инженера

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

В начале своего пути мне крайне не хватало представления о том, чем занимается DevOps-инженер и какие задачи перед ним ставятся. Сейчас встречаю людей, которые на старте задаются подобными вопросами. Как говорится, если кто-то прошёл путь и дошёл туда, где бы вы хотели быть, то и у вас получится.

Перед началом

В данном материале не будет решений задач DevOps-инженер, потому что по некоторым из них можно писать отдельный гайд с пояснениями. И объём такого гайда может быть равен отдельной статье. Впрочем, может быть, и стоит этим заняться.

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

Задачи являются реальными кейсами, которые взяты из реальных и в основном растущих проектов. Они также несколько упрощены, хотя, можно подумать, куда уж проще.

Подразумевается, что читатель знаком с Linux, слышал о веб-серверах, IaC-инструментах, понимает, что такое docker, и слышал об инструментах оркестрации и облаках.

Реальные кейсы:

Задача 0:

• Написать Ansible-плейбук, для конфигурации веб-сервера Nginx, который будет настраивать также и firewall-правила, открыв 22, 80, 443 порты.

Комментарий к задаче: вполне заурядный кейс, где используется Ansible, предполагается что конфигурация Nginx уже есть, и дело только за Ansible. Официальная документация Ansible — Клик. Почитать об Nginx — Клик.

Задача 1:

• Описать конфигурацию Nginx, где он будет выполнять роль балансировщика c использованием upstream. 

Комментарий к задаче: если вы не имели дела с Nginx, реализация решения может занять какое-то время, но впоследствии станет полезным скиллом. Про upstream’ы — Клик.

Задача 2:

• Собрать docker image, который включает в себя приложение и веб-сервер Nginx, при запуске открыть порт 80 и добавить контейнер в автостарт системы. 

Комментарий к задаче: в данной задаче можно использовать статическую веб-страницу вместо приложения, например, что-то можно найти на Github.

Задача 3:

• Написать CloudFormation-скрипт, для создания EC2-инстанса и внутренней сети для этого инстанса.

Комментарий к задаче: CloudFormation так же часто используется в проектах завязанных на AWS. Важно уметь пользоваться документацией в целом, потому что многие сервисы, которые предоставляет AWS, можно сконфигурировать с помощью CF-шаблонов. Примечание: можно использовать для тестов тип инстанса ЕС2 t2.micro, чтобы не тратить лишние кровные.

Задача 4:

• Написать bash скрипт, который будет создавать PostgreSQL бэкап. Для автоматического запуска скрипта создаём запись в Cron.

Комментарий к задаче: bash является частью автоматизации и может применяться как в задачах вроде этой, так и в конфигурации CI/CD.

Задача 5:

• Сделать так, чтоб весь вывод скрипта из предыдущей задачи записывался в лог-файл /var/log/backup/backup.log. Формат лога: [Название скрипта][Время выполнения] — полный вывод.

Комментарий к задаче: продолжаем работать с bash’ем. Хорошая практика логировать всю автоматизацию для последущего траблшутинга.

Задача 6:

• Написать скрипт, который будет выполнять проверку состояния диска и, если места меньше чем 85%, то высылать алерт на почту. Для отправки писем прямиком из консоли можно использовать ssmtp клиент. 

Комментарий к задаче: абсолютно не важно какой диск. Неплохая тренировка перевязки инструментов друг с другом. Да-да, здесь можно спорить с реализацией, но не всегда клиенты хотят использовать что-то сторонее, плюс конфигурация и освоение стороннего инструмента занимает такое же время, как аккуратное описание всё bash’ем.

Всё же приходится много иметь дела с Linux.

Задача 7:

• Написать шаблон Cloudformation для создания ECS и ECR, в котором мы будем разворачивать контейнер.

Комментарий к задаче: здесь нужно посидеть с документацией AWS.

Задача 8:

• Описать Dockerfile, который содержит Python приложение (или, например, можно использовать контейнер со статической веб-страницей из задачи 2), запушить его в ECR, откуда его возьмёт CodePipeline и развернёт в ECS.

Комментарий к задаче: здесь может понадобиться знание IAM, для генерации токенов для CodePipeline и понимание, как работает ECS и ECR. Чем дальше тем ECS и ECR чаще встречаются в проектах.

Задача 9:

• Настройка мониторинга в связке c Prometheus+Grafana+Node exporter+Alertmanager. 

Комментарий к задаче: если инфраструктура не хостится где-то в облаке или нужны более гибкие метрики, то может использоваться что-то стороннее. Часто это что-то из опенсорс. Для практики можно взять один-два инстанса в том же AWS t2.micro чтоб «распробовать» эту связку и как можно тоньше настроить мониторинг основных показателей серверов и систем. Вот пример метрик из Node exporter для Grafana — Клик.

Задача 10:

• Описать конфигурацию мониторинг сервера в Ansible. Конфигурация должна включать настройку Prometheus+Grafana+Alertmanager на сервере мониторинга и конфигурацию с открытием портов в firewall правилах на серверах, которые мы хотим мониторить. Для мониторинга инстансов, ставим Node exporter, который выводит метрики на порт 9100 (его мы и открываем на отслеживаемых серверах). В целях безопасности порт 9100 открываем только для мониторинг инстанса. 

Комментарий к задаче: чтобы не вести отдельно документацию, часто можно просто прочитать IaC-скрипты, которые конфигурируют то или иное окружение. Полезно и для соблюдения идентичности окружений.

Задача 11:

• Настроить Gitlab Ci пайплайн для сборки и деплоя контейнера в окружение. В качестве окружения — для упрощения — это может быть инстанс где-либо, в качестве контейнера может быть что угодно (даже ранее собранный контейнер со статической веб страницей). То есть при коммите, мы запускаем наш пайплайн, собираем docker image, и деплоим его на наш тестовый инстанс, где потенциально его могут опробовать — например, тестировщики.

Комментарий к задаче: CI/CD-инструменты, такие как Gitlab CI, Jenkins, Circle CI, TeamCity, и облачные, такие как Azure DevOps, Google Cloud Build, AWS CodePipeline и подобные, очень часто используются на различных проектах. В целом, у всех подход очень похож: собрать, протестировать, доставить, но, как всегда, дьявол в мелочах.

Задача 12:

• Поднять Kubernetes cluster из трёх нод. Сделать первичную конфигурацию и задеплоить в него контейнер. 

Комментарий к задаче: не самый часто встречающийся кейс, но подняв несколько раз кластер и настроив в CI/CD, можно освоить очень полезный навык, а уж если хочется больше задач по K8s, то их можно найти здесь — Клик. Также есть отличный курс — Kubernetes the hard way, которй немного через боль может поставить правильное понимание организации и работы кластера.

Задача 13:

• Распарсить JSON данные и сохранить их в CSV. Сгенерировать JSON можно здесь — Клик. 

Комментарий к задаче: куда же без скриптовых задач. Для решения можно использовать Bash, Python или что-то другое. Пока важен именно результат, а уж пути, какими мы к нему придём, можно в последствии оптимизировать.

Задача 14:

• Описать в Terraform создание в AWS-инстанса EC2 с EBS-томом .

Комментарий к задаче: в продолжение IaC, Terraform часто встречается на различных проектах, но не всегда им можно достичь желаемого состояния инфраструктуры. Например, в том же Azure приходилось столкнуться с тем, что Terraform мог далеко не всё, и приходилось делать связку PowerShell и Terraform.

Задача 15:

• Есть инфраструктура в AWS, и окружения периодически «разъезжаются» — имеется в виду, что в процессе эксплуатации инфраструктуры, имеющей несколько окружений, например production, staging, dev, qa, могут со временем начинать отличаться друг от друга. Нужно описать все элементы инфраструктуры с помощью CloudFormation. Инфраструктура включает в себя, шесть EC2-инстансов: два бэкэнда, два фронтэнда, балансировщик и сервер для сбора аналитики с бэкэнда. У каждого сервера должен быть открыт 22-й порт, только для перечня адресов VPN. У балансировщика и фронтэнда должны быть открыты 80-й и 443-й порты, у бэкэнда — 5000-й, 80-й, 443-й, у сервера сбора аналитики — 6000-й, 80-й и 443-й. При этом, все сервера не должны быть видны снаружи, кроме балансировщика. Скрипт должен быть универсален для всех окружений. 

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

Более абстрактные задачи:

• Есть сервис, где периодически что-то происходит, из-за чего он медленнее обрабатывает запросы пользователей. Нужно посмотреть логи. Важно уметь искать в логах нужное событие. Быстро ориентироваться в бесконечно больших лог -файлах, при этом не нагружая диск при открытии(да здравствует less).
• Нужно написать Ansible -скрипт, который можно будет применить на нескольких окружениях с разными внутренними IP-адресами, DNS-именами и секретами. Важно уметь правильно разделять и описывать конфигурации разных окружений. То есть использовать одни и те же роли для всех окружений, но разделять их с помощью inventory файлов и файлов с переменными и секретами.
• Необходимо нарисовать график существующей инфраструктуры. Периодически клиент такое тоже может попросить сделать, например, когда проходит аудит ,и регуляторы в сфере деятельности компании/проекта требуют определённой отчётности об организации инфраструктуры, данных, и прочего. Популярный инструмент для рисования графиков и блок-схем — Клик.
• Сделать анализ облачных провайдеров и выбрать подходящий под определённые требования. Например: клиент расположен в Канаде, гос регулятор выдвигает требования, что данные пользователей должны хранится только в Канаде, соответственно, сразу отпадает перечень провайдеров, которые расположены вне требуемой зоны. Важно провести глубокую аналитику всех канадских провайдеров, их перечня услуг, готовых решений, цен и так далее. Также важно смотреть на количество локаций дата центров, реальных отзывов и множество других переменных.
• Провести оптимизацию существующей инфраструктуры или её части. Под оптимизацией в основном имеется в виду снижение ценника за единицу времени работы инфраструктуры. Здесь может быть целый список нюансов, и конкретизировать что-либо крайне трудно. Но такие кейсы могут быть в практике, потому что под быстро меняющиеся требования растущего бизнеса нужно успевать подстраиваться.

Резюме

Если вы только в начале пути, решение этих и подобных задач может стать хорошим толчком в прокачке автоматизации, что является неотъемлемой частью DevOps и прочих *Ops практик. Если у вас что-то не выходит, это абсолютно нормально. Не бойтесь пробовать, экспериментировать и у вас всё получится.