LAMP

Ever wanted to deploy a LAMP Stack on Kubernetes?

TL;DR;

$ helm repo add lamp https://lead4good.github.io/lamp-helm-repository
$ helm install my-lamp lamp/lamp

Introduction

This chart bootstraps a LAMP Stack deployment on a Kubernetes cluster using the Helm package manager. It was designed in a very modular and transparent way. Instead of using a custom built docker container running multiple services like apache and php-fpm inside with no control or overwatch of these processes from within kubernetes, this chart takes the approach of using one service per container.

The charts default configurations were made with performance in mind. By default PHP-FPM is enabled and communication between php and mysql as well as apache and php is realized over unix sockets.

By default the chart is exposed to the public via LoadBalancer IP but exposing the chart via an ingress controller is also supported. If a working lego container is configured the chart supports creating lets encrypt certificates.

Setting up your website is easy, you can either use git or svn to copy your repo into the pod or use sftp or webdav and simply transfer your files into the container. If you have a different method of setting up your website, you can manually prepare it inside of an init container before the services start.

Once you've set up your website, you'd like to have separate development environments for testing? Don't worry, with one additional setting you can clone an existing release without downtime using the xtrabackup init container.

Official containers are used wherever possible ( namingly php, apache, mysql, mariadb and percona ) while the use of well established containers was anticipated otherwise ( phpmyadmin/phpmyadmin, atmoz/sftp, openweb/git-sync ) . To provide some of its unique features such as chart cloning and wordpress support some containers had to be newly created. All of those are hosted as automated builds on docker hub - with their respective sources on GitHub (lead4good/init-wp, lead4good/svn-sync, lead4good/webdav, lead4good/xtrabackup).

Prerequisites

• Kubernetes 1.7+
• LoadBalancer support or Ingress Controller

Installing the Chart

To install the chart with the release name my-release:

$ helm install --name my-release stable/lamp

The command deploys the LAMP chart on the Kubernetes cluster in the default configuration. The configuration section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

Uninstalling the Chart

To uninstall/delete the my-release deployment:

$ helm delete my-release

The command removes all the Kubernetes components associated with the chart and deletes the release.

Examples

To try out one of the examples. you can run, e.g. for wordpress:

$ helm install -f examples/wordpress.yaml --name wordpress stable/lamp

Currently you can try the following examples:

• examples/wordpress.yaml
• examples/wordpress-ingress-ssl.yaml
• examples/wordpress-php-ini.yaml
• examples/drupal.yaml
• examples/joomla.yaml
• examples/joomla.yaml
• examples/owncloud.yaml
• examples/nextcloud.yaml

Configuration

The following tables list the configurable parameters of the LAMP chart and their default values.

You can specify each of the parameters using the --set key=value[,key=value] argument to helm install. For example,

$ helm install --name my-release \
  --set init.clone.release=my-first-release-lamp,php.sockets=false,php.oldHTTPRoot=/var/www/my-website.com \
    stable/lamp

The above command sets up the chart to create its persistent contents by cloning its content from my-first-release-lamp, sets PHP socket communication to false and sets an old http root to compensate for absolute path file links

Alternatively, a YAML file that specifies the values for the above parameters can be provided while installing the chart. For example,

$ helm install --name my-release -f values.yaml stable/lamp

Tip: You can use the default values.yaml file as a template

Manually preparing the webroot and database

The manual init container enables you to manually pull a websites backup from somewhere and set it up inside the container before the chart is deployed. Set init.manually.enabled to true and connect to the container by replacing example-com-lamp and executing

$ kubectl exec -it \
  $(kubectl get pods -l app=example-com-lamp --output=jsonpath={.items..metadata.name}) \
  -c init-manually /bin/bash

The container has the document root mounted at /var/www/html and the database directory mounted at /var/lib/mysql . The default manual init container is derived from the official mysql container and can create and startup a mysql db by setting the necessary environment variables and then executing

$ /entrypoint.sh mysqld &

If another flavor of DB is used (mariadb or percona) then the image needs to be pointing to the right container.

After setting up your DB backup you can stop the database by executing

$ mysqladmin -uroot -p$MYSQL_ROOT_PASSWORD shutdown

Now copy all necessary files into the web directory, but do not forget to recursively chown the webroot to the www-data user ( id 33 ) by executing

$ chown -R 33:33 /var/www/html

Once everything is setup stopping the init container is done by executing

$ im-done

Cloning charts

If init.clone.release is set to the fullname of an existing, already running LAMP chart (e.g. example-com-lamp), the persistent storage of that chart (web files and db) will be copied to this charts persistent storage. It is mandatory that both database containers are of the same type (mysql, mariadb or percona). Mixing them will not work.

Init Containers Resources

| init.resources | init containers resource requests/limits | resources |

PHP and HTTPD Containers

The PHP container is at the heart of the LAMP chart. By default, the LAMP chart uses the official PHP container from docker hub. You can also use your own PHP container, which needs to have the official PHP container at its base. FPM is enabled by default, this creates an additional HTTPD container which routes PHP request via FCGI to the PHP container. Set php.fpmEnabled to false to work with the official php:apache image.

Note: If you are using a custom container, be sure to use the official php:apache or php:fpm containers at its base and set php.fpmEnabled accordingly

MySQL Container

The MySQL container is disabled by default, any container with the base image of the official mysql, mariadb or percona should work.

SFTP Container

SFTP is an instance of the atmoz/sftp container, through which you can access the webroot.

Note: The webroot is located in the subfolder of the sftp users home directory so putting files into the webroot via sftp have to be put to the web subfolder and the put command will fail if you upload to the root directory since writing permissions are disabled there.

Note: using a different image than the default atmoz/sftp will most probably not work since the containers startup command is overwritten to be able to configure the sftp user, you may however change the tag to a different version without any problems

WebDAV Container

An instance of WebDAV, through which you can access the webroot.

Git Container

If Git is enabled, the contents of the specified repository will be synchronized every git.wait seconds to the web root. The web root needs to be empty otherwise the container will fail exit.

Note: You should not combine SFTP or WebDAV with the Git container since this might cause confusion if someone edits a file via SFTP just to find out that its changes got reverted by the Git sync process

SVN Container

If SVN is enabled, the contents of the specified repository will be synchronized every 30 seconds to the web root. If allowOverwrite is disabled and files already exist in the web folder then it will not create a working clone or sync files.

Note: You should not combine SFTP or WebDAV with the SVN container since this might cause confusion if someone edits a file via SFTP just to find out that its changes got reverted by the SVN sync process

PHPMyAdmin Container

An instance of PHPMyAdmin through which you can access the database.

Note: using a different image than the default phpmyadmin/phpmyadmin image might not work since the containers startup command is overwritten to be able to advertise the http services on phpmyadmin.port, you may however change the tag to a different version without any problems

Default Resources

Default resources are used by all containers which have no custom resources configured.

Persistence

If persistence is enabled, PVC's will be used to store the web root and the db root. If a pod then is redeployed to another node, it will restart within seconds with the old state prevailing. If it is disabled, EmptyDir is used, which would lead to deletion of the persistent storage once the pod is moved. Also cloning a chart with persistence disabled will not work. Therefor persistence is enabled by default and should only be disabled in a testing environment. In environments where no PVCs are available you can use persistence.hostPath instead. This will store the charts persistent data on the node it is running on.

Network

To be able to connect to the services provided by the LAMP chart, a Kubernetes cluster with working LoadBalancer or Ingress Controller support is necessary. By default the chart will create a LoadBalancer Service, all services will be available via LoadBalancer IP through different ports. You can set service.type to ClusterIP if you do not want your chart to be exposed at all. If ingress.enabled is set to true, the LAMP charts services are made accessible via ingress rules. Those services which are not provided by HTTP protocol via nodePorts. In ingress mode the LAMP chart also supports ssl with certificates signed by lets encrypt. This requires a working lego container running on the cluster.

Note: In ingress mode it is mandatory to set ingress.domain, otherwise the ingress rules won't know how to route the traffic to the services.

Wordpress

The LAMP chart offers additional wordpress features during the init stage. It supports two modes, normal mode sets up the chart completely automatic by downloading an InfiniteWP backup from google drive, while the other mode gets executed when in manual mode (see: init.manually). While in manual mode, the web files and db backup need to be manually downloaded and stashed in the appropriate folders (/var/www/html <-- web root, /var/www/mysql <-- sql backup). The automatic mode does this automatically. Both modes then import the backup and do some necesssary config file changes. So even in manual mode it is not necessary to import the db backup.

In development mode everything that gets executed in normal mode will also get executed. Additionally the wordpress domain is automatically search replaced inside the database. Also the wp_content/uploads and wp_content/cache directories are deleted. The .htaccess file is modified to redirect requests to the uploads directory to the uploads directory of wordpress.domain.

Other