feat: added dockerfile and docker-compose

[vitordm]

Added two new files to the repository: Dockerfile and compose.yml.
This update simplifies the process of running s3-browser quickly. By using Docker and Docker Compose, you can easily set up and start the application with minimal effort, ensuring a consistent environment every time.

Usage:

docker compose up -d

[tlinhart]

Hi Vítor, thanks for your contribution. Couple of notes:

• Could you remove the superfluous leading and trailing spaces in the CMD instruction in Dockerfile?
• Please add the syntax directive to the Dockerfile as it's a best practise. I usually use 1.4.0 version as it allows for use e.g. COPY --link (should we ever need it).
• Rename the docker-compose.yaml to compose.yaml as that's the new default path Docker Compose looks for. I'm not really interested in keeping backwards compatible burden.
• I'd like to keep things as simple as possible. So we should be fine with build: . in compose.yaml as that sets the build context to the currect directory and uses the default Dockerfile path.
• The same goes for the env_file instruction which should be as simple as a flat env_file: .env.
  Thanks.

[tlinhart]

As per the comment

[tlinhart]

@vitordm I thought about it a bit more and there are at least two problems with the current approach:

• The Docker image won't build without Docker Compose, i.e. using docker build, because it won't have access to env variables needed for the build. Not everyone is willing to be using Docker Compose and the image has to be buildable even without it.
• Using env_file in the compose.yaml provides the env variables both to the build process and to the runtime, which is undesirable. We only need the credentials (and the rest of vars) during the build and don't want it to be exposed during runtime. (I'm aware that finally the credentials are still hard-coded in the built index.html, but this at least lowers the vulnerability surface.)

We have couple of options to solve it:

• Use build arguments using ARG in Dockerfile and declare every supported env variable that's used in the build. This still leaves some security issues as the arguments are then leakable using docker history on the final image.
• Use build arguments as before but also use multi-stage build. In the build stage, we would provide arguments, build the app and in the runtime stage, we would just copy the files and there would be no trace of the credentials (well, apart from the index.html itself as noted above).
• Use build secrets for passing the env file to the npm run build step. This has a downside in that you have to use .env file. This, on the other hand, is also an upside as that means you don't have to enumerate all the supported env variables on multiple places (webpack config, Dockerfile, compose.yaml, ...)

So I'd have a small preference for the last option using build secrets. What do you think?

[vitordm]

@vitordm I thought about it a bit more and there are at least two problems with the current approach:

• The Docker image won't build without Docker Compose, i.e. using docker build, because it won't have access to env variables needed for the build. Not everyone is willing to be using Docker Compose and the image has to be buildable even without it.
• Using env_file in the compose.yaml provides the env variables both to the build process and to the runtime, which is undesirable. We only need the credentials (and the rest of vars) during the build and don't want it to be exposed during runtime. (I'm aware that finally the credentials are still hard-coded in the built index.html, but this at least lowers the vulnerability surface.)

We have couple of options to solve it:

• Use build arguments using ARG in Dockerfile and declare every supported env variable that's used in the build. This still leaves some security issues as the arguments are then leakable using docker history on the final image.
• Use build arguments as before but also use multi-stage build. In the build stage, we would provide arguments, build the app and in the runtime stage, we would just copy the files and there would be no trace of the credentials (well, apart from the index.html itself as noted above).
• Use build secrets for passing the env file to the npm run build step. This has a downside in that you have to use .env file. This, on the other hand, is also an upside as that means you don't have to enumerate all the supported env variables on multiple places (webpack config, Dockerfile, compose.yaml, ...)

So I'd have a small preference for the last option using build secrets. What do you think?

Thanks for the detailed feedback. I understand your perspective; however, I view docker-compose as a method for quick local deployment, which is why I appreciate the "env" mode and the simplicity of executing docker-compose up.