Konfiguracja oparta na Git

Storing configuration in Git gives you version history, code review, and rollback. The Config Server simply reads files from a configured repository.

Each service has one or more YAML/properties files named after its application name, optionally with a profile suffix.

A file literally named application.yml holds defaults applied to every client. Put cross-cutting settings (logging, common URLs) here.

Profile files like orders-prod.yml override the base orders.yml for that profile. The server merges them, with the profile file taking precedence.

Set the Git URI on the server. For private repos add credentials or an SSH key.

The Git label defaults to main/master but can be any branch or tag. Clients can request a specific label, enabling per-environment branches.

If config lives in subfolders, set search-paths so the server looks in the right places. Placeholders like {application} are supported.

The server clones the repo on first request (or eagerly). With clone-on-start: true it fails fast at boot if the repo is unreachable, surfacing misconfiguration early.

On each client request the server checks for new commits. So pushing a change to the repo makes it available - clients still need to be refreshed to apply it (covered later).

You can map different applications or patterns to different repositories, e.g. keep secrets in a separate, tightly-controlled repo.

Even in Git, never commit plaintext secrets. Use the server's {cipher} encryption or an external secret manager, and restrict repo access.

Verify your Git-backend understanding.

You backed config with Git:

• Files named by application + optional profile suffix
• application.yml = shared defaults; app-profile.yml overrides
• Configure URI, label (branch), search-paths and credentials
• Keep secrets encrypted, never plaintext