What if you do not consider one of the greatest advantages of containers to be an advantage to you? Many tout the stateless nature of containers as their single greatest feature. They start up, they accomplish their task, and they go away – no stateful storage necessary. Many within the container community consider a stateful container to be a violation of best practices.
And yet there is a growing desire by some to run stateful containers. One of the arguments for doing this is it allows development and production to use the exact same infrastructure. This makes it easier to move an app from development to test to production – something essential to a devops workflow. Unfortunately, however, limitations of Docker and its associated partners create difficulties for those wanting to do this.
It is toward this end that Nexenta developed NexentaEdge, which is deployed as containerized micro-services on shared nothing clusters of low cost industry standard servers running Linux, interconnected through 10 Gigabit Ethernet or higher. NexentaEdge can scale to hundreds of nodes in a single cluster with iSCSI block and object services with inline deduplication and compression, as well as unlimited snapshots and clones.
Customers can run their application containers on the same bare-metal servers that are acting as the NexentaEdge nodes. The containers can access the NexentaEdge storage via S3, OpenStack Swift APIs, or even Linux Native Block Devices. NexentaEdge also supports the ClusterHQ Flocker driver, which manages the relationship between storage resources and the containers that need them.
Flocker attempts to solve one of the problems with running staple containers. With a cluster of machines running Docker, a container could theoretically start in any one of the nodes. If it is a stateful container it needs access to its data volume. Flocker creates a one-to-one relationship between the container and a volume, and ensures that the relationship is created when the container starts up. In order for Flocker to work, however, each volume must be available in each node of the cluster. NexentaEdge makes this possible.
Containers require a high-performance networking switching topology. Because NexentaEdge runs as a container, this topology automatically configures upon installation. It is also possible to deploy it into an existing container infrastructure.
If you have a desire in using stateful containers, you will encounter a number of roadblocks: the Docker community, the documentation, websites about container best practices, and even limitations of Docker and associated applications. But if you are determined that stateful containers are appropriate for your infrastructure, it would seem that Flocker would be essential. Using a product like NexentaEdge, that is designed from the ground up to work with Flocker, makes perfect sense. If all stateful containers were this easy to configure and use, perhaps the community would feel differently about them.