Docker служба должна влиять на обе реплики другой службы - PullRequest
1 голос
/ 14 марта 2020

Доброе утро,

У меня проблема, которую я пытаюсь диагностировать и устранить. Сначала отказ от ответственности. Я только начал изучать Python около 6 или 7 месяцев go, и до этого у меня не было опыта разработки. Моим первым проектом был веб-проект с использованием движка Scrapy. После изучения Docker я решил, что хочу разбить его на контейнеры. Это потребовало немного времени, чтобы понять, но как только я это сделал, я начал работать и координировать в docker -compose.yml.

У меня есть 5 сервисов, один для Scrapyd, который является демоном / сервером, который движок Scrapy работает, один для postgres, чтобы собрать очищенные записи, один для опроса postgres ищет ключевые слова и сервис postgres для go с ним. Наконец, у меня есть служба развертывания, которая доставляет мне проблемы.

Служба развертывания ожидает полного запуска службы Scrapyd (проверено с помощью вызова APi из скрипта), а затем создает python файлы egg для всех моих пауков (веб-сканеры, которые очищают данные) и отправляет их по почте в Scrapyd. Это все работает нормально при моем обычном сочинении, однако сейчас я пытаюсь развернуть его на Docker Swarm.

У меня есть настройки роя на 2 Raspberry Pi, я развертываю службу Scrapyd с

sudo docker service create --name scrapyd --network scrapy-bridge \
--publish 6800:6800 --hostname scrapyd --with-registry-auth \
--replicas 2 my-registry:test-scrapyd-arm

Затем я запускаю службу развертывания с:

sudo docker service create --name scrapyd-deploy --replicas 2 \
--network scrapy-bridge --with-registry-auth \
my-registry:test-scrapyd-deploy-arm

Кажется, все go хорошо, за исключением того, что служба развертывания, похоже, влияет только на одну из реплик Scrapyd. Когда я тестировал, посылая несколько запросов на запуск пауков, некоторые из них могли бы go пройти, а некоторые возвращали ошибку, что паука не существует.

Затем я сделал:

curl 127.0.0.1:6800

несколько раз и понял, что пауки были развернуты только в одной из реплик Scrapyd

Как я могу настроить это так, чтобы мои Служба развертывания влияет на службу Scrapyd на обоих узлах?

docker -compose.yml:

version: '3'
services:
    scrapyd:
        image: my-image:test-scrapyd
        ports:
            - "6800:6800"
        expose:
            - "6800"
        volumes:
            - Vscrapyd:/app/clist/
        networks: 
             - scrapyd-postgres
             - scrapy-bridge
            # - bridge

    scrapyd-postgres:
        image: my-image:test-scrapyd-postgres
        ports:
            - "5400:5432"
        depends_on: 
            - scrapyd
        volumes: 
            - Vscrapyd-postgres:/var/lib/postgresql/data
        networks: 
             - scrapyd-postgres
             - notify-bridge

    notify:
        image: my-image:test-notify
        depends_on: 
            - notify-postgres
        volumes: 
            - Vnotify:/projects/notify
        networks: 
             - notify-bridge
             - notif-postgres

    notify-postgres:
        image: my-image:test-notify-postgres
        ports: 
            - "5401:5432"
        depends_on: 
            - scrapyd-postgres
        volumes: 
            - Vnotify-postgres:/var/lib/postgresql/data
        networks: 
             - notif-postgres

    scrapyd-deploy:
        image: my-image:test-scrapyd-deploy
        volumes:
            - VTscrapyd-deploy:/app/clist_deploy/
        networks:
            - scrapy-bridge
        command: ["./entrypoint.sh", "scrapyd", "6800" , "python3", "/app/clist_deploy/deploy.py"]


volumes: 
    Vscrapyd:
        external: false
    Vscrapyd-postgres:
        external: false
    Vnotify:
        external: false
    Vnotify-postgres:
        external: false
    VTscrapyd-deploy:
        external: false
    Vscrapyd-api:
        external: false

networks:
    default:
        external:
            name: bridge
    notif-postgres:
        driver: bridge
        external: false
    scrapyd-postgres:
        driver: bridge
        external: false
    notify-bridge:
        driver: bridge
        external: false
    scrapy-bridge:
        driver: bridge
        external: false

точка входа. sh

#!/bin/sh

set -e

host="$1"
port="$2"
shift 2
cmd="$@"

python3 scrapy_status.py $host $port

# Retrieves the server response and parses out ok if it exists in response
# if ok then breaks out of loop
# until [ $response = "ok" ]

exec $cmd

scrapy_status.py

import subprocess, sys, time


def get_scrapyd_status(host, port):

    try:
        result = subprocess.check_output(["curl",f"http://{host}:{port}/daemonstatus.json"])
    except subprocess.CalledProcessError:
        pass
    else:
        return result

def main(host,port):
    count = 0
    while (count < 5):
        r = get_scrapyd_status(host,port)

        print(r)
        try:
            r = "".join(map(chr,r)).split(",")[1].split(":")[1].replace('"',"").strip()
        except TypeError:
            pass
        if r == 'ok':
            print('Scrapyd is up!')
            sys.exit(0)
        else:
            print('Scrapyd not up yet...')
            pass
        count += 1
        time.sleep(5)

if __name__ == "__main__":
    if sys.argv and len(sys.argv) != 3:
        sys.exit('Only 2 arguments are allowed!')
    elif len(sys.argv) == 3:
        host = sys.argv[1]
        port = sys.argv[2]
        main(host,port)
    else:
        sys.exit('Unknown error ocurred')

вот гист для deploy.py, если кто-то хочет его увидеть

1 Ответ

1 голос
/ 14 марта 2020

Похоже, что вы находитесь в той точке этого проекта, где вы хотите объединить вещи в производственное развертывание. Во-первых, если вы узнали все это за 6 месяцев, не имея опыта разработки программного обеспечения, вы проделали фантастическую работу c.

Двигаясь дальше, история выбора инструментов и того, как они взаимодействуют между собой. Docker Swarm является частью самого Docker, тогда как Docker Compose является внешним по отношению к Docker и работает посредством взаимодействия с Docker Engine через API Docker. Действительно, Compose - это всего лишь Python скрипт. В настоящее время оба инструмента имеют большое сходство, и за последние несколько лет к ним добавилось много нового.

Интересная часть - когда вы начинаете рассматривать третий инструмент: Docker Stack. Стек, как и Swarm, является частью Docker. В совокупности два инструмента перекрываются с Compose по-разному. Они оба могут читать одни и те же файлы docker-compose.yml (но для Stack требуется версия 3, а Compose также может использовать более старую версию).

Одно из основных отличий между Docker Stack и Docker Compose заключается в том, что последний будет создавать новые образы. Стек хочет предварительно подготовить изображения и оттуда будет координировать процесс установки. По этой причине Compose все еще является лучшим выбором для того, что вы использовали до этого момента: локальная разработка и тестирование, когда изображения перестраиваются снова и снова в рамках цикла разработки.

Итак что я здесь получаю? Поскольку вы начинаете задумываться о развертывании этого проекта с использованием Swarm, возможно, сейчас самое время подумать об использовании Docker Stack для координации развертывания. Вы можете использовать:

$ docker stack deploy

для непосредственного развертывания стека в рое. Во-первых, вам нужно добавить службу реестра:

$ docker service create --name registry --publish published=5000,target=5000 registry:2
$ curl http://localhost:5000/v2/

Поскольку приложение уже создано и работает с docker-compose, создайте его следующим образом:

$ docker-compose up -d
[ wait.... ]
$ docker-compose down

Pu sh в реестр:

$ docker-compose push

и попробуйте развернуть его в стеке:

$ docker stack deploy --compose-file docker-compose.yml stackdemo

эта документация может помочь. Вы должны иметь возможность использовать стек для управления настройкой всех реплик в рое.

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