Docker compose for stack deploy

[gs0510]

Add script for stack deploy

TODO:
[ ] Make relative paths also work with docker-compose deploy

[art-w]

I believe the CI build is failing because of this path change?

Step 8/20 : RUN opam exec -- dune build --profile=release ./pipeline/bin/main.exe
 ---> Running in f11d5059f3c5
Error: Don't know how to build ./pipeline/bin/main.exe
The command '/bin/sh -c opam exec -- dune build --profile=release ./pipeline/bin/main.exe' returned a non-zero code: 1

On line 22 there is a COPY --chown=opam pipeline/. . that already takes care of "hiding" the pipeline/ directory (so either the COPY or the dune build should handle the pipeline dir, but not both?)

[gs0510]

So the problem here is that the deployer needs absolute path and not relative path. So we have to explicitly say that the path is pipeline/bin/main.exe. It's a bit convoluted. Perhaps these changes should live on the live branch? And we can have a github action to sync them? I don't know if this makes sense.

[punchagan]

Or can we do some environment variable magic to detect that we are in "deployer mode" to use a different path? I don't know enough about deployer, and I'm just thinking out loud here.

[punchagan]

@gs0510 Just writing some thoughts here from yesterday's work.

• I think we don't have enough tests and stability, yet, to be comfortable deploying to production automatically on every merge. We could get there, but it would need some work.

• We could instead have automatic deployments from main to the packet/test machine, and have a script which one of the developers runs, when we are happy with what we see on the test machine. So, ocurrent-deployer could track two branches - main and live. Everything on main gets deployed to the test machine, and live gets deployed to production (autumn). The script run by developers just updates live to the current main when we wish to upgrade the production deployment.

• It would be nice if this workflow had a rollback mechanism too - we could start by keeping track of the exact commits that got deployed to production from the script, but the tricky part would be rolling back the database migrations. All our migrations come with reverse migrations, and potentially there should be a way to do this, but needs some thought.

[gs0510]

Ah I think I didn't mention this, but this is for deployment on the packet machine, not automatic deployments of cb yet! (It'd be nice to get to that, but we have to many moving parts).

I think something to think of also would be (in case we do deployment of production) is that we need to move from docker-compose to docker-stack.

[punchagan]

Ah I think I didn't mention this, but this is for deployment on the packet machine, not automatic deployments of cb yet! (It'd be nice to get to that, but we have to many moving parts).

Yes, I understood that we want to deploy to the "packet" machine. But, I think I don't understand what the purpose of the "packet" machine is. I assumed that the eventual goal was to have a staging environment that we can replicate for production deployments?