[FOLIO-1995] use Okapi docker container instead of the deb for ref envs Created: 02/May/19  Updated: 03/Jun/20  Resolved: 25/Jun/19

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Jakub Skoczen Assignee: Ian Hardy
Resolution: Won't Do Votes: 0
Labels: platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: Text File deploy-excerpt.txt    
Issue links:
Blocks
blocks FOLIO-2117 Kubernetes integration (Q2, container... Closed
blocks UXPROD-1823 Kubernetes integration (Q3, Okapi fea... Draft
Relates
relates to FOLIO-1994 consolidate Okapi docker containers a... Closed
relates to FOLIO-2117 Kubernetes integration (Q2, container... Closed
relates to OKAPI-743 Configurable host for deployed contai... Closed
relates to UXPROD-1823 Kubernetes integration (Q3, Okapi fea... Draft
Sprint: CP: ready for planning, CP: sprint 64
Story Points: 3
Development Team: Core: Platform

 Description   

Switch from the deb to the Docker container for snapshot and testing.



 Comments   
Comment by Ian Hardy [ 03/Jun/19 ]

folio-snapshot-test.aws.indexdata.com is set up using the okapi docker container running with the host network configuration. Ideally, it should be set up to use the bridge network driver but I've run into the following probelm with the bridge network setup:

During module deployment (posting descriptors to the /_/discovery/module endpoing using the okapi-deployment ansible role) okapi will try to reach the modules at a localhost address which refers to the container running okapi. The first container will get spun up on the host machine successfully, but okpai tries to connect to port 9131 at localhost, and eventually times out.

Here are the options okapi is running with

exec java -Djava.awt.headless=true -Dstorage=postgres -Dpostgres_host=10.0.2.15 -Dpostgres_port=5432 -Dpostgres_user=okapi -Dpostgres_password=okapi25 -Dpostgres_database=okapi -Dhost=10.0.2.15 -Dport=9130 -Dport_start=9131 -Dport_end=9661 -DdockerUrl=http://10.0.2.15:4243 -Dokapiurl=http://10.0.2.15:9130 -javaagent:/opt/agent-bond/agent-bond.jar=jolokia{{host=0.0.0.0}},jmx_exporter{{9779:/opt/agent-bond/jmx_exporter_config.yml}} -cp . -jar /usr/verticles/okapi-core-fat.jar dev

An excerpt of the okapi log from this process is attached. At the top of the file, the descriptor is posted, and the failure message with the call to localhost/127.0.0.1 is at the end. deploy-excerpt.txt.

Comment by Ian Hardy [ 10/Jun/19 ]

Still having issues with deployment. After Okapi starts the docker container, it tries to connect to it on localhost:9131 which refers to the Okapi container and not where the module is running.

There are a few places (TcpPortWaiting, ProcessModuleHandle) where okapi makes a call to "localhost" during module deployment. As an experiment, I'm able build an okapi container where "localhost" replaced with the default ip of the docker0 bridge network (172.17.0.1) and deployment succeeds.

I think in order to run okapi as a container and do orchestrate deployment on the reference environments, there would need to be a way to call the address of the node instead of localhost. I might be misunderstanding deployment and there's a good chance I'm misunderstanding the okapi code so I'd be interested in any comments, John Malconian or Adam Dickmeiss

additional information on setup:
Okapi running in dev mode w/the following options set:

-Djava.awt.headless=true -Dstorage=postgres -Dpostgres_host=10.0.2.15 \
-Dpostgres_port=5432 -Dpostgres_user=okapi -Dpostgres_password=okapi25 \
-Dpostgres_database=okapi -Dhost=172.17.0.1 -Dport=9130 -Dport_start=9131 \
-Dport_end=9661 -DdockerUrl=http://172.17.0.1:4243 -Dokapiurl=http://172.17.0.1:9130

response from _/discovery/nodes:

[
    {
        "nodeId": "172.17.0.1",
        "url": "http://172.17.0.1:9130"
    }
]
Generated at Thu Feb 08 23:17:26 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.