This article provides some guidance for deploying a Ziti Controller. You can go back and read the controller component introduction if needed.
Public Key Infrastructure
You will need a PKI setup for Ziti. If you follow one of the quickstart guides then a PKI will be generated for you. This is probably the best way to start out. Pay particular attention to the PKI-related fields in the configuration file, and check out the pki page.
The Ziti Controller's configuration is loaded from a YAML file. If you follow one of the quickstart guides a configuration file will be generated. You can generate a configuration with the
ziti create config controller command, optionally mutating the result through command-line options or environment variables. You can also find an annotated sample config file from the Ziti repo.
The controller listens on several configurable server ports that must be exposed.
1280/tcp: client sessions and management API
6262/tcp: router control plane
You may configure the controller to expose management functions on separate port if you wish to limit network access for password authenticators.
All Ziti components log to standard output and standard error file descriptors.
- Log Formats
- Log Levels
Output from Ziti components comes in three distinct styles. Choose the style of logging that is right for you.
pfxlog- a human-readable format leveraging ascii escape codes to display colorized log level
json- a machine-readable format targeting automated processes for log aggregation/searching
text- a human-readable format using plain text (no ascii escape codes)
ziti-router run ./router.yml --log-formatter pfxlog
By default the Ziti components will log at the
INFO level. This means that log messages
FATAL will all be emitted. Ziti components all support verbose logging by adding
--verbose or -v to the command being executed. Verbose mode will add
DEBUG log messages.
ziti-controller run ./ctrl.yml --verbose