Deploy Microservices

Deploy customer

Make sure you are logged in

  1. oc whoami
  2. or
  3. kubectl config current-context

and you have setup the project/namespace

  1. oc new-project tutorial
  2. or
  3. kubectl create namespace tutorial
  4. kubectl config set-context $(kubectl config current-context) --namespace=tutorial

Give the tutorial project the required privileges.

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

Then clone the git repository

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

Start deploying the microservice projects, starting with customer

Make sure istioctl is in your PATH:

  1. $ istioctl version
  2. client version: 1.3.0
  3. control plane version: 1.3.0

Deploy Customer

You will deploy docker images that were previously built for this tutorial. If you want to build customer using Quarkus visit: Build Customer
You will deploy docker images that were previously built for this tutorial. If you want to build customer using Spring Boot visit: Build Customer Spring Boot

If you have not built the images on your own then let’s deploy the customer pod with its sidecar using the already built images for this tutorial:

  1. oc apply -f <(istioctl kube-inject -f customer/kubernetes/Deployment.yml) -n tutorial
  2. oc create -f customer/kubernetes/Service.yml -n tutorial
  4. or
  6. kubectl apply -f <(istioctl kube-inject -f customer/kubernetes/Deployment.yml) -n tutorial
  7. 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.

  1. oc create -f customer/kubernetes/Gateway.yml -n tutorial
  2. or
  3. kubectl create -f customer/kubernetes/Gateway.yml -n tutorial
  5. oc get pods -w -n tutorial
  6. or
  7. 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

  1. 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.

  1. customer => UnknownHostException: preference

Also review the logs

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

You should see a stacktrace containing this cause:

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

Deploy Preference

You will deploy docker images that were previously built for this tutorial. If you want to build preference with Quarkus visit: Build Preference
You will deploy docker images that were previously built for this tutorial. If you want to build preference with Spring Boot visit: Build Preference Spring Boot

If you have not built the images on your own then let’s deploy the customer pod with its sidecar using the already built images for this tutorial:

  1. oc apply -f <(istioctl kube-inject -f preference/kubernetes/Deployment.yml) -n tutorial
  2. oc create -f preference/kubernetes/Service.yml -n tutorial
  4. or
  6. kubectl apply -f <(istioctl kube-inject -f preference/kubernetes/Deployment.yml)  -n tutorial
  7. kubectl create -f preference/kubernetes/Service.yml -n tutorial

Wait preference to be deployed

  1. oc get pods -w  -n tutorial
  2. or
  3. 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

  1. 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
  1. customer => Error: 503 - preference => UnknownHostException: recommendation

and check out the logs

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

You should see a stacktrace containing this cause:

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

Deploy Recommendation

You will deploy docker images that were previously built for this tutorial. If you want to build recommendation with Quarkus visit: Build Recommendation
You will deploy docker images that were previously built for this tutorial. If you want to build recommendation with Spring Boot visit: Build Recommendation Spring Boot

If you have not built the images on your own then let’s deploy the customer pod with its sidecar using the already built images for this tutorial:

  1. oc apply -f <(istioctl kube-inject -f recommendation/kubernetes/Deployment.yml)  -n tutorial
  2. oc create -f recommendation/kubernetes/Service.yml  -n tutorial
  3. oc get pods -w -n tutorial
  5. or
  7. kubectl apply -f <(istioctl kube-inject -f recommendation/kubernetes/Deployment.yml) -n tutorial
  8. kubectl create -f recommendation/kubernetes/Service.yml -n tutorial
  9. 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

  1. curl istio-ingressgateway-istio-system.$(minishift ip).nip.io/customer

it should now return

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

and you can monitor the recommendation logs with

  1. stern $(kubectl get pods|grep recommendation-v1|awk '{ print $1 }'|head -1) -c recommendation
  2. or
  3. 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:

  1. cd {servicename}/java/{quarkus|springboot|vertx}
  3. vi src/main/java/com/redhat/developer/demos/{servicename}/{Servicename}{Controller|Verticle}.java

Make your changes, save it and then:

  1. mvn clean package
  2. docker build -t example/{servicename}:v1 .
  4. oc get pods -o jsonpath='{.items[*].metadata.name}' -l app={servicename}
  5. oc get pods -o jsonpath='{.items[*].metadata.name}' -l app={servicename},version=v1
  6. oc delete pod -l app={servicename},version=v1 -n tutorial{namespace-suffix}
  8. or
  10. kubectl get pods -o jsonpath='{.items[*].metadata.name}' -l app={servicename}
  11. kubectl get pods -o jsonpath='{.items[*].metadata.name}' -l app={servicename},version=v1
  12. 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

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