DEV Community: Capact.io

Take Capact for a spin!

Mateusz Szostok — Mon, 07 Feb 2022 13:59:23 +0000

Our first blog post focused strongly on why—why we created Capact, what's the general concept behind it. Now it's time for showing how—how you can use it.

Although, there are many ways to get started with Capact, today we will focus on your perspective as a Capact User.

The recommended way to try out Capact quickly is to set up a local environment.

Detailed instructions are already nicely described in our local installation tutorial. Once you have Capact up and running, we can start!

What you will learn

NOTE: For this blog post, we will use Capact CLI. However, the described scenario can also be executed with our brand-new UI! 😎

In 5 minutes, by running examples from this blog post, you will learn about the following Capact concepts:

Interface—provides an option to abstract Implementations.
Implementation—defines the actual workflow that is executed.
Attribute—provides an option to tag manifests. Today we will use it to select a specific Implementation.
Type and TypeInstance—provide a combined feature, where Type holds the schema and TypeInstance the instance for the Type.
Action—triggers Engine to render and run a given Interface.
Policy—impacts the render process to select desired Implementations.

Creating new workflows is not the concern of this article, and it will be covered in future blog posts.

Here we only briefly describe each part, but I encourage you to take a deeper look at our Terminology section later.

Prerequisites

Capact CLI at least v0.6.0
Capact cluster at least v0.6.0
(Optional) kubectl
jq

📜 Scenario

The key concepts were described in the Introducing Capact blog post. There, we used Mattermost as an example. It was a real life scenario but at the same time more resource and time-consuming.

For the purpose of this blog post, we created an extremely simple Hello World example.

There are two Implementations for the cap.interface.capactio.examples.say Interface. Depending on the Policy, a different Implementation is selected. By default, Engine selects the Implementation which is first on the list (alphabetical order) and doesn't have any requirements regarding executions, such as requiring AWS credentials.

🎬 Camera, Lights, Action!

Action is the entry point for executing any Interface. It allows you to define which Interface should be executed and with which parameters. This is later consumed by Capact Engine and the appropriate workflow is rendered. Later, you can review it and approve it for the execution.

Steps

Make sure that you are logged into local cluster.

List available Interfaces:

capact hub interfaces get

We are interested in this part:

                           PATH          LATEST REVISION                  IMPLEMENTATIONS
---------------------------------------+-----------------+-----------------------------------------------
# ... trimmed ...
---------------------------------------+-----------------+-----------------------------------------------
cap.interface.capactio.examples.greet        0.1.0             cap.implementation.capactio.examples.greet
---------------------------------------+-----------------+-----------------------------------------------
cap.interface.capactio.examples.say          0.1.0             cap.implementation.capactio.examples.hello
                                                               cap.implementation.capactio.examples.ricky

Create a new Action:

💡 A Policy is not needed as we use the default behavior here.
```
capact act create --name hello cap.interface.capactio.examples.greet
```
Wait for the Action to have the READY_TO_RUN status:
```
 capact act get hello
```
When the status is READY_TO_RUN, run the Action:
```
 capact act run hello
```
Watch the progress:
```
 capact act watch hello
```

(Optional) Once the Action is finished, copy the name of the Pod for the print workflow step (column PODNAME). To read its logs, run:

kubectl logs {PODNAME} main

Example output:

 ____________________________
< message: Hello from Capact >
 ----------------------------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/

Get the Action output (TypeInstance). Copy the id field value:

 capact act get hello -ojson | jq '.Actions[0].output.typeInstances'

Example output:

[
 {
   "id": "08fcaa07-7846-47af-b6a7-7c3818c69656",
   "typeRef": {
     "path": "cap.type.capactio.examples.message",
     "revision": "0.1.0"
   }
 }
]

Get the TypeInstance value.message field value:

 capact ti get {ID} -ojson | jq -r '.[0].latestResourceVersion.spec.value.message'

Delete the Action:
```
 capact act delete hello
```

What if you wanted to output a different message, that reminds you about a masterpiece song you can listen to endlessly? With Capact that's really easy ✨

To choose a different Implementation for the say Interface, we need to prepare a dedicated Policy. The power of it is that you don't have to change the main workflow. You treat the step as a building block and just swap it for another existing one.

To test it, create the Action again, and pass the Action Policy.

First, save the Policy to the /tmp/policy.yaml file:

cat <<EOF > /tmp/policy.yaml
rules:
  - interface:
      path: cap.interface.capactio.examples.say
    oneOf:
    - implementationConstraints:
        attributes:
          - path: cap.attribute.capactio.examples.be-positive
            revision: 0.1.0
EOF

Next, create the Action with the Policy:

capact act create --name hello cap.interface.capactio.examples.greet --action-policy-from-file /tmp/policy.yaml

Now, you can repeat steps starting from 4th point—so, once again, wait for the Action to have the READY_TO_RUN status and run it!

In the optional step no. 7, if you read the Pod logs, the output will be:

 __________________________________
< message: Never gonna give you up >
 ----------------------------------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/

Note also that the produced TypeInstance from no. 9 is valid against the same JSON Schema but the message was changed.

What is so special about it?

Our example was simplified to a minimum, but you could see that you can:

chain different steps together,
have a unified way of execution,
built-in Type validation based on JSON Schema,
and more importantly, write once and swap implementation details with ease.

Capact is also great if you want to chain different tools together and keep the same entry point (UX) but that requires more complex examples. For now, we recommend you to take a look at our other examples described in the How can I get involved and learn more? section.

Behind the CLI

As you saw, you can use CLI to browse Hub manifests, create a specific Action for a given Interface and retrieve the output. CLI communicates with our Gateway via GraphQL calls, same as the UI (Capact Dashboard). You can read more in the E2E Architecture document.

However, a more important question is, how did it happen?

1  spec:
2    # ... trimmed ...
3    imports:
4      - interfaceGroupPath: cap.interface.capactio.examples
5        alias: examples
6        methods:
7          - name: say
8  
9    # ... trimmed ...
10   steps:
11     - - name: get-message
12         capact-action: examples.say # dynamic step, rendered by Engine based on the Policy.
13     - - name: print
14         template: print
15         arguments:
16           artifacts:
17             - name: message
18             from: "{{steps.get-message.outputs.artifacts.message}}"
19     # ... trimmed ...
20     - name: print
21       inputs:
22         artifacts:
23           - name: message
24           path: /tmp/message.yaml
25       container:
26         image: docker/whalesay:latest
27         command: [ sh, -c ]
28         args: [ "cowsay < /tmp/message.yaml" ]

The snippet above shows the most important parts of the Implementation manifest. In lines 4-7, we declare the import, which is later used in steps. In line 12, we use capact-action to make a dynamic step with a given Interface.

💡 Instead of providing the full Interface path, we use alias assigned to the imported Interface.

As a result, our Engine and, in particular, Argo Renderer has an option to put there an Implementation that fulfills the specified Interface. Thanks to that, this step is swappable based on the defined Policy.

How can I get involved and learn more?

The Getting Started goes into more detail about how to start with Capact and use its more-advanced features. There are also Rocket.Chat and Mattermost tutorials that we keep up-to-date for you to walk you through using Capact in real cases.

We appreciate any input you have about your experience with Capact!

There are plenty of options to contact us:

Thank you for taking the time to learn about Capact 🙌

Introducing Capact, your new way to manage applications and infrastructure

Paweł Kosiec — Tue, 21 Sep 2021 12:55:17 +0000

Managing the lifecycle of infrastructure, applications, and processes in modern IT is problematic. There are a variety of tools and best practices, which are ever-changing. It's a struggle to stay up-to-date with these practices, and not everyone is an expert at everything. Technical debt is inevitable.

We are ultimately all alone. We are siloed within the context of team, department, or company, locked-in in a particular ecosystem of tooling. To deliver end-to-end capabilities, we build them from scratch in a vacuum. We consume API calls, transform data, build and manage infrastructure and applications. Don't we spend too much time solving the same problems as others have?

Sharing expertise is something that already happens—we have plenty of libraries and frameworks out there. But what if we went a step further and have a way to create, use and share building blocks that are language-agnostic abstracted capabilities?

For example, if you're not a cloud expert, all you need to know is that you want a managed PostgreSQL database on AWS. Let the subject-matter experts take care of it, and simply focus on your business logic. Likewise, if you need any Kubernetes cluster—by saying "I want any Kubernetes cluster" and letting the magic happen, you could cover both local development and production scenarios…

What if I told you… now this is all possible?

Introducing Capact, crowdsourced expertise. Learn once, use everywhere.

What is Capact?

Capact is a new way to manage applications and infrastructure and run arbitrary workflows.

source: tenor.com

Yes, we get it. You already know plenty of different tools for that. But Capact is different. How is it different?

Capact comes with a truly unique feature—interchangeability of dependencies. If you know the concept of interfaces from a variety of programming languages, you get the idea. Think about Capact as a way of executing workflows with steps, which are described with interfaces. An implementation for a given interface is resolved dynamically at runtime, according to your preferences. Also, these dynamic workflow steps are building blocks, which can be reused by others (or even nested within other workflows).

Initially, we focused on day-one and day-two operations for managing applications and infrastructure. However, Capact is built with universal concepts in mind, so you can run any arbitrary workflow you want. For example, you can do data processing, machine learning workloads, system configuration, cluster benchmarking, auditing, running serverless workloads—the possibilities are virtually endless.

The best thing is that Capact is fully open-source under the Apache 2.0 license. How cool is that? 😎

Capact concept in one minute

The whole concept sounds confusing? Let's see that in action.

Let's take Mattermost installation as an example. Mattermost is an open-source alternative for Slack.

Mattermost is a Go server application, which uses a PostgreSQL database. If we want to install Mattermost, this how the workflow would look like:

We need a PostgreSQL database first to run a Mattermost server. It's pretty simple.

Now, what if we make the PostgreSQL database installation abstract? Think about that as an empty slot, where you can put a puzzle with a specific shape.

Assuming there are many puzzles pieces out there, you see that only a few of them fit in the slot:

In the case of PostgreSQL installation, four puzzle pieces fit:

Install PostgreSQL Helm chart on a Kubernetes cluster
Provision GCP CloudSQL for PostgreSQL database
Provision AWS RDS for PostgreSQL database
Reuse existing PostgreSQL database

By default, for a workflow run, Capact picks the first puzzle piece that fits. However, by applying Policy, you are in complete control of which puzzle piece will be chosen. Moreover, you can select a different one for a specific scenario, such as local setup, CI/CD, stage, and production cluster.

What's great is that Mattermost installation itself is also a larger puzzle piece, which others can use! Maybe as a part of productivity stack installation, which could consist of Mattermost, GitLab and Jitsi Meet? 🤔

And that's Capact. You can build your own workflows with existing puzzles, which are available inside Capact Hub. You can also create your own puzzles. Share them with the community and enable DRY at a global scale, together!

How does Capact differ from other tools?

Capact doesn't compete with tools you might already be familiar with, but it integrates them instead. Whether you are a Helm or Terraform user, you can still use your favorite tools. Mix and match your tooling or API of choice. For example, chain Terraform, Helm, and Slack API.

If you are familiar with Kubevela, Crossplane, and Open Application Model, you can see many similarities between the solution and Capact. Here are the main differences:

Capact has unique built-in feature—interchangeable dependencies, which reduces the amount of duplicated code.
Capact is a process / workflow-based solution, which gives you more flexibility. Unlike Kubevela and Crossplane, Capact is not limited to just infrastructure and application deployment. You can use it for virtually everything.

To read a detailed comparison between Capact and other tools, see our FAQ.

Get started with Capact

Interested in trying out Capact? Awesome! The easiest way to do so is by installing it locally and trying out one of our examples to understand Capact basic concepts.

Here are other things to do:

⭐ Star our GitHub repository: If you like the idea, show your interest in the project and give us a GitHub star! You can also subscribe for new Capact releases. Thank you for your support!

👉 Follow us: Interesting in Capact updates? Follow us on Twitter! Also, check out our LinkedIn page and YouTube channel.

📖 Read our documentation: If you want to get familiar with other installation options, examples, content development, or contribution guides, check out the Capact documentation.

🤔 Get support: If you need any help, or you have a question for us, join our Slack channel on the CNCF workspace and post a message—we'll do our best to get you sorted!

Currently, Capact is at an experimental stage. We open-sourced Capact as early as possible to get early feedback and build Capact together with the community.

Wait, there's more!

In a series of future blog posts, we will highlight Capact features and cover various topics for all!

Also, as of September 20th 2021, a brand-new release, Capact 0.5.0, is here. We were working really hard to bring many UX improvements, both for Capact users and content developers. The list includes:

Complete Action input validation and more advanced, concurrent Capact manifests validation with optional server-side checks,
Experimental content development tools for Helm and Terraform-based (AWS and GCP) manifest generation,
Policy syntax and behavior changes for improving consistency and usability,
Verbose output for Capact CLI,
Dependency updates, including migration to Argo 3,
Air-gapped Capact installation,
k3d support,
and much, much, more!

To see the full list of features, read the release notes.

Are you ready to start playing around with Capact?

source: tenor.com

Originally published at https://capact.io on September 7, 2021 and updated on September 20th, 2021 to highlight that the Capact 0.5.0 release is publicly available.