Practical Configuration Tricks for Spring Cloud API Gateway and Service Discovery
During using Zuul of Spring Cloud (Finchley.SR2) proxy as my API Gateway and Eureka as the registration server, there are some interesting configuration tricks, which may be very practical for you. In following examples, I set the Spring Boot project of Zuul starting at http://127.0.0.1:8080
- A normal static route in YAML file can be replaced by an environment variable:
This is the classic setting. But in a real application scenario it would be more practical that you set the URL via an environment. Especially if the Zuul runs in a docker on the Kubernetes, it would be easier to manipulate the routes for production run-time via the environment variables, so that there is no need to roll out a new docker delivery. Hence the settings of the route could be like this:
Then the environment variable shall be set for the docker container:
Since we chose to use the environment variables, the configuration in YAML could actually be spared. With help by Spring Boot, what you need is just to set the following environment variables.
In fact, with this environment variable, even if you have the same route in the application.yml file, it will be overridden.
2. A normal static route with hyphen in service name in YAML file:
Unfortunately there could be service names with hyphen “-”, i.e. product-info, then it is a little complicated to set the environments variables, which do not allow any hyphen. Therefore, instead of one line you would need three:
So the client can call the service via the service name, e.g. http://127.0.0.1:8080/product-info and the swagger of the Zuul will show the service name as the primary name also with the hyphen.
Exclude Swagger in production
Swagger is very useful for API description, trying out and client-side code generation during development and test. However, it should be disabled in the production environment due to the security concern and the information hiding. It could certainly be configured in the Swagger configuration class, but you have to do it for each micro-service.
If you would like to just exclude it for external world, you could utilize the Zuul configuration “ignoredPattern” via the environment variable:
or the application.yml file:
It will then prevent the access to the Open-API document of the service using Swagger, so that the Zuul will not able generate the corresponding content within Swagger UI, as long as the request goes through the Zuul proxy. The requester can still open the Swagger UI page to see which services are connected, but without endpoints content except a warning message.
Service Discovery for multi-branches
The Zuul API gateway can be integrated with the Spring Cloud service discovery easily. We just need to add the following dependency into pom.xml in case of Maven:
And add an annotation @EnableDiscoveryClient to the application class:
Certainly you need to tell Zuul where the Eureka server is located:
Then you could reach the micro-services which have been registered on the Eureka server.
During the development a micro-service could have many VCS (Version Management System, i.e. Git) branches. Perhaps you would like to test your branches by integration with the front end applications which call the micro-service via the Zuul gateway. Hence you should register each of your branches to the Eureka server with different application name and instance Id via defining the application.yaml file of the micro-service application so:
The environment variable APP_REG_NAME could easily be combined with the application name from pom.xml and the branch name of the VCS by using Jenkins project or pipeline, for example in the Jenkinsfile:
And add the environment variable APP_REG_NAME=appName to the docker.