I'm trying to use BuildKit with Docker on Google Cloud Build so that I can eventually use the --secret flag. I'm using Build Enhancements for Docker as a reference.
It works on my laptop when I use the following command: DOCKER_BUILDKIT=1 docker build -t hello-world:latest .
When I run it on Cloud Build, I get the error "docker.io/docker/dockerfile:experimental not found".
Any idea how to get this to work on Cloud Build?
Here is the setup (note: I'm not using the --secret flag yet):
Dockerfile:
#syntax=docker/dockerfile:experimental
FROM node:10.15.3-alpine
RUN mkdir -p /usr/src/app && \
apk add --no-cache tini
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install --production
COPY . .
RUN chown -R node:node .
USER node
EXPOSE 8080
ENTRYPOINT ["/sbin/tini", "--"]
CMD [ "node", "index.js" ]
cloudbuild.yaml:
steps:
- id: 'Build'
name: 'gcr.io/cloud-builders/docker'
args: [
'build',
'-t', 'gcr.io/$PROJECT_ID/hello-world:latest',
'.'
]
env:
- "DOCKER_BUILDKIT=1"
Cloud Build Log:
starting build "xxxx"
FETCHSOURCE
Fetching storage object: gs://xxxxx
Copying gs://xxxxx...
/ [0 files][ 0.0 B/ 15.3 KiB]
/ [1 files][ 15.3 KiB/ 15.3 KiB]
Operation completed over 1 objects/15.3 KiB.
BUILD
Already have image (with digest): gcr.io/cloud-builders/docker
#2 [internal] load .dockerignore
#2 digest: sha256:3ce0de94c925587ad30afb764af9bef89edeb62eb891b99694aedb086ee53f50
#2 name: "[internal] load .dockerignore"
#2 started: 2019-07-24 03:21:49.153855989 +0000 UTC
#2 completed: 2019-07-24 03:21:49.195969197 +0000 UTC
#2 duration: 42.113208ms
#2 transferring context: 230B done
#1 [internal] load build definition from Dockerfile
#1 digest: sha256:82b0dcd17330313705522448d60a78d4565304d55c86f55b903b18877d612601
#1 name: "[internal] load build definition from Dockerfile"
#1 started: 2019-07-24 03:21:49.150042849 +0000 UTC
#1 completed: 2019-07-24 03:21:49.189628322 +0000 UTC
#1 duration: 39.585473ms
#1 transferring dockerfile: 445B done
#3 resolve image config for docker.io/docker/dockerfile:experimental
#3 digest: sha256:401713457b113a88eb75a6554117f00c1e53f1a15beec44e932157069ae9a9a3
#3 name: "resolve image config for docker.io/docker/dockerfile:experimental"
#3 started: 2019-07-24 03:21:49.210803849 +0000 UTC
#3 completed: 2019-07-24 03:21:49.361743084 +0000 UTC
#3 duration: 150.939235ms
#3 error: "docker.io/docker/dockerfile:experimental not found"
docker.io/docker/dockerfile:experimental not found
ERROR
ERROR: build step 0 "gcr.io/cloud-builders/docker" failed: exit status 1
Laptop Docker version:
Client: Docker Engine - Community
Version: 18.09.2
API version: 1.39
Go version: go1.10.8
Git commit: 6247962
Built: Sun Feb 10 04:12:39 2019
OS/Arch: darwin/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.2
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 6247962
Built: Sun Feb 10 04:13:06 2019
OS/Arch: linux/amd64
Experimental: false
Cloud Build Docker Version:
Step #0 - "Version": Client:
Step #0 - "Version": Version: 18.09.7
Step #0 - "Version": API version: 1.39
Step #0 - "Version": Go version: go1.10.8
Step #0 - "Version": Git commit: 2d0083d
Step #0 - "Version": Built: Thu Jun 27 17:56:17 2019
Step #0 - "Version": OS/Arch: linux/amd64
Step #0 - "Version": Experimental: false
Step #0 - "Version":
Step #0 - "Version": Server: Docker Engine - Community
Step #0 - "Version": Engine:
Step #0 - "Version": Version: 18.09.3
Step #0 - "Version": API version: 1.39 (minimum version 1.12)
Step #0 - "Version": Go version: go1.10.8
Step #0 - "Version": Git commit: 774a1f4
Step #0 - "Version": Built: Thu Feb 28 05:59:55 2019
Step #0 - "Version": OS/Arch: linux/amd64
Step #0 - "Version": Experimental: false
Update: I noticed that I was using #syntax=docker/dockerfile:experimental whereas the linked article has #syntax=docker/dockerfile:1.0-experimental. I get the same error when using 1.0-experimental.
There seems to be an issue when the "registry-mirrors" option is used in combination with buildkit, then the buildkit frontend images fail to fetch:
https://github.com/moby/moby/issues/39120
Pulling them before doing the build seems to resolve the issue:
- name: 'gcr.io/cloud-builders/docker'
args: ['pull', 'docker/dockerfile:experimental']
- name: 'gcr.io/cloud-builders/docker'
args: ['pull', 'docker/dockerfile:1.0-experimental']
I had a similar issue and managed to figure it out. It's not really possible to use docker buildkit with gcr.io/cloud-builders/docker, instead, you have to run a docker in docker daemon and run another docker build on the side with docker-compose.
Specifically, you'll need a docker-compose.yml that has:
docker (docker in docker daemon)
a docker build step that builds the image (with buildkit enabled)
a docker auth and push step that authorizes docker to push to gcr (you need to create creds.json w/ service role w/ gcs permission, see bottom for details)
In order to auth and push to gcr, one needs to do docker login with creds.json. See details: https://cloud.google.com/container-registry/docs/advanced-authentication
# deploy/app/docker-compose.yml
version: '3.7'
services:
docker:
image: "docker:18.09.9-dind"
privileged: true
volumes:
- docker-certs-client:/certs/client
- docker-certs-ca:/certs/ca
expose:
- 2376
environment:
- DOCKER_TLS_CERTDIR=/certs
networks:
- docker-in-docker-network
docker-build:
image: docker:18.09.9
working_dir: /project
command: build -t 'gcr.io/$PROJECT_ID/<image>:<tag>'
privileged: true
depends_on:
- docker
volumes:
- docker-certs-client:/certs/client:ro
- ../../:/project
environment:
- DOCKER_TLS_CERTDIR=/certs
- DOCKER_BUILDKIT=1
networks:
- docker-in-docker-network
docker-push:
image: docker:18.09.9
working_dir: /project
entrypoint: /bin/sh -c
command:
- |
cat creds.json | docker login -u _json_key --password-stdin https://gcr.io
docker push 'gcr.io/$PROJECT_ID/<image>:<tag>'
privileged: true
depends_on:
- docker
volumes:
- docker-certs-client:/certs/client:ro
- ../../:/project
environment:
- DOCKER_CERT_PATH=/certs/client
- DOCKER_HOST=tcp://docker:2376
- DOCKER_TLS_VERIFY=1
networks:
- docker-in-docker-network
volumes:
docker-certs-ca:
docker-certs-client:
networks:
docker-in-docker-network:
Then in your cloud-build.yaml:
you need to first decrypt a creds.json (must be created and encrypted first) -- for details: https://cloud.google.com/docs/authentication/getting-started
(The push step will use the key to authorize docker login to gcr.)
Run a docker daemon from docker-compose in daemon mode (so it doesn't block the build and push step)
Run the build step docker-compose
Run the auth and push step in docker-compose.
# cloud-build.yaml
steps:
# decrypt gcloud json secret
- name: gcr.io/cloud-builders/gcloud
args:
- kms
- decrypt
- --ciphertext-file=deploy/app/creds.json.enc
- --plaintext-file=creds.json
- --location=global
- --keyring=<...>
- --key=<...>
# run docker daemon
- name: 'docker/compose:1.24.1'
args: ['-f', 'deploy/app/docker-in-docker-compose.yml', 'up', '-d', 'docker']
env:
- 'PROJECT_ID=$PROJECT_ID'
# build image
- name: 'docker/compose:1.24.1'
args: ['-f', 'deploy/app/docker-in-docker-compose.yml', 'up', 'docker-build']
env:
- 'PROJECT_ID=$PROJECT_ID'
# docker auth and push to gcr
- name: 'docker/compose:1.24.1'
args: ['-f', 'deploy/app/docker-in-docker-compose.yml', 'up', 'docker-push']
env:
- 'PROJECT_ID=$PROJECT_ID'
timeout: 600s
Related
On self hosted Gitlab on GCP installed by helm, I use Gitlab-runner.
On gitlab-runner I need to use docker so using dind, but I got error
tcp://docker:2375. Is the docker daemon running?
gitlab-runner deployment
...
spec:
containers:
- command:
- /bin/bash
- /scripts/entrypoint
env:
- name: CI_SERVER_URL
value: https://my-gitlab.com
- name: CLONE_URL
- name: RUNNER_REQUEST_CONCURRENCY
value: "1"
- name: RUNNER_EXECUTOR
value: kubernetes
- name: REGISTER_LOCKED
value: "false"
- name: RUNNER_TAG_LIST
- name: KUBERNETES_IMAGE
- name: KUBERNETES_PRIVILEGED
value: "true" # <= set privileged true to use dind
...
gitlab-ci.yaml
services:
- docker:20.10.4-dind
stages:
- build
variables:
GIT_SSL_NO_VERIFY: "1"
DOCKER_DRIVER: overlay2
DOCKER_TLS_CERTDIR: ''
DOCKER_HOST: tcp://docker:2375
image:
name: google/cloud-sdk:latest
before_script:
- docker version
build:
stage: build
script:
- echo hello
gitlab-runner log
Executing "step_script" stage of the job script
00:00
$ docker version
Cannot connect to the Docker daemon at tcp://docker:2375. Is the docker daemon running?
Client: Docker Engine - Community
Version: 19.03.11
API version: 1.40
Go version: go1.13.10
Git commit: 42e35e61f3
Built: Mon Jun 1 09:09:53 2020
OS/Arch: linux/amd64
Experimental: false
Cleaning up file based variables
00:00
ERROR: Job failed: command terminated with exit code 1
troubleshooting says that it's because of TLS. So I set DOCKER_TLS_CERTDIR: '' , the way written in another document.
Also, this problem didn't happen when I used docker:19.03.0-dind. From 19.03.0-dind, TLS is automatically. So disable TLS configuration must be worked correctly.
(docker:19.3.13-dind also worked well.)
I don't know why from docker:20 this error showed up. Has anyone already tried gitlab-runner with grater than docker:20 ?
I figured out that I should follow https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#docker-in-docker-with-tls-enabled-in-kubernetes
toml
runners:
config: |
[[runners]]
[runners.kubernetes]
image = "ubuntu:20.04"
privileged = true
[[runners.kubernetes.volumes.empty_dir]]
name = "docker-certs"
mount_path = "/certs/client"
medium = "Memory"
gitlab-ci.yaml
services:
- docker:20.10.4-dind
stages:
- build
variables:
GIT_SSL_NO_VERIFY: "1"
DOCKER_DRIVER: overlay2
DOCKER_TLS_CERTDIR: "/certs"
DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"
DOCKER_HOST: tcp://docker:2376
DOCKER_TLS_VERIFY: 1
image:
name: google/cloud-sdk:latest
before_script:
- docker version
build:
stage: build
script:
- echo hello
What happened:
Add "USER 999:999" in Dockerfile to add default uid and gid into container image, then start the container in Pod , its UID is 999, but its GID is 0.
In container started by Docker the ID is correct
docker run --entrypoint /bin/bash -it test
bash-5.0$ id
uid=9999 gid=9999 groups=9999
But start as Pod, the gid is 0
kubectl exec -it test /bin/bash
bash-5.0$ id
uid=9999 gid=0(root) groups=0(root)
bash-5.0$
bash-5.0$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin
systemd-coredump:x:200:200:systemd Core Dumper:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
systemd-resolve:x:193:193:systemd Resolver:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
If Dockerfile run extra "useradd" command , then it seems the gid is ok in Pod
RUN useradd -r -u 9999 -d /dev/null -s /sbin/nologin abc
USER 9999:9999
then the ID in container of Pod is the same as set in Dockerfile
bash-5.0$ id uid=9999(abc) gid=9999(abc) groups=9999(abc)
What you expected to happen: the GID of container in Pod should also 999
How to reproduce it (as minimally and precisely as possible):
Dockerfile add "USER 999:999"
Then start the container in Pod
apiVersion: v1
kind: Pod
metadata:
name: test
spec:
containers:
- name: test
image: test
imagePullPolicy: Never
command: ["/bin/sh", "-c", "trap : TERM INT; sleep infinity & wait"]
Environment:
Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:07:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
OS (e.g: cat /etc/os-release): Fedora release 30 (Thirty)
docker version
Client:
Version: 18.09.9
API version: 1.39
Go version: go1.11.13
Git commit: 039a7df9ba
Built: Wed Sep 4 16:52:09 2019
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.9
API version: 1.39 (minimum version 1.12)
Go version: go1.11.13
Git commit: 039a7df
Built: Wed Sep 4 16:22:32 2019
OS/Arch: linux/amd64
Experimental: false
I realize this isn't what you asked, but since I don't know why the USER directive isn't honored, I'll point out that you have explicit influence over the UID and GID used by your Pod via the securityContext:
spec:
securityContext:
runAsUser: 999
runAsGroup: 999
containers:
- ...
I have seen that gcloud kubernetes is using Docker version 17.03.2-ce, build f5ec1e2.
Where as the I want to have docker version Docker version 18.09.0, build 4d60db4
The error “* Fix error “unexpected EOF” when adding an 8GB file moby/moby#37771” has been resolved in the latter version of docker.
Is there any way i can manually upgrade the version?
Thanks
In Google Kubernetes engine you should have Node OS as Ubuntu. Then you should use a DeamonSet as start-up script with the following yaml file below:
kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
name: ssd-startup-script
labels:
app: ssd-startup-script
spec:
template:
metadata:
labels:
app: ssd-startup-script
spec:
hostPID: true
containers:
- name: ssd-startup-script
image: gcr.io/google-containers/startup-script:v1
imagePullPolicy: Always
securityContext:
privileged: true
env:
- name: STARTUP_SCRIPT
value: |
#!/bin/bash
sudo curl -s https://get.docker.com/ | sh
echo Done
Then you have the Docker version should be like below:
Client:
Version: 18.09.0
API version: 1.39
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:49:01 2018
OS/Arch: linux/amd64
Experimental: false
I'm using docker quickstart terminal on Win10.
Client:
Version: 17.06.0-ce,
API version: 1.30
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:30:30 2017
OS/Arch: windows/amd64
I have a simple document upload php script that saves an uploaded document to a file location called '/uploads'.
I want to make the '/uploads' folder a volume attached to the php:apache container, so i can easily share the contents with the python back-end.
I'm using the following docker-compose.yml file to build a web service with a python back-end.
Note: The php works on the php:apache environment without the volume.
$ docker volume create fileul --opt o=uid=197609,gid=0
version: '3.2'
services:
Python_app:
build: ./product
volumes:
- ./product:/usr/src/app
ports:
- 5001:80
website:
image: php:apache
volumes:
- ./website:/var/www/html
- type: volume
source: fileuld
target: /var/www/html/uploads
read_only: false
ports:
- 5000:80
depends_on:
- Python_app
volumes:
fileuld:
I get a permission error on the web service when I try to upload a document to the attached volume fileuld. failed to open stream: Permission denied in /var/www/html/upload.php
I have read some other stackoverflow posts on this and they talk about uid and gid and i have tried using :
$ls -ls
Which gives the following:
4 -rw-r--r-- 1 ASUSNJHOME 197609 343 Sep 23 14:49 docker-compose.yml
32 drwxr-xr-x 1 ASUSNJHOME 197609 0 Sep 22 07:10 product/
0 drwxr-xr-x 1 ASUSNJHOME 197609 0 Sep 23 15:38 volume-example/
0 drwxr-xr-x 1 ASUSNJHOME 197609 0 Sep 22 21:32 website/
But i can't work out how to have the volume able to accept a document getting written into or how to change the permissions of it when it is being created from the docker-compose file.
Can anyone point me in the right direction?
Thanks
Michael
Am using mesos version 1.0.3. Just installed mesos thru
docker pull mesosphere/mesos-master:1.0.3
docker pull mesosphere/mesos-salve:1.0.3
Using docker-compose to start mesos-master and mesos-slave.
docker-compose file,
services:
#
# Zookeeper must be provided externally
#
#
# Mesos
#
mesos-master:
image: mesosphere/mesos-master:1.0.3
restart: always
privileged: true
network_mode: host
volumes:
- ~/mesos-data/master:/tmp/mesos
environment:
MESOS_CLUSTER: "mesos-cluster"
MESOS_QUORUM: "1"
MESOS_ZK: "zk://localhost:2181/mesos"
MESOS_PORT: 5000
MESOS_REGISTRY_FETCH_TIMEOUT: "2mins"
MESOS_EXECUTOR_REGISTRATION_TIMEOUT: "2mins"
MESOS_LOGGING_LEVEL: INFO
MESOS_INITIALIZE_DRIVER_LOGGING: "false"
mesos-slave1:
image: mesosphere/mesos-slave:1.0.3
depends_on: [ mesos-master ]
restart: always
privileged: true
network_mode: host
volumes:
- ~/mesos-data/slave-1:/tmp/mesos
- /sys/fs/cgroup:/sys/fs/cgroup
- /var/run/docker.sock:/var/run/docker.sock
environment:
MESOS_CONTAINERIZERS: docker
MESOS_MASTER: "zk://localhost:2181/mesos"
MESOS_PORT: 5051
MESOS_WORK_DIR: "/var/lib/mesos/slave-1"
MESOS_LOGGING_LEVEL: WARNING
MESOS_INITIALIZE_DRIVER_LOGGING: "false"
Mesos master runs fine without any issues. But the slave is not starting with the below error. Not sure, what else is missing here.
I0811 21:38:28.952507 1 main.cpp:243] Build: 2017-02-13 08:10:42 by ubuntu
I0811 21:38:28.952599 1 main.cpp:244] Version: 1.0.3
I0811 21:38:28.952601 1 main.cpp:247] Git tag: 1.0.3
I0811 21:38:28.952603 1 main.cpp:251] Git SHA: c673fdd00e7f93ab7844965435d57fd691fb4d8d
SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.29: No such file or directory
2017-08-11 21:38:29,062:1(0x7f4f78d0d700):ZOO_INFO#log_env#726: Client environment:zookeeper.version=zookeeper C client 3.4.8
2017-08-11 21:38:29,062:1(0x7f4f78d0d700):ZOO_INFO#log_env#730: Client environment:host.name=<HOST_NAME>
2017-08-11 21:38:29,062:1(0x7f4f78d0d700):ZOO_INFO#log_env#737: Client environment:os.name=Linux
2017-08-11 21:38:29,062:1(0x7f4f78d0d700):ZOO_INFO#log_env#738: Client environment:os.arch=3.8.13-98.7.1.el7uek.x86_64
2017-08-11 21:38:29,062:1(0x7f4f78d0d700):ZOO_INFO#log_env#739: Client environment:os.version=#2 SMP Wed Nov 25 13:51:41 PST 2015
2017-08-11 21:38:29,063:1(0x7f4f78d0d700):ZOO_INFO#log_env#747: Client environment:user.name=(null)
2017-08-11 21:38:29,063:1(0x7f4f78d0d700):ZOO_INFO#log_env#755: Client environment:user.home=/root
2017-08-11 21:38:29,063:1(0x7f4f78d0d700):ZOO_INFO#log_env#767: Client environment:user.dir=/
2017-08-11 21:38:29,063:1(0x7f4f78d0d700):ZOO_INFO#zookeeper_init#800: Initiating client connection, host=localhost:2181 sessionTimeout=10000 watcher=0x7f4f82265e50 sessionId=0 sessionPasswd=<null> context=0x7f4f5c000930 flags=0
2017-08-11 21:38:29,064:1(0x7f4f74ccb700):ZOO_INFO#check_events#1728: initiated connection to server [127.0.0.1:2181]
2017-08-11 21:38:29,067:1(0x7f4f74ccb700):ZOO_INFO#check_events#1775: session establishment complete on server [127.0.0.1:2181], sessionId=0x15dc8b48c6d0155, negotiated timeout=10000
Failed to perform recovery: Failed to run 'docker -H unix:///var/run/docker.sock ps -a': exited with status 1; stderr='Error response from daemon: client is newer than server (client API version: 1.24, server API version: 1.22)
'
To remedy this do as follows:
Step 1: rm -f /var/lib/mesos/slave-1/meta/slaves/latest
This ensures agent doesn't recover old live executors.
The below command returns same version for docker client API and docker server API. Not sure what is wrong with the setup.
docker -H unix:///var/run/docker.sock version
Client:
Version: 1.10.1
API version: 1.22
Go version: go1.5.3
Git commit: 9e83765
Built: Thu Feb 11 19:18:46 2016
OS/Arch: linux/amd64
Server:
Version: 1.10.1
API version: 1.22
Go version: go1.5.3
Git commit: 9e83765
Built: Thu Feb 11 19:18:46 2016
OS/Arch: linux/amd64
Meoss slave was using the client version 1.24.
This is working after setting the environment variable for the mesos slave.
DOCKER_API_VERSION = 1.22
The combination of the release version and API version of Docker is as follows:
https://docs.docker.com/engine/api/v1.26/#section/Versioning
The other option is to update the docker version.