8000 Proposal - Image defined probe · Issue #21143 · moby/moby · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Proposal - Image defined probe #21143

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.

Sign up for GitHub

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

Jump to bottom
Closed
icecrime opened this issue Mar 11, 2016 · 5 comments · Fixed by #23218
Closed

Proposal - Image defined probe #21143

icecrime opened this issue Mar 11, 2016 · 5 comments · Fixed by #23218
Labels
kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny
Milestone
1.12.0

Comments

@icecrime
Copy link
Contributor

Problem statement

This is a followup to #21142 to discuss the idea of adding a way to specify a default "alive probe" for all containers started from a particular image.

Proposal

Introduce a new Dockerfile instruction to specify the probe. The (yet to be used) support for instructions options could be leveraged to model the design proposed for the CLI.

  • An image would optionally have a single probe definition, and any new occurrence of that instruction (either in the same Dockerfile, or in a child image) would override the previous one.
  • The default probe could be overridden through the command-line.

Open questions:

  • Ping @tianon: what's your opinion on that in the context of official images?

Ping @crosbymichael @tonistiigi @mgoelzer @aluzzardi @ehazlett
@tianon
Copy link
Member
tianon commented Mar 11, 2016

I definitely think that this is useful to be able to set a default in the image metadata, given that the image author is going to be in the best position to say what conditions generally make a given service be considered "available" (especially if they need to write and include in the image a potentially complex script for determining as much), and then the operator can decide whether they want to use those as-is, define their own, or disable such checks entirely.

The place I see instant value for this is for images like databases and their consumers -- for example, the official wordpress image has a really boring "retry" loop to just keep trying to hit MySQL until it's actually initialized, configured, and up and ready for connections.

I've got some other comments/thoughts for the implementation itself, but I'll go post those on the issue discussing the runtime feature. 👍

@tianon tianon mentioned this issue Mar 12, 2016
Closed
@dnephin
Copy link
Member
dnephin commented Mar 15, 2016

I wonder if the configuration for these "probes" is really consistent enough between environments and different users that it would belong in the image. An image author could still provide the necessary scripts or endpoints, and document that they are available, without having to provide the probe configuration.

It also seems likely that images that are extended would be forced to modify the probe configuration quite often, which could make it more work to extend these images.

@calavera calavera mentioned this issue Mar 15, 2016
Closed
@programmerq programmerq added the kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny label Mar 18, 2016
@talex5 talex5 mentioned this issue May 13, 2016
Closed
@thaJeztah
Copy link
Member

There's a pull request opened to implement this, so anyone that's interested, PTAL at #22719

@AkihiroSuda
Copy link
8000 Member

@thaJeztah Is this issue closable? #23218

@thaJeztah
Copy link
Member

Yes! If forgot the "closes" mention in my carry, thanks!

implemented in #23218

@thaJeztah thaJeztah added this to the 1.12.0 milestone Jun 3, 2016
@thaJeztah thaJeztah mentioned this issue Jun 3, 2016
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny
Projects
None yet
Milestone
1.12.0
Development

Successfully merging a pull request may close this issue.

[Carry 22719] healthcheck feature thaJeztah/docker
6 participants
@programmerq @tianon @dnephin @icecrime @thaJeztah @AkihiroSuda
2A8E
0