Project: Apollo (Provisioning / Automation & Configuration)
File: common-issues-in-deployment-and-development-phase.md

Install , then run `./build.sh` Note the first `./` By default config service starts on port 8080 and admin service starts on port 8090. Please check if these two ports are occupied by other applications. If there is also an exception message: org.springframework.web.client.HttpClientErrorException: 405 Method Not Allowed, it is usually due to the local startup of `ShadowSocks`, because `ShadowSocks` will occupy port 8090 by default. port 8090 by default. Version 1.1.0 added System Information page, you can view the current Meta Server and admin service information of each environment through `Administrator Tools` -> `System Information` to help troubleshoot the problem. Please refer to . Version 1.6.0 adds the ability to customize the environment, which allows you to add an environment without modifying the code add environment for protaldb, refer to add the meta server address corresponding to the new environment for apollo-portal, refer to: . apollo-client also needs to be configured properly when used in a new environment, refer to: . Note 1: A set of Portal can manage multiple environments, but each environment needs to deploy a set of Config Service, Admin Service and ApolloConfigDB independently, please refer to: , , Note 2: If you are adding an environment to Apollo Configuration Center that has been running for a while, don't forget to refer to to initialize the new environment If the environment to be added is an Apollo pre-defined environment (DEV, FAT, UAT, PRO), two steps are required. protaldb add environment, refer to add the meta server address corresponding to the new environment for apollo-portal, refer to: . apollo-client also needs to be configured properly when used in a new environment, refer to: . Note 1: A set of Portal can manage multiple environments, but each environment needs to deploy a set of Config Service, Admin Service and ApolloConfigDB independently, please refer to: , , Note 2: If you are adding an environment to Apollo Configuration Center that has been running for a while, don't forget to refer to to initialize the new environment Note 3: 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". If the environment to be added is not one of Apollo's pre-defined environments, please refer to the following steps. Assume the name of the environment to be added is beta Modify class by adding the ``BETA`` enumeration to it. ```java public enum Env{ LOCAL, DEV, BETA, FWS, FAT, UAT, LPT, PRO, TOOLS, UNKNOWN; ... } ``` Modify the class to include conversion logic for the `BETA` enumeration. ```java public final class EnvUtils { public static Env transformEnv(String envName) { if (StringUtils.isBlank(envName)) { return Env.UNKNOWN; } switch (envName.trim().toUpperCase()) { ... case "BETA": return Env.BETA; ... default: return Env.UNKNOWN; } } } ``` Modify to add the ``beta.meta`` placeholder. ```properties local.meta=http://localhost:8080 dev.meta=${dev_meta} fat.meta=${fat_meta} beta.meta=${beta_meta} uat.meta=${uat_meta} lpt.meta=${lpt_meta} pro.meta=${pro_meta} ``` Modify the class to add logic to read the meta server address of the ``BETA`` environment. ```java public class LegacyMetaServerProvider { ... domains.put(Env.BETA, getMetaServerAddress(prop, "beta_meta", "beta.meta"));

} ``` Add `BETA` environment for protaldb, refer to Add the meta server address corresponding to the new environment for apollo-portal, refer to: . apollo-client also needs to be configured properly when used in a new environment, refer to: . Note 1: A set of Portal can manage multiple environments, but each environment needs to deploy a set of Config Service, Admin Service and ApolloConfigDB independently, please refer to: , , Note 2: If you are adding an environment to Apollo Configuration Center that has been running for a while, don't forget to refer to to initialize the new environment From version 0.11.0 Apollo Administrator has added a page to delete applications, clusters and AppNamespace, we recommend to use this page to delete them. Page entry : Page details : The logic of getting client NIC has been adjusted in version 1.4.0, so you need to differentiate according to client version If there are multiple NICs and they are all normal NICs, you need to add a mapping relationship in /etc/hosts to raise the weight. Format: `ip ${hostname}` Here ${hostname} is the result of your execution of hostname on the machine. For example, if the correct IP is: 192.168.1.50, the result of the hostname execution is: jim-ubuntu-pc Then the final record mapped in the hosts file is ``` 192.168.1.50 jim-ubuntu-pc ``` If you have multiple NICs and they are all normal NICs, you can change the priority by adjusting their order in the system, with the first in the order having higher priority. You can refer to in the project and code examples. Apollo comes with Eureka as an internal registry implementation by default, and there is generally no need to consider deploying a separate registry for Apollo. However, some companies already have a set of Eureka, if you want to register Apollo's Config Service and Admin Service to achieve unified management, you can follow the steps below. Configure apollo-configService with `apollo.eureka.server.enabled=false`, either through bootstrap.yml or the -D parameter. Modify , change `@EnableEurekaServer` to `@ EnableEurekaClient` ```java @EnableEurekaClient @EnableAspectJAutoProxy @EnableAutoConfiguration // (exclude = EurekaClientConfigBean.class) @Configuration @EnableTransactionManagement @PropertySource(value = {"classpath:configservice.properties"}) @ComponentScan(basePackageClasses = {ApolloCommonConfig.class, ApolloBizConfig.class, ConfigServiceApplication.class, ApolloMetaServiceConfig.class}) public class ConfigServiceApplication { ... } ``` For example, if your own Eureka service address is 1.1.1.1:8761 and 2.2.2.2:8761, then set `eureka.service.url` in `ApolloConfigDB.ServerConfig` table with: ``` http://1.1.1.1:8761/eureka/,http://2.2.2.2:8761/eureka/ ``` Note that changing the Eureka address only requires changing the `eureka.service.url` in the `ApolloConfigDB.ServerConfig` table, not the meta server address. 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, so you don't need to change the meta server address when you modify the Eureka address. The `@ConditionalOnProperty` feature is supported since version 0.10.0, see Please refer to , in this case, because the Chinese and American server rooms are far away from each other, so the config db needs to be deployed in two places. If it is a multi-city machine room, the config service of both machine rooms can be connected to one config

Each service of apollo has `/health` page, which is used by apollo to do health check and supports various request methods such as GET, POST, HEAD, etc. Starting from version 1.1.0, apollo-portal adds support for view permissions, which allows you to configure an environment to allow only project members to view the private Namespace. The project members here are The project's administrator Have the permission to modify or publish the private Namespace in that environment The configuration is very simple, after logging in with the super administrator account, go to `Administrator Tools - System Parameters` page to add or modify `configView.memberOnly.envs` configuration items. Some companies' O&M policies may require that they must use a standalone tomcat to run their applications and do not allow apollo to run in the default startup.sh way. The following is a brief example of how to make the apollo server run in a standalone tomcat. Get the apollo code (the release version is recommended for production deployments) Modify the apollo-configservice pom.xml and add `<packaging>war</packaging>`. Configure build.sh according to the distributed deployment documentation, and then package it Put the apollo-configservice war package under tomcat cp apollo-configservice/target/apollo-configservice-xxx.war ${tomcat-dir}/webapps/ROOT.war Run tomcat's startup.sh Run tomcat's startup.sh In addition, apollo has some tuning parameters that are recommended to be configured in tomcat's server.xml, which can be found in Many company microservice projects are already using zookeeper, if you want to replace Eureka with zookeeper for the purpose of easy service management, you can refer to the transformation steps contributed by : Refer to In general it is recommended to use the root directory directly to mount the portal, however if there are cases where you want to share nginx/slb with other applications and need to add a relative path (e.g. /apollo), then you can configure it as follows. First add the `-D` parameter `server.servlet.context-path=/apollo` or the system environment variable `SERVERSERVLETCONTEXT_PATH=/apollo` for apollo-portal. Then just configure forwarding on nginx/slb, using nginx as an example. ``` location /apollo/ { proxysetheader X-Forwarded-Host $host; proxysetheader X-Forwarded-Server $host; proxysetheader X-Forwarded-For $proxyaddxforwardedfor; proxy_pass http://127.0.0.1:8070/apollo/; } ``` First add the `prefix.path=/apollo` configuration parameter to the portal, the configuration is very simple, after logging in with the super administrator account, go to the `Administrator Tools - System Parameters` page and add or modify the `prefix.path` configuration item. Then you can configure forwarding on nginx/slb, using nginx as an example. ``` location /apollo/ { proxysetheader X-Forwarded-Host $host; proxysetheader X-Forwarded-Server $host; proxysetheader X-Forwarded-For $proxyaddxforwardedfor; proxy_pass http://127.0.0.1:8070/; } ``` configure https access configuration on nginx/slb, taking nginx as an example: ``` server { listen 80 default_server; location / { return 301 https://$httphost$requesturi; } } server { listen 443 ssl http2; server_name your-domain-name; ssl_certificate /etc/nginx/ssl/xxx.crt; sslcertificatekey /etc/nginx/ssl/xxx.key; location / { proxy_pass http://apollo-portal-address:8070; proxysetheader x-real-ip $remote_addr; proxysetheader x-forwarded-for $proxyaddxforwardedfor; proxysetheader host $http_host; proxysetheader x-forwarded-proto $scheme; proxyhttpversion 1.1; } } ``` Configure apollo-portal to parse the header information from the reverse proxy Modify application-github.properties under the config directory in the apollo-portal installation package and add the following configuration: ```properties server.forward-headers-strategy=framework ``` It can also be configured through environment variables: ``` SERVERFORWARDHEADERS_STRATEGY=framework ```