Posted on 02/04/2016 1:50:25 PM PST by ShadowAce
In the still-developing container world, it seems like new functionality is being released every time you turn around. Engineers are trying to solve the questions of how to make containers run faster, smarter, and take up fewer resources.
This week's hack comes from Iron.io, a Platform as a Service (PaaS) company. In a word: Microcontainers.
Last week, Iron.io co-founder Travis Reeder explained how to reduce the size of Docker Images by using what they have dubbed Microcontainers, following up on a post in December on how to build your own Docker Image.
"A Microcontainer contains only the OS libraries and language dependencies required to run an application and the application itself. Nothing more," says the Iron.io blog, which also contains explicit instructions and links to their GitHub page.
Using Docker's official repositories as the standard container language results in Node images of a minimum of 643 MB. By streamlining the cruft that is attached to the Node Images and installing only the essentials, they reduced the image from 644 MB to 29MB in these "tiny, portable Docker containers." In addition to this very impressive size reduction, there are other benefits.
One advantage is that distribution goes faster. Because of the smaller size, downloading the image from a Docker registry is much quicker, as is distribution to different machines.
In addition, the company claims improved security with this design. "Less code/less programs in the container means less attack surface. And, the base OS can be more secure -- These benefits are similar to the benefits of Unikernels, with none of the drawbacks," Reeder wrote.
Iron.io has a library of base images in Docker for all major languages available on GitHub. "These have some optimizations in them to make them as small as possible and we update them regularly, which makes them a slightly better choice than doing it yourself," the blog claims.
Using the Iron.io base images, the Dockerfile above for the Node app can be built with this Dockerfile:
FROM iron/node WORKDIR /app ADD . /app ENTRYPOINT [ "node", "server.js" ]
Initial reaction to micro containers seems to be positive.
"This seems to solve one of my biggest issues with trying to use individual Dockers to run microservices," _Marak_ enthused On Hacker News. "Past experiments proved that it wasn't feasible to match one microservice request to one Docker instance. The size of each Docker required vertical scaling of the microservices per container, which was not ideal."
User lox noted, "Of course, if you have ruby or node apps your biggest space hog is still going to be your packages."
Also in container news, Google software engineer Brendan Burns released results from his ongoing survey on the use of containers, on the Kubernetes blog. The survey is admittedly limited--119 responders to questionnaire sent out to twitter followers of Kubernetes engineers), but is interesting nonetheless.
The vast majority of respondents--80 percent--use containers for development but only 50 percent are using them for production. That will be changing soon, as 78 percent said they are planning to move containers into production "soon."
The majority of the respondents deploy containers on their laptop (53 percent), followed by private VM, followed by physical infrastructure (33 percent), and 31 percent on a public cloud VM.
But it was the free-text answers to the challenges working with containers that offered the most interesting information.
In addition to security, which is always a concern, other free-text answers are grouped into the main categories of Development Complexity, Immaturity, Complexity, and Data.
Talking about development complexity, one responder wrote: "massive amounts of knowledge is required to grasp the whole infrastructure stack and best practices from say deploying / updating kubernetes, to underlying networking."
Respondents complained about the lack of maturity of the container systems, bemoaning the lack of comprehensive non-propriety standards, and poor CI support. "A lot of tooling still in very early days."
Another criticism involves the complexity of the system. "Clustering is still too hard," wrote one respondent. As reported here last month, Google announced a partnership with Red Hat last month partially to address the complexity issues of their customers.
And last but never least, complaints about data storage and persistence.
None of this is news to sysadmins using containers. But perhaps emerging tools like Iron.io's Microcontainers will address some of these concerns.
DIGITAL DIRTYTALKIN’
My cat’s name is Mittens.
Hence the “Tech” ping, and that it is in the “computer/internet” forum.
I understood everything they were talking about in this and I’m depressed because now I know I need to get a life
Great stuff. Love posts like this.
Also trying to figure out how to deploy containers in an Enterprise environment, and what to use them for.
My understanding (limited as it is) is that containers eliminate any friction between testing and production. If it runs on your laptop it *will* run in production. Not true in the non-container world. Probably other advantages as well.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.