Migrations

Migrations can be added to a BYOC application to run operational scripts, make database schema changes and more.

While Nuon does not enforce how migrations are dispatched for an install, this document outlines several common approaches.

​

Kubernetes Applications

If your application is using Kubernetes, and you are packaging via Helm you can use a chart hook to execute a migrations script.

For example in your helm chart:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: migrations
  namespace: {{ .Release.Namespace }}
  annotations:
    "helm.sh/hook": post-upgrade
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: migrations
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          command:
            - /bin/service
            - migrations

Then, when Nuon installs or upgrades the chart in your install, the hooks will be executed:

​

Job Components

Job components can be used to run any script within a container image as part of your install. They work just like any other component, and give you access to do powerful things such as run schema migrations, batch jobs and more.

To use job components to manage migrations, first start by adding a container image or docker build component that combines your migration tool, and migrations:

Next, declare a job config that executes your migrations image.

When the job component is released, the script will be executed just like any other component deploy.

This approach can be used with common migration tools including:

1. Atlas
2. Flyway

You can use an existing application container, and use the job component to run a command such as npm run migrations or rake db:migrate depending on your framework.