keacloud/main-repo

Master repository for all things kea

Description

kea is a telecommunications platform that merchants use to take orders and requests automatically when customers call in.

Links

• Github projects page
• Issues page
• Pipefy

Schematic

Notes

Stack

• Kubernetes to manage our clusters.
• Aiven for all of our managed databases.
• PostgreSQL as our primary source of truth.

Kubernetes base stack

Kubernetes extensions

• helm

• traefik

• openvpn

• weave-cloud

• weave-scope

• kubewatch

• redis

• kubeless

• metabase

• luigi

• centrifugo

• google-service-catalog

• influxdb

• chronograf

• kapacitor

• telegraf

• kubeapps

• eventrouter

• gitkube

• argo

Kubernetes static tools

• psykube
• kompose
• kubesec
• telepresence

Environments

• Identical kubernetes environments for production and staging.
• master branch -> production
• staging branch -> staging
• Different subdomains, k1.kea.cloud and k2.kea.cloud.
• Different deployment strategies.

Component deployment (staging)

• Add a Dockerfile that runs the component.
• Build and test docker image locally.
• Add the gitkube git remote.
• Push code to the remote, gitkube builds images and updates components!

Component deployment (production)

• Add a Dockerfile that runs the component.
• Build and test docker image locally.
• Push code to gihub master branch, Google Container registry automatically picks up changes and builds the image.
• Weave Cloud checks the registry and updates components automatically.

Process

• All code begins life as part of a component.
• Once tested and deployed, refactor aggressively.
• Recursively, move generalizable components to libraries.
• Open source libraries once sufficient documentation is added.
• Let the world maintain it for ya.
• Stand on the shoulders of giants, use kubernetes and friends for managed CI/CD.

Branches

• staging: [default] Base branch for fix/feature branch. Only merges allowed after CI passes.

• master: The untouchable branch. Only automatic merges allowed after CI passes.

• develop: Special Orphan branch. All experimental stuff base on this. Be aware that merging into staging is non-trivial.

  Notes

• Naming convention:

  • Bugfix branches -> fix/<short_descriptive_name>
  • Feature branches -> feature/<short_descriptive_name>
  • Patch branches -> patch/<short_descriptive_name>
  • Experimental branches -> experiment/<short_descriptive_name>

• Branch bases and merge points:

  • Bugfix branches -> staging or master.
  • Feature branches -> staging only.
  • Patch branches -> any branch except staging, master or develop.
  • Experimental branches -> develop only.

  Flow

• Bug fixes:

  1. Create branch of staging or master.
  2. Add code, lint, make tests pass etc.
  3. Make sure branch is updated and can be safely merged back.
  4. Rebase into one commit, if possible.
  5. Create pull request on original branch.
  6. Make sure all CI tests pass.
  7. Merge and delete fix branch.

• New featues:

  1. Same as for bug fixes except only on staging.
  2. See above.

• Experiments:

  1. Before beginning an experiment, find last history intersection of develop and staging.
  2. Base an experiment branch off of that intersection commit.
  3. Remaining steps same as for features except only on develop. See above.

Directory Structure

• Logically separate projects are referenced as git-submodules.

• Use git-hooks amply to maintain sanity checks.

• Entire directory is a \<Component> composed of mainly:

  • Any application code.
  • 0 or more components, which are basically nested \<Component> s.
  • Required README.md and (optional) docs/ folder.
  • Required tests directory containing any tests.
  • Optional deply directory that contains kubernetes stack yaml files.
  • Optional scripts directory structured as \<Scripts>.
  • Optional metadata directories which are free-form.

• \<Scripts> have:

  • Any scripts.
  • Optional config directory, containing configuration files.
  • Optional init script
  • Optional build script
  • Optional lint script
  • Optional deploy script

main-repo/
  |   README.md
  |   (you are here)
  |
  └── docs/
  |   (contains general purpose documentation referencing docs recursively in all submodules)
  |   |
  |   └── README.md
  |   └── **/*.md
  |
  └── **/* ...
  |   (Application code)
  |
  └── components/
  |   (contains individual components that make up the entire kea stack)
  |   |
  |   └── sample-subcomponent/
  |   |   |
  |   |   └── README.md
  |   |   └── { ... }
  |   |   |
  |   |   └── **/* ...
  |   |       (Application code)
  |   |
  |   └── other-component/ ...
  |
  └── deploy/
  |   (contains yaml kubernetes scripts for getting up and running)
  |   |
  |   └── *.yaml
  |   |
  |   └── helm-charts/
  |   |   |
  |   |   └── **/*.yaml
  |
  └── scripts/
  |   (contains lint / build / deploy scripts for getting up and running)
  |   |
  |   └── README.md
  |   |
  |   └── config/
  |   |   |
  |   |   └── **/*.(yml|json|xml)   # Config files
  |   |
  |   └── build
  |   └── init
  |   └── lint
  |   └── deploy
  |
  └── metadata/
  └── tests/

Misc

Why is a raven like a writing desk? ~ Alice in Wonderland

Because it can produce a few notes, tho they are very flat; and it is never put with the wrong end in front!