Using an IDE while developing on a docker container

Question

There is something that I am not getting when developing an application while using docker containers.

Lets say I am developing a java application and I set up a java container with jdk 8 base image, I still need to install java 8 jdk on my local development machine, since the IDE which I am going to use is going to look for runtime libraries on the local machine not the docker container.

Is this right or am I missing something? Somethings I will be able to do entirely on the docker container like setting up a database but some things I will also have to do on my local development machine and try to match it up with my docker image for example a language runtime like java or python for the sake of using the IDE.

Solution 1

Updates:

• 2018/04/17: http://docker-sync.io/
• 2018/03/18: Check skaffold from GoogleCloudPlatform.

---

Original post:

There is something that I am not getting when developing an application while using docker containers.

It's ok, this is not something trivial. Try to see the big picture, it's about creating a Development Pipeline (or CI/CD Pipeline if you like to use the terms Continuous Integration/Continuous Delivery).

The above image is from [2]

Limitations when setting-up a local dev environment

Lets say I am developing a java application and I set up a java container with jdk 8 base image, I still need to install java 8 jdk on my local development machine, since the IDE which I am going to use is going to look for runtime libraries on the local machine not the docker container.

This is an option that may cause you a problem already mentioned: it may work on your local dev environment and fail elsewhere because you forgot adding a library, a dependency, a minor change that you did without paying attention and keeping in mind to add it to your docker environment.

You can stick to docker while developing

An approach that solves the above problem is to rely on docker^[3], in order to set-up the environment you want to use. This means that every time you change something, you will have to docker build a new image and docker run a new container based on this image. As others have mentioned, to define how your images are going to be built you will have to use Dockerfiles. And if your app has different interconnected containers you will have to define all these (networks, links, dependencies) inside a docker-compose.yml file. The repetitive process of building and running will then be your IDE's job...

IDEs & plugins/add-ons

from [1]:

IDE

Docker versions do not provide a native IDE for developing with Docker. The primary interface is the command line API. However, most leading IDEs (NetBeans, Eclipse, IntelliJ, Visual Studio) have some support for Docker through plugins or add-ons.

For example, from [2]:

Docker Labs - Developer Tools Tutorials

You can find some guidelines depending on your case (IDE, language...) here:

• github.com/docker/labs/tree/master/developer-tools

Shared Volumes | Hot reload | "watching" for file changes

I think this approach matches with your title saying "developing on a docker container" and I mean/understand the case where someone has a running container with a shared volume and whenever a change happens in the code (using the IDE), this affects the container directly. Maybe this will work for a case and have limitations for some other cases. It is up to you to make your assessments and choose your path.

My sources are:

• [1] Docker Reference Architecture: Development Pipeline Best Practices Using Docker EE
• [2] Exploring Docker in CI/CD
• [3] What is a Container? video from VMware Cloud-Native

Solution 2

You have the option to run the IDE as a docker container as well, so you don’t need to install anything on your machine.

To do so, you need:
- docker
- X11
- an IDE of your choice.

Take a look at this java project which runs java8 and gradle inside an IntelliJ IDE:

https://github.com/marioluan/java-data-structures

The setup is pretty straightforward:

Dockerfile

FROM openjdk:8-jdk-alpine

# ttf-dejavu is required to render GUI under X11: https://github.com/docker-library/openjdk/issues/73
RUN apk --update add --no-cache ttf-dejavu

# install intellij
RUN wget -O /tmp/idea.tar.gz https://download-cf.jetbrains.com/idea/ideaIC-2017.3.4.tar.gz \
    && mkdir -p /usr/share/intellij \
    && tar -xf /tmp/idea.tar.gz --strip-components=1 -C /usr/share/intellij \
    && rm /tmp/idea.tar.gz

docker-compose.yml

version: '3'
services:
  intellij:
    build: .
    environment:
      - DISPLAY=$DISPLAY
    volumes:
      - /tmp/.X11-unix:/tmp/.X11-unix
      - /your/workspace:/tmp/your/workspace
      - idea_cache:/root/.IdeaIC2017.3
      - java_cache:/root/.java
    working_dir: $APP_ROOT
    command: /usr/share/intellij/bin/idea.sh
volumes:
  idea_cache:
  java_cache:

Comments

[tiagoboldt]

Only because you can, it doesn't mean it is a good idea. The entropy introduced by developing inside docker containers largely outweighs its advantages.

[Mario Souza]

They wanted to avoid having to install libraries on the host, not reuse them in Docker.

[Mario Souza]

Well, that’s up to whom is making the choice.

[guettli]

@tiagoboldt. Could you please explain what you mean with "entropy introduced by ...". Because I think the solution is good. I guess I am missing something.

[emory]

@guettli I am not sure what tiagoboldt meant but my general observation is that it is a very good idea when your host system is linux but when your host system is mac or worse windows you are actually running docker on a linux virtual machine and your X11 sucks. It is passable for somethings but for running gui app containers it is gross.