Home

Welcome to the sk8 wiki!

Purpose

The purpose os this tool is to have a developer/source-controlled deployment of microservices to a series of kuberentes-cluster of different stages (dev, testing, staging, production), and using the same basic service-definition thru the entire chain.

Story

This is a basic CI/CD example/story of using sk8 to deploy microservices to 2 kubes: Dev & Prod

Both kubes have their own repo: KubeDev and KubeProd

Folder layout

KubeDev/
  |- .sk8default/
  |    |- default.yaml
  |
  |- templates/
  |    |- cronjob.yaml
  |    |- deploy.yaml
  |    |- service.yaml
  |
  |- ns1/
  |    |- .config/
  |    |    |- sql.yaml
  |    |
  |    |- .sk8/
  |    |    |- defaults.yaml
  |    |
  |    |- service1.yaml

sk8-settings:

# file: .sk8default/default.yaml

# Will apply to all sk8-objects in files in current folder and below
port: 8080
extra:
  replicas: 1
  history: 2
teplates:
  service: "../templates/service.yaml"
  deploy: "../templates/deploy.yaml"

# file: ns1/.sk8/defaults.yaml

# Will apply to all sk8-objects in 'ns1'
namespace: ns1

Configs and Secrets

# file: ns1/.config/sql.yaml

# Regular K8 ConfigMaps and Secrets
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: sql
data:
  CUSTOMERDB: Tk9USElOR19UT19TRUVfSEVSRV9fTU9WRV9BTE9ORw==

Templates

These are 'text/template'-instructions on converting a sk8-object into a kubernetes object.

See in the examples/templates-folder for examples

2 kube-repos ?

KubeProd is basically a copy of KubeDev, with some differences:

KubeDev

  replicas: 1

KubeProd

  replicas: 4

Source & commit/checkin

Sourcecode gets checked in and built. In the source-repo a folder called deploy exists, containing:

# file: ns1/service1.yaml
name: service1
version: x
port: 3000
env:
  secret:
    CONNECTIONSTRING:
      name: sql
      key: CUSTOMERDB

Process

During build the version-number is replaced in all deploy/*.yaml-files with the build-version from the tools one use.

The entire deploy-folder is then packaged as the 'artifact' from the build (because the actual version-tagged docker-image has been send to a private docker-repo).

After the build is completed an automatic deploy to KubeDev is triggered:

• This clones the KubeDev repo copies in the files from the artifact
• Runs sk8 -all -apply on all the files from the artifact (thus doing a kubectl apply on the result)
• Commit & Push the changes to the KubeDev repo

After testing/verification

Once it's verified the service is ok, a person then manually triggers the release to KubeProd, repeating the same process as above on the production system.

Revert a release

Since the artifact contains a versioned artifact we can simple re-apply the older release thus applying the previous settings and version.