Using Meshery CLI
Meshery’s command line interface is
mesheryctl to both manage the lifecyle of Meshery itself and to access and invoke any of Meshery’s application and cloud native management functions.
mesheryctl commands can be categorized as follows:
mesheryctl- Global overrides and flags
mesheryctl app- Service Mesh Application Management
mesheryctl filter- Service Mesh Filter Management
mesheryctl mesh- Service Mesh Lifecycle & Configuration Management
mesheryctl perf- Service Mesh Performance Management
mesheryctl pattern- Service Mesh Pattern Configuration & Management
mesheryctl system- Meshery Lifecycle and Troubleshooting
Configuring Meshery Deployments with meshconfig
Meshconfig refers to a configuration file found at
~/.meshery/config.yaml. Your meshconfig file must contain one or more
contexts in order for any
mesheryctl system command to work. Each context represents a Meshery deployment.
Each of the
system commands are used to control Meshery’s lifecycle like
reset and so on.
Meshery CLI FAQ
Question: What is the meshconfig?
Like kubeconfig for
kubectl, meshconfig is the name of your
mesheryctl config file. You can find your meshconfig file in its default location of
~/.meshery/config.yaml. By default,
mesheryctl will look to this location for your meshconfig. You can override the default location at anytime with the use of the global parameter,
Question: What is a context?
context represents a single Meshery deployment. Using
contexts, you can configure different Meshery deployments with environment-specific settings and you can easily switching between your individual Meshery deployments by updating your current-context.
Question: Why are contexts necessary?
Many Meshery users have more than one Meshery deployment. Contexts allow you to deploy different versions of Meshery, update your release channel subscription settings, selectively install one or more Meshery Adapters, and so on. Contexts allow you to configure your invididual Meshery deployments.
Question: What is
current-context identifies the Meshery deployment that when any
mesheryctl command is invoked will use the environment described in the
current-context. You can switch between contexts. Only one context can be the
Question: What’s the difference between contexts and environments?
Contexts configure Meshery deployments (server, adapters, operator and so on), while environments define a collection of Kubernetes clusters and service meshes under management in Meshery.
Question: What does the default meshconfig look like?
The following template is used to create a config file from scratch. Not all of the following variables are required to be included. Some of the variables may have a null value or may be excluded (e.g. “adapters”).
contexts: <context1-name>: endpoint: <url to meshery server rest api> token: <name of token variable in this config file> platform: <type of platform: ”docker” or “kubernetes”> # Future: specify type of kubernetes (e.g. eks) adapters: <collection of names of service mesh adapters: “istio”,“linkerd”,”consul”,”nginx-sm”,”octarine”,”tanzu-sm”,”citrix-sm”,”kuma”,”osm”,”nsm”> <context2-name>: endpoint: <url to meshery server rest api> token: <name of token variable in this config file> platform: <type of platform: ”docker” or “kubernetes”> current-context: <context name> tokens: - name: <token1-name> location: <token-location> - name: <token2-name> value: <token-value> # Future: allow embedding of token certificate
Try it out and see for yourself. Run
mesheryctl system context create test and
mesheryctl system context view test.
Question: How do endpoints work in meshconfig?
Endpoints specify the access URL for the Meshery UI, for a deployment. Endpoints are developed based on platform:
- Docker: Docker users can specify the endpoint in the meshconfig. The port specified in this will be used to generate the endpoint. The endpoint is of the form
portis taken from the meshconfig.
- Kubernetes: Deployments with kubernetes as the platform have an endpoint generated by service discovery using the Kubernetes API. This endpoint overwrites the endpoint specified in the meshconfig.
Users can control the specific container image and tag (version) of Meshery that they would like to run by editing their local ~/.meshery/meshery.yaml (a docker compose file). Aligned with the Meshery container image, instead of leaving the implicit :stable-latest tag behind image: layer5/meshery, users will instead identify a specific image tag like so:
bash version: '3' services: meshery: image: layer5/meshery:v0.5.0 labels: - "com.centurylinklabs.watchtower.enable=true"
For an exhaustive list of
mesheryctl commands and syntax:
Guides to using Meshery’s various features and components.
Recent Discussions with "mesheryctl" Tag
- Dec 21 | Facing an error in setting up meshery locally
- Dec 17 | Error installing Meshery on Ubuntu 22.04
- Dec 07 | Error deploying mesheryctl
- Nov 08 | Not able to choose an adapter an install mesheryctl command
- Oct 06 | Unable to setup meshery docs on local (mac)
- Sep 27 | Issue while setting up meshery using GItpod
- Sep 03 | How to run Mesheryctl locally in my system
- Jul 27 | Mesheryctl app import: Design Spec Review
- Jul 27 | Meshery Not Starting (mesheryctl)
- Jul 06 | Call for Feedback: Behavior changes in `mesheryctl mesh`