3.0.0

Release notes

Important

Breaking changes

This realease introduces several breaking changes. Make sure to adjust your HelmRelease files to use this version

What's Changed

Volumes handling

This release changes how volumes should be configured. At this point we support three type of volumes:

• nfs
• secret
• configmap

Every type of volume has it's own mountPath and subPath parameters.

Warning

NFS configuration is moved one level up in HelmRelease structure, during the type object removal. Be sure, to follow the provided NFS example on upgrade.

NFS example:

volumes:
  ownership: 991:991
  nfs:
    server: srv-storage.lan
    path: /storage
    mountPath:
    - data:/data

Upgrading

Before version 3.0.0

volumes:
  enabled: true
  mountPath:
    - model-cache:/cache
  ownership: 0:0
  type:
    nfs:
      server: nfs.lan
      path: /storage

On version 3.0.0

volumes:
  ownership: 0:0
  nfs:
    server: nfs.lan
    path: /storage
    mountPath:
    - model-cache:/cache

Service name

Previous version of this HelmChart has service name prefixed with ReleaeName value. This turned out to be a little bit confusing how service should be named when this name should be referenced in other app. This approach was replaced with static service name

Example:

services:
  - name: app-web
    protocol: "TCP"
    servicePort: 8080
    targetPort: 80

What's added

Configmap volumes

This feature allow to mount files in configmap inside container.

Configmap example:

volumes:
  configmap:
    configMap: application-config
    mountPath: /app/config.json
    subPath: config.json

Secret volumes

This new feature allows to mount secret as a file inside container.

Secret Example

volumes:
  secret:
    secretName: application-secret
    mountPath: /app/secret.json
    subPath: secret.json

What's removed

dbsecrets

This resource was used to generate app-related database secret. It's no longer needed since SOPS was introduced as the way to provide encrypted secret data

initwebsitedir

This webhook was removed to the execution problems. It was responsible for creating directory structure on NFS share for deployed application. This hook was executed before helm, install process. Perhaps this feature will be restored in future versions. For now it was removed due to app deployment disruption.

Mattermost-notify

This webhook was executed to notify users, that application is deployed on kubernetes cluster. It turned to be not useful as i thought.

MySQLDBHelper

This webhoo along with dbsecrets was developed to create database for application. It was not maintained anymore. It's support MySQL databases only, so it's not so useful anymore.

2.7.0

Added

SecurityContext

Adding k8s securityContext support. https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
Helpful, when certain app running inside a pod needs additional privileges.

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  capabilities:
    add: ["IPC_LOCK"]

ConfigMap

With this version you can attach custom configMap object to helmrelease file

app configmap example

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
  namespace: default
data:
  nginx.conf: |
     worker_processes 1;
     daemon off;
     error_log nginx_error.log;
     events {
         worker_connections 1024;
     }

    http {
       server {
         listen 8008;

         location / {
            root /Users/bsergean/src/sandbox/json/jsoncpp;
         }
       }
    }

HelmRelease fragment example:

values:
   configMap:
       name: nginx-conf
       mountPath: /etc/nginx.conf

2.6.1

What's Changed

• fix: hardcoded namespace value replaced with .Release.Namespace (helm doc) by @kkrolikowski in #15

Full Changelog: 2.6.0...2.6.1

2.6.0

Probes configuration (livenessProbe and startupProbe)

This change resolves issue #7, where some applications failed to start due to overly restrictive probe configurations. The problem was addressed by moving the startupProbe and livenessProbe sections directly into the HelmRelease files of specific applications. The Helm chart now imports this configuration to create the deployment objects.

Example

startupProbe:
  httpGet:
    path: /
    port: 666
  failureThreshold: 30
  periodSeconds: 10
livenessProbe:
  tcpSocket:
    port: 666
  initialDelaySeconds: 10
  periodSeconds: 2

More info on: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Pre hook: initWebsiteDir

In some situations hook returned non 0 status code, so applications deployment was distrupted. This was fixed by checking if application directory exists.

2.5.0

Use case

In some cases there's a need to share common shared storage space among more than one app or different app instances (i.e. server and worker instances). To solve this problem a new option was introduced: rootDir
This change was introduced in #9 issue.

How to use

rootDir configuration

values:
  volumes:
    rootDir: common

This parameter is optional, so when no rootDir is specified, than HelmRelease name will be used to create parent folder on shared storage.

2.4.0

Liveness Probe

Ability to enable liveness probe on specified port. Liveness probes are TCP type

Hardcoded setup

initialDelaySeconds: 10
  periodSeconds: 2

Tolerations

When certain cluster node is not available

node.kubernetes.io/unreachable
node.kubernetes.io/not-ready

Pod should be killed and deployed on healthy node after 10 sec.

LoadBalancer

Ability to specify IP Address to be used in certain service.

Example

values:
   services:
     - name: ssh
        type: LoadBalancer
        protocol: "TCP"
        loadBalancerIP: 10.0.0.100

2.3.0

Changed

• removed liveness probes
• redefined startup probes

Added

• private container registries support (imagePullSecrets)
• support of multiple ingresses to single deployment

Container commands

Added option to run containers with custom commands and args.

image:
  repository: imagename
  tag: version
  command: 
    - "cmd.sh"
  args: 
    - "cmdarg"

Service Protocol Family

Added variable protocol in Values.services specitication. This allows to choose between protocol family which is used by application (i.e. named port 53)