Build radosgw with civet web instead of apache about ceph-container

[Ulexus]

+1 ; I'm all for reducing the glut from Apache

[leseb]

@Ulexus Actually I believe that some people (for some reasons) might want to keep apache.
Should we maintain both?

[Ulexus]

The nature of the present container is such that it is not particularly flexible, apache or otherwise. It's basically a black box which provides the API. As such, what web server is used is largely irrelevant, outside of system resource usage.

That said, it would probably be a good idea to provide an option for a broken-out radosgw without the web server, thus allowing one to plug in whatever web server you wanted. I haven't looked at radosgw enough to know how feasible this is. Is the interface plain CGI, FastCGI, or something else?

[leseb]

Maybe we can set a new var while bootstrapping the container, something like this:

docker run -e RGW_FRONTED=civetweb -e RGW_NAME=myrgw ceph/radosgw

Then in the entrypoint we can do the appropriate setup of the vhost or not.
The only problem is that apache will remain install and if we use civet web we don't want it...
The civet web thing is embedded into the radosgw process.

[Ulexus]

I would say that problem is emblematic of my root complaint.

In the primary use case (as I see it), the user merely wants a functional radosgw, and they don't really care what is underneath the hood, be it Apache, nginx, etc., except in as much as it takes greater or fewer resources.

In the (theoretical, for me) secondary use case, the user wants to integrate radosgw into their existing web service model. Using a reverse proxy is the usual approach to this: segments off some namespace to direct requests to the radosgw. In this case, the implementation is the same as the primary use case: radosgw API service is just a black box that serves requests. If, however, you say, "I've already got a webserver. Why can't I integrate radosgw into my existing webserver?" you get to this secondary use case.

I don't know what demand there is for this, if any, but the natural approach is to allow access to radosgw from a common endpoint. In this case, that endpoint is the FastCGI socket. The idea is that we have, say radosgw-socket, which merely runs radosgw and exposes its FastCGI socket.

Normally, you would use a unix socket for this (because it is slightly faster), but that is not as clean, in Docker-space, as a TCP socket. Unfortunately, it doesn't look like radosgw supports anything other than a unix socket, so that means we'll have to expose the socket as a file, in some way.

We could have something like:

: ${RGW_WEB_ENABLE:=1}
: ${RGW_SOCKET_PATH:=/data/radosgw.socket}

(Where /data is defined as a volume in the Dockerfile, perhaps.)

This would allow the user to access the socket themselves. If they set RGW_WEB_ENABLE=0, the web server would not be started, but radosgw would. Then, they can mess with the socket or provide their own socket path, as necessary.

[yehudasa]

----- Original Message -----

From: "Seán C. McCord" [email protected]
To: "ceph/ceph-docker" [email protected]
Sent: Friday, February 27, 2015 7:56:39 AM
Subject: Re: [ceph-docker] Build radosgw with civet web instead of apache (#26)

I would say that problem is emblematic of my root complaint.

In the primary use case (as I see it), the user merely wants a functional
radosgw, and they don't really care what is underneath the hood, be it
Apache, nginx, etc., except in as much as it takes greater or fewer
resources.

In the (theoretical, for me) secondary use case, the user wants to integrate
radosgw into their existing web service model. Using a reverse proxy is the
usual approach to this: segments off some namespace to direct requests to
the radosgw. In this case, the implementation is the same as the primary
use case: radosgw API service is just a black box that serves requests.
If, however, you say, "I've already got a webserver. Why can't I integrate
radosgw into my existing webserver?" you get to this secondary use case.

I don't know what demand there is for this, if any, but the natural approach
is to allow access to radosgw from a common endpoint. In this case, that
endpoint is the FastCGI socket. The idea is that we have, say
radosgw-socket, which merely runs radosgw and exposes its FastCGI socket.

Normally, you would use a unix socket for this (because it is slightly
faster), but that is not as clean, in Docker-space, as a TCP socket.
Unfortunately, it doesn't look like radosgw supports anything other than a
unix socket, so that means we'll have to expose the socket as a file, in

radosgw does support tcp for fastcgi:

    rgw socket path = ""
    rgw frontends = fastcgi socket_port=9000 socket_host=0.0.0.0

You could also provide multiple frontends, e.g., have both fastcgi and civetweb on the same radosgw instance.

Yehuda

some way.

We could have something like:

: ${RGW_WEB_ENABLE:=1}
: ${RGW_SOCKET_PATH:=/data/radosgw.socket}

(Where /data is defined as a volume in the Dockerfile, perhaps.)

This would allow the user to access the socket themselves. If they set
RGW_WEB_ENABLE=0, the web server would not be started, but radosgw would.
Then, they can mess with the socket or provide their own socket path, as
necessary.

---

Reply to this email directly or view it on GitHub:
#26 (comment)

[Ulexus]

@yehudasa Is there a way to specify the tcp bindings as CLI parameters? It is presumed /etc/ceph/ceph.conf is supplied (and should, therefore, not be written to). Trying to parse the port from ceph.conf and exposing that same port from docker is a chicken-and-egg problem.

[yehudasa]

@Ulexus --rgw-socket-path="" --rgw-frontends="fastcgi socket_port=9000 socket_host=0.0.0.0, civetweb port=8888"

[Ulexus]

@yehudasa Perfect, thanks!

@leseb Is that enough for you to go on (jumbled as my thoughts were)?

The idea, then, is that you can run radosgw as either a standalone TCP-connected FastCGI service or you can run it with the bundled webserver.

That should be nicely flexible, and we can then provide a container which has only the radosgw service and no webserver.

[leseb]

I guess it's clear, I just thought that using RGW_WEB_ENABLE might be easier for end users than RGW_FRONTED where they have to chose between Apache and civet web.

[Ulexus]

I think we're on the same page, then. I agree: for the builtin webserver (whichever is chosen), then system should be opinionated (user has no choice). However, the web server should not have to be bundled, in which case, the user can decide and supply their own, using a common CGI interface.

[leseb]

Ok it's clearer now.
So in practice we will have another container that runs let say Apache and then we can connect our rgw container to this tcp socket.

[Ulexus]

Exactly

On Wed, Mar 4, 2015 at 9:33 AM Leseb [email protected] wrote:

Ok it's clearer now.
So in practice we will have another container that runs let say Apache and
then we can connect our rgw container to this tcp socket.

—
Reply to this email directly or view it on GitHub
#26 (comment).

[Ulexus]

Tested and merged; thanks!