Docker Compose Revisited

[panasenco]

I'm frustrated that the docker compose file submitted in #6 by @infogulch was quietly deleted in b903055523b52fc809f36c0baf891abb38b804af.

I understand that a docker-compose file by itself cannot provide the flexibility and power that a script can. But a compose file is an absolute necessity for someone deploying Terminus to an orchestration service like Docker Swarm. Forcing users to use a script rather than a compose file eliminates a lot of Docker's usefulness.

I'd like the compose file to be reintroduced and the launch script to be rewritten to use the compose file when launching Terminus.

Specifically, I'd like to see:

1. Use of Docker Compose file version 3 and maintain full compatibility with Docker Swarm mode.
2. The Terminus team commit to either using environment variables in the user's shell OR variables in a special environment file but NOT both. Move as much of the environment variable default setting logic as possible to the compose file via:
   • If using environment variables in the user's shell: Use the environment directive with variable substitution. Compose files even allow variables in the image version tag.
     • If using an environment file: Use the env_file directive.
3. Declare and mount the persistent storage volume in the compose file.

I should be able to start terminus with either docker-compose up -d OR docker stack deploy -c docker-compose.yml terminus producing a valid container I can access via localhost:6363 and connect to Terminus Hub from - without ever touching the terminusdb-container file. This container should also persist state between application launches by default.

[rrooij]

Thanks for making this issue. We provided the docker-compose.yml as an example, thanks to the contribution of @infogulch. But some people were having trouble with the provided docker-compose because we did not maintain it. As we can't guarantee that the docker-compose file works as expected, we decided to get rid of it so people would not get into these issues.

You are providing good arguments for a maintained docker-compose file. We'll definitely consider it. The reason why we chose a bash script in the first place is that we can launch terminusdb-server in a more controlled way, especially when we consider future upgrade paths as well. But you are right that it is possible to launch the docker-compose with the bash script as well. And using one ENV file would be the cleanest solution for sure.

I'm leaving this issue open as you provide good arguments and it might be worth considering again.

[panasenco]

Thanks @rrooij, I'm glad you're at least open to the idea 👍

[infogulch]

But some people were having trouble with the provided docker-compose

I'm sorry to hear that people were having issues with docker-compose, and I totally understand your reluctance to maintain a deployment method that you don't use inside the team. I've found that docker can be finicky to get set up the first time, but once it's working, a docker-compose-based deployment is the simplest and most repeatable way to manage small-medium deployments.

Do you recall (or can you reference) the issues that users were having with the original docker-compose.yml? Maybe we could make the docker-compose experience smoother or better documented.

[dmytri]

Hey @infogulch, @panasenco, we're adding the compose file example to the main terminusdb-server repo instead, so it's moving on up.

For bootstrap, docker-compose introduces another dependency which is not required and having an alternative makes it more confusing to use and to document, so I'll close this issue for now.

[infogulch]

@dmytri limiting the scope of this repo to reduce complexity for new users is a good strategy imo. Once the the docker-compose-based solution is in place in the main repo, perhaps it would deserve a mention here for people that are looking for it.

[rrooij]

I added the docker-compose in the main repo.

https://github.com/terminusdb/terminusdb-server/commit/41392c96c92eaddbde19b3c86c0cd4923f3c38a6