I have mixed feelings about containers. I absolutely think they make things better and are easier to use. My mixed feelings come from the fact that they add a completely new way of thinking about deployment and provisioning that you have to master before using them. The other downside is that only the docker community managed ones can be trusted out of the box, next trustworthy are the ones maintained by the SW owner (Elastic in this case) the rest have to be examined very closely and that requires a high degree of Docker knowledge as well as understanding the SW in the container.
So we use out own forked containers built mostly from Docker community ones. But we do not support them because often people use them before understanding Docker.
This logic is even more in play when the container is from an unknown source. So we flat out do not support containers in this forum unless another community member is willing to do so. I encourage you to learn Docker because it is the future but can’t help much here. You might try the Docker community if it’s a community supported container.
That said, make sure pio-env.sh points to the REST client on port 9200 of the container IP address. Also in the engine.json you should have a line in sparkConf that says something like es.nodes=“node1,node1” for whatever your container IP address(es) is. Make sure ES is listening on the IP and port by accessing the REST API with a tool like Elasticsearch Head, a Chrome plugin.
If `pio status` and `pio app list` work correctly the the problem must be in engin.json. Oh, and upgrade to PIO 0.12.1. It is the first non-incubating release and uses the ES REST client exclusively. I was unaware that the latest UR would run with 0.12.0-incubating.