You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just dropping this to team as a perspective, since I recently deployed Semapps.
The process outlined in the deploy readme is roughly as follows:
Copy the deploy folder somewhere on your server
Edit the docker-compose.yml files as well as 3 seperate .env.local to set various deployment parameters
Run docker compose build and docker compose up -d
I understood from @srosset81 that part of the motivation here was to allow the loading of custom files to the containers from the folders.
It feels like a weird way to deploy an app. As a simple step from the current setup towards a more streamlined and - in my opinion - idiomatic way of deploying compose apps, I would suggest the following changes:
Centralize all deployment parameters into env vars that are loaded centrally through docker-compose.yml into containers
To deploy the app, the user needs to only copy the docker-compose.yml file
The user can then pass all parameters through a single .env file or by setting environment variables in the host system
If additional data needs to be passed into containers, the user could mount volumes to them, possibly configurable through environment variables
Running the app is done as before: docker compose up -d (docker compose build can be removed from the readme since this happens automatically in compose anyway if needed).
This is a matter of taste and experience of course, but this approach is more in line with deployment strategies I've personally seen so far.
The text was updated successfully, but these errors were encountered:
Personnally, I create a (private) repo for all my deployments.
So I copy the deploy folder (only), make the changes, and then push everything to the repo. I then clone it on the server.
I don't think it's a good practice to edit the env variables directly on the server, because if the server disappears, you lose all your configurations.
This is true, but it doesn't invalidate my argument that configuration is needlessly complex. The simplifications I propose work equally well when stored in a git repository.
Just dropping this to team as a perspective, since I recently deployed Semapps.
The process outlined in the deploy readme is roughly as follows:
deploy
folder somewhere on your serverdocker-compose.yml
files as well as 3 seperate.env.local
to set various deployment parametersdocker compose build
anddocker compose up -d
I understood from @srosset81 that part of the motivation here was to allow the loading of custom files to the containers from the folders.
It feels like a weird way to deploy an app. As a simple step from the current setup towards a more streamlined and - in my opinion - idiomatic way of deploying compose apps, I would suggest the following changes:
docker-compose.yml
into containersdocker-compose.yml
file.env
file or by setting environment variables in the host systemdocker compose up -d
(docker compose build
can be removed from the readme since this happens automatically in compose anyway if needed).This is a matter of taste and experience of course, but this approach is more in line with deployment strategies I've personally seen so far.
The text was updated successfully, but these errors were encountered: