distributed system - ghdrako/doc_snipets GitHub Wiki

muratbuffalo.blogspot.com/2020/06/learning-about-distributed-systems.html

PATTERNS

Single node patterns

Sidecar pattern

The sidecar pattern is a single-node pattern made up of two containers. The first is the application container. It con‐ tains the core logic for the application. Without this container, the application would not exist. In addition to the application container, there is a sidecar container. The role of the sidecar is to augment and improve the application container, often without the application container’s knowledge. In its simplest form, a sidecar container can be used to add functionality to a container that might otherwise be difficult to improve. Sidecar containers are coscheduled onto the same machine via an atomic container group, such as the pod API object in Kubernetes. In addition to being scheduled on the same machine, the application container and sidecar container share a number of resources, including parts of the filesystem, hostname, and network, and many other namespaces.

• Example Adding HTTPS to a Legacy Service The legacy web service can be configured to serve exclusively on localhost (127.0.0.1), which means that only services that share the local network with the server will be able to access the service. Sidecar nginx container lives in the same network namespace as the legacy web application, so it can access the service that is running on localhost. At the same time, this nginx service can terminate HTTPS traffic on the external IP address of the pod and proxy that traffic to the legacy web application.

• Example Dynamic Confi guration with Sidecars There again are two containers: the container thatis the serving application and the container that is the configuration manager. The two containers are grouped together into a pod, where they share a directory between themselves. This shared directory is where the configuration file is aintained.

When the legacy application starts, it loads its configuration from the filesystem, as expected. This configuration is placed into the filesystem using a ConfigMap volume which places the current contents of a ConfigMap resource at a particular location in the filesystem. When the configuration manager starts, it examines the configuration API and looks for differences between the local filesystem and the configuration stored in the API. If there are differences, the configuration manager downloads the new configuration to the local filesystem and signals to the legacy application that it should reconfigure itself with this new configuration. The actual mechanism for this notification varies by application. Some applications actually watch the configuration file for changes, while others respond to a SIGHUP signal. In extreme cases, the con‐ figuration manager may send a SIGKILL signal to abort the legacy application. Once aborted, the container orchestration system will restart the legacy application, at which point it will load its new configuration. As with adding HTTPS to an existing application, this pattern illustrates how the sidecar pattern can help adapt pre- existing applications to more cloud native scenarios.