-
Notifications
You must be signed in to change notification settings - Fork 29
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
Minimum Working Dockerfile #549
Conversation
A mostly-functional Docker environment for tracker. Some things this doesn't include: * PDF generation (grover/puppeteer/chromium) * Production environment * Static asset serving documentation
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.
This is great! Just a few notes.
I really prefer to stick to the Rails templates for the configs unless there is a strong reason to waiver. After updating Tracker through the entire chain from 5.0 to 6.1 (took at least a month), I don't wish on anyone to have to go through so so many changes that don't actually affect runtime and just things hard to understand (i.e. "was this a workaround" or "someone just made it different").
* Bind 0.0.0.0 only in container * Use port 3000 in container instead of 80 * Use default rails configuration
Keep it for rvm, but don't check that the ruby version is correct, so it isn't needed in the Docker image.
Puppeteer cannot provide its own headless chromium on amd64, and has compatability and versioning issues with installed chromium. Additionally, chromium has unwanted graphical packages. Therefore, we just lock everything to amd64.
Developers will need to create, run commands in, and stop containers constantly. Since only one development instance of tracker should run at a time due to port binding anyways, we recommend developers name their containers for convenient operations on them.
Co-authored-by: Perry Naseck <4472083+DaAwesomeP@users.noreply.github.com>
The lifecycle of the development containers seems pretty automatable. What do you think about including some I'd also personally like to include a healthcheck, but I don't want to deviate too far from the rails template. |
We could, but ideally in the end I think it would condense down to: docker compose up --file compose_dev.yaml
docker exec -it tracker rails c # for initial member account That way you don't even have to setup SQL. The
When we reach Rails 7 there is this: https://edgeapi.rubyonrails.org/classes/Rails/HealthController.html |
Great. I think I've addressed all comments, so what remains is whatever remaining comments you have. It seems like after this PR, next steps in dockerizing may be
|
Great! I have a standard GitHub action for dealing with GHCR I can push later tonight. I think we should try to tackle #544 as a part of this. The current email process and Sphinx process are trivial to run in Docker Compose with the same container, but the Slack notification runs on a Systemd timer. That Systemd service can just become a |
A mostly-functional Docker environment for tracker.
Some things this doesn't include: