{"meta":{"title":"Como permitir que seu codespace acesse um registro privado","intro":"Você pode permitir que GitHub Codespaces acesse imagens de contêiner ou outros pacotes em um registro privado.","product":"Codespaces","breadcrumbs":[{"href":"/pt/codespaces","title":"Codespaces"},{"href":"/pt/codespaces/reference","title":"Referência"},{"href":"/pt/codespaces/reference/allowing-your-codespace-to-access-a-private-registry","title":"Acessar um registro privado"}],"documentType":"article"},"body":"# Como permitir que seu codespace acesse um registro privado\n\nVocê pode permitir que GitHub Codespaces acesse imagens de contêiner ou outros pacotes em um registro privado.\n\n## Sobre registros privados e GitHub Codespaces\n\nUm registro é um espaço seguro para armazenar, gerenciar e buscar imagens de contêiner ou outros pacotes. Há muitos exemplos de registros, como:\n\n* GitHub\n Container registry, o Registro de Contêiner do Azure e o DockerHub para imagens de contêiner\n* O npm registry para pacotes do Node.js.\n\nCertos GitHub Packages registries, incluindo o Container registry, podem ser configurados para permitir que os pacotes sejam baixados de forma transparente para o GitHub Codespaces durante a criação do codespace, sem a necessidade de fornecer credenciais de autenticação.\n\nPara acessar outros registros de imagem de contêiner, você pode criar segredos GitHub para armazenar os detalhes de acesso, o que permitirá GitHub Codespaces acessar imagens armazenadas nesse registro.\n\n## Como acessar pacotes armazenados em registros com permissões granulares\n\nGitHub Packages os registros que dão suporte a permissões granulares, incluindo o Container registry, fornecem a maneira mais fácil de GitHub Codespaces consumir pacotes. Para obter a lista de registros GitHub Packages com suporte a permissões granulares e acesso GitHub Codespaces contínuo, confira [Sobre permissões para o GitHub Packages](/pt/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages).\n\n### Como acessar um pacote publicado no mesmo repositório que o codespace\n\nSe você publicar um pacote no mesmo repositório em que o codespace está sendo iniciado, será possível buscar automaticamente esse pacote na criação do codespace. Você não precisará fornecer nenhuma credencial adicional, a menos que a opção **Herdar acesso do repositório** tenha sido desmarcada quando o pacote foi publicado.\n\n#### Herdar o acesso do repositório do qual um pacote foi publicado\n\nPor padrão, o pacote herda a configuração de acesso do repositório do qual foi publicado. Por exemplo, se o repositório for público, o pacote também será público. Se o repositório for privado, o pacote também será privado, mas acessível a partir do repositório.\n\nEsse comportamento é controlado pela opção **Herdar acesso do repositório**.\n**Herdar o acesso do repositório** é selecionado por padrão ao publicar via GitHub Actions, mas não ao publicar diretamente em um registro usando um personal access token.\n\nSe a opção **Herdar acesso do repositório** não foi selecionada quando o pacote foi publicado, você poderá adicionar manualmente o repositório aos controles de acesso do pacote publicado. Para saber mais, confira [Configurando o controle de acesso e visibilidade de um pacote](/pt/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility).\n\n### Acessar um pacote publicado para a organização na qual um codespace será inicializado\n\nSe você deseja que um pacote seja acessível a todos os codespaces em uma organização, recomendamos que você publique o pacote com visibilidade interna. Isso tornará o pacote automaticamente visível para todos os codespaces dentro da organização, a menos que o repositório do qual o codespace é inicializado seja público.\n\nSe o codespace estiver sendo inicializado de um repositório público referenciando um pacote interno ou privado, você deverá permitir manualmente o acesso do repositório público ao pacote interno. Isso evita que o pacote interno vaze acidentalmente para o público. Para saber mais, confira [Configurando o controle de acesso e visibilidade de um pacote](/pt/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package).\n\n### Acessar um pacote privado de um subconjunto de repositórios em uma organização\n\nSe você deseja permitir que um subconjunto dos repositórios de uma organização acesse um pacote, ou permitir que um pacote interno ou privado seja acessado de um codespace inicializado em um repositório público, você pode adicionar repositórios manualmente às configurações de acesso de um pacote. Para saber mais, confira [Configurando o controle de acesso e visibilidade de um pacote](/pt/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package).\n\n### Como publicar um pacote de um codespace\n\nO acesso contínuo de um codespace para um registro é limitado a efetuar pull de pacotes. Se você desejar publicar um pacote em um codespace, utilize um personal access token (classic) com o escopo `write:packages`.\n\nRecomendamos publicar pacotes via GitHub Actions. Para saber mais, confira [Publicando imagens do Docker](/pt/actions/tutorials/publish-packages/publish-docker-images) e [Publicar pacotes do Node.js](/pt/actions/tutorials/publish-packages/publish-nodejs-packages).\n\n## Como acessar imagens armazenadas em outros registros\n\nVocê pode definir segredos para permitir que GitHub Codespaces acesse registros de imagens de contêiner que não sejam o GitHub do Container registry. Se você estiver acessando uma imagem de contêiner de um registro que não oferece suporte a acesso integrado, GitHub Codespaces verifica a presença de três segredos, que definem o nome do servidor, o nome de usuário e a personal access token senha de um registro. Se esses segredos forem encontrados, GitHub Codespaces disponibilizará o registro dentro do seu codespace.\n\n* `<*>_CONTAINER_REGISTRY_SERVER`\n* `<*>_CONTAINER_REGISTRY_USER`\n* `<*>_CONTAINER_REGISTRY_PASSWORD`\n\nÉ possível armazenar segredos a nível do usuário, repositório ou organização, permitindo que você os compartilhe de forma segura entre diferentes codespaces. Ao criar um conjunto de segredos para um registro de imagem privado, você deverá substituir o \"<\\*>\" no nome por um identificador consistente. Para saber mais, confira [Gerenciando seus segredos específicos da conta no GitHub Codespaces](/pt/codespaces/managing-your-codespaces/managing-your-account-specific-secrets-for-github-codespaces) e [Gerenciando segredos de ambiente de desenvolvimento para seu repositório ou organização](/pt/codespaces/managing-codespaces-for-your-organization/managing-development-environment-secrets-for-your-repository-or-organization).\n\nSe você estiver definindo os segredos no nível do usuário ou da organização. certifique-se de atribuir esses segredos para o repositório no qual você criará o codespace, escolhendo uma política de acesso na lista suspensa.\n\nScreenshot of the \"Repository access\" dropdown menu with the options \"All repositories,\" \"Private repositories,\" and \"Selected repositories.\"\n\n### Transferir uma imagem do Docker para o seu codespace\n\nGitHub Codespaces usa Docker; portanto, para baixar uma imagem privada do Docker no seu codespace em tempo de execução, você precisa conseguir usar Docker-in-Docker. Para tornar isso possível, os segredos necessários para o login no Docker são adicionados automaticamente ao arquivo `~/.docker/config.json` dentro do codespace. Isso acontece após o gancho de ciclo de vida `onCreateCommand`, mas antes de `postCreateCommand`, `postStartCommand` e `postAttachCommand`. Como resultado, o `postCreateCommand` conseguirá usar o Docker-in-Docker para transferir uma imagem do Docker para o codespace, mas isso não será possível para o `onCreateCommand`. Por esse motivo, o Docker-in-Docker não está disponível durante a criação de um prebuild.\n\nDepois que o codespace estiver em execução, você conseguirá abrir um terminal nele e executar o comando `docker pull PRIVATE-IMAGE-URL`.\n\n### Exemplos de segredos\n\nPara um registro de imagem privada no Azure, você pode criar os seguintes segredos:\n\n```shell\nACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io\nACR_CONTAINER_REGISTRY_USER = acr-user-here\nACR_CONTAINER_REGISTRY_PASSWORD = \n```\n\nPara obter informações sobre registros de imagem comuns, confira [Servidores de registro de imagem comuns](#common-image-registry-servers). Observe que acessar o AWS Elastic Container Registry (ECR) é diferente.\n\n![Captura de tela das configurações de \"Segredos de Codespaces\" para um repositório. Três segredos para o Registro de Contêiner do ACR são definidos.](/assets/images/help/codespaces/codespaces-image-registry-secret-example.png)\n\nApós adicionar os segredos, pode ser que você precise parar e, em seguida, iniciar o processo de codespace para que as novas variáveis de ambiente sejam passadas para o contêiner. Para saber mais, confira [Usando a paleta de comandos Visual Studio Code em GitHub codespaces](/pt/codespaces/reference/using-the-vs-code-command-palette-in-codespaces#suspending-or-stopping-a-codespace).\n\n#### Acessando o AWS Elastic Container Registry\n\nPara acessar o ECR (Registro de Contêiner Elástico) do AWS, você pode fornecer uma ID de chave de acesso AWS e uma chave secreta e GitHub pode recuperar um token de acesso para você e fazer logon em seu nome.\n\n```shell\n*_CONTAINER_REGISTRY_SERVER = \n*_CONTAINER_REGISTRY_USER = \n*_CONTAINER_REGISTRY_PASSWORD = \n```\n\nVocê também precisa garantir que tenha as permissões apropriadas de IAM da AWS para fazer a troca de credenciais (por exemplo, `sts:GetServiceBearerToken`), bem como a operação de leitura do ECR (`AmazonEC2ContainerRegistryFullAccess` ou `ReadOnlyAccess`).\n\nComo alternativa, se você não quiser GitHub executar a troca de credenciais em seu nome, poderá fornecer um token de autorização buscado por meio de APIs ou CLI da AWS.\n\n```shell\n*_CONTAINER_REGISTRY_SERVER = \n*_CONTAINER_REGISTRY_USER = AWS\n*_CONTAINER_REGISTRY_PASSWORD = \n```\n\nComo esses tokens são curtos e precisam ser atualizados periodicamente, recomendamos fornecer um ID de chave de acesso e um segredo.\n\nEmbora esses segredos possam ter qualquer nome, desde que o `*_CONTAINER_REGISTRY_SERVER` seja uma URL do ECR, recomendamos usar `ECR_CONTAINER_REGISTRY_*`, a menos que você esteja lidando com vários registros do ECR.\n\nPara obter mais informações, confira a [documentação de autenticação de registro privado](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html) do ECR da AWS.\n\n### Servidores de registro de imagens comuns\n\nAlguns dos servidores comuns de registro de imagens estão listados abaixo:\n\n* [DockerHub](https://docs.docker.com/engine/reference/commandline/info/) - `https://index.docker.io/v1/`\n* [GitHub Repositório de Contêiner](/pt/packages/working-with-a-github-packages-registry/working-with-the-container-registry) - `ghcr.io`\n* [Registro de Contêiner do Azure](https://docs.microsoft.com/azure/container-registry/) - `.azurecr.io`\n* [Registro de Contêiner Elástico do AWS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) - `.dkr.ecr..amazonaws.com`\n* [Google Cloud Container Registry](https://cloud.google.com/container-registry/docs/overview#registries) - `gcr.io` (EUA), `eu.gcr.io` (UE), `asia.gcr.io` (Ásia)\n\n## Debugando o acesso ao repositório de imagens privadas\n\nSe você tendo problemas para extrair uma imagem de um registro de imagem privada, verifique se consegue executar `docker login -u -p ` usando os valores dos segredos definidos acima. Se o login falhar, certifique-se de que as credenciais de login sejam válidas e que você tenha as permissões apropriadas no servidor para buscar uma imagem de contêiner. Se o logon for bem-sucedido, certifique-se de que esses valores sejam copiados adequadamente para os segredos corretos GitHub Codespaces , seja no nível do usuário, do repositório ou da organização e tente novamente."}