### Install and Run Consul as a Daemon with Exec Resource

Source: https://jumppad.dev/resources/exec

This example demonstrates using the `exec` resource to first download and install Consul, then run it as a background daemon. The installation script checks for existing binaries and downloads the appropriate version based on the OS and architecture. The daemon process is configured to run continuously using `daemon = true` and depends on the installation step.

```HCL
resource "exec" "install" {
  script = <<-EOF
  #!/bin/sh
  OS=$(uname -s | tr '[:upper:]' '[:lower:]')
  ARCH=$(uname -m | tr '[:upper:]' '[:lower:]')

  if [ ! -f /tmp/consul ]; then
    curl -L -o /tmp/consul.zip \
      https://releases.hashicorp.com/consul/1.16.2/consul_1.16.2_$${OS}_$${ARCH}.zip
    cd /tmp && unzip ./consul.zip
  fi
  EOF
}

resource "exec" "run" {
  depends_on = ["resource.exec.install"]

  script = <<-EOF
  #!/bin/sh
  /tmp/consul agent -dev
  EOF

  daemon = true
}
```

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

### Execute Quick Install Script for Jumppad

Source: https://jumppad.dev/introduction/installation

Run this command in your terminal to download and execute the latest Jumppad installation script. The script will prompt for administrator access if necessary to install Jumppad to /usr/local/bin/jumppad.

```bash
curl https://jumppad.dev/install | bash
```

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

### Verify Jumppad Quick Installation Output

Source: https://jumppad.dev/introduction/installation

This is the expected terminal output after a successful quick installation of Jumppad. It confirms the installation path, provides instructions for uninstallation, and shows system diagnostics for required dependencies like Docker, Git, and xdg-open.

```bash
################################
Installing Jumppad to /usr/local/bin/jumppad

Please note: You may be prompted for your password

To remove Jumppad and all configuration use the command "jumppad uninstall"
Downloading https://github.com/jumppad-labs/jumppad/releases/download/v0.1.0/jumppad_0.1.0_linux_x86_64.tar.gz
/usr/bin/sudo
[sudo] password for nicj:

###### SYSTEM DIAGNOSTICS ######
 [   OK    ] Docker
 [   OK    ] Git
 [   OK    ] xdg-open
```

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

### Complete Jumppad Docs Resource Configuration Example

Source: https://jumppad.dev/resources/docs/docs

A comprehensive example demonstrating the configuration of a `docs` resource, including network attachment, image specification, logo settings, and content/asset paths.

```HCL
resource "docs" "docs" {
  network {
    id = resource.network.main.meta.id
  }

  image {
    name = "ghcr.io/jumppad-labs/docs:v0.4.0"
  }

  logo {
    url = "https://mycompany.com/logo.png"
    width = 32
    height = 32
  }

  content = [
    module.course.output.book
  ]

 assets = "${dir()}/assets"
}
```

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

### Clone Jumppad Examples Repository Locally

Source: https://jumppad.dev/introduction/running

This snippet demonstrates how to clone the Jumppad examples Git repository to your local machine and navigate into its directory, which is a prerequisite for running blueprints from the local filesystem.

```shell
git clone https://github.com/jumppad-labs/examples.git
cd examples
```

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

### Jumppad Build Resource Container Configuration Example

Source: https://jumppad.dev/resources/build

Example configuration for the `container` block within a Jumppad `build` resource, specifying the Dockerfile and build context for image creation.

```Jumppad Configuration
container {
  dockerfile = "Dockerfile"
  context    = "./src"
}
```

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

### Jumppad Build Resource Output Configuration Example

Source: https://jumppad.dev/resources/build

Example configuration for the `output` block within a Jumppad `build` resource, demonstrating how to copy artifacts from the built container image to the local filesystem.

```Jumppad Configuration
output {
  source = "/bin/myapp"
  destination = "${data("local_app")}/bin"
}
```

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

### CLI Example of Jumppad Down Command Execution

Source: https://jumppad.dev/cli/down

Illustrates an example execution of the `jumppad down` command, showing the log output as various resources like Kubernetes configuration, Ingress, Cluster, and Network are destroyed.

```shell
jumppad down

2020-08-16T13:33:31.160+0100 [INFO]  Destroy Kubernetes configuration: ref=app config=[/home/nicj/go/src/github.com/jumppad-run/jumppad-website/examples/simple_kubernetes/k8s_app]
2020-08-16T13:33:31.160+0100 [INFO]  Destroy Ingress: ref=app type=ingress
2020-08-16T13:33:31.394+0100 [INFO]  Destroy Cluster: ref=k3s
2020-08-16T13:33:31.832+0100 [INFO]  Destroy Network: ref=local
```

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

### Example Output of HereDoc Template

Source: https://jumppad.dev/resources/template

This snippet shows the resulting configuration file generated by the HereDoc template example, with the `data_dir` variable interpolated to `/tmp`.

```HCL
data_dir = "/tmp"
log_level = "DEBUG"

datacenter = "dc1"
primary_datacenter = "dc1"

server = true

bootstrap_expect = 1
ui = true

bind_addr = "0.0.0.0"
client_addr = "0.0.0.0"
advertise_addr = "10.6.0.200"

ports {
  grpc = 8502
}

connect {
  enabled = true
}
```

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

### CLI Example: Show a single jumppad output variable

Source: https://jumppad.dev/cli/output

This example illustrates how to retrieve the value of a specific output variable, such as `KUBECONFIG`, by providing its name as an argument to the `jumppad output` command.

```bash
jumppad output KUBECONFIG
/home/nicj/.jumppad/config/k3s/kubeconfig-docker.yaml
```

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

### CLI Example: Show all jumppad output variables

Source: https://jumppad.dev/cli/output

This example demonstrates how to use the `jumppad output` command without arguments to display all defined output variables in a JSON formatted string.

```bash
jumppad output
{
  "KUBECONFIG": "/home/nicj/.jumppad/config/k3s/kubeconfig-docker.yaml"
}
```

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

### Install Jumppad using Homebrew on macOS

Source: https://jumppad.dev/introduction/installation

Use this Homebrew command to install Jumppad on macOS systems. Homebrew is a popular package manager for macOS that simplifies software installation.

```bash
brew install jumppad-labs/homebrew-repo/jumppad
```

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

### Example Kubernetes Config Resource Definition

Source: https://jumppad.dev/resources/k8s/kubernetes_config

This HCL example demonstrates how to define a `k8s_config` resource. It links to a Kubernetes cluster, specifies paths to configuration files, and sets `wait_until_ready` to true for readiness checks.

```HCL
resource "k8s_config" "app" {
  cluster = resource.k8s_cluster.k3s

  paths = [
    "./k8s_config/app",
    "./k8s_config/dashboard",
  ]

  wait_until_ready = true
}
```

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

### Jumppad Up: Create Stack from Specific File

Source: https://jumppad.dev/cli/up

Example showing how to deploy a stack by specifying a particular Jumppad configuration file.

```cli
jumppad up my-stack/network.hcl
... output
```

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

### Example HCL Configuration for Chapter Resource

Source: https://jumppad.dev/resources/docs/chapter

Demonstrates how to define a `chapter` resource in HCL, linking it to various `task` resources and including multiple content pages from local files.

```HCL
resource "chapter" "installation" {
  title = "Install terraform"

  tasks = {
    manual_installation = resource.task.manual_installation
    verify_installation = resource.task.verify_installation
    terraform_version = resource.task.terraform_version
  }

  page "manual_installation" {
    content = file("docs/installation/manual_installation.mdx")
  }

  page "verify_installation" {
    content = file("docs/installation/verify_installation.mdx")
  }

  page "terraform_version" {
    content = file("docs/installation/terraform_version.mdx")
  }
}
```

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

### Ingress Example: Exposing Kubernetes Remote Service

Source: https://jumppad.dev/resources/ingress

Example of configuring an `ingress` resource to expose a Kubernetes service's port in a specific namespace, making it accessible locally.

```HCL
resource "ingress" "fake_service_1" {
  port = 19090

  target {
    resource = resource.k8s_cluster.k3s.meta.id
    port = 9090

    config = {
      service   = "fake-service"
      namespace = "default"
    }
  }
}
```

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

### Example of `book` Resource Definition in HCL

Source: https://jumppad.dev/resources/docs/book

Demonstrates how to define a `book` resource using HCL, setting its title and linking to multiple `chapter` resources.

```HCL
resource "book" "terraform_basics" {
  title = "Understanding Terraform basics"

  chapters = [
    resource.chapter.introduction,
    resource.chapter.installation,
    resource.chapter.workflow,
    resource.chapter.providers,
    resource.chapter.state,
    resource.chapter.summary
  ]
}
```

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

### Load Template from External File in HCL

Source: https://jumppad.dev/resources/template

This example demonstrates using the `file` function to load template content from an external file. It also shows how the `template` resource can be used as a dependency for a `container` resource, ensuring the template is processed before the container starts.

```HCL
resource "template "consul_config" {

  source = file("./mytemplate.hcl")
  destination = "./consul_config/consul.hcl"

  variables = {
    data_dir = "/tmp"
  }
}

container "consul" {
  depends_on = ["template.consul_config"]

  image   {
    name = "consul:${variable.consul_version}"
  }

  command = ["consul", "agent", "-config-file=/config/consul.hcl"]

  volume {
    source      = resource.template.consul_config.destination
    destination = "/config/consul.hcl"
  }
}
```

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

### Gherkin Statement: Running Blueprint with Specific Jumppad Version

Source: https://jumppad.dev/cli/test

This Gherkin example shows how to use the `I have a running blueprint using version "<version>"` statement to start a blueprint with a specified jumppad version.

```Gherkin
Scenario: Single Container from Local Blueprint
  Given I have a running blueprint using version "0.1.2"
```

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

### Install Helm Chart from GitHub Repository (HCL)

Source: https://jumppad.dev/resources/helm

Illustrates installing a Helm chart directly from a GitHub repository. The chart is specified by its GitHub URL, and custom values are provided inline using "values_string".

```HCL
resource "helm" "vault" {
  cluster = resource.k8s_cluster.k3s
  chart = "github.com/hashicorp/vault-helm"

  values_string = {
    "server.dataStorage.size" = "128Mb"
  }
}
```

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

### Container Property: Command Execution

Source: https://jumppad.dev/resources/container/container

Command allows you to specify a command to execute when starting a container. Command is specified as an array of strings, each part of the command is a separate string. For example, to start a container and follow logs at /dev/null the following command could be used.

```APIDOC
Name: command
Type: ([]string: [])
Required: 
Readonly: Readonly
Description: Command allows you to specify a command to execute when starting a container. Command is specified as an array of strings, each part of the command is a separate string.
```

```HCL
command = [
    "tail",
    "-f",
    "/dev/null"
]
```

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

### HCL: Full Container Resource Definition with Advanced Options

Source: https://jumppad.dev/resources/container/container

A comprehensive example showcasing various configuration options for a container resource. It includes dependencies, detailed network and image settings, command execution, environment variables, volume mounts, and port mappings, demonstrating a complete container setup.

```HCL
resource "container" "unique_name" {
    depends_on = ["resource.container.another"]

    network {
        id         = resource.network.cloud.meta.id
        ip_address = "10.16.0.200"
        aliases    = ["my_unique_name_ip_address"]
    }

    image {
        name     = "consul:1.6.1"
        username = "repo_username"
        password = "repo_password"
    }

    command = [
        "consul",
        "agent"
    ]

    environment = {
        CONSUL_HTTP_ADDR = "http://localhost:8500"
    }

    volume {
        source      = "./config"
        destination = "/config"
    }

    port {
        local  = 8500
        remote = 8500
        host   = 18500
    }

    port_range {
        range       = "9000-9002"
        enable_host = true
    }

    privileged = false
}
```

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

### Install Helm Chart from Helm Repository (HCL)

Source: https://jumppad.dev/resources/helm

Demonstrates installing a Helm chart from a remote Helm repository. It configures the repository URL, chart name, version, and applies values from a local file. Includes health check settings for specific pods.

```HCL
resource "helm" "consul" {
  cluster = resource.k8s_cluster.k3s

  repository {
    name = "hashicorp"
    url  = "https://helm.releases.hashicorp.com"
  }

  chart   = "hashicorp/consul"
  version = "v0.40.0"

  values = "./helm/consul-values.yaml"

  health_check {
    timeout = "240s"
    pods = [
      "component=connect-injector",
      "component=client",
      "component=controller",
      "component=server",
    ]
  }
}
```

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

### Template Resource Source Property - Local Path Example

Source: https://jumppad.dev/resources/template

Demonstrates setting the `source` property of a Template resource to a local file path.

```Configuration
source = "myfile.txt"
```

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

### Jumppad Up: Create Stack from Directory

Source: https://jumppad.dev/cli/up

Example demonstrating how to use the `jumppad up` command to recursively create a stack from the current directory or a specified local directory.

```cli
jumppad up ./-stack
... output
```

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

### Install Helm Chart from Local Folder (HCL)

Source: https://jumppad.dev/resources/helm

Shows how to install a Helm chart from a local file system path. The chart is referenced by its local folder path, and custom values are provided inline using "values_string".

```HCL
resource "helm" "vault" {
  cluster = resource.k8s_cluster.k3s
  chart   = "./files/helm/vault"

  values_string = {
    "server.dataStorage.size" = "128Mb"
  }
}
```

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

### Example: Create Jumppad Network Resource

Source: https://jumppad.dev/resources/network

This example demonstrates how to define a `network` resource named `local` using the Jumppad DSL, specifying a `subnet` of "10.10.0.0/16" for network isolation. This resource creates an isolated network environment.

```Jumppad DSL
resource "network" "local" {
  subnet = "10.10.0.0/16"
}
```

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

### Check Current Jumppad Version

Source: https://jumppad.dev/cli/version

This example shows how to execute the `jumppad version` command without any arguments to display the currently installed Jumppad version.

```Jumppad CLI
jumppad version
Current Version: 0.1.4

```

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

### Example Tailing Logs for All Running Jumppad Resources

Source: https://jumppad.dev/cli/logs

Demonstrates how to use `jumppad logs` without a specific target to view aggregated logs from all active Jumppad resources, including Docker cache, user services, and server components.

```Shell
jumppad logs
[docker-cache]       # Secondary tier caching of manifests; configure via MANIFEST_CACHE_SECONDARY_REGEX and MANIFEST_CACHE_SECONDARY_TIME
[docker-cache]       location ~ ^/v2/(.*)/manifests/(.*)(\d|\.)+(.*)(\d|\.)+(.*)(\d|\.)+ {
[docker-cache]           set $docker_proxy_request_type "manifest-secondary";
[docker-cache]           proxy_cache_valid 60d;
[docker-cache]           include "/etc/nginx/nginx.manifest.stale.conf";
[users-1]   Aug 10 12:20:16 users-1 consul[80]: 2021-08-10T12:20:16.994Z [ERROR] agent.client: RPC failed to server: method=Intention.Match server=10.0.0.3:8300 error="rpc error making call: Permission denied"
[users-1]   Aug 10 12:20:17 users-1 consul[80]: 2021-08-10T12:20:17.642Z [DEBUG] agent.client.memberlist.lan: memberlist: Stream connection from=10.0.0.3:41084
[users-1]   Aug 10 12:20:18 users-1 consul[174]: [2021-08-10 12:20:18.290][174][debug][main] [source/server/server.cc:209] flushing stats
[server]   Aug 10 12:20:47 server consul[58]: 2021-08-10T12:20:47.613Z [WARN]  agent.server.intentions: Operation on intention prefix denied due to ACLs: prefix=users accessorID=
[server]   Aug 10 12:20:47 server consul[58]: 2021-08-10T12:20:47.644Z [DEBUG] agent.server.memberlist.lan: memberlist: Initiating push/pull sync with: users-1 10.0.0.2:8301
[server]   Aug 10 12:20:48 server consul[58]: 2021-08-10T12:20:48.152Z [WARN]  agent.server.intentions: Operation on intention prefix denied due to ACLs: prefix=users accessorID=
[users-1]   Aug 10 12:20:48 users-1 consul[80]: 2021-08-10T12:20:48.152Z [ERROR] agent.client: RPC failed to server: method=Intention.Match server=10.0.0.3:8300 error="rpc error making call: Permission denied"
[users-1]   Aug 10 12:20:48 users-1 consul[174]: [2021-08-10 12:20:48.309][174][debug][main] [source/server/server.cc:209] flushing stats
```

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

### Ingress Example: Exposing Local App as Kubernetes Service

Source: https://jumppad.dev/resources/ingress

Demonstrates how to define a local `container` with exposed ports and then use an `ingress` resource to expose that local application as a Kubernetes service in a specified namespace.

```HCL
resource "container" "app" {
  image {
    name = variable.image
  }

  port {
    local  = 9090
    remote = 9090
    host = 9090
  }
}

resource "ingress" "fake_service_1" {
  port = 9090

  target {
    resource = resource.k8s_cluster.k3s
    port = 80

    config = {
      service   = "fake-service"
    }
  }
}
```

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

### Ingress Example: Exposing Nomad Remote Service

Source: https://jumppad.dev/resources/ingress

Example of configuring an `ingress` resource to expose a specific task's HTTP port within a Nomad job, making it accessible locally.

```HCL
resource "ingress" "fake_service_1" {
  port = 19090

  target {
    resource   = resource.nomad_cluster.dev
    named_port = "http"

    config = {
      job   = "example_1"
      group = "fake_service"
      task  = "fake_service"
    }
  }
}
```

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

### Install Jumppad CLI Autocomplete

Source: https://jumppad.dev/cli/overview

This command installs or uninstalls Jumppad's command-line autocomplete feature for various shells like bash, zsh, fish, or powershell.

```shell
jumppad completion [bash|zsh|fish|powershell]
```

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

### Example: Create a Root Certificate with certificate_ca

Source: https://jumppad.dev/resources/cert/certificate_ca

This example demonstrates how to define a `certificate_ca` resource named `cd_consul_ca`. The generated certificate and private key will be written to the 'certs' data output folder.

```HCL
resource "certificate_ca" "cd_consul_ca" {
  output = data("certs")
}
```

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

### Network Attachment Configuration and Examples

Source: https://jumppad.dev/resources/exec

Defines properties for attaching a container to a network, including network ID, static IP address, and aliases. Provides configuration examples for specifying network ID and assigning alternative names for container resolution.

```APIDOC
network_attachment:
  id:
    Type: (string: "")
    Required: true
    Readonly: true
    Description: ID of the network to attach the container to, specified in reference format.
  ip_address:
    Type: (string: "")
    Required: false
    Readonly: true
    Description: Static IP address to assign container for the network. If omitted, an IP address will be automatically assigned.
  aliases:
    Type: ([]string: [])
    Required: false
    Readonly: true
    Description: Aliases allow alternate names to be specified for the container for network resolution.
  name:
    Type: (string: "")
    Required: false
    Readonly: true
    Description: Name will equal the name of the network as created by jumppad.
  assigned_address:
    Type: (string: "")
    Required: false
    Readonly: true
    Description: Assigned IP address for the network. Equals ip_address if set, otherwise automatically assigned.
```

```Configuration
network {
  id = "network.cloud"
}
```

```Configuration
network {
  name    = "network.cloud"
  aliases = [
    "alt1.container.local.jmpd.in",
    "alt2.container.local.jmpd.in"
  ]
}
```

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

### Template Resource Variables Property Example

Source: https://jumppad.dev/resources/template

Shows how to define variables for the template using the `variables` property, which is a map of string keys to interface values.

```Configuration
variables = {
  data_dir = "/tmp"
}
```

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

### Example: Generate Certificate Leaf with CA

Source: https://jumppad.dev/resources/cert/certificate_leaf

Illustrates how to use the `certificate_leaf` resource in conjunction with a `certificate_ca` resource to generate a leaf certificate. This example specifies CA key and certificate paths, IP addresses, DNS names, and an output directory for the generated certificate.

```HCL
resource "certificate_ca" "cd_consul_ca" {
  output = data("certs")
}

resource "certificate_leaf" "cd_consul_server" {
  ca_key = resource.certificate_ca.cd_consul_ca.key_path
  ca_cert = resource.certificate_ca.cd_consul_ca.cert_path

  ip_addresses = ["127.0.0.1"]

  dns_names = [
    "localhost",
    "server.${var.cd_consul_dc}.consul",
    "1.consul.server.container.local.jmpd.in",
    "2.consul.server.container.local.jmpd.in",
    "3.consul.server.container.local.jmpd.in"
  ]

  output = data("certs")
}
```

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

### Kubernetes Cluster Docker Configuration Example

Source: https://jumppad.dev/resources/k8s/kubernetes_cluster

Example configuration for the Docker engine within a Kubernetes cluster, specifying proxy and insecure registry settings for local development.

```HCL
config {
  docker {
    no_proxy            = ["insecure.container.local.jmpd.in"]
    insecure_registries = ["insecure.container.local.jmpd.in:5003"]
  }
}
```

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

### Ingress Resource Example: Targeting Kubernetes Cluster

Source: https://jumppad.dev/resources/ingress

Demonstrates how to define an `ingress` resource that targets a `kubernetes_cluster` resource, specifying the port and service configuration within the Kubernetes cluster.

```HCL
resource "k8s_cluster" "dev" {
}

resource "ingress" "consul_http" {
  port = 18500

  target {
    resource = resource.k8s_cluster.dev
    port     = 8500

    config = {
      service   = "consul-consul-server"
      namespace = "default"
    }
  }
}
```

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

### Kubernetes Configuration `k8s_config` Resource Properties and Example

Source: https://jumppad.dev/resources/k8s/kubernetes_config

Details the configurable properties of the `k8s_config` resource, including cluster reference, configuration file paths, optional health checks, and readiness waiting behavior. Includes an example of referencing a Nomad cluster.

```APIDOC
k8s_config Resource Properties:
  cluster:
    Name: cluster
    Type: (nomad_cluster: )
    Required: required
    Readonly: true
    Description: The reference to a cluster to apply the jobs to. Kubernetes config is only applied when the referenced cluster is created and healthy.
  paths:
    Name: paths
    Type: ([]string: [])
    Required: required
    Readonly: true
    Description: Paths to the Nomad job files to apply to the cluster.
  health_check:
    Name: health_check
    Type: ([health_check](/docs/resources/k8s/kubernetes_config#health_check): {})
    Required: optional
    Readonly: true
    Description: Optional health check to perform after the jobs have been applied, this resource will not complete until the health checks are passing.
  wait_until_ready:
    Name: wait_until_ready
    Type: (bool: )
    Required: required
    Readonly: true
    Description: Determines if the resource waits until all config defined in the paths has been accepted and started by the server. If set to false the resource returns immediately after submitting the job.
```

```HCL
resource "nomad_job" "example" {
  cluster = resource.nomad_cluster.dev
  ...
}
```

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

### Define Simple Jumppad Output Variable for KUBECONFIG

Source: https://jumppad.dev/resources/internal/output

This example demonstrates the basic usage of an `output` resource to configure an environment variable. It shows how to set the `KUBECONFIG` variable by referencing the `kubeconfig` property of a `k8s_cluster` resource, illustrating a common pattern for exposing cluster configuration.

```Jumppad Config
output "KUBECONFIG" {
  value = resource.k8s_cluster.k3s.kubeconfig
}
```

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

### Example: Generic Cluster Property Configuration

Source: https://jumppad.dev/resources/container/sidecar

Demonstrates a generic configuration for a 'cluster' property. This snippet shows a basic structure for defining a cluster setting.

```HCL
code
```

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

### Container Property: Entrypoint Command

Source: https://jumppad.dev/resources/container/container

Entrypoint for the container, if not set, Jumppad starts the container using the entrypoint defined in the Docker image.

```APIDOC
Name: entrypoint
Type: ([]string: [])
Required: 
Readonly: Readonly
Description: Entrypoint for the container, if not set, Jumppad starts the container using the entrypoint defined in the Docker image.
```

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

### Example: Container and Sidecar Resource Definition

Source: https://jumppad.dev/resources/container/sidecar

Illustrates how to define a 'container' resource with various configurations like image, command, volumes, network, environment variables, and port ranges. It also shows how to attach a 'sidecar' resource to the main container, demonstrating inter-resource dependency.

```HCL
resource "container" "consul" {
  image {
    name = "consul:${variable.consul_version}"
  }

  command = ["consul", "agent", "-config-file", "/config/config.hcl"]

  volume {
    source      = "./"
    destination = "/files"
  }

  volume {
    source      = resource.template.consul_config.destination
    destination = "/config/config.hcl"
  }

  network {
    id         = resource.network.onprem.meta.id
    ip_address = "10.6.0.200" // optional
    aliases    = ["myalias"]
  }

  environment = {
    something       = variable.something
    foo             = env("BAH")
    file            = file("./conf.txt")
    abc             = "123"
    SHIPYARD_FOLDER = shipyard()
    HOME_FOLDER     = home()
  }

  port_range {
    range       = "8500-8502"
    enable_host = true
  }

}

resource "sidecar" "envoy" {
  target = resource.container.consul.meta.id

  image {
    name = "envoyproxy/envoy:v${variable.envoy_version}"
  }

  command = ["tail", "-f", "/dev/null"]

  volume {
    source      = data("config")
    destination = "/config"
  }
}
```

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

### Example: Copying Files with Specific Permissions

Source: https://jumppad.dev/resources/copy

Demonstrates how to use the `copy` resource to transfer files from a source directory to a destination, applying specific Unix file permissions (0666) to the copied items.

```Resource Definition
resource "copy" "myfiles" {
  source = "./myfolder"
  destination = "./mydestination"
  permissions = "0666"
}
```

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

### Example: Assigning Books to Docs Resource Content

Source: https://jumppad.dev/resources/docs/docs

This snippet demonstrates how to assign a list of `book` resources or module outputs to the `content` property of a `docs` resource. The `content` property expects an array of book references.

```Configuration DSL
content = [
  resource.book.introduction,
  module.course.output.book
]
```

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

### Jumppad CLI Purge Command Example Output

Source: https://jumppad.dev/cli/purge

Demonstrates the output of the `jumppad purge` command, showing the removal of Docker images, Helm charts, and blueprints with informational logs.

```Shell
jumppad purge
2020-04-21T14:00:17.962+0100 [INFO]  Removing image: image=docker.io/nicholasjackson/fake-service:v0.9.0
2020-04-21T14:00:17.972+0100 [INFO]  Removing image: image=docker.io/envoyproxy/envoy:v1.14.1
2020-04-21T14:00:17.976+0100 [INFO]  Removing Helm charts: path=/home/nicj/.jumppad/helm_charts
2020-04-21T14:00:17.976+0100 [INFO]  Removing Blueprints: path=/home/nicj/.jumppad/helm_charts
```

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

### Run Jumppad Blueprint Directly from Git Repository

Source: https://jumppad.dev/introduction/running

This command allows running a Jumppad blueprint directly from a Git repository URL. Jumppad automatically downloads the blueprint to the user's home directory and then starts all defined resources, simplifying the deployment process.

```shell
jumppad up github.com/jumppad-labs/examples//kubernetes-vault
```

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

### Template Resource Source Property - HereDoc Example

Source: https://jumppad.dev/resources/template

Illustrates using a HereDoc string literal for the `source` property to define inline template content.

```Configuration
source = <<-EOF
My inline content
EOF
```

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

### Check system dependencies with Jumppad CLI

Source: https://jumppad.dev/cli/check

Executes the `jumppad check` command to verify that all necessary system dependencies for Jumppad are correctly installed and configured.

```Shell
jumppad check
```

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

### Gherkin Test Example: Single Container Blueprint

Source: https://jumppad.dev/cli/test

This Gherkin feature defines a test scenario for a Docker container blueprint, asserting resource creation and HTTP accessibility. It sets environment variables and checks for running resources and successful HTTP responses.

```Gherkin
Feature: Docker Container
  In order to test jumppad creates containers correctly
  I should apply a blueprint which defines a simple container setup
  and test the resources are created correctly
Scenario: Single Container from Local Blueprint
  Given the following environment variables are set
    | key            | value                 |
    | CONSUL_VERSION | 1.8.0                 |
    | ENVOY_VERSION  | 1.14.3                |
  And I have a running blueprint
  Then the following resources should be running
    | name                      | type      |
    | onprem                    | network   |
    | consul                    | container |
    | envoy                     | sidecar   |
    | consul-container-http     | ingress   |
  And a HTTP call to "http://consul.container.local.jmpd.in:8500/v1/status/leader" should result in status 200
  And a HTTP call to "http://consul-http.ingress.local.jmpd.in:28500/v1/status/leader" should result in status 200
```

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

### Tail Logs for a Specific Jumppad Container

Source: https://jumppad.dev/cli/logs

Demonstrates how to use the `jumppad logs` command to view real-time logs for a container named `users-1`. The output shows example log entries, including error messages from Consul indicating permission issues.

```Shell
jumppad logs container.users-1
[users-1]   Aug 10 12:22:45 users-1 consul[80]: 2021-08-10T12:22:45.305Z [ERROR] agent.client: RPC failed to server: method=Intention.Match server=10.0.0.3:8300 error="rpc error making call: Permission denied"
[users-1]   Aug 10 12:22:45 users-1 consul[80]: 2021-08-10T12:22:45.669Z [ERROR] agent.client: RPC failed to server: method=Intention.Match server=10.0.0.3:8300 error="rpc error making call: Permission denied"
[users-1]   Aug 10 12:22:46 users-1 consul[80]: 2021-08-10T12:22:46.192Z [ERROR] agent.client: RPC failed to server: method=Intention.Match server=10.0.0.3:8300 error="rpc error making call: Permission denied"
```

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

### Configure HTTP Health Check

Source: https://jumppad.dev/resources/container/sidecar

Example of an HTTP health check block, specifying the address, method, body, headers, and expected success codes. This check performs an HTTP GET request and validates the response.

```HCL
http {
  address = "http://localhost:8500/v1/status/leader"
  method  = "GET"
  body    = <<-EOF\n    {\"test\": \"123\"}\n  EOF
  headers = {
    "X-Auth-Token": ["abc123"]
  }
  success_codes = [200]
}

```

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

### Matrix Testing with Dynamic Values

Source: https://jumppad.dev/cli/test

Enables executing a single test scenario multiple times, each with a different set of input values defined in an 'Examples' table. Values from the table are dynamically interpolated into test statements at runtime, allowing for comprehensive testing across various configurations.

```Gherkin
Scenario: Single Container from Local Blueprint with multiple runs
  Given the environment variable "CONSUL_VERSION" has a value "<consul>"
  And the environment variable "ENVOY_VERSION" has a value "<envoy>"
  And I have a running blueprint
  Then the following resources should be running
    | name                      | type      |
    | onprem                    | network   |
    | consul                    | container |
    | envoy                     | sidecar   |
    | consul-container-http     | ingress   |
  And a HTTP call to "http://consul-http.ingress.local.jmpd.in:8500/v1/status/leader" should result in status 200
  And the response body should contain "10.6.0.200"
  Examples:
    | consul            | envoy    |
    | 1.8.0             | 1.14.3   |
    | 1.7.3             | 1.14.3   |
```

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

### Create Bash Shell in a Container using jumppad exec

Source: https://jumppad.dev/cli/exec

Example of using `jumppad exec` to open an interactive bash shell inside a specified container resource, providing direct access to the container's environment.

```CLI
jumppad exec container.consul -- bash
```

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

### Basic Usage of jumppad exec CLI Command

Source: https://jumppad.dev/cli/exec

Demonstrates the fundamental syntax for using the `jumppad exec` command, showing how to specify a target resource and the command to execute within it.

```CLI
jumppad exec <target> -- <command>
```

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

### Define Jumppad Application Build with Output and Local Execution

Source: https://jumppad.dev/resources/build

This snippet demonstrates how to define a Jumppad 'build' resource for an application, including the Dockerfile, build context, and an output configuration to specify where built binaries should be placed. It also includes a 'local_exec' resource to run a Jumppad command, typically used for deploying or managing the application locally.

```Jumppad HCL
resource "build" "app" {
  container {
    dockerfile = "Dockerfile"
    context    = "./src"
  }

  output {
    source = "/go/src/github.com/jumppad-labs/jumppad/bin"
    destination = "${data("local_app")}/bin"
  }
}

resource "local_exec" "app" {
  command = ["jumppad", "up", "./config"]
}
```

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

### Gherkin Statement: Running Blueprint from Path with Specific Jumppad Version

Source: https://jumppad.dev/cli/test

This Gherkin example illustrates the `I have a running blueprint at path "<path>" using version "<version>"` statement, enabling matrix testing of blueprints across different jumppad versions.

```Gherkin
Scenario: Single Container from Local Blueprint
  Given I have a running blueprint at path "./testsetup/container" using version "<version>"
  Examples:
    | consul            | envoy    |
    | 1.8.0             | 1.14.3   |
    | 1.7.3             | 1.14.3   |
```

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

### HCL Example: Create and Output Random ID

Source: https://jumppad.dev/resources/random/random_id

This example demonstrates how to define a `random_id` resource with a specified `byte_length` and then output its `base64`, `hex`, and `dec` representations using meta properties.

```HCL
resource "random_id" "id" {
    byte_length = 4
}

output "id_base64" {
    value = resource.random_id.meta.id.base64
}

output "id_hex" {
    value = resource.random_id.meta.id.hex
}

output "id_dec" {
    value = resource.random_id.meta.id.dec
}
```

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

### Jumppad Up: Create Stack from GitHub Blueprint

Source: https://jumppad.dev/cli/up

Illustrates how to use `jumppad up` to deploy a stack directly from a blueprint hosted in a GitHub repository.

```cli
jumppad up github.com/jumppad-up/blueprints//vault-k8s
... output
```

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

### Running Jumppad Tests with Purge Flag and Output

Source: https://jumppad.dev/cli/test

This example demonstrates how to execute jumppad tests for a blueprint located at `./examples/container` using the `--purge` flag. The flag ensures all cached dependencies are removed before testing, and the output shows the detailed Gherkin test execution with step definitions.

```Shell
jumppad test --purge ./examples/container
```

```Gherkin
Feature: Docker Container
  In order to test jumppad creates containers correctly
  I should apply a blueprint which defines a simple container setup
  and test the resources are created correctly
  Scenario: Single Container from Local Blueprint                                                                   # examples/container/test/container.feature:6
    Given the following environment variables are set                                                               # test.go:309 -> *CucumberRunner
      | key            | value  |
      | CONSUL_VERSION | 1.8.0  |
      | ENVOY_VERSION  | 1.14.3 |
    And I have a running blueprint                                                                                  # test.go:141 -> *CucumberRunner
    Then the following resources should be running                                                                  # test.go:189 -> *CucumberRunner
      | name                  | type      |
      | onprem                | network   |
      | consul                | container |
      | envoy                 | sidecar   |
      | consul-container-http | ingress   |
    And a HTTP call to "http://consul.container.local.jmpd.in:8500/v1/status/leader" should result in status 200     # test.go:277 -> *CucumberRunner
    And a HTTP call to "http://consul-http.ingress.local.jmpd.in:28500/v1/status/leader" should result in status 200 # test.go:277 -> *CucumberRunner
```

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

### APIDOC: Jumppad Connector Run Parameters

Source: https://jumppad.dev/cli/connector

Documents the configuration flags for the `jumppad connector run` command, detailing options such as bind addresses for various APIs, logging settings, and paths for TLS certificates.

```APIDOC
Name: api-bind
  Type: (string: :9092)
  Required
  Readonly
  Description: Bind address for the API Server.
Name: grpc-bind
  Type: (string: :9090)
  Required
  Readonly
  Description: Bind address for the gRPC API.
Name: http-bind
  Type: (string: :9091)
  Required
  Readonly
  Description: Bind address for the HTTP API.
Name: log-file
  Type: (string: ./connector.log)
  Required
  Readonly
  Description: Log file for connector logs.
Name: log-level
  Type: (string: info)
  Required
  Readonly
  Description: Log output level [debug, trace, info].
Name: root-cert-path
  Type: (string: "")
  Required
  Readonly
  Description: Path for the PEM encoded TLS root certificate.
Name: server-cert-path
  Type: (string: "")
  Required
  Readonly
  Description: Path for the servers PEM encoded TLS certificate.
Name: server-key-path
  Type: (string: "")
  Required
  Readonly
  Description: Path for the servers PEM encoded Private Key.
```

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

### Jumppad Up Command Usage Syntax

Source: https://jumppad.dev/cli/up

Shows the basic command line syntax for the `jumppad up` command, indicating it accepts a file, directory, or URL as input, followed by optional flags.

```cli
jumppad up <file|directory|url> [flags]
```

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

### Terraform Template Resource with Go Template Helpers

Source: https://jumppad.dev/resources/internal/functions

This example defines a Terraform `resource "template"` block, demonstrating how to embed Go template helper functions like `file`, `quote`, and `trim` within the `source` content. It shows how to include file content, quote strings, and trim whitespace.

```HCL
resource "template" "consul_config" {

  source = <<-EOF

  file_content = "{{ file \"./myfile.txt\" }}"
  quote = {{quote something}}
  trim = {{quote (trim with_whitespace)}}

  EOF

  destination = "./consul_config/consul.hcl"
}
```

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

### Execute Commands in Containers with Exec Resource

Source: https://jumppad.dev/resources/exec

This example showcases two ways to execute commands using the `exec` resource within containers: targeting an existing `container` resource, and defining a standalone container directly within the `exec` resource itself. Both examples run a simple `ls -las` command inside an Alpine Linux environment.

```HCL
resource "container" "alpine" {
  image {
    name = "alpine"
  }

  command = ["tail", "-f", "/dev/null"]
}

resource "exec" "in_container" {
  target = resource.container.alpine

  script = <<-EOF
  #/bin/sh
  ls -las
  EOF
}

resource "exec" "standalone" {
  image {
    name = "alpine"
  }

  script = <<-EOF
  #/bin/sh
  ls -las
  EOF
}
```

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

### Define and Consume Jumppad Output Lists

Source: https://jumppad.dev/resources/internal/output

This snippet illustrates how to define an `output` resource that holds a list of values. It also demonstrates how to consume a specific element from this list using zero-based indexing, showcasing the interpolation syntax for accessing list items.

```Jumppad Config
output "list" {
  value = [1,2,3]
}

output "list_value" {
  value = output.list.2 // 3
}
```

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

### Define Nomad Cluster and Job Resources

Source: https://jumppad.dev/resources/nomad/nomad_job

This HCL configuration defines a Nomad cluster resource named 'dev' and a Nomad job resource named 'example'. The cluster resource links to an existing network ID, and the job resource references the cluster. It also specifies a path to job configurations and includes a health check with a timeout for the 'example' job.

```HCL
resource "nomad_cluster" "dev" {
  network {
    id = resource.network.cloud.meta.id
  }
}

resource "nomad_job" "example" {
  cluster = resource.nomad_cluster.dev.meta.id

  paths = ["./app_config/example1.nomad"]

  health_check {
    timeout    = "60s"
    nomad_jobs = ["example"]
  }
}
```

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

### Helm Resource `helm` Overview

Source: https://jumppad.dev/resources/helm

Provides a high-level description of the `helm` resource, detailing its purpose in provisioning Helm charts to Kubernetes cluster resources.

```APIDOC
Helm `helm`
The `helm` resource allows Helm charts to be provisioned to `k8s_cluster` resources.
```