Ceph Object Gateway turns a Ceph storage cluster into an S3-compatible object endpoint. Deploying RGW with cephadm places the gateway daemons through the Ceph orchestrator, so object traffic lands on managed gateway hosts instead of manually maintained service units.

cephadm keeps RGW daemon settings in the monitor configuration database and tracks daemon placement as an orchestrated service. Use a single-cluster service name such as object, two gateway hosts, and a frontend port such as 8080 for the first endpoint; add a load balancer or DNS name in front of those hosts when applications need one stable address.

Start from a Ceph administration shell that already has /etc/ceph/ceph.conf and an admin keyring. A finished deployment shows rgw.object in ceph orch ls, running rgw.object.* daemons in ceph orch ps, and an HTTP response from the gateway listener before S3 users and buckets are created.

Steps to deploy Ceph Object Gateway with cephadm:

  1. Confirm the cluster accepts admin commands.
    $ ceph health
    HEALTH_OK

    Run the deployment from the same admin shell that will manage cephadm services. Resolve monitor, manager, or orchestrator errors before adding RGW daemons.
    Related: How to check Ceph cluster health

  2. List the hosts that can run gateway daemons.
    $ ceph orch host ls
    HOST        ADDR           LABELS  STATUS
    ceph-node1  192.0.2.21
    ceph-node2  192.0.2.22
    ceph-node3  192.0.2.23

    Choose hosts on the client-facing network that applications or a load balancer can reach. Do not place the gateway only on a host marked _no_schedule.

  3. Apply the RGW service to the selected hosts.
    $ ceph orch apply rgw object --placement="2 ceph-node1 ceph-node2" --port=8080
    Scheduled rgw.object update...

    Each ceph orch apply rgw object run replaces the desired service placement for rgw.object. Include the complete intended placement in the command, or export and reapply the service spec when changing it later.
    Related: How to manage Ceph services with cephadm

  4. Check the orchestrator service state.
    $ ceph orch ls --service_name rgw.object --refresh
    NAME        PORTS   RUNNING  REFRESHED  AGE  PLACEMENT
    rgw.object  ?:8080      2/2  12s ago    2m   count:2;ceph-node1;ceph-node2

    RUNNING should match the requested daemon count before client traffic is routed to the endpoint.

  5. List the running RGW daemons.
    $ ceph orch ps --service_name rgw.object --refresh
    NAME                         HOST        PORTS   STATUS        REFRESHED  AGE  VERSION
    rgw.object.ceph-node1.a1b2c3  ceph-node1  *:8080  running (2m)  8s ago     2m   20.2.2
    rgw.object.ceph-node2.d4e5f6  ceph-node2  *:8080  running (2m)  8s ago     2m   20.2.2
  6. Send an unauthenticated request to one gateway listener.
    $ curl -i http://ceph-node1.example.net:8080/
    HTTP/1.1 403 Forbidden
    Content-Type: application/xml
    Server: Ceph Object Gateway
    ##### snipped #####
    
    <Error>
      <Code>AccessDenied</Code>
      <Message>Access Denied</Message>
    </Error>

    An AccessDenied response from Ceph Object Gateway is enough for a listener smoke test because no S3 credential was sent. Create an RGW user and run a signed bucket test before giving the endpoint to an application.
    Related: How to create an S3 user in Ceph Object Gateway
    Related: How to test an S3 bucket on Ceph Object Gateway