Skip to content

Latest commit

 

History

History
163 lines (116 loc) · 8.12 KB

README.yarp.md

File metadata and controls

163 lines (116 loc) · 8.12 KB

YARP (Yet Another Reverse Proxy)

Important: The images from the dotnet/nightly repositories include last-known-good (LKG) builds for the next release of .NET.

See dotnet for images with official releases of .NET.

Featured Tags

  • 2.3-preview
    • docker pull mcr.microsoft.com/dotnet/nightly/yarp:2.3-preview

About

This image contains an implementation of YARP, a reverse proxy framework in .NET.

Watch discussions for Docker-related .NET announcements.

Usage

The .NET Docker samples show various ways to use .NET and Docker together. See Building Docker Images for .NET Applications to learn more.

You can run this image to launch a YARP instance.

Configuration

YARP expects the config file to be in /etc/yarp.config, and listens by default on port 5000.

Example of configuration:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "ReverseProxy": {
    "Routes": {
      "route1": {
        "ClusterId": "cluster1",
        "Match": {
          "Path": "/aspnetapp/{**catch-all}"
        },
        "Transforms": [
            { "PathRemovePrefix": "/aspnetapp" }
        ]
      }
    },
    "Clusters": {
      "cluster1": {
        "Destinations": {
          "destination1": {
            "Address": "http://aspnetapp1:8080"
          }
        }
      }
    }
  }
}

It can then be used with the following command (where my-config.config is a file containing this configuration):

docker run --rm --name myaspnetapp -d -t  mcr.microsoft.com/dotnet/samples:aspnetapp 
docker run --rm -v $(pwd)/my-config.config:/etc/yarp.config -p 5000:5000 --link myaspnetapp:aspnetapp1 mcr.microsoft.com/dotnet/yarp:latest

This example will proxy every requests from http://localhost:5000/aspnetapp to the mcr.microsoft.com/dotnet/samples:aspnetapp container deployed.

The YARP GitHub repository contains more configuration samples.

For more details, see the documentation for how to configure the image and documentation for the reverse proxy configuration.

OpenTelemetry support

This image supports OpenTelemetry. It can be configured by passing environment variables to the container:

docker run --rm -v $(pwd)/my-config.config:/etc/yarp.config -p 5000:5000 -e OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp-endpoint.internal:4317 mcr.microsoft.com/dotnet/yarp:latest

See the OTLP Exporter Configuration for all supported environment variables.

You can skip HTTPS validation for the OTLP endpoint only by passing the environment variable YARP_UNSAFE_OLTP_CERT_ACCEPT_ANY_SERVER_CERTIFICATE.

Related Repositories

.NET:

.NET Framework:

Full Tag Listing

Linux amd64 Tags

Tags Dockerfile OS Version
2.3.0-preview.2, 2.3-preview, 2-preview, latest Dockerfile Azure Linux 3.0

Linux arm64 Tags

Tags Dockerfile OS Version
2.3.0-preview.2, 2.3-preview, 2-preview, latest Dockerfile Azure Linux 3.0

Tags not listed in the table above are not supported. See the Supported Tags Policy. See the full list of tags for all supported and unsupported tags.

Support

Lifecycle

Image Update Policy

  • Base Image Updates: Images are re-built within 12 hours of any updates to their base images (e.g. debian:bookworm-slim, windows/nanoserver:ltsc2022, etc.).
  • .NET Releases: Images are re-built as part of releasing new .NET versions. This includes new major versions, minor versions, and servicing releases.
  • Critical CVEs: Images are re-built to pick up critical CVE fixes as described by the CVE Update Policy below.
  • Monthly Re-builds: Images are re-built monthly, typically on the second Tuesday of the month, in order to pick up lower-severity CVE fixes.
  • Out-Of-Band Updates: Images can sometimes be re-built when out-of-band updates are necessary to address critical issues. If this happens, new fixed version tags will be updated according to the Fixed version tags documentation.

CVE Update Policy

.NET container images are regularly monitored for the presence of CVEs. A given image will be rebuilt to pick up fixes for a CVE when:

  • We detect the image contains a CVE with a CVSS score of "Critical"
  • AND the CVE is in a package that is added in our Dockerfile layers (meaning the CVE is in a package we explicitly install or any transitive dependencies of those packages)
  • AND there is a CVE fix for the package available in the affected base image's package repository.

Please refer to the Security Policy and Container Vulnerability Workflow for more detail about what to do when a CVE is encountered in a .NET image.

Feedback

License