Ferramentas de geração de página de conteúdo para Intranet com containers

Olá caros amigos, tudo bem com vocês? Espero muito que sim.

Nesse artigo vamos falar sobre conteúdos que podem ser disponibilizados via Intranet e claro, provisionados rapidamente com containers. Seja uma pequena até uma grande empresa os sites ou base de conhecimento disponibilizados internamente são a “porta de entrada” para os funcionários ao iniciar e durante o dia de trabalho, para acesso a links de serviços externos e/ou comunicados da empresa. Até ai tudo bem, nada diferente do que já sabemos. Mas como podemos montar uma estrutura simples para essas páginas e entregar algo rápido, eficiente e mais simples de manter?

Sabemos que containers são voláteis contudo neste caso as páginas terão toda a sua estrutura “montada” no servidor e o serviço de renderização no container (não tenho certeza absoluta se no Windows também será assim), ou seja, toda a modificação estrutural e postagens não serão perdidas. Devemos utilizar volumes para que os dados utilizados não sejam perdidos perdidos ao morrer um container.

Até algum tempo atrás nós tínhamos poucas opções para criação de sites, externamente buscávamos uma hospedagem e instalaria o Wordpress ou iríamos recorrer a algo mais simples no Blogger ou no próprio Wordpress[.]com, nesses dois últimos a coisa funcionava de forma um pouco engessada. Para provisionar uma estrutura local de Intranet tínhamos o IIS com uma combinação de MySQL, PHP e com o Wordpress ou um servidor Linux rodando as mesmas aplicações requerendo talvez um ambiente exclusivo só para essa aplicação.

Hoje felizmente evoluímos e chegamos ao advento dos sites estáticos. Ferramentas como o Jekyll e o HUGO (este humilde Blog inclusive roda em HUGO) nos permite provisionar sites simples e super leves tanto para armazenamento quanto em código e consequentemente acesso e com a mesma qualidade de um Wordpress da vida. Na mesma esteira também temos os Containers, ferramentas que facilitam muito a nossa vida no provisionamento de serviços.

Nesse artigo vamos montar de forma simples uma página de Intranet, uma central de chamados e uma base de conhecimento com Docker Containers.

docker stop [container] docker start [container] docker restart [container] serão as únicas tarefas que precisarão ser feitas no container após montado. Caso precise atualizar a imagem basta reprovisionar o container removendo o antigo.

Caso sua rede possua resolução de nomes em FQDN as páginas estarão acessíveis pelo nome do Host/Server.

Índice:

HUGO

Supondo que você já tenha o Docker-ce instalado seja em um Windows Server ou em uma Distro Linux.

Clone este repositório abaixo e siga as instruções contidas para rodá-lo. Percebam que todo o conteúdo deste repo é possível ser auditado e também uma engenharia reversa para modifica-lo ao seu modo e à sua necessidade. Devemos criar uma pasta de output e esta ser apontada no comando docker container run para que o site seja montado e acessível fora do container.

Feito isso voilà, nosso site já estará respondendo através do endereço localhost:1313. Escolha um tema de sua preferência para modificar e insira os arquivos no diretório output onde você o tiver criado.

OBS: Caso seja feita alguma modificação no arquivo “config.toml” o container precisará ser reiniciado. Qualquer outra modificação nos arquivos .html ou nas postagens serão automaticamente publicadas.

Como complemento e que o HUGO é muito versátil, que tal uma página de documentação interna rodando HUGO? Pois temos com o tema K-State CS Hugo Theme.

Jekyll

Está mais adaptado ao Jekyll? Temos também um container e este oficial.

Assim como no container para o HUGO nós devemos criar uma pasta e esta ser também apontada no comando docker container run para que o site seja montado e acessível fora do container.

Mas claro que em ambos os casos acima não queremos qualquer pessoa (por favor meu caro leitor, não entenda aqui como uma colocação pejorativa) acessando o servidor para publicar no site, para isso existe duas formas: Ou dar acesso via compartilhamento ao pessoal da assessoria/setor que manterá o site à pasta output, ou após o site pronto o compartilhamento/acesso tão somente através da pasta que conterá as publicações em formato Markdown.

Se necessário por exemplo montar uma lista de aniversariantes podemos lançar mão dos conteúdos em Embed do Google Apps. As implementações são muitas dentro dos sites estáticos. Sites estáticos são simples e poderosos e esse mesmo ambiente relatado aqui pode ser utilizado para um time de desenvolvimento.

osTicket

Já atendeu a quantos chamados hoje?

É bem possível que a reação de alguns de nós ao dar de cara com o GLPI pela primeira vez seja de espanto. Eu particularmente me senti intimidado com a aparência dele e suas inúmeras funções. Demorei dias até entender como as opções funcionavam e se interligavam. Apesar de na época minha conta ter acesso limitado no ambiente de trabalho, passei a fazer alguns testes em casa mesmo através de labs. E tem tantas funções que acho que mesmo uma empresa de grande porte não faria uso de todas elas no decorrer de suas atividades.

Ainda em lab de testes fui verificar outras alternativas open source para o mesmo fim. Algumas empresas que estão iniciando ou já estão estabelecidas seja de pequeno ou médio porte podem não ter se dado conta da importância de uma central para catalogar e arquivar chamados. Diante disso uma solução simples que pode ser implementada é a osTicket, ferramenta open source como as outras citadas acima.

Tradicionalmente a instalação da osTicket é através de PHP, MySQL ou MariaDB e servidor Apache. Mas como estamos falando de containers aqui, podemos encontrá-lo através de um container oficial (link abaixo) e devemos executar o provisionamento de apenas dois containers para seu funcionamento.

Após a instalação temos as telas abaixo que ilustram sua simplicidade. Alguns itens como podem ver infelizmente não estão totalmente traduzidos. Se seu inglês é bom e você puder contribuir, vale a pena ajudar o projeto. Vale destacar também que através de um plugin oficial a ferramenta possui suporte a LDAP útil para base de usuários. Infelizmente o que faltou para a osTicket ser uma ferramenta perfeita foi a possibilidade de cadastro de equipamentos. Há um plugin de terceiros porém sem manutenção há anos o que inviabiliza a sua implementação nas novas versões.

Se você domina o PHP pode inclusive dar um toque na página inicial e nos logos. Como design não é minha praia e quis somente trazer a ferramenta para vocês tive este resultado simplório.

OTOBO

Em fevereiro de 2021 a empresa por trás do OTRS anunciou o encerramento da sua versão community, em outras palavras não haverá mais OTRS gratuito. É ai então que entra a OTOBO um fork Open Source da OTRS com as mesmas funcionalidades da ferramenta pai e até aqui. O que eu achei excelente na OTOBO foi a sua documentação, muito vasta e direto ao ponto. Assim como a ferramenta pai, ela também permite integração com Active Directory/LDAP, mas também não possui integração com a OCS para integração com o inventário de hosts. A integração precisará ser feita editando um arquivo de sistema conforme documentação.

Os mantenedores da OTOBO permitem um tour demo pela ferramenta, então se está iniciando e deseja implementar uma central de chamados, lá será o lugar para um teste drive legal dela.

E claro, novamente, temos uma imagem oficial disponível para implementação.

As semelhanças Com a OTRS são apenas as cores, por ser um fork direto toda a diagramação permanece inalterada. Segue algumas imagens capturadas do lab.

Eu particularmente dependendo do cenário ainda preferiria a osTicket pela simplicidade ou partiria logo para a GLPI por ser mais completa. Justificando a escolha pelo GLPI, esse possui suporte via plugin à ferramenta OCS Inventory de inventários. Com isso, é possível atrelar um equipamento a um requerente do chamado. A OTRS/OTOBO possui alguns modos onde é possível configuração com a OCS mas não um plugin ou configuração out-of-the-box. E a migração entre OTRS e OTOBO é suportada e pode ser feita livremente inclusive com documentação.

Wiki.js

Assim com a central de chamados é importante a base de conhecimento também é tão importante quanto. Através dela os erros conhecidos podem ser catalogados, tutoriais de configuração desenvolvidos dentre tantas outras funções. Na minha opinião essa é sem dúvida uma das partes vitais de um setor de suporte. Parto da premissa que o analista não é eterno, ou seja, poderá ir para um outro emprego e que nem todo mundo nasce sabendo. Assim sua informação poderá ajudar um recém chegado, seja um analista experiente ou até um estagiário. Documentação seja onde for é de extrema importância.

Tanto GLPI quanto OTRS ou a osTicket possuem uma base de conhecimento interna mas ao usar não me pareceu uma melhor opção. No intuito de sempre utilizar ferramentas FOSS (free and open source software) eis que temos a ferramenta Wiki.js que possui muitas funções e bem simples de utilizar. Através dela você poderá montar uma base de conhecimento como um post de um blog, com escrita em Markdown que é muito mais simples que RTF ou HTML.

Sua instalação também pode ser feita através de um container oficial e é de se elogiar a sua documentação.

Aqui deixem sua imaginação e criatividade falarem mais alto, a ferramenta em si é bem intuitiva e oferece muitas opções de configuração. Abaixo algumas imagens de exemplo.

Conclusão

Lidar com containers nos livra muito das complexidades geradas na manutenção de servidores dedicados. Acima listei somente algumas ferramentas em que já possui essa funcionalidade disponível. É possível inclusive a utilização de ferramentas em Front-End para manipulação dos containers como a Portainer, apesar de particularmente não ver necessidade exceto quando da existência de muitos containers rodando no mesmo servidor.

E você caro leitor conhece alguma das ferramentas listadas? Teria outras para indicar? Me deixe saber logo abaixo nos comentários.

Espero que mais esse artigo seja útil.
Até a próxima!