6 тенденций DevOps в 2022 году, которые должны принять инженеры DevOps

6 тенденций DevOps в 2022 году, которые должны принять инженеры DevOps

15 апреля 2022 г.

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


В основные обязанности входит развертывание выпуска продуктов, интеграция и углубление процессов разработки в поставку, стандартизация процессов разработки, настройка инфраструктуры в соответствии с требованиями ПО, автоматизация процессов. Конечно, наибольшая нагрузка ложится на DevOps-инженеров во время подготовки инфраструктуры для приложения, а также настройки процесса CI\CD, который затем работает в автоматическом режиме. DevOps использует различные инструменты для управления конфигурацией, виртуализации и автоматизации операционных процессов, использования облачных технологий. Чтобы идти в ногу с быстрым развитием технологий, инженеры DevOps должны постоянно учиться, быть сосредоточенными и усердными.


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


Тренд DevOps №1 — Terraform


Terraform — это инструмент от Hashicorp, который помогает декларативно управлять инфраструктурой. Благодаря этой технологии вам не нужно вручную создавать экземпляры, сети и т. д. в консоли облачного провайдера, а просто написать конфигурацию, которая будет излагать, как вы видите будущую инфраструктуру. Эта конфигурация создается в текстовом формате. Если вы хотите изменить инфраструктуру, то отредактируйте конфигурацию и запустите terraform apply. Terraform будет направлять запросы API вашему облачному провайдеру в соответствии с конфигурацией, указанной в файле.


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


Или, скажем, мы хотим создать веб-сервер, который выдавал бы нам домашнюю страницу по запросу www.arizon.page. Процесс создания инфраструктуры (развертывание экземпляра, установка веб-сервера, настройка веб-сервера) может занять около 3-5 минут, и мы получим готовую инфраструктуру со всем функционалом и движками.


С Terraform могут работать один или несколько человек. Как правило, разработка ведется группой людей. Один работает над одной функцией, другой над другой и так далее. Когда пришло время развертывания, мы используем команду terraform apply.


Благодаря механизму блокировки в то время, когда один из товарищей по команде разворачивает свою часть инфраструктуры, никто другой не может этого сделать. Механизм блокировки работает с файлом tf.state, который хранится удаленно (ведро aws s3 или что-то подобное). Если вы не используете удаленный файл tf.state и делаете все локально, то ваши тиммейты не будут знать о сделанных вами изменениях в облаке и могут их просто удалить/изменить. Когда все работают с одним и тем же файлом tf.state, у всей команды будет соответствующее состояние инфраструктуры. Когда одна из команд разворачивается, всем остальным показывается индикатор, что вы не можете развернуть, потому что с ней работает другой человек. Когда процесс развертывания завершен, Terraform автоматически настраивает разблокировку, и другие уже могут работать.


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


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


С помощью двух команд terraform plan\terraform apply инфраструктура будет восстановлена ​​до исходного рабочего состояния за считанные минуты, тогда как отладка может занять несколько часов. Первая команда (terraform plan) покажет изменения, внесенные в инфраструктуру, а вторая (terraform apply) внесет изменения, которые были внесены первой командой. В этом вся сила Terraform (инфраструктура как код). Есть и другие технологии, покрывающие инфраструктуру кодом, такие как Cloud Formation в AWS, Pullumi в Python и другие. Основное правило заключается в том, что инфраструктура должна быть покрыта кодом. В случае ручных изменений Terraform покажет состояние, в которое нужно вернуть код. Но следует избегать ручных изменений и все делать непосредственно в Terraform, просто потому, что именно для этого он и предназначен.


Тренд DevOps №2 — облачные технологии


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


Некоторые компании не доверяют свою конфиденциальную информацию AWS, Google Cloud или Azure. Они хранят все локально и обслуживают свои собственные серверы. Но если в силу неприятных обстоятельств оборудование забирают со средой, которая работает и приносит деньги, они оказываются в статусе «простой» — об этом нужно всегда помнить. Некоторым компаниям может быть запрещено использовать облачные технологии, например государственным компаниям, но это совсем другая история.


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


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


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


Ночью могут работать 15-20 серверов, а утром, когда трафик снижается, количество серверов сокращается до 4-х.


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


Тренд DevOps №3 — Докер


Docker — один из самых известных инструментов для работы с контейнерами. Эта технология позволяет поднять работающее приложение за считанные минуты. И нам больше не нужно создавать виртуальную машину, устанавливать на нее операционную систему и устанавливать в операционной системе необходимые компоненты для запуска приложения. На данный момент все, что нам нужно, это Dockerfile (инструкция по запуску приложения внутри контейнера), в котором мы указываем, какой образ (docker image) нам нужно использовать, а также какие дополнительные компоненты нужны для работы приложения, и т.д. на.


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


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


Часто бывает, что со стороны разработчика все работает, но когда приложение попадает к тестерам — работает не совсем корректно, потому что окружения разные (разные версии установленных пакетов и т.п.). Чтобы сэкономить драгоценное время и избежать обмена билетами между разработчиками и тестировщиками, Docker незаменим.


Тренд DevOps №4 — Kubernetes


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


Контейнерные технологии помогают в ежедневном обновлении приложений для обеспечения бесперебойной работы сервиса 24/7. Kubernetes — это решение, позволяющее обновлять и запускать приложения в любое время и в любом месте за счет оркестровки контейнеров.


Представьте, что веб-сайт размещен на определенном контейнере. Kubernetes следит за тем, чтобы контейнер работал. Если Docker-контейнер по какой-то причине рухнет, Kubernetes создаст такой же новый рабочий контейнер по определенному шаблону, но в этом случае будет определенный статус «downtime». Поэтому рекомендуется запускать как минимум два контейнера, выполняющих одинаковые функции одновременно. В этом случае, если один контейнер рухнет, другой будет доступен, пока другой развернут — так мы избегаем статуса «даунтайм». Таким образом, Kubernetes может отслеживать сотни сервисов, работающих одновременно. Kubernetes напоминает осьминога — у него один центр и множество щупалец, также известных как сервисы.


Таким образом, у Kubernetes есть несколько преимуществ: 1) простое масштабирование контейнерных приложений; 2) легкая миграция — приложения-контейнеры очень просто перенести с локальных машин в облачное хранилище для дальнейшего развертывания; 3) самоуправление — контейнеры перезагружаются, меняются или уничтожаются автоматически; 4) Безопасное развертывание — Kubernetes автоматически обновляет приложения, анализируя их статус.


Тренд DevOps №5 — GoLang и Python


Стандартного набора технологий, которыми должен обладать DevOps-инженер, не существует, но он должен знать один из языков программирования. Эту задачу можно решить несколькими способами — C++, Python, Java. Условием выполнения задания является знание хотя бы одного языка программирования. В 2022 году такой язык программирования, как GoLang, набирает популярность среди инженеров DevOps.


GoLang — это язык программирования, разработанный Google и ставший популярной технологией. В 2019 году он был включен в список самых быстрорастущих языков. Согласно данным StackOverflow за 2022 год, Go занимает 14-е место в мировом рейтинге. популярных языков и 10-е место среди украинских программистов по данным опроса DOU. Благодаря этому языку вы можете быстро и легко создать продукт. Обычно программы, основанные на этой технологии, работают быстрее.


В Go есть множество библиотек, которые работают с конкретным приложением. Например, вы можете назвать библиотеку, которая будет работать с Amazon. С помощью программы, написанной на GoLang, вы можете отключить все сервисы на вашем аккаунте Amazon, которые не соответствуют текущему состоянию (разумеется, если у вас есть на это достаточно прав). Как мы уже говорили, это также можно сделать с помощью другого языка программирования, например Python.


Освоив одну из технологий, можно идти дальше и изучать другую. Важно понимать логику технологии и постепенно изучать синтаксис.


Тренд DevOps №6 — Jenkins\GithubActions


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


Конвейер настраивается в декларативном или скриптовом стиле в Groovy, а файл конфигурации (Jenkinsfile) находится в системе контроля версий вместе с исходным кодом.


Дженкинс настраивается на проблемы, в которых нуждаются разработчики и тестировщики. Для этого откройте Jenkins UI — там есть список вакансий. Выбираем нужную задачу, задаем параметры и нажимаем запустить. После этого Дженкинс переходит на Github (репозиторий, где разработчик запустил свой код), скачивает код и начинает сборку. Если Jenkins обнаружит в процессе синтаксическую ошибку, разработчик может посмотреть в Jenkins Console или получить сообщение в мессенджере, что что-то пошло не так, исправить ошибку, запустить новый код, нажать build и проверить результат Jenkins. Есть много разных плагинов для Jenkins, которые помогают с той или иной функцией. Одним из них является плагин «GitHub», который позволяет запускать Jenkins Job после того, как код попал в ветку GitHub.


Подводя итог, можно сказать, что у Jenkins есть несколько важных особенностей:


  • Непрерывная интеграция и непрерывная доставка

Jenkins можно использовать как простой CI-сервер или превратить в центр непрерывной доставки для любого проекта.


  • Простота установки

Jenkins — это отдельная программа на основе Java, готовая к немедленному запуску с пакетами для Linux, macOS и других Unix-подобных операционных систем. Jenkins также можно запустить в контейнере Docker.


  • Плагины

Благодаря сотням подключаемых модулей Jenkins интегрируется практически со всеми инструментами в цепочке инструментов непрерывной интеграции и доставки.


  • Простота распространения

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


  • Финансовый аспект

Jenkins — бесплатное программное обеспечение, но недостатком является отсутствие технической поддержки. Аналог Jenkins — GithubActions, который является продуктом GitHub и был разработан всего год или два назад. С помощью действий GitHub вы можете запускать сборки прямо в файле git. Преимущество и удобство в том, что вам не нужно оборудование и техническое обслуживание для запуска сборок. Вы можете настроить сборку триггера (тег git, создать запрос на включение, отправить в определенную ветку и т. д.). Инструкции для GitHub написаны в формате .yml.


  • Терминал

Современному DevOps, как и системному администратору, необходимо знать командную строку, потому что большинство систем — это Linux.


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


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


  • На базе Linux

Инженеры DevOps должны ориентироваться в системах Linux, как рыба в воде.


Удобство систем на базе Linux в том, что они не требуют графической оболочки, отнимающей ресурсы. Для работы в системе на базе Linux достаточно командной строки, где выполняются все манипуляции в системе.


Рано или поздно приходится выяснять, почему не работает тот или иной сервис. Для этого нужно выстроить четкую цепочку процесса отладки. Если служба не запускается — нужно просмотреть логи, и если вы видите в логах ошибки, требующие определенных действий — выполнить их и так далее. Для выполнения поставленных задач необходим определенный объем знаний и опыта, который приобретается на практике. Если у вас есть проблема сегодня, вы можете потратить 2 часа на ее решение, и это нормально, но завтра вы справитесь с ней за 2 минуты. Такой подход развивает навыки. И не только с Linux-системами, это тоже процесс любой практики.


  • Bash-скрипты

Автоматизация — одна из ролей инженера DevOps. Если вам нужно что-то сделать несколько раз, то процесс требует автоматизации.


Сценарии Bash — это сценарии командной строки, написанные для оболочки bash, которые представляют собой мощный способ автоматизации часто выполняемых действий.


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


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


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


  • Резервные копии

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


  • Мониторинг

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


Требования к навыкам межличностного общения и трудным навыкам инженера DevOps


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


  • Развить гибкость в работе с командой

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


  • Внимательность на этапе производства

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


  • На первых этапах важно много практиковаться

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


  • Спрашивайте, прежде чем что-то удалить

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


  • Важно иметь хорошего наставника и многому научиться

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


  • Возможные пути развития для инженера DevOps

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


Вне зависимости от выбранного вектора развития каждый DevOps-инженер в 2022 году должен усвоить важное правило Life-Long Learning. Чем больше технологий вы знаете, тем более востребованным специалистом вы становитесь на рынке.


В этой статье Игорь Канивец, Advanced DevOps в Innovecs, рассказывает о роли DevOps-инженеров, их обязанностях, возможностях роста, наборе важных программных и трудные навыки и, самое главное, тенденции DevOps в 2022 году.



Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE