Martin Ahrer's questions

Eu atualizei minha configuração ansible de ansible 2.10 para ansible 2.12 (de ansible 5) usando homebrew no Mac OS. Desde então, um playbook parou de produzir resultados funcionais.

- name: Assemble consul cluster
  become: true
  hosts: consul_nodes
  roles:
    - role: consul
      vars:
        consul_version: "1.11.1"
        consul_install_upgrade: true
        consul_group_name: "consul_nodes"
        consul_addresses:
          dns: !unsafe '169.254.1.1 127.0.0.1 {{  GetPrivateIP }} {{ GetInterfaceIP  \"docker0\" }}' 
          http: !unsafe '169.254.1.1 {{  GetPrivateIP }} {{ GetInterfaceIP  \"docker0\" }}' 
          https: !unsafe '127.0.0.1 {{  GetPrivateIP }}' 
          grpc: "127.0.0.1"
        consul_client_address: "169.254.1.1" 
        consul_node_role: server
        consul_bootstrap_expect_value: 3
        consul_bootstrap_expect: true

O manual contém valores de variáveis ​​não seguros que não devem ser modelados, pois seu valor deve ser passado para um arquivo de configuração JSON gravado em disco.

Estava funcionando bem antes de atualizar para o ansible 2.12

ansible [core 2.12.1]
  config file = None
  configured module search path = ['/Users/martin/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/Cellar/ansible/5.1.0/libexec/lib/python3.10/site-packages/ansible
  ansible collection location = /Users/martin/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.10.1 (main, Dec  6 2021, 23:20:29) [Clang 13.0.0 (clang-1300.0.29.3)]
  jinja version = 3.0.3
  libyaml = True

Agora, todo o JSON que o manual está criando é inválido. Aspas ("") são escapadas como (").

Suspeito que o problema esteja relacionado às variáveis ​​inseguras, pois com a versão 2.10 do ansible, obtive o mesmo resultado ruim ao não usar o !unsafe. Isso pode ser apenas uma coincidência.

Estou executando o docker dentro de um container usando o comando abaixo:
docker run --rm -ti --privileged -v /var/run/docker.sock:/var/run/docker.sock docker:1.12 sh

Dentro do shell desse contêiner, vejo um diretório com vários arquivos. Digamos que /projectcom um arquivo build.gradle. Gostaria de iniciar um novo container e montar este diretório usando o comando abaixo

docker run -ti --rm -v /project:/project openjdk:8-jdk bash -c "ls /project".

No entanto, parece que o diretório do projeto está vazio, ls /projectnão mostra nenhum arquivo.

Agora tentando montar um arquivo:

docker run -ti --rm -v /project/build.gradle:/project/build.gradle openjdk:8-jdk bash -c "ls /project/"

Desta vez, a pasta mostra o arquivo.

Qualquer um que tenha uma ideia de por que a montagem do volume não funciona como esperado. Isso é um problema de permissão?

Estou tentando configurar um registro de docker privado com base na documentação de https://docs.docker.com/registry/deploying/#running-a-domain-registry .

Estou usando o StartSSL como emissor de certificado, baixei seus crts intermediários e os combinei com meu certificado de cliente:

cd certs    
cat sca.server3.crt ca.crt client.pem  > client.crt

Depois de iniciar o registro com

docker run --rm -p 5000:5000 --name registry -v `pwd`/certs:/certs -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/client.crt -e REGISTRY_HTTP_TLS_KEY=/certs/private.key registry:2

o registro reclama sobre a incompatibilidade de chave privada/pública. No entanto, o mesmo certificado + chave privada funciona em algum outro site Apache. Eu não recebi esse erro antes de adicionar os crts intermediários ao client.crt

time="2016-07-18T11:34:19Z" level=fatal msg="crypto/tls: private key does not match public key"

Como o registro está sendo executado em uma intranet (não na Internet pública), não quero configurar um apache/nginx apenas para atuar como proxy.

Observação: estou usando o Docker Mac (Docker versão 1.12.0-rc4, build e4a0dbc, experimental).