[HN Gopher] GitHub Actions as a time-sharing supercomputer
___________________________________________________________________
GitHub Actions as a time-sharing supercomputer
Author : petercooper
Score : 123 points
Date : 2024-01-10 10:11 UTC (1 days ago)
(HTM) web link (blog.alexellis.io)
(TXT) w3m dump (blog.alexellis.io)
| api wrote:
| Cloud in general is just "mainframe 2.0."
| colonelpopcorn wrote:
| Definitely validates the mainframe architecture though doesn't
| it?
| jauntywundrkind wrote:
| Ironically the fastest path to getting everyone connected was
| to have them talk to cloud data-centers/neo-mainframes.
|
| So it both justifies the mainframe, but if you look at why we
| all went mainframe in the end, it was to, ironically, connect
| many computers together.
|
| There's also the overwhelming issue of power and control.
| Moving computing back to the mainframe allow totalistic
| control over computing by the service provider. This is a
| good way to make money. But is it good for the world? And
| what would the world look like if we had reliable fast
| trustable interconnected system, instead of cloud
| mainframes/data keeps?
|
| I'm forgetting which books but some of the books about early
| computing talked about protests against computerization,
| against the mass data ingestion (probably among others _What
| The Doormouse Said_?). For a while the personal computer was
| a friendlier less scary mass-roll-out of computing, but this
| cloud era has not seen many viable alternatives to staying
| connected while keeping computing personal. RemoteStorage was
| early in, and Tim Berners Lee trying a seemingly very
| reasonable Solid idea seem like very reasonable takes, or
| going full p2p with data /hyper and that world: none of these
| have the inertia where others can follow suit. The problem is
| much harder, but I think it's more path dependence and
| perverse incentives, that breaking out will be found to be
| quite workable and good and validated, but there's gross
| inaction on finding the moral, open ecosystem, protocols &
| standards based alternatives for connecting ourselves
| together as we might.
| mplewis wrote:
| Fast, trustable, and interconnected is a function of the
| infrastructure, so everyone who wants to host still needs a
| data center.
| jauntywundrkind wrote:
| Hosting from home seems absurdly viable for many. I have
| a systemd-timer that keeps a upnp-igd nat hole punched so
| I can ssh in, and that has absurdly good uptime. My fiber
| to the home would survive to quite a lot of use.
|
| Past that, vps can be had so cheap. If we have good
| software, the computing footprint ought to be tiny.
|
| One real challenge is scale out. Ideally, for p2p to
| really work, some multi-tenant systems seem required, so
| we can effectively co-host. I loved the sandstorm model,
| but didn't actually use it, and I think there's further
| refinement possible.
|
| Ideally imo, I could host like 10 apps, but if you want
| to use one, you spin up your own tenant instance. The
| lambda engine/serverless/FaaS thing wouldn't actually
| spin up new runtimes, it'd use the same FaaS instances,
| but be fed your tenant context when it ran and only be
| able to access your tenant stuff. That way as a host, I
| kind of know & can manage what runs, but you can have
| your own freedom of configuring your own instance to a
| large degree.
|
| Then we need front ends that let you traffic steer and
| any cast in fancy ways, so you can host your own but it
| falls back to me, or you have 10 peers helping you host &
| you can weight between them.
|
| Operationalizing what we have already & finding efficient
| wins to scale is kind of cart before the horse, since
| fediverse &Al are so new, but I think the
| deployment/management model to let us scale our footprint
| beyond ourselves is a crucial leap. And I think we are
| remarkably closer than we might think, that the jump into
| a bigger more holistic pattern is possible if we leverage
| the excellent serverless runtimes & operational tools
| that have recently merged integratively.
| o11c wrote:
| It's not a mainframe unless IBM ships 6 entirely different OSes
| for it.
| nordsieck wrote:
| Indeed.
|
| http://www.winestockwebdesign.com/Essays/Eternal_Mainframe.h...
| kubanczyk wrote:
| Thank you, much appreciated. While I'm still processing the
| arguments, the style itself is breathtaking. They don't make
| sentences like this anymore:
|
| > Home computers are not unusual, anymore; the novelty is
| gone.
| ndiddy wrote:
| The approach the author describes is batch processing, not time
| sharing. The whole point of time sharing was to allow users to
| work with the computer interactively rather than having to submit
| a job and wait for results.
| Waterluvian wrote:
| This reminds me of my dad talking about how amazing it was when
| time-sharing became a thing at UWaterloo. He'd talk about how
| batch-processing was such a pain when you'd discover some tiny
| error and have to get back in line, and how with time-sharing
| you could show up at 3am and have an entire PDP to yourself.
| dekhn wrote:
| My PhD advisor stayed up late at night (in the '60s) to get
| exclusive access to an IBM mainframe that was normally used
| at UC for payroll. When I joined the lab the convention was
| to go find a machine that was only lightly loaded (manually;
| there was no batch queue, just telnet to a cluster of
| machines) and start your multi-month simulation and hope
| nobody else popped onto the machine to steal half your
| processor.
| bee_rider wrote:
| Batch processing and time sharing, there are pros and cons.
| Time aloning, though, there are no cons.
| jamesblonde wrote:
| Yes. In the courses I give on MLOps, we use Github Actions to
| run on a schedule:
|
| 1. feature pipelines
|
| 2. batch inference pipelines
| ipsum2 wrote:
| I needed to setup GitHub actions for several open source
| repos for automated CI/CD, using it for ML pipelines seems
| awful.
| pona-a wrote:
| Wouldn't Google Colab then we closer to both "time shared" and
| "supercomputer"? Jupiter
|
| notebooks are certainly interactive and Colab's purpose is to
| allow often low-powered clients to offload ML
| training/inference to a GNU-enabled server, so kind-of like
| time-shared systems of the old?
| jhallenworld wrote:
| It needs JCL cards for proper batch processing.
|
| Speaking of mainframes... I ran across this video on the latest
| workflow for COBOL / CICS development on your IBM mainframe.
| You have the old 3270 emulation way yes, but then we move into
| 2010 technology: a custom version of Eclipse IDE that submits
| the jobs for you, then we move into modern times with Visual
| Studio Code integration (using something called Zowe CLI):
|
| https://www.youtube.com/watch?v=_CYUYnKim7U
| kevmo314 wrote:
| "super" seems a bit generous. Actions runners have always felt
| slow to me. Fast enough to get the job done for CI/CD but for a
| batch job running it locally would be faster.
|
| This idea does leech free compute in an API-agnostic way though,
| if this could be tied together with a GCP free tier, AWS free
| instance, etc I wonder if you could cobble together enough free
| resources to run everything you wanted.
| ape4 wrote:
| I suspect they are slightly slow on purpose - so people don't
| abuse it for mining or whatever
| pinkgolem wrote:
| CPU is okay from my observations, but iops is surprisingly
| slow
| tomComb wrote:
| Why do actions use VM's instead of containers? And yet codespaces
| use containers.
| autoexecbat wrote:
| sometimes you need to be able to run containers within your
| action, which can get complicated if you're already in a
| container
| falcor84 wrote:
| Is there an inherent complication here?
| fermuch wrote:
| There are some! This is called "Docker in Docker", and you
| need to expose your docker socket to the container, which
| has some security implications.
|
| It can be secured, as gitpod does, but as I understand it
| is a PITA.
| bo0tzz wrote:
| > you need to expose your docker socket to the container
|
| I always thought this was a hard limitation, but I
| deployed some self-hosted GHA runners in Kubernetes this
| week and to my surprise that setup came with an option to
| run the full docker daemon inside of a container - so
| apparently it is possible.
| alexellisuk wrote:
| If you're running a full docker daemon, then you'll be
| running as a privileged container which is worse or about
| the same in terms of terms of poor security. Anyone's
| workload can compromise the host, and likely the cluster.
|
| Rootless containers are a lot of work and do not support
| many scenarios that you're going to need.
|
| MicroVMs are the same experience as GitHub, full system
| and Kernel, do what you will. Even launch a nested VM.
| dboreham wrote:
| That's not what dind is. Rather, there is a docker daemon
| running inside the container, and the containers it hosts
| are nested inside its cgroup in the host kernel. The
| result is very close in feel to docker in its own VM.
| Furthermore nesting can be done inside one of the payload
| containers creating a turduckin. E.g. you can run k8s in
| a container, with k8s nodes implemented as nested
| containers and the cluster pods as doubly nested "pigeon"
| containers.
|
| I haven't tried more than three levels but in theory more
| should work.
| chuckadams wrote:
| docker-in-docker doesn't run a docker daemon in the
| container, it just bind-mounts the host's docker socket
| inside the container, and the docker client talks to
| that. Any containers you launch from within docker-in-
| docker are _siblings_ , not nested.
| ekimekim wrote:
| You are mistaken. From https://hub.docker.com/_/docker:
| What is Docker in Docker? Although running Docker
| inside Docker is generally not recommended, there are
| some legitimate use cases, such as development of Docker
| itself. ...If you are still convinced that you
| need Docker-in-Docker and not just access to a
| container's host Docker server, then read on.
|
| This makes it pretty clear that it's a different copy of
| the docker daemon (which eg. allows you to test changes
| to docker itself) and specifically says it's different
| from "just access to a container's host Docker server".
| angra_mainyu wrote:
| It's hardly a PITA, I've done this a few times and as
| long as you use the dind docker image, it's easy to
| forget you're even using DIND.
| autoexecbat wrote:
| I think it simply got easier over the years, as the
| various implementations overcame problems
| alexellisuk wrote:
| Good question, I covered that in detail, including the issues
| with Docker In Docker.
|
| https://actuated.dev/blog/blazing-fast-ci-with-microvms
|
| https://docs.actuated.dev/faq/
| ranting-moth wrote:
| GitHub Actions computing time is crazy expensive. Especially the
| Mac prices.
| judge2020 wrote:
| Running macOS legally requires real mac servers and a bespoke
| storage solution:
| https://www.datacenterdynamics.com/en/analysis/not-just-stac...
|
| A self-hosted macOS runner will be more economical in the long-
| run, if you have a spot you can hook it up at; or, if you're
| fine doing things less than legally, you can use
| https://github.com/sickcodes/Docker-OSX.
| actionfromafar wrote:
| I'm sure legality depends on jurisdiction, too. If you
| acquired the software legally and you need to keep it running
| in a VM, I'm sure it's legal at least in some places.
|
| But yeah, just drive-by-downloading MacOS to your Windows box
| it is probably not quite on the up and up.
| xjia wrote:
| We are working on an alternative that's 100% compatible with
| GHA but much cheaper and faster. Check out https://dime.run/
| tomschlick wrote:
| They also price gouge by charging each job you run as per
| minute rounded up.
|
| So if you have 5 10 second actions that run when a PR is
| created, that 50 seconds of compute is charged as 5 minutes.
| Retr0id wrote:
| Is it really price gouging, or just embodying the real warmup
| costs of spinning up a job?
| almostdeadguy wrote:
| I truly don't understand why this isn't more widely discussed
| (I've seen several "GH Actions Gotchas" articles where this
| isn't mentioned). Many of the community actions also seem to
| be designed to run as short jobs to paper around missing
| features (for ex: https://github.com/dorny/paths-filter ),
| that end up eating up an enormous amount of your minutes
| budget.
| wilg wrote:
| Highly recommend everyone check out the self-hosted runners.
| GitHub has made it crazy easy to set up and all your actions
| are free and can have local cache. And you get all the benefits
| of the Actions ecosystem. Throw a used Mac mini or old PC or
| whatever at it.
| aberoham wrote:
| Alex's product vision is fantastic. I hope
| https://github.com/self-actuated gets noticed by more folks out
| there who are hitting the limits of GitHub's hosted runners.
| k8svet wrote:
| Seems like a solid tech approach too. I'm surprised there isn't
| more of this around GHA. It really feels like Microsoft
| calibrated exactly good enough, yet everyone seems to have
| their own piles of workarounds in published actions, even
| bigger piles in their infra, and then some more in the workflow
| yamls themselves, to get everything actually workings,
| especially when you need to support GHA runners, self-hosted
| runners, ARC runners, `act` runners, etc. If they can foster an
| OSS community around easy self-hosted, and then also offer a
| hosted runners product that is priced well. I'd pay 'em.
| imiric wrote:
| Neat, this is a great simulation of eventual computing. When GH
| Actions goes down, it would be like your time-sharing quota has
| run out. (:
| gchamonlive wrote:
| I know this is tangential to the linked article, but why the
| "Open" in OpenFaaS if the community edition is so limited? The
| first payment tier is 1000 dollars. Is that open in the sense you
| can send pull request and inspect code?
| dmattia wrote:
| > "is GitHub Actions production ready? The answer is yes, so by
| proxy, you could run this tool in production"
|
| I sent this to some of my coworkers for a good laugh.
| posix86 wrote:
| > There's something persuasive about running jobs and I don't
| think it's because developers "don't want to maintain
| infrastructure".
|
| I remember taking a small university course on Ethereum, and
| getting an introduction smart contracts, trustless environments,
| and so on. We then heard about a couple of example projects, and
| were finally asked for our own ideas.
|
| Now, after learning a bit more, I'm pretty sure none if the ideas
| presented either by the lecturers, me, or the other students
| really benefitted from the trustless environment, which is mostly
| what you'd use Ethereum for, and arguably what you pay (a lot)
| for during contract execution. Yet there were so many ideas about
| what could be done using smart contracts which were really cool
| projects on their own.
|
| I think a big world computer with nodes that can perform
| calculations, react to user input, be called from other nodes,
| and exchange tokens and information, is somehow an incredibly
| natural abstraction that humans can work very well with. So,
| agreed.
| ufo wrote:
| One thing that I still don't understand about github actions is
| how much computing power gets wasted downloading and reinstalling
| the same dependencies over and over. A build that takes a couple
| of seconds in my local machine can easily take several minutes in
| github actions.
| 0cf8612b2e1e wrote:
| GitHub charges per minute. Some incentive to keep actions on
| the most under specced machines available.
| Raed667 wrote:
| Do other CI services do it differently? I worked with Jenkins
| and Circleci and it was exactly the same.
|
| For github actions caching was fairly easy to add.
| codetrotter wrote:
| Yeah. We have a similar thing going on with self-hosted GitLab
| at my work. (And there, there isn't even any incentive why it
| should be slow.)
|
| When I make an edit and rebuild on my computer, it takes a few
| seconds to rebuild because most things are cached.
|
| In CI it takes 20 minutes on the MR branches of our repo. 30
| minutes on master. Because a whole bunch of crap is downloaded
| from scratch and rebuilt from scratch.
|
| Our infrastructure guys did set up something that is able to
| cache stuff that some of the repos use. But with the limited
| access I have I have not been able to figure out how to make
| use of it for the repo I work on. And they don't have time to
| look into it for me either.
|
| That's my life lol
___________________________________________________________________
(page generated 2024-01-11 23:00 UTC)