We are pleased to announce the immediate availability of StorageOS 0.8.1. This release further simplifies the initial deployment process and adds multi-user management and access control.
Embedded KV Store
To simplify installation, we’ve incorporated the Key/Value (KV) store within the StorageOS container. StorageOS relies on a KV store to provide guaranteed consistency of the StorageOS configuration, and a robust mechanism for electing a single cluster scheduler as well as distributed locking.
Embedding the KV store within StorageOS removes the requirement for provisioning an external Consul KV cluster, making installation even easier. External KV stores are still supported, however we have deprecated Consul in favor of etcd, a mature, battle-tested implementation of the RAFT protocol.
Although Consul has served us well, we chose to switch to etcd for a number of reasons:
- embedded etcd is widely used and proven in products such as CockroachDB
- we implement a gossip protocol (SERF) for cluster state change detection, and Consul has its own tightly coupled
- authentication and access controls better suited to our use case
- strong community, with close ties to Kubernetes
No configuration is required to use the embedded KV Store. If you wish to provide your own etcd external store, set the KV_ADDR environment variable to the etcd address.
To simplify deployment of new clusters there is a new discovery service. The discovery service lets administrators pre-allocate a cluster which StorageOS nodes can register against and discover other nodes in the cluster. Without using the discovery service, the administrator would specify the hostnames or ip addresses of the initial cluster members.
You can choose whether to use our public discovery service or to run your own internal service. The code is open-source and available on GitHub. To allocate a new cluster, use the API or StorageOS CLI:
storageos cluster create --size 3
This returns a unique cluster identifier, such as 3d5918ee-7670-4574-96f4-9fa04afe0f6e. The first three nodes to start with CLUSTER_ID=3d5918ee-7670-4574-96f4-9fa04afe0f6e set will form the initial cluster, with subsequent nodes joining the cluster.
The public discovery service is only intended for initial cluster bootstrap and does not provide HA or persist data. Once a cluster has bootstrapped there is no dependency on the discovery service. We are working on functionality to better manage cluster membership including the ability to expand/reduce the initial cluster size. Until then, cluster sizes are fixed.
StorageOS now supports multiple users and authorization policies. Policies control a user’s (or group’s) access to the volumes and rules within one or more namespaces. This behavior mimics the ABAC functionality found in Kubernetes, and gives a simple but powerful way to control access to resources.
For example, to grant a team access to storage resources you might:
1. Create a namespace for the new project
storageos namespace create customer_portal
2. Create the team’s accounts, and add them to a project group
storageos user create --groups sre --role user anna storageos user create --groups sre --role user bob
3. Create a policy to grant the team access to the resources in the project namespace
storageos policy create --group sre --namespace customer_portal
Now only users anna or bob (or new users added to the sre group) will be able to create, mount or delete volumes in the customer_portal namespace.
Anonymous Usage and Stability Reports
We have also added opt-out anonymized usage reports. This information allows us to better understand how StorageOS is being used so that we can focus our efforts appropriately. We collect statistics such as the number of nodes, pools, volumes and rules within a cluster, and this information is sent to us when the cluster starts, and once daily thereafter. We also collect statistics on the type and frequency of API calls.
To opt-out of usage reporting, pass the environment variable DISABLE_TELEMETRY=true to the StorageOS container.
Get Started with StorageOS for Free
Author: Simon Croome
Simon’s background is in providing infrastructure solutions for financial services and government organizations. Simon is a co-founder of StorageOS, where he leads Engineering. He is focused on bringing enterprise-class storage capabilities to containerized environments.