moving pgsodium_root.key to its own directory to allow it to be mou…

[ghost]

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

Currently, the main docker-compose.yml file does not allow pgsodium_root.key to survive a cycle of docker compose down/docker compose up.

The problem is, the key (current location within container: /etc/postgresql-custom/pgsodium_root.key) is being overwritten. See supabase/vault#27 and supabase/vault#30.

Previous (unworking) attempts at solving this problem:

• mount /etc/postgresql-custom/pgsodium_root.key to /volumes/db/pgsodium_root.key (see here and here)
  • this does not work, because the file /volumes/db/pgsodium_root.key will not exist on the first docker compose up, this causes the path /volumes/db/pgsodium_root.key to be treated as a directory even when the :Z flag is supplied
• generating an empty /volumes/db/pgsodium_root.key and using the method above
  • this also does not work, as the current behavior does not check if a key was properly loaded (i.e., is the file non-empty)

What is the new behavior?

The new behavior would store /etc/postgresql-custom/pgsodium_root.key in its own directory: /etc/postgresql-custom/pgsodium. The full path of the key would become: /etc/postgresql-custom/pgsodium/pgsodium_root.key.
This way, the key file can be mounted in docker compose as follows:

# ...
  db:
    # ...
    volumes:
      # ...
      # pgsodium decryption key
      - ./volumes/db/pgsodium:/etc/postgresql-custom/pgsodium

In the above scenario:

• on the first start, /etc/postgresql-custom/pgsodium/pgsodium_root.key would not exist and would be created; since the entire parent directory (/etc/postgresql-custom/pgsodium) can be mounted in docker-compose, the /etc/postgresql-custom/pgsodium/pgsodium_root.key file would survive the initial docker compose down.
• on subsequent starts, /etc/postgresql-custom/pgsodium/pgsodium_root.key will exist (from /volumes/db/pgsodium/pgsodium_root.key and be utilized instead of a new key

Additional context

The point of this is to solve supabase/vault#27 and supabase/vault#30, where self-hosted supabase vault instances cannot survive a docker compose down.

[sweatybridge]

Closing as this is too big a breaking change for our infra and cli. Using docker named volume solves the original issues.