DOCSEARCHbyAlgolia
Submit Docs

Apollo Configuration Management System

repository·master·Indexed 12 days ago

https://github.com/apolloconfig/apollo

A centralized, reliable configuration management system optimized for microservices. Apollo provides real-time updates, versioning, and grayscale release capabilities across multiple environments and clusters. It features native SDKs for Java (including Spring Boot support) and .NET, HTTP APIs for other languages, and Open Platform APIs for custom validation and complex configuration formats.

Tokens
66K
Snippets
149
Records
270
Agent score
94%

What's inside Apollo

  1. Overview of Apollo Configuration Management

    master

    Apollo is a reliable configuration management system designed for microservice architectures. It provides centralized management for configurations across different applications, environments, and clusters.

    Key capabilities include:

    • Unified Management: Centralized control over environments, clusters, and namespaces.
    • Real-time Updates (Hot Release): Configuration changes are pushed to SDKs in real-time (typically within 1 second).
    • Version Control: Every configuration release is versioned, enabling easy rollbacks.
    • Grayscale Release: Supports gradual rollout of configurations to a subset of application instances for observation before full deployment.
    • Global Search: Fuzzy search capabilities to locate configuration keys and values across the entire system.
    • Security & Audit: Includes authorization mechanisms, release approval workflows, and full operation audit logs.
    • Monitoring: Visibility into which application instances are using which configuration versions.

  2. New features in Apollo 2.1.0

    master

    Apollo 2.1.0 introduced several significant features and improvements:

    • Node.js Client SDK: A new Node.js client SDK is available.
    • Namespace Management: Users can now associate multiple public namespaces at once and delete AppNamespace.
    • Configuration Management: Added a user-friendly config management page in the Apollo Portal, support for basic type checks for Item values, and a potential JSON value check feature.
    • Database as Registry: Added support for using a database as a registry.
    • Dynamic Profiles: Users can now change spring.profiles.active values without rebuilding the project.
    • Pagination API: A new API was added to load items with pagination.
    • Portal Enhancements: Improved user management pages and open platform authorization management UI.

  3. E2E Test Suite Overview

    master

    Apollo's end-to-end testing is divided into three main suites:

    1. Portal UI E2E: Uses Playwright and Chromium to test user journeys in the Portal UI. It includes @smoke tests for core journeys and @regression tests for extended scenarios. It also covers the ConfigService full-chain behavior (controllers like ConfigController, ConfigFileController, and NotificationControllerV2).
    2. Portal Auth Matrix E2E: Uses Playwright, Chromium, and Dockerized auth providers to test authentication modes (ldap and oidc). It verifies login success/failure and post-login user search/role management.
    3. External Discovery Smoke: Uses Bash and Docker to verify service registration with external providers (nacos, consul, zookeeper).

  5. What is a Cluster in Apollo?

    master
    A Cluster is a grouping of different instances of an application. This is typically used to divide application instances based on physical or logical locations, such as grouping instances in 'Server Room A' into one cluster and 'Server Room B' into another cluster based on the data center.

  6. Overview of Apollo architecture modules

    master

    Apollo's architecture is composed of several logical modules that handle different parts of the configuration lifecycle:

    • Config Service: Serves Apollo clients. It provides configuration acquisition and real-time update pushes (via HTTP long polling).
    • Admin Service: Serves the Apollo Portal. It provides interfaces for configuration modification, publishing, and retrieval.
    • Meta Server: Acts as an abstraction layer over Eureka. It encapsulates service discovery details so that Clients and the Portal can discover Config Service and Admin Service instances via a simple HTTP interface without needing to understand the underlying registry.
    • Eureka: The service registry used by Config Service and Admin Service to register themselves and maintain heartbeats.
    • Portal: The web-based management interface used by humans to manage configurations. It discovers Admin Service instances via the Meta Server.
    • Client: The SDK integrated into your application. It discovers Config Service instances via the Meta Server to fetch configurations and receive updates.

    Deployment Note: To simplify deployment, the Config Service, Eureka, and Meta Server are often deployed together within a single JVM process.

  7. Customize Apollo Meta Server Discovery via SPI

    master

    You can implement the MetaServerProvider SPI to inject custom logic for locating the Meta Server address. This is useful for large organizations to provide a zero-configuration client.

    • Implementation: Use the Java Service Loader pattern.
    • Priority: Smaller Order values have higher priority (e.g., Order=0 runs before Order=1).
    • Behavior: Apollo iterates through providers until one returns a non-empty address.

    Refer to LegacyMetaServerProvider or DefaultMetaServerProvider in the source code for implementation examples.

  8. Configure editing and publishing permissions

    master

    Apollo distinguishes between two types of configuration permissions. By default, no permissions are assigned after project creation; an administrator must authorize them.

    Permission Types

    • Edit permission: Allows users to create, modify, or delete configurations via the Apollo interface. Note: Modifying a configuration only changes it in the Apollo UI; it does not affect the actual configuration used by the running application.
    • Publish permission: Allows users to publish or roll back configurations. Configurations are only applied to the application after a Publish or Rollback action is performed. Apollo notifies the application in real time to apply the changes.

    How to assign permissions

    1. Click the authorization button for the specific Namespace.
    2. Assign the Modify permission (for editing).
    3. Assign the Publish privileges (for applying changes).

  9. How the Apollo client works

    master

    The Apollo client implements a multi-layered configuration retrieval and caching strategy to ensure high availability:

    1. Push Mechanism: The client maintains a long connection to the server via Http Long Polling to receive real-time configuration updates.
    2. Pull Mechanism (Fallback): The client regularly pulls the latest configuration from the Apollo Configuration Center (defaults to every 5 minutes). This acts as a fallback if the push mechanism fails. The client reports its local version, and the server returns 304 - Not Modified if no updates are available.
    3. In-Memory Cache: Once retrieved, configurations are stored in memory for fast access.
    4. Local File Cache: The client caches a copy of the configuration in the local file system. This allows the application to restore configuration even during network failures or server unavailability.
    5. Application Interface: Applications can retrieve the latest configuration or subscribe to update notifications via the Apollo client.

  10. Use database-discovery (Default for 3.0.0+)

    master

    Starting from version 3.0.0, database-discovery is enabled by default. This allows Apollo to use its internal database tables as a registry, removing the need for third-party registries like Eureka, Nacos, or Consul.

    Configuration Options

    • Rollback to Eureka: If you need to revert to the old Eureka behavior, set SPRING_PROFILES_ACTIVE=github at runtime or in config/application.properties.
    • Multi-cluster Isolation: To ensure clients only read from the Config Service in the same cluster, add this to application-github.properties: apollo.service.registry.cluster=<cluster-name>
    • Custom URI for Clients: To expose a specific domain or IP instead of an internal IP, add this to application-github.properties: apollo.service.registry.uri=http://your-ip-or-domain:${server.port}/
    # Example: Custom URI for clients
apollo.service.registry.uri=http://apollo.example.com:8080/

  11. Understand the Apollo configuration model

    master

    Apollo manages configurations using a hierarchical 4-dimensional model in Key-Value format. This allows for centralized management across different scopes:

    1. application: The specific application being configured.
    2. environment: Different deployment stages (e.g., development, testing, production).
    3. cluster: Different data centers or logical groupings within an environment.
    4. namespace: A logical grouping of configuration items. Namespaces allow multiple applications to share the same configuration, while also allowing individual applications to override shared settings.

  12. How Apollo integrates with Spring and Spring Boot

    master

    Apollo integrates with the Spring framework by leveraging ConfigurableEnvironment and PropertySource.

    During the application startup phase, Apollo:

    1. Fetches the remote configuration from the Apollo server.
    2. Assembles the configuration into a PropertySource.
    3. Inserts this PropertySource at the highest priority (the first position) in the Spring Environment.

    Because Spring uses a priority-based lookup, any key present in the Apollo PropertySource will take precedence over keys in other property sources (like application.properties or environment variables).