1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
moby--moby/integration-cli/docker_cli_health_test.go

168 lines
5.4 KiB
Go
Raw Normal View History

Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
package main
import (
"encoding/json"
"strconv"
"strings"
"testing"
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
"time"
"github.com/docker/docker/api/types"
"github.com/docker/docker/integration-cli/cli/build"
"gotest.tools/assert"
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
)
rm-gocheck: check.C -> testing.T sed -E -i 's#\bcheck\.C\b#testing.T#g' \ -- "integration-cli/check_test.go" "integration-cli/daemon/daemon.go" "integration-cli/daemon/daemon_swarm.go" "integration-cli/daemon_swarm_hack_test.go" "integration-cli/docker_api_attach_test.go" "integration-cli/docker_api_build_test.go" "integration-cli/docker_api_build_windows_test.go" "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_containers_windows_test.go" "integration-cli/docker_api_exec_resize_test.go" "integration-cli/docker_api_exec_test.go" "integration-cli/docker_api_images_test.go" "integration-cli/docker_api_inspect_test.go" "integration-cli/docker_api_logs_test.go" "integration-cli/docker_api_network_test.go" "integration-cli/docker_api_stats_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_api_swarm_service_test.go" "integration-cli/docker_api_swarm_test.go" "integration-cli/docker_api_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_attach_unix_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_cp_from_container_test.go" "integration-cli/docker_cli_cp_test.go" "integration-cli/docker_cli_cp_to_container_test.go" "integration-cli/docker_cli_cp_to_container_unix_test.go" "integration-cli/docker_cli_cp_utils_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_plugins_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_events_test.go" "integration-cli/docker_cli_events_unix_test.go" "integration-cli/docker_cli_exec_test.go" "integration-cli/docker_cli_exec_unix_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_history_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_info_unix_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_login_test.go" "integration-cli/docker_cli_logout_test.go" "integration-cli/docker_cli_logs_test.go" "integration-cli/docker_cli_netmode_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_logdriver_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_proxy_test.go" "integration-cli/docker_cli_prune_unix_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_pull_local_test.go" "integration-cli/docker_cli_pull_test.go" "integration-cli/docker_cli_push_test.go" "integration-cli/docker_cli_registry_user_agent_test.go" "integration-cli/docker_cli_restart_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_save_load_test.go" "integration-cli/docker_cli_save_load_unix_test.go" "integration-cli/docker_cli_search_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_service_logs_test.go" "integration-cli/docker_cli_service_scale_test.go" "integration-cli/docker_cli_sni_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_stats_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_swarm_unix_test.go" "integration-cli/docker_cli_top_test.go" "integration-cli/docker_cli_update_unix_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_v2_only_test.go" "integration-cli/docker_cli_volume_test.go" "integration-cli/docker_deprecated_api_v124_test.go" "integration-cli/docker_deprecated_api_v124_unix_test.go" "integration-cli/docker_hub_pull_suite_test.go" "integration-cli/docker_utils_test.go" "integration-cli/events_utils_test.go" "integration-cli/fixtures_linux_daemon_test.go" "integration-cli/utils_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/memory/memory_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:55 -04:00
func waitForHealthStatus(c *testing.T, name string, prev string, expected string) {
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
prev = prev + "\n"
expected = expected + "\n"
for {
out, _ := dockerCmd(c, "inspect", "--format={{.State.Health.Status}}", name)
if out == expected {
return
}
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, out, prev)
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
if out != prev {
return
}
time.Sleep(100 * time.Millisecond)
}
}
rm-gocheck: check.C -> testing.T sed -E -i 's#\bcheck\.C\b#testing.T#g' \ -- "integration-cli/check_test.go" "integration-cli/daemon/daemon.go" "integration-cli/daemon/daemon_swarm.go" "integration-cli/daemon_swarm_hack_test.go" "integration-cli/docker_api_attach_test.go" "integration-cli/docker_api_build_test.go" "integration-cli/docker_api_build_windows_test.go" "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_containers_windows_test.go" "integration-cli/docker_api_exec_resize_test.go" "integration-cli/docker_api_exec_test.go" "integration-cli/docker_api_images_test.go" "integration-cli/docker_api_inspect_test.go" "integration-cli/docker_api_logs_test.go" "integration-cli/docker_api_network_test.go" "integration-cli/docker_api_stats_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_api_swarm_service_test.go" "integration-cli/docker_api_swarm_test.go" "integration-cli/docker_api_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_attach_unix_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_cp_from_container_test.go" "integration-cli/docker_cli_cp_test.go" "integration-cli/docker_cli_cp_to_container_test.go" "integration-cli/docker_cli_cp_to_container_unix_test.go" "integration-cli/docker_cli_cp_utils_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_plugins_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_events_test.go" "integration-cli/docker_cli_events_unix_test.go" "integration-cli/docker_cli_exec_test.go" "integration-cli/docker_cli_exec_unix_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_history_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_info_unix_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_login_test.go" "integration-cli/docker_cli_logout_test.go" "integration-cli/docker_cli_logs_test.go" "integration-cli/docker_cli_netmode_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_logdriver_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_proxy_test.go" "integration-cli/docker_cli_prune_unix_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_pull_local_test.go" "integration-cli/docker_cli_pull_test.go" "integration-cli/docker_cli_push_test.go" "integration-cli/docker_cli_registry_user_agent_test.go" "integration-cli/docker_cli_restart_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_save_load_test.go" "integration-cli/docker_cli_save_load_unix_test.go" "integration-cli/docker_cli_search_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_service_logs_test.go" "integration-cli/docker_cli_service_scale_test.go" "integration-cli/docker_cli_sni_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_stats_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_swarm_unix_test.go" "integration-cli/docker_cli_top_test.go" "integration-cli/docker_cli_update_unix_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_v2_only_test.go" "integration-cli/docker_cli_volume_test.go" "integration-cli/docker_deprecated_api_v124_test.go" "integration-cli/docker_deprecated_api_v124_unix_test.go" "integration-cli/docker_hub_pull_suite_test.go" "integration-cli/docker_utils_test.go" "integration-cli/events_utils_test.go" "integration-cli/fixtures_linux_daemon_test.go" "integration-cli/utils_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/memory/memory_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:55 -04:00
func getHealth(c *testing.T, name string) *types.Health {
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
out, _ := dockerCmd(c, "inspect", "--format={{json .State.Health}}", name)
var health types.Health
err := json.Unmarshal([]byte(out), &health)
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, err, nil)
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
return &health
}
rm-gocheck: check.C -> testing.T sed -E -i 's#\bcheck\.C\b#testing.T#g' \ -- "integration-cli/check_test.go" "integration-cli/daemon/daemon.go" "integration-cli/daemon/daemon_swarm.go" "integration-cli/daemon_swarm_hack_test.go" "integration-cli/docker_api_attach_test.go" "integration-cli/docker_api_build_test.go" "integration-cli/docker_api_build_windows_test.go" "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_containers_windows_test.go" "integration-cli/docker_api_exec_resize_test.go" "integration-cli/docker_api_exec_test.go" "integration-cli/docker_api_images_test.go" "integration-cli/docker_api_inspect_test.go" "integration-cli/docker_api_logs_test.go" "integration-cli/docker_api_network_test.go" "integration-cli/docker_api_stats_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_api_swarm_service_test.go" "integration-cli/docker_api_swarm_test.go" "integration-cli/docker_api_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_attach_unix_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_cp_from_container_test.go" "integration-cli/docker_cli_cp_test.go" "integration-cli/docker_cli_cp_to_container_test.go" "integration-cli/docker_cli_cp_to_container_unix_test.go" "integration-cli/docker_cli_cp_utils_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_plugins_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_events_test.go" "integration-cli/docker_cli_events_unix_test.go" "integration-cli/docker_cli_exec_test.go" "integration-cli/docker_cli_exec_unix_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_history_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_info_unix_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_login_test.go" "integration-cli/docker_cli_logout_test.go" "integration-cli/docker_cli_logs_test.go" "integration-cli/docker_cli_netmode_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_logdriver_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_proxy_test.go" "integration-cli/docker_cli_prune_unix_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_pull_local_test.go" "integration-cli/docker_cli_pull_test.go" "integration-cli/docker_cli_push_test.go" "integration-cli/docker_cli_registry_user_agent_test.go" "integration-cli/docker_cli_restart_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_save_load_test.go" "integration-cli/docker_cli_save_load_unix_test.go" "integration-cli/docker_cli_search_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_service_logs_test.go" "integration-cli/docker_cli_service_scale_test.go" "integration-cli/docker_cli_sni_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_stats_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_swarm_unix_test.go" "integration-cli/docker_cli_top_test.go" "integration-cli/docker_cli_update_unix_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_v2_only_test.go" "integration-cli/docker_cli_volume_test.go" "integration-cli/docker_deprecated_api_v124_test.go" "integration-cli/docker_deprecated_api_v124_unix_test.go" "integration-cli/docker_hub_pull_suite_test.go" "integration-cli/docker_utils_test.go" "integration-cli/events_utils_test.go" "integration-cli/fixtures_linux_daemon_test.go" "integration-cli/utils_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/memory/memory_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:55 -04:00
func (s *DockerSuite) TestHealth(c *testing.T) {
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
testRequires(c, DaemonIsLinux) // busybox doesn't work on Windows
existingContainers := ExistingContainerIDs(c)
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
imageName := "testhealth"
buildImageSuccessfully(c, imageName, build.WithDockerfile(`FROM busybox
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
RUN echo OK > /status
CMD ["/bin/sleep", "120"]
STOPSIGNAL SIGKILL
HEALTHCHECK --interval=1s --timeout=30s \
CMD cat /status`))
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
// No health status before starting
name := "test_health"
cid, _ := dockerCmd(c, "create", "--name", name, imageName)
out, _ := dockerCmd(c, "ps", "-a", "--format={{.ID}} {{.Status}}")
out = RemoveOutputForExistingElements(out, existingContainers)
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, out, cid[:12]+" Created\n")
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
// Inspect the options
out, _ = dockerCmd(c, "inspect",
"--format=timeout={{.Config.Healthcheck.Timeout}} interval={{.Config.Healthcheck.Interval}} retries={{.Config.Healthcheck.Retries}} test={{.Config.Healthcheck.Test}}", name)
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, out, "timeout=30s interval=1s retries=0 test=[CMD-SHELL cat /status]\n")
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
// Start
dockerCmd(c, "start", name)
waitForHealthStatus(c, name, "starting", "healthy")
// Make it fail
dockerCmd(c, "exec", name, "rm", "/status")
waitForHealthStatus(c, name, "healthy", "unhealthy")
// Inspect the status
out, _ = dockerCmd(c, "inspect", "--format={{.State.Health.Status}}", name)
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, out, "unhealthy\n")
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
// Make it healthy again
dockerCmd(c, "exec", name, "touch", "/status")
waitForHealthStatus(c, name, "unhealthy", "healthy")
// Remove container
dockerCmd(c, "rm", "-f", name)
// Disable the check from the CLI
dockerCmd(c, "create", "--name=noh", "--no-healthcheck", imageName)
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
out, _ = dockerCmd(c, "inspect", "--format={{.Config.Healthcheck.Test}}", "noh")
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, out, "[NONE]\n")
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
dockerCmd(c, "rm", "noh")
// Disable the check with a new build
buildImageSuccessfully(c, "no_healthcheck", build.WithDockerfile(`FROM testhealth
HEALTHCHECK NONE`))
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
out, _ = dockerCmd(c, "inspect", "--format={{.Config.Healthcheck.Test}}", "no_healthcheck")
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, out, "[NONE]\n")
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
// Enable the checks from the CLI
_, _ = dockerCmd(c, "run", "-d", "--name=fatal_healthcheck",
"--health-interval=1s",
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
"--health-retries=3",
"--health-cmd=cat /status",
"no_healthcheck")
waitForHealthStatus(c, "fatal_healthcheck", "starting", "healthy")
health := getHealth(c, "fatal_healthcheck")
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, health.Status, "healthy")
assert.Equal(c, health.FailingStreak, 0)
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
last := health.Log[len(health.Log)-1]
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, last.ExitCode, 0)
assert.Equal(c, last.Output, "OK\n")
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
// Fail the check
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
dockerCmd(c, "exec", "fatal_healthcheck", "rm", "/status")
waitForHealthStatus(c, "fatal_healthcheck", "healthy", "unhealthy")
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
failsStr, _ := dockerCmd(c, "inspect", "--format={{.State.Health.FailingStreak}}", "fatal_healthcheck")
fails, err := strconv.Atoi(strings.TrimSpace(failsStr))
rm-gocheck: IsNil sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.IsNil\b#assert.Assert(c, \1 == nil#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_attach_unix_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_cp_from_container_test.go" "integration-cli/docker_cli_cp_to_container_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_history_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_pull_local_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_save_load_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "integration-cli/docker_hub_pull_suite_test.go" "integration-cli/docker_utils_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/memory/memory_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:57 -04:00
assert.Assert(c, err == nil)
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, fails >= 3, true)
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
dockerCmd(c, "rm", "-f", "fatal_healthcheck")
// Check timeout
// Note: if the interval is too small, it seems that Docker spends all its time running health
// checks and never gets around to killing it.
_, _ = dockerCmd(c, "run", "-d", "--name=test",
"--health-interval=1s", "--health-cmd=sleep 5m", "--health-timeout=1s", imageName)
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
waitForHealthStatus(c, "test", "starting", "unhealthy")
health = getHealth(c, "test")
last = health.Log[len(health.Log)-1]
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, health.Status, "unhealthy")
assert.Equal(c, last.ExitCode, -1)
assert.Equal(c, last.Output, "Health check exceeded timeout (1s)")
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
dockerCmd(c, "rm", "-f", "test")
// Check JSON-format
buildImageSuccessfully(c, imageName, build.WithDockerfile(`FROM busybox
RUN echo OK > /status
CMD ["/bin/sleep", "120"]
STOPSIGNAL SIGKILL
HEALTHCHECK --interval=1s --timeout=30s \
CMD ["cat", "/my status"]`))
out, _ = dockerCmd(c, "inspect",
"--format={{.Config.Healthcheck.Test}}", imageName)
rm-gocheck: Equals -> assert.Equal sed -E -i 's#\bassert\.Assert\(c, (.*), checker\.Equals, (.*)#assert.Equal(c, \1, \2#g' \ -- "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_volume_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:56 -04:00
assert.Equal(c, out, "[CMD cat /my status]\n")
Add support for user-defined healthchecks This PR adds support for user-defined health-check probes for Docker containers. It adds a `HEALTHCHECK` instruction to the Dockerfile syntax plus some corresponding "docker run" options. It can be used with a restart policy to automatically restart a container if the check fails. The `HEALTHCHECK` instruction has two forms: * `HEALTHCHECK [OPTIONS] CMD command` (check container health by running a command inside the container) * `HEALTHCHECK NONE` (disable any healthcheck inherited from the base image) The `HEALTHCHECK` instruction tells Docker how to test a container to check that it is still working. This can detect cases such as a web server that is stuck in an infinite loop and unable to handle new connections, even though the server process is still running. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. The options that can appear before `CMD` are: * `--interval=DURATION` (default: `30s`) * `--timeout=DURATION` (default: `30s`) * `--retries=N` (default: `1`) The health check will first run **interval** seconds after the container is started, and then again **interval** seconds after each previous check completes. If a single run of the check takes longer than **timeout** seconds then the check is considered to have failed. It takes **retries** consecutive failures of the health check for the container to be considered `unhealthy`. There can only be one `HEALTHCHECK` instruction in a Dockerfile. If you list more than one then only the last `HEALTHCHECK` will take effect. The command after the `CMD` keyword can be either a shell command (e.g. `HEALTHCHECK CMD /bin/check-running`) or an _exec_ array (as with other Dockerfile commands; see e.g. `ENTRYPOINT` for details). The command's exit status indicates the health status of the container. The possible values are: - 0: success - the container is healthy and ready for use - 1: unhealthy - the container is not working correctly - 2: starting - the container is not ready for use yet, but is working correctly If the probe returns 2 ("starting") when the container has already moved out of the "starting" state then it is treated as "unhealthy" instead. For example, to check every five minutes or so that a web-server is able to serve the site's main page within three seconds: HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 To help debug failing probes, any output text (UTF-8 encoded) that the command writes on stdout or stderr will be stored in the health status and can be queried with `docker inspect`. Such output should be kept short (only the first 4096 bytes are stored currently). When the health status of a container changes, a `health_status` event is generated with the new status. The health status is also displayed in the `docker ps` output. Signed-off-by: Thomas Leonard <thomas.leonard@docker.com> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-04-18 05:48:13 -04:00
}
// GitHub #33021
rm-gocheck: check.C -> testing.T sed -E -i 's#\bcheck\.C\b#testing.T#g' \ -- "integration-cli/check_test.go" "integration-cli/daemon/daemon.go" "integration-cli/daemon/daemon_swarm.go" "integration-cli/daemon_swarm_hack_test.go" "integration-cli/docker_api_attach_test.go" "integration-cli/docker_api_build_test.go" "integration-cli/docker_api_build_windows_test.go" "integration-cli/docker_api_containers_test.go" "integration-cli/docker_api_containers_windows_test.go" "integration-cli/docker_api_exec_resize_test.go" "integration-cli/docker_api_exec_test.go" "integration-cli/docker_api_images_test.go" "integration-cli/docker_api_inspect_test.go" "integration-cli/docker_api_logs_test.go" "integration-cli/docker_api_network_test.go" "integration-cli/docker_api_stats_test.go" "integration-cli/docker_api_swarm_node_test.go" "integration-cli/docker_api_swarm_service_test.go" "integration-cli/docker_api_swarm_test.go" "integration-cli/docker_api_test.go" "integration-cli/docker_cli_attach_test.go" "integration-cli/docker_cli_attach_unix_test.go" "integration-cli/docker_cli_build_test.go" "integration-cli/docker_cli_build_unix_test.go" "integration-cli/docker_cli_by_digest_test.go" "integration-cli/docker_cli_commit_test.go" "integration-cli/docker_cli_cp_from_container_test.go" "integration-cli/docker_cli_cp_test.go" "integration-cli/docker_cli_cp_to_container_test.go" "integration-cli/docker_cli_cp_to_container_unix_test.go" "integration-cli/docker_cli_cp_utils_test.go" "integration-cli/docker_cli_create_test.go" "integration-cli/docker_cli_daemon_plugins_test.go" "integration-cli/docker_cli_daemon_test.go" "integration-cli/docker_cli_events_test.go" "integration-cli/docker_cli_events_unix_test.go" "integration-cli/docker_cli_exec_test.go" "integration-cli/docker_cli_exec_unix_test.go" "integration-cli/docker_cli_external_volume_driver_unix_test.go" "integration-cli/docker_cli_health_test.go" "integration-cli/docker_cli_history_test.go" "integration-cli/docker_cli_images_test.go" "integration-cli/docker_cli_import_test.go" "integration-cli/docker_cli_info_test.go" "integration-cli/docker_cli_info_unix_test.go" "integration-cli/docker_cli_inspect_test.go" "integration-cli/docker_cli_links_test.go" "integration-cli/docker_cli_login_test.go" "integration-cli/docker_cli_logout_test.go" "integration-cli/docker_cli_logs_test.go" "integration-cli/docker_cli_netmode_test.go" "integration-cli/docker_cli_network_unix_test.go" "integration-cli/docker_cli_plugins_logdriver_test.go" "integration-cli/docker_cli_plugins_test.go" "integration-cli/docker_cli_port_test.go" "integration-cli/docker_cli_proxy_test.go" "integration-cli/docker_cli_prune_unix_test.go" "integration-cli/docker_cli_ps_test.go" "integration-cli/docker_cli_pull_local_test.go" "integration-cli/docker_cli_pull_test.go" "integration-cli/docker_cli_push_test.go" "integration-cli/docker_cli_registry_user_agent_test.go" "integration-cli/docker_cli_restart_test.go" "integration-cli/docker_cli_rmi_test.go" "integration-cli/docker_cli_run_test.go" "integration-cli/docker_cli_run_unix_test.go" "integration-cli/docker_cli_save_load_test.go" "integration-cli/docker_cli_save_load_unix_test.go" "integration-cli/docker_cli_search_test.go" "integration-cli/docker_cli_service_create_test.go" "integration-cli/docker_cli_service_health_test.go" "integration-cli/docker_cli_service_logs_test.go" "integration-cli/docker_cli_service_scale_test.go" "integration-cli/docker_cli_sni_test.go" "integration-cli/docker_cli_start_test.go" "integration-cli/docker_cli_stats_test.go" "integration-cli/docker_cli_swarm_test.go" "integration-cli/docker_cli_swarm_unix_test.go" "integration-cli/docker_cli_top_test.go" "integration-cli/docker_cli_update_unix_test.go" "integration-cli/docker_cli_userns_test.go" "integration-cli/docker_cli_v2_only_test.go" "integration-cli/docker_cli_volume_test.go" "integration-cli/docker_deprecated_api_v124_test.go" "integration-cli/docker_deprecated_api_v124_unix_test.go" "integration-cli/docker_hub_pull_suite_test.go" "integration-cli/docker_utils_test.go" "integration-cli/events_utils_test.go" "integration-cli/fixtures_linux_daemon_test.go" "integration-cli/utils_test.go" "pkg/discovery/discovery_test.go" "pkg/discovery/file/file_test.go" "pkg/discovery/generator_test.go" "pkg/discovery/kv/kv_test.go" "pkg/discovery/memory/memory_test.go" "pkg/discovery/nodes/nodes_test.go" Signed-off-by: Tibor Vass <tibor@docker.com>
2019-09-09 17:05:55 -04:00
func (s *DockerSuite) TestUnsetEnvVarHealthCheck(c *testing.T) {
testRequires(c, DaemonIsLinux) // busybox doesn't work on Windows
imageName := "testhealth"
buildImageSuccessfully(c, imageName, build.WithDockerfile(`FROM busybox
HEALTHCHECK --interval=1s --timeout=5s --retries=5 CMD /bin/sh -c "sleep 1"
ENTRYPOINT /bin/sh -c "sleep 600"`))
name := "env_test_health"
// No health status before starting
dockerCmd(c, "run", "-d", "--name", name, "-e", "FOO", imageName)
defer func() {
dockerCmd(c, "rm", "-f", name)
dockerCmd(c, "rmi", imageName)
}()
// Start
dockerCmd(c, "start", name)
waitForHealthStatus(c, name, "starting", "healthy")
}