Forem: Isaac Alves Pinheiro

Vibe Coding (2025)

Isaac Alves Pinheiro — Tue, 12 Aug 2025 00:21:28 +0000

Nos últimos anos, o desenvolvimento de software tem passado por transformações impulsionadas pela Inteligência Artificial, e um dos conceitos que mais tem ganhado relevância nesse cenário é o vibe coding.

Introduzido por Andrej Karpathy em 2025, o termo descreve uma nova abordagem à programação, em que as pessoas desenvolvedoras deixam de se concentrar na escrita do código e passam a expressar suas intenções em linguagem natural, enquanto agentes de IA se encarregam da implementação técnica.

Essa mudança de paradigma está sendo rapidamente adotada em escala global: segundo o Vibe Coding Dashboard 2025 da Innobu, a IA já é responsável por gerar 41% de todo novo código, com 256 bilhões de linhas escritas somente em 2024. Esses dados evidenciam o impacto e a velocidade dessa evolução, além de redefinir o papel da pessoa programadora na era da IA.

Basicamente, vibe coding é uma nova forma de programar que coloca a ideia de quem está desenvolvendo no centro do processo.

Assim, em vez de uma pessoa escrever cada linha de código manualmente, ela descreve o que deseja criar (ou seja, a “vibe” do projeto) e a Inteligência Artificial cuida da parte técnica, sugerindo códigos prontos, montando estruturas básicas e automatizando tarefas repetitivas.

Essa abordagem permite que a pessoa desenvolvedora foque mais na criatividade e no design da solução, enquanto a IA trata dos detalhes operacionais.

Na prática, o vibe coding também torna o desenvolvimento de software mais rápido, intuitivo e acessível, representando uma grande mudança na forma como a programação é feita e como é criada.

A expressão vibe coding, que pode ser traduzida como “codificação por intenção” ou “programar pela vibe”, representa muito mais do que uma técnica. Trata-se de uma mudança na forma de pensar o desenvolvimento de software.

Nesse modelo, como vimos, o fluxo é iterativo: a pessoa explica, a IA gera o código, a pessoa desenvolvedora testa e ajusta, e esse ciclo se repete até que o resultado desejado esteja satisfatório. Isso favorece a experimentação rápida e permite a refinação da solução com base em testes contínuos, alinhando-se aos princípios das metodologias ágeis.

Vale ressaltar também que, mesmo ao codar com IA, o papel do(a) profissional de desenvolvimento continua essencial, por ser quem garante que o código faça sentido, esteja alinhado aos objetivos do projeto e seja seguro. Por isso, podemos concluir que o sucesso do vibe coding depende da capacidade humana de orientar a IA com clareza, revisar com senso crítico e tomar decisões estratégicas com base no contexto do negócio.

E, praticamente, TUDO na vida de um profissional de tecnologia é método científico, baseado em (Who, What, How, When, Where and Why?), onde fazemos seleções, consultas e projeções de algo. É sempre baseado no que eu quero ver ou pra que eu preciso. E, é até curioso como, mesmo sem perceber, a gente vive aplicando um ciclo científico no dia a dia do trabalho em tecnologia.

Você parte de um “por que” (o problema ou necessidade real), passa pelo “o que” (definição do objeto ou resultado desejado), segue para o “como” (métodos, ferramentas e arquitetura para chegar lá), depois determina “quem” (atores, equipes, usuários, stakeholders), “quando” (prazos, releases, janelas de manutenção) e “onde” (ambiente, infraestrutura, contexto de uso).

No fundo, é a mesma lógica que o método científico formal usa:

Observação (notar um problema ou oportunidade);
Pergunta (Who, What, How, When, Where, Why);
Hipótese (solução proposta ou estratégia);
Experimentação (testes, PoCs, prototipagem);
Análise (validar resultados, métricas, feedback);
Conclusão (aprovar, refatorar ou pivotar).

E como na ciência, quase tudo é iterativo — cada entrega, cada sprint, cada refatoração é um novo “experimento” validando ou derrubando hipóteses.

Por essa razão, esse método alinhado ao Vibe Coding é uma revolução, mas não substitui o profissional sendo ele Júnior, Pleno ou Sênior, mas sim o impulsiona e amplifica seus dons, pois estaremos sempre em busca da viabilidade e da automação. Então, o que antes era mais complexo de desenvolver por estimar prazos, processos e obstáculos enfrentados, atualmente é possível por um curto período.

No entanto, claro, sempre alinhado com os stakeholders, utilizando feedbacks e usando Soft Skills (pensamento crítico, criatividade, comunicação, colaboração, etc), são o que mantém essa engrenagem funcionando. Sem isso, mesmo com toda tecnologia, a chance de desalinhamento é alta.

Mesmo que uma IA evolua para ter um “senso crítico” técnico, como proposto para modelos futuros de AGI (Artificial General Intelligence), ele ainda será moldado por dados, regras, protocolos e objetivos que não abrangem todas as nuances da experiência humana. Ou seja, ela também pode ser sujeita a muitos erros, falhas e inconsistências de resultados.

E o julgamento humano é criterioso, atravessado por contextos subjetivos, valores culturais, memórias, opiniões, intuições e até contradições internas, algo que não pode ser completamente capturado e preenchido por modelos estatísticos ou algoritmos de aprendizado.

Uma IA pode ser excelente em identificar inconsistências lógicas, propor soluções criativas dentro de parâmetros e até fazer análises de risco, mas ela não tem vivência pessoal, não sente o impacto emocional e não percebe prioridades sutis que para um humano podem ser óbvias — como saber quando seguir uma regra e quando quebrá-la por razões éticas ou contextuais.

Por isso, o equilíbrio entre capacidade técnica da IA e senso crítico humano é o que realmente potencializa resultados, principalmente em tecnologia, onde as decisões envolvem não só o “funciona ou não”, mas também o que “deve ou não ser feito” e “como será recebido pelo mundo real”.

É uma nova filosofia de trabalho moderna para desenvolvimento de software, combinando o método científico como base da análise e decisão com uma mentalidade Vibe Coding para fluidez criativa e entrega rápida.

No fundo, programar não é só escrever código, mas um processo contínuo de formular hipóteses (Who, What, How, When, Where, Why?), testar, analisar e ajustar. Isso é exatamente como funciona o método científico, só que aplicado ao mundo da tecnologia.

Assim como a citação:

"A mudança é a lei da vida. E aqueles que apenas olham para o passado ou para o presente irão com certeza perder o futuro." - John Kennedy

Essa citação de John Kennedy ressalta que devemos acompanhar as crescentes mudanças do mercado e nos prepararmos para o futuro.

Portanto, o Vibe Coding entra como o catalisador: ele reduz o atrito, dá fluidez ao processo e faz com que o desenvolvedor possa experimentar e validar ideias em ciclos muito menores, sem perder o alinhamento com stakeholders. Isso muda o jogo, porque:

Antes: Certas ideias eram descartadas por serem “impraticáveis” ou demoradas.
Agora: Com a abordagem certa, conseguimos provar (ou descartar) hipóteses em dias ou até horas.
Resultado: Mais inovação, menos medo de experimentar, mas ainda com responsabilidade e métricas.

Para experimentar o vibe coding, na prática, basta utilizar uma das diversas ferramentas capazes de gerar AI coding (código com IA) a partir de comandos em linguagem natural, denominados prompts. Atualmente, existem várias soluções no mercado que viabilizam essa abordagem de forma eficiente.

A seguir, apresentamos quatro das ferramentas mais populares:

GitHub Copilot (Microsoft): Desenvolvido em parceria com a OpenAI, o GitHub Copilot é uma das ferramentas mais populares de codificação assistida por IA. Ela se integra diretamente ao VS Code, Neovim, JetBrains e outros editores, oferecendo sugestões em tempo real com base em comentários e no próprio contexto do código.

Melhor uso: ideal para acelerar tarefas rotineiras de programação, gerar trechos de código repetitivos, prototipar funcionalidades rapidamente e explorar novas APIs.

Cursor: O Cursor é um editor de código com IA baseado no VS Code, mas otimizado desde o início para colaboração com IA. Ele permite conversar com o código e realizar buscas contextuais, correções, testes e refatorações usando comandos em linguagem natural.

Melhor uso: fluxos de trabalho iterativos, onde a pessoa desenvolvedora precisa testar ideias para prototipação, exploração de novos projetos ou refatorações em grande escala.

Ghostwriter: Integrado à plataforma online Replit, o Ghostwriter permite a codificação assistida em tempo real no navegador, com suporte para dezenas de linguagens. Seu sistema oferece sugestões completas de código, depuração assistida por IA e até mesmo explicações em linguagem simples do que cada trecho faz.

Melhor uso: perfeito para pessoas desenvolvedoras iniciantes ou para fins educativos. Também é útil em contextos colaborativos, onde múltiplos membros de uma equipe compartilham um mesmo projeto.

Amazon Q Developer: Voltado principalmente para pessoas desenvolvedoras que usam o ecossistema AWS, o Amazon Q oferece sugestões de código, snippets, integração com serviços da nuvem e suporte para diversas linguagens de programação, como Python, Java e JavaScript.

Melhor uso: indicado para equipes que desenvolvem em ambientes de produção usando infraestrutura da AWS. Também é uma escolha sólida para empresas preocupadas com conformidade e segurança em aplicações corporativas.

Embora o vibe coding esteja frequentemente associado ao uso de IA na programação, ele possui uma definição específica (e controversa). Em sua forma original, a abordagem significa "aceitar o código gerado pela IA sem necessariamente compreendê-lo por completo".

Essa característica é o que mais diferencia essa abordagem de uma prática mais tradicional de desenvolvimento assistido por IA, onde a pessoa programadora continua sendo responsável por revisar, testar e entender tudo o que está sendo implementado. Essa diferença foi destacada pelo pesquisador Simon Willison, que afirmou:

“Se um LLM escreveu cada linha do seu código, mas você revisou, testou e entendeu tudo, isso não é vibe coding na minha opinião — isso é usar um LLM como um assistente de digitação.”

O termo vibe coding captura justamente essa ideia de “deixar fluir” o código gerado pela IA, sem uma análise crítica rigorosa, um pouco aquela pegada de “aceitar o que o gerador sugere e partir para frente”, mesmo que o entendimento ou a qualidade do código fiquem um pouco nebulosos.

No entanto, isso lembra bastante o famoso Go Horse Process — aquela prática informal e irônica de “vai que dá certo”, com pouco planejamento, pouca revisão e muita tentativa e erro.

Enquanto o desenvolvimento tradicional assistido por IA foca na colaboração consciente entre humano e máquina — com a pessoa programadora revisando, ajustando, entendendo e validando o que a IA sugere — o vibe coding abre espaço para um fluxo mais espontâneo, menos engessado, onde a velocidade e a experimentação imperam.

Essa diferença, de fato, gera controvérsia:

Para uns, vibe coding é uma forma inovadora e pragmática de acelerar o desenvolvimento.
Para outros, é uma receita para criar dívida técnica, bugs e sistemas difíceis de manter.

Simon Willison, ao destacar essa nuance, chama atenção para o risco de delegar demais à IA sem a devida responsabilidade humana — o que pode gerar soluções frágeis, pouco robustas, quase um “Go Horse” tecnológico. Essa distinção é crucial, especialmente porque o termo vibe coding passou a ser usado amplamente no mercado, muitas vezes por empresas que promovem ferramentas de IA como soluções profissionais sob esse rótulo. Ao fazer isso, existe o risco de mudar o significado original do termo e, pior, de promover práticas potencialmente perigosas.

Por trás do nome atrativo, algumas organizações podem acabar incentivando a ideia de que é aceitável “esquecer que o código existe”. Ou seja, adotar o código com IA sem questionamento, mesmo em sistemas críticos de produção.

Por este motivo, mais do que uma discussão técnica, o debate em torno do vibe coding revela um choque ético e cultural.

De um lado, estão os valores clássicos da engenharia de software: rigorosidade, responsabilidade técnica e compreensão profunda do sistema. Do outro, surge uma nova cultura, baseada na velocidade, nos prompts e na experimentação rápida, impulsionada pela acessibilidade das ferramentas de IA.

Essa discussão já provocou reações fortes dentro da comunidade das pessoas desenvolvedoras. Inclusive, o termo vibe coding já foi duramente criticado, chegando a ser classificado por muitos(as) profissionais como uma prática “descuidada”, “preguiçosa” ou até mesmo como um “insulto à engenharia de software”.

A questão é, qual a diferença entre as ferramentas de vibe coding e os famosos sites de perguntas e respostas da comunidade dev (Stack Overflow, Reddit e etc)? Ou ainda perguntar para o Pleno ou Sênior da sua equipe como resolver ou contornar aquele erro.

Diante disso, o verdadeiro desafio não está somente em adotar novas ferramentas, mas em equilibrar dois mundos: de um lado, a inovação e agilidade oferecidas pela Inteligência Artificial; de outro, os fundamentos sólidos da programação.

Entretanto, quais os riscos de codar com IA? Complementando as questões éticas que o vibe coding possui, existem outros riscos que, se ignorados, podem comprometer seriamente a qualidade e a segurança de diferentes projetos. Abaixo, estão os principais desafios associados à prática de codificação com IA — especialmente em sua forma mais automatizada, como no vibe coding puro.

Compreensão superficial do código: Ao aceitar um IA coding sem revisar cuidadosamente sua lógica, as pessoas desenvolvedoras correm o risco de implementar soluções que funcionam momentaneamente, mas que não são totalmente compreendidas. Isso afeta diretamente a capacidade de manter, escalar ou adaptar o sistema criado no futuro.

Introdução de falhas e vulnerabilidades: Modelos de IA, como LLMs, aprendem com grandes volumes de código disponível na internet, incluindo padrões inseguros, desatualizados ou errôneos. Isso significa que o código gerado pode conter:

erros lógicos difíceis de identificar em testes superficiais;
vulnerabilidades de segurança, como falhas em autenticação e problemas de validação de entrada;
práticas obsoletas, como o uso de bibliotecas descontinuadas ou abordagens ultrapassadas de arquitetura.
Se o código for colocado em produção sem validação adequada, esses riscos podem resultar em falhas sistêmicas, vazamentos de dados ou exploração de vulnerabilidades por ciberataques.

Sobre a dependência da IA, o uso frequente de ferramentas de codificação assistida sem reflexão crítica pode levar à perda de autonomia técnica. Isso significa que as pessoas desenvolvedoras podem deixar de praticar habilidades fundamentais como:

Estruturação lógica de algoritmos;
Escrita e interpretação de código limpo;
Análise de desempenho;
Compreensão de documentação e bibliotecas.
Problemas de propriedade intelectual

A IA pode gerar código com base em exemplos extraídos de repositórios públicos, como o GitHub, durante seu treinamento. Embora os modelos não copiem código diretamente, há o risco de reprodução parcial de trechos protegidos por licenças específicas (como GPL ou MIT). Isso pode gerar implicações legais, especialmente em produtos comerciais que exigem direitos autorais e licenças de software.

Como usar o vibe coding nas empresas? Apesar dos desafios envolvidos, a abordagem vibe coding, como vimos ao longo do texto, representa uma verdadeira faca de dois gumes.

Por um lado, há riscos que não podem ser ignorados, como a falta de compreensão total do código com IA gerado. Por outro lado, também existem benefícios concretos, como ganho de produtividade, aceleração na prototipação e mais fluidez nos processos criativos de desenvolvimento.

O que ninguém pode contestar é que essa prática já é uma realidade no mercado. Sendo assim, a questão que devemos evidenciar é: como as empresas podem usar o vibe coding de forma ética em seus projetos? Para isso, separamos algumas etapas abaixo que, para empresas que querem adotar essa abordagem, serão essenciais para enfrentar os desafios e usar essa tecnologia a favor da organização:

1ª etapa: fale com sua equipe e escolha a ferramenta - Antes de tudo, entenda como o vibe coding pode ser introduzido na sua empresa. Para isso, converse com seu time de desenvolvimento juntamente com a sua liderança tech para entender como essa abordagem pode ser benéfica para o setor. Nesta conversa, alinhe também os objetivos e, a partir deles, busque a ferramenta de vibe coding que mais se alinhe à equipe, como as opções que apresentamos anteriormente. A escolha deve considerar:

nível de autonomia desejado;
linguagens de programação utilizadas;
integração com plataformas já existentes (como AWS, Git, CI/CD).

2ª etapa: estabeleça diretrizes claras de uso - Para evitar usos irresponsáveis, as empresas devem criar políticas internas de governança de IA. Isso inclui padrões mínimos de validação de código e definições sobre onde e quando a IA pode ser usada, como nas fases de produção e prototipagem. Essas diretrizes equilibram criatividade e controle para promover responsabilidade e segurança, tanto para os projetos da empresa quanto para a equipe, pois mostra que o trabalho de seus colaboradores e colaboradoras é essencial e insubstituível no processo.

3ª etapa: capacite a equipe para trabalhar com IA - Implementar vibe coding exige uma mudança de processos, mas também de cultura. Para que as pessoas desenvolvedoras da sua empresa usem essa abordagem com eficiência, é preciso que toda a equipe seja treinada em letramento em IA. Assim, todas as pessoas podem conseguir formular prompts eficientes, avaliar criticamente as respostas da IA e melhorar os resultados gerados.

4ª etapa: acompanhe o uso e os resultados do vibe coding - Após implementar ferramentas e integrar o vibe coding ao fluxo de trabalho do seu time, é essencial monitorar continuamente seu uso e os impactos gerados. Essa etapa garante que a prática esteja realmente agregando valor ao desenvolvimento, além de ajudar a identificar pontos de melhoria e evitar desvios que comprometam a qualidade do código.

Para concluir, podemos resumir que o vibe coding representa uma oportunidade concreta de transformar a maneira como o software é construído dentro das empresas. Com uso responsável, processos bem definidos e capacitação das equipes, a IA pode se tornar uma aliada estratégica poderosa. Destacamos que o futuro do desenvolvimento corporativo não está em substituir pessoas desenvolvedoras por máquinas, mas sim em potencializar suas capacidades humanas com o apoio inteligente da tecnologia.

Docker

Isaac Alves Pinheiro — Wed, 24 May 2023 21:34:54 +0000

O Docker é um software/ plataforma open source para construir, armazenar, distribuir e rodar contêineres (containers são ambientes virtualizados, isolados e voláteis), o qual permite a equipe emular ambientes de desenvolvimento e que empacota um todo sistema operacional, como também a sua aplicação para dentro de um container.

Em 2013, foi criado o Docker, escrito na linguagem Go (Golang), por Solomon Hykes, onde o Docker começou como um projeto interno, inicialmente desenvolvido pelo dotCloud engineers, essa empresa é uma PaaS (Plataform as a Service), uma empresa que você manda o código da sua aplicação feita em Java, PHP, Node ou Python etc e a empresa toma todo o cuidado possível para você hospedar sua aplicação. Um exemplo de empresas PaaS são as empresas:

Heroku;
AWS - Amazon Web Services;
GCP - Google Cloud Plataform;
AZ - Microsoft Azure;

Quando o Docker nasceu, a dotCloud utilizava a AWS - Amazon Web Services, que é um serviço que provê VMs ou máquinas físicas, então ela queria hospedar na VM a aplicação dela, porém ela usou seu sistema de containers para subir sua aplicação, e assim nasceu o Docker, um intermediário entre um sistema operacional e seus containers contendo aplicações em uma mesma máquina.

De desktop a cloud, o Docker é considerado padrão e a ferramenta mais popular: é usado por milhões de desenvolvedores para construir e compartilhar aplicações conteinerizadas. Para termos uma ideia de volume, 30% das empresas usavam Docker em ambientes AWS, em 2019.

Embora seja uma das ferramentas de conteinerização mais usadas e conhecidas, o Docker não está sozinho. Há outros fornecedores no ecossistema: ConteinerD, CoreOS, Canonical, LXC Linux Conteiners, CRIO-D, OpenShift e Mesos Containerizer.

Além da empresa dotCloud ser focada em manter o Docker, ela também liberou o Docker para Open Source, exatamente isso, o Docker possui também código-livre para desenvolvimento!

Está tudo lá, as bibliotecas, as contribuições para o desenvolvimento de tecnologias do Docker.

Vantagens de um container Docker

Por não possuir um sistema operacional, o container é muito mais leve e não possui o custo de manter múltiplos sistemas operacionais, já que só teremos um sistema operacional, que será dividido entre os containers.

Além disso, por ser mais leve, o container é muito rápido de subir, subindo em questão de segundos. Logo, o container é uma solução para suprir o problema de múltiplas máquinas virtuais em um hardware físico, já que com o container, nós dividimos o sistema operacional entre as nossas aplicações.

Volátil, ou seja, sobe e mata um container, é da natureza do container sumir e subir rapidamente.

Necessidade do uso de containers Docker

Mas por que precisamos dos containers, não podemos simplesmente instalar as aplicações no nosso próprio sistema operacional? Até por que já fazemos isso, já que no nosso sistema operacional temos um editor de texto, terminal, navegador, etc.

No caso das nossas aplicações, essa abordagem pode ter alguns problemas. Por exemplo, se dois aplicativos precisarem utilizar a mesma porta de rede? Precisaremos de algo para isolar uma aplicação da outra. E se uma aplicação consumir toda a CPU, a ponto de prejudicar o funcionamento das outras aplicações? Isso acontece se não limitarmos a aplicação. Outro problema que pode ocorrer é cada aplicação precisar de uma versão específica de uma linguagem, por exemplo, uma aplicação precisa do Java 7 e outra do Java 8. Além disso, uma aplicação pode acabar congelando todo o sistema. Por isso é bom ter essa separação das aplicações, isolar uma da outra, e isso pode ser feito com os containers.

Com os containers, conseguimos limitar o consumo de CPU das aplicações, melhorando o controle sobre o uso de cada recurso do nosso sistema (CPU, rede, etc). Também temos uma facilidade maior em trabalhar com versões específicas de linguagens/bibliotecas, além de ter uma agilidade maior na hora de criar e subir containers, já que eles são mais leves que as máquinas virtuais.

Vamos agora ver as diversas tecnologias presentes no Docker e como são incríveis as possibilidades de se trabalhar em cada uma delas!

O ecossistema/ambiente do container Docker

O ambiente do container é todo um ecossistema de desenvolvimento, ou seja, toda uma infraestrutura com:

Os servidores web em NGINX ou Apache;
Banco de dados como PostgreSQL, MySQL, MongoDB, Cassandra, etc;
Os interpretadores de linguagem de programação como Python, Node.js, PHP, GO, Ruby, etc;
As bibliotecas e frameworks utilizadas para desenvolvimento, como o React.js, Django, Spring, etc.;
As scripts e plugins são arquivos de bash-script ou shell-script responsáveis por executar uma determinada ação no container, como: Automatizar alguma ação manual, Instalar programas adicionais, criar ou mudar configurações, preencher ambiente, etc.
As variáveis de ambiente são arquivos responsáveis por guardar segredos relacionados a qualquer informação sigilosa.

Então, é basicamente tudo o que a gente instala no nosso sistema operacional (Windows, Mac OS ou Linux) para conseguir fazer o desenvolvimento de software e rodar uma aplicação nela.

Com o Docker é possível resolver aquele velho problema dos desenvolvedores:

> Como assim!? Na minha máquina funciona, na sua não?

Etapas e ferramentas/modos do Docker

Além disso, existem algumas "etapas" com terminologias para a criação desses containers, pois afinal são uma evolução de VMs e não são instaladas por padrão na nossa máquina pessoal. São elas:

Image: Pacote com todas as dependências para criar o nosso container (nossa aplicação rodando no container);
Dockerfile: Arquivo de texto que contém todas as instruções para iniciar o processo de Build na nossa imagem do container;
Build: É uma ação que cria a imagem a partir do Dockerfile (lê as instruções e cria uma imagem);
Container: Feito a imagem pelo Build é instanciado o container (execução de uma aplicação, ou processo ou um serviço);
Volumes: Armazena dados em disco, ou seja, se o container morrer é o volume que salva os dados do container (os dados do container não serão perdidos dentro do volume);
Tags: Ajuda no versionamento das nossas imagens;
Multi-stage Build: Múltiplos estágios de Build onde usamos uma imagem para compilar a nossa aplicação, e essa chama outra imagem (Roy na Aplicação);
Repository: Nada mais é do que uma coleção de imagens, então é como se fosse uma caixa cheia de imagens;
Registry: É um serviço que provê acesso do Docker ao repositório, como o Docker Hub (repositório remoto de imagens de containers públicas e privadas);
Compose: É uma metadata que você pode executar múltiplos containers com um simples comando.

Docker Engine

As tecnologias de containers para prover ferramentas modernas para deployar e rodar aplicações.

Docker Compose

O Docker Compose é um modo do Docker onde podemos escalar e diminuir o número de containers necessário para nossa aplicação rodar com melhor aproveitamento, ou seja, é um jeito simples de definir múltiplos containers, o que é ideal para uma stack de tecnologia (.NET, Spring, LAMP, LEMP, MEAN, MERN, MENV, RoR, FReMP, etc), utilizar um balanceador de carga, banco de dados e até adotar a arquitetura de micro serviços.

No entanto, para aplicações e arquiteturas mais robustas é um pouco limitado em utilidades, se comparado ao modo Docker Swarm.

Docker Swarm

O Docker Swarm é um modo do Docker com uma ferramenta para orquestrar múltiplos docker engines para trabalharem juntos em um cluster com dezenas ou centenas de containers. As versões atuais do Docker incluem o modo swarm para gerenciar nativamente um cluster de Docker Engines chamado swarm (enxame). Use a CLI do Docker para criar um swarm, implantar serviços de aplicativo em um swarm e gerenciar o comportamento do swarm.

O modo Docker Swarm é integrado ao Docker Engine. E possui algumas utilidades:

Gerenciamento de cluster integrado ao Docker Engine: Use a CLI do Docker Engine para criar um enxame de Docker Engines onde você pode implantar serviços de aplicativos. Você não precisa de software de orquestração adicional para criar ou gerenciar um enxame.
Design descentralizado: em vez de lidar com a diferenciação entre as funções do nó no momento da implantação, o Docker Engine lida com qualquer especialização no tempo de execução. Você pode implantar os dois tipos de nós, gerentes e trabalhadores, usando o Docker Engine. Isso significa que você pode criar um enxame inteiro a partir de uma única imagem de disco.
Modelo de serviço declarativo: o Docker Engine usa uma abordagem declarativa para permitir que você defina o estado desejado dos vários serviços em sua pilha de aplicativos. Por exemplo, você pode descrever um aplicativo composto por um serviço de front-end da Web com serviços de enfileiramento de mensagens e um back-end de banco de dados.
Dimensionamento: Para cada serviço, você pode declarar o número de tarefas que deseja executar. Quando você aumenta ou diminui, o gerenciador de enxame se adapta automaticamente adicionando ou removendo tarefas para manter o estado desejado.
Reconciliação do estado desejado: O nó do gerenciador de swarm monitora constantemente o estado do cluster e reconcilia quaisquer diferenças entre o estado real e o estado desejado expresso. Por exemplo, se você configurar um serviço para executar 10 réplicas de um contêiner e uma máquina de trabalho que hospeda duas dessas réplicas falhar, o gerente criará duas novas réplicas para substituir as réplicas que falharam. O gerenciador de swarm atribui as novas réplicas aos trabalhadores que estão em execução e disponíveis.
Rede multi-host: você pode especificar uma rede de sobreposição para seus serviços. O gerenciador de swarm atribui automaticamente endereços aos contêineres na rede de sobreposição quando inicializa ou atualiza o aplicativo.
Descoberta de serviço: os nós do Swarm Manager atribuem a cada serviço no Swarm um nome DNS exclusivo e equilibram a carga dos contêineres em execução. Você pode consultar todos os contêineres em execução no enxame por meio de um servidor DNS incorporado no enxame.
Balanceamento de carga: você pode expor as portas para serviços a um balanceador de carga externo. Internamente, o enxame permite especificar como distribuir contêineres de serviço entre os nós.
Seguro por padrão: cada nó no enxame impõe autenticação e criptografia mútuas TLS para proteger as comunicações entre ele e todos os outros nós. Você tem a opção de usar certificados raiz autoassinados ou certificados de uma CA raiz personalizada.
Atualizações contínuas: no momento da implementação, você pode aplicar atualizações de serviço aos nós de forma incremental. O gerenciador de enxame permite controlar o atraso entre a implantação do serviço em diferentes conjuntos de nós. Se algo der errado, você pode reverter para uma versão anterior do serviço.

Docker Machine

Uma ferramenta que nos permite instalar e gerenciar o Docker Engine em hosts virtuais, com comandos docker-machine.

Você pode usar o Machine para criar hosts do Docker em sua caixa local do Mac ou Windows, na rede da empresa, no data center ou em provedores de nuvem como Azure, AWS ou Digital Ocean.

> O Docker encerrou o desenvolvimento ativo e o suporte para o Docker Machine. Um método principal para escalonamento automático do GitLab runner em instâncias de máquina virtual de nuvem pública é o Runner configurado com o executor do Docker Machine.

Docker Hub

Um repositório com mais de 250 mil imagens diferentes para os nossos containers. Para instalar, você precisa ter os seguintes requisitos:

Um sistema de 64 bits;
Se você utiliza o Windows 10, você precisar utilizar a versão Windows 10 PRO;
Habilitar a virtualização do Windows;

Play with Docker

https://labs.play-with-docker.com/

Esse é um ambiente totalmente grátis para testar a todos os recursos do Docker pela web, o que facilita muito no aprendizado para iniciantes! Com práticas e exercícios.

Você verá que cada instância é um nó com seu endereço de IP e tem tempo para escalar seus ambientes antes que eles sejam removidos.

> Em exemplos posteriores, vamos utilizar o modo Docker Swarm com Flask e Hashicorp Consul como malha de serviço!

Instalação do Docker

Linux

sudo apt update
sudo apt install -y docker.io
sudo systemctl enable docker --now
docker

Windows

Habilitar a Virtualização de CPU na BIOS (programa da placa-mãe) do seu computador
Baixar o pacote de atualização do kernel do Linux (WSL 2)

https://docs.microsoft.com/pt-br/windows/wsl/install-win10#step-4---download-the-linux-kernel-update-package

Seguimos o passo a passo do instalador para aceitar a licença, autorizamos o instalador e seguimos com a instalação. Ao clicar em Finish, precisamos encerrar a sessão do Windows e iniciá-la novamente. Ao fazer o login, precisamos habilitar o Hyper-V, clicando em Ok, para que o computador será reiniciado.

Quando o computador terminar a reinicialização, irá aparecer um ícone do Docker na barra inferior, à direita, ao lado do relógio. O Docker pode demorar um pouco para inicializar, mas quando a mensagem Docker is running for exibida, significa que ele foi instalado com sucesso e já podemos utilizá-lo.

Exibir a versão do Docker

docker --version

Exibir os todos os dados do Docker

docker version

Lembrando que você precisa estar executando o Docker na sua máquina.

`Hello, World!` - Docker

docker run hello-world

Lembrando que quando aparece a seguinte mensagem no terminal Unable to find image 'hello-world' locally, significa que o docker não achou a imagem localmente, mas sim precisou buscar a imagem e baixar ela!

Imagens e Containers

Na aula anterior, para executar a imagem hello-world, executamos o comando docker run hello-world.

Quando executado esse comando, a primeira coisa que o Docker faz é verificar se temos a imagem hello-world no nosso computador, e caso não tenhamos, o Docker buscará e baixará essa imagem no Docker Hub/Docker Store.

A imagem é como se fosse uma receita de bolo, uma série de instruções que o Docker seguirá para criar um container, que irá conter as instruções da imagem, do hello-world. Criado o container, o Docker executa-o. Então, tudo isso é feito quando executamos o docker run hello-world.

Há milhares de imagens na Docker Store disponíveis para executarmos a nossa aplicação. Por exemplo, temos a imagem do Ubuntu:

Rodar a imagem do Sistema Operacional Ubuntu

docker run ubuntu

É normal o nome do container ser seguida de nomes aleatórios, não tem problema nenhum! a imagem possui o nome escrita em azul para você identificar no Docker Desktop, assim como no terminal também informa.

Listar todos os containers ativos no momento

docker ps

Listar todos os containers que eu criei

docker ps -a

Listar todos os containers que eu criei (somente os id's)

docker ps -q

Executar um Olá, Mundo dentro do container do Ubuntu

docker run ubuntu echo "Ola Mundo"

Interagir mais com o container do Ubuntu

docker run -it ubuntu

Dessa forma, ele retorna o terminal do Ubuntu:

root@9fea4151a9f8:/#

Se você rodar qualquer comando do Linux irá funcionar, porém não dentro do Sistema Operacional, mas sim dentro do container.

root@9fea4151a9f8:/# ls

Retorno:

bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

Para sair é só ctrl+D ou exit.

Startando o container

docker ps -a
docker start [id do container]
docker ps

Como também:

docker start -a -i [3 dígitos iniciais do id do container]

Agora vamos brincar, digite a série de comandos de entrada abaixo:

ls
touch hello-world.txt
ls
echo "Hello, World!" &gt; hello-world.txt
cat hello-world.txt

Saída:

Hello, World!

Startando o container de forma interativa

docker start -it [nome do container]

Sai do container interativo, mas desejo voltar novamente

docker start -a -i [id-do-container]

Ou também você pode usar a seguinte forma:

docker start [nome container]
docker exec -it [nome do container] bash

Parar o container

docker stop [id do container]

Existem formas mais eficientes de rodar ou parar o docker, pois a execução as vezes demora muito...Para saber mais, use:

docker stop --help

Então, com a lista de parâmetros, utilizaremos o parâmetro -t e com ele podemos, instantaneamente, executar o tempo de uma execução no docker, como:

docker stop -t 0 [3 dig. do id do container]

Parar mais de um id

docker stop $(docker ps -q)

docker stop -t 0 $(docker ps -q)

Layered File System

Aqueles dois principais estados de um container, quando criamos um ou iniciamos, ele fica no estado de running, e quanto a sua execução encerra ou
paramos, ele fica no estado de stopped:

Limpar container

docker prune

Limpar containers inativos

docker container prune

Deletar ou Remover containers

docker rm [id do container]

Deletar todos os containers

docker container prune

Remover ou Deletar as imagens do Docker

docker image prune

Remover ou Deletar todas as imagens do Docker

docker system prune

Remover ou deletar um Volume

docker volume prune

Forçar remover um container

docker rm -f [id do container]

Listando imagens

docker images

Removendo imagens

docker rmi [container]

Ver logs de um container

docker logs [ID do container]

E do mesmo jeito que temos o comando docker container para mexermos com o container, temos o comando docker images, que nos exibe as imagens que temos na nossa máquina. Para remover uma imagem, utilizarmos o comando docker rmi, passando para ele o nome da imagem a ser removida, por exemplo:

Rodar uma determinada versão da imagem

docker run ubuntu:14.04

Camada de imagens

Quando baixamos a imagem do Ubuntu, reparamos que ela possui camadas, mas como elas funcionam? Toda imagem que baixamos é composta de uma ou mais camadas, e esse sistema tem o nome de Layered File System.

As pricincipais características das camadas, são:

As camadas na imagem são de leitura apenas;
Essas camadas podem ser reaproveitadas em outras imagens, acelerando assim o tempo de download;
Toda imagem que baixamos é composta de uma ou mais camadas.

Essas camadas podem ser reaproveitadas em outras imagens. Por exemplo, já temos a imagem do Ubuntu, isso inclui as suas camadas, e agora queremos baixar a imagem do CentOS. Se o CentOS compartilha alguma camada que já tem na imagem do Ubuntu, o Docker é inteligente e só baixará as camadas diferentes, e não baixará novamente as camadas que já temos no nosso computador:

No caso da imagem acima, o Docker só baixará as duas primeiras camadas da imagem do CentOS, já que as duas últimas são as mesmas da imagem do Ubuntu, que já temos na nossa máquina. Assim poupamos tempo, já que precisamos de menos tempo para baixar uma imagem.

Uma outra vantagem é que as camadas de uma imagem são somente para leitura. Mas como então conseguimos criar arquivos na aula anterior? O que acontece é que não escrevemos na imagem, já que quando criamos um container, ele cria uma nova camada acima da imagem, e nessa camada podemos ler e escrever:

Então, quando criamos um container, ele é criado em cima de uma imagem já existente e nele nós conseguimos escrever. E com uma imagem base, podemos reaproveitá-la para diversos containers:

Isso nos traz economia de espaço, já que não precisamos ter uma imagem por container.

Praticando com o `docker run`

Já podemos fazer um container mais interessante, um pouco mais complexo. Então, vamos criar um container que segurará um site estático, para entendermos também como funciona a parte de redes do Docker. Para tal, vamos baixar a imagem dockersamples/static-site:

docker run dockersamples/static-site

As imagens não oficiais, ou seja, imagens de terceiros, precisam ser especificadas pelo username e pela imagem.

Baixando a imagem apenas pelo docker, sem atrelar ao terminal

docker run -d dockersamples/static-site

Se você executar os dois comandos, criará dois containers diferentes, pois o Docker é inteligente no quesito de solicitações de imagem, ele sabe criar um id e ambientes diferentes!

Acessando o site

docker run -d -P [nome da imagem]

A flag -P significa que fará com que o Docker atribua uma porta aleatória do mundo externo, que no caso é a nossa máquina, para poder se comunicar com o que está dentro do container.

Abrindo uma porta externa para uma interna

Vamos ver como abrir portas e acessar o site com elas.

Descobrir a porta

docker ps

Descobrir a porta de uma maneira mais legível

docker port [id do container]

Logo, ele retornará a porta pelo protocolo TCP:

80/tcp -> 0.0.0.0:49155
80/tcp -> :::49155
443/tcp -> 0.0.0.0:49154
443/tcp -> :::49154

Se você copiar o endereço:

:49155

E ir para o browser digitando na aba do navegador:

localhost:49155

Você verá o preview do site estático!

Nomeando um container

docker run -d -P --name [nome do container] [nome da imagem]

Acessando os detalhes do container

dive [nome do container]

Dessa forma, ele irá nomear o container que possuia um nome aleatório, isso facilita nosso aprendizado e nossos projetos.

Renomeando um container

docker rename [nome ou id do container] [novo nome]

Mapeando portas do computador para a porta do servidor

docker run -d -p 12345:80 [nome da imagem]

Assim, ele muda o endereço da porta do localhost para 12345.

Definindo a variável autor

docker run -d -P -e AUTHOR="seu username" [imagem]

Dessa forma, ele apresentará você no site estático. Mas primeiro acesse o endereço ip que ele mudou!

docker ps

Dessa foma, coloque junto ao localhost.

Docker para DevOps

DevOps é um tópico bem amplo que envolve tanto aspectos culturais como técnicos, mas possui como principal objetivo aumentar a qualidade e eficiência da entrega de software. DevOps é uma metodologia que visa integrar os times de desenvolvimento com infraestrutura e o Docker está tendo um papel importante nessa tarefa.

Repare que com Docker os desenvolvedores não precisam se preocupar em configurar um ambiente de desenvolvimento específico de cada vez. Em vez disso, eles podem se concentrar na construção de um código de boa qualidade. Isso, obviamente, leva à aceleração nos esforços de desenvolvimento. O Docker facilita muito construir o ambiente: é rapido, simples e confiável.

No outro lado, para a equipe de operações de TI/Sysadmins, o Docker possibilita configurar ambientes que são exatamente como um servidor de produção e permite que qualquer pessoa trabalhe no mesmo projeto com exatamente as mesmas configurações, independentemente do ambiente de host local. As configurações são descritas em arquivos simples facilmente aplicáveis pelo desenvolvedor.

Com a padronização de um entregável Docker é possível que o desenvolvedor tenha um ambiente similar ao de produção na sua máquina sem todo o custo de configuração e o Sysadmin consiga lidar apenas com um tipo de entregável conseguindo, desta forma, dar atenção aos desafios de monitoramento e orquestração para que nada dê errado. Neste caso, o melhor para os dois.

Salvando dados com volumes

É da natureza dos containers a volatilidade, isto é, eles são criados e removidos rapidamente e facilmente, mas devemos ter um lugar para salvar os dados, e esse lugar são os volumes.

Quando escrevemos em um container, assim que ele for removido, os dados também serão. Mas podemos criar um local especial dentro dele, e especificamos que esse local será o nosso volume de dados.

Quando criamos um volume de dados, o que estamos fazendo é apontá-lo para uma pequena pasta no Docker Host. Então, quando criamos um volume, criamos uma pasta dentro do container, e o que escrevermos dentro dessa pasta na verdade estaremos escrevendo do Docker Host. Ou seja, fica salvo no computador onde a Docker Engine está rodando.

Isso faz com que não percamos os nossos dados, pois o container até pode ser removido, mas a pasta no Docker Host ficará intacta.

Trabalhando com volumes

Sabendo disso, vamos ver como trabalhar com o Docker Host. No Terminal ou PowerShell (ou Docker Quickstart Terminal), criamos um container com o docker run, mas dessa vez utilizando a flag -v para criar um volume, seguido do nome do mesmo:

docker run -v "/var/www" ubuntu

No exemplo acima, criamos o volume /var/www, mas a que pasta no Docker Host ele faz referência? Para descobrir, podemos inspecionar o container, executando o comando docker inspect, passando o seu id para o mesmo:

Inspecionando o container

docker inspect [id do container]

Ele retornará uma série de dados, mas o mais importante, no momento, é o Mounts:

      "Mounts": [
            {
                "Type": "volume",
                "Name": "54a5fad5f6c046a4afad7854caf90089a40d9c9d60d3eb604982b6084b799cc2",
                "Source": "/var/lib/docker/volumes/54a5fad5f6c046a4afad7854caf90089a40d9c9d60d3eb604982b6084b799cc2/_data",
                "Destination": "/var/www",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            }
         ]

Mesmo se eu remover o container, mas se tiver algo escrito no destination /var/www ele ainda vai existir, pois o que está escrito lá está ligada ao Docker Host, como se fosse um link.

Portanto, os dados vão continuar ainda dentro do computador.

Iniciando uma escrita no volume (montando ou linkando em /var/www pelo desktop)

docker run -it -v "C:\Users\Alura\Desktop:/var/www" ubuntu

Os : servem para separar os dois meios do container que vai rodar a imagem do ubuntu.

Funcionou, então:

root@abd0286c0083:/#

ls
cd var/www/
touch novo-arquivo.txt
echo "este arquivo foi criado dentro de um volume" &gt; novo-arquivo.txt
cat novo-arquivo.txt
touch segundo-arquivo.txt
ls

O que acontece se eu remover esse container?

Continuando o tópico acima, vamos sair do container e remover ele:

exit
docker ps -a
docker container prune

Aquela camada do container foi removida, porém os seus arquivos ainda permaneceram na sua Desktop!

[Stand alone] Rodando código em apenas um container Docker

Já vimos que o que escrevemos no volume (pasta /var/www do container) aparece na pasta configurada da nossa máquina local, que no vídeo anterior foi o Desktop. Mas podemos pensar o contrário, ou seja, tudo o que escrevemos no Desktop será acessível na pasta /var/www do container.

Isso nos dá a possibilidade de implementar localmente um código de uma linguagem que não está instalada na nossa máquina, e colocá-lo para compilar e rodar dentro do container. Se o container possui Node, Java, PHP, seja qual for a linguagem, não precisamos tê-los instalados na nossa máquina, nosso ambiente de desenvolvimento pode ser dentro do container.

É isso que faremos, pegaremos um código nosso, que está na nossa máquina, e colocaremos para rodar dentro do container, utilizando essa técnica com volumes.

Para isso, vamos usar um exemplo escrito Node.js. Até podemos executar esse código na nossa máquina, mas temos que instalar o Node na versão certa em que o desenvolvedor implementou o código.

Agora, como fazemos para criar um container, que irá pegar e rodar esse código Node que está na nossa máquina? Vamos utilizar os volumes. Então, vamos começar a montar o comando.

Primeiramente, como vamos rodar um código em Node.js, precisamos utilizar a sua imagem:

docker run node

docker run -d -P --name running-node.js node

docker ps -a
docker ps -a -q

Além disso, precisamos criar um volume, que faça referência à pasta do código no nosso Desktop:

docker run -it -v "C:\Users\Dell\Desktop\volume-exemplo:/var/www" node

Mas para fazer esse servidor rodar, precisamos inserir o famoso NPM (Node Package Manager), com o comando npm start:

docker run -it -v "C:\Users\Dell\Desktop\volume-exemplo:/var/www" node npm start

Mas de acordo com a nossa aplicação, está programada para abrir a porta (endereço de ip) :3000:

docker run -p 8080:3000 -v "C:\Users\Dell\Desktop\volume-exemplo:/var/www" node npm start

Não funcionou, devido o nosso container não rodar na pasta /var/www e sim numa pasta aleatória! No caso do Ubuntu, ele rodou na pasta do boot do Ubuntu, então para ele rodar o comando do npm devemos especificar onde ele deve abrir o meu container!

Para isso passaremos mais uma flag, a -w que significa "working directory", então é só referenciar nosso diretório a ele:

[Stand alone] Código completo do Docker + Node.js

docker run -d -p 8080:3000 -v "C:\Users\Dell\Desktop\volume-exemplo:/var/www" -w "/var/www" node npm start

Feito todos esses passos, o container irá funcionar no localhost:8080.

Eu posso modificar esse arquivo e atualizar a página localmente, que o servidor vai automaticamente atualizar. Portanto, eu tenho um ambiente de desenvolvimento dentro do meu desktop.

O container pode ser compartilhado entre a equipe e todos conteram a mesma versão dos programas e do ambiente.

Portanto, isso já resolve aquele velho erro de produção:

> Funcionou na minha máquina, na sua não? Como assim!? 🤔😕

> Então, se funcionou em uma máquina, funcionou em todas as máquinas! Esse é o grande benefício do Docker! 🐋 🐳 💙

Interpolação de comando

docker run -d -p 8080:3000 -v "$(pwd):/var/www" -w "/var/www" node npm start

[Stand alone] Dockerfile

docker images

Já trabalhamos com a imagem do ubuntu, hello-world, dockersamples/static-site e por fim do node, mas até agora não criamos a nossa própria imagem, para podermos distribuir para as outras pessoas.

A imagem é como se fosse uma receita de bolo. Então, para criarmos a nossa própria imagem, temos que criar a nossa receita de bolo, o Dockerfile (arquivo Docker), ensinando o Docker a criar uma imagem a partir da nossa aplicação, para que ela seja utilizada em outros locais.

O Dockerfile nada mais é do que um arquivo de texto, e ele possui o nome identificador, porém se alterarmos o nome com o identificador , como node.dockerfile, ele será reconhecido, mesmo assim. No caso de possuir muitos Dockerfile é realmente interessante modificar o nome pela tecnologia que você está utilizando.

Vamos agora, distribuir nosso arquivo para que os outros desenvolvedores possam utilizar, para isso utilizaremos os comandos do Dockerfile:

[Stand alone] Montando imagem no Dockerfile

Você pode criar do zero ou pegar uma imagem base para isso! Vamos fazer nosso dockerfile se basear no node, então:

FROM node:latest
MAINTAINER isaacalves7 
ENV NODE_ENV=production
ENV PORT=3000
COPY . /var/www
WORKDIR /var/www
RUN npm install 
ENTRYPOINT npm start ["npm", "start"]
EXPOSE $PORT

Identificamos com o FROM e depois imputamos a imagem e o sinal : servem para especificar a versão da imagem, no caso latest (última versão);
Outra instrução que é comum colocarmos é quem cuida, quem criou a imagem, através do MAINTAINER;
Variável de ambiente ENV, servem apenas para não gerar um log ao cliente;
Com o COPY copiamos nosso diretório padrão para rodar o node;
Com o WORKDIR assim que o container carregar o diretório, ele executará o mesmo com o npm start;
Com o RUN instalamos nossas dependências necessárias. E assim, podemos deletar a pasta node_modules, pois o que vale é apenas o dockerfile;
Com o ENTRYPOINT, cujo gerencia as dependências com base no JSON.

Feito a imagem, é hora de buildar essa imagem, para isso devemos ir ao terminal e inserir:

docker build -f Dockerfile -t isaacalves7/node-file .

Após rodar esse comando, o docker fará dele uma imagem. Portanto:

docker images

Dessa forma, poderá startar o comando dentro do repositório do arquivo:

docker run -d -p 8080:3000 isaacalves7/node-file

Podemos alterar a variável de ambiente:

docker run -d -p 1234:8080 isaacalves7/node-file

[Stand alone] Subindo imagens no Docker Hub

Faça sua conta no Docker Hub, depois ensira os comandos no terminal:

docker login
docker push [nome da imagem]

No caso docker login é para se logar no Docker Hub, para ele reconhecer nosso ambiente e usuário.

Depois, inserimos docker push [nome da imagem] para ele subir nossa imagem no Docker Hub, para outros usuários terem acesso!

Somente baixar a imagem

docker pull [nome da imagem]

Link do meu perfil:

🖧 Networking no Docker (Tipos de Redes)

Veremos como funciona a rede, e como fazemos para interligar diversos containers no Docker. Normalmente uma aplicação é composta por diversas partes, sejam elas o load balancer/proxy, a aplicação em si, um banco de dados, etc. Quando estamos trabalhando com containers, é bem comum separarmos cada uma dessas partes em um container específico, para cada container ficar com somente uma única responsabilidade.

Mas se temos uma parte da nossa aplicação em cada container, como podemos fazer para essas partes falarem entre elas? Pois para a nossa aplicação funcionar como um todo, os containers precisam trocar dados entre eles.

Bridge network

Host network

Overlay network

A boa notícia é que no Docker, por padrão, já existe uma default network, que no caso é a rede bridge. Isso significa que, quando criamos os nossos containers, por padrão eles funcionam na mesma rede:

[Stand alone] Verificando o default container com o Ubuntu

docker run -it ubuntu

[Stand alone] Inspecionando a rede

docker inspect [id container]

"Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "905b02e0985ba89a81e437141cfbc432e7aa82c73fd51b2979ef989c9f8ec2a5",
                    "EndpointID": "",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "",
                    "DriverOpts": null
                }

Logo, inserimos o comando:

hostname -i
ping 172.17.0.3

Depois disso, o comando não funcionará, pois a imagem do Ubuntu só possui o básico para o Ubuntu funcionar via container.

Para isso, precisamos utilizar os comandos do Linux, como o de instalação de pacotes:

apt-get update &amp;&amp; apt-get install

Agora o nome do pacote:

apt-get update &amp;&amp; apt-get install -y iputils-ping

O iputils-ping serve para fazer o ping dentro do container.

ping --help
ping 172.17.0.3

Comunicação de containers

docker network create --driver bridge [nome da rede]
docker network ls

Criando um novo container atrelada a rede

docker run -it --name meu-container-de-ubuntu --network [nome da rede] ubuntu
docker inspect [nome do container]

Pegando dados de um banco

Para praticar o que vimos sobre redes no Docker, vamos criar uma pequena aplicação que se conectará ao banco de dados, utilizando tudo o que vimos no vídeo anterior.

O que vamos fazer é utilizar a aplicação alura-books, que irá pegar os dados de um banco de dados de livros e exibi-los em uma página web. É uma aplicação feita em Node.js e o banco de dados é o MongoDB.

Pegando dados de um banco em um outro container

Então, primeiramente vamos baixar essas duas imagens, a imagem douglasq/alura-books na versão cap05 e a imagem mongo:

docker pull douglasq/alura-books:cap05
docker pull mongo
docker images

Na imagem douglasq/alura-books, não há muito mistério. Ela possui o arquivo server.js, que carrega algumas dependências e módulos que são instalados no momento em que rodamos a imagem. Esse arquivo carrega também as configurações do banco, que diz onde o banco de dados estará em execução, no caso o seu host será meu-mongo, e o database, com nome de alura-books. Então, quando formos rodar o container de MongoDB, seu nome deverá ser meu-mongo. Além disso, o arquivo realiza a conexão com o banco, configura a porta que será utilizada (3000) e levanta o servidor.

No Dockerfile da imagem, também não há mistério, é basicamente o que vimos no vídeo anterior. Por fim, temos as rotas, que são duas: a rota /, que carrega os livros e os exibe na página, e a rota /seed, que salva os livros no banco de dados.

Caso queira, você pode baixar aqui o código da versão cap05 da imagem alura-books.

Visto isso, já podemos subir a imagem:

docker run -d -p 8080:3000 douglasq/alura-books:cap05

Ao acessar a página http://localhost:8080/, nenhum livro nos é exibido, pois além de não termos levantado o banco de dados, nós não salvamos nenhum dado nele.

docker rm -f 43

Então, vamos excluir esse container e subir o container do MongoDB, lembrando que o seu nome deve ser meu-mongo, e vamos colocá-lo na rede que criamos na sessão anterior:

docker run -d --name meu-mongo --network minha-rede mongo

Com o banco de dados rodando, podemos subir a aplicação do mesmo jeito que fizemos anteriormente, mas não podemos nos esquecer que ele deve estar na mesma rede do banco de dados, logo vamos configurar isso também:

docker run --network minha-rede -d -p 8080:3000 douglasq/alura-books:cap05

Verificando a rede:

docker network ls
docker inspect minha-rede

Possuimos então dois containers na mesma rede (minha-rede):

"Containers": {
            "7dcce72922f00b3e3db3c9bc925c72cefb6495b0bb6e6d4a525629b62cc5a297": {
                "Name": "meu-mongo",
                "EndpointID": "89bb420463f092d057118137ce5b08d936194cae35db7f9886e3afcd8612042e",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            },
            "c68d8bbc9cdaea5fe75a3fce1e024eb6251f72e762c38b76670dd0ee7049d911": {
                "Name": "dreamy_wilbur",
                "EndpointID": "c3010c6d9c05af02d38b8816530677199d020b9c01d232f9fb86037375a3f5a4",
                "MacAddress": "02:42:ac:12:00:03",
                "IPv4Address": "172.18.0.3/16",
                "IPv6Address": ""
            }

Agora, acessamos a página http://localhost:8080/seed/ para salvar os livros no banco de dados. Após isso, acessamos a página http://localhost:8080/ e vemos os dados livros são extraídos do banco e são exibidos na página.

Para provar isso, podemos parar a execução do meu-mongo e atualizar a página, veremos que nenhum livro mais será exibido.

docker stop meu-mongo
docker ps

Então, esse foi um exemplo para praticar a comunicação entre containers, sempre lembrando que devemos colocá-los na mesma rede.

Docker Swarm

Ok, tudo bem até aqui. Agora vou ter vários serviços rodando usando o Docker. E para facilitar a criação desses containers já aprendemos usar o Docker Compose que sabe subir vários containers. O Docker Compose é a ferramenta ideal para coordenar a criação dos containers, no entanto para melhorar a escalabilidade e desempenho pode ser necessário criar muito mais containers para um serviço específico.

Em outras palavras, agora gostaríamos de criar muitos containers aproveitando várias máquinas (virtuais ou físicas)! Ou seja, pode ser que um microsserviço fique rodando em 20 containers usando três máquinas físicas diferentes. Como podemos facilmente subir e parar esses containers? Repare que o Docker Compose não é para isso e por isso existe uma outra ferramenta que se chama Docker Swarm.

Docker Swarm facilita a criação e administração de um cluster de containers.

Network: Bridge Mode

docker network create -d bridge petaBridge
docker network ls
docker run -d --net petaBridge --name db consul:latest
docker run -d --env "DB=db" --net petaBridge --name web -p 8000:5000 poroko/flask-demo-app
docker ps -a
docker exec -it web bash
bash$ ls
bash$ exit
docker exec -it web sh

Network: Host Mode

docker run -d --net host --name db consul 
docker run -d --env "DB=localhost" --net host poroko/flask-demo-app
docker ps
netstat -nltp

WARNING: Nesse modelo de rede, você não pode colocar outra aplicação da mesma linguagem na mesma porta, você precisa abrir outra porta!

[SWARM] Duas instâncias em rede bridge

Faremos um Docker Swarm, onde uma das duas máquinas será o gerenciador, ou seja, o principal controlando os demais nós desse cluster (no caso, a máquina).

Container de front-end (Flask = chrch/docker-pets:1.0 = web) e rede Bridge (petsBridge). No caso, esse vai ser o container principal do Docker SWARM.

Podemos escalonar o tráfego de rede com o Docker SWARM, criando assim o Load Balancer entre os dois containers (cada um em uma instância diferente).

docker network create -d bridge petsBridge
docker run -it --env "DB=db" --net petsBridge --name web -p 8000:5000 chrch/docker-pets:1.0
docker ps -a
docker restart [id do container]
ifconfig
docker swarm init --advertise-addr [IP do container]
> docker swarm join --token SWMTKN-1-1qrnyxbd5bja864nx27sdzpuwd52j60kdt1350ox42h45pkage-1jrrm0afvugxzdin34a5y6k1y 192.168.0.28:2377
docker node ls
hostname
docker network create -d overlay petsOverlay 
docker service create --network petsOverlay --name db consul
docker service create --network petsOverlay -p 8000:5000 -e "DB=db" --name web chrch/docker-pets:1.0
docker service ls
docker service scale web=3

Container de back-end (Consul = db) e rede Bridge (petsBridge). Esse será chamado através do token de acesso do docker swarm para se juntar com o outro container, ligados pelo mesmo modelo de rede.

docker network create -d bridge petsBridge
docker run -d --net petsBridge --name db consul
docker swarm join --token SWMTKN-1-1qrnyxbd5bja864nx27sdzpuwd52j60kdt1350ox42h45pkage-1jrrm0afvugxzdin34a5y6k1y 192.168.0.28:2377
docker logs [ID container]
netstat -nltp

Armazenamento no Docker (Docker storage)

Tanto o bind mounts quanto o volume, se o container for removido ou reiniciado, as informações serão persistidas em disco.

O tmpfs mounts é um disco temporário para guardar logs e caches da sua aplicação, o container for reiniciado ou removido esses arquivos serão deletados, ou seja, não foram para a camada de escrita do container.

Exemplo 1: Criando volume

docker volume create meuPrimeiroVolume
docker volume ls
docker volume inspect meuPrimeiroVolume
docker run -d -p 80:80 --name container-volume --mount source=meuPrimeiroVolume,nginx:latest

Limites no Docker

Precisamos ter limites de memória e CPU no Docker, se acaso a sua aplicação consumir muito recurso de memória ou CPU desnecessariamente, siga o exemplo abaixo:

docker run -d --memory 10m busybox sleep 3600
docker stats
docker run --cpus=".5" -d --rm programium/stress -c 8 -t 50s

Docker Compose

Agora vamos subir múltiplos containers! Mas como? Simples! Basta rodar os dois comandos ao mesmo tempo:

docker run -d --name meu-mongo --network rede-producao mongo
docker run -d -p 3000:3000 --name alura-books --network rede-producao douglasq/alura-books

Contudo, essa forma de subir containers é um tanto falha, pois possue a maior probabilidade de:

Esquecer de uma flag;
Esquecer um parâmetro importante;
Muito manual;
Fácil de errar;
Preciso garantir a ordem.

[Compose] Funcionamento das aplicações em geral

Na vida real, sabemos que a aplicação é maior que somente dois containers, geralmente temos dois, três ou mais containers para segurar o tráfego da aplicação, distribuindo a carga. Além disso, temos que colocar todos esses containers para se comunicar com o banco de dados em um outro container, mas quanto maior a aplicação, devemos ter mais de um container para o banco também.

E claro, se temos três aplicações rodando, não podemos ter três endereços diferentes, então nesses casos utilizamos um Load Balancer em um outro container, para fazer a distribuição de carga quando tivermos muitos acessos. Ele recebe as requisições e distribui para uma das aplicações, e ele também é muito utilizado para servir os arquivos estáticos, como imagens, arquivos CSS e JavaScript.

Assim, a nossa aplicação controla somente a lógica, as regras de negócio, com os arquivos estáticos ficando a cargo do Load Balancer:

Se formos seguir esse diagrama, teríamos que criar cinco containers na mão, e claro, cada container com configurações e flags diferentes, além de termos que nos preocupar com a ordem em que vamos subi-los. Ou seja, subir 5 flags na mão??? subir tudo isso de forma manual??? Que trabalhooooo....

Então, para isso foi criada uma ferramenta no Docker chamada Docker Compose, que ele executa e auxilia na build ou criação de vários (múltiplos) containers simultaneamente. Ele funciona seguindo um arquivo de texto, chamado docker-compose.yaml.

Esse arquivo serve para dar um conjunto de passos ao Docker e com ele podemos controlar quais containers sobem primeiro, ou seja, funciona como um processo de BIOS ou um automatizador de containers.

O Docker Compose cria uma rede padrão. Também é possível criar uma nova rede usando o comando docker network.

OBS: O YAML é semelhante ao JSON.

Seguindo o mesmo diagrama, vejamos nossa nova aplicação rodando atualizada para o uso do Docker Compose:

O código do projeto pode ser baixado aqui.

Para começarmos a entender como funciona o Docker Compose, primeiramente vamos entender como funciona a aplicação que utilizaremos como base. É uma aplicação bem semelhante à utilizada na sessão anterior, com o mesmo servidor, rotas e banco de dados. De novidade, é que agora precisamos criar o NGINX, que é mais um container que devemos subir.

Então, ao utilizamos a imagem nginx, ou criamos a nossa própria. Como vamos configurar o NGINX para algumas coisas específicas, como lidar com os arquivos estáticos, vamos criar a nossa própria imagem, por isso que na aplicação há o nginx.dockerfile:

FROM nginx:latest
MAINTAINER isaacalves7
COPY /public /var/www/public
COPY /docker/config/nginx.conf /etc/nginx/nginx.conf
EXPOSE 80 443
ENTRYPOINT ["nginx"]
# Parametros extras para o entrypoint
CMD ["-g", "daemon off;"]

Nesse arquivo, nós utilizamos a última versão disponível da imagem do nginx como base, e copiamos o conteúdo da pasta public, que contém os arquivos estáticos, e um arquivo de configuração do NGINX para dentro do container. Além disso, abrimos as portas 80 e 443 e executa o NGINX através do comando nginx, passando os parâmetros extras -g e daemon off.

Por fim, vamos ver um pouco sobre o arquivo de configuração do NGINX, para entendermos um pouco como o load balancer está funcionando.

No arquivo nginx.conf, dentro server, está a parte que trata de servir os arquivos estáticos. Na porta 80, no localhost, em /var/www/public, ele será responsável por servir as pastas css, img e js. E todo resto, que não for esses três locais, ele irá jogar para o node_upstream.

No node_upstream, é onde ficam as configurações para o NGINX redirecionar as conexões que ele receber para um dos três containers da nossa aplicação. O redirecionamento acontecerá de forma circular, ou seja, a primeira conexão irá para o primeiro container, a segunda irá para o segundo container, a terceira irá para o terceiro container, na quarta, começa tudo de novo, e ela vai para o primeiro container e assim por diante.

Isso já está tudo pronto, basta baixarmos o código da imagem e da aplicação aqui.

Criando o `docker-compose.yaml`

Tanto faz as duas extensões, as duas são a mesma linguagem!

Para utilizar o Docker Compose, devemos criar o seu arquivo de configuração, o docker-compose.yml, na raiz do projeto. Em todo arquivo de Docker Compose, que é uma espécie de receita de bolo para construirmos as diferentes partes da nossa aplicação, a primeira coisa que colocamos nele é a versão do Docker Compose que estamos utilizando:

version: '3'
services:
    nginx:
        build:
            dockerfile: ./docker/nginx.dockerfile
            context: .
        image: douglasq/nginx
        container_name: nginx
        ports:
            - "80:80"
        networks: 
            - production-network
        depends_on: 
            - "node1"
            - "node2"
            - "node3"

    mongodb:
        image: mongo
        networks: 
            - production-network

    node1:
        build:
            dockerfile: ./docker/alura-books.dockerfile
            context: .
        image: douglasq/alura-books
        container_name: alura-books-1
        ports:
            - "3000"
        networks: 
            - production-network
        depends_on:
            - "mongodb"

    node2:
        build:
            dockerfile: ./docker/alura-books.dockerfile
            context: .
        image: douglasq/alura-books
        container_name: alura-books-2
        ports:
            - "3000"
        networks: 
            - production-network
        depends_on:
            - "mongodb"

    node3:
        build:
            dockerfile: ./docker/alura-books.dockerfile
            context: .
        image: douglasq/alura-books
        container_name: alura-books-3
        ports:
            - "3000"
        networks: 
            - production-network
        depends_on:
            - "mongodb"

networks: 
    production-network:
        driver: bridge

Estamos utilizando a versão 3 pois é a versão mais recente no momento da criação do treinamento. O YAML lembra um pouco o JSON, mas ao invés de utilizar as chaves para indentar o código, ele utiliza espaços.

Agora, começamos a descrever os nossos serviços, os nossos services:

No YAML, toda vez que colocamos o caractére - significa que disponibilizamos um array.

Um serviço é uma parte da nossa aplicação. Lembrando do nosso diagrama:

Temos NGINX, três Node, e o MongoDB como serviços. Logo, se queremos construir cinco containers, vamos construir cinco serviços, cada um deles com um nome específico.

Então, vamos começar construindo o NGINX, que terá o nome *nginx.

Em cada serviço, devemos dizer como devemos construí-lo, como devemos fazer o seu build:

O serviço será construído através de um Dockerfile, então devemos passá-lo onde ele está. E também devemos passar um contexto, para dizermos a partir de onde o Dockerfile deve ser buscado. Como ele será buscado a partir da pasta atual, vamos utilizar o ponto:

Construída a imagem, devemos dar um nome para ela, por exemplo douglasq/nginx:

E quando o Docker Compose criar um container a partir dessa imagem, vamos dizer que o seu nome será nginx:

Sabemos também que o NGINX trabalha com duas portas, a 80 e a 443. Como não estamos trabalhando com HTTPS, vamos utilizar somente a porta 80, e no próprio arquivo, podemos dizer para qual porta da nossa máquina queremos mapear a porta 80 do container. Vamos mapear para a porta de mesmo número da nossa máquina:

No YAML, toda vez que colocamos um traço, significa que a propriedade pode receber mais de um item. Agora, para os containers conseguirem se comunicar, eles devem estar na mesma rede, então vamos configurar isso também. Primeiramente, devemos criar a rede, que não é um serviço, então vamos escrever do começo do arquivo, sem as tabulações:

O nome da rede será production-network e utilizará o driver bridge:

Com a rede criada, vamos utilizá-la no serviço:

Isso é para construir o serviço do NGINX, agora vamos construir o serviço do MongoDB, com o nome mongodb. Como ele será construído a partir da imagem mongo, não vamos utilizar nenhum Dockerfile, logo não utilizamos a propriedade build. Além disso, não podemos nos esquecer de colocá-lo na rede que criamos:

Falta agora criarmos os três serviços em que ficará a nossa aplicação, node1, node2 e node3. Para eles, será semelhante ao NGINX, com Dockerfile alura-books.dockerfile, contexto, rede production-network e porta 3000:

Com isso, a construção dos nossos serviços está finalizada.

Ordem dos serviços

Por último, quando subimos os containers na mão, temos uma ordem, primeiro devemos subir o mongodb, depois a nossa aplicação, ou seja, node1, node2 e node3 e após tudo isso subimos o nginx. Mas como que fazemos isso no docker-compose.yml?

Nós podemos dizer que os serviços da nossa aplicação dependem que um serviço suba antes deles, o serviço do mongodb.

Da mesma forma, dizemos que o serviço do nginx depende dos serviços node1, node2 e node3.

[Docker Compose] Subindo os serviços

Com o docker-compose.yml pronto, podemos subir os serviços, mas antes devemos garantir que temos todas as imagens envolvidas neste arquivo na nossa máquina. Para isso, dentro da pasta do nosso projeto, executamos o seguinte comando:

Inicia o Docker Compose

docker-compose build

Depois de buildar os serviços, eles podem ser vistos em:

docker images

Após isso, podemos inserir o comando:

Starta todas as solicitações (build) do Docker Compose

docker-compose up

docker-compose up -d

Listando e verificando o docker-compose

docker-compose ps

Para e remove todos os containers do docker-compose

docker-compose down

Verificando que os containers estão se comunicando

docker exec -it alura-books-1 ping alura-books-2
docker exec -it alura-books-1 ping node2

Reinicializando containers

docker-compose restart

Docker e Microsserviços

Trabalhar com uma arquitetura de microsserviços gera a necessidade de publicar o serviço de maneira rápida, leve, isolada e vimos que o Docker possui exatamente essas características! Com Docker e Docker Compose podemos criar um ambiente ideal para a publicação destes serviços.

O Docker é uma ótima opção para rodar os microsserviços pelo fato de isolar os containers. Essa utilização de containers para serviços individuais faz com que seja muito simples gerenciar e atualizar esses serviços, de maneira automatizada e rápida.

Nginx

Isaac Alves Pinheiro — Wed, 24 May 2023 21:31:42 +0000

O NGINX é um servidor web/proxy reverso rápido, de alto rendimento e um proxy para correio eletrônico (IMAP/POP3), é um software livre e de código-aberto. Ele é um serviço, é um programa que roda e que serve para responder requisições web.

Ele não usa somente aquela ideia de processos do servidor Apache, threads e programação paralela, ele usa um outro conceito de programação assíncrona muito interessante:

Então, temos aqui uma base do funcionamento do NGINX. Quando você inicia um serviço do NGINX, ele cria um processo principal como se fosse o patrão desses colaboradores aqui. No qual esse patrão vai criar alguns processos colaboradores, alguns worker process. Esses worker process são criados baseado no número de núcleos (cores) que o seu processador tem. Suponha que eu tenho um servidor que tem um processador com quatro núcleos. Então eu poderia criar, por exemplo, 4 processos worker process para tratar requisições. Porque assim eu tenho um maior número de processos tratando cada número de requisições, então eu consigo tratar mais requisições.

Só que a sacada é: Não é como se cada processo tratasse uma requisição. Não é isso! Cada um desses processos trata um número grande de requisições, várias requisições, e para que ele consiga tratar mais de uma requisição, ele usa um conceito de Multiplexing I/O. Ou seja, ele faz mais de uma coisa de forma assíncrona.

Então, imagine que chegou uma requisição nesse worker aqui e depois chega uma nova requisição que caiu nesse mesmo worker. O que ele vai fazer? Ele vai colocar para executar o primeiro. Enquanto esse processo está esperando essa tarefa ser executada - por exemplo: o servidor de aplicação responder e o arquivo ser carregado - ele já trata outra requisição, coloca para carregar imagem e manda requisição para servidor de imagem. Depois ele pega a resposta da primeira requisição e devolve, continua tratando a segunda e devolve. Por isso o NGINX veio com a proposta de ser o servidor web mais rápido.

Existem benchmarks que colocam realmente o NGINX lá no topo, ou seja, é um servidor muito performático. Mas obviamente não existe bala de prata e ele tem seus cenários onde ele trabalha muito bem e não é ferramenta ideal.

Funcionamento do NGINX: Ele inicia um servidor, um processo. Esse processo cria outros processos colaboradores, e cada um desses processos consegue tratar várias requisições utilizando o conceito de programação assíncrona, garantindo assim uma grande performance.

Difere-se muito do servidor Apache, porque ele transfere a responsabilidade de um servidor web para um servidor de aplicação além de ser:

Tolerante a falhas;
Compatível com o IPv6;

Exemplo: Com Java você pode ter um Tomcat rodando, ou com PHP você vai ter um PHP FPM rodando. Enfim, você vai ter algum servidor de aplicação aqui, e o NGINX consegue se conectar à ele. Mas nós vamos focar só na parte do NGINX, sem nos conectarmos a algum servidor de aplicação.

Instalação do NGINX

Como baixar e configurar o NGINX server.

Windows

http://nginx.org/en/download.html

macOS

brew install nginx

Linux

sudo apt install nginx

Para iniciar o nginx é simples, basta escrever o nome dele na linha de comando no terminal:

nginx

Basta somente executa-lo e acessar o http://localhost:8080

[NGINX] Servidor HTTP

Exibe ajuda e lá podemos ver os caminhos do arquivo de configuração

nginx -h

Arquivos de configuração do servidor (`nginx.conf`)

Essa é a área que configuramos o nosso servidor Nginx:

#user  nobody;
worker_processes  1; # auto

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024; # limite de processos em um sistema operacional de arquivos assíncronos (file descriptors = sockets, connections, etc...)
}


http { # Servidor HTTP
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    server { # Servidor Web
        listen       8080;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
        }

        #error_page  404              /404.html;

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }


    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}


    # HTTPS server
    #
    #server {
    #    listen       443 ssl;
    #    server_name  localhost;

    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;

    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}
    include servers/*;
}

Você pode usar o comando abaixo para retirar os comentários e visualizar somente o necessário, funciona como um filtro:

cat /opt/homebrew/etc/nginx/nginx.conf | grep -ve '^.\s*#' | grep -ve '^#' | sed '/^$/d'

Dessa forma, o arquivo de configuração fica assim:

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       8080;
        server_name  localhost;
        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
    include servers/*;
}

Vamos editar nosso arquivo principal da página do Nginx. Para isso, acesse o comando abaixo:

nano /opt/homebrew/Cellar/nginx/1.23.2/html/index.html

Se definirmos location /, significa / literalmente tudo, ou seja, podemos definir qual o diretório raiz do projeto, qual o arquivo padrão, regras de redirecionamento, etc. Percebe-se que o arquivo não mostra o preview dele no localhost.

Recarrega o arquivo nginx

nginx -s reload

Testar o arquivo de configuração

nginx -t

Páginas de erro HTTP

Os códigos de erro de protocolo HTTP começam na faixa dos 400:

server {
    listen 80;
    server_name localhost;

    location / {
        root C:/Users/isaac/Dev/nginx;
        index index.html
    }
    error_page 404 400 401 402 /erro.html;
}

[NGINX] Proxy Reverso

Um proxy de rede funciona basicamente como se fosse um "túnel" ou "filtro", quando acessamos uma determinada área, o proxy . Então é assim que funciona um proxy, ele literalmente pega as requisições e dispara na internet para um servidor web acessar as informações, ou sejam um proxy reverso ele pega as requisições feitas e redireciona ainda para outro servidor (Como se acrescentasse mais uma etapa no processo de proxy).

Então, o proxy reverso é um servidor web que recebe as requisições e distribui para outros servidores.

Porque normalmente um proxy fica no lado do cliente. O conceito padrão de proxy é algo que fica no lado do cliente interceptando os pacotes de rede. Como nesse caso o proxy está no lado do servidor, chamamos de proxy reverso.

location / {
    proxy_pass http://localhost;
}

Com esse simples código, eu tenho o conceito de proxy reverso.

Por que realizar um proxy reverso e não apenas deixar o servidor de aplicação lidar com todas as requisições? Com nginx na frente podemos responder arquivos estáticos muito mais rapidamente. Esse é um dos principais motivos. O nginx é um servidor incrivelmente performático, então nós ganhamos muito ao não enviar todas as requisições para o servidor de aplicação. O nginx pode enviar diretamente os arquivos estáticos sem processar nada, além de poder definir cache, compressão, etc.

Servidor 2 em 1

Com o proxy reverso podemos receber uma requisição e devolver muito rápido se for um arquivo estático, fazer cash e etc. Já para fazer uma rota ou uma URL que precisa de lógica, que precisa ser processada, eu mando para o servidor de aplicação.

Exemplo (default.conf):

server {
    listen 80;
    server_name localhost;

    location / {
        root /Users/isaac/Dev/nginx;
        index index.html
    }

    location ~ \.php$ {
        proxy_pass http://localhost:8000;
    }

    error_page 404 400 401 402 /erro.html
}

php -S localhost:8000

Com nginx na frente podemos responder arquivos estáticos muito mais rapidamente. Esse é um dos principais motivos. O nginx é um servidor incrivelmente performático, então nós ganhamos muito ao não enviar todas as requisições para o servidor de aplicação. O nginx pode enviar diretamente os arquivos estáticos sem processar nada, além de poder definir cache, compressão, etc.

[NGINX] API Gateway

Monolítica, Microserviços e Múltiplos serviços

Resumidamente:

Monolithic (Monolítica): é nada mais e nada menos do que uma arquitetura para uma aplicação rodando em somente um serviço contendo uma estrutura com poucas seções de maneira estruturada para o servidor;
Microserviços (Microservices): é nada mais é do que uma arquitetura com muitos micro (pequenos) serviços rodando em uma ou várias aplicações, ideal para projetos de grande porte e com diversas áreas diferentes.

Vamos criar dois serviços dentro de (microserviços.conf):

server {
    listen 8001;
    server_name localhost;

    location / {
        root /Users/isaac/Dev/nginx/servico1;
        index index.html
    }

    error_page 404 400 401 /erro.html;
}

server {
    listen 8002;
    server_name localhost;

    location / {
        root /Users/isaac/Dev/nginx/servico2;
        index index.html
    }

    error_page 404 400 401 /erro.html;
}

Agora vamos criar a index.html:

mkdir Dev/nginx/servico1 Dev/nginx/servico2
echo "Servico 1" > Dev/nginx/servico1/index.html
echo "Servico 2" > Dev/nginx/servico1/index.html

Configurando um servidor web que faz o redirecionamento para outros múltiplos servidores baseados na URL recebida (ponto de entrada para centralizar o acesso a múltiplos serviços em um único host):

location /servico1 {
    proxy_pass http://localhost:8001/;
  }

location /servico2 {
    proxy_pass http://localhost:8002/;
  }

Dessa forma, todas as requisições podem ser feitas para o mesmo servidor, facilitando a vida do cliente, dentre outras vantagens.

Um servidor web que faz o redirecionamento para outros múltiplos servidores baseado na URL recebida. Dessa forma, todas as requisições podem ser feitas para o mesmo servidor, facilitando a vida do cliente, dentre outras vantagens.

A partir do API Gateway é decidido onde essa requisição será direcionada.

Problema: Clientes acessando livremente os serviços geram caos
Gateway fornece um proxy, uma fachada, para as necessidades reais
Desvantagem: Esse portão de entrada pode se tornar um pouco central de falha

O comportamento do Gateway

Simplesmente autorizar e redirecionar os requests
Uso de Decorator para adicionar informações necessárias aos requests
Limitar o acesso ou conteúdo trafegado
Impedir que determinadas URLs sejam acessadas por completo

Agora que conhecemos o conceito de um API Gateway, temos uma base melhor para esse artigo fenomenal do próprio Nginx: https://www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/

[NGINX] Load Balancing (Balanceamento de carga)

É um balanceador de carga (como um switch para serviços).

mv Dev/nginx/servico2/servico.html Dev/nginx/servico2/index.html

Podemos configura-lo de forma muito simples, com o upstream:

upstream servicos {
     server localhost:8001;
     server localhost:8002;
}

server {
    listen 8003;
    server_name localhost;

    location / {
        proxy_pass http://servicos;
    }
}

Na prática, através do nome definido em upstream, podemos acessar algum dos servidores deste grupo dependendo de algumas regras definidas.

Configuração de logs

access_log é qualquer log de acesso, já o error_log é um log somente de erros. Vamos ver um exemplo no (nginx.conf):

#user nobody;
worker_processes 1;

#error_log  logs/error.log;
#error_log  logs/error.log notice;
#error_log  logs/error.log info;

#pid        logs/nginx.pid


events {
    worker_connections  1024;
}


http {
    include        mime.types;
    default_type   application/octet-stream;

    logs_format main  '$remote_addr - $remote_user [$time_local] "$request"'
                      '$status $body_bytes_sent "$http_referer"
                      '"$http_user_agent" "$http_x_fowarded_for"';

   #access_log  logs/access.log  main;
}

Logo:

mkdir Dev/nginx/logs
nginx -t
nginx -s reload
tail -f Dev/nginx/logs/servico1
tail -f Dev/nginx/logs/servico2

Formato de logs (nginx.conf)

#user nobody;
worker_processes 1;

#error_log  logs/error.log;
#error_log  logs/error.log notice;
#error_log  logs/error.log info;

#pid        logs/nginx.pid


events {
    worker_connections  1024;
}


http {
    include        mime.types;
    default_type   application/octet-stream;

    logs_format main  'Remote Addr: $remote_addr - Time: [$time_local] "$request"'
                      'Status: $status, Referer: "$http_referer"

   #access_log  logs/access.log  main;
}

     sendfile          on;

Formato de logs (microservicos.conf)

server {
    listen 8001;
    server_name localhost;
    access_log /Users/isaac/Dev/nginx/logs/servico1.log main;

    location / {
      root /Users/isaac/Dev/nginx/logs/servico1.log;
      index index.html;
    }
}

server {
    listen 8002;
    server_name localhost;
    access_log /Users/isaac/Dev/nginx/logs/servico2.log main;

    location / {
      root /Users/isaac/Dev/nginx/logs/servico2.log;
      index index.html;
    }
}

Adicionando informações

Dentro do load-balancer.conf:

upstream servicos {
     server localhost:8001;
     server localhost:8002;
}

server {
    listen 8003;
    server_name localhost;

    location / {
        proxy_pass http://servicos;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

No nginx.conf:

#user nobody;
worker_processes 1;

#error_log  logs/error.log;
#error_log  logs/error.log notice;
#error_log  logs/error.log info;

#pid        logs/nginx.pid


events {
    worker_connections  1024;
}


http {
    include        mime.types;
    default_type   application/octet-stream;

    logs_format main  'Remote Addr: $http_x_real_ip, Time: [$time_local] "$request"'
                      'Status: $status, Referer: "$http_referer"

   #access_log  logs/access.log  main;
}

     sendfile          on;

Definindo pesos (load-balancer.conf)

Se não distriuimos corretamente o peso para cada um servidor, deixaremos um desses servidores sobrecarregados.

upstream servicos {
     server localhost:8001 weight=2;
     server localhost:8002;
}

server {
    listen 8003;
    server_name localhost;

    location / {
        proxy_pass http://servicos;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Aplicamos o cenário de quando temos servidores com capacidades diferentes.

Servidores de backup

https://nginx.org/en/docs/http/ngx_http_upstream_module.html

Vamos fazer o seguinte, vamos utilizar o servidor1 como o servidor principal e o servidor2 como o nosso servidor de backup.

upstream servicos {
     server localhost:8001 fail_timeout=120s;
     server localhost:8002 backup;
}

server {
    listen 8003;
    server_name localhost;

    location / {
        proxy_pass http://servicos;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Utilizaremos o servidor backup somente para casos extremos, ou seja, se o servidor principal falhar e estiver em instabilidade, o servidor backup o substitue.

[NGINX] Fast CGI

Lógicas do lado do servidor, e para isso foi criado o CGI. Com a mesma ideia do CGI, surgiu então o FastCGI cujo você não precisa criar outro processo por cada requisição, o que melhora muito na performance.

A principal diferença entre o CGI e o FastCGI está no processo, o FastCGI permanece vivo após o encerramento de uma requisição. Ao iniciar um processo FastCGO, ele ouvirá novas conexões e não morrerá mais, ou seja, o mesmo processo continua gerenciando os recursos da aplicação. Usando CGI, a cada requisição um processo é criado e depois morre.

Configurando o proxy

touch index.php
echo '<?php phpinfo();' > index.php
docker run --rm -it -p 9000:9000 -v $(pwd):/caminho/projeto php:fpm

Quero um serviço para rodar no localhost:8004, vamos criar um novo documento (fpm.conf):

server {
   listen 8004;

   location / {
       fastcgi_pass localhost:9000;
   }
}

Parâmetros adicionais

Ainda dentro do (fpm.conf):

server {
    listen 8004;
    root /caminho/projeto;

    location / {
        include fastcgi.conf;
        fastcgi_pass localhost:9000;
    }
}

É um protocolo mais enxuto com fendas comprimidas e dessa forma a requisição do app não precisa receber todo o protocolo HTTP

Performance

Cache HTTP

O navegador (browser) pode ignorar os cabeçalhos de cache e não cachear o recurso. Tanto isso é verdade que temos a opção de desabilitar o cache do nosso navegador. Os cabeçalhos de cache instruem o navegador sobre o quanto tempo ele pode/deve manter o recurso em cache, mas cabe a ele aceitar essa instrução ou não. Todos os navegadores modernos tendem a seguir a instrução a menos que configuremos de forma diferente.

server {
    listen 8005;
    root /Users/isaac/Dev/performance;
    index index.html;

    location ~ \.jpg$ {
       expires 30d;
       add_header Cache-Control public;
    }
}

Compreensão

Modo de compreensão instalado no próprio NGINX:

server {
    listen 8005;
    root /Users/isaac/Dev/performance;
    index index.html
    gzip on;
    gzip_types image/jpg text/css;

    location ~ \.jpg$ {
         expires 30d;
         add_header Cache-Control public;
    }
}

Os tipos de recursos que são mais beneficiados pela compressão com gzip na web são os arquivos de texto (estáticos): html, css, js, svg, etc...

Os arquivos de texto podem ser facilmente comprimidos e são os que mais levam vantagem desta técnica. Arquivos binários ou arquivos de imagem, por exemplo, naturalmente já são comprimidos, por isso o efeito seria bem menor (ou inexistente).

Conexões

server {
    listen 8005;
    root /Users/isaac/Dev/performance;
    index index.html;
    gzip on;
    gzip_types text/css;
    add_header Keep-Alive "timeout=5, max=1000";

    location ~ \.jpg$ {
         expires 30d;
         add_header Cache-Control public;
    }
}

Cache

Caminho do Cache

É possível tranformar nosso servidor em um servidor cache, armazenando dados de resposta para não reprocessar determinadas requisições. Em um cenário em que URLs precisam de processamento e não mudam de usuário para usuário.

fastcgi_cache_path level=1.2 /tmp/cache keys_zone=fpm:10m;
proxy_cache_path /tmp/cache levels=1:2 keys_zone=proxy:1m;

server {
    listen 8004;
    root /caminho/projeto;

    location / {
        include fastcgi.conf;
        fastcgi_pass localhost:9000;
    }
}

Com uma simples página web por exemplo, nós não precisamos realizar todas as queries de cursos, formações, etc o tempo todo. Podemos executar uma vez só e armazenar o html montado em cache.

Usando o cache

fastcgi_cache_path /tmp/cache level=1:2 keys_zone=fpm:10m;

server {
    listen 8004;
    root /caminho/projeto;

    location / {
        fastcgi_pass localhost:9000;
        include fastcgi.conf;
        fastcgi_cache_key $request_method$request_uri;
        fastcgi_cache fpm;
        fastcgi_cache_valid 1m;
    }
}

Verificando o status

Para podermos depurar quando necessário, se precisarmos saber se um cache está sendo encontrado ou não, ter um cabeçalho na resposta é uma forma bem fácil de obter essa informação.

fastcgi_cache_path /tmp/cache level=1:2 keys_zone=fpm:10m;

server {
    listen 8004;
    root /caminho/projeto;

    location / {
        fastcgi_pass localhost:9000;
        include fastcgi.conf;
        fastcgi_cache_key $request_method$request_uri;
        fastcgi_cache fpm;
        fastcgi_cache_valid 1m;
        add_header X-Cache-Status $upstream_cache_status;
    }
}

HTTPS

Um protocolo de Hipertexto seguro criptografado. Quanto utilizamos o HTTP os dados são transportados em texto puro para o servidor, visível para qualquer um. Nossos dados são enviados em um texto puro, ficando visível para qualquer um que consiga interceptar nossa conexão!

Gerando nosso próprio certificado

openssl req -x509 -nodes -days 30 -newkey rsa:2048 -keyout /tmp/localhost.key -out /tmp/localhost.crt

security add-certificate /tmp/localhost.crt
security add-trusted-cert /tmp/localhost.crt

Configurando o NGINX

server {
    listen 443 ssl;
    root /Users/isaac/Dev/performance;
    index index.html
    gzip on;
    gzip_types text/css;
    add_header Keep-Alive "timeout=5, max=1000";
    ssl_certificate /tmp/localhost.crt;
    ssl_certificate_key /tmp/localhost.key;

    location ~ \.jpg$ {
         expires 30d;
         add_header Cache-Control public;
    }
}

server {
    listen 8005;
    root /Users/isaac/Dev/performance;
    index index.html;
    gzip on;
    gzip_types text/css;
    add_header Keep-Alive "timeout=5, max=1000"

    location ~ \.jpg$ {
         expires 30d;
         add_header Cache-Control public;
    }
}

HTTPD - Servidor Web Apache2 (Apache2 Web Server)

Isaac Alves Pinheiro — Wed, 24 May 2023 21:25:47 +0000

Dentre os programas mais utilizados em servidores da internet em todo o mundo está o Apache. Para começar este tópico, precisamos entender o que é o Apache e o papel que ele desempenha em servidores.

O Apache, também conhecido como Httpd, é um servidor HTTP ou, como muitos chamam, um servidor Web (Web Server). Ele é responsável por receber e processar requisições enviadas por clientes HTTP. Quando acessamos um site, do outro lado estamos sendo atendidos por um servidor HTTP.

Os Servidores HTTP são executados em processos do tipo background, ou seja, sem intervenção manual de um administrador para responder às solicitações recebidas.

O Apache se destaca por ser um software de alta confiabilidade, gratuito e de código-fonte aberto, permitindo que qualquer pessoa possa modificá-lo para uso pessoal ou contribuir com melhorias para a comunidade de usuários.

Sobre o processamento de um servidor Apache rodando, quando chega uma requisição, esse processo cria um novo processo e trata essa requisição, depois mata esse processo e fica tudo certo. Só que isso é muito custoso. Criar um processo, fazer a mudança de contexto de um processo para o outro e depois matar um processo. Isso é uma tarefa custosa. Outros servidores web, resolveram esse processo, você verá a diferença com Nginx.

O Apache é mantido pela The Apache Software Foundation e um grande número de programadores contribui com o seu desenvolvimento. Como possui diversos módulos opcionais para variadas funcionalidades, tem grande versatilidade.

Atenção: É importante frisar que diferentes distribuições Linux utilizam distintos esquemas de organização das configurações do Apache. Neste tema, abordaremos a organização usada nas distribuições baseadas no Debian, como a Ubuntu Linux.

Mais importante do que entender a organização é compreender a lógica de administração. Assim, você saberá do que precisa quando se deparar com uma distribuição que utiliza um esquema diferente.

INSTALAÇÃO DO APACHE

Geralmente, o Apache pode ser instalado por dois caminhos:

Caminho 1 Baixando seu código-fonte e compilando-o. Apesar de existir farta documentação, é uma atividade mais complexa e exige a instalação prévia de bibliotecas, compiladores etc. Em geral, é a opção para usuários avançados e em casos mais específicos. Caminho 2 O segundo caminho, mais simples, é a instalação por meio de pacotes fornecidos pelas principais distribuições Linux. Os pacotes já trazem o programa pronto para executar, além de bibliotecas e outras dependências. As rotinas de atualização também são facilitadas, assim como a instalação de módulos opcionais.

A instalação do Apache na distribuição Ubuntu/Debian Linux é feita com o comando:

sudo apt install apache2 \ 
  sudo service apache2 start \
  sudo service apache2 -h \
  sudo service apache2 -v \
  sudo service apache2 status

Caso queira instalar o Apache na distribuição Fedora/CentOS/Red Hat Enterprise Linux é feita com o comando:

sudo yum install httpd \
  sudo systemctl enable httpd \
  sudo systemctl start httpd

Caso esteja instalando pelo código-fonte: https://httpd.apache.org/docs/2.4/en/install.html

O ‘apt’ é o programa gerenciador de pacotes usado pelo Ubuntu. Ele irá obter na internet os pacotes do Apache e fará sua instalação. Após isso, o Apache estará configurado com uma página inicial de demonstração, que pode ser acessada a partir de outro computador.

Usando o comando ip addr, obtenha o endereço IP do servidor. Em outra máquina, na mesma rede, abra um navegador (Internet Explorer, Firefox, Chrome) e digite o endereço do servidor. Exemplo: http://192.168.1.70

Mas, no meu caso, farei simplesmente no localhost, cujo basta somente dar o comando sudo service apache2 start, com o endereço: http://127.0.0.1

Ao aparecer essa tela, isso significa que seu web server está funcionando corretamente!

Alterar a página inicial do Apache:

sudo nano /var/www/html/index.html

Configuração do Apache

cd /etc/apache2/ && ls

sudo nano /etc/apache2/apache2.conf

sudo nano /etc/apache2/ports.conf

Mudando a porta do Apache

Listen 801

Após mudar o endereço da porta, você deve reiniciar o Apache!

Antes, era comum escrever toda a configuração do Apache em um único arquivo, como o ‘/etc/httpd.conf’.

O problema dessa abordagem é que, quanto mais sites eram criados no servidor, maior ficava esse arquivo, até ser impraticável administrá-lo. Para piorar, aumentavam as chances de se cometer um erro acidental na configuração, afetando todo o servidor.

Não era incomum o servidor sair do ar, e consequentemente todos os sites hospedados, por um erro acidental, muitas vezes difícil de ser diagnosticado.

Para facilitar a administração, a configuração do Apache passou a ser modularizada, composta por diversos arquivos, organizados por tipo de configuração, em diretórios específicos.

Uma árvore de diretórios de configuração típica está representada a seguir:

/etc/apache2/
├── conf-available
├── conf-enabled
├── mods-available
├── mods-enabled
├── sites-available
└── sites-enabled

Arquivos do Apache

No diretório '/etc/apache2' estão localizados arquivos com configurações globais do Apache. Entre eles:

, em que são declaradas as portas TCP que o Apache abre para receber solicitações – Por padrão, 80 para HTTP e 443 para HTTPS.
, o arquivo principal de configuração. Mas, nenhuma configuração deve ser incluída aqui. Por padrão, esse arquivo contém instruções para que as configurações sejam obtidas nos demais arquivos e diretórios.

Divisão dos diretórios em grupos

Dentro de /etc/apache2 há seis diretórios, divididos em três grupos:

conf - Para configurações gerais do Apache.
mods - Para configuração de módulos.
sites - Para configuração de sites.

Leitura dos arquivos

Para cada um desses grupos, há um diretório ‘available’ (disponível) e um ‘enabled’ (habilitado). Quando o Apache é iniciado, ele lê todos os arquivos dos diretórios ‘enabled’:

/etc/apache2/conf-enabled
/etc/apache2/mods-enable
/etc/apache2/sites-enabled

Cada um dos arquivos presentes nesses diretórios será lido e sua configuração carregada pelo Apache. Se listarmos, porém, o conteúdo de qualquer um desses diretórios, veremos que todos os seus arquivos são, na verdade, links.

$ ls –l /etc/apache2/conf-enabled
lrwxrwxrwx 1 root root 30 May 26 12:53 charset.conf -> ../conf-available/charset.conf
lrwxrwxrwx 1 root root 44 May 26 12:53 localized-error-pages.conf -> ../conf-available/localized-
lrwxrwxrwx 1 root root 46 May 26 12:53 other-vhosts-access-log.conf -> ../conf-available/other-
lrwxrwxrwx 1 root root 31 May 26 12:53 security.conf -> ../conf-available/security.conf
lrwxrwxrwx 1 root root 36 May 26 12:53 serve-cgi-bin.conf -> ../conf-available/serve-cgi-bin.conf

Observe o l no início de cada linha, indicando que se trata de links simbólicos.

Todos os links no diretório conf-enabled apontam para arquivos que estão no respectivo diretório conf-available.

Mas por que essa organização? Para permitir que as configurações possam ser escritas livremente e só ativadas quando desejado. Um arquivo nos diretórios 'available' não será lido pelo Apache. Isso permite que escrevamos uma configuração, mas só a ative posteriormente, criando o link em ‘enabled’ para esse arquivo.

Assim, o Apache pode trazer diversas configurações de módulos opcionais que permanecerão inativas até que o administrador as ative manualmente. Isso vale para as configurações de site. É possível retirar um site do ar meramente apagando o ‘link’ da configuração deste, não sendo necessário editar arquivos com outras configurações.

Nos diretórios ‘available’ estarão os arquivos de texto com as configurações, ativas ou não. Nos diretórios ‘enabled’ existirão apenas links para as configurações ativas.

Exemplo: O arquivo /etc/apache2/mods-available/ssl.conf possui configurações para ativar o protocolo criptografado HTTPS. Se o seu servidor não vai utilizar esse recurso, não há necessidade de ter esse módulo habilitado. Por outro lado, para ativar o HTTPS, basta criar o link no diretório ‘enabled’ e o recurso estará disponível para uso.

Importante: O nome dos arquivos de configuração deve terminar com .conf.

ATIVANDO E DESATIVANDO MÓDULOS, CONFIGURAÇÕES E SITES

Sabemos que para ativar as configurações devem ser criados links nos diretórios ‘enabled’ apontando para arquivos no diretório ‘available’. No entanto, o Apache traz comandos que facilitam essa tarefa:

a2enconf e a2disconf

O comando a2enconf habilita (enable) as configurações, enquanto o a2disconf as desabilita (disable). Exemplo de uso:

sudo a2enconf charset

O nome da configuração é passado no argumento, e a terminação .conf dos arquivos pode ser omitida.

Nesse exemplo, foi ativada a configuração charset. O programa criou o link: /etc/apache2/conf-enabled/charset.conf apontando para /etc/apache2/conf-available/charset.conf

Os comandos para habilitar e desabilitar módulos e sites são semelhantes.

a2enmod e a2dismod

O comando a2enmod habilita módulos opcionais do Apache, enquanto o a2dismod desabilita.

a2ensite e a2dissite

O comando a2ensite habilita sites, enquanto o a2dissite desabilita.

Após qualquer alteração nas configurações, é necessário avisar ao Apache para que ele as releia ou reinicie o processo.

Para as tarefas de controle do processo do Apache existe o comando apache2ctl, que oferece diversas opções. Entre elas:

apache2ctl start

Inicia o processo do Apache, retornando erro se o processo já estiver executando.

apache2ctl restart

Encerra e reinicia o processo do Apache. Não deve ser usado apenas para carregar novas configurações, pois as requisições em andamento serão interrompidas imediatamente. Deve-se usar com cuidado, já que eventuais erros de configuração poderão impedir o processo de reiniciar, deixando-o parado.

apache2ctl configtest

Executa uma análise dos arquivos de configuração do Apache em busca de erros de sintaxe, sem interferir com o processo em execução. Deve-se observar que nem todo erro será detectável por esse teste.

apache2ctl graceful

Envia um sinal para o Apache reiniciar, relendo os arquivos de configuração, porém sem interromper as requisições em andamento. Se o processo não estava em execução, ele é iniciado. Também é possível que erros na configuração impeçam o processo de reiniciar, deixando-o parado.

apache2ctl stop

Encerra o processo do Apache. Nenhuma nova requisição será recebida e os usuários receberão um aviso do tipo “servidor inacessível”.

apache2ctl status

Exibe informações sobre o processo em execução do Apache. Há também o argumento fullstatus, com informações detalhadas sobre as requisições sendo atendidas (requer o módulo mod_status habilitado).

Como já vimos, quando o Apache é instalado é feita uma configuração inicial com uma página de teste. O nome do arquivo deste site pode variar dependendo da distribuição Linux.

Nas distribuições Debian e Ubuntu, esse arquivo é o /etc/apache2/sites-enables/000-default.conf e seu conteúdo é reproduzido a seguir:

<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

O arquivo parece grande, mas repare que muitas linhas começam com o caractere ‘#’. Toda linha iniciada com o ‘#’ é considerada comentário e não é lida pelo Apache. As linhas em branco também são ignoradas.

Atenção: A maioria dos arquivos de configuração no Linux usa essa mesma lógica, assim, é fácil inserir textos, comentários e observações para serem lidos por pessoas e não pela máquina.

Portanto, desse arquivo, o que será efetivamente lido pelo Apache é somente isso:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Uma diretiva importante na configuração do Apache é a < VirtualHost >, que nos possibilita configurar o endereço do servidor que irá responder por um site e a respectiva porta. Essa diretiva é uma das mais importantes na configuração de um site no Apache. Por meio dela é possível definir o endereço pelo qual o servidor irá responder e a porta que será usada. Sites que atendem pelos protocolos HTTP (porta 80) e HTTPS (porta 443) precisarão ser definidos com duas diretivas, uma para cada porta.

Uma diretiva importante de configuração do Apache é a DocumentRoot, usada na definição de sites. Essa diretiva tem como objetivo indicar o diretório onde estão os arquivos que compõem determinado site. Ou seja, informa ao Apache em qual diretório do sistema está a raiz do site, ou seja, todo e qualquer recurso acessível pelo site deverá estar nesse diretório.

EXAMINANDO O ARQUIVO DE CONFIGURAÇÃO

Antes de analisar o significado de cada uma dessas linhas, precisamos ter em mente qual é o objetivo dessa configuração: trata-se de uma configuração inicial, com uma página simples de demonstração, a única presente no servidor.

Em um servidor com vários sites, existirão vários arquivos de configuração semelhantes a esse, um para cada site.

`<VirtualHost *:80>`

A diretiva <VirtualHost> permite configurar os endereços e as portas em que o site responde.

Um servidor Linux pode ser configurado com diversos endereços IP. O Apache permite que determinados sites respondam em somente um desses endereços. É possível, por exemplo, designar um endereço IP para cada site. A desvantagem desse tipo de configuração é que você precisará de novos endereços para cada novo site, o que nem sempre é possível.

A configuração mais usada hoje consiste em um único endereço IP sendo usado para atender a diversos sites.

Nessa linha de <VirtualHost>, o *:80 significa que o site responderá em todos os endereços IP do servidor e na porta 80.

Lembre-se que a porta 80 é a padrão (well known port) para o protocolo HTTP, assim como a porta 443 é a padrão para o protocolo HTTPS. A princípio, qualquer porta pode ser utilizada pelo Apache, se já não estiver em uso por outro processo. Mas será necessário divulgar, além do endereço, o número da porta para compor a URL.

Por exemplo, se for usada a porta 8000, a URL será: http://www.meusite.com:8000

`ErrorLog /var/log/apache/error.log`

A diretiva ErrorLog define em que arquivo serão gravados os registros (logs) de erro. A cada erro ocorrido, uma nova linha é gerada nesse arquivo, com as informações sobre ele, além de data e hora.

`ServerAdmin webmaster@localhost`

Informação que será passada a um cliente em caso de erro no acesso ao site, contendo um e-mail para contato.

`CustomLog /var/log/apache/access.log combined`

A diretiva CustomLog define em que arquivo serão gravados os registros de acesso aos sites. O parâmetro combined define um formato predeterminado para esses registros.

`DocumentRoot /var/www/html`

Uma das configurações mais importantes de um site é onde está seu conteúdo. Nesse caso, o diretório /var/www/html.

A DIRETIVA `DIRECTORYINDEX`

O acesso a um site é sempre feito por meio de uma URL (Uniform Resource Locator) digitada no navegador. A URL é, em resumo, uma frase que contém todas as informações para localizar um recurso como site ou arquivo.

Exemplo: http://site-exemplo.com/info.html

Nessa URL constam o protocolo (HTTP), o endereço do site (site-exemplo.com) e o nome do recurso procurado (info.html). O cliente (navegador) se conecta ao servidor do site e requisita o recurso info.html. Nesse exemplo, o servidor Apache buscaria o arquivo info.html no diretório do site e o enviaria ao cliente.

Muitas vezes, porém, usamos uma URL sem indicar um recurso, como em http://site-exemplo.com.

Nesses casos, como o Apache sabe que arquivo buscar?

Para esta função, há a diretiva DirectoryIndex, que permite definir um ou mais arquivos que serão procurados pelo Apache, em ordem.

Exemplo: DirectoryIndex principal.html define o nome do arquivo a ser procurado.

DirectoryIndex principal.html opcional.html o Apache procurará o arquivo principal.html. Se não encontrar, irá procurar o opcional.html.

Na ausência dessa diretiva, o Apache assume como padrão o arquivo index.html.

CONFIGURANDO DOIS SITES (Múltiplos) NO MESMO SERVIDOR APACHE

Atualmente, é muito comum um servidor hospedar diversos sites independentes utilizando somente um endereço IP (192.168.0.30). A diretiva Servername permite determinar na configuração do site o nome (domínio) pelo qual ele responderá.

Mas é importante lembrar que o cliente deverá conseguir resolver esse nome, assim, não basta configurar o Apache para responder por ele, também é preciso registrá-lo em um servidor DNS.

Vamos simular a configuração de dois sites em um servidor Apache?

Na tabela a seguir, relacionaremos todas as informações necessárias para a configuração:

	Site A	Site B
Nome (domínio) do site	www.site-test1.com	www.site-teste2.com
Diretório com o conteúdo do site	/var/www/site-teste1	/var/www/site-teste2
Arquivo "principal" (DirectoryIndex)	index.html	default.htm
Arquivo de configuração (/etc/apache2/sites-available)	site-teste1.conf	site-teste2.conf

Criando os diretórios para os sites

Também é necessário colocar o conteúdo. Nesse exemplo, copiaremos o arquivo de demonstração (/var/www/html/index.html) para este fim.

sudo mkdir /var/www/site-teste1

sudo cp /var/www/html/index.html /var/www/site-teste1

sudo mkdir /var/www/site-teste2

sudo cp /var/www/html/index.html /var/www/site-teste2/default.htm

Repare que, no segundo exemplo, o arquivo foi copiado mudando o nome para default.htm.

Lembre-se: O nome e o caminho do arquivo HTML de demonstração, que usamos como base, variam conforme a distribuição Linux. Qualquer arquivo HTML pode ser usado como conteúdo nesse teste.

Importante: O Apache é executado por um usuário com poucos privilégios. O nome do usuário varia com a distribuição Linux: www-data, apache etc. É importante que os arquivos nos diretórios dos sites (/var/www/site-teste1 etc.) possam ser lidos pelo usuário do Apache. Uma opção é garantir que os arquivos possuam permissão de leitura para outros e os diretórios, permissões de leitura r e de acesso x também para outros.

Criando os arquivos de configuração para os sites

Usando um editor de textos, como o Vim ou nano, criamos o arquivo /etc/apache2/sites-available/site-teste1.conf e o preenchemos com o seguinte conteúdo:

<VirtualHost *:80>
        ServerName www.site-teste1.com
        ServerAdmin webmaster@site-teste1.com
        DocumentRoot /var/www/site-teste1
        DirectoryIndex index.html
        ErrorLog /var/log/apache2/site-teste1-error.log
        CustomLog /var/log/apache2/site-teste1-access.log combined
</VirtualHost>

Do mesmo modo, criamos o arquivo /etc/apache2/sites-available/site-teste2.conf e o preenchemos:

<VirtualHost *:80>
        ServerName www.site-teste1.com
        ServerAdmin webmaster@site-teste2.com
        DocumentRoot /var/www/site-teste2
        DirectoryIndex index.html
        ErrorLog /var/log/apache2/site-teste1-error.log
        CustomLog /var/log/apache2/site-teste1-access.log combined
</VirtualHost>

Habilitando os sites

sudo a2ensite site-teste1

sudo a2ensite site-teste2

Enviando um sinal para o Apache reler as configurações

sudo apache2ctl graceful

É possível acessar os novos sites a partir de um navegador, simulando o acesso de um usuário comum. Isso poderá ser feito a partir de um computador executando o sistema operacional Windows.

No entanto, é preciso que o navegador consiga resolver os nomes dos sites para o endereço do servidor Apache. Como os domínios dos sites que criamos não existem na internet, será necessário “enganar” o Windows.

O procedimento a seguir deve ser feito com cautela, pois pode causar danos ao Windows. Será necessário que o usuário tenha permissão de administrador do sistema.

Execute o editor notepad como administrador.
Abra o arquivo C:\Windows\System32\drivers\etc\HOSTS
Inclua as seguintes linhas, trocando o endereço IP pelo endereço IP do servidor Apache que você obteve com o comando ip addr.

192.168.1.70 www.site-teste1.com
192.168.1.70 www.site-teste2.com

Salve o arquivo. Não se esqueça de desfazer essa configuração após terminar seus testes.

Essa alteração fará com que o Windows reconheça os endereços dos novos sites, mesmo que eles não existam na internet.

No seu computador com Windows, abra um navegador de sua preferência. Digite os sites configurados: www.site-teste1.com e www.site-teste2.com.

Os dois sites serão exibidos da mesma maneira, pois o conteúdo é o mesmo, obtido na página de demonstração. Mesmo sem conhecer HTML, edite esses arquivos e faça uma pequena alteração no texto deles. Recarregue as páginas no seu navegador e veja as alterações. Confira alguns exemplos e aproveite para praticar!

Prática 1 - Apache2

Na configuração dos sites, indicamos arquivos de log em que o Apache incluirá os registros de acessos, um por linha:

Busque esses arquivos e veja o seu conteúdo. Observe o formato e as informações que ele contém. Você pode usar o comando less ARQUIVO.

Prática 2 - Apache2

Vamos acessar um recurso que não existe no servidor e veremos o que acontece:

No seu navegador, busque um recurso inexistente no site. Por exemplo, digite a URL: http://www.site-teste1.com/abc.html

Como não existe um recurso com o nome abc.html, o Apache retornará uma página com o conhecido erro 404 (recurso não encontrado).

Habilitanto o HTTPS - Apache2

Uma limitação do protocolo HTTP é que ele não conta com a criptografia dos dados para tráfegos, sendo possível que um terceiro consiga interceptar as informações transmitidas e até modificá-las. Para resolver essa fragilidade, foi criado o protocolo HTTPS que é, basicamente, o protocolo HTTP com uma camada adicional de criptografia.

Atualmente, é considerado obrigatório que um site utilize o HTTPS se transmite dados pessoais de um usuário, solicita senhas, cartão de crédito etc.

O HTTPS é simples de configurar no Apache, mas pode parecer complicado porque se baseia em certificação digital e são necessárias algumas ações, além da simples configuração de um arquivo.

Em poucas palavras, o certificado digital é como um documento autenticado no cartório, afirmando que você é realmente quem diz ser. O cartório desse exemplo são as autoridades certificadoras (CA).

O processo de obtenção de um certificado deve seguir alguns passos:

Criação das chaves criptográficas (pública e privada).
Elaboração da requisição de certificado (CSR).
Envio da requisição (CSR) a uma autoridade certificadora (CA).
Emissão do certificado pela autoridade certificadora (CA).
Instalação do certificado digital emitido pela autoridade certificadora (CA).
É importante lembrar que a maioria das autoridades certificadoras cobra pelo serviço, já que precisa realizar verificações de segurança. O valor varia dependendo do tipo de certificado solicitado e da autoridade certificadora.

Vamos habilitar o protocolo HTTPS no site www.site-teste1.com. Nessa atividade, assumiremos o papel da autoridade certificadora, gerando um certificado do tipo self-signed (assinado por mim). Na prática, esse tipo de certificado não é reconhecido por nenhum navegador e sempre será exibido um aviso de segurança.

Lembre-se de que esse é um procedimento simplificado, pois nosso objetivo é a configuração do Apache. Sempre que for gerar um certificado, leia as instruções da autoridade certificadora escolhida, que costuma disponibilizar procedimentos detalhados.

Para gerar nosso certificado self-signed, usaremos o comando a seguir (tudo em uma única linha):

sudo openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout /etc/ssl/private/site-teste1.key -out /etc/ssl/certs/site-teste1.crt

Se o comando openssl não for encontrado, será necessário instalar esse pacote de software. Verifique a documentação da distribuição Linux que estiver usando.

Por exemplo: No Ubuntu Linux, a instalação é feita com o comando:

sudo apt install openssl

O comando openssl é uma ferramenta para gerenciamento, entre outras coisas, de chaves criptográficas. Nessa única linha estamos gerando as chaves (criptografia RSA de 2048 bits), preparando a requisição e emitindo um certificado com 365 dias de validade.

Chegou o momento de entrar com os dados do novo certificado:

Country Name (2 letter code) [AU]:BR
State or Province Name (full name) [Some-State]:Rio de Janeiro
Locality Name (eg, city) []:Nome da cidade
Organization Name (eg, company) []:Minha Empresa LTDA
Organizational Unit Name (eg, section) []:Departamento de TI
Common Name (e.g. server FQDN or YOUR name) []:www.site-teste1.com
Esse é o endereço do seu site.
Email Address []: Não é necessário preencher o e-mail.

Ao término, dois arquivos são gerados nos caminhos indicados: a chave criptográfica e o certificado digital. Nesse exemplo foram escolhidos os diretórios /etc/ssl/private e /etc/ssl/certs, padrão na distribuição Ubuntu, porém você pode criar outro diretório para esses arquivos.

Atenção: O arquivo site-teste1.key contém a chave privada do seu certificado e deve ser protegido ao máximo, pois um invasor será capaz de decifrar a comunicação do servidor, além de forjar um site com o mesmo domínio. É recomendável que o arquivo possua proprietário e grupo root e permissão do tipo 400 ou 600. Sempre confira a segurança das suas chaves privadas!

A chave pública está armazenada junto ao certificado digital, e ambos são entregues aos usuários quando se conectam ao servidor.

O próximo passo é configurar o Apache:

Habilite o módulo de ssl do Apache (SSL é a camada criptográfica usada pelo HTTPS).

a2enmod ssl

Inclua o seguinte conteúdo no final do arquivo de configuração, sem modificar o conteúdo que já existe (/etc/apache2/sites-available/site-teste1.conf).

<VirtualHost *:443>
ServerName www.site-teste1.com 
ServerAdmin webmaster@site-teste1.com
DocumentRoot /var/www/site-teste1
DirectoryIndex index.html
ErrorLog /var/log/apache2/site-teste1-error.log
CustomLog /var/log/apache2/site-teste1-access.log combined

SSLEngine on
SSLCertificateFile      /etc/ssl/certs/site-teste1.crt
SSLCertificateKeyFile /etc/ssl/private/site-teste1.key 
</VirtualHost>

Repare que é um conjunto de diretivas iguais às já existentes com quatro diferenças: a primeira é a porta 443 na diretiva <VirtualHost> – lembrando que o protocolo HTTPS tem porta padrão 443; as outras são as três últimas linhas, onde a diretiva SSLEngine ativa o uso da camada SSL e as demais indicam onde estão a chave e o certificado digital.

Carregue a nova configuração no Apache:

apache2ctl graceful

Acesse o site: https://www.site-teste1.com. (Atenção ao https)

Uma mensagem de segurança será exibida, afinal o certificado não foi emitido por uma CA conhecida e confiável. Selecione a opção para acessar assim mesmo. Você deverá ver o seu site. A diferença é que agora toda a comunicação ocorreu por um canal criptografado.

No navegador, peça para exibir o certificado digital do site e veja os dados que foram digitados na requisição:

Repita o procedimento e habilite o HTTPS também para o domínio www.site-teste2.com.

REFERÊNCIAS

APACHE HTTP SERVER PROJECT. Documentação do servidor HTTP Apache versão 2.4. Consultado em meio eletrônico em: 17 jul. 2020.
MAXWELL, S. Administração de sistemas Unix. 1. ed. Rio de Janeiro: Ciência Moderna, 2003.
MOTA FILHO, J. Descobrindo o Linux: Entenda o Sistema Operacional GNU/Linux. 3. ed. São Paulo: Novatec, 2012.
PETERSEN, R. Ubuntu 18.04 LTS Server: Administration and Reference. 1. ed. Surfing Turtle Press, 2018.
UBUNTU SERVER GUIDE. HTTPD Apache2 Web server. Consultado em meio eletrônico em: 17 jul. 2020.\
UBUNTU DOCUMENTATION. Ubuntu desktop guide. Consultado em meio eletrônico em: 17 jul. 2020.

TAXONOMIA DE FLYNN: Computação Paralela

Isaac Alves Pinheiro — Wed, 24 May 2023 21:22:20 +0000

A computação paralela (Parallel Computing) é uma computação em que os trabalhos são divididos em partes discretas que podem ser executadas simultaneamente. Cada parte é subdividida em uma série de instruções. As instruções de cada parte são executadas simultaneamente em CPUs diferentes. Os sistemas paralelos lidam com o uso simultâneo de vários recursos de computador que podem incluir um único computador com vários processadores, vários computadores conectados por uma rede para formar um cluster de processamento paralelo ou uma combinação de ambos.

Os sistemas paralelos são mais difíceis de programar do que os computadores com um único processador, porque a arquitetura dos computadores paralelos varia de acordo com os recursos disponíveis, sendo assim, os processos de várias CPUs devem ser coordenados e sincronizados.

A primeira descrição formal desse tipo de abordagem foi a taxonomia de Flynn. Essa taxonomia foi desenvolvida em 1966 e ligeiramente expandida em 1972:

É uma metodologia para classificar formas gerais de operação paralela disponíveis em um processador.
Propõe uma abordagem para esclarecer os tipos de paralelismo suportados no hardware por um sistema de processamento ou disponíveis em uma aplicação.
Sua classificação é baseada na visão da máquina ou do aplicativo pelo programador de linguagem de máquina (machine code).

A taxonomia de Flynn é uma categorização de formas de arquiteturas de computador paralelas.

Do ponto de vista do programador de linguagem assembly (linguagem de montagem), os computadores paralelos são classificados pela simultaneidade em sequências de processamento (ou fluxos), dados e instruções. Isso resulta em quatro classes: SISD (instrução única, dados únicos), SIMD (instrução única, dados múltiplos), MISD (instrução múltipla, dados únicos) e MIMD (instrução múltipla, dados múltiplos).

A taxonomia de Flynn pode ser sumarizada de forma ilustrativa segundo a imagem a seguir.

SISTEMAS DE INSTRUÇÃO ÚNICA E DADOS ÚNICOS (SINGLE-INSTRUCTION, SINGLE-DATA – SISD)

Um sistema de computação de instrução única e dados únicos (Single-Instruction, Single-Data – SISD) é uma máquina de um processador que é capaz de executar uma única instrução, operando em um único fluxo de dados, como se observa na imagem seguinte.

No SISD, as instruções de máquina são processadas de maneira sequencial, e os computadores que adotam esse modelo são popularmente chamados de computadores sequenciais. A maioria dos computadores convencionais derivados da proposição de Von Neumann possui arquitetura SISD. Todas as instruções e dados a serem processados devem ser armazenados na memória primária.

A velocidade do elemento de processamento no modelo SISD é limitada (dependente) pela taxa por meio da qual o computador pode transferir informações internamente. Os sistemas SISD representativos dominantes são IBM PC e estações de trabalho, entre outros.

SISTEMAS DE INSTRUÇÃO ÚNICA E DADOS MÚLTIPLOS (SINGLE-INSTRUCTION, MULTIPLE-DATA – SIMD)

Um sistema SIMD é uma máquina multiprocessada capaz de executar a mesma instrução em todas as CPUs, mas operando em diferentes fluxos de dados.

As máquinas baseadas em um modelo SIMD são adequadas para computação científica, pois envolvem muitas operações de vetor e matriz. Para que a informação possa ser passada para todos os elementos de processamento (Processing Elements – PEs), os elementos de dados organizados dos vetores podem ser divididos em vários conjuntos (N-conjuntos para sistemas N PE) e cada PE pode processar um conjunto de dados. Veja a imagem a seguir.

Os sistemas SIMD representativos são, por exemplo, máquinas de processamento vetorial da Cray e as Unidades de Processamento Gráfico, as famosas placas de vídeo (Graphical Processing Unit – GPU).

SISTEMAS DE INSTRUÇÃO MÚLTIPLA E DADOS ÚNICOS (MULTIPLE-INSTRUCTION, SINGLE-DATA – MISD)

Um sistema de computação MISD é uma máquina multiprocessada capaz de executar diferentes instruções em diferentes PEs, mas todas operando no mesmo conjunto de dados, conforme a próxima imagem.

O sistema executa diferentes operações no mesmo conjunto de dados. As máquinas construídas usando o modelo MISD não são úteis na maioria das aplicações, algumas máquinas são construídas, mas nenhuma delas está disponível comercialmente.

SISTEMAS DE MÚLTIPLAS INSTRUÇÕES E MÚLTIPLOS DADOS (MULTIPLE-INSTRUCTION, MULTIPLE-DATA – MIMD)

Um sistema de múltiplas instruções e múltiplos dados (MIMD) é uma máquina com multiprocessador capaz de executar várias instruções em vários conjuntos de dados, conforme a imagem a seguir.

Cada PE no modelo MIMD tem instruções e fluxos de dados separados, portanto, as máquinas construídas a partir desse modelo suportam qualquer tipo de aplicação. Ao contrário das máquinas SIMD e MISD, os PEs em máquinas MIMD funcionam de forma assíncrona.

Atenção: As máquinas MIMD são amplamente categorizadas em MIMD de memória compartilhada e MIMD de memória distribuída com base na maneira como os PEs são acoplados à memória principal.

No modelo MIMD de memória compartilhada (sistemas multiprocessadores fortemente acoplados), todos os PEs são conectados a uma única memória global e todos têm acesso a ela. A comunicação entre os PEs nesse modelo ocorre por meio da memória compartilhada, e a modificação dos dados armazenados na memória global por um PE é visível para todos os outros PEs. Os sistemas MIMD representativos dominantes de memória compartilhada são as máquinas Silicon Graphics e SMP (Symmetric Multi-Processing) da Sun / IBM.

Em máquinas MIMD de memória distribuída (sistemas multiprocessadores fracamente acoplados), todos os PEs têm uma memória local. A comunicação entre PEs nesse modelo ocorre por meio da rede de interconexão (o canal de comunicação entre processos, ou IPC). A rede que conecta os PEs pode ser configurada em árvore, malha ou de acordo com o requisito.

Árvore (Tree): A topologia de rede em árvore é uma topologia que possibilita a visualização da interligação de várias redes e sub-redes, caracterizando-se pela presença de um concentrador que interliga todos os nodos (nós - nodes) (computadores, servidores, PEs etc.) de uma rede local, enquanto outro concentrador interliga as demais redes, interligando dessa forma um conjunto de redes locais (LAN) e fazendo com que estas sejam dispostas no formato de árvore.

Malha (Mesh): A topologia de rede em malha consiste em uma topologia de rede de computadores onde cada nodo da rede (computador, servidor, PE etc.) está conectado aos demais diretamente, o que possibilita que todos os nodos da rede sejam capazes de trocar informações diretamente com todos os demais. Nessa topologia, a informação pode ser transmitida da origem ao destino por diversos meios ou caminhos.

A arquitetura MIMD de memória compartilhada é mais fácil de programar, mas é menos tolerante a falhas e mais difícil de estender em relação ao modelo MIMD de memória distribuída.

Falhas em um MIMD de memória compartilhada afetam todo o sistema, ao passo que este não é o caso do modelo distribuído, no qual cada um dos PEs pode ser facilmente isolado.

Além disso, as arquiteturas MIMD de memória compartilhada têm menos probabilidade de serem escaláveis porque a adição de mais PEs leva à contenção de memória, situação que não ocorre no caso da memória distribuída, em que cada PE possui sua própria memória. Por causa dos resultados práticos e requisitos do usuário, a arquitetura de memória distribuída MIMD é superior aos outros modelos existentes.

LEI DE AMDAHL E SPEEDUP

Quando buscamos o paralelismo da execução de instruções, desejamos que o nosso sistema realize suas tarefas da forma mais rápida possível. Entretanto, existe um limite teórico para a execução dessas tarefas, e ele é determinado pela lei de Amdahl.

Que no caso é a resolução de um simples problema, nós temos o nosso ganho, que é 1 dividido pelo Sequencial do programa + a diferença (1 - Sequencial, ou seja o percentual do meu programa que é paralelizável), dividido pela quantidade de processadores.

Atenção: A lei de Amdahl afirma que podemos paralelizar e/ou distribuir nossos cálculos tanto quanto quisermos, ganhando em desempenho à medida que adicionamos recursos de computação. No entanto, nosso código não pode ser mais rápido do que a velocidade de suas partes sequenciais combinadas (ou seja, não paralelizáveis) em um único processador.

Vamos ver um exemplo de problema: Suponhamos que 80% do nosso programa não podemos paralelizarm então:

Colocado de modo mais formal, a lei de Amdahl tem a seguinte formulação.

Dado um algoritmo que é parcialmente paralelo, vamos chamar P sua fração paralela e S sua fração serial (S + P = 100%). Além disso, chamemos T(n) o tempo de execução (em segundos) do algoritmo ao usar n processadores.

Então, a seguinte relação se mantém:

T(n) ≥ S . T(1) + P . T(1) / n

A relação anterior afirma o seguinte:

O tempo de execução do algoritmo descrito aqui em n processadores é igual — e geralmente maior — do que o tempo de execução de sua parte serial em um processador (isto é, S.T(1)) mais o tempo de execução de sua parte paralela em um processador (ou seja, P.T(1)) dividido por n (número de processadores).

À medida que aumentamos o número n de processadores usados por nosso código, o segundo termo da equação fica cada vez menor, tornando-se insignificante em relação ao primeiro termo. Nesses casos, a relação anterior simplesmente se torna esta:

T(∞) ≈ S.T(1)

A tradução dessa relação pode ser interpretada da seguinte forma:

O tempo de execução do algoritmo descrito aqui em um número infinito de processadores (ou seja, um número realmente grande de processadores) é aproximadamente igual ao tempo de execução de sua parte serial em um único processador (ou seja, S.T(1)).

Agora, vamos parar por um segundo e pensar sobre as implicações da lei de Amdahl. O que temos aqui é uma observação bastante simples: muitas vezes, não podemos paralelizar totalmente nossos algoritmos.

O que significa que, na maioria das vezes, não podemos ter S = 0 nas relações anteriores. As razões para isso são inúmeras:

Copiar dados e/ou código para onde os vários processadores serão capazes de acessá-los.
Dividir os dados em pedaços e mover esses pedaços pela rede.
Coletar os resultados de todas as tarefas simultâneas e executar algum processamento adicional nelas, e assim por diante.

Atenção: Seja qual for o motivo, se não pudermos paralelizar totalmente o algoritmo, eventualmente o tempo de execução do código será dominado pelo desempenho da fração serial. Não apenas isso, mas mesmo antes que aconteça, começaremos a ver acelerações cada vez menores do que o esperado.

Como uma observação lateral, algoritmos que são totalmente paralelos são geralmente chamados de “embaraçosamente paralelos” e oferecem propriedades de escalabilidade impressionantes (com acelerações geralmente lineares com o número de processadores). É claro que não há nada de constrangedor nesses softwares. Porém, infelizmente, eles não são tão comuns quanto gostaríamos.

Como a execução paralela dos algoritmos pode realmente fazer com que a tarefa seja executada de forma mais rápida, temos de mensurar esse ganho, o que chamamos de speedup.

O speedup é definido como a razão entre o tempo de execução serial do melhor algoritmo sequencial para resolver um problema e o tempo gasto pelo algoritmo paralelo para resolver o mesmo problema com p processadores.

É simplesmente a razão entre o tempo gasto com uma execução serial dividido pelo tempo gasto pela execução paralela, conforme podemos ver na fórmula a seguir.

Speedup = Temposerial / TempoParalelo = T8 / Tp

Vamos tentar visualizar toda a lei de Amdahl, bem como o speedup associado com alguns números.

Suponha que o algoritmo leve 100 segundos para ser executado em um único processador.
Vamos supor também que podemos paralelizar 99% disso, o que seria uma façanha incrível, na maioria das vezes.
Podemos tornar o código mais rápido aumentando o número de processadores que usamos, conforme esperado.

Veja o cálculo:

T(1) = 100s
T(10) ≈ 0,01 . 100s + 0,99*100s / 10 = 10,9s => Speedup = 100/10,9 = 9,2x
T(100) ≈ 1s + 0,99s = 1,99s ===> Speedup = 100/1,99 = 50,2x
T(1000) ≈ 1s + 0,099s = 1,099s => Speedup = 100/1,099 = 91x

A partir dos números anteriores, vemos que o aumento da aceleração com valores crescentes de n é bastante decepcionante.

Começamos com um aumento de velocidade realmente incrível de 9,2x usando 10 processadores, e então caímos para apenas 50x ao usar 100 processadores e um insignificante 91x ao usar 1.000 processadores.

A imagem anterior mostra a aceleração de melhor caso esperada para o mesmo algoritmo (calculado até ). Não importa quantos processadores usamos; não podemos obter um aumento de velocidade maior que , o que significa que o mais rápido que o código rodará é um segundo, que é o tempo que sua fração serial leva em um único processador, exatamente como foi previsto pela lei de Amdahl.

A lei de Amdahl nos diz duas coisas:

A primeira é o quanto de aceleração podemos razoavelmente esperar na melhor das hipóteses e quando parar de adicionar hardware ao sistema devido aos retornos decrescentes.

A segunda é que a lei de Amdahl se aplica igualmente a sistemas distribuídos e sistemas híbridos distribuídos, ou seja são aqueles que combinam diferentes tipos de aspectos arquiteturais, paralelamente. Nesses casos, n refere-se ao número total de processadores em computadores disponíveis no sistema.

Um aspecto que deve ser mencionado nesse ponto é que à medida que os sistemas que podemos usar se tornam mais poderosos, nossos algoritmos distribuídos levarão cada vez menos tempo para rodar, se puderem fazer uso dos ciclos extras.

https://player.vimeo.com/video/549004821?h=68a286301b&app_id=122963

Memória Compartilhada

Para se aproveitar do paralelismo disponível nos sistemas modernos, os programas podem ser desenvolvidos para utilizar mais de um core (núcleos) simultaneamente. Isso significa que um programa com essa capacidade, sendo executado em um servidor, por exemplo, com 8 cores, poderia ser executado até oito vezes mais rápido (já vimos de acordo com a lei de Amdahl que isso não é verdade). Para isso, o programa precisa ser explicitamente programado com essa capacidade, usando bibliotecas ou técnicas específicas.

A memória compartilhada é a memória que pode ser acessada simultaneamente por vários programas com a intenção de fornecer comunicação entre eles. Além de ser uma forma de comunicação entre os diversos programas, possibilita a economia de recursos, evitando cópias redundantes. Dentro desse contexto, os programas podem ser executados em um único processador ou mesmo em vários processadores separados.

O conceito de memória compartilhada pode ser aplicado tanto em hardware como em software. Sua aplicação em hardware não é o foco do nosso estudo neste tema, assim, passaremos apenas a considerar sua aplicação em software.

Em termos de software, a memória compartilhada pode ser um método de comunicação entre processos (Interprocess Communication – IPC), ou seja, uma maneira de trocar dados entre programas em execução ao mesmo tempo. Um processo criará uma área na RAM a qual outros processos podem acessar.

Como dissemos anteriormente, o uso de memória compartilhada permite a conservação de recursos de memória, evitando cópias de dados de uma mesma instância, usando mapeamentos de memória virtual ou com suporte explícito do programa em questão.

Uma vez que ambos os processos podem acessar a área de memória compartilhada como memória de trabalho regular, essa é uma forma muito rápida de comunicação, utilizando-se, via de regra, a comunicação síncrona nesses sistemas. Por outro lado, é menos escalável, pois os processos de comunicação devem estar rodando na mesma máquina, ficando limitado aos recursos desta. Existem ainda outros problemas, pois se os processos que compartilham a mesma memória compartilhada estiverem sendo executados em CPUs separadas, podem surgir problemas de coerência de cache.

Passemos a um exemplo onde todos os cores de CPUs utilizados estão sempre no mesmo servidor, e tem acesso a mesma memória, chamamos essa técnica de paralelização de memória compartilhada. São termos relacionados a esse mecanismo: SMP, Threads, OpenMP, os quais não serão objetos de nosso estudo.

Thread é uma forma como um processo/tarefa de um programa de computador é divido em duas ou mais tarefas que podem ser executadas concorrentemente. Os threads criados ocupam a CPU do mesmo modo que o processo criador, e também são escalonadas pelo próprio processo.

Exemplo: Programas em C/C++ podem ser “facilmente” paralelizados para esse modelo usando a biblioteca OpenMP. Para isso, são necessárias as inclusões de algumas diretivas de compilação (pragmas) no código e a utilização de um compilador compatível.

A seguir, temos um exemplo de memória compartilhada utilizando a linguagem C. Claro que para utilizá-lo, a biblioteca OMP já deve estar instalada em seu computador.

Inicialmente, temos que incluir o cabeçalho OpenMP para nosso programa junto com os arquivos de cabeçalho padrão.

//OpenMP header
#include <omp.h>

No OpenMP, precisamos mencionar a região que vamos fazer como paralela usando a palavra-chave pragma omp parallel. O pragma omp parallel é usado para bifurcar threads adicionais para realizar o trabalho paralelo na região determinada. O encadeamento original será indicado como o encadeamento mestre com ID de encadeamento 0.

O código para a criação de uma região paralela seria:

#pragma omp parallel
{
// As variáveis criadas aqui serão compartilhadas por todas
// as theads em execução
//Parallel region code
}

Na região entre colchetes, todas as variáveis ali declaradas serão compartilhadas por todos os threads em execução. Em outras palavras, todas as variáveis criadas nesse espaço de memória serão compartilhadas por todas as instâncias de thread criadas.

O comando poderia ser, por exemplo:

#pragma omp parallel
{
  printf("Ola Mundo... da thread = %d\n", omp_get_thread_num());
}

Defina o número de threads para executar o programa usando a variável externa.

export OMP_NUM_THREADS=5

De acordo com a imagem anterior, uma vez que o compilador encontra o código das regiões paralelas, o thread mestre (thread que tem o id de thread 0) será bifurcado no número especificado de threads.

Aqui, ele será dividido em 5 threads porque inicializaremos o número de threads a serem executados como 5, usando o comando export OMP_NUM_THREADS = 5.

Todo o código dentro da região paralela será executado por todos os threads simultaneamente, bem como todas as variáveis eventualmente declaradas nesse código serão compartilhadas. Uma vez que a região paralela terminar, todos os threads serão mesclados no thread mestre.

Comentário: Não se preocupe em executar este programa no seu computador. A biblioteca OpenMP não será o foco do nosso estudo. Mas, caso se interesse no exemplo atual, siga os comandos abaixo descritos.

Compile o programa no ambiente Linux, utilizando o seguinte comando:

gcc -o hello -fopenmp hello.c

Execute o programa com o seguinte comando:

./hello

A seguir, está o programa completo descrito anteriormente.

// Usando o OpenMP para executar o Hello World compartilhado
// utilizando a linguagem C

// OpenMP header
#include <omp.h>

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[])
{

    // Inicio da Regiao Paralela
    #pragma omp parallel
    {

        printf("Ola Mundo... da thread = %d\n", omp_get_thread_num());
    }
    // Fim da regiao paralela
}

Como especificamos, o número de threads a serem executados como 5, estes 5 threads executarão a mesma instrução de impressão ao mesmo tempo. Aqui, não podemos garantir a ordem de execução dos threads, ou seja, a ordem de execução da instrução na região paralela não será a mesma para todas as execuções.

Na imagem a seguir, durante a primeira execução do programa, o encadeamento 1 é concluído primeiro, sendo que na segunda execução do programa, o encadeamento 0 é o primeiro a ser concluído. omp_get_thread_num () retornará o número do thread (tarefa) associado ao segmento.

Veja a saída de uma execução do programa.

aluno@ubuntu: ~$ export OMP_NUM_THREADS=5
aluno@ubuntu: ~$ gcc -o hello -fopenmp hello.c
aluno@ubuntu: ~$ ./hello
Ola Mundo... da thread = 1
Ola Mundo... da thread = 0
Ola Mundo... da thread = 4
Ola Mundo... da thread = 3
Ola Mundo... da thread = 2

Quando executado por várias vezes: a ordem de execução dos threads muda a cada vez.

aluno@ubuntu: ~$ ./hello
Ola Mundo... da thread = 1
Ola Mundo... da thread = 0
Ola Mundo... da thread = 4
Ola Mundo... da thread = 3
Ola Mundo... da thread = 2
aluno@ubuntu: ~$ ./hello
Ola Mundo... da thread = 0
Ola Mundo... da thread = 4
Ola Mundo... da thread = 3
Ola Mundo... da thread = 2
Ola Mundo... da thread = 1

A memória compartilhada pode ser um método de comunicação entre processos. A memória compartilhada não é escalável, pois os processos compartilham a mesma memória no mesmo computador, dificultando a expansão da quantidade de memória disponível. Por compartilharem o mesmo espaço de memória, ocorrem problemas de coerência, pois os processos estão disputando o mesmo espaço de memória.

Memória Distribuída

A memória distribuída refere-se a um sistema de computador multiprocessador no qual cada processador tem sua própria memória privada. As tarefas computacionais só podem operar em dados locais e, se forem necessários dados remotos, a tarefa computacional deve se comunicar com um ou mais processadores remotos.

Em contraste, como vimos anteriormente, um multiprocessador de memória compartilhada oferece um único espaço de memória usado por todos os processadores. Os processadores não precisam estar cientes de onde os dados residem, exceto de que pode haver penalidades de desempenho e que as condições de corrida devem ser evitadas.

Condições de corrida são situações caracterizadas pelo acesso simultâneo de dois ou mais processos a dados compartilhados, em um processamento ou sistema cujo resultado final depende da ordem de execução de seus processos.

Em um sistema de memória distribuída, normalmente, há um processador, uma memória e alguma forma de interconexão que permite que os programas em cada processador interajam uns com os outros. A interconexão pode ser organizada com enlaces ponto a ponto ou o hardware separado pode fornecer uma rede de comutação.

A topologia da rede é um fator chave para determinar como a máquina multiprocessadora é dimensionada. Os enlaces entre os nós podem ser implementados usando algum protocolo de rede padrão (onde a comunicação via placas Ethernet é a mais comum) ou algum outro tipo de comunicação. Como a comunicação, geralmente, é por protocolos de rede, pode existir uma grande latência nestas operações, que em operações bloqueantes (síncronas) pode não ser apropriado. Assim, as comunicações assíncronas (em regra as não bloqueantes) são as mais utilizadas nesse tipo de sistema.

O principal problema na programação de sistemas de memória distribuída é como distribuir os dados pelas memórias. Dependendo do problema resolvido, os dados podem ser distribuídos estaticamente ou podem ser movidos através dos nós. Os dados podem ser movidos sob demanda ou podem ser enviados para os novos nós com antecedência.

A principal vantagem da memória compartilhada é que ela oferece um espaço de endereço unificado no qual todos os dados podem ser encontrados, além dos dados serem acessados com maior rapidez.

A vantagem da memória distribuída é que ela exclui condições de corrida, e a principal preocupação do programador é pensar sobre a distribuição de dados. Da mesma forma, a memória distribuída é muito mais escalável do que a memória compartilhada, bastando acessar novos nós a rede. Por outro lado, em que pese a ocultar o mecanismo de comunicação, não é possível deixar de considerar a latência de comunicação para acessar os dados.

Um programa que usa as funcionalidades de memória distribuída tem de ser explicitamente desenvolvido com essa capacidade. Geralmente, isso é feito usando uma biblioteca MPI (no caso da memória compartilhada, usamos no nosso exemplo o OpenMP). Não se preocupe em executar este código no seu computador, alguns conceitos não foram tratados, mas irá permitir que você tenha uma visão do emprego da memória distribuída, conforme veremos em nosso vídeo: https://player.vimeo.com/video/549006057

// Bibliotecas do MPI necessarias
#include "mpi.h"
#include <stdio.h>

int main(int argc, char *argv[])
{
    int  numtasks, rank, len, rc;
    char hostname[MPI_MAX_PROCESSOR_NAME];

    // initializando o MPI
    MPI_Init(&argc,&argv);
    // obtendo o numero de tasks
    MPI_Comm_size(MPI_COMM_WORLD,&numtasks);
    // obtendo o rank
    MPI_Comm_rank(MPI_COMM_WORLD,&rank);
    // obtendo o nome do processador
    MPI_Get_processor_name(hostname, &len);
    printf ("Number of tasks= %d My rank= %d Running on %s\n", numtasks,rank,hostname);
    // finalizando o MPI
    MPI_Finalize();
}

A memória distribuída é altamente escalável e a vantagem da memória distribuída é que ela exclui condições de corrida. O programador deve pensar sobre a distribuição de dados. Os processadores não precisam estar cientes de onde os dados residem, exceto de que pode haver penalidades de desempenho e que as condições de corrida devem ser evitadas.

PARALELISMO DE DADOS

O paralelismo de dados é a paralelização dos dados entre vários processadores em ambientes de computação paralela:

Concentra-se na distribuição dos dados em nós diferentes, que operam nos dados em paralelo.
Pode ser aplicado em estruturas de dados regulares, como arrays e matrizes, trabalhando em cada elemento em paralelo.

Um trabalho paralelo de dados em uma matriz de n elementos pode ser dividido igualmente entre todos os processadores.

Vamos supor que queremos somar todos os elementos da matriz fornecida e o tempo para uma única operação de adição é unidades de tempo Ta.

No caso de execução sequencial, o tempo gasto pelo processo será n x Ta unidades de tempo, pois soma todos os elementos de uma matriz.

Por outro lado, se executarmos esse trabalho como um trabalho paralelo de dados em 4 processadores, o tempo gasto seria reduzido para (n x Ta)/4, desconsiderando eventuais atrasos de execução e operações obrigatoriamente serializáveis já citados na lei Amdahl. Nesse caso, a execução paralela resulta em uma aceleração de 4 em relação à execução sequencial.

Atenção: Uma questão interessante a se notar é que a localidade das referências de dados desempenha um papel importante na avaliação do desempenho de um modelo de programação paralela de dados.

A localidade dos dados depende de dois fatores:

Acessos à memória realizados pelo programa.
Tamanho do cache.

Em um sistema multiprocessador que executa um único conjunto de instruções (SIMD), arquitetura de dados que já explanamos, o paralelismo de dados é obtido quando cada processador executa a mesma tarefa em diferentes dados distribuídos.

Em algumas situações, um único thread de execução controla as operações em todos os dados.

Em outras, diferentes threads controlam a operação, mas executam o mesmo código.

Exemplo: Considere a multiplicação e adição de matrizes de maneira sequencial. Veja a seguir o pseudocódigo sequencial para multiplicação e adição de duas matrizes onde o resultado é armazenado na matriz C. O pseudocódigo para multiplicação calcula o produto escalar de duas matrizes A e B e armazena o resultado na matriz de saída C.

Se os programas a seguir forem executados sequencialmente, o tempo necessário para calcular o resultado seria O(n³), assumindo que os comprimentos de linha e de coluna de ambas as matrizes são n e O(n) para multiplicação e adição, respectivamente.

// Multiplicacao de matrizes
for (i = 0; i < row_length_A; i++)
{
    for (k = 0; k < column_length_B; k++)
    {
        sum = 0;
        for (j = 0; j < column_length_A; j++)
        {
            sum += A[i][j] * B[j][k];
        }
        C[i][k] = sum;
    }
}
// Adicao de arrays
for (i = 0; i < n; i++) {
    c[i] = a[i] + b[i];
}

Podemos explorar o paralelismo de dados no código anterior para executá-lo mais rapidamente, pois a aritmética é independente em relação ao loop.

A paralelização do código de multiplicação da matriz é obtida usando o OpenMP. Uma diretiva OpenMP, "omp parallel for" instrui o compilador a executar o código no loop for em paralelo. Para multiplicação, podemos dividir a matriz A e B em blocos ao longo de linhas e colunas, respectivamente. Isso nos permite calcular cada elemento na matriz C individualmente, tornando a tarefa paralela.

Exemplo: Matriz A versus Matriz B

A[m x n].B[n x k] pode ser finalizado em O(n) em vez de O(m*n*k) quando executado em paralelo usando m * k processadores.

// Multiplicação de matrizes em paralelo
#pragma omp parallel for schedule(dynamic,1) collapse(2)
for (i = 0; i < row_length_A; i++){
    for (k = 0; k < column_length_B; k++){
        sum = 0;
        for (j = 0; j < column_length_A; j++){
            sum += A[i][j] * B[j][k];
        }
        C[i][k] = sum;
    }
}

Pode-se observar a partir do exemplo que, conforme os tamanhos das matrizes continuam aumentando, serão necessários muitos processadores. Manter o tempo de execução baixo é a prioridade, mas, na medida em que o tamanho da matriz aumenta, nos deparamos com outras restrições, como a complexidade de tal sistema e seus custos associados. Portanto, restringindo o número de processadores no sistema, podemos ainda aplicar o mesmo princípio e dividir os dados em blocos maiores para calcular o produto de duas matrizes.

Para adição de matrizes em uma implementação paralela de dados, vamos supor um sistema mais modesto com duas CPUs A e B. A CPU A poderia adicionar todos os elementos da metade superior das matrizes, enquanto a CPU B poderia adicionar todos os elementos da metade inferior das matrizes. Como os dois processadores funcionam em paralelo, a tarefa de realizar a adição do array levaria metade do tempo de realizar a mesma operação em série usando apenas uma CPU.

O paralelismo de dados está muito em voga nos dias atuais, e talvez as placas com tecnologia GPU sejam o sinônimo desta tecnologia. Esse tipo de abordagem não será o foco do nosso estudo.

Utiliza-se computação síncrona no paralelismo de dados. A mesma tarefa é executada em diferentes subconjuntos de dados e a quantidade de paralelização é proporcional ao tamanho da entrada.

Para saber mais sobre os assuntos explorados neste tema, pesquise:

Os livros mais adotados para sistemas distribuídos, que são os de COULOURIS et al., 2013 e TANENBAUM e STEEM, 2006. Neles, podem ser encontrados os principais conceitos referentes a esses assuntos.
O tutorial de OpenMP do Lawrence Livermore National Laboratory, onde se encontram orientações bem detalhadas sobre programação paralela e distribuída.
Um exemplo completo e detalhado da multiplicação de matrizes, disponível em Matrix Multiplication with OpenMP e Mxm Openmp c.

PARALELISMO DE TAREFAS

O paralelismo de tarefas (também conhecido como paralelismo de função e paralelismo de controle) é uma forma de paralelismo de código de computador em vários processadores em ambientes de computação paralela. Concentra-se na distribuição de tarefas — executadas simultaneamente por processos ou threads — em diferentes processadores. Em contraste com o paralelismo de dados, que envolve a execução da mesma tarefa em diferentes componentes de dados, distingue-se pela execução de muitas tarefas diferentes ao mesmo tempo nos mesmos dados.

Atenção: Em um sistema multiprocessador, o paralelismo de tarefas é obtido quando cada processador executa um thread diferente (ou processo) nos mesmos dados ou em dados diferentes, diferentemente do que vimos no paralelismo de dados, onde os threads executam a mesma tarefa.

Os threads podem executar o mesmo código ou código diferente. No caso geral, diferentes threads de execução se comunicam uns com os outros enquanto funcionam, mas isso não é um requisito. A comunicação geralmente ocorre passando dados de um thread para o próximo como parte de um fluxo de trabalho. Essa comunicação entre threads pode ser executada inclusive utilizando mecanismos de memória distribuída.

Exemplo: Se um sistema está executando o código em um sistema de dois processadores (CPUs "a" e "b") em um ambiente paralelo e queremos fazer as tarefas "A" e "B", é possível dizer CPU "a" para fazer a tarefa "A" e CPU "b" para fazer a tarefa "B" simultaneamente, reduzindo assim o tempo de execução. As tarefas podem ser atribuídas usando instruções condicionais.

O paralelismo de tarefas enfatiza a natureza distribuída (paralelizada) do processamento (ou seja, threads), em oposição aos dados (paralelismo de dados).

O paralelismo de nível de thread (TLP) é o paralelismo inerente a um aplicativo que executa vários threads de uma vez. Esse tipo de paralelismo é encontrado principalmente em aplicativos escritos para servidores comerciais, como bancos de dados. Ao executar muitos threads de uma vez, esses aplicativos são capazes de tolerar as altas quantidades de input e output e latência do sistema de memória em que suas cargas de trabalho podem incorrer - enquanto um thread está atrasado esperando por um acesso à memória ou disco, outros threads podem fazer um trabalho útil.

A exploração do paralelismo de nível de thread também começou a fazer incursões no mercado de desktops com o advento dos microprocessadores multicores. Nos computadores de mesa, isso ficou evidenciado com o advento do Windows NT e do Windows 95, em que pese a essas tecnologias, já eram possíveis em outros sistemas operacionais, como o SunOS e o Solaris. Isso ocorreu porque, por várias razões, tornou-se cada vez mais impraticável aumentar a velocidade do clock ou as instruções por clock de um único núcleo.

Comentário: Se essa tendência continuar, novos aplicativos terão de ser projetados para utilizar vários threads para se beneficiar do aumento potencial do poder de computação. Isso contrasta com as inovações anteriores do microprocessador, nas quais o código existente era automaticamente acelerado ao ser executado em um computador mais novo / mais rápido.

O exemplo que mostramos em memórias compartilhada também serve como exemplo de uma tarefa distribuída, onde cada thread executava a função de imprimir o seu Id. Uma forma simples seria colocar uma função dentro do espaço reservado para o paralelismo.

https://player.vimeo.com/video/549007806

As tarefas diferentes podem ser executadas nos mesmos dados que foram disponibilizados para processamento. A quantidade de paralelização é proporcional ao número de tarefas independentes realizadas e como cada processador executará um thread, ou processo, diferente no mesmo conjunto de dados ou em um conjunto diferente de dados, a aceleração é menor.

Fundamentos de Computação Paralela

O desenvolvimento dos sistemas distribuídos nos permitiu acessar diversos tipos de aplicações, disponibilizadas na internet. Essas aplicações mudaram a forma de estudarmos, de trabalharmos, de nos divertimos e até a maneira como as pessoas se relacionam.

Uma aplicação distribuída, porém, tem algumas complexidades. Por ser distribuída, existem vários processos que vão compô-la e, consequentemente, há a necessidade de uma coordenação entre esses processos.

Vários processos sendo executados simultaneamente dão origem ao conceito de programação paralela − divisão de uma tarefa computacional em instâncias (processos) independentes e que podem ser executados de forma paralela.

Os processos que são executados em paralelo, no entanto, podem trazer algumas situações inconvenientes durante sua execução. Imagine, por exemplo, que existe um recurso − como uma impressora − que deve ser acessado por esses processos que estão executando em paralelo. Se todos quiserem acessar simultaneamente, teremos problemas para definir quem irá imprimir primeiro.

É necessário conhecer os fundamentos da computação paralela para entender os problemas que existem nesse paradigma computacional e quais mecanismos podemos utilizar para evitar ou, pelo menos, minimizar os seus efeitos.

Por fim, conheceremos diversas plataformas que podem ser utilizadas para o desenvolvimento de programas paralelos.

https://player.vimeo.com/video/558221759

O thread mestre normalmente espera por solicitações de trabalho − por exemplo, em uma rede −, e, quando um novo pedido chega, ele bifurca/inicia um thread de trabalho.

Esse thread executa a solicitação e, quando conclui o trabalho, termina e se junta ao thread mestre. Esse tipo de modelo faz uso eficiente dos recursos do sistema, uma vez que os recursos exigidos por um thread só estão sendo usados enquanto este está realmente em execução.

VARIÁVEIS COMPARTILHADAS

Antes de mais nada, saiba que:

Em programas de memória compartilhada, as variáveis podem ser compartilhadas ou privadas.

Em um ambiente onde um processo possui vários threads, as variáveis compartilhadas podem ser lidas ou escritas por qualquer um deles, e variáveis privadas normalmente podem ser acessadas apenas por um thread. Quando a comunicação entre os threads é feita por meio de variáveis compartilhadas, ela é implícita, não explícita − como por soquetes (sockets) ou named pipes.

Comentário: Em muitos ambientes, os programas de memória compartilhada usam threads dinâmicos. Nesse modelo, geralmente há um thread mestre e, em qualquer momento, uma coleção (possivelmente vazia de início) de threads de trabalho.

O thread mestre normalmente espera por solicitações de trabalho − por exemplo, em uma rede −, e, quando um novo pedido chega, ele bifurca/inicia um thread de trabalho.

PARADIGMA DE THREAD ESTÁTICO

Uma alternativa ao paradigma dinâmico é o paradigma de thread estático. Nesse paradigma, todos os threads são bifurcados/iniciados após qualquer configuração necessária pelo thread mestre e os threads são executados até que todo o trabalho seja concluído. Depois que os threads se juntam ao thread mestre, este pode fazer alguma limpeza (por exemplo, liberação de memória) e, então, também finaliza esses threads.

Atenção: Em termos de uso de recursos, isso pode ser menos eficiente: se um thread estiver ocioso, seus recursos (por exemplo: pilha, contador de programa etc.) não podem ser liberados.

No entanto, bifurcar e unir threads podem ser operações bastante demoradas. Portanto, se os recursos necessários estiverem disponíveis, o paradigma de thread estático tem potencial de melhor desempenho do que o paradigma dinâmico. Ele também tem a virtude de estar mais próximo do paradigma mais amplamente usado para programação de memória distribuída, então, parte da memória que é usada para um tipo de sistema é preservada para o outro.

Assim, o paradigma de thread estático é o mais frequente.

CÁLCULO NÃO DETERMINÍSTICO

Em qualquer sistema MIMD, Instrução Múltipla - Dados Múltiplos – em inglês, Multiple Instruction Multiple Data, no qual os processadores são executados de forma assíncrona, é provável que haja não determinismo das tarefas. Um cálculo é não determinístico se uma entrada específica pode resultar em saídas diferentes. Se vários threads estiverem executando de forma independente, a taxa relativa na qual eles concluirão as instruções varia de execução para execução e, portanto, os resultados do programa podem ser diferentes a cada execução.

Exemplo:

Suponha que temos dois threads, um com id 0 e o outro com id 1. Suponha também que cada um está armazenando uma variável privada x, o valor de x na thread 0 é 5 e na thread 1 é 8. Além disso, imagine que ambos os threads executem o seguinte código:

printf("Thread %d > val = %dnn", x);

Então, a saída pode ser:

Thread 0 >  val = 5

Thread 1 >  val = 8

Mas pode ser também:

Thread 1 > val = 8

Thread 0 > val = 5

Na verdade, as coisas podem ser ainda piores: a saída de um thread pode ser interrompida pela saída de outro thread. No exemplo anterior, estamos apenas tratando de uma saída.

No entanto, como os threads estão executando de forma independente e interagindo com o sistema operacional, o tempo que leva para um thread completar um bloco de instruções varia de execução para execução. Portanto, a ordem em que essas instruções são concluídas não pode ser prevista.

Comentário: Em muitos casos, o não determinismo não é um problema. Em nosso exemplo, uma vez que rotulamos a saída com a classificação do tópico, a ordem em que a saída aparece provavelmente não importa. No entanto, também existem muitos casos em que o não determinismo, especialmente em programas de memória compartilhada, pode ser desastroso, porque pode facilmente resultar em erros de programa.

Vejamos um exemplo simples com dois threads: suponha que cada thread calcule um valor inteiro, que ele armazena em uma variável privada val, e que queremos adicionar os valores armazenados em val em um local de memória compartilhada x que foi inicializado em 0. Ambos os threads, portanto, desejam executar um código semelhante a este:

val = Compute_val(my_rank);
x += val;

Agora, lembre-se de que uma adição normalmente requer o carregamento dos dois valores a serem adicionados aos registradores, a adição dos valores e, por fim, o armazenamento do resultado. Para manter o exemplo relativamente simples, vamos presumir que os valores são carregados da memória principal diretamente nos registradores e armazenados na memória principal diretamente dos registradores. Na tabela a seguir, visualizamos uma sequência possível de execução desses threads utilizando os valores 5 e 8 do exemplo anterior:

Tempo	Núcleo 1	Núcleo 2
0	Carrega o valor de val	Chama a função Compute_val
1	Carrega x = 0 para o registrador	Carrega o valor de val
2	Carrega val = 5 para o registrador	Carrega x = 0 para o registrador
3	Adiciona val a x	Carrega val = 8 para o registrador
4	Armazena x = 5	Adiciona val a x
5	Inicia outro trabalho	Armazena x = 8

Claramente, não é isso que queremos, pois o resultado deveria considerar que estamos incrementando o valor de x, e o resultado esperado deveria ser 13. Assim, é fácil imaginar outras sequências de eventos que resultam em um valor incorreto para x.

O não determinismo aqui é resultado do fato de que duas threads estão tentando atualizar mais ou menos simultaneamente à localização da memória x.

Quando threads ou processos tentam acessar simultaneamente um recurso, e os acessos podem resultar em erro, costumamos dizer que o programa tem uma condição de corrida, porque os threads ou processos estão em uma “corrida de cavalos”. Ou seja, o resultado do cálculo depende de qual thread ganha a corrida. Em nosso exemplo, os threads estão em uma corrida para executar x + = val. Nesse caso, a menos que um encadeamento conclua x + = val antes do outro encadeamento iniciar, o resultado será incorreto.

Você sabia: Um bloco de código que só pode ser executado por um thread de cada vez é chamado de seção crítica (veremos isso em mais detalhes adiante), e, geralmente, é nosso trabalho como programadores garantir acesso mutuamente exclusivo à seção crítica. Em outras palavras, precisamos garantir que, se um encadeamento estiver executando o código na seção crítica, os outros encadeamentos serão excluídos.

MUTEX

O mecanismo mais comumente utilizado para garantir a exclusão mútua é um bloqueio de exclusão mútua ou mutex ou bloqueio.

Atenção: A ideia básica é que cada seção crítica seja protegida por um “tipo de fechadura”. Antes que um thread possa executar o código na seção crítica, ele deve "obter" essa fechadura, no caso o mutex, chamando uma função mutex e, quando terminar de executar o código na seção crítica, deve "abandonar" o mutex, chamando uma função de desbloqueio.

Enquanto um thread "possui" o bloqueio − isto é, retornou de uma chamada para a função de bloqueio, mas ainda não chamou a função de desbloqueio −, qualquer outro thread que tentar executar o código na seção crítica aguardará em sua chamada para a função de bloqueio.

Para garantir que nosso código funcione corretamente, podemos modificá-lo para que se pareça com isto:

val = Compute_val(my_rank);
Lock(&add my_val_lock);
x += val;
Unlock(&add my_val_lock);

Assim, garante-se que apenas um thread de cada vez possa executar a instrução x + = val. Observe que o código não impõe nenhuma ordem predeterminada nos threads que executam o código. Tanto o thread 0 quanto o thread 1 podem executar x + = val primeiro.

Observe também que o uso de um mutex impõe a serialização da seção crítica. Como apenas um thread por vez pode executar o código na seção crítica, esse código é efetivamente serial. Portanto, queremos que nosso código tenha o menor número possível de seções críticas, e que nossas seções críticas sejam as mais curtas possíveis.

Existem alternativas para seções críticas além do mutex. Na espera ocupada, por exemplo, um thread entra em um loop cujo único propósito é testar uma condição.

Suponha que haja uma variável compartilhada ok que foi inicializada como falsa. Então, algo como o código a seguir pode garantir que o thread 1 não atualize x até que o thread 0 o tenha atualizado:

val = Compute_val(my_rank);
while (ok != 1); // Espera ocupada
ok = 0 // Bloqueia a entrada de outros thread
x += my val; // Executa a seção crítica
ok = 1 // Desbloqueia a variável

Até que o thread 0 seja executado, a variável ok passa para o valor 0, bloqueando a entrada de outros threads. Assim, o thread 1 ficará preso no loop while (ok != 1); − chamado de "espera ocupada", porque o thread pode estar muito ocupado esperando a condição.

Saiba mais: Simples de entender e implementar, isso, no entanto, pode ser um grande desperdício de recursos do sistema, porque mesmo quando um encadeamento não está fazendo nenhum trabalho útil, o núcleo que o executa verifica repetidamente se a seção crítica pode ser acessada.

MEMÓRIA COMPARTILHADA

Tratamos, até aqui, do uso simplificado de memória compartilhada utilizando threads dentro de um mesmo processo. Entretanto, é possível fazer o uso de memória compartilhada usando processos diferentes, como você pode observar na imagem a seguir:

Sabemos que, para nos comunicarmos entre dois ou mais processos, usamos memória compartilhada. Mas, antes de usar a memória compartilhada, o que precisa ser feito com as chamadas de sistema, tendo uma sequência de operações para isso?

Devemos criar o segmento de memória compartilhada. No Linux, isso pode ser feito com a chamada shmget().
Devemos, posteriormente, anexar o segmento de memória anteriormente criado ao nosso programa com a chamada shmget().
Fazemos nossas operações sobre a memória, como escrita e leitura, com a chamada shmget().
Vale ressaltar que devemos ter todos os cuidados necessários, decorrentes da programação concorrente, citados neste conteúdo.
Por fim, devemos desanexar o segmento de memória compartilhada de nosso programa com a chamada shmget().

O uso de memória compartilhada em processos distintos também está disponível nos diversos sistemas operacionais, como, por exemplo, o Windows.

https://player.vimeo.com/video/558216109

CONDIÇÕES DE CORRIDA

Uma condição de corrida ou risco de corrida, como vimos anteriormente, é a condição na qual o comportamento do sistema depende da sequência ou do tempo de outros eventos incontroláveis.

Torna-se um bug quando um ou mais dos comportamentos possíveis são indesejáveis.

Uma condição de corrida surge no software quando um programa de computador, para operar corretamente, depende da sequência ou do tempo dos processos ou threads do programa.

Saiba mais: Condições críticas de corrida − que frequentemente acontecem quando os processos ou threads dependem de algum estado compartilhado − causam execução inválida e bugs de software. As operações em estados compartilhados são feitas em seções críticas que devem ser mutuamente exclusivas. O não cumprimento dessa regra pode corromper o estado compartilhado.

Uma condição de corrida pode ser difícil de reproduzir e depurar, pois o resultado não é determinístico e depende do tempo relativo entre threads interferentes. Problemas dessa natureza podem, então, desaparecer durante a execução no modo de depuração, adicionando log extra ou anexando um depurador. Os erros que desaparecem durante as tentativas de depuração são geralmente chamados de heisenbug. Portanto, é melhor evitar condições de corrida por meio de um projeto de software cuidadoso.

Suponha que cada um de dois threads incremente o valor de uma variável inteira global em 1. Idealmente, a seguinte sequência de operações ocorreria:

Thread 1	Thread 2		Valor da variável
			0
Ler valor		←	0
Incrementar valor			0
Escrever valor		→	1
	Ler valor	←	1
	Incrementar valor		1
	Escrever valor	→	2

Nesse caso, o valor final é 1, em vez do resultado correto de 2. Isso ocorre porque aqui as operações de incremento não são mutuamente exclusivas.

Mutuamente exclusivas operações mutuamente exclusivas são aquelas que não podem ser interrompidas durante o acesso a algum recurso, como um local de memória.

Comentário: Nem todos consideram as corridas de dados como um subconjunto das condições de corrida. A definição precisa de corrida de dados é específica para o modelo de simultaneidade formal que está sendo usado.

Normalmente, porém, refere-se a uma situação na qual uma operação de memória em um encadeamento de threads pode tentar acessar um local de memória ao mesmo tempo que uma operação de memória em outro encadeamento está escrevendo para esse local da memória, em um contexto no qual isso é perigoso. Isso implica que uma corrida de dados é diferente de uma condição de corrida, pois é possível haver não determinismo devido ao tempo, mesmo em um programa sem corrida de dados. Por exemplo, em um programa no qual todos os acessos à memória usam apenas operações atômicas.

Isso pode ser perigoso, porque, em muitas plataformas, se dois threads gravam em um local da memória ao mesmo tempo, é possível que o local da memória acabe mantendo um valor que é uma combinação arbitrária e sem sentido dos bits que representam os valores que cada thread estava tentando escrever. Com isso, pode haver uma corrupção de memória, se o valor resultante for um que nenhum thread tentou gravar (às vezes, isso é chamado de "gravação interrompida").

Da mesma forma, se um thread lê um local enquanto outro thread está gravando nele, é possível que a leitura retorne um valor que é uma combinação arbitrária e sem sentido dos bits que representam o valor que o local da memória mantinha antes da gravação e dos bits que representam o valor que está sendo escrito.

Atenção: Em muitas plataformas, operações de memória especiais são fornecidas para acesso simultâneo; nesses casos, normalmente o acesso simultâneo é seguro, mas o acesso simultâneo usando outras operações de memória é perigoso. Às vezes, essas operações especiais (que são seguras para acesso simultâneo) são chamadas de operações atômicas ou de sincronização, enquanto as operações comuns (que não são seguras para acesso simultâneo) são chamadas de operações de dados, sendo esse termo denominado de corrida de dados.

SINCRONIZAÇÃO DE PROCESSOS (Operações Atômicas)

A sincronização é a tarefa de coordenar a execução de processos, de forma que dois deles não possam ter acesso aos mesmos dados e recursos compartilhados.

Atenção: É especialmente necessária em um sistema de vários processos, quando vários deles estão sendo executados juntos e mais de um processo tenta obter, simultaneamente, acesso ao mesmo recurso ou dado compartilhado, o que pode levar à inconsistência de dados.

Isso porque a mudança feita por um processo não se reflete necessariamente quando outros acessam os mesmos dados compartilhados. Por exemplo: o processo A altera os dados em um local da memória enquanto outro processo B tenta ler os dados do mesmo local da memória. Há grande probabilidade de que os dados lidos pelo segundo sejam errôneos. Portanto, para evitar esse tipo de inconsistência de dados, os processos precisam ser sincronizados entre si.

A sincronização de threads é definida como um mecanismo que garante que dois ou mais processos ou threads simultâneos não executem simultaneamente algum segmento de programa específico conhecido como seção crítica.

O acesso dos processos à seção crítica é controlado por meio de técnicas de sincronização. Quando um thread começa a executar a seção crítica (segmento serializado do programa), o outro thread deve esperar até que o primeiro termine. Se as técnicas de sincronização adequadas não forem aplicadas, isso pode causar uma condição de corrida na qual os valores das variáveis podem ser imprevisíveis, dependendo dos tempos de troca de contexto dos processos ou threads.

Suponha que haja três processos: 1, 2 e 3. Todos os três estão executando simultaneamente e precisam compartilhar um recurso comum (seção crítica), conforme mostrado na imagem a seguir:

A sincronização deve ser usada aqui para evitar quaisquer conflitos para acessar esse recurso compartilhado. Portanto, quando os Processos 1 e 2 tentam acessar esse recurso, ele deve ser atribuído a apenas um processo por vez. Se for atribuído ao Processo 1, o Processo 2 precisa esperar até que o primeiro libere esse recurso. Veja na próxima imagem:

Precisamos satisfazer quatro condições para chegar a uma solução:

Dois processos nunca podem estar simultaneamente em suas regiões críticas.
Nada pode ser afirmado sobre a velocidade ou sobre o número de CPUs.
Nenhum processo executando fora de sua seção crítica pode bloquear outros processos.
Nenhum processo deve esperar eternamente para entrar em sua seção crítica.

Outro requisito de sincronização a ser considerado é a ordem na qual determinados processos ou threads devem ser executados. Não é possível, por exemplo, embarcar em um avião antes de comprar uma passagem ou verificar e-mails antes de validar as credenciais apropriadas (nome de usuário e senha). Da mesma forma, um caixa eletrônico não fornecerá nenhum serviço até que receba um PIN correto.

Além da exclusão mútua, a sincronização também lida com o seguinte:

Deadlock (impasse)

Conforme veremos mais detalhadamente adiante, deadlocks ocorrem quando muitos processos estão esperando por um recurso compartilhado (seção crítica) que está sendo mantido por algum outro processo. Nesse caso, os processos simplesmente continuam esperando e não são mais executados. Deadlocks também podem ocorrer entre máquinas.

Por exemplo, diversos escritórios têm redes locais com vários computadores conectados entre elas. Muitas vezes, dispositivos como scanners e impressoras são conectadas a essas redes como recursos compartilhados, disponíveis a qualquer usuário em qualquer máquina. Se esses dispositivos puderem ser reservados remotamente, o mesmo tipo de deadlock poderá ocorrer, como descrito anteriormente.

Starvation (fome)

Ocorre quando um processo está esperando para entrar na seção crítica, mas outros processos a monopolizam, e o primeiro é forçado a esperar indefinidamente.

Inversão de prioridade

Ocorre quando um processo de alta prioridade está na seção crítica e é interrompido por um de média prioridade. Essa violação das regras de prioridade pode acontecer em certas circunstâncias, e pode levar a sérias consequências em sistemas de tempo real.

Espera ocupada

Ocorre quando um processo pesquisa frequentemente para determinar se tem acesso a uma seção crítica. Essa pesquisa frequente rouba o tempo de processamento de outros processos.

Um dos desafios para o projeto do algoritmo em ambientes distribuídos é minimizar ou reduzir a sincronização − que pode levar mais tempo do que a computação, especialmente na computação distribuída. A redução da sincronização atraiu a atenção dos cientistas da computação por décadas e, à medida que a lacuna entre a melhoria da computação e a latência aumenta, isso se torna um problema cada vez mais significativo.

PROBLEMAS CLÁSSICOS DE SINCRONIZAÇÃO

A seguir, alguns problemas clássicos de sincronização:

PROBLEMA PRODUTOR-CONSUMIDOR (PROBLEMA DE BUFFER LIMITADO)

Nesse problema, há um produtor (que está produzindo algo) e um consumidor (que está consumindo esses produtos produzidos). Os produtores e consumidores compartilham o mesmo buffer de memória de tamanho fixo.

O trabalho do produtor é gerar os dados, colocá-los no buffer (Em ciência da computação, buffer de dados é uma região de memória física utilizada para armazenar temporariamente os dados enquanto eles estão sendo movidos de um lugar para outro.) e, novamente, começar a gerar dados. Enquanto o trabalho do consumidor é consumir os dados do buffer.

O produtor deve produzir dados apenas quando o buffer não estiver cheio. Se estiver cheio, o produtor não deve ter permissão para colocar nenhum dado no buffer.

O consumidor, por sua vez, deve consumir dados apenas quando o buffer não está vazio. Se estiver vazio, o consumidor não deve ter permissão para retirar nenhum dado do buffer. O produtor e o consumidor não devem acessar o buffer ao mesmo tempo.

PROBLEMA DOS LEITORES-ESCRITORES

O problema dos leitores-escritores está relacionado a um objeto, como um arquivo que é compartilhado entre vários processos. Alguns desses processos são leitores (querem apenas ler os dados do objeto) e alguns são escritores (querem escrever no objeto).

O problema dos leitores-escritores é usado para gerenciar a sincronização, de forma que não haja intercorrências com os dados do objeto.

Se dois leitores, por exemplo, acessarem o objeto ao mesmo tempo, não há problema. No entanto, se dois escritores ou um leitor e um escritor o acessarem ao mesmo tempo, pode haver problemas. Para resolver essa situação, um escritor deve obter acesso exclusivo a um objeto. Ou seja, quando um escritor está acessando o objeto, nenhum leitor ou escritor pode acessá-lo. No entanto, vários leitores podem acessar o objeto ao mesmo tempo.

PROBLEMA DO JANTAR DOS FILÓSOFOS

O problema do jantar dos filósofos afirma que há cinco filósofos compartilhando uma mesa circular, e eles comem e pensam alternativamente. Há uma tigela de arroz para cada um dos filósofos, além de cinco hashis. Um filósofo precisa de dois hashis para comer. Um filósofo faminto só pode comer se houver os dois talheres disponíveis. Do contrário, ele abaixa o talher e começa a pensar novamente. O grande problema nesse algoritmo é que, se todos os filósofos pegarem somente um hashi, todos ficarão parados para sempre, aguardando o segundo talher ficar disponível, gerando um deadlock (ou impasse).

Esses problemas são usados para testar quase todos os esquemas de sincronização ou primitivos recentemente propostos.

EXCLUSÃO MÚTUA

Na ciência da computação, a exclusão mútua é uma propriedade do controle de concorrência, instituída com o objetivo de prevenir condições de corrida.

É o requisito de que um thread de execução nunca entre em uma seção crítica enquanto um thread simultâneo de execução já a está acessando. Refere-se a um intervalo de tempo durante o qual um thread de execução acessa um recurso compartilhado, como memória e objetos de dados compartilhados.

Comentário: Conforme vimos, a seção crítica é um objeto de dados que dois ou mais threads simultâneos estão tentando modificar (no qual duas operações de leitura simultâneas são permitidas, mas não são permitidas duas operações de gravação simultâneas ou uma leitura e uma gravação, pois isso leva à inconsistência dos dados).

O algoritmo de exclusão garante, portanto, que, se um processo já estiver executando a operação de gravação em um objeto de dados, nenhum outro tem permissão para acessar e modificar o mesmo objeto ou seção crítica até que o primeiro tenha concluído a gravação e liberado o objeto para outros processos lerem e escreverem. Em outras palavras, a seção crítica passa a ser de uso exclusivo do processo que a acessou inicialmente.

Um exemplo simples de porque a exclusão mútua é importante na prática pode ser visualizado usando uma lista unida de quatro itens, na qual o segundo e o terceiro devem ser removidos, como pode ser exemplificado na imagem a seguir: Lista unida de quatro itens.

A remoção de um nó que fica entre dois outros é realizada mudando o ponteiro próximo do nó anterior para apontar para o próximo nó. Em outras palavras, se o nó está sendo removido, então o ponteiro próximo de nó é alterado para apontar para o nó , removendo assim da lista encadeada qualquer referência ao nó . Observe a imagem a seguir: Lista unida após movimentação do ponteiro próximo de n-.

Quando tal lista encadeada está sendo compartilhada entre vários threads de execução, dois threads de execução podem tentar remover dois nós diferentes simultaneamente − um thread de execução mudando o ponteiro próximo do nó i - 1 para apontar para o nó i + 1, enquanto outro thread de execução muda o ponteiro próximo do nó i para apontar para o nó i + 2. Embora ambas as operações de remoção sejam concluídas com sucesso, o estado desejado da lista vinculada não é alcançado: nó i + 1 permanece na lista, porque o ponteiro próximo do nó i - 1 aponta para o nó i + 1.

Esse problema (chamado de condição de corrida) pode ser evitado usando o requisito de exclusão mútua para garantir que atualizações simultâneas na mesma parte da lista não ocorram.

Saiba Mais: O termo exclusão mútua também é usado em referência à gravação simultânea de um endereço de memória por um thread/processo, enquanto o endereço de memória mencionado anteriormente está sendo manipulado ou lido por um ou mais threads/processos.

O problema que a exclusão mútua aborda é de compartilhamento de recursos:

Como um sistema de software pode controlar o acesso de vários processos a um recurso compartilhado, quando cada processo precisa do controle exclusivo desse recurso enquanto faz seu trabalho?

Para isso, a solução de exclusão mútua torna o recurso compartilhado disponível apenas enquanto o processo está em um segmento de código específico (seção crítica), com acesso exclusivo, impedindo que outros processos acessem essa área de código. Ele controla o acesso ao recurso compartilhado controlando cada execução mútua daquela parte do programa na qual o recurso seria usado.

Uma solução bem-sucedida para esse problema deve ter pelo menos duas propriedades:

Deve implementar a exclusão mútua: Apenas um processo pode estar na seção crítica de cada vez.
Deve estar livre de deadlocks: Se os processos estão tentando entrar na seção crítica, um deles deve ser capaz de fazê-lo com sucesso, desde que nenhum processo permaneça na seção crítica permanentemente.

A liberdade de deadlock pode ser expandida para implementar uma ou ambas as propriedades. A liberdade de bloqueio garante que qualquer processo que deseje entrar na seção crítica será capaz de fazê-lo eventualmente. Isso é diferente da prevenção de deadlock, que requer que algum processo em espera seja capaz de obter acesso à seção crítica, mas não requer que cada processo tenha sua vez. Se dois processos trocarem continuamente um recurso entre eles, um terceiro processo pode ser bloqueado e ficar sem recursos, mesmo que o sistema não esteja em um impasse. Se um sistema estiver livre de bloqueios, ele garante que todos os processos possam ser revertidos em algum ponto no futuro.

Uma propriedade de espera limitada por k fornece um compromisso mais preciso do que a liberdade de bloqueio. Isso porque, na liberdade de bloqueio, não dá nenhuma garantia sobre o tempo de espera. Um processo pode ser ultrapassado um número arbitrário ou ilimitado de vezes por outros de prioridade mais alta antes de chegar a sua vez. Sob uma propriedade de espera limitada por k, cada processo tem um tempo de espera máximo finito. Isso funciona estabelecendo um limite para o número de vezes que outros processos podem interromper a fila, de modo que nenhum deles possa entrar na seção crítica mais de k vezes enquanto outro está esperando.

O programa de cada processo pode ser dividido em quatro seções, resultando em quatro estados. A execução do programa percorre esses quatro estados, em ordem:

Seção não crítica: A operação está fora da seção crítica; o processo não está usando ou solicitando o recurso compartilhado.
Tentando: A operação está fora da seção crítica; o processo não está usando ou solicitando o recurso compartilhado.
Seção crítica: O processo tem permissão para acessar o recurso compartilhado nessa seção.
Saída: O processo sai da seção crítica e disponibiliza o recurso compartilhado para outros processos.

Se um processo deseja entrar na seção crítica, ele deve primeiro executar a seção de tentativa e esperar até obter acesso à seção crítica. Após ter executado sua seção crítica e finalizado com os recursos compartilhados, ele precisa executar a seção de saída para liberá-los para uso de outros processos. O processo então retorna à sua seção não crítica.

🆘 SEÇÃO CRÍTICA (Região)

Conforme vimos, na programação simultânea, os acessos simultâneos a recursos compartilhados podem levar a um comportamento inesperado ou errôneo. Portanto, partes do programa onde o recurso compartilhado é acessado precisam ser protegidas de maneiras que evitem o acesso simultâneo. Essa seção protegida − chamada de região ou seção crítica − não pode ser executada por mais de um processo por vez.

Normalmente, a seção crítica acessa um recurso compartilhado, como uma estrutura de dados, um dispositivo periférico ou uma conexão de rede, que não operaria corretamente no contexto de vários acessos simultâneos.

Comentário: Códigos ou processos diferentes podem consistir na mesma variável ou em outros recursos que precisam ser lidos ou escritos, mas cujos resultados dependem da ordem em que as ações ocorrem.

Por exemplo, se uma variável x deve ser lida pelo processo A e o processo B precisa gravar na mesma variável x ao mesmo tempo, o processo A pode obter o valor antigo ou o novo valor de x.

//Processo a
b = x + 5 // Instrução executada em Tx
//Processo b
x = 3 + z // Instrução executada em Tx

Em casos como esses, uma seção crítica é importante. No exemplo anterior, se A precisar ler o valor atualizado de x, executar o Processo A e o Processo B ao mesmo tempo pode não dar os resultados necessários. Para evitar isso, a variável x é protegida por uma seção crítica. Primeiramente, B obtém o acesso à seção. Assim que B terminar de escrever o valor, A terá acesso à seção crítica e a variável x poderá ser lida.

Controlando cuidadosamente quais variáveis são modificadas dentro e fora da seção crítica, o acesso simultâneo à variável compartilhada é evitado.

Uma seção crítica é normalmente usada quando um programa multithreaded deve atualizar várias variáveis relacionadas sem que um thread separado faça alterações conflitantes nesses dados.

Em uma situação relacionada, uma seção crítica pode ser usada para garantir que um recurso compartilhado − por exemplo, uma impressora − só possa ser acessado por um processo por vez.

🚘🚙 DEADLOCK (impasse)

Como vimos, na computação simultânea, um deadlock é um estado em que cada membro de um grupo espera que outro membro, incluindo ele mesmo, execute uma ação − como enviar uma mensagem ou, mais comumente, liberar um bloqueio.

Atenção: Deadlock são problemas comuns em sistemas de multiprocessamento (sistemas operacionais), banco de dados, computação paralela e sistemas distribuídos, em que bloqueios de software e hardware são usados para arbitrar recursos compartilhados e implementar sincronização de processos.

Em um sistema operacional, um deadlock ocorre quando um processo ou thread entra em um estado de espera porque um recurso de sistema solicitado é mantido por outro processo em espera − que, por sua vez, está esperando por outro recurso mantido por outro processo em espera.

Se um processo é incapaz de mudar seu estado indefinidamente porque os recursos solicitados por ele estão sendo usados por outro processo em espera, então o sistema é considerado um deadlock.

Em um sistema de comunicação, os deadlock ocorrem principalmente devido a sinais perdidos ou corrompidos, em vez de contenção de recursos. Uma situação de deadlock em um recurso pode surgir se e somente se todas as seguintes condições, conhecidas como as quatro condições de Coffman et al. 1971, forem mantidas simultaneamente em um sistema:

Exclusão mútua: Como vimos anteriormente, pelo menos um recurso deve ser mantido em um modo não compartilhável. Caso contrário, os processos não seriam impedidos de usar o recurso quando necessário. Apenas um processo pode usar o recurso em um determinado instante de tempo.
Reter e aguardar ou retenção de recurso: Um processo está atualmente retendo pelo menos um recurso e solicitando recursos adicionais que estão sendo retidos por outros processos.
Sem preempção: Um recurso só pode ser liberado voluntariamente pelo processo que o detém.
Espera circular: Cada processo deve estar esperando por um recurso que está sendo retido por outro processo, que, por sua vez, está aguardando que o primeiro processo libere o recurso. Em geral, existe um conjunto de processos de espera, P = {P1, P2, ..., PN}, tal que P1 está esperando por um recurso mantido por P2, P2 está esperando por um recurso mantido por P3 e assim por diante, até que PN seja esperando por um recurso mantido por P1.

Um deadlock ocorre se e somente se as quatro condições de Coffman forem satisfeitas:

Exclusão mútua.

Posse e espera.

Não preempção.

Espera circular.

Embora essas condições sejam suficientes para produzir um conflito em sistemas de recursos de instância única, elas indicam apenas a possibilidade de conflito em sistemas com várias instâncias de recursos.

A maioria dos sistemas operacionais atuais não pode evitar bloqueios. Quando ocorre um deadlock, diferentes sistemas operacionais respondem a eles de maneiras diferentes e fora do padrão. A maioria das abordagens funciona evitando que uma das quatro condições de Coffman ocorra, especialmente a espera circular.

As principais abordagens são:

IGNORANDO IMPASSE: Nessa abordagem, presume-se que nunca ocorrerá um deadlock. É usada quando os intervalos de tempo entre as ocorrências de deadlocks são grandes e a perda de dados incorrida a cada vez é tolerável. Ignorar deadlocks pode ser feito com segurança se estes forem formalmente comprovados como nunca ocorrendo.
DETECÇÃO: Na detecção de deadlocks, presumimos que estes podem ocorrer. Em seguida, o estado do sistema é examinado para detectar se ocorreu um conflito e, posteriormente, corrigi-lo. É empregado um algoritmo que rastreia a alocação de recursos e os estados do processo, reverte e reinicia um ou mais processos para remover o impasse detectado. Detectar um deadlock que já ocorreu é facilmente possível, uma vez que os recursos que cada processo bloqueou e/ou solicitou atualmente são conhecidos pelo escalonador de recursos do sistema operacional.

Depois que um deadlock é detectado, ele pode ser corrigido usando um dos seguintes métodos:

Encerramento do processo

Um ou mais processos envolvidos no deadlock podem ser abortados. Pode-se optar por abortar todos os processos concorrentes envolvidos no impasse, garantindo que o impasse seja resolvido com certeza e velocidade. Entretanto, eventuais processamentos anteriores podem ser perdidos.

O encerramento de processos pode seguir uma sequência, até que o impasse seja resolvido. Essa abordagem, porém, tem alto custo, porque após cada encerramento de processo/thread, um algoritmo deve determinar se o sistema ainda está em deadlock.

Vários fatores devem ser considerados ao escolher um candidato para o encerramento, como prioridade e tempo de execução do processo.

Preempção de recursos

Os recursos alocados a vários processos podem ser sucessivamente eliminados e alocados a outros processos até que o impasse seja resolvido.

A prevenção de deadlock funciona evitando que uma das quatro condições de Coffman ocorra. Remover a condição de exclusão mútua significa que nenhum processo terá acesso exclusivo a um recurso. Isso é impossível para recursos que não podem ser armazenados em spool. Mas, mesmo com recursos em spool, o impasse ainda pode ocorrer. Os algoritmos que evitam a exclusão mútua são chamados de algoritmos de sincronização sem bloqueio.

Spool é o processo que transfere dados colocando-os em uma área de trabalho temporária, na qual outro programa pode acessá-lo para processá-lo em um tempo futuro.

Comentário: As condições de retenção e espera ou retenção de recurso podem ser removidas exigindo que os processos solicitem todos os recursos de que precisarão antes de iniciar (ou antes de iniciar um determinado conjunto de operações). Esse conhecimento prévio é frequentemente difícil de satisfazer e, em qualquer caso, é um uso ineficiente de recursos.

Outra maneira é exigir que os processos solicitem recursos apenas quando não houver nenhum. Primeiro, eles devem liberar todos os seus recursos atualmente mantidos antes de solicitar todos os recursos de que precisarão do zero. Muitas vezes, isso também é impraticável, porque os recursos podem ser alocados e permanecer sem uso por longos períodos. Além disso, um processo que requer um recurso popular pode ter que esperar indefinidamente, já que este pode sempre ser alocado para algum processo, resultando em escassez de recursos. Esses algoritmos, como tokens de serialização, são conhecidos como algoritmos tudo ou nada. Eles devem liberar todos os seus recursos atualmente mantidos antes de solicitar todos os recursos de que precisarão do zero. Muitas vezes, isso também é impraticável, porque os recursos podem ser alocados e permanecer sem uso por longos períodos. Além disso, um processo que requer um recurso popular pode ter que esperar indefinidamente, já que este pode sempre ser alocado para algum processo, resultando em escassez de recursos. Esses algoritmos, como tokens de serialização, são conhecidos como algoritmos tudo ou nada.

A condição de ausência de preempção também pode ser difícil ou impossível de evitar, pois um processo deve ser capaz de ter um recurso por um determinado período de tempo, ou o resultado do processamento pode ser inconsistente. No entanto, a incapacidade de impor a preempção pode interferir com um algoritmo de prioridade.

A preempção de um recurso "bloqueado" geralmente implica uma reversão e deve ser evitada, uma vez que é muito cara em despesas gerais. Os algoritmos que permitem a preempção incluem algoritmos sem bloqueio e sem espera e controle de simultaneidade otimista. Se um processo retém alguns recursos e solicita algum outro que não pode ser alocado imediatamente a eles, a condição pode ser removida liberando todos os recursos retidos atualmente desse processo.

A condição final é a condição de espera circular. Abordagens que evitam esperas circulares incluem desabilitar interrupções durante seções críticas e usar uma hierarquia para determinar uma ordenação parcial de recursos. Se nenhuma hierarquia óbvia existe, até mesmo o endereço de memória dos recursos será usado para determinar a ordem, e os recursos serão solicitados na ordem crescente da enumeração.

Deadlocks distribuídos podem ocorrer em sistemas distribuídos quando transações distribuídas ou controle de simultaneidade estão sendo usados. Eles podem ser detectados pela construção de um gráfico de espera global a partir de gráficos de espera locais em um detector de deadlock ou por um algoritmo distribuído como perseguição de borda.

Os sistemas distribuídos podem ter três tipos de deadlocks: fantasma, de recurso e de comunicação. Veja-os a seguir:

Deadlocks fantasmas

São deadlocks falsamente detectados em um sistema distribuído devido a atrasos internos do sistema, mas não existem de fato.

Por exemplo, se um processo libera um recurso R1 e emite uma solicitação de R2, e a primeira mensagem é perdida ou atrasada, um coordenador (detector de deadlocks) pode concluir falsamente um deadlock (a solicitação de R2 enquanto tem R1 causaria um impasse). Em uma possível situação de deadlock fantasma, é muito difícil detectá-lo, porque vários processos podem liberar alguns recursos ou solicitar outros recursos ao mesmo tempo.

Em alguns casos, as mensagens de liberação chegam depois das mensagens de solicitação para alguns recursos específicos. O algoritmo de detecção trata a situação como um deadlock, e pode abortar alguns processos para quebrá-lo. Mas, na realidade, nenhum deadlock estava presente − os algoritmos o detectaram com base em mensagens desatualizadas dos processos devido a atrasos na comunicação. Esse impasse é chamado de impasse fantasma.

Deadlocks de recurso

Os processos podem esperar simultaneamente por vários recursos, e não podem prosseguir até que tenham adquirido todos eles. Um conjunto de processos fica em deadlock se cada processo no conjunto solicitar recursos mantidos por outro processo no conjunto. E deve receber todos os recursos solicitados antes que possa ser desbloqueado. Esse tipo de deadlock é muito parecido com os que observamos anteriormente.

Deadlocks de comunicação

Os processos esperam para se comunicar com outros em um conjunto. Um processo de espera pode ser desbloqueado ao receber uma comunicação de um desses processos.

Há conflito se cada processo no conjunto estiver esperando para se comunicar com outro e nenhum deles iniciar qualquer comunicação adicional até que receba a comunicação pela qual está esperando.

Assista ao vídeo a seguir e conheça as quatro condições necessárias para que ocorra o problema de deadlock.

🚦 Semáforo

Na ciência da computação, um semáforo é um tipo de dado variável ou abstrato empregado para controlar o acesso a um recurso comum por vários processos e evitar problemas de seção crítica em um sistema simultâneo, como um sistema operacional multitarefa. Um semáforo trivial é uma variável simples que é alterada (por exemplo, incrementada ou decrementada ou alternada), dependendo das condições definidas pelo programador.

Em ciência da computação, semáforo é uma variável especial protegida que tem como função o controle de acesso a recursos compartilhados num ambiente multitarefa. A invenção desse tipo de variável é atribuída a Edsger Dijkstra, em 1965 e foi utilizado inicialmente no sistema operacional THEOS.

Atenção: Os semáforos são uma ferramenta útil na prevenção de condições de corrida; entretanto, seu uso não é de forma alguma uma garantia de que um programa esteja livre desses problemas.

Os semáforos que permitem uma contagem arbitrária de recursos são chamados de semáforos de contagem, enquanto os que são restritos aos valores 0 e 1 (ou bloqueado/desbloqueado, indisponível/disponível) são chamados de semáforos binários e são usados para implementar bloqueios.

Exemplo:

Suponha que uma biblioteca tenha dez salas de estudo idênticas, para serem usadas por um aluno por vez. Os alunos devem solicitar na recepção, caso desejem usar uma sala de estudo e, se nenhuma estiver disponível, eles esperam na mesa. Quando um aluno terminar de usar uma sala, ele deve retornar à carteira e indicar que uma das salas ficou livre.

Na implementação mais simples, o funcionário da recepção sabe apenas o número de salas livres disponíveis. Quando um aluno solicita uma sala, o funcionário diminui esse número. Quando um aluno libera uma sala, o secretário aumenta esse número. As salas podem ser usadas por tempo indeterminado, por isso não é possível reservá-las com antecedência.

Nesse cenário, o contador da recepção representa um semáforo de contagem, as salas são o recurso e os alunos representam processos/threads. O valor do semáforo é inicialmente 10, com todas as salas vazias. Quando um aluno solicita uma sala, o valor do semáforo é alterado para 9. Depois que o próximo aluno chega, ele cai para 8, depois para 7 e assim por diante. Se alguém solicita uma sala e o valor atual do semáforo é 0, eles são forçados a esperar até que uma delas esteja disponível (quando a contagem é aumentada de 0).

Se uma das salas foi liberada, mas há vários alunos esperando, então qualquer método pode ser usado para selecionar aquele que irá ocupá-la. E os alunos precisam informar ao balconista sobre a liberação de sua sala somente depois de realmente deixá-la; caso contrário, pode haver uma situação embaraçosa quando este está em processo de deixar a sala (está empacotando seus livros etc.) e outro aluno entra antes de ele sair.

Os semáforos são muito úteis na sincronização de processos e multithreading. Temos a biblioteca de semáforo POSIX em sistemas Linux, e vamos aprender a usá-lo.

Salientamos que semáforos existem nas mais diversas linguagens que permitem programação paralela, como por exemplo Java, bem como em diferentes sistemas operacionais.

O código básico de um semáforo é simples, conforme apresentado em nosso estudo. Mas esse código não pode ser escrito diretamente, pois as funções precisam ser atômicas, e escrever o código diretamente levaria a uma troca de contexto sem a conclusão da função e resultaria em uma bagunça.

Para bloquear um semáforo ou esperar, podemos usar a função sem_wait:

int sem_wait(sem_t *sem);

Para liberar ou sinalizar um semáforo, usamos a função sem_post:

int sem_post(sem_t *sem);

Um semáforo é inicializado usando sem_init (para processos ou threads) ou sem_open (para IPC).

sem_init(sem_t *sem, int pshared, unsigned int value);

SEÇÃO CRÍTICA: TÉCNICAS DE SINCRONIZAÇÃO

Como vimos no módulo anterior, o acesso dos processos à seção crítica (segmento serializado do programa) é controlado pelo uso de técnicas de sincronização. Quando um thread começa a executar a seção crítica, o outro thread deve esperar até que o primeiro thread termine.

Se as técnicas de sincronização adequadas não forem aplicadas, isso pode causar uma condição de corrida em que os valores das variáveis podem ser imprevisíveis e variam dependendo dos tempos de alternância de contexto dos processos ou threads.

Vejamos um exemplo de código para estudar problemas de sincronização por meio de uma seção crítica:

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
pthread_t tid[2];
int counter;
pthread_mutex_t lock;
void * trythis(void* arg)
{
    pthread_mutex_lock(&lock);
    unsigned long i = 0;
    counter += 1;
    printf("\n Job %d has started\n", counter);
    for (i = 0; i < (0xFFFFFFFF); i++);
    printf("\n Job %d has finished\n", counter);
    pthread_mutex_unlock(&lock);
    return NULL;
}

int main(void)
{
    int i = 0;
    int error;

    if (pthread_mutex_init(&lock, NULL) != 0) {
        printf("\n mutex init has failed\n");
        return 1;
    }

    while (i < 2) {
        error = pthread_create(&(tid[i]), NULL, &trythis, NULL);
        if (error != 0)
            printf("\nThread can't be created :[%s]",
                strerror(error));
        i++;
    }
    pthread_join(tid[0], NULL);
    pthread_join(tid[1], NULL);
    pthread_mutex_destroy(&lock);
    return 0;
}

No código anterior, percebemos que:

Um mutex é inicializado no início da função principal.
O mesmo mutex está bloqueado na função trythis () ao usar o recurso compartilhado ‘contador’.
No final da função trythis (), o mesmo mutex é desbloqueado.
No final da função principal, quando ambas os threads estão concluídos, o mutex é destruído.

Resultado:

Job 1 started
Job 1 finished
Job 2 started
Job 2 finished

🚨 MONITOR

Para superar os erros de tempo que ocorrem ao usar o semáforo para sincronização de processos, foi introduzida uma construção de sincronização de alto nível denominada monitor. Um tipo de monitor é um tipo de dados abstrato usado para sincronização de processos.

Sendo um tipo de dados abstrato, o tipo de monitor contém as variáveis de dados que devem ser compartilhados por todos os processos e algumas operações definidas pelo programador, que permitem que os processos sejam executados em exclusão mútua dentro do monitor.

Um processo não pode acessar diretamente a variável de dados compartilhados no monitor. Ele deve acessá-lo por meio de procedimentos definidos no monitor que permitem que apenas um processo acesse as variáveis compartilhadas em um monitor por vez. Ou seja, um monitor é uma construção em que apenas um processo está ativo por vez. Se outro processo tentar acessar a variável compartilhada no monitor, ele será bloqueado e será alinhado na fila para obter o acesso.

A sintaxe do monitor é a seguinte:

monitor monitor_name
{
    //shared variable declarations
    procedure P1 ( . . . ) {
    }
    procedure P2 ( . . . ) {
    }
    procedure Pn ( . . . ) {
    }
    initialization code ( . . . ) {
    }
}

Nos monitores, há a introdução do conceito de variáveis condicionais como um mecanismo de sincronização adicional. A variável condicional permite que um processo aguarde dentro do monitor e que um processo de espera seja retomado imediatamente quando o outro libera os recursos.

Atenção: A variável condicional pode invocar apenas duas operações, wait () e signal (). Se um processo P invocar uma operação wait (), ele é suspenso no monitor até que outro processo Q invoque a operação signal (); ou seja, uma operação signal () invocada por um processo retoma o processo suspenso.

DIFERENÇA ENTRE SEMÁFORO E MONITOR

Veja no quadro abaixo algumas diferenças entre semáforo e monitor:

Semáforos	Monitores
O semáforo é uma variável inteira S que indica o número de recursos disponíveis no sistema	O monitor é o tipo de dado abstrato que permite que apenas um processo seja executado na seção crítica por vez.
O valor do semáforo pode ser modificado apenas pelas operações `wait()` e `shmget()`	Um monitor, por sua vez, possui as variáveis compartilhadas e os procedimentos apenas por meio dos quais as variáveis compartilhadas podem ser acessadas pelos processos.
No semáforo, quando um processo deseja acessar recursos compartilhados, o processo executa a operação `wait()` e bloqueia os recursos e, quando libera os recursos, executa a operação `signal()`	Em monitores, quando um processo precisa acessar recursos compartilhados, ele deve acessá-los por meio de procedimentos no monitor.

Além disso, o tipo de monitor possui variáveis de condição que o semáforo não possui.

//---------------------------------------------------------------------
// Programa em C para demonstrar como os Semaforos trabalham
//---------------------------------------------------------------------
#include <stdio.h>
#include <pthread.h>
#include <semaphore.h>
#include <unistd.h>
//---------------------------------------------------------------------
#define SemaforoLigado 1 // constante com o semáforo ligado
//---------------------------------------------------------------------
typedef struct { // estrutura de dados para identificar o estado do semáforo
    int identificador;
}thread_arg, *ptr_thread_arg;
//---------------------------------------------------------------------
sem_t mutex;    //semaforo nao-binario
//---------------------------------------------------------------------
void* thread(void* arg)
{
    //wait
    if(SemaforoLigado) sem_wait(&mutex);

    printf("\nEntrando na Regiao Critica..\n");

    ptr_thread_arg targ = (ptr_thread_arg)arg;

    printf("A - Thread:  [%d]\n", targ->identificador);

    sleep(5); //dormir 5 segundos

    printf("B - Thread:  [%d]\n", targ->identificador);
    //signal
    printf("\nSaindo da Regiao Critica...\n");

    if(SemaforoLigado) sem_post(&mutex);
}
//---------------------------------------------------------------------
int main()
{
    thread_arg argumentos[2];
    if(SemaforoLigado) sem_init(&mutex, 0, 1);        //Iniciar semaforo

    pthread_t t[2];

    argumentos[0].identificador=1;
    argumentos[1].identificador=2;

    pthread_create(&t[0],NULL,thread,&(argumentos[0])); //Criar a Thread 1
    sleep(2);                                           //dormir 2 segundos
    pthread_create(&t[1],NULL,thread,&(argumentos[1])); //Criar a Thread 2
    pthread_join(t[0],NULL);                            //Esperar por um Thread 1
    pthread_join(t[1],NULL);                            //Esperar por um Thread 2  

    if(SemaforoLigado) sem_destroy(&mutex);
    return 0;
}
//---------------------------------------------------------------------

↕️ CORROTINAS (co-rotinas)

As corrotinas são componentes de programas de computador que generalizam sub-rotinas para multitarefa não preemptiva, permitindo que a execução seja suspensa e reiniciada. Os sistemas Windows iniciais não eram preemptivos, e o uso de corrotinas permitia que se alternassem dentro dos processos em execução. O uso de corrotinas permite, por exemplo, a não utilização de mecanismos de primitivas de sincronização, como semáforos e mutex.

As corrotinas foram uma das primeiras formas de permitir a simulação de um ambiente multitarefa, em especial nos sistemas operacionais não preemptivos, sendo ainda bastante úteis e simples.

Elas também são componentes de programas de computador, onde os valores dos dados locais para uma co-rotina persistem em chamadas sucessivas e a execução de uma corrotina é suspensa quando o controle a deixa.

As sub-rotinas são casos especiais de corrotinas. Quando são chamadas, a execução começa no início e, quando uma sub-rotina for encerrada, ela é concluída. Uma instância de uma sub-rotina só retorna uma vez, e não mantém o estado entre as invocações.

As corrotinas são úteis para implementar máquinas de estado.

As corrotinas, por sua vez, podem sair chamando outras corrotinas, que podem posteriormente retornar ao ponto onde foram chamadas na corrotina original. Do seu ponto de vista, ela não está saindo, mas chamando outra corrotina. Assim, uma instância de corrotina mantém o estado e varia entre as invocações − pode haver várias instâncias de uma determinada corrotina de uma vez.

A diferença entre chamar outra corrotina por meio de "ceder" a ela e simplesmente chamar outra rotina (que então, também, voltaria ao ponto original), é que a relação entre duas corrotinas que cedem uma à outra não é a do chamador, mas simétrica.

Uma aplicação de corrotina seria na industria de videogames, onde cada ator tem seus proprios procedimentos, mas eles cedem controle ao escalonador central, que faz a execução dele sequencialmente.

Vejamos um exemplo simples de como as corrotinas podem ser úteis: Suponha que você tenha um relacionamento consumidor-produtor em que uma rotina cria itens e os adiciona a uma fila e outra remove itens da fila e os usa. Por razões de eficiência, você deseja adicionar e remover vários itens de uma vez. O código pode ser assim:

var q := new queu
coroutine produce # produtora
    loop # preenchendo/criando os elementos em uma fila
        while q is not full
            create some new items
            add the items to q
        yield to consume # Quando ela termina, ela manda para a consumidora
coroutine consume # consumidora
    loop
        while q is not empty # consumir os elementos e remover
            remove some items from q
            use the items
        yield to produce # Quando ele acabar de consumir, ele envia para a produtora
call produce

Um exemplo clássico, seria o de produtor e consumidor, onde a corrotina cria itens e os coloca em uma fila e a outra rotina remove os itens da fila para usá-los e fazer a atividade dela. Perceba que há um processo colaborativo, onde ocorre as execuções e eles ficam se avisando quando ocorre essa execução.

# -*- coding: utf-8 -*-
# Exemplo de co-rotina 
def imprimir_nome(nome):
    print("Procurando Nome:{}".format(nome))
    while True:
        texto_entrada = (yield)
        if nome in texto_entrada:
            print(nome, "foi encontrado no texto: ",texto_entrada)

# Chamando co-rotina. Nada irá acontecer.
co_rotina = imprimir_nome("teste")
# Isso iniciará a execução da co-rotina e
# Imprime a primeira linha "Procurando Nome ..."
# e avançar a execução para "yield"

co_rotina.__next__()

# Enviando entradas
co_rotina.send("teste 1")
co_rotina.send("teste 2")
co_rotina.send("este 3")

Temos um exemplo de corrotina implementada na linguagem de programação Python, diferente no programa anteriormente, esse tem uma função onde fazemos chamadas, e no resultado dela, foi achado o teste 1 e teste 2, mas não o este 3.

A fila é completamente preenchida ou esvaziada antes de ceder o controle para a outra corrotina usando o comando yield. As chamadas de corrotinas adicionais começam logo após o rendimento, no loop de corrotinas externo.

Embora, esse exemplo seja frequentemente usado como uma introdução ao multithreading, dois threads não são necessários para isso: a instrução yield pode ser implementada por um salto direto de uma rotina para a outra.

As vantagens das corrotinas sobre os threads são:

Elas podem ser usadas em um contexto de tempo real rígido (alternar entre as corrotinas não precisa envolver nenhuma chamada do sistema ou qualquer chamada de bloqueio).
Não há necessidade de primitivas de sincronização, como mutexes, semáforos etc. para proteger as seções críticas.
Não há necessidade de suporte do sistema operacional.

É possível implementar corrotinas usando encadeamentos de tarefas agendados preventivamente, de forma que seja transparente para o código de chamada, mas algumas das vantagens (particularmente a adequação para operação em tempo real e relativa economia de alternar entre eles) serão perdidas.

As corrotinas são úteis para implementar o seguinte:

MÁQUINAS DE ESTADO: Dentro de uma única sub-rotina, em que o estado é determinado pelo ponto de entrada e de saída atual do procedimento. Isso pode resultar em um código mais legível em comparação com o uso da diretiva goto, e pode ser implementado por meio de recursão mútua com chamadas finais.
MODELO DE ATOR DE SIMULTANEIDADE: Por exemplo, em videogames, cada ator tem seus próprios procedimentos (isso, novamente, separa logicamente o código), mas eles cedem de forma voluntária o controle ao escalonador central, que os executa sequencialmente (essa é uma forma de multitarefa cooperativa).
COMUNICAR PROCESSOS SEQUENCIAIS: Ocorre quando cada subprocesso é uma corrotina. As entradas/saídas do canal e as operações de bloqueio geram corrotinas, e um planejador as desbloqueia em eventos de conclusão. Alternativamente, cada subprocesso pode ser o pai daquele que o segue no pipeline de dados (ou o precede, caso em que o padrão pode ser expresso como geradores aninhados).
COMUNICAÇÃO REVERSA: Comumente usada em software matemático, no qual um procedimento como um solucionador, avaliador integral, precisa do processo de uso para fazer um cálculo, como avaliar uma equação ou integrando.

PTHREADS

Um dos conceitos mais importantes relacionados a sistemas operacionais é denominado processo. De modo geral, um processo é uma abstração de um programa em execução.

Tal programa possui um espaço de endereçamento e, em sistemas tradicionais, apenas um thread (segmento ou fluxo de controle) de execução. Além disso, o processo contém toda informação relacionada ao seu contexto de execução, por exemplo, contador de programa, apontador de pilha e demais registradores. Ou seja, é um programa com sua função principal, denominada, sendo executado sequencialmente, instrução por instrução.

No entanto, em muitos sistemas operacionais é possível criar mais de um thread no mesmo processo, isto é, no mesmo espaço de endereçamento. Nesse caso, mais de um fluxo de execução ocorre dentro do mesmo processo. Diante disso, é importante destacar algumas aplicações:

Tratar atividades que ocorrem “simultaneamente”.
Dividir a aplicação em tarefas que acessam recursos compartilhados.
Reduzir o tamanho de uma aplicação, uma vez que threads ocupam menos espaço em relação aos processos.
São mais fáceis de criar e destruir.
A sobreposição de tarefas pode acelerar a aplicação.
Possibilitam paralelismo real em sistemas multicore.

É importante destacar que threads e processos são conceitos diferentes.

Processo	Threads
Como dito anteriormente, o processo é basicamente um agrupador de recursos (código e dados) e possui uma identidade.	Os threads são criados no contexto de um processo e compartilham o mesmo espaço de endereçamento.

Em vista disso, threads não são independentes como os processos, pois, embora compartilhem o mesmo espaço de endereçamento dentro de um processo, cada thread possui os mecanismos para gerenciar seu contexto de execução. Assim, threads possuem seu próprio contador de programa, seu apontador de pilha e seus registradores.

Os threads criados ocupam a CPU do mesmo modo que o processo criador, e são escalonados pelo próprio processo. Nesse contexto, quando uma aplicação multithread é executada, esses threads podem estar em qualquer um destes estados: em execução, bloqueado (aguardando), pronto para ser executado ou concluído (finalizado), conforme ilustrado na imagem a seguir:

Para padronizar a utilização de threads em diversos sistemas, o IEEE estabeleceu o padrão POSIX threads (IEEE 1003.1c), ou Pthreads. Esse padrão define mais de 60 funções − definidas na biblioteca pthreads.h para criar e gerenciar threads.

Novo Thread: Ela é criada,

Pronto para ser executado: pronta para ser executada,

Em execução: A thread pode passar pelo escalonador para ser executada,

Aguardando: A thread pode voltar para o estado de pronto, mas também para a operação de I/O,

Pronto para ser executado: Quando a operação anterior é resolvida, ela volta para o estado de pronto e volta para o ciclo em execução. Até que ela seja finalizada.

Além disso, a biblioteca define estruturas de dados e atributos para configurar os threads. De modo geral, esses atributos são passados como argumentos para os parâmetros das funções, por exemplo:

Exemplo:

pthread_t: Handle para pthread, isto é, um valor que permite identificar o thread.

pthread_attr_t: Atributos para configuração de thread.

🔂 OPENMP

OpenMP é uma interface de programação de aplicativo (API) de memória compartilhada cujos recursos, como acabamos de ver, são baseados em esforços anteriores para facilitar a programação paralela de memória compartilhada.

O OpenMP se destina à implementação em uma ampla gama de arquiteturas SMP.

Atenção: À medida que máquinas multicore e processadores multithreading se espalham no mercado, eles podem ser cada vez mais usados para criar programas para computadores uniprocessadores.

Como seus predecessores, OpenMP não é uma nova linguagem de programação. Em vez disso, é uma notação que pode ser adicionada a um programa sequencial em C ou C++ para descrever como o trabalho deve ser compartilhado entre threads que serão executados em diferentes processadores ou núcleos e para solicitar acessos a dados compartilhados conforme necessário.

A inserção apropriada de recursos OpenMP em um programa sequencial permitirá que muitos, talvez a maioria, dos aplicativos se beneficiem de arquiteturas paralelas de memória compartilhada − geralmente com modificações mínimas no código. Na prática, muitos aplicativos têm um paralelismo considerável que pode ser explorado.

O sucesso do OpenMP pode ser atribuído a vários fatores:

Sua forte ênfase na programação paralela estruturada.
O fato de ser comparativamente simples de usar, uma vez que a responsabilidade de trabalhar os detalhes do programa paralelo é do compilador.
A grande vantagem de ser amplamente adotado, de modo que um aplicativo OpenMP pode ser executado em muitas plataformas diferentes.

Mas, acima de tudo, o OpenMP é oportuno. Com o forte crescimento na implantação de SMPs pequenos e grandes e outros hardwares multithreading, a necessidade de um padrão de programação de memória compartilhada que seja fácil de aprender e aplicar é aceita em todo o setor. Os fornecedores por trás do OpenMP entregam coletivamente grande fração dos SMPs em uso nos dias atuais. Seu envolvimento com esse padrão de fato garante sua aplicabilidade contínua às suas arquiteturas.

Prós

Código multithreading portátil (em C/C++ e outras linguagens, normalmente é necessário chamar primitivas específicas da plataforma para obter multithreading).
Não precisa lidar com a passagem de mensagens como o MPI faz.
O layout e a decomposição dos dados são controlados automaticamente por diretivas.
Escalabilidade comparável ao MPI em sistemas de memória compartilhada.
Paralelismo incremental: pode funcionar em uma parte do programa ao mesmo tempo, sendo que nenhuma mudança drástica no código é necessária.
Código unificado para aplicativos seriais e paralelos: construções OpenMP são tratadas como comentários quando compiladores sequenciais são usados.
As instruções de código original (serial) não precisam, em geral, ser modificadas quando paralelizadas com OpenMP. Isso reduz a chance de introduzir bugs inadvertidamente.
Tanto o paralelismo de granulação grossa quanto o de granulação fina são possíveis.
Em aplicações multifísicas irregulares que não aderem apenas ao modo de computação SPMD (Single Program Multiple Data), conforme encontrado em sistemas de partículas de fluido fortemente acoplados, a flexibilidade do OpenMP pode ter grande vantagem de desempenho sobre o MPI.
Pode ser usado em vários aceleradores, como GPGPU (General Purpose Graphics Processing Unit) e FPGAs (Field Programmable Gate Array).

CONTRAS

Risco de introdução de bugs de sincronização difíceis de depurar e condições de corrida.
A partir de 2017, funciona de forma eficiente somente em plataformas de multiprocessador de memória compartilhada.
Requer um compilador que suporte OpenMP.
A escalabilidade é limitada pela arquitetura da memória.
Sem suporte para comparar e trocar.
Falta um tratamento confiável de erros.
Carece de mecanismos refinados para controlar o mapeamento do processador de thread.
Alta chance de escrever código de compartilhamento falso acidentalmente.

Polling

Isaac Alves Pinheiro — Wed, 24 May 2023 20:51:23 +0000

Abordamos a arquitetura de polling anteriormente, a agora passaremos a ver mais detalhes dessa implementação.

O polling é um conceito que pode ser utilizado em diversas situações, tais como controle de acesso à rede, gerenciamento de impressora, entre outros. Seu mecanismo consiste no processo de um computador central, ou dispositivo de controle, interrogar cada estação ou recurso existente que compõe o sistema verificando sua prontidão ou estado.

Em outras palavras, polling, ou operação com polling, na ciência da computação, refere-se à amostragem ativa do status de um dispositivo externo por um programa cliente como uma atividade síncrona.

Esse sistema é mais frequentemente usado em termos de entrada/saída (E/S); também é conhecido como E/S com poll ou E/S orientada por software. A sondagem às vezes é usada como sinônimo de sondagem em espera ocupada.

Nessa situação, quando uma operação de E/S é necessária, o computador não faz nada além de verificar o status do dispositivo de E/S até que ele esteja pronto, momento em que o dispositivo é acessado. Em outras palavras, o computador espera até que o dispositivo esteja pronto.

Comentário: A sondagem também se refere à situação em que um recurso é testado continuamente quanto a sua prontidão. Caso não esteja, o computador retorna para uma tarefa diferente. Apesar de ser mais eficiente que a espera ocupada, não desperdiçando tantos ciclos de CPU, isso, geralmente, não é tão eficiente quanto a alternativa à E/S controlada por interrupção de polling, ou seja, com um dispositivo de hardware dedicado a esta tarefa.

A grande desvantagem do mecanismo de polling é que se houverem muitos dispositivos no sistema ou rede, o tempo necessário para percorrer cada um dos dispositivos e voltar ao inicial será muito alto. A consequência é que pode exceder o tempo disponível para atender ao dispositivo de E/S.

O mecanismo de polling pode ser descrito nas seguintes etapas:

Ações da estação

A estação verifica continuamente o bit de ocupado até que ele se torne livre, por exemplo, quando o bit assumir o valor 0;
Estando o bit marcado como livre, a estação escreve o comando no registro de comando. Caso o host esteja enviando dados para a saída, ele irá marcar o bit de gravação e enviar um byte de dados para o registrador de saída de dados. Caso a estação esteja recebendo dados, ela irá ler o registrado de entrada de dados e define o bit de leitura para 0 como o próximo comando;
A estação irá definir o bit de pronto para comando (command-ready) para 1.

Ações do controlador

Quando o controlador verificar que o bit command-ready está definido, ele configura o bit ocupado como 1.
O controlador irá ler o registro de comando. Caso o bit de gravação interno estiver definido, ele lê os dados do registrador de saída e executa as operações de E/S necessárias no dispositivo. Caso o bit de leitura esteja definido, os dados do dispositivo serão carregados no registro de entrada de dados para que a estação possa ler.
Quando terminarem as operações, o controlador libera o bit command-ready, limpa o bit de erro para mostrar que a operação foi bem-sucedida e libera o bit ocupado.

O ciclo de polling pode ser definido como o tempo que leva para, após ter sido consultado em dado momento, o ciclo receba uma nova consulta. O tempo ideal para cada ciclo depende de vários aspectos, tais como, retardo esperado para cada componente responder e a sobrecarga, por exemplo, tempo do processador e largura de banda da pesquisa.

Na votação nominal (roll call polling), o controlador irá consultar cada recurso em uma lista em uma sequência fixa. Neste tipo de polling, é necessário que seja configurado um mecanismo de temporização para aguardar a resposta de cada recurso que foi consultado, evitando travamentos do sistema caso ele não responda. Esse tipo de votação pode ser ineficiente caso haja muitos elementos a serem consultados, sendo poucos ativos e, também, caso a sobrecarga para as mensagens de consulta seja alta.

No hub polling, ou token polling, cada recurso pesquisa pelo próximo recurso em uma determinada sequência fixa, até que o primeiro recurso dessa sequência seja alcançado. E quando isso ocorre, o ciclo de polling começa novamente.

Atenção: O mecanismo de polling é empregado em diversas situações na área de computação, principalmente para controlar a execução ou a sequência de transmissão dos elementos envolvidos.

Por exemplo, em sistemas operacionais multitarefa, pode ser utilizado para que vários processos concorrentes possam disputar o uso do processador ou de dispositivos de E/S.

Outro exemplo seria na área de redes, quando o canal de comunicação é compartilhado entre diversos dispositivos. Para que não ocorra colisão, é necessário que seja empregado um mecanismo de controle de acesso ao meio, dentre eles o polling. Uma estação mestre irá interrogar as estações escravas para que possam transmitir as informações por meio do canal.

Master-Slave

Isaac Alves Pinheiro — Wed, 24 May 2023 20:38:10 +0000

Embora o nome sugira certa semelhança com o modelo de cliente-servidor, na arquitetura mestre-escravo, as funções se invertem.

Mestre-escravo (master-slave) é um modelo de comunicação ou controle assimétrico onde um dispositivo ou processo (o "mestre") controla um ou mais outros dispositivos ou processos (os "escravos") e serve como seu hub de comunicação.

Em alguns sistemas, um mestre é selecionado a partir de um grupo de dispositivos elegíveis, com os outros dispositivos atuando na função de escravos.

O processo de comunicação de um mestre com um escravo é denominado transação. Existem dois tipos:

Pergunta-Resposta: O mestre inicia uma transação com um de seus escravos. Todos os escravos o ouvem, mas apenas aquele a quem a comunicação é dirigida responde. A transação pode envolver a troca de várias mensagens.
Disseminação sem Resposta: O mestre inicia uma transação para todos os escravos. Nenhum escravo responde explicitamente e o mestre presume que eles terminarão suas execuções em algum ponto. Pode ser que um ou mais escravos não recebam as informações corretamente e isso deve ser levado em consideração ao utilizar esse tipo de transação.

Em uma transação mestre-escravo, certos parâmetros são definidos para organizá-los e garanti-los, entre eles:

Protocolo: Para que dois componentes que estão trocando informações sejam compreendidos, é necessário que haja acordo sobre o conteúdo das informações trocadas. O conjunto de regras e convenções que governam a comunicação é chamado de protocolo.
Polling: O componente mestre interroga sob um esquema programado a sequência de escravos disponíveis; cada escravo pode receber diferentes tipos de transações correspondentes a uma ou mais tarefas.
Tempo esgotado (Timeout): Quando o mestre inicia a transação com um determinado escravo dentro do esquema de consulta-resposta, pode acontecer que o escravo seja incapaz de responder ao mestre. Portanto, o mestre deve lidar com um tempo limite para a resposta do escravo e, se não houver resposta, abortar a transação para tentar novamente ou para continuar com seu esquema de polling.
Novas tentativas: Quando um escravo não responde e o mestre aborta a transação, ele deve decidir o que fazer: continuar com o esquema de polling ou tentar novamente a transação abortada. O número de vezes que uma transação será repetida é chamado de novas tentativas.

Dentro desses modelos, há ainda algumas variações. No projeto de um sistema com arquitetura mestre-escravo, uma das decisões mais relevantes afeta a distribuição de responsabilidades, o que se denomina granularidade.

Granularidade é a forma como o trabalho a ser executado é decomposto, ou seja, a carga computacional ou o tamanho das tarefas atribuídas aos escravos.

Dois tipos são distinguidos:

Granularidade fina: Consiste em distribuir o trabalho em muitas pequenas tarefas. Isso tem a vantagem de que, se um escravo morrer, o mestre atribui a tarefa a outro escravo, com uma penalidade de tempo muito pequena. Como desvantagem, você precisa de um número maior de escravos para realizar a tarefas específica;
Granularidade grossa: Consiste em distribuir o trabalho em algumas tarefas grandes. Como vantagem, é apresentado que não serão necessários muitos escravos para realizar uma tarefa. Por outro lado, se um escravo morrer, a penalidade de tempo será significativa.

A implantação de um sistema com arquitetura mestre-escravo também permite a aplicação de diversas variantes dependendo da utilização de um ou mais mestres.

São elas:

Mestre-escravo simples: Estrutura clássica em que existe um único mestre que realiza a distribuição das tarefas entre os componentes escravos que as executam. Também pode ser responsável pelo gerenciamento dos próprios escravos (inicialização e parada, criação de mais instâncias em resposta ao aumento de solicitações ou carga do sistema, prisão de escravos ociosos ou com comportamentos anômalos etc.).
Mestre-escravo multinível: Estrutura profunda na qual, ao invés de ter um único mestre supervisionando todos os escravos, um ou mais níveis de mestres são introduzidos para esse fim. Esses níveis de mestres então agrupam a supervisão de escravos ou outros mestres, de forma a conter o número de componentes supervisionados por cada componente de supervisão. Esta variante é comum em sistemas com grande número de escravos para evitar problemas de desempenho, ou seja, o mestre fica saturado com alta frequência de comunicações de escravos e para os escravos.
Master sobressalente: Estrutura que inclui um ou mais master sobressalentes, com o objetivo de aumentar a disponibilidade. Esta variante apresenta vários mestres secundários para que o esquema geral da arquitetura seja mantido. Se, durante a operação usual de monitoramento e controle o mestre morre, ele é imediatamente substituído por outro (usando pontos de verificação), minimizando o tempo em que o sistema deixa de estar operacional.
Mestre com redundância passiva: Estrutura que inclui um ou mais masters sobressalentes, com o objetivo de aumentar a disponibilidade. Esta variante, como no caso anterior, introduziria um novo mestre, que seria constantemente atualizado em relação aos dados do mestre principal. Assim, se durante a operação usual de supervisão e controle o mestre morrer, ele é imediatamente substituído por outro que já está pronto para funcionar, reduzindo praticamente a zero o tempo em que o sistema deixa de estar operacional.

Vantagens do Master-Slave

Entre as vantagens da arquitetura mestre-escravo está a alta tolerância a erros. Isso significa que caso um escravo morra, dificilmente o sistema será afetado e poderá continuar operando sem problemas. A tarefa incompleta pode ser atribuída a outro escravo pelo mestre, e o escravo com falha pode ser reiniciado ou substituído. Por outro lado, no caso de falecimento do mestre (que é o caso que mais afeta o sistema, pois envolve uma penalidade maior ou até mesmo faz com que pare totalmente) pode ser resolvido aplicando algumas das variantes que proporcionam um substituto para o mestre.

Desvantagens do Master-Slave

Entre as desvantagens mais problemáticas está a necessidade de independência das tarefas a serem desempenhadas pelo sistema, de forma a distribuí-las entre os escravos. Além disso, tal distribuição deve fazer uso inteligente das capacidades dos escravos, para maximizar o desempenho geral do sistema.

Assim, se uma arquitetura com muitos escravos e um único mestre for implantada, onde há muitas comunicações entre ela e estes, o mestre pode sofrer problemas de saturação, sendo o principal componente do sistema, isso resultaria em uma redução direta no desempenho. A saturação (ou baixo desempenho) do mestre é tanto mais provável quanto mais responsabilidades lhe forem atribuídas, portanto um sistema em que o mestre, além de distribuir tarefas entre os escravos, é responsável por processar os dados por eles retornados, fazendo algum tipo de computação global com esses dados, aumenta o risco de oferecer uma latência maior do que a esperada.

Em termos gerais, a arquitetura mestre-escravo é adequada para a construção de sistemas de tempo real, que precisam garantir o tempo de resposta. Também é frequentemente encontrado em sistemas embarcados, que podem ser construídos combinando arquitetura de repositório ou arquitetura de pipeline com mestre-escravo.

Comentário: Essa arquitetura, às vezes, é usada para estruturar a parte dos sistemas que lida com a replicação de informações; portanto, na replicação do banco de dados, o banco de dados mestre é considerado a fonte autorizada, e os bancos de dados escravos são sincronizados com ele.

Além de organizar a relação entre componentes de software de sistemas computacionais, a organização mestre-escravo está presente nas camadas mais baixas dos níveis de rede, bem como nas caraterísticas de arquitetura de computadores.

Os periféricos conectados a um barramento em equipamentos de informática geralmente funcionam como escravos de um mestre (controlador). Os discos rígidos que usam ATA em paralelo também são organizados em um esquema mestre-escravo.

ATA - Acrônimo de Advanced Technology Attachment é uma tecnologia surgida nos anos 80, trazendo o inovador recurso de funcionamento do disco rígido com o driver (controlador) integrado, tendo o objetivo de homogeneizar os tipos de conectores do disco rígido à placa mãe e à fonte de energia.

Os clusters de computadores fazem uso dessa arquitetura, assim como ferramentas como o Jenkins que utiliza essa arquitetura para realizar seu build da instância master para as instâncias slaves.

Client-Server model

Isaac Alves Pinheiro — Wed, 24 May 2023 20:19:59 +0000

O modelo cliente-servidor (em inglês client-server model), em computação, é uma estrutura/arquitetura de aplicação distribuída que distribui as tarefas e cargas de trabalho entre os fornecedores/provedores de um recurso e/ou serviço, designados como servidores, e os solicitantes/requerentes dos serviços, designados como clientes.

Um servidor é um dispositivo ou computador ou programa dedicado à prestação de serviços para outros programas, chamados de "clientes". Ou seja, um servidor é uma máquina centralizada que oferece serviços a um cliente que é o computador do usuário, assim como o seu. É utilizado pelas pessoas para acessar sites ou sistemas a partir de um endereço no navegador (Google Chrome, Internet Explorer, Safari, Mozilla Firefox e etc).

Depois da etapa de UI/UX Design, vem a etapa de codificação. Na parte de codificação no modelo cliente-servidor, você consegue discernir quem é o requerente e o provedor, o aplicativo mobile do banco de seu celular é o requerente. E a forma como o requerente irá acessar e solicitar as informações dele no sistema, é necessário o provedor. Então, perceba que eles tem funções distintas, assim como também pode haver linguagens de programação distintas ou não.

O modelo cliente-servidor é a arquitetura mais frequentemente citada na literatura de sistemas distribuídos. Historicamente, é a mais importante e continua sendo a mais amplamente utilizada. A figura a seguir ilustra a estrutura simples na qual os processos assumem as funções de clientes ou servidores. Em particular, os processos do cliente interagem com os processos individuais do servidor em computadores host potencialmente separados para acessar os recursos compartilhados que eles gerenciam.

Geralmente os clientes e servidores comunicam através de uma rede de computadores em computadores distintos, mas tanto o cliente quanto o servidor podem residir no mesmo computador.

Um servidor é um host que está executando um ou mais serviços ou programas que compartilham recursos com os clientes. Um cliente não compartilha qualquer de seus recursos, mas solicita um conteúdo ou função do servidor. Os clientes iniciam sessões de comunicação com os servidores que aguardam requisições de entrada.

Frequentemente, clientes e servidores se comunicam em uma rede de computadores em hardware separado, mas tanto o cliente quanto o servidor podem residir no mesmo sistema. Um host de servidor executa um ou mais programas de servidor, que compartilham seus recursos com os clientes.

Um cliente, geralmente, não compartilha nenhum de seus recursos, mas solicita conteúdo ou serviço de um servidor. Os clientes, portanto, iniciam sessões de comunicação com os servidores, que aguardam solicitações de entrada.

O modelo cliente-servidor foi desenvolvido na Xerox PARC durante os anos 70. Este modelo é actualmente o predominante nas redes informáticas. Email, a World Wide Web e redes de impressão são exemplos comuns deste modelo.

A arquitetura cliente-servidor descreve o relacionamento de programas cooperativos em um aplicativo. O componente do servidor fornece uma função ou serviço a um ou mais clientes, que iniciam solicitações para esses serviços. Nesse sentido, os servidores são classificados pelos serviços que fornecem.

Os tipos de servidores dessa arquitetura incluem:

Servidor de Aplicação (Middleware)
Servidor DNS
Servidor Web (Web Server)
Servidor de Fax
Servidor de arquivos
Servidor de email
Servidor FTP
Servidor de imagens

A arquitetura de um sistema de software é uma metáfora, análoga à arquitetura de um edifício. Funciona como um blueprint do sistema e do projeto em desenvolvimento, que a gerência do projeto pode utilizar posteriormente para extrapolar as tarefas necessárias a serem executadas pelas equipes e pessoas envolvidas.

A arquitetura de software trata de fazer escolhas estruturais fundamentais que custam caro mudar uma vez implementadas. As opções de arquitetura de software incluem opções estruturais específicas de possibilidades no design do software.

Exemplo: Um servidor web atende páginas web e um servidor de arquivos atende arquivos de computador.

Um recurso compartilhado pode ser qualquer software e componentes eletrônicos do computador servidor, desde programas e dados até processadores e dispositivos de armazenamento. O compartilhamento de recursos de um servidor constitui um serviço.

Se um computador é um cliente, um servidor ou ambos, é determinado pela natureza do aplicativo que requer as funções de serviço.

Exemplo: Um único computador pode executar um servidor web e um software servidor de arquivos ao mesmo tempo para servir dados diferentes a clientes que fazem diferentes tipos de solicitações. O software cliente também pode se comunicar com o software servidor no mesmo computador.

Em geral, um serviço é uma abstração de recursos do computador, e um cliente não precisa se preocupar, em tese, com o desempenho do servidor enquanto atende a solicitação e entrega a resposta. O cliente só precisa entender a resposta com base no protocolo de aplicativo bem conhecido, ou seja, o conteúdo e a formatação dos dados para o serviço solicitado.

Clientes e servidores trocam mensagens em um padrão de mensagem de solicitação-resposta. O cliente envia uma solicitação e o servidor retorna uma resposta. Essa troca de mensagens é um exemplo de comunicação entre processos. Para se comunicar, os computadores devem ter uma linguagem comum e devem seguir regras para que o cliente e o servidor saibam o que esperar.

O idioma e as regras de comunicação são definidos em um protocolo de comunicação, sendo que estes protocolos operam na camada de aplicativo. O protocolo da camada de aplicação define os padrões básicos do diálogo.

Para formalizar ainda mais a troca de dados, o servidor pode implementar uma interface de programação de aplicativos (Application Program Interface – API).

A API é uma camada de abstração para acessar um serviço:

Ao restringir a comunicação a um formato de conteúdo específico, facilita a análise.
Ao abstrair o acesso, facilita a troca de dados entre plataformas.

Um servidor pode receber solicitações de muitos clientes distintos em um curto período. Um computador só pode realizar um número limitado de tarefas a qualquer momento e conta com um sistema de agendamento para priorizar as solicitações de entrada dos clientes para acomodá-las.

Para evitar sobrecarga e maximizar a disponibilidade, o software do servidor pode limitar a disponibilidade para os clientes. Aproveitando a eventual possibilidade de sobrecarga, podem ser feitos ataques de negação de serviço que são projetados para explorar a obrigação de um servidor de processar solicitações, sobrecarregando-o com taxas de solicitação excessivas.

Atenção: Caso a segurança seja um fator importante, técnicas de criptografia podem ser aplicadas se as informações confidenciais forem comunicadas entre o cliente e o servidor.

Quando um correntista de banco acessa serviços de banco on-line com um navegador da web (o cliente), este inicia uma solicitação ao servidor de web do banco.

As credenciais de login do correntista podem ser armazenadas em um banco de dados e o servidor da web acessa o servidor de banco de dados como um cliente. Um servidor de aplicativos (Middleware) interpreta os dados retornados aplicando a lógica de negócios do banco e fornece a saída para o servidor da web. Finalmente, o servidor da web retorna o resultado ao navegador da web do correntista para exibição.

Por exemplo, os sistemas que controlavam o veículo de lançamento do ônibus espacial tinham o requisito de serem muito rápidos e muito confiáveis. Portanto, uma linguagem de computação de tempo real (RTC) apropriada precisaria ser escolhida. Além disso, para satisfazer a necessidade de confiabilidade, pode-se optar por ter várias cópias redundantes e produzidas independentemente do programa e executar essas cópias em hardware independente enquanto verifica os resultados.

A documentação da arquitetura de software facilita a comunicação entre as partes interessadas , captura decisões iniciais sobre o design de alto nível e permite a reutilização de componentes de design entre projetos.

A característica do modelo cliente-servidor, descreve a relação de programas numa aplicação. O componente de servidor fornece uma função ou serviço a um ou mais clientes, que iniciam os pedidos de serviço.

Servidor DNS

Quando os usuários digitam nomes de domínio na barra de URL do navegador, os servidores de DNS são responsáveis pela tradução desses nomes de domínio em endereços de IP numéricos, levando-os ao site correto. O Domain Name System (DNS) é a lista telefônica da Internet. Quando os usuários digitam nomes de domínio como 'google.com' ou 'nytimes.com' nos navegadores da web, o DNS é responsável por encontrar o endereço de IP correto para esses sites. Os navegadores então usam esses endereços para se comunicar com os servidores de origem ou com os servidores de borda da CDN para acessar as informações do site. Tudo isso acontece graças aos servidores de DNS: máquinas dedicadas para responder às solicitações ao DNS.

Os clientes DNS, que são integrados à maioria dos sistemas operacionais modernos dos desktops e de dispositivos móveis, permitem que os navegadores web interajam com os servidores de DNS. Para obter mais informações, veja O Modelo Cliente-Servidor.

Web Server (Servidor web)

Um "Servidor web (web server)" pode referir ao hardware ou ao software, ou ambos trabalhando juntos.

As funcionalidades como a troca de e-mail, acesso à internet ou acesso a um banco de dados, são construídos com base no modelo cliente-servidor. Por exemplo, um navegador web é um programa cliente, em execução no computador do usuário, que acede às informações armazenadas num servidor web (Web Server) na internet, onde seu objetivo é ouvir uma porta para responder requisições HTTP. Usuários de serviços bancários, acedendo do seu computador, usam um cliente web para enviar uma solicitação para um servidor web num banco. Esse programa pode, por sua vez, encaminhar o pedido para o seu próprio programa de banco de dados do cliente que envia uma solicitação para um servidor de banco de dados noutro computador do banco para recuperar as informações da conta. O saldo é devolvido ao cliente de banco de dados do banco, que por sua vez, serve de volta ao cliente navegador exibindo os resultados para o usuário.

Mas como o servidor web (Web Server) e o computador sabem o que significa "localhost"? Através do arquivo de hosts. Então, todo sistema operacional possui um arquivo de hosts. No Linux, por padrão fica em /etc/hosts. No Mac, /private/etc/hosts. Já no Windows, C:\Windows\System32\Drivers\Etc\hosts. Esse arquivo informa ao sistema operacional que quando uma conexão for estabelecida usando algum nome, o IP correspondente deve ser usado. Para o nome localhost, temos o IP da nossa própria máquina (127.0.0.1).

São exemplos de servidores web HTTP, junto com suas características abaixo:

Apache (desenvolvimento/produção): O Servidor HTTP Apache ou Servidor Apache ou HTTP Daemon Apache ou somente Apache, é o servidor web livre criado em 1995 por um grupo de desenvolvedores da NCSA, tendo como base o servidor web NCSA HTTPd criado por Rob McCool. O Apache é um software de servidor da Web de código aberto usado para fornecer páginas da Web aos usuários. É um dos servidores da Web mais populares do mundo e é usado por muitos dos maiores sites. O Apache também é usado como um servidor de aplicativos, permitindo que os desenvolvedores criem e implantem aplicativos na web;
Nginx (desenvolvimento/produção): Nginx é um servidor leve de HTTP, proxy reverso, proxy de e-mail IMAP/POP3, feito por Igor Sysoev em 2005, sob licença BSD-like 2-clause. O Nginx consome menos memória que o Apache, pois lida com requisições Web do tipo “event-based web server”; e o Apache é baseado no “process-based server”, podendo trabalhar juntos;
IIS Express (desenvolvimento): O IIS - Serviços de informação para internet (Internet Information Services) é um servidor web incluso no Visual Studio que permite você aproveitar ao máximo todos os recursos do servidor da Web (SSL, regras de regravação de URL, etc.). O IIS é um servidor web completo – o que significa que você terá uma experiência mais próxima de como funcionará quando implantar o aplicativo em um servidor de produção. O IIS Express é usado apenas para fins de desenvolvimento e teste e não tem suporte para uso em um ambiente de produção como um servidor Web de produção.
Lighttpd (desenvolvimento/produção): é um servidor web projetado para otimizar ambientes de alta performance. A utilização de memória é baixa se comparada a outros servidores web, possui um bom gerenciamento de carga da UCP e opções avançadas como CGI, FastCGI, SCGI, SSL, reescrita de URL, entre outras. Ele é projetado em um modelo assíncrono para lidar com solicitações e funciona em um único thread. Se você não deseja carregar os recursos do sistema, essa é a melhor opção para você. O Lighttpd é capaz de lidar com algumas centenas de solicitações por segundo.
Gunicorn (desenvolvimento/produção): O Gunicorn "Green Unicorn" é um servidor HTTP Python Web Server Gateway Interface. É um modelo de trabalhador pré-fork, portado do projeto Unicorn de Ruby. O servidor Gunicorn é amplamente compatível com vários frameworks da web, implementado de forma simples, leve nos recursos do servidor e bastante rápido. O Gunicorn é, acima de tudo, um servidor de aplicativos Python WSGI e testado em batalha: é rápido, otimizado e projetado para produção. Ele oferece um controle mais refinado sobre o próprio servidor de aplicativos;
Puma (desenvolvimento/produção): Puma é um servidor web HTTP derivado de Mongrel e escrito por Evan Phoenix. Ele enfatiza a velocidade e o uso eficiente da memória. Ele é ideal para aplicações Rails em produção;
Apache Tomcat (desenvolvimento/produção): O Tomcat é um servidor web Java, mais especificamente, um container de servlets. O Tomcat implementa, dentre outras de menor relevância, as tecnologias Java Servlet e JavaServer Pages e não é um container Enterprise JavaBeans. Desenvolvido pela Apache Software Foundation, é distribuído como software livre.
Glassfish (desenvolvimento): GlassFish é um servidor de aplicação open source liderado pela Sun Microsystems para a plataforma Java EE. Sua versão proprietária é chamada Sun GlassFish Enterprise Server. GlassFish suporta todas as especificações da API Java EE, tais como JDBC, RMI, JavaMail, JMS, JMX etc. e define como coordená-las. GlassFish também suporta algumas especificações para componentes Java EE, como Enterprise JavaBeans, conectore, servlets, portlets, JSF e diversas tecnologias de web services. Isto permite que desenvolvedores criem aplicações corporativas portáveis, escaláveis e fáceis de integrar com código legado.

A base de GlassFish é o código-fonte liberado pela Sun e o sistema de persistência TopLink da Oracle. Ele utiliza uma variante do Apache Tomcat como container de servlets, com um componente adicional chamado Grizzly que utiliza nio para maior escalabilidade e eficiência.

Caddy (desenvolvimento/produção): é um servidor HTTP de código aberto pronto para produção, mais produtivo, fácil de usar e rápido com HTTPS ativado por padrão. Foi lançado em 2015 e oferece suporte a uma variedade de tecnologias de sites. O Caddy é semelhante ao NGINX em sintaxe e em muitas outras coisas, mas é extremamente simplificado. Let's Encrypt (uma autoridade certificadora sem fins lucrativos que fornece certificados TLS) A integração SSL pode ser concluída usando três linhas de configuração.

O modelo cliente-servidor, tornou-se uma das ideias centrais de computação de rede. Muitos aplicativos de negócios, escritos hoje, utilizam o modelo cliente-servidor. O termo também tem sido utilizado para distinguir a computação distribuída por computadores dispersos da "computação" monolítica centralizada em mainframe.

Mainframe é um computador de grande porte dedicado normalmente ao processamento de um volume enorme de informações. O termo mainframe era utilizado para se referir ao gabinete principal que alojava a CPU (unidade central de processamento) nos primeiros computadores.

Cada instância de software do cliente pode enviar requisições a vários servidores (sendo clusters ou não). Por sua vez, os servidores podem aceitar esses pedidos, processá-los e retornar as informações solicitadas para o cliente. Embora este conceito possa ser aplicado por uma variedade de razões e para diversos tipos de aplicações, a arquitetura permanece fundamentalmente a mesma.

Curiosidade: Nesse tipo de arquitetura que surgiu o Desenvolvimento Web com as terminologias de Front-End (Lado do Cliente) e Back-End (Lado do Servidor). Onde o front-end se trata de toda a interface que o usuário interage com a Web com arquivos estáticos e o Back-end se trata do seu consumo e interação com as aplicações de servidores localizados na internet.

Temos aqui o cliente e o servidor, então imagine que o cliente é um navegador web (browser); e nós temos um servidor rodando, uma aplicação em Java, em PHP, C-Sharp (C#) - .NET, Python, Ruby ou a linguagem que for.

Então, o cliente vai digitar a URL do nosso site: “site.com.br”, por exemplo, e ele vai fazer uma requisição, utilizando o protocolo HTTP, para o computador que tem o nome “site.com.br”. Esse computador precisa saber/receber essa requisição (request) web e fazer uma resposta (response) que pode ser: exibir o HTML, a imagem, devolver o arquivo CSS - ou então mandar para uma aplicação processar essa requisição, uma aplicação em Java, em PHP, em Python ou no que for. Essa tarefa de receber a requisição e decidir o que vai fazer para enviar uma resposta, se vai mandar para uma aplicação, se vai devolver algum arquivo direto - essa é a tarefa de um servidor web (Web Server), e que ele vai fazer dentro de um servidor é ficar ouvindo a porta (Listener).

O papel de um servidor web é ouvir conexões TCP em alguma porta configurada. Um servidor web vai ficar esperando uma conexão chegar. Quando ela chegar, o servidor web faz seu trabalho, garantindo que a mensagem recebida está no formato HTTP e depois fazendo o que deve fazer segundo suas configurações.

Quando falamos de HTTP, a porta padrão é a 80. Então, se você não digita uma porta e está utilizando HTTP, essa requisição vai cair na porta 80. Então um servidor web fica lá ouvindo, por exemplo, a porta 80 e ele fica esperando alguma requisição ou algum pedido entrar para chegar nesse computador.

Caching (Cacheamento)

Na área da computação, cache é um dispositivo de acesso rápido, interno a um sistema, que serve de intermediário entre um operador de um processo e o dispositivo de armazenamento ao qual esse operador acede.

Portanto, o caching é uma técnica de armazenamento intermediário de dados da aplicação, que podem ser feitos através de hardware ou software. Ela serve para prover um acesso mais rápido a determinadas informações do que acessar diretamente a base de dados da aplicação.

Uma das maiores causas da má performance em aplicações Web é a falta de cache. Nem todas as requests precisam gastar recursos computacionais do seu servidor para executarem alguma coisa. Grande parte das requisições que fazemos podem ocupar um total de 0 recursos computacionais usando técnicas de caching.

Existem diversas formas de se fazer cache, a mais comum delas é utilizar o próprio servidor de proxy, como o Nginx ou o Apache para poder tratar e verificar se aquela requisição já foi feita no passado e evitar que ela sequer chegue no servidor da sua aplicação, já retornando o valor computado.

Em outros casos, quando precisamos de uma requisição mais complexa, a gente pode usar bancos de dados chave-valor, como o Redis, para poder armazenar os resultados das nossas requisições e retornar uma resposta o mais rápido possível, utilizando o mínimo do nosso servidor.

A grande maioria das empresas, principalmente as que lidam com dados que não se alteram tanto, usam caches para poder servir as páginas da forma mais rápida possível, ou você acha que o Twitter vai recalcular toda a sua linha do tempo todas as vezes?

Middleware (Servidor de Aplicação)

Quando chega, esse servidor web tem que saber o que fazer, ou seja, ele vai analisar e se o que você está pedindo parece ser um arquivo de imagem, então não preciso fazer nada com mais ninguém. Eu só vou te devolver essa imagem e o navegador vai exibir para você. Se você está me pedindo um arquivo estático, um arquivo de CSS? Então só vou te devolver, não preciso envolver ninguém nesse processo. Agora, o que você está me pedindo aqui parece ser uma rota, uma URL, que precisa ser executada por uma aplicação, em PHP, Python ou Java, então o que ele faz é poder transferir a responsabilidade para algum servidor de aplicação, também conhecido como middleware, cujo é um servidor que disponibiliza um ambiente para a instalação e execução de aplicações de informática, centralizando e dispensando a instalação em computadores clientes. Esse servidor de aplicação pode estar, por exemplo, aberto ouvindo uma outra porta.

Middleware é um software que permite um ou mais tipos de comunicação ou conectividade entre dois ou mais aplicativos e/ou componentes de aplicativos em uma rede distribuída. Ao tornar mais fácil conectar aplicativos que não foram projetados para se conectar uns aos outros — e fornecer funcionalidade para conectá-los de maneiras inteligentes — o middleware otimiza o desenvolvimento de aplicativos e acelera o tempo de lançamento no mercado.

E esse servidor web manda uma outra requisição (não utilizando o protocolo HTTP, necessariamente, pode ser usando outro formato), mas ele manda esse pedido para o servidor de aplicação. O servidor de aplicação processa, devolve para o servidor web, e o servidor web vai devolver para o cliente o que ele recebeu. Essa comunicação entre um servidor web e um servidor de aplicação pode ser feita de diversas formas. Então vamos focar, pelo menos no início, só nessa tarefa individual do servidor web tratando o que ele tem que tratar, de forma isolada.

Após vários modelos estudados de cliente-servidor caracterizou-se chamar tecnicamente de arquitetura multicamada, inspirado nas camadas no Modelo OSI, o processo de dividir a arquitetura de cliente-servidor em várias camadas lógicas (logic layers) facilitando o processo de programação distribuída, existe desde o modelo mais simples de duas camadas, e o mais utilizado atualmente que é o modelo de três camadas que é paralelo ao modelo de arquitetura de software denominado MVC (Model-view-controller), onde a troca de mensagens entre o cliente e o servidor é feita através de uma chamada de API: REST, SOAP ou RPC.

O resumo a seguir mostra a sequência de ações tanto do lado do cliente como do lado do servidor.

Características do Cliente

Inicia pedidos/solicitações para servidores;
Espera/aguarda por respostas;
Recebe respostas;
Conecta-se a um pequeno/reduzido número de servidores por vez;
Normalmente/usualmente, interage diretamente com os servidores através/por meio de seu software de aplicação específico para a tarefa de estabelecer/possibilitar a comunicação entre cliente e servidor;
Utiliza recursos da rede.

Características do Servidor

Sempre aguarda/espera por um pedido/solicitação de um cliente;
Atende os pedidos/solicitações e, em seguida, responde aos clientes com os dados solicitados/requisitados;
Podem se conectar com outros servidores para atender uma solicitação específica do cliente; jamais podem se comunicar.
Fornece recursos adicionais de rede, além da infraestrutura de rede propriamente dita.
Normalmente interage por meio de interfaces diretamente com os usuários finais através de qualquer interface com o usuário;
Estrutura o sistema.

Vantagens do modelo Cliente-Servidor

Na maioria dos casos, a arquitetura cliente-servidor permite que os papéis e responsabilidades de um sistema de computação possam ser distribuídos entre vários computadores independentes que são conhecidos por si só através de uma rede. Isso cria uma vantagem adicional para essa arquitetura: maior facilidade de manutenção. Por exemplo, é possível substituir, reparar, atualizar ou mesmo realocar um servidor de seus clientes, enquanto continuam a ser a consciência e não afetado por essa mudança. A arquitetura cliente-servidor permite que as responsabilidades de um sistema de computação possam ser distribuídas entre vários computadores independentes interconectados por meio de uma rede, o que resulta em maior facilidade de manutenção;
Todos os dados são armazenados nos servidores, que geralmente possuem controles de segurança muito maiores do que a maioria dos clientes. Os servidores podem controlar melhor o acesso a recursos, para garantir que apenas os clientes com credenciais válidas possam aceder e alterar os dados;
Como o armazenamento de dados é centralizado, as atualizações dos dados são muito mais fáceis de administrar em comparação com o paradigma P2P. Em uma arquitetura P2P, atualizações de dados podem precisar ser distribuídas e aplicadas a cada nó na rede, o que consome tempo e é passível de erro, já que pode haver milhares ou mesmo milhões de nós. O gerenciamento das atualizações dos dados é mais fácil de ser feita nesse modelo do que no paradigma peer-to-peer (P2P), onde as atualizações de dados podem necessitar ser distribuídas e aplicadas a cada nó na rede, o que consome tempo e torna-se passível de erro;
Muitas tecnologias avançadas de cliente-servidor estão disponíveis e foram projetadas para garantir a segurança, facilidade de interface do usuário e facilidade de uso;
Os dados principais são armazenados nos servidores, que por regra possuem controles de segurança mais robustos do que o da maioria dos clientes.
Muitas tecnologias avançadas de cliente-servidor foram projetadas para garantir a segurança, facilidade de interface do usuário e facilidade de uso encontram-se disponíveis.
Funciona com vários clientes diferentes, sendo que os clientes podem ter capacidades diferentes.

Entretanto, o modelo apresenta diversos problemas. Visto que a capacidade de oferecer serviços ou recursos fica centralizada na figura do servidor, surge um problema:

O que fazer quando o número de requisições dos clientes ultrapassa a capacidade computacional do servidor?

Essa pergunta não tem uma resposta de alta eficiência para aplicações em redes de computadores. A sobrecarga de servidores é um problema real apesar de a capacidade computacional dos servidores crescer consideravelmente ano após ano.

Além do fato de algumas requisições não serem atendidas, pela sobrecarga do servidor, no modelo cliente-servidor, ainda há o fato de que o modelo não é robusto, ou seja, se um servidor crítico falha, as requisições já feitas pelos clientes não poderão ser atendidas.

Esses motivos são a base para a concepção das redes peer-to-peer (P2P).

Desvantagens do modelo Cliente-Servidor

Clientes podem solicitar serviços, mas não podem oferecê-los para outros clientes, sobrecarregando o servidor, pois quanto mais clientes, mais informações que irão demandar mais banda.
Um servidor poderá ficar sobrecarregado caso receba mais solicitações simultâneas dos clientes do que pode suportar;
Este modelo não possui a robustez de uma rede baseada em P2P. Na arquitetura cliente-servidor, se um servidor crítico falha, os pedidos dos clientes não poderão ser cumpridos. Já no P2P, os recursos são normalmente distribuídos entre vários nós. Mesmo se uma ou mais máquinas falharem no momento de download de um arquivo, por exemplo, as demais ainda terão os dados necessários para completar a referida operação.

Protocolos de transporte e aplicações de rede

Os protocolos do nível de transporte fornecem serviços que garantem uma transferência confiável de dados e aplicativos entre computadores (ou outros equipamentos) remotos. Os programas na camada de aplicação usam os protocolos de transporte para contactar outras aplicações. Para isso, a aplicação interage com o software do protocolo antes de ser feito o contacto. A aplicação que aguarda a conexão informa ao software do protocolo local que está pronta a aceitar mensagem. A aplicação que estabelece a conexão usa os protocolos de transporte e rede para contactar o sistema que aguarda. As mensagens entre as duas aplicações são trocadas através da conexão resultante.

Existem duas formas para que se estabeleça uma ligação cliente-servidor: enquanto uma delas é orientada à conexão, a outra não é. O TCP, por exemplo, é um protocolo de transporte orientado à conexão em que o cliente estabelece uma conexão com o servidor e ambos trocam múltiplas mensagens de tamanhos variados, sendo a aplicação do cliente quem termina a sessão. Já o protocolo UDP não é orientado à conexão, nele o cliente constrói uma mensagem e a envia num pacote UDP para o servidor, que responde porém, sem garantia de entrega em uma conexão permanente com o cliente.

Cluster

Isaac Alves Pinheiro — Wed, 24 May 2023 19:23:02 +0000

A palavra "cluster", em inglês, significa “aglomerar” ou “agrupar”, dentro da Tecnologia da Informação (TI), cluster também significa integrar dois ou mais computadores para que eles trabalhem simultaneamente no processamento de uma determinada tarefa.

No entanto, os clusters não necessariamente precisam ter dois ou mais servidores, podemos ter um cluster com apenas um servidor. Então, para ter um cluster com Docker ou Kubernetes, você não precisa ter dois servidores. Entretanto, é importante ter, dentro do cluster, mais de um servidor porque caso ocorra uma falha no primeiro servidor o outro pode assumir o papel, caso seja pré-configurado dessa maneira.

Um cluster de computador é um conjunto de computadores fracamente ou fortemente conectados que funcionam juntos para que, em muitos aspectos, possam ser vistos como um único sistema. Os clusters de computador têm cada nó definido para executar a mesma tarefa, controlado e programado por software.

Os componentes de um cluster geralmente são conectados uns aos outros por meio de redes locais rápidas, com cada nó (computador usado como servidor) executando sua própria instância de sistema operacional. Na maioria das circunstâncias, todos os nós usam o mesmo hardware e o mesmo sistema operacional, embora em algumas configurações, diferentes sistemas operacionais podem ser usados em cada computador ou hardware diferente.

Os clusters são, geralmente, implantados para melhorar o desempenho e a disponibilidade em relação a um único computador, embora sejam, normalmente, muito mais econômicos do que computadores únicos de velocidade ou disponibilidade comparáveis.

Os clusters de computador surgiram como resultado da convergência de uma série de tendências de computação, incluindo a disponibilidade de microprocessadores de baixo custo, redes de alta velocidade e software para computação distribuída de alto desempenho.

Um dos problemas ao projetar um cluster é o quão fortemente acoplados os nós individuais podem ser. Por exemplo, um único trabalho de computador pode exigir comunicação frequente entre os nós. Isso implica que o cluster compartilha uma rede dedicada, está densamente localizado e provavelmente tem nós homogêneos. O outro extremo é quando um trabalho de computador usa um ou poucos nós e precisa de pouca ou nenhuma comunicação entre nós, aproximando-se da computação em grade.

“A computação em grade é um grupo de computadores em rede que trabalham em conjunto, como um super computador virtual, para executar tarefas grandes, como analisar grandes conjuntos de dados e modelagem do clima.” - Fonte: Microsoft Azure.

Em um cluster, os programas aplicativos nunca veem os nós computacionais (também chamados de computadores escravos), mas apenas interagem com o mestre, que é um computador específico que cuida do agendamento e gerenciamento dos escravos. Em uma implementação típica, o mestre tem duas interfaces de rede, uma que se comunica com a rede privada para os escravos e a outra para a rede de uso geral da organização (pública).

Os clusters de computador são historicamente executados em computadores físicos separados com o mesmo sistema operacional. Com o advento da virtualização, os nós do cluster podem ser executados em computadores físicos separados com diferentes sistemas operacionais, mas é adicionada uma camada virtual acima deles a fim de parecerem semelhantes.

Dentro do conceito sobre o que é cluster, o cluster de servidores é a junção de várias máquinas (computadores/servidores) que, quando interligadas, elevam o seu potencial de disponibilidade e de capacidade de atuação.

No cluster, cada computador é denominado “nodo” ou “nó”, sendo que não há limites de quantos nodos podem ser interligados.

Lembrando: Um nodo ou nó (node) representa cada ponto de interconexão com uma estrutura ou rede, independente da função do equipamento representado por ele, seja um ponto de redistribuição ou um terminal de comunicação. A definição de um nó depende da rede e da camada de protocolo referida.

Com isso, os computadores passam a atuar dentro de um único sistema, trabalhando em conjunto no processamento, análise e interpretação de dados, na mesma conexão de rede, informações e/ou realização de tarefas simultâneas.

A função de um cluster é combinar o funcionamento de vários computadores dentro de um mesmo sistema, a fim de potencializar o seu desempenho.

Muitas vezes, a computação em cluster permite o uso de hardwares simples, evitando a necessidade de utilização de servidores complexos ou dos chamados “supercomputadores” para realizar a mesma tarefa, reduzindo, assim, os investimentos.

O cluster consiste em computadores fracamente ou fortemente ligados que trabalham em conjunto, de modo que, em muitos aspectos, podem ser considerados como um único sistema. Diferentemente dos computadores em grade (grid), computadores em cluster têm cada conjunto de nós (nodes), para executar a mesma tarefa, controlado e programado por software.

Tipos de clusters

Existem vários tipos de cluster. Os mais conhecidos são:

High Performance Computing Cluster (cluster de alto desempenho): também conhecido como cluster de alta performance, ele funciona permitindo que ocorra uma grande carga de processamento com um volume baixo de gigaflops em computadores comuns e utilizando sistema operacional gratuito, o que diminui seu custo. Ou seja, esse tipo de cluster é utilizado para desempenhar tarefas de alto desempenho, de modo que garantam a máxima performance da atuação. Também conhecido como cluster de alta performance, funciona permitindo que ocorra uma grande carga de processamento com um volume em computadores comuns e utilizando sistema operacional gratuito, o que diminui seu custo.
Failover ou High Availability Computing Cluster (cluster de alta disponibilidade): são clusters cujos sistemas conseguem permanecer ativos por um longo período de tempo e em plena condição de uso; sendo assim, podemos dizer que eles nunca param seu funcionamento; além disso, conseguem detectar erros se protegendo de possíveis falhas. Ou seja, garante que uma rede permaneça sempre ativa. Para isso, caso um computador apresente falha e fique fora do ar, outro continua mantendo a rede operante. É aquele que consegue permanecer ativo por um longo período e em plena condição de uso. Além disso, consegue detectar erros se protegendo de possíveis falhas.
Load Balancing (cluster para balanceamento de carga): esse tipo de cluster tem como função controlar a distribuição equilibrada do processamento. Requer um monitoramento constante na sua comunicação e em seus mecanismos de redundância, pois, se ocorrer alguma falha, haverá uma interrupção no seu funcionamento. Ou seja, o tipo de cluster load balancing é uma estrutura na qual todos os computadores são responsáveis pela execução de uma determinada tarefa. Assim, caso um dos equipamentos apresente algum problema, ele é automaticamente retirado do sistema e a função inicial atribuída a ele é dividida entre os demais nós. Tem como função controlar a distribuição equilibrada do processamento. Requer um monitoramento constante na sua comunicação e em seus mecanismos de redundância, pois, se ocorrer alguma falha, seu funcionamento será interrompido.
Processamento paralelo: Esse tipo de cluster transforma uma tarefa complexa em várias simples e as distribui entre os nós integrados ao sistema.

Não existe um tipo de cluster mais adequado, por isso, é possível utilizar diferentes tipos paralelamente. A escolha de qual, ou quais, usar depende do objetivo que se pretende alcançar.

O que significa clusterizar?

Clusterizar significa promover o agrupamento de algo. Dentro da Tecnologia da Informação (TI), consiste em integrar um dois ou mais computadores com o objetivo de potencializar a sua eficiência.

No meio corporativo, clusterizar quer dizer unir duas ou mais empresas com o propósito de melhorar suas atuações, aumentar o poder competitivo, permitir acesso a inovações, entre outras funções.

O que é cluster físico e o que é cluster virtual?

Para deixar o conceito do que é cluster mais completo, é importante que você entenda também a diferença entre cluster físico e cluster virtual.

O cluster físico consiste em uma integração presencial entre dois ou mais computadores.

Já o cluster virtual segue o mesmo princípio, ou seja, de integrar computadores em um mesmo sistema, porém por meio de uma rede online.

Esse processo acaba sendo mais dinâmico e garante que mesmo máquinas que estejam distantes fisicamente possam ser conectadas para aumentar o seu desempenho.

Load Balancer

Isaac Alves Pinheiro — Wed, 24 May 2023 19:06:09 +0000

Um Load Balancer (balanceador de carga), abreviado como LB, é um método de distribuição de tráfego de protocolos de redes entre vários computadores e, geralmente, ele fica na frente da aplicação, ou seja, na frente das máquinas (servidores) que rodam seu back-end, enquanto seu back-end consome sua aplicação e as requisições que ele está recebendo, onde, o Load Balancer fica encarregado de distribuir tudo e manter tudo organizado.

As grandes empresas como Google, Microsoft, Amazon, Netflix, Apple e entre outras são capazes de receber muitas informações e muitos clientes online em um site ou aplicativo, e isso sem que o servidor acabe caindo e nisso sem ter algum problema de performance, então, obviamente, há um load balancer (balanceador de carga) configurado nesse servidor.

Então, todo o hardware tem o seu limite, e muitas vezes o mesmo serviço tem que ser repartido por várias máquinas, sob pena de se tornar congestionado. Estas soluções podem-se especializar em pequenos grupos sobre os quais se faz um balanceamento de carga: utilização do CPU, de armazenamento, ou de rede. Qualquer uma delas introduz o conceito de clustering, ou server farm, já que o balanceamento será, provavelmente, feito para vários servidores.

Em rede de computadores, o balanceamento de carga é uma técnica para distribuir a carga de trabalho uniformemente entre dois ou mais computadores, enlaces de rede, UCPs, discos rígidos ou outros recursos, a fim de otimizar a utilização de recursos, maximizar o desempenho, escalabilidade, minimizar o tempo de resposta e evitar sobrecarga. Utilizando múltiplos componentes com o balanceamento de carga, em vez de um único componente, pode aumentar a confiabilidade através da redundância.

Além disso, se houver problema com alguma máquina, ele será capaz de direcionar o tráfego para outra máquina, sem que o usuário perceba.

Dentro de um Load Balancer, quando ele está rodando na aplicação, existem algoritmos responsáveis por fazer essa distribuição e o melhor disso é que você pode configurar essa distribuição, e não existe somente um algoritmo, mas sim vários algoritmos: com menas conexões, menor tempo de resposta, IP Hash, de duas escolhas aleatórias e entre outros tipos de algoritmos dependendo da maneira que você configurar na sua aplicação e isso é bem customizável. O algoritmo mais comum de todos é o RR - Round Robin que é o algoritmo padrão que roda na maioria dos Load Balancers, veja abaixo como esse algoritmo funciona em um balanceador de carga:

RR - Round Robin

O Round Robin, abreviado como RR, é um dos algoritmos mais simples de agendamento de processos em um sistema operacional e é padrão para a maioria dos balanceadores de carga pela simplicidade da sua funcionalidade e processamento, que atribui frações de tempo para cada processo em partes iguais e de forma circular, manipulando todos os processos sem prioridades. O escalonamento Round Robin é simples e fácil de implementar.

O algoritmo de escalonamento Round-Robin é um dos mais antigos e simples algoritmos, além de ser totalmente imune a problemas de starvation que são tarefas que nunca são executadas em função de ter prioridade inferior as demais.

É usado em projetos de sistemas operacionais multitarefa, e foi projetado especialmente para sistemas time-sharing (tempo compartilhado), pois este algoritmo depende de um temporizador (Timer).

Uma unidade de tempo, denominada quantum, é definida pelo sistema operacional, que determina o período de tempo entre cada sinal de interrupção. Todos os processos são armazenados em uma fila circular (circular queue, data structure - estrutura de dados).

Se o quantum é 100 milisegundos e a tarefa leva 250 milisegundos para completar, o agendamento round-robin suspenderá a tarefa após os primeiros 100 milisegundos e dará a outra tarefa da fila, o mesmo tempo. Essa tarefa será executa portanto após 3 agendamentos a saber (100 ms + 100 ms + 50 ms). A interrupção da tarefa é conhecida como preempção.

Tarefa1 = Tempo de execução igual a 250 ms (quantum 100 ms).

Primeiro agendamento = executa tarefa durante 100 ms.
Segundo agendamento = mais 100 ms de execução da tarefa.
Terceiro agendamento = 100 ms, mas a tarefa termina após os primeiros 50 ms.
Total de tempo que a CPU levou para a tarefa1 = 250 ms

Um melhoramento desse agendamento é dividir todos os processos em números iguais de frações de tempo e proporcionais ao tamanho da tarefa, assim todos os processos terminam ao mesmo tempo.

Nesse exemplo, possuimos os clientes no lado esquerdo (C1, C2, C3, C4), o Load Balancer no meio delas, e as máquinas no lado direito (M1, M2, M3). Então, vamos imaginar que esses clientes estão enviando requisição para um endpoint (ponto-final) que vai cair lá no nosso LB, não vamos somente imaginar que 4, mas sim vários clientes enviando requisição para esse endpoint.

E o nosso LB está configurado com o algoritmo de R.R - Round Robin, então esse algoritmo vai sequencialmente distribuir essa carga de tráfego de requisições para cada uma dessas máquinas, ou seja, a primeira que ele vai receber vai distribuir para a máquina 1 (M1), a máquina 2 (M2) e a máquina 3 (M3).

E, assim por diante, para a quantidade de máquinas que ele conseguir enxergar e enviar essa requisição. E, assim que ele acabar, ele vai voltar para a primeira máquina, segunda máquina, terceira máquina e assim por diante. No qual, ele armazena para onde foi enviada a ultima conexão.

Sticky Round Robin

Weighted Round Robin

IP/URL Hash

Least Time

Menor número de conexões

O algoritmo de menor número de conexões é especifico para o determinado propósito a qual foi atribuido pelo seu próprio nome, ou seja, ele verifica quantas conexões possuem em cada máquina aberta.

Least Connections

Verifica quantas conexões há abertas com cada servidor para decidir para onde enviar a próxima requisição.

EJS - Embedded JavaScript Templating

Isaac Alves Pinheiro — Wed, 24 May 2023 19:05:03 +0000

Um Template Engine é um programa responsável por compilar um template (que pode ser escrito usando qualquer uma das várias linguagens) em HTML. O Template Engine normalmente receberá dados de uma fonte externa, que injetará no template que está compilando.

O PHP não é um template engine, mas uma linguagem de programação que pode ser usada para escrever templates ou templates engine. Um template engine não é apenas uma linguagem, mas também a API de programação que permite que os scripts localizem, organizem templates ou atribuam os dados do script a eles.

Os Templates Engine compilam para php nativo, portanto, não há nada a perder e muito a ganhar usando um template engine. Se você olhar para qualquer Template Engine moderno, como smarty ou twig, verá que eles compilam os modelos para fonte php, de modo que a saída seja a mesma como se você tivesse feito a página em php manualmente. Mas os templates engine sabem como compilar a página php melhor do que uma pessoa, pois os templates engine são mantidos por milhares de pessoas.

Essa abordagem permite que você reutilize elementos estáticos da página da Web, enquanto define elementos dinâmicos com base em seus dados. Também facilita a separação de preocupações, mantendo a lógica do aplicativo isolada da lógica de exibição. É mais provável que você se beneficie de um Template Engine se seu site ou aplicativo da Web for orientado a dados - como um diretório de equipe para funcionários administrativos, uma loja da Web que lista vários produtos para os usuários comprarem ou um site com funcionalidade de pesquisa dinâmica. Você não precisará de um Template Engine se estiver buscando uma pequena quantidade de dados de uma API (nesse caso, você pode usar apenas as strings de modelo nativo do JavaScript) ou se estiver criando um pequeno site estático.

Portanto, uma das vantagens do Template Engine é a segurança adicional para personalização do usuário final. Os temas em PHP puro têm capacidade irrestrita de causar danos a um usuário e sua instalação. Assim, um template engine remove esse risco, se for bom e a facilidade de uso para não programadores, como artistas gráficos ou web designers.

Next.js, Astro, EJS, Pug e PHP compartilham a mesma raiz conceitual: gerar HTML no servidor. A diferença está em como, quando e por que fazem isso, e no nível de controle e abstração oferecido.

O EJS (Embedded JavaScript Templating) é uma Template Engine que podemos utilizar com Node.js. Assim como vimos sobre o PUG, com a template engine nós podemos criar as páginas das nossas aplicações em Node.js de forma dinâmica sem depender das limitações do HTML.

A grande diferença entre o EJS e o PUG é que o EJS segue uma sintaxe muito semelhante ao HTML, desta forma qualquer desenvolvedor que já conhece HTML não terá nenhuma dificuldade de trabalhar com o EJS, ao contrário do PUG que possuí algumas particularidades e que pode, no início, afetar a produtividade do desenvolvedor. Além disso, o PHP e EJS compartilham o objetivo comum de facilitar a renderização de conteúdo dinâmico em páginas web, eles diferem em suas abordagens, sintaxe e ecossistemas subjacentes.

Um bom cenário para se usar Templates Engine seria nas áreas de login, cadastro de usuários, cadastro de admins, áreas de usuários e áreas de admin. Isso tudo com arquitetura monolítica e MVC (Model View Controller).

const express = require("express");
const app = express("express");

// Setting up EJS
app.set("view engine", "ejs");

app.get("/", (req,res) => {
    res.render("index");
});

app.listen(8080,()=>{
    console.log("App rodando");
});

Obrigatoriamente, o EJS trabalha com o padrão de servir o HTML do nosso projeto através da pasta ./views/, só que não estamos utilizando HTML básico, mas sim com EJS, a extensão .ejs. E o Express renderiza esse arquivo com res.render() onde ele reconhece os arquivos de forma automática, mas se você quer processar todos os arquivos, basta criar uma pasta: "principal/home", que ele irá interpretar esse diretório dentro da pasta views.

Dentro do arquivo EJS, a tag <%= %> significa exibir o valor da variável.

Podemos também exibir variáveis no nosso HTML:

const express = require("express");
const app = express("express");

// Setting up EJS
app.set("view engine", "ejs");

app.get("/", (req,res) => {
    var nome = "Isaac";
    var lang = "português brasileiro";
    res.render("index", {
       nome: nome,
       lang: lang,
       empresa: "Globo"
    });
});

app.listen(8080,()=>{
    console.log("App rodando");
});

<!DOCTYPE html>
<html lang="pt-BR">
<head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta name="description" content="Exemplo de documento HTML5 básico." />
    <title>EJS</title>
</head>
<body>
    <h1>Dados do colaborador:</h1>

    <%= nome %>
    <%= empresa %>
    <%= lang %>
</body>
</html>

Exemplo 2: Passando parâmetros na nossa rota

const express = require("express");
const app = express("express");

// Setting up EJS
app.set("view engine", "ejs");

app.get("/:nome/:lang", (req,res) => {
    var nome = req.params.nome;
    var lang = req.params.lang;
    res.render("index", {
       nome: nome,
       lang: lang,
       empresa: "Globo"
    });
});

app.listen(8080,()=>{
    console.log("App rodando");
});

<!DOCTYPE html>
<html lang="pt-BR">
<head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta name="description" content="Exemplo de documento HTML5 básico." />
    <title>EJS</title>
</head>
<body>
    <h1>Dados do colaborador:</h1>

    <%= nome %>
    <%= lang %>
</body>
</html>

MVC (Model View Controller)

Isaac Alves Pinheiro — Wed, 24 May 2023 18:14:20 +0000

O MVC é o acrônimo de Model-View-Controller (em português: Arquitetura Modelo-Visão-Controle - MVC) é um padrão de projeto de software, ou padrão de arquitetura de software formulado na década de 1970, focado no reuso de código e a separação de conceitos em três camadas interconectadas, onde a apresentação dos dados e interação dos usuários (front-end) são separados dos métodos que interagem com o banco de dados (back-end).

A arquitetura MVC (Model View Controller) é um padrão de arquitetura de projeto de software adotado para sistemas e aplicações web, que foi muito usado no modelo cliente-servidor.

Normalmente usado para o desenvolvimento de interfaces de usuário que divide uma aplicação em partes (camadas/componentes) interconectadas. Isto é feito para separar representações de informação internas dos modos como a informação é apresentada para e aceita pelo usuário, levando ao desenvolvimento paralelo de maneira eficiente.

Antigamente, o cliente acessava somente um arquivo do sistema dentro de um servidor, isso é possível, porém digamos que seu sistema está em fase de crescimento, e dessa forma seu arquivo vai ganhando um grande volume de dados sendo contidos e processados ao mesmo tempo de maneira congestionada, gerando assim uma sobrecarga, ainda mais se ele estiver desorganizado. Então, o MVC é ideal, justamente, para separar as funcionalidades (Model, View e Controller) tornando seu sistema mais fácil de manutenção, performático e organizado.

A arquitetura MVC (Model-View-Controller) foi criada nos anos 80 na Xerox Parc, por Trygve Reenskaug, que iniciou em 1979 o que viria a ser o nascimento do padrão de projeto MVC. A implementação original foi descrita no artigo “Applications Programming in Smalltalk-80: How to use Model-View-Controller”.

Tradicionalmente usado para interfaces gráficas de usuário (GUIs), esta arquitetura tornou-se popular para projetar aplicações web e até mesmo para aplicações móveis, para desktop e para outros clientes. Linguagens de programação populares como Java, C#, Object Pascal/Delphi, Ruby, PHP, JavaScript e outras possuem frameworks MVC populares que são atualmente usados no desenvolvimentos de aplicações web.

É comum esse tipo de padrão de arquitetura possuir o padrão estrutural de aplicações monolíticas, mas nada impede você de implementar sua aplicação MVC para a arquitetura de microsserviços, então você pode fazer, dessa forma, uma migração do monolítico para microservices.

A popularidade dessa arquitetura pode ser vista principalmente no desenvolvimento de aplicações WEB. Isso é uma consequência do ambiente ter um alcance ilimitado e com constante crescimento, onde a escalabilidade é um dos fatores mais importantes.

Com o aumento da complexidade das aplicações desenvolvidas, sempre visando a programação orientada a objeto, torna-se relevante a separação entre os dados e a apresentação das aplicações. Desta forma, alterações feitas no layout não afetam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout.

Esse padrão resolve tal problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interação com o utilizador, introduzindo um componente entre os dois: o controlador.

A separação de propósitos que o paradigma MVC propõem ajuda na escalabilidade e padronização de um produto. Manter um código que cresce constantemente em grandes corporações é uma tarefa árdua, e pequenas equipes também podem sofrer para aumentar a escalabilidade de um produto se não houver um preparo.

Essa divisão de preocupações, ajuda na separação de tarefas e torna-as mais específicas, uma consequência disso é que os códigos possuem um propósito melhor definido, o que facilita no teste e no contexto de seu desenvolvimento e na reutilização do mesmo.

Além de dividir a aplicação em três tipos de componentes, o desenho MVC define as interações entre eles.

O Controlador (controller) envia comandos para o modelo para atualizar o seu estado (por exemplo, editando um documento). O controlador também pode enviar comandos para a visão associada para alterar a apresentação da visão do modelo (por exemplo, percorrendo um documento).
Um modelo (model) armazena dados e notifica suas visões e controladores associados quando há uma mudança em seu estado. Estas notificações permitem que as visões produzam saídas atualizadas e que os controladores alterem o conjunto de comandos disponíveis. Uma implementação passiva do MVC monta estas notificações, devido a aplicação não necessitar delas ou a plataforma de software não suportá-las.
A visão (view) gera uma representação (Visão) dos dados presentes no modelo solicitado, fazendo a exibição dos dados, sendo ela por meio de um html ou xml.

Camada de modelo ou da lógica da aplicação (Model)

Modelo (Model) é a ponte entre as camadas Visão (View) e Controle (Controller), consiste na parte lógica da aplicação, que gerencia o comportamento dos dados através de regras de negócios, lógica e funções. Esta fica apenas esperando a chamada das funções, que permite o acesso para os dados serem coletados, gravados e, exibidos.

É o coração da execução, responsável por tudo que a aplicação vai fazer a partir dos comandos da camada de controle em um ou mais elementos de dados, respondendo a perguntas sobre o sua condição e a instruções para mudá-las. O modelo sabe o que o aplicativo quer fazer e é a principal estrutura computacional da arquitetura, pois é ele quem modela o problema que está se tentando resolver. Modela os dados e o comportamento por trás do processo de negócios. Se preocupa apenas com o armazenamento, manipulação e geração de dados. É um encapsulamento de dados e de comportamento independente da apresentação.

Lida diretamente com os dados contidos dentro do banco de dados via ORM ou ODM.

Camada de apresentação ou visualização (View)

Visão (View) pode ser qualquer saída de representação dos dados, como uma tabela ou um diagrama. É onde os dados solicitados do Modelo (Model) são exibidos. É possível ter várias visões do mesmo dado, como um gráfico de barras para gerenciamento e uma visão tabular para contadores. A Visão também provoca interações com o usuário, que interage com o Controle (Controller). O exemplo básico disso é um botão gerado por uma Visão, no qual um usuário clica e aciona uma ação no Controle.

Não se dedica em saber como o conhecimento foi retirado ou de onde ela foi obtida, apenas mostra a referência. Segundo Gamma et al (2006), ”A abordagem MVC separa a View e Model por meio de um protocolo inserção/notificação (subscribe/notify). Uma View deve garantir que sua expressão reflita o estado do Model. Sempre que os dados do Model mudam, o Model altera as Views que dependem dele. Em resposta, cada View tem a oportunidade de modificar-se”. Adiciona os elementos de exibição ao usuário: HTML, ASP, XML, Applets. É a camada de interface com o usuário. É utilizada para receber a entrada de dados e apresentar visualmente o resultado.

Camada de controle ou controlador (Controller)

Controle (Controller) é o componente final da tríade, faz a mediação da entrada e saída, comandando a visão e o modelo para serem alterados de forma apropriada conforme o usuário solicitou através do mouse e teclado. O foco do Controle é a ação do usuário, onde são manipulados os dados que o usuário insere ou atualiza, chamando em seguida o Modelo.

O Controle (Controller) envia essas ações para o Modelo (Model) e para a janela de visualização (View) onde serão realizadas as operações necessárias.

Podemos dizer que o Controller é a principal funcionalidade que controla esse sistema, pois ele fica encarregado de obter os dados do Model, realizar responses e requests por meio de protocolos HTTP, configuração de APIs e Middlewares e renderizar todos os dados para a View processar para o cliente.

Então, a sigla correta deveria ser, na verdade, CMV ou CVM.

Então, para ocorrer o funcionamento é acompanhado do seguinte fluxo: o usuário (cliente) acessa a aplicação web pelo browser e faz um request (Controller) e assim pegando os dados (Model) do banco de dados e liberando assim esses dados para o View que envia as responses para o cliente (browser), e assim o sistema estará funcionando perfeitamente para o usuário.

Vantagens do modelo MVC

Como o modelo MVC gerencia múltiplos views usando o mesmo modelo é fácil manter, testar e atualizar sistemas compostos;
É muito simples adicionar novos clientes apenas incluindo seus views e controles;
Torna a aplicação escalável;
É possível ter desenvolvimento em paralelo para o modelo, visualizador e controle pois são independentes;
Facilita o reuso do código;
Melhor nível de sustentabilidade, pois facilita a manutenção da aplicação;
Fácil transformação da interface, sem que haja necessidade de modificar a camada de negócio;
Melhor desempenho e produtividade, graças a estrutura de pacotes modulares;
A arquitetura modular permite aos desenvolvedores e designers desenvolverem em paralelo;
Partes da aplicação podem ser alteradas sem a necessidade de alterar outras.

Desvantagens do modelo MVC

Necessita de um tempo maior para explorar e modelar o sistema;
Requer mão-de-obra especializada;
À medida que o tamanho e a complexidade do projeto crescem, a quantidade de arquivos e pastas continuará aumentando também. Os interesses de UI (interface do usuário) (modelos, exibições, controladores) se localizam em várias pastas, que não são formadas em grupos por ordem alfabética.

Forem: Isaac Alves Pinheiro

Vibe Coding (2025)

Docker

Vantagens de um container Docker

Necessidade do uso de containers Docker

O ecossistema/ambiente do container Docker

Etapas e ferramentas/modos do Docker

Docker Engine

Docker Compose

Docker Swarm

Docker Machine

Docker Hub

Play with Docker

Instalação do Docker

Exibir a versão do Docker

Exibir os todos os dados do Docker

Hello, World! - Docker

Imagens e Containers

Rodar a imagem do Sistema Operacional Ubuntu

Listar todos os containers ativos no momento

Listar todos os containers que eu criei

Listar todos os containers que eu criei (somente os id's)

Executar um Olá, Mundo dentro do container do Ubuntu

Interagir mais com o container do Ubuntu

Startando o container

Startando o container de forma interativa

Sai do container interativo, mas desejo voltar novamente

Parar o container

Parar mais de um id

Layered File System

Limpar container

Limpar containers inativos

Deletar ou Remover containers

Deletar todos os containers

Remover ou Deletar as imagens do Docker

Remover ou Deletar todas as imagens do Docker

Remover ou deletar um Volume

Forçar remover um container

Listando imagens

Removendo imagens

Ver logs de um container

Rodar uma determinada versão da imagem

Camada de imagens

Praticando com o docker run

Baixando a imagem apenas pelo docker, sem atrelar ao terminal

Acessando o site

Abrindo uma porta externa para uma interna

Descobrir a porta

Descobrir a porta de uma maneira mais legível

Nomeando um container

Acessando os detalhes do container

Renomeando um container

Mapeando portas do computador para a porta do servidor

Definindo a variável autor

Docker para DevOps

Salvando dados com volumes

Trabalhando com volumes

Inspecionando o container

Iniciando uma escrita no volume (montando ou linkando em /var/www pelo desktop)

O que acontece se eu remover esse container?

[Stand alone] Rodando código em apenas um container Docker

[Stand alone] Código completo do Docker + Node.js

Interpolação de comando

[Stand alone] Dockerfile

[Stand alone] Montando imagem no Dockerfile

[Stand alone] Subindo imagens no Docker Hub

Somente baixar a imagem

🖧 Networking no Docker (Tipos de Redes)

Bridge network

Host network

Overlay network

[Stand alone] Verificando o default container com o Ubuntu

[Stand alone] Inspecionando a rede

Comunicação de containers

Criando um novo container atrelada a rede

Pegando dados de um banco

Pegando dados de um banco em um outro container

Docker Swarm

Network: Bridge Mode

Network: Host Mode

`Hello, World!` - Docker

Praticando com o `docker run`

Criando o `docker-compose.yaml`

Arquivos de configuração do servidor (`nginx.conf`)

`<VirtualHost *:80>`

`ErrorLog /var/log/apache/error.log`

`ServerAdmin webmaster@localhost`

`CustomLog /var/log/apache/access.log combined`

`DocumentRoot /var/www/html`

A DIRETIVA `DIRECTORYINDEX`