Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upDocker Branch, can co-exist with current Vagrant workflow #1012
Conversation
This comment has been minimized.
This comment has been minimized.
|
This might explain why tomcat7 is reporting failure on service start, even though it appears to be running: to investigate. |
| @@ -0,0 +1,7 @@ | |||
| .vagrant | |||
| .git/objects/* | |||
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
hornc
Jul 19, 2018
Author
Collaborator
This was done to enable the git sub-modules fetching of 3rd party stuff, including js, but to reduce the size of the context send to docker. I'll have to check all of this in light of your 404ing js below, because those items should have been fetched, so it sounds like there is a problem somewhere else.
This comment has been minimized.
This comment has been minimized.
hornc
Aug 14, 2018
Author
Collaborator
@cdrini I rechecked this by setting it to .git and the make command fails on
Line 32 in 495c389
git all, so for now .git/objects/* excludes as much of the git cruft from the Docker build context as I could manage. There may be a way to remove this, but it will involve digging into the git task in the Makefile
| errors | ||
| infogami | ||
| config | ||
| build |
This comment has been minimized.
This comment has been minimized.
cdrini
Jul 19, 2018
Collaborator
errors, infogami, and build don't appear on my system; what are these files relative to?
This comment has been minimized.
This comment has been minimized.
hornc
Jul 19, 2018
Author
Collaborator
They all appear in the root dir (at least on my dev machine :) ), I think they are all artefacts from the vagrant provisioning -- I'm guessing you started with a clean checkout? config is a symlink that is created to conf, which is odd... I thought that was done by bootstrap.sh, but now I can't find where the symlink was created.
I wanted to at least for now exclude stuff created by Vagrant provisioning from getting copied over to the image before we remove it completely. I think I need to confirm that Vagrant is still creating all of these. errors is only written to to log errors from the vagrant vm . It'll be a bit of extra work to support Vagrant in parallel, and should all be removed once Vagrant is completely gone.
| # required for postgres | ||
| ENV LC_ALL POSIX | ||
|
|
||
| RUN apt-get -qq update |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| @@ -0,0 +1,36 @@ | |||
| #!/bin/bash | |||
This comment has been minimized.
This comment has been minimized.
cdrini
Jul 19, 2018
Collaborator
Can we put this file docker/? It feels a little more organized, cause the scripts/ directory already has way too much stuff in it :P
This comment has been minimized.
This comment has been minimized.
| ENV LANG en_US.UTF-8 | ||
|
|
||
| # required for postgres | ||
| ENV LC_ALL POSIX |
This comment has been minimized.
This comment has been minimized.
cdrini
Jul 19, 2018
Collaborator
It seems like ENV variables are inherited ( moby/moby#33242 ), so these 2 can probably be removed from oldev.
| # Using vim to change and test things, may want to remove? | ||
| RUN apt-get install -y vim | ||
|
|
||
| #COPY . /openlibrary # already copied from olbase |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
hornc
Jul 19, 2018
Author
Collaborator
A lot of these dupes over the two Docker files is because I was rebuilding ol-dev frequently and wanted local file changes copied into the image. I guess this won't be such an issue if the containers are generated at the same time, and we volume mount local files anyway.
Now is the time to DRY them up :)
| FROM olbase | ||
|
|
||
| # Expose Open Library, Infogami, and SOLR | ||
| EXPOSE 80 7000 8983 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
hornc
Aug 14, 2018
Author
Collaborator
I wanted to keep it there to document which ports that particular container expected, so each container could technically stand alone.
This comment has been minimized.
This comment has been minimized.
|
After running
Then
I could then access openlibrary locally running docker \o/ Although I got 404s for some static files, and the UI looked a little weird.
Otherwise:
So overall woot! It's a bit slow to launch now because it has to setup the postgres stuff each time, but I think we can figure that out later. |
This comment has been minimized.
This comment has been minimized.
|
@cdrini I thought I'd fixed the js issues and UI weirdness, I'll take another look tomorrow and see if I can figure out what has been missed. If you have any thoughts on how to speed up the postgres start, that'd be super helpful too! Based on something you said, I was putting that down to a Xenial issue, rather than containers, but I haven't been able to find any obvious cause. |
This comment has been minimized.
This comment has been minimized.
|
@cdrini, I've made changes per your comments. I tried running everything from a clean checkout and could not reproduce the js 404s. I did rebase, so if it was an unrelated code change that has since been fixed, it may be resolved? Could you get this updated branch and see if you are still getting those errors? I found that the local OL can get confused with exisiting cookies which can break the nav bar and logged in info. Using an incognito window is a quick way to check if that's the problem with UI display. Any other comments? |
This comment has been minimized.
This comment has been minimized.
|
I got it running, but I'm still having the same issue with static files :/ Interestingly enough, I can access file in |
This comment has been minimized.
This comment has been minimized.
|
OHHHH, I think it's the symlinks. JQuery/Slick (the files that aren't loading for me) are symlinks. That might be related. |
|
Ok, it looks like that static issues are because of symlinks on Windows. I think it's related to this: docker/for-win#109 . In the interest of progress, let's move forward though. I'll create an issue for further investigating this. Final todos:
|
This comment has been minimized.
This comment has been minimized.
|
Great catch about symbolic links for static files and also I'm shutting down the database gracefully |
This comment has been minimized.
This comment has been minimized.
|
Awesome! I'll run it on my machine to triple-check everything is ok, and then it should be g2g! |
|
Works like a charm! The postgres changes seem to have done the trick! |


hornc commentedJun 29, 2018
•
edited
I believe this is ready for merging. Ideally all the services will NOT be in the one container, but this is a starting point to begin with something that runs as well as the Vagrant dev env as a working baseline.
TODO
split out services into separate imagesNot in this PRremove all vagrant / upstart / bootstrap.sh codeNot yet, we will try to make Vagrant and Docker work in parallel before making a full switchCurrent Issues
What is going on with nginx service not being required? I thought it was critical in vagrant, doesn't appear to be necessary here?
Investigate why tomcat7 service reports error on start, but appears to function perfectly
sporadic test failure from openlibrary/catalog/add_book/test_add_book.py , test_duplicate_ia_book (looks like a problem with the test in general, not containers)
Perhaps we should move the initial solr indexing into the image as it triggers every time the container is run and increases startup time.
RESOLVED
postrgres start up seems very slow, site 500s and reports other errors if db not yet up, see #1050 , was because postgres was not shut down cleanly when creating the image.
js errors, Search dropdown not populated. most of vendor/js not populated (except wmd, which occurs via git submodule update)