2 votes

La communication avec les conteneurs n'est pas toujours possible

J'ai un couple de services qui s'exécutent dans un essaim de dockers sur un seul hôte docker. Tous les services s'exécutent dans le même réseau superposé. Ces services exposent tous un port différent sur lequel un serveur web est disponible. L'hôte Docker exécute CoreOS (1520.0.0 Alpha channel).

Parfois, je me retrouve dans une situation où les demandes faites sur http://docker-host.local : timeout. Lorsque je me connecte sur le docker-host et que je fais une requête vers localhost : timeout également. Cependant, à partir d'un Shell dans un conteneur différent, une demande au service réussit sans problème.

docker service ls montre les mappages de port corrects.

Le service qui n'est pas joignable, est apparemment aléatoire. Parfois, tous les services fonctionnent correctement, parfois l'un d'entre eux n'est pas joignable, parfois cela se résout après un certain temps.

J'ai inspecté les réseaux des dockers, ils ne sont pas en conflit avec le réseau de l'hôte.

Je peux reproduire ce problème en créant une pile de services nginx, hébergeant la page web par défaut. fichier : docker-compose-test.yml

version: '3.1'
services:
  nginx1:
    image: nginx:1.11.8-alpine
    networks:
      - test
    ports:
      - "10081:80"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

  nginx2:
    image: nginx:1.11.8-alpine
    networks:
      - test
    ports:
      - "10082:80"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

  nginx3:
    image: nginx:1.11.8-alpine
    networks:
      - test
    ports:
      - "10083:80"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

  nginx4:
    image: nginx:1.11.8-alpine
    networks:
      - test
    ports:
      - "10084:80"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

  nginx5:
    image: nginx:1.11.8-alpine
    networks:
      - test
    ports:
      - "10085:80"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

  nginx6:
    image: nginx:1.11.8-alpine
    networks:
      - test
    ports:
      - "10086:80"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

  nginx7:
    image: nginx:1.11.8-alpine
    networks:
      - test
    ports:
      - "10087:80"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

  nginx8:
    image: nginx:1.11.8-alpine
    networks:
      - test
    ports:
      - "10088:80"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

  nginx9:
    image: nginx:1.11.8-alpine
    networks:
      - test
    ports:
      - "10089:80"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure
networks:
  test:

Ce script va déployer la pile, tester la disponibilité et démonter la pile jusqu'à ce que la situation d'erreur soit atteinte. fichier : test-docker-swarm.sh

#!/bin/bash

DOCKER_HOST=$1
fail=0

while [[ ${fail} -eq 0 ]] ; do
  docker -H ${DOCKER_HOST} stack deploy -c docker-compose-test.yml test
  sleep 15

  for i in $(seq 1 9) ; do
    request="http://${DOCKER_HOST}:1008${i}"
    echo "making request: ${request}"
    curl -s -o /dev/null --max-time 2 ${request}
    if [[ $? -ne 0 ]] ; then
        echo request failed: ${request}
        fail=1
    fi
  done

  if [[ ${fail} -eq 0 ]] ; then
      docker -H ${DOCKER_HOST} stack down test

    while [[ $(docker -H ${DOCKER_HOST} network ls --filter 'name=^test_' | wc -l) -ne 1 ]]; do
      echo "waiting for stack to go down"
      sleep 2
    done
  fi
done

exécution en cours : `./test-docker-swarm.sh

Je n'ai aucune idée des mesures que je peux prendre pour déboguer et résoudre ce problème. Toute indication est la bienvenue.

version du docker

Client:
 Version:      17.06.1-ce
 API version:  1.30
 Go version:   go1.8.2
 Git commit:   874a737
 Built:        Tue Aug 29 23:50:27 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.1-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.2
 Git commit:   874a737
 Built:        Tue Aug 29 23:50:09 2017
 OS/Arch:      linux/amd64
 Experimental: false

info docker

Containers: 9
 Running: 9
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 17.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: x06mlhlwqyo3dg4lmigy18z1q
 Is Manager: true
 ClusterID: qy022nd3bjn1157sxcc6qzr9n
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Root Rotation In Progress: false
 Node Address: 10.255.11.40
 Manager Addresses:
  10.255.11.40:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: v0.13.2 (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
 seccomp
  Profile: default
 selinux
Kernel Version: 4.13.0-rc7-coreos
Operating System: Container Linux by CoreOS 1520.0.0 (Ladybug)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 5.776GiB
Name: fqfs-development
ID: RCNI:3ZUR:LTDA:ABIB:EYEW:HCIY:H2RC:XDNT:LC77:BMQH:FKXI:T6YZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

1voto

BMitch Points 4794

Il existe un problème ouvert sur github qui correspond aux symptômes que vous observez. Je vous recommande de poursuivre en fournissant aux développeurs vos propres journaux, afin qu'ils puissent voir s'il y a des points communs entre les différents rapports.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X