Walking through the generated files

The files generated by JHipster are in the following structure. That is, each application will have its own folder and the files related to that service will be present inside it.

We will start with the gateway application. There will be three generated files, which will be the gateway-service, gateway-mysql, and gateway-deployment.yml files.

The following is the gateway-service.yml file:

apiVersion: v1
kind: Service
metadata: 
    name: gateway
    namespace: default
    labels:
        app: gateway
spec:
    selector:
        app: gateway
    type: LoadBalancer
ports:
 - name: web
   port: 8080

The first line defines the API version of Kubernetes, followed by the kind of template or object that this template carries. This template will have a service inside of it.

Then, we will have the metadata information. Kubernetes uses this metadata information to group certain services together. In the metadata, we can define:

The service name
The namespace it belongs to
The labels, which are key and value pairs

Then, we will define the spec. The spec in the Kubernetes object will provide the state of the service. In the spec, we can define the number of replicas we need. We can also define the selector, within which we can specify the service with identifiers. We can also specify the type of the service. Kubernetes will take the information from this spec and then maintain the application in the state provided (we will have a look at the spec gateway in a while), followed by the ports in which port the application should run. This is similar to the Dockerfile, so we are exposing the 8080 port for the gateway service.

Then, we have the gateway-mysql.yml file, where we have defined our MySQL server for the gateway application. The difference here is that the spec points to gateway-mysql, which is defined in the same file and is exposed on port 3306:

apiVersion: v1
kind: Service
metadata:
    name: gateway-mysql
    namespace: default
spec:
    selector:
        app: gateway-mysql
ports:
    - port: 3306

In the gateway-mysql app declaration, we have specified the database and environment properties that are needed for our application to run. Here, the kind is mentioned as deployment. The job of the deployment object is to change the state of the services to the state that is defined in the deployment object.

Here, we have defined a single replica of the MySQL server, followed by the spec, where we have mentioned the version of MySQL that we need (the container). This is then followed by the username, password, and then the database schema. We can also specify the volume information with volume mounts for persistent storage:

Note: we can also define a spec inside a spec object (as shown in the following code):

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    ... // metadata
spec:
    replicas: 1
    ... // metadata related information
    spec:
        ... //volumes and other information
        containers:
         - name: mysql
           image: mysql:5.7.20
        env:
            ...  // environment details
        ports:
            ... // port
        volumeMounts:
            ... //Mapping the volume to the external persistent location

Similarly, we have gateway-deployment.yml, in which we have defined the gateway application and its environment properties along with the other details like ports, probes and so on.

A similar approach is done for both the invoice and notification services. You can find them in their respective folders.

In JHipster-registry, alongside Service and Deployment, we have defined Secret and StatefulSet.

The secret is used to handle passwords. It will be an opaque type and the password is base64 encoded.

Then, we have the StatefulSet, which are similar to pod except they have a sticky identity. Pods are dynamic in nature. These pods have a persistent identifier that is maintained throughout. It makes sense for a registry server to be defined as a StatefulSet, since it is essential that the registry server should be identified by a persistent identifier. This enables all services to connect to that single endpoint and get the necessary information. If the registry server is down, then communication between the services will also have problems, since the services connect to other services via the registry server.

There are various options that are available to set the controller, which are as follows:

Replica Set: Provides a replica of pods at any time with selectors
Replica Controller: Provides a replica of pods without any selectors
StatefulSet: Makes the pod unique by providing it with a persistent identifier
DaemonSet: Provides a copy of the pod which is going to be run

The JHipster Registry is configured in a cluster and with high availability. The UI access to the JHipster Registry is also restricted to the cluster for better security.

Similarly, configuration files are generated for the JHipster Console, and they are placed in a console folder, which is jhipster-console.yml, where the JHipster Console is also defined.

The JHipster Console runs on an ELK stack, so we need Elasticsearch, which is defined in jhipster-elasticsearch.yml, followed by Logstash in the jhipster-logstash.yml file.