Digi Containers: The Best Way to Build, Deploy and Manage Custom Applications

Nate: That's a really good question. We offer the ability for both. On the Digi Containers SDK page, we have a list of pre-built template containers that can get you started, using some common containerized applications that customers or users have requested. So, that's a good way to get started. Those same templates can be also loaded in Digi Remote Manager®. So, when you look at your device for the first time, if you're getting the device first set up in Remote Manager, it can show you those templates to select from, and you can get started with that. But the more common use case we see is a lot of people have custom applications, or they want to get started with using their own application and container.

So, they want to completely customize it. So again, that SDK tool can help you get started with a step-by-step walkthrough of getting your application compiled if needed. Or if you already have a Docker or LXC containerized application, you can get that loaded and started, using that on your Digi device.

Nate: Digi devices run the gamut as far as size of product. So, we have a product with a single Ethernet port and a single serial port, with a cell connection, all the way to, like Kyle mentioned earlier, we have console servers that have 48 serial ports and multiple Ethernet and cellular connections together, and meant to be installed in a server rack. So, fairly large products. And with that, there are many different types of CPU architectures and memory and disk space available on each of those products from the small size to the large.

The majority of them run similar CPU architectures. The benefit of that is, if you have an LXC container, and you have a custom binary application that's compiled to run on an Arm PC, that can then be ported and run across multiple Digi device types that have the same CPU and internal inside of it. It makes it very portable across multiple Digi products. And furthermore, the LXC containerized technology itself doesn't have any CPU-specific calls. So, unless you have a custom application that is built for a certain CPU architecture, if you're just using this for extra scripting or Python capabilities or other applications like that, the container itself can then be ported across any of the Digi devices because the LXC container itself is just a way to port that onto any device.

Kyle: Yes. So, Binary Armor has full individual user accounts, so you can set up as many as you need, and you can assign them individual permissions. If you want someone able to change settings of the Binary Armor itself, but not change operation settings, you have the controls to be able to fine-tune to meet your organization's needs.

Kyle: There are a few ways that Binary Armor notifies you, depending on if you're in the operations group or in security. Binary Armor has the ability to send out alerts. So, what we saw in the demo, of feeding back to a user interface… That whole user interface is based off of an HTTP API, so we can pull that into a number of different operation toolkits to be able to display that information to wherever the operation users are. Also, if there is an interface such as the Node-RED one that we were running in that demo, we could add in a notification of the mode to Binary Armor into that demonstration itself, as a second data channel.

From a security perspective, our information is all logged out to wherever you have a log collection or a SIEM in security. So, if you are running a security operations center, this information will feed that security operations center, where you're also able to see alerts of what's going on with a little bit more detail so you can dive into the forensics of what actually happened on the network. Is it someone just didn't call, or is it something malicious is potentially happening?

Nate: On the Digi device, when you load a container, how much CPU and memory it utilizes is based off the applications that are running inside the container. The LXC container itself is very, very small. We're talking, to have a basic test LXC container that is just the wrapper for your current Linux kernel environment, it's a few kilobytes in size, because it's sharing that host CPU architecture, so there's a lot of ability for it to run really lightweight and lean for getting the LXC container started. So, again, how much CPU and memory you need is based off of what your application is running, and its system requirements.

Beyond that, though, the container itself can share resources on the device beyond just memory and CPU, such as things like the networking. So, you can tie that container within a certain segment of a network that the Digi device has access to. So, it could be a VLAN, it could be part of a Wi-Fi network, or in anything thereof that the Digi device has access to, networking-wise, that can be exposed to the container.

We can also expose serial ports, which is exactly the demo Kyle showed with Binary Armor — giving direct access to the serial ports on the Digi device to the container, so it can control the data flowing into and out of it. And then there's also shared local file system storage. So, whether it's the amount of local file system access on the Digi router itself, or if there's some USB storage that's added to the Digi device, that can also be shared as shared directories, or you can give control over to the container so it has access for expanded disk storage, if needed.