# Configure parameters of portable services using ConfigMap

> [HTML Version](configmap.html)

You can set limits and parameters for deploying microservices from [portable services in modules](portable-microservices.md) using ConfigMap, a Kubernetes resource for working with configuration data. This allows you to:

- Limit the dedicated resources.

- Define the number of microservice instances that are deployed in Kubernetes, and configure their autoscaling.

- Configure the distribution of microservice pods across cluster nodes in ConfigMap.

- Pass Kubernetes secrets to portable services.

- Configure a connection to the local image registry.

You can specify global settings for portable services configured in all modules of the system, as well as add individual settings for a specific service.

You can use ConfigMap for:

- Fine tuning of microservice deployment. You can specify parameter values that are not available when [editing a portable service in a module](portable-services.md#docker-settings).

- Changing settings without editing the module. It is useful for paid modules. For example, you can set the number of microservice instances because the parameter in ConfigMap is prioritized over the value set by the developer when creating the module.

To configure ConfigMap, do the following steps:

1. [Enable ConfigMap](#enable-configmap).

2. [Set parameters in ConfigMap](#configmap-parameters).

## Step 1: Enable ConfigMap

To use ConfigMap for configuration of portable services, enable the \[OBJECT\] environment variable for the **babysitter** service. To do this, make changes to the \[OBJECT\] configuration file:

1. Create a backup copy of the \[OBJECT\] file filled in when installing BRIX. This is required before editing, as incorrect parameter settings may cause BRIX application malfunction.

2. In the \[OBJECT\] configuration file, enable the following parameters:

````
global:  
...  
\# Enable portable services  
    managedServices:  
        enabled: true  
...  
\# ConfigMap use  
        watchableConfigMap:  
          enabled: true

3. ````
Update the BRIX application using the following command:

````
helm upgrade brix365 ./brix365 -f values-brix365.yaml --timeout=30m

````
After that, a file that stores ConfigMap parameters will be automatically created. It will be added to the \[OBJECT\] where the portable services are placed, which is \[OBJECT\] by default. The file is preconfigured with a ConfigMap named \[OBJECT\]. For correct operation, it is recommended to not change the default name.

Now you can set the parameters in ConfigMap.

To return to the default settings and start the configuration again, delete the \[OBJECT\] file and run the following command to regenerate it:

````
kubectl apply -f cfg.yaml -n brix365-applets

````
Where \[OBJECT\] is the \[OBJECT\] for placing the portable services.

## Step 2: Set parameters in ConfigMap

To change the settings:

1. Run the command to open the ConfigMap file for editing:

````
kubectl edit configmap brix365-babysitter-config -n brix365-applets

````
Where:

- \[OBJECT\] is the name of the ConfigMap in the **cfg.yaml** file.

- \[OBJECT\] is the namespace that hosts the portable services.

2. In the opened file, set:

- Global parameters. They are applied by default to portable services in all modules. Set them in the \[OBJECT\] block.

- Parameters for a particular service. To set them, add a block with the service name according to the template: \[OBJECT\] where:

	- \[OBJECT\] is the BRIX company code. You can find it in its URL address.

	- \[OBJECT\] is the identifier of the module where the portable service is configured. You can copy it from the URL address of the module in BRIX.

	- \[OBJECT\] is the unique name of the portable service from the [module settings](portable-services.md#add-service).

Please note that parameter values from the block specific to a portable service have a higher priority than the global parameter values. If a parameter is not specified at the portable service level, the value from the `global` block is used.

ConfigMap example

````
apiVersion: v1  
kind: ConfigMap  
metadata:  
  name: brix365-babysitter-config  
  annotations:  
    "helm.sh/resource-policy": keep  
data:  
   # Global settings  
  global:  
    replicaCount: 1  
    nodeSelector:   
      role: brix   
    tolerations:  
      - effect: NoSchedule  
        key: dedicated  
        operator: Equal  
        value: brix  
    autoscaling:  
      enabled: true  
      minReplicas: 1  
      maxReplicas: 9  
      targetMemoryUtilizationPercentage: 80  
      targetCPUUtilizationPercentage: 80  
    resources:  
      requests:  
        memory: "384Mi"  
        cpu: "250m"  
      limits:  
        memory: "1024Mi"  
        cpu: "1000m"  
  
   # Settings for a particular service  
   abcd12345efgh.ext\_4a685c94-3dcd-433a-ac5f-6367aaf38950.portableservice:  
    resources:  
      requests:  
        memory: "512Mi"  
        cpu: "500m"  
      limits:  
        memory: "2048Mi"  
        cpu: "1000m"  
    image:  
      repository: registry.example.com  
      pullSecret:  
        - "my-registry-secret"
````

````
Available parameters:

1. **Resources** (\[OBJECT\]):

- \[OBJECT\] are memory and CPU resources to be dedicated for the microservice.

- \[OBJECT\] is the maximum values of dedicated resources.

Read more about possible values of these parameters in the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes).

````
начало примера

````
Example

````
resources:  
  requests:  
    memory: "512Mi"  
    cpu: "500m"  
  limits:  
    memory: "2048Mi"  
    cpu: "1000m"

конец примера

2. ````
**Number of instances** (\[OBJECT\]). How many pods to start for the microservice. Available values: 0-32k.

````
начало примера

````
Example

````
replicaCount: 4

конец примера

3. ````
**Autoscaling** (\[OBJECT\]):

- \[OBJECT\] enables autoscaling.

- \[OBJECT\] is the minimum number of microservice instances. Available values: 0-32k.

- \[OBJECT\] is the maximum number of instances. Available values: 0-32k.

- \[OBJECT\] is desired memory usage in percentage. Available values: 0-100.

- \[OBJECT\] is desired CPU resource utilization in percentage. Available values: 0-100.

````
начало примера

````
Example

````
autoscaling:  
   enabled: true  
   minReplicas: 1  
   maxReplicas: 9  
   targetMemoryUtilizationPercentage: 80  
   targetCPUUtilizationPercentage: 80

конец примера

4. ````
**Select nodes for pod placement** (\[OBJECT\]). Configure microservices pods to be placed on specific cluster nodes using special tags.

Read more about using the parameter in the [official Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/).

````
начало примера

````
**Example**

````
nodeSelector:  
  role: brix  
  disk: ssd

конец примера

5. ````
**Tolerations for placing pods** (\[OBJECT\]). Set tolerations for microservice pods so that they can be placed on nodes with appropriate taints.

````
начало примера

````
**Example**

````
tolerations:  
  - effect: NoSchedule  
    key: dedicated  
    operator: Equal  
    value: monitoring

конец примера

6. ````
**Getting Kubernetes secrets** (`secretMappings`). If you need to pass sensitive information to the portable service, e. g. a database connection string, first save it in a Kubernetes secret, and then specify the rule for getting it in the `secretMappings` parameter. For more information, see the [Pass Kubernetes secrets to portable services using ConfigMap](configmap-secrets.md) article.

7. **Path and secrets for the local image registry** (`image`).  To run the portable service in an isolated environment without internet access, you must first download and save its Docker image to your local image registry. Then specify:

- `repository`. The address of the local image registry. This allows you to replace the domain part of the [image address](portable-services.md#image-address) specified in the module on the **Services** tab in the **Docker container** block.

- `pullSecret`. The name of the secret containing the access keys to the local image registry if authentication is required to access them.

````
начало примера

````
**Example**

In the module on the **Services** tab, the following public Docker Hub address is specified: **chialab/math-api**. In the ConfigMap, you specified the following parameters:

````
image:  
  repository: registry.example.com  
  pullSecret:  
    - "my-registry-secret"

````
As a result, the source of the image for deploying the microservice will be the local repository: **registry.example.com/chialab/math-api**.

````
конец примера

3. ````
After making the changes, apply them using the command specifying the \[OBJECT\] that hosts the portable services:

````
kubectl apply -f cfg.yaml -n brix365-applets

````
The settings will be applied automatically as the **babysitter** service tracks changes in ConfigMap. All microservices for which the settings have changed will restart.