Oracle Addresses Container Issues for IT Operations
As part of an effort to raise its profile in the container community, Oracle has made available three open-source utilities intended to meet the needs of IT operations teams rather than individual developers.
The utilities include Smith, a container builder designed more for IT operations teams than developers; a Crashcart debugging tool also designed more for IT operations teams; and Railcar, an alternative runtime platform for containers that Oracle has developed.
Vish Abrams, architect for cloud development at Oracle, says IT operations teams that employ containerized applications to help manage their data center environments require access tools designed for them versus for developers. To address that issue, Smith provides a means to more consistently create microcontainers using rpms, yum repositories or existing docker containers, Abrams says.
Oracle says microcontainers are unique in that they contain only a single executable and its dependencies; run with a read-only root filesystem; have no user and group filesystem ownership; have no filesystem timestamps or capabilities; and can be built to be reproduced, producing the same image each time. Within that context, Oracle says microcontainers lend themselves well to applications targeting IT operations management.
In a similar vein, Crashcart provides a debugging tool optimized for microcontainers, while Railcar provides an alternative to the Open Container Initiative (OCI) spec that is more memory efficient while also providing more granular control over threads when employed in conjunction with the Rust programming language.
While Docker containers have emerged as a standard, there are a lot of use cases Docker containers don’t necessarily address. Given that issue, it is probable that over time multiple container standards will take hold. In the short term, multiple container standards will undoubtably lead to some additional container confusion. At the same time, containers in multiple forms provide an opportunity to simplify the building and deploying of certain classes of applications that Docker containers are simply too large and cumbersome to address. From an IT operations perspective, that means the future of IT is likely to consist of multiple types of containers as well as variants of traditional and lightweight virtual machines. Why an IT organization might decide to opt of one of these formats versus another will be as varied as the used cases being addressed.
Oracle notes Docker’s shortcomings, including the size of the images generated, the lack of an image repository, production problems created by the copying of images using an Overlayfs utility, how vulnerabilities get managed, challenges associated with maintain User Namespaces, and the security model.
There’s no doubt the Docker community is working on these issues. But in the meantime, there are obviously application scenarios that can’t necessarily wait for the Docker community to address these issues. In fact, there are more than a few IT operations professionals who feel containers are a construct being forced upon them by developers who have little regard for the production challenges they might create. Faced with those issues, it should not come as a surprise that IT operations teams would come up with their own form of a container to resolve some of those issues.