Skip to content

NOT COMPLETE

Components in WPLib Box

"Components" provide the underlying functionality of WPLib Box. Components are collected together into an Project Stack to drive the

Component Classes

In general Components will fall into one or more of these classes:

  1. Service Containers: Service apllications running in Docker containers; i.e. web servers, database servers, process VMs (e.g. a PHP version), etc.
  2. Executable Containers: Compiled binaries running inside of a Docker container; i.e. Command-line versions of PHP, Python and Ruby as well tools like Git and SVN, etc.
  3. Scripts: Interpreted scripts executed by pairing with an executable container; i.e. Composer, PHPUnit, WP-CLI, PHP-CodeSniffer, etc.
  4. Source: Source code files; i.e. WordPress core, plugins, themes and PHP libraries as well as collections of those files we will call Blueprints.
  5. Data: Data files; i.e. MySQL dumps, XML files, JSON files, etc.
  6. Media: Media files; i.e. Image files, video files, PDF files, etc.

Note

The page describes our 1.0 vision for WPLib Box.
Though not everything described below is implemented we plan to be feature-complete before 2019.

Requirements

Each component has a "Named Type" and each component must implement the "Interface" defined by its named type.

Named Types

Interfaces

Components are a method to add additional functionality to WPLib Box. These packages can include anything, and any user can create a package.

Current Component Types

All of the following Component Types are implemented via a Docker Container and supplied - container/webserver - An HTTP Web Server that runs on Linux that provides sufficient features to serve WordPress websites, such as Nginx. - container/dbserver - A MySQL-compatible Database Server that runs on Linux that can serve databases for WordPress websites - container/kvstore - A Key-Value Store typically used for persistent object caches in WordPress, such as Redis or Memcached - container/processvm - A PHP-style language engine used to execute WordPress source code.

Currently Supported Components

WPLib Box can currently compose an operating "stack" from the following Components (the first one listed in each category is the default component) when you first install WPLib Box:

Category Default Component Also Available "Component Type" Notes
Web Server Nginx Apache and Caddy container/webserver
DB Server MySql MariaDB container/dbserver
Cache Server Redis memcached container/cacheserver
Process VM PHP 7.0 PHP 7.1 and PHP 5.6 container/processvm PHP 7.0 and 5.6 are (currently) implemented in Docker containers but PHP 7.1 has been installed directly to Linux while we wait for an official Docker PHP 7.1 container.

Disclaimer: Currently all except Caddy and container/webserver are not actually implemented as components, but instead installed directly. However it is our intention to convert them all to components in the near future.

How Components Work

Components are listed in the project.json file for each project that uses WPLib Box. In this JSON file is a list of services that will get automatically configured and made to run whenever vagrant up is run. Vagrant delegates to box startup which it runs inside in the Linux box (specifically this script does not run in the Windows or macOS host computer, it runs via SSH tunnelling in WPLib Box.)

If WPLib Box does not find that the component has been previously installed in the current WPLib Box it reaches out to the Internet and downloads and installs the component, and then ensures that it is running for the current project. This approach allows easy stack sharing during development among team members on multi-developer project, and it makes it easy for individual developers to pick of a prior project without having the spend time recreating the previously used development environment.

Note that we expect the exact details of how components work will to evolve significantly before we reach version 1.0 so we'll wait until things settle down before document them in detail.

Anatomy of a Docker Container Component.

  • component.json - A file at the root level of the repository that defines the component package.
  • commands directory - This subdirectory contains commands that can be executed by the guest CLI.
  • README.md (optional) - This should detail how to install the package and the CLI commands made available.

component.json Contents

This file is simply a collection of JSON objects that define the package.

JSON Object Properties

Property Name Description
name This is the name of the component. This should be in human readable form, e.g. My Super Cool Component.
version The component version. This should following Semantic Version rules, e.g. 0.1.0.
type Each package has both a major and minor type. The major type defines the role the component plays in the box, ( e.g. webserver ). The minor type is the implementation of the component, ( e.g. container for a Docker container ). Currently, only Docker container minor type is supported.
download This is the source repository of the component, ( e.g. wplib/my-super-cool-component ). Currently, only GitHub repositories are supported.
containername This is the name to use for the Docker container. It MUST be unique, ( e.g. mysupercoolcontainer ).
website This is the URL for the component. This could be either the GitHub repository, or a link to a site or page dedicated to information about the component package.
contains

This a JSON object with the following property/value pairs: type, version, and website. If you were to create a component for ElasticSearch, this object might be as follows:

contains:{ 
   "type": "service/linux", 
   "version": "5.4.0", 
   "website": "https://github.com/elastic/elasticsearch" 
}

Container Hosting

The Docker containers used by our components are hosted at the WPLib account on Docker Hub.