Database

Database venders maintain well positioned tools, procedures, and best practices that can be deployed based on the Enterprise’s current policies.

Disaster recovery procedures for vendor-managed databases should follow the vendor’s recommended solutions and procedures. To ensure robust disaster recovery solutions that avoid data loss and promote rapid recovery, additional methods and procedures beyond the vendor recommendations should be deployed.

EnterWorks on Linux supports both Docker-containerized and non-containerized implementations of PostgreSQL. In addition to adhering to PostgreSQL backup best practices, systems utilizing a Docker-containerized implementation of PostgreSQL should also be aligned with Docker container recommendations and the EnterWorks best practices listed below.

EnterWorks Best Practices for Docker Containers

During the design, configuration, and deployment phases, EnterWorks may be customized or extended to meet requirements for a customer. Configuration files, start scripts, and other “custom files” store these customizations.

In some instances, Docker containers need to be redeployed. Customizations made in the configuration files, start scripts, and custom files will not survive this process. It is therefore imperative that these files are maintained externally to their Docker containers. In the event these files are updated or the containers are redeployed, they are then copied back into the containers and the containers are restarted. These externally maintained files will be backed up when the host VM is backed up, and as a result will persist in the event of a recovery procedure.

The best practice for copying these files back into the containers is via one or more deployment scripts. (These scripts deploy the files into the containers – they do not redeploy the containers themselves.) This method ensures that all the files are consistently copied and that after redeployment of a container, the only recovery needed would be running the deployment script(s). Consider combining deployment scripts in order to simplify the deployment process.

In addition to the custom file deployment procedures listed in theEnterWorks 10 Installation Guide for Linux and the EnterWorks 10 Services Framework Deployment Guide that detail the management and retention of HTML files, JAR files, and the similar, there are additional files that need to be managed, specifically, start scripts and configuration files.

Start Scripts (Environment Variables and Services Parameters)

Start scripts are responsible for the service run-time configurations, such as SSL/SSO/Hosts/Ports. Start scripts are titled: start.sh.

The following start scripts are maintained on the host VM, in the following folders.

• ./docker/micro-svc/webcm-broker-service/start.sh
• ./docker/micro-svc/es-manager-service/start.sh
• ./docker/micro-svc/web-server-service/start.sh
• ./docker/micro-svc/channel-readiness-service/start.sh
• ./docker/micro-svc/es-indexer-service/start.sh
• ./docker/micro-svc/monitor-dam-drop-service/start.sh
• ./docker/micro-svc/dam-manager-service/start.sh
• ./docker/micro-svc/es-search-service/start.sh
• ./docker/micro-svc/mq-logger-service/start.sh
• ./docker/micro-svc/api-go-service/start.sh
• ./docker/micro-svc/dam-magick-native-service/start.sh
• ./docker/micro-svc/epx-broker-service/start.sh

These start scripts may need to be altered based on business requirements. They should not be altered inside the container. Instead, they should be altered in the folders where they reside. One or more deployment scripts should be written to deploy the start scripts into the containers. In the event the scripts are modified or a container is rebuilt, run the deployment script(s). After running the deployment script(s), the container must be restarted (not reinstalled or redeployed).

Configuration Files

The relevant EnterWorks configuration files are:

• Enterworks.properties
• sharedConfig.properties
• config.properties
• esjdbc.properties

These files may need to be altered based on business requirements. They should not be altered inside the containers. Instead, they should be altered in folders external to the containers. One or more deployment scripts should be written to deploy the configuration files into the containers. Once this has been set up, all subsequent changes to these files should be made to the files in these folders, then redeployed by running the deployment script. Should a new file need to be maintained outside a container, it should be copied to the appropriate directories, updated, added to the deployment script(s), and the deployment scripts should be run.

In the event of the files are modified or a container is rebuilt, run the deployment script(s). After running the deployment script(s), the container must be restarted (not reinstalled or redeployed).

The following configuration file is the same for all containers:

Enterworks.properties

Because of this, it is managed in the folder:

/opt/enterworks-root/enterworks/shared

Create the following directory in the NFS share to hold the rest of EnterWorks’ configuration files:

/opt/enable/enterworks-root/enterworks/configuration/

Create subdirectories under this that mirror the Docker container names:

• epimtomcat
• epxtomcat
• epxjboss
• epimjboss
• jbossslave<N>: (One for each slave.)

These subdirectories will contain copies of the configuration files specific to their containers.

Configuration Files in Docker Containers

Configuration File	Containers	Notes
Enterworks.properties	epimjboss epxjboss epxtomcat jbossslaveN	This file is identical in every container it which it resides.
sharedConfig.properties	epimtomcat epimjboss epxtomcat jbossslaveN	This file is slightly different for each container, therefore separate copies for container need to be maintained.
config.properties	epxtomcat epxjboss	This is identical for both processes. It contains the configuration settings for EPX.
esjdbc.properties	epxtomcat epxjboss	Is identical in both process. It contains the EPX DB Connectivity information.

EnterWorks Docker Containers with Properties Files

The following list of containers identify which property files drive their implementation.

• jbossslave<n>:
  • /opt/jboss/wildfly/standalone/configuration/conf/sharedConfig.properties
  • /opt/jboss/wildfly/standalone/configuration/conf/Enterworks.properties
• epxtomcat:
  • /app/enterworks/EPX/EnableServer/conf/sharedConfig.properties
  • /app/enterworks/EPX/bin/conf/Enterworks.properties
  • /app/enterworks/EPX/bin/config.properties
  • /app/enterworks/EPx/bin/esjdbc.properties
• epxjboss:
  • /app/enterworks/EPX/bin/config.properties
  • /app/enterworks/EPX/bin/esjdbc.properties
  • /app/enterworks/EPX/bin/conf/Enterworks.properties
• epimtomcat:
  • /usr/local/tomcat/webapps/webcm/WEB-INF/classes/sharedConfig.properties
  • /usr/local/tomcat/webapps/webcm/WEB-INF/classes/Enterworks.properties
• epimjboss:
  • /opt/jboss/wildfly/standalone/configuration/conf/sharedConfig.properties
  • /opt/jboss/wildfly/standalone/configuration/conf/Enterworks.properties

EnterWorks Docker Containers without Property Files

The following containers do not contain property files.

• api-go
• dam-manager
• dam-magick-native
• channel-readiness
• cr-mongo
• elasticsearch
• enable2020broker
• es-search
• es-manager
• es-indexer
• epx-broker
• dam-manager
• dam-magick-native
• channel-readiness
• mq-logger
• monitor-dam-drop
• nfs
• web-server
• webcm-broker