Перевод книги DevOps Toolkit 2.0: Глава 1. Идеальный devops
Идеальный DevOps
Работать над небольшим проектом это восхитительно. Последний раз со мной такое было летом 2015 года, и хоть на проекте было много проблем, я испытывал удовольствие от работы, мы могли выбирать технологии, практики и фреймворки.
Будем использовать микросервисы?
Конечно!
Попробуем Polymer и Golang?
Естественно!
Чувствовать свободу - это прекрасное чувство! Мы создавали продукт заново, и неправильное решение конечно могло отбросить нас на несколько недели назад, но это бы не перечеркнуло бы годы работы. Проще говоря, за спиной не было устаревшей системы, о целостности и работоспособности, которых надо бы было бы думать и волноваться.
Мой предыдущий рабочий опыт, конечно, был совсем другим. Я работал с проектами, в которых уже было ряд исторически сложившихся систем, с одной стороны это была и благодать, и проклятье. Компании, которые существовали задолго того, как я присоединился. При работе с такими проектами, я должен был соблюдать баланс между инновациями и стабильностью существующих систем. Все эти годы я пытался улучшать и изменить такие системы. Как не печально это признавать, не всегда я выходил победителем из этой битвы.
В этой книги мы будем рассматривать и обсуждать такие неудачи, как неудачи могут мотивировать, и перерасти в победы и принести пользу.
Непрерывные интеграции, поставка, и развертывание
Открытие для себя непрерывной интеграции(CI), а позднее непрерывной доставки (CD) пожалуй, было поворотным событием в моей карьере. Весь мой тетанический труд по внедрению непрерывных интеграций имел смысл, в то время интеграции могли занять дни, недели или даже месяцы и это было настоящим адом на земле. Данте по всей видимости написал свое произведение “Инферно”” именно про интеграции, только представьте несколько команд, работают над приложениями или службами несколько месяцев, и наступает день Х, первый день интеграции, когда все системы собираются воедино и их пытаются заставить работать вместе и этот день мы все по-настоящему боялись.
В День ИКС мы все пришли в офис с хмурыми лицами, было так тихо, что можно было слышать шепоты и как гром среди ясного неба прозвучала фраза инженера: “Игра началась”. Он собрал финальную системы и результат не заставил себя ждать - белая страница. Месяца работы в изолированных средах, обернулись катастрофой для нас и для приложения. Наш продукт просто не интегрировался в среду, теперь нам предстояло переделать недели работы, хотя проблем не было ни на одной стадии до этого, но интеграция беспощадна и расставила все на свои места.
Потом конечно появилась экстремальное программирование и вместе с ней пришла практика Непрерывной интеграции(ci). Сама идея непрерывных интеграций сейчас звучит как нечто очевидное и как естественный процесс разработки. Еще бы! Конечно вы не должны ждать до последнего чтобы узнать о проблемах, но в эпоху Каскадной методологии эта прописная истина, не была на столько очевидной. Наша идея была внедрить непрерывные интеграции и наш конвейер должен был работать на всех стадиях, таких как: проверять каждое изменение в системе контроля версий, запускать статическую проверку кода, функциональные и модульные тесты, сборку, и распространение на среды и то чего нам не хватало, интеграционные тесты. И если хотя бы одна из фаз терпела неудачу, мы отправлялись искать и исправлять проблему, мы могли расставить приоритеты по исправлению ошибок. Наш новый подход был на столько быстр, что после любого изменения, мы уже через несколько минут знали, если что-то пошло не так и у нас где-то вкралась ошибка. Позже настало время непрерывной поставки(CD), мы могли с уверенностью сказать, что каждое изменение, которое успешно прошло все этапы, может быть развернута в продуктивной среде без какого-либо внешнего вмешательства и что самое замечательное этот процесс был полностью автоматизирован.
Ах, если бы мечта сбыла. Серьезно! Если бы….но это была места, которой не суждено было стать явью. Спросите, почему? Мы ошиблись, мы ошиблись в том, что думали что CI/CD процессы это задачи только для отдела Системного администрирования. Мы думали что все готово, готовы инструменты и фреймворки, архитектура, тестирование и многие другие задачи и это не наша забота. Мы ошибались, я ошибался!
Теперь то я знаю, успешное внедрение CI/CD процесса это не краеугольный камень, при внедрении необходимо заботиться обо всех процессах от архитектуры до тестирования, разработки и эксплуатации и даже до ожиданий от бизнеса, но вернемся к истокам. Так что же пошло не так?
Архитектура
Пытаться ужиться с монолитным приложением, которое разрабатывают долгие годы, многими людьми,без тестов,с жесткими зависимостями и устаревшими технологиями, это так же нелепо как молодящая старуха. С помощью пластических операций, мы можем улучшить внешний вид, но старуха останется старухой, и никак не молодой девушкой. Конечно усилия по “омоложению” не всегда целесобразны, только представьте, что я пришел к клиенту, скажем в банк, со словами: “Мы перепишем всю вашу систему”. Риски слишком высоки, чтобы переделать все с нуля, как бы то ни было, лучше оставить, систему как есть, со своими зависимостями, устаревшими технологиями, игра не стоит свечь. Обычный подход в таких ситуациях был разработка новой системы и параллельная поддержка уже существующей. И обычно, это все заканчивалось полной и бесповоротной катастройфой, такой проект мог затянуться на годы и думаю вы понимаете, что может произойти с такими долгоидущими планами. И это даже не Каскадная модель, это все равно что, упасть на дно водопада и удивляться, почему это я вымок! В таких проектах, даже не значительные изменения, к примеру обновление версии JDK до последней версии, это уже была победа! Это наверное тот случай, когда меня можно было назвать удачным! А что делать например с исходными кодами напасаными на Фортране или Кобол?
Однажды я услышал про микросервисы и как мне казалось это было моим спасением. Идея, что мы можем создавать небольшие независимые сервисы, которые могли поддерживать небольшие команды, использовать исходый код, который возможно быстро понять, легко изменить структуру, язык разработки или даже базу данных, и не влиять на работоспособность остальной системы, и самое главное иметь возможность развернуть приложение независимо от других, это звучало слишком хорошо, чтобы было правдой. Мы могли начать работать с частью монолитного приложения без рисков повлиять на все приложение целиком. Это звучало слишком хорошо, чтобы быть првдой и это было так, но были и недостатки. Распространение и поддержка огромного количества сервисов, оказалось не подъемной задачей, нам пришлось стандартизировать сервисы, использовать общие библиотеки и распространять группами и это все свело на нет выгоду от использования микросервисов. Я молчу по конфигурацию и хаосе, который был. Этот период моей карьеры, который я пытаюсь забыть, как страшный сон. И так было множество проблем с монолитными приложения, микросервисы их только приумножили, назыайте меня извращенцем, но я был не готов сдаться и тогда я столкнулся со следующей проблемой - развертывание
Развертывание
Конечно, вы знаете процесс. Собираете “артефакты” это может быть jar,war или чего-то другого, далее копируете на сервер, который уже имеет не эталонную конфигурацию…..я даже не могу продолжить свою мысль, бывали такие случаи, что мы не знали и не могли знать, что уже было на серверах. С течением времени любой сервер обслуживаемый вручную начинает “обрастает” библиотеками, остатками от программ, и многое другое, такие сервера рано или поздно становятся сложны в поддержке. Единственное, что объединяет такие сервера, то что они абсолютно разные, и никто не сможет дать гарантии, что программное обеспечение, которое успешно этап тестирования будет себя одинаково вести при развертывании в производственной среде, на таких серверах. Каждый раз это лотерея и Вам, конечно, может повести, а может и нет, но надежда умирает последней.
Вы, конечно, можете удивляться, почему мы не использовали виртуальные машины? Есть два ответа на это почему. Во-первых, это зависило напряму от “тех дней”, в те дни у нас не было виртуальных машин, либо они были они были настолько новые, что менеджмент боялся их использовать. Другой ответ, мы начали использовать виртуальные машины позже, и это стало реальным улучшением! Теперь мы могли скопироуать производственную среду и использовать ее скажем как среду для разработки или тестирования, теперь мы могли обновлять конфигурации, управлять сетями и многие другие вещи, правда мы до сих пор не знали и не представляли, что могло накопиться на этих машинах в течении времени, мы просто брали и копировали их. Конечно это не решало проблему с неоднородностью конфигураций, однородность копии и оригинала, была всего лишь до тех пор пока кто-либо не изменит конфигурацию, различия копятся и копятся тогда, когда у вас ручная настройка и нет автоматизации, как снежный ком проблемы будут наростать, и если в то время у нас была бы автоматизация мы бы никогда не пошли по пути накапливания различий в средах. Вместо этого, мы бы создавали новою виртуальную машину как часть нашего конвеера. И так вместо того чтобы собирать артифакты, мы начали создавать новые сервера с нуля, на каждый релиз создавался сервер, на него него устанавливалось все необходимое, тестировалось, затем переключался траффик с продуктивной систем. Это было неплохое решение, заисключением того, что оно было медленным и требовательным к ресурсам. Конечно деражть под каждый сервис отдельнуб виртуальную машину это излишнее, вооружившись временем и терпением, мы использовали этот подход, хотя и инструменты у нас были плохи.
Orchestration
Главной задачей, оставалась оркестрация. Chef и Puppet нам оказали огромную услугу, программируй конфигурацию сервера, и процесс развертывания было просто прорыв, мало того, что у нас сократилось время развертывания серверов, теперь мы могли построить более надежный процесс, нежели целый отдел, который вручную настраивал и обслуживал среды. Ну что наконец-то счастливый конец? А вот и нет! Вы, наверное, уже заметили закономерность, как только мы достигаем одного улучшения, выясняется, что цена слишком велика. Учитывая потраченное на сценарии и конфигурацию chef или puppet все это превращается в кучу *****(автора просили не ругаться, так что заполните звездочки на свое усмотрение), поддержка обычно становиться кошмаром и так везде, тем не менее, с инструментами оркестрации мы значительно сократили время по созданию и конфигурации виртуальных серверов. это было лучше, чем ничего.
Свет в конце Pipeline
Я конечно могу продолжать плакаться и рассказывать о проблемах с которыми мы столкнулись, но не поймите меня не правильно. Все эти улучшения и изменения занимают свое место в истории. Но история - это прошлое, а надо жить настоящим и поглядывать в будущее. Многие, если не все проблемы, с которыми мы сталкивались раньше, сейчас уже решены. Ansible показал, что управление серверами и конфигурация может быть простой для настройки и поддержания в будущем, с появлением docker, виртуальные машины постепенно уходят в прошлое, как более простой способ развертывания приложений. Инструменты по обнаружению сервисов это уже новые горизонты, а Swarm, KubernetesandMesos/DCOS открывают нам дверь в неведанные дали, о которых несколько лет назад можно было только мечтать.
Microservices постепенно становятся способом по умолчанию и лучшими практиками по созданию больших, простых в обслуживании и масштабируемых систем благодаря инструментам, таким как Docker, CoreOS, etcd, Consul, Fleet, Mesos, Rocket и многие другие. Идеи у нас были великие, но не было инструментов, чтобы наши идеи работали правильно. Конечно это не значит что теперь проблем нет совсем, это означает что планка стала намного выше, чем несколько лет назад.
Я начал с жалом и рассказов как это было тяжело, но такого больше не повториться. Прежде всего эта книга предназначена для тех, кто не хочет жить прошлым, эта книга про подготовку к будущему, это книга про то как посмотреть под другим углом и заглянуть в те места, где вы не были.
– Morpheus (Matrix)