Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page explique comment modifier les artefacts système dans l'appliance Google Distributed Cloud (GDC) isolée.
Modifiez les artefacts système dans GDC pour gérer et affiner votre déploiement.
Avant de commencer
Pour modifier les artefacts système, vous devez obtenir un accès aux diagnostics et disposer des rôles d'identité et d'accès nécessaires :
L'accès aux diagnostics est un mode d'accès privilégié requis pour aider un client de manière sécurisée lorsqu'il rencontre un problème. Vous devez créer une demande pour obtenir cet accès.
Débogueur System Artifact Registry : dispose d'un accès en lecture et en écriture à toutes les ressources Harbor. Demandez à votre administrateur de sécurité de vous accorder le rôle de cluster "Débogueur System Artifact Registry" (sar-debugger).
Debugger secret harbor-system System Artifact Registry : il dispose d'un accès au débogueur dans l'espace de noms harbor-system. Demandez à votre administrateur de sécurité de vous accorder le rôle Debugger du secret harbor-system System Artifact Registry (sar-harbor-system-secret-debugger).
Importer des images Docker
Pour modifier les artefacts système, vous devez importer de nouvelles images Docker. La méthode d'importation dépend du registre vers lequel vous transférez vos images de conteneurs :
Les sections suivantes présentent les instructions d'importation pour les deux types de registres.
Importer l'image de conteneur dans la machine bootstrap
Pour importer des images de conteneur dans Artifact Registry sur la machine bootstrap, procédez comme suit :
Assurez-vous d'avoir l'image Docker modifiée avec les problèmes de rupture corrigés.
Transférez la nouvelle image vers le nœud d'amorçage de votre environnement GDC.
Connectez-vous au nœud d'amorçage.
Localisez l'adresse d'Artifact Registry sur la machine d'amorçage au moment de l'amorçage et définissez-la comme variable d'environnement REGISTRY_IP :
Importer l'image de conteneur dans le cluster d'infrastructure de l'organisation
Pour importer des images de conteneurs dans Artifact Registry sur un cluster d'infrastructure d'organisation, procédez comme suit :
Assurez-vous d'avoir l'image Docker modifiée avec les problèmes de rupture corrigés.
Transférez la nouvelle image vers un nœud disposant d'un accès racine avec un fichier kubeconfig racine vers le cluster d'infrastructure de l'organisation dans votre environnement isolé.
Exportez le chemin d'accès du cluster d'infrastructure de l'organisation kubeconfig en tant que variable d'environnement :
exportORG_INFRA_KUBECONFIG=KUBECONFIG_FILE_PATH
Remplacez KUBECONFIG_FILE_PATH par le chemin d'accès au fichier kubeconfig.
Localisez l'adresse Artifact Registry dans le cluster et définissez-la comme variable d'environnement REGISTRY_IP :
Récupérez les identifiants permettant d'accéder à Artifact Registry. Utilisez la commande suivante pour récupérer le compte et le mot de passe de l'administrateur :
Utilisez les commandes gdcloud artifacts pour modifier les artefacts système dans GDC. Mettez à jour, personnalisez et sécurisez votre déploiement en effectuant des actions telles que le remplacement de packages logiciels, l'ajustement des configurations et l'application de correctifs.
Effectuez les actions suivantes :
Gérez les packages apt.
Créez et extrayez des images à partir de packages OCI.
Répertoriez les versions disponibles de l'image OCI racine.
Corrigez les packages existants.
Transférer et extraire des packages OCI vers et depuis un registre.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["# Modify system artifacts\n\nThis page describes how to modify your system artifacts in Google Distributed Cloud (GDC) air-gapped appliance.\n\nModify system artifacts in GDC to manage and refine your deployment,\n\nBefore you begin\n----------------\n\nTo modify system artifacts, you must get diagnostic access and have access to the necessary identity and access roles:\n\n- Diagnostic access is a privileged access mode required to securely support a customer when they encounter an issue. You must create a ticket to have this access granted.\n- System Artifact Registry Debugger: has read and write access to all Harbor resources. Ask your Security Admin to grant you the System Artifact Registry Debugger (`sar-debugger`) cluster role.\n- System Artifact Registry harbor-system secret Debugger: has debugger access in the `harbor-system` namespace. Ask your Security Admin to grant you the System Artifact Registry harbor-system secret Debugger (`sar-harbor-system-secret-debugger`) role.\n\nUpload Docker images\n--------------------\n\nTo modify system artifacts, you must upload new Docker images. The upload method\ndepends on which of the following two registries you push your container images\nto:\n\n- Upload container images to [the Artifact Registry in the bootstrap machine](#bootstrap-registry).\n- Upload container images to [the Artifact Registry in the org infrastructure cluster](#registry-admin-cluster).\n\nThe following sections show the upload instructions for the two registry types.\n\n### Upload container image in the bootstrap machine\n\nTo upload container images to the Artifact Registry in the bootstrap machine, complete the\nfollowing steps:\n\n1. Ensure you have the modified Docker image with the breaking issues fixed.\n\n2. Transfer the new image to the bootstrap node in your GDC\n environment.\n\n3. Sign in to the bootstrap node.\n\n4. Locate the address of the Artifact Registry in the bootstrap machine at bootstrap time and set\n it as the \u003cvar translate=\"no\"\u003eREGISTRY_IP\u003c/var\u003e environment variable:\n\n REGISTRY=$(kubectl get harborcluster harbor -n harbor-system -o=jsonpath='{.spec.externalURL}')\n\n REGISTRY_IP=${REGISTRY#https://}\n\n5. Retrieve the credential for accessing the Artifact Registry. Retrieve the administrator account and password:\n\n ADMIN_PASS=$(kubectl -n harbor-system get secret harbor-admin \\\n -o jsonpath=\"{.data.secret}\" | base64 -d)\n\n6. Sign in to the Artifact Registry:\n\n docker login $REGISTRY_IP -u admin -p $ADMIN_PASS\n\n A `Login Succeeded` message prints to verify a successful login\n to the Artifact Registry.\n7. Tag the new image:\n\n docker image tag \u003cvar translate=\"no\"\u003eCONTAINER_IMAGE_URL\u003c/var\u003e \\\n $REGISTRY_IP/\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e/\u003cvar translate=\"no\"\u003eIMAGE_NAME\u003c/var\u003e:\u003cvar translate=\"no\"\u003eTAG\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCONTAINER_IMAGE_URL\u003c/var\u003e: the local container image URL, such as `gcr.io/repository/image:tag`.\n - \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e: the Artifact Registry project name.\n - \u003cvar translate=\"no\"\u003eIMAGE_NAME\u003c/var\u003e: the container image name.\n - \u003cvar translate=\"no\"\u003eTAG\u003c/var\u003e: the container image tag.\n8. Push the new image to the Artifact Registry:\n\n docker image push $REGISTRY_IP/PROJECT_NAME/IMAGE_NAME:TAG\n\n### Upload container image to the org infrastructure cluster\n\nTo upload container images to the Artifact Registry on a org infrastructure cluster, complete the following steps:\n\n1. Ensure you have the modified Docker image with the breaking issues fixed.\n\n2. Transfer the new image to a node that has root access with a root\n `kubeconfig` file to the org infrastructure cluster\n in your air-gapped environment.\n\n3. Export the org infrastructure cluster `kubeconfig` path as an environment variable:\n\n export ORG_INFRA_KUBECONFIG=\u003cvar translate=\"no\"\u003eKUBECONFIG_FILE_PATH\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eKUBECONFIG_FILE_PATH\u003c/var\u003e with the path to the `kubeconfig` file.\n4. Locate the in-cluster Artifact Registry address and set it as the\n \u003cvar translate=\"no\"\u003eREGISTRY_IP\u003c/var\u003e environment variable:\n\n REGISTRY=$(kubectl --kubeconfig $ORG_INFRA_KUBECONFIG get harborcluster /\n harbor -n harbor-system -o=jsonpath='{.spec.externalURL}')\n\n REGISTRY_IP=${REGISTRY#https://}\n\n5. Ensure the \u003cvar translate=\"no\"\u003eREGISTRY_IP\u003c/var\u003e contains a valid URL, such as\n `10.200.0.36:10443`:\n\n echo ${REGISTRY_IP}\n\n6. Check whether the certificate authority (CA) certificate exists:\n\n ls -al /etc/docker/certs.d/${REGISTRY_IP}/ca.crt\n\n If the certificate does not exist, create and configure it: \n\n mkdir -p /etc/docker/certs.d/${REGISTRY_IP}/\n\n chmod 755 /etc/docker/certs.d/${REGISTRY_IP}/\n\n echo $(kubectl get secret harbor-cert-secret -n istio-system -o jsonpath='{.data.ca\\.crt}' --kubeconfig $ORG_INFRA_KUBECONFIG) | openssl base64 -A -d \u003e /etc/docker/certs.d/${REGISTRY_IP}/ca.crt\n\n chmod 755 /etc/docker/certs.d/${REGISTRY_IP}/ca.crt\n\n7. Retrieve the credential for accessing the Artifact Registry. Use the following command\n to retrieve the administrator account and password:\n\n ADMIN_PASS=$(kubectl --kubeconfig $ORG_INFRA_KUBECONFIG \\\n -n harbor-system get secret harbor-admin \\\n -o jsonpath=\"{.data.secret}\" | base64 -d)\n\n8. Sign in to the Artifact Registry:\n\n docker login $REGISTRY_IP -u admin -p $ADMIN_PASS\n\n A `Login Succeeded` message prints to verify a successful login\n to the Artifact Registry.\n9. Tag the new image:\n\n docker image tag \u003cvar translate=\"no\"\u003eCONTAINER_IMAGE_URL\u003c/var\u003e \\\n $REGISTRY_IP/\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e/\u003cvar translate=\"no\"\u003eIMAGE_NAME\u003c/var\u003e:\u003cvar translate=\"no\"\u003eTAG\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCONTAINER_IMAGE_URL\u003c/var\u003e: the local container image URL, such as `gcr.io/repository/image:tag`.\n - \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e: the Artifact Registry project name.\n - \u003cvar translate=\"no\"\u003eIMAGE_NAME\u003c/var\u003e: the container image name.\n - \u003cvar translate=\"no\"\u003eTAG\u003c/var\u003e: the container image tag.\n10. Push the new image to the Artifact Registry:\n\n docker image push $REGISTRY_IP/PROJECT_NAME/IMAGE_NAME:TAG\n\nModify system artifacts\n-----------------------\n\nUse the `gdcloud artifacts` commands to modify system artifacts in GDC. Update, customize, and secure your deployment by performing actions like replacing software packages, adjusting configurations, and applying patches.\n\nPerform the following actions:\n\n- Manage `apt` packages.\n- Build and extract images from OCI packages.\n- List available versions of the root OCI image.\n- Patch existing packages.\n- Pull and push OCI packages to and from a registry.\n- Display the structure of an OCI bundle.\n- Unpack OCI bundles.\n\nFor more information, see [`gdcloud artifacts`](/distributed-cloud/hosted/docs/latest/appliance/resources/gdcloud-reference/gdcloud-artifacts)."]]
