Microsoft Docker Development Container Templates
github.com
github.com
When we started, in 2020, there were many rough edges both in the extension and WSL2, but the experience got remarkably better over time.
But it still showed significant friction for (a) very junior developers (b) non technical business people who wanted to code. Generally the same folks that would need help installing PostGIS on their machines, etc. People just wanted to merge some cool ideas into our codebases and now they needed to learn wtf Docker and Docker Compose are[1]. That was a huge time waster.
Devcontainers are neatly integrated into VS Code's UI, so they solved the "last mile" problem of allowing non-tech folks to use containers.
[1] https://www.youtube.com/watch?v=AbSehcT19u0&themeRefresh=1
You can use plain Dockerfiles if you prefer, dev containers provides some tooling to smooth out the rough edges of using Docker to host your dev environment including mounting your source code into the container etc. Details are at: https://containers.dev
* You can add a docker compose file as well as a docker file. This means that all of the services you want to exist (postgres, redis, etc) don't have to be separately installed/updated by each developer on the team.
* Good vscode integration. It doesn't feel like you're developing inside a container. You open a terminal, and its inside your containerized dev environment.
* "Features" (https://containers.dev/implementors/features/ ) which allow you to quickly add functionality to your dev containers. For example, when I want to add the terraform CLI, I add the corresponding feature to the devcontainer.json.
* At the end of the day it's all built on docker, docker-compose, etc so there is minimal lock-in to vscode
You can do exactly what you're saying--have a dockerfile as the source of truth--right now. And you can install the devcontainer CLI and use it outside vs code if necessary too: https://code.visualstudio.com/docs/devcontainers/devcontaine...
However
> vs. spending days installing tools from a (likely) undocumented and out of date process
This makes no sense, that is not an advantage over a dockerfile.
On GitHub codespaces it gives you a button on the website that is literally one click and get vs code in the browser connected to your dev container launched in their cloud--you don't even need vs code or anything installed and can code from a tablet for example.
If you think about it Nix Flakes shares the same philosophy. But flakes, as from my experience a year and a half ago, are ergonomics-wise terrible.
I love dev containers and do all my work in them. I often start from the above images and then add more, like adding postgres in the container. If you are looking for examples, nearly all the repos linked from https://github.com/pamelafox have dev containers. Mostly for Python backed web apps.
It'll start up everything for regular dev, supports live reload, and will put in proper waits while your environment gets into a ready state.
https://github.com/devcontainers/templates/tree/main/src/rub...
I would however add in the Postgres libs
Do you really have nobody on your team who doesn't use vscode.
But... I don't think you have a good understanding of the feature if you're making that comment. Most people that use dev containers just have a dockerfile or docker compose file in their project and point the dev container config at it directly. Anything can use that dockerfile, it's not special in any way.
Granted, it’s not really a problem with devcontainers as much as it is with docker mounts. But that makes devcontainers terribly slow when the code is on the local file system and mounted into the devcontainer, which is the default.
I checked php and didn't see much, I didn't see xdebug for instance.
What am I missing ?
If you have a scenario where using a container as your development environment makes sense, this is some tooling that can improve the developer experience vs just using plain Docker and Docker Compose.
This is essentially how Codespaces works too, fwiw.
Would codespace solve that more elegantly ?
Codespaces is where I use them but it is supported by VS Code and can be used locally or in other scenarios as well. It mainly improves DX over using bare Docker for running your developer inner loop. Yes you can do this yourself using Docker and docker-compose if that is your preference.
After not doing any devel in years I was trying last week to do the modern equivalent (nginx + php) and literally none of the guides online ended up with a webserver that processed php, which I eventually figured out was every single tutorial I tried was giving the wrong code at the step where you have to manually edit the nginx configuration file, because you have to declare the php version there and Ubuntu apt installs a more recent version, so nginx can't find it. Previously the linking between webserver and php 'just worked', now it's all manual and there are no breadcrumbs for non-experts when things break
So a reasonably simple server has a qualified engineer confused for few hours, what hope does anyone have for something more complex?
Or if you’re not using containers at all run the language’s app server? (E.g. an equivalent of <node serve index.js> / <go run app.go> / <python server.py> / <rails serve> etc…)
I would guess the Microsoft angle here is to make the process smooth for a developer running VS Code in Windows to develop in a Linux container from Windows. I personally use it in Codespaces, so there is also the cloud developer environment aspect of it.
Nothing about this is Microsoft or Windows-specific.
Saying "nothing" is overstating the case. In a corporate shop of the common sort where everything is Windows and Azure, even the developers will have Windows on their daily development box.
When the company starts to deploy on docker & Kubernetes in Azure (whether or not that's a wise decision), the Windows environments are going to have a tough time because most tools for the container world are Linux-centric. It can work passably on a MacOS system, on Windows it's a completely different picture.
Giving developers VS Code with a pre-configured environment eases the migration.
> Saying "nothing" is overstating the case. In a corporate shop of the common sort where everything is Windows and Azure, even the developers will have Windows on their daily development box.
I meant that Dev Containers are not Windows-specific. They are probably used on MacOS just as much as Windows and you could also use them if you worked natively on Linux. I just did not want a reader to get the impression this is only for devs working on Windows
The reason I asked about windows was because a few folks here said it is helping them with their windows dev environments, where as in my experience with software you’re developing for *Nix it’s not really a big deal. Usually you’re just checking out the repo(s) and running your languages command to install the libs.
I think it less about difficulty and more about when you have a desire to run your dev environment in a container. How are you getting your source code into the container? How is your editor accessing the source code to make changes etc. Dev Containers provides a pattern to follow for doing this that works across tools and OS that can simplify it for your team.
If you work on a large team where devs work on the OS and Editor of their choice it can also simplify the development docs and environments you need to maintain. You can develop things like Node, Python, Ruby natively on Windows but if you are deploying on Linux, especially if in a container on Linux, having the dev environment running in Docker has advantages and there is less for the developer to setup and maintain.
You're misinterpreting ease of setup as a solution to "it's difficult", from what I assume is a bias; the two are not the same coin. Docker based development, which is what devcontainers is a template for, works in Linux too and is a useful way of having everything ready to go. You can of course put instructions in a README, this is one step further than that which is to prepare a docker image.
> where as in my experience with software you’re developing for Nix it’s not really a big deal. Usually you’re just checking out the repo(s) and running your languages command to install the libs.
That isn't entirely true about nix environments, or it depends which *nix environments you mean. On Linux, yes it can be pretty much clone and go (install dependencies where needed). A very "close 2nd" is WSL2 on Windows as it's also just... Linux. On Macos you need to perform a series of brew gymnastics to get the environment into shape because all the included defaults are practically insults. If you're considering that clone and go, then you might be doing it so frequently that you don't equate it to a difficult to set up environment. However even on Linux, it depends on the kind of development you're doing, because if you've ever worked with Cuda/Torch/Tensorflow, then you know that isn't necessarily a smooth experience but has to be carefully controlled.