pedrozulian/mouts-sales-api-migrator repository overview

⁠Descrição curta

Job de migration EF Core para o schema da mouts-sales-api — aplica e termina (.NET 8).

⁠Categoria

Application Frameworks (secundária opcional: API Management)

⁠Overview

⁠mouts-sales-api-migrator

Aplica as migrations do Entity Framework Core no PostgreSQL usado pela mouts-sales-api⁠. É um job de provisionamento — roda, aplica o schema pendente e termina; não é um processo de longa duração e não expõe porta nenhuma.

Repositório: github.com/pedrozulian/mouts-sales-api⁠

⁠Uso

docker run --rm \
  --platform linux/amd64 \
  -e ConnectionStrings__DefaultConnection="Host=<host>;Port=5432;Database=<db>;Username=<user>;Password=<senha>" \
  pedrozulian/mouts-sales-api-migrator:latest

Rode-o antes de subir a mouts-sales-api, contra o mesmo banco, usando a mesma tag de versão nas duas imagens. --rm remove o container ao final — não há motivo para mantê-lo depois que a migration é aplicada.

Sem ConnectionStrings__DefaultConnection, o container encerra imediatamente na inicialização com erro nomeando a variável ausente — nunca roda apontando para um endereço padrão.

⁠Plataforma

Imagem publicada apenas para linux/amd64. Se sua máquina é de outra arquitetura (ex.: Apple Silicon / arm64), inclua --platform linux/amd64 no docker run — sem essa flag o Docker pode recusar a execução ou emitir um aviso de incompatibilidade de plataforma antes de rodar via emulação.

Isso só se aplica ao rodar a imagem publicada diretamente. Ao usar docker compose a partir do código-fonte do repositório no GitHub⁠ (que builda a imagem localmente em vez de baixar do Docker Hub), a imagem é gerada nativamente para a arquitetura da sua máquina — por isso a flag não aparece nem é necessária nesse fluxo.

⁠Rede — conectando ao PostgreSQL

Host=postgres (o nome usado nos exemplos do projeto) só resolve dentro do Docker Compose do repositório, onde o Compose cria uma rede própria e registra cada serviço pelo nome. Rodando com docker run isolado, esse nome não existe — aponte para um endereço que o container realmente alcance:

• PostgreSQL em outro container Docker: crie uma rede e coloque os dois containers nela; o migrator então resolve o banco pelo nome dado com --name:

  docker network create sales-net
  docker run -d --name sales-db --network sales-net \
    -e POSTGRES_DB=salesapi -e POSTGRES_USER=salesapi -e POSTGRES_PASSWORD=salesapi \
    postgres:16
  
  docker run --rm --network sales-net --platform linux/amd64 \
    -e ConnectionStrings__DefaultConnection="Host=sales-db;Port=5432;Database=salesapi;Username=salesapi;Password=salesapi" \
    pedrozulian/mouts-sales-api-migrator:latest
  

  Copy

• PostgreSQL rodando na sua máquina (fora de container): localhost de dentro do container aponta para o próprio container, não para o host. Use o hostname especial host.docker.internal — disponível por padrão no Docker Desktop (Mac/Windows); no Linux, é necessário adicionar --add-host=host.docker.internal:host-gateway ao docker run.

  docker run --rm --platform linux/amd64 \
    --add-host=host.docker.internal:host-gateway \
    -e ConnectionStrings__DefaultConnection="Host=host.docker.internal;Port=5432;Database=salesapi;Username=salesapi;Password=salesapi" \
    pedrozulian/mouts-sales-api-migrator:latest
  

  Copy

  (--add-host é ignorado no Docker Desktop, onde o hostname já resolve nativamente, mas não atrapalha deixá-lo.)

• PostgreSQL em outro servidor: use o host/IP real diretamente em Host=, sem necessidade de rede ou flag adicional.

⁠Configuração

⁠Versionamento

Publicada com as tags X.Y.Z e latest, sempre geradas a partir do mesmo commit que mouts-sales-api:X.Y.Z — use a mesma tag nas duas imagens.

CHANGELOG⁠ · Releases⁠