Continuing the conversation from

[drowsy ocean]

.

If you're interested in early access, you can DM me, or say hi here, or just click "contact us" on https://dagger.io

[torpid jewel]

Pretty please

[drowsy ocean]

@torpid jewel would the high-performance runners I mentioned be a good fit for you? Self-hosted GHA on AWS (our initial beta focus): something you could deploy?

[torpid jewel]

I sadly had to drop off before you got to that part. Both lunar and I would probably do self hosted because that is the most cost effective solution.

And yes we do have that capability

[drowsy ocean]

Yes self-hosted is what we provide. We give you a CI runner stack to deploy on your own AWS account. Under the hood is an EKS cluster with Github Actions runner + dagger engine pre-installed on all nodes. All nodes are hooked up to a centralized "acceleration" service, that collects telemetry and orchestrates caching across the cluster.

You deploy, configure, then setup your Github account to send jobs to your new self-hosted runner stack, and you're good to go

The difference is that if you use dagger in any of your Github Actions jobs, it's super fast and properly cached, and you can visualize it all in the cloud UI

this saves you money and time because the more your pipelines are cached, the less compute minutes you need to run them 🙂

@vale dragon I'm wondering if the above is something you could try, in spite of the corporate allegiance mismatch ? 🙂 Maybe you using it can facilitate future support for an Azure CI stack?

[torpid jewel]

This may not fit entirely with what we need from Lunars perspective, we already got a our own kubernetes cluster and would rather run it there. Also we are not using dagger raw. We have our own tools on top, without finding out what rhe runder consist of it may or may not be compatible. It should be though as long as it functions as a normal runner.

I.e. we would prefer just having an image we can run to provide the things.

[vale dragon]

I think it would be difficult to run such a stack even if it were on Azure.
Internally we have a team who essentially manages build agents (we do customize them, setup allocation strategy, etc, though), but this is all tied into Azure DevOps.

[drowsy ocean]

using your own tools will work transparently unless you are forking the engine itself. You just wrap execution of your tool with dagger run and you’re good to go

We do provide the engine as an OCI image that you can run yourself. But you will not get the seamless scaling and acceleration. We do plan on offering the acceleration service separately from the high-performance runners, so that you can “bring your own runner”, but that will not be available right away

Eventually we will offer a kubernetes controller to drop on your cluster, but that will take longer too because the support and QA surface area are wider. Different kub versions, kernel versions, hosting providers, plugins, interplay with other controllers etc. Hard to guarantee that it will work

For now easier to stand up a clean cluster on a narrow platform target, and take responsibility for supporting it

We can probably offer an “escape hatch” for design partners that are excited about using the platform overall, and don’t mind lower support guarantees in exchange for more control over the runner configuration

[torpid jewel]

I would have trouble convincing our platform squads / org to adopt the semi managed approach. We would definitely be interested in an operator or the likes though.

I think it is a valid approach for more traditional companies. But Lunar may not be the right fit for now.

That said we will probably run our own runners anyways just with our own configuration.

[drowsy ocean]

We just don’t want to mass-distribute a helm chart and then spend all our time doing basic kubernetes support on discord

[torpid jewel]

I fully get it. When we choose this approach we are fully in the clear that we will get no platform support

[drowsy ocean]

can you clarify what you mean by semi-managed? The caching service?

[torpid jewel]

The aws eks cluster thing

[drowsy ocean]

ok got it. But setting up on kub yourself + hooking up to cache+telemetry service is ok?

[torpid jewel]

Yep. I would expect so

[drowsy ocean]

most of the value is in caching & telemetry. The packaging of the runners in kub is more of a convenience

so what you describe seems perfectly fine and you should be able to get tons of value 🙂

[torpid jewel]

We are running our own CAPI so we would gitops a new cluster up with the required resources

[drowsy ocean]

Ok if @coral relic gets in touch to discuss your use case, and walk you through the early access program?

[torpid jewel]

Sure I think we've gotten a bit further since last we talked and have something cool to show as well

Just out of curiosity is the source available for the integration?

[drowsy ocean]

Which part, the kub configuration etc?

[torpid jewel]

Yep, i guess. But if it just uses flags inside of dagger then it wouædnt actually be needed.

I.e. experimental_dagger_cache etc

[drowsy ocean]

Right now it’s a combination of flags and perhaps a few patches to the engine, plus kubernetes resources , and generated cloudformation templates

engine patches are temporary, that will all be open soon enough

flags - may not be stable or properly documented

kub resources: not open source at the moment, but not exactly a state secret. We’ll probably open source and even before that, share with design partners as needed

cloudformation template (and associated tooling): not open, probably not worth the effort since if you don’t use the final packaged product, you probably have your own provisioning stack anyway

[torpid jewel]

We can wait for it to go upstream we're very much still in the poc / figuring out how we want to work with dagger.

[drowsy ocean]

it may already be upstream, cc @sick iris

One suggestion for the POC phase is to simply use the full thing: just standup a test cluster with our template, use it for your poc. Then you can always invest the time to custom install on your cluster if/when you decide the poc is successful

Less time investment for you upfront

[torpid jewel]

I will discuss with my team how we want to proceed. I can't be here making all the hard decisions 😉

[sick iris]

Yeah so the client-side code for the engine is already merged into our main branch. The idea is that all you need to do is provide an api token for our cloud, so if you are running the registry.dagger.io/engine image in your k8s cluster you just need to set an env var with that token when the engine spins up. From there the engine talks to cloud and internally figures everything else out, no extra config needed from users.

The practical reality at this exact moment is we haven't deployed the cache service to our cloud yet, but there's a workaround if needed. That's a very temporary state of affairs though, migrating it to run in our cloud is the next step we're working on.

[torpid jewel]

Sweet. That is fine for us xD. I will figure out the details with Jeremy at some point.

[drowsy ocean]

Given that context, do you see a path to moby-packaging, and therefore Dagger, getting used "for real" in your org?

[slow sentinel]

Hi, interested on the early access here 👀

[vale dragon]

If by "for real" you mean this stuff with the acceleration service and all for your production builds, I think this is a little bit at odds with how we do builds.

[drowsy ocean]

I just mean in a way that meets your organization’s bar for running those pipelines in production. Whatever that bar is, I want to make sure dagger can meet it 😁