Fails silently on valid RAML, even with names option

[malomick]

Using abao to test my REST API, which is running in the default Docker machine:

me$ abao my-api.raml --server $(docker-machine ip)

Hangs for <.5s, then abao exits and I'm back at my prompt, nothing output or printed by abao. Even when I run with just the names option (me$ abao my-api.raml --names), it exits with no output. If it's failing or throwing an error, it's doing so silently; so I have no good way to troubleshoot.

Initially, some of my JSON schema were invalid, and abao was (correctly) complaining; so I know abao is working to that degree, and I have now confirmed that all my JSON and RAML is valid.

[plroebuck]

Dunno your Dockerfile setup and it's not provided. Ensure your outside:inside port#s are in agreement. The server argument should be a URL in the form 'http://host-or-ip-addr:outside-port'. Most likely scenario is that abao is working but server argument is invalid. Use curl with the same server argument to verify your REST endpoint is externally accessible.

[malomick]

I've successfully hit several endpoints in the Dockerized app, both through curl and Postman. In both curl and Postman, the URL I use is just the IP address plus the path (e.g. '192.168.99.100/my-api/v1/...'). I tried adding the 'http://' scheme to the front of it, and the outside port ':8000' (which I believe is the default) when using abao, but still nothing.

IMO, the more troubling issue is that abao is failing silently. Obviously I want to get it working for myself, but to exit without any further info is frustrating for any user.

[plroebuck]

Again, without seeing your Dockerfile, this is all guesswork. If you're using "192.168.99.100/my-api/v1/..." with curl and getting output, then your REST server is probably Apache-fronted (redirecting from 80 to 8000). Correspondingly, your server argument should be "http://192.168.99.100" (i.e., default to port 80). Have you verified your requests are making it into the Docker machine? Check Apache logfile(s) to verify request received, and your REST server logfile to see actual request.

[malomick]

@plroebuck Thanks for rephrasing, that wording was a little clearer for me to follow.

I have checked the Dockerfile and confirmed that the app is running on the default port (80), and also that my requests from curl and Postman are being logged. I've tried every combination of scheme, IP address, and port number in the server argument. Still nothing 👎

My next step is to stand up a hello world app in Docker and write a hello world RAML spec for it, and use that setup to confirm that abao works in the most basic situation.

[plroebuck]

How about attach your Dockerfile and simplified RAML (single resource with GET for debugging)?

What version of desktop OS? What version of Docker? How is server being run? What language/framework was it written in? Would not usually expect REST endpoint to assume control of port 80; usually on 8000 or 8080 instead as ports below 1024 reserved for system-level services.

What is output of $ docker ps on your system?

[malomick]

Ok, I have abao working with this (most basic ever) Hello world! app. I tried to add as many layers of complexity (e.g. docker-compose, a very prescriptive schema) without moving too far past Hello world!

I'm working to rule out some factors with the much more complex app that I want to test—but this here is working.

abao-test.zip

Output of docker ps:

me$ docker ps
CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS              PORTS                                                                                                                                              NAMES
1309cea59a21        abaotest_web                    "npm start"              22 minutes ago      Up 22 minutes       0.0.0.0:3000->3000/tcp                                                                                                                             abaotest_web_1```

[plroebuck]

Given:
$ SERVICE="abao-test"
$ SERVICE_VERSION="v1"
$ RAML_FILE="${SERVICE}.raml"
$ DOCKER_MACHINE_IP_ADDR="$(docker-machine ip default)" # 192.168.99.100
$ EXTERNAL_PORT="3000"
$ SERVER_URL="http://${DOCKER_MACHINE_IP_ADDR}:${EXTERNAL_PORT}"
$ ENDPOINT_URL="${SERVER_URL}/${SERVICE}/${SERVICE_VERSION}/"

Assume that running test app is accessible via curl using:

$ curl ${ENDPOINT_URL}

and accessible via abao using:

$ abao ${RAML_FILE} --server ${SERVER_URL}

[malomick]

Yes, everything in the abao-test example is working just fine. I did that exercise to confirm that abao will validate even the most basic example of an app running in Docker on my machine, and indeed it works. However, it still fails silently when I try it on my much larger Dockerized app, which I can hit no problem from both Postman and curl.

My latest idea was to change the port mapping in my docker-compose.yml so that I have an explicit mapping from 8000 to 80. I thought maybe abao was having some issue hitting 80. I confirmed that the new mapping works in Postman (by hitting http://192.168.99.100:8000/my-api/v1/...), but when I try abao my-api.raml --server http://192.168.99.100:8000, I still get the same result: silent exit.

[plroebuck]

I was trying to verify my understanding of your setup with my previous post; you didn't exactly say that those exact commands work with test app.

Assuming your original was also NodeJS service, you did verify that internal port from "docker-compose.yml" matches the listening port in "app.js", right? I would avoid using 80 as external port myself regardless.

[malomick]

The original service is a Java Spring Boot application. It's running a load balancer, so that's been pitched as a possible complication—But as far as curl and Postman are concerned, the app is working as expected.

I'm sorry I can't be more helpful. If abao was logging anything at all before exiting, I could give you something to work off of; but it's giving me nothing. (tbh, I think this is an opportunity to improve abao; and I would contribute by adding in the missing error logging if I had any inkling as to where it's failing.) If abao is, for example, trying and failing to hit the first endpoint specified in the RAML file, and it's failing because the URL is malformed, I would expect it to spit out the malformed URL; and then I could address the problem. If it's failing to open any connection whatsoever to the server, I would expect it to say so. Maybe a --verbose option would be a nice addition.