Naming Conventions - woveon/wovtools GitHub Wiki

< Home

Woveon Logo

Naming Conventions match WovTools to Kubernetes (via naming conventions, WovTools can support the deployment of a system for a range of uses, across a range of Cloud providers):

{stage}

A developer's personal stage or a CI/CD development or production stage name.

  • Production - 'prod'
  • Development - 'dev' - Useful for a CI/CD process of merging all changes into a running system.
  • Personal - USERCODE - I generally use initials for developers. This uses Kubernetes namespaces to wall off developers from each other.

{project}

A group of services running in a Kubernetes namespace

{namespace} => {project}-{stage}

A WovTools namespace uses Kubernetes namespaces to separate running microservices.

{cluster} => {sys}-{provider}-{regioncode}-{flavor}

A Kubernetes cluster is named by WovTools as a mix of the system name under development, cloud provider, localized region of the provider. Flavor is independent.

{origin}

Where to run as a microservice defaults to running 'internal', i.e. in the cluster, but also as 'here' for local development.

{context} => [{origin}:]{cluster}-{namespace}

A WovTools context fully defines where code is running on a Kubernetes cluster. Origin is optional.

Example from our Facebook Plugin

Our Facebook plugin connects to Facebook, listening for updates and pushing content to our Woveon system. We run it in our own cluster that we call wov-aws-va-live, in its own project plfb, which we manage in three Kubernetes namespaces of plfb-cw (cw is my private namespace, where 'cw' are my initials), plfb-dev and plfb-prod. Here's how the naming convetions play out in detail:

The Kubernetes context for the production running Facebook plugin is wov-aws-va-live-plfb-prod. This means the cluster name is wov-aws-va-live, implying this cluster is the main Woveon cluster (sys=wov), on Amazon Web Services (provider=aws) in AWS's region us-east-1 (regioncode=va) (i.e. that is in Virginia (va)), on our main cluster (flavor=live) (We could make another cluster with flavor 'top' or 'brown' if we wanted, to experiment with cluster deployment, but we chose 'live' for now). The plugin is one project, plfb (short for plugin Facebook), and follows our internal naming convetion of starting plugins with 'pl' followed by the plugin's short code, 'fb' for Facebook. There is one github repo for this project, and each namespace is its own branch (cw, dev, prod). Inside the project, there are three microservices (i.e. three Kubernetes deployments) that append their microservice code to the project to generate its name (wl - plfbwl - the Facebook plugin WoveonListener, rl - plfbrl - the Facebook plugin RemoteListener, etc.). Each microservice will have its own implementation, either a Helm chart or its own Deployment with its own container (plfbwl, plfbrl, etc.). Our cluster has two nodes, which we use kops to manage.