Запуск Сборок, Требующих Демона Docker В Jenkins, Установленного С Помощью Helm И Работающего Как Контейнер Контейнера.

  • Автор темы Kopeyko
  • Обновлено
  • 19, Oct 2024
  • #1

Jenkins устанавливается с использованием официальной управляющей диаграммы в кластере Kubernetes, который использует containerd as container runtime.

Как настроить контейнерные агенты, которые будут запускать клиентские команды Docker, например. для создания образов докеров.

На узлах Kubernetes нет демона докера. Есть ли возможность использовать клиент контейнера, который будет взаимодействовать с сервером контейнера на узлах? Идея аналогична случаю, когда клиент Docker внутри контейнера взаимодействует с демоном Docker, работающим на узле.

Я также думаю о следующих вариантах для агентов Jenkins:

Есть ли лучшая практика?

#docker #jenkins #kubernetes #docker-in-docker #containerd

Kopeyko


Рег
09 May, 2007

Тем
70

Постов
206

Баллов
586
  • 25, Oct 2024
  • #2

Есть способы сделать это, но мне не удалось это сделать. Я бы рекомендовал обойти проблему, используя Канико. Вы можете добавить специально созданный контейнер kaniko в свой podTemplate агента сборки k8s и позволить ему обрабатывать часть рабочей нагрузки по сборке (и отправке) контейнера без необходимости использования демонов докеров или сокетов.

У меня это работает хорошо, и я также использую Jenkins через Helm на k8s.

 
 
 pipeline {

agent {

label 'builder' // Refers to the custom k8s pod template defined in the jenkins helm chart values.yaml

}

environment {

RELEASE_TAG = "1.0.0"

}

stages {

stage('Build') {

steps {

container('builder') { // refers to the 'builder' container within the 'builder' agent pod

echo "do a maven build or whatever other steps you need to take here"

}

container('kaniko') { // refers to the 'kaniko' container within the 'builder' agent pod sharing the same workspace

/kaniko/executor --dockerfile `pwd`/dockerfile --context `pwd` --destination=${DOCKER_REPOSITORY}:${RELEASE_TAG}

}

}

}

}
}
 
agent.podTemplates section.

Вот фрагмент моей диаграммы руля

apiVersion: v1 kind: ConfigMap metadata: name: docker-config namespace: jenkins data: config.json: |- { "credsStore": "ecr-login" }

Обратите внимание, что агент «строитель» содержит 2 контейнера (на самом деле 3, включая контейнер по умолчанию «jnlp», который обрабатывает связь с контроллером jenkins), и они используют общее рабочее пространство: yaml: |- field because it was the only way I could find to mount a volume containing the configMap needed by kaniko for docker authorization, Обратите внимание, что я использовалссылка на конфигурацию

agent: namespace: jenkins podTemplates: builder: | - name: 'builder' label: 'builder' serviceAccount: jenkins nodeUsageMode: EXCLUSIVE yamlMergeStrategy: "merge" yaml: |- apiVersion: v1 kind: Pod metadata: name: builder namespace: jenkins spec: serviceAccountName: jenkins containers: - name: builder image: builder:latest imagePullPolicy: IfNotPresent command: ["sleep"] args: ["99d"] tty: true resources: requests: cpu: 1 memory: 1Gi limits: cpu: 2 memory: 2Gi workingDir: /home/jenkins/agent - name: kaniko image: gcr.io/kaniko-project/executor:debug imagePullPolicy: IfNotPresent command: ["sleep"] args: ["99d"] tty: true volumeMounts: - name: docker-config mountPath: /kaniko/.docker workingDir: /home/jenkins/agent env: - name: DOCKER_REPOSITORY value: "private_docker_repository" volumes: - name: docker-config configMap: name: docker-config

. Поэтому я также kubectl сначала применил простую конфигурацию docker-config в пространстве имен jenkins, прежде чем применять эту управляющую диаграммуvalues.yaml..

Узнайте больше о том, что вам нужно для конфигурации docker.

values.yaml
 

Shvets


Рег
28 May, 2020

Тем
63

Постов
212

Баллов
567
Тем
403,760
Комментарии
400,028
Опыт
2,418,908

Интересно