- CICD has become the mainstream of the industry. As a project drive n by Google, Tekton is of great importance
- To be a crab eater, the back waves of the Yangtze River push the front waves and beat the front waves to death on the beach
- In the first stage, we mainly focus on Tekton's official manual to understand the basic usage
- Tekton is closely related to k8s, sometimes interspersed with k8s
- Tekton's positioning can be summarized as follows: next generation engine
- Application scenario example: push the code to GitHub, automatically trigger the following operation: build source code, and then push the image to remote hub
- Create a Task
- Create a Pipeline containing your Tasks
- Use a TaskRun to instantiate and execute a Task outside of a Pipeline
- Use a PipelineRun to instantiate and run a Pipeline containing your Tasks
Creating and running a Task
- A Task defines a series of steps that run in a desired order and complete a set amount of build work. Every Task runs as a Pod on your Kubernetes cluster with each step as its own container. For example, the following Task outputs "Hello World":
- kind:Task etc
- collection of steps as part of CI flow
- A task executes as a Pod on Kubernates cluster
- task available within a specific ns/clusterTask available across the entire cluster
- Learn kubernetes style resources for declaring CI/CD style pipelines
- The pipelines run on Kubernetes like any other process.
- Each step runs as an independent container.
- Tekon run on k8s
Tekton Pipelines is a Kubernetes extension that installs and runs on your Kubernetes cluster. It defines a set of Kubernetes Custom Resources that act as building blocks from which you can assemble CI/CD pipelines. Once installed, Tekton Pipelines becomes available via the Kubernetes CLI (kubectl) and API calls, just like pods and other resources.
- You will learn:
- How to install a private registry with a UI
- How to install the Tekton controller and optional CLI tool
- How to declare resources specific to defining a CI/CD pipeline
- About various Tekton resources like Resources, Tasks, and Pipelines
- How to kick off a pipeline and inspect its progress
- a k8s cluster + helm + prepare k8s dashboard
- install registry+ registry proxies as Node Daemons+ install registry UI
- Build container ->deploy them to registry
- clone JS app
- install tekon
- install tekon dashboard
- install tkn(manage tekon resource)
- Apply ppresource
- Apply two task
- apply pipeline
- need account access private resource
- K8s workflow
- Container registries
- stable helm chart for docker registry
- stable chart
- docker engine on each node
- Tekton is a Kubernetes Operator
- it can be completely administered using the standard Kubernetes manifests using the defined custom resources that have been associated with the Tekton controllers.
- apply command
- A task will run inside a Pod on your cluster.
- Each Tekton task runs as a Kubernetes Pod. Each step in the task runs as a separate container in the task's Pod.
- a task is a Pod
- a k8s cluster
- Helm: package manager is used to install applications on K8S
- kubectl is used to manage cluster s
step by step
- The Docker engine will pull from a "localhost" registry without triggering its security precautions.
- run a kube-registry-proxy on each node in the cluster, exposing a port on the node (via the hostPort value), which Docker accepts since it is accessed by localhost.
- Internal to all the container engines in the cluster, the registry is now available as a service for pushing and pulling container images. Pods can pull images from the registry at http://localhost:5000 and the proxies resolve the requests to https://registry-docker-registry.kube-system:5000.
Pipeline Run Pipeline Tasks Steps Resources
apiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: git spec: type: git params: - name: revision value: master - name: url value: https://github.com/javajon/node-js-tekton
apiVersion: tekton.dev/v1alpha1 kind: Task metadata: name: build-image-from-source spec: inputs: resources: - name: git-source type: git params: - name: pathToContext description: The path to the build context, used by Kaniko - within the workspace default: . - name: pathToDockerfile description: The path to the Dockerfile to build default: Dockerfile - name: imageUrl description: value should be like - us.icr.io/test_namespace/builtImageApp - name: imageTag description: Tag to apply to the built image steps: - name: list-src image: alpine command: - "ls" args: - "$(inputs.resources.git-source.path)" - name: build-and-push image: gcr.io/kaniko-project/executor command: - /kaniko/executor args: - "--dockerfile=$(inputs.params.pathToDockerfile)" - "--destination=$(inputs.params.imageUrl):$(inputs.params.imageTag)" - "--context=$(inputs.resources.git-source.path)/$(inputs.params.pathToContext)/" - "--insecure" - "--insecure-pull" - "--skip-tls-verify" - "--skip-tls-verify-pull"
apiVersion: tekton.dev/v1alpha1 kind: Task metadata: name: deploy-application spec: inputs: resources: - name: git-source type: git params: - name: pathToContext description: The path to the build context, used by Kaniko - within the workspace default: . - name: pathToYamlFile description: The path to the yaml file to deploy within the git source default: deploy.yaml - name: imageUrl description: Url of image repository default: url - name: imageTag description: Tag of the images to be used. default: "latest" steps: - name: update-yaml image: alpine command: ["sed"] args: - "-i" - "-e" - "s;IMAGE;$(inputs.params.imageUrl):$(inputs.params.imageTag);g" - "$(inputs.resources.git-source.path)/$(inputs.params.pathToContext)/$(inputs.params.pathToYamlFile)" - name: deploy-app image: lachlanevenson/k8s-kubectl command: ["kubectl"] args: - "apply" - "-f" - "$(inputs.resources.git-source.path)/$(inputs.params.pathToContext)/$(inputs.params.pathToYamlFile)"
kubectl apply -f task-test.yaml kubectl apply -f pipelineresource.yaml kubectl apply -f taskrun.yaml see TaskRun View the build status based on the status of the resource object kubectl get taskrun see pods state kubectl get pods To view the process of task running kubectl describe pod testrun-pod-mw9bt View the log information of the container to understand the execution result information of the task kubectl logs testrun-pod-mw9bt --all-containers
Create CICD pipeline
A powerful and flexible CI/CD open source cloud native framework
Tekton's predecessor is the build pipeline project of Knative project. This project is to add the function of pipeline to the build module. However, with the addition of different functions to the Knative build module, the build module becomes more and more like a general CI/CD system. Therefore, simply peel the build pipeline out of Knative and become the current Tekton, Since then, Tekton has been committed to providing full-featured and standardized cloud native CI/CD solutions
Create a build pipeline that will run the application's unit tests Build Docker image and push it to Docker Hub
Preparation: K8S cluster available, tekton installation
kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.14.2/release.yaml brew install tektoncd-cli kubectl apply --filename https://storage.googleapis.com/knative-releases/serving/latest/istio.yaml kubectl label namespace default istio-injection=enabled kubectl apply --filename https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml
- Task execution template
- Include steps (responsible for starting the container based on the image to perform operations, and each step is performed by a pod)
- Run task. If you create taskrun, run task
- Pass in the parameters required by task
- Choreograph task
- Run PP, create and run
- Used to share resources between task s
- You can put GIT warehouse information in resource
- Tekton itself is Kubernetes' native choreography system. Therefore, the service account mechanism of Kubernetes can be directly used to realize authentication
Each of these five concepts provides services in the form of CRD
- As an upgraded version of Knative Build module, Tekton provides richer functions and can be applied to more scenarios
Docker Hub configuration
- In order to build Docker image, Docker is generally used. Here is a container, so Docker In Docker mode can be used, but this mode is not safe
- In addition to this way, we can also use the software launched by Google Kaniko Tool, which can build the Docker image in the Kubernetes cluster without relying on the Docker daemon.
- Using Kaniko to build an image is basically the same as the Docker command, so we can set the login credentials of the Docker Hub in advance to facilitate the subsequent push of the image to the image warehouse. The login credentials can be saved into the Secret resource object of Kubernetes, and a new one named Secret. Net can be created Yaml file
- The annotation information is used to tell Tekton the Docker image warehouse to which these authentication information belongs
- icepanel , which can be used to quickly create and visualize our Kubernetes microservice application
A workspace is a way to provide available shared volumes for a pipeline and its tasks in progress.
Define worksapce in the pipeline as a shared volume and pass a related task. The purpose of defining workspace in tekton is as follows:
- Store inputs and / or outputs
- Share data between task s
- Mount point for secret authentication
- Mount point of the configuration saved in ConfigMap
- Mount point of common tools shared by the organization
- Cached build artifacts can speed things up. In short, they are used to cache packages at build time, for example, as Maven repositories
In the pipe, the running results of tasks can be used as the input of other tasks, that is, tasks can generate some results during execution, which can be used as parameter values in subsequent tasks of pipeline. In addition, Tekton will infer the execution order of tasks according to the input parameters to ensure that the tasks that generate results run before those tasks that consume their results.
- k8s custome resource
- process incoming HTTP based events with JSON payloads
- EventListeners expose an addressable "Sink" to which incoming events are directed. (?)
- Users can declare TriggerBindings to extract fields from events, and apply them to TriggerTemplates in order to create Tekton resources.
- In addition, EventListeners allow lightweight event processing using Event Interceptors.
- define a configuration file for an EventListener resource