Environment upgrade scenario#
For example, a user wants to upgrade from LUNA PLATFORM v.5.53.0 to LUNA PLATFORM v.5.57.0 and has four servers where old LUNA PLATFORM services are deployed:
- Server A with databases — PostgreSQL, InfluxDB and Redis databases.
- Server B with the Image Store service.
- Server C with the Licenses service.
- Server D with all other LUNA PLATFORM services.
In fact, all environment preparation can be done with one or two commands. The main thing is to correctly specify the necessary settings for the Storages utility. The Storages utility can receive settings from the running Configurator service or from a configuration file (see "Setting Storages configuration"). If it is possible to specify all the necessary settings in the configuration file, then executing one command with the argument --config will be enough. If all parameters for connecting to the database, services, etc. have already been set in the existing Configurator service and there is no desire to refill the Storages configuration, then to prepare the environment for all services, you can use the existing Configurator settings (argument --luna-config), having previously separately updated the environment for the Configurator service. In this example, we will first update the environment for the Configurator service, and then we will use all its settings to update the environment of the remaining services.
To prepare the environment for the Configurator service, you need to perform the following steps on any of the servers:
- Configure the "LUNA_CONFIGURATOR_DB" section to obtain the Configurator DB address in the Storages configuration file:
vi /var/lib/luna/current/extras/conf/storages_config.conf
By default, the configuration file specifies the location of the Configurator database at 127.0.0.1. In our example, PostgreSQL and Configurator are located on different servers, so you need to explicitly set the database address. If Configurator and PostgreSQL were on the same server, then it would be possible not to edit the configuration file and use the default one inside the container without passing the
--config
argument.If necessary, you can set the environment preparation settings for all services at once in the Storages configuration file and immediately proceed to preparing the environment for all services. This example specifically reflects both options for using settings.
- Migrate the Configurator service database:
docker run \
--rm \
--network=host \
- -v /var/lib/luna/current/extras/conf/storages_config.conf:/srv/storages_config.conf \
dockerhub.visionlabs.ru/luna/storages:v.0.4.23 \
bash -c "luna_prepare prepare configurator \
--entity=database \
--platform_version=v.5.57.0 \
--config=/srv/storages_config.conf"
Note that when using a configuration file other than the default one, it must be mounted to the Storages container.
- Migrate Configurator service settings:
docker run \
--rm \
--network=host \
- -v /var/lib/luna/current/extras/conf/storages_config.conf:/srv/storages_config.conf \
dockerhub.visionlabs.ru/luna/storages:v.0.4.23 \
bash -c "luna_prepare prepare configurator \
--entity=configs \
--platform_version=v.5.57.0 \
--config=/srv/storages_config.conf"
If necessary, you can run both of the above commands as one command with the argument
--entity=all_entities
, becauseall_entities
for the Configurator service means using thedatabase
,configs
andinflux_bucket
entities. However, the InfluxDB bucket (the last entity) will be prepared in theprepare all_entities --profile=common
command below, also that there is no point in preparing it at this stage. If you nevertheless prepare it at this stage, then in the environment preparation command for all services it will be re-created, but only if the named argument--ii
is specified (whether existing objects should be ignored).
- Stop the old version of Configurator and start the new version of the service.
Now that there is a current version of the Configurator service with the current environment, you can use its settings when preparing the environment for other services.
The environment preparation command looks like this:
docker run \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/storages:v.0.4.23 \
bash -c "luna_prepare prepare all_entities \
--platform_version=v.5.57.0 \
--profile=common \
--luna-config=<configurator_address>"
The environment preparation command can be launched from any server if all addresses are specified correctly in the Configurator settings.
This command will do the following on the respective servers using the Configurator settings on server D:
- Creates buckets (if they are missing) in InfluxDB for monitoring work on server A (positional argument
influx_bucket
). - Creates buckets (if they are missing) in the Image Store service on server D (positional argument
lis_bucket
). - Will prepare the InfluxDB (if it has not been prepared previously) for collecting aggregated statistics by the Admin service on server A (positional argument
aggregated_influx_bucket
). - Will migrate the databases on server A (positional argument
database
). - Will migrate settings to the Configurator database on server D (positional argument
configs
).
Migration of settings to the Configurator database will not be performed in this case, because they have already been migrated at the stage of preparing the environment for the Configurator service.
The Storages utility will check for the presence of buckets in the launched Image Store service in accordance with the Configurator settings. If the Image Store service is not launched, you can explicitly specify the location of the buckets using the
--local-buckets
command.
Example of command execution:
[2024-02-07 15:05:40+0300] [storages] [INFO]: The surrounding state was prepared according to platform version 'v.5.57.0'
[2024-02-07 15:05:40+0300] [storages] [INFO]: Actual services versions:
[2024-02-07 15:05:40+0300] [storages] [INFO]: Service `luna_accounts` version - `v.0.2.6`
[2024-02-07 15:05:40+0300] [storages] [INFO]: Service `luna_admin` version - `v.5.5.6`
...
After executing this command, you need to stop all LUNA PLATFORM services on the corresponding servers, update the settings in the Configurator (optional) and launch their new versions.