Add support for Dockerfile and generic container execution

[muka]

trafficstars

I would suggest to introduce a raw Dockerfile support that just build a dir to a container.

This may then been invoked directly via a proxy call ex. fx call my_container

At call time, arguments are injected in the container stdin, returning stdout

I am working at a PoC for validation (WIP https://github.com/muka/fx/tree/anyfx)

[metrue]

@muka

Yes, this is a very good idea. let's clarify a little bit.

1. when Dockerfile given.

fx call Dockerfile

fx will build it then run it directly ?

2. when a Container given

fx call Container

basically it's same as #1.

I am sure how can we make it as a service all the time since we can not grantee the Docker/Container is a valid long-live server to run, if it's not, what's the difference with docker run

Maybe I am not totally get your idea here, would you give a example?

[muka]

Yes, I was thinking to something like that

1. fx up ./myfx/Dockerfile would set up the container image
2. fx call <container id or name> arg1 arg2 or fx call one with arg | fx call two

The main difference is that there is no strict requirement to have a server running, the container is created, started and stopped every time a lot like a standard command. In some cases may cost more in term of time and resources but this end up as a choice for the user.

To keep compatibility with the current functions model (with a web service running) I would add an additional label to the container (like fx-type=container or similar).

With that label on fx call we can decide when to use a POST request or spawn the container and collect its output.

~~I was also thinking to add a --name flag to up so that referencing function get easier~~ Let's keep this for later :)

[metrue]

@muka

Sounds great. let me open a issue for this feature.

[metrue]

@muka I opened this issue and assigned to you, but you please don't take it as a push, ): https://github.com/metrue/fx/issues/115

I will take this one first: https://github.com/metrue/fx/issues/114

[muka]

That's great, do you want to consider the work did here https://github.com/muka/fx/tree/anyfx ?

It allow to run a container with argument and collect output and has full test coverage

If you have a chance you can go test -v ./docker-api from there and see what the api looks like in docker-api/exec_test.go

Let me know thanks!

[metrue]

@muka

I think if we make fx up Dockerfile/<Container> also a service, that's would be more cool. I mean, when we run

fx up Dockerfile arg1 arg2    # or
fx up Container arg1 arg2

fx would build then run container to compute with arg1 and arg2, and return the result to stdout. at the same time, fx should return the service URL also.

http://0.0.0.0:1234  

which will talk arg1 and arg2 as POST data. then we call that service anytime without fx up again. just call the service like

curl -X POST http://0.0.0.0:1234 -H "Content-Type: application/json" -d '{"arg1": 1, "arg2": 1}'

[muka]

Yes this is also an option, I thought to split call and up to better differentiate concern.

Up as it is now setup one or more functions and call make it run.

Also the code readability/testability would get advantaged

Instead presetting the argument sounds a bit hacky to me as the function must be redeployed just to change an argument, need to think about it

What is you preference?

• sent from my phone

[metrue]

Yeah, I still hope the usage interface of fx keeps as simple as possible. for now, we have

fx up
fx down
fx list
fx version

I think it's enough to cover almost everything we want right now. fx up now is to setup functions and make them services, but it could also expand to setup a Dockerfile/Container to be a service.

Instead presetting the argument sounds a bit  hacky to me as the function
must be redeployed just to change an argument, need to think about it

Yes, this is a challenge, I will think about it also.

[metrue]

and one for fx up Container, the workflow is like:

1. create Docker image from given Container
2. upload Docker image to fx server
3. fx run Docker image with given args.

is this consistent with the idea in your mind ?

[muka]

Yes, I'd suggest also to stay compatible with the current approach which is ok and does not require refactoring

To recap

1. Up build image (from src file or docker file)
2. Instead of having IP:port we can expose an endpoint in the fx serve like /fx/<name or I'd>

This works for both types and is super easy for the user that just hast to call a single service setting the right function name or Id

Also looking to support a scalable deployment may ease up things a lot

Let me know, thanks

[metrue]

Great, we are on same page then.