anchor.diff:  docker start server3
   ----
   
  -## OpenShift v3 (Optional Part, No Windows )
  +TODO: Is there any way to visualize containers in a cluster? Use Docker REST API?
  +
  +## Starting Multiple Containers Using Docker Compose
  +
  +Docker Compose script is only downloadable for OSX and Linux.
  +
  +TODO: What are the exact steps to get it running on Windows?
  +
  +Multiple containers, as in <<JavaEE_Application_Docker_Cluster>> can be easily started using Docker Compose, or Compose for short.
  +
  +If you have some additional time, you can take this part of the lab:
  +
  +http://blog.arungupta.me/docker-compose-orchestrate-containers-techtip77/
  +
  +## Java EE Application on Kubernetes
  +
  +
  +## OpenShift v3 (Optional Part, No Windows)
  +
   If you are on a Mac or Linux system, you can also try out clustering with OpenShift V3 and Kubernetes. For this is an optional step in the lab, you can follow these separate instructions.
   
   http://blog.arungupta.me/openshift-v3-getting-started-javaee7-wildfly-mysql/
   
  -
  -## Docker Compose (Optional, No Windows Version without Python)
  -Docker Orchestration using Fig showed how to defining and control a multi-container service using Fig. Since then, Fig has been renamed to Docker Compose, or Compose for short.
  -If you have some additional time, you can take this part of the lab:
  -
  -http://blog.arungupta.me/docker-compose-orchestrate-containers-techtip77/
  -
  -
   ## References
   
   . JBoss and Docker: http://www.jboss.org/docker/
  
positive.code: .Streaming Logs
  image::images/jdbs-docker-tools5.png[]
  
  **Managing Docker Containers**
  
  The Docker Containers view lets the user manage her containers. The view toolbar provides commands to start, stop, pause, unpause, display the logs and kill containers.
  
  
negative.code: mvn -s settings.xml -f ticket-monster/demo/pom.xml -Pdocker-test test
  ----
  
  http://blog.arungupta.me/run-javaee-tests-wildfly-docker-arquillian-cube/
  
  [[JavaEE_Application_Docker_Cluster]]
  ## Java EE Application on Container Cluster
  
  A frequent requirement for Java EE based applications is running them on a cluster of application server. While setup and test can be complicated on developer machines, this is where Docker can play to it's full potential. With the help of images and automatic port mapping, we're ready to test Ticket Monster on a couple of WildFly instances and add and remove them randomly.
  
  The diagram below shows what will be achieved in this section:
  
  .Standalone Cluster with WildFly and mod_cluster
  image::images/wildfly_cluster1.png[]
  
  . Start Apache HTTPD server
  +
  [source, text]
  ----
  docker run -d --name modcluster -p 80:80 <INSTRUCTOR_IP>:5000/mod_cluster
  ----
  +
  . Open http://dockerhost/mod_cluster_manager in your browser to see the empty console as:
  +
  .Apache HTTPD runing mod_cluster_manager interface
  image::images/wildfly_cluster2.png[]
  +
  . Start the first WildFly instance:
  +
  [source, text]
  ----
  docker run -d --name server1 --link db:db --link modcluster:modcluster <INSTRUCTOR_IP>:5000/ticketmonster-pgsql-wildfly
  ----
  +
  Besides linking the database container using `--link db:db`, we also link the ``modcluster'' container. This should be done rather quickly and if you now revisit the http://dockerhost/mod_cluster_manager/[mod_cluster_manager] in your browser, then you can see that the first server was registered with the loadbalancer:
  +
  .First WildFly instance registered with Load Balancer
  image::images/wildfly_cluster3.png[]
  +
  . To make sure the Ticket Monster application is also running just visit http://dockerhost/ticket-monster and you will be presented with the Ticket Monster welcome screen.
  +
  .Clustered Ticket Monster Application
  image::images/wildfly_cluster4.png[]
  +
  . Start as many WildFly instances as you want (and your computer memory can handle):
  +
  [source, text]
  ----
  docker run -d --name server2 --link db:db --link modcluster:modcluster <INSTRUCTOR_IP>:5000/ticketmonster-pgsql-wildfly
  docker run -d --name server3 --link db:db --link modcluster:modcluster <INSTRUCTOR_IP>:5000/ticketmonster-pgsql-wildfly
  docker run -d --name server4 --link db:db --link modcluster:modcluster <INSTRUCTOR_IP>:5000/ticketmonster-pgsql-wildfly
  ----
  +
  . Stop some servers and check the application behavior:
  +
  [source, text]
  ----
  docker stop server1
  docker stop server3
  ----
  
  TODO: Pick the parts that need to be described in more detail from https://goldmann.pl/blog/2013/10/07/wildfly-cluster-using-docker-on-fedora/
  
  ## Java EE Application on Docker Swarm Cluster
  
  Docker Swarm solves one of the fundamental limitations of Docker where the containers could only run on a single Docker host. Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual host.
  
  .Key Components of Docker Swarm
  image::images/swarm1.png[]
  
  *Swarm Manager*: Docker Swarm has a Master or Manager, that is a pre-defined Docker Host, and is a single point for all administration. Currently only a single instance of manager is allowed in the cluster. This is a SPOF for high availability architectures and additional managers will be allowed in a future version of Swarm with #598. TODO: ADD LINK.
  
  *Swarm Nodes*: The containers are deployed on Nodes that are additional Docker Hosts. Each Swarm Node must be accessible by the manager, each node must listen to the same network interface (TCP port). Each node runs a node agent that registers the referenced Docker daemon, monitors it, and updates the discovery backend with the node’s status. The containers run on a node.
  
  *Scheduler Strategy*: Different scheduler strategies (``binpack'', ``spread'' (default), and ``random'') can be applied to pick the best node to run your container. The default strategy optimizes the node for least number of running containers. There are multiple kinds of filters, such as constraints and affinity.  This should allow for a decent scheduling algorithm.
  
  *Node Discovery Service*: By default, Swarm uses hosted discovery service, based on Docker Hub, using tokens to discover nodes that are part of a cluster. However etcd, consul, and zookeeper can be also be used for service discovery as well. This is particularly useful if there is no access to Internet, or you are running the setup in a closed network. A new discovery backend can be created as explained here. It would be useful to have the hosted Discovery Service inside the firewall and #660 will discuss this.
  
  **Standard Docker API:** Docker Swarm serves the standard Docker API and thus any tool that talks to a single Docker host will seamlessly scale to multiple hosts now. That means if you were using shell scripts using Docker CLI to configure multiple Docker hosts, the same CLI would can now talk to Swarm cluster and Docker Swarm will then act as proxy and run it on the cluster.
  
  There are lots of other concepts but these are the main ones.
  
  . Create a Swarm cluster. The easiest way of using Swarm is, by using the official Docker image:
  +
  [source, text]
  ----
  docker run swarm create
  ----
  +
  This command returns a <TOKEN> and is the unique cluster id. It will be used when creating master and nodes later. This cluster id is returned by the hosted discovery service on Docker Hub.
  +
  NOTE: Make sure to note this cluster id now as there is no means to list it later.
  +
  . Swarm is fully integrated with Docker Machine, and so is the easiest way to get started. Let's create a Swarm Master next:
  +
  [source, text]
  ----
  docker-machine create -d virtualbox --swarm --swarm-master --swarm-discovery token://<TOKEN> swarm-master
  ----
  +
  The option "--swarm" configures the machine with Swarm, "--swarm-master" configures the created machine to be Swarm master. Make sure to replace cluster id after token:// with that obtained in the previous step. Swarm master creation talks to the hosted service on Docker Hub and informs that a master is created in the cluster.
  +
  . Connect to this newly created master and find some more information about it:
  +
  [source, text]
  ----
  eval "$(docker-machine env swarm-master)"
  docker info
  ----
  +
  NOTE: If you're on Windows, use the "docker-machine env swarm-master" command only and copy the output into an editor to replace all appearances of EXPORT with SET and issue the three commands at your command prompt, remove the quotes and all duplicate appearences of "/".
  +
  . Create Swarm nodes.
  +
  [source, text]
  ----
  docker-machine create -d virtualbox --swarm --swarm-discovery token://<TOKEN> swarm-node-01
  ----
  +
  Node creation talks to the hosted service at Docker Hub and joins the previously created cluster. This is specified by --swarm-discovery token://... and specifying the cluster id obtained earlier.
  +
  . To make it a real cluster, let's create a second node:
  +
  [source, text]
  ----
  docker-machine create -d virtualbox --swarm --swarm-discovery token://<TOKEN> swarm-node-02
  ----
  +
  . List all the nodes / Docker machines, that has been created so far.
  +
  [source, text]
  ----
  TODO: ADD CODE
  ----
  +
  This shows the output as:
  +
  [source, text]
  ----
  TODO: ADD CODE
  ----
  +
  The machines that are part of the cluster have the cluster’s name in the SWARM column, blank otherwise. For example, ``mymachine'' is a standalone machine where as all other machines are part of swarm-master cluster. The Swarm master is also identified by (master) in the SWARM column.
  +
  . Connect to the Swarm cluster and find some information about it:
  +
  [source, text]
  ----
  eval "$(docker-machine env --swarm swarm-master)"
  docker info
  ----
  +
  This shows the output as:
  +
  [source, text]
  ----
  TODO: ADD CODE
  ----
  +
  There are 3 nodes – one Swarm master and 2 Swarm nodes. There is a total of 4 containers running in this cluster – one Swarm agent on master and each node, and there is an additional swarm-agent-master running on the master. This can be verified by connecting to the master and listing all the containers:
  +
  [source, text]
  ----
  eval "$(docker-machine env swarm-master)"
  docker info
  ----
  +
  . List nodes in the cluster with the following command:
  +
  [source, text]
  ----
  docker run swarm list token://<TOKEN>
  ----
  +
  The complete cluster is in place now, and we need to deploy the Ticket Monster application to it.
  
  Swarm takes care for the distribution of the deployments across the nodes. The only thing, we need to do is to deploy the application as explained already:
  
  Double check, if the db instance is still running. If not, start it again.
  