New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow users to specify an IP for their container #6743

Closed
vishh opened this Issue Jun 27, 2014 · 107 comments

Comments

Projects
None yet
@vishh
Copy link
Contributor

vishh commented Jun 27, 2014

There is no way to tie a container to an IP in docker as of now. #2801 captures this limitation.
If users were allowed to specify an IP in 'docker0' subnet that would solve this issue.
With #6704 users can be specify IPs even outside the default docker0 bridge.
#5829 was the first attempt to solve that issue.

+@crosbymichael

@acornejo

This comment has been minimized.

Copy link

acornejo commented Jan 24, 2015

+1

@crosbymichael

This comment has been minimized.

Copy link
Member

crosbymichael commented Jan 26, 2015

@erikh

just so this is not forgotten

@erikh

This comment has been minimized.

Copy link
Contributor

erikh commented Jan 27, 2015

tyvm

@jessecooper

This comment has been minimized.

Copy link

jessecooper commented Feb 19, 2015

+1
Ran into this issue when I was building a test mongodb shard cluster. I was not anticipating the IP changing on the container when it restarted.

@pgenevski

This comment has been minimized.

Copy link

pgenevski commented Feb 21, 2015

+1

1 similar comment
@coolljt0725

This comment has been minimized.

Copy link
Contributor

coolljt0725 commented Feb 22, 2015

+1

@Kokonoe

This comment has been minimized.

Copy link

Kokonoe commented Feb 26, 2015

+1

1 similar comment
@mgcrea

This comment has been minimized.

Copy link

mgcrea commented Feb 27, 2015

👍

@Ovski4

This comment has been minimized.

Copy link

Ovski4 commented Mar 5, 2015

+1

2 similar comments
@AndreiMuresan

This comment has been minimized.

Copy link

AndreiMuresan commented Mar 8, 2015

+1

@hansgru

This comment has been minimized.

Copy link

hansgru commented Mar 8, 2015

+1

@mgcrea

This comment has been minimized.

Copy link

mgcrea commented Mar 9, 2015

My alternative to address this has been to use docker-gen to regenerate on the fly the /etc/hosts of my host, providing avahi-like hostnames my-container-name.docker.

@nfnty

This comment has been minimized.

Copy link

nfnty commented Mar 10, 2015

+1

1 similar comment
@re6exp

This comment has been minimized.

Copy link

re6exp commented Mar 10, 2015

+1

@xiaods

This comment has been minimized.

Copy link
Contributor

xiaods commented Mar 11, 2015

anyone can clarify the detail proposal. do we need implement it in docker run args? i am also interest this feature implement.

@chenchun

This comment has been minimized.

Copy link
Contributor

chenchun commented Mar 19, 2015

+1

3 similar comments
@dchen1107

This comment has been minimized.

Copy link
Contributor

dchen1107 commented Mar 21, 2015

+1

@yinheli

This comment has been minimized.

Copy link

yinheli commented Mar 25, 2015

+1

@hilyjiang

This comment has been minimized.

Copy link

hilyjiang commented Apr 1, 2015

+1

@xiaods

This comment has been minimized.

Copy link
Contributor

xiaods commented Apr 6, 2015

today review the original comments and @shykes 's comments, currently we need know where is the plugin codebase, then we can evaluate the ip feature in this new plugin architect. ping @erikh , do you know where is best start plugin code base?

@itoffshore

This comment has been minimized.

Copy link

itoffshore commented Oct 15, 2015

For fixed ip addresses I've been using Alpine Linux LXC containers with runit to manage the services & logging by socklog.

If you apk add runit runit-doc socklog apk-post-messages the Alpine README will be printed with instructions to configure services with runit. socklog sets itself up.

You will need to rc-update add runitd && rc-update add socklog & start the services or reboot the container.

@candlerb

This comment has been minimized.

Copy link

candlerb commented Oct 15, 2015

But that's not docker, is it?

@itoffshore

This comment has been minimized.

Copy link

itoffshore commented Oct 15, 2015

@candlerb - I have scripts to giver docker fixed ip's but only use it for a build environment.

@candlerb

This comment has been minimized.

Copy link

candlerb commented Oct 15, 2015

Sure, that's pipework. It's mentioned lots in the comments above.

@netroby

This comment has been minimized.

Copy link

netroby commented Oct 31, 2015

Shall we persist the ip for the exists container? for real world example:

Front Web load balance == Link => web server 1 == Link => DB

Once we made some change in web server, we need restart web server , but we don't want to stop front load balance,
If we can just only restart the web server, we can prevent lots of downtime, and we can make sure our service more smothly

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Oct 31, 2015

@netroby why would you need to stop the lb in this case today?

@netroby

This comment has been minimized.

Copy link

netroby commented Oct 31, 2015

It's running on docker container, because it was link to the web server . if web server restart , the ip changed, the link still valid?

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Oct 31, 2015

Yes, link is still valid.

@netroby

This comment has been minimized.

Copy link

netroby commented Oct 31, 2015

Ok, i got it. but the load balance need to reload , because the ip changes. so i know how to do it.

@netroby

This comment has been minimized.

Copy link

netroby commented Oct 31, 2015

Thanks for your help

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented Oct 31, 2015

this may be interesting as well for that https://github.com/ehazlett/interlock

@candlerb

This comment has been minimized.

Copy link

candlerb commented Nov 1, 2015

@netroby:

Front Web load balance == Link => web server 1 == Link => DB

Once we made some change in web server, we need restart web server , but we don't want to stop front load balance,

But don't forget the common case where you decide to upgrade the web server. With the docker architecture this normally means you have to discard the old container and replace it with a new one.

In that case, there is no benefit to the old container remembering its IP address, since when you start the new container, you will have to instruct it with the correct IP address to use anyway.

Also if you're using "docker link" then you're using private internal addresses behind docker's own NAT, in that case you probably want docker to manage this for you, rather than choosing IP addresses manually for every container you start.

I'm not sure what's the best way to support the use case you suggest (i.e. stopping/starting/recreating a middle tier container for a three-tier architecture), but I don't think containers remembering their assigned IP is the right solution.

@JonasT

This comment has been minimized.

Copy link

JonasT commented Nov 2, 2015

In that case, there is no benefit to the old container remembering its IP address, since when you start the new container, you will have to instruct it with the correct IP address to use anyway.

Why that? I discard and re-create my containers all the time for upgrades (e.g. to have a simple apt-get upgrade run again with newer results), and I almost never touch the config let alone manually specify some IP again. Why would recreating a container mean I would want to waste time to manually set some things up? Docker is meant for automation, it should always be designed in a way to not force me to manually do anything if there's no good reason for it.

I'm not sure what's the best way to support the use case you suggest (i.e. stopping/starting/recreating a middle tier container for a three-tier architecture), but I don't think containers remembering their assigned IP is the right solution.

While docker link is a fair solution for a lot of things, it sucks that destroying a linked container and bringing it up again will often result in the other previously connected one to be eternally confused. I don't understand how remembering an assigned IP isn't the perfect solution for that. How would it not easily solve that scenario?

Edit: also sorry if I'm misunderstanding something here, I'm certainly not a docker link guru or anything...

@candlerb

This comment has been minimized.

Copy link

candlerb commented Nov 2, 2015

I discard and re-create my containers all the time for upgrades (e.g. to have a simple apt-get upgrade run again with newer results), and I almost never touch the config

I mean settings applied when the container is instantiated, not what's in the Dockerfile. That is, I thought we were discussing the following proposed feature:

docker run --ip 1.2.3.4 image1 container1
docker stop container1
docker start container1    # remembers IP address is 1.2.3.4

Use case: you have four webserver processes behind a load balancer process. You instantiate four copies of the same image, differing only in their IP address. So the above allows you to stop and restart container1 and continue running on the same IP address, which is helpful for the load balancer.

What I'm saying is I don't think that feature will help if you want to destroy container1 and recreate it using image2, because you will have to specify --ip 1.2.3.4 to the new docker run as well. As far as I know, there's no command which says "create container Y but copy all the run-time settings from container X".

If you have to remember externally that the IP address of container1 is 1.2.3.4, you might as well provide --ip 1.2.3.4 to docker start as well, and at that point there is no need to persist the IP address with the container at all.

Now, it might be usefu to persist the IP l if we could do this:

docker restart --new-image image2 container1

That of course is a completely different feature request. But even then there are some open questions: does the new container get the same UUID as before, or a new UUID? Does it carry forward all the unionfs layers apart from the base image?

My apologies if I've missed the point here.

@JonasT

This comment has been minimized.

Copy link

JonasT commented Nov 2, 2015

@candlerb
Ah right, I misunderstood before. Yea, I agree with what you're saying.

@robbrockbank

This comment has been minimized.

Copy link

robbrockbank commented Dec 8, 2015

Hi @mavenugo,

I'm looking for a way to specify an IP address when creating a container using docker run. You mentioned that writing an IPAM driver is one way of achieving this. I have written an IPAM driver, but I'm still not sure how to pass information through to the IPAM driver to know that a particular container needs to be assigned a particular IP address. What would be the recommended approach when writing your own driver to achieve this.

Is it possible to specify arbitrary options on the docker run command that get passed into the IPAM and network drivers, or would you expect some pre-configuration that allows the IPAM driver to lookup a particular container and then select the IP address that it should be assigned, and in this case how would the container endpoint be identified before the container is created?

@mavenugo

This comment has been minimized.

Copy link
Contributor

mavenugo commented Dec 8, 2015

@robbrockbank we had a few discussions on this topic recently & @aboch is looking at the way to provide this support in conjunction with IPAM (we had a recent fix in IPAM integration to support that).
@aboch can you please add more details to this ?

@aboch

This comment has been minimized.

Copy link
Contributor

aboch commented Dec 8, 2015

@robbrockbank
In order for user to specify a preferred address for the container, plan is to add an explicit --ip (--ip6) option to docker run to be used in conjunction with --subnet.
Your ipam driver will ultimately receive the user chosen address as parameter of the RequestAddress() call.
This is WIP and it is planned for 1.10.

I am also planning some work to allow DHCP based ipam plugins, where libnetwork would set the endpoint MAC address in the options parameter in the call to RequestAddress if the ipam driver expressed this need during registration.

@kevinxucs

This comment has been minimized.

Copy link

kevinxucs commented Dec 9, 2015

@aboch is there a timeframe when 1.10 will be released?

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented Dec 9, 2015

@kevinxucs 1.10 is expected to be released somewhere in February, due to the Holidays and New Year

@Frogging101

This comment has been minimized.

Copy link

Frogging101 commented Dec 9, 2015

@aboch The built-in IPAM driver will support this, right? No need to write our own IPAM drivers to specify the IP address when running a container?

@aboch

This comment has been minimized.

Copy link
Contributor

aboch commented Dec 9, 2015

@Frogging101
Yes, the built-in IPAM driver will honor the preferred IP option specified by the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment