diff --git a/docs/src/main/asciidoc/intro.adoc b/docs/src/main/asciidoc/intro.adoc index e47aae85..989710cd 100644 --- a/docs/src/main/asciidoc/intro.adoc +++ b/docs/src/main/asciidoc/intro.adoc @@ -1,2 +1,3 @@ + Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. The concepts on both client and server map identically to the Spring `Environment` and `PropertySource` abstractions, so they fit very well with Spring applications, but can be used with any application running in any language. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate. The default implementation of the server storage backend uses git so it easily supports labelled versions of configuration environments, as well as being accessible to a wide range of tooling for managing the content. It is easy to add alternative implementations and plug them in with Spring configuration. diff --git a/docs/src/main/asciidoc/quickstart.adoc b/docs/src/main/asciidoc/quickstart.adoc index 5b504a40..80f29135 100644 --- a/docs/src/main/asciidoc/quickstart.adoc +++ b/docs/src/main/asciidoc/quickstart.adoc @@ -18,7 +18,7 @@ $ curl localhost:8888/foo/development ---- The default strategy for locating property sources is to clone a git -repository (at "spring.cloud.config.server.git.uri") and use it to +repository (at `spring.cloud.config.server.git.uri`) and use it to initialize a mini `SpringApplication`. The mini-application's `Environment` is used to enumerate property sources and publish them via a JSON endpoint. @@ -33,7 +33,7 @@ The HTTP service has resources in the form: /{label}/{application}-{profile}.properties ---- -where the "application" is injected as the "spring.config.name" in the +where the "application" is injected as the `spring.config.name` in the `SpringApplication` (i.e. what is normally "application" in a regular Spring Boot app), "profile" is an active profile (or comma-separated list of properties), and "label" is an optional git label (defaults to @@ -46,13 +46,14 @@ map, even if the origin of the values (reflected in the Spring Cloud Config Server pulls configuration for remote clients from a git repository (which must be provided): +[source,yaml] ---- spring: cloud: config: - server: - git: - uri: https://github.com/spring-cloud-samples/config-repo + server: + git: + uri: https://github.com/spring-cloud-samples/config-repo ---- === Client Side Usage @@ -115,8 +116,7 @@ users. Example Maven configuration: Then you can create a standard Spring Boot application, like this simple HTTP server: ---- -@Configuration -@EnableAutoConfiguration +@SpringBootApplication @RestController public class Application { diff --git a/docs/src/main/asciidoc/spring-cloud-config.adoc b/docs/src/main/asciidoc/spring-cloud-config.adoc index 2ffdd2fd..1546c858 100644 --- a/docs/src/main/asciidoc/spring-cloud-config.adoc +++ b/docs/src/main/asciidoc/spring-cloud-config.adoc @@ -93,6 +93,7 @@ one wins (like adding entries to a `Map`). Example: a client application has this bootstrap configuration: .bootstrap.yml +[source,yaml] ---- spring: application: @@ -150,6 +151,7 @@ you need it, but remember that the label is applied as a git label anyway). So you can easily support a "one repo per application" policy using (for example): +[source,yaml] ---- spring: cloud: @@ -170,6 +172,7 @@ comma-separated list of `{application}/{profile}` names with wildcards (where a pattern beginning with a wildcard may need to be quoted). Example: +[source,yaml] ---- spring: cloud: @@ -206,6 +209,7 @@ use a YAML array (or `[0]`, `[1]`, etc. suffixes in properties files) to bind to multiple patterns. You may need to do this if you are going to run apps with multiple profiles. Example: +[source,yaml] ---- spring: cloud: @@ -237,6 +241,7 @@ Every repository can also optionally store config files in sub-directories, and patterns to search for those directories can be specified as `searchPaths`. For example at the top level: +[source,yaml] ---- spring: cloud: @@ -255,6 +260,7 @@ By default the server clones remote repositories when configuration is first requested. The server can be configured to clone the repositories at startup. For example at the top level: +[source,yaml] ---- spring: cloud: @@ -285,6 +291,7 @@ To use HTTP basic authentication on the remote repository add the "username" and "password" properties separately (not in the URL), e.g. +[source,yaml] ---- spring: cloud: @@ -368,6 +375,7 @@ accidentally changed by the application using the normal Spring Boot hooks. To declare overrides just add a map of name-value pairs to `spring.cloud.config.server.overrides`. For example +[source,yaml] ---- spring: cloud: @@ -403,6 +411,7 @@ label provided by the `EnvironmentRepository` implementation. You can configure the Health Indicator to check more applications along with custom profiles and custom labels, e.g. +[source,yaml] ---- spring: cloud: @@ -442,7 +451,7 @@ You can download the "Java Cryptography Extension (JCE) Unlimited Strength Juris from Oracle, and follow instructions for installation (essentially replace the 2 policy files in the JRE lib/security directory with the ones that you downloaded). -If the remote property sources contain encryted content +If the remote property sources contain encrypted content (values starting with `{cipher}`) they will be decrypted before sending to clients over HTTP. The main advantage of this set up is that the property values don't have to be in plain text when they are @@ -455,6 +464,7 @@ applications it might contain an `application.yml` like this, for instance: .application.yml +[source,yaml] ---- spring: datasource: @@ -572,6 +582,7 @@ $ keytool -genkeypair -alias mytestkey -keyalg RSA \ Put the `server.jks` file in the classpath (for instance) and then in your `application.yml` for the Config Server: +[source,yaml] ---- encrypt: keyStore: @@ -592,7 +603,7 @@ keystore (`encrypt.keystore.location`) the default locator will look for keys in the store with aliases as supplied by the "key" prefix, i.e. with a cipher text like this: - +[source,yaml] ---- foo: bar: `{cipher}{key:testkey}...` @@ -806,7 +817,7 @@ to set `spring.cloud.config.failFast=true`, and then you need to add `spring-retry` and `spring-boot-starter-aop` to your classpath. The default behaviour is to retry 6 times with an initial backoff interval of 1000ms and an exponential multiplier of 1.1 for subsequent backoffs. You can configure these -properties (and others) using `spring.config.retry.*` configuration properties. +properties (and others) using `spring.cloud.config.retry.*` configuration properties. TIP: To take full control of the retry add a `@Bean` of type `RetryOperationsInterceptor` with id "configServerRetryInterceptor". Spring @@ -838,6 +849,7 @@ that via the config server URI, or via separate username and password properties, e.g. .bootstrap.yml +[source,yaml] ---- spring: cloud: @@ -848,6 +860,7 @@ spring: or .bootstrap.yml +[source,yaml] ---- spring: cloud: @@ -867,6 +880,7 @@ works locally and for a user-provided service on Cloud Foundry named "configserver": .bootstrap.yml +[source,yaml] ---- spring: cloud: