In software engineering it is recommended to separate dynamic configuration from static run time software. This allows developers and operation engineers to change the configuration without having rebuild the runtime.
In openshift it is recommended to only have runtime software packaged in to a container image and stored in the registry . Configuration is then injected to the runtime image during the initialization stage. The major advantage of this approach is that run time image can be build once the configuration can change as the application is promoted to different environments ( like DEV/SIT/PROD)
In openshift we have below mechanisms that can be added as configuration changes in a running pod
Name: nodejs-ex-27-mqurr
Namespace: node-dev
Security Policy: restricted
Node: 192.168.65.2/192.168.65.2
Start Time: Sat, 22 Oct 2016 21:15:57 +1100
Labels: app=nodejs-ex
deployment=nodejs-ex-27
deploymentconfig=nodejs-ex
Status: Running
IP: 172.17.0.13
Controllers: ReplicationController/nodejs-ex-27
Containers:
nodejs-ex:
Container ID: docker://b095481dfae40855815afe46dc61086957a99c907edb5a26fed1a39ed559e725
Image: 172.30.18.34:5000/node-dev/nodejs-ex@sha256:891f5118149f1f134330d1ca6fc9756ded5dcc6f810e251473e3eeb02095ea95
Image ID: docker://sha256:6a0eb3a95c6c2387bea75dbe86463e31ab1e1ed7ee1969b446be6f0976737b8c
Port: 8080/TCP
State: Running
Started: Sat, 22 Oct 2016 21:15:59 +1100
Ready: True
Restart Count: 0
Volume Mounts:
/etc/config from app-config (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-lr5yp (ro)
Environment Variables:
FILTERS_PROPERTIES: <set to the key 'filters.properties' of config map 'test-config'>
KEY1: <set to the key 'key1' of config map 'unixchips-config'>
KEY2: <set to the key 'key2' of config map 'unixchips-config'>
Remaining topics i will update in second part
Thank you for reading ..
In openshift it is recommended to only have runtime software packaged in to a container image and stored in the registry . Configuration is then injected to the runtime image during the initialization stage. The major advantage of this approach is that run time image can be build once the configuration can change as the application is promoted to different environments ( like DEV/SIT/PROD)
In openshift we have below mechanisms that can be added as configuration changes in a running pod
- secrets
- Configuration maps
- Environment variables
- Downward API
- Layered builds
- Resource Quotas
Secrets
Secrets are the mechanism by which sensitive information ( like username/password/certificates) can be added to pods . Also it will keep the OpenShift Container Platform client configuration files, dockercfg files, private source repository credentials, and so on. Secrets decouple sensitive content from the pods. You can mount secrets into containers using a volume plug-in or the system can use secrets to perform actions on behalf of a pod.
Secret object definition
*******************
apiVersion: v1
kind: Secret
metadata:
name: unixchipssecret
namespace: my-namespace
type: Opaque 1
data: 2
username: dmFsdWUtMQ0K 3
password: dmFsdWUtMg0KDQo=
stringData: 4
hostname: myapp.mydomain.com 5
1. Indicates the structure of the secret key names and values
2. The allowable format for the keys in the data field
3. The value associated with keys in the data map must be base64 encoded.
4. The value associated with keys in the stringData map is made up of plain text strings
5.Domain name
save this file as unixchipssecret.yml and now we have to create the secret from this file
#oc create -f unixchipssecret.yml
Also we can use the oc secret command to create the secret
#oc secret new unixchipssecret cert.pem
#oc get secrets
NAME AGE TYPEDATA
unixchipssecret 40s Opaque
We can add labels to the secret for management purpose
#oc label secret unixchipssecret env=test
secret "unixchipssecret" labeled
#oc get secrets --show-labels=true
NAME AGE TYPE LABELS
unixchipssecret 53s Opaque env=Test
Once the secret is created it is needs to be added to the pod . There are two methods to do that
Mounting the secret as a volume
Mounting the secret as an environment variable
First we will try to add the secret as a volume to the underlying deployment configuration
# oc get dc | grep nodejs-ex
NAME REVISION DESIRED CURRENT TRIGGERED BY
node-canary 2 1 1 config.image(nodejs-ex:canary)
nodejs-ex 16 1 1 config.image(nodejs-ex:latest)
#oc volume dc/nodejs-ex --add -t secret --secret-name=unixchipssecret -m /etc/keys --name=unixchips-keys deploymentconfigs/nodejs-ex
Adding the volume will trigger the config changes and the pods are redeployed . To verify the secrets are mounted under volume mounts run the following command
$ oc describe pod nodejs-ex-21-apdcg Poclicy: restricted Node: 192.168.65.2/192.168.65.2 Start Time: Sat, 22 Oct 2016 15:48:26 +1100 Labels: appcccccccccc=nodejs-ex deployment=nodejs-ex-21 deploymentconfig=nodejs-ex Status: Running IP: 172.17.0.13 Controllers: ReplicationController/nodejs-ex-21 Containers: nodejs-ex: Container ID: docker:// 255be1c595fc2654468ab0f0df2f99 715ac3f05d1773d05c59
a18534051f 2933
Image: 172.30.18.34:5000/node-dev/ nodejs-ex@sha256: 891f5118149f1f1343
30d1ca6fc975 6ded5dcc6f810e251473e3eeb02095 ea95
Image ID: docker://sha256: 6a0eb3a95c6c2387bea75dbe86463e 31ab1e1ed7ee1
969b446be6f097673 7b8c
Port: 8080/TCP
State: Running
Started: Sat, 22 Oct 2016 15:48:27 +1100
Ready: True
Restart Count: 0
Volume Mounts:
/etc/keys from unixchipskeys (rw)
/var/run/secrets/kubernetes. io/serviceaccount from default-token-lr5yp(ro)
Environment Variables: <none>
The files contained within the secret will be available in the /var/key directory
$oc rsh nodejs-ex-22-8noey ls /etc/keys
certs unixchipskeys
$oc rsh nodejs-ex-22-8noey ls /etc/keys
certs unixchipskeys
Now we can check how to mount the secret as environment variable
First create the secret
$ oc secret new unixchips-env-secrets
username=user-file
password=password-file
secret/unixchips-env-secrets
Then add it to the deployment config
$oc set env dc/nodejs-ex --from=secret/unixchips-env-secrets
deploymentconfig 'nodejs-ex' updated
Now if we check the pod
First create the secret
$ oc secret new unixchips-env-secrets
username=user-file
password=password-file
secret/unixchips-env-secrets
Then add it to the deployment config
$oc set env dc/nodejs-ex --from=secret/unixchips-env-secrets
deploymentconfig 'nodejs-ex' updated
Now if we check the pod
$ oc describe pod nodejs-ex-22-8noey
Name: nodejs-ex-22-8noey
Namespace: node-dev
Security Policy: restricted
Start Time: Sat, 22 Oct 2016 16:37:35 +1100
Labels: app=nodejs-ex
deployment=nodejs-ex-22
deploymentconfig=nodejs-ex
Status: Running
IP: 172.17.0.14
Controllers: ReplicationController/nodejs- ex-22
Containers:
nodejs-ex:
Container ID: docker:// a129d112ca8ee730b7d8a41a51439e 1189c7557fa917a852c50e539903e2 721a
Image ID: docker://sha256: 6a0eb3a95c6c2387bea75dbe86463e 31ab1e1ed7ee1969b446be6f097673 7b8c
Port: 8080/TCP
State: Running
Started: Sat, 22 Oct 2016 16:37:36 +1100
Ready: True
Restart Count: 0
Volume Mounts:
/var/keys from ssl-keys (rw)
/var/run/secrets/kubernetes. io/serviceaccount from default-token-lr5yp (ro)
Environment Variables:
PASSWORD: <set to the key 'password' in secret 'unixchips-env-secrets'>
USERNAME: <set to the key 'username' in secret 'unixchips-env-secrets'>
$oc set env dc/nodejs-ex --list
deploymentconfigs nodejs-ex container nodejs-ex
container nodejs-ex
PASSWORD from secret env-secrets, key password
USERNAME from secret unixchips-env-secrets, key username
Configuration maps
Configuration maps almost same as secrets , but it contains non sensitive text-based configuration. Configuration maps also injected to the pods as volumes or as a set of environment variables . A major difference between the configuration maps and secrets is how they handle the updates. When the content of a configuration map is changed it is reflected in the pods that it is mounted it and the content of the files in the pods files system are changed . Configuration maps mounted as environment variable do not change on other case .
1. Creating the configuration map
$oc create configmap unixchips-config --from-literal=key1=config1 --from-literal=key2=config2
--from-file=filters.properties
configmap 'unixchips-config' created
2. Mounting configuration maps as volumes
We can read config maps as volumes that can be readable within our container
We can read config maps as volumes that can be readable within our container
$oc volume dc/nodejs-ex --add -t configmap -m /etc/config --name=app-config
--configmap-name=unixchips-config
deploymentconfigs/nodejs-ex
The configuration map will be available in the /etc/config directory
$oc rsh nodejs-ex-26-44kdm ls /etc/config
filters.properties key1 key2
3. To change the configuration maps we have to delete it and recreate it
$oc delete configmap unixchips-config
configmap 'unixchips-configmap' deleted
$$oc create configmap unixchips-config --from-literal=key1=config3 --from-literal=key2=config4
--from-file=filters.properties
configmap 'unixchips-config' created
(we have updated the new configuration config3 & config4 and updated in the pods)
$oc rsh nodejs-ex-26-44kdm ls /etc/config
filters.properties key1 key2 key3
4. Mounting the configuration map as environment variable
$oc set env dc/nodejs-ex --from=configmap/unixchips-config
deploymentconfig 'nodejs-ex' updated
$oc describe pod nodejs-ex-27-mqurr
Name: nodejs-ex-27-mqurr
Namespace: node-dev
Security Policy: restricted
Node: 192.168.65.2/192.168.65.2
Start Time: Sat, 22 Oct 2016 21:15:57 +1100
Labels: app=nodejs-ex
deployment=nodejs-ex-27
deploymentconfig=nodejs-ex
Status: Running
IP: 172.17.0.13
Controllers: ReplicationController/nodejs-ex-27
Containers:
nodejs-ex:
Container ID: docker://b095481dfae40855815afe46dc61086957a99c907edb5a26fed1a39ed559e725
Image: 172.30.18.34:5000/node-dev/nodejs-ex@sha256:891f5118149f1f134330d1ca6fc9756ded5dcc6f810e251473e3eeb02095ea95
Image ID: docker://sha256:6a0eb3a95c6c2387bea75dbe86463e31ab1e1ed7ee1969b446be6f0976737b8c
Port: 8080/TCP
State: Running
Started: Sat, 22 Oct 2016 21:15:59 +1100
Ready: True
Restart Count: 0
Volume Mounts:
/etc/config from app-config (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-lr5yp (ro)
Environment Variables:
FILTERS_PROPERTIES: <set to the key 'filters.properties' of config map 'test-config'>
KEY1: <set to the key 'key1' of config map 'unixchips-config'>
KEY2: <set to the key 'key2' of config map 'unixchips-config'>
Also we have another option to create the configmaps from a file and mapping it to the pod definition .
First create a config map file as below by mentioning the environment variable
# cat example.env
VAR_1=Hello
VAR_2=World
$oc create configmap unixchips-config --from-env-file=example.env
configmap "unixchips-config" created
Below command will provide the details about the resources created on it
# oc describe configmap/unixchips-config
Name: unixchips-config
Namespace: advanced
Labels: <none>
Annotations: <none>
Data
====
VAR_1:
----
Hello
VAR_2:
----
World
Events: <none>
The next step is to inject this config map to the pod by mentioning inside the pod definition file
# cat example-pod-1.yml
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: example
image: cirros
command: ["/bin/sh", "-c", "env"]
envFrom:
- configMapRef:
name: unixchips-config
# oc create -f example-pod-1.yml
pod "example" created
if we check the logs of the pod we can see the environment variables mentioned in the configmap
# oc logs po/example
...
<output omitted>
...
VAR_1=Hello
VAR_2=World
Thank you for reading ..