CN112256399B - 基于Docker的Jupyter Lab多用户远程开发方法及系统 - Google Patents

基于Docker的Jupyter Lab多用户远程开发方法及系统 Download PDF

Info

Publication number
CN112256399B
CN112256399B CN202011172063.7A CN202011172063A CN112256399B CN 112256399 B CN112256399 B CN 112256399B CN 202011172063 A CN202011172063 A CN 202011172063A CN 112256399 B CN112256399 B CN 112256399B
Authority
CN
China
Prior art keywords
service
lab
user
docker
jupyter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011172063.7A
Other languages
English (en)
Other versions
CN112256399A (zh
Inventor
李伟强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sichuan Changhong Electric Co Ltd
Original Assignee
Sichuan Changhong Electric Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sichuan Changhong Electric Co Ltd filed Critical Sichuan Changhong Electric Co Ltd
Priority to CN202011172063.7A priority Critical patent/CN112256399B/zh
Publication of CN112256399A publication Critical patent/CN112256399A/zh
Application granted granted Critical
Publication of CN112256399B publication Critical patent/CN112256399B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明公开了一种基于Docker的Jupyter Lab多用户远程开发方法，其特征在于，以Docker Swarm程序实现对容器集群的管理，以文件共享技术实现Jupyter Lab服务中用户数据的持久化存储，利用Docker daemon API以程序的方式自动化地完成用户账户验证、用户数据文件区域划分、Jupyter Lab服务启动，以反向代理技术将用户账户验证服务和Jupyter Lab服务统一到同一个域名下。本发明的方法可实现互相隔离的多用户Jupyter Lab运行环境，解决传统方案中组件繁多，配置、部署、维护难度较大，较为复杂的问题。

Description

基于Docker的Jupyter Lab多用户远程开发方法及系统
技术领域
本发明涉及支持多用户的远程交互式编程技术领域，特别涉及一种基于Docker的Jupyter Lab多用户远程开发方法及系统。
背景技术
Docker是开源的应用容器引擎，通过将应用打包为一个标准化、可移植、自管理、轻量级的容器中，能够发布到任何流行的Linux计算机中，高效率地实现虚拟化。DockerSwarm是Docker软件内置的集群管理程序，能够将集群中的Docker节点，抽象为单个Docker节点，简化集群管理过程，具有操作简便、配置简单，占用资源较少的特点。Kubernets是由Google开发的容器集群管理系统，功能强大，但使用和配置难度较大，管理系统本身也占用大量计算机资源。
Jupyter Lab，作为Jupyter Notebook软件的下一代版本，是一款支持多种编程语言的交互式计算开发开源软件，在数据分析，机器学习等工作中得到广泛应用，用户能够通过网页登录到云端的交互式编程环境中，这极大地方便了用户调用远程计算资源进行程序开发、数据研究等工作。在使用过程中，独立的计算资源、数据存储区域、程序执行权限等互相隔离的运行环境是多用户使用场景下的必然需求，但是Jupyter Lab本身对于多用户的支持较弱，需要其他方式提供一定支持，实现多用户的计算环境的难度较大。
通常情况下，要想实现多用户的Jupyter Lab运行环境，需要手动在服务器端建立多个不同的Linux系统账户，再启动多个Jupyter Lab服务程序，并且每个服务程序的配置文件中要指定对应的Linux系统账户名称以及每个程序对应的登录密码。在交付用户使用时，用户需要牢记自己的Jupyter Lab服务URL地址和登录密码。然而这种实现方式存在较多缺点，例如：服务的维护需要服务器管理员手动完成，操作较为繁琐；每个用户对于服务器硬件资源的占用是全局的，会出现用户对系统资源的抢占现象，并且某个用户对服务器系统环境造成的影响也会影响到其他用户；如果用户量较大时，服务器管理员需要手动管理大量服务器，工作量较大；多服务器情况下，每个用户的Jupyter Lab服务URL地址各不相同，用户使用难度增加等。
Jupyter组织为满足多个用户使用各自独立的Jupyter Lab服务器的需求，开发了JupyterHub，除了上述利用Linux系统用户的权限隔离功能实现用户环境隔离之外，还实现了利用外部账号认证系统实现用户认证，以及利用Kubernetes服务框架的容器化用户运行环境隔离方案。该容器化方案的优点是通过Kubernetes服务框架连接到Docker集群资源，能够将Jupyter Lab运算服务部署在多台物理机中，支持大规模用户的访问，并且每个用户的Jupyter Lab都位于独立的Docker容器中，资源存储区域独立，权限仅限于容器内部，计算资源受到容器约束。但是，这一实现方案也存在一定的弊端，整体实现起来复杂，JupyterHub和Kubernetes的组件繁多，服务框架配置、部署、维护起来难度较大。该实现方案中的集群管理服务Kubernetes也需要占用大量的计算资源，对于小规模的Jupyter Lab服务部署情况下，可提供给用户使用的计算资源被大量占用。
现有的技术方案中，虽然能够解决Jupyter Lab支持互相隔离的多用户运行环境问题，但是实现方案组件繁多，配置、部署、维护难度较大，较为复杂。
发明内容
本发明的目的是克服上述背景技术中不足，提供一种基于Docker的Jupyter Lab多用户远程开发方法及系统，基于Docker的容器化技术，Docker Swarm容器集群管理技术，结合反向代理技术、共享文件存储技术，并利用Docker daemon API开发用户认证及服务资源调度程序，实现互相隔离的多用户Jupyter Lab运行环境，解决传统方案中组件繁多，配置、部署、维护难度较大，较为复杂的问题。
为了达到上述的技术效果，本发明采取以下技术方案：
基于Docker的Jupyter Lab多用户远程开发方法，以Docker Swarm程序实现对容器集群的管理，以文件共享技术实现Jupyter Lab服务中用户数据的持久化存储，利用Docker daemon API以程序的方式自动化地完成用户账户验证、用户数据文件区域划分、Jupyter Lab服务启动，以反向代理技术将用户账户验证服务和Jupyter Lab服务统一到同一个域名下；
本发明的基于Docker的Jupyter Lab多用户远程开发方法中，以Docker Swarm实现对容器集群的管理，Docker Swarm为Docker自带组件，操作简便，配置简单，运行时占用资源少；以文件共享技术实现Jupyter Lab服务中用户数据的持久化存储，利用Dockerdaemon API以程序的方式自动化地完成用户账户验证、用户数据文件区域划分、JupyterLab服务启动等操作，该过程由程序自动执行，无需人工配置、启动服务，使用方便，且使用到的组件均有成熟、配置简单的开源程序，这些服务均在Docker容器中运行，服务部署难度降低；以反向代理技术将用户账户验证服务和Jupyter Lab服务统一到同一个域名下，用户仅需要访问一个域名，即可完成登录和Jupyter Lab服务访问的操作，提高了实用便利性；即基于Docker的容器化技术，Docker Swarm容器集群管理技术，结合反向代理技术、共享文件存储技术，并利用Docker daemon API开发用户认证及服务资源调度程序，实现互相隔离的多用户Jupyter Lab运行环境，解决了传统方案中组件繁多，配置、部署、维护难度较大，较为复杂的问题。
同时，本发明公开了一种基于Docker的Jupyter Lab多用户远程开发系统，包括硬件层、服务层、应用层；
所述硬件层包括基础网络连接和若干服务器资源；所述服务层包括若干Docker服务、Docker Swarm服务、Docker Networking服务、反向代理服务、Web服务、数据库服务、文件共享服务、若干Jupyter Lab服务；所述应用层包括若干用户终端；
所述基础网络连接与服务器资源相连并为其提供网络连接环境；所述服务器资源利用所述基础网络连接实现网络互相访问；且在反向代理服务所在的上述服务器资源中，通过基础网络连接可提供能够从外部访问服务资源的IP及端口；
所述Docker服务与服务器资源一一对应并部署于服务器资源中，使所述服务器资源成为Docker节点；
所述Docker Swarm服务为由所述若干Docker服务组成的集群，且所述若干Docker服务中至少有一个Docker服务为执行管理任务的主节点，其余Docker服务为接受运行任务的子节点；所述Docker Swarm服务用于接受来自所述Web服务的控制请求，并负责启动、关闭、获取所述Jupyter Lab服务；
所述Docker Networking服务为运行在所述Docker服务中的容器服务，用于为Docker Swarm服务管理的集群提供内部的网络连接服务；
即在所述Docker服务中构建所述Docker Swarm服务和Docker Networking服务；所述Docker Swarm服务可将所述Docker服务组织成为Docker服务的集群；DockerNetworking服务将所述Docker Swarm服务建立的Docker服务集群中各个服务、容器之间进行跨宿主机网络连接，并且服务、容器的名称可作为hostname实现网络连接；
所述反向代理服务、Web服务、数据库服务、文件共享服务、若干Jupyter Lab服务均以容器的形式运行在所述Docker Swarm服务管理的集群中；即所述Web服务、所述数据库服务、所述文件共享服务、所述Jupyter Lab服务、所述反向代理服务均部署在所述DockerSwarm服务建立的Docker服务集群上，并且接入所述Docker Networking服务，实现网络互相连接功能；
所述用户终端与反向代理服务相连，并通过所述反向代理服务的路由转发规则，实现对Web服务、JupyterLab服务的访问，且所述用户终端以Web页面的形式与用户实现交互；
所述反向代理服务分别与Web服务、Jupyter Lab服务、用户终端相连；所述反向代理服务用于接收来自用户终端的请求，并根据不同的请求路径将请求转发至Web服务或Jupyter Lab服务；
所述Web服务分别与数据库服务、文件共享服务、Docker Swarm服务相连，Web服务用于提供用于注册账户、账户登录验证的Web页面并对监控Jupyter Lab服务的运行状态；
所述数据库服务用于存储用户的账户数据及用户的Jupyter Lab服务配置数据；
所述文件共享服务用于持久化存储用户数据文件以及用户的Jupyter Lab服务配置文件；则用户注册账户时，所述Web服务将创建的用户账户数据和Jupyter Lab服务配置数据存储到所述数据库服务，所述Web服务在所述文件共享服务创建用户数据文件夹和Jupyter Lab配置文件夹，并生成配置文件；且利用所述Docker服务中的容器技术，每个用户对应一个单独的所述Jupyter Lab服务，具有单独的Jupyter Lab编程空间，在该空间内具有全部权限，用户数据持久化地保存在所述文件共享服务中，使用户可利用的资源受到约束。
进一步地，所述Docker Swarm服务中，所述主节点配置为仅执行管理任务，或执行管理任务的同时接受运行任务，且当仅有一个Docker服务时，则该Docker服务被配置为执行管理任务的同时接受运行任务；即所述Docker Swarm服务建立的Docker集群，其中包含至少一个manager节点，可能没有worker节点也可能有一个或者多个worker节点，manager节点(主节点)既可以做所述Docker Swarm服务的管理节点，也可以接受所述Docker Swarm服务发布的任务；worker节点(子节点)只用于接受所述Docker Swarm服务发布的任务；在所述服务器资源不足的情况下，可以仅建立一个manager节点；在实际使用过程中，如果遇到计算资源不足时，可通过添加所述服务器资源，让其作为Worker节点加入Docker集群中，实现服务资源扩容的功能。
进一步地，所述Docker服务通过分别在各个服务器资源中安装Docker程序实现；所述Docker Networking服务是由Docker程序创建的overlay类型的网络对象。
进一步地，所述数据库服务中存储的用户的账户数据包括用户账号、密码、用户id值；所述用户的Jupyter Lab服务配置数据包括容器名称、CPU资源限制量、内存资源限制量、Jupyter Lab服务登录密钥、用户数据存储路径、Jupyter Lab配置文件存储路径。
进一步地，所述用户id值为随机产生的uuid值，且仅在用户账号注册时生成；所述CPU资源限制量与内存资源限制量用于约束单个用户的Jupyter Lab服务的资源使用量；即不同用户，其所述数据库服务中的记录不同，在所述文件共享服务生成的用户数据文件夹、Jupyter Lab配置文件夹以及其中的Jupyter Lab配置文件均不相同，依据其配置文件启动的所述Jupyter Lab服务也不相同，不同的所述Jupyter Lab服务之间互相独立；所述数据库服务中记录有用户可使用的所述服务器资源数量，包括CPU核心数，内存容量等；
所述Jupyter Lab服务登录密钥是随机产生的哈希值，用于完成所述Jupyter Lab服务的登录验证工作，所述用户数据存储路径、Jupyter Lab配置文件存储路径用于指定所述文件共享服务中的路径，该路径中添加了用户id值作为区分。
进一步地，所述文件共享服务中的文件数据被所述Jupyter Lab服务所在的容器挂载；所述文件共享服务中，用户的数据存储路径中包含用户id值，不同用户的数据存储路径不同，在用户的所述Jupyter Lab服务启动时挂载在该用户对应的容器中，则用户的Jupyter Lab服务启动时，通过Volume挂载的方式挂载所述文件共享服务中用户相应的用户数据文件夹、Jupyter Lab配置文件夹，实现了用户数据持久化存储的目标。
进一步地，所述用户终端位于用户的主机中，且通过浏览器访问所述反向代理服务并将账户验证请求发送至所述Web服务，将Jupyter Lab服务访问的请求发送至所述Jupyter Lab服务，所述反向代理服务与所述用户终端之间的请求具有相同的域名和端口，通过请求路径实现不同服务的区别和转发。
进一步地，所述反向代理服务通过对带有用户id值的字段的所述Jupyter Lab服务的请求地址进行正则匹配，将成功匹配到的请求地址，构造目标服务hostname，并将请求转发到该hostname名称的Jupyter Lab服务上；所述反向代理服务的上述转发过程以动态匹配的方式进行。
进一步地，所述Web服务通过Docker daemon API控制所述Docker Swarm服务，实现所述Jupyter Lab服务的自动化创建过程；用户登录到系统中之后，请求访问JupyterLab服务时，所述Jupyter Lab服务自动完成启动。
本发明与现有技术相比，具有以下的有益效果：
第一，Docker Swarm是Docker程序自带的集群管理程序，该程序具有Docker程序原生支持，占用资源少，配置灵活，功能强大的特点。在本发明的技术方案中，充分使用Docker Swarm作为集群管理程序，避免了使用Kubernetes等大型Docker集群管理框架带来的运行占用资源巨大，部署、配置、维护难度较大，操作复查的问题。
第二，本发明的技术方案中仅使用到了反向代理服务、web服务、数据库服务、文件共享服务、Docker Swarm服务，服务组件较少，除Web服务需要编程实现外，其他服务均有可用的开源程序，配置简单；并且这些服务均在Docker容器中运行，服务部署难度降低。
第三，本发明的技术方案利用Docker容器技术，每个用户对应一个单独的JupyterLab服务，具有单独的Jupyter Lab编程空间，在该空间内具有全部权限，用户数据持久化地保存在文件共享服务中，用户可利用的资源受到约束，满足了Jupyter Lab在多用户运行情况下独立的计算资源、数据存储区域、程序执行权限等互相隔离的运行环境需求。
第四，本发明的技术方案实现的web服务，通过调用Docker daemon API，控制Docker Swarm，实现Jupyter Lab服务的自动化创建，避免了人工进行后台配置、启动、维护操作，简化了工作量，提高了易用性。
第五，本发明的技术方案利用反向代理服务，将用户身份验证、Jupyter Lab服务资源访问，统一在了同一个域名下，无需单独记录Jupyter Lab服务实际的IP地址和端口，提高了用户使用的便利性。
综上可知，本发明的技术方案是以轻便、简单、占用资源少的Docker Swarm替换结构复杂的Kubernetes程序，编写Web服务实现对Jupyter Lab服务自动化启动、管理操作，并结合反向代理技术、共享文件存储技术，构成一个完整的、自动化的、互相隔离的、支持用户账户验证和Jupyter Lab服务访问的多用户开发系统，较好的解决了传统方案中存在的组件繁多，配置、部署、维护难度大，操作复杂的问题。
附图说明
图1是本发明的基于Docker的Jupyter Lab多用户远程开发系统的结构示意图。
图2是本发明的基于Docker的Jupyter Lab多用户远程开发系统的业务流程示意图。
具体实施方式
下面结合本发明的实施例对本发明作进一步的阐述和说明。
实施例：
实施例一：
一种基于Docker的Jupyter Lab多用户远程开发方法，其核心是以Docker Swarm程序实现对容器集群的管理，以文件共享技术实现Jupyter Lab服务中用户数据的持久化存储，利用Docker daemon API以程序的方式自动化地完成用户账户验证、用户数据文件区域划分、Jupyter Lab服务启动，以反向代理技术将用户账户验证服务和Jupyter Lab服务统一到同一个域名下；
本实施例的基于Docker的Jupyter Lab多用户远程开发方法中，以Docker Swarm实现对容器集群的管理，Docker Swarm为Docker自带组件，操作简便，配置简单，运行时占用资源少；以文件共享技术实现Jupyter Lab服务中用户数据的持久化存储，利用Dockerdaemon API以程序的方式自动化地完成用户账户验证、用户数据文件区域划分、JupyterLab服务启动等操作，该过程由程序自动执行，无需人工配置、启动服务，使用方便，且使用到的组件均有成熟、配置简单的开源程序，这些服务均在Docker容器中运行，服务部署难度降低；以反向代理技术将用户账户验证服务和Jupyter Lab服务统一到同一个域名下，用户仅需要访问一个域名，即可完成登录和Jupyter Lab服务访问的操作，提高了实用便利性；即基于Docker的容器化技术，Docker Swarm容器集群管理技术，结合反向代理技术、共享文件存储技术，并利用Docker daemon API开发用户认证及服务资源调度程序，实现互相隔离的多用户Jupyter Lab运行环境，解决了传统方案中组件繁多，配置、部署、维护难度较大，较为复杂的问题。
实施例二
如图1所示，一种基于Docker的Jupyter Lab多用户远程开发系统，包括硬件层、服务层、应用层；硬件层包括基础网络连接和若干服务器资源；服务层包括若干Docker服务、Docker Swarm服务、Docker Networking服务、反向代理服务、Web服务、数据库服务、文件共享服务、若干Jupyter Lab服务；应用层包括若干用户终端。
具体的，本实施例中，基础网络连接与一个或者多个服务器资源相连，服务器资源利用基础网络连接实现网络互相访问；Docker服务安装于服务器资源中，使服务器资源成为Docker节点。
本实施例中具体是在Docker服务中构建Docker Swarm服务和Docker Networking服务；Docker Swarm服务将Docker服务组织成为Docker服务的集群；Docker Networking服务实现Docker Swarm服务建立的Docker服务集群中各个服务、容器之间跨宿主机的网络连接，并且其服务、容器的名称可作为hostname实现网络连接。具体的，本实施例中，DockerSwarm服务利用Docker程序中自带的Swarm程序作为Docker集群的管理程序。
其中，Docker Swarm服务建立的Docker集群中包含至少一个manager节点，且可能没有worker节点也可能有一个或者多个worker节点，manager节点既可以做Docker Swarm服务的管理节点，也可以接受Docker Swarm服务发布的任务；worker节点只用于接受Docker Swarm服务发布的任务；在服务器资源不足的情况下，可以仅建立一个manager节点；在实际使用过程中，如果遇到计算资源不足时，可通过添加服务器资源，让其作为Worker节点加入Docker集群中，实现服务资源扩容的功能。
Web服务、数据库服务、文件共享服务、Jupyter Lab服务、反向代理服务均部署在Docker Swarm服务建立的Docker服务集群上，并且接入Docker Networking服务，实现网络互相连接功能。
反向代理服务与用户终端、Web服务和Jupyter Lab服务相连；用户终端位于用户的主机中，通过浏览器访问反向代理服务，具体将账户验证请求发送至Web服务，将JupyterLab服务访问的请求发送至Jupyter Lab服务；反向代理服务与用户终端之间的请求具有相同的域名和端口，通过请求路径实现不同服务的区别和转发。
作为优选，反向代理服务通过对带有用户id字段的Jupyter Lab服务的请求地址进行正则匹配，将成功匹配到的请求地址，构造目标服务hostname，并将请求转发到该hostname名称的Jupyter Lab服务上；反向代理服务的上述转发过程以动态匹配的方式进行，并不做固定化的绑定。
如来自用户终端的请求中，其请求的URL路径为“/”时，则转发至Web服务，端口号为5000，如果请求的URL路径为“/jupyter-[userid]”，则转发至hostname为“jupyter-[userid]”的JupyterLab服务中，端口号为8888；其中“[userid]”代表用户id值，来自不同的用户终端的请求，其实际值也不相同，将请求“/jupyter-[userid]”中的userid数据取出，构造为“jupyter-[userid]”字段，由于JupyterLab服务处于Docker Networking服务中，因此“jupyter-[userid]”既是容器名称，也是容器的hostname名称，进而实现了通过不同用户的“/jupyter-[userid]”URL路径，访问不同用户所对应的JupyterLab服务的功能；用户终端仅需要访问固定的外部IP及端口。
Web服务与数据库服务、文件共享服务和Docker Swarm服务相连；用户注册账户时，Web服务将创建的用户账户数据和Jupyter Lab服务配置数据存储到数据库服务，Web服务在文件共享服务创建用户数据文件夹和Jupyter Lab配置文件夹，并生成配置文件，并通过在路径中添加以用户id命名的路径实现不同用户之间的区分；用户登录时，Web服务从数据库服务从查询数据并进行校验工作，校验成功后，该用户即可访问属于该用户的JupyterLab服务；Web服务通过Docker daemon API控制Docker Swarm服务，实现Jupyter Lab服务的自动化创建过程；挂载该用户在文件共享服务中的用户数据文件夹和Jupyter Lab配置文件夹，加载其中的Jupyter Lab配置文件，启动该用户的Jupyter Lab服务；Jupyter Lab服务通过反向代理服务的转发，与用户终端建立网络连接，实现用户在Jupyter Lab服务中交互式编程的功能，且用户登录到系统中之后，请求访问Jupyter Lab服务时，Jupyter Lab服务自动完成启动。
具体的，本实施例中，不同用户，其数据库服务中的记录不同，在文件共享服务生成的用户数据文件夹、Jupyter Lab配置文件夹以及其中的Jupyter Lab配置文件均不相同，依据其配置文件启动的Jupyter Lab服务也不相同，不同的Jupyter Lab服务之间互相独立；数据库服务中记录有用户可使用的服务器资源数量，包括CPU核心数，内存容量。
具体的，Jupyter Lab服务通过将服务命名为带有用户id字段名称，实现不同用户之间的Jupyter Lab服务区分；Web服务在文件共享服务中创建Jupyter Lab配置文件时，将该用户的“c.NotebookApp.base_url”项目配置为包含用户id的请求路径，将“c.NotebookApp.token”项目配置为随机密码，并存储于数据库服务中用户的Jupyter Lab服务配置数据中；该随机密码在用户终端请求Web服务并成功登录后，连同该用户的Jupyter Lab服务的请求地址返回给用户终端，用户终端利用这些信息向反向代理服务发起请求；用户的随机密码不正确，或者和Jupyter Lab服务的请求地址不匹配时，JupyterLab服务无法通过验证，不能建立开发环境连接，无法使用Jupyter Lab服务，为用户的Jupyter Lab服务提供了安全保障；反向代理服务通过带有用户id字段的服务名称，将Jupyter Lab服务转发给对应的用户；系统中Jupyter Lab服务和注册的账户相对应。
本实施例中，利用Docker服务中的容器技术，每个用户对应一个单独的JupyterLab服务，具有单独的Jupyter Lab编程空间，在该空间内具有全部权限，用户数据持久化地保存在文件共享服务中，用户可利用的资源受到约束。用户的Jupyter Lab服务启动时，通过Volume挂载的方式挂载文件共享服务中用户相应的用户数据文件夹、Jupyter Lab配置文件夹，实现了用户数据持久化存储的目标。
如图2所示为本系统的业务流程示意，用户使用Jupyter Lab服务的流程主要为：用户请求登录页面，登录请求通过反向代理服务转发给Web服务，经过读取数据库用户数据比对后，完成校验过程，创建用户数据文件存储区域以及Jupyter Lab配置文件存储区域，创建Jupyter Lab配置文件，调用Docker daemon API，控制Docker Swarm，创建容器，挂载用户数据文件存储区域以及Jupyter Lab配置文件存储区域，启动Jupyter Lab服务，Jupyter Lab服务的页面经过反向代理服务转发给用户。
具体说明如下，当用户通过用户终端使用本系统时，先访问登录页面，认证通过后自动跳转至Jupyter Lab编程页面。
其中，用户初次使用Web服务时，需注册账户，注册成功后将账户信息以及初始化后的Jupyter Lab服务配置数据存储至数据库服务中。
当用户初次使用时，完成注册工作，并登录到系统中时，Web服务读取数据库服务中的Jupyter Lab服务配置数据，按照其中的用户数据存储路径、Jupyter Lab配置文件存储路径在文件共享服务中创建该用户的数据存储区域、Jupyter Lab服务配置文件存储区域及配置文件；Web服务调用Docker daemon API，控制Docker Swarm，按照数据库服务中的Jupyter Lab服务配置数据中的容器名称、CPU资源限制量、内存资源限制量，创建容器，并挂载文件共享服务中创建的该用户的数据存储区域和Jupyter Lab服务配置文件存储区域，运行Jupyter Lab程序，实现Jupyter Lab服务的启动。
Jupyter Lab服务配置文件中，将“c.NotebookApp.base_url”配置项的值设置为“/jupyter-[userid]”,“[userid]”代表用户id值，“c.NotebookApp.port”配置项的值设置为8888，利用这两项设置，既起到区分不同用户的Jupyter Lab服务的作用，同时也便于反向代理服务进行URL识别并做转发。
Jupyter Lab服务配置文件中，将“c.NotebookApp.ip”配置项的值设置为“*”,将“c.NotebookApp.tornado_settings”配置项的值设置为“{'headers':{'Content-Security-Policy':""}}”,将“c.NotebookApp.allow_remote_access”配置项的值设置为“True”,将“c.NotebookApp.allow_origin”配置项的值设置为“*”,将“c.NotebookApp.allow_credentials”配置项的值设置为“True”,利用这五项设置实现跨域访问Jupyter Lab服务的功能。
Jupyter Lab服务配置文件中，将“c.NotebookApp.token”配置项的值设置为Jupyter Lab服务配置数据中的Jupyter Lab服务登录密钥，利用该项配置，实现JupyterLab服务具有密钥验证的安全防护功能，提高用户环境的安全性。
Jupyter Lab服务启动后，Web服务将该服务的URL路径和登录密钥返回，并通过方向代理服务转发给用户终端，用户终端利用获取到的URL路径和登录密钥，发送URL请求，登录到Jupyter Lab服务提供的研究页面，进行后续的编程工作。
用户通过用户终端，利用Jupyter Lab服务提供的研究页面中的“终止”菜单选项，即可停止Jupyter Lab服务的运行，Jupyter Lab服务所在的容器被终止运行并删除，其占用的硬件资源被释放，但文件共享服务中的数据存储区域、Jupyter Lab服务配置文件存储区域以及配置文件得到保留；Jupyter Lab服务停止后其所在的容器资源立即被删除，因此系统中不存在处于停止状态的Jupyter Lab服务容器。
当用户再次登录到系统中时，Web服务读取数据库服务中的Jupyter Lab服务配置数据，获取其中的容器名称数据，调用Docker daemon API，获取名称为“jupyter-[userid]”的容器的运行状态，如果没有查询到该容器，则启动Jupyter Lab服务，文件共享服务中之前创建的该用户的数据存储区域、Jupyter Lab服务配置文件存储区域不变，但配置文件中的登录密钥数据更新为新的随机产生哈希值；如果查询到该容器处于运行状态，Web服务直接返回Jupyter Lab服务的URL路径和登录密钥。
实施例三
本实施例中将具体举例说明上述实施例一的系统的一种搭建过程，具体如下：
首先搭建系统的硬件层。
准备三台服务器，并且三台服务器的网络能够互相连接，其中manager节点具有外网IP，本实施例中，其配置如下表所示：
节点 CPU核心数 RAM容量 内网IP地址 外网IP地址
Manager 8 16GB 192.168.195.190 具有
Worker1 8 16GB 192.168.195.191
Worker2 8 16GB 192.168.195.192
在硬件层搭建完成的基础上，开始搭建服务层。
首先为每个节点安装Docker程序。在Manager节点上，使用“docker swarm init--advertise-addr 192.168.195.190::2375”，将该节点设置为Docker Swarm集群的Manager节点；在Worker1、Worker2节点中，使用“docker swarm join--token xxxxxx192.168.195.190:2375”命令，将节点添加到Docker Swarm集群众，其中“xxxxxx”代表Docker Swarm集群的密钥；在系统使用过程中，如果遇到计算资源利用率较高的情况，可根据上述操作，添加Worker节点，增加计算资源。
在Manager节点上，使用“docker network create--driver overlay--optencrypted jupyter-swarm”命令，创建名称为“jupyter-swarm”的Docker Networking，该网络工作在overlay模式下，能够支持Docker集群中跨宿主机网络通信的需求，并且自带DNS解析功能，可以通过容器名称、服务名称访问相应的服务。
在以上部署工作完成的基础上，部署反向代理服务、Web服务、数据库服务、文件共享服务、Jupyter Lab服务，这些服务通过Dockerfile文件的形式进行封装并build为镜像，存储在Manager节点中，集群中其他节点可以利用这些镜像启动服务。
反向代理服务利用Nginx软件实现，从Docker Hub中拉取Nginx:latest镜像，在Manager节点启动反向代理服务，服务名称为“nginx”；该服务添加到“jupyter-swarm”Docker Networking中；该服务启动时需要配置Nginx代理转发配置文件default.conf，其主要设置以下内容：
Figure BDA0002747593290000171
Figure BDA0002747593290000181
配置中指定Nginx服务所在的物理机种，来自80端口，域名为“test.jupyter.com”的请求，对于请求路径为“/”的请求，转发至名称为“webserver”，端口为5000的Web服务中。对于请求路径为“/jupyter-[0-9a-z-]{36}”的请求，其特征是以“/jupyter-”为开头，由0到9、a到z的小写字母以及“-”组成的36个字符串作为后缀，其中该字符串后缀表示用户id；这一类型的请求表示用户的Jupyter Lab服务请求，Nginx程序利用正则表达式规则识别这一类型的请求，并剔除开头的“/”字符，的并转发至“jupyter-swarm”Docker Networking中，hostname名称为“jupyter-[0-9a-z-]{36}”，端口为9999，的Jupyter Lab服务上，由于请求的路径中带有用户id信息，Jupyter Lab服务的hostname也带有用户id信息，两者结合可以很好地完成不同用户的Jupyter Lab服务；resolver 127.0.0.11配置项指定了Nginx使用“jupyter-swarm”Docker Networking中的DNS解析服务地址。
数据库服务，选用MongoDB数据库实现，从Docker Hub中拉取mongo:latest镜像，在Manager节点启动数据库服务，服务名称为“mongodb”；该服务添加到“jupyter-swarm”Docker Networking中；该服务启动时需要配置MongoDB数据库的配置文件default.conf，其配置内容主要有：
Figure BDA0002747593290000191
Figure BDA0002747593290000201
配置文件中，指定数据文件和日志文件的路径，指定缓存数据的内存占用为4GB，配置服务端口号为27017，支持外部链接，指定需要通过用户身份认证连接数据库，以非后台方式启动程序；数据文件和日志文件的路径在该服务启动时，挂载到宿主机中数据存储磁盘中，以实现数据持久化的目的。
文件共享服务，选用nfs-utils和rpcbind程序实现，其中nfs-utils负责管理共享文件数据，rpcbind负责端口信息同步，从Docker Hub中拉取centos:latest镜像，在Manager节点启动文件共享服务，服务名称为“nfs”；该服务添加到“jupyter-swarm”DockerNetworking中；该服务启动时需要配置nfs程序的配置文件/etc/exports，其配置内容为：/userdata 192.168.195.190/24，该配置指定了被共享的文件夹路径，服务启动时，将共享文件夹路径挂载到宿主机中数据存储磁盘中，以实现数据持久化的目的。
Web服务使用Dockerfile文件，通过build封装为image镜像，并在Manager节点启动该服务，服务名称为“webserver”，服务端口号为5000。主要实现用户账户验证、JupyterLab配置文件生成和Jupyter Lab服务管理的工作；该服务采用Python语言实现，使用flask框架并结合flask_login组件实现用户账户验证工作；用户账户验证过程中，需要用户注册账户，其注册信息包括账号、密码、用户id值等信息，该程序将注册信息保存至数据库服务“mongodb”中。使用os组件，创建用户的数据存储文件夹和Jupyter Lab服务配置文件文件夹，并在配置文件文件夹中创建Jupyter Lab配置文件，并使用volume挂载的方式映射到文件共享服务中的数据存储区域，同时路径中包含用户id信息以便于区分不同用户的数据。例如：
用户id为[userid]；
用户数据存储文件夹为/userdata/[userid]/notebook；
Jupyter Lab服务配置文件文件夹/userdata/[userid]/.jupyter；
配置文件路径为/userdata/[userid]/.jupyter/jupyter_notebook_config.py。
使用Docker daemon API实现对Docker Swarm集群进行Jupyter Lab服务管理的工作，包括启动、停止、查看状态等操作。Jupyter Lab服务管理过程时，启动容器时需要初始化Jupyter Lab服务配置信息，包括容器名称、CPU资源限制量、内存资源限制量、JupyterLab服务登录密钥、用户数据存储路径、Jupyter Lab配置文件存储路径，该用户的JupyterLab服务配置信息保存至数据库服务“mongodb”中。
Jupyter Lab服务，选用Jupyter Lab程序实现，从Docker Hub中拉取jupyter:latest镜像，在Manager节点启动数据库服务，服务名称为“jupyter-[userid]”，其中“[userid]”为用户id，；该服务添加到“jupyter-swarm”Docker Networking中，在该网络中的其他容器，可以使用“jupyter-[userid]”作为hostname，访问其中的Jupyter Lab服务，以此实现区分不同用户的Jupyter Lab服务的需求；
该服务启动时，通过volume挂载的方式，将该用户的数据文件夹、配置文件夹和配置文件，挂载到容器中；用户在Jupyter Lab服务中创建的文件，将会被存储在文件共享服务中。其挂载的映射关系为：
文件共享服务中/userdata/[userid]/notebook文件夹挂载到容器中/home/notebook文件夹；
文件共享服务中/userdata/[userid]/.jupyter文件夹挂载到容器中/root/.jupyter文件夹；
Jupyter Lab服务启动时，将根据Web服务在文件共享服务中创建的配置文件jupyter_notebook_config.py启动服务，其配置文件的内容主要有：
Figure BDA0002747593290000221
以上即本实施例的系统的搭建过程，实际中相应参数等可根据具体情况设定。
可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。

Claims (9)

1.基于Docker的Jupyter Lab多用户远程开发系统，其特征在于，以Docker Swarm程序实现对容器集群的管理，以文件共享技术实现Jupyter Lab服务中用户数据的持久化存储，利用Docker daemon API以程序的方式自动化地完成用户账户验证、用户数据文件区域划分以及Jupyter Lab服务启动，以反向代理技术将用户账户验证服务和Jupyter Lab服务统一到同一个域名下；所述开发系统包括硬件层、服务层以及应用层；
所述硬件层包括基础网络连接和若干服务器资源；所述服务层包括若干Docker服务、Docker Swarm服务、Docker Networking服务、反向代理服务、Web服务、数据库服务、文件共享服务以及若干Jupyter Lab服务；所述应用层包括若干用户终端；
所述基础网络连接与服务器资源相连并为其提供网络连接环境；所述服务器资源利用所述基础网络连接实现网络互相访问；
所述Docker服务与服务器资源一一对应并部署于服务器资源中，使所述服务器资源成为Docker节点；
所述Docker Swarm服务为由所述若干Docker服务组成的集群，且所述若干Docker服务中至少有一个Docker服务为执行管理任务的主节点，其余Docker服务为接受运行任务的子节点；所述Docker Swarm服务用于接受来自所述Web服务的控制请求，并负责启动、关闭以及获取所述Jupyter Lab服务；
所述Docker Networking服务为运行在所述Docker服务中的容器服务，用于为DockerSwarm服务管理的集群提供内部的网络连接服务；
所述反向代理服务、Web服务、数据库服务、文件共享服务以及若干Jupyter Lab服务均以容器的形式运行在所述Docker Swarm服务管理的集群中；
所述用户终端与反向代理服务相连，并通过所述反向代理服务的路由转发规则，实现对Web服务以及JupyterLab服务的访问，且所述用户终端以Web页面的形式与用户实现交互；
所述反向代理服务分别与Web服务、Jupyter Lab服务以及用户终端相连；所述反向代理服务用于接收来自用户终端的请求，并根据不同的请求路径将请求转发至Web服务或Jupyter Lab服务；
所述Web服务分别与数据库服务、文件共享服务以及Docker Swarm服务相连，Web服务用于提供用于注册账户以及账户登录验证的Web页面并对监控Jupyter Lab服务的运行状态；
所述数据库服务用于存储用户的账户数据及用户的Jupyter Lab服务配置数据；
所述文件共享服务用于持久化存储用户数据文件以及用户的Jupyter Lab服务配置文件。
2.根据权利要求1所述的基于Docker的Jupyter Lab多用户远程开发系统，其特征在于，所述Docker Swarm服务中，所述主节点配置为仅执行管理任务，或执行管理任务的同时接受运行任务，且当仅有一个Docker服务时，则该Docker服务被配置为执行管理任务的同时接受运行任务。
3.根据权利要求1所述的基于Docker的Jupyter Lab多用户远程开发系统，其特征在于，所述Docker服务通过分别在各个服务器资源中安装Docker程序实现；所述DockerNetworking服务是由Docker程序创建的overlay类型的网络对象。
4.根据权利要求1所述的基于Docker的Jupyter Lab多用户远程开发系统，其特征在于，所述数据库服务中存储的用户的账户数据包括用户账号、密码以及用户id值；所述用户的Jupyter Lab服务配置数据包括容器名称、CPU资源限制量、内存资源限制量、JupyterLab服务登录密钥、用户数据存储路径以及Jupyter Lab配置文件存储路径。
5.根据权利要求4所述的基于Docker的Jupyter Lab多用户远程开发系统，其特征在于，所述用户id值为随机产生的uuid值，且仅在用户账号注册时生成；所述CPU资源限制量与内存资源限制量用于约束单个用户的Jupyter Lab服务的资源使用量；所述Jupyter Lab服务登录密钥是随机产生的哈希值，用于完成所述Jupyter Lab服务的登录验证工作，所述用户数据存储路径以及Jupyter Lab配置文件存储路径用于指定所述文件共享服务中的路径，该路径中添加了用户id值作为区分。
6.根据权利要求4所述的基于Docker的Jupyter Lab多用户远程开发系统，其特征在于，所述文件共享服务中的文件数据被所述Jupyter Lab服务所在的容器挂载；所述文件共享服务中，用户的数据存储路径中包含用户id值，不同用户的数据存储路径不同，在用户的所述Jupyter Lab服务启动时挂载在该用户对应的容器中。
7.根据权利要求4所述的基于Docker的Jupyter Lab多用户远程开发系统，其特征在于，所述用户终端位于用户的主机中，且通过浏览器访问所述反向代理服务并将账户验证请求发送至所述Web服务，将Jupyter Lab服务访问的请求发送至所述Jupyter Lab服务，所述反向代理服务与所述用户终端之间的请求具有相同的域名和端口，通过请求路径实现不同服务的区别和转发。
8.根据权利要求7所述的基于Docker的Jupyter Lab多用户远程开发系统，其特征在于，所述反向代理服务通过对带有用户id值的字段的所述Jupyter Lab服务的请求地址进行正则匹配，将成功匹配到的请求地址，构造目标服务hostname，并将请求转发到该hostname名称的Jupyter Lab服务上；所述反向代理服务的上述转发过程以动态匹配的方式进行。
9.根据权利要求1-8中任一所述的基于Docker的Jupyter Lab多用户远程开发系统，其特征在于，所述Web服务通过Docker daemon API控制所述Docker Swarm服务，实现所述Jupyter Lab服务的自动化创建过程；用户登录到系统中之后，请求访问Jupyter Lab服务时，所述Jupyter Lab服务自动完成启动。
CN202011172063.7A 2020-10-28 2020-10-28 基于Docker的Jupyter Lab多用户远程开发方法及系统 Active CN112256399B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011172063.7A CN112256399B (zh) 2020-10-28 2020-10-28 基于Docker的Jupyter Lab多用户远程开发方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011172063.7A CN112256399B (zh) 2020-10-28 2020-10-28 基于Docker的Jupyter Lab多用户远程开发方法及系统

Publications (2)

Publication Number Publication Date
CN112256399A CN112256399A (zh) 2021-01-22
CN112256399B true CN112256399B (zh) 2022-08-19

Family

ID=74262776

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011172063.7A Active CN112256399B (zh) 2020-10-28 2020-10-28 基于Docker的Jupyter Lab多用户远程开发方法及系统

Country Status (1)

Country Link
CN (1) CN112256399B (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112989253A (zh) * 2021-04-02 2021-06-18 南昌工程学院 一种基于JupyterHub的水库优化调度实践教学平台的搭建方法
CN113742716B (zh) * 2021-11-04 2022-02-08 腾讯科技（深圳）有限公司 代码运行方法、装置、电子设备、存储介质和程序产品
CN114296863B (zh) * 2021-11-08 2024-08-27 北京思特奇信息技术股份有限公司 一种优化Jupyter开发环境启动速度的方法及系统、电子设备、存储介质
CN114116684B (zh) * 2022-01-27 2022-05-24 中国传媒大学 基于Docker容器化的深度学习大模型与大数据集版本管理方法
CN114816571B (zh) * 2022-04-15 2023-06-16 西安广和通无线通信有限公司 外挂闪存的方法、装置、设备及存储介质
CN117785266B (zh) * 2023-12-26 2024-09-20 无锡雪浪数制科技有限公司 应用程序的自动发布方法、调度服务器及低代码平台

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106844000A (zh) * 2016-12-21 2017-06-13 北京大学 一种多用户环境下利用浏览器访问Linux容器集群的方法和装置
CN109918359A (zh) * 2019-01-18 2019-06-21 华南理工大学 基于swarm的数据库服务持久化方法及系统
CN110493175A (zh) * 2019-07-01 2019-11-22 联想(北京)有限公司 一种信息处理方法、电子设备和存储介质
CN111158745A (zh) * 2019-12-30 2020-05-15 山东浪潮商用系统有限公司 一种基于Docker的数据处理平台
CN111708595A (zh) * 2020-06-11 2020-09-25 湖北美和易思教育科技有限公司 一种基于可视化界面的远程交互协作方法及装置
CN111726399A (zh) * 2020-06-08 2020-09-29 中国工商银行股份有限公司 Docker容器安全访问方法及装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10002163B2 (en) * 2016-08-18 2018-06-19 Palantir Technologies Inc. Managing sharable cell-based analytical notebooks
CN107395762A (zh) * 2017-08-30 2017-11-24 四川长虹电器股份有限公司 一种基于Docker容器的应用服务访问系统及方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106844000A (zh) * 2016-12-21 2017-06-13 北京大学 一种多用户环境下利用浏览器访问Linux容器集群的方法和装置
CN109918359A (zh) * 2019-01-18 2019-06-21 华南理工大学 基于swarm的数据库服务持久化方法及系统
CN110493175A (zh) * 2019-07-01 2019-11-22 联想(北京)有限公司 一种信息处理方法、电子设备和存储介质
CN111158745A (zh) * 2019-12-30 2020-05-15 山东浪潮商用系统有限公司 一种基于Docker的数据处理平台
CN111726399A (zh) * 2020-06-08 2020-09-29 中国工商银行股份有限公司 Docker容器安全访问方法及装置
CN111708595A (zh) * 2020-06-11 2020-09-25 湖北美和易思教育科技有限公司 一种基于可视化界面的远程交互协作方法及装置

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
[docker]Swarm、SwarmKit、Swarm mode 对比;寻觅神迹;《https://blog.csdn.net/halcyonbaby/article/details/52037091》;20160726;1-3 *
Andrea Zonca.Deploy scalable Jupyterhub on Docker Swarm mode.《https://zonca.dev/2017/10/scalable-jupyterhub-docker-swarm-mode.html》.2017,1-11. *
CyberGIS-Jupyter for Reproducible and Scalable Geospatial Analytics;Dandong Yin等;《Concurrency and computation: practice and experience》;20181130;第31卷;1-14 *
Deploy scalable Jupyterhub on Docker Swarm mode;Andrea Zonca;《https://zonca.dev/2017/10/scalable-jupyterhub-docker-swarm-mode.html》;20171026;1-11 *

Also Published As

Publication number Publication date
CN112256399A (zh) 2021-01-22

Similar Documents

Publication Publication Date Title
CN112256399B (zh) 基于Docker的Jupyter Lab多用户远程开发方法及系统
CN109067828B (zh) 基于Kubernetes和OpenStack容器云平台多集群构建方法、介质、设备
US11496523B2 (en) Policy engine for cloud platform
US10469314B2 (en) API gateway for network policy and configuration management with public cloud
CN107181808B (zh) 一种私有云系统及运行方法
CN109067827B (zh) 基于Kubernetes和OpenStack容器云平台多租户构建方法、介质、设备
US8290998B2 (en) Systems and methods for generating cloud computing landscapes
CA2543753C (en) Method and system for accessing and managing virtual machines
US9569266B2 (en) Apparatus, method, and computer program product for solution provisioning
WO2017157156A1 (zh) 一种用户请求的处理方法和装置
CN115269184B (zh) 函数即服务（faas）执行分配器
US11425054B1 (en) User-configured multi-location service deployment and scaling
US9858105B1 (en) Service for managing custom virtual machine images
CN113301116B (zh) 微服务应用跨网络通信方法、装置、系统及设备
CN107547250A (zh) 在云计算管理平台中部署数据库的方法和装置
US8250183B1 (en) System and method for pre-installing of virtual server files
JP2021518018A (ja) 関数チェックポイントを使用したサービスハブのための関数移植性
EP4026014B1 (en) Enabling federated query access to heterogeneous data sources
CN113821268B (zh) 一种与OpenStack Neutron融合的Kubernetes网络插件方法
US10333901B1 (en) Policy based data aggregation
CN112073448B (zh) 一种双系统终端的服务隔离方法和装置
CN112099913A (zh) 一种基于OpenStack实现虚拟机安全隔离的方法
CN115086166A (zh) 计算系统、容器网络配置方法及存储介质
US11765244B1 (en) Latency-based service discovery and routing for multi-location service-oriented applications
CN113992657A (zh) 一种基于云平台的共享存储的搭建方法、设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant