This podcast is the first in a series of interviews that we conducted while assembling our second eBook on the container ecosystem, “Applications & Microservices with Docker and Containers,” out January 20.
If you’re planning on running containers at any scale in your environment, you’ll need to think about standards. This discussion with Josh Ellithorpe, lead software architect at cloud platform provider Apcera, revolves around standardization within the Docker and container ecosystem. Its focus is on the importance of compatibility with standardized image formats.
In this interview, conducted at Dockercon EU by The New Stack’s Alex Williams, you’ll hear about not only the difficulties of those goals but also how cloud platform provider Apcera has thought through these issues and worked toward its own rigorous solutions.
This podcast is also available on YouTube.
Apcera’s own package manager uses a tag-based system to describe dependencies, said Ellithorpe, “so that we could describe the metadata about what’s running in the system in a way that we thought was a little clearer than how Docker described it in their image formats.”
“When we stage our applications outside of the Docker context, it detects the frameworks, and actually calls into our package manager,” he explained. “I may deploy a Node app, and it’s going to go and look for a package tagged ‘Node,’ and it’ll be very clear what version of Node that package is picking up.”
“That Node package has its own dependencies — things like Git or Python for some of the build chain, as well as an OS dependency that it’s going to need to pull in,” he explained. “Each of these packages can be audited by your security team to make sure that there’s high-quality metadata across them.”
In addition to being of high quality, the metadata is also thorough. “When you audit software inside of an Apcera platform,” Ellithorpe said, “you can say, ‘Tell me every single workload that’s using this exact release of Java,’ and it can tell you exactly what’s running in your infrastructure, and exactly what needs to be updated.”
Apcera also offers policy hooks around packet retirement, Ellithorpe noted. “If you release a new version of a Ruby package, you can say, ‘Ruby now is defined as this new Ruby package,’ and when you go to re-stage your Ruby applications, that’ll automatically get picked up,” he said.
“Dependency updates can happen automatically, and we get a lot better audit-ability about every single action in the system, as we provide audit logs on everything,” he continued. “Who updated this package? Who uploaded a new package? Who’s consuming this package? We have all of that metadata available for our customers.”
Ellithorpe observed that the topic of policy is more complex than ever. “You have individual security solutions bolted onto many different pieces, that have been bolted together to create one working system. You may be using four or five or ten different pieces of software to create your internal PaaS if you’re rolling it out yourself.”
“We’ve been working on ways that you can template out policy, and new UI constraints to make it easier to configure policy,” Ellithorpe said. “And we’ve been working with some of our customers to get feedback about best ways to describe policy as it relates to your LDAP groups, how you bring in those user records, and how you describe this for an organization that may have thousands of applications deployed across thousands of machines.”
“That’s something we’re always looking to optimize,” he said.
Docker and Apcera are sponsors of The New Stack.
Feature image via Pixabay.