Lando provides a way to easily define nice
lando MYCOMMAND commands so that users can take advantage of development tools that are installed inside of containers. Setting up some common routes for things like
npm allows the user to get a "native" experience but perhaps more importantly allows project specific development dependencies to be isolated and run in containers instead of on the user's host machine. You never need to worry about which version of
grunt you need for each project.
You can think of tooling configuration as a nice way to alias a superset of commands that would otherwise need to be run as something like
lando ssh -c "composer install".
Make sure to install your dependencies
# Tooling example name: trivial-tooling # Proxy the basics proxy: nginx: - trivial-tooling.lndo.site # Let up a basic LEMP stack services: appserver: type: php:7.1 via: nginx webroot: www # Run composer install after we start our app build: - "cd $LANDO_MOUNT && composer install" # Add in a helper script to showcase some magic below overrides: services: volumes: - $LANDO_APP_ROOT_BIND/word.sh:/helpers/word.sh cli: type: node:6.10 database: type: mariadb portforward: true # This section defines our tooling routes tooling: # Define `lando composer` as a command that runs `composer --ansi @` against # the appserver service. Note that @ will be any additional arguments you pass # into `lando composer` # # Example: typing `lando composer install` will run `composer --ansi install` # inside the container. composer: # Run the `lando composer` command against the appserver from the services # section above service: appserver # Give a nice description to describe what this does. # If ommited this will default to "Run COMMAND commands" where COMMAND is # composer in this case description: Run composer commands # Define a specific command to start with inside the container. If ommited # this will default to the name you give the service eg composer. # # This can be a string or an array. We recommend using an array if you are # passing in additional options that you might want to enforce. cmd: - composer - --ansi # Define `lando php` as a command that runs `php @` against the appserver where # @ is additional input from the user. php: # Run this command against the appserver service: appserver # Run this command as the www-data inside of the container. If ommitted this # will default to the LANDO_WEBROOT_USER envvar for the service and then root. # if undefiend. You can also pass in user:group. # # Note that the user needs to already exist inside of the container user: www-data # Define `lando mysql` as a command that will drop the user into a mysql shell # inside of the database service mysql: service: database description: Drop into a MySQL shell # Define a tooling command with a stringed command test: service: appserver cmd: composer test description: Run our tests # Define `lando word` that passes through to a script that can handle options. # The script is mounted into our appserver in the service overrides above # # This script doesnt really do anything it's just to demonstrate options declaration # for the lando cli eg if you run `lando word -- --help` you should see some # options. # # Note that you can also specify options for the commands above as well but # generally it makes more sense to just delegate to the options of the command # you are invoking itself # # Note that options get passed into commands no matter what and AS IS. They do # not need to be defined explicitly here. This is purely to provide helpers # when running `lando CMD -- --help` or to get interactive prompts. As an # example try running `lando word -w bird --surprise`. `--surprise` is not defined below but # has a handler in our word.sh. word: service: appserver cmd: /helpers/word.sh options: word: # If you are specifying interactive options, as is the case here, # you will want to set passthrough to true so that interactive answers # get translated into command line args for the script to handle passthrough: true alias: - w describe: Print what the word is interactive: type: input message: What is the word? default: bird weight: 600 # Define `lando npm` so that it also requires the `database` service to be running # in order to work. # # This is useful for complex commands that can act on multiple services eg # a database-import, or drush status check, or pull from a hosting provider # like pantheon npm: service: cli # Add a string or array of services that also need to load up for this # command to function properly needs: - database
You can see the extra commands by running
lando inside your app.
lando Usage: lando <command> [args] [options] [-- global options] Commands: config Display the lando configuration destroy [appname] Destroy app in current directory or [appname] info [appname] Prints info about app in current directory or [appname] init <appname> [method] Initializes a lando app called <appname> with optional [method] list List all lando apps logs [appname] Get logs for in current directory or [appname] poweroff Spin down all lando related containers rebuild [appname] Rebuilds app in current directory or [appname] restart [appname] Restarts app in current directory or [appname] ssh [appname] [service] SSH into [service] in current app directory or [appname] start [appname] Start app in current directory or [appname] stop [appname] Stops app in current directory or [appname] version Display the lando version composer Run composer commands php Run php commands mysql Drop into a MySQL shell Global Options: --help, -h Show help --verbose, -v, -vv, -vvv, -vvvv Change verbosity of output You need at least one command before moving on
You can override tooling provided by Lando by redefining the tooling options in your
.lando.yml file. For example, if you wanted to override the built in
drush command that comes with Drupaly recipes so that it always runs in a specific directory you could do the below.
tooling: drush: cmd: - "drush" - "--root=/app/web"
You can also disable built in tooling by setting the command to a non-object value in your
.lando.yml file. While any value will do it's convention to use
disabled as in the below.
tooling: push: disabled
Lando will try to map your host directory to the analogous directory inside the service. This should MAKE IT SEEM as though you are running the command locally.
If you are not sure about what tools live inside your container, you can use
lando ssh to drop into a shell on a specific service to both investigate and install any needed dependencies.
# SSH into the appserver lando ssh appserver # Explore whether grunt is installed which grunt # not installed # Add grunt npm install -g grunt-cli # Exit the appserver container exit # Add grunt to the tooling in your .lando.yml
While you can do the above, it's generally recommended to install any additional dependencies as part of the build process either using specific dependency management built into the service you are using or with Lando's more generic build step process.