🏗️DevOps: Как да настроите Jenkins Build Agents на Kubernetes през 2023 г.

Чудесен начин за намаляване на цената на CI средата е използването на ефимерен Jenkins агент, базиран на Kubernetes pod, хм. Само ако има заявка за изграждане, агентите на Дженкинс се завъртат. Умен, това е!

Вече обсъдихме как да настроим Jenkins на Kubernetes. В случай, че се интересувате, вижте го тук 👉Разполагане на jenkins в Kubernetes

Как работи Jenkins Agent в Kubernetes?

Защо агентът Дженкинс се присъедини към Kubernetes pod?

Да организира своята контейнерна кариера с малко хумор! 😆

Хуморът настрана позволява да разберем как работи настройката на jenkin agent K8.

1. Когато се задейства задание на Jenkins, плъгинът Jenkins Kubernetes прави извикване на API към Kubernetes, за да създаде K8 agent pod.
2. С някои променливи на обкръжението под пространството на имената се разполага jenkin agent pod.
3. Когато подът на агента се появи, той използва променливите на средата, за да се свърже с главния Jenkins, използвайки нещо, наречено jnlp (Java Network Launch Protocol и се използва от Jenkins за отдалечено стартиране на агенти за изграждане)

Сега според Jenkinsfile, всички стъпки за изграждане се изпълняват на този агент. След като бъде готово, групата се прекратява автоматично, но има опция за запазване на този създаден агент на група.

Освен това, докато k8 клъстерът се мащабира, можете да мащабирате Jenkins build agents без никакъв проблем.

Но първо трябва да настроим приставката Kubernetes на Jenkins. Да видим как!

Конфигурация на плъгин на Jenkins Kubernetes

За да инсталирате плъгина jenkins kubernetes:

1. Отидете на Управление на Jenkins → Управление на добавки

2. потърсете плъгина kubernetes в наличния раздел и го инсталирайте. Забележка: не можете да го видите в горната снимка, тъй като вече съм го инсталирал.

Създайте конфигурация на облак kubernetes със следните стъпки:

1. След инсталиране отидете на Manage Jenkins –› Manage Node & Clouds

2. Щракнете върху Конфигуриране на облаци

3. „Добавяне на нов облак“ изберете Kubernetes.

4. Изберете Подробности за Kubernetes Cloud

За да конфигурирате облака kubernetes на jenkins

Тук имаме два случая

1. Сървър на Jenkins (главен), работещ в същия клъстер на Kubernetes
2. Сървърът на Jenkins (главният) се изчерпва от клъстера Kubernetes.

Да видим първия сценарий

Сървър на Jenkins, работещ в същия клъстер на Kubernetes

Тъй като имаме Jenkins в клъстера на Kubernetes със сервизен акаунт за внедряване на модулите на агента, не е нужно да споменаваме URL адреса на Kubernetes или ключа на сертификата.

Въпреки това, за да потвърдите връзката с помощта на акаунта на услугата, използвайте бутона Тестване на връзката, както е показано по-долу. Трябва да покаже свързано съобщение, ако модулът Jenkins може да се свърже с основния API на Kubernetes.

Забележка:тук използваме пространството от имена kubernates като jenkins (където ще бъде разгърната групата на jenkins agent). Използвам този, в който е разположен Jenkin сървър (главен).

Нека видим сценария, в който jenkins работи на различен клъстер kubernetes или работи извън (някъде другаде) клъстера kubernetes.

Сървър на Jenkins, работещ извън клъстера Kubernetes

Ако вашият Jenkins сървър работи извън клъстера Kubernetes, трябва да посочите следното.

1. URL адрес на Kubernetes: Това е крайната точка на Kubernete master API. Ако https е активиран, използвайте https url.
2. Ключ на Kubernete Server Certificate:Ако имате Kubernetes Cluster CA сертификат, можете да го добавите за защитена връзка. Можете да получите сертификата от всеки работещ pod, който има монтиран акаунт за услуга/var/run/secrets/kubernetes.io/serviceaccount/ca.crt. Ако нямате сертификата, можете да активирате опцията „disable https certificate check“. Или можете да го намерите в /etc/kubernetes/pki/ в главния възел
3. Идентификационни данни: За да може Дженкинс да комуникира с клъстера на Kubernetes, се нуждаем от токен на акаунт за услуга с разрешение за внедряване на подове в пространството от имена devops-tools.

Вече създадохме сервизния акаунт в пространството на имената „jenkins“. Трябва да вземем токена от акаунта на услугата.

Изпълнете следните команди, за да извлечете тайното име от акаунта на услугата.

SECRET_NAME=$(kubectl get serviceaccount jenkins-admin  
  -o=jsonpath='{.secrets[0].name}' -n jenkins)

Сега ще използваме SECRET_NAME, за да получим токена на акаунта на услугата, кодиран в base64, и след това да го декодираме. Ще получите токена като изход.

kubectl get secrets $SECRET_NAME  
  -o=jsonpath='{.data.token}' -n devops-tools | base64 -D

Сега щракнете върху бутона Add под идентификационни данни и създайте тип идентификационни данни „Secret text“. Въведете токена на акаунта на услугата в тайното поле и добавете други подробности, както е показано по-долу. Накрая запазете идентификационните данни.

Облачната конфигурация на Kubernetes ще изглежда така.

След като попълните всички подробности, можете да тествате връзката, за да потвърдите свързаността на клъстера Kubernetes.

Конфигурирайте подробностите за URL адреса на Jenkins със следните стъпки:

За главния Jenkins, работещ вътре в клъстера, можете да използвате крайната точка на услугата на клъстера Kubernetes като URL адрес на Jenkins, тъй като модулите на агентите могат да се свързват към клъстера чрез DNS на вътрешна услуга.

URL адресът се извлича чрез следния синтаксис.

http://<service-name>.<namespace>.svc.cluster.local:8080

В нашия случай услугата DNS ще бъде,

http://jenkins-service.jenkins.svc.cluster.local:8080

Освен това добавете етикета POD, който може да се използва за групиране на контейнерите, ако е необходимо по отношение на изграждане или персонализирани табла за управление.

Забележка:Ако главният Jenkins е извън клъстера на Kubernetes, използвайте IP или DNS на Jenkinsв конфигурацията на URL на Jenkins.

Създаване на POD и шаблон на контейнер:

След това трябва да добавите POD шаблона с подробностите, както е показано на изображението по-долу. Етикетът kubeagent ще бъде използван в заданието като идентификатор за избор на тази група като агент за изграждане. След това трябва да добавим шаблон на контейнер с подробности за изображението на Docker.

Следващата конфигурация е шаблонът на контейнера. Ако не добавите шаблон на контейнер, плъгинът Jenkins Kubernetes ще използва JNLP изображението по подразбиране от Docker hub, за да завърти агентите. т.е. jenkins/inbound-agent

Уверете се, че премахвате аргументите по подразбиране sleep и 9999999 от шаблона на контейнера.

Можем да добавим множество шаблони на контейнери към POD шаблона и да ги използваме в конвейера. Обясних това в следващия раздел с Jenkinsfile примера.

Това е базовата минимална конфигурация, необходима за работа на агента. Ще обясня няколко случая на използване на обеми и други опции по-късно в примерите за конвейер.

Сега запазете всички конфигурации и нека тестваме дали можем да изградим работа с под агент.

Тествайте агента с Freestyle Project:

В описанието на длъжността добавете етикета buildagent, както е показано по-долу. Това е етикетът, който присвоихме на шаблона на pod. По този начин Дженкинс знае кой шаблон на pod да използва за контейнера на агента.

Добавете стъпка за изграждане на обвивка с команда echo, за да потвърдите заданието, както е показано по-долу.

Сега запазете конфигурацията на заданието и щракнете върху „Изграждане сега“

Трябва да видите чакащ агент в хронологията на изграждането на задания, както е показано по-долу.

След няколко минути ще видите успешна компилация. Ако проверите регистрационните файлове, той ще ви покаже изпълнената обвивка.

Jenkinsfile с шаблон на Pod

Каквото и да сме виждали досега, е да разберем и потвърдим настройката на приставката kubernetes jenkins.

Когато става въпрос за действителен проект, по-добре е да имате POD шаблоните в Jenkinsfile.

Ето какво трябва да знаете за POD шаблона.

1. По подразбиране изображение на JNLP контейнер се използва от приставката за свързване към сървъра на jenkins. Можете да замените с персонализирано JNLP изображение, при условие че дадете името jnlp в шаблона на контейнера.
2. Можете да имате множество шаблони на контейнери в един шаблон на под. След това всеки контейнер може да се използва в различни етапи на тръбопровода.
3. POD_LABEL ще присвои произволен етикет на компилация към групата, когато компилацията се задейства. Не можете да давате други имена освен POD_LABEL.

Ето примерен Jenkinfile с POD шаблон.

podTemplate{
  node(POD_LABEL){
    stage('Run shell'){
        sh 'echo hellow world'
     }
  }
}

Ако изградите горния Jenkinsfile в задание на pipleline, той ще използва JNLP изображението по подразбиране и ще изпълни командите в етапа „Run Shell“. Когато казвам по подразбиране, JNLP изображението от докер хъба ще се използва от плъгина, ако не посочите такъв.

Сега можете да използвате нашето собствено jnlp изображение с помощта на шаблон на контейнер с всички необходими инструменти за изграждане и да ги използвате в процеса, както е дадено по-долу.

podTemplate( containers: [
    containerTemplate(
      name: "jnlp",
      image: "jenkins/inbound-agent:latest"
    )
  ])
{
  node(POD_LABEL){
    stage('Get a Maven project'){
      container('jnlp'){
        stage('Shell Execution'){
          sh '''
            echo "Hello world"
            '''
        }

      }

    }

  }

}

Шаблон за под с няколко контейнера

Можете да използвате множество шаблони на контейнери в един шаблон на POD.

Ето един случай на използване на тази настройка.

Да приемем, че искате да настроите един конвейер за изграждане, който изгражда както java, така и python проект. В този случай можете да използвате два шаблона за контейнери и да ги използвате в етапите на изграждане.

В примера по-долу, в два отделни етапа, ние извикваме два различни контейнера, посочени в шаблона на pod.

Един контейнер съдържа всички зависимости на maven за изграждане на java, а друг съдържа зависимости на изграждане на python.

podTemplate( containers: [
  containerTemplate(
    name: "maven",
    image: "maven:3.8.1-jdk-8",
    command: 'sleep',
    args: '30d'
  ),
  containerTemplate(
    name: "python",
    image: "python:latest",
    command: "sleep",
    args: "30d"
  )
])
{
  node(POD_LABEL){
    stage("Get a maven project"){
      git: "https://github.com/spring-projects/spring-petclinic.git"
      container("maven"){
        stage("Build a Maven project"){
           sh '''
              echo "maven build"
              '''
        }
      }
    }

    stage('Get a python project'){
      git url: 'https://github.com/hashicorp/terraform.git', branch: 'main'
      container('python'){
        stage('Build a go project'){
          sh '''
              echo "Go Build"
            '''
        }
      }
    }
  }
}

Можете да опитате да създадете горния Jenkinsfile, като използвате заданието за конвейер.

Докато изграждате горния тръбопровод, ако поставите отметка на kubernetes pods, ще видите три контейнера в build agent pod.

Забележка: Не можете да използвате директно изображения на Docker hub поради съответствие със сигурността в реални проекти. Така че трябва да създадете свои собствени Docker изображения и да ги хоствате в одобрения от организацията регистър на контейнерите.

Използване на споделени постоянни томове с Jenkins Docker Agent Pods

За да ускорите процеса на изграждане, по-добре е да прикачите споделен постоянен том към контейнера за изграждане.

Например, ако вземете java приложение, то има много зависимости от maven.

Когато изграждате java приложенията, той изтегля зависимости, добавени в pom.xml от отдалеченото хранилище на maven за първи път, и създава локална .m2 кеш директория, където се кешират зависимите пакети.

Кешът .m2 не е възможен в компилации, базирани на Docker агент, тъй като се унищожава след компилацията.

Можем да създадем постоянен том за кеша на maven и да го прикачим към агентния модул чрез шаблон на контейнер, за да разрешим този проблем.

За да демонстрираме това, нека първо създадем PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: maven-repo-storage
  namespace: jenkins
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Ето примерен Jenkinsfile с POD шаблон, който използва постоянния том maven-repo-storage.

podTemplate( containers: [
    containerTemplate(
      name: 'maven',
      image: 'maven:latest',
      command: 'sleep',
      args: '99d'
    )
  ],
  volumes:[
    persistentVolumeClaim(
      mountPath: '/root/.m2/repository',
      claimName: 'maven-repo-storage',
      readOnly: false
    )
  ]
)
{
   node(POD_LABEL){
      stage("Build petclinic java app"){
        git url: 'https://github.com/spring-projects/spring-petclinic.git', branch: 'main'
        container('maven'){
          sh 'mvn -B -ntp clean package -DskipTests'
        }
      }

   }
}

И ето ни края на тази статия.

В тази статия обсъдихме основната подчинена архитектура на Jenkins, как да я настроим на kubernetes с агенти за изграждане. И накрая направи някаква работа чрез скриптове за изпълнение на тях (задачи) на агенти за изграждане.

След това ще видим как да създаваме и изпращаме докер изображения. Накратко обработка на Docker изображения на Jenkins.

Ако харесвате работата ми, винаги сте добре дошли да ме последвате или да ме подкрепите. 🙂