Chainguard Container for heartbeat-fips

Heartbeat periodically checks the status of your services and determine whether they are available.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/heartbeat-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

The Chainguard Heartbeat Image is comparable to the official Heartbeat Image from Docker Hub. However, the Chainguard image does not run as the root user and contains only the minimum set of tools and dependencies needed to function. This means it doesn't include things like a package manager.

The Chainguard Heartbeat Image also does not ship the Chromium and Node.js components as it is in beta and not generally available.

FIPS Support

The heartbeat-fips Chainguard Image ships with a validated redistribution of the OpenSSL's FIPS provider module. For more on FIPS support in Chainguard Images, consult the guide on FIPS-enabled Chainguard Images on Chainguard Academy

Getting Started

Heartbeat image is usually deployed together with Elasticsearch to send the data to it. It can be run in docker with the configuration mounted - such as:

docker run \
  -v /path/to/heartbeat.yml:/usr/share/heartbeat/heartbeat.yml \
  cgr.dev/ORGANIZATION/heartbeat-fips

A sample, minimal configuration file is as follows:

heartbeat.monitors:
  - type: http
    id: nginx
    name: nginx
    service.name: sampleapp
    hosts: ["http://localhost:80"]
    check.response.status: [200]
    schedule: '@every 5s'
output.elasticsearch:
  enabled: false
output.file:
  path: "/tmp/output"
  filename: "metricbeat"
  rotate_every_kb: 10000
  number_of_files: 7

This will query http://localhost:80 URL every 5 seconds and store the results in /tmp/output directory.

In most cases, elasticsearch output should be used - such as:

heartbeat.monitors:
  # same content as before
output.elasticsearch:
  hosts: '${ELASTICSEARCH_HOSTS:elasticsearch:9200}'
  username: '${ELASTICSEARCH_USERNAME:}'
  password: '${ELASTICSEARCH_PASSWORD:}'

This will cause heartbeat to send data to elasticsearch, which can be configured via environment variables, but defaults to elasticsearch hostname. To run it, simply pass the values to docker run:

docker run \
  -v /path/to/heartbeat.yml:/usr/share/heartbeat/heartbeat.yml \
  -e ELASTICSEARCH_USERNAME=elasticadmin \
  -e ELASTICSEARCH_PASSWORD=.... \
  cgr.dev/ORGANIZATION/heartbeat-fips

Running on Kubernetes

There are no Helm charts that simplify the deployment of Heartbeat, but the Running Heartbeat on Kubernetes documentation provides detailed instructions on how to run it inside Kubernetes. The only change needed is to replace the image to use the one provided by Chainguard.

What are Chainguard Containers?

Chainguard Containers are minimal container images that are secure by default.

In many cases, the Chainguard Containers tagged as :latest contain only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager. Chainguard Containers are built with Wolfi, our Linux undistro designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a -dev variant.

Although the -dev container image variants have similar security features as their more minimal versions, they feature additional software that is typically not necessary in production environments. We recommend using multi-stage builds to leverage the -dev variants, copying application artifacts into a final minimal container that offers a reduced attack surface that won’t allow package installations or logins.

Learn More

To better understand how to work with Chainguard Containers, please visit Chainguard Academy and Chainguard Courses.

In addition to Containers, Chainguard offers VMs and Libraries. Contact Chainguard to access additional products.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.