templates: Dockerfile missing?

Hi @bherbruck 👋

Recently, we have modified the “Add devcontainer configuration files” command to make it more simpler and easier to understand. We have updated the Templates and built the dev container config using Features (which avoids the need of Dockerfile in most cases).

We still have few Templates which consist of a Dockerfile (eg. cpp, anaconda)

Is there some new functionality that deprecates this way of working with devcontainers?

No, it’s more of a design change 😄

ℹ️ Look how the java Template got simplified which looks more clean and utilizes the Features - old config vs new config.

FWIW - I would not recommend going to the trouble for basic things that you can do in a Dockerfile like doing apt-get install. RUN apt-get update && apt-get -y install <blah> is about as simple as it can get. Features are primarily focused on reusable chunks of config and code that Dockerfiles alone cannot provide.

All you need to do is switch "image": "<blah>" to

"build": {
    "dockerfile": "Dockerfile"
}

and add FROM <blah> to the top of the Dockerfile to switch to one.

But - if you’re going to reference a shell script in your Dockerfile anyway, a local feature is probably just as easy.

That said - We flipped to using image, but I think there’s probably a good question here as to whether that is more or less confusing than what was done in the past. The Dockerfile did provide a very easy want to do certain things. Definitely worth tracking the feedback.

Perhaps this should be moved to the templates repo as a proposal to track upvotes?

@andreujuanc That would end up being specific to the Dev Containers extension I suspect since it would need access to your local machine and docker would have to be installed. But we could do that in concept - or we could just have an option to enter an image name as a starting point.

I do think it would be pretty easy to automate the process of an image reference getting converted into a stub Dockerfile or Docker Compose file here as a part of the UX. @burkeholland also mentioned being confused by them not being present, and it impacts docs and samples.

@andreujuanc makes a lot of good points. When working in any higher-level language with C-bindings it is common to require external packages. Relying on a list of features can be handy if we need to run shell scripts during docker build, but for just installing packages…

I too have spend considerable time trying to install a list of packages in my own features, doing it in a json string in the devcontainer.json file is not easily maintainable.

Many already know docker. Adding another statement to RUN apt-get install my-packages is trivial and second-nature. Developing and debugging our own feature is time consuming (especially when permissions come into play).

Yes, it is possible. We have posted guidance in here - https://containers.dev/implementors/features-distribution/#addendum-locally-referenced

You could take advantage of postCreateCommand to install packages.

Eg. -

• "postCreateCommand": "npm install -g @devcontainers/cli"
• "postCreateCommand": ".devcontainer/.postcreate.sh"

I also forgot to mention that most of the time I reuse the same dockerfile for my devcontainers, my cicd, and my k8s. So that way I know that my app will run 100% of the time.

More again, in a lot of company like the one I work for are using internal Debian/docker repository and have to manage network specific stuff that make feature almost totally unusable. Devcontainer is great but now they try to PIMP it so much that maybe the dream is to have developers that cannot handle their own system. Not my choice

Features are not portable and they are faraway less powerful than docker. My choice is done. Feature are just a script that can execute on every machine. I will never develop a such tool. If the tool is there and work maybe I will use it but I will manage to prepare a fully working development image with all my team tools. More also, feature like docker-in-docker are taking a while to install at devcontainer creation. Providing those software in a docker image costs nothing. Cheers

Just to clarify, Dockerfiles are still fully supported. It’s just more an an advanced use case, and we don’t want people to have to be Docker experts in order to start using Devcontainers. We believe that devcontainer features make it easier for people to add and maintain functionality in their configuration and encourage the use of features as a starting point. But if you have a scenario that needs more flexibility/control, you can certainly add a Dockerfile.

No, now you want people to be “feature” expert, and remember names, find exactly the thing they want. A simple “switch” to go back to the previous behavior should be released now. I’ll give you an example:

Just yesterday a colleague asked me a favor to help him fix a piece of python code, I use devcontainers exclusively and I went ahead and created a python one. And whilst installing the dependencies I noticed I had to add libodbc.so.2. Then I spend 30 minutes trying to figure out what feature has that and changes else so no other dependency breaks. I didn’t manage, and had to manually create the DevContainer file.

Why was it so hard to keep the previous option whilst adding the new features on the side? Why the push towards “programming a json file”, isnt better for everyone to understand how your dev environment work if they want?

I know Dockerfiles are still available, but the wizard to create them was REALLY nice, and now I have to manually map things.

But hey,maybe the top post’s reactions might give a clue.

Cheers

Can we get an option to add a dockerfile that exists on local? So if I had done docker pull node:latest then when I run the VSCode command to add a devContainer to it there could be an option that shows “locally available images” and so I can just chose from there. 😄

Just to clarify, Dockerfiles are still fully supported

These docs will be helpful if you’d like to augment our existing templates with a Dockerfile.

https://containers.dev/implementors/json_reference/#image-specific

Just to clarify, Dockerfiles are still fully supported. It’s just more an an advanced use case, and we don’t want people to have to be Docker experts in order to start using Devcontainers. We believe that devcontainer features make it easier for people to add and maintain functionality in their configuration and encourage the use of features as a starting point. But if you have a scenario that needs more flexibility/control, you can certainly add a Dockerfile.

Do we now need to make our own devcontainer features to do this?

Creating your own Feature and sharing it with the community is a great thing to do, we highly appreciate that. You may want to look at currently available features here.

Thanks for the explanation @samruddhikhandale!

Is there any documentation for installing packages with apt or for doing things like adding global npm packages? Do we now need to make our own devcontainer features to do this?