otterwiki icon indicating copy to clipboard operation
otterwiki copied to clipboard

nginx baked into the docker image

Open edheliel opened this issue 1 year ago • 4 comments

Current State

The docker image comes with nginx reverse proxy baked in and opens container port 80.

Issue description

  • binding to lower ports requires privileges and I assume this is why the container runs as root, which is not a good security practice and also breaks the container if you want to deploy it on kubernetes with runAsUser as you won't have those privileges
  • On production like deployments or microservice based deployments you usually have an IngressController or a separate reverse proxy that would deal with SSL termination

Conclusion

  • Removing nginx from the docker container would improve the state of the application in several ways
  • The documentation already talks about reverse proxies and how to set them up for otterwiki

PS: Unless there is some other reason why nginx is inside of the docker image, for me seems reasonable to not ship the container with nginx and rather use smaller more secure container image like alpine or the likes

If this is on your radar I am also happy to help

edheliel avatar Jul 02 '24 12:07 edheliel

Hey @edheliel, thank you for bringing this up.

The image has nginx bundled originally out of two reasons:

  1. Serving static files, doing this with flask is highly inefficient and with uwsgi alone I did not manage to find a performant solution, but I have not tried this again and it maybe worth a shot.
  2. For convinience with nginx bundled it's easy to deploy the image standalone. The 10MB of wasted memory are in my opinion bearable.

I agree with the point of running an unpriviliged user and an overall smaller image.

This might cause a problem that I want to avoid: breaking backwards compability. So that An Otterwiki user breaks an existing installation because of a change in ports.

Thinking about it: Maybe an extra released "slim" image, with a matching tag like otterwiki:2.x.y-slim would be a conceivable middle ground?

redimp avatar Jul 02 '24 16:07 redimp

Hi @redimp,

Sorry for the late reply, life happened. I agree that maybe going for 2 different versions of the docker image is the way to go so everyone can choose what they feel is the right thing for them.

edheliel avatar Jul 06 '24 15:07 edheliel

For testing the slim docker image is available as: redimp/otterwiki:dev-2.4.3-alpine-slim

The size of the compressed image for e.g. amd64 was (accoording to hub.docker.com) reduced from 167.04 MB to 67.69 MB.

The amount of memory consumed is reduced by approx. 25 MB for amd64, due to skipping both nginx and supervisord.

redimp avatar Jul 09 '24 21:07 redimp

Did some testing, looks promising. Just switched otterwiki.com with the release of 2.4.4 to the slim image.

Open task: Update the documentation.

redimp avatar Jul 10 '24 23:07 redimp

FWIW, I think the hard dependency on nginx-1.25.3 in

https://github.com/redimp/otterwiki/blob/67264121ab51b83b7e4164b49ba89cd380eae4c6/Dockerfile#L4

and

https://github.com/redimp/otterwiki/blob/67264121ab51b83b7e4164b49ba89cd380eae4c6/Dockerfile#L51

is what is "the most wrong" about the current approach, and you should depend on stable-bookworm instead.

jtru avatar Oct 09 '24 09:10 jtru

The documentation howto use the slim image can be found here: https://otterwiki.com/Installation#the-slim-image-variant

I also addressed to base image used, as @jtru suggested in https://github.com/redimp/otterwiki/commit/e8fb063efe324c476bbe1abc2a956887a098fe79

redimp avatar Nov 10 '24 20:11 redimp