Как стать DevOps инженером за полгода или даже быстрее. Часть 5. Развертывание

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.
Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование
Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии
Как стать DevOps инженером за полгода или даже быстрее. Часть 4. Пакетирование программ



Освежим память


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



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

Развертывание кода


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

Минимизация этих различий – самое лучшее, что вы можете сделать не только в процессе развертывании кода, но и во время его выполнения после развертывания. Итак, как же нам уменьшить и / или устранить различия между нашим prod- и non-prod окружением?

А на моей машине это работает!


Если ваша dev-инфраструктура выглядит так:



А prod-инфраструктура так:



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

Суть в том, что вы не добьетесь успеха в управлении современным технологическим стеком, если вы все еще настраиваете вещи вручную. Это аксиома. Первое, что вам нужно сделать, это убедиться, что все, что касается prod, является версионным артефактом, развернутым вашим сервером развертывания.

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

Современный подход к развертыванию кода


Верно то, что развертывание кода на машинах – это отголосок 1990-х. Самая большая проблема при развертывании кода на набор производственных машин заключается в том, что по определению ваши prod-серверы (на которых выполняется код) отличаются от ваших dev-серверов (где этот код пишется). Неудивительно, что сразу после развертывания возникает масса проблем, которые раньше никогда не замечались, ведь сейчас условия поменялись!

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



Это называется «неизменяемым развертыванием» и является очень мощным шаблоном, который избавит вас от многих часов головной боли после развертывания. Конечно, если вы запускаете контейнеры, применяется та же идея: вы везде развертываете один и тот же контейнер. Вы можете сказать: «стоп! Мой prod отличается от dev!”, и это будет правильно, ведь имена пользователей базы данных / пароли, строки соединения, местоположения корзины S3 — это все разные вещи! Да, они вещи очень разнятся.

Способ решить эту проблему заключается в использовании принципа 12 factor app config. Приложение двенадцати факторов хранит конфигурацию в переменных окружения env vars, или env. Переменные окружения легко изменить между развёртываниями, не изменяя код. В отличие от файлов конфигурации, существует меньшая вероятность случайно сохранить их в репозиторий кода, и в отличие от пользовательских конфигурационных файлов или других механизмов конфигурации, таких как Java System Properties, они являются стандартом, независимым от языка и операционной системы. Таким образом, вся ваша конфигурация должна быть экстернализирована и передана в качестве переменных среды на ваш компьютер.

Например, если вы находитесь в AWS, используйте SSM в качестве внешнего хранилища параметров — он прекрасно интегрируется с CloudFormation. Кроме того, очень легко установить переменные окружения непосредственно из команд AWS ssm cli. Конечно, другие облачные провайдеры имеют аналогичные механизмы.

Кроме того, сопротивляйтесь желанию «починить» свои машины prod, когда что-то пойдет не так. Машины должны быть неизменными, и это означает, что все исправления, которые вы делаете, должны исходить от dev. Ваша цель должна заключаться в том, чтобы вообще не допустить доступа к машинам prod. Ни ssh, ни scp, ни prod доступа – никогда и никому, ни самому себе, ни начинающим хакерам.

Но что делать, если мне нужны логи для устранения проблемы? Вы уже догадались — ваши журналы также должны быть экстернализированы, в идеале отправлены в другое место либо с помощью стека ElasticSearch/Logstash/Kibana (ELK), либо с помощью коммерческого программного обеспечения, такого как SumoLogic или Datadog.

Что бы вы ни делали, ваши prod-машины – это «рабочая скотина», которая заменяется при малейшем признаке нездоровья. Они не являются «домашними животными», которых нужно выхаживать, чтобы вылечить, тратя часы на устранение неполадок.

Я знаю, что эта аналогия используется слишком часто, и слышу от людей, которые действительно заботятся о скоте, что это не совсем так, но суть та же самая — не «чините» свои prod-машины, просто исправьте свою разработку и повторно ее разверните.

Механика развертывания кода


Итак, вы знаете, что делать, но не знаете, как. К сожалению, именно здесь появляется Дженкинс. Если вы не знаете, то Jenkins — это один из самых популярных серверов автоматизации развертывания с открытым исходным кодом.



Я говорю «к сожалению», потому что Jenkins (и его предшественник Hudson) окружали нас почти десять лет, и это заметно. Он сложен в настройке и еще более сложен в обслуживании. Он поставляется с миллионами плагинов сомнительного качества. Эти плагины, как правило, ломаются в самое неподходящее время, обваливая за собой все остальное. На самом деле, по-настоящему устойчивые, мастерские установки Дженкинса встречаются редко и обычно наблюдаются только в самых крупных организациях.

Почему же я рекомендую вам начать с Дженкинса? Потому что, несмотря на все свои недостатки, он все еще чрезвычайно популярен и широко используется в ИТ сфере. Знание Дженкинса, в частности того, как структурирован Jenkinsfile, является огромным преимуществом для перспектив трудоустройства и не может быть упущено из виду. При изучении Jenkins убедитесь, что вы взялись за новый плагин Pipeline BlueOcean, а не за устаревший конвейер Jenkins jobs. Это критически важно, если вы хотите, чтобы ваш конвейер CI/CD жил прямо внутри вашего кода GitHub/GitLab repo. Таким образом, сам конвейер — это версионный фрагмент кода!



На самом деле это настолько важно, что стоит повторить еще раз: все является кодом! Ваше приложение, то, как оно развернуто, как оно отслеживается, как оно настроено и т. д. – это все надлежащим образом версируемые фрагменты кода, хранящиеся в GitHub/GitLab/Где-угодно. Цель этого — создать свободную от нестыковок среду для основных разработчиков (инженеров-программистов, которые пишут функциональный код).

Например, я должен быть в состоянии:

  • написать свой маленький микросервис;
  • добавить любые тесты, которые я считаю необходимыми;
  • добавить файл Jenkinsfile;
  • добавить конфигурацию monitoring-as-code;
  • указать мои параметры в файле env.yaml;
  • сохранить все это в одном репозитории;
  • заставить Jenkins автоматически обнаружить указанный репозиторий;
  • построить свой микросервис;
  • протестировать его;
  • развернуть (методом Canary или Blue-Green);
  • организовать отправку сообщения на свой e-mail, когда это будет сделано!

Это и есть цель, в достижении которой заключается суть основной миссии инженеров DevOps.

Альтернативы Дженкинсу


Как я уже говорил ранее, Jenkins существует уже целую вечность, и на сегодня есть другие, на мой взгляд, лучшие, хотя и менее популярные альтернативы. Одна из них это сервис CodeDeploy от AWS. У него есть ограничения, но разработчики сделали значительные улучшения за последний год, и если вы работаете в AWS, я настоятельно призываю вас попробовать CodeDeploy.

Вторая альтернатива – это модуль непрерывной интеграции GitLab CI. Если ваша организация работает под управлением GitLab, вы, вероятно, должны начать работать именно с ним, так как он довольно аккуратно интегрирован с остальной частью GitLab.

Наконец, GitHub анонсировал собственный инструмент для развертывания приложений Actions, который поддерживается их собственной автоматизацией.

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

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

Продолжение будет совсем скоро…

Немного рекламы :)


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Источник: https://habr.com/ru/company/ua-hosting/blog/502834/


Интересные статьи

Интересные статьи

В последние полгода удалось поработать над большим и интересным проектом, в котором было все: от монтажа оборудования до создания единого VXLAN/EVPN домена в 4-х ЦОД. Т.к. было получено м...
«— Скажите, пожалуйста, куда мне отсюда идти? — А куда ты хочешь попасть? — ответил Кот. — Мне все равно… — сказала Алиса. — Тогда все равно, куда и идти, — заметил Кот.» (С) «Алиса в стране ...
Первый прототип объектных хранилищ мир увидел в 1996 году. Через 10 лет Amazon Web Services запустит Amazon S3, и мир начнёт планомерно сходить с ума от плоского адресного пространства. Благодаря...
Прежде чем начать урок, хочу сказать, что на нашем сайте теперь действует система баллов My Points. Заработанные баллы можно потратить на оплату заказов в нашем онлайн-магазине. Баллы можно зараб...
И снова здравствуйте. Это продолжение статьи про организацию студенческого хакатона. В этот раз расскажу про проблемы появляющиеся прямо во время хакатона и как мы их решали, локальные ивенты ко...