Untuk mengubah bind mount Compose dengan aman di macOS, pertama-tama identifikasi folder host yang ada dan jalur kontainer yang dilayaninya. Salin berkas ke folder Mac yang baru sebelum mengedit Compose, lalu verifikasi mount yang telah disesuaikan dan buat ulang layanan yang terpengaruh. Sebuah bind mount mengarah ke jalur host; mengubah jalur tersebut tidak memindahkan atau menghapus berkas asli. Dokumentasi bind mount Docker juga menjelaskan bahwa mount dapat menyembunyikan berkas yang sudah ada di lokasi tujuan kontainernya.

Ketahui berkas mana yang dikontrol oleh mount

Bind mount Compose menghubungkan jalur di Mac Anda ke jalur di dalam kontainer. Misalnya, ./data:/var/lib/example membuat direktori data di samping berkas Compose dapat diakses di dalam kontainer pada /var/lib/example. Operasi penulisan yang dilakukan oleh kontainer ke mount tersebut dapat mengubah berkas Mac, karena secara default bind mount bersifat baca-tulis (read-write). Folder Mac adalah data yang perlu Anda pertahankan; tujuan kontainer adalah tempat aplikasi mengharapkan keberadaannya.

Ini berbeda dengan named volume seperti db-data:/var/lib/example. Named volume disimpan dan dikelola oleh Docker, sedangkan bind mount menggunakan direktori host. Mengubah salah satunya ke yang lain merupakan migrasi penyimpanan, bukan sekadar pengeditan jalur. Jangan berasumsi bahwa membuat ulang kontainer akan menyalin berkas di antara keduanya. Dokumentasi penyimpanan Docker menjelaskan perbedaan ini.

Salin berkas yang ada ke folder Mac yang baru

Sebelum mengubah berkas Compose, hentikan layanan jika layanan tersebut berpotensi menulis ke data. Dari Terminal, jalankan docker compose stop app, dengan mengganti app dengan nama layanan Compose. Langkah ini mengurangi kemungkinan folder lama dan baru mengalami perbedaan saat Anda menyalin. Periksa berkas Compose dan semua override untuk mengonfirmasi sumber serta target saat ini secara tepat; hindari menebak hanya dari direktori kontainer yang terlihat.

Sebagai contoh, jika sumber saat ini adalah ~/Projects/Old App/data dan sumber baru seharusnya ~/Projects/New App/data, buat tujuannya dan salin isinya dengan perintah standar macOS rsync:

mkdir -p "$HOME/Projects/New App/data"
rsync -a "$HOME/Projects/Old App/data/" "$HOME/Projects/New App/data/"

Garis miring penutup berarti “salin isi direktori ini.” Tanda kutip melindungi spasi dalam contoh jalur ini dari shell default macOS, zsh. Perintah ini menggabungkan berkas ke tujuan dan tidak menghapus berkas yang hanya ada di tujuan. Periksa tujuan sebelum melanjutkan. Jika data tersebut penting, simpan juga cadangan independen; salinan bukanlah pengganti cadangan.

Perbarui bind mount dan cegah kesalahan pengetikan

Utamakan sintaksis panjang Compose untuk mount direktori saat Anda ingin jalur sumber yang hilang menghentikan startup alih-alih secara senyap menjadi folder kosong:

services:
  app:
    volumes:
      - type: bind
        source: ./data
        target: /var/lib/example
        bind:
          create_host_path: false

Di sini, ./data disesuaikan relatif terhadap direktori induk berkas Compose untuk runtime Compose lokal. Ubah ke jalur Mac relatif atau absolut yang diinginkan, tetapi biarkan target tetap sama jika aplikasi harus terus menggunakan /var/lib/example. Sintaksis pendek Compose membuat direktori host jika sumbernya tidak ada; sintaksis panjang dengan create_host_path: false menghindari fallback tersebut. Lihat referensi layanan Compose.

Jika Anda memilih jalur absolut dengan spasi, beri tanda kutip pada string YAML, misalnya source: "/Users/sam/Projects/New App/data". Ganti sam dengan nama direktori home akun Mac Anda yang sebenarnya. Pertahankan jalur sumber dalam YAML sebagai jalur harfiah; aturan tanda kutip shell berlaku untuk perintah Terminal, bukan untuk nilai YAML.

Periksa jalur yang telah disesuaikan, lalu buat ulang layanan

Dari direktori yang memuat berkas Compose, periksa konfigurasi yang akan digunakan Compose:

docker compose config

Periksa bahwa sumber bind layanan app mengarah ke folder baru dan targetnya masih /var/lib/example. Jika Anda menggunakan beberapa berkas Compose, ingatlah bahwa jalur didasarkan pada berkas pertama yang ditentukan; referensi CLI Compose mendokumentasikan perilaku ini. Jika sumber yang disesuaikan tidak sesuai, hentikan dan perbaiki berkas tersebut sebelum memulai kontainer.

Buat ulang layanan agar kontainer yang berjalan menerima perubahan mount:

docker compose up -d --force-recreate app
docker compose ps app

Compose mendokumentasikan bahwa up membuat ulang kontainer saat konfigurasi berubah, dan --force-recreate menegaskannya secara eksplisit. Pastikan layanan berjalan, lalu periksa berkas atau data yang diharapkan oleh aplikasi sebelum menghapus atau mengganti nama folder lama. Direktori lama tetap berada di Mac Anda kecuali Anda menghapusnya sendiri. Pertahankan folder tersebut sampai Anda memastikan bahwa sumber baru sudah benar dan aplikasi berjalan sesuai harapan.

Jika mount gagal di Docker Desktop untuk Mac

Docker Desktop menjalankan kontainer di VM Linux dan memediasi akses ke berkas Mac. Direktori bersama default-nya mencakup /Users, /Volumes, /private, /tmp, dan /var/folders; sumber di luar lokasi bersama yang tersedia mungkin perlu ditambahkan di Docker Desktop pada bagian Settings > Resources > File sharing. Dokumentasi pengaturan Desktop Docker menjelaskan kontrol ini dan mencatat bahwa izin berkas tetap berpengaruh.

Mount yang gagal seharusnya memicu pemeriksaan jalur dan berbagi berkas, bukan penghapusan salinan lama. Jika direktori baru kosong, verifikasi source yang disesuaikan, apakah penyalinan menempatkan berkas pada tingkat direktori yang dituju, dan apakah Docker Desktop dapat mengakses lokasi Mac tersebut. Jangan gunakan docker compose down -v sebagai langkah perbaikan bind-mount: perintah ini tidak diperlukan untuk mengubah sumber bind dan dapat menghapus named volume yang digunakan oleh proyek.

Langkah penyelesaian yang aman sangat sederhana: pastikan folder Mac baru berisi berkas yang diperlukan, konfirmasi bahwa Compose mengarah ke folder tersebut beserta target kontainer yang diharapkan, lalu uji layanan yang dibuat ulang sebelum menonaktifkan atau menghapus salinan asli.

Sumber