Logical
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 helps 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, and 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 instance of 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