[BETA] Deploying to Kubernetes

WARNING! This is a new sub-generator, of BETA quality. Use it at your own risk! Feedback is highly welcome!

This sub-generator allows deployment of your JHipster application to Kubernetes.

Limitations

Pre-requisites

You have to install:

You must have a Docker registry. If you don’t have one, you can use the official Docker Hub

Minikube

Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day.

You can use it to test your application before pushing it to Kubernetes.

Running the sub-generator

To generate config files for Kubernetes, run this command in a new folder:

yo jhipster:kubernetes

Then answer all the questions to deploy your application.

Which type of application would you like to deploy?

Your type of application depends on whether you wish to deploy a microservices architecture or classical applications.

Enter the root directory where your applications are located

Enter the path.

Which applications do you want to include in your Kubernetes configuration?

Select your applications.

Enter the admin password used to secure the JHipster Registry admin

This question is only displayed if you choose microservices architecture.

What should we use for the Kubernetes namespace?

See the documentation on namespace here

What should we use for the base Docker repository name?

If you choose Docker Hub as main registry, it will be your Docker Hub login.

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

The default command to push to Docker Hub is docker image push For example, if you use the Google Cloud to host your Docker images, it will be: gcloud docker push

Updating your deployed application

Preparing a new deployment

When your application is already deployed, you can re-deploy it by building a new Docker image:

./mvnw package -Pprod -DskipTests docker:build

Or when using gradle:

./gradlew -Pprod bootRepackage buildDocker -x test

Pushing to Docker Hub

Tag locally your image:

docker image tag application username/application

Push your image to Docker Hub:

docker image push username/application

Deploying a monolith application

Deploy your application:

kubectl apply -f application/

It will create a Kubernetes deployment for your application and its associated dependent services (database, elasticsearch…) as well as a Kubernetes service to expose the application to the outside.

Deploying a microservice application

Deploying a Service Registry in Kubernetes

Although, Kubernetes does feature its own internal service discovery with Kube-DNS, JHipster rely on Spring Cloud for service discovery, so it depends on a third party service registry like Eureka or Consul. This has the advantage of being platform independent and to work similarly in production and on a local development machine.

Consequently, for microservices applications, the JHipster Kubernetes sub-generator will generate Kubernetes manifest files to deploy service registries like the JHipster-Registry (based on Eureka) or Consul. Moreover, the generated microservices and gateway Kubernetes manifests will contains the appropriate configuration to register themselves to their central registry.

Managing the JHipster Registry or Consul in Kubernetes

For the JHipster Registry and Consul, StatefulSets configurations are provided. Those are a special kind of Kubernetes resource that can handle stateful applications and will let you scale your service registries for high-availability. For more information on high-availability for Eureka and Consul refer to their respective documentation.

Centralized configuration in Kubernetes

Centralized configuration is also setup using either Spring Cloud Config Server (when using the JHipster-Registry) or the Consul Key/Value store (when using Consul). By default, both configuration servers load their configuration from a Kubernetes ConfigMap which contains property files in this format :

apiVersion: v1
kind: ConfigMap
metadata:
  name: application-config
  namespace: default
data:
  application.yml: |- # global properties shared by all applications
    jhipster:
      security:
        authentication:
          jwt:
            secret: secret
  gateway-prod.yml: |- # gateway application properties for the "prod" profile
    foo:
      bar: foobar

By default, configuration servers run in development mode, which means that YAML property files are read directly from the filesystem and hot-reloaded on changes. For production it is advised to setup configuration from a git repository as explained in our microservice documentation for the JHipster-Registry config server and Consul config server.

More information