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