Desenvolvimento e Implantação de

Produtos Digitais no âmbito de PD&I

Guia introdutório

TIC/US/EXP-RES-DC/PN-DSCIEN

INTERNA \ Força de Trabalho

14-09-2022
Introdução
• Este é um guia rápido elaborado para esclarecer questões associadas à construção e
implantação de produtos digitais na Petrobras, contemporâneo à data de edição na capa desta
apresentação. A versão mais atualizada deste documento está em Guia Introdutório;
• Este material não esgota as informações do contexto em que se insere;
• Deve ser considerado como introdutório e as informações citadas devem ser consultadas em
suas fontes de origem sempre que possível, pois são dinâmicas e podem impactar as escolhas
ao longo do tempo;
• O material tem como público alvo os parceiros externos inseridos em projetos de construção
de produtos digitais com o CENPES. Incluem universidades, startups e outros Institutos de
Ciência e Tecnologia;
• Este material cobre somente a etapa de desenvolvimento e implantação. Não tange as
etapas de planejamento e contratação do parceiro externo e a etapa de sustentação do
produto após a implantação.

INTERNA \ Força de Trabalho

Orientações gerais
Para material de escopo amplo e direcionado
para os projetos do CENPES, consultar a
comunidade de interesse de
Desenvolvimento Científico para o Cenpes

INTERNA \ Força de Trabalho

Orientações gerais
• A construção do produtos digitais deve se alinhar à arquitetura de referência de TIC, pois as
escolhas de tecnologias devem convergir com as ofertas de infraestrutura e de suporte
contemporâneas (material acessível pela Internet mas requer liberação de acesso). As ofertas são limitadas pois a TIC
obedece às orientações corporativas de ter recursos otimizados para a demanda planejada.;
• O padrão do CENPES a ser seguido no início da jornada é o PE-2TDI-00017 - DESENVOLVER CICLO
DE VIDA DE PRODUTOS DIGITAIS NO ÂMBITO DE PD&I (material restrito, somente com chave da RIC);

• Os padrões da TIC e SI devem ser seguidos, portanto devem ser observados pelas equipes dos
parceiros externos. É papel da TIC apontar os padrões de TIC e SI para que o parceiro externo se
aproprie das exigências;
• A gerência que apoia os projetos do CENPES oferece uma fonte rica, amigável e específica para
orientar as equipes em Desenvolvimento Científico para o Cenpes (material interno também acessível pela
Internet caso o domínio seja de confiança);

INTERNA \ Força de Trabalho

Orientações gerais
• Os parceiros externos devem ter pelo menos um membro da equipe com chave de acesso à RIC (Rede Interna Corporativa),
para que tenha acesso às fontes de informação, comunidades de interesse com documentos e guias, repositórios de
códigos, pipelines de CI/CD etc..
• O responsável pela EV deve solicitar os terminais virtuais e chaves para os profissionais do parceiro externo.
• Solicitar recursos para credenciados e arcar com os custos são atribuições das gerências demandantes do negócio. A
gerência que apoia o negócio (PN) somente apoia com orientações.
• Em Desenvolvimento Científico para o Cenpes é possível obter as orientações e links necessários.

INTERNA \ Força de Trabalho

Orientações gerais
• Todo produto digital (conhecido como “aplicação” para a TIC) deve ser cadastrado no Catálogo de Aplicações
da TIC para ser devidamente registrado e mapeado de forma unívoca, recebendo um código de aplicação
com 4 dígitos, e.g. XPTO;
• Todo produto digital necessita ter um profissional responsável pela articulação junto à TIC, conhecido como
RT (Responsável Técnico). Diversas solicitações por recursos serão aceitas somente quando feitas por ele (ou
equipe devidamente responsável);
• O aprovisionamento de infraestrutura somente é possível após a validação de arquitetura da solução,
confrontada com a arquitetura de referência. A tarefa de validação é etapa formal no ciclo de
desenvolvimento do produto digital e é efetuada por áreas específicas da TIC, e solicitada por canais formais
pelo RT da aplicação (ou equipe devidamente responsável);
• A solução deve ser classificada sob critérios de criticidade e nível de serviço, o que implicará na necessidade
de infraestrutura devida e custos proporcionais. Ex.: soluções de alta disponibilidade devem estar no nível B
ou A;
• Toda Infraestrutura aprovisionada tem custo. Os custos são direcionados para a gerência responsável pelo
produto digital (CENPES “por padrão”), mas podem ser rateados entre diversas áreas de negócio. Consultar
detalhes em LINK;

INTERNA \ Força de Trabalho

Processo desenvolver produto digital

Fluxo comum e
simplificado
esperado para o
processo de
desenvolvimento

Imagem retirada da fonte em 23/08/2022

INTERNA \ Força de Trabalho

 Orientações técnicas
Para a equipe de desenvolvimento do
Parceiro Externo

INTERNA \ Força de Trabalho

Roteiro de implantação comum
• O passo-a-passo natural e comum para a
implantação de aplicações deve ser
consultado aqui ;
• Casos com necessidades específicas
devem ser tratados a parte.

Fonte: Desenvolvimento Científico para o Cenpes

Imagem retirada da fonte em 14/09/2022

INTERNA \ Força de Trabalho

Arquitetura de referência
• A arquitetura de referência é definida pela ARQTIC, gerência da TIC responsável pelas diretrizes tecnológicas. Deve ser
consultada em Arquitetura de Referência para Desenvolvimento em geral;
• Tecnologias que não estiverem contempladas na arquitetura de referência, e forem desejadas para a solução, podem ser
apreciadas através de consulta à ARQTIC quando imprescindíveis ao negócio e sem equivalente de oferta interna;
• Para desenvolvimento de soluções de ciência de dados, consultar a Arquitetura de Referência de Ciência de Dados.

Fonte: link Fonte: link

Imagem retirada da fonte em 31/08/2022 Imagem retirada da fonte em 31/08/2022

INTERNA \ Força de Trabalho

Pipeline de CI/CD on-premises
• Todas solução de parceiro externo deve ter seu código depositado no GitLab Externo (preferencialmente) ou no GitLab E&P
(escopo SOX);
• A solução é “empacotada” nos ambientes internos de CI/CD, de modo a ter o código inspecionado por ferramentas como o
SONAR;
• Soluções críticas, SOX, LGPD e na DMZ serão submetidas aos testes SAST e DAST;
• As soluções são versionadas em repositórios como o NEXUS para binários de bibliotecas, executáveis e instaladores, e o
Registry Harbor para imagens Docker de containers;

INTERNA \ Força de Trabalho

Ambiente CI/CD para containers
TIC-RT TIC-DevOps TIC-Containers TIC-Containers TIC-Containers
Solicita apoio e
interage

Constrói
Configura Configura Configura Configura
Configura

2 4 5 6 Usuários
(K8S)

codigo-externo Pipeline de Build Registry Pipeline de Deploy

Acessa
Aciona DSV
Deposita 3 Aciona aplicação
códigos
1 implantação
construção
TST

Parceiro Deposita Parceiro Parceiro TIC-RT & P.O. HMG

artefatos (DSV/TST/HMG) (PRD)

PRD
1 Códigos e artefatos são depositados no repositório de código GitLab (externo)
2 Jenkins copia artefatos p/ construir as imagens de containers
7
3 Artefatos são consultados e/ou depositados no repositório de artefatos Nexus Observa
Parceiro Logs
4 Jenkins deposita imagens de containers no repositório de imagens Harbor
5 Jenkins verifica existência de imagens de containers no Harbor
6 Jenkins avisa ao K8S que deve-se atualizar as imagens dos containers nos ambientes de DSV, TST, HMG e PRD
Obs.: O parceiro (profissional de ICT) precisa de acesso ao TV, Workspace e
7 Monitora-se o comportamento das aplicações através de Logs e gráficos integrar o grupo LDAP liberado para acessar os ambientes (DSV, TST, HMG).

INTERNA \ Força de Trabalho

Exemplo de arquitetura em containers on-premises
• 6 containers no Kubernets (K8S), com persistência de dados estruturados em banco Oracle;
• Utiliza dados não estruturados (imagens etc.) em storage;
• Containers executam diferentes linguagens como Python, .Net Core e Java;
• Containers com pouca capacidade de processamento e memória visando a escalabilidade horizontal;

INTERNA \ Força de Trabalho

Informações comuns em uma aplicação hipotética
• Nome da aplicação: SolucaoXPTO
• Código no Catálogo de aplicações (em analogia é o CPF da aplicação na TIC) => XPTO
• URLs:
• PRD = http://solucaoxpto.petrobras.com.br
• HMG = http://solucaoxpto-hmg.petrobras.com.br
• TST = http://solucaoxpto-tst.petrobras.com.br
• DSV = http://solucaoxpto-dsv.petrobras.com.br
• Banco de dados = PRD(bancop08.petrobras.com.br), HMG(bancoh08.petrobras.com.br) , TST(bancot08.petrobras.com.br), DSV(bancod08.petrobras.com.br)
• Controle de acesso CAv4 = provisionado para PRD, HMG, TST e DSV (Regional CENPES)
• Containers:
• xpto-core : 2vcpu e 2GB
• xpto-web : 2vcpu e 2GB
• Ambiente CI/CD:
• GitLab externo = https://codigo-externo.petrobras.com.br/SolucaoXPTO
• Pipeline de build no Jenkins de CI:
• https://ci.petrobras.com.br/job/XPTO-Web/
• https://ci.petrobras.com.br/job/XPTO-Core/
• Repositório de imagens (Registry Harbor) = https://registry.petrobras.com.br/harbor/projects/999/repositories
• Pipeline de deploy no Jenkins de CD = https://deploy.petrobras.com.br/job/XPTO-k8s/
• Grafana = https://k8smon.petrobras.com.br/d/3-Jfyu6Gk/k8smon-XPTO
• Usuário de integração entre bancos de dados:
• XPTO_INTEGRACAO_ZZZZ (Solução XPTO acessa BD da solução ZZZZ)
• Chave de serviço da aplicação:
• SAXPTO (e.g. utilizada para acessar recursos de outra aplicação como storage, serviço via REST, banco de dados etc.)
• Storage para arquivos de imagens etc.:
• \\s9999vfs9999.petrobras.biz\prd_xpto_002$\dados-prd

INTERNA \ Força de Trabalho

Orientações gerais
• Deve-se utilizar a solução corporativa Controle de Acesso (conhecida como CAv4) para as etapas de
autenticação e autorização de usuários em soluções on-premises, pois ela já contempla todas as exigências e
mecanismos certificados pela SI.
• Atualmente a Petrobras oferece alternativa de implantação em ambiente on-premises e/ou em ambiente em
nuvem Azure/AWS. Para ambiente em nuvem é necessário um estudo de viabilidade técnica e financeira por
parte do CCC (Centro de Competência em Computação em nuvem). Na data atual as fontes de dados
oferecidas na nuvem são limitadas, algo que deve ser considerado com cautela em projetos que exigem
integrações com dados e sistemas internos;
• Soluções on-premises que devem ser expostas para usuários externos na Internet devem ser implantadas na
DMZ, utilizando o recurso do CAv4 para autenticação de usuários externos por login/senha desacoplados à
RIC. Soluções na nuvem com a mesma necessidade utilizarão a autenticação Azure AD;
• Aplicações com arquitetura desktop devem ser evitadas quando for possível a opção pelo ambiente web em
containers. Um exemplo onde a escolha por desktop é imprescindível ocorre quando existe a necessidade de
execução da solução síncrona em ambientes de alto desempenho como clusters e workstations científicas,
comum em soluções com simuladores numéricos por exemplo;
• Aplicativos em dispositivos móveis ainda estão em amadurecimento na arquitetura de referência, portanto
devem ser planejados com alguma antecedência para o devido mapeamento e endereçamento específico;

INTERNA \ Força de Trabalho

Orientações específicas
Utilizar o recurso de Deploy-BD para promover atualização automática do modelo entre ambientes de DSV, TST,
HMG e PRD. O conceito de migração é o ponto-chave do deploy-bd, e consiste em tratar a evolução (da
estrutura) do banco de dados como uma sequência sucessiva de modificações. Cada modificação é identificada
como uma versão. Por exemplo, migrar um banco que esteja na versão 1 para versão 5 significa executar os
scripts de migração 2, 3, 4 e 5, nesta ordem. Consultar referência;

INTERNA \ Força de Trabalho

Orientações específicas
• Para planejamento dos containers consultar: https://petrobrasbr.sharepoint.com/teams/Comunidades-de-interesse-236

Imagem extraída da fonte em 08/08/2022

INTERNA \ Força de Trabalho

Orientações específicas
• Sobre uso do Controle de Acesso
consultar:
https://cawiki.ep.petrobras.com.br/bin/view/CA/WebHome

Atenção: Usar navegador Firefox !!!

INTERNA \ Força de Trabalho