Of a devcontainer, or a Rails app Dockerfile? I've built many Rails apps in Docker, and there's a lot you have to add. To utilize devcontainers, I feel like it would need to include a lot of the boilerplate that is missing here. You could roll your own, but I think that would strongly impair devcontainer adoption industrywide.
These are just starter templates, they are supposed to be bare. If you think there are some other standard things that ought to be included I am sure they would appreciate the Issue or PR.
Of course, but even a bare Rails Dockerfile would include much more than this, and pretty much every Rails app built off of this would be including much of the same boilerplate.
I work in a Windows centric industry and devcontainers were a complete game changer for our productivity. One click and you have a newcomer's development environment ready, locally. Gone are days I had to teach folks how to install PostGIS, or help them because their version of libfoo was wrong.
When we started, in 2020, there were many rough edges both in the extension and WSL2, but the experience got remarkably better over time.
You have automatic tooling configurations and a consistent developement environment that you can expect to run anywhere. Basically Microsoft Intune done right for programmers.
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 see it as being similar to the relationship between Vagrant and Virtual Machines.
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
It's integrated into vs code and nearly transparent. Like they said, someone new to a project can just open the IDE and their environment is automatically setup vs. spending days installing tools from a (likely) undocumented and out of date process.
Again, it's integrated in vs code and GitHub codespaces. If you open your project in vs code it detects the devcontainer config and automatically launches the container using docker, connects vs code remotely to code in the container, and pops open any terminals or tool executions in the container.
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.
We started with plain Docker Compose files (one container for our project, others for DB, Spark, Airflow, etc.). For more experienced, full-time developers this setup was good enough (though it required a few extra steps after `docker compose up`).
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.
have you even looked into devcontainers? If people build a docker wrapper just to give you the exact things docker can do, that would be ridiculous wouldn't it? A cursory view of the devcontainer website will reveal that vscode is mentioned a bunch of times
I never suggested such a thing, I wanted to know why it's better than just Dockerfiles and it seems vscode integration. Everything else can be achieved with docker, compose and/or makefiles.
I use these every day and here's some things I like:
* 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
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.
I’m not across the Microsoft ecosystem but why is it (that people say) it’s so difficult for people to setup their dev environments? Is it something to do with running windows or is it a .net thing?
This is about containers .. so primarily about running a Linux dev environment in a container. https://containers.dev
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.
But surely if your code base is that difficult to setup your dev environment for - it’s likely a sign of much bigger problems?
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.
> But surely if your code base is that difficult to setup your dev environment for - it’s likely a sign of much bigger problems?
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.
> > But surely if your code base is that difficult to setup your dev environment for - it’s likely a sign of much bigger problems?
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.
> 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.
>> 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.
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
Oh yes, dev containers work wherever docker and vs code work. If the production environment is Kubernetes, though, I prefer to develop with Kubernetes or minikube, to better align with production behavior.
Compared to say 10 years ago, now days devel environments are made up of stacks of modules that you have to hand configure. 10 years ago a LAMP server involved hopping on a Ubuntu server, paste in an apt command from a website and off you go.
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?
It’s probably been about 10 years since I’ve had to run any php, would you not just clone the repo and run whatever the modern equivalent of php-fpm+Nginx is in a container passing in the code as a volume?
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 do not know why someone shared this repo, there is nothing special about it other than containing some start templates. I would start here for understanding Dev Containers: https://containers.dev
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.
I usually put my code into a volume and use bindfs to read/write that volume from the host as a regular user (with vscode, vim, whatever). It prevents ownership conflicts since files in the volumes are owned by root/www-data/whoever. VScode can be configured with a mapping between running code in the container and accessible code in the host so xdebug breakpoints are set on the host in vscode and when xdebug calls back vscode it gets xdebug data and displays it on the host.
I don't know what "run VSCode as a server" is supposed to mean in this context, but there are other comments in this page that suggest the integration between dev containers and vscode is pretty good, e.g. opening a terminal is just scoped to that container by default, etc.
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.
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.
I love devcontainers, I just wish performance was better on Apple M* chips.
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.
When will we see some usable containers for Windows from Microsoft? You can't use Nano or Core for building C++ code with Visual Studio / MSBuild, so you're bringing down the whole Windows container (3.4Gb compressed) which is effectively as heavy as a full VM.
58 comments
[ 3.4 ms ] story [ 137 ms ] threadhttps://github.com/devcontainers/templates/tree/main/src/rub...
I would however add in the Postgres libs
When we started, in 2020, there were many rough edges both in the extension and WSL2, but the experience got remarkably better over time.
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.
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 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...
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.
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.
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 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
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.
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.
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.
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.
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
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 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 ?
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.
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.