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

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

- + - + @@ -110,52 +110,52 @@

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

CAPÍTULO 2 - PREPARANDO O AMBIENTE

CAPÍTULO 3 - TEST DRIVE

CAPÍTULO 4 - APROFUNDANDO

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/neur0dev/neur0dev.github.io/master/post/images/lxc.png#center

+

https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/docker.png#center

+

https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/2wzeZJt.png#center

+

https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/o3uoJ12.png#center

+

https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/tl53ec9.png#center

+

https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/FsyZT7m.png#center

    +

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

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

    -

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

    +

    https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/IP1wCV7.png#center

    +

    https://raw.githubusercontent.com/scovl/scovl.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,32 +243,32 @@

    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/neur0dev/neur0dev.github.io/master/post/images/cG69vhp.png#center

    +

    https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/8sPOhGu.png#center

    +

    https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/SH20A4i.png#center

    +

    https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/LKIgIoQ.png#center

    +

    https://raw.githubusercontent.com/scovl/scovl.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/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:

    +

    https://raw.githubusercontent.com/scovl/scovl.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:

    -
    1sudo yum -y install origin origin-clients vim-enhanced atomic-openshift-utils 
+
    1sudo yum -y install origin origin-clients vim-enhanced atomic-openshift-utils
 
    Agora o NetworkManager e o certificado:
    
 
    1sudo yum -y install NetworkManager python-rhsm-certificates
 
    Com esses pacotes instalados, precisaremos iniciar o NetworkManager pois o OpenShift usa o NetworkManager para gerenciar as configurações de rede de todos os servidores no cluster:
    
@@ -281,7 +281,7 @@ 
    CONFIGURANDO O NETWORKMANAGER
    
 
    NOTA: Estas etapas se aplicam somente se você estiver usando o nip.io para seus hostnames.
    
 
 
    Vamos então editar o  client DNS do CentOs através do arquivo /etc/resolv.conf, que foi gerado quando instalamos o NetworkManager. O parâmetro nameserver se refere ao servidor DNS do qual seu servidor irá se conectar. Você pode ter até três parâmetros nameserver listados no resolv.conf. O outro parâmetro padrão do resolv.conf, é o search. O valor do search é usado para qualquer consulta no DNS que não seja FQDN. Isto é, nome de domínio completo. Os FQDNs são registros DNS completos - isso significa que um FQDN contém um hostname, e um domínio de nível superior.
    
-
    Caso não esteja familiarizado com a abreviação FQDN,  acesse https://wikibase.adentrocloud.com.br/index.php?rp=/knowledgebase/63/Fully-Qualified-Domain-Name-FQDN-e-Hostname.html para saber mais. Usando o domínio nip.io, perceba que cada octeto no endereço IP é separado por um período. Isso significa que cada número no endereço IP é um nível no domínio sendo o nip.io de nível superior. Devido a algumas configurações que o OpenShift adiciona a cada contêiner, isso pode causar confusão ao extrair imagens de nosso registro intergrado. Sendo assim, o recomendado é editar o parâmetro search para ter apenas o domínio de nível superior (no caso, nip.io), conforme mostrado seguir:
    
+
    Caso não esteja familiarizado com a abreviação FQDN,  acesse https://wikibase.adentrocloud.com.br/index.php?rp=/knowledgebase/63/Fully-Qualified-Domain-Name-FQDN-e-Hostname.html para saber mais. Usando o domínio nip.io, perceba que cada octeto no endereço IP é separado por um período. Isso significa que cada número no endereço IP é um nível no domínio sendo o nip.io de nível superior. Devido a algumas configurações que o OpenShift adiciona a cada contêiner, isso pode causar confusão ao extrair imagens de nosso registro intergrado. Sendo assim, o recomendado é editar o parâmetro search para ter apenas o domínio de nível superior (no caso, nip.io), conforme mostrado seguir:
    
 
    Editando o /etc/resolv.conf:
    
 
    1# Generated by NetworkManager
 2search nip.io
@@ -320,7 +320,7 @@ 
    CONFIGURANDO O NETWORKMANAGER
    
     6...
 
    Pós reiniciar o NetworkManager, confira se de fato o arquivo /etc/resolv.conf foi alterado. Se não houver o parâmetro search, tudo estará como deveria, e você estará pronto para seguir em frente. Agora vamos configurar um software específico para os servidores master e o node.
    
 
    Uma visão mais aprofundada dos subdomínios curinga e do OpenShift:
    
-
    O domínio usar precisará apontar para o servidor do node. Isso ocorre porque o OpenShift usa o HAProxy para rotear o tráfego corretamente entre seu DNS, e os contêineres apropriados. O HAProxy é um balanceador de carga popular, software livre. No OpenShift, ele é executado em um contêiner e em um host específico em seu cluster. Tratando-se de DNS, ter um domínio curinga significa que qualquer host desse domínio apontará automaticamente para o mesmo endereço IP. Vamos ver alguns exemplos. Primeiro, aqui está um domínio curinga real que configuramos em um domínio:
    
+
    O domínio usar precisará apontar para o servidor do node. Isso ocorre porque o OpenShift usa o HAProxy para rotear o tráfego corretamente entre seu DNS, e os contêineres apropriados. O HAProxy é um balanceador de carga popular, software livre. No OpenShift, ele é executado em um contêiner e em um host específico em seu cluster. Tratando-se de DNS, ter um domínio curinga significa que qualquer host desse domínio apontará automaticamente para o mesmo endereço IP. Vamos ver alguns exemplos. Primeiro, aqui está um domínio curinga real que configuramos em um domínio:
    
 
    1$ dig +short *.apps.jeduncan.com
 212.207.21.2
 
    Observe que se você procurar qualquer outro registro terminado em .apps.jeduncan.com, e ele retornará o mesmo IP:
    
@@ -360,7 +360,7 @@ 
    CONFIGURANDO O CONTEINER STORAGE
    
 
 
    Criando o arquivo de configuração do docker-storage-setup:
    
 
    1cat <<EOF > /etc/sysconfig/docker-storage-setup
-2DEVS=/dev/vdb 
+2DEVS=/dev/vdb
 3VG=docker-vg
 4EOF
 
    Perceba que o particionamento /dev/vdb, trata-se do volume de 20 GB que você criou para os nodes.
    
@@ -391,7 +391,7 @@ 
    CONFIGURANDO O CONTEINER STORAGE
    
     7Main PID: 2352 (dockerd-current)
 8Memory: 121.4M
 9CGroup: /system.slice/docker.service
-

    O próximo passo é modificar o SELinux para permitir que o OpenShift se conecte ao NFS como uma fonte de armazenamento persistente.

    +

    O próximo passo é modificar o SELinux para permitir que o OpenShift se conecte ao NFS como uma fonte de armazenamento persistente.

    CONFIGURANDO O SELINUX EM SEUS NODES

    No geral, as aplicações OpenShift precisarão de volumes NFS para atuar como armazenamento persistente. Para fazer isso com sucesso, você precisa informar ao SELinux sobre seus nodes para permitir que os contêineres usem o NFS. Você faz isso usando o utilitário de linha de comando setsebool:

    @@ -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/neur0dev/neur0dev.github.io/master/post/images/tela.png#center

    +

    https://raw.githubusercontent.com/scovl/scovl.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.

    @@ -517,7 +517,7 @@

    CRIANDO PROJETOS

    NOTA: Você poderá encontrar na documentação todos os recursos do comando oc em https://goo.gl/Y3soGH.

    -

    Além do nome do seu projeto, você pode opcionalmente fornecer um display name. O display name é um nome mais amigável para o seu projeto visto que o nome do projeto, tem uma sintaxe restrita porque se torna parte da URL de todos os aplicativos implementados no OpenShift. Agora que você criou seu primeiro projeto, vamos fazer o deploy do nosso primeiro aplicativo. Digamos que o Image Uploader seja um aplicativo escrito em Golang usado para carregar e exibir arquivos. Antes de efetuar o deploy do aplicativo, vou explicar o funcionamento de todos os seus componentes para que você entenda como todas as partes se encaixam e funcionam juntas. Aplicações no OpenShift não são estruturas monolíticas; elas consistem em vários componentes diferentes em um projeto que trabalham em conjunto para implantar, atualizar e manter seu aplicativo durante seu ciclo de vida. Esses componentes são:

    +

    Além do nome do seu projeto, você pode opcionalmente fornecer um display name. O display name é um nome mais amigável para o seu projeto visto que o nome do projeto, tem uma sintaxe restrita porque se torna parte da URL de todos os aplicativos implementados no OpenShift. Agora que você criou seu primeiro projeto, vamos fazer o deploy do nosso primeiro aplicativo. Digamos que o Image Uploader seja um aplicativo escrito em Golang usado para carregar e exibir arquivos. Antes de efetuar o deploy do aplicativo, vou explicar o funcionamento de todos os seus componentes para que você entenda como todas as partes se encaixam e funcionam juntas. Aplicações no OpenShift não são estruturas monolíticas; elas consistem em vários componentes diferentes em um projeto que trabalham em conjunto para implantar, atualizar e manter seu aplicativo durante seu ciclo de vida. Esses componentes são:

    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/neur0dev/neur0dev.github.io/master/post/images/novoprojeto.png#center

    +

    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/scovl/scovl.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:

    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/neur0dev/neur0dev.github.io/master/post/images/appco02.png#center

    +

    https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/appco03.png#center

    +

    https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/appco04.png#center

    +https://raw.githubusercontent.com/scovl/scovl.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/neur0dev/neur0dev.github.io/master/post/images/appco05.png#center

    +

    https://raw.githubusercontent.com/scovl/scovl.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:

    @@ -702,7 +702,7 @@

    FLUXO DE TRABALHO AUTOMATIZADO

    O exemplo a seguir lista todos os namespaces de app-cli com lsns:

    1# lsns -p 4470
-2   	NS TYPE NPROCS PID USER COMMAND
+2       NS TYPE NPROCS PID USER COMMAND
 34026531837 user	254	1 root	/usr/lib/systemd/systemd --	switched-root --system --deserialize 20
 44026532211 mnt	12 4470 1000080000 httpd -D FOREGROUND
 54026532212 uts	12 4470 1000080000 httpd -D FOREGROUND
@@ -729,8 +729,8 @@ 
    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/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:
    
+
    https://raw.githubusercontent.com/scovl/scovl.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):
    
 
    1# pgrep -f dockerd-current
@@ -738,19 +738,19 @@ 
    O NAMESPACE MOUNT
    
 
    1$ nsenter --target 2385
 
    De dentro do namespace mount do docker, a saída do comando mount inclui o ponto de montagem do sistema de arquivos root do app-cli. O LV que o docker criou para o app-cli é montado no node do aplicativo em /var/lib/docker/devicemapper/mnt/8bd64cae.... Vá para esse diretório enquanto estiver no namespace mount do daemon do docker e você encontrará um diretório chamado rootfs. Este diretório é o sistema de arquivos da sua aplicação app-cli no contêiner:
    
 
     1# ls -al rootfs
- 2-rw-r--r--. 	 1 root root 15759 Aug 1 17:24 anaconda-post.log
- 3lrwxrwxrwx. 	 1 root root 7 Aug 1 17:23 bin -> usr/bin
- 4drwxr-xr-x. 	 3 root root 18 Sep 14 22:18 boot
- 5drwxr-xr-x. 	 4 root root 43 Sep 21 23:19 dev
- 6drwxr-xr-x. 	53 root root 4096 Sep 21 23:19 etc
- 7-rw-r--r--. 	 1 root root 7388 Sep 14 22:16 help.1
- 8drwxr-xr-x. 	 2 root	root 6 Nov 5 2016 home
+ 2-rw-r--r--.      1 root root 15759 Aug 1 17:24 anaconda-post.log
+ 3lrwxrwxrwx.      1 root root 7 Aug 1 17:23 bin -> usr/bin
+ 4drwxr-xr-x.      3 root root 18 Sep 14 22:18 boot
+ 5drwxr-xr-x.      4 root root 43 Sep 21 23:19 dev
+ 6drwxr-xr-x.     53 root root 4096 Sep 21 23:19 etc
+ 7-rw-r--r--.      1 root root 7388 Sep 14 22:16 help.1
+ 8drwxr-xr-x.      2 root	root 6 Nov 5 2016 home
  9lrwxrwxrwx.      1 root root 7 Aug 1 17:23 lib -> usr/lib
-10lrwxrwxrwx. 	 1 root root 9 Aug 1 17:23 lib64 -> usr/lib64
-11drwx------. 	 2 root root 6 Aug 1 17:23 lost+found
-12drwxr-xr-x. 	 2 root root 6 Nov 5 2016 media
+10lrwxrwxrwx.      1 root root 9 Aug 1 17:23 lib64 -> usr/lib64
+11drwx------.      2 root root 6 Aug 1 17:23 lost+found
+12drwxr-xr-x.      2 root root 6 Nov 5 2016 media
 13drwxr-xr-x.      2 root root 6 Nov 5 2016 mnt
-14drwxr-xr-x. 	 4 root root 32 Sep 14 22:05 opt
+14drwxr-xr-x.      4 root root 32 Sep 14 22:05 opt
 15...
 
    Entender como esse processo funciona e onde os artefatos são criados é importante quando você usa contêineres todos os dias. Do ponto de vista dos aplicativos em execução no contêiner app-cli, tudo o que está disponível para eles é o que está no diretório rootfs, porque o namespace mount criado para o contêiner isola seu conteúdo. Entender como os namespaces mount funcionam em um node e saber como inserir um namespace de contêiner manualmente é uma ferramenta inestimável para solucionar um problema de uma contêiner que não está funcionando como foi projetado. Por fim, ainda sobre o namespace mount pressione Ctrl+D para sair dele e retornar ao namespace padrão do node. A seguir vamos conhecer o namespace UTS .
    
 
    
@@ -797,7 +797,7 @@ 
    Referências
    
 
     
    Outra maneira de fazer o mesmo processo, é apenas digitando testparm no terminal. Esta é uma ferramenta do samba-tool e serve para fazer análise da sintaxe do smb.conf. Caso não exista smb.conf, ele gera um novo e baseando o workgroup nas configurações existentes do sistema. Crie o diretório dos arquivos dos usuários e aplique as novas configurações:
    
 
    1sudo mkdir -p /var/sambausers
 
    Para aplicar novas configurações:
    
-
    1sudo smbcontrol all reload-config 
+
    1sudo smbcontrol all reload-config
 
    Caso não saiba como configurar seu smb.conf, consulte o site http://www.sloop.net/smb.conf.html. Depois de tudo a cima feito, vamos testar as configurações. Verifique versão do samba e smbclient:
    
 
    1sudo samba -V
 2sudo smbclient -V
@@ -611,7 +611,7 @@ 
    Samba como um controlador de domin
 
    1Domain=[TESTE] OS=[Unix] Server=[Samba 4.1.17-Debian]
 2.   D		   0  Fri Dec 18 11:16:51 2015
 3..	D		   0  Fri Dec 18 11:21:12 2015
-4	49788 blocks of size 524288. 44277 blocks available
+4    49788 blocks of size 524288. 44277 blocks available
 
    
 
    Compartilhamento com o servidor de impressao
    
 
    Você poderá compartilhar as impressoras já configurados com o CUPS mas, tenha em mente que o Samba comunica com o CUPS via soquetes, portanto, você não precisa configurar qualquer permissão especial, além de uma diretiva Listen para o socket CUPS. Criaremos um diretório de spool de impressão, e definir as permissões corretamente. Este é destino onde o Samba irá armazenar arquivos temporários relacionados para imprimir documentos:
    
@@ -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):
    
@@ -917,7 +917,7 @@ 
    Migrando um samba3 PDC para Samb
 
    1sudo ldapsearch -x -h 127.0.0.1
 
    Pronto já temos um servidor ldap com nossa base de usuários. Lembre-se que o samba4 já tem um servidor ldap interno só estamos usando esse servidor ldap temporariamente para que possamos migrar as contas de usuários do samba3 (que usava ldap) para o samba4.
 Fazendo a Migração:
    
-
    1sudo samba-tool domain classicupgrade --dbdir=root/backup/var/lib/samba/ --use-xattrs=yes 
+
    1sudo samba-tool domain classicupgrade --dbdir=root/backup/var/lib/samba/ --use-xattrs=yes
 2--dns-backend=SAMBA_INTERNAL --realm=empresa /root/backup/etc/samba/smb.conf
 
    Entendendo um pouco o faz cada parâmetro:
    
 
      
@@ -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,18 +991,18 @@ 
    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.
    
 
    
 
    
 
    RSAT Ferramenta de administracao remota
    
-
    Para administrar o samba pode-se utilizar o samba-tool, no entanto, recomenda-se a ferramenta Remote Server Admininstration Tools - RSAT da Microsoft. Após instalar, habilite as ferramentas necessárias para a administração do Samba, vá em painel de controle, “Programas e Recursos” e cliquem em “Ativar ou desativar recursos do Windows” (aba lateral esquerda)e selecione as ferramentas:
    
+
    Para administrar o samba pode-se utilizar o samba-tool, no entanto, recomenda-se a ferramenta Remote Server Admininstration Tools - RSAT da Microsoft. Após instalar, habilite as ferramentas necessárias para a administração do Samba, vá em painel de controle, “Programas e Recursos” e cliquem em “Ativar ou desativar recursos do Windows” (aba lateral esquerda)e selecione as ferramentas:
    
 
      
 
    • Ferramentas de Serviços da Área de Trabalho Remota;
      • 
 
    • Ferramentas de Servidor DNS;
      • 
@@ -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
    
@@ -1135,7 +1135,7 @@ 
    Backup e recovery do Samba AD
    
 
    Nota: Se ocorrer algum erro, verifique se na pasta destino se encontra três arquivos. São eles: etc.{Timestamp}.tar.bz2, samba4_private.{Timestamp}.tar.bz2 e sysvol.{Timestamp}.tar.bz2. Em caso de não haver, busque pelos três no source code e coloque-os lá.
    
 
    
 
    E em caso de sucesso, agora só nos falta adicionar o script ao crontab:
    
-
    1sudo crontan -e 
+
    1sudo crontan -e
 
    E a rotina de backup. Por exemplo para ele rodar sempre as 2am
    
 
    10 2 * * * /usr/sbin/samba_backup
 
    Para restaurar o backup, ou melhor, fazer o recovery, é tão simples quanto os passos a cima. Primeiro vamos remover algumas pastas do samba:
    
@@ -1148,7 +1148,7 @@ 
    Backup e recovery do Samba AD
    
     3sudo tar -jxf samba4_private.{Timestamp}.tar.bz2 -C /usr/local/samba/
 4sudo tar -jxf sysvol.{Timestamp}.tar.bz2 -C /usr/local/samba/
 
    Renomeie os arquivos .ldb.bak gerados para .ldb .Para tal, usaremos o find:
    
-
    1sudo find /usr/local/samba/private/ -type f -name '.ldb.bak' -print0 | while read -d $'\0' f ; 
+
    1sudo find /usr/local/samba/private/ -type f -name '.ldb.bak' -print0 | while read -d $'\0' f ;
 2do mv "$f" "${f%.bak}" ; done
 
    Agora faça um upgrade no samba:
    
 
    1sudo samba_upgradedns --dns-backend=SAMBA_INTERNAL
@@ -1177,7 +1177,7 @@ 
    Samba como servidor secundario
    
 
  • –use-ntvfs - Modo de replicação. Neste caso, o NTFS.
    • 
 
 
    Assim, conseguiremos unir o servidor primário com o secundário. Agora, o próximo passo consiste em certificar que seu hostname do domínio secundário é resolúvel:
    
-
    1nslookup test1.dominio.com 
+
    1nslookup test1.dominio.com
 
    
 
    Nota: Neste caso, depende muito do servidor DNS que você está adontando. Isto é, o BIND9 ou o Samba_internal.
    
 
    
@@ -1188,7 +1188,7 @@ 
    Samba como servidor secundario
    
 
    E tente novamente testar o DNS:
    
 
    1nslookup test1.dominio.com
 
    Teste também se o objectGUID é resolúvel:
    
-
    1ldbsearch -H /usr/local/samba/private/sam.ldb '(invocationid= * )' --cross-ncs objectguid 
+
    1ldbsearch -H /usr/local/samba/private/sam.ldb '(invocationid= * )' --cross-ncs objectguid
 
    Se tudo correr bem, deverá aparecer algo semelhante a isto:
    
 
    1# record 1
 2dn: CN=NTDS Settings,CN=TEST,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,
@@ -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:
    
 
      
@@ -1254,7 +1254,7 @@ 
      Referências: