There has been increasing talk in the CMS communities around lando as a tool to use with Docker for the ease of local development. I have used it on a few projects now and I really enjoyed the speed and reliability, if you are a fan of Docker Compose this is not for you but if you are a fan of reduced onboard time then lando could be your friend.
How does it help? Basically lando takes control of speaking to Docker Compose and Compose-Utility. So its acting as an abstraction layer to allows for greater ease of use and reduced complexity for developers. This is same as Docker which acts an abstraction layer for Linux containers that allows greater ease of use.
Lando uses the concept of recipes which are preset configurations tailored for a specific service/language/CMS. With the use of recipes developers can easily spin up a standardised environment that includes the needed tools for their work. You can utilise the pre-congiured recipes or create your own for your specific project which can then be shared amongst a team. The CMS recipes work great for learning and teaching and being able to focus on the CMS code without needing to know how to configure Docker.
The documentation for lando I found really good and goes into a nice amount of detail for configuration options. For the fastest way to start with lando I recommend using a recipe. You can always modify your recipe config however it can act as a good starting template for when you want to dive deeper into configuring lando. But for the purpose of getting a dev environment up there is no need to understand how to write configs as most needs can meet by a current recipe, and it really does save alot of time.
It is important to note that lando is a local development tool and has no impact on how you deploy your code from github to production.
To help get you up and running with lando, I have included a tutorial on setting up a development pipeline for WordPress with lando on MacOS.
Tutorial – lando for WordPress development
This tutorial will walk you through setting up lando for your local development environment and connecting to a remote github repository.
There is a lando cask that you can install from Homebrew, this will also check if you have Docker and if not install it for you when it checks for dependencies.
brew cask install lando
For Debian and Fedora there is a package available lando-stable
sudo dpkg -i lando-stable.deb
sudo dnf install lando-stable.rpm
I had Docker installed prior to installing lando and the brew cask threw an error when it saw docker and would stop. This is a known bug and can be resolved by removing docker.app, as the brew script gets stuck and then exits whilst it exists. Once I removed the docker.app from Applications folder it ran fine and installed lando.
Our next steps now are to initialise lando and then pull down the latest wordpress version, then we run the wordpress recipe on the clean wordpress codebase and start lando.
Configuring WordPress recipe
First we need to initialise lando
lando init \
--source remote \
--remote-url https://wordpress.org/latest.tar.gz \
--recipe wordpress \
--webroot wordpress \
The above commands will then kick off the lando recipe and lando will go and fetch what it needs to run WordPress. When it has completed it will inform where the codebase is located.
This will install the default configuration below:
It is important to note that you can easily change the configuration of the WordPress recipe if you need to tune it to your requirements. Some reasons you may want to do this is to change the type DB to mariadb or change the WebServer to nginx.
Now we need to start up lando:
In order to find out our database connection information we can look into the lando configuration file
The top of the info file will display the urls that are active for your WordPress site.
You can also locate your Database connection information by searching for creds:
Another nice thing about using the WordPress recipe is that it installs a set of needed development tools.
lando composer Composer commands
lando db-export [file] Export db from service to file
lando db-import <file> Import dump file to database
lando wp Runs wordpress commands
lando mysql MySQL shell on database service
lando php Runs php commands
lando logs Get log
lando logs -t -f Follow and show timestamps
lando logs -s cache logs for only database services
lando logs -s database logs for only cache services
lando logs -s appserver logs for only appserver services
lando list list all running lando services
lando list --all list all service running or not
lando rebuild rebuilds app retaining data
lando ssh ssh shell
lando php run php commands
lando share shares your local site publicly
lando destroy destroys your app
lando poweroff spins down containers
Importing exisiting lando.yaml
If a project is using lando as part of their developer tools they will have their own configuration. In this case you do not need to use a recipe for lando because you have lando installed as long as the code base you are trying to run has a lando.yaml included running the command lando start will execute the config in this file.
The lando start command will fetch any needed libraries or packages from the internet needed to build the lando app. Once this is complete the command will out the urls that the site can be accessed on.
Importing an existing WordPress site
At this point if we had an existing WordPress site that we wanted to work on all we need to do is could copy the wp-content folder across and import the database using the lando db-import command.
lando db-import db_file.sql
We can also set lando up to build a recipe from a git repo if we have a pre-exisiting project we want to use. First we need to tell lando that the source will be github.
lando init --source github
Configure lando to use your public shh key and github repo and configure it as a WordPress recipe.
lando init \
--source github \
--recipe wordpress \
--github-auth "$MY_GITHUB_TOKEN" \
Because we have built the recipe from github we do not have to configure our remote origin for git as lando has done this for us. So we are ready to create a local branch for our work and then push the branch upstream to github.
And thats it we now have lando up with a clean version of WordPress running and an empty database. The next step from here would be to create a new repo on your github profile. Then set up the codebase as a git repo
Now we need to commit our local WordPress files to git, we only need to add the wp-content directory as this is where all the additional code that we need to share lives. However there could be additional modifications we have made to outside files and non WordPress core folders added that we want to include.
git add wp-content
git commit -m 'initial repo baseline'
There are times we may want to store the whole WordPress codebase in our repo in order for us to ensure version consistency across developer builds. This comes in handy when we have additional code and/or config folders within WordPress. We can also use this codebase to build a custom WordPress recipe for your project. You can add all files to your git repo with . this will add all files into the repo except those mentioned in .gitignore.
git add .
git commit -m 'inital WordPress all-files repo baseline'
Now we need to get the URL of the repository we created on github and add it to our local repo as a remote repository.
git remote add origin https://github.com/USERNAME/REPO
We can also verify that the correct remote URL has been entered with -v switch.
git remote -v
Now we are ready to push our local code to the remote repository.
git push -u origin master
We can now create local branches and push them as new upstream branches to github. The first time we push the branch to remote we need to use the set-upstream command to create the sync with remote.
git checkout -b FEAT-0002
git push --set-upstream origin FEAT-0002
After we have set upstream we can now just type git push
Our next steps from here would be to add some automated tests into the pipeline. This will be covered in another blog post and include a look into automated accessibility testing possibilities.