[Discuess] CLI Features.

[appleboy]

Implement program language: Golang

Support Platform:

• Windows
• Linux
• Darwin

Reference: https://github.com/logaretm/laradock-cli

• [ ] laradock init Initializes Laradock in existing laravel projects.
• [ ] laradock up Creates/Starts the Laradock containers for the current project.
• [ ] laradock halt Stops the containers running for the current project.
• [ ] laradock destroy Destroys/Removes Laradock from the current project.
• [ ] laradock ssh Helps you ssh into the workspace container to run migrations or seeds.

cc @Mahmoudz @dlnsk @philtrep @laradock/owners @laradock/admins

[dlnsk]

Why did you choose Golang? It just my curiosity. I think Python is more common or am I wrong?

[dlnsk]

About items before: Why needs to change 'down' to 'halt'? 'Destroy' is very dangerous command because many of people change standard configuration, so I offer to exclude it.

I think it could be convenient to use:

1. Auto define used configuration of laradock (single, multiproject). It needs to grep volumes from "application" section.
2. Autocompletion for command and for containers list of 'up' command.

[logaretm]

I also want to suggest adding a command that rebuilds the nginx container to add any new sites that might have been added, maybe call it provision or whatever you guys want to call it, It will be only useful to those with multiple app configurations tho.

[appleboy]

@dlnsk

Why did you choose Golang? It just my curiosity. I think Python is more common or am I wrong?

You don't need to install any package on server or desktop (Windows, Linux or MacOS), just download binary. It is working for everyone. Try the following package:

https://github.com/appleboy/gorush/releases/tag/v1.7.1

Download binary depends on your OS and executes the binary.

[gulien]

Hi guys,

I'm the author of kickoff-docker-php and I've been contacted by @Mahmoudz for sharing my ideas about a CLI tool for Laradock.

In my opinion, each project should have its own "Laradock environment". A project may contain one or more applications (the source code, a server, PHP-FPM and tools - composer, npm..) plus some shared services (DBMS, RabbitMQ and so on).

For example:

ldk init

├── my-project/
│   ├──.ldk/

ldk add app --name="backoffice" --server="nginx" --php-version="7.1" --with-composer --with-npm

├── my-project/
│   ├──.ldk/
│   │   ├── apps/
│   │   │   ├── backoffice/
│   │   │   │   ├── nginx/
│   │   │   │   │   ├── Dockerfile
│   │   │   │   │   ├── some-conf-file
│   │   │   │   ├── php-fpm/
│   │   │   │   │   ├── Dockerfile
│   │   │   │   │   ├── some-conf-file
│   │   │   │   ├── tools/
│   │   │   │   │   ├── Dockerfile
│   │   │   │   │   ├── some-conf-file
│   ├──backoffice/
│   │   │   │   ├── index.php
│   │   │   │   ├── composer.json
│   │   │   │   ├── package.json
│   ├──docker-compose.yml

ldk add mysql --version="5.7"

├── my-project/
│   ├──.ldk/
│   │   ├── apps/
│   │   ├── mysql-pool/
│   │   │   │   ├── mysql57/
│   │   │   │   │   ├── volume/
│   │   │   │   │   ├── some-conf-file
│   ├──backoffice/
│   ├──docker-compose.yml <- has been updated

ldk up

Builds all the containers and starts them :metal:

So the CLI tool will help developers to pick what they need from the rich collection of the Laradock' services :smiley:

[cr101]

@gulien I am currently using WAMP to build & manage WordPress websites which share the same configuration. I'm planning to move to a Docker development environment. What's the advantage of each project having its own LaraDock/Docker environment as opposed to having one Docker environment for all the projects like WAMP?

[Treggats]

@Olivia101 @gulien personally I think that the advantage of having laradock per project is that it's tailored to the projects needs. For example one project needs PHP 5.* and another needs PHP 7 and so on.

Disregarding the version bit, again personally I like a small footprint when it comes to Docker containers. Because these build faster e.g. more time to develop :)

[cr101]

@Treggats "For example one project needs PHP 5.* and another needs PHP 7 and so on." In that situation it would make sense that each project has its own Laradock environment but in my use case all my projects use PHP 7 and same version of everything else.

[Treggats]

@Olivia101 In that case it wouldn't indeed have any additional value to have a per-project-laradock. That would be another scenario that the cli tool needs to take into account.

[dlnsk]

@gulien It seems like play with closed box... we can do something but don't know what is happens inside. OK. I did ldk add app --name="backoffice" --server="nginx" but what if I need additional port? Why needs to add bridge between cli and docker-compose.yml? It would be too difficult to use. Much simpler to change yml directly! Original idea was to make frequent command much simpler. ldk add mysql --version="5.7" is not frequent command!

My opinions are:

• don't make cli-yml bridge
• don't save any configuration outside yml
• don't autoupdate yml
• don't use per project strategy

My suggestions are:

• add ldk init command that just clone latest version of laradock in ./.ldk folder;
• create "ldk runner" script (with self version checking) that installs in system folder and does only one - searches appropriate .ldk folder (from current) and runs ldk-cli inside it with all given parameters;
• "ldk runner" should search .ldk folder at first in current folder, next in previous level folder (in first time we use per project scenario, in second time - multi project);
• add autocompletion for command and for containers list of 'up' command.

[gulien]

@dlnsk My main idea is that each project has its own needs and the CLI tool might help people to setup correctly their projects by picking up what they need.

But maybe it's not the purpose of Laradock, which might be interpreted as "we bring you every services so you don't have to struggle with the technical environment of your projects".

OK. I did ldk add app --name="backoffice" --server="nginx" but what if I need additional port?

You could actually update the docker-compose.yml file directly as the "add" command will not altering pre-existing "block".

Why needs to add bridge between cli and docker-compose.yml?

Helping people to add services "on the fly" without having to worry about "did I miss something?".

Original idea was to make frequent command much simpler.

You're right 😃 ! My previous post was not clear, but I was just highlighting a possibility which I find interesting. Your suggestions are definitely more in the Laradock's philosophy as stated before.

@Mahmoudz @appleboy @philtrep Do you guys have opinions or suggestions to share 😃 ?

[gulien]

Hi guys!

I've been working on the v2 of kickoff-docker-php.

I'm now using Orbit, which allows me to generate templates according to a YAML file, a .env file and the current OS at runtime. Also, it is able to run external commands (like docker-compose up -d).

I think it might be an interesting tool to help Laradock's user to setup a Laradock project easily.

[Nightbr]

Hey, any roadmap for the cli feature? Or any help needed on specific development (Orbit integration, ...) ?

[tonysm]

I've been working on this proof of concept: https://github.com/tonysm/laradock-cli/

Maybe it gives some ideas to the official one, would love some feedback there too.

[Treggats]

@tonysm +1 for the README

[ryh]

https://github.com/laradock/laradock/issues/1394

[ghost]

Personally, I dont like cloning Laradock to several locations on my machine.

My solution to missing CLI support is to have a script called up in my PATH somewhere.

Instead of having a myriad of Laradock instances (which takes up a whole load of Disk and bandwidth) it just boots/reboots the containers and updates the current .env.

I am not proposing this as a change of scope, as my little stupid script has a lot less to offer than what's planned here. But I hope you take my view of the situation into consideration.