Docker volumes vs bind mounts

By default a docker container won’t store any persistent data, so anything that we write to its writable layer won’t be available once we stop it.When running Docker containers we might be interested in persisting certain data. This can be achieved by using either volumes or bind mounts. Below I’m describing main differences between the two.

Bind mounts are directories on the host filesystem mounted onto a Docker container. These can be modified outside of Docker.

Volumes on the other hand are managed by Docker only and you can use Docker cli commands to manage them directly. They are a preferred way to persist data.

There are named volumes created by the “volume” command that can be referenced by their name and there are volumes that are created by the VOLUME instruction from the docker files. The latter are identified by a hash and stored in the same Docker volumes folder.

When mounting volumes you specify the name instead of the paths you would like to mount. Volumes don’t increase the size of docker containers. If you would like to keep your own directory structure you should use bind mounts. Volumes make your project more portable, because with bind mounts you would need to rebuild your directory structure when migrating and you must ensure that all the security settings like user permissions are setup correctly.

Different ways of running PHP on an Apache server

When the server receives a request from the user it can serve the file directly, but sometimes it needs to translate the code using the appropriate application. Otherwise it would be showing the users the source code of the website. A server like Apache needs to be configured to handle specific content with an appropriate application like PHP.

A common set of rules of passing the information between the server and the application is the Common Gateway Interface. This standard lets programmers write applications in different languages that can plug into the server and interact with it. The interface guarantees consistency of data passed between the server and the application. An alternative to a CGI application is Microsoft’s Active Server Page (ASP).

CGI

A CGI program is one that conforms to the above specified protocol. The advantage of using CGI over a server module is keeping the execution of the application separate from the server.

If CGI is installed on the server a cgi-bin directory might be added to the public directory of the website and every page from that directory is treated as a CGI script, so the server runs the files through a relevant application instead of showing the code directly to the user. The server can also be configured to treat files with specific extensions as CGI files.

If CGI is installed on the server, the specific cgi-bin directory is also added there, for example home/user/public_html/cgi-bin. CGI scripts are stored in this directory. Each file in the directory is treated as an executable program. When accessing a script from the directory, the server sends request to the application, responsible for this script, instead of sending file’s content to the browser. After the input data processing is completed, the application sends the output data to the web server which forwards the data to the HTTP client.

When PHP is run in a CGI mode the server knows the location of the executable file and the loads it, with all its settings from the php.ini file every time it needs to interpret a php file. With this kind of workflow comes a lot of repeated work. The advantage is slightly better security, because the code is isolated from the server and the ability to load the php settings directly, without having to restart the server.

Fast CGI

The original CGI wasn’t very efficient and the FastCGI interface was introduced to deal with some of thess performance issues. One of the differences with the original is that the process spawned to handle the request is kept alive longer, so it can handle also some future requests.

FPM

FPM which stands for FastCGI Process Manager is a FastCGI implementation which has some features geared toward heavily trafficked websites. It maintains a pool of workers that can handle PHP requests and should avoid the memory overload from PHP in Apache processes. You can check out a list of features on the php.net website.

Apache Module

In case of using an Apache Module every child process that Apache spawns will contain its own copy of PHP interpreter. The downside of this solution is that the footprint of every spawned process is higher, so it consumes more server resources. In order to apply new PHP settings a server restart is required, but on the other hand PHP-specific settings can be included in the .htaccess files.

Finding out PHP server interface

There are many ways of executing a PHP script. For example you might run it directly from a command line:

php <name_of_the_script>

Other option, readily available for tesing since PHP 5.4, is to spin up the internal PHP server and see the result in a browser:

php -S localhost:3000

If you create a simple page with the function php_sapi_name you will be able to check out the interface that is being used to run the script.

In the first case the out put should be “cli” in the second one “cli-server”. If you run the file on a server it could output “apache2handler” or something similar if you’re using Apache server.

Installing Let’s Encrypt SSL certificate

Https has become a standard for websites and there’s no excuse not to have it enabled on the website, especially that it’s now possible for free.

Making your website more secure with a free Let’s Encrypt certificate is very easy with Certbot.

The prerequisites are to have SSH access to your server that is already online and serving the site over http. In the example I’m setting up the certificates with Apache.

You would need to add the repository for Certbot first:

    sudo apt-get update
    sudo apt-get install software-properties-common
    sudo add-apt-repository universe
    sudo add-apt-repository ppa:certbot/certbot
    sudo apt-get update

After Certbot and the Apache plugin are installed you need to install the certificate with the server:

sudo apt-get install certbot python3-certbot-apache
sudo certbot --apache

During the installation you will need to answer some configuration questions like which domains that you would like to include, but they are pretty self-explanatory.

And that’s it! Your server is ready to serve the site over https.