* Add AWS S3 Environment Repository
This adds s3 as an Environment Repository.
This is based on code linked here:
https://github.com/spring-cloud/spring-cloud-config/issues/654
though it has been significantly reworked and tested.
It has been tested against vanilla buckets, versioned buckets, encrypted buckets with both AES-256 and AWS-KMS.
There are several things that I am not sure I have done 100% correctly. I'm happy to take feedback and fix. Here is a list of specific things that are known unknowns for me.
* Is there anything else that I need to do to make this implementation available in addition to what I added in EnvironmentRespositoryConfiguration?
* I added the AWS s3 java dependency for obvious reasons. There was already an AWS core dependency so I just used the same version. It is a very old version thought (2016). It seems to get the job done, but there is some stuff for STS credentials that I might use in the newer AWS SDK. I'm unsure what the process for testing the other code that requires AWS would be and updating.
* The AWS S3 client is constructed using the Default AWS provider chain. This should handle most cases implicitly (including assume role), though a newer AWS SDK might be preferable.
* This currently works against typical <app>-<profile>.properties and <app>-<profile>.yml files that are in a single AWS account and in a specified bucket. Label is optionally used as another suffix on the file name (<app>-<profile>-<label>.yml). This seems like a straight forward mapping of config server concepts to S3, but I am happy to hear other ideas. I noticed that the Git impl allows multiple repos and a kind of routing layer. This is a possibility later if needed, but this seems like a good place to start.
* I think the yaml and properties are parsed into a map correctly, but have a look at the unit tests to ensure.
* I'm trying to handle exceptional cases like other implementations when there are problems getting the config.
* In the factory I pass in ConfigServerProperties and make use of several of its attributes.
* I added the new test to AdhocTestSuite.
* I've tried serveral things, but I don't have the dependencies resolving correctly in IntelliJ Idea. I can compile and run tests with mvn on the command line, but it would be great to be able to do those things in IJ. I think that it gets confused with the parent pom in spring-cloud-build.
* Simpler YAML handling
Use YamlPropertiesFactoryBean for YAML.
Add configurable s3 endpoint.
* handle JSON config content in S3
* Label should denote a directory in S3
* Checkstyle changes, and make S3 JSON look more deliberate
Noted that JSON is using a YAML parser on purpose.
* added documentation for AWS S3 backend
* Allow overriding of AwsS3EnvironmentRepository
* put awss3 config properties at a consistent path
* Minor addition to get the new AwsS3 beans picked up during app init.
Adds a new format if requested using v2 Accept header, otherwise the
format is backwards compatible so older clients will work with new
servers.
fixes gh-866
Whenever the `spring.cloud.config.server.overrides` property was changed
(either through the env actuator endpoint or remote bootstrap
configuration) this was not reflected when retrieving the application's
configuration.
fixes gh-1295
* fix svnKitEnvironmentRepository param order
* Replace string concutination
Replace string concutination when used StringBuilder in EnvironmentController
The VaultEnvironmentRepository requires a token to be passed in a X-Config-Token header in an HttpServletRequest. This doesn't work well when config server is embedded in an application, as an HttpServletRequest is not available in that case.
These changes allows the Vault token to be provided in the HttpServletRequest header (the default behavior) or as a configuration property.
Without any preparations JGit defaults to read system / user / project
configuration from local file system. Users running tests locally
might see test failures due to their config diverging from the test
author config.
For me JGitEnvironmentRepositoryIntegrationTests.pullDirtyRepo() was
constantly failing, because JGit calculated a different hash for the
created commit than on the build server.
