Сбой докера - PullRequest
       54

Сбой докера

0 голосов
/ 01 июля 2018

Я пытаюсь развернуть докерский стек, который включает мою среду разработки. Но в случайных случаях у меня следующая ошибка:

> failed to create service < service_name >: Cannot connect to the
> Docker daemon at unix:///var/run/docker.sock. Is the docker daemon
> running?

Далее я перезапускаю демон Docker. Иногда требуется убить докер процессов и прокладок. Я удалил старый стек и собрал заново. Иногда Docker успешно завершает сборку, но на начальном этапе происходит сбой сокета.

Также все контейнеры работают правильно, когда я запускаю его в обычном режиме, без роя или стека. Он не работает точно внутри роя.

Я использовал следующую команду для сборки:

> $ docker stack deploy dev-env-stc -c docker-compose.yml

Среда запускается в Antergos Linux (Arch).

макет как на диаграмме enter image description here

Сети контейнеров и докеров Nginx, созданные с помощью команд:

>$ docker run --detach --name nginx-main --net dev-env-ext --ip 10.20.20.10 --publish 80:80 --publish 443:443 --volume /env-vol/nginx/conf:/etc/nginx:ro --volume /env-vol/nginx/www:/usr/var/www --volume /env-vol/nginx/logs:/usr/var/logs --volume /env-vol/nginx/run:/usr/var/run --volume /env-vol/ssl:/usr/var/ssl:ro nginx-webserver 
>
> $ docker network create --driver=bridge --attachable --ipv6 --subnet fd19:eb5a:3d2f:f15d::/48 --subnet 10.20.20.0/24 --gateway 10.20.20.1 dev-env-ext
> 
> $ docker network create --driver=bridge --attachable --ipv6 --subnet fd19:eb5a:3e30:f15d::/48 --subnet 10.20.30.0/24 --gateway 10.20.30.1 dev-env-int
> 
> $ docker network create --driver=overlay --attachable --ipv6 --subnet fd19:eb5a:3c1e:f15d::/48 --subnet 10.20.40.0/24 --gateway 10.20.40.1 dev-env-swarm
> 
> $ docker network connect dev-env-swarm --ip=10.20.40.10 nginx-main
>
> $ docker network connect dev-env-int --ip=10.20.30.10 nginx-main

Мой файл docker-compose.yml:

version: '3.6'
volumes:
  postgres-data:
    driver: local
  redis-data:
    driver: local
networks:
  dev-env-swarm:
    external: true
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    hostname: gitlab.testenv.top
    external_links: 
      - nginx-main
    ports:
      - 22:22
    healthcheck:
      test: ["CMD", "curl", "-f", "https://localhost:443"]
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 60s
    deploy:
      mode: global
      endpoint_mode: vip
      resources:
        limits:
          cpus: "0.50"
          memory: 4096M
        reservations:
          cpus: "0.10"
          memory: 512M
      restart_policy:
        condition: on-failure
        delay: 20s
        max_attempts: 3
        window: 300s
    networks:
      dev-env-swarm:
        aliases:
          - gitlab.testenv.top
    dns: 
      - 10.10.10.10
      - 8.8.8.8
    volumes:
      - /env-vol/gitlab/config:/etc/gitlab
      - /env-vol/gitlab/logs:/var/log/gitlab
      - /env-vol/gitlab/data:/var/opt/gitlab
    external_links:
      - nginx-main
  redis:
    env_file: .env
    image: redis:3.2.6-alpine
    hostname: redis.testenv.top
    external_links: 
      - nginx-main
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:6379"]
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 60s
    deploy:
      mode: global
      endpoint_mode: dnsrr
      resources:
        limits:
          cpus: "0.20"
          memory: 1024M
        reservations:
          cpus: "0.05"
          memory: 128M
      restart_policy:
        condition: on-failure
        delay: 20s
        max_attempts: 3
        window: 60s
    volumes:
      - redis-data:/var/lib/redis
    command: redis-server --appendonly yes
    networks:
      dev-env-swarm:
        aliases:
          - redis.testenv.top
    dns:
      - 10.10.10.10
      - 8.8.8.8
  redisco:
    image: rediscommander/redis-commander:latest
    hostname: redisco.testenv.top
    external_links: 
      - nginx-main
    depends_on:
      - redis
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8081"]
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 60s
    deploy:
      mode: global
      endpoint_mode: dnsrr
      resources:
        limits:
          cpus: "0.20"
          memory: 512M
        reservations:
          cpus: "0.05"
          memory: 256M
      restart_policy:
        condition: on-failure
        delay: 20s
        max_attempts: 3
        window: 60s
    networks:
      dev-env-swarm:
        aliases:
          - redisco.testenv.top
    dns: 
      - 10.10.10.10
      - 8.8.8.8
    environment: 
      REDIS_PORT: 6379
      REDIS_HOST: redis.testenv.top
  plantuml:
    image: plantuml/plantuml-server:tomcat
    hostname: plantuml.testenv.top
    external_links: 
      - nginx-main
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080"]
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 60s
    deploy:
      mode: global
      endpoint_mode: dnsrr
      resources:
        limits:
          cpus: "0.20"
          memory: 1024M
        reservations:
          cpus: "0.05"
          memory: 256M
      restart_policy:
        condition: on-failure
        delay: 20s
        max_attempts: 3
        window: 60s
    networks:
      dev-env-swarm:
        aliases:
          - plantuml.testenv.top
    dns: 
      - 10.10.10.10
      - 8.8.8.8
  portainer-agent:
    image: portainer/agent
    external_links: 
      - nginx-main
    expose:
      - 9001
    deploy:
      mode: global
      endpoint_mode: dnsrr
      resources:
        limits:
          cpus: "0.20"
          memory: 1024M
        reservations:
          cpus: "0.05"
          memory: 256M
      restart_policy:
        condition: on-failure
        delay: 20s
        max_attempts: 3
        window: 60s
    environment:
      AGENT_CLUSTER_ADDR: tasks.portainer-agent
      AGENT_PORT: 9001
      LOG_LEVEL: debug
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      dev-env-swarm:
        aliases:
          - portainer-agent.testenv.top
    deploy:
      mode: global
  portainer:
    image: portainer/portainer
    command: -H tcp://tasks.portainer-agent:9001 --tlsskipverify
    depends_on:
      - portainer-agent
    external_links: 
      - nginx-main
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000"]
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 60s
    deploy:
      mode: global
      endpoint_mode: dnsrr
      resources:
        limits:
          cpus: "0.20"
          memory: 2024M
        reservations:
          cpus: "0.05"
          memory: 512M
      restart_policy:
        condition: on-failure
        delay: 20s
        max_attempts: 3
        window: 60s
    volumes:
      - /env-vol/portainer/data:/data
    hostname: portainer.testenv.top
    networks:
      dev-env-swarm:
        aliases:
          - portainer.testenv.top
    dns: 
      - 10.10.10.10
      - 8.8.8.8 
  pgadmin4:
    image: dpage/pgadmin4:latest
    hostname: pgadmin.testenv.top
    external_links: 
      - nginx-main
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost"]
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 60s
    deploy:
      mode: global
      endpoint_mode: dnsrr
      resources:
        limits:
          cpus: "0.20"
          memory: 1024M
        reservations:
          cpus: "0.05"
          memory: 256M
      restart_policy:
        condition: on-failure
        delay: 20s
        max_attempts: 3
        window: 60s
    environment:
      PGADMIN_DEFAULT_EMAIL: email@example.com
      PGADMIN_DEFAULT_PASSWORD: PASWORD
    networks:
      dev-env-swarm:
        aliases:
          - pgadmin.testenv.top
    dns: 
      - 10.10.10.10
      - 8.8.8.8
    volumes:
      - /env-vol/pgadmin:/var/lib/pgadmin

1 Ответ

0 голосов
/ 27 марта 2019

Проблема с сокетом была из-за неправильной установки Python из исходников и ручной установки библиотек. Похоже, я установил несовместимые версии. Когда я переустановил Python из репозитория, эта проблема больше не появлялась.

Но я пришел к выводу, что использование Docker Stack в среде разработки не является хорошим решением, поэтому лучше использовать Docker Compose по этой причине. Поэтому стек Docker следует использовать для конфигураций развертывания (например, развертывание Docker Swarm или в Kubernetes, или в других облачных средах).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...