Concepts
As an extensible platform, Meshery empowers you with a wide range of logical constructs that provide support for the majority of the systems in the cloud and cloud native ecosystems. Meshery abstracts away the system specific requirements and help you focus on getting things done.
Logical Concepts
- Components - Meshery Components identify and characterize infrastructure under management.
- Connections - Meshery Connections are managed and unmanaged resources that either through discovery or manual entry are managed by a state machine and used within one or more Environments.
- Credentials - Meshery uses one or more Credentials when authenticating to a managed or unmanaged Connection.
- Designs - Meshery Designs are descriptive, declarative characterizations of how your Kubernetes infrastructure should be configured.
- Environments - Environments are how you organize your deployment targets (whether on-premises servers or cloud services) into resource groups.
- Models - Meshery uses a set of resource models to define concrete boundaries to ensure extensible and sustainable management.
- Patterns - Meshery Patterns are descriptive, declarative characterizations of how your Kubernetes infrastructure should be configured.
- Policies - Meshery Policies enable you with a broad set of controls and governance of the behavior of systems under Meshery's management.
- Registry - Meshery Registry is a database acting as the central repository for all capabilities known to Meshery. These capabilities encompass various entities, including models, components, relationships, and policies.
- Relationships - Meshery Relationships identify and facilitate genealogy between Components.
- Workspaces - Meshery Workspaces act as central collaboration point for teams.
The logical concepts included in Meshery establish a set of foundational constructs. Each logical construct is:
- Versioned (see Schemas)
- Extensible (see Extension Points)
- Composable (see Patterns)
- Portable (see Export/Import of Designs and Models)
- Interoperable (see Compatibility Matrix)
- Configurable (see Lifecycle Management)
- Documented (you are here)
- Testable
- Maintainable
- Secure (v0.9.0)
- Observable (v0.1.0)
Every construct is represented in each of the following forms:
- Schema (static) - the skeletal structure representing a logical view of the size, shape, characteristics of a construct.
- Example: Component schema found in github.com/meshery/schemas
- Definition (static) - An implementation of the Schema containing specific configuration for the construct at-hand.
- Example: Component definition generically describing a Kubernetes Pod
- Declaration (static) - A defined construct; A specific deof the Definition.
- Example: Component configuration of an NGINX container as a Kubernetes Pod
- Instance (dynamic) - A realized construct (deployed/discovered); An instantiation of the Declaration.
- Example: NGINX-as234z2 pod running in cluster