You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During this project we a few lessons learned that we would like to share based on our experiencing using our own products.
(1) Too many upstream docker images
(2) Challenging to understand minimum session requirements
(1) Too many upstream docker images
Observation
In our documentation, we suggest that admins use the r-session-complete image. This image comprises several upstream images: ubuntu:22.04 → product-base → product-base-pro → r-session-complete. As an admin, this multi-layered image creates several challenges:
It is difficult for an admin to understand what is in the image. To do so, they must review three different docker files.
It is difficult for an admin to create their own r-session-complete from scratch as they need to review and understand three docker files.
It is difficult for an admin to build on top of r-session-complete:
The image is already large (5.71GB)
It comes with arbitrary versions of R and Python already installed. For example, what if I only want to use Python 3.11, but rstudio/r-session-complete:jammy-2023.03.0--fa5bcba already ships with: R 4.1.3, R 4.2.3, Python 3.8.15, and Python 3.9.14
Proposed changes
Provide admins with one image that they can:
Use without making any modifications.
Rebuild using more flexible build arguments. For example, install one or many specific versions of R and Python.
Use as an example to create their own session images.
By having no additional upstream images, it is easier for the admin to customize and understand all of the components in the image.
Below is an example image that captures these requirements:
(2) Challenging to understand minimum session requirements
Observation
r-session-complete is a good example or starting point for customers. The downside, is that the image is very large, and includes many dependencies a customer may never need.
Proposed changes
It could be helpful to document and maintain "minimal session" images. Customers with more specific needs can use these as a starting point. We tested the following images:
Recently, the sol-eng team upgrade the Workbench session images we use on Colorado. There were several major changes:
The final changes can be found here:
During this project we a few lessons learned that we would like to share based on our experiencing using our own products.
(1) Too many upstream docker images
Observation
In our documentation, we suggest that admins use the r-session-complete image. This image comprises several upstream images:
ubuntu:22.04
→product-base
→product-base-pro
→r-session-complete
. As an admin, this multi-layered image creates several challenges:Proposed changes
Provide admins with one image that they can:
By having no additional upstream images, it is easier for the admin to customize and understand all of the components in the image.
Below is an example image that captures these requirements:
Example Dockerfile
(2) Challenging to understand minimum session requirements
Observation
r-session-complete is a good example or starting point for customers. The downside, is that the image is very large, and includes many dependencies a customer may never need.
Proposed changes
It could be helpful to document and maintain "minimal session" images. Customers with more specific needs can use these as a starting point. We tested the following images:
See https://github.com/rstub/session-minimal for the Dockerfiles.
The text was updated successfully, but these errors were encountered: