Geekly articles weekly

Kontainer Dewasa (Bagian 01): Panduan Praktis untuk Terminologi

Anda mungkin bertanya, mengapa berurusan dengan terminologi jika konsep wadah terlihat cukup sederhana dan langsung? Namun, sering kali penggunaan istilah yang salah menciptakan hambatan bagi pengembangan wadah. Sebagai contoh, orang sering berpikir bahwa istilah "wadah" dan "gambar" digunakan secara bergantian, meskipun sebenarnya ada perbedaan konseptual yang penting di antara mereka. Contoh lain: di dunia wadah, "repositori" tidak berarti apa yang Anda pikirkan. Selain itu, teknologi wadah jauh lebih dari sekadar buruh pelabuhan.



Jadi, tanpa mengetahui terminologinya, akan sulit untuk memahami bagaimana buruh pelabuhan berbeda dari CRI-O, rkt atau lxc / lxd; atau mengevaluasi peran Open Container Initiative dalam menstandarisasi teknologi wadah.

Pendahuluan


Memulai dengan wadah Linux sangat sederhana, tetapi segera ternyata kesederhanaan ini menyesatkan. Ini biasanya terjadi seperti ini: setelah menghabiskan hanya beberapa menit memasang buruh pelabuhan atau mesin kontainer lainnya, Anda sudah memasukkan perintah pertama Anda. Hanya beberapa menit - dan Anda sudah membuat gambar pertama wadah itu dan meletakkannya di domain publik. Kemudian Anda terbiasa beralih ke arsitektur lingkungan produksi, dan kemudian tiba-tiba Anda menyadari bahwa untuk ini Anda harus terlebih dahulu berurusan dengan massa istilah dan teknologi yang ada di balik semua ini. Lebih buruk lagi, banyak istilah yang tercantum di bawah ini digunakan secara bergantian, yang menciptakan banyak kebingungan bagi pemula.

  • Wadah
  • Gambar
  • Gambar Kontainer
  • Lapisan Gambar
  • Daftar
  • Repositori
  • Tag
  • Gambar Dasar
  • Gambar Platform
  • Lapisan

Setelah menguasai terminologi yang ditetapkan dalam dokumen ini, Anda akan lebih memahami dasar teknologi wadah. Selain itu, ini akan membantu Anda dan kolega Anda berbicara bahasa yang sama, serta secara sadar dan sengaja merancang arsitektur lingkungan wadah sesuai dengan spesifik tugas yang sedang diselesaikan. Pada gilirannya, dari sudut pandang komunitas TI dan industri secara keseluruhan, peningkatan umum dalam pemahaman tentang teknologi kontainer berkontribusi pada munculnya arsitektur dan solusi baru. Perhatikan bahwa artikel ini ditujukan untuk pembaca yang sudah memiliki gagasan tentang cara menjalankan wadah.

Wadah: Dasar-dasar


Sebelum melanjutkan ke terminologi wadah, kami akan menentukan apa sebenarnya wadah itu. Istilah "wadah" berarti dua hal sekaligus. Seperti program Linux biasa, sebuah wadah dapat berada di salah satu dari dua negara: bekerja dan tidak bekerja. Dalam keadaan siaga, wadah adalah file atau satu set file yang disimpan di disk. Ke kondisi inilah istilah yang merujuk pada Container Image and Repository Container. Ketika Anda memasukkan perintah peluncuran kontainer, mesin wadah membuka paket file dan metadata yang diperlukan dan mentransfernya ke kernel Linux. Memulai sebuah wadah sangat mirip dengan memulai proses Linux biasa dan membutuhkan panggilan API ke kernel Linux. Panggilan API ini biasanya memulai isolasi tambahan dan memasang salinan file yang ada dalam gambar wadah. Setelah wadah diluncurkan, itu hanya proses Linux. Prosedur untuk meluncurkan wadah, serta format gambar wadah yang disimpan pada disk, ditentukan dan diatur oleh standar.

Ada beberapa format untuk gambar kontainer ( Docker , Appc , LXD ), tetapi industri ini secara bertahap bergerak menuju standar Open Container Initiative tunggal, kadang-kadang disebut Open Containers atau hanya OCI. Standar ini mendefinisikan spesifikasi format gambar kontainer , yang mendefinisikan format disk untuk menyimpan gambar kontainer, serta metadata, yang, pada gilirannya, mendefinisikan hal-hal seperti arsitektur perangkat keras dan sistem operasi (Linux, Windows, dll.). Format gambar standar industri tunggal adalah kunci untuk menciptakan ekosistem perangkat lunak yang memungkinkan pengembang, proyek Open Source, dan vendor perangkat lunak untuk membuat gambar yang kompatibel dan berbagai alat, seperti tanda tangan elektronik, pemindaian, perakitan, peluncuran, pergerakan, dan pengelolaan gambar wadah.

Selain itu, ada beberapa mesin kontainer, seperti Docker , CRI-O , Railcar , RKT , LXC . Mesin wadah mengambil gambar wadah dan mengubahnya menjadi wadah (mis., Proses yang berjalan). Proses konversi juga ditentukan oleh standar OCI, yang mencakup spesifikasi runtime kontainer dan implementasi referensi runtime yang disebut RunC, yang merupakan model sumber terbuka yang diatur oleh komunitas pengembangan yang sesuai. Banyak mesin penampung menggunakan model ini untuk berinteraksi dengan kernel host ketika membuat wadah.

Alat yang mendukung spesifikasi format gambar wadah dan lingkungan pelaksanaan wadah standar OCI memberikan portabilitas dalam ekosistem berbagai platform wadah, mesin wadah, dan alat pendukung di berbagai platform cloud dan arsitektur lokal. Memahami terminologi, standar, dan arsitektur sistem wadah akan memungkinkan Anda untuk berkomunikasi secara bermanfaat dengan spesialis lain dan merancang aplikasi dan lingkungan kontainer yang dapat diskalakan dan didukung yang memastikan penggunaan kontainer yang efisien untuk tahun-tahun mendatang.

Kosakata dasar


Gambar kontainer


Dalam definisi yang paling sederhana, gambar kontainer adalah file yang diunduh dari server registri dan digunakan secara lokal sebagai titik pemasangan ketika wadah mulai. Terlepas dari kenyataan bahwa istilah "gambar wadah" cukup sering digunakan, itu bisa berarti hal yang berbeda. Faktanya adalah bahwa meskipun Docker, RKT dan bahkan LXD bekerja sesuai dengan prinsip yang baru saja dijelaskan - yaitu, mereka mengunduh file yang dihapus dan menjalankannya sebagai wadah - masing-masing teknologi ini mengartikan gambar wadah dengan caranya sendiri. LXD beroperasi dengan gambar monolitik (lapisan tunggal), sedangkan buruh pelabuhan dan RKT menggunakan gambar OCI, yang dapat berisi beberapa lapisan.

Sebenarnya, gambar kontainer pada server registri jauh dari satu file. Ketika orang menggunakan istilah "gambar wadah", mereka sering berarti repositori dan berarti satu set beberapa lapisan gambar wadah, serta metadata yang berisi informasi tambahan tentang lapisan ini.

Selain itu, konsep gambar wadah secara implisit menyiratkan keberadaan format untuk gambar seperti itu.

Format gambar kontainer


Awalnya, setiap mesin kontainer, termasuk LXD, RKT, dan Docker, memiliki format gambar sendiri. Beberapa format ini hanya memungkinkan satu lapisan, sementara yang lain mendukung struktur pohon dari beberapa lapisan. Saat ini, hampir semua alat dan mesin kontainer utama telah beralih ke format OCI , yang menentukan bagaimana lapisan dan metadata harus diatur dalam gambar wadah. Intinya, format OCI mendefinisikan gambar kontainer yang terdiri dari file tar terpisah untuk setiap layer dan file manifest.json umum yang berisi metadata.

Standar Open Container Initiative (OCI) , yang awalnya didasarkan pada format gambar Docker V2 , telah berhasil menggabungkan ekosistem besar dari mesin kontainer, platform cloud dan alat (pemindai keamanan, alat penandatanganan, pembuatan dan pemindahan wadah) dan memungkinkan Anda untuk melindungi investasi Anda dalam pengetahuan dan alat.

Mesin kontainer


Mesin penampung adalah bagian dari perangkat lunak yang menerima permintaan pengguna, termasuk parameter baris perintah, mengunduh gambar, dan, dari perspektif pengguna akhir, meluncurkan penampung. Ada banyak mesin kontainer, termasuk buruh pelabuhan, RKT, CRI-O, dan LXD. Selain itu, banyak platform cloud, layanan PaaS, dan platform container memiliki mesin mereka sendiri yang memahami gambar dalam format Docker atau OCI. Memiliki standar industri untuk format gambar memastikan interoperabilitas semua platform ini.

Turun tingkat, kita dapat mengatakan bahwa sebagian besar mesin kontainer tidak benar-benar memulai kontainer sendiri, tetapi melalui runtime yang kompatibel dengan OCI, seperti runc. Biasanya, runtime wadah melakukan hal-hal berikut:

  • Menangani parameter, input pengguna
  • Menangani parameter yang melewati API (paling sering sistem orkestrasi wadah)
  • Unduh gambar wadah dari server registri
  • Membongkar dan menyimpan gambar kontainer ke disk menggunakan Graph Driver (blok atau file, tergantung pada driver)
  • Mempersiapkan titik mount untuk wadah, biasanya dalam penyimpanan copy-on-write (lagi, blok atau file, tergantung pada driver)
  • Mempersiapkan metadata yang akan diteruskan ke runtime untuk menjalankan wadah dengan benar menggunakan:
    • Pengaturan default khusus yang tersirat untuk gambar wadah (misalnya, ArchX86 )
    • Input pengguna untuk mengganti nilai default yang terkandung dalam gambar wadah (misalnya, CMD, ENTRYPOINT)
    • Parameter default yang ditentukan oleh gambar wadah (misalnya, aturan SECCOM )
  • Meminta runtime kontainer

Wadah


Kontainer sudah ada dalam sistem operasi untuk beberapa waktu, karena sebenarnya ini hanya contoh berjalan dari gambar kontainer. Wadah adalah proses Linux standar yang biasanya dibuat menggunakan panggilan sistem clone () alih-alih fork () atau exec (). Selain itu, langkah-langkah isolasi tambahan sering diterapkan pada wadah menggunakan cgroups , SELinux, atau AppArmor .

Tuan rumah kontainer


Host kontainer adalah sistem di mana proses kemas dijalankan, yang sering disebut wadah untuk kesederhanaan. Ini bisa berupa, misalnya, mesin virtual RHEL Atomic Host yang berlokasi di cloud publik atau berjalan pada logam kosong di pusat data perusahaan. Ketika gambar kontainer (dengan kata lain, repositori) dari server registri diunduh ke host kontainer lokal, mereka mengatakan bahwa itu jatuh ke dalam cache lokal.

Anda dapat menentukan repositori mana yang disinkronkan dengan cache lokal menggunakan perintah berikut:

  [root @ rhel7 ~] # buruh pelabuhan gambar -a

 ID GAMBAR TAG PENGUASAAN YANG DIBUAT DENGAN UKURAN VIRTUAL
 registry.access.redhat.com/rhel7 6883d5422f4e terbaru 3 minggu lalu 201,7 MB

Server registri


Registri server pada dasarnya adalah server file yang digunakan untuk menyimpan repositori buruh pelabuhan. Sebagai aturan, server registri ditentukan oleh nama DNS dan, secara opsional, nomor port. Sebagian besar manfaat ekosistem buruh pelabuhan didorong oleh kemampuan untuk mengunduh dan mengunggah repositori ke server registri.

Jika daemon docker tidak menemukan salinan repositori di cache lokal, daemon docker secara otomatis mengunduhnya dari server registri. Pada sebagian besar distribusi Linux, daemon docker akan menggunakan situs docker.io untuk ini, tetapi pada beberapa distribusi ia dapat dikonfigurasi dengan caranya sendiri. Sebagai contoh, Red Hat Enterprise Linux pertama kali mencoba mengunduh dari registry.access.redhat.com, dan baru kemudian dari docker.io (Docker Hub).

Harus ditekankan di sini bahwa server registri secara implisit dianggap tepercaya. Oleh karena itu, Anda harus memutuskan seberapa besar Anda mempercayai isi registri dan, masing-masing, mengizinkan atau menolaknya. Selain keamanan, ada aspek lain yang harus ditangani terlebih dahulu, misalnya masalah lisensi perangkat lunak atau pemantauan kepatuhan. Kesederhanaan yang memungkinkan pekerja mengunduh perangkat lunak membuat masalah kepercayaan sangat penting.

Red Hat Enterprise Linux memungkinkan Anda untuk mengkonfigurasi registri buruh pelabuhan default. Selain itu, RHEL7 dan RHEL7 Atomic memungkinkan Anda untuk menambah atau mengunci server registri melalui file konfigurasi :

  vi / etc / sysconfig / docker

RHEL7 dan RHEL 7 Atom secara default menggunakan server registri Red Hat:

  ADD_REGISTRY = '- tambahkan-registry registry.access.redhat.com'

Dalam beberapa kasus, untuk alasan keamanan, masuk akal untuk memblokir pendaftar dermaga umum, seperti DockerHub:

  # BLOCK_REGISTRY = '- blok-registri'

Red Hat juga menawarkan server registri terintegrasi sebagai bagian dari Platform OpenShift Container , serta server registri perusahaan yang berdiri sendiri Quay Enterprise dan cloud, repositori swasta dan publik Quay.io.

Orkestrasi wadah


Orang biasanya memulai dengan memasang host kontainer dan pertama-tama hanya mengunduh gambar kontainer yang mereka butuhkan. Kemudian mereka melanjutkan untuk membuat gambar mereka sendiri dan mengunggahnya ke server registri untuk membuat tersedia untuk seluruh tim. Setelah beberapa waktu, ada kebutuhan untuk menggabungkan beberapa kontainer sehingga dapat digunakan sebagai satu unit. Dan akhirnya, pada titik tertentu, unit-unit ini harus menjadi bagian dari conveyor produksi (pengembangan-QA-produksi). Beginilah biasanya orang menyadari bahwa mereka membutuhkan sistem orkestrasi.

Sistem orkestrasi wadah hanya mengimplementasikan dua hal:

  1. Mengirim muatan kontainer secara dinamis ke seluruh komputer cluster (ini sering disebut sebagai "komputasi terdistribusi")
  2. Menyediakan file deskripsi aplikasi standar (kube yaml, docker compose, dll.)

Dua hal ini sebenarnya memberikan berbagai manfaat:

  1. Kemampuan untuk mengelola wadah yang menyusun aplikasi, secara terpisah satu sama lain, yang memungkinkan Anda untuk menyelesaikan tugas-tugas berikut secara efektif:
    • Pembuangan cluster host kontainer besar
    • Kegagalan pada tingkat wadah individu (tidak lagi merespons proses, kehabisan memori)
    • Gagal pada level host kontainer (drive, jaringan, reboot)
    • Gagal di tingkat mesin wadah (kerusakan, restart)
    • Penskalaan individu atas dan bawah kontainer
  2. Mudah untuk menyebarkan contoh baru dari aplikasi yang sama di lingkungan baru, baik cloud dan tradisional, misalnya:
    • Pada mesin pengembang yang dikendalikan oleh sistem orkestrasi
    • Dalam lingkungan pengembangan bersama di ruang nama pribadi
    • Dalam lingkungan pengembangan yang sama di namespace publik internal untuk memastikan visibilitas dan menguji kinerja
    • Di lingkungan internal QA
    • Dalam lingkungan uji beban disediakan dan dicabut secara dinamis di cloud
    • Dalam lingkungan referensi untuk memverifikasi kompatibilitas dengan lingkungan produksi
    • Di lingkungan produksi
    • Dalam lingkungan pemulihan bencana
    • Dalam lingkungan produksi baru yang berisi host kontainer diperbarui, mesin kontainer atau alat orkestrasi
    • Di lingkungan produksi baru, yang tidak berbeda dari yang utama, tetapi terletak di wilayah yang berbeda

Komunitas Open Source dan vendor perangkat lunak menawarkan banyak alat orkestrasi yang berbeda. Awalnya, tiga alat besar ini termasuk Swarm , Mesos dan Kubernetes , tetapi hari ini Kubernetes sebenarnya telah menjadi standar industri, karena Docker dan Mesosphere telah mengumumkan dukungan mereka, belum lagi hampir semua penyedia layanan utama. Namun, jika Anda mencari sistem orkestrasi perusahaan, kami sarankan Anda melihat lebih dekat pada Red Hat OpenShift .

Kamus Tingkat Lanjut


Runtime kontainer


Runtime kontainer adalah komponen tingkat rendah yang biasanya digunakan sebagai bagian dari mesin wadah, tetapi juga dapat digunakan secara manual untuk menguji wadah. Standar OCI mendefinisikan implementasi referensi runtime yang dikenal sebagai runc . Ini adalah implementasi yang paling banyak digunakan, tetapi ada runtime yang kompatibel dengan OCI lainnya seperti crun , railcar, dan katacontainers . Docker, CRI-O, dan banyak mesin kontainer lainnya menggunakan runc.

Runtime kontainer bertanggung jawab untuk hal-hal berikut:

  • Mendapat titik pemasangan wadah yang disediakan oleh mesin wadah (untuk pengujian, bisa saja berupa direktori)
  • Mendapat metadata wadah yang disediakan oleh mesin wadah (selama pengujian, ini mungkin file config.json yang dirakit secara manual)
  • Berkomunikasi dengan kernel OS untuk meluncurkan proses kemas (melalui panggilan sistem klon)
  • Mengkonfigurasi cgroup
  • Mengkonfigurasi Kebijakan SELinux
  • Mengkonfigurasi Aturan Armor Aplikasi

Sedikit penyimpangan sejarah: ketika mesin Docker pertama kali muncul, ia menggunakan LXC sebagai lingkungan runtime. Pengembang Docker kemudian menulis perpustakaan mereka sendiri untuk menjalankan kontainer yang disebut libcontainer. Itu ditulis dalam bahasa Golang dan menjadi bagian dari mesin Docker. Setelah pembentukan organisasi OCI, Docker memperkenalkan libcontainer kode sumber ke dalam proyek ini dan merilis perpustakaan ini sebagai utilitas terpisah yang disebut runc, yang kemudian menjadi implementasi referensi runtime kontainer dalam standar OCI dan digunakan dalam mesin kontainer lainnya, seperti CRI-O . Runc adalah utilitas yang sangat sederhana yang hanya menunggu titik mount (direktori) dan metadata (config.json) diteruskan ke sana. Informasi lebih lanjut tentang runc dapat ditemukan di sini .

Untuk pemahaman yang lebih dalam, lihat Memahami Standar Kontainer dan Runtime Kontainer .

Lapisan gambar


Repositori sering disebut sebagai gambar atau gambar wadah, meskipun sebenarnya repositori terdiri dari satu atau lebih lapisan. Lapisan gambar dalam repositori saling berhubungan oleh hubungan orangtua-anak, dan setiap lapisan gambar berisi perbedaan dari lapisan induk.

Mari kita lihat lapisan repositori pada host kontainer lokal. Sejak dimulai dengan versi 1.7, Docker tidak memiliki alat bawaan untuk melihat lapisan gambar di repositori lokal (tetapi ada alat untuk pendaftaran online), kami akan menggunakan utilitas Dockviz . Perhatikan bahwa setiap lapisan memiliki tag dan pengidentifikasi unik universal (UUID) . Untuk melihat UUID disingkat yang biasanya unik dalam mesin yang sama, kami menggunakan perintah berikut (jika Anda memerlukan UUID lengkap, gunakan perintah yang sama dengan opsi -no-trunc):

run docker --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock gambar nate / dockviz -t

  ├─2332d8973c93 Ukuran Virtual: 187,7 MB
  │ └─ea358092da77 Ukuran Virtual: 187,9 MB
  │ └─a467a7c6794f Ukuran Virtual: 187,9 MB
  │ └─ca4d7b1b9a51 Ukuran Virtual: 187,9 MB
  │ └─4084976dd96d Ukuran Virtual: 384.2 MB
  │ └─943128b20e28 Ukuran Virtual: 386.7 MB
  │ └─db20cc018f56 Ukuran Virtual: 386.7 MB
  │ └─45b3c59b9130 Ukuran Virtual: 398.2 MB
  │ └─91275de1a5d7 Ukuran Virtual: 422.8 MB
  │ └─e7a97058d51f Ukuran Virtual: 422.8 MB
  │ └─d5c963edfcb2 Ukuran Virtual: 422.8 MB
  │ └─5cfc0ce98e02 Ukuran Virtual: 422.8 MB
  │ └─7728f71a4bcd Ukuran Virtual: 422.8 MB
  │ └─0542f67da01b Ukuran Virtual: 422.8 MB Tag: docker.io/registry:latest

Seperti yang Anda lihat, repositori docker.io/registry sebenarnya terdiri dari banyak lapisan. Namun, yang lebih penting, pengguna dapat, pada prinsipnya, "memulai" wadah dari langkah apa pun di tangga langkah ini, misalnya, dengan memasukkan perintah di bawah ini (benar-benar benar, tetapi tidak ada yang dapat menjamin bahwa itu telah diuji atau akan bekerja dengan baik sama sekali). Sebagai aturan, kolektor gambar memberi tag (membuat nama) lapisan-lapisan yang harus digunakan sebagai titik awal:

  run docker -it 45b3c59b9130 bash

Repositori diatur dengan cara yang sama karena setiap kali kolektor membuat gambar baru, perbedaan disimpan sebagai lapisan lain. Ada dua cara utama untuk membuat layer baru di repositori. Pertama, saat membuat gambar secara manual, setiap konfirmasi perubahan membuat lapisan baru. Jika kolektor membuat gambar menggunakan file Docker, setiap arahan dalam file menciptakan lapisan baru. Oleh karena itu, selalu berguna untuk dapat melihat apa yang telah berubah dalam repositori antar lapisan.

Tag


Meskipun pengguna sendiri dapat menentukan lapisan awal untuk pemasangan dan memulai wadah di repositori, ia tidak harus melakukan ini sama sekali. Ketika pengumpul gambar membuat repositori baru, mereka biasanya menandai lapisan yang paling cocok untuk peran ini. Marker ini disebut tag dan mewakili alat yang dengannya kolektor gambar dapat memberi tahu konsumen gambar lapisan mana yang paling baik digunakan. Biasanya, tag digunakan untuk menunjukkan versi perangkat lunak dalam repositori.Namun, baik OCI, maupun standar lain tidak mengatur penggunaan tag, yang membuka ruang lingkup tanpa batas untuk kebingungan selama kolaborasi. Oleh karena itu, kami merekomendasikan untuk secara hati-hati mendokumentasikan tag jika tag tidak hanya digunakan untuk menandai versi perangkat lunak.

Selain itu, ada satu tag khusus - terbaru, yang biasanya menunjuk ke lapisan yang berisi perangkat lunak terbaru dalam repositori. Tag ini hanya menunjuk ke lapisan gambar, seperti tag lain, dan karenanya dapat juga digunakan secara tidak benar.

Untuk melihat tag yang tersedia di repositori dari jarak jauh, jalankan perintah berikut ( utilitas jq membuat output lebih mudah dibaca):

curl -s registry.access.redhat.com/v1/repository/rhel7/tags | jq
 {
 "7.0-21": "e1f5733f050b2488a17b7630cb038bfbea8b7bdfa9bdfb99e63a33117e28d02f",
 "7.0-23": "bef54b8f8a2fdd221734f1da404d4c0a7d07ee9169b1443a338ab54236c8c91a",
 "7.0-27": "8e6704f39a3d4a0c82ec7262ad683a9d1d9a281e3c1ebbb64c045b9af39b3940",
 "7.1-11": "d0a516b529ab1adda28429cae5985cab9db93bfd8d301b3a94d22299af72914b",
 "7.1-12": "275be1d3d0709a06ff1ae38d0d5402bc8f0eeac44812e5ec1df4a9e99214eb9a",
 "7.1-16": "82ad5fa11820c2889c60f7f748d67aab04400700c581843db0d1e68735327443",
 "7.1-24": "c4f590bbcbe329a77c00fea33a3a960063072041489012061ec3a134baba50d6",
 "7.1-4": "10acc31def5d6f249b548e01e8ffbaccfd61af0240c17315a7ad393d022c5ca2",
 "7.1-6": "65de4a13fc7cf28b4376e65efa31c5c3805e18da4eb01ad0c8b8801f4a10bc16",
 "7.1-9": "e3c92c6cff3543d19d0c9a24c72cd3840f8ba3ee00357f997b786e8939efef2f",
 "7.2": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e",
 "7.2-2": "58958c7fafb7e1a71650bc7bdbb9f5fd634f3545b00ec7d390b2075db511327d",
 "7.2-35": "6883d5422f4ec2810e1312c0e3e5a902142e2a8185cd3a1124b459a7c38dc55b",
 "7.2-38": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e",
 "terbaru": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e"
  }

Repositori


Saat menggunakan perintah buruh pelabuhan, repositori, bukan gambar, ditentukan pada baris perintah. Misalnya, dalam perintah rhel7 di bawah ini, ini adalah repositori.

 docker pull rhel7

:

 docker pull registry.access.redhat.com/rhel7:latest

, . , , , docker images. , , , «» (manifest.json):

 docker images

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
 registry.access.redhat.com/rhel7 latest 6883d5422f4e 4 weeks ago 201.7 MB
 registry.access.redhat.com/rhel latest 6883d5422f4e 4 weeks ago 201.7 MB
 registry.access.redhat.com/rhel6 latest 05c3d56ba777 4 weeks ago 166.1 MB
 registry.access.redhat.com/rhel6/rhel terbaru 05c3d56ba777 4 minggu lalu 166.1 MB
  ...

Dengan menentukan repositori pada baris perintah, kami sebenarnya meminta mesin kontainer untuk melakukan beberapa pekerjaan untuk kami. Dalam contoh di atas, daemon buruh pelabuhan (yaitu, daemon, bukan alat klien) memiliki daftar server yang dikonfigurasi untuk mencari, dan karenanya akan mencari repositori rhel7 pada masing-masingnya.

Dalam contoh di atas, kami hanya menentukan nama repositori, tetapi di klien buruh pelabuhan Anda juga dapat menentukan URL lengkap. Untuk memahami bagaimana melakukan ini, pisahkan URL lengkap menjadi bagian-bagian komponennya.



Dengan kata lain, turun ke:

 REGISTRI / NAMESPACE / REPOSITORY [: TAG]

URL lengkap terdiri dari nama server, namespace, dan tag opsional. Bahkan, ada banyak nuansa saat menentukan URL, dan saat Anda menjelajahi ekosistem buruh pelabuhan, Anda akan melihat bahwa banyak hal bersifat opsional. Secara khusus, lihat perintah di bawah ini: semuanya benar dan mengarah ke hasil yang sama:

 buruh pelabuhan menarik registry.access.redhat.com/rhel7/rhel:latest
 buruh pelabuhan menarik registry.access.redhat.com/rhel7/rhel
 buruh pelabuhan menarik registry.access.redhat.com/rhel7
 buruh pelabuhan tarik rhel7 / rhel: terbaru

Ruang nama


Ruang nama adalah alat untuk memisahkan repositori menjadi grup. Di registri publik DockerHub , namespace biasanya adalah nama pengguna yang berbagi gambar, tetapi juga bisa berupa nama grup atau nama logis.

Red Hat menggunakan ruang nama untuk memisahkan grup repositori dengan produk yang terdaftar di server Red Hat Federated Registry . Contoh jajak pendapat dari registry.access.redhat.com disediakan di bawah ini. Perhatikan bahwa baris terakhir dalam contoh ini sebenarnya menunjuk ke server registri yang berbeda. Ini karena fakta bahwa Red Hat bekerja untuk menampilkan repositori pada server registri mitra kami:

 registry.access.redhat.com/rhel7/rhel
registry.access.redhat.com/openshift3/mongodb-24-rhel7
registry.access.redhat.com/rhscl/mongodb-26-rhel7
registry.access.redhat.com/rhscl_beta/mongodb-26-rhel7
registry-mariadbcorp.rhcloud.com/rhel7/mariadb-enterprise-server:10.0

Harap perhatikan bahwa kadang-kadang URL lengkap mungkin tidak ditentukan. Dalam contoh di atas, untuk setiap namespace ada repositori default. Jika pengguna hanya menentukan namespace fedora, maka repositori dengan tag terbaru diunduh ke server lokal. Oleh karena itu, perintah di bawah ini menghasilkan hasil yang sama:

 buruh pelabuhan tarik fedora
buruh pelabuhan menarik docker.io/fedora
buruh pelabuhan menarik docker.io/library/fedora:latest

Kernel Namespaces


, , . , , , , , . , , , . .

Bash Enter, Bash Linux- exec(). Kontainer berbeda karena ketika Anda mengirim permintaan ke mesin wadah, seperti buruh pelabuhan, daemon buruh pelabuhan meminta kernel untuk membuat proses kemas menggunakan menggunakan panggilan sistem lain yang disebut clone () . Panggilan sistem clone () istimewa karena dapat membuat proses dengan titik mount virtualnya sendiri, ID proses, ID pengguna, antarmuka jaringan, nama host, dll.

Oleh karena itu, meskipun Linux tidak memiliki struktur data satu untuk mewakili wadah, yang paling dekat dengan peran adalah ruang nama kernel dan panggilan sistem clone ().


Dilanjutkan ...

Source: https://habr.com/ru/post/id416169/

More articles:


All Articles