VPN კონტეინერი 'exec format error'-ით წყვეტს მუშაობას: არასწორი პლატფორმა

კონტეინერები, რომლებიც დაუყოვნებლივ წყვეტენ მუშაობას exec format error-ით, არასწორ ინსტინქტს იწვევენ: შესაძლებლობის დამატება, მოწყობილობის მიმაგრება, გვირაბის კონფიგურაციის რედაქტირება. ამათგან არცერთი არ აღწევს პრობლემამდე. ბირთვმა საერთოდ ვერ შეძლო ბინარულის შესრულება, რაც კონტეინერში თითქმის ყოველთვის ნიშნავს, რომ გამოსახულება მიმართულია ჰოსტისგან განსხვავებული CPU არქიტექტურისკენ. ყველაფერი, რისი შეცვლაც შეიძლებოდა მარშრუტიზაციაში, სერტიფიკატებში ან უფლებებში, ხდება პროგრამის გაშვების შემდეგ, და არცერთი პროგრამა არ გაშვებულა.

გაშვების შეტყობინება, რომელიც კონფიგურაციის შეცდომას ჰგავს

exec ფორმატის წარუმატებლობა მოდის ჩამტვირთავიდან, სანამ აპლიკაცია ერთ პარამეტრსაც წაიკითხავს. ამიტომ ის არ ქმნის კონფიგურაციის გაფრთხილებებს და არც გვირაბის ჟურნალს, რადგან არ არსებობს ცოცხალი პროცესი, რომელიც დაწერდა მათ. წარუმატებლობა ასევე საოცრად სწრაფია, ხშირად მანამდე, სანამ კონტეინერის ჟურნალში ერთი ხაზიც გამოჩნდება. იგივე მოკლე შეტყობინება ჩნდება მიუხედავად იმისა, ბინარული სხვა არქიტექტურისთვისაა, სხვა ოპერაციული სისტემისთვისაა თუ დაზიანებულია.

ჩაწერეთ გაშვების გარემო და არქიტექტურა ზუსტ გამოსახულების მითითებასთან ერთად, შემდეგ შეამოწმეთ რას გვთავაზობს ეს მითითება რეალურად. Docker Desktop-ზე კონტეინერის პლატფორმა ეკუთვნის Linux-ის ვირტუალურ მანქანას და არა ლეპტოპს, ამიტომ მხოლოდ ჰოსტის არქიტექტურამ შეიძლება შეგცდინოს. წაიკითხეთ ამ მითითების ინდექსის ჩანაწერების სია და არა მარკეტინგული ტექსტი მისი ტეგის გვერდზე.

წაიკითხეთ გამოსახულების ინდექსი გაშვების ბრძანებამდე

როცა რეესტრი აქვეყნებს მრავალპლატფორმიან მითითებას, ტეგი მიუთითებს ინდექსზე, და ყოველი ჩანაწერი ასახელებს პლატფორმას საკუთარი digest-ით. შეისწავლეთ განსახილველი მითითება და არა მეზობელი ტეგი, და წაიკითხეთ ინდექსი იმის ნაცვლად, რომ ივარაუდოთ მისი შიგთავსი.

docker buildx imagetools inspect ghcr.io/example/vpn:1.4
docker image inspect --format '{{.Os}}/{{.Architecture}}' ghcr.io/example/vpn:1.4

პირველი ბრძანება ჩამოთვლის პლატფორმებს, რომლებსაც მითითება აქვეყნებს. მეორე აცნობებს უკვე ლოკალურად არსებული გამოსახულების პლატფორმას, და სწორედ მას გაუშვებს გაშვების გარემო. მხოლოდ ერთი ჩანაწერის მქონე მითითება ნიშნავს, რომ ყოველი ჰოსტი ერთსა და იმავე ბინარულს იღებს, და ტეგი ვერ დაეხმარება მანქანას, რომლისთვისაც ის არასდროს აშენებულა.

ტეგები ირჩევენ ვარიანტს; ისინი არ ქმნიან მას

მრავალპლატფორმიანი ინდექსი გაშვების გარემოს საშუალებას აძლევს აირჩიოს შესაბამისი ჩანაწერი, რაც ნამდვილად მოსახერხებელია და ხშირად გადატანადობად შეცდომით მიიჩნევა. არჩევანი ძიებაა და არა თარგმანი: თუ ვარიანტი არ არსებობს, ასარჩევი არაფერია. ამიტომ ერთი და იგივე ტეგი ორ ჰოსტზე შეიძლება ორ სხვადასხვა ბინარულამდე მიგვიყვანოს, ხოლო ერთ ჰოსტზე არც ერთ გამოსადეგ რამემდე.

digest-ით დამაგრება აღმოფხვრის გაურკვევლობას და შესაძლებელს ხდის მოგვიანებით გადახედვასაც, რადგან digest ზუსტად აიდენტიფიცირებს შემოწმებულ ბაიტებს. შეინახეთ ეს digest განლაგების ჩანაწერთან ერთად, იმ ტეგზე დაყრდნობის ნაცვლად, რომელიც შემთხვევით აქტუალური იყო.

ემულაცია შეთანხმებაა და არა თარგმანის ფენა

მხარდაჭერილი გაშვების გარემოს მეშვეობით ემულაციას შეუძლია ზოგიერთი არამშობლიური მომხმარებლის სივრცის დატვირთვის გაშვება, ამიტომ აბსოლუტური მტკიცება, რომ ერთი არქიტექტურა ვერასდროს გაუშვებს მეორის გამოსახულებას, მცდარია. ის ასევე არ არის ზოგადი გადაწყვეტა. ემულირებულ შესრულებას განსხვავებული წარმადობის მახასიათებლები აქვს, და ტრივიალური პროცესი, რომელიც იწყება, არაფერს გეუბნებათ იმაზე, თუ რამდენად მისაღებად იქცევა გვირაბის დატვირთვა.

Docker-ის მრავალპლატფორმიანი სახელმძღვანელო მშობლიურ აწყობას, ჯვარედინ კომპილაციას და ემულაციას ცალკეულ სტრატეგიებად განიხილავს, და ეს არის ვარიანტების წაკითხვის სწორი გზა. აირჩიეთ ერთი განზრახ და შეაფასეთ VPN დატვირთვა მის ქვეშ, ეკვივალენტობის ვარაუდის ნაცვლად.

უფლებები სხვა პრობლემას წყვეტს

ქსელის ადმინისტრირების შესაძლებლობის მიცემა ან TUN მოწყობილობის გატარება ვერ აიძულებს შეუთავსებელ შესრულებად ფაილს იმუშაოს. ეს გაშვების უფლებებია, რომლებსაც მოქმედი პროცესი იყენებს; ისინი უხილავია ჩამტვირთავისთვის, რომელმაც ფაილზე უკვე თქვა უარი.

საპირისპირო თანაბრად მართალია. მშობლიური ბინარული არაფერს ამტკიცებს უფლებებზე, მოწყობილობებზე წვდომაზე, resolver-ის ინტეგრაციაზე ან გადატვირთვის პოლიტიკაზე, რომელიც გვირაბს სჭირდება, ამიტომ მოქმედი კონტეინერი ჯერ არ არის მუშა კონტეინერი. ჯერ დაადგინეთ პლატფორმის ხელშეკრულება, შემდეგ გადადით გაშვების ხელშეკრულებაზე მისი დოკუმენტირებული ვარიანტებით.

შეინახეთ გამოსახულების digest, მხარდაჭერილი სამიზნე და კონფიგურაცია ერთად იმავე ჩანაწერში. არქიტექტურის ჩუმად შემცვლელი ტეგის განახლების დაჭერა უფრო ადვილია, როცა წინა digest ჩაწერილია, ვიდრე მაშინ, როცა ერთადერთი სიმპტომი ნაცნობი შეცდომა და გამართვაზე დახარჯული ახალი შუადღეა.