jhipster-registry | JHipster Registry , based on Spring Cloud Netflix Eureka | Microservice library

After some trial and error I ended up doing something like this:

1. Clone https://github.com/jhipster/jhipster-registry

2. Build a Docker container locally with ./mvnw package -Pprod verify jib:dockerBuild

3. Create an ECR registry in AWS console or using AWS CLI as follows: aws --profile [AWS_PROFILE] ecr create-repository --repository-name [ECR_REGISTRY_NAME]

4. Assuming that v6.3.0 was cloned in step 1, tag the local Docker as follows: image docker tag [IMAGE_ID] [AWS_ACCOUNT].dkr.ecr.[AWS_REGION].amazonaws.com/[ECR_REGISTRY_NAME]:jhipster-registry-6.3.0

5. Authenticate to ECR as follows: eval $(aws --profile [AWS_PROFILE] ecr get-login --no-include-email --region [AWS_REGION])

6. Push the local Docker image to ECR as follows: docker push [AWS_ACCOUNT].dkr.ecr.[AWS_REGION].amazonaws.com/[ECR_REGISTRY_NAME]:jhipster-registry-6.3.0

7. Set up Elastic Beanstalk (EB) CLI

8. Initialize local EB project as follows: eb init --profile [AWS_PROFILE]

9. Create Dockerrun.aws.json with the following content:

The secret have to be in the same namespace as the deployment to be able to use it to pull from the docker registry.
So when you create the secret, you use:

Docker is absolutely NOT required for JHipster micro services architecture using jhipster-registry, your use case is well supported and the issues you encountered are only due to your configuration errors.

gateway.yml is not indented correctly so property names for datasource do not match and this is why you get this error about being unable to find JDBC driver.

The eureka block in the middle of the spring block completely broke it and anyway eureka config is shared by all apps so it should be placed in application-dev.yml and application-prod.yml.

gateway.yml as any other files that are in environment repository (central-config folder when using native) must be exactly the same format as your local application.yml files.

If you are not comfortable with YAML files you could switch to normal properties.

About file naming in native repository, Spring Cloud Config Server doc says:

If the repository is file-based, the server creates an Environment from application.yml (shared between all clients) and foo.yml (with foo.yml taking precedence). If the YAML files have documents inside them that point to Spring profiles, those are applied with higher precedence (in order of the profiles listed). If there are profile-specific YAML (or properties) files, these are also applied with higher precedence than the defaults.

So basically it means that in your central-config folder you should have these files:

• application.yml: all properties common to all apps when no profile is set
• application-dev.yml: all properties common to all apps when dev profile is set. This is where you will put the JWT secret for dev, the url for dev Eureka server (often localhost)
• application-prod.yml: all properties common to all apps when prod profile is set. This is where you will put the JWT secret for prod, the url for prod Eureka server
• gateway.yml: all properties of gateway app when no profile is set
• gateway-dev.yml: all properties of gateway app when dev profile is set. This is where you will put dev datasource
• gateway-prod.yml: all properties of gateway app when prod profile is set. This is where you will put prod datasource

So when your gateway bootstraps with dev profile, it will gets a combination of application.yml, application-dev.yml, gateway.yml and gateway-dev.yml

This mechanism can work only if you follow the naming convention {app name}-{profile}.yml

So, having named a file application-dev-gateway.yml just meant properties common to all apps with dev-gateway profile which is probably not what you meant.

You must change port in spring.cloud.config.uri in all application's bootstrap*.yml so they can retrieve their config from the registry and also change it in eureka.client.defaultZone in application.yml in jhipster-registry's central-config folder if you use file system backend or in git repo if you use git backend.

This is because the registry is both a Spring Cloud Config server and an Eureka server. In JHipster's setup, the applications first connect to the config server, retrieve their config which indicate the URL of the Eureka server. As this is a common config for all apps, it's set in application*.yml in config server.

Please read also the jhipster-registry doc: https://www.jhipster.tech/jhipster-registry/

I suspect your health endpoint /management/health fails to return a 200 prompting K8s to recreate the Pod.

I was able to solve this using this answer.