MINIMIZING VORTEIL APPS

Originally written by Alan Murtagh (http://blog.vorteil.io/post/minimization/)

A simple app is a superior app. When it comes to Vorteil we like to think of an app as the whole system. Your app isn’t just running on a small VM, it is a small VM. We cannot always simplify the binary’s source code, but keeping unnecessary files out of the file-system is something anyone can do. Though barely noticeable, superfluous file-system contents have a real cost that can add up over time:

• Longer build times
• Longer deployment latency
• More wasted disk-space
• Wasted RAM and CPU cycles
• More developer hours spent on understanding and maintenance

Why waste the time and money when our tools make it so easy to trim the fat? This post will tell you everything you need to know about minimising Vorteil apps using the CLI’s “analyse” command.

How does it work?

Here’s a comparison I did on my own system of the same Tomcat application before and after minimisation.

Before Minimisation

• Package Size: 205 MiB
• Smallest Possible Disk Size: 319 MiB
• Smallest Possible Number of Inodes: 1295
• Number of ‘.so’ Shared Object Files: 44
• Time to Compile: ~2.1s

After Minimisation

• Package Size: 71 MiB
• Smallest Possible Disk Size: 170 MiB
• Smallest Possible Number of Inodes: 482
• Number of ‘.so’ Shared Object Files: 17
• Time to Compile: ~1.4s

Benefits

• ~65% smaller packages, which implies less disk space wasted in repositories; less bandwidth spent streaming packages and faster downloads, which can translate directly to faster deployments
• ~33% less time building disk images, creating faster deployments
• ~47% less disk space for images, which creates a lower infrastructure burden and faster provisioning times (varies from platform to platform)
• ~62% fewer files on the disk, simplifying troubleshooting and more efficient disk cache (resulting in better performance)
• ~61% fewer shared object files; less files implies fewer software vulnerabilities to patch

Examples

Let’s work through a real life example to create the minimised Tomcat package I’ve just showed off. The marketplace’s Tomcat package contains a complete installation of Java 11 and Tomcat 9. No app is ever going to use everything built in to Java, but since we designed the Tomcat package to be something you could just slot your WAR file into and run we couldn’t distribute an already minimised Tomcat package. Which files are necessary varies from one use-case to the next, so you shouldn’t try to minimise it until after you’ve got your app working. That said, in our example we’ll just be using Tomcat as-is. The process will be the same.

I’ll be working with a standard Vorteil installation. If you need to install Vorteil you can check out this guide. We’ll also be connecting to the marketplace, learn how to do this here.

Setting up a Project

The first task when minimising an app is to turn it into a project. Since we’ll be using the already packaged app on the marketplace, we’ll need to unpack it.

Pull from the Marketplace

This step isn’t completely necessary, but I generally like to use my local repository as a sort of cache for remote apps.

$ vorteil pull marketplace:sisatech/tomcat

Unpack the Local Copy to a Project

Now you have to decide where you’ll be unpacking to. I keep all of my projects in “~/vorteil/projects”, but you can put them wherever you like.

$ cd ~/vorteil/projects
$ vorteil unpack local:sisatech/tomcat tomcat

From this point onwards, I’ll be using this tomcat project directory as my working directory.

$ cd ~/vorteil/projects/tomcat

Provisioning the App

We have to run the app a little bit differently than you’re probably used to. Normally we’d just use the CLI’s ‘run’ command, but the run command treats Vorteil VMs as disposable. Normally that’s a good thing, but we need to preserve the virtual disk image of our app after it has run. To achieve this we’ll be using various ‘machines’ commands for a finer-grained control over the VMs.

To start with, just provision the application.

$ vorteil machines provision
provisioned VM: tomcat

As you can see, our new virtual machine has been named “tomcat”. It will now show up under the list command, and also on the Developer Studio.

$ vorteil machines list
╭─────────┬────────╮
│   ID    │ STATUS │
├─────────┼────────┤
│ tomcat  │ Ready  │
╰─────────┴────────╯

A virtual machine that is “Ready” is not yet running. To start it you’ll need to use the ‘start’ command.

$ vorteil machines start tomcat

After a brief delay, you should see the status of the VM has changed.

$ vorteil machines list
╭─────────┬────────╮
│   ID    │ STATUS │
├─────────┼────────┤
│ tomcat  │ Alive  │
╰─────────┴────────╯

At this stage if you’d like to follow the app’s logs like you’d see using the ‘run’ command, open up another terminal and use the ‘tail’ command.

$ vorteil machines tail tomcat

Branch Testing the App

Most apps won’t load files until they are needed. Simply launching your app is probably not going to be sufficient in most cases. You should try your best to put your app through its paces before shutting it down and analysing the disk whenever app minimisation is the goal.

The ideal way to test your app is to perform “branch testing” on it in an attempt to force it to try everything it is capable of trying. In the real world using your intuition and common sense is probably good enough. You may end up accidentally removing a file you shouldn’t have, but a missing file is usually a pretty easy error to debug, so you can always add them back in afterwards.

For our example I just went to the Tomcat dashboard at “localhost:8080” and clicked as many links as I could find.

Recovering the Virtual Disk Image

Now we need to recover the virtual disk image. First, we need to shut down the virtual machine. It is important to shut down the VM gracefully because the Vorteil kernel uses a cache in memory for most of its file-system accesses to improve performance. You must perform a proper shutdown to be absolutely certain that changes to last access time are flushed to the disk.

$ vorteil machines stop tomcat
$ vorteil machines list
╭─────────┬─────────╮
│   ID    │ STATUS  │
├─────────┼─────────┤
│ tomcat  │ Stopped │
╰─────────┴─────────╯

As you can see, just because we have stopped the VM doesn’t mean the VM has been discarded. We can now download a copy of the virtual disk using the ‘image’ command.

$ vorteil machines image tomcat /tmp/tomcat.vmdk

Note that I’ve put the disk image in my temporary directory. I did that because I don’t want to risk accidentally including it in my project. I could also have added a pattern like “*.vmdk” to the project’s ignores list instead to protect myself from this problem.

We no longer need the VM at all now that we’ve recovered a copy of the virtual disk. Let’s clean it up properly now.

$ vorteil machines delete tomcat

Using the Analyze Command

Now that we’ve got our used disk image, let’s see what the ‘analyze’ command does.

$ vorteil images analyze /tmp/tomcat.vmdk

If you’ve followed all the steps up until now, the analyze command will dump a list of every file on the disk to the screen. The command will also colourise the list: objects written in white have a last access time more recent than Unix zero time, and objects written in blue have never been accessed at all. If you ran this command on a freshly compiled disk every object on the disk would be written in blue.

Take a good look at the list and see if it looks alright to you. If you spot anything that doesn’t seem right, be sure to make a note of it for later.

Now I’m going to clone my project directory so that I have easy access to a backup of the project before I made any changes.

$ cp -R ../tomcat ../tomcat-backup

With that out of the way, I’m going to use the experimental “cull” flag on the analyze command to have the CLI delete every blue object from the project tree. Right now the cull flag is a blunt instrument that doesn’t do anything particularly clever, so there’s definitely a risk that it could do some damage to my project. Having said that, I think sometimes it’s easier to break it this way and then fix it up later than to manually remove each blue object one-by-one.

The cull flag takes a path to a project directory that it will assume it the complete and original source for the files on the disk.

$ vorteil images analyze /tmp/tomcat.vmdk --cull .

Fixing the Minimized App

It’s important after using the cull flag to check that the app still works. Let’s try and run the app again.

$ vorteil run
error: ~/vorteil/projects/tomcat/jdk-11.0.1/bin/java: no such file or directory

As you can see, we didn’t even make it past the disk building stage. What happened? This is actually caused by a quirk in the way Vorteil operates. With Vorteil, the app’s binary is put on the kernel’s partition for performance reasons. This means the app’s binary usually doesn’t need to be on the file-system at all!

Because the binary was loaded from the kernel’s partition it was never accessed on the file-system, and consequently showed up blue, so the cull flag deleted it. The problem here is that the project still needs the binary, so we’ll have to copy it back in. I’ll copy it from the backup I created earlier.

$ cp ../tomcat-backup/jdk-11.0.1/bin/java jdk-11.0.1/bin/java

It’s often worth trying to exclude the binary from the file-system by adding it explicitly to the project’s ignore patterns. This will help minimize the app by preventing the binary being included twice.

Now let’s try again.

$ vorteil run

This time my project built and provisioned perfectly. At this stage you should open your website up in your browser and check that it behaves correctly. If your tests back in the section “Branch Testing Your App” were comprehensive then everything should work fine!

Once your tests are finished, you should repackage the project and upload it to your repository for distribution!