Tengo una canalización de Concourse con una tarea que usa una imagen de Docker que está almacenada en nuestro servidor Artifactory local. Cada vez que inicio Pipeline, toma alrededor de 5 minutos hasta que finalmente se ejecutan las tareas. El registro se ve así:
Supongo que Concourse de alguna manera busca versiones más nuevas de la imagen de Docker. Desafortunadamente, no tengo la oportunidad de depurar ya que todos los archivos de registro en la VM del trabajador de Concourse no ofrecen información utilizable.
Mis preguntas:
¿Cómo puedo depurar lo que está pasando cuando Concourse dice "preparando compilación" y el estado es "pendiente".
¿Hay alguna posibilidad de evitar que Concourse busque una versión más nueva de la imagen de Docker? Etiqueté la imagen de Docker con la latest versión. ¿Podría ser un problema?
¿Alguna otra idea de cómo podría acelerar las cosas?
Aquí está la configuración detallada de mi tubería y tareas:
canalización.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: # ...tarea.yml:
--- platform: linux inputs: - name: git - name: concourse outputs: - name: deployment-manifest run: path: concourse/tasks/create-and-upload-cloud-config/task.shEl motivo de este problema fue que extrajimos la imagen de Docker de un registro interno de Docker, que se ejecuta solo en HTTP . Concourse intentó extraer la imagen usando HTTPS y tomó alrededor de 5 minutos hasta que Concourse cambió a HTTP (eso es lo que nos mostró un tcpdump en el trabajador).
Cambiar la configuración de recursos a la siguiente configuración resolvió los problemas:
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 Básicamente, estaba agregando el puerto explícitamente al repository e insecure_registries .