我正在探索 Azure 上 ShinyProxy 的 Docker 功能,我希望以一种简单、可扩展且经济实惠的方式对其进行设置。据我了解,有五种方法可以在 Azure 上设置基于 Docker 的服务。
问题
我的问题有两个,
- 部署基于 ShinyProxy 的容器的一般经验,这些容器会根据连接的用户会话生成和销毁其他容器;
- 如何纠正我的方法?
方法
(从最理想到最不理想列出;除了虚拟机方法之外的所有测试。)
A) 应用服务 Docker 或 Docker Compose 设置
大多数经验,复杂性都被抽象掉了。
通过这种方法,我发现 Docker 和 Docker Compose for Azure App Services 的当前实现不支持(忽略)networks
(据我了解)让 ShinyProxy 与内部网络上的其他容器通信所需的那些。在 Docker Compose 文件中,我指定了以下内容(并验证它在本地工作):
networks:
app_default:
driver: bridge
external: false
name: app_default
如果我正确理解文档,您将无法为您的容器创建任何自定义网络。目前尚不清楚您是否可以创建可用于此目的的自定义 Azure vnet(我没有创建这些的经验)。
这个 ShinyProxy 设置的第二个重要部分是docker.sock
将主机和容器中的文件映射在一起。同样,这可以通过 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
ShinyProxyapplication.yml
文件中定义的任何内容只会导致 aConnection refused
或File could not be found
Java 错误。两者都对应于网络通信和docker.sock
映射。
B) 容器实例
新型服务,看起来很简单
与应用服务方法几乎相同的问题。
C) 容器应用
新型服务,看起来很简单
与应用服务方法几乎相同的问题。
D) Kubernetes 服务
需要很多额外的配置。
尝试过,但放弃了这种方法,因为我不想处理额外的配置层,而且我怀疑我是否需要这么多的控制来实现我想要的目标。
E) 虚拟机
需要对生产环境进行大量设置和自我管理。
还没试过。似乎有几篇文章讨论了如何解决这个问题。
本地复制
这是我的配置文件的一些修改示例。我留下了一些评论,并在那里评论了属性。
闪亮代理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
.