Examples & blog posts

[bpmct]

In preparation for the v1.0 launch on Oct 1, let's create the following examples (for examples/ dir) and blog posts so people can find these use cases on Google:

• Run Dev Container on Kubernetes: Example Kubernetes spec yaml
• Run Dev Container on OpenShift: Example OpenShift spec
• Run Dev Container on Red Hat Code Ready / Eclipse Che: Example blog post + issue comment on how folks can run Dev Containers on Red Hat Code Ready as a workaround
• Build Dev Containers in CI / GitHub Actions: Example workflow to build & push a dev container image or to run your pipeline with it

[mattvollmer]

Do we see this content living within a single blog post? It's good stuff, but I have reservations about flooding the blog with too much at one time. Or, would we start with K8s and drip the remaining posts over 'n' days/weeks?

[phorcys420]

hey @mattvollmer, the way I understood it when talking with Ben was that each use case would have it's own post

[bpmct]

👍 and these can explain how to use envbuilder but not necessarily coder as envbuilder works without coder

…

On Wed, Sep 11, 2024 at 11:36 AM Phorcys ***@***.***> wrote: hey @mattvollmer <https://github.com/mattvollmer>, the way I understood it when talking with Ben was that each use case would have it's own post — Reply to this email directly, view it on GitHub <#335 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFK6WELE6RSJG52WKHB3WEDZWBWRJAVCNFSM6AAAAABNQ76RBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBUGE2DEMBVGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[phorcys420]

I've started working on the Kubernetes and GitHub Actions examples but ran into some pretty important road blocks/questions.

For GH actions, GitHub forces tail as the entrypoint, and we also need a shell to run the job, both things which the envbuilder image lacks (this should be an easy fix though, talked about this w/ @johnstcn today and we could replace the base image with busybox to keep it light).
The other issue is that you'd need to pass registry auth to envbuilder through ENVBUILDER_DOCKER_CONFIG_JSON_BASE64, which is not convenient at all.

Now to put it in contrast with the other option, there is an already existing devcontainers/ci action that lets you prebuild images and push them to the registry, also lets you run tests/builds within the devcontainer.

The issue with this is that envbuilder is honestly less convenient to use than the official option in its current state, and i'm not sure if it would make sense to use it instead.

---

For Kubernetes, it's pretty simple but I would like to know what example use-case makes the most sense.
Running tests and building makes more sense in CI, and running the devcontainer to do programming in feels weird to promote outside of a CDE.

So I'm not sure in which case it would even make sense to run Devcontainers in k8s in the first place (envbuilder or not).

---

I know we're trying to showcase the fact that envbuilder is not a Coder-only product, but I don't think we should be pushing less convenient use-cases to show that off, Eclipse Che/OpenShift Dev Spaces is definitely a great use-case though!

cc: @bpmct

[bpmct]

Oh nice TIL about devcontainers CI. Makes sense. Although I assume you also need to pass docker config to that? Overall, it seems easier though. For kubernetes, a basic YAML spec similar to the existing docker run would be good just so people know it’s possible to run in k8s and can get into a shell

…

On Sun, Sep 22, 2024 at 1:34 PM Phorcys ***@***.***> wrote: I've started working on the Kubernetes and GitHub Actions examples but ran into some pretty important road blocks/questions. For GH actions, GitHub forces tail as the entrypoint, and we also need a shell to run the job, both things which the envbuilder image lacks (this should be an easy fix though, talked about this w/ @johnstcn <https://github.com/johnstcn> today and we could replace the base image with busybox to keep it light). The other issue is that you'd need to pass registry auth to envbuilder through ENVBUILDER_DOCKER_CONFIG_JSON_BASE64, which is not convenient at all. Now to put it in contrast with the other option, there is an already existing devcontainers/ci <https://github.com/devcontainers/ci> action that lets you prebuild images and push them to the registry, also lets you run tests/builds within the devcontainer. The issue with this is that envbuilder is honestly less convenient to use than the official option in its current state, and i'm not sure if it would make sense to use it instead. ------------------------------ For Kubernetes, it's pretty simple but I would like to know what example use-case makes the most sense. Running tests and building makes more sense in CI, and running the devcontainer to do programming in feels weird to promote outside of a CDE. So I'm not sure in which case it would even make sense to run Devcontainers in k8s in the first place (envbuilder or not). ------------------------------ I know we're trying to showcase the fact that envbuilder is not a Coder-only product, but I don't think we should be pushing less convenient use-cases to show that off, Eclipse Che/OpenShift Dev Spaces is definitely a great use-case though! cc: @bpmct <https://github.com/bpmct> — Reply to this email directly, view it on GitHub <#335 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFK6WEIIXXAQYB6W4CLWQ3TZX35THAVCNFSM6AAAAABNQ76RBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRWHA4DKMRTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[phorcys420]

Oh nice TIL about devcontainers CI. Makes sense. Although I assume you also need to pass docker config to that?

You kinda do but it actually respects .docker/config.json so you can use the existing docker/login-action action, which won't work with envbuilder AFAICT.

For kubernetes, a basic YAML spec similar to the existing docker run would be good just so people know it’s possible to run in k8s and can get into a shell

Alright I see, so not highlighting anything specific, just showing that you can build&run devcontainers on the fly.

EDIT: You mentioned in DMs that people could run their staging infra on devcontainers and I think that's actually a valid use-case.

[bpmct]

Yep! And makes sense. I guess we would have to make a envbuilder specific workflow people would import to emulate that, and the advantages aren’t clear at this point. We can pass on the CI use case, just realized my previous comment wasn’t clear.

…

On Sun, Sep 22, 2024 at 1:41 PM Phorcys ***@***.***> wrote: Oh nice TIL about devcontainers CI. Makes sense. Although I assume you also need to pass docker config to that? You kinda do but it actually respects .docker/config.json so you can use the existing docker/login-action <https://github.com/docker/login-action> action, which won't work with envbuilder AFAICT. For kubernetes, a basic YAML spec similar to the existing docker run would be good just so people know it’s possible to run in k8s and can get into a shell Alright I see, so not highlighting anything specific, just showing that you can build&run devcontainers on the fly. — Reply to this email directly, view it on GitHub <#335 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFK6WENPILSJLX3EN4BZIVTZX36NLAVCNFSM6AAAAABNQ76RBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRWHA4DQMBUGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[phorcys420]

Alright so I'll see if I can get access to Tim's OCP cluster, otherwise there's probably a way to get a trial or something.

---

Given that K8S/OCP are basically the same thing with different resource names, I think we should do both of those in the same article.

So in the end we'd end up with:

• Run Dev Container on Kubernetes/OpenShift: Example Kubernetes & OpenShift spec yaml
  • Run an existing devcontainer
  • Run your staging env on dev containers for easier debugging since all the right tools are there
• Run Dev Container on Red Hat Code Ready / Eclipse Che