We have released the first version of our command line interface (CLI). With the CLI you can connect your repositories to steadybit. In this blog post, we will show you the first implemented features. Be sure - there is much more to come! If you do not have access to our platform yet, feel free to create an account.

Disclaimer

We are currently extending this feature. Some aspects may change and work different than described in this blog. If you need help, you can always check our docs or contact us. We are happy to hear your feedback!

CLI-Installation

Nothing more than a simple

npm install -g steadybit

Authorization

First of all, we need an authorization token. You can grab one from Settings -> API Access Tokens. Make sure to create a token with type "Team".

➜ steadybit config profile add

? Profile name: steadybit

? API access token: [hidden]

? Base URL of the Steadybit server: https://platform.steadybit.io

Describe your Service

Next you need to describe your service and how steadybit can find it. At the moment, only Kubernetes deployments are supported. We are working on other service-types. You can define how steadybit can check the health of your deployment and which Resilience Level you want to achieve. You don't know our Resilience Level feature? You can have a quick look into our documentation. We are heavily working on this feature as well. You will be able to define your service resilience requirements in much more detail in the future.

➜ steadybit service init

? Service name: gateway

? Desired Resilience Level: A - challenges for loose coupling

In order to understand which service you are describing, we need to be able to map it to data collected by the Steadybit agents. Right now, we only support mapping to Kubernetes monitored deployments.

? Kubernetes cluster name: demo-dev

? Kubernetes namespace: steadybit-demo

? Kubernetes deployment: gateway

We need to ensure that the service is still operating as expected when verifying compliance with the desired resilience level. To do so we support various checks. Please define at least one health check that we can use when running resilience checks.

? Health Check Type: HTTP

? URL: http://k8s.demo.steadybit.io/products

...

The CLI created a .yml file containing your service definition in your current working directory. From now on you are able to fine tune your settings either via subsequent CLI calls or by editing the .yml once you understand the format.

id: 9cb2888d-3abf-4ac3-bf8b-40b7eb61d271

name: gateway

desiredResilienceLevel: A

mapping:

kubernetes:

cluster: demo-dev

namespace: steadybit-demo

deployment: gateway

health:

- type: HTTP

url: http://k8s.demo.steadybit.io/products

Sync the service definition with the steadybit platform

You can now upload the service definition by executing

steadybit service apply .steadybit.yml

or even better, you can automatically sync the service definition with every commit using our Github Action

jobs:

apply:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v2

- uses: steadybit/define-service@v1

with:

apiAccessToken: ${{ secrets.STEADYBIT_TOKEN }}

See your Service Definition in Action

You can now use the cli to open steadybit and watch your current state and work on the next steps.

steadybit service open .steadybit.yml

which opens the steadybit platform in your standard web browser. From here, you can inspect the service’s current state, trigger challenges and much more.

As an alternative you can verify your current state directly via the CLI

steadybit service verify .steadybit.yml

which will create the following output

We are working on several new features for our cli. What do you think? We are interested in your ideas!

Curious about steadybit? Just book a personalized demo or try steadybit yourself.