Docker swarm обновление сертификатов?

Question

[kiranananda]

Здравствуйте!

Есть запущенный в docker swarm nginx. К нему подключается куча сертификатов. В данный момент сделал через secrets. Но после обновления файла сертификата докер ругается

failed to update secret dev-test_sec: Error response from daemon: rpc error: code = InvalidArgument desc = only updates to Labels are allowed

То есть надо менять названия, тобиш ротейт получается. Да для конфигов такой подход очень хороший, что бы случайно не уронить сервис и была возможность отката, но для сертификата хорошо бы вырубить как то это ограничение или на крайняк как то решить этот вопрос другим путем. Сами сертификаты обновляются по крону через certbot...

Пока на ум приходит мысль писать скрипт, проверять если какой то сертификат изменен, менять ему лабел и растратить сервис...

Есть ли какие идеи?

Comments

[Дмитрий Шицков]

А почему вы не удаляете старый secret перед добавлением нового?

[kiranananda]

Дмитрий Шицков, Так там штука такая, при изменении этих данных swarm рестартит процесс. Если удалять и добавлять будет 2 рестарта. Самое хреновое то что у меня эти все настройки в docker-compose.

Ради эксперимента таки попробовал но при удалении получаю

Error response from daemon: rpc error: code = InvalidArgument desc = secret 'dev-test_sec' is in use by the following service: dev-fedsp_nginx

Если совсем удалять и растратить сервис, тогда nginx упадет и скажет "А где мой секрет?" :)

[Дмитрий Шицков]

kiranananda, а если остановить контейнер, удалить секрет, добавить секрет, предоставлять доступ nginx и запустить его снова ? :)
Секрет невозможно обновить, так что вариантов без остановки контейнера, как мне кажется, нет.

[kiranananda]

Дмитрий Шицков, Есть ротейт, он работает все хорошо. Но для этого надо писать скрипт который будет проверять какие секреты изменены и делать ротейт, это делать совсем не охота :). Останавливать там совсем низя, может до сотни онлайн подключений быть, нагрузка хорошая, мне потом начальство по шапке даст )))...

[Дмитрий Шицков]

kiranananda, ну тут претензии у меня будут к вашей инфраструктуре :)

Останавливать там совсем низя

А почему сервис в единичном экземпляре?

Но для этого надо писать скрипт который будет проверять какие секреты изменены и делать ротейт

А где ваша система управления конфигурациями для таких задач?

[kiranananda]

Ну тут nginx. Можно конечно 2 реплики сделать это не проблема, но тогда часть трафика начнет гоняться по сети до второго nginx, что мне совсем не хочется. На самом деле там при рестарте стартует новый сервис, старый остается висеть пока все клиенты не отвалятся... Так что простоев там нет никаких.

Конфигурация у меня на отдельной виртуалочке пока что, что бы туда никто кроме меня не ползал :).
Вот он пока тестовый такой

nginx:
    image: 127.0.0.1:5000/nginx:0.1
    ports:
      - target: 8080
        published: 8082
        mode: host
    user: www-data:www-data
    volumes:
      - /srv:/srv
    depends_on:
      - web-dev

    secrets:
      - source: test_sec
        target: /etc/test.11
    stop_grace_period: 3m
    stop_signal: SIGQUIT

    deploy:
        #Перезапуск сервиса
        restart_policy:
            condition: on-failure
            delay: 15s
            window: 120s

        rollback_config:
            order: start-first

        update_config:
            failure_action: rollback
            monitor: 10s
            max_failure_ratio: 0
            order: start-first

        placement:
            constraints: [node.labels.registry == true]

    logging:
        driver: syslog
        options:
            tag: nginx-dev
            syslog-address: "udp://10.0.0.151:514"

secrets:
  cert_mysite_com:
    file: /etc/docker/certbot/letsencrypt/live/mysite/cert.pem
  test_sec:
    file: ./deploy