compose control network domain name

[dwaite]

When I create a "foo.com" network with docker-compose, the network appears to be changed and to be dynamic.

The containers themselves talk to each other with TLS, and do hostname validation. So, the DNS resolution for my network has to have the services be addressed in the form of "foo.bar.com".

Today I'm handling this by having docker-compose attach to an externally created network so that I can control the FQDN. Is there another way to accomplish this?

[shin-]

Are you looking for aliases?

[dwaite]

Are aliases within a domain, or can they be FQDNs?

[shin-]

They're always fully qualified.

[dwaite]

I believe my issue is that for:

version: "2"
networks:
  bar.com:
services:
  foo:
    networks:
      bar.com:

a FQDN is created based on the service label (not dynamic container name) and the dynamic network name (not network label). So my service isn't reachable as foo.bar.com, but something like foo.folder_bar.com.

Would it be worth opening an issue that there should be a default alias created of foo.bar.com?

[shin-]

This should work, unless I'm misunderstanding the use case.

version: "2"
networks:
  bar.com:
services:
  foo:
    networks:
      bar.com:
        aliases:
          - foo.bar.com

[dwaite]

Yes, it does. I'm wondering if I should open an issue that that particular alias should be automatic under compose - today without specifying an alias, your service will wind up with a DNS name in the form of foo.foldername_bar.com

[WolfgangFahl]

This report is more than a year old and for me falls in to the category of useability issues. The workaround above is non intuitive and most awkward. Setting the fqdn foo.bar.com directly would IMHO be most sensible.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.

[WolfgangFahl]

Again automatically closed with no fix. The need is still there - how do you no that it's not?

[glours]

We added the bot to do some automatic cleanup & get more visibility on what's really matter or not. There's currently too much issues open, some for years, and it can be difficult to prioritize what to do.

When the bot mark an issue as stale, you only have to add a comment to remove this status.

I reopen the issue

[stale[bot]]

This issue has been automatically marked as not stale anymore due to the recent activity.

[stale[bot]]

This issue has been automatically marked as not stale anymore due to the recent activity.

[WolfgangFahl]

How about teaching the bot not to close issues that have a certain comment content /number of upvotes or the like?

[rbuckland]

Where is this ticket up to ? I would expect that

  foobar:
    image: ${image_foobar}
    domainname: test-local
    dns_search:
            - test-local

would have expected

1. give the foobar image a DNS entry of foobar and foobar.test-local in the internal DNS server. It doesn't
2. to give all containers the default service-name and service.${COMPOSE_PROJECT_NAME}

the latter would mean simply

# test-local/docker-compose.yml
...
  foobar:
    image: ${image_foobar}

automatically gives the entries foobar and foobar.test-local This would make creating test harnesses really nice.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dwaite]

Still a usability issue with a non-intuitive workaround. It's only stale in the sense that there's no proper triage for issues, so as such it may remain a usability issue forever.

[stale[bot]]

This issue has been automatically marked as not stale anymore due to the recent activity.