Создание первой цепочки DevOps за пять шагов для новичков.
DevOps стал панацеей для слишком медленных, разобщенных и прочих проблемных процессов разработки. Но нужны минимальные познания в DevOps. Здесь будет рассмотрены такие понятия, как цепочка DevOps и как создать ее за пять шагов. Это не полное руководство, а только “рыба”, которую можно расширять. Начнем с истории.
Мое знакомство с DevOps
Когда-то я работал с облаками в Citi Group и разрабатывал веб-приложение IaaS, чтобы управлять облачной инфраструктурой Citi, но мне всегда было интересно, как можно оптимизировать цепочку разработки и улучшить культуру среди разработчиков. Грег Лавендер, наш техдиректор по облачной архитектуре и инфраструктуре, посоветовал мне книгу Проект «Феникс». Она прекрасно объясняет принципы DevOps, при этом читается, как роман.
В таблице на обороте показано, как часто компании выкатывают новые версии:
Как Amazon, Google и Netflix успевают столько выкатывать? А все просто: они поняли, как создать почти идеальную цепочку DevOps.
У нас в Citi все было совсем не так, пока мы не перешли на DevOps. Тогда у моей команды были разные среды, но поставку на сервер разработки мы делали вручную. У всех разработчиков был доступ только к одному серверу разработки на базе IBM WebSphere Application Server Community Edition. При одновременной попытке поставки сервер “падал”, а нам приходилось каждый раз “болезненно” договариваться между собой. А еще у нас было недостаточное покрытие кода тестами, трудоемкий ручной процесс поставки и никакой возможности отслеживать поставку кода по некоторой задаче или требованию клиента.
Было понятно, что нужно срочно что-то делать, и я нашел коллегу-единомышленника. Мы решили вместе создать первую цепочку DevOps — он настроил виртуальную машину и сервер приложений Tomcat, а я занялся Jenkins, интеграцией с Atlassian Jira и BitBucket, а также и покрытием кода тестами. Проект был успешным: мы полностью автоматизировали цепочку разработки, добились почти 100% бесперебойной работы сервера разработки, могли отслеживать и улучшать покрытие кода тестами, а ветку Git можно было привязать к поставке и задаче Jira. И почти все инструменты, которыми мы строили цепочку DevOps, были открытым исходным кодом.
По факту, цепочка была упрощенной, ведь мы даже не применяли расширенные конфигурации с помощью Jenkins или Ansible. Но у нас все получилось. Возможно, это следствие принципа Парето (он же правило 80/20).
Краткое описание цепочки DevOps и CI/CD
У DevOps есть разные определения. DevOps, как и Agile, включает в себя разные дисциплины. Но большинство согласятся с следующим определением: DevOps — это метод, или жизненный цикл, разработки ПО, главный принцип которого — создание культуры, где разработчики и другие сотрудники “на одной волне”, ручной труд автоматизирован, каждый занимаются тем, что лучше всего умеет, возрастает частота поставок, повышается продуктивность работы, увеличивается гибкость.
И хотя одних только инструментов недостаточно для создания среды DevOps, без них не обойтись. Самым важным из них является непрерывная интеграция и непрерывная поставка (CI/CD). В цепочке для каждого окружения есть разные этапы (например, DEV (разработка), INT (интеграция), TST (тестирование), QA (контроль качества), UAT (приемочное тестирование пользователями), STG (подготовка), PROD (использование)), ручные задачи автоматизированы, разработчики могут делать качественный код, делают его поставку и могут легко перестраиваться.
Данная заметка описывает, как за пять шагов создать цепочку DevOps, как показано на картинке ниже, с помощью инструментов с открытым исходным кодом.
Перейдем к делу.
Шаг 1: Платформа CI/CD
Первым делом вам нужен инструмент CI/CD. Jenkins — это открытый инструмент CI/CD написанный на Java с лицензией MIT, с которого началась популяризация движения DevOps и который де-факто стал стандартом для CI\CD.
А что такое Jenkins? Представьте, что у вас есть волшебный пульт управления для самых разных сервисов и инструментов. Сам по себе инструмент CI/CD, типа Jenkins, бесполезен, но с разными инструментами и сервисами он становится всемогущим.
Кроме Jenkins есть множество других открытых инструментов, выбирайте любой.
Вот как выглядит процесс DevOps с инструментом CI/CD
У вас в localhost есть инструмент CI/CD, но делать пока особо нечего. Перейдем к следующему шагу.
Шаг 2: управление версиями
Лучший (и, пожалуй, самый простой) способ проверить магию инструмента CI/CD — интегрировать его с инструментом контроля версий (source control management, SCM). Зачем нужен контроль версий? Допустим вы делаете приложение. Вы пишете его на Java, Python, C++, Go, Ruby, JavaScript или на любом другом языке, коих вагон и маленькая тележка. То, что вы пишете, называется исходным кодом. Поначалу, особенно если вы работаете в одиночку, можно сохранять все в локальный каталог. Но когда проект разрастается и к нему присоединяется больше людей, вам нужен способ делиться изменениями в коде, но при этом избежать конфликтов при слияниях изменений. А еще вам нужно как-то восстанавливать предыдущие версии без использования резервных копий и применения метода copy-paste для файлов с кодом.
И тут без SCM никуда. SCM сохраняет код в репозиториях, управляет его версиями и координирует его среди разработчиков.
Инструментов SCM немало, но стандартом де-факто заслуженно стал Git. Я советую использовать именно его, но есть и другие варианты.
Вот как выглядит пайплайн DevOps после добавления SCM.
Инструмент CI/CD может автоматизировать загрузку и выгрузку исходного кода и совместную работу в команде. Неплохо? Но как теперь из этого сделать рабочее приложение, любимое миллиардами пользователей?
Шаг 3: инструмент автоматизации сборки
Все идет как надо. Вы можете выгружать код и фиксировать изменения в системе контроля версий, а также пригласить друзей поработать с вами. Но приложения у вас пока нет. Чтобы это было веб-приложение, его нужно скомпилировать и поместить в пакет для поставки или запустить как исполняемый файл. (Интерпретируемый язык программирования, вроде JavaScript или PHP, компилировать не надо.)
Применяйте инструмент автоматизации сборки. Какой бы инструмент вы ни выбрали, он будет собирать код в нужном формате и автоматизировать очистку, компиляцию, тестирование и поставку. Инструменты сборки бывают разные в зависимости от языка, но обычно используются следующие варианты с открытым кодом.
Превосходно! Теперь вставим файлы конфигурации инструмента автоматизации сборки в систему контроля версий, чтобы инструмент CI/CD их собрал.
Вроде, все нормально. Но куда теперь все это выкатить?
Шаг 4: сервер веб-приложений
Итак, у вас есть запакованный файл, который можно исполнять или выкатывать. Чтобы приложение действительно приносило пользу, у него должен быть какой-то сервис или интерфейс, но вам нужно где-то это все разместить.
Веб-приложение можно разместить на сервере веб-приложений. Сервер приложений обеспечивает среду, где можно исполнить программную логику из пакета, выполнить отрисовку интерфейса и открыть web-сервисы через сокет. Вам нужен HTTP-сервер и несколько других окружений (виртуальная машина, например), чтобы установить сервер приложений. Пока давайте представим, что вы разбираетесь со всем этим в процессе (хотя о контейнерах я расскажу ниже).
Есть несколько открытых серверов веб-приложений.
У нас уже получился почти рабочая цепочка DevOps. Отличная работа!
В принципе, здесь можно остановиться, дальше вы справитесь сами, но стоит еще рассказать о качестве кода.
Шаг 5: Тестовое покрытие
Тестирование отнимает много времени и сил, но лучше сразу найти ошибки и улучшить код, чтобы порадовать конечных пользователей. Для этой цели есть много открытых инструментов, которые не только протестируют код, а еще и посоветуют, как его улучшить. Большинство инструментов CI/CD могут подключаться к этим инструментам и автоматизировать процесс.
Тестирование разделено на две части: фреймворки тестирования, чтобы писать и выполнять тесты, и инструменты с подсказками по повышению качества кода.
Фреймворки тестирования
Инструменты с подсказками по качеству
Большинство этих инструментов и фреймворков написаны для Java, Python и JavaScript, потому что C++ и C# — проприетарные (хотя у GCC открытый исходный код).
Инструменты тестового покрытия мы применили, и теперь пайплайн DevOps должен выглядеть, как на рисунке в начале руководства.
Дополнительные шаги
Контейнеры
Как я уже говорил, сервер приложений можно разместить на виртуальной машине или сервере, но контейнеры более популярны.
Что такое контейнеры? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
Для контейнеров обычно берут Docker и Kubernetes, хотя есть и другие варианты.
Почитайте статьи о Docker и Kubernetes на Opensource.com:
Инструменты автоматизации промежуточного ПО
Наша цепочка DevOps ориентирована на совместную сборку и поставку приложения, но с инструментами DevOps можно делать и другие интересные штуки. Например, использовать инструменты «инфраструктура как код» (IaC), которые еще называются инструментами автоматизации промежуточного ПО. Эти инструменты помогают автоматизировать установку, управление и другие задачи для промежуточного ПО. Например, инструмент автоматизации может брать приложения (сервер веб-приложений, базу данных, инструменты мониторинга) с правильными конфигурациями и выкатывать их на сервер приложений.
Вот несколько вариантов открытых инструментов автоматизации промежуточного ПО:
Подробности в статьях на Opensource.com:
- Руководство по началу работы с Ansible
- Стратегии автоматизации деплоя с Ansible
- 5 лучших инструментов управления конфигурацией
И что теперь?
Это только верхушка айсберга. Цепочка DevOps может гораздо больше. Начните с инструмента CI/CD и узнайте, что еще можно автоматизировать, чтобы упростить себе работу. Не забудьте про открытые инструменты коммуникации для эффективной совместной работы.
Вот еще несколько хороших статей о DevOps для начинающих:
- Что такое DevOps
- 5 навыков DevOps-разработчика
- DevOps для всех
- Введение в прогнозную аналитику в DevOps
А еще можно интегрировать DevOps с открытыми инструментами для agile:
Комментарии (18)
karavan_750
13.05.2019 23:28Очень хочу услышать аргументы за докер для Java.
Понимаю, что это перевод и просьба до автора не дойдет.
Потому приглашаю дать комментарии тех, кто везде твердит "докер это круто", вместо "некоторые вещи хорошо решаются с помощью докера".
gecube
14.05.2019 07:53- Можно тащить несколько версий Явы
- Унификация тестовой и продакшен среды. И среды, где бежит сборка
- Потенциально — возможность поехать в кубернетес, но запаковка в контейнер — это только первый и самый простой (не всегда!) шаг
Shadow0fClown
14.05.2019 10:06А что не так с докером для Java? Собрал jar и запустил spring-boot например.
gecube
14.05.2019 10:08наверное, имеется в виду, что на хосте и так прекрасно уживается 100500 версий джавы и проблема окружения высосана из пальца. А вот настройка джавы для работы в докере (лимиты и прочая дрянь) — вполне себе дополнительная сложность.
karavan_750
14.05.2019 10:37Проблемы в мультиверсионировании нету, это так. И с дополнительными настройками не вижу проблем, один раз сделал и оно работает на каждый билд.
А вот контейнеризация того, что уже по своей сути контейнером является, вызывает у меня взрыв мозга.gecube
14.05.2019 11:14ну, Ваш сервис джавы все равно оборачивать в тот же systemd юнит… Почему бы не обернуть в докер? Или чем Вы их там планируете менеджить?
karavan_750
14.05.2019 13:58systemd ? container
gecube
14.05.2019 14:28Не равно (я и не утверждал, что равно), но часть решаемых ими задач пересекается.
karavan_750
14.05.2019 16:38Верно, пересекаются.
Мне недоступно понимание плюсов/профита от засовывания явы в докер против systemd.ckpunT
14.05.2019 17:44Docker позволяет создать минимальное окружение для запуска вашего приложения. Удобнее выполнить docker build на основании написанного Вами Dockerfile, чем проходить квест с установкой нужной версии Java, дополнительных пакетов определенных версий и т.д. до тех пор, пока Вы не перейдете на новую версию Java и не придется проходить по новой квест. Да и сделав docker-образ больше не придется его билдить, что бы запустить его на другой машине, а просто воспользовавшись docker registry перенести его куда угодно и где бы он не был запущен, он будет работать. Удобнее чем копировать с сервера на сервер все эти вот jar/war-ники.
Собственно для Java самый распространенный вариант запуска в docker-контейнере, это сборка проекта. Я уже даже не вспомню когда последний раз готовил стенды для сборки Java, сейчас только указываю в каком образе выполнить сборку проекта, т.е. стенд стал динамическим и управляется с помощью кода. Т.е. мне как админу разбираться в этих особенностях больше не надо, а это экономит наши с вами время и нервы.
Ну и docker это не просто упаковка приложений и либ в один файл, а инфраструктура позволяющая гибко управлять Вашими приложениями, опять же управляемое кодом.
Ну а дальше идут OpenShift, Kubernetes и т.д., которые на голову обходят сложные и неповоротливые Wildfly и IBM WS, хотя их сравнивать неверно. Но на сегодня я лучше запущу в контейнере в Kubernetes полностью рабочую инфраструктуру за пару часов, чем буду неделю разбираться почему в WildFly не работает одно приложение.
Собственно Ваша позиция только со стороны Dev, что творится в Ops Вам безразлично, как следствие не щупали Вы DevOps как следует.
Попробуйте с помощью systemd быстро мигрировать Ваше приложение вместе с БД на другой кластер и попробуйте это же сделать с помощью docker swarm в связке с consul и confd, например. Которые так же можно развернуть в docker (да, и docker можно запустить в docker, называется dind).
Ну а разработкой заниматься с помощью docker одно удовольствие, так что docker-compose Вам в помощь.
Вариантов использования docker очень много. Попробуйте, Вам понравится.
ProFfeSsoRr
15.05.2019 07:22Да, в Java сделано все то, что контейнеры сотоварищи сделали для всех остальных ЯП. Поэтому Java в контейнеры пихают в основном для унификации процесса со всем остальным. Но если у вас в компании на Java всё — действительно, контейнеры типа Docker вам незачем.
baruk
15.05.2019 08:16Как Amazon, Google и Netflix успевают столько выкатывать? А все просто: они поняли, как создать почти идеальную цепочку DevOps.
И нигде не написано, зачем они столько раз выкатывают.
Вот бы глянуть список решенных задач того же Амазона хотя бы за 1 час, а то пока это больше похоже на «у кого больше?»
А по сути статьи… Это как гвозди микроскопом забивать. У людей процессы разработки не выстроены были, а они сразу в devOps. По пути процессы выстроили, счастье наступило, но так и не поняли, что счастье наступило от процессов, а не от devops'a, который под их проблемы, в общем-то, нафиг не был нуженgecube
15.05.2019 10:16И нигде не написано, зачем они столько раз выкатывают.
очень просто. Они ставят A/B эксперименты. Причем, когда у тебя посещаемость сайта 1 млн пользователей, то ты можешь эти эксперименты ставить по 10 штук на дню. Был доклад от Яндекса, как они это делают… habr.com/ru/company/yandex/blog/342704
По пути процессы выстроили, счастье наступило, но так и не поняли, что счастье наступило от процессов, а не от devops'a, который под их проблемы, в общем-то, нафиг не был нужен
примерно, но девопс — он про процессы, в общем-то, а не про технологии.baruk
15.05.2019 11:10очень просто. Они ставят A/B эксперименты. Причем, когда у тебя посещаемость сайта 1 млн пользователей, то ты можешь эти эксперименты ставить по 10 штук на дню.
10, да пусть при их объеме даже 1000 экспериментов. Но 23 тысячи это все равно за гранью, как мне кажется.
девопс — он про процессы, в общем-то, а не про технологии
А потом заходим на условный hh и видим, что уже давно идет смысловая миграция и большинству нужны именно технологии, а не процессы. А «Однако, исследование, выпущенное в январе 2017 года компанией „F5 Labs“, на основе опроса почти 2200 ИТ-руководителей и специалистов отрасли, показало, что только один из пяти опрошенных полагает, что DevOps оказывает стратегическое влияние на их организацию, несмотря на рост использования.» вообще удручает, поскольку косвенно показывает, что большинство внедряли его просто потому что модно, а не для решения каких-то проблем. Вангую, что у них внедрен такой же DevOps, как у эффективных менеджеров Agile
Singaporian
16.05.2019 22:51И нигде не написано, зачем они столько раз выкатывают.
Это не сразу понятно, потому что термин Сontinuous Integration был девальвирован.
Но вот как раз здесь вы видите настоящий continuous в его оригинальном значении на английском языке — «непрерывный».
Нет никаких агрегаций фич/багфиксов в версию. Нет простоев на тестирование.
Все вытекает из под пера художника сразу в продакшен.
Continuous!
MMik
Вместо обещанного процесса «создания цепочек DevOps с помощью инструментов с открытым исходным кодом» увидел картинки, картинки с табличками со списком продуктов, и мало что поясняющий текст. Зато тегов много.
gecube
Да, я тоже в бешенстве от табличек в виде картинок. Хотел прокликать по интересным продуктам по ссылкам… А тут облом!