Преобразование диаграмм руля в приложения Jenkins X

Ваш кластер должен запускать довольно много сторонних приложений. Их нужно как-то устанавливать и управлять. В этой статье предлагается один из возможных способов установки и поддержки сторонних приложений с помощью Jenkins X Apps. Мы будем использовать Istio в качестве примера такого приложения и попытаемся выяснить, как преобразовать его официальные диаграммы Helm в приложения Jenkins X Apps, и в ходе этого процесса рассмотрим некоторые из преимуществ, которые они предоставляют.

Если вы надеетесь запустить примеры из этой статьи, вам понадобится кластер Kubernetes с установленным Jenkins X с помощью Jenkins X Boot .

Если вы прочитаете документацию Istio , вы обнаружите, что необходимо установить две диаграммы; istio-init и istio . Вы также узнаете, что хранилище, в котором хранятся диаграммы, доступно по адресу https://storage.googleapis.com/istio-release/releases/1.3.2/charts/ . Учитывая, что одно приложение Jenkins X ссылается на одну диаграмму Хелма, нам нужно добавить два приложения; один для istio-init а другой для istio . Обладая этими знаниями, мы можем добавить первое из двух приложений. Команда выглядит следующим образом.

Как и раньше, вывод этой команды будет отличаться в зависимости от того, использовали ли вы Jenkins X Boot с dev репо, или нет.

Вы должны увидеть ссылку на вновь созданный пул-запрос. Откройте его и перейдите на вкладку « Измененные файлы », чтобы мы рассмотрели предложенные изменения.

При добавлении istio-init те же файлы, что и в Prometheus, за исключением того, что два (из трех) находятся в разных каталогах.

env/istio-init/README.MD содержит информацию о приложении и весь файл README из исходного графика. Далее у нас есть env/istio-init/templates/app.yaml который является определением приложения, с информацией о репозитории jenkins.io/chart-repository , именем диаграммы ( jenkins.io/app-name ) и версия ( jenkins.io/app-version ). Наконец, istio-init был добавлен вместе с другими зависимостями в env/requirements.yaml istio-init .

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

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

Нажмите Ctrl + C, чтобы прекратить наблюдение за действием после его успешного завершения.

Наконец, мы подтвердим, что istio-init был установлен правильно, путем вывода пользовательских определений ресурсов (CRD), которые содержат istio.io в своем имени. Если вы не знакомы с Istio, все, что istio-init , это устанавливает эти CRD. Остальная часть установки приходит после.

Если Istio не изменилось со времени, когда я написал это (октябрь 2019 г.), в выводе должно быть двадцать три CRD, и мы можем сделать вывод, что первая часть настройки Istio была выполнена правильно.

Вот и все. Вы видели, как вы можете создавать Jenkins X Apps с помощью команды jx add app . Мы также изучили, как эти приложения могут быть обновлены или удалены. Если вы используете репозиторий dev , вы видели некоторые преимущества приложений, в основном их поддержку процессов GitOps. Каждый раз, когда приложение добавляется или удаляется, jx создает новую ветвь и запрос на извлечение, и он ждет, когда вы просмотрите и утвердите изменения, объединив его с мастером.

Однако в некоторых случаях вы можете пропустить просмотр и объединение запросов на извлечение. Возможно, вы захотите, чтобы Jenkins X сделал это и для вас. В таких случаях вы можете добавить аргумент --auto-merge .

--auto-merge может не работать из-за проблем 5761 . Не стесняйтесь контролировать это, чтобы видеть, было ли это решено.

Вы должны понимать, что команды jx add app и jx delete app только манипулируют файлами в репозитории dev и отправляют их в Git. Все остальное сделано Jenkins X, работающим в кластере. Это означает, что вам не нужно использовать эти команды. Думайте о них больше как о «помощниках», чем о требованиях для работы с приложениями. Мы можем сделать то же самое без них. Мы можем создать нужные нам файлы и отправить их в Git. В результате новое приложение будет добавлено без выполнения какой-либо команды (кроме git ).

Нам все еще нужно применить вторую диаграмму ( istio ), поэтому мы будем использовать ее в качестве предлога, чтобы попытаться добавить приложение без выполнения команд jx .

Так как мы собираемся создать и изменить несколько файлов в локальной копии репозитория dev , мы должны начать с получения последней базы кода из GitHub.

Теперь, когда у нас есть локальная копия последней версии репозитория, мы можем создать новое приложение. Помните, на этот раз мы изучаем, как это сделать, создав файлы сами, а не с помощью команды jx add app .

Мы можем подойти к этому вызову с двух сторон. Одним из вариантов может быть создание всех файлов с нуля. Другой — скопировать каталог одного из существующих приложений и изменить его в соответствии с нашими потребностями. Мы пойдем со вторым вариантом, так как он, вероятно, проще. Учитывая, что у нас уже есть приложение, использующее istio-init , его файлы, вероятно, являются лучшим кандидатом для использования в качестве основы для istio .

Теперь, когда мы скопировали istio-init как istio , все, что нам нужно сделать, это изменить несколько файлов. Мы пропустим модификацию README. Это важно только для людей (мы могли бы прочитать это), но это не играет никакой роли в этом процессе. В ситуациях «реального мира» я бы ожидал, что вы тоже это измените. Но поскольку это не «реальный мир», а скорее опыт обучения, нам не нужно проводить с ним время.

Есть три файла, которые нам может потребоваться изменить. Мы можем создать env/istio/templates/values.yaml если хотим изменить любое из значений диаграммы по умолчанию. Мы пропустим этот, потому что istio хорош как есть. Вместо этого мы сосредоточимся на двух других файлах.

Это определение приложения, которое мы собираемся добавить в кластер. Это копия istio-init , поэтому все, что нам нужно сделать, это изменить значения jenkins.io/app-name и name с istio-init на istio . Мы также изменим jenkins.io/chart-description . Он служит только информативным целям. Но, поскольку мы хорошие люди и не хотим вводить в заблуждение других, изменение этого может дать дополнительную ясность тому, кто бы мог исследовать это позже.

Команда, которая должна внести эти изменения, выглядит следующим образом.

Определение приложения само по себе бесполезно. Его существование не приведет к его запуску внутри кластера. Нам нужно добавить его как еще одну зависимость в env/requirements.yaml . Итак, давайте взглянем на то, что внутри.

Вывод следующий.

Все, кроме последней зависимости, относятся к системе в конфигурации по умолчанию. Позже мы использовали jx add app для добавления istio-init в микс. Теперь нам не хватает записи для istio . repository и version совпадают, и единственное отличие заключается в name .

Осталось только перенести изменения в GitHub и позволить системе привести фактическое в желаемое состояние, которое мы только что расширили с помощью дополнительного приложения. Обычно мы создаем ветку, помещаем туда изменения, создаем запрос на извлечение и объединяем его с главной веткой. Это был бы правильный способ справиться с этим или любым другим изменением. Но в интересах времени мы пропустим это, предполагая, что вы уже знаете, как создавать PR. Если вы этого не сделаете, вы не в той отрасли.

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

Istio должен быть полностью запущен. Мы можем подтвердить это, перечислив все стручки, которые содержат istio в своих именах.

Это не время и не место для более глубокого погружения в Истио. Это не было целью. Я использовал его только в качестве примера различных способов добавления Jenkins X Apps в систему.

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

Вывод следующий, по крайней мере, для тех, кто установил Jenkins X с помощью Boot.

Вот и все. Мы исследовали несколько часто используемых способов добавления, управления и удаления приложений Jenkins X. Скоро у нас будет короткое обсуждение. Сейчас мы удалим istio и istio-init так как они нам больше не нужны.

Вы знаете, что делать дальше. Объедините PR, чтобы изменение (удаление istio ) было применено к системе. Это видно по предлагаемым изменениям в файле env/requirements.yaml .

Вы заметите, что команда jx delete app работает независимо от того, было ли приложение добавлено через jx add app или путем манипулирования файлами непосредственно в Git. Он всегда работает через Git (если вы НЕ используете dev репо).

Следующим в очереди на удаление является istio-init , и процесс такой же.

Я оставлю вас, чтобы сделать все остальное самостоятельно (если вы используете Boot). Слей этот пиар!

Вот и все. Вы изучили основы расширения платформы Jenkins X, добавив приложения. На самом деле речь идет не только о расширении Jenkins X, но и о надежном способе добавления любого стороннего приложения в ваш кластер. Однако не все одинаково хорошо подходят для Jenkins X Apps.

Приложения Jenkins X полезны как минимум для двух сценариев. Когда мы хотим расширить Jenkins X, добавление Apps, без сомнения, является наилучшим вариантом. Учитывая, что приложениями могут быть любые диаграммы Хелма, мы можем преобразовать любое приложение в приложение.

Помимо тех, которые предназначены для расширения Jenkins X, отличными кандидатами являются диаграммы, которые не обязательно должны быть в нескольких репозиториях. Например, если мы хотим запустить два экземпляра Prometheus (один для тестирования, а другой для производства), лучше добавить их в соответствующие репозитории постоянной среды. Однако многие из них плохо подходят для запуска в тестировании или не стоят проверки. Прометей может быть таким случаем. Если мы модернизируем его, и это окажется плохим выбором, никакой опасности для кластера не будет. Возможно, мы не сможем получить некоторые показатели, но это будет только временно, пока мы не вернемся к предыдущей версии. Исключение будет, если мы подключим HorizontalPodAutoscaler к метрикам Prometheus, и в этом случае тестирование перед развертыванием новой версии в производстве имеет первостепенное значение. Таким образом, когда приложения должны запускаться только в рабочей среде (без использования второго экземпляра для тестирования), приложения являются лучшим способом управления ими благодаря ряду дополнительных преимуществ, которые они предоставляют.

По сути, Jenkins X Apps следует тем же принципам GitOps, что и любой другой. Их определения хранятся в Git, мы можем создавать запросы извлечения и просматривать изменения, и только слияние с основной веткой изменит состояние кластера. Использование приложений не сильно отличается от определения зависимостей в промежуточном, производственном или любом другом постоянном хранилище среды. Что делает их «особенными», так это добавление нескольких вспомогательных функций и нескольких соглашений, облегчающих управление. У нас есть более четко определенный конвейер. Филиалы и пул-запросы создаются автоматически. Секреты хранятся в хранилище. Зависимости лучше организованы. И так далее. Мы исследовали только некоторые из этих функций. Позже мы увидим еще несколько в действии, и сообщество обязательно добавит больше со временем.