Using the CLI
Codezero's tools can be used via the Desktop app or the CLI. If you installed the Desktop app you also have the CLI.
This section is about getting up and running with the CLI.
Configure the CLI
Many CLI commands need to interact with a Kubernetes cluster, therefore the CLI requires access to a kubeconfig for your cluster.
Accessing Your Cluster
By default, Codezero uses the default cluster in ~/.kube/config. Alternatively, you can set the KUBECONFIG environment variable to point to your kubeconfig file.
export KUBECONFIG=<path to kubeconfig>
Some commands let you explicitly specify a kubeconfig file.
This is the same as configuring the kubectl CLI. See here for more information.
Getting Help
The CLI is invoked via the czctl command. To get more information about individual commands, see the associated command under References (e.g. Teleport), or run:
> czctl help
Initialize the CLI
Start the Codezero daemon (background service) by running:
> czctl start
Codezero requires sudo access to modify your system's hosts file. The hosts file is used to define in-cluster DNS information on your local machine during a teleport session.
Run commands
The czctl command loosely follows the conventions of the kubectl command, where each command references a Kubernetes resource (like a deployment or service), and where a namespace is given with a -n flag.
Use czctl <command> --help to see the options available for a given command.
Most czctl commands take the form czctl <action> <resource>, and czctl <action> <resource> --help will display the argument(s) and flag(s) available for that command.
Some examples:
> czctl teleport namespace --help
> czctl intercept service --help
> czctl mount --help
> czctl config --help
Session commands are an exception in that they take the form czctl <resource> <action>.
> czctl session list --help
> czctl session close --help
Configuration
The primary concept behind the Configuration command is to help developers to develop and debug their code locally by bringing in configuration from a workload.
Use Case
A problem that developers encounter is that they need to locally use the same configuration that a remotely deployed service uses. Finding the configuration and setting of a remote service so that the local service can use it is a time-consuming task. Additionally, if the configuration changes on the server, the developer may not be aware of those changes when they occur. Configurations need to be updated locally as they change remotely.
Codezero resolves this by enabling developers to bring down environment variables from workloads they are modifying and have the local configuration files update as they change on the server.
Under the Hood
The Configuration command starts a watch of the configuration files of the workload and writes to the given environment file as configuration changes in the cluster.
Residue
The configuration command makes no changes to your remote cluster and the only residue is the file where the configuration is written and the watcher process.
However, if the configuration watcher continues to run after a clean/close has been performed, you will need to find the process id and do a kill -9 of the configuration monitor process.
Here's an example of getting the process ids and using kill -9 to end these processes:
> ps xau | grep 'child.js' | grep -v 'grep' | awk '{print $2 " -> " $11, $12}'
65120 -> /Users/username/.codezero/bin/czdaemon/czdaemon /snapshot/node-monorepo/gulpfile.js/tmp/czdaemon/package/lib/engine/services/monitors/env/child.js
> sudo kill -9 65120
Command Reference
See the Configuration command reference for more information.