Workflow with docker in the development environment

Question

I have a couple of questions related to the usage of Docker in a development environment. I am going to propose three different scenarios of how I think Docker could be used in a development environment. Let's imagine that we are creating a REST API in Java and Spring Boot. For this, I will need a MySQL database.

1. The first scenario is to have a docker-compose for development with the MySQL container and a production docker-compose with MySQL and the Java application (jar) in another container. To develop I launch the docker-compose-dev.yml to start only the database. The application is launched and debugged using the IDE, for example, IntelliJ Idea. Any changes made to the code, the IDE will recognize and relaunch the application by applying the changes.

2. The second scenario is to have, for both the development and production environment, a docker-compose with the database and application containers. That way, every time I make a change in the code, I have to rebuild the image so that the changes are loaded in the image and the containers are launched again. This scenario may be the most typical and used for development with Docker, but it seems very slow due to the need to rebuild the image every time there is a change.

3. The third scenario consists of a mixture of the previous two. Two docker-compose. The development docker-compose contains both containers, but with mechanisms that allow a live reload of the application, mapping volumes and using, for example, Spring Dev Tools. In this way, the containers are launched and, in case of any change in the files, the application container will detect that there is a change and will be relaunched. For production, a docker-compose would be created simply with both containers, but without the functionality of live reload. This would be the ideal scenario, in my opinion, but I think it is very dependent on the technologies used since not all allow live reload.

The questions are as follows.

• Which of these scenarios is the most typical when using Docker for development?

• Is scenario 1 well raised? That is, dockerize only external services, such as databases, queues, etc. and perform the development and debugging of the application with the IDE without using Docker for it.

The doubts and the scenarios that I raise came up after I raised the problem that scenario 2 has. With each change in the code, having to rebuild the image and start the containers again is a significant waste of time. In short, a question would be: How to avoid this?

Thanks in advance for your time.

Answer 1

We use kubernetes / minikube rather than docker-compose, but its the same problem. We generally go with option #1 as:

• Development is 99% getting the app right.
• You want to be able to iterate fast/freely with your app.
• You want easy use of your debugger / IDE without inhibition.
• It lets you avoid configuring / managing remote debuggers from within the docker container.
  • If you did this in the container, you'd have to worry about making sure you didn't actually put it in prod as it can be harmful; see below.

For most code changes, we actually just have GitLab-CI set up so that it test-builds/deploys the container/app on check in (on their own branch/space). That way, most developers don't even need to think about the container part unless they're making mods to that area. But, obviously you'd still want them being able to run the MySQL container locally and easily.

Remote Debugging Info

https://jaxenter.com/remote-debugging-java-applications-151466.html

Warning: Don’t keep remote debugging JVM arguments ON always, as it has following downsides:

Remote debugging mode disables several optimizations that JVM does to application to optimize the performance. All those optimizations will be lost. Remote debugging opens up a port. It’s a security risk, as anyone who can hit the server can initiate remote debugging