Perguntas[docker](server)

Recentemente, instalei a versão mais recente do Docker e do Docker Compose, disponíveis no site oficial, na minha máquina Ubuntu. Ao usá- docker-compose configlo, recebi este resultado:

name: docker
services: {}

Também tentei docker-compose config --services, mas não obtive nenhuma saída, embora docker-compose config --profileslistasse os perfis no arquivo de composição. Se tento executar todos os serviços usando o docker-compose up -dcomando, aparece a mensagem "nenhum serviço selecionado".

Adicionei meu usuário atual ao grupo docker e tentei os mesmos comandos com o usuário root , mas não adiantou.

ubuntu@my-ec2-server$ docker --version
Docker version 28.0.4, build b8034c0
ubuntu@my-ec2-server$ docker-compose --version
Docker Compose version v2.34.0

Aqui está meu docker-compose.ymlarquivo:

services:

################################| Utility |################################

  utility:
    build:
      context: ./utility
      dockerfile: Dockerfile
    image: utility:latest
    container_name: utility
    profiles: ["utility","all"]
    volumes:
      - ./utility/certs:/app/certs
      - ./utility/secrets:/app/secrets
    ports:
      - 3001:3000
    env_file:
      - ./.env/.utility.env


################################| Reports |################################

  reports:
    build:
      context: ./analytics_reports
      dockerfile: Dockerfile
    image: reports:latest
    container_name: reports
    profiles: ["reports","all"]
    ports:
      - 3002:3000
    env_file:
      - ./.env/.reports.env

################################| Backend API |################################

  supplier-backendapi:
    build:
      context: ./backend_api-supplier
      dockerfile: Dockerfile
    image: supplier_configuration:latest
    container_name: api-supplier
    profiles: ["backend-api","all"]
    ports:
      - 3003:3000
    env_file:
      - ./.env/.supplier.env

  voucher-backendapi:
    build:
      context: ./backend_api-voucher
      dockerfile: Dockerfile
    image: voucher:latest
    container_name: api-voucher
    profiles: ["backend-api","all"]
    ports:
      - 3004:3000
    env_file:
      - ./.env/.voucher.env

recebi uma notificação da Victoria Risk [email protected]

Novas versões do BIND estão disponíveis: 9.18.35, 9.20.7, 9.21.6

depois que baixei a imagem mais recente, o bind9 não consegue iniciar devido ao seguinte novo erro:

$ docker compose up
[+] Running 2/1
 ✔ Network bind_bind  Created                                                                                                                                                                                                                                                            0.2s
 ✔ Container bind9    Created                                                                                                                                                                                                                                                            0.0s
Attaching to bind9
bind9  | named: setgid(): Operation not permitted
bind9 exited with code 1
$ 

O bind9 funcionava bem antes de extrair a nova imagem mais recente.

meu ambiente:

$ uname -a
Linux gamma 6.1.0-26-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) x86_64 GNU/Linux
$ docker --version
Docker version 27.3.1, build ce12230
$ docker compose version
Docker Compose version v2.29.7
$

meudocker-compose

$ cat docker-compose.yml
services:
  bind:
    image: internetsystemsconsortium/bind9:9.20
    container_name: bind9
    env_file: .env
    expose:
      - 80
      - 443
      - 853
    networks:
      - default
    ports:
      - 0.0.0.0:53:53/udp
      - 0.0.0.0:53:53/tcp
      - 0.0.0.0:443:443/tcp
      - 0.0.0.0:853:853/tcp
      - 127.0.0.1:953:953/tcp
    restart: always
    volumes:
      - ./etc/bind:/etc/bind
      - ./var/cache/bind:/var/cache/bind
      - ./var/lib/bind:/var/lib/bind
      - ./var/log:/var/log

networks:
  default:
    name: bind_bind
    driver: bridge

$

named.conf:

$ cat ./etc/bind/named.conf
# Use with the following in named.conf, adjusting the allow list as needed:
key "rndc-key" {
    algorithm hmac-sha256;
    secret "XYZ";
};
#
controls {
    inet 127.0.0.1 port 953
        allow { 127.0.0.1; } keys { "rndc-key"; };
};
# End of named.conf

logging {
        channel stdout {
                stderr;
                severity debug;
#                severity info;
                print-category yes;
                print-severity yes;
                print-time yes;
        };
        category security { stdout; };
        category dnssec   { stdout; };
        category default  { stdout; };
        category queries  { stdout; };
};

tls local-tls {
    key-file "/etc/bind/letsencrypt/X.Y.Z/privkey.pem";
    cert-file "/etc/bind/letsencrypt/X.Y.Z/fullchain.pem";
};

http local-http-server {
    endpoints { "/dns-query";  };
};

options {
    allow-query-cache { any; };
        allow-recursion {
        X.X.X.X/Y;
    };
        allow-transfer {
        X.X.X.X/Y;
    };
        allow-update { none; };
        directory "/var/cache/bind";
    http-port 80;
    https-port 443;
    listen-on port 53 { any; };
    listen-on port 80 tls none http local-http-server { any; };
    listen-on port 443 tls local-tls http local-http-server { any; };
    listen-on-v6 port 53 { any; };
    listen-on-v6 port 80 tls none http local-http-server { any; };
    listen-on-v6 port 443 tls local-tls http local-http-server { any; };

        max-cache-size 100M;
        max-cache-ttl 3600;
        max-ncache-ttl 3600;

        # https://kb.isc.org/docs/bind-best-practices-authoritative#6-prepare-for-abuse-of-any-externalfacing-servers
        rate-limit {
#                slip 2; // Every other response truncated
#                window 15; // Seconds to bucket
                responses-per-second 5;// # of good responses per prefix-length/sec
#                referrals-per-second 5; // referral responses
#                nodata-per-second 5; // nodata responses
#                nxdomains-per-second 5; // nxdomain responses
#                errors-per-second 5; // error responses
#                all-per-second 20; // When we drop all
#                log-only no; // Debugging mode
#                pps-scale 250; // x / 1000 * per-second
#                // = new drop limit
#                exempt-clients { 127.0.0.1; 192.153.154.0/24; 192.160.238.0/24 };
#                ipv4-prefix-length 24; // Define the IPv4 block size
#                ipv6-prefix-length 56; // Define the IPv6 block size
#                max-table-size 20000; // 40 bytes * this number = max memory
#                min-table-size 500; // pre-allocate to speed startup
        };

    version none;
};

$

por favor, avise.

infelizmente o usuário/equipe do internetsystemsconsortium não tem uma tag específica de versão de 3º nível, o que me impede de fazer o rollback: https://hub.docker.com/r/internetsystemsconsortium/bind9/tags

como estou com dificuldades para encaminhar o IP real para os aplicativos docker, agora estou executando o docker traefik no modo de rede host.

traefik e serviços funcionam. Aqui está minha configuração

docker-compose.yaml:

---
services:
  traefik:
    image: traefik:latest
    container_name: traefik
    network_mode: host
    volumes:
      - ./traefik.yaml:/traefik.yaml
      - ./letsencrypt/:/letsencrypt/
      - /run/docker.sock:/var/run/docker.sock:ro
    labels:
      - traefik.enable=true
      - traefik.http.routers.traefik.rule=Host(`frontal.cestpasla.norhere.net`)
      - traefik.http.routers.traefik.entrypoints=websecure
      - traefik.http.routers.traefik.service=api@internal
      - traefik.http.services.traefik-0000traefik.loadbalancer.server.port=8080
      - traefik.http.routers.traefik.tls.certresolver=myresolver
      - traefik.http.routers.traefik.middlewares=traefik-auth
      - traefik.http.middlewares.traefik-auth.basicauth.users=me:encryptedpassword

O arquivo yaml estático do traefik:

---
api:
  dashboard:
providers:
  docker:
    exposedByDefault: false
entrypoints:
  web:
    address: 10.20.0.2:80
  websecure:
    address: 10.20.0.2:443
certificatesresolvers:
  myresolver:
    acme:
      tlschallenge: true
      email: [email protected]
      storage: /letsencrypt/acme.json
#log:
#  level: DEBUG

A linha problemática é:

      - traefik.http.services.traefik-0000traefik.loadbalancer.server.port=8080

O nome do serviço do painel é traefik-0000traefik, provavelmente porque o arquivo docker-compose está em uma pasta chamada 0000.traefik. Não me lembro em que ponto dos meus testes eu tive que adicionar essa linha de repente, mas a partir de agora, no modo host de rede, se eu não usar essa linha, posso ver esse erro nos logs do docker:

2025-03-12T11:25:38Z ERR error="service \"traefik-0000traefik\" error: port is missing" container=traefik-0000traefik-09ccfe569180f81f22b135fd75082ed017ce95a7dc0ade1ab5a7e2bfbd960886 providerName=docker

A questão:
Se eu precisar usar uma linha de configuração para o serviço do painel, posso pelo menos escolher o nome do serviço, digamos traefik_dashboard, ou algo parecido? E como?

Não estou conseguindo executar meu projeto webapp em uma instalação nova do Arch Linux. Ele usa docker e docker-compose.yaml para criar DB, servidor nginx etc. Este projeto já está sendo executado em vários PCs e ambientes de nuvem (por alguns anos), então estou pensando se talvez algum novo pacote esteja quebrando o processo de construção dos contêineres.

Meu dockerfile instala alguns pacotes usando APK, mas falha sempre que tento usar node.js. Originalmente, ele tinha um RUN npm installcomando, e para ter certeza de que node era o problema, adicionei um RUN node -vcomando logo após instalar o node. Ambos os comandos falham com a mesma mensagem exata:

=> ERROR [app  6/24] RUN node -v                                                                          0.2s
------                                                                                                          
 > [app  6/24] RUN node -v:                                                                                     
0.197 Error relocating /usr/bin/node: sqlite3session_attach: symbol not found
0.197 Error relocating /usr/bin/node: sqlite3changeset_apply: symbol not found
0.197 Error relocating /usr/bin/node: sqlite3session_create: symbol not found
0.197 Error relocating /usr/bin/node: sqlite3session_changeset: symbol not found
0.198 Error relocating /usr/bin/node: sqlite3session_patchset: symbol not found
0.198 Error relocating /usr/bin/node: sqlite3session_delete: symbol not found
------
failed to solve: process "/bin/sh -c node -v" did not complete successfully: exit code: 127

Node e npm são instalados no início do arquivo:

FROM php:8.2-fpm-alpine
COPY composer.lock composer.json /var/www/html/
WORKDIR /var/www/html/
RUN apk update 
RUN apk add nodejs npm
RUN node -v
(...)

Como posso depurar essa situação? Tentei docker compose up --buildvárias pesquisas no Google por essa mensagem de erro, mas não tive sorte.

Tenho um Docker Swarm com vários serviços em execução. Adicionei um serviço OSE syslog-ng usando https://github.com/linuxserver/docker-syslog-ng . A pilha syslog-ng tem o seguinte docker-compose.yml:

---
services:
  syslog:
    image: registry.local.net/syslog-ng:latest
    ports:
      - 514:514
    volumes:
      - /path/on/host/syslog-ng/config:/config
      - /path/on/host/log:/log
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - LOG_TO_STDOUT=1
#    healthcheck:
#      test: ["CMD-SHELL", "/usr/sbin/syslog-ng-ctl healthcheck -c /config/syslog-ng.ctl || exit 1"]
#      interval: 10s
#      timeout: 2s
#      retries: 3
    deploy:
      mode: replicated
      replicas: 1
      restart_policy:
        condition: on-failure
      update_config:
        parallelism: 1
        delay: 10s
    networks:
      syslog:

networks:
  syslog:
    external: true

e meu arquivo syslog-ng.conf é este:

@version: 4.2
@include "scl.conf"

options {
     chain_hostnames(no);
     flush_lines(0);
     use_dns(no);
     time_reopen(1);
};

source net {
    tcp(ip(0.0.0.0) port(514));
};

template my_log_format {
    template("$MSG\n");
};

filter f_access_log { program("httpd.access") };

destination d_logs {
    file(
        "/log/TEST"
        owner("1000")
        group("1000")
        perm(0664)
        template(my_log_format)
        );
};

log {
    source(net); filter(f_access_log); destination(d_logs);
};

Configurei um serviço Apache no Docker Swarm para enviar seus logs para o serviço syslog-ng usando logger -T -t httpd.accept -n syslog -P 514 --rfc3164.

O Syslog-ng cria o arquivo de log configurado, recebe as linhas de log do Apache e as anexa ao arquivo de log configurado regularmente. Tudo parece estar funcionando do jeito que eu quero. O único problema é que o contêiner Docker syslog-ng continua saindo e reiniciando a cada 70-80 segundos. Tentei adicionar uma verificação de integridade (comentada acima), mas não mudou nada. A inspeção dos contêineres encerrados mostra que todas as verificações de integridade passam até o contêiner sair com o código de saída 137, e o log do Docker dos contêineres encerrados não exibe nada obviamente errado.

O arquivo de log atual do syslog-ng mostra o seguinte (menos os registros de data e hora no início de cada linha):

Accepting connections; addr='AF_INET(0.0.0.0:514)'
syslog-ng starting up; version='4.8.1'
Syslog connection accepted; fd='14', client='AF_INET(10.0.6.244:37126)', local='AF_INET(0.0.0.0:514)'

Segundos antes de um dos contêineres sair, topdentro do contêiner estava escrito o seguinte:

top - 08:31:26 up 169 days, 17:44,  0 user,  load average: 1.13, 1.05, 1.05
Tasks:  15 total,   1 running,  14 sleeping,   0 stopped,   0 zombie
%Cpu(s): 23.8 us,  1.8 sy,  0.0 ni, 73.9 id,  0.0 wa,  0.2 hi,  0.2 si,  0.0 st 
MiB Mem :   7652.9 total,    405.8 free,   2924.0 used,   4968.6 buff/cache     
MiB Swap:   8192.0 total,   7883.4 free,    308.6 used.   4728.9 avail Mem 

EDIT: Achei que tinha encontrado uma solução adicionando

    time-reap(30);
    mark-freq(10);

para as opções globais do syslog-ng. O contêiner Docker ficou ativo por quase 5 minutos depois que eu fiz essa alteração inicialmente, mas agora ele voltou a sair e reiniciar a cada minuto ou mais, mesmo com essas opções.

Tenho uma instância do GitLab em um contêiner Docker em execução em um Synology NAS. Agora, quero mover o GitLab para um PC Windows que tenho, mas manter os dados no NAS, compartilhando pastas e tornando-as volumes Docker. Para testar, criei algumas pastas config, data, e logsno NAS e as compartilhei na rede com "Shared Folder". Pelo que entendi, configuramos para usar SMB para isso. Então, na máquina Windows, executo (com base nesta sugestão)

docker volume create --driver local
  --opt type=cifs
  --opt device=//192.168.1.150/gitlab_docker_volume/config
  --opt o=user=gitlab_docker_volume,password=<password> gitlab-config

e mais dois para criar gitlab-datae gitlab-logs.

Então, eu inicio o contêiner com

docker run -d -p 8070:80 -p 8433:443 -p 8012:22
  -v gitlab-logs:/var/log/gitlab:rw
  -v gitlab-data:/var/opt/gitlab:rw
  -v gitlab-config:/etc/gitlab:rw gitlab/gitlab-ce

e trava com o erro

...
Mixlib::ShellOut::ShellCommandFailed:
Failed asserting that ownership of "/var/opt/gitlab/git-data" was git:git
...

2024-12-13 13:54:47 + [ root:root = git:git ]

Quando olho para as pastas no NAS, posso ver que o contêiner criou com sucesso todos os arquivos e pastas que o GitLab precisa, mas todos eles têm proprietário gitlab_docker_volume:userse 777permissões. No datavolume do contêiner GitLab original que está sendo executado no NAS, a git-datapasta pertence a algum usuário misterioso 998e tem 2770permissões.

Se entendi corretamente, o que está acontecendo é que o contêiner do GitLab tenta acessar chowna git-datapasta e esse comando teria que ser mapeado no compartilhamento SMB/CIFS, mas isso não está acontecendo.

Há duas postagens sobre o mesmo erro, mas elas o encontraram usando configurações diferentes para seus volumes: uma delas parece ter o problema devido à execução do servidor Windows em uma VM, a outra está usando pastas nativas do Windows.

https://stackoverflow.com/questions/45134978/setting-up-gitlab-using-docker-on-windows-host-issue-with-shared-folders

https://stackoverflow.com/questions/44684621/volume-trouble-with-gitlab-docker-image-on-windows

Também tentei descobrir como editar as permissões do Linux por meio do compartilhamento de rede em geral, mas os resultados da pesquisa estão inundados com "como definir as permissões ao criar as pastas para que o contêiner do Docker possa editá-las em primeiro lugar" - o que já estava funcionando na minha configuração.

Eu, por outro lado, tenho pastas compartilhadas que estão originalmente em uma máquina Linux. Existe alguma maneira de alterar a configuração de compartilhamento de pastas, a configuração de volume ou qualquer outra coisa, para que o contêiner possa alterar o usuário e as permissões dos arquivos? O Docker está sendo executado com o backend WSL, a propósito.

Eu tenho uma datapasta na raiz do meu sistema de arquivos

arthur@debian:~$ ls -la /data
total 36
drwxr-xr-x  9 root   root            4096 Dec 13 09:45 .
drwxr-xr-x 21 root   root            4096 Dec 13 10:08 ..
drwxr-xr-x  2 root   root            4096 Jun 15  2020 500g2
drwxr-xr-x  6 root   root            4096 Nov 16 18:20 quad_1
drwxr-sr-x  5 arthur arthur          4096 Dec 13 13:29 tera_1
drwxrwxr-x  6 root   root            4096 Dec  7 00:00 tera_2
drwxr-xr-x  5 root   root            4096 Sep 18 21:32 tera_3
drwxr-xr-x  6 root   root            4096 May  5  2021 tera_4

Quero montar o diretório inteiro como um volume docker, mas o contêiner deve ter acesso somente leitura. Então usei:ro

sudo docker run -it --name testcontainer -v /data:/internal_data:ro --rm alpine:latest /bin/sh

Quando o shell é gerado, ainda consigo escrever no contêiner supostamente somente leitura. Por que isso?

/ # touch /internal_data/test
touch: /internal_data/test: Read-only file system        # Ok, container prevented from writing
/ # touch /internal_data/tera_1/test                     # This worked
/ # touch /internal_data/tera_2/test                     # This worked
/ # touch /internal_data/500g2/test                      
touch: /internal_data/500g2/test: Read-only file system # Ok, container prevented from writing
/ #

Tenho uma pasta de script com um script python, um arquivo docker e também um requirements.txt

Meu script Python está sendo executado individualmente bem, localmente.

Script Python

import os
import time
from fastapi import FastAPI
import uvicorn

app = FastAPI()


SHARED_VOLUME_PATH = '/mnt/shared'
@app.get("/")
def process_data():
    data = "From Primary car"
    
    with open(os.path.join(SHARED_VOLUME_PATH, 'shared_data_file.txt'), 'w') as f:
        f.write(data)
    
    print("Data processed and stored in shared volume")
    response = "Data processed and stored in shared volume"
    return response

if __name__ == '__main__':
    port = int(os.environ.get("PORT", 8080))
    uvicorn.run(app, host="0.0.0.0", port=port)
    process_data()

O conteúdo do arquivo Docker é o seguinte

FROM python:3.11

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY main.py .

CMD ["python", "main.py"]

Quando eu executo o comando

gcloud builds submit --tag europe-west4-docker.pkg.dev/<GCP-project-ID>/artifactory/scar-prim-component:latest

Estou recebendo este erro.

ERROR: (gcloud.builds.submit) HTTPError 412: 'us' violates constraint 'constraints/gcp.resourceLocations'

Não sou muito forte nessa área. Por favor, informe o que preciso mudar para que eu possa enviar meu código como um componente artifactory no GCP.

Executei o mesmo script e realizei as mesmas etapas em um projeto diferente do GCP e funcionou bem e também foi implantado.

Se houver um meio alternativo para construir e enviar para o artefato, informe as etapas (em detalhes)

Tenho o seguinte cenário: Um Docker Host com vários projetos CMS e um Traefik instalado e funcionando. Gostaria de filtrar a URL de backend de endereços IP públicos, já que ela só deve ser acessível de intervalos de IP privados.

disponível publicamente: https://www.project.com/xyz https://www.project.com/abc

restrito apenas a IPs internos: https://www.project.com/backend

Posso fazer isso com uma lista de permissões de IP e, por exemplo, 2 roteadores - 1 para acesso público e 1 para acesso de backend?

Eu tentei algo como:

  # Backend Router (Restricted Access)
  - "traefik.http.routers.project-backend.rule=Host(`${DOMAINNAME}`) && PathPrefix(`/backend`)"
  - "traefik.http.routers.project-backend.entrypoints=https"
  - "traefik.http.routers.project-backend.tls=true"
  - "traefik.http.routers.project-backend.middlewares=backend-ipwhitelist"
  - "traefik.http.routers.project-backend.priority=100"

Mas o filtro não funcionou - ainda foi possível acessar o backend.

Alguma sugestão?

Estou executando o BIND9 dentro de um contêiner Docker e notando muitas mensagens como esta:

bind9 | 13-Nov-2024 22:39:13.792 consultas: info: cliente @0x7f81a0077000 200.55.244.14#7459 (.): consulta: . IN ANY +E(0) (172.19.0.2)

Agora estou tentando implementar “Response Rate Limiting (RRL)” seguindo as Melhores Práticas do BIND - Autoritativo e/ou Usando Response Rate Limiting (RRL) . No entanto, mesmo após adicionar a seguinte configuração, não parece estar fazendo nenhuma diferença:

options {
         …
          rate-limit {
              responses-per-second 5;
          };
      };

meu ambiente:

$ docker --version
Docker version 27.3.1, build ce12230
$ docker compose version
Docker Compose version v2.29.7
$ cat /etc/debian_version
12.7
$ uname -a
Linux X 6.1.0-26-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) x86_64 GNU/Linux
$ docker images internetsystemsconsortium/bind9
REPOSITORY                        TAG       IMAGE ID       CREATED       SIZE
internetsystemsconsortium/bind9   9.21      2fe7f58e77a3   4 weeks ago   371MB
$

Por favor, avise) Obrigado antecipadamente!