Bug: Catch-22 when migrating to Kubernetes cluster

[kajes]

There's an issue with restoring a Snipe-IT instance in a Kubernetes cluster using the snipeit helm chart. According to the documentation, moving a Snipe-IT instance from one server to another is a matter of copying files from the backup to the new server instance, setting the environment variable BACKUP_ENV to true before you start migrating.

The BACKUP_ENV variable prevents the installer running when accessing the site before migrating, resulting instead in the page erroring out until you've migrated all the files.

This, however, also causes the /health endpoint to also throw PHP exceptions, which means the kubernetes controller will judge it to be unhealthy and kill the pod before you have the chance to migrate everything, leaving the pod in an endless CrashLoopBackOff state. Unfortunately, the only way to prevent the endless restart state is to actually copy the files, mainly the .env file to the proper location in the pod container.

Currently, there's no way to prevent this without building your own custom container image which copies the .env file into the pod when building, and then make the chart pull that image instead.

There are probably multiple ways of solving this, but one way is to allow the user to specify their own .env file in values.yaml to prevent this from happening.

[mschmidt291]

So setting the BACKUP_ENV variable through .Values.config.snipeit.envConfig and then disabling liveness and readiness probe is not enough? Currently there is no way to disable the liveness and readiness probes, but this wouldn't be a problem.

[kajes]

@mschmidt291

That would be one solution, but probably pretty bad practice. Would make more sense to try to populate the .env config with values that the user should provide for the database already. It seem to mainly be SQL Connection errors that are thrown. Alternatively you should be able to load a .env from a configmap you create yourself.

Edit: In fact, it would make a lot of sense if you could specify a .env to be mounted in the already existing config.snipeit.envConfig object. Something like this:

config:
  snipeit:
    envConfig:
      .env: |
        DB_HOST: <hostname>
        [...]

This could be mounted as the .env file if the key exist in the object.