Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
This document will outline steps to enable a development environment with a smaller resource footprint than the standard FOLIO Vagrant box. The environment will be suitable enough to run Karate tests.
Every FOLIO cluster needs services like Postgres and Kafka to function. The docker-compose file below will instantiate the services. It is a decent starting point with default credentials that will be used through out this document.
Copy the file below into a directory somewhere. Make sure it is named docker-compose.yml
If the operating system is Linux, at the time of writing, host.docker.internal is not a domain name that is automatically configured. One workaround is to replace every instance of host.docker.internal with 172.17.0.1 or your IP address in the docker-compose.yml file. This thread provides some insight on how to enable host.docker.internal for Linux.
This docker-compose.yml is adapted for Windows users:
Make sure you add a hostname entry to resolve host.docker.internal correctly on Windows machine such as the one below:
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
192.168.0.170 host.docker.internal
Execute the following in the same directory as the docker-compose.yml file above
docker-compose.yml Directory
docker-compose up -d
The following script will wipe the database created by the docker-compose.yml script above. This is good for starting from scratch.
Ensure that base services are accessible before continuing! Typically, if one of the services are accessible, most likely others are as well.
postgres: Verify that you connect to the postgres container at port 5432 via PgAdmin or other similar tool
OKAPI: Confirm that the service at port 9130 returns a response.
The only container that should disabled is the "createbuckets" container used to create a bucket in minio.
BusyBee
BusyBee is a tool that helps to streamline HTTP calls to okapi to manage the development environment. Get the source code at https://github.com/Olamshin/busybee
Python 3.13 is the latest version required for BusyBee.
Run the following to install required dependencies for busybee. Run the following commands in the directory where BusyBee is located.
BusyBee Directory
pip install -r requirements.txt
The first invocation of BusyBee should fail and create a config file at a location that needs to be updated. The location should be in the BusyBee response. The config should be in a .busybee folder in your home directory.
BusyBee Directory
python -m busybee
After the BusyBee config is updated, invoke BusyBee once more. You will be launched into another terminal where special commands are supported.
To start creating the dev environment, run the following:
BusyBee
start
Working With Custom Versions Of Modules
FOLIO modules that are initialized by BusyBee are at the same version of the install.json provided. During development, it is necessary to make code changes to a branch and test. This section will describe how to accomplish this with mod-inventory as an example.
Run the command below in BusyBee terminal. It will remove the docker container created by OKAPI that would represent mod-inventory.
BusyBee
undeploy -m mod-inventory
Start a custom version of mod-inventory and note the port on your local machine where it will be available. In our example, custom mod-inventory is started on port 7000. Run the command below in a BusyBee terminal to redirect mod-inventory requests from OKAPI to custom mod-inventory
Now OKAPI will forward requests to the custom mod-inventory at port 7000.
To remove the redirect, run the command below in the BusyBee terminal
BusyBee
redirect -m mod-inventory -rm
You can use this cURL-based script in a terminal session (for Windows use Git Bash or WSL2 terminal) to query Okapi and verify whether the redirection is successful by running ./test_busybee_redirect.sh mod-invoice:
# Find current Module Id (version) for mod-invoice
curl --location 'http://localhost:9130/_/proxy/modules?filter=mod-invoice'
# Check health of mod-invoice
curl --location 'http://localhost:9130/_/discovery/health/mod-invoice-5.9.0-SNAPSHOT.435'
The FOLIO UI can be built by git cloning the platform-complete repository. The "snaphot" branch of platform-complete is a better starting point that the "master" branch. At the time of writing platform-complete requires a Node v18 runtime and yarn installed as a node module. After NodeJS has been installed, Yarn can be installed globally with:
platform-complete Directory
npm i -g yarn
The command above needs to be run only once.
With the platform-complete repository as the current working directory, required node modules can be installed with:
platform-complete Directory
yarn install
The command above should only the executed once unless the current branch of the platform-complete repo is updated. Or if install.json is modified to include/exclude modules and module versions updated.