Use custom Docker images

[ataylorme]

Rather than installing global packages as part of services that are run after the containers are initialized the global packages should be instead be defined in a custom to a Dockerfile.

See https://docs.devwithlando.io/config/advanced.html#using-dockerfiles

[felixarntz]

I think that makes sense to me. Could you (as time permits) spin up a simple PR just to give a better idea of what that could look like for this project?

[ataylorme]

@felixarntz you must create your own Dockerfile. If you have not done so before the easiest way to go is to start with an existing image base and then add what you need.

You can look at this Dockerfile that start with Node and then add JS task runners.

After that the image can be hosted on Docker Hub for Lando to pull from.

In .lando.yml you can then specify the custom Dockerfile image for any service (the default ones like appserver as well as any additional services you register).

Here is an excerpt of .lando.yml that adds a Node service based on a custom Dockerfile.

proxy:
  node:
    # Setup a proxy for the node service to connect
    # to BrowserSync at https://wp-best-practices.lndo.site:3000/
    - wp-best-practices.lndo.site:3000

services:
  # Spin up a node service so we can run gulp
  node:
    type: node:custom
    ssl: true
    overrides:
      services:
        ports:
          # expose port 3000 for BrowserSync
          - "3000:3000"
        # use a custom Docker image
        image: ataylorme/docker-node-advanced-wordpress-on-pantheon:latest

# Additional "lando" commands
tooling:
  npm:
    service: node
  node:
    service: node
  gulp:
    service: node

You can, of course, customize the image and mapped commands in tooling to suit your needs.

[westonruter]

Why is a Dockerfile better than just including the gulp installation as part of a install_dependencies_as_me_internal under the node service? Seems better to maintain that way.

[westonruter]

For example I can see on https://docs.devwithlando.io/services/node.html that Gulp can be installed via the .lando.yml as follows:

# Spin up services to run a basic node server
services:

  # Create a node instance
  appserver:
    #...

    # Optionally install the following npm dependencies globally
    # These follow the normal package.json form
    #
    # Note that most deps should be installed by the normal npm install, this is
    # for things like gulp/grunt cli that are global dependencies
    globals:
      gulp-cli: "latest"

[ataylorme]

@westonruter I suppose that can be a preference as well. I would still advocate for using a Node service, even if it is with a default Node image then installing gulp or Grunt or whatever else using globals rather than adding Node to the appserver service.

I prefer a Dockerfile because they can be built once, on Docker Hub or similar, and reused in many places (Lando, CI services, etc.).

Installing Node, as @felixarntz is doing now, or even using globals must be done when Lando is initialized for the project and on each rebuild after the container is downloaded.

If you are using a custom Dockerfile then the container is downloaded and ready to go since it has already been built to your specifications. So building the container once, in the cloud, is my preference.

Also, I can keep the Dockerfile in its own repo with version control and use it across many projects. So if you use Grunt, gulp, etc. your lando.yml can just call the custom Dockerfile rather than repeating the steps to install Node, Grunt, gulp, etc. in the .lando.yml for each project.

Anyway, these are just suggestions based on my Lando use and preferences. Feel free to reject them if your preferences differ.

[westonruter]

I'd probably agree with you if I weren't such a Docker newbie 😄

[felixarntz]

@ataylorme How about the need to access these Node tools from appserver though, if they're in a separate node service? It should definitely be possible to do lando ssh, and then npm install or grunt for example.

Edit: Oh wait, I noticed this was probably better suited on #2. I'm not sure I fully understand yet, but doesn't this issue only apply if we go with a separate node service? Or do you mean for appserver as well?

[ataylorme]

appserver is the name of the default PHP service. It uses a Dockerfile that has PHP installed (no Node). You can

1) create your own Dockerfile to use that has PHP and Node, giving you the ability to run PHP and Node tasks from the same service

2) create a new service for Node, leaving the appserver as-is handling PHP tasks and offload the Node tasks to the new service.

The former seems like what you hope to do. Here is an example Dockerfile that starts with PHP and installs Node.

For the latter, you would need to split your AMP plugin build steps into PHP and Node pieces and run them in sequence on the appropriate service.

[felixarntz]

Thanks for clarifying @ataylorme! Revisiting this, I think it makes sense to use a Dockerfile for this. I'd like to keep it somewhere in this repository for now though. @westonruter What do you think?

[westonruter]

I think I've never written a Dockerfile before so I don't know. But as far as I know putting it in this repo sounds good to me.

[ataylorme]

I'm happy to help with this and can open a PR if you like. Any requirements besides PHP, wp-cli, Node and Grunt?

[westonruter]

That would be great.

Also SVN is needed. Basically most of this I assume could be added to the Dockerfile:

https://github.com/felixarntz/wordpressdev/blob/01721d8aeb010b7608615857a0a854c82f3ade6c/.lando.yml#L14-L44

I suppose it could include a full copy of WordPress core SVN and Git as well so that when pulling down the image it would just need to svn up and git pull rather than having to start from scratch?

For WP-CLI, I think it would be good to install it from source rather than grab the Phar. See #10.

I suppose Redis or Memcached wouldn't need to be part of this (#7) since they could continue to be separate services.

[felixarntz]

I'd say let's stick to everything that is is currently in install_dependencies_as_root for now. Possibly also the tasks under install_dependencies_as_me and run, although I'm not familiar enough with Dockerfiles either to know whether it's a good practice to include these tasks. Also, does Dockerfile assume it is run as root or not?

Regarding WP-CLI, Redis and Memcached, let's defer these changes to their separate issues (as in continue to reuse WP-CLI like the WordPress recipe sets it up, and not worry about object cache services for this PR).