1
votes

I have a 3rd party Tomcat server image/container running in LinuxVM on Azure. The LinxVM actually started as 2 images(NGINX loadbalancer) running via a docker-compose script, but to test this on a webapp I've wittled down to just the single tomcat image. Now, the compose script uses the key:

ports:
    - 80:8090
    - 8445:8443

In the VM I can run the docker-compose script and hit http://mypage:80 and it works just fine. I can also run:

docker run -d -p <somePort>:8090 --name tomcat_1 <myrepo/myimage>

I can then access my site with http://mypage:<somePort> regardless of which port I want to map to the container. This all works great.

Now, with the Azure Web App, I'm using an Azure Web App for Containers --> Docker Compose (Preview). My compose script looks something like:

version: "3.0"
services:
    pdfd-tomcat:
            image: <myrepo/myimage>
            build:
                context: .
                args:
                    INCLUDE_DEMO: 'true'
                    LIBRE_SUPPORT: 'false'
                    HTML_SUPPORT: 'false'
            container_name: Blackbox
            environment:
                TRN_PDFNET_KEY:
                TRN_DB_TYPE: SQLITE
                TRN_DB_LINK:
                TRN_BALANCER_COOKIE_NAME: HAPROXID
                TRN_DEBUG_MODE: 'false'
            ports:
                - 80:8090
                - 8445:8443

I've exposed 80:8090 because I've read that Azure Web Apps only expose port 80 and 443 by default. However, I cannot access this site from any port once the web app is spun up. I've verified running this same compose script works in a VM. Now, when I hit the web app logs, I see this:

Status: Image is up to date for <myrepo/myimage>

2018-06-17 05:38:41.298 INFO  - Starting container for site
2018-06-17 05:38:41.298 INFO  - docker run -d -p 18455:8090 --name tomcat_1 -e WEBSITE_SITE_NAME=<mywebsite> -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_INSTANCE_ID=<stuff goes here>

2018-06-17 05:38:41.298 INFO  - Logging is not enabled for this container.
Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
2018-06-17 05:38:56.994 INFO  - Started multi-container app
2018-06-17 05:38:57.008 INFO  - Container tomcat_1 for site <mywebsite> initialized successfully.

So, it seems that it's trying to map external port: 18455 to my internal 8090 port. Why? Also, if I try to hit my site via that port, I can't. Each time the app deploys/restarts it maps a different external port.

Also, if I retroactively go to 'Application Settings' and use the key/value: WEBSITES_PORT:<current externally mapped port> it has literally no effect. Then if the app gets restarted/redeployed, I can see that WEBSITES_PORT:<port> is what the previous port was mapped with, but since that changes every deployment, the current external port and the WEBSITES_PORT values never match. I don't even know if it works to begin with.

How the heck do get this working in a deterministic manner? I can supply other material if needed.

1

1 Answers

0
votes

This boiled down to a permissions issue when using Tomcat 9.0+ with Docker.

Permission problem while running tomcat as a non-root user

The Dockerfile would create a new usergroup and add a user, then give that user permissions in the folders where Tomcat existed. If you jumped into the container via docker exec /bin/bash and checked permissions, they all seemed perfectly fine. However, logs would show that Tomcat couldn't gain access to those folders.

Once I implemented the fix as described by Empinator in the link everything worked (using root also worked).