I'd like to set up a Percona XtraDB Cluster
using this Docker image. The documentation for the Docker image assumes the use of the etcd discovery service.
My question is this: Doesn't Docker ship with a built in service discovery (i.e. DNS server), makeing the use of etcd redundant? Or are there use cases where the build in service discovery is still needed?
How would one typically go about using the build in service discovery for muliti host setups?
From what I have read, Docker discovery service is only available on docker-swarm-based images/setups. This PXC Docker image is not swarm capable and thus uses an external discovery service. Running etcd is completely optional, as stated on the Docker image README. You can manually specify each other node when starting multiple nodes.
Related
I built two docker applications that communicate with each other using the docker network, but when I tried to run those applications using nomad. The problem within nomad is that the container name is not configurable and gives the container a random name. So I can't add those containers to the docker network and have them know each other with their specific names.
So how can I run two or more docker containers in the same docker network using nomad?
I'm aware of few approaches. First one works with nomad only, the others assume that consul is deployed as well.
Place both containers in the same task group. Nomad will locate them always on the same node and you can access address via Nomad env variables NOMAD_IP_<label>, NOMAD_PORT_<label> or NOMAD_ADDR_<label>.
Register the server application (docker container) in the consul service registry with nomad service stanza. You can then use nomad template stanza in "client" application to render config. Example/doc is here.
Setup consul connect (service mesh) in your deployment.
You could use consul DNS interface. Consul can work as a DNS server and every service is resolvable at <service_name>.service.<dc>.consul (doc). But you have to configure your servers to use consul DNS (doc).
Approach 1 is the easiest but has huge limitation (the same node). Approach 2 worked for me well for several years. Nomad is that intelligent that it will reload/restart your client IP should the server IP/port change.
Docker network is created in a docker swarm, which contains several nodes, with this command:
docker network create --attachable --driver overlay [network-name]
And containers are attached to the network with "docker service create" command.
There is extra container with the name "lb-[network-name]" appeared after in the network.
What is that container and how to configure docker network not to have that?
From docker swarm documentation (https://docs.docker.com/engine/swarm/key-concepts/):
Swarm mode has an internal DNS component that automatically assigns
each service in the swarm a DNS entry. The swarm manager uses internal
load balancing to distribute requests among services within the
cluster based upon the DNS name of the service.
It's a part of swarm architecture, you can't deactivate it.
Take a look also to this detailed answer regarding networking of docker swarm:
https://stackoverflow.com/a/44649746/3730077
I have setup a 3 node cluster (with no Internet access) with 1 manager and 2 worker-nodes using the standard swarm documentation.
How does the swarm manager in swarm mode know about the images present in worker nodes?
Lets say I have image A in worker-node-1 and image B in worker-node-2 and no images in the manager-node.
Now how do I start container for image A using the manager?
Will it start in manager or node-1?
When I query manager for the list of images will it give the whole list with A and B in it?
Does anyone know how this works?
I couldn’t get the details from the documentation.
Docker Swarm manager node may to be a worker one by the second role but not strictly necessary.
Image deployment policy is mapped via docker-compose.yml which has an information like target nodes, networks, hostnames, volumes, etc. in relation of particular service. So, it will start either in specified node or in emptiest default one.
Swarm manager communicates with the worker nodes via Docker networks:
When you initialize a swarm or join a Docker host to an existing swarm, two new networks are created on that Docker host:
an overlay network called ingress, which handles control and data
traffic related to swarm services. When you create a swarm service and
do not connect it to a user-defined overlay network, it connects to
the ingress network by default
a bridge network called
docker_gwbridge, which connects the individual Docker daemon to the
other daemons participating in the swarm.
Reference
During Swarm deployment, the images of it's services are being propagated to worker nodes according to their deployment policy.
The manager node will contain images once the node is the worker one too (correct me, if it won't).
The default configuration with swarm mode is to pull images from a registry server and use pinning to reference a unique hash for those images. This can be adjusted, but there is no internal mechanism to distribute images within a cluster.
For an offline environment, I'd recommend a stand alone registry server accessible to the cluster. You can even run it on the cluster. Push your image there, and point your server l services to the registry for their images to pull. See this doc for details on running a stand alone registry, or any of the many 3rd party options (e.g. Harbor): https://docs.docker.com/registry/
The other option is to disable the image pinning, and manually copy images to each of your swarm nodes. You need to do this in advance of deploying any service changes. You'll also lose the benefit of reused image layers when you manually copy them. Because of all this issues it creates, overhead to manage, and risk of mistakes, I'd recommend against this option.
Run the docker stack deploy command with --with-registry-auth that will give the Workers access to pull the needed image
By default Docker Swarm will pull the latest image from registry when deploying
i'm learning about docker swarm, and got confused about the swarm discovery option, i see that lots of tutorials on internet use this option to create containers with docker-machine, but when i enter the documentation on docker swarm doc it says:
You are viewing docs for legacy standalone Swarm. These topics describe standalone Docker Swarm. In Docker 1.12 and higher, Swarm mode is integrated with Docker Engine. Most users should use integrated Swarm mode.
So, what are the use cases for the discovery options? All the tutorials use the docker-machine to create a swarm, i always need it or can just install the docker on machines in my cluster, join them in swarm and use normal?
I saw some names like Docker Swarm and Docker Swarm Mode, are there any difference or just different ways to call the same feature?
Q. Docker Swarm discovery is still relevant?
A: No, if you use docker Swarm Mode and an overlay network (see below)
Q. Are there any difference between Docker Swarm and Docker Swarm Mode?
A: Yes, TL;DR Docker Swarm is deprecated and should not be used anymore, Docker Swarm Mode (we should just say Swarm Mode) is the recommended way of clustering containers and have reliability, load-balancing, scaling, and rolling service upgrades.
Docker Swarm (official doc) :
is the old fashioned way (<1.12) of clustering containers
uses a dedicated container for building a Docker Swarm cluster
needs a discovery service like Consul to reference containers in cluster
Swarm Mode (official doc):
is the new and recommended way (>=1.12) of clustering containers on host nodes (called managers / workers)
is built-in in Docker engine, you don't need an additional container
has a built-in discovery service if you use an overlay network (DNS resolution is done within this network), you don't need an additional container
You can have a look to this SO thread on same topic.
Q. Do i always need docker-machine to create a swarm?
A: No, docker-machine is a helper to create virtual hosts in the cloud like amazon ec2, azure, digitalocean, google, openstack..., or your own network with virtual box.
To create a Swarm Mode, you need :
a multiple hosts cluster with docker engine installed on each host (called node) (that is what docker-machine facilitates)
run docker swarm init to switch to Swarm Mode on your first manager node
run docker swarm join on worker nodes to add them in the cluster
There are some subtle adjustments to Swarm mode to increase high availability (recommended number of managers in the swarm, node placement in multiple availability zones in the cloud)
Hope this helps!
I run a web container in server A, and a DB container in server B.
How can I connect these two containers?
I only know how to connect two containers which run in same host.
You need a:
service discovery which will record your containers hosts (like Consul, a KV -- Key/Value store)
A good way to think of Consul is broken into 3 layers.
The middle layer is the actual config store, which is not that different from etcd or Zookeeper.
The layers above and below are pretty unique to Consul.
The killer feature of Consul is its service catalog. Instead of using the key-value store to arbitrarily model your service directory as you would with etcd or Zookeeper, Consul exposes a specific API for managing services.
a registrator (you can use swarm even though it is a bit overkill, or registrator)
Registrator is a single, host-level service you run as a Docker container.
It watches for new containers, inspects them for service information, and registers them with a service registry. It also deregisters them when the container dies.
It has a pluggable registry system, meaning it can work with a number of service discovery systems.