2

I'm writing a platform to automate the day to day runnings of a business, this is to be a SaaS offering with each customer having its own database's.

I'm currently using the following; Gitlab (Git Repo with many DevOps based tools), Sentry (Error Tracking integrated with Gitlab), Kubernetes (Container Orchestration), PHPStorm (IDE).

The idea was to push the code to Gitlab which would do the CI/CD process and deploy as a rolling update to all my customers who are separated by namespaces in Kubernetes. The problem is each customer would need there own environment variables including encryption keys, database credentials, and API keys to a central API that enables communications between each customers deployment. I can see where I would enter environment variables for one customer but how would I do it for many customers.

I have looked into forking the code for each customer and setting up a mirror but Gitlab always gives a 500 error when trying to mirror the same Gitlab server.

This has caused my whole project to come to a halt.

Any guidance is greatly appreciated.

Each customer runs on a separate copy of the code base for a few reasons including data isolation and we bill on resource usage not per user.

2 Answers 2

1

My answer is:

By "inject" I mean, the stuff that differentiates one deployment from another shouldn't be present inside the git repo. This is also perfect way to run one or more test/dev/qa/staging deployments. See 12 Factor App (but don't use environment variables as they suggest).

Hence every process where you deploy your codebase somewhere first requires a documented steps "How to prepare ConfigMaps/Secrets".

1
  • I will give you answer a go today and will feedback Apr 8, 2019 at 6:05
1

This might be trivial but just make a few code changes to accept all the variables as environment variables. Now even though your clients could be in the same namespace using the same codebase and pulling the docker image from the same repo, all you have to do is modify the deployment file and voila! All your customers can now have their own environments, also since you are using Kubernetes you can leverage rolling update and also as a safeguard wherever you are using environment variables don't provide a default value (although it is a good practice). As far as I understand your case you want customers to only be served with the content relative to their environments. So providing a default value might make you miss out on an environment variable or two at times creating issues for you.

Reference: https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .