How can we spin up dev container from dagger? Please help to write a step by step blog

[crude vortex]

I am currently exploring to write a step by step guide blog to spin up dev containers with dagger only.
in this workflow, we dont want to write any docker file or docker compose file also.
Awating your response.

[patent hamlet]

you can spin up devcontainers with Dagger. There's a caveat though which is that Dagger doesn't allow yet to bind mount files in your machine to the container

so you'll have to restart the devcontainer each time yoi make changes to your files

it's not the ideal flow, but something that we'll eventually want to enable

[crude vortex]

any ETA?

[crude vortex]

@patent hamlet any ETA bro?

[patent hamlet]

Hey! There's no ETA for this.

[crude vortex]

@patent hamlet is this possible now with dagger 0.10 release?

[patent hamlet]

hey! no, not possible yet. You can still do it, but it has the same caveats that I mentioned above

the code that you modify in the devcontainer won't be automatically synced to your local machine

[crude vortex]

We don't want to sync it with a local machine we just want to push it to github repo once work is done that's the only requirement from dev container, so can you please guide for it?

[radiant sage]

@crude vortex - It might not be exactly what you are looking for, but I figured I'd throw it in here as a possibility. We are using Coder successfully for a while now for what they call CDEs or cloud development environments. Maybe it is what you are looking for?

[crude vortex]

thanks a lot for helping.
i am aware of coders and such tools but we want to build with only dagger and dont want to use any other things as dependency. so our team is reserching how we can migrate to dagger only dev and cicd workflow

[crude vortex]

we will be able to keep modified code files till we turn down dev container or kill container through dagger?

[patent hamlet]

yes, you can export the modified files to your local machine before shuttind down the environment

[patent hamlet]

where are you planning to pull the code for the dev environment?

also, what do you expect this dev environments to contain?

are you planning to provide a remote VSCode or something so developers can edit the code in the editor?

what's the workflow that you have in your mind?

[crude vortex]

we just want to spin up dev container through the dagger and want to develop in that container and once work done we want to stop or kill that container, currently in local machine...other part we will take later in enhancement and basically we want to replace docker in our devops workflow with dagger for any end to end work...we dont want to write docker files or compose yml files, that's it
Please HELP

[lone hare]

@patent hamlet one part I'm not sure about, is IDE integration. What's the standard way for IDE to integrate with a devcontainer? Can I configure say, VSCode or Zed so that it's transparently editing files in the contaner, and when it opens a terminal, that terminal is in the container? That's the experience I would want, but I have a feeling that reality is not so seamless...

[patent hamlet]

for VSCode AFAIK the integration is seamless given that as long as I can expose a TCP port to the host I can attach the VScode client and everything works out of the box. Not sure if Zed has the same model though.

[lone hare]

What's the protocol behind that TCP port?

[patent hamlet]

not sure, haven't checked what underlying transport it uses

https://code.visualstudio.com/docs/remote/faq#_what-are-the-connectivity-requirements-for-vs-code-server

[lone hare]

Ah well that answers my question, it' s a vscode-specific server protocol

One part that will be painful, is that VSCode remote works by airdropping binaries into the remote server in a very ugly way

I expect it doesn't work well with ultra-ephemeral containers, because VSCode will just reinstall everything each time, which will be slow

[patent hamlet]

it's quite nice because it also multiplexes other ports over the same transport. So if you run something in your dagger container, you can still access it via localhost in your machine

[patent hamlet]

well.. I guess we can:

1. use a cache volume
2. try to pre-install those binaries beforehand as part of the module

[lone hare]

yeah that could work

The other approach is devcontainers: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers

But then that's tied to calling docker I guess

[patent hamlet]

devcontainers is basically a spec over the vscode transfer protocol

[lone hare]

Yes but it's also a specific implementation in a VSCode extension, which has a hardcoded dependency on the docker CLI I think

--> This extension https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers

[patent hamlet]

yes, correct

I'd assume there's something in the spec where you can say: "don't provision the server, just connect to this port".. but we'll need to check

[lone hare]

Eventually would it make sense to fork the devcontainers extension, and make a Dagger-compatible one? Or even contribute dagger support to the upstream extension?

Not looking good 👆 (for preinstall)

But cache volume could work

@patent hamlet I think the options for integrating with VSCode boil down to 3 possible entrypoints:

1. SSH (via Remote/SSH extension)
2. Docker CLI (via Devcontainers extension)
3. Dagger CLI (requires forking the devcontainers extension)

[radiant sage]

This is exactly what Coder does (among other things). And it isn't simple to do AFAIK (otherwise Coder wouldn't be a thing, right?). Coder sets up a tunnel over HTTPS so that VSCode or other IDEs can communication via SSH within the container (using tailscale). Terminal connection is also included, but over Coder's tunnel.

[crude vortex]

@lone hare @patent hamlet first of all thank you so much for taking consideration of this idea and showing serious efforts in this direction, yes after spinning up container we can connect it with vs code via vs code remote container or ssh feature of vs code extensions, so we are very close...we don't require to much things to implement to achieve this...please keep this efforts on and help me to write a blog for dagger.
which can remove the dependency of docker eventually.

[crude vortex]

any update for this vision?

[crude vortex]

@lone hare any steps required from my side?

@lone hare can't we use this so we can have url also in browser for dev https://code.visualstudio.com/docs/remote/vscode-server

can running cli command forwarded to dagger and then to cli to get that running url and get auth with it?

[crude vortex]

@lone hare @patent hamlet are we there yet?

@lone hare can we achieve similar functionality of https://devpod.sh/ with dagger function capabilities without using devpod?

[lone hare]

@crude vortex no, Dagger does not replace devpod. It's possible to implement a devpod equivalent on top of Dagger primitives, as discussed in this post. But that is not something we (the core Dagger developers) are focused on. If you decide to work on this yourself, we will be happy to support you by answering your questions. But unless you or someone else in the community decides to invest their own time, it will not happen on its own. Please stop asking.