Let's assume that I have a blob storage account and a VM in Azure. VM is closed to the world, has no public endpoint, however it is reachable from the inside of Azure Subscription. I would like to notify application that runs on this VM, that new file has been uploaded to my blob storage. I know that I can pass this kind of events using EventGrid. What I don't know is if it is possible to send this event to an internal endpoint, available only from VNET/Subnet.
No, this is not possible unless you create some proxy.
You might achieve something with Azure Automation + hybrid worker combo. EventGrid can publish to Azure Automation.
Related
I have implemented Azure SFTP Gateway.
I looked everywhere and I couldn't find anything in the documentation.
During the configuration, you set a Storage account where the use can deploy its file. And you can set different blobs for different users if required, but I couldn't find anywhere if its possible or not to have multiple storage accounts.
In sftp gateway webpage, under setting, I have the option to set only one storage account. Is this a limitation of the service?
Do I need a SFTP Gateway VM for each storage account?
Thank you very much for your help and any clarification.
For SFTP Gateway version 2 on Azure, only one Blob Storage Account can be configured per VM. This is because of a product limitation -- the Blob Storage Account connection settings are global to the VM. You can point SFTP users to different containers within the same Blob Storage Account. But if you wanted to point to separate Storage Accounts, that would require a separate VM.
For SFTP Gateway version 3 on Azure, you can configure "Cloud Connections". These let you point SFTP users to different Blob Storage Accounts, so you only need to use one VM.
As abatishchev mentioned, contacting the product owner's support email is a good approach.
I'm trying to figure out if Azure Blob Storage has similar functionality to Amazon S3. An S3 bucket can be configured in a way, that when new object is created, bucket sends message to SQS. I'm wondering if Azure Blob Storage is able to do the same with Azure Service Bus (which is kind of similar to SQS, correct?).
The only resource I've found so far, which mentions something similar is https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-event-overview, but there is no Azure Service Bus on the right side. I know I can use Functions as a proxy, but I'm interested in direct connection.
Any ideas?
Service bus(I think you compare service bus with SQS and SNS in AWS) don't have the ability to subscripe to Blob storage events. Event Grid(the link that you reffered to has Service bus support on the roadmap but no date is confirmed.
I think your best choice is Azure Functions(or Logic app if you don't want to write code) that has a blob Storage trigger to catch events and do action X.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-create-storage-blob-triggered-function.
Or wait a litte for event grid but you still get that "proxy" part.
One option is to use logic apps/ event grid and you can add trigger directly from azure blob storage (https://azure.microsoft.com/it-it/blog/azure-service-bus-now-integrates-with-azure-event-grid/) . Another option would be to add blob trigger with azure functions and write the code to do whatever action which you are looking for .
I have a use case where I'd like to launch a job on an Azure Container Service cluster to process a file being uploaded to Blob storage. I know that I can trigger an Azure Functions instance from the upload, but I haven't been able to find examples in the documentation of starting a job within Functions.
This diagram illustrates the AWS equivalent of what I want:
Thanks!
The Azure Event Grid feature is what you need. It is still in preview, but you can subscribe to the Blob Created event. You can set the subscriber endpoint to an Azure Function that puts a message in a queue to trigger your job, or you can expose a service on your cluster that will accept the request and do whatever you need done.
Microsoft provides a guide at https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-event-quickstart?toc=%2fazure%2fevent-grid%2ftoc.json#create-a-message-endpoint
I'm developing a Stateless Service which will be in charge to process the blobs uploaded to a certain azure storage blob container. Is there a way to bind this Stateless Service to the blob the same way it can be done using Azure WebJobs?
As a workaround I was thinking of having a binded WebJob to that Azure Storage Blob Container and calling the Stateless Service everytime new blobs are uploaded.
Any sugestions or examples?
Thanks in advance!
It's possible to use the WebJob SDK in ASF services and use a blob trigger.
You can also use an Azure Function with a blob trigger, that then calls a service hosting a web api.
I deployed WorkerRole to Azure Cloud Service (classic) in new portal. With this, I also created Azure Storage account for queue.
Try to add AutoScale rule, the storage account is not listed. Tried to select Other Resource and put Resource Identifier of storage, there's no Metric name listed.
Is it by design that classic Cloud Service and new Storage account not working together?
Storage account data (e.g. blobs, queues, containers, tables) are accessible simply with account name + key. Any app can work with them.
However, to manage/enumerate available storage accounts, there are Classic-created and ARM-created accounts, each with different API's.
The original Azure Service Management (ASM) API doesn't know anything about ARM resources. There's a fairly good chance that, since you're deploying to a Classic cloud service, it's using ASM only and will not be able to enumerate ARM-created storage accounts.
If you create a Classic storage account (which has zero difference in functionality), you should be able to see it as an option for auto-scale.
I have a bit more details on the differences in this answer.
At this time, it is not possible to autoscale anything based on a new "v2" storage account. It has nothing to do with the fact that you are using the classic Azure Cloud Service. I am having the same issue with using Azure App Services. In the end, I just created a classic storage account to use for the autoscaling. There is no difference in how you interact with the different types of storage accounts.