Hello Istio ⛵️, welcome to JHipster

Microservices are great. They break down bigger applications into smaller pieces.

They help you to

• Create more modular & Loosely coupled applications
• Parallelize and accelerate the rate of development
• Increase the overall productivity

But (Yes there is a but 😉) they are a pain to maintain. In short,

Microservices shift the problems from inside the application into layers between the applications.

This results in newer questions like,

• How to connect different services?
• How to secure the services?
• How to control the services? and
• How to monitor the services?

They are a difficult problem to solve. Seriously, playing with Transport Layer, for example, Layer 4 and Layer 7 is not an easy job.

While there are a lot of new applications, projects and products are created to address the problems with Microservices. But still maintaining high availability, resiliency and reliability all together are harder to fix.

Istio is a game changer. Istio components need not be installed or configured in each application. Instead, it runs along with your microservices independently. (Yes you heard it right it runs separately)

Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code. — Istio

From istio.io site

Istio helps to address these problems. Istio helps to

• Automatically load balance the traffic between services
• Configure and Control the routing between services
• Provides authentication and authorization between services
• Automatic metrics, logs, and traces collection for services

And the best of all is that you don’t need to change anything in the existing services. Istio is platform independent and designed to run in a variety of environments. — Check out Istio Architecture here

JHipster is a development platform to generate, develop and deploy Spring Boot + Angular/React Web applications and Spring microservices.

So what are we gonna do today,

• Generate Kubernetes & Istio configuration files for the generated JHipster microservices application
• Deploy them on the GCP.

Create a Microservices Gateway and Application using JHipster. Check out here for how to create a Microservices application using JHipster. The application is generated with default options.

Hooray, you have generated a cool microservice application with JHipster. Now it is time to generate Kubernetes and Istio configuration files for it.

Create Microservices Gateway and Application in sibling folders like this,

Go to hello-istio folder. Create a folder called k8s inside it. Go to k8s folder and run,

> jhipster kubernetes

Note: It checks whether you have installed Docker since we need Docker for creating and pushing the images and use them later.

As with other JHipster commands, this will ask you a set of questions. Let us answer them.

Let us choose the Microservice Application for the first question.

? Which *type* of application would you like to dep?
    Monolithic Application
  > Microservice Application 

The next question is to link your applications for which you have to generate the configuration files. If you are following this sample folder structure, just use the default path, else (thanks for being creative ✨) use the folder in which you have your microservice applications.

? Enter the root directory where your gateway(s) and microservices are located (../)

The next question is to select the respective microservices applications here.

? Which applications do you want to include in your configuration? (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◯ app1
 ◯ gate

Since microservices need monitoring, that helps the developers and operations to understand what is going on and where is the fault.

JHipster provides two options one with our own JHipster-Console. The other is with Prometheus. For the purpose of this example, I will choose No.

Do you want to setup monitoring for your applications ? (Use arrow keys)
❯ No
  Yes, for logs and metrics with the JHipster Console (based on ELK and Zipkin)
  Yes, for metrics only with Prometheus (only compatible with JHipster >= v3.12)

JHipster intelligently finds that you are using JHipster Registry in the microservices application and asks you to secure it with the password in the next question. I will go with the default here. Again, in real life scenario, use a difficult password, please.

JHipster registry detected as the service discovery and configuration provider used by your apps
? Enter the admin password used to secure the JHipster Registry (admin)

The next question is about the Kubernetes namespace, let us choose the default for this.

? What should we use for the Kubernetes namespace? (default)

Since we will create a Docker image and push this into the Docker repository. The next question is the Docker repository name.

? What should we use for the base Docker repository name? sendilkumarn

Let us push the Docker images using docker push command.

? What command should we use for push Docker image to repository? (docker push)

The next question is whether we need to configure Istio. There are three options here for you to choose.

• Not to have Istio at all
• A Manual sidecar injection.
• An Automatic sidecar injection using label tags

So what is the difference between Manual & Automatic sidecar injection?

In the case of manual, the deployment pod specs are modified to have sidecar related details. But in the case of automated, the sidecar is injected at the pod creation time.

Let us choose, Automatic injection. So we need not worry about adding this in every deployment.

Note: Check here for a detailed information about sidecar injection.

? Do you want to configure Istio? (Use arrow keys)
  Not required
  Manual sidecar injection (ensure istioctl in $PATH)
❯ Label tag namespace as automatic injection is already configured

Routing and Load balancing are one of the coolest features that Istio provides out of the box. Living outside your services they control routing the requests to the services and Load Balance the request between services or various versions of the services.

The next question is whether we need to generate Istio route files. Let us select Yes for the route files.

? Do you want to generate Istio route files?
  No
❯ Yes

The route files helps you to configure routing requests, set request timeouts, switch to Https, control traffic, circuit breaking, and health checking.

The next question is the service type for the edge services. Let us use Ingress for this.

? Choose the kubernetes service type for your edge services
  LoadBalancer - Let a kubernetes cloud provider automatically assign an IP
  NodePort - expose the services to a random port (30000 - 32767) on all cluster nodes
❯ Ingress - create ingresses for your services. Requires a running ingress controller

There are three options here

• Load Balancer — This will create an external IP for the services and you can use that IP to access the application.
• Nodeport — This will use the cluster IP and expose’s the service via a static port.
• Ingress — It is a collection of rules that allow inbound connections to the services.

Since we have selected Ingress, the next question is to say a DNS with which we can route the services. If you have a domain name you can use that here, else give a dummy entry here and change your etc/hosts file to match the IP with the Domain name.

? What is the root FQDN for your ingress services (e.g. example.com, sub.domain.co, www.10.10.10.10.xip.io, [namespace.ip]...)? (default.192.168.99.100.nip.io) sendilkumarn.com

If you don’t have the DNS, then edit your /etc/hosts file to have this,

x.x.x.x  sendilkumarn.com

Sweet 🎉🎉🎉, You have created Kubernetes & Istio configuration files. Let us see what JHipster has actually created and deploy it to GCP in part 2.