Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated documentation in Architecture section for 3.0 #239

Merged
merged 4 commits into from
Oct 9, 2023
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions website/docs/architecture/architecture-summary.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,16 @@ sidebar_label: Architecture Summary

The Litmus architecture can be segregated into two parts:

1. **Control Plane:** Contains the components required for the functioning of Chaos Center, the website-based portal for Litmus.
1. **Control Plane:** Contains the components required for the functioning of ChaosCenter, the website-based portal for Litmus.

2. **Execution Plane:** Contains the components required for the injection of chaos in the target resources.

Chaos Center can be used for creating, scheduling, and monitoring Chaos Scenarios, a set of chaos experiments defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the Chaos Center using valid login credentials and leverage the interactive web UI to define their chaos scenario to target multiple aspects of their infrastructure. Once the user creates a Chaos Scenario using the Chaos Center, it is passed on to the Execution Plane. The Execution Plane can be present either in the host cluster containing the Control Plane if the self chaos delegate is being used, or in the target cluster if an external chaos delegate is being used. The Execution Plane interprets the Chaos Scenario as a list of steps required for injecting chaos into the target resources. It ensures efficient orchestration of chaos in cloud-native environments using various Kubernetes CRs. Once the Chaos Scenario is executed, Execution Plane sends the chaos result to the Control Plane for their post-processing using either the built-in monitoring dashboard of Litmus or using external observability tools such as Prometheus DB and Grafana dashboard. Litmus also achieves automated Chaos Scenario runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps.
ChaosCenter can be used for creating and scheduling Chaos Experiments, a set of chaos faults defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the ChaosCenter using valid login credentials and leverage the interactive web UI to define their chaos experiment to target multiple aspects of their infrastructure. Once the user creates a Chaos Experiment using the ChaosCenter, it is passed on to the Execution Plane. The Execution Plane can be present either in the host cluster containing the Control Plane if the self chaos infrastructure is being used, or in the target cluster if an external chaos infrastructure is being used. The Execution Plane interprets the Chaos Experiment as a list of steps required for injecting chaos into the target resources. It ensures efficient orchestration of chaos in cloud-native environments using various Kubernetes CRs. Once the Chaos Experiment is executed, Execution Plane sends the chaos result to the Control Plane for their post-processing using either the built-in monitoring dashboard of Litmus or using external observability tools such as Prometheus DB and Grafana dashboard. Litmus also achieves automated Chaos Experiment runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps.

:::note
With the latest release of LitmusChaos 3.0.0:

<li>The term <b>Chaos Delegate/Agent</b> has been changed to <b>Chaos Infrastructure.</b> </li>
<li>The term <b>Chaos Experiment</b> has been changed to <b>Chaos Fault.</b> </li>
<li>The term <b>Chaos Scenario/Workflow</b> has been changed to <b>Chaos Experiment.</b></li>
:::
28 changes: 14 additions & 14 deletions website/docs/architecture/chaos-control-plane.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,33 +8,33 @@ sidebar_label: Chaos Control Plane

<img src={require("../assets/chaos-control-plane.png").default} alt="Chaos Control Plane" />

Chaos Control Plane consists of micro-services responsible for the functioning of the Chaos Center, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos scenarios, system observability during the event of chaos, and post-processing and analysis of experiment results.
Chaos Control Plane consists of micro-services responsible for the functioning of the ChaosCenter, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos experiments, system observability during the event of chaos, and post-processing and analysis of fault results.

## Chaos Control Plane Components

- **Authentication Server:** A Golang micro-service that is responsible for authorizing, authenticating the requests received from Chaos Center and managing users along with their projects. It primarily serves the cause of user creation, user login, resetting the password, updating user information, creating project, managing project related operations.
- **Authentication Server:** A Golang micro-service that is responsible for authorizing, authenticating the requests received from ChaosCenter and managing users along with their projects. It primarily serves the cause of user creation, user login, resetting the password, updating user information, creating project, managing project related operations.

- **Backend Server:** A GraphQL based Golang micro-service that serves the requests received from Chaos Center, by either querying the database for the relevant information or by fetching information from the Execution Plane.
- **Backend Server:** A GraphQL based Golang micro-service that serves the requests received from ChaosCenter, by either querying the database for the relevant information or by fetching information from the Execution Plane.

- **Database:** A NoSQL MongoDB database micro-service that is accountable for storing users' information, past chaos scenarios, saved chaos scenario templates, user projects, ChaosHubs, and GitOps details, among the other information.
- **Database:** A NoSQL MongoDB database micro-service that is accountable for storing users' information, past chaos experiments, saved chaos experiment templates, user projects, ChaosHubs, and GitOps details, among the other information.

- **Chaos Center:** Refers to the interfaces used by Litmus for creation and scheduling of chaos scenarios, system observability during chaos injection, and post chaos result analysis. It includes:
- **ChaosCenter:** Refers to the interfaces used by Litmus for creation and scheduling of chaos experiments, system observability during chaos injection, and post chaos result analysis. It includes:

- **Web UI:** A React.js based frontend application micro-service with built-in system observability capabilities and an analytics dashboard. It also facilitates teams of users to collaborate over chaos scenarios using role-based user accounts.
- **Web UI:** A React.js based frontend application micro-service with built-in system observability capabilities and an analytics dashboard. It also facilitates teams of users to collaborate over chaos experiments using role-based user accounts.

- **Litmusctl:** A command-line tool that allows management of Litmus Chaos Delegate Infrastructure components. It can be used to create chaos delegates, project, and manage multiple Litmus accounts.
- **Litmusctl:** A command-line tool that allows management of Litmus Chaos Infrastructure Infrastructure components. It can be used to create chaos infrastructures, project, and manage multiple Litmus accounts.

- **Litmus API:** Refers to two different Litmus APIs, namely Litmus Authentication API and Litmus Portal API:

- **Litmus Authentication API:** Used to authenticate the identity of a user and to perform several user and project specific tasks like create new users, update profile, update password, create project, invite users to project, get project details etc. It uses the Authentication Server to perform these tasks.

- **Litmus Portal API:** Provides command-line and UI experience for managing and monitoring the events around chaos scenarios. It uses the Backend Server to perform its functions.
- **Litmus Portal API:** Provides command-line and UI experience for managing and monitoring the events around chaos experiments. It uses the Backend Server to perform its functions.

## Standard Chaos Control Plane Flow

1. The User logs in to the ChaosCenter using a valid login credential. A default project is created for the user on initial login. Every user is a part of a project and has a role assigned to them. To schedule a chaos scenario, the user needs to have an Editor or Owner role assigned in the project.
2. The user uploads a Chaos Scenario manifest using the ChaosCenter, which is received by the Backend Server.
3. Backend Server stores the manifest in the Database and also sends it to the Chaos Delegate.
4. Chaos Delegate uses the Chaos Scenario manifest to inject chaos into the target resources. The steps of the Chaos Scenario execution can be visualized using the ChaosCenter.
5. Chaos Delegate returns the results of the chaos experiments that were a part of the chaos scenario back to the Backend Server, along with the experiment logs.
6. Backend Server then sends the chaos experiment results and logs to the ChaosCenter. It also stores the results into the Database for generating post-chaos scenario statistics and information.
1. The User logs in to the ChaosCenter using a valid login credential. A default project is created for the user on initial login. Every user is a part of a project and has a role assigned to them. To schedule a chaos experiment, the user needs to have an Editor or Owner role assigned in the project.
2. The user uploads a Chaos Experiment manifest using the ChaosCenter, which is received by the Backend Server.
3. Backend Server stores the manifest in the Database and also sends it to the Chaos Infrastructure.
4. Chaos Infrastructure uses the Chaos Experiment manifest to inject chaos into the target resources. The steps of the Chaos Experiment execution can be visualized using the ChaosCenter.
5. Chaos Infrastructure returns the results of the chaos faults that were a part of the chaos experiment back to the Backend Server, along with the fault logs.
6. Backend Server then sends the chaos fault results and logs to the ChaosCenter. It also stores the results into the Database for generating post-chaos experiment statistics and information.
Loading
Loading