volume

Last updated: 2025-11-05 01:15:11.578785 File source: link on GitLab

GlusterFS

Glusterfs client is now in its own image

I decided to put the glusterfs client in its own container instead of running mount -t glusterfs and installing the client on the host system.

There are 2 reasons:

  1. Linux distro compatibility (some distro's dont ship the same version and the mount command doesnt work)

  2. Most important, it isolates each glusterfs clients certificate/key in its own container

to build the image:

make build-nunet-glusterfs-client

load the fuse kernel module:

sudo modprobe fuse

it will create an image named: nunet-glusterfs-client

Server Configuration

Run glusterfs server container:

docker run --name gluster-server-container -v /sys/fs/cgroup:/sys/fs/cgroup:rw -d --privileged=true --net=host --cgroupns=host ghcr.io/gluster/gluster-containers:fedora

use docker exec to gain shell access to the container:

We need to make sure a glusterfs server is setup with proper keys. We need to generate x509 certificates for both server and clients to authenticate and encrypt transit data.

For server we generate:

For this test, we will be using the docker glusterfs container which is running in net=host mode, so we can use the host's hostname for now.

Replace CN=puthotnamehere with your hostname in the above command

Now we need to copy these certs to the glusterfs container at /etc/pki/tls

If openssl isnt available, create them on your machine and then copy them:

Deploy DMS to glusterfs container

Make sure glusterfs server container is started, and then copy the dms binary to the container :

Make sure you create key and caps before running dms

Make sure to start dms on the container with the following configuration:

Copy the /etc/pki/tls/glusterfs.pem file to ${storage_ca_directory}/glusterfs_nodes/ directory.

Explanation:

Each storage dms, has to keep the server pem files in one place so it can create a chain CA file and send it back to the clients when they create a volume. For this purpose inside storage_ca_directory we have the following:

On your host run another DMS instance that will connect to the dms we ran in the container

Note that we need to give this dms capabilities to run the following behaviours on the glusterfs dms:

Client Side

1. Generate glusterfs client key,certificate

here we are defining clientX as the Common name of the cert. We could use a key did here for example.

At this point we have the a directory where the clients certificates are stored.

2. Create a volume

On the host dms create a volume and obtain the CA file returned from the glusterfs dms.

Now if we go to the client certificate directory we should see one additional .ca file.

3. Start the volume

4.A. Reload gluster

For now, since we are not using a CA Root for the glusterfs server, each glusterfs is their own "Roots". We need to do one manual step which will be removed in future by introducing a Root Authority that will allow certificate of depth of more than 0 which means just by keeping the intermidiate certifivates we will be able to still verify the chain and no need each time to restart/reload.

On the glusterfs server

4.B. Run an allocation with storage

We can run an allocation with storage now:

The volume shows the requirements. We need to pass the the client auth data so it can read client certs and ca file we created earlier

after the allocation is started, go to the container and check the mount volume. Write to it and then go the the glususterfs container where the bricks storage directory is and observe the data.

4.C. Test manually without an ensemble

You can always run directly from your host:

and unomunt:

Other Notes

dms on the glusterfs config

When running e2e tests these should be availabe on the machine

Last updated