see: release notes
This docker images facilitates running an OpenEdge db in a Docker container. Apart from this it facilitates builing and/or updating the database from a given .df
/.st
.
The following volumes are important for running the database:
/app/db
- the db files will reside here
/app/schema
- the location where .df
and/or .st
files are located
/usr/dlc/progress.cfg
- location where the .cfg
file MUST reside (otherwise ESM kicks in)
When running the container these volume are mapped via the -v
parameter.
For example:
docker run -d ^
-v c:/sports2020/db:/app/db ^
-v c:/sports2020/schema:/app/schema ^
-v c:sports2020/progress.cfg:/usr/dlc/progress.cfg ^
-p 10000-10010:10000-10010
--env DBNAME=sports2020 ^
docker.io/devbfvio/openedge-db:12.8.0
The scripts in the container operate under the assumption that the env var DBNAME
is set, hence:
--env DBNAME=sports2020
.
The .df
and .st
files (in either /app/schema or /app/db) should have the same name as the database.
The first thing is establishing the DBNAME. If ${DBNAME} is empty is database name is derived. The first .db
file is taken to get the database name.
Once the database name is established the initialization starts.
- if a
.lk
is found the container exits - if a
.db
files is not found, the process searches for a.df
and.st
in/app/schema
- if one of these is not found, the container exits
- otherwise a empty database is build based on the
.df
and.st
. /usr/dlc/empty8
is copied to the database (todo: UTF-8 support need)- the
.df
file is hashed and this hash is put in/app/db/<dbname>.schema.hash
- otherwise (the database is already there)
- if
/app/schema/<dbname>.df
is present this is hashed and compared to/app/db/<dbname>.schema.hash
- if they differ the schema needs to be updated (create new empty db, created delta, apply delta)
- if
At this point the container is either exited or has an up to date database (schema wise) The database is started:
proserve /app/db/${DBNAME} -pf /app/db/db.pf
This implies that a db.pf
MUST be present.
This file should container at least:
-S 10000
-minport 10001
-maxport 10010
You can use whatever ports you like.
The database is gracefully shut down whenever an SIGINT
or SIGTERM
signal is sent to the container.
proshut
executes and the db goes down, no .lk
is left. Ready for the next start up.
When a new .df
is put in /app/schema
(read: its mounted location on the host) there are two options:
- stop and start the db (see above). The db is updated offline
- run
docker exec -d /app/scripts/update-schema.sh
. This is online and it may fail subsequently.
The most logical things is running the db from a docker compose stack. An example docker-compose.yaml
:
version: "3.8"
services:
sports2020-db:
image: docker.io/devbfvio/openedge-db:12.8.0
volumes:
- c:/docker/sports2020/db:/app/db
- c:/docker/sports2020/schema:/app/schema
- c:/docker/license/oe-12.8/oe128-db-dev-progress.cfg:/usr/dlc/progress.cfg
ports:
- 10000-10010:10000-10010
environment:
- DBNAME=sports2020
If an .lk file is found upon running the container the container exits, unless you set the DEL_LK_FILE
to true. (f.e. --env DEL_LK_FILE=true
)
When a db is created the .df
is scanned for MULTITENANT yes
. If found, the db is created as a multi tenant db.