Olá, habrozhiteli!Com o desenvolvimento de microsserviços e contêineres, as abordagens para o design, criação e lançamento de software mudaram. Explore os novos padrões e princípios de design necessários para implementar aplicativos em nuvem Kubernetes.Este livro é destinado a desenvolvedores que desejam projetar e desenvolver aplicativos baseados em nuvem para a plataforma Kubernetes. O maior benefício disso serão os leitores que estão pelo menos um pouco familiarizados com os contêineres e desejam subir para um novo nível. Cada padrão de design é uma descrição do problema real e a solução é suportada e ilustrada por exemplos de código específicos.Excerto. Sidecar Pattern
O padrão Sidecar (Trailer) é para definir um contêiner que amplia os recursos de um contêiner existente sem alterá-lo. Esse é um dos padrões fundamentais de contêineres que permite criar contêineres altamente especializados que trabalham em estreita colaboração. Neste capítulo, você aprenderá tudo relacionado à idéia do padrão Sidecar (Trailer). E nos capítulos 16 e 17 você se familiarizará com variantes especializadas desse padrão - os padrões Adaptador e Embaixador, respectivamente.Tarefa
Containers é uma tecnologia de empacotamento popular que permite que desenvolvedores e administradores de sistema criem, entreguem e executem aplicativos de maneira unificada. Um contêiner representa o limite natural de uma unidade funcional com seu tempo de execução, ciclo de liberação, API e a equipe de desenvolvimento à qual ele pertence. Um contêiner típico age como um processo no Linux - resolve um problema e resolve-o bem - e é criado sob a suposição da possibilidade de substituição e reutilização. O último é especialmente importante porque permite criar aplicativos rapidamente usando contêineres especializados existentes.Atualmente, para enviar uma solicitação HTTP, você não precisa escrever uma biblioteca cliente, basta usar a existente. Da mesma forma, para manter o site, você não precisa criar um contêiner com um servidor da Web, basta usar o existente. Essa abordagem permite que os desenvolvedores não reinventem a roda e criem um ecossistema com menos contêineres de melhor qualidade para manutenção. No entanto, para poder usar contêineres reutilizáveis altamente especializados, são necessárias maneiras de expandir seus recursos e meios para organizar as interações entre eles. O padrão Sidecar (Trailer) descreve exatamente essa maneira de organizar interações quando um contêiner expande os recursos de outro contêiner existente.Decisão
No capítulo 1, vimos como os pods permitem combinar vários contêineres em um bloco. Nos bastidores, em tempo de execução, under também é um contêiner, mas começa como um processo de pausa (literalmente usando o comando de pausa) na frente de todos os outros contêineres na lareira. Ele não faz nada além de armazenar todos os namespaces do Linux que os contêineres de aplicativos usam para interagir durante todo o ciclo de vida do pod. Além desses detalhes de implementação, todas as características que a abstração da lareira fornece também são interessantes.Under é uma primitiva tão fundamental que está presente em muitas plataformas em nuvem, embora com nomes diferentes, mas sempre com recursos semelhantes. Sob, como uma unidade de implantação, impõe certas restrições de tempo de execução em seus contêineres. Por exemplo, todos os contêineres são implantados em um nó e têm um ciclo de vida comum. Além disso, permite que seus contêineres usem volumes compartilhados e troquem dados por meio de uma rede local ou usando ferramentas de comunicação entre processos do host. É por isso que os usuários combinam contêineres em cápsulas. O padrão Sidecar (Trailer), às vezes também chamado de Sidekick (Companion), descreve o cenário de adicionar um contêiner ao sub para expandir os recursos de outro contêiner.Um exemplo típico que demonstra esse padrão é o servidor HTTP e o mecanismo de sincronização com o repositório Git. O contêiner do servidor HTTP resolve os problemas associados à manutenção de arquivos via HTTP e não sabe como e de onde esses arquivos vêm. Da mesma forma, o único objetivo de um contêiner que sincroniza com o Git é sincronizar dados no sistema de arquivos local com dados no servidor Git. Ele não se importa com o que acontece com os arquivos após a sincronização, sua única tarefa é sincronizar o conteúdo da pasta local com o conteúdo no servidor Git remoto. A Listagem 15.1 fornece uma definição de pod com esses dois contêineres configurados para usar o volume para compartilhamento de arquivos.Listagem 15.1. Implementação do Padrão Sidecar (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) O contêiner principal do aplicativo que atende arquivos via HTTP.(2) Contêiner auxiliar (Trailer) atuando em paralelo e recebendo dados do servidor Git.(3) Uma pasta compartilhada para troca de dados entre os contêineres primário e secundário.Este exemplo mostra como um contêiner de sincronização com o Git adiciona conteúdo a ser servido por um servidor HTTP e o mantém atualizado. Você também pode dizer que os dois contêineres trabalham em estreita cooperação e são igualmente importantes, mas o padrão Sidecar (Trailer) assume a presença de um contêiner principal (principal) e auxiliar que expande o comportamento coletivo. Normalmente, o principal é listado primeiro na lista de contêineres e representa o contêiner padrão (que é iniciado pelo comando kubectl exec, por exemplo).Este padrão simples, mostrado na fig. 15.1 garante uma estreita cooperação dos contêineres em tempo de execução e, ao mesmo tempo, permite o compartilhamento de tarefas que podem pertencer a equipes separadas de desenvolvedores que usam diferentes linguagens de programação, com diferentes ciclos de lançamento de novas versões, etc. Também promove intercambiabilidade e reutilização de contêineres - no sentido de que o servidor HTTP e o mecanismo de sincronização Git podem ser reutilizados em outros aplicativos e com outras configurações, de forma independente e em conjunto com outros contêineres.Explicação
Já foi dito acima que as imagens do contêiner são semelhantes às classes e os contêineres são como objetos na programação orientada a objetos (OOP). Continuando essa analogia, podemos comparar a expansão das capacidades dos contêineres com a herança no OOP, e o trabalho conjunto de vários contêineres na lareira com a recepção de uma composição no OOP. Ambas as abordagens permitem a reutilização de código, mas a herança define um relacionamento mais próximo e representa o relacionamento "is" entre contêineres.A composição na lareira representa a relação “tem” - é mais flexível, porque não requer a combinação de contêineres durante a montagem, o que possibilita posteriormente alterar os contêineres na definição da lareira. Mas a composição também implica a presença de vários contêineres (processos) operando simultaneamente, que devem ser verificados quanto à operacionalidade e reiniciados e que consomem recursos, bem como o contêiner principal do aplicativo. O padrão Sidecar (Trailer) envolve a criação de pequenos contêineres auxiliares que consomem recursos mínimos, mas você decide se inicia um processo separado ou combina melhor todas as tarefas em um contêiner principal.De outro ponto de vista, a composição dos contêineres é semelhante à programação orientada a aspectos, quando, com a ajuda de contêineres adicionais, recursos ortogonais (independentes) que não estão relacionados ao contêiner principal são adicionados ao sub. Nos últimos meses, o padrão Sidecar (Trailer) está ganhando popularidade, especialmente para resolver tarefas de gerenciamento de rede, serviços de monitoramento, onde cada serviço também vem na forma de contêineres auxiliares.»Mais informações sobre o livro podem ser encontradas no site da editora» Conteúdo» Trecho docupom Khabrozhiteley de 25% de desconto no cupom - KubernetesApós o pagamento da versão impressa do livro, um livro eletrônico é enviado por e-mail.