Связаться по Skype: vkarabedyants
Позвонить Написать
+7 (499) 404-28-83

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

Поговорим о девопс без трэша

Поговорим о девопс

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

Введение в DevOps.

Начнем с того, что же это такое. DevOps сейчас интерпретируют по-разному. Кто-то расценивает это как человека, кто-то как технологию. На самом деле однозначного определения нет. По одному из определений DevOps (слияние англ. слов Development (разработка) и Operations (ИТ-операции)) – это новая методология разработки ПО. Она сосредоточена на коммуникации, сотрудничестве и интеграции между подразделениями разработки и эксплуатации.

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

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

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

Поступает новый проект, ставятся задачи  в этом проекте, отдел разработки начинает писать код, отдел тестирования — тестировать, системные администраторы настраивают различные окружения тестовые среды, девелопмент и продакшн окружения, устанавливают новые версии приложения.  И, о ура!, все заработало!, но часто не так, как ожидалось…

DevOpsКаковы проблемы такого подхода

  1. Проблемы взаимодействия
  2. Проблемы качественного поиска багов
  3. Проблемы устранения багов из продакшн версии
  4. Проблемы развертывания идентичных сред программного окружения и установки разрабатываемого продукта  в эти среды
  5. Проблемы качества кода

DevOps зародился в 2009 году на пересечении развития идей и подходов CaaS, методов Aglie, продуктивности непрерывной интеграции, доступности облачных и PaaS технологий.

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

Принципы DevOps

  • Целостность и производительность системы превыше всего. Хорошо система работает только тогда, когда все узлы качественно взаимодействуют между собой.
  • Обратная связь – важный элемент взаимодействия для дальнейшего совершенствования.
  • Соблюдение баланса между экспериментированием с осознанными рисками и получением навыков путем повторений проверенных действий.

принципы devops

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

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

непрерывная интеграция

С  точки зрения DevOps это выглядит следующим образом:

В первую очередь все начинается с запуска репозитория. Это может быть сторонний сервис, который покупается за деньги: тот же Bitbucket или GitHub. Также это может быть личный репозитарий, развернутый на своем оборудовании на основе GitLab или SVN для совместной разработки. После того, как все настроено, разработчики  уже могут заниматься написанием проекта, загружать его из какого либо репозитария. Для автоматической сборки проекта и развертывании его на серверах необходимо устанавливать уже другое ПО, которое называется Continious Integration и Continious Delivery. Основные представители такого ПО: Jenkins, Bamboo TeamSity. Но TeamSity более ориентирован на развертывание Windows приложений на основе ASP.NET  и прочих инструментов разработки под эту ОС. Вся суть этих приложений заключается в том, что они могут выполнять определенную последовательность команд на серверах, которые занимаются сборкой приложений. Таким образом, есть само приложение, Jenkins или TeamCity или Bamboo, а у него уже подчиненные сборщики, на которых выполняется сборка непосредственно проекта. Настраивая ПО для Continious Integration мы указываем последовательность действий: пишем скрипт, в котором будет проходить сборка проекта, то есть его компиляция, и, если первый шаг прошел без ошибок, то далее — его автоматическое тестирование. После успешного завершения  выполнения скрипта создаваемый продукт готов к запуску на серверах.

После того, как приложение скомпилировано, его запуск разделяется на несколько шагов, которые компания сама для себя определила. Это может быть альфа ветка, бета ветка, гамма и так далее вплоть до продакшена. То есть на каждой ветке выполняется какое-то определенное тестирование, каждая ветка может иметь ответвления в том же репозитории, в которые будут уже потом по ходу дела вноситься правки. То есть, например, вся разработка идет в альфа ветке репозитория и собирается в альфа таске Jenkins или TeamCity или Bamboo. После того, как убедились, что все работает – изменения вносятся в бета ветку, потом собирается в бета тасках, ну и так далее до продакшен релиза.  По поводу деплоя приложения – это делается точно так же на уровне заданий Jenkins или Bamboo. Опять же пишется определенный скрипт, который выполняет последовательность команд, но только уже не на узле сборщика, а на самом севере, где должно быть запущено приложение. Он выполняет определенные задания:

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

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

CI CD

Также приложения CI&CD могут интегрироваться с другими системами, например JIRA, в которой можно отсылать уведомления о процессе сборки. То есть в зависимости от того, как прошла сборка (то есть была ли это удачная или неудачная сборка), могут создаваться определенные задачи с определенными текстовками, назначаться на определенных людей. Такие комплексные решения используются, чтобы автоматизировать процесс разработки и оперативно устранять проблемы во время сборки проекта.

Примеры.

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

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

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

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

Рассмотрим пример архитектуры с использованием DevOps и средств автоматизации разработки на основе облачной среды Amazon:

amazon devops

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

Проекты на основе виртуальной инфраструктуры

  1. Linux, VMware, Jenkins

В основе архитектуры решения лежит виртуализация средствами VMware vSphere. Виртуальная инфраструктура может быть реализована в виде кластера, так и в виде отдельных серверов. Минимальная конфигурация для кластера — 3 физических сервера и общая система хранения данных, если инфраструктура не предполагает использование отказоустойчивого кластера, то для минимального начального уровня будет достаточно 1 сервера, с внутренними дисками в качестве хранилища виртуальных машин. В программной основе этого решения используется ОС enterprise класса — CentOS 7. Это позволяет обеспечить должный уровень безопасности и своевременное устранение уязвимостей.

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

  • Централизованное обновление серверов
  • Централизованное управление пользователями
  • Развертывание серверов из шаблона

В качестве ПО для Continuous Integration, или для краткости CI, в этом решении используется Jenkins. Jenkins — open source проект, который не уступает платным решениям, а в чем-то и превосходит их. Он имеет огромное количество плагинов, которые позволяют расширять его функционал. Если объединить Jenkins и Ansible мы получим в итоге мощное средство CI/CD.

  1. Linux, Amazon, Jenkins

Решение базируется на основе среды виртуализации от Amazon. Для запуска виртуальных машин используется сервис EC2. На его основе разворачиваются все необходимые сервисы, в том числе и Jenkins. Jenkins используется в качестве CI решения.

Также возможны другие варианты, например:

  1. Linux, Docker, Jenkins
  2. Windows, Hyper-V, Teamcity
  3. Windows, Azure, Teamcity

Ценность DevOpsпреимущества devops

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

Наша команда профессиональных администраторов, уже несколько лет практикует DevOPS и успешно внедряет и поддерживает различные решения, по вопросам сотрудничества обращайтесь office@system-admins.ru

1 Response

  1. Evgenii

    TeamCity, а не TeamSity и никакого прямого отношения к Windows он не имеет

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.