{"meta":{"title":"Arbeiten mit der Containerregistrierung","intro":"Sie können Docker- und OCI-Images in der Container registryDatei speichern und verwalten.","product":"GitHub Packages","breadcrumbs":[{"href":"/de/packages","title":"GitHub Packages"},{"href":"/de/packages/working-with-a-github-packages-registry","title":"Arbeiten mit einer GitHub Packages-Registrierung"},{"href":"/de/packages/working-with-a-github-packages-registry/working-with-the-container-registry","title":"Containerregistrierung"}],"documentType":"article"},"body":"# Arbeiten mit der Containerregistrierung\n\nSie können Docker- und OCI-Images in der Container registryDatei speichern und verwalten.\n\n## Informationen zum Container registry\n\nDie Container registry speichert Containerimages innerhalb deiner Organisation oder deines persönlichen Kontos und ermöglicht es dir, ein Image einem Repository zuzuordnen. Du kannst wählen, ob Berechtigungen von einem Repository geerbt oder präzise Berechtigungen unabhängig von einem Repository festgelegt werden sollen. Du kannst auch anonym auf öffentliche Containerimages zugreifen.\n\n## Informationen zu Container registry Support\n\nDer Container registry unterstützt derzeit die folgenden Container-Image-Formate:\n\n* [Docker-Imagemanifest, Version 2, Schema 2](https://docs.docker.com/registry/spec/manifest-v2-2/)\n* [Spezifikationen der Open Container Initiative (OCI)](https://github.com/opencontainers/image-spec)\n\nBeim Installieren oder Veröffentlichen eines Docker-Images unterstützt Container registry fremde Layer, z. B. Windows-Images.\n\n## Authentifizierung für die Container registry\n\n> \\[!NOTE]\n> GitHub Packages unterstützt nur die Authentifizierung mit einem personal access token (classic). Weitere Informationen finden Sie unter [Verwalten deiner persönlichen Zugriffstoken](/de/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n\nDu benötigst ein Zugriffstoken, um private, interne und öffentliche Pakete zu veröffentlichen, zu installieren und zu löschen.\n\nDu kannst ein personal access token (classic) verwenden, um dich bei GitHub Packages oder der GitHub-API zu authentifizieren. Wenn du ein personal access token (classic) erstellst, kannst du dem Token je nach Bedarf verschiedene Bereiche zuweisen. Weitere Informationen zu paketbezogenen Bereichen für ein personal access token (classic) findest du unter [Informationen zu Berechtigungen für GitHub-Pakete](/de/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries).\n\nUm dich bei einer GitHub Packages-Registrierung innerhalb eines GitHub Actions-Workflows zu authentifizieren, kannst du Folgendes verwenden:\n\n* `GITHUB_TOKEN`, um Pakete zu veröffentlichen, die mit dem Workflowrepository verbunden sind.\n* Ein personal access token (classic) mit mindestens dem `read:packages`-Bereich für die Installation von Paketen, die anderen privaten Repositorys zugeordnet sind (`GITHUB_TOKEN` kann verwendet werden, wenn das Repository Lesezugriff auf das Paket enthält. Weitere Informationen findest du unter [Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen](/de/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)).\n\n### Authentifizieren in einem GitHub Actions Workflow\n\nDiese Registrierung unterstützt präzise Berechtigungen. Für Registries, die feingranulare Berechtigungen unterstützen, empfehlen wir dringend, Ihren GitHub Actions-Workflow, wenn er ein personal access token zur Authentifizierung bei einer Registry verwendet, so zu aktualisieren, dass `GITHUB_TOKEN` verwendet wird. Anleitungen zum Aktualisieren Ihrer Workflows, die sich mit einer personal access token bei einer Registry authentifizieren, finden Sie in [Veröffentlichen und Installieren eines Pakets mit GitHub Actions](/de/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions#upgrading-a-workflow-that-accesses-a-registry-using-a-personal-access-token).\n\n> \\[!NOTE]\n> Die Möglichkeit für GitHub Actions-Workflows, Pakete mithilfe der REST-API zu löschen und wiederherzustellen, befindet sich derzeit in der Öffentliche Vorschau. Änderungen sind vorbehalten.\n\nSie können einen `GITHUB_TOKEN` in einem GitHub Actions-Workflow verwenden, um über die REST-API ein Paket zu löschen oder wiederherzustellen, wenn das Token über die Berechtigung `admin` für das Paket verfügt. Repositorys, die Pakete mithilfe eines Workflows veröffentlichen, und Repositorys, die du explizit mit Paketen verbunden hast, erhalten automatisch die `admin`-Berechtigung für Pakete im Repository.\n\nWeitere Informationen zum `GITHUB_TOKEN` findest du unter [Verwenden von GITHUB\\_TOKEN für die Authentifizierung in Workflows](/de/actions/tutorials/authenticate-with-github_token#using-the-github_token-in-a-workflow). Weitere Informationen zu den Best Practices bei der Verwendung einer Registrierung in Actions findest du unter [Kompromittierte Runner](/de/actions/concepts/security/compromised-runners#cross-repository-access).\n\nSie können auch festlegen, dass Paketen unabhängig fürGitHub Codespaces undGitHub Actions Zugriffsberechtigungen erteilt werden. Weitere Informationen findest du unter [Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen](/de/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package) und [Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen](/de/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-workflow-access-to-your-package).\n\n### Authentifizieren mit einem personal access token (classic)\n\n> \\[!NOTE]\n> GitHub Packages unterstützt nur die Authentifizierung mit einem personal access token (classic). Weitere Informationen finden Sie unter [Verwalten deiner persönlichen Zugriffstoken](/de/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n\n1. Erstellen Sie ein neues personal access token (classic) mit den entsprechenden Scopes für die Aufgaben, die Sie ausführen möchten. Wenn für deine Organisation SSO notwendig ist, musst du SSO für dein neues Token aktivieren.\n\n   > \\[!NOTE]\n   > Standardmäßig wird beim Auswählen des `write:packages` Geltungsbereichs für Ihr personal access token (classic) in der Benutzeroberfläche auch der `repo` Geltungsbereich ausgewählt. Der `repo` Berechtigungsumfang gewährt unnötigen und zu weitreichenden Zugriff, weshalb wir empfehlen, ihn insbesondere für GitHub Actions-Workflows nicht zu verwenden. Weitere Informationen finden Sie unter [Kompromittierte Runner](/de/actions/concepts/security/compromised-runners#cross-repository-access). Als Workaround können Sie in der Benutzeroberfläche über diese URL nur den `write:packages` Geltungsbereich für Ihre personal access token (classic) auswählen: `https://github.com/settings/tokens/new?scopes=write:packages`\n\n   * Wähle den Bereich `read:packages` aus, um Containerimages herunterzuladen und die zugehörigen Metadaten zu lesen.\n   * Wähle den Bereich `write:packages` aus, um Containerimages herunter- und hochzuladen und die zugehörigen Metadaten zu lesen und zu schreiben.\n   * Wählen Sie den Bereich `delete:packages` aus, um Container-Images zu löschen.\n\n   Weitere Informationen finden Sie unter [Verwalten deiner persönlichen Zugriffstoken](/de/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n\n2. Speichern Sie Ihr personal access token (classic). Du solltest dein Token als Umgebungsvariable speichern.\n\n   ```shell\n   export CR_PAT=YOUR_TOKEN\n   ```\n\n3. Melden Sie sich mit der CLI für Ihren Containertyp beim Container registry-Dienst unter `ghcr.io` an.\n\n   ```shell\n   $ echo $CR_PAT | docker login ghcr.io -u USERNAME --password-stdin\n   > Login Succeeded\n   ```\n\n## Pushen von Containerimages\n\nIn diesem Beispiel wird die neueste Version von `IMAGE_NAME` gepusht.\n\n```shell\ndocker push ghcr.io/NAMESPACE/IMAGE_NAME:latest\n```\n\nErsetze `NAMESPACE` durch den Namen des persönlichen Kontos oder der Organisation, auf das bzw. die das Image festgelegt werden soll.\n\nIn diesem Beispiel wird die `2.5`-Version des Images hochgeladen.\n\n```shell\ndocker push ghcr.io/NAMESPACE/IMAGE_NAME:2.5\n```\n\nWenn du ein Paket zum ersten Mal veröffentlichst, ist die Sichtbarkeit standardmäßig auf privat eingestellt. Informationen zum Ändern der Sichtbarkeit oder zum Festlegen von Zugriffsberechtigungen findest du unter [Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen](/de/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility). Sie können ein veröffentlichtes Paket über die Benutzeroberfläche oder Befehlszeile mit einem Repository verknüpfen. Weitere Informationen finden Sie unter [Verbinden eines Repositorys mit einem Paket](/de/packages/learn-github-packages/connecting-a-repository-to-a-package).\n\nBeim Pushen eines Containerimages über die Befehlszeile wird das Image standardmäßig nicht mit einem Repository verknüpft. Dies gilt auch, wenn das Image mit einem Namespace gekennzeichnet wird, der dem Repositorynamen entspricht, z. B. `ghcr.io/octocat/my-repo:latest`.\n\nDie einfachste Möglichkeit, ein Repository mit einem Containerpaket zu verknüpfen, besteht in der Veröffentlichung des Pakets über einen Workflow mit `${{secrets.GITHUB_TOKEN}}`. Dies liegt daran, dass das Repository, das den Workflow enthält, automatisch verknüpft wird. Beachte, dass `GITHUB_TOKEN` nicht über die Berechtigung zum Pushen des Pakets verfügt, wenn du zuvor ein Paket an denselben Namespace gepusht, das Paket aber nicht mit dem Repository verbunden hast.\n\nEs wird empfohlen, die Bezeichnung `GITHUB_TOKEN` zu Ihrem `org.opencontainers.image.source` hinzuzufügen, um eine Verbindung mit einem Repository herzustellen, wenn Sie ein Image über die Befehlszeile veröffentlichen, und gleichzeitig sicherzustellen, dass `org.opencontainers.image.source` bei der Verwendung eines GitHub Actions-Workflows über die entsprechenden Berechtigungen verfügt. Weitere Informationen findest du in diesem Artikel unter [Bezeichnen von Containerimages](#labelling-container-images) sowie unter [Veröffentlichen und Installieren eines Pakets mit GitHub Actions](/de/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions).\n\n## Herunterladen von Container-Abbildern\n\n### Pullen mit „digest“\n\nUm sicherzustellen, dass du immer dasselbe Image verwendest, kannst du die exakte Version des Containerimage, die du pullen möchtest, mit dem SHA-Wert `digest` angeben.\n\n1. Um den Digest-SHA-Wert zu finden, musst du `docker inspect` oder `docker pull` verwenden und den SHA-Wert nach `Digest:` kopieren.\n\n   ```shell\n   docker inspect ghcr.io/NAMESPACE/IMAGE_NAME\n   ```\n\n   Ersetze `NAMESPACE` durch den Namen des persönlichen Kontos oder der Organisation, dem das Image zugeordnet ist.\n\n2. Entferne das Image nach Bedarf lokal.\n\n   ```shell\n   docker rmi ghcr.io/NAMESPACE/IMAGE_NAME:latest\n   ```\n\n3. Pulle das Containerimage mit `@YOUR_SHA_VALUE` dem Imagenamen.\n\n   ```shell\n   docker pull ghcr.io/NAMESPACE/IMAGE_NAME@sha256:82jf9a84u29hiasldj289498uhois8498hjs29hkuhs\n   ```\n\n### Abrufen nach Name\n\n```shell\ndocker pull ghcr.io/NAMESPACE/IMAGE_NAME\n```\n\nErsetze `NAMESPACE` durch den Namen des persönlichen Kontos oder der Organisation, dem das Image zugeordnet ist.\n\n### Abrufen nach Name und Version\n\nDieses Docker-CLI-Beispiel zeigt ein Image, das nach Namen und `1.14.1`-Versionstag gepullt wurde:\n\n```shell\n$ docker pull ghcr.io/NAMESPACE/IMAGE_NAME:1.14.1\n> 5e35bd43cf78: Pull complete\n> 0c48c2209aab: Pull complete\n> fd45dd1aad5a: Pull complete\n> db6eb50c2d36: Pull complete\n> Digest: sha256:ae3b135f133155b3824d8b1f62959ff8a72e9cf9e884d88db7895d8544010d8e\n> Status: Downloaded newer image for ghcr.io/NAMESPACE/IMAGE_NAME/release:1.14.1\n> ghcr.io/NAMESPACE/IMAGE_NAME/release:1.14.1\n```\n\nErsetze `NAMESPACE` durch den Namen des persönlichen Kontos oder der Organisation, dem das Image zugeordnet ist.\n\n### Abrufen nach Name und neuester Version\n\n```shell\n$ docker pull ghcr.io/NAMESPACE/IMAGE_NAME:latest\n> latest: Pulling from NAMESPACE/IMAGE_NAME\n> Digest: sha256:b3d3e366b55f9a54599220198b3db5da8f53592acbbb7dc7e4e9878762fc5344\n> Status: Downloaded newer image for ghcr.io/NAMESPACE/IMAGE_NAME:latest\n> ghcr.io/NAMESPACE/IMAGE_NAME:latest\n```\n\nErsetze `NAMESPACE` durch den Namen des persönlichen Kontos oder der Organisation, dem das Image zugeordnet ist.\n\n## Erstellung von Container-Images\n\nIn diesem Beispiel wird das Image `hello_docker` erstellt:\n\n```shell\ndocker build -t hello_docker .\n```\n\n## Kennzeichnung von Container-Images\n\n1. Suche die ID des Docker-Image, das du taggen möchten.\n\n   ```shell\n   $ docker images\n   > REPOSITORY                                            TAG                 IMAGE ID            CREATED             SIZE\n   > ghcr.io/my-org/hello_docker         latest            38f737a91f39        47 hours ago        91.7MB\n   > hello-world                                           latest              fce289e99eb9        16 months ago       1.84kB\n   ```\n\n2. Tagge dein Docker-Image mithilfe der Image-ID, des gewünschten Imagenamens und des gewünschten Hostingziels.\n\n   ```shell\n   docker tag 38f737a91f39 ghcr.io/NAMESPACE/NEW_IMAGE_NAME:latest\n   ```\n\nErsetze `NAMESPACE` durch den Namen des persönlichen Kontos oder der Organisation, auf das bzw. die das Image festgelegt werden soll.\n\n## Kennzeichnung von Container-Abbildern\n\nDu kannst deinem Containerimage mithilfe von vordefinierten Anmerkungsschlüsseln Metadaten hinzufügen, z. B. eine Beschreibung, eine Lizenz und ein Quellrepository. Werte für unterstützte Schlüssel werden auf der Paketseite für das Bild angezeigt.\n\nFür die meisten Images kannst du Docker-Bezeichnungen verwenden, um einem Image die Anmerkungsschlüssel hinzuzufügen. Weitere Informationen findest du unter [LABEL](https://docs.docker.com/engine/reference/builder/#label) in der offiziellen Docker-Dokumentation und unter [Vordefinierte Anmerkungsschlüssel](https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys) im Repository `opencontainers/image-spec`.\n\nBei Multi-Arch-Images kannst du dem Image eine Beschreibung hinzufügen, indem du dem Feld `annotations` im Imagemanifest den entsprechenden Anmerkungsschlüssel hinzufügst. Weitere Informationen findest du unter [Hinzufügen einer Beschreibung zu Multi-Arch-Images](#adding-a-description-to-multi-arch-images).\n\nDie folgenden Annotationsschlüssel werden in der Container registry unterstützt.\n\n| Schlüssel                              | BESCHREIBUNG                                                                                                                                                                                                                                                                              |\n| -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `org.opencontainers.image.source`      | Die URL des Repositorys, das dem Paket zugeordnet ist. Weitere Informationen finden Sie unter [Verbinden eines Repositorys mit einem Paket](/de/packages/learn-github-packages/connecting-a-repository-to-a-package#connecting-a-repository-to-a-container-image-using-the-command-line). |\n| `org.opencontainers.image.description` | Eine reine Textbeschreibung, die auf 512 Zeichen beschränkt ist. Diese Beschreibung wird auf der Paketseite unter dem Namen des Pakets angezeigt.                                                                                                                                         |\n| `org.opencontainers.image.licenses`    | Ein SPDX-Lizenzbezeichner wie MIT, der auf 256 Zeichen beschränkt ist. Die Lizenz wird auf der Paketseite auf der Randleiste „Details“ angezeigt. Weitere Informationen findest du unter [SPDX-Lizenzliste](https://spdx.org/licenses/).                                                  |\n\nUm einen Schlüssel als Docker-Bezeichnung hinzuzufügen, empfiehlt es sich, die `LABEL`-Anweisung in deines `Dockerfile` zu verwenden. Wenn du beispielsweise der Benutzer bzw. die Benutzerin `octocat` bist, dir `my-repo` gehört und dein Image unter den Bedingungen der MIT-Lizenz verteilt wird, musst du deinem `Dockerfile` die folgenden Zeilen hinzufügen:\n\n```dockerfile\nLABEL org.opencontainers.image.source=https://github.com/octocat/my-repo\nLABEL org.opencontainers.image.description=\"My container image\"\nLABEL org.opencontainers.image.licenses=MIT\n```\n\n> \\[!NOTE]\n> Wenn du ein Paket veröffentlichst, das mit einem Repository verknüpft ist, erbt das Paket automatisch die Zugriffsberechtigungen des verknüpften Repositorys, und GitHub Actions-Workflows im verknüpften Repository erhalten automatisch Zugriff auf das Paket – es sei denn, deine Organisation hat die automatische Vererbung von Zugriffsberechtigungen deaktiviert. Weitere Informationen finden Sie unter [Konfigurieren der Zugriffssteuerung und Sichtbarkeit von Paketen](/de/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#about-inheritance-of-access-permissions).\n\nAlternativ kannst du einem Image auch mit dem Befehl `docker build` zur Buildzeit Bezeichnungen hinzufügen.\n\n```shell\n$ docker build \\\n --label \"org.opencontainers.image.source=https://github.com/octocat/my-repo\" \\\n --label \"org.opencontainers.image.description=My container image\" \\\n --label \"org.opencontainers.image.licenses=MIT\"\n```\n\n### Hinzufügen einer Beschreibung zu Multi-Arch-Images\n\nEin Multi-Arch-Image ist ein Image, das mehrere Architekturen unterstützt. Es funktioniert, indem innerhalb eines einzelnen Manifests auf eine Liste von Images verwiesen wird, die jeweils eine andere Architektur unterstützen.\n\nDie Beschreibung, die auf der Paketseite für ein Multi-Arch-Image angezeigt wird, wird aus dem `annotations`-Feld im Imagemanifest abgerufen. Wie Docker-Bezeichnungen bieten Anmerkungen eine Möglichkeit, Metadaten einem Image zuzuordnen und vordefinierte Anmerkungsschlüssel zu unterstützen. Weitere Informationen findest du unter [Anmerkungen](https://github.com/opencontainers/image-spec/blob/main/annotations.md) im `opencontainers/image-spec`-Repository.\n\nUm eine Beschreibung für ein Multi-Arch-Image bereitzustellen, lege wie folgt einen Wert für den `org.opencontainers.image.description`-Schlüssel im Feld `annotations` des Manifests fest.\n\n```json\n\"annotations\": {\n  \"org.opencontainers.image.description\": \"My multi-arch image\"\n}\n```\n\nZum Beispiel erstellt und pusht der folgende GitHub Actions Workflowschritt ein Multi-Arch-Image. Der `outputs`-Parameter legt die Beschreibung für das Image fest.\n\n```yaml\n# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.\n# Sie werden von einem Drittanbieter bereitgestellt und unterliegen\n# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support\n# Onlinedokumentation.\n\n- name: Build and push Docker image\n  uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4\n  with:\n    context: .\n    file: ./Dockerfile\n    platforms: ${{ matrix.platforms }}\n    push: true\n    outputs: type=image,name=target,annotation-index.org.opencontainers.image.description=My multi-arch image\n```\n\n## Problembehandlung\n\n* Der Container registry hat ein Größenlimit von 10 GB pro Ebene.\n* Das Container registry Zeitlimit für Uploads beträgt 10 Minuten."}