Walking through the generated files

Let's start with the app.yml file under src/main/docker inside your gateway application.

As we saw at the beginning of the chapter, the file starts with the Docker version that it supports:

version: '2'

This is followed by the services section where we define the various services, applications, or components that we will kick start with this Docker file.

Under services section, we will define a name for the service, in our case we have used gateway-app, followed by the image that we want to use as a container. This image is generated with the help of the Docker file that we have in that folder.

This is followed by the series of environment variables that our application will depend on, they include:

SPRING_PROFILES_ACTIVE: Tells the application to run in production mode and expose Swagger endpoints.
EUREKA_CLIENT_SERVICE_URL_DEFAULTZONE: Tells the application where to check for the JHipster Registry (which is the Eureka client that we are using. If we have chosen Consul here, then the application will point to the Consul URL)
SPRING_CLOUD_CONFIG_URI: Tells the application where to look for the config service for the application.
SPRING_DATASOURCE_URL: Tells the application where to look for the data source.
JHIPSTER_SLEEP: This is a custom property that we have used to make sure that the JHipster Registry starts before the application starts up.

Finally, we specify on which port the application should run and be exposed:

services:
    gateway-app:
        image: 'gateway'
        environment: 
            - SPRING_PROFILES_ACTIVE=prod,swagger
            - EUREKA_CLIENT_SERVICE_URL_DEFAULTZONE=http://admin:$${jhipster.registry.password}@jhipster-registry:8761/eureka
            - SPRING_CLOUD_CONFIG_URI=http://admin:$${jhipster.registry.password}@jhipster-registry:8761/config
            - SPRING_DATASOURCE_URL=jdbc:mysql://gateway-mysql:3306/gateway?.....
            - JHIPSTER_SLEEP=30
        ports:
            8080:8080

We have just defined the service with the docker-compose file; now we have to specify two other services that are needed for our application to run. They are the database and JHipster Registry.

So, we register another service called gateway-mysql, which creates and starts the MySQL server. We can define MySQL as a separate Docker Compose file and link them in here. So, we put an extends keyword followed by the docker-compose file and the service that we have to start from the specified docker-compose file:

   gateway-mysql:
        extends:
            file: mysql.yml
            service: gateway-mysql.yml

Then we input the following code for the mysql.yml file, shown as follows:

version: '2'
services:
    gateway-mysql: 
        image: mysql:5.7.20 
        # volumes: 
        # - ~/volumes/jhipster/gateway/mysql/:/var/lib/mysql/ 
        environment: 
            - MYSQL_USER=root 
            - MYSQL_ALLOW_EMPTY_PASSWORD=yes 
            - MYSQL_DATABASE=gateway 
        ports: 
            - 3306:3306 
        command: mysqld --lower_case_table_names=1 --skip-ssl --character_set_server=utf8 --explicit_defaults_for_timestamp

We have again started with the version that it supports followed by the services keyword and then specify the service name, gateway-mysql that is used in the app.yml file. If you want to specify a volume for the persistent data storage you can uncomment the commented volumes segment. This basically maps the local file location to Docker's internal location so that the data is persistent even if the Docker image itself is replaced or updated.

This is followed by a set of environment variables, such as the username and the password (we have set it to empty here, but for a real production application it is recommended to set it to a more complex password), and then the database schema name.

We have also specified the command that we need to run to start the MySQL server.

Then we go back to the app.yml file and we then define the JHipster Registry service. This will again extend the jhipster-registry.yml and docker-compose file. One more thing to note here is, even though we extend the services from another Docker file, we can override the environment variables that we have specified in the original docker-compose file. This comes in handy in certain cases where we have to kickstart our application with different or customized values. In our case, we have overridden the location of the Spring Cloud Config server file location from that of the original:

    jhipster-registry:
        extends:
            file: jhipster-registry.yml
            service: jhipster-registry
        environment:
            - SPRING_CLOUD_CONFIG_SERVER_NATIVE_SEARCH_LOCATIONS=file:./central-config/docker-config/

The Jhipster-registry.yml file:

version: '2'
services:
    jhipster-registry:
        image: jhipster/jhipster-registry:v3.2.3
    volumes:
        - ./central-server-config:/central-config
    # When run with the "dev" Spring profile, the JHipster Registry will
    # read the config from the local filesystem (central-server-config directory)
    # When run with the "prod" Spring profile, it will read the configuration from a Git             repository
        # See http://www.jhipster.tech/microservices-architecture/#registry_app_configuration
    environment:
        - SPRING_PROFILES_ACTIVE=dev
        - SECURITY_USER_PASSWORD=admin
        - JHIPSTER_REGISTRY_PASSWORD=admin
        - SPRING_CLOUD_CONFIG_SERVER_NATIVE_SEARCH_LOCATIONS=file:./central-config/localhost-config/
        # - GIT_URI=https://github.com/jhipster/jhipster-registry/
        # - GIT_SEARCH_PATHS=central-config
    ports:
        - 8761:8761

We have defined the central-config for JHipster Registry as follows. We have configured the secret for the JWT and the Eureka client's URL. The JWT token specified is used for services to authorize and communicate between them and the registry:

# Common configuration shared between all applications
configserver:
    name: Docker JHipster Registry
    status: Connected to the JHipster Registry running in Docker
jhipster:
    security:
        authentication:
            jwt:
                secret: my-secret-token-to-change-in-production
eureka:
    client:
        service-url:
            defaultZone: http://admin:${jhipster.registry.password}@localhost:8761/eureka/

Added to these, we also generate a sonar.yml, (this file is not important for deploying your application):

version: '2'
services:
    gateway-sonar:
        image: sonarqube:6.5-alpine
        ports:
            - 9000:9000
            - 9092:9092

Similarly, in the microservices, that is, in our invoice and the notification applications, we will have similar files generated. They are the same except for the change in the service name.

Unlike MySQL, MongoDB is also capable of running as a cluster with different nodes and configuration. We need to specify them differently here. So we will create have two docker-compose files. mongodb.yml is for starting the MongoDB with a single node, and the mongodb-cluster.yml to start the MongoDB as the cluster.

Please check the database port number between the gateway and the microservice application. If they use the same database, there may be a clash in the port number since JHipster generates the same port number for both. Change it to any other unused port, or Docker Compose will show an error. In our case, I have changed it to 3307.