Could not find docker images and worker running on my local laptop


where does the docker images and containers reside? I have installed concourse locally and did a basic hello-world pipeline. I could not see any busybox image nor the container in my local machine. Not sure where these images would reside?

- name: job-hello-world
  public: true
  - task: hello-world
      platform: linux
        type: docker-image
        source: {repository: ubuntu}
        path: echo
        args: [hello world]

docker ps -a & docker images does not show the ubuntu image or the worker

Where do I find this out?

If we need to login to worker to debug something, how would we do it?


Concourse doesn’t use docker for container orchestration. Instead it uses Garden. I’m not aware of a way to see a list of active containers when running Concourse locally beyond the output of fly containers.

Generally when debugging tasks you would make use of fly intercept to get a shell in the running container.


Thanks. The container spin up by the Graden on worker are docker containers or something else. The reason I am asking this question is because we are specifying the containers as docker containers in the pipeline.

One more question which is slightly different is how are other docker containers accessed within the task containers created by Garden.

I am trying to access artifactory instance via from the task container where my build is executing and it complains about the below.

bash-4.4# curl curl: (7) Failed to connect to port 8081: Connection refused

Any suggestions on how do we access it from the task container?


Garden is a container manager so it is responsible for starting and managing containers. On linux it uses a backend using runc from the Open Container Initiative (OCI). Generally in Concourse the images that Garden starts as containers are Docker images (Docker is a member of the OCI). So in short, you provide a docker image and Garden starts it as a container then manages it.

I don’t think there is any mechanism for container to container networking in Concourse. When you are running Concourse locally I think it is an intentional design decision to not allow containers within Concourse to talk to each other let alone to containers running elsewhere on the host.