This page documents environment variables for configuring AIStor to publish data to an HTTP webhook endpoint and trigger an Object Lambda function. See Transforms with Object Lambda for more complete documentation and tutorials on using these environment variables. Environment Variables You can specify multiple targets by appending a unique identifier _ID for each set of related settings.

AIStor’s Object Lambda enables developers to programmatically transform objects on demand. You can transform objects as needed for your use case, such as redacting personally identifiable information (PII), enriching data with information from other sources, or converting between formats. Overview An Object Lambda handler is a small code module that transforms the contents of an object and returns the results. Like Amazon S3 Object Lambda functions, you trigger an AIStor Object Lambda handler function with a GET request from an application. The handler retrieves the requested object from AIStor, transforms it, and returns the modified data back to AIStor to send to the original application. The original object remains unchanged.

The AIStor Security Token Service (STS) AssumeRoleWithLDAPIdentity API endpoint generates temporary access credentials using Active Directory or LDAP user credentials. This page documents the AIStor Server AssumeRoleWithLDAPIdentity endpoint. For instructions on implementing STS using an S3-compatible SDK, defer to the documentation for that SDK. The AIStor STS AssumeRoleWithLDAPIdentity API endpoint is modeled after the AWS AssumeRoleWithWebIdentity endpoint and shares certain request/response elements. This page documents the AIStor-specific syntax and links out to the AWS reference for all shared elements.

The mc version suspend command disables versioning on the specified bucket. Syntax Example The following command disables versioning for the mybucket bucket on the myminio AIStor deployment:

This page covers settings that control Information Lifecycle Management (ILM) for the AIStor process. You can establish or modify settings by defining: an environment variable on the host system prior to starting or restarting the AIStor Server. Refer to your operating system’s documentation for how to define an environment variable. a configuration setting using mc admin config set. If you define both an environment variable and the similar configuration setting, AIStor uses the environment variable value.

This page documents the steps necessary to initialize site replication between two AIStor deployments. The procedures assume at least two existing AIStor installations. Only one of the two sites can have any data at the time of setup. All other sites must be empty of buckets and objects. All sites must otherwise having the following matching configurations: AIStor Server version Key Management Server for Server-Side Encryption Identity Manager Ensure each peer site has a Load Balancer, Reverse Proxy, or similar network control plane component to handle routing connections to its AIStor Server nodes. Using a single node hostname for a peer site creates a single point of failure for site replication where replication can fail if that single node goes down.

AIStor supports publishing bucket notification events to a AMQP 0-9-1 service endpoint such as RabbitMQ. Prerequisites AMQP 0-9-1 service endpoint. AIStor relies on the https://github.com/streadway/amqp project for AMQP connectivity. The project is primarily tested against RabbitMQ deployments, though other AMQP 0-9-1-compatible services may also work. This procedure assumes a RabbitMQ deployment using the 0-9-1 protocol as the service endpoint.

The AIStor Batch Framework allows you to create, manage, monitor, and execute jobs using a YAML-formatted job definition file (a “batch file”). The batch jobs run directly on the AIStor deployment to take advantage of the server-side processing power without constraints of the local machine where you run the AIStor Client. The replicate batch job replicates objects from one AIStor deployment (the source deployment) to another AIStor deployment (the target deployment). The deployment specified as the alias becomes the ’local’ deployment for the purposes of replication.

AIStor supports publishing bucket notification events to a Kafka service endpoint. AIStor relies on the https://github.com/Shopify/sarama project for Kafka connectivity and shares that project’s Kafka support. See the sarama Compatibility and API stability section for more details. Prerequisites Kafka minimum versions and supported versions.

This tutorial deploys AIStor onto Kubernetes distributions that follow the upstream API and functionality. The steps in this procedure may work on forked Kubernetes distributions. This procedure requires the installation of Kubernetes operators and associated resources including CustomResourceDefinitions, Statefulsets, and secrets into new or existing namespaces. You must perform the operations in this procedure as a user that has broad permissions to create resources within multiple namespaces. Deploy AIStor using Helm This procedure documents installation on Kubernetes with the AIStor Helm Charts.