docker 1.9.1 pull on centos7 is failing when pulling from private V2 registry.
$ docker -v
Docker version 1.9.1, build 78ee77d/1.9.1
$ docker pull web-docker.bin-repo.hostname.com/web-dev:latest
Trying to pull repository web-docker.bin-repo.hostname.com/web-dev ...
failed
manifest invalid: manifest invalid
The same command works fine on osx with docker 1.10.3. Can anyone tell me why this isn't working and how to troubleshoot further?
update: here is the manifest it's trying to pull. It can pull v1 manifests, but fails on v2 manifests like the one below.
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/octet-stream",
"size": 7503,
"digest": "sha256:58672cb2c8c6d44c1271a5ca38e60a4ab29fb60050bc76995ce662c126509036"
},
"layers": [
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 32,
"digest": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 72038766,
"digest": "sha256:35d9d5d11536c0c6843ecd106dc710b5c54b8198aa28710e73dba2cbe555847f"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 19361671,
"digest": "sha256:f7de7971859186e93100b41fbba5513771737ba65f57c62404130646bd41b96b"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 108814795,
"digest": "sha256:0041a80e34f1271571619554f6833c06e0ef75d39f152f5fe44ba75bf7e25ae2"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 157895786,
"digest": "sha256:ec3cfa9c22f7e6497a0eacf85c86bf8eb5fdec35d096298f9efb43827a393472"
}
]
}
For this issue what I observed is that whenever you push the same image artifact for the second time with same SHA, we will observe this issue.
To Solve this, I would recommend giving permission to override/delete the mainifest file in artifactory.
This will definitely solve this issue.
Problem resolved itself after upgrading to a new version of Docker. (Docker version 1.10.3, build 20f81dd) The standard yum repo lags behind in versions, so add the docker repo and get the latest version of docker:
sudo yum update
Add the yum repo:
sudo tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF
Install the docker-engine:
sudo yum install docker-engine
Start the daemon:
sudo service docker start
Add the insecure-registry flag (if the priv registry does not have a cert)
sudo vi /usr/lib/systemd/system/docker.service
ExecStart=/usr/bin/docker daemon --insecure-registry web-docker.bin-repo.hostname.com -H fd://
Reload the daemon:
sudo systemctl daemon-reload
Pull from the private registry:
sudo docker pull web-docker.bin-repo.hostname.com/web-dev:latest
latest: Pulling from web-dev
a3ed95caeb02: Pull complete
Related
I have a CI pipeline on Github Actions that builds and pushes a docker image, then, I have a seperate repository that has an action that I trigget from the command line, that takes as an arg a docker image which then applies it to a Kustomize template
Here is an example of that CI
docker build . -t ghcr.io/myOrg/myApp:${{ commitSha }}
docker push ghcr.io/myOrg/myRepo:${{ commitSha }}
gh workflow run update_image.yml -R myOrg/myInfraRepo -f image=ghcr.io/myOrg/myRepo#$(docker images --no-trunc --quiet ghcr.io/myOrg/myApp:${{ commitSha }})
When testing, the whole flow works, and triggers the workflow with an image & digest, however, the digest doesn't seem to be correct
When I check the container via github packages, I can see the following manifest
{
"digest": "sha256:9e32f9292cbe63d27374fd467ad5e530112cbfddf17c250ca90e087bdfcd436e",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 1998,
"config": {
"digest": "sha256:6f7e582643c22f4e41021be851bb0394c0e326e8fe06c7d3e890316d1a0234e9",
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 8755
},
"layers": [
...
Both digests are different, and the output of docker images --no-trunc --quiet was the digest under config.digest, not the top level digest. I don't understand why they're different, is this a registry digest?
If so, how can I get that digest via the command line?
Well, I managed to resolve this. I was using the wrong command to get the digest.
docker images --no-trunc --quiet ghcr.io/myOrg/myApp:${{ commitSha }}
It works, but that's only the local digest. I replaced it with this from here
docker inspect --format='{{index .RepoDigests 0}}' $IMAGE
which returns the full name and remote digest. So now my final command looks like this:
gh workflow run update_image.yml -R myOrg/myInfraRepo -f image=$(docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/myOrg/myApp:${{ commitSha }})
I have used Docker-compose a lot recently, but this time I found a container I really want to use but the docker hub’s image is not compatible with my arm/v6 raspberry pi.
Using it anyway results in
standard_init_linux.go:219: exec user process caused: exec format error
Strangely, copying the Dockerfile and building it with
build:
context: ./ttrss-docker/src/app
results in the app working well. But for some reason, I can’t use the dockerhub’s image.
In case it matters, the Dockerfile is this, and the Docker Hub image is this.
FROM alpine:3.12
EXPOSE 9000/tcp
RUN apk add --no-cache dcron php7 php7-fpm \
php7-pdo php7-gd php7-pgsql php7-pdo_pgsql php7-mbstring \
php7-intl php7-xml php7-curl php7-session \
php7-dom php7-fileinfo php7-json \
php7-pcntl php7-posix php7-zip php7-openssl \
git postgresql-client sudo
ADD startup.sh /
ADD updater.sh /
ADD index.php /
ADD dcron.sh /
ADD backup.sh /etc/periodic/weekly/backup
RUN sed -i.bak 's/^listen = 127.0.0.1:9000/listen = 9000/' /etc/php7/php-fpm.d/www.conf
RUN sed -i.bak 's/\(memory_limit =\) 128M/\1 256M/' /etc/php7/php.ini
RUN mkdir -p /var/www
CMD /startup.sh
Question: if I don’t use the Docker hubs image, can Watchtower update my container ?
If not, does anyone know what’s happening and how I can achieve a container that updates via Watchtower ?
Many thanks :)
The image you are pulling has only been built for a single architecture: amd64. The resulting binaries and libraries are not usable on other platforms like ARM used by the Raspberry Pi. Below are the debugging steps to verify this.
The manifest is application/vnd.docker.distribution.manifest.v2+json:
$ regctl image manifest --list cthulhoo/ttrss-fpm-pgsql-static
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 4257,
"digest": "sha256:916ae5126809992b922c5db0f41e62a40be245703685e19f51797db95f312e81"
},
...
Checking the architecture of that image:
$ regctl image inspect cthulhoo/ttrss-fpm-pgsql-static --format '{{.Architecture}}'
amd64
This would need to be fixed by the image creator to build an image for ARM platforms, which you see with the Alpine base image.
$ regctl image manifest --list alpine:3.12
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 528,
"digest": "sha256:074d3636ebda6dd446d0d00304c4454f468237fdacf08fb0eeac90bdbfa1bac7",
"platform": {
"architecture": "amd64",
"os": "linux"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 528,
"digest": "sha256:096ebf69d65b5dcb3756fcfb053e6031a3935542f20cd7a8b7c59e1b3cb71558",
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v6"
}
},
{
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"size": 528,
"digest": "sha256:299294be8699c1b323c137f972fd0aa5eaa4b95489c213091dcf46ef39b6c810",
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v7"
}
},
...
Building multi-platform images is often done with buildx. The regctl command used above is part of my regclient project.
I'm currently trying to build a Docker image using GitHub Actions (CI). I can successfully build it on my machine and multiple other x86_64 architectures which I believe GitHub Actions also runs, but when building, I experience the following issue:
standard_init_linux.go:219: exec user process caused: exec format error
The command '/bin/sh -c apt-get update && apt-get install -y build-essential psmisc ifupdown omxplayer x11-xserver-utils xserver-xorg libraspberrypi0 libraspberrypi-dev raspberrypi-kernel-headers cec-utils libpng12-dev git-core wget --no-install-recommends && apt-get clean && rm -rf /var/lib/apt/*' returned a non-zero code: 1
I've searched multiple other threads here, but I wasn't able to find anything useful and I'm not quite sure what else to try. Any help or suggestions would be much appreciated.
Relevant Files:
This is the full build log
This is the Dockerfile
This is the CI file
This is the full repository
Your base image is invalid for amd64:
$ docker image inspect balenalib/raspberry-pi-debian-node:latest-jessie
...
"Architecture": "amd64",
...
$ docker run -it --rm balenalib/raspberry-pi-debian-node:latest-jessie /bin/bash
...
root#2eb37d8359ed:/# dpkg --print-architecture
armhf
That base image won't run on systems without qemu's binfmt_misc configured to run binaries for other platforms.
It's actually not a multi-platform base image at all, and instead is only designed to run on systems with qemu setup (note the media type is a manifest and not a manifest list):
$ regctl image manifest --list balenalib/raspberry-pi-debian-node:latest-jessie
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 11726,
"digest": "sha256:5ec0839ecb046f260ad72751d0c4b08c7a085b147a519619e5a54876643a3231"
},
"layers": [
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 40222636,
"digest": "sha256:d84b7435af12678c551b7489227b74c994981386b5bc4875ec512e11f28249c5"
},
And the image configuration has more pointers to qemu:
$ regctl image inspect balenalib/raspberry-pi-debian-node:latest-jessie
{
"created": "2019-05-02T22:50:58.241895826Z",
"architecture": "amd64",
"os": "linux",
"config": {
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"LC_ALL=C.UTF-8",
"DEBIAN_FRONTEND=noninteractive",
"UDEV=off",
"QEMU_CPU=arm1176",
"NODE_VERSION=11.14.0",
"YARN_VERSION=1.12.3"
],
This won't work on hosts without qemu's binfmt-misc setup. For building within a github action, you can use the setup qemu action:
- name: Set up QEMU
id: qemu
uses: docker/setup-qemu-action#v1
with:
image: tonistiigi/binfmt:latest
platforms: all
I'm trying to figure out the correct URL to use for this. As an example, let's say I want to get the manifest for the alpine:3.9 tag. I've tried https://hub.docker.com/v2/repositories/library/alpine/manifests/3.9 but that yields a 404 error.
I've found that Docker Hub's registry implementation doesn't really match their documentation. For example, https://docs.docker.com/registry/spec/api/#tags indicates that the URL for getting the list of tags is v2/<name>/tags/list, but when you query Docker Hub, you actually need to leave off the "list" part of the URL: https://hub.docker.com/v2/repositories/library/alpine/tags/. So that makes me question everything about their documentation now when it comes to querying the Docker Hub registry.
TL;DR
The hub.docker.com REST API is not the docker registry API, rather it's a custom API mainly used for the Dockerhub frontend, but could occasionally be useful for other things.
The docker registry API for dockerhub is hosted on registry-1.docker.io, with an alias on registry.docker.io. Even more confusing is that both API's start with the root path /v2.
Full answer
Here are some cURL commands that exercise some of the V2 endpoints. I'm super confused about what the hub.docker.com endpoints are for (https://hub.docker.com/v2/users/login, https://hub.docker.com/v2/repositories/library/, etc.) but I think the /v2/ there is a total red herring and unrelated to the registry V2 API? This article using hub.docker.com can get you tags, but not the manifests.
DOCKERHUB_USERNAME=$(jq -r '.username' < ~/.secrets/docker.json)
DOCKERHUB_PASSWORD=$(jq -r '.password' < ~/.secrets/docker.json)
TARGET_NS_REPO=library/debian
# yes, you need a new token for each repository, maybe you can have multiple scopes though?
PARAMS="service=registry.docker.io&scope=repository:$TARGET_NS_REPO:pull"
TOKEN=$(curl --user "$DOCKERHUB_USERNAME:$DOCKERHUB_PASSWORD" \
"https://auth.docker.io/token?$PARAMS" \
| jq -r '.token'
)
curl "https://registry-1.docker.io/v2/$TARGET_NS_REPO/tags/list" \
-H "Authorization:Bearer $TOKEN" \
| jq '.tags[:10]'
TAG="10-slim"
curl "https://registry-1.docker.io/v2/$TARGET_NS_REPO/manifests/$TAG" \
-H "Authorization:Bearer $TOKEN" \
| jq '.fsLayers'
Output:
[
"10-slim",
"10.0-slim",
"10.0",
"10",
"6.0.10",
"6.0.8",
"6.0.9",
"6.0",
"6",
"7-slim"
]
[
{
"blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
},
{
"blobSum": "sha256:1ab2bdfe97783562315f98f94c0769b1897a05f7b0395ca1520ebee08666703b"
}
]
Reverse engineer it
I basically had to reverse engineer this with mitmproxy. If you want to know how anything else works:
Install/run mitmproxy. Check it's working via:
curl -x localhost:8080 http://mitm.it/cert/pem # should print out a cert
Get/install it's certificate (to MITM yourself):
# Ubuntu 18.04, other distros may vary
MITM_CERT_PATH=/usr/local/share/ca-certificates/mitmproxy.crt
sudo cp ~/.mitmproxy/mitmproxy-ca-cert.cer "$MITM_CERT_PATH"
sudo chown root:root "$MITM_CERT_PATH"
sudo chmod 644 "$MITM_CERT_PATH"
sudo update-ca-certificates
# Verify MITM root cert accepted
curl -x localhost:8080 https://sha256.badssl.com/
# Troubleshooting
# - see if installed (https://unix.stackexchange.com/a/97252/42385)
awk -v cmd='openssl x509 -noout -subject' \
'/BEGIN/{close(cmd)};{print | cmd}' \
< /etc/ssl/certs/ca-certificates.crt \
| grep -i mitmproxy
# - print the cert used (OpenSSL 1.1.0+)
openssl s_client -proxy localhost:8080 -showcerts -connect sha256.badssl.com:443 </dev/null
Uninstall the cert later if desired
sudo rm /usr/local/share/ca-certificates/mitmproxy.crt
sudo update-ca-certificates
Check not in the list
awk -v cmd='openssl x509 -noout -subject' \
'/BEGIN/{close(cmd)};{print | cmd}' \
< /etc/ssl/certs/ca-certificates.crt \
| grep -i mitmproxy
# Double-check MITM root cert rejected
curl -x localhost:8080 https://sha256.badssl.com/
Run dockerd (stop the service if it already is running) with HTTPS_PROXY set
sudo HTTPS_PROXY=http://localhost:8080/ dockerd # bash
# sudo env HTTPS_PROXY=http://localhost:8080/ dockerd # fish
Tell the Docker daemon to do something, e.g. docker pull alpine. In mitmproxy you'd see something like
Flows
GET https://registry-1.docker.io/v2/
← 401 application/json 87b 213ms
GET https://auth.docker.io/token?account=youraccount&scope=repository%3Alibrary%2Fal
pine%3Apull&service=registry.docker.io
← 200 application/json 4.18k 245ms
>> GET https://registry-1.docker.io/v2/library/alpine/manifests/latest
← 200 application/vnd.docker.distribution.manifest.list.v2+json 1.6k 294ms
GET https://registry-1.docker.io/v2/library/alpine/manifests/sha256:57334c50959f26ce
1ee025d08f136c2292c128f84e7b229d1b0da5dac89e9866
← 200 application/vnd.docker.distribution.manifest.v2+json 528b 326ms
GET https://registry-1.docker.io/v2/library/alpine/blobs/sha256:b7b28af77ffec6054d13
378df4fdf02725830086c7444d9c278af25312aa39b9
← 307 text/html 242b 288ms
GET https://registry-1.docker.io/v2/library/alpine/blobs/sha256:0503825856099e6adb39
c8297af09547f69684b7016b7f3680ed801aa310baaa
← 307 text/html 242b 322ms
GET https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sh
a256/b7/b7b28af77ffec6054d13378df4fdf02725830086c7444d9c278af25312aa39b9/data?…
← 200 application/octet-stream 1.48k 191ms
GET https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sh
a256/05/0503825856099e6adb39c8297af09547f69684b7016b7f3680ed801aa310baaa/data?…
← 200 application/octet-stream 2.66m 207ms
⇩ [27/32] [*:8080]
Inspect the requests. Picking the ...manifests/latest request to look at:
Flow Details
2019-08-20 13:43:44 GET https://registry-1.docker.io/v2/library/alpine/manifests/latest
← 200 OK application/vnd.docker.distribution.manifest.list.v2+json 1.6k 294ms
[[ Request ]] Response Detail
Host: registry-1.docker.io
User-Agent: docker/19.03.1 go/go1.12.5 git-commit/74b1e89 kernel/4.15.0-55-generic
os/linux arch/amd64 UpstreamClient(Docker-Client/19.03.1\\(linux\\))
Accept: application/vnd.docker.distribution.manifest.v2+json
Accept: application/vnd.docker.distribution.manifest.list.v2+json
Accept: application/vnd.oci.image.index.v1+json
Accept: application/vnd.docker.distribution.manifest.v1+prettyjws
Accept: application/json
Accept: application/vnd.oci.image.manifest.v1+json
Authorization: Bearer eyJhbGci...(a big JWT returned by the auth.docker.io req.)
Accept-Encoding: gzip
Connection: close
The registry API is defined by OCI in the distribution-spec.
The complicated part of this is getting auth and headers setup. For an anonymous manifest pull from Docker Hub, that looks like:
#!/bin/sh
ref="${1:-library/ubuntu:latest}"
sha="${ref#*#}"
if [ "$sha" = "$ref" ]; then
sha=""
fi
wosha="${ref%%#*}"
repo="${wosha%:*}"
tag="${wosha##*:}"
if [ "$tag" = "$wosha" ]; then
tag="latest"
fi
api="application/vnd.docker.distribution.manifest.v2+json"
apil="application/vnd.docker.distribution.manifest.list.v2+json"
token=$(curl -s "https://auth.docker.io/token?service=registry.docker.io&scope=repository:${repo}:pull" \
| jq -r '.token')
curl -H "Accept: ${api}" -H "Accept: ${apil}" \
-H "Authorization: Bearer $token" \
-s "https://registry-1.docker.io/v2/${repo}/manifests/${sha:-$tag}" | jq .
Note that official images are all within the library repository, e.g. library/alpine. So this script can be called like the following to pull the alpine:3.9 manifest:
$ ./hub-manifest.sh library/alpine:3.9
{
"manifests": [
{
"digest": "sha256:65b3a80ebe7471beecbc090c5b2cdd0aafeaefa0715f8f12e40dc918a3a70e32",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "amd64",
"os": "linux"
},
"size": 528
},
{
"digest": "sha256:7a3d88cbc7e2d6c0213deaf2d006933c9f5905c4eb7846b703a66fc6504000b7",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v6"
},
"size": 528
},
{
"digest": "sha256:cfd8b55d209956f63c8fcc931f5c6874984e5e0ffdcb8f45ba9085f190385d73",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v7"
},
"size": 528
},
{
"digest": "sha256:f920ccc826134587fffcf1ddc6b2a554947e0f1a5ae5264bbf3435da5b2e8e61",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "arm64",
"os": "linux",
"variant": "v8"
},
"size": 528
},
{
"digest": "sha256:2a41778b4675b9a91bd2ea3a55a2cfdaf4436aa85a476ee8b48993cdd6989a18",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "386",
"os": "linux"
},
"size": 528
},
{
"digest": "sha256:6ee74256ce03a4280792ddb67cfefee9119349a63e86ca1c4c6407b08fec008e",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "ppc64le",
"os": "linux"
},
"size": 528
},
{
"digest": "sha256:7e474fa79d2fc816da8fb626ac37d0344c83cfdffad3d55158123d0cc2683b98",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "s390x",
"os": "linux"
},
"size": 528
}
],
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"schemaVersion": 2
}
From there you can see it's outputting a manifest list, and you could pull individual manifests from there:
$ hub-manifest.sh library/alpine#sha256:65b3a80ebe7471beecbc090c5b2cdd0aafeaefa0715f8f12e40dc918a3a70e32
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 1509,
"digest": "sha256:78a2ce922f8665f5a227dc5cd9fda87221acba8a7a952b9665f99bc771a29963"
},
"layers": [
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 2773413,
"digest": "sha256:31603596830fc7e56753139f9c2c6bd3759e48a850659506ebfb885d1cf3aef5"
}
]
}
Shell scripts only get me so far with this, so I've been writing regclient with regctl. There's also crane from Google and skopeo from RedHat that do similar things:
$ regctl manifest get alpine:3.9 --format '{{jsonPretty .}}'
{
"manifests": [
{
"digest": "sha256:65b3a80ebe7471beecbc090c5b2cdd0aafeaefa0715f8f12e40dc918a3a70e32",
"mediaType": "application\/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "amd64",
"os": "linux"
},
"size": 528
},
...
$ regctl manifest get alpine:3.9 --format '{{jsonPretty .}}' --platform linux/amd64
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 1509,
"digest": "sha256:78a2ce922f8665f5a227dc5cd9fda87221acba8a7a952b9665f99bc771a29963"
},
"layers": [
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 2773413,
"digest": "sha256:31603596830fc7e56753139f9c2c6bd3759e48a850659506ebfb885d1cf3aef5"
}
]
}
The advantage of these other commands over curl is they handle different types of auth (basic and bearer), can use credential helpers, and they pass headers for a lot more media types, including the old v1 schema from Docker and the newer OCI schemas.
I was entirely unable to get Docker's Registry API working with DockerHub for manifests :-(
If you find a way, please let me know.
Unfortunately, DockerHub's UI does not include manifest details either.
If you have access to Google Container Registry (GCR), its implementation of Docker Registry API works. Also GCR's UI includes manifests and digests.
I summarized my experiences here:
https://medium.com/google-cloud/adventures-w-docker-manifests-78f255d662ff
I'm trying to build and provision a docker container, but when I run this it hangs when running the provisioning script.
I'm running on a OSX using:
Boot2Docker-cli version: v1.3.1
Packer v0.7.2
**docker version**
Client version: 1.3.1
Client API version: 1.15
Server version: 1.3.1
Server API version: 1.15
Running this:
packer build ./packer-build-templates/docker/testsite/testsite.json
packer-build-templates/docker/testsite/testsite.json
{
"builders": [
{
"type": "docker",
"image": "centos:centos6",
"commit": "true"
}
],
"provisioners": [
{
"type": "shell",
"script": "script.sh"
}
],
"post-processors": [
[
{
"type": "docker-tag",
"repository": "test/stuff",
"tag": "latest"
}
]
]
}
script.sh
#!/bin/sh -x
echo foo
Output:
==> docker: Creating a temporary directory for sharing data...
==> docker: Pulling Docker image: centos:centos6
docker: centos:centos6: The image you are pulling has been verified
docker: Status: Image is up to date for centos:centos6
==> docker: Starting docker container...
docker: Run command: docker run -v /var/folders/z2/nm_4_yyx2ss9z8wn4h0bfd1jw_pj8j/T/packer-docker208208953:/packer-files -d -i -t centos:centos6 /bin/bash
docker: Container ID: 3ab21c7c21bc4af84e0f0c7bdbac91ee600d1ea0a469bfa51a959faba73fa7e4
==> docker: Provisioning with shell script: script.sh
This is as far as it gets. Then it just sits there. Any idea what's going on here?