mirror of
https://github.com/jupyterhub/the-littlest-jupyterhub.git
synced 2025-12-18 21:54:05 +08:00
streamlining the whentouse page
This commit is contained in:
@@ -84,6 +84,7 @@ Topic guides provide in-depth explanations of specific topics.
|
|||||||
.. toctree::
|
.. toctree::
|
||||||
:titlesonly:
|
:titlesonly:
|
||||||
|
|
||||||
|
topic/whentouse
|
||||||
topic/requirements
|
topic/requirements
|
||||||
topic/security
|
topic/security
|
||||||
topic/customizing-installer
|
topic/customizing-installer
|
||||||
|
|||||||
@@ -4,79 +4,31 @@
|
|||||||
When to use The Littlest JupyterHub
|
When to use The Littlest JupyterHub
|
||||||
===================================
|
===================================
|
||||||
|
|
||||||
The Littlest JupyterHub allows you to deploy a JupyterHub serving user sessions
|
This page is a brief guide to determining whether to use The Littlest JupyterHub
|
||||||
on a single VM (or your own hardware). The Zero to JupyterHub guide allows you
|
(TLJH) or `Zero to JupyterHub for Kubernetes <https://zero-to-jupyterhub.readthedocs.io/en/latest/>`_ (Z2JH).
|
||||||
to deploy JupyterHub on Kubernetes, making it much more scalable.
|
|
||||||
This page is a brief guide to determining which is best for your use-case.
|
|
||||||
Many of these ideas were first laid out in a
|
Many of these ideas were first laid out in a
|
||||||
`blog post announcing TLJH <http://words.yuvi.in/post/the-littlest-jupyterhub/>`_.
|
`blog post announcing TLJH <http://words.yuvi.in/post/the-littlest-jupyterhub/>`_.
|
||||||
|
|
||||||
The Littlest JupyterHub
|
**The Littlest JupyterHub (TLJH)** (`link <https://the-littlest-jupyterhub.readthedocs.io/en/latest/>`_) is an opinionated and pre-configured distribution
|
||||||
-----------------------
|
to deploy a JupyterHub on a **single machine** (in the cloud or on your own hardware).
|
||||||
|
It is designed to be a more lightweight and maintainable solution
|
||||||
|
for use-cases where size, scalability, and cost-savings are not a huge concern.
|
||||||
|
|
||||||
The Littlest JupyterHub (TLJH) is an opinionated and pre-configured distribution
|
**Zero to JupyterHub on Kubernetes** (`link <https://zero-to-jupyterhub.readthedocs.io/en/latest/>`_) allows you
|
||||||
to deploy a JupyterHub on a single virtual machine (or your own hardware).
|
to deploy JupyterHub on **Kubernetes**. This allows JupyterHub to scale to many thousands
|
||||||
It is designed to be a more lightweight, flexible, and maintainable solution
|
of users, to flexibly grow/shrink the size of resources it needs, and to use
|
||||||
for use-cases where scalability and cost-savings are not a huge concern.
|
container technology in administering user sessions.
|
||||||
|
|
||||||
When to use TLJH
|
When to use TLJH vs. Z2JH
|
||||||
^^^^^^^^^^^^^^^^
|
=========================
|
||||||
|
|
||||||
* You want to provide easy access to a shared computational resource (CPU, RAM, data, etc)
|
The choice between TLJH and Z2JH ultimately comes down to only a few questoins:
|
||||||
* You only need to support up to ~100 people
|
|
||||||
* You aren't concerned about `over-provisioning your cluster <https://community.spiceworks.com/cloud/article/overprovisioning-servers-iaas>`_.
|
|
||||||
* You don't need production-level security promises for your deployment
|
|
||||||
|
|
||||||
TLJH main benefits
|
1. Do you want your hub and all users to live on a **single, larger machine** vs. spreading users on a **cluster of smaller machines** that are scaled up or down?
|
||||||
^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
* Simpler to deploy on many kinds of cloud services
|
* If you can use a single machine, we recommend **The Littlest JupyterHub**.
|
||||||
* Faster to set up and tear down
|
* If you wish to use multiple machines, we recommend **Zero to JupyterHub for Kubernetes**.
|
||||||
* Allows administrators to quickly update user environments
|
2. Do you **need to use container technology**?
|
||||||
* Is fairly simple in its technical makeup, reducing accidental complexity
|
|
||||||
* Supports any jupyter-based user workflows
|
|
||||||
|
|
||||||
TLJH main drawbacks
|
* If no, we recommend **The Littlest JupyterHub**.
|
||||||
^^^^^^^^^^^^^^^^^^^
|
* If yes, we recommend **Zero to JupyterHub for Kubernetes**.
|
||||||
|
|
||||||
The Littlest JupyterHub is more lightweight and easy to deploy, which makes it poorly suited for
|
|
||||||
large userbases or more fine-grained control over the computational resources
|
|
||||||
your deployment uses. It also doesn't use containers (both a good and a bad thing)
|
|
||||||
which means it does not support some security and networking features that some
|
|
||||||
may find useful.
|
|
||||||
|
|
||||||
|
|
||||||
Zero to JupyterHub for Kubernetes
|
|
||||||
---------------------------------
|
|
||||||
|
|
||||||
The other main distribution for deploying JupyterHub is the
|
|
||||||
`Zero to JupyterHub on Kubernetes <https://z2jh.jupyter.org>`_ guide.
|
|
||||||
While Kubernetes is fantastic
|
|
||||||
for managing complex web infrastructure, sometimes it is a more complex
|
|
||||||
solution than needed. These points should help you decide if this is is the
|
|
||||||
tool for your use-case.
|
|
||||||
|
|
||||||
When to use Z2JH
|
|
||||||
^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
* You may have more than ~100 users at a time
|
|
||||||
* You do want to avoid over-provisioning your cluster
|
|
||||||
* You want the security features of containers and Kubernetes
|
|
||||||
* You want a more "production-ready" JupyterHub deployment
|
|
||||||
|
|
||||||
Z2JH main benefits
|
|
||||||
^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
* Runs on Kubernetes
|
|
||||||
* Scalable up to thousands of users
|
|
||||||
* More cost-effective at this scale (because you can automatically scale up/down the resources used)
|
|
||||||
* Uses container technology, and all the benefits that come with this
|
|
||||||
* Supports any user workflow that can run via a browser (Jupyter, RStudio, OpenRefine, etc)
|
|
||||||
|
|
||||||
Z2JH main drawbacks
|
|
||||||
^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
JupyterHub on Kubernetes is more complex to deploy because Kubernetes is more
|
|
||||||
complex. In addition, a more limited number of cloud providers offer
|
|
||||||
one-click solutions for running Kubernetes. This may provide more technical
|
|
||||||
overhead than you wish.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user