Author: Alex Panagis

With a quarter of all businesses relying on Docker (according to this Datadog study) and over 20% of web hosts running it – Docker’s containerization architecture is tried, tested, and relied upon from startup to enterprise.

At RunCloud, we’re pleased to announce that we are now rolling out support for Docker, making it easier for its users to deploy and manage their web applications (powered by Docker containerization architecture).

In this article, we’re going to cover exactly what this means and what you will now be able to do with the combined power of RunCloud and Docker.

Why Containerization – What Led Us Here

Firstly, a very brief bit of history.

What came before Docker, and why was Docker needed?

Most enterprise companies, by default, usually treat all users as untrusted and try to limit their access to services even if they are performing just a simple action. One technology that is commonly used for this purpose is chroot jail. This is a way of isolating a single process and its children from the rest of the system. It’s often used within VMs, resulting in a Dedicated → VM → chroot structure.

The problem with chroot jail is that it requires copying or mounting all necessary files from the host to the jail – which can be difficult to manage if multiple jails are needed.

Additionally, many applications only support a single jail, making it difficult to provide each user with their own jail. Overall, jailing users can be messy and requires careful tracking of shared objects and binaries within the jail.

When jailing users became difficult to manage, several major companies sought to create a new technology that would make it easier. This led to the development of Linux Containers (LXC), which offered a VM-like solution without the need to create a virtual machine. However, LXC was difficult for many people to use, as it required creating your own image rather than using pre-made solutions. This limited the adoption of LXC, despite its powerful capabilities.

In contrast to VMs, container images are read-only and faster to start up. This led to the creation of Docker, which was developed by Docker Inc. with a focus on security, ease of use, and portability. Docker has become one of the most popular tools in the world of DevOps and allows for easy sandboxing of servers. In 2015, Docker launched the Open Container Initiative (OCI) to provide a standard for OS-level virtualization.

The Benefits of Docker Containerization with RunCloud

1. Enhanced Security

If your web app gets hacked while running natively on RunCloud, hackers may well be able to gain access to the root shell if the server isn’t hardened properly. This is clearly bad news, as once the root user gets compromised, hackers gain access to everything on the server.

But in Docker, if your site gets compromised, you just need to clean up your web app and then restart the Docker container to roll everything back to how it should be quickly, easily, and relatively painlessly.

Using Docker allows us to better implement the rule of least privilege. Everyone with access to your server is treated as if you don’t know what their intention or capabilities are. Someone accessing your server may just want to do their job, perhaps they have bad intentions, or maybe they are a complete beginner who may inadvertently run a command that could make your server crash.

With Docker running inside RunCloud, we have `rc-shell` (RunCloud Shell) that will jail users inside their own container. Anything they do will only affect their data and their container – leaving the rest of the server unscathed.

2. Improved Performance

Although Docker may look like a virtual machine, it’s actually very different from that concept. Deleting old Docker containers and launching a fresh one takes only a couple of seconds. By using Docker to run your server, you can expect near-native performance, with improved performance when used in production at scale (as a result of isolation).

3. Better Server Management

Using containers for your server makes it much easier to manage your servers.

Firstly, since you are not installing services directly on the operating system, your server will be much cleaner, and you will encounter fewer problems in server management.

Secondly, suppose you need to use an older version of PHP on your site in the future. It will be much easier to do so with a containerized server since the version of the operating system running on the server might drop support for older PHP versions in the future.

Finally, upgrading your server will be much simpler because you won’t have to worry about compatibility issues with shared libraries or other potential causes of server crashes.

4. Same Dashboard/No Learning Curve

RunCloud aims to provide an easy-to-use interface for managing containerized servers – users migrating from native RunCloud installations will find the transition to using containers to be smooth and straightforward.

Additionally, users don’t need to have any knowledge of Docker to use RunCloud, as they won’t need to use any Docker commands. The learning curve for using Docker with RunCloud is relatively shallow, with only a few new concepts for users to learn in order to get started. Overall, using Docker inside RunCloud offers a more user-friendly experience for managing your server.

What’s New?

There are a lot of new features coming to RunCloud. Here are some of the most exciting ones.

Add Individual Services

In a native installation of RunCloud, all necessary software such as NGINX, PHP, MariaDB, Redis, and Beanstalkd are installed and can be started or stopped as needed.

In a containerized server, you now have the option to run each of these components individually – and can even choose not to run any of them if desired. Additionally, if a necessary image is not present on the server, it can automatically be downloaded from Docker Hub to ensure that everything is up to date and ready to run.

Quick and Easy Upgrades

With a native installation of RunCloud, some software, such as Redis and Beanstalkd may not be automatically updated after being installed. In order to enable automatic updates for these components, you may need to use third-party software, which can sometimes cause update failures and lead to issues such as agents not updating to the latest version.

In contrast, a containerized server automatically checks for the latest versions of all necessary components every 3 hours, ensuring that your software is always up to date and avoiding potential update & security issues.

Selectively Upgrade Services

MariaDB and Beanstalkd use exclusive locks, which means that during an upgrade, they can each cause a few seconds of downtime, as the running container must be stopped in order to start a new one. While the process of starting a new container is instantaneous, the health check process may cause a delay in reporting the status of the running service. Because of this, we have provided the option to enable or disable automatic updates for MariaDB and Beanstalkd.

However, it is generally recommended to avoid automatically updating critical software and instead has updates performed by a professional. With Docker, however, updates can be performed more easily and with minimal downtime. By default, MariaDB and Beanstalkd will not be automatically updated, but users can change this behavior if desired.

With native installations of RunCloud, updates to the agent software can sometimes result in new versions of other software being automatically installed on the server, even if the user doesn’t need or want them. For example, if an update to the agent brings PHP 8.0 to the server, it will be automatically installed whether the user wants it or not.

However, in a containerized server, the user has the ability to choose which versions of software they want to use and can easily remove any unnecessary components from the server stack. This allows for greater control over which software is installed and used on the server.

Easily Restore Passwords

In a native installation of RunCloud, the password for the MariaDB root user is stored in the /etc/mysql/conf.d/root.cnf file. If this password is accidentally changed, it must be updated in the file in order to access the MariaDB server, and it can be difficult to regain access to the server if the password isn’t known.

In a containerized server, if the password in the /etc/mysql/conf.d/root.cnf file is changed, the MariaDB server will automatically reset the root password to match the new password specified in the file, allowing you to easily regain access to the server.

Automatic Network Management

In a containerized server, the values localhost and 127.0.0.1 no longer refer to the server itself but instead indicate the location of the current container. This can cause issues when installing software, such as WordPress, that expects these values to refer to the server.

To address this, RunCloud uses the host to indicate the host machine rather than the current container. This can be used in the DB_HOST setting when installing WordPress, for example, to ensure that the database connection is established with the host machine rather than the PHP container. Additionally, the values mariadb and redis can be used to connect to the MariaDB and Redis containers, respectively, within your application.

Isolate Users

Docker is designed to run as a privileged user, such as the root, or a user with sudo access. In RunCloud, creating a system user does not automatically grant that user privileged access. Since PHP is not installed natively on the server, users will not be able to run PHP-related commands.

To overcome this limitation, RunCloud is introducing rc-shell, a jailed shell that allows users to run commands within a Docker container. Whenever a user connects to the server via SSH or SFTP, a new container is created, and the user is logged in to that container. This provides a secure environment where the user can only access their own files and has access to all necessary commands.

The only limitation is that each user can only choose one PHP version to use as their PHP command-line interface (CLI). However, users can choose whether to use the same PHP CLI version as the server or a different version for their own user account.

Run Different Versions of The Same Command

With a native installation of RunCloud, the php command refers to the PHP command-line interface (CLI) that is installed on the server. In a containerized server, this behavior is the same, and the php command refers to the default PHP CLI version that is installed on the server.

If a user wants to use a different PHP CLI version, they can use the /RunCloud/Packages/<php version>/bin/php command, where <php version> is the version of PHP they want to use.

In a containerized server, users can also use commands such as php72rc, php73rc, php74rc, etc., to run a specific PHP CLI version. However, the composer and wp commands will always use the default PHP CLI version and cannot be changed at this time. This applies to both native and containerized installations of RunCloud.

When the root user runs the php, wp, or composer command within a user’s directory, such as /home/user/webapps/mysite, these commands will automatically be run as if they were being executed by the user. This means that the root user does not need to switch to the other user in order to run these commands.

For example, if the root user runs the command composer install within /home/amir/webapps/mysite, it will be executed as if the amir user had run the command themselves. This provides a convenient and user-friendly way to manage these commands within a user’s directory.

“Run as” / Emulate / Mock User

Due to the limitations described above, cron and supervisor may not be able to run the php, composer, and wp commands as a specific user. To overcome this, RunCloud provides a feature called “fake run as” for use with cron and supervisor.

When using this feature, the specified command will be run as the root user, but it will be executed as if it were being run by the user specified in the “fake run as” field. This only applies to the php, composer, and wp commands and should not be used for any other commands. Using this feature allows cron and supervisor to run these commands as if they were being executed by a specific user, even though they are actually being run by the root user.

Restart Services Selectively

In a native installation of RunCloud, the systemctl command can be used to reload PHP-FPM for a specific PHP version. For example, to reload PHP-FPM for PHP 7.4, you can use the command systemctl reload php74rc-fpm.

In a containerized server, the <phpversion> reload command can be used instead, where <phpversion> is the specific PHP version you want to reload. For example, to reload PHP-FPM for PHP 7.4, you can use the command php74rc reload. The nginx-rc reload command can also be used to reload Nginx in a containerized server. This provides a convenient and user-friendly way to manage and reload PHP-FPM and Nginx on a containerized server.

How To Use Docker On RunCloud

It is fairly straightforward to use Docker on RunCloud.

1. Create a fresh Ubuntu server on your favorite public cloud, and click “Connect a New Server” in your RunCloud dashboard. Pick the “Containerized” option and complete the necessary fields.

2. Having done that, you can either continue via direct installation, or choose to install manually as you normally would.

Summary

The infrastructure improvements that Docker containerization allow us to deliver are incredibly powerful, and – in some ways – we’ve only really scratched the surface of what’s possible.

By rolling out support for Docker, we’re making it easier for users to deploy and manage web applications, including testing in consistent, isolated environments – also playing a role in preparing our architecture for further improvements planned in 2023 and beyond. This is an important step for RunCloud and all of our users.

With RunCloud, you don’t need to be a system administrator or Linux expert to manage your cloud infrastructure. With everything from backups, staging, cloning, atomic deployments, and more – RunCloud makes it truly enjoyable to manage your own production-grade infrastructure. Learn more & get started today.