Docker – Benefits of Running Development Environment in a Docker Container

docker

I develop primarily using Visual Studio on Windows. The problem is that after a while Windows gets bogged down and I'm faced with needing to reinstall Windows. Similarly switching to new machines is a problem.

Reinstalling Windows is painful because my development environment has a lot of dependencies (such as extra MSBuild configuration files, VS extensions, npm, Java etc). I don't imagine I'm alone in having a complex system, and setting it back up would probably take a day minimum.

I've not really used Docker, but in theory it sounds like I could setup my dev environment in a Windows Container and then just ship it around (eg. copy to my laptop, put in a new Windows install) and it should be painless.

Is what I'm describing possible? Are there any downsides, such as performance, reliability? Other gotchas?

Best Answer

This is not an uncommon problem, but Docker isn't really the right tool to solve it. Containers in general (including Docker) are intended to provide an application runtime for a single process, such as a web server, not for a multi-process scenario such as a dev environment. In can be done, but isn't a very elegant solution.

A better (and more common) approach is to create VMs either through a traditional hypervisor such as VirtualBox or Hyper-V (since you're on Windows). A typical workflow is:

Find or create a base VM image based on your preferred OS flavor. This can be done directly with the installer ISO, or someone in your workplace may have one already.
Once the base image is built, add in all the dev tools and settings that you need. Snapshot or save this as a separate image.
Now you can run this image, RDP or remote into it, and work until you get to a point where you "get bogged down", and then just save off the files you need (commit to source control, etc.), then blow away the image and start again from either of the two snapshots/images you created. This can be done in seconds, vs. up to a day the old-fashioned way.
At any point along the line, create additional snapshots when you encounter situations that you might want to rollback to in order to reproduce a problem, etc.

Vagrant is also a fantastic tool for doing much of the above in a more structured manner.

A side benefit of all this is that you now have standardized environments that can be shared with your whole team, saving everyone the effort. This is especially great for quickly on-boarding new people.

Back to your original question, Docker isn't really intended for this, but if you had a small enough dev environment (say PHP on Linux), you could do it in a container, and the benefit would be a much smaller image (potentially under 100MB vs many GB for a Windows VM with virtual disk).

I can pull safely the alpine image and indeed get the official image?

When you pull from the Docker Hub (Official Repository) you will get the official Alpine image.

My images are only based on the "official" images, I do not need a local registry?

Images are just layers. If all your images are based on official public images you will not need use a repository (Docker Hub or on-premise). But, a good practice is create a base image. This image is created from a Official Image plus your enterprise customizations.

Example:

mycompany/alpine-custom:latest

In this particular case, if you want to keep your image private and on-premise. You can use a internal registry. If you want to keep your image private, but on the cloud, Docker Hub private is also an option.

What is the advantage of having a (local) registry with ready images in a deployment scenario over building the image on the host off the baseimage (e.g. alpine) and create a new one on the host with few additional git checkouts of code to deploy?

When a application is ready for deployment, you create a package with all dependencies. You build the application before releasing. Is the same principle. It is better to have a static image prepared to production. It deploys faster and has less chance to download an incompatible dependency version or have a network failure.

When does it make sense to pull full images from a (local) registry instead of building on the host? And then: why not using dockerhub private repositories for that?

The chose between cloud or on-premise repository evolves aspects like: security, performance, reliability, costs, network availability, etc. Each scenario has its own particularities. Usually use DockerHub private is OK for majority of scenarios.

For instance:

You have to follow regulations that imposes to not use cloud platforms.
You use Docker for private processing and your network does not have access to the Internet.

Is good to thing about the Container Workflow:

Layer one:

Pull base
Build image-a
Push image-a

Layer two:

Pull image-a
Build image-b
Push image-b

Deployment:

Pull image-b
Run image-b

Php – Why place Composer in separate docker container

This is called a multi-stage build. It’s used to keep both the final image size and numbers of layers to a minimum. This results in less network traffic and a faster spin up time on machines where the image hasn’t been downloaded yet.

Best Answer

Related Solutions

Docker – Advantages of Running a Local Docker Registry

I can pull safely the alpine image and indeed get the official image?

My images are only based on the "official" images, I do not need a local registry?

What is the advantage of having a (local) registry with ready images in a deployment scenario over building the image on the host off the baseimage (e.g. alpine) and create a new one on the host with few additional git checkouts of code to deploy?

When does it make sense to pull full images from a (local) registry instead of building on the host? And then: why not using dockerhub private repositories for that?

Php – Why place Composer in separate docker container

Related Topic