github.com/smartcontractkit/chainlink-testing-framework/libs@v0.0.0-20240227141906-ec710b4eb1a3/docs/debug/eth2.md (about)

     1  # Prysm containers
     2  Docker images provided by Prysm are bare-bone and do not even contain exectuable shell, which makes debugging impossible. To overcome it we need to build our own image with debug tools installed. The following Dockerfile will do the job for `beacon chain`:
     3  ```
     4  ARG tag
     5  FROM --platform=linux/x86_64 gcr.io/prysmaticlabs/prysm/beacon-chain:$tag as upstream
     6  
     7  FROM --platform=linux/x86_64 debian:buster-slim
     8  COPY --from=upstream /app /app
     9  
    10  RUN apt-get update && apt-get install -y \
    11      curl \
    12      jq \
    13      nano \
    14      netcat-openbsd \
    15      iputils-ping \
    16      && rm -rf /var/lib/apt/lists/*
    17  
    18  
    19  STOPSIGNAL SIGINT
    20  
    21  ENTRYPOINT ["/app/cmd/beacon-chain/beacon-chain"]
    22  ```
    23  
    24  And for `validator`:
    25  ```
    26  ARG tag
    27  FROM --platform=linux/x86_64 gcr.io/prysmaticlabs/prysm/validator:$tag as upstream
    28  
    29  FROM --platform=linux/x86_64 debian:buster-slim
    30  COPY --from=upstream /app /app
    31  
    32  RUN apt-get update && apt-get install -y \
    33      curl \
    34      jq \
    35      nano \
    36      netcat-openbsd \
    37      iputils-ping \
    38      && rm -rf /var/lib/apt/lists/*
    39  
    40  
    41  STOPSIGNAL SIGINT
    42  
    43  ENTRYPOINT ["/app/cmd/validator/validator"]
    44  ```
    45  
    46  And the use as follows:
    47  ```
    48  docker build -t gcr.io/prysmaticlabs/prysm/validator:debug --build-arg tag=v4.1.0 .
    49  ```
    50  
    51  # Lighthouse
    52  No supported yet.
    53  
    54  # Local Kubernetes @ Docker Desktop (MacOS)
    55  It's very handy and easy to setup, but comes with some hurdles: `hostpath` storage class doesn't work as expected in relation to retention policy. Whether you chose `Delete` or `Recycle` old data won't be removed and your chain will start correctly only the first time, when there is no data yet (consecutive runs will fail, because they will try to generate genesis.json based on previous chain states).
    56  
    57  My hacky workaround is to generate a new host directory based on current timestamp every time I start the service. Not idea, but works. It has one main drawback, though: disk gets bloated, since old data is never removed. Now... you can delete it manually, but it's not as straight-fowardward as you might think, because that directory is not directly accessible from your MacOS machine, because it runs inside Docker's VM. Here's how to go about it:
    58  ```
    59  docker run -it --rm --privileged --pid=host justincormack/nsenter1
    60  ```
    61  (Other options are described [here](https://gist.github.com/BretFisher/5e1a0c7bcca4c735e716abf62afad389))
    62  Then you need to find find a folder where `rootfs` for Docker VM is located, in my case it was `/containers/services/02-docker/rootfs` (search for a folder containing whatever hostpath you have the persistent volumne mounted at, or inspect one of your pods, check the volume mount and find it in the VM, just remember that even if your volume is supposedly mounted in `/data/shared` on the host in reality that `/data/shared` folder is still relative to wherever `rootfs` folder is located).
    63  
    64  Once you find it, you can delete the old data and start the service again. Or you can use it for debugging to easily inspect the content of shared volumes (useful in case of containers that are bare-bone and don't even have `bash` installed, like Prysm).