Dev containers
Developing inside a Container using Visual Studio Code Remote Development
Dealing with problems
Every so often my dev container processes I am running just completely fall over - help!
Is this running Webpack hot-reloading?
This is probably because your dev container is running out of memory and is silently crashing. This is particularly likely if we are using Webpack, as Node.js based setups are very memory intensive in containerised environments.
Dev containers use Docker under the hood.
On Mac OS X, Docker is set by default to use 2GB of memory. This isn't much!
You can increase this by changing your settings in Docker. Navigate to Preferences in the Docker menu item, select Resources and increase Memory, Swap and CPUs as you see fit. If development is the only thing you are doing, it probably isn't too bad to let Docker use all your system memory if it needs to. Containers will then be blazingly fast!
Docker Desktop for Mac user manual
My dev container feels a bit sluggish, is there anything I can do about it?
Dev containers use Docker under the hood.
On Mac OS X, Docker is set by default to use 2GB of memory. This isn't much for today's memory hungry applications and certainly isn't enough for really rapid development, where shaving seconds off a feedback loop is quite important. Fortunately we can fix it very easily.
You can increase this by changing your settings in Docker. Navigate to Preferences in the Docker menu item, select Resources and increase Memory, Swap and CPUs as you see fit. If development is the only thing you are doing, it probably isn't too bad to let Docker use all your system memory if it needs to.
Docker will need to restart and then dev containers and containers in general will then be blazingly fast!
Docker Desktop for Mac user manual
My dev container used to work flawlessly, now I am not seeing one or more of them not work.
For example, the Webpack DevServer is not coming up so I can't see my CSS and JavaScript in a Wagtail project.
Dev containers interact with the wider Docker based ecosystem on your machine. Sometimes this causes problems.
For example, if you have a Docker container already bound to port 8080 for another project - the default port DevServer launches on - VS Code will not be able to bind port 8080 and serve your assets. Sadly, this will fail silently.
To fix this, you need to work out what is running on this port and stop it. Running docker ps on the command line will show running containers on your machine. You will be able to see if one binds to a port VS Code also want to bind to, in our example, port 8080.
docker kill followed by one the container ID of the container bound to the port that is needed will help you stop these containers until VS Code has a space to launch into.
If you want to ensure this, run docker kill $(docker ps -q) to kill all running containers before using VS Code dev containers.
Other non-Docker processes might be binding a port VS Code dev containers want to use. You might need to find and stop this other process.
There are several ways to work backwards from a port to kill a process.