Giter VIP home page Giter VIP logo

registry-image-resource's Introduction

Registry Image Resource

Supports checking, fetching, and pushing of images to Docker registries. This resource can be used in three ways: with tag specified, with tag_regex specified, or with neither tag nor tag_regex specified.

With tag specified, check will detect changes to the digest the tag points to, and out will always push to the specified tag. This is to be used in simpler cases where no real versioning exists.

With tag_regex specified, check will instead detect tags based on the regex provided. If created_at_sort is set to true, the tags will be sorted in descending order by the creation time. This is useful when you want to get the latest tag based on the regex (see Docker registry issue here).

With tag and tag_regex both omitted, check will instead detect tags based on semver versions (e.g. 1.2.3) and return them in semver order. With variant included, check will only detect semver tags that include the variant suffix (e.g. 1.2.3-stretch).

This resource comes with Concourse by default. You can override the version you use within your pipeline if the built-in one is not working for you for some reason

Comparison to docker-image resource

This resource is intended as a replacement for the Docker Image resource. Here are the key differences:

  • This resource is implemented in pure Go and does not use the Docker daemon or CLI. This makes it safer (no need for privileged: true), more efficient, and less error-prone (now that we're using Go APIs and not parsing docker CLI output).

  • This resource has stronger test coverage.

  • This resource does not and will never support building - only registry image pushing/pulling. Building should instead be done with something like the oci-build task (or anything that can produce OCI image tarballs).

  • A goal of this resource is to stay as focused and simple as possible. The Docker Image resource grew way too large and complicated. There are simply too many ways to build and publish Docker images. It will be easier to support many smaller resources + tasks rather than one huge interface.

Source Configuration

Field Name Description
repository (Required) The URI of the image repository, e.g. alpine or ghcr.io/package/image. Defaults to checking docker.io if no hostname is provided in the URI.
Note: If using ecr you only need the repository name, not the full URI e.g. alpine not 012345678910.dkr.ecr.us-east-1.amazonaws.com/alpine. ECR usage is NOT automatically detected. You must set the aws_region to tell the resource to automatically use ECR.
insecure (Optional)
Default: false
Allow insecure registry.
tag (Optional)
Default: latest
Instead of monitoring semver tags, monitor a single tag for changes (based on digest).
tag_regex (Optional) Instead of monitoring semver tags, monitor for tags based on a regex provided.
The syntax of the regular expressions accepted is the same general syntax used by Perl, Python, and other languages. More precisely, it is the syntax accepted by RE2 and described at https://golang.org/s/re2syntax
Note if used, this will override all Semver constraints and features. By default, order of tags is not guaranteed. If you want to sort the tags in descending order, set `created_at_sort` to `true`.
created_at_sort (Optional)
Default: false
If set to `true`, the tags will be sorted in descending order using the creation time from the image history. This is useful when you want to get the latest tag based on the tag_regex.
variant (Optional) Detect only tags matching this variant suffix, and push version tags with this suffix applied. For example, a value of stretch would be used for tags like 1.2.3-stretch. This is typically used without tag - if it is set, this value will only used for pushing, not checking.
semver_constraint (Optional) Constrain the returned semver tags according to a semver constraint, e.g. "~1.2.x", ">= 1.2 < 3.0.0 || >= 4.2.3".
Follows the rules outlined in https://github.com/Masterminds/semver#checking-version-constraints
If the value appends with -0 for pre-release versions, pre_releases needs to be true.
pre_releases (Optional) By default, pre-release versions are ignored. With `pre_releases: true`, they will be included.
Note however that variants and pre-releases both use the same syntax: `1.2.3-alpine` is technically also valid syntax for a Semver prerelease. For this reason, the resource will only consider prerelease data starting with `alpha`, `beta`, or `rc` as a proper prerelease, treating anything else as a variant.
username and password (Optional) A username and password to use when authenticating to the registry. Must be specified for private repos or when using put.
aws_access_key_id (Optional) The access key ID to use for authenticating with ECR.
aws_secret_access_key (Optional) The secret access key to use for authenticating with ECR.
aws_session_token (Optional) The session token to use for authenticating with STS credentials with ECR.
aws_region (Optional) The region to use for accessing ECR. This is required if you are using ECR. This region will help determine the full repository URL you are accessing (e.g., 012345678910.dkr.ecr.us-east-1.amazonaws.com)
aws_role_arn (Optional) If set, then this role will be assumed before authenticating to ECR. An error will occur if aws_role_arns is also specified. This is kept for backward compatibility.
aws_role_arns (Optional) An array of AWS IAM roles. If set, these roles will be assumed in the specified order before authenticating to ECR. An error will occur if aws_role_arn is also specified.
aws_account_id (Optional) The AWS Account ID that the image is located in. Useful if interacting with images in another account. If omitted then the current AWS account ID will be used. Be sure to wrap the account ID in quotes so it is parsed as a string instead of a number.
platform (Optional)
(Experimental)
debug (Optional)
Default: false
If set, progress bars will be disabled and debugging output will be printed instead.
registry_mirror (Optional)
  • host (Required): A hostname pointing to a Docker registry mirror service. Note that this is only used if no registry hostname prefix is specified in the repository key. If the repository contains a registry hostname, such as my-registry.com/foo/bar, the registry_mirror is ignored and the explicitly declared registry in the repository key is used.
  • username and password (Optional): A username and password to use when authenticating to the mirror.
content_trust (Optional)
  • server (Optional): URL for the notary server. (equal to DOCKER_CONTENT_TRUST_SERVER)
  • repository_key_id (Required): Target key's ID used to sign the trusted collection, could be retrieved by notary key list
  • repository_key (Required): Target key used to sign the trusted collection.
  • repository_passphrase (Required): The passphrase of the signing/target key. (equal to DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE)
  • tls_key (Optional): TLS key for the notary server.
  • tls_cert (Optional): TLS certificate for the notary server.
  • username (Optional): Username for authorize Docker Registry with a Notary server(`content_trust.server`) attached.
  • password (Optional): Password for authorize Docker Registry with a Notary server(`content_trust.server`) attached.
  • scopes (Optional): What access for the resources requested, should be one of ['pull', 'push,pull', 'catalog']
ca_certs(Optional) An array of PEM-encoded CA certificates. Example:
ca_certs:
- |
  -----BEGIN CERTIFICATE-----
  ...
  -----END CERTIFICATE-----
- |
  -----BEGIN CERTIFICATE-----
  ...
  -----END CERTIFICATE-----
    

Each entry specifies the x509 CA certificate for the trusted docker registry. This is used to validate the certificate of the docker registry when the registry's certificate is signed by a custom authority (or itself).

Signing with Docker Hub

Configure Docker Content Trust for use with the Docker Hub and Notary service by specifying the above source parameters as follows:

  • repository_key should be set to the contents of the DCT key file located in your ~/.docker/trust/private directory.
  • repository_key_id should be set to the full key itself, which is also the filename of the key file mentioned above, without the .key extension.

Consider the following resource:

resources:
- name: trusted-image
  type: registry-image
  source:
    repository: docker.io/foo/bar
    username: ((registry_user))
    password: ((registry_pass))
    content_trust:
      repository_key_id: ((registry_key_id))
      repository_key: ((registry_key))
      repository_passphrase: ((registry_passphrase))

Specify the values for these variables as shown in the following static variable file, or preferrably in a configured credential manager:

registry_user: jertel
registry_pass: my_docker_hub_token
registry_passphrase: my_dct_key_passphrase
registry_key_id: 1452a842871e529ffc2be29a012618e1b2a0e6984a89e92e34b5a0fc21a04cd
registry_key: |
  -----BEGIN ENCRYPTED PRIVATE KEY-----
  role: jertel

  MIhsj2sd41fwaa...
  -----END ENCRYPTED PRIVATE KEY-----

NOTE This configuration only applies to the out action. check & in aren't impacted. Hence, it would be possible to check or use in to get unsigned images.

Behavior

check Step (check script) with tag: discover new digests for the tag

Reports the current digest that the registry has for the tag configured in source.

check Step (check script) with tag_regex: discover tags matching regex

Reports the current digest that the registry has for tags matching the regex configured in source. They will be returned in the same order that the source repository lists them unless created_at_sort is set to true.

check Step (check script) without tag or tag_regex: discover semver tags

Detects tags which contain semver version numbers. Version numbers do not need to contain all 3 segments (major/minor/patch).

Each unique digest will be returned only once, with the most specific version tag available. This is to handle "alias" tags like 1, 1.2 pointing to 1.2.3.

Note: the initial check call will return all valid versions, which is unlike most resources which only return the latest version. This is an intentional choice which will become the normal behavior for resources in the future (per concourse/rfcs#38).

Example:

resources:
- name: concourse
  type: registry-image
  source: {repository: concourse/concourse}

The above resource definition would detect the following versions:

[
  {
    "tag": "1.6.0",
    "digest": "sha256:e1ad01d3227569ad869bdb6bd68cf1ea54057566c25bae38b99d92bbe9f28d78"
  },
  {
    "tag": "2.0.0",
    "digest": "sha256:9ab8d1021d97c6602abbb2c40548eab67aa7babca22f6fe33ab80f4cbf8ea92c"
  },
  // ...
]

Variant tags

Docker repositories have a pretty common convention of adding -SUFFIX to tags to denote "variant" images, i.e. the same version but with a different base image or dependency. For example, 1.2.3 vs 1.2.3-alpine.

With a variant value specified, only semver tags with the matching variant will be detected. With variant omitted, tags which include a variant are ignored.

Note: some image tags actually include mutliple variants, e.g. 1.2.3-php7.3-apache. With a variant of only apache configured, these tags will be skipped to avoid accidentally using multiple variants. In order to use these tags, you must specify the full variant combination, e.g. php7.3-apache.

Example:

resources:
- name: concourse
  type: registry-image
  source:
    repository: concourse/concourse
    variant: ubuntu

The above resource definition would detect the following versions:

[
  {
    "tag": "5.2.1-ubuntu",
    "digest": "sha256:91f5d180d84ee4b2cedfae45771adac62c67c3f5f615448d3c34057c09404f27"
  },
  {
    "tag": "5.2.2-ubuntu",
    "digest": "sha256:cb631d788797f0fbbe72a00afd18e5e4bced356e1b988d1862dc9565130a6226"
  },
  // ...
]

get Step (in script): fetch an image

Fetches an image at the exact digest specified by the version.

get Step params

Parameter Description
format (Optional)
Default: rootfs
The format to fetch the image as. Accepted values are: rootfs, oci
skip_download (Optional)
Default: false
Skip downloading the image. Useful if you want to trigger a job without using the object or when running after a put step and not needing to download the image you just uploaded.

Files created by the get step

The resource will produce the following files:

  • ./repository: A file containing the image's full repository name, e.g. concourse/concourse. For ECR images, this will include the registry the image was pulled from.
  • ./tag: A file containing the tag from the version.
  • ./digest: A file containing the digest from the version, e.g. sha256:....
  • ./labels.json: A file containing a JSON map of image labels, e.g. { "commit": "4e5c4ea" }

The remaining files depend on the configuration value for format:

rootfs Format

The rootfs format will fetch and unpack the image for use by Concourse task and resource type images.

This the default for the sake of brevity in pipelines and task configs.

In this format, the resource will produce the following files:

  • ./rootfs/...: the unpacked rootfs produced by the image.
  • ./metadata.json: the runtime information to propagate to Concourse.
oci Format

The oci format will fetch the image and write it to disk in OCI format. This is analogous to running docker save.

In this format, the resource will produce the following files:

  • ./image.tar: the OCI image tarball, suitable for passing to docker load.

put Step (out script): push and tag an image

Pushes an image to the registry as the specified tags.

The currently encouraged way to build these images is by using the oci-build-task.

Tags may be specified in multiple ways:

  • With tag configured in source, the configured tag will always be pushed.
  • With version given in params, the image will be pushed using the version number as a tag, optionally with a variant suffix (configured in source).
  • With additional_tags given in params, the image will be pushed as each tag listed in the file (whitespace separated). Only those tags are pushed, e.g. the default latest isn't included.

put Steps params

Parameter Description
image (Required) The path to the oci image tarball to upload. Expanded with filepath.Glob
version (Optional) A version number to use as a tag.
bump_aliases (Optional)
Default: false
When set to true and version is specified, automatically bump alias tags for the version. For example, when pushing version 1.2.3, push the same image to the following tags:
  • 1.2, if 1.2.3 is the latest version of 1.2.x.
  • 1, if 1.2.3 is the latest version of 1.x.
  • latest, if 1.2.3 is the latest version overall.
If variant is configured as foo, push the same image to the following tags:
  • 1.2-foo, if 1.2.3 is the latest version of 1.2.x with foo.
  • 1-foo, if 1.2.3 is the latest version of 1.x with foo.
  • foo, if 1.2.3 is the latest version overall for foo.
Determining which tags to bump is done by comparing to the existing tags that exist on the registry.
additional_tags (Optional) The path to a file with whitespace-separated list of tag values to tag the image with (in addition to the tag configured in source, but not the default `latest` tag if no tag is configured).

Use in tasks

Images used as image resources in tasks are called anonymous resources. Anonymous resources can specify a version, which is the image digest. For example:

image_resource:
  type: docker-image
  source:
    repository: golang
  version:
    digest: 'sha256:5f640aeb8b78e9876546a9d06b928d2ad0c6e51900bcba10ff4e12dc57f6f265'

This is useful when the registry image does not have tags, or when the tags are going to be re-used.

Development

Prerequisites

  • golang is required - version 1.11.x or above is required for go mod to work
  • docker is required - version 17.06.x is tested; earlier versions may also work.
  • go mod is used for dependency management of the golang packages.

Running the tests

The tests have been embedded with the Dockerfile; ensuring that the testing environment is consistent across any docker enabled platform. When the docker image builds, the test are run inside the docker container, on failure they will stop the build.

Run the tests with the following commands:

docker build -t registry-image-resource --target tests --build-arg base_image=paketobuildpacks/run-jammy-base:latest .

Integration tests

The integration requires 3 docker repos: one private dockerhub repo, one public dockerhub repo, and one GCR repo. The docker build step requires setting --build-args so the integration will run.

Run the tests with the following command:

docker build . -t registry-image-resource --target tests \
  --build-arg DOCKER_PRIVATE_USERNAME="some-username" \
  --build-arg DOCKER_PRIVATE_PASSWORD="some-password" \
  --build-arg DOCKER_PRIVATE_REPO="some/repo" \
  --build-arg DOCKER_PUSH_USERNAME="some-username" \
  --build-arg DOCKER_PUSH_PASSWORD="some-password" \
  --build-arg DOCKER_PUSH_REPO="some/repo" \
  --build-arg GCR_PUSH_SERVICE_ACCOUNT_KEY='{"some":"json"}' \
  --build-arg GCR_PUSH_REPO="some/repo"

Note that you may omit any of the repo credentials in order to skip those integration tests.

Contributing

Please make all pull requests to the master branch and ensure tests pass locally.

registry-image-resource's People

Contributors

cdmessin avatar chenbh avatar cherwin avatar dan-hill2802 avatar dependabot-preview[bot] avatar dependabot-support avatar dependabot[bot] avatar exp0nge avatar fenech avatar hbd avatar infra-red avatar int-tt avatar jertel avatar jhosteny avatar jtarchie avatar mattburgess avatar osis avatar owenfarrell avatar pivotal-bin-ju avatar pn-santos avatar pvaramballypivot avatar simonxming avatar taylorsilva avatar tlwr avatar tvon-a avatar vito avatar vixus0 avatar xtreme-sameer-vohra avatar xtremerui avatar youssb avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

registry-image-resource's Issues

invalid payload: json: unknown field "aws_access_key_id"

I'm trying to push an image built from a custom task script to an ECR repository with the following pipeline configuration:

# no resource_types entry for registry-image; using built-in.

resources:
- name: foo
  type: registry-image
  source:
    repository: category/my-ecr-image-name
    aws_access_key_id: ((aws_access_key_id))
    aws_secret_access_key: ((aws_secret_access_key))
    tag: something

jobs:
- name: publish
  plan:
  - task: build foo which produces foo-image volume
     ...
  - put: foo
    params:
      image: foo-image

The put step then fails with:

ERRO[0000] invalid payload: json: unknown field "aws_access_key_id" 

This doesn't immediately make sense to me as aws_access_key_id is a documented source attribute, and I can see that the Go struct defines it: https://github.com/concourse/registry-image-resource/blob/master/types.go#L31

What might I be doing wrong?

Concourse version: 5.8.0

Fetch all tags associated with image

We have an image that we create on every push to our codebase using Github Actions.These images are tagged with the git SHA and branch name. So a push to master creates an image cfroutesync:master and cfroutesync:269bff3d11a3722826f8a60e3893506d080ba2b.

On Concourse we're using the registry-image-resource to check for updates to cfroutesync:master and deploy them to a Kubernetes cluster. However, we want to deploy the image tagged with the git SHA and there currently isn't a way to easily retrieve that.

Would it be possible for this resource to return all remote tags associated with the image?

Make it easier to push semver tags

This would be a nice sugar on top of additional_tags - Docker has a pretty strong convention of pushing a version like 1.2.3 under tags 1, 1.2, and 1.2.3 (assuming it's the latest release):

put: my-image
params:
  semver_tags: version/version

Might want to make the level configurable; if it's a patch for an older version it makes sense to push 1.2 and 1.2.3 but not 1:

put: my-image
params:
  semver_minor_tags: version/version

(just a quick mockup, there may be a more intuitive way to configure this)

Dependabot can't parse your go.mod

Dependabot couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: github.com/simonshyu/[email protected] requires
	github.com/spf13/[email protected] requires
	github.com/grpc-ecosystem/[email protected] requires
	gopkg.in/[email protected]: invalid version: git fetch --unshallow -f origin in /opt/go/gopath/pkg/mod/cache/vcs/748bced43cf7672b862fbc52430e98581510f4f2c34fb30c0064b7102a68ae2c: exit status 128:
	fatal: The remote end hung up unexpectedly

View the update logs.

Can't push OCI image layout

Reproduction:

#!/bin/bash
set -x
mkdir -p /tmp/repro
cd /tmp/repro
rm -f image.tar
buildah pull busybox
buildah push busybox oci-archive:image.tar
echo '{"params":{"image":"image/image.tar"},"source":{"repository":"example","tag":"latest"}}' \
  | podman run -it --rm -v $PWD/image.tar:/build/image/image.tar concourse/registry-image-resource /opt/resource/out /build

Output:

+ mkdir -p /tmp/repro
+ cd /tmp/repro
+ buildah pull busybox
db8ee88ad75f6bdc74663f4992a185e2722fa29573abcc1a19186cc5ec09dceb
+ rm -f image.tar
+ buildah push busybox oci-archive:image.tar
Getting image source signatures
Copying blob 0d315111b484 done
Copying config d068e40b11 done
Writing manifest to image destination
Storing signatures
Successfully pushed image.tar:@sha256:42212762065786db5a6fee614c801044c9328da5389b30c314c001d1e186a2ce
+ echo '{"params":{"image":"image/image.tar"},"source":{"repository":"example","tag":"latest"}}'
+ podman run -it --rm -v /tmp/repro/image.tar:/build/image/image.tar concourse/registry-image-resource /opt/resource/out /build
{"params":{"image":"image/image.tar"},"source":{"repository":"example","tag":"latest"}}
ERRO[0000] could not load image from path 'image/image.tar': file manifest.json not found in tar 

Indeed, there is no manifest.json in the OCI Image Layout Specification.

As a workaround, I changed my task to do buildah push whatever docker-archive:image.tar, but it would be nice if registry-image-resource supported OCI images.

Support ENTRYPOINT and CMD

It would be pretty nifty if this resource knew to extract the ENTRYPOINT and CMD config and forward that to Concourse. Then we could allow users to omit run config. This would be a step towards reusable tasks.

Make "get" during "put" step additional

Just as documented in the docker-image-resource:

As with all concourse resources, to modify params of the implicit get step after each put step you may also set these parameters under a put get_params. For example:

put: foo
params: {...}
get_params: {skip_download: true}

Alpine image does not honor /etc/hosts due to missing /etc/nsswitch.conf

If for whatever reason you need to set CONCOURSE_GARDEN_ADDITIONAL_HOST_ENTRY (or populate /etc/hosts some other way) then it will be ignored by alpine images.

This is apparently due to golang/go#22846 and I suppose gliderlabs/docker-alpine#367.

In short, /etc/nsswitch.conf is not present in alpine which causes golang to ignore /etc/hosts. To remedy this the file /etc/nsswitch.conf needs to be created with the content hosts: files dns (I believe this tells it to look at /etc/hosts first and then DNS, given the default is to fallback to /etc/hosts only if DNS does not resolve).

The ubuntu variant works as expected.

Question about the plan for tagging built images

Disclaimer: Not sure if this is the right place to post this, or if it's "too soon" in the development for asking (seeing this is still "beta"). Apologies if it is.

I was wondering what the vision/plan is for tagging images. I know put is still very early stages but this resource as it stands, requires tags to be specified "statically" (in the pipeline config). However I think it's a frequent use case to tag built images with runtime generated values (like auto-incremented build nr, or git rev, etc.).

I've been experimenting with this resource (and the builder task - they work well and much faster than the docker-image resource btw 👍) and I've been pondering whether it would be useful to add the ability to read tags from a file when specifying a put (for example). But not sure if it fits in the plans for this resource.

From a design perspective it seems to go against specifying the tag in the source definition, since that implies the resource is tracking a specific tag, so for symmetry the put should update the tag...

Proposal: don't let "check" step failed if `source.tag` not exist on registry server

In current implement, even you don't specify source.tag, put step still push the image to the default latest tag.
Our user wants to avoid using latest tag and only keep versioned tag. In this case, registry-image check step will fail. Could you avoid this kind of failure in registry-image-resource?(the same case won't fail in docker-image-resource)

Ability to use semver version for tag

When using additional_tags option in the put params, the resource tags and pushes the images with the ones specified in the additional tags file and also the tag specified in resources' source. I am using semver concourse resource for versioning tags and I want to push just the tag specified in the file. Or is there a way I can pass my servem verion to the tag in the sources?

Resource

- name: docker-image
  type: registry-image
  source:
    repository: {{REPO_NAME}}
    username: ((username))
    password: ((password))
    tag: ##<servem-verion-file>##

Job

- put: docker-image
    params: 
      image: image/image.tar
      additional_tags: version/number

If passing the servem version to the tag is not possible can we use something similar to tag_file in the docker image resource?

Add support for STS credentials for AWS ECR

The current ECR functionality accepts AWS credentials when creating a session, but leaves the session token empty. It would be helpful to be able to us STS credentials, such as when credentials are provided to the task by a privileged credential provider, such as sidecred.

PR coming shortly.

Put & Artifactory Authentication

I've been trying to troubleshoot an issue I'm seeing with authenticating with a private docker registry hosted using Artifactory, but not sure where to go next in troubleshooting the issue.

First, I've successfully tested pushing artifacts to the Artifactory instance locally using the same user/pass I'm using within the resource source username and password fields defined within the registry-image resource. I can import the tarball using docker import and then push the image using docker push.

When attempting to use the registry-image to put the image to Artifactory I receive the error:

INFO[0000] pushing sha256:8c328069f241ed6370bbe95f22988f15542be1c737fd2613d0b584ae51a56c95 to artifactory.server.com:2077/base/image:latest
ERRO[0000] failed to upload image: no token in bearer response:
{"statusCode":401,"details":"BAD_CREDENTIAL"} 

I'd like to dive deeper into troubleshooting the container created for this put. What are some basic steps I can use to do so? For example, where are the credentials stored within the container (I notice that aren't set in environment variables). Second, is there something I can run within the container to test the same action executed with the put?

See below for an obfuscated version of my pipeline configuration. All stages up to the put are successful and I can see that the tarball is properly created and exists within the put stage's container.

resources:
- name: image-repo
  type: git
  source:
    branch: master
    private_key: ((private_key))
    uri: ssh://[email protected]:7999/project/repo.git

- name: artifactory
  type: registry-image
  source:
    repository: artifactory-server:2077/((repo))
    tag: latest
    username: ((destination_username))
    password: ((destination_password))
    debug: true

jobs:
- name: update-image
  plan:
  - get: image-repo
    trigger: true
  - task: process-and-update
    file: image-repo/scripts/process-and-update.yml
    vars:
      repository-directory: ((repo))
  - task: build-image
    privileged: true
    file: image-repo/scripts/build-image.yml
    vars:
      repository-directory: ((repo))
  - put: artifactory
    params:
      image: image/image.tar

Intermittent 504 errors when uploading image

Lately we are seeing intermittent 504 status errors when using this resource in a put step, trying to push an image built with the concourse/builder-task resource. This happens in ~ one out of 30 builds. Currently we resort to re-triggering the build and will probably use the attempt step modifier to get around this, but it would be great if the retry logic could be built-in / we could identify the cause and fix it for good.

Specifically we are using the forked resource with ECR support linked in here: #27

The concourse workers are running inside EC2 as well, so I assume networking not to be an issue.

This is what we see in the logs (debug is not yet enabled):

INFO[0009] pushing sha256:34a09a2c3c928632ba4744838ae799de33f85a70887eef8afd8080af6fe0a993 to <ECR-registry>/<image>:<tag>
2019/08/23 00:22:46 existing blob: sha256:37a3ead0766dcfba55ff2ccfa9860d25ee131493acebd7edc9eaae745c32411b
2019/08/23 00:22:46 existing blob: sha256:e53c3bcf61e07a59d01e2165e114c04160f066f2ed072da4c8cf91704e819179
2019/08/23 00:22:46 existing blob: sha256:dad366dafa97989db13e3371c5ade90997dc4a32b23e04617de5bbfeb6208b7c
2019/08/23 00:22:46 existing blob: sha256:0a4690c5d889e116874bf45dc757b515565a3bd9b0f6c04054d62280bb4f4ecf
2019/08/23 00:22:46 existing blob: sha256:687121a174978dda4981b1d1d0c047148b64cf6962df0edf440926cdc68074f0
2019/08/23 00:22:46 existing blob: sha256:d4542771caf6b5e86dce5c2a145a07f71af9f10e662f96c18c1a2547cae11651
2019/08/23 00:22:46 existing blob: sha256:c9cb2749d092c7fea537b446059e678c9ae92bfdc8beff186ee0cf84125a2027
2019/08/23 00:22:46 existing blob: sha256:e011ac85ea7cee3f26fbb106851eabcab8c9cd851badaf2b74797b1d2ed46b06
2019/08/23 00:22:46 existing blob: sha256:f0234a3d453d84d2fdb1cee057eed3408d1302a3cc6682afa9aca065277a03be
2019/08/23 00:22:46 existing blob: sha256:83ccbf5da27b43ce99e8cab70b6f18701bacd847b4047793ea939304faff3ff9
2019/08/23 00:22:46 existing blob: sha256:068294ceaa2e10baa1ae378b2ed47fe5ef9eef9e26cee7e57d319857d61bc4cd
2019/08/23 00:22:46 existing blob: sha256:2a31688e46c5c209e020965440e6d7ab15e1f6c1e71b8f1c21b788ed0454fffd
2019/08/23 00:24:12 pushed blob: sha256:06ff1ba3ace5a790b243100c5d1714801250c40df9b8854f7e6ab1211230b803
ERRO[0147] failed to upload image: unsupported status code 504; body: 

Tagging via fetched image digest fails

I'm not sure if this is something I'm doing something wrong but I can't seem to be able tag an image via the fetched digest. These are the steps I'm following:

  1. Pull an image using get (oci format)
  2. Run docker load -q -i image/image.tar
  3. Run `docker tag "$image_repo@$(cat image/digest)" "new-repo:new-tag"

Step 3 fails. However if I run a docker pull on the same image sha and retry step 3 it works!

Example (commands run in a intercepted container):

bash-5.0# cat image/digest
sha256:64cfcb80ef6a3c56701dc8585cb52b0d890e27b578e5128cc481e9625c0e4e14

bash-5.0# docker image ls
REPOSITORY                  TAG                 IMAGE ID            CREATED             SIZE
my-host:443/my-image-repo   dev-latest          77ced5983f57        8 minutes ago       764MB

bash-5.0# docker tag "my-host:443/my-image-repo@sha256:64cfcb80ef6a3c56701dc8585cb52b0d890e27b578e5128cc481e9625c0e4e14" "test-repo:blah"
Error response from daemon: No such image: my-host:443/my-image-repo@sha256:64cfcb80ef6a3c56701dc8585cb52b0d890e27b578e5128cc481e9625c0e4e14

bash-5.0# docker pull my-host:443/my-image-repo:dev-latest
dev-latest: Pulling from my-image-repo
Digest: sha256:64cfcb80ef6a3c56701dc8585cb52b0d890e27b578e5128cc481e9625c0e4e14
Status: Image is up to date for my-host:443/my-image-repo:dev-latest

bash-5.0# docker image ls
REPOSITORY                  TAG                 IMAGE ID            CREATED             SIZE
my-host:443/my-image-repo   dev-latest          77ced5983f57        9 minutes ago       764MB

bash-5.0# docker tag "my-host:443/my-image-repo@sha256:64cfcb80ef6a3c56701dc8585cb52b0d890e27b578e5128cc481e9625c0e4e14" "test-repo:blah"

bash-5.0# docker image ls
REPOSITORY                  TAG                 IMAGE ID            CREATED             SIZE
test-repo                   blah                77ced5983f57        9 minutes ago       764MB
my-host:443/my-image-repo   dev-latest          77ced5983f57        9 minutes ago       764MB

Any idea what could be the issue?

Some env info:

  • Concourse 5.3.0 (using bundled registry-image-resource)
  • Docker 18.09.8-ce (alpine 3.10.3 container)
  • Image was built using oci-build-task (v0.1)

Failed to pull/push image from quay registry

I have the following error when trying to pull image from quay repository:
ERRO[0000] failed to extract image: MANIFEST_UNKNOWN: "manifest unknown"

How to reproduce?
Simple pipeline:

---
jobs:
- name: my-test-job
  serial: true
  plan:
  - get: hyperkube-build-image


resources:
- name: hyperkube-build-image
  type: registry-image
  source:
    repository: quay.io:443/coreos/hyperkube
    tag: v1.9.6_coreos.2
  check_every: 60m

Here is what docker manifest command return:

> docker manifest inspect quay.io:443/coreos/hyperkube:v1.9.6_coreos.2
unsupported manifest media type and no default available: application/vnd.docker.distribution.manifest.v1+prettyjws

Can you please add the ability to pull/push image from/to quay registry?

Feature request: Support skip push to "latest" in `put`

Currently, in registry-resource, it always uses latest as the default tag in put step. So it pushes the image to the registry using latest along with additional_tags.

The request is to have params.tag_file in out config and when a user specifies tag_file disable push latest in put step. So that users have the flexibility to push the image with custom tags and not have latest tag by default.

Or maybe we could provide params.skip_latest or something like that.

Support `skip_download`?

Currently, when using skip_download, this resource produces ERRO[0000] invalid payload: json: unknown field "skip_download"

Will it be possible to add that?

Avoid reference to deprecate 'build' task in readme

I found this in the readme:

This resource does not and will never support building - only registry image pushing/pulling. Building should instead be done with something like the builder task (or anything that can produce OCI image tarballs).

When I follow the link under 'builder task' it leads me to some other page that says it is deprecated.

Maybe it is better to point directly to the thing that replaces deprecated builder task instead?

Example usage

Reading through the issues and documentation it seems this is a very idiomatic plugin for concourse but I can't configure it to work with concourse/builder-task --

I have an output from builder-task which is an image.tar file I want to upload to my registry on docker hub; is there an example task I can refer to for doing this?

Feature request: support digest in 'source'

Hi,
we'd like to specify a digest instead of a tag in the source section of a registry-image resource. This would make it easier for us to ensure that our jobs are using the correct version of our images because tags can be changed easily and only the digest is really unique.

I know that there is resource pinning available in Concourse v5 but it's not really the same thing.
E.g. if I provide a wrong digest (no image available for that digest) the pinning causes the job to wait forever until a resource with this digest is available. Instead I would like to have a failing resource with some error message (e.g. digest not found).

As a digest is an alternate way to get a specific version of an image I think the right place to specify it would be in source section:

resources:
- name: my-image
  type: registry-image
  source:
    repository: myrepo/my-image
    digest: sha256:a252b563fad36e16b71c0aab7d1ea8e380c6a4b21d69d6d38efa4cd873e8da09

What do you think about this?

check failed: get remote image: unsupported status code 405

I've stumbled on this very misleading error message when I'm trying to use a registry-image resource to run a task with a specific docker image.

error

After some playing around with it, I found out, that this happens when the credentials are incorrect and the basic authentication fails.

Here is a sample pipeline, which can be used to reproduce it

---
jobs:
  - name: job-hello-world
    public: true
    plan:
      - task: hello-world
        config:
          platform: linux
          image_resource:
            type: registry-image
            source:
              repository: weberstephanhd/iacbox22
              tag: v280
              username: fake-user
              password: fake-password
          run:
            path: echo
            args: [hello world]

I've reproduced it with registry-image-resource packed in Concourse 5.8.0.

Ideally, the error message should be 401 Unauthorized.

Insecure registries not supported

We can not switch from docker-image to registry-image due to insecure registries not being supported. Is there any plan to support insecure registries?

Ability to add full description from README.md in Docker Hub

It would be nice to add a description out parameter to be able to add a full description in Docker Hub from a README.md file (usually from the git repository that contains the Dockerfile used to build the image).

It could be something like this:

  - put: docker-hub
    params:
      image: image/my-beautiful-image.tar
      description: repo/README.md

Of course that feature would only works with Docker Hub repository.

For us it would be nice because we want to be on par between an image description from Docker Hub and the GitHub repository that contains the files used to build that image.

Does it sound a good idea?

"put" step fails with error "x509: certificate signed by unknown authority"

Hi,

I've been pulling my hairs off for a few days trying to get this resource type to pull/push to a local private Docker registry that I have setup.

My setup is rather simple :

  • Concourse is run on my local machine (run under Debian) using the official Docker compose file (with a database, a web service, and a worker)
  • The Docker registry is run on my local machine as well
  • I made myself my own Certificate Authority and used this CA to generate my Docker registry's certificate
  • I accepted my own CA certificate by the usual dpkg-reconfigure ca-certificates

At this point things go pretty well :

  • From my local machine, using the docker CLI, I can push/pull to my local docker registry
  • From a machine on my LAN, I can push/pull as well (provided it has accepted the CA)
  • From any container I run on my local machine, I can access my registry as well (provided I have updated the CAs in the containers) via curl (e.g. curl https://time.home/v2/_catalog returns the list of my repositories [time.home being my machine's hostname] )
  • concourse/builder or img run "by hand" on my machine (via a docker run) can also push/pull to my local registry (provided their CAs have been updated of course)

Now, in Concourse, I have setup a very simple pipeline whose sole job is to build a docker image (using concourse/builder on a minimal workspace I build within one of the tasks) and push it to my local registry (using the resource type provided in this repo).

The build step goes great, the image is built, and then comes the final put stage, that always ends the same way :

INFO[0000] pushing sha256:c1acdd46a1c94d8cd5349878ff567eea6efd1af2a272fdbbe29219cfde9bf15a to time.home/dummy-base: 
ERRO[0000] failed to upload image: Get https://time.home/v2/: x509: certificate signed by unknown authority 

I've been looking around everywhere for days trying to understand what was going on (having no experience with Docker, SSL, Concourse I didn't want to jump to conclusions), and I've found a hack that basically suits my limited needs, which is to generate beforehand my own Docker image of concourse/registry-image-resource updated with my own CA.

But my understanding is that it should work, even though I've read issues and PRs that make it look like a rather sensible subject (especially concourse/concourse#1027), but nonetheless dealt with for such a basic case.

The documentation seems rather clear on the subject :

Certificates can be automatically propagated into each resource container, if the worker is configured to do so.

So I've added my machine certs' dir in the worker's environment in docker-compose via CONCOURSE_CERTS_DIR=/etc/ssl/certs/, to no success. If I inspect the put step that fails, curl fails and there's no trace of my certificate in the /etc/ssl/certs :

fly -t local i -j dummy-new/build-docker-base 
1: build #4, step: build-docker-image-base, type: task
2: build #4, step: build-workspace-base, type: task
3: build #4, step: dummy-image-base, type: put
choose a container: 3
bash-4.4# apk add curl
...
bash-4.4# curl https://time.home/v2/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
bash-4.4# cat /etc/ssl/certs/ca-certificates.crt | grep QrnlfZjA1GyrEakJ1EXqWW32xQ9ZcSxFCjmebu8RPHBr4WGZZVRvltiWJ707PGdP

I can't even add it "by hand" within that container, since the /etc/ssl/certs is read-only (which seems to prove that the certificates are propagated indeed) :

bash-4.4# update-ca-certificates 
Failed to open temporary file /etc/ssl/certs/bundleXXXXXX for ca bundl
bash-4.4# cat /usr/share/ca-certificates/theenglishway.crt >> /etc/ssl/certs/ca-certificates.crt 
bash: /etc/ssl/certs/ca-certificates.crt: Read-only file system
bash-4.4# mount
...
/dev/sda2 on /etc/ssl/certs type ext4 (ro,relatime,errors=remount-ro)
...

Among all the investigation I've made, I've noticed that using update-ca-certificate on a plain alpine image does not have the intended effect :

$ docker run -ti -v $(pwd)/certs/ca/:/certs alpine 
/ # apk add ca-certificates curl
...
/ # cp /certs/ca.crt /usr/share/ca-certificates/ca.crt
/ # update-ca-certificates 
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
/ # curl https://time.home/v2/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Simply appending my certificate file makes it work :

$ docker run -ti -v $(pwd)/certs/ca/:/certs alpine 
/ # apk add ca-certificates curl
...
/ # cat /certs/ca.crt >> /etc/ssl/certs/ca-certificates.crt 
/ # curl https://time.home/v2/_catalog
{"repositories":["alpine","docker-builder","dummy-base","dummy-full","image-builder","registry-image-resource"]}

This seems to be a known issue, and though it is marked as closed, it does not seem to be working so fine ... Could it be related ?

I'll add that the whole pipeline works like a charm if I use a slightly updated image of concourse/registry-image-resource (with my CA embedded and "enabled"), and that the legacy docker resource type works fine in that regard as well, provided it's correctly setup (with ca_certs) ... It's painfully slow, though, so I'm glad I ended up finding @vito 's builder and registry-image-resource that work so much faster 👍

As I said I've been investigating this issue for days so maybe I've missed something obvious but now that I've found a rather clean workaround that fits my needs, I wanted to publicize this issue and get your thoughts about it

(BTW I might be able to share a git repo with the setup to reproduce this issue if needed, it just needs a bit of cleaning up)

Support pushing images up to the registry

We could really easily support pushing docker saved images, using these two methods:

This would mesh really well with a Kaniko-based task for doing the actual building. Related: https://github.com/concourse/rfcs/issues/7 and concourse/docker-image-resource#190 (comment)

We'll probably need auth support for this first (#1).

Get step fails with images from old schema version

Hey,

As noticed by Trevor in Discord (sorry, I don't know how to link to a message there), old images like tutum/hello-world and tutum/curl fail to be fetched by registry-image when performing being geted.

That seems very related to the fact that these images use an older schema version (although that's detectable).

Using the following snippet (click to expand), we can see the different schema versions:

snippet
#!/bin/bash

set -o errexit

main() {
check_args "$@"

local image=$1
local tag=$2
local token=$(get_token $image)

echo "$(get_tag $image $tag $token)"
}

get_token() {
local image=$1

echo "Retrieving Docker Hub token.
IMAGE: $image
" >&2

curl
--silent
"https://auth.docker.io/token?scope=repository:$image:pull&service=registry.docker.io"
| jq -r '.token'
}

get_tag() {
local image=$1
local tag=$2
local token=$3

echo "Retrieving tag config.
IMAGE: $image
TAG: $tag
TOKEN: $token
" >&2

curl
--silent
--header "Accept: application/vnd.docker.distribution.manifest.v2+json"
--header "Authorization: Bearer $token"
"https://registry-1.docker.io/v2/$image/manifests/$tag"
| jq -r '.'
}

check_args() {
if (($# != 2)); then
echo "Error:
Two arguments must be provided - $# provided.

Usage:
  $0 <image> <tag>

Aborting."
exit 1
fi
}

main "$@"


./get-tag.sh concourse/concourse latest | grep schema
  "schemaVersion": 2,

./get-tag.sh tutum/hello-world latest | grep schema
  "schemaVersion": 1,

To reproduce:

resources:
  - name: image-docker
    type: docker-image
    source:
      repository: tutum/hello-world

  - name: image-registry
    type: registry-image
    source:
      repository: tutum/hello-world

jobs:
  - name: test
    plan:
      - aggregate:
        - get: image-docker
        - get: image-registry

Screen Shot 2019-03-11 at 9 12 03 AM

If that should be considered a bug ... I'm not sure 🤷‍♂️

Maybe for now it's more of a matter of documenting the behavior?

Thanks!

Retry on 429 errors

Seems like we're getting this error a lot from Docker Hub all of a sudden:

ERRO[0002] failed to get remote image: unrecognized HTTP status: 429 Too Many Requests

We should retry with exponential backoff.

Failed to pull specific image from Docker Hub

We found an issue with registry image where an image available in Docker Hub and docker pullable failed in the get step of a job.

The image failing in the get step is from RabbitMQ Docker Hub:

rabbitmq@sha256:7c592e6c6b3510fa4353fa078ee3d5bd0b0ea5500ddee31607b964f02d0b46e2

This is how our resource definition and job is configured:

- name: rabbitmq-release
  type: registry-image
  source:
    repository: rabbitmq
    tag: 3.8-rc-management
  version: {digest: "sha256:7c592e6c6b3510fa4353fa078ee3d5bd0b0ea5500ddee31607b964f02d0b46e2"}

- name: some-job
  plan:
  - get: rabbitmq-release
    params:
      format: oci
[...]

In the get step, we get the following error message:

fetching rabbitmq@sha256:7c592e6c6b3510fa4353fa078ee3d5bd0b0ea5500ddee31607b964f02d0b46e2
ERRO[0000] failed to write OCI image: unsupported status code 404; body: 404 page not found 

However, we are able to docker pull this image. Worth mentioning, this image has another SHA rabbitmq@sha256:76346c31d3eee20f82ebc2573cb0be891e4827b35e875f53cc93c9df76143732 that is docker pullable and it works fine with the registry image resource.

Private registry with kubernetes credentials not working

Hello there, with the following pipeline.yml

---
resources:
- name: sample-repository
  type: git
  source:
    uri: <REPO>
    private_key: <PRIVATE_KEY>

- name: sample-image
  type: registry-image
  source:
    repository: <PRIVATE_REGISTRY>
    username: <K8S-SECRET>
    password: <K8S-SECRET>

jobs:
  - name: build-publish-image
    plan:
    - get: sample-repository
      passed:
      - tests
      trigger: true
    - config:
        container_limits: {}
        image_resource:
          source:
            repository: vito/oci-build-task
          type: registry-image
        inputs:
        - name: sample-repository
          path: .
        outputs:
        - name: image
        platform: linux
        run:
          path: build
      privileged: true
      task: build
    - params:
        image: image/image.tar
      put: image

we are facing the following issue:

  • If I use the user/pass as a plain text on the registry-image, it works like charm
  • If I use a kubernetes secret, the put step fails due to a 401 (unauthorized) error.

Some key points:

  • I can guarantee that the secret is ok (base64 encoded, so, when I decode it, it is the desired user/pass)
  • I can successfully publish the image using the docker-image-resource with the same k8s user/pass

migration from docker-image to registry-image resource

While looking over the docker image resource, I’ve noticed that there are few configurations (though, I don’t use), may need some guidance in a migration.

For example, the fields aws_access_key_id in the source is very specific to AWS. Is there way to use those in this resource? Are they even needed?

Can't authorize to Google Container Registry with json key

Concourse setup: with docker-compose
Concourse version: 4.2.1

I have following resource described in my pipeline.

resources: [
   {
         "name": "bill-transactions-api-image",
         "source": {
            "password": "((service_account_json))",
            "repository": "eu.gcr.io/((project))/image",
            "username": "_json_key"
         },
         "type": "registry-image"
      }
]

And I'm getting this error:

resource script '/opt/resource/check []' failed: exit status 1

stderr:
�[31mERRO�[0m[0000] failed get image digest: UNAUTHORIZED: "You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication" 

While I used docker-image resource, everything worked fine. I've only changed resource type.

"put" step fails with error "not implemented"

Fairly basic pipeline, just builds an image:

jobs:
- name: build-image
  plan:
  - aggregate:
    - get: dockerfile
      trigger: true
  - task: build
    privileged: true
    config:
      platform: linux
      image_resource:
        type: registry-image
        source: {repository: concourse/builder}
      params:
        REPOSITORY: bdaimna20corecr01.azurecr.io/terraform/azuretfv
        TAG: latest
        CONTEXT: dockerfile/dockerfiles/azuretfv
      inputs: [{name: dockerfile}]
      outputs: [{name: image}]
      run: {path: build}
  - put: build-image
    params: {image: image/image.tar}

- name: build-image
  type: registry-image
  source:
    repository: bdaimna20corecr01.azurecr.io/terraform/azuretfv
    username: ((registry-username))
    password: ((registry-password))

On the put step, receiving the following in Concourse:

ERRO[0000] not implemented                              

Any ideas?

Access denied from ECR even though EC2 have read access

Hi!

Just want to thank you for all the awesome work first!

The issue I've encountered is, it seems like registry-image can't grab images from ECR even though the IAM of the EC2 have read access to it.

Here's the screenshot of the error.
401-ecr

I tried digging through the logs to find that error but was unsuccessful so the screenshot is all I can provide.

Semver tags should be used for versions - not digests

This has been brewing for a while. I hope to have more concrete details soon.

Over time there have been a few indicators that the versioning approach of this resource is a bit problematic, and we should instead find a reasonable way to interpret semver-like tags as versions, either instead of or in addition to digests (for purposes of detecting overwritten tags).

Digests are great for precisely identifying an image and detecting when a tag has changed, but pretending that a single tag represents a versioned history is a bit of a lie, since a tag can only really point to one digest, and doesn't contain information about prior digests that it pointed to.

Tags are often used semver-style, with a single repository having tags for e.g. 1.0.0, 1.0.1, 1.2.3 etc. This is in addition to tags like 1 and 1.0 which are "shorthand" allowing folks to refer to a semver "version line" without having to be precise. We'd have to figure out how to reconcile those too.

I'm opening this early so I can go back to it later and provide more concrete pain points around the current digest-based versioning scheme, but if you've run into any please leave them here too!

Registry image resource v0.8.1 DIGEST_INVALID error

When doing a resource put, we observed this error

INFO[0006] pushing sha256:bb26db804aba789e8f7ceb096fcbf505eb4039a502fad19aa6f6c8f98aa6b171 to index.docker.io/concourse/dev:latest 
2019/11/01 01:02:16 [DEBUG] GET https://index.docker.io/v2/
2019/11/01 01:02:16 [DEBUG] GET https://auth.docker.io/token?scope=repository%3Aconcourse%2Fdev%3Apush%2Cpull&service=registry.docker.io
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:ff1ee406b3be50c26a03f45ac4f3b44514afe28efb622aaea1ed5fda587d7e72
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:f72ac68b1cced6960902bdb52d972fac2287d7afc7384e5f37224cd12d1bca11
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:005c899d27a5e32209a114e9de8a1d89b3ee51126c668326e3464e6930a0963a
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:d1072db285cc5eb2f3415891381631501b3ad9b1a10da20ca2e932d7d8799988
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:858453671e6769806e0374869acce1d9e5d97f5020f86139e0862c7ada6da621
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:e2f8d62ebfe98a4ca8998a2073394f0c7487129deb8a033ac6c6232390cde2f8
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:0e44111e1ecefadbfcfc6f55a3753619d64c783a9e0f2624f7f8aa857d1fbeea
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:26e91f006848acd6de48f650c3ca8eec820cd5c128c7b18a3334168ba065d423
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:0b3bff5e840fa7f4b3bff64d3e10f58aa1d560f164f8d2689c730311468540af
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:c9fc4f402c5407deca47d1a3d7e9f86268d5c94c8ef1c7ad8fce311d2820fc2a
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:3521b36c951d3cf6f846757a099282b758c64a26378353ce961b1f84b6eec024
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:3d07b1124f982f6c5da7f1b85a0a12f9574d6ce7e8a84160cda939e5b3a1faad
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:0e10166626a2be62bdd0968bc16910e3279f750b046778856d80d6b34f74034f
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:b7b3373b37dbc0f24652208bd9faa0df144768b3c8c1750887ad34fb1732ffea
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:f428c5f42136a293bed974733fc9d396943f4f209ec8cfab15c529539a3deb38
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:99f6937bc42d517a18553d2728877c58e485d08426ade2f4c3426dc769323a58
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:7a9e2afc90a4b9ca9c44c7d16278d276a6bafe5783d2c3901142bed9ebd71845
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:c0403c697fcbec7c4d72ace484f6caa6da4283e9e61d5348ff848d28fd3eec3c
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:63bf8387b5151f4f8fffaf43854cd7b23bfafdada4406c11912a3b50bc3eb16c
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:7a2a5384bbd0cccedfc271914ffe2e36be0e39b62992f1a7adac27a2daa881d0
2019/11/01 01:02:16 [DEBUG] HEAD https://index.docker.io/v2/concourse/dev/blobs/sha256:a9c9f2d9c4ee6ad756070912ab2143311157b1d4dc5a8d7305a7b38a4efec4a5
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] POST https://index.docker.io/v2/concourse/dev/blobs/uploads/
2019/11/01 01:02:16 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/b9fe3b88-d36f-4132-8ad6-a8f96338484c?_state=GpiDftGIsYP4s9uum678NcdtmJ5nn996locqcJkVnmR7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImI5ZmUzYjg4LWQzNmYtNDEzMi04YWQ2LWE4Zjk2MzM4NDg0YyIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43Mjc1MDQxM1oifQ%3D%3D
2019/11/01 01:02:16 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/fc9023a1-b635-4fdf-8515-0c6d6ec22c29?_state=-jQffQR1lCEXG53PVjO4zkbBxom5-tkywhjqjcNfLwt7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImZjOTAyM2ExLWI2MzUtNGZkZi04NTE1LTBjNmQ2ZWMyMmMyOSIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MjMzMjkzMjZaIn0%3D
2019/11/01 01:02:16 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/34132cdc-3f3e-40c6-958e-bfe7767845b6?_state=h_3mdWJzhMkIwrXV069V1VwUjc7hJPMVS0cgcrSZHLR7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjM0MTMyY2RjLTNmM2UtNDBjNi05NThlLWJmZTc3Njc4NDViNiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MTc3NzMxMzNaIn0%3D
2019/11/01 01:02:17 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/1356d062-5af2-4197-96b6-f26470e9e374?_state=SSh6n1kKq45ocaUa-uH6rk-TSeV1scXTrDRQ1OwSuWd7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjEzNTZkMDYyLTVhZjItNDE5Ny05NmI2LWYyNjQ3MGU5ZTM3NCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43NTM4NjQwMTRaIn0%3D
2019/11/01 01:02:17 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/34132cdc-3f3e-40c6-958e-bfe7767845b6?_state=GrMUvqEk4Le0Z-GW4hucBuC08A5ocrgrB5EYkSr-Skt7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjM0MTMyY2RjLTNmM2UtNDBjNi05NThlLWJmZTc3Njc4NDViNiIsIk9mZnNldCI6MzM0OTYsIlN0YXJ0ZWRBdCI6IjIwMTktMTEtMDFUMDE6MDI6MTZaIn0%3D&digest=sha256%3A0b3bff5e840fa7f4b3bff64d3e10f58aa1d560f164f8d2689c730311468540af
2019/11/01 01:02:18 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/1356d062-5af2-4197-96b6-f26470e9e374?_state=d-HI6HaugV0E-mpHspGoN9Wj_AVc4gZPFWKhIfc2js57Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjEzNTZkMDYyLTVhZjItNDE5Ny05NmI2LWYyNjQ3MGU5ZTM3NCIsIk9mZnNldCI6MjY4NywiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNloifQ%3D%3D&digest=sha256%3A005c899d27a5e32209a114e9de8a1d89b3ee51126c668326e3464e6930a0963a
2019/11/01 01:02:18 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/b9fe3b88-d36f-4132-8ad6-a8f96338484c?_state=KkiPznt3BHGhHsHPfDN_Fvx8pAn9cJjWQEnHmp3ydNB7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImI5ZmUzYjg4LWQzNmYtNDEzMi04YWQ2LWE4Zjk2MzM4NDg0YyIsIk9mZnNldCI6OTU0NiwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNloifQ%3D%3D&digest=sha256%3A63bf8387b5151f4f8fffaf43854cd7b23bfafdada4406c11912a3b50bc3eb16c
2019/11/01 01:02:18 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/fc9023a1-b635-4fdf-8515-0c6d6ec22c29?_state=mW4qGq8UKOI5RhxoYl8i6xn3Rdb0Dw3LUMzuQEzAn1J7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImZjOTAyM2ExLWI2MzUtNGZkZi04NTE1LTBjNmQ2ZWMyMmMyOSIsIk9mZnNldCI6MzM0OTUsIlN0YXJ0ZWRBdCI6IjIwMTktMTEtMDFUMDE6MDI6MTZaIn0%3D&digest=sha256%3A0e44111e1ecefadbfcfc6f55a3753619d64c783a9e0f2624f7f8aa857d1fbeea
2019/11/01 01:02:20 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/cf383b2f-d99d-4672-805d-8e183e71be7e?_state=rgIC5jvWQH-eU1I_oPMGlnl0-mO2IPearC5boLQRPgd7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImNmMzgzYjJmLWQ5OWQtNDY3Mi04MDVkLThlMTgzZTcxYmU3ZSIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MjU2NzI4ODRaIn0%3D
2019/11/01 01:02:23 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/b86e1db5-b9f4-447d-ae09-28a491ae8688?_state=gZTO0RkUQUB72fNAc-PJOXsZzoOsv4q64WIXug4dTUN7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImI4NmUxZGI1LWI5ZjQtNDQ3ZC1hZTA5LTI4YTQ5MWFlODY4OCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43NjAzOTQ0NFoifQ%3D%3D
2019/11/01 01:02:35 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/cf383b2f-d99d-4672-805d-8e183e71be7e?_state=bBhMPrCMtWkdcpi0G6OYjqKQ3yt68MEgwj_Uf20jku97Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImNmMzgzYjJmLWQ5OWQtNDY3Mi04MDVkLThlMTgzZTcxYmU3ZSIsIk9mZnNldCI6MTA2MTA0ODAsIlN0YXJ0ZWRBdCI6IjIwMTktMTEtMDFUMDE6MDI6MTZaIn0%3D&digest=sha256%3A0e10166626a2be62bdd0968bc16910e3279f750b046778856d80d6b34f74034f
2019/11/01 01:02:35 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/110c4823-68e8-4036-a0a0-3507a0caa0eb?_state=hFFjAuDM3R5M_Iy5fH7IT5QowJrBzSKvfMOaOvg1WXR7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjExMGM0ODIzLTY4ZTgtNDAzNi1hMGEwLTM1MDdhMGNhYTBlYiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi44MTc1NjQ0NjZaIn0%3D
2019/11/01 01:02:35 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/b86e1db5-b9f4-447d-ae09-28a491ae8688?_state=Vh3cA0_5oFbPxLVO0l_oPWV-HSgiLn0yXmvqijenj4p7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImI4NmUxZGI1LWI5ZjQtNDQ3ZC1hZTA5LTI4YTQ5MWFlODY4OCIsIk9mZnNldCI6MTAyOTI0NTYsIlN0YXJ0ZWRBdCI6IjIwMTktMTEtMDFUMDE6MDI6MTZaIn0%3D&digest=sha256%3Ac0403c697fcbec7c4d72ace484f6caa6da4283e9e61d5348ff848d28fd3eec3c
2019/11/01 01:02:36 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/110c4823-68e8-4036-a0a0-3507a0caa0eb?_state=Z06-pSrwK0FSU3Trj2utnFgj8-2FKDM72wW2HN4C7pB7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjExMGM0ODIzLTY4ZTgtNDAzNi1hMGEwLTM1MDdhMGNhYTBlYiIsIk9mZnNldCI6MTA0NTU2MDksIlN0YXJ0ZWRBdCI6IjIwMTktMTEtMDFUMDE6MDI6MTZaIn0%3D&digest=sha256%3A3521b36c951d3cf6f846757a099282b758c64a26378353ce961b1f84b6eec024
2019/11/01 01:03:01 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/aa71cb8c-2bdd-4478-ac8d-aaca5e50d8fb?_state=LXQ3e1ClnIepszxch6vzO_X-aZlr6ofdBaFmawGFeeV7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImFhNzFjYjhjLTJiZGQtNDQ3OC1hYzhkLWFhY2E1ZTUwZDhmYiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MzIwOTcwMDRaIn0%3D
2019/11/01 01:03:01 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/09321ee0-beb3-472a-acc6-80bb2a472f20?_state=aYzodoEQxPcDyeD8A7eCrCBe4m-4bMghgQrV-t_NouV7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjA5MzIxZWUwLWJlYjMtNDcyYS1hY2M2LTgwYmIyYTQ3MmYyMCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MTYwMzE1OTRaIn0%3D
2019/11/01 01:03:11 [ERR] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/09321ee0-beb3-472a-acc6-80bb2a472f20?_state=aYzodoEQxPcDyeD8A7eCrCBe4m-4bMghgQrV-t_NouV7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjA5MzIxZWUwLWJlYjMtNDcyYS1hY2M2LTgwYmIyYTQ3MmYyMCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MTYwMzE1OTRaIn0%3D request failed: Patch https://index.docker.io/v2/concourse/dev/blobs/uploads/09321ee0-beb3-472a-acc6-80bb2a472f20?_state=aYzodoEQxPcDyeD8A7eCrCBe4m-4bMghgQrV-t_NouV7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjA5MzIxZWUwLWJlYjMtNDcyYS1hY2M2LTgwYmIyYTQ3MmYyMCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MTYwMzE1OTRaIn0%3D: net/http: TLS handshake timeout
2019/11/01 01:03:11 [ERR] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/aa71cb8c-2bdd-4478-ac8d-aaca5e50d8fb?_state=LXQ3e1ClnIepszxch6vzO_X-aZlr6ofdBaFmawGFeeV7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImFhNzFjYjhjLTJiZGQtNDQ3OC1hYzhkLWFhY2E1ZTUwZDhmYiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MzIwOTcwMDRaIn0%3D request failed: Patch https://index.docker.io/v2/concourse/dev/blobs/uploads/aa71cb8c-2bdd-4478-ac8d-aaca5e50d8fb?_state=LXQ3e1ClnIepszxch6vzO_X-aZlr6ofdBaFmawGFeeV7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImFhNzFjYjhjLTJiZGQtNDQ3OC1hYzhkLWFhY2E1ZTUwZDhmYiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MzIwOTcwMDRaIn0%3D: net/http: TLS handshake timeout
2019/11/01 01:03:11 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/09321ee0-beb3-472a-acc6-80bb2a472f20?_state=aYzodoEQxPcDyeD8A7eCrCBe4m-4bMghgQrV-t_NouV7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjA5MzIxZWUwLWJlYjMtNDcyYS1hY2M2LTgwYmIyYTQ3MmYyMCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MTYwMzE1OTRaIn0%3D: retrying in 1s (4 left)
2019/11/01 01:03:11 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/aa71cb8c-2bdd-4478-ac8d-aaca5e50d8fb?_state=LXQ3e1ClnIepszxch6vzO_X-aZlr6ofdBaFmawGFeeV7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImFhNzFjYjhjLTJiZGQtNDQ3OC1hYzhkLWFhY2E1ZTUwZDhmYiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MzIwOTcwMDRaIn0%3D: retrying in 1s (4 left)
2019/11/01 01:03:14 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/aa71cb8c-2bdd-4478-ac8d-aaca5e50d8fb?_state=qGKuAaf5pyaMExdf0syoztJ6dcejoUudcjJTXcVdQ5t7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6ImFhNzFjYjhjLTJiZGQtNDQ3OC1hYzhkLWFhY2E1ZTUwZDhmYiIsIk9mZnNldCI6MzQ2MjA4NDAsIlN0YXJ0ZWRBdCI6IjIwMTktMTEtMDFUMDE6MDI6MTZaIn0%3D&digest=sha256%3A7a2a5384bbd0cccedfc271914ffe2e36be0e39b62992f1a7adac27a2daa881d0
2019/11/01 01:03:14 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/09321ee0-beb3-472a-acc6-80bb2a472f20?_state=Y3XQTAhF1ZYdOuGrG2cdX5x96SKnMvGqSHDsv_bOJGx7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjA5MzIxZWUwLWJlYjMtNDcyYS1hY2M2LTgwYmIyYTQ3MmYyMCIsIk9mZnNldCI6MzQ2MjA4NDQsIlN0YXJ0ZWRBdCI6IjIwMTktMTEtMDFUMDE6MDI6MTZaIn0%3D&digest=sha256%3A26e91f006848acd6de48f650c3ca8eec820cd5c128c7b18a3334168ba065d423
2019/11/01 01:04:43 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/4854735d-a5e6-4659-838b-065e4db48ac1?_state=cyvVODxz874orcBr8R-o-1G3HUYpWYmf4RK7HQhvl_97Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjQ4NTQ3MzVkLWE1ZTYtNDY1OS04MzhiLTA2NWU0ZGI0OGFjMSIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MjMyMzc2ODJaIn0%3D
2019/11/01 01:04:43 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/4b87609e-c529-4c88-b20a-72ee53c4fb6e?_state=OqwwjIlMbQkrAP17xyKHLtqXRBxWcXI9RJtn95USNPt7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjRiODc2MDllLWM1MjktNGM4OC1iMjBhLTcyZWU1M2M0ZmI2ZSIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MTgyOTkyNzVaIn0%3D
2019/11/01 01:04:43 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/14eac0cc-fcaa-4d2d-a3a4-01b300f5fc4d?_state=vhHgKjjBDjhV8ss16XHn4oXJ22zQSnrCuQdVr_CJ-a17Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjE0ZWFjMGNjLWZjYWEtNGQyZC1hM2E0LTAxYjMwMGY1ZmM0ZCIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MTQ3NTU1M1oifQ%3D%3D
2019/11/01 01:08:26 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/4854735d-a5e6-4659-838b-065e4db48ac1?_state=XSMFtlp520H5XBVUJtasCJGggAbrHkznmaVYRAsH4397Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjQ4NTQ3MzVkLWE1ZTYtNDY1OS04MzhiLTA2NWU0ZGI0OGFjMSIsIk9mZnNldCI6MjE5OTYxMDgsIlN0YXJ0ZWRBdCI6IjIwMTktMTEtMDFUMDE6MDI6MTZaIn0%3D&digest=sha256%3Aff1ee406b3be50c26a03f45ac4f3b44514afe28efb622aaea1ed5fda587d7e72
2019/11/01 01:08:26 [DEBUG] GET https://auth.docker.io/token?scope=repository%3Aconcourse%2Fdev%3Apush%2Cpull&service=registry.docker.io
2019/11/01 01:08:26 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/649b3244-0503-4365-ac6e-7b305a5471c6?_state=qWmL7ilWOAupEf7RWcCrpjRWrg_9MgeBJZGobgdKiYB7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjY0OWIzMjQ0LTA1MDMtNDM2NS1hYzZlLTdiMzA1YTU0NzFjNiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MzE3MzI4MTRaIn0%3D
2019/11/01 01:08:26 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/4854735d-a5e6-4659-838b-065e4db48ac1?_state=XSMFtlp520H5XBVUJtasCJGggAbrHkznmaVYRAsH4397Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjQ4NTQ3MzVkLWE1ZTYtNDY1OS04MzhiLTA2NWU0ZGI0OGFjMSIsIk9mZnNldCI6MjE5OTYxMDgsIlN0YXJ0ZWRBdCI6IjIwMTktMTEtMDFUMDE6MDI6MTZaIn0%3D&digest=sha256%3Aff1ee406b3be50c26a03f45ac4f3b44514afe28efb622aaea1ed5fda587d7e72
2019/11/01 01:08:26 [DEBUG] GET https://auth.docker.io/token?scope=repository%3Aconcourse%2Fdev%3Apush%2Cpull&service=registry.docker.io
2019/11/01 01:08:28 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/4b87609e-c529-4c88-b20a-72ee53c4fb6e?_state=hTuVWgKJesNWqL-TzlbZuWXf45EK7WK1qwDQGQUH3Yl7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjRiODc2MDllLWM1MjktNGM4OC1iMjBhLTcyZWU1M2M0ZmI2ZSIsIk9mZnNldCI6MjE4ODk2NTQ4LCJTdGFydGVkQXQiOiIyMDE5LTExLTAxVDAxOjAyOjE2WiJ9&digest=sha256%3Aa9c9f2d9c4ee6ad756070912ab2143311157b1d4dc5a8d7305a7b38a4efec4a5
2019/11/01 01:08:41 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/14eac0cc-fcaa-4d2d-a3a4-01b300f5fc4d?_state=1J4dVtvuv5oI3srBDuAEMZ8u3t5qKq8o8RsFhGn87a57Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjE0ZWFjMGNjLWZjYWEtNGQyZC1hM2E0LTAxYjMwMGY1ZmM0ZCIsIk9mZnNldCI6NTA0MDY1NTE3LCJTdGFydGVkQXQiOiIyMDE5LTExLTAxVDAxOjAyOjE2WiJ9&digest=sha256%3Ae2f8d62ebfe98a4ca8998a2073394f0c7487129deb8a033ac6c6232390cde2f8
2019/11/01 01:13:10 [DEBUG] PATCH https://index.docker.io/v2/concourse/dev/blobs/uploads/649b3244-0503-4365-ac6e-7b305a5471c6?_state=qWmL7ilWOAupEf7RWcCrpjRWrg_9MgeBJZGobgdKiYB7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjY0OWIzMjQ0LTA1MDMtNDM2NS1hYzZlLTdiMzA1YTU0NzFjNiIsIk9mZnNldCI6MCwiU3RhcnRlZEF0IjoiMjAxOS0xMS0wMVQwMTowMjoxNi43MzE3MzI4MTRaIn0%3D
2019/11/01 01:13:36 [DEBUG] PUT https://index.docker.io/v2/concourse/dev/blobs/uploads/649b3244-0503-4365-ac6e-7b305a5471c6?_state=XpZzqrsY4ZpvgMUsUjjuXhQ2-49ZrIjkecG8kljFEyx7Ik5hbWUiOiJjb25jb3Vyc2UvZGV2IiwiVVVJRCI6IjY0OWIzMjQ0LTA1MDMtNDM2NS1hYzZlLTdiMzA1YTU0NzFjNiIsIk9mZnNldCI6NTA4MzI4ODg4LCJTdGFydGVkQXQiOiIyMDE5LTExLTAxVDAxOjAyOjE2WiJ9&digest=sha256%3Af72ac68b1cced6960902bdb52d972fac2287d7afc7384e5f37224cd12d1bca11
ERRO[0687] failed to upload image: DIGEST_INVALID: provided digest did not match uploaded content; map[Digest:sha256:f72ac68b1cced6960902bdb52d972fac2287d7afc7384e5f37224cd12d1bca11 Reason:map[]] 

Steps to reproduce

  • Setup the pipeline
jobs:
- name: build-alpine
  plan:
  - get: 2m
    trigger: true
  - get: alpine-edge
    params:
      format: oci
    trigger: true
  - config:
      container_limits: {}
      image_resource:
        source:
          repository: busybox
        type: docker-image
      outputs:
      - name: my-docker
      platform: linux
      run:
        args:
        - -c
        - |
          #!/bin/bash

          echo "FROM alpine:edge AS foo" > my-docker/Dockerfile
          echo "RUN dd if=/dev/urandom of=file.txt bs=1048576 count=100" >> my-docker/Dockerfile
          echo "FROM foo" >> my-docker/Dockerfile
        path: sh
    task: getdockerfile
  - config:
      container_limits: {}
      image_resource:
        source:
          repository: vito/oci-build-task
        type: registry-image
      inputs:
      - name: my-docker
        path: .
      outputs:
      - name: image
      platform: linux
      run:
        path: build
    privileged: true
    task: build
  - params:
      image: image/image.tar
    put: testimg
resource_types:
- name: registry-image
  privileged: true
  source:
    repository: concourse/registry-image-resource
    tag: 0.8.1
  type: registry-image
resources:
- name: 2m
  source:
    interval: 2m
  type: time
- icon: docker
  name: alpine-edge
  source:
    debug: true
    repository: alpine
    tag: edge
  type: registry-image
- icon: docker
  name: testimg
  source:
    debug: true
    password: ((REPLACE_ME))
    repository: ((ALSO_REPLACE_ME))
    username: ((REPLACE_ME))
  type: registry-image

We observed a failure rate of ~2-3% when pushing 2 layers. We saw a higher failure rate when pushing more layers (eg. dev-image build in Concourse)

Feature request: Support content trust while image pushing?

What challenge are you facing?

There are requests from users to add content trust(similar function like DOCKER_CONTENT_TRUST and DOCKER_CONTENT_TRUST_SERVER) in registry-image-resource. So they could sign image with their Notary server in concourse pipeline.

What would make this better?

Add content trust feature at resource level or library level. I noticed registry-resource is using github.com/google/go-containerregistry and it doesn't support content trust feature right now. I have created google/go-containerregistry#461, not sure if this feature request will be accepted.

Are you interested in implementing this yourself?

Yes, but I should wait for google/go-containerregistry#461.

Basic auth support

Right now there's no way to configure auth, which means this resource is only useful for fetching public images.

There's all sorts of auth we'd need to support various registries. Let's start with the simplest one: basic auth.

Dependabot can't parse your go.mod

Dependabot couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: github.com/simonshyu/[email protected] requires
	github.com/jinzhu/[email protected] requires
	github.com/denisenkom/[email protected] requires
	gopkg.in/[email protected]: invalid version: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /opt/go/gopath/pkg/mod/cache/vcs/9241c28341fcedca6a799ab7a465dd6924dc5d94044cbfabb75778817250adfc: exit status 128:
	fatal: The remote end hung up unexpectedly

View the update logs.

Custom tag | Question

Hello,

I wanted to ask how to go about a particular use-case which is tagging and image with a custom tag other than latest maybe even generate a unique build number? After doing that, then fetching that new tag, and passing it to another resource's put like linkyard's helm resource.

Bug? Keeps producing new versions on every check

I came across a strange situation today with the following resource definition:

- name: docker-hub-registrator-image
  type: registry-image
  source:
    repository: gliderlabs/registrator
    tag: v7

Every time concourse runs a new check it's producing a new sha even though that particular tag hasn't been updated in 3 years.

Docker seems to handle the image just fine:

λ docker pull gliderlabs/registrator:v7     
v7: Pulling from gliderlabs/registrator
c87f684ee1c2: Pull complete 
30ebee0d3a4a: Pull complete 
999a7dd2ee1f: Pull complete 
Digest: sha256:0caaf84db8d645993964a0225c0485e7853135bf368393ce5a3a2c854379d476
Status: Downloaded newer image for gliderlabs/registrator:v7

then if I run it again

λ docker pull gliderlabs/registrator:v7
v7: Pulling from gliderlabs/registrator
c87f684ee1c2: Already exists 
30ebee0d3a4a: Already exists 
999a7dd2ee1f: Already exists 
Digest: sha256:0caaf84db8d645993964a0225c0485e7853135bf368393ce5a3a2c854379d476
Status: Image is up to date for gliderlabs/registrator:v7

However after running several checks with fly on the resource in question I'm getting this:
checks

Not sure what is going on.... old manifest? When I try to get the image in the job this prints:

fetching gliderlabs/registrator@sha256:4c298fb92a0b22ee00de6b0b7a2155cc6d1a63e84fb1cd34e874169925f7fbae
	
ERRO[0001] failed to write OCI image: MANIFEST_UNKNOWN: "manifest unknown" 

Doesn't happen for any other image I've used AFAICT

This is on v4.2.1

Feature Request: handle images with foreign layers

As a result of this investigation, we've discovered that we are unable to use this concourse resource with Microsoft base images as they contain foreign layers. We are able to get this base image using the docker-image concourse resource.

How we configured the resource:

- name: windowsservercore
  type: registry-image
  source:
    repository: mcr.microsoft.com/windows/servercore
    tag: ltsc2019-amd64
    debug: true

The error in ci on get:

fetching mcr.microsoft.com/windows/servercore@sha256:b26b4b226ea91f4ee269b4d8608febaa2b5bf2869729cd30d97e8ccbe1f65891
DEBU[0000] extracting layer 1 of 2                      
ERRO[0000] failed to extract image: BLOB_UNKNOWN: "blob unknown to registry" 

We can successfully docker pull this image:

bosh_6ea35edd9a6a422@VM-4DB8B27E-B39 C:\Users\bosh_6ea35edd9a6a422>docker pull mcr.mic
rosoft.com/windows/servercore@sha256:b26b4b226ea91f4ee269b4d8608febaa2b5bf2869729cd30d
97e8ccbe1f65891                                                                       
sha256:b26b4b226ea91f4ee269b4d8608febaa2b5bf2869729cd30d97e8ccbe1f65891: Pulling from 
windows/servercore                                                                    
65014b3c3121: Already exists                                                          
0e787b79aad1: Pull complete                                                           
Digest: sha256:b26b4b226ea91f4ee269b4d8608febaa2b5bf2869729cd30d97e8ccbe1f65891       
Status: Downloaded newer image for mcr.microsoft.com/windows/servercore@sha256:b26b4b2
26ea91f4ee269b4d8608febaa2b5bf2869729cd30d97e8ccbe1f65891       

The foreign layers:

$ docker manifest inspect mcr.microsoft.com/windows/servercore:ltsc2019-amd64                                                                                                                                                
{                                                                                                                                                                                                                        
        "schemaVersion": 2,                                                                                                                                                                                                  
        "mediaType": "application/vnd.docker.distribution.manifest.v2+json",                                                                                                                                                 
        "config": {                                                                                                                                                                                                          
                "mediaType": "application/vnd.docker.container.image.v1+json",                                                                                                                                               
                "size": 786,                                                                                                                                                                                                 
                "digest": "sha256:954d1507112f98f8b2ec3e2f8d65546aead2c1e9aea1793feab4b4f8b14fc957"                                                                                                                          
        },
        "layers": [
                {
                        "mediaType": "application/vnd.docker.image.rootfs.foreign.diff.tar.gzip",
                        "size": 1534685324,
                        "digest": "sha256:65014b3c312172f10bd6701a063f9b5aaf9a916c2d2cb843d406a6f77ded3f8d",
                        "urls": [
                                "https://go.microsoft.com/fwlink/?linkid=2041275"
                        ]
                },
                {
                        "mediaType": "application/vnd.docker.image.rootfs.foreign.diff.tar.gzip",
                        "size": 439177903,
                        "digest": "sha256:0e787b79aad1a2bfd8fbef887083298fcd314650de9e7ca884cdf0897e874b63",
                        "urls": [
                                "https://go.microsoft.com/fwlink/?linkid=2086938"
                        ]
                }
        ]
}

When we modify the registry-image resource to print out the url for the foreign layer in the go-containerregistry, we see that the url doesn't consider the urls field in the image's docker manifest:

https://mcr.microsoft.com/v2/windows/servercore/blobs/sha256:65014b3c312172f10bd6701a063f9b5aaf9a916c2d2cb843d406a6f77ded3f8d

Repro:

$ echo '{  "source": { "repository": "mcr.microsoft.com/windows/servercore", "tag": "ltsc2019-amd64", 
"debug": true}, "version": { "digest":"sha256:b26b4b226ea91f4ee269b4d8608febaa2b5bf2869729cd30d97e8c
cbe1f65891"} }' | ./in /tmp

DEBU[0000] extracting layer 1 of 2 
ERRO[0000] failed to extract image: BLOB_UNKNOWN: "blob unknown to registry"  

Potential fixes?

  1. A short term fix would be to add a skip-unpack-image param to this resource so that we can use it with the Microsoft base image that contains foreign layers. This parameter might be niche in that we want to use this resource to detect updates to an image but we do not need to unpack this image in the following job.
  2. We believe the error we are seeing in CI with this resource is due to missing support for foreign layers in the go-containerregistry. If that is correct, then we can work on adding support to it and the bumping that dependency here so that this resource can support foreign layers. (Related issue: google/go-containerregistry#207)

cc @sophiewigmore @benmoss

invalid memory address or nil pointer dereference

I am trying to setup a Concourse-CI pipeline that uses a put step to push a .tar image built on the previous step.

Unfortunately my put step fails with the following error.

I'm not sure whether the issue comes from this repo in cmd/out/main.go:90 +0x733 or if it comes from the library you're using

github.com/google/go-containerregistry/pkg/v1/tarball.(*image).loadTarDescriptorAndConfig(0xc000044440, 0x0, 0x0)
	/go/pkg/mod/github.com/google/[email protected]/pkg/v1/tarball/image.go:158 +0x151

Here's the full error:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x6912a1]

goroutine 1 [running]:
github.com/google/go-containerregistry/pkg/v1/tarball.(*image).loadTarDescriptorAndConfig(0xc000044440, 0x0, 0x0)
	/go/pkg/mod/github.com/google/[email protected]/pkg/v1/tarball/image.go:158 +0x151
github.com/google/go-containerregistry/pkg/v1/tarball.Image(0xc00000c600, 0x0, 0xc00000c600, 0x1, 0xc000016120, 0x22)
	/go/pkg/mod/github.com/google/[email protected]/pkg/v1/tarball/image.go:75 +0x62
github.com/google/go-containerregistry/pkg/v1/tarball.ImageFromPath(0xc000016120, 0x22, 0x0, 0xc000016120, 0x22, 0x0, 0x0)
	/go/pkg/mod/github.com/google/[email protected]/pkg/v1/tarball/image.go:66 +0x4d
main.main()
	/src/cmd/out/main.go:90 +0x733

Support Private Authentication using Files

Feature Request:

Support reading username / password etc. from file

This would allow me to use ECR with a separate concourse task which does an ecr:GetAuthorizationToken, decodes it, and writes it to a file.

This also means private authentication would be supported for numerous providers without needing to add support into the resource itself.

Discussion item: Too many requests to a Google Cloud Registry

Hi there,

Occasionally we see issues with the docker image resource hitting our GCR too much causing us to get 429: Too many requests responses while the resource is being checked, causing some 🍊s in our pipelines. I'm really not sure how to handle this (maybe using multiple registries?) but thought it would be worthwhile to bring up as a discussion point for the reimagining of the registry resource.

Cheers, and thanks for the good work.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.