Bills of materials or BOMs are nothing new, but they are new in the software industry. They have been part of many supply chains for decades. When you purchase a car or a pharmaceutical device, the manufacturer of those products maintains a list of...
Singularity Containers For Compute-Driven Workloads In 2018: Results For The Community And Community-Motivated Roadmap
At this juncture, the Singularity Community has advanced a number of use case examples that all have the above paradigm in common – i.e., streamed workloads, real-time analysis, and data pipelining into compute-focused services. What may not be readily obvious from examples like this is the innate ability of Singularity to singularly bridge the containerization requirements of both the compute-driven workloads that characterize Enterprise Performance Computing (EPC) simultaneously with those typical of services-based deployments. Whereas Community members are already employing Singularity containers in the demanding, complex use cases shared here, this uptake has resulted in various additional requirements. To ensure that Singularity continues to be relevant to its Community, in the final section of this post we share items from the roadmap that better place the container technology in terms of relevance and usefulness in serving all its stakeholders.
Looking Forward: Roadmap Beyond 2018
The previous section concluded with a demanding and complex use case that straddled the realms of both EPC and services-based deployments. Whereas containerization via Singularity today affords the ability to entertain such use cases, broader and deeper adoption within the Community demands that additional requirements be addressed. A number of these requirements are covered briefly in this final section of this post, with the promise that subsequent, more focused posts will allow members of the Community to elaborate as appropriate. As possibly the most-encouraging takeaway we can share at the current time, all of these roadmap items are not only committed to, most are already well underway.
As alluded to much earlier in this post, and with respect to the original vision for SIF, we noted that block-based encryption for any data object was in scope and on the roadmap. As we work to bring Singularity into full compliance with standards emerging from the Open Container Initiative (OCI), this data-encryption requirement is slated for immediate action. Also related to OCI compliance, and involving SIF specifically, will be the need to harmonize the existing signing and verification capability inherent in SIF with those requirements currently emerging from within the OCI. Because extensibility was designed into SIF from the outset, OCI compliance can be addressed through technically efficient and effective means. Finally, and related to compliance with respect to the OCI Image Specification, will be efforts to ensure that SIF images can be appropriately ‘ingested’ – e.g., for subsequent use in an OCI-compliant runtime. In other words, SIF becomes a packaging format for OCI-based containers.
Still related to SIF, compliance will include the ability to mount an arbitrary number of SIF images as an OCI bundle. Needed for compliance with the OCI Runtime Specification, at a high level, this translates to mounting an arbitrary number of files – as SIF encapsulates each Singularity container into a single file. Of course, it’ll be the dogged efforts of working the low-level details to ensure ultimate compliance with SIF for runtime purposes. Keeping with the OCI runtime, and not too surprisingly, efforts are also underway to draw Singularity’s CLI and Application Programming Interface (API) into compliance.
The implementation of SIF in Singularity, as well as the Go-based core implementation that is Singularity itself, is all licensed under the three-clause BSD license available online at the project’s GitHub site. Whereas it might be effectively argued that open source-based Singularity is the de facto standard for containerization implementation in HPC and EPC, it is not today fully compliant with open standards for containerization within the enterprise. As an active participant in the development of those standards that will ultimately define image specifications, runtimes, and more, in support of containerization, Sylabs and the Singularity Community is committed to the OCI process and outcomes as they will ultimately deliver benefits for all stakeholders in the entire containerization ecosystem.
As the schematic presented as a motivating use case indicates, the Community’s interests in adopting Kubernetes for orchestrating Singularity containers spans both services-based deployment models as well as (increasingly) those originating from HPC and EPC. Whereas the former comprises a canonical example for Kubernetes uptake, the latter might be received with a degree of surprise. Recall however, the high-level description of the use case – namely streaming workloads, real-time analysis, and data pipelining into compute-focused services. When taken en masse, Kubernetes rapidly emerges as a better fit than any pre-existing capabilities (e.g., workload management) in EPC or even HPC.
With the Community’s need then originating from use cases such as the compute-services hybrid shared above, it’s not too surprising that tightly coupled integration and interoperability with Kubernetes has emerged as a pressing requirement for Singularity. The need to be immediately addressed here relates to integration between Singularity containers and the Kubernetes runtime. Fortunately, as of version 1.5 of Kubernetes in 2016, a Container Runtime Interface (CRI) was released. Improved in two subsequent ‘dot’ releases of Kubernetes, Kubelet interaction with this CRI is illustrated schematically below. Evident from this figure is that the node-persistent agent known as a “Kubelet” is now able to work with any container runtime that provides a gRPC server implementing the CRI. Thus immediately upon our agenda is the need to implement the Kubernetes CRI ‘shim’ (see schematic) to allow Singularity containers to be orchestrated by Kubernetes.
[Image credit: Yu-Ju Hong, Software Engineer, Google
Introducing Container Runtime Interface (CRI) in Kubernetes
Basically, the Singularity CRI implementation is a gRPC server which serves Kubelet requests by interoperating with the Singularity runtime. This server will interact with the Kubernetes CRI to natively spawn Singularity containers, and add SIF support to Kubernetes. As of this writing, the Kubernetes integration effort is underway, and the Singularity CRI already possesses an ImageService interface implemented and ready for testing; this ImageService interface is responsible for pulling, removing, and maintaining the list of local images. The Community’s efforts with respect to the RuntimeService remains challenging and ongoing at the present time.
Based upon the compute-services hybrid use case we shared earlier, you can well appreciate the enthusiasm with which the pursuit of integration with Kubernetes is being both pursued and received within the Singularity Community – let’s face it, it’s not every day that entirely new workflow patterns are enabled for complex use cases that span EPC and services-oriented computing.
Dockerfile Syntax Support
As of the version 3.0 release, not only can Singularity still make use of existing Docker images from the Docker Hub repository, it can reformat them into SIF. Once reformatted into SIF, of course, the reliance upon the source Docker image is removed, and the image can be managed as any other SIF file – as the single means for encapsulating the runtime corresponding to a Singularity container.
Owing to the predominance of Docker in architecting microservices based applications, and the unsurprising and significant investment made by those making use of the technology including repository-hosted images, interoperability with Docker has always been a strength of Singularity. In broadening and deepening that interoperability, support for Docker in Singularity is about to be further enhanced through the addition of direct support for the Dockerfile syntax. Paring down Docker images to a build ‘recipe’ captured through a single text file, Dockerfiles are representative of the most-efficient means for detailing containerized images – Singularity, of course, employs definition files for this purpose. When you review definition files, such as those rapidly appearing in the examples area of the project’s GitHub site, you’ll quickly appreciate just how valuable direct support for the Dockerfile syntax has the potential to be. Furthermore, owing to the not always subtle implementation differences between Docker and Singularity, by working at the build level it is expected that higher degrees of compatibility will be ultimately ensured.
As noted in the section that provided the motivating use case for our roadmap, Nomad is already factoring into some leading-edge use case examples. To reiterate here, Nomad is being used to deploy application workflows in Kubernetes container clusters. From hardened use case pioneers to those wanting to employ Nomad for the first time, it is clear that there is value in integrating the Nomad runtime with Singularity directly; thus, through use of a (Nomad) plugin, Singularity will be enabled as a container runtime under Nomad.
From native runtime interfaces for Singularity in Kubernetes and Nomad, to OCI standards compliance plus direct support for the Dockerfile syntax, there are a number of projects underway at the present time. Owing to the anticipated release of these latest efforts by and for the Singularity Community, in tandem with the potential to rapidly accelerate the implementation of game-changing compute-services hybrid use cases, realization of these roadmap projects will deliver immediately leverageable implementations while addressing important strategic objectives.
Call to Action
As outlined in a recent blog post, SC18 provides numerous opportunities to engage formally or informally with Singularity and its rapidly growing Community – from BoFs and a panel in the Technical Program to presentations, hands-on workshops, and scavenger hunts on the exhibits floor. Because there are certain to be discussions as to current challenges and opportunities within the container ecosystem, in this post we’ve made efforts to ensure you are aware of the progress that has been made in 2018, and what you can expect from all of us over the next few weeks, months, and quarters. As of this writing, Singularity has progressed significantly, and established a vibrant and active Community; however, there is always room for additional Community members and a variety of ways in which contributions can be made. The Singularity Community looks forward to the discussions at SC18 and beyond, as together we can continue to develop this unique approach for containerization into an even better solution for your existing and future use cases in HPC, EPC, and more.
Join Our Mailing List
There are many different approaches that can be taken when building software. At one end of the spectrum is the extreme caution and conservatism that’s appropriate, for example, of safety critical code used in vehicles or in real-time operating systems. At the other...
In the development world, continuous integration is where members of a team integrate all their work frequently, for example, think of a team all working on the same code base, they are fixing bugs, implementing new features, so to prevent conflicts, all the code is...