-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jekyll containerisation #17
Conversation
This is a great idea! I didn't get to test it today, but will make some time tomorrow. Stay tuned! |
Adding cache option bundles for dev too. |
docker-compose.yaml
Outdated
container_name: docsy | ||
command: jekyll serve --watch --drafts | ||
image: jekyll/jekyll:latest | ||
volumes: ["./:/srv/jekyll", "./vendor/bundle:/usr/local/bundle"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intuition is that binding ./vendor/bundle to anywhere in /usr would be not a great idea, security wise. Could you clarify why this needs to be bound to /usr/local/bundle
? Or are you simply trying to put it somewhere so it's not found in the root of /srv/jekyll
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are mounting from container to host not host to container.
You can run without mounting bundle. On every restart bundle will be a clean build which is time consuming. This is optional.
We are using the default folder provided by container, we are just mounting them to host to maintain persistency of bundles on every restart.
To test it better remove the second volume and do ‘docker-compose down‘ and ‘docker-compose up‘
Second test add the volume and repeat the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To understand more better read about jekyll/jekyll docker image official README.md
https://github.com/envygeeks/jekyll-docker/blob/master/README.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, understood. And I just pulled the container to see what you meant - the bundle directory already exists in the container and you are saving build time (I wasn't familiar with jekyll/jekyll).
$ docker run -it --rm --entrypoint bash jekyll/jekyll:latest
bash-5.0# ls /usr/local/
bin bundle etc include lib share
And I agree it would save time to mount and then store those files.
and we are still needing to debug an issue with bringing up the latest jekyll container (4.0.0) that seems to have a permissions error to write to /usr/gem/cache that does not exist in the container Signed-off-by: vsoch <vsochat@stanford.edu>
@JinnaBalu I've updated the PR with some tweaks to the documentation, and opening up the docker-compose.yml lists so it's easier to read. But I'm hitting this issue when trying to bring up the containers:
Did you not do any customization to create the directory, or bind something to do the same? Note that I just pulled jekyll/jekyll so my latest is tag 4.0.0, are you using a different (possibly earlier) version? |
@vsoch We are doing nothing from our end we are making use of the Jekyll Docker image, so we have to just use the volumes they suggest to use. They provide the path in the container where the bundles are store. If you are facing issue with the version, we should use jekyll/jekyll:3.8, we need to upgrade the app according to the version used in Dockerfile Ruby Version |
Ok thanks for letting me know, I’ll debug this more fully tomorrow. Don’t worry, we’ll get it working. |
Signed-off-by: vsoch <vsochat@stanford.edu>
Downgrading did the trick (and I've updated the docker-compose recipe!) I also found some evidence for the error! I think it's very recent, see this post (specifically the bottom comment that was just 4 hours ago!) fastai/fastpages#267 (comment). |
Thank you for this contribution! Containerization of software is always a very good idea, and I don't know why I didn't think of doing it here! |
No description provided.