Redome - Contribuições do(a) usuário(a) [pt-br]

Arquitetura do Sistema - Decisões de Arquitetura

2018-03-19T18:34:56Z

Tgmoraes: Criou página com 'O propósito desta seção é reunir e apresentar as decisões arquiteturais relacionadas ao projeto, detalhando as razões e justificativas que motivaram cada decisão. Sen...'

O propósito desta seção é reunir e apresentar as decisões arquiteturais relacionadas ao projeto, detalhando as razões e justificativas que motivaram cada decisão.

Sendo um ponto único de acesso às informações relacionadas com decisões de arquitetura do projeto, este documento visa preservar a integridade do desenho da arquitetura e dos elementos que surgirão com base nessa arquitetura, assegurar a consistência entre todas as decisões tomadas e evitar reconsideração de decisões já tomadas.

==DA01 – Linguagem para Programação do Backend==
{| class="wikitable"
| style="font-weight: bold;" | Descrição do Problema
| Escolher a linguagem de programação mais adequada para programar o backend do sistema da Fundação Ary Frauzino.
|-
| style="font-weight: bold;" | Premissas
| Linguagem moderna, não proprietária, baseada em padrões abertos, ampla utilização no mercado e referência para desenvolvimento de projetos de sistemas web.
|-
| style="font-weight: bold;" | Alternativas
|
# Backend programado em linguagem NodeJS.
# Backend programado em linguagem Java/JEE.
|-
| style="font-weight: bold;" | Motivação
|
* Java possui frameworks, padrões de projeto e componentes muito bem documentados e que facilitam a implementação de sistemas complexos.
* Existem várias comunidades ativas no mundo trabalhando para popularizar o NodeJS, divulgando posts e tutoriais.
* Java/JEE pertence atualmente ao portfólio de tecnologias da Fundação Ary Frauzino.
* Haverá uma curva de aprendizado dos profissionais da Fundação Ary Frauzino para aprender NodeJS.
* Benchmarks de mercado indicam que runtimes Java apresentam melhor desempenho (maior tempo de resposta e menor consumo de recursos computacionais - CPU/Memória) em comparação à runtimes NodesJS para um mesmo volume de requisições web.
|-
| style="font-weight: bold;" | Decisão de Arquitetura
| Backend programado em linguagem Java.
|-
| style="font-weight: bold;" | Justificativa
| O conhecimento técnico dos profissionais da Fundação em trabalhar com Java/JEE, ampla documentação disponível, maturidade tecnológica no uso desta linguagem de programação para sistemas corporativos complexos e melhor desempenho comprovado da runtime web fundamentam esta decisão.
|-
| style="font-weight: bold;" | Implicações
| A equipe do projeto deve ser constituída por profissionais com conhecimento de programação Java/JEE
|}

==DA02 – Linguagem para Programação do Frontend==
{| class="wikitable"
| style="font-weight: bold;" | Descrição do Problema
| Escolher a linguagem de programação mais adequada para programar o frontend do sistema da Fundação Ary Frauzino.
|-
| style="font-weight: bold;" | Premissas
| Linguagem moderna, não proprietária, baseada em padrões abertos, ampla utilização no mercado e referência para desenvolvimento de projetos de sistemas web.
|-
| style="font-weight: bold;" | Alternativas
|
# Frontend programado em linguagem JSP/JSF.
# Frontend programado em linguagem AngularJS 2.
|-
| style="font-weight: bold;" | Motivação
|
* AngularJS é um framework SPA (Single Page Applications), permitindo fazer páginas web que funcionam sem precisar de reload e que se comporte verdadeiramente como uma aplicação.
* JSP/JSF é parte integrante da plataforma Java/JEE e dispões de muitas bibliotecas de componentes (Primefaces, Richfaces, Trinidad, Icefaces, etc.) para praticamente todos os tipos de aplicação web.
* O AngularJS 2 é compatível com Chrome, Edge, Firefox, IE 9+, Safari, Android 4.1+, desktop, mobile web, iOS, Ionic e NativeScript.
* AngularJS é fortemente orientada a componentes e dispõe de bibliotecas de componentes HTML reutilizáveis (ex.: ngmodules.org ) que contribuiem para manter a produtividade do time alta.
* JSF é um framework server-side que exige o encapsulamento do comportamento do frontend em componentes java(classes, tags) do lado do servidor. AngularJS por outro lado é um framework client-side baseado em JavaScript.
|-
| style="font-weight: bold;" | Decisão de Arquitetura
| Frontend programado em linguagem AngularJS 2.
|-
| style="font-weight: bold;" | Justificativa
| AngularJS apresenta maior abrangência e compatibilidade tecnológica (adequada para aplicações web, desktop, mobile), apresentam melhor tempo de resposta para renderizar o frontend e possui uma sintaxe muito mais clara e fácil de entender pois trabalha com padrões amplamente utilizados no mercado (HTML, CSS e Javascript) de aplicações web.
|-
| style="font-weight: bold;" | Implicações
| A equipe do projeto deve ser constituída por profissionais com conhecimento de programação AngularJS 2.
|}

Arquivo:Arquitetura-pipeline-develop.png

2018-03-19T18:17:16Z

Tgmoraes: Tgmoraes carregada uma nova versão de Arquivo:Arquitetura-pipeline-develop.png

Arquivo:Arquitetura-pipeline-master.png

2018-03-19T18:16:07Z

Tgmoraes: Tgmoraes carregada uma nova versão de Arquivo:Arquitetura-pipeline-master.png

Arquitetura do Sistema - Modelo Operacional

2018-03-19T18:05:19Z

Tgmoraes:

O modelo operacional tem por objetivo definir e documentar a forma como os componentes do sistema serão desenvolvidos e distribuídos em nós, junto com as conexões necessárias para suportar as interações requeridas por estes, de forma a atender os requerimentos funcionais e não funcionais da solução, considerando as restrições de tecnologia.

==Plataforma de Desenvolvimento==
O sistema será desenvolvido com a utilização do IBM® Bluemix porque facilita a implementação e a hospedagem de aplicações.

O IBM® Bluemix que é uma plataforma como serviço (PaaS) baseada em um projeto de código aberto de Cloud Foundry que permite que as organizações e os desenvolvedores criem, implementem e gerenciem aplicativos na nuvem de maneira fácil e rápida.

A equipe do projeto seguirá uma metodologia de desenvolvimento de software DevOps e o IBM Bluemix oferece capacidades que permite maior agilidade no ciclo de vida de desenvolvimento de aplicações nesta metodologia. A seguir uma breve descrição dos serviços DevOps que estão previstos de serem utilizados no projeto:

* '''Track and Plan –''' Permite planejar o backlog e os work itens e tarefas de cada sprint bem como rastrear quem está fazendo o que e quando ficará pronto. Oferece uma interface simples para iniciar um projeto e rapidamente adicionar membros da equipe, atribuir tarefas e produzir código.
* '''Git Hosting –''' Permite criar um projeto com um repositório Git para compartilhar o código fonte com membros da equipe. Os work itens no plano de trabalho podem ser associados às mudanças de código no repositório Git. O código do sistema ficará hospedado na nuvem através de um repositório Git conectado ao Bluemix e desenvolvido localmente utilizando a IDE de desenvolvimento Eclipse. Essa instância Git é o repositório MASTER de código do projeto.
* '''Delivery Pipeline –''' Permite automatizar o processo de deployment de projetos. O pipeline de um projeto define uma sequência de etapas e roda jobs, como builds, testes e deployments.
* '''Gestão e Relatórios –''' Há vários widgets para montar dashboards personalizados. Por exemplo, o widget burndown chart permite acompanhar a velocidade do time enquanto o widget work-item control permite acompanhar o trabalho de cada membro do time.

Cada desenvolvedor executará o Eclipse IDE em seu computador e carregará o código-fonte do sistema usando uma conexão com o repositório Git integrado com o Bluemix. Uma instância local do perfil Liberty que será executada no Eclipse e uma instância do banco de dados Oracle 10g Express Edition deverá ser instalada na máquina de cada desenvolvedor. O Oracle XE é totalmente gratuito para desenvolvimento, distribuição e uso comercial, porém é limitado em tamanho máximo da base de dados (4GB incluindo a tablespace SYSTEM).

Com essa configuração, será possível testar e depurar rapidamente a aplicação, sem conexão com a Internet e fazendo upload do código de volta ao repositório de código sempre que alguma mudança for feita.

[[Arquivo:arquitetura-plataforma-cloud.png]]

==Promoção automatizada entre ambientes==
No Bluemix, serão criados três espaços virtuais para armazenar e controlar os recursos do sistema conforme seu estágio de operação: desenvolvimento, homologação e produção. Cada espaço está configurado com uma runtime do WebSphere Liberty conectado a um schema de banco de dados dedicado ao sistema e disponibilizado pela Fundação Ary Frauzino.

Os seguintes endereços de rede foram definidos para acesso a essas runtimes:

{| class="wikitable"
! style="font-weight: bold;" | Endereço Web
! style="font-weight: bold;" | Ambiente
|-
| style="font-weight: bold;" | dev-redome.mybluemix.net
| Ambiente de testes da equipe de desenvolvimento.
|-
| style="font-weight: bold;" | tst-redome.mybluemix.net
| Ambiente para testes integrados.
|-
| style="font-weight: bold;" | hml-redome.mybluemix.net
| Ambiente para testes de aceitação/homologação do sistema.
|-
| style="font-weight: bold;" | prod-redome.mybluemix.net
| Ambiente produtivo no datacenter Américas.
|-
| style="font-weight: bold;" | prod-redome.eu-gb.mybluemix.net
| Ambiente produtivo no datacenter Europa (alta-disponibilidade geográfica).
|}

A prática de integração e entrega contínua será adotada pela equipe do projeto para permitir aumentar a capacidade de liberar versões do sistema sob demanda, gerar releases bem-sucedidas e implantar o sistema em qualquer ambiente simplesmente apertando um botão e, evitando atividades manuais para geração da build das releases do sistema.

Deste modo será possível detectar erros de forma antecipada e desenvolver o sistema de forma coesa. Para isso, será utilizado o serviço Delivery Pipeline do Bluemix, automatizando desde o desenvolvimento do sistema até sua entrega final. Com ele, diversos tipos de tarefas (ex. testes unitários, análise de código) são executadas com base no sucesso da tarefa anterior.

'''PIPELINE DE DESENVOLVIMENTO - Integração contínua e promoção entre ambientes automatizada para branch ''develop'' '''
[[Arquivo:arquitetura-pipeline-develop.png|1024px]]

'''PIPELINE DE PRODUÇÃO - Integração contínua e promoção entre ambientes automatizada para branch ''master'' '''
[[Arquivo:arquitetura-pipeline-master.png|1400px]]

O serviço Delivery Pipeline do Bluemix será configurado com um acionador manual ou automático (ex. sempre que alguém da equipe realizar o push do código para o repositório Git do projeto) para mover o código para o ambiente de desenvolvimento.

Assim, depois que o código estiver em execução na máquina local e for considerado pronto para o lançamento, ele poderá ser empacotado e enviado ao ambiente de testes na nuvem pública (o processo representado pela seta pontilhada no diagrama). A partir deste momento, a aplicação ficará disponível por meio do Bluemix e acessível através da Internet para ser validada pela equipe de teste e/ou submetido aos testes automatizados.

Somente quando a aplicação passar com sucesso por todos os testes ela será movida para o espaço seguinte para homologação. Este espaço é uma representação de um local para testar o código ativo em um ambiente de qualidade de produção sem colocá-lo na produção real.

Os espaços virtuais criados no Bluemix terão seu acesso controlado. A equipe do projeto terá acesso somente ao espaço '''desenvolvimento''' (teste) o qual conterá os recursos necessários para execução dos testes automatizados e a montagem (build) do sistema. Este espaço é uma área de integração na qual o trabalho individual do desenvolvedor é liberado para ser incorporado ao build e às baselines gerais do sistema.

[[Arquivo:arquitetura-controle-acesso.png]]

Os espaços virtuais '''homologação''' e '''produção''' são restritos e somente a Fundação Ary Frauzino terá acesso, mantendo um isolamento relativo da equipe projeto.

Arquitetura do Sistema - Modelo Operacional

2018-03-19T17:56:34Z

Tgmoraes: Criou página com 'O modelo operacional tem por objetivo definir e documentar a forma como os componentes do sistema serão desenvolvidos e distribuídos em nós, junto com as conexões necessá...'

Arquitetura do Sistema - Princípios de Arquitetura

2018-03-19T17:40:46Z

Tgmoraes: Criou página com 'Nesta seção estão descritos os princípios de arquitetura para o sistema computacional objeto deste projeto. Tais princípios são definições de alto nível de valores fu...'

Nesta seção estão descritos os princípios de arquitetura para o sistema computacional objeto deste projeto. Tais princípios são definições de alto nível de valores fundamentais, regras gerais e diretrizes que orientam o processo de tomada de decisões técnicas, servindo de base para a arquitetura e desenvolvimento deste sistema.

==PA01 – Conformidade com padrões técnicos==
O sistema será desenvolvido para operar em plataforma Web. O back-end será implementado em tecnologia Java EE (versão 7) e Java Persistence API (versão 2.1) enquanto que o front-end com Angular (versão 2.0) e Typescript.

No contexto dos componentes desenvolvidos em Java, os seguintes padrões serão adotados quando aplicável:

[[Arquivo:arquitetura-padroes-tecnicos.png]]

Adicionalmente, as seguintes Features Java EE 7 poderão ser utilizadas:
* Bean Validation
* EJB (Enterprise JavaBeans)
* JavaMail (JavaMail API)
* JAX-RS (Java API for RESTful Web Services)
* JAX-WS (Java API para Web services XML)
* JTA (Java Transaction API)
* JPA (Java Persistence API)
* CDI (Contexts and Dependency Injection for Java EE)
* JSON-P (Java API for JSON Processing)

Mudanças nos padrões técnicos e nas versões de tecnologias podem levar a mudanças no sistema computacional.

==PA02 – Navegadores oficiais==
Para as funcionalidades do sistema funcionarem de forma adequada, é necessário usar um navegador da web homologado pela equipe de desenvolvimento. As versões suportadas de navegadores da web para este projeto são as seguintes:
* Internet Explorer 11 ou superior
* Google Chrome 42 ou superior
* Firefox versão 45 ou superior

Versões de navegadores não homologadas podem apresentar resultados imprevisíveis.

==PA03 – Automatização dos testes==
Crie scritps automáticos para testar unidades individuais de código fonte afim de mostrar que cada unidade atende corretamente sua especificação. Unidades podem ser métodos, classes, módulos, etc. Dependerá muito do que é a menor parte do sistema que pode ser testada.

Crie scripts automáticos para testar a combinação das unidades em conjunto. Tais scripts devem emular a interação do usuário em usar as diversas funcionalidades consideradas centrais do sistema para confirmar as principais funcionalidades fazem o esperado.

Fique atento ao fato de que é necessário rever e atualizar os scripts de teste para evitar resultados errados na hora da execução automática.

Considere que não é possível substituir todos os testes manuais por automáticos pois testes manuais também são importantes para encontrar falhas que simulam ambiente real e ações que só pessoas podem ser capazes de fazer no sistema.

==PA04 – Reutilização e simplicidade de componentes==
A arquitetura do sistema deve ser desenvolvida considerando componentes reutilizáveis, modulares e de baixo acoplamento que implementam serviços bem definidos.

Ela deve ser o mais simples possível de manter, mas atendendo a todos os requisitos de negócios e corporativos. Sempre que complexidade for necessária, ela deve ser encapsulada para promover a simplicidade das soluções desenvolvidas.

==PA05 – Sistema fácil de usar==
O sistema deve ser fácil de usar, intuitivo e seguir um padrão de identidade visual, com aparência e layouts uniformes.

A tecnologia computacional deve ser transparente para os usuários, portanto, permitir que eles concentrem-se nas suas tarefas em vez de preocupar-se com questões relativas à tecnologia.

==PA06 – Segurança de informações==
As informações devem ser protegidas com base na integridade, disponibilidade, confidencialidade, incontestabilidade e autenticidade. Cada informação deve ser submetida a uma avaliação de segurança com base nesses cinco fatores.

A rastreabilidade de segurança inclui a concepção e aplicação adequadas do sistema de auditoria e das ferramentas de monitoramento.

O compartilhamento e a divulgação abertos de informações devem ser balanceados com a necessidade de restringir a disponibilidade de informações confidenciais, proprietárias e sensíveis.

Atentar que as leis e regulamentos atuais podem exigir privacidade de dados e, simultaneamente, permitir acesso livre e sem restrição. Informações temporárias (massas de teste) devem ser protegidas para evitar especulação injustificada, erros de interpretação e uso impróprio.

==PA07 – Mudanças com base em requisitos==
Mudanças em sistemas e tecnologias serão implementadas apenas para atender a necessidades de negócios.

Mudanças de tecnologia podem criar oportunidades para melhorar o processo de negócios e, consequentemente, alterar as necessidades de negócios.

O desenvolvimento do sistema ou melhoria técnica não será implementada a menos que haja uma necessidade de negócio associada.

Uma necessidade de negócio deve ser considerada, mas deve também ser alinhada com outros princípios de arquitetura e/ou direcionadores de TI. Deve haver um equilíbrio entre necessidades de negócio e operações de TI.

==PA08 – Aderência a domínios funcionais==
As regras de negócios e funcionalidade do sistema são consistentes com a finalidade/missão deste sistema. Deverá haver uma aderência completa ao domínio funcional em que o sistema está localizado.

Cada nova solicitação de funcionalidade deve ser avaliada, conjuntamente, pelo Product Owner, consultor do negócio e gestor do contrato do projeto.

==PA09 – Interfaces de baixo acoplamento==
As interfaces de comunicação devem ter baixo acoplamento, possuir descrição própria e oferecer baixo impacto sobre os sistemas computacionais envolvidos em caso de mudanças.

Baixo acoplamento significa que os serviços (APIs corporativas, por exemplo) são criados sem uma afinidade com certo consumidor do serviço. Portanto, o serviço é totalmente desacoplado de um consumidor.

O serviço também é responsável pelo tratamento de exceção. O resultado é uma arquitetura de baixo acoplamento.

Arquitetura do Sistema - Requisitos Não Funcionais

2018-03-19T17:34:13Z

Tgmoraes: Criou página com 'Os Requerimentos não funcionais remetem a aspectos que, embora não afetem diretamente as funcionalidades do sistema sob a ótica de negócio dos usuários, pode ter um profu...'

Os Requerimentos não funcionais remetem a aspectos que, embora não afetem diretamente as funcionalidades do sistema sob a ótica de negócio dos usuários, pode ter um profundo efeito na forma como o sistema é aceito pelos usuários e pessoas que dão suporte ao sistema.

Em outras palavras, os requisitos não funcionais são aqueles que declaram restrições e se relacionam aos padrões de qualidade e definem se o sistema será eficiente e adequado para a tarefa que se propõe a fazer. Ao contrário dos requisitos funcionais, não determinam as funções a serem realizadas pelos sistemas de software, mas os comportamentos e restrições que ele deve satisfazer.

A seguir apresentamos os requisitos não funcionais definidos para o sistema em questão, bem como, as diretrizes para satisfazer esses requisitos.

{| class="wikitable"
! colspan="2" style="font-weight: bold;" | Requisito Não-Funcional
! style="font-weight: bold;" | Diretrizes
|-
| style="font-weight: bold;" | RNF001
| O acesso à informação dos doadores e pacientes no sistema, bem como a transmissão destas informações para outros sistemas deve ser permitido somente a usuários autorizados. Tais informações devem ser protegidas contra modificação ou destruição acidental.
|
* O controle de acesso ao sistema será baseado em papéis que determinará os privilégios de cada usuário.
* As ações sobre as informações de paciente e doadores tomadas pelo usuário para modificá-las serão registradas em um log de auditoria.
|-
| style="font-weight: bold;" | RNF002
| Todo o processo de envio, reenvio e recebimento de arquivos no sistema deverá ser logado.
|
* Os logs serão gravados em arquivo texto, no sistema de arquivos onde o sistema está hospedada.
|-
| style="font-weight: bold;" | RNF003
| A interface gráfica do usuário do sistema deverá ser apresentada nos idiomas Português Brasileiro, Inglês e Espanhol.
|
* Será utilizado um mecanismo de internacionalização (i18N) e Localização (l10N) que possibilite o compartilhamento destes conteúdos entre essas camadas do sistema.
* Para camada de apresentação: atributos i18n e TranslationProvider.
* Para camada de aplicação e acesso a dados: MessageSources do Spring MVC.
|}

Arquitetura do Sistema - Visão Geral

2018-03-19T17:25:21Z

Tgmoraes:

==Contexto do Projeto==
A Fundação Ary Frauzino pretende com este projeto aumentar o controle e capacidade de monitoramento de todo o processo de doação e colocar o registro nacional de doadores em um patamar internacional de qualidade.

O presente projeto consiste no desenvolvimento de um sistema computacional especializado e em conformidade com as exigências técnicas estabelecidas pela ''World Marrow Donor Association'' no documento intitulado ''International Standards for Unrelated Haematopoietic Stem Cell Donor Registries'', versão de 1 de janeiro de 2017, também denominado como '''WMDA Standards'''.

Este sistema computacional especializado será uma aplicação web e que poderá ser acessado de qualquer lugar desde que se tenha um ponto de acesso a Internet disponível.

Atualmente a Fundação Ary Frauzino conta com um conjunto de sistemas legado para o atendimento aos processos de Doação de Medula Óssea e Cordão Umbilical. Tais processos, além de não estarem totalmente integrados, estão intercalados com muitos procedimentos manuais, e tarefas burocráticas que a impedem de atingir o máximo de sua capacidade.

[[Arquivo:arquitetura-sistemas-legados-fundacao.png]]

Este conjunto de sistemas são responsáveis por gerir, aproximadamente, 4 milhões de doadores de medula óssea, 1.400 pacientes em ativos, isto é, pacientes que se encontram em alguma etapa do processo para receber células tronco. O registro brasileiro de doadores de medula óssea é o terceiro maior registro de doadores do mundo.

O desenvolvimento deste sistema computacional especializado pretende reduzir progressivamente o uso das funcionalidades dos atuais sistemas legado em favor das funcionalidades disponíveis na nova plataforma. No entanto, há funções que não serão tratadas por este sistema computacional especializado e, portanto, permanecerão no sistema legado.

A figura a seguir mostra uma visão geral da fronteira deste sistema computacional especializado no contexto da Fundação Ary Frauzino, bem como sua relação e interfaces com as entidades externas.

[[Arquivo:arquitetura-fronteiras-novo-redome.png|800px]]

Note que as entidades externas presentes neste diagrama representam sistemas, pessoas, empresas ou outras partes elementares definidas como fontes ou destinos de algum fluxo de dados relacionado a este sistema computacional especializado. Na seção a seguir, apresentamos os processos de negócio considerados neste projeto.

==Processos de Negócio==

A Fundação Ary Frauzino apoia o Instituto Nacional de Câncer (Inca) em vários processos relacionados a transplante de medula óssea e sangue de cordão umbilical. O sistema computacional especializado, objeto deste projeto, limita-se a oferecer funções específicas para operação contínua de dois desses processos de negócio. São eles: (1) '''Doação de Medula Óssea''' e (2) '''Doação de Cordão Umbilical'''. Os diagramas a seguir apresentam cada uma das etapas desses processos.

Esses dois processos de negócio cobrem o conjunto de atividades ou tarefas estruturadas relacionadas ao cadastro de doadores e receptores de medula óssea, cadastro de cordão umbilical, motor de Identificação de doador compatível e registro de ocorrência de procedimentos de transplantes de medula óssea. Eles são as referências para definição da lista de funcionalidades para o sistema computacional especializado. Esta lista de funcionalidades, denominada por ''Product Backlog'', será priorizada pelo ''Product Owner'' juntamente com a equipe do projeto, considerando o que é possível ser implementado durante cada iteração (Sprint) e, as restrições e necessidades para manter uma convivência adequada com os sistemas legados.

===Processo de Doação de Medula Óssea===

[[Arquivo:arquitetura-processo-medula-ossea.png|1024px]]

===Processo de Doação de Cordão Umbilical===

[[Arquivo:arquitetura-processo-cordao-umbilical.png|1024px]]

==Estrutura do Sistema==
O sistema computacional especializado será organizado segundo um modelo em três camadas (3-Tier) lógicas: camada de apresentação, camada de aplicação e camada de dados. Ele irá funcionar de maneira que os componentes de software executados em cada camada possam ser substituídos sem prejuízo para o sistema, de modo que atualizações e correções de defeitos possam ser feitas sem prejudicar as demais camadas. A título de exemplo, alterações de interface devem poder ser realizadas sem o comprometimento das informações contidas no banco de dados.

[[Arquivo:arquitetura-visao-geral-camadas.png|1024px]]

A seguir é apresentada uma breve descrição de cada uma dessas camadas do sistema:

# '''Apresentação:''' esta camada aqui denominada ''front-end'' ou simplesmente ''interface''. Ela compreende os componentes responsáveis pela interface de interação com os usuários do sistema. Esses usuários podem ser internos e externos à Fundação Ary Frauzino e terão acesso ao sistema por meio de navegadores web.
# '''Aplicação:''' nesta camada denominada ''back-end'' é onde residem as regras e lógicas de negócio para atendimentos aos requisitos. Esta camada será composta por um servidor de aplicações Java e um componente analítico para atendimento aos requisitos de elaboração de dashboards, indicadores e relatórios.
# '''Acesso a dados:''' Esta camada é responsável pelo armazenamento permanente dos dados e informações e seguirá o atual padrão da Fundação Ary Frauzino e do Inca, os quais utilizam a tecnologia de banco de dados relacional Oracle.

==Componentes de Software==
Componente de software é aqui denominado como uma não-trivial, quase independente, e substituível parte de um sistema e que cumpre uma função clara e bem definida no contexto da solução computacional. Ele não é necessariamente uma tecnologia implementada especificamente e nem a aplicação, mas sim uma unidade independente, que pode ser utilizado com outros componentes para formar um sistema mais complexo.

A arquitetura do sistema computacional especializado objeto deste projeto possui componentes funcionais e lógicos com interfaces bem definidas, usadas para comunicação entre esses componentes.

[[Arquivo:arquitetura-componentes.png|1024px]]

A função de cada um desses componentes de software é apresentada a seguir:

{| class="wikitable"
!
! style="font-weight: bold;" | Componente
! style="font-weight: bold;" | Função
! style="font-weight: bold;" | Observações
|-
| style="font-weight: bold;" | 1
| Navegador Web, (thin client)
| Habilitar os usuários a interagirem com documentos HTML hospedados no servidor Web/Aplicação do sistema.
|
* O acesso ao sistema, tanto para usuários internos ou externos, será por meio denavegadores web.
* A aplicação estará aderente a determinado conjunto de navegadores, com versõesespecíficas (vide seção “Restrições Técnicas” deste documento).
* A lógica de apresentação produzida em HTML5, CSS3 e JavaScript é executada em no próprio browser.
|-
| style="font-weight: bold;" | 2
| Email (EMEDYS)
| Habilitar outros registros Internacionais a efetuarem transações no sistema Brasil.
|
* O atual recebimento e interpretação derequisições EMEDYS via e-mail proveniente de outros países deverá ser mantido nosistema.
|-
| style="font-weight: bold;" | 3
| Firewall
| Aplicar as políticas de segurança para filtro de pacotes de dados de/para o sistema.
|
* Hoje o próprio Bluemix disponibiliza em seus componentes, o firewall necessário para controle de acesso a seu ambiente. Existem outras capacidades cobertas pela plataforma como segregação de ambientes e proteção contra ataques.
|-
| style="font-weight: bold;" | 4
| Java Liberty
| Habilitar um Servidor de aplicação Java na nuvem.
|
* A aplicação de backend JEE Application será responsável por encapsular as regras e lógicas de negócio, controlar o acesso aos dados e expor as funcionalidades como serviços e/ou componentes.
|-
| style="font-weight: bold;" | 5
| SMTP
| Suportar protocolo padrão para envio de e-mails através da Internet, padronizado pela RFC 821.
|
* Considerando que a atual integração do Redome com o servidor SMTP do INCA já é uma realidade para o funcionamento das requisições de transações “EMEDYS, a mesma solução técnica, poderá ser aproveitada como uma integração do sistema computacional que será desenvolvido.
|-
| style="font-weight: bold;" | 6
| Relatórios
| Habilitar a elaboração e publicação de relatórios e dashboards.
|
* Ambiente analítico também na Cloud permitirá a criação de dashboard para acompanhamento de indicadores, bem como a demanda de relatórios para os usuários.
|-
| style="font-weight: bold;" | 7
| Banco de Dados
| Permitir armazenamento dos dados da aplicação.
|
* Banco de dados relacional que permitirá a persistência dos dados do sistema computacional que será desenvolvido, levando em consideração todos os requisitos técnicos para Acreditação.
|-
| style="font-weight: bold;" | 8
| Servidor de Arquivos
| Permitir o armazenamento das requisições no formato EMEDYS.
|
* Servidor padrão de arquivos Linux.
|}

Arquitetura do Sistema - Visão Geral

2018-03-19T17:04:11Z

Tgmoraes:

A Fundação Ary Frauzino pretende com este projeto aumentar o controle e capacidade de monitoramento de todo o processo de doação e colocar o registro nacional de doadores em um patamar internacional de qualidade.

O presente projeto consiste no desenvolvimento de um sistema computacional especializado e em conformidade com as exigências técnicas estabelecidas pela ''World Marrow Donor Association'' no documento intitulado ''International Standards for Unrelated Haematopoietic Stem Cell Donor Registries'', versão de 1 de janeiro de 2017, também denominado como '''WMDA Standards'''.

Este sistema computacional especializado será uma aplicação web e que poderá ser acessado de qualquer lugar desde que se tenha um ponto de acesso a Internet disponível.

Atualmente a Fundação Ary Frauzino conta com um conjunto de sistemas legado para o atendimento aos processos de Doação de Medula Óssea e Cordão Umbilical. Tais processos, além de não estarem totalmente integrados, estão intercalados com muitos procedimentos manuais, e tarefas burocráticas que a impedem de atingir o máximo de sua capacidade.

[[Arquivo:arquitetura-sistemas-legados-fundacao.png]]

Este conjunto de sistemas são responsáveis por gerir, aproximadamente, 4 milhões de doadores de medula óssea, 1.400 pacientes em ativos, isto é, pacientes que se encontram em alguma etapa do processo para receber células tronco. O registro brasileiro de doadores de medula óssea é o terceiro maior registro de doadores do mundo.

O desenvolvimento deste sistema computacional especializado pretende reduzir progressivamente o uso das funcionalidades dos atuais sistemas legado em favor das funcionalidades disponíveis na nova plataforma. No entanto, há funções que não serão tratadas por este sistema computacional especializado e, portanto, permanecerão no sistema legado.

A figura a seguir mostra uma visão geral da fronteira deste sistema computacional especializado no contexto da Fundação Ary Frauzino, bem como sua relação e interfaces com as entidades externas.

[[Arquivo:arquitetura-fronteiras-novo-redome.png]]

Note que as entidades externas presentes neste diagrama representam sistemas, pessoas, empresas ou outras partes elementares definidas como fontes ou destinos de algum fluxo de dados relacionado a este sistema computacional especializado. Na seção a seguir, apresentamos os processos de negócio considerados neste projeto.

==Processos de Negócio==

A Fundação Ary Frauzino apoia o Instituto Nacional de Câncer (Inca) em vários processos relacionados a transplante de medula óssea e sangue de cordão umbilical. O sistema computacional especializado, objeto deste projeto, limita-se a oferecer funções específicas para operação contínua de dois desses processos de negócio. São eles: (1) '''Doação de Medula Óssea''' e (2) '''Doação de Cordão Umbilical'''. Os diagramas a seguir apresentam cada uma das etapas desses processos.

Esses dois processos de negócio cobrem o conjunto de atividades ou tarefas estruturadas relacionadas ao cadastro de doadores e receptores de medula óssea, cadastro de cordão umbilical, motor de Identificação de doador compatível e registro de ocorrência de procedimentos de transplantes de medula óssea. Eles são as referências para definição da lista de funcionalidades para o sistema computacional especializado. Esta lista de funcionalidades, denominada por ''Product Backlog'', será priorizada pelo ''Product Owner'' juntamente com a equipe do projeto, considerando o que é possível ser implementado durante cada iteração (Sprint) e, as restrições e necessidades para manter uma convivência adequada com os sistemas legados.

===Processo de Doação de Medula Óssea===

[[Arquivo:arquitetura-processo-medula-ossea.png]]

===Processo de Doação de Cordão Umbilical===

[[Arquivo:arquitetura-processo-cordao-umbilical.png]]

==Estrutura do Sistema==
O sistema computacional especializado será organizado segundo um modelo em três camadas (3-Tier) lógicas: camada de apresentação, camada de aplicação e camada de dados. Ele irá funcionar de maneira que os componentes de software executados em cada camada possam ser substituídos sem prejuízo para o sistema, de modo que atualizações e correções de defeitos possam ser feitas sem prejudicar as demais camadas. A título de exemplo, alterações de interface devem poder ser realizadas sem o comprometimento das informações contidas no banco de dados.

[[Arquivo:arquitetura-visao-geral-camadas.png]]

A seguir é apresentada uma breve descrição de cada uma dessas camadas do sistema:

# '''Apresentação:''' esta camada aqui denominada ''front-end'' ou simplesmente ''interface''. Ela compreende os componentes responsáveis pela interface de interação com os usuários do sistema. Esses usuários podem ser internos e externos à Fundação Ary Frauzino e terão acesso ao sistema por meio de navegadores web.
# '''Aplicação:''' nesta camada denominada ''back-end'' é onde residem as regras e lógicas de negócio para atendimentos aos requisitos. Esta camada será composta por um servidor de aplicações Java e um componente analítico para atendimento aos requisitos de elaboração de dashboards, indicadores e relatórios.
# '''Acesso a dados:''' Esta camada é responsável pelo armazenamento permanente dos dados e informações e seguirá o atual padrão da Fundação Ary Frauzino e do Inca, os quais utilizam a tecnologia de banco de dados relacional Oracle.

==Componentes de Software==
Componente de software é aqui denominado como uma não-trivial, quase independente, e substituível parte de um sistema e que cumpre uma função clara e bem definida no contexto da solução computacional. Ele não é necessariamente uma tecnologia implementada especificamente e nem a aplicação, mas sim uma unidade independente, que pode ser utilizado com outros componentes para formar um sistema mais complexo.

A arquitetura do sistema computacional especializado objeto deste projeto possui componentes funcionais e lógicos com interfaces bem definidas, usadas para comunicação entre esses componentes.

[[Arquivo:arquitetura-componentes.png]]

A função de cada um desses componentes de software é apresentada a seguir:

Arquivo:Arquitetura-componentes.png

2018-03-19T16:54:14Z

Tgmoraes:

Arquivo:Arquitetura-padroes-tecnicos.png

2018-03-19T16:53:24Z

Tgmoraes:

Arquivo:Arquitetura-pipeline-master.png

2018-03-19T16:52:37Z

Tgmoraes:

Arquivo:Arquitetura-pipeline-develop.png

2018-03-19T16:51:46Z

Tgmoraes:

Arquivo:Arquitetura-controle-acesso.png

2018-03-19T16:50:57Z

Tgmoraes:

Arquivo:Arquitetura-plataforma-cloud.png

2018-03-19T16:50:11Z

Tgmoraes:

Arquivo:Arquitetura-visao-geral-camadas.png

2018-03-19T16:49:17Z

Tgmoraes:

Arquivo:Arquitetura-processo-cordao-umbilical.png

2018-03-19T16:41:37Z

Tgmoraes:

Arquivo:Arquitetura-processo-medula-ossea.png

2018-03-19T16:40:44Z

Tgmoraes:

Arquivo:Arquitetura-fronteiras-novo-redome.png

2018-03-19T16:36:24Z

Tgmoraes:

Arquivo:Arquitetura-sistemas-legados-fundacao.png

2018-03-19T16:35:06Z

Tgmoraes:

Arquitetura do Sistema - Visão Geral

2018-03-19T16:33:51Z

Tgmoraes: Criou página com 'A Fundação Ary Frauzino pretende com este projeto aumentar o controle e capacidade de monitoramento de todo o processo de doação e colocar o registro nacional de doadores...'

Padrões de Desenvolvimento

2018-03-19T15:42:43Z

Tgmoraes:

Esta seção descreve as melhores práticas, ferramentas e orientações que são adotadas pela equipe de desenvolvimento do sistema Redome.

==Contrato Social da Equipe==
O contrato social é um acordo feito entre os membros da equipe de desenvolvimento do sistema Redome e tem a função de destabelecer boas práticas para o dia-a-dia de trabalho.
As diretrizes a seguir foram redijidas com os membros da equipe de desenvolvimento, e não representa uma obrigação, mas um comprometimento informal entre o time.

===Cerimônias===
# A daily scrum meeting conta com a presença de todo o Dev Team com 15 minutos de duração com o objetivo de compartilhar o trabalho e identificação de impedimentos
# Assegurar que todas as reuniões tenham uma agenda e que as ações sejam registradas
# Se você não puder participar ou precisar sair mais cedo de uma reunião, notifique a equipe antes
# Venha preparado para reuniões
# Seja pontual ( as reuniões começam no horário agendado independente da presença de todos )

===Fluxo de Trabalho===
# Se receber/pegar um trabalho, apropriar-se dele e mantê-lo atualizado
# Se você acha que precisa trabalhar até tarde para fazer o trabalho, acordar com o Scrum Master/GC

===Comunicação===
# Avise para o scrum master de forma imediata caso tenha um problema
# Respeitar um ao outro e compreender as diferenças de conhecimento
# Demonstrar respeito tanto com palavras quanto atitudes
# Todos os documentos da equipe devem ser compartilhados
# Não há perguntas tolas, se você não entender, pergunte
# Não faça inferências, pergunte
# Concentre-se nos aspectos positivos
# Respeitar quando outra pessoa do time estiver falando

== Padrões ==
=== Banco de Dados ===
Padronização de nomenclatura de estrutura de dados e diretrizes para a criação de qualquer objeto no banco de dados tal como tabelas, colunas, chaves primárias, estrangeiras, índices, dentre outros.

[ [[Padrão de Desenvolvimento - Banco de Dados|Mostrar Padrão]] ] 
=== Codificação ===
Convenções de codificação para o desenvolvimento do backend (Java) e frontend (Angular) do sistema Redome. Esse padrão define as regras de como o código-fonte deve ser escrito.

[ [[Padrão de Desenvolvimento - Codificação|Mostrar Padrão]] ] 
=== Documentação ===
Diretrizes para documentar o código-fonte de modo a explicar O QUE faz cada classe e método do sistema Redome. A documentação não pretende explicar COMO cada método faz o que faz, porque o desenvolvedor interessado nesse assunto deve ser capaz de ler o código-fonte.

[ [[Padrão de Desenvolvimento - Documentação|Mostrar Padrão]] ] 
=== Testes Unitários ===
Padrão para escrever os testes unitários automatizados e orientação para utilização da técnica de desenvolvimento dirigido por testes (TDD).

[ [[Padrão de Desenvolvimento - Testes Unitários|Mostrar Padrão]] ] 

== Arquitetura do Sistema: ==
Este seção detalha as diretrizes de arquitetura que nortearam o desenvolvimento do sistema e aprenta a visão geral da arquitetura da solução do Projeto de Modernização do Redome, expondo as perspectivas funcionais e não funcionais relacionadas à solução.

A arquitetura de sistemas é responsável por conceituar e representar os componentes de software, suas propriedades externas e relacionamentos, bem como os direcionadores que justificam sua existência dentro da solução proposta.

=== Visão Geral ===
Esta seção descreve o contexto do projeto, os processos de negócio envolvidos e detalha como o sistema computacional está organizado em termos de seus componentes de software.

[ [[Arquitetura do Sistema - Visão Geral|Ler Mais]] ] 

=== Requisitos não funcionais ===
Os Requerimentos não funcionais remetem a aspectos que, embora não afetem diretamente as funcionalidades do sistema sob a ótica de negócio dos usuários, pode ter um profundo efeito na forma como o sistema é aceito pelos usuários e pessoas que dão suporte ao sistema.

[ [[Arquitetura do Sistema - Requisitos Não Funcionais|Ler Mais]] ] 

=== Princípios de Arquitetura ===
Nesta seção estão descritos os princípios de arquitetura para o sistema computacional objeto deste projeto. Tais princípios são definições de alto nível de valores fundamentais, regras gerais e diretrizes que orientam o processo de tomada de decisões técnicas, servindo de base para a arquitetura e desenvolvimento deste sistema.

[ [[Arquitetura do Sistema - Princípios de Arquitetura|Ler Mais]] ] 

=== Modelo Operacional ===
O modelo operacional tem por objetivo definir e documentar a forma como os componentes do sistema serão desenvolvidos e distribuídos em nós, junto com as conexões necessárias para suportar as interações requeridas por estes, de forma a atender os requerimentos funcionais e não funcionais da solução, considerando as restrições de tecnologia.

[ [[Arquitetura do Sistema - Modelo Operacional|Ler Mais]] ] 

=== Decisões de Arquitetura ===
Esta seção reune e apresentar as decisões arquiteturais relacionadas ao projeto, detalhando as razões e justificativas que motivaram cada decisão.

[ [[Arquitetura do Sistema - Decisões de Arquitetura|Ler Mais]] ] 

== Ferramentas & Frameworks para: ==
A seguir estão detalhadas as ferramentas utilizadas no processo de desenvolvimento do sistema Redome.
=== Realizar Teste de Software ===
[ [[Ferramentas & Frameworks - Realizar Teste de Software|Ler Mais]] ] 

== Orientações para: ==
=== Configurar o ambiente de desenvolvimento ===

[ [[Orientação - Configurar o ambiente de desenvolvimento|Mostrar Orientação]] ] 

=== Controlar as mudanças feitas no código (GIT) ===

[ [[Orientação - Controlar as mudanças feitas no código|Mostrar Orientação]] ] 

=== Realizar a revisão do código-fonte ===

[ [[Orientação - Realizar a revisão do código-fonte|Mostrar Orientação]] ] 

=== Organizar a estrutura do código-fonte===

[ [[Orientação - Organizar a estrutura do código-fonte|Mostrar Orientação]] ] 

=== Efetuar correções de bugs em produção/homologação ===

[ [[Orientação - Efetuar correções de bugs em produção ou homologação|Mostrar Orientação]] ] 

=== Como acessar o Build Pipeline ===

[ [[Orientação - Como acessar o Build Pipeline|Mostrar Orientação]] ] 

=== Configurar container Kubernete da Wiki Redome ===

[ [[Orientação - Configurar container Kubernete da Wiki Redome|Mostrar Orientação]] ]

Padrões de Desenvolvimento

2018-03-19T15:40:51Z

Tgmoraes:

Esta seção descreve as melhores práticas, ferramentas e orientações que são adotadas pela equipe de desenvolvimento do sistema Redome.

==Contrato Social da Equipe==
O contrato social é um acordo feito entre os membros da equipe de desenvolvimento do sistema Redome e tem a função de destabelecer boas práticas para o dia-a-dia de trabalho.
As diretrizes a seguir foram redijidas com os membros da equipe de desenvolvimento, e não representa uma obrigação, mas um comprometimento informal entre o time.

===Cerimônias===
# A daily scrum meeting conta com a presença de todo o Dev Team com 15 minutos de duração com o objetivo de compartilhar o trabalho e identificação de impedimentos
# Assegurar que todas as reuniões tenham uma agenda e que as ações sejam registradas
# Se você não puder participar ou precisar sair mais cedo de uma reunião, notifique a equipe antes
# Venha preparado para reuniões
# Seja pontual ( as reuniões começam no horário agendado independente da presença de todos )

===Fluxo de Trabalho===
# Se receber/pegar um trabalho, apropriar-se dele e mantê-lo atualizado
# Se você acha que precisa trabalhar até tarde para fazer o trabalho, acordar com o Scrum Master/GC

===Comunicação===
# Avise para o scrum master de forma imediata caso tenha um problema
# Respeitar um ao outro e compreender as diferenças de conhecimento
# Demonstrar respeito tanto com palavras quanto atitudes
# Todos os documentos da equipe devem ser compartilhados
# Não há perguntas tolas, se você não entender, pergunte
# Não faça inferências, pergunte
# Concentre-se nos aspectos positivos
# Respeitar quando outra pessoa do time estiver falando

== Padrões ==
=== Banco de Dados ===
Padronização de nomenclatura de estrutura de dados e diretrizes para a criação de qualquer objeto no banco de dados tal como tabelas, colunas, chaves primárias, estrangeiras, índices, dentre outros.

[ [[Padrão de Desenvolvimento - Banco de Dados|Mostrar Padrão]] ] 
=== Codificação ===
Convenções de codificação para o desenvolvimento do backend (Java) e frontend (Angular) do sistema Redome. Esse padrão define as regras de como o código-fonte deve ser escrito.

[ [[Padrão de Desenvolvimento - Codificação|Mostrar Padrão]] ] 
=== Documentação ===
Diretrizes para documentar o código-fonte de modo a explicar O QUE faz cada classe e método do sistema Redome. A documentação não pretende explicar COMO cada método faz o que faz, porque o desenvolvedor interessado nesse assunto deve ser capaz de ler o código-fonte.

[ [[Padrão de Desenvolvimento - Documentação|Mostrar Padrão]] ] 
=== Testes Unitários ===
Padrão para escrever os testes unitários automatizados e orientação para utilização da técnica de desenvolvimento dirigido por testes (TDD).

[ [[Padrão de Desenvolvimento - Testes Unitários|Mostrar Padrão]] ] 

== Arquitetura do Sistema: ==
Este seção detalha as diretrizes de arquitetura que nortearam o desenvolvimento do sistema e aprenta a visão geral da arquitetura da solução do Projeto de Modernização do Redome, expondo as perspectivas funcionais e não funcionais relacionadas à solução.

A arquitetura de sistemas é responsável por conceituar e representar os componentes de software, suas propriedades externas e relacionamentos, bem como os direcionadores que justificam sua existência dentro da solução proposta.

=== Visão Geral ===
Esta seção descreve o contexto do projeto, os processos de negócio envolvidos e detalha como o sistema computacional está organizado em termos de seus componentes de software.

[ [[Arquitetura do Sistema - Visão Geral|Mostrar Padrão]] ] 

=== Requisitos não funcionais ===
Os Requerimentos não funcionais remetem a aspectos que, embora não afetem diretamente as funcionalidades do sistema sob a ótica de negócio dos usuários, pode ter um profundo efeito na forma como o sistema é aceito pelos usuários e pessoas que dão suporte ao sistema.

[ [[Arquitetura do Sistema - Requisitos Não Funcionais|Mostrar Padrão]] ] 

=== Princípios de Arquitetura ===
Nesta seção estão descritos os princípios de arquitetura para o sistema computacional objeto deste projeto. Tais princípios são definições de alto nível de valores fundamentais, regras gerais e diretrizes que orientam o processo de tomada de decisões técnicas, servindo de base para a arquitetura e desenvolvimento deste sistema.

[ [[Arquitetura do Sistema - Princípios de Arquitetura|Mostrar Padrão]] ] 

=== Modelo Operacional ===
O modelo operacional tem por objetivo definir e documentar a forma como os componentes do sistema serão desenvolvidos e distribuídos em nós, junto com as conexões necessárias para suportar as interações requeridas por estes, de forma a atender os requerimentos funcionais e não funcionais da solução, considerando as restrições de tecnologia.

[ [[Arquitetura do Sistema - Modelo Operacional|Mostrar Padrão]] ] 

=== Decisões de Arquitetura ===
Esta seção reune e apresentar as decisões arquiteturais relacionadas ao projeto, detalhando as razões e justificativas que motivaram cada decisão.

[ [[Arquitetura do Sistema - Decisões de Arquitetura|Mostrar Padrão]] ] 

== Ferramentas & Frameworks para: ==
A seguir estão detalhadas as ferramentas utilizadas no processo de desenvolvimento do sistema Redome.
=== Realizar Teste de Software ===
[ [[Ferramentas & Frameworks - Realizar Teste de Software|Ler Mais]] ] 

== Orientações para: ==
=== Configurar o ambiente de desenvolvimento ===

[ [[Orientação - Configurar o ambiente de desenvolvimento|Mostrar Orientação]] ] 

=== Controlar as mudanças feitas no código (GIT) ===

[ [[Orientação - Controlar as mudanças feitas no código|Mostrar Orientação]] ] 

=== Realizar a revisão do código-fonte ===

[ [[Orientação - Realizar a revisão do código-fonte|Mostrar Orientação]] ] 

=== Organizar a estrutura do código-fonte===

[ [[Orientação - Organizar a estrutura do código-fonte|Mostrar Orientação]] ] 

=== Efetuar correções de bugs em produção/homologação ===

[ [[Orientação - Efetuar correções de bugs em produção ou homologação|Mostrar Orientação]] ] 

=== Como acessar o Build Pipeline ===

[ [[Orientação - Como acessar o Build Pipeline|Mostrar Orientação]] ] 

=== Configurar container Kubernete da Wiki Redome ===

[ [[Orientação - Configurar container Kubernete da Wiki Redome|Mostrar Orientação]] ]

Página principal

2018-02-21T11:50:14Z

Tgmoraes:

== Bem Vindo! ==
Este espaço reune conhecimentos sobre a Plataforma Tecnológica Redome. A informação aqui disponível é a referência oficial para promover a capacitação de colaboradores, dirimir dúvidas e comunicar os padrões técnicos e metodológicos adotados na plataforma.

=== Por onde você quer começar ? ===

<gallery>
File:User-manual.png|link=Manual de Usuário|Manual de Usuário
File:Standards.png|link=Padrões de Desenvolvimento|Padrões de Desenvolvimento
File:Standards.png|link=Metodologia de Trabalho|Metodologia de Trabalho
File:Tips-wiki.jpg|link=Benefícios da Plataforma|Benefícios da Plataforma
File:Tips-wiki.jpg|Dicas Wiki|link=http://meta.wikimedia.org/wiki/Help:Contents
</gallery>

Padrões de Desenvolvimento

2017-12-29T16:06:32Z

Tgmoraes:

Página principal

2017-12-29T15:56:48Z

Tgmoraes:

== Bem Vindo! ==
Este espaço reune conhecimentos sobre a Plataforma Tecnológica Redome. A informação aqui disponível é a referência oficial para promover a capacitação de colaboradores, dirimir dúvidas e comunicar os padrões técnicos e metodológicos adotados na plataforma.

=== Por onde você quer começar ? ===

<gallery>
File:User-manual.png|link=Manual de Usuário|Manual de Usuário
File:Standards.png|link=Padrões de Desenvolvimento|Padrões de Desenvolvimento
File:Standards.png|link=Metodologia de Trabalho|Metodologia de Trabalho
File:Tips-wiki.jpg|Benefícios da Plataforma|Benefícios da Plataforma
File:Tips-wiki.jpg|Dicas Wiki|link=http://meta.wikimedia.org/wiki/Help:Contents
</gallery>

Metodologia de Trabalho

2017-12-29T15:43:11Z

Tgmoraes: Criou página com '==Cerimônias== ===Planejamento e priorização do backlog (Grooming)=== ===Planejamento da Interação (Sprint)=== ===Review/Demo=== ===Retrospectiva=== ===Daily meeting ==='

==Cerimônias==
===Planejamento e priorização do backlog (Grooming)===
===Planejamento da Interação (Sprint)===
===Review/Demo===
===Retrospectiva===
===Daily meeting ===

Página principal

2017-12-29T15:39:08Z

Tgmoraes:

== Bem Vindo! ==
Este espaço reune conhecimentos sobre a Plataforma Tecnológica Redome. A informação aqui disponível é a referência oficial para promover a capacitação de colaboradores, dirimir dúvidas e comunicar os padrões técnicos e metodológicos adotados na plataforma.

=== Por onde você quer começar ? ===

<gallery>
File:User-manual.png|link=Manual de Usuário|Manual de Usuário
File:Standards.png|link=Padrões de Desenvolvimento|Padrões de Desenvolvimento
File:Standards.png|link=Metodologia de Trabalho|Metodologia de Trabalho
File:Tips-wiki.jpg|Dicas Wiki|link=http://meta.wikimedia.org/wiki/Help:Contents
</gallery>

Orientação - Configurar container Kubernete da Wiki Redome

2017-12-17T22:48:16Z

Tgmoraes:

Toda a documentação da plataforma Redome é mantida no presente portal, o qual é uma instância de um pacote de software livre e código aberto (escrito em PHP) para wikis denominado MediaWiki. Este ambiente de documentação opera dentro de um container Linux que é gerenciado com tecnologia Kubernetes, o qual é uma plataforma open source que automatiza as operações dos containers. Kubernetes implementa todos os mecanismos de alta disponibilidade, isolamento e alta performance de clusters tradicionais.

==Comandos básicos==
'''Iniciar cluster:'''
bx cs init

'''Configurar variável de ambiente:'''
export KUBECONFIG=/root/.bluemix/plugins/container-service/clusters/mycluster/kube-config-dal10-mycluster.yml

'''Listar os clusters disponíveis'''
bx cs clusters

'''Obter informação detalhada da configuração de um cluster
bx cs cluster-get [cluster name]

'''Listar as images de containers docker disponíveis para uso'''
bx cr images

'''Listar os deployments publicados em um cluster'''
kubectl get deployments [cluster name]

'''Listar os pods publicados em um cluster'''
kubectl get pods [cluster name]

'''Listar os serviços publicados em cluster'''
bx cs cluster-services [cluster name]

'''Acessar a configuracao do volume de armazenamento da wiki
kubectl describe pvc fcancer-pvc-file-bronze

'''Criar/Atualizar a configuração de um deployment/pod/serviço/volume
kubectl apply -f [arquivo.yaml]

'''Remover a configuração de um deployment/pod/serviço/volume
kubectl delete -f [arquivo.yaml]

==Acessar via FTP os locais de armazenamento da wiki==
Todo conteúdo publicado nesta wiki é armazenado em um sistema de arquivos NFS. A rigor, o conteúdo das páginas são gravados em um bando de dados (SQLite). O SQLite é software livre de domínio público e multiplataforma que implementa um mecanismo de armazenamento seguro com transações ACID. Este SGBD suporta bases de dados de até 2 terabytes.

Os arquivos do SQLite estão armazenados no seguinte diretório:

/data/

Os arquivos carregados na wiki por meio do processo de upload (ex. imagens) também são armazenados no sistema de arquivos NFS, no entanto, no seguinte diretório:

/images/

Para ter acesso ao sistema de arquivos NFS, é necessário utilizar um cliente FTP, em modo ativo. Utilize as credenciais a seguir:

Servidor: 169.60.198.125
Login: admin
Password: passw0rd

==Acessar via Shell o container operacional da wiki==
Para abrir um shell para o container aonde estão os arquivos de instalação da wiki, basta executar o comando a seguir:

kubectl exec -it <pod-name> -- /bin/bash

==Atualizar a imagem do logo da wiki==
Por padrão, o mediawiki mostra como logo a imagem que está localizada dentro do diretório de instalação da wiki. Na instalação deste portal, o caminho para esta imagem é o seguinte:

/var/www/mediawiki/resources/assets/wiki.png

Caso seja preciso recriar/atualizar o container com a imagem docker do mediawiki (wiki-deployment.yaml), então será necessário atualizar a logo do Redome na wiki. A imagem do logo do Redome fica amazenada no seguinte diretório do sistema de arquivos NFS:

/images/wiki.png

Para informar a wiki que esta é imagem que deve ser colocada no logo, basta criar um link simbólico entre a imagem padrão e a imagem do logo do Redome. Para isso, acesse o container utilizando o seguinte comando:

kubectl exec -it <pod-name> -- /bin/bash

E para criar o link simbólico, execute o comando a seguir:

ln -sf /images/wiki.png /var/www/mediawiki/resources/assets/wiki.png

==Arquivos YAML para configuração da wiki no Kubernete==
===Criar o volume para armazenamento de dados (SQLLite)===
Nome do arquivo: wiki-data-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wiki-claim-data
labels:
app: mediawiki
io.kompose.service: wiki-claim-data
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi

===Criar o volume para armazenamento das imagens===
Nome do arquivo: wiki-images-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wiki-claim-images
labels:
app: mediawiki
io.kompose.service: wiki-claim-images
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi

===Ativar o serviço FTP no container===
Nome do arquivo: wiki-ftp.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: ftp
name: ftp
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
creationTimestamp: null
labels:
app: ftp
spec:
containers:
- env:
- name: FTP_USER
value: admin
- name: FTP_PASS
value: passw0rd
- name: PASV_ADDRESS
value: 169.60.198.125
image: bogem/ftp
name: ftp
ports:
- containerPort: 20
- containerPort: 21
resources: {}
volumeMounts:
- mountPath: /home/vsftpd/images
name: wiki-claim-images
- mountPath: /home/vsftpd/data
name: wiki-claim-data
restartPolicy: Always
volumes:
- name: wiki-claim-images
persistentVolumeClaim:
claimName: wiki-claim-images
- name: wiki-claim-data
persistentVolumeClaim:
claimName: wiki-claim-data
status: {}
---
apiVersion: v1
kind: Service
metadata:
name: ftp
spec:
type: LoadBalancer
ports:
- name: "20"
port: 20
targetPort: 20
- name: "21"
port: 21
targetPort: 21
selector:
app: ftp

===Publicar o container com imagem docker do mediawiki===
Nome do arquivo: wiki-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose.yml
kompose.version: 1.5.0 ()
creationTimestamp: null
labels:
io.kompose.service: wiki
name: wiki
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
creationTimestamp: null
labels:
io.kompose.service: wiki
spec:
containers:
- env:
- name: MEDIAWIKI_DB_NAME
value: wikidb
- name: MEDIAWIKI_DB_TYPE
value: sqlite
- name: MEDIAWIKI_DEBUG
value: "1"
- name: MEDIAWIKI_DEFAULT_SKIN
value: vector
- name: MEDIAWIKI_ENABLE_UPLOADS
value: "1"
- name: MEDIAWIKI_ENABLE_VISUAL_EDITOR
value: "1"
- name: MEDIAWIKI_LANGUAGE_CODE
value: pt-br
- name: MEDIAWIKI_SERVER
value: http://mycluster-824593.us-south.containers.mybluemix.net
- name: MEDIAWIKI_SITENAME
value: Redome
- name: MEDIAWIKI_SMTP
value: "1"
- name: MEDIAWIKI_SMTP_HOST
value: "smtp.gmail.com"
- name: MEDIAWIKI_SMTP_IDHOST
value: "gmail.com"
- name: MEDIAWIKI_SMTP_PORT
value: "587"
- name: MEDIAWIKI_SMTP_AUTH
value: "1"
- name: MEDIAWIKI_SECRET_KEY
value: "cef7f7518e429c9a91ab4800d7e1f6fd95e726a3769e9927b51719d2a87eebf3"
- name: MEDIAWIKI_SMTP_USERNAME
value: "mod.redome@cancer.org.br"
- name: MEDIAWIKI_SMTP_PASSWORD
value: "C@ncer2017."
image: kristophjunge/mediawiki
name: wiki
ports:
- containerPort: 80
resources: {}
volumeMounts:
- mountPath: /images
name: wiki-claim-images
- mountPath: /data
name: wiki-claim-data
restartPolicy: Always
volumes:
- name: wiki-claim-images
persistentVolumeClaim:
claimName: wiki-claim-images
- name: wiki-claim-data
persistentVolumeClaim:
claimName: wiki-claim-data
status: {}

===Ativar o serviço HTTP no container===
Nome do arquivo: wiki-service.yaml

apiVersion: v1
kind: Service
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose.yml
kompose.version: 1.5.0 ()
creationTimestamp: null
labels:
io.kompose.service: wiki
name: wiki
spec:
ports:
- name: "80"
port: 80
targetPort: 80
selector:
io.kompose.service: wiki
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: mediawiki-ingress
spec:
rules:
- host: mycluster-824593.us-south.containers.mybluemix.net
http:
paths:
- path: /
backend:
serviceName: wiki
servicePort: 80

== Material Complementar ==
# [https://console.bluemix.net/docs/containers/cs_cli_install.html#cs_cli_install| Configurando a CLI e API], IBM Cloud, 2017.
# [https://console.bluemix.net/docs/containers/cs_cluster.html#cs_cluster| Configurando clusters], IBM Cloud, 2017.
# [https://console.bluemix.net/docs/containers/cs_apps.html| Implementando apps em clusters],IBM Cloud, 2017.

Orientação - Configurar container Kubernete da Wiki Redome

2017-12-17T22:44:45Z

Tgmoraes:

Toda a documentação da plataforma Redome é mantida no presente portal, o qual é uma instância de um pacote de software livre e código aberto (escrito em PHP) para wikis denominado MediaWiki. Este ambiente de documentação opera dentro de um container Linux que é gerenciado com tecnologia Kubernetes, o qual é uma plataforma open source que automatiza as operações dos containers. Kubernetes implementa todos os mecanismos de alta disponibilidade, isolamento e alta performance de clusters tradicionais.

==Comandos básicos==
'''Iniciar cluster:'''
bx cs init

'''Configurar variável de ambiente:'''
export KUBECONFIG=/root/.bluemix/plugins/container-service/clusters/mycluster/kube-config-dal10-mycluster.yml

'''Listar os clusters disponíveis'''
bx cs clusters

'''Obter informação detalhada da configuração de um cluster
bx cs cluster-get [cluster name]

'''Listar as images de containers docker disponíveis para uso'''
bx cr images

'''Listar os deployments publicados em um cluster'''
kubectl get deployments [cluster name]

'''Listar os pods publicados em um cluster'''
kubectl get pods [cluster name]

'''Listar os serviços publicados em cluster'''
bx cs cluster-services [cluster name]

'''Acessar a configuracao do volume de armazenamento da wiki
kubectl describe pvc fcancer-pvc-file-bronze

'''Criar/Atualizar a configuração de um deployment/pod/serviço/volume
kubectl apply -f [arquivo.yaml]

'''Remover a configuração de um deployment/pod/serviço/volume
kubectl delete -f [arquivo.yaml]

==Acessar via FTP os locais de armazenamento da wiki==
Todo conteúdo publicado nesta wiki é armazenado em um sistema de arquivos NFS. A rigor, o conteúdo das páginas são gravados em um bando de dados (SQLite). O SQLite é software livre de domínio público e multiplataforma que implementa um mecanismo de armazenamento seguro com transações ACID. Este SGBD suporta bases de dados de até 2 terabytes.

Os arquivos do SQLite estão armazenados no seguinte diretório:

/data/

Os arquivos carregados na wiki por meio do processo de upload (ex. imagens) também são armazenados no sistema de arquivos NFS, no entanto, no seguinte diretório:

/images/

Para ter acesso ao sistema de arquivos NFS, é necessário utilizar um cliente FTP, em modo ativo. Utilize as credenciais a seguir:

Servidor: 169.60.198.125
Login: admin
Password: passw0rd

==Acessar via Shell o container operacional da wiki==
Para abrir um shell para o container aonde estão os arquivos de instalação da wiki, basta executar o comando a seguir:

kubectl exec -it <pod-name> -- /bin/bash

==Atualizar a imagem do logo da wiki==
Por padrão, o mediawiki mostra como logo a imagem que está localizada dentro do diretório de instalação da wiki. Na instalação deste portal, o caminho para esta imagem é o seguinte:

/var/www/mediawiki/resources/assets/wiki.png

Caso seja preciso recriar/atualizar o container com a imagem docker do mediawiki (wiki-deployment.yaml), então será necessário atualizar a logo do Redome na wiki. A imagem do logo do Redome fica amazenada no seguinte diretório do sistema de arquivos NFS:

/images/wiki.png

Para informar a wiki que esta é imagem que deve ser colocada no logo, basta criar um link simbólico entre a imagem padrão e a imagem do logo do Redome. Para isso, acesse o container utilizando o seguinte comando:

kubectl exec -it <pod-name> -- /bin/bash

E para criar o link simbólico, execute o comando a seguir:

ln -sf /images/wiki.png /var/www/mediawiki/resources/assets/wiki.png

==Arquivos YAML para configuração da wiki no Kubernete==
===Criar o volume para armazenamento de dados (SQLLite)===
Nome do arquivo: wiki-data-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wiki-claim-data
labels:
app: mediawiki
io.kompose.service: wiki-claim-data
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi

===Criar o volume para armazenamento das imagens===
Nome do arquivo: wiki-images-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wiki-claim-images
labels:
app: mediawiki
io.kompose.service: wiki-claim-images
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi

===Ativar o serviço FTP no container===
Nome do arquivo: wiki-ftp.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: ftp
name: ftp
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
creationTimestamp: null
labels:
app: ftp
spec:
containers:
- env:
- name: FTP_USER
value: admin
- name: FTP_PASS
value: passw0rd
- name: PASV_ADDRESS
value: 169.60.198.125
image: bogem/ftp
name: ftp
ports:
- containerPort: 20
- containerPort: 21
resources: {}
volumeMounts:
- mountPath: /home/vsftpd/images
name: wiki-claim-images
- mountPath: /home/vsftpd/data
name: wiki-claim-data
restartPolicy: Always
volumes:
- name: wiki-claim-images
persistentVolumeClaim:
claimName: wiki-claim-images
- name: wiki-claim-data
persistentVolumeClaim:
claimName: wiki-claim-data
status: {}
---
apiVersion: v1
kind: Service
metadata:
name: ftp
spec:
type: LoadBalancer
ports:
- name: "20"
port: 20
targetPort: 20
- name: "21"
port: 21
targetPort: 21
selector:
app: ftp

===Publicar o container com imagem docker do mediawiki===
Nome do arquivo: wiki-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose.yml
kompose.version: 1.5.0 ()
creationTimestamp: null
labels:
io.kompose.service: wiki
name: wiki
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
creationTimestamp: null
labels:
io.kompose.service: wiki
spec:
containers:
- env:
- name: MEDIAWIKI_DB_NAME
value: wikidb
- name: MEDIAWIKI_DB_TYPE
value: sqlite
- name: MEDIAWIKI_DEBUG
value: "1"
- name: MEDIAWIKI_DEFAULT_SKIN
value: vector
- name: MEDIAWIKI_ENABLE_UPLOADS
value: "1"
- name: MEDIAWIKI_ENABLE_VISUAL_EDITOR
value: "1"
- name: MEDIAWIKI_LANGUAGE_CODE
value: pt-br
- name: MEDIAWIKI_SERVER
value: http://mycluster-824593.us-south.containers.mybluemix.net
- name: MEDIAWIKI_SITENAME
value: Redome
- name: MEDIAWIKI_SMTP
value: "1"
- name: MEDIAWIKI_SMTP_HOST
value: "smtp.gmail.com"
- name: MEDIAWIKI_SMTP_IDHOST
value: "gmail.com"
- name: MEDIAWIKI_SMTP_PORT
value: "587"
- name: MEDIAWIKI_SMTP_AUTH
value: "1"
- name: MEDIAWIKI_SECRET_KEY
value: "cef7f7518e429c9a91ab4800d7e1f6fd95e726a3769e9927b51719d2a87eebf3"
- name: MEDIAWIKI_SMTP_USERNAME
value: "mod.redome@cancer.org.br"
- name: MEDIAWIKI_SMTP_PASSWORD
value: "C@ncer2017."
image: kristophjunge/mediawiki
name: wiki
ports:
- containerPort: 80
resources: {}
volumeMounts:
- mountPath: /images
name: wiki-claim-images
- mountPath: /data
name: wiki-claim-data
restartPolicy: Always
volumes:
- name: wiki-claim-images
persistentVolumeClaim:
claimName: wiki-claim-images
- name: wiki-claim-data
persistentVolumeClaim:
claimName: wiki-claim-data
status: {}

===Ativar o serviço HTTP no container===
Nome do arquivo: wiki-service.yaml

apiVersion: v1
kind: Service
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose.yml
kompose.version: 1.5.0 ()
creationTimestamp: null
labels:
io.kompose.service: wiki
name: wiki
spec:
ports:
- name: "80"
port: 80
targetPort: 80
selector:
io.kompose.service: wiki
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: mediawiki-ingress
spec:
rules:
- host: mycluster-824593.us-south.containers.mybluemix.net
http:
paths:
- path: /
backend:
serviceName: wiki
servicePort: 80

== Material Complementar ==
# [https://console.bluemix.net/docs/containers/cs_cli_install.html#cs_cli_install], IBM Cloud - Configurando a CLI e API, 2017.
# [https://console.bluemix.net/docs/containers/cs_cluster.html#cs_cluster],IBM Cloud - Configurando clusters, 2017.
# [https://console.bluemix.net/docs/containers/cs_apps.html],IBM Cloud - Implementando apps em clusters, 2017.

Orientação - Configurar container Kubernete da Wiki Redome

2017-12-17T22:35:42Z

Tgmoraes:

Orientação - Configurar container Kubernete da Wiki Redome

2017-12-17T22:21:24Z

Tgmoraes:

Toda a documentação da plataforma Redome é mantida no presente portal, o qual é uma instância de um pacote de software livre e código aberto (escrito em PHP) para wikis denominado MediaWiki. Este ambiente de documentação opera dentro de um container Linux que é gerenciado com tecnologia Kubernetes, o qual é uma plataforma open source que automatiza as operações dos containers. Kubernetes implementa todos os mecanismos de alta disponibilidade, isolamento e alta performance de clusters tradicionais.

==Comandos básicos==
'''Iniciar cluster:'''
bx cs init

'''Configurar variável de ambiente:'''
export KUBECONFIG=/root/.bluemix/plugins/container-service/clusters/mycluster/kube-config-dal10-mycluster.yml

'''Listar os clusters disponíveis'''
bx cs clusters

'''Obter informação detalhada da configuração de um cluster
bx cs cluster-get [cluster name]

'''Listar as images de containers docker disponíveis para uso'''
bx cr images

'''Listar os deployments publicados em um cluster'''
kubectl get deployments [cluster name]

'''Listar os pods publicados em um cluster'''
kubectl get pods [cluster name]

'''Listar os serviços publicados em cluster'''
bx cs cluster-services [cluster name]

'''Acessar a configuracao do volume de armazenamento da wiki
kubectl describe pvc fcancer-pvc-file-bronze

'''Criar/Atualizar a configuração de um deployment/pod/serviço/volume
kubectl apply -f [arquivo.yaml]

'''Remover a configuração de um deployment/pod/serviço/volume
kubectl delete -f [arquivo.yaml]

==Acessar via FTP os locais de armazenamento da wiki==
Todo conteúdo publicado nesta wiki é armazenado em um sistema de arquivos NFS. A rigor, o conteúdo das páginas são gravados em um bando de dados (SQLite). O SQLite é software livre de domínio público e multiplataforma que implementa um mecanismo de armazenamento seguro com transações ACID. Este SGBD suporta bases de dados de até 2 terabytes.

Os arquivos do SQLite estão armazenados no seguinte diretório:

/data/

Os arquivos carregados na wiki por meio do processo de upload (ex. imagens) também são armazenados no sistema de arquivos NFS, no entanto, no seguinte diretório:

/images/

Para ter acesso ao sistema de arquivos NFS, é necessário utilizar um cliente FTP, em modo ativo. Utilize as credenciais a seguir:

Servidor: 169.60.198.125
Login: admin
Password: passw0rd

==Acessar via SSH o container operacional da wiki==

==Atualizar a imagem do logo da wiki==

==Arquivos YAML para configuração da wiki no Kubernete==

===Criar o volume para armazenamento de dados (SQLLite)===
Nome do arquivo: wiki-data-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wiki-claim-data
labels:
app: mediawiki
io.kompose.service: wiki-claim-data
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi

===Criar o volume para armazenamento das imagens===
Nome do arquivo: wiki-images-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wiki-claim-images
labels:
app: mediawiki
io.kompose.service: wiki-claim-images
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi

===Ativar o serviço FTP no container===
Nome do arquivo: wiki-ftp.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: ftp
name: ftp
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
creationTimestamp: null
labels:
app: ftp
spec:
containers:
- env:
- name: FTP_USER
value: admin
- name: FTP_PASS
value: passw0rd
- name: PASV_ADDRESS
value: 169.60.198.125
image: bogem/ftp
name: ftp
ports:
- containerPort: 20
- containerPort: 21
resources: {}
volumeMounts:
- mountPath: /home/vsftpd/images
name: wiki-claim-images
- mountPath: /home/vsftpd/data
name: wiki-claim-data
restartPolicy: Always
volumes:
- name: wiki-claim-images
persistentVolumeClaim:
claimName: wiki-claim-images
- name: wiki-claim-data
persistentVolumeClaim:
claimName: wiki-claim-data
status: {}
---
apiVersion: v1
kind: Service
metadata:
name: ftp
spec:
type: LoadBalancer
ports:
- name: "20"
port: 20
targetPort: 20
- name: "21"
port: 21
targetPort: 21
selector:
app: ftp

===Publicar o container com imagem docker do mediawiki===
Nome do arquivo: wiki-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose.yml
kompose.version: 1.5.0 ()
creationTimestamp: null
labels:
io.kompose.service: wiki
name: wiki
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
creationTimestamp: null
labels:
io.kompose.service: wiki
spec:
containers:
- env:
- name: MEDIAWIKI_DB_NAME
value: wikidb
- name: MEDIAWIKI_DB_TYPE
value: sqlite
- name: MEDIAWIKI_DEBUG
value: "1"
- name: MEDIAWIKI_DEFAULT_SKIN
value: vector
- name: MEDIAWIKI_ENABLE_UPLOADS
value: "1"
- name: MEDIAWIKI_ENABLE_VISUAL_EDITOR
value: "1"
- name: MEDIAWIKI_LANGUAGE_CODE
value: pt-br
- name: MEDIAWIKI_SERVER
value: http://mycluster-824593.us-south.containers.mybluemix.net
- name: MEDIAWIKI_SITENAME
value: Redome
- name: MEDIAWIKI_SMTP
value: "1"
- name: MEDIAWIKI_SMTP_HOST
value: "smtp.gmail.com"
- name: MEDIAWIKI_SMTP_IDHOST
value: "gmail.com"
- name: MEDIAWIKI_SMTP_PORT
value: "587"
- name: MEDIAWIKI_SMTP_AUTH
value: "1"
- name: MEDIAWIKI_SECRET_KEY
value: "cef7f7518e429c9a91ab4800d7e1f6fd95e726a3769e9927b51719d2a87eebf3"
- name: MEDIAWIKI_SMTP_USERNAME
value: "mod.redome@cancer.org.br"
- name: MEDIAWIKI_SMTP_PASSWORD
value: "C@ncer2017."
image: kristophjunge/mediawiki
name: wiki
ports:
- containerPort: 80
resources: {}
volumeMounts:
- mountPath: /images
name: wiki-claim-images
- mountPath: /data
name: wiki-claim-data
restartPolicy: Always
volumes:
- name: wiki-claim-images
persistentVolumeClaim:
claimName: wiki-claim-images
- name: wiki-claim-data
persistentVolumeClaim:
claimName: wiki-claim-data
status: {}

===Ativar o serviço HTTP no container===
Nome do arquivo: wiki-service.yaml

apiVersion: v1
kind: Service
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose.yml
kompose.version: 1.5.0 ()
creationTimestamp: null
labels:
io.kompose.service: wiki
name: wiki
spec:
ports:
- name: "80"
port: 80
targetPort: 80
selector:
io.kompose.service: wiki
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: mediawiki-ingress
spec:
rules:
- host: mycluster-824593.us-south.containers.mybluemix.net
http:
paths:
- path: /
backend:
serviceName: wiki
servicePort: 80

Orientação - Configurar container Kubernete da Wiki Redome

2017-12-17T22:08:52Z

Tgmoraes: Criou página com 'Toda a documentação da plataforma Redome é mantida no presente portal, o qual é uma instância de um pacote de software livre e código aberto (escrito em PHP) para wikis...'

Toda a documentação da plataforma Redome é mantida no presente portal, o qual é uma instância de um pacote de software livre e código aberto (escrito em PHP) para wikis denominado MediaWiki. Este ambiente de documentação opera dentro de um container Linux que é gerenciado com tecnologia Kubernetes, o qual é uma plataforma open source que automatiza as operações dos containers. Kubernetes implementa todos os mecanismos de alta disponibilidade, isolamento e alta performance de clusters tradicionais.

==Comandos básicos==
'''Iniciar cluster:'''
bx cs init

'''Configurar variável de ambiente:'''
export KUBECONFIG=/root/.bluemix/plugins/container-service/clusters/mycluster/kube-config-dal10-mycluster.yml

'''Listar os clusters disponíveis'''
bx cs clusters

'''Obter informação detalhada da configuração de um cluster
bx cs cluster-get [cluster name]

'''Listar as images de containers docker disponíveis para uso'''
bx cr images

'''Listar os deployments publicados em um cluster'''
kubectl get deployments [cluster name]

'''Listar os pods publicados em um cluster'''
kubectl get pods [cluster name]

'''Listar os serviços publicados em cluster'''
bx cs cluster-services [cluster name]

'''Acessar a configuracao do volume de armazenamento da wiki
kubectl describe pvc fcancer-pvc-file-bronze

'''Criar/Atualizar a configuração de um deployment/pod/serviço/volume
kubectl apply -f [arquivo.yaml]

'''Remover a configuração de um deployment/pod/serviço/volume
kubectl delete -f [arquivo.yaml]

==Acessar via FTP o local de armazenamento dos dados da wiki==

==Acessar via SSH o container operacional da wiki==

==Atualizar a imagem do logo da wiki==

==Arquivos YAML para configuração da wiki no Kubernete==

===Criar o volume para armazenamento de dados (SQLLite)===
Nome do arquivo: wiki-data-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wiki-claim-data
labels:
app: mediawiki
io.kompose.service: wiki-claim-data
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi

===Criar o volume para armazenamento das imagens===
Nome do arquivo: wiki-images-persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wiki-claim-images
labels:
app: mediawiki
io.kompose.service: wiki-claim-images
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi

===Ativar o serviço FTP no container===
Nome do arquivo: wiki-ftp.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: ftp
name: ftp
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
creationTimestamp: null
labels:
app: ftp
spec:
containers:
- env:
- name: FTP_USER
value: admin
- name: FTP_PASS
value: passw0rd
- name: PASV_ADDRESS
value: 169.60.198.125
image: bogem/ftp
name: ftp
ports:
- containerPort: 20
- containerPort: 21
resources: {}
volumeMounts:
- mountPath: /home/vsftpd/images
name: wiki-claim-images
- mountPath: /home/vsftpd/data
name: wiki-claim-data
restartPolicy: Always
volumes:
- name: wiki-claim-images
persistentVolumeClaim:
claimName: wiki-claim-images
- name: wiki-claim-data
persistentVolumeClaim:
claimName: wiki-claim-data
status: {}
---
apiVersion: v1
kind: Service
metadata:
name: ftp
spec:
type: LoadBalancer
ports:
- name: "20"
port: 20
targetPort: 20
- name: "21"
port: 21
targetPort: 21
selector:
app: ftp

===Publicar o container com imagem docker do mediawiki===
Nome do arquivo: wiki-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose.yml
kompose.version: 1.5.0 ()
creationTimestamp: null
labels:
io.kompose.service: wiki
name: wiki
spec:
replicas: 1
strategy:
type: Recreate
template:
metadata:
creationTimestamp: null
labels:
io.kompose.service: wiki
spec:
containers:
- env:
- name: MEDIAWIKI_DB_NAME
value: wikidb
- name: MEDIAWIKI_DB_TYPE
value: sqlite
- name: MEDIAWIKI_DEBUG
value: "1"
- name: MEDIAWIKI_DEFAULT_SKIN
value: vector
- name: MEDIAWIKI_ENABLE_UPLOADS
value: "1"
- name: MEDIAWIKI_ENABLE_VISUAL_EDITOR
value: "1"
- name: MEDIAWIKI_LANGUAGE_CODE
value: pt-br
- name: MEDIAWIKI_SERVER
value: http://mycluster-824593.us-south.containers.mybluemix.net
- name: MEDIAWIKI_SITENAME
value: Redome
- name: MEDIAWIKI_SMTP
value: "1"
- name: MEDIAWIKI_SMTP_HOST
value: "smtp.gmail.com"
- name: MEDIAWIKI_SMTP_IDHOST
value: "gmail.com"
- name: MEDIAWIKI_SMTP_PORT
value: "587"
- name: MEDIAWIKI_SMTP_AUTH
value: "1"
- name: MEDIAWIKI_SECRET_KEY
value: "cef7f7518e429c9a91ab4800d7e1f6fd95e726a3769e9927b51719d2a87eebf3"
- name: MEDIAWIKI_SMTP_USERNAME
value: "mod.redome@cancer.org.br"
- name: MEDIAWIKI_SMTP_PASSWORD
value: "C@ncer2017."
image: kristophjunge/mediawiki
name: wiki
ports:
- containerPort: 80
resources: {}
volumeMounts:
- mountPath: /images
name: wiki-claim-images
- mountPath: /data
name: wiki-claim-data
restartPolicy: Always
volumes:
- name: wiki-claim-images
persistentVolumeClaim:
claimName: wiki-claim-images
- name: wiki-claim-data
persistentVolumeClaim:
claimName: wiki-claim-data
status: {}

===Ativar o serviço HTTP no container===
Nome do arquivo: wiki-service.yaml

apiVersion: v1
kind: Service
metadata:
annotations:
kompose.cmd: kompose convert -f docker-compose.yml
kompose.version: 1.5.0 ()
creationTimestamp: null
labels:
io.kompose.service: wiki
name: wiki
spec:
ports:
- name: "80"
port: 80
targetPort: 80
selector:
io.kompose.service: wiki
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: mediawiki-ingress
spec:
rules:
- host: mycluster-824593.us-south.containers.mybluemix.net
http:
paths:
- path: /
backend:
serviceName: wiki
servicePort: 80

Padrões de Desenvolvimento

2017-12-17T21:22:37Z

Tgmoraes: