Shulou(Shulou.com)06/03 Report--

Guide reading

The concept of cloud native is becoming more and more popular. As one of the typical technologies, micro-service architecture, in the past, we also said that it is a double-edged sword, bringing certain benefits, at the same time, the technical requirements of the service team have also been greatly improved. However, with the continuous development of open source technology, more and more excellent technologies and tools have emerged to make it easier for the cloud to land on the ground. To this end, Boyun Research Institute will irregularly summarize and sort out the best practices related to cloud native development, testing, operation and maintenance, with the help of the joint efforts of Bo Yun and the open source community, to help customers standardize and simplify the way to cloud nativism.

Background

Developing micro-service based on Spring Boot framework and deploying it in Kubernetes cluster is the technology selection for many enterprises to implement micro-service. Under the micro-service architecture, developers mainly focus on the micro-services maintained by their service team, which usually rely on the micro-services developed by other teams, as well as by another set of micro-services.

In the process of micro-service development, a traditional approach is to verify the code through unit testing, find problems as early as possible, and deploy to the Kubernetes cluster for joint debugging after the development of related services is basically completed. In this way, on the one hand, developers spend a lot of time designing test cases, writing test code, and piling for each dependent service; on the other hand, because the time of integration is relatively late, problems caused by a large number of interface inconsistencies may break out in the process of integration testing, resulting in a waste of manpower and material resources.

If the service is deployed to the Kubernetes test environment for joint debugging testing as soon as possible, the problem can be found in advance. Because the deployment process needs to be executed repeatedly in the development process, many enterprises have built CICD tools. The more common process is: submit code-> Jenkins pull source code-> Maven compilation-> Docker image build-> deploy-> test. Although the process can be completed automatically, each debugging needs to go through this step, which takes a long time and is very inefficient. At the same time, the characteristic of the micro-service within the Kubernetes cluster is that the micro-services can access each other within the cluster, and there is no good way to obtain the internal functions of the cluster outside the cluster, such as reading and writing data in the database, so it is difficult to observe the running results of the service, and it is impossible to provide the same local single-step debugging experience as a single application.

Telepresence is an open source software that provides rapid localized development capabilities for the Kubernetes micro services framework. Telepresence deploys a two-way network agent in a Pod running in a Kubernetes cluster, which proxies data from Kubernetes environments (such as TCP connections, environment variables, volumes) to local processes. The local process transparently overrides its network so that DNS calls and TCP connections are routed to the remote Kubernetes cluster through proxies and can obtain the resources of the remote K8S cluster. This tool can achieve:

Local services have full access to other services in the remote cluster; local services have full access to Kubernetes's environment variables, and remote services running in Secrets and ConfigMap;K8S have full access to local services. Practice

1. Install the kubectl command line tool and configure the Kubernetes cluster to be accessed locally.

Install Telepresence tools

The Telepresence tool can be installed in OS X using the following command.

# deploy Demo micro service on brew cask install osxfuse# brew install datawire/blackbird/telepresence

Deploy microservices in the Kubernetes cluster of the integrated test environment.

# kubectl get allNAME READY STATUS RESTARTS AGEdemo-backend-7bb6cf9994-9qnxp 1 9qnxp 1 Running 0 118sdemo-frontend-84b7f5c75f-8r69n 1 Running 0 40hNAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGEservice/demo-backend ClusterIP 10.233.55.68 8080/TCP 40hservice/demo-frontend NodePort 10.233.17.241 8081:30001/TCP 40hNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGEdeployment.apps/demo-backend 1 1 1 40hdeployment.apps/demo-frontend 1 1 1 40hNAME DESIRED CURRENT READY AGEreplicaset.apps/demo-backend-7bb6cf9994 1 1 1 40hreplicaset.apps/demo-frontend-84b7f5c75f 1 1 1 40h

Access the application through the NodePort access application exposed by Kubernetes to verify that there is no problem with the service.

# curl http://10.20.1.71:30001/Message from backend is: Hello from demo-backend-7bb6cf9994-9qnxp starts the local service through the Telepresence tool # cd spring-cloud-kubernetes/demo-backend/# telepresence\-mount / tmp/known\-swap-deployment demo-backend\-- docker-run\-- rm\-v $(pwd): / build\-v $HOME/.m2/repository:/m2\- V=/tmp/known/var/run/secrets:/var/run/secrets\-p 8080 mvn 8080\-p 5005 mvn 5005\ Xdebug-Xrunjdwp:transport=dt_socket Server=y,suspend=n,address=5005 "\-Dmaven.repo.local=/m2\-f / build\ spring-boot:run

The parameters are analyzed in detail as follows.

Telepresence: command to start telepresence

-- mount / tmp/known: tell Telepresence to mount TELEPRESENCE_ROOT to the local / tmp/known directory

-- swap-deployment foo: assuming that we have run a Deployment named foo in the cluster, the next step will be to replace it with a locally running process

-- docker-run: tell Telepresence to run as a Docker container next

-- rm: tells Docker to discard previously created containers when terminating, without causing confusion to the local area

-v$ (pwd): / build: Mount the current directory (the result of the pwd command) to the folder / build within the Docker container, which is also the location of the local source code

-v $HOME/.m2/repository:/m2: install the Maven cache folder so that we don't have to download the Maven component every time we run the container

-v=/tmp/known/var/run/secrets:/var/run/secrets: Mount the secrets directory under the above local / tmp/known directory to the / var/run/secrets path of the local container. Tools like Fabric8 Kubernetes Client can read Secretes information through this directory, just as if the container is running inside Kubernetes.

-p 8080rig 8080-p 5005vir 5005: expose the service port of the local container and access it when you need to make a request directly to the service.

Maven:3.6-jdk-8-alpine: this is the image we will use to build and run our service, which includes tools such as Maven and Java 8

Mvn... Spring-boot:run: the command to run in the Docker container. Here it uses the Spring Boot Maven plug-in, but you can use any command you need to build the tool. It tells maven to point to the installed repository cache and where the source code is located

-Dspring-boot.run.jvmArguments= "- Xdebug-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005": means to open the 5005 remote debugging port for the service. In the Telepresence document, the Debug configuration is passed through the MAVEN_OPTS parameter, which actually turns on Debug mode for the Maven process, not a demo-backend application, and cannot provide remote single-step debugging capability.

-Dmaven.repo.local=/m2: indicates the location of the local Maven repository

The home directory where f / build:Maven was built, that is, the root directory of the source code

Goal released by the spring-boot:run:spring-boot-maven-plugin plug-in, which is used to launch Spring Boot applications.

View the Pod information in the Kubernetes cluster. As you can see, the previous Pod demo-backend-7bb6cf9994-9qnxp has been replaced by a new container, using the image provided by Telepresence.

# kubectl get podNAME READY STATUS RESTARTS AGEdemo-backend-c9df931b5c83411aad5a329ec9ecbcbb-5b4fdd7b-wzz9r 1/1 Running 0 11sdemo-frontend-84b7f5c75f-8r69n 1/1 Running 0 40h

View the local Docker operation.

# docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESc7c10281a32c maven:3.6-jdk-8-alpine "/ usr/local/bin/mvn-..." 35 seconds ago Up 33 seconds telepresence-1555471863-056155-58429fd94d372f832 datawire/telepresence-local:0.98 "/ sbin/tini-v-- py …" 44 seconds ago Up 43 seconds 0.0.0.0 5005/tcp 5005-> 5005/tcp, 0.0.0.0 5005/tcp 8080-> 8080/tcp, 127.0.0.1 5005/tcp 64163-> 38022/tcp telepresence-1555471853-8663979-58429

Verify that ports 8080 and 5005 are open locally.

# netstat-na | grep-E "5005 | 8080" tcp6 00:: 1.5005 * .* LISTENtcp4 00 * .5005 * .* LISTENtcp6 00:: 1.8080 * .* LISTENtcp4 00 * .8080 *. * LISTEN

Access the local demo-backend service directly through port 8080.

# curl localhost:8080Hello from demo-backend-c9df931b5c83411aad5a329ec9ecbcbb-5b4fdd7b-wzz9r

Through the NodePort access application exposed by Kubernetes, you can see that the request to demo-backend has been forwarded to the locally running docker.

# curl http://10.20.1.71:30001Message from backend is: Hello from demo-backend-80d454f85d8b43118f5740d9f25260ba-854fcd9fbd-lzkb7 launches IDEA through code development and single-step debugging through IDE, and opens the project on the above source code path.

Configure remote debugging to connect to local port 5005.

Set breakpoints and access the application, which can be debugged step by step in IDEA.

Modify the code and save it, then click Build-> Build Project.

In the pom file of the demo-backend project, the dependency of devtools is configured.

Org.springframework.boot spring-boot-devtools true

When IntelliJ IDEA is rebuilt, the file demo-backend/target/classes in that directory is updated. When the application is launched through mvn spring-boot:run, the classpath that Devtools listens to, that is, the above directory, will launch restart and execute the new code when the files in the directory change.

. _ _ _ (() _ _ _ )'| _ |. _ _ | _ | | _ | _ | | _\ _ _ | | / = | _ | = | _ _ / = / _ /:: Spring Boot:: (v2.1.3.RELEASE) 11restartedMain 17purl 44.328 [restartedMain] INFO c.b.s.c.k.b.KubernetesBackendApplication-Starting KubernetesBackendApplication on Waret with PID 58351 (/ Users/Waret87/WorkSpace/telepresence/spring-cloud-kubernetes/demo-backend/target/classes started by Waret87 in / Users/Waret87/WorkSpace/telepresence/spring-cloud-kubernetes/demo-backend) | 11RV 17RU 44.331 [restartedMain] INFO c.b.s.c.k.b.KubernetesBackendApplication-No active profile set Falling back to default profiles: default...11:17:45.931 [restartedMain] INFO o.s.b.w.e.tomcat.TomcatWebServer-Tomcat started on port (s): 8080 (http) with context path''11 Tomcat started on port 17 JVM running for 45.934 [restartedMain] INFO c.b.s.c.k.b.KubernetesBackendApplication-Started KubernetesBackendApplication in 1.873 seconds (JVM running for 2.282) 11 20 JVM running for 35.483 [Thread-6] INFO o.s.s.c.ThreadPoolTaskExecutor-Shutting down ExecutorService 'applicationTaskExecutor'. _ _ _ (() _ _ _ )'| _ |. _ _ | _ | | _ | _ | | _\ _ _ | | / = | INFO c.b.s.c.k.b.KubernetesBackendApplication-Starting KubernetesBackendApplication on Waret with PID 58351 (/ Users/Waret87/WorkSpace/telepresence/spring-cloud-kubernetes/demo-backend/target/classes started by Waret87 in / Users/Waret87/WorkSpace/telepresence/spring-cloud-kubernetes/demo-backend) | _ _ / = / _ /:: Spring Boot:: (v2.1.3.RELEASE) 11hand20 INFO c.b.s.c.k.b.KubernetesBackendApplication 36.838 [restartedMain] 1120 restartedMain 36.838 [restartedMain] INFO c.b.s.c.k.b.KubernetesBackendApplication-No active profile set Falling back to default profiles: default...11:20:37.272 [restartedMain] INFO o.s.b.w.e.tomcat.TomcatWebServer-Tomcat started on port (s): 8080 (http) with context path''11 restartedMain 20 restartedMain 37.272 [restartedMain] INFO c.b.s.c.k.b.KubernetesBackendApplication-Started KubernetesBackendApplication in 0.467 seconds (JVM running for 173.62)

Visit the service again and you can see that the new code has taken effect.

# curl http://10.20.1.71:30001Message from backend is: Hello World from demo-backend-c9df931b5c83411aad5a329ec9ecbcbb-5b4fdd7b-wzz9r summary

Through the above practice, we can see that the Telepresence project solves the problem of connection between development testing and deployment, and is a good supplement to the Kubernetes ecological environment. The project has been donated to the CNCF Foundation, and the community documentation is relatively complete. For more detailed principles and usage, please refer to the documentation.

This article is originally published by Boyun Research Institute. Please indicate the source when reproduced.

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.