Some parts of customers workflows don't fall neatly into services, cron jobs, or triggers. Occasionally, customers need to run one-off tasks (think creating a database in a newly minted RDS instance, running a query against their instance, or just for debugging). This design talks about how we can enable this for customers.

What category is this command?

I believe the tasks domain should be under a new category called Operate. These commands are focused around one-off executions that are a normal part of operations, but may not be part of a customers day to day workflow.

How will it work?

copilot task run 

By default, this will build the local image. Then, if the customer is working within a workspace associated with a project, we can prompt them to choose an environment.

copilot task run 
Which environment would you like to run this task?
> Test
> Prod
> None (runs in your default VPC)

If they select an existing environment, we can set up an ECR repo for on-off tasks real quick (or
bake the one-off repo into our environment template), push the image, and launch the task on Fargate with a sensible default configuration.

If the customer doesn't have any projects set up (or they are not in a workspace) - we can just deploy the task to the Default ECS cluster and the Default VPC. Since this is a lower level command, we can expose flags like subnet or security group.

For this command, you don't have to have set up any ecscli projects.

Optional Flags

--num (the number of tasks to set up)
--cpu (the cpu-units)
--memory (the amount of memory)
--image (an optional image to run, instead of building a dockerfile)
--task-role (optional role for the task to use when running. If running in an environment, the default can be one of our roles like the env task role)
--env, --project (for selecting the environment and project to run this in)
--subnet-id, security-group-id (for choosing a vpc)
--env-vars (key/value list of environment variables)
--command (list of commands which are passed to docker run)

Some examples might be

# Builds, and pushes the local docker file to an ECR repo in environment test. This is run within
# a workspace, so we don't need to provide the --project flag. The VPC will be the env's VPC
copilot task run --env test
✔️ Great, we started your task _i3df4cg43_
$ run copilot task logs --task _i3df4cg43_ to view your task's logs. 

# If not run in a workspace, builds and executes the image in the default VPC/Cluster.
copilot task run

# Runs in the default VPC (if not in a WS). Spins up 4 tasks with 256vcpu, 2GB mem. Runs a 
# particular image (kohidave/ddb-parallel-scan-backup), passes in environment roles, and uses
# a particular role for the task to executed under. 
copilot task run --num 4 
                     --cpu 256 --memory 2048
                     --image kohidave/ddb-parallel-scan-backup 
                     --env-var bucket,davids-ddb-output-s3-bucket 
                     --task-role ddb-backup-role

# Same as above, but overwrites the default commands in the Dockerfile
copilot task run --num 4 
                     --cpu 256 --memory 2048
                     --image kohidave/my-service 
                     --env-var bucket,davids-ddb-output-s3-bucket 
                     --task-role ddb-backup-role
                     --commands rake db migrate

Isn't this like the Fargate CLI?

Yeap! Almost exactly like that. But we can also include integrations into our view of environments so folks can run their tasks in a particular environment (ECS cluster / VPC). This is super useful if you have resources within a particular VPC that can only be accessed from within the VPC.

What next?

We'll have to follow up with visibility features for tasks. Logs, list, PS, etc.

Questions

• Should we do anything to limit folks from running commands in production environments?