задеплоить что это значит
Heroku и React: деплоим свое первое приложение
Всем привет. Вместе с весной в OTUS пришли новые курсы, знакомить с которыми мы начинаем прямо сегодня. Уже сейчас открыт набор на курс «React.js разработчик». Подробнее о курсе можно узнать на бесплатном вебинаре, который пройдет 11 марта. В рамках этого же вебинара будет разработано небольшое веб-приложение на ReactJS.
А сейчас предлагаем вам прочитать статью о деплое своего первого приложения, которую написал наш внештатный автор.
Стартовый шаблон Create-react-app и Heroku — это прекрасные инструменты для быстрого создания работающих в облаке приложений, однако документация React и Heroku включает в себя на удивление немного информации о том, как все-таки выкатить свое React-приложение на Heroku. Описанные в этой статье шаги сработают на любом проекте, созданном с помощью create-react-app. В нашей статье мы задеплоим на Heroku простое todo-приложение с самым минимальным бекэндом, просто чтобы посмотреть на сам процесс. Но обо всем по порядку:
Что такое вообще Heroku? Зачем он мне нужен?
Heroku — это облачная платформа как услуга (PaaS), которая поддерживает множество языков программирования (и этим она очень хвастается и выделяется). История Heroku началась в 2007, и тогда первым языком программирования был Ruby. Теперь она поддерживает Java, Node.js, Scala, Clojure, Python, PHP и Go.
А зачем мне это облако? Я вот могу хостинг недорогой купить
Да, вы можете купить себе любой хостинг и установить туда Node.js сервер, если на хостинге поддерживается эта услуга. Однако облачные платформы обладают такими качествами, как, например, эластичность и учет потребления — если на ваш сервис заходит очень много пользователей, тогда платформа скорее всего автоматически (или вы сами с помощью предоставленных платформой инструментов) отмасштабирует или сузит поток. Учет потребления означает, что вы заплатите только за те ресурсы, которые оказались востребованы. Облачные платформы имеют еще множество преимуществ, с полным списком можно ознакомиться здесь. Ну а мы перейдем непосредственно к деплою.
Создание своего React приложения
Что это вообще за шаблон create-react-app? Хоть немного заниматься разработкой React приложений и не знать про него, наверное, невозможно. Этот шаблон предоставляет React, React-dom, Webpack, ESLint «под капотом». Конечно, вы можете сами собрать свое React — приложение, но зачем плодить себе сложное приложение с кучей зависимостей, когда можно воспользоваться уже готовым велосипедом?
Для начала практических шагов убедитесь, что у вас установлена Node.js.
Что бы создать новое приложение, введите в консоль следующие команды:
Можете поставить это приложение себе и развернуть его при помощи:
Дальше у нас есть невероятная возможность поиграться и создавать свои дела. Однако все возможности, которые есть в данном приложении — это сохранять дела в state. Никакой подвязки к серверу или хотя бы к localStorage я не делал, цель этой статьи состоит не в этом. Предположим, что я очень сильно параноик и свои дела буду записывать только за одно включение вкладки браузера.
Создание своего favicon
Зачем нам вообще нужен Node.js сервер, если никакой работы с БД не проводится? С помощью сервера мы будем отдавать favicon и весь остальный код. В нашем React-приложении заходим в папку public и удаляем оттуда шаблонный favicon.ico. Я возьму иконку отсюда и перенесу ее в папку public.
Создаем свой Express-сервер
Пишем в нем следующее:
Так как мы используем пакеты express, express-favicon и path, их нужно проинсталлировать:
В package.json изменяем команду start на следующую:
Запускаем build
Дальше нам нужно забилдить приложение с помощью следующей команды:
Неплохо было бы потестировать, что наше приложение работает корректно. Для этого набираем yarn start и оцениваем, насколько корректно оно работает.
Скрываем sourcemap
Непосредственно деплой
Потом вводим имя вашего приложения. В моем случае это будет todoisakura313, потому что использовать спецсимволы и нижние подчеркивания в имени приложения нельзя:
Потом мы отправим наш билд с помощью следующих команд:
На этом все! Спасибо за внимание. С работающим приложением можно ознакомиться здесь, а с его готовым кодом — здесь.
А тех, кто дочитал до конца, мы приглашаем на еще один бесплатный вебинар, в рамках которого Вы узнаете сильные и слабые стороны самых популярных JS-фреймворков для Frontend-разработки, поймете для каких задач какой из фреймворков лучше подойдет и сможете определиться, что лучше изучать.
Задеплоить что это значит
3 года назад 20559 9
Что такое деплой
Основная цель
Тестовое приложение
Начнем с тестового приложения. Создадим проект на laravel и добавим простой роут, выводящий номер версии.
Далее открываем routes/web.php и пишем следующее:
В resources/views/welcome.blade.php добавляем вывод нашей версии:
Создаем git-репозиторий и пушим туда код нашего демо проекта.
Подготовка сервера
Теперь перейдем к подготовке нашего сервера. Установку зависимостей приложения, таких как сам PHP, composer я опущу и остановлю только внимание на важных моментах, а именно создание пользователя для deployer’а, настройка прав доступа для него, а также настройка nginx.
Итак, у меня есть сервер под управлением ubuntu server 16.04 и root-доступ к нему. Я создам пользователя deployer, дам ему sudo-привилегии, настрою ему доступ к серверу по ssh-ключу.
Создаем пользователя, система попросит ввести для него пароль:
Даем пользователю sudo доступ:
Добавляем пользователя в группу www-data:
Создаем директорию для нашего проекта и выставляем права доступа:
Скопируем вывод и на сервере вставим в
Также нужно позаботиться о том, чтобы наш сервер имел возможность клонировать наш репозиторий если он приватный. Для этого будучи залогиненым на сервере как deployer нужно сгенерировать ssh ключ и добавить его публичную часть в deploy keys нашего репозитория.
И вставляем в этот файл следующую строку:
Это позволит пользователю deployer выполнять sudo systemctl restart php7.2-fpm.service без ввода пароля.
Теперь сервер готов к деплою нашего приложения. Перейдем к настройке самого deployer’а.
Настройка deployer’а
На нашей локальной машине устанавливаем deployer:
В папке нашего демо-проекта инициализируем конфиг deployer’а:
Некоторые директории должны иметь права доступа на запись, для этого их нужно добавить в writable_dirs :
При такой конфигурации delployer будет использовать ваш дефолтный ssh ключ и настройки агента. Но доступна и более тонкая настройка, подробнее можно почитать в документации.
Заметьте что artisan:migrate закомментирован, так как наш демо проект не использует базу данных. В результате наш deploy.php имеет следующий вид:
Деплоим!
Можно деплоить. В корне нашего проекта выполняем простую команду:
Проверяем наш задеплоенный код на сервере:
Мы видим что весь код доставлен, зависимости установлены, символьные ссылки добавлены. Все впорядке. Осталось настроить nginx, используем следующий минимальный конфиг:
Теперь сделаем контрольный выстрел. Внесем изменения в код, закоммитим их и попробуем задеплоить чтобы окончательно убедиться что все работает корректно.
Открываем routes/web.php и меняем версию на другую:
Делаем ккоммит и пушим в репозиторий. Деплоим:
Открываем в браузере http://deployer-demo.local/ и видим что версия изменилась на 2. Значит все работает корректно.
Все действия описанные в статье производились на ubuntu 16.04.
Деплой приложений в VM, Nomad и Kubernetes
Всем привет! Меня зовут Павел Агалецкий. Я работаю тимлидом в команде, которая разрабатывает систему доставки Lamoda. В 2018 году я выступал на конференции HighLoad++, а сегодня хочу представить расшифровку своего доклада.
Моя тема посвящена опыту нашей компании по деплою систем и сервисов в разные среды. Начиная от наших доисторических времен, когда мы деплоили все системы в обычные виртуальные сервера, заканчивая постепенным переход от Nomad к деплою в Kubernetes. Расскажу о том, почему мы это сделали и какие у нас были в процессе проблемы.
Деплой приложений на VM
Начнем с того, что 3 года назад все системы и сервисы компании деплоились на обычные виртуальные сервера. Технически было организовано так, что весь код наших систем лежал и собирался за счет средств автоматической сборки, с помощью jenkins. При помощи Ansible он из нашей системы контроля версий раскатывался уже на виртуальные сервера. При этом каждая система, которая была в нашей компании, деплоилась, как минимум, на 2 сервера: одна из них — на head, вторая — на tail. Эти две системы были абсолютно идентичны между собой по всем своим настройкам, мощности, конфигурации и прочему. Отличие между ними было лишь в том, что head получал пользовательский трафик, а tail никогда трафик пользователей на себя не получал.
Для чего это было сделано?
Когда мы деплоили новые релизы нашего приложения, то хотели обеспечить возможность бесшовной раскатки, то есть без заметных последствий для пользователей. Достигалось это за счет того, что очередной собранный релиз с помощью Ansible выкатывался на tail. Там люди, которые занимались деплоем, могли проверить и убедиться, что все хорошо: все метрики, разделы и приложения работают; запускаются нужные скрипты. Только после того, как они убеждались, что все ок, трафик переключался. Он начинал идти на тот сервер, который до этого был tail. А тот, который до этого был head-ом, оставался без пользовательского трафика, при этом с имеющейся на нем предыдущей версией нашего приложения.
Таким образом, для пользователей это было бесшовно. Потому что переключение одномоментное, так как это просто переключение балансировщика. Очень легко можно откатиться на предыдущую версию, просто переключив балансировщик назад. Также мы могли убедиться в способности приложения на продакшн еще до того, как на него пойдет пользовательский трафик, что было достаточно удобно.
Какие мы видели во всем этом достоинства?
Мы долго размышляли над тем, какую из них можно взять. Дело в том, что на тот момент этот стек деплоя на обычные виртуальные сервера был у нас несколько устаревшим, так как там были не самые свежие версии операционных систем. В какой-то момент там даже FreeBSD стояла, которую было не очень удобно поддерживать. Мы понимали, что нужно как можно быстрее мигрировать в docker. Наши девопс посмотрели на свой имеющийся опыт работы с разными решениями и выбрали такую систему как Nomad.
Переход на Nomad
Nomad – это продукт компании “HashiCorp”. Также они известны другими своими решениями:
«Consul» — это средство для сервис-дискаверинга.
«Terraform» — система для управления серверами, позволяющая вам настраивать их через конфигурацию, так называемую infrastructure-as-a-code.
«Vagrant» позволяет вам разворачивать виртуальные машины локально или в облаке путем определенных файлов конфигурации.
Nomad на тот момент показался достаточно простым решением, на который можно быстро перейти без изменения всей инфраструктуры. К тому же, он достаточно легко осваивается. Поэтому именно его мы и выбрали в качестве системы фильтрации нашего контейнера.
Что нужно для того, чтобы вообще задеплоить вашу систему в Nomad?
Он позволяет сказать, сколько контейнеров хотите задеплоить, из каких images передать им различные параметры при деплое. Таким образом, вы скармливаете этот файл Nomad, а он запускает в соответствии с ним контейнеры в продакшн.
В нашем случае мы поняли, что просто писать под каждый сервис абсолютно одинаковые, идентичные HСL-файлы будет не очень удобно, потому что сервисов много и иногда хочется их обновить. Бывает такое, что один сервис задеплоен не в одном экземпляре, а в самых разных. Например, одна из систем, которая у нас находится в продакшн, имеет более 100 инстансов в проде. Они запускаются из одних и тех же образов, но отличаются конфигурационными настройками и конфигурационными файлами.
Поэтому мы решили, что нам будет удобно хранить все наши конфигурационные файлы для деплоя в одном общем репозитории. Таким образом, они становились обозреваемы: их было легко поддерживать и можно было увидеть, какие системы у нас есть. В случае необходимости также несложно что-то обновить или поменять. Добавить новую систему тоже не составит труда — достаточно просто завести конфигурационный файл внутри новой директории. Внутри нее лежат файлы: service.hcl, который содержит описание нашего сервиса, и некоторые env-файлы, которые позволяют этот самый сервис, будучи задеплоенным в продакшн, настроить.
Однако некоторые наши системы задеплоены в проде не в одном экземпляре, а в нескольких сразу. Поэтому мы решили, что нам удобно будет хранить не конфиги в чистом виде, а их шаблонизированный вид. И в качестве языка шаблонизации мы выбрали jinja 2. В таком формате у нас хранятся как конфиги самого сервиса, так и env-файлы, нужные для него.
Помимо этого, мы поместили в репозиторий общий для всех проектов скрипт-деплой, который позволяет запустить и задеплоить ваш сервис в продакшн, в нужный environment, в нужный таргет. В случае, когда мы превратили наш HCL-конфиг в шаблон, то тот HСL-файл, который до этого был обычным конфигом Nomad, в этом случае стал выглядеть несколько иначе.
То есть мы заменили какие-то переменные места конфига на вставки переменных, которые берутся из env-файлов или из других источников. Помимо этого, мы получили возможность собирать HСL-файлы динамически, то есть мы можем применять не только обычные вставки переменных. Так как jinja поддерживает циклы и условия, туда же можно делать конфигурационные файлы, которые меняются в зависимости от того, куда именно вы деплоите свои приложения.
Например, вы хотите деплоить ваш сервис в препродакшн и в продакшн. Допустим, что в препродакшн вы не хотите запускать крон-cкрипты, а просто хотите видеть сервис на отдельном домене, чтобы убедиться, что он функционирует. Для любого, кто деплоит сервис, процесс выглядит очень просто и прозрачно. Достаточно выполнить файл deploy.sh, указать, какой сервис вы хотите задеплоить и в какой таргет. Например, вы хотите задеплоить некоторую систему в Россию, в Белоруссию или Казахстан. Для этого достаточно просто поменять один из параметров, и у вас соберется правильный конфигурационный файл.
Когда сервис Nomad уже оказывается у вас задеплоенным в кластер, он выглядит следующим образом.
Для начала вам нужен некоторый балансировщик снаружи, который будет принимать весь пользовательский трафик в себя. Он будет работать вместе с Consul и узнавать у него, где, на какой ноде, по какому IP-адресу находится конкретный сервис, который соответствует тому или иному доменному имени. Сервисы в Consul появляются из самого Nomad. Поскольку это продукты одной и той же компании, они неплохо связаны между собой. Можно сказать, что Nomad из коробки умеет регистрировать все запускаемые в нем сервисы внутри Consul.
После того как ваш внешний балансировщик узнает о том, в какой сервис необходимо отправить трафик, он перенаправляет его в соответствующий контейнер или в несколько контейнеров, которые соответствуют вашему приложению. Естественно, что при этом необходимо думать и о безопасности. Даже несмотря на то, что все сервисы запускаются на одних и тех же виртуальных машинах в контейнерах, обычно для этого требуется запретить свободный доступ из любого сервиса к любому другому. Мы достигали этого за счет сегментации. Каждый сервис запускался в своей виртуальной сети, на которой были прописаны правила маршрутизации и правила разрешения/запрета доступа к другим системами и сервисам. Они могли находиться как внутри этого кластера, так и вне него. Например, если вы хотите запретить сервису коннектиться к определённой базе данных, это можно сделать путем сегментации на уровне сети. То есть даже по ошибке вы не можете случайно подсоединяться из тестового окружения к вашей продакшн базе.
Во что нам обошелся процесс перехода в плане человеческих ресурсов?
Примерно 5-6 месяцев занял переход всей компании в Nomad. Мы переходили посервисно, но в достаточно быстром темпе. Каждая команда должна была создать свои собственные контейнеры для сервисов.
У нас принят такой подход, что каждая команда отвечает за docker images своих систем самостоятельно. Девопс же предоставляют общую инфраструктуру, необходимую для деплоя, то есть поддержку самого кластера, поддержку CI-системы и так далее. И на тот момент у нас более 60 систем переехали в Nomad, получилось порядка 2 тысяч контейнеров.
Девопс отвечает за общую инфраструктуру всего, что связано с деплоем, с серверами. А каждая команда разработки в свою очередь отвечает за реализацию контейнеров под свою конкретную систему, поскольку именно команда знает, что ей вообще нужно в том или ином контейнере.
Причины отказа от Nomad
Какие достоинства мы получили, перейдя на деплой с помощью Nomad и docker в том числе?
Оказалось, что мы не смогли достичь бесшовности деплоев в случае Nomad. При выкатке контейнеров из разных условий могло получиться так, что он оказывался запущенным, и Nomad воспринимал его как готовый к принятию трафика контейнер. Это происходило еще до того, как приложение внутри него успело запуститься. По этой причине система на недолгий срок начинала выдавать 500-е ошибки, потому что трафик начинал идти на контейнер, который еще не готов его принять.
Мы столкнулись с некоторыми багами. Самый существенный баг заключается в том, что Nomad не очень хорошо воспринимает большой кластер, если у вас много систем и контейнеров. Когда вы хотите вывезти в обслуживание один из серверов, который включен в кластер Nomad, есть достаточно большая вероятность того, что кластер почувствует себя не очень хорошо и развалится на части. Часть контейнеров может, например, упасть и не подняться — это вам впоследствии очень дорого обойдется, если все ваши системы в продакшн находятся именно в кластере, управляемом Nomad.
Поэтому мы решили подумать, куда нам идти дальше. На тот момент мы стали намного лучше осознавать, чего хотим добиться. А именно: хотим надежности, немножко больше функций, чем дает Nomad, и более зрелую, более стабильную систему.
В этом плане наш выбор пал на Kubernetes как на самую популярную платформу для запуска кластеров. Особенно при условии того, что размер и количество наших контейнеров был достаточно большой. Для таких целей Kubernetes показался самой подходящей системой из тех, что мы могли посмотреть.
Переход в Kubernetes
Немножко расскажу о том, какие есть основные понятия Kubernetes и чем они отличаются от Nomad.
В первую очередь самым базовым понятием в Kubernetes является понятие pod. Pod — это группа одного или нескольких контейнеров, которые всегда запускаются вместе. И они работают как будто всегда строго на одной виртуальной машине. Они доступны друг другу по айпишнику 127.0.0.1 на разных портах.
Предположим, что у вас есть РНР-приложение, которое состоит из nginx и php-fpm – классическая схема. Скорее всего, вы захотите, чтобы и nginx и php-fpm контейнеры были всегда вместе. Kubernetes позволяет этого добиться, описав их как один общий pod. Как раз этого мы и не могли получить при помощи Nomad.
Вторым понятием является deployment. Дело в том, что pod сам по себе – это эфемерная вещь, она запускается и исчезает. Хотите ли вы сначала убивать все ваши предыдущие контейнеры, а потом запускать сразу новые версии или же вы хотите выкатывать их постепенно – вот именно за этот процесс отвечает понятие deployment. Он описывает то, как вы деплоите ваши podы, в каком количестве и, как их обновлять.
Третьим понятием является service. Ваш service – это фактически ваша система, которая принимает в себя некий трафик, а потом направляет его на один или несколько podов, соответствующих вашему сервису. То есть он позволяет сказать, что весь входящий трафик на такой-то сервис с таким-то именем необходимо отправлять на конкретно эти podы. И при этом он обеспечивает вам балансировку трафика. То есть вы можете запустить два podа вашего приложения, и весь входящий трафик будет равномерно балансироваться между относящимися к этому сервису podами.
И четвертое основное понятие — Ingress. Это сервис, который запускается в кластере Kubernetes. Он выступает как внешний балансировщик нагрузки, который принимает на себя все запросы. За счет API Kubernetes Ingress может определять, куда эти запросы надо отправить. Причем делает он это очень гибко. Вы можете сказать, что все запросы на этот хост и такой-то URL отправляем на этот сервис. А эти запросы, приходящие на этот хост и на другой URL отправляем на другой сервис.
Самое крутое с точки зрения того, кто разрабатывает приложение — это то, что вы способны этим всем управлять самостоятельно. Задав конфиг Ingress, можете весь трафик, приходящий на такой-то API, отправлять на отдельные контейнеры, прописанные, например, на Go. А вот этот трафик, приходящий на тот же домен, но на другой URL, отправлять на контейнеры, написанные на РНР, где много логики, но они не очень скоростные.
Если сравнить все эти понятия с Nomad, то можно сказать, что первые три понятия – это все вместе Service. А последнее понятие в самом Nomad отсутствует. Мы в качестве него использовали внешний балансировщик: это может быть haproxy, nginx, nginx+ и так далее. В случае с кубом вам не надо вводить это дополнительное понятие отдельно. Однако, если посмотреть на Ingress внутри, то это либо nginx, либо haproxy, либо traefik, но как бы встроенный в Kubernetes.
Все описанные мною понятия – это, по сути дела, ресурсы, которые существуют внутри кластера Kubernetes. Для их описания в кубе используется yaml-формат, более читаемый и привычный, чем НСL-файлы в случае с Nomad. Но структурно они описывают в случае, например, podа то же самое. Они говорят – хочу задеплоить такие-то podы туда-то, с такими-то имаджи, в таком-то количестве.
Помимо этого, мы поняли, что не хотим руками создавать каждый отдельный ресурс: deployment, сервисы, Ingress и прочее. Вместо этого мы хотели при деплое описывать нашу каждую систему, имеющуюся в терминах Kubernetes, чтобы не приходилось вручную пересоздавать в нужном порядке все необходимые зависимости ресурсов. В качестве такой системы, которая позволила нам это сделать, был выбран Helm.
Основные понятия в Helm
Helm – это пакетный менеджер для Kubernetes. Он очень похож на то, как работают пакетные менеджеры в языках программирования. Они позволяют вам хранить сервис, состоящий из, например, deployment nginx, deployment php-fpm, конфига для Ingress, configmaps (это сущность, которая позволяет вам задать env и другие параметры для вашей системы) в виде так называемых чартов. При этом Helm работает поверх Kubernetes. То есть это не какая-то система, стоящая в стороне, а просто ещё один сервис, запускаемый внутри куба. Вы взаимодействуете с ним по его API через консольную команду. Его удобство и прелесть в том, что даже если helm сломается или вы его удалите из кластера, то ваши сервисы не исчезнут, так как helm служит по сути только для запуска системы. За работоспособность и состояние сервисов дальше отвечает сам Kubernetes.
Также мы поняли, что шаблонизация, которую до этого были вынуждены делать самостоятельно через внедрение jinja в наши конфиги, является одной из основных возможностей helm. Все конфиги, которые вы создаете для ваших систем, хранятся в helm в виде шаблонов, похожих немножко на jinja, но, на самом деле, использующих шаблонизацию языка Go, на котором helm написан, как и Kubernetes.
Helm добавляет нам еще несколько дополнительных понятий.
Chart — это описание вашего сервиса. В других пакетных менеджерах его назвали бы пакет, bundle или что-то подобное. Здесь это называется chart.
Values – это переменные, которые вы хотите использовать для сборки ваших конфигов из шаблонов.
Release. Каждый раз сервис, который деплоится с помощью helm, получает инкрементальную версию релиза. Helm помнит, какой был конфиг сервиса при предыдущем, позапрошлом релизе и так далее. Поэтому, если нужно откатиться, достаточно выполнить команду helm callback, указав ему предыдущую версию релиза. Даже если в момент отката соответствующая конфигурация в вашем репозитории не будет доступна, helm все равно помнит, какой она была, и откатит вашу систему на то состояние, в котором она была в предыдущем релизе.
В случае, когда мы используем helm, обычные конфиги для Kubernetes тоже превращаются в шаблоны, в которых есть возможность использовать переменные, функции, применять условные операторы. Таким образом, вы можете собирать конфиг вашего сервиса в зависимости от среды.
На практике мы решили поступить чуть-чуть иначе, чем мы делали в случае с Nomad. Если в Nomad в одном репозитории хранились и конфиги для деплоя, и n-переменные, которые нужны для того, чтобы задеплоить наш сервис, то здесь мы решили их разделить на два отдельных репозитория. В репозитории «deploy» хранятся только n-переменные, нужные для деплоя, а в репозитории «helm» хранятся конфиги или чарты.
Несмотря на то, что в самих конфигурационных файлах мы не храним какие-то действительно чувствительные данные. Например, пароли к базам данных. Они хранятся в виде secrets в Kubernetes, но тем не менее, там все равно есть отдельные вещи, к которым мы не хотим давать доступ всем подряд. Поэтому доступ к репозиторию «deploy» более ограничен, а репозиторий «helm» содержит просто описание сервиса. По этой причине в него можно дать доступ безопасно большему кругу лиц.
Поскольку у нас есть не только продакшн, но и другие среды, то благодаря такому разделению мы можем переиспользовать наши helm-чарты, чтобы деплоить сервисы не только в продакшн, но и, например, в QA-среду. Даже для того, чтобы разворачивать их локально, используя Minikube — это такая штука для локального запуска Kubernetes.
Внутри каждого репозитория мы оставили разделение на отдельные директории для каждого сервиса. То есть внутри каждой директории находятся шаблоны, относящиеся к соответствующему чарту и описывающие те ресурсы, которые необходимо задеплоить для запуска нашей системы. В репозитории «deploy» мы оставили только энвы. В этом случае мы не стали использовать шаблонизацию с помощью jinja, потому что helm сам дает шаблонизацию из коробки – это одна из его основных функций.
Мы оставили скрипт для деплоя – deploy.sh, который упрощает и стандартизирует запуск для деплоя с помощью helm. Таким образом, для любого, кто хочет задеплоить, интерфейс деплоя выглядит точно так же, как он был в случае деплоя через Nomad. Такой же deploy.sh, название вашего сервиса, и то, куда вы хотите его задеплоить. Это приводит к тому, что внутри запускается helm. Он в свою очередь собирает конфиги из шаблонов, подставляет в них необходимые values-файлы, затем деплоит, пуская их в Kubernetes.
Выводы
Сервис Kubernetes выглядит более сложным, чем Nomad.
Здесь исходящий трафик приходит в Ingress. Это как раз фронт-контроллер, который принимает на себя все запросы и впоследствии отправляет их в соответствующие данным запроса сервисы. Определяет он их на основе конфигов, которые являются частью описания вашего приложения в helm и которые разработчики задают самостоятельно. Сервис же отправляет запросы на свои podы, то есть конкретные контейнеры, балансируя входящий трафик между всеми контейнерами, которые относятся к данному сервису. Ну и, конечно, не стоит забывать про то, что от безопасности на уровне сети, мы никуда не должны уходить. Поэтому в кластере Kubernetes работает сегментация, которая основана на тегировании. Все сервисы имеют определенные теги, к которым привязаны права доступов сервисов к тем или иным внешним/внутренним ресурсам внутри или вне кластера.
Выполняя переход, мы увидели, что Kubernetes обладает всеми возможностями Nomad, который до этого мы использовали, а также добавляет много нового. Его можно расширять через плагины, а по факту через кастомные типы ресурсов. То есть у вас есть возможность не просто использовать что-то, что идет в Kubernetes из коробки, а создать свой собственный ресурс и сервис, который будет ваш ресурс читать. Это дает дополнительные возможности расширения вашей системы без необходимости переустановки Kubernetes и без необходимости изменений.
Примером такого использования является Prometheus, который запускается у нас внутри кластера Kubernetes. Для того, чтобы он начал собирать метрики с того или иного сервиса, нам нужно добавить в описание сервиса дополнительный тип ресурса, так называемый сервис-монитор. Prometheus за счет того, что умеет вычитывать, будучи запущенным в Kubernetes, кастомный тип ресурсов, автоматически начинает собирать метрики с новой системы. Это достаточно удобно.
Первый деплой, который мы сделали в Kubernetes был в марте 2018 года. И за это время мы никогда не испытывали с ним никаких проблем. Он достаточно стабильно работает без существенных багов. К тому же, мы можем его дальше расширять. На сегодняшний день нам хватает тех возможностей, которые в нем есть, а темпы развития Kubernetes нам очень нравятся. На данный момент больше 3000 контейнеров находятся в Kubernetes. Кластер занимает несколько Node. При этом он обслуживаемый, стабильный и очень контролируемый.