docker run -it --device=/dev/bus/usb/001/002 ubuntu bash

Я не обнаружил влияния udev из udev-rules.tar.gz, который в SLK на работу в docker.

У меня заработали варианты на ubuntu 20.04

docker run --device=/dev/bus/usb/001/003
docker run --privileged
docker run --device-cgroup-rule="c 189:* rmw" -v /dev/bus/usb:/dev/bus/usb

Установка udev rules и например

docker run -v /dev/bus/usb:/dev/bus/usb

не заработало. Можете спросить у разработчиков, как с какими параметрами запускали docker?

Наши вводные

- java 17,
- SLK 3.3.0,
- хост linux redhat и debian семейств (CentOS, Ubuntu, Astra Linux). Если это рабочая машина, чаще это будет Win 10 с docker wsl2
- Если хост linux и на нем активируем программные ключи, то ставим на хост Guardant Control Center
- Если хост linux и подключаем аппаратные ключи, настраиваем udev-rules в хосте
- docker image обычно openjdk:17-jdk-alpine, но т.к для Control Center нужна ОС Debian/Redhat/SUSE семейства, для локальных в докере ключей можно для экспериментов ориентироваться на debian 11 bellsoft/liberica-openjdk-debian:17.0.5
- Мы купили несколько физических ключей Sign, скоро приедут, пока нет возможности на них проверить. Проверяли только программные демо ключи.
- Если физические Sign для некоторых кейсов не заработают, будем рассматривать DL Net или Sign Net

Т.к инсталляции и стенды у нас могут варьироваться - большие хосты с kubernetes, маленькие хосты с docker-compose/swarm, виртуалки, но само приложение будет всегда в docker (по крайней мере рассчитываем на это), то мы рассматриваем все способы использования приложением guardant api. Способы ниже, вопросы в самом низу:

a) Ключ аппаратный Sign
a.a) Хост с kubernetes, ключ в хосте
a.b) Хост с docker-compose/swarm, ключ в хосте
a.c) виртуалка с linux с docker-compose/swarm, приложение в docker-compose, ключ в хосте

b) Ключ программный локальный DL
b.a) Хост с docker-compose/swarm, ключ на хосте. Проверял, но не заработало, даже с --priviliged
b.b) виртуалка с linux, в ней приложение, ключ на хосте. Проверял, не заработало
b.c) docker с debian, ключ активируется в контейнере. Проверено, работает при привязке только по cpu. При перезапуске контейнера происходит повторная активация

c) Ключ сетевой аппаратный Sign Net
c.a) Хост с kubernetes, Control Center в kubernetes (виртуалка/docker), ключ в хосте
c.b) Хост с docker-compose/swarm, Control Center в docker, ключ в хосте
c.c) Хост с docker-compose/swarm, Control Center на хосте, ключ в хосте. Не проверял, но думаю не должно быть проблем
c.d) виртуалка на хосте, Control Center в виртуалке, приложение в виртуалке, ключ в хосте.

d) Ключ программный DL Net
d.a) Хост с docker-compose/swarm, ключ на хосте, control center на хосте. Проверено, работает
d.b) виртуалка, control center на хосте, ключ на хосте,. Проверено, работает
d.c) виртуалка, control center в виртуалке, ключ в виртуалке. Проверено, работает
d.d) docker с debian, ключ в контейнере. Проверено, работает при привязке только по cpu. При перезапуске контейнера происходит повторная активация

Из этих вариантов возникает несколько вопросов:

1. аппаратный ключ на хосте виден в docker (a.a, a.b, c.a, c.b)? Тут даже не просим вас настроить kubernetes и проверять, но хотя бы схема ключ воткнут в хост и в контейнер прокинут volume с флешкой https://stackoverflow.com/a/57117369/9466638
2. аппаратный ключ может быть виден в виртуалке, если прокинуть usb в виртуалку (a.c, c.d)?
3. программный ключ на хосте виден в docker/виртуалке (b.a, b.b)? Мне кажется это невозможно.
4. где хранится информация о программном ключе, чтобы прокинуть его в докер/сохранить в volume (b.c, d.d)? Как для linux и для windows. Возможно вы не разглашаете эту информацию, но тогда скорее всего отметаются варианты с докер и программными ключами.
5. какие порты открывать для control center для docker (для связи с другими Control Center во вне и для поиска ключа приложением). Потому что сейчас кажется что это всегда 3189