Broadcom: API Portal - Docker and MySQL installed on same system. Portal deployment fails when "localhost" is used to define the local Database.

Products

• CA API Developer Portal

Issue/Introduction

This case scenario implementation sees Portal containers (Docker) and MySQL server installed on the same system in a demo or test environment. For production systems, we discourage installing MySQL on the same Portal server and avoid single-point of failure scenarios. 

If in the Portal configuration file we point the Database to "localhost" (PORTAL_DATABASE_HOST=localhost), the implementation routine will fail because unable to connect to the database. The following error can be seen in the log of [portal_db_upgrade] container:

Environment

Portal 5.x - MySQL: 5.7/8.x

Cause

The reason for the inability of Portal deployment to connect the database is because the Portal Upgrade container cannot resolve "localhost". The container is a virtual machine with its own virtual network and localhost is not the underlying system that is hosting Docker service, but is the container itself.

Resolution

We must replace localhost with the fully qualified domain name of the underlying system. 

Here is a good example of implementation:

- this lab server resolves in the network as apim<EXAMPLE>.<domain>

- in the portal configuration file (/<portal_path>/conf/portal.conf) we use the FQDN for the Database host value:

- NOTE:  before deploying Portal by running portal.sh script, verify that in MySQL, the user configured as DB username (in this example is "root") has access from any remote connection ( 'root'@'%' ). This is because the container is seen as a device remotely connecting to the database even if Docker is hosted on the same server:

- then deploy the Portal by executing the portal.sh script, which should be successful

- after a few minutes all Portal services should be up and running:

 

Additional Information

NOTE: It is NOT recommended to have Portal/Docker and MySQL database on the same system for production, as we want to avoid single-point-of-failure implementation.