TOC

Серия вебинаров: Управление пакетами Kubernetes с помощью Helm и CI / CD с Jenkins X

Вступление

Чтобы уменьшить количество ошибок и упорядочить сложность при развертывании приложения, системы CI / CD должны включать надежные инструменты для управления / развертывания пакетов и конвейеры с автоматическим тестированием. Но в современных производственных средах повышенная сложность облачной инфраструктуры может создать проблемы для создания надежной среды CI / CD. Для решения этой проблемы были разработаны два специфичных для Kubernetes инструмента: менеджер пакетов Helm и инструмент автоматизации конвейера Jenkins X.

Helm - это менеджер пакетов, специально разработанный для Kubernetes, поддерживаемый Cloud Native Computing Foundation (CNCF) в сотрудничестве с Microsoft, Google, Bitnami и сообществом разработчиков Helm. На высоком уровне он выполняет те же цели, что и менеджеры системных пакетов Linux, такие как APT или YUM: управление установкой приложений и зависимостей за кулисами и скрытие сложности от пользователя. Но в Kubernetes необходимость такого управления еще более очевидна: для установки приложений требуется сложная и утомительная согласованность файлов YAML, а обновление или откат выпусков может быть где угодно, от трудного до невозможного. Чтобы решить эту проблему, Helm работает поверх Kubernetes и упаковывает приложения в предварительно сконфигурированные ресурсы, называемые charts, которыми пользователь может управлять с помощью простых команд, делая процесс совместного использования и управления приложениями более удобным для пользователя.

Jenkins X - это инструмент CI / CD, используемый для автоматизации производственных конвейеров и сред для Kubernetes. Используя изображения Docker, диаграммы Хелма и механизм конвейера Jenkins, Jenkins X может автоматически управлять выпусками и версиями и продвигать приложения между средами на GitHub.

Во второй статье *CI/CD with Kubernetes * series вы предварительно ознакомитесь с этими двумя инструментами:

  • Управление, создание и развертывание пакетов Kubernetes с помощью Helm.

  • Создание конвейера CI / CD с Jenkins X.

Хотя различные платформы Kubernetes могут использовать Helm и Jenkins X, в этом руководстве вы запустите симулированный кластер Kubernetes, настроенный в вашей локальной среде. Для этого вы будете использовать Minikube, программу, которая позволяет вам опробовать инструменты Kubernetes на своем компьютере без необходимости устанавливать настоящий кластер Kubernetes.

К концу этого учебного курса вы получите общее представление о том, как эти нативные инструменты Kubernetes могут помочь вам реализовать систему CI / CD для вашего облачного приложения.

Предпосылки

Чтобы следовать этому уроку, вам понадобится:

  • Сервер Ubuntu 16.04 с 16 ГБ ОЗУ или выше. Поскольку этот учебник предназначен только для демонстрационных целей, команды запускаются от имени учетной записи root. * Обратите внимание, что неограниченные привилегии этой учетной записи не соответствуют рекомендациям, готовым к работе, и могут повлиять на вашу систему. * По этой причине рекомендуется выполнять следующие действия в тестовой среде, такой как виртуальная машина или https: / /www.digitalocean.com/products/droplets/[DigitalOcean Droplet].

  • Https://github.com/[GitHub account] и https://github.com/settings/tokens/new?scopes=repo,read:user,read:org,user:email,write:repo_hook,delete_repo [ GitHub API-токен. Обязательно запишите этот токен API, чтобы его можно было ввести во время части Jenkins X этого руководства.

  • Знакомство с понятиями Kubernetes. Пожалуйста, обратитесь к статье An Введение в Kubernetes для более подробной информации.

Шаг 1 - Создание локального кластера Kubernetes с Minikube

Перед настройкой Minikube вам необходимо установить его зависимости, в том числе инструмент командной строки Kubernetes kubectl, двунаправленное реле передачи данных. socat и контейнерная программа Docker.

Во-первых, убедитесь, что менеджер пакетов вашей системы может обращаться к пакетам через HTTPS с помощью + apt-transport-https +:

apt-get update
apt-get install apt-transport-https

Затем, чтобы убедиться, что загрузка kubectl действительна, добавьте ключ GPG для официального репозитория Google в вашу систему:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

Как только вы добавили ключ GPG, создайте файл + / etc / apt / sources.list.d / kubernetes.list +, открыв его в текстовом редакторе:

nano /etc/apt/sources.list.d/kubernetes.list

После открытия этого файла добавьте следующую строку:

/etc/apt/sources.list.d/kubernetes.list

deb http://apt.kubernetes.io/ kubernetes-xenial main

Это покажет вашей системе источник для загрузки kubectl. После добавления строки сохраните и выйдите из файла. С помощью текстового редактора nano вы можете сделать это, нажав + CTRL + X +, набрав + y + и нажав + ENTER +.

Наконец, обновите список источников для APT и установите + kubectl +, + socat + и + docker.io +:

apt-get update
apt-get install -y kubectl socat docker.io

Теперь, когда вы установили kubectl, вы можете перейти к install Minikube. Сначала используйте + curl + для загрузки бинарного файла программы:

curl -Lo minikube https://storage.googleapis.com/minikube/releases//minikube-linux-amd64

Затем измените права доступа для файла, который вы только что загрузили, чтобы ваша система могла его выполнить:

chmod +x minikube

Наконец, скопируйте файл + minikube + в путь к исполняемому файлу + / usr / local / bin / + и удалите исходный файл из вашего домашнего каталога:

cp minikube /usr/local/bin/
rm minikube

С установленным на вашем компьютере Minikube вы можете запустить программу. Чтобы создать кластер Minikube Kubernetes, используйте следующую команду:

minikube start --vm-driver none

Флаг + - vm-driver none + указывает Minikube запускать Kubernetes на локальном хосте, используя контейнеры, а не виртуальную машину. Запуск Minikube таким способом означает, что вам не нужно загружать драйвер виртуальной машины, но также означает, что сервер Kubernetes API будет работать небезопасно как пользователь root.

Теперь, когда вы запустили Minikube, убедитесь, что ваш кластер работает, с помощью следующей команды:

minikube status

Вы получите следующий вывод с вашим IP-адресом вместо ++:

minikube: Running
cluster: Running
kubectl: Correctly Configured: pointing to minikube-vm at

Теперь, когда вы настроили имитируемый кластер Kubernetes с помощью Minikube, вы можете получить опыт управления пакетами Kubernetes, установив и настроив менеджер пакетов Helm в верхней части кластера.

Шаг 2 - Настройка диспетчера пакетов Helm в вашем кластере

Чтобы координировать установку приложений в вашем кластере Kubernetes, вы теперь установите менеджер пакетов Helm. Helm состоит из клиента + helm +, работающего вне кластера, и сервера + tiller +, который управляет выпуском приложений из кластера. Вам нужно будет установить и настроить оба, чтобы успешно запустить Helm в вашем кластере.

Чтобы install двоичные файлы Helm, сначала используйте + curl + для загрузки следующего https://raw.githubusercontent.com/helm / helm / master / scripts / получить [скрипт установки] из официального репозитория Helm GitHub в новый файл с именем + get_helm.sh +:

curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh

Поскольку для этого сценария требуется доступ с правами root, измените разрешение + get_helm.sh +, чтобы владелец файла (в данном случае root) мог прочитать, записать и выполнить его:

chmod 700 get_helm.sh

Теперь выполните скрипт:

./get_helm.sh

Когда скрипт завершится, у вас будет установлено + helm + для + / usr / local / bin / helm + и + tiller + для + / usr / local / bin / tiller +.

Хотя + tiller + теперь установлен, у него еще нет правильных ролей и разрешений для доступа к необходимым ресурсам в вашем кластере Kubernetes. Чтобы назначить эти роли и разрешения + tiller +, вам нужно будет создать service account с именем + tiller + `. В Kubernetes учетная запись службы представляет собой идентификатор для процессов, которые выполняются в модуле. После проверки подлинности процесса через учетную запись службы он может связаться с сервером API и получить доступ к ресурсам кластера. Если модулю не назначена определенная учетная запись службы, она получает учетную запись службы по умолчанию. Вам также нужно будет создать правило Role-Based access control (RBAC), которое авторизует учетную запись службы `+ tiller +.

В API RBAC Kubernetes role содержит правила, которые определяют набор разрешений. Роль может быть определена с областью действия + namespace + или + cluster + и может предоставлять доступ к ресурсам только в пределах одного пространства имен. + ClusterRole + может создавать одинаковые разрешения на уровне кластера, предоставляя доступ к ресурсам кластерной области, таким как узлы, и ресурсам с пространством имен, таким как pods. Чтобы назначить учетной записи службы + tiller + правильную роль, создайте файл YAML с именем + rbac_helm.yaml + и откройте его в текстовом редакторе:

nano rbac_helm.yaml

Добавьте следующие строки в файл для настройки учетной записи службы + tiller +:

rbac_helm.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
 name: tiller
 namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
 name: tiller
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: cluster-admin
subjects:
 - kind: ServiceAccount
   name: tiller
   namespace: kube-system

 - kind: User
   name: "admin"
   apiGroup: rbac.authorization.k8s.io

 - kind: User
   name: "kubelet"
   apiGroup: rbac.authorization.k8s.io

 - kind: Group
   name: system:serviceaccounts
   apiGroup: rbac.authorization.k8s.io

В предыдущем файле + ServiceAccount + позволяет процессам + tiller + получить доступ к серверу в качестве аутентифицированной учетной записи службы. + ClusterRole + предоставляет определенные разрешения для роли, а + ClusterRoleBinding + назначает эту роль списку + subject +, включая учетную запись службы + tiller +, пользователи + admin + и + kubelet +, и группа + system: serviceaccounts +.

Затем разверните конфигурацию в + rbac_helm.yaml + с помощью следующей команды:

kubectl apply -f rbac_helm.yaml

С развернутой конфигурацией + tiller + вы можете теперь инициализировать Helm с флагом + - service-acount +, чтобы использовать только что настроенную учетную запись службы:

helm init --service-account tiller

Вы получите следующий вывод, представляющий успешную инициализацию:

OutputCreating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /root/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

Это создает модуль + tiller в пространстве имен` + kube-system`. Он также создает репозиторий по умолчанию + .helm + в вашем каталоге + $ HOME + и настраивает репозиторий стабильных диаграмм Helm по умолчанию по адресу + https: // kubernetes-charts.storage.googleapis.com + и локальный репозиторий Helm по адресу + HTTP: //127.0.0.1: 8879 / графики +.

Чтобы убедиться, что модуль + tiller работает в пространстве имен` + kube-system`, введите следующую команду:

kubectl --namespace kube-system get pods

В вашем списке модулей появится + tiller-deploy +, как показано в следующем выводе:

OutputNAME                                    READY   STATUS    RESTARTS   AGE
etcd-minikube                           1/1     Running   0          2h
kube-addon-manager-minikube             1/1     Running   0          2h
kube-apiserver-minikube                 1/1     Running   0          2h
kube-controller-manager-minikube        1/1     Running   0          2h
kube-dns-86f4d74b45-rjql8               3/3     Running   0          2h
kube-proxy-dv268                        1/1     Running   0          2h
kube-scheduler-minikube                 1/1     Running   0          2h
kubernetes-dashboard-5498ccf677-wktkl   1/1     Running   0          2h
storage-provisioner                     1/1     Running   0          2h

Если состояние модуля + tiller + равно + Running +, теперь он может управлять приложениями Kubernetes из вашего кластера от имени Helm.

Чтобы убедиться, что все приложение Helm работает, найдите в хранилище пакетов Helm такое приложение, как MongoDB:

helm search mongodb

В выводе вы увидите список возможных приложений, которые соответствуют вашему поисковому запросу:

OutputNAME                                    CHART VERSION   APP VERSION     DESCRIPTION
stable/mongodb                          5.4.0           4.0.6           NoSQL document-oriented database that stores JSON-like do...
stable/mongodb-replicaset               3.9.0           3.6             NoSQL document-oriented database that stores JSON-like do...
stable/prometheus-mongodb-exporter      1.0.0           v0.6.1          A Prometheus exporter for MongoDB metrics
stable/unifi                            0.3.1           5.9.29          Ubiquiti Network's Unifi Controller

Теперь, когда вы установили Helm в своем кластере Kubernetes, вы можете больше узнать о менеджере пакетов, создав образец диаграммы Helm и развернув из нее приложение.

Шаг 3 - Создание диаграммы и развертывание приложения с помощью Helm

В менеджере пакетов Helm отдельные пакеты называются charts. В диаграмме набор файлов определяет приложение, которое может варьироваться по сложности от модуля до структурированного приложения с полным стеком. Вы можете скачать графики из репозиториев Helm или использовать команду + helm create + для создания своих собственных.

Чтобы проверить возможности Helm, создайте новую диаграмму Helm с именем + demo + с помощью следующей команды:

helm create demo

В вашем домашнем каталоге вы найдете новый каталог с именем + demo +, в котором вы можете создавать и редактировать свои собственные шаблоны диаграмм.

Перейдите в каталог + demo + и используйте + ls + для просмотра его содержимого:

cd demo
ls

В + demo + вы найдете следующие файлы и каталоги:

demo

charts  Chart.yaml  templates  values.yaml

Используя ваш текстовый редактор, откройте файл + Chart.yaml +:

nano Chart.yaml

Внутри вы найдете следующее содержимое:

демо / Chart.yaml

apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: demo
version: 0.1.0

В этом файле + Chart.yaml + вы найдете такие поля, как + apiVersion +, которые всегда должны быть + v1 +, + description +, которые дают дополнительную информацию о том, что такое + demo +, + name + `диаграммы и номер + version + `, который Хелм использует в качестве маркера выпуска. Когда вы закончите изучение файла, закройте текстовый редактор.

Затем откройте файл + values.yaml +:

nano values.yaml

В этом файле вы найдете следующее содержимое:

демо / values.yaml

# Default values for demo.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
 repository: nginx
 tag: stable
 pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
 type: ClusterIP
 port: 80

ingress:
 enabled: false
 annotations: {}
   # kubernetes.io/ingress.class: nginx
   # kubernetes.io/tls-acme: "true"
 paths: []
 hosts:
   - chart-example.local
 tls: []
 #  - secretName: chart-example-tls
 #    hosts:
 #      - chart-example.local

resources: {}
 # We usually recommend not to specify default resources and to leave this as a conscious
 # choice for the user. This also increases chances charts run on environments with little
 # resources, such as Minikube. If you do want to specify resources, uncomment the following
 # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
 # limits:
 #  cpu: 100m
 #  memory: 128Mi
 # requests:
 #  cpu: 100m
 #  memory: 128Mi

nodeSelector: {}

tolerations: []

affinity: {}

Изменяя содержимое + values.yaml +, разработчики диаграмм могут предоставить значения по умолчанию для приложения, определенного в диаграмме, контролируя количество реплик, базу изображений, входной доступ, секретное управление и многое другое. Пользователи Chart могут предоставить свои собственные значения для этих параметров с помощью специального файла YAML, используя + helm install +. Когда пользователь предоставляет пользовательские значения, эти значения будут переопределять значения в файле диаграммы + «values.yaml +».

Закройте файл + values.yaml и перечислите содержимое каталога` + templates` с помощью следующей команды:

ls templates

Здесь вы найдете шаблоны для различных файлов, которые могут управлять различными аспектами вашей диаграммы:

шаблоны

deployment.yaml  _helpers.tpl  ingress.yaml  NOTES.txt  service.yaml  tests

Теперь, когда вы изучили диаграмму + demo +, вы можете поэкспериментировать с установкой диаграммы Helm, установив + demo +. Вернитесь в свой домашний каталог с помощью следующей команды:

cd

Установите таблицу + demo Helm под именем` + web` с помощью + helm install:

helm install --name  ./demo

Вы получите следующий вывод:

OutputNAME:   web
LAST DEPLOYED: Wed Feb 20 20:59:48 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME      TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)  AGE
web-demo  ClusterIP  10.100.76.231  <none>       80/TCP   0s

==> v1/Deployment
NAME      DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
web-demo  1        0        0           0          0s

==> v1/Pod(related)
NAME                       READY  STATUS             RESTARTS  AGE
web-demo-5758d98fdd-x4mjs  0/1    ContainerCreating  0         0s


NOTES:
1. Get the application URL by running these commands:
 export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=demo,app.kubernetes.io/instance=web" -o jsonpath="{.items[0].metadata.name}")
 echo "Visit http://127.0.0.1:8080 to use your application"
 kubectl port-forward $POD_NAME 8080:80

В этом выводе вы найдете + STATUS вашего приложения, а также список соответствующих ресурсов в вашем кластере.

Далее перечислите развертывания, созданные диаграммой Helm + demo +, с помощью следующей команды:

kubectl get deploy

Это приведет к выводу, в котором будут перечислены ваши активные развертывания:

OutputNAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
web-demo   1         1         1            1           4m

Список ваших модулей с командой + kubectl get pods + будет показывать модули, на которых запущено ваше приложение + web +, что будет выглядеть следующим образом:

OutputNAME                        READY   STATUS    RESTARTS   AGE
web-demo-5758d98fdd-nbkqd   1/1     Running   0          4m
Чтобы продемонстрировать, как изменения в диаграмме Хелма могут выпустить разные версии вашего приложения, откройте + demo / values.yaml + в текстовом редакторе и измените + replicaCount: + на + 3 + и тег +

: + от + stable + до + latest + `. В следующем блоке кода вы найдете, как должен выглядеть YAML-файл после того, как вы закончили его изменение с выделенными изменениями:

демо / values.yaml

# Default values for demo.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount:

image:
 repository: nginx
 tag:
 pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
 type: ClusterIP
 port: 80
. . .

Сохраните и выйдите из файла.

Перед развертыванием этой новой версии приложения + web + перечислите выпуски Helm, как они есть, с помощью следующей команды:

helm list

Вы получите следующий вывод с одним созданным ранее развертыванием:

OutputNAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE

Обратите внимание, что + REVISION + указан как + 1 +, указывая на то, что это первая версия приложения + web +.

Чтобы развернуть приложение + web + с последними изменениями, внесенными в + demo / values.yaml +, обновите приложение с помощью следующей команды:

helm upgrade web ./demo

Теперь, перечислите выпуски Хелма снова:

helm list

Вы получите следующий вывод:

OutputNAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE
web                    Wed Feb 20 21:18:12 2019        DEPLOYED        demo-0.1.0      1.0             default

Обратите внимание, что + REVISION + изменился на + 2 +, указывая, что это вторая ревизия.

Чтобы найти историю выпусков Helm для + web +, используйте следующее:

helm history web

Это покажет обе версии приложения + web +:

Выход

REVISION        UPDATED                         STATUS          CHART           DESCRIPTION
1               Wed Feb 20 20:59:48 2019        SUPERSEDED      demo-0.1.0      Install complete
2               Wed Feb 20 21:18:12 2019        DEPLOYED        demo-0.1.0      Upgrade complete

Чтобы откатить ваше приложение до ревизии + 1 +, введите следующую команду:

helm rollback web 1

Это даст следующий результат:

OutputRollback was a success! Happy Helming!

Теперь, поднимите историю выпуска Хелма:

helm history web

Вы получите следующий список:

OutputREVISION        UPDATED                         STATUS          CHART           DESCRIPTION
1               Wed Feb 20 20:59:48 2019        SUPERSEDED      demo-0.1.0      Install complete
2               Wed Feb 20 21:18:12 2019        SUPERSEDED      demo-0.1.0      Upgrade complete
3               Wed Feb 20 21:28:48 2019                demo-0.1.0      Rollback to 1

Откатив приложение + web +, вы создали третью ревизию, которая имеет те же настройки, что и ревизия + 1 +. Помните, что вы всегда можете узнать, какая ревизия активна, найдя пункт + DEPLOYED + в + STATUS +.

Чтобы подготовиться к следующему разделу, очистите область тестирования, удалив релиз + web командой` + helm delete`:

helm delete web

Изучите историю выпуска Хелма снова:

helm history web

Вы получите следующий вывод:

OutputREVISION        UPDATED                         STATUS          CHART           DESCRIPTION
1               Wed Feb 20 20:59:48 2019        SUPERSEDED      demo-0.1.0      Install complete
2               Wed Feb 20 21:18:12 2019        SUPERSEDED      demo-0.1.0      Upgrade complete
3               Wed Feb 20 21:28:48 2019                 demo-0.1.0      Deletion complete

+ STATUS + для + REVISION 3 + изменился на + DELETED +, указывая, что ваш развернутый экземпляр + web + был удален. Однако, хотя это удаляет релиз, он не удаляет его из хранилища. Чтобы полностью удалить релиз, выполните команду + helm delete с флагом` + - purge`.

helm delete web --purge

На этом этапе вы управляли выпуском приложений в Kubernetes с помощью Helm. Если вы хотите изучить Helm дальше, ознакомьтесь с нашей Anstruction to Helm Диспетчер пакетов для Kubernetes или ознакомьтесь с официальной документацией Helm.

Затем вы настроите и протестируете инструмент автоматизации конвейера Jenkins X с помощью CLI + jx + для создания кластера Kubernetes, готового для CI / CD.

Шаг 4 - Настройка среды Jenkins X

С Jenkins X вы можете создать свой кластер Kubernetes с нуля с помощью встроенных решений автоматизации конвейера и CI / CD. Установив CLI-инструмент + jx +, вы сможете эффективно управлять выпусками приложений, образами Docker и диаграммами Helm, а также автоматически продвигать свои приложения в средах GitHub.

Поскольку вы будете использовать + jx + для создания кластера, вы должны сначала удалить кластер Minikube, который у вас уже есть. Для этого используйте следующую команду:

minikube delete

Это удалит локальный имитированный кластер Kubernete, но не удалит каталоги по умолчанию, созданные при первой установке Minikube. Чтобы очистить их от вашей машины, используйте следующие команды:

rm -rf ~/.kube
rm -rf ~/.minikube
rm -rf /etc/kubernetes/*
rm -rf /var/lib/minikube/*

После того, как вы полностью очистили Minikube от своего компьютера, вы можете перейти к установке бинарного файла Jenkins X.

Сначала загрузите сжатый файл + jx + из официального Jenkins X GitHub репозитория с помощью команды + curl + и распакуйте его с помощью команды + tar +:

curl -L https://github.com/jenkins-x/jx/releases/download/v1.3.781/jx-linux-amd64.tar.gz | tar xzv

Затем переместите загруженный файл + js в путь к исполняемому файлу в` + / usr / local / bin`:

mv jx /usr/local/bin

Jenkins X поставляется с Docker Registry, который работает внутри вашего кластера Kubernetes. Поскольку это внутренний элемент, меры безопасности, такие как самозаверяющие сертификаты, могут создавать проблемы для программы. Чтобы это исправить, настройте Docker на использование незащищенных реестров для локального диапазона IP-адресов. Для этого создайте файл + / etc / docker / daemon.json + и откройте его в текстовом редакторе:

nano /etc/docker/daemon.json

Добавьте следующее содержимое в файл:

/etc/docker/daemon.json

{
 "insecure-registries" : ["0.0.0.0/0"]
}

Сохраните и выйдите из файла. Чтобы эти изменения вступили в силу, перезапустите службу Docker с помощью следующей команды:

systemctl restart docker

Чтобы убедиться, что вы настроили Docker с небезопасными реестрами, используйте следующую команду:

docker info

В конце вывода вы должны увидеть следующую выделенную строку:

OutputContainers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 15
Server Version: 18.06.1-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true

. . .

Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:

127.0.0.0/8
Live Restore Enabled: false

Теперь, когда вы загрузили Jenkins X и настроили реестр Docker, используйте инструмент CLI + jx + для создания кластера Minikube Kubernetes с возможностями CI / CD:

jx create cluster minikube --cpu=5 --default-admin-password=admin --vm-driver=none --memory=13314

Здесь вы создаете кластер Kubernetes, используя Minikube, с флагом + - cpu = 5 + для установки 5 процессоров и + - memory = 13314 + для предоставления вашему кластеру 13314 МБ памяти. Поскольку Jenkins X - надежная, но большая программа, эти спецификации обеспечат беспроблемную работу Jenkins X в этой демонстрации. Кроме того, вы используете + - default-admin-password = admin +, чтобы установить пароль Jenkins X как + admin + и + - vm-driver = none +, чтобы настроить кластер локально, как вы это делали в Шаг 1.

Поскольку Jenkins X раскручивает ваш кластер, вы будете получать различные запросы в разное время в течение всего процесса, которые задают параметры для вашего кластера и определяют, как он будет взаимодействовать с GitHub для управления производственными средами.

Сначала вы получите следующее приглашение:

Output? disk-size (MB) 150GB

Нажмите + ENTER для продолжения. Затем вам будет предложено указать имя, которое вы хотите использовать с git, адрес электронной почты, который вы хотите использовать с git, и ваше имя пользователя GitHub. Введите каждый из них при появлении запроса, затем нажмите + ENTER.

Затем Jenkins X предложит вам ввести свой токен GitHub API:

OutputTo be able to create a repository on GitHub we need an API Token
Please click this URL

Then COPY the token and enter in into the form below:

? API Token:

Введите свой токен здесь или создайте новый токен с соответствующими разрешениями, используя выделенный URL-адрес в предыдущем блоке кода.

Далее Дженкинс Х спросит:

Output? Do you wish to use GitHub as the pipelines Git server: (Y/n)

? Do you wish to use  as the pipelines Git user for GitHub server: (Y/n)

Введите + Y + для обоих вопросов.

После этого Jenkins X предложит вам ответить на следующие вопросы:

Output? Select Jenkins installation type:   [Use arrows to move, type to filter]
>Static Master Jenkins
 Serverless Jenkins

? Pick workload build pack:   [Use arrows to move, type to filter]
> Kubernetes Workloads: Automated CI+CD with GitOps Promotion
 Library Workloads: CI+Release but no CD

Для предыдущего выберите + Static Master Jenkins + и выберите + Kubernetes Workloads: автоматизированный CI + CD с GitOps Promotion + для последнего. Когда будет предложено выбрать организацию для своего репозитория среды, выберите ваше имя пользователя GitHub.

Наконец, вы получите следующий вывод, который проверяет успешную установку и предоставляет ваш пароль администратора Jenkins X.

OutputCreating GitHub webhook for /environment-horsehelix-production for url http://jenkins.jx..nip.io/github-webhook/

Jenkins X installation completed successfully


       ********************************************************

            NOTE: Your admin password is:

       ********************************************************



Your Kubernetes context is now set to the namespace: jx
To switch back to your original namespace use: jx namespace default
For help on switching contexts see: https://jenkins-x.io/developing/kube-context/

To import existing projects into Jenkins:       jx import
To create a new Spring Boot microservice:       jx create spring -d web -d actuator
To create a new microservice from a quickstart: jx create quickstart

Затем используйте команду + js get, чтобы получить список URL-адресов, которые показывают информацию о вашем приложении:

jx get urls

Эта команда выдаст список, подобный следующему:

Name                      URL
jenkins                   http://jenkins.jx..nip.io
jenkins-x-chartmuseum     http://chartmuseum.jx..nip.io
jenkins-x-docker-registry http://docker-registry.jx..nip.io
jenkins-x-monocular-api   http://monocular.jx..nip.io
jenkins-x-monocular-ui    http://monocular.jx..nip.io
nexus                     http://nexus.jx..nip.io

Вы можете использовать URL-адреса для просмотра данных Jenkins X о вашей среде CI / CD через пользовательский интерфейс, введя адрес в браузере и введя свое имя пользователя и пароль. В этом случае это будет «администратор» для обоих.

Затем, чтобы гарантировать, что учетные записи службы в пространствах имен + jx +, + jx-staging + и + jx-production + имеют привилегии администратора, измените ваши политики RBAC с помощью следующих команд:

kubectl create clusterrolebinding jx-staging1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:expose --namespace=jx-staging
kubectl create clusterrolebinding jx-staging2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:default --namespace=jx-staging
kubectl create clusterrolebinding jx-production1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:expose --namespace=jx-productions
kubectl create clusterrolebinding jx-production2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:default --namespace=jx-productions
kubectl create clusterrolebinding jx-binding1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx:expose --namespace=jx
kubectl create clusterrolebinding jx-binding2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx:default --namespace=jx

Теперь, когда вы создали свой локальный кластер Kubernetes со встроенной функциональностью Jenkins X, вы можете перейти к созданию приложения на платформе для тестирования его возможностей CI / CD и использования конвейера Jenkins X.

Шаг 5 - Создание тестового приложения в вашей среде Jenkins X

С вашей средой Jenkins X, настроенной в вашем кластере Kubernetes, теперь у вас есть инфраструктура CI / CD, которая может помочь вам автоматизировать конвейер тестирования. На этом этапе вы попробуете это, настроив тестовое приложение в работающем конвейере Jenkins X.

В демонстрационных целях в этом руководстве будет использоваться пример приложения RSVP, созданного командой CloudYuga. Вы можете найти это приложение вместе с другими материалами вебинара в репозитории DO-Community GitHub.

Сначала клонируйте образец приложения из репозитория с помощью следующей команды:

git clone https://github.com/do-community/rsvpapp.git

После того, как вы клонировали репозиторий, перейдите в каталог + rsvpapp + и удалите файлы git:

cd rsvpapp
rm -r .git/

Чтобы инициализировать репозиторий git и проект Jenkins X для нового приложения, вы можете использовать + jx create +, чтобы начать с нуля или из шаблона, или + jx import +, чтобы импортировать существующее приложение из локального проекта или репозитория git. Для этого руководства импортируйте пример приложения RSVP, выполнив следующую команду в домашнем каталоге приложения:

jx import

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

Поскольку пример приложения RSVP работает на порту + 5000 + своего контейнера, измените файл + charts / rsvpapp / values.yaml +, чтобы он соответствовал этому. Откройте + charts / rsvpapp / values.yaml + в текстовом редакторе:

nano charts/rsvpapp/values.yaml

В этом файле + values.yaml + установите для + service: internalPort: + значение + 5000 +. После внесения изменений ваш файл должен выглядеть следующим образом:

Графики / rsvpapp / values.yaml

# Default values for python.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
image:
 repository: draft
 tag: dev
 pullPolicy: IfNotPresent
service:
 name: rsvpapp
 type: ClusterIP
 externalPort: 80
 internalPort:
 annotations:
   fabric8.io/expose: "true"
   fabric8.io/ingress.annotations: "kubernetes.io/ingress.class: nginx"
resources:
 limits:
   cpu: 100m
   memory: 128Mi
 requests:
   cpu: 100m
   memory: 128Mi
ingress:
 enabled: false

Сохраните и выйдите из файла.

Затем измените + charts / preview / needs.yaml + для соответствия вашему приложению. + needs.yaml + - это файл YAML, в котором разработчики могут объявлять зависимости диаграммы вместе с расположением диаграммы и желаемой версией. Поскольку наше приложение использует MongoDB для базы данных, вам нужно изменить файл + charts / preview / needs.yaml +, чтобы включить MongoDB в качестве зависимости. Откройте файл в текстовом редакторе с помощью следующей команды:

nano charts/preview/requirements.yaml

Отредактируйте файл, добавив запись + mongodb-replicaset + после записи + alias: cleanup +, как это выделено в следующем блоке кода:

графики / просмотр / requirements.yaml

# !! File must end with empty line !!
dependencies:
- alias: expose
 name: exposecontroller
 repository: http://chartmuseum.jenkins-x.io
 version: 2.3.92
- alias: cleanup
 name: exposecontroller
 repository: http://chartmuseum.jenkins-x.io
 version: 2.3.92




 # !! "alias: preview" must be last entry in dependencies array !!
 # !! Place custom dependencies above !!
- alias: preview
 name: rsvpapp
 repository: file://../rsvpapp

Здесь вы указали диаграмму + mongodb-replicaset + как зависимость для диаграммы + preview +.

Затем повторите этот процесс для вашей диаграммы + rsvpapp +. Создайте файл + charts / rsvpapp / needs.yaml + и откройте его в текстовом редакторе:

nano charts/rsvpapp/requirements.yaml

Когда файл открыт, добавьте следующее, убедившись, что до и после заполненных строк есть одна строка пустого пространства:

Графики / rsvpapp / requirements.yaml

dependencies:
- name: mongodb-replicaset
 repository: https://kubernetes-charts.storage.googleapis.com/
 version: 3.5.5

Теперь вы указали диаграмму + mongodb-replicaset + как зависимость для вашей диаграммы + rsvpapp +.

Затем, чтобы подключить внешний интерфейс примера приложения RSVP к бэкэнду MongoDB, добавьте переменную окружения + MONGODB_HOST + в файл + deploy.yaml + в + charts / rsvpapp / templates / +. Откройте этот файл в вашем текстовом редакторе:

nano charts/rsvpapp/templates/deployment.yaml

Добавьте следующие выделенные строки в файл, кроме одной пустой строки вверху файла и двух пустых строк внизу файла. Обратите внимание, что эти пустые строки необходимы для работы файла YAML:

графики / rsvpapp / шаблоны / deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: {{ template "fullname" . }}
 labels:
   draft: {{ default "draft-app" .Values.draft }}
   chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}"
spec:
 replicas: {{ .Values.replicaCount }}
 template:
   metadata:
     labels:
       draft: {{ default "draft-app" .Values.draft }}
       app: {{ template "fullname" . }}
{{- if .Values.podAnnotations }}
     annotations:
{{ toYaml .Values.podAnnotations | indent 8 }}
{{- end }}
   spec:
     containers:
     - name: {{ .Chart.Name }}
       image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"



       imagePullPolicy: {{ .Values.image.pullPolicy }}
       ports:
       - containerPort: {{ .Values.service.internalPort }}
       resources:
{{ toYaml .Values.resources | indent 12 }}

С этими изменениями Helm сможет развернуть ваше приложение с MongoDB в качестве своей базы данных.

Затем, проверьте + Jenkinsfile +, сгенерированный Jenkins X, открыв файл из домашнего каталога вашего приложения:

nano Jenkinsfile

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

Чтобы продемонстрировать это, добавьте настраиваемый тестовый пример, заменив + sh" python -m unittest "+ в + stage ('CI Build and push snapshot') + и + stage ('Build Release') + в + Jenkinsfile + со следующими выделенными строками:

/ Rsvpapp / Jenkinsfile

. . .
 stages {
   stage('CI Build and push snapshot') {
     when {
       branch 'PR-*'
     }
     environment {
       PREVIEW_VERSION = "0.0.0-SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER"
       PREVIEW_NAMESPACE = "$APP_NAME-$BRANCH_NAME".toLowerCase()
       HELM_RELEASE = "$PREVIEW_NAMESPACE".toLowerCase()
     }
     steps {
       container('python') {


         sh "export VERSION=$PREVIEW_VERSION && skaffold build -f skaffold.yaml"
         sh "jx step post build --image $DOCKER_REGISTRY/$ORG/$APP_NAME:$PREVIEW_VERSION"
         dir('./charts/preview') {
           sh "make preview"
           sh "jx preview --app $APP_NAME --dir ../.."
         }
       }
     }
   }
   stage('Build Release') {
     when {
       branch 'master'
     }
     steps {
       container('python') {

         // ensure we're not on a detached head
         sh "git checkout master"
         sh "git config --global credential.helper store"
         sh "jx step git credentials"

         // so we can retrieve the version in later steps
         sh "echo \$(jx-release-version) > VERSION"
         sh "jx step tag --version \$(cat VERSION)"


         sh "export VERSION=`cat VERSION` && skaffold build -f skaffold.yaml"
         sh "jx step post build --image $DOCKER_REGISTRY/$ORG/$APP_NAME:\$(cat VERSION)"
       }
     }
   }
. . .

С добавленными строками конвейер Jenkins X установит зависимости и выполнит тест Python всякий раз, когда вы вносите изменения в свое приложение.

Теперь, когда вы изменили пример приложения RSVP, зафиксируйте и отправьте эти изменения в GitHub с помощью следующих команд:

git add *
git commit -m update
git push

Когда вы отправите эти изменения в GitHub, вы запустите новую сборку вашего приложения. Если вы откроете пользовательский интерфейс Jenkins, перейдя к + http: // jenkins.jx..nip.io + и введя «admin» для своего имени пользователя и пароля, вы найдете информацию о вашей новой сборке. Если вы нажмете «История сборки» в меню в левой части страницы, вы увидите историю ваших совершенных сборок. Если вы щелкнете по синему значку рядом со сборкой, а затем выберите «Консольный вывод» в левом меню, вы найдете выход консоли для автоматизированных шагов в вашем конвейере. Прокрутив до конца этого вывода, вы увидите следующее сообщение:

Output. . .
Finished: SUCCESS

Это означает, что ваше приложение прошло пользовательские тесты и теперь успешно развернуто.

Как только Jenkins X соберет релиз приложения, он переведет приложение в среду + staging +. Чтобы убедиться, что ваше приложение работает, перечислите приложения, запущенные в вашем кластере Kubernetes, с помощью следующей команды:

jx get app

Вы получите вывод, подобный следующему:

OutputAPPLICATION STAGING PODS URL
rsvpapp     0.0.2   1/1  http://rsvpapp.jx-staging..nip.io

Из этого вы можете видеть, что Jenkins X развернул ваше приложение в вашей среде + jx-staging + как версия + 0.0.2 +. В выводе также отображается URL, который вы можете использовать для доступа к своему приложению. Посещение этого URL покажет вам пример приложения RSVP:

изображение: https: //assets.digitalocean.com/articles/cart_64885/Sample_App_jx-staging.png [Пример приложения RSVP в промежуточной среде]

Далее, проверьте активность вашего приложения с помощью следующей команды:

jx get activity -f rsvpapp

Вы получите вывод, подобный следующему:

OutputSTEP                                        STARTED      AGO DURATION STATUS
/rsvpappv/master #1    3h42m23s    4m51s Succeeded Version: 0.0.1
 Checkout Source                          3h41m52s       6s Succeeded
 CI Build and push snapshot               3h41m46s          NotExecuted
 Build Release                            3h41m46s      56s Succeeded
 Promote to Environments                  3h40m50s    3m17s Succeeded
 Promote: staging                         3h40m29s    2m36s Succeeded
   PullRequest                            3h40m29s    1m16s Succeeded  PullRequest: https://github.com//environment-horsehelix-staging/pull/1 Merge SHA: dc33d3747abdacd2524e8c22f0b5fbb2ac3f6fc7
   Update                                 3h39m13s    1m20s Succeeded  Status: Success at: http://jenkins.jx..nip.io/job//job/environment-horsehelix-staging/job/master/2/display/redirect
   Promoted                               3h39m13s    1m20s Succeeded  Application is at: http://rsvpapp.jx-staging..nip.io
 Clean up                                 3h37m33s       1s Succeeded
/rsvpappv/master #2      28m37s    5m57s Succeeded Version: 0.0.2
 Checkout Source                            28m18s       4s Succeeded
 CI Build and push snapshot                 28m14s          NotExecuted
 Build Release                              28m14s      56s Succeeded
 Promote to Environments                    27m18s    4m38s Succeeded
 Promote: staging                           26m53s     4m0s Succeeded
   PullRequest                              26m53s     1m4s Succeeded  PullRequest: https://github.com//environment-horsehelix-staging/pull/2 Merge SHA: 976bd5ad4172cf9fd79f0c6515f5006553ac6611
   Update                                   25m49s    2m56s Succeeded  Status: Success at: http://jenkins.jx..nip.io/job//job/environment-horsehelix-staging/job/master/3/display/redirect
   Promoted                                 25m49s    2m56s Succeeded  Application is at: http://rsvpapp.jx-staging..nip.io
 Clean up                                   22m40s       0s Succeeded

Здесь вы получаете активность Jenkins X для приложения RSVP, применяя фильтр с помощью + -f rsvpapp +.

Далее, перечислите модули, работающие в пространстве имен + jx-staging +, с помощью следующей команды:

kubectl get pod -n jx-staging

Вы получите вывод, подобный следующему:

NAME                                 READY     STATUS    RESTARTS   AGE
jx-staging-mongodb-replicaset-0      1/1       Running   0          6m
jx-staging-mongodb-replicaset-1      1/1       Running   0          6m
jx-staging-mongodb-replicaset-2      1/1       Running   0          5m
jx-staging-rsvpapp-c864c4844-4fw5z   1/1       Running   0          6m

Эти выходные данные показывают, что ваше приложение работает в пространстве имен + jx-staging + вместе с тремя модулями базы данных MongoDB на сервере, придерживаясь изменений, которые вы внесли в файлы YAML ранее.

Теперь, когда вы запустили тестовое приложение через конвейер Jenkins X, вы можете попробовать продвинуть это приложение в производственную среду.

Шаг 6 - Продвижение вашего тестового приложения в другое пространство имен

Чтобы завершить эту демонстрацию, вы завершите процесс CI / CD, продвинув пример приложения RSVP в свое пространство имен + jx-production +.

Во-первых, используйте + jx advance + в следующей команде:

jx promote rsvpapp --version=0.0.2 --env=production

Это продвинет приложение + rsvpapp +, работающее с + version = 0.0.2 +, в производственную среду. На протяжении всего процесса сборки Jenkins X будет предлагать вам ввести информацию о вашей учетной записи GitHub. Ответьте на эти запросы с вашими индивидуальными ответами, как они появляются.

После успешного продвижения проверьте список приложений:

jx get app

Вы получите вывод, подобный следующему:

OutputAPPLICATION STAGING PODS URL                                             PRODUCTION PODS URL
rsvpapp     0.0.2   1/1  http://rsvpapp.jx-staging..nip.io 0.0.2      1/1  http://rsvpapp.jx-production..nip.io

С помощью этой информации «+ PRODUCTION» вы можете подтвердить, что Jenkins X внедрила приложение «+ rsvp» в производственную среду. Для дальнейшей проверки посетите производственный URL + http: // rsvpapp.jx-production..nip.io + в своем браузере. Вы должны увидеть работающее приложение, не запущенное из «производства»:

изображение: https: //assets.digitalocean.com/articles/cart_64885/Sample_App_jx-production.png [Пример приложения RSVP в производственной среде]

Наконец, перечислите ваши модули в пространстве имен + jx-production +.

kubectl get pod -n jx-production

Вы обнаружите, что в этом пространстве имен работают + rsvpapp + и модули MongoDB:

NAME                                     READY     STATUS    RESTARTS   AGE
jx-production-mongodb-replicaset-0       1/1       Running   0          1m
jx-production-mongodb-replicaset-1       1/1       Running   0          1m
jx-production-mongodb-replicaset-2       1/1       Running   0          55s
jx-production-rsvpapp-54748d68bd-zjgv7   1/1       Running   0          1m

Это показывает, что вы успешно внедрили образец приложения RSVP в свою производственную среду, имитируя готовое к развертыванию приложение в конце конвейера CI / CD.

Заключение

В этом руководстве вы использовали Helm для управления пакетами в смоделированном кластере Kubernetes и настроили диаграмму Helm для упаковки и развертывания своего собственного приложения. Вы также настраиваете среду Jenkins X в своем кластере Kubernetes и запускаете пример приложения через конвейер CI / CD от начала до конца.

Теперь у вас есть опыт работы с этими инструментами, которые вы можете использовать при создании системы CI / CD в своем собственном кластере Kubernetes. Если вы хотите узнать больше о шлеме, ознакомьтесь с нашим An Введение в шлем , менеджер пакетов для Kubernetes и How для установки программного обеспечения о кластерах Kubernetes с помощью диспетчера пакетов Helm. Чтобы узнать больше о CI / CD-инструментах в Kubernetes, вы можете прочитать о сервисной сетке Istio в следующем уроке из этой серии вебинаров.

Related