preface

This article mainly introduces you to configuration management and service isolation in Nacos multi environment from the following points

• What is the Namespace of Nacos

• Business status and pain points

• Introduction to environmental isolation scheme

• Configure synchronization management scheme

What is the Namespace of Nacos

Nacos is a popular microservice configuration center and registry service component at this stage. It introduces the concept of Namespace for configuration management and service isolation in multiple environments. In the team, each member can also share a Nacos service to share Nacos resources by opening up a personal Namespace.

Business status and pain points

• Each developer builds Nacos locally, and the environment is not unified, which is inconvenient for management.

Solution: build a shared Nacos to isolate the environment of developers through Namespace.

• The development environment, test environment and production environment have their own Nacos. It is inconvenient to modify the configuration manually one by one.

Solution: build gitlab pipeline and call Nacos API through script for configuration synchronization

• At present, the configuration file is in json format. After modification, it is impossible to judge whether the syntax is correct. After modification, it is lack of judgment on the health status of the service

Solution: through Python - M JSON Tool performs syntax verification and health status detection according to the returned value by calling the service interface.

Let's solve these pain points step by step

Introduction to environmental isolation scheme

Before solving these pain points, we first need to understand the environmental isolation scheme.

• The multi tenant oriented scheme recommended by Nacos is as follows:

From the perspective of multiple tenants, each tenant may have its own namespace, and the configuration data and registered service data of each tenant will belong to its own namespace, so as to realize data isolation among multiple tenants.

For example, three tenants are allocated, namely Zhang San, Li Si and Wang Wu. Zhang San is in charge of project A, Li Si is in charge of project B, and Wang Wu is in charge of project C

After allocation, each tenant logs in with their own account name and password and creates their own namespace. As shown in the figure below:

Nacos uses Namespace to isolate services and configurations between multiple tenants, and it has good scalability

• As the business becomes larger, you can also Group environments through groups.

Assuming that the company develops rapidly and its business is adjusted, Zhang San is responsible for projects A, B and C, Li Si is responsible for projects D, E and F, and Wang Wu is responsible for projects G, H and I,

Each project is divided into three environments: dev, test and prod. it is inconvenient to continue to use the previous namespace isolation tenant scheme. At this time, you can add a Group to the namespace to Group the project environment, as shown in the figure:

• However, when the business scale is larger, the number of projects > the number of environments) can be grouped by Group, as shown in the following figure:

Through the above theoretical analysis, it can be seen that the scheme has good scalability.

Let's practice it through script.

Configure synchronization management scheme

1. Developers create shared nacos

Write the user account to users, and it will be automatically after submitting the master branch

Create a namespace on shared Nacos.

The API of Nacos is implemented through script calls. The following two key APIs are introduced

Nacos API survey

• Create namespace API

Request type POST

Request path / nacos/v1/console/namespaces

Request parameters (string type)

• customNamespaceId namespace ID (required)
• namespaceName namespace name (required)
• namespaceDesc namespace description

Request example:

curl -X POST 'http://localhost:8848/nacos/v1/console/namespaces'-d 'customNamespaceId=&namespaceName=dev&namespaceDesc='

• Publish configuration API

Request type POST

Request URL/nacos/v1/cs/configs

Request parameters (string type)

• Tenant tenant information, corresponding to the namespace ID field of Nacos
• dataId configuration ID (required)
• Group configuration group (required)
• Content configuration content (required)
• Type configuration type

Request example:

curl -X POST 'http://127.0.0.1:8848/nacos/v1/cs/configs'-d 'dataId=nacos.example&group=com.alibaba.nacos&content=contentTest'

Implementation code

Create a Namespace by looping through the users in users, and create a configuration by reading the data in nacos-conf.json

# Automatically create namespaces based on users
if [ $CI_COMMIT_BRANCH = "master" ]; then
    namespace=($(cat users))
    for url in ${nacos_url[@]}; do
        for ns in ${namespace[@]}; do
        echo create namespace:$ns namespace
        ## Create namespace
        curl -X POST "${url}/nacos/v1/console/namespaces" -d "customNamespaceId=${ns}&namespaceName=${ns}&namespaceDesc=${ns}"
        echo
        done
    done    
## Automatic publishing configuration
    namespace=($(cat users))
    config=$(cat nacos-conf.json)
    dataId=gateway-route.properties
    group=DEFAULT_GROUP
    for url in ${nacos_url[@]}; do
        echo ${url}
        echo ${namespace[@]}
        for ns in ${namespace[@]}; do
            echo ${url}
            echo ${namespace[@]}
            echo create dataId:$dataId in namespace:$ns group:$group
            curl --location --request POST "${url}/nacos/v1/cs/configs?tenant=${ns}&dataId=${dataId}&group=${group}"   --form "content=$config"
            echo
        done
    done

fi

2. Submit the modified configuration to the branch and publish it to the corresponding environment

Variables bound to different environments according to branches

Implementation code

if [ $CI_COMMIT_BRANCH = "master" ]; then
    export nacos_url=(
        nacos.test.com:8848
        ...
        ...
    )
    export CHECK_URL=(
        http://api-test.yizhoucp.cn/api/lanling/login
        ...
        ...
    )
fi

3. Grammar check and health check

• Check whether json format is legal

Example gitlab CI YML is as follows

stages: 
  - deploy-nacos
deploy-nacos:
  stage: deploy-nacos
  tags: 
    - nacos
  image: nacos-check:alpine3.14
  script:
    - cat nacos-conf.json |python -m json.tool
    - ./nacos.sh
  only:
    refs:
      - master
      - deploy-test
      - deploy-prod

The image used here needs to contain python and curl. An example Dockerfile is as follows

FROM python:3.9.9-alpine3.14
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories && apk add --no-cache git curl bash ca-certificates
CMD     ["/bin/sh"]

• health examination

By requesting the previously defined service interface, the return field with code is regarded as available, otherwise it fails.

## health examination
    for CHECK in ${CHECK_URL[@]}; do
        echo  -----$CHECK
        CMD=`curl  ${CHECK} 2>/dev/null | grep -E 'code' | wc -l`
        if [ ${CMD} -eq 1 ]; then
            echo "Succ: Check proxy ${CHECK} is succeed."
    #        exit 0
        else
            echo "Fail: check proxy ${CHECK} is failed."
            export erro_var=1
        fi
    done
fi

# echo $erro_var

if [ ${erro_var} -eq 1 ]; then
    exit 1
fi

summary

The above analyzes the practical scheme of Nacos using Namespace for environmental isolation, and carries out the experiment of automatic configuration synchronization code, which meets the expected requirements.

Reference and thanks: Nacos official manual,Namespace,endpoint best practices