Merge pull request #5 from schubergphilis/update-docs

docs: Add docs to examples, fix README image

README.md

@@ -7,7 +7,7 @@ This composition scheduler can be used to schedule compositions with components
 
 It has the following high level architecture:
 
-![Architecture](docs/architecture.png)
+![Architecture](https://raw.githubusercontent.com/schubergphilis/terraform-aws-mcaf-resource-scheduler/main/docs/architecture.png)
 
 ## Features
 
@@ -41,7 +41,7 @@ When setting up scheduling, the scheduler will check if configured maintenance-
 
 Optionally a pair of webhooks can be deployed to trigger starting or stopping an environments based on external events. This allows for on-demand starting or stopping of environments by - for example - a service management ticket, a Slack integration, a custom frontend, a Github workflow, etc.
 
-Webhooks require an API key and can be setup to only allow certain IP addresses.
+Webhooks require an API key and can be setup to only allow certain IP addresses. A POST request has to be made to one of the outputted endpoints to trigger a webhook.
 
 ## Limitations
 
@@ -170,7 +170,9 @@ This module uses the integrated Lambda to abstract some of the more complex func
 | Name | Description |
 |------|-------------|
 | <a name="output_api_gateway_stage_arn"></a> [api\_gateway\_stage\_arn](#output\_api\_gateway\_stage\_arn) | n/a |
+| <a name="output_start_composition_state_machine_arn"></a> [start\_composition\_state\_machine\_arn](#output\_start\_composition\_state\_machine\_arn) | n/a |
 | <a name="output_start_composition_webhook_url"></a> [start\_composition\_webhook\_url](#output\_start\_composition\_webhook\_url) | n/a |
+| <a name="output_stop_composition_state_machine_arn"></a> [stop\_composition\_state\_machine\_arn](#output\_stop\_composition\_state\_machine\_arn) | n/a |
 | <a name="output_stop_composition_webhook_url"></a> [stop\_composition\_webhook\_url](#output\_stop\_composition\_webhook\_url) | n/a |
 | <a name="output_webhook_api_key"></a> [webhook\_api\_key](#output\_webhook\_api\_key) | n/a |
 <!-- END_TF_DOCS -->

examples/office_hours/README.md

@@ -0,0 +1,13 @@
+# Office Hours
+
+This example starts resources at 09:00 AM on weekdays and shuts them down again at 06:00 PM.
+
+When starting the resources it follows these steps:
+
+1. Giving the RDS instance with id `application-cluster-1` a start command.
+1. Waits 10 minutes for the RDS instance to become available.
+1. Update the ECS service named `application-service-1` on ECS cluster `application-cluster-1` and put the number of desired tasks in the service to 2.
+
+These steps are executed in reverse when stopping the instances.
+
+The RDS instance will also be started 15 minutes before its configured maintenance- and backup window. It will be stopped 15 minutes after its configured maintenance- and backup window. The ECS service is unaffected during these windows.

examples/on_demand/README.md

@@ -0,0 +1,13 @@
+# On-Demand
+
+This example never starts resources on a schedule, but will always attempt to shut them down at 06:00 PM. There are no webhooks configured in this example, meaning the state machine that starts resources will have to be triggered in some other way.
+
+When starting the resources it follows these steps:
+
+1. Giving the RDS instance with id `application-cluster-1` a start command.
+1. Waits 10 minutes for the RDS instance to become available.
+1. Update the ECS service named `application-service-1` on ECS cluster `application-cluster-1` and put the number of desired tasks in the service to 2.
+
+These steps are executed in reverse when stopping the instances.
+
+The RDS instance will also be started 15 minutes before its configured maintenance- and backup window. It will be stopped 15 minutes after its configured maintenance- and backup window. The ECS service is unaffected during these windows.

examples/webhooks/README.md

@@ -0,0 +1,15 @@
+# Webhooks
+
+This example starts resources at 09:00 AM on weekdays and shuts them down again at 06:00 PM.
+
+When starting the resources it follows these steps:
+
+1. Giving the RDS instance with id `application-cluster-1` a start command.
+1. Waits 10 minutes for the RDS instance to become available.
+1. Update the ECS service named `application-service-1` on ECS cluster `application-cluster-1` and put the number of desired tasks in the service to 2.
+
+These steps are executed in reverse when stopping the instances.
+
+The RDS instance will also be started 15 minutes before its configured maintenance- and backup window. It will be stopped 15 minutes after its configured maintenance- and backup window. The ECS service is unaffected during these windows.
+
+Additional to the scheduled start/stop of the mentioned resources, an API Gateway is deployed that provides endpoints for webhooks that can be used for automation from external resources. Think starting/stopping a bunch of resources from a ticketing system or via ChatOps.

outputs.tf

@@ -1,15 +1,23 @@
+output "api_gateway_stage_arn" {
+  value = var.webhooks.deploy ? aws_api_gateway_stage.webhooks[0].arn : null
+}
+
+output "start_composition_state_machine_arn" {
+  value = aws_sfn_state_machine.composition_start.arn
+}
+
 output "start_composition_webhook_url" {
   value = var.webhooks.deploy ? "${aws_api_gateway_stage.webhooks[0].invoke_url}/start" : null
 }
 
+output "stop_composition_state_machine_arn" {
+  value = aws_sfn_state_machine.composition_stop.arn
+}
+
 output "stop_composition_webhook_url" {
   value = var.webhooks.deploy ? "${aws_api_gateway_stage.webhooks[0].invoke_url}/stop" : null
 }
 
 output "webhook_api_key" {
   value = var.webhooks.deploy ? aws_api_gateway_api_key.webhooks[0].value : null
 }
-
-output "api_gateway_stage_arn" {
-  value = var.webhooks.deploy ? aws_api_gateway_stage.webhooks[0].arn : null
-}