Max Koretskyi's questions

Li que flex-basis deveria substituir width. Mas, neste exemplo, ambos os contêineres têm flex-basis:0, mas o segundo também tem width:50px"defined" e isso claramente tem o efeito de tornar o tamanho igual.

Então estou intrigado com duas coisas relacionadas:

1. por que flex-basis:0 não substituiu a largura (eu não esperaria nenhum efeito ao adicionar widthao css)
2. por que flex-basis:0 não funcionou para definir o tamanho hipotético como 0, resultando na largura igual sem adicionar largura

Pelo que entendi da especificação :

Determine o tamanho da base flexível e o tamanho principal hipotético de cada item:

1. Se o item tiver uma base flexível usada definida, esse será o tamanho da base flexível.
2. O tamanho principal hipotético é o tamanho da base flexível do item fixado de acordo com seus tamanhos principais mínimo e máximo usados ​​(e limitando o tamanho da caixa de conteúdo a zero).

Portanto, o tamanho da base flexível está definido e deve ser resolvido como 0. O tamanho principal hipotético também deve ser resolvido como 0, pois há restrições de largura mínima/máxima.

    .container1, .container2 {
        width: 210px;
        height: 200px;
        padding: 10px;
        border: solid;
        display: inline-flex;
        box-sizing: border-box;

        div {
            margin: 1px;
            flex: 1 1 0;
        }

        & div:nth-child(1) {
            background: lightpink;
        }

        & div:nth-child(2) {
            background: lightblue;
        }
    }

    .container2 div {
        width: 50px;
    }

<div class="container1">
  <div>short</div>
  <div>looooooooooooooong</div>
</div>
<div class="container2">
  <div>short</div>
  <div>looooooooooooooong</div>
</div>

Olho para esta captura de tela:

Estou correto em assumir que o consumo de CPU que é mostrado por /usr/bin/dockerdé aplicável ao daemon do docker em si, não aos processos que rodam dentro dos contêineres gerenciados pelo docker? Por exemplo, o /usr/bin/clickhouse-serverprocesso roda dentro do contêiner, mas é mostrado como uma entrada separada na tabela.

Implementei a função lambda assim

import boto3
import os
from datetime import datetime

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')

    instance_ids = os.environ['INSTANCE_IDS'].split(",")

    for instance_id in instance_ids:
        new_ami = ec2.create_image(
            InstanceId=instance_id,
            Name=f"Backup-{instance_id}-{datetime.now().strftime('%Y-%m-%d-%H-%M-%S')}",
            NoReboot=True
        )

        new_ami_id = new_ami['ImageId']

        waiter = ec2.get_waiter('image_available')
        waiter.wait(ImageIds=[new_ami_id])
        print(f"AMI {new_ami_id} is now available")

        encrypted_ami = ec2.copy_image(
            SourceImageId=new_ami_id,
            SourceRegion=context.invoked_function_arn.split(":")[3],
            Name=f"Encrypted-Backup-{instance_id}-{datetime.now().strftime('%Y-%m-%d-%H-%M-%S')}",
            Encrypted=True
        )

    return {"status": "AMIs created, encrypted, and old AMIs managed"}

Como tirar um snapshot ec2.get_waiterrequer uma quantidade considerável de tempo, a função expira mesmo se eu colocar a quantidade máxima de ms. Qual é o fluxo correto para realizar essa tarefa?

Tenho um diretório com permissões para o usuário1:

$ ls -la owned-by-u1
drwxr-xr-x 19 u1 u1 4096 Sep  4 16:22 owned-by-u1

$ ls -nla
drwx------ 19 1001 1001 4096 Sep  4 16:22 owned-by-u1

quando mapeio esse diretório como volume para um contêiner postgres, ele altera o proprietário do diretório para o ID de usuário 999, que pode mapear diferentes nomes de usuários.

$ ls -la owned-by-u1
drwx------ 19 gitlab-runner u1 4096 Sep  4 16:22 owned-by-u1

$ ls -nla
drwx------ 19  999 1001 4096 Sep  4 16:22 owned-by-u1

Eu executo o contêiner assim

docker run -d \
    --name aaa-postgres \
    -e POSTGRES_PASSWORD=mysecretpassword \
    -e PGDATA=/var/lib/postgresql/pgdata \
    -v /home/u1/tt/owned-by-u1:/var/lib/postgresql/pgdata \
    postgres

Alguém pode explicar o mecanismo, por favor?

O dockerd está sendo executado como root (não sem root) e o remapeamento de UID não está habilitado.

Se eu habilitar o remapeamento de uid, o contêiner trava:

chmod: changing permissions of '/var/lib/postgresql/pgdata': Operation not permitted
find: ‘/var/lib/postgresql/pgdata’: Permission denied
chown: changing ownership of '/var/lib/postgresql/pgdata': Operation not permitted

O que é esperado porque a raiz interna não é uma raiz real:

$ docker run \
    --name aaa-postgres \
    --entrypoint "" \
    -e POSTGRES_PASSWORD=mysecretpassword \
    -e PGDATA=/var/lib/postgresql/pgdata \
    -v /home/max/tt/owned-by-u1:/var/lib/postgresql/pgdata \
    postgres cat /proc/self/uid_map

dá isso

0     296608      65536

que está de acordo com /etc/subuid:

$ cat /etc/subuid
dockremap:296608:65536

Aqui estão algumas informações sobre o Docker:

$ docker context ls
NAME            DESCRIPTION                               DOCKER ENDPOINT                             ERROR
default *       Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux   Docker Desktop                            npipe:////./pipe/dockerDesktopLinuxEngine

$ docker version
Client: Docker Engine - Community
Server: Docker Engine - Community