{"id":68860,"date":"2017-09-25T10:00:16","date_gmt":"2017-09-25T07:00:16","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=68860"},"modified":"2023-12-11T10:22:16","modified_gmt":"2023-12-11T08:22:16","slug":"docker-java-developers-docker-command-line","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2017\/09\/docker-java-developers-docker-command-line.html","title":{"rendered":"Docker for Java Developers: Docker over command line"},"content":{"rendered":"

This article is part of our Academy Course titled Docker Tutorial for Java Developers<\/a>.<\/p>\n

In this course, we provide a series of tutorials so that you can develop your own Docker based applications. We cover a wide range of topics, from Docker over command line, to development, testing, deployment and continuous integration. With our straightforward tutorials, you will be able to get your own projects up and running in minimum time. Check it out here<\/a>!<\/em><\/p>\n

\n

Table Of Contents<\/h3>\n
\n
1. Introduction<\/a><\/dt>\n
2. Images<\/a><\/dt>\n
3. Containers<\/a><\/dt>\n
4. Ports<\/a><\/dt>\n
5. Volumes<\/a><\/dt>\n
6. Networks<\/a><\/dt>\n
7. Linking<\/a><\/dt>\n
8. Health Checks<\/a><\/dt>\n
9. Resource Limits<\/a><\/dt>\n
10. Clean up<\/a><\/dt>\n
11. All-in-One: The Deployment Stack<\/a><\/dt>\n
12. Conclusions<\/a><\/dt>\n
12. What\u2019s next<\/a><\/dt>\n<\/dl>\n<\/div>\n

<\/a>1. Introduction<\/h2>\n

In this section of the tutorial we are going to master the Swiss army knife of Docker<\/a>, its command line tool of the same name docker<\/a> and its best friend docker-compose<\/a>. To give these tools some credit, each of them supports myriads of different command line arguments and options so discussing all of them would make this section literally endless. Instead, we would be focusing on most useful classes of the commands, pointing to the relevant sections of the documentation in case you would like to learn more right away.<\/p>\n

Docker<\/a> evolves very fast and as such, docker<\/a> and docker-compose<\/a> are constantly changing as well, adding some new command line arguments while deprecating others. Breaking changes are not so rare but this is a reality Docker<\/a> users are facing for quite a while now.<\/p>\n

One of the largest changes which came into effect recently concerned exactly the command line tooling. In the past, the docker<\/a> used to accept a single command as the first argument followed by list of options. However, the amount of different commands grew so large, that the tool became really confusing and cumbersome to use. It was decided to split the commands into classes (for example image<\/strong>, container<\/strong>, network<\/strong>, volume<\/strong>, plugin<\/strong>, system<\/strong>, \u2026) so the every command will be preceded by its class (for example, docker build<\/strong> becomes docker image build<\/strong>). It was a really needed change and although the old-style usage of the commands is still supported, we would adhere to the recommended practices in the tutorial.<\/p>\n

The section is structured in such a way so to familiarize you with the most useful commands while not really digging into the details and usage scenarios. The rationale behind is quite simple though, in the next sections of the tutorial we are going to battle-test most (if not all) of them while doing really practical things.<\/p>\n

<\/a>2. Images<\/h2>\n

It looks logical to start from the bottom and get acquainted with docker<\/a> by learning how to build images. In the first section of the tutorial we have briefly walked through the process but it is time to do it ourselves using build<\/a> command.<\/p>\n

docker image build [OPTIONS] PATH | URL | -\n<\/pre>\n
As we remember, docker<\/a> builds images from the Dockerfile<\/a>s, executing each instruction in the order it is specified. The PATH or URL options are the hints where to look for the Dockerfile<\/a>.<\/p>\n
Building small and efficient images, and doing so fast, is one of the key goals to aim for in order to be successful with Docker<\/a>. Image caching, labeling, tagging, reducing the final size of the image and many other topics are nicely summarized in the best practices for writing Dockerfiles<\/a>, it is highly recommended to go over this read.<\/p>\n
You may rarely find the need to build your own base images so let us talk instead what would be our choices in order to pick the base image for Java applications.<\/p>\n
As of now, objectively, the Alpine Linux<\/a> is the de facto base Linux distribution for the containerized applications. If you happen to run your applications on OpenJDK<\/a>, you are really lucky as the project\u2019s official DockerHub repository<\/a> provides plenty of the images based on Alpine Linux<\/a>. Quickly, here is a simplest Dockerfile<\/a> example:<\/p>\n
FROM openjdk:8u131-jdk-alpine\nCMD [\"java\", \"-version\"]\n<\/pre>\n
Assuming your shell is pointing to the same folder where this Dockerfile<\/a> resides, you can build (and also tag) the image with this command:<\/p>\n
docker image build . --tag base:openjdk-131-jdk\n<\/pre>\n
In case you bet on Oracle JVM<\/a> distributions, sadly the Alpine Linux<\/a> is not officially supported yet (although you may see that some people are trying to marry those two together, please be aware that it kind of feasible but the JVM process in the container could crash any time). The options here are either to use official Oracle Java 8 SE (Server JRE) image<\/a> or build your own based on Ubuntu<\/a> or Debian<\/a> distributions.<\/p>\n
In terms of which JVM version to build upon, please make sure to use at least Java 8 update 131<\/strong> or later, for the reasons we will discuss in details in the upcoming sections (but if you are curious, here is the sneak peek behind the curtain<\/a>).<\/p>\n
Along with build<\/a>, there is a couple of very useful commands which are worth mentioning. The ls<\/a> command shows all the images:<\/p>\n
docker image ls [OPTIONS] [REPOSITORY[:TAG]]\n<\/pre>\n
The history<\/a> command shows the history of an image:<\/p>\n
docker image history [OPTIONS] IMAGE\n<\/pre>\n
While the rm<\/a> command removes one or more images:
 
<\/div> <\/div><\/p>\n
docker image rm [OPTIONS] IMAGE [IMAGE...]\n<\/pre>\n
To interface with registries, there are pull<\/a> and push<\/a> commands. The first one fetches the image from a registry while the latter uploads it to the registry.<\/p>\n
docker image pull [OPTIONS] NAME[:TAG|@DIGEST]\ndocker image push [OPTIONS] NAME[:TAG]\n<\/pre>\n
Lastly, the exceptionally useful prune<\/a> command removes all unused images (which you have better to use with -a<\/strong> option all the time):<\/p>\n
docker image prune [OPTIONS]\n<\/pre>\n
One of the tremendously useful features introduced by Docker<\/a> in the recent release is the support of multi-stage builds<\/a> which allows to have multiple FROM statements in the Dockerfile<\/a>. We would just mention that here but it will come back to us in the upcoming sections of the tutorial.<\/p>\n
<\/a>3. Containers<\/h2>\n
Container management constitutes a large portion of the Docker<\/a> functionally and there are a lot of different commands to back it up. Let us start by dissecting super powerful run<\/a> command, which spawns a new container:<\/p>\n
docker container run [OPTIONS] IMAGE [COMMAND] [ARG...]\n<\/pre>\n
To get a feeling of how easy it is, we could run the container using our OpenJDK<\/a>-based image which we have hand-built previously:<\/p>\n
$ docker container run base:openjdk-131-jdk\n\nopenjdk version \"1.8.0_131\"\nOpenJDK Runtime Environment (IcedTea 3.4.0) (Alpine 8.131.11-r2)\nOpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)\n<\/pre>\n
Once you have the containers running, you could attach<\/a> to them or use start<\/a> \/ stop<\/a> \/ restart<\/a> commands to manage their lifecycle.<\/p>\n
docker container attach [OPTIONS] CONTAINER\ndocker container start [OPTIONS] CONTAINER [CONTAINER...]\ndocker container stop [OPTIONS] CONTAINER [CONTAINER...]\ndocker container restart [OPTIONS] CONTAINER [CONTAINER...]\n<\/pre>\n
Additionally, with pause<\/a> \/ unpause<\/a> commands you have the control over the state of the processes within the containers.<\/p>\n
docker container pause CONTAINER [CONTAINER...]\ndocker container unpause CONTAINER [CONTAINER...]\n<\/pre>\n
Probably, the ls<\/a> command will be the most used one as it lists all running containers (and with -a<\/strong> option all containers, running and stopped):<\/p>\n
docker container ls [OPTIONS]\n<\/pre>\n
Consequently, the inspect<\/a> command display detailed information about one or more containers:<\/p>\n
docker container inspect [OPTIONS] CONTAINER [CONTAINER...]\n<\/pre>\n
The stats<\/a> command is designated to expose runtime statistics about the container. The top<\/a> command shows running container processes while the logs<\/a> command fetches the logs of the container.<\/p>\n
docker container stats [OPTIONS] [CONTAINER...]\ndocker container top CONTAINER \ndocker container logs [OPTIONS] CONTAINER\n<\/pre>\n
Over its lifetime container could go through many modifications and diverge from its base image significantly. The diff<\/a> command inspects all the changes to files or directories on a container\u2019s filesystem and reports them.<\/p>\n
docker container diff CONTAINER\n<\/pre>\n
In case you would need to capture these changes, there is a handy commit<\/a> command which creates a new image from the container.<\/p>\n
docker container commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]\n<\/pre>\n
Once container is not needed anymore, it could be terminated using rm<\/a> command. Please be cautious as all the data stored inside the container will be gone (unless it is backed by volumes<\/a>).<\/p>\n
docker container rm [OPTIONS] CONTAINER [CONTAINER...]\n<\/pre>\n
More extreme version of rm<\/a> command, the prune<\/a> command, mass-removes all stopped containers.<\/p>\n
docker container prune [OPTIONS]\n<\/pre>\n
<\/a>4. Ports<\/h2>\n
Every container could expose ports to listen at runtime, either through image Dockerfile<\/a> instructions or through the options of the run<\/a> command. The port<\/a> command lists all port mappings (or a specific mapping) for the container.<\/p>\n
docker container port CONTAINER [PRIVATE_PORT[\/PROTO]]\n<\/pre>\n
<\/a>5. Volumes<\/h2>\n
As we remember, containers are ephemeral and once the container is terminated, all the data it holds will be lost. It might not be a problem in many cases, but if you run the data store in a container for example, it is very likely you would prefer to keep your data.<\/p>\n
To fill this gap Docker<\/a> introduces volumes<\/a> as the preferred mechanism for persisting data used by containers and, obviously, docker<\/a> has a dedicated class of commands for that (create<\/a>, inspect<\/a>, ls<\/a>, prune<\/a> and rm<\/a>).<\/p>\n
docker volume create [OPTIONS] [VOLUME]\ndocker volume inspect [OPTIONS] VOLUME [VOLUME...]\ndocker volume ls [OPTIONS]\ndocker volume prune [OPTIONS]\ndocker volume rm [OPTIONS] VOLUME [VOLUME...]\n<\/pre>\n
[ulp id=’MD25RnPuC2vrVItl’]
\n <\/p>\n
<\/a>6. Networks<\/h2>\n
Docker<\/a> has pretty good networking support<\/a> for containers with a number of network drivers available out of the box. Surely, the standard set of create<\/a>, inspect<\/a>, ls<\/a>, prune<\/a> and rm<\/a> commands is available to manage the networks.<\/p>\n
docker network create [OPTIONS] NETWORK\ndocker network inspect [OPTIONS] NETWORK [NETWORK...]\ndocker network ls [OPTIONS]\ndocker network prune [OPTIONS]\ndocker network rm NETWORK [NETWORK...]\n<\/pre>\n
What distinguishes Docker<\/a> networking is the fact the dockerd<\/a> daemon contains an embedded DNS server which provides names resolution among containers connected to the same user-define network (so that the containers could be referenced by their names, not only IP addresses).<\/p>\n
Any running container could be connected to the network or disconnected from the network using connect<\/a> and disconnect<\/a> commands respectively.<\/p>\n
docker network connect [OPTIONS] NETWORK CONTAINER\ndocker network disconnect [OPTIONS] NETWORK CONTAINER\n<\/pre>\n
Aside from that, the container could be connected to a particular network by passing the options to the run<\/a> command. All unused networks could be removed by invoking the prune<\/a> command.<\/p>\n
docker network prune [OPTIONS]\n<\/pre>\n
<\/a>7. Linking<\/h2>\n
More often than not your application stack would be composed of many connected components rather than standalone ones (a typical example would be a Java server-side application which talks to MySQL<\/a> data store). Projecting that to the world of containers, you would need a group of containers which could somehow discover their upstream dependencies and communicate with each other. In Docker<\/a> it used to be known as linking<\/a> but nowadays it could be easily achieved using user-defined networks<\/a> (which is also the recommended practice).<\/p>\n
<\/a>8. Health Checks<\/h2>\n
Usually Docker<\/a> daemon provisions the containers pretty fast however it does not mean that the applications packaged inside the containers are ready and fully functional. For many Docker<\/a> users it used to be one of the most annoying issues to deal with, forcing the community to come up with many ad-hoc solutions to the problem.<\/p>\n
But kudos to Docker<\/a> team, we now have health checks<\/a> (which could be specified in the Dockerfile<\/a> or using the options of the run<\/a> command). It is an additional verification layer which instructs the Docker<\/a> on how to test that the application inside the container is working. It resulted into adding a new health status<\/strong> property to complement the regular container status.<\/p>\n
<\/a>9. Resource Limits<\/h2>\n
Interestingly, by default a container has no resource constraints and may consume all the resources of its host operating system. It could have been a show-stopper but fortunately Docker<\/a> provides a way to control<\/a> how much memory, CPU, or block I\/O a particular container can use by passing a number of options to the run<\/a> command. Alternatively, for the running containers the update<\/a> command allows to adjust the container configuration (primary, resource limits) dynamically.<\/p>\n
docker container update [OPTIONS] CONTAINER [CONTAINER...]\n<\/pre>\n
With respect to JVM running inside the container, the subject of the CPU and memory limits gets a bit trickier. As of Java SE 8u131<\/strong> (and surely in JDK 9<\/strong>) and later, the JVM is Docker-aware<\/a> and with just a little bit of tuning is able to play nicely according to the rules.<\/p>\n
<\/a>10. Clean up<\/h2>\n
As we have seen so far, there are a lot of abstractions you can manage with Docker<\/a>. However, with a time Docker<\/a> generates a lot of garbage (like unused layers, images, containers, volumes, \u2026), eating the precious disk space. It has been a known issue for years but since not long ago we have a dedicated prune<\/a> command which cleans up all unused data:<\/p>\n
docker system prune [OPTIONS]\n<\/pre>\n
Please note that by default the command will not clean up the volumes unless the –volumes<\/strong> option is specified.<\/p>\n
<\/a>11. All-in-One: The Deployment Stack<\/h2>\n
As we have seen up to this point, you can accomplish any task using just docker<\/a> command line tool. But managing lifecycle of multiple containers connected together will quickly become a burden and force you to think about automating the process, ether with bunch of shell scripts or alike.<\/p>\n
The community has realized the problem early on and came up with a brilliant solution to that, known these days as Docker Compose<\/a>. In a nutshell, Docker Compose<\/a> provides the declarative way for defining and then running multiple Docker<\/a> containers, drastically simplifying the rather complex deployment of the containerized application stacks.<\/p>\n
So how does it work? There are just a three simple steps involved, some of them we are already quite familiar with:<\/p>\n