Our blog smackdown between containerization and virtualization continues with a new post on package distribution.
For new readers, we are in the middle of a “wrestling match” – a friendly contest between Taras Shapovalov, (team container) Piotr Wachowicz (team VM). The battle royal includes:
- Image size and Overhead (part 1)
- Overhead (part 2)
- Start time, and Setup Orchestration
- Image formats
- Applications sharing
- Image version control
- Package distribution
- Device access
The Bell for Round 7 has Sounded – Let's discuss Package Distribution
Taras – At this point, packages (for example, RPM Package Manager (RPM), Debian software package (DEB), and Windows Installer (previously known as Microsoft Installer or MSI), are distributed as files with different formats. These packages contain directories and files, as well as scripts which are executed when the package is installed, uninstalled, or updated. Each operation may be associated with a script that is distributed with the package. The scripts ensure that the package is installed correctly and the application will run as expected in a particular environment.
With container images we can dispense with such scripts, making package maintenance simpler. This also makes the packages function more reliably, because it means that nothing will be modified in an environment that has never been tested. The required environment is generated during image creation and never changes. In fact, container images could even potentially replace the classic packages format.
Using such images for application distribution in VMs is theoretically possible, but it is unlikely they will replace classic distribution packages, because they are not well suited to the purpose.
Piotr - Good point. But let’s look at this argument from the other side. The traditional package-based approach actually makes it a bit easier to update parts of a VM in some cases. For example, if you know that OpenSSL is broken, you can simply use Yellowdog Updater, Modified (yum) to “yum update” your VMs. It is a bit trickier with containers, because as far as I know, container images do not have their own RPM Package Manager database (RPMdb), so yum update will not work.
As for VM image distribution being difficult – as long as your entire team is within the same cloud, sharing VM images is relatively easy, as we discussed earlier.
Taras - Theoretically you can put RPMdb inside each of your container images, although this increases image size. Also, when a user changes anything inside the container, the changes are applied to a temporarily created image layer. This means that when the user runs something like yum update inside the container and then restarts it, the update will be reverted. Users should create a snapshot of the updated container that is running, and use that instead of the old one. I really think containers need something better than using RPM or a similar tool inside the images.
Join us again soon for Round 8 – as we look at device access and sum up our series with a quick look at how VMs and containers stack up as competitors.