adding kubernetes docs

.gitignore

@@ -7,3 +7,4 @@ target
 .settings
 deployments
 orders-service/ObjectStore/
+deployment/kubernetes/istio/istio-0.*

Readme.md

@@ -0,0 +1,51 @@
+# Ticket Monster Monolith to Microservices
+
+This is project is a monorepo of projects that illustrate migrating a monolith application to microservices.
+
+The motivation for the patterns used in this repo are articulated in detail in [this blog post](http://blog.christianposta.com/microservices/low-risk-monolith-to-microservice-evolution/)
+
+## Quick start
+
+Whether using Kubernetes or OpenShift Origin, make sure you have [Istio installed](https://istio.io/docs/setup/kubernetes/quick-start.html) .
+
+Check the [deployment](./deployment) folder. In here we have scripts for deploying to [Kubernetes](http://kubernetes.io) and [OpenShift Origin](https://www.openshift.org). In the `$platform/demo/` folder is step-by-step instructions for running the demo. 
+
+
+## Getting started with the projects
+
+There are a series of projects used to illustrate a migration to microservices from a Java EE monolith. 
+
+### monolith
+The getting started experience begins with the [monolith](./monolith/README.md) project. In this project we deploy our monolith application and understand the domain, architecture, and structure of the application that will be the foundation for successive iterations.
+
+
+### tm-ui
+
+The `tm-ui-*` folders contain different versions of the front-facing UI that we use as we migrate from a monolith to split out the UI to the set of microservices.
+
+### backend
+
+The `backend-*` folders contain the monolith with the UI removed and successive iterations of evolution. With `backend-v1`, we have taken the monolith as it is and removed the UI. It contains a REST API that can be called from the UI. In `backend-v2` we've stated adding feature flags for controlling the introduction of a new microservice. See each respective sub project for more information.
+
+
+### orders-service
+
+This 
+
+
+
+
+## Using Minikube (Kubernetes)
+
+Bootstrapping minikube:
+
+```
+$ minikube start --vm-driver=xhyve --memory=4096 --disk-size=30g --kubernetes-version=v1.7.5 
+```
+
+## Using Minishift (OpenShift Origin)
+
+Bootstrapping in minishift:
+
+```
+```

deployment/kubernetes/istio/install.sh

@@ -0,0 +1,11 @@
+#!/usr/bin/env bash
+curl -L https://git.io/getLatestIstio | sh -
+ISTIO=`ls | grep istio`
+export PATH="$PATH:~/$ISTIO/bin"
+cd $ISTIO
+kubectl apply -f install/kubernetes/istio.yaml
+
+kubectl create -f install/kubernetes/addons/prometheus.yaml
+kubectl create -f install/kubernetes/addons/grafana.yaml
+kubectl create -f install/kubernetes/addons/servicegraph.yaml
+kubectl create -f install/kubernetes/addons/zipkin.yaml

monolith/README.md

@@ -1,74 +1,102 @@
-# TicketMonster - a JBoss example
+# Monolith TicketMonster
 
-TicketMonster is an online ticketing demo application that gets you started with JBoss technologies, and helps you learn and evaluate them.
+This is the monolith version of the TicketMonster app from the [tutorial on developers.redhat.com](https://developers.redhat.com/ticket-monster/).
 
-Here are a few instructions for building and running it. You can learn more about the example from the [tutorial](http://www.jboss.org/ticket-monster).
 
-## Updating the Performance dates
+This project illustrates the following concepts:
 
-_NOTE: This step is optional. It is necessary only if you want to update the dates of the Performances in the `import.sql` script in an automated manner. Updating the performance dates ensure that they are always set to some timestamp in the future, and ensures that all performances are visible in the Monitor section of the TicketMonster application._
+* App running in WildFly 10.x (EE 7)
+* Packaging as a Docker image using [fabric8-maven-plugin](https://maven.fabric8.io)
+* Connecting to a separate instance of `mysql` database
+* Arquillian integration tests (embedded/remote)
+* Deploying to Kubernetes with [fabric8-maven-plugin](https://maven.fabric8.io)
 
-1. Run the `update_import_sql` Perl script. You'll need the `DateTime`, `DateTime::Format::Strptime` and `Tie::File` Perl modules. These are usually available by default in your Perl installation.
-
-        $ perl update_import_sql.pl src/main/resources/import.sql
 
+## Running TicketMonster
+
+From the command line, you can run the application simply in a WildFly 10.x application server as simple as this:
+
+```
+mvn clean package wildfly:run
+```
+
+This builds the application with an embedded database and bootstraps an embedded application server and deploys the service available at [http://localhost:8080/ticket-monster](http://localhost:8080/ticket-monster). Give it a try to make sure everything comes up correctly.
+
+
+### Running with docker:
+
+If you're attached to a `docker` daemon:
+
+```
+docker run -it -p 8080:8080 ceposta/ticket-monster-monolith:latest
+```
+
+### Running on kubernetes
 
-## Building TicketMonster
+If you're connected to a Kubernetes instance, you can do a complete docker build and run of the application with the fabric8 maven plugin like this:
 
-TicketMonster can be built from Maven, by runnning the following Maven command:
+```
+mvn clean package -Pdefault,kubernetes fabric8:run
+```
 
-    mvn clean package
+## For developers: Building TicketMonster
+
+TicketMonster can be built from Maven, by running the following Maven command:
+
+```
+mvn clean package
+```
 
-### Building TicketMonster with tests
+### Building TicketMonster with integration tests
 
 If you want to run the Arquillian tests as part of the build, you can enable one of the two available Arquillian profiles.
 
 For running the tests in an _already running_ application server instance, use the `arq-wildfly-remote` profile.
 
-    mvn clean package -Parq-wildfly-remote
+```
+mvn clean package -Parq-wildfly-remote
+```
 
 If you want the test runner to _start_ an application server instance, use the `arq-wildfly-managed` profile. You must set up the `JBOSS_HOME` property to point to the server location, or update the `src/main/test/resources/arquillian.xml` file.
 
-    mvn clean package -Parq-wildfly-managed
+```
+mvn clean package -Parq-wildfly-managed
+```
 
-### Building TicketMonster with Postgresql (for OpenShift)
-
-If you intend to deploy into [OpenShift](http://openshift.com), you can use the `postgresql` and `openshift` profile
-
-    mvn clean package -Ppostgresql,openshift,default
+### Building TicketMonster with MySQL 
 
-### Building TicketMonster with MySQL (for OpenShift)
+If you want to build the WAR with support for MySQL database, build with the following profiles:
 
-If you intend to deploy into [OpenShift](http://openshift.com), you can use the `mysql` and `openshift` profiles
-
-    mvn clean package -Pmysql,openshift,deafult
+```
+mvn clean package -Pmysql,default
+```
+       
+Note, we explicitly enable the `mysql` profile and also the `default` profile. We keep the default profile around to skip integration tests. Leave it off to run them.    
 
-## Running TicketMonster
+### Building TicketMonster with MySQL and Kubernetes
 
-You can run TicketMonster into a local JBoss EAP 6.3 instance or on OpenShift.
+First you should deploy a `mysql` instance. Take a [look at a Kubernetes deployment for mysql from here](../deployment/kubernetes/core/monolith/).
 
-### Running TicketMonster locally
+Deploy the `mysql` kubernetes service:
 
-#### Start JBoss Enterprise Application Platform 6.3
+```
+kubectl apply -f deployment/kubernetes/core/monolith/mysql-svc.yml
+```
 
-1. Open a command line and navigate to the root of the JBoss server directory.
-2. The following shows the command line to start the server with the web profile:
+Next, deploy the `mysql` deployment:
 
-        For Linux:   JBOSS_HOME/bin/standalone.sh
-        For Windows: JBOSS_HOME\bin\standalone.bat
-		
-#### Deploy TicketMonster
+```
+kubectl apply -f deployment/kubernetes/core/monolith/mysql-deployment.yml
+```
 
-1. Make sure you have started the JBoss Server as described above.
-2. Type this command to build and deploy the archive into a running server instance.
-
-        mvn clean package wildfly:deploy
-
-	(You can use the `arq-wildfly-remote` profile for running tests as well)
+Lastly, deploy the latest version of the monolith:
 
-3. This will deploy `target/ticket-monster.war` to the running instance of the server.
-4. Now you can see the application running at `http://localhost:8080/ticket-monster`
+```
+mvn clean package -Pdefault,kubernetes,mysql fabric8:deploy
+```
 
-### Running TicketMonster in OpenShift
+To undeploy:
 
-TBD
+```
+mvn -Pdefault,kubernetes,mysql fabric8:undeploy
+```

monolith/src/test/resources/arquillian.xml

@@ -26,7 +26,7 @@
    <container qualifier="jboss" default="true">
       <!-- If you want to use the JBOSS_HOME environment variable, just delete the jbossHome property -->
       <configuration>
-         <property name="jbossHome">/Users/ceposta/dev/eap/wildfly-10.0.0.Final</property>
+         <!--<property name="jbossHome">/Users/ceposta/dev/eap/wildfly-10.0.0.Final</property>-->
       </configuration>
    </container>
 

tm-ui-v1/README.md

@@ -1,28 +1,27 @@
 ## Ticket Monster UI
 
 This proxy helps us keep friendly URLs even when there are composite UIs or composite microservice REST apis
-It also helps us avoid tripping the browser Same Origin policy
+It also helps us avoid tripping the browser Same Origin policy. We use a simple HTTP server (apache) to serve the static content and then use the reverse proxy plugins to proxy REST calls to the appropriate microservice:
 
-Build the docker container:
-
-> docker build -t ceposta/tm-ui:monolith .
-
-Run in kubernetes
+```
+# proxy for the admin microserivce
+ProxyPass "/rest" "http://ticket-monster:8080/rest"
+ProxyPassReverse "/rest" "http://ticket-monster:8080/rest"
+```
 
-> kubectl run tm-ui --image=ceposta/tm-ui:monolith --port=80
+## Running in docker
 
-Or using the resource file:
+The docker image for this project is `ceposta/tm-ui:monolith`
 
-> kubectl apply -f ../deployment/kubernetes/backend/tm-ui-deployment.yml
 
-Let's create the kubernetes service:
+## Developers:
 
-> kubectl apply -f ../deployment/kubernetes/backend/tm-ui-svc.yml
+Build the docker container:
 
-When it comes time to include this UI service in the routing between services, you may want to inject it with the istio side proxy:
+> docker build -t ceposta/tm-ui:monolith .
 
-> kubectl replace -f <(kubectl get deploy tm-ui -o yaml | istioctl kube-inject -f -)
+Run in kubernetes
 
-## Ticket Monster Monolith 
+> kubectl run tm-ui --image=ceposta/tm-ui:monolith --port=80
 
-If you want to build the version the UI that talks directly to the monolith (instead of the backend which is the REST API without the UI), then checkout SHA 0c570d1 and build this docker image. Right now it points to the `backend` service. You can see the tags for the `tm-ui` here: [https://hub.docker.com/r/ceposta/tm-ui/tags/](https://hub.docker.com/r/ceposta/tm-ui/tags/)
+Or using the resource files in the [deployment](../deployment/kubernetes/core/frontend/) folder.

tm-ui-v2/README.md

@@ -1,28 +1,28 @@
 ## Ticket Monster UI
 
 This proxy helps us keep friendly URLs even when there are composite UIs or composite microservice REST apis
-It also helps us avoid tripping the browser Same Origin policy
+It also helps us avoid tripping the browser Same Origin policy. We use a simple HTTP server (apache) to serve the static content and then use the reverse proxy plugins to proxy REST calls to the appropriate microservice:
 
-Build the docker container:
+```
+# proxy for the admin microserivce
+ProxyPass "/rest" "http://backend:8080/rest"
+ProxyPassReverse "/rest" "http://backend:8080/rest"
+```
 
-> docker build -t ceposta/tm-ui:backend .
 
-Run in kubernetes
-
-> kubectl run tm-ui --image=ceposta/tm-ui:backend --port=80
+## Running in docker
 
-Or using the resource file:
+The docker image for this project is `ceposta/tm-ui:backend`
 
-> kubectl apply -f ../deployment/kubernetes/backend/tm-ui-deployment.yml
+## Developers:
 
-Let's create the kubernetes service:
+Build the docker container:
 
-> kubectl apply -f ../deployment/kubernetes/backend/tm-ui-svc.yml
+> docker build -t ceposta/tm-ui:backend .
 
-When it comes time to include this UI service in the routing between services, you may want to inject it with the istio side proxy:
+Run in kubernetes
 
-> kubectl replace -f <(kubectl get deploy tm-ui -o yaml | istioctl kube-inject -f -)
+> kubectl run tm-ui --image=ceposta/tm-ui:backend --port=80
 
-## Ticket Monster Monolith 
+Or using the resource files in the [deployment](../deployment/kubernetes/core/frontend/) folder.
 
-If you want to build the version the UI that talks directly to the monolith (instead of the backend which is the REST API without the UI), then checkout SHA 0c570d1 and build this docker image. Right now it points to the `backend` service. You can see the tags for the `tm-ui` here: [https://hub.docker.com/r/ceposta/tm-ui/tags/](https://hub.docker.com/r/ceposta/tm-ui/tags/)