As microservices-based applications become more prevalent, both the number of and complexity of their interactions increases. Up until now much of the burden of managing these complex microservices interactions has been placed on the application developer, with different or non-existent support for microservice concepts depending on language and framework.
The service mesh concept pushes this responsibility to the infrastructure, with features for traffic management, distributed tracing and observability, policy enforcement, and service/identity security, freeing the developer to focus on business value. In this hands-on session you will learn how to apply some of these features to a simple polyglot microservices application running on top of OpenShift using Istio, an open platform to connect, manage, and secure microservices.
Istio is an open platform to connect, manage, and secure microservices. Istio provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in application code. OpenShift can automatically inject a special sidecar proxy throughout your environment to enable Istio management for your application. This proxy intercepts all network communication between your microservices microservices, and is configured and managed using Istio’s control plane functionality -- not your application code!
Kiali is an observability console designed to provide operational insight into the behavior and performance of the service mesh as a whole.
Jaeger is a utility for capturing distributed tracing information of requests as they travel throughout the mesh.
Prometheus and Grafana are used to capture metrics about the performance and behavior of the mesh.
These components combined together are the Red Hat OpenShift Service Mesh.
While this lab content was designed against the environment provided at the Red Hat Summit, the content can be used and deployed in virtually any OpenShift environment. It does, however, assume an OpenShift 4 environment.
You can deploy the lab guide as a container image. There are two steps. First, you need to gather information about your environment. Then, you can launch the lab guide using that information.
Deploying the lab guide will take two steps. First, you will need to get information about your cluster. Second, you will deploy the lab guide using the information you found so that proper URLs and references are automatically displayed in the guide.
Most of the information can be found in the output of the installer.
Export the API URL endpoint to an environment variable:
export API_URL=https://api......:6443Export the master/console URL to an environment variable:
export MASTER_URL=https://console-openshift-console.....Export the kubeadmin password as an environment variable:
export KUBEADMIN_PASSWORD=xxxIf you don't have the kubeadmin password but you do have a user that has access to the OpenShift 4 cluster, just be sure to log in with that user instead of kubeadmin where instructed in the lab guide.
Export the routing subdomain as an environment variable. When you
installed your cluster you specified a domain to use, and OpenShift built a
routing subdomain that looks like apps.clusterID.domain. For example,
apps.mycluster.company.com. Export this:
export ROUTE_SUBDOMAIN=apps.mycluster.company.comThis lab guide was built for an internal Red Hat system, so there are two additional things you will need to export. Please export them exactly as follows:
export GUID=xxxx
export BASTION_FQDN=foo.bar.comNow that you have exported the various required variables, you can deploy the
lab guide into your cluster. The following assumes you are logged in already
as kubeadmin and on a system with the oc client installed:
oc new-project labguide
oc new-app -n labguide --name istio \
quay.io/osevg/workshopper -e CONTENT_URL_PREFIX="https://raw.githubusercontent.com/thoraxe/istio-lab-summit-2019/master/instructions/" \
-e WORKSHOPS_URLS="https://raw.githubusercontent.com/thoraxe/istio-lab-summit-2019/master/instructions/_rhsummit18.yml" \
-e API_URL=$API_URL \
-e MASTER_URL=$MASTER_URL \
-e KUBEADMIN_PASSWORD=$KUBEADMIN_PASSWORD \
-e BASTION_FQDN=$BASTION_FQDN \
-e GUID=$GUID \
-e ROUTE_SUBDOMAIN=$ROUTE_SUBDOMAIN
oc expose service istioIn the /src/deployments folder of this repository are several YAML files. You will want to create a project called istio-tutorial and then create all of these YAML files. For example:
oc new-project istio-tutorial
oc create -n istio-tutorial -f https://raw.githubusercontent.com/thoraxe/istio-lab-summit-2019/master/src/deployments/curl.yaml
oc create -n istio-tutorial -f https://raw.githubusercontent.com/thoraxe/istio-lab-summit-2019/master/src/deployments/customer.yaml
oc create -n istio-tutorial -f https://raw.githubusercontent.com/thoraxe/istio-lab-summit-2019/master/src/deployments/gateway.yaml
oc create -n istio-tutorial -f https://raw.githubusercontent.com/thoraxe/istio-lab-summit-2019/master/src/deployments/preference.yaml
oc create -n istio-tutorial -f https://raw.githubusercontent.com/thoraxe/istio-lab-summit-2019/master/src/deployments/recommendation.yamlYour lab guide should deploy in a few moments. To find its url, execute:
oc get route admin -n labguideYou should be able to visit that URL and see the lab guide. From here you can follow the instructions in the lab guide.
Remember, this experience is designed for a provisioning system internal to Red Hat. Your lab guide will be mostly accurate, but slightly off.
lab-userGUIDGUID or other slightly off
thingsMachineSets are different depending on the EC2 region you choseBut, generally, everything should work. Just don't be alarmed if something looks mostly different than the lab guide.