4

I have a Concourse Pipeline with a Task using a Docker image that is stored in our local Artifactory server. Every time I start the Pipeline it takes about 5 mins until the tasks are finally run. The log looks like this:

enter image description here

I assume that Concourse somehow checks for newer versions of the Docker image. Unfortunately I have no chance to debug since all the logfiles on the Concourse worker VM offer no usable information.

My Questions:

  1. How can I possibly debug what's going on, when Concourse says "preparing build" and the status is "pending".

  2. Is there any chance to avoid Concourse from checking for a newer version of the Docker image? I tagged the Docker image with version latest - might this be an issue?

  3. Any further ideas how I could speed things up?

Here is the detailed configuration of my pipeline and tasks:

pipeline.yml:

---
resources:
- name: concourse-image
  type: docker-image
  source:
    repository: OUR_DOMAIN/subpath/concourse
    username: ...
    password: ...
    insecure_registries:
    - OUR_DOMAIN

# ...

jobs:
- name: deploy
  public: true
  plan:
  - get: concourse-image
  - task: create-manifest
    image: concourse-image
    file: concourse/tasks/create-manifest/task.yml
    params:
      # ...

task.yml:

---
platform: linux

inputs:
- name: git
- name: concourse

outputs:
  - name: deployment-manifest

run:
  path: concourse/tasks/create-and-upload-cloud-config/task.sh
Michael Lihs
  • 7,460
  • 17
  • 52
  • 85
  • can you check ATC, worker logs for any failures? Could be worker is not reachable or ran out of space... – Maria S Mar 17 '17 at 16:42
  • Hi @MariaS - thx for your suggestion. The logfiles unveiled no useful information, but `tcpdump` gave us some insights :) – Michael Lihs Mar 22 '17 at 13:07

1 Answers1

4

The reason for this problem was that we pulled the Docker image from an internal Docker registry, which is running on HTTP only. Concourse tried to pull the image using HTTPS and it took around 5 mins until Concourse switched to HTTP (that's what a tcpdump on the worker showed us).

Changing the resource configuration to the following config solved the problems:

resources:
- name: concourse-image
  type: docker-image
  source:
    repository: OUR_SERVER:80/subpath/concourse
    username: docker-readonly
    password: docker-readonly
    insecure_registries:
    - OUR_SERVER:80

So basically it was adding the port explicitly to the repository and the insecure_registries.

Michael Lihs
  • 7,460
  • 17
  • 52
  • 85