piratas/gti

Dockerizando os serviços e sites

Opened this issue · 8 comments

iuriguilherme commented

Como forma de tornar a infraestrutura mais resiliente, estamos em processo de utilizar a tecnologia docker para o que já temos no ar.

O primeiro site passando por este processo é o o site do partido (http://partidopirata.org), cujo processo está sendo documentado na #14.

A ideia é que tanto os arquivos Dockerfile quanto docker-compose.yml sejam mantidos em repositórios no github (e nos outros espelhos), assim como as imagens utilizadas mantidas na organização do partido no docker hub.

Bancos de dados e demais dados sigiliosos devem ser mantidos de forma segura e não pública, mas isto é outro assunto.

Os outros sites/serviços e suas especificações seriam os seguintes (caso algo esteja incorreto, favor corrigir):

  1. Sites estáticos
    1. https://gti.partidopirata.org
    2. https://iuf.partidopirata.org
    3. https://mumble.partidopirata.org
    4. http://lapirata.org
    5. http://radio.lapirata.org
  2. Wordpress
    1. Site principal
      1. Endereço: http://partidopirata.org
      2. Código
      3. Containers
        1. MariaDB
        2. Wordpress
      4. Volumes
        1. Banco de dados
        2. Uploads
        3. Tema
        4. Plugins
      5. Tarefas
    2. ANAPIRATA
      1. Endereço: http://anapirata.partidopirata.org
      2. Código
      3. Containers
        1. MariaDB
        2. Wordpress
      4. Volumes
        1. Banco de dados
        2. Uploads
        3. Tema
        4. Plugins
      5. Tarefas
        • Configurar envio de e-mail a partir do wordpress
  3. Biblioteca Pirata
    1. Endereço: https://biblioteca.partidopirata.org
    2. Código
    3. Software: Mediagoblin
    4. Containers
      1. Postgres
      2. Mediagoblin
      3. Nginx
    5. Volumes
      1. A biblioteca aceita arquivos de imagem e qualquer documento que possa ser convertido pra PDF no LibreOffice. Isto ocupa espaço de armazenamento.
      2. Tema
  4. Hotsite de coleta de assinaturas
    1. Endereço: https://apoio.partidopirata.org
    2. Código
    3. Software: Django
    4. Containers
      1. Django
      2. Nginx
    5. Volumes
      1. Se o FAQ voltar, é necessário no mínimo um banco SQLite, ou então alguém aponte outra alternativa.
  5. GNU Social
    1. Endereço: https://social.pirata.xyz
    2. Código
    3. Software: GNU Social
    4. Containers
      1. MariaDB
      2. GNU Social
      3. Nginx
    5. Volumes
      1. Banco de dados
      2. Tema
  6. Moodle
    1. Endereço: https://moodle.escolapirata.org
    2. Código
    3. Software: Moodle
    4. Containers
      1. MariaDB
      2. Moodle
      3. Nginx
    5. Volumes
      1. Banco de dados
      2. Uploads
  7. Naofo.de
    1. Endereços
      1. http://nao.usem.xyz
      2. http://naofode.xyz
      3. http://nfde.xyz
    2. Código
    3. Software: naofo.de
    4. Containers
      1. MariaDB
      2. Nginx
    5. Volumes
      1. Banco de dados
      2. O diretório prints armazena vários arquivos de imagem para cada site salvo.
  8. Wikis
    1. Endereços
      1. https://wiki.partidopirata.org
      2. https://sul.partidopirata.org
    2. Código
      1. Wiki Pirata
      2. PIRATAS Sul
    3. Software: Ikiwiki
    4. Containers
      1. Ikiwiki
      2. Nginx
    5. Volumes
      1. Nenhum, o banco de dados é um repositório GIT e se atualiza sozinho aqui no github, em outros sites, e no computador de quem quiser clonar a wiki inteira.
  9. Servidor web
    1. Software: Nginx
    2. Containers
      1. Nginx
    3. Volumes
      1. Arquivos de configuração de sites (diretório /etc/nginx/sites-available)
      2. Arquivos de SSL do let's encrypt - decidir se isto fica no docker ou no hypervisor
    4. Tarefas
      • Criar Dockerfile com Nginx e definindo volumes
      • Manter repositório no github e no dockerhub
      • Acrescentar arquivos de configuração atualmente em uso como volume
      • Acrescentar arquivos do let's encrypt (não publicamente) no diretório do container docker
      • Garantir que o servidor web nginx dentro do container vai conseguir se comunicar normalmente com todos backends como está fazendo agora no hypervisor
      • Mapear as portas 80 e 443 do container nas portas 80 e 443 do servidor enwtickler
  10. Site do GTC
    1. Endereço: http://gtc.partidopirata.org
    2. Código
    3. Issue
    4. Containers
      1. MariaDB
      2. Wordpress
    5. Volumes
      1. Banco de dados
      2. Uploads
      3. Tema
      4. Plugins
    6. Tarefas
      • Criar instalação nova e limpa do wordpress
      • Importar arquivo XML do site antigo para o novo
      • Ver mais tarefas em #40
  11. Plataforma de crowdfunding
    1. Issue
    2. Containers
      1. MariaDB
      2. Wordpress
    3. Volumes
      1. Banco de dados
      2. Uploads
      3. Tema
      4. Plugins
    4. Tarefas
      • Analisar backup do site antigo
      • Criar arquivo docker-compose.yml com instalação do wordpress
      • Criar repositórios git para o site
      • Instalar e configurar plugin de e-mail
      • Ver mais tarefas em #45
iuriguilherme commented

Para o servidor web, encontrei estes projetos no docker hub que podem auxiliar e/ou inspirar:

iuriguilherme commented

Um motivo pra insistir nesta empreitada: https://www.debian.org/security/2016/dsa-3701

Alias, é sabido há anos que existem infinitas técnicas de escalar pra root. Virtualização é a solução óbvia. O ideal seria usar Xen, mas Docker é o que vai ser por enquanto, já é um avanço.

webarthur commented

Mais um ambiente como exemplo (wordpress+phpmyadmin):
http://araujo.cc/blog/ambiente-wordpress-phpmyadmin-com-docker.html

iuriguilherme commented

Outro fato de mundo real para insistir nisto é que com a queda do servidor principal ontem, e com o não uso de servidores alternativos e de backup, é dificultada a possibilidade de subir os serviços em outro servidor em tempo hábil, e portanto, reduzir o tempo de queda para 30 minutos, que é o TTL mínimo do servidor de DNS do domínio.

Eu poderia ter botado os sites no ar nos servidores da igreja insurgente ontem ainda, com o último backup do banco de dados, mas o ideal mesmo é que os serviços já estivessem rodando em vários servidores, com docker swarm e/ou outras ferramentas.

Alias, cabe lembrar que o plano original do novo GTI era manter os servidores da suecia como principais e utilizando estritamente para proxy reverso e balanceador de carga. Apesar de isto ter sido documentado, não foi elaborado o planejamento estratégico do GTI.

Em 2014 cheguamos a mobilizar gente pra botar servidores na roda e fazer parte desse esforço, mas só vale a pena ir atrás das pessoas de novo se já tiver o sistema pronto e for só "dar o deploy" que nem os jovens dizem.

webarthur commented

Já conseguiram dockerizar o negócio? Em que pé ta isso aq?