search

brainlife / ezbids

A web service for semi-automated conversion of raw imaging data to BIDS
https://brainlife.io/ezbids
MIT License
26 stars 13 forks source link

Add Standalone Production config #134

Open buti1021 opened 2 weeks ago

buti1021 commented 2 weeks ago

Following the excellent work by Anthony I split the nginx into a proper config production which doesnt use the vite development server.

I still have a few open questions/remarks I want to discuss:

  1. Env File, imo we should put the .env into version control, just an example of it. My prefered solution would be to create a file called .env-example and .gitignore the .env file.
  2. The development version as provided right now is not really working, as the vite can't access the wss for HMR. I would ask the question if we should really use nginx for the dev setup. Happy for your input here.
  3. Healthchecks: @bendhouseart Your changes to the healthchecks in the compose file, didn't work for me. What was the point behind your changes?
  4. Startup scripts (dev.sh and prod.sh) I see the benefit of those files (git submodules & key generation) but also would try to look for a streamlining of the storage of environment variables (script vs. .env) and the duplication of code between the dev and prod file. + I don't completly understand why the npm dependencies are installed in that script and not in the Dockerfiles of the corresponding containers. Option might be to merge dev and prod into a start.sh with more flags.
  5. Nginx config file, I think this a good starting point, not sure tho how far we can go with this as setups are quiet different (e.g. we have dont have our cert key encrypted and as a result don't have a ssl_password_file. Thus the nginx fails. Maybe remove the config from the code repo and put it into the documentation as an example instead?
  6. The api still runs in dev mode more or less. Didn't completly get what the start.sh is used for here (maybe nowhere at all?). Might have time to tackle that in the next few days.

Happy for your input.

Best,

Tim

bendhouseart commented 2 weeks ago

Env File, imo we should put the .env into version control, just an example of it. My prefered solution would be to create a file called .env-example and .gitignore the .env file.

Yes, that makes sense, but I prefer example.env ;). I think it's worth adding an if [ ! -f .env ]; then cp example.env .env fi somewhere to handle things (adding this to my branch right now).

The development version as provided right now is not really working, as the vite can't access the wss for HMR. I would ask the question if we should really use nginx for the dev setup. Happy for your input here.

I'd like to commit to nginx always being run b/c that makes the development and production environments as similar as possible (barring how brainlife.io deploys things). That is to say I think it's simpler to have 2 nginx configuration files and 1 env file then to have multiple docker compose files, but that solution while being simpler to me may not be the best path forward.

Healthchecks: @bendhouseart Your changes to the healthchecks in the compose file, didn't work for me. What was the point behind your changes?

It was required as the health checks were failing when reaching out to localhost after we got nginx up and behaving. Since we were all in on nginx it seemed like a good idea to just go with it in the compose too.

Startup scripts (dev.sh and prod.sh) I see the benefit of those files (git submodules & key generation) but also would try to look for a streamlining of the storage of environment variables (script vs. .env) and the duplication of code between the dev and prod file. + I don't completly understand why the npm dependencies are installed in that script and not in the Dockerfiles of the corresponding containers. Option might be to merge dev and prod into a start.sh with more flags.

Yeah, I had some similar remarks about the run/build process, but I think it's helpful to keep in mind that this is not how ezbids is deployed on brainlife.io. Technically speaking, everything we've been doing has been "non-production" compared to how this project was originally scoped/intended to work.

I agree and will be working today to streamline the launch/build process to better leverage:

Nginx config file, I think this a good starting point, not sure tho how far we can go with this as setups are quiet different (e.g. we have dont have our cert key encrypted and as a result don't have a ssl_password_file. Thus the nginx fails. Maybe remove the config from the code repo and put it into the documentation as an example instead?

When I requested my ssl certs I encrypted the keys, I'm not sure of a clever way around this within the nginx config. Before we think too much on this, could you try running the http version (point to nginx/development_nginx.conf) instead? My thinking is to use the http nginx enabled version for local development and the https nginx version for production going forward.

The api still runs in dev mode more or less. Didn't completly get what the start.sh is used for here (maybe nowhere at all?). Might have time to tackle that in the next few days.

No idea either, but I think consolidation is the word of the week for my branch.