Ускоряем и упрощаем работу в DevOps

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

ZSH

Начнем с наиболее часто используемого инструмента — интерпретатора командной строки. Многие используют zsh из-за плагинов, тем и возможностей автозаполнения. Автозаполнение из истории значительно сокращает время ввода команд, а плагины расширяют возможности автозаполнения, выделяют синтаксис и добавляют полезные псевдонимы.

Два наибо­лее полез­ных пла­гина:

• git — отоб­ража­ет вет­ки/ком­миты/репози­тории. Наг­лядно вид­но, в каком репози­тории находишь­ся, ини­циали­зиро­ван ли он, какая вет­ка, ком­мит, син­хро­низи­рова­но ли с уда­лен­ным репози­тори­ем и про­чее;
• zsh-syntax-highlighting — под­свет­ка син­такси­са в кон­соли. Удоб­но при написа­нии и отладке скрип­тов.

Под­свет­ка веток в Git

Я бы рекомендовал установить плагины для повседневных инструментов: AWS, Docker, brew, knife, node, encode64, kubectl, osx, Python, pip. Практически каждый добавляет табу-подсказки, что уже очень полезно, некоторые по этому табу обращаются в API службы и предлагают расширенное автозаполнение, а не только возможные команды.

С помощью плагинов AWS и kubectl можно сделать еще одну важную вещь: они всегда указывают контекст / профиль, в котором вы работаете, и значительно снижают вероятность ошибки при вводе какой-либо опасной команды в неправильном терминале. Кроме того, например, расширение Amazon может считывать цвета, назначенные профилям, и, если вы работаете в производстве, вы можете покрасить профиль в ярко-красный цвет, чтобы точно понимать, где выполняется команда.

Под­свет­ка про­филя AWS

Под­свет­ка про­филя kubectl

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

Плагины, как и темы, довольно легко установить. Если вас это беспокоит — для этого есть менеджеры плагинов / пакетов для zsh, такие как antigen или zinit. Но в целом установка так же проста, как клонирование git и запуск скрипта, который сам все настроит. Лучшее место для поиска плагинов — использовать коллекции на GitHub, такие как awesome-zsh-plugins.

Screen и tmux

В качестве эмулятора (мультиплексора) терминальных сессий VTM100 используется Screen. Но обычно он используется как способ безопасного выполнения команд через SSH в случае прерывания соединения.

К примеру, если вы запускаете длительную команду как apt-get upgrade,и в этот момент соединение с сервером прерывается. В результате дочерний процесс сеанса SSH apt-get умирает, а процесс обновления пакета завершается. Чтобы этого не произошло, просто запустите экран и выполните все необходимые команды. Теперь, если соединение потеряно, процесс родительского экрана останется активным и не только позволит команде завершиться в обычном режиме, но также позволит ему повторно подключиться к существующему сеансу независимо от устройства.

Screen запус­кает мно­жес­тво тер­миналов в рам­ках одной SSH-сес­сии

Screen имеет более современную альтернативу – tmux. Он был разработан людьми из OpenBSD и в целом имеет лучшую производительность и различные современные дополнения, такие как поддержка плагинов. Сразу рекомендую установить плагин tmux-resurrect, который позволяет сохранять текущий набор открытых терминалов в tmux в файл и восстанавливать его, когда вам нужно выполнить аналогичную задачу.

JQ

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

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

Пос­мотреть выс­тавлен­ные перемен­ные окру­жения в кон­тей­нерах:

$ kubectl get pods --all-namespaces -o json | jq '.items[].spec.containers[].env[]?'

По­иск пов­режден­ных деп­лой­мен­тов:

$ kubectl get --raw=/apis/apps/v1/deployments | jq '.items[] | {name: .metadata.name, replicas: .status.replicas, available: (.status.availableReplicas // 0), unavailable: (.status.unavailableReplicas // 0)} | select (.unavailable > 0)'

Быс­тро пос­мотреть, какие обра­зы дос­тупны на нодах (час­то помога­ет при проб­леме с кеширо­вани­ем и ска­чива­нием обра­зов новых вер­сий):

$ kubectl get nodes -o json | jq '.items[] | .status .images[]'`

Схо­же с пре­дыду­щей, вари­ант быс­тро­го прос­мотра дос­тупных ресур­сов на нодах, удоб­но поль­зовать­ся в связ­ке со скрип­тами:

$ kubectl get nodes -o json | jq '.items[] | .status .allocatable'

K9S и K8S Lens

Консольный менеджер Kubernetes K9s. Простой в использовании и удобный в работе, поддерживает все методы аутентификации Kubera, включая SSO и aws-iam-auth. Позволяет быстро и четко перемещаться по кластеру, редактировать манифесты и ресурсы, входить в контейнеры и наблюдать за загрузкой ресурсов.

К минусам можно отнести отсутствие «вкладок» и возможность возврата к открытым ресурсам. Но в любом случае работать с кластером по K9s намного удобнее, чем по kubectl, даже если для последнего написать много псевдонимов.

Отоб­ражение подов в K9s

Про­вер­ка манифес­тов ресур­са в K9s

K8s lens — это автономное настольное приложение (фактически написанное в электронном виде). Показывает кластер еще красивее. По возможностям он примерно равен K9s. С другой стороны, поддерживаются не все методы авторизации. Имеется довольно большая библиотека плагинов.

Об­щий вид K8s lens

Vagrant

В настоящее время Vagrant является устаревшим, но в целом полезным инструментом для управления виртуальными машинами. Основной плюс в том, что Vagrant имеет удобную и простую (с точки зрения конфигурации) оркестровку виртуальных машин; это позволяет создавать универсальные тестовые среды с различными целями. 

Например, многие используют Ansible для настройки образов виртуальных машин во время сборки. Но каждый раз при тестовых запусках подключение к серверам, будь то облачные или локальные Hyper-V / VMware / QEMU, может быть проблематичным, сложным и трудоемким. Лучше написать простую конфигурацию для Vagrant, которая будет запускать Ansible playbook на локальном VirtualBox в Vagrant-Up. Это намного быстрее и проще, чем использование удаленного сервера.

При­мер тес­тового кон­фига с Ansible-provisioner:

Vagrant.configure("2") do |config|

Packer

Для окончательной сборки образов виртуальных машин используется Packer. Это часть стека Hashicorp (того самого, который написал Vagrant), поэтому установка для запуска Ansible аналогична и очень легко переносится с Vagrant на Packer.

Так же как и в Vagrant, исполь­зуя Ansible-provisioner, запус­каем такую же кон­фигура­цию в про­цес­се сбор­ки AMI:

build {

Supervisord

В производственной среде каждый контейнер должен отвечать за запуск только одного процесса (это хорошее практическое правило). Для тестирования, помимо основного процесса (например, серверной части приложения), часто необходимо запустить обратный прокси, базу данных или какой-либо дополнительный процесс для мониторинга и тестирования.

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

Сам кон­фиг супер­визора для тес­тирова­ния работы прок­си к бэкен­ду выг­лядит при­мер­но так:

[supervisord]

И сам докер­файл с точ­кой вхо­да под супер­визор:

FROM base-image:latest

COPY ./nginx /etc/nginx

ENTRYPOINT ["/usr/bin/supervisord"]

Логины и пароли

Скорее всего, вы уже пользуетесь менеджерами паролей, такими как LastPass, Keepass, 1Password и Dashlane. Не исключено что у вас есть возможность использовать их на корпоративном уровне. Но вы могли не знать, что в большинстве этих менеджеров есть очень удобные консольные версии.

Их использование позволяет вам создавать врапперы для авторизации в облачной системе, быстро вставлять токены в Curl и даже встраивать их как источники секретов в каналы вместо использования такой технологии, как Hashicorp Vault.

Ко­рот­кий али­ас, поз­воля­ющий получить по име­ни хра­нили­ща и клю­чу нуж­ное зна­чение. К при­меру, op-value Engineering console-pass:

alias op-value=function(){op list items --vault $1 | jq --arg v $2 -r '.[] | select(.overview.title | contains($v)) | .uuid'}

Быс­трый прос­мотр и поиск нуж­ного айте­ма, сра­зу мож­но копиро­вать UUID, что­бы получить нуж­ное зна­чение:

alias op-list-items=function(){op list items --vault $1 | jq -r '.[] | .uuid, .overview.title' | less

В качестве альтернативы вы можете использовать простейший Console Pass диспетчера паролей, который работает полностью локально (с возможностью сохранения в Git). Его хранилище удобно передавать при необходимости, так как это набор файлов, зашифрованных с помощью GPG.

В качестве бонуса–fzf, визуальный динамический поиск по именах файлов и путей в каталогах. Отправьте на консоль полный путь к файлу, чтобы было удобно использовать псевдоним vzf = ‘vim $ (fzf)’ вместе с псевдонимом. Это инструмент для быстрого редактирования файлов в текущей папке без загрузки тяжелых записных книжек, которые были необходимы для работы.

Выводы

Если вам нужно решить какую-то задачу, то вы можете найти для себя подходящее решение и внедрить его в свою жизнь. Это позволяет сделать вывод, что плагины zsh становятся привычными помощниками, Vagrant и Supervisord помогают сэкономить время на проведении тестов, а менеджеры паролей, несмотря на их нестандартный характер, отлично интегрируются с облачной инфраструктурой.  Самое главное в любой рутинной задаче — это то, что в следующий раз ее можно будет выполнить быстрее.