Are there benefits to running my development environment in a Docker container?

Question

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?

Answer 1

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).

Answer 2

not in one docker container but yes in n docker containers.

While you could - theoretically - assemble your whole dev environment inside one single container, docker was not meant to do this.

Instead you should deploy each service into separate containers, using docker compose, managing your whole infrastructure in one single file, where each service will have its own logfile, userspace, networking, etc.

Let me give you an example, this is a draft of my docker-compose.yml

version: '2'
services:

  myproxy:
    build: myproxy
    container_name: ppproxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    networks:
      default:
        aliases:
          - www.domain1.it
          - www.domain2.it
          - www.domain4.it

  mydb1:
    build: mydb
    environment:
      DB_USER: sdffdssdf
      DB_PASSWORD:  fdsfsdsdf
      DB_NAME: dbanme1
      DB_ENCODING: UTF-8    
      VIRTUAL_HOST: myhost1.net.lan
      VIRTUAL_PORT: 5432

  mydb2:
    build: mydb
    environment:
      DB_USER: ssdfsdfs
      DB_PASSWORD:  sffdssd
      DB_NAME: dbanme2
      DB_ENCODING: UTF-8    
      VIRTUAL_HOST: myhost2.net.lan
      VIRTUAL_PORT: 5432

  www:
    image: myimages/oldservice:v1.1
    container_name: www
    command: /bin/bash /root/launch
    environment:
        VIRTUAL_HOST: www.domain1.it
        VIRTUAL_PORT: 80
    ports:
      - 80
    depends_on:
      - mydb1
      - mydb1
      - myws

  myws:
    build: myjettycontainer
    environment:
        HTTPS_METHOD: noredirect
        VIRTUAL_HOST: www.domain2.it
        VIRTUAL_PORT: 8080
    ports:
      - 8080
    depends_on:
      - mydb1
      - mydb2
      - myproxy
      - mypostfix

  mypostfix:
    image: catatnight/postfix
    container_name: mailer
    environment:
      maildomain: domain1.it
      smtp_user: mymail:sfsfdfds
    ports:
      - 25

There is an nginx proxy (myproxy), two similar postgres databases (mydb1 and 2), an old java web application server (www), a java jetty container that provides a rest web service and finally a very simple SMTP postfix container.

Everything starts up - usually :) - with docker-compose up, either on my dev machine or in production; log files are aggregated into one easy to read file and it is possible to replicate locally almost every functionality with the guarantee that, if it works on my laptop it will work.

Answer 3

I use VirtualBox VMs for this kind of thing.

The portability of having your dev environment in a container is handy, but the really nice thing is that I can snapshot the thing before any upgrade attempts, and if I screw it up, it's no problem to fall back and start again.

I also find it helpful to do this because I frequently work with multiple versions of things like Qt, and I don't feel like figuring out how to get the two versions to co-exist - instead, I just put them on different VMs and I don't have to worry about interactions because I installed something incorrectly.