10

Update: Docker just released support for Kubernetes as scheduler, which changes the situation and makes Kubernetes just an alternative scheduler to Docker Swarm. TL;DR: DON'T DO IT. Engineers always try to create these dog-pigs. Every unnecessary technology you bring will bring another whole set of faults. If you can pick one, then pick one and be happy ...


6

There are various timeouts within swarm mode that do not handle high latency well and may start to assume nodes within the cluster are down, lose quorum, or have networking issues. For HA, the standard advice is to have multi-AZ but not multi-region for a single cluster. For use cases that need multi-region, you would deploy multiple swarm clusters, one per ...


5

I just figure it out. The problem is not with the service or the swarm, it's with the network. When I use driver: overlay the default subnet is 10.0.0.0/24 which result in 254 address. So I change the mask in the subnet, to 22, which result in 1022 address, I added: ipam: config: -subnet: 10.0.0.0/22 And now the network section in the docker-compose ...


4

On June 30, 2016 this issue was created on GitHub to request the implementation of static IP on docker-swarm services. Since then multiple replies with thumbs up and down were added. At the time of writing on December 20, 2019 this issue is open and the feature has not been implemented. Discussion After reading all comments I strongly doubt whether ...


3

You just have to use the hostname on your docker compose file like this: hostname: whatever-{{.Node.Hostname}} Note that you have to prepend something to the hostname to avoid hostnames duplicates.


3

If you configured and joined correctly you should see two hosts: one for Linux and one for Windows. Windows hosts cannot natively run inside the Linux hosts and vice-versa. This means you have to have different kernels for Linux hosts and Windows hosts in the same swarm. This way they can communicate across the same Docker network. Refer to Docker Engine ...


3

Secrets support for mongo is built in. You can see in that image's entrypoint script that if you add _FILE to end of username/password values it will pull from those secret files. As for .js files, if you're storing decrypted passwords in those files, you'd need to make a custom entrypoint script or something that will take envvars you're passing in for ...


3

It depends on how much time you can invest into configuration and your configuration. I have built my own cluster on AWS using Nomad and Consul where Fabio was used as Application Load Balancing layer (AWS ALB was lacking for my purposes). Alternatively if you use k8s and do not need additional ALB you can use DNS RR (multiple A or AAAA records for your ...


3

You missed a point that there's still a need in balancing traffic before nodes in Docker cluster, and ELB is great for it (managed cluster, healthchecks, you don't pay for number of ELB instances per VPC, you can spawn spare nodes and register them in ELB automagically with Cloudwatch), great discussion on ServerFault. Basically, external balancer will split ...


3

Assuming that "publicly available" is on the public internet it will be difficult. DNS isn't really that reactive to changes and is challenging to run in a secure fashion on the public internet. It also depends on what protocol you are running, because of an oddity around SRV records where pre-existing protocols were excluded from supporting it in the RFC. ...


3

So it turned out that some of the workers didn't have the correct credentials to the docker registry. After I applied the correct ones, the command worked normally. That's weird, since I could do it locally... Anyway, case solved.


3

Why it is mandatory to switch to swarm mode to run docker stack? A stack and service are swarm mode objects by their very definition. The stack is a collection of services, and each service is a definition of a target state. Swarm mode takes those target states and manages containers to achieve that target state. And most important, what are the ...


2

Once the secret reaches a manager node, it gets saved to the internal Raft store, which uses NACL’s Salsa20Poly1305 with a 256-bit key to ensure no data is ever written to disk unencrypted. Writing to the internal store gives secrets the same high availability guarantees that the the rest of the swarm management data gets. https://blog.docker.com/...


2

Yes, when using Docker Swarm you'll still want to use Gunicorn in your Docker containers. Gunicorn is necessary to facilitate the communication between the server and your web application. In the case of a Dockerized Flask application this is still the case as Gunicorn handles the communication between the Flask application and the Docker container. Adding ...


2

By Docker Swarm design it is dencentralized, so you can promote any node to a manager. Normally, 3 managers are enough, for landscapes with thousands of nodes 5 are enough. https://docs.docker.com/engine/swarm/admin_guide/


2

Have the Swarm Manager place the worker join token in a Key/Value store. We use AWS Parameter Store but I believe Consul would be another option (I don't use it). Each node can then retrieve the token while it is bootstrapping.


2

Here's a solution I've used in cases like this - I utilize Ansible to manage Docker containers, and Ansible Vault to store secrets for those containers. Ansible Playbook to run MongoDB container Your playbook.yml may look something like this: - name: run mongodb docker container docker_container: name: mongo-container image: mongo ports: ...


2

Why do you want to create a new Manager node, risking damaging your raft consensus and cie? I find it way easier to simply expose the docker socket locally, as if you were working inside the node, but with your Windows environment. To do so, simply open a ssh tunnel that exposes /var/run/docker.sock: ssh -M -S ~/.docker.sock \ -fnNT -4 -L localhost:...


2

The swarm protocol is not http, so you will not be able to pass it through a proxy. Swarm nodes need direct communication between each node on port 2377/tcp (or your configured swarm port), 7946/both, and 4789/udp. If you configure an overlay network with the secure option for IPSec, then you'll also need protocol 50 open between the nodes.


2

At present the answer is "no", swarm mode does not support affinity or anti-affinity between a service and other containers/services running on a node. However, depending on your goal there are other options. One option is to reserve resources like CPU and memory for your container. This will ensure two resource intensive applications do not schedule ...


2

Try do pull your image manually first. docker pull ${DOCKER_REGISTRY}imageNameX:${VERSION} And then re-run your compose-file It may be a bug using a private registry, or something simple as you don't have enough disk space to pull the image.


2

You need the --with-registry-auth flag, e.g.: docker stack deploy -c myapp.yml --with-registry-auth myapp From the docker stack deploy --help output: --with-registry-auth Send registry authentication details to Swarm agents


2

AFAIK, Swarm does zero real-time resource monitoring. It's only as smart as reservations and limits that you set on the Service beforehand. First, it takes into account if the tasks of that Service are spread out. It will try not to schedule multiple tasks on the same node, and may ignore total task count per node to do so. Then, it counts the number of ...


1

This might not be the answer to your specific cross data-center-ip setup. I occasionally run into one or more swarm-nodes being status: Down and Availability: Active. Having the Status.Message: "heartbeat failure". This can happen after a reboot. What helped was to stop the docker daemon, remove /var/lib/docker/swarm/worker/tasks.db and start the docker ...


1

I suggest making a cronjob container that does the SQL dump and elastic index using docker exec commands toward the corresponding containers.


1

It is safe. As soon as docker returns it is safe to logout/leave the shell. The issue was that Docker 18.06.0-ce broke docker stack deploy. Reverting to 18.03.1 (specifically 18.03.1~ce-0~ubuntu) made it work.


1

Docker containers are isolated applications. When the application that it launches exits, the container also exits. So when your command is ls, that will run and then exit almost immediately, stopping the container. Swarm mode has the goal to maintain a target state for your containers. By default, it will keep a single replica (instance of a container) of ...


1

One could also use a docker image from an official docker repository like https://hub.docker.com/r/library/redis/ docker run --name some-redis -d redis:alpine


1

It seems like the AutoScaling Group from AWS are not that synchronized with the Docker Swarm configuration and the default timeouts in the AutoScaling are not accepted in the Docker Swarm managers. Actually the Health Check is not configured good by default in the EE CloudFormation template, even if the managers are running and stable the Health Check fails ...


1

I think Windows Server 2016 needs at least 17.09 Docker EE to support overlay networking and VIP's. I recommend updating it. I was wrong, the latest version is indeed 17.06.2-ee-6 and should support overlay and VIP. Second, ping isn't a good test, as it may not be available on the VIP or container IP depending on the setup (Docker has changed over time if ...


Only top voted, non community-wiki answers of a minimum length are eligible