-
Notifications
You must be signed in to change notification settings - Fork 162
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
Build Docker images in GitHub Actions #546
Conversation
a0a3238
to
2e3bbe7
Compare
1e26129
to
084802e
Compare
Co-authored-by: Matthias Brandt <mattelacchiato@googlemail.com>
084802e
to
9759473
Compare
Thanks, @tobiasmcnulty! Have you actually tried using the images with your intended configurations and orchestration strategies? Here's a little bit of context on how things ended up the way that they are. One big goal with Central has been to make it fast and simple enough so that it's possible to run its full stack off a single, inexpensive host. We also try hard to make upgrades, even including important changes like postgres version updates, both transparent to users and approachable to folks who don't have a lot of devops experience (e.g. we've shied away from a management script which can really obfuscate what's going on). Finally, we do want to make it relatively easy for folks to customize. These priorities have left us with a little bit of an unusual setup: we consider the images produced more of an implementation detail, particularly because some configuration does require a rebuild. I understand people want to do things like scale horizontally and orchestrate containers in ways other than the default. I also understand that the build steps can be time consuming even with the default setup. All that aside, here are some thoughts on what you have:
|
Hi, @lognaturel ! We are running these images on our instance of ODK Central; I just pushed our changes if helpful for context (ignore the pgbouncer stuff at the top). We're still using
That's fair, and if you decide that these images stray too far from the course I understand. While my own needs are slightly different, I could see someone making the argument that pulling the pre-built images might lower the barrier to entry even further; as you say, the build steps can be a time consuming part of the default setup. My concern with updating the
Correct. I didn't dig into the details here, but from what I could tell in the compose setup, different images are built depending on the
My gut says it's better to provide these images too, so long as they are used by
It seems totally fair to require rebuilds for custom widgets or themes. Regarding the "configuration changes seem to require rebuilds" question, I suspect that having a single image that is the source of truth would make this issue go away, for installs that use the pre-built images at least. |
+1 it would be very helpful to have pre-built images 👍 @lognaturel would it be useful to have the images multi-architecture, so they work on default AMD64, ARM64 (latest Mac), and others? I assume it's not essential, as Mac devs can build their own images, and ARM64 deployments are rare currently. It's relatively trivial to add onto the proposed Github workflow, but note it would significantly increase the build time (using QEMU), so best left for release images only. Github also recently released ARM64 runners, but I doubt the cost/benefit would be worth it. |
What are your thoughts about the secrets and Enketo images as I asked above?
We generally try not to add things that could be useful without knowing we have a committed user, even when it’s small. Like you say, it seems like something that could be added once someone asks for it. |
Agree the pre-built images don't necessarily need ARM64 unless asked. As for bundling the
|
Co-authored-by: Tobias McNulty <tobiasmcnulty@users.noreply.github.com>
Co-authored-by: Tobias McNulty <tobiasmcnulty@users.noreply.github.com>
As an update, we are now running these images both in a docker-compose install (removing If maintaining the images is not in scope for this repo, it might be nice to merge at least the environment variable changes, so others could benefit from the ability to override these variables and to reduce the burden of maintaining a fork with the built images. I'm happy to update this PR to remove the Github Actions workflow if needed (though of course, I'd still love to see the images on the official repo, too!). |
I am also maintaining a pre-built ODK Central image that would be great to replaced with the official build here. Looking forward to furthering the discussion around this 😄 An alternative to this would be building the images directly from this repo, using a URL context, like this: odkcentral:
build:
context: https://github.com/getodk/central.git#v2024.1.0
dockerfile: service.dockerfile It would save having to maintain an upstream dockerfile for building Central.
This PR renders the issue moot though - pre-built images are even better. |
Thanks for the follow-up! It’s on my list for this upcoming release to get this finalized. One step we’ve taken is that we’ve moved the front end configuration so it gets requested at run time instead of needing to be baked in so we won’t need multiple front end images. |
I appreciate all the great ideas and discussion here! Let's consider #675 separately. I know it's important for folks who want to do their own orchestration. I've tried to capture the subtleties that I see on that issue and we can continue discussing there. I'll get the nginx and service images working at #676. I think the last major question that needs to be answered is how to handle custom ssl certs. |
Closes #165
What has been done to verify that this works as intended?
Why is this the best possible solution? Were any other approaches considered?
This PR is an adaptation / scale back from #249. It merely adds images that can be pulled as needed, without changing how the deployment occurs. If there is motivation and a clear path forward, the
docker-compose.yml
file could be updated (or a correspondingdocker-compose.nobuild.yml
added) to support using these images from docker-compose.These images in the meantime will prove useful to non-compose deployment mechanisms, so they don't have to build, push, and host their own images.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
There should be no regression risks since this merely adds the Docker images to GitHub.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
This does not currently require documentation changes, but if there is interest in integrating these images into existing deployment mechanisms, it could be updated for example when the
docker-compose.yml
file is changed.Before submitting this PR, please make sure you have: