Размещение ShinyProxy в Azure

Question

Я изучаю возможности Docker для ShinyProxy в Azure и хочу настроить его простым, расширяемым и доступным способом. Насколько я понимаю, есть пять способов настроить службы на основе Docker в Azure.

Вопросы

Мой вопрос двоякий,

1. на общем опыте развертывания контейнеров на основе ShinyProxy, которые порождают и уничтожают другие контейнеры на основе подключенных пользовательских сеансов;
2. как исправить мой подход?

подходы

(Перечислено от наиболее желательного к наименее желательному; проверено все, кроме подхода виртуальной машины.)

A) Настройка службы приложений Docker или Docker Compose

Большая часть опыта, сложность абстрагируется.

При таком подходе я обнаружил, что текущая реализация Docker и Docker Compose для Azure App Services не поддерживает (игнорирует ) networksкоторые необходимы (насколько я понимаю), чтобы ShinyProxy мог взаимодействовать с другими контейнерами во внутренней сети. В файле Docker Compose я указал следующее (и проверил, что он работает локально):

      networks:
  app_default:
    driver: bridge
    external: false
    name: app_default

Если я правильно понимаю документацию, вы просто не можете создавать какие-либо пользовательские сети для своих контейнеров. Неясно, можете ли вы создать пользовательскую виртуальную сеть Azure, которую можно было бы использовать для этого или нет (у меня нет опыта их создания).

Второй важной частью настройки ShinyProxy является совместное сопоставление файла на хосте и в контейнере. Опять же, это можно сделать с помощью файла Docker Compose или параметров для одного файла Docker. Вот как я указал это в своем файле Docker Compose (и проверил, что он работает):

      volumes:
  # The `//` path prefix only works on Windows host machines, it's because
  # Windows uses the Windows Pipeline system as a workaround for these kinds
  # of Unix filesystem paths. On a Linux host machine, the path prefix
  # needs to only contain a single forward slash, `/`.
  # Windows Host volume
  # docker_sock: //var/run/docker.sock
  # Linux Host volume
  docker_sock: /var/run/docker.sock

А затем используйте docker_sockименованный том для сопоставления с контейнерами /var/run/docker.sockфайл, docker_sock:/var/run/docker.sock.

Из-за этих двух проблем, пытаясь посетить любой specsопределенный в файле ShinyProxy, просто приведет к Connection refusedили же File could not be foundОшибки Java. Оба соответствуют общению по сети и docker.sockотображение.

Б) Экземпляры контейнеров

Новый вид сервиса, кажется приятным и простым

Почти те же проблемы, что и в подходе службы приложений.

C) Контейнерные приложения

Новый вид сервиса, кажется приятным и простым

Почти те же проблемы, что и в подходе службы приложений.

Г) Служба Кубернетес

Требует много дополнительных настроек.

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

Д) Виртуальная машина

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

Еще не пробовал. Кажется, есть пара статей, в которых рассказывается, как к этому подойти.

Локальное воспроизведение

Вот несколько измененных примеров моих конфигурационных файлов. Я оставил пару комментариев, а также прокомментировал свойства там.

блестящий прокси application.yml:

      # ShinyProxy Configuration

proxy:
  title: ShinyProxy Apps
  landing-page: /

  heartbeat-enabled: true
  heartbeat-rate: 10000 # 10 seconds
  heartbeat-timeout: 60000 # 60 seconds

  # Timeout for the container to be available to ShinyProxy
  container-wait-time: 20000 # 20 seconds
  
  port: 8080
  authentication: none

  docker:
    # url: http://localhost:2375
    privileged: true
    internal-networking: true
    container-network: "app_default"

  specs:
    - id: hello_demo
      container-image: openanalytics/shinyproxy-demo
      display-name: Hello Application
      description: Application which demonstrates the basics of a Shiny app.
      container-network: "${proxy.docker.container-network}"
      # container-cmd: ["R", "-e", "shinyproxy::run_01_hello()"]

logging:
  file:
    name: shinyproxy.log

server:
  servlet:
    context=path: /

sprint:
  application:
    name: "ShinyProxy Apps"

блестящий прокси Dockerfile:

      FROM openjdk:8-jre

USER root

RUN mkdir -p "/opt/shinyproxy"

# Download shinyproxy version from the official source
RUN wget https://www.shinyproxy.io/downloads/shinyproxy-2.6.0.jar -O "/opt/shinyproxy/shinyproxy.jar"
# Or, Copy local shinyproxy jar file
# COPY shinyproxy.jar "/opt/shinyproxy/shinyproxy.jar"

COPY application.yml "/opt/shinyproxy/application.yml"

WORKDIR /opt/shinyproxy/
CMD ["java", "-jar", "/opt/shinyproxy/shinyproxy.jar"]

docker-compose.yml:

      networks:
  app_default:
    driver: bridge
    external: false
    name: app_default

# volumes:
  # The `//` path prefix only works on Windows host machines, it's because
  # Windows uses the Windows Pipeline system as a workaround for these kinds
  # of Unix filesystem paths. On a Linux host machine, the path prefix
  # needs to only contain a single forward slash, `/`.
  # Windows only volume
  # docker_sock: //var/run/docker.sock
  # Linux only volume
  # docker_sock: /var/run/docker.sock

services:
  # Can be used to test out other images than the shinyproxy one
  # hello_demo:
  #   image: openanalytics/shinyproxy-demo
  #   container_name: hello_demo
  #   ports:
  #     - 3838:3838
  #   networks:
  #     - app_default
  #   volumes:
  #     - //var/run/docker.sock:/var/run/docker.sock

  shinyproxy:
    build: ./shinyproxy
    container_name: app_shinyproxy
    # Change the image to what you've called your own image to
    image: shinyproxy:latest
    # privileged: true
    restart: OnFailure
    networks:
      - app_default
    ports:
      - 8080:8080
    volumes:
      - //var/run/docker.sock:/var/run/docker.sock

Со всеми файлами на месте просто запустите docker compose build && docker compose up.