Deploy TourGuide app in a Docker Swarm cluster

[albertinisg]

In a conversation with @KennethNagin, we've found an issue trying to deploy TourGuide in a cluster. After exposing to the host the following services at the following ports:

• Orion: 1026
• CEP: 8080
• IDM: 443
• TourGuide: 80

The application fails when redirecting the 'Log in' to IDM. The issue is caused for several reasons:

• This configuration in the keystone_provision.py file:

    tourguide_app = keystone.oauth2.consumers.create(
        name='TourGuide',
        redirect_uris=['http://tourguide/login'],
        description='Fiware TourGuide Application',
        scopes=['all_info'],
        client_type='confidential',
        grant_type='authorization_code',
        url='http://tourguide',
        img='/static/dashboard/img/logos/small/app.png')

Assumes that the application is being deployed at http://tourguide.

• The environment variables IDM_HOSTNAME and TOURGUIDE_HOSTNAME

Ater making the HOST at IDM provision at IDM configurable, we will need to modify the environment variables IDM_HOSTNAME and TOURGUIDE_HOSTNAME matching the requirements.

[albertinisg]

Apart from that, we will have to discuss about how to go through the images that loads their configurations with volumes. This approach breaks the development of the TourGuide in a Docker Swarm cluster.

[jmcanterafonseca]

What are those images? Why configurations are loaded using images?

[dmabtrg]

The problem is not the images themselves, but the volumes mapped from the host used by those images, as they won't work when using Docker Swarm / Machine. Some images (e.g. cygnus or the official pep-wilma image) allow or require you to provide a configuration file to configure the application and that, right now, is done via a volume from the host. For this to work with Docker Swarm / Machine, we need to find an alternative solution:

• Create an external volume where we can push the configuration and have the containers use that volume.
• Have preconfigured images. This is impractical if we need to use the official images.
• Make the image automatically generate the configuration via a template and allow the user to change it via environment variables. This is the approach we tried to use on our custom images.
• Create a new image that holds the configuration files needed by other images and provide them as volumes for the other images to use.

The problem @KennethNagin faced was that the cygnus image loaded the configuration from a host volume. To solve this, he made two approaches:

• He tried to create a new cygnus image with the required files already in the image.
• He modified the compose file to make the cygnus container download the configuration from a github repository prior to start the application.

From the current images, this are the ones that (may) have this problem:

• cygnus:

  Our custom image allow a simple configuration to be generated from a template via environment variables, but to use a more complex configuration it requieres the user to provide that configuration file to the container (i.e. via a volume). The official image requires a volume to mount the configuration files.

• pep-wilma:

  Our custom image generates the configuration from a template via environment variables. The official image requires the user to provide the configuration file via a volume (or use the default configuration).

• idm:

  Our custom image modifies the default configuration via environment variables. The official image uses the default configuration.

• other images:

  The other images that we use don't need further configuration changes from the defaults used or can be tweaked via command line parameters (e.g orion).