can you rebuild docker.io/elementsproject/lightningd ?

[x3nb63]

Issue and Steps to Reproduce

DNS lookups fail in the container, when running on a k3s cluster. As a consequence lightningd fails to connect to bitcoind.

I do have (many) containers that use the clusters DNS just fine... so its not the cluster per se. This far I tracked the issue down to versions of Alpine where DNS succeeds or fails depending on the Alpine version chosen. This test I did with running a alpine shell as a sidecar to the lightningd container - so I am right in the same pod (same host, same virtual nic, same packet filter rules that apply ...) - an I can toggle whether name lookups succeed or not.

From alpine I know there have been many updates on the resolving library in their busybox core ... I have no idea what Debian does or does not here, but given they have a newer build than current elementsproject/lightningd:latest points to, I think its worth doing.

also: does it need to be buster? Perhaps lightningd works just fine on a newer release?

[cdecker]

Sounds like something that we might want to look into. Can you try and see how resolution is configured in a non-lightningd container and a lightningd container (presumably using kubectl exec to run in the container itself).

Depending on how these differ we might have a better idea on how to fix this up in the docker image.

[x3nb63]

all pods have a resolv.conf file pointing to the kube-dns service IP. The service itself is then backed by a coredns pod. There is no difference other than the namespace in the search ... list.

however, the question of query with FQDN / without FQDN does not matter in my tests, DNS works in the container or it does not.

testing with nslookup tool sometimes reports a answer but at the same time says: *** Can't find host.domain.tld: No answer.

[cdecker]

It seems indeed like the kubernetes DNS resolution may have some issues with alpine containers:

• https://stackoverflow.com/questions/65181012/does-alpine-have-known-dns-issue-within-kubernetes#answer-65593511
• dns problem in apline based docker image kubernetes-sigs/kind#442
• Dns server is null in some pods. kubernetes/kubernetes#30215

I'll look into how we can address that without requiring changes to the kubernetes config.

[x3nb63]

yes, I've found many issues with this and many hint to musl and/or busybox. ... that is, to the "core" of Alpine and the reason why its so small and efficient.

Yet your Dockerfile uses buster-slim ... so I am not sure this is it - unless this slimification switches to busybox and/or some other libc ...? That I can't tell.

thanks for looking

[x3nb63]

here is a Dockerfile based on that new Debian Bullseye - so far it does not appear to have this DNS issue

btw: is there a particular reason why your Dockerfile builds static binaries? I did not do that and it runs fine so far

FROM docker.io/debian:bullseye-slim as downloader

ARG LIGHTNING_BRANCH=v0.10.1
ARG LIGHTNING_CLONE_URL=https://github.com/ElementsProject/lightning.git

RUN apt-get update && apt install -y \
    git wget tar \
  && git clone --depth 1 --shallow-submodules --branch ${LIGHTNING_BRANCH} ${LIGHTNING_CLONE_URL} /src/lightning

ARG BITCOIN_VERSION=22.0
ENV BITCOIN_TGZ=bitcoin-${BITCOIN_VERSION}-x86_64-linux-gnu.tar.gz
ENV BITCOIN_URL=https://bitcoincore.org/bin/bitcoin-core-${BITCOIN_VERSION}/${BITCOIN_TGZ}
ENV BITCOIN_SHA_URL=https://bitcoincore.org/bin/bitcoin-core-${BITCOIN_VERSION}/SHA256SUMS

RUN mkdir /opt/bitcoin && cd /opt/bitcoin \
    && wget -qO $BITCOIN_TGZ "$BITCOIN_URL" \
    && wget -qO all_shasums "$BITCOIN_SHA_URL" \
    && grep $BITCOIN_TGZ all_shasums | tee SHA256SUMS \
    && sha256sum -c SHA256SUMS \
    && BD=bitcoin-$BITCOIN_VERSION/bin \
    && tar -xzvf $BITCOIN_TGZ $BD/bitcoin-cli --strip-components=1 \
    && rm $BITCOIN_TGZ

RUN exit 0



FROM docker.io/debian:bullseye-slim as builder

RUN apt-get update && apt install -y --no-install-recommends \
    ca-certificates autoconf automake build-essential git libtool \
    python3 python3-mako wget gnupg dirmngr gettext \
    libgmp10 libgmp10-dev \
    sqlite3 libsqlite3-dev \
    zlib1g zlib1g-dev

COPY --from=downloader /src/lightning /tmp/lightning

WORKDIR /tmp/lightning

 #   --enable-static  # FIXME: why? \
RUN ./configure \
    --prefix=/tmp/lightning_install \
  && echo ========== CONFIGURE DONE ==========  \
  && make -j3 \
  && echo ========== MAKE DONE ==========  \
  && make install



FROM docker.io/debian:bullseye-slim as final

ENV LIGHTNINGD_DATA=/root/.lightning
ENV LIGHTNINGD_NETWORK=bitcoin
ENV LIGHTNINGD_PORT=9735
ENV LIGHTNINGD_RPC_PORT=9835

RUN apt-get update && apt install -y --no-install-recommends \
    socat inotify-tools python3 python3-pip tini \
    libgmp10 sqlite3 zlib1g \
  && mkdir $LIGHTNINGD_DATA \
  && touch $LIGHTNINGD_DATA/config \
  && rm -rf /var/lib/apt/lists/*

COPY --from=builder /tmp/lightning_install/ /usr/local/
COPY --from=downloader /src/lightning/tools/docker-entrypoint.sh entrypoint.sh
COPY --from=downloader /opt/bitcoin/bin /usr/local/bin

VOLUME [ "/root/.lightning" ]

EXPOSE 9735 9835

ENTRYPOINT  [ "/usr/bin/tini", "-g", "--", "./entrypoint.sh" ]