Comment by KronisLV | Hacker News Reader

Comment by KronisLV | Hacker News Reader

I recently moved over from self-hosting GitLab to instead having Gitea, Nexus and Drone, because the burden of keeping GitLab up to date was cumbersome, given how it's such a large and complicated software package.

I wrote about it in my blog post "Goodbye GitLab; Hello Gitea, Nexus and Drone": https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-...

That said, I still find the UI of GitHub and GitLab to be a bit better than Gitea's (the whole organizations/groups navigation feels better), though Gitea is immeasurably more performant when compared to GitLab, especially when the available hardware resources are limited - in the case of 4 GB of RAM being all that I could afford, it's the difference between a really snappy and annoyingly laggy UI.

Admittedly, now it's Nexus that loves eating my resources, though for the most part having software like it for managing most of my container images and other packages is pretty cool and worthwhile, though one might also want to explore the alternatives, such as Artifactory or something else.

Also, personally I find Drone to be a bit less capable than GitLab CI and its documentation isn't quite as good in comparison - though that's a given, since it's an external tool developed by another company. Though I guess even Jenkins would also be a viable alternative (despite it having certain issues with plugin stability etc.), or many other CI tools, given that Gitea is actually decently supported!

In summary, even if there still are a few challenges here and there, the whole setup is a lovely way to self-host your own projects and everything around them in a cost effective manner and whilst also staying in control over your own data. Gitea is an important part of this and overall I'm really glad that we have cool software like it nowadays!

At the same time, I'm more than happy to use GitLab or something like it at work, as long as keeping it working nicely, up to date (and paying for the servers) is someone else's responsibility.

You'll probably be happy to see the 1.17 dev version of gitea (which should be the next major release) actually has an artifact repository built in and it can even host docker images: https://docs.gitea.io/en-us/packages/overview/ You have to build the branch yourself right now though, despite being in the docs it's not in the release downloads yet. You might be able to get rid of nexus and just use this built in registry.

That's actually pretty cool to hear!

Though a problem that I ran into with GitLab Registry was that sometimes the Docker image cleanup wasn't done properly and old layers kept lingering around and eating a lot of space. I sort of fixed it with some cleanup scripts and the occasional manual actions, but it still was a bit problematic since running out of space was a very real risk.

Nexus does appear to have similar issues, should you use it as an intermediary for CI image builds (e.g. tag it with branch-date and tell your cluster to redeploy the image), but at least it has instructions for cleaning it up that work most of the time: https://help.sonatype.com/repomanager3/nexus-repository-admi...

Personally, I think that using the same software package for storing build artifacts and the source code itself is a bit risky, but maybe Gitea will be able to tackle those challenges with no significant issues!

It probably depends on the scale of your builds, but I’d agree that it seems like a generally better idea to separate your docker image repositories from your source control.

I just discovered that the latest gitea supports package repositories. I'd like to see something that works for R packages without too much hassle.

By Drone do you mean the `0.8` open source version? If you've not tried Woodpecker it built upon the `0.8` code and added lots of nice functionality, has better documentation, and is in active development.

https://woodpecker-ci.org/

I mean the currently available 2.X set of versions: https://docs.drone.io/server/provider/gitea/

Its source code is also available on GitHub: https://github.com/harness/drone/releases

Of course, the point about their license is a good one, which definitely has some limitations on what you can do with it: https://github.com/harness/drone/blob/master/LICENSE (I wish I earnt 5 million $ and this would be a problem I'd have to think about).

Thanks for bringing up Woodpecker, though, it also seems like a nice project and the two CI solutions haven't diverged far enough for migrating over from one to another to be too problematic, should that become relevant in the future: https://github.com/woodpecker-ci/woodpecker

Of course, as I said, some folks might also prefer something like Jenkins or another CI solution. I'm yet to explore most of the packages out there!

I wanted to self-host a git server, and because I use gitlab at work, that was my first choice. But the system requirements for gitlab were too heavy for the linode I was running, so I went with gitea. Linode also had a handy install-script to set everything up painlessly.

I concur with your overall assessment.

Mind if I ask how you're hosting this setup, are you using something like k8s or swarm? If so how are you handling persistence, just normal volumes? I imagine if you were to lose data, that'd be pretty bad.

Currently using Docker Swarm with bind mounts instead of volumes, because they're a bit easier to work with, backup-wise.

Infrastructure wise, there are a few VPSes from a local provider (https://www.time4vps.com/?affid=5294 affiliate link), though I've also used DigitalOcean, Hetzner, Scaleway and others in the past, AWS, GCP and Azure would work as well, though would be much more expensive. For executing CI tasks and backing up the data, i have a few servers on my desk (though regular towers with passive cooling, instead of the rack mounted kind), since those are more cost effective, especially storage wise.

The actual files are backed up with BackupPC over the network automatically, at a set interval, to another server: https://backuppc.github.io/backuppc/ Then, of course, the backup server data is occasionally sent to another server in my local network, just to spread it around more, in case of disk failures or one of the servers shorting out.

Admittedly, it's a lot like using regular rsync with cron, although the benefits of BackupPC are being able to really easily restore files, as well as having incremental backups with compression.

It is a bit rudimentary as far as handling data goes, but sometimes that's all that you need: https://blog.kronis.dev/tutorials/simple-ways-to-do-backups

Alternatively, one might also achieve the same result with something like Bacula, Kubernetes with either hostPath or maybe even just a NFS mount. Other folks might prefer something like GlusterFS or a similar distributed storage solution, or something like Longhorn for Kubernetes in particular.

Comparison of free clouds https://paul.totterman.name/posts/free-clouds/

Thanks for this, it's interesting to see how others are hosting these kinds of setups. Been wanting to move to it for a while but kube (which I know best) is quite large and the idea of ensuring really solid data backups often has me on edge a bit when not using something like AWS (I have a small server at home I'd use).

Appreciate the detail around BackupPC as well!

> Been wanting to move to it for a while but kube (which I know best) is quite large and the idea of ensuring really solid data backups often has me on edge a bit when not using something like AWS (I have a small server at home I'd use).

One option would be opting for a more lightweight Kubernetes distro, such as K3s https://k3s.io/ or k0s https://k0sproject.io/ both of which have comparatively smaller resource requirements whilst still being certified and compliant.

Personally, I'd also use something like Portainer, Rancher or Lens, but that's just because I like UIs alongside my CLIs that are nice to look at.

Maintaining Jenkins and its gazillions of plugins is such a hassle I'd never consider it for a new project.

Reply on news.ycombinator.com