Hacker News Reader

Comment by 5e92cb50239222b | Hacker News Reader

This has been happening pretty much every day for a long time. Maybe this will push more people towards some decentralization. A self-hosted Gitea instance my organization has been using had exactly zero downtime in the past year. None. Same with our CI system. Yes, I know, GitHub is 10⁹⁹⁹ times larger than our puny Gitea instance, and that's why they're having issues, but why should I care when one is working, and the other one isn't?

View on HN

>> A self-hosted Gitea instance my organization has been using had exactly zero downtime in the past year. None. Same with our CI system.

And when they do go down, how long will they be unavailable? When this happens (and it will happen) please post here so we can say "why are you running infrastructure yourself?"

Very likely to be lower than GitHub/etc, because it's a much simpler system that can be reinstalled from scratch in 30 minutes by an experienced admin on brand new hardware if needed.

Less than you've already wasted waiting for GitHub to come up from the dead in the last year alone. If you're insinuating that we'll have to restore everything from scratch, don't worry, the machine is being continuously replicated and sysadmins are trained to restore everything chop-chop.

I ran a GitLab instance for a company pretty much solo and it never wound up going down outside of when I was upgrading it, that I can recall. The thing about that is, it’s a small scale instance. If an upgrade or change failed, I could literally delete everything and restore from backup in under an hour, and never really needed to do that (although to be clear, I did actually test that it was possible.)

Now I’ll tell you the real problem with it: it worked great for people who were located in the U.S., but it was terrible for certain remote employees due to increased latency, and the fix for that would be to set up a complicated replication setup that puts data closer to people not near the main instance.

There’s obviously other issues, but that is one that is probably commonly overlooked that most SaaS solutions can do better on.

What gitlab features do you utilize where latency actually is a problem?

I currently manage an internal gitlab instance with some remote coworkers, but I haven't heard any complaints about latency. Although tbf, I feel like we've barely scratched the surface of what gitlab supports

The most impacted user had ~500ms latency to the server, which is enough that even pageloads are bound to feel slow (especially because Gitlab itself is not necessarily the fastest thing in the world sometimes.) And if I am remembering correctly, I think that was basically it: the UI pageloads just had enough chained round trips that they were way too slow. In retrospect, there may have been some ways to work around this that we didn’t end up exploring.

When I moved to a new company, the GitLab instance was still up, and last I was aware, many years down the road, it is still in use. Feature-wise, we were very much satisfied, and the GitLab CI model with Docker executors worked very well for us.

If you have high latency to a GitLab server consider setting up a GitLab Geo server locally https://docs.gitlab.com/ee/administration/geo/ to improve things (this is a paid feature).

Looks like you got downvoted for some reason, but yes, this is exactly what I am referring to. (We did pay for GitLab EE, so I think we had access to Geo.)

With something as simple as serving git for your own organisation, when you do get downtime it's going to be a case of restoring from backup and changing DNS. No need for complicated infrastructure, so bringing it back really is that simple.

Worst case is losing commits between going down and backups, but even then it'll be minimal if you set your backup to simply push to a another origin.

I pay for someone else to worry about most services, but git doesn't have to be one of them.

The worst case is discovering the hard way that your backup system isn't working and you haven't been diligent about spending the time to periodically test restores.

That's why testing of backups should be at least partially automated. Though you will always find a point where the automation, and automated tests to make sure that is working, and so on, get to the point where making a human responsible for sanity checking is most resource effective.

Pushing to multiple origins is not a hard thing.

The risk is less about losing commits, since those tend to live on every devs machines too. It's about losing all of the other data like the issue tracker, comments, etc.

If you think "serving git" is the only role github is serving for organizations you are probably not the target audience.

I don't. Which is why I was explicit in the problem I'm targeting.

Depends on your setup. For a simple git server on AWS I might have it on a single-node ASG so that when something terminates the instance, the ASG notices and launches a new one. The initialization scripts would then attach and mount a pre-existing EBS volume and start services.

Very simple to set up, and as long as your data volume is not lost (which can happen, but is very rare), such a system would recover from a host failure by itself faster than most people could react to it going down. In the unlikely case that you lose the EBS volume, you'd just recover from snapshots manually.

5 years of a Gogs instance. Zero downtime. I'll come back to you when it goes down.

does gogs plan to support any kind of CI integration like gh actions?

No it doesn't. I fully confess the feature set is extremely minimal. But the point here is that running your own infrastructure can make a lot of sense if you know what your precise requirements are (or are not).

Gogs and gitea are designed to be a single-binary minimal source code hosting service. Additional services like CI within that binary is likely to bloat it up and make it less reliable. However, it's easy to integrate a CI service to it - like Woodpecker CI [1]. Woodpecker also has a minimalist approach like gogs. If you instead prefer a full package, then gitlab is the best solution.

[1] https://woodpecker-ci.org/docs/administration/vcs/gogs

I once worked at a place that self hosted a lot and they had fail-over, backups and restores dialed in

If something like Git went down — which it never — it was a few clicks away from coming back

Working with competent people is a blast

You also need an organization that will spend the money to make that happen. Many of us would like to have such systems where we work, and are capable enough to implement them, but the Finance people say 'NO'.

Infra I have been running myself only goes down when I reboot INTENTIONALLY.

I've been running gitlab for ~5y in companies with ~200 devs and haven't had a single downtime, it also takes very little work/effort.

I'm honestly sick of this conversation.

Have we as an industry forgot how to make systems? that's pretty telling if so.

Why are people so utterly afraid of running their own systems.

If a SaaS platform goes down it's followed by "#hugops; running large systems is hard!", when someone says "Well, if it's hard, why not break it into smaller pieces and run it myself" it's met directly with "Do you think you can do better!?!".

Honestly, probably, maybe not. Why does it matter?

Those two things cannot be true simultaneously. You cannot say "running big systems is hard" and "they can run a big system better than you can run a small system".

I'm not going to fall into the trap of arguing points like the fact that if you own the data you can have your own D/R & backup strategies and the fact you can run maintenance's on your own time (hell: you can run maintenance's to migrate things around, which is more than github can do, which is not an indictment of them, just the nature of being a hosted service).

Honestly, I miss sysadmins. People who were not afraid of servers, even if they said "no" sometimes. Because, you know, being afraid of servers and hosting things is just pathetic.

From an organisational perspective, outsourcing infrastructure is the safest and cost effective way to meet Regulatory & Compliance requirements.

When you run your own servers, not only do you need to maintain them, you are also responsible for their certification and getting them audited.

As a manager in a medium sized company, I think it is essential to identify what "needs building" and what could be bought to ensure the needs of stakeholders are met in a timely manner.

Heh, time was "compliance" was the reason to host your own services. It is a lot easier to be compliant with many things if you're hosting your own services.

Back when I was working in eCommerce (PCI-DSS Tier 1, Cardholder data on premises) it was basically impossible to use hosted services.

As then, it is now: "Compliance" is just enough nebulous of a word to prevent critical thinking.

I wouldn't call compliance a deterrence to critical thinking. The end goal for any business is to make a profit, if an option exists that complies with industry standards, which also happens to be the most inexpensive one in terms of resourcing, it would be foolish not to take it.

I think you misunderstand the intention. The parent comment is comparing uptime to their own system and declare superiority, and the one you reply to is asking the the opposite — the duration of downtime.

Sure you can build your own infrastructure but don’t pretend that’s superior. Each has its pros and cons.

The last line probably is making fun of their reaction — any person as dogmatic as the parent commenter would comment someone with their own infrastructure going down with that comment.

> Those two things cannot be true simultaneously. You cannot say "running big systems is hard" and "they can run a big system better than you can run a small system".

They can absolutely be true simultaneously. In fact, I can't name a logic system where those two statements comprise a contradiction. They are logically completely unrelated to each other.

It only takes one month long outage of an international undersea cable to negate all the benefit of SaaS when that SaaS is hosted in or heavily depends on other services hosted in the USA or Europe.

DNS goes down for a particular dot com? BGP hijinks? Backhoe through the major fibre serving your workplace?

All of these are going to happen and will lead to downtime out of your control or the control of the SaaS provider.

Thankfully git is designed to be decentralised and developers can continue to work even if they have to use paper books as reference material and not Stack Overflow.

It's not about being larger, it's about doing changes. GitHub used to be pretty stable before, when they didn't really do any (user facing) changes. It stood still in terms of features, but was also pretty stable overall.

Compared to GitHub, how often does your Gitea instance go through code changes? How many major features have been switched on in that instance during the past year without any hiccups?

I run Gitea myself as well. I generally throw in a new release once a month or so, never had any real hiccups.

Again, how much it actually change across those releases? GitHub most likely are going through more changes on a weekly basis (if not daily) than what Gitea does on a monthly basis.

The major releases generally change quite a lot in one go, for example:

https://blog.gitea.io/2022/02/gitea-1.16.0-and-1.16.1-releas...

https://blog.gitea.io/2021/08/gitea-1.15.0-is-released/

But I'm sure Github changes a lot more. However, the question is if those changes are worth the instability. For my workflow I just want my repos to be accessible, have my source, issues, and wiki accessible, and of course my basic git operations working. If that core functionality is actually not working at times, I'd definitely consider changing the git provider.

it sounds like you dont make code changes unless they are required for function.

Also for security reasons, and because some features are nice to have. But you're right in that I'm definitely not randomly updating sometimes. When I do update I basically just back up the database, throw in a new Gitea binary, and restart the service. As the releases have been fairly well tested in general, this hasn't given me issues so far.

I tried to look at the Gitea repo to see how fast they get commits, but github is 500ing :-(

https://github.com/go-gitea/gitea

Rest assure, a open source project with ~100 contributors (whereas maybe 10% regularly contributes) has less activity and changes than a multi-international company focusing a SaaS with "1000 to 5000" employees worldwide.

For perspective, GitHub has 4,000 employees who list them as their employer on LinkedIn and GitLab has 1,700.

GitHub's feature churn is irrelevant to the comparison unless those features are used in parent poster's workflow.

Really? No, comparing the uptime of two services (actually, one service and one open source self-hosted service) it's relevant to consider _why_ one would have more downtime than another, even if they don't use those features. Even if the parent posters workflow doesn't use the new/deprecated features, they will still be affected by the downtime GitHub have monthly.

I don't think anyone is overlooking the reasons why one might have more downtime than the other.

The problem is that ultimately the downtime itself matters and not the reason, and if you don't need any of the features that GitHub offers, then the self-hosted route is a better option.

> if you don't need any of the features that GitHub offers

In particular, all of the new features whose addition causes instability.

I think it's the development process (as in moving things around and potentially introducing bugs) than the new features per-se.

With all due respect to the developers, it would not speak well for GitHub if they can't maintain stability while refactoring. There's a lot of testing processes and CI processes explicitly around making those actions safe.

New features breaking is a lot more understandable - even expected - than regressions and refactoring failures.

An infrastructure company focusing on feature churn just sounds wrong.

What? Github is a social networking company.

I'm a bit dumb about these things on text, but did you drop an "/s" somewhere? I understand it has sort of a social networking layer on top, but that is not its main function right? This would be like calling a calculator app a social networking app because it allows me to share my results :D.

GitHub has always branded itself as a "social collaboration platform" rather than anything else (well, first "git hosting" but secondly the social stuff).

Here is a early version of their landing page from 2008 (the year they launched): https://web.archive.org/web/20081111061111/http://github.com...

Notice the logo says "Social code hosting" and the messaging of the page is mostly around popular repositories, collaborative features and other social elements.

Gitea is nice, what CI/CD system do you use with it? I used it in the past with Drone, and Drone left a lot to be desired (coming from/going back to GitHub actions, Drone's job syntax is a bit more complicated and focused on containers).

I've used Drone CI in the past with Gitea. I still prefer gitlabs CI tho

Drone CI has been working fine for our purposes. I agree that it may not be the most feature-packed thing in the world (for example, caching support is missing completely), but there are lots of plugins and it's easy to write your own.

We've been using exec and ssh runners when containers are not enough (for example, when you need to juggle a few VMs or build some complicated Docker image, and using docker-in-docker is not fun).

https://docs.drone.io/pipeline/exec/overview/

https://docs.drone.io/pipeline/ssh/overview/

GitHub Actions are nice… when they're actually working.

> A self-hosted Gitea instance my organization has been using had exactly zero downtime in the past year.

> Yes, I know, GitHub is 10⁹⁹⁹ times larger than our puny Gitea instance, and that's why they're having issues

Exactly. That is also my overall point. [0] It makes no sense to go 'all in' on GitHub and something goes down and everyone is stuck once again.

[0] https://news.ycombinator.com/item?id=30711442

Opposite anecdata my GitLab install absolutely self destructed itself at one point and I had to rebuild it myself, waste of a weekend

> my GitLab install absolutely self destructed itself

That’s frightening, we’ve been using it for multiple years now. It’s running fine and the only short downtime is every few weeks for the update.

What happened to your instance?

More fairly to GitLab it was the underlying server that broke initially. The issue from there was that I couldn't restore from the backup as the newly installed server was also a newer version of GitLab

Tried restoring it to the older version to run through the upgrade path and the process didn't want to work. Wish I could be more specific here but I gave up on it and decided it'd just be quicker to whip up a script to recreate all the groups/projects/CICD in a new install and push repos from backups

Don't let your GitLab server get outdated and don't consider it a valid backup unless it was taken with the latest version to avoid the same

Also it wasn't relevant here but make sure you're backing up the etc files too, while that wasn't an issue for me it could easily trip you over in a worst case scenario ( https://docs.gitlab.com/charts/backup-restore/backup.html#ba... )

Not a complaint, it's just one of the hats that needs wearing sometimes, would have been easier on me if someone else was handling it though :P

Thank you. From what I know direct updates to the next major releases of gitlab are only supported from relatively recent releases. I guess that’s what caught you.

We’ve been updating about as soon as an update is released for a while now, with very good results. (I’d rather have to restore a backup or a snapshot than to be running without the latest security fixes. If gitlab is down for an hour (didn’t happen in ~3 years) at least all developers have their local repo.)

Mind sharing some details on your install? Which database are you using (especially wondering about sqlite with gitea)? Are you using the docker install, or from package, or in k8s?

No pressure, but I'm seriously considering standing one up but it would need to be production ready.

Gitea is absolutely production ready, we use an older version by now and don't even think about it much because it just works so well. Exactly what you want in production (production = software should work more often).

Actually not "vendoring" dependencies from github is very much not production ready in many cases.

IMHO storage is the big issue to figure out with a production ready gitea installation. Gitea only supports the local filesystem for storing bare repo data and not anything like S3 or other distributed or highly available storage systems (it supports S3 only for git LFS data right now, it is a long awaited open issue to get the bare repos there too).

So the big issue for any non-trivial or highly available setup is going to be how you get high availability for the local storage volume. There are tons of options with various tradeoffs and levels of complexity here--simple local disk RAID, distributed filesystems like gluster or ceph, etc. I think this is the real crux of getting a good gitea instance going.

No matter what figure out and test a good backup and recovery solution!

Ah interesting! I read somewhere that it uses the database for that, but I think they were mistaken.

Thanks that's quite helpful. If we do it in prod we'll have to accept single-instance.

Yeah I forgot to mention too a lot of complexity goes away if you host it on a good IaaS platform. On AWS for example you could just mount an EBS volume as the bare repo root and use RDS for a database. Then you just have to deploy and manage an EC2 instance to host gitea's main process. It's more expensive to use those managed platforms but might be well worth the cost vs. doing it all yourself with a bare metal deployment of everything.

It's a really boring setup, I'm unlikely to share anything of much value here.

No k8s or anything like that. An Ubuntu LTS virtual machine on top of I don't know what hypervisor (probably Hyper-V). Gitea requires very few resources.

Data is stored in PostgreSQL 11. Probably should be upgraded at some point, but it's working fine for now.

A Drone CI instance runs on that same machine. It controls CI workers on a dozen other VMs.

Everything is in Docker containers under docker-compose for two reasons: easy upgrades, and the ability to shove all data into a single directory.

caddy for HTTPS.

Sonatype Nexus for package repositories (caching upstream npm, nuget, maven, composer, and our own internal repos). This one is pretty heavy and will probably be moved to a separate machine at some point.

Never had any issues with any of these in about three years we've been running this setup.

I was a bit facetious with the "zero downtime" statement. It has about 30 seconds of downtime per month, but it is always planned and outside of working hours deep into the night.

There's been zero seconds of unplanned downtime.

Basically you do:

    $ docker-compose pull
    $ docker-compose up -d

and half a minute later it is running new versions. If anything is broken (it hasn't been yet), call the sysadmin guy, and a few minutes later he restores a VM snapshot.

Backups are being done on the hypervisor's level. I don't know about that much.

cool, thank you!

10^999, really?

Rule of thumb is that 10^100 of anything doesn't fit in the observable universe.

Git is distributed, you should be able to completely detach from your remote and still work effectively. I think a lot of big projects get too lazy about good, reproducible build environments and just rely on centralized CI to do everything.

If you haven't noticed, the whole point of GitHub is to infest git-using environments with so many centralized features that user's get trapped using that service. Seems like issues and actions are doing that job nicely!

GitHub isn't just a repo in many cases. It is project management software.

Reply on news.ycombinator.com