docker-hostmanager
docker-hostmanager copied to clipboard
Add DOMAIN_NAME for networks
Resolves #32
Add the possibility to add a DOMAIN_NAME for containers in a network. To specify the network concerned by the domain name, add my_network_name: before value. Exemple :
version: '2'
networks:
first:
driver: bridge
second:
driver: bridge
services:
web:
image: php:7-apache
environment:
- "DOMAIN_NAME=first:web,first:www.web"
networks:
- first
- second
db:
image: php:7-apache
environment:
- "DOMAIN_NAME=first:db,second:database"
networks:
- first
- second
mail:
image: php:7-apache
environment:
- "DOMAIN_NAME=first:mail"
networks:
- first
will result in
## docker-hostmanager-start
172.26.0.4 ... db.dockerhostmanager_first db
172.25.0.3 ... db.dockerhostmanager_second database
172.26.0.3 ... web.dockerhostmanager_first web www.web
172.25.0.2 ... web.dockerhostmanager_second
172.26.0.2 ... mail.dockerhostmanager_first mail
## docker-hostmanager-end
@iamluc What the state of this PR? I would love to see it merged :)
ping @Jean-Beru Have you time to work on this ?
Not really but I will do an effort just fo you @iamluc ;-)
Hi there, Is there any news about this PR ?
Note: it seems that using this patch does work, but you need to specify the network, like so:
web:
environment:
- DOMAIN_NAME=default:foo.bar
Without the default, it did not work for me. Maybe we can allow for default being equal to null so it works out of the box?
@iamluc what can we do to get this built and pushed to Docker Hub? :)
Hi @dkarlovi thanks for testing.
I'm gonna try to finish this PR with @Jean-Beru and @mykiwi in a few days.
BTW I've pushed this to https://hub.docker.com/r/dkarlovi/docker-hostmanager/ as a workaround, will remove it once this gets merged.
@iamluc any news on this?
I discussed with @Jean-Beru about this PR, and the need is not clearly defined (IMHO).
Could you tell if those examples help you to do what you want to achieve ? https://github.com/iamluc/docker-hostmanager/pull/39/files
Any help to improve the documentation is also welcomed :smile:
@iamluc hostmanager adds some non-human-friendly Docker hosts to /etc/hosts:
## docker-hostmanager-start
172.20.0.2 reverse-proxy.traefik_loc 5b13bd735a62.traefik_loc traefik.traefik_loc
172.27.0.3 rabbitmq.arm_default 6f60c1c9caa7.arm_default arm_rabbitmq_1.arm_default
## docker-hostmanager-end
The goal here is to allow define user-friendly one(s) so it can be accessed and configured as developer wants, so instead of the lines above we can get:
## docker-hostmanager-start
172.20.0.2 traefik.loc reverse-proxy.traefik_loc 5b13bd735a62.traefik_loc traefik.traefik_loc
172.27.0.3 rabbit.loc rabbitmq.arm_default 6f60c1c9caa7.arm_default arm_rabbitmq_1.arm_default
## docker-hostmanager-end
and use traefik.loc and rabbit.loc in the browser or other tools (always, even if project's directories and/or services would change name).
@Wirone What I mean is that you can already do that:
version: '2'
networks:
default:
external:
name: loc
services:
traefik:
image: traefik
rabbit:
image: rabbit
Will have the same result.
Of course you need to create the loc network yourself.
But it can be automated. I personally do it in a Makefile (e.g. make start)
@iamluc
Of course you need to create the loc network yourself.
This makes the process a bit more complex in a cross-cutting team, as you must always ship additional tooling too. It might also lead to collisions (where multiple projects are trying to create the same external network).
Also, it doesn't allow you to have different / multiple / no suffixes if the need arises, if I understood correctly.
This makes the process a bit more complex in a cross-cutting team, as you must always ship additional tooling too
In fact, this is not needed anymore. Since compose file version 3.5, you can change the name of the network (https://docs.docker.com/compose/compose-file/#name-1).
networks:
default:
name: mynetwork
Also, it doesn't allow you to have different / multiple / no suffixes
You can have define multiple networks, it will result to multiple suffix.
version: '3.5'
networks:
default:
name: mynetwork
backend:
name: backend
services:
app:
image: myimage
networks:
- default
- backend
Indeed a suffix is required, but I don't think it is a good idea to not have one.
A very important point to me is that with this system, hostnames are the same whether you are inside a container or outside from you host, because we do the same thing docker does.
If we allow changing the hostname with a label or an env var, it will works ONLY from the host
hostnames are the same whether you are inside a container or outside from you host, because we do the same thing docker does
That does sound neat. But, would it lead to problems?
For example, I wish to always use the suffix local for my projects. If I start up two separate projects at the same time, they'll both try to create redis.local even though I don't need Redis to be available at all.
Also, note that I'm using a actual valid FQDN for some of my projects to allow them to have valid Let's Encrypt certs (example, project.dev.company.com). This would mean my network name would have to be a very common TLD.
Hi @iamluc, have you decided how to proceed here?
IMHO, this feature is not needed so I will not work on it.
BUT, if someone wants to finish it, validates it is working and ensures it breaks nothing. I will agree to merge it.
We've been using this since I've pushed my own image with the PR merged. It does work as expected.
Yep, but it would be great if someone could reply to the comments: https://github.com/iamluc/docker-hostmanager/pull/34/files#r86107703 https://github.com/iamluc/docker-hostmanager/pull/34/files#r184656291
And also document this feature in the README
Fair :+1: I try to get this done in the near future.
also, please change the target of the PR to the develop branch. This way I will test it for some days.
@dkarlovi @iamluc would be good to finish this somehow... is there something we can do to get this PR merged? Using Dalibor's fork is OK, but maintaining it (keeping up-to-date) isn't something easy I think. Additionally, Dalibor's fork does NOT contain changes in readme, so sharing link to the repo isn't enough (I just sent it to my colleague and he installed iamluc/docker-hostmanager because documentation states so...).
Gotta admit I've forgotten about my promise here. I'm using my image ever since I've pushed it, with my entire team (we've documented it in our project) so it's basically fire & forget currently.
@Wirone If you feel like you'd get additional value from this being merged, maybe you can take over the PR and get it merged?
@dkarlovi how is it possible technically? PR is from @Jean-Beru's branch, if we want to continue in this PR I would need to get access to that repo :thinking:? Or maybe you mean forking fork and creating new PR?
You just fork this repo, add @Jean-Beru's repo as an additional remote and checkout the PR branch into your own. Any commit you make would of course be made to your own branch which gets a separate PR, but all the code is already there. Otherwise you'd need to do PRs against that repo which is inefficient.
There's some Github magic with refs which allows you to do it automagically, but I always forget how.
Yo, do we have to drop this one in favor of dkarlovi's one if this feature does not workas expected ? :open_mouth: