diff --git a/2019/06/08/openshift/index.html b/2019/06/08/openshift/index.html index cbbbbab..d93f09d 100644 --- a/2019/06/08/openshift/index.html +++ b/2019/06/08/openshift/index.html @@ -13,9 +13,9 @@ - - - + + + @@ -27,7 +27,7 @@ - + @@ -38,15 +38,15 @@

- $ /home/neurodev_ + $ /home/neurodev_

- + - + @@ -110,7 +110,7 @@

OpenShift

-

Este material foi elaborado com o propósito de compreender melhor o funcionamento do OpenShift, e de plataformas agregadas. Se houver por minha parte alguma informação errada, por favor, entre em contato ou me mande um pull request em meu perfil no github. As referências usadas para o estudo além da experiência prática, estarão no rodapé da página. Artigo em constante atualização e revisão.

+

Este material foi elaborado com o propósito de compreender melhor o funcionamento do OpenShift, e de plataformas agregadas. Se houver por minha parte alguma informação errada, por favor, entre em contato ou me mande um pull request em meu perfil no github. As referências usadas para o estudo além da experiência prática, estarão no rodapé da página. Artigo em constante atualização e revisão.

CAPÍTULO 1 - O CONCEITO

@@ -151,11 +151,11 @@

BREVE INTRODUCAO

Imagine o seguinte cenário:

Você contém diversos servidores rodando diversas aplicações em produção e homologação que precisam ser monitoradas, os deploy’s precisam ser rápidos e eficientes com o menor risco possível de queda. Além disso a sua infraEstrutura precisa ser escalável, precisa suportar todas as requesições necessárias para atender à demanda esperada pelo cliente. Imagine este cenário com integração contínua, com deploy contínuo onde ao desenvolvedor, caberá apenas trabalhar com a ferramenta de controle de versão (git, svn, etc..). Imagine um sistema inteligente o suficiente para detectar alterações em código, falhas, ser capaz de voltar a versão automaticamente se algo der errado, ser capaz de escalar horizontalmente automaticamente se as requisições e os acessos aumentarem de repente, e também ser capaz de voltar ao seu estado normal assim que os acessos cessarem.

Além de tudo isso, este sistema inteligente é capaz de prolongar a vida útil dos servidores por entrar em estado IDLE quando nenhuma requisição estiver rodando, e retornar ao estado normal a partir da primeira requisição. E tudo de maneira automática. Este sistema também é capaz de fazer canary teste, para descobrir a aceitação em produção de um determinado sistema. Imaginou o cenário? Pois bem, é sobre esta tecnologia que irei escrever aqui. Devido ao crescimento da demanda por máquinas virtuais e grande dificuldade na operação desse ambiente, surgiu a necessidade de melhorar esse modelo. Com isso empresas que buscam melhores soluções para administradores de sistemas, e desenvolvedores tanto do meio corporativo, quanto da própria comunidade, perceberam que não havia a necessidade de recriar um sistema complexo bastando apenas reutilizar alguns recursos da própria arquitetura e engenharia do kernel Linux. Lançando mão de uma funcionalidade nativa do Kernel Linux para facilitar a criação e gestão destes ambientes virtuais, eles conseguiram ótimos resultados. Assim surgiu o LXC.

-

https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/lxc.png#center

+

https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/lxc.png#center

O Linux Container ou LXC como é mais conhecido, foi lançado em 2008 e é uma tecnologia que permite a criação de múltiplas instâncias isoladas de um determinado Sistema Operacional dentro de um único host. É uma maneira de virtualizar aplicações dentro de um servidor Linux. O conceito é simples e antigo sendo o comando chroot seu precursor mais famoso que foi lançado em 1979 pelo Unix V7 com o intuito de segregar acessos a diretórios e evitar que o usuário pudesse ter acesso à estrutura raiz (“/” ou root). Esse conceito evoluiu alguns anos mais tarde com o lançamento do jail, no sistema operacional FreeBSD 4.

Essa implementação já introduzia a ideia de segregação de rede e limitação dos acessos de superusuários aos processos que passou a ser adotada com maiores funcionalidades pelas distribuições Linux. Posteriormente foi melhor definido em alguns sistemas como o AIX WPAR e o Solaris Containers. Nesses dois sistemas já havia o conceito de virtualização de sistema operacional, mas não o conceito de contêineres.

Nas distribuições Linux o chroot era uma maneira fácil de criar uma jail para as conexões dos servidores FTP, mas acabou ficando mais conhecido pela sua vulnerabilidade do que pela sua segurança. Mais tarde o chroot acabou ajudando a cunhar um termo jailbreak. A grande diferença entre o chroot e o LXC é o nível de segurança que se pode alcançar. Com relação à virtualização, a diferença está no fato do LXC não necessitar de uma camada de sistema operacional para cada aplicação. Ao comparar com a virtualização tradicional, fica mais claro que uma aplicação sendo executada em um LXC demanda muito menos recursos, consumindo menos espaço em disco, e com um nível de portabilidade difícil de ser alcançado por outras plataformas. Mas não foi só a adoção de desenvolvedores e administradores de sistemas que tornou essa tecnologia tão popular. A consolidação da virtualização no mercado e a crescente demanda por computação em nuvem criaram o ambiente perfeito para o LXC se espalhar rapidamente. Aplicações podem ser portadas direto do laptop do desenvolvedor, para o servidor de produção, ou ainda para uma instância virtual em uma nuvem pública ou privada.

-

https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/docker.png#center

+

https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/docker.png#center

Hoje um dos mais conhecidos LXC’s do mercado é o Docker, escrito em GO, que nasceu como um projeto open source da DotCloud, uma empresa de PaaS (Platform as a Service) que apesar de estar mais interessada em utilizar LXC apenas em suas aplicações, acabou desenvolvendo um produto que foi muito bem aceito pelo mercado. Do ponto de vista de desenvolvimento, o Docker por sí atendeu muito bem em vários quesitos. No entanto, com a crescente demanda e necessidade de entregar mais resultados em menos tempo, surgiu também a necessidade de extender as funcionalidades do Docker. Surgiu então ferramentas de orquestração de contêineres como Kubernetes e posteriormente potencializadores do próprio Kubernetes como é o caso do OpenShift.

PLATAFORMA EM CONTEINERES

@@ -170,7 +170,7 @@

PLATAFORMA EM CONTEINERES

Embora o docker engine gerencie contêineres facilitando os recursos do kernel do Linux, ele é limitado a um único sistema operacional no host. Para orquestrar contêineres em vários servidores com eficiência, é necessário usar um mecanismo de orquestração de contêineres. Isto é, um aplicativo que gerencia contêineres em tempo de execução em um cluster de hosts para fornecer uma plataforma de aplicativo escalável. Existem alguns orquestradores conhecidos na comunidade e no mercado como o Rancher, Heroku, Apache Mesos, Docker Swarm, Kubernetes e o OpenShift. O OpenShift usa o Kubernetes como seu mecanismo de orquestração de contêineres. O Kubernetes é um projeto de código aberto que foi iniciado pelo Google. Em 2015, foi doado para a Cloud Native Computing Foundation.

O Kubernetes emprega uma arquitetura master/node. Os servidores master do Kubernetes mantêm as informações sobre o cluster de servidores e os nodes executam as cargas de trabalho reais do aplicativo. A grande vantagem de usar o OpenShift ao invés de seu concorrente Heroku, é que o OpenShift é gratuito, de código aberto, e roda tanto em rede pública, quanto em rede privada. O Heroku roda em plataforma fechada e somente em redes públicas. A baixo uma visão geral da arquitetura do Kubernetes:

-

https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/2wzeZJt.png#center

+

https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/2wzeZJt.png#center

NOTA: Um NODE é uma máquina de trabalho no OpenShift, anteriormente conhecida como minion no Kubernetes. Um node pode ser uma máquina virtual ou física, dependendo do cluster. Cada node tem os serviços necessários para executar pods e é gerenciado pelos componentes principais. Os serviços em um node incluem Docker, kubelet e kube-proxy. Consulte a seção sobre nodes do Kubernetes no documento de design da arquitetura para obter mais detalhes.

@@ -178,7 +178,7 @@

PLATAFORMA EM CONTEINERES

Em uma plataforma de contêiner como o OpenShift, as imagens são criadas quando ocorre o deploy das aplicações, ou quando as imagens são atualizadas. Para ser eficaz, as imagens devem estar disponíveis rapidamente em todos os nodes em um cluster. Para tornar isto possível, o OpenShift inclui um registro de imagens integrado como parte de sua configuração padrão. O registro de imagem é um local central que pode servir imagens dos contêineres para vários locais (tipo um DockerHub local). No Kubernetes, os contêineres são criados nos nodes usando componentes chamados pods. Os pods são a menor unidade dentro de um cluster Kubernetes e nada mais é do que containers rodando dentro do seu cluster. Quando um aplicativo consiste em mais de um pods, o acesso ao aplicativo é gerenciado por meio de um componente chamado service.

Um service é um proxy que conecta vários pods e os mapeia para um endereço IP em um ou mais nodes no cluster. Os endereços IP podem ser difíceis de gerenciar e compartilhar, especialmente quando estão por trás de um firewall. O OpenShift ajuda a resolver esse problema fornecendo uma camada de roteamento integrada. A camada de roteamento é um software balanceador de carga. Quando é feito um deploy de uma aplicação no OpenShift, um registro DNS é criado automaticamente para ele. Esse registro DNS é adicionado ao balanceador de carga, e o balanceador de carga faz interface com o serviço Kubernetes para lidar eficientemente com as conexões entre o deploy da aplicação e seus usuários. Dessa forma, não interessa saber o IP do pod uma vez que quando o container for derrubado e subir outro contêiner para substituí-lo, haverá outro IP em seu lugar.

Nesse caso o registro DNS que fora criado automaticamente será nosso mapeamento de rede daquela respectiva aplicação. Com as aplicações sendo executadas em pods em vários nodes e solicitações de gerenciamento vindas do node master, há bastante comunicação entre os servidores em um cluster do OpenShift. Assim, você precisa ter certeza de que o tráfego está corretamente criptografado e que poderá separar quando necessário. Visão geral da arquitetura OpenShift:

-

https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/o3uoJ12.png#center

+

https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/o3uoJ12.png#center

O OpenShift usa uma solução de rede definida por software SDN para criptografar e modelar o tráfego de rede em um cluster. O OpenShift SDN, é uma solução que usa o Open vSwitch e outras tecnologias software livre, que são configuradas por padrão quando o OpenShift é implementado. Outras soluções SDN também são suportadas. O OpenShift possui fluxos de trabalho projetados para ajudá-lo a gerenciar seus aplicativos em todas as fases de seu ciclo de vida:

-

https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/tl53ec9.png#center

+

https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/tl53ec9.png#center

@@ -217,9 +217,9 @@

CASOS DE USO

  • Configurações e informações sobre como conectar-se a fontes de dados compartilhadas

    • Máquinas virtuais podem ser usadas para isolamento do processo:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/FsyZT7m.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/FsyZT7m.png#center

    Casos de uso para plataformas que trabalham com contêineres:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/MTIhnmV.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/MTIhnmV.png#center

    Os contêineres usam um único kernel para servir aplicações economizando espaço, e recursos e fornecendo plataformas de aplicações flexíveis. No entanto, é bom frizar que o que os contêineres não contêm, é igualmente importante. Ao contrário das máquinas virtuais, todos os contêineres são executados em um único kernel Linux compartilhado. Para isolar os aplicativos, os contêineres usam componentes dentro do kernel. Como os contêineres não precisam incluir um kernel completo para atender a aplicação a ser implementada, além de todas as dependências de um sistema operacional, eles tendem a ser muito menores do que as máquinas virtuais, tanto em suas necessidades de armazenamento, quanto no consumo de recursos.

    Por exemplo, enquanto uma máquina virtual típica você poderá começar com um storage de 10 GB mais ou menos, a imagem do contêiner do CentOS 7 é de 140 MB (do Alpine Linux é ainda menor). Ser menor vem com algumas vantagens: Primeiro, a portabilidade é aprimorada. Mover 140 MB de um servidor para outro é muito mais rápido do que mover 10 GB ou mais. Em segundo lugar, iniciar um contêiner não inclui a inicialização de um kernel inteiro, o processo de inicialização é muito mais rápido. Iniciar um contêiner é normalmente medido em milissegundos, ao contrário de segundos ou minutos para máquinas virtuais.

    As tecnologias por trás dos contêineres fornecem vários benefícios técnicos. Eles também oferecem vantagens comerciais. Soluções empresariais modernas devem incluir economia de tempo ou recursos como parte de seu design. Se você comparar um servidor que usa máquinas virtuais para isolar processos com um que usa contêineres para fazer o mesmo, notará algumas diferenças fundamentais:

    @@ -228,7 +228,7 @@

    CASOS DE USO

  • A densidade da aplicação aumenta com os contêineres. Como a unidade básica usada para efetuar o deploy da aplicação (imagens de contêiner) é muito menor que a unidade para máquinas virtuais (imagens de máquina virtual), mais aplicativos podem caber por servidor. Isso significa que mais aplicações exigem menos servidores para serem executados.

    • Comparando máquinas virtuais e contêineres, podemos ver, por exemplo, que os contêineres fornecem uma melhor utilização dos recursos do servidor:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/IP1wCV7.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/IP1wCV7.png#center

    No entanto, mesmo que os contêineres sejam ótimas ferramentas, nem sempre são a melhor ferramenta para todos os trabalhos. Por exemplo, se você tiver um aplicativo legado complexo, tenha cuidado ao decidir dividi-lo e convertê-lo em uma série de contêineres. Se a aplicação em questão trata-se de um modelo monolítico muito grande, e com diversos recursos, com um banco de dados relacional enorme, e esta aplicação fizer parte de todo um ecossistema de outras aplicações onde compartilha recursos, executa-lo em um contêiner não fará muito sentido e poderá ser um desafio bastante cansativo de tentar implementa-lo em contêineres.

    Os contêineres são uma tecnologia revolucionária, mas não fazem tudo por conta própria. O armazenamento é uma área em que os contêineres precisam ser configurados com outras soluções para efetuar deploys em produção, por exemplo. Isso ocorre porque o armazenamento criado quando um contêiner é levantado, é efêmero. Isto é, se um contêiner for destruído ou substituído, o armazenamento de dentro desse contêiner não será reutilizado.

    Isso é proposital e ocorre por design para permitir que os contêineres estejam sempre stateless por padrão. Isto é, se algo der errado, um container pode ser removido completamente do seu ambiente, e um novo pode ser colocado para substituí-lo quase que instantaneamente. Em outras palavras, contêineres foram feitos para morrer. A idéia de um contêiner stateless é ótima. Mas em algum lugar em sua aplicação, geralmente em vários lugares, os dados precisam ser compartilhados em vários contêineres, e o estado do serviço precisa ser preservado. Aqui estão alguns exemplos dessas situações:

    @@ -243,28 +243,28 @@

    ESCALANDO APLICACOES

    Para aplicações stateless, escalar para cima e para baixo é simples. Como não há dependências além do que está no contêiner e como as transações que acontecem no contêiner são atômicas por design, tudo o que você precisa fazer para dimensionar uma aplicação stateless, é implantar mais instâncias dele e equilibrá-las. Para tornar esse processo ainda mais fácil, o OpenShift faz o proxy das conexões para cada aplicativo por meio de um balanceador de carga integrado. Isso permite que os aplicativos aumentem e diminuam o escalonamento sem alteração na maneira como os usuários se conectam a aplicação.

    Se seus aplicativos forem stateful, o que significa que eles precisam armazenar ou recuperar dados compartilhados, como um banco de dados ou dados que um usuário carregou, então você precisará fornecer armazenamento persistente para eles. Esse armazenamento precisa ser ampliado e reduzido automaticamente em suas aplicações no OpenShift. Para aplicações com informações de estado, o armazenamento persistente é um componente-chave que deve ser totalmente integrado ao seu design.

    À medida que você começa a separar os aplicativos tradicionais e monolíticos em serviços menores que funcionam de forma eficaz em contêineres, você começará a visualizar suas necessidades de dados de uma maneira diferente. Esse processo é geralmente chamado de design de aplicativos como microsserviços. Integrando aplicativos stateful e stateless:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/cG69vhp.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/cG69vhp.png#center

    O OpenShift pode integrar e gerenciar plataformas de armazenamento externo e garantir que o volume de armazenamento de melhor ajuste seja correspondido com os aplicativos que precisam dele. Para qualquer aplicação, você terá serviços que precisam ser informativos e outros sem estado. Por exemplo, o serviço que fornece conteúdo da web estático pode ser sem estado, enquanto o serviço que processa a autenticação do usuário precisa poder gravar informações no armazenamento persistente.

    Como cada serviço é executado em seu próprio contêiner, os serviços podem ser ampliados e desativados independentemente. Em vez de precisar ampliar toda a sua base de código, com os contêineres, você dimensiona apenas os serviços em seu aplicativo que precisam processar cargas de trabalho adicionais. Além disso, como apenas os contêineres que precisam de acesso ao armazenamento persistente o contêm, os dados que entram no contêiner são mais seguros. No exemplo abaixo, se houvesse uma vulnerabilidade no serviço B, um processo comprometido teria dificuldade em obter acesso aos dados armazenados no armazenamento persistente. Ilustrandoas diferenças entre aplicativos tradicionais e de microsserviço: os aplicativos de microsserviço escalam seus componentes de forma independente, criando melhor desempenho e utilização de recursos:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/8sPOhGu.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/8sPOhGu.png#center

    Isso nos leva ao fim do nosso passo inicial inicial do OpenShift e como ele implementa, gerencia e orquestra os aplicativos implantados com contêineres usando o docker e o Kubernetes. Osbenefícios fornecidos pelo OpenShift economizam tempo para humanos e usam os recursos do servidor com mais eficiência. Além disso, a natureza de como os contêineres funcionam oferece melhor escalabilidade e velocidade de implantação em relação às implantações de máquinas virtuais.

    PREPARANDO PARA INSTALAR O OPENSHIFT

    Para este artigo, usarei a distribuição GNU/Linux Centos 7. Ele pode ser executado em servidores físicos, máquinas virtuais (VMs) ou VMs em uma nuvem pública, como o Amazon Web Services (AWS) EC2 ou Google Cloud. Essa instalação deve levar aproximadamente uma hora, dependendo da velocidade da sua conexão com a Internet. Na maior parte do tempo configurando o OpenShift, darei ênfase à linha de comando para controlar o cluster. Para instalar o oc, você precisará ser super usuário, ou ter acesso ao root. Para compreender melhor do que se trata o comando oc, recomendo acessar https://goo.gl/9n8DbQ documentação completa do comando oc. A configuração padrão do OpenShift usa a porta TCP 8443 para acessar a API, e a interface Web. Acessaremos o servidor master nessa porta.

    Para garantir que o cluster possa se comunicar adequadamente, várias portas TCP e UDP precisam estar abertas no master e nos nodes. Você poderá encontrar mais detalhes em https://docs.openshift.org/3.6/install_config/install/prerequisites.html#required-ports. Em nosso caso, faremos isto de maneira mais simples. Por exemplo, caso você esteja criando este ambiente uma rede isolada, como em seu laptop, poderá deixar todas as portas abertas. Ou se preferir, abaixo uma lista de portas que usaremos inicialmente:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/SH20A4i.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/SH20A4i.png#center

    No OpenShift, os hostnames para todos os nodes devem ter um registro DNS. Isso permite que o tráfego criptografado rede entre os nodes funcione corretamente. Basicamente você precisará configurar um registro DNS curinga que apontará para o seu cluster afim de acessar os aplicativos que você implementar futuramente. Se você já tem um servidor DNS já resolve a questão. Caso contrário, você poderá usar o domínio nip.io.

    NOTA: Se você tem experiência com servidores Linux, poderá estar se perguntando: “Por que não posso simplesmente usar o arquivo /etc/hosts para este fim? A resposta é bem simples: esta configuração só funcionaria bem em um host pois não há propagação do DNS na rede. Serviria bem para um Minishift por exemplo. Mas para clusters distribuídos, o melhor é ter um DNS propagado.

    O domínio nip.io quebra um galho enorme neste aspecto. Em vez de configurar e gerenciar um servidor DNS, você poderá criar registros DNS que resolvam qualquer endereço IP escolhido. A única desvantagem do nip.io em comparação ao um servidor DNS próprio, é que você dependerá do acesso á Internet. O único requisito para nossa instalação, no entanto, é que todos os seus servidores possam acessar um servidor DNS público. Como tenho que escolher qual DNS usarei para este artigo, então, escolhi usar o nip.io. A baixo, um exemplo do que poderemos configurar como modelo:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/LKIgIoQ.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/LKIgIoQ.png#center

    O CentOS 7 com o OpenShift terá endereço IP estático para garantir que o DNS e os hostnames configurados funcionem de maneira consistente. Se você não usasse endereço IP estático, seria necessário gerenciar um servidor DHCP em seu ambiente o que de todo modo não é uma boa prática.

    NOTA: O servidor DNS que estamos usando é o 8.8.8.8, que é um dos servidores DNS públicos do Google. Você pode usar qualquer servidor DNS que desejar, mas, para funcionar, ele deve resolver consultas DNS públicas para o domínio nip.io.

    Consulte os requisitos oficiais de hardware para a instalação do OpenShift Origin. Eles são baseados na premissa de que você montará um cluster grande em produção. Em nosso caso, vamos testar algo menor:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/qAChvCm.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/qAChvCm.png#center

    Agora como já vimos como preparar o ambiente, vamos à primeira etapa de instalação do OpenShift. Primeiro, vamos instalar o repositório Extra Packages for Enterprise Linux - EPEL e em seguida o OpenShift Origin. Para tal, execute o seguinte comando:

    1sudo yum -y install epel-release centos-release-openshift-origin36

    Em seguida, alguns pacotes adicionais:

    @@ -492,7 +492,7 @@

    EXECUTANDO O PLAYBOOK

    1# ansible-playbook -i /root/hosts \
 2/usr/share/ansible/openshift-ansible/playbooks/byo/config.yml

    Isso inicia o processo de deploy. Dependendo da velocidade da sua conexão com a Internet, o deploy pode levar cerca de 30 a 45 minutos. Se tudo for bem sucedido, a saída indicará que o processo foi concluído com sucesso. Do contrário, observe o erro que estará em vermelho no terminal e busque debuga-lo. Quando a instalação estiver concluída, você poderá acessar seu host https://ocp1.192.168.1.100.nip.io:8443:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/tela.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/tela.png#center

    NOTA: Provavelmente você receberá um aviso sobre o site estar inseguro porque o certificado SSL não foi assinado corretamente. Não se preocupe com isso - o OpenShift criou seus próprios certificados SSL como parte do processo de instalação. Em nossa configuração, como o deploy do cluster foi feito em um laptop, o cluster está disponível apenas no laptop onde os nodes da VM estão instalados.

    @@ -529,7 +529,7 @@

    CRIANDO PROJETOS

    Todos esses componentes trabalham juntos para atender as aplicações dos usuários finais. As interações entre os componentes do aplicativo podem parecer um tanto complexo, então, vamos ver o que esses componentes fazem com mais detalhes. Começaremos com a forma como o OpenShift cria e usa imagens personalizadas para cada aplicativo. Para cada deploy realizado, é criado uma imagem personalizada para servir a sua aplicação. Essa imagem é criada usando o código-fonte do aplicativo e uma imagem de base personalizada chamada de builder image.

    Por exemplo, o builder image do Golang pode conter servidor da web, e as principais bibliotecas da linguagem. O processo de construção da imagem integra seu código-fonte e cria uma imagem customizada que será usada para o deploy do aplicativo em um contêiner. Uma vez criadas todas as imagens juntamente com todas as builder images, serão então armazenados no registro integrado do OpenShift. Cada aplicativo implementado cria componentes no cluster do OpenShift. Este fluxo de trabalho é totalmente automatizado e personalizável:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/novoprojeto.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/novoprojeto.png#center

    Uma build config contém todas as informações necessárias para construir um aplicativo usando seu código-fonte. Isso inclui todas as informações necessárias para criar a imagem do aplicativo que irá gerar o contêiner. Por exemplo:

    Agora que implementamos o aplicativo, precisaremos acessar o pod recém-implementado. A imagem abaixo mostra o pod associado a um componente chamado service, que é vinculado para fornecer acesso do aplicativo aos usuários:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/deployanapplication.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/deployanapplication.png#center

    Um service usa os rótulos aplicados aos pods quando eles são criados, para acompanhar todos os pods associados a um determinado aplicativo. Isso permite que um service atue como um proxy interno para o aplicativo. Você poderá visualizar informações sobre o service app-cli executando o comando oc describe svc/app-cli:

     1$ oc describe svc/app-cli
  2Name:	app-cli
@@ -611,23 +611,23 @@ 
    IMPLEMENTANDO NOSSO PRIMEIRO AP
 13Weight:		100 (100%)
 14Endpoints:	10.129.1.112:8080

    A saída informa as configurações de host adicionadas ao HAProxy, o service associado à rota, e os endpoints para o service se conectar às solicitações para a rota. Agora que criamos a rota para o aplicativo, verificaremos se está funcional em um navegador Web:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/imageuploader1.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/imageuploader1.png#center

    No OpenShift, vários componentes trabalham em conjunto para criar, implantar e gerenciar os aplicativos:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/apprequest.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/apprequest.png#center

    Todo este processo de deployment da nossa aplicação poderia ter sido feita pela interface web do OpenShift. No entanto, compreendo que temos mais domínio da ferramenta se optarmos pelas configurações em linha de comando. Você poderá experimentar usar a interface Web do OpenShift para fazer o mesmo ou explorar outros caminhos. A partir daquí, analisaremos mais detalhadamente o cluster do OpenShift e investigaremos como os contêineres isolam seus processos no node do aplicativo.

    TRABALHANDO DIRETAMENTE COM DOCKER

    O Docker possui em uma ferramenta de linha de comando apropriadamente chamada de docker. Para obter as informações necessárias para aprofundar o modo como os contêineres isolam os aplicativos no OpenShift, o comando docker deve ser o seu ponto de partida. Para interagir diretamente com o docker, você precisa do SSH e preferencialmente executar os comandos em modo root no node da aplicação. A primeira coisa a percorreremos, é a lista de todos os contêineres atualmente em execução.

    Entre no node da aplicação e execute o comando docker ps. Este comando retorna uma lista de todos os contêineres atualmente em execução no node do aplicativo. Cada linha na saída do comando docker ps representa um contêiner em execução. O primeiro valor em cada linha é uma versão abreviada do ID desse contêiner. Você pode também confirmar com qual aplicação está lidando ao observar o nome dado ao contêiner. Se você seguiu os passos acima, certamente que a saída do docker ps será grande pois inclui informações sobre contêineres que hospedam o registro interno e o balanceador de carga HAProxy.

    -

    A URL que aponta para a imagem no registro OpenShift pode parecer um pouco estranho se você já fez o download de uma imagem de qualquer aplicação ou ferramenta antes. Uma URL padrão de solicitação de registro contém um nome de contêiner e uma tag correspondente, como docker.io/lobocode/golang-app:latest por exemplo. Essa URL do registro pode ser dividida em quatro componentes:

    +

    A URL que aponta para a imagem no registro OpenShift pode parecer um pouco estranho se você já fez o download de uma imagem de qualquer aplicação ou ferramenta antes. Uma URL padrão de solicitação de registro contém um nome de contêiner e uma tag correspondente, como docker.io/neur0dev/golang-app:latest por exemplo. Essa URL do registro pode ser dividida em quatro componentes:

    -

    NOTA: A URL docker.io/lobocode/golang-app:latest, é meramente ilustrativa. Sinta-se livre para testar quaisquer aplicações consultando o Dockerhub.

    +

    NOTA: A URL docker.io/neur0dev/golang-app:latest, é meramente ilustrativa. Sinta-se livre para testar quaisquer aplicações consultando o Dockerhub.

    O valor latest se refere a tag da imagem que você deseja baixar. As Tags das images são valores arbitrários que especificam uma versão da imagem a ser baixada. Em vez de usar tags para especificar uma versão de uma imagem, o OpenShift usa o valor de hash SHA256 exclusivo para cada versão de uma imagem. O download de uma imagem pelo hash SHA256 é um benefício de segurança para o OpenShift. As tags são mutáveis, o que significa que várias tags podem apontar para diferentes versões de imagem em momentos diferentes. As hashes SHA256 são imutáveis ​​e sempre apontam para uma única imagem, independentemente de quaisquer tags associadas a ela. Se uma imagem for alterada por algum motivo, a hash SHA256 será alterada, mesmo que suas tags não sejam alteradas.

    O comando docker inspect exibe todas as informações de tempo de execução de baixo nível sobre um contêiner. Se você não especificar nenhum parâmetro, o docker inspect retornará uma longa lista de informações sobre o contêiner no formato JSON. Usando o parâmetro -f, você pode especificar uma parte da saída JSON que deseja visualizar. Usando o ID do contêiner app-cli obtido usando o docker ps, é possível também obter o PID do contêiner app-cli usando o docker inspect, conforme demonstrado no exemplo a seguir:

    @@ -650,7 +650,7 @@

    COMPREENDENDO O PROCESSO

  • O OpenShift cria um componente chamado Image Stream. No OpenShift, um image stream monitora o builder image, o deployment config e outros componentes que sofrem modificações. Se uma alteração for detectada, os image streams podem acionar as redefinições de aplicativos para refletir as mudanças.

    • A imagem abaixo mostra como esses componentes estão interligados. Quando um desenvolvedor cria um código-fonte de um aplicativo e aciona um novo deployment (neste caso, usando a ferramenta de linha de comando oc), o OpenShift cria os componentes como o deployment config, o image stream e o build config.

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/appco01.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/appco01.png#center

    O build config cria uma imagem customizada específica do aplicativo usando o builder image e o código-fonte especificado. Esta imagem é armazenada no registro de imagens e o componente do deployment config cria um deploy exclusivo para cada versão do aplicativo. O image stream é criado e monitora as alterações na configuração de deployment e nas imagens relacionadas no registro interno. A rota do DNS também é criada e será vinculada a um objeto do Kubernetes. Na imagem acima observe que os usuários estão sem acesso ao aplicativo. Não há aplicação. O OpenShift depende do Kubernetes, bem como do docker para obter o deployment do aplicativo para o usuário.

    UM POUCO SOBRE KUBERNETES

    @@ -662,13 +662,13 @@

    UM POUCO SOBRE KUBERNETES

    Normalmente, um único pod é composto por um único contêiner. Mas, em algumas situações, faz sentido ter um pod composto por vários contêineres. A figura a seguir ilustra os relacionamentos entre os componentes criador pelo Kubernetes. O replication controller determina quantos pods são criados para um deploy inicial de um aplicativo e está vinculado ao componente de deployment do OpenShift. O service também está vinculado ao pod. O service representa todos os pods que o replication controller efetuou o deploy. Ele fornece um único endereço IP no OpenShift para acessar seu aplicativo, pois ele é dimensionado para cima e para baixo em diferentes nodes em seu cluster. O service é o endereço IP interno mencionado na rota criada no balanceador de carga do OpenShift.

    O relacionamento entre o deployment e os replication controllers pode ser explicado na forma como é feito o deployment dos aplicativos, como são dimensionados e atualizados. Quando são feitas alterações em uma configuração de deployment, um novo deploy é criado, o que, por sua vez, cria um novo replication controller. O replication controller, em seguida, cria o número desejado de pods dentro do cluster, que é onde realmente ocorre o deployment do aplicativo.

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/appco02.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/appco02.png#center

    O Kubernetes é usado para orquestrar contêineres em um cluster do OpenShift. Mas em cada node do aplicativo, o Kubernetes depende do docker para criar os contêineres das aplicações.

    UM POUCO SOBRE DOCKER

    O Docker é um contêiner runtime. Isto é, é uma aplicação em servidor que cria, mantém e remove contêineres. Basicamente um contêiner runtime pode atuar como uma ferramenta independente em um laptop ou em um único servidor, mas é mais poderoso quando está sendo orquestrado em um cluster por uma ferramenta como o Kubernetes.

    Posso dizer, então, que o Docker é o contêiner runtime do OpenShift. No entanto, não é o único, pois, um novo runtime é suportado a partir do OpenShift 3.9 e é chamado cri-o e você pode encontra-lo em http://cri-o.io. O Kubernetes controla o docker para criar contêineres que hospedam o aplicativo. Para isolar as bibliotecas e aplicativos na imagem, juntamente com outros recursos do servidor, o docker usa componentes do kernel do Linux. Esses recursos no nível do kernel são os componentes que isolam os aplicativos em seu contêiner.

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/appco03.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/appco03.png#center

    O Docker usa três componentes do kernel Linux para isolar os aplicativos em execução nos contêineres que são criados e limita seu acesso aos recursos no host. São eles:

    O daemon do docker cria esses recursos do kernel dinamicamente quando o contêiner é criado. Aplicativos no OpenShift são executados e associados a esses componentes do kernel. Eles fornecem o isolamento que você vê de dentro de um contêiner. -https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/appco04.png#center

    +https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/appco04.png#center

    Um servidor Linux é separado em dois grupos de recursos principais: o espaço do usuário e o espaço do kernel. O espaço do usuário é onde os aplicativos são executados. Qualquer processo que não faz parte do kernel é considerado parte do espaço do usuário em um servidor Linux. O kernelspace é o próprio kernel. Sem privilégios especiais de administrador, como os usuário root, os usuários não podem fazer alterações no código em execução no kernelspace.

    Os aplicativos em um contêiner são executados no espaço do usuário, mas os componentes que isolam os aplicativos no contêiner são executados no kernelspace. Isso significa que os contêineres são isolados usando componentes do kernel que não podem ser modificados de dentro do contêiner.

    FLUXO DE TRABALHO AUTOMATIZADO

    O fluxo de trabalho automatizado executado após um deploy de um aplicativo no OpenShift inclui o Kubernetes, o docker e o kernel do Linux. As interações e dependências se estendem por vários serviços, conforme descrito na imagem abaixo:

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/appco05.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/appco05.png#center

    O OpenShift trabalha com o Kubernetes para garantir que as solicitações dos usuários sejam atendidas e que os aplicativos sejam entregue. Como qualquer outro processo em execução em um servidor Linux, cada contêiner tem um identificador do processo (PID) no node da aplicação.

    Você pode analisar como os contêineres isolam recursos de processo com namespaces do Linux testando o PID atual do contêiner app-cli. O Docker cria um conjunto exclusivo de namespaces para isolar os recursos em cada contêiner. A aplicação está vinculada aos namespaces porque elas são exclusivas para cada contêiner. O Cgroups e o SELinux são configurados para incluir informações para um contêiner recém-criado, mas esses recursos do kernel Linux são compartilhados entre todos os contêineres em execução no node do aplicativo.

    Para obter uma lista dos namespaces criados para o app-cli, use o comando lsns. Você precisa que o PID para app-cli passe como parâmetro para lsns. O comando lsns aceita um PID com a opção -p e gera os namespaces associados a esse PID. A saída para lsns possui as seis colunas a seguir:

    @@ -729,7 +729,7 @@

    FLUXO DE TRABALHO AUTOMATIZADO

    O NAMESPACE MOUNT

    O namespace mount isola o conteúdo do sistema de arquivos, garantindo que o conteúdo atribuído ao contêiner pelo OpenShift seja o único conteúdo disponível para os processos em execução no contêiner. O namespace mount para o contêiner app-cli, por exemplo, permite que os aplicativos no contêiner acessem apenas o conteúdo na imagem do contêiner app-cli personalizada e qualquer informação armazenada no volume persistente associado à declaração de volume persistente (PVC) para app-cli.

    -

    https://raw.githubusercontent.com/lobocode/lobocode.github.io/master/post/images/namespace-mount.png#center

    +

    https://raw.githubusercontent.com/neur0dev/neur0dev.github.io/master/post/images/namespace-mount.png#center

    Quando configuramos o OpenShift, especificamos um dispositivo de bloco para o docker a ser usado para armazenamento em contêiner. Sua configuração do OpenShift usa o gerenciamento de volume lógico LVM neste dispositivo para armazenamento em contêiner. Cada contêiner recebe seu próprio volume lógico LV quando é criado. Essa solução de armazenamento é rápida se adapta bem a grandes clusters em produção. Para visualizar todos os LVs criados pelo docker no seu host, execute o comando lsblk. O dispositivo LV que o contêiner app-cli usa para armazenamento é registrado nas informações do docker inspect. Para obter o LV para seu contêiner app-cli, execute o seguinte comando:

    1docker inspect -f '{{ .GraphDriver.Data.DeviceName }}' fae8e211e7a7

    Você receberá um valor semelhante ao docker-253: 1-10125-8bd64caed0421039e83ee4f1cdcbcf25708e3da97081d43a99b6d20a3eb09c98. Esse é o nome do LV que está sendo usado como o sistema de arquivos root do contêiner app-cli. O namespace mount para os contêineres das suas aplicações é criado em um namespace de montagem diferente do sistema operacional do node. Quando o daemon do docker é iniciado, ele cria seu próprio namespace mount para conter o conteúdo do sistema de arquivos para os contêineres que cria. Você pode confirmar isso executando lsns para o processo docker. Para obter o PID do processo docker principal, execute o seguinte comando pgrep (o processo dockerd-current é o nome do processo principal do daemon do docker):

    @@ -797,7 +797,7 @@

    Referências

    - @@ -805,7 +805,7 @@

    Referências

    -     @@ -813,14 +813,14 @@

    Referências

    -     - @@ -844,7 +844,7 @@

    Referências

    return; } var d = document, s = d.createElement('script'); s.async = true; - s.src = '//' + "lobocode-github-io" + '.disqus.com/embed.js'; + s.src = '//' + "neur0dev-github-io" + '.disqus.com/embed.js'; s.setAttribute('data-timestamp', +new Date()); (d.head || d.body).appendChild(s); })(); @@ -863,7 +863,7 @@

    Referências

    - neurodev + neurodev

    @@ -878,9 +878,9 @@

    - - - + + + diff --git a/2023/01/01/samba4/index.html b/2023/01/01/samba4/index.html index bf6cd66..c8e00be 100644 --- a/2023/01/01/samba4/index.html +++ b/2023/01/01/samba4/index.html @@ -13,9 +13,9 @@ - - - + + + @@ -27,7 +27,7 @@ - + @@ -38,15 +38,15 @@

    - $ /home/neurodev_ + $ /home/neurodev_

    - + - + @@ -110,7 +110,7 @@

    Samba 4

    -

    Esta é uma documentação não oficial do Samba 4 que fora elaborada através de um estudo pessoal e experiências práticas que tenho tido com o Samba em ambiente de produção. Se houver por minha parte alguma informação errada, por favor, entre em contato para que eu possa corrigir através do meu e-mail (lobocode@gmail.com), ou me mande um pull request no github. As referências usadas para o estudo além da experiência prática, estarão no rodapé da página. Documentação em constante atualização.

    +

    Esta é uma documentação não oficial do Samba 4 que fora elaborada através de um estudo pessoal e experiências práticas que tenho tido com o Samba em ambiente de produção. Se houver por minha parte alguma informação errada, por favor, entre em contato para que eu possa corrigir através do meu e-mail (neur0dev@gmail.com), ou me mande um pull request no github. As referências usadas para o estudo além da experiência prática, estarão no rodapé da página. Documentação em constante atualização.

    Capítulo 1 - História

      @@ -157,7 +157,7 @@

      Introdução

      Foi incluso no NetBIOS um esquema de endereçamento que usava nomes de 16 bytes para identificar estações de trabalho e aplicações habilitadas para rede. Em seguida, a Microsoft adicionou recursos para o DOS que permitia o disco I/O ser redirecionado para a interface NetBIOS, o que permitiu que o espaço em disco fosse compartilhável através da LAN. O protocolo de compartilhamento de arquivos ficou conhecido como SMB, e agora CIFS.

      Em 1985, o protocolo foi expandido, dando origem ao protocolo NetBEUI, que foi durante muito tempo o principal protocolo usado em redes locais, antes da popularização do TCP/IP. O SMB (Server Message Block) veio mais tarde, junto com o Windows 3.11. O protocolo SMB faz o compartilhamento de arquivos e impressoras em redes Microsoft, incluindo a navegação na rede, o estabelecimento de conexões e a transferência de dados. Ele utiliza o NetBIOS para a troca de mensagens entre os hosts e inclui uma versão atualizada do protocolo, que roda sobre o TCP/IP.

      Andrew Tridgell, um australiano que na época era estudante do curso de PhD em Ciências da Computação da Universidade Nacional da Austrália, precisava rodar um software chamado “eXcursion”, no DEC, empresa que trabalhava, para interagir com o Patchworks, um software de compartilhamento de arquivos. O Patchworks era um software proprietário, que utilizava um protocolo obscuro, sobre o qual não existiam muitas informações disponíveis.

      -

      Samba

      +

      Samba

      Como todo bom hacker Andrew_tridgell decidiu estudar o protocolo e assim desenvolver um servidor que pudesse rodar em seu PC. Ele desenvolveu então um sniffer chamado clockspy que era capaz de examinar o tráfego da rede e fez engenharia reversa no protocolo SMB e o implementou no Unix. Isso fez com que no servidor Unix aparecesse como um servidor de arquivos Windows em seu PC com DOS. Com isso, ele foi rapidamente capaz de implementar o suporte às principais chamadas e a desenvolver um programa servidor que era capaz de conversar com os clientes rodando o Patchworks. O objetivo desta primeira versão era apenas resolver um problema doméstico: interligar um computador rodando o MS-DOS ao servidor rodando o Solaris.

      O projeto começou a se tornar popular a partir da versão 1.6.09, que foi a primeira a trazer suporte ao controle de acesso com base nos logins de usuário (assim como o Windows NT), enquanto as versões anteriores suportavam apenas o controle de acesso com base no compartilhamento (assim como no Windows 3.11 e 95), onde a única opção de segurança era usar uma senha de acesso para os compartilhamentos. Para a época, foi um avanço extraordinário visto que tudo o que o samba oferecia, supria os serviços oferecidos pela Microsoft.

      No entanto, em 1999 a Microsoft lançou o Active Directory que é implementado pela primeira vez no Microsoft Windows 2000 Server Edition e com melhorias significativas no Microsoft Windows Server 2003 e 2003 R2 e mais tarde no Windows Server 2008 e 2008 R2.

      @@ -168,7 +168,7 @@

      Introdução

      Usando destes recursos então a comunidade começa a escrever uma nova versão pós a 3.6 do Samba em 2011. A versão 3.6 já trabalhava com o protocolo LDAP usando o OpenLDAP e o Kerberos em separado para alimentar as funcionalidades do Samba para que pudessem obter funcionalidades próximas ao AD.

      Depois de anos de desenvolvimento, a o que seria supostamente a versão 3.7 do Samba não chega nem a ser lançado e é descontinuado visto que em 2012, momento em que o Samba ainda estava em desenvolvimento, a Microsoft libera o RFC 1823 do LDAP, e o RFC 2307,3062,4533 e a comunidade desiste do desenvolvimento da nova versão do Samba e resolvem reescreve-lo do zero.

      Nasce o Samba 4.0. O Samba 4 compreende um servidor de diretório LDAP, um servidor de autenticação Kerberos, um servidor DNS dinâmico e implementações de todas as chamadas de procedimento remoto necessários para o Active Directory. Ele fornece tudo que é necessário para servir como um Active Directory Domain Controler compatível com todas as versões de clientes Microsoft Windows atualmente suportados pela Microsoft, incluindo o Windows 8. O Samba agora permite implementar mecanismos de compartilhamento de arquivos e impressoras, sendo assim possível o acesso a recursos do Windows a partir do GNU/Linux.

      -

      Samba

      +

      Samba

      Possibilidades com Samba 4:

      • Criar um AD Completo
        • @@ -243,7 +243,7 @@

        Conceitos iniciais

        Uma árvore é uma coleção de um ou mais domínios, e árvores de domínio em um namespace contínuo, vinculados em uma hierarquia de confiança transitiva. Uma floresta é uma coleção de árvores que compartilham um catálogo global comum, esquemas de diretório, estruturas lógicas e a configuração do diretório. A floresta representa o limite de segurança dentro do qual os usuários, computadores, grupos e outros objetos são acessíveis.

        O banco de dados do AD está organizado em partições, cada um armazenando tipos de objetos específicos e seguindo um padrão de replicação. A partição schema contém a definição de classes de objetos e atributos dentro da Floresta. A partição Configuration contém informações sobre a estrutura física e de configuração da floresta (como a topologia física). Ambos replicam para todos os domínios da floresta. A partição do domínio detém todos os objetos criados nesse domínio e replica somente dentro de seu próprio domínio.

        Os objetos mantidos dentro de um domínio podem ser agrupados em Organizational Units (OUs). OUs é o nível recomendado de a aplicação de políticas de grupo, que são objetos do AD chamados formalmente Group Policy Objects (GPOs), embora as políticas também podem ser aplicadas a domínios ou sites. A UO é o nível em que os poderes administrativos são comumente delegados, mas a delegação pode ser executada com os objetos individuais ou com os atributos também.

        -

        Samba

        +

        Samba

        Não é possível, criar contas de usuários com um nome de usuário idêntico em OUs separadas. Isto é assim porque o atributo de objeto de usuário (sAMAccountName), deve ser exclusivo dentro do domínio. Dois usuários em diferentes OUs podem ter o mesmo Common Name (o nome sob o qual eles são armazenados no próprio diretório).

        A razão para este problema de nomes duplicados através de diretórios hierárquicos, é que a Microsoft baseia-se nos princípios do NetBIOS, que é um método de gerenciamento de objetos de redes de arquivos simples, que vem desde o Windows NT 3.1 e MS-DOS LAN Manager. Permitir a duplicação de nomes de objetos no diretório, ou remover completamente o uso de nomes de NetBIOS, impediria a compatibilidade com softwares e equipamentos legados.

        O Volume de Sistema (SYSVOL) que é um diretório compartilhado que armazena a cópia do servidor de arquivos de domínio público, que deve ser compartilhado para acesso e replicação em domínios comuns. Ela contém:

        @@ -258,7 +258,7 @@

        Conceitos iniciais

      • Junções de sistema de arquivo. Segundo a Microsoft, o recomendável é instalar esses 3 em locais distintos, preferencialmente em HDs separados, para facilitar a recuperação do sistema em caso de falha de hardware. Se a floresta está no nível de funcionalidade do Windows Server 2008 ou Windows Server 2008 R2, o sistema de replicação de SYSVOL deixa de ser o NT File Replication.
      • Service (NTFRS) e passa a ser o Distributed File System Replication (DFSR), o que termina criando uma dependência de uma versão específica de sistema operacional Windows.
      -

      Samba

      +

      Samba

      Depois de 10 anos de trabalho e 6 anos da liberação da última versão principal, os desenvolvedores do Samba anunciaram o lançamento do Samba 4.0, a versão mais recente da implementação em software livre do protocolo Server Message Block (SMB). Outras características do Samba 4 incluem a primeira implementação em software livre da versão 2.1 do protocolo SMB de compartilhamento de arquivos da Microsoft e uma implementação inicial do SMB3 que será desenvolvido em versões futuras da ramificação do Samba 4.

      Por padrão, o servidor smbd do Samba 3 é utilizado para todos os serviço de arquivos. Para casos de uso como um controlador de domínio do Active Directory, o servidor de arquivos NTVFS é fornecido da forma como foi utilizado nos primeiros betas do Samba 4 e é mais recomendável para esta tarefa. A integração segura e incorporada ao NTP fornece timestamps mais precisos para clientes Windows.

      @@ -281,7 +281,7 @@

      Protocolos SMB e CIFS

      Na evolução do desenvolvimento do SMB, pela Microsoft, criou-se uma versão chamada CIFS (Common Internet File System) para padronizar com a Internet Engineering Task Force - IETF recebendo o nome final de SMB/CIFS (tecnicamente um “dialeto” do SMB) em 1996. O Windows for WorkGroups foi o primeiro sistema da Microsoft a adotar o SMB/CIFS. Como o protocolo predominante foi o TCP/IP e para a resolução de nomes a Microsoft teve que adotar o DNS (Domain Name System) e com que SMB tivesse que ser executado diretamente sobre o protocolo TCP/IP na modalidade denominada hosting direto (utiliza-se TCP e UDP na porta 445). Portanto, em redes Windows, o SMB/CIFS se transformou em um padrão para a manipulação de arquivos entre máquinas.

      O SMB, que significa Server Message Block, é um protocolo para compartilhamento de arquivos, impressoras, portas seriais e abstrações de comunicação. O SMB é um protocolo cliente-servidor. O diagrama a baixo, ilustra a maneira pela qual funciona SMB. Os servidores disponibilizam sistemas de arquivos e outros recursos (impressoras, processadores de mensagens, pipes) disponíveis para os clientes da rede. Os computadores clientes podem ter seus próprios discos rígidos, mas eles também querem o acesso aos sistemas de arquivos compartilhados e impressoras nos servidores.

      -

      SMB

      +

      SMB

      Basicamente o cliente se conecta ao servidor que utiliza o protocolo TCP/IP (na verdade, se conecta ao NetBIOS sobre o TCP/IP, conforme especificado no RFC1001 e RFC1002), NetBEUI ou IPX/SPX. Depois de terem estabelecido uma conexão, o cliente pode, em seguida, enviar comandos (SMBs) para o servidor o que lhe permite abrir arquivos, ler e escrever. É possível fazer todo o tipo de coisa dentro de um servidor de arquivos. No entanto, no caso do SMB, estas coisas são feitas através da rede.

      O protocolo SMB embora tenha outras funções associadas a ele, primordialmente tem como funcionalidade o compartilhamento de arquivos. Mas é possível também o compartilhamento de impressoras e definir níveis de segurança e autenticação. Por ser muito usado nos sistemas operacionais da Microsoft a versão do SMB, denominado SMB/CIFS, é um protocolo muito comum em diversos tipos de máquinas e sistemas para o compartilhamento de arquivos.

      @@ -302,7 +302,7 @@

      Estrutura do Active Directory

      O Active Directory assumiu o mercado de serviços de diretório pelo seu desempenho, segurança e principalmente disponibilidade, o Active Directory esta no mercado desde o lançamento do Windows 2000 Server, após o seu nascimento assumiu a liderança dos serviços de diretório, utilizando como base o LDAP e a comunicação através de replicação lançou vários atributos e principalmente ferramentas para facilitar o gerenciamento de informações nas empresas.

      Hoje quando criamos um usuário para logar no domínio de nossa empresa, estamos utilizando um serviço de diretório e por consequência usando o Active Directory. Abaixo temos uma figura para demonstrar todos os recursos que o Active Directory pode utilizar como serviço de diretório de sua empresa:

      -

      SMB

      +

      SMB

      A cima, comparamos o AD com uma agenda, o AD físicamente também tem um banco de dados, este banco é conhecido com NTDS.dit e esta localizado na pasta %SystemRoot%\NTDS\ntds.dit em uma instalação default do AD. Este diretório chamado de NTDS apenas existirá nos servidores que tenham a função de Domain Controllers (DC’s). Neste diretório existirão os arquivos relacionados abaixo. Durante o processo de instalação do Active Directory da Microsoft, são criados cinco arquivos:

      • Ntds.dit - Arquivo onde são armazenadas todas as informações do AD.
        • @@ -312,16 +312,16 @@

        Estrutura do Active Directory

      • Res2.log - Arquivo de reserva assegura que alterações sejam gravadas na base(Ntds.dit) no caso de falta de espaço em disco.

      Bem, agora sabemos que a estrutura lógica do AD é gravada em uma base de dados física chamada de Ntds.dit, porém Domain Controller é Active Directory? Claro que não, no desenho abaixo demonstramos claramente a diferença entre AD (estrutura lógica do AD) e DC (Servidor que contém uma cópia do NTDS.dit do AD). No desenho abaixo imaginemos uma construção, estamos construindo um grande salão de festas. Imaginem que nosso teto (retângulo azul) é nosso Active Directory, porém precisamos apoiar este teto em pilares (cilindros vermelhos), caso contrário nosso teto irá desabar, certo?

      -

      SMB

      +

      SMB

      É isto mesmo, o Active Directory é a estrutura lógica (teto), e os DC’s são servidores fisicos (pilares), por isto a necessidade de termos muitos DC’s espalhados. Assim nosso AD mesmo na falha de um DC (pilar) ou vários DC’s ainda conseguirá responder as solicitações e pedidos de nossa infraestrutura.

      -

      SMB

      +

      SMB

      Isto só é possível porque cada servidor quando recebe a função de Domain Controller, herda a criação do diretório %SystemRoot%\NTDS\ e toda a estrutura comentada acima. Todos os dados criados originalmente são replicados para o novo DC criado. Assim em um AD (domínio) com três DC’s como na figura abaixo, todos os Dc’s estão atualizados com todos os dados igualmente, isto recebe o nome de replicação do Active Directory.

      -

      SMB

      +

      SMB

      O Serviço de Diretório do AD é divido em duas estruturas a estrutura lógica e a estrutura física, o conhecimento pleno sobre a estrutura do AD é muito importante, principalmente quando maior for sua estrutura. Nestas explicações informaremos algumas ferramentas que podem auxiliar na verificação deste processo, vale lembrar que estamos focando as explicações no Active Directory do Windows Server 2008 R2, porém estas explicações poderão ser utilizadas em qualquer uma das versões de Active Directory, nos próximos artigos falaremos das evoluções para as futuras versões.

      Quando falamos de estrutura lógica do Active Directory, muitos termos são falados, a estrutura lógica do AD consiste em Objetos, Unidades Organizacionais, Domínio, Árvores de Domínio e Floresta. Utilizamos a estrutura lógica do AD para podermos gerenciar os objetos dentro da organização. Já os objetos, são os componentes mais básicos da estrutura lógica e representam, usuários, computadores e impressoras.

      No caso do OU (Unidades Organizacionais), é um objeto de container, utilizado para organizar outros objetos. A organização pode ser feita de várias formas. Geográfica – Onde as OU’s representam Estadas ou Cidades de sua estrutura física Exemplo: OU SP - OU RJ Setorial – Onde as OU’s representam setores da estrutura física da empresa, por unidade de negócio. Exemplo: OU Administrativo – OU Produção Departamental – Onde as OU’s representam setores da estrutura física da empresa por departamento. Exemplo: OU RH – OU DP – OU Caldeira Híbrido – Modelo onde podemos interagir todos os modelos acima, na Figura abaixo temos um modelo disto.

      -

      SMB

      +

      SMB

      O domínio é a estrutura mais importante do Active Directory e tem 2 funções principais.

      • Fecham um limite administrativo para objetos. “Quem esta fora não entra, quem esta dentro não sai”, claro que esta regra pode sofrer alteração media/sambante permissões de entrada e saída, como relações de confiança.
        • @@ -335,14 +335,14 @@

        Estrutura do Active Directory

      Quando precisamos criar um segundo domínio, na maioria das vezes por necessidades no processo de segurança temos o que chamamos de domínios filhos. Quando temos um domínio pai com seus domínios filhos, chamamos de árvore de domínio, pois dividem o mesmo sufixo DNS, porém em distribuição hierárquica. Abaixo colocamos um exemplo para ilustrar nossa explicação.

      Criamos o domínio livemotion.local (Figura esquerda abaixo), para podermos configurar diretivas de segurança, em um dado momento, precisamos criar um domínio novo, que tenha acesso aos recursos do domínio livemotion.local, porém tenha suas próprias necessidades de segurança (Figura direita abaixo).

      -

      SMB

      +

      SMB

      Conforme as figuras acima, podemos ver que quando temos um domínio filho, imedia/sambatamente estamos vinculados a um domínio pai, e esta divisão hierárquica de nome chamamos de Árvore de Domínios.O primeiro domínio de uma Floresta, chamamos de Root Domain, a Floresta receberá o nome deste domínio, a floresta pode ser feita de um único domínio com também estar dividida com várias árvores dentro da mesma floresta.

      -

      SMB

      +

      SMB

      Quando falamos de estrutura física do Active Directory, alguns termos são utilizados, a estrutura física do AD consiste em Domain Controllers e Sites. A estrutura física do AD é totalmente independente da estrutura lógica do AD. A estrutura física é responsável por otimizar o tráfego de rede e manter segurança em locais físicos distintos. Um Domain Controller ou DC tem a função de executar o Active Directory e também armazenar a base do Active Directory bem como Replicar esta base “alterações” com outros DC’s.

      Quando falamos de Árvores de Domínio ou até mesmo Floresta, vale lembrar que um DC pode apenas suportar um único domínio. Para criar uma disponibilidade do Active Directory podemos ter mais de um DC, sendo assim num exemplo de 2 Dc’s temos a base do Active Directory sendo replicada de forma perfeita entre os dois Dc’s. A base do Active Directory o NTDS.dit é divido em partições, conforme a figura demonstrada abaixo:

      -

      SMB

      +

      SMB

      Estas partições formam o arquivo NTDS.dit, este é replicado entre cada um dos DC’s de seu domínio, consequentemente o arquivo é replicado para cada DC, tendo todos os Dc’s sincronizados logo teremos um Active Directory saudável e que pode suprir a falha de um DC, sem afetar o serviço de diretório do domínio.

      Protocolos do Active Directory

      @@ -779,7 +779,7 @@

      Rotacionamento de logs

      Usando acls para permissoes avancadas no Linux

      As ACLs (Access Control Lists) nos fornecem um controle mais refinado sobre quais usuários podem acessar diretórios e arquivos específicos do que as permissões tradicionais do GNU/Linux. Usando as ACLs, podemos especificar as formas nas quais cada um dos usuários podem acessar um diretório ou um arquivo. Se eu quiser dar uma permissão apenas para mais uma pessoa, por exemplo, a minha opção com chmod, seria criar um grupo de apenas uma pessoa e autorizar este grupo a acessar o arquivo ou diretório. Enfim, fica muito complicado quando precisamos regular o acesso de uma maneira mais detalhada.

      -

      Existem dois tipos de ACLs: regras de acesso (access ACLs) e regras padrão (default ACLs). Uma regra de acesso especifica informações de acesso para um único arquivo ou diretório. Já uma regra padrão é aplicada apenas a diretórios, e especifica informações de acesso padrões para todos os arquivos no diretório que não possuam uma ACL explícita aplicada. Como vimos no capítulo 4 em Instalando o Samba, note que instalamos também as ACL’s e ajustamos o particionamento para aceitar a acl no /etc/fstab. De agora em diante vamos trabalhar com uma maneira diferente de lidar com permissões além do já conhecido chmod.

      +

      Existem dois tipos de ACLs: regras de acesso (access ACLs) e regras padrão (default ACLs). Uma regra de acesso especifica informações de acesso para um único arquivo ou diretório. Já uma regra padrão é aplicada apenas a diretórios, e especifica informações de acesso padrões para todos os arquivos no diretório que não possuam uma ACL explícita aplicada. Como vimos no capítulo 4 em Instalando o Samba, note que instalamos também as ACL’s e ajustamos o particionamento para aceitar a acl no /etc/fstab. De agora em diante vamos trabalhar com uma maneira diferente de lidar com permissões além do já conhecido chmod.

      Para usar este tipo de permissão, é bastante simples apesar de haver inúmeros parâmetros. Por exemplo, crie uma pasta chamada testes:

      1mkdir testes

      Em seguida, vamos setar o acesso a leitura, escrita e gravação “apenas” para o usuário “lobo” (o meu usuário por exemplo):

      @@ -925,7 +925,7 @@

      Migrando um samba3 PDC para Samb
    • –dbdir: O diretório onde o banco de dados do Samba3 está localizado.
    • –use-xattr: O Samba4 usa xattr para armazenar metadados de arquivos. O Samba3 não suporta xattr, então você deve usar o parâmetro –use-xattr=yes para habilitar o suporte a xattr no Samba4.
    • –realm: O domínio do Samba3.
      • -
    • –dns-backend: Por padrão o Samba é configurado com o servidor DNS interno. Mas você poderá usar o BIND9 como explica no capítulo 4 em Samba como um controlador de dominio.
      • +
    • –dns-backend: Por padrão o Samba é configurado com o servidor DNS interno. Mas você poderá usar o BIND9 como explica no capítulo 4 em Samba como um controlador de dominio.

    Apos migrar o domínio tive um problema na senha do meu usuário administrator com isso tive que setar a senha do mesmo novamente:

    1sudo samba-tool user setpassword Administrator
@@ -933,7 +933,7 @@ 
    Migrando um samba3 PDC para Samb
 
    1sudo aptitude purge slapd ldap-utils -y
 
    Permissão na pasta dns do samba
    
 
    1sudo chmod 777 -R /opt/samba/private/dns
-
    Por fim, no samba4 faça alguns testes do kerberos e do próprio samba4 que já foram descritos os passos no capítulo 4 em Samba como um controlador de dominio, a partir de Teste o Kerberos….
    
+

    Por fim, no samba4 faça alguns testes do kerberos e do próprio samba4 que já foram descritos os passos no capítulo 4 em Samba como um controlador de dominio, a partir de Teste o Kerberos….

    Nota: Caso você tenha problemas com SID duplicados, por favor acessar a documentação do Samba em Prevent failure due to duplicate SID’s. Isto é, lá contém um script em python que ajuda a resolver este problema.

    @@ -991,12 +991,12 @@

    Samba-Tool

    Ingressando clientes no dominio Windows

    Como o Windows 10 ainda é recente e o 8 não é tão prático quanto o 7, vamos nos focar no 7 para a configuração de domínio do samba. Lembrando que você poderá aplicar o mesmo no 8 e 10 que deverá funcionar. Acesse as propriedades do sistemas e em computador, clique no botão “Alterar”. Informe o nome do domínio e clique em “OK”. Será solicitado um nome e senha de um usuário do domínio, neste caso, iremos utilizar a conta de administrador do Samba, visto que ainda não criamos nenhum usuário comum. Será solicitado que o computador seja reiniciado como nos exemplos a baixo: -Windows -Windows -Windows -Windows

    +Windows +Windows +Windows +Windows

    Ao efetuar este procedimento, o computador será automaticamente registrado no samba. Computadores com S.O. até o Windows XP serão registrados de forma diferente aos clientes com Windows Vista em diante, por conta das diferentes versões do protocolo SMB utilizadas. Reinicie o computador e troque o usuário para o administrador do domínio.

    -

    Windows

    +

    Windows

    Nota: Caso não apareça “Fazer logon em: DOMÍNIO”, informe o login como: DOMÍNIO\administrator.

    @@ -1011,15 +1011,15 @@

    RSAT Ferramenta de administraca
  • Módulo do Active Directory para Windows PowerShell; e
  • Ferramentas de Gerenciamento de Diretiva de Grupo.
    • -

    Windows

    +

    Windows

    A principal ferramenta de administração do Samba da RSAT, é a “Usuários e Computadores do Active Diretory”. Acessível em: “Painel de Controle” > “Ferramentas Administrativas”. Ao executá-la, habilite a opção “Recursos avançados” para exibição plena dos recursos de administração.

    -

    Windows -Windows

    +

    Windows +Windows

    Para outras versões do Microsoft Windows, consulte a instalação do RSAT na documentação do samba. Ao instalar e configurar o Samba, fora definido um compartilhamento denominado “home”, que destina-se ao uso pessoal dos usuários. Não se trata da função de perfil remoto, mas apenas um diretório onde o usuário poderá utilizar para armazenar arquivos pessoais e acessar em qualquer computador do domínio. É necessário ajustar algumas permissões diretamente no Samba. Para isso, efetue o login do usuário administrator no Windows e acesse “Gerenciamento do computador”. Vá no menu “Ação” > “Conectar a outro computador…” e informe o nome do servidor samba, neste caso “debian”.

    -

    Windows -Windows -Windows

    +

    Windows +Windows +Windows

    Ao conectar no servidor, vá em “Ferramentas do sistema” > “Pastas Compartilhadas” > “home”. Configure nas abas “Permissões de compartilhamento” e “Segurança” os seguintes nomes e grupos de usuários:

    Permissões de compartilhamento:

    1Usuários autenticados    Controle Total
@@ -1032,19 +1032,19 @@ 
    RSAT Ferramenta de administraca
 4Administrator           Controle Total
 5Domain Admins           Controle Total

    Você poderá customizar essas permissões de acordo com suas necessidades.

    -

    Windows -Windows -Windows

    +

    Windows +Windows +Windows

    Clique em “OK” para salvar.

    Através da RSAT iremos criar um usuário comum, sem privilégios de administrador. Abra a ferramenta “Usuários e Computadores do Active Diretory”. Em seguida vá no menu “Ação” > “Novo” > “Uusuário”. Informe os dados do usuário, como nome, sobrenome, logon e senha. As senhas deverão atender a política de senhas do Samba, por padrão requer caracteres maiúsculos, minúsculos e números.

    -

    Windows -Windows -Windows

    +

    Windows +Windows +Windows

    Após criá-lo, consulte-o em “Usuários” e configure o compatilhamento “home”, conforme:

    -

    Windows -Windows

    +

    Windows +Windows

    Ao concluir, basta efetuar o login com o novo usuário criado:

    -

    Windows

    +

    Windows

    Configurando perfil nomade

    O Roaming Profile (Perfil Nomade) ou móvel, é criado pelo administrador do sistema e armazenado em um Servidor. Esse perfil está disponível sempre que você faz logon em qualquer computador na rede. Qualquer alteração feita no perfil Roaming Profile será atualizada no Servidor. Se o usuário efetuar logon em outra máquina, todas as configurações e preferências do Desktop (Área de trabalho), como por exemplo, impressoras, papel de parede, configurações de vídeo, etc, estarão disponível para o usuário. @@ -1077,9 +1077,9 @@

    Configurando perfil nomade

    Verifique se o diretório compartilhado está disponível:

    1sudo smbclient -L localhost -U%

    Agora vá para o computador com Windows onde você instalou a ferramenta de administração remota (AD) para o seu servidor de domínio e defina os usuários a quem você deseja definir como perfil nomade. Abra o cmd e digite dsa.msc, ou run e digite dsa.msc para abrir console do Active Directory e em seguida defina o caminho do usuário:

    -

    Windows

    +

    Windows

    Vá para o usuário para o qual você deseja implementar perfil nomade e adicione o caminho seguido pelo nome do usuário do diretório do perfil no profile path da seção de propriedades como mostra abaixo:

    -

    Windows

    +

    Windows

    Daqui em diante você apenas acompanha se o perfil nomade está funcionando ou não. Uma forma de fazer isto, é acessando o usuário no Windows, fazer modificações de arquivos e pastas e acompanhar modificações na pasta /userprofiles no samba.

    Nota: Certifique-se de que o usuário estará logando em máquinas onde o Sistema Operacional se mantém o mesmo. Isto é, que ele esteja logando em máquinas do Windows 7 ao invés de outras versões. Pois, pode ser que não funcione caso o usuário fique transitando entre uma versão e outra do mesmo sistema. Caso ainda tenha dificuldades em operar com perfil nomade no windows7, dê uma olhada neste vídeo. Recomendo que tenha o VLC player instalado na máquina.

    @@ -1095,7 +1095,7 @@

    Adicionando unidades organizaciona
  • Em type, coloque o nome ‘OU Demo’ por exemplo.
  • Em seguida será exibida uma unidade organizacional chamada ‘OU Demo’.
    • -

    Windows

    +

    Windows

    A partir de agora, você poderá mudar o lugar onde criou a unidade organizacional ou simplesmente criar sub unidades organizacionais.

    Nota: Normalmente nós criamos UO baseado na configuração dodepartamento de sua organização. Tenha cuidado para não confundir grupos e unidades organizacionais, grupos são usados para controlar permissões, OU são utilizados para as configurações de implantação para todos os usuários/computadores dentro da UO.

    @@ -1105,16 +1105,16 @@

    Implementando Group Policies

    Assim como para criar unidades organizacionais usando o snap-in do Windows, para criar GPO’s também é bastante simples. Veja os exemplos a baixo:

    • Clique em Iniciar, Ferramentas Administrativas e Diretivas de Grupos. -Windows
      • +Windows
    • Clique sobre com botão direito e Criar um GPO neste domínio e … -Windows
      • +Windows
    • Nome da GPO será “Exemplo_GPO” e OK. -Windows
      • +Windows
    • Sobre a nova GPO clique com botão direito, clique em editar: -Windows
      • +Windows
    • Para bloquear o acesso ao Painel de Controle vai em, Configurações do Usuário, Diretivas, Modelos Administrativos, Painel de Controle e Proibir acesso ao Painel de Controle:
    -

    Windows

    +

    Windows

    Duplo clique sobre a diretiva e marque a opção “Habilitado” de OK. Pronto, GPO criada com sucesso. Caso ainda existam dúvidas a respeito da criação de GPO’s, dê uma olhada neste video da documentação oficial.

    Backup e recovery do Samba AD

    @@ -1227,10 +1227,10 @@

    Samba como servidor secundario

    Agora é hora de ver se a replicação está funcionando para ambos os controladores de domínio. Assim que se você fizer qualquer alteração em um dos dc o mesmo deve refletir sobre o outro dc. Para verificar isto basta usar o comando a baixo:

    1samba-tool drs showrepl

    Na máquina com Windows Server, caso você deseje gerenciar o servidor secundário a partir do snap-in do AD do Windows, abra o Console de gerenciamento do Active Directory, vá em Ação e selecione Alterar controlador de domínio como mostra a baixo:

    -

    Windows

    +

    Windows

    Aqui você deve ser capaz de ver os seus controladores de domínio disponíveis e seus status como mostrado abaixo:

    -

    Windows

    -

    Agora teste criar um usuário no servidor secundário e acompanhar no primário como já mostrei no capítulo 6 em Samba tool. Se o usuário criado no servidor secundário aparecer no primário, a nossa replicação está funcionando bem. O mesmo a partir de qualquer controlador de domínio.

    +

    Windows

    +

    Agora teste criar um usuário no servidor secundário e acompanhar no primário como já mostrei no capítulo 6 em Samba tool. Se o usuário criado no servidor secundário aparecer no primário, a nossa replicação está funcionando bem. O mesmo a partir de qualquer controlador de domínio.

    Referências: