Timed out error uploading small test dataset

[ch728]

I set up a local instance of Gigwa v2.5 using the docker option. I get the following error when I try to create a new database by uploading some data:

[GuilhemSempere]

Looks like the webapp is unable to see the MongoDB server. How did you start the Docker containers? Did you use the provided docker-compose.yml?

[ch728]

Yes, I used the provided docker-compose.yml with out changing anything.

[GuilhemSempere]

Are you starting it using the command line suggested at the top of that file?

[ch728]

I did. I made some changes to the original docker-compose.yml based on a coworker's suggestions and we were able to get it to work. See the attached .yml and environment files. I added the .txt and removed the "." from the env file, which would normally be hidden so github would let me upload. The main thing we changed was adding the hostname and links instead of exposing the mango port on the host. I added bind mounts to a local index.jsp and images, but that was just to change some aesthetics.

docker-compose.yml.txt

env.txt

[GuilhemSempere]

Thanks for sharing your solution. Using the .env file is indeed useful in the sense that it avoids having the MongoDB credentials in two places, with the drawback of needing to carry an extra file along.

I find your other changes (using links) interesting because they allow to get rid of the docker0 workaround. From my understanding of the documentation you could just go with MONGO_IP: mongo and get it to work without using links. However using your method or the one I just mentioned both require setting MONGO_PORT to the mongo container's internal port, which is fine when both containers run on the same host, but may require more changes for people who want to split the setup over two different machines. But maybe these are rare cases and the distributed docker-compose.yml is unnecessarily complex. Maybe we should provide separate docker-compose.yml files for each case.

However, I still don't understand why you were having the issue in the first place. A problem that is likely to occur is when people launch the containers with some credentials, then later change those, and start again. What happens then is that since the MongoDB container creates its root user the first time it's launched, then it's there forever and changing those credentials in the config only affects the client (Tomcat) side which then is not in sync with the other container anymore...

[agostof]

@GuilhemSempere and @ch728, when I tried the original compose file, I think the{docker0} workaround didn't work for me. But you are right, using MONGO_IP: mongo should work. I originally setup a version of the compose above using the domain alias to be very explicit that a hostname or IP could be used in this place, preserving the spirit of the original configuration.

In addition, for any future readers, commenting out the ports option of the "mongo" section would keep the the database service only accessible to the app's container, preventing unwanted exposure of the database to the default network interface and possibly the internet. If access is needed for mongo from the host, the container could be bound to the the loopback e.g. change ports to - 127.0.0.1::27017. I point this last bit out because as you know exposing the database port might be unneeded for many use cases, and could create security issues in certain setups.

Now that I think about it, maybe not exposing the mongodb port is why the docker0 workaround didn't work for me (I was not exposing mongodb to the host). I think that since the ${docker0} variable is undefined (at least it was in my case), gigwa is being instructed to look for mongo on the default interface which is is 0.0.0.0, which we are trying to prevent in the first place. So gigwa might be somewhat "blind" to the db. This is my hypothesis, did not test this. Wrong hypothesis, if the command is run the variable should be defined properly, disregard the previous statement.