- Go Template 61.6%
- Go 25%
- Shell 11.6%
- Dockerfile 1.8%
| development | ||
| rendered/enabling-test | ||
| tests | ||
| .chainsaw.yaml | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| appset.yaml | ||
| dev.helmfile.yaml.gotmpl | ||
| flow.helmfile.yaml | ||
| kustomization.yaml | ||
| README.md | ||
| renovate.json | ||
Flow Platform
Flow is RWS WM's development and deployment platform.
Purpose and Goals
The Flow Platform intends to streamline development and operational workflows.
It aims to:
- Provide a robust, simple and scalable environment for building, testing, and deploying applications.
- Provide standard solutions for common operational problems. Said problems include, but are not limited to:
- Continuous Integration and Deployment
- Secrets Management
- Policy Management
- Observability: monitoring, logging and tracing
- Certificate and trust management
- Identity and Access Management (not implemented yet)
- Alerting (not implemented yet)
- Self-service PostgreSQL (not implemented yet)
- API management (not implemented yet)
- Make the deployment and operation of our applications consistent, using a reduced number of technology stacks, so TABers can easily switch between applications.
- Enable multitenancy and separation of concerns.
Target Users
There are two main groups of target users
- Suppliers. They are concerned with the development and testing of the applications. They value ease of use, quick turnaround and independance.
- TABers. They value stabiliity, consistency and predictability.
Core Components
The platform consists of the following core components:
- ArgoCD for the continuous delivery of applications
- Cert Manager for managing certificates
- CNPG operator for deploying and operating PostgresQL databases
- External Secrets Operator for managing secrets. Backed by HashiCorp Vault
- Kube-Fledged to manage a cache of container images on all workers
- Kyverno for managing policies
- NFS Provisioner for providing **read-write many" persistent volumes
- SMB CSI Driver - SMB volume driver
- Observability stack based on Grafana, Prometheus, Loki and Tempo
- Stakater Reloader for reloading of application when their config changes
- Trust Manager for managing trust bundles
Flow Platform deployment pipeline
graph TD
Node1[Gitlab-CI PRE stage]
Node1 --> Node2[deploy eso on wm-tooling]
Node1 --> Node3[deploy trustmanager on wm-tooling]
Node1 --> Node4[render Flow manifests]
Node1 --> Node5[render test manifests]
Node5 --> Node101[Gitlab-CI tooling stage]
Node4 --> Node101
Node3 --> Node101
Node2 --> Node101
Node101 --> Node102[bootstap]
Node101 --> Node103[deploy wm-infra external secrets on tooling cluster]
Node101 --> Node104[deploy Argo CD on tooling cluster]
Node102 --> Node201[Gitlab-CI cluster stage]
Node103 --> Node201
Node104 --> Node201
Node201 --> Node202[Child pipeline for cluster 'X']
Node202 --> Node203[Deploy Argo CD agent on cluster 'X']
Node203 --> Node204[Deploy Flow apps for cluster 'X' to tooling Argo CD]
Node204 --> Node205[Deploy external secrets to cluster 'X']
Node201 --> Node302[Child pipeline for cluster 'enabling-test']
Node302 --> Node303[Deploy Argo CD agent on cluster 'enabling-test']
Node303 --> Node304[Deploy Flow apps for cluster 'enabling-test' to tooling Argo CD]
Node304 --> Node305[Deploy Flow tests for cluster 'enabling-test' to tooling Argo CD]
Node305 --> Node306[Deploy external secrets to cluster 'enabling-test']
vcluster on featurebranches
To prevent concurrency issues on our internal test cluster, we introduced vcluster based deployments when our pipeline runs on other branches then the main branch. The manifests are rendered the same way as for the actual cluster, what has to be different in a vcluster is done in the pipeline and in appset.yaml.
The pipeline contains a set of additional step to make sure the vcluster is set up first and payloads deployed to it are accessible using special ingresss URLs.
Exceptions:
- Branches created by renovate matchting ^renovate.* run their pipeline against the actual enabling-test cluster.
- The same goes for branches with 'vclusterdisabled' in their branch name.
Local / helmfile deployment
Our deployment is based on helmfile. We tested with version v1.7.0 but anything newer should also work. Also we depend on the helm 'diff' plugin. One way to get it is using the source repository:
helm plugin install https://github.com/databus23/helm-diff --verify=false