1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
# docker-gluster-swift
docker-gluster-swift is to provide object interface for a Gluster volume.
Let us see how to run gluster-swift inside a docker container.
## Building
```bash
# docker build --rm --tag gluster-swift .
```
## Running
On the host machine, mount one or more gluster volumes under the directory
`/mnt/gluster-object` with mountpoint name being same as that of the volume.
For example, if you have two gluster volumes named `test` and `test2`, they
should be mounted at `/mnt/gluster-object/test` and `/mnt/gluster-object/test2`
respectively. This directory on the host machine containing all the individual
glusterfs mounts is then bind-mounted inside the container. This avoids having
to bind mount individual gluster volumes.
The same needs to be updated in etc/sysconfig/swift-volumes.
For example(in swift-volumes):
GLUSTER_VOLUMES='tv1'
Where tv1 is the volume name.
**Example:**
```bash
# docker run -d --privileged -v /sys/fs/cgroup/:/sys/fs/cgroup/:ro -p 8080:8080 -v /mnt/gluster-object:/mnt/gluster-object gluster-swift
```
If you have selinux set to enforced on the host machine, refer to the
Troubleshooting section below before running the container.
**Note:**
~~~
-d : Runs the container in the background.
-p : Publishes the container's port to the host port. They need not be the same.
If host port is omitted, a random port will be mapped. So you can run
multiple instances of the container, each serving on a different port on
the same host machine.
-v : Bind mount a host path inside the container.
-e : Set and pass environment variable. In our case, provide a list of volumes
to be exported over object inerface by setting GLUSTER_VOLUMES environment
variable.
~~~
### Custom deployment
You can provide your own configuration files and ring files and have the
swift processes running inside container use those. This can be done by
placing your conf files and ring files in a directory on your host machine
and then bind-mounting it inside the container at `/etc/swift`.
**Example:**
Assuming you have conf files and ring files present at `/tmp/swift` on the
machine, you can spawn the container as follows:
```bash
# docker run -d -p 8080:8080 -v /tmp/swift:/etc/swift -v /mnt/gluster-object:/mnt/gluster-object prashanthpai/gluster-swift:dev
```
If the host machine has SELinux set to enforced:
```bash
# chcon -Rt svirt_sandbox_file_t /tmp/swift
```
### Troubleshooting
**SELinux**
When a volume is bind mounted inside the container, you'll need blessings of
SELinux on the host machine. Otherwise, the application inside the container
won't be able to access the volume. Example:
```bash
[root@f24 ~]# docker exec -i -t nostalgic_goodall /bin/bash
[root@042abf4acc4d /]# ls /mnt/gluster-object/
ls: cannot open directory /mnt/gluster-object/: Permission denied
```
Ideally, running this command on host machine should work:
```bash
# chcon -Rt svirt_sandbox_file_t /mnt/gluster-object
```
However, glusterfs does not support setting of SELinux contexts [yet][1].
You can always set SELinux to permissive on host machine by running
`setenforce 0` or run container in privileged mode (`--privileged=true`).
I don't like either. A better workaround would be to mount the glusterfs
volumes on host machine as shown in following example:
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1252627
```bash
mount -t glusterfs -o selinux,context="system_u:object_r:svirt_sandbox_file_t:s0" `hostname`:test /mnt/gluster-object/test
```
### TODO
* Install gluster-swift from RPMs. (Currently installed from source)
|
