Unable to run HTTP web service as function

[denismakogon]

Unable to run HTTP microservice as function:

Image: denismakogon/aioservice-examples:latest

Dockerfile:

FROM python:3.5

ENV PYTHONUNBUFFERED 1

RUN mkdir /code
WORKDIR /code
ADD requirements.txt /code/
ADD app.py /code/

RUN pip install -r /code/requirements.txt
ENTRYPOINT ["python3", "/code/app.py", "--host", "0.0.0.0", "--port", "11111"]
EXPOSE 11111

Ports are not being exposed from Dockerfile (none of networking options are used to expose ports, so ports mentioned in Dockerfile are remaining private).

Functions latest commit: af149045f1ec515369439e66058768aec9a004ed Go version: 1.7 Docker version: 1.12.3, build 6b644ec

[ucirello]

I believe it is intended that IronFunctions works this way. Containers can either be short-lived, ie they do not sit long enough to be any use as daemons; or they can be long-lived, and in that case, their purpose is to interact with standard I/O to get workload from IronFunctions daemon.

However, you might be uncovering an unforeseen use case. What's the goal here? Why would you need to bind a port? Or, in different terms, why do you need IronFunctions to deploy a container whose role seems to be of a daemon?

[denismakogon]

@ccirello here's the thing. Main reason why AWS lambda gained popularity in enterprise is that AWS lambdas are capable to run microservices without need to manage them through their lifecycle (deploying, scaling, re-configuring). There are tons of articles about turning regular self-hosted API services (daemons, basically) to lambdas, here's one of them.

So, the reason behind running functions as daemons is to enable microservices architecture without need to self-host them on baremetal or VMs. Also consider use ase of horizontal scaling, when your set up API services are facing high load, so you need to scale them in fast to eliminate down time and scale down in matter of seconds (i.e. scale on-demand).

Existing serverless technologies that are running web servers as functions/lambdas:

• http://cloudacademy.com/blog/serverless-framework-aws-lambda-api-gateway-python/
• http://mark.stosberg.com/blog/tech/review-of-nodejs-lambda-serverless/

I do understand that IronFunctions were not designed to run daemons, that it is a good thing to have for platform that names itself as serverless.

[denismakogon]

There are a lot examples of AWS Lambdas and API gateway to run web services, here's an example: https://github.com/Miserlou/Zappa

[ucirello]

@denismakogon I am afraid there is a miscommunication issue here. I am very well versed on the use cases you put forward. Incidentally, none of them provide a way to bind TCP or UDP port to work. So again, why do you need to expose TCP/UDP ports of a container?

[ucirello]

Discussion follow-up https://open-iron.slack.com/archives/functions/p1480014779000961

[treeder]

@denismakogon exposing ports and running your own API inside IronFunctions defeats the whole purpose and as Carlos said, that's not how Lambda works either. Have you even tried IronFunctions? It's got the API gateway built in. The quickstart gets you up and running with an API endpoint as the very first example.