Hacker News Reader

Comment by dsfsaff | Hacker News Reader

I have used a Virtual Box VM with a Ubuntu guest for years and it has worked great. It's as close to the VM's in prod you can get.

View on HN

I used to do that, but now that all of our microservices are dockerized every microservice has its own docker container

Vscode supports remote containers, so everyone in the org just develops INSIDE a replica of the prod container

All containers run remotely on enormous machines with 800+ GB of RAM and 8+ GPUs

It’s trivial to share environments now because you just open the project and the dev container starts up and installs all the deps, devcontainer.json is just a few kb so just check it into git

Engineering, DevOps, Data science all use this setup, push around your devcontainer.json and everyone gets the same GPU accelerated dev environment with near unlimited RAM and hundreds of CPU cores, none of this hardware is local so you can code on the balcony/beach on your MacBook Air, light and easy to travel with.

We put VMs in the same country as our staff so latency has never been an issue

This is the dev setup I’ve wanted for ages, and it’s a joy to use

What do devs who don't use VSCode do to work in this environment?

VScode devcontainer can build from existing Dockerfile. You can develop the project image as usual, and then reference the Dockerfile from devcontainer.json. This means you can build and run from the command line via `docker` command if needed. The VScode extension just makes this slightly easier.

Not sure how GP's company does it, but that is how I would configure it.

Caveat: the default devcontainer initialization workflow does _not_ create the Dockerfile, only the .json.

At $work we don't use devcontainer.json, but we can launch the development environment image such that you can SSH into it as if it was a regular VM.

We only have one who hasn't made the switch, he works in vim inside the docker container.

I dont actually mind what development environments our devs use, as long as your productivity is up and you get the job done and you are happy. You can use a magnetised needle for all I care, whatever makes you the best version of you.

One option as mentioned in another comment is to use an editor inside the VM itself on the CLI. I've also tried mounting SSHFS directly which can work, though some inotify-type things don't always work.

Do you have any more detail on how you're handling this on a shared host? My understanding is that the base remote containers + remote ssh extensions would require the code to exist directly on the remote host, and then the container to be created afterwards (and bind to the host directory etc). Is this what you're doing?

Yes that's right, the process is:

- clone the repo with git

- Open Cursor (or vscode) locally, click "open remote window" little blue button at the bottom left of the screen

- Navigate to the folder you cloned and press open

- IDE will recognise that there's a .devcontainer inside the folder and pop a dialog saying "Re-open in container", click that. If this dialog doesn't show press "Shift+Ctrl+P" and type "Rebuild" and a menu option "Dev containers: Rebuild and re-open in container" will show up, select that.

- The docker container will be built and you'll be dropped inside it, with the appropriate folder mounts happening automatically. Now when you open a terminal inside the IDE it's a terminal inside the container.

Great thanks for the info, this is along the lines I was thinking. I'm guessing that means you also have dedicated user accounts on the shared host for each developer? I suppose that would be pretty easy to manage with some ansible.

I've always liked the devcontainer approach, and in particular github codespace. But I've wanted to run it on hardware we can buy and manage. This approach sounds like it gets you 95% of the process, just missing a bit of the convenience around env per branch like codespaces can do. But that's hardly a problem really.

Reply on news.ycombinator.com