I’m trying to ditch Vagrant and switch over to Docker, and so far, I really like using Lando. This post was particularly helpful in getting things going.
Everything works great for a standard WP/Bedrock install, but I can’t quite figure out how to get things going for multisite though. I’m working on a subfolder multisite at the moment, but I have a subdomain multisite in the not too distant future. If anyone has any suggestions, I’d greatly appreciate hearing them.
Just out of curiosity how do you deal with the other envs?
Trellis is great because of its configs and the whole ease of provisioning/deploying the server.
(sorry for the off topic)
What do you mean by “other envs?” Customizing the container environments?
We use Lando for docker because it has a super-easy cost of entry. Lando is basically a wrapper on docker and docker-compose and provides ready-made containers for WordPress as well as support for Pantheon.
We don’t use Trellis or Bedrock, so I am not sure how deployment would be handled with those.
We use CircleCI for deployment. CircleCi monitors git branches, and pushes to certain branches (staging, preview, developer1, developer2) trigger CircleCi to spin up its own containers, checkout that branch, and run composer install, yarn, and yarn run build:production. CircleCi then uses rsync (normal servers) or git push (WPEngine) to push the assets to the appropriate server.
I don’t use Pantheon, but my coding partner does, so I can’t really speak to that deployment process.
Just read that post linked in the first comment.
Maybe we’re doing it wrong, but we don’t actually run composer or yarn in the container. We run it locally.
wp-cli needs access to a working WordPresss with php and mysql, but Composer and Yarn don’t. So we do use lando wp but yarn and composer can be run locally. Any changes they make are synced virtually instantly to the container.
This also means our .lando.yml is much thinner.
I’m still new to the whole Lando/Docker world, but I think the idea here is that you would use lando composer instead of composer so that it doesn’t require you to have everything installed on your local machine, especially if you have things like different versions of PHP. That being said, its my personal opinion that if it works for you (since most of us already have PHP installed locally), there’s no “wrong” way to do it. Composer is generally much faster on the host machine instead of the guest one, too.
“other envs” as in staging / qa / production, everything that’s not “development”.
Basically trying to understand where the configs for those would fall.
Might be a docker thing and not really related to lando but I was curious if lando also deals with that.
Aha, Rory, I see. Composer running locally could be installing dependencies based on the local PHP’s version rather that the container’s PHP version, which is a potential source of conflicts.
I’ll have to look at updating our workflow, thanks! =)
Lando could pass environmental variables to the containers via the .lando.yml file. That could make sense if you are using Lando in your staging and production environments.
https://docs.devwithlando.io/config/env.html
We’re only using Lando for local development. In that workflow, CircleCi handles any environment changes when it runs the deployment process.
This topic was automatically closed after 42 days. New replies are no longer allowed.