Detailed tutorial on deploying Apollo custom environment with docker-compose

What is the Apollo Configuration Center?

Apollo is an open source configuration management center developed by Ctrip's framework department. It can centrally manage the configuration of different application environments and clusters. After the configuration is modified, it can be pushed to the application end in real time, and it has standardized permissions, process governance and other features.

Features of Apollo

• Centralized management of configurations in different environments and clusters

Apollo provides a unified interface to centrally manage the configuration of different environments, clusters, and namespaces.
The same code deployed in different clusters can have different configurations, such as the address of Zookeeper. Namespaces can easily support multiple different applications to share the same configuration, while also allowing applications to overwrite the shared configuration.

• Configuration changes take effect in real time (hot release)
  

After the user modifies the configuration in Apollo and publishes it, the client can receive the latest configuration in real time (1 second) and notify the application

• Version release management
  

All configuration releases have a version concept, which can easily support configuration rollback

• Grayscale release

Supports grayscale release of configurations. For example, after clicking Release, it will only take effect on some application instances, and then be pushed to all application instances after observing for a period of time without any problems.

• Permission management, release review, and operation audit
  

There is a complete permission management mechanism for application and configuration management. Configuration management is also divided into two parts: editing and publishing, which reduces human errors.
All operations have audit logs, which can easily track problems

• Client configuration information monitoring
  

You can easily see which instances are using the configuration on the interface.

• Provide Java and .Net native clients

.Net native client, convenient for application integration, and provides Http interface, non-Java and .Net applications can also be used easily

• Provide open platform API
  

Apollo itself provides a relatively complete unified configuration management interface, supporting multi-environment, multi-data center configuration management, permissions, process governance and other features. However, for the sake of universality, Apollo does not impose too many restrictions on configuration changes. As long as it conforms to the basic format, it can be saved. There will be no targeted verification of different configuration values, such as database username, password, Redis service address, etc. For this type of application configuration, Apollo supports the application party to modify and publish the configuration in Apollo through the open platform API, and has complete authorization and permission control.

• Simple deployment

As a basic service, the configuration center has very high availability requirements, which requires Apollo to have as few external dependencies as possible. Currently, the only external dependency is MySQL, so the deployment is very simple. As long as Java and MySQL are installed, Apollo can run.
Apollo also provides a packaging script that can generate all the required installation packages with one click, and supports custom runtime parameters

Client Architecture

Architecture and modules

1: Config Service provides functions such as configuration reading and pushing, and the service object is the Apollo client

• Provides configuration acquisition interface
• Provides configuration update push interface (based on Http long polling)

The server uses Spring DeferredResult to achieve asynchrony, which greatly increases the number of long connections. The current default configuration of tomcat embed is a maximum of 10,000 connections (which can be adjusted). The 4C8G virtual machine can support 10,000 connections, so it meets the requirements (one application instance will only initiate one long connection).

• The interface service object is Apollo client

2. Admin Service provides functions such as configuration modification and publishing, and its service object is Apollo Portal (management interface)

• Provides configuration management interface
• Provide configuration modification, publishing and other interfaces
• The interface service object is Portal

3. Meta Server We built a Meta Server on top of Eureka to encapsulate Eureka's service discovery interface

• Portal accesses Meta Server through domain name to obtain Admin Service service list (IP+Port)
• The client accesses the Meta Server through the domain name to obtain the Config Service service list (IP+Port)
• Meta Server obtains the service information of Config Service and Admin Service from Eureka, which is equivalent to a Eureka Client
• The purpose of adding a Meta Server role is to encapsulate the details of service discovery. For Portal and Client, they always obtain the service information of Admin Service and Config Service through an Http interface without having to care about the actual service registration and discovery components behind them.
• Meta Server is just a logical role. When deployed, it is in the same JVM process as Config Service, so the IP and port are consistent with Config Service.
  

Four: A service discovery component of Eureka java

• Service registration and discovery based on Eureka and Spring Cloud Netflix
• Config Service and Admin Service will register services with Eureka and maintain heartbeat
• For simplicity, Eureka is currently deployed in the same JVM process as the Config Service (via Spring Cloud Netflix).
  

Five: Portal

• Provides a web interface for users to manage configurations
• Get the Admin Service list (IP+Port) through Meta Server and access the service through IP+Port
• Perform load balancing and error retry on the Portal side
  

6. Client

• The client program provided by Apollo provides functions such as configuration acquisition and real-time update for applications
• Get the Config Service service list (IP+Port) through Meta Server and access the service through IP+Port
• Perform load balancing and error retry on the client side
  

deploy

1. Currently we have multiple development environments: dev, devmt, uat, etc. Apollo can be deployed in multiple environments, and you need to specify the environment to deploy
2. Apollo is deployed in multiple environments. Config Service and Admin Service need to be deployed separately according to the environment. Portal can be deployed in only one copy to manage all environments.
3. GitHub download: https://github.com/ctripcorp/apollo source code
4. Custom environment variable source code modification, it is recommended to check the github document file of the source code for the specific path of the code

Env com.ctrip.framework.apollo.core.enums add DEVMT

public enum Env{
  LOCAL, DEV, FWS, FAT, UAT, LPT, PRO, TOOLS, UNKNOWN, DEVMT;

  public static Env fromString(String env) {
    Env environment = EnvUtils.transformEnv(env);
    Preconditions.checkArgument(environment != UNKNOWN, String.format("Env %s is invalid", env));
    return environment;
  }
}

EnvUtils com.ctrip.framework.apollo.core.enums add DEVMT

public final class EnvUtils {
  
  public static Env transformEnv(String envName) {
    if (StringUtils.isBlank(envName)) {
      return Env.UNKNOWN;
    }
    switch (envName.trim().toUpperCase()) {
      case "LPT":
        return Env.LPT;
      case "FAT":
      case "FWS":
        return Env.FAT;
      case "UAT":
        return Env.UAT;
      case "PRO":
      case "PROD": //just in case
        return Env.PRO;
      case "DEV":
        return Env.DEV;
      case "LOCAL":
        return Env.LOCAL;
      case "TOOLS":
        return Env.TOOLS;
      case "DEVMT":
        return Env.DEVMT;
      default:
        return Env.UNKNOWN;
    }
  }
}

LegacyMetaServerProvider com.ctrip.framework.apollo.core.internals add DEVMT

private void initialize() {
    Properties prop = new Properties();
    prop = ResourceUtils.readConfigFile("apollo-env.properties", prop);

    domains.put(Env.LOCAL, getMetaServerAddress(prop, "local_meta", "local.meta"));
    domains.put(Env.DEV, getMetaServerAddress(prop, "dev_meta", "dev.meta"));
    domains.put(Env.FAT, getMetaServerAddress(prop, "fat_meta", "fat.meta"));
    domains.put(Env.UAT, getMetaServerAddress(prop, "uat_meta", "uat.meta"));
    domains.put(Env.LPT, getMetaServerAddress(prop, "lpt_meta", "lpt.meta"));
    domains.put(Env.PRO, getMetaServerAddress(prop, "pro_meta", "pro.meta"));
    domains.put(Env.SIT, getMetaServerAddress(prop, "devmt_meta", "devmt.meta"));
  }

Check, install JAVA JDK and Maven, enter the source code folder Scripts and execute the Build file to compile and package apollo

Copy apollo-configservice/target, apollo-adminservice/target, apollo-portal/target, the zip files and Dockerfile under the files to the specified folder, as shown below

Modify the version numbers of configservice, adminservice, portal, and Dockerfile files to be consistent with the version numbers of the zip files.

Find the sql deployment script under the Scripts folder of the source code and execute it in Mysql.

Modify apolloconfigdb, the address of eureka.service.url is the address where Configservice is deployed, for example, http://192.168.xx.xxx:8081/eureka/,

Modify portal's apollo.portal.envs to: environment variables for multi-environment deployment, such as dev, devmt

Modify portal's apollo.portal.meta.servers to the address of the deployed Configservice, for example

{
    "DEV":"http://192.168.xx.xxx:8081",
    "DEVMT":"http://192.168.xx.xxx:8082"
}

Write docker-compose.yml

version: "3"
services:
  apollo-configservice:
    container_name: apollo-configservice
    build: apollo-configservice/ 
    image: apollo-configservice
    ports:
      -8081:8080
    volumes:
      - /root/apollo/apollocompose/logs:/opt/logs
    environment:
      - SPRING_DATASOURCE_URL= jdbc:mysql://192.168.xx.xxx:3306/apolloconfigdbdev?characterEncoding=utf8&serverTimezone=Asia/Shanghai
      -SPRING_DATASOURCE_USERNAME=xxxxxx
      -SPRING_DATASOURCE_PASSWORD=xxxxxx

  apollo-adminservice:
    container_name: apollo-adminservice
    build: apollo-adminservice/ 
    image: apollo-adminservice
    ports:
      -8091:8090
    volumes:
      - /root/apollo/apollocompose/logs:/opt/logs
    environment:
      - SPRING_DATASOURCE_URL= jdbc:mysql://192.168.xx.xxx:3306/apolloconfigdbdev?characterEncoding=utf8&serverTimezone=Asia/Shanghai
      -SPRING_DATASOURCE_USERNAME=xxxxxx
      -SPRING_DATASOURCE_PASSWORD=xxxxxx
  
  apollo-configservice-uat:
    container_name: apollo-configservice-uat
    build: apollo-configservice/ 
    image: apollo-configservice
    ports:
      -8082:8080
    volumes:
      - /root/apollo/apollocompose/logs:/opt/logs
    environment:
      - SPRING_DATASOURCE_URL= jdbc:mysql://192.168.xx.xxx:3306/apolloconfigdbuat?characterEncoding=utf8&serverTimezone=Asia/Shanghai
      -SPRING_DATASOURCE_USERNAME=xxxxxx
      -SPRING_DATASOURCE_PASSWORD=xxxxxx

  apollo-adminservice-uat:
    container_name: apollo-adminservice-uat
    build: apollo-adminservice/ 
    image: apollo-adminservice
    ports:
      -8092:8090
    volumes:
      - /root/apollo/apollocompose/logs:/opt/logs
    environment:
      - SPRING_DATASOURCE_URL= jdbc:mysql://192.168.xx.xxx:3306/apolloconfigdbuat?characterEncoding=utf8&serverTimezone=Asia/Shanghai
      -SPRING_DATASOURCE_USERNAME=xxxxxx
      -SPRING_DATASOURCE_PASSWORD=xxxxxx
  
  apollo-portal:
    container_name: apollo-portal
    build: apollo-portal/
    image: apollo-portal
    restart: always
    depends_on:
      - apollo-adminservice
    environment:
      - SPRING_DATASOURCE_URL= jdbc:mysql://192.168.xx.xxx:3306/apolloportaldb?characterEncoding=utf8&serverTimezone=Asia/Shanghai
      -SPRING_DATASOURCE_USERNAME=xxxxxx
      -SPRING_DATASOURCE_PASSWORD=xxxxxx
    volumes:
      - /root/apollo/apollocompose/logs:/opt/logs
      - /root/apollo/apollocompose/apollo-env.properties:/apollo-portal/config/apollo-env.properties
    ports:
      -8071:8070

Modify the local apollo-env.properties environment variable configuration to be consistent with the custom configuration or the environment variables defined by Ctrip

dev.meta=http://localhost:8081
devmt.meta=http://localhost:8082

Execute docker-compose, there is a delay in starting, wait a little longer

Pitfalls

Custom environment variables require downloading source code, compilation, sql scripts and database connection configuration. Be sure to use the latest connection configuration on the official website. Different versions may have inconsistent sql scripts. The deployment machine must have sufficient running memory. After deployment and startup, configservice, adminservice, portal, Mata service, and Eureka need to communicate, so there is a delay after startup. Wait for a while to see if the deployment is successful. For server ports, the firewall needs to open the corresponding ports, 8080, 8090, 8071 and the ports you specify.

Study Links

Mr. Yang Bo's architecture analysis article: https://blog.csdn.net/yang75108/article/details/86989524?spm=1001.2014.3001.5501

Apollo design documentation: https://www.apolloconfig.com/

Apollo builds a custom environment: https://www.jianshu.com/p/f84da093944f

The above is the details of docker-compose deployment of Apollo custom environment. For more information about docker-compose deployment of Apollo environment, please pay attention to other related articles on 123WORDPRESS.COM!