Perguntas[docker](server)

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?

Gostaria de executar várias instâncias docker-android no docker swarm. Mas elas falham:

ERROR   | x86 emulation currently requires hardware acceleration!
https://developer.android.com/studio/run/emulator-acceleration#vm-linux
CPU acceleration status: /dev/kvm is not found: VT disabled in BIOS or KVM kernel module not loaded

Meu nó suporta kvm e roda diretamente no nó com docker compose quando adicionado privileged: truefunciona bem.
Mas o docker swarm não suporta o modo privilegiado!
Eles adicionaram cap_addsuporte recentemente no swarm, então tentei adicionar todos os caps disponíveis, mas nenhum deles habilita o kvm dentro do contêiner.

Os dispositivos também não são suportados no modo swarm!

devices:
      - "/dev/kvm:/dev/kvm"

Eu sei sobre essa solução alternativa para o modo privilégio, mas quero usar os limites de recursos de implantação para selecionar nós automaticamente com base na memória.

Preciso de uma solução rápido, então vou abrir uma recompensa.
Estou aberto a qualquer hacky way ou algo como docker forks que suportem isso

Eu executo um servidor de e-mail em um pequeno VPS executando docker-mail-server.

Estava funcionando perfeitamente até 2024-10-02, quando começou a rejeitar e-mails.

Renovei os certificados, embora eles tenham expirado em 15/10/2024 (duas semanas depois de parar de funcionar).

Sempre que recebo um e-mail, o seguinte rastreamento aparece no log (aqui um e-mail enviado do meu endereço protonmail):

NOQUEUE: reject: RCPT from unknown[185.70.43.21]: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found; from=<[email protected]> to=<contact@$MY_DOMAIN> proto=ESMTP helo=<mail-4321.protonmail.ch>

Interpretando isso como "Não sei qual é esse domínio, então rejeito o e-mail", executei dig protonmail.com, o que deu uma saída correta:

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> protonmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12017
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;protonmail.com.            IN  A

;; ANSWER SECTION:
protonmail.com.     1200    IN  A   185.70.42.12

;; Query time: 31 msec
;; SERVER: 213.186.33.99#53(213.186.33.99) (UDP)
;; WHEN: Thu Oct 10 17:32:34 UTC 2024
;; MSG SIZE  rcvd: 59

Ping para protonmail.com também funciona. Alguma ideia de uma correção/solução alternativa para esse problema ou de onde ele pode estar vindo? Quero ter certeza de que não é um erro do usuário antes de abrir um problema no github.

EDIT: parece que o próprio contêiner não tem acesso à internet. Não consigo fazer ping em um domínio nem em um endereço IP. Aqui está o docker compose que estou usando:

services:
  mailserver:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest
    container_name: mailserver
    # Provide the FQDN of your mail server here (Your DNS MX record should point to this value)
    hostname: mail.$MY_DOMAIN.fr
    env_file: mailserver.env
    # More information about the mail-server ports:
    # https://docker-mailserver.github.io/docker-mailserver/latest/config/security/understanding-the-ports/
    ports:
      - "143:143"  # IMAP4 (explicit TLS => STARTTLS)
      - "465:465"  # ESMTP (implicit TLS)
      - "587:587"  # ESMTP (explicit TLS => STARTTLS)
      - "993:993"  # IMAP4 (implicit TLS)
      - "25:25"
    volumes:
      - ./docker-data/dms/mail-data/:/var/mail/
      - ./docker-data/dms/mail-state/:/var/mail-state/
      - ./docker-data/dms/mail-logs/:/var/log/mail/
      - ./docker-data/dms/config/:/tmp/docker-mailserver/
      - /etc/localtime:/etc/localtime:ro
      - /docker/vol/dms/cert:/var/cert
      - /etc/letsencrypt:/etc/letsencrypt
    restart: always
    stop_grace_period: 1m
    healthcheck:
      test: "ss --listening --tcp | grep -P 'LISTEN.+:smtp' || exit 1"
      timeout: 3s
      retries: 0

Tentei criar uma rede externa e vincular o serviço a ela, mas não funcionou.

Para entender a replicação do mariadb criei os seguintes containers docker:

docker run -e TZ=America/Denver --name mariadb1 --network=camino_nw \
  -e MARIADB_SERVER_ID=1 -e MARIADB_LOG_BIN=mysql-bin -e MARIADB_LOG_BASENAME=mariadb1 \
  -e MARIADB_BINLOG_FORMAT=mixed -p 127.0.0.1:53301:3306 \
  -v /home/jcz/Documents/dockerMariadbData1:/var/lib/mysql:z \
  -e MARIADB_ROOT_PASSWORD=S3cretPw -d mariadb:latest

docker run -e TZ=America/Denver --name mariadb2 --network=camino_nw \
  -e MARIADB_SERVER_ID=2 -e MARIADB_LOG_BIN=mysql-bin -e MARIADB_LOG_BASENAME=mariadb2 \
  -e MARIADB_BINLOG_FORMAT=mixed -p 127.0.0.1:53302:3306 \
  -v /home/jcz/Documents/dockerMariadbData2:/var/lib/mysql:z \
  -e MARIADB_ROOT_PASSWORD=S3cretPw -d mariadb:latest

docker run -e TZ=America/Denver --name mariadb3 --network=camino_nw \
  -e MARIADB_SERVER_ID=3 -e MARIADB_LOG_BIN=mysql-bin -e MARIADB_LOG_BASENAME=mariadb3 \
  -e MARIADB_BINLOG_FORMAT=mixed -p 127.0.0.1:53303:3306 \
  -v /home/jcz/Documents/dockerMariadbData3:/var/lib/mysql:z \
  -e MARIADB_ROOT_PASSWORD=S3cretPw -d mariadb:latest

O master é mariadb1 e para este eu executei:

CREATE USER 'replication_user'@'%' IDENTIFIED BY 'S3cretPw';
GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%';

Para cada um dos escravos mariadb2 e mariadb3 eu executo:

CHANGE MASTER TO MASTER_HOST='mariadb1',  MASTER_USER='replication_user',  MASTER_PASSWORD='S3cretPw',  MASTER_PORT=3306, MASTER_CONNECT_RETRY=10;

CHANGE MASTER TO MASTER_USE_GTID = slave_pos;

Também iniciei os escravos com START SLAVE;

Depois de executar o

SHOW SLAVE STATUS \G 

Recebi o seguinte erro:

         Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MariaDB server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).

Como isso pode acontecer se eu usei

MARIADB_SERVER_ID=1
MARIADB_SERVER_ID=2
MARIADB_SERVER_ID=3

para cada um dos meus contêineres?

Estou tentando seguir:

https://mariadb.com/kb/en/setting-up-replication/

No final, depois de MUITO tempo gasto na configuração, estou sem ideias. Algo que deveria ser bem simples está se tornando bem complicado. Espero que outra pessoa possa me ajudar a encontrar a solução.

Estou tentando executar um contêiner com o Traefik. Em vez de colocar toda a configuração no arquivo docker-compose do contêiner (docker-compose.yml), como muitas pessoas fazem, estou colocando a configuração em um arquivo dedicado (traefik.yml), pois é mais flexível para mim.

Tenho o seguinte arquivo docker-compose.yml para o Traefik:

version: "3.8"

services:
  traefik:
    image: traefik:latest
    hostname: traefik
    container_name: traefik
    restart: unless-stopped
    command:
      - "--configFile=/traefik.yml"
    networks:
      - traefik_gw_bridge
    ports:
      - 80:80
      - 443:443
      - 8080:8080
    volumes:
      - ./traefik.yml:/traefik.yml
      - logs:/logs
      - letsencrypt:/letsencrypt
      - /var/run/docker.sock:/var/run/docker.sock:ro
    healthcheck:
      test: ["CMD", "traefik", "healthcheck", "--ping"]
      interval: 10s
      timeout: 6s
      retries: 2
      start_period: 5s

networks:
  traefik_gw_bridge:
    driver: bridge
    external: true

volumes:
  letsencrypt:
  logs:

E estes são os parâmetros de configuração que estou usando para traefik.yml:

api:
  dashboard: true     
  insecure: false    

ping:
  entryPoint: web      

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false 

entryPoints:
  web:
    address: ":80"   
  websecure:
    address: ":443"   
  traefik:
    address: ":8080" 

http:
  routers:
    dashboard:
      rule: "Host(`traefikdash.mydomain.com`)" 
      entryPoints:
        - traefik
      service: api@internal
      middlewares:
        - auth

  middlewares:
    auth:
      basicAuth:
        users:
          - "admin:$apr1$Nzj4xQwY$QiXQ/eYHzKTFS.Lx.6XG71"

log:                              
  filePath: "/logs/traefik.log"
  format: json
  level: DEBUG

accessLog:                        
  filePath: "/logs/access.log"
  bufferingSize: 150

certificatesResolvers:
  le:    
    acme:
      email: "[email protected]"    
      storage: "/letsencrypt/acme.json"  
      httpChallenge:
        entryPoint: "web" 

Logicamente, na parte seguinte do arquivo de configuração, estou tentando definir um roteador para configurar a autenticação básica com um nome de usuário e senha para o Dashboard:

http:
  routers:
    dashboard:
      rule: "Host(`traefikdash.mydomain.com`)"  # Reemplaza `yourdomain.com` con tu dominio
      entryPoints:
        - traefik
      service: api@internal
      middlewares:
        - auth

  middlewares:
    auth:
      basicAuth:
        users:
          - "admin:$apr1$Nzj4xQwY$QiXQ/eYHzKTFS.Lx.6XG71"

Não consigo obter o resultado que desejo. Quando acesso traefikdash.mydomain.comor traefikdash.mydomain.com:8080ou traefikdash.mydomain.com:8080/dashboard/ traefikdash.mydomain.com/dashboard, simplesmente recebo as seguintes respostas do Traefik e do meu navegador:

• Página HTTP 404 não encontrada
• Erro de conexão recusada

Depois de tentar vários tipos de configurações, simplesmente não consigo encontrar muito mais informações sobre como implementar a autenticação básica HTTP para acessar o painel do Traefik.