Guardant licensing api, SLK и docker
Здравствуйте, т.к наши дистрибутивы рассчитаны на работу в docker, возникло много вопросов по использованию SLK с docker. Я вполне допускаю, что docker пока не ваша целевая платформа, только linux, но в теории linux и docker схожи, но 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