devops практики и инструменты отус
DevOps-практики: Кто? Где? Сколько?
DevOps-инженера ищут многие, но находят не все. Специалисты, умеющие внедрять DevOps-практики, последние 3 года являются одними из самых востребованных на IT-рынке. Спрос на них постоянно растёт. Заработная плата, несмотря на кризис, тоже не падает. Хорошие причины, чтобы задуматься, как прийти в эту профессию и каким образом в ней развиваться?
Специальность DevOps-инженера действительно появилась в IT-индустрии относительно недавно и быстро вырвалась в «топ». Development Operations – это, в первую очередь, набор практик, призванный улучшить и автоматизировать процесс доставки продукта до конечного пользователя, и он может быть полезен везде, где речь идёт о разработке приложений или управлении большим количеством серверов. Пожалуй, только небольшие команды могут позволить себе не выделять DevOps в отдельную функцию и обходиться исключительно своими силами.
Итак, какие задачи решает DevOps-инженер?
Его основная цель – выявлять «узкие места» и при помощи DevOps-практик обеспечивать «прохождение» продукта через эти «ловушки». Решаемые задачи всегда носят практический характер и находятся на стыке разных областей. Как правило, они зависят от потребностей продукта, от команды и подходов, которые применяются в той или иной компании. Проекты, входящие в зону ответственности DevOps, можно сгруппировать в четыре основных направления:
Обеспечение полного жизненного цикла продукта;
Подготовка различных окружений (разработка — тестирование — production) и обеспечение поставок продукта на эти окружения;
Обеспечение автоматического прохождения продукта через различные стадии непрерывной интеграции (CI) и непрерывной доставки (CD);
Виртуализация и управление инфраструктурой, мониторинг.
Результатом внедрения методологии и практик DevOps становится синхронизация различных этапов разработки и выпуска конечного продукта. Чтобы решать задачи подобного масштаба, DevOps-инженер должен выступать одновременно в роли админа, разработчика, тестировщика и менеджера. Однако не стоит думать, что появление такого человека в команде сразу и полностью решит проблемы. Все члены коллектива, чья деятельность, так или иначе, подразумевает связь с DevOps, оказываются вовлечены в эти процессы.
Исходя из направлений деятельности, на практике DevOps-инженер используют следующие инструменты:
CI/СD и интеграцию (Jenkins, TeamCity, GitLab, Bamboo);
Автоматизацию (Terraform, Puppit, Ansible);
Облачные платформы (AWS, Google Cloud Platform, Microsoft Azure, Huawei Cloud, Яндекс Облако, Mail.ru Cloud Solutions);
Мониторинг (Prometheus, Grafana, Zabbix, Nagios);
Системы логирования, трассировки (ELK Stack, Graylog, Gafana, Jaeger);
Контейнеризация и орекстрация (Docker, Kubernetes, Nomad).
Карьерная карта
Андрей Синицын, Head of IT Optimisation Departmen в «ECommPay», рассказывает: «Я занимаюсь компьютерами с середины 90-х — я из того времени, когда эта профессия выбирала тебя. Передо мной никогда не стояло вопроса, чем заниматься по жизни. Сначала я работал программистом, потом понял, что мне интереснее эксплуатация, и ушел в DevOps. «Живой» продакшн — это всегда интересно. И, на мой взгляд, интереснее, чем написание программы: ты видишь, как код эволюционирует, как он работает, как он выполняет (или, как это часто бывает, не выполняет) ту задачу, для решения которой был написан».
Комплексность подхода, характерная для DevOps-процессов, и сложность их полного охвата объясняют тот факт, что на рынке труда востребованы курсы и сертификаты, как правило, связанные с повышением навыков использования конкретных инструментов, но не DevOps-практику целиком.
Сертификаты AWS, GCP, Azure, Kubernetes (CKA, CKAD) могут рассказать работодателю о том, что соискатель имеет навык работы с конкретными платформами, но, как правило, DevOps-инженером становятся только на практике.
Составляя идеальное «DevOps-резюме», важно отразить в нём навыки, которыми вы владеете, задачи в рамках уже реализованных проектов, их особенности, зону ответственности; используемый стек технологий и, конечно, не забыть о soft-skills. Андрей Синицин подчёркивает, что для DevOps «очень важны хорошие коммуникативные навыки, знание английского, обучаемость и out-of-box thinking — стандартный набор для любой специализации в IT. Еще я бы добавил, что большое преимущество в DevOps дает понимание бизнеса (или стремление к этому). Эксплуатация никогда не зарабатывает деньги напрямую, и осознавать business value того, что ты делаешь, очень важно».
В свою очередь, рассматривая те или иные вакансии, соискатель должен обращать внимание на информацию о компании и проекте, основных обязанностях, масштабе задач, которые предстоит решать, текущем состоянии жизненного цикла продукта и с помощью каких инструментов он построен (используемый стек).
Кстати, нам вы также можете прислать резюме по этой ссылке.
Перспективы – сегодня и завтра
DevOps-инженеры действительно зарабатывают больше всех в отрасли. В США, Канаде, UK заработная плата колеблется между 90 и 122 тысячами долларов в год. Что касается России, то в Москве работодатели готовы предложить такому специалисту в среднем 260 тыс. рублей в месяц (верхняя планка доходит до 350 тыс. ), в Санкт-Петербурге средняя зарплата составляет 200 тыс. рублей.
Есть и нематериальные мотиваторы. В частности, участие в масштабных проектах, решение сложных задач, возможность применять новые технологии и подходы. По словам Андрея Синицына, главный стимул, это «создаваемый продукт, наверное. И интереса добавляет то, что этот продукт — не «коробочный». Участие в таких проектах всегда вдохновляет, появляется даже ощущение «творца»: когда команда создает шаг за шагом большую и сложную систему, которая обрабатывает огромное количество трафика, отвечая требованиям надежности.
Конечно, в мои обязанности входит и рутинная работа: что-то падает, что-то зависает, кончается место, ломаются маршруты, теряется связь — это все сотни и сотни мелких повседневных задач, которые решают инженеры эксплуатации.»
Что касается возможностей карьерного роста, то для DevOps-инженера открыт путь к следующим позициям: Devops Team Lead, DevRel (Developer relations), Delivery Manager, Devops architect, Head of Engineering.
DevOps 2021: основные тренды
«Анализируя 2020 год, можно заметить, что в центре внимания стала, прежде всего, безопасность. В том числе, безопасность IT-продуктов, поэтому одним из самых заметных трендов является DevSecOps и в целом SDLC (Security development lifecycle). DevSecOps подразумевает встраивание процесса безопасной разработки в процесс DevOps, интеграцию парадигм безопасности в каждый из этапов разработки.
Внедрение таких подходов, как DevSecOps, невозможно без следующего тренда — автоматизации, одного из основных «китов» DevOps-практики. Скрипты, автоматизация, внедрение подхода IaC (инфраструктура как код) — все это обеспечивает гибкость, скорость процессов разработки и поставки продукта.
Стоит также выделить глобальный тренд, который существует уже несколько лет — это переход в cloud-native-среду и разработка приложений с учетом особенностей облачных платформ», — считает Элиса Данильсон, консультант направления IT&Telecoms в Санкт-Петербурге.
Подробнее о курсе «DevOps: практики и инструменты»
Внутри современного IT-подразделения очень важно обеспечить взаимную интеграцию рабочих процессов между разработчиками, тестировщиками, специалистами по информационно-технологическому обслуживанию. Это ускорит выполнение поставленных задач, позволит оперативно обновлять программные продукты и услуги, повысит стабильность, надежность, безопасность и устойчивость production-среды. Лучший способ сделать цифровой бизнес более эффективным и привить вашей команде набор необходимых инженерных практик — пройти обучение на курсе «DevOps практики и инструменты».
Курс подготовлен официальным партнёром OTUS — компанией Экспресс 42, которая на протяжении уже более 5 лет помогает внедрять DevOps-практики в крупные российские и зарубежные организации.
Что входит в программу курса?
Программа составлена на основе опыта, накопленного компанией Экспресс 42. Цель — решить задачу взаимодействия инженеров между собой, что, в свою очередь, поможет им быстрее создавать и обновлять сервисы и приложения.
Программа включает в себя следующие модули: 1. DevOps: описание, история развития, локальное окружение инженера, знакомство с облачной инфраструктурой, основные сервисы GCP и пр. 2. Особенности управления инфраструктурой и конфигурацией (Packer, Ansible, Terraform). 3. Continuous Integration & Continuous Delivery с использованием Docker (gitlab). 4. Fast Feedback Loop (мониторинг и логирование), EFK (ElasticSearch Fluentd Kibana), Zipkin, Prometheus. 5. Контейнерная Оркестрация (Kubernetes). 6. Проектная работа.
В чём особенность курса?
Главная особенность заключается в специфике подачи материала. Речь идёт о постоянном переходе от абстрактного к конкретному: сначала даётся карта конкретных практик, после этого — отдельные подпрактики с моментальным погружением в инструмент. Так как карта практик для специалиста уже сформирована, риск попасть в колею прошлого опыта отсутствует.
Каковы итоги обучения?
В результате обучения на курсе вы подробно освоите инструменты и конкретные приёмы для реализации следующих практик: • инфраструктура как код; • непрерывная поставка ПО; • непрерывный сбор метрик (мониторинг и логирование).
Ознакомиться с программой более подробно вы сможете на странице курса. Если хотите задать вопрос, пишите комментарий!
Devops практики и инструменты отус
Quicker mitigation of software defects – The better communication and collaboration between operations and software development, you can identify and mitigate defects at any stage of the development cycle. The same culture can be applied to Application development
Better resource management – In the course of application and software development stage, developers and testers are constantly waiting for resources to arrive causing delays in delivery. Agi
В конце курса «DevOps практики и инструменты» студентов ждёт выполнение проекта. Это самостоятельная работа, необходимая для закрепления полученных знаний. Предлагаем вашему вниманию проект Александра Баркова, одного из лучших выпускников курса.
Мы в OTUS постоянно интересуемся мнением наших студентов о том, насколько им интересно учиться, что именно они узнают, чем запоминаются занятия, с какими проблемами сталкиваются. Специально для этого была внедрена опросная система, цель которой — улучшить качество образования и оперативно устранять возникающие проблемы. И конечно, мы всегда радуемся, когда студенты готовы дать фидбек не только в формате опроса, но и ответить на конкретные вопросы лично. Так мы связались с Иваном Борискиным, выпускником курса «DevOps практики и инструменты».
Один день из жизни DevOps
Накануне запуска курса «DevOps-практики и инструменты» мы провели очередной открытый урок. Вебинар получился весьма содержательным. По сути, это была полуторачасовая практика в режиме нон-стоп:
Начнём с того, что запустим виртуалку, т. к. всю работу будем делать там. И сразу сделаем директорию с названием «Hello», где будем разрабатывать наше приложение:
Потом создадим файл под названием app.py, куда вставим следующий код:
Как видите, в коде нет ничего сложного. Но если мы файл включим как модуль из другого приложения, то он ничего не будет делать, а будет делать лишь в том случае, если мы его запустим напрямую как приложение, за что отвечает следующая конструкция:
Стильно, модно, молодёжно, просто — это так называемое Stateless-приложение, которому в принципе для работы ничего не нужно, например, базы данных. При этом наше приложение, состоящее из 10 магических строк кода, готово при получении запроса его обслужить.
Следующая важная особенность — мы хотим, чтобы наше приложение работало через web. Но давайте представим, что наш код очень сложный, а мы хотим иметь возможность его перед выкладкой как-то проверять. Для этого мы помечаем файл app.py как исполняемый и сразу проверяем в консоли, что всё работает:
Также нам понадобится инструмент, который позволит контролировать развитие приложения, к примеру, изменения в версиях и т. д. Тут пригодится всем известная система контроля версий Git, которая устанавливается простой командой:
Конечно, это надо бы поправить, но перед этим сделаем другую важную вещь — объясним гиту, кто мы такие. Почему это важно? Дело в том, что когда вы сохраняете какую-нибудь версию кода, вы должны написать, кто сделал коммит, как его зовут, и какой у него адрес электронной почты. Без этих настроек гит попросту не даст нам сделать коммит.
Нам помогут две простые команды:
Теперь добавим наш файлик, сообщив, что это первая версия приложения. И после успешного срабатывания коммита сразу же посмотрим историю командой git log:
Если хотим увидеть более подробную историю изменений, к команде git log добавляем параметр –p :
Как видим, теперь к каждому коммиту будет прикрепляться diff тех изменений, которые происходили, т. е. мы будем видеть какие строчки добавили, а какие убрали. Это очень удобно, если вы работаете с кодом.
Теперь представьте, что от нас требуют, чтобы приложение открывалось и работало в браузере. Это можно сделать мегастародревним методом.
Для начала установим Apache:
Проверив браузер, увидим, что Apache установлен:
Apache ожидает, что он будет сбрасывать файлы, которые у него будут, в определённую директорию. Её можно увидеть, но там пока ничего нет:
Давайте теперь пойдём в директорию /var/www/html и сделаем очень простую вещь: перенесём директорию старого html в html2. А дальше сделаем ещё одну хитрую вещь: директорию html направим на домашнюю директорию, где у нас лежит приложение:
Что произошло в итоге? Мы создали ярлык, но ярлык этот — html и, как говорится, отряд не заметит потери бойца. Теперь при наших обращениях к веб-серверу Apache будет бежать в нашу директорию, где и лежит приложение. Но просто так он приложение запускать не будет.
А значит, надо продолжить настройку. Во-первых, следует включить отвечающий за выполнение внешних скриптов модуль Apache:
Но пока запускать не будем, ведь ещё нужно добавить возможность переопределять настройки Apache путём создания файлов в нашей директории с проектом. Для этого давайте поправим сайт Apache по умолчанию:
И добавим сюда очень простую конструкцию: скажем, что в директории /var/www/html можно переопределять всё, что угодно, добавив всего 3 строчки кода:
Расшифровываем по строчкам:
Вуаля! Путь от простейшего обычного приложения до простейшего веб-приложения мы прошли за минут 20:
Теперь фиксируем эту версию, добавляя в коммит только app.py :
Посмотрев лог, увидим, что у нас уже две версии, причём вторая версия модифицирована под исполнение CGI.
Для этого редактируем наш код, модифицируя его:
Теперь, если вызов происходит через Apache, строчка print(«Content-type: text/html\n\n») добавляется, а если вызов осуществляется просто так, то она убирается (не показывается).
Всё вышло очень даже неплохо, поэтому пришло время пометить то, что получилось, как некую версию, добавив тег:
Что даёт тег? Например, возможность возвращаться (откатываться) к нужным версиям кода.
Краткий вывод из этого демо:
Итак, мы хотим продолжать работать с кодом и вносить в него изменения, но не хотим, чтобы наши коллеги это видели, и чтобы им это как-то мешало. Поэтому используем фичу гита под названием branch. Она позволяет создать ответвление (копию репозитория со всем его кодом), куда дальше будем складывать свои коммиты. А когда мы посчитаем, что разработка закончена, можно будет влить изменения в основной репозиторий.
Для создания копии репозитория выполняем простую команду:
Для совместимости со стандартом uWSGI вносим изменения в код:
Теперь нужно установить то, что нужно для работы этой версии, ведь uWSGI — это особый сервер:
Чтобы запустить наш файл, выполняем следующую замечательную конструкцию:
Мы увидим, что наши изменения отлично влились поверх того, что было.
Что же мы увидели в этом демо:
Итак, у нас сейчас используется встроенный сервер uWSGI, но это не очень круто, ведь он не очень производительный. А вообще, хорошо бы использовать nginx, т. к. это модно. Кроме того, шеф на переговорах, поэтому в ближайшее время проект придётся выкатывать, а в воздухе пахнет скорым деплоем.
А теперь создадим простенький конфигурационный файл, который позволит nginx принимать входящие соединения и пробрасывать их на uWSGI, то есть получим более-менее современный веб-стек. Но прежде удалим файлы конфигурации nginx по умолчанию, т. к нам нужно положить туда свои. Также создаём файл конфигурации нашего сервера и перезапускаем nginx :
Вот содержимое нашего конфигурационного файла:
Теперь можно переходить в нашу директорию и копировать настройки, созданные на этапе разработки, в настройки прода.
И редактируем настройки, меняя одну строчку:
Далее идём в нашу директорию и запускаем uwsgi с настройками прода:
После чего убеждаемся, что всё работает и готово к деплою:
Каковы итоги Demo 4:
Не успели мы допить очередную чашку кофе, как прибегает шеф и говорит, что пора бы и деплой делать. Это значит, что нам предстоит писать не просто код, а инфраструктурный код, то есть, тот код, который умеет выкатывать наше приложение.
Не руками же это делать, ведь у клиента 5 тысяч серверов, и они находятся в разных дата-центрах и разбросаны по миру, и нам нужно туда задеплоить наше приложение. И мы понимаем, что нам нужно как-то переходить к хранению инфраструктурного кода. В данном случае мы принимаем инженерное решение хранить инфраструктурный код в одной директории с нашим кодом приложения. Это, кстати, одна из практик девопса. Когда мы с вами говорим про деплой, то подразумеваем, что деплой должен быть автоматизирован, автоматизация означает написание инфраструктурного кода, а мы можем хранить инфраструктурный код как с приложением, так и отдельно. Так как приложение простое, мы принимаем решение хранить всё вместе.
Что делаем дальше? Идём в нашу директорию и создаём одним движением 5 директорий, причём они разные:
Зачем нам это? Дело в том, что наш код может запускаться при помощи Apache, при помощи nginx, uWSGI, да и systemd понадобится, поэтому надо красиво и качественно это всё вместе разложить. Что мы и делаем:
Что ж, настало время поделиться кодом с внешним миром. А значит, надо подготовить возможность этот код куда-то выложить. В нашем случае можно воспользоваться своим аккаунтом на гитхабе, создав публичный репозиторий с именем «Hello». Для работы с гитхабом выполняем необходимые настройки. Т. к. всё настроено с помощью SSH-ключей, никаких логинов и паролей вводить не нужно.
Забрасываем изменения на гитхаб:
Вроде бы всё клёво, только в нашем удалённом репозитории не будет хватать тегов. Почему, ведь мы же их делали? Дело в том, что теги не переносятся автоматически в удалённый репозиторий, поэтому мы тег передадим вручную:
Теперь наша версия появится в разделе релизов и будет представлять собой некую версию приложения, которую можно будет скачать в архиве:
У нас есть ещё одна задача: сделать так, чтобы наш демон uWSGI запускался автоматически, при этом мы не хотим использовать никакие внешние инструменты. Для решения этой задачи создадим юнит-файл для systemd :
Со следующим содержимым:
Теперь можем смело стартовать, и консоль не будет ругаться:
Мы в принципе построили некую конфигурацию, которую хотели бы видеть в деплое. Теперь возвращаемся в домашнюю директорию, копируем наш скрипт и кладём его в папку deploy :
И сейчас мы в принципе готовы деплоиться на любой сервер. А значит, можно делать коммит и создать новый релиз 2.0:
Что же, на этом остановим нашу текстовую трансляцию. Однако вы можете продолжить просмотр, так как день девопс-инженера ещё не закончился и впереди ещё:
Пример выпускного проекта курса «DevOps практики и инструменты»
Выполнение выпускного проекта предусмотрено в конце курса «DevOps практики и инструменты» в OTUS. Это самостоятельная работа, необходимая для закрепления полученных знаний. Предлагаем вашему вниманию проект балансировщика одного из наших выпускников, Вячеслава Егорова.
Вячеслав создал хорошо задокументированный проект, использующий стек ELK в кластере, Traefik и SSL для обеспечения доступа к сервисам и балансировки нагрузки.
Инфраструктура следующая: — поднимаются ВМ; — внутри — docker-swarm-cluster; — остальное — в виде абстракции Stack в Docker swarm.
Инфраструктура поднимается с помощью Terraform и выполняется в Shared gitlab-runner.
Давайте посмотрим на Pipeline проекта:
А вот принцип работы Traefik:
Обратите внимание, что каждому контейнеру в кластере мы можем назначать label. И если label traefik.enable=true, то traefik найдёт контейнер и будет ждать подключения по адресу, прописанному в label.
Подробную информацию об особенностях реализации вы можете узнать по ссылке на репозиторий или в презентации.
Проект был рассмотрен преподавательским составом и получил следующие оценки и рекомендации: 1. Преимущества: — использование Traefik для доступа к сервисам с автоматическим получением сертификатов SSL; — управление Google DNS при помощи Ansible; — использование в проекте Docker swarm является и плюсом и минусом одновременно; — применённое приложение Sockshop в лучших традициях показывает, что такое микросервис; — решение использовать Swarmprom достаточно логично. 2. Рекомендации: — постараться разработать и добавить свои метрики и визуализировать их в Grafana; — разработать CI\CD; — доработать систему разворота окружения; — внедрить систему логирования; — доработать документацию.
Кроме того, были отмечены преимущества инструментария для работы с обратной связью проекта: — Swarmprom-сборка для мониторинга кластера Docker swarm; — кластер ELK для логирования, шаблоны для парсинга логов.
Также преподаватели порекомендовали уделить внимание процессу ci\cd, так как оптимальным решением будет вынести мониторинг в другой репозиторий для возможности работы инфраструктурной команды.
Несмотря на несколько рекомендаций, итоговый проект был признан успешным. Студент на практике продемонстрировал полученные знания и расширил своё профессиональное портфолио.