[{"_1":2,"_148":-5,"_149":-5},"loaderData",{"_3":4,"_13":14,"_20":21,"_127":128},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","routes/_layout.r.$namespace.$reponame",{"_22":23,"_24":-5,"_25":11,"_26":11,"_27":28,"_29":30,"_31":-5,"_32":11,"_33":34,"_83":-5,"_84":85,"_120":-5,"_121":11,"_122":17,"_123":11,"_124":-5,"_125":126},"canonicalUrl","https://hub.docker.com/r/digiwhite/consul/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","digiwhite","reponame","consul","cloudBuildSource","isAutobuildsAvailable","repo",{"_35":36,"_37":38,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":50,"_52":30,"_27":28,"_53":54,"_55":-5,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":69,"_74":17,"_75":76,"_80":28,"_81":82},"categories",[],"content_types",[39],"image","date_registered","2016-01-07T12:35:35.163146Z","description","Consul agent v0.6.0 for docker","is_private","last_updated","2016-05-31T14:31:05.373272Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[51],"application/vnd.docker.distribution.manifest.v1+prettyjws","name","pull_count",1052,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","## Consul agent (0.6.4) Docker image\n\nBased on: progrium/consul (https://hub.docker.com/r/progrium/consul/)\n\nThis docker image is based on the docker image coming from progrium/consul. Consul 0.6.4 is used based on Alpine 3.3.\n\nThe following documentation us part of the progrium/consul docker image taken from README.md.\n\nGetting the container\n```shell\n$ docker pull digiwhite/consul\n```\n\n# Just trying out Consul\n```shell\n$ docker run -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node1 digiwhite/consul -server -bootstrap\n```\n\nOur recommended interface is HTTP using curl:\n```shell\n$ curl localhost:8500/v1/catalog/nodes\n```\n\nWe can also use dig to interact with the DNS interface:\n```shell\n$ dig @0.0.0.0 -p 8600 node1.node.consul\n```\n\nHowever, if you install Consul on your host, you can use the CLI to interact with the containerized Consul Agent:\n```shell\n$ consul members\n```\n\n# Testing a Consul cluster on a single host\n\nif you want to start a Consul cluster on a single host to experiment with clustering dynamics (replication, leader election), \nhere is the recommended way to start a 3 node cluster.\n\nHere we start the first node not with -bootstrap, but with -bootstrap-expect 3, \nwhich will wait until there are 3 peers connected before self-bootstrapping and becoming a working cluster.\n\n```shell\n$ docker run -d --name node1 -h node1 digiwhite/consul -server -bootstrap-expect 3\n```\n\nWe can get the container's internal IP by inspecting the container. We'll put it in the env var JOIN_IP.\n```shell\n$ JOIN_IP=\"$(docker inspect -f '{{.NetworkSettings.IPAddress}}' node1)\"\n```\n\nThen we'll start node2 and tell it to join node1 using $JOIN_IP:\n```shell\n$ docker run -d --name node2 -h node2 digiwhite/consul -server -join $JOIN_IP\n```\n\nNow we can start node3 the same way:\n```shell\n$ docker run -d --name node3 -h node3 digiwhite/consul -server -join $JOIN_IP\n```\n\nWe now have a real three node cluster running on a single host. Notice we've also named the containers after their internal hostnames / node names.\n\nWe haven't published any ports to access the cluster, but we can use that as an excuse to run a fourth agent node in \"client\" mode (dropping the -server). \nThis means it doesn't participate in the consensus quorum, but can still be used to interact with the cluster. It also means it doesn't need disk persistence.\n```shell\n$ docker run -d -p 8400:8400 -p 8500:8500 -p 8600:53/udp --name node4 -h node4 digiwhite/consul -join $JOIN_IP\n```\n\nNow we can interact with the cluster on those published ports and, if you want, play with killing, adding, and restarting nodes to see how the cluster handles it.\n\n# Running a real Consul cluster in a production environment\n\nSetting up a real cluster on separate hosts is very similar to our single host cluster setup process, but with a few differences:\n\nWe assume there is a private network between hosts. Each host should have an IP on this private network\nWe're going to pass this private IP to Consul via the -advertise flag\nWe're going to publish all ports, including internal Consul ports (8300, 8301, 8302), on this IP\nWe set up a volume at /data for persistence. As an example, we'll bind mount /mnt from the host\n\nAssuming we're on a host with a private IP of 10.0.1.1 and the IP of docker bridge docker0 is 172.17.42.1 we can start the first host agent:\n```shell\n$ docker run -d -h node1 -v /mnt:/data \\\n -p 10.0.1.1:8300:8300 \\\n -p 10.0.1.1:8301:8301 \\\n -p 10.0.1.1:8301:8301/udp \\\n -p 10.0.1.1:8302:8302 \\\n -p 10.0.1.1:8302:8302/udp \\\n -p 10.0.1.1:8400:8400 \\\n -p 10.0.1.1:8500:8500 \\\n -p 172.17.42.1:53:53/udp \\\n digiwhite/consul -server -advertise 10.0.1.1 -bootstrap-expect 3\n```\n\nOn the second host, we'd run the same thing, but passing a -join to the first node's IP. Let's say the private IP for this host is 10.0.1.2:\n```shell\n$ docker run -d -h node2 -v /mnt:/data \\\n -p 10.0.1.2:8300:8300 \\\n -p 10.0.1.2:8301:8301 \\\n -p 10.0.1.2:8301:8301/udp \\\n -p 10.0.1.2:8302:8302 \\\n -p 10.0.1.2:8302:8302/udp \\\n -p 10.0.1.2:8400:8400 \\\n -p 10.0.1.2:8500:8500 \\\n -p 172.17.42.1:53:53/udp \\\n digiwhite/consul -server -advertise 10.0.1.2 -join 10.0.1.1\n```\n\nAnd the third host with an IP of 10.0.1.3:\n```shell\n$ docker run -d -h node3 -v /mnt:/data \\\n -p 10.0.1.3:8300:8300 \\\n -p 10.0.1.3:8301:8301 \\\n -p 10.0.1.3:8301:8301/udp \\\n -p 10.0.1.3:8302:8302 \\\n -p 10.0.1.3:8302:8302/udp \\\n -p 10.0.1.3:8400:8400 \\\n -p 10.0.1.3:8500:8500 \\\n -p 172.17.42.1:53:53/udp \\\n digiwhite/consul -server -advertise 10.0.1.3 -join 10.0.1.1\n```\n\nThat's it! Once this last node connects, it will bootstrap into a cluster. You now have a working cluster running in production on a private network.\n\n# Runner command\n\nSince the docker run command to start in production is so long, a command is available to generate this for you. \nRunning with cmd:run [::[::client]] [docker-run-args...] will output an opinionated, \nbut customizable docker run command you can run in a subshell. For example:\n```shell\n$ docker run --rm digiwhite/consul cmd:run 10.0.1.1 -d\n>>> outputs\neval docker run --name consul -h $HOSTNAME \\\n -p 10.0.1.1:8300:8300 \\\n -p 10.0.1.1:8301:8301 \\\n -p 10.0.1.1:8301:8301/udp \\\n -p 10.0.1.1:8302:8302 \\\n -p 10.0.1.1:8302:8302/udp \\\n -p 10.0.1.1:8400:8400 \\\n -p 10.0.1.1:8500:8500 \\\n -p 172.17.42.1:53:53/udp \\\n -d \\\n digiwhite/consul -server -advertise 10.0.1.1 -bootstrap-expect 3\n```\n\nBy design, it will set the hostname of the container to your host hostname, it will name the container consul (though this can be overridden), \nit will bind port 53 to the Docker bridge, and the rest of the ports on the advertise IP. If no join IP is provided, \nit runs in -bootstrap-expect mode with a default of 3 expected peers. Here is another example, specifying a join IP and setting more docker run arguments:\n```shell\n$ docker run --rm digiwhite/consul cmd:run 10.0.1.1::10.0.1.2 -d -v /mnt:/data\n>>> outputs\neval docker run --name consul -h $HOSTNAME \\\n -p 10.0.1.1:8300:8300 \\\n -p 10.0.1.1:8301:8301 \\\n -p 10.0.1.1:8301:8301/udp \\\n -p 10.0.1.1:8302:8302 \\\n -p 10.0.1.1:8302:8302/udp \\\n -p 10.0.1.1:8400:8400 \\\n -p 10.0.1.1:8500:8500 \\\n -p 172.17.42.1:53:53/udp \\\n -d -v /mnt:/data \\\n digiwhite/consul -server -advertise 10.0.1.1 -join 10.0.1.2\n```\n\nYou may notice it lets you only run with bootstrap-expect or join, not both. \nUsing cmd:run assumes you will be bootstrapping with the first node and expecting 3 nodes. \nYou can change the expected peers before bootstrap by setting the EXPECT environment variable.\n\nTo use this convenience, you simply wrap the cmd:run output in a subshell. Run this to see it work:\n```shell\n$ $(docker run --rm digiwhite/consul cmd:run 127.0.0.1 -it)\n```\n\n# Client flags\n\nClient nodes allow you to keep growing your cluster without impacting the performance of the underlying gossip protocol \n(they proxy requests to one of the server nodes and so are stateless).\n\nTo boot a client node using the runner command, append the string ::client onto the :: argument. For example:\n```shell\n$ docker run --rm digiwhite/consul cmd:run 10.0.1.4::10.0.1.2::client -d\n```\n\nWould create the same output as above but without the -server consul argument.\n\n# Health checking with Docker\n\nConsul lets you specify a shell script to run for health checks, similar to Nagios. As a container, those scripts run inside this container environment which is a minimal Busybox environment with bash and curl. For some, this is fairly limiting, so I've added some built-in convenience scripts to properly do health checking in a Docker system.\n\nThese all require you to mount the host's Docker socket to /var/run/docker.sock when you run the Consul container.\n\n# Using check-http\n\n```shell\ncheck-http [curl-args...]\n```\n\nThis utility performs curl based HTTP health checking given a container ID or name, an internal port (what the service is actually listening on inside the container) and a path. You can optionally provide extra arguments to curl.\n\nThe HTTP request is done in a separate ephemeral container that is attached to the target container's network namespace. The utility automatically determines the internal Docker IP to run the request against. A successful request will output the response headers into Consul. An unsuccessful request will output the reason the request failed and set the check to critical. By default, curl runs with --retry 2 to cover local transient errors.\n\n# Using check-cmd\n```shell\ncheck-cmd \n```\n\nThis utility performs the specified command in a separate ephemeral container based on the target container's image that is attached to that container's network namespace. Very often, this is expected to be a health check script, but can be anything that can be run as a command on this container image. For convenience, an environment variable SERVICE_ADDR is set with the internal Docker IP and port specified here.\n\n# Using docker\nThe above health check utilities require the Docker binary, so it's already built-in to the container. If neither of the above fit your needs, and the container environment is too limiting, you can perform Docker operations directly to perform any containerized health check.\n\n# DNS\n\nThis container was designed assuming you'll be using it for DNS on your other containers. So it listens on port 53 inside the container to be more compatible and accessible via linking. It also has DNS recursive queries enabled, using the Google 8.8.8.8 nameserver.\n\nWhen running with cmd:run, it publishes the DNS port on the Docker bridge. You can use this with the --dns flag in docker run, or better yet, use it with the Docker daemon options. Here is a command you can run on Ubuntu systems that will tell Docker to use the bridge IP for DNS, otherwise use Google DNS, and use service.consul as the search domain.\n```shell\n$ echo \"DOCKER_OPTS='--dns 172.17.42.1 --dns 8.8.8.8 --dns-search service.consul'\" >> /etc/default/docker\n```\n\nIf you're using boot2docker on OS/X, rather than an Ubuntu host, it has a Tiny Core Linux VM running the docker containers. Use this command to set the extra Docker daemon options (as of boot2docker v1.3.1), which also uses the first DNS name server that your OS/X machine uses for name resolution outside of the boot2docker world.\n```shell\n$ boot2docker ssh sudo \"ash -c \\\"echo EXTRA_ARGS=\\'--dns 172.17.42.1 --dns $(scutil --dns | awk -F ': ' '/nameserver/{print $2}' | head -1) --dns-search service.consul\\' > /var/lib/boot2docker/profile\\\"\"\n```\n\nWith those extra options in place, within a Docker container, you have the appropriate entries automatically set in the /etc/resolv.conf file. To test it out, start a Docker container that has the dig utility installed (this example uses aanand/docker-dnsutils which is the Ubuntu image with dnsutils installed).\n```shell\n$ docker run --rm aanand/docker-dnsutils dig -t SRV consul +search\n```\n\n## Runtime Configuration\n\nAlthough you can extend this image to add configuration files to define services and checks, this container was designed for environments where services and checks can be configured at runtime via the HTTP API.\n\nIt's recommended you keep your check logic simple, such as using inline curl or ping commands. Otherwise, keep in mind the default shell is Bash, but you're running in Busybox.\n\nIf you absolutely need to customize startup configuration, you can extend this image by making a new Dockerfile based on this one and having a config directory containing config JSON files. They will be added to the image you build via ONBUILD hooks. You can also add packages with opkg. See docs on the Busybox image for more info.\n\nIssue with quickly restarting a node using the same IP\nWhen testing a cluster scenario, you may kill a container and restart it again on the same host and see that it has trouble re-joining the cluster.\n\nThere is an issue when you restart a node as a new container with the same published ports that will cause heartbeats to fail and the node will flap. This is an ARP table caching problem. If you wait about 3 minutes before starting again, it should work fine. You can also manually reset the cache.\n\nLicense\nBSD\n","has_starred","hub_user","immutable_tags_settings",{"_70":11,"_71":72},"enabled","rules",[73],".*","is_automated","permissions",{"_77":17,"_78":11,"_79":11},"read","write","admin","user","storage_size",110478829,"orgData","recentTags",[86],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":95,"_45":109,"_110":89,"_111":28,"_112":51,"_52":113,"_114":115,"_116":-5,"_117":109,"_118":107,"_119":17},"content_type","creator",192371,"full_size",26288526,"id",1681907,"images",[96],{"_97":98,"_99":100,"_101":-5,"_102":-5,"_103":100,"_104":100,"_105":-5,"_106":57,"_58":107,"_108":-5},"architecture","amd64","features","","last_pulled","last_pushed","os","os_features","os_version","size","inactive","variant","2016-05-31T14:31:03.6028Z","last_updater","last_updater_username","media_type","latest","repository",471832,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_33":129,"_136":137,"_125":146,"_147":11},{"_35":130,"_37":131,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":132,"_52":30,"_27":28,"_53":54,"_55":-5,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":133,"_74":17,"_75":135,"_80":28,"_81":82},[],[39],[51],{"_70":11,"_71":134},[73],{"_77":17,"_78":11,"_79":11},"tags",{"_138":59,"_139":-5,"_140":-5,"_141":142},"count","next","previous","results",[143],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":144,"_45":109,"_110":89,"_111":28,"_112":51,"_52":113,"_114":115,"_116":-5,"_117":109,"_118":107,"_119":17},[145],{"_97":98,"_99":100,"_101":-5,"_102":-5,"_103":100,"_104":100,"_105":-5,"_106":57,"_58":107,"_108":-5},[],"canDeleteTags","actionData","errors"]

digiwhite/consul

Tags for digiwhite/consul