Shared kubernetes service on Helm?


#1

Hello! i have a question about best practices -
Let’s say we have 2 apps A,B and they are using a shared service (RabbitMQ for example).

Now, i need to configure users, queues, etc… for each service (and create them in rabbitMQ).

What’s the best way of doing it? i have an helm chart for RabbitMQ - and if i’ll add the values per application to the chart it will be come pretty big and messy.
Is there an option to somehow deploy the apps and define the “rabbit” part in those apps? or any other recommendations?


#2

Hi @Ariel_B,

I’d say the “best practice” way would be to deploy a RabbitMQ for each application.

However, if you don’t wish to go down that road, you can add an initContainer to your application that reaches out to RabbitMQ and ensures the users and queues you require exist.


#3

Thanks, so as i see there are inded 2 options:

  1. initContainer as you said - to ensure everything is configured
  2. hooks - but they are only when installing https://docs.helm.sh/developing_charts/#hooks

#4

I considered mentioning hooks, but I refrained for two reasons:

  1. It seems to be common practice to use helm template rather than helm upgrade or helm install, as the consensus is that the “tiller is bad” from a security standpoint. There’s plenty of resources on the internet with more thought out conversations about this, should you wish to learn more.

  2. Helm 3 will address this with a client-side architecture and Lua hooks. So I didn’t want to suggest something that wouldn’t be backwards compatible in 6/12 months time.


#5

Hi,
We are also using init container to create application specific db and db user but to create db we are passing db admin user credentials to init container . Here problem is application can read db admin credentials . how to avoid this ? Is any best practice ?


#6

While your initContainers and your containers share the volumes specified in your manifest, they can each utilise/mount only the one you select. So your initContainer can mount a different volume (admin secret) than the application container. I’m not sure if this is what you’re asking though?

@Jebin_J, do you want to provide some further details about your setup?


#7

This really isn’t a concern of Kubernetes itself as it is an application layer concern. This should be handled by the mechanism that is deploying your kubernetes objects such as your CI/CD service(s).

How are you currently deploying things?


#8

Thanks @rawkode , i understood wrongly now i’m clear


#9

I think the answers above satisfy my concern.
we will deploy it using ansible, running helm scripts - firstly creating the rabbitMQ pods.

it’s a good practice that each service will perform object creations / verification in the init phase and it satisfies my question.


#10

Hi,

What is the best way to change the DB user periodically ?

Regards,
Jebin J