Why not host your own git repo (e.g. gitea) so you can do 2 or 4 without opening services outside?
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!
I'd be a bit concerned with having the git repo also be hosted on the machine itself. If the drives break it's all gone. I could of course have two remotes but then pushing changes still becomes a multi step procedure.
Backup mate. Either local or something over the network. When comes to data loss, it will come find you eventually.
I do have nightly off-site backups, that's true. Still, having the git repo be on the same machine doesn't seem right to me.
You can set up multiple remotes for a repo and push to a local git server and github at the same time
I world strongly suggest a second device like an RPI with Gitea. There what I have.
I use portainer to pull straight from git and deploy
I'd be a bit concerned with having the git repo also be hosted on the machine itself.
Please tell me you have a tested backup solution/procedure in place.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters | More Letters |
---|---|
Git | Popular version control system, primarily for code |
IP | Internet Protocol |
SSH | Secure Shell for remote terminal access |
[Thread #827 for this sub, first seen 23rd Jun 2024, 10:55] [FAQ] [Full list] [Contact] [Source code]
GH action is all what you need. If you really worried open ssh over the internet, use Tailscale or Cloudflare Tunnel. Or use a firewall rule to block off traffic except from GH IP ranges. TBH, I have VPSes that have SSH open to the whole world. Yes, it got many hits everyday but they doesn't do anything beyond that.
Addition. Use a Makefile to push and deploy in one make
command.
Have a look at GitLab.
I'm doing the same thing you are doing, but automatically. I have a repo per app and a few GitLab runners connected on my Raspis/servers. Everytime I push a change, the shell runner runs the commands configured for the pipeline. I don't have to lift a finger after changes.
For no 1, that shouldn’t be dind, the container would be controlling the host docker, wouldn’t it?
If so, keep in mind that this is the same as giving root SSH access to the host machine.
As far as security goes, anything that allows GitHub to cause your server to download (pull) and use a set of arbitrary of Docker images with arbitrary configuration is remote code execution. It doesn’t really matter what you to secure access to the machine, if someone compromises your GitHub account.
I would probably set up SSH with a key dedicated to GitHub, specifically for deploying. If SSH is configured to only allow keys for access, it’s not much of a security risk to open it up to the internet. I would then configure that key to only be able to run a single command, which I would make a very simple bash script which runs git fetch
, and then git verify-commit origin/main
(or whatever branch you deploy), befor checking out the latest commit on that branch.
You can sign commits fairly easily using SSH keys now, which combined with the above allows you to store your data on GitHub without having to trust them to have RCE on your host.
Just brain storming here:
You could expose a bare git repo on the server with a git hook that runs Docker compose up on push.
You could also have GitHub actions ssh in and run git pull && docker compose up on push to main.
I prefer having a convenient pull mechanism that I can trigger from a workstation in the lab network. I maintain the setup with Ansible
I use Ansible to meet this need. Whenever I want to deploy to one or more remote hosts, I run Ansible locally and it connects via SSH to the remote host(s). There, it can run Docker Compose, configure services, lay down files on the host, restart things, etc.
You could perhaps use the Portainer tool to manage your deployments...
That would fill the same role as watchtower I guess? I've previously tried to have a look at having portainer manage the docker compose stack that it's running inside but at least back then it seemed to be a dead end and not really what portainer is meant to do. I'm not interested in moving away from docker compose at this time.
Dockge would be more appropriate for that.
Watchtower has different functionality, mainly keeping them up to date with images.
You want Jenkins, GH Actions, or even ansible.
Why save things on github? I used to save my configs directly in the server running docker. To change anything I had to ssh into it and do the stuff.
Why save things on github? I used to save my configs directly in the server running docker. To change anything I had to ssh into it and do the stuff.