Девопс

Возможно, вы уже умеете писать отличный код. И может, у вас уже есть реальное представление, как работает платформа, виртуализация и сеть с безопасностью. Но что, если вы не хотите углубляться ни в одну из этих областей? А может, вы уже думали о переходе в DevOps, где требуется много знаний и со стороны dev, и со стороны ops, но не нужно становиться хардкорным разработчиком? Тогда у нас хорошая новость начинать в DevOps можно в любом возрасте и с любой технической специализацией.

Тому пример Александр Шуляк, который нашел себя именно в Девопсе. Накануне конференции DevOps 2021 мы встретились с Сашей и поговорили о том, как и с чего начался его DevOps, а также к чему он пришел в этой карьере.

Саша, очень приятно с тобой познакомиться. На странице про твой доклад написано, что ты делал и делаешь DevOps в больших и маленьких компаниях. Расскажи, как ты начинал.

И мне тоже очень приятно. В сфере IT я уже больше семи лет. Начинал системным администратором, изучая сети и учась на курсах Cisco. Но мне было интересно и кодить. Я не уходил в глубокую специализацию, просто применял всё, что узнавал в одной области в другой. Например, я хорошо знал, поработав сисадмином, как работают сети и системы. И мог использовать это в своей повседневной работе.

Правда, со временем я всё больше понимал, что ни одна из dev- и ops-областей меня полностью не устраивает. Мне хотелось совместить все эти интересные штуки из разработки и operations вместе. Но тогда я еще не знал, что это возможно в DevOps.

Как ты узнал про DevOps?

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

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

Какие твои навыки тебе тогда потребовались на практике?

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

Тогда от меня требовалось писать код, чтобы автоматизировать всё и вся. При этом нужно было ковыряться в системах, но уже абстрагируясь от железа. Использовать облачные ресурсы, чтобы быстро получать требуемые мощности.

В DevOps пригодятся любые навыки программирования, и начальный язык не так важен, потому что пересесть на профильные python/golang не будет сложным делом.

Что именно нужно уметь кодить DevOps-инженеру?

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

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

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

Shell-скрипты это ведь часть работы в терминале. Что-то еще там нужно уметь?

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

Какие инструменты нужно изучать для мониторинга и сбора логов?

Основные инструменты для сбора метрик сейчас это Prometheus и Grafana. Prometheus это метрик-коллектор (формально time-series database). Как альтернатива мне ещё очень нравится TICK стек на базе InfluxDB. Grafana, в свою очередь, используется для отрисовки красивой инфографики и отправки оповещений.

Для сбора логов в одном месте можно посмотреть Elastic Stack. Он довольно сложный, но дает отличное представление о работе с логами. У него есть бесплатная версия, и этого достаточно, чтобы поиграться с системой и понять, как она работает, из каких компонентов состоит. Альтернативы Elastic Stack Splunk, Datadog. Но это больше enterprise-инструменты, изучать их достаточно сложно.

Что насчет операционных систем? Чем тут заняться, чтобы приблизиться к девопсу?

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

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

У Linux Professional Institute (LPI) есть статьи по работе linux и базовым манипуляциям с системой. Это открытые курсы/уроки, и они хорошо помогут разобраться с работой Linux. А у Роберта Лава (Robert Love) есть отличная, хоть и немного скучная книга Ядро Linux: описание процесса разработки. Помогает быстро уснуть :)

Ещё в изучении Linux вам может сильно помочь Youtube-канал Кирилла Семаева.

Поговорим про сетевую сторону operations. Что нужно уметь делать здесь?

Первое и самое важное знать как работает сеть. Теоретическая и практическая часть прекрасно описаны в цикле статей от linkmeup сети для самых маленьких. Статьи на примере Cisco, с прекрасными иллюстрациями и отличными объяснениями. Очень легко понять, как сеть работает на всех уровнях.

Ещё в любом случае надо знать веб-сервера, но тут достаточно изучить nginx на базовом уровне. Основные принципы не сильно отличаются от сервера к серверу, а nginx один из самых популярных из них.

Расскажи про принципы DevOps. Это что-то as Code. Как они работают?

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

Наверное, самый популярный инструмент управления инфраструктурой (Infrastructure as Code) это Terraform. Его довольно просто изучать, там великолепная документация. И буквально в этом году вышло новое издание книги Евгения Брикмана Terraform. Инфраструктура на уровне кода, которая тоже отлично объясняет, как работать с этим инструментом.

Есть ещё принцип Configuration as Code, который описывает состояние операционной системы. Тут я советую для изучения Ansible. Можно Chef, но выбрать можно любой, так как поняв основной принцип работы одного, переходить на другие инструменты будет несложно.

А Pipeline as Code вообще очень интересная вещь. Так как синтаксис и предоставляемые возможности инструментов очень схожи, то можно спокойно выучить один и пользоваться всеми. С другой стороны, практически всегда построение пайплайнов приводит к shell-скриптам, потому что основного инструмента без его кастомизации в любом случае будет недостаточно.

Оркестрация это тоже необходимый навык?

Да, примерно по тем же причинам, почему мы используем всё as Code. Когда у вас контейнеров больше одного, ими сложно управлять. Для этого и существуют оркестраторы вроде Mesos, Nomad, Openshift, Kubernetes и так далее. Самый популярный, конечно, Kubernetes. Он достаточно сложный для изучения с точки зрения архитектуры и управления, но базовые понятия выучить не проблема. На первых порах этого должно быть достаточно, а остальное придёт с опытом и интересом.

Какие есть особенности у специализации DevOps-инженеров?

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

На практике список обязанностей сильно зависит от размера компании. Где-то могут быть большие команды и несколько DevOps-инженеров, которые отвечают за build продукта, релиз, платформу или безопасность и governance облака.

После интенсива в минском аутсорсе я пришел работать в Accenture в Латвии. Это было что-то абсолютно противоположное огромная корпорация, четко поставленные процессы, большие команды, много командировок и общения с заказчиками. Для меня это был очень полезный и новый опыт. Но Рига город небольшой и во многом похож на Минск. IT-рынок также не широк, а мне уже хотелось эмигрировать дальше и не просто так, а ради чего-то нового.

Так я оказался в Лондоне. Сейчас, после полутора лет в Gearset, я Senior SRE в финтех-стартапе Divido. И мой опыт показывает, что в Англии больше верят в узкую специализацию, чем у нас. То есть вам надо знать некоторые предметные области в вашем техническом стеке намного лучше, чем другие. Допустим, если вы Cloud Ops инженер, то у вас будет сильный упор на бизнес-инструменты именно в облаках.

У нас же чаще подразумевается, что человек умеет делать всё.

Твой доклад как раз по этой теме?

Нет, на этот раз я хочу поговорить о тестировании. Многие сомневаются, а нужно ли вообще тестировать. И если надо, то когда начинать, если, например, и так много задач. Особенно если у вас не хватает времени, есть какое-то легаси, да еще и технический долг, который нужно разгребать. Или внезапно продукт вашей компании должен отвечать каким-то требованиям стандартизации и сертификации. Собственно моя история будет схожей с обходными путями тестирования инфраструктуры, когда в лоб не очень получается. Я уверен, что многие сталкивались с похожими проблемами, поэтому мне очень хочется поделиться своим опытом. Тебе нравится выступать?

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

Что ты предпочитаешь, офлайн или онлайн?

Вживую намного больше возможностей пообщаться как со зрителями, так и с другими докладчиками. Я очень хочу пообщаться офлайн с единомышленниками. Хотя авиасообщение между Великобританией и Россией до сих пор закрыто, я ищу билеты с пересадкой. Потому что меня ждет и взаимодействие с аудиторией, и новые контакты, и дискуссии. А такое живое общение намного круче чатов!

Какие темы из программы для тебя наиболее актуальны и какие доклады хочешь послушать сам?

Разумеется доклад Дмитрия Столярова, я его большой фанат! :) У него всегда можно узнать что-то новое про кубер, с которым я последние два года очень плотно работаю. А также о теоретической части SRE/DevOps, поскольку мне очень интересно, как выстроены процессы в разных компаниях и как они скрещивают методологии с реальной жизнью.

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

Ну и конечно, нас ждет извечно актуальная и холиварная для меня тема про SRE человек-оркестр, потому что никто не знает как обозвать человека со специфичным набором навыков и вообще надо ли :)

Саша, спасибо тебе огромное за подробный разговор. Желаем тебе найти билеты в Россию, чтобы встретиться на конференции!

Спасибо и до встречи!

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

Конечно, в онлайн вы не сможете пообщаться со всеми вживую. Но онлайн-формат в этом году больше, чем трансляция. Билеты все еще забронировать, а расписание здесь. Присоединяйтесь к сообществу фанатов DevOps-подхода. До встречи на конференции!

Привет, Хабр!

Предлагаем подборку свежих статей, подкастов, докладов и грядущих событий для DevOps-специалистов от команды Рексофт. Собрали всё самое интересное за последние несколько недель.

Статьи

1. Обзор инструментов для chaos engineering в Kubernetes

Материал в двух частях от специалистов из компании Флант. Они описывают и сравнивают Open Source-утилиты для запуска управляемого хаоса в кластере Kubernetes. В первой части специалисты рассказали о появлении самой дисциплины chaos engineering, а также рассмотрели kube-monkey, chaoskube и Chaos Mesh.

Читать первую часть

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

Читать вторую часть

2. Не паникуйте: Kubernetes и Docker

Начиная с версии v1.20, Kubernetes отказывается от Docker как от исполняемой среды контейнеров. Но не паникуйте. Не все так страшно, как представляется на первый взгляд. Перевод статьи, которая призвана ответить на шумиху вокруг грядущего релиза K8s, в котором поддержка Docker будет объявлена устаревшей.

Читать перевод

3. Red Hat борются с системной несправедливостью и расизмом в коде и документации

Red Hat продолжают бороться с использованием в коде и документации неполиткорректных или оскорбляющих слов. Вендор выпустил специальный фреймоворк, чтобы помочь другим компаниям выявлять у себя такие слова. В частности, рекомендовано заменить термины master/slave и blacklist/whitelist.

Конечно, в IT есть проблемы и посерьезнее, да и вообще, для русскоязычного сегмента, новость может выглядеть комично. Однако, похоже, что инициатива будет только расширяться и влиять на всю отрасль. К движению уже присоединились IBM, Linux Foundation, Cisco и ряд других крупных компаний.

Читать новость (на английском)

4. DevOps и SRE технологии и инструменты 2021 года

Небольшая, но очень ёмкая подборка технологий и инструментов, на которые DevOps и SRE-специалистам необходимо обратить пристальное внимание в 2021 году.

Читать подборку (на английском)

Подкасты

1. SRE vs DevOps

Кто такой Site Reliability Engineer (SRE), зачем он нужен и чем отличается от DevOps или простого системного администратора? Как SRE взаимодействуют внутри команды и вне её, как работает эта культура в разных странах? На эти и многие другие вопросы отвечают эксперты SRE Google и и другие спикеры в очередном выпуске подкаста Linkmeup.

Слушать подкаст

2. Зачем IT в благотворительности

Казалось бы, в благотворительности нет места разработке, да и бюджеты на IT там не предусмотрены. Однако именно технологический подход помогает фонду Нужна помощь собирать по миллиону рублей в день на решение социальных проблем. Технический директор фонда и тимлид проекта Если быть точным рассказали, как в фонде создают IT-инфраструктуру для благотворительности по всей России, и что происходит с разработкой, если о твоем сайте упомянул Иван Ургант.

Слушать подкаст

События

Вебинар Docker Swarm vs K8s. Уйти нельзя остаться. Когда, кому и зачем переходить на Kubernetes со Swarm

10 декабря Mail.ru Cloud Solutions проведут вебинар, на котором сравнят функциональность и ограничения Docker Swarm и Kubernetes. Спикеры разберутся почему лучше перейти на K8s или наоборот, остаться на Swarm. Расскажут, как упростить свой путь в овладении технологией Kubernetes с помощью облачных сервисов с гарантированной доступностью, которые автоматизируют операции Life Cycle. В конце вебинара на вопросы ответит ведущий DevOps Mail.ru Cloud Solutions.

Зарегистрироваться на вебинар

Доклады

DevOps без полномочий

Видео и расшифровка доклада с DevOps Moscow 2020. Спикеры рассказали, как простой исполнитель без больших полномочий может положительно влиять на энтерпрайзные процессы между Dev и Ops. Что кому говорить, как мотивировать и как работать с возражениями. За час выступления спикеры рассмотрели все возможные способы влияния без реальных полномочий, пожалуй, кроме парапсихологических практик и гипноза.

Читать материал и смотреть видео

Вступление

Привет, Хабр! Работаю java программистом в одной финансовой организации. Решил оставить свой след на хабре и написать первую свою статью. В силу проблем с наличием девопсеров передо мной была поставлена задача обновить кластер кафки с 2.0 до 2.6 без даунтайма и потери сообщений (сами понимаете, никто не любит, когда денежки зависают в воздухе или где-то теряются). Хочу поделиться этим опытом с Вами и получить конструктивный фидбек. Итак, хватит воды, переходим сразу к делу.

Схема миграции

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

Ниже представлена схема миграции. Имеем 3 брокеров на старых ВМ, 3 брокеров на новых ВМ, также для каждого брокера имеется свой zookeeper.

План миграции

Для того чтобы нам мигрировать так, чтобы этого никто не заметил, придется "немного" попотеть. Ниже приведен общий план.

1. Добавить в настройки приложения адреса новых брокеров

2. Пробить доступы между всеми и вся

3. Подготовить инфраструктуру на новых виртуалках

4. Поднять новый кластер зукиперов и объединить его со старым

5. Поднять новых брокеров кафки

6. Мигрировать все партиции со старых брокеров на новые

7. Отключить старые брокеры кафки и старых зукиперов

8. Убрать из новых конфигов старых брокеров и зукиперов

А теперь поехали по порядку разбирать подробнее каждый пункт

Добавление брокеров в приложение

Самый простой пункт. В коде клиента, там где были прописаны адреса старых брокеров, туда же дописываем новых. В свойство "bootstrap.servers"

Пробитие доступов

Одно из самых нелюбимых занятий - это пробитие доступов. Заявки согласуются долго, а выполняются еще дольше. Доступов нам придется заказать немало, давайте разберемся какие именно.

1. Как вы уже догадались по строке настройки брокеров, нам нужен порт 9092 в направлении Приложение -> новые брокеры кафки (в сумме 3 доступа)

2. Этот же порт для Новые брокеры <----> Старые брокеры (+18 доступов)

3. Все тот же порт 9092 между каждым новым брокером (+6 доступов)

4. Аналогичные доступы из пунктов 2 и 3 для портов зукиперов: 2181, 2888, 3888 ( (18+6)*3 = 72)

Итого: 99 доступов. Получите и распишитесь! А потом еще проверьте все.

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

Инфраструктура нового кластера

Для начала нам нужно создать пользователя kafka на новых виртуалках

Далее очень важный пункт - необходимо прописать разрешенное количество открытых файлов пользователю kafka. А именно, в файле /etc/security/limits.conf дописываем строки

kafka hard nofile 262144kafka soft nofile 262144

Если мы этого не сделаем, то это грозит нам внезапным падением брокера, так как кафка по своей природе любит открывать много файлов, поэтому надо подготовиться к ее аппетитам.

Честно говоря, число 262144, взято просто потому, что на старом кластере было установлено такое значение (исторически сложилось). Хотя у нас кафка открывает не больше 10 тысяч файлов, поэтому вы можете провести анализ и выставить более подходящее.

Далее нам надо прописать переменную среды к java

в файл /home/kafka/.bash_profile дописываем

export JAVA_HOME=/opt/javaexport PATH=JAVA_HOME/bin:PATH

Соответственно у вас должна лежать jre в папке /opt/java

Далее раскидываем папки по нужным директориям и устанавливаем права

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

tar -xf ../jdk1.8.0_181.tar.gz -C /opt/mv /home/kafka/kafka /optmv /home/kafka/zookeeper /optmv /home/kafka/kafka-start.sh /optmv /home/kafka/scripts /optln -sfn /opt/kafka/kafka_2.13-2.6.0 /opt/kafka/currentln -sfn /opt/zookeeper/zookeeper-3.6.2 /opt/zookeeper/currentln -sfn /opt/jdk1.8.0_181/ /opt/javachown -R kafka:kafka /optchmod -R 700 /opt#env_var start ------------------------------->kafkaProfile=/home/kafka/.bash_profilehomeVar="export JAVA_HOME=/opt/java"javaHome=$(cat $kafkaProfile | grep "$homeVar")if [ "$javaHome" != "$homeVar" ]; then    echo -e "\n$homeVar\n" >> $kafkaProfilefipathVar="export PATH=\$JAVA_HOME/bin:\$PATH"path=$(cat $kafkaProfile | grep "$pathVar")if [ "$path" != "$pathVar" ]; then    echo -e "\n$pathVar\n" >> $kafkaProfilefi#env_var end --------------------------------->#ulimit start >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>limitsFile=/etc/security/limits.confsoft="kafka soft nofile 262144"limitSoft=$(cat $limitsFile | grep "$soft")if [ "$limitSoft" != "$soft" ]; then    echo -e "\n$soft\n" >> $limitsFilefihard="kafka hard nofile 262144"limitHard=$(cat $limitsFile | grep "$hard")if [ "$limitHard" != "$hard" ]; then    echo -e "\n$hard\n" >> $limitsFilefi#ulimit end >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Далее из под пользователя kafka проверяем что у нас все установлено правильно

ulimit -n  = 262144echo $JAVA_HOME  = /opt/javaecho $PATH  должен содержать /opt/java/bin

Новый кластер зукиперов

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

ниже кусок файла конфигурации зукипера /opt/zookeeper/current/conf/zoo.cfg

dataDir=/opt/zookeeper/zookeeper-dataserver.1=server1:2888:3888server.2=server2:2888:3888server.3=server3:2888:3888server.4=server4:2888:3888server.5=server5:2888:3888server.6=server6:2888:3888

Стартуем все зукиперы /opt/zookeeper/current/bin/zkServer.sh start

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

echo -e "\nserver.4=server4:2888:3888" >> /opt/zookeeper/zookeeper-3.4.13/conf/zoo.cfgecho -e "\nserver.5=server5:2888:3888" >> /opt/zookeeper/zookeeper-3.4.13/conf/zoo.cfgecho -e "\nserver.6=server6:2888:3888" >> /opt/zookeeper/zookeeper-3.4.13/conf/zoo.cfg

Теперь нужно определить кто из зукиперов был лидером, и перезапустить все зукиперы. Лидера в последнюю очередь.

/opt/zookeeper/zookeeper-3.4.13/bin/zkServer.sh restart

Наконец проверяем, что все зукиперы увидели друг друга и выбрали лидера. Везде выполняем

.../zkServer.sh status

Настройка ансамбля зукиперов завершена.

Поднятие новых брокеров

Теперь можно заняться запуском новых брокеров, но перед этим нужно убедиться что в server.properties у нас проставлен broker.id и zookeeper.connect

Пример для 4 брокера

broker.id=4zookeeper.connect=server4:2181,server5:2181,server6:2181/cluster_name

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

Также необходимо там же в server.properties прописать текущую версию протокола взаимодействия между брокерами (2.0.0). Иначе мы не сможем переместить партиции.

inter.broker.protocol.version=2.0.0

Запускаем новых брокеров

nohup /opt/kafka/current/bin/kafka-server-start.sh /opt/kafka/config/server.properties > log.log 2>&1 &

Теперь необходимо проверить что новые брокеры присоединились к кластеру. Для этого заходим в cli любого из зукиперов.

/opt/zookeeper/current/bin/zkCli.sh

и выполняем там команду

ls /cluster_name/brokers/ids

Должен быть выведен такой ответ

[1,2,3,4,5,6]

Это значит что в кластере у нас все 6 штук брокеров, чего мы и добивались.

Перемещение партиций

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

Заглянув в документацию я увидел , что перемещение партиций "автоматическое", но надо проделать немалое количество манипуляций, чтобы запустить все это дело.

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

{"topics": [{"topic": "foo1"},              {"topic": "foo2"}],  "version":1 }

Так как топиков у нас было много, я сгенерил несколько таких файлов

Далее все эти json файлы надо скормить утилите kafka-reassign-partitions.sh с аргументом --generate и указать id брокеров куда мы хотим переехать --broker-list "4,5,6".

У нас получится несколько файлов такого вида

{"version":1,  "partitions":[{"topic":"foo1","partition":2,"replicas":[1,2,3]},                {"topic":"foo1","partition":0,"replicas":[3,2,1]},                {"topic":"foo2","partition":2,"replicas":[1,2,3]},                {"topic":"foo2","partition":0,"replicas":[3,2,1]},                {"topic":"foo1","partition":1,"replicas":[2,3,1]},                {"topic":"foo2","partition":1,"replicas":[2,3,1]}]  }  Proposed partition reassignment configuration  {"version":1,  "partitions":[{"topic":"foo1","partition":2,"replicas":[5,4,6]},                {"topic":"foo1","partition":0,"replicas":[4,5,6]},                {"topic":"foo2","partition":2,"replicas":[6,4,5]},                {"topic":"foo2","partition":0,"replicas":[4,5,6]},                {"topic":"foo1","partition":1,"replicas":[5,4,6]},                {"topic":"foo2","partition":1,"replicas":[4,5,6]}]  }

Все что идет до Proposed partition reassignment configuration это текущее распределение партиций (может пригодиться для роллбека). Все что после - распределение после переезда. Соответственно нам надо собрать все эти нижние половины со всех файлов, сформировать новые json.

Так как все это делать руками ну ооочень долго. я "быстро" накатал скрипт, который вызывает все эти команды и режет файлы как нам надо. За резку файлов отвечает джарник kafka-reassign-helper.jar код можно глянуть тут.

Ниже скрипт подготовки файлов для переезда партиций

#параметр отвечает за количество топиков в одном файле. у нас было 20if [ "$#" -eq 0 ]then    echo "no arguments"    exit 1fiecho "Start reassignment preparing"/opt/kafka/current/bin/kafka-topics.sh --list --zookeeper localhost:2181/cluster_name >> topics.txtecho created topics.txtjava -jar kafka-reassign-helper.jar generate topics.txt $1fileCount=$(ls -dq generate*.json | wc -l)echo "created $fileCount file for topics to move"echo -e "\nCreating generated files\n"mkdir -p generatedfor ((i = 1; i < $fileCount+1; i++ ))do/opt/kafka/current/bin/kafka-reassign-partitions.sh --zookeeper localhost:2181/cluster_name --broker-list "4,5,6" --topics-to-move-json-file "generate$i.json" --generate >> "generated/generated$i.txt"echo "generated/generated$i.txt" createddoneecho -e "\nCreating execute/rollback files"java -jar kafka-reassign-helper.jar execute $fileCountecho -e "\nexecute/rollback files created"echo -e "\nPreparing finished successfully!"

После выполнения скрипта скармливаем сгенеренные файлы по очереди утилите kafka-reassign-partitions.sh, но на этот раз с параметром --execute

#параметр отвечает за номер файла execute1.json, execute2.json ....if [ "$#" -eq 0 ]then    echo "no arguments"    exit 1fi        /opt/kafka/current/bin/kafka-reassign-partitions.sh --zookeeper localhost:2181/cluster_name --reassignment-json-file "execute/execute$1.json" --execute

Вот теперь кафка начнет перемещать партиции. В логе новых брокеров судорожно забегают строки, как и в логах старых. Пока все это происходит, чтобы не скучать, нам предоставили третий аргумент kafka-reassign-partitions.sh, а именно --verify, который предоставляет узнать текущий статус переезда.

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

progress=-1while [ $progress != 0 ]do    progress=$(/opt/kafka/current/bin/kafka-reassign-partitions.sh --zookeeper localhost:2181/cluster_name --reassignment-json-file execute/execute$1.json --verify | grep "in progress" -c)    complete=$(/opt/kafka/current/bin/kafka-reassign-partitions.sh --zookeeper localhost:2181/cluster_name --reassignment-json-file execute/execute$1.json --verify | grep "is complete" -c)    failed=$(/opt/kafka/current/bin/kafka-reassign-partitions.sh --zookeeper localhost:2181/cluster_name --reassignment-json-file execute/execute$1.json --verify | grep "failed" -c)    echo "In progress:" $progress;    echo "Is complete:" $complete;    echo "Failed:" $failed;    sleep 2sdone

Вызываем и ждем пока In progress станет равным 0. а Is complete примет какое-то конечное значение. И надеемся что Failed так и останется 0.

Когда все закончилось вызываем снова move-partitions.sh и reassign-verify.sh для следующего файла, до тех пор пока не переберем все наши файлы миграции.

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

Отключение старого кластера

Тут все просто. выполняем kafka-server-stop.sh и zkStop.sh для брокеров и зукиперов соответственно.

Чистим конфиги нового кластера

Начинаем с зукиперов. Из файлов zoo.cfg удаляем лишние записи

sed -i '/server.1/d' /opt/zookeeper/current/conf/zoo.cfgsed -i '/server.2/d' /opt/zookeeper/current/conf/zoo.cfgsed -i '/server.3/d' /opt/zookeeper/current/conf/zoo.cfg

Далее, как обычно, у зукиперов определяем кто лидер и перезапускаем по очереди, лидера в последнюю очередь. После перезапуска проверяем статусы: 2 фолловера и 1 лидер.

Удаляем из server.properties брокеров старый протокол общения

sed -i '/inter.broker.protocol.version=2.0.0/d' /opt/kafka/config/server.properties

Теперь вроде как можно перезапустить брокеров, но надо убедиться, что все партиции находятся в состоянии insync, причем не в количестве min.insync.replicas (у нас равно 2), а в количестве default.replication.factor (у нас 3)

Иначе если где-то будет 2 реплики, а не 3, то при перезапуске брокера, на котором лежит одна из этих двух реплик, мы получим ошибку на клиенте, что не хватает insync реплик.

Ниже скриптик для проверки

input="check-topics.txt"rm -f $input/opt/kafka/current/bin/kafka-topics.sh --list --zookeeper localhost:2181/cluster_name >> check-topics.txtcheckPerIter=100i=0list=""notInsync=0while IFS= read -r linedo ((i=i+1)) list+="${line}|" if [ $i -eq $checkPerIter ]  then   list=${list::${#list}-1}   echo "checking $list"   count=$(/opt/kafka/current/bin/kafka-topics.sh --describe --topic $list --zookeeper localhost:2181/cluster_name | egrep "Isr: [4-6/,]{3}$" -c)   if [ "$count" -ne 0 ]    then     /opt/kafka/current/bin/kafka-topics.sh --describe --topic $list --zookeeper localhost:2181/cluster_name | egrep "Isr: [4-6/,]{3}$"   fi   ((notInsync=notInsync+count))   list=""   i=0 fidone < "$input"echo "not insync: $notInsync"

Если на выходе получаем not insync: 0, то можно по очереди перезапустить брокеров.

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

Вот как выглядит инструкция, которую я отправил админам, которые все это проворачивали на бою. На удивление справились с первого раза и без вопросов.

Инструкция по миграции кафка 2.0.0 -> 2.6.01 этап. Подготовка инфраструктуры1.1 Скопировать архивы для миграции на сервера кафкиNEW4.tar.gz -> адрес 4 брокераmigration.tar.gz -> адрес 4 брокераNEW5.tar.gz -> адрес 5 брокераNEW6.tar.gz -> адрес 6 брокера1.2 Разархивировать архивыtar -xf NEW4.tar.gz -C /home/kafkatar -xf NEW5.tar.gz -C /home/kafkatar -xf NEW6.tar.gz -C /home/kafka1.3 От пользователя root выполнить скрипт на каждом новом сервере (установка файлов в нужные директории, прав и лимитов)/home/kafka/scripts/setup.sh1.4 Перейти на пользователя kafka (на каждом новом сервере)1.5 Проверить следующие параметры среды (на каждом новом сервере)ulimit -n  = 262144echo $JAVA_HOME  = /opt/javaecho $PATH  должен содержать /opt/java/binсодержимое папки /opt должно принадлежать kafka kafka2 этап. Запуск зукиперов и брокеров2.1 Перейти под пользователя kafka (на каждом новом сервере)2.2 Выполнить скрипт на каждом новом сервере (запускаются новые зукиперы)/opt/scripts/zkStart.sh2.3 Скопировать архивы на старые сервера кафки OLD1.tar.gz -> адрес 1 брокераOLD2.tar.gz -> адрес 2 брокераOLD3.tar.gz -> адрес 3 брокера2.4 Разархивировать архивыtar -xf OLD1.tar.gz -C /home/kafkatar -xf OLD2.tar.gz -C /home/kafkatar -xf OLD3.tar.gz -C /home/kafka2.5 От пользователя root выполнить скрипт на каждом старом сервере (установка прав на скрипты миграции)/home/kafka/scripts/setup-old.sh2.6 Перейти под пользователя kafka на каждом старом сервере2.7 Выполнить скрипт на каждом старом сервере (добавляем новые зукиперы в конфиг старых зукиперов)/home/kafka/scripts/zk-add-new-servers.sh2.8 Выполнить скрипт на каждом старом сервере (проверка статуса зукиперов)/home/kafka/scripts/zkStatus.shопределить какой из старых серверов является лидером2.9 Перезапустить по очереди зукиперы на старых серверахлидера перезапускать в последнюю очередь/home/kafka/scripts/zkRestart.sh2.10 Проверить что кластер зукиперов подхватил новые серверадля этого на всех серверах выполнить/home/kafka/scripts/zkStatus.sh (на старых)/opt/scripts/zkStatus.sh (на новых)все сервера кроме одного должны быть в состоянии followerодин сервер leader2.11 запуск новых брокеровна новых серверах выполнить скрипт/opt/kafka-start.sh2.12 проверить что новые брокеры в кластеревыполнить на новом сервере/home/kafka/migration/zkCli.shls /cluster_name/brokers/idsдолжно быть выведено [1,2,3,4,5,6]3 этап Перемещение партиций на новых брокеров3.1 Выполнить скрипт (подготовка файлов для перемещения партиций)/home/kafka/migration/prepare-for-assignment.sh  203.2 Выполнить данный пункт по очереди для каждого файла в директории /home/kafka/migration/executeПример:для файла execute1.json/home/kafka/migration/move-partitions.sh 1после начала выполнения скрипта выполнить скрипт Пример:/home/kafka/migration/reassign-verify.sh 1когда количество партиций в состоянии "in progress" достигнет 0 дождаться ОК от программиста и приступить к п.3.2 для следующего файла3.3 После завершения перемещения партиций производится проверка логов на наличие ошибок, а также проверка директории /opt/kafka/kafka-data на всех старых брокерахДолжны остаться только технические логи кафки3.4 По очереди выключить на старых серверах брокеров, выполнив скрипт/opt/kafka/current/bin/kafka-server-stop.sh3.5 По очереди выключить зукиперов на старых серверах, выполнив скрипт/home/kafka/scripts/zkStop.sh3.6 На новых серверах выполнить скрипт (удаляем старых зукиперов из конфига новых зукиперов)/opt/scripts/zk-remove-old-servers.sh3.7 На новых серверах перезапустить зукиперов/opt/scripts/zkRestart.sh3.8 На новых серверах проверить статус зукиперов (один лидер, 2 фоловера)/opt/scripts/zkStatus.sh3.9 На новых серверах выполнить скрипт (удаляем из конфига старый протокол общения между брокерами)/opt/scripts/remove-old-protocol.sh3.10 Проверить что все реплики в статусе insyncдля этого запустить скрипт /home/kafka/migration/check-insync.shnot insync должно быть равно 03.11 По очереди для каждого нового брокера выполнить/opt/kafka/current/bin/kafka-server-stop.shдождаться пока брокер остановиться (ps aux | grep kafka должен показывать только зукипера)выполнить /opt/kafka-start.shПриступить к 3.10 следующего брокераМиграция завершена!

Надеюсь, что кому-то помог в этом вопросе. Жду ваших комментов и замечаний.

Все скрипты и инструкции, в том числе для роллбеков можно найти тут

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

Вот уже несколько лет я набираю на работу девопсов. Путеводная звезда приводила к нам в компанию разных соискателей, в том числе весьма курьезных: от программистов микроконтроллеров до арт-директора, который после 40 вдруг узрел новое призвание. Был даже студент-африканец, который едва говорил по-русски, но уже сделал головокружительную карьеру ростовой куклы, распугивающей пассажиров у выхода из метро. Но за анекдотическими ситуациями кроется главная проблема: по-настоящему квалифицированные люди это крупицы и большая редкость

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

Трудности перевода

Справедливости ради оговорюсь, что DevOps это не название профессии, а методология. Она описывает набор подходов и практик, которые помогают командной разработке. Но штампы преследуют нас повсюду. И вот уже не режет слух, когда уважаемый заказчик, представляя свою команду на установочном звонке, говорит: А это Антон, наш девопс. Знакомьтесь, DevOps. Человек и пароход.

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

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

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

Байка про хромого девопса

Недавно нас позвали на помощь в один проект, где стояла, на первый взгляд, простая задача. Web-приложение работало через web-сокеты, но было развернуто внутри периметра, а на фронте стоял ISPManager, который в качестве reverse proxy использовал apache. Юный девопс, работавший в этом проекте, перепробовал все примеры конфига апача, которые нашел в Гугле, и вконец разочаровавшись в его поисковых способностях, перешел уже было к Яндексу, но тут менеджер проекта забил тревогу. На задачу к тому моменту было потрачено 72 часа. 72 часа, Карл! Кто вам сказал, что методология DevOps ускоряет разработку и сокращает time-to-market? ;)

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

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

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

Про технологии

DevOps это про культуру и философию совместной работы, но с этим понятием также сопряжен определенный технологический стек. Скорее всего я не ошибусь, если скажу, что какие-нибудь NetApp, Cisco, AIX или MS SQL воспринимаются как старый добрый олдскул (хотя это не совсем так, и классические вендоры делают гигантские шаги в новом направлении), а вот, скажем, Docker, Ansible, Jenkins и Prometheus в нашем сознании прочно ассоциируются с DevOps, SRE и новыми веяниями.

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

Найти в гугле пример и скопипастить его к себе еще один легкий путь отхватить проблем. Типичный пример тюнинг и оптимизация сети и ядра через параметры sysctl. Конфиг, который удачно сработал для кого-то в интернете, не является волшебной пилюлей для любой другой системы. Как минимум, надо разобраться, что каждая директива значит. Может в вашей версии ядра она вообще deprecated.

И отдельная боль это сеть. В сети надо разбираться, владеть инструментами диагностики. Сеть не зависит от платформы, она есть везде и напрямую (а порой больно) влияет на работоспособность и производительность всего остального. Когда человек, грезящий себя девопсом, наивно полагает, что надо установить свежую версию Kibana, потому что она умеет конвертировать адреса IPv6 в IPv4 это звучит как анекдот. Но потом он, например, берет и орудует с сетью вот так:

или вот так:

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

А давайте-ка все распилим на микросервисы, засунем в Docker и запустим в Kubernetes

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

Но не все следует доводить до маразма, даже если это увлекательно. Недавно моей команде на попечение был передан проект разработки мобильного приложения, в котором до нас один одаренный девопс настроил деплой бэкэнда на тестинг и продакшн, а затем от греха подальше уволился. Бэкэнд, по сути, представлял собой приложение на python, упакованное в один единственный контейнер. И этот одинокий контейнер исполнятся на одном физическом хосте. Мы читали путанный многоэтажный Dockerfile и искренне недоумевали, зачем все это надо было вообще совать в контейнер. Точнее, в контейнере ему и место, но не в этом.

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

Вот, кстати, символичный фрагмент одного из скриптов по деплою:

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

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

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

- А у вас есть kubernetes?

- Да, конечно, ну как у всех! Как полагается.

- А зачем?

- Ну как это зачем? Это же

Дальше следует немая сцена, гримаса ужаса и спустя некоторое время человек, вероятно, идет топиться.

Я считаю себя евангелистом подхода Infrastructure as Code (IaC). Мне спокойно только тогда, когда продукт не просто освоен, а когда его развертывание и настройка автоматизированы. Специально не добавляю слово документированы, потому что декларативный характер инструментов IaC что приятно во много порождает автодокументируемый код.

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

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

Просто через docker run:

С помощью docker-compose

А вот тот же сервис в Kubernetes

Если решение все же принято, вам предстоит перелопатить горы документации, написать тонны yaml-a, мучительно искать, где пропущен отступ, по 10 раз пересобирать контейнеры. И в этом момент вы еще и не знаете, что через пару недель пройдете новый круг ада, подстраивая ваш деплоймент под Pod Security Policy и разные энтерпрайзные фичи. Конечно, когда вы это дотащите до конца, вы получите красивый сервис, который легко скейлится, автоматически перезапускается при сбоях, который можно обновлять, используя, например, канареечные релизы или какой-нибудь blue-green deployment.

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

Автоматизация как истинный путь джедая

Наши бэкапшики помнят один случай, как сотрудник заказчика собирался в консоли что-то удалить то ли ненужный симлинк, то ли копию конфига. А его то и дело дергали. По воле случая в один момент так сошлось, что товарищ успел набрать rm -rf /oradata, работая от рута, потом чихнул, что в свою очередь пробудило в его организме рута позывы на исход жидкости, а по дороге обратно он зацепился языками с товарищами. Когда он вернулся на рабочее месте, его экран спал. Не будучи в силах терпеть проделки этого вечно дремлющего устройства и дабы преподнести ему урок бодрости, товарищ решительно разбудил его точным ударом в Enter. В общем, когда все делаешь руками, нелепые вещи случаются сплошь и рядом.

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

Самое плохое в автоматизации это время, которое надо на нее потратить. И самое хорошее в ней тоже время, которое она впоследствие высвобождает. Например, пару лет назад нам потребовалось в нашем облаке IaaS развернуть инфраструктуру под нового e-commerce заказчика. Архитектура проекта: кластер БД, пул серверов приложений, распределенное хранилище, слой кэширования, сетевые балансировщики, WAF, ну и стандартная обвязка в виде телеметрии, СРК и сбора логов с визуализацией. Конечно, виртуальные машины мы давно создавали при помощи terraform, благо под наше облако можно использовать AWS-провайдер, так как мы по API совместимы. Программные компоненты и раньше ставили через ansible, и опыт настройки всего по отдельности, в общем, был. Но мы задались целью описать инфраструктуру проекта в виде единого пайплайна. На это ушло время, ну и до сих пор части этой автоматизации совершенствуются, так как еще много где были нами после переиспользованы.

Когда нам позже подвернулся аналогичный проект, различия описывались на уровне файла ответов. Мы развернули проект за 2 дня, причем большую часть времени занял перенос данных. В Gitlab CI запускался pipeline, который заполнял переменные для terraform, который затем запускался runner-ом. Тот создавал в облаке сети, диски и ВМ. ВМ запускались с cloud-init, который ставил внутрь puppet agent, который после старта связывался с foreman, забирал настройки для своей роли и деплоил все ПО. Через service discovery подключался мониторинг всех служб, везде встал и настроился filebeat, а бакап полился в S3. Voila! Все быстро и четко, без ошибок и ручных тестов на каждом шаге.

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

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

• осмысленный сайзинг ресурсов;

• отдельные точки монтирования (отдельный диск/раздел) под данные приложений и все, что может быстро пухнуть;

• синхронизацию времени по ntp;

• переход на использование ключей вместо паролей в ssh;

• настроить ротацию всех логов;

• иметь автоматический механизм обновления протухающих SSL-сертификатов

• покрыть мониторингом все ключевые показатели жизнеспособности системы и не забыть про алерты;

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

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

Эти простые меры по принципу Парето составляют не более 20% действий по первичной настройке, но дают 80% вклада в стабильную и автономную их работу в будущем.

Если у вас уже есть provision-система, то следом можно подключить инструмент IaC, и накатывать все эти настройки всегда по умолчанию, через какой-нибудь базовый профиль. Я в такой профиль еще включаю набор обязательных утилит, чтобы, к примеру, в экстренной ситуации не оказалось, что в системе нет lsof, tcpdump и т. п.

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

Как не стать героем баек

В игре, которую мы ведем в жизни, многое зависит не только от того, что мы знаем и умеем, как и от того, насколько в себя верим. Между состояниями, когда ты еще просто админ, и когда ты уже причислен к сословию девопсов граница весьма призрачная. И по упомянутым выше причинам люди стараются быстрее ее пересечь. Поучился по видосикам на ютубе девопс. Запустил хром в докере у себя на компе девопс. Засунул в гит всю свою папку с котиками ну, тоже девопс.

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

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

И напоследок завет работодателям

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

Если вам понадобился девопс, у вас вероятно уже есть разработка. Задачи, которые выполняет девопс это та же разработка, только инфраструктуры и процессов, поэтому к ней в целом применимы те же правила. Над девопсом должен быть senior или тимлид, который через систему контроля версий делает code review, проверяет и одобряет PR/MR. И совершенно точно не стоит доверять архитектурные вопросы человеку без подтвержденного архитектурного опыта. Лучше поищите стороннюю экспертизу для подстраховки.

Мне также нравится концепция, когда отдельно от специалистов DevOps позиционируется еще одна команда - платформенных инженеров (Platform engineer). Она не работает непосредственно с девелоперами, но именно она снабжает девопса готовыми, отлаженными рычагами к этой платформе и уже настроенному инструментарию. Именно такой подход позволяет снизить планку требований к девопсу, позволяя ему спокойнее учиться и снижая риск его ошибок.

В этом месте ставлю не точку, а многоточие, так как тема неисчерпаемая и весьма холиварная. Комментарии, как говорится, покажут :)