प्रौद्योगिकी साझेदारी

क्रॉस्-प्लेटफॉर्म इमेज् निर्मातुं docker buildx इत्यस्य उपयोगं कुर्वन्तु

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

buildx इति Docker द्वारा आधिकारिकतया प्रदत्तं निर्माणसाधनम् अस्ति यत् एतत् उपयोक्तृभ्यः Docker चित्राणि शीघ्रं कुशलतया च निर्मातुं साहाय्यं कर्तुं शक्नोति, तथा च बहुविधमञ्चानां निर्माणस्य समर्थनं करोति । buildx इत्यस्य उपयोगेन उपयोक्तारः बहुविध-आर्किटेक्चर-कृते, यथा x86 तथा arm-आर्किटेक्चर-इत्येतयोः कृते चित्राणि एकस्मिन् आदेशे निर्मातुम् अर्हन्ति, यत्र बहुविध-निर्माण-आदेशान् मैन्युअल् रूपेण संचालयितुं न प्रवृत्ताः । तदतिरिक्तं buildx Dockerfile इत्यस्य बहुचरणनिर्माणं, संग्रहणं च समर्थयति, यत् चित्रनिर्माणस्य कार्यक्षमतां गतिं च बहुधा सुधारयितुं शक्नोति ।

buildx एकं CLI प्लग-इन् अस्ति यत् Docker निर्माणं प्रबन्धयति अन्तर्निहितं स्तरं Docker निर्माणक्षमतां विस्तारयितुं BuildKit इत्यस्य उपयोगं करोति ।

BuildKit इति उच्च-प्रदर्शन-निर्माण-इञ्जिनं आधिकारिकतया Docker-द्वारा प्रदत्तम् अस्ति, यस्य उपयोगः Docker-इत्यस्य मूल-निर्माण-इञ्जिनस्य स्थाने भवितुं शक्यते । मूलइञ्जिनस्य तुलने बिल्डकिट् इत्यस्य निर्माणवेगः द्रुततरः, समानान्तरता अधिका, संसाधनानाम् उपयोगः न्यूनः, सुरक्षा च उत्तमः अस्ति ।

buildx संस्थापनार्थं उपयोगाय च Docker Engine संस्करणसङ्ख्या 19.03 इत्यस्मात् अधिका वा समाना वा भवति ।

क्रॉस-प्लेटफॉर्म इमेज बिल्डिंग रणनीति

निर्माता पार-मञ्च-प्रतिम-निर्माणार्थं भिन्न-भिन्न-रणनीतयः समर्थयति ।

कर्नेल् मध्ये QEMU अनुकरणसमर्थनस्य उपयोगः

यदि भवान् Docker Desktop इत्यस्य उपयोगं करोति तर्हि QEMU पूर्वमेव समर्थितम् अस्ति तथा च क्रॉस्-प्लेटफॉर्म इमेज् निर्मातुं सरलतमं रणनीतिः अस्ति । अस्य मूल Dockerfile मध्ये किमपि परिवर्तनस्य आवश्यकता नास्ति BuildKit Linux kernel function binfmt_misc इत्यस्य माध्यमेन cross-platform program execution कार्यान्वितं करिष्यति ।

कार्यसिद्धान्तः १.

QEMU एकः प्रोसेसर सिमुलेटरः अस्ति यः भिन्न-भिन्न CPU आर्किटेक्चर्स् अनुकरणं कर्तुं शक्नोति वयं तत् वर्चुअल् मशीन् इत्यस्य अन्यरूपेण अवगन्तुं शक्नुमः । buildx इत्यस्मिन् QEMU इत्यस्य उपयोगः build प्रक्रियायाः समये गैर-देशीय-आर्किटेक्चर-कृते बाइनरी-निष्पादनार्थं भवति । यथा, x86 होस्ट् इत्यत्र ARM इमेज् निर्माय QEMU ARM वातावरणस्य अनुकरणं कृत्वा ARM द्विचक्रिकाः चालयितुं शक्नोति ।

binfmt_misc Linux कर्नेल् इत्यस्य एकं मॉड्यूल् अस्ति यत् उपयोक्तृभ्यः कार्यान्वयनीयसञ्चिकास्वरूपं तत्सम्बद्धान् च व्याख्याकारान् पञ्जीकरणं कर्तुं शक्नोति ।यदा कर्नेल् अज्ञातस्वरूपस्य कार्यान्वयनीयसञ्चिकायाः ​​सम्मुखीभवति तदा सञ्चिकास्वरूपेण (अस्मिन् सन्दर्भे QEMU) सह सम्बद्धं व्याख्याकारं अन्वेष्टुं सञ्चिकां चालयितुं binfmt_misc इत्यस्य उपयोगः भवति . एतत् कार्यं rk3568 मञ्चे निष्क्रियम् अस्ति ।

QEMU तथा binfmt_misc इत्येतयोः संयोजनेन buildx मार्गेण क्रॉस्-प्लेटफॉर्म-निर्माणं सम्भवं भवति । एतेन अन्यस्य आर्किटेक्चरस्य कृते होस्ट् इत्यत्र एकस्य आर्किटेक्चरस्य कृते Docker इमेज् निर्मातुं शक्यते यत् वास्तविकं लक्ष्यहार्डवेयरस्य स्वामित्वं न भवति ।

यद्यपि Docker Desktop अन्येषां मञ्चानां कृते binfmt_misc समर्थनेन सह पूर्वविन्यस्तम् अस्ति तथापि Docker इत्यस्य अन्यसंस्करणानाम् कृते, समर्थनार्थं विशेषाधिकारयुक्तं पात्रं आरभ्य भवद्भिः tonistiigi/binfmt चित्रस्य उपयोगः आवश्यकः भवेत्

docker run --privileged --rm tonistiigi/binfmt --install all

एतत् आदेशं चालयित्वा भिन्न-भिन्न-आर्किटेक्चरस्य व्याख्याकार-कार्यक्रमाः संस्थाप्यन्ते, अर्थात् /usr/bin निर्देशिकायां qemu सिमुलेटर्:

binfmt_misc मॉड्यूल् अस्माकं संकलनसर्वरस्य उपरि लोड् भवति:

qemu इत्यस्य उपयोगेन docker buildx इत्यस्य भूमिका

Docker Buildx Docker इत्यस्य प्रयोगात्मकं विशेषता अस्ति यत् Docker इत्यस्य निर्माणक्षमतां विस्तारयति, यत्र बहु-नोड्, qemu इत्यादीनां उपयोगः अपि अस्ति । QEMU इति एकं मुक्तस्रोत-वर्चुअल् मशीन-सॉफ्टवेयरं यत् भिन्न-भिन्न-CPU-इत्यादीनां हार्डवेयर-इत्यस्य अनुकरणं कर्तुं शक्नोति, येन अस्मान् एकस्मिन् ऑपरेटिंग्-प्रणाल्यां अन्यस्य ऑपरेटिंग्-प्रणाल्याः प्रतिबिम्बं निर्मातुं शक्यते

Docker Buildx इत्यस्य qemu फंक्शन् इत्यस्य उपयोगेन अस्मान् बहुविधविभिन्न आर्किटेक्चर्स् (यथा ARM, MIPS इत्यादीनां) कृते Docker इमेज् निर्मातुं साहाय्यं कर्तुं शक्यते ।

ARM आर्किटेक्चरस्य कृते Docker इमेज् निर्मातुं Docker Buildx तथा QEMU इत्येतयोः उपयोगः कथं करणीयः इति दर्शयति निम्नलिखितम् सरलम् उदाहरणम् अस्ति:

  1. # 创建一个新的 buildkit 实例
  2. docker buildx create --name mybuilder --use
  3. # 启动 buildkit 实例
  4. docker buildx start mybuilder
  5. # 启用 QEMU 驱动支持
  6. docker buildx inspect --bootstrap
  7. # 构建一个面向 ARM 架构的 Docker 镜像
  8. docker buildx build --platform linux/arm/v7 -t myimage:latest .

अस्मिन् उदाहरणे .--platform पैरामीटर् निर्दिशति यत् वयं यस्य लक्ष्यमञ्चस्य निर्माणं कर्तुम् इच्छामः तत् ARM v7 अस्ति । एवं प्रकारेण Docker ARM वातावरणस्य अनुकरणार्थं QEMU इत्यस्य उपयोगं करिष्यति तथा च x86 आर्किटेक्चरयन्त्रे ARM आर्किटेक्चरस्य कृते Docker इमेज निर्मास्यति ।

binfmt_misc सञ्चिकातन्त्रम्

binfmt-misc इति विण्डोज इत्यत्र सञ्चिकासम्बद्धतायाः सदृशं Linux कर्नेल् द्वारा प्रदत्तं कार्यं, परन्तु सञ्चिकासम्बद्धतायाः अपेक्षया अधिकं शक्तिशाली अस्ति यत् एतत् न केवलं सञ्चिकाप्रत्ययनाम्ना आधारेण न्यायं कर्तुं शक्नोति, अपितु सञ्चिकायाः ​​आधारेण भिन्नानां कार्यक्रमानां उपयोगेन अपि उद्घाटयितुं शक्यते सामग्री (जादू बाइट्स) . एकः विशिष्टः उपयोगपरिदृश्यः अन्येषु आर्किटेक्चर मञ्चेषु द्विचक्रीयसञ्चिकाः चालयितुं qemu इत्यस्य उपयोगः भवति ।

binfmt-misc सक्षमं कुर्वन्तु

अस्थायीरूपेण सक्षमीकरणाय निम्नलिखित आदेशस्य उपयोगं कुर्वन्तु ।

$ sudo mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc

पुनः आरम्भस्य अनन्तरं एषा पद्धतिः अमान्यः भविष्यति यदि भवान् इच्छति यत् एतत् दीर्घकालं यावत् प्रभावं प्राप्नुयात् तर्हि /etc/fstab सञ्चिकायां रेखां योजयितुं शक्नोति ।

none  /proc/sys/fs/binfmt_misc binfmt_misc defaults 0 0

उद्घाटनं सफलं वा इति परीक्षितुं भवान् निम्नलिखित-आदेशस्य उपयोगं कर्तुं शक्नोति ।

  1. $ mount | grep binfmt_misc
  2. binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
  3. $ ls -l /proc/sys/fs/binfmt_misc
  4. 总用量 0
  5. --w------- 1 root root 0 25 22:55 register
  6. -rw-r--r-- 1 root root 0 25 22:55 status

प्रथमं arm64 आर्किटेक्चर इत्यनेन सह प्रोग्राम् सज्जीकरोतु तस्य निष्पादनस्य अनन्तरं त्रुटिः निवेदिता भवति ।

bash: ./go-test:无法执行二进制文件: 可执行文件格式错误

अधुना, apt install qemu-user-binfmt इति आदेशं निष्पादयामः, ततः उपरिष्टात् arm64 प्रोग्राम् चालयामः तथा च सामान्यतया चालयितुं शक्नोति इति ज्ञास्यामः । qemu-user-binfmt संस्थापनानन्तरं /proc/sys/fs/binfmt_misc निर्देशिकायां अनेकाः सञ्चिकाः निर्मिताः भविष्यन्ति, यत्र एकः qemu-aarch64 अस्ति ।

  1. root@ubuntu:/proc/sys/fs/binfmt_misc# cat qemu-aarch64
  2. enabled
  3. interpreter /usr/bin/qemu-aarch64-static
  4. flags: OC
  5. offset 0
  6. magic 7f454c460201010000000000000000000200b700
  7. mask ffffffffffffff00fffffffffffffffffeffffff
  8. root@ubuntu:/proc/sys/fs/binfmt_misc#

एषा सञ्चिका नियमसञ्चिकायाः ​​वर्णनं करोति :

प्रथमा पङ्क्तिः सक्षमा नियमः सक्षमः इति सूचयति;

द्वितीयपङ्क्तिव्याख्याकारः /usr/bin/qemu-aarch64-static द्विचक्रीयसञ्चिकां निष्पादयितुं /usr/bin/qemu-aarch64-static इत्यस्य उपयोगं सूचयति;

तृतीया पङ्क्तिः : OC धावन्तं ध्वजं प्रतिनिधियति, विशिष्टः अर्थः निम्नलिखितरूपेण अस्ति ।

P: इत्यस्य अर्थः preserve-argv इति भवति, यस्य अर्थः अस्ति यत् सिमुलेटरं आह्वयति समये मूलमापदण्डाः (argv) संरक्षिताः भविष्यन्ति ।एतत् तादृशानां परिस्थितीनां कृते उपयोगी भवति यत्र मौनकार्यक्रमेभ्यः रनटाइम् इत्यत्र स्वस्य नाम (अर्थात् argv[0]) ज्ञातव्यं भवति

O: offset इत्यस्य प्रतिनिधित्वं करोति, यस्य अर्थः अस्ति यत् सिमुलेटरस्य आरम्भात् पूर्वं द्विचक्रीयसञ्चिकातः एकं ऑफसेट् पठितव्यम्, अयं च ऑफसेट् सिमुलेटरस्य पैरामीटर् रूपेण उपयुज्यते

C: इति प्रमाणपत्रस्य अर्थः भवति, यस्य अर्थः अस्ति यत् एमुलेटरः मूलप्रोग्रामेन उपयुज्यमानेन एव उपयोक्तृ-ID-समूह-ID-सहितं चालयिष्यति, यत् एमुलेटर् मूलप्रोग्रामस्य समानैः अनुमतिभिः सह चालयति इति सुनिश्चित्य सहायकं भवति

चतुर्थपङ्क्तिः: offset 0 इत्यस्य अर्थः 0 मूल्यात् सञ्चिकां पठितुं आरभ्यते;

पञ्चमपङ्क्तिः: magic 7f454c46020101000000000000000000200b700 मेलनीयं मॉड्यूलो बाइट् प्रतिनिधियति;

arm64 आर्किटेक्चरस्य ELF सञ्चिकायाः ​​शीर्षके जादूक्षेत्रं निम्नलिखितम् अस्ति, यस्य अर्थः अस्ति यत् binfmt_misc सञ्चिकातन्त्रं ELF सञ्चिकायां जादूक्षेत्रस्य आधारेण सञ्चिकां चालयितुं कस्य आर्किटेक्चर सिमुलेटरस्य उपयोगः कर्तव्यः इति निर्धारयितुं शक्नोति:

अधः द्वौ भिन्नौ वास्तुकलाद्वयम् अस्ति

मिप्स वास्तुकला: 7f454c46010201000000000000000000020008
arm64 वास्तुकला: 7f454c4602010100000000000000000200b700

पङ्क्ति 6: mask ffffffffffffffff00ffffffffffffffffffffffffffffffffffffffffffffffff off byte mask इत्यस्य प्रतिनिधित्वं करोति, यस्य उपयोगेन सञ्चिकायां केचन अमहत्त्वपूर्णाः बाइट् इत्यस्य अवहेलना कर्तुं शक्यते ।

x86_64 प्रणाल्यां arm64 आर्किटेक्चर Docker इमेज चालयति

अधुना वयं उपयुञ्ज्महेdockerआदेशः arm64 इमेज चालयति:

  1. $ docker run -it arm64v8/ubuntu bash
  2. Unable to find image 'arm64v8/ubuntu:latest' locally
  3. latest: Pulling from arm64v8/ubuntu
  4. 005e2837585d: Pull complete
  5. Digest: sha256:ba545858745d6307f0d1064d0d25365466f78d02f866cf4efb9e1326a4c196ca
  6. Status: Downloaded newer image for arm64v8/ubuntu:latest
  7. standard_init_linux.go:207: exec user process caused "no such file or directory"

किञ्चित् अन्वेषणं कृत्वा अहं ज्ञातवान् यत् यावत् अहं निम्नलिखितम् आदेशं निष्पादयामि तावत् ।apt install qemu-user-static, ततः docker आरभ्यताम्पात्रम्सामान्यम् एव।

Dockerfile इत्यस्मिन् बहुचरणीय-क्रॉस्-बिल्ड् इत्यस्य उपयोगः

क्रॉस्-कम्पाइलेशनस्य जटिलता Docker इत्यत्र न भवति, अपितु प्रोग्रामे एव अस्ति । उदाहरणार्थं, Go प्रोग्राम्स् सहजतया क्रॉस्-कम्पाइल् कर्तुं शक्यन्ते भवद्भिः केवलं go build इत्यस्य उपयोगेन प्रोग्राम् इत्यस्य निर्माणकाले GOOS तथा GOARCH इति वातावरणचरद्वयं निष्पादयितुं आवश्यकम् ।

निर्माता रचयन्तु

क्रॉस्-प्लेटफॉर्म इमेज् निर्मातुं buildx इत्यस्य उपयोगाय प्रथमं बिल्डर् निर्मातव्यं, यत् बिल्डर् इति अनुवादयितुं शक्यते ।

बिल्डर् सूचीं द्रष्टुं docker buildx ls आदेशस्य उपयोगं कुर्वन्तु:

  1. root@ubuntu:/proc# docker buildx ls
  2. NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS
  3. mybuild * docker-container
  4. mybuild0 unix:///var/run/docker.sock running linux/arm64*, linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/amd64/v4, linux/386
  5. vigilant_hugle docker-container
  6. vigilant_hugle0 unix:///var/run/docker.sock stopped
  7. default docker
  8. default default running linux/amd64, linux/386

* चिह्नं वर्तमानकाले प्रयुक्तं बिल्डरं सूचयति यदा वयं docker build आदेशं चालयामः तदा वयं इमेज् निर्मातुं एतस्य बिल्डर् इत्यस्य उपयोगं कुर्मः । द्वितीयस्तम्भे DRIVER/ENDPOINT इत्यनेन प्रयुक्तं चालकं सूचयति । buildx निम्नलिखितचालकानाम् समर्थनं करोति:

  • docker: Docker डेमन् मध्ये बण्डल् कृतस्य BuildKit पुस्तकालयस्य उपयोगं कुर्वन्तु, यत् Docker संस्थापनानन्तरं पूर्वनिर्धारितं BuildKit अस्ति ।
  • docker-container: नूतनं समर्पितं BuildKit पात्रं निर्मातुं Docker इत्यस्य उपयोगं कुर्वन्तु ।
  • kubernetes: kubernetes क्लस्टरमध्ये BuildKit Pod रचयन्तु ।
  • remote: मैन्युअल् रूपेण प्रबन्धित BuildKit डेमन् इत्यनेन सह प्रत्यक्षतया संयोजयन्तु ।

यतः docker चालकस्य उपयोगेन पूर्वनिर्धारितनिर्माता एकस्य आदेशस्य उपयोगेन cross-platform चित्राणां निर्माणस्य समर्थनं न करोति (पूर्वनिर्धारितनिर्मातृस्य --platform पैरामीटर् केवलं एकं मूल्यं स्वीकुर्वति), अतः अस्माभिः docker-container चालकस्य उपयोगेन नूतनं बिल्डरं निर्मातव्यम् .

आदेशवाक्यविन्यासः यथा भवति ।

$ docker buildx create --name=<builder-name> --driver=<driver> --driver-opt=<driver-options>

परिमाणानां अर्थः यथा;

--name: निर्मितं नाम, आवश्यकम्।

--driver: निर्माता चालकः, पूर्वनिर्धारितं docker-container अस्ति ।

--driver-opt: चालकविकल्पाः उदाहरणार्थं, --driver-opt=image=moby/buildkit:v0.11.3 विकल्पः BuildKit इत्यस्य निर्दिष्टं संस्करणं संस्थापयितुं शक्नोति पूर्वनिर्धारितं मूल्यं moby/buildkit अस्ति ।

वयं निम्नलिखित आदेशस्य उपयोगेन नूतनं बिल्डरं निर्मातुम् अर्हति ।

  1. $ docker buildx create --name mybuilder
  2. mybuilder

पुनः निर्मातासूचीं पश्यन्तु:

  1. $ docker buildx ls
  2. NAME/NODE DRIVER/ENDPOINT STATUS BUILDKIT PLATFORMS
  3. mybuilder * docker-container
  4. mybuilder0 unix:///var/run/docker.sock inactive
  5. default docker
  6. default default running 20.10.21 linux/arm64, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
  7. desktop-linux docker
  8. desktop-linux desktop-linux running 20.10.21 linux/arm64, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6

भवान् पश्यति यत् चयनितं बिल्ड् Mybuilder इत्यत्र स्विच् कृतम् अस्ति यदि तत् न चयनितम् अस्ति तर्हि बिल्डर् स्विच् कर्तुं docker buildx use mybuilder इति आदेशस्य मैन्युअल् रूपेण उपयोगः करणीयः ।

निर्माता आरभत

अस्माकं नवनिर्मितः mybuilder सम्प्रति निष्क्रियः अस्ति, तस्य उपयोगात् पूर्वं आरम्भः करणीयः ।

  1. $ docker buildx inspect --bootstrap mybuilder
  2. [+] Building 16.8s (1/1) FINISHED
  3. => [internal] booting buildkit 16.8s
  4. => => pulling image moby/buildkit:buildx-stable-1 16.1s
  5. => => creating container buildx_buildkit_mybuilder0 0.7s
  6. Name: mybuilder
  7. Driver: docker-container
  8. Nodes:
  9. Name: mybuilder0
  10. Endpoint: unix:///var/run/docker.sock
  11. Status: running
  12. Buildkit: v0.9.3
  13. Platforms: linux/arm64, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6

inspect subcommand इत्यस्य उपयोगः build status इत्यस्य जाँचार्थं भवति mybuilder builder इत्यस्य आरम्भार्थं --bootstrap पैरामीटर् इत्यस्य उपयोगं कुर्वन्तु mybuilder स्थितिः चालयितुं परिवर्तिता अस्ति ।

  1. $ docker buildx ls
  2. NAME/NODE DRIVER/ENDPOINT STATUS BUILDKIT PLATFORMS
  3. mybuilder * docker-container
  4. mybuilder0 unix:///var/run/docker.sock running v0.9.3 linux/arm64, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
  5. default docker
  6. default default running 20.10.21 linux/arm64, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6
  7. desktop-linux docker
  8. desktop-linux desktop-linux running 20.10.21 linux/arm64, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6

PLATFORMS स्तम्भे प्रदर्शितं मूल्यम्

linux/arm64, linux/amd64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6 वर्तमाननिर्मातृणा All द्वारा समर्थिताः सन्ति मञ्चाः ।

अधुना mybuilder builder इत्यस्य अनुरूपं BuildKit container आरब्धम् इति द्रष्टुं docker ps आदेशस्य उपयोगं कुर्वन्तु ।

  1. $ docker ps
  2. CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
  3. b8887f253d41 moby/buildkit:buildx-stable-1 "buildkitd" 4 minutes ago Up 4 minutes buildx_buildkit_mybuilder0

अस्माकं कृते क्रॉस्-प्लेटफॉर्म इमेज् निर्मातुं एतत् पात्रं उपयुज्यते ।

क्रॉस्-प्लेटफॉर्म इमेज् निर्मातुं builder इत्यस्य उपयोगं कुर्वन्तु

$ docker buildx build --platform linux/arm64,linux/amd64 -t jianghushinian/hello-go .

docker buildx build इत्यस्य वाक्यविन्यासः docker build इत्यस्य समानः अस्ति --platform पैरामीटर् इमेज् इत्यस्य निर्माणार्थं लक्ष्यमञ्चं सूचयति, -t इमेज् इत्यस्य Tag इत्येतत् सूचयति । .सन्दर्भः वर्तमाननिर्देशिका इति सूचयति。 

केवलं यत् कार्यं न करोति तत् --platform पैरामीटर् इत्यस्य समर्थनम् अस्ति docker build इत्यस्य --platform पैरामीटर् केवलं एकं मञ्चसूचनं पारयितुं समर्थयति, यथा --platform linux/arm64, यस्य अर्थः अस्ति यत् एकः मञ्चप्रतिबिम्बः कर्तुं शक्नोति एकस्मिन् समये निर्मिताः भवन्तु।

चित्रस्य निर्माणार्थं docker buildx build इत्यस्य उपयोगः एकस्मिन् समये बहुविधमञ्चसूचनाः प्रसारयितुं समर्थयति, आङ्ग्लविल्पविरामैः पृथक्कृतः, अतः केवलं एकेन आदेशेन बहुविधं पार-मञ्चप्रतिमानां निर्माणस्य कार्यं साक्षात्करोति

उपरिष्टात् आदेशं निष्पादयित्वा वयं चेतावनीम् प्राप्नुमः :

WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load

इयं चेतावनी अस्मान् स्मारयति यत् वयं docker-container चालकस्य कृते आउटपुट् न निर्दिष्टवन्तः उत्पन्नाः परिणामाः केवलं build cache मध्ये एव स्थापिताः भविष्यन्ति Use --push इत्यनेन चित्रं Docker Hub दूरस्थभण्डारं प्रति धकेलितुं शक्यते, तथा च --load इत्यस्य उपयोगः करणीयः चित्रं स्थानीयरूपेण रक्षितुं .

यतो हि अस्माकं नवनिर्मितं mybuilder BuildKit चालयितुं कंटेनरं आरभते यत् इदं प्रत्यक्षतया निर्मितं क्रॉस्-प्लेटफॉर्म इमेज् स्थानीययन्त्रे आउटपुट् कर्तुं वा रिमोट् मध्ये धक्कायितुं वा न शक्नोति ।

वयं स्थानीयहोस्ट् मध्ये चित्रं रक्षितुं --load इति निर्दिष्टुं प्रयतितुं शक्नुमः ।

  1. $ docker buildx build --platform linux/arm64,linux/amd64 -t jianghushinian/hello-go . --load
  2. [+] Building 0.0s (0/0)
  3. ERROR: docker exporter does not currently support exporting manifest lists

परिणामः त्रुटिवृत्तलेखः भविष्यति । इदं प्रतीयते यत् एतत् स्थानीयं प्रति क्रॉस्-प्लेटफॉर्म-प्रतिमाः निर्यातयितुं समर्थयति न यंत्रं।

ततः वयं केवलं --push पैरामीटर् इत्यस्य माध्यमेन cross-platform इमेज् दूरस्थं गोदामं प्रति धक्कायितुं शक्नुमः । तथापि एतत् कर्तुं पूर्वं भवद्भिः प्रवेशं पूर्णं कर्तुं docker login इत्यस्य उपयोगः सुनिश्चितः करणीयः ।

$ docker buildx build --platform linux/arm64,linux/amd64 -t jianghushinian/hello-go . --push

अधुना Docker Hub इत्यत्र प्रवेशं कुर्वन्तु ततः भवन्तः धक्कायमानं cross-platform इमेज् द्रष्टुं शक्नुवन्ति ।

क्रॉस्-प्लेटफॉर्म इमेज् इत्यस्य प्रकटसूचनाः परीक्षितुं वयं imagestools इत्यस्य उपयोगं अपि कर्तुं शक्नुमः एतस्य आदेशस्य उपयोगः केवलं गोदामे इमेज् सूचनां प्राप्तुं शक्यते, तथा च स्थानीय इमेज् द्रष्टुं न शक्यते ।

  1. $ docker buildx imagetools inspect jianghushinian/hello-go
  2. Name: docker.io/jianghushinian/hello-go:latest
  3. MediaType: application/vnd.docker.distribution.manifest.list.v2+json
  4. Digest: sha256:51199dadfc55b23d6ab5cfd2d67e38edd513a707273b1b8b554985ff562104db
  5. Manifests:
  6. Name: docker.io/jianghushinian/hello-go:latest@sha256:8032a6f23f3bd3050852e77b6e4a4d0a705dfd710fb63bc4c3dc9d5e01c8e9a6
  7. MediaType: application/vnd.docker.distribution.manifest.v2+json
  8. Platform: linux/arm64
  9. Name: docker.io/jianghushinian/hello-go:latest@sha256:fd46fd7e93c7deef5ad8496c2cf08c266bac42ac77f1e444e83d4f79d58441ba
  10. MediaType: application/vnd.docker.distribution.manifest.v2+json
  11. Platform: linux/amd64

 

यथा भवान् पश्यति, अस्मिन् क्रॉस्-प्लेटफॉर्म-प्रतिबिम्बे द्वयोः लक्ष्य-मञ्चयोः चित्राणि सन्ति, यथा linux/arm64 तथा linux/amd64 इति ।