Penggunaan Raspberry Pi sebagai perangkat komputasi berbiaya rendah semakin meluas di Indonesia, baik untuk keperluan pendidikan, prototipe Internet of Things (IoT), maupun solusi edge computing skala kecil. Namun, ketika pengembang mencoba menjalankan kontainer Docker di atas board tersebut, sering kali menghadapi kendala tak terduga berupa status kontainer yang langsung berhenti dengan kode keluar `Exited (1)`. Error ini menjadi salah satu keluhan umum di forum komunitas teknologi lokal, terutama bagi mereka yang baru mengenal ekosistem containerization pada arsitektur ARM. Artikel ini mengulas secara mendalam penyebab teknis di balik kegagalan tersebut serta langkah-langkah mitigasi yang dapat diterapkan langsung di perangkat Raspberry Pi.
Kode keluar 1 pada Docker secara umum menandakan bahwa proses utama di dalam kontainer telah terminasi dengan error generik. Akan tetapi, dalam konteks perangkat embedded seperti Raspberry Pi, penyebabnya sangat spesifik dan berbeda dari lingkungan server konvensional. Beberapa faktor dominan meliputi ketidakcocokan arsitektur CPU, ketiadaan biner yang kompatibel dengan instruksi ARM, serta permasalahan hak akses terhadap perangkat keras tertentu. Memahami akar masalah ini krusial karena penanganan yang salah hanya akan membuang waktu dan sumber daya, padahal solusinya relatif sederhana jika dipahami secara sistematis.
Penyebab paling fundamental adalah perbedaan arsitektur antara image Docker yang diunduh dengan prosesor Raspberry Pi. Mayoritas image di registri publik seperti Docker Hub dibangun untuk arsitektur x86_64 (amd64), sementara Raspberry Pi generasi awal hingga Pi 3 menggunakan armhf (ARMv7) dan Pi 4 serta Pi Zero 2 menggunakan aarch64 (ARMv8). Ketika sebuah kontainer mencoba mengeksekusi biner yang dikompilasi untuk amd64 di atas hardware ARM, sistem operasi akan menolaknya dengan pesan seperti `no such file or directory` pada level init. Hal ini sering membingungkan karena file sebenarnya ada, tetapi tidak kompatibel secara instruksi CPU.
Sinyal diagnostik yang sangat berguna adalah ketika kontainer tersebut berjalan normal pada mesin virtual Raspberry Pi di atas PC (yang mungkin meniru x86_64 via QEMU), namun gagal total saat dijalankan di hardware fisik. Kondisi ini mengonfirmasi bahwa masalah bukan pada konfigurasi aplikasi, melainkan murni ketidaksesuaian arsitektur. Untuk memverifikasi, pengguna dapat menjalankan perintah `uname -m` pada host untuk melihat arsitektur Pi, dan `docker inspect --format='{{.Architecture}}' nama_image` untuk melihat arsitektur image. Jika hasilnya berbeda (misal armv7l vs amd64), maka kecocokan harus diperbaiki sebelum mencoba opsi lain.
Langkah praktis berikutnya adalah menjalankan kontainer tanpa mode background (`-d`) dan dengan opsi interaktif (`-it`) agar pesan error langsung terlihat di terminal. Perintah `docker run --net=host -it --rm nama_image` akan menampilkan log secara real-time. Jika penyebabnya arsitektur, pesan `standard_init_linux.go:211: exec user process caused: no such file or directory` akan muncul. Catatan penting juga mengenai sintaks `--net=host`: penulisan dengan spasi seperti `--net = host` merupakan kesalahan umum yang membuat Docker menginterpretasikan `=` sebagai bagian dari nilai, sehingga kontainer gagal secara diam-diam. Penulisan yang benar adalah merangkai parameter tanpa spasi.
Untuk mengatasi ketidakcocokan arsitektur, terdapat tiga pendekatan utama. Pertama, gunakan image resmi multi-ar sitektur seperti `python:3.11-slim` yang secara otomatis menyediakan varian ARM. Kedua, bangun image secara lokal di Raspberry Pi dengan perintah `docker build -t nama_image .` sehingga biner terkompilasi native. Ketiga, jika terpaksa menjalankan image x86_64, pasang `qemu-user-static` dan daftarkan ke Docker melalui kontainer privileged, namun metode ini sangat lambat dan hanya direkomendasikan untuk pengujian, bukan produksi. Bagi komunitas maker Indonesia, membangun image lokal adalah pilihan paling efisien karena tidak bergantung pada emulasi.
Aspek lain yang sering diabaikan adalah kebutuhan hak akses perangkat keras. Raspberry Pi sering digunakan untuk mengontrol GPIO, sensor I2C, atau kamera, yang memerlukan akses ke `/dev`. Menjalankan kontainer dengan `--privileged` atau memetakan `-v /dev:/dev` dapat menyelesaikan masalah izin, tetapi membuka risiko keamanan jika diterapkan di lingkungan produksi. Rekomendasi keamanan adalah menggunakan `--cap-add` tertentu atau `--device=/dev/i2c-1` agar kontainer hanya mendapat akses minimal. Hal ini relevan dengan tren edge computing di sektor industri Indonesia yang mulai menaruh kontainer di perangkat lapangan.
Sebagai langkah lanjutan, pengembang dapat membuat skrip otomatisasi untuk mendeteksi arsitektur dan memilih tag image yang tepat. Misalnya, skrip bash yang membaca `uname -m` dan menetapkan `arm32v7/myimage` atau `arm64v8/myimage` secara dinamis. Praktik ini meningkatkan portabilitas proyek antar tipe board dan mengurangi human error. Ditambah dengan pipeline CI/CD yang mendukung multi-arch build, ekosistem Docker di ARM menjadi semakin matang.
Dari perspektif industri teknologi Tanah Air, penguasaan penanganan error spesifik seperti `Exited (1)` pada Raspberry Pi mendorong literasi infrastruktur yang lebih inklusif. Mengingat banyak universitas dan startup lokal menggunakan Pi sebagai node murah untuk eksperimen ML atau gateway IoT, efisiensi debugging berdampak langsung pada kecepatan inovasi. Selain itu, meningkatnya dukungan ARM di ekosistem cloud dan silikon lokal membuka peluang untuk harmonisasi pengembangan dari prototype hingga deployment.
Pada akhirnya, setelah arsitektur dan izin diperbaiki, kontainer seharusnya berstatus `Up` saat dicek dengan `docker ps`. Jika masih gagal, pemeriksaan log via `docker logs <container_id>` akan memberikan petunjuk lanjutan. Dengan pemahaman menyeluruh tentang interaksi antara Docker, arsitektur CPU, dan perangkat keras Raspberry Pi, pengembang di Indonesia dapat memaksimalkan potensi komputasi tepi tanpa terjebak pada error generik yang sebenarnya mudah diatasi.