Alembicue Foundation

Introduction

Overview

The aim of the project was to design, develop and release Alembicue, an integrated development environment for composing Docker images, centred around a projectional editor for Dockerfiles.

The lack of a comprehensive and integrated development environment for Docker causes issues for both developer adoption of the containerisation platform and the implementation of advanced platform functionality for professionals, as identified in gap analysis. Appropriate in-depth research of new and old editor types and functionality was necessary to establish a foundation for design with an understanding of the context of the solution.

Development was led by the choice of applicable tooling and languages including that of a language workbench forming the centre of defining and implementing a language specification. This language was derived to represent the image build language used by Docker’s image build process, while benefiting from the advantages of projectional and structural editing identified in the lessons learned from literature review. Incorporating this editor alongside orchestration mechanics to run containers based on the built images integrates an end-to-end workflow for containerisation of services, streamlining the process for novices and experts alike.

This report documents the processes involved in reaching this aim, through the completion of various objectives.

Motivation

Docker is used by more than 7 million developers worldwide (Evans Data Corp., 2018; Stack Overflow, 2019), in use by over half of all developers (Stack Overflow, 2019) and 92% of organisations (JetBrains s.r.o., 2018a). Despite this, the field is lacking a competent integrated development environment for Docker. It is left to the combined power of various tools augmenting developer knowledge to create and maintain Docker images and containers (section 3.1). These tools can be difficult to set up and use requiring a full containerisation platform installation, and may still only provide varying levels of accuracy in linting (code checking) of syntax, style and references.

A primary source of difficulty in building images for containerisation is the Dockerfile language. A Dockerfile is written by a containerisation developer and contains instructions used for the production of a Docker image, each of which creates a new build layer for the image. Docker does not provide a formal specification for the language, only officially providing a Dockerfile reference (Docker, 2018c) containing a brief description of layout, keywords and instruction parameters. To be able to write a Dockerfile, it is necessary to understand this document, which can be difficult due to the informal nature of the specification. This leads to inaccuracies and misinterpretations both in developers using the specification to write their Dockerfiles and in implementations of linting in existing tools aiming to assist developers.

This difficulty presents issues for novices and experts alike. According to the Stack Overflow Developer Survey 2019, Docker is the platform with the most interest by far from developers who are not currently developing using it (Stack Overflow, 2019). For developers looking to begin using Docker, the Dockerfile language reference can be difficult to interpret due to its informal nature. Lacking a rigid and consistent structure to the parameters and syntax used to distinguish types, it can be very easy to make a syntax error, which is only presented when the lengthy build process takes place. Furthermore, Docker is not just for development novices, with Docker ranking second in most loved platforms for development in the aforementioned survey (Stack Overflow, 2019). For experts, the advanced functionality of the Dockerfile is under-represented by tooling, yet this is the area that needs the most assistance due to its complexity. For example, multi-stage builds require careful referencing in instructions crossing stages, yet issues in tooling support and ambiguity in usage contribute to 22% of developers dreading the Docker platform (Stack Overflow, 2019).

Defining an understandable and consistent specification for the Dockerfile language, alongside an innovative editor for the language ensuring syntax compliance and providing contextual assistance in development, as part of an integrated development environment capable of supporting an entire containerisation workflow, would help novices and experts alike make the best use of the capabilities of Docker for their containerisation needs.

Benefits

The projectional editor, the core of Alembicue, edits an abstract syntax tree (AST) which directly represents the structure of the document and its content, instead of the usual text document editing, but with an interface similar to that of a standard IDE for text-based programming languages. By defining a structure of the language and behaviours for editing instances of the language, the editor enforces a requirements for properties, references and children, assisting with code completion and providing instant compliance checking for type system rules.

Since the projection in the editor is a precise and faithful reflection of the AST enforcing constraints defined in the language, it is not possible to enter invalid syntax prior to ‘parsing’ as with regular text files/editors, as there is no parsing step. For example, in a projectional editor, typing with an insertion point at a location which cannot possibly produce a valid tree with the entered characters will have no effect, as the characters are prevented from being entered by having no suitable destination.

In addition to enforcing structure and constraints based on the language, since this editor is not limited to text, the AST can be projected in alternative ways which may make understanding relationships easier. Multiple projections of nodes can be used to represent references, making parts of the file available in other locations and editable from either. Presenting the referenced node to the user ensures correct use of references, confirming that correct destinations of references are selected in the editor and by extension in the tree, and encouraging quick fixes to be performed on the secondary projection of the node, improving editing efficiency.