Jupyter on OpenShift Part 7: Adding the Image to the Catalog

Jupyter on OpenShift Part 7: Adding the Image to the Catalog

When you are deploying an application from the OpenShift web console you have the choice of deploying an image hosted on an external image registry, or an existing image which was built within the OpenShift cluster using either the Docker or Source build strategies. This is done from Deploy Image after having selected Add to project in the web console.

Read More...

Jupyter on OpenShift Part 6: Running as an Assigned User ID

Jupyter on OpenShift Part 6: Running as an Assigned User ID

When you deploy an application to OpenShift, by default it will be run with an assigned user ID unique to the project the application is running in. This user ID will override whatever user ID a Docker-formatted image may declare as the user it should be run as.

Running applications under a project as a user ID different to applications running in any other project is part of the multi-layered approach to security used in OpenShift. In this post, we will delve more into the topic of user IDs, as well as what changes would need to be made to the Jupyter Notebook image being used to enable it to run as the user ID OpenShift assigns to it.

Read More...

Jupyter on OpenShift Part 5: Ad-hoc Package Installation

Jupyter on OpenShift Part 5: Ad-hoc Package Installation

The main reason persistent volumes are used is to store any application data. This is so that if a container running an application is restarted, that data is preserved and available to the new instance of the application.

When using an interactive coding environment such as Jupyter Notebooks, what you may want to persist can extend beyond just the notebooks and data files you are working with. Because it is an interactive environment using the dynamic scripting language Python, a user may want to install additional Python packages at the point they are creating a notebook.

Read More...