Hello, habrozhiteli!With the development of microservices and containers, approaches to the design, creation and launch of software have changed. Explore the new design patterns and principles that are required to implement Kubernetes cloud applications.This book is intended for developers who want to design and develop cloud-based applications for the Kubernetes platform. The greatest benefit from it will be readers who are at least a little familiar with containers and want to rise to a new level. Each design pattern is a description of the real problem, and the solution is supported and illustrated by specific code examples.Excerpt. Sidecar Pattern
The Sidecar pattern (Trailer) is to define a container that extends the capabilities of an existing container without changing it. This is one of the fundamental container patterns that allows you to create highly specialized containers that work closely with each other. In this chapter you will learn everything related to the idea of the Sidecar pattern (Trailer). And in chapters 16 and 17 you will get acquainted with specialized variants of this pattern - the Adapter and Ambassador patterns, respectively.Task
Containers is a popular packaging technology that allows developers and system administrators to create, deliver, and run applications in a unified way. A container represents the natural boundary of a functional unit with its runtime, release cycle, API, and the development team to which it belongs. A typical container acts like a process on Linux — solves one problem, and does it well — and is created under the assumption of the possibility of replacement and reuse. The latter is especially important because it allows you to quickly create applications using existing specialized containers.Currently, in order to send an HTTP request, you do not need to write a client library, just use the existing one. Similarly, to maintain the website, you do not need to create a container with a web server, just use the existing one. This approach allows developers not to reinvent the wheel and create an ecosystem with fewer containers of better quality for maintenance. However, in order to be able to use highly specialized reusable containers, ways to expand their capabilities and means for organizing interactions between them are necessary. The Sidecar pattern (Trailer) describes just such a way of organizing interactions when one container expands the capabilities of another, existing container.Decision
In chapter 1, we saw how pods allow you to combine several containers into one block. Behind the scenes, at run time, under is also a container, but it starts as a paused (literally using the pause command) process in front of all the other containers in the hearth. It does nothing but store all of the Linux namespaces that application containers use to interact throughout the pod life cycle. In addition to this implementation detail, all the characteristics that the hearth abstraction provides are also of interest.Under is such a fundamental primitive that it is present in many cloud platforms, albeit under different names, but always with similar capabilities. Under, as a deployment unit, imposes certain runtime restrictions on its containers. For example, all containers are deployed on one node and have a common life cycle. In addition, under allows its containers to use shared volumes and exchange data through a local network or using host interprocess communication tools. That is why users combine containers into pods. The Sidecar pattern (Trailer), sometimes also called Sidekick (Companion), describes the scenario of adding a container to the under to expand the capabilities of another container.A typical example demonstrating this pattern is the HTTP server and the synchronization mechanism with the Git repository. The HTTP server container solves the problems associated with servicing files via HTTP and does not know how and where these files come from. Similarly, the only purpose of a container that synchronizes with Git is to synchronize data in the local file system with data on the Git server. He doesn't care what happens to the files after synchronization, his only task is to synchronize the contents of the local folder with the contents on the remote Git server. Listing 15.1 provides a pod definition with these two containers configured to use the volume for file sharing.Listing 15.1. Sidecar Pattern Implementation (Trailer)apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
containers:
- name: app
image: docker.io/centos/httpd ❶
ports:
- containerPort: 80
volumeMounts:
- mountPath: /var/www/html ❸
name: git
- name: poll
image: axeclbr/git ❷
volumeMounts:
- mountPath: /var/lib/data ❸
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
(1) The main application container serving files over HTTP.(2) Auxiliary container (Trailer) acting in parallel and receiving data from the Git server.(3) A shared folder for exchanging data between the primary and secondary containers.This example shows how a synchronization container with Git adds content to be served by an HTTP server and keeps it up to date. You can also say that both containers work in close cooperation and are equally important, but the Sidecar pattern (Trailer) assumes the presence of a main (main) and auxiliary container that expands collective behavior. Usually the main one is listed first in the list of containers and represents the default container (which is launched by the kubectl exec command, for example).This simple pattern, shown in fig. 15.1 ensures close cooperation of containers at runtime and at the same time allows sharing tasks that may belong to separate teams of developers using different programming languages, with different cycles of release of new versions, etc. It also promotes interchangeability and reuse of containers - in the sense that the HTTP server and the Git synchronization mechanism can be reused in other applications and with other settings, both independently and in conjunction with other containers.Explanation
It has already been said above that container images are similar to classes, and containers are like objects in object-oriented programming (OOP). Continuing this analogy, we can compare the expansion of container capabilities with inheritance in OOP, and the joint work of several containers in the hearth with the reception of a composition in OOP. Both of these approaches allow code reuse, but inheritance defines a closer relationship and represents the “is” relationship between containers.The composition in the hearth represents the “has” relationship - it is more flexible because it does not require the combination of containers during assembly, which makes it possible to change containers later in the hearth definition. But composition also implies the presence of several containers (processes) operating simultaneously, which must be checked for operability and restarted and which consume resources, as well as the main application container. The Sidecar pattern (Trailer) involves the creation of small auxiliary containers that consume minimal resources, but you decide whether to start a separate process or better combine all the tasks into a main container.From another point of view, the composition of containers is similar to aspect-oriented programming, when using additional containers, orthogonal (independent) capabilities that are not related to the main container are added to the sub. In recent months, the Sidecar pattern (Trailer) is gaining popularity, especially for solving network management tasks, monitoring services, where each service also comes in the form of auxiliary containers.»More information about the book can be found on the publisher’s website» Contents» ExcerptFor Khabrozhiteley 25% discount on coupon - KubernetesUpon payment of the paper version of the book, an electronic book is sent by e-mail.