Procedimento Operacional Padrão (POP): Gestão de Acessos e Imagens Docker

Projeto: Implementação Odoo 18 com Localização Brasil

Ambiente: Homologação

Servidor Principal: azul1.conexaoazul.com Autor: Diego Santos Data: 29 de setembro de 2025 Versão: 1.0

1. Objetivo

Este documento descreve os procedimentos realizados para:

Criar e configurar novos usuários de desenvolvimento com acesso restrito e permissões específicas.
Atualizar uma imagem Docker a partir de um contêiner em execução, aplicando modificações e correções.
Publicar a nova imagem no Docker Hub para garantir a distribuição e o versionamento.
Diagnosticar e corrigir erros de dependências Python dentro de um ambiente Odoo conteinerizado.

2. Pré-requisitos

Acesso SSH ao servidor azul1.conexaoazul.com com permissões de root ou sudo.
Credenciais de acesso ao Docker Hub (usuário e senha).
Conhecimento básico de comandos Linux e Docker.

3. Procedimentos Executados

Parte A: Criação de Usuário para Equipe de DevOps

Cenário: Foi necessário criar um usuário (italo.eduardo) para a equipe de DevOps, concedendo acesso a um diretório de trabalho específico do projeto.

Criação do Usuário: O comando adduser foi utilizado para criar o usuário e seu grupo primário, além de configurar interativamente uma senha forte.Bash
```
# Acessado como root no servidor azul1
sudo adduser novousuario
```
Mapeamento do Diretório Home: O diretório padrão foi alterado para uma pasta específica do projeto, movendo os arquivos de configuração do usuário para o novo local.Bash
```
# -d define o novo diretório home e -m move o conteúdo do antigo
sudo usermod -d /docker/azul/18/mod/blue_br -m novousuario
```
Adição ao Grupo Secundário: O usuário foi adicionado ao grupo devops para herdar permissões de acesso compartilhadas, sem remover seu grupo primário.Bash
```
# -aG adiciona o usuário a um grupo suplementar
sudo usermod -aG devops novousuario
```
Ajuste de Propriedade do Diretório: A propriedade do diretório de trabalho foi atribuída ao grupo devops, permitindo que todos os membros do grupo tenham controle total sobre seus arquivos.Bash
```
# -R aplica a permissão recursivamente para todos os arquivos e subdiretórios
sudo chown -R devops:devops /docker/azul/18/mod/blue_br/
```
Resultado: O usuário italo.eduardo agora pode acessar o servidor via SSH e trabalhar diretamente no diretório /docker/azul/18/mod/blue_br com as permissões do grupo devops.

Parte B: Atualização e Publicação de Imagem Docker

Cenário: Após a aplicação de correções e instalações de pacotes em um contêiner Odoo em execução (dev18), foi necessário persistir essas alterações em uma nova imagem Docker e publicá-la.

Identificação do Contêiner: O ID do contêiner em execução foi localizado.Bash
```
docker ps | grep dev18
# Resultado: 3783e9eed6e4 ... dev18_dev18.1...
```
Commit do Contêiner: O estado atual do contêiner foi salvo como uma nova imagem, versionando-a de 18.0-nfe para 18.1-nfe.Bash
```
# docker commit [ID_DO_CONTAINER] [nova_imagem:tag]
docker commit 3783e9eed6e4 conexaoazul/odoo:18.1-nfe
```
Autenticação no Docker Hub: Foi realizado o login no repositório para permitir o envio da imagem.Bash
```
docker login
```
Publicação da Imagem: A nova imagem versionada foi enviada para o Docker Hub, tornando-a disponível para deploy em outros ambientes.Bash
```
docker push conexaoazul/odoo:18.1-nfe
```
Resultado: A imagem conexaoazul/odoo:18.1-nfe, contendo todas as atualizações, foi publicada com sucesso e está pronta para uso.

Parte C: Diagnóstico e Correção de Dependência Python

Cenário: Ao tentar instalar o módulo l10n_br_base no Odoo, o sistema reportou um erro de dependência externa: Package 'packaging' is required.

Diagnóstico: Foi identificado que o erro não era a ausência do pacote erpbrasil.base, mas sim da biblioteca packaging, que o Odoo utiliza para interpretar os requisitos de versão (ex: >=2.3.0).

Correção Temporária (Emergencial): Para resolver o problema imediatamente no ambiente de homologação, o pacote foi instalado diretamente no contêiner em execução.Bash

# Acessar o shell do contêiner
docker exec -it dev18_dev18.1.j8liionmrkjyyryzc84i9cmsi bash

# Instalar o pacote Python ausente
# A flag --break-system-packages foi necessária devido a proteções do S.O. base
pip3 install packaging --break-system-packages

Implementação da Correção Permanente: Para garantir que o problema não ocorra novamente em futuros deploys, a instrução de instalação foi adicionada ao Dockerfile do projeto.Dockerfile
```
# Exemplo de adição ao Dockerfile
RUN pip3 install --no-cache-dir erpbrasil.base>=2.3.0 packaging --break-system-packages
```
Após a alteração, a imagem foi reconstruída (docker build) e o serviço foi reiniciado. A nova imagem (versionada como 18.1-nfe) já contém a correção definitiva.

Resultado: O módulo l10n_br_base pôde ser instalado com sucesso. A correção foi aplicada de forma permanente no Dockerfile, seguindo as boas práticas de Infraestrutura como Código.

Documento elaborado por: Diego Santos