DEV Community: Amit Kumar Das

Workflow Creation with Litmus 2.0 Beta

Amit Kumar Das — Tue, 18 May 2021 09:24:12 +0000

With Litmus 2.0 announced, you are no longer confined to perform Chaos Engineering with a terminal in your hand. You now have a control plane to create, schedule and analyze chaos workflows with our upgraded Litmus Portal.

The new Litmus Portal makes chaos engineering fun and hassle free. With a single click, you can re-run a workflow without configuring it again. Don't want to create a new workflow from scratch, just save one of the existing workflow as a predefined template and much more. In this blog we will go through all the new features that are added to the Portal with the 2.0 update.

Before moving ahead, let's know about Litmus. ❓

Litmus is a complete framework to perform chaos engineering in a cloud-native ecosystem.
It is a toolkit to orchastrate chaos on Kubernetes. It allows SRE to inject chaos in the environment and find the bugs and vulnerabilities in the system. Fixing these vulnerebilities will ultimately make the system resilient.

Chaos experiments are hosted on ChaosHub. It is a public marketplace where different vendors share their chaos experiments so that their users can use them to increase the resilience of the applications in production.

New Upgrades with Litmus 2.0 🚀

Workflow Creation ✍️

Choose a workflow 🎟️

With the new Litmus Portal, you can choose workflows from 4 different ways.

a. Create a new workflow from one of the pre-defined chaos experiment. With this option, you can select the pre-defined experiments that executes chaos operations on real-world applications like sock-shop. Currently there are 3 pre-defined experiments available sock-shop-chaos,kube-proxy-chaos and the new podtato-head-chaos.

b. Create a new workflow by cloning and existing workflow. With this option, you can save an existing workflow as a template from the scheduled workflows. This options saves some time if you don't want to schedule a workflow from scratch.

c. Create a new workflow using experiments from MyHub. With this option, you can create custom experiments from the connected MyHubs. By default , the public Chaos Hub is already installed. You can connect a MyHub with the following steps

d. Import workflow using YAML. With this option, you can upload a workflow manifest and tune it according to the use-case and schedule it.
Tune Workflow 🎯

A lot of new changes are added in the tune workflow section, these include:

a. Workflow Visualisation 👀 - Now visualize your workflow even before scheduling it. This feature gives a breif idea about the sturcture of the workflow. You can view the experiments if they are parallel or serial.

b. Experiments Table 📋 - This table give valuable information about the experiments present in the workflow. It also shows the target applications of each experiments where chaos will be injected.
c. Sequencing Experiments 🔧 - This is one of the major feature we added with the 2.0 update, with this you can tune the sequence of the workflow by dragging and dropping the experiment as shown below. This allows you to sequence your experiments parallel and serial manner.

d. Tune Experiments 🔥 - Our prior focus with the 2.0 update was to make the experiment tuning step hassle free for the user, hence we added the Kubernetes Object integration in this step. With this you can get the cluster details like the available namespaces and the application labels according to the resourse type. This allows you to target the application to inject chaos in a much simpler way.

e. Probes Integration ⌚ - Now you can add probes directly from the portal. The probe properties are available dynamically in the portal. Select one probe and add it in your chaos engine to enhance your chaos testing.

f. Reliability Score 💯 - The look and feel of the reliability score page is also upgraded, it now gives a clearer idea about the weights of the expeiments.

Conclusion

So these were the new changes we have added in the workflow creation steps. Stay tuned, a lot of new features will be available in the coming releases.

Make sure to try the Litmus Portal 2.0 and give your valuable feedback and suggestion. Don’t forget to checkout our Litmus website and the Litmus repo. Do leave a star if you find it interesting. 😊

Further, feel free to put forward any queries or concerns you have. I would love to address them. I would love to invite you to our slack community for keeping up to date and interacting with our community members, contributors & maintainers.
To join our slack please follow the following steps!
Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/
Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/

Cheers!

Custom Workflow with MyHub using Litmus Portal

Amit Kumar Das — Thu, 07 Jan 2021 12:04:03 +0000

Hello Chaos Engineers,
In this article, we will get to know about one of the salient features of Litmus Portal i.e My Hub. We will go through the steps from connecting a hub to creating a custom workflow. My Hub allows SREs to orchestrate their Litmus Experiments directly from their respective Github repositories.

What is Litmus and how we can run chaos experiments using Litmus Portal?

Litmus is an open-source chaos engineering framework that provides tools to set up chaos in Kubernetes to help developers and SREs discover weaknesses and flaws in the application system. It is very easy to use and comes with detailed documentation. It also provides a large collection of chaos experiments, which you can find here. If you want to get started with Litmus Portal and how to create a custom workflow, this article is surely going to help you. You can also join our slack community for an open discussion.
Litmus Portal allows you to create, run and analyze the chaos workflows using a UI console. SREs can invite their team members to work on different projects and analyze the workflows present in the projects. Currently the Litmus Portal is in beta-0 version and lots of improvements are being added on a daily basis.

Steps involving the creation of custom workflows using MyHub are :

Using the Default MyHub:
When a user creates a project on Litmus Portal, a default MyHub is provided to the user. It is similar to the Litmus ChaosHub.
Connecting a MyHub:
Users can connect their chaos hubs from their Github repositories using the github link and the branch name. Once this step is done, the user can view their connected hub in the My Hub section.
View charts and experiments:
Users can select one of the hubs and view the charts present in the particular hub. The user can view a variety of chaos experiments and these are sorted according to their types like generic, kube-aws etc.

The user can then select one of the charts and view the details about the experiments.

The user can install the experiment using the experiment link, the user can also setup a service account using the RBAC link and we also provide the link for chaos engine which is highly configurable.
Customize your workflows using MyHubs:
The users can click the “Create your own workflow” card in the pre-defined templates section to start creating the custom workflows.

Here the user can select a hub and choose the experiment from the different My Hubs present in the project. The user can also specify the namespace where he wants to run the chaos experiment.
After selecting the experiment from the hub, the user can now customize the experiment, the users can now tune the workflow according to their requirement.

The users can edit the appinfo which includes the appns, applabel, appkind.
To know more about appns, applable etc, please check the Litmus Docs
The users can tune the variables of the chaos engine and add more key value pairs as necessary.

Once the user has customized the experiment , more experiments can be added to the workflows. The user can also alter the sequence of the experiments in the workflow according to the requirements. Once the user clicks the Finish adding the experiments button, a YAML is generated consisting of the experiment details that the user has selected while configuring the workflow.

Here in this custom workflow, I have selected two experiemnts generic/pod-delete and generic/pod-cpu-hog. The generated YAML comprising these two experiment is

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: custom-chaos-workflow-1609259040
  namespace: litmus
spec:
  arguments:
    parameters:
      - name: adminModeNamespace
        value: litmus
  entrypoint: custom-chaos
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: argo-chaos
  templates:
    - name: custom-chaos
      steps:
        - - name: install-chaos-experiments
            template: install-chaos-experiments
        - - name: pod-delete
            template: pod-delete
        - - name: pod-cpu-hog
            template: pod-cpu-hog
        - - name: revert-chaos
            template: revert-chaos
    - name: install-chaos-experiments
      container:
        args:
          - kubectl apply -f
            https://github.com/litmuschaos/chaos-charts/raw/master/charts/generic/pod-delete/experiment.yaml
            -n {{workflow.parameters.adminModeNamespace}} | kubectl apply -f
            https://github.com/litmuschaos/chaos-charts/raw/master/charts/generic/pod-cpu-hog/experiment.yaml
            -n {{workflow.parameters.adminModeNamespace}} | sleep 30
        command:
          - sh
          - -c
        image: lachlanevenson/k8s-kubectl
    - name: pod-delete
      inputs:
        artifacts:
          - name: pod-delete
            path: /tmp/chaosengine-pod-delete.yaml
            raw:
              data: |
                apiVersion: litmuschaos.io/v1alpha1
                kind: ChaosEngine
                metadata:
                  name: pod-delete
                  namespace: "{{workflow.parameters.adminModeNamespace}}"
                spec:
                  appinfo:
                    appns: default
                    applabel: app=nginx
                    appkind: deployment
                  annotationCheck: "false"
                  engineState: active
                  chaosServiceAccount: litmus-admin
                  monitoring: false
                  jobCleanUpPolicy: delete
                  experiments:
                    - name: pod-delete
                      spec:
                        components:
                          env:
                            - name: TOTAL_CHAOS_DURATION
                              value: "30"
                            - name: CHAOS_INTERVAL
                              value: "10"
                            - name: FORCE
                              value: "false"
      container:
        args:
          - -file=/tmp/chaosengine-pod-delete.yaml
          - -saveName=/tmp/engine-name
        image: litmuschaos/litmus-checker:latest
    - name: pod-cpu-hog
      inputs:
        artifacts:
          - name: pod-cpu-hog
            path: /tmp/chaosengine-pod-cpu-hog.yaml
            raw:
              data: |
                apiVersion: litmuschaos.io/v1alpha1
                kind: ChaosEngine
                metadata:
                  name: pod-cpu-hog
                  namespace: "{{workflow.parameters.adminModeNamespace}}"
                spec:
                  annotationCheck: "false"
                  engineState: active
                  appinfo:
                    appns: default
                    applabel: app=nginx
                    appkind: deployment
                  chaosServiceAccount: litmus-admin
                  monitoring: false
                  jobCleanUpPolicy: delete
                  experiments:
                    - name: pod-cpu-hog
                      spec:
                        components:
                          env:
                            - name: CPU_CORES
                              value: "1"
                            - name: TOTAL_CHAOS_DURATION
                              value: "60"
      container:
        args:
          - -file=/tmp/chaosengine-pod-cpu-hog.yaml
          - -saveName=/tmp/engine-name
        image: litmuschaos/litmus-checker:latest
    - name: revert-chaos
      container:
        args:
          - kubectl delete chaosengines --all -n
            {{workflow.parameters.adminModeNamespace}}
        command:
          - sh
          - -c
        image: lachlanevenson/k8s-kubectl

Now the user can run the workflow and see the results in the analytics section. Once the workflow execution is completed , the user can view the workflow in a graphical format that consists of all useful informations like the nodes, step groups etc.

Conclusion

Now you are not limited to some predefined workflows, even if you are beginner. You are getting your own chaos template that it highly customisable. Using the Public Hub and your own My Hub, you get all the chaos experiments at one place. You can play around with all the configuration from the UI and check the changes that are happening in the workflow.

Feel free to check out our ongoing project - Litmus Portal and do let us know if you have any suggestions or feedback regarding the same. You can always submit a PR if you find any required changes.

Make sure to reach out to us if you have any feedback or queries. Hope you found the blog informative!

If chaos engineering is something that excites you or if you want know more about cloud native chaos engineering, don’t forget to checkout our Litmus website, ChaosHub and the Litmus repo. Do leave a star if you find it insightful. 😊

I would love to invite you to our community to stay connected with us and get your Chaos Engineering doubts cleared.
To join our slack please follow the following steps!
Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/
Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/

Cheers!

Test Driven Development using Cypress

Amit Kumar Das — Fri, 21 Aug 2020 14:54:45 +0000

In this blog, we will be discussing test-driven development with Cypress along with some of the best practices for unit testing. As frontend developers, our main objective is to create different UI screens that include the development of various functional and reusable components. But one thing that most of us do not put into practice, maybe because we don’t understand its importance is testing, especially front-end unit testing.

What is Unit Testing?
First things first! Let’s understand what unit testing is.
Unit testing makes sure that the basic building blocks of the project including methods, UI elements, etc. are working properly. In React components, it lets the developer know if they are being rendered properly, whether the props are being passed to the components in a proper state, etc.

Why is it important?

In a bigger project, as the number of components increases, unit testing becomes the savior for the developers. We can test individual code before the complete integration and get faster feedback on the working of components without impacting the other sections of the project!
Inculcating the practice of writing unit tests, not only makes us think harder about the problem but also helps us discover the edges cases which in turn makes us write better quality of code.
Since the bugs are found in the starting phase, it reduces the overhead of fixing it in later stages, which would be a daunting task for us as developers.

So, we’ll be talking about the Cypress testing we do in Litmus.
Litmus is an open-source chaos engineering framework that provides tools to set up chaos in Kubernetes in order to help developers and SREs discover weaknesses in the application deployment. It is very easy to use and comes with detailed documentation. It also provides a large collection of chaos experiments, which you can find here. If you want to get started with Litmus, this article is surely going to help you. You can also join our slack community for an open discussion. Currently, we are developing the Litmus Portal which provides console and UI experience for managing, monitoring, and events around chaos workflows using the React and Typescript for the frontend.

What is Cypress?
Cypress is a Javascript-based testing framework that is built on top of Mocha which itself is a full-featured Javascript testing framework. It also includes cross-browser testing that makes it more preferable to use.
As mentioned in the official documentation of Cypress, Cypress facilitates a developer to write all types of tests :

Unit tests
Integration tests
End to End tests

Why Cypress?
Before jumping into its implementation let’s get to know why did we choose Cypress for unit testing. So the primary reasons are:

With in-browser execution, it is incredibly fast!
We didn’t have to worry about its setup as it is very easy to use and provides very good and detailed documentation.
It also boasts about a growing community.

Some of the best practices that we have followed while doing unit testing are:

Used unique “data-cy” attributes to make it easier in targeting the elements, targeting the elements using a tag, id or class should be prevented as these are highly subject to change. For example:

<button id="main" class="btn btn-large" name="submission"
  role="button" data-cy="submit">Submit</button>
  cy.get('[data-cy=submit]').click()

Maintained well defined and clean folder structure. All the tests are stored in cypress/components in the litmus-portal/frontend directory.
We have added logs wherever it is required to make the debugging easy.
We have tried to limit one assert per method to avoid confusion in case of failure.
Each of the tests is independent of each other so that the tests can be executed in any order and failure of one test case doesn’t affect others.
We have kept each of the tests short and simple to enhance readability and understanding.

Since the project is using Typescript in the frontend, we have written all the tests in the same.
So, now we’ll be setting up cypress along with a small react app.

Prerequisites:

React app
Custom components
Cypress

Installing cypress

Install cypress using npm

  npm install cypress

Install cypress using yarn

  yarn add cypress

Once Cypress is successfully installed, you can try it out by running these commands.

Open Cypress

Open cypress using npm

  npx cypress open

Open cypress using yarn

  yarn run cypress open

Setting up Cypress in the react app with Typescript for the unit-test:

Install Cypress React Unit Test Plugin

npm install --save-dev cypress cypress-react-unit-test

Configure your tsconfig.json by adding these

{
   "compilerOptions": {
       "target": "es5",
       "lib": ["dom", "dom.iterable", "esnext"],
       "types": ["node", "cypress"]
   },
   "include": ["src", "cypress/component/*.tsx"]
}

Configure your cypress.json by adding these

{
   "experimentalComponentTesting": true,
   "componentFolder": "cypress/component",
   "specFiles": "*spec.*",
   "defaultCommandTimeout": 4000,
   "execTimeout": 200000,
   "taskTimeout": 200000
}

Make sure you specify the folder that contains the test cases, here the test scripts are present in the cypress/components folder.
These timeouts can be checked here.

Inside your Cypress folder add the following export statements inside plugin/index.js file

* @type {Cypress.PluginConfig}
*/
module.exports = (on, config) => {
   require("cypress-react-unit-test/plugins/react-scripts")(on, config);
   // IMPORTANT to return the config object
   // with the any changed environment variables
   return config;
};

In this file, we have exported a function. Cypress is going to call this function, pass the project’s configuration, and enable it to bind to the events exposed.

Writing your first unit test in Cypress

So we have created this basic react app in which the user will enter a value between 1-10 using an InputField and the progress bar will change its color accordingly, it also has a semi-circular progress bar that takes input and changes according to the value entered. We have used these components in the Litmus Portal as well.

Use Case :

If the entered value is between 1-3, the progress bar color will change to red.
If the entered value is between 4-6, the progress bar color will change to yellow.
If the entered value is between 7-10, the progress bar color will change to green.
In case of the semicircular progress bar, it will take an input between 1-100 and display the result accordingly.

The landing page of our react app looks like this.

Let’s write some unit tests for these components:

Linear ProgressBar
For this component we’ll perform few tests, for example :

The length of the stroke according to the value
The color progress bar when the value is 2
The color progress bar when the value is 6
The color progress bar when the value is 8

The test script for this component looks like this:

/// <reference types="Cypress" />
import React from "react";
import { mount } from "cypress-react-unit-test";
import LinearProgressBar from "../../src/components/ProgressBar/LinearProgressBar";

describe("Linear Progressbar Testing", () => {
 it("Progressbar stroke for value 2", () => {
   mount(<LinearProgressBar value={2} />);
   cy.get(".rc-progress-line-path").should(
     "have.css",
     "stroke-dasharray",
     "20px, 100px"
   );
 });
 it("Progressbar stroke for value 8", () => {
   mount(<LinearProgressBar value={8} />);
   cy.get(".rc-progress-line-path").should(
     "have.css",
     "stroke-dasharray",
     "80px, 100px"
   );
   cy.get(".rc-progress-line-path").should("have.attr", "stroke", "#109B67");
 });
 it("Progressbar stroke for value 6", () => {
   mount(<LinearProgressBar value={6} />);
   cy.get(".rc-progress-line-path").should(
     "have.css",
     "stroke-dasharray",
     "60px, 100px"
   );
   cy.get(".rc-progress-line-path").should("have.attr", "stroke", "#F6B92B");
 });

describe(): This function is used to describe the test suite for the corresponding component as “Linear Progressbar Testing”
it(): Inside that, we have specified the particular test names like “Progressbar stroke for value 2” using this function.

Note: describe() and it() are some of the test interfaces provided by Mocha.

describe("Linear Progressbar Testing", () => {
 it("Progressbar stroke for value 2", () => {
   mount(<LinearProgressBar value={2} />);
   cy.get(".rc-progress-line-path").should(
     "have.css",
     "stroke-dasharray",
     "20px, 100px"
   );
 });

mount(): This function mounts the component for testing.
We have added the props that the components take i.e value={2} here.
Once the component has been mounted/rendered properly we can check different properties of the component, like in this case, we are checking for the width of the progress bar when the value is 2 with the help of should(“have.css”, “css-property”, “css-value”)

Once the test succeeds , we get the following results in the browser:

Similarly, in the next test:

mount(<LinearProgressBar value={8} />);
   cy.get(".rc-progress-line-path").should(
     "have.css",
     "stroke-dasharray",
     "80px, 100px"
   );
   cy.get(".rc-progress-line-path").should("have.attr", "stroke", "#109B67");
 });

Here we are re-mounting the component with a different prop ie value as 8.
Once it is done, we can check the width of the progress bar and can check if the correct color is being displayed, in this case “#109B67” as the value is above 7.
This can be done using should(“have.attr”,” stroke”,”#109B67”), here we are checking if the color of stroke is according to the use-case i.e Green / #109B67.

Semi-Circular ProgressBar
The test script for this component looks like this:

/// <reference types="Cypress" />

import React from "react";
import { mount } from "cypress-react-unit-test";
import SemiCircularProgressBar from "../../src/components/ProgressBar/SemiCircularProgressBar";

// Test Suite -
// Progress Bar props -> value = 50, 10, 100
describe("Semi Circular Progress Bar has appropriate values", () => {
 [50, 10, 100].map((i) => {
   it(`Value is equal to ${i}`, () => {
     const wrapper = <SemiCircularProgressBar value={i} />;
     mount(wrapper);
     cy.get("[data-cy=progressValue]").then((value) => {
       expect(value[0].innerText).to.equal(`${i}%`);
     });
   });
 });
});

// Test Suite - Icon has the correct src
describe("Icons have a correct path", () => {
 it("Progress Bar icon has a correct source", () => {
   const wrapper = <SemiCircularProgressBar value={40} />;
   mount(wrapper);
   cy.get("[data-cy=progressIcon]")
     .should("have.attr", "src")
     .should("include", "./icons/graph.svg");
 });
});

For this component we are performing four tests. Three tests to check if the proper values are being passed in the props and the last test is to check if the image is taken from the correct source.

Here we are using an array of values that is being mapped with the component.

[50, 10, 100].map((i) => {
   it(`Value is equal to ${i}`, () => {
     const wrapper = <SemiCircularProgressBar value={i} />;
     mount(wrapper);
     cy.get("[data-cy=progressValue]").then((value) => {
       expect(value[0].innerText).to.equal(`${i}%`);
     });
   });
 });

Here we are using "[data-cy=progressValue]" to easily target the element for which we are writing the test cases. We can then make sure that the correct value is being displayed in the component as shown below.

it("Progress Bar icon has a correct source", () => {
   const wrapper = <SemiCircularProgressBar value={40} />;
   mount(wrapper);
   cy.get("[data-cy=progressIcon]")
     .should("have.attr", "src")
     .should("include", "./icons/graph.svg");
 });

Similarly, in these test cases, we are checking if the source of the image is correct with the should() attribute that we discussed above.

Conclusion

So these were some of the basic examples of unit testing we did with Cypress. If you wish, you can also add more test suites here. Feel free to check out our ongoing project - Litmus Portal and do let us know if you have any suggestions or feedback regarding the same. You can always submit a PR if you find any required changes.

This blog is also contributed by:

Since this is our first blog, would love to know your views and suggestions. Feel free to reach out to us if you have any queries. Hope you found it insightful!

Last but not the least, if chaos engineering is something that excites you or if you want know more about cloud native chaos engineering, don’t forget to checkout our Litmus website and the Litmus repo. Do leave a star if you find it interesting. 😊

Cheers!