Location>code7788 >text

How to smoothly migrate from nacos to r-nacos?

Popularity：304 ℃/2024-07-22 08:48:24

1. Introduction

Many students learn about the features of r-nacos and then use r-nacos only for development and testing environments at first.

After a period of time, some students have the intention of generating environments that also migrate from nacos to r-nacos.

Some students who previously used the nacos service are planning to migrate from nacos to r-nacos after learning about r-nacos.

So how do you migrate from nacos to r-nacos in a balanced way?

r-nacos Synopsis:

r-nacos is a nacos service implemented in rust. Compared to java nacos, it is a service that provides the same functionality, starts faster, takes up less system resources (initial memory is less than 10M), has higher performance and runs more stably.

r-nacos is designed to be fully compatible with the latest version of nacos client sdk-oriented protocols (including the http OpenApi, and the grpc protocol), to support the use of nacos services applications migrate to r-nacos.

2. Migration plans

2.1 Content analysis to be migrated

The goal of the migration has been defined and we need to analyze the data to be migrated before designing the migration plan.

Migrating from nacos to r-nacos involves 4 main types of data:

  1. nacos authenticated user data
  2. Namespace data
  3. Configuration data
  4. Service Instance Data

nacos user data, namespace data, and configuration data are persistent data and need to be set up and migrated beforehand.
The service instance data is dynamic and should be automatically registered after switching without prior migration.

2.2 Migration phases and steps

We can categorize migration into 3 stages:

  1. Pre-migration preparation phase;
  2. Migration phase;
  3. Post-migration close-out phase;

I. Pre-migration preparation

  1. Deploy r-nacos for data migration and data entry before migration. (If nacos and r-nacos are on the same machine, you can start r-nacos with a temporary port number and then update the port number and restart it when you migrate.)
  2. Enter the user information that the application depends on in the r-nacos console to complete the user data initialization.
  3. Enter namespace data in the r-nacos console;
  4. Export the full amount of data by namespace from the nacos console (one file will be exported for each namespace); then import this part of the configuration data into the corresponding namespace through the r-nacos console respectively to complete the configuration data migration.

II. On the move

Once the data migration is complete you can start the cutover migration.

Cutting application request traffic into r-nacos is a step that needs to be handled differently for different scenarios:

  1. Application directly request nacos service scenario: r-nacos needs to replace it on the same machine as nacos; you need to shut down nacos first, then change the port of r-nacos to the original nacos port to start and complete the switch.
  2. Reverse proxy to nacos scenario after application requests nginx: update the nginx configuration to update the nacos reverse proxy address to the r-nacos address, then re-add the configuration to complete the switch.

After the cutstream migration is complete, watch to see if the application behaves as expected with r-nacos.

Note: Even if the goal is to enable authentication, r-naocs should not enable interface authentication at this stage (RNACOS_ENABLE_OPEN_API_AUTH=false) in case the application is intercepted using the original nacos to assign the old token request.

III. Post-migration closure

After completing the migration and stabilizing for a short period of time, you can remove nacos and keep only r-nacos.

If you need to enable authentication for the interface, do the following:

a) After the old tokens of the application have expired (the default expiration time is 5 hours) and all the new tokens have been obtained from r-nacos again, then turn on the interface authentication configuration to restart r-nacos (r-nacos can be restarted in seconds, and the application is almost senseless).
b) You can also restart applications in batches to force them to use the r-nacos token, and then restart r-nacos by enabling the interface authentication configuration.

This completes the migration from nacos to r-nacos.

3. Migration cases

The previous talk is the migration operation steps may be more abstract, here to add two specific migration scenarios to let the reader have a more physical sense.

3.1 Scenario migration scheme for single node nacos with direct chaining of application services

Deployment chart:

nacos persistent content.

nacos usage:

  1. Deploy a nacos on 10.0.24.9 and use the default port numbers 8848,8948 for service;
  2. On nacos, two namespaces, pre and prod, are set up to provide services for pre-release and production environments, respectively.
  3. There are 3 applications, each with 2 instances of the nacos service; there are two environments in total, one of which has 3 configuration files, 3 services, and 6 instances;
  4. The username used by the application:xxx_app_id , Password.a07a6deb5e56

Objective:
Deploy r-nacos to replace nacos in the same machine to provide the service, using theSystemd deployment

2.2.1 Migration steps - before migration

Step 1 , deploy r-nacos on 10.0.24.9 using temporary port 8858.
Here we assume that the deployment is done using the linux systemd method. For details, please refer to the r-nacos documentation, which will not be expanded here.
The key configuration items are listed below:

# r-nacos listens on http port, here use temporary port 8858, later adjusted back when cutting streams
RNACOS_HTTP_PORT=8858
# r-nacos listen to grpc port, grpc port is not configured here, the default value: HTTP port +1000
# r-nacos_grpc_port=9858
# r-nacos independent console port, there is no port conflict, you can directly use the official port
RNACOS_HTTP_CONSOLE_PORT=10848 # RNACOS_ENABLE_CONSOLE_PORT=10848
RNACOS_ENABLE_OPEN_API_AUTH=false

Note: If you are using the docker boot method, you don't need to change the configuration port, just change the port number of the corresponding external mapping.

Step 2 Initialize user information
interviewshttp://10.0.24.9:10848/rnacos/Go to the console.
Add application dependent users, username:xxx_app_id Password: `a07a6deb5e56

Step 3, initialize the namespace

Initialize namespaces pre, prod

Step 4Migration configuration information

  1. Exporting configuration from nacos

Export the configuration under the pre and prod namespaces respectively

The format of the exported filename is:nacos_config_export_20240721230938.zip

Note: Remember to change the file name after each export to increase the namespace tag in case you select the wrong file when importing.

  1. Importing configuration into r-nacos
    Export the configuration file package exported by nacos in the previous step to the configuration under the r-nacos pre, prod namespace, respectively.

a) Go to the r-nacos console ->Configuration list page and select the corresponding namespace.

b) Uploading imported configuration files

After importing:

The above figure operates on the PRE namespace, and the PROD namespace is also operated once, which is not expanded here.

2.2.2 Migration steps - in migration

Step 5After completing the data initialization, shut down r-nacos and update the temporary ports to the official ports first, so that you can start r-nacos directly later.

Shut down the r-nacos service

systemctl stop rnacos

The key configuration items are listed below:

properties
# r-nacos listens on http port
RNACOS_HTTP_PORT=8848
# r-nacos listens to grpc port, grpc port is not configured here, default value: HTTP port +1000
# r-nacos_grpc_port=9848
# RNACOS_GRPC_PORT=9848 # r-nacos standalone console port
RNACOS_HTTP_CONSOLE_PORT=10848
# Interface authentication not enabled during switchover
RNACOS_ENABLE_OPEN_API_AUTH=false

Step 6Shut down nacos.

# Switch to the nacos directory and perform the following named shutdown of nacos
. /bin/

Step 7The first step in the process is to start r-nacos.

Configuration information is prepared before shutting down nacos. start the r-nacos service directly:

systemctl start rnacos

2.2.3 Migration steps - after migration

Step 8The cut stream is complete, and observe the application with r-nacos to confirm that it is working correctly.

The application service can be accessed through the upstream application page to see if it works.
r-nacos may be queried via the Monitor page to see if it is being accessed by the application.

Step 9Enables r-nacos interface authentication (optional).

Enable r-nacos interface authentication after 5 hours have passed since the cutover was completed.

The key configuration items are listed below:

properties
# r-nacos listens on http port
RNACOS_HTTP_PORT=8848
# r-nacos listens to grpc port, grpc port is not configured here, default value: HTTP port +1000
# r-nacos_grpc_port=9848
# RNACOS_GRPC_PORT=9848 # r-nacos standalone console port
RNACOS_HTTP_CONSOLE_PORT=10848
# Enable interface authentication
RNACOS_ENABLE_OPEN_API_AUTH=true

Restart the r-nacos service.

systemctl start rnacos

This completes the migration from nacos to r-nacos.

3.2 Migration scheme for application services linking nacos scenarios via nginx

Deployment chart:

The nacos content is the same as in the previous scenario, deployed with an extra nginx proxy in the middle to provide services.

Linking nacos through nginx, then the switch only needs to switch the original nacos address in the nginx configuration to the r-naocs address, and then pass thenginx -s reload A reload of the configuration rule completes the cut flow.

3.2.1 Migration steps - before migration

The steps are the same as steps 1, 2, 3, and 4 of the previous scenario and will not be expanded upon here.

3.2.2 Migration steps - in migration

Step 5, update the nginx configuration to switch the original nacos address to the r-naocs address.

Original nginx configuration

# nacos http
server {
    listen       8848;
    listen  [::]:8848;
    server_name  localhost;

    location /nacos {
        proxy_set_header Host $proxy_host;
        proxy_pass http://10.0.24.9:8848;
    }
}

# nacos grpc
server {
    listen       9848;
    listen  [::]:9848;
    server_name  localhost;

    location /nacos {
        grpc_pass grpc://10.0.24.9:9848;
    }
}

Updated nginx configuration

# nacos http
server {
    listen       8848;
    listen  [::]:8848;
    server_name  localhost;

    location /nacos {
        proxy_set_header Host $proxy_host;
        proxy_pass http://10.0.24.9:8858;
    }
}

# nacos grpc
server {
    listen       9848;
    listen  [::]:9848;
    server_name  localhost;

    location /nacos {
        grpc_pass grpc://10.0.24.9:9858;
    }
}

fulfillmentnginx -s reload A reload of the configuration rule completes the cut flow.

After the switch:

3.2.3 Migration steps - after migration

The steps are the same as steps 8 and 9 of the previous scenario and will not be expanded upon here.

summarize

For nacos to r-nacos migration, analyzing the data items to be migrated and delineating what needs to be done in each phase of the migration, you can design a suitable migration plan.

Migration can be divided into three stages: before, during and after migration, and this paper gives more specific steps in conjunction with sample scenarios.

If the above case is consistent with your own actual situation, you can consider adding a layer of nginx reverse proxy before the application requests nacos, and then migrate according to case 2 afterwards.

<Previous Next>