From Fedora Project Wiki
(audience, use cases, research) |
(add command prompt mockup) |
||
| (6 intermediate revisions by 3 users not shown) | |||
| Line 34: | Line 34: | ||
* Desktop application development with containers - this is already covered by Flatpak | * Desktop application development with containers - this is already covered by Flatpak | ||
[[Image:container-schema.png|center|style="width: 80%; border-width: 0px; vertical-align: top;"]] | |||
== Audience == | == Audience == | ||
| Line 49: | Line 51: | ||
== Research == | == Research == | ||
To inform the design of this solution, a (very) small series of interviews was conducted with a range of different developers. Some | 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 == | == Relevant Art == | ||
| Line 70: | Line 72: | ||
* Mini-systems that you maintain (true pet containers) | * Mini-systems that you maintain (true pet containers) | ||
* Portable development environments ( | * Portable development environments (similar to Vagrant or PurpleEgg) | ||
* Lightweight servers to test complex environments (docker-compose is often used for this) | * Lightweight servers to test complex environments (docker-compose is often used for this) | ||
* Scale-out with OpenShift/Kubernetes | * Scale-out with OpenShift/Kubernetes | ||
It | 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 == | == Tentative Design == | ||
The initial plan is to build on existing "pet container" efforts and turn them into a more complete and robust solution. Elements of this: | The initial plan is to build on existing "pet container" efforts and turn them into a more complete and robust solution. Elements of this: | ||
| Line 91: | Line 91: | ||
** An interactive command-line tutorial is another possibility | ** 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 | * 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 | ||
=== Command prompt integration === | |||
[[File:Container-command-prompt.png|style="border-width: 0px; vertical-align: top;"]] | |||
== Implementation == | |||
[[/Notes|Meeting notes]] | |||
Latest revision as of 09:12, 4 April 2019
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
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
Command prompt integration
