Основной набор повседневных инструментов DevOps-инженера

Антон Кузнецов — руководитель группы системных инженеров отдела DevOps компании Кометрика, описал все значимые инструменты и сервисы, с которыми ежедневно работает его команда.

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

Антон Кузнецов

Руководитель группы системных инженеров отдела DevOps компании Кометрика.

В Кометрике применяется очень много облачных сервисов, начиная с IaaS, PaaS и заканчивая SaaS. Это обусловлено тем, что лицензированное ПО, как правило, равнозначно по цене как для Self hosted, так и для Cloud. При равнозначности цены, облачные решения гораздо быстрее по внедрению, проще в поддержке и обслуживании, а также гибче тарифицируются.

1. Jira & ConfluenceZoom & Telegram & SlackiTerm || Terminal || ConsoleGitPackerTerraformAws Cli & OpenStack cli & etcYAML editCI/CDDocker (kaniko/werf/etc) — gradle/npmKubectlAnsible & HelmSentry vs. ELKPrometheus & GrafanaРазное

Jira & Confluence

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

Таск-трекер — незаменимый инструмент, автоматизирующий проектную работу. Он помогает проще, быстрее и эффективнее ставить и выполнять задачи. На рынке существует множество подобных систем, но для себя мы выбрали Jira, как один из самых продвинутых и гибких инструментов в своем роде. В нем можно настроить совершенно любой процесс, где можно кастомизировать практически все. Плюс, не стоит забывать про возможную автоматизацию, например, в нашей компании есть типовой воркфлоу для проектов, интегрированный с Gitlab CI, что позволяет менять статус задач автоматически по коммиту, мр или деплою. Также есть ряд кастомизированных проектов для процессов presale, закупок и т.д.

Zoom & Telegram & Slack

Удаленный формат работы перенес практически все общение в мессенджеры. Неважно что вы используете Telegram или Slack, 80% общения проходит именно там, плюс к этому добавляются различные боты, нотификации от Alertmanager и другие самые различные интеграции.

Сейчас становится модным внедрять ChatOps — как пример того, что можно управлять pipeline вашей CI/CD системы через мессенджер. Отдельное внимание в новых условиях работы отводится системам видеоконференций Zoom, Skype и другим, которые позволяют нам обеспечить ежедневные митапы. Многое пришлось переосмыслить. Например то, что офис может существовать там где ты есть, достаточно только включить камеру на звонке. Подобные системы позволяют практически полностью перевести общение из офиса в онлайн, где можно провести презентацию, совещание, командное мероприятие или просто посмотреть на коллег. Но не стоит забывать и про старую добрую почту, по которой проходит вся деловая переписка.

iTerm || Terminal || Console

Тут даже добавить нечего. Must have. Всегда и везде! Открытый терминал как старая привычка, где лучше написать пару команд, чем все делать в GUI интерфейсе. В жизни DevOps инженера всегда присутствует этот инструмент, невозможно обойтись без него. Проводя собеседования молодых системных инженеров сталкиваешься с тем, что они не так хорошо разбираются в консольных утилитах. Но DevOps — это не просто человек, который умеет настраивать Pipeline в CI/CD, но и тот, кто может провести дебаг в случае, если что-то не собирается или неправильно работает. Хорошие познания в Linux — очень важный скилл, который сильно помогает в ежедневной работе. В нашей компании у каждого DevOps-инженера не один год опыта системного администрирования.

Git

Лет 10 назад, когда Git только начинал набирать популярность, для системных администраторов достаточно было знать пару команд для работы с ним: clone/pull/add/commit/push. Все остальное выполняли разработчики, так как для них это был рабочий инструмент, а сисадмину нужно было просто вылить код на сервер.

Сейчас все по-другому, все по-новому. Теперь Git — неотъемлемая часть работы любого IT сотрудника, почти все данные перекочевали в Git. Мы начали строить pipeline рядом с кодом, как единое целое, там же мы конфигурируем сборку и деплой. Сама инфраструктура из железных серверов переползла в облака, где стало применяться понятие IaC (Инфраструктура как код). Теперь ресурсы описываются через YAML/JSON конфиги и хранятся в Git.

Packer

Очень удобный инструмент. Когда приходится поднимать большое количество однотипных виртуальных машин в облаке, Packer позволяет практически в любом окружении, будь то virtualbox/vagrant или само облако, без проблем создать образ виртуальной машины, после чего загрузить облако с нужным названием.

Terraform

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

Terraform — идеальный инструмент по управлению ресурсами в облаке. Через него можно полностью управлять: сетями, фаерволами, роутерами, ip-адресами, балансировщиками, жесткими дисками, виртуальными машинами и многим другим. Также есть возможность создания шаблонов, так называемых модулей. Через них можно упростить работу с ресурсами в облаке, достаточно просто указать название модуля и передать нужные переменные, все остальное Terraform сделает сам. Для совместной работы группы DevOps-инженеров есть возможность хранить стейтменты (состояние работы Terraform) в удаленном хранилище от hashicorp или любом S3 совместимом.

В последних версиях этот инструмент пошел дальше и, благодаря большой базе разных провайдеров, позволяет работать с более высокими абстракциями, такими как Docker, ресурсы Kubernetes или настраивать Consul и управлять Mysql. В итоге на выходе у вас есть возможность описать всю вашу инфраструктуру до мельчайших деталей.

Aws Cli & OpenStack cli & etc

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

YAML edit

DevOps-инженеров иногда называют Yaml-разработчиками, а умение выйти из Vim — это полезный скилл. Но когда приходится часто работать с кодом, то без хорошего редактора не обойтись. За счет использования таких редакторов, как VSCode или IntelliJ IDEA, можно в значительной степени упростить свою жизнь, подключить различные синтаксические проверки и автокомплитеры, путем установки нужных плагинов.

CI/CD

Jenkins/TeamCity/TravisCI/Bamboo/CircleCI/Drone и, конечно же, GitlabCI — все эти CI/CD-инструменты подходят для выполнения своих задач: сборка и деплой софта. У всех есть свои плюсы и минусы, но так или иначе, каждый выбирает для себя идеальный инструмент, с которым он будет строить свой идеальный Pipeline. Существуют и более продвинутые системы, такие как Tekton, где можно манифестом описать весь CI/CD процесс через crd в Kubernetes. Однако хочется больше внимания уделить именно GitlabCI, как одному из хедлайнеров среди CI/CD-систем.

Нам очень нравится подход, когда весь процесс CI/CD лежит в Git-репозитории непосредственно рядом с кодом. Это позволяет не терять время на то, чтобы вникнуть в сам процесс сборки и деплоя, все находится под рукой.

Ясный и понятный Yaml, в котором описывается весь pipeline, прост в понимании того что происходит. Благодаря Yaml манифестам для Kubernetes, разработчики стали сами писать pipeline и helm чарты, прося проверить мердж реквесты на наличие ошибок. Это говорит о том, что с подобными системами легко и приятно работать. А когда работа в кайф — это круто!

Docker (kaniko/werf/etc) — gradle/npm

Сборки, сборки и еще раз сборки. Хороший DevOps-инженер должен уметь не просто настраивать сборки ПО, но и оптимизировать их, чтобы они не выполнялись по 30-60 минут, это очень сильно замедляет разработку! Для начала нужно разобраться как грамотно написать Dockerfile. По этой теме есть множество материалов, хочу лишь добавить, что необходимо уметь делать двухэтапную сборку, где на выходе будет Docker-образ минимального размера.

На этом можно было бы остановиться, будь у нас один проект и один сервер на котором выполняется сборка. Но у нас десятки разных проектов, сотни репозиториев и тысячи сборок в день. Чтобы все это быстро собиралось, необходимо множество сборочных машин, в том числе и динамических, которые стартуют по мере общей загруженности Pipeline в CI/CD-системе. Чтобы сборки не висели по полчаса на выкачивании зависимостей для Gradle или npm, их можно закэшировать, так как изменения на этом этапе происходят редко, а вот код меняется часто. Для решения этой задачи подходят более продвинутые решения, например Kaniko или Werf, где каждый слой можно закешировать в Docker stage registry и просто вытаскивать готовые слои. Для этой задачи могут подойти любые инструменты способные работать с кешами, благо сейчас их достаточное количество, выбор остается за вами.

Kubectl

В Кометрике активно используется оркестрация докер контейнеров на базе Kubernetes и данная утилита не требует представления.

При работе с кластерами Kubernetes невозможно обойтись без консольной утилиты Kubectl. У нее есть отличный автокомплит, что позволяет ускорить и упростить ввод команд. Конечно, во время GUI интерфейсов возможно заменить её на какой-то продвинутый дэшборд, например на тот, который есть у Rancher, но все это требует больше времени, нежели ввод пары простых команд в консоли. А уж если требуется что-то автоматизировать или провести массовые изменения, без этой утилиты просто не обойтись.

В нашей команде, для разработчиков которые только недавно познакомились с Kubernetes, мы предоставляем веб-интерфейс на базе Rancher, но как показывает практика, это опять-таки, ненадолго. И, в конечном итоге, все приходят к работе с Kubectl.

Ansible & Helm

Собрав ПО его необходимо доставить на сервер, где оно будет запущено в своем окружении. Тут существует множество разных инструментов, которые позволяют выполнить данную операцию. Начиная с Shell-скриптов, заканчивая различными инструментами будь, то Terraform или Kustomize, для деплоя в k8s. Для себя мы выбрали комбинацию Ansible & Helm.

Ansible выполняет деплой на сервер docker-compose, из которого мы уже запускаем все наши контейнеры. Опытные инженеры могут сказать, что у Ansible есть встроенные модули для работы с Docker. Да, это так, но мы осознанно не стали использовать подобные решения и этому есть ряд причин. Первая причина — нужно строго соблюдать версию python на серверах, иначе возможны неожиданные казусы. Вторая причина — при необходимости, по файлу docker-compose.yaml достаточно просто разобраться, что и как было запущено.

В выборе инструмента для деплоя в кластер Kubernetes, побеждает Helm. В нем мы можем полностью шаблонизировать весь деплой под любой стенд и это будет понятно любому из системных инженеров. Helm, как единый инструмент управления, покрывает все необходимые задачи: это и управление инфраструктурой, и работа с релизом, и создание динамического окружения для ревью. Вообще вариантов деплоя в k8s есть множество, от простых в виде YAML файлов, до более сложных в виде Jsonnet. Какой инструмент и под какие цели выбирать вам, все зависит от вашей фантазии и поставленных задач.

Sentry vs. ELK

Логи или события? Вот в чем вопрос! Раньше приходилось очень долго перелопачивать текстовые логи, которые хранились на сервере в gzip-формате, что вызывало постоянную боль, когда нужно было писать grep grep и еще раз grep, все это требовало уйму времени и ресурсов. Потом на смену пришел стек ELK/EFK/graylog и другие вариации. С логами стало значительно проще работать, теперь через удобный графический интерфейс нужно просто сделать запрос и система сама вытащит логи из огромного массива данных. Но прогресс не стоит на месте и появляются еще более продвинутые инструменты, например Sentry.

Sentry — инструмент мониторинга ошибок в ваших приложениях, который позволяет быстро находить причины возникших проблем и устранять баги раньше, чем о них вам сообщат тестировщики, коллеги из саппорта, пользователи, ПМ или директор. Sentry бесплатен, легко интегрируется в проект, ловит ошибки и в браузере пользователя и на вашем сервере. Sentry доступен для Python, JavaScript, PHP, Java, Ruby и других языков.

Prometheus & Grafana

Мониторинг наше все! В работе DevOps-инженера возникает такой момент, когда необходимо провести диагностику работы системы. Тут нам на помощь приходит система сбора метрик Prometheus. Есть и другие системы мониторинга, но в современных реалиях, когда контейнеры эфемерны (например, как поды в Kubernetes, которые могут запускаться на разных машинах), вся инфраструктура постоянно меняется, то уследить за всем становится очень сложно, а иногда и невозможно, плюс возможны человеческие факторы ошибки в конфигурировании. Автоматический дискаверинг виртуальных машин, Docker-контейнеров и т.д., в значительной степени упрощает жизнь системного инженера.

PromQL — позволяет очень четко найти и, благодаря Grafana, построить красивые и информативные графики. Grafonnet — это Jsonnet библиотека, для написания Grafana dashboards as code. При помощи которой мы собираем уникальные дашборды под каждый проект.

Разное

Кроме рассмотренных подробно инструментов у нас используется ряд сервисов, о которых стоит упомянуть:

• Consul/etcd/vault — сервисы для хранения конфигураций и секретов.
• Nexus/Artifactory — сервисы, позволяющие публиковать готовые сборки и модули для сборок.
• SonarQube/Checkmarx/JFrog Xray — сканеры ИБ и статического анализа кода.
• Docker registry — репозиторий хранения docker контейнеров.
• Deploy tools — тулзы для деплоя в различные среды.
• Kubernetes operator — операторы для Kubernetes, упрощающие запуск и обслуживание сервисов, таких как базы данных и все что только возможно.
• Также БД (sql/nosql/in memory), системы хранения данных (minio/ceph/nfs и др), брокеры сообщений (rabbitmq/activemq и др) и многое многое другое.

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