Language image vs OS image with language feature

[alefteris]

I understand that there are two approaches to create a devcontainer for a single language nowadays:

1. Pick a language image from the devcontainers/images repo. Those images are usually based on a docker hub official image for the language, like the node, golang or python images. Those are build using the feature for the language, but with the installation of the language disabled (as it's already provided by the docker hub image)
2. Pick an OS image from the devcontainers/images repo. Then add the required language using a language feature from devcontainers/features. For example, to create a devcontainer.json for Node.js, use mcr.microsoft.com/devcontainers/base:debian-11 as the base image and the ghcr.io/devcontainers/features/node feature to install Node.js and other related goodies. Probably also add some additional features like common-utils, git etc.

What are the benefits and downsides of each of the above two approaches?

Thanks

[Chuxel]

Advantages of starting from an language image:

• Starting from an image like node gives you the opportunity to use that same base when you deploy your app in a container - which improves in consistency. The is the primary reason the mcr.microsoft/devcontainer images flow this pattern. They are the language images + some additions in another layer.
• Some languages like Python can be surprisingly hard and/or slow to install in some cases. While Dev Container Features abstract this complexity away, it can still take a while to execute. Starting from python speeds things up. That said, if you are pre-building your images, this isn't quite as big a deal.

Advantages of starting from an OS image:

• If you prefer to use Ubuntu over Debian, you'll typically need to start from an OS image. Most Docker Library base images are Debian (or Alpine) based.
• While not every Feature supports every Linux distro, other OS bases will likely be better supported over time as well. For example common-utils now supports Alpine and RHEL-based images (e.g., Rocky Linux or Fedora).
• If you've already got a Dockerfile or custom image you are happy with that starts from an OS image, Features can allow you to add whatever you may need.
• If you are looking for consistency for where things are installed across different images, Features will generally ensure they're in the same spot when you use a pure OS image as a base.

In either case:

• You can get deployment and Dev Container image consistency using a multi-stage Dockerfile to wire things together. More info here.

That help?