Learn OpenStack - Swift (Object Storage Service)

#Introduction

After understanding block storage in episode 8, you now meet one more storage type that completes OpenStack: Swift, the Object Storage Service. If Cinder deals with mountable virtual hard disks, Swift deals with unstructured data — files, images, videos, backup archives — stored as objects with metadata.

Why does it deserve its own episode? Because the way object storage thinks is very different. There's no mount, no filesystem tree, no file locks. There are buckets/containers, objects, and keys. Episode 9 dissects that difference, Swift's architecture behind the scenes, and the practical operations of creating containers and uploading objects — including REST API access and temporary URLs.

#The Object Storage Concept

#Unbounded, Scalable Unstructured Data

Object storage stores data as objects — a combination of the data itself, metadata, and a unique identifier — inside containers. Its main strength is unbounded horizontal scalability: to add capacity you just add storage nodes, with no downtime and no limit on a single filesystem's size.

Container (bucket)
   ├── object: foto-2026.jpg  (metadata: content-type, size, date)
   ├── object: backup-db-08-10.sql
   └── object: video-presentasi.mp4

Each object is accessed by its identifier, not by a filesystem path. That's what makes Swift a great fit for continuously growing data: backups, archives, media, and assets.

#Comparing the Three Storage Types

OpenStack provides three storage types that complement each other:

Choose Cinder when you need a persistent disk for an instance, Swift when you're storing large unstructured files, and Manila when you need a filesystem shared by many instances at once — the topic of episode 10.

#Swift Architecture

#Swift Server Components

Swift is designed as a distributed system with four server roles:

• Proxy Server: the entry point for all requests, handling authentication and routing to storage.
• Account Server: manages the list of containers within an account.
• Container Server: manages the list of objects within a container.
• Object Server: stores the objects themselves on disk.

openstack object store account show

The output of openstack object store account show shows the number of containers, the number of objects, and the total bytes used in your project's account.

#Replication and Consistency Model

Swift uses eventual consistency and replication: every object is replicated to several nodes (usually 3 replicas) by the replicator process. If one node dies, the object remains available from other replicas. Adding new nodes automatically rebalances data without downtime — that's why Swift is so resilient for archival data.

#Swift Operations

#Creating Containers and Uploading Objects

openstack container create backup-data
openstack object create backup-data server-db-2026-08-10.sql
openstack object list backup-data

The openstack container create backup-data command creates a container, then openstack object create uploads a file into it. Objects can be extremely large — Swift automatically splits large files into segments.

openstack object save backup-data server-db-2026-08-10.sql
openstack object delete backup-data server-db-2026-08-10.sql

openstack object save downloads an object into the current directory, and openstack object delete deletes it. All of these are REST operations — the CLI is just a wrapper.

#Accessing Objects via REST API

Because Swift is a REST service, you can access objects directly with curl using a token:

TOKEN=$(openstack token issue -f value -c id)
curl -s -H "X-Auth-Token: $TOKEN" \
  https://openstack.example.com/v1/AUTH_project/backup-data/server-db-2026-08-10.sql

The openstack token issue -f value -c id command grabs a Keystone token for curl to use. The Swift REST URL follows the pattern /v1/AUTH_<project>/<container>/<object>.

#Temporary URLs

Giving access to an object without sharing a token is a problem solved by temporary URLs (TempURL). Swift creates a short-lived URL that already carries a signature:

openstack container set --property X-Container-Meta-Temp-URL-Key=rahasia123 backup-data
swift tempurl GET 3600 /v1/AUTH_project/backup-data/server-db-2026-08-10.sql rahasia123

swift tempurl produces a URL valid for 3600 seconds. This URL can be shared with anyone — perfect for file sharing or expiring download links.

#Summary

Episode 9 rounds out your storage knowledge: Swift stores unbounded, scalable unstructured data, conceptually different from Cinder and Manila, runs on a proxy, account, container, and object server architecture with replication, and is operated via the CLI and REST APIs including temporary URLs.

Key takeaways:

• Object storage stores unstructured data in containers with unique keys.
• Swift for archives and backups; Cinder for disks; Manila for shared filesystems.
• Four server roles: proxy, account, container, object.
• Replication provides high availability without downtime.
• openstack container create and openstack object create are the basic operations.
• TempURL shares object access without leaking tokens.

In episode 10, we'll cover Manila (Shared Filesystem Service) and Barbican (Key Manager) — providing NFS/CIFS shares that many instances can mount at once with CephFS and NFS-Ganesha backends, and managing secrets, encryption keys, and certificates through Barbican, integrated with Cinder volume encryption.