Use a public registry

To accommodate diverse infrastructure requirements and organizational preferences, Dynatrace images are available on selected public registries. These images adhere to best practices, ensuring immutability and signing for enhanced security and resilience against potential supply chain risks.

Explore our supported public registries with multi-arch Dynatrace container images supporting ARM64 (AArch64), x86-64, and s390x CPU architectures on Linux, ensuring compatibility across various platforms.

This page provides instructions for using Dynatrace signed and immutable container images hosted on supported public registries.

Prerequisites

Before you begin, be sure to meet the following prerequisites:

required Dynatrace Operator version is v0.11 or later
required Target CPU architectures are ARM64 (AArch64), x86-64, and/or s390x
required Allow egress traffic to public registry

Limitations

Note that the following configurations are not supported in combination with public registries:

Application-Only monitoring without CSI driver
Classic Full-Stack monitoring - Alternatively, use a private registry for Classic Full-Stack monitoring

Start using these fortified images today for a safer and more efficient containerized monitoring experience:

Deploy Dynatrace Operator with container images from a public registry
Configure DynaKube to use container images from a public registry for monitoring components

Supported public registries

Dynatrace publishes its container images to Amazon ECR and Docker Hub:

Amazon ECR

Docker Hub

public.ecr.aws/dynatrace/dynatrace-activegate

dynatrace/dynatrace-activegate

public.ecr.aws/dynatrace/dynatrace-codemodules

dynatrace/dynatrace-codemodules

public.ecr.aws/dynatrace/dynatrace-oneagent

dynatrace/dynatrace-oneagent

public.ecr.aws/dynatrace/dynatrace-operator¹

dynatrace/dynatrace-operator

Available from Dynatrace Operator version 1.0.0

Rate limiting

Be aware that, when accessing public registries, there is a potential risk of encountering rate limiting. To ensure a smoother experience and reduce this risk, we recommend using a private registry or authenticating against the respective registry.

Image tagging

Dynatrace employs version-based image tagging for its container images and does not use mutable image tags like latest. For more information on tags, please visit the respective public registry repository.

Deploy Dynatrace Operator with images from public registry

By default, the Dynatrace Operator image dynatrace/dynatrace-operator is served by the public registry on AWS ECR.

Dynatrace Operator consists of multiple components (operator, webhook, CSI driver), all of which use the same dynatrace-operator image with specific deployment configurations per component.

The following command installs Dynatrace Operator and configures container images to be pulled from a public registry:

helm install dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \
  --create-namespace \
  --namespace dynatrace \
  --atomic \

Alternatively, an existing installation can be upgraded as follows:

helm upgrade dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \
  --reuse-values \
  --atomic \
  --namespace dynatrace

Use the following kustomization to conveniently install or update Dynatrace Operator by applying the necessary manifests.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: Dynatrace

resources:
  - namespace.yaml # can be created by `kubectl create namespace dynatrace --dry-run=client -oyaml > namespace.yaml`
  - https://github.com/Dynatrace/dynatrace-operator/releases/download/<version>/kubernetes.yaml
  - https://github.com/Dynatrace/dynatrace-operator/releases/download/<version>/kubernetes-csi.yaml # when CSI driver is used

To avoid tedious and error-prone editing of large YAML files, we recommend using either Helm or Kustomize for manifest manipulation.

If you prefer to make your modifications directly, however, be sure to adjust the image fields on all containers and pods where the dynatrace-operator image occurs.

Configure DynaKube to use images from public registry

Classic Full-Stack monitoring is not supported in combination with a public registry.

The Dynatrace Operator can easily be instructed to use images from a public registry by configuring the respective image fields in the DynaKube custom resource. The configured images will be deployed to your Kubernetes cluster to set up monitoring components.

The following DynaKube snippet demonstrates how to configure Cloud-Native Full-Stack monitoring setup leveraging the public Amazon ECR registry.

apiVersion: dynatrace.com/v1beta2
kind: DynaKube
metadata:
  name: dynakube
  namespace: dynatrace
spec:
  ...

  oneAgent:
    cloudNativeFullstack:
      ...
      image: public.ecr.aws/dynatrace/dynatrace-oneagent:<tag>
      codeModulesImage: public.ecr.aws/dynatrace/dynatrace-codemodules:<tag>
      # autoUpdate: true # has no effect - see note below
      # version:         # has no effect - see note below
      ...

  activeGate:
    ...
    image: public.ecr.aws/dynatrace/dynatrace-activegate:<tag>
    ...

Note that the autoUpdate and version fields have no effect when the image and/or codeModulesImage fields are set.

After configuring the required fields, the DynaKube custom resource must be applied to the Kubernetes cluster.

Application and Kubernetes Observability with Amazon ECR

The following custom resource describes how to configure DynaKube for Application Observability and Kubernetes observability:

apiVersion: dynatrace.com/v1beta2
kind: DynaKube
metadata:
  name: dynakube
  namespace: dynatrace
spec:
  ...

  oneAgent:
    applicationMonitoring:
      ...
      codeModulesImage: public.ecr.aws/dynatrace/dynatrace-codemodules:<tag>
      # autoUpdate: true # has no effect
      # version:         # has no effect

      useCSIDriver: true # required; defaults to false
      ...

  activeGate:
    ...
    image: public.ecr.aws/dynatrace/dynatrace-activegate:<tag>
    ...

Verify image signature

All of our immutable and signed container images adhere to best practices, enhancing security and shielding against supply chain attacks. To learn how to verify signatures and guarantee software integrity, see Verify Dynatrace image signatures.