The Problem
Developers often ask the same questions repeatedly, such as: "How do I run this?", "Can I change the infrastructure?", or "Can I get permissions?". This leads to a reliance on DevOps teams, resulting in many tickets and Slack messages. This overloads DevOps and causes long wait times for developers, hurting overall productivity.
The Solution: A Slack Bot
A Slack bot enables developers to perform actions independently through a familiar interface. With the right integrations, Slack can become a control center for the entire organization.
Infrastructure
The infrastructure created involves:
A Slack app.
Code deployed on AWS.
Developers triggering automated actions through Slack commands.
This infrastructure allows teams to create self-service actions quickly. The bot's source code is based on the Slack Bolt framework, which simplifies Slack app development by providing an easy-to-use interface for handling messages, responses, and interactions.
The resources used include:
API Gateway: Triggers a Lambda function that acts as the bot.
Lambda function: Receives events from Slack and triggers specific actions automatically.
AWS CodeBuild: Executes the actions.
Notifier: A Lambda function that runs an API request and updates users with the process result.
Creating the Slack App
The process starts with creating an application in the Slack API console. Key aspects of setting up the app include:
Permissions: Add permissions to the bot, such as the ability to send chat messages.
Slash Commands: Create slash commands that users can execute from Slack to interact with the bot. For example, the command /Sonora sends a payload to a specific URL. This URL should be the API Gateway URL.
Interactivity: Enable interactivity to send messages, modals, and forms with fields and checkboxes. The bot needs the API Gateway URL to receive interactivity events.
After creating the app, you can deploy the infrastructure using a blueprint. Cloning the blueprint and executing make all builds a CloudFormation stack and deploys it.
Code Structure
The code consists of two main folders:
Bot: Contains the code that receives events and a Notifier for sending messages back to Slack. Actions are created as CodeBuild projects with Terraform.
Runners: The back end of the actions that developers will run.
The actions folder contains Terraform code, including a buildspec.yml file with shell commands and a modal.json file for the front end. The modal.json file contains blocks that can be designed using Slack's Block Kit Builder.
Deployment
After the CloudFormation stack is up and running, Terraform is applied. The API Gateway URL needs to be set in the interactivity and slash command settings. A secret needs to be added to the secret manager, which was created by the CloudFormation template.
Testing the Bot
Once deployed, users can run the slash command (e.g., /Sonora) in any channel to get a menu. After submitting a request, the CodeBuild service runs the commands specified in the buildspec.yml file. The Notifier Lambda function then sends a message back to Slack indicating that the process is complete.
Adding New Actions
To add a new action, copy an existing action folder, modify the buildspec.yml and modal.json files, and redeploy using make all. The block ID should contain the folder name as a prefix. The buildspec.yml file can include commands to create secrets or execute DevOps scripts. You can also build a Docker image with all the necessary repositories and scripts and deploy it as a CodeBuild project.
Considerations
Permissions: Control which actions each role can perform. This can be achieved by creating a service to manage user profiles and permissions, or by using a dedicated portal like Port.
Auditing: Add user IDs, ticket IDs, or request IDs to each execution and attach them to the logs. This data can then be connected to a monitoring tool like Datadog for filtering and analysis. Slack provides a thread ID (thread_ts) that is unique and can be attached to logs.
Security: Implement verification functions to ensure that messages are from the correct workspace and to enforce policies. The blueprint includes a verification function that checks if the user sending the message is from the workspace.
Limitations
This solution may not be ideal for organizations that require a ready-made solution with extensive support. It is well-suited for support tickets and operational tasks but may need to be split into specific topics for larger corporate solutions.
Vision
The future vision includes integrating AI to take the bot to the next level.
Kommentare