Project

General

Profile

Wiki » Development Using a Docker Container »

Runtime Setup Using Docker

Introduction

Because of the vast variations between applications, we are showing the Hotel GUI sample application only in this section.

This section shows you how to run the application within a Docker image. Before executing these steps, you MUST have either: After the conversion (full or incremental) completes, you can:
  • Run the application in place. The ./deploy directory within the project contains the configuration used for runtime.
  • Move the archives created in the ./distribution directory to setup another environment. The "deploy" archive (see here for more details on the archive filenames) can be used as input to the Docker image build process, or transported to another location.

If you are starting from a deployment zip file, first follow the Conversion Project Setup Using Docker step then resume from here. Create the ./distribution directory in the project, and place the deployment zip file within it. Then you can proceed.

Decide on the RDBMS Type

The Hotel GUI application can run under H2 or PostgreSQL database. Certainly the H2 database is simpler to use, but not as much of a real-world example. This documentation will proceed with PostgreSQL 17. It is presented here because it is a major decision for runtime setup.

Now when we start dbash.sh or fbash.sh we need to include PG17 support, and mount the newly created Docker volume into it at a location the image is expecting it to be located:

dbash.sh -v hotel_db_postgres --pg17 -w

More details about the database, including creation and import of data, are described here

Configure the Runtime Setup

Now that you have decided on the configuration, and you are running in the correct Docker container, you can configure the runtime environment. There is a prepare_dir_postgres_docker.json configuration file which has most all of the configuration properly setup, so we start with that, and make a copy of it.

cd deploy/server
cp prepare_dir_postgres_docker.json prepare_dir.json

Now you should edit the prepare_dir.json file, which will be input to the configuration program. The values that will most likely change are shown below with example values. The /home/rfb is the writer's $HOME value and rfb is the writer's $USER value:
  "server_xml_file": "server.xml",
  "directory_xml_file": "directory.xml",
  "spawner_path": "/home/rfb/projects/hotel_gui/spawner/spawn",
  "client_start_dir": "/home/rfb/projects/hotel_gui/deploy/client",
  "os_user": "rfb",
  "server_log": "../logs",
  "client_log": "../logs",

Traditionally the spawner is placed in /opt/spawner directory. However, within the Docker container the /opt location is not persistent. It is actually the Docker image. Instead, we place the spawner in a location that can persist, which would be the home space where our project is. symlinks could be used here so as to shorten paths, or utilize the more traditional /opt/spawner location. See below for setting up the spawner.

Once the prepare_dir.json edits are complete, you can setup the directory (the prepare_dir.json is the default filename, otherwise you can pass an option to -f):

./prepare_dir.sh -of

Setup the Spawner

The spawner can be positioned with the below command. Because we are not using the default location, we have to pass additional parameters.

cd ../..
./install_spawner.sh -as ./spawner

Updates to deploy Files

If there are updates to the files in the deploy directories, you will want those updates in your runtime environment. How to update depends upon whether you are running from a Docker image, or just with the files in place.

When the files are local, they just need to be pulled into your environment. If they are part of a bzr repository, just issue bzr update from the project directory. If they are part of a deploy ZIP, they will need to be unzipped.

© 2004-2026 Golden Code Development Corporation. ALL RIGHTS RESERVED.