4 ms·

"Nomad 0.3.1 was released earlier today. In the next major release, we will focus on data volumes to enable Nomad to run more stateful applications." What is t

by jgrowl 11y ago

"Nomad 0.3.1 was released earlier today. In the next major release, we will focus on data volumes to enable Nomad to run more stateful applications." What is the current approach for dealing with persistent data?

cyphar 11y ago
Nomad has a "raw" execution mode where you can run arbitrary commands in your cluster (it can schedule more than just containers). Using this, you could run the Docker command you want with the right flags. This might include setting --volumes-from or whatever. But you shouldn't really be using persistent volumes on a node level (since the whole point is to be resilient to node deaths), so if you can hook it up to some networked and redundant storage you can access it anywhere in your cluster. In principle you can already do this, by making a volume plugin. I'm just interested to see how Nomad will deal with volume plugins.
markbnj 11y ago
Data is the remaining elephant in the room. Containers have made code and config ephemeral and trivially replicable. But then you get to data, which represents billions of actually valuable magnetized bits of platter or flipped nand gates or whatever. It's like butterflies and battleships. One approach, as another reply suggested, is to mount external volumes into the container, i.e. a persistent disk on GCP or Amazon EBS (or even a GCS or S3 bucket). This works, but of course the container, hosting the software that makes the data meaningful, is now bolted to a physical thing. It can no longer be moved, auto-scaled, etc. It can be monitored and restarted and you still get all the benefits of dependency isolation and repeatability. I'd still much, much rather run a DB this way than installing it directly onto an instance, but there's no use pretending that we can do with data what we can now do with code and config. It's still a cement block chained to our ankles.
phildougherty 11y ago
Not sure of the approach Nomad takes, if any, but generally speaking bind mounting from the host system into the container is the common approach. That allows you to attach network storage, or EBS, or whatever you're used to using, and having access to it from your containers pretty transparently. ContainerShip, has CodexD (https://github.com/containership/codexd https://github.com/containership/codexd) which creates subvolumes for your containers on the fly using ephemeral/host storage, and can stream the data around to other servers in the cluster if containers are relocated. (Disclosure: I'm a founder of ContainerShip)

by jgrowl 11y ago

cyphar 11y ago

Nomad has a "raw" execution mode where you can run arbitrary commands in your cluster (it can schedule more than just containers). Using this, you could run the Docker command you want with the right flags. This might include setting --volumes-from or whatever. But you shouldn't really be using persistent volumes on a node level (since the whole point is to be resilient to node deaths), so if you can hook it up to some networked and redundant storage you can access it anywhere in your cluster. In principle you can already do this, by making a volume plugin. I'm just interested to see how Nomad will deal with volume plugins.

markbnj 11y ago

Data is the remaining elephant in the room. Containers have made code and config ephemeral and trivially replicable. But then you get to data, which represents billions of actually valuable magnetized bits of platter or flipped nand gates or whatever. It's like butterflies and battleships. One approach, as another reply suggested, is to mount external volumes into the container, i.e. a persistent disk on GCP or Amazon EBS (or even a GCS or S3 bucket). This works, but of course the container, hosting the software that makes the data meaningful, is now bolted to a physical thing. It can no longer be moved, auto-scaled, etc. It can be monitored and restarted and you still get all the benefits of dependency isolation and repeatability. I'd still much, much rather run a DB this way than installing it directly onto an instance, but there's no use pretending that we can do with data what we can now do with code and config. It's still a cement block chained to our ankles.

phildougherty 11y ago

Not sure of the approach Nomad takes, if any, but generally speaking bind mounting from the host system into the container is the common approach. That allows you to attach network storage, or EBS, or whatever you're used to using, and having access to it from your containers pretty transparently. ContainerShip, has CodexD (https://github.com/containership/codexd https://github.com/containership/codexd) which creates subvolumes for your containers on the fly using ephemeral/host storage, and can stream the data around to other servers in the cluster if containers are relocated. (Disclosure: I'm a founder of ContainerShip)