Why use Dekorate for a Kubernetes manifest? Well, the practice of deploying applications has seen a lot of changes in the relatively short time that computer systems have been part of our daily lives and business operations. One of the latest significant shifts in the deployment of applications is the move to containers.
Using containers—rather than dedicated physical servers or virtual machines—makes the underlying system more lightweight and portable than the previous methods.
Of course, containers need to be properly organised and managed if this system is to work to its full potential—or, indeed, at all—and that’s where Kubernetes comes in. Kubernetes is a framework to run distributed systems, taking care of several aspects of the process, such as scaling and failover. It allows for the bundling of applications, as well as deployment patterns.
Even with such an agile system, setting things up and making changes once things are up and running can be a tedious venture. Editing XML, YAML, or JSON files manually is a time-consuming way of doing things, and one that invites the possibility of human error. Dekorate takes care of this aspect for you.
What is Dekorate?
Dekorate is a collection of Java compile-time generators and decorators designed to work with Kubernetes (and OpenShift) manifests. The purpose of this tool is to make generating Kubernetes manifests much easier and faster by reducing the process of adding a dependency to the classpath. It also makes customising things easier by reducing that process to setting annotations or application properties.
It works with almost any Java build tool, including Gradle, Maven, Bazel, and sbt. Lightweight integration with build tools, making it an incredibly versatile solution for saving time when setting up or modifying application deployments. It allows for the manifests to be customised through annotation or properties, so developers and system admins can use the method that best suits them and the application.
This is an “out of the box” solution that includes framework detection. This means that, in the vast majority of situations, very little (if any) customisation to a specific system is required.
Dekorate boasts several time-saving features that make it worthwhile when working with Kubernetes manifests. These include;
- Allows fine-grained customisation: When opting for convenience, it is often the case that one has to sacrifice some of the control they previously had. For example, using a high-level programming language may be easier, but low-level languages are more powerful. In the case of this tool, admins will still have fine-grained customisation options through annotations, properties, or both. Essentially, it removes a substantial chunk of work without taking the control away.
- Works for most build tools and all jvm languages: This tool works with almost any Java build tool (including all of the major ones) and all jvm languages. It provides lightweight integration with those build tools and can refer to information from the build tool config without needing to bring the build tool itself into the classpath.
- Can be used as a library: It is possible to use Dekorate as a library for manipulating Kubernetes manifests, allowing for more bespoke integration when needed.
- Framework detection: Dekorate can automatically detect Java frameworks such as Quarkus, Thorntail, and Springboot. In doing so, it can align the generated manifests accordingly, making it a true “out of the box” experience.
Generating a Kubernetes Manifest via Annotation Processing
Generating a Kubernetes manifests using this tool is incredibly simple. Here we will go over the process of getting started.
Configuring the Kubernetes Manifest
The simplest way to get Dekorate enabled is to add the JAR file that corresponds to the target platform file to the class path. In the case of Kubernetes users, this would look something like this;
groupId io.dekorate /groupId
groupId kuberentes-annotations /groupId
version 0.13.2 /groupId
The code for Openshift users would be almost identical save for the fact that the groupID value would be “kubernetes-spring-starter”. For Spring Boot, it would be “openshift-spring-starter”.
This will cause the tool to be triggered by the compiler during the compilation process, and that will generate the desired manifests under target/classes/META-INF/dekorate. Once created, these manifests can be applied directly to the cluster in order to deploy the application.
The manifests will contain a basic deployment resource, but may also contain additional configurations and resources depending on what Dekorate detected in your code. One example of this is the HTTP port being added to the container and exposed as a service if an HTTP endpoint is detected in your code.
Using annotations allows the user to specify almost anything related to the deployment manifest, including ports, environment variables, annotations and labels, and more. This is a much more efficient method than creating or editing long XML, YAML, or JSON files.
Rich Framework Integration
It was mentioned above that there is lightweight integration with frameworks like Maven and Gradle. This feature means that it can bring in information from the tool configuration without having to bring the build tool into the classpath.
Integration with application frameworks like Spring Boot further enhances the appeal of Dekorate, especially with frameworks that provide native resource generation for Kubernetes that is based on this tool. One such framework is Quarkus.
Quarkus delivers its own extension for Kubernetes but makes use of Dekorate to customise the generated manifests. This is done after Quarkus has retrieved as much information as it can for the applications.
How the Code Looks
Given that the sole purpose of this tool is to generate Kubernetes manifests, it shouldn’t be surprising that the resulting code is clean and accessible. Should a developer ever want or need to go into the manifests to read or edit them manually, they will not need to worry about being able to understand the generated code.
Of course, the labels in a Kubernetes manifest are generally self-explanatory, but this tool ensures that everything is correctly indented according to hierarchy, and that line breaks are used to separate out individual sections and make it easier to navigate through the code.
Hello World Example
No article about a programming language, framework, or development tool would be complete without a “hello world”-level introduction on how to use it. In this case, hello world will be different depending on the framework that is in play, but those differences are not significant. For example, in Quarkus you would add the following dependency to your project;
dependency<br>groupId io.quarkus /groupId<br>artifactId quarkus-kubernetes /artifactId<br>version 1.0.0.Final /version<br>/dependencyCode language: HTML, XML (xml)
Then, once the project has been built, you would find the generated manifests under target/kubernetes. For Spring Boot, you would add the following dependency;
groupId io.dekorate /groupId
artifactId kubernetes-spring-starter /artifactId
version 2.9.2 /version
And the resulting manifest would be found under target/classes/META-INF/dekorate. Details on the other frameworks like Thorntail can be found on Dektorio’s Github page.
Of course, not all deployments make use of frameworks like Spring Boot. For generic Java projects, the process is basically the same, but there also needs to be an annotation that expresses an intent to enable the tool.
Use Cases Where Dekorate Will Help You
Dekorate is useful in almost any container-based app deployment because reduces the work involved in that deployment, not to mention the continued maintenance of it. The fact that it features automatic framework detection and works out of the box with most build tools only adds to that convenience. And, like all good tools of convenience, it allows developers to put as much or as little effort in as they wish. It can be used to set up a project with the minimum possible effort, but it a developer can also dive into the project and make fine fine-grained changes without fighting against the tool that is supposed to be saving them time.
There is a public roadmap for future features, and already provides a good deal of integration modules and extensions. The popularity already of what is, ultimately, a very new project, makes it highly likely that this tool will continue to improve and expand its feature set. And, as it does, the developers of frameworks will be more inclined to make their tools work better with it, even incorporating it as Quarkus has done.
Ultimately, this is a tool of convenience. And, while tools of convenience aren’t always necessary, it is a tool that does not hamstring developers by taking control out of their hands, meaning there is very little downside to adopting it.