Migrating from Alauda DevOps Tekton v3 to Alauda DevOps Pipelines
NOTE
- This guide is specifically for migrating from
Alauda DevOps Tekton v3 to Alauda DevOps Pipelines. For upgrading between Alauda DevOps Pipelines versions, please refer to the Pipelines upgrade documentation.
This guide provides detailed steps for smoothly migrating from Alauda DevOps Tekton v3 to Alauda DevOps Pipelines. The upgrade process is designed as a seamless migration to ensure your existing CI/CD pipelines remain unaffected.
TOC
Migration Steps
1. Uninstall Existing Tekton Pipeline Instance and Alauda DevOps Tekton v3
Before starting the upgrade, you need to uninstall the existing Tekton components. Follow these steps:
Important Note: The uninstallation process will not affect your existing Task, TaskRun, Pipeline, and PipelineRun resources. These resources will remain unchanged after the upgrade is complete.
-
Delete Pipeline Instance
$ kubectl delete tektonpipelines.operator.tekton.dev pipeline
-
Verify Pipeline Instance Deletion
$ kubectl get tektonpipelines.operator.tekton.dev pipeline
Ensure the command returns no resources, indicating successful deletion.
-
Uninstall Tekton Operator
$ kubectl delete subscriptions.operators.coreos.com tekton-operator -n tekton-operator
-
Verify Operator Uninstallation
$ kubectl get subscriptions.operators.coreos.com -A | grep tekton
Ensure the command returns no results, indicating successful uninstallation.
2. Deploy Alauda DevOps Pipelines
- Navigate to your cluster's
Administrator -> Application Market Management -> OperatorHub page
- Search for and select Alauda DevOps Pipelines
- Choose the appropriate Channel
WARNING
-
You can only select versions for installation in the pipelines-4.0 Channel.
This is because the Pipeline component versions in other Channels are higher, which may cause incompatibility with the original CI/CD system.
-
Follow the on-screen instructions to complete the deployment
-
Wait for Alauda DevOps Pipelines Operator to be Ready
After the Alauda DevOps Pipelines Operator deployment is complete, it will automatically deploy related components such as Pipelines. You can check the component status using the following commands:
$ kubectl get tektonconfigs.operator.tekton.dev config
$ kubectl get tektonpipelines.operator.tekton.dev pipeline
Wait until both resources show a Ready status before proceeding to the next step.
NOTE
- If you previously used
Tekton only in Alauda Container Platform Builds, you can skip the following steps and use the default configuration of Alauda DevOps Pipelines directly.
3. Configure TektonConfig
NOTE
- If you previously used
Tekton only in Alauda Container Platform Builds, you can skip the following steps and use the default configuration of Alauda DevOps Pipelines directly.
After the Alauda DevOps Pipelines Operator deployment is complete, you need to configure the TektonConfig resource to ensure compatibility with your existing system:
Best Practice: It is recommended to only modify the spec.pipeline section configuration to maintain system stability.
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
name: config
spec:
pipeline:
await-sidecar-readiness: true
disable-creds-init: false
enable-bundles-resolver: true
enable-cluster-resolver: true
enable-custom-tasks: true
enable-git-resolver: true
enable-hub-resolver: true
enable-provenance-in-status: true
enable-step-actions: true
enforce-nonfalsifiability: none
keep-pod-on-cancel: false
metrics.count.enable-reason: false
metrics.pipelinerun.duration-type: histogram
metrics.pipelinerun.level: pipeline
metrics.taskrun.duration-type: histogram
metrics.taskrun.level: task
performance:
disable-ha: false
require-git-ssh-secret-known-hosts: false
running-in-environment-with-injected-sidecars: true
send-cloudevents-for-runs: false
set-security-context: false
trusted-resources-verification-no-match-policy: ignore
# Tekton Operator compatibility configuration
coschedule: workspaces
disable-affinity-assistant: true
enable-api-fields: alpha
enable-cel-in-whenexpression: true
enable-param-enum: true
max-result-size: 8192
results-from: sidecar-logs
options:
disabled: false
configMaps:
# Modify default configuration: init container quotas, runAsUser, image pull timeout
config-defaults:
data:
# Container configuration
default-imagepullbackoff-timeout: 5m
default-pod-template: |
securityContext:
runAsUser: 0
# Resource quota configuration
default-container-resource-requirements: |
place-scripts: # Update 'place-scripts' container resource requirements
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "128Mi"
cpu: "100m"
prepare: # Update 'prepare' container resource requirements
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "256Mi"
cpu: "100m"
working-dir-initializer: # Update 'working-dir-initializer' container resource requirements
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "512Mi"
cpu: "100m"
prefix-scripts: # Update containers starting with 'scripts-' resource requirements
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "128Mi"
cpu: "100m"
prefix-sidecar-scripts: # Update containers starting with 'sidecar-scripts-' resource requirements
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "128Mi"
cpu: "100m"
sidecar-tekton-log-results: # Update 'sidecar-tekton-log-results' container resource requirements
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "128Mi"
cpu: "100m"
addon: {}
chain:
artifacts.oci.format: simplesigning
artifacts.oci.storage: oci
artifacts.pipelinerun.format: in-toto
artifacts.pipelinerun.storage: oci
artifacts.taskrun.format: in-toto
artifacts.taskrun.storage: oci
disabled: false
options: {}
config: {}
dashboard:
options: {}
readonly: false
hub:
options: {}
platforms:
openshift: {}
profile: all
pruner:
disabled: false
keep: 100
resources:
- pipelinerun
schedule: 0 8 * * *
targetNamespace: tekton-pipelines
trigger:
enable-api-fields: stable
options: {}
4. Configure Log Access Permissions
NOTE
- If you previously used
Tekton only in Alauda Container Platform Builds, you can skip the following steps and use the default configuration of Alauda DevOps Pipelines directly.
Since the results-from: sidecar-logs feature is enabled, you need to configure log access permissions for the controller:
Technical Note: This configuration allows the controller to retrieve results information from pod logs. For detailed information, please refer to the Tekton official documentation.
kubectl apply -f - <<EOF
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: tekton-pipelines-controller-pod-log-access
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: default
app.kubernetes.io/part-of: tekton-pipelines
rules:
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: tekton-pipelines-controller-pod-log-access
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/instance: default
app.kubernetes.io/part-of: tekton-pipelines
subjects:
- kind: ServiceAccount
name: tekton-pipelines-controller
namespace: tekton-pipelines
roleRef:
kind: ClusterRole
name: tekton-pipelines-controller-pod-log-access
apiGroup: rbac.authorization.k8s.io
EOF
Migration Complete
After completing the above steps, you have successfully migrated from Alauda DevOps Tekton v3 to Alauda DevOps Pipelines. The new version provides:
- Enhanced system stability
- Richer feature set
- Better performance
- More flexible configuration options
We recommend reviewing the Alauda DevOps Pipelines documentation to understand all the features the new version offers and take full advantage of its capabilities.
