content_image/838469.jpg content_image/838467.jpg
name : git env : - name : GIT_REPO value : https://github.com/mdn/beginner-html-site-scripted command : - "sh" - "-c" - "git clone $(GIT_REPO) . && watch -n 600 git pull" workingDir : /var/lib/data volumes : - emptyDir : {} name : git 

Main application container serving files over HTTP 

<img src='content_image/838469.jpg'>

Sidecar container running in parallel and pulling data from a Git server 

Shared location for exchanging data between the Sidecar and main application container 

This example shows how the Git synchronizer enhances the HTTP server’s behavior with content to serve and keeps it synchronized. We could also say that both contain‐ ers collaborate and are equally important, but in a Sidecar  pattern, there is a main container and a helper container that enhances the collective behavior. Typically, the main container is the first one listed in the containers list, and it represents the default container (e.g., when we run the command: kubectl exec ). 

This simple pattern, illustrated in Figure 15-1, allows runtime collaboration of con‐ tainers, and at the same time, enables separation of concerns for both containers, which might be owned by separate teams, using different programming languages, with different release cycles, etc. It also promotes replaceability and reuse of contain‐ ers as the HTTP server, and the Git synchronizer can be reused in other applications and different configuration either as a single container in a Pod or again in collabora‐ tion with other containers. 

<img src='content_image/838467.jpg'>

