Support using different profiles with 'jhipster aws'

[neshanjo]

Overview of the feature request

Currently, jhipster aws can only be used to deploy the application that is built with the prod profile. Make it possible to deploy the app with different profiles to different Elastic Beanstalk environments.

Suggested solution: Store the "aws" subsection of .yo-rc.json as key (profile name) / value (settings) map and introduce parameter --profile to the jhipster aws command or interactive question, which profile to use (can be prod by default). Example:

    "aws": {
      "prod": {
        "applicationName": "my-application",
        "environmentName": "my-application-env",
        "bucketName": "my-application",
        "instanceType": "t2.micro",
        "awsRegion": "eu-central-1",
        "dbName": "my-application-db",
        "dbInstanceClass": "db.t2.micro"
      },
      "dev": {
        "applicationName": "my-application-dev",
        "environmentName": "my-application-dev-env",
        "bucketName": "my-application-dev",
        "instanceType": "t2.micro",
        "awsRegion": "eu-central-1",
        "dbName": "my-application-dev-db",
        "dbInstanceClass": "db.t2.micro"
      }

To preserve backwards compatibility of .yo-rc.json, one could also keep the current structure and add a new subsection "aws-profiles" that contain all profile settings but prod.

Motivation for or Use Case

We usually have our applications deployed in a dev, staging and prod environment.

Related issues or PR

Did not find any.

• [x] Checking this box is mandatory (this is just to show you read everything)

Just a small additional remark: The instance type lists both for instanceType and dbInstanceType are outdated. There are t3.* instances available now.

[SudharakaP]

@neshanjo : Thanks for raising this issue.

I am not sure about this use case of supporting deployment of profiles other than the prod profile. Since my understanding is that the development profile is for development and debugging purposes (such as using with an in memory db such as H2) and therefore I am not sure we should let our users deploy development profiles to public clouds such as Elastic Beanstalk. I might be wrong, maybe someone else can chip in.

cc: @jhipster/developers

Just a small additional remark: The instance type lists both for instanceType and dbInstanceType are outdated. There are t3.* instances available now.

As for the supporting new instanceType and dbInstanceClass types I will review and update them soon. Thanks for pointing it out. :smile:

[SudharakaP]

I've noticed that there's a huge variety of instance types and db types in AWS that a user can choose (https://aws.amazon.com/ec2/instance-types/ and https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html). So I added additional options called Custom Instance Type and Custom RDS Type within the instance types and db type selections. If the Custom Instance Type is chosen an additional prompt will ask the user to specify the exact instance type that should be used (same applies for RDS type). :smile:

[neshanjo]

I am not sure about this use case of supporting deployment of profiles other than the prod profile. Since my understanding is that the development profile is for development and debugging purposes (such as using with an in memory db such as H2) and therefore I am not sure we should let our users deploy development profiles to public clouds such as Elastic Beanstalk. I might be wrong, maybe someone else can chip in.

In another project, we use CI/CD to deploy every commit to the master branch to exactly such an dev environment (Elastic Beanstalk). It's a good way to get early feedback from testers and also to verify that the application is really working and not only on the developer's machine.

Anyway, the more common use case would maybe be a "staging" environment:

"staging": {
        "applicationName": "my-application-staging",
        "environmentName": "my-application-staging-env",
        "bucketName": "my-application-staging",
        "instanceType": "t2.micro",
        "awsRegion": "eu-central-1",
        "dbName": "my-application-staging-db",
        "dbInstanceClass": "db.t2.micro"
      }

You can add another maven profile and application-staging.yml as described in https://medium.com/tekraze/add-a-new-profile-to-jhipster-application-spring-boot-application-25fa9851756c

But currently there is no way to deploy this profile easily to Beanstalk since the "prod" value is hardcoded during the preparational build.

If you don't like the idea of having the configuration in .yo-rc.json, what about adding command line parameters overriding the configuration in the "aws" section? E.g. jhipster aws --aws-build-profile staging --aws-application-name my-application-staging --aws-environment-name ... Then I could write a script to deploy the staging environment.

Or, as a third option, is it possible to pass a different configuration file to jhipster/yeoman? Then I could duplicat .yo-rc.json to .yo-rc-staging.json and pass this file to jhipster. This is the less preferred way, though, since it required a lot of duplication in the two yo-rc files.

[SudharakaP]

@pascalgrimaud : Just want to verify with you before I work on this whether there's any workaround to this that you know of? I am kind of surprised since I haven't seen this raised by anyone before, for any other cloud deployments we support (gae, heroku etc) ? :smile: :thinking:

[pascalgrimaud]

@SudharakaP : my opinion about all cloud deployment is to provide a sample for our users. We can't cover all cases because there is too much different ways to deploy in production. We have very few feedbacks (or no feedbacks at all), because most of users use it for:

• having default k8s files, and then customizing all these files, to match to their needs
• playing with this cloud provider and learning new stuff

So not sure if we should invest too much time on this, for coding something which is not used a lot (or not used at all) -> remember we had an issue with AWS sub generator during more than 1 year, and no one wanted to work on this, excepting you @SudharakaP What could be done is to add more documentation.

About different environments in real project, I still think the best way is to have a Spring Cloud Config server. Easy to have, easy to config, easy to have your own properties.

[PierreBesson]

I think there is a confusion here about our spring profiles. It has always been the case that we only support deployments using the "prod" profile while the "dev" profile is for local development.

This profile is unrelated to the name of the environment in which it is deployed (eg. staging, production, some even call their environment "dev" !). However while you could use the spring profile to define configuration for each environments, I would argue that it is not a good practice as it bundles the application artifact with its configuration which is not what you want in most cases.

Also as @pascalgrimaud said we have to support many kinds of deployment : traditional jar, docker, kubernetes, etc, so it's quite tricky to change this part.

[PierreBesson]

To comment further on the feature request of supporting multiple deployment environment, I think it goes beyond the initial goal of JHipster. JHipster wants to provide a starting point to help the user deploy his app. I would argue we should not go as far as managing multiple deployment environments from JHipster.

[pascalgrimaud]

Yes, @PierreBesson is totally right here ! Our dev / prod profile is related to our packaging:

• dev -> for quick start
• prod -> specially for optimizing the front part

Once you want to deploy in production environnement, you must override a lot of properties. Do not put it in application-prod.yml !

[SudharakaP]

@pascalgrimaud, @PierreBesson : Thanks a lot for the inputs; very much appreciated. I am closing this as it seems there's nothing more to be done on this one in terms of development.

@neshanjo : Feel free to let us know if you have further questions or comments on this. :smile_cat:

[neshanjo]

Thanks for your comments!

my opinion about all cloud deployment is to provide a sample for our users.

@pascalgrimaud I agree that this is probably the main purpose of all parts of JHipster, to get sample (a really good one, chapeau!) of a fullstack application that you can modify to suit your personal needs.

However, that's not what the aws subgenerator gives. Unlike k8s templates that are adaptable, the jhipster aws command is a black box that uses some internal scripts to "magically" deploy the prod profile build to a single AWS Beanstalk environment.

So in our situation, the only thing we can do, is writing our own scripts to deploy to different Beanstalk environments, which essentially means duplicating a lot from what the aws submodule already does. That's why, in the end, I was asking if one could add command line parameters overriding the configuration in the "aws" section. E.g. jhipster aws --aws-build-profile staging --aws-application-name my-application-staging --aws-environment-name .... Would you accept this addition to the submodule? I could have a look at the code and try to implement it myself.

Kind regards, Johannes