SaltStack Event-Driven Automation for AWS Cloud
We will be at AWS re:Invent next week which is already sold out. If you were one of the lucky tens of thousands to get a ticket early make sure to stop by the SaltStack booth at K19. We’ll have SaltStack swag (stickers, fidget spinners, and more) and would be happy to share a demo of SaltStack event-driven automation for AWS Cloud.
This demo is based on how SaltStack can be used to solve a customer’s problem with partial infrastructure automation that leaves zombie artifacts within third party applications. Here are more details:
The customer’s current process and associated problems:
The customer has thousands of nodes running in an AWS cluster. When load on the cluster reaches a pre-set threshold auto scaling kicks in and a new node is provisioned. This node installs a third-party application which then automatically registers with the third-party application server.
When load on the cluster subsides, AWS Auto Scaling de-provisions the node but the third-party application server is never notified of this event and there is no way to trigger an action to complete the de-registration of the node. This partial automation leaves zombie artifacts and increases the overall license count and costs associated with the third-party application.
In addition, when the auto-scale up event occurs the incumbent configuration management tool often fails to install the third-party application leaving the AWS node running but not utilized. The customer incurs charges for this zombie node and it creates work for the infrastructure team that now is required to spend time and resources to closely monitor the AWS cluster.
SaltStack event-driven automation to the rescue:
With SaltStack event-driven automation for AWS the customer is now able to efficiently manage the entire lifecycle of the cluster node in addition to the third-party application. Here is the new AWS Auto Scaling process flow utilizing SaltStack.
When the auto-scale up event occurs:
- Key exchange occurs between the Salt Minion and Salt Master
- Custom tags are associated with the new AWS node and synched with the Salt Master
- A scheduled task is created in SaltStack and assigned to the new AWS node:
- This task provides enough time for the incumbent configuration management solution to fail or succeed in installing and registering the third-party application
- SaltStack determines the success or failure of the application installation based on the existence of the node on the third-party application server
- If installation failed, de-provision the node and trigger another AWS Auto Scaling event and subsequent workflow actions
- If installation is successful, SaltStack waits and watches for auto-scale down event.
When the auto-scale down event occurs:
- SaltStack captures the AWS node ID from the AWS SQS event
- With the AWS node decommissioned, SaltStack compares the node ID against cached Salt Minion details
- Use the cached Salt Minion details to notify the third-party application and force de-registration of the node
- Validate the action occurred
- Remove the Salt Minion key from the Salt Master.
Get the SaltStack white paper titled, “SaltStack Event-Driven Automation for Any Cloud,” and learn how to use the SaltStack Reactor for event-driven cloud control.
This is just one of many use cases specific to SaltStack event-driven automation for AWS Cloud. For example, a SaltConf17 breakout session (video below) included three lightning case studies from three different customers using SaltStack to manage AWS environments. The three case studies focus on:
- Easy migration of resources from a managed service provider to AWS
- Saving $250,000 in annual hosting costs by using AWS Spot instances and SaltStack event-driven automation
- Enabling the Dev in DevOps with SaltStack, AWS and ChatOps
We hope to see you at AWS re:Invent 2017.