Deploy Microservices

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
or
kubectl create namespace tutorial
kubectl config set-context $(kubectl config current-context) --namespace=tutorial

Give the tutorial project the required privileges.

oc adm policy add-scc-to-user privileged -z default -n tutorial

Then clone the git repository

git clone https://github.com/redhat-developer-demos/istio-tutorial
cd istio-tutorial

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
oc create -f customer/kubernetes/Service.yml -n tutorial

or

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

Expose customer

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

oc create -f customer/kubernetes/Gateway.yml -n tutorial
or
kubectl create -f customer/kubernetes/Gateway.yml -n tutorial

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

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.$(minishift ip).nip.io/customer

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
oc create -f preference/kubernetes/Service.yml -n tutorial

or

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

Wait preference to be deployed

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

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.$(minishift ip).nip.io/customer

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
oc create -f recommendation/kubernetes/Service.yml  -n tutorial
oc get pods -w -n tutorial

or

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

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.$(minishift ip).nip.io/customer

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