Miles to go ... - Arun Gupta: Microservice using Docker stack deploy WildFly, ...

There is plenty of material onmicroservices, just google it ! I gave a presentation onrefactoring monolith to microservices at Devoxx Belgium a couple of years back and it hasgood reviews:

This blog will show howDocker simplifies creation and shutting down of a microservice.

All code used in this blog is at github.com/arun-gupta/couchbase-javaee .

Microservice Definition using Compose

Docker 1.13 introduced a v3of Docker Compose . The changes in the syntax are minimal but the key difference is addition of deploy attribute. This attribute allows to specify replicas, rolling update and restart policy for the container.

Our microservice will start a WldFly application server with a Java EE application pre-deployed. This application will talk to a Couchbase database to CRUDapplication data.

Here is the Compose definition:

version: '3' services: web: image: arungupta/couchbase-javaee:travel environment: - COUCHBASE_URI=db ports: - 8080:8080 - 9990:9990 depends_on: - db db: image: arungupta/couchbase:travel ports: - 8091:8091 - 8092:8092 - 8093:8093 - 11210:11210

In this Compose file:

Two services in this Compose are defined by the name db and web attributes Image name for each service defined using image attribute The arungupta/couchbase:travel image starts Couchbase server, configures it using Couchbase REST API , and loads travel-sample bucket with ~32k JSON documents. The arungupta/couchbase-javaee:travel image starts WildFly and deploys application WAR file built from https://github.com/arun-gupta/couchbase-javaee . Clone that project if you want to build your own image. envrionment attribute defines environment variables accessible by the application deployed in WildFly. COUCHBASE_URI refers to the database service. This is used in the application code as shown at https://github.com/arun-gupta/couchbase-javaee/blob/master/src/main/java/org/couchbase/sample/javaee/Database.java . Port forwarding is achieved using ports attribute

depends_on attribute in Compose definition file ensures the container start up order. But application-level start up needs to be ensured by the applications running inside container. In our case, WildFly starts up rather quickly but takes a few seconds for the database to start up. This means the Java EE application deployed in WildFly is not able to communicate with the database. This outlines a best practice when building micro services applications: you must code defensively and ensure in your application initialization that the micro services you depend on have started, without assuming startup order. This is shown in the database initialization code at https://github.com/arun-gupta/couchbase-javaee/blob/master/src/main/java/org/couchbase/sample/javaee/Database.java . It performs the following checks:

Bucket exists Query service of Couchbase is up and running Sample bucket is fully loaded

This application can be started using docker-compose up -d command on a single host. Or a cluster of Docker engines in swarm-mode using docker stack deploy command.

Setup Docker Swarm-mode

Initialize Swarm mode using the following command:

dockerswarminit

This starts a Swarm Manager. By default, manager node are also worker but can be configured to be manager-only.

Find some information about this one-node cluster using the command docker info command:

Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 17 ServerVersion: 1.13.0 StorageDriver: overlay2 BackingFilesystem: extfs Supportsd_type: true Native OverlayDiff: true LoggingDriver: json-file CgroupDriver: cgroupfs Plugins: Volume: local Network: bridgehostipvlanmacvlannull overlay Swarm: active NodeID: 92mydh0e09ba5hx3wtmcmvktz Is Manager: true ClusterID: v68ikyaff7rdxpaw1j0c9i60s Managers: 1 Nodes: 1 Orchestration: TaskHistoryRetentionLimit: 5 Raft: SnapshotInterval: 10000 NumberofOldSnapshotsto Retain: 0 HeartbeatTick: 1 ElectionTick: 3 Dispatcher: HeartbeatPeriod: 5 seconds CAConfiguration: ExpiryDuration: 3 months NodeAddress: 192.168.65.2 ManagerAddresses: 192.168.65.2:2377 Runtimes: runc Default Runtime: runc InitBinary: docker-init containerdversion: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e runcversion: 2f7393a47307a16f8cee44a37b262e8b81021e3e initversion: 949e6fa SecurityOptions: seccomp Profile: default KernelVersion: 4.9.5-moby OperatingSystem: Alpinelinuxv3.5 OSType: linux Architecture: x86_64 CPUs: 4 TotalMemory: 1.952 GiB Name: moby ID: SGCM:KDRD:G3M7:PZHN:J4RL:VFFR:G2SR:EKD5:JV4J:RL3X:LF7T:XF6V DockerRootDir: /var/lib/docker DebugMode (client): false DebugMode (server): true FileDescriptors: 31 Goroutines: 124 SystemTime: 2017-01-27T08:25:58.032295342Z EventsListeners: 1 NoProxy: *.local, 169.254/16 Username: arungupta Registry: https://index.docker.io/v1/ Experimental: true InsecureRegistries: 127.0.0.0/8 LiveRestoreEnabled: false

This cluster has 1node, and that is manager.

Alternatively, a multi-host cluster can be easily setup using Docker for AWS .

Deploy Microservice

The microservice can be started as:

dockerstackdeploy --compose-file=docker-compose.ymlwebapp

This shows theoutput:

Creatingnetworkwebapp_default Creatingservicewebapp_web Creatingservicewebapp_db

WildFly and Couchbase services are started on this node. Each service has a single container. If the Swarm mode is enabled on multiple nodes then the containers will be distributed across multiple nodes.

A new overlay network is created. This allows multiple containers on different hosts to communicate with each other.

Verify that the WildFly and Couchbase services are running using docker service ls :

IDNAMEMODEREPLICASIMAGE a9pkiziw3vgwwebapp_dbreplicated1/1arungupta/couchbase:travel hr5s6ue54kwjwebapp_webreplicated1/1arungupta/couchbase-javaee:travel

Logs for the service can be seen using docker service logs -f webapp_web :