Secrets Files - woveon/wovtools GitHub Wiki

< Home

Woveon Logo

TL;DR - The wovtools/config.json and wovtools/myconfig.json control how JSON files in the wovtools/secrets directory are merged together to generate environment variables and JSON values the configure development locally or in a stage.

DevInOps requires code to quickly and effortlessly switch configurations and it traveles between environments and stages. For example, the same code could be developed and tested on your laptop, pushed to a development node in your cluster, packaged into a container for deployment on a development Kubernetes cluster and then packaged into production, all in the same hour. WovTools manages this by on-the-fly generation of configurations and secrets which are used to update runtime and deployment variables.

Purpose

  • Capable of generating configurations for Kubernetes, environment variables, Docker container recipes, database, CLI and any other tooling necessary
  • Access to stages is limited and clearly controlled.
  • No configuration should be hard coded in any part of the project.
  • Configurations are versioned
  • Cluster Configuration sets are deployed with Docker containers and Kubernetes files.

About Project Configuration Files WovTools manages configurations in two files (wovtools/config.json and wovtools/myconfig.json). The config.json is packaged with the repository and contains rules for dev and prod stages while myconfig.json is for the user's personal use. These files combined control:

  1. .secrets: which and the order of how JSON files in wovtools/secrets are combined for a stage
  2. .originmods: modifications to a stage for a specific use like local development or in a pod
  3. .curorigin: which defines the configuration to use locally (ex. creating configurations that swap things like databases or remote vs local servers, etc.).

About Cluster Configuration Source (CCS) Files (wovtools/secrets/*):

  • There are multiple JSON files and are merged to generate a wovtools/cache/clusters/ORIGIN_CLUSTER/config.json file.
  • Inside the files, information can be overwritten by STAGE, CLUSTER and ORIGIN changes
    • ex. STAGEme : { port : 57342 }, CLUSTERwov-aws-va-grape : { port : 80 }, ORIGINhere : { port : 34353} - This means that if the stage is 'me', port 57342 is used. However, CLUSTER wov-aws-va-grape uses 80 but if ORIGIN is 'here' (i.e. you are on your laptop working on cluster wov-aws-va-grape), you are using port 34353, which is probably an ssh tunnel into the cluster.
  • generally: configuration is turned into environment variables by changing path into underscores

Example apirest secret file, for microservice 'jb':

In the following example, the microservice apirest uses node 10.1. However, cluster wov-aws-va-dog is 11.1 and the development stage is testing 12.1. In handlebars preprocessed files, these are accessed by apirest.containerfrom but environment variables would be WOV_apirest_containerfrom. For the database naemd apirestdb, the username is postgres by default, but apirestme for stage me, and apirestdev for stage dev. As well, if you are on your laptop developing locally (ORIGIN here), then port 5432 is used to connect to the default Postgres port. But, ORIGIN external connects to port 65432 which is an ssh tunnel port to the database in the cloud.

{
  "apirest" : {
    "healthpath" : "/api/v1/health",
    "ver" : "v1",
    "containerfrom"         : "node:10.1",
    "CLUSTERwov-aws-va-dog" : {
      "containerfrom"         : "node:11.1",
    },
    "STAGEdev" : {
      "containerfrom"         : "node:12.1",
    }
  },
  "apirestdb" : {
    "username" : "postgres",
    "STAGEme" : {"username" : "apirestme" },
    "STAGEdev" : {"username" : "apirestdev"},
    "CLUSTERwov-aws-va-grape" : { STAGEprod : {"password" : "foobar"}},
    "ORIGINhere"     : {"port" : "5432"},
    "ORIGINexternal" : {"port" : "65432"}
  }
}