Quite often, software projects rely on third-party services and software. Examples include a relational database, message broker, or email service. When starting a new software project or joining the development team for an existing project, it can be a daunting and time consuming task to install all of the required dependencies. Instead of pouring over numerous on-boarding instructions and meticulously installing all the required software dependencies, you can use Docker to ensure you’re using the correct version and configuration of the required software. This is the beauty of working with Docker containers!
What is Docker?
Docker is a software platform for launching and managing containers. A Docker container is a self-contained environment for running processes and commands. It is isolated from the rest of the host machine’s operating system as well as from other Docker containers. Each container has its own network, file system, and starts up fast because it doesn’t have everything else you would find in a full operating system (such as a graphical user interface). Containers are instantiated from images, where an image is all the “stuff” you want Docker to run. Images start with a base image, which might be a particular version of the Postgresql database, the Ubuntu Linux Distribution, or any other custom software that can be run on Linux. You can even make your own Docker images by layering custom configurations on top of other images!
Docker for Development
Docker is a great tool that can make development easier by making a project’s software dependencies reliable, repeatable, easy to install, and run. However, for all of Docker’s flexibility comes a steep learning curve and wisdom of Docker best practices. In some cases, you might think it’s easier to just install the software directly on your machine. Installing software natively on your machine vs using Docker containers is kind of like buying a book vs checking it out from the library. As you start to buy more and more books, you have to make space for all these books in your home. If you mostly check books out from the library, you return them when you’re done and don’t need additional bookshelf space.
Another problem developers new to Docker often encounter is knowing what software is worth running as a Docker container. It might be tempting to run multiple applications and frameworks all in one Docker container or to develop entirely within a Docker container. This is a sure-fire way to build containers that are massive in size or make your development environment much more complex than it needs to be. Simplicity is key, and by sticking to only running individual services or executables in Docker containers, you can save time and work more efficiently.
Service Containers
Typically, services are good candidates to run as a Docker container. A service is any third-party software running as a separate, independent, long running background process, that your project will interact with. Examples include databases, web servers, and full-stack applications like JIRA or Jenkins. Running a service locally as a Docker container is easy because you will install the version of the service your project requires, and you don’t have to install all of its various dependencies. (They’re already included in the container!)
As an example, let’s look at how to run the RabbitMQ message broker as a Docker container. First, make sure you have Docker installed. You can follow the instructions here to install Docker for your operating system. Next, copy and execute the code below in a terminal:
What does this command do? It will run a new Docker container named dev-rabbit in detached mode based on the official RabbitMQ Docker image tagged management. It will also change the hostname of the container to dev-rabbit and map the container’s port 15672 to our host machine’s port 15672. What does all this mean? The official RabbitMQ Docker image will be downloaded from Docker Hub if it doesn’t already exist on the host machine and specifically, the management tagged version will be downloaded and used. More on this in a minute. By setting the port mapping and hostname, RabbitMQ in the container will act just as if RabbitMQ was running on a native Linux host. The management tagged version includes the Management Plugin, so we can go to [http://localhost:15672](http://localhost:15672/) with user/pass guest/guest to access the RabbitMQ Management Plugin’s browser-based UI.
The container will continue to run until the host machine is shutdown or we manually tell Docker to stop running the container. We can stop the container at any time with the command docker stop dev-rabbit and manually start it back up again with docker start dev-rabbit. Because we initially ran the Docker container in detached mode, the dev-rabbit container will always run as a background process, and it’s output to stdout can be viewed with docker logs dev-rabbit.
#go #docker #neo4j #software-development #database
