A .lando.yml file is at the heart of every Lando app. It is needed to tell Lando what things your app needs for development. It usually will contain the services and tools needed to run and develop your app. This file should live in the root directory of your app's code repository and ideally be tracked in its version control system.

If you make changes to your .lando.yml you will need to lando restart your app for those changes to be applied.

Basic config

The most basic .lando.yml file contains two entries.

# The name of my application
name: trivial

# A list of docker compose files to load relative to my app root directory
  - compose.yml

And can be run easily.

# Navigate to the directory with above .lando.yml
cd /path/to/app

# Start the app
lando start

Images need to be pulled!

The first time you start an app it may need to pull down container images. This can take a moment depending on your internet connection. Subsequent pulls to that container or service are cached so they should be much faster.

You can check out the full code for this example over here. Keep reading to learn about more powerful configuration options for .lando.yml.

The recipe Option

If all you want to do is run a Docker Compose configuration, then the above example is for you. But Lando's real power is in its high-level abstractions with very little configuration.

Recipes offer the highest level of abstraction, composing many lower-level features of Lando into a single, top-level recipe option:

name: envfile
recipe: lemp

This is a working example you can run by following these instructions. It spins up a full LEMP stack out of the box.

The config Option

Recipes are powerful by themselves, but recipe defaults won't always work for your application.

The top-level config option customizes specific aspects of a recipe. For example, the Drupal 8 recipe allows specifying the PHP version, the webserver, and even how to install drush:

# Drupal 8 recipe
name: d8

# Start with the default Drupal 8 recipe
recipe: drupal8

# Configure the Drupal8 recipe

  # See: https://www.drupal.org/docs/7/system-requirements

  # Optionally specify the php version to use.
  # If ommitted this will default to the latest php version supported by Drupal 8.
  # Consult the `php` service to see what versions are available. Note that all
  # such versions may not be supported in Drupal 8s so YMMV.
  # See: https://www.drupal.org/docs/7/system-requirements/php
  # NOTE: that this needs to be wrapped in quotes so that it is a string
  php: '7.1'

  # Optionally specify whether you want to serve drupal via nginx or apache
  # If ommitted this will default to the latest apache
  # See: https://www.drupal.org/docs/7/system-requirements/web-server
  via: nginx

  # Optionally specify the location of the webroot relative to your approot.
  # If ommitted this will be your approot itself.
  webroot: web

  # Optionally specify how you want Lando to handle Drush. There are a few options
  # If omitted this will install the Drush Launcher and assume you've installed a
  # site-local version of Drush with Composer
  # You can also configure it in the following ways:
  # 1. Install via Composer
  # This will install the Drush Launcher (https://github.com/drush-ops/drush-launcher)
  # and will delegate to the site-local version of Drush you've installed with Composer
  # http://docs.drush.org/en/master/install/
  # drush: composer
  # 2. Install Globally
  # This will globally install the corresponding Drush 8 PHAR posted over at
  # https://github.com/drush-ops/drush/releases
  # drush: global:8.1.12
  # This will ATTEMPT to globally install any pre Drush 8 versions via Composer
  # drush: global:~7
  # 3. Specify a path
  # This assumes the user has already installed Drush but wishes to tell Lando where
  # it exists.
  # drush: path:/app/vendor/bin/drush
  # 4. Do nothing
  # This will tell Lando to not do anything, e.g. it's up to the user
  # drush: false
  drush: composer

  # Optionally specify whether you want to disable the global install of drupal console.
  # You should also consider a site-local install of drupal console via composer
  # See: https://hechoendrupal.gitbooks.io/drupal-console/content/en/getting/composer.html
  # drupal: false

  # Optionally specify the database type, this can be one of:
  #   - `mysql`
  #   - `mariadb`
  #   - `postgres`
  # If ommitted this will default to the latest mysql. You can additionally provide
  # a version with `type:version` but you will need to consult the documentation
  # for the correct DB service to see what versions are available
  # see: https://www.drupal.org/docs/7/system-requirements/database-server
  # database: mariadb:10.1

  # Optionally activate xdebug
  # If you are having trouble getting xdebug to work please see:
  # https://docs.devwithlando.io/services/php.html#using-xdebug
  xdebug: true

  # Optionally mix in your own config files
  # If ommitted this will use "sane defaults" for your recipe type
  # conf:

    # For more information on setting these files check out the documentation
    # and examples
    # Docs: https://docs.devwithlando.io/services/php.html
    # Examples: https://github.com/lando/lando/tree/master/examples
    # server: config/drupal8.conf
    # php: config/php.ini

    # For more information on setting these files check out the documentation
    # and examples for the relevant services:
    # MySQL: https://docs.devwithlando.io/services/mysql.html
    # MariaDB: https://docs.devwithlando.io/services/mariadb.html
    # PostGres: https://docs.devwithlando.io/services/postgres.html
    # Examples: https://github.com/lando/lando/tree/master/examples
    # database: config/mysql

The conf option

Within a config block, some recipes allow mounting custom language- or service-specific config files via the conf option:

    php: ./path/to/host/config/dir/php.ini

These can include:

  • .ini files for PHP
  • .conf files for Apache/Nginx
  • config directories for MySQL/MariaDB/PostGres

Examples or recipes that support this include drupal (as illustrated above), wordpress, and backdrop. The conf option is also supported within individual service blocks for services that support it.

Fine-grained Configuration

Recipes are simply common development use-cases, composed of different combinations of services, tooling, proxies, and events. Each of these is a first-class citizens in Lando, with its own top-level configuration options. They can run alongside recipes or raw compose setups to extend functionality.

Configuring services

The services block describes any number of single services, such as php and mysql. It always expects a type to specified. Other supported options within a service block depend on the type.

name: myapp
recipe: lamp

# Let's add a Redis cache service that our PHP service can talk to
    type: redis

Read more about services.

Configuring tooling

The tooling block can define arbitrary lando commands, which map to arbitrary commands that run inside specific service containers. The key for each block becomes the name of the lando sub-command. For example, say you want to expose a CLI into your Redis service above. Just add this:

    service: cache

Lando interprets this as "add a lando redis-cli subcommand that executes redis-cli inside the container running the cache service."

Read more about tooling.

Configuring proxy domains

The proxy block defines custom domains for your services. Lando does this automatically, but by adding a proxy config you can map additional domains on your host machine to arbitrary services. To add a domain for a service called myapp, for example, simply add a myapp block with one or more domain names, defined as a YAML array:

    - custom-name.lndo.site
    - another-name.lndo.site

This comes with several caveats, so be sure to read the Proxy docs to understand the limitations.

Configuring events

Lando apps expose a powerful event-based API. By defining a top-level events block, you can run arbitrary commands before or after any supported event.

The syntax is simple: pre-eventname and post-eventname blocks tell Lando to run extra commands before and after eventname fires, respectively. Individual event blocks are declared as YAML arrays. Within each array, the syntax for a single command tells Lando which to service to run it in. This means that one post- or pre- event block can declare any number of commands to be run in separate services:

    type: node

# Tell lando what to do after we run `lando autotweet`
    - appserver: /path/to/tweeter-scraper.sh --with options
    - echo 'tweeter service is tweeting'

    service: tweeter
    cmd: "node autotweet.js --all-caps"

Lando determines which service to run the command in according to the following rules:

  • If the command is defined in the form SERVICENAME: CMD where SERVICENAME is a service declared in the services block, the command is executed in that service.
  • If the event name is a tooling command, the command is executed in the service declared in the tooling command block.
  • If neither condition is met, Lando runs the command in appserver.

In the above example, lando autotweet covfefe results in the following, in this order:

  • node autotweet.js --all-caps covfefe is run inside the tweeter service (as a normal tooling command)
  • /path/to/tweeter-scraper.sh --with options is run inside appserver (because it was declared with the appserver: ... syntax)
  • echo 'tweeter service is tweeting' is run inside the tweeter container (because autotweet is a tooling command for the tweeter service)

Read more about events

results matching ""

    No results matching ""