Deploying a Quarkus application with NubesGen

[agoncal]

Before creating an issue or PR, I'm opening up a discussion about deploying a Quarkus application with NubesGen.

Like Spring Boot, a Quarkus application can be deployed in several modes:

• Quarkus with Maven: an executable JAR built with Maven
• Quarkus with Gradle: an executable JAR built with Gradle
• Quarkus Docker JVM: Docker container with an executable JAR
• Quarkus Docker Native: Docker container with a Linux native binary (GraalVM)

The way of building these artifacts is throught Quarkus properties passed to the Quarkus Maven(Gradle) plugin:

• Quarkus with Maven: mvn package(i.e (mvn package -Dquarkus.package.type=jar) to build an executable JAR
• Quarkus Docker JVM: mvn package -Dquarkus.container-image.build=true (i.e. mvn package -Dquarkus.container-image.build=true -Dquarkus.package.type=jar)
• Quarkus Docker Native: mvn package -Dquarkus.container-image.build=true -Dquarkus.package.type=native -Dquarkus.native.container-build=true

Quarkus has specific properties. For example, the ones used for the datasource in the app-service/main.tf file:

  app_settings = {
    "WEBSITES_ENABLE_APP_SERVICE_STORAGE" = "false"

    # These are app specific environment variables
    "QUARKUS_DATASOURCE_DB_KIND"  = "mysql"
    "QUARKUS_DATASOURCE_JDBC_URL" = "jdbc:mysql://${var.database_url}?useUnicode=true&characterEncoding=utf8&useSSL=true&useLegacyDatetimeCode=false&serverTimezone=UTC"
    "QUARKUS_DATASOURCE_USERNAME" = var.database_username
    "QUARKUS_DATASOURCE_PASSWORD" = var.database_password
  }

[jdubois]

Thank you @agoncal !
The part with the environment variables is exactly what I expected with Quarkus, so this should be fine.

For the different options, like "Quarkus Docker Native":

• Our drop down list is already too big, and we'll need to find a good UX/UI idea to simplify this. @cmaneu do you have an idea?
• @agoncal you should focus first on the most "usual" build mechanism, get some feedback, before doing the 3 others. Otherwise you'll lose time if you need to do some refactoring. Once you have one option working, doing the 3 others similarly should be very fast.

[agoncal]

Yes, if Quarkus brings 4 more options, then Micronaut, then... the UI will get more and more complex.

Yes @jdubois I'm just concentrating in the usual build system for now. ATM I'm working on just building and deploying an executable JAR. We'll see for the future.

BTW I'm struggling with Azure: my app is deploying but not executing and I can't see the logs. It would be good to have some documentation on "How to add a new 'extension' in NubesGen" with some "Troubleshooting" in there ;o). I'll create an issue around this topic so you can help me with Azure

[jdubois]

I agree that by default it's annoying to get logs. I'm currently adding Application Insights support, but even this doesn't seem to help much for a Java app (it will change in the future when the Java agent is rolled out everywhere).
We need to improve logging when generating the infrastructure, another matter where we should have something better than what is provided by default.

[agoncal]

@jdubois The way the Mustache templates are structured makes it difficult to add a new runtime. For example, take the src/main/resources/nubesgen/terraform/modules/app-service/main.tf.mustache template. If the runtime is Spring, then we have a SPRING_DATASOURCE_URL property, if not, we have a DATABASE_URL:

...
{{#runtimeSpring}}
    "SPRING_PROFILES_ACTIVE"     = "prod,azure"
    
  {{#databaseTypeSqlServer}}
    "SPRING_DATASOURCE_URL"      = "jdbc:sqlserver://${var.database_url}"
    "SPRING_DATASOURCE_USERNAME" = var.database_username
    "SPRING_DATASOURCE_PASSWORD" = var.database_password
  {{/databaseTypeSqlServer}}
  ...
{{/runtimeSpring}}
{{^runtimeSpring}}
  {{#databaseTypeSqlServer}}
    "DATABASE_URL"      = var.database_url
    "DATABASE_USERNAME" = var.database_username
    "DATABASE_PASSWORD" = var.database_password
  {{/databaseTypeSqlServer}}
  ...
{{/runtimeSpring}}

To keep the same structure, we add a new runtime. That means that if the runtime is Quarkus, then, we have a QUARKUS_DATASOURCE_JDBC_URL property.... but because it's not a Spring runtime, the default DATABASE_URL property is also added

...
{{#runtimeQuarkus}}
    "QUARKUS_HTTP_PORT"           = 80
    "QUARKUS_PROFILE"             = "prod"
    
  {{#databaseTypeSqlServer}}
    "QUARKUS_DATASOURCE_JDBC_URL" = "jdbc:sqlserver://${var.database_url}"
    "QUARKUS_DATASOURCE_USERNAME" = var.database_username
    "QUARKUS_DATASOURCE_PASSWORD" = var.database_password
  {{/databaseTypeSqlServer}}
  ...
{{#runtimeQuarkus}}
{{#runtimeSpring}}
    "SPRING_PROFILES_ACTIVE"     = "prod,azure"
    
  {{#databaseTypeSqlServer}}
    "SPRING_DATASOURCE_URL"      = "jdbc:sqlserver://${var.database_url}"
    "SPRING_DATASOURCE_USERNAME" = var.database_username
    "SPRING_DATASOURCE_PASSWORD" = var.database_password
  {{/databaseTypeSqlServer}}
  ...
{{/runtimeSpring}}
{{^runtimeSpring}}
  {{#databaseTypeSqlServer}}
    "DATABASE_URL"      = var.database_url
    "DATABASE_USERNAME" = var.database_username
    "DATABASE_PASSWORD" = var.database_password
  {{/databaseTypeSqlServer}}
  ...
{{/runtimeSpring}}

AFAIK Mustache does not allow to have several inverted section. Wouldn't it be possible to restructure the code so there is a runtimeDefault ? Something like:

...
{{#runtimeQuarkus}}
  ...
{{#runtimeQuarkus}}
{{#runtimeSpring}}
  ...
{{/runtimeSpring}}
{{#runtimeMicronaut}}
  ...
{{/runtimeMicronaut}}
{{runtimeDefault}}
  ...
{{/runtimeDefault}}

[jdubois]

Yes, let’s have a "runtimeDefault"
Mustache is very limited compared to EJS, but I find the end result easier to read, and to maintain.