### Installing Overlaybd P2P Configuration Helm Chart Bash

Source: https://github.com/azure/peerd/blob/main/docs/usage.md

Provides the bash command to install the configure-overlaybd-p2p-helm chart using Helm, specifying the Kubernetes cluster context. This tool automates the configuration steps for Overlaybd on AKS.

```bash
CLUSTER_CONTEXT=<your-cluster-context> && \
  helm --kube-context=$CLUSTER_CONTEXT install --wait overlaybd ./tools/configure-overlaybd-p2p-helm
```

--------------------------------

### Deploying Peerd Helm Chart Bash

Source: https://github.com/azure/peerd/blob/main/docs/usage.md

Provides the bash command to install the main Peerd Helm chart into the Kubernetes cluster. It requires specifying the cluster context and the desired Peerd image reference, waiting for the deployment to complete.

```bash
CLUSTER_CONTEXT=<your-cluster-context> && \
  helm --kube-context=$CLUSTER_CONTEXT install --wait peerd ./build/package/peerd-helm \
    --set peerd.image.ref=ghcr.io/azure/acr/dev/peerd:stable
```

--------------------------------

### Example P2P Proxy GET Request - Bash

Source: https://github.com/azure/peerd/blob/main/docs/design.md

This snippet shows a sample HTTP GET request made by the Overlaybd TCMU driver to the p2p proxy server. It includes the full SAS URL for the blob and a Range header to request a specific byte range.

```bash
GET http://localhost:5000/blobs/https://westus2.data.mcr.microsoft.com/01031d61e1024861afee5d512651eb9f36fskt2ei//docker/registry/v2/blobs/sha256/1b/1b930d010525941c1d56ec53b97bd057a67ae1865eebf042686d2a2d18271ced/data?se=20230920T01%3A14%3A49Z&sig=m4Cr%2BYTZHZQlN5LznY7nrTQ4LCIx2OqnDDM3Dpedbhs%3D&sp=r&spr=https&sr=b&sv=2018-03-28&regid=01031d61e1024861afee5d512651eb9f

Range: bytes=456-990
```

--------------------------------

### Build Peerd Binary - Bash

Source: https://github.com/azure/peerd/blob/main/docs/build.md

Builds the peerd executable binary, a systemd service unit file, and copies the API swagger file. The output files are listed below the command.

```bash
$ make
```

--------------------------------

### Build Peerd Image and Deploy to Kind Cluster - Bash

Source: https://github.com/azure/peerd/blob/main/docs/build.md

Builds the peerd docker image and then creates a local Kind cluster, deploying the peerd application as a daemonset and service to each node. Waits for pods to connect.

```bash
$ make build-image && \\
    make kind-create kind-deploy
```

--------------------------------

### Run Container Image Sharing Workload on Kind - Bash

Source: https://github.com/azure/peerd/blob/main/docs/build.md

Deploys and runs the 'ctr' test workload on the Kind cluster. This workload tests peer-to-peer sharing of container images from the containerd content store.

```bash
$ make ci-kind-ctr
```

--------------------------------

### Configuring Overlaybd Snapshotter P2P JSON

Source: https://github.com/azure/peerd/blob/main/docs/usage.md

Shows the JSON configuration snippet required in the overlaybd-snapshotter configuration file (/etc/overlaybd/overlaybd.json) to enable peer-to-peer functionality and specify the Peerd address for artifact streaming.

```json
"p2pConfig": {
    "enable": true,
    "address": "http://localhost:30000/blobs"
},
```

--------------------------------

### Run Random File Sharing Workload on Kind - Bash

Source: https://github.com/azure/peerd/blob/main/docs/build.md

Deploys and runs the 'random' test workload on the Kind cluster. This workload simulates simple peer-to-peer file sharing and outputs performance metrics like download speeds and error rates.

```bash
$ make ci-kind-random
```

--------------------------------

### Viewing Peerd Pod Logs Kubectl Bash

Source: https://github.com/azure/peerd/blob/main/docs/usage.md

Provides the kubectl command to stream logs from pods labeled app=peerd within the peerd-ns namespace. The command uses the specified cluster context and follows the log output.

```bash
kubectl --context=$CLUSTER_CONTEXT -n peerd-ns logs -l app=peerd -f
```

--------------------------------

### Mermaid Diagram: Peerd DHT Topology in Kubernetes

Source: https://github.com/azure/peerd/blob/main/assets/mermaid/peerd-dht-topo.md

This Mermaid diagram visualizes the architecture of Peerd instances running DHTs across multiple Kubernetes nodes. It shows the initialization connection to the Kubernetes API server for leader election (using a Lease resource) and the state synchronization connections between the DHTs on different Peerd instances. The diagram includes a legend explaining the connection types (Initialize via TLS, State via mTLS).

```Mermaid
graph TD;
     subgraph Cluster[DHT Topology in a Kubernetes Cluster]
        direction LR
        subgraph peerd-1[Peerd]
            dht-1(DHT)
        end

        subgraph peerd-2[Peerd]
            dht-2(DHT)
        end

        subgraph peerd-3[Peerd]
            dht-3(DHT)
        end

        subgraph Node1[Node A]
            peerd-1
        end
        
        subgraph Node2[Node B]
            peerd-2(Peerd)
        end

        subgraph Node3[Node C]
            peerd-3(Peerd)
        end

        subgraph k8s-api[K8s API Server]
            lease-1((("Peerd Leader
Lease Resource")))
        end
    end

    dht-1 o-.-o |<b style="color:orange">Initialize<br><br></b>| lease-1
    dht-2 o-.-o |<b style="color:orange">Initialize<br><br></b>| lease-1
    dht-3 o-.-o |<b style="color:orange">Initialize<br><br></b>| lease-1

    dht-1 <==> |<b style="color:blue">State<br><br></b>| dht-2
    dht-1 <==> |<b style="color:blue">State<br><br></b>| dht-3
    dht-2 <==> |<b style="color:blue">State<br><br></b>| dht-3

    classDef cluster fill:#fafafa,stroke:#bbb,stroke-width:2px,color:#326ce5;
    class Node1,NodeN cluster

    classDef outer fill:#e0f7fa,stroke:#00008b,stroke-width:2px,color:#a9a9a9;
    class Cluster outer

    subgraph Legend[Legend]
        direction TB
        tls[<b style="color:orange">Initialize</b> - TLS connections]
        mtls[<b style="color:blue">State</b> - mTLS connections]
    end

    Cluster ~~~ Legend
```

--------------------------------

### Mermaid Diagram for Kubernetes Image Streaming

Source: https://github.com/azure/peerd/blob/main/assets/mermaid/normal-streaming-summary.md

Defines a Mermaid graph illustrating the process of normal image streaming within a Kubernetes cluster, showing nodes, filesystems, and interactions with an upstream registry.

```Mermaid
graph TD;
     subgraph Cluster[Normal Image Streaming in a Kubernetes Cluster]
        subgraph fs-1[Filesystem]
            subgraph store-1["Files"]
                sf-2[sha256:l2, bytes=10-4500]
            end
        end

        subgraph fs-2[Filesystem]
            subgraph store-2["Files"]
                sf-6[sha256:l6, bytes=100-1000]
                sf-3[sha256:l3, bytes=0-10000]
            end
        end

        subgraph fs-3[Filesystem]
            subgraph store-3["Files"]
                sf-4[sha256:l4, bytes=90-1000]
                sf-5[sha256:l5, bytes=0-700]
            end
        end

        subgraph Node1[Node A]
            direction TB
            kubelet["kubectl run mcr.microsoft.com/nginx:streamable"]
            fs-1

            kubelet ~~~ fs-1
        end

        subgraph Node2[Node B]
            fs-2
        end

        subgraph Node3[Node C]
            fs-3
        end
    end
    
    subgraph Upstream[Upstream Container Registry]
        acr(mcr.microsoft.com)
    end

    Node1 --> |<b style="color:blue">GET sha256:l6<br>bytes=101-500</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:l3<br>bytes10-790</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:l4<br>bytes=91-500</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:l5<br>bytes=0-700</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:l1<br>bytes=800-9000</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:c1<br>bytes=0-10000</b>| acr    

    classDef cluster fill:#fafafa,stroke:#bbb,stroke-width:2px,color:#326ce5;
    class Node1,NodeN cluster

    classDef registry fill:#e0f7fa,stroke:#00008b,stroke-width:2px,color:#326ce5;
    class acr registry

    classDef outer fill:#e0f7fa,stroke:#00008b,stroke-width:2px,color:#a9a9a9;
    class Cluster outer
```

--------------------------------

### Peer-to-Peer Image Pulling Sequence Diagram (Mermaid)

Source: https://github.com/azure/peerd/blob/main/assets/mermaid/peerd-pull-seq.md

A Mermaid sequence diagram depicting the steps involved in pulling a container image layer. It shows how a Containerd client first attempts to fetch the layer from a local Peerd instance, which may delegate the request to a Peerd on another node (peer found) or fall back to the upstream registry (upstream request). The diagram also includes an optional step for advertising state.

```Mermaid
sequenceDiagram
    Title: Peer-to-Peer Image Pulling in a Kubernetes Cluster

    box white Node A
        participant Nginx Pod
        participant Containerd Client
        participant Peerd-A
    end

    box white Node N
        participant Peerd-N
    end

    box white Upstream Registry
        participant Upstream
    end

    loop Every layer
        Containerd Client->>Peerd-A: GET sha256:l1
        Note over Containerd Client,Peerd-A: 1

        alt peer found
            Peerd-A->>Peerd-N: GET sha256:l1
            Note over Peerd-A,Peerd-N: 2
            activate Peerd-N
            Peerd-N->>Peerd-A: result
            Peerd-A->>Containerd Client: result
        else upstream request
            Containerd Client->>Upstream: GET sha256:l1
            Note over Peerd-A,Upstream: 3
            Upstream->>Containerd Client: result
        end

        opt Advertise state (async)
            activate Peerd-A
            Note right of Peerd-A: Advertise state from containerd content store
        end
    end

    Containerd Client-->Nginx Pod: start
```

--------------------------------

### Configuring Peerd P2P Settings (JSON)

Source: https://github.com/azure/peerd/blob/main/docs/design.md

This JSON snippet shows how to configure the peer-to-peer settings for Peerd. It enables the P2P feature and specifies the address where the P2P service is exposed. This configuration is typically part of a larger Peerd configuration file.

```json
"p2pConfig": {
  "enable": true,
  "address": "localhost:30000/blobs"
}
```

--------------------------------

### Mermaid Diagram for Kubernetes P2P Image Pull Flow

Source: https://github.com/azure/peerd/blob/main/assets/mermaid/peerd-pull-summary.md

This Mermaid diagram visualizes the process of pulling a container image (nginx) in a Kubernetes cluster with peer-to-peer capabilities. It depicts multiple nodes (A, B, C) running Containerd with content stores, the image manifest and its layers, an upstream registry, and a legend explaining the connection types (mTLS for peer, TLS for upstream). It shows Node A initiating a pull and retrieving layers from other nodes (peers) and the upstream registry.

```Mermaid
graph TD;
     subgraph Cluster[Peer to Peer Image Pull in a Kubernetes Cluster]
        subgraph ctr-1[Containerd]
            subgraph store-1["Content Store"]
                sl-2[sha256:l2]
            end
        end

        subgraph ctr-2[Containerd]
            subgraph store-2["Content Store"]
                sl-6[sha256:l6]
                sl-3[sha256:l3]
            end
        end

        subgraph ctr-3[Containerd]
            subgraph store-3["Content Store"]
                sl-4[sha256:l4]
                sl-5[sha256:l5]
            end
        end

        subgraph Node1[Node A]
            direction TB
            kubelet["kubectl run mcr.microsoft.com/nginx:latest"]
            ctr-1

            kubelet ~~~ ctr-1
        end

        subgraph Node2[Node B]
            ctr-2
        end

        subgraph Node3[Node C]
            ctr-3
        end
    end

    subgraph manifest-1[mcr.microsft.com/nginx@sha256:m1]
        direction TB
        c-1[config sha256:c1]
        l-1[layer sha256:l1]
        l-2[layer sha256:l2]
        l-3[layer sha256:l3]
        l-4[layer sha256:l4]
        l-5[layer sha256:l5]
        l-6[layer sha256:l6]

        c-1 ~~~ l-1
        l-1 ~~~ l-2
        l-2 ~~~ l-3
        l-3 ~~~ l-4
        l-4 ~~~ l-5
        l-5 ~~~ l-6
    end

    subgraph Upstream[Upstream Container Registry]
        acr(mcr.microsoft.com)
    end

    subgraph Legend[Legend]
        direction TB
        mtls[<b style="color:orange">Pull from Peer</b> - mTLS connections]
        tls[<b style="color:blue">Pull from Upstream</b> - TLS connections]

        mtls ~~~ tls
    end

    Legend ~~~ Upstream

    Node1 -.-> |<b style="color:orange"><br>GET sha256:l6</b>| sl-6
    Node1 -.-> |<b style="color:orange"><br>GET sha256:l3</b>| sl-3
    Node1 -.-> |<b style="color:orange"><br><br>GET sha256:l4</b>| sl-4
    Node1 -.-> |<b style="color:orange"><br>GET sha256:l5</b>| sl-5

    Node1 --> |<b style="color:blue"><br>GET sha256:l1</b>| acr
    Node1 --> |<b style="color:blue"><br>GET sha256:c1</b>| acr    

    classDef cluster fill:#fafafa,stroke:#bbb,stroke-width:2px,color:#326ce5;
    class Node1,NodeN cluster

    classDef registry fill:#e0f7fa,stroke:#00008b,stroke-width:2px,color:#326ce5;
    class acr registry

    classDef outer fill:#e0f7fa,stroke:#00008b,stroke-width:2px,color:#a9a9a9;
    class Cluster outer
```

--------------------------------

### Mermaid Diagram for Kubernetes Image Pull

Source: https://github.com/azure/peerd/blob/main/assets/mermaid/normal-pull-summary.md

Defines a Mermaid flow chart diagram showing the steps and components involved in a standard container image pull operation within a Kubernetes cluster, including interactions with an upstream registry.

```Mermaid
graph TD;
     subgraph Cluster[Normal Image Pull in a Kubernetes Cluster]
        subgraph ctr-1[Containerd]
            subgraph store-1["Content Store"]
                sl-2[sha256:l2]
            end
        end

        subgraph ctr-2[Containerd]
            subgraph store-2["Content Store"]
                sl-6[sha256:l6]
                sl-3[sha256:l3]
            end
        end

        subgraph ctr-3[Containerd]
            subgraph store-3["Content Store"]
                sl-4[sha256:l4]
                sl-5[sha256:l5]
            end
        end

        subgraph Node1[Node A]
            direction TB
            kubelet["kubectl run mcr.microsoft.com/nginx:latest"]
            ctr-1

            kubelet ~~~ ctr-1
        end

        subgraph Node2[Node B]
            ctr-2
        end

        subgraph Node3[Node C]
            ctr-3
        end
    end
    
    subgraph Upstream[Upstream Container Registry]
        acr(mcr.microsoft.com)
    end

    Node1 --> |<b style="color:blue">GET sha256:l6</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:l3</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:l4</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:l5</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:l1</b>| acr
    Node1 --> |<b style="color:blue">GET sha256:c1</b>| acr    

    classDef cluster fill:#fafafa,stroke:#bbb,stroke-width:2px,color:#326ce5;
    class Node1,NodeN cluster

    classDef registry fill:#e0f7fa,stroke:#00008b,stroke-width:2px,color:#326ce5;
    class acr registry

    classDef outer fill:#e0f7fa,stroke:#00008b,stroke-width:2px,color:#a9a9a9;
    class Cluster outer
```

--------------------------------

### Delete Kind Cluster - Bash

Source: https://github.com/azure/peerd/blob/main/docs/build.md

Deletes the local Kind Kubernetes cluster, removing all deployed resources and the cluster itself.

```bash
$ make kind-delete
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.