lando ssh -s database
You can also set environment variables that will ONLY be available for a given tooling command.
tooling: deploy: service: appserver cmd: deploy.sh env: TARGET: production
One of the great features of Lando is its ability to destroy a single planet... we mean add additional dependencies or build steps to your service without the hassle of having to build or manage your own Dockerfiles.
Note that build steps will ONLY RUN THE FIRST TIME YOU SPIN UP YOUR APP. That means if you change them, you will need to run lando rebuild for them to re-run. An exception to this is if one or more of your build steps error. When this happens Lando will run the build steps until they complete successfully.
When should I use build steps?
If you need additional on-server dependencies like php extensions or node modules, it sounds like a build step may be for you. If you have automation, you want to run EVERY TIME and you may want to consider using events instead.
There are four major build steps.
build runs as "you" and before your service boots up
build_as_root runs as root and before your service boots up
run runs as "you" and after your service boots up
run_as_root runs as root and after your service boots up
An example to consider is shown below:
services: appserver: type: php:7.1 build_as_root: - apt-get update -y && apt-get install -y libmemcached-dev - pecl install memcached - docker-php-ext-enable memcached run: - composer install node: type: node:16 build: - yarn run: - /helpers/some-helper-script.sh run_as_root: - echo "127.0.0.1 mysite.lndo.site" >> /etc/hosts
As you can likely surmise from the above, each step is intended for a pretty specific use case:
build to install application dependencies that are needed before you start your application
build_as_root to install low level server packages required by your application
run to install application dependencies or run build steps that require your application be started first
run_as_root for any other post-start root level one-time setup commands.