С полной версией поддержки Kubernetes для Docker Desktop я решил обновить свое руководство по локальной разработке с помощью Jenkins. Новое предложение значительно упрощает локальную работу локального кластера Kubernetes.
Настройте рабочий стол Docker для Windows для запуска Kubernetes. Не забудьте изменить настройки, чтобы предоставить Docker немного больше ресурсов и поделиться своими дисками.
Чтобы упростить отладку развертываний в кластере, я разверну панель управления Kubernetes с помощью команды helm.
helm install --wait --name k8s-dash --set service.type=NodePort,service.nodePort=31111 stable/kubernetes-dashboard
Я столкнулся с несколькими проблемами при установке панели управления Kubernetes. Во-первых, helm кэширует диаграммы локально, и, поскольку я установил другую версию диаграммы более года назад, я столкнулся с проблемой попытки использовать последние параметры для старой диаграммы. Чтобы решить эту проблему, запустите обновление репозитория helm, чтобы получить последние диаграммы. Вторая проблема заключалась в доступе к пользовательскому интерфейсу в Chrome, который не мог расшифровать сертификат SSL со следующей ошибкой.
You cannot visit localhost right now because the website sent scrambled credentials that Chrome cannot process.
Чтобы исправить это, я выполнил ответ https://stackoverflow.com/a/31900210/5732682. Я бы никогда не включил это на производственном сервере, и вы тоже.
После того, как все будет установлено и настроено, вы сможете посетить https: // localhost: 31111 и получить доступ к пользовательскому интерфейсу Dashboard.
Затем мы хотим развернуть Jenkins в кластере и настроить его для локальной разработки.
view rawjenkins-helm-values.yaml hosted with ❤ by GitHub
view rawpvc.yaml hosted with ❤ by GitHub
Раньше я использовал плагин File System SCM для мониторинга и использования локальной папки для сборок. Но есть более простое решение, которое работает почти так же хорошо, и не требует установки дополнительных плагинов. Мы можем использовать путь к папке к локальному репозиторию git, как если бы это был удаленный репозиторий. Единственная проблема с этим способом заключается в том, что Jenkins будет использовать только сервер git для изменений, а не для изменений локальных файлов, поэтому вам нужно будет проверить изменения локально, прежде чем сборка сможет их забрать. Но я заметил, что производительность намного выше, если использовать только git и не полагаться на файловую систему для отслеживания изменений.
Docker Desktop с Kubernetes монтирует локальные общие тома в / host_mount / {DRIVE_LETTER} / в средах Windows. Конфигурация агента - это отдельная конфигурация модуля, для которой нужен собственный путь к исходному коду.
Есть и другие изменения, облегчающие жизнь, которые я реализовал с момента последнего написания конфигурации. Во-первых, это отключение безопасности для локальной разработки в строке 6. Это удаляет часть входа в систему Jenkins и дает бонус в виде отсутствия необходимости каждый раз искать пароль администратора. Я также увеличил ресурсы агента по умолчанию, строка 52. Возникла проблема, когда Kubernetes завершал работу модуля после достижения пределов ресурсов агента и завершал сборку с ошибкой. Это было исправлено увеличением лимитов.
Чтобы избежать времени раскрутки и необходимости загружать все плагины в хранилище, я использую PersistentVolumeClaim, который выделяется заранее. Таким образом, каждый раз, когда я удаляю воссоздать экземпляр Jenkins, не так много времени задержки его вызова. Иногда необходимо удалить и воссоздать том, и это можно сделать с помощью простой команды kubectl.
Я иногда сталкивался с проблемой, что постоянный том не может быть привязан к модулю, что, как я подозреваю, связано с тем, что у меня был старый постоянный том в кластере из предыдущей конфигурации Jenkins, который, возможно, мешал привязке нового тома в капсулу. Я только что очистил свои постоянные тома, удалив их из пользовательского интерфейса, или вы можете использовать kubectl для их удаления. После этого я удалил развертывание Jenkins и повторно развернул как Persistent Volume, так и Jenkins.
На этом мы завершаем быструю и простую настройку Jenkins на Kubernetes локально.
Перевод статьи с сайта: https://medium.com/@garunski/jenkins-and-kubernetes-with-docker-desktop-53a853486f7c
Настройте рабочий стол Docker для Windows для запуска Kubernetes. Не забудьте изменить настройки, чтобы предоставить Docker немного больше ресурсов и поделиться своими дисками.
Чтобы упростить отладку развертываний в кластере, я разверну панель управления Kubernetes с помощью команды helm.
helm install --wait --name k8s-dash --set service.type=NodePort,service.nodePort=31111 stable/kubernetes-dashboard
Я столкнулся с несколькими проблемами при установке панели управления Kubernetes. Во-первых, helm кэширует диаграммы локально, и, поскольку я установил другую версию диаграммы более года назад, я столкнулся с проблемой попытки использовать последние параметры для старой диаграммы. Чтобы решить эту проблему, запустите обновление репозитория helm, чтобы получить последние диаграммы. Вторая проблема заключалась в доступе к пользовательскому интерфейсу в Chrome, который не мог расшифровать сертификат SSL со следующей ошибкой.
You cannot visit localhost right now because the website sent scrambled credentials that Chrome cannot process.
Чтобы исправить это, я выполнил ответ https://stackoverflow.com/a/31900210/5732682. Я бы никогда не включил это на производственном сервере, и вы тоже.
После того, как все будет установлено и настроено, вы сможете посетить https: // localhost: 31111 и получить доступ к пользовательскому интерфейсу Dashboard.
Затем мы хотим развернуть Jenkins в кластере и настроить его для локальной разработки.
| Master: | |
| ImageTag: "2.141" | |
| ServiceType: NodePort | |
| NodePort: 32222 | |
| UseSecurity: false | |
| InstallPlugins: | |
| - kubernetes:1.12.4 | |
| - workflow-aggregator:2.5 | |
| - credentials-binding:1.16 | |
| - git:3.9.1 | |
| - blueocean:1.8.2 | |
| - timestamper:1.8.10 | |
| - greenballs:1.15 | |
| - cobertura:1.12.1 | |
| ScriptApproval: | |
| - method groovy.json.JsonSlurperClassic parseText java.lang.String | |
| - method java.util.Collection toArray | |
| - method org.jenkinsci.plugins.workflow.support.actions.EnvironmentAction getEnvironment | |
| - new groovy.json.JsonSlurperClassic | |
| - staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods first java.lang.Object[] | |
| - staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods leftShift java.util.Map java.util.Map | |
| - staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods split java.lang.String | |
| - staticMethod org.kohsuke.groovy.sandbox.impl.Checker checkedCall java.lang.Object boolean boolean java.lang.String java.lang.Object[] | |
| - staticMethod org.kohsuke.groovy.sandbox.impl.Checker checkedGetProperty java.lang.Object boolean boolean java.lang.Object | |
| InitScripts: | |
| JobRelationshipManager: |- | |
| import jenkins.model.Jenkins | |
| import org.jenkinsci.plugins.workflow.job.WorkflowJob | |
| import hudson.plugins.git.GitSCM | |
| def jobs = hudson.model.Hudson.instance.getAllItems(org.jenkinsci.plugins.workflow.job.WorkflowJob)*.fullName | |
| if('JobRelationshipManager' in jobs) { | |
| println 'JobRelationshipManager already defined' | |
| } else { | |
| WorkflowJob job = Jenkins.instance.createProject(WorkflowJob, 'JobRelationshipManager') | |
| GitSCM scm = new GitSCM("/code/jobrm/websiteui") | |
| def flowDefinition = new org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition(scm, "Jenkinsfile.local") | |
| job.definition = flowDefinition | |
| Jenkins.instance.reload() | |
| } | |
| Agent: | |
| Enabled: true | |
| ImageTag: alpine | |
| resources: | |
| requests: | |
| cpu: "500m" | |
| memory: "512Mi" | |
| limits: | |
| cpu: "1000m" | |
| memory: "1024Mi" | |
| volumes: | |
| - type: HostPath | |
| hostPath: /host_mnt/e/code | |
| mountPath: /code | |
| - type: HostPath | |
| hostPath: /var/run/docker.sock | |
| mountPath: /var/run/docker.sock | |
| rbac: | |
| install: true | |
| Persistence: | |
| ExistingClaim: jenkins-pvc | |
| volumes: | |
| - name: source-code | |
| hostPath: | |
| path: /host_mnt/e/code | |
| mounts: | |
| - mountPath: /code | |
| name: source-code |
| kind: PersistentVolumeClaim | |
| apiVersion: v1 | |
| metadata: | |
| name: jenkins-pvc | |
| spec: | |
| accessModes: | |
| - ReadWriteOnce | |
| resources: | |
| requests: | |
| storage: 8Gi | |
| storageClassName: hostpath | |
| selector: | |
| matchLabels: | |
| app: "jenkins" | |
| matchExpressions: | |
| - {key: release, operator: In, values: [jenkins]} |
Раньше я использовал плагин File System SCM для мониторинга и использования локальной папки для сборок. Но есть более простое решение, которое работает почти так же хорошо, и не требует установки дополнительных плагинов. Мы можем использовать путь к папке к локальному репозиторию git, как если бы это был удаленный репозиторий. Единственная проблема с этим способом заключается в том, что Jenkins будет использовать только сервер git для изменений, а не для изменений локальных файлов, поэтому вам нужно будет проверить изменения локально, прежде чем сборка сможет их забрать. Но я заметил, что производительность намного выше, если использовать только git и не полагаться на файловую систему для отслеживания изменений.
Docker Desktop с Kubernetes монтирует локальные общие тома в / host_mount / {DRIVE_LETTER} / в средах Windows. Конфигурация агента - это отдельная конфигурация модуля, для которой нужен собственный путь к исходному коду.
Есть и другие изменения, облегчающие жизнь, которые я реализовал с момента последнего написания конфигурации. Во-первых, это отключение безопасности для локальной разработки в строке 6. Это удаляет часть входа в систему Jenkins и дает бонус в виде отсутствия необходимости каждый раз искать пароль администратора. Я также увеличил ресурсы агента по умолчанию, строка 52. Возникла проблема, когда Kubernetes завершал работу модуля после достижения пределов ресурсов агента и завершал сборку с ошибкой. Это было исправлено увеличением лимитов.
Чтобы избежать времени раскрутки и необходимости загружать все плагины в хранилище, я использую PersistentVolumeClaim, который выделяется заранее. Таким образом, каждый раз, когда я удаляю воссоздать экземпляр Jenkins, не так много времени задержки его вызова. Иногда необходимо удалить и воссоздать том, и это можно сделать с помощью простой команды kubectl.
Я иногда сталкивался с проблемой, что постоянный том не может быть привязан к модулю, что, как я подозреваю, связано с тем, что у меня был старый постоянный том в кластере из предыдущей конфигурации Jenkins, который, возможно, мешал привязке нового тома в капсулу. Я только что очистил свои постоянные тома, удалив их из пользовательского интерфейса, или вы можете использовать kubectl для их удаления. После этого я удалил развертывание Jenkins и повторно развернул как Persistent Volume, так и Jenkins.
На этом мы завершаем быструю и простую настройку Jenkins на Kubernetes локально.
Перевод статьи с сайта: https://medium.com/@garunski/jenkins-and-kubernetes-with-docker-desktop-53a853486f7c