Configuration¶

The service allowed two variants of configuration:

use the Configurator service

use the configuration file

The service reads settings from the configuration file by default.

You can specify the –luna-config option for pulling settings from the Configurator service, see configurator.

Auto reload configuration¶

The service supports an auto-reload of configurations. You can enable this feature by specifying a config-reload option in the command line. The service periodically checks new settings. If current settings and new pulled settings are the same the service will not perform any actions. You can specify the check period in the pulling-time command line argument (10 seconds by default).

If a configuration fetching has failed, the service will work without applying any changes to the existing configurations.

If check connections with the new configuration have failed, the service will retry pulling new configuration after pulling-time seconds. The service will shut down after 10 failed attempts.

Warning

Service can work incorrectly while the new settings are being applied. It is strongly recommended not to send requests to the service when you change important settings (database configuration, work plugins list, and others).

Configuration file for administrator¶

# LUNA Image Store configurator file

[LUNA_CONFIGURATOR]
#: [integer] load configs from LUNA Configurator
USE_CONFIGURATOR = 0
#: [string] LUNA Configurator protocol, IP address, and port
LUNA_CONFIGURATOR_ORIGIN = http://127.0.0.1:5070
#: [integer] API version of the LUNA Configurator
LUNA_CONFIGURATOR_API  = 1


[LUNA_BUILDER_LOGGER]

#: [string] folder, where logs are saved (relative path begins in directory with application)
FOLDER_WITH_LOGS = ./
#: [string] level of debug print, by priority: "ERROR", "WARNING", "INFO", "DEBUG"
LOG_LEVEL = INFO
#: [string] time format used in log records: "LOCAL" or "UTC"
LOG_TIME = LOCAL
#: [integer] maximum log file size in megabytes before performing rotation (0 - without rotation)
MAX_LOG_FILE_SIZE = 1024
#: send log to stdout
LOG_TO_STDOUT = 1
#: send log to file
LOG_TO_FILE = 0
#: allow multiline stack trace in logs
MULTILINE_STACK_TRACE = 1

[LUNA_MONITORING]

#: [string] storage type
STORAGE_TYPE = influx
#: [integer] Whether to send data for monitoring
SEND_DATA_FOR_MONITORING = 1
#: [string] InfluxDB 2.x workspace
ORGANIZATION = luna
#: [string] InfluxDB 2.x authentication token
TOKEN = kofqt4Pfqjn6o0RBtMDQqVoJLgHoxxDUmmhiAZ7JS6VmEnrqZXQhxDhad8AX9tmiJH6CjM7Y1U8p5eSEocGzIA==
#: [string] InfluxDB 2.x bucket name
BUCKET = luna_monitoring
#: [string] Monitoring database IP address
HOST = 127.0.0.1
#: [integer] Monitoring database port
PORT = 8086
#: [integer] Whether to use HTTPS to connect to Monitoring database
USE_SSL = 0
#: [integer] frequency of sending monitoring data to the database (in seconds)
FLUSHING_PERIOD = 1

[LUNA_BUILDER_HTTP_SETTINGS]
#: web server http settings

#: [integer] service request timeout (in seconds)
REQUEST_TIMEOUT = 60
#: [integer] service response timeout (in seconds)
RESPONSE_TIMEOUT = 600
#: [integer] max request size (in bytes), default ~130gb
REQUEST_MAX_SIZE = 137438953472
#: [integer] service http keep-alive timeout (in seconds)
KEEP_ALIVE_TIMEOUT = 15

[LUNA_BUILDER_S3]
HOST = http://192.168.49.2:30900
#: S3 public access key
AWS_PUBLIC_ACCESS_KEY = qa-team
#: S3 secret access key
AWS_SECRET_ACCESS_KEY = qa-secret
#: S3 public access key
BUCKET = test-plugins
#: S3 region
REGION = eu-central-1

[CLUSTER_CREDENTIALS]
#: cluster host
HOST = https://127.0.0.1:6443
#: access token
TOKEN = token
#: path to ssl certificate
CERTIFICATE_PATH = ./cert.crt

[LUNA_BUILDER_BUILD_LIMITS]

#: cpu limit
CPU_LIMIT=2000
#: ram limit
RAM_LIMIT=4
#: cpu request
CPU_REQUEST=500
#: ram request
RAM_REQUEST=0.5

[REGISTRY_TIMEOUTS]

#: [integer] HTTP connection timeout
CONNECT = 30
#: [integer] HTTP request timeout (total)
REQUEST = 300


[LUNA_SERVICE_METRICS]

#: [int] whether to enable /metrics path and statistics collection
ENABLED = 0
# [string] statistics data format (prometheus is the only option yet)
METRICS_FORMAT = prometheus

[LUNA_BUILDER_REDIS_DB_ADDRESS]

#: redis host for the service subscription
HOST = 127.0.0.1
#: redis port for the service subscription
PORT = 6379
#: [string] redis username for the service subscription
USER =
#: redis password for the service subscription
PASSWORD =
#: [integer] Redis database number (0-15)
NUMBER = 0


[LUNA_BUILDER_REDIS_DB_ADDRESS.SENTINEL]
#: [string] sentinel master name
MASTER_NAME = luna_builder
#: [list(string)] list of Redis Sentinel listeners (example [127.0.0.1:26379, 10.0.4.1:26379]).
#: By setting this parameter, application will query Redis parameters (host and port) from sentinels
SENTINELS = []
#: [string] sentinel username
USER =
#: [string] sentinel password
PASSWORD =

[LUNA_SERVICE_METRICS.EXTRA_LABELS]


[OTHER]

#: [string] type of storage: "S3" or "LOCAL", where "LOCAL" is HDD
STORAGE_TYPE = LOCAL
#: [string] folder, where images are stored (relative path begins in directory with application)
LOCAL_STORAGE = ./local_storage
#: [list(string)] list of active plugins
LUNA_BUILDER_ACTIVE_PLUGINS = []
#: k8s cluster location: remote/local(executed on same machine)/internal(executed in cluster)
CLUSTER_LOCATION = local
#: registry
LUNA_BUILDER_REGISTRY = lambdas-registry.vlabs
#: insecure registries
LUNA_BUILDER_INSECURE_REGISTRIES = [lambdas-registry.vlabs, registry.vlabs:5000]
#: use kubernetes or not
USE_KUBERNETES = 1

Extended administrator configuration¶

Configuration requirements¶

There are several parameters that are responsible for interacting with the kubernetes cluster.

If set USE_KUBERNETES = 1, the main significant parameter is CLUSTER_LOCATION. There are several allowed values of this parameter:
- internal: suggests service works in k8s cluster and doesn’t require and other additional settings
- remote: suggests service works with remote k8s cluster and properly defined CLUSTER_CREDENTIALS settings (highly not recommended for anything except for development)
- local: suggests service works on the same machine as k8s cluster (highly not recommended for anything except for development)
If luna-builder is configured to use remote kubernetes cluster it is required to define CLUSTER_CREDENTIALS:
- suggests access to k8s cluster using ssl connection
- HOST is kubernetes cluster host
- TOKEN is kubernetes cluster token which must be provided by kubernetes cluster administrator (each token has its own expiration time, do not forget to use actual token)
- CERTIFICATE_PATH is path to SSL certificate which must be provided by kubernetes cluster administrator
There is LUNA_BUILDER_REGISTRY parameter. It is required read and write access to this registry. If luna-builder is running in kubernetes cluster, it is required to grant access to this registry from kubernetes cluster.
There is LUNA_BUILDER_INSECURE_REGISTRIES parameter. If LUNA_BUILDER_REGISTRY contains insecure registry and/or it is required access to any other insecure registries during image creation process they must be specified in LUNA_BUILDER_INSECURE_REGISTRIES.
For correct operation of the local kaniko build process, the builder container must be started with the following Docker flags: -u=root, –security-opt=no-new-privileges:true, –cap-drop=ALL, –cap-add=CHOWN, –cap-add=FOWNER, –cap-add=DAC_OVERRIDE, –cap-add=SETFCAP –cap-add=SYS_CHROOT and –cap-add=MKNOD. For detailed description of these runtime options, refer to the Docker documentation and Runtime privilege and Linux capabilities.

--cap-drop=ALL

Removes all capabilities from the process inside the container. After that, the container only receives capabilities that are explicitly added via –cap-add.

--cap-add=CHOWN

Allows changing ownership of files and directories. Required by Kaniko to correctly unpack image layers and create/copy files with proper ownership inside the build filesystem.

--cap-add=FOWNER

Allows changing file permissions and certain file attributes. Required by Kaniko for operations such as chmod, modifying timestamps, and adjusting attributes of files extracted from image layers where ownership and permissions are fixed.

--cap-add=DAC_OVERRIDE

Allows bypassing standard Unix discretionary access control checks. Required by Kaniko so it can freely read and modify files in the root filesystem while unpacking layers, even if their permissions would normally prevent it.

--cap-add=SETFCAP

Allows Kaniko to set and restore file capabilities via security.capability attribute for binaries from the base image (e.g. networking tools or user-namespace utilities). This ensures privilege settings from the base image are preserved regardless of which files with file capabilities are present.

--cap-add=SYS_CHROOT

Allows the use of the chroot() system call to change the process’s root directory. Required by Kaniko to run builds in an isolated rootfs and avoid mixing environments from different builds.

--cap-add=CAP_MKNOD

Permits creating special device files using mknod(). Required by Kaniko to create basic devices (e.g., /dev/null) inside the chroot, without which build commands and package managers won’t work.