Jupyter Blog - Kubernetes

The superheroes and the magic wand

2020-03-19T18:23:00+00:00

This is the first of a series of posts describing tools in the JupyterHub ecosystem, written by our wonderful Contributor in Residence, Georgiana. For our first post, we’ll share some lore of JupyterHub, and tell you a story of how it all began…

In a place far, far away, on a planet called Jupyter, magic happens every day. This land is special because it’s full of magical tools with all kind of powers, devoted to one common purpose: to help people. Everyone sympathizing with this goal either advocates, uses, or cares for these tools. So, in the blink of an eye, these people with sometimes nothing else in common than the same drive to help others, gathered together and formed a community.

This special group is known in the galaxy as “The Jovyans*” and new recruits join every day.* 🚀

This image was created by Scriberia for The Turing Way community and is used under a CC-BY licence. Zenodo record.

But somebody needed to take care of these magical tools. So, the first Jovyans decided that from then on, they will become tool-keepers. Because their greatest responsibility was to teach new Jovyans how to use the magic, shortly after, they created a set of guiding laws. Some call this “the Documentation”.

The magic wand

One greatly cherished tool on planet Jupyter is the magical wand. This wand’s very special power is to help people work together as a team and find solutions to important problems.

The wand is called “JupyterHub”.

But the wand is of vast complexity and because of this, so are the guiding laws that control it.

As a consequence, people trying to benefit from the magic of JupyterHub, spent a lot of time reading and understanding the instructions.

The superheros

The tool-keepers noticed that most of the people coming to planet Jupyter to become Jovyans were from a big city in the cloud 🌤 called Kubernetes. So they gathered together and debated what is the best way to help the people of Kubernetes.

After 3 days and 3 nights of intense discussions (also lots of pizza breaks of course) they decided that one of them needed to get special training, rent a house in Kubernetes and teach the people there the wonders of the JupyterHub magic wand.

The Chosen One gained the people’s trust, and it got better and better at anticipating and understanding their needs. So the locals started seeing it as a superhero and they even gave it a name, “Z2JH”. 👓

The news of these events started to spread far and wide, and people living in little towns outside of Kubernetes felt that they deserved the support of a superhero too. They also had great ideas and little time and needed to use the wand’s magic to do good.

The tool-keepers were inspired by the magnificent accomplishments of these little towns, taking place even without a superhero around. So the littlest of them all, volunteered to go into superhero training to help the people of the little towns do good, faster. Though it was little, in no time, it grew to become the helper these small groups needed.

The residents called it “The Littlest JupyterHub” or “TLJH” because of its stature. But everybody knew that its stature didn’t reflect its enormous tenacity, speed and ability to do great things. This ended up inspiring people all over to believe that not all superheros wear capes, nor do they need to know how to fly in the cloud to be cool.

Nowadays, people from all over join their forces and help the superheros learn new skills. Thanks to them, TLJH and Z2JH get stronger and better and have more special powers than they had when first created by the tool-keepers. Join them, become a Jovyan! ツ

nbviewer has a new host: OVHcloud

2020-03-06T19:46:00+00:00

For several years, nbviewer has been generously hosted by Rackspace. That sponsorship program appears to be ending, so nbviewer needed a new home; it has found one in OVHcloud. We are extremely grateful to OVHcloud for their support in keeping nbviewer running, building on their existing participation in the Binder Federation (literally—nbviewer is now running on the same kubernetes cluster as ovh.mybinder.org).

How we moved

Where were we before?

nbviewer was previously deployed using a private repo (because it contained credentials) and various commands using invoke. It was a mixture of custom steps, using the openstack Python API and docker machine to:

allocate two VMs
build docker images
deploy two nbviewer instances per node
deploy memcached via nbcache on each node
deploy statuspage publisher as a separate step
update fastly to point to the running nbviewer instances

The upside was that we had a repo that could immediately deploy nbviewer to anywhere with docker. With this repo, we moved our deployment strategy from a CoreOS cluster to Rackspace’s short-lived Carina service to deploying VMs ourselves with docker-machine. Migrating to a new source of VMs would not have been hard, but it wouldn’t have solved any of our challenges.

Known downsides of this deployment that we’ve experienced over the years:

only a few folks ever knew how to use it and could thus deploy updates to nbviewer
it was private, contributing to above. It’s hard to onboard folks in an open community to a private repo!
independent machines meant cache was not shared (minor, but contributes to our consumption of the GitHub API rate limit)
no automatic recovery based on health monitoring, so when a container had issues, some humans got automated emails but no action was automatically taken. Extra frustrating because the fix was ~always to restart the container.

The credentials used by this repo have been revoked and an archived version of the repo is available (with credentials redacted from history) in the new, public nbviewer.org-deploy repo.

What have we learned?

We’ve learned a lot about open, automatic, and sustainable deployments, and can now comfortably address all of the downsides above. Most of this has been learned from the communities participating in the JupyterHub and Binder projects, as seen in the mybinder.org-deploy repo. mybinder.org-deploy is a public repo that automatically deploys and tests updates to at least four different Kubernetes clusters at the push of a button (the Big Green Merge Button, to be precise). Some things we have learned in the years since we set up our nbviewer deployment:

kubernetes and helm are great :)
git-crypt allows us to have public repos with some secret contents, so deployment repos don’t need to be fully private just to protect a couple api keys.
Continuous Deployment via services like Travis or Circle lowers the bar to adding maintainers on a given deployment since all that’s needed is to press the Big Green Button.

The OVH sponsorship came in the form of a slice of a kubernetes cluster; that meant we had to migrate the nbviewer deployment tools from using docker-machine to kubernetes, which for us means helm.

Step 1: helm chart for nbviewer

The first step was to create a helm chart for nbviewer, which is done here. Before, nbviewer was two docker containers running nbviewer and one running memcached per server. To turn this into a helm chart we need:

dependency on memcached helm chart for easy deployment of the cache. All the nbviewer instances will talk to this memcache, which should improve our GitHub rate limit consumption, since the cache will be shared. This means the deprecation of our own nbcache repo.
Deployment for nbviewer. This is (one of) the kubernetes wrappers around containers. It has a nice ‘replicas’ field to easily scale nbviewer up and down. We are currently running with 3 replicas.
Service to expose nbviewer to the Internet (likely also need an ingress in the future)
Deployment for the statuspage publisher, which updates https://status.jupyter.org with the remaining github rate limit available

We also needed helm charts and docker images for some other components, such as cdn.jupyter.org and the nbviewer statuspage data source.

Step 1b: helm chart for cdn.jupyter.org

nbviewer and some other services interact with cdn.jupyter.org, which is a lightweight nginx configuration to serve the classic notebook’s javascript and css as static files(this is no longer needed for npm-based jupyterlab, which can use unpkg as a CDN). This used to run on a multipurpose server VM, but that is also being retired for the same reason. The result was creating a docker image and helm chart for serving the contents of cdn.jupyter.org. The scripts used to run the existing CDN were already in a repo, so it was a small amount of work to adapt this to run in a container instead of on a server. We may retire cdn.jupyter.org in the future, so please don’t rely on it :)

This is where we are right now — nbviewer.jupyter.org and cdn.jupyter.org are being served by OVH and the Rackspace machines are being retired.

Step 2: automatic deployment

It would have been ideal for this to be step 1, but that’s now how it happened. Sometimes you need to get it done quickly before you get it done right. The task here will be to make a new, public nbviewer-deploy repo following the patterns we have learned in mybinder.org-deploy. That will mean:

create public nbviewer.org-deploy repo with configuration and git-crypt encrypted secrets for deploying nbviewer on the ovh cluster (done)
adopting chartpress to publish our helm charts for nbviewer and version-tagged images from the nbviewer repo
configure Travis-CI or other CI service to automatically deploy updates with helm, so merging a PR is all we need to do to deploy updates to nbviewer

Thanks to OVHCloud for their continued support of Jupyter and Binder, and the JupyterHub and Binder communities for teaching me how to operate services in the open with kubernetes and helm.

A 2019 retrospective from the Binder Project

2020-01-15T17:48:00+00:00

2019 was a busy year for the Binder and JupyterHub projects — each saw growth in both their community and technology. Now that the year has wrapped up, it is a good time to reflect on some of the highlights from the year.

Overall, 2019 was about improving the robustness, stability, and team dynamics around the JupyterHub and Binder projects, as well as connecting these projects with other tools and services in the open source community. Here are a few things that we are most-excited about.

More people are using mybinder.org

The Binder Federation is a collection of BinderHubs accessible from mybinder.org. This deployment is run as a public service and a demonstration of BinderHub, the underlying technology of the Binder project. This deployment is run on a volunteer basis by Binder community members, and is supported through grants and donations in infrastructure from project stakeholders. In 2019, the user base of mybinder.org grew from around 70,000 users per week to around 100,000 users (a growth of nearly 40%). mybinder.org is being used for teaching classes, sharing reproducible analyses, creating interactive documentation and narratives, and much more. We’re astonished at the rapid growth of Binder-ready repositories, and we’re excited to see what the community creates next.

Weekly user sessions at mybinder.org. Here you can see a typical pattern of activity over the course of a year. There are dips in activity over the summer and winter months, reflecting reduced activity from academic institutions.

JupyterHub reaches 1.0

JupyterHub, the underlying technology that provides interactive computing sessions to multiple users, is now at 1.0 status. The JupyterHub Python application was written several years ago, and reaching 1.0 reflects the work of dozens of open source contributors over time. JupyterHub is now a robust and stable application, having been used at smaller scales (think 5–10 people running on a single VM) as well as much larger scales (think 5,000 students running Jupyter sessions for a class).

The JupyterHub logo

BinderHub is out of beta

BinderHub, the kubernetes-based technology that powers mybinder.org, also came out of Beta this year. This reflects the fact that BinderHub is a battle-hardened application that can provide a stable service over time. mybinder.org runs nearly 100,000 sessions a week, and requires minimal maintenance time from the Binder’s projects team of volunteer operators.

The BinderHub federation is launched

The Binder Project envisions a world in which technology can be used in vendor-agnostic and decentralized ways. BinderHub runs on Kubernetes, which can be deployed on a variety of cloud and local infrastructure. While the Binder team runs one BinderHub deployment at mybinder.org, our goal has always been to see other organizations running their own BinderHubs. This year, we went one step beyond this by launching the BinderHub Federation. This is a collection of research and technology organizations that combine their expertise and computational resources to power mybinder.org. When users visit mybinder.org, they are now directed to one of several BinderHub instances. This makes mybinder.org more robust, and grows the number of organizations that utilize the project’s technology for their communities. A BIG THANKS goes out to Google, OVH, GESIS, and the Turing Institute for supporting the Binder Federation.

The (rough) location of each BinderHub deployment in the mybinder.org federation

Binder connects with open science services

Another goal of Binder is to be a part of the solution to more transparent, sharable, reproducible computational work. This means plugging in to other ecosystems and projects in order to leverage the broader open science community. This year we saw a number of new connections with other services. BinderHub now supports links that point directly to Zenodo and Dataverse repositores, and we are working on a few other integrations in the coming months. This means that projects utilizing these resources will be able to share reproducible and interactive links to their work out-of-the-box.

Binder now works with Zenodo repositories!

The Binder community grows

The Binder project’s most important asset is its people — this is a collection of volunteers spread across the world and from a variety of organizations. Binder community members do a variety of things — from working on technology, to teaching others how to make their work more reproducible, to participating in community discussions, to maintaining and debugging Binder tech. There is also a “core team” of Binder members that dedicates a significant part of their time to supporting the project. In 2019, we saw several new members join the core team, as well as a general growth in the Binder community. Welcome to all of our new team members! You can find a list of our current team members here.

We welcome our first Contributor in Residence

One challenge with running large, open projects is that resources tend to be scarce. The Binder Project has no formal project funding, and must find ways to both grow its technology as well as run mybinder.org on resources that are donated from its community. One thing that often suffers as a result is the maintenance and general improvement of our open source technology. This work is often under-appreciated, difficult, and unlikely to happen with purely volunteer labor.

For this reason, the Binder project decided to apply for the CZI Essential Open Source grant series. We proposed the creation of the “Binder Contributor in Residence” position — an annual contractor position that pays a member of the Binder community to do many of the daily things that are crucial for the project’s growth. We are excited to have Georgiana Dolocan as our first contributor in residence, and look forward to where this project will go in 2020.

Many thanks to CZI for their support of the Binder and JupyterHub projects in 2020!

There are more BinderHub deployments

The Binder Project aims to create technology that is deployable anywhere so that other organizations can support their communities with Binder infrastructure. In 2019 we ran a number of training sessions for how other groups can run their own BinderHub. In particular, the Turing Institute ran several workshops that had attendees up-and-running with their own functioning BinderHubs.

Thanks to our community

As you can see, 2019 was a busy and exciting year for the Binder community. As a final note, we want to say thanks to all of you who have supported Binder in one form or another over the years. Binder is a project run by the community, for the community. It wouldn’t be possible without all of your hard work and friendly faces, thanks! We look forward to what’s coming next in 2020!

The International Binder Federation

2019-07-01T09:11:00+00:00

About two years ago, the Binder project evolved into the community led project that it is today. The deployment at mybinder.org was upgraded to use
BinderHub, a scalable open-source web application that runs on Kubernetes and provides free, sharable, interactive computing environments to people
all around the world.

In the ensuing years, the Binder community has grown considerably.
Now people use the public deployment at mybinder.org around 100,000 times each week, and there are around 8,000 unique repositories compatible with Binder. Binder links now work with multiple repository providers, such as GitHub, GitLab, BitBucket, and even Zenodo! This means that providing enough compute power for everyone is a challenge.

This is why today we are happy to announce that mybinder.org is now backed by two clusters hosted by two different cloud providers: Google Cloud and OVH. This is the beginning of the International Binder Federation.

How did we get here? Alongside mybinder.org’s growth we’ve seen growth in another part of the Binder ecosystem: people deploying a BinderHub for their own groups. In the last year, we have seen BinderHubs deployed for large-scale earth analytics with the Pangeo project, for communities of best-practices in open science with The Turing Way, and for specific domains such as the social sciences like GESIS.

As more BinderHubs are deployed, we realized that there was an opportunity to leverage the strengths and resources of the community to improve the large, public BinderHub deployment at mybinder.org. Instead of a single BinderHub run by the Binder team, we could build a network of BinderHubs that shares the load and keeps mybinder.org stable and quick.

OVH Joins the mybinder.org Federation

Today, we are thrilled to announce that the Binder Project now has a world-wide federation of BinderHubs powering mybinder.org. We’ve partnered with OVH, a cloud hosting company based in Europe that is supportive of open projects such as Jupyter and Binder.

Through the partnership with OVH, all traffic to mybinder.org will now be split between two BinderHubs - one run by the Binder team, and another run by a team of open-source advocates at OVH. They have generously offered their resources and computing time to allow Binder to serve the scientific and educational communities.

The mybinder.org federation currently has two BinderHubs, but this network can (and will!) grow as more groups offer to connect their own BinderHubs to the network.

What does this mean?

So what has changed for you, the user? Probably not much. The
biggest difference you’ll notice is that landing at mybinder.org
will now redirect you to one of two places:

gke.mybinder.org is the BinderHub hosted on the Google Cloud Platform
ovh.mybinder.org is the BinderHub hosted on the OVH platform in France.

Other than this, your experience should be the same. You might even notice an improvement in speed and load times because the BinderHub you’re using has a little bit less traffic on it 😀.

As always, we are pushing this out as soon as we think it is useful. You can help us to scale this model and make it rock solid by reporting weird things you notice. Expect tweaks over the next few weeks based on feedback from users. Let us know about the things you like, dislike or have questions about at https://discourse.jupyter.org/t/the-binder-federation/1286.

Why is this a big deal?

We think that having a federation of BinderHubs behind mybinder.org is pretty cool, for a few different reasons. First, it demonstrates the dedication that the Binder community has towards building tools that anybody can deploy — we certainly don’t want to be the only ones running a BinderHub, and having other BinderHubs behind mybinder.org is a great example of this. Second, a network of BinderHubs for mybinder.org means that we can eventually do some clever things like use geolocation to distribute users, which should improve the performance that you all experience. Third, having fewer users per BinderHub means that we can optimize the resources available to each hub — resulting in improvements in speed and stability. Finally, having a federation of BinderHubs makes the mybinder.org service significantly more robust, and less-dependent on a single team, deployment, platform, and funding source. We are now more confident than ever that mybinder.org will continue to be available as a stable, free, public service that keeps growing.

What’s next?

Now that we’ve reached N=2 BinderHubs powering mybinder.org,
it is straightforward for us to grow this network to N=3 and beyond. Over the summer we will continue our work on approaching universities, research councils, and cloud hosting companies.

If you are interested in helping out: we’d love to see other community members come forward to offer their time or resources to provide more nodes in the international BinderHub federation. If you’re interested in doing so, please open an issue in the JupyterHub team compass repository
to discuss the possibilities of working together!

We’re excited about the ability for the Binder community continuing
to grow, and to build more tools for distributed, community-run
infrastructure for open science and education. This is all possible
because of the hard work of many people in the community, so a big
thank you to those who spend their time working on open tools in
the Jupyter and Binder ecosystems. We’re excited to see what comes
next!

BinderHub is out of Beta!

2019-04-26T16:49:00+00:00

Nearly two years ago, the Binder Project released the beta version
of BinderHub, the technology behind mybinder.org. Since then, mybinder.org has grown to serve nearly 90,000 launches each week and hit the two million launches in a year milestone last year. Over these two years BinderHub has matured as technology and community. Several new organizations now run their own BinderHubs and have joined the community of maintainers.

A year of Binder sessions served from mybinder.org. Darker colors show users in countries that have launched more Binder sessions. The pins show the approximate locations of public BinderHubs that we know of. Where is mybinder.org? It is a global effort so there is no one location associated with it or the team that runs it.

Today we are proud to announce that we’ve removed the “beta” label from all pages served by BinderHub. BinderHub is now a tool with a track record of working well in production (both at mybinder.org and in other deployments), its general features and API have stabilized, and JupyterHub, the underlying technology that BinderHub uses, is close to its 1.0 release.

A big thank you to all those who have used, commented, advocated, advertised, contributed, maintained and funded this journey. The deployment at mybinder.org is funded with grants from the Moore Foundation and the Google Cloud Platform.

Who else has deployed a BinderHub?

A goal of Project Binder is to build modular, open-source tools that
others can deploy for their own communities. BinderHub, the core technology behind mybinder.org, runs on Kubernetes this means it can be deployed on many cloud providers or even on your own hardware. Over the years, we have seen many new organizations deploy their own BinderHubs. Here are our highlights of other organizations who have joined the BinderHub community.

GESIS were the first to deploy a public BinderHub that is operated independently of mybinder.org. The GESIS BinderHub instance went live
in December 2017 and has been running ever since. They are frequent
contributors to the upstream project. Their BinderHub runs on a bare metal
Kubernetes cluster.

The Pangeo Project instance was the next to come online, launching their
public BinderHub instance in September 2018 (more details in their blog post). They provide additional compute resources and have customized their setup to provide on-demand dask clusters to users. Try out one
of their examples using ocean data. The Pangeo cluster is hosted on Google Kubernetes Engine.

Recently, the Turing Way project has been working on deploying a BinderHub at the Turing Institute in the UK. This BinderHub will serve both internal and external users with the goal of making it easier to share data science projects. They have run several workshops including one that teaches scientists and research software engineers how to deploy their own BinderHub instance. Recently they led a workshop in which ten academics and IT staff deployed their own BinderHub on the Microsoft Azure cloud! Sarah Gibson from their team has recently joined the team that operates mybinder.org.

Finally, the Pacific Institute for the Mathematical Sciences (PIMS) runs a service called Syzygy. It deploys several JupyterHubs and BinderHubs for scientific organizations around Canada. A Binder team recently held a tutorial on deploying Binder and JupyterHub at the PEARC (you can find slides for the talk here). They have also provided a script for deploying JupyterHub (and Binder) on Terraform.

What’s next?

Now that BinderHub is not in beta anymore, what is next? As Project Binder we will focus on adoption, training, and growing the Binder community. This means growing the creation of Binder-ready repositories (repositories that have the necessary structure for Binder to create the environment needed to run the repository’s code). We will increase our outreach and marketing efforts to make sure a diverse audience everywhere around the world knows about Binder.

We will also work on making it easier to setup and operate a public BinderHub no matter what cloud vendor you are using. We are excited to see more organizations deploy their own BinderHubs for their communities. In the coming months, our goal is to create a federation of public BinderHubs
that operate in unison to serve the global user base of mybinder.org.

If this caught your attention consider joining the Binder community, or contributing to Project Binder! A good place to start is the Jupyter Community Forum or dive straight into the code on GitHub.

Introducing TraefikProxy — a scalable and highly available proxy for JupyterHub

2019-03-06T11:58:00+00:00

In the JupyterHub context, the proxy is the unit in charge of directing the user requests to their notebook servers.

The proxy manages a list of [user : notebook] mappings (the proxy routing table) in order to decide which request is sent where. The routing table must be continuously updated as users start and stop their servers without disrupting the requests being processed. The following drawing illustrates the proxy functionality in a JupyterHub deployment.

Why the need for a new proxy?

Currently, the default proxy implementation for JupyterHub is configurable-http-proxy (CHP), which is a single-process nodejs proxy, that stores the routing table in-memory. CHP is easy to install and run, and thus in most of the cases it’s a fine option. However, because you can only run a single copy of the proxy at a time, it has its limitations when used in dynamic, large scale systems.

What makes this new proxy special?

JupyterHub 0.8. opened the way towards allowing users to create custom proxy implementations based on their deployment needs. JupyterHub Traefik Proxy leverages this feature to offer an alternative to the default proxy. It is an implementation of the JupyterHub Proxy API based on traefik, an extremely lightweight, portable reverse proxy implementation, that supports load balancing and can configure itself automatically and dynamically. JupyterHub Traefik Proxy comes in two flavors, depending on how traefik stores the routing table:

TraefikTomlProxy — for smaller, single-node deployments
TraefikEtcdProxy — for distributed setups

How does it work?

Both TraefikTomlProxy and TraefikEtcdProxy use a toml file for the global configuration. This file contains information about how to set up the connections to the routing table provider (the unit that stores the routing rules like “/user/mary” should be sent to Mary’s server at http://10.0.1.5:12345) and to the network entry points into Traefik (listening port, SSL, traffic redirection). However, the two proxies go in different directions when it comes to the provider used for storing the routing table.

TraefikTomlProxy uses a toml file to store the routes and keeps an in-memory copy of it for a faster access to the routes. This is appropriate for smaller-scale deployments. For example, the Littlest Jupyterhub (the single-node JupyterHub distribution, for a small number of users) just switched from using two proxies (traefik as an edge proxy with letsencrypt support and CHP for routing) to a configuration with just TraefikTomlProxy that serves both requirements. ❤

TraefikEtcdProxy uses etcd, a distributed key-value store to persist the routing table. This implementation aims to benefit Zero to JupyterHub with Kubernetes because it allows having multiple proxy replicas, making the proxy highly available and thus improving the scalability and stability of the system.

Adding the information about TraefikProxy to the first diagram , the drawing below presents the two proxy flavors with their common parts (the global configuration file — traefik.toml) and their differences (the mechanism used for storing the routing table — a toml file vs. etcd)

Another cool Traefik feature is the Web UI dashboard which lists all of the registered frontends (the set of rules that determine how incoming requests are forwarded) and backends (the notebooks), the routing rules, some useful metrics, and other configuration elements. The port on which TraefikProxy’s api will run, as well as the username and password used for authenticating, are all configurable.

Here’s what the dashboard looks like:

How to enable Traefik Proxy?

These instructions help you enable one of the Traefik proxies on your JupyterHub.

Install it:

python3 -m pip install jupyterhub-traefik-proxy

Install traefik and etcd:

$ python3 -m jupyterhub_traefik_proxy.install --output=/usr/local/bin

This will install the default versions of traefik and etcd, namely traefik-1.7.5 and etcd-3.3.10 to /usr/local/bin specified through the --output option.

Configure JupyterHub to run with TraefikProxy through jupyterhub_config.py, using the proxy_class config option.

from jupyterhub_traefik_proxy import TraefikEtcdlProxy
c.JupyterHub.proxy_class = TraefikEtcdProxy
# will configure JupyterHub to run with TraefikEtcdProxy

from jupyterhub_traefik_proxy import TraefikTomlProxy
c.JupyterHub.proxy_class = TraefikTomlProxy
# will configure JupyterHub to run with TraefikTomlProxy

As there are many other proxy configuration options, please check out the project documentation for more info and some example configurations.

What’s next?

TraefikEtcdProxy is soon to be integrated into zero-to-jupyterhub-k8s, the Helm Chart for deploying JupyterHub on Kubernetes. By using the Traefik proxy with etcd, we can eliminate the downtime while the proxy restarts or upgrades, as well as have an all-in-one proxy that can be used for both routing and HTTPS (Let’s Encrypt) support.

Also, there’s a performance analysis of all the three proxies on the way that will help us understand the advantages and limitations of this new JupyterHub Proxy implementation.

The story behind

JupyterHub Traefik Proxy was developed as part of my Outreachy internship. I am very grateful to have had the chance to work with the Jupyter community and I’m happy and proud to say that I’ve learned a lot and the experience has been invaluable. There were a lot of questions and a ton of fears along the way, but the encouragements and guidance I received, helped me move forward and finish this great project. So, a big thank you to everyone for their support and to NumFocus and Berkeley Institute for Data Science for sponsoring this Outreachy round! ❤

Zero to JupyterHub helm chart 0.8

2019-02-21T18:34:00+00:00

We’ve just released version 0.8 of the jupyterhub helm chart.

For those who may not know, Zero to JupyterHub is a guide and helm chart for deploying JupyterHub on Kubernetes. Helm is like a package manager for Kubernetes, which aims to make it easy to install and manage applications on your cluster.

There are loads of bugfixes and improvements to this release, and we encourage you to check out the change log. Here, we’ll discuss two highlights from the new features: profiles and autoscaling.

Profiles

By adopting the profiles pattern established in WrapSpawner, Kubernetes users can now pick from a selection of “profiles” or pre-set configurations, defined by the operator of a cluster. For example, defining small, medium, and large resource requests, or special profiles for GPUs.

The above sample is created from the following snippet in your values.yaml:

singleuser:
  profileList:
    - display_name: "Small: default"
      description: |
        A small job. 1 CPU, no GPU. This is the default.
      default: True
      kubespawner_override:
        cpu_limit: 1
        cpu_guarantee: 1
        mem_limit: "1G"
        mem_guarantee: "512M"
        extra_resource_limits: {}
    - display_name: "Big: 8 CPUs"
      description: |
        A big job. 8 CPUs, no GPU, and 64GB of RAM
      kubespawner_override:
        cpu_limit: 8
        cpu_guarantee: 8
        mem_limit: "64G"
        mem_guaranttee: "64G"
        extra_resource_limits: {}
    - display_name: "GPU job"
      description: |
        This configuration gives you 4 CPUs, 16GB of RAM, and a GPU
      kubespawner_override:
        image: consideratio/singleuser-gpu:v0.3.0
        cpu_limit: 4
        cpu_guarantee: 4
        mem_limit: "16G"
        mem_guarantee: "16G"
        extra_resource_limits:
          nvidia.com/gpu: "1"

Autoscaling

Autoscaling is a big focus of this release, and many of the new features in 0.8 of the chart relate to scaling in some way. At the center is a new ‘user scheduler’ a custom kubernetes scheduler responsible for assigning user pods to nodes. To enable the user scheduler:

scheduling:
  userScheduler:
    enabled: true

There are two major pain-points for autoscaling with JupyterHub. First, is scaling up. Kubernetes scale-up is very basic: If scheduling a pod fails due insufficient resources, a new node is requested. This isn’t a great fit for JupyterHub. If you happen to be the unlucky user who is the first to need a new node, launching your server can take several minutes as the new node is requested and warming up. To prevent this, the chart adds the notion of “placeholder pods,” which are pods that request the same resources as user pods, but have lower priority and will thus be evicted immediately if a user pod needs their resources. This allows a cluster to always have a certain amount of “headroom” of vacant slots available for users so that requesting a new node occurs not when there are 0 slots available for users, but instead when there are 5 or 10 (you choose) slots available. See this exploration of how mybinder.org arrived at 25 placeholders for its deployment. To enable 10 user placeholders:

scheduling:
  podPriority:
    enabled: true
  userPlaceholder:
    enabled: true
    replicas: 10

The second major improvement to autoscaling that comes with the user scheduler is in scaling down. If your cluster is automatically scaling up, you probably want it to scale down as well when you no longer need the added capacity. Unfortunately, because user pods cannot be kicked out, Kubernetes’ default scheduler doesn’t manage to drain nodes that are no longer needed without some manual intervention. The user scheduler adds this feature, ensuring that, over time, your newest nodes eventually drain when they are no longer needed. It accomplishes this by prioritizing the node with the most other user pods when picking a node to start new users. If there is an extra node, over time eventually all the users on that node will stop and the node will become idle and culled by the cluster autoscaler. This is the default behavior . There’s loads more scheduling optimizations available in the updated documentation, including dedicating certain nodes to users so that user pods never run on the same node as others, etc.

And finally, a huge thanks to the numerous contributors who helped make this release, be it via documentation contributions, testing, discussion, or code.

Check it out

MyBinder.org serves two million launches

2018-11-13T12:35:00+00:00

by the Binder Team

Since the beginning of 2018, the Binder community has been hosting a BinderHub at https://mybinder.org as a free public service. Today, we are proud to announce that this hub has served over two million Binders. To mark this milestone we would like to say a huge Thank You! to the large community of people who use, build, and fund the project. Without you this important public infrastructure would not be the user-friendly, reliable, well-supported and documented resource that we enjoy today. mybinder.org has enabled people from almost every country in the world to learn, participate and share countless projects, ideas and stories. Here’s to two million more!

A huge thank you to all those who help with building, using, and operating https://mybinder.org.

What is mybinder.org?

mybinder.org let’s you take a repository full of Jupyter notebooks or RMarkdown and turn it into a collection of interactive notebooks. You can share your work with anyone by sending them a simple link (like this one). All they have to do is open the link in a web browser and they can run those notebooks from anywhere in the world without having to install anything.

Who is using mybinder.org?

Currently about 70–80,000 Binders are launched every week. A lot of those are people who are looking for a quick and easy way to launch a Python or RStudio environment. However in the last week a notebook showing off fifty ways to solve Fizz Buzz has been getting a lot of love. Beyond those heavy hitters and short-lived audience favorites there is a long tail of over 400 unique repositories that get launched every week. It would take the rest of the post to list them all!

One last statistic that we are particularly proud of: over the last 80 days we have had users from almost all around the globe! Binder was started as a way to make computational research easier to share and reuse. We have been amazed at how many people around the world have used Binder for teaching classes, reproducing results, sharing interactive analyses, and making their work more accessible to others. We are particularly proud that this includes people from around the entire world.

Countries from which https://mybinder.org has received visitors between 22 August 2018 and 10 November 2018.

Data set of all launches on mybinder.org

mybinder.org is operated as a public infrastructure that is transparent, open, and inclusive. We chat, discuss, and work in the open. This is why we are now publishing a new data set: a continuously updated log of every launch that happens on mybinder.org!

MyBinder.org Events Archive

We would love to see people explore this data set as a public resource that describes the kinds of repositories being shared and launched on the public mybinder.org deployment.

A new badge!

One more thing … we thought now is a good time to give the trusty “Launch Binder” badge an overhaul. To improve the badge we put together some suggestions, reached out to the community, and within a few days received a lot of feedback and new ideas. After combining all the inputs, our new badge went live earlier this week. We present to you our new badge:

The new “Launch Binder” badge. Binder blue instead of bright red!

We hope you like it as much as we do. If you are in love with the old design or not quite ready to switch yet, do not worry! The old badge is not going anywhere. If you are using the old badge in your README it will continue to look the same as it always has.

If you do want to change a previously generated link to the new badge, edit the name of the SVG in the link from the old:

[![Binder](http://mybinder.org/badge.svg)](http://mybinder.org/v2/gh/binder-examples/r/master)

to the new:

[![Binder](http://mybinder.org/badge_logo.svg)](http://mybinder.org/v2/gh/binder-examples/r/master)Outro.

Open infrastructure in the cloud

The Binder project is a community-driven experiment in radically-open infrastructure. BinderHub, the underlying technology that powers a Binder deployment, is an open project and can be deployed in many other cloud environments. For example, see the Pangeo Binder deployment for geospatial analytics, or the Gesis Binder deployment for social sciences. We are excited to see the project head in new directions as we continue to grow the technology and the community around Binder.

Finally, we could not have done any of this without a ton of support from the Binder community. First, many thanks to the Moore Foundation for funding initial development of Binder’s underlying tech, and for helping us finance running the deployment at mybinder.org. Second, many thanks to the Binder project core team for fostering excellent technology and a great community. Finally, thanks to everybody in the Binder community — whether you’ve launched repositories, shared your Binders, participated in discussions, built features, helped design this post’s banner image (❤), or gave us some critical feedback. Binder’s purpose is to serve the community, and you all have made it so worth it!

If you’d like to get involved in the Binder project, here are a few helpful links:

To learn about Binder, see the Binder documentation: docs.mybinder.org
For information on how to deploy your own BinderHub, see the BinderHub deployment docs: binderhub.readthedocs.io
To participate in conversations with the Binder community, say hello on the Binder gitter channel (https://gitter.im/jupyterhub/binder) or the JupyterHub/Binder Discourse forum (discourse.jupyter.org).
If you’d like to see the code itself, see the three main open projects that make up a Binder deployment: BinderHub (github.com/jupyterhub/binderhub), repo2docker (github.com/jupyter/repo2docker), and JupyterHub (github.com/jupyterhub/jupyterhub)

On-demand Notebooks with JupyterHub, Jupyter Enterprise Gateway and Kubernetes

2018-10-16T15:03:00+00:00

by: Luciano Resende, Kevin Bates, Alan Chin

Jupyter Notebook has become the “de facto” platform used by data scientists to build interactive applications and to tackle big data and AI problems.

With the increased adoption of Machine Learning and AI by enterprises, we have seen more and more requirement to build analytics platforms that provide on-demand notebooks for data scientists and data engineers in general.

This article describes how to deploy multiple components from the Jupyter Notebook stack to provide an on-demand analytics platform powered by JupyterHub and Jupyter Enterprise Gateway on a Kubernetes cluster.

Image 1 — Deployment Architecture

On-Demand Notebooks Infrastructure

Below are the main components we are going to use to build our solution, and its high-level description:

JupyterHub enables the creation of a multi-user Hub which spawns, manages, and proxies multiple instances of the single-user Jupyter Notebook server providing the ‘as a service’ feeling we are looking for.

Jupyter Enterprise Gateway provides optimal resource allocations by enabling kernels to be launched in its own pod enabling notebook pods to have minimal resources while kernel specific resources are allocated/deallocated accordingly to its lifecycle. It also enables the base image of the kernel to become a choice.

Kubernetes enables easy management of containerized applications and resources with the benefit of Elasticity and multiple other quality of services.

JupyterHub Deployment

JupyterHub is the entry point for our solution, it will manage user authorization and provisioning of individual Notebook servers for each user.

JupyterHub configuration is done via a config.yaml, and the following settings are required:

Enable custom notebook configuration (coming from the customized user image).

hub:
  extraConfig: |-
    config = '/etc/jupyter/jupyter_notebook_config.py'

Define the docker image to be used when instantiating the notebook server for each user
Define custom environment variables used to connect the Notebook server with Jupyter Enterprise Gateway to enable support for remote kernels

singleuser:
  image:
    name: elyra/nb2kg
    tag: dev
  storage:
    dynamic:
      storageClass: nfs-dynamic
  extraEnv:
    KG_URL: <FQDN of Gateway Endpoint>
    KG_HTTP_USER: jovyan
    KERNEL_USERNAME: jovyan
    KG_REQUEST_TIMEOUT: 60

The complete config.yaml would look like the one below:

hub:
  db:
    type: sqlite-memory
  extraConfig: |-
    config = '/etc/jupyter/jupyter_notebook_config.py'
    c.Spawner.cmd = ['jupyter-labhub']
proxy:
  secretToken: "xxx"

ingress:
  enabled: true
  hosts:
    - <FQDN Kubernetes Master>

singleuser:
  defaultUrl: "/lab"
  image:
    name: elyra/nb2kg
    tag: 2.0.0.dev0
  storage:
    dynamic:
      storageClass: nfs-dynamic
  extraEnv:
    KG_URL: <FQDN of Gateway Endpoint>
    KG_HTTP_USER: jovyan
    KERNEL_USERNAME: jovyan
    KG_REQUEST_TIMEOUT: 60

rbac:
  enabled: true

debug:
  enabled: true

Detailed deployment instructions for JupyterHub can be found at Zero to JupyterHub for Kubernetes, but the command below would deploy it into a Kubernetes environment.

helm upgrade --install --force hub jupyterhub/jupyterhub --namespace hub --version 0.7.0 --values jupyterhub-config.yaml

Custom JupyterHub user image

By default, JupyterHub would deploy a vanilla Notebook Server image which will require that all resources ever used by the image to be allocated when the Kubernetes image is instantiated.

Our custom image will enable kernels to be started in its own pod, promoting a better resource allocation as resources can be allocated and freed up as needed. This also gives us the flexibility of supporting different frameworks for different notebooks (e.g. a notebook using Python and TensorFlow, while another is using Python and Caffe2).

Dockerfile for elyra-nb2kg custom image:

FROM jupyterhub/k8s-singleuser-sample:0.7.0

# Do the pip installs as the unprivileged notebook user
USER $NB_USER

ADD jupyter_notebook_config.py /etc/jupyter/jupyter_notebook_config.py

# Install NB2KG
RUN pip install --upgrade nb2kg && \
    jupyter serverextension enable --py nb2kg --sys-prefix

Jupyter Notebook custom configuration to override Notebook handlers with the ones from NB2KG that will enable the notebook to connect with the Enterprise Gateway that enables remote kernels.

from jupyter_core.paths import jupyter_data_dir
import subprocess
import os
import errno
import stat

c = get_config()
c.NotebookApp.ip = '*'
c.NotebookApp.port = 8888
c.NotebookApp.open_browser = False

c.NotebookApp.session_manager_class = 'nb2kg.managers.SessionManager'
c.NotebookApp.kernel_manager_class = 'nb2kg.managers.RemoteKernelManager'
c.NotebookApp.kernel_spec_manager_class = 'nb2kg.managers.RemoteKernelSpecManager'

# https://github.com/jupyter/notebook/issues/3130
c.FileContentsManager.delete_to_trash = False

# Generate a self-signed certificate
if 'GEN_CERT' in os.environ:
    dir_name = jupyter_data_dir()
    pem_file = os.path.join(dir_name, 'notebook.pem')
    try:
        os.makedirs(dir_name)
    except OSError as exc:  # Python >2.5
        if exc.errno == errno.EEXIST and os.path.isdir(dir_name):
            pass
        else:
            raise
    # Generate a certificate if one doesn't exist on disk
    subprocess.check_call(['openssl', 'req', '-new',
                           '-newkey', 'rsa:2048',
                           '-days', '365',
                           '-nodes', '-x509',
                           '-subj', '/C=XX/ST=XX/L=XX/O=generated/CN=generated',
                           '-keyout', pem_file,
                           '-out', pem_file])
    # Restrict access to the file
    os.chmod(pem_file, stat.S_IRUSR | stat.S_IWUSR)
    c.NotebookApp.certfile = pem_file

Note that the document above was generated by jupyter notebook --generate-config and then updated with the required handlers override:

c.NotebookApp.session_manager_class = 'nb2kg.managers.SessionManager'
c.NotebookApp.kernel_manager_class = 'nb2kg.managers.RemoteKernelManager'
c.NotebookApp.kernel_spec_manager_class = 'nb2kg.managers.RemoteKernelSpecManager'

Jupyter Enterprise Gateway deployment

Jupyter Enterprise Gateway enables Jupyter Notebook to launch and manage remote kernels in a distributed cluster, including Kubernetes cluster.

Enterprise Gateway provides a Kubernetes deployment descriptor that makes it simple to deploy it on a Kubernetes environment with the command below:

kubectl apply -f https://raw.githubusercontent.com/jupyter-incubator/enterprise_gateway/master/etc/kubernetes/enterprise-gateway.yaml

We also recommend that the kernel images be downloaded on all nodes of the Kubernetes cluster to avoid delays/timeouts when launching kernels for the first time on these nodes.

docker pull elyra/enterprise-gateway:dev
docker pull elyra/kernel-py:dev
docker pull elyra/kernel-tf-py:dev
docker pull elyra/kernel-r:dev
docker pull elyra/kernel-scala:dev

Automated One-Click Deployment using Ansible

If you are eager to get started and try this in a few machines, we have published anansible script that deploys the full set of components described above on vanilla RHEL machines/VMs.

ansible-playbook --verbose setup-kubernetes.yml -c paramiko -i hosts-fyre-kubernetes

Conclusion

Jupyter Enterprise Gateway provides remote kernel management to Jupyter Notebooks. In a JupyterHub/Kubernetes environment, it enables hub to launch tiny Jupyter Notebook pods and only allocate large kernel resources when these are created as independent pods. This approach also allows for easy sharing of expensive resources as GPUs, etc

Special Thanks

Special thanks to Erik Sundell and Min RK from the JupyterHub team for the support and initial discussions around JupyterHub.

Deploying JupyterHub with Kubernetes on OpenStack

2018-10-15T13:11:00+00:00

Jupyter is now widely used for teaching and research. The use of Kubernetes for deploying a JupyterHub has enabled reliable setups scaling to thousands of users.

There are many cloud computing vendors (Google, Amazon, …) and the first attempts to use JupyterHub with Kubernetes is based on them. But relying on vendor clouds increases the risk of vendor lock-in.

In addition, there are many pre-existing academic clouds managed by people with a high level of expertise and a thorough knowledge of their infrastructure and associated tools. These are often more cost-effective for research and education. Could we build upon these academic cloud computing to provide scalable and high-quality infrastructure for education and research?

In this post, we will focus on how to deploy JupyterHub with Kubernetes on OpenStack. A first attempt to create academic cloud computing in France.

This post is split into two parts (see links below).

Why to deploy JupyterHub on OpenStack is a high-level description of our problem, and our steps to solve it. It explains why we want to deploy a JupyterHub on OpenStack, what difficulties we have encountered, and what we want to do in a near future.

A technical guide to deploying JupyterHub on OpenStack is an in-depth guide that you may follow in order to deploy your own JupyterHub on Kubernetes on OpenStack. It’s designed for any person interested in how to replicate our deployment on their own infrastructure.

Our story, our difficulties and our plans

Why deploy JupyterHub on OpenStack?

JupyterHub, the multi-user Jupyter server, has been actively developed since 2014 and has seen a rapidly growing adoption in the past year.

You may know about Zero to JupyterHub, which provides step-by-step instructions for installing JupyterHub using a vendor-managed Kubernetes cluster. In the guide, you can also find how to set up a Kubernetes cluster on many vendor clouds such as AWS, Azure, and more recently on OpenShift. But what about other cloud infrastructures based on open-source infrastructure, such as OpenStack? While cloud vendors often provide you with many tools that make your life easier, OpenStack requires more explicit configuration and setup.

Earlier this year, we set up a working group across several France universities to explore how to easily set up JupyterHub for teaching and research in our academic cloud infrastructures. It turns out that the technology used across these academic clouds is OpenStack. One of the objectives of this working group is to make just as easy to deploy JupyterHub on OpenStack as compared to following Zero to JupyterHub and using vendor infrastructure.

Note: We are not the first to work on this problem, and we should also mention the work done in Canada through Syzygy.ca which is a project of PIMS, Compute Canada, and Cybera. They have developed their own deployment tools using terraform and ansible scripts. Our approach differs in that while we use the same technological stack, we prefer not to build a custom deployment tool that we would need to maintain over time.

Issues we encountered

We started a deployment using Kubespray in January of this year and have had a bumpy path since then. To begin, we looked at what existed already in the OpenStack world. We came across Kubespray, which offers a great facility and a lot of flexibility when you want to deploy a Kubernetes cluster. An interesting fact about Kubespray is that it’s not dedicated to OpenStack infrastructures, so you should be able to follow the same procedure for other deployments such as a baremetal cluster.

Using Kubespray, we very quickly had a Kubernetes cluster on OpenStack. However, we ran into network problems, and would lose network packets that made the JupyterHub completely unusable. It took us a long time to realize that we had MTU issues and even longer to solve it. To make things harder, we used a production platform which made it very difficult to update. We finally solved the problem by using a test platform where we could have more freedom.

In Kubespray, there are various CNIs (Container Network Interface) and one of them (weave) allows to modify the MTU. We tried to configure it carefully on the production platform, but we continued facing the same problem. Trying a new version of OpenStack on the test platform, we were able to solve the problem. That means that something bad had also happened with the LoadBalancer. For more explanation, see the MTU section in the technical description below.

We thought we could deploy JupyterHub with Kubernetes on OpenStack in a few weeks but as you can see, that’s not what happened at all. That’s why it was important for us to share our experience in the hopes that it makes the process easier for others. In the last section, we’ll cover more of the technical details for our deployment

What’s next ?

For us, the installation of JupyterHub on OpenStack was just the first step of a long journey. We are able now to offer to our researchers and our students a JupyterHub but we want more. Here’s a short wish-list our deployments.

On-demand environments. Imagine offering researchers and teachers an even more flexible platform where they can create their work environment and distribute them without needing to use central IT for the installation of their packages. As you may have guessed, we are more interested in what BinderHub has to offer.

The steps described above also work for the installation of BinderHub. We deployed a BinderHub on OpenStack alongside a DockerHub registry. Kubespray also offers the possibility to deploy a private registry and we would like to test it with BinderHub.

Cluster monitoring. It would also be great to have monitoring of the Kubernetes cluster. This would allow us to inspect the usage rates and resources available on the deployment. In the roadmap of Kubespray, it is planned to add Grafana and Prometheus installations.

Authentication for BinderHub. Currently BinderHub does not support authentication for users. However, note that a recent pull request on this subject was merged in BinderHub (see https://github.com/jupyterhub/binderhub/pull/666).

Persistent storage in BinderHub. It is also currently not possible to persist storage across BinderHub sessions. Once authentication is possible in BinderHub, we’d also like to connect user accounts to their storage so that they can keep their work over time. This will also require being able to mount the home directory of each user.

We will work on all these items in the next months.

The Technical Details

This part details the set up of a Kubernetes cluster and JupyterHub using a bare OpenStack infrastructure. To make it as reproducible as possible, we will start by listing the versions we have used.

OpenStack: Pike
Kubespray: commit 3632290
Kubernetes: 1.11.3
Helm: 2.9.1
JupyterHub: 0.7.0

Now that we’ve described the components and the versions used, let’s start to deploy our JupyterHub on OpenStack !!

The deployment steps are the following

Connect to our OpenStack infrastructure
Download Kubespray
Create your infrastructure using terraform
Deploy your Kubernetes cluster using ansible
Deploy your JupyterHub using Helm chart
Enjoy!

Connect to OpenStack

Kubespray needs a access to your OpenStack infrastructure in order to create all the instances needed for your Kubernetes cluster using the OpenStack CLI (Command-Line Interface). When you log in to your OpenStack dashboard, you can download all the environment variables to use the CLI.

We chose to download the OpenStack RC File V3. You should obtain something like this:

#!/usr/bin/env bash

export OS_AUTH_URL=https://keystone.xxxxxx:5000/v3
export OS_PROJECT_ID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export OS_PROJECT_NAME="xxxxxxxx"
export OS_USER_DOMAIN_NAME="xxxxxxxx"
if [ -z "$OS_USER_DOMAIN_NAME" ]; then unset OS_USER_DOMAIN_NAME; fi

# unset v2.0 items in case set
unset OS_TENANT_ID
unset OS_TENANT_NAME

export OS_USERNAME="xxxxxxxx"
export OS_REGION_NAME="xxxxxxxx"
# Don't leave a blank variable, unset it if it was empty
if [ -z "$OS_REGION_NAME" ]; then unset OS_REGION_NAME; fi

export OS_INTERFACE=public
export OS_IDENTITY_API_VERSION=3

# to be added
export OS_PASSWORD="xxxxxxxx"
export OS_CLOUD=xxxxxxxx
export OS_CACERT=/home/loic/.certs/openstack_cacert.pem

Example of rc_file

Note that we’ve removed the lines which ask for your password when you use the CLI and add it to “never ask again”. You also have to provide OS_CLOUD and OS_CACERT (even if you don’t have a certificate to access to your OpenStack infrastructure, you must provide one but you can keep it blank).

Now, you can install the OpenStack CLI with the command line. We’ll show two ways to do this below:

with virtualenv

virtualenv ~/openstack
source ~/openstack/bin/activate
pip install python-openstackclient

with conda

conda create -n openstack python=3.6
source activate openstack
pip install python-openstackclient

Next, source your rc file to activate it

source rc_file

and test your connection

openstack project list

You should be able to see your projects listed.

Once you have access, you will need some information in order to use terraform with Kubespray. You should find the following things (we have highlighted them in the images below):

The name of the image you want to deploy. To list it, run the following command:

openstack image list

List of OpenStack images

The id of the flavor describing the type of machine you want to deploy (the flavor must be aUUID and not an integer ID). To find it, run this command:

openstack flavor list

List of OpenStack flavors

Once you’ve got this information, it’s time to install Kubespray.

Install Kubespray

Because Kubespray is simply a GitHub repository, we don’t “install” it in a traditional sense, we only clone the repository to our machine. Since Kubespray is a project that evolves quickly, we’ll list the commit that we used for this post. Run the following command to get Kubespray:

git clone https://github.com/kubernetes-incubator/kubespray.git
cd kubespray
git checkout 3632290

Next, prepare all the files describing your Kubernetes cluster. We’ll follow the documentation given by Kubespray and will just change some flags. We encourage you to follow the procedure described below as the documentation seems to have some errors.

Kubespray uses terraform and ansible to deploy your Kubernetes cluster. ansible needs an inventory file which describes your cluster in order to execute the playbook roles on it. Kubespray provides a skeleton dedicated to OpenStack platform to provision your cluster using terraform and create the inventory file for ansible accordingly. To use the skeleton provided by Kubespray, the steps are the following

cp -LRp contrib/terraform/openstack/sample-inventory inventory/jhub
cd inventory/jhub
ln -s ../../contrib/terraform/openstack/hosts

jhub is the name directory we choose to store our inventory but you can choose what you want.

If you look at the inventory/jhub directory you will see

cluster.tf: the terraform file describing your inventory.
group_vars: the directory where we set all the variables used by ansible scripts provided by Kubespray.

Let’s describe our inventory.

Initialize Terraform

In the cluster.tf file, you can specify different kinds of Kubernetes clusters with floating IP for each VM. floating ip means that you ask to OpenStack to give you a public IP address in order to connect to the VM from an external network. You can also have a bastion where you have to log before reaching your Kubernetes cluster.

In the following, we only choose to have a master VM and two nodes for our Kubernetes cluster. Another important part is to specify a GlusterFS to have some storage resources for JupyterHub (database and home directories). Our inventory file cluster.tf looks like this

# your Kubernetes cluster name here
cluster_name = "jhub"

# SSH key to use for access to nodes
public_key_path = "~/.ssh/id_rsa.pub"

# image to use for bastion, masters, standalone etcd instances, and nodes
image = "CentOS-7-x86_64-GenericCloud-20180108.qcow2"
# user on the node (ex. core on Container Linux, ubuntu on Ubuntu, etc.)
ssh_user = "centos"

# 0|1 bastion nodes
number_of_bastions = 0
# standalone etcds
number_of_etcd = 0

# masters
number_of_k8s_masters = 1
number_of_k8s_masters_no_etcd = 0
number_of_k8s_masters_no_floating_ip = 0
number_of_k8s_masters_no_floating_ip_no_etcd = 0
flavor_k8s_master = "5e879c45-e709-4671-a38b-45ed0573dc38"

# nodes
number_of_k8s_nodes = 0
number_of_k8s_nodes_no_floating_ip = 2
flavor_k8s_node = "5e879c45-e709-4671-a38b-45ed0573dc38"

# GlusterFS
# either 0 or more than one
number_of_gfs_nodes_no_floating_ip = 2
gfs_volume_size_in_gb = 100
# Container Linux does not support GlusterFS
image_gfs = "CentOS-7-x86_64-GenericCloud-20180108.qcow2"
# May be different from other nodes
ssh_user_gfs = "centos"
flavor_gfs_node = "5e879c45-e709-4671-a38b-45ed0573dc38"

# networking
#network_name = "<network>"
external_net = "6cd08271-..."
#subnet_cidr = "<cidr>"
floatingip_pool = "public"

dns_nameservers = ["8.8.8.8", "8.8.4.4"]

The flavors are the same for each master, node, and GlusterFS but you can do what you want. We also added dns_nameservers to be sure that we have a correct DNS on each nodes. We will check in future experiments if it’s really necessary.

The ID of the external network and the name of the floatingip_pool can be obtained with the following command:

openstack network list

List of OpenStack networks

You need ssh keys to be able to connect to the nodes. From the documentation of Kubespray:

Ensure your local ssh-agent is running and your ssh key has been added. This step is required by the terraform provisioner:

eval $(ssh-agent -s) ssh-add ~/.ssh/id_rsa

Now, it’s time to initialize terraform. It’s important for the next steps to be run from the root directory of Kubespray.

terraform init contrib/terraform/openstack

Now, create your VMs!

terraform apply -state=inventory/jhub/terraform.tfstate -var-file=inventory/jhub/cluster.tf contrib/terraform/openstack

At the end of this process, you can see your instances in the dashboard of OpenStack. It’s important to keep the information given at the end of the output.

At this stage, you’ve just created several VMs with the images given in the cluster.tf file. You don’t have a Kubernetes cluster up and running yet. It’s the next step!

Note: If you want to destroy all that you’ve done, run this command:

terraform destroy -state=inventory/jhub/terraform.tfstate -var-file=inventory/jhub/cluster.tf contrib/terraform/openstack

Configure your Kubernetes cluster

Again, Kubespray lets you configure your Kubernetes cluster with a lot of possibilities. We will show you one setup, but once you understand the procedure, you should be able to make your own choices.

Let’s start to see if we can ping our VMs. You have to add the following script that we called ssh-nodes.conf in your inventory/jhub directory

Host 10.0.0.*
    User centos
    UserKnownHostsFile=/dev/null
    StrictHostKeyChecking=no
    ProxyCommand ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -W %h:%p centos@134.xx.xx.xx

You also have to modify the ssh_args variable in ansible.cfg script in the root directory of Kubespray accordingly

ssh_args = -F inventory/jhub/ssh-nodes.conf -o ControlMaster=auto -o ControlPersist=30m -o ConnectionAttempts=100 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

Just pay attention that you give the right external address and that your internal network is 10.0.0.*.

To check that everything is configured correctly, this command:

ansible -i inventory/jhub/hosts -m ping all

should have an output like this

You can now install your Kubernetes cluster with the ansible scripts provided by Kubespray. To do that, you will edit the files found in the group_vars directory in inventory/jhub.

You need several things to have a JupyterHub up and running

A CNI (Container Network Interface). Kubespray offers different CNI for your Kubernetes cluster: cilium, calico, contiv, weave or flannel. We will choose calico.

Storage for the data. We’ll deploy a GlusterFS and add storage on the Kubernetes cluster to have access to it.

A LoadBalancer to have access to the service from the external network. You have two kinds of LoadBalancer on Openstack: Neutron or Octavia. You can use both with Kubespray. We will choose Neutron but it will be preferable to use Octavia in the future.

So how do we configure all these items?

First, open the file inventory/jhub/group_vars/all/all.yml and modify the following entries

bootstrap_os: centos

upstream_dns_servers:

    - 8.8.8.8

    - 8.8.4.4

cloud_provider: openstack

Note that the dns address is specific to our infrastructure.

Now, open the file inventory/jhub/group_vars/all/openstack.yml and configure the LoadBalancer

openstack_lbaas_enabled: True

openstack_lbaas_subnet_id: "48ec8433-..."

openstack_lbaas_floating_network_id: "6cd08271-..."

The two IDs are those given at the end of the terraform apply step.

Open the file inventory/jhub/group_vars/k8s-cluster/k8s-cluster.yml and set persistent_volumes_enabled to true and resolvconf_mode to host_resolvconf.

Our OpenStack cloud infrastructure is configured with a VXLAN tunnel where the header size is 50 bytes. We use Calico with Kubernetes which also uses a VXLAN tunnel with a header of 50 bytes. Then, for a default MTU of 1500 bytes, we already have 100 bytes taken by the headers. So, we need to configure carefully the MTU of calico in order to be sure that the packet size (headers included) doesn’t exceed the 1500 bytes.

To configure the MTU of calico, we have to edit the file inventory/jhub/group_vars/k8s-cluster/k8s-net-calico.yml and set the calico_mtu flag to 1400.

It’s important to notice that setting MTU had no effect for OpenStack versions earlier than Pike. The LoadBalancer didn’t work correctly.

The last file to modify is inventory/jhub/group_vars/k8s-cluster/addons.yml. JupyterHub uses Helm charts to deploy all that you need on the Kubernetes cluster and Kubespray can install Helm for you. So just set the helm_enabled flag to true.

Now we can run ansible playbook

ansible-playbook --become -i inventory/jhub/hosts cluster.yml

You can take a coffee break because it takes time to install all the stuff. At the end of this process, you have a Kubernetes cluster up and running.

To be sure, log in on the master nodes (the external address given by terraform) and enter the command

kubectl -n kube-system get pods

You should be able to see all pods of the kube-system namespace running.

The last step is to install the persistent volume from our GlusterFS.

ansible-playbook --become -i inventory/jhub/hosts ./contrib/network-storage/glusterfs/glusterfs.yml

If you log in again to the master of your Kubernetes cluster and enter the following command

kubectl get pv

you will see your GlusterFS storage connected to your Kubernetes cluster.

Install JupyterHub

Now that you have a Kubernetes cluster running, the procedure to install JupyterHub is exactly the same as the one described in Zero to JupyterHub. The only difference is that you don’t have to install Helm, since Kubespray did it for you. We’ll post the commands below, and you can go to the Zero to JupyterHub website for more information.

The first step is to log in to the master node of your Kubernetes cluster. Then, initialize Helm.

helm init --service-account tiller

kubectl patch deployment tiller-deploy --namespace=kube-system --type=json --patch='[{"op": "add", "path": "/spec/template/spec/containers/0/command", "value": ["/tiller", "--listen=localhost:44134"]}]'

Next, follow the procedure described here

Setting up JupyterHub - Zero to JupyterHub with Kubernetes 0.7.0 documentation

If the LoadBalancer did its job, you should be able to see the external IP to connect to your JupyterHub

kubectl -n jhub  get svc

If you enter this address in your web browser. If everything worked, you will see the JupyterHub login page:

JupyterHub login page

Wrapping up and feedback

The steps above described our attempts at running a JupyterHub on Kubernetes using OpenStack. There are likely many other ways to accomplish the same thing, and we’d love to hear feedback on the best procedure to install JupyterHub or BinderHub on OpenStack infrastructure. If you have encountered any issues, please leave a comment or ping us on the gitter channel of JupyterHub or Binder.

Thanks to the Project Jupyter team for their review and helpful comments and especially to Sylvain Corlay and Chris Holdgraf.

About the Authors (alphabetical order)

David Delavennat, Research Engineer in Scientific Infrastructures at CMLS (Polytechnique/CNRS) and INSMI (CNRS)
Loïc Gouarin, Research Engineer in Scientific Computing at CMAP (Polytechnique/CNRS)
Guillaume Philippon, Research Engineer in Scientific Infrastructures at LAL (IN2P3/CNRS)

Introducing Jupyter Enterprise Gateway

2018-09-17T20:19:00+00:00

by Luciano Resende, Kevin Bates, Alan Chin

Yesterday, the Jupyter Steering Council voted to make Jupyter Enterprise Gateway a top-level Jupyter Project. I want to thank everyone for their contributions so far — code from my teammates at IBM and the community in general; advice from the Jupyter development team and mentors; and questions, issues, and requirements from end users.

As we become an official Jupyter project, I would like to take the opportunity to give an update on the project’s progress during our incubation period.

What is Jupyter Enterprise Gateway?

Jupyter Enterprise Gateway enables Jupyter Notebook to launch remote kernels in a distributed cluster, including Apache Spark managed by YARN, IBM Spectrum Conductor or Kubernetes.

Although Enterprise Gateway is mostly kernel agnostic, it provides out of the box configuration examples for the following kernels:

· Python using IPython kernel

· R using IRkernel

· Scala using Apache Toree kernel

Jupyter Enterprise Gateway does not manage multiple Jupyter Notebook deployments, for that you should look for JupyterHub. Having said that, Enterprise Gateway can enable JupyterHub to launch remote kernels as individual Kubernetes pods, providing better resource allocation and enabling better environment management as each pod can be based on different images (e.g. TensorFlow, Anaconda, etc)

Supported Platforms

Jupyter Enterprise Gateway currently enables remote kernels in the following platforms:

Distributed Kernels in Apache Spark

Jupyter Enterprise Gateway leverages different resource managers to enable distributed kernels in Apache Spark clusters. One example shown below describes kernels being launched in YARN cluster mode across all nodes of a cluster.

Jupyter Enterprise Gateway leverages Apache Spark resource managers to distribute kernels

Note that, Jupyter Enterprise Gateway also provides some other value-added capabilities such as enhanced security and multiuser support with user impersonation.

Jupyter Enterprise Gateway provides Enhanced Security and Multiuser support with user Impersonation

Distributed Kernels in Kubernetes

Jupyter Enterprise Gateway support for Kubernetes enables decoupling the Jupyter Notebook Server and its kernels into multiple pods. This enables running Notebook server pods with minimally necessary resources based on the workload being processed.

Jupyter Enterprise Gateway enable remote kernels on Kubernetes cluster

Jupyter Enterprise Gateway and JupyterHub

JupyterHub is a multi-user server that manages and proxies multiple instances of the single-user Jupyter notebook server. Particularly in a Kubernetes environment, Jupyter Enterprise Gateway can enable JupyterHub to launch remote kernels as individual Kubernetes pods, providing better resource allocation and enabling better environment management as each pod can be based on different images (e.g. TensorFlow, Anaconda, etc). This has proven to be very desired, particularly when working on Deep Learning related Notebooks.

JupyterHub and Jupyter Enterprise Gateway together in a Kubernetes cluster

Some project metrics

The following stats have been collected from the Jupyter Enterprise Gateway GitHub repository during the incubation period:

10 releases

12 individual contributors

90 Stars

34 Forks

Source code, documentation, and other community resources

The Jupyter Enterprise Gateway community provides multiple resources that both users and contributors can use:

Source Code available at GitHub
https://github.com/jupyter/enterprise_gateway

Documentation available at ReadTheDocs
http://jupyter-enterprise-gateway.readthedocs.io/en/latest/

Automated builds available at Travis.CI
https://travis-ci.org/jupyter/enterprise_gateway

Releases available at PyPi.org and Conda Forge
https://pypi.org/project/jupyter_enterprise_gateway/
https://github.com/conda-forge/jupyter_enterprise_gateway-feedstock

Related Docker Images available at Elyra organization at DockerHub
https://hub.docker.com/u/elyra/dashboard/

What’s next?

We are eager to build an even greater community around the project, and tailor the project roadmap based on community advise.

Currently, we are busy working on advancing our Kubernetes support and integration with JupyterHub.

As always, we welcome questions, comments, and suggestions from users and the community in general.

Announcing the JupyterHub Helm Chart v0.5

2017-12-20T16:24:00+00:00

JupyterHub makes it possible to serve Jupyter instances to multiple users. The JupyterHub Helm Chart makes it possible to run this setup on kubernetes, making JupyterHub more scalable, stable, and flexible.

We, the JupyterHub team, are proud to announce the next version of the JupyterHub Helm Chart: version 0.5. This post describes a bit of what’s new in this release. We’ve nicknamed the releases of the JupyterHub Helm Chart after famous cricketers, in this case world-class bowler Hamid Hassan*.

tl;dr: The release bumps JupyterHub to 0.8, adds better HTTPS support, and improves scalability to ~4,000 simultaneous users. See the Helm Chart Changelog for more information.

New Features

The following major features have been added to v0.5:

JupyterHub 0.8

Version 0.8 of JupyterHub was released earlier this year. It is full of new features, many of which directly benefit the Kubernetes deployment of JupyterHub. Below is a list of relevant points along with the relevant sections of the Helm Chart configuration:

Lots of performance improvements. We now know we can handle up to 4k active users.
Limit the number of users who can try to launch the hub at once. This can be tuned to avoid crashes when hundreds of users try to launch at the same time. It gives them a friendly error message and asks them to try later. See hub.concurrentSpawnLimit.
Limit the number of simultaneous active users . The Active Server limit can be used to limit the total number of active users that can use the hub at any given time. This allows admins to control the size of their clusters more effectively. See hub.activeServerLimit.
Memory limits & guarantees can now contain fractional units. So you can say 0.5G instead of having to use 512M.
No more ‘too many redirects’ errors at scale. This fixes an annoying race condition causing users to get stuck in a redirect loop when starting their servers.

Easier HTTPS

Version 0.5 of the helm chart makes it easier for admins to set up HTTPS for their users with Let’s Encrypt. Users often access a JupyterHub instance from a public URL. To avoid nefarious behavior and increase security, using HTTPS is important. You can now choose to use Let’s Encrypt or a valid HTTPS certificate and key. You can also use your own HTTPS certificates & keys rather than using Let’s Encrypt. You can find the new instructions here.

More authenticators

Authenticators allow you to control who has access to your JupyterHub. The following new authentication providers have been added in 0.5:

You can now also set up a whitelist of usernames that have access to the hub (in addition to other authenticators in use). Do so by adding to the list in auth.whitelist.users.

Hub Services support

Services let you connect your JupyerHub to other web services (for example, in mybinder.org). You can now add external JupyterHub Services by adding them to hub.services. Note that you are still responsible for actually running the service somewhere (perhaps as a deployment object in Kubernetes).

More customization with `jupyterhub_config.py`

Sometimes it is useful to be able to run arbitrary extra code when setting up your deployment. You can put extra snippets of jupyterhub_config.py configuration in hub.extraConfig. Now you can also add extra environment variables to the hub in hub.extraEnv and extra configmap items via hub.extraConfigMap. This makes it cleaner to customize the hub’s configuration in ways that are not yet possible with config.yaml. You can find more information in the documentation.

More customization options for user server environments

More options have been added under singleuser to help you customize the environment that the user session is spawned in. You can…

Change the uid / gid of the user with singleuser.uid and singleuser.fsGid
Mount extra volumes with singleuser.storage.extraVolumes & singleuser.storage.extraVolumeMounts
Provide extra environment variables with singleuser.extraEnv.

More information

For more information about the JupyterHub Helm Chart, and the JupyterHub ecosystem more broadly, see the following links:

The JupyterHub documentation
The JupyterHub development repository
The JupyterHub Helm Chart development repository
The Zero to JupyterHub guide to deploying JupyterHub on Kubernetes

*Hamid Hassan is a fast bowler who currently plays for the Afghanistan National Cricket Team. With nicknames ranging from “Afghanistan’s David Beckham” to “Rambo”, he is considered by many to be Afghanistan’s first Cricket Superhero. Currently known for fast (145km/h+) deliveries, cartwheeling celebrations, war painted face and having had to flee Afghanistan as a child to escape from war. He says he plays because “We are ambassadors for our country and we want to show the world that Afghanistan is not like people recognize it by terrorists and these things. We want them to know that we have a lot of talent as well.”

Binder 2.0, a Tech Guide

2017-11-30T16:01:00+00:00

Authors: The Binder project is comprised of many individuals within and outside of the core Jupyter team. A list of members that contributed to this post is at the end of this article.

Note: this post focuses more on technical changes in the Binder 2.0 reboot. For a post about user-facing features and future plans, see this eLife blog post.

We are undergoing a dramatic increase in the complexity of techniques for analyzing data, doing scientific research, and sharing our work with others. In early 2016, the Binder project was announced, attempting to connect these three components. A blogpost in eLife described a vision where scientists could specify dependencies along with a collection of Jupyter notebooks. Binder builds a Docker image from these dependencies, and provides a URL where any user in the world can instantly recreate this environment.

Want to see it in action? Click the button below.

With this post we are proud to announce the next version of Binder. It aims to be more modular, more flexible, more stable, faster, and more extensible than its predecessor. Powering this version of Binder is a collection of tools in the Jupyter ecosystem. Since being released, the Binder project has learned many things about implementing fast, flexible online deployments. In addition, its vision has expanded to include not only Jupyter notebooks, but many other computational workflows. You can access an open beta version of this deployment here:

mybinder.org

You can find a list of sample repositories to learn how to create “Binder”-ready repositories here:

github.com/binder-examples

You can also see what the Binder community has been up to in creating their own repositories by checking the GitHub Binder topic:

https://github.com/topics/binder

Give it a shot, build some repositories, and importantly, tell us what could be improved on our GitHub repo. Below we’ll describe a bit about what’s new.

The new Binder UI. Users input a URL to a git repository (or specify a specific branch/tag/commit). Upon clicking “launch”, you will be directed to a live environment where you can interact with the code.

What’s new?

First off we’ll describe how the experience will change for users. The short answer is: not much. The goal of Binder is still enabling you to intantly create interactive and shareable repositories. We’ve completely rebuilt the backend of Binder, but we’ve made minimal changes to the front-end user experience.

The biggest difference you should notice is that Binder is both faster and more stable. You’ll still be able to generate Binder links from a git URL from a single web-page. However, there are a few key differences:

New Default Environment

Old versions of Binder were based off of a Docker image that contained a fairly heavy computational environment. The new Binder deployment makes minimal assumptions about what environment you want installed, by default the only thing that will be installed is the Jupyter Notebook and Python 3. This means you’ll need to be more expressive in the dependencies you include in your dependency files. For example, if you want numpy or matplotlib, you should specify them in a requirements.txt or environment.yml file. Since you’re explicitly listing your requirements it makes reproducing your work more reliable, and allows the Binder infrastructure to change more freely without breaking your repository code.

New URL structure

The new URL structure for Binder follows the following convention:

https://mybinder.org/v2/gh/<org-name>/<repo-name>/<branch|tag|hash-name>?filepath=<path-to-file>

For example, below is the URL for a basic Binder-ready Python 3 repository, it includes basic information about the repository:

https://mybinder.org/v2/gh/binder-examples/requirements/master

You can also specify parameters that do things like point users to a particular file or initialize a user-interface. For example, the following URL starts JupyterLab once users click the link:

https://mybinder.org/v2/gh/binder-examples/jupyterlab/master?urlpath=lab

In each case, note the gh at the very beginning — this specifies that the git URL exists on github.com. It is possible to build new URL parsers for other online repositories such as BitBucket, osf.io, or any other provider. We are currently focusing on Git and GitHub, but nothing prevents Binder from being compatible with other kinds of content providers. Shortly before this blog post we added support for arbitrary git URLs to binderhub, so watch this space.

Specify a specific branch / tag / commit

Also notice that in the URL above you can specify a branch, tag, or commit hash for the Binder image. This allows you to ensure that a Binder image will always remain the same (if you specify package versions properly). This is a crucial step for reproducibility and maintaining consistency in how users experience the files in your repository.

Notice that in the URL above you can specify a commit hash or git tag for the Binder image. This hash is unique to the state of the code at the moment that the commit was made, ensuring that Binder can rebuild the exact same environment any time. Note that if authors don’t want to guarantee the same reproducible environment, they can specify a branch and BinderHub will resolve it to the latest commit hash before building the environment.

Binder auto-building

When a git repository is launched, Binder will now check whether an image has already been built for that repository at the same commit hash. If it has, then Binder will skip the building process and take you straight to a JupyterHub instance that serves this image.

If the image hasn’t been built, then it will automatically be generated before sending the user to JupyterHub. The only difference will be the amount of time it takes before entering the JupyterHub environment. This means that authors no longer need to explicitly build their Binder images when they update a branch. The next time someone clicks a Binder link, it will happen automatically. If you don’t want this behavior, be sure to point Binder to a specific tag or commit hash, rather than a branch name or tag. For example, here’s a Binder URL that will always point to the same commit hash:

https://mybinder.org/v2/gh/wildtreetech/explore-open-data/binder20-elife

While this URL points to a branch, and will thus be re-built each time a new commit is made to that branch:

https://mybinder.org/v2/gh/wildtreetech/explore-open-data/master

More options for dependency files

Users often want to specify a computational environment that is more complex than a simple list of Python requirements. While this is possible by specifying a Dockerfile, it’s often an overly-complicated solution to this problem. Binder now uses repo2docker to build a Docker image from your repository. This makes it possible to specify a more complex environment with text files. For example, you can use an apt.txt file to install packages with apt-get, or use a file called postBuild to define shell commands that are run before generating the Docker image (e.g. for downloading some data or running scripts). See the repo2docker documentation for a list of files that are supported with Binder.

For a selection of examples that show off how to specify dependencies take a look at the example gallery: https://github.com/binder-examples

More user interfaces

The JupyterLab interface running on Binder. You can access the JupyterLab demo repository at ``mybinder.org/v2/gh/binder-examples/jupyterlab/master?urlpath=lab

The previous iteration of Binder only supported the classic Jupyter Notebook user interface, while the new deployment will additionally support RStudio and JupyterLab. Because of the extra build configuration files specified above, you can also utilize more tools in the Jupyter widgets ecosystem, such as the RISE plugin for interactive presentations or the appmode plugin to generate interactive apps from your repository. We also welcome contributions to add support for other user interfaces.

More online repository providers

While GitHub is a fantastic repository of open-source code, it’s not the only repository. The new Binder deployment makes it straightforward to adding support for new sources of code (for example, GitLab, the OSF, or even non-git codebases). Currently GitHub is the only supported source for code, but we welcome contributions enabling support for new sources.

We’re excited about this next step in Binder’s development, and hopeful that we can build a community around this powerful set of tools. Don’t hesitate to open an issue or pull request on our GitHub repository, or to reach out via our Gitter channel. We look forward to seeing what comes next, and to continue enabling reproducible and open workflows in data science and research.

For developers

The next few sections are meant for developers interested in deploying their own Binder, or for those interested in the technical details behind the new deployment.

Tech components

The three main technical components behind the new Binder backend are:

BinderHub, currently on display at mybinder.org and contained in the binderhub repository.
repo2docker, a tool that converts a code repository into a Docker image with an environment specified via dependency files (e.g., requirements.txt).
JupyterHub, which hosts user instances with a server in the cloud. We use a distribution of JupyterHub that runs on top of Kubernetes.

For more information on the infrastructure behind Binder, see the documentation.

A prototype of RStudio running in a Binder. This is currently support with a Dockerfile, and we are working on supporting R build files natively. You can access this repository at: <https://mybinder.org/v2/gh/binder-examples/dockerfile-rstudio/master>

Kubernetes

Binder now also heavily relies on Kubernetes for scaling our image building service and the JupyterHub. Kubernetes is massively scalable and has a strong community of developers behind it. Moreover, Kubernetes is cloud-agnostic. It can be run on Google Cloud, Microsoft Azure, and AWS among others, as well as on your own bare metal hardware if needed. Because BinderHub is built to run on top of Kubernetes, you can deploy Binder off of any of these resources as well (see below).

Deploying your own Binder server

While mybinder.org will continue to exist as a public service, we hope to see new Binder deployments for many different use cases in the wild. One of our primary goals is to make it easier for users to deploy their own Binder servers. This is relatively straightforward by following the instructions on the BinderHub documentation, which are currently under active development to make ongoing improvements as the Kubernetes technology evolves. We’re continuously updating these steps to make them as clear as possible, so please don’t hesitate to open an issue or a pull request on our github repository and make suggestions.

We would love to see others deploy their own BinderHub servers, either for their own communities, or as part of a federated public service of BinderHubs.

Future development

This is the just the beginning of new features and improvements to Binder. We’re working hard to grow an open-source community around these tools, and we encourage issues, comments, and PRs on the BinderHub, repo2docker, and JupyterHub repositories. We look forward to growing the Binder ecosystem, and we’re excited to see all of the Binders that people design.

Acknowledgements (alphabetical order)

C. Titus Brown (UC Davis), Matthias Bussonnier (UC Berkeley), Jessica Forde (UC Berkeley), Brian Granger (Cal Poly), Tim Head (Wild Tree Tech), Chris Holdgraf (UC Berkeley), Andrew Osheroff (Google), Naomi Penfold (eLife Sciences), M Pacer (UC Berkeley), Yuvi Panda (UC Berkeley), Fernando Perez (UC Berkeley), Min Ragan-Kelley (Simula Research Laboratory), and Carol Willing (Cal Poly). The Binder project is currently being funded from a grant from the Moore Foundation.

Introducing the Helm Chart for JupyterHub Deployment with Kubernetes

2017-06-29T23:21:00+00:00

The JupyterHub team proudly announces the release of a helm chart for deploying JupyterHub on Kubernetes clusters. We’ve designed the JupyterHub helm chart to save you time in creating JupyterHub deployments.

You can find a repository with the helm chart here.

This is a pre-release version of the helm-chart. It will likely change in a breaking fashion sometime in the future, though we will make every effort to minimize this as much as possible as modifications are made for new features and increased stability. If you have any questions or comments, reach out to us on Gitter or open an issue. For help with deploying your own JupyterHub instance, see our guide for setting up JupyterHub (which uses this helm chart). Or, come find us at the JupyterHub talk at JupyterCon.

The following principles guided development:

Easy to administer

The nitty gritty of JupyterHub setup and management can be cumbersome, complicated, and time-consuming. With the JupyterHub helm chart, you will spend less time debugging your setup, and more time deploying, customizing to your needs, and successfully running your JupyterHub. Within a cloud computing infrastructure, using the helm chart typically requires only one or two commands to get started.

Open source

The JupyterHub helm chart uses applications and codebases that are open and thriving. We prefer, prioritize, and select tools that have a history of stability and development, and which adhere to open-source principles when it comes to project and community growth. As a result, you’ll be able to easily connect with the many tools available in the open-source community, and you’ll have flexibility in where you deploy JupyterHub.

Cloud agnostic

We’ve made an effort to keep our helm chart as cloud-agnostic as possible. The only requirement is that your computing provider supports the Kubernetes infrastructure, an open-source platform that is widely available across many different online providers. You can run JupyterHub on cloud services such as Google Cloud, Microsoft Azure, and Amazon EC2, and even on your own hardware or institution-specific setup.

Scalable

We’ve taken great care to develop the JupyterHub helm chart with the ability to be used in a variety of work, research, and education settings. Some JupyterHub deployments have a dynamic userbase that works in spurts of activity. Others have users that have long periods of inactivity. Rather than capping the amount of resources available for users, the JupyterHub helm chart utilizes Kubernetes to scale computational resources up (or down) as needed. This means that large changes in user behavior don’t result in system-wide instability or slowdown issues. It also means that you can quickly update user hardware, push new files to user disks, and alter the environment in which users are operating.

JupyterHub has been deployed in a variety of places, including at least one class with nearly 1500 students. We’ve made sure that it can handle large groups of users, and we’re excited to see people push the limit even further.

Support

If you have any questions or comments, reach out to us on Gitter or open an issue. For help with deploying your own JupyterHub instance, see our guide, Zero to JupyterHub. Or, come find us at the JupyterHub talk at JupyterCon.

Acknowledgements

JupyterHub and this helm chart wouldn’t have been possible without the goodwill, time, and funding from a lot of different people. In particular, we want to thank the Gordon and Betty Moore Foundation, the Sloan Foundation, the Helmsley Charitable Trust, the Berkeley Data Science Education Program, and the Wikimedia Foundation for supporting various members of our team. We also want to thank the individuals of the JupyterHub team (listed below), the Project Jupyter community, and our more than 100 contributors for continuing to grow and improve this technology.

Sincerely,
The JupyterHub Team (in alphabetical order)

Berkeley Data Science Education Program (Gunjan Baid, Sam Lau, Ryan Lovett, Yuvi Panda, Vinitra Swamy)

Cal Blueprint Team (Jiefu Gong, Sam Lau, Derrick Mar, Peter Veerman, Tony Yang)

Project Jupyter (Chris Holdgraf, Yuvi Panda, Min Ragan-Kelley, Carol Willing)

Jupyter Blog - Kubernetes

The superheroes and the magic wand

The magic wand

The superheros

nbviewer has a new host: OVHcloud

How we moved

Where were we before?

What have we learned?

Step 1: helm chart for nbviewer

Step 1b: helm chart for cdn.jupyter.org

Step 2: automatic deployment

A 2019 retrospective from the Binder Project

More people are using mybinder.org

JupyterHub reaches 1.0

BinderHub is out of beta

The BinderHub federation is launched

Binder connects with open science services

The Binder community grows

We welcome our first Contributor in Residence

There are more BinderHub deployments

Thanks to our community

The International Binder Federation

OVH Joins the mybinder.org Federation

What does this mean?

Why is this a big deal?

What’s next?

BinderHub is out of Beta!

Who else has deployed a BinderHub?

What’s next?

Introducing TraefikProxy — a scalable and highly available proxy for JupyterHub

Zero to JupyterHub helm chart 0.8

Profiles

Autoscaling

MyBinder.org serves two million launches

What is mybinder.org?

Who is using mybinder.org?

Data set of all launches on mybinder.org

A new badge!

Open infrastructure in the cloud

On-demand Notebooks with JupyterHub, Jupyter Enterprise Gateway and Kubernetes

On-Demand Notebooks Infrastructure

JupyterHub Deployment

Custom JupyterHub user image

Jupyter Enterprise Gateway deployment

Automated One-Click Deployment using Ansible

Conclusion

Special Thanks

Deploying JupyterHub with Kubernetes on OpenStack

Our story, our difficulties and our plans

Why deploy JupyterHub on OpenStack?

Issues we encountered

What’s next ?

The Technical Details

Connect to OpenStack

Install Kubespray

Initialize Terraform

Configure your Kubernetes cluster

Install JupyterHub

Wrapping up and feedback

About the Authors (alphabetical order)

Introducing Jupyter Enterprise Gateway

What is Jupyter Enterprise Gateway?

Supported Platforms

Distributed Kernels in Apache Spark

Distributed Kernels in Kubernetes

Jupyter Enterprise Gateway and JupyterHub

Some project metrics

Source code, documentation, and other community resources

What’s next?

Announcing the JupyterHub Helm Chart v0.5

New Features

JupyterHub 0.8

Easier HTTPS

More authenticators

Hub Services support

More customization with jupyterhub_config.py

More customization options for user server environments

More information

Binder 2.0, a Tech Guide

What’s new?

More customization with `jupyterhub_config.py`