我在gitlab-ci中運行以下CI腳本時收到錯誤docker: command not found
。在部署階段,before_script
期間發生此錯誤。未找到碼頭工的碼頭工具:dind + google/cloud-sdk
services:
- docker:dind
stages:
- build
- test
- deploy
before_script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
build:
stage: build
image: docker:latest
script:
- docker info
- docker version
- docker build --pull -t $SERVICE_NAME:$CI_COMMIT_REF_NAME .
- docker image list
- docker tag $SERVICE_NAME:$CI_COMMIT_REF_NAME $CI_REGISTRY_IMAGE/$SERVICE_NAME:$CI_COMMIT_REF_NAME
- docker push $CI_REGISTRY_IMAGE/$SERVICE_NAME:$CI_COMMIT_REF_NAME
test:
image: docker:latest
stage: test
script:
- docker pull $CI_REGISTRY_IMAGE/$SERVICE_NAME:$CI_COMMIT_REF_NAME
- docker image list
- docker run $CI_REGISTRY_IMAGE/$SERVICE_NAME:$CI_COMMIT_REF_NAME npm test
deploy:
image: google/cloud-sdk
stage: deploy
environment: Production
script:
- echo $DEPLOY_KEY_FILE_PRODUCTION > /tmp/GCLOUD_KEYFILE.json
- gcloud auth activate-service-account --key-file /tmp/GCLOUD_KEYFILE.json
- rm /tmp/GCLOUD_KEYFILE.json
- gcloud info
- gcloud components list
only:
- master
我有點困惑,因爲我乳寧泊塢窗功能於泊塢窗(docker:dind
)作爲一個服務應作出泊塢窗命令適用於所有階段(如果我這個理解正確的),但是這顯然不是。
是否由於與Google/cloud-sdk的互動?
感謝您的回答,我相信你是對的。但這有點違反直覺。 Gitlab在他們的文檔中提供了將mysql作爲服務運行的例子。這樣,可以在構建的任何階段調用mysql。因此,使用相同的邏輯,我應該能夠在docker中運行Docker作爲服務,並在任何階段訪問docker命令。但事實並非如此。 – Overdrivr
爲了增加歧義性,在服務中使用'dind'的所有人也都使用['docker:latest'圖像](https://hub.docker.com/_/docker/),這已經是Docker了Docker! WTF。我在這裏錯過了一些非常明顯的東西嗎? – Overdrivr
我會立刻投票並等待看看我能否獲得更多反饋,我會盡快嘗試你的方法 – Overdrivr