Esc

Run inside the charm container

Skip Juju entirely and talk to a mounted Pebble socket directly, from a charm hook, a debug-hooks session, or against any socket path.

When borescope runs inside a Juju Kubernetes charm container, it doesn't need Juju at all. Juju mounts each workload's Pebble socket into the charm container at /charm/containers/<name>/pebble.socket, and borescope can talk to that socket directly with the real ops.pebble.Client API.

Auto-detect with --here

From a juju ssh <unit> session, a juju debug-hooks shell, or charm code, run:

$ borescope --here

borescope scans /charm/containers/ for mounted Pebble sockets. If the charm declares exactly one workload container, it connects to that one. No unit reference, no model, no Juju round-trip.

Several containers

If the charm has more than one workload container, --here can't guess which you mean, so name it:

$ borescope --here --container=workload

If you omit --container with multiple containers present, borescope lists the available names and asks you to choose one.

Files you see are the workload's, not the charm container's

When you run borescope --here inside the charm container, the prompt's filesystem commands (ls, cat, cp, push, …) see the workload container's filesystem, not the charm container's. That's the whole point — --here talks to the workload's Pebble, which serves the workload's files.

This bites most often with /tmp: a file you write in the charm container's /tmp is invisible to cat /tmp/whatever at the borescope prompt. To poke at a specific local file, push it across first:

$ borescope --here -c "push /charm/scratch.txt /tmp/scratch.txt"
$ borescope --here -c "cat /tmp/scratch.txt"

The same applies in reverse: pull /workload/path /charm/path brings a file out of the workload into the charm container's filesystem where you can juju scp it back to your workstation.

Point at a socket

To talk to a Pebble over a specific Unix socket (a workload socket at a non-standard path, or a local Pebble you're running yourself), pass --socket:

$ borescope --socket /charm/containers/workload/pebble.socket
$ borescope --socket /var/run/pebble.socket

With --socket, borescope skips Juju discovery entirely and connects straight to that socket via the HTTP API. You can still pass a unit reference for labelling (it's used for the history key and the prompt), but it isn't required.

When to use which

You are… Use
On your workstation, debugging a remote unit borescope myapp/0 (the default)
Inside the charm container already borescope --here
Inside, with multiple workloads borescope --here --container=<name>
Pointing at a specific or local socket borescope --socket <path>

--here and --socket both use the direct socket transport, which is faster than going through juju ssh and works without any Juju access, but only from somewhere that can see the socket. From your workstation, use a unit reference instead. See How it reaches Pebble for how the two transports differ.