0

I understand the concept of GitOps, where Git is the source of truth.

Well with us that's partly true. Gradle is our source of truth, and our build.gradle files, which are stored in Git, define the microservices, their versions, and their dependencies that we want deployed to an EKS cluster.

This is where my disconnect comes in.

Supposedly, Helm charts should be in their corresponding applications. So I should have this directory structure per microservice. The Helm chart is created using helm create

/microservice1
/microservice1/build.gradle
/src/...  <- source code
/helm/
-----/Chart.yaml
-----/charts
-----/templates
-----/values.yaml
-----/requirements.yaml

/microservice2
/microservice2/build.gradle
/src/...  <- source code
/helm/
-----/Chart.yaml
-----/charts
-----/templates
-----/values.yaml

Some questions. (I'll update as I think of some more)

  1. We use semantic version when we build our services, and that version is automatically generated and committed on the gradle.properties file via Gradle plugin I wrote. How can this version be reflected in the microservice's Chart.yaml file so the version there corresponds to the version in gradle.properties?
  2. Say microservice1 depends on microservice2, hence it has a requirements.yaml file. (The dependency is also of course reflected in microservice1/build.gradle dependencies{} section.) If I update microservice2 with a new version (again automated via plugin), how am I supposed to reflect that in microservice1's requirements.yaml for microservice2, and then update microservice1's version in its Chart.yaml?
  3. Our microservices use Spring boot profile, and we have sandbox, staging, and production profiles. When Spring Boot comes up, it reads the appropriate properties file based on the profile. Where can this be defined in the values.yaml file? Or should I have 3 different values.yaml files for each profile?
  4. We define a JAVA_OPTS variable that has the JAVA options that the microservice needs, and this is dynamic, depending on the microservice. How can this be defined via Helm charts?
  5. To save costs, I just want to define ONE ingress controller, and then each microservice with just add a /path/microserviceX rule to it. How can this be reflected in each microservice's ingress.yaml chart?

Disclosure, I'm new to Kubernets and Helm, and though I KNOW what I want to do, I don't quite know how to wire it together yet. I know I can do all the updates "manually" but I'd rather not do that. Is there a workflow already out there that supports this?

It seems like I need scripts to massage my helm charts when I release a microservice, but I'm not sure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.