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.yml
is 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-extensions
to 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