search

MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.24k stars 21.41k forks source link

Followed the instructions for Debian - Result is error "bash: func: command not found" #114822

Open ManfredLange opened 1 year ago

ManfredLange commented 1 year ago

I followed the instructions to install Azure Functions Core Tools on Debian. The installation was a root. Then I tried to use the tools with non-root user dev which I have set up.

The result is the following error message:

bash: func: command not found

I then switched to root and the result is the same.

How can I diagnose this?

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ManfredLange commented 1 year ago

It downloads 160 MB archives. Which directory is it installed in? What do I need to add to the path?

Naveenommi-MSFT commented 1 year ago

@ManfredLange Thanks for your feedback! We will investigate and update as appropriate.

ggailey777 commented 1 year ago

Are you installing on Debian 12? Sounds like Debian 12 isn't yet fully supported. https://github.com/Azure/azure-functions-core-tools/issues/3431#issuecomment-1685053359

ManfredLange commented 1 year ago

@ggailey777 @Naveenommi-MSFT Thank you, Glenn! Thank you, Naveen!

I'm using a dev container with the base image mcr.microsoft.com/dotnet/sdk:7.0.401. This is Debian 11 based. The output of lsb_release -a is:

No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye

It turned out that this base image doesn't have gpg installed, which is required during installation of the Azure Functions Core Tools. I trusted a search engine too much (my mistake) and followed a link to what I though were the instructions to install gpg. It installed gnugp which is quite different. Search engines these days are a little too "flexible" ....

Backing up the truck, I then added the following to my Dockerfile for the dev container which then successfully installed the Azure Functions Core Tools:

################################################################################
# Install Azure Functions Core Tools
# based on https://learn.microsoft.com/en-us/azure/azure-functions/create-first-function-cli-csharp?tabs=linux%2Cazure-cli
# Install prerequisites
RUN apt-get install -y \
        gpg
# Install the Microsoft package repository GPG key, to validate package integrity:
RUN curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
RUN mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg
# Set up the APT source list before doing an APT update
RUN sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/debian/$(lsb_release -rs | cut -d'.' -f 1)/prod $(lsb_release -cs) main" > /etc/apt/sources.list.d/dotnetdev.list'
# Update and install:
RUN apt-get update && \
    apt-get install -y \
        azure-functions-core-tools-4

This gave me func in the dev container, just as desired.

The next challenge, however, was to get it set up so that F5 would start debugging the function. This was less obvious to solve. I installed the VS Code extension "ms-azuretools.vscode-azurefunctions" which in turn then offered to generate certain files. Now I can use F5 to run the function under a debugger.

A remaining issue is that the function has a file propoerties/launchSettings.json with a given port number passed as a command line argument. This is code generated by func. Howerver, that port number is not used. Instead it uses port number 7071, which I assume is the default port number. I changed the port mapping accordingly for the dev container.

It'd be much nicer if func would not introduce a new way of working with a C# project. Instead it should provide an appropriate launch configuration that is as close as possible to what you'd do for a standard web application or micro service. It fells a little like one team at Microsoft doesn't care (or know?) what a different team at MIcrosoft is doing. It makes technology less accessible in my opinion.

Anyways, I got it working now, and perhaps the details I shared helps someone else who has similar issues.

I think, since dev containers is a great concept to reduce the "works on my machine" issue and to reduce variability, it'd be great if the documentation would include that setup as well. Based on my experience from the last 5 years, I believe that dev containers should be the norm, not the exception. The approach has too many benefits to miss out on.