Package: ok8deploy
Openshift/K8 templating and deployment engineSuper simple python templating and deployment engine for openshift/k8 yml files.
Detects changes made and only applies the required objects.Use caseThis tool was born in the need to a very simple templating system
which can track changes (similar to terraform). It was build for my requirements but should
fit others as well.RequirementsPython 3.8 or lateroc(orkubectl) binary in pathUsageDeploy all changesDeploys all enabled apppython deploy.py deploy-allDeploy single appDeploys all object of the app with the give namepython deploy.py deploy nginxReload configThis command executes theon-config-changetriggerpython deploy.py reload prometheusConfigurationIn OK8Deploy you define apps, each app can contain multiple yml files.
Additionally, there is a project configuration which describes the openshift project.All yml files will be pre-processed before they will be imported.
This includes replacing any known${KEY}variables with their associate values and merging referenced templates.Config structureconfigs
|- _root.yml <- Project config
|- my-app <- App
    |- _index.yml <- App config
    |- dc.yml <- Openshift yml file(s)
    |- secrets.ymlProject configHere is a sample_root.ymlfileproject: 'my-oc-project'

# OPTIONAL STUFF
# Global variables
vars:
  DOMAIN: "dev-core.org"App configAn app is represented by a folder containing an_index.ymlfile and any additional openshift yml files.
The following shows all available parameters. Only the first 3 are required.# The type defines how the app will be used.
# Can be "app" (default) or "template"
type: 'app'

# Indicates if this app should be deployed or ignored
enabled: true 

# Deployment config parameters
dc:
    # Name of the deployment config, available as variable, see below
    name: 'my-app'

# Template which should be applied, none by default
applyTemplates: []

# Templates which should be applied AFTER processing the other templates and base yml files
postApplyTemplates: []

# Action which should be executed if a configmap has been changed
on-config-change:
# Available options: 
# deploy (re-deploys the deployment config)
  - deploy

# exec (Executes a command inside the running container)
  - exec: 
      command: /bin/sh
      args: 
        - "-c"
        - "kill -HUP $(ps a | grep prometheus | grep -v grep | awk '{print $1}')"

# Additional variables which are used for replacements
vars:
  NSQ_NAME: 'nsq-core'

# Required parameters which must be passed to this app.
# This can be done via the CLI or if this app is a template the referring app can define it in "vars" 
params:
  - PASSWORD

# File based configmaps
configmaps:
  - name: nginx-config
    files:
      - file: "nginx.conf"ConfigmapsIn addition to the regular configmaps you can also define configmaps with a file source.
This is done in the_index.ymlfile:configmaps:
  - name: nginx-config
    files:
      - file: "nginx.conf"This will create a new configmap from the filenginx.confwith the namenginx-config.
Any changes made to the file will be automatically deployed.VariablesYou can refer to variables in yml files by using${VAR-NAME}. Variables can also be loaded from files.# _index.yml
vars:
  # Regular key/value assignment
  key: value

  # This will load the public/private and intermediate certs
  # from a pem file and store it in *_KEY, *_PUBLIC, *_CACERT
  # where * is the key of the value (CERT in this example)
  CERT:
    loader: pem
    file: my-cert.pemIt is also possible to decorate objects using variables:# _index.yml
vars:
  someMerging:
    hello: world
    replicas: 2# dc.yml
spec:
  replicas: 1
  _ok8merge: ${someMerging}Results in:spec:
  replicas: 2
  hello: worldGlobal variablesThe following variables are available anywhere inside the yml files by defaultKeyValueDC_NAMEName of the deployment-config in the_index.ymlOC_PROJECTName of the openshift project in_root.ymlTemplatesYou can use templates to reuse and generate yml files.
To do so you create a new app with thetypefield set totemplate.
Other apps can now refer to this template via theapplyTemplatesorpostApplyTemplatesfield.
Templates can refer to other templates (recursively). Any vars defined are passed to the next template.Example:|- some-template
    |- _index.yml
    |- dc.yml

|- my-app
    |- _index.yml <-- Referes to "some-template"
    |- others.ymlWill result in|- my-app
    |- _index.yml
    |- others.yml
    |- dc.ymlObject mergingThe template engine support content aware object merging.
This allows you to decorate existing templates or enhance apps with features.
A common example would be a template which adds a monitoring sidecar container.
In theexamplesyou can find thensq-templatewhich defines a sidecar container.Here is a minimal example:# examples/nsq-template/dc.yml
kind: DeploymentConfig
apiVersion: v1
spec:
    template:
        spec:
        containers:
            - name: "nsqd"
            image: "nsqio/nsq"# examples/my-app/dc.yml
kind: DeploymentConfig
apiVersion: v1
metadata:
  name: "${DC_NAME}"

spec:
  replicas: 1
  selector:
    name: "${DC_NAME}"
  strategy:
    type: Rolling

  template:
    metadata:
      labels:
        name: "${DC_NAME}"

    spec:
      containers:
        - name: "${DC_NAME}"
          image: "docker-registry.default.svc:5000/oc-project/my-app:prod"If we now apply the nsq-template to our app usingpostApplyTemplates: [nsq-template]theDeploymentConfigobject gets automatically merged:# Merged result after applying template
kind: DeploymentConfig
apiVersion: v1
metadata:
  name: "${DC_NAME}"

spec:
  replicas: 1
  selector:
    name: "${DC_NAME}"
  strategy:
    type: Rolling

  template:
    metadata:
      labels:
        name: "${DC_NAME}"

    spec:
      containers:
        - name: "${DC_NAME}"
          image: "docker-registry.default.svc:5000/oc-project/my-app:prod"
        # This is the part of the template
        - name: "nsqd"
            image: "nsqio/nsq"LoopsLoops allow you to apply the same template with different parameters.
This is useful when deploying microservices which all have the same openshift config.# _index.yml
enabled: true
applyTemplates: [ api-template ]
forEach: 
    # DC_NAME is required for each instance that should be created
  - DC_NAME: entity-compare-api
    # You can define other vars as well
    PORT: 8080

  - DC_NAME: favorite-api
    PORT: 8081LibraryIt's possible to define whole project as alibrary. This allows all apps and templates to be reused
by another project. An example would be the same setup for multiple systems which are separated by projects (e.g.dev/test/prod).# testLib/_root.yml
type: library

# Required parameters
params:
  - domain
  - dockerDomain
  - imageStreamTag# prod/_root.yml
project: 'prod-project'
inherit: testLib

# Required parameters
vars:
  domain: my-prod.dev-core.org
  dockerDomain: prod-docker.com
  imageStreamTag: prodWhen you now deploy theprodproject it will inherit all apps insidetestLib.Change trackingChanges are detected by storing a md5 sum in the label of the object.
If this hash has changed the whole object will be applied.
If no label has been found in openshift the object is assumed to be equal, and the label is added.ExamplesAll examples can be found in theexamplesfolder.GrafanaThe grafana folder contains a basic grafana setup.NSQThis example adds an NSQ sidecar container to a deployment config.my-app/_index.ymlenabled: true
postApplyTemplates: [nsq-template]
vars:
  NSQ_NAME: 'app-nsq'

dc:
  name: my-appContributeThe code should be mostly commented. If you found a bug or want to improve something feel free to open an issue and discuss your ideas.