- Overview: This pattern is a specialized sidecar repsonsible for hiding the complexity and providing the unified interface for accessing the services
- To demonstrate this pattern, lets say we use a cache for application. In the local developer environment we want tous memcached and in production we want to use etcd.
- So we create an Ambassador container which accesses the memcached and also the ambassador container which uses local memcached
- Depending on the envoronment we can use the Ambassador container.
- Refer Here for the sample created
- Every application needs to be configured and easy way to do it by storing configurations in code. This approach has side effect of configuration and code living and dying together.
- We still need the flexibility to adapt configuration without recreating application image.
- Refer Here for the config Map
- Use environmental variables is easier way to setup configuration for simple use cases
- Environmental variables are set only before the application starts and we cannot change them later
- Refer Here for the manifests
- One significant disadvantage of the EnvVar Configuration pattern is that it’s suitable for only a handful of variables and simple configurations.
- Often its better to keep all the configuration data in a single place.
- kuberenetes has dedicated Configuration Resources that are more flexible than pure environment variables
- These are ConfigMap and Secret Objects for general-purpose configuration and sensitive data respectively
- Once a config Map is create and holding data, we can use the keys of Config Maps in two ways
- As a reference for environmental variables. Key is environmental variable
- As files that are maaped to a volume mounted in a Pod. Key is file name
- The file mounted ConfigMap Volume is updated when the ConfigMap is update via k8s api.
- Refer Here for the configmap as volume mount.