Skip to content

Apollo multi-environment deployment strategy

The Apollo multi-environment deployment strategy is an approach to managing application configurations across distinct environments—such as testing (fat) and production (pro)—using a single container image. This strategy leverages Kubernetes Namespaces and environment-specific configurations to allow code to remain static while configurations change dynamically based on the deployment context^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].

Core Principles

The primary goal of this strategy is to ensure that a single application artifact (e.g., a Docker image) can be deployed to multiple environments without modification. By decoupling the configuration from the application binary, developers can promote the exact same image through the testing and production pipeline, reducing the risk of "configuration drift" and eliminating the need to rebuild images for different stages^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].

Infrastructure Implementation

Namespace Isolation

The strategy relies heavily on Kubernetes Namespaces to logically separate environments.

  • Namespace Creation: Distinct namespaces, such as test and prod, are created to isolate resources^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].
  • Deployment: Identical application manifests (Deployments, Services, Ingress) are applied to these respective namespaces.

Database Architecture

Apollo requires separate database instances or schemas to store configuration for each environment.

  • Databases: Separate MySQL databases are created for each environment (e.g., ApolloConfigTestDB, ApolloConfigProdDB)^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].
  • Server Configuration: The eureka.service.url in each database's ServerConfig table is updated to point to the environment-specific Apollo Config Service (e.g., http://config-test.od.com/eureka for test, http://config-prod.od.com/eureka for prod)^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].

Domain and Service Routing

  • DNS Configuration: Specific DNS records are created for the Config Services of each environment. For example, config-test.od.com and config-prod.od.com are both mapped to the Kubernetes cluster Ingress IP (e.g., 10.4.7.10)^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].
  • Application Routing: Similarly, application domains are segmented, such as demo-test.od.com for the testing environment and demo-prod.od.com for production^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].

Application Configuration

Environment Variables

To direct the application to the correct Apollo environment and configuration server, specific environment variables are injected into the Kubernetes Deployment manifests^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].

  • C_OPTS: This Java options variable is used to pass critical runtime arguments to the application.
    • -Denv: Identifies the Apollo environment profile (e.g., -Denv=fat for testing, -Denv=pro for production)^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].
    • -Dapollo.meta: Specifies the address of the Meta Server (Config Service). This can be the public URL (e.g., http://config-test.od.com) or, if the application resides in the same namespace as the Apollo Config Service, the internal Kubernetes Service DNS (e.g., http://apollo-configservice:8080)^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].

Example Manifest Snippet

# Example for Testing Environment
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: dubbo-demo-service
  namespace: test
spec:
  template:
    spec:
      containers:
      - name: dubbo-demo-service
        image: harbor.od.com/app/dubbo-demo-service:apollo_tag
        env:
        - name: C_OPTS
          value: "-Denv=fat -Dapollo.meta=http://config-test.od.com"

Deployment Workflow

This strategy supports a streamlined CI/CD process where the artifact is built once and deployed multiple times^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].

  1. Image Build: An application is built and tagged (e.g., apollo_200304_1730) in Jenkins or a similar CI tool.
  2. Test Deployment: The image tag is updated in the test namespace deployment manifest. The application starts, connects to the ApolloConfigTestDB via config-test.od.com, and loads the test-specific configurations.
  3. Production Deployment: Once verified, the same image tag is updated in the prod namespace deployment manifest. The application connects to ApolloConfigProdDB via config-prod.od.com (or internal service DNS) to load production configurations.

This separation ensures that the testing team can verify the exact binary that will go to production, while operations teams maintain strict control over production configuration values through the Apollo Portal^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md].

Sources

^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]