# Automated netbench

An automated version of netbench that deploys and runs tests on the cloud automatically.

## Why does this exist?
Manual netbench though useful, is complicated to run and deploy to the cloud. Automated netbench simplifies this process for the user, allowing netbench to be more easily used in different scenarios.

## How it works
The first step to using Automated Netbench is building the report generation image using this [Docker file](https://github.com/aws/s2n-quic/blob/main/netbench/netbench-cli/etc/Dockerfile). This can be done with a command such as 

```shell
docker build -t netbench-report-generation -f ./netbench/netbench-cli/etc/Dockerfile .
``` 
within the s2n-quic directory as the build context.

The next step is to build the Client and Server Docker images using this [Docker file](https://github.com/aws/s2n-quic/blob/main/netbench/netbench-driver/etc/Dockerfile). This can be done with a command such as 

```shell
docker build -t netbench-s2n-quic-client -f ./netbench/netbench-cli/etc/Dockerfile --build-arg DRIVER=client --build-arg ENDPOINT=s2n-quic . 
``` 
within the s2n-quic directory as the build context, changing the build args as necessary.

These images must be pushed to an ECR repo for the CDK application to access them, the official guide to do so can be found [here](https://docs.aws.amazon.com/AmazonECR/latest/public/docker-push-ecr-image.html). 

Once the Docker images have been set up, the CDK application can be deployed with a command similar to 

```shell
cdk deploy --all --require-approval never -c instance-type=t4g.xlarge -c server-ecr-uri=public.ecr.aws/d2r9y8c2/s2n-quic-collector-server-scenario:latest
```
The following parameters are configurable by passing in context variables through the -c flag. The default parameters can also be set within the following [file](https://github.com/aws/s2n-quic/blob/main/netbench/cdk/src/main/java/com/aws/NetbenchAutoApp.java), for example, if the same ECR repositories are always used.

1. protocol - The netbench supported transport protocol used in the current run. This is to set the type of traffic for the port mappings on the Docker containers, currently only s2n-quic with UDP is supported.
2. aws-account - The AWS account ID of the AWS account used to deploy the CDK resources, likely to just be the default account used to configure CDK/AWS CLI.
3. client-region - The AWS region to deploy the client instance to, currently must be the same as the server. Default option is the default region configured for CDK.
4. server-region - The AWS region to deploy the client instance to, currently must be the same as the server. Default option is the default region configured for CDK.
5. instance-type - The EC2 instance type for the client and servers to be deployed to. 
6. arm - Determines to use an ARM or x86 Linux AMI. Possible values include "true" or "false".
7. server-ecr-uri - The URI of the server image. This should be passed in the form repo_uri:image tag.
8. client-ecr-uri - The URI of the client image. This should be passed in the form repo_uri:image tag.
9. scenario - The path to the scenario file in the client/server Docker containers. The default does need to be changed unless the way the scenario file is generated by the Docker file changes.

When the CDK application has finished deploying, start the state machine through the AWS Step Functions console. Once finished running, all generated metrics will be found in the metrics S3 bucket. To destroy deployed CDK infrastructure, run 
```shell
cdk destroy
```