I was recently faced with a scenario where I needed a script to deploy an Azure Function. Specifically, there was a desire to use a REST API to deploy a .zip file of the Function app.
The documentation for “Deploy ZIP file with REST APIs” indicates this is possible via a HTTP POST request to https://{APP-NAME}.scm.azurewebsites.net/api/zipdeploy. One challenge with the current documentation is the stated need to use HTTP BASIC authentication.
I recently started experimenting with the beta versions of the new Azure Storage and Event Hub extensions for Azure Functions. The new extensions use the new Azure SDK, and as a result, include support for using Azure AD to authenticate to specific Azure resources (a.k.a., managed identities). I’m a fan of having fewer secrets to manage. Less secrets . . . more better. 😉
This intent of this blog post is to share my initial experiences with the extensions.
I was recently asked how to change Azure Functions’ system keys, such as the ones automatically created by the Event Grid or Durable Functions extensions.
It’s possible to change these keys via the Azure portal. There is a button in the portal to generate a new key.
What if you want to change the keys programmatically? I couldn’t find official documentation which stated how to do so. After a bit of splunking through GitHub issues (here, here) and reading Mark Heath’s excellent blog post on Azure Function keys, I think I found an approach that, so far, seems to work.
I recently ran into a situation using the Azure Functions default host key where I did not understand the behavior I was observing. Thanks to the help of some fantastic colleagues, we figured out what was going on. I understand what is happening now. I want to share here in hopes that my experience will help others that may run into a similar challenge.
Scenario I needed to create an Azure Function app via an ARM template.
A few months ago one of the greatest scandals to hit Azure Functions erupted . . . ASCIIartgate!
#teamAsciiArt became a trending topic on Twitter. Maybe.
The Big Deal In an effort to reduce the verbosity of logging output by func start in the Azure Functions Core Tools, the decision was made to remove the famed ASCII art. To be fair, running func start did output quite a bit of logs.
Earlier this year I wrote a post showing how to set up private site access for Azure Functions. To briefly recap, private site access refers to setting up a virtual network service endpoint to restrict HTTP-based access to the function to be only traffic from the designated virtual network (i.e. inbound HTTP requests). Attempts to access the public endpoint (e.g., https://contoso.azurewebsites.net) result in an HTTP 403 Forbidden message. Service endpoints are great, but they are not without some drawbacks (use a public IP address, doesn’t work with connections from on-premises resources (i.
As enterprises continue to adopt serverless (and Platform-as-a-Service, or PaaS) solutions, they often need a way to integrate with existing resources on a virtual network. These existing resources could be databases, file storage, message queues or event streams, or REST APIs. In doing so, those interactions need to take place within the virtual network. Until relatively recently, combining serverless/PaaS offerings with traditional network access restrictions was complex, if not nearly impossible.
This post will demonstrate how to create an Azure Function with private site access. Private site access refers to a way for resources within a virtual network to reach out to an Azure Function. Configuring private site access ensures that the specified Azure Function is not able to be triggered via the public internet. Instead, the function can only be accessed via a specific virtual network. The function is private to the specified virtual network.