Use pre-built images for nginx & service containers

[alxndrsn]

TODO

• review tag script - is it necessary?
• consider how commits for upgrading submodules are currently handled - tagging could likely be identical

---

Related to #677

What's changed?

• docker-compose.yml now references service and nginx containers by specific version number
• add a script for tagging releases and making appropriate updates to docker-compose.yml. If preferred, this could be converted to documentation

---

What has been done to verify that this works as intended?

• CI
• a lot of manual testing in a forked repo (https://github.com/alxndrsn/odk-central/actions)
• ran docker compose build locally, and watched the results:

Why is this the best possible solution? Were any other approaches considered?

TODO

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?

• should reduce the system requirements for performing upgrades
• might contain surprises for deployers who have made local changes to any of client, server, nginx etc.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

• internal release documentation
• public upgrade documentation

Before submitting this PR, please make sure you have:

• branched off and targeted the next branch OR only changed documentation/infrastructure (master is stable and used in production)
• verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced

[lognaturel]

Latest thinking doc. @alxndrsn will revise this PR in light of those thoughts and describe how each end-user goal is met by the proposed approach.

[alxndrsn]

But wouldn't we need to run the script on next before merging next into master? Otherwise, there would be a commit on the master branch that includes changes to the central repo without corresponding changes to central-backend and central-frontend.

I think this is correct. To tackle this I have:

1. renamed release.sh to tag-release.sh, and
2. changed the branch check from only runs on master to cannot run on master

[alxndrsn]

I think we'll want to add some documentation on how to make code edits to frontend and backend since that will now require changes to the docker compose file as well. It's not something we highly recommend but it was easy in the past and we know some people do it.

Is there any risk of breaking these peoples' existing deployments? Would it be better for existing commands to continue building locally, and add new recommended commands which use pre-built images?

[lognaturel]

Is there any risk of breaking these peoples' existing deployments?

It would definitely be annoying for them. But if they're modifying source we know they have technical capacity and as long as we document a process I think it's ok.

Would it be better for existing commands to continue building locally, and add new recommended commands which use pre-built images?

Can you elaborate a bit on what that would look like? When you say commands, do you mean docker compose up, etc?

[alxndrsn]

When you say commands, do you mean docker compose up, etc?

Yes, so in this scenario the existing docker compose up etc. would still work for deployments building locally, and then documentation would change for new deployments to use pre-built images, perhaps with dedicated scripts e.g. ./restart-services.sh.

I don't think this necessarily simplifies things though, so I'm relieved you said this:

as long as we document a process I think it's ok.

[matthew-white]

@alxndrsn, just wanted to check whether there are any outstanding questions here. Are you blocked by anything? Once we get v2025.1 out the door, I'd be happy to meet/pair on this PR. I'm familiar with our release process(es) and how the different repos work, so I think I can add any context that's missing.