cortexapps-cli 0.18.0

Command Line Interface for cortexapps

• Installation

  • pypi.org

  • homebrew

    • Workaround for homebrew installation

• Usage

  • Config file

  • Environment Variables

  • Commands

• Examples

  • Export from one tenant; import into another

  • Iterate over all domains

  • Iterate over all teams

  • Iterate over all services

  • Get git details for a service

  • Add a suffix to all x-cortex-tag values for services

  • Add a group to all domains

  • Remove a group from domains

  • Add a domain parent to a single service

  • Add a github group as an owner to a service

  • Modify all github basepath values for domain entitities, changing ‘-’ to ‘_’

  • Modify deploys based on selection criteria

Installation

pypi.org

pip install cortexapps-cli

Using a python virtual environment:

VENV_DIR=~/.venv/cortex
python3 -m venv $VENV_DIR
source $VENV_DIR/bin/activate
pip install cortexapps-cli

homebrew

The package will be published to homebrew in the future, but we need your help!

In order to be accepted to homebrew-core, a repository has to be ‘notable’. This is determined by running an audit of the homebrew formula. Currently, this results in the following:

brew audit --strict --new-formula --online cortexapps-cli
cortexapps-cli
  * GitHub repository not notable enough (<30 forks, <30 watchers and <75 stars)
Error: 1 problem in 1 formula detected.

Please help us by watching and starring https://github.com/cortexapps/cli. Once we’re ‘notable’, we’ll throw a small party for ourselves and then submit a PR to homebrew-core.

Workaround for homebrew installation

This is a temporary solution until we reach ‘notable’ status and get the formula added to homebrew-core.

Run the following commands to download the homebrew formula from this repo into your local homebrew tap:

curl -L -H "Accept: application/vnd.github.VERSION.raw" -o $(brew --repository)/Library/Taps/homebrew/homebrew-core/Formula/c/cortexapps-cli.rb https://api.github.com/repos/cortexapps/cli/contents/homebrew/cortexapps-cli.rb
HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source cortexapps-cli

Usage

Config file

The CLI requires an API key for all operations. This key is stored in a config file whose default location is ~/.cortex/config. This path can be overridden with the -c flag.

Minimal contents of the file:

[default]
api_key = REPLACE_WITH_YOUR_CORTEX_API_KEY

If you have multiple Cortex instances, you can create a section for each, for example:

[default]
api_key = REPLACE_WITH_YOUR_CORTEX_API_KEY

[my-test]
api_key = REPLACE_WITH_YOUR_CORTEX_API_KEY
base_url = https://app.cortex.mycompany.com

NOTE: if not supplied, base_url defaults to https://app.getcortexapp.com.

The CLI will retrieve configuration data from the [default] section unless you pass the -t/--tenant flag.

For example, to list all entities in the my-test tenant, run the following command:

cortex -t my-test catalog list

If the config file does not exist, the CLI will prompt you to create it.

Environment Variables

The CLI supports the following environment variables. If provided, the Cortex config file will not be read.

• CORTEX_API_KEY

• CORTEX_BASE_URL - this is optional if using Cortex cloud; defaults to https://app.getcortexapp.com

Example:

export CORTEX_API_KEY=<YOUR_API_KEY>

Commands

Run cortex -h to see a list of all commands:

Run cortex <subcommand> -h to see a list of all commands for each subcommand.

For example:

cortex audit-logs -h

usage: cortex CLI audit-logs [-h] {get} ...

positional arguments:
  {get}       audit logs help
    get       retrieve audit logs

options:
  -h, --help  show this help message and exit

Examples

Almost all CLI responses return JSON or YAML. Tools like jq and yq will be helpful to extract content from these responses.

Export from one tenant; import into another

This example shows how to export from a tenant named myTenant-dev and import those contents into a tenant named myTenant.

Your cortex config file will require api keys for both tenants. It would look like this:

[myTenant]
api_key = <your API Key for myTenant>

[myTenant-dev]
api_key = <your API Key for myTenant-dev>

Export

cortex -t myTenant-dev backup export

Getting resource definitions
 -->  my-resource-1
 Getting catalog entities
 -->  my-domain-1
 -->  my-service-1
 -->  my-service-2
 Getting IP Allowlist definitions
 Getting scorecards
 -->  my-scorecard-1
 Getting teams
 -->  my-team-1
 -->  my-team-2

 Export complete!
 Contents available in /Users/myUser/.cortex/export/2023-11-19-14-58-14

Import

cortex -t myTenant backup import -d <directory created by export>

NOTE: some content will not be exported, including integration configurations and resources that are automatically imported by Cortex. Cortex does not have access to any keys, so it cannot export any integration configurations.

Iterate over all domains

for domain in `cortex catalog list -t domain | jq -r ".entities[].tag" | sort`; do echo "domain = $domain"; done

Iterate over all teams

for team in `cortex catalog list -t team | jq -r ".entities[].tag" | sort`; do echo "team = $team"; done

Iterate over all services

for service in `cortex catalog list -t service | jq -r ".entities[].tag" | sort`; do echo "service = $service"; done

Get git details for a service

cortex catalog details -t my-service-1 | jq ".git"

{
  "repository": "my-org/my-service-1",
  "alias": null,
  "basepath": null,
  "provider": "github"
}

Add a suffix to all x-cortex-tag values for services

for service in `cortex catalog list -t service | jq -r ".entities[].tag" | sort`; do
   cortex catalog descriptor -y -t ${service} | yq '.info.x-cortex-tag |= . + "-suffix"' | cortex catalog create -f-
done

This example combines several CLI commands:

• the for loop iterates over all services

• the descriptor for each service is retrieved in YAML format

• the YAML descriptor is piped to yq where the value of x-cortex-tag is retrieved and modified to add “-suffix” to the end

• the modified YAML is then piped to the cortex catalog command to update the entity in cortex

NOTE: Any cortex commands that accept a file as input can also receive input from stdin by specifying a “-” after the -f parameter.

Add a group to all domains

for domain in `cortex catalog list -t domain | jq -r ".entities[].tag" | sort`; do
   cortex catalog descriptor -y -t ${domain} | yq -e '.info.x-cortex-groups += [ "my-new-group" ]' | cortex catalog create -f-
done

Remove a group from domains

for domain in `cortex catalog list -t domain -g my-old-group | jq -r ".entities[].tag" | sort`; do
   cortex catalog descriptor -y -t ${domain} | yq -e '.info.x-cortex-groups -= [ "my-old-group" ]' | cortex catalog create -f-
done

Add a domain parent to a single service

cortex catalog descriptor -y -t my-service | yq -e '.info.x-cortex-domain-parents += { "tag": "my-new-domain" }' | cortex catalog create -f-

Add a github group as an owner to a service

cortex catalog descriptor -y -t my-service | yq -e '.info.x-cortex-owners += { "name": "my-org/my-team", "type": "GROUP", "provider": "GITHUB" }' | cortex catalog create -f-

Modify all github basepath values for domain entitities, changing ‘-’ to ‘_’

for domain in `cortex catalog list -t domain | jq -r ".entities[].tag"`; do
   cortex catalog descriptor -y -t ${domain} | yq ".info.x-cortex-git.github.basepath |= sub(\"-\", \"_\")" | cortex catalog create -f-
done

Modify deploys based on selection criteria

This example fixes a typo in the deployment environment field, changing PYPI.org to PyPI.org.

It loops over each selected array element based on the search criteria, removes the uuid attribute (because that is not included in the payload), assigns the environment attribute to the correct value and invokes the CLI with that input.

cortex deploys list -t cli > /tmp/deploys.json
for uuid in `cat /tmp/deploys.json | jq -r '.deployments[] | select(.environment=="PYPI.org") | .uuid'`
do
   cat /tmp/deploys.json | jq ".deployments[] | select (.uuid==\"${uuid}\") | del(.uuid) | .environment = \"PyPI.org\"" | cortex deploys update-by-uuid -t cli -u ${uuid} -f-
done

---