Move cli + folder structure to a skeleton repo

[codeliner]

Move cli + folder structure to a skeleton repo

[prolic]

I have an idea, but I am not so sure about it, so please correct me if I am completely wrong on this.

1. micro is only the kernel and has to be composer required by a service.
2. the skeletton is only some empty folder structure, so you can base your project on this.
3. micro-cli, the cli commands should also be updated independently. So this must be a composer requirement of the project root, not an individual service. As everything runs out of the box with docker, the same is not true for micro-cli, it requieres php 7.1 installed on your machine. My idea is that we provide micro-cli as docker image! So you don't need to install php at all, only docker is a requirement. The skeletton could provide a shortcut to install, update and run commands of micro-cli.

Thoughts? @sandrokeil @codeliner

[codeliner]

great idea!

We should move micro-cli to a separate repo and the set up command should create the folder structure so we don't need another skeleton repo with just some folders in it.

Then we can build a docker image for micro-cli so that it can be used like any other docker container.

@sandrokeil Should work, right?

[codeliner]

Dependency to #21

[sandrokeil]

micro-cli as docker image

Sounds pretty good 👍 We should also provide a phar file and I guess as Composer package it is also useful for some people.

[oqq]

And finally we are run docker in a docker container. ✨ 😆

[danizord]

The only drawback I see is that running dockerized commands usually makes the command more verbose (with the need to mount volumes and such). Is there any way around that?

[codeliner]

We'll definitely have a micro-cli (or whatever it will be called) repo, so one can use it as a composer dependency if PHP 7.1 is installed locally. Providing a prooph/micro-cli docker image is a bonus for those of us who don't want to install infrastructure locally.

[prolic]

From the chat:

@prolic:

perhaps the name is not really a good fit. it has nothing really to do with micro. what is does, is create docker-compose.yml config and register services in nginx gateway. so it's more like a docker extension, perhaps the name should reflect that. other's could also add java-, ruby- and more services. i don't know what a really good name is though, perhaps something like docker-microservices-nginx-toolbox

@oqq:

Its more like an environment builder..
The docker-compose.yml builder should also be a separat package.
I dont like this array to yaml shizzle. Some hard models which reflect the docker-compose.yml documantion would be nice. Maybe there is already something open source.

[codeliner]

From a marketing view it is easier to keep the connection between prooph/micro as the framework and prooph/micro-cli as the environment builder. Next step is a prooph/micro-ui that sits on top of both and provides a UI to configure the stuff + dev tools, monitoring, ...

Sure prooph/micro can be used without the cli and micro-cli can also be used for other things, but IMO this can be documented. The preferred way is to use both together.

[codeliner]

@oqq

The docker-compose.yml builder should also be a separat package.

That is indeed a good side project ;)

[sandrokeil]

Some hard models which reflect the docker-compose.yml documantion would be nice.

container-transform could help.

[bweston92]

+1 to rename, tbh I didnt even know what the goal of the project was and was confused.

I thought you was going to be having services that register themselves as if they was infrastructure aware. Rather then just a tool that is going to orchestrate.

[bweston92]

Maybe this could support kubernetes? They support more container runtimes like Rkt

[sandrokeil]

Maybe this could support kubernetes? They support more container runtimes like Rkt

I guess this is hard to achieve, but if we use docker-compose.yml format we can transform it to Kubernetes Pod specs with container-transform.

Maybe it's even better to go with Docker InfraKit.

[bweston92]

Well actually the other way round would be easier? Create a kubernetes deployment and from that you can use kubectl to deploy to a kubernetes env or translate to a Docker-compose? Then we can use all the container runtimes that kubernetes supports.

[codeliner]

As noted elsewhere we should focus on simplicity at the moment. The whole microservice topic isn't easy to understand. I'd like to provide an easy to use toolbox for php microservices that use prooph as a core library for write operations and simple read services. We can rename micro-cli to docker-cli if you think this is less confusion but I'd stick to Docker because it is better known by our users. @bweston92 how would a kubernetes configuration look like and what needs to be Installed on the user's machine to get the services up and running on their local machine?

[bweston92]

Docker-cli would be more understanding name.

Kubernetes is configured using a YAML/JSON file. The benefits of that it would automatically do the load balancing etc. Maybe I can make one in a side project to show you.

Kubernetes can be run "anywhere". Of course can run in Docker containers them selves too. Easiest way I found is "minikube" installer.

[codeliner]

Side project sounds good. Then we can compare both ways.

[prolic]

see https://github.com/prooph/micro-cli

improvements and discussion should be moved there.