Browse --- Chat --- Wekan

Skip to content
GitLab
Open
Issue created by kc@kcOwner4 of 5 checklist items completed4/5 checklist items

Roadmap

Several different routes/goals/tasks to undertake next

  • 1. Start using skaffold build & skaffold deploy in .gitlab-ci
    • skaffold building needs to support different registries
  • 2. Dynamically use the correct cloud providers volumes for pvc/pv
  • 3. Determine best way to handle pvc cleanup for review/dev/beta/prod cluster/evironment
    • Skaffold/Helm behaves weirdly with deleting pvcs, probably just need to kubectl delete pvc --all -n KUBE_NAMESPACE for non-prod environment.
    • 11/27/22 accf699c - Depends on the cluster configuration after the PV is no longer bound to the PVC/PVC is deleted.
    • See #3 (comment 2124) for more details
  • 4. Get mongo statefulset to launch in replicated mode if count > 3
    • 11/27/22 accf699c - Separate values file in skaffold/replica/react-template-db.yaml file to start mongo as a replica set.
    • See #3 (comment 2127) for more details
  • 5. Have init sidecar consul containers to register db service
    • Have our db connection string be correct based on consul service

TLDR Update 12/2/22
Databases tied directly to apps is the direction this project aims to utilize.
Copy pasting reasoning when updating infra:

I was originally against DBs in containers/pods but given how databases can be individually configured/fine-tuned, resources separated/limited/expanded, backed up, upgraded, tested, scaled, and run scheduled resource intensive maintenance tasks, per application, without compromising databases for other applications, I've since decided containerizing databases is actually a really good idea (sorry DB admins).

The description below is older and keeping for transparency and historical insight about the general ideas on it.

Below is ongoing research being updated as more info becomes available.

For the mongo statefulset - atm we'll have one service for 3 replicated mongo pods. How do we get these to detect if the primary node is down and have a secondary node to take over as primary.

Do we have a service per replicated mongo pod?
Its old but should provide some insight: https://kubernetes.io/blog/2017/01/running-mongodb-on-kubernetes-with-statefulsets/

Looks like using a headless service allows us to use each replicated pod to be addressed individually using replicaname-index.servicename
ie mongo-0.mongo mongo-1.mongo

More detail on headless services:
https://stackoverflow.com/questions/52707840/what-is-a-headless-service-what-does-it-do-accomplish-and-what-are-some-legiti

Maybe for development we have a mongo release bundled with skaffold dev but have a separate mongo helm release thats used for the cluster instead of per application.

We want our mongo db in replicated mode absolutely, but do we want completely isolated mongo instances per application? I feel like 3 mongo pods * X applications feels like too many mongo dbs/pods. At the moment we have 1 db per db node, so maybe that would work? 3 db nodes each with a replicated mongo pod per application.

Isolated mongo pods does allow for more fluid upgrades. Application 1 uses mongo 4, appication 2 uses mongo 5 which deprecates somethings from mongo 4 that application 1 uses. Instead of forcing an upgrade of application 1 to use mongo 5, it can simply stay put until its ready.

Could also just have mongo pods based on a database release instead of per application. mongo4.4 service/pod/replicas, mongo5.2 service/pod/replicas etc.

Each replica pod per app will need a pvc which will add up to a lot of pvcs, whereas release per db version is more easily managed.

Depending on how provisioning pvcs work and the cost, theres an argument for both but leaning towards a separate helm release per database version. Less pvcs/pods to manage overall and db provisioning/handling separate from application development/deployments.

Edited by kc