Puppet Labs Automates Kubernetes for DevOps
So much can change in a year, even for the enterprise.
Back in February, Puppet Labs CEO Luke Kanies told The New Stack that he believed the rapid adoption of Docker in the enterprise was essentially an illusion. “No technology spreads through the enterprise that quickly. I don’t care how awesome it is,” said Kanies. “You don’t take the millions and millions of workloads that are in production right now and suddenly swap out the virtualization layer for a completely different deployment packaging, runtime, all that stuff.”
Fast-forward nearly a year, and Puppet Labs finds itself in a position where it is adapting its tools for use in containerized environments. On Wednesday, the company announced the release of a module for Kubernetes that will enable the orchestration environment to be managed by way of Puppet code.
Puppet for Programmers
There’s a common perception that Puppet is the system administrator’s automation tool for configuration management, whereas Chef is a tool that does the same job for developers. Earlier this year, a premium report by VB Insight attempted to apply permanent epoxy to this distinction, arguing that while Chef enables developers to make experiments, Puppet tries to keep admins from making mistakes.
Puppet Labs’ U.K.-based senior software developer Gareth Rushgrove, the point man for the Kubernetes support, flipped the entire topic of configuration automation on its ear, effectively making the case that Puppet should be the developers’ choice because, he said, “it’s a programming language — especially now, more so than maybe a few years ago.”
Over the past few years, Rushgrove argued, Puppet has acquired the types and level of tooling and support that developers expect from a language. “I think the difference is, it’s a declarative language, not a general-purpose language. But the things you can do because of that are then quite powerful,” he said.
There are indeed programming languages that are declarative, so the declarative syntax of Puppet should not exclude it from consideration. Rushgrove explained that declarative syntax enables an operator (it’s up to you to decide whether to call this person a “developer”) to declare the desired state of the system supporting the container platform. From there, the plug-in will enable changes to be made to Kubernetes’ configuration in the background.
“Configuration management is not just about managing resources and files on disk; it’s the high-level discipline of management over time,” stated Rushgrove. “Our customers, our users tend to be large organizations that are more interested in process. What we’re trying to do is build tools that allow them to have the controls they want from manual processes, without having to have those processes be manual.”
In large organizations, he said, the processes that comprise service management and configuration management have evolved gradually, over time, and have often grown quite messy. Puppet tries to acknowledge the value of those processes, which he says have acquired “a lot of hard-won wisdom.”
But left to their own devices, organizations will evolve these processes with various gates, sign-offs, and handovers between individual parties — transfers that can be automated, conceivably, but not with any really positive effect. Such transfers are not only inefficient when hard-wired, but incompatible with the ideal of container orchestration. Security controls help organizations to maintain ownership and authorization of processes taking place while at the same time ensuring that ball-point pens aren’t directly involved in the proceedings.
Kubernetes for Non-Admins
“What we see with Puppet generally is, rather than it being the admin writing code for something that he previously would have done manually,” noted Rushgrove, “because it’s code, because you have that intermediary artifact, it becomes something that teams and groups interact with, rather than just individuals. You move away from that individual stereotype of a system administrator … By having that intermediary artifact, you can introduce things from software development practices — like continuous integration, unit testing, code review. And you build up a shared model, a shared responsibility for describing that model.”
The model can reflect an evolutionary system over time — not just the optimum, fixed state of the platform, but the expected changes to that state given certain conditions. This is accomplished in Puppet (as admins already know) by declaring those conditions as dynamic variables. With the new Kubernetes platform, those changes can then be rendered automatically to Kubernetes over time.
It’s worth noting that Kubernetes is described in its own documentation as a desired-state system. “Kubernetes establishes robust declarative primitives for maintaining the desired state requested by the user,” one page reads. “We see these primitives as the main value added by Kubernetes. Self-healing mechanisms, such as auto-restarting, re-scheduling, and replicating containers require active controllers, not just imperative orchestration.”
Gareth Rushgrove believes Kubernetes’ strength lies in these primitives. In a company blog post published Wednesday, he argued that Kubernetes’ handling of the task of configuration does not, after all, make the need for configuration management go away.
“Some people look at configuration management (and tools like Puppet) as a way of managing host-bound resources like files, services, packages, users or groups,” wrote Rushgrove. “Kubernetes introduces higher-level primitives, like Pods and Replication Controllers, aimed at making the management of distributed and scalable systems drastically easier. The story goes that you no longer need configuration management with those new primitives. But configuration management is really a much broader discipline, dating back formally to the 1950s.”
His statement precedes an example of Puppet code, which uses YAML, incorporating identical elements of Kubernetes code, which also uses YAML. This way, anyone familiar with the Kubernetes API will not need to learn an entirely new way to express its primitives, when expressing them in Puppet code. “So the better that you understand Kubernetes,” Rushgrove told us, “the more you’ll be able to use the module.”
What’s more, he believes it could become possible for Puppet scripts that automate Kubernetes to be used by a separate class of users — folks who are not Kubernetes experts, but may only be interested in resolving a short-term business problem. As an example of this, Rushgrove presented the classic Kubernetes guestbook example — which generates a simple, load-balanced Web application with server — re-rendered as Puppet code, as a way of giving evidence of how few syntactic changes there actually are.
Simple adjustments to the guestbook application, he explained, would enable this second user class to make simple adjustments — for instance, to the numbers of containers for replication controllers — without having to consult the expert users first. “So you have different people in your team, all able to use large applications on Kubernetes, but not all of them having to be experts on all of it. They just use the interfaces you create, at a sort of business level.”
Docker is a sponsor of The New Stack.
Feature Image via Pixabay
