Kontainer Docker dalam kontainer Docker menggunakan daemon Docker induk HOST dan oleh karena itu, setiap volume yang dipasang dalam kasus "docker-in-docker" masih direferensikan dari HOST, dan bukan dari Kontainer.
Oleh karena itu, jalur aktual yang dipasang dari wadah Jenkins "tidak ada" di HOST. Karena itu, direktori baru dibuat di wadah "docker-in-docker" yang kosong. Hal yang sama berlaku ketika direktori dipasang ke container Docker baru di dalam Container.
Hal yang sangat mendasar dan jelas yang saya lewatkan, tetapi saya sadari segera setelah saya mengetik pertanyaan.
Cara lain untuk melakukannya adalah dengan menggunakan volume bernama atau wadah volume data. Dengan cara ini, wadah di dalamnya tidak perlu mengetahui apa pun tentang host dan wadah Jenkins serta wadah build mereferensikan volume data dengan cara yang sama.
Saya telah mencoba melakukan sesuatu yang mirip dengan apa yang Anda lakukan, kecuali dengan agen daripada menggunakan master Jenkins. Masalahnya sama karena saya tidak bisa memasang ruang kerja Jenkins di wadah bagian dalam. Apa yang berhasil bagi saya adalah menggunakan pendekatan wadah volume data dan file ruang kerja dapat dilihat oleh wadah agen dan wadah dalam. Apa yang saya sukai dari pendekatan ini adalah kedua kontainer mereferensikan volume data dengan cara yang sama. Memasang direktori dengan inner container akan menjadi rumit karena inner container sekarang perlu mengetahui sesuatu tentang host tempat container induknya dijalankan.
Saya memiliki entri blog mendetail tentang pendekatan saya di sini:
http://damnhandy.com/2016/03/06/creating-containerized-build-environments-with-the-jenkins-pipeline-plugin-and-docker-well-almost/
Serta kode di sini:
https://github.com/damnhandy/jenkins-pipeline-docker
Dalam kasus khusus saya, tidak semuanya berfungsi seperti yang saya inginkan dalam hal plugin Jenkins Pipeline. Tapi itu mengatasi masalah penampung bagian dalam yang dapat mengakses direktori ruang kerja Jenkins.
Banyak info bagus di posting ini tetapi saya tidak menemukan satupun dari mereka yang sangat jelas tentang wadah mana yang mereka maksud. Jadi mari beri label pada 3 lingkungan:
- tuan rumah:H
- kontainer buruh pelabuhan berjalan di H:D
- wadah buruh pelabuhan berjalan di D:D2
Kita semua tahu cara memasang folder dari H ke D:mulai D dengan
docker run ... -v <path-on-H>:<path-on-D> -v /var/run/docker.sock:/var/run/docker.sock ...
Tantangannya adalah:Anda ingin path-on-H tersedia di D2 sebagai path-on-D2 .
Tapi kami semua tergigit saat mencoba memasang path-on-H yang sama ke D2, karena kami memulai D2 dengan
docker run ... -v <path-on-D>:<path-on-D2> ...
Saat Anda berbagi soket buruh pelabuhan di H dengan D, maka menjalankan perintah buruh pelabuhan di D pada dasarnya menjalankannya di H. Memang jika Anda memulai D2 seperti ini, semua berfungsi (awalnya tidak terduga, tetapi masuk akal jika Anda memikirkannya):
docker run ... -v <path-on-H>:<path-on-D2> ...
Bagian rumit berikutnya adalah bagi banyak dari kita, path-on-H akan berubah tergantung siapa yang menjalankannya. Ada banyak cara untuk mengirimkan data ke D sehingga ia mengetahui apa yang harus digunakan untuk path-on-H , tapi mungkin yang paling mudah adalah variabel lingkungan. Untuk memperjelas tujuan dari var tersebut, saya memulai namanya dengan DIND_ . Kemudian dari H mulai D seperti ini:
docker run ... -v <path-on-H>:<path-on-D> --env DIND_USER_HOME=$HOME \
--env DIND_SOMETHING=blabla -v /var/run/docker.sock:/var/run/docker.sock ...
dan dari D mulai D2 seperti ini:
docker run ... -v $DIND_USER_HOME:<path-on-D2> ...