Developing Inside a Container

Don’t fall for this. It’s too good and I can’t get out now since nothing else than vscode supports it.

Dependencies, env vars, dev databases, ports, everything all written up in code and ready to use once you open the workspace. All without messing up your host pc. Works also via ssh.

I started to develop in containers before VSCode introduced the dev container to keep my local machine clean. A few years ago, I switched to the VSCode dev container, and the integration is very good. Having the ability to have a dev environment ready per project is very neat. We started to adopt it in my company. As a team it saves a lot of hassle, and onboarding is much faster. However, we have encountered some issues, mainly when we want to work with GPU and PyTorch dependencies, and that is the opposite of pleasant! Otherwise, now each new project/repo I create comes with a dev container.

I'm not sure I follow -- do they suggest running VS locally, and the work/project inside the container?

I've been doing this for years, it seems to me like the absolutely hands-down easiest way to keep projects encapsulated and easily shareable with coworkers.

Set up the env in a docker container, mount a volume to a local fs where all the sources live, ssh into the container if necessary, interact with app(s) within the container over http.

What's MS adding here, what am I missing? They streamline the process and integrate scripts with VS?

I’ve been developing inside of Podman containers using Neovim. It’s mostly great. I love that my machine doesn’t get cluttered with random dev dependencies.

Yesterday, though, I ran into an issue where Bun was occasionally not completing http requests. I thought it was a bug with Bun (it might be), but the issue went away when I ran it outside of a container.

Containers do add layers which sometimes cause issues, or at least make diagnosis trickier.

I recently started using this workflow and I'm very pleased by it.

Now, for every project I start, I quickly create a Docker container with all dependencies the project needs, and then I develop inside the container using vscode. If I need to develop in another machine (laptop instead of my desktop for example), I just download the Docker image, and everything is already setup to start coding.

We've been using tilt [1] for a similar process.

If you are doing a k8s deployment anyways then tilt is really quiet nice once properly setup.

The one thing that isn't so nice is local package caching. That's a hard problem to solve and containers makes it annoying to get right.

[1] https://tilt.dev/

We've been using this where I work for over a year and I'm never going back.

https://devspace.sh also gives a similar workflow but where the container is running in a remote k8s cluster

I like tilt [https://tilt.dev] if the dev infra has any significant complexity to it.

Docker compose also has a "watch" command that can do lots of the the things devcontainers does, and I use it for more simple setups.

https://docs.docker.com/compose/file-watch/

I guess I've been living in SF for too long... upon seeing the headline, my first thought was "a developer working from his container home, makes sense".

DevContainers are good. I find them especially nice for working on k8s stuff. For those comparing them against Nix, it's likely that most developers are already familiar with Docker, while Nix's language and tools have a pretty steep learning curve.

I’ve been using DevPod (https://devpod.sh) for this and it’s been pretty great.

I like this but I use an x86 32-bit box for my "home lab" (for the fun of needing to compile everything myself) and it'd be nice if VSCode supported that natively. As is I had to compile VSCode server myself, which isn't exactly what I wanted. Unsure if I can even add 32-bit x86 to this functionality.

My biggest problem with DevContainers has been getting the debugger to work. I need to walk through the code for my job, and it’s been a pain to get it to work in a container. Never understood what I’m doing wrong though, theoretically it shouldn’t be any different than how I set it up on my local machine.

While I personally don't love developing at all times within a container. When I need to, I've found the flow of setting up with Nix and then containerizing to be the most ideal today. Is there something new recently that folks are using?

(I'm also a biased person as I'm a Nix person at heart)

Somehow I still prefer using Nix to have consistent dev env...

Does the container approach bring something more than using Nix?

Isn't this just glorified bind mount? I skimmed the article but could not see what this does other than let you write files in your docker container through VS code. Why not just set up a bind mount and run any old editor?

Mmm, I already do this with LXC, but could be better integrated, I guess?

My next goal was to use Docker for this, but since I don't know docker yet, I'm not sure if that would a good idea for having a ready prod env right after a commit.

I like the concept. What I didn't like was:

- Re-opening the project in a dev container felt like overhead

- I sometimes stuggled with setting the work directory

- Restarting the development container for various reasons interrupts the development

I fail to see how this is any better than IntelliJ/PyCharms remote interpreter feature and Services tab and a proper docker-compose file. It feels like VSCode is finally catching up.

Somehow I still prefer using Nix to have consistent dev env...

Does the container approach bring something more than using Nix?

i much prefer using docker “compose watch”, i never fully managed to wrap my head around the relationship and proper setup of vscode workspace, project and container.

is this like rookout?

This feature is at least 5 years old, why isn't (2019) in the title?

https://github.com/microsoft/vscode-docs/blob/3bafb9f610bd6b...

Hacker Olds, amirite.