hi all, i believe i might be running into <https:...
# general
v
hi all, i believe i might be running into https://github.com/pantsbuild/pants/issues/17851 or similar. this is a docker-from-docker setup where a machine, running docker container A, gives container A access to the host's docker daemon via mounting or something. then docker container A can run docker commands internally that communicate directly with the host machine's docker daemon. the issue creator solved the problem by mounting
/tmp
from the host machine into docker container A. i am running
pants package
on circleci in a docker executor. circleci has a similar setup: docker-from-docker, and they call it
setup_remote_docker
. i'm not sure i could perform the same solution, if indeed this is my problem as
setup_remote_docker
is somewhat of a black box any help on how to debug would be greatly appreciated some docs on
setup_remote_docker
• some good 3rd party docs here https://gist.github.com/OlegGorj/52ca84624503a5e85624c6eb38df4590 • some 1st party docs here https://circleci.com/docs/building-docker-images/ some similar threads i found: • https://pantsbuild.slack.com/archives/C046T6T9U/p1689934342736989https://pantsbuild.slack.com/archives/C046T6T9U/p1683134620837339https://pantsbuild.slack.com/archives/C046T6T9U/p1670489335652639 my error running
pants package
Copy code
Bootstrapping Pants 2.17.0 using cpython 3.9.16
Installing pantsbuild.pants==2.17.0 into a virtual environment at /root/.cache/nce/260e9f180e257368873660af8dd93ef1ae670cb61bde99eea1fd914ad6e534bb/bindings/venvs/2.17.0
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.1/2.1 MB 85.1 MB/s eta 0:00:00
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 819.3/819.3 KB 61.7 MB/s eta 0:00:00
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 64.8/64.8 KB 4.7 MB/s eta 0:00:00
New virtual environment successfully created at /root/.cache/nce/260e9f180e257368873660af8dd93ef1ae670cb61bde99eea1fd914ad6e534bb/bindings/venvs/2.17.0.
16:34:06.26 [INFO] waiting for pantsd to start...
16:34:08.17 [INFO] pantsd started
16:34:08.36 [INFO] Initializing scheduler...
16:34:15.00 [INFO] Scheduler initialized.
16:34:19.29 [INFO] Starting: Building dockerfile_parser.pex from <resource://pants.backend.docker.subsystems/dockerfile.lock>
16:34:28.98 [INFO] Completed: Building dockerfile_parser.pex from <resource://pants.backend.docker.subsystems/dockerfile.lock>
16:34:29.11 [INFO] Starting: Pulling Docker image `python:3.11.5-bookworm` because the image is missing locally.
16:34:29.46 [INFO] Completed: Pulling Docker image `python:3.11.5-bookworm` because the image is missing locally.
16:34:30.13 [ERROR] 1 Exception encountered:

Engine traceback:
  in `package` goal

ProcessExecutionFailure: Process 'Extract environment variables from the Docker image python:3.11.5-bookworm' failed with exit code 126.
stdout:
OCI runtime exec failed: exec failed: unable to start container process: chdir to cwd ("/pants-sandbox/pants-sandbox-ELFZUJ") set in config.json failed: no such file or directory: unknown

stderr:



Use `--keep-sandboxes=on_failure` to preserve the process chroot for inspection.
Exited with code exit status 1
e
> i am running pants package on circleci in a docker executor. circleci has a similar setup ... Did you mean to say GitHub Actions in the 1st sentence? Can you provide the config yml for whichever CI setup it currently is?
the issue creator solved the problem by mounting /tmp from the host machine into docker container
That sounds like the right approach. If the Circle CI remote docker is truly remote - network separated - then you can't do a volume mount in any simple way any longer (docker run -v [...]).
You'd be asking docker over the network to mount your
/tmp
over there. Can be done via things like sshfs and other means - but I have no clue how you'd do this in Docker. They do have support for custom / exotic volume drivers for just this sort of thing, but at that point I think you're in too deep water.
If I were you I'd be trying to get DinD working locally 1st. That will learn you a thing or two and then you'll be equipped to transferring that to Circle CI or some such where it's much harder to debug / iterate.
v
i meant circleci. we don't use GHA for this. this is the relevant section of the circleci config:
Copy code
build-my-app:
    working_directory: ~/my_repo

    resource_class: << parameters.resource_class >>

    docker:
      # pants has been installed in this image
      - image: $AWS_ECR_ACCOUNT_URL/$AWS_ECR_PANTS_REPO:latest
        aws_auth:
          aws_access_key_id: $AWS_ACCESS_KEY_ID
          aws_secret_access_key: $AWS_SECRET_ACCESS_KEY

    parameters:
      resource_class:
        type: string

      docker_layer_caching:
        type: boolean

    steps:
      # just a simple checkout of the my_repo
      - run:
          name: Checkout the repository
          command: *checkout-my-repo-command

      # will install docker in the image and do magic
      - setup_remote_docker:
          docker_layer_caching: << parameters.docker_layer_caching >>

      - aws-cli/setup:
          aws-access-key-id: AWS_ACCESS_KEY_ID
          aws-region: AWS_REGION
          aws-secret-access-key: AWS_SECRET_ACCESS_KEY

      - run:
          name: Login to ECR
          command: |
            PASS=$(aws ecr get-login-password --region $AWS_REGION)
            docker login --username AWS --password $PASS \
              << pipeline.parameters.pipeline-aws-ecr-url >>

      - run:
          name: Build My App Docker Container
          command: |
            cd python || exit 1
            pants package projects/my_app:docker

      - run:
          name: Tag & Push My App Docker Container
          command: |
            cd python || exit 1
            echo hello
            # pants publish projects/my_app:docker
why does pants need access to mount /tmp from the docker A to docker B? i think the only thing allowed is
docker cp
so i could have pants build the pex binary locally
docker cp
it into position. but i would have to abandon having pants doing any sort of docker packaging
agreed about going to deep
i don't think i should do straight dind. it appears to not be recommended from a security angle
agreed on circleci being a poor environment for trial and error / learning
e
i don't think i should do straight dind. it appears to not be recommended from a security angle
Um, OK, but messing around on your own machine is really, really instructive! I am not saying actually do this in prod, but you are trying to use a facsimile of it in prod, so to have a shot at being able to self service you need some basis for understanding the machinery. Thanks for the extra info - looking at the yaml ...
Ok, @victorious-zebra-49010 - a sanity check 1st: is there a good reason you must run Pants in Circle CI in a container to start with vs on a machine? That choice is what causes all this wrangling; so if the choice can be un-made - that may be the easiest path.
Is it just for "# pants has been installed in this image"? I.E.: caching the Pants install step?
So, assuming your answer to those is we need to for reasons, the next step I'd do is add an early step to the job to print all the env vars. Presumably the remote docker setup sets up
DOCKER_*
env vars to point to the remote docker. If so, those same env vars need to be leaked into Pants - because, by default, Pants masks the environment for all actions. You must, in general, say when and which env vars from your local environment you wish to allow Pants subprocesses to read.
But also, Circle CI does have a useful re-run job with ssh gadget. I've used this before to ssh into a job and debug. Have you tried that?
v
oooooo re-run
is there a good reason you must run Pants in Circle CI in a container to start with vs on a machine? That choice is what causes all this wrangling; so if the choice can be un-made - that may be the easiest path.
this is a great point. i got an impression from the last engineer who looked at this that this wasn't an option for us, i.e. do a linux vm execution environment and install pants there. but that impression could be wrong, maybe i misunderstood. i'll revisit that. i would love greatly to sidestep this problem
So, assuming your answer to those is we need to for reasons, the next step I'd do is add an early step to the job to print all the env vars. Presumably the remote docker setup sets up
DOCKER_*
env vars to point to the remote docker. If so, those same env vars need to be leaked into Pants - because, by default, Pants masks the environment for all actions. You must, in general, say when and which env vars from your local environment you wish to allow Pants subprocesses to read.
declare -x DOCKER_HOST="unix:///var/run/docker.sock" declare -x DOCKER_MACHINE_NAME="localhost"
i'll be back if vm executor is a no-go
(thanks so much john)
(well, got the wrong impression from that other engineer. indeed i can use the linux vm execution environment, and it just worked)
🔥 1