Shulou(Shulou.com)05/31 Report--

This article shows you how to understand the Knative practice of automated deployment from source code to services, which is concise and easy to understand. I hope you can gain something through the detailed introduction of this article.

Through the previous article, I believe you are already familiar with Serving, Eventing and Tekton. Then in the actual use, we often encounter some complex scenarios, which requires collaborative processing between the various components. For example, can we deploy the service to K8s directly after we submit the source code? This scenario is very attractive to users. So let's take a look at how to implement code-to-service in Knative.

Scene introduction

The current scenario looks like this: code build-> event-driven-> service deployment. Then corresponding to Knative, Eventing, Tekton and Serving need to work together to implement this scenario.

Prepare for

Deploy Knative. Refer to the deployment of Knative on Ali Cloud CCS.

Deploy Tekton. Through the Ali Cloud CCS console, select ack-tekton-pipelines in the application directory to install and deploy Tekton

Deploy the GitHub event source. Select to install the GitHub component in the Knative component management of the Ali Cloud CCS console, as shown below:

From source code to service

Modify branch code, submit merge request for merging to master branch

Eventing listens for merge events and sends them to the GitHub Trigger service

The GitHub Trigger service receives events, performs code builds through Tekton, and performs service deployment through deployer. The role of GitHub Trigger is to parse the details of GitHub events, then convert them into Tekton resources and submit them to Kubernetes to execute Pipeline. Project address: https://github.com/knative-sample/tekton-serving. There are two parts of this project: the role of Trigger and Deployer,Trigger is to parse the github event and submit the PipelineRun definition. The function of Deployer is to update the mirror information of Service. The key elements of github source pull_request body are as follows:

{"action": "closed",. Merge_commit_sha: "f37cb28b1777a28cd34ea1f8df1b7ebcc6c16397",... "base": {"ref": "master",...},...}

Action represents the details of the current pull request event. Action is opened when pull request is created, and action is closed when pull request is closed

Merge_commit_sha can get the id of merge commit

Base.ref can find out on which branch the merge request occurs.

The code and resource file addresses covered in this article:

GitHubTrigger and Deployer: https://github.com/knative-sample/tekton-serving

Deployment sample file: https://github.com/knative-sample/eventing-tekton-serving

And then we started to do it step by step.

Deploy Tekton services

Let's take a look at creating the code to build Task and deploy the service Task.

Code build Task:

ApiVersion: tekton.dev/v1alpha1kind: Taskmetadata: name: source-to-imagespec: 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 (relative to the context) default: Dockerfile-name: imageUrl description: Url of image repository-name: imageTag description: Tag to apply to the built image default: "latest" steps:-name: build-and-push image: registry.cn-hangzhou.aliyuncs.com/knative-sample/kaniko-project-executor:v0.10.0 command: -/ kaniko/executor args:-dockerfile=$ {inputs.params.pathToDockerFile}-destination=$ {inputs.params.imageUrl}: ${inputs.params.imageTag}-context=/workspace/git-source/$ {inputs.params.pathToContext} env:-name: DOCKER_CONFIG value: / builder/home/.docker

Here, the service deployment is performed through deployer-deployer, and the service Task is deployed:

ApiVersion: tekton.dev/v1alpha1kind: Taskmetadata: name: image-to-deployspec: inputs: resources:-name: git-source type: git params:-name: pathToYamlFile description: The path to the yaml file to deploy within the git source-name: imageUrl description: Url of image repository-name: imageTag description: Tag of the images to be used. Default: "latest" steps:-name: deploy image: "registry.cn-hangzhou.aliyuncs.com/knative-sample/deployer-deployer:7620096e" args:-"- namespace=default"-"- serivce-name=hello-sample"-"- image=$ {inputs.params.imageUrl}: ${inputs.params.imageTag}"

In addition, you need to set the secret of the image repository:

ApiVersion: v1kind: Secretmetadata: name: ack-cr-push-secret annotations: tekton.dev/docker-0: https://registry.cn-hangzhou.aliyuncs.comtype: kubernetes.io/basic-authstringData: username: password:

Execute the following command:

# Create Pipelinekubectl apply-f tekton/pipeline/build-and-deploy-pipeline.yaml# Create PipelineResourcekubectl apply-f tekton/resources/picalc-git.yaml# Create image secretkubectl apply-f tekton/image-secret.yaml# Create task: soruce to imagekubectl apply-f tekton/tasks/source-to-image.yaml# Create task: deploy the image to clusterkubectl apply-f tekton/tasks/image-to-deployer.yaml deploy Knative Serving service

First create a deployer-github-trigger service to receive GitHub events and trigger the Tekton Pipeline build task. The service.yaml is as follows:

ApiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata: name: deployer-github-triggerspec: template: spec: containers:-image: registry.cn-hangzhou.aliyuncs.com/knative-sample/deployer-trigger:tekton-v1_74647e3a-20190806093544 args:-trigger-config=/app/config/deployer-trigger.yaml volumeMounts:-name: config-volume mountPath: / app/config ServiceAccountName: tekton volumes:-name: config-volume configMap: name: deployer-trigger-config items:-key: deployer-trigger.yaml path: deployer-trigger.yaml

Here, set the PipelineRun through ConfigMap deployer-trigger-config. Deployer-github-trigger can get the latest information of the code repository based on github Event information, but can not automatically determine the definition of PipelineRun, so you need to specify a template for PipelineRun. Trigger specifies the template of PipelineRun through the-- trigger-config parameter. The template content is as follows:

ApiVersion: v1kind: ConfigMapmetadata: name: deployer-trigger-config namespace: defaultdata: "deployer-trigger.yaml":-apiVersion: tekton.dev/v1alpha1 kind: PipelineRun metadata: name: tekton-kn-sample spec: pipelineRef: name: build-and-deploy-pipeline resources:-name: git-source resourceRef: name: eventing-tekton-serving-git params:- Name: pathToContext value: "src"-name: pathToYamlFile value: ""-name: imageUrl value: "registry.cn-hangzhou.aliyuncs.com/knative-sample/eventing-tekton-serving-helloworld"-name: imageTag value: "1.0" trigger: type: manual serviceAccount: pipeline-account

Execute the command as follows:

# Create clusterrolekubectl apply-f serving/clusterrole.yaml# Create clusterrolebindingkubectl apply-f serving/clusterrolebinding.yaml# Create serviceaccountkubectl apply-f serving/serviceaccount.yaml# Create configmapkubectl apply-f serving/configmap.yaml# Create servicekubectl apply-f serving/service.yaml configure the GitHub event source in Eventing

The code merge request triggers the corresponding event, which is obtained through Knative Eventing and sent directly to the deployer-github-trigger service.

Create GitHub Token

Create a Personal access tokens to access the GitHub API. In addition, your code will use it to validate incoming webhook (secret token) from github. The name of token can be set at will. Source needs to open repo:public_repo and admin:repo_hook to trigger Event events through public repositories and to create webhooks for those public repositories.

The following is an example of setting up a "GitHubSource Sample" token.

Update githubsecret.yaml content. If you generate personal_access_token_value token, you need to set secretToken as follows:

ApiVersion: v1kind: Secretmetadata: name: githubsecrettype: OpaquestringData: accessToken: personal_access_token_value secretToken: asdfasfdsaf

Execute an order to make it effective:

Kubectl apply-f eventing/githubsecret.yaml creates a GitHub event source

In order to receive events generated by GitHub, you need to create a GitHubSource to receive events.

ApiVersion: sources.eventing.knative.dev/v1alpha1kind: GitHubSourcemetadata: name: deployer-github-sourcesspec: eventTypes:-pull_request ownerAndRepository: knative-sample/eventing-tekton-serving accessToken: secretKeyRef: name: githubsecret key: accessToken secretToken: secretKeyRef: name: githubsecret key: secretToken sink: apiVersion: serving.knative.dev/v1alpha1 kind: Service name: deployer-github-trigger

Key field explanation:

Specify the github repository: ownerAndRepository: knative-sample/eventing-tekton-serving indicates the event listening to the https://github.com/knative-sample/eventing-tekton-serving repository

Event type: eventTypes is an array in which the list of github events can be configured

Authentication information: accessToken and secretToken refer to the authentication information of the github repository through secret

The target Service:sink field indicates which Service the received event needs to be sent to, in this case directly to the deployer-github-trigger service defined earlier.

Execute the kubectl command:

Kubectl apply-f eventing/github-source.yaml

If Istio injection is enabled in the cluster, you need to enable egress access:

Kubectl apply-f eventing/egress.yaml

After the deployer-github-sources is submitted to Kubernetes, github source controller will create a webhook under http://github.com/knative-sample/eventing-tekton-serving, and the callback address is the public network address of our github_receive_adapter service.

When pull request occurs in http://github.com/knative-sample/eventing-tekton-serving, it automatically triggers the execution of deployer-github-trigger. Deployer-github-trigger first compiles the image, and then updates the hello-sample service image to complete the automatic release.

Code-> Image-> Service

Let's demonstrate how to automate the build and deployment process from code to service:

Service access experience address: http://hello-sample.default.serverless.kuberun.com

The above is how to understand the Knative practice of automating the deployment of services from source code to services. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.