Contentor de Concessão

  • Artigo

A Lease Container operação estabelece e gere um bloqueio num contentor para operações de eliminação. A duração do bloqueio pode ser de 15 a 60 segundos ou pode ser infinita.

Pode chamar a Lease Container operação num dos seguintes modos:

  • Acquire, para pedir uma nova concessão.

  • Renew, para renovar uma concessão existente.

  • Change, para alterar o ID de uma concessão existente.

  • Release, para libertar a concessão se já não for necessária, para que outro cliente possa adquirir imediatamente uma concessão no contentor.

  • Break, para terminar a concessão, mas certifique-se de que outro cliente não pode adquirir uma nova concessão até que o período de concessão atual expire.

Nota

A Lease Container operação está disponível na versão 2012-02-12 e posterior.

Pedir

Pode construir o pedido da Lease Container seguinte forma. É recomendado HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento.

Método URI do pedido Versão HTTP
PUT https://myaccount.blob.core.windows.net/mycontainer?comp=lease&restype=container HTTP/1.1

Para especificar o contentor de raiz, introduza $root como o nome do contentor.

URI do serviço de armazenamento emulado

Quando fizer um pedido contra o serviço de armazenamento emulado, especifique o nome do anfitrião do emulador e Armazenamento de Blobs do Azure porta como 127.0.0.1:10000, seguido do nome da conta de armazenamento emulada.

Método URI do pedido Versão HTTP
PUT http://127.0.0.1:10000/mycontainer?comp=lease&restype=container HTTP/1.0

HTTP/1.1

Para obter mais informações, veja Utilizar o emulador Azurite para desenvolvimento local do Armazenamento do Azure.

Parâmetros URI

Pode especificar o seguinte parâmetro adicional no URI do pedido.

Parâmetro Description
timeout Opcional. O timeout parâmetro é expresso em segundos. Para obter mais informações, veja Definir tempos limite para operações de Armazenamento de Blobs.

Cabeçalhos do pedido

A tabela seguinte descreve os cabeçalhos de pedido obrigatórios e opcionais.

Cabeçalho do pedido Description
Authorization Obrigatório. Especifica o esquema de autorização, o nome da conta e a assinatura. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
Date ou x-ms-date Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
x-ms-version Opcional. Especifica a versão da operação a utilizar para este pedido. Para obter mais informações, veja Controlo de versões dos serviços de Armazenamento do Azure.
x-ms-lease-id: <ID> Necessário para renovar, alterar ou libertar a concessão.

Pode especificar o valor de x-ms-lease-id em qualquer formato de cadeia GUID válido. Consulte o Guid Constructor (Cadeia) para obter uma lista de formatos válidos.
x-ms-lease-action: <acquire ¦ renew ¦ change ¦ release ¦ break> acquire: pede uma nova concessão. Se o contentor não tiver uma concessão ativa, o Armazenamento de Blobs cria uma concessão no contentor e devolve um novo ID de concessão. Se o contentor tiver uma concessão ativa, só pode pedir uma nova concessão com o ID de concessão ativo. No entanto, pode especificar um novo x-ms-lease duration, incluindo um negativo (-1) para uma concessão que nunca expira.

renew: renova a concessão. Pode renovar a concessão se o ID de concessão especificado no pedido corresponder ao associado ao contentor. Tenha em atenção que a concessão pode ser renovada mesmo que tenha expirado, desde que o contentor não tenha sido arrendado novamente desde a expiração dessa concessão. Quando renova uma concessão, o relógio de duração da concessão é reposto.

change: altere o ID de concessão de uma concessão ativa. A change tem de incluir o ID de concessão atual no x-ms-lease-ide um novo ID de concessão em x-ms-proposed-lease-id.

release: liberte a concessão. Pode libertar a concessão se o ID de concessão especificado no pedido corresponder ao associado ao contentor. A libertação da concessão permite que outro cliente adquira imediatamente a concessão do contentor assim que a versão estiver concluída.

break: quebre a concessão, se o contentor tiver uma concessão ativa. Depois de uma concessão ser interrompida, não pode ser renovada. Qualquer pedido autorizado pode interromper a concessão. O pedido não é necessário para especificar um ID de concessão correspondente. Quando uma concessão é interrompida, o período de interrupção da concessão é permitido decorrido. Só pode realizar e efetuar break operações release de concessão no contentor durante este período de tempo. Quando uma concessão é quebrada com êxito, a resposta indica o intervalo em segundos até que uma nova concessão possa ser adquirida.

Também pode ser lançada uma concessão que tenha sido interrompida. Um cliente pode adquirir imediatamente uma concessão de contentor que tenha sido lançada.
x-ms-lease-break-period: N Opcional. Para uma break operação, este cabeçalho é a duração proposta que a concessão deve continuar antes de ser interrompida, entre 0 e 60 segundos. Este período de interrupção só é utilizado se for mais curto do que o tempo restante na concessão. Se for mais longo, é utilizado o tempo restante na concessão. Uma nova concessão não estará disponível antes do período de interrupção expirar, mas a concessão pode ser mantida por mais tempo do que o período de interrupção. Se este cabeçalho não aparecer com uma break operação, uma concessão de duração fixa quebra após o período de concessão restante decorrido e uma concessão infinita quebra imediatamente.
x-ms-lease-duration: -1 ¦ n seconds Necessário para acquire. Especifica a duração da concessão, em segundos ou negativa (-1) para uma concessão que nunca expira. Uma concessão não infinita pode ter entre 15 e 60 segundos. Uma duração da concessão não pode ser alterada com renew ou change.
x-ms-proposed-lease-id: <ID> Opcional para acquiree necessário para change. ID de concessão proposto, num formato de cadeia GUID. O Armazenamento de Blobs devolve 400 (Invalid request) se o ID de concessão proposto não estiver no formato correto. Consulte o Guid Constructor (Cadeia) para obter uma lista de formatos válidos.
Origin Opcional. Especifica a origem a partir da qual o pedido é emitido. A presença deste cabeçalho resulta em cabeçalhos de partilha de recursos entre origens (CORS) na resposta. Veja Suporte CORS para obter detalhes sobre os serviços de Armazenamento .
x-ms-client-request-id Opcional. Fornece um valor opaco gerado pelo cliente com um limite de carateres de 1 kibibyte (KiB) que é registado nos registos quando o registo é configurado. Recomendamos vivamente que utilize este cabeçalho para correlacionar as atividades do lado do cliente com os pedidos que o servidor recebe. Para obter mais informações, veja Monitorizar Armazenamento de Blobs do Azure.

Esta operação também suporta a utilização de cabeçalhos condicionais para executar a operação apenas se for cumprida uma condição especificada. Para obter mais informações, veja Especificar cabeçalhos condicionais para operações de Armazenamento de Blobs.

Corpo do pedido

Nenhum.

Pedido de exemplo

O seguinte pedido de exemplo mostra como adquirir uma concessão:

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=lease HTTP/1.1  
  
Request Headers:  
x-ms-version: 2012-02-12  
x-ms-lease-action: acquire  
x-ms-lease-duration: -1  
x-ms-proposed-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-date: Thu, 26 Jan 2012 23:30:18 GMT  
Authorization: SharedKey testaccount1:esSKMOYdK4o+nGTuTyeOLBI+xqnqi6aBmiW4XI699+o=

Resposta

A resposta inclui um código de estado HTTP e um conjunto de cabeçalhos de resposta.

Código de estado

Os códigos de estado de êxito devolvidos para as operações de concessão são os seguintes:

  • Acquire: uma operação bem-sucedida devolve o código de estado 201 (Criado).

  • Renew: uma operação bem-sucedida devolve o código de estado 200 (OK).

  • Change: uma operação bem-sucedida devolve o código de estado 200 (OK).

  • Release: uma operação bem-sucedida devolve o código de estado 200 (OK).

  • Break: uma operação bem-sucedida devolve o código de estado 202 (Aceite).

Para obter informações sobre códigos de estado, veja Códigos de estado e de erro.

Cabeçalhos de resposta

A resposta para esta operação inclui os seguintes cabeçalhos. A resposta também pode incluir cabeçalhos HTTP padrão adicionais. Todos os cabeçalhos padrão estão em conformidade com a especificação do protocolo HTTP/1.1.

Syntax Descrição
ETag O ETag para o contentor. Este cabeçalho é devolvido para pedidos feitos na versão 2013-08-15 e posterior e o ETag valor está entre aspas. Lease Container as operações efetuadas na versão 2013-08-15 e posterior não modificam esta propriedade, mas as versões anteriores sim.
Last-Modified Devolvido para pedidos feitos na versão 2013-08-15 e posterior. Devolve a data e hora em que o contentor foi modificado pela última vez. Para obter mais informações, veja Representação dos valores de data/hora nos cabeçalhos.

Qualquer operação que modifique o contentor, ou as respetivas propriedades ou metadados, atualiza a hora da última modificação. Isto inclui a definição das permissões do contentor. As operações em blobs não afetam a hora da última modificação do contentor. Lease Container as operações efetuadas na versão 2013-08-15 e posterior não modificam esta propriedade, mas as versões anteriores sim.
x-ms-lease-id: <id> Quando pede uma concessão, o Armazenamento de Blobs devolve um ID de concessão exclusivo. Enquanto a concessão estiver ativa, tem de incluir o ID de concessão com qualquer pedido para eliminar o contentor ou para renovar, alterar ou libertar a concessão.

Uma operação de renovação bem-sucedida também devolve o ID de concessão da concessão ativa.
x-ms-lease-time: seconds Tempo aproximado restante no período de concessão, em segundos. Este cabeçalho é devolvido apenas para um pedido bem-sucedido para interromper a concessão. Se a quebra for imediata, 0 será devolvido.
x-ms-request-id Este cabeçalho identifica exclusivamente o pedido que foi feito e pode ser utilizado para resolver o pedido. Para obter mais informações, veja Resolver problemas de operações da API.
x-ms-version Indica a versão do Armazenamento de Blobs utilizada para executar o pedido. Este cabeçalho é devolvido para pedidos feitos na versão 2009-09-19 e posterior.
Date Um valor de data/hora UTC que indica a hora em que a resposta foi iniciada. O serviço gera este valor.
Access-Control-Allow-Origin Devolvido se o pedido incluir um Origin cabeçalho e CORS estiver ativado com uma regra correspondente. Este cabeçalho devolve o valor do cabeçalho do pedido de origem em caso de correspondência.
Access-Control-Expose-Headers Devolvido se o pedido incluir um Origin cabeçalho e CORS estiver ativado com uma regra correspondente. Devolve a lista de cabeçalhos de resposta que devem ser expostos ao cliente ou emissor do pedido.
Access-Control-Allow-Credentials Devolvido se o pedido incluir um Origin cabeçalho e CORS estiver ativado com uma regra correspondente que não permita todas as origens. Este cabeçalho será definido como true.
x-ms-client-request-id Pode utilizar este cabeçalho para resolver problemas de pedidos e respostas correspondentes. O valor deste cabeçalho é igual ao valor do x-ms-client-request-id cabeçalho, se estiver presente no pedido. O valor é, no máximo, 1024 carateres ASCII visíveis. Se o x-ms-client-request-id cabeçalho não estiver presente no pedido, não estará presente na resposta.

Corpo da resposta

Nenhum.

Resposta de amostra

Segue-se uma resposta de exemplo para um pedido de aquisição de uma concessão:

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2012-02-12  
x-ms-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
Date: Thu, 26 Jan 2012 23:30:18 GMT

Autorização

A autorização é necessária quando está a chamar qualquer operação de acesso a dados no Armazenamento do Azure. Pode autorizar a Lease Container operação conforme descrito nas secções seguintes.

O Armazenamento do Azure suporta a utilização de Microsoft Entra ID para autorizar pedidos para dados de blobs. Com Microsoft Entra ID, pode utilizar o controlo de acesso baseado em funções do Azure (RBAC do Azure) para conceder permissões a um principal de segurança. O principal de segurança pode ser um utilizador, grupo, principal de serviço de aplicação ou identidade gerida do Azure. O principal de segurança é autenticado por Microsoft Entra ID para devolver um token OAuth 2.0. Em seguida, o token pode ser utilizado para autorizar um pedido contra o Armazenamento de Blobs.

Para saber mais sobre a autorização através de Microsoft Entra ID, veja Autorizar o acesso a blobs com Microsoft Entra ID.

Permissões

As seguintes ações RBAC são necessárias para que um utilizador, grupo ou principal de serviço Microsoft Entra chame a Lease Container operação e a função RBAC do Azure com menos privilégios que inclua esta ação:

Para saber mais sobre a atribuição de funções com o RBAC do Azure, veja Atribuir uma função do Azure para acesso a dados de blobs.

Observações

Uma concessão num contentor fornece acesso de eliminação exclusivo ao contentor. Uma concessão de contentor só controla a capacidade de eliminar o contentor com a operação Eliminar Contentor . Para eliminar um contentor com uma concessão ativa, um cliente tem de incluir o ID de concessão ativo com o pedido de eliminação. Se o ID de concessão não estiver incluído, a operação falhará com o 412 (A pré-condição falhou). Todas as outras operações de contentor têm êxito num contentor arrendado, sem incluir o ID de concessão. A concessão é concedida durante a duração especificada quando a concessão é adquirida, que pode ser entre 15 e 60 segundos, ou uma duração infinita.

Quando um cliente adquire uma concessão, é devolvido um ID de concessão. O Armazenamento de Blobs gera um ID de concessão, se não for especificado no pedido de aquisição. O cliente pode utilizar este ID de concessão para renovar a concessão, alterar o ID de concessão ou libertar a concessão. O diagrama seguinte mostra os estados possíveis de uma concessão e os comandos ou eventos que causam alterações ao estado de concessão.

Diagrama de estados de concessão de contentores e acionadores de alteração de estado.

Uma concessão pode ser em um de cinco estados, com base no facto de a concessão estar bloqueada ou desbloqueada, e se a concessão é renovável nesse estado. As ações de concessão mostradas no diagrama anterior causam transições de estado.

Estado da renovação Concessão bloqueada Concessão desbloqueada
Concessão renovável Arrendado Fora do prazo
Concessão não renovável A quebrar Quebrado, Disponível

  • Available, a concessão é desbloqueada e pode ser adquirida. Ação permitida: acquire.

  • Leased, a concessão está bloqueada. Ações permitidas: acquire (apenas o mesmo ID de concessão), renew, change, releasee break.

  • Expired, a duração da concessão expirou. Ações permitidas: acquire, renew, releasee break.

  • Breaking, a concessão foi interrompida, mas a concessão continuará bloqueada até o período de interrupção expirar. Ações permitidas: release e break.

  • Broken, a concessão foi interrompida e o período de interrupção expirou. Ações permitidas: acquire, releasee break.

O Armazenamento de Blobs mantém o ID de concessão após a expiração de uma concessão de contentor. Um cliente pode renovar ou libertar a concessão com o respetivo ID de concessão expirado. Se o cliente tentar renovar ou libertar uma concessão expirada com o ID de concessão anterior e o pedido falhar, o contentor foi novamente arrendado ou eliminado, uma vez que a concessão do cliente estava ativa pela última vez.

Se uma concessão expirar em vez de ser explicitamente lançada, um cliente poderá ter de aguardar até um minuto para que seja possível adquirir uma nova concessão para o contentor. No entanto, o cliente pode renovar a concessão com o ID de concessão expirado imediatamente.

A propriedade do Last-Modified-Time contentor não é atualizada por chamadas para Lease Container.

As tabelas seguintes mostram os resultados das ações em contentores com concessões em vários estados de concessão. As letras (A), (B) e (C) representam IDs de concessão e (X) representam um ID de concessão gerado pelo Armazenamento de Blobs.

Resultados das tentativas de utilização em contentores por estado de concessão

Ação Disponível Arrendado (A) Breaking (A) Quebrado (A) Expirado (A)
Eliminar com (A) Falha (412) Concessão (A), eliminação com êxito Breaking (A), delete succeeds (Breaking (A), delete succeeds (Breaking (A), delete succeeds Falha (412) Falha (412)
Eliminar com (B) Falha (412) Falha (409) Falha (412) Falha (412) Falha (412)
Eliminar, sem concessão especificada Disponível, eliminação com êxito Falha (412) Falha (412) Disponível, eliminação com êxito Disponível, eliminação com êxito
Outras operações com (A) Falha (412) Leased (A), operation succeeds (Leased (A), operation succeeds (Leased (A), operation succeeds Breaking (A), operation succeeds (Breaking (A), operation succeeds (Breaking (A), operation succeeds Falha (412) Falha (412)
Outras operações com (B) Falha (412) Falha (409) Falha (409) Falha (412) Falha (412)
Operações, sem concessão especificada Disponível, a operação é bem-sucedida Leased (A), operation succeeds (Leased (A), operation succeeds (Leased (A), operation succeeds Breaking (A), operation succeeds (Breaking (A), operation succeeds (Breaking (A), operation succeeds Broken (A), operation succeeds (Broken (A), operation succeeds (Broken (A), operation succeeds Expirado (A), a operação é bem-sucedida

Resultados das operações de concessão em contentores por estado de concessão

Ação Disponível Arrendado (A) Breaking (A) Quebrado (A) Expirado (A)
Acquire, nenhum ID de concessão proposto Arrendado (X) Falha (409) Falha (409) Arrendado (X) Arrendado (X)
Acquire (A) Arrendado (A) Concessão (A), nova duração Falha (409) Concedido (A) Concedido (A)
Acquire (B) Concedido (B) Falha (409) Falha (409) Concedido (B) Concedido (B)
Break, ponto final=0 Falha (409) Quebrada (A) Quebrada (A) Quebrada (A) Quebrada (A)
Break, período>0 Falha (409) Interrupção (A) Interrupção (A) Quebrada (A) Quebrada (A)
Change, (A) a (B) Falha (409) Concedido (B) Falha (409) Falha (409) Falha (409)
Change, (B) para (A) Falha (409) Concedido (A) Falha (409) Falha (409) Falha (409)
Change, (B) a (C) Falha (409) Falha (409) Falha (409) Falha (409) Falha (409)
Renew (A) Falha (409) Concessão (A), reposição do relógio de expiração Falha (409) Falha (409) Concedido (A)
Renew (B) Falha (409) Falha (409) Falha (409) Falha (409) Falha (409)
Release (A) Falha (409) Disponível Disponível Disponível Disponível
Release (B) Falha (409) Falha (409) Falha (409) Falha (409) Falha (409)
A duração expira Disponível Expirado (A) Quebrada (A) Quebrada (A) Expirado (A)

Faturação

Os pedidos de preços podem ter origem em clientes que utilizam APIs de Armazenamento de Blobs, diretamente através da API REST do Armazenamento de Blobs ou a partir de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam custos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura acumulam-se numa categoria de faturação diferente das transações de escrita. A tabela seguinte mostra a categoria de faturação dos Lease Container pedidos com base no tipo de conta de armazenamento:

Operação Tipo de conta de armazenamento Categoria de faturação
Contentor de Concessão (adquirir, lançar, renovar) Blob de blocos Premium
Standard para fins gerais v2		 Outras operações
Contentor de Concessão (adquirir, lançar, renovar) Standard para fins gerais v1 Operações de leitura
Contentor de Concessão (quebra, alteração) Blob de blocos Premium
Standard para fins gerais v2		 Outras operações
Contentor de Concessão (quebra, alteração) Standard para fins gerais v1 Operações de escrita

Para saber mais sobre os preços da categoria de faturação especificada, veja Preços do Armazenamento de Blobs do Azure.

Ver também

Autorizar pedidos para o Armazenamento do Azure
Códigos de estado e de erro
Códigos de erro do Armazenamento de Blobs
Blob de Concessão