Re: Communication between CLI and Docker container in the new architecture.

+1 Em sex., 17 de abr. de 2020 às 11:15, Bruno Sette escreveu: > Standardizing with gRPC seems better to me. It is a good agnostic and safe > language solution. > > Em sex., 17 de abr. de 2020 às 14:56, Lucas Cardoso Silva < > cardosolucas61@gmail.com> escreveu: > > > Standardize with gRPC s

Re: Communication between CLI and Docker container in the new architecture.

Standardizing with gRPC seems better to me. It is a good agnostic and safe language solution. Em sex., 17 de abr. de 2020 às 14:56, Lucas Cardoso Silva < cardosolucas61@gmail.com> escreveu: > Standardize with gRPC seems like a better idea. It has all the security > features we need and mainta

Re: Communication between CLI and Docker container in the new architecture.

Standardize with gRPC seems like a better idea. It has all the security features we need and maintains the code's agnosticism. What do the rest of you guys think? Lucas Cardoso Em sex., 3 de abr. de 2020 às 14:45, Daniel Lucredio < daniel.lucre...@ufscar.br> escreveu: > If we are going for a ser

Re: Communication between CLI and Docker container in the new architecture.

If we are going for a server to maintain the daemon, instead of a simple process just to keep the container alive, why not go for a gRPC solution? In this way, both the engine's endpoints and the toolbox commands would be accessible in the same way. And it would also support other languages for the

Re: Communication between CLI and Docker container in the new architecture.

What do you think about using the Pyro4 library to maintain the daemon? The license is compatible and it deals with security issues. We can use the docker API to provision containers and interact at a high level while remote method calls are made through Pyro lib. Pyro4 github: https://github.com/

Re: Communication between CLI and Docker container in the new architecture.

Great! I will do some tests with the "daemon" approach and report any updates. Thanks! Em ter., 17 de mar. de 2020 às 17:40, Daniel Takabayashi < daniel.takabaya...@gmail.com> escreveu: > No, I think everything is here. The "daemon" idea is the best way to handle > this problem, basically, we nee

Re: Communication between CLI and Docker container in the new architecture.

No, I think everything is here. The "daemon" idea is the best way to handle this problem, basically, we need to have a Marvin agent running inside the container responsible to receive and run the commands from outside. But I didn't get the part related to Jupyter. Em sex., 13 de mar. de 2020 às 1

Re: Communication between CLI and Docker container in the new architecture.

I did some testing with the Docker API. The only problem is that a container needs a process running to stay active, if it does not exist the instance stop before receiving the command through the API. There is the possibility to maintain an infinite and inexpensive process like: tail -f / dev / nu

Re: Communication between CLI and Docker container in the new architecture.

Take a look at the Docker API https://docs.docker.com/engine/api/v1.24/, I believe this will simplify the solution. Cause if you add another layer (Flask application) you going to need to control/manage this layer as well, creating a chicken and egg problem. I believe the Docker API is a simple so

Re: Communication between CLI and Docker container in the new architecture.

I thought about using a flask application, which can become very fast and scalable with a Python WSGI server for production like Gunicorn. We can make the communication establish by HTTPS protocol and use a public and private key generation system for each engine generated. Another, althougt comple

Re: Communication between CLI and Docker container in the new architecture.

@Daniel The biggest challenge is to run commands in a remote container without having access to the whole O.S. Basically the idea is to create an interface to make possible, in a secure way the communication between Toolbox and remote engines. Creating this we could start to run our engines in clo

Re: Communication between CLI and Docker container in the new architecture.

Hi Lucas and everyone, Couldn't the developer just run the CLI from inside the container, opening a shell inside it? []s Daniel Em qui., 5 de mar. de 2020 às 13:31, Lucas Cardoso Silva < cardosolucas61@gmail.com> escreveu: > I think we could define better how we will make the communication

Re: Communication between CLI and Docker container in the new architecture.

+1 Em sex., 13 de mar. de 2020 às 11:06, Bruno Sette escreveu: > LGTM > > +1 > > Em qui., 5 de mar. de 2020 às 13:31, Lucas Cardoso Silva < > cardosolucas61@gmail.com> escreveu: > > > I think we could define better how we will make the communication CLI > with > > the Docker development inst

Re: Communication between CLI and Docker container in the new architecture.

LGTM +1 Em qui., 5 de mar. de 2020 às 13:31, Lucas Cardoso Silva < cardosolucas61@gmail.com> escreveu: > I think we could define better how we will make the communication CLI with > the Docker development instance in the new architecture. The container > needs a running process to stay activ

Communication between CLI and Docker container in the new architecture.

I think we could define better how we will make the communication CLI with the Docker development instance in the new architecture. The container needs a running process to stay active. We could make a communication via API endpoints to keep a web service running on the container receiving informat