Perguntas[docker](server)

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.

TL;DR: Não consigo entender como telegraf@sha256:05cbea951c5cf9da6c663321b32848c1b6ffdfa877563237838efa21b508b079e telegraf@sha256:848201b0601513122f567a6b690b5ef84abbb38e78ca461d1c1d3d7465691d39são a mesma imagem para telegraf:1.31, enquanto o primeiro não é mencionado em lugar nenhum. Tenho quase certeza de que são completamente as mesmas imagens, mas estou tentando entender de onde sha256:05cbea9vem o desconhecido.

Estou trabalhando em um host e notei que a imagem do Docker para o Telegraf tem dois resumos de repositório, o que gerou alguma curiosidade porque eu esperaria ver apenas o resumo do índice ou o resumo do índice e o resumo para Linux/AMD64, já que a imagem é multiarquitetura e o host é Linux/AMD64.

Quando eu corro:

docker inspect 4fffb7e682428f97779fdee3f4c44d062de6da9ba4a754a0f3b3f0ecaf87052eno servidor, recebo a seguinte saída:

        "RepoDigests": [
            "telegraf@sha256:05cbea951c5cf9da6c663321b32848c1b6ffdfa877563237838efa21b508b079",
            "telegraf@sha256:6b0d623c54754958fed356d2af239de21dcf7c95d63b76298d0cd70df79cc719"
        ],

O segundo digest parece bom, pois representa o digest do índice. No entanto, quando verifico a API do Docker Hub, o primeiro digest (05cbea...) não é mencionado de forma alguma:

curl -s https://hub.docker.com/v2/namespaces/library/repositories/telegraf/tags/1.31 | jq '.images[] | "\(.architecture) \(.digest)"' | grep 05cbea951c5cf9da6c663321b32848c1b6ffdfa877563237838efa21b508b079
# Grep returns an empty result here

curl -s https://hub.docker.com/v2/namespaces/library/repositories/telegraf/tags/1.31 | jq '.images[] | "\(.architecture) \(.digest)"' | grep amd64
"amd64 sha256:848201b0601513122f567a6b690b5ef84abbb38e78ca461d1c1d3d7465691d39"

No entanto, elas ainda são a mesma imagem. Aqui está como eu verifiquei:

Primeiro hash;

docker pull telegraf@sha256:05cbea951c5cf9da6c663321b32848c1b6ffdfa877563237838efa21b508b079

docker images|grep telegraf
telegraf                                                                  <none>      4fffb7e68242   4 weeks ago     472MB

docker inspect 4fffb7e68242 --format='{{json .}}'| jq '"\(.Created) \(.Config.Env[1]) \(.RepoDigests)"'
"2024-08-12T15:27:35Z TELEGRAF_VERSION=1.31.3 [\"telegraf@sha256:05cbea951c5cf9da6c663321b32848c1b6ffdfa877563237838efa21b508b079\"]"

Segundo hash;

docker pull telegraf@sha256:848201b0601513122f567a6b690b5ef84abbb38e78ca461d1c1d3d7465691d39
docker images|grep telegraf
telegraf                                                                  <none>      4fffb7e68242   4 weeks ago     472MB

docker inspect 4fffb7e68242 --format='{{json .}}'| jq '"\(.Created) \(.Config.Env[1]) \(.RepoDigests)"'
"2024-08-12T15:27:35Z TELEGRAF_VERSION=1.31.3 [\"telegraf@sha256:848201b0601513122f567a6b690b5ef84abbb38e78ca461d1c1d3d7465691d39\"]"

Gostaria de saber o que estou perdendo aqui. Agradeceria qualquer dica.

Editar; A única coisa que esqueci de mencionar é que o contêiner telegraf é executado por uma pilha docker swarm. Acho que isso faria diferença em como as imagens são extraídas.

Quero que meu aplicativo seja executado em um cluster Kubernetes e use o certificado montado em um volume definido no meu arquivo deployment.yaml.

Não estou usando o ingress, em vez disso, configurei meu serviço como um LoadBalancer. Não consigo descobrir como fazer esse serviço lidar com a terminação tls. Então, segui o outro caminho, onde devo montar e usar o certificado dentro do pod.

Eu montei um segredo que contém as informações do certificado dentro do arquivo deployment.yaml dos aplicativos. O pod está instalado e funcionando e encontrou esse segredo com sucesso. O único problema é que o servidor web não está configurado para usar o certificado, então meu site não está disponível. Como posso configurar o servidor web para usar o certificado? Ele pode ser definido dentro do comando no arquivo docker?

O servidor web está em execução: npm run preview

Verificando o arquivo package.json, isto é: "preview": "vite preview"

Posso configurar o vite para usar certificados armazenados dentro do contêiner do kubernetes? É possível definir isso no meu dockerfile?

seção de implantação que montou o certificado

          volumeMounts:
            - name: cert-volume
              mountPath: "/etc/ssl/certs"
              readOnly: true
      volumes:
        - name: cert-volume
          secret:
            secretName: my-secret

Verifiquei online e não vejo muita maneira de fazer meu servidor web npm usar esse certificado para terminação TLS. Suspeito de algo que eu possa adicionar ao package.json ou diretamente no dockerfile para apontar para esse diretório dentro do meu contêiner kubernetes.

Alguém tem alguma configuração semelhante ou experiência fazendo isso?