I'm looking for someone who was able to follows the documentation of Microsoft (https://learn.microsoft.com/en-us/azure/iot-edge/tutorial-deploy-function) and Jon Gallant (https://blog.jongallant.com/2017/11/azure-iot-edge-raspberrypi/) with success.
After following the whole documentation to get a working Azure Function on a Raspberry PI hosted in a docker container, the Function does not work and the edgeAgent log contains just an info that the Functions can't start. To find out what is happen, I setup the debug environment like described here: https://learn.microsoft.com/en-us/azure/iot-edge/how-to-vscode-debug-azure-function but nothing works. After hit the last F5 (as its described) I get the error, that the docker container does not exists.
Yes, Dariusz is right.
So, I went to check the status of Azure Functions Runtime and the good news is that they have now a version of their runtime for ARM. https://hub.docker.com/r/microsoft/azure-functions-runtime/tags/ for ARM.
So, we just need to update our Binding and start publishing our image for Arm.
I opened this GitHub Issue to rack the status:
https://github.com/Azure/iot-edge/issues/485
UPDATE: We have release 1.0.0-preview022 that has ARM version for Function that works for raspberry pi! Let us know if you found any problem. We should be updating our VS Code Template soon.
As of today there is no Azure Functions image for ARM released. If you look at the docker hub url https://hub.docker.com/r/microsoft/azureiotedge-functions-binding/tags/ there are just Windows Nano container and Linux x64 container available.
Related
I'm building a module with nodejs to run inside Azure IoT Edge V2. For this I have set up the runtime on a Raspberry Pi running in my local network.
I'm following this official guide and was able to reproduce all previous steps until Debug a module with the IoT Edge runtime.
I get a success response after both the Azure IoT Edge: Build and Push IoT Edge solution& Create Deployment for Single Device steps. In the Visual Studio Code device explorer I can also see that both my new module and the SampleTemperatureSensor have been created, however only the latter one is showing as running. I also don't receive any messages in the IoT Hub like it did with local debugging.
When I SSH into my Raspberry Pi I can also not see my new module running as a Docker container.
Looking at the deployment.debug.arm32v7.json I wonder if the docker container cannot be deployed from my local repository localhost:5000? Do I perhaps need to deploy the container through ACR for remote debugging?
If you have specified localhost as the repository then Docker is going to be looking for that repository on the Raspberry Pi. I'm guessing that's not where it is. You would need to create the repository on your Pi and push your module image to it then it should work. If the repository is already on your Pi then something else must be awry.
I have been working on a project built from the SAFE stack template and everything runs successfully when I build it to a docker container and run this locally.
Using Azure WebApp for Container, the container successfully attaches and deploys, and I am able to load the app from the URL as expected. [The Server is responding with the Client App]
The issue is that the WebSockets are not working once deployed, but they work properly from when I run the container locally.
I've looked through a lot in regards to all of this and tried a lot of different things, but am having no success. I could share more, but I was primarily seeing if anyone has encountered this.
I did run this:
az webapp config set --web-sockets-enabled true --name MyAppName --resource-group MyResourceGroup
as per something suggested from here: https://social.msdn.microsoft.com/Forums/azure/en-US/036f9c3d-16dc-4e52-b943-5eb1afed824f/enabling-websockets-on-a-web-app-for-containers-service
I can confirm that the WebSockets being enabled was set to false, by default, and that it required using the CloudShell to set it to true.
It is frustrating, because I am unable to get any information beyon the following:
WebSocket connection to 'wss://xxx.azurewebsites.net/socket/init' failed: Error during WebSocket handshake: Unexpected response code: 503
I don't want to initially overshare detail about code, unless requested as something helpful, because everything works when run in a container locally. It does feel oddly like something related to that Azure setting or perhaps some kind of Port-related Application Setting or the such.
Further, this does feel like it is not an aspect of SAFE-template or Elmish-Bridge, but anyone who has successfully deployed this combo on Azure using a Docker Container may have direct insight on this problem. It seems like something wider than this particular usage, but related to Container/Websocket usage on Azure.
Any help is appreciated. Thanks.
It seems that WebSockets are not fully supported in Azure WebApp for Containers that are running Linux Containers:
https://github.com/aspnet/AspNetCore/issues/10370
Can you check what appservice plan you have?
TLDR: you need to get at least a B1 appservice plan. The FREE one will not work with Streamlit (and apps using WebSockets).
After a couple of hours trying to find the answer to the same answer, I found out what it was. I wanted to deploy a streamlit app, but was stuck at the same place after following the guidance. A Ctrl+Maj+J showed in the "Please wait" page that WebSockets were an issue. It appears WebSockets will not work for FREE Linux appservice plans, and after recreating a B1 appservice plan (as in the guidance), it worked.
Might be a duplicate of this issue.
I'm creating a custom vhd image to make it available in azure market place. Its an inbuild centos 7 machine and I want to load it as an image. Is it mandatory to have WALinuxAgent agent to be installed as part of the image? Here is the documentation which says to install it https://learn.microsoft.com/en-us/azure/virtual-machines/linux/create-upload-centos#centos-70. I want to exclude that package from the image. Is that okay to do that ?
You do need it, otherwise the VM may not boot. This agent communicates with the Azure fabric to provide VM status amongst other things. You can find more information about it here: https://github.com/Azure/WALinuxAgent
I'm running an Azure function in Azure, the function gets triggered by a file being uploaded to blob storage container. The function detects the new blob (file) but then outputs the following message - Did not find any initialized language workers.
Setup:
Azure function using Python 3.6.8
Running on linux machine
Built and deployed using azure devops (for ci/cd capability)
Blob Trigger Function
I have run the code locally using the same blob storage container, the same configuration values and the local instance of the azure function works as expected.
The functions core purpose is to read in the .xml file uploaded into blob storage container and parse and transform the data in the xml to be stored as Json in cosmos db.
I expect the process to complete like on my local instance with my documents in cosmos db, but it looks like the function doesn't actually get to process anything due to the following error:
Did not find any initialized language workers
Troy Witthoeft's answer was almost certainly the right one at the time the question was asked, but this error message is very general. I've had this error recently on runtime 3.0.14287.0. I saw the error on many attempted invocations over about 1 hour, but before and after that everything worked fine with no intervention.
I worked with an Azure support engineer who gave some pointers that could be generally useful:
Python versions: if you have function runtime version ~3 set under the Configuration blade, then the platform may choose any of python versions 3.6, 3.7, or 3.8 to run your code. So you should test your code against all three of these versions. Or, as per that link's suggestion, create the function app using the --runtime-version switch to specify a specific python version.
Consumption plans: this error may be related to a consumption-priced app having idled off and taking a little longer to warm back up again. This depends, of course, on the usage pattern of the app. (I infer (but the Engineer didn't say this) that perhaps if the Azure datacenter my app is in happens to be quite busy when my app wants to restart, it might just have to wait for some resources to become available.). You could address this either by paying for an always-on function app, or by rigging some kind of heartbeat process to stop the app idling for too long. (Easiest with a HTTP trigger: probably just ping it?)
The Engineer was able to see a lower-level error message generated by the Azure platform, that wasn't available to me in Application Insights: ARM authentication token validation failed. This was raised in Microsoft.Azure.WebJobs.Script.WebHost.Security.Authentication.ArmAuthenticationHandler.HandleAuthenticate() at /src/azure-functions-host/src/WebJobs.Script.WebHost/Security/Authentication/Arm/ArmAuthenticationHandler.cs. There was a long stack trace with innermost exception being: System.Security.Cryptography.CryptographicException : Padding is invalid and cannot be removed.. Neither of us were able to make complete sense of this and I'm not clear whether the responsibility for this error lies within the HandleAuthenticate() call, or outside (invalid input token from... where?).
The last of these points may be some obscure bug within the Azure Functions Host codebase, or some other platform problem, or totally misleading and unrelated.
Same error but different technology, environment, and root cause.
Technology Net 5, target system windows. In my case, I was using dependency injection to add a few services, I was getting one parameter from the environment variables inside the .ConfigureServices() section, but when I deployed I forget to add the variable to the application settings in azure, because of that I was getting this weird error.
This is due to SDK version, I would suggest to deploy fresh function App in Azure and deploy your code there. 2 things to check :
Make sure your local function app SDK version matches with Azure function app.
Check python version both side.
This error is most likely github issue #4384. This bug was identified, and a fix was released mid-june 2020. Apps running on version 3.0.14063 or greater should be fine. List of versions is here.
You can use azure application insights to check your version. KUSTO Query the logs. The exception table, azure SDK column has your version.
If you are on the dedicated App Service plan, you may be able to "pull" the latest version from Microsoft by deleting and redeploying your app. If you are on consumption plan, then you may need to wait for this bugfix to rollout to all servers.
Took me a while to find the cause as well, but it was related to me installing a version of protobuf explicitly which conflicted with what was used by Azure Functions. Fair, there was a warning about that in the docs. How I found it: went to <your app name>.scm.azurewebsites.net/api/logstream and looked for any errors I could find.
I am trying to attach a cloud drive as described here http://msdn.microsoft.com/en-us/library/gg466226.aspx#bk_Storage but I get the error ERROR_AZURE_DRIVE_DEV_PATH_NOT_SET ?
What does this mean? I've tripled checked my config at it seems ok.
I am trying to connect the cloud drive in a Windows Service on a VM Role.
I discovered that the FixMSI.js script from http://msdn.microsoft.com/en-us/library/gg466226.aspx#bk_Install was failing. For some reason $(BuiltOutputPath) was empty. I did it relative to the $(ProjectDir) instead.
It then failed with a different error (and much earlier). CloudDriveException 0x80070103.
Searching for this gave me this article which basically told me to manually edit the driver inf file for the wa miniport. http://msdn.microsoft.com/en-us/library/windowsazure/hh708321.aspx.
Now it attaches ok. The strange thing now is that the device has a warning when the vm starts (but only when hosted in azure), I have to manually go into the vm on azure and update the driver.
try to change BuiltOutputPath to BuildOutputPath. According to Richard, this is an error in the document. Refer to the Community Content section on the document for more information.