<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Boa tarde Héctor,</p>
    <p>Fico feliz em contribuir.</p>
    <p>Eu li sobre alguns problemas de configuração dos sistemas e uma
      das coisas que me chamou a atenção para a adoção do Docker é que
      as imagens já vem prontas para uso. Então, por exemplo, eu uso
      dois serviços que são o <a moz-do-not-send="true"
        href="https://github.com/eea/eea.docker.haproxy/">HAProxy</a> e
      o <a moz-do-not-send="true"
        href="https://github.com/eea/eea.docker.varnish">Varnish</a>,
      que são mantidas pela <a moz-do-not-send="true"
        href="https://www.eea.europa.eu/">EEA</a> e para configurá-las
      eu preciso apenas passar alguns parâmetros, como nomes de
      serviços, dentre outros. A configuração para uso do container na
      Stack já estava pronta, bastando apenas verificar e adaptar alguns
      parâmetros.</p>
    <p><br>
    </p>
    <p>
      poderia nos contar um pouco mais de quais são os casos em que
      vocês precisam aumentar o número de instâncias no backend? <br>
    </p>
    <p>Ainda não foi necessário, mas isso foi pensado quando estávamos
      montando a Stack. Eu li um trabalho da UFRGS em que eles
      descreviam uma arquitetura semelhante a que eu usei, com mais de
      um motor, mas com máquinas físicas, então achamos que seria melhor
      desenhar um esquema com mais clientes para aumentar, se fosse o
      caso. Geralmente temos mais picos de uso no início de semestre,
      por exemplo, e nesse caso poderíamos aumentar a quantidade de
      motores se identificarmos necessidade. Além disso, o setor de
      desenvolvimento havia adotado o uso de containers e a gestão da
      infraestrutura por código. Como estávamos construindo um novo
      portal, optamos por aderir a esse sistema para implementar nosso
      ambiente, aproveitando toda uma infraestrutura já voltada ao
      desenvolvimento.<br>
    </p>
    <p>o processo de matrícula envolve o que no Plone?</p>
    <p>Esse processo não envolve o Plone. É o SIGA (Sistema de Gestão
      Acadêmica) da universidade, que sempre tem picos muito altos em
      épocas de matrícula, principalmente o último dia, e picos altos a
      moderados nos finais de período, época de fechamento de turmas e
      lançamento de notas. O sistema é baseado em PHP e a equipe usa uma
      configuração específica para gerenciar a autenticação. Nesse
      semestre ele estava ativo na fase de matrículas e pela
      estabilidade já entrou em produção definitivamente.<br>
    </p>
    <p> os usuários precisam logar?
    </p>
    <p>As equipes de gestão dos sites fazem login, mas adotamos a
      autenticação via LDAP conectando com uma base já existente na
      universidade. Ainda não pensamos em abrir autenticação para toda a
      comunidade acadêmica, mas haveria essa possibilidade via LDAP. Em
      todo o caso, com essa configuração não há problemas com o login.<br>
    </p>
    <p>Eu também fiz alguns testes e se você reparar na configuração do
      arquivo docker-compose.yml no branch 'develop' a Stack está sem o
      HAProxy porque nos testes o sistema de autenticação não funcionava
      usando o Docker Swarm. Depois de pesquisar a respeito notei que
      nesse caso o balanceamento de carga seria desnecessário, porque o
      Swarm já fazia isso, nesse caso a conexão externa seria com um
      serviço, e não com um host específico O sistema interno do Swarm
      faz o balanceamento entre as replicas.<br>
    </p>
    <p>Mas vale ressaltar que mesmo com 4 motores, nos testes de carga
      AB havia muitas falhas. Os clientes ficavam congestionados e o
      Rancher entendia que eles tinham caído e já recriavam outro
      container em seguida, isso causava muitas perdas nos testes, já
      que não havia respostas a muitas requisições. Com a inserção do
      Varnish esse problema foi resolvido, pelo menos em ambiente de
      testes. Talvez eu pudesse balancear a carga diretamente no
      Varnish, mas achei meio trabalhoso configurar os backends
      automaticamente. Nesse caso ele envia requisições para o HAProxy
      que balanceia e distribui entre os clientes, eu mapeio apenas um
      backend. Para executar essa função o Varnish pode sim estar fora
      da Stack, mas caso ele esteja dentro eu consigo mapear pelo
      hostname o endereço de purga nos sites Plone.</p>
    <p>De qualquer forma ainda precisamos ver o comportamento do sistema
      em produção, o que deve acontecer em cerca de uns dois a três
      meses.<br>
    </p>
    <p>Estou à disposição.</p>
    <p>Um abraço,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Elias da Cunha Alves
Graduando em Sistemas de Informação
Estagiário Portal/DICOM
Ramal: 8263
UFVJM - Diamantina/MG</pre>
    <div class="moz-cite-prefix">Em 17-11-2017 12:34, Héctor Velarde
      escreveu:<br>
    </div>
    <blockquote type="cite"
cite="mid:517266aa-7ba9-d28f-6dc3-74abfad18cc5@simplesconsultoria.com.br">muito
      interessante seu caso de uso, Elias; obrigado por compartilhar!
      <br>
      <br>
      acho que não fui claro na minha mensagem anterior; me desculpe, eu
      não estou falando em tirar o HAProxy do stack, estou falando de
      tirar ele da configuração do buildout.
      <br>
      <br>
      na minha opinião ele nunca deveu estar ai, pois essa
      funcionalidade não se justifica em todos os sites. nós, por
      exemplo, só usamos ele como balanceador de carga em 2 sites, mas
      acho que só precisamos em um mesmo.
      <br>
      <br>
      o HAProxy é um software fenomenal, mas ele é tão complexo e a
      documentação e configuração tão enrolada que prefiro deixar ele
      por fora para só ser usado por quem realmente precisar.
      <br>
      <br>
      eu demorei mais de uma semana para chegar em uma configuração que
      utiliza só algumas das funcionalidades avançadas e que fazem muito
      sentido no site que mencionei acima. no passado boa parte das
      pessoas que pediram suporte na lista foi por problemas
      relacionados com o HAProxy e o buildout.
      <br>
      <br>
      por outro lado 75% das pessoas que responderam a enquete usam ou o
      nginx ou o Varnish para fazer balanceamento, e acho que esse
      número faz muito sentido.
      <br>
      <br>
      poderia nos contar um pouco mais de quais são os casos em que
      vocês precisam aumentar o número de instâncias no backend? o
      processo de matrícula envolve o que no Plone? os usuários precisam
      logar?
      <br>
      <br>
      muito obrigado!
      <br>
      <br>
      Héctor Velarde
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>