Dockerfile missing?

[bherbruck]

It seems after v0.16x.x Dockerfiles are no longer included in the .devcontainer directory when using vscode's "Add devcontainer configuration files".
These are critical for installing extra packages and customizing the development environment.

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

.
├── .devcontainer
│   └── devcontainer.json
|       <-- Dockerfile used to be here
├── package.json
└── src
    └── index.js

[samruddhikhandale]

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.

[bherbruck]

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?

[samruddhikhandale]

You could take advantage of postCreateCommand to install packages.

Eg. -

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

[samruddhikhandale]

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.

[jkeech]

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.

[joshspicer]

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

[bherbruck]

Thanks for all the clarification on this, is it possible to use local/relative "features" rather that importing from a public registry/repo?

So if we wanted to do something like:

"features": {
  "./install-lots-of-packages-and-do-lots-of-stuff": {}
}

[samruddhikhandale]

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

[Chuxel]

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]

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. :D

[Chuxel]

@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]

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

[bherbruck]

@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).

[7d4b9]

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

[7d4b9]

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

[andreujuanc]

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.

[eitsupi]

If the goal is simple installation of packages, I think it easier to use Features for installing any package instead of writing a Dockerfile.

For example, here is a Feature to install any package with apt-get -y install --no-install-recommends, which has been downloaded quite a few times.
https://github.com/rocker-org/devcontainer-features/tree/main/src/apt-packages

It appears to be used as follows:
https://github.com/igraph/igraph/blob/925f5243fc0c8dd58fc34cfbe01ca4480f042355/.devcontainer/devcontainer.json#L7-L14

Compare this to installing on a Dockerfile, which has the advantage of not having to worry about options like --no-install-recommends and deleting caches (e.g. by rm -rf /var/lib/apt/lists/*).
Also, if we install on a Dockerfile, we have to modify all Dockerfiles if we need to modify a command, whereas a Feature is distributed from a single location, so we only have to modify one location.

On the other hand, if the installation involves importing a gpg key instead of a simple installation like this, it may be more flexible to write it in a Dockerfile.

(As a side note, the apt-packages Feature is very common and I think it should be in https://github.com/devcontainers/features, but there was no sign of it being registered in there (devcontainers/features#67) and it was needed in https://github.com/rocker-org/devcontainer-features, so I am maintaining it in https://github.com/rocker-org/devcontainer-features.)

[andreujuanc]

If the goal is simple installation of packages, I think it easier to use Features for installing any package instead of writing a Dockerfile.

You think is easier, but consider someone who needs to search and find the correct feature for what they need.
I think the "linux" community have more content than the "feature" community, hence, easier to find solutions.

For example, here is a Feature to install any package with apt-get -y install --no-install-recommends, which has been downloaded quite a few times. https://github.com/rocker-org/devcontainer-features/tree/main/src/apt-packages
Might be a hot take, but if you are developing inside a linux container, you should be familiar with the apt-get command, at least.

I understand we are trying to abstract things out, but then we must not forget about the "advanced" use cases, which is what we are arguing here. We are not asking for the "features" to go away, but to at least have an option to rollback to the previous behaviour.

Compare this to installing on a Dockerfile, which has the advantage of not having to worry about options like --no-install-recommends and deleting caches (e.g. by rm -rf /var/lib/apt/lists/*). Also, if we install on a Dockerfile, we have to modify all Dockerfiles if we need to modify a command, whereas a Feature is distributed from a single location, so we only have to modify one location.

If you have 100 projects using that feature, it will have to be re-run in all containers, on the other side, if you have a dockerfile you just need to download it. Done.

The problem here is that when a developer has a problem, it will have to search how to fix it with a feature, or, instead run a custom command, will will increase in size anyway with time. So just keeping the scripts within the dockerfile makes the most sense. Publishing docker images is also a thing, so people can reuse them within the org.

[bamurtaugh]

Hi everyone! Thanks so much for the discussion and honest feedback so far, as this is incredibly helpful to shaping the dev container spec and its resources.

I've opened an issue to discuss this topic and potential solutions: #135. Please feel free to share your thoughts there, we'd really appreciate any and all feedback. Thank you!