I’m using a near-stock Dockerfile to deploy a Rails app. Running a
fly deploy at the moment gets to the step where it installs Volta (
RUN curl https://get.volta.sh | bash), and hangs trying to connect to
Sending build context to Docker daemon 161.4kB [+] Building 28.8s (9/23) => [internal] load remote build context => copy /context / => resolve image config for docker.io/docker/dockerfile:experimental => CACHED docker-image://docker.io/docker/dockerfile:experimental@sha256:600e5c62eedff338b3f7a0850beb7c05866e0ef27b2d2e8c02aa468e78496ff5 => [internal] load metadata for quay.io/evl.ms/fullstaq-ruby:3.1.2-jemalloc-slim => CACHED [base 1/6] FROM quay.io/evl.ms/fullstaq-ruby:3.1.2-jemalloc-slim@sha256:1810013115213b003a9d66530bb674d25270979fcaede0ed083a21cb6a4b61da => [base 2/6] RUN mkdir /app => [base 3/6] WORKDIR /app => [base 4/6] RUN mkdir -p tmp/pids => [base 5/6] RUN curl https://get.volta.sh | bash => => # % Total % Received % Xferd Average Speed Time Time Time Current => => # Dload Upload Total Spent Left Speed => => # 0 0 0 0 0 0 0 0 --:--:-- 0:00:25 --:--:-- 0
-v in there only prints on line of debug information…
…which appears to resolve to an AWS instance, and is different from where my local machine resolves
get.volta.sh to (18.104.22.168, which appears to be some kind of Google IP). Not sure if that’s interesting or if it’s just a proxy thing.
I did some sanity-checking, and
get.volta.sh is indeed working fine at the moment, even if I try to talk to it through a shell in the same Docker base image (running locally). This build has worked fine for the last ~month since I started this project, though I don’t know how much of that was due to hitting cache for this build step and never having to actually run curl.
Looks like there’s some network strangeness happening on the build machines, but I’m unsure how to debug further.