it-swarm.com.ru

Как интегрировать GitLab-Ci с Azure Kubernetes + Kubectl + ACR для развертываний?

Наш предыдущий CI/CD на основе GitLab использовал запрос аутентификации curl к определенной конечной точке API REST, чтобы инициировать повторное развертывание обновленного контейнера в нашем сервисе, если вы используете нечто подобное для своего развертывания на основе Kubernetes, этот вопрос для вас.

Больше фона

Мы запускаем рабочий сайт/приложение (на основе блога Ghost) в кластере Azure AKS. Прямо сейчас мы вручную отправляем наши обновленные контейнеры в частный ACR (реестр контейнеров Azure), а затем выполняем обновление из командной строки с помощью Kubectl.

При этом мы ранее использовали Docker Cloud для нашей оркестровки и полностью интегрировали повторное развертывание наших производственных/промежуточных сервисов с использованием GitLab-Ci.

Именно интеграция GitLab-Ci является целью, и «почему» стоит за этим вопросом.

Мой вопрос

Так как мы ранее использовали Docker Cloud (до, должно быть, K8s с самого начала), как мы должны учитывать тот факт, что GitLab-Ci смог использовать Secrets, создал CLI Docker Cloud и затем прошел аутентификацию с помощью Docker Cloud API для запуска действий на наших узлах (т. е. повторно развернуть с новыми контейнерами и т. д.).

Хотя я полагаю, что мы можем построить контейнер (который будет использоваться нашим бегуном GitLab-Ci), который содержит Kubectl и интерфейс командной строки Azure, я знаю, что у Kubernetes также есть аналогичный (для облака докеров) API-интерфейс Rest, который можно найти здесь ( https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster ) - в частности, раздел, в котором говорится о подключении БЕЗ Kubectl, кажется уместным (как и часть о HTTP REST API).

Мой вопрос ко всем, кто подключается к Azure (или, возможно, к другой управляемой службе Kubernetes):

Каким образом ваш сервер Ci/CD проходит проверку подлинности на сервере управления вашего поставщика услуг Kubernetes, и как вы в настоящее время инициируете обновление/повторное развертывание обновленного контейнера/службы?

Если вы использовали API-интерфейс Kubernetes HTTP Rest для повторного развертывания службы, ваши мысли будут особенно полезны!

Kubernetes Resources Я рассматриваю

  1. Как мне управлять развертыванием с kubernetes
  2. Kubernetes Deployments

Буду обновлять по мере прохождения процесса.

10
Necevil

Создание интеграции

У меня была такая же проблема, как интегрировать GitLab CI/CD с моим кластером Azure AKS Kubernetes. Я создал этот вопрос потому что у меня была какая-то ошибка, когда я пытался добавить свою информацию о Kubernetes cluester в GitLab.

Как их интегрировать:

  1. Внутри GitLab перейдите в меню «Операции»> «Кубернетес».
  2. Нажмите кнопку «Добавить кластер Kubernetes» в верхней части страницы.
  3. Вам нужно будет заполнить некоторые поля формы, чтобы получить содержимое, которое вы должны поместить в эти поля, подключиться к своей учетной записи Azure из интерфейса командной строки (вам нужно установить Azure CLI на вашем ПК) с помощью команды az login, а затем выполнить эту другую команду получить учетные данные кластера Kubernetes: az aks get-credentials --resource-group <resource-group-name> --name <kubernetes-cluster-name>
  4. Предыдущая команда создаст файл ~/.kube/config, откроет этот файл, содержимое полей, которые вы должны заполнить в форме GitLab «Добавить кластер Kubernetes», находится внутри этого файла .kube/config

Это поля:

  1. Имя кластера Kubernetes: Это имя вашего кластера в Azure, оно также находится в файле .kube/config
  2. API URL: Это URL в поле server файла .kube/config.
  3. CA Сертификат: Это поле certificate-authority-data файла .kube/config, но вам придется декодировать его base64.

После того, как вы расшифруете его, оно должно выглядеть примерно так:

-----BEGIN CERTIFICATE-----
...
some base64 strings here
...
-----END CERTIFICATE-----
  1. Token: Это строка шестнадцатеричных символов в поле token файла .kube/config (может также понадобиться декодировать base 64?). Вам нужно использовать токен, принадлежащий учетной записи с привилегиями cluster-admin, чтобы GitLab мог использовать его для аутентификации и установки чего-либо в кластере. Самый простой способ добиться этого - создать новую учетную запись для GitLab: создать файл YAML с определением учетной записи службы (пример можно увидеть здесь в Создать учетную запись службы gitlab в пространстве имен по умолчанию) и примените его к вашему кластеру с помощью kubectl apply -f serviceaccount.yml.
  2. Пространство имен проекта (необязательно, уникально): Я оставляю его пустым, пока не знаю, для чего или где это пространство имен можно использовать.

Нажмите «Сохранить» и все готово. Ваш проект GitLab должен быть подключен к вашему кластеру Kubernetes.

Развертывание

В вашем задании развертывания (в конвейере) вам понадобятся некоторые переменные среды для доступа к вашему кластеру с помощью команды kubectl, вот список всех доступных переменных:

https://docs.gitlab.com/ee/user/project/clusters/index.html#deployment-variables

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

  • Вы, должно быть, правильно добавили кластер Kubernetes в свой проект GitLab, меню «Операции»> «Kubernetes» и эти шаги, которые я описал выше
  • Ваша работа должна быть «задачей развертывания», в GitLab CI, чтобы считаться задачей развертывания, ваше определение работы (в вашем .gitlab-ci.yml) должно иметь ключ environment (взгляните на строку 31 в этом примере ) и имя среды должно совпадать с именем, которое вы использовали в меню «Операции»> «Среды».

Вот пример .gitlab-ci.yml с тремя этапами:

  • Build: он создает образ докера и отправляет его в личный реестр gitlab
  • Test: он еще ничего не делает, просто введите exit 0, чтобы изменить его позже
  • Deploy: загрузите стабильную версию kubectl, скопируйте файл .kube/config, чтобы иметь возможность запускать команды kubectl в кластере, и выполните kubectl cluster-info, чтобы убедиться, что он работает. В моем проекте я не закончил писать сценарий развертывания, чтобы действительно выполнить развертывание. Но эта команда kubectl cluster-info выполняется нормально.

Совет: чтобы посмотреть на все переменные среды и их значения (у Дженкинса есть страница с этим представлением, а у GitLab CI), вы можете выполнить команду env в сценарии стадии развертывания. Это очень помогает отладить работу.

22
lmcarreiro

Сегодня я вошел в наш бэкэнд GitLab-Ci и увидел кнопку «Kubernetes» - вместе с предложением сэкономить 500 долларов на GCP. 

 $500 at GCP with GitLab-Ci Kubernetes

ГитЛаб Кубернетес

URL, чтобы попасть на страницу вашего репозитория Kubernetes GitLab: https://gitlab.com/^your-repo^/clusters

По мере прохождения процесса интеграции я буду обновлять этот ответ (но также приветствую!).

Официальные документы по интеграции GitLab Kubernetes

https://docs.gitlab.com/ee/user/project/clusters/index.html

0
Necevil