Check if it’s a recently-introduced Docker bug by downgrading to 18.03. Can’t say it’s likely to fix it, but it’s easy enough to try it first just in case.
Modify the app.yml to run the ping test before anything else; that’ll rule in (or out) problems with the app container itself versus network issues.
After that, you’re in tcpdump territory. Capture DNS packets going over docker0 with something like tcpdump -i docker0 -n port 53, and make sure the packets are at least getting onto the network. Then make sure they’re getting out by capturing on enp1s0 as well – and make sure they’re gooing out with the machine’s public IP, rather than some internal IP. If the firewall’s too restrictive, the packets won’t show up at all on one of those tcpdumps, and if they’re on enp1s0 but with a private IP, then the NAT config’s busted.
If the packets are going out but not coming back, there’s upstream network problems (or an OUTPUT rule that’s eating them at the last minute), but given you’ve got some DNS resolution on the machine, the problem’s unlikely to be there. If the DNS response packets are coming back in part of the way, then it’s incoming firewall rules that are the problem, and if they appear to be making it all the way back to docker0, dump the veth<whatever> interface for the container to double-check, and if they’re there too, something’s setting up iptables rules inside the container, and you’re back to giving Docker some serious side-eye.