Создание Python pipeline с использованием template
Этот pipeline предназначен для автоматизации полного CI/CD workflow для Python-приложений. Он является повторно используемым и гибким, поддерживает пользовательские аргументы сборки, несколько workspace и условное выполнение шагов.
Основные возможности:
- ✅ Гибкий источник кода
- 🔌 Подключаемые задачи через params
- 🛠️ Динамическая сборка и push image
- ☁️ Обновление image workload через kubectl
Содержание
Указание с помощью hub resolversПараметрыGit ClonePre buildSonarQube ScannerBuild ImagesTrivy ScannerDeploy or upgrade workloadWorkspacesPlatformsИспользованиеМинимальная настройка: запуск end-to-end с минимальными параметрамиКонфигурация свойств SonarQubeDeploy or upgrade workloadЗапуск pytestПропуск задач с помощью ParamsПолный пример со всеми задачамиУказание с помощью hub resolvers
В следующем примере PipelineRun ссылается на pipeline из каталога:
Параметры
Git Clone
-
git-url
- type: string
- default:
"" - description: URL репозитория, из которого выполняется clone.
-
git-revision
- type: string
- default:
"" - description: Ревизия для checkout (branch, tag, sha, ref и т. д.).
-
skip-git-clone
- type: string
- default:
"false" - description: Пропустить выполнение задачи git clone. Ее можно включить только если соответствующий репозиторий кода уже существует в workspace.
-
git-crt-file-name
- type: string
- default:
"ca-bundle.crt" - description: Имя файла mounted crt, используемого через workspace ssl-ca-directory. Значение по умолчанию: ca-bundle.crt.
Pre build
-
pre-build-script
- type: string
- default: ""
- description: Python script, который будет выполнен перед build. Его можно использовать для unit test, lint, запуска script перед build и т. д. Task
pre-buildбудет пропущена, если этот параметр не задан.
-
pre-build-args
- type: array
- default:
[] - description: Аргументы, передаваемые в pre-build script.
-
pre-build-requirements-file
- type: string
- default:
"requirements.txt" - description: Имя файла requirements в исходном расположении, с резервным использованием файла requirements в корневом расположении.
-
pre-build-pip-conf-file
- type: string
- default:
"pip.conf" - description: Имя пользовательского файла конфигурации pip.
SonarQube Scanner
-
sonar-url
- type: string
- default:
"" - description: URL вашего экземпляра SonarQube Server. Если не указан, task sonarqube scanner будет пропущена.
-
sonar-project-key
- type: string
- default:
"" - description: Уникальный ключ проекта SonarQube.
-
sonar-properties
- type: array
- default:
["sonar.sources=."] - description: Дополнительные свойства для передачи в SonarQube. Дополнительные сведения см. в разделе Configuration of SonarQube properties.
Build Images
-
images
- type: array
- description: Ссылка на images, которые будет создавать buildah. Может содержать несколько адресов image, разделенных запятыми. Например:
- busybox:latest
- busybox:v1 .30.1
-
containerfile-path
- type: string
- default: ./Containerfile
- description: Путь к Containerfile для build.
-
build-extra-args
- type: string
- default: ""
- description: Дополнительные параметры, передаваемые в команду build при сборке images. ВНИМАНИЕ — должны быть очищены, чтобы избежать command injection (например, --build-arg key=value --label key=value).
-
build-args
- type: array
- default: [""]
- description: Указывает аргумент build и его значение, которое будет подставлено в инструкции, прочитанные из Containerfile, так же как переменные окружения, но не будет добавлено в список переменных окружения в конфигурации результирующего image. например HTTP_PROXY=http://10.10.10.10:8080
-
build-context
- type: string
- default: .
- description: Путь к директории, используемой в качестве context.
-
push-extra-args
- type: string
- default: ""
- description: Дополнительные параметры, передаваемые в команду push при push images. ВНИМАНИЕ — должны быть очищены, чтобы избежать command injection (например, --creds=username:password ).
Trivy Scanner
-
skip-trivy-scan
- type: string
- default: "false"
- description: Установите, чтобы пропустить scan image с помощью trivy после build.
-
trivy-extra-args
- type: string
- default: ""
- description: Дополнительные параметры, передаваемые в команду trivy при scan images. ВНИМАНИЕ — должны быть очищены, чтобы избежать command injection (например, --insecure). Можно использовать
--skip-db-update--skip-java-db-update, чтобы пропустить обновление базы уязвимостей.
Deploy or upgrade workload
-
workload-name
- type: string
- default: ""
- description: Имя workload для deploy или upgrade. Если не указано, task
deploy-or-upgradeбудет пропущена.
-
workload-kind
- type: string
- default: Deployment
- description: Тип workload для deploy или upgrade, например Deployment, StatefulSet и т. д.
-
workload-namespace
- type: string
- default: ""
- description: Namespace workload для deploy или upgrade. Если не указан, будет использован namespace текущего TaskRun.
-
workload-container
- type: string
- default: []
- description: Этот параметр используется для указания контейнеров внутри workload, image которых требуется обновить. По умолчанию будут обновлены image всех контейнеров в workload.
-
workload-rollout-timeout
- type: string
- default: "0"
- description: Время ожидания перед завершением ожидания готовности workload;
0означает никогда. Любые другие значения должны содержать соответствующую единицу времени (например, 1s, 2m, 3h).
-
workload-manifests-dir
- type: string
- default: ""
- description: Манифест workload для deploy. Если он не указан, будет обновлено только image workload, который уже находится в cluster. Можно использовать относительный путь к директории манифестов в workspace
source. Например: "manifests".
Workspaces
- source: Workspace для обмена информацией между задачами.
- git-basic-auth: Необязательный workspace, содержащий файлы .gitconfig и .git-credentials. Они будут скопированы в home пользователя перед выполнением любых команд git. Любые другие файлы в этом Workspace игнорируются. По возможности настоятельно рекомендуется использовать ssh-directory вместо basic-auth и привязывать Secret к этому Workspace вместо других типов volume.
- git-ssh-directory: Необязательный workspace с private key, known_hosts, config и т. д. Скопируется в home пользователя перед выполнением команд git. Используется для аутентификации с git remote при выполнении clone. Настоятельно рекомендуется привязывать Secret к этому Workspace вместо других типов volume.
- git-ssl-ca-directory: Необязательный workspace с CA certificates; будет использоваться Git для проверки peer при получении или push по HTTPS.
- pip-conf: Необязательный workspace с пользовательскими настройками pip.
- sonar-settings: Необязательный workspace, в который можно смонтировать свойства SonarQube.
- sonar-credentials: Необязательный workspace с учетными данными для использования в SonarQube.
- registryconfig: Необязательный workspace для файлов конфигурации distribution registry, таких как
config.jsonили.dockerconfigjson. Он необязателен и используется для аутентификации при push images в registry. - kubeconfig: Необязательный workspace с файлом kubeconfig. Имя kubeconfig должно быть
kubeconfig. Если в этом workspace нет kubeconfig, workspace будет проигнорирован.
Platforms
Task может выполняться на платформах linux/amd64 и linux/arm64.
Использование
Минимальная настройка: запуск end-to-end с минимальными параметрами
Необязательные задачи (sonarqube-scanner, deploy-or-upgrade и т. д.) будут корректно пропущены, если они не заданы или опущены.
Конфигурация свойств SonarQube
Вы можете смонтировать workspace sonar-settings или использовать параметр sonar-properties, чтобы применить свойства для файла sonar-project.properties.
Свойства по умолчанию: sonar.sources=..
Ознакомиться с использованием свойств SonarQube можно в разделе analysis parameters и the properties for Python
Ниже приведены некоторые свойства, которые можно задать:
Deploy or upgrade workload
Вы можете deploy или upgrade workload, используя image, собранный задачей build-image в этом pipeline.
Установив параметр workload-manifests-dir, можно применить Kubernetes manifests из указанной директории, чтобы создать или обновить workload.
Поддерживаются форматы JSON и YAML. Все манифесты в указанной директории будут обработаны с помощью kubectl apply. Обратите внимание, что kubectl apply не проходит по подкаталогам.
Если в директории содержится файл конфигурации Kustomize (например, kustomization.yaml, kustomization.yml или Kustomization), он будет обработан с помощью kubectl kustomize.
Ниже приведен пример структуры workload-manifests-dir:
Можно настроить следующие параметры:
Если вы не хотите deploy workload с использованием manifests, просто оставьте параметр workload-manifests-dir пустым. В этом случае task будет только обновлять image существующего workload в cluster.
Необходимо управлять image pull secrets для workload. Если новый image размещен в другом registry, убедитесь, что для вашего workload создан и настроен соответствующий pull secret.
Запуск pytest
Вы можете запустить pytest с помощью task pre-build в этом pipeline.
Вот пример запуска pytest:
Пропуск задач с помощью Params
Pipeline поддерживает пропуск задач с помощью params:
Полный пример со всеми задачами
В этом примере показано, как использовать все task в pipeline. Он включает следующие задачи:
- clone исходного кода
- запуск unit test с помощью task pre-build
- сборку image и push image в registry
- scan image с помощью Trivy
- scan code с помощью SonarQube
- deploy или upgrade workload