We see a lot of people trying to deploy JHipster applications on Clever Cloud. It does not seem to be fully understood all the time. Especially with the differences between deploying on IaaS and PaaS. And since JHipsterConf is around the corner, it's the perfect time to write about it, to explain a bit what it is and how it can be deployed on PaaS platform like Clever Cloud.

What is JHipster?

If you are not familiar with JHipster, it's a scaffolding system to bootstrap applications using Spring Boot and AngularJS or React. You can choose to scaffold a monolithic application (Which are great and modular and everything because Spring Boot lets you build modular monolith. If you have no idea what you are doing you should start with this) or microservices architecture with an API Gateways and a registry.

When scaffolding microservices, you are using the Spring Boot and Netflix OSS stack. That’s something you want to know in general when looking for documentation online. Most of the things you will read here apply both to JHipster and to Spring Boot + Netflix OSS deployments.

JHipster or NetflixOSS versus IaaS or PaaS

Is there an incompatibility between JHipster/Netflix OSS and PaaS deployment? The reason I am raising this question is that this stack was pretty much made for IaaS deployment, more particularly AWS, where fewer things are managed than on any PaaS platform.

And as such JHipster comes up with lots of nifty tools to compensate the absence of services usually provided by higher level solutions like CaaS or PaaS. This is especially true when you are deploying a microservices architecture. So, will this overlap when deploying on Clever Cloud? Are things even compatible? Yes, it is, and in this post, I will show you some exciting things you can do.

Reverse proxy and Service Registry

One of the central question raised by our users doing microservices is how do you configure the JHipster Registry (Eureka in Netflix OSS terms). It maintains a registry of all the instances of your architecture services.

Going back to a classic AWS deployment, the typical behavior when you manage several instances of the same application is to deploy those apps to VMs. They all have their own set of IP/port. In their configuration, they have the different addresses of their Eureka server. They will register to that server as an instance of a particular application, identified by that IP/port couple. It is great when you manage your private network and plan to expose everything through an API gateway or your reverse proxy.

But as it turns out, this is already managed by PaaS providers like Clever Cloud or Heroku. So you don't have access to that IP/port for each instance. But it's OK. Eureka can be configured to support setup like these. You can use the URL given by the proxy instead.

The only issue with that is that you won’t be able to go on one specific instance since you go through the proxy. In some cases, this can become a problem. Like with the JHipster Registry.

JHipster Registry’s Statefulness Exception

Let’s say you want to scale out your registry for failover. It seems like a legitimate thing to do. If you only have one JHipster registry instance and it’s down, you lose your service registry(Eureka) and your configuration server (Spring Cloud config, embedded in the JHipster registry, more on that later). It means your architecture is down. So you want to have several instances of the registry in case one goes down.

Something also worth to know is that the service registry(Eureka in Netflix OSS terms) stores things in memory. You cannot store the information in a shared database that all your instances could use. It makes the registry stateful. They all have their datastore(their RAM). So you need to have your services register themselves to each registry instance to make sure they always have the same copy of the data.

If you were to use the URL of your JHipster registry application given by a PaaS, so behind a reverse proxy, the service would register to a random. It depends on the PaaS load balancer. In that case, you have no guarantee that your service will have registered itself with every instance of the registry.

If you use an IaaS, you will have all the IP/PORT couples at your disposal to make sure each service can register to each registry.

If you use PaaS autoscaling, each instance is hidden behind a reverse proxy with only one URL, and you have no way to have the clients register themselves to each instance (Now you could use sticky sessions, but you would have to craft the sticky session cookie manually, and this is cumbersome). So it is much simpler to create one application with its URL instead.

In that case, what you need to do is deploy an application for each instance you would like. That way you get a different URL for each, and you ask all your services to register to each URL.

Configuration Management

Another feature that comes up with most Platform as a Service and overlap with JHipster or the Netflix OSS stack is configuration management. In JHipster case, the registry is also a Spring Cloud Config server. As such it supports different backends to store your configuration: Git, native filesystem, Databases or Vault. By default JHipster uses git. Using GitHub, in particular, is excellent as you can benefit from their WebHooks. Each time you change the configuration, your server will receive the updates and broadcast it through an AMQP system with Spring Cloud Bus if you have configured one. So, you are sure that all your architecture is up to date with the latest configuration.

And of course, Spring Cloud Config also supports environment variables which is what we offer by default with Clever Cloud, with some exciting orchestration tricks.

The PaaS granularity level being Application(as oppose to VMs in IaaS), you can assign environment variables to Applications. All these variables are injected into all the instances of the app when we boot the VM. Applications can also expose some variables for others. How does it work?

Applications or add-ons can be linked together. It merely means that their exposed variables will be injected into the linked app. And the great thing about this is that when an exposed variable is modified, all the linked apps are restarted in blue/green so without service interruption. So you get an up to date architecture without having to setup Webhooks and an AMQP with Spring Cloud Bus :) Note that Clever Cloud also offers a configuration provider addon that lets you define configuration without having to tied it to an app. It is a bit like a configuration server. And it works exactly like described above. It's mostly here to make a semantic distinction.

Conclusion

JHipster and the Netflix OSS do provide some overlap to what PaaS can offer. But fear not because it’s still compatible and can benefit from the high-level feature supplied by PaaS. In the next post, I will show you all the steps to deploy this on Clever Cloud :)

There has been some demand for a JHipster Clever Cloud generator. We started working on it and it's now avaiable on the JHipster marketplace as a module.

What is JHipster?

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

Simply put, JHipster will scafold a new Spring Boot + Angular project based on your answers to a series of questions. Among those questions you'll get to choose if you want to use Maven or Gradle and which database you want among other things. These two basic choices will determine how you deploy your application on Clever Cloud.

This is where the jhipster-clevercloud generator comes in handy. It will generate the appropriate configuration and create the right application and addon. The current flow of question is simple.

• Choose the organisation or user to deploy the project
• Choose the region where to deploy it
• Give it a name (or reuse an already linked application)
• Decide if you want Clever Cloud to manage the database
  • If yes, it will be detected and will let you choose the appropriate plan
  • If no, you will have to manage the DB configuration yourself

Please note that the only DBs supported so far are PostgreSQL, MySQL and MsSQL.

Once the generator does its magic, you are left with a clevercloud folder containing the specifics. All you have to do then is to commit those changes and run clever deploy.

How to

Prerequisites

As this is a JHipster module, we expect you have JHipster and its related tools already installed. Make sure you have also installed clever-tools and that you have already ran clever login. The generator uses it heavily and won't work if it's not available.

Installation

To install this module:

npm install -g generator-jhipster-clevercloud

To update this module:

npm update -g generator-jhipster-clevercloud

Usage

To run the module on a JHipster generated application:

yo jhipster-clevercloud

What's next?

We plan to add support for other databases and third-parties once they are publicly supported by Clever Cloud. Think Elasticsearch, RabbitMQ, Kafka etc..

This project is in early stage and we would love to have your feedback. What would you like to do with it?

Welcome to this new edition of One Framework a Day keeps the Boredom Away. In this series I will show you how to deploy a particular framework on Clever Cloud every day until I want to go back to boredom. Today it's about JHipster.

In each post of this series we'll see how to deploy a particular framework on Clever Cloud. Today we are taking a look at JHipster.

If you want to tag along, make sure you have git, a Clever Cloud account and that you have installed our CLI Clever-Tools.

What is JHipster?

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

JHipster, not your grandma's Yeoman generator, has been around for quite some time now and seems to be one of the default solution to scafold a modern SpringBoot+Angular stack. It supports many different options for both frontend and backend. Some of these supported by Clever Cloud.

So today we are going to deploy a JHipster stack based on MySQL. We are doing this mostly because our good friends Stephan Janssen and Antonio Goncalves told us they would love to see a JHipster/Clever Cloud integration. Before any convenient integration, I need to know how it works :)

Setup

Here are the steps to create and deploy a JHipster/MySQL application to Clever Cloud:

• First make sure you have installed JHipster: yarn global add generator-jhipster
• Create a folder for your future application: mkdir clever-jhipster && cd clever-jhipster
• Run JHipster and follow instructions on screen jhipster
• Make sure you select MySQL and Maven in the wizard
• Create the MySQL database: clever addon create mysql-addon --plan dev --region eu jhipstersql
• Create the Clever Cloud application: clever create --type maven cleverJHipster
• Link your database to your application: clever service link-addon jhipstersql
• Create a clevercloud folder at the root of your project: mkdir clevercloud
• Create a maven.json file with the following content: vim clevercloud/maven.json

{
  "build": {
    "type": "maven",
    "goal": "-Pprod package -DskipTests"
  },
  "deploy": {
    "jarName": "./target/jhipster-0.0.1-SNAPSHOT.war"
  }
}

This file tells Clever Cloud to run mvn -Pprod package -DskipTests and then java -jar ./target/my-app-0.0.1-SNAPSHOT.war. Don't forget to change the jarName according to the name of your project.

Now to configure the application we will create aclevercloud/application-clever.yml file containing all the specific configuration to run on Clever Cloud.

spring:
    datasource:
        url: jdbc:mysql://${MYSQL_ADDON_HOST}:${MYSQL_ADDON_PORT}/${MYSQL_ADDON_DB}?useUnicode=true&characterEncoding=utf8&useSSL=false
        username: ${MYSQL_ADDON_USER}
        password: ${MYSQL_ADDON_PASSWORD}
        maxActive: 5

Here I am using variable already predefined by CleverCloud with the ${} synthax. To make sure this file is found while running the application, we need to copy it right before running with a hook: clever env set CC_PRE_RUN_HOOK "cp ./clevercloud/application-clever.yml ./application-prod.yml"

Deploy

Select the build dedicated instance because the JHipster build is memory greedy. To do that you have to go on the WebConsole, in your application, in the Information tab and tick the Enable dedicated build instance checkbox.

Now commit your changes and run clever deploy, this will push your code to our remote git branch and deploy it. At the end you can type clever open and it should open your website in your default web browser.

We plan to have a better integration to JHipster through a module. What kind of features would you like to have?