Kabanero is designed to deliver integrated workflows for application architects, application developers, and operations teams, allowing them to focus more intently in their respective areas of expertise.
Kabanero workflows covers common scenarios for these different roles, such as architects defining base images and starter applications for developers, developers iterating through code changes from their favorite IDE without worrying about the setup of a Kubernetes cluster, and operation teams using pipelines that can continuously monitor code deliveries and deploy the finished applications to a running cluster.
The following sections outline the overall architecture of the system, its components, and explains the typical workflows for the different roles.
The Kabanero architecture supports the activity of application developers, application architects, and operations teams in continuously delivering applications to Kubernetes environments. The architecture also covers non-functional requirements, such as supporting the implementation of operational policies for application management and security.
The following figure illustrates the main building blocks of the architecture, which will be elaborated in the next sections.
A large portion of the Kabanero experience is centered around application stacks. An application stack is created by an application architect as a logical set of software components for developing and deploying applications. Although the application architect builds the stacks, all of the software components that comprise them should be agreed upon by operations, enterprise, and developer advocates. An application stack is realized as components (such as tools and container images) used at coding time by application developers. Application stack configuration is done via standard Kubernetes operator (CRD) configuration.
If necessary, an application stack can be customized to meet local requirements. For example, you might want to define specific maintenance levels of software components or expose particular ports for use by the applications that are based on the stack. Customizing an application stack provides a mechanism for controlling the precise development and runtime environment for an application. In a large organization, customization ensures that applications are developed and tested with a level of consistency that promotes quality and helps guarantee a seamless implementation in your production environment.
A stack is designed, built, and published by an application architect, which can then be pulled into local registries by application developers and into the deployment pipeline upon code deliveries.
A stack has conventions for its internal structure, with a clear separation between the portions of the stack that are common across all applications created with the stack and the portions that are unique to each application, being visible and editable by application developers.
Those conventions for a stack are detailed in the Stack Structure section of the Appsody website. For the portion of the stack that is common across all applications, an application architect makes choices such as the base container image, the runtime framework for the programming language being targeted by the stack, the toolset for the runtime framework, the management choices for the running application, and many other choices not directly related to the functional aspects of the application.
The stack structure also contains at least one application template: a set of source code files matching the technology of the stack. A template is used by the client portion of Kabanero upon request by application developers to create the first version of an application. As examples, a template may contain an empty website and web folder with all the visual branding elements for an organization, whereas another template may contain an empty REST-based application secured by API keys.
Kabanero provides initial application stacks for the most popular software development frameworks, but it is expected that feedback from developers, regular upgrades, and ever-evolving organizational requirements start to drive the creation of custom application stacks or the updating of existing ones.
For application developers, the Kabanero experience is realized as tools that allows a developer to continuously iterate over changes to source code and validate the changes, considerably reducing or even eliminating the amount of time spent setting up and dealing with infrastructures such as Docker containers and Kubernetes clusters. The current tools are offered as a combination of the following initial offerings:
Appsody: A Command-line interface with commands for creating, building, running, and deploying applications. Appsody also has extensions that are used by other portions of the architecture to reassemble the application as a container image and to deploy it to a running container, and those will be covered in the respective sections of this overview.
Codewind: Hosted IDE (Codewind for Eclipse Che) and IDE extensions (Eclipse and Visual Studio Code) with a set of commands for creating, building, running, and profiling applications. When compared to Appsody, Codewind cannot deploy an application directly to a Kubernetes cluster, but it adds useful profiling capabilities where developers can inspect the usage of system resources between different local iterations on the source code.
Both Appsody and the local IDE extensions of Codewind depend on a running docker daemon to run a container with the resulting image for the application being developed.
The Kabanero Foundation sits on the opposite side of the developer experience, as a set of managed pipelines that provide consistent, managed, and governed CI/CD processes that react to repository events that occur during code development. Kabanero Foundation is a set of Kubernetes components covering the disciplines of serving applications, service mesh, build, and deployment.
With these components deployed to a Kubernetes cluster, webhooks are utilized to connect the source code repositories (such as GitHub) to pipelines that extract the source code, reassemble it according to the structure and runtime specifications of the underlying Kabanero application stack, execute all the build and verification steps, and then make the final application container pods available in the cluster.
Applications in a production environment are subject to common operational policies and lifecycle operations. Kabanero combines a set of open-source projects to support operations teams in those activities, ranging from the Kubernetes CLI for managing the Kabanero custom resources to Application Navigator (kAppNav) to view related application resources in a single, simplified view.
The following sections contain concrete examples of how different roles would interact with Kabanero to achieve concrete goals.
An application developer installs and configures Appsody on their local system to use the application stacks that have been customized for their organization. These stacks can be initialized with an initial application template. This activity is explained in detail in the Appsody website but can be summarized as follows:
> appsody list ... incubator nodejs-express 0.2.10 scaffold, *simple Express web framework for Node.js ... > mkdir -p ~/workspace/myapp > cd ~/workspace/myapp > appsody init nodejs-express simple
As described in the Stack Structure section of Appsody, besides the "Initialization" mode exercised during the creation of a new application, there are also "Rapid Local Development" and "Build and Deploy" modes, with the first mode being exercised the most during local application changes. The application architect designing that experience is expected to leverage the underlying framework capabilities to ensure code changes are reflected as quickly as possible.
> appsody run ... // Wait for the local container to indicate it is ready, typically via // console output // Make code changes, test code changes // If the image indicates it cannot dynamically adopt one of the changes: > appsody stop > appsody run ..
Note that patches to the application stack may be picked up between executions of "appsody run", triggering the download of the new base image for the stack. In the case of minor or major patches, the application architect is expected to notify application developers about the new release and implications to existing applications, at which point the application developers need to update the Kabanero metadata in the application directory to pick up these changes.
An application stack can be set up differently between the "Rapid Local Development" and the "Build and Deploy" modes, so application developers can anticipate and ward off eventual problems in an actual pipeline deployment by running a local build before delivering their code changes.
> appsody build ... // Wait for the local build container to indicate it the build was successful // Address eventual problems and notify the application architect about the // occurrences, so that the stack can be enhanced to minimize or eliminate // the sources of common problems. ...
Similarly to testing a local build, application developers can preempt problems in an actual pipeline deployment by running a local deployment to a development Kubernetes environment before delivering their code changes.
> appsody deploy ... // Wait for the deployment to indicate it was successful // Address eventual problems and notify the application architect about the // occurrences so that the stack can be enhanced to minimize or eliminate // the sources of common problems. ...
Assuming the observance of proper controls and operational policies for the target Kubernetes cluster, "appsody deploy" can be used to deploy an application directly to that cluster. For actual production environments, access to the cluster will likely be restricted to an automated pipeline like the one included in Kabanero.
With all code modifications, local build, and local deployment in place, this is the culmination of a local development session, which ends with a code push towards the application source code repository.
At that point, Kabanero Foundation will detect the code delivery and execute a pipeline run that will ultimately result in the publication of the finished application.
After several iterations of the previous workflows, application developers will have provided valuable feedback to the application architect responsible for a given application stack.
The overall process for modifying a stack is explained in the "Stacks Overview" page of the Appsody website.
The application architect must judge the nature of the changes in light of semantic versioning guidelines and decide on the new version number for the stack. Application stacks are expected to have application templates set to adopt all new patches automatically and set to require a manual change to the application code to adopt minor and major versions.
Once the decision about the new version is made, the application stack must be published to the remote location hosting the application stack, a process also described in the "Working with stacks" guide.
This is more of an activity than a workflow, though some interaction is expected between the application architect and the operations team to align the cluster configuration with the application requirements. Those interactions should also result in the documentation of the operational aspects of the application that can be incorporated into operational processes.
For instance, if an application stack supports connection to a remote database, the mapping of connectivity parameters to the cluster may entail a combination of hostname and ports as config-maps and database credentials as secrets. The application architect will have to ensure the operations team knows what is necessary to create the proper setup of those parameters in the cluster.
This concludes the overview of the Kabanero architecture. Head to the Kabanero.io guides for deeper dives into Kabanero components and "Getting Started" guides that will get you up and running with hands-on examples of the workflows introduced here.