Re: Feedback on Helm
Paul Czarkowski <pczarkowski@...>
A few things to address your template concerns.
Firstly you can create your own chart starter packs (https://helm.sh/docs/topics/charts/#chart-starter-packs) which you can base subsequent charts off, this is really useful to create a sane set of defaults for similar apps in the same languages. You can also use Library Charts (https://helm.sh/docs/topics/library_charts/) to reduce overlap/copy/paste and generally create DRYer charts.
As for "Problem is when the kubernetes template is actually rendered I have a new instance of the logging-configmap for each service, etc. I need to be able to build and deploy my services in isolation as well as part of the whole for testing purposes."
It's pretty common to include the dependencies in your charts so that the apps can be installed independently and start their own eureka/config-server etc, but when deployed to staging/prod you'd disable the dependencies (see condition - https://helm.sh/docs/topics/charts/#tags-and-condition-fields-in-dependencies ) and instead have the infrastructure deployed as its own thing. This also gives you the ability to maintain the infrastructure pieces of your application at a different lifecycle as your actual applications. You'd still use the rest of the settings for that subchart to configure your own application to talk to the upstream server.
If you have pretty complex relationships between the apps and need to be installed in a very ordered way, you can also reach towards a higher level tool like Helmfile (a declarative spec for deploying helm charts) to perform that work (Helm tries really hard not to boil the ocean). I use Helmfile extensively for this very purpose.
Also of note, Spring has some very good integrations with Kubernetes, giving you options for using kubernetes itself for service discovery and config server, which may in a homogenous environment allow you to simplify some of your app's infrastructure. I'm far from a Spring expert, but I work pretty closely with a number of the Spring team and they're working hard to make Kubernetes a first class platform for Spring, especially when it comes to the developer experience itself.
If there's anything specific I can do to help, I'd be happy to get further into the weeds with you.
On Fri, May 1, 2020 at 2:16 PM Loritsch, Berin <bloritsch@...> wrote: