At the moment the docker self-hosted install uses 2 different upgrade procedures, if I understand correctly:
sometimes you can click the upgrade button the UI, just like the old source-code update procedure, and it will, I think, modify the running docker image.
sometimes you have to follow a manual process to git stash changes to the compose file, manually download the enterprise image etc.
IMO this should be 1 procedure:
Docker containers are supposed to be immutable. Procedure 1 from above shouldn’t be valid in the docker world.
All updates should be via docker compose
the docker compose file should be more parameterised, so fewer people have to edit it. For instance I had to edit mine to allow the service to be directly accessible on port 443
the .env file should be .gitignore’d. The git repo should instead have a env-example file which the user should copy into place at first install
There should be an authenticated docker registry for enterprise customers which we can access directly, rather than having to manually download the image in an interactive web browser then copy to the target server
There are examples of this elsewhere: mailcow-dockerised does this (but without the enterprise registry), using an update.sh script. Home Assistant ships a single .deb called the supervisor which runs on the local machine outside docker to orchestrate.
Apologies if I’ve miss-represented the above procedure “1”.
Are there any plans to improve this?, the current situation is, IMO, a mess.
Your understanding of the two procedures is accurate, and I kind of agree with you. Improving the update procedure is on our radar and something we plan to do.
That said, there are a few things worth considering:
The UI-based update is genuinely user-friendly, and it’s worked this way for a very long time. A lot of our users rely on that simplicity, so we’d want to be careful not to lose it in the name of doing things “the Docker way.” I’m also not sure that having to talk to your sysadmin every time you want to upgrade is something most users would want.
It’s also worth noting that we don’t actually need to update anything at the Docker layer very often. The reason it’s coming up right now is that we’re introducing automation features that require infrastructure changes, it’s a specific case driven by new functionality.
Your points about parameterising the compose file, .gitignore’ing the .env (with an env-example to copy from), and an authenticated registry for enterprise customers are all reasonable, and they’re the kind of thing we’d want to factor in when we revisit this.
Short version: agreed in principle, it’s in our plans, but there are some trade-offs (especially around keeping updates approachable for less technical users) that we need to weigh before changing anything.
One example from my side: Discourse, where we’re writing right now, you can do updates from the UI, and from time to time major updates are done via CLI. So there are examples on both sides.
I won’t add much value here, as @sam has already answered, but I’ll share my opinion.
Updating from the UI will always be the preferred option. The majority of eramba users are not technical IT users or sysadmins, or simply do not want to perform Docker updates manually. Because of that, the UI update option will definitely not be removed.
Regarding the port, I do not fully agree. In some scenarios, the server where eramba is installed may already have other web servers running, or routing may be handled through a reverse proxy.
So I do not think it should strictly default to port 443, because this is environment-dependent and it is expected that users may need to modify it accordingly.
Regarding Docker registry authentication, I completely agree that this should be an option.
The .env.example can also be done. I would also say that it is indeed a better practice.
WRT the port configuration; my point was that it should be a .env variable, and the .env shouldn’t be in git, so I wouldn’t have to muck about with git stash to do the next update. As it happens I will have to muck about with git stash because the ssl default certs are also in git, and you haven’t parameterised the location of those either. In summary, I think if the procedure involves getting the user to stash their changes, then something is wrong somewhere else.
I’m a little surprised that the self-hosted users of this software would be so averse to involving their IT team. This is after-all IT GRC software, and in companies where IT GRC is actually a thing I would expect to have formalised roles and procedures regarding keeping software up-to-date, change management procedures etc. I suppose I’m only a little surprised though.
As a further question on this topic; what do you about regular in-container updates?
ie, as far as I can tell your docker image is layered on the standard Debian container image. When debian release security updates to that image, do you also mutate the running image via the usual Eramba update process to apply those updates? ie does the the Eramba update procedure run apt update && apt upgrade -y or similar?