Feature/slt 134 postupgrade split

[Jancis]

Story:
https://wunder.atlassian.net/browse/SLT-134

Description:
splits post-install resource into two - one that gets triggered after new helm deployment install and another that is run after deployment update.

• Install checks for config files in sync folder. If they exist, installs site with a config_installer profile and imports said configuration. imports database dump from (shared) mounted location /var/backups/db. Shared NFS location must be deployed beforehand.
• Update imports config files, updates entitity configs and runs database updates.

---

Shared persistent volume resource for project

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: {{ .Release.Namespace }}-dbdump
  namespace: {{ .Release.Namespace }}
spec:
  storageClassName: nfs
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

[Jancis]

@floretan where should I put the shared storage resource? Maybe I should take another approach to the shared dbdump storage? (see PR description above). I made a simple chart with just this resource and deployed it manually to cluster, but maybe there's some better way to check/create/update kubernetes resources when deployment is run.

[floretan]

@Jancis I think we will need some kind of project-level chart, and as you pointed out it could consist of only a single volume. This chart could be provisioned from CircleCI, but limited to the master branch.

Since the volume doesn't need to be mounted multiple times, we should be able to use the "standard" volume provider. One possible alternative would be to use Cloud Storage (Google's S3) via a service broker. This type of block storage is perfect for storing backups, and it should be cheaper as well.

[Jancis]

@floretan there is stll a (very) slim chance it would be mounted simultaneously on two containers - the regular backup+sanitization from "production" branch and postinstall import when a new branch is deployed (share is mounted, sql dump is imported).

[Jancis]

I need to add private storage to container.

[Jancis]

Next steps: moving commands into values.yaml file so the db import can be assessed later, when the storage is solved.

[Jancis]

• Made a split, removed backup restore on first deployment, just the site-install with config install if such exists.
• Moved configs to values file, based on suggestions from https://github.com/wunderio/charts/pull/3/files

Branch force-pushed with a clean branch because it has pretty deviated from master.

[floretan]

@Jancis this looks good. I would move the configuration under drupal in the values.yaml file. It could be that in the future we also get cron jobs for other systems.