Configuration Directory
Till MinIO release RELEASE.2018-08-02T23-11-36Z, MinIO server configuration file (config.json) was stored in the configuration directory specified by --config-dir or defaulted to ${HOME}/.minio. However from releases after RELEASE.2018-08-18T03-49-57Z, the configuration file (only), has been migrated to the storage backend (storage backend is the directory passed to MinIO server while starting the server).
You can specify the location of your existing config using --config-dir, MinIO will migrate the config.json to your backend storage. Your current config.json will be renamed upon successful migration as config.json.deprecated in your current --config-dir. All your existing configurations are honored after this migration.
Additionally --config-dir is now a legacy option which will is scheduled for removal in future, so please update your local startup, ansible scripts accordingly.
MinIO also encrypts all the config, IAM and policies content if KMS is configured. Please refer to how to encrypt your config and IAM credentials here
Certificate Directory
If you’ve ever lost an important document or file you know how essential timely and reliable backups are. Getting backups done effeciently can prove to be challenge however, especially on Linux where a dozen different tools exist and do a variation on the same theme. Replace all instances of and with a random access and secret key respectively (only verified by the MinIO service) Getting GCP credentials Now we must connect MinIO to GCS (if you decided to use some other storage provider, have a look at the Minio documentation).
TLS certificates by default are stored under ${HOME}/.minio/certs directory. You need to place certificates here to enable HTTPS based access. Read more about How to secure access to MinIO server with TLS.
Following is the directory structure for MinIO server with TLS certificates.
You can provide a custom certs directory using --certs-dir command line option.
Credentials
On MinIO admin credentials or root credentials are only allowed to be changed using ENVs namely MINIO_ROOT_USER and MINIO_ROOT_PASSWORD. Using the combination of these two values MinIO encrypts the config stored at the backend.
Region
or environment variables
Example:
Storage Class
By default, parity for objects with standard storage class is set to N/2, and parity for objects with reduced redundancy storage class objects is set to 2. Read more about storage class support in MinIO server here.
or environment variables
Cache
MinIO provides caching storage tier for primarily gateway deployments, allowing you to cache content for faster reads, cost savings on repeated downloads from the cloud.
or environment variables
Etcd
MinIO supports storing encrypted IAM assets and bucket DNS records on etcd.
NOTE: if path_prefix is set then MinIO will not federate your buckets, namespaced IAM assets are assumed as isolated tenants, only buckets are considered globally unique but performing a lookup with a bucket which belongs to a different tenant will fail unlike federated setups where MinIO would port-forward and route the request to relevant cluster accordingly. This is a special feature, federated deployments should not need to set path_prefix.
or environment variables
API
By default, there is no limitation on the number of concurrent requests that a server/cluster processes at the same time. However, it is possible to impose such limitation using the API subsystem. Read more about throttling limitation in MinIO server here.
or environment variables
Notifications
Notification targets supported by MinIO are in the following list. To configure individual targets please refer to more detailed documentation here
Accessing configuration
All configuration changes can be made using mc admin config get/set/reset/export/import commands.
List all config keys available
Obtain help for each key
e.g: mc admin config set myminio/ etcd returns available etcd config args
To get ENV equivalent for each config args use --env flag
This behavior is consistent across all keys, each key self documents itself with valid examples.
Dynamic systems without restarting server
The following sub-systems are dynamic i.e., configuration parameters for each sub-systems can be changed while the server is running without any restarts.
NOTE: if you set any of the following sub-system configuration using ENVs, dynamic behavior is not supported.
Usage scanner
Data usage scanner is enabled by default. The following configuration settings allow for more staggered delay in terms of usage calculation. The scanner adapts to the system speed and completely pauses when the system is under load. It is possible to adjust the speed of the scanner and thereby the latency of updates being reflected. The delays between each operation of the scanner can be adjusted by the mc admin config set alias/ delay=15.0. By default the value is 10.0. This means the scanner will sleep 10x the time each operation takes.
In most setups this will keep the scanner slow enough to not impact overall system performance. Setting the delay key to a lower value will make the scanner faster and setting it to 0 will make the scanner run at full speed (not recommended in production). Setting it to a higher value will make the scanner slower, consuming less resources with the trade off of not collecting metrics for operations like healing and disk usage as fast.
Example: Following setting will decrease the scanner speed by a factor of 3, reducing the system resource use, but increasing the latency of updates being reflected.
Once set the scanner settings are automatically applied without the need for server restarts.
NOTE: Data usage scanner is not supported under Gateway deployments.
Healing
Healing is enabled by default. The following configuration settings allow for more staggered delay in terms of healing. The healing system by default adapts to the system speed and pauses up to '1sec' per object when the system has max_io number of concurrent requests. It is possible to adjust the max_delay and max_io values thereby increasing the healing speed. The delays between each operation of the healer can be adjusted by the mc admin config set alias/ max_delay=1s and maximum concurrent requests allowed before we start slowing things down can be configured with mc admin config set alias/ max_io=30 . By default the wait delay is 1sec beyond 10 concurrent operations. This means the healer will sleep 1 second at max for each heal operation if there are more than 10 concurrent client requests.
In most setups this is sufficient to heal the content after drive replacements. Setting max_delay to a lower value and setting max_io to a higher value would make heal go faster.
Example: The following settings will increase the heal operation speed by allowing healing operation to run without delay up to 100 concurrent requests, and the maximum delay between each heal operation is set to 300ms.
Once set the healer settings are automatically applied without the need for server restarts.
NOTE: Healing is not supported under Gateway deployments.
Environment only settings (not in config)
Browser
Enable or disable access to web UI. By default it is set to on. You may override this field with MINIO_BROWSER environment variable.
Example:
Domain
Minio Generate Random Access Key Generator
By default, MinIO supports path-style requests that are of the format http://mydomain.com/bucket/object. MINIO_DOMAIN environment variable is used to enable virtual-host-style requests. If the request Host header matches with (.+).mydomain.com then the matched pattern $1 is used as bucket and the path is used as object. More information on path-style and virtual-host-style here
Example:
For advanced use cases MINIO_DOMAIN environment variable supports multiple-domains with comma separated values.