{"id":73273,"date":"2018-02-13T10:54:36","date_gmt":"2018-02-13T08:54:36","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=73273"},"modified":"2023-12-11T10:31:22","modified_gmt":"2023-12-11T08:31:22","slug":"docker-java-developers-deploy-docker","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2018\/02\/docker-java-developers-deploy-docker.html","title":{"rendered":"Docker for Java Developers: Deploy on Docker"},"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. Containers as Deployment Units<\/a><\/dt>\n
3. Orchestration using Kubernetes<\/a><\/dt>\n
4. Orchestration using Apache Mesos<\/a><\/dt>\n
5. Orchestration using Docker Swarm<\/a><\/dt>\n
6. Containers in the Cloud<\/a><\/dt>\n
\n
\n
6.1. Amazon Elastic Container Service<\/a><\/dt>\n
6.2. Google Kubernetes Engine<\/a><\/dt>\n
6.3. Azure Container Service<\/a><\/dt>\n<\/dl>\n<\/dd>\n
7. Conclusions<\/a><\/dt>\n
8. What\u2019s next<\/a><\/dt>\n<\/dl>\n<\/div>\n

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

Many companies have been using container-based virtualization to deploy applications (including JVM based ones) in production way before Docker<\/a> appearance on the horizon. However, primarily because of Docker<\/a>, deployment practices using containers turned into the mainstream these days.<\/p>\n

In this section of the tutorial we are going to glance over some of the most popular orchestration and cluster management engines (covering a couple of cloud offerings as well) which natively support deployment and lifecycle of the containerized applications.<\/p>\n

The topics we are going to talk about are worth of several books (at least!) so the goal of this part would be to serve as an introduction. If you feel a particular interest in any of those, there is a tremendous amount of the resources available in the public access.<\/p>\n

<\/a>2. Containers as Deployment Units<\/h2>\n

These days containers (in particular, Docker<\/a> containers) became standardized units of software deployment. They are prepackaged with everything that the applications may need to run: code (or binary), runtime, system tools and libraries, you name it.<\/p>\n

Managing and orchestrating the container-based deployments is quite a hot topic and, as we are going to see in a moment, every solution out there offers it right from the start.<\/p>\n

<\/a>3. Orchestration using Kubernetes<\/h2>\n

In a rare case you haven\u2019t heard about it yet, Kubernetes<\/a> is an open-source system for automating deployment, scaling, and management of containerized applications. This is one of the most exciting, innovative and actively evolving projects in the open-source community. Probably, if you or your company is looking for container orchestration solution, Kubernetes<\/a> is the de-facto choice nowadays.<\/p>\n

There are a lot of things which Kubernetes<\/a> could do for you, but in this part of the tutorial we are going to see how easy it is to deploy our containerized Spring Boot<\/a> application stack, including MySQL<\/a>, using only minimal subset of the Kubernetes<\/a> features.<\/p>\n

Setting up a full-fledged Kubernetes<\/a> cluster on the local machine might sound a bit impractical but luckily Kubernetes<\/a> could be deployed in development mode via minikube<\/a>. This awesome tool spawns a single-node Kubernetes<\/a> cluster inside a virtual machine so you could develop on it day-to-day using your laptop or desktop for example.<\/p>\n

With the assumption that you installed minikube<\/a> on the operating system of your choice, let us move on to the next step and deploy a couple of Docker<\/a> containers on it.<\/p>\n

$ minikube start\n<\/pre>\n
When minikube<\/a> is started, we could immediately initiate MySQL<\/a> deployment, sticking to the same version 8.0.2<\/code> which we have been using along this tutorial.<\/p>\n
$ kubectl run mysql --image=mysql:8.0.2 --env='MYSQL_ROOT_PASSWORD=p$ssw0rd' --env='MYSQL_DATABASE=my_app_db' --env='MYSQL_ROOT_HOST=%' --port=3306\n<\/pre>\n
It will take some time and at the end you should be able to see MySQL<\/a> container (or better to say, Kubernetes<\/a> pod) up and running:<\/p>\n
$ kubectl get pod\nNAME                       READY     STATUS    RESTARTS   AGE\nmysql-5d4dbfcd58-6fmck     1\/1       Running   0          22m\n<\/pre>\n
Excellent, now we would need to rebuild the Docker<\/a> image of our Spring Boot<\/a> application we have developed previously<\/a>, using the Docker<\/a> settings of the deployed Kubernetes<\/a> cluster (alternatively, we could have used private registry).<\/p>\n
$ eval $(minikube docker-env)\n$ docker image build \\\n  --build-arg BUILD_VERSION=0.0.1-SNAPSHOT \\\n  -f Dockerfile.build \\\n  -t jcg\/spring-boot-webapp:latest \\\n  -t jcg\/spring-boot-webapp:0.0.1-SNAPSHOT .\n<\/pre>\n
With this step completed, we have our Docker<\/a> image available for deployment in Kubernetes<\/a> and we could run it as another pod.<\/p>\n
$ kubectl run spring-boot-webapp --image=jcg\/spring-boot-webapp:latest --env='DB_HOST=mysql.default.svc.cluster.local' --port=19900 --image-pull-policy=Never\n<\/pre>\n
Let us check that we have two pods up and running:<\/p>\n
$ kubectl get pod\nNAME                                  READY     STATUS    RESTARTS   AGE\nmysql-5d4dbfcd58-6fmck                1\/1       Running   0          33m\nspring-boot-webapp-5ff8456bf5-gf5qv   1\/1       Running   0          31m\n<\/pre>\n
Last but not least, we have to expose our Spring Boot<\/a> application deployment as Kubernetes<\/a> service to make it accessible:<\/p>\n
$ kubectl expose deployment spring-boot-webapp --type=NodePort\n<\/pre>\n
And quickly check it is listed among other services:<\/p>\n
$ kubectl.exe get service\nNAME               TYPE      CLUSTER-IP          EXTERNAL-IP PORT(S     AGE\nkubernetes         ClusterIP 10.96.0.1           443\/TCP                4d\nspring-boot-webapp NodePort  10.109.108.87       19900:30253\/TCP        40s\n<\/pre>\n
And that\u2019s basically it, in a few simple steps we have gotten our Docker<\/a> containers up and running, all managed by Kubernetes<\/a>. Let us make sure that the application is actually passing all the health checks:<\/p>\n
$ curl $(minikube service spring-boot-webapp --url)\/application\/health\n{\n    \"status\":\"UP\",\n    \"details\": {\n        \"diskSpace\": {\n            \"status\":\"UP\",\n            \"details\": {\n                \"total\":17293533184,\n                \"free\":14476333056,\n                \"threshold\":10485760\n            }\n        },\n        \"db\": {\n            \"status\":\"UP\",\n            \"details\": {\n                \"database\":\"MySQL\",\n                \"hello\":1\n            }\n        }\n    }\n}\n<\/pre>\n
And it really does! To finish up our discussion regarding Kubernetes<\/a>, it is worth to mention that Docker<\/a> already includes an early native integration with Kubernetes<\/a> on some of the edge channels<\/a>.
 
<\/div> <\/div><\/p>\n
<\/a>4. Orchestration using Apache Mesos<\/h2>\n
Apache Mesos<\/a> is arguably the one of the oldest resource and cluster management frameworks in use. It effectively abstracts resources (CPU, memory, storage) away from physical or virtual hardware, allowing to build and operate fault-tolerant and elastic distributed systems. One of its strengths is exceptional level of extensibility and support of containerized application deployments, however it is also known to be quite complex and difficult to operate.<\/p>\n
Architecturally, Apache Mesos<\/a> consists of a master<\/code> that manages agents<\/code> (running on each cluster node), and frameworks<\/code> (that run tasks<\/code> on these agents). The master enables fine-grained sharing of resources (CPU, RAM, \u2026) across frameworks by making them resource offers<\/code>. Bounding ourselves to only the necessary components, let us take a look on how Apache Mesos<\/a> cluster could be defined using docker-compose<\/a> specification.<\/p>\n
version: \"3\"\n\nservices:\n  zookeeper:\n    image: zookeeper\n    networks:\n      - mesos-network\n    environment:\n      ZOO_TICK_TIME: 2000\n      ZOO_INIT_LIMIT: 10\n      ZOO_SYNC_LIMIT: 5\n      ZOO_MAX_CLIENT_CNXNS: 128\n      ZOO_PORT: 2181\n      ZOO_MY_ID: 1\n\n  mesos-master:\n    image: mesosphere\/mesos-master:1.3.2\n    networks:\n      - mesos-network\n    ports:\n      - \"5050:5050\"\n    environment:\n      MESOS_ZK: zk:\/\/zookeeper:2181\/mesos\n      MESOS_QUORUM: 1\n      MESOS_CLUSTER: docker-compose\n      MESOS_REGISTRY: replicated_log\n    volumes:\n      - \/var\/run\/docker.sock:\/run\/docker.sock\n    depends_on:\n      - zookeeper\n\n  mesos-slave:\n    image: mesosphere\/mesos-slave:1.3.2\n    privileged: true\n    networks:\n      - mesos-network\n    ports:\n      - \"5051:5051\"\n    links:\n      - zookeeper\n      - mesos-master\n    environment:\n      - MESOS_CONTAINERIZERS=docker\n      - MESOS_ISOLATOR=cgroups\/cpu, cgroups\/mem\n      - MESOS_LOG_DIR=var\/log\n      - MESOS_MASTER=zk:\/\/zookeeper:2181\/mesos\n      - MESOS_PORT=5051\n      - MESOS_EXECUTOR_REGISTRATION_TIMEOUT=5mins\n      - MESOS_EXECUTOR_SHUTDOWN_GRACE_PERIOD=90secs\n      - MESOS_DOCKER_STOP_TIMEOUT=90secs\n      - MESOS_RESOURCES=cpus:2;mem:2080;disk:5600;ports(*):[19000-19999]\n      - MESOS_WORK_DIR=\/var\/lib\/mesos\n      - MESOS_SYSTEMD_ENABLE_SUPPORT=false\n    volumes:\n      - \/var\/run\/docker.sock:\/run\/docker.sock\n    dns:\n      - mesos-dns\n    depends_on:\n      - mesos-master\n      - mesos-dns\n\n  marathon:\n    image: mesosphere\/marathon:v1.5.6\n    networks:\n      - mesos-network\n    environment:\n      - MARATHON_ZK=zk:\/\/zookeeper:2181\/marathon\n      - MARATHON_MASTER=zk:\/\/zookeeper:2181\/mesos\n    ports:\n      - \"8080:8080\"\n    depends_on:\n      - mesos-master\n\n  mesos-dns:\n    image: mesosphere\/mesos-dns:v0.6.0\n    command: [ \"\/usr\/bin\/mesos-dns\", \"-v=2\", \"-config=\/config.json\" ]\n    ports:\n      - 53:53\/udp\n      - 8123:8123\n    volumes:\n      - .\/config.json:\/config.json\n      - \/tmp\n    links:\n      - zookeeper\n    dns:\n      - 8.8.8.8\n      - 8.8.4.4\n    networks:\n      - mesos-network\n\nnetworks:\n    mesos-network:\n       driver: bridge\n<\/pre>\n
As we can see, there are quite a few moving parts in there, besides just Apache Mesos<\/a> (and Apache Zookeeper<\/a>). In the heart of it is the Marathon<\/a> framework, the container orchestration platform. Marathon<\/a> provides a beautiful web UI<\/a> as well as REST(ful) APIs<\/a> to manage the application deployments and uses own JSON<\/a>-based specification format. Following our Spring Boot<\/a> application stack, let us take a look on the example of the MySQL<\/a> deployment descriptor (which is stored inside the mysql.json<\/code> file):<\/p>\n
{\n  \"id\": \"\/jcg\/mysql\",\n  \"container\": {\n    \"type\": \"DOCKER\",\n    \"docker\": {\n      \"image\": \"mysql:8.0.2\",\n      \"network\": \"BRIDGE\",\n      \"portMappings\": [\n        {\n          \"containerPort\": 3306,\n          \"servicePort\": 3306,\n          \"hostPort\": 0,\n          \"protocol\": \"tcp\"\n        }\n      ],\n      \"parameters\": [\n        {\n          \"key\": \"hostname\",\n          \"value\": \"mysql\"\n        }\n      ]\n    }\n  },\n  \"env\": {\n    \"MYSQL_ROOT_PASSWORD\": \"p$ssw0rd\",\n    \"MYSQL_DATABASE\": \"my_app_db\",\n    \"MYSQL_ROOT_HOST\": \"%\"\n  },\n  \"instances\": 1,\n  \"cpus\": 0.1,\n  \"mem\": 500,\n  \"healthChecks\": [\n    {\n      \"protocol\": \"COMMAND\",\n      \"command\": { \"value\": \"ss -ltn src :3306 | grep 3306\" },\n      \"gracePeriodSeconds\": 10,\n      \"intervalSeconds\": 10,\n      \"timeoutSeconds\": 5,\n      \"maxConsecutiveFailures\": 2\n    }\n  ]\n}\n<\/pre>\n
With that, to bring MySQL<\/a> container to live we just need to submit this descriptor to Marathon<\/a> by leveraging its REST(ful) APIs<\/a> (assuming our Apache Mesos<\/a> is up and running), for example:<\/p>\n
$ curl -X POST http:\/\/localhost:8080\/v2\/apps -d @mysql.json -H \"Content-type: application\/json\"\n\n{\n  \"id\":\"\/jcg\/mysql\",\n  \"container\":{\n     \u2026\n  },\n  \u2026\n}\n<\/pre>\n
Looks good, let us do the same for Spring Boot<\/a> application, starting off from the Marathon<\/a> deployment descriptor and persist it in the spring-webapp.json<\/code> file.<\/p>\n
{\n  \"id\": \"\/jcg\/spring-webapp\",\n  \"container\": {\n    \"type\": \"DOCKER\",\n    \"docker\": {\n      \"image\": \"jcg\/spring-boot-webapp:latest\",\n      \"network\": \"BRIDGE\",\n      \"portMappings\": [\n        { \n          \"containerPort\": 19900, \n          \"servicePort\": 19900, \n          \"hostPort\": 19900 \n        }\n      ],\n      \"parameters\": [\n        { \"key\": \"hostname\", \"value\": \"spring-webapp\" }\n      ]\n    }\n  },\n  \"env\": {\n    \"DB_HOST\": \"172.17.0.2\"\n  },\n  \"instances\": 1,\n  \"cpus\": 0.1,\n  \"mem\": 512,\n  \"healthChecks\": [\n    {\n      \"protocol\": \"COMMAND\",\n      \"command\": { \"value\": \"nc -z localhost 19900\" },\n      \"gracePeriodSeconds\": 25,\n      \"intervalSeconds\": 10,\n      \"timeoutSeconds\": 5,\n      \"maxConsecutiveFailures\": 3\n    }\n  ]\n}\n<\/pre>\n
Next step would be to submit it to Marathon<\/a>:<\/p>\n
$ curl -X POST http:\/\/localhost:8080\/v2\/apps -d @spring-webapp.json -H \"Content-type: application\/json\"\n\n{\n  \"id\":\"\/jcg\/spring-webapp\",\n  \"container\":{\n     \u2026\n  },\n  \u2026\n}\n<\/pre>\n
And we are effectively done! Once the deployment is finished, we should be able to see our application stack in operational state using, for example, Marathon<\/a>\u2019s web UI<\/a>, accessible at http:\/\/localjost:8080\/ui\/<\/a>.<\/p>\n
\"\"<\/a>
Marathon Applications<\/figcaption><\/figure><\/p>\n
The curious reader may wonder how we linked those two Marathon<\/a> applications, Spring Boot<\/a> and MySQL<\/a>, together. For this particular case, we have been using service discovery and load balancing<\/a> capabilities of Apache Mesos<\/a> fulfilled by Mesos-DNS<\/a>. To illustrate them in action, this is how we can query the IP address of the MySQL<\/a> instance by its name, mysql-jcg.marathon.mesos<\/code>.<\/p>\n
$ curl http:\/\/localhost:8123\/v1\/hosts\/mysql-jcg.marathon.mesos\n[\n  {\n   \"host\": \"mysql-jcg.marathon.mesos.\",\n   \"ip\": \"172.17.0.2\"\n  }\n]\n<\/pre>\n
As usual, let us confirm that Spring Boot<\/a> application is up and running by sending over a HTTP request to its health endpoint:<\/p>\n
$ curl http:\/\/localhost:19900\/application\/health\n\n{\n    \"details\": {\n        \"db\": {\n            \"details\": {\n                \"database\": \"MySQL\",\n                \"hello\": 1\n            },\n            \"status\": \"UP\"\n        },\n        \"diskSpace\": {\n            \"details\": {\n                \"free\": 44011802624,\n                \"threshold\": 10485760,\n                \"total\": 49536962560\n            },\n            \"status\": \"UP\"\n        }\n    },\n    \"status\": \"UP\"\n}\n<\/pre>\n
[ulp id=’MD25RnPuC2vrVItl’]
\n <\/p>\n
<\/a>5. Orchestration using Docker Swarm<\/h2>\n
It has been awhile since Docker<\/a> has the cluster management and orchestration features embedded in the engine. This orchestration layer is used to be known as Docker Swarm<\/a> but later on evolved into, essentially, just a special mode (swarm mode<\/a>) to run Docker Engine<\/a> in.<\/p>\n
If you are betting heavily on Docker<\/a> and prefer not to look for anything else, running Docker Engine<\/a> in a swarm mode<\/a> could be a good option as an orchestrator. It is fairly easy to get started with as well.<\/p>\n
$ docker swarm init\n<\/pre>\n
Conceptually, there are quite a few differences which swarm mode introduces, beyond just changes in the Docker Engine<\/a> itself. First and foremost, you should start thinking in terms of services, not containers. The assumptions about running everything inside single Docker<\/a> host won\u2019t be accurate anymore as the swarm would very like consist of many Docker<\/a> hosts distributed over the network.<\/p>\n
When running Docker Engine<\/a> in a swarm mode<\/a>, we can deploy a complete application (service) stack using already familiar docker-compose<\/a> specification. There is only one constraint though, the docker-compose<\/a> file format should be version 3 (or above)<\/code> to be compatible between Docker Compose<\/a> and Docker Engine<\/a>\u2019s swarm mode<\/a>.<\/p>\n
To see the swarm mode<\/a> in action, let us rework our Spring Boot<\/a> application stack a bit to comply with docker-compose<\/a> file format version 3.3<\/code>.<\/p>\n
version: '3.3'\n\nservices:\n  mysql:\n    image: mysql:8.0.2\n    environment:\n      - MYSQL_ROOT_PASSWORD=p$$ssw0rd\n      - MYSQL_DATABASE=my_app_db\n      - MYSQL_ROOT_HOST=%\n    healthcheck:\n      test: [\"CMD-SHELL\", \"ss -ltn src :3306 | grep 3306\"]\n      interval: 10s\n      timeout: 5s\n      retries: 3\n    networks:\n      - my-app-network\n\n  java-app:\n    image: jcg\/spring-boot-webapp:latest\n    environment:\n      - DB_HOST=mysql\n    ports:\n      - 19900:19900\n    depends_on:\n      - mysql\n    healthcheck:\n      test: [\"CMD-SHELL\", \"nc -z localhost 19900\"]\n      interval: 10s\n      timeout: 5s\n      retries: 3\n    networks:\n      - my-app-network\n\nnetworks:\n    my-app-network:\n       driver: overlay\n<\/pre>\n
Fairly speaking, we didn’t have to do many changes. Specifically to support the swarm mode<\/a>, there is a dedicated family of commands which has been introduced into docker<\/a> tooling: docker stack<\/code>. We have not talked about them in the second part of this tutorial<\/a>, but now is time to do so.<\/p>\n
With the deploy<\/a> command, and docker-compose<\/a> specification at hand, we could initiate the application stack deployment into the swarm cluster.<\/p>\n
$ docker stack deploy --compose-file docker-compose.yml springboot-webapp\n<\/pre>\n
To see the status of the deployments and also all deployed services we could use services<\/a> command, as in the example below (the output has been shortened a bit):<\/p>\n
$ docker stack services  springboot-webapp\nNAME                        IMAGE                         REPLICAS PORTS\nspringboot-webapp_java-app  jcg\/spring-boot-webapp:latest 1\/1      *:19900->19900\/tcp\nspringboot-webapp_mysql     mysql:8.0.2                   1\/1   \n<\/pre>\n
Awesome, looks like our Spring Boot<\/a> application is up and running, let us confirm that by sending over a HTTP request to its health endpoint:<\/p>\n
$ curl http:\/\/localhost:19900\/application\/health\n\n{\n    \"details\": {\n        \"db\": {\n            \"details\": {\n                \"database\": \"MySQL\",\n                \"hello\": 1\n            },\n            \"status\": \"UP\"\n        },\n        \"diskSpace\": {\n            \"details\": {\n                \"free\": 3606978560,\n                \"threshold\": 10485760,\n                \"total\": 19195224064\n            },\n            \"status\": \"UP\"\n        }\n    },\n    \"status\": \"UP\"\n}\n<\/pre>\n
It looks exactly what we expected. To conclude, Docker Engine<\/a> in swarm mode<\/a> in an interesting option to consider however it is worth to mention that it is not as popular as Kubernetes<\/a> or Apache Mesos<\/a>.<\/p>\n
<\/a>6. Containers in the Cloud<\/h2>\n
Every major player in the cloud space is rushing to the market their own managed offerings which intend to support the deployment and orchestration of the containers so you could just drop one and magic happens. Let us quickly glance through them.<\/p>\n
<\/a>6.1. Amazon Elastic Container Service<\/h3>\n
Amazon Elastic Container Service<\/a> (or simply Amazon ECS<\/a>) is a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker<\/a> containers in the cluster. As you may expect, Amazon ECS<\/a> integrates nicely with many other cloud offerings from Amazon Web Services<\/a> portfolio, including:<\/p>\n