diff --git a/content/en/actions/private_actions/update_private_action_runner.md b/content/en/actions/private_actions/update_private_action_runner.md index e2c1fc44107..a60bf349a6f 100644 --- a/content/en/actions/private_actions/update_private_action_runner.md +++ b/content/en/actions/private_actions/update_private_action_runner.md @@ -71,20 +71,22 @@ Update the Datadog Operator and Agent image versions in your DatadogAgent manife ```bash helm repo update helm upgrade datadog-operator datadog/datadog-operator \ - --set image.repository=datadog/operator \ - --set image.tag=latest # you can pin a specific version, see available tags on [Docker Hub][102] + --set image.repository=registry.datadoghq.com/operator \ + --set image.tag=latest ``` + You can pin a specific version. To browse available tags, use [Docker Hub][102]. + 2. Update the Agent image versions in your `datadog-agent.yaml` manifest: ```yaml override: nodeAgent: image: - name: datadog/agent: + name: registry.datadoghq.com/agent: clusterAgent: image: - name: datadog/cluster-agent: + name: registry.datadoghq.com/cluster-agent: ``` 3. Apply the updated manifest: diff --git a/content/en/actions/private_actions/use_private_actions.md b/content/en/actions/private_actions/use_private_actions.md index fb3f083ccfc..5d1ae8ec696 100644 --- a/content/en/actions/private_actions/use_private_actions.md +++ b/content/en/actions/private_actions/use_private_actions.md @@ -184,7 +184,7 @@ Install the Datadog Operator version 1.25.0: helm repo add datadog https://helm.datadoghq.com helm repo update helm install datadog-operator datadog/datadog-operator \ - --set image.repository=datadog/operator \ + --set image.repository=registry.datadoghq.com/operator \ --set image.tag=1.25.0 ``` diff --git a/content/en/agent/configuration/secrets-management.md b/content/en/agent/configuration/secrets-management.md index fa3694cd876..fa45a8f1db3 100644 --- a/content/en/agent/configuration/secrets-management.md +++ b/content/en/agent/configuration/secrets-management.md @@ -855,7 +855,7 @@ docker service create \ --env DD_SECRET_BACKEND_TYPE="docker.secrets" \ --env DD_SITE="datadoghq.com" \ --env DD_HOSTNAME="dd-agent" \ - datadog/agent:latest + registry.datadoghq.com/agent:latest ``` The secret `dd_api_key` is automatically mounted at `/run/secrets/dd_api_key`, and the Agent reads it using the `docker.secrets` backend. @@ -869,7 +869,7 @@ version: '3.8' services: datadog: - image: datadog/agent:latest + image: registry.datadoghq.com/agent:latest environment: - DD_API_KEY=ENC[dd_api_key] - DD_SECRET_BACKEND_TYPE=docker.secrets diff --git a/content/en/agent/guide/agent-v6-python-3.md b/content/en/agent/guide/agent-v6-python-3.md index 6a020daf9e0..ab1de0d29dc 100644 --- a/content/en/agent/guide/agent-v6-python-3.md +++ b/content/en/agent/guide/agent-v6-python-3.md @@ -59,7 +59,7 @@ To keep the Datadog Agent updated, edit your `datadog-values.yaml` to remove any To use a specific container registry, set it with `agent.image.repository` and `clusterChecksRunner.image.repository`. Ensure that `agents.image.tag` and `clusterChecksRunner.image.tag` are undefined. -The default registry is `gcr.io/datadoghq/agent`. +When the image repository is unset, the Helm chart derives it from `datadog.site`, cluster type, and `registryMigrationMode`. ```yaml agent: @@ -143,7 +143,7 @@ spec: name: gcr.io/datadoghq/agent:6.33.0 ``` -Use the `spec.global.registry` if you need to change the default registry. The default is `gcr.io/datadoghq`. +Use `spec.global.registry` if you need to change the registry selected from your Datadog site, cluster type, and `registryMigrationMode`. Then, pin the Agent 7 image tag in `spec.override.nodeAgent.image.tag`. @@ -279,4 +279,4 @@ datadog_config: [1]: /agent/versions/upgrade_to_agent_v7/?tab=linux [2]: /agent/configuration/agent-configuration-files/#agent-main-configuration-file -[3]: /agent/configuration/agent-commands/#restart-the-agent \ No newline at end of file +[3]: /agent/configuration/agent-commands/#restart-the-agent diff --git a/content/en/agent/guide/install-agent-6.md b/content/en/agent/guide/install-agent-6.md index 4b72c8d3411..3486412cf49 100644 --- a/content/en/agent/guide/install-agent-6.md +++ b/content/en/agent/guide/install-agent-6.md @@ -763,12 +763,12 @@ For a one-step install, run the following command. Replace `MY_API_KEY` with you On Amazon Linux v2: ```shell -docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=MY_API_KEY -e DD_SITE="datad0g.com" gcr.io/datadoghq/agent:6 +docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=MY_API_KEY -e DD_SITE="datad0g.com" registry.datadoghq.com/agent:6 ``` On other operating systems: ```shell -docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=MY_API_KEY -e DD_SITE="datad0g.com" gcr.io/datadoghq/agent:6 +docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=MY_API_KEY -e DD_SITE="datad0g.com" registry.datadoghq.com/agent:6 ``` #### Troubleshooting @@ -1235,4 +1235,4 @@ Alternatively, you can build the Agent binary for version 6 following the [Getti [9]: https://github.com/DataDog/dd-agent/wiki/Windows-Agent-Installation [10]: /agent/guide/windows-agent-ddagent-user/ [11]: https://github.com/DataDog/datadog-agent/blob/main/docs/dev/agent_omnibus.md#building-inside-docker-linux-only-recommended -[12]: https://github.com/DataDog/datadog-agent#getting-started \ No newline at end of file +[12]: https://github.com/DataDog/datadog-agent#getting-started diff --git a/content/en/containers/amazon_ecs/managed_instances.md b/content/en/containers/amazon_ecs/managed_instances.md index f511b28af49..6a8155f290f 100644 --- a/content/en/containers/amazon_ecs/managed_instances.md +++ b/content/en/containers/amazon_ecs/managed_instances.md @@ -629,7 +629,7 @@ To collect traces over UDS: { "containerDefinitions": [ { - "image": "datadog/agent:latest", + "image": "public.ecr.aws/datadog/agent:latest", "mountPoints": [ { "containerPath": "/var/run/datadog", diff --git a/content/en/containers/cluster_agent/_index.md b/content/en/containers/cluster_agent/_index.md index b472b0416c1..229a0a0f492 100644 --- a/content/en/containers/cluster_agent/_index.md +++ b/content/en/containers/cluster_agent/_index.md @@ -36,7 +36,7 @@ Datadog publishes container images to the Datadog Container Registry, Google Art {{% container-images-table %}} -By default, the Helm chart pulls images from Google Artifact Registry (`gcr.io/datadoghq`). The Datadog Operator chart is progressively migrating to the Datadog Container Registry (`registry.datadoghq.com`). +By default, the Datadog Agent Helm chart determines the Agent image registry from your Datadog site, cluster type, and `registryMigrationMode`. Depending on these values and environment exclusions, Agent images may be pulled from the Datadog Container Registry (`registry.datadoghq.com`) or from a site-specific registry. The Datadog Operator chart is included as a dependency of the Datadog Agent Helm chart by default. As of Datadog Operator chart version 2.19.0, when you install the Operator through that dependency, the Datadog Agent Helm chart's `registryMigrationMode` applies to Agent images managed by the Operator. The Operator Helm chart itself does not define `registryMigrationMode`; the Operator pod image is controlled separately by the Operator chart `image.repository` value.
Docker Hub is subject to image pull rate limits. If you are not a Docker Hub customer, Datadog recommends that you update your Datadog Agent and Cluster Agent configuration to pull from another registry. For instructions, see Changing your container registry.
diff --git a/content/en/containers/guide/autodiscovery-with-jmx.md b/content/en/containers/guide/autodiscovery-with-jmx.md index 5a918c0c0d2..0bbaefcdfdd 100644 --- a/content/en/containers/guide/autodiscovery-with-jmx.md +++ b/content/en/containers/guide/autodiscovery-with-jmx.md @@ -299,7 +299,7 @@ If you cannot mount these files in the Agent container (for example, on Amazon E For example: ```Dockerfile -FROM gcr.io/datadoghq/agent:latest-jmx +FROM registry.datadoghq.com/agent:latest-jmx COPY conf.d/tomcat.d/ COPY conf.d/tomcat.d/ ``` diff --git a/content/en/containers/guide/changing_container_registry.md b/content/en/containers/guide/changing_container_registry.md index 9972d121285..380ddf151c3 100644 --- a/content/en/containers/guide/changing_container_registry.md +++ b/content/en/containers/guide/changing_container_registry.md @@ -27,7 +27,7 @@ When selecting a container registry, Datadog recommends the following approach: 4. **Docker Hub**: Avoid unless you have a Docker Hub subscription, as it is subject to rate limits. Only Docker Hub supports Notary for image signature verification. -
As of version 2.19.0, the Datadog Operator chart is progressively migrating to the Datadog Container Registry (registry.datadoghq.com).
+
The Datadog Agent Helm chart determines the default Agent image registry from your Datadog site, cluster type, and registryMigrationMode. The Datadog Operator chart is included as a dependency of the Datadog Agent Helm chart by default. As of Datadog Operator chart version 2.19.0, when you install the Operator through that dependency, the Datadog Agent Helm chart's registryMigrationMode applies to Agent images managed by the Operator. The Operator Helm chart itself does not define registryMigrationMode; the Operator pod image is controlled separately by the Operator chart image.repository value.
To update your registry, update your registry values based on the type of container environment you are deploying on. You can also use a private registry, but you need to [create a pull secret][1] to pull the images. @@ -39,13 +39,13 @@ To update your containers registry, run the pull command for the new registry. T ## Kubernetes with Helm chart -To update your containers registry while deploying the Datadog Agent (or Datadog Cluster Agent) with the Datadog helm chart on Kubernetes (including GKE, EKS, AKS, and OpenShift) update the `values.yaml` to specify a different registry: +To update your containers registry while deploying the Datadog Agent (or Datadog Cluster Agent) with the Datadog Helm chart on Kubernetes (including GKE, EKS, AKS, and OpenShift), update the `values.yaml` to specify a different registry: ### Datadog Helm chart >= v2.7.0 -1. Update your `values.yaml`: +1. Update your `values.yaml`. For example, to use Amazon ECR: ```yaml - registry: registry.datadoghq.com + registry: public.ecr.aws/datadog ``` 2. Remove any overrides for `agents.image.repository`, `clusterAgent.image.repository`, or `clusterChecksRunner.image.repository` in the `values.yaml`. @@ -89,11 +89,11 @@ clusterChecksRunner: ## Kubernetes with the Datadog Operator -As of Operator chart version 2.19.0, the Datadog Operator is migrating to `registry.datadoghq.com` for both the operator image and Agent images it manages. Previously, Agent images were pulled from site-specific registries (`gcr.io/datadoghq`, `eu.gcr.io/datadoghq`, `asia.gcr.io/datadoghq`, or `datadoghq.azurecr.io`). To keep using the previous site-specific registries, set `registryMigrationMode: ""` in your Operator Helm `values.yaml`. +As of Datadog Operator chart version 2.19.0, when the Operator is installed through the Datadog Agent Helm chart dependency, the Datadog Agent Helm chart's `registryMigrationMode` can use `registry.datadoghq.com` for Agent images managed by the Operator. Earlier versions pulled Agent images from site-specific registries (`gcr.io/datadoghq`, `eu.gcr.io/datadoghq`, `asia.gcr.io/datadoghq`, or `datadoghq.azurecr.io`). To use the previous site-specific registries for Agent images in this deployment path, set `registryMigrationMode: ""` in your Datadog Agent Helm chart `values.yaml`. This setting has no effect when you explicitly set a registry, and it is not a setting in the standalone Operator Helm chart. To use a different registry for the Operator pod image, set `image.repository` in your Operator Helm `values.yaml`. To update your registry while deploying the Datadog Agent (or Datadog Cluster Agent) with the Datadog Operator: -1. Update the Datadog Agent manifest file to override the default registry (`registry.datadoghq.com`). For example, with `public.ecr.aws/datadog`: +1. Update the Datadog Agent manifest file to override the resolved registry. For example, with `public.ecr.aws/datadog`: ```yaml apiVersion: datadoghq.com/v2alpha1 kind: DatadogAgent @@ -134,7 +134,7 @@ For more information about the Datadog Operator, see [Deploying an Agent with th ### Using another container registry with Helm -You can switch from the default `registry.datadoghq.com` registry to another registry, such as `public.ecr.aws/datadog` when installing the Operator with the Helm chart: +To use another registry for the Operator pod image, such as `public.ecr.aws/datadog`, when installing the standalone Operator Helm chart: Update [`values.yaml`][6] with the new image: diff --git a/content/en/containers/guide/readonly-root-filesystem.md b/content/en/containers/guide/readonly-root-filesystem.md index 56add26333f..257193c5d04 100644 --- a/content/en/containers/guide/readonly-root-filesystem.md +++ b/content/en/containers/guide/readonly-root-filesystem.md @@ -83,7 +83,7 @@ Create a custom Datadog Agent image with pre-defined volumes for writable direct 1. Create a Dockerfile that extends the Datadog Agent image and declares volumes for required paths: ```dockerfile -FROM gcr.io/datadoghq/agent:latest +FROM registry.datadoghq.com/agent:latest VOLUME ["/etc/datadog-agent", "/opt/datadog-agent/run", "/var/run/datadog", "/var/log/datadog"] @@ -153,4 +153,3 @@ Agent flare requires write access to `/tmp/`. If generating flares is important [2]: https://docs.aws.amazon.com/eks/latest/best-practices/pod-security.html [3]: https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF [4]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html - diff --git a/content/en/containers/kubernetes/installation.md b/content/en/containers/kubernetes/installation.md index a1b8d66482e..7e6b85cdb8d 100644 --- a/content/en/containers/kubernetes/installation.md +++ b/content/en/containers/kubernetes/installation.md @@ -228,14 +228,14 @@ Datadog publishes container images to the Datadog Container Registry, Google Art {{% container-images-table %}} -By default, the Helm chart pulls images from Google Artifact Registry (`gcr.io/datadoghq`). The Datadog Operator chart is progressively migrating to the Datadog Container Registry (`registry.datadoghq.com`). +By default, the Datadog Agent Helm chart determines the Agent image registry from your Datadog site, cluster type, and `registryMigrationMode`. Depending on these values and environment exclusions, Agent images may be pulled from the Datadog Container Registry (`registry.datadoghq.com`) or from a site-specific registry. The Datadog Operator chart is included as a dependency of the Datadog Agent Helm chart by default. As of Datadog Operator chart version 2.19.0, when you install the Operator through that dependency, the Datadog Agent Helm chart's `registryMigrationMode` applies to Agent images managed by the Operator. The Operator Helm chart itself does not define `registryMigrationMode`; the Operator pod image is controlled separately by the Operator chart `image.repository` value.
Docker Hub is subject to image pull rate limits. If you are not a Docker Hub customer, Datadog recommends that you update your Datadog Agent and Cluster Agent configuration to pull from another registry. For instructions, see Changing your container registry.
{{< tabs >}} {{% tab "Datadog Operator" %}} -The Datadog Operator chart is migrating to `registry.datadoghq.com` for both the operator image and Agent images it manages. Previously, Agent images were pulled from site-specific registries (`gcr.io/datadoghq`, `eu.gcr.io/datadoghq`, `asia.gcr.io/datadoghq`, or `datadoghq.azurecr.io`). To keep using the previous site-specific registries, set `registryMigrationMode: ""` in your Operator Helm `values.yaml`. +As of Datadog Operator chart version 2.19.0, when the Operator is installed through the Datadog Agent Helm chart dependency, the Datadog Agent Helm chart's `registryMigrationMode` can use `registry.datadoghq.com` for Agent images managed by the Operator. Earlier versions pulled Agent images from site-specific registries (`gcr.io/datadoghq`, `eu.gcr.io/datadoghq`, `asia.gcr.io/datadoghq`, or `datadoghq.azurecr.io`). To keep using the previous site-specific registries for Agent images in this deployment path, set `registryMigrationMode: ""` in your Datadog Agent Helm chart `values.yaml`. This setting has no effect when you explicitly set a registry, and it is not a setting in the standalone Operator Helm chart. To use a different registry for the Operator pod image, set `image.repository` in your Operator Helm `values.yaml`. To use a different container registry, modify `global.registry` in `datadog-agent.yaml`. diff --git a/content/en/database_monitoring/setup_mysql/azure.md b/content/en/database_monitoring/setup_mysql/azure.md index 747403e5155..f4f90902961 100644 --- a/content/en/database_monitoring/setup_mysql/azure.md +++ b/content/en/database_monitoring/setup_mysql/azure.md @@ -189,7 +189,7 @@ docker run -e "DD_API_KEY=${DD_API_KEY}" \ Labels can also be specified in a `Dockerfile`, so you can build and deploy a custom agent without changing any infrastructure configuration: ```Dockerfile -FROM datadog/agent:7.36.1 +FROM registry.datadoghq.com/agent:7.36.1 LABEL "com.datadoghq.ad.check_names"='["mysql"]' LABEL "com.datadoghq.ad.init_configs"='[{}]' diff --git a/content/en/database_monitoring/setup_postgres/azure.md b/content/en/database_monitoring/setup_postgres/azure.md index df9620d4884..2bdf02cba86 100644 --- a/content/en/database_monitoring/setup_postgres/azure.md +++ b/content/en/database_monitoring/setup_postgres/azure.md @@ -315,7 +315,7 @@ For Postgres 9.6, add the following settings to the instance config where host a Labels can also be specified in a `Dockerfile`, so you can build and deploy a custom Agent without changing any infrastructure configuration: ```Dockerfile -FROM datadog/agent: +FROM registry.datadoghq.com/agent: LABEL "com.datadoghq.ad.check_names"='["postgres"]' LABEL "com.datadoghq.ad.init_configs"='[{}]' diff --git a/content/en/integrations/guide/jmxfetch-fips.md b/content/en/integrations/guide/jmxfetch-fips.md index a8529402eba..98116701d8e 100644 --- a/content/en/integrations/guide/jmxfetch-fips.md +++ b/content/en/integrations/guide/jmxfetch-fips.md @@ -88,7 +88,7 @@ Container installations must use BCFKS key store format. Use the `keytool` utili ```shell keytool -keystore java-app-keystore -genkey -alias java-app -dname CN=java-app -validity 365 -keyalg ec -storepass changeit - docker run --rm -v $(pwd):/ssl datadog/agent:latest-fips-jmx \ + docker run --rm -v $(pwd):/ssl registry.datadoghq.com/agent:latest-fips-jmx \ keytool -keystore /ssl/jmxfetch-keystore -genkey -alias jmxfetch -dname CN=jmxfetch -validity 365 -keyalg ec -storepass changeit -keypass changeit ``` @@ -97,7 +97,7 @@ Container installations must use BCFKS key store format. Use the `keytool` utili ```shell keytool -keystore java-app-keystore -export -alias java-app -rfc -file java-app-cert.pem -storepass changeit - docker run --rm -v $(pwd):/ssl datadog/agent:latest-fips-jmx \ + docker run --rm -v $(pwd):/ssl registry.datadoghq.com/agent:latest-fips-jmx \ keytool -keystore /ssl/jmxfetch-keystore -export -alias jmxfetch -rfc -file /ssl/jmxfetch-cert.pem -storepass changeit ``` @@ -106,7 +106,7 @@ Container installations must use BCFKS key store format. Use the `keytool` utili ```shell keytool -keystore java-app-truststore -import -alias jmxfetch -file jmxfetch-cert.pem -storepass changeit -noprompt - docker run --rm -v $(pwd):/ssl datadog/agent:latest-fips-jmx \ + docker run --rm -v $(pwd):/ssl registry.datadoghq.com/agent:latest-fips-jmx \ keytool -keystore /ssl/jmxfetch-truststore -import -alias java-app -file /ssl/java-app-cert.pem -storepass changeit -noprompt ``` diff --git a/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_daemonset.md b/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_daemonset.md index bef7c46a086..a180b1bfd7b 100644 --- a/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_daemonset.md +++ b/content/en/opentelemetry/setup/ddot_collector/install/kubernetes_daemonset.md @@ -152,7 +152,7 @@ When enabling additional Datadog features, always use the Datadog or OpenTelemet **Note**: As of operator `v1.22.0`, the DDOT container uses the `ddot-collector` image instead of the `-full` agent image. - When overriding the node agent image tag, use a tag >= `7.67.0` so the OTel container is scheduled (the `ddot-collector` image is only supported in >= `7.67.0`). -- The `ddot-collector` image has no `-full` variant. If you need a `-full` image, set `spec.override.nodeAgent.image.name` to a full agent image (for example, `gcr.io/datadoghq/agent:7.72.1-full`). +- The `ddot-collector` image has no `-full` variant. If you need a `-full` image, set `spec.override.nodeAgent.image.name` to a full agent image (for example, `registry.datadoghq.com/agent:7.72.1-full`). [1]: /getting_started/site [2]: /containers/guide/changing_container_registry/ diff --git a/layouts/shortcodes/csm-fargate-eks-sidecar.en.md b/layouts/shortcodes/csm-fargate-eks-sidecar.en.md index 65e5af236af..c5347384d7e 100644 --- a/layouts/shortcodes/csm-fargate-eks-sidecar.en.md +++ b/layouts/shortcodes/csm-fargate-eks-sidecar.en.md @@ -43,7 +43,7 @@ spec: mountPath: "/cws-instrumentation-volume" readOnly: true - name: datadog-agent - image: datadog/agent:latest + image: public.ecr.aws/datadog/agent:latest env: - name: DD_API_KEY value: "" @@ -64,4 +64,4 @@ spec: - name: cws-instrumentation-volume serviceAccountName: datadog-agent shareProcessNamespace: true -``` \ No newline at end of file +``` diff --git a/layouts/shortcodes/dbm-mongodb-agent-setup-docker.en.md b/layouts/shortcodes/dbm-mongodb-agent-setup-docker.en.md index 28f216e5f86..d6017500885 100644 --- a/layouts/shortcodes/dbm-mongodb-agent-setup-docker.en.md +++ b/layouts/shortcodes/dbm-mongodb-agent-setup-docker.en.md @@ -33,7 +33,7 @@ docker run -e "DD_API_KEY=${DD_API_KEY}" \ }] } }' \ - datadog/agent:${DD_AGENT_VERSION} + registry.datadoghq.com/agent:${DD_AGENT_VERSION} ``` ### Validate diff --git a/layouts/shortcodes/dbm-sqlserver-agent-setup-docker.en.md b/layouts/shortcodes/dbm-sqlserver-agent-setup-docker.en.md index 4c9677f499b..17695e6beb1 100644 --- a/layouts/shortcodes/dbm-sqlserver-agent-setup-docker.en.md +++ b/layouts/shortcodes/dbm-sqlserver-agent-setup-docker.en.md @@ -24,7 +24,7 @@ docker run -e "DD_API_KEY=${DD_API_KEY}" \ "env:" ] }]' \ - gcr.io/datadoghq/agent:${DD_AGENT_VERSION} + registry.datadoghq.com/agent:${DD_AGENT_VERSION} ``` Use the `service` and `env` tags to link your database telemetry to other telemetry through a common tagging scheme. See [Unified Service Tagging][3] on how these tags are used throughout Datadog.