Skip to content
This repository has been archived by the owner on Nov 20, 2023. It is now read-only.

First class support for running azure functions for local dev #18

Closed
davidfowl opened this issue Mar 1, 2020 · 4 comments · Fixed by #572
Closed

First class support for running azure functions for local dev #18

davidfowl opened this issue Mar 1, 2020 · 4 comments · Fixed by #572
Assignees
Labels
Milestone

Comments

@davidfowl
Copy link
Member

Microservices may consist of apps and functions (and other executables) see what it takes to launch the functions runtime as part of the microservice topology.

@rynowak rynowak added the idea label Mar 1, 2020
@rynowak rynowak added this to the backlog milestone Mar 3, 2020
@luisgizirian
Copy link

It'd be lovely to have this packed into the tool. The Micronetes time suggestion (davidfowl/Micronetes#8).

@timjroberts
Copy link

This would be awesome. We're currently defining services like this to spin up Functions Apps:

services:
- name: web
  executable: dotnet
  args: C:/Users/timroberts/AppData/Roaming/npm/node_modules/azure-functions-core-tools/bin/func.dll host start --prefix ./bin/Debug/netcoreapp3.1  --port 8080
  workingDirectory: ./src/WebGatewayService
  bindings:
  - port: 8080
    protocol: http

At the moment, it appears that args can't expand environment variables? It would be nice to replace the hard coded path with something that referenced HOME.

@jkotalik jkotalik modified the milestones: backlog, 0.4 Jun 22, 2020
@jkotalik
Copy link
Contributor

Yeah I currently have that effectively working locally right now, however there are a few challenges I'm hitting:

  • Installing func.exe/func.dll. Right now, the func.exe you have is installed via NPM usually and not on the path by default (I tried just calling func.exe on windows and that failed). VS also installs func to a different location as well. I think in tye, we may need to install func locally based on OS and version rather than trying to find one; writing logic to find func.exe never is easy and can cause misconceptions.
  • Deploying. Functions can be deployed to both k8s and azure, and ideally we'd like as much as possible to work there.
  • Service discovery. This one is currently hard, especially for things like queues. Binding information for functions is usually defined in attributes above a function.

At the moment, it appears that args can't expand environment variables? It would be nice to replace the hard coded path with something that referenced HOME.

Yeah this may not work for args, I think it may work for env though. We'll look into it.

@timjroberts
Copy link

This is working great for local @jkotalik
Changed my tye.yaml (from above) to:

services:
- name: web
  azureFunction: src/WebGatewayService/bin/Debug/netcoreapp3.1
  bindings:
  - port: 8080
    protocol: http

and all working!

Any plans to look at the deployment side?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants