Liran Tal found the Docker CLI so cumbersome that he built an open-source alternative he called Dockly. Dockly helps you manage and monitor all your Docker containers from the command line using a visual terminal interface. To get a better understanding of how Dockly improves working with Docker through the console, InfoQ asked Tal about his experience building Dockly and creating terminal-based applications.
A typical Docker CLI workflow requires you to list the containers on your system, note the name or ID of the container you want to work with, then issue a subsequent command to start the container. Dockly instead lists all containers that currently exist on your system. It allows you to start, stop, delete, and inspect those containers from one window.
Dockly is open-source software written in Node.js, Dockly installs via NPM and can be run on Linux, iOS, and Windows systems.
InfoQ: What inspired you to create Dockly?
Liran Tal: When I started working with containers more aggressively a few years back I found that even though I love working in the terminal, my use of the Docker CLI tool was repetitive and cumbersome. Listing containers wouldn't display them well due to long names or small terminal windows. Having to run commands on specific containers or images would require querying first for the container name or ID and then firing off another command, etc.
At that point I realized I need a better way of interacting with my containers but that didn't require a context switch such as multitasking to a browser to use a web UI.
InfoQ: What challenges did you face when creating Dockly?
Tal: The layout for the different widgets and information as well as their placements and real estate on the screen was challenging and I did end up re-arranging it a couple of times.
Another challenge has been about compatibility with different Node.js engines. Since Dockly might be adopted by Ops teams who rely on the OS-provided channels for package management, they hit a wall when they try to run Dockly on Node.js 4. You require a recent version of Node.js such as version 8 LTS to be able to run it.
InfoQ: What features or additions are you hoping to add in next?
Tal: I've been thinking that a type-ahead, interactive auto-completion on the containers list could be really useful as with a long list or container name you might end up scrolling until you find the desired container.
It's also worth mentioning that Matan Avneri had recently contributed some great enhancements to the project such as being able to view services, which is truly useful if you're working in a Docker swarm cluster.
InfoQ: What limitations or gaps currently exist within the tool?
Tal: For some advanced use cases, it will be interesting to further enhance the swarm cluster management or visibility into a current state of a service. Gaining some insights into the health and status of services at a quick glance would be useful.
Not exactly a limitation from a feature perspective but it always hurts me that the test suite is currently non-existent. While unit and integration tests are easy to target, the entire screen interactivity flow is trickier. Think about end-to-end (E2E) tests but for terminal interaction. I'm pretty sure that by itself it makes a terrific idea for a whole new open-source project.
InfoQ: If someone was looking to contribute to Dockly, where would be a good place for them to start?
Tal: We have a couple of nice-to-have issues open, but I've seen and merged contributions that came from users on different topics entirely, such as adding more commands and control over the containers from within the user interface, or refactoring some of the code base to make better reuse of code components and widgets throughout the terminal UI.
InfoQ: You recently spoke about developing for the terminal at JSHeroes; what tips would you have for someone who is looking to create their own console based tooling?
Tal: My primary advice for anyone building command-line tools is to pay attention and focus on developer experience by optimizing for productivity and friendliness. It is easy to forget that not all of your end-users will be advanced. If you, on the other hand, treat a command-line app as a product then it forces you to think about good defaults, good user experience, and your users will value how your app "just works".
Some of these concepts are very similar to developing for the web. For example, if the tool is busy processing, provide an indication to the user in the form of a spinner or a progress bar. Or, if something unexpected happened, provide a reasonable message to the user which isn't cryptic.
More information about Dockly can be found within the project's GitHub repository.
