1

I don't know how to explain this problem better, but I'll try to explain it clearly:

  • Where I work our customers are companies, with lots of users
  • We offer a SaaS solution for them to manage stuff
  • For every customer, there are around 50 right now, we create a vhost in one of our machines, a database in some of our database VMs and we configure the dotenv files for this application, potentially creating more VMs or database machines (nowadays this happens less frequently)
  • The SaaS allows us to configure the same application to serve multiple clients by doing a multi-tenant setup with multiple environment files

The problem: The whole process of creating vhost, configuring stuff, etc. is manual. We know how to automate this setup with ansible + terraform by creating application VMs and infrastructure for every customer or creating a HA environment with every application dotenv on a shared application, and we even have the option to migrate this to k8s. However, the most valuable thing to us would be to be able to add, to whichever solution we choose, extra customers based on API calls or some sort of automation.

If you're on k8s world, I think this would be equivalent to add a new ConfigMap to every customer based on some sort of automation, alongside deployments for these customers.

Improve this question

2 Answers 2

Reset to default
1

From what I understood is that you want add deploy a configMap and a Deployment based on some API calls every time you need to add a new customer?

Basically you need a CD Pipeline that triggers a deployment based on new customer added. The trigger can be an API Call or a webhook from your software where you add a new customer. It should support sending an API call with details required in those ConfigMaps and Deployments. Now with the details of API Call you'd need to pass those parameters to a Values.yaml of Helm Chart which then goes and deploys to your selected cluster.

If you don't have a CD, you can use Azure Devops or ArgoCD. Both of these support trigger based on API Calls. Then setup the pipeline with connection to your cluster. In Azure Devops, you'd have to create a service connection and in ArgoCD register your cluster. Also, Helm Chart is the easiest way to deploy k8s manifests to it'd be preferable if you did it via that. ArgoCD would limit you to k8s only. You can go with Azure Devops for support for all. I'd have said Jenkins but managing that is a pain in the back. If that is not an issue you can try that too.

Improve this answer
1
  • Hi @Anti21, Thank you for the answer! We use gitlab as our CI/CD platform and the CD can be triggered via api calls, I think our biggest problem is about where can we store customer specific info and monolith config (shared and specific) so we can easily retrieve it during the CD process. I'm not sure it's possible to do that with ConfigMaps because I'm just starting with k8s. I've searched a bit and maybe a json in a git repo would solve the problem, or an entry in some config management database.
    – Leonardo Cavalcante
    Commented Aug 11, 2021 at 11:38
0

Look into a workflow engine like Argo Workflows.

I have seen similar setups. Consider all the steps required to onboard a new client as a workflow.

A workflow engine would then read this particular set of steps (a workflow-template) and performs the tasks as required (a run/workflow).

Since you mentioned going into k8s you might look into this or a non-k8s workflow engine as required. While the workflows itself might run on k8s containers, the steps can be for any environment.

I used Argo Workflows to setup the templates. A dedicated setup for the Devops/SRE teams should fit your use case perfectly. You can also automate other step-wise processes and deploy them too.

Advantages:-

  • Argo Workflows provides a UI/CLI approach to trigger workflows. Additionally it has a Events/Webhooks support for triggering workflows as well.

  • Support for multiple artifact-repositories, data sources to read/write your client configurations.

  • RBAC/SSO support which can help you permission your workflows and who can run them.

  • System where you can control the execution steps/environment and the user just has to provide the inputs to your workflows and have permissions to run the same. This reduced a lot of manual intervention and troubleshooting due to steps going wrong during each try and saved us a lot of time.

  • Logs are easily available along with the outputs of the workflows as artifacts.

  • Workflows can be versioned.The workflows are yaml files which can be versioned and released, hence maintained as code.

  • Workflows can be deployed using the CD tools of your choice.(ArgoCD).

Disadvantages:-

  • Maybe an overkill for just one workflow.Try deploying multiple templates.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.