Что такое devops труба

Кто такие DevOps?

На данный момент это чуть ли не самая дорогая позиция на рынке. Суета вокруг «DevOps» инженеров превосходит все мыслимые пределы, а тем хуже с Senior DevOps инженерами.
Я работаю руководителем отдела интеграции и автоматизации, угадайте английскую расшифровку — DevOps Manager. Отражает ли именно английская расшифровка нашу повседневную деятельность — вряд ли, а вот русский вариант в данном случае более точен. По роду моей деятельности, естественно, что мне, необходимо собеседовать будущих членов моей команды и, за прошедший год, через меня прошло человек 50, а еще столько же срезалось на прескрине с моими сотрудниками.

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

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

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

Так кто же такие DevOps инженеры?

Давайте начнем с истории появления — Development Operations появился как еще один шаг к оптимизации взаимодействия в малых командах для повышения скорости производства продукта, как ожидаемое следствие. Идея заключалась в том, чтобы усилить команду разработки знаниями о процедурах и подходах в управлении продуктовой средой. Иными словами, разработчик должен понимать и знать как его продукт работает в тех или иных условиях, должен понимать как деплоить его продукт, какие характеристики среды подкрутить, чтобы повысить производительность. Так, в течение некоторого времени, появились разработчики с DevOps подходом. DevOps разработчики писали скрипты сборки и упаковки для упрощения своей деятельности и работоспособности продуктивной среды. Однако, сложность архитектуры решений и взаимное влияние компонентов инфраструктуры с течением времени начало ухудшать рабочие показатели сред, с каждой итерацией требовались все более глубокие понимания тех или иных компонентов, снижая продуктивность самого разработчика из-за дополнительных затрат на понимание компонентов и тюнинга систем под конкретную задачу. Собственная стоимость разработчика росла, стоимость продукта вместе с ним, резко подскочили требования к новым разработчикам в команде, ведь им необходимо было также покрывать обязанности «звезды» разработки и, естественно, «звезды» становились все менее доступны. Также стоит отметить, что, по моему опыту, мало кому из разработчиков интересна специфика обработки пакетов ядром операционной системы, правила маршрутизации пакетов, аспекты безопасности хоста. Логичным шагом было привлечь администратора, который именно с этим знаком и возложить подобного формата обязанности именно на него, что, благодаря его опыту, позволило достичь тех же показателей меньшей стоимостью в сравнении со стоимостью «звезды» разработки. Таких администраторов помещали в команду и основной его задачей было управление тестовыми и продуктивными средами, на правилах конкретно взятой команды, с ресурсами выделенными именно этой команде. Так, собственно, и появились DevOps в представлении большинства.

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

Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к системным администраторам, которые способны построить данные системы.

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

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

Build Engineer/Release Engineer

Весьма узкоспециализированные инженеры, появившиеся как средство стандартизации процессов сборки ПО и его релизов. В процессе введения повального Agile казалось бы они перестали быть востребованы, однако это далеко не так. Эта специализация появилась как средство стандартизации именно сборки и поставки ПО в промышленных масштабах, т.е. используя стандартные техники для всех продуктов компании. С появлением DevOps разработчиков частично утратили функции, поскольку именно разработчики стали подготавливать продукт к поставке, а учитывая изменяющуюся инфраструктуру и подход в максимально быстрой поставке без оглядки на качество со временем превратились именно в стопор изменений, поскольку следование стандартам качества неизбежно замедляет поставки. Так, постепенно, часть функционала Build/Release инженеров перекочевала на плечи системных администраторов.

Ops’ы такие разные

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

Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.

Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.

Недостаток средств и возможности влияния хотя бы на одно из этих трех направлений деятельности произведет смещение веса проблем в сторону где эти изменения проще применить, как например применение технических ограничений на релизы в связи с «грязным» кодом по данным систем статического анализатора. То есть когда PMO устанавливает жесткий срок на выпуск функционала, R&D не может выдать качественный результат в эти сроки и выдает его как может, оставив рефакторинг на потом, DevOps относящийся к IT, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.

Рынок DevOps ресурсов

Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.

Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.

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

Рассмотрим иную вакансию:

Резюмируя — Middle/Senior System Administrator

Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все. Для примера возьмем ‘build framework’ Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно?
По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.

Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.

Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.

Сколько вешать в граммах

Разброс предлагаемых зарплат для указанных вакансий — 90к-200к
Теперь хотелось бы провести параллель между денежными вознаграждениями Системных Администраторов и DevOps Engineers.

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

Сайт поиска сотрудников предлагает:
System Adminsitrators:

По стажу «DevOps»’ов использовался стаж, хоть как то затрагивающий SDLC.

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

Процесс обучения DevOps инженеров также ограничен лишь набором специфичных работ, утилит, не дает общего понимания процессов и их зависимостей. Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.

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

Так кто же они? DevOps’ы или жадные системные администраторы? =)

Как дальше жить?

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

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

Источник

Зачем нужен DevOps и кто такие DevOps-специалисты

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

Какие практики входят в понятие DevOps и зачем они нужны? Чем занимаются DevOps-инженеры и что они должны уметь? На эти и другие вопросы отвечают эксперты из EPAM: Кирилл Сергеев, системный инженер и DevOps-евангелист, и Игорь Бойко, ведущий системный инженер и координатор одной из DevOps-команд компании.

Зачем нужен DevOps?

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

Что такое DevOps?

Вопрос хороший – и спорный: окончательно в мире об этом пока не договорились. В ЕРАМ считают, что DevOps объединяет в себе технологии, процессы и культуру взаимодействия внутри команды. Это объединение нацелено на непрерывную доставку ценностей конечным пользователям.

Кирилл Сергеев: «Разработчики пишут код, тестировщики его проверяют, а администраторы устанавливают финальный продукт на производственное окружение. Долгое время эти части команды были несколько разрознены, а потом появилась идея объединить их общим процессом. Так появились DevOps-практики».

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

В чем состоит суть DevOps-культуры?

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

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

Какие бывают DevOps-практики?

DevOps-практики покрывают все этапы жизненного цикла ПО.

Игорь Бойко: «Идеальный случай – когда мы начинаем использовать DevOps-практики прямо при инициации проекта. Вместе с архитекторами мы планируем, какой у приложения будет архитектурный ландшафт, где оно будет располагаться и как масштабироваться, выбираем платформу. Сейчас в моде микросервисная архитектура – для нее мы выбираем систему оркестрации: нужно уметь управлять каждым элементом приложения по отдельности и обновлять его независимо от других. Еще одна практика – это “инфраструктура как код”. Так называют подход, при котором инфраструктура проекта создается и управляется при помощи кода, а не через прямое взаимодействие с серверами.

Дальше мы переходим на этап разработки. Здесь одна из крупнейших практик – построение CI/CD: нужно помочь разработчикам интегрировать изменения в продукт быстро, мелкими порциями, чаще и безболезненней. CI/CD покрывает и проверку кода, и заливку мастера в кодовую базу, и разворачивание приложения на тестовых и продуктивных средах.

На этапах CI/CD код проходит через quality gates. С их помощью проверяют, чтобы код, который вышел с рабочей станции разработчика, соответствовал заданным критериям качества. Здесь добавляется юнит- и UI-тестирование. Для быстрого, безболезненного и фокусированного разворачивания продукта можно выбрать подходящий тип деплоймента.

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

Чем полезны DevOps-практики?

Если бы мы писали учебник по современным практикам DevOps, на его первой странице значились бы три пункта: автоматизация, ускорение релиза и быстрая обратная связь от пользователей.

Кирилл Сергеев: «Первое – это автоматизация. Все взаимодействия в команде мы можем автоматизировать: написали код – выкатили – проверили – установили – собрали фидбэк – вернулись в начало. Всё это – автоматически.

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

Третье – это ускорение обратной связи от пользователя. Если у него есть замечания, мы можем сразу же вносить корректировки и тут же обновлять приложение».

Как соотносятся понятия «системный инженер», «билд-инженер» и «DevOps-инженер»?

Они пересекаются, но относятся к немного разным сферам.

Системный инженер в ЕРАМ – это должность. Они бывают разных уровней: от джуниора до chief-специалиста.

Билд-инженер – это скорее роль, которую можно выполнять на проекте. Сейчас так называют людей, ответственных за CI/CD.

DevOps-инженером называют специалиста, который внедряет на проекте DevOps-практики.

Если суммировать всё это, получается примерно следующее: человек в должности системного инженера исполняет на проекте роль билд-инженера и занимается там внедрением DevOps-практик.

Чем именно занимается DevOps-инженер?

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

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

Кирилл Сергеев: «Прежде чем внедрять обновления в продукт, их нужно протестировать на стороннем окружении. Его готовят DevOps-инженеры. Они же насаждают на проекте DevOps-культуру в целом: внедряют DevOps-практики на всех слоях своих проектов. Эти три принципа: автоматизация, упрощение, ускорение – они привносят всюду, куда могут дотянуться».

Что должен знать DevOps-инженер?

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

1. Языки программирования

DevOps-инженеры знают несколько базовых языков для автоматизации и могут, например, сказать программисту: «Давай ты будешь делать установку кода не руками, а с помощью нашего скрипта, который всё автоматизирует? К нему мы подготовим config-файл, его будет удобно читать и тебе, и нам – и мы в любой момент сможем его изменить. А еще мы будем видеть, кто, когда и для чего вносит в него изменения».

DevOps-инженер может выучить один или несколько из этих языков: Python, Groovy, Bash, Powershell, Ruby, Go. Знать их на глубинном уровне не требуется – достаточно основ синтаксиса, принципов ООП, умения писать несложные скрипты для автоматизации.

2. Операционные системы

DevOps-инженер должен понимать, на каком сервере будет установлен продукт, в какой среде будет запускаться, с какими сервисами будет взаимодействовать. Можно выбрать специализацию на Windows или Linux-семействе.

3. Системы контроля версий

Без знаний системы контроля версий DevOps-инженеру никуда. Git – одна из самых популярных систем в настоящий момент.

4. Облачные провайдеры

AWS, Google, Azure – особенно если мы говорим про Windows-направление.

Кирилл Сергеев: «Облачные провайдеры предоставляют нам виртуальные сервера, которые прекрасно ложатся на рельсы CI/CD.

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

5. Системы оркестрации: Docker и Kubernetes

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

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

6. Системы конфигураций: Chef, Ansible, Puppet

Когда необходимо обслуживать целый парк серверов, приходится делать много однотипных операций. Это долго и сложно, а еще ручная работа повышает шанс ошибки. Тут на помощь приходят системы конфигураций. С их помощью создают скрипт, который удобно читать и программистами, и DevOps-инженерами, и системными администраторами. Этот скрипт помогает проводить одинаковые операции на серверах автоматически. Так ручных операций (и, следовательно, ошибок) становится меньше.

Какую карьеру может построить DevOps-инженер?

Развиваться можно и горизонтально, и вертикально.

Игорь Бойко: «С точки зрения горизонтального развития, у DevOps-инженеров сейчас самые широкие перспективы. Всё постоянно меняется, и наращивать навыки можно по самым разным направлениям: от систем контроля версий до мониторинга, от управления конфигурациями до баз данных.

Можно стать системным архитектором, если сотруднику интересно разобраться, как работает приложение на всех этапах своего жизненного цикла – от разработки до поддержки».

Как стать DevOps-инженером?

А также можно посмотреть актуальные тренинги по DevOps на сайте Тренинг-центра EPAM.

Больше информации о DevOps-направлении на сайте.

Источник

Руководство для начинающих: создаем DevOps-пайплайн

Если вы новичок в DevOps, взгляните на эту инструкцию по созданию вашего первого конвейера из пяти этапов.

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

Мое путешествие по DevOps

Раньше я работал в облачной команде Citi Group, разрабатывая веб-приложение Infrastructure-as-a-Service (IaaS) для управления облачной инфраструктурой Citi, но меня всегда интересовало, как сделать процесс развития более эффективным и привнести позитивные культурные изменения в команду разработчиков. Ответ я нашел в книге, рекомендованной Грегом Лавендером (Greg Lavender), техническим директором Citi по облачной архитектуре и инфраструктуре. Книга называлась «Проект Феникс» (The Phoenix Project), и в ней объясняются принципы DevOps, при этом она читается как роман.

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

Amazon: 23 000 в день
Google: 5 500 в день
Netflix: 500 в день
Facebook: Раз в день
Twitter: 3 раза в неделю
Типичная компания: Раз в 9 месяцев

Как вообще возможны частоты Amazon, Google и Netflix? Все потому, что эти компании придумали, как сделать почти идеальный DevOps-конвейер.

Мы были далеки от этого, пока не внедрили DevOps в Citi. Тогда в моей команде были разные окружения, но развертывание на сервере разработки было полностью ручным. Все разработчики имели доступ только к одному серверу разработки на базе IBM WebSphere Application Server Community Edition. Проблема заключалась в том, что сервер выключался всякий раз, когда несколько пользователей одновременно пытались выполнить развертывание, поэтому разработчики должны были сообщать друг другу о своих намерениях, что было довольно болезненно. Кроме того, существовали проблемы с низкоуровневым тестовым покрытием кода, громоздкими процессами ручного развертывания и отсутствием возможности отслеживать развертывание кода, связанного с определенной задачей или пользовательской историей.

Я понял, что нужно что-то делать, и нашел коллегу-единомышленника. Мы решили сотрудничать в создании первоначального DevOps-конвейера – он установил виртуальную машину и сервер приложений Tomcat, пока я работал над Jenkins, интегрировал Atlassian Jira и BitBucket, а также работал над тестовым покрытием кода. Этот сайд-проект был очень успешным: мы почти полностью автоматизировали многие процессы, достигли практически 100% работоспособности нашего сервера разработки, обеспечили отслеживание и улучшили тестовое покрытие кода, а также добавили возможность связывать ветки в Git с задачами в Jira или развертыванием. Большинство инструментов, которые мы использовали для построения нашего конвейера DevOps, имели открытый исходный код.

Теперь я понимаю, насколько простым был наш DevOps-пайплайн: мы не использовали расширения вроде Jenkins files или Ansible. Однако, этот простой конвейер работал хорошо, возможно, благодаря принципу Парето (также известному как правило 80/20).

Краткое введение в DevOps и пайплайн CI/CD

Если вы спросите несколько человек: «Что такое DevOps?», то вы, вероятно, получите несколько разных ответов. DevOps, как и Agile, развивался, чтобы охватить множество различных дисциплин, но большинство людей согласятся с некоторыми вещами: DevOps — это практика разработки программного обеспечения или жизненный цикл разработки программного обеспечения (SDLC), центральным принципом которой является изменение культуры, в которой разработчики и не-разработчики существуют в среде, в которой:

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

Хотя наличие правильных программных инструментов — не единственное, что нужно для создания среды DevOps, некоторые инструменты необходимы. Ключевой инструмент – непрерывная интеграция и непрерывное развертывание (CI/CD). В этом конвейере среды имеют различные стадии (например, DEV, INT, TST, QA, UAT, STG, PROD), многие операции автоматизированы, а разработчики могут писать высококачественный код, добиваться гибкости разработки и высокой частоты развертываний.

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

Шаг 1: Методы CI/CD

Первое, что вам нужно – инструмент для CI/CD. Jenkins, инструмент с открытым исходным кодом, основанный на Java, и распространяемый по лицензии MIT, является тем средством, которое популяризировало направление DevOps и стало стандартом де-факто.

Так что же такое Jenkins? Считайте, что это некий волшебный универсальный пульт дистанционного управления, который может разговаривать с различными службами и инструментами и организовывать их. Сам по себе CI/CD инструмент, такой как Jenkins, бесполезен, но он становится более мощным по мере того, как подключается к различным инструментам и сервисам.

Jenkins – всего лишь один из многих инструментов с открытым исходным кодом для CI/CD, который вы можете использовать для построения DevOps-пайплайна.

Jenkins: Creative Commons and MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Вот как выглядят DevOps-процессы с инструментом CI/CD:

У вас есть инструмент CI/CD, работающий на вашем локалхосте, но на данный момент вы мало что можете сделать. Давайте перейдем на следующий этап путешествия в мир DevOps.

Шаг 2: Управление системами контроля исходного кода

Лучший (и, возможно, самый простой) способ проверить, что ваш инструмент CI/CD может творить магию – интегрироваться с инструментом контроля исходного кода (SCM). Зачем вам нужен контроль над исходным кодом? Предположим, вы разрабатываете приложение. Всякий раз, когда вы создаете приложение, вы программируете, и неважно, используете вы Java, Python, C++, Go, Ruby, JavaScript или какой-нибудь из газиллионов языков программирования. Код, который вы пишете называется исходным кодом. В начале, особенно когда вы работаете в одиночку, вероятно, можно поместить все в локальную директорию. Но когда проект становится больше, и вы приглашаете других людей к сотрудничеству, вам нужен способ предотвращения конфликтов при эффективном обмене модификациями. Вам также нужен способ восстановления предыдущих версий, потому что создание бекапов и копирование/вставка в них уже устаревает. Вам (и вашим товарищам по команде) нужно что-то получше.

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

Хотя существует множество инструментов контроля исходного кода, Git является стандартом, и это верно. Я настоятельно рекомендую использовать Git, хотя, если угодно, есть и другие варианты с открытым исходным кодом.

Git: GPLv2 и LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Так выглядит DevOps-пайплайн с добавлением средств контроля исходного кода.

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

Шаг 3: Создание инструмента автоматизации сборки

Отлично! Вы можете проверять код и вносить изменения в систему контроля исходного кода, а также приглашать своих друзей к сотрудничеству в разработке. Но вы еще не создали приложение. Чтобы сделать веб-приложение, его нужно скомпилировать и упаковать в развертываемый пакетный формат или запустить в виде исполняемого файла. (Обратите внимание, что интерпретируемый язык программирования, такой как JavaScript или PHP, не нуждается в компиляции).

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

Здорово! Вы можете поместить файлы конфигурации инструмента автоматизации сборки в систему управления исходным кодом и позволить вашему инструменту CI/CD собрать все воедино.

Все хорошо, не так ли? Но где развернуть ваше приложение?

Шаг 4: Сервер для веб-приложений

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

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

Существует несколько серверов для веб-приложений с открытым исходным кодом.

Ваш DevOps-пайплайн почти готов к использованию. Хорошая работа!

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

Шаг 5: Покрытие тестирования кода

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

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

Системы тестирования кода

Системы рекомендаций по улучшению кода

Обратите внимание, что большинство инструментов и фреймворков, упомянутых выше, написаны для Java, Python и JavaScript, поскольку C++ и C# являются проприетарными языками программирования (хотя GCC и имеет открытый исходный код).

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

Дополнительные шаги

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

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

Хотя существуют и другие варианты контейнеров, наиболее популярными являются Docker и Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Промежуточные средства автоматизации

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

Вот несколько инструментов промежуточной автоматизации с открытым исходным кодом:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache или GPL

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:

Источник