Most people wouldn't think to compare a File Transfer Protocol (FTP) Server to an Open Container Initiative (OCI) Image Registry, much less to use one for the purposes of the other.

These two technologies date back to entirely different eras—1970s vs mid-2010s. So much has changed in that span of time. Embedded into their names are very different uses cases: short-term transfer of arbitrary files vs long-term storage of structured container tarballs. No wonder they don't come up in the same conversations.

But... are we missing an opportunity?

OCI images are not just for runnable applications.

An OCI image can hold any kind of content. Case in point, it could just be some files that you need to transfer.

I learned this lesson on a project where we were providing students with individual, dynamically-provisioned environments. Each student would need to build a sizable Java application, which can take a minute or five to download dependencies. We were in a conundrum: if we build the app as the environment is being prepared, the student has to wait to get started. If we let the student do the first build, they would be stalled just a few steps in. Neither seemed good.

Luckily, one of my colleagues came up with a brilliant idea: use an OCI image to bundle the dependencies and transfer them to each environment before the first build. This would be faster than downloading them through Java's build tool. The kicker: we could do this very easily using Carvel's imgpkg tool.

docker build, push and pull are not the only gateways to an OCI registry.

imgpkg is better known for packaging and distribution of Kubernetes configuration and dependent OCI images, but there's nothing stopping you from using it more creatively.

In our case, we packaged the $HOME/.m2 directory (where Java downloads dependencies) as an image and published it to a registry. This was a one-time step.

imgpkg push --image myRegistry/myAppLibs:latest --file $HOME/.m2

Then, during the setup of each environment, we retrieved the image and unpacked it into the same relative location.

imgpkg pull --image myRegistry/myAppLibs:latest --output $HOME/.m2

Problem solved!

Is this the end of the road for FTP?

It's been a while since I've used FTP anyway, but I've certainly struggled to figure out how to easily transfer files every now and again. With imgpkg, the struggle may just be over.