Labels format in Docker

[YankeeInLondon]

I had been looking for examples of how to add labels properly and have Traefik dynamically incorporate it. I am using docker-compose to configure my services and recently someone who's been around the block a few times suggested this configuration for Traefik and the classic "whoami" service:

version: "3.9"

services:
  traefik:
    image: traefik:v2.8
    container_name: traefik
    command:
      - --api.insecure=true
      - --log.level=DEBUG
      - --providers.docker
      - --entrypoints.web.address=:80
      - --entrypoints.web.http.redirections.entryPoint.to=websecure
      - --entrypoints.web.http.redirections.entrypoint.scheme=https
      - --entrypoints.websecure.address=:443
      - --entrypoints.websecure.http.tls=true
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

  whoami:
    image: traefik/whoami:v1.8.1
    container_name: whoami
    labels:
      traefik.http.routers.whoami.rule: Host(`whoami.local`)
      traefik.http.routers.whoami.entrypoints: websecure

Using this alone, my whoami service works but I was surprised to see "labels" configured as an object hash of key/values. Though much nicer than an array in most cases I've seen examples like this:

labels:
  - traefik.http.routers.strapi.rule=Host(`strapi.local`)
  - traefik.http.routers.strapi.entrypoints=websecure
  - traefik.http.services.strapi.loadbalancer.server.port=1337

Is there a correct one? I will say, because the objection notation is nicer (imo) and worked for "whoami" I figured I'd use that. However, when I try to start the popular CMS Strapi up with this docker-compose file:

version: '3.9'
services:
  strapi:
    image: strapi/strapi
    restart: unless-stopped
    volumes:
      - /home/ken/data/strapi:/srv/app
    ports:
      - '1337:1337'
    labels:
      traefik.enable: true
      traefik.http.routers.strapi.rule: Host(`strapi.local`)
      traefik.http.routers.strapi.entrypoints: websecure
      traefik.http.services.strapi.loadbalancer.server.port: 1337

I get no errors but it just never shows up in Traefik! So then my ability to revert to old bad habits kicks in and I try this instead:

labels:
  - traefik.enable=true
  - traefik.http.routers.strapi.rule=Host(`strapi.local`)
  - traefik.http.routers.strapi.entrypoints=websecure
  - traefik.http.services.strapi.loadbalancer.server.port=1337

Now suddenly it shows in Traefik! Looking at it's definition it looks good too:

However, go to strapi.local and it redirects to HTTPS and then after accepting my SSL key I get nothing for a bit and then a Gateway Timeout. What gives? What's right?

[ldez]

Docker has a specific interpretation of boolean when using key/value syntax: you have to add quotes around the value:

traefik.enable: 'true'

[YankeeInLondon]

Ok, good to know. I'll give it a try and if it works I'll add to my list of reasons I don't like YAML

[YankeeInLondon]

Ok, so I believe this is probably a step in the right direction however things are not well in newbie-land. After quoting the boolean value I do indeed get the object notation to work but it appears to work in precisely the same way that the array notation worked ... meaning it times out after 30 seconds.

So my assumptions right now are that:

• both array and object syntax works for labels in Docker
• array syntax is a bit more forgiving in interpreting boolean types but object syntax is far prettier in an editor like vs-code
• both fail equally to actually expose the service with the current configuration
• I am also uncertain why the "whoami" service did not even need the enable: true configuration but other packages seem to be ignored unless they have it?

What else could be wrong here? How should I be debugging this?

[YankeeInLondon]

Now this is a strange one ... I was trying to compare the whoami service configuration to the strapi one which I'm trying to get to work and noticed that while all my services -- strapi but also other containers I'm running on Docker -- are internally put on the 172.x.y.z network but to my surprise (and mild horror) the whoami service is operating on 192.168.48.x which is odd and may come into conflict with sub-domains I'm directly managing.

Furthermore, when further analyzing the output of whoami I get this:

All the way at the bottom is my client's actual IP address but what are 192.168.48.[2,3] doing there? There clearly is something going on here from a networking standpoint that I don't understand and this might all be a Red Herring but still it was the only major difference I found looking at the dashboard UI that distinguished a working example from a non-working one.