Freigeben über

Rapidly Deploy Serverless Azure Functions Using PowerShell

  • Artikel

Editor's note: The following post was written by Cloud and Datacenter Management MVP Doug Finke as part of our Technical Tuesday series. Albert Duan of the MVP Award Blog Technical Committee served as the technical reviewer for this piece.

You finished your PowerShell script, it pulls data from your database, and you want to make it available to your fellow workers. You may have an internal process to deliver the script to your users,  but now there is even better way - an HTTP Azure function. This means that once deployed, you can execute your PowerShell code using a Url and Invoke-RestMethod. And it gets easier. This new PowerShell function lets you quickly point to your Azure subscription and publish your script, making it instantly available.

Invoke-DeployAzureFunction -SiteName MyAzureFunction -SourceFile GetDBData.ps1

That's it! This publishes your PowerShell script to the Cloud as a Serverless Azure function that can be accessed as a REST API endpoint. This also works for C#, JavaScript, F#, TypeScript, Python or any other language Azure Functions supports.

Plus, you can also post your code as a Timer Trigger (fork this on GitHub and you can automate it to deploy with other supported triggers).

This article will speak to why Serverless, why Azure Functions, and then show you how versatile  and flexible the Invoke-DeployAzureFunction can be. The article will also point you to the GitHub repo where the PowerShell code lives, and it’s ready to be forked and updated.

Serverless Azure Functions

Serverless is the next wave of Cloud Architecture, and Azure Functions peel away much of the complication that comes with it to significantly reduces your DevOps activities, and the the time it takes to deliver features to you clients. But remember, it is not a silver bullet.

You can quickly spin up a server in the Azure cloud, take a snippet of code, PowerShell in this example, and make it available as a REST endpoint. Think of all the steps you'd need to do that even on your local machine. Almost all of this is abstracted away for you in the cloud. Here are the benefits:

  • Reduced complexity in provisioning the environment. Plus, your code has to do little work to interact as a REST API.
  • Multiple bindings can be applied to different implementation languages. Your PowerShell, C#, JavaScript can be a HTTP Trigger, Timer Trigger or other. All described in a JSON binding file.
  • Faster time to market - After a little practice, you'll be able to spin up new ideas in minutes, reachable from anywhere, from any language.
  • Fewer lines of code - You'll be pleasantly surprised with the types of features you can create, with PowerShell (and other languages) in a page of code.
  • Mix and match languages in different functions to provide a range of solutions - In a single Azure function app, you can deploy as many functions as you'd like in any of these languages:  Bash, Batch, C#, F#, JavaScript, PHP, PowerShell, Python, or TypeScript.

Plus, the solutions can all be rapidly deployed with this PowerShell module.

The PowerShell Module

The PowerShellAzureFunctions module makes quick work of deploying your Azure Function to an already existing function app. See Create a function app from the Azure portal.

Invoke-DeployAzureFunction takes two parameters, the SourceFile you want to deploy and the SiteName - which is your function app - where you want to deploy to. Invoke-DeployAzureFunction has also built features to your life simpler. For example, it detects if you're already logged into Azure. If you're not, it will prompt you to login. Plus, the SiteName parameter will present you with a list of the function apps you have already provisioned in your Azure subscription. This way you don't have to leave the console to get a list of sites where you can deploy.

There is a third parameter TriggerType. It can be either HttpTrigger or TimerTrigger. Choosing either will deploy a function.json file with the appropriate binding JSON.

Lastly, after the deployment is complete, if you chose HttpTrigger for the TriggerType, Invoke-DeployAzureFunction will output the url of the function you deployed so you can quickly hit that REST endpoint.

Deploy More Than One Function

The next screenshot demos how easy it is to publish one or more functions to your Azure Function App. These functions, which are all on your local drive, can be a mix of programming languages or a group of functions all written in the same language. You can use this to push an idea quickly to the cloud, enabling you to try things quickly and share it instantly with others.

Being able to deliver functionality this quickly to the cloud makes it very cheap to try new ideas, iterate on quickly decide viability. Plus, the PowerShell function quickly publishes your code, which is super easy to use, and far easier than using a browser. After deployment, PowerShell retrieves the URL of your newly published function so you to test it immediately.

The PowerShell Module in Action

Screenshots are worth thousand words, and a 30 second video of this PowerShell module in action deploying Azure functions is even better. Required

In order to get this to work you need the following:

  • Microsoft Azure Cmdlets (Install)
  • An active Microsoft Azure subscription

Lastly, you need the PowerShell module. Grab my PowerShell module so you can rapidly deploy PowerShell scripts as Azure Functions.

Wrap up

This was a quick tour of a PowerShell module that enables you to try your code in the cloud as a Serverless Azure Function. I encourage you to get it and test it out. Not only will you like it, you’ll like what Azure Functions can do for your productivity and feature velocity. With just one to two lines of PowerShell you’ll be deploying solutions, and then emailing the URL endpoint for folks to try it out (or embedding them in Web Apps, Web Hooks, and more).

Check out my other two posts about PowerShell Azure functions, Use Serverless PowerShell to Extend Slack and Use PowerShell in Azure Functions to perform a scheduled clean-up task.

Follow me on Twitter @dfinke. Ask questions, leave suggestions on the GitHub repo, fork it and enhance it.

Looking forward to seeing where this goes.

Doug Finke is an 8 time PowerShell MVP, author of “PowerShell for Developers” from O’Reilly, and organizer of the PowerShell User Group in New York City. He has several open source PowerShell projects up on GitHub and in the PowerShell Gallery. He likes to make humans go faster by automating as much as he possibly can. He is currently working at a stealth eCommerce start-up, using PowerShell to automate all the things. Catch up with Doug at his blog here.

Comments

  • Anonymous
    August 16, 2017
    Great post Doug!
  • Anonymous
    October 24, 2017
    The comment has been removed
  • Anonymous
    October 24, 2017
    I also added "unblock-file" to the script for my environment :Unblock-File "$($ModulePath)$($ModulePath).psm1"
    • Anonymous
      October 24, 2017
      Oops - should be this :Unblock-File "$($ModulePath)$($ModuleName)$($ModuleName).psm1"