Settings
In your playbook, you can set specific settings to define its execution requirements. These settings allow you to:
Specify CPU and memory requirements.
Set execution rate or schedule.
Define a general timeout and concurrency.
Manage output handling.
These settings help customize the playbook performance to your project’s needs, making testing processes more efficient and scalable.
Name, Description and Mitigation Settings
In your playbook, you can define a name, description, and mitigation strategy to enhance playbook identification. Here’s how each component contributes to a clear and actionable setup:
- Name: assign a descriptive name to identify the playbook quickly.
- Description: provide details about the playbook's purpose, such as supported languages and tool functionalities.
- Mitigation: specify a remediation step if the playbook fails, it provides clear guidance for necessary actions upon failure.
settings:
name: Find Secrets using Semgrep
description: A free open-source static code analysis tool with stable support for C#, Go, Java, JavaScript, JSON, Python, PHP, Ruby, and Scala. It has experimental support for nineteen other languages, as well as a language agnostic mode.
mitigation: Remove secrets from your code if the playbook fails
install:
assertReturnCode: 0
semgrep:
- [ python3 -m pip install semgrep ]
semgrep:
assertStdout: False
secrets:
- [ semgrep --config "p/secrets" -q ]
Associating this metadata with each playbook run provides valuable context and supports informed follow-up actions, especially if mitigation measures are necessary.
Configuring CPU and Memory for Playbooks
Define the required CPU and memory for each playbook to ensure optimal performance. Use the settings
to specify these parameters:
settings:
cpu: 16384
memory: 122880
These are the possible combinations of CPU and memory configurations and the compatible operating systems. Select the values that best suit your playbook's requirements.
CPU value | Memory value | Operating systems supported |
---|---|---|
256 (.25 vCPU) | 512 1024 2048 | Linux |
512 (.5 vCPU) | 1024 2048 3072 4096 | Linux |
1024 (1 vCPU) | 2048 3072 4096 5120 6144 7168 8192 | Linux, Windows |
2048 (2 vCPU) | 4096 5120 6144 7168 8192 9216 10240 11264 12288 13312 14336 15360 16384 | Linux, Windows |
4096 (4 vCPU) | 8192 9216 10240 11264 12288 13312 14336 15360 16384 17408 18432 19456 20480 21504 22528 23552 24576 25600 26624 27648 28672 29696 30720 | Linux, Windows |
8192 (8 vCPU) | 16384 20480 24576 28672 32768 36864 40960 45056 49152 53248 57344 61440 | Linux |
16384 (16vCPU) | 32768 40960 49152 57344 65536 73728 81920 90112 98304 106496 114688 122880 | Linux |
Scheduling Playbooks with Cron and Rate settings
To schedule playbook execution based on specific times or intervals, configure Cron or Rate settings. Each offers a different approach to scheduling:
- Cron Settings: use cron settings to schedule playbooks at precise times or recurring intervals, such as daily or weekly runs. For more detailed instructions, refer to the Cron Scheduling section in the Monitor documentation.
- Rate Settings: configure rate settings for simple, fixed-interval scheduling, such as every 5 minutes or hourly. See the rate setting section in the Monitor documentation for guidance.
These settings help automate playbook runs, ensuring timely and consistent execution based on your testing needs.
Notification settings for execution results
You can customize how you receive notifications based on the execution results of your playbook. Choose from three notification settings:
- log: receive notifications for every execution, regardless of the outcome.
- logOnFail: get notified only when the result is a failure.
- logOnPass: receive notifications only when the result is a success.
Notifications can be sent through various channels. Use the following formats to define your notification preferences:
- slack followed by the alias you defined for the Slack channel.
- email followed by the email you defined for email notifications.
- telegram followed by the alias you defined for the Telegram channel.
- discord followed by the alias you defined for the Discord channel.
You can define these aliases in your Settings when adding a notification.
You can specify different log types simultaneously to notify users through multiple channels:
settings:
logOnFail: slack, email, telegram, discord
Timeout Settings
Set a maximum runtime for playbook executions to control resource usage. Specify the timeout duration in seconds:
settings:
timeout: 60 # the default value is 3600 seconds
If the playbook reaches the defined timeout without completing, the instance will automatically shut down, terminating any ongoing processes. This setting helps prevent excessive resource use and ensures timely task completion.
Count Settings
The count
parameter allows you to launch multiple instances of the same playbook concurrently through the Satori Cloud infrastructure. Each instance runs independently and generates its own report, which is especially useful for tests requiring high concurrency, such as load or DDoS testing. Here’s an example configuration for a DDoS test playbook:
settings:
name: "Siege - Load testing web servers"
description: "Knowing how much traffic your web server can handle when under stress is essential for planning
future grow of your website or application. By using tool called siege, you can run a load test
on your server and see how your system performs under different circumstances."
mitigation: "Use an anti DDoS service such as CloudFlare to prevent network attacks"
count: 100 # maximum amount of concurrent instances for a playbook
install:
assertReturnCode: 0
siege:
- [ apt install -y siege ]
host:
assertReturnCode: 0
before_siege:
- [ curl -s ${(URL}} -m 3 ]
siege:
- [ siege -c 100 -t 30s $(URL) ]
results:
- [ "set +f; cat siege.*" ]
after_siege:
- [ curl -s ${{URL}} -m 3 ]
Report Settings
Control whether and how reports are saved after playbook execution. You can prevent data storage on Satori servers or specify a format to receive a downloadable copy.
- Disable report storage: set report
to false
to avoid storing any report data on Satori servers, while still receiving an execution summary upon completion.
- Receive a report copy in PDF: set report
to pdf
to receive a PDF copy of the report.
If no report format is specified, you can still access the report online using the CLI or Web interface.
Example Configurations
PDF report: sends a downloadable PDF version of your report.
yamlsettings: report: pdf
No report storage: ensures no report data is saved on Satori servers after execution. You will still get the overall status of your report and test after completion but the outputs will not be stored.
yamlsettings: report: False
If you need any help, please reach out to us on Discord or via Email