Make sure you are logged in
oc whoami
or
kubectl config current-contextand 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
oc adm policy add-scc-to-user privileged -z default -n tutorialThen clone the git repository
git clone https://github.com/redhat-developer-demos/istio-tutorial
cd istio-tutorialStart deploying the microservice projects, starting with customer
Make sure istioctl is in your PATH:
$ istioctl version
version.BuildInfo{Version:"1.1.1", GitRevision:"2b1331886076df103179e3da5dc9077fed59c989", User:"root", Host:"7077232d-4c6c-11e9-813c-0a580a2c0506", GolangVersion:"go1.10.4", DockerHub:"docker.io/istio", BuildStatus:"Clean", GitTag:"1.1.0-17-g2b13318"}|
Note
|
Your very first Docker build will take a bit of time as it downloads all the layers. Subsequent rebuilds of the Docker image, updating only the microservice layer will be very fast. |
cd customer/java/quarkus
mvn clean package -DskipTests
docker build -t example/customer .
docker images | grep customerNow let’s deploy the customer pod with its sidecar
oc apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment.yml) -n tutorial
oc create -f ../../kubernetes/Service.yml -n tutorial
or
kubectl apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment.yml) -n tutorial
kubectl create -f ../../kubernetes/Service.yml -n tutorialSince the customer service is the one our users will interact with, let’s add an OpenShift Route that exposes that endpoint.
oc expose service customer -n tutorial
oc get route -n tutorial
oc get pods -w -n tutorial
or
kubectl get route -o=jsonpath='{.items[0].spec.host}'
kubectl get pods -w|
Important
|
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 customer-tutorial.$(minishift ip).nip.ioYou 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 customerYou should see a stacktrace containing this cause:
customer-6fc99b7bfd-5st28 customer Caused by: java.net.UnknownHostException: preferenceBack to the main istio-tutorial directory
cd ../../..cd preference/java/quarkus
mvn clean package -DskipTests
docker build -t example/preference:v1 .
docker images | grep preference
oc apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment.yml) -n tutorial
oc create -f ../../kubernetes/Service.yml
or
kubectl apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment.yml) -n tutorial
kubectl create -f ../../kubernetes/Service.ymloc get pods -w -n tutorial
or
kubectl get pods -wWait until the status is Running and there are 2/2 pods in the Ready column. To exit, press Ctrl+C
curl customer-tutorial.$(minishift ip).nip.ioIt will respond with an error since the service recommendation is not yet deployed.
|
Note
|
We could make this a bit more resilient in a future iteration of this tutorial |
customer => Error: 503 - preference => UnknownHostException: recommendationand check out the logs
stern $(kubectl get pods|grep preference|awk '{ print $1 }'|head -1) -c preference
or
stern "preference-\w" -c preferenceYou should see a stacktrace containing this cause:
preference-v1-898764bdb-hz7s6 preference Caused by: java.net.UnknownHostException: recommendationBack to the main istio-tutorial directory
cd ../../..|
Important
|
The tag v1 at the end of the image name matters. We will be creating a v2 version of recommendation later in this tutorial. Having both a v1 and v2 version of the recommendation code will allow us to exercise some interesting aspects of Istio’s capabilities.
|
cd recommendation/java/quarkus
mvn clean package -DskipTests
docker build -t example/recommendation:v1 .
docker images | grep recommendation
oc apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment.yml) -n tutorial
oc create -f ../../kubernetes/Service.yml -n tutorial
oc get pods -w
or
kubectl apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment.yml) -n tutorial
kubectl create -f ../../kubernetes/Service.yml
kubectl get pods -wWait until the status is Running and there are 2/2 pods in the Ready column. To exit, press Ctrl+C
curl customer-tutorial.$(minishift ip).nip.ioit should now return
customer => preference => recommendation v1 from '99634814-sf4cl': 1and 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-v1Back to the main istio-tutorial directory
cd ../../..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}.javaMake 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
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=v1Why 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} | grep Replicas
or
kubectl describe deployment {servicename} | grep Replicas