TL;DR. The proposed solutions are about:
- Establish Docker container and integrate with project file on the host directory
- Use debug module in VSCode for Go
- Separation of Docker images based on purpose — base, debug, production
As a Windows user who needs to work with other developers that are using other operating systems, such as Ubuntu or MacOS, I usually become discouraged whether my work could be run on the others or not. Even when I am using the same operating system with the others, having an issue regarding the different environment is still common. So, Docker is a solution, for a developer like me, who does not want to spend a lot of times to debug this repetitive issue.
Establish Docker container and integrate with project file on the host directory
There is a drawback when I am using Docker for development — I am still writing and running the code in my host. I do not think that Docker could solve my concern regarding the different environment. When I am still in the development stage, I do not want to build so often — I want to have a way where I could only use Docker container as the environment, but still could code-on-demand. For this one, you could check here.
The diagram above provides a high-overview of how this methodology works. By mount-binding between the directory of your current project directory and the directory inside your container. So, whenever you make any changes in your local machine, it would directly reflect inside your Docker container. Hence, it solves the problem of:
- Different environment between machines.
- Continuous development without putting the code and build it together as a Docker image.
Use debug module in VSCode for Go
The diagram above provides a high-overview of how this methodology works. The idea is simple, we want to make a backdoor for go-delve to listen to the system inside the container. On here, I expose the container to another port, which is 1234 on the example.
Separation of Docker images based on purpose — base, debug, production
Also, since I want to debug in Docker, I do not want to mix it with the stack that I only want to have in my production container. So I split the Dockerfile based on its purpose. I write the idea and the usage of each file on here.
The diagram above provides a high-overview of how this methodology works. by doing this approach, we could make sure that:
- Your Docker image would keep small.
- You only put relevant packages in each environment.
- You still maintain the standard between production and test image.
I hope this tutorial could help you to enjoy your development time in Go language much better! I am happy to hear your feedback.
Nevertheless, happy coding!