Configurations - woveon/wovtools GitHub Wiki

;TLDR - The wovtools/config.json and wovtools/local.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.

Goals

  • 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.
  • Configurations are versioned
  • Configuration sets are deployed with Docker containers and Kubernetes files.

About Configuration Config Files (wovtools/{config|local}.json) WovTools manages configurations in two files (wovtools/config.json and wovtools/local.json). The config.json is packaged with the repository and contains rules for dev and prod stages while local.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. .secretsmods: modifications to a stage for a specific use like local development or in a pod
  3. .localcontext: which defines the configuration to use locally (ex. creating configurations that swap things like databases or remote vs local servers, etc.).

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

  • There can be multiple files.
  • They are json format
  • Information is hiararchical and changes are broken out by STAGE.
    • i.e. level one is your microservice name
    • level two can be fixed information across all uses of your microservice, or a STAGE name (ex. 'dev', 'prod', your initials or nickname)
  • information can be specific to CLUSTERS by setting the key to start with CLUSTER. (ex. cluster wov-aws-va-dog would have { "CLUSTERwov-aws-va-dog" : {} }.
  • 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.

{
  "apirest" : {
    "healthpath" : "/api/v1/health",
    "ver" : "v1",
    "containerfrom"         : "node:10.1",
    "CLUSTERwov-aws-va-dog" : {
      "containerfrom"         : "node:11.1",
    },
    "STAGEdev" : {
      "containerfrom"         : "node:12.1",
    }
  },
  "jb" : {
      "containerfrom"         : "node:10.1",
      "urlscheme"             : "https",
      "url"                   : "api-jb.woveon.com",
      "daemonTime"            : 60000,
      "port_int"              : 80,
      "port_ext"              : 3010,
      "healthprobetime"       : 180,
      "defaultUser" : {
        "password"  : "XXXXXXXXXXXXXX"
      }
  }
}