Project: Apollo (Provisioning / Automation & Configuration)
File: distributed-deployment-guide.md

This document describes how to compile, package, and deploy Apollo Configuration Center in a distributed deployment manner, so that it can be deployed and run separately in development, test, and production environments. If you just need to try Apollo locally, you can refer to The server side is based on Spring Boot and the startup script theoretically supports all Linux distributions, is recommended. Apollo server: 1.8+ Apollo client: 1.8+ For running in Java 1.7 runtime environment, please use apollo client of 1.x version, such as 1.9.1 Once configured, this can be checked with the following command. ```sh java -version ``` Sample output. ```sh java version "1.8.0_74" Java(TM) SE Runtime Environment (build 1.8.0_74-b02) Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode) ``` Version requirement: 5.6.5+ Apollo's table structure uses multiple default declarations for `timestamp`, so version 5.6.5+ is required. After connecting to MySQL, you can check with the following command. ```sql SHOW VARIABLES WHERE Variable_name = 'version'; ``` | Variable_name | Value | | - | | | version | 5.7.11 | Note 1: MySQL versions can be downgraded to 5.5, see for details. Note 2: If you wish to use Oracle, you can refer to 's developed on top of Apollo 0.8.0 with `Oracle` version `10.2.0.1.0`. Note 3: If you wish to use Postgres, you can refer to the developed by on top of Apollo 0.9.1 with `Postgres` version 9.3.20, also see developed on the basis of Apollo 0.10.2 with `Postgres` version 9.5. Distributed deployments require a pre-determined environment for the deployment and how it will be deployed. Apollo currently supports the following environments. DEV Development environment FAT Test environments, equivalent to alpha environments (functional testing) UAT Integration environment, equivalent to a beta environment (regression testing) PRO Production environment If you want to add custom environment names, you can refer to for the specific steps. Please note, if your custom environment name is "PROD", it will be forcibly converted to "PRO". Similarly, if the environment name is "FWS", it will be forcibly converted to "FAT". You can refer to For distributed deployment, `apollo-configservice` and `apollo-adminservice` need to register their IPs and ports to Meta Server (apollo-configservice itself). Apollo clients and Portal will get the address (IP+port) of the service from Meta Server, and then access it directly through the service address. Note that `apollo-configservice` and `apollo-adminservice` are designed based on the intranet trusted network, so for security reasons, please do not expose `apollo-configservice` and `apollo-adminservice` directly to the public network. So if the actual deployed machine has multiple NICs (e.g. docker), or there are some NICs with IPs that are not accessible by Apollo clients and Portal (e.g. network security restrictions), then we need to do relevant configurations in `apollo-configservice` and `apollo-adminservice` to solve connectivity issues. You can modify the startup.sh of `apollo-configservice` and `apollo-adminservice` respectively by passing the -D parameter through the JVM System Property, or by passing the OS Environment Variable, the following example will change the ` docker0` and NICs starting with `veth` are ignored when registering to Eureka. JVM System Property example. ```properties -Dspring.cloud.inetutils.ignoredInterfaces[0]=docker0 -Dspring.cloud.inetutils.ignoredInterfaces[1]=veth.* ``` OS Environment Variable example. ```properties SPRINGCLOUDINETUTILSIGNOREDINTERFACES[0]=docker0 SPRINGCLOUDINETUTILSIGNOREDINTERFACES[1]=veth.* ``` You can modify the startup.sh of `apollo-configservice` and `apollo-adminservice` respectively, passing in the -D parameter via JVM System Property, or via OS Environment Variable, the following example will specify the IP to be registered as `1.2.3.4`. JVM System Property example. ```properties -Deureka.instance.ip-address=1.2.3.4 ``` OS Environment Variable example. ```properties EUREKAINSTANCEIP_ADDRESS=1.2.3.4 ``` You can modify the

of `apollo-configservice` and `apollo-adminservice` respectively, passing in the -D parameter via JVM System Property, or via OS Environment Variable, the following example will specify the URL to register URL as `http://1.2.3.4:8080`. JVM System Property example. ```properties -Deureka.instance.homePageUrl=http://1.2.3.4:8080 -Deureka.instance.preferIpAddress=false ``` OS Environment Variable Example. ```properties EUREKAINSTANCEHOMEPAGEURL=http://1.2.3.4:8080 EUREKAINSTANCEPREFERIPADDRESS=false ``` If Apollo is deployed on the public cloud and the local development environment cannot connect, but you need to do development testing, the client can upgrade to version 0.11.0 and above, and then configure In some companies (e.g. companies in the financial industry), there are many firewalls and network isolation, and it is necessary to open up the network (so that `ip1` can access a port of `ip2`) For clients that use the configuration center, `Apollo-Client` needs to access all (or the same room within) Meta Server and Config Service (default are port 8080), please do not open the network from `Client` to `Admin Service`. ```mermaid flowchart LR subgraph servers[IP1:8080, IP2:8080, ..., IPn:8080] m[Meta Sever] c[Config Service] end client --> servers ``` If an application needs to use openapi, it also needs to access Portal (default is port 8070). ```mermaid flowchart LR subgraph servers[IP:8070] Portal end openapi-client --> servers ``` For the configuration center itself, it is also necessary to ensure network connectivity as each service needs to access each other. ```mermaid flowchart LR subgraph config-service-servers[All Config Service's IP:8080] m[Meta Server] c[Config Service] end subgraph admin-service-servers[All Admin Service's IP:8090] a[Admin Service] end subgraph portal-servers[IP:8070] p[Portal] end configdb[(ConfigDB)] portaldb[(PortalDB)] a --> config-service-servers a --> configdb c --> configdb p --> config-service-servers p --> admin-service-servers p --> portaldb ``` The overall deployment steps are relatively simple. recorded a series of Apollo quick start videos, if you feel slightly tedious to read the documentation, you may wish to first look at his . If you encounter problems during the deployment process, you can refer to , and you can usually find the answers. Apollo server side needs a total of two databases: `ApolloPortalDB` and `ApolloConfigDB`, we prepared the database, table creation and sample data as sql files respectively, and just need to import the database. Note that ApolloPortalDB only needs to deploy one in the production environment, while ApolloConfigDB needs to deploy one set in each environment, such as fat, uat and pro respectively, to deploy 3 sets of ApolloConfigDB. Note: If you have already created Apollo database locally, please pay attention to backup data. The sql file we prepare will empty the Apollo related tables. You can choose to create it by manually importing SQL or by automatically importing SQL via depending on the actual situation. You can import through various MySQL clients. Using the native MySQL client as an example. ```sql source /yourlocalpath/scripts/sql/profiles/mysql-default/apolloportaldb.sql ``` Requires version 1.3.0 and above Modify the `flyway-portaldb.properties` in in `flyway.user`, `flyway.password` and `flyway.url` configurations Execute `mvn -N -Pportaldb flyway:migrate` in the apollo project root directory After a successful import, you can verify it by executing the following sql statement. ```sql select `Id`, `Key`, `Value`, `Comment` from `ApolloPortalDB`. `ServerConfig` limit 1; ``` | Id | Key | Value | Comment | | - | | -- | | | 1 | apollo.portal.envs | dev | list of supported environments | Note: ApolloPortalDB only needs to be deployed in a production environment. You can choose to create it by manually importing SQL or automatically importing SQL via according to the actual situation. You can import through various MySQL clients. Using the native MySQL client as an example. ```sql source /yourlocalpath/scripts/sql/profiles/mysql-default/apolloconfigdb.sql ``` Version 1.3.0 and above is required Modify the `flyway.user`, `flyway.password`, and `flyway.password` in

Run `mvn -N -Pconfigdb flyway:migrate` in the apollo project root directory After a successful import, you can verify it by executing the following sql statement. ```sql select `Id`, `Key`, `Value`, `Comment` from `ApolloConfigDB`. `ServerConfig` limit 1; ``` | Id | Key | Value | Comment | | - | | -- | | | 1 | eureka.service.url | http://127.0.0.1:8080/eureka/ | Eureka Service Url | Note: ApolloConfigDB needs to be deployed in one set per environment, e.g. 3 sets of ApolloConfigDB for fat, uat and pro respectively If the Apollo configuration center is newly deployed, please ignore this step. If the Apollo Configuration Center is not newly deployed, for example, it has been in use for some time and a number of projects and namespaces have been created in the Apollo Configuration Center at that time, then you need to import the necessary project data from other normally running environments in the ApolloConfigDB in the new environment. The following four tables of ApolloConfigDB are mainly involved, and the following data query statements are also attached. App Import all the apps e.g.: insert into `New environment of ApolloConfigDB`. `App` select from `Other Environment's ApolloConfigDB`. `App` where `IsDeleted` = 0; AppNamespace Import all AppNamespace e.g. insert into `New environment's ApolloConfigDB`. `AppNamespace` select from `other environment's ApolloConfigDB`. `AppNamespace` where `IsDeleted` = 0; Cluster Import the default default cluster e.g. insert into `New environment's ApolloConfigDB`. `Cluster` select from `ApolloConfigDB of other environment`. `Cluster` where `Name` = 'default' and `IsDeleted` = 0; Namespace Import the namespace in the default default cluster e.g. insert into `ApolloConfigDB` of the new environment. `Namespace` select from `ApolloConfigDB of other environment`. `Namespace` where `ClusterName` = 'default' and `IsDeleted` = 0; Also don't forget to notify users to set the correct configuration information for their projects in the new environment, especially for some public namespace configurations that have a large impact. If you are migrating data for a running environment, it is recommended to restart the config service after migration, because the config service has cached data for appnamespace Apollo's own configuration is placed inside the database, so you need to make some adjustments for the actual situation, please refer to for specific parameters. Most of the configurations can use the default values first, but and please make sure configured correctly before proceeding to the following deployment steps. The installation package can be obtained in two ways. directly downloading the installer Download the pre-typed installer from the page If you don't need to customize Apollo's code, it is recommended to use this way to skip the local packaging process Build via source code Download the Source code package from the page or directly clone then build locally If you need to do custom development for Apollo, you need to use this method Download the latest versions of `apollo-configservice-x.x.x-github.zip`, `apollo- adminservice-x.x.x-github.zip` and `apollo-portal-x.x.x-github.zip` can be downloaded. The Apollo server needs to know how to connect to the database you created earlier. The database connection string information is located in `config/application-github.properties` in the zip file you downloaded in the previous step. unzip `apollo-configservice-x.x.x-github.zip`. 2. Open the `application-github.properties` file in the `config` directory with a programmer's editor (e.g. vim, notepad++, sublime, etc.) fill in the correct ApolloConfigDB database connection string information, note that there are no spaces after the username and password! The result of the modification is as follows. ```properties spring.datasource.url = jdbc:mysql://localhost:3306/ApolloConfigDB?useSSL=false&characterEncoding=utf8 spring.datasource.username = someuser spring.datasource.password = somepwd ``` Note: Since ApolloConfigDB is deployed in each environment, you need to configure the database parameters of the corresponding environment for different environment config-services unzip

2. Open the `application-github.properties` file in the `config` directory with a programmer's editor (e.g. vim, notepad++, sublime, etc.) fill in the correct ApolloConfigDB database connection string information, note that there are no spaces after the username and password! The result of the modification is as follows. ```properties spring.datasource.url = jdbc:mysql://localhost:3306/ApolloConfigDB?useSSL=false&characterEncoding=utf8 spring.datasource.username = someuser spring.datasource.password = somepwd ``` Note: Since ApolloConfigDB is deployed in each environment, you need to configure the database parameters of the corresponding environment for different environment admin-services unzip `apollo-portal-x.x.x-github.zip`. 2. Open the `application-github.properties` file in the `config` directory with a programmer-specific editor (e.g. vim, notepad++, sublime, etc.) fill in the correct ApolloPortalDB database connection string information, note that there are no spaces after the username and password! The effect after modification is as follows. ```properties spring.datasource.url = jdbc:mysql://localhost:3306/ApolloPortalDB?useSSL=false&characterEncoding=utf8 spring.datasource.username = someuser spring.datasource.password = somepwd ``` Apollo Portal needs to access different meta service (apollo-configservice) addresses in different environments, so we need to provide this information in the configuration. By default, the meta service and config service are deployed in the same JVM process, so the address of the meta service is the address of the config service. For version 1.6.0 and above, you can configure the Meta Service address through the configuration item in ApolloPortalDB.ServerConfig, see Open the `apollo-env.properties` file in the `config` directory of `apollo-portal-x.x.x-github.zip` using a programmer-specific editor (e.g. vim, notepad++, sublime, etc.). Suppose DEV's apollo-config service is not bound to a domain name at 1.1.1.1:8080, FAT's apollo-config service is bound to the domain name apollo.fat.xxx.com, and UAT's apollo-config service is bound to the domain name apollo.uat.xxx.com, and PRO's apollo-configservice is bound to the domain apollo.xxx.com, then you can modify each environment meta service address as follows, in the format of `${env}.meta=http://${config-service- url:port}`, and if an environment does not need it, you can also directly delete the corresponding configuration item (e.g. lpt.meta): ```properties dev.meta=http://1.1.1.1:8080 fat.meta=http://apollo.fat.xxx.com uat.meta=http://apollo.uat.xxx.com pro.meta=http://apollo.xxx.com ``` In addition to configuring the meta service by means of `apollo-env.properties`, apollo also supports specifying the meta service at runtime (with a higher priority than `apollo-env.properties`): 1. via Java System Property `${env}_meta` Can be specified via Java System Property `${env}_meta` e.g. `java -Ddev_meta=http://config-service-url -jar xxx.jar` Can also be specified programmatically, e.g. `System.setProperty("dev_meta", "http://config-service-url");` through the operating system's System Environment `${ENV}_META` e.g. `DEV_META=http://config-service-url` Note that the key is all-caps and separated by `_`. Note 1: In order to achieve high availability of meta service, it is recommended to do dynamic load balancing by SLB (Software Load Balancer). Note 2: The meta service address can also be filled with IPs. Before version 0.11.0, only one IP was supported. From version 0.11.0 onwards, multiple addresses separated by commas ( ), such as `http://1.1.1.1:8080,http://2.2.2.2:8080`, although production environments are still recommended to use domain names (go slb), as machine expansion, shrinkage, etc. may result in changes to the IP list. The Apollo server needs to know how to connect to the database you created earlier, so you need to edit and modify ApolloPortalDB and ApolloConfigDB related database connection string information. Note: The filled-in user needs to have read/write access to ApolloPortalDB and ApolloConfigDB

```sh apolloconfigdb_url=jdbc:mysql://localhost:3306/ApolloConfigDB?useSSL=false&characterEncoding=utf8 apolloconfigdb_username=username apolloconfigdb_password=password (if you don't have a password, just leave it blank) apolloportaldb_url=jdbc:mysql://localhost:3306/ApolloPortalDB?useSSL=false&characterEncoding=utf8 apolloportaldb_username=username apolloportaldb_password=password (if you don't have a password, just leave it blank) ``` Note 1: As ApolloConfigDB is deployed in each environment, so for different environments config-service and admin-service need to use different database parameters to play different packages, portal only need to play once package can Note 2: If you don't want config-service and admin-service to have a package for each environment, you can also pass in the database connection string information at runtime, which can be found in Note 3: Each environment needs to deploy a separate set of config-service, admin-service and ApolloConfigDB Apollo Portal needs to access different meta service (apollo-configservice) addresses in different environments, so this information needs to be provided at packaging time. Suppose DEV's apollo-config service is not bound to a domain name with the address 1.1.1.1:8080, FAT's apollo-config service is bound to the domain name apollo.fat.xxx.com, and UAT's apollo-config service is bound to the domain name apollo.uat.xxx.com, and PRO's apollo-configservice is bound to the domain apollo.xxx.com, then edit as follows to modify each environment meta service service address in the format ``${env}_meta=http://${config-service-url:port}``, if an environment does not need it, you can also directly delete the corresponding configuration item: ```sh dev_meta=http://1.1.1.1:8080 fat_meta=http://apollo.fat.xxx.com uat_meta=http://apollo.uat.xxx.com pro_meta=http://apollo.xxx.com METASERVERSOPTS="-Ddevmeta=$devmeta -Dfatmeta=$fatmeta -Duatmeta=$uatmeta -Dprometa=$prometa" ``` In addition to configuring the meta service at packaging time, apollo also supports specifying the meta service at runtime: 1. via Java System Property `${env}_meta` can be specified via the Java System Property `${env}_meta` such as `java -Ddev_meta=http://config-service-url -jar xxx.jar` Can also be specified programmatically, e.g. `System.setProperty("dev_meta", "http://config-service-url");` through the operating system's System Environment `${ENV}_META` e.g. `DEV_META=http://config-service-url` Note that the key is all-caps and separated by `_`. Note 1: In order to achieve high availability of meta service, it is recommended to do dynamic load balancing by SLB (Software Load Balancer). Note 2: The meta service address can also be filled with IPs. Before version 0.11.0, only one IP was supported. From version 0.11.0 onwards, multiple addresses separated by commas ( ), such as `http://1.1.1.1:8080,http://2.2.2.2:8080`, although production environments are still recommended to use domain names (go slb), as machine expansion, shrinkage, etc. may lead to changes in the IP list. After doing the above configuration, you can execute the compilation and packaging. Note: The initial compilation will download a lot of dependencies from the central Maven repository, so if the network is not good, it is recommended to use a domestic Maven repository source, such as ```sh ./build.sh ``` This script will package apollo-configservice, apollo-adminservice, apollo-portal in turn. Note: Since ApolloConfigDB is deployed in each environment, you need to use different packages for config-service and admin-service for different environments with different database connection information, and only one package for portal Located in the `apollo-configservice/target/` directory `apollo-configservice-x.x.x-github.zip` Note that since ApolloConfigDB is deployed in every environment, the config-service for different environments needs to be deployed separately using different packages with different database parameters The `apollo-adminservice-x.x.x-github.zip` located in the `apollo-adminservice/target/` directory Note that since ApolloConfigDB is deployed in each environment, the admin-service for different environments needs to be deployed separately using different packages with different database parameters `apollo-portal-x.x.x-github.zip` located in the `apollo-portal/target/` directory Upload the `apollo-configservice-x.x.x-github.zip` of the corresponding environment to the server, decompress it and execute scripts/startup.sh. To stop the service, execute scripts/shutdown.sh. Remember to set a JVM memory according to the actual environment in scripts/startup.sh. The following are our default settings for reference: ```bash export JAVA_OPTS="-server -Xms6144m -Xmx6144m -Xss256k -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=384m -XX:NewSize=4096m -XX:MaxNewSize=4096m -XX:SurvivorRatio=18" ``` Note 1: If you need to modify the JVM parameters, you can modify the `JAVA_OPTS` section of scripts/startup.sh. Note 2: To adjust the log output path of the service, you can modify `LOG_DIR` in scripts/startup.sh and apollo-configservice.conf. Note 3: To adjust the listening port of the service, you can modify the `SERVER_PORT` in scripts/startup.sh. In addition, apollo-configservice also assumes the responsibility of meta

If you want to modify the port, pay attention to the `eureka.service.url` configuration item in the ApolloConfigDB.ServerConfig table and the meta server information used in apollo-portal and apollo-client. For details, see: and . Note 4: If the eureka.service.url of ApolloConfigDB.ServerConfig is only configured with the currently starting machine, the eureka registration failure information will be output in the log during the process of starting apollo-configservice, such as `com.sun.jersey .api.client.ClientHandlerException: java.net.ConnectException: Connection refused`. It should be noted that this is the expected situation, because apollo-configservice needs to register the service with the Meta Server (itself), but because it has not yet woken up during the startup process, it will report this error. The retry action will be performed later, so the registration will be normal after the service is up. Note 5: If you read this, I believe that you must be someone who reads the documentation carefully, and you are a little bit closer to success. Keep going, you should be able to complete the distributed deployment of Apollo soon! But do you feel that Apollo's distributed deployment steps are a bit cumbersome? Do you have any advice you would like to share with the author? If the answer is yes, please move to and look forward to your suggestions! Upload the `apollo-adminservice-x.x.x-github.zip` of the corresponding environment to the server, decompress it and execute scripts/startup.sh. To stop the service, execute scripts/shutdown.sh. Remember to set a JVM memory according to the actual environment in scripts/startup.sh. The following are our default settings for reference: ```bash export JAVA_OPTS="-server -Xms2560m -Xmx2560m -Xss256k -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=384m -XX:NewSize=1024m -XX:MaxNewSize=1024m -XX:SurvivorRatio=22" ``` Note 1: If you need to modify the JVM parameters, you can modify the `JAVA_OPTS` section of scripts/startup.sh. Note 2: To adjust the log output path of the service, you can modify `LOG_DIR` in scripts/startup.sh and apollo-adminservice.conf. Note 3: To adjust the listening port of the service, you can modify the `SERVER_PORT` in scripts/startup.sh. Upload `apollo-portal-x.x.x-github.zip` to the server, unzip it and execute scripts/startup.sh. To stop the service, execute scripts/shutdown.sh. Remember to set a JVM memory according to the actual environment in startup.sh. The following are our default settings for reference: ```bash export JAVA_OPTS="-server -Xms4096m -Xmx4096m -Xss256k -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=384m -XX:NewSize=1536m -XX:MaxNewSize=1536m -XX:SurvivorRatio=22" ``` Note 1: If you need to modify the JVM parameters, you can modify the `JAVA_OPTS` section of scripts/startup.sh. Note 2: To adjust the log output path of the service, you can modify `LOG_DIR` in scripts/startup.sh and apollo-portal.conf. Note 3: To adjust the listening port of the service, you can modify the `SERVER_PORT` in scripts/startup.sh. For version 1.8.0 and above Enable external nacos service registry to replace built-in eureka Note: need repackage Modify build.sh/build.bat to change the maven build command for config-service and admin-service to ```shell mvn clean package -Pgithub,nacos-discovery -DskipTests -pl apollo-configservice,apollo-adminservice -am -Dapolloprofile=github,nacos-discovery -Dspringdatasourceurl=$apolloconfigdburl -Dspringdatasourceusername=$apolloconfigdbusername -Dspringdatasource password=$apolloconfigdbusername password=$apolloconfigdb_password ``` Modify the application-github.properties in the config directory of the apollo-config service and apollo-adminservice installation packages, respectively, to configure the nacos server address ```properties nacos.discovery.server-addr=127.0.0.1:8848 nacos.discovery.access-key= nacos.discovery.username= nacos.discovery.password= nacos.discovery.secret-key= nacos.discovery.namespace= nacos.discovery.context-path= ``` For version 1.9.0 and above Enable external Consul service registry to replace built-in eureka Modify `config/application.properties` after decompression of `apollo-configservice-x.x.x-github.zip` and `apollo-adminservice-x.x.x-github.zip`, uncomment ```properties ``` to ```properties spring.profiles.active=github,consul-discovery ``` Modify the application-github.properties in the config directory of the apollo-configservice and apollo-adminservice installation packages, respectively, to configure the consul server address ```properties spring.cloud.consul.host=127.0.0.1 spring.cloud.consul.port=8500 ``` Modify build.sh/build.bat to change the maven build command for config-service and admin-service to ```shell mvn clean package -Pgithub -DskipTests -pl apollo-configservice,apollo-adminservice -am -Dapolloprofile=github,consul-discovery -Dspringdatasourceurl=$apolloconfigdburl -Dspringdatasourceusername=$apolloconfigdbusername -Dspringdatasourcepassword=$apolloconfigdbpassword ``` Modify the

in the config directory of the apollo-configservice and apollo-adminservice installation packages, respectively, to configure the consul server address ```properties spring.cloud.consul.host=127.0.0.1 spring.cloud.consul.port=8500 ``` For version 2.0.0 and above Enable external Zookeeper service registry to replace built-in eureka Modify `config/application.properties` after decompression of `apollo-configservice-x.x.x-github.zip` and `apollo-adminservice-x.x.x-github.zip`, uncomment ```properties ``` to ```properties spring.profiles.active=github,zookeeper-discovery ``` Modify the application-github.properties in the config directory of the apollo-config service and apollo-adminservice installation packages, respectively, to configure the zookeeper server address ```properties spring.cloud.zookeeper.connect-string=127.0.0.1:2181 ``` Zookeeper version description Support Zookeeper 3.5.x or higher; If apollo-configservice application starts reporting port occupation, please check the following configuration of Zookeeper; Note: Zookeeper 3.5.0 added a built-in ```properties admin.enableServer admin.serverPort ``` Modify build.sh/build.bat to change the maven build command for ``config-service`` and ``admin-service`` to ```shell mvn clean package -Pgithub -DskipTests -pl apollo-configservice,apollo-adminservice -am -Dapolloprofile=github,zookeeper-discovery - Dspringdatasourceurl=$apolloconfigdburl -Dspringdatasourceusername=$apolloconfigdbusername -Dspringdatasourcepassword=$apolloconfigdbpassword ``` Modify the application-github.properties in the config directory of the apollo-config service and apollo-adminservice installation packages, respectively, to configure the zookeeper server address ```properties spring.cloud.zookeeper.connect-string=127.0.0.1:2181 ``` Zookeeper version description Support Zookeeper 3.5.x or higher; If apollo-configservice application starts reporting port occupation, please check the following configuration of Zookeeper; Note: Zookeeper 3.5.0 added a built-in ```properties admin.enableServer admin.serverPort ``` For version 2.0.0 and above Enable custom-defined-discovery to replace built-in eureka Modify `config/application.properties` after decompression of `apollo-configservice-x.x.x-github.zip` and `apollo-adminservice-x.x.x-github.zip`, uncomment ```properties ``` to ```properties spring.profiles.active=github,custom-defined-discovery ``` There are two ways to configure the access addresses of the custom config-service and admin-service: one is to write two pieces of data in the mysql database ApolloConfigDB and the table ServerConfig. ```sql INSERT INTO `ApolloConfigDB`.`ServerConfig` (`Key`, `Value`, `Comment`) VALUES ('apollo.config-service.url', 'http://apollo-config-service', 'ConfigService access address '); INSERT INTO `ApolloConfigDB`.`ServerConfig` (`Key`, `Value`, `Comment`) VALUES ('apollo.admin-service.url', 'http://apollo-admin-service', 'AdminService access address '); ``` Another way to modify application-github.properties in the config directory of the apollo-configservice installation package ```properties apollo.config-service.url=http://apollo-config-service apollo.admin-service.url=http://apollo-admin-service ``` Modify build.sh/build.bat and change the maven compilation commands of `config-service` and `admin-service` to ```shell mvn clean package -Pgithub -DskipTests -pl apollo-configservice,apollo-adminservice -am -Dapolloprofile=github,custom-defined-discovery -Dspringdatasourceurl=$apolloconfigdburl -Dspringdatasourceusername=$apolloconfigdbusername -Dspringdatasourcepassword=$apolloconfigdbpassword ``` There are two ways to configure the access addresses of the custom config-service and admin-service: one is to write two pieces of data in the mysql database ApolloConfigDB and the table ServerConfig. ```sql INSERT INTO `ApolloConfigDB`.`ServerConfig` (`Key`, `Value`, `Comment`) VALUES ('apollo.config-service.url', 'http://apollo-config-service', 'ConfigService access address '); INSERT INTO `ApolloConfigDB`.`ServerConfig` (`Key`, `Value`, `Comment`) VALUES ('apollo.admin-service.url', 'http://apollo-admin-service', 'AdminService access address '); ``` Another way to modify application-github.properties in the config directory of the apollo-configservice installation package ```properties apollo.config-service.url=http://apollo-config-service apollo.admin-service.url=http://apollo-admin-service ``` For version 2.1.0 and above Enable database-discovery to replace built-in eureka Apollo supports the use of internal database table as registry, without relying on third-party registry. Modify `config/application.properties` after decompression of `apollo-configservice-x.x.x-github.zip` and `apollo-adminservice-x.x.x-github.zip`, uncomment ```properties ``` to ```properties spring.profiles.active=github,database-discovery ``` (optional) In multi-cluster deployments, if you want apollo client only read Config Service in the same cluster, you can add a property in `config/application-github.properties` of the Config Service and Admin Service installation package ```properties apollo.service.registry.cluster=same name with apollo Cluster ``` (optional) If you want to customize Config Service and Admin Service's uri for Client, for example when deploying on the intranet, if you don't want to expose the intranet ip, you can add a property in `config/application-github.properties` of the Config Service and Admin Service installation package ```properties apollo.service.registry.uri=http://your-ip-or-domain:${server.port}/ ``` Apollo version 1.7.0 starts uploading Docker images to by default, which can be obtained by following these steps ```bash docker pull apolloconfig/apollo-config service:${version} ``` Example: ```bash docker run -p 8080:8080 \ -e SPRINGDATASOURCEURL="jdbc:mysql://fill-in-the-correct-server:3306/ApolloConfigDB?characterEncoding=utf8" \ -e SPRINGDATASOURCEUSERNAME=FillInCorrectUser -e SPRINGDATASOURCEPASSWORD=FillInCorrectPassword \ -d -v /tmp/logs:/opt/logs --name apollo-configservice apolloconfig/apollo-configservice:${version} ``` Parameter

`SPRINGDATASOURCEURL`: Address of the corresponding environment ApolloConfigDB `SPRINGDATASOURCEUSERNAME`: The user name of the corresponding environment ApolloConfigDB `SPRINGDATASOURCEPASSWORD`: password of the corresponding environment ApolloConfigDB ```bash docker pull apolloconfig/apollo-adminservice:${version} ``` Example: ```bash docker run -p 8090:8090 \ -e SPRINGDATASOURCEURL="jdbc:mysql://fill-in-the-correct-server:3306/ApolloConfigDB?characterEncoding=utf8" \ -e SPRINGDATASOURCEUSERNAME=FillInCorrectUser -e SPRINGDATASOURCEPASSWORD=FillInCorrectPassword \ -d -v /tmp/logs:/opt/logs --name apollo-adminservice apolloconfig/apollo-adminservice:${version} ``` Parameter description. `SPRINGDATASOURCEURL`: Address of the corresponding environment ApolloConfigDB `SPRINGDATASOURCEUSERNAME`: The user name of the corresponding environment ApolloConfigDB `SPRINGDATASOURCEPASSWORD`: password of the corresponding environment ApolloConfigDB ```bash docker pull apolloconfig/apollo-portal:${version} ``` Example: ```bash docker run -p 8070:8070 \ -e SPRINGDATASOURCEURL="jdbc:mysql://fill-in-the-correct-server:3306/ApolloPortalDB?characterEncoding=utf8" \ -e SPRINGDATASOURCEUSERNAME=FillInCorrectUser -e SPRINGDATASOURCEPASSWORD=FillInCorrectPassword \ -e APOLLOPORTALENVS=dev,pro \ -e DEVMETA=http://fill-in-dev-meta-server:8080 -e PROMETA=http://fill-in-pro-meta-server:8080 \ -d -v /tmp/logs:/opt/logs --name apollo-portal apolloconfig/apollo-portal:${version} ``` Parameter description: `SPRINGDATASOURCEURL`: Address of the corresponding environment ApolloPortalDB `SPRINGDATASOURCEUSERNAME`: The username of the corresponding environment ApolloPortalDB `SPRINGDATASOURCEPASSWORD`: The password of the corresponding environment ApolloPortalDB `APOLLOPORTALENVS` (optional): corresponds to the configuration item in ApolloPortalDB, which can be configured by this environment parameter if it is not configured in the database. `DEVMETA/PROMETA`(optional): Configure the Meta Service address of the corresponding environment, named by `${ENV}_META`, it should be noted that if you configure configuration, then the configuration in apollo.portal.meta.servers prevails. If you have modified the apollo server code and wish to build a Docker image from source, you can refer to the following steps. Build the installation package from source: `./scripts/build.sh` 2. build the Docker image: `mvn docker:build -pl apollo-configservice,apollo-adminservice,apollo-portal` Apollo project already comes with Docker file, you can refer to to configure the installer and then hit the Docker image with the following file. See also the project by Apollo user and for the project. Apollo version 1.7.0 adds a deployment model based on Kubernetes native service discovery, which greatly simplifies the overall deployment as it no longer uses the built-in Eureka, and also provides Helm Charts for easy deployment. More design notes can be found in . Kubernetes 1.10+ Helm 3 ```bash $ helm repo add apollo https://charts.apolloconfig.com $ helm search repo apollo ``` You need to install apollo-configservice and apollo-adminservice in each environment, so it is recommended to include the environment information in the release name, e.g. `apollo-service-dev` ```bash $ helm install apollo-service-dev \ --set configdb.host=1.2.3.4 \ --set configdb.userName=apollo \ --set configdb.password=apollo \ --set configdb.service.enabled=true \ --set configService.replicaCount=1 \ --set adminService.replicaCount=1 \ -n your-namespace \ apollo/apollo-service ``` The general deployment recommendation is to configure via values.yaml ```bash $ helm install apollo-service-dev -f values.yaml -n your-namespace apollo/apollo-service ``` After installation, you will be prompted for the Meta Server address of the corresponding environment, which needs to be recorded. apollo-portal needs to be installed with. ```bash Get meta service url for current release by running these commands: echo http://apollo-service-dev-apollo-configservice:8080 ``` See for more configuration notes For example to uninstall the `apollo-service-dev` deployment. ```bash $ helm uninstall -n your-namespace apollo-service-dev ``` The following table lists the configurable parameters of the apollo-service-chart and their default values. | Parameter | Description | Default | | -- | | -- | | `configdb.host` | The host for apollo config db | `nil` | | `configdb.port` | The port for apollo config db | `3306` | | `configdb.dbName` | The database name for apollo config db | `ApolloConfigDB` | | `configdb.userName` | The user name for apollo config db | `nil` | | `configdb.password` | The password for apollo config db | `nil` | | `configdb.connectionStringProperties` | The connection string properties for apollo config db | `characterEncoding=utf8` | | `configdb.service.enabled` | Whether to create a Kubernetes Service for `configdb.host` or not. Set it to `true` if `configdb.host` is an endpoint outside of the kubernetes cluster | `false` | |

| Override the service name for apollo config db | `nil` | | `configdb.service.port` | The port for the service of apollo config db | `3306` | | `configdb.service.type` | The service type of apollo config db: `ClusterIP` or `ExternalName`. If the host is a DNS name, please specify `ExternalName` as the service type, e.g. `xxx.mysql.rds.aliyuncs.com` | `ClusterIP` | | `configService.fullNameOverride` | Override the deployment name for apollo-configservice | `nil` | | `configService.replicaCount` | Replica count of apollo-configservice | `2` | | `configService.containerPort` | Container port of apollo-configservice | `8080` | | `configService.image.repository` | Image repository of apollo-configservice | `apolloconfig/apollo-configservice` | | `configService.image.tag` | Image tag of apollo-configservice, e.g. `1.8.0`, leave it to `nil` to use the default version. (chart version >= 0.2.0) | `nil` | | `configService.image.pullPolicy` | Image pull policy of apollo-configservice | `IfNotPresent` | | `configService.imagePullSecrets` | Image pull secrets of apollo-configservice | `[]` | | `configService.service.fullNameOverride` | Override the service name for apollo-configservice | `nil` | | `configService.service.port` | The port for the service of apollo-configservice | `8080` | | `configService.service.targetPort` | The target port for the service of apollo-configservice | `8080` | | `configService.service.type` | The service type of apollo-configservice | `ClusterIP` | | `configService.ingress.enabled` | Whether to enable the ingress for config-service or not. (chart version >= 0.2.0) | `false` | | `configService.ingress.annotations` | The annotations of the ingress for config-service. (chart version >= 0.2.0) | `{}` | | `configService.ingress.hosts.host` | The host of the ingress for config-service. (chart version >= 0.2.0) | `nil` | | `configService.ingress.hosts.paths` | The paths of the ingress for config-service. (chart version >= 0.2.0) | `[]` | | `configService.ingress.tls` | The tls definition of the ingress for config-service. (chart version >= 0.2.0) | `[]` | | `configService.liveness.initialDelaySeconds` | The initial delay seconds of liveness probe | `100` | | `configService.liveness.periodSeconds` | The period seconds of liveness probe | `10` | | `configService.readiness.initialDelaySeconds` | The initial delay seconds of readiness probe | `30` | | `configService.readiness.periodSeconds` | The period seconds of readiness probe | `5` | | `configService.config.profiles` | specify the spring profiles to activate | `github,kubernetes` | | `configService.config.configServiceUrlOverride` | Override `apollo.config-service.url`: config service url to be accessed by apollo-client, e.g. `http://apollo-config-service-dev:8080` | `nil` | | `configService.config.adminServiceUrlOverride` | Override `apollo.admin-service.url`: admin service url to be accessed by apollo-portal, e.g. `http://apollo-admin-service-dev:8090` | `nil` | | `configService.config.contextPath` | specify the context path, e.g. `/apollo`, then users could access config service via `http://{configserviceaddress}/apollo`. (chart version >= 0.2.0) | `nil` | | `configService.env` | Environment variables passed to the container, e.g. <br />`JAVA_OPTS: -Xss256k` | `{}` | | `configService.strategy` | The deployment strategy of apollo-configservice | `{}` | | `configService.resources` | The resources definition of apollo-configservice | `{}` | | `configService.nodeSelector` | The node selector definition of apollo-configservice | `{}` | | `configService.tolerations` | The tolerations definition of apollo-configservice | `[]` | | `configService.affinity` | The affinity definition of apollo-configservice | `{}` | | `adminService.fullNameOverride` | Override the deployment name for apollo-adminservice | `nil` | | `adminService.replicaCount` | Replica count of apollo-adminservice | `2` | | `adminService.containerPort` | Container port of apollo-adminservice | `8090` | | `adminService.image.repository` | Image repository of apollo-adminservice | `apolloconfig/apollo-adminservice` | | `adminService.image.tag` | Image tag of apollo-adminservice, e.g. `1.8.0`, leave it to `nil` to use the default version. (chart version >= 0.2.0) | `nil` | | `adminService.image.pullPolicy` | Image pull policy of apollo-adminservice | `IfNotPresent` | | `adminService.imagePullSecrets` | Image pull secrets of apollo-adminservice | `[]` | | `adminService.service.fullNameOverride` | Override the service name for apollo-adminservice | `nil` | | `adminService.service.port` | The port for the service of apollo-adminservice | `8090` | |

| The target port for the service of apollo-adminservice | `8090` | | `adminService.service.type` | The service type of apollo-adminservice | `ClusterIP` | | `adminService.ingress.enabled` | Whether to enable the ingress for admin-service or not. (chart version >= 0.2.0) | `false` | | `adminService.ingress.annotations` | The annotations of the ingress for admin-service. (chart version >= 0.2.0) | `{}` | | `adminService.ingress.hosts.host` | The host of the ingress for admin-service. (chart version >= 0.2.0) | `nil` | | `adminService.ingress.hosts.paths` | The paths of the ingress for admin-service. (chart version >= 0.2.0) | `[]` | | `adminService.ingress.tls` | The tls definition of the ingress for admin-service. (chart version >= 0.2.0) | `[]` | | `adminService.liveness.initialDelaySeconds` | The initial delay seconds of liveness probe | `100` | | `adminService.liveness.periodSeconds` | The period seconds of liveness probe | `10` | | `adminService.readiness.initialDelaySeconds` | The initial delay seconds of readiness probe | `30` | | `adminService.readiness.periodSeconds` | The period seconds of readiness probe | `5` | | `adminService.config.profiles` | specify the spring profiles to activate | `github,kubernetes` | | `adminService.config.contextPath` | specify the context path, e.g. `/apollo`, then users could access admin service via `http://{adminserviceaddress}/apollo`. (chart version >= 0.2.0) | `nil` | | `adminService.env` | Environment variables passed to the container, e.g. <br />`JAVA_OPTS: -Xss256k` | `{}` | | `adminService.strategy` | The deployment strategy of apollo-adminservice | `{}` | | `adminService.resources` | The resources definition of apollo-adminservice | `{}` | | `adminService.nodeSelector` | The node selector definition of apollo-adminservice | `{}` | | `adminService.tolerations` | The tolerations definition of apollo-adminservice | `[]` | | `adminService.affinity` | The affinity definition of apollo-adminservice | `{}` | ```yaml configdb: host: 1.2.3.4 dbName: ApolloConfigDBName userName: someUserName password: somePassword connectionStringProperties: characterEncoding=utf8&useSSL=false service: enabled: true ``` ```yaml configdb: host: xxx.mysql.rds.aliyuncs.com dbName: ApolloConfigDBName userName: someUserName password: somePassword connectionStringProperties: characterEncoding=utf8&useSSL=false service: enabled: true type: ExternalName ``` ```yaml configdb: host: apollodb-mysql.mysql dbName: ApolloConfigDBName userName: someUserName password: somePassword connectionStringProperties: characterEncoding=utf8&useSSL=false ``` If apollo-client cannot directly access the service of apollo-configservice (for example, it is not in the same k8s cluster), you can refer to the following example to specify the address returned by Meta Server to apollo-client (for example, it can be accessed through nodeport) ```yaml configService: config: configServiceUrlOverride: http://1.2.3.4:12345 ``` If apollo-portal cannot directly access the service of apollo-adminservice (for example, it is not in the same k8s cluster), you can refer to the following example to specify the address returned by Meta Server to apollo-portal (for example, it can be accessed through nodeport) ```yaml configService: config: adminServiceUrlOverride: http://1.2.3.4:23456 ``` ```yaml configService: config: contextPath: /config ingress: enabled: true hosts: paths: /config ``` ```yaml adminService: config: contextPath: /admin ingress: enabled: true hosts: paths: /admin ``` Suppose there are dev and pro environments, and the meta server addresses are `http://apollo-service-dev-apollo-configservice:8080` and `http://apollo-service-pro-apollo-configservice:8080` respectively : ```bash $ helm install apollo-portal \ --set portaldb.host=1.2.3.4 \ --set portaldb.userName=apollo \ --set portaldb.password=apollo \ --set portaldb.service.enabled=true \ --set config.envs="dev\,pro" \ --set config.metaServers.dev=http://apollo-service-dev-apollo-configservice:8080 \ --set config.metaServers.pro=http://apollo-service-pro-apollo-configservice:8080 \ --set replicaCount=1 \ -n your-namespace \ apollo/apollo-portal ``` General deployment recommendations are configured through values.yaml: ```bash $ helm install apollo-portal -f values.yaml -n your-namespace apollo/apollo-portal ``` For more configuration item descriptions, please refer to [2.4.1.4.3 Configuration item description]( For example, to uninstall an `apollo-portal` deployment. ```bash $ helm uninstall -n your-namespace apollo-portal ``` The following table lists the configurable parameters of the apollo-portal chart and their default

| Parameter | Description | Default | | - | | - | | `fullNameOverride` | Override the deployment name for apollo-portal | `nil` | | `replicaCount` | Replica count of apollo-portal | `2` | | `containerPort` | Container port of apollo-portal | `8070` | | `image.repository` | Image repository of apollo-portal | `apolloconfig/apollo-portal` | | `image.tag` | Image tag of apollo-portal, e.g. `1.8.0`, leave it to `nil` to use the default version. (chart version >= 0.2.0) | `nil` | | `image.pullPolicy` | Image pull policy of apollo-portal | `IfNotPresent` | | `imagePullSecrets` | Image pull secrets of apollo-portal | `[]` | | `service.fullNameOverride` | Override the service name for apollo-portal | `nil` | | `service.port` | The port for the service of apollo-portal | `8070` | | `service.targetPort` | The target port for the service of apollo-portal | `8070` | | `service.type` | The service type of apollo-portal | `ClusterIP` | | `service.sessionAffinity` | The session affinity for the service of apollo-portal | `ClientIP` | | `ingress.enabled` | Whether to enable the ingress or not | `false` | | `ingress.annotations` | The annotations of the ingress | `{}` | | `ingress.hosts.host` | The host of the ingress | `nil` | | `ingress.hosts.paths` | The paths of the ingress | `[]` | | `ingress.tls` | The tls definition of the ingress | `[]` | | `liveness.initialDelaySeconds` | The initial delay seconds of liveness probe | `100` | | `liveness.periodSeconds` | The period seconds of liveness probe | `10` | | `readiness.initialDelaySeconds` | The initial delay seconds of readiness probe | `30` | | `readiness.periodSeconds` | The period seconds of readiness probe | `5` | | `env` | Environment variables passed to the container, e.g. <br />`JAVA_OPTS: -Xss256k` | `{}` | | `strategy` | The deployment strategy of apollo-portal | `{}` | | `resources` | The resources definition of apollo-portal | `{}` | | `nodeSelector` | The node selector definition of apollo-portal | `{}` | | `tolerations` | The tolerations definition of apollo-portal | `[]` | | `affinity` | The affinity definition of apollo-portal | `{}` | | `config.profiles` | specify the spring profiles to activate | `github,auth` | | `config.envs` | specify the env names, e.g. `dev,pro` | `nil` | | `config.contextPath` | specify the context path, e.g. `/apollo`, then users could access portal via `http://{portal_address}/apollo` | `nil` | | `config.metaServers` | specify the meta servers, e.g.<br />`dev: http://apollo-configservice-dev:8080`<br />`pro: http://apollo-configservice-pro:8080` | `{}` | | `config.files` | specify the extra config files for apollo-portal, e.g. `application-ldap.yml` | `{}` | | `portaldb.host` | The host for apollo portal db | `nil` | | `portaldb.port` | The port for apollo portal db | `3306` | | `portaldb.dbName` | The database name for apollo portal db | `ApolloPortalDB` | | `portaldb.userName` | The user name for apollo portal db | `nil` | | `portaldb.password` | The password for apollo portal db | `nil` | | `portaldb.connectionStringProperties` | The connection string properties for apollo portal db | `characterEncoding=utf8` | | `portaldb.service.enabled` | Whether to create a Kubernetes Service for `portaldb.host` or not. Set it to `true` if `portaldb.host` is an endpoint outside of the kubernetes cluster | `false` | | `portaldb.service.fullNameOverride` | Override the service name for apollo portal db | `nil` | | `portaldb.service.port` | The port for the service of apollo portal db | `3306` | | `portaldb.service.type` | The service type of apollo portal db: `ClusterIP` or `ExternalName`. If the host is a DNS name, please specify `ExternalName` as the service type, e.g. `xxx.mysql.rds.aliyuncs.com` | `ClusterIP` | ```yaml portaldb: host: 1.2.3.4 dbName: ApolloPortalDBName userName: someUserName password: somePassword connectionStringProperties: characterEncoding=utf8&useSSL=false service: enabled: true ``` ```yaml portaldb: host:

dbName: ApolloPortalDBName userName: someUserName password: somePassword connectionStringProperties: characterEncoding=utf8&useSSL=false service: enabled: true type: ExternalName ``` ```yaml portaldb: host: apollodb-mysql.mysql dbName: ApolloPortalDBName userName: someUserName password: somePassword connectionStringProperties: characterEncoding=utf8&useSSL=false ``` ```yaml config: envs: dev, pro metaServers: dev: http://apollo-service-dev-apollo-configservice:8080 pro: http://apollo-service-pro-apollo-configservice:8080 ``` ```yaml service: type: LoadBalancer ``` ```yaml ingress: enabled: true hosts: paths: / ``` ```yaml ingress: enabled: true hosts: paths: /apollo config: ... contextPath: /apollo ... ``` ```yaml ingress: enabled: true annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/affinity-mode: "persistent" nginx.ingress.kubernetes.io/session-cookie-conditional-samesite-none: "true" nginx.ingress.kubernetes.io/session-cookie-expires: "172800" nginx.ingress.kubernetes.io/session-cookie-max-age: "172800" hosts: host: xxx.somedomain.com # host is required to make session affinity work paths: / ``` ```yaml config: ... profiles: github,ldap ... files: application-ldap.yml: | spring: ldap: base: "dc=example,dc=org" username: "cn=admin,dc=example,dc=org" password: "password" searchFilter: "(uid={0})" urls: "ldap://xxx.somedomain.com:389" ldap: mapping: objectClass: "inetOrgPerson" loginId: "uid" userDisplayName: "cn" email: "mail" ``` If you have modified the code of the apollo server and want to build a Docker image from source code, you can refer to the steps in . Thanks to for providing k8s deployment support, please refer to . Thanks to for Helm Chart deployment support, please refer to for usage instructions. The following configurations are supported not only in the database, but also through -D parameters, application.properties, etc., and -D parameters, application.properties, etc. have higher priority than the configuration in the database Configuration items are uniformly stored in ApolloPortalDB.ServerConfig table, and can also be configured through `Administrator Tools - System Parameters` page, without special instructions, the modification will take effect in real time after one minute. The default value is dev, if portal needs to manage multiple environments, just separate them by commas (case insensitive), e.g. ``` DEV,FAT,UAT,PRO ``` After the modification needs to reboot to take effect. Note 1: A set of Portal can manage multiple environments, but each environment needs to deploy a separate set of Config Service, Admin Service and ApolloConfigDB, please refer to: , , , and if you are adding an environment to Apollo Configuration Center that has been running for a while, don't forget to refer to to do the initialization of the new environment. Note 2: Adding the environment to the database only does not work, you also need to add the meta server address corresponding to the new environment for apollo-portal, refer to: . portal's meta-service information). apollo-client also needs to be configured accordingly when used in a new environment, refer to: . Note 3: If you wish to add a custom environment name, you can refer to . Note 4: Version 1.1.0 added the system information page (`Administrator Tools` -> `System Information`), you can check whether the configuration is correct through this page For version 1.6.0 and above Apollo Portal needs to access different meta service (apollo-configservice) addresses in different environments, so we need to provide this information in the configuration. By default, the meta service and config service are deployed in the same JVM process, so the address of the meta service is the address of the config service. Sample example is as follows. ```json { "DEV": "http://1.1.1.1:8080", "FAT": "http://apollo.fat.xxx.com", "UAT": "http://apollo.uat.xxx.com", "PRO": "http://apollo.xxx.com" } ``` A reboot is required to take effect after the modification. This configuration has a higher priority than the Meta Service address set in other ways. For more information, please refer to . All new apps in the Portal need to select departments, so you need to configure optional department information here, sample example is as follows ```json [{"orgId": "TEST1", "orgName": "Sample Department 1"},{"orgId": "TEST2", "orgName": "Sample Department 2"}] ``` The superAdmin has all privileges and needs to be set up

If you don't have access to your company's SSO system, you can use the default value apollo (default user) for now. When you have access to it, change it to the actual account used, with multiple accounts separated by English commas (,). You can set a token salt if you will use the open platform API, but ignore it if you don't. The address of the "help" link on the portal, the default is the Apollo github wiki home page, you can set it yourself. Whether to allow project admins to create private namespace. set to `true` to allow creation, set to `false` to prevent project admins from seeing the option to create private namespace on the page. Configure a list of environments that allow emergency publishing, with multiple envs separated by commas. When the config service turns on the only one person can modify switch (`namespace.lock.switch`) for one publish, only one person can modify and another publish a configuration publish. In order to avoid not being able to publish the configuration in case of emergency (e.g. out-of-hours, holidays), you can configure this to allow some environments to operate emergency publishing, i.e. the same person can modify and publish the configuration. A list of environments that display configuration information only to project members, with multiple envs separated by commas. For environments that are set to display configuration information only to project members, only the administrator of the project or users with edit or publish privileges for that namespace can see the configuration information and publish history for that private namespace. Public namespaces are always visible to all users. Supported since version 1.1.0, see For versions 1.5.0 and above Default is false, all users can create projects If set to true, only super administrators and accounts with create-application privileges can create projects. Super administrators can assign project creation privileges to users via `Administrator Tools - System Rights Management`. For versions 1.5.0 and above Default is false, all project administrators can add/remove administrators for the project If set to true, only super administrators and accounts with project administrator assignment privileges can add/remove administrators for a specific project, and super administrators can assign project-specific administrator assignment privileges to users via `Administrator Tools - System Rights Management for version 1.7.1 and above If the corresponding environment apollo-adminservice has , then you need to configure apollo-portal access here access token required for this environment apollo-adminservice, otherwise access will fail . The format is json, as follows. ```json { "dev" : "098f6bcd4621d373cade4e832627b4f6", "pro" : "ad0234829205b9033196ba818f7a872b" } ``` The default is true, which makes it easy to quickly search for configurations by configuration item If set to false, this feature is disabled Configuration items are uniformly stored in the ApolloConfigDB.ServerConfig table. It should be noted that each environment's ApolloConfigDB.ServerConfig needs to be configured separately, and the modification takes effect in real time for one minute afterwards. Not applicable to Kubernetes-based native service discovery scenarios Both apollo-configservice and apollo-adminservice need to register with the eureka service, so the eureka service address needs to be configured. According to the current implementation, apollo-configservice itself is an eureka service, so you only need to fill in the address of apollo-configservice, separated by commas if there is more than one (be careful not to forget the /eureka/ suffix). It should be noted that each environment only fills in the eureka service address of its own environment, for example, apollo-config service for FAT is 1.1.1.1:8080 and 2.2.2.2:8080, apollo-config service for UAT is 3.3.3.3:8080 and 4.4.4.4: 8080, and the apollo-configigservice for PRO is 5.5.5.5:8080 and 6.6.6.6:8080, then. set eureka.service.url in the

table of the FAT environment to ``` http://1.1.1.1:8080/eureka/,http://2.2.2.2:8080/eureka/ ``` set eureka.service.url in ApolloConfigDB.ServerConfig table of UAT environment to ``` http://3.3.3.3:8080/eureka/,http://4.4.4.4:8080/eureka/ ``` Set eureka.service.url in the ApolloConfigDB.ServerConfig table of the PRO environment to ``` http://5.5.5.5:8080/eureka/,http://6.6.6.6:8080/eureka/ ``` Note 1: Here you need to fill in the address of all the eureka services in this environment, because eureka needs to copy each other's registration information Note 2: If you want to register Config Service and Admin Service to the company's unified Eureka, you can refer to section Note 3: In multi-cluster deployments, you often want the config service and admin service to register only with the eureka in the same room. To achieve this, you need to use the cluster field in the `ServerConfig` table, and the config service and admin service will read the `/opt/settings/server.properties` (Mac/Linux) or `C:\opt\settings\server.properties` (Windows), and if the idc has a corresponding eureka.service.url configuration, then will only register with eureka for that server room. For example, if the config service and admin service are deployed to two IDCs, `SHAOY` and `SHAJQ`, then in order to register the services in these two server rooms only with that server room, you can add two new records in the `ServerConfig` table and fill in the `SHAOY` and `SHAJQ` server room eureka addresses respectively. If there are config service and admin service that are not deployed in `SHAOY` and `SHAJQ`, this default configuration will be used. | Key | Cluster | Value | Comment | | | - | | - | | eureka.service.url | default | http://1.1.1.1:8080/eureka/ | Default Eureka Service Url | | eureka.service.url | SHAOY | http://2.2.2.2:8080/eureka/ | Eureka Service Url for SHAOY | | eureka.service.url | SHAJQ | http://3.3.3.3:8080/eureka/ | Eureka Service Url for SHAJQ | This is a functional switch, if configured to true, then only one person can modify and another publish at a time for a configuration release. This option is recommended for production environments This is a function switch, if configured to true, config service will cache the loaded configuration information to speed up the performance of subsequent configuration fetches. The default is false. Please evaluate the total configuration size and adjust the config service memory configuration before turning it on. Ensure that the `app.id``apollo.cluster` of the configuration in the application is in the correct case when caching is enabled, otherwise it will not fetch the correct configuration, You can also refer to the `config-service.cache.key.ignore-case` configuration for compatibility processing. `config-service.cache.enabled` configuration adjustment requires a restart of the config service to take effect For versions 2.2.0 and above This configuration takes effect when config-service.cache.enabled is set to true, and controls whether the configuration cache key ignores case. The default value is false, which means that cache keys are strictly case-sensitive. In this case, it is necessary to ensure that the capitalization of app.id and apollo.cluster configured in the application is correct, otherwise the correct configuration cannot be obtained. It can be configured as true to ignore case sensitivity. This configuration is used to be compatible with the configuration acquisition logic when the cache is not enabled, because MySQL database queries are case-insensitive by default. If the cache is enabled and MySQL is used, it is recommended to configure it as true. If the database used by your Apollo is case-sensitive, you must keep the default configuration as false, otherwise the configuration cannot be obtained. The default configuration is 128. The default configuration is 20000. This configuration is used to override the

configuration to achieve fine-grained control of the namespace's value maximum length limit, the configured value is a json format, the key of the json is the id value of the namespace in the database, the format is as follows. ``` namespace.value.length.limit.override = {1:200,3:20} ``` The above configuration specifies a maximum length limit of 200 for the value of namespace with id=1 and 20 for the value of namespace with id=3 in the ApolloConfigDB.Namespace table For versions 1.7.1 and above Default is false, if configured to true, then apollo-portal needs to be to access the access token of that environment, otherwise access will be denied For versions 1.7.1 and above If this configuration item is empty, then access control will not take effect. If multiple tokens are allowed, the tokens are separated by commas Example. ```properties admin-services.access.tokens=098f6bcd4621d373cade4e832627b4f6 admin-services.access.tokens=098f6bcd4621d373cade4e832627b4f6,ad0234829205b9033196ba818f7a872b ``` For version 2.0.0 and above The default value is 60, in seconds. Since the key authentication needs to verify the time, there may be time deviation between the time of the client and the time of the server, if the deviation is too large, the authentication will fail, this configuration can configure the tolerated time deviation size, the default is 60 seconds. For version 2.1.0 and above The default value is false, if you want to improve security (such as when apollo is exposed to the public network), you can enable login authentication for eureka by setting this configuration to true. Note that if eureka login authentication is enabled, the addresses in needs to be configured with a user name and password, such as: ``` http://some-user-name:some-password@1.1.1.1:8080/eureka/, http://some-user-name:some-password@2.2.2.2:8080/eureka/ ``` Among them, `some-user-name` and `some-password` need to be consistent with the configuration items of `apollo.eureka.server.security.username` and `apollo.eureka.server.security.password`. A reboot is required to take effect after the modification. For version 2.1.0 and above Configure the login username of eureka server, which needs to be used together with . A reboot is required to take effect after the modification. Note that the username cannot be configured as apollo. For version 2.1.0 and above Configure the login password of eureka server, which needs to be used together with . A reboot is required to take effect after the modification. For version 2.2.0 and above The default value is -1, which means there is no limit on the number of retained release history. If the configuration is set to a positive integer(The minimum value is 1, which means at least one record of history must be kept to ensure the basic configuration functionality), only the specified number of recent release histories will be kept. This is to prevent excessive database pressure caused by too many release histories. It is recommended to configure this value based on the business needs for configuration rollback. This configuration item is global and cleaned up based on appId + clusterName + namespaceName + branchName. For version 2.2.0 and above This configuration is used to override the `apollo.release-history.retention.size` configuration and achieve granular control over the number of retained release histories for appId+clusterName+namespaceName+branchName. The value of this configuration is in JSON format, with the JSON key being the concatenated value of appId, clusterName, namespaceName, and branchName using a `+` sign. The format is as follows: ``` json { "kl+bj+namespace1+bj": 10, "kl+bj+namespace2+bj": 20 } ``` The above configuration specifies that the retention size for release history of appId=kl, clusterName=bj, namespaceName=namespace1, and branchName=bj is 10, and the retention size for release history of appId=kl, clusterName=bj, namespaceName=namespace2, and branchName=bj is 20. In general, branchName equals clusterName. It is only different during gray release, where the branchName needs to be confirmed by querying the ReleaseHistory table in the database.