Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
.. _management:
Service Management
==================
This section shows how a deployed VS stack can be interacted with.
Scaling
-------
Scaling is a handy tool to ensure stable performance, even when dealing with
higher usage on either service. For example, the preprocessor and registrar can
be scaled to a higher replica count to enable a better throughput when
ingesting data into the VS.
The following command scales the ``renderer`` service to 5 replicas:
.. code-block:: bash
docker service scale <stack-name>_renderer=5
A service can also be scaled to zero replicas, effectively disabling the
service.
.. warning::
The ``redis`` and ``database`` should never be scaled (their replica count
should remain 1) as this can lead to service disruptions and corrupted data.
Updating Images
---------------
Updating the service software is done using previously established tools. To
update the service in question, it needs to be scaled to zero replicas. Then
the new image can be pulled, and the service can be scaled back to its original
value. This forces the start of the service from the newly fetched image.
Another option to keep the service running during the upgrade procedure is to sequentially
restart the individual instances of the services after pulling a newer image using a command:
.. code-block:: bash
docker service update --force <stack-name>_<service-name>
Updating configurations or environment files
---------------
Updating the service configurations or environment files used can not be done just by
rescaling the impacted services to 0 and rerunning. The whole stack needs to be shut down using a command:
.. code-block:: bash
docker stack rm <stack-name>
A new deployment of the stack will already have updated configuration. The above mentioned process necessarily
involved a certain service downtime between shutting down of the stack and new deployment.