All of our spring cloud microservices make use of Spring REST docs to generate documentation and serve it from /docs/index.html. This works well.
Not so for the config server. I'm running it embedded with #EnableConfigServer. I've moved the config root to /config with spring.cloud.config.server.prefix and can see that it has indeed been relocated both in the config server startup logs and the Eureka metadataMap for the config server (nice bit of integration there).
The documentation index.html is bound into the spring boot jar at the correct /static/docs/index.html location but it is not reachable on the config server's port.
I must be missing something straightforward here. What do I need to do to re-enable /static as a root for static resources in the jar?
Related
Versions
Spring Parent: 2.7.4, Spring Cloud Version: 2021.0.4, Java Version: 11
Issue
My Spring service has been using Eureka to connect to the config server for a long time, but I want to upgrade to Spring 2.7.4. I understand that as of Spring 2.4, the bootstrap context has been deprecated (source) and I need to make some adjustments to the old bootstrap properties and move them over to application.properties.
The documentation for Spring Cloud specifies that in order for me to continue to use discovery-first config lookup, I need to define a spring.config.import property with an optional configserver entry (source). Since I'm also using Vault, I define the property as follows:
spring.config.import = optional:configserver:placeholder,vault://<my-generic-backend>/dev
Next, I need to define the following properties (source). These properties were already defined in my old bootstrap.properties, so all I need to do is copy and paste.
spring.cloud.config.discovery.enabled = true
spring.cloud.config.discovery.serviceId = config-server
eureka.client.serviceUrl.defaultZone = <my-eureka-url>
Unless I'm missing something, these are all the steps I need to take in order to upgrade to 2.7.4. However, when I run the Spring service, it complains that it can't find the config server (via Eureka, or via URL), then it registers successfully with Eureka, and then continues trying and failing to find the config server.
Here is some of the output of the program:
> Running with Spring Boot v2.7.4, Spring v5.3.23
> Could not locate configserver via discovery: No instances found of configserver (config-server)
> Could not locate PropertySource ([ConfigServerConfigDataResource#2aa6311a uris = array<String>['placeholder'], optional = true, profiles = list['local']]): Invalid URL: placeholder
...
> DiscoveryClient_<my-project-name>/local - registration status: 204
I understand why it's failing to find a config server at URL: placeholder since that's not a valid URL, but I don't understand how the service can successfully register with Eureka yet not be able to find the config server. I know the service is registered because the output of the program says it registered correctly (and I can see it in the registry), and I know that the config server has the correct entity ID (config-server) because it was copied and pasted from the old bootstrap (and I can see config-server in the registry).
Workaround with Hardcoded URL
When I hardcode the config server URL like this (and set spring.cloud.config.discovery.enabled to false), the config is loaded properly from the server:
spring.config.import=configserver:https://<my-hardcoded-config-url>.com,vault://<my-generic-backend>/dev
Workaround with Bootstrap
It's possible to return to using the bootstrap context and still use Spring 2.7.4 with discovery-first config lookup by adding the "spring-cloud-starter-bootstrap" dependency. So I added the dependency to my POM and moved these properties back to bootstrap.properties from application.properties.
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.service-id=config-server
I moved the Vault and Eureka properties back into bootstrap.properties as well. The new application.properties now contains no values relating to Eureka, Vault, and Cloud Config.
When I run the service, it does indeed find the address for the config server through Eureka, as expected (although it fails to connect because it's the internal address and I'm running locally).
Conclusion
While these are valid workarounds, it's frustrating to not be able to have a dynamic URL for the config server (as is the entire point of using Eureka). Right now, it looks like my choices are either to use a hard-coded URL and risk having to change every property file, or use a deprecated behavior that Spring documentation specifically disfavors (source).
I would appreciate any guidance you have on the issue, and I thank you in advance.
I have multiple microservices which communicates with each other through REST calls.
I have used spring boot and spring rest and have configured the URLS of the rest end points in application.properties file.
Now the problems is if the URL for one end point changes then I to have to manually modify all the property files of the services which are calling that particular end point which has got changed.
Is there a workaround for this so that the URLS can be somehow placed in a centralized location so that any modification does not impacts the other services which are using it.
You can use spring-cloud to achieve this. Usual way used in spring-cloud is by configuring the required properties in a git repo. And then those properties can be accessed by any micro-service you want with minimal configurations. You can refer projects in this repo
limits-services acts as a client that needs certain properties those are configured in spring-cloud-config-server. Hope this helps.
In case with microservices you can use Spring Cloud Config (Spring Cloud Config, Spring Cloud Config Server). It's very usefull and you can update your configuration at runtime.
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.
As others have mentioned you can use Spring Cloud Config Server to remotly load your application configuration. All you need is git repository containing your configuration.
Spring cloud configuration supporst Git, database as your store for configuration.
Idea is to create an spring-boot app that can provide configuration to other applications.
#SpringBootApplication
#EnableConfigServer
public class ConfigServer {
public static void main(String[] args) {
SpringApplication.run(ConfigServer.class, args);
}
}
You can configurae port and provide your git repository using key spring.cloud.config.server
server.port: 8888
spring.cloud.config.server.git.uri: file://${user.home}/config-repo
At client side, if you have spring-config in your classpath, application will try to connect to an application runnign at port 8888 to retrieve configuration.
More information can be found here.
may put configuration inside a database.
after that need have one centralize cache service that used by other services, can be .jar service,
then the values can be load inside a cache class in this service,
then in the front end side need have update button for updating the cache after modify the URL value in the database, so then all impacted services can use new value.
and also to be easier may have stand alone UI for update those configuration rather than updating database directly.
You can use Microconfig.IO to manage your service configuration and it's placeholders functionality to reference configuration values of certain services from others. So in your case you configure your deploy url in your server and put placeholders on it in your clients. This allows you to edit value only in one place and then everyone who depend on it will get it automatically.
According to the docs, to connect to the config server, spring.application.name and spring.cloud.config.uri should be set in a bootstrap.properties file for the config client, such that the parameters fetched from the config server can be prior to those set locally. I am just wondering how this works, since:
I searched the source code of Spring Cloud Config Client, but cannot find what it does with the bootstrap.properties
It still works if I set spring.application.name in application.properties
Is it a feature of SpringBoot?
This feature is not located in spring-cloud-config. Instead, it is in spring-cloud-context which is a dependency of spring-cloud-config.
Basically, it creates a parent context for the actual context of the application and initializes it with the parameters of the bootstrap.
You can find more information in https://cloud.spring.io/spring-cloud-commons/multi/multi__spring_cloud_context_application_context_services.html
It is a feature of spring cloud. The spring.cloud.config.uri needs to be set in bootstratp.properties. This comes from the spring-cloud-commons project. My guess is you might be running the config server in the default location of localhost:8888.
My question is how will a spring boot application which is pushed on cloud understand that it has to use so-and-so properties file that is stored in Git and referred in Spring Cloud config server?
I understand a cloud config server will have the Git repository url, etc.
and
a binding of spring-boot application with the spring cloud config service should happen,
but still I don't understand how an application understands that it has to use a properties file stored externally?
Name the properties file in the Git repo that is used by the Config server like:
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
Meaning if your client app is name mysoapapp, create a file: mysoapapp-dev.properties. Now run mysoapapp passing the active Spring profile: dev, using argument: -Dspring.profiles.active=dev
You should also confirm that the Config server is able to serve the files by sending a request like:
curl -v http://<the config server>/mysoapapp-dev.properties
and it should retrieve the properties.
I published a couple of blog posts about this topic that might help you:
Centralized and versioned configuration using Spring Cloud Config Server and Git
Refreshable Configuration using Spring Cloud Config Server, Spring Cloud Bus, RabbitMQ and Git
Consider you have a Spring application that gets its configuration from a config server. If it cannot connect to the config server, the application will continue to start but as all configurations are missing, it will eventually fail with a potentially misleading error.
Is it possible to configure Spring, so it immediately aborts when it cannot connect to its config server during startup?
Set spring.cloud.config.failFast to true in your bootstrap.yml or bootstrap.properties file. Also, you can add -Dspring.cloud.config.failFast=true to the JVM arguments.
From the documentation
Config Client Fail Fast
In some cases, it may be desirable to fail startup of a service if it cannot connect to the Config Server. If this is the desired behavior, set the bootstrap configuration property spring.cloud.config.failFast=true and the client will halt with an Exception.
You can achieve that by using spring cloud Spring Cloud Config Serverand Spring Cloud Config Client components.
1. Spring Cloud Config Server
The Server provides an HTTP, resource-based API for external configuration (name-value pairs, or equivalent YAML content). The server is easily embeddable in a Spring Boot application using the #EnableConfigServer annotation. So this app is a config server:
//ConfigServer.java
#SpringBootApplication
#EnableConfigServer
public class ConfigServer {
public static void main(String[] args) {
SpringApplication.run(ConfigServer.class, args);
}
}
2. Spring Cloud Config Client
A Spring Boot application can take immediate advantage of the Spring Config Server (or other external property sources provided by the application developer), and it will also pick up some additional useful features related to Environment change events.
Then in the config client side you can configure fail fast by setting the bootstrap configuration property spring.cloud.config.failFast=true
Spring cloud documentation Config Client Fail Fast