Informationen zu privaten Registrierungen und GitHub Codespaces
Eine Registrierung ist ein sicherer Ort für das Speichern, Verwalten und Abrufen von Containerimages und anderen Paketen. Es gibt viele Beispiele für Registrierungen, z. B.:
- Container registry von GitHub, Azure Container Registry und Docker Hub für Containerimages.
- Die npm registry für Node.js-Pakete.
Bestimmte GitHub Packages-Registrierungen, einschließlich Container registry, können so konfiguriert werden, dass Pakete beim Erstellen von Codespaces nahtlos in GitHub Codespaces gepullt werden können, ohne dass du Anmeldeinformationen für die Authentifizierung angeben musst.
Für den Zugriff auf andere Containerimageregistrierungen kannst du Geheimnisse in GitHub erstellen, um die Zugangsdaten zu speichern, mit denen GitHub Codespaces auf die in dieser Registrierung gespeicherten Images zugreifen kann.
Zugreifen auf Pakete in Registrierungen mit spezifischen Berechtigungen
GitHub Packages-Registrierungen, die spezifische Berechtigungen unterstützen, einschließlich Container registry, stellen für GitHub Codespaces die einfachste Möglichkeit dar, um Pakete zu nutzen. Eine Liste der GitHub Packages-Registrierungen, die differenzierte Berechtigungen und nahtlosen GitHub Codespaces-Zugriff unterstützen, findest du unter Informationen zu Berechtigungen für GitHub-Pakete.
Zugreifen auf ein im selben Repository wie der Codespace veröffentlichtes Paket
Wenn du ein Paket im selben Repository veröffentlichst, in dem der Codespace gestartet wird, kannst du dieses beim Erstellen des Codespace automatisch abrufen. Du musst keine zusätzlichen Anmeldeinformationen angeben, es sei denn, die Option Zugriff von Repository erben wurde bei der Veröffentlichung des Pakets deaktiviert.
Vererbung des Zugriffs von dem Repository, aus dem ein Paket veröffentlicht wurde
Standardmäßig erbt das Paket die Zugriffseinstellung des Repositorys, aus dem es veröffentlicht wurde. Wenn das Repository zum Beispiel öffentlich ist, ist auch das Paket öffentlich. Ist das Repository privat, ist auch das Paket privat, aber über das Repository zugänglich.
Dieses Verhalten wird über die Option Zugriff von Repository erben gesteuert. Die Option Zugriff von Repository erben ist standardmäßig aktiviert, wenn die Veröffentlichung über GitHub Actions erfolgt, aber nicht, wenn die direkte Veröffentlichung in einer Registrierung mithilfe eines personal access token erfolgt.
Wenn die Option Zugriff von Repository erben bei der Veröffentlichung des Pakets nicht ausgewählt wurde, kannst du das Repository manuell zur Zugriffssteuerung des veröffentlichten Pakets hinzufügen. Weitere Informationen findest du unter Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen.
Zugreifen auf ein Paket, das in der Organisation veröffentlicht wurde, in der ein Codespace gestartet wird
Wenn du möchtest, dass ein Paket für alle Codespaces in einer Organisation zugänglich ist, empfehlen wir, es mit interner Sichtbarkeit zu veröffentlichen. Dadurch wird das Paket automatisch für alle Codespaces innerhalb der Organisation sichtbar – es sei denn, das Repository, aus dem der Codespace gestartet wird, ist öffentlich.
Wenn der Codespace aus einem öffentlichen Repository gestartet wird, das auf ein internes oder privates Paket verweist, musst du dem öffentlichen Repository manuell Zugriff auf das interne Paket gewähren. So wird verhindert, dass das interne Paket versehentlich öffentlich verfügbar gemacht wird. Weitere Informationen findest du unter Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen.
Zugreifen auf ein privates Paket aus einer Teilmenge der Repositorys in einer Organisation
Wenn du einem Teil der Repositorys einer Organisation Zugriff auf ein Paket gewähren oder den Zugriff auf ein internes oder privates Paket von einem Codespace aus zulassen möchtest, der in einem öffentlichen Repository gestartet wurde, kannst du Repositorys manuell zu den Zugriffseinstellungen eines Pakets hinzufügen. Weitere Informationen findest du unter Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen.
Veröffentlichen eines Pakets aus einem Codespace
Der nahtlose Zugriff eines Codespaces auf eine Registrierung ist auf das Pullen von Paketen beschränkt. Wenn du ein Paket über einen Codespace veröffentlichen möchtest, musst du ein personal access token (classic) mit dem Bereich write:packages verwenden.
Es wird empfohlen, Pakete über GitHub Actions zu veröffentlichen. Weitere Informationen findest du unter Veröffentlichen von Docker-Images und unter Node.js-Pakete veröffentlichen.
Zugreifen auf in anderen Registrierungen gespeicherte Images
Du kannst Geheimnisse definieren, damit GitHub Codespaces auf andere Containerimageregistrierungen als Container registry von GitHub zugreifen kann. Wenn du über eine Registrierung auf ein Containerimage zugreifst, die keinen nahtlosen Zugriff unterstützt, überprüft GitHub Codespaces das Vorhandensein von drei Geheimnissen, die den Servernamen, den Benutzernamen und das personal access token für eine Registrierung definieren. Wenn diese Geheimnisse gefunden werden, macht GitHub Codespaces die Registrierung in deinem Codespace verfügbar.
<*>_CONTAINER_REGISTRY_SERVER<*>_CONTAINER_REGISTRY_USER<*>_CONTAINER_REGISTRY_PASSWORD
Du kannst Geheimnisse auf Benutzer-, Repository- oder Organisationsebene speichern, sodass du sie sicher zwischen verschiedenen Codespaces austauschen kannst. Wenn du einen Satz von Geheimnissen für eine private Imageregistrierung erstellst, musst du das <*> im Namen durch einen einheitlichen Bezeichner ersetzen. Weitere Informationen finden Sie unter Verwalten deiner kontospezifischen Geheimnisse für GitHub Codespaces und unter Verwalten von Entwicklungsumgebungs-Geheimnissen für Ihr Repository oder Ihre Organisation.
Wenn du die Geheimnisse auf Benutzer- oder Organisationsebene festlegst, stelle sicher, dass du diese Geheimnisse dem Repository zuweist, in dem du den Codespace erstellst. Wähle dazu eine Zugriffsrichtlinie aus der Dropdownliste aus.
Pullen eines Docker-Bildes in Ihren Codespace
GitHub Codespaces verwendet Docker. Um ein privates Docker-Image innerhalb Ihres Codespaces zur Runtime abzurufen, müssen Sie Docker-in-Docker verwenden können. Um dies zu ermöglichen, werden die Geheimnisse, die für die Anmeldung bei Docker erforderlich sind, automatisch der ~/.docker/config.json-Datei in Ihrem Codespace hinzugefügt. Dies geschieht nach dem Lebenszyklushook onCreateCommand, aber vor postCreateCommand, postStartCommand und postAttachCommand. Daher kann postCreateCommand Docker-in-Docker verwenden, um ein Docker-Bild in den Codespace zu ziehen, aber onCreateCommand nicht. Aus diesem Grund ist Docker-in-Docker während der Prebuilderstellung nicht verfügbar.
Nachdem der Codespace ausgeführt wird, können Sie ein Terminal im Codespace öffnen und den Befehl docker pull PRIVATE-IMAGE-URL ausführen.
Beispielgeheimnisse
Für eine private Imageregistrierung in Azure könntest du die folgenden Geheimnisse erstellen:
ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
ACR_CONTAINER_REGISTRY_USER = acr-user-here
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>
Informationen zu gängigen Imageregistrierungen findest du unter Gängige Imageregistrierungsserver. Beachte, dass der Zugriff auf AWS Elastic Container Registry (ECR) anders funktioniert.
Wenn du die Geheimnisse hinzugefügt hast, musst du den Codespace, in dem du dich befindest, möglicherweise anhalten und anschließend neu starten, damit die neuen Umgebungsvariablen an den Container übergeben werden. Weitere Informationen findest du unter Verwenden der Visual Studio Code-Befehlspalette in GitHub Codespaces.
Zugreifen auf AWS Elastic Container Registry
Für den Zugriff auf AWS Elastic Container Registry (ECR) kannst du eine AWS-Zugangsschlüssel-ID und einen geheimen Schlüssel angeben, und GitHub kann ein Zugriffstoken für dich abrufen und sich in deinem Namen anmelden.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>
*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>
Außerdem musst du sicherstellen, dass du über die entsprechenden AWS-IAM-Berechtigungen verfügst, um den Berechtigungstausch (z. B. sts:GetServiceBearerToken) und den ECR-Lesevorgang (entweder AmazonEC2ContainerRegistryFullAccess oder ReadOnlyAccess) durchzuführen.
Wenn du alternativ nicht möchtest, dass GitHub die Anmeldeinformationen in deinem Namen austauscht, kannst du auch ein Autorisierungstoken angeben, das du über die AWS-APIs oder die CLI abrufst.
*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = AWS
*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>
Da diese Token kurzlebig sind und regelmäßig erneuert werden müssen, empfehlen wir, eine Zugriffsschlüssel-ID und ein Geheimnis anzugeben.
Diese Geheimnisse können zwar einen beliebigen Namen haben, solange es sich bei *_CONTAINER_REGISTRY_SERVER um eine ECR-URL handelt, aber wir empfehlen die Verwendung von ECR_CONTAINER_REGISTRY_* – es sei denn, du arbeitest mit mehreren ECR-Registrierungen.
Weitere Informationen findest du in der Dokumentation zur Authentifizierung der privaten Registrierung von AWS ECR.
Gängige Imageregistrierungsserver
Im Folgenden sind einige der gängigen Imageregistrierungsserver aufgeführt:
- DockerHub -
https://index.docker.io/v1/ - GitHub Container Registry -
ghcr.io - Azure Container Registry -
<registry name>.azurecr.io - AWS Elastic Container Registry -
<aws_account_id>.dkr.ecr.<region>.amazonaws.com - Google Cloud Container Registry -
gcr.io(USA),eu.gcr.io(EU),asia.gcr.io(Asien)
Debuggen des Registrierungszugriffs für private Images
Wenn du Probleme hast, ein Image aus einer privaten Imageregistrierung zu pullen, vergewissere dich, dass du docker login -u <user> -p <password> <server> mit den Werten der oben definierten Geheimnisse ausführen kannst. Wenn die Anmeldung fehlschlägt, vergewissere dich, dass die Anmeldedaten gültig sind und dass du auf dem Server die geeigneten Berechtigungen hast, um ein Containerimage abzurufen. Wenn die Anmeldung erfolgreich war, vergewissere dich, dass diese Werte in die richtigen GitHub Codespaces-Geheimnisse kopiert wurden, entweder auf Benutzer-, Repository- oder Organisationsebene. Versuche es anschließend erneut.