search

kontena / kontena

The developer friendly container and micro services platform. Works on any cloud, easy to setup, simple to use.
https://www.kontena.io/
Apache License 2.0
1.47k stars 127 forks source link

.kontena.local -> .kontena #264

Open thecatwasnot opened 9 years ago

thecatwasnot commented 9 years ago

I think it's worth considering changing the domain, the .local tld causes conflicts with the avahi daemon on Ubuntu boxes. I also feel like .local would be more likely to cause conflicts with other vpns, or local network setups in bizarre ways. service.grid.kontena feels like a pretty sensible way to address things from my newbie POV. Originally suggested: https://github.com/kontena/kontena/issues/150#issuecomment-139356536

jakolehm commented 9 years ago

Yes, it seems that .local is causing a little too much trouble. We need to think this carefully so that we don't blow up existing installations. Maybe this could be some kind of option in the grid settings.

/cc @nevalla @miskun

miskun commented 9 years ago

Yes, I like the service.grid.kontena namespace. The current .local adds no real value in my mind. Just causing some conflicts in existing networks. I also like the idea of having this setting as config parameter for a Grid.

colinmollenhour commented 8 years ago

Just wrestled with this for a while.. Only solution that worked was to remove "avahi-daemon" from Ubuntu box. Pretty sure removing .local would make it a non-issue.

SpComb commented 8 years ago

Workaround for Ubuntu: the relevant package to remove is libnss-mdns; removing that should clear the hosts: mdns* entry from /etc/nsswitch.conf.

$ grep hosts /etc/nsswitch.conf 
hosts:          files mdns4_minimal [NOTFOUND=return] dns
$ sudo apt purge libnss-mdns
...
Removing libnss-mdns:amd64 (0.10-7) ...
libnss-mdns.postrm: Checking NSS setup...
libnss-mdns.postrm: Removing mdns from NSS setup
Purging configuration files for libnss-mdns:amd64 (0.10-7) ...
$ grep hosts /etc/nsswitch.conf 
hosts:          files dns

You can then still reinstall it:

$ sudo apt install libnss-mdns
...
Setting up libnss-mdns:amd64 (0.10-7) ...
First installation detected...
Checking NSS setup...
$ grep hosts /etc/nsswitch.conf 
hosts:          files mdns4_minimal [NOTFOUND=return] dns
colinmollenhour commented 7 years ago

What is the purpose of having the grid in the DNS? Nodes can't communicate across grids, can they? If there is no situation in which from one environment you can communicate with multiple grids (VPN?) it seems it would be better to just remove the grid from DNS. For example, I'm configuring monitoring and to aggregate nginx stats with DataDog I would check something like:

instances:
  - nginx_status_url: http://nginx-admin-1.web.primary.kontena.local:8081/nginx_status/
    tags:
      - role:admin
  - nginx_status_url: http://nginx-frontend-1.web.primary.kontena.local:8081/nginx_status/
    tags:
      - role:frontend
  - nginx_status_url: http://nginx-frontend-2.web.primary.kontena.local:8081/nginx_status/
    tags:
      - role:frontend
  - nginx_status_url: http://nginx-frontend-3.web.primary.kontena.local:8081/nginx_status/
    tags:
      - role:frontend

However, now my config is dependent on the grid name whereas without the grid it would work without having to substitute this in:

instances:
  - nginx_status_url: http://nginx-admin-1.web.kontena:8081/nginx_status/
    tags:
      - role:admin
  - nginx_status_url: http://nginx-frontend-1.web.kontena:8081/nginx_status/
    tags:
      - role:frontend
  - nginx_status_url: http://nginx-frontend-2.web.kontena:8081/nginx_status/
    tags:
      - role:frontend
  - nginx_status_url: http://nginx-frontend-3.web.kontena:8081/nginx_status/
    tags:
      - role:frontend
matti commented 7 years ago

Agree, but I think you can parametrize the ${GRID} away...?

On 2 Mar 2017, at 0.26, Colin Mollenhour notifications@github.com wrote:

What is the purpose of having the grid in the DNS? Nodes can't communicate across grids, can they? If there is no situation in which from one environment you can communicate with multiple grids (VPN?) it seems it would be better to just remove the grid from DNS. For example, I'm configuring monitoring and to aggregate nginx stats with DataDog I would check something like:

instances:

instances:

SpComb commented 7 years ago

Agree, but I think you can parametrize the ${GRID} away...?

In the stack files, yes, but harder in external configuration files.

If you're generating the configs inside service containers, you can use the KONTENA_GRID_NAME Docker container env.

What is the purpose of having the grid in the DNS? Nodes can't communicate across grids, can they

AFAIK the usecase is using image: registry.$GRID.kontena.local with kontena stack build while having Kontena VPN connections to different grids. Not that having multiple Kontena VPN connections active at the same time would actually behave sanely...

Non-stacked services will also have a plain service-X.kontena.local DNS name without the grid, but stacked services are only registered with the service-X.stack.grid.kontena.local name.

There's a very raw WIP branch to make the kontena grid create --dns-domain=... customizable, but that's still pending on some heavy agent refactoring work. That would let you use the same domain for every grid if you wanted to. We're working on that atm, and it may happen for 1.2..

robotmay commented 7 years ago

Bleh, I can confirm that this is still an issue on Ubuntu. I'm working on exposing the services via the load balancers instead because the workarounds don't work for me :\

Edit: I can confirm that I seem to be able to access things via the container IP, and in fact pings also work, but browsing to them by the domain doesn't.