Development Containers - the fine print
Development Containers are supposed to liberate your development environment from a specific local installation, like container technology liberated your runtimes (a.k.a YAMLed them into Docker or Kubernetes).

Development != Runtime
Containerization for development has some overlap and quite some difference to containerization for production:
| Topic | Development | Production |
|---|---|---|
| Mutability | You alter container content | Container is static |
| Network | Use internal network | Use internal network |
| Access | Developer tools++ | Browser / App |
| Containers | multiple | multiple |
| Volumes | primary container binds projectdir all others mount only |
all: bind or mount |
| Configuration | devcontainer.json, docker-compose.yml |
docker-compose.yml,Helm Chart |
| Scope | Runtime & Tooling | Runtime |
| Dockerfile | Setup development environment | Configure production |
Insights
- There are many getting started resources available: here, here, here, here and here. They are working examples, commonly strong on what and how, but light on why
- There are plenty of templates to learn by example
- There seem to be substantial differences how it works on different platforms, subtle and annoying
- On macOS (14.4.1) with with the devcontainer plugin 0.364.0 mount binds would not work in auxiliary containers, only in the main app
- I couldn't find any descrption which subset of
docker-compose.ymlis supported - The most interesting templates, for now, live on the Microsoft Artifact Registry, when you know how to look. Starting with those saves you tons of time and frustration
- You will love
code --list-extensionsto figure out the extensions you have in your vscode (unless you are a code n00b and don't have any)
Read more
Posted by Stephan H Wissel on 12 May 2024 | Comments (0) | categories: Container Docker Java NodeJS WebDevelopment