BindStore Quickstart Guide

BindStore is a High Performance Object Storage released under Apache License v2.0. It is API compatible with Amazon S3 cloud storage service. Use BindStore to build high performance infrastructure for machine learning, analytics and application data workloads.

This README provides quickstart instructions on running BindStore on baremetal hardware, including Docker-based installations. For Kubernetes environments, see the orchestration docs.

Docker Installation

Use the following commands to run a standalone BindStore server on a Docker container.

Standalone BindStore servers are best suited for early development and evaluation. Certain features such as versioning, object locking, and bucket replication require distributed deploying BindStore with Erasure Coding. For extended development and production, deploy BindStore with Erasure Coding enabled - specifically, with a minimum of 4 drives per BindStore server. See BindStore Erasure Code Quickstart Guide for more complete documentation.

Stable

Run the following command to run the latest stable image of BindStore on a Docker container using an ephemeral data volume:

docker run -p 9000:9000 bindoffice/bindstore server /data

The BindStore deployment starts using default root credentials bindadmin:bindadmin. You can test the deployment using the BindStore Browser, an embedded web-based object browser built into BindStore Server. Point a web browser running on the host machine to http://127.0.0.1:9000 and log in with the root credentials. You can use the Browser to create buckets, upload objects, and browse the contents of the BindStore server.

You can also connect using any S3-compatible tool, such as the MinIO Client mc commandline tool. See Test using MinIO Client mc for more information on using the mc commandline tool.

NOTE: To deploy BindStore on Docker with persistent storage, you must map local persistent directories from the host OS to the container using the docker -v option. For example, -v /mnt/data:/data maps the host OS drive at /mnt/data to /data on the Docker container.

Edge

Run the following command to run the bleeding-edge image of BindStore on a Docker container using an ephemeral data volume:

docker run -p 9000:9000 bindoffice/bindstore:edge server /data

The BindStore deployment starts using default root credentials bindadmin:bindadmin. You can test the deployment using the BindStore Browser, an embedded web-based object browser built into BindStore Server. Point a web browser running on the host machine to http://127.0.0.1:9000 and log in with the root credentials. You can use the Browser to create buckets, upload objects, and browse the contents of the BindStore server.

You can also connect using any S3-compatible tool, such as the MinIO Client mc commandline tool. See Test using MinIO Client mc for more information on using the mc commandline tool.

NOTE: To deploy BindStore on Docker with persistent storage, you must map local persistent directories from the host OS to the container using the docker -v option. For example, -v /mnt/data:/data maps the host OS drive at /mnt/data to /data on the Docker container.

macOS

Use the following commands to run a standalone BindStore server on macOS.

Standalone BindStore servers are best suited for early development and evaluation. Certain features such as versioning, object locking, and bucket replication require distributed deploying BindStore with Erasure Coding. For extended development and production, deploy BindStore with Erasure Coding enabled - specifically, with a minimum of 4 drives per BindStore server. See BindStore Erasure Code Quickstart Guide for more complete documentation.

Build from Source (recommended)

Clone the repository and build BindStore. Replace /data with the path to the drive or directory in which you want BindStore to store data.

git clone https://github.com/bindoffice/bindstore.git
cd bindstore
make
./bindstore server /data

The BindStore deployment starts using default root credentials bindadmin:bindadmin. You can test the deployment using the BindStore Browser, an embedded web-based object browser built into BindStore Server. Point a web browser running on the host machine to http://127.0.0.1:9000 and log in with the root credentials. You can use the Browser to create buckets, upload objects, and browse the contents of the BindStore server.

You can also connect using any S3-compatible tool, such as the MinIO Client mc commandline tool. See Test using MinIO Client mc for more information on using the mc commandline tool.

GNU/Linux

Use the following command to build and run a standalone BindStore server on Linux hosts. Replace /data with the path to the drive or directory in which you want BindStore to store data.

git clone https://github.com/bindoffice/bindstore.git
cd bindstore
make
./bindstore server /data

Replace /data with the path to the drive or directory in which you want BindStore to store data.

The BindStore deployment starts using default root credentials bindadmin:bindadmin. You can test the deployment using the BindStore Browser, an embedded web-based object browser built into BindStore Server. Point a web browser running on the host machine to http://127.0.0.1:9000 and log in with the root credentials. You can use the Browser to create buckets, upload objects, and browse the contents of the BindStore server.

You can also connect using any S3-compatible tool, such as the MinIO Client mc commandline tool. See Test using MinIO Client mc for more information on using the mc commandline tool.

NOTE: Standalone BindStore servers are best suited for early development and evaluation. Certain features such as versioning, object locking, and bucket replication require distributed deploying BindStore with Erasure Coding. For extended development and production, deploy BindStore with Erasure Coding enabled - specifically, with a minimum of 4 drives per BindStore server. See BindStore Erasure Code Quickstart Guide for more complete documentation.

Microsoft Windows

Use the following commands to build and run a standalone BindStore server on 64-bit Windows hosts. Replace D:\ with the path to the drive or directory in which you want BindStore to store data:

git clone https://github.com/bindoffice/bindstore.git
cd bindstore
go build -o bindstore.exe
bindstore.exe server D:\

The BindStore deployment starts using default root credentials bindadmin:bindadmin. You can test the deployment using the BindStore Browser, an embedded web-based object browser built into BindStore Server. Point a web browser running on the host machine to http://127.0.0.1:9000 and log in with the root credentials. You can use the Browser to create buckets, upload objects, and browse the contents of the BindStore server.

You can also connect using any S3-compatible tool, such as the MinIO Client mc commandline tool. See Test using MinIO Client mc for more information on using the mc commandline tool.

NOTE: Standalone BindStore servers are best suited for early development and evaluation. Certain features such as versioning, object locking, and bucket replication require distributed deploying BindStore with Erasure Coding. For extended development and production, deploy BindStore with Erasure Coding enabled - specifically, with a minimum of 4 drives per BindStore server. See BindStore Erasure Code Quickstart Guide for more complete documentation.

Install from Source

Use the following commands to compile and run a standalone BindStore server from source. Source installation is only intended for developers and advanced users. If you do not have a working Golang environment, please follow How to install Golang. Minimum version required is go1.16

git clone https://github.com/bindoffice/bindstore.git
cd bindstore
make
./bindstore server /data

The BindStore deployment starts using default root credentials bindadmin:bindadmin. You can test the deployment using the BindStore Browser, an embedded web-based object browser built into BindStore Server. Point a web browser running on the host machine to http://127.0.0.1:9000 and log in with the root credentials. You can use the Browser to create buckets, upload objects, and browse the contents of the BindStore server.

You can also connect using any S3-compatible tool, such as the MinIO Client mc commandline tool. See Test using MinIO Client mc for more information on using the mc commandline tool.

NOTE: Standalone BindStore servers are best suited for early development and evaluation. Certain features such as versioning, object locking, and bucket replication require distributed deploying BindStore with Erasure Coding. For extended development and production, deploy BindStore with Erasure Coding enabled - specifically, with a minimum of 4 drives per BindStore server. See BindStore Erasure Code Quickstart Guide for more complete documentation.

BindStore strongly recommends against using compiled-from-source BindStore servers for production environments.

Deployment Recommendations

Allow port access for Firewalls

By default BindStore uses the port 9000 to listen for incoming connections. If your platform blocks the port by default, you may need to enable access to the port.

ufw

For hosts with ufw enabled (Debian based distros), you can use ufw command to allow traffic to specific ports. Use below command to allow access to port 9000

ufw allow 9000

Below command enables all incoming traffic to ports ranging from 9000 to 9010.

ufw allow 9000:9010/tcp

firewall-cmd

For hosts with firewall-cmd enabled (CentOS), you can use firewall-cmd command to allow traffic to specific ports. Use below commands to allow access to port 9000

firewall-cmd --get-active-zones

This command gets the active zone(s). Now, apply port rules to the relevant zones returned above. For example if the zone is public, use

firewall-cmd --zone=public --add-port=9000/tcp --permanent

Note that permanent makes sure the rules are persistent across firewall start, restart or reload. Finally reload the firewall for changes to take effect.

firewall-cmd --reload

iptables

For hosts with iptables enabled (RHEL, CentOS, etc), you can use iptables command to enable all traffic coming to specific ports. Use below command to allow access to port 9000

iptables -A INPUT -p tcp --dport 9000 -j ACCEPT
service iptables restart

Below command enables all incoming traffic to ports ranging from 9000 to 9010.

iptables -A INPUT -p tcp --dport 9000:9010 -j ACCEPT
service iptables restart

Pre-existing data

When deployed on a single drive, BindStore server lets clients access any pre-existing data in the data directory. For example, if BindStore is started with the command bindstore server /mnt/data, any pre-existing data in the /mnt/data directory would be accessible to the clients.

The above statement is also valid for all gateway backends.

Test BindStore Connectivity

Test using BindStore Browser

BindStore Server comes with an embedded web based object browser. Point your web browser to http://127.0.0.1:9000 to ensure your server has started successfully.

Test using MinIO Client mc

mc provides a modern alternative to UNIX commands like ls, cat, cp, mirror, diff etc. It supports filesystems and Amazon S3 compatible cloud storage services. Follow the MinIO Client Quickstart Guide for further instructions.

Upgrading BindStore

BindStore server supports rolling upgrades, i.e. you can update one BindStore instance at a time in a distributed cluster. This allows upgrades with no downtime. Upgrades can be done manually by replacing the binary with the latest release and restarting all servers in a rolling fashion. However, we recommend all our users to use mc admin update from the client. This will update all the nodes in the cluster simultaneously and restart them, as shown in the following command from the MinIO client (mc):

mc admin update <bindstore alias, e.g., mybindstore>

NOTE: some releases might not allow rolling upgrades, this is always called out in the release notes and it is generally advised to read release notes before upgrading. In such a situation mc admin update is the recommended upgrading mechanism to upgrade all servers at once.

Important things to remember during BindStore upgrades

• mc admin update will only work if the user running BindStore has write access to the parent directory where the binary is located, for example if the current binary is at /usr/local/bin/bindstore, you would need write access to /usr/local/bin.
• mc admin update updates and restarts all servers simultaneously, applications would retry and continue their respective operations upon upgrade.
• mc admin update is disabled in kubernetes/container environments, container environments provide their own mechanisms to rollout of updates.
• In the case of federated setups mc admin update should be run against each cluster individually. Avoid updating mc to any new releases until all clusters have been successfully updated.
• If using kes as KMS with BindStore, just replace the binary and restart kes more information about kes can be found here
• If using Vault as KMS with BindStore, ensure you have followed the Vault upgrade procedure outlined here: https://www.vaultproject.io/docs/upgrading/index.html
• If using etcd with BindStore for the federation, ensure you have followed the etcd upgrade procedure outlined here: https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrading-etcd.md

Explore Further

• BindStore Erasure Code QuickStart Guide
• Use mc with BindStore Server
• Use aws-cli with BindStore Server
• Use s3cmd with BindStore Server
• Distributed BindStore
• BindStore documentation

Contribute to BindStore Project

Please follow BindStore Contributor's Guide

License

Use of BindStore is governed by the Apache 2.0 License found at LICENSE.