2mo ago

How to deploy Docker images to Raspberry Pi w/o using a image registry

Hello, fellow Linux users!

My question is in the titel: What is a good approach to deploy docker images on a Raspberry Pi and run them?

To give you more context: The Raspberry Pi runs already an Apache server for letsencrypt and as a reverse proxy, and my home grown server should be deployed in a docker image.

To my understanding, one way to achieve this would be to push all sources over to the Raspberry Pi, build the docker image on the Raspberry Pi, give the docker image a 'latest' tag and use Systemd with Docker or Podman to execute the image.

My questions:

Has anyone here had a similar problem but used a different approach to achieve this?
Has anyone here automated this whole pipeline that in a perfect world, I just push updated sources to the Raspberry Pi, the new docker image gets build and Docker/Podman automatically pick up the new image?
I would also be happy to be pointed at any available resources (websites/books) which explain how to do this.

At the moment I am using Raspbian 12 with a Raspberry Pi Zero 2 W and the whole setup works with home grown servers which are simply deployed as binaries and executed via systemd. My Docker knowledge is mostly from a developer perspective, so I know nearly nothing about deploying Docker on a production machine. (Which means, if there is a super obvious way to do this I might not even be aware this way exists.)

27 comments

Afaik, systemd has nothing to do with docker, except to start the docker daemon.
I think I have done almost exactly what you want to do, I use gitlab CI to build and deploy my application:
https://github.com/cameroncros/discordshim_rs/blob/main/.gitlab-ci.yml
Gitlab is relatively heavy, so I dont know how it will go on a raspi (I run on a Intel nuc). You can run gitlab on a separate machine, and the CI runner on your Pi.
- systemd has nothing to do with docker, except to start the docker daemon.
  I think what OP was describing was writing systemd unit files that would start/stop docker containers.
  
  Compose files would probably make more sense
  
  Exactly, this is what I am doing right now (just for binaries, not execute Docker or Podman).
  
  Yeah, probably, but thats not very common is it? Normally you'd just let the docker daemon handle the start/stop etc?
- Thanks for the idea! I try to keep as little 'moving' parts as possible, so hosting gitlab is something I would want to avoid if possible. The Raspberry Pi is supposed to be sole hardware for the whole deployment of the project.
  
  Its definitely not a lightweight solution. Is the pi dedicated to the application? If so, is it even worth involving docker?
I wouldn't build anything significant on the RPi Zero and instead would try to build elsewhere, namely on a more powerful machine with the same architecture, or cross-build as others suggested.
That being said, what's interesting IMHO with container image building is that you can rely on layers. So... my advice would be to find the existing image supported by your architecture then rely on it to layer on top of it. This way you only build on the RPi what is truly not available elsewhere.
Perhaps a compose file on the raspberry pi. You can have it build the container as part of the compose file, then you can just start your services up with docker-compose up -d --build. The only things you would need to do is update the git repos and rerun the up command. You could also script it to pull the git repos before building.
You can export images to tarballs and import them to your local docker daemon if you want.
Not sure how podman manages local images.
Idea:
Setup inotifywait on your sources directory and rsync to keep directories in sync, and on change, build and run latest image
Setup inotifywait on your image tarball directory/file and on change import and run latest
Mount your source directory to a docker server image that supports hot reloading.
- Wow, thanks a lot! Your answer is exactly what I hoped for when posting on Lemmy: I didn't even know the docker-tarball thingy is a thing, it fits my problem space very nice in combination with cross building and it seems as easy as it can be. Excellent! :-)
  
  In case needed, may want to also look into multi-arch images so it also supports the right ARM build for the Pi: https://www.docker.com/blog/multi-arch-images/
one way to achieve this would be to push all sources over to the Raspberry Pi, build the docker image on the Raspberry Pi, give the docker image a 'latest' tag and use Systemd with Docker or Podman to execute the image.
I do it almost exactly like this, except instead of systemd I just start containers with --restart unless-stopped.
I'm also looking at improving the current setup, but haven't really made any progress. I'm thinking of setting up a GitOps type workflow, e.g. as described here: https://medium.com/linux-shots/gitops-on-docker-using-portainer-8712ba7d38c9 (disclaimer: I haven't tried these instructions myself)
- Thanks for the link!
What is a good approach to deploy docker images on a Raspberry Pi and run them?
See if they have a git repository and just clone then build the image yourself.
So you're building your own images? I'm sure there's a way to build, transfer, and run an image. But you might just set up a local registry. Or just throw them up on a free registry like GitHub.
- My development machine is an AMD64 and the Pi is an Aarch64... I have no clue how complicated cross-building images for a different architecture is?!? (I am thinking about using something like Erlang/Elixir, so I honestly don't know at all.)
  I am not totally opposed to use a registry (free or payed), but, correct me if I am wrong: If I just build the image on the Pi, it is already exactly at the one spot where I need it, so what problem is solved for me by using a registry?
  Edit: Someone above mentioned docker buildx, so seems cross compilation is solved.
You just...build it.
If you're looking for a way to run it like a system service, you could make a systemd unit I suppose, but it's little effort to make a compose config, or a quadlet if you're running podman.
- AFAIK Podman only supports quadlets from version 4.4 and later, I am on version 4.3... so, technically you are right and it would work (for me end of the year or next year, when Raspbian gets an update to Trixie), I am mostly interested how people achieved this and automated this and if there are different/better approaches than the ones outlined by me above.
  
  Compose is stateful, so if you start a container and demonize it, it will start it again on restart of the machine until you stop it (by default), so that's one way. If you want to hook into systems, you can go that route, but it's not going to net you much just trusting one mechanism over another.

27 comments