Über private Registries 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.:
- GitHub's Container registry, die Azure Container Registry und DockerHub für Container-Images
- Die npm registry für Node.js-Pakete.
Bestimmte GitHub Packages Registrys, einschließlich der Container registry, können so konfiguriert werden, dass Pakete bei der Erstellung des Codespaces nahtlos in GitHub Codespaces heruntergeladen werden können, ohne dass dafür Anmeldeinformationen angegeben werden müssen.
Um auf andere Container-Image-Registrys zuzugreifen, können Sie in GitHub Secrets erstellen, um die Zugriffsdaten zu speichern. Dadurch kann GitHub Codespaces auf Images zugreifen, die in dieser Registry gespeichert sind.
Zugreifen auf Pakete in Registrierungen mit spezifischen Berechtigungen
GitHub Packages Registrys, die granulare Berechtigungen unterstützen, darunter Container registry, bieten GitHub Codespaces die einfachste Möglichkeit, Pakete zu beziehen. Die Liste der GitHub Packages Registrierungen, die granulare Berechtigungen und nahtlosen GitHub Codespaces Zugriff unterstützen, finden Sie 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. Zugriff aus dem Repository übernehmen ist bei der Veröffentlichung über GitHub Actions standardmäßig ausgewählt, jedoch nicht bei der direkten Veröffentlichung in eine Registry mithilfe einer personal access token.
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 finden Sie 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 finden Sie 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 finden Sie 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 Sie ein Paket von innerhalb eines Codespace veröffentlichen möchten, müssen Sie einen personal access token (classic) mit dem write:packages Gültigkeitsbereich verwenden.
Wir empfehlen, Pakete über GitHub Actions zu veröffentlichen. Weitere Informationen findest du unter Veröffentlichen von Docker-Images und Node.js-Pakete veröffentlichen.
Zugreifen auf in anderen Registrierungen gespeicherte Images
Sie können Secrets definieren, um GitHub Codespaces den Zugriff auf andere Container-Image-Registrys als GitHubs Container registry zu ermöglichen. Wenn Sie von einer Registrierung aus auf ein Containerimage zugreifen, das keinen nahtlosen Zugriff unterstützt, überprüfen Sie, GitHub Codespaces ob drei geheime Schlüssel vorhanden sind, die den Servernamen, den Benutzernamen und personal access token eine Registrierung definieren. Wenn diese geheimen Schlüssel gefunden werden, GitHub Codespaces stellt die Registrierung in Ihrem Codespace zur Verfügung.
<*>_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 findest du unter Verwalten Ihrer kontospezifischen geheimen Schlüssel für GitHub Codespaces und 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 daher zur Laufzeit in Ihrem Codespace ein privates Docker-Image abrufen zu können, 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 Prebuild-Erstellung 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önnten Sie die folgenden geheimen Schlüssel erstellen:
ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
ACR_CONTAINER_REGISTRY_USER = acr-user-here
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>
Weitere 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 finden Sie unter Verwenden der Visual Studio Code Befehlspalette in GitHub Codespaces.
Zugreifen auf AWS Elastic Container Registry
Um auf AWS Elastic Container Registry (ECR) zuzugreifen, können Sie eine AWS-Zugriffsschlüssel-ID und einen geheimen Zugriffsschlüssel angeben, und GitHub kann für Sie ein Zugriffstoken abrufen und die Anmeldung in Ihrem Namen übernehmen.
*_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.
Alternativ können Sie, wenn Sie nicht möchten, dass GitHub den Austausch von Anmeldeinformationen für Sie durchführt, ein Autorisierungstoken angeben, das über die AWS-APIs oder die CLI abgerufen wurde.
*_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 privaten Registrierungsauthentifizierung von AWS ECR.
Gängige Imageregistrierungsserver
Im Folgenden sind einige der gängigen Imageregistrierungsserver aufgeführt:
- DockerHub -
https://index.docker.io/v1/ - GitHub Containerregistrierung -
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 ist, stellen Sie sicher, dass diese Werte entsprechend in die richtigen GitHub Codespaces geheimen Schlüssel kopiert werden, entweder auf Benutzer-, Repository- oder Organisationsebene, und versuchen Sie es erneut.