From Fedora Project Wiki

< Workstation

Revision as of 17:24, 24 May 2018 by Aday (talk | contribs)

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 things that were seen:

  • Confusion about the environment a terminal prompt is in, when using containers
  • A range of methods used to get software, including language-specific package-managers
  • A range of methods for isolating development projects, including virtual environments, Vagrant, environment modules and virtual machines
  • Dislike of VMs, because they are heavy
  • Ongoing adoption of containers, but also some hold outs
  • A lack of need to have isolated development projects, by some
  • Enthusiasm for package managers
  • A strong preference for personalisation - *my* environment, *my* tools
  • Frustration with how complicated the command line tools are for creating containers

Relevant Art

See Relevant Art.

Discussion

A high-level typology of container usage:

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

Some of these types overlap in real-world usage. It might not be practical to support all of them, 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