how does docker auto allocate and recycle ports for containers
When I run docker command
docker run -d -P nginx
docker will run and auto allocate port for nginx's port 80. If I stop the image and start it again, a new port will be allocated to nginx (normally next one available).
As I found out, the range for port allocation is based on ephemeral port range , in docker case default is 32768 - 61000. (https://docs.docker.com/v17.09/engine/userguide/networking/default_network/binding/)
How and when does docker recycle ports? Will it go back to 32768 or nearest available?
docker
add a comment |
When I run docker command
docker run -d -P nginx
docker will run and auto allocate port for nginx's port 80. If I stop the image and start it again, a new port will be allocated to nginx (normally next one available).
As I found out, the range for port allocation is based on ephemeral port range , in docker case default is 32768 - 61000. (https://docs.docker.com/v17.09/engine/userguide/networking/default_network/binding/)
How and when does docker recycle ports? Will it go back to 32768 or nearest available?
docker
add a comment |
When I run docker command
docker run -d -P nginx
docker will run and auto allocate port for nginx's port 80. If I stop the image and start it again, a new port will be allocated to nginx (normally next one available).
As I found out, the range for port allocation is based on ephemeral port range , in docker case default is 32768 - 61000. (https://docs.docker.com/v17.09/engine/userguide/networking/default_network/binding/)
How and when does docker recycle ports? Will it go back to 32768 or nearest available?
docker
When I run docker command
docker run -d -P nginx
docker will run and auto allocate port for nginx's port 80. If I stop the image and start it again, a new port will be allocated to nginx (normally next one available).
As I found out, the range for port allocation is based on ephemeral port range , in docker case default is 32768 - 61000. (https://docs.docker.com/v17.09/engine/userguide/networking/default_network/binding/)
How and when does docker recycle ports? Will it go back to 32768 or nearest available?
docker
docker
edited Nov 13 '18 at 10:25
vidriduch
asked Nov 12 '18 at 16:03
vidriduchvidriduch
3,67453550
3,67453550
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
It took a lot of time for me to find out but docker
doesn't do much.
I dived into docker-ce
source files and saw that it uses a function RequestPortInRange
which simply gives the next available port.
Now, when you run docker run -d -P nginx
command, docker gives you the first available port in the "ephemeral range" i.e. 32768 - 61000 ( as you pointed out).
Once you destroy /stop the container, it should resume to 32768
, However, it goes to the next available port i.e. 32769
( on my computer at least).
So, I thought may be it takes sometime for linux
or any OS to take back the port after the container is destroyed but netstat -lntu
confirms that the port isn't in use any more.
So, my theory is (which may be entirely wrong, in which case I will be glad to be corrected ), that it creates one instance of PortAllocator
thing and thus it has a state. so, the next time docker run -P ...
is called, it goes for the next available port. This is also corroborated by the fact that even when you create other containers, the docker engine
is providing you the next available port not the previous yet available ones.
I hope i answered your question and i don't know much of golang
so, forgive any mistake in terminology.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53265885%2fhow-does-docker-auto-allocate-and-recycle-ports-for-containers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It took a lot of time for me to find out but docker
doesn't do much.
I dived into docker-ce
source files and saw that it uses a function RequestPortInRange
which simply gives the next available port.
Now, when you run docker run -d -P nginx
command, docker gives you the first available port in the "ephemeral range" i.e. 32768 - 61000 ( as you pointed out).
Once you destroy /stop the container, it should resume to 32768
, However, it goes to the next available port i.e. 32769
( on my computer at least).
So, I thought may be it takes sometime for linux
or any OS to take back the port after the container is destroyed but netstat -lntu
confirms that the port isn't in use any more.
So, my theory is (which may be entirely wrong, in which case I will be glad to be corrected ), that it creates one instance of PortAllocator
thing and thus it has a state. so, the next time docker run -P ...
is called, it goes for the next available port. This is also corroborated by the fact that even when you create other containers, the docker engine
is providing you the next available port not the previous yet available ones.
I hope i answered your question and i don't know much of golang
so, forgive any mistake in terminology.
add a comment |
It took a lot of time for me to find out but docker
doesn't do much.
I dived into docker-ce
source files and saw that it uses a function RequestPortInRange
which simply gives the next available port.
Now, when you run docker run -d -P nginx
command, docker gives you the first available port in the "ephemeral range" i.e. 32768 - 61000 ( as you pointed out).
Once you destroy /stop the container, it should resume to 32768
, However, it goes to the next available port i.e. 32769
( on my computer at least).
So, I thought may be it takes sometime for linux
or any OS to take back the port after the container is destroyed but netstat -lntu
confirms that the port isn't in use any more.
So, my theory is (which may be entirely wrong, in which case I will be glad to be corrected ), that it creates one instance of PortAllocator
thing and thus it has a state. so, the next time docker run -P ...
is called, it goes for the next available port. This is also corroborated by the fact that even when you create other containers, the docker engine
is providing you the next available port not the previous yet available ones.
I hope i answered your question and i don't know much of golang
so, forgive any mistake in terminology.
add a comment |
It took a lot of time for me to find out but docker
doesn't do much.
I dived into docker-ce
source files and saw that it uses a function RequestPortInRange
which simply gives the next available port.
Now, when you run docker run -d -P nginx
command, docker gives you the first available port in the "ephemeral range" i.e. 32768 - 61000 ( as you pointed out).
Once you destroy /stop the container, it should resume to 32768
, However, it goes to the next available port i.e. 32769
( on my computer at least).
So, I thought may be it takes sometime for linux
or any OS to take back the port after the container is destroyed but netstat -lntu
confirms that the port isn't in use any more.
So, my theory is (which may be entirely wrong, in which case I will be glad to be corrected ), that it creates one instance of PortAllocator
thing and thus it has a state. so, the next time docker run -P ...
is called, it goes for the next available port. This is also corroborated by the fact that even when you create other containers, the docker engine
is providing you the next available port not the previous yet available ones.
I hope i answered your question and i don't know much of golang
so, forgive any mistake in terminology.
It took a lot of time for me to find out but docker
doesn't do much.
I dived into docker-ce
source files and saw that it uses a function RequestPortInRange
which simply gives the next available port.
Now, when you run docker run -d -P nginx
command, docker gives you the first available port in the "ephemeral range" i.e. 32768 - 61000 ( as you pointed out).
Once you destroy /stop the container, it should resume to 32768
, However, it goes to the next available port i.e. 32769
( on my computer at least).
So, I thought may be it takes sometime for linux
or any OS to take back the port after the container is destroyed but netstat -lntu
confirms that the port isn't in use any more.
So, my theory is (which may be entirely wrong, in which case I will be glad to be corrected ), that it creates one instance of PortAllocator
thing and thus it has a state. so, the next time docker run -P ...
is called, it goes for the next available port. This is also corroborated by the fact that even when you create other containers, the docker engine
is providing you the next available port not the previous yet available ones.
I hope i answered your question and i don't know much of golang
so, forgive any mistake in terminology.
edited Nov 12 '18 at 21:54
answered Nov 12 '18 at 20:12
scipsychoscipsycho
1438
1438
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53265885%2fhow-does-docker-auto-allocate-and-recycle-ports-for-containers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown