Support for cloud-based platforms #7
Conversation
…mages, and supports deploying to Cloud Foundry and Kubernetes with free Wavefront monitoring.
|
.travis.yml has been bumped to jdk11 |
|
Hi @odedia is this still planned to be merged? If there's any more work required on the Kubernetes end, could I help out somehow? Unfortunately I may not be very helpful with Cloud Foundry and Wavefront. |
|
Hi. It is pretty much done for this version. I created a PR for the main repo, it’s in their hands now. I don’t have permissions to merge. Thanks for the interest! |
|
Sorry for the delay. I m on vacation without laptops . I try to review it tomorrow. |
|
No code reviews while on holiday! :) |
| ``` | ||
| If your operator deployed the wavefront proxy in your Cloud Foundry environment, point the URI to the proxy instead. You can obtain the value of the IP and port by creating a service key of the wavefront proxy and viewing the resulting JSON file. | ||
|
|
||
| Contine with creating the services and deploying the application's microservices. A sample is available at `scripts/deployToCloudFoundry.sh`. Note that some of the services' plans may be different in your environment, so please review before executing. For example, you want want to fork [https://github.com/odedia/spring-petclinic-microservices-config.git]https://github.com/odedia/spring-petclinic-microservices-config.git if you want to make changes to the configuration. |
There was a problem hiding this comment.
I see you have done some changes to the spring-petclinic-microservices-config repo: spring-petclinic/spring-petclinic-microservices-config@master...odedia:master
Majors changes are in new config files for the cloud and k8s spring profiles. Only the api-gateway.yml has been rewritten. But I suspect an issue in the existing one that sould be empty (see spring-petclinic/spring-petclinic-microservices-config#12)
We have several options:
- Create a new
spring-petclinic-cloud-configrepo with your config - Create a dedicated branch in the existing
spring-petclinic-microservices-configone - Adapt the existing
spring-petclinic-microservices-configto support bothspring-petclinic-microservicesandspring-petclinic-cloud.
The third solution has my preference for maintenance work but we could have regression.
What is your position?
There was a problem hiding this comment.
I would prefer a separate repo to avoid any lockin and regression tests between the two repos. They seem to be going in slightly different directions. It will also allow us to experiment more with the cloud-based config without impacting the existing microservices repo.
There was a problem hiding this comment.
Ok thus I've create the https://github.com/spring-petclinic/spring-petclinic-cloud-config repo. I let you published your config.
|
|
||
| You free account has now been created. | ||
|
|
||
| Create a user-provided service for Wavefront using the data above. For example: |
There was a problem hiding this comment.
What happens if we don't create the Wavefront service? Does the application works without Wavefront?
There was a problem hiding this comment.
No, you will need to remove the dependency from the pom.xml to disable it.
There was a problem hiding this comment.
Ok. So it's a point of failure. Sleuth and OpenTracing have a different behavior
| enabled: true | ||
|
|
||
| customers-service-id: http://customers-service.spring-pet-clinic.svc.cluster.local:8080 | ||
| visits-service-id: http://vists-service.spring-pet-clinic.svc.cluster.local:8080 |
| @@ -0,0 +1,22 @@ | |||
| echo "Creating Required Services..." | |||
| { | |||
| cf create-service -c '{ "git": { "uri": "https://github.com/odedia/spring-petclinic-microservices-config.git", "periodic": true }, "count": 3 }' p.config-server standard config & | |||
| <version>2.3.1</version> | ||
| <groupId>org.springframework.boot</groupId> | ||
| <artifactId>spring-boot-starter-parent</artifactId> | ||
| <version>2.3.1.RELEASE</version> |
There was a problem hiding this comment.
Why did you remove usage of the parent pom? Did you change it to a full reactor pom?
I suppose to have microservice that share nothing (no code and no maven config) ? A default is that we have plenty of copy paste in pom.xml
There was a problem hiding this comment.
No shared parent anymore since each microservice has a completely separate lifecycle now. Some microservices may want to stay on 2.3.1, while others may want to upgrade to 2.3.2 and JDK 14. It becomes a problem when they are bound to the same upstream.
Support for cloud-based platforms
Support for cloud-based platforms
This version has been adapted to Spring Boot 2.3 which supports building docker images with cloud-native buildpacks, and supports deploying to Cloud Foundry and Kubernetes with free Wavefront monitoring.