The use of Springboot application configuration in k8s cluster of microservice series articles

In fact, Docker deployment can also map the configuration file directory to the host in docker run or dockerfile, and then modify the parameters through the host configuration file.

FROM docker.io/python:3.6MAINTAINER tianye
# 设置容器时间
RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo 'Asia/Shanghai' >/etc/timezone
ENV LANG C.UTF-8         # 设置编码
ENV PATH=$PATH:/usr/local/lib/python3.6/    
ENV PYTHONPATH $PATH     # 配置环境变量

ENV PARAMS=""      # 给我们要传的参数一个初始值
ARG VERSION=1.20

#代码添加到code文件夹
ADD ./tttt/ /test/code/tttt/
#设置code文件夹为工作目录
WORKDIR /test/code/tttt/
CMD python3 ttt.py $PARAMS

In many cases, variables need to be defined in the Dockerfile to reduce the modification of the Dockerfile, and parameters are passed in from the outside when compiling. In this case,  ARGparameters can be used and then --build-argassigned.

For example: the following parameter variable VERSION of Dockerfile is passed in from the outside, when building the image, use --build-arg VERSION=version number to pass

docker build -f  dockerfile/server_dockerfile.v5.0.1 -t server:v5.0.1 zcbus_server --build-arg VERSION=v5.0.1 -e PARAMS="我是参数"

 We implement parameter passing here through environment variables, where -e PARAMS="I am a parameter", PARAMS is specified in the Dockerfile.

What about the k8s? Pod objects are randomly created in the cluster, and local volumes are basically not used for file storage. They all use distributed file systems (FastDFS) or object storage (MinIO). It seems that there is no place to put configuration files. So do I have to throw the online configuration into the configuration file in the program before going online?

The answer is definitely no.

In fact, those who have done operation and maintenance and development at the same time may know that the yml file of springboot actually supports the loading of operating system environment variables.

For example:

redis:
    port: 16379
    host: 36.134.204.163

The above is a common redis configuration. In fact, it can also be as follows:

redis:
    port: ${REDIS_PORT:16379}
    host: ${REDIS_HOST:36.134.204.163}

When the machine is running, there is actually no effect.

So what does the second wording mean?

Here we are going to talk about system environment variables. Remember how JavaHome is configured? That is actually an environment variable.

The environment variable is a global parameter variable configured in the system, and any program can directly read the value of the environment variable through the system interface.

The above writing is, if there is a REDIS_PORT environment variable parameter setting in the system, then use this setting, if not, then use 16379 as the default value. The host is also a reason.

There are REDIS_HOST environment variable parameter settings in the system

Remove the REDIS_HOST environment variable parameter in the  external system

1. Configure all configuration items in the service that need to be decoupled as environment variables + default values.

2. Provide the list of environment variables to the k8s operation and maintenance personnel, and he will configure the yml file deployed by k8s according to the list, add the corresponding environment variable settings through env under spec, and change them to the settings in the k8s environment.

k8s will output the parameters under the env configuration to the environment variables of the container, and the service will take effect when it is directly read. Thus achieving decoupling.

In fact, this method is recommended. The development team can use standardized forms to process information such as mysql, redis, mq, and nacos in a unified manner. Basically, it will not affect the local development and testing work of developers. At the same time, it will not increase the burden on k8s operation and maintenance personnel.

    spec:
      containers:
      - args: []
        env:
        - name: RUNTIME_ENV
          value: 'prd'
        - name: DATASOURCE_IP
          value: '192.168.0.60'
        - name: DATASOURCE_PORT
          value: '3306'
        - name: DATASOURCE_USERNAME
          value: 'root'
        - name: DATASOURCE_PASSWORD    #数据库密码

In fact, there is another way. After testing, the env configuration of deploy will rewrite the value of the key corresponding to yml in springboot.

So we can actually write it directly like this:

      env:
        - name: spring.redis.host
          value: '192.168.216.219' 
        - name: spring.redis.port
          value: '6379'
        - name: spring.redis.password
          value: '123456'

 So in the java service that starts the container under k8s, the 192.168.216.219 configured by k8s takes effect.

The original configuration in the jar package is overwritten.

This method feels simpler than Solution 1, but there are actually some problems. For example, the levels of yml in different projects are different, and the names of configuration items may be different. For k8s administrators, it is not easy to deploy projects through a unified yaml template, and you need to check with the R&D personnel every time.