Montagens bind - Serviço Amazon Elastic Container

Montagens bind

Com montagens bind, um arquivo ou diretório em um host, comouma instância do Amazon EC2 ou do AWS Fargate, é montado em um contêiner. As montagens bind são compatíveis com tarefas hospedadas em instâncias do Fargate e do Amazon EC2. Por padrão,ontagens bind estão vinculadas ao ciclo de vida do contêiner que as está usando. A partir do momento em que todos os contêineres que utilizam uma montagem bind forem interrompidos, por exemplo, quando uma tarefa é interrompida, os dados serão removidos. Para tarefas hospedadas em instâncias do Amazon EC2, os dados podem ser vinculados ao ciclo de vida da instância do Amazon EC2 do host especificando um host e um valor opcional de sourcePath na definição de tarefa. Para obter mais informações, consulte Usar montagens bind na documentação do Docker.

Veja a seguir alguns casos de uso comuns de montagens bind.

  • Para fornecer um volume de dados vazio para ser montado em um ou mais contêineres.

  • Para montar um volume de dados de host em um ou mais contêineres.

  • Para compartilhar um volume de dados de um contêiner de origem com outros contêineres na mesma tarefa.

  • Para expor um caminho e seu conteúdo de um Dockerfile para um ou mais contêineres.

Considerações quando forem usadas montagens bind

Ao usar montagens bind, considere o seguinte.

  • Por padrão, as tarefas hospedadas no AWS Fargate usando a versão 1.4.0 ou posterior (Linux) ou 1.0.0 ou posterior (Windows) da plataforma recebem, no mínimo, 20 GiB de armazenamento temporário para montagens bind. A quantidade total de armazenamento temporário pode ser aumentada, até um máximo de 200 GiB, ao ser especificado o objeto ephemeralStorage na definição de tarefa.

  • Para expor arquivos de um Dockerfile a um volume de dados quando uma tarefa é executada, o plano de dados do Amazon ECS procura uma diretiva VOLUME. Se o caminho absoluto especificado na diretiva VOLUME é o mesmo que o containerPath especificado na definição de tarefa, os dados no caminho da diretiva VOLUME são copiados para o volume de dados. No exemplo de Dockerfile a seguir, um arquivo denominado examplefile do diretório /var/log/exported é gravado no host e, em seguida, montado no contêiner.

    FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"]

    Por padrão, as permissões de volume são definidas como 0755 e o proprietário como root. Você pode personalizar essas permissões no Dockerfile. O exemplo a seguir define o proprietário do diretório como node.

    FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported RUN touch /var/log/exported/examplefile USER node VOLUME ["/var/log/exported"]
  • Para tarefas hospedadas em instâncias do Amazon EC2, quando umhost e sourcePath não são especificados, o daemon do Docker gerencia a montagem bind para você. Quando nenhum contêiner fizer referência a essa montagem bind, o serviço de limpeza de tarefas do agente de contêiner do Amazon ECS acabará excluindo-a. Isso ocorre por padrão três horas após o encerramento do contêiner. Porém, é possível configurar essa duração com a variável de agente ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION. Para mais informações, consulte Configuração do agente de contêiner do Amazon ECS. Se você precisar que esses dados persistam além do ciclo de vida do contêiner, especifique um valor sourcePath para a montagem bind.

Especificar uma montagem bind na definição de tarefa

Para tarefas do Amazon ECS hospedadas ou no Fargate ou em instâncias do Amazon EC2, o trecho JSON de definição de tarefa a seguir mostra a sintaxe dos objetos volumes, mountPoints e ephemeralStorage para uma definição de tarefa.

{ "family": "", ... "containerDefinitions" : [ { "mountPoints" : [ { "containerPath" : "/path/to/mount_volume", "sourceVolume" : "string" } ], "name" : "string" } ], ... "volumes" : [ { "name" : "string" } ], "ephemeralStorage": { "sizeInGiB": integer } }

Para tarefas do Amazon ECS que são hospedadas em instâncias do Amazon EC2, é possível utilizar o parâmetro host e um sourcePath ao especificar detalhes do volume da tarefa. Quando especificado, ele associa a montagem bind ao ciclo de vida da tarefa no lugar do contêiner.

"volumes" : [ { "host" : { "sourcePath" : "string" }, "name" : "string" } ]

A seguir, é descrito em mais detalhes cada parâmetro de definição de tarefa.

name

Tipo: string

Obrigatório: não

O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números, hífens e sublinhados. Este nome é referenciado no parâmetro sourceVolume da definição de contêiner mountPoints.

host

Obrigatório: não

Esse parâmetro é especificado ao usar montagens bind. Em vez disso, para usar volumes de Docker, especifique um dockerVolumeConfiguration. O conteúdo do parâmetro host determina se o volume de dados da montagem de bind persiste na instância de contêiner host e onde é armazenado. Caso o parâmetro host esteja vazio, o daemon do Docker atribui um caminho host para o volume de dados, mas os dados não têm garantia de persistir depois que os contêineres associados deixarem de ser executados.

Volumes de host de montagens bind são compatíveis quando são usados os tipos de inicialização do EC2 ou do Fargate.

Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como $env:ProgramData.

sourcePath

Tipo: string

Obrigatório: não

Quando o parâmetro host é usado, especifique um sourcePath para declarar o caminho na instância de contêiner host que é apresentada ao contêiner. Se esse parâmetro está vazio, o daemon do Docker atribuiu um caminho host para você. Caso o parâmetro host contenha um local de arquivo sourcePath, o volume de dados persiste no local especificado na instância de contêiner host até você excluí-lo manualmente. Caso o valor sourcePath não exista na instância de contêiner host, o daemon do Docker o cria. Caso o local exista, o conteúdo da pasta do caminho de origem é exportado.

mountPoints

Tipo: matriz de objeto

Obrigatório: não

Os pontos de montagem para volumes de dados no contêiner.

Esse parâmetro é mapeado para Volumes na seção Criar um contêiner da API remota do Docker e a opção --volume para docker run.

Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como $env:ProgramData. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e o ponto de montagem não pode ser entre unidades.

sourceVolume

Tipo: string

Exigido: Sim, quando mountPoints são usados

O nome do volume a ser montado.

containerPath

Tipo: string

Exigido: Sim, quando mountPoints são usados

O caminho no contêiner no qual montar o volume de

readOnly

Type: booliano

Obrigatório: não

Caso o valor seja true, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja false, o contêiner pode gravar no volume. O valor padrão é false.

ephemeralStorage

Tipo: objeto

Obrigatório: não

A quantidade de armazenamento temporário a ser alocada para a tarefa. Esse parâmetro é usado para expandir a quantidade total de armazenamento temporário, além da quantidade padrão, para tarefas hospedadas no AWS Fargate, usando a versão 1.4.0 ou posterior (Linux) ou 1.0.0 ou posterior (Windows) da plataforma.

Você pode usar a CLI do Copilot, o CloudFormation, o AWS SDK ou a CLI para especificar o armazenamento temporário para uma montagem bind.

Exemplos de montagem bind

Os exemplos a seguir abrangem os casos de uso mais comuns para o uso de uma montagem bind para contêineres.

Para alocar uma quantidade maior de espaço de armazenamento temporário para uma tarefa do Fargate

Para tarefas do Amazon ECS hospedadas no Fargate usando a versão 1.4.0 ou posterior (Linux) ou 1.0.0 (windows) da plataforma, você pode alocar mais do que a quantidade padrão de armazenamento temporário para os contêineres da tarefa que serão usados. Esse exemplo pode ser incorporado aos outros exemplos para alocar mais armazenamento temporário para suas tarefas do Fargate.

  • Na definição da tarefa, defina um objeto ephemeralStorage. O sizeInGiB deve ser um número inteiro entre os valores de 21 e 200 e é expresso em GiB.

    "ephemeralStorage": { "sizeInGiB": integer }

Para fornecer um volume de dados vazio para um ou mais contêineres

Em alguns casos, você pode querer fornecer aos contêineres de uma tarefa algum espaço temporário. Por exemplo, você pode ter dois contêineres de banco de dados que precisam acessar o mesmo local de armazenamento de arquivos temporários durante uma tarefa. Isso pode ser feito usando uma montagem bind.

  1. Na seção volumes da definição de tarefa, defina uma montagem bind com o nome database_scratch.

    "volumes": [ { "name": "database_scratch", } ]
  2. Na seção containerDefinitions, crie as definições de contêiner de banco de dados. Isso deve ser feito para que elas montem o volume.

    "containerDefinitions": [ { "name": "database1", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] }, { "name": "database2", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] } ]

Para expor um caminho e seu conteúdo em um Dockerfile para um contêiner

Neste exemplo, você tem um Dockerfile que grava dados que você quer montar em um contêiner. Este exemplo funciona para tarefas hospedadas em instâncias do Fargate ou do Amazon EC2.

  1. Crie um Dockerfile. O exemplo a seguir usa a imagem pública do contêiner do Amazon Linux 2 e cria um arquivo denominado examplefile no diretório /var/log/exportedque queremos montar dentro do contêiner. A diretiva VOLUME deve especificar um caminho absoluto.

    FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"]

    Por padrão, as permissões de volume são definidas como 0755 e o proprietário como root. Essas permissões podem ser alteradas no Dockerfile. No exemplo a seguir, o proprietário do diretório /var/log/exported é definido como node.

    FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported RUN touch /var/log/exported/examplefile USER node VOLUME ["/var/log/exported"]
  2. Na seção volumes da definição da tarefa, defina um volume com o nome application_logs.

    "volumes": [ { "name": "application_logs", } ]
  3. Na seção containerDefinitions, crie as definições do contêiner da aplicação. Isso deve ser feito para que elas montem o armazenamento. O valor containerPath deve corresponder ao caminho absoluto especificado na diretiva VOLUME do Dockerfile.

    "containerDefinitions": [ { "name": "application1", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] }, { "name": "application2", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] } ]

Para fornecer um volume de dados vazio para um contêiner vinculado ao ciclo de vida da instância host do Amazon EC2

Para tarefas hospedadas em instâncias do Amazon EC2, você pode usar montagens bind e ter os dados vinculados ao ciclo de vida da instância host do Amazon EC2. Você pode fazer isso usando o parâmetro host e especificando um valor sourcePath. Todos os arquivos existentes em sourcePath são apresentados aos contêineres no valor containerPath. Todos os arquivos que são gravados no valor containerPath são gravados no valor sourcePath na instância do host do Amazon EC2.

Importante

O Amazon ECS não sincroniza seu armazenamento entre instâncias do Amazon EC2. As tarefas que usam armazenamento persistente podem ser colocadas em qualquer instância do Amazon EC2, no cluster que tiver capacidade disponível. Se suas tarefas exigirem armazenamento persistente após a interrupção e a reinicialização, sempre especifique a mesma instância do Amazon EC2 no momento da inicialização da tarefa com o comando start-task da AWS CLI. Também podem ser usados volumes do Amazon EFS para armazenamento persistente. Para mais informações, consulte Volumes do Amazon EFS.

  1. Na seção volumes da definição de tarefa, defina uma montagem bind com os valores name e sourcePath. No exemplo a seguir, a instância host do Amazon EC2 contém dados em /ecs/webdata que você quer montar no contêiner.

    "volumes": [ { "name": "webdata", "host": { "sourcePath": "/ecs/webdata" } } ]
  2. Na seção containerDefinitions, defina um contêiner com um valor mountPoints que faça referência ao nome da montagem bind definida e ao valor containerPath para montar a montagem bind no contêiner.

    "containerDefinitions": [ { "name": "web", "image": "nginx", "cpu": 99, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webdata", "containerPath": "/usr/share/nginx/html" } ] } ]

Para montar um volume definido em vários contêineres em diferentes locais

Você pode definir um volume de dados em uma definição de tarefa e montar esse volume em locais diferentes em diferentes contêineres. Por exemplo, seu contêiner host tem uma pasta de dados de site em /data/webroot. É possível montar esse volume de dados como somente leitura em dois servidores Web diferentes com raízes de documentos distintas.

  1. Na seção volumes de definição de tarefa, defina um volume de dados com o nome webroot e o caminho de origem /data/webroot.

    "volumes": [ { "name": "webroot", "host": { "sourcePath": "/data/webroot" } } ]
  2. Na seção containerDefinitions, defina um contêiner para cada servidor da Web com valores mountPoints que associam o volume webroot com o valor containerPath apontando para a raiz do documento desse contêiner.

    "containerDefinitions": [ { "name": "web-server-1", "image": "my-repo/ubuntu-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/var/www/html", "readOnly": true } ] }, { "name": "web-server-2", "image": "my-repo/sles11-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 8080, "hostPort": 8080 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/srv/www/htdocs", "readOnly": true } ] } ]

Para montar volumes de outro contêiner usando volumesFrom

Para tarefas hospedadas em instâncias do Amazon EC2, é possível definir um ou mais volumes em um contêiner e, em seguida, usar o parâmetro volumesFrom em uma definição de contêiner diferente (dentro da mesma tarefa) para montar todos os volumes do sourceContainer em seus pontos de montagem definidos originalmente. O parâmetro volumesFrom se aplica a volumes determinados na definição de tarefa, e os que são incorporados na imagem com um Dockerfile.

  1. (Opcional) Para compartilhar um volume incorporado em uma imagem, utilize a instrução VOLUME no arquivo Dockerfile. O Dockerfile de exemplo a seguir usa uma imagem httpd e, em seguida, adiciona um volume e monta-o em dockerfile_volume na raiz do documento Apache. É a pasta usada pelo servidor Web httpd.

    FROM httpd VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"]

    Você pode incorporar uma imagem com esse Dockerfile e enviá-la para um repositório, como o Docker Hub, e usá-la em sua definição de tarefa. A imagem de exemplo my-repo/httpd_dockerfile_volume usada nas etapas a seguir foi incorporada com o Dockerfile acima.

  2. Crie uma definição de tarefa que defina seus outros volumes e pontos de montagem para os contêineres. Nesta seção volumes de exemplo, você cria um volume vazio chamado empty, que o daemon do Docker gerencia. Há também um volume host definido que se chama host_etc. Ele exporta a pasta /etc na instância de contêiner host.

    { "family": "test-volumes-from", "volumes": [ { "name": "empty", "host": {} }, { "name": "host_etc", "host": { "sourcePath": "/etc" } } ],

    Na seção definições de contêiner, crie um contêiner que monte os volumes definidos anteriormente. Neste exemplo, o contêiner web monta os volumes empty e host_etc. Este é o contêiner que utiliza a imagem criada com um volume no Dockerfile.

    "containerDefinitions": [ { "name": "web", "image": "my-repo/httpd_dockerfile_volume", "cpu": 100, "memory": 500, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "mountPoints": [ { "sourceVolume": "empty", "containerPath": "/usr/local/apache2/htdocs/empty_volume" }, { "sourceVolume": "host_etc", "containerPath": "/usr/local/apache2/htdocs/host_etc" } ], "essential": true },

    Crie outro contêiner que use volumesFrom para montar todos os volumes que estão associados com o contêiner web. Todos os volumes no contêiner web também são montados no contêiner busybox. Isso inclui o volume especificado no Dockerfile que foi utilizado para criar a imagem my-repo/httpd_dockerfile_volume.

    { "name": "busybox", "image": "busybox", "volumesFrom": [ { "sourceContainer": "web" } ], "cpu": 100, "memory": 500, "entryPoint": [ "sh", "-c" ], "command": [ "echo $(date) > /usr/local/apache2/htdocs/empty_volume/date && echo $(date) > /usr/local/apache2/htdocs/host_etc/date && echo $(date) > /usr/local/apache2/htdocs/dockerfile_volume/date" ], "essential": false } ] }

    Quando essa tarefa é executada, os dois contêineres montam os volumes, e o command no contêiner busybox grava a data e a hora em um arquivo. Esse arquivo se chama date em cada uma das pastas de volume. As pastas ficam visíveis no site exibido pelo contêiner web.

    nota

    Como o contêiner busybox executa um comando rápido e, em seguida, é encerrado, ele deve ser definido como "essential": false na definição do contêiner. Caso contrário, ele interromperá toda a tarefa quando for encerrado.