Skip to content
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

Merged
merged 9 commits into from
Jun 4, 2024
Merged

Conversation

NoRePercussions
Copy link
Contributor

A mostly-functional Docker environment for tracker.

Some things this doesn't include:

  • PDF generation (grover/puppeteer/chromium)
  • Production environment
  • Static asset serving documentation

A mostly-functional Docker environment for tracker.

Some things this doesn't include:

* PDF generation (grover/puppeteer/chromium)
* Production environment
* Static asset serving documentation
Copy link
Member

@DaAwesomeP DaAwesomeP left a 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").

Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Dockerfile Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
config/puma.rb Outdated Show resolved Hide resolved
* 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.
Dockerfile Outdated Show resolved Hide resolved
NoRePercussions and others added 3 commits June 4, 2024 13:16
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>
@NoRePercussions
Copy link
Contributor Author

NoRePercussions commented Jun 4, 2024

The lifecycle of the development containers seems pretty automatable. What do you think about including some make targets for development?

I'd also personally like to include a healthcheck, but I don't want to deviate too far from the rails template.

@DaAwesomeP
Copy link
Member

The lifecycle of the development containers seems pretty automatable. What do you think about including some make targets for development?

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 compose_dev.yaml could build the repo locally and the compose.yaml (for production) would pull from the GitHub container registry.

I'd also personally like to include a healthcheck, but I don't want to deviate too far from the rails template.

When we reach Rails 7 there is this: https://edgeapi.rubyonrails.org/classes/Rails/HealthController.html

@NoRePercussions
Copy link
Contributor Author

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

  • Github actions for build check, run check
  • Set up GHCR
  • Setting up docker-compose dev env and everything that entails
  • as well as continuing to work on salt interface for compose

@DaAwesomeP
Copy link
Member

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 docker exec but it would be better to be self-contained.

@DaAwesomeP DaAwesomeP merged commit a765198 into ABTech:docker Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants