问题标签 [docker-swarm]

I have followed through the example at getting started overlay and i have a simple query. Is it possible to use multi-host networking feature using overlay without creating a swarm cluster? I don't want to use third party plugins like weave etc. I want to use docker native networking support for this.

I have 3.16+ kernel running RHEL and docker 1.9.

我将三个节点添加到具有静态文件模式的 swarm 集群中。我想从集群中删除host1 。但我没有找到docker swarm remove命令：

如何从 swarm 中删除节点？

I have been playing with docker-compose and have cobbled together a project from the docker hub website.

One thing that eludes me is how I can scale individual services up (by adding more instances) AND have existing instances somehow made aware of those new instances.

For example, the canonical docker-compose example comprises a cluster of:

• redis node
• python (flask) node
• haproxy load balancer

I create the cluster and everything works fine, however I attempt to add another node to the cluster:

That worked... But lets see what the haproxy node sees of the cluster (docker-machine modifies the '/etc/hosts' file)

If I were to restart the entire cluster using docker-compose that node should have it's /etc/hosts populated but it now seems to have broken even further:

So in conclusion is there a smarter way to do this (resolution and discovery)? Is there another smarter way rather than just updating the hosts files ? What's the best practice here?

我正在测试使用多播进行发现的应用程序。我创建了一个 Swarm 集群，network create -d overlay swarm-net因此容器在多个 Swarm 代理主机之间共享同一个 LAN。

发现似乎不起作用，所以我安装了tshark. tshark显示tshark正在运行的 IP 地址节点和正在发送的数据包的多播地址，但tshark 不显示任何传入的多播数据包。

请注意，由于我不知道更好的方法，容器运行时--privileged启用tshark。另请注意，容器可以相互通信。

多播是否因为 Docker iptable 而被阻止？如何在覆盖网络中启用多播？

我有一个docker-compose运行静态 html 的工作示例nginx。

目录树：

docker-compose.yml：_

该nginx目录具有Dockerfile：

一切正常。

问题是我按照 Docker 文档构建了一个Docker-Swarm基础设施： 、和.docker-machineLocalswarm-mastertwo nodes

一切似乎也都很好。

但是nginx正在返回一个Forbidden

我进入virtualbox并进入container：

目录中没有任何内容nginx/html：

是否有必要在compose/swarm中做一些不同的事情volumes？难道我做错了什么？

在我的微服务系统中，我计划使用 docker swarm 和 Consul。为了确保 Consul 的高可用性，我将构建一个由 3 个服务器代理组成的集群（以及每个节点的客户端代理），但这并不能让我免于本地 consul 代理故障。

我错过了什么吗？如果没有，我如何配置 swarm 以了解超过 1 个领事代理？

通常，应用程序开发人员（以 J2EE 为例）在设计应用程序时不会优先考虑与基础设施相关的问题。很难与传统的非可编程基础架构进行交互。一种传统的方法是构建一个 .war 文件，然后该文件可以在 JBoss 等应用服务器中运行。Spring等传统框架（除了新版本的Spring Cloud）都以此为前提。现在，如果有一个容错、弹性的部署运行时可用，例如 Kubernetes 提供的，那么似乎以同样的方式编写业务应用程序会忽略运行时提供的调度等功能。一个具体的问题：应用程序通常从运行时（即 Kubernetes、Mesos 等）API 中交谈（并从中受益）吗？如果是这样，您能否举一个很好的例子。

我已经docker swarm设置了正在运行的节点node-1, node-2 and node-3。由于某种原因，我的一个节点每天都会失败，基本上它们会退出。我跑了docker logs <container id of swarm>，但日志不包含任何与节点故障相关的信息。

那么，是否有任何日志文件可以看到与此故障相关的日志？或者这是由于一些较少的内存分配问题？

任何人都可以建议我如何挖掘这个问题并找到合适的解决方案。每天我必须从群节点开始。

我为 kibana 添加了配置文件“-./kibana/config/kibana.yml:/opt/kibana/config/kibana.yml”，它在我的本地测试机（没有 swarm 集群）中运行良好。但是在 swarm 上出现“错误：compose.cli.main.main：500 内部服务器错误：无法启动容器 3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530：[9] 系统错误：不是目录”错误。

我的本地存储驱动程序是 AUFS，但在集群中，每个节点的驱动程序是 devicemapper。我是否需要使用 AUFS 来解决这个问题的原因。或者我应该使用一些工具，如植绒器。

我为详细转储添加了我的 docker-compose 配置、群信息和错误。 ERROR: compose.cli.main.main: 500 Internal Server Error: Cannot start container 3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530: [9] System error: not a directory

version: '2' services: elasticsearch: build: elasticsearch/ command: elasticsearch -Des.network.host=0.0.0.0 volumes: - /usr/share/elasticsearch/data:/usr/share/elasticsearch/data logstash: build: logstash/ command: logstash -f /etc/logstash/conf.d/logstash.conf extra_hosts: - ${MONGO} volumes: - ./logstash/config:/etc/logstash/conf.d kibana: build: kibana/ volumes: - ./kibana/config/kibana.yml:/opt/kibana/config/kibana.yml nginx: build: nginx/ depends_on: - elasticsearch - kibana extra_hosts: - "es.imoney.my:127.0.0.1" - "reports.imoney.my:127.0.0.1" ports: - "8080:80" networks: default: driver: overlay volumes: {}

Containers: 6 Running: 3 Paused: 0 Stopped: 3 Images: 17 Role: primary Strategy: spread Filters: health, port, dependency, affinity, constraint Nodes: 2 report-node-1: 10.130.3.39:2375 └ Status: Healthy └ Containers: 3 └ Reserved CPUs: 0 / 8 └ Reserved Memory: 0 B / 16.45 GiB └ Labels: executiondriver=native-0.2, kernelversion=4.4.1-1.el7.elrepo.x86_64, operatingsystem=CentOS Linux 7 (Core), storagedriver=devicemapper └ Error: (none) └ UpdatedAt: 2016-02-12T04:26:24Z report-node-2: 10.130.0.114:2375 └ Status: Healthy └ Containers: 3 └ Reserved CPUs: 0 / 8 └ Reserved Memory: 0 B / 16.45 GiB └ Labels: executiondriver=native-0.2, kernelversion=4.4.1-1.el7.elrepo.x86_64, operatingsystem=CentOS Linux 7 (Core), storagedriver=devicemapper └ Error: (none) └ UpdatedAt: 2016-02-12T04:26:20Z Plugins: Volume: Network: Kernel Version: 4.4.1-1.el7.elrepo.x86_64 Operating System: linux Architecture: amd64 CPUs: 16 Total Memory: 32.91 GiB Name: 455a1ddf13bf

compose.service.build_container_labels: Added config hash: 4360ff02d2c79d27ddef844b2823c0f563bfa8ac13c127b2186fbbb5f7b1db7e compose.cli.verbose_proxy.proxy_callable: docker create_host_config <- (memswap_limit=None, links=[], devices=None, pid_mode=None, log_config={'Type': u'', 'Config': {}}, cpu_quota=None, read_only=None, dns=None, volumes_from=[], port_bindings={}, security_opt=None, extra_hosts=None, cgroup_parent=None, network_mode=u'dockerkibana_default', cap_add=None, restart_policy=None, dns_search=None, privileged=False, binds=[u'/home/ariful/docker-kibana/kibana/config/kibana.yml:/opt/kibana/config/kibana.yml:rw'], ipc_mode=None, mem_limit=None, cap_drop=None, ulimits=None) compose.cli.verbose_proxy.proxy_callable: docker create_host_config -> {'Binds': [u'/home/ariful/docker-kibana/kibana/config/kibana.yml:/opt/kibana/config/kibana.yml:rw'], 'Links': [], 'LogConfig': {'Config': {}, 'Type': u''}, 'NetworkMode': u'dockerkibana_default', 'PortBindings': {}, 'VolumesFrom': []} compose.cli.verbose_proxy.proxy_callable: docker create_container <- (name=u'dockerkibana_kibana_1', image=u'dockerkibana_kibana', labels={u'com.docker.compose.service': u'kibana', u'com.docker.compose.project': u'dockerkibana', u'com.docker.compose.config-hash': '4360ff02d2c79d27ddef844b2823c0f563bfa8ac13c127b2186fbbb5f7b1db7e', u'com.docker.compose.version': u'1.6.0', u'com.docker.compose.oneoff': u'False', u'com.docker.compose.container-number': '1'}, host_config={'NetworkMode': u'dockerkibana_default', 'Links': [], 'PortBindings': {}, 'Binds': [u'/home/ariful/docker-kibana/kibana/config/kibana.yml:/opt/kibana/config/kibana.yml:rw'], 'LogConfig': {'Type': u'', 'Config': {}}, 'VolumesFrom': []}, environment={u'affinity:container': u'=0bf65d0d5bcebf1ad106556b46c32b2d4c0dad49f91b4a41fde9d8563423ef4c'}, volumes={u'/opt/kibana/config/kibana.yml': {}}, detach=True) compose.cli.verbose_proxy.proxy_callable: docker create_container -> {u'Id': u'3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530'} compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- (u'3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530') compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> {u'AppArmorProfile': u'', u'Args': [u'/tmp/entrypoint.sh'], u'Config': {u'AttachStderr': False, u'AttachStdin': False, u'AttachStdout': False, u'Cmd': [u'/tmp/entrypoint.sh'], u'Domainname': u'', u'Entrypoint': [u'/docker-entrypoint.sh'], u'Env': [u'PATH=/opt/kibana/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', u'TINI_VERSION=v0.9.0', ... compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- (u'3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530') compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> {u'AppArmorProfile': u'', u'Args': [u'/tmp/entrypoint.sh'], u'Config': {u'AttachStderr': False, u'AttachStdin': False, u'AttachStdout': False, u'Cmd': [u'/tmp/entrypoint.sh'], u'Domainname': u'', u'Entrypoint': [u'/docker-entrypoint.sh'], u'Env': [u'PATH=/opt/kibana/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', u'TINI_VERSION=v0.9.0', ... compose.cli.verbose_proxy.proxy_callable: docker attach <- (u'3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530', stderr=True, stream=True, stdout=True) compose.cli.verbose_proxy.proxy_callable: docker attach -> <generator object _multiplexed_response_stream_helper at 0x7f92b781b4b0> compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- (u'3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530', u'dockerkibana_default') compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> None compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- (u'3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530', u'dockerkibana_default', links=[], aliases=['kibana', u'3bf3e9b086']) compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> None compose.cli.verbose_proxy.proxy_callable: docker start <- (u'3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530') ERROR: compose.cli.main.main: 500 Internal Server Error: Cannot start container 3bf3e9b086b80b47e9cc055581ae005d41133187e4c6820cf34ba9ed580d4530: [9] System error: not a directory

我正在尝试在 3 台专用 pc 上设置一个 HA docker 集群。我已成功遵循 docs.docker.com/engine/installation/linux/ubuntulinux 上的说明，现在我正在尝试遵循https://docs.docker.com/swarm/install-manual上的说明。由于我没有使用任何虚拟化，我从“设置领事发现后端”开始。PC（运行 ubuntu trusty 14.04 服务器版）都在 LAN 192.168.2.0/24 中。ubuntu001 有 .104，ubuntu002 有 .106，而 ubuntu003 有 .105

我按照说明做了以下操作：

但是当尝试下一步时，swarm manager 并没有像它说的那样显示为“Primary”，并且没有列出任何主节点：

并且： arnolde@ubuntu001:~$ docker -H :4000 run hello-world docker: 来自守护进程的错误响应：没有选定的主集群管理器。

我搜索并发现https://github.com/docker/swarm/issues/1491建议使用 dockerswarm/swarm:master 代替，我这样做了，但它没有帮助：

我没有找到关于 swarm+consul+primary 的任何其他输入，所以我在这里......有什么建议吗？不幸的是，我不确定如何进行故障排除，因为我什至不知道在哪里寻找日志记录/调试信息，即经理是否成功连接到领事等......