Projectional, productive Dockerfile editor
Write syntactically correct Dockerfiles every time,
with a projectional editor ensuring syntax,
providing contextual intentions and
quick fixes for best practices.
Free, source code
Context-aware, intelligent suggestions
Relevant operations to the current context are always available, at an ⌥alt-↩︎enter at any time. Fix warnings and errors by choosing from multiple suggestions depending on context, or automatically apply a quickfix.
Instructions with references show a preview of the referenced content, fully editable. Edits in any location reflect everywhere, per character. Projections update to the most appropriate based on refactoring, such as numeric to name when a name is given.
This isn’t refactoring — this is multiple projections.
For example, expose provides VCS hints for
- Changed/added/removed port
- Changed/removed protocol
- Replaced port with another
See what’s changed
No more “x lines added, x lines removed”; see exactly what’s changed with context-aware gutter markers. Use the model viewer to view changes in diff views, pre-commit and from the repository history.
VCS integration for Git, Subversion and CVS
Control your local and remote Docker instances, manage images and containers, and deploy your Dockerfiles, with an intuitive visual interface.
10.11 El Capitan or later
Developer ID signed
Requires JDK 8 on 64-bit Windows 10, 8.x, or 7 SP1 with ≥3 GB RAM
Extract .zip, run
Requires JDK 8 on GNOME or KDE desktop and ≥3 GB RAM
Extract tar.gz, run
The lack of a competent integrated development environment for Docker is a detriment to the field of containerisation and cloud computing. This project documents the development of Alembicue, a projectional and productive Docker IDE, implementing a more formally specified language definition, representative of what is necessary to create images for use with a containerisation platform. Alembicue guarantees syntactic correctness with a projectional editor mutating an abstract syntax tree, incorporating contextual intentions and quick fixes to suggest and automatically apply standards and best practices. Alembicue’s launch has been a success, being received well by the community with tens of thousands of interested visitors to the project page, and elated testimonials from those having used the application and the innovative concepts portrayed within.
I would like to thank my supervisor, Dr. Daniel Reidenbach, for his consistent support and valuable feedback on my work. I would also like to thank my family and friends for their support in my studies.
alembicate, v. 1627. transitive. Chiefly figurative: to produce, refine, or transform (an idea, emotion, etc.) as if in an alembic. Cf. alembicated adj.
cue, n.2 1553. 1c. A stimulus or signal to perception, articulation, or other physiological response.
Oxford English Dictionary (1989).
alembicue, n. 2019. Chiefly emblematic: the juncture of the production of imagery and the container articulation process founded on the aforesaid.
With apologies to linguists.
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.
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.
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.