| For students, unless there are allocated server resources with network access, it SHOULD/MUST scale down to one local offline ARM64 node (because school districts haven't afforded containers on a managed k8s cloud for students at scale fwiu, though universities do with e.g. JupyterHub and BinderHub [4] and Colab). For Chromebook sysadmins, Instructors, and Students learning about how {Linux*, ChromiumOS, Android, Git, Bash, ZSH, Python, and e.g. PyData Tools supported by NumFOCUS} are developed, for example; When you git commit to a git branch, and then `git push` that branch to GitHub, and create a Pull Request, GitHub Actions runs the (container,command) tasks defined in the YAML files in the .github/workflows/ directory of the repo; so `git push` to a PR branch runs the CI job and the results are written back as cards in the Pull Request thread on the GitHub Project; saving to the server runs the (container,command) Actions with that revision of the git repo. Somewhat-equivalent GitOps CI Continuous Integration workflows (without Bazel or Blaze or gtest or gn, or GitHub Enterprise or GitHub Free due to the kids' intererests) that might be supported at least in analogue by Education and Chromebooks: k8s with podman-desktop in a VM, Gitea Actions (nektos/act; like Github Actions), devpod devpod: https://github.com/loft-sh/devpod : > Codespaces but open-source, client-only and unopinionated: Works with any IDE and lets you use any cloud, kubernetes or just localhost docker. (with devcontainer.json, like Github Codespaces) devcontainer.json is supported by a number of tools; e.g. VScode, IntelliJ,: https://containers.dev/supporting repo2docker has buildpacks (like Heroku and Google AppEngine). repo2docker buildpacks should probably work with devcontainer.json too? repo2docker docs > Usage > "REES: Reproducible Execution Environment" describes what all repo2docker will build a container from: https://repo2docker.readthedocs.io/en/latest/specification.h... jupyterhub/repo2docker builds a Dockerfile (Containerfile) from git repo (or a Figshare/Zenodo DOI) that minimally has at least an /environment.yml and /example.py (and probably also at least a /README.md to start with), and installs a current, updated version of jupyter notebook along with whatever's in e.g. /environment.yml per the REES spec. [1][2][3] [1] repo2docker/buildpacks/base.py: https://github.com/jupyterhub/repo2docker/blob/main/repo2doc... [2] "Make base_image configurable" https://github.com/jupyterhub/repo2docker/commit/20b08152578... [3] repo2docker/buildpacks/conda/environment.py-3.11.yml:
https://github.com/jupyterhub/repo2docker/blob/main/repo2doc... [4] "When to use [TLJH or Z2JH]" https://tljh.jupyter.org/en/latest/topic/whentouse.html SLSA; Supply-chain Levels for Software Artifacts: https://security.googleblog.com/2022/04/how-to-slsa-part-2-d... https://slsa.dev/blog/2023/06/slsa-github-worfklows-containe... How do ContainerSec, DevOpsSec, and UI/UX apply to getting a perhaps necessarily at least sometimes restricted set of containers provisions to support STEM lab module workflows for learning? 1. Instructor: Specify e.g. docker.io/busybox:latest, and docker.io/buildpack-deps:container_tag as the necessary containers for the course/module/day 2. Student: Login to that context (as allowed by domain policy if necessary), have the container images pulled according to idk like a syllabus.yml before the schema.org/CourseInstance :eventSchedule :Event begins or at the start of class per a distributed URL/QRcode. 3. Student: Review and manage which containers are running with something like the podman-desktop indication bar applet. 4. Student: git push a repo of notebooks to be graded with ottergrader, okpy, nbgrader (and get feedback on a Pull Request) Gaps/Challenges/Opportunities: Instructors don't have CI workflows implemented in curricula, but easily could create a git repo that works with repo2docker and/or devcontainers.json. Education Organizations don't have control over which containers are running on students' managed workstations, do have such monitoring for which apps are so errantly provisioned; and so students don't have containers but do have apps. Android Apps are installed as APKs, which are a ZIP file with a manifest. Binaries on Android devices will not run without SELinux labels. SELinux labels for executables on Android can only be granted by (root or) a the process that installs the APKs. This means that other installers like pip and apt (in Termux or any app off the Android Google Play Store with the new SDK) cannot work in an Android App in a VM on a Chromebook. This means that e.g. Termux could work from the Play Store only if they repack every installable package as an APK on the Play Store. Python is installable with Termux on Android with Fdroid; but the Fdroid Android App repository ("Allow third party sources" (with a different cert trust root)) doesn't work on Chromebook Android, so FWICS you can't install Python with Termux apt on a managed Chromebook, and you can't keep sideloaded APKs from Fdroid updated with an unmanaged Chromebook: a [Google] dev would just use containers in a VM (or CI) instead. JupyterLite and VScode.dev work in a browser tab because everything is compiled to WASM (WebAssembly), but the browser traps shortcuts like Ctrl-P. So then you might say, "wrap JupyterLite in Electron or similar so it works offline as an app with all the keyboard shortcuts that you need".
(Electron apps run a web app locally in a browser without the chrome (the address bar and back buttons); but if 5 apps each depend upon unique copies of Electron that they must repack and that users must keep updated, app sizes are suboptimal due to lack of a proper package dependency model for Android APKs.) Flatpack is neat, supports package dependency edges, and supports having multiple versions of a package installed, but most flatpaks have similar boundary violations where the guest container is insufficiently isolated from the host machine. VScode flatpak, for example, can call commands on the host with `flatpak-spawn` or `host-spawn` or the additional package for the vscode flatpak copy of the `podman-remote` go binary. distrobox and fedora/toolbox make it easy to mount your entire $HOME into the container with the correct UID and file permissions: `distrobox create arithmetic; distrobox enter arithmetic` provisions a container and opens an interactive shell within the container. ChromiumOS's zygote messages also cross container/vm boundaries IIRC. gvisor is considered good enough to contain containerized workflows for shared multitenant workloads at Google; and so it should also probably be useful for getting devcontainers.json and at least vscode working on Chromebooks for the kids. |
chromiumos/docs/+/HEAD/containers_and_vms.md > Can I run Wayland programs? with Sommelier: https://chromium.googlesource.com/chromiumos/docs/+/HEAD/con...
But that doesn't solve because containers and vms aren't on and aren't supported for their accounts.
A school chromebook's access to containers could be controlled by setting the containers.conf repo URL to a Container Image Repository controlled by the school. GitHub, Gitea, and GitLab all support storing (OCI) container images.
An instructor would import a container image with an associated Pull Request that causes an Action to run to (1) scan the container and its SBOM Software Bill of Materials; before (2) hosting the container image for the students and (3) regularly (along with e.g. Dependabot, which for security regularly checks for references to outdated versions of software in GitHub repos) .
It looks like GitHub supports 3rd party code scanning tools, too; so Instructors and Students could auto-scan for security vulnerabilities and get reports back in the Pull Request https://docs.github.com/en/code-security/code-scanning/intro...
GitHub Project Templates are designed to be forked; e.g. like an assignment handout to be filled out (that already has an /.github/workflows/actions.yml and README.md headings). Cookiecutter is another way to create a project/assignment/handout/directory/git_repo skeleton; with jinja2 templates to generate file names like `/{{name}}/README.md` and file contents like {% if name %}<h1>Hello World, {{name}}{% endif %} . jinja2 is a useful skill also for ansible [collections of roles of] playbooks of tasks.
chromebook-ansible installs a number of apps by default (including docker and vscode (instead of podman and vscodium or similar)), but because there are variables in the playbook, you can change which parts of the playbook runs by specifying different parameters with ansible inventory: https://github.com/seangreathouse/chromebook-ansible#include... https://github.com/seangreathouse/chromebook-ansible/blob/c8...
It would be helpful to be able to provision [Android and Chromebook] devices with [Ansible] like it is possible with Mac, Windows, and Linux devices (without a domain controller; decentralizedly and for bootstrapping). It appears that there happens to be no way to `adb install play-store://url` with Ansible, but there is news about Ansible support for Enterprise Chromebooks.
There are [vscode] IDE mentions in the chromebook git repos IIRC. The [vscode] [docker/podman extension] could work with aforementioned functionality to limit which containers can be pulled or are running at a given time.
USE CASE (for a "STEM workstations for learning" spec): Create a minimal git repo project from a project template with cookiecutter-pypackage or similar.
A minimal project [template] would have at least:
This is a very common workflow for STEM (PyData) software; how is it done with Win/Mac/Lin (and bash and git) and how do we do this with our Chromebook with no Terminal or Containers?