The practical application of Linux Deploy on desktops
Despite the fact that Linux Deploy was originally conceived as an Android application, over time other options for its application appear. With the advent of the Linux Deploy CLI, a number of features have become available that open up new areas of application for this tool.
Linux Deploy CLIIs a command line interface application designed to automate the process of installing, configuring and running GNU / Linux distributions inside a chroot container. The application can work both in ordinary desktop Linux distributions, and on mobile platforms based on the Linux kernel, provided that the necessary dependencies are observed (all dependencies can be built statically). Applications from the Linux distribution run in a chroot environment, work in parallel with the main system and are comparable in speed to it. Since the operation of Linux Deploy is based on a system call of the Linux kernel, only Linux distributions can act as “guest” systems.
The application can work in two modes: with superuser rights (chroot) and without them (proot). In normal mode, all supported installation types are available: installation to a file, to a disk partition (logical drive), to a POSIX compatible directory, and to RAM (tmpfs). In proot mode, installation is available only in the directory, and a number of restrictions appear:
The application supports automatic installation (of the base system) and initial configuration of the distributions of Debian, Ubuntu, Kali Linux, Arch Linux, Fedora, CentOS, Gentoo, openSUSE and Slackware. Installing a Linux distribution is done over the network from official mirrors on the Internet. It also supports the import of any other system from a pre-prepared rootfs-archive in the format tar.gz, tar.bz2 or tar.xz. The application allows you to connect to the console of the installed system (container), as well as start and stop applications inside the container (there is support for various initialization systems and own autorun scripts). Each installation option is saved in a separate configuration file, which is responsible for configuring each container. If necessary, containers can be launched in parallel.
In general, the idea of Linux Deploy arose from the desire to get an easy and convenient tool for quickly deploying a Linux distribution that could be used for development, testing or training, and then quickly remove it without making changes to the main (host) Linux system and without risking its integrity. Thanks to the PRoot program, it became possible to create containers for running Linux applications without root privileges, as well as use QEMU software emulation for launching applications with a different architecture from the host without the need for kernel -level binfmt_misc module support .
It so happened that since 2011 my main work has been using computers with Debian. Local developers periodically need a system to run and test their web applications (mainly Java, PHP, Python). For these purposes, virtual systems based on VirtualBox, or in the local Proxmox cloud or Docker, were usually used. The main disadvantage of VirtualBox is its exactingness on computer resources, the large size of the VDI disk image, the relatively low speed and the likelihood of a VM image crashing when the system shuts down incorrectly. The disadvantage of using the “cloud” is the need for the administrator himself to serve user requests for the creation of such systems, as well as the expenditure of the “cloud” resources on secondary tasks. Superuser privileges are required to work with Docker.
An experiment was conducted this month; PHP developers have replaced their virtual server with an LD container. Two Debian-based containers were prepared: Apache + PHP + OCI8 and Apache + PHP + MySQL + PhpMyAdmin. The containers were placed on a shared network drive on the local network, the size of each container was about 150 MB.
What the administrator received from this:
What the developer got:
And now in more detail about how to achieve this. Next, instructions will be provided on preparing and deploying the LD container.
To run containers without superuser privileges, you need to install PRoot:
Download and install Linux Deploy CLI:
Creating a configuration named “linux” to deploy the Debian Wheezy base system (64 bits):
View saved configuration:
Launching the deployment of a new system:
Connecting to the console console under the root user (to exit the exit command):
Then you can install and configure the necessary software in the container, however, you should take into account the previously described features. For example, to start Apache you need to change its port (file /etc/apache2/ports.conf) to 8000, set the empty parameter APACHE_ULIMIT_MAX_FILES = "" (file / etc / apache2 / envvars), and run apachectl from under a regular user ( not root).
Configuring autorun based on the SysV initialization system:
Parameters: INIT_LEVEL - initialization level SysV, INIT_USER - from which user to start services (by default it is root), INIT_ASYNC - start services in parallel.
Preparing the configuration, exporting it and exporting the container to the rootfs archive (tar.gz, tar.bz2 and tar.xz archives are supported):
Escaping "\ $" allows you to save the names of variables in the config, not their values. Thus, when importing the config, these variables will be automatically replaced with the corresponding values, which may differ from the current ones. Now there are two files (linux.conf and linux.tgz) that you can use when importing a container on another computer:
Connect the main system directory to the container (connect the ~ / www directory to the / var / www container):
Starting the container (for SysV, the scripts /etc/rcN.d/SXXname start are executed):
Stopping the container with freeing resources (for / or SysV the /etc/rc6.d/KXXname stop scripts are executed):
The result is a solution that meets the needs of both developers and administrators. Linux Deploy application source code is available under the GPL version 3 license.
Linux Deploy CLIIs a command line interface application designed to automate the process of installing, configuring and running GNU / Linux distributions inside a chroot container. The application can work both in ordinary desktop Linux distributions, and on mobile platforms based on the Linux kernel, provided that the necessary dependencies are observed (all dependencies can be built statically). Applications from the Linux distribution run in a chroot environment, work in parallel with the main system and are comparable in speed to it. Since the operation of Linux Deploy is based on a system call of the Linux kernel, only Linux distributions can act as “guest” systems.
The application can work in two modes: with superuser rights (chroot) and without them (proot). In normal mode, all supported installation types are available: installation to a file, to a disk partition (logical drive), to a POSIX compatible directory, and to RAM (tmpfs). In proot mode, installation is available only in the directory, and a number of restrictions appear:
- all users inside the container have full access to the entire file system of the container, and the current user is the owner of all files and directories;
- there is no access to privileged operations with the system, for example, ping, ulimit, etc. do not work;
- applications can only work with network port numbers above 1024;
- if the application uses the chroot system call in its work, then it must be launched through the special fakechroot utility, for example fakechroot / usr / sbin / sshd -p 2222.
The application supports automatic installation (of the base system) and initial configuration of the distributions of Debian, Ubuntu, Kali Linux, Arch Linux, Fedora, CentOS, Gentoo, openSUSE and Slackware. Installing a Linux distribution is done over the network from official mirrors on the Internet. It also supports the import of any other system from a pre-prepared rootfs-archive in the format tar.gz, tar.bz2 or tar.xz. The application allows you to connect to the console of the installed system (container), as well as start and stop applications inside the container (there is support for various initialization systems and own autorun scripts). Each installation option is saved in a separate configuration file, which is responsible for configuring each container. If necessary, containers can be launched in parallel.
In general, the idea of Linux Deploy arose from the desire to get an easy and convenient tool for quickly deploying a Linux distribution that could be used for development, testing or training, and then quickly remove it without making changes to the main (host) Linux system and without risking its integrity. Thanks to the PRoot program, it became possible to create containers for running Linux applications without root privileges, as well as use QEMU software emulation for launching applications with a different architecture from the host without the need for kernel -level binfmt_misc module support .
It so happened that since 2011 my main work has been using computers with Debian. Local developers periodically need a system to run and test their web applications (mainly Java, PHP, Python). For these purposes, virtual systems based on VirtualBox, or in the local Proxmox cloud or Docker, were usually used. The main disadvantage of VirtualBox is its exactingness on computer resources, the large size of the VDI disk image, the relatively low speed and the likelihood of a VM image crashing when the system shuts down incorrectly. The disadvantage of using the “cloud” is the need for the administrator himself to serve user requests for the creation of such systems, as well as the expenditure of the “cloud” resources on secondary tasks. Superuser privileges are required to work with Docker.
An experiment was conducted this month; PHP developers have replaced their virtual server with an LD container. Two Debian-based containers were prepared: Apache + PHP + OCI8 and Apache + PHP + MySQL + PhpMyAdmin. The containers were placed on a shared network drive on the local network, the size of each container was about 150 MB.
What the administrator received from this:
- once prepared container can be deployed on the developer's computer with one team without the participation of the administrator;
- work with the container does not require superuser rights, therefore there is no risk of breakdown of the main system.
What the developer got:
- deployment, launch and management of the system in the container is carried out without the participation of the administrator as a single team;
- Deployment of the container from pre-prepared archives is carried out over the network in less than a minute;
- container start and stop (Web server + database) occurs instantly, no need to wait for the operating system to start;
- there is no risk of damaging the container if you forget to turn it off when you turn off the computer, because the system image is a regular directory without its own file system;
- the computer is faster because resources are spent only on running software in the container, and not on the entire operating system (in our case, this is about 50 MB, instead of 500 MB in VirtualBox).
- checking the functionality of the software directly from the IDE directory without the need to upload it to the server, for this it is enough to connect the necessary directory of the main system to the container.
And now in more detail about how to achieve this. Next, instructions will be provided on preparing and deploying the LD container.
To run containers without superuser privileges, you need to install PRoot:
mkdir ~/bin
wget http://portable.proot.me/proot-x86_64 -O ~/bin/proot
chmod 755 ~/bin/proot
Download and install Linux Deploy CLI:
wget -O cli.zip https://github.com/meefik/linuxdeploy-cli/archive/master.zip
unzip cli.zip
rm cli.zip
ln -sf ~/linuxdeploy-cli/cli.sh ~/bin/linuxdeploy
Creating a configuration named “linux” to deploy the Debian Wheezy base system (64 bits):
linuxdeploy -p linux conf --method='proot' --source-path='http://mirror.yandex.ru/debian/' \
--distrib='debian' --arch='amd64' --suite='wheezy' --target-path='$ENV_DIR/rootfs/linux' \
--chroot-dir='$TARGET_PATH' --target-type='directory' --username='webmaster' --include='bootstrap'
View saved configuration:
linuxdeploy -p linux conf -x
Launching the deployment of a new system:
linuxdeploy -p linux deploy
Connecting to the console console under the root user (to exit the exit command):
linuxdeploy -p linux shell -u root
Then you can install and configure the necessary software in the container, however, you should take into account the previously described features. For example, to start Apache you need to change its port (file /etc/apache2/ports.conf) to 8000, set the empty parameter APACHE_ULIMIT_MAX_FILES = "" (file / etc / apache2 / envvars), and run apachectl from under a regular user ( not root).
Configuring autorun based on the SysV initialization system:
linuxdeploy -p linux conf --include='$INCLUDE init' --init='sysv' --init-level='3' --init-user='$USER_NAME' --init-async
Parameters: INIT_LEVEL - initialization level SysV, INIT_USER - from which user to start services (by default it is root), INIT_ASYNC - start services in parallel.
Preparing the configuration, exporting it and exporting the container to the rootfs archive (tar.gz, tar.bz2 and tar.xz archives are supported):
linuxdeploy -p linux conf --source-path='linux.tgz' --target-path='\$ENV_DIR/rootfs/linux' --chroot-dir='\$TARGET_PATH'
linuxdeploy -p linux conf -x > /path/to/linux.conf
linuxdeploy -p linux export /path/to/linux.tgz
Escaping "\ $" allows you to save the names of variables in the config, not their values. Thus, when importing the config, these variables will be automatically replaced with the corresponding values, which may differ from the current ones. Now there are two files (linux.conf and linux.tgz) that you can use when importing a container on another computer:
cd /path/to
linuxdeploy -p linux conf -i ./linux.conf
linuxdeploy -p linux deploy
Connect the main system directory to the container (connect the ~ / www directory to the / var / www container):
linuxdeploy -p linux conf --mounts='$HOME/www:/var/www'
Starting the container (for SysV, the scripts /etc/rcN.d/SXXname start are executed):
linuxdeploy -p linux start
Stopping the container with freeing resources (for / or SysV the /etc/rc6.d/KXXname stop scripts are executed):
linuxdeploy -p linux stop -u
The result is a solution that meets the needs of both developers and administrators. Linux Deploy application source code is available under the GPL version 3 license.
