view the rest of the comments
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Wouldn't you need to rebuild your image any time the upstream image changes?
Yes - same as with the original script, upgrades would require more manual steps than just updating the version in the Compose file. This is how it's typically done.
There are ways to automate this. Docker Hub used to have a feature for automatic rebuilds when base images had changed, but AFAIK this feature was removed some years ago. Now it's a matter of setting up a CI with periodically (nightly or weekly) scheduled pipelines, but it's not a trivial matter.
Semi-automation can be achieved by using build-time arguments. I'm at my computer now, so here's a revised process:
First, a bunch of manual commands that would allow us to write a patch. I'll use those crude
sed
statements - just because they work today, but YMMV.This will produce a nice patch like this that you can copy. Create an empty directory and save as
change-limits.patch
in there:Now, put the Dockerfile next to the patch:
And a shell script to semi-automate the upgrades. Note it requires
curl
andjq
to be available to parse JSON.And finally, create a file called
.dockerignore
that contains only one line that would saybuild.sh
. That's just minor cosmetic touch saying that ourbuild.sh
is not meant to be a part of the build context. If everything is correct, there should be now 4 files in the directory:.dockerignore
,build.sh
,change-limits.patch
andDockerfile
.Now when you run
build.sh
it will automatically find the latest version and build you a custom image tagged as e.g.my-mastodon:v4.1.3
, which you can use in your Compose file. For a distributed system like Docker Swarm, Nomad or Kubernetes you'll want to tweak this script a little to use some registry (your-registry.example.org/your/mastodon:v4.1.3
) and possibly even apply changes further (e.g.docker service update --image ...
).Mutable tags like
latest
can become confusing or even problematic (e.g. if you'll want to downgrade it's best to have previous version image readily available for some time - even if the build process is reproducible), so I would really recommend to use explicit version number tags.Hope this helps.