First of all GlusterFS is a userspace file system. Containers are designed for ‘user-space applications’ , Isn’t it? Once you containerize your user space application, you get many advantages, so GlusterFS containers.
If I quote the advantages of Container ( for ex: docker ) from this link:
Docker brings in an API for container management, an image format, and a possibility to use a remote registry for sharing containers. This scheme benefits both developers and system administrators with advantages such as:
Rapid application deployment – containers include the minimal runtime requirements of the application, reducing their size and allowing them to be deployed quickly.
Portability across machines – an application and all its dependencies can be bundled into a single container that is independent from the host version of Linux kernel, platform distribution, or deployment model. This container can be transferred to another machine that runs Docker and executed there without compatibility issues.
Version control and component reuse – you can track successive versions of a container, inspect differences, or roll-back to previous versions. Containers reuse components from the preceding layers, which makes them noticeably lightweight.
Sharing – you can use a remote repository to share your container with others. Red Hat provides a registry for this purpose, and it is also possible to configure your own private repository.
Lightweight footprint and minimal overhead – Docker images are typically very small, which facilitates rapid delivery and reduces the time to deploy new application containers.
Simplified maintenance – Docker reduces effort and risk of problems with application dependencies.
Apart from above, we closely work on Container Operating systems like “Atomic host” which designed as a container platform/OS to run your application containers, so GlusterFS can. It is not possible to use package managers like rpm and set up the system in your own way if you use this stripped container OSs. If we want to take advantage of these OSs, we have to be containerized.
If the application is in a container, we get many advantages which come with the container orchestration software like Kubernetes/Openshift. So, let Gluster take that advantage as well. For ex: if you deploy GlusterFS in a bare metal system there is no piece of code that monitors GlusterFS and if something goes wrong, admin intervention is required to bring it back, but if the gluster is containerized the orchestrator does it for you like any other application.
Let us look at the deployment part, if you have to deploy GlusterFS in a new Kubernetes/Openshift node, you don’t have to worry about the ‘preparation/setup’, ie Setting up the repositories, Installation of packages ..etc rather just label ( in case of DeamonSet deployment model in Kube/Openshift ) a node, You got new Gluster Node within seconds.
This list goes, but I have to stop.
I would like to wrap this article saying, the attempt of gluster containerization has been justified by the massive download of GlusterFS containers from docker hub.
https://hub.docker.com/r/gluster/gluster-centos/
