Workstation/Desktop Containers

Desktop Containers

Design and planning for facilitating container-based development on the desktop.

Goals

Primary goals:

• Allow developers to comfortably use common CLI tools on ostree-based workstation products
• Should feel familiar to those who are used to traditional package-based systems
• Transition to ostree-based workstation products should be as smooth as possible
• Integrated documentation/guidance
• Container-based development features should be accessible from the command line as well as 3rd party development apps
• Promote container-based development
  • Demonstrate the benefits of container-based development to new audiences
  • Make it easy for developers to try containers for the first time
  • Align with and complement existing container tooling
  • Provide a bridge to the wider Red Hat container ecosystem

Potential secondary goals:

• Graphical tooling to make container-based development easier and more convenient
  • A container-aware terminal application
  • A container management application
  • ...
• Red Hat Container Registry integration
  • Advertise the registry
  • Make it easy to download and use images
  • ...
• Promote containers as a way to host and manage types of development project that don't tend to use containers at the moment
• OpenShift integration, such as basic functionality to deploy images, monitor clusters

Non-goals:

• Desktop application development with containers - this is already covered by Flatpak

Audience

Fedora's desktop container solution should be attractive to:

• Existing CentOS, Fedora and Red Hat Enterprise Linux users
• Developers using other Linux distributions
• Developers from other operating systems

Desktop containers ought to offer an effective solution for a broad range of developer types, including front and back end web development, mobile, database administrators, sysadmins, DevOps and data science.

It ought to be possible to use desktop containers in combination with a range of popular development tools, including the terminal, Visual Studio Code, IntelliJ, Atom, Eclipse, Android Studio, NetBeans, Pycharm and GNOME Builder.

Research

To inform the design of this solution, a (very) small series of interviews was conducted with a range of different developers. Some findings to come out of this exercise:

• Some of those who use containers on the desktop sometimes get confused about which environment their terminal prompt is in
• Developers already use a range of methods to get their software - including packages from their distros and language-specific package-managers
• There are a range of existing methods for isolating development projects, including virtual environments, Vagrant, environment modules and virtual machines
• People don't really like the heaviness of VMs, and this is one of the factors driving container adoption
• While there is a lot of container migration going on, not everyone is sold as of yet
• Some developers don't have much need to isolate their projects, but they all need to run command line tools of some form
• Some developers *really* like package managers
• Some developers displayed a strong preference for personalisation - they felt it important to have access to *their* environment and *their* tools
• Some find the existing command line tools for container creation to be too complicated

Relevant Art

See Relevant Art.

Discussion

A high-level typology of container usage:

• Mini-systems that you maintain (true pet containers)
• Portable development environments (this is what PurpleEgg was about)
• Lightweight servers to test complex environments (docker-compose is often used for this)
• Scale-out with OpenShift/Kubernetes

It wouldn't be practical to support all of these, and some of them might require different solutions.

Tentative Design

Phase one: privileged toolboxes

The initial plan is to build on existing "pet container" efforts and turn them into a more complete and robust solution. Elements of this:

• High-level command line tools to allow creating and running containers, including "toolbox" containers
• "Toolboxes" are envisioned to be privileged containers, which contain enough Fedora to run DNF and allow installing packages. It would be good to have one available out of the box, and make it possible to create more as necessary.
• Have the terminal prompt default to run within a toolbox environment
• Provide high-quality documentation
  • This should link to and/or integrate with other container-specific documentation
• Effective onboarding (needs design)
  • Could potentially show some help the first time the terminal is used
  • An interactive command-line tutorial is another possibility
• Potentially modify the default bash prompt, to indicate whether the prompt is in a container or the host, and whether the container is privileged or not