3

I'm using ArangoDB and developing a Foxx application. ArangoDB is hosted within a Docker container using this image https://store.docker.com/images/arangodb. I have another Docker container that is running my app front end.

I've created a volume to persist database data, and I've also created a volume to persist Foxx app data:

  - type: volume
    source: databasedev
    target: /var/lib/arangodb3
  - type: volume
    source: foxx
    target: /var/lib/arangodb3-apps

Finally, I created a bind mount from my Foxx source folder to the Foxx app folder in my ArangoDB container:

  - type: bind
    source: C:\\[pathtosource]\\src\\foxx
    target: /var/lib/arangodb3-apps/_db/poflow

About 40-50% of the time when I compose up my Foxx source code gets deleted. I've tried using the "no-copy" option on the Foxx volume, but it only seems to make it worse.

After my containers compose up a node script in my front end container attempts to install my Foxx service and set it to development mode. Basically, it zips my Foxx source on the fly and installs it. But it often finds my Foxx source folder empty and fails, and which point I restore the files, and compose down, then back up and try again.

Am I going about this wrong? Is there something I'm missing? It seems like ArangoDB is not persisting the Foxx data every time.

Mohammed Zayan
  • 859
  • 11
  • 20
skinneejoe
  • 3,921
  • 5
  • 30
  • 45

2 Answers2

2

I may have found a solution. Instead of using the public ArangoDB docker image directly in my compose file, I've switched to build my own using a dockerfile.

Before:

database:
    image: "arangodb"

After:

  database:
    image: "arangodb"
    build:
      context: .
      dockerfile: dock-arango-dev.Dockerfile

Then my docker file looks like this:

FROM arangodb
ENV ARANGO_ROOT_PASSWORD supersecurepass
WORKDIR /var/lib
COPY "./src/foxx" "./arangodb3-apps/_db/foxxapp"
EXPOSE 8529

I think the copy directive in the docker file is what does the trick. So far it's been working perfectly. I'll accept this answer in a few days if it continues this way.

EDIT: Unfortunately this has not 100% solved the problem, although it has improved it. So I won't mark this as the answer, but it was a helpful step.

EDIT: After using this approach for a few weeks, it only failed once on me. So maybe that was a fluke. But this approach is definitely working better than my previous technique. So I will mark this as the answer. If anyone provides a better workflow or approach that is even more solid I will change the answer.

skinneejoe
  • 3,921
  • 5
  • 30
  • 45
2

My previous answer helped for a while until the project got more complicated and involved more Foxx micro services. Instead of creating one large convoluted answer, I decided to post a separate answer to keep things more clear.

After much testing using bindings with Arango, it seems that the way Arango sets up it's Foxx services directory has a conflict with how Docker creates it's bindings. Maybe if there was a way for Docker to delay binding creation until after Arango had booted up and configured it's Foxx services, things might work. But it seems there's a conflict and often Dockers bindings seems to corrupt the Foxx services. In many cases source files from one service found their way into another service. Very odd.

So my solution was to forgo using bindings for development at all. Instead I created a script that leverages the ArangoJS driver and an NPM library called chokidar. This script watches my foxx source directory and any time a change is saved, it replaces the foxx service via HTTP using the ArangoJS driver. I thought it might be inefficient, but actually it's very fast and effective, and it circumvents all the issues I'm having with Docker.

I would love to see Arango embrace Docker support more fully with their Foxx services, but for the meantime this solution seems to work very well for my needs.

skinneejoe
  • 3,921
  • 5
  • 30
  • 45