#PYTHON SLACK CLIENT CODE#
The next portion of the code is used to handle how the bot interacts with messages seen or what is executed when a certain message is seen. When this function is executed, it will instantiate an instance of NetBot, send a generic message, and upload the file created from the get_file_payload method. We are creating a function called get_network_info that takes in two parameters. get_message_payload()įile_output = net_bot. Run the get_message_payload and get_file_upload method I will break down one portion to keeps things short and sweet, but most all of them follow the same workflow.ĭef get_network_info(channel, device_name): The next portions actually perform the execution of all of our code. The BOT_ID constant is used in code later on to make sure the bot does not respond to itself. We utilize two environment variables for authentication. The imports mentioned above will import the required Flask, Slack, and NetBot packages. We will be utilizing Flask to do most of the heavy lifting. # Define bot ID so it will not respond to itselfīOT_ID = slack_web_client. get( "SLACK_EVENTS_TOKEN"), "/slack/events", app Slack_events_adapter = SlackEventAdapter( # Create an events adapter and register it to an endpoint in the slack app for event ingestion. # Initialize a Flask app to host the events adapter In our case we are using a very simple YAML file with the two hosts mentioned earlier.įrom slackeventsapi import SlackEventAdapter This would then have management IP, platform, and whatever else would be needed to connect using NAPALM. Think Netbox API call to get device information for a device named XYZ. In a grander scale, you would most likely have some dynamic inventory that is cached to the app running or the code actually interacts with your inventory source to pull the correct information. Quick deviation, I almost forgot to mention the inventory. The first is pretty standard syntax to connect to device, run the get_interfaces function, and return as pretty JSON. Below you will see the two methods used to put this all together. One being a Cisco IOL router and the other an Aruba CX switch. For our networking example, we will use NAPALM to retrieve the network interfaces from two devices. As long as the end result returns data in a format we can use to craft a Slack message. In theory you can use whatever you are comfortable with Netmiko, NAPALM, Nornir, or Ansible. The following is added under our NetBot class from above. We are basically reading the readme file in our root directory and then returning all the data required to compose a message in slack.
#PYTHON SLACK CLIENT HOW TO#
One of the first things that came to mind when building the bot is how will users know how to run the bot? I created the following method to solve that little problem. The NET_BLOCK class attribute is just there so the bot can respond with some generic message to the user. In reality this would be an environment variable or pulled from a secure source. I kept it simple and created some credentials for authentication as class attributes. Essentially things in the program that wont change. The variables you see in all caps are called class attributes/constants.
"Getting interface information for device :slightly_smiling_face:"ĭef _init_(self, channel, device_name):Ī few things to note. In this case we will call it NetBot, but you can name your bot whatever you like. It only made sense to me to create a separate class to define our network engineering bot. The initial code from Masons example has you create a class called CoinBot. I’ll try not to repeat information that was already shared in Masons post.
Lets walk through some code and I hope to answer how those goals were met. Ability to call different (non static) devices.Network Engineering Botīelow are a few of the goals I had when creating this bot. I hope you enjoy and maybe get inspired to build something you can use to assist you in your daily workflow. What I will demonstrate in this post is what made sense to me at this point in time. I’m a fairly novice python user, expect to see areas where code can be refactored and even total rewrites that would make the organization better. Think of that post as a prerequisite to get you started before following along with this one. After coming across a fantastic post by Mason Egger at Digital Ocean (linked at the end), I figured now is as good a time as any. I’ve wanted to mess with getting a bot running on Slack for a while now. Hello and thank you for joining me in another blog post.
0 kommentar(er)
