search

erinknight242 / hsbot

Headspring's Hipchat Hubot
9 stars 12 forks source link

Support deployment as Azure Web App #78

Closed Malagari closed 7 years ago

Malagari commented 7 years ago

This feature allows hsbot to be run as an Azure Web App instead of a blocking process on a Linux VM. This brings hsbot back to its roots, running similar to a deployment on Heroku.

There are more than a few benefits to switching to this implementation:

  1. Automatic deployment from master to Azure. Whenever a PR is approved, hsbot will automatically update.
  2. Environment variables are stored in Azure, managed via Portal (or CLI), and not in a separate script (e.g. snippet in BitBucket).
  3. Easier management - no more ssh'ing into a VM to run console commands.
  4. Azure alerts and monitoring - to be alerted if hsbot is having issues.
  5. Free - possibly, depending on web app tier.

Azure has a Free and Shared tier for web apps - the main difference being CPU Minutes and custom DNS. We don't really care about the domain name, and I'm not sure we'll run into the CPU Minutes quota. We'll need to add an Azure Function (or Automation script) to ping the web app every 15 minutes so it doesn't timeout automatically (I've done this with a personal blog and it's easy).

After this PR is merged, we'll need to:

  1. Update documentation for managing / controlling / updating hsbot in Confluence.
  2. Enable the hsbot web app.
  3. Set up the deployment pipeline for the Azure web app (app is currently stopped).
  4. Set up an Azure Function for hsbot-keepalive to ping every 15 minutes.
  5. Deprecate the Linux VM.
bptillman commented 7 years ago

So is the Azure Function solely to keep the "website" alive so that hsbot will be running at all times due to being on the free tier? If so, is there a tier that we could have the website running under so that it is always running, negating the need of the Azure Fucntion?

Malagari commented 7 years ago

Correct - if we go the Free route, the Function will simply keep hsbot warmed up.

There are two methodologies for hosting apps in Azure:

  1. Create an App Service Plan per web app. This allows you to scale each web app independently.
  2. Create an App Service Plan for all web apps within a similar context. This would lump all of our 'Production' apps into one App Service Plan, and they would all share the resources for that tier.

As we get more web apps on Azure, we should follow pattern #2. This gives us more bang-for-the-buck when it comes to these razor thin web apps (hsbot). My comments thus far have focused on hsbot in its own App Service Plan on the Free tier.

TL;DR - We should host the hsbot web app within the Production Apps service plan alongside PM, that way it can benefit from the always-on feature.

Malagari commented 7 years ago

A side note - I was able to use an Azure Automation runbook (free) to keep a Free tier web app from timing out. This means the Free tier would actually be free.

bptillman commented 7 years ago

Okay approved and merged. Let's make it happen @Malagari !

Malagari commented 7 years ago

@hulahomer Awesome. I want to make sure that all of the JIRA Auth issues are fixed before switching over, but I'll take care of the rest.