Deploy Microservices

Create an environment variable for your user and log into OpenShift.

export WORKSHOP_USER=<your-username-number>


#Example:
export WORKSHOP_USER=1

oc login -u user$WORKSHOP_USER -p openshift https://master.jconf-d4f8.openshiftworkshop.com

Deploy customer

Make sure you are logged in

oc whoami
or
kubectl config current-context

and you have setup the project/namespace

oc new-project tutorial-$WORKSHOP_USER
or
kubectl create namespace tutorial-$WORKSHOP_USER
kubectl config set-context $(kubectl config current-context) --namespace=tutorial-$WORKSHOP_USER

Then clone the git repository

Start deploying the microservice projects, starting with customer

Make sure istioctl is in your PATH:

$ istioctl version
version.BuildInfo{Version:"1.1.9", GitRevision:"879413c25b871ae6fd0df82bea1605baf12cba2e", User:"root", Host:"161bf1f4-8ef6-11e9-887b-0a580a2c0403", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Clean", GitTag:"1.1.8-4-g879413c"}

Deploy Customer

You will deploy docker images that were privously built. If you want to build customer visit: Build Customer

Now let’s deploy the customer pod with its sidecar

oc apply -f <(istioctl kube-inject -f customer/kubernetes/Deployment.yml) -n tutorial-$WORKSHOP_USER
oc create -f customer/kubernetes/Service.yml -n tutorial-$WORKSHOP_USER

or

kubectl apply -f <(istioctl kube-inject -f customer/kubernetes/Deployment.yml) -n tutorial-$WORKSHOP_USER
kubectl create -f customer/kubernetes/Service.yml -n tutorial-$WORKSHOP_USER

Expose customer

Since the customer service is the one our users will interact with, let’s add an OpenShift Route that exposes that endpoint.

envsubst < customer/kubernetes/Gateway.workshop.yml | oc create -f - -n tutorial-$WORKSHOP_USER
or
envsubst < customer/kubernetes/Gateway.workshop.yml | kubectl create -f - -n tutorial-$WORKSHOP_USER

oc get pods -w -n tutorial-$WORKSHOP_USER
or
kubectl get pods -w -n tutorial-$WORKSHOP_USER
If your pod fails with ImagePullBackOff, it’s possible that your current terminal isn’t using the proper Docker Environment. See Setup environment.

Wait until the status is Running and there are 2/2 pods in the Ready column. To exit, press Ctrl+C

Then test the customer endpoint

curl istio-ingressgateway-istio-system.apps.jconf-d4f8.openshiftworkshop.com/customer$WORKSHOP_USER

You should see the following error because the services preference and recommendation are not yet deployed.

customer => UnknownHostException: preference

Also review the logs

stern $(kubectl get pods|grep customer|awk '{ print $1 }'|head -1) -c customer
or
stern "customer-\w" -c customer

You should see a stacktrace containing this cause:

customer-6fc99b7bfd-5st28 customer Caused by: java.net.UnknownHostException: preference

Deploy Preference

You will deploy docker images that were privously built. If you want to build preference visit: Build Preference

Now let’s deploy the preference pod with its sidecar

oc apply -f <(istioctl kube-inject -f preference/kubernetes/Deployment.yml) -n tutorial-$WORKSHOP_USER
oc create -f preference/kubernetes/Service.yml -n tutorial-$WORKSHOP_USER

or

kubectl apply -f <(istioctl kube-inject -f preference/kubernetes/Deployment.yml)  -n tutorial-$WORKSHOP_USER
kubectl create -f preference/kubernetes/Service.yml -n tutorial-$WORKSHOP_USER

Wait preference to be deployed

oc get pods -w  -n tutorial-$WORKSHOP_USER
or
kubectl get pods -w -n tutorial-$WORKSHOP_USER

Wait until the status is Running and there are 2/2 pods in the Ready column. To exit, press Ctrl+C

curl istio-ingressgateway-istio-system.apps.jconf-d4f8.openshiftworkshop.com/customer$WORKSHOP_USER

It will respond with an error since the service recommendation is not yet deployed.

We could make this a bit more resilient in a future iteration of this tutorial
customer => Error: 503 - preference => UnknownHostException: recommendation

and check out the logs

stern $(kubectl get pods|grep preference|awk '{ print $1 }'|head -1) -c preference
or
stern "preference-\w" -c preference

You should see a stacktrace containing this cause:

preference-v1-898764bdb-hz7s6 preference Caused by: java.net.UnknownHostException: recommendation

Deploy Recommendation

You will deploy docker images that were privously built. If you want to build recommendation visit: Build Recommendation

Now let’s deploy the recommendation pod with its sidecar

oc apply -f <(istioctl kube-inject -f recommendation/kubernetes/Deployment.yml)  -n tutorial-$WORKSHOP_USER
oc create -f recommendation/kubernetes/Service.yml  -n tutorial-$WORKSHOP_USER
oc get pods -w -n tutorial-$WORKSHOP_USER

or

kubectl apply -f <(istioctl kube-inject -f recommendation/kubernetes/Deployment.yml) -n tutorial-$WORKSHOP_USER
kubectl create -f recommendation/kubernetes/Service.yml -n tutorial-$WORKSHOP_USER
kubectl get pods -w -n tutorial-$WORKSHOP_USER

Wait recommendation to be deployed

Wait until the status is Running and there are 2/2 pods in the Ready column. To exit, press Ctrl+C

curl istio-ingressgateway-istio-system.apps.jconf-d4f8.openshiftworkshop.com/customer$WORKSHOP_USER

it should now return

customer => preference => recommendation v1 from '99634814-sf4cl': 1

and you can monitor the recommendation logs with

stern $(kubectl get pods|grep recommendation-v1|awk '{ print $1 }'|head -1) -c recommendation
or
stern "recommendation-v1-\w" -c recommendation-v1

Updating Redeploying Code

When you wish to change code (e.g. editing the .java files) and wish to "redeploy", simply:

cd {servicename}/java/{quarkus|springboot|vertx}

vi src/main/java/com/redhat/developer/demos/{servicename}/{Servicename}{Controller|Verticle}.java

Make your changes, save it and then:

mvn clean package
docker build -t example/{servicename}:v1 .

oc get pods -o jsonpath='{.items[*].metadata.name}' -l app={servicename}
oc get pods -o jsonpath='{.items[*].metadata.name}' -l app={servicename},version=v1
oc delete pod -l app={servicename},version=v1 -n tutorial{namespace-suffix}

or

kubectl get pods -o jsonpath='{.items[*].metadata.name}' -l app={servicename}
kubectl get pods -o jsonpath='{.items[*].metadata.name}' -l app={servicename},version=v1
kubectl delete pod -l app={servicename},version=v1 -n tutorial{namespace-suffix}

Why the delete pod?

Based on the Deployment configuration, Kubernetes/OpenShift will recreate the pod, based on the new docker image as it attempts to keep the desired replicas available

oc describe deployment {servicename}  -n tutorial{namespace-suffix}| grep Replicas
or
kubectl describe deployment {servicename} -n tutorial{namespace-suffix} | grep Replicas