This repository was archived by the owner on Jul 15, 2022. It is now read-only.
Add support for Docker #27
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To spin up a container just do:
docker build -t sitejs . docker run -p 80:80 -p 443:443 sitejsSince running
sysctlwithin a Docker container is not allowed I added a flag for theservecommand to skip disabling privileged ports on Linux viasudo sysctl .... I haven’t added documentation of this flag in README.md since I’m not sure how you’d like to handle this.Regarding the Dockerfile itself, I first had in mind building Site.js in the host machine and then add it to the container via
COPY. However, on my first go at it, running Site.js in the container complained about libc versions, so I decided to better build the app in the image. The biggest downside of this method is that the resulting image is a whopping 1.2 GB. Another option could be to have two containers, one that builds the app and produces the executablesiteand then copy it to a second container. I’ve tried it and the resulting image is ~200 MB. The downside is that the whole process isn’t self-contained in a single step.To build Site.js in the container I had to replace your self-hosted patched version of Nexe with version 3.3.7. If I didn’t, running
npm installwould produce anode_modules/nexedirectory which missed a requiredlibdirectory. This didn’t happen outside the container, so it’s really puzzling and if somebody has enough free time to investigate what’s going on I’d love to hear why.A limitation is that within Docker you can’t run the command
enable, again due to Docker’s limitations (nosystemdorsystemctl). However, I think that’s fine and runningservefits with the Docker/container philosophy of one container, one process.By default the resulting container runs
site serve /var/www/html --dockerbut you can pass any command you like, e.g.:What I’ve noticed is that Firefox (or any other browser) won’t trust the certificates coming from the container. I’ve very limited knowledge about HTTPS/SSL so this is something that currently I haven’t got the time to look into. Without any arguments
curlwill fail:But:
@aral Let me know your thoughts. No worries if this stays on hold, but solving the SSL certificates issue would be at least necessary in order to merge IMO.