Add OpenDroneMap to docker compose stack

[spwoodcock]

Adds the following:

• ODM API (which presumably interfaces with the same code as ODM CLI): does the actual processing
  • This is simply an API wrapper to do processing
  • It's a throwaway instance & should be scalable in the future
• Postgres DB for persistent data in the web instance
• A Redis broker for the job message queue when processing jobs
• ODM worker: an instance of WebODM that uses Celery to manage processing jobs
• ODM web: the web instance to coordinate all of the above

ODMWeb (UI) --> worker/broker --> ODM API (processing)

[nrjadkry]

It could have been better if the odm related compose are in the seperate compose file like docker-compose.odm.yml. So, If I don't want odm in my setup, I wouldn't have it in my setup.

[spwoodcock]

Yeah for sure I can do that 👍

[spwoodcock]

Done.

Now to run only ODM:

docker compose -f docker-compose.odm.yml up -d

or to run it alongside Drone TM:

docker compose -f docker-compose.yml -f docker-compose.odm.yml up -d

[spwoodcock]

Although in my opinion, these should be merged back together in future, as we use the main docker-compose.yml only for local development & it makes sense to bundle ODM there (or at minimum a single NodeODM instance).

The docker-compose.vm.yml is used to deploy to prod for now, so is not affected.

[nrjadkry]

Yes, you are right. But, we could use the above command too.
Another question is, how does web odm stores volumes. Does it support minio ? We might want to store images, orthos, everything in s3.

[spwoodcock]

I commented on the discussion here about this topic: #94

Probably best we have a call at some point to discuss this.

For the POC using locally hosted Minio (essentially storing all images on-disk with an S3 wrapper) is probably ok, but we need large storage attached to the machine we deploy to.

S3 is still the way to go in the future, but probably an externally hosted one. ODM does not support bulk file import from S3 though. To import in bulk via the NodeODM API we would need to zip the files first

[nischalstha9]

The setup went smooth! I think it's fine to keep ODM in separate compose file as users may want to use their own ODM stack. Optionally, they will have option to run ODM via compose stack too. IMO: It's better to provide docs to run ODM via compose stack rather than merging it in default. But if the requirement/convention goes as "the project should run with just docker compose up", Its fine to bake into default compose file too.