Aws-cli: सीआई/सीडी परिदृश्यों में उपयोग के लिए एडब्ल्यूएस सीएलआई के साथ एक आधिकारिक डॉकर छवि

मैं यहां इसलिए हूं क्योंकि मैं भी अपने सीआई/सीडी वातावरण में उपयोग करने के लिए एक आधिकारिक aws-cli docker छवि की तलाश में हूं। इसके बजाय अब मैं एक डॉकर छवि बनाने के लिए एक और पाइपलाइन बनाने जा रहा हूं जिसमें एडब्ल्यूएस क्ली शामिल है जब मैं अपनी मूल पाइपलाइन में आधिकारिक एक को संदर्भित कर सकता हूं।

साथ ही... किसी और को भी यह https://hub.docker.com/r/google/cloud-sdk मिल जाता है

@matti और @nscavell , इस विषय पर

धन्यवाद।

क्या +1 को हानिकारक नहीं माना जाता है;)

वैसे भी यह इस बारे में बनाया गया तीसरा (?) मुद्दा है...

👍 मेरा +1 . जोड़ें

मुझे अपने सीआई में केवल awsCLI को शामिल करने के लिए अपनी खुद की डॉकटर छवि बनानी होगी। मैं एक आधिकारिक पसंद करूंगा

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

यहाँ एक अल्पाइन (पोस्ट फिक्स) छवि है जिसमें सबसे हाल ही में क्लि को स्थापित किया गया है जो किसी और के लिए हाल के संस्करण की तलाश में है।

@justnance पर्याप्त?

+1

+1

+1

+1

एक अन्य कारण यह है कि कोरओएस जैसे ओएस का उपयोग करते समय जिसमें कोई पैकेज प्रबंधन नहीं होता है, चीजों को चलाने का मुहावरेदार तरीका एक कंटेनर के माध्यम से होता है। मुझे आश्चर्य है कि इसकी आवश्यकता पर भी सवाल उठाया जाएगा, यह एक स्पष्ट चूक है। मैं

+1

:+1:

+1

+1

+1

+1

+1

#3291 के ओपनर के रूप में (तीन उद्धृत इश्यू लोल में से सबसे पहले), मुझे यह देखकर खुशी हो रही है कि यह मुद्दा आखिरकार कर्षण प्राप्त कर रहा है। भविष्य के सभी उत्तरदाताओं के लिए, जब @justnance कहते हैं, "कृपया इसे रुचि दिखाने के लिए +1 करें", तो उनका मतलब है कि पहली टिप्पणी पर एक पसंद जोड़ें, यह GitHub पर चीजों को +1 करने का उचित तरीका है ताकि आप अनुरक्षकों के मेलबॉक्स को स्पैमिंग नहीं कर रहे हैं .

रेपो मालिकों को सूचित रखने के लिए +1

+1

जब वे +1 कोई समस्या कहते हैं, तो उनका मतलब बटन पर क्लिक करना होता है। यह डेवलपर्स को 100 टिप्पणियों में मदद नहीं करता है जो प्रत्येक "+1" कहते हैं। जितना अधिक आप जानते हैं!

@ डेविडम - स्पष्टीकरण के लिए धन्यवाद और प्रतिक्रिया देने के लिए सभी को धन्यवाद। मैं उसका समर्थन करता हूं। कृपया GitHub प्रतिक्रियाओं का उपयोग करें और बटन पर क्लिक करें।

मैंने 2 दिन पहले भी यही कहा था लेकिन हम सब एक ही तरफ हैं

+1

+1

+1

+1

+1

+1

+1

क्या आप +1 को रोक सकते हैं? यदि आप +1 करना चाहते हैं, तो इसे शीर्ष पर करें।

आप बहुमूल्य इंजीनियर समय बर्बाद कर रहे हैं। हम इस मुद्दे पर दर्जन भर सदस्यता ले चुके हैं...

मैं दो साल से अधिक समय से aws-cli छवि बनाए हुए हूं। जरूरत पड़ने पर बेझिझक इसका इस्तेमाल करें (मैं इसे दिन में कई बार इस्तेमाल करता हूं)। मुझे नए संस्करण रिलीज (आईएफटीटी के माध्यम से) पर अपडेट प्राप्त होते हैं और अपडेट को काफी तेज़ी से धक्का देते हैं। अपनी खुद की छवि (हा!) चलाने की प्रसिद्धि और महिमा के बावजूद, मैं आधिकारिक छवि का उपयोग करने के लिए लोगों को _ग्लैडली_ टाल दूंगा और धक्का दूंगा।

• गिटहब रेपो
• डोकर हब

लंबे समय तक मेरी छवि का उपयोग करने के बाद, मैं कहूंगा कि यह _super_ सहायक होगा यदि आधिकारिक छवि में jq (क्योंकि API JSON भारी है)। यह एक सीआई/सीडी पाइपलाइन चरण में "नवीनतम ईसीएस कार्य परिभाषा को पकड़ो, परिवर्तन करें, और इसे पीछे धकेलें" जैसी चीजों को करने के लिए सुपर सुविधाजनक बनाता है।

समस्या का एक और वैकल्पिक समाधान: https://hub.docker.com/r/somedeveloper/aws-cli/

उपयोग करने के कारण:

• सरल रखता है।
• आधार छवि के रूप में आधिकारिक पायथन 3.7-खिंचाव का उपयोग करता है।
• स्थापना के लिए एडब्ल्यूएस अनुशंसित रणनीति का उपयोग करता है - पायथन + पीआईपी। यहाँ देखें ।
• उन सर्वर रहित नर्ड 8- के लिए aws-sam-cli शामिल है)।
• यह सार्वजनिक है और इसके लिए लॉगिन की आवश्यकता नहीं है।
• सीआई/सीडी पाइपलाइनों के लिए बढ़िया - किसी और चीज के लिए इसका इस्तेमाल नहीं किया है, इसलिए पेशेवरों और विपक्षों का वजन नहीं किया है।

अभी भी एक आधिकारिक छवि की उम्मीद है। अब लोगों के बारे में सोचो

https://hub.docker.com/r/google/cloud-sdk/ । क्षमा करें दोस्तों। AWS जैसे दिग्गज के लिए ऐसा करना बहुत कठिन काम है।

+1

क्या +1 को हानिकारक नहीं माना जाता है;)

वैसे भी यह इस बारे में बनाया गया तीसरा (?) मुद्दा है...

चौथा, यदि आप https://github.com/aws/amazon-linux-docker-images/issues/10 पर विचार करते हैं

क्या हम इसे सिर्फ CircleCI में नहीं डाल सकते और इसके साथ काम नहीं कर सकते? Dockerfile या पाइपलाइन के साथ मदद करने में प्रसन्नता हो रही है।

मुझे आश्चर्य है कि अमेज़ॅन के अंदर कोई आंतरिक प्रतिबंध और/या कागजी कार्रवाई है जो डेवलपर्स को इस मामूली काम को पूरा करने से दूर रखती है ...

के लोल

कुछ प्रकार हैं जो "आधिकारिक" छवि में होना अच्छा होगा। उदाहरण के लिए, मैं वर्तमान में एडब्ल्यूएस क्ली और कर्ल (आईएएम मेटाडेटा एंडपॉइंट की जांच करने के लिए) के साथ एक कंटेनर को पकड़ने की तलाश में हूं और यह वास्तव में आसान होगा जिसे मैं बस पकड़ सकता हूं और मेरे के 8 एस परिनियोजन में प्लग कर सकता हूं।

आधिकारिक चित्र प्रदान करने का एक सुरक्षा कारण भी है।

यह "इंटरनेट पर यादृच्छिक व्यक्ति" पर निर्भरता को हटाकर खतरे के मॉडल को सरल बनाता है जो छवि को बनाए रखता है जिसका उपयोग सीआई/सीडी पाइपलाइनों जैसे उच्च मूल्य लक्ष्यों में किया जाता है जो आमतौर पर आपके सिस्टम तक बहुत अधिक पहुंच प्रदान करते हैं।

मुझे डॉकर से आधारित एक आधिकारिक एडब्ल्यूएस-क्ली डॉकर छवि चाहिए : 18 (वर्तमान स्थिर) छवि (https://hub.docker.com/_/docker) - उदाहरण के लिए। एडब्ल्यूएस-क्ली-डॉकर-18 क्योंकि मैं अपने सीआई/सीडी वातावरण में अपनी डॉकर छवि बनाना चाहता हूं जो वर्तमान में docker:18 छवि का उपयोग करता है और इसे एडब्ल्यूएस ईसीआर में प्रकाशित करता है।

+1

+1

यह बहुत अच्छा होगा अगर लोग टिप्पणी करने से परहेज करेंगे जब उनकी टिप्पणी हाथ में इस मुद्दे पर योगदान नहीं देगी। "+1" जैसी टिप्पणियां केवल ग्राहकों के लिए स्पैम का परिचय देती हैं और समस्या को आवश्यकता से अधिक लंबा कर देती हैं। इसके बजाय, मुद्दे की पहली टिप्पणी के लिए एक अंगूठा दें।

यह बहुत अच्छा होगा अगर लोग टिप्पणी करने से परहेज करेंगे जब उनकी टिप्पणी हाथ में इस मुद्दे पर योगदान नहीं देगी। "+1" जैसी टिप्पणियां केवल ग्राहकों के लिए स्पैम का परिचय देती हैं और समस्या को आवश्यकता से अधिक लंबा कर देती हैं। इसके बजाय, मुद्दे की पहली टिप्पणी के लिए एक अंगूठा दें।

यह इश्यू पिछले साल सितंबर से खुला है। मुझे लगता है कि हमें एडब्ल्यूएस से इस मुद्दे पर फिर से विचार करने के लिए कहने की जरूरत है, क्योंकि इसमें स्पष्ट रूप से रुचि है। हमें बताया जाना चाहिए कि "पर्याप्त" कितना ब्याज है।

चूंकि इसमें स्पष्ट रूप से रुचि है

न केवल रुचि, बल्कि अधिक के साथ खुला मुद्दा है: +1: प्रतिक्रियाएं :

https://github.com/aws/aws-cli/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

सबसे अधिक प्रतिक्रियाओं वाला दूसरा 2014 में और तीसरा 2015 में खोला गया था, जबकि यह अंक 2018 के सितंबर में ( एक साल से भी कम समय पहले ) खोला गया था।

+1000

मेरे पास मेरी स्थानीय मशीन पर हर समय एडब्ल्यूएस-क्ली काम करने के लिए सही निर्भरता स्थापित करने के मुद्दे हैं। इसलिए मैंने docker के अंदर aws-cli पर स्विच करने का निर्णय लिया। मुझे डॉकर-हब पर कई सार्वजनिक रूप से उपलब्ध छवियां मिलीं, लेकिन क्योंकि वे आधिकारिक नहीं हैं, मुझे डिफ़ॉल्ट रूप से उन पर भरोसा नहीं है, इसलिए हर बार एक अद्यतन संस्करण उपलब्ध होने पर मुझे एक ऐसी छवि को खोजना और ढूंढना होगा जिस पर भरोसा किया जा सके। और उपयोग करने के लिए सुरक्षित है। कृपया एडब्ल्यूएस डॉकर हब के माध्यम से एक सुरक्षित एडब्ल्यूएस-क्ली डॉकर छवि बनाएं, बनाए रखें और प्रदान करें। अग्रिम में धन्यवाद

समुदाय का एक बड़ा विखंडन aws-cli छवियां प्रदान करता है। लेकिन, जैसा कि पहले उल्लेख किया गया है: लोग उसे पसंद करेंगे जो आधिकारिक तौर पर अमेज़ॅन द्वारा बनाए रखा और समर्थित हो। कई कारण क्यों:

1) बासी नहीं होंगे -- सामुदायिक छवियां अंततः बासी होने के लिए कुख्यात हैं;
2) अधिक सुरक्षित -- यह एक विश्वसनीय संसाधन से है, चाहे समुदाय का सदस्य कितना भी भरोसेमंद क्यों न हो, वे आधिकारिक तौर पर अमेज़ॅन का प्रतिनिधित्व नहीं करते हैं, इसलिए "सभी वारंटी शून्य" हैं;
3) आधिकारिक समर्थन का मतलब बग, संस्करण संघर्ष, पिछली संगतता आदि की स्थिति में आधिकारिक समर्थन है।
4) AWS अपनी छवि को अपडेट कर सकता है क्योंकि वे ऐतिहासिक टैग सहित aws cli को अपडेट करते हैं।

+1

+1 यह वास्तव में दुर्भाग्यपूर्ण है कि अमेज़ॅन इसे प्रदान नहीं करता है

मैंने तब से एक और छवि जोड़ी है जो काम में आई है। यह डॉकर में डॉकर को एडब्ल्यूएस और एसएएम सीएलआई के साथ जोड़ती है जो एक संपूर्ण ईसीआर एकीकरण के लिए बनाता है।

डिंड-एज़-क्ली

+1

जबकि वहाँ बहुत सारी अनौपचारिक छवियां हैं जिन्हें अच्छी तरह से बनाए रखा गया है, उन्हें एक दिन यह कहने से रोकने के लिए क्या है "पीएफएफटी, अब इसे अपडेट करने का क्या मतलब है। यह अमेज़ॅन का काम है!"

+1

+1

जब एडब्ल्यूएस के साथ लोगों को अपने काम को स्वचालित करने में मदद करने की बात आती है, तो अमेज़ॅन बड़े समय से विफल हो रहा है, यही एक कारण है कि हम उन्हें छोड़ने की सोच रहे हैं।

क्या यह अभी तक रोड मैप पर है या नहीं, इस बारे में अनुरक्षकों की ओर से कोई आधिकारिक प्रतिक्रिया है? कई अन्य लोगों की तरह, मैं भी आधिकारिक छवि का उपयोग करना पसंद करूंगा...

+1

अगर एडब्ल्यूएस सीएलआई के लिए कोई आधिकारिक छवि होती तो यह एक स्क्रैच कंटेनर के अंदर एक निष्पादन योग्य बैठती थी। क्योंकि यह व्यक्तियों के लिए अविश्वसनीय रूप से उपयोगी नहीं होगा, जो सबसे अच्छा हो सकता है:

• स्रोत से सीएलआई बनाने के लिए आधिकारिक पायथन कंटेनर का प्रयोग करें
• परिणामी AWS CLI बाइनरी को एक बिजीबॉक्स या स्क्रैच कंटेनर में कॉपी करें

यहां होने वाली किसी भी बहस के बावजूद कुछ भी ओवर-इंजीनियरिंग होगा।

AWS को अपनी सभी ECR और CodeDeploy सेवाओं का प्रदर्शन करना पसंद है। वे उस सारी मारक क्षमता को अपने स्वयं के कंटेनरीकृत सीएलआई पर क्यों नहीं इंगित करेंगे?

क्योंकि मेज पर प्रस्ताव ऐसा लगता है कि इसे बनाए रखने के लिए समुदाय के किसी व्यक्ति के लिए है।

@balibebas समुदाय का कोई व्यक्ति पहले से ही ऐसा कर रहा है। वहाँ छवियों का एक टन है - लेकिन यहाँ बिंदु यह है कि AWS द्वारा एक होगा, क्योंकि मैं अपने CI वातावरण में randomguy/aws-cli:canbechangedanytime नहीं चलाना चाहता, जिसमें सभी रहस्य खुले हों।

तब आप F-Droid के बारे में क्या कहेंगे?

यह इस बिल्ली के रूप में इस मुद्दे के लिए प्रासंगिक है:

आप भुगतान करने वाले ग्राहक की तरह लगते हैं।

ठीक है शायद ऐसा इसलिए है क्योंकि _I_ _am_

गाने बजने वालों को उपदेश। वैसे भी ब्रू फॉर्मूला का एक बेहतर मौका था क्योंकि इसे लंबे समय तक ट्रोल किया गया था, फिर भी बिना किसी हलचल के। इसलिए बिल्ली की तस्वीरें तुरंत काउंटर प्रोडक्टिव हो जाती हैं, जब कोई सामान्य उपयोग का मामला नहीं होता है, शायद स्क्रैच या बिजीबॉक्स कंटेनर जैसा कि मैंने पहले बताया था। आपका डिजाइन प्रस्ताव क्या है?

मैं और कई अन्य वर्तमान में "बिजीबॉक्स कंटेनर" कर रहे हैं उदाहरण के लिए इसे ईसीआर ऑथ प्रमाण-पत्र प्राप्त करने के लिए डॉकर के साथ चलाने के लिए। यह देखते हुए कि aws के पास कितनी docker चीज़ें हैं, इसका कोई मतलब नहीं है कि कोई आधिकारिक पैकेजिंग मौजूद नहीं है।

हो सकता है कि वे बस किसी और चीज़ पर हों। ;)

मुझे खुशी है कि हमने अब इसे सुलझा लिया है। +1 टिप्पणियों पर वापस जाएं:

डॉकरलेस के लिए +1

@matti @balibebas ध्यान रखें कि इस समय इस मुद्दे की बातचीत में अकेले 64 लोग हैं, और प्रत्येक प्रतिक्रिया एक अनुपयोगी ईमेल और अधिसूचना को ट्रिगर करती है जो संभावित रूप से उन 64 लोगों में से प्रत्येक को भेजी जाती है और अधिक सदस्यता ली जाती है। यह संदेश वही करेगा, और मैं इसके लिए क्षमा चाहता हूं।

लेकिन वास्तव में, कृपया चीजों को पेशेवर रखें। जबकि बिल्ली की तस्वीरें अच्छी हैं, आगे यह धागा रेल से दूर हो जाता है, मुझे लगता है कि अनुरक्षकों द्वारा इसे गंभीरता से लेने की संभावना कम है। दुर्भाग्य से, स्पैम स्पैम है स्पैम है।

सदस्यता समाप्त बटन यही करता है, जिसे मैंने अभी क्लिक किया है।

होना अच्छी बात होगी। मुझे केवल आश्चर्य है कि कोई कार्रवाई नहीं की जा रही है या इसे बनाए रखा जा रहा है (नहीं कहा जा रहा है)।
वैसे भी ऊपर के लोगों ने एक आधिकारिक एडब्ल्यूएस क्ली इमेज के महत्व को ठीक ही बताया है।
मुझे लगता है कि लोग पहले से ही निजी तौर पर या किसी और की निर्मित छवि/पैकेज प्रबंधक मार्ग आदि के माध्यम से स्वयं का उपयोग कर रहे हैं।
उसी के लिए एक और उदाहरण स्क्रिप्ट

लेकिन सबसे सरल और अपरिहार्य समस्या वही रहती है।

• निर्भरताओं और अनिश्चितताओं की कभी न खत्म होने वाली सूची जो डेवलपर्स पर निर्भर करती है कि वे चीजों को स्वयं एकीकृत करें। अंततः रेपो में और अधिक समस्याएं पैदा होंगी क्योंकि लोग पर्यावरण को दूषित करने के लिए एक चीज स्थापित करने के साथ शुरू करेंगे और फिर कुछ अन्य काम करेंगे जो सीआई / सीडी या अलग-थलग और प्राचीन होने के समान कार्यों के उद्देश्य को हरा देता है।
• अपने काम के लिए किसी और की डॉकटर छवि को लागू करने और ट्रैक करने के लिए भरोसा करना मुश्किल है। यह नई awscli छवि के लिए डॉकटर रजिस्ट्री में एक और पाइपलाइन और प्रविष्टि जोड़ने की ओर जाता है, एक और भंडार यानी बनाए रखने के लिए एक और चीज।
• सीआई/सीडी में, मेरी प्राथमिकता केवल छवि (हमारे आंतरिक या आधिकारिक) का उपयोग करना है और जितना संभव हो सके चीजों को जोड़ने के लिए स्क्रिप्टिंग लाइनों से बचना है।
• आधिकारिक छवि के रूप में निर्माण और libs के साथ समस्या तुरंत स्रोत रिलीज से ही बनाई जा सकती है और कम गतिशील निर्भरता wrt पैकेज प्रबंधक और क्या नहीं है।

अन्यथा
=> हर कोई अपना बना लेता है।

यहां वही है, वर्तमान में मैं एक स्वयं निर्माण छवि का उपयोग करता हूं, लेकिन इसके तहत एक आधिकारिक छवि पसंद करूंगा

• https://hub.docker.com/_/awscli

नाम स्थान। मैं इसका उपयोग अन्य डॉकटर छवियों को बनाने और उन्हें ईसीआर पर धकेलने के लिए करता हूं, जहां साख प्राप्त करने के लिए awscli की आवश्यकता होती है।

FROM docker:18.06

RUN apk update && \
apk -Uuv add python py-pip && \
pip install awscli && \
apk --purge -v del py-pip && \
rm /var/cache/apk/*

इसे अपनी awscli बिल्ड पाइपलाइन में जोड़ना इतनी बड़ी बात नहीं होनी चाहिए ... :)

--

मैंने डॉकरफाइल को @ mikesir87 सुझाव के अनुसार अपडेट किया है, इसके लिए thx (यह एक और कारण है कि छोटी छवि प्राप्त करने के लिए

सभी को स्पैम करने के लिए खेद है, लेकिन यह बताना चाहता था (यदि कोई अन्य @jens-meiss के स्निपेट का उपयोग करना चाहता है) कि आपको _really_ अपने तीन RUN कथनों को एक ही कथन में शामिल करने पर विचार करना चाहिए। अन्यथा, आप अभी भी py-pip और मध्यवर्ती परतों में एपीके कैश के आसपास शिपिंग कर रहे हैं, भले ही आपका अंतिम कंटेनर उन तक नहीं पहुंच सकता।

एक और नोट पर, टिप्पणी एक और वैध उपयोग के मामले को सामने लाती है ... जब आप छवियों को धक्का देने के लिए ईसीआर के लिए प्रमाण-पत्र प्राप्त करने के लिए केवल एडब्ल्यूएस-क्ली का उपयोग कर रहे हैं। यह एक छवि में भी ईसीआर क्रेडेंशियल हेल्पर को पैकेजिंग करने की आवश्यकता की तरह लगता है। यह निश्चित रूप से पूर्ण aws-cli की आवश्यकता के बिना छवियों को बनाना और धक्का देना आसान बना देगा।

हाय सब लोग, यहाँ अनुरक्षक। बस स्पष्ट करना चाहता था, यह हो रहा है, हम यह कर रहे हैं।

हम आंतरिक रूप से बेहतर रिलीज़ अवसंरचना के निर्माण की प्रक्रिया में हैं, ताकि हम अधिक प्रकार के रिलीज़ आर्टिफ़ैक्ट्स का निर्माण/परीक्षण/समर्थन कर सकें, विशेष रूप से जब हम cli v2 के लिए अधिक रिलीज़ आर्टिफ़ैक्ट्स की शिपिंग करेंगे।

फिलहाल हमारे पास सटीक समयरेखा नहीं है, लेकिन ऐसा हो रहा है।

अमेज़ॅन डेवलपर्स और कई अन्य लोगों के अनुसार करना आसान है, फिर भी 2 साल बाद भी इंतजार कर रहा है और कोई ईटीए नहीं है

+1

इंटरनल रिलीजिंग इंफ्रास्ट्रक्चर (2019 Q4)
लीगल टीम असेसमेंट (2020 Q1)
एडब्ल्यूएस/क्ली-देव-टेस्ट (2020 क्यू2) के तहत सार्वजनिक बीटा
अंतिम रिलीज (2020 Q3)

इस आशावादी समय में, आपको 10 महीने से भी कम समय में वह मिलेगा जो आप चाहते हैं। मैं

जेफ बार्स ब्लॉग पोस्ट की प्रतीक्षा कर रहा है

मैं इसका बेसब्री से इंतजार कर रहा हूं।

क्या हमें कम से कम आधिकारिक घोषणा या प्रतिबद्धता मिल सकती है। शायद एक लक्ष्य रिलीज?

@bhmckendrick एक प्रतिबद्धता है न कि यह वह टिप्पणी है जो आपकी टिप्पणी से बहुत ऊपर नहीं है?

https://github.com/aws/aws-cli/issues/3553#issuecomment -519280276

एक साल से अधिक पुराना और कोई अपडेट नहीं? छवि?

अरे @jamesls , क्या आप इस धागे को तब तक हार्ड-लॉक करने पर विचार करेंगे जब तक आपके पास साझा करने के लिए कुछ न हो?

पढ़ने के लिए पूरी तरह से अनिच्छुक लोगों की संख्या ( संकेत संकेत ) और इसके बजाय 70+ दर्शकों को स्पैम करने के लिए चुनना कि वे कैसे _specifically_ नाराज हैं, मुझे यकीन है, इस धागे का पालन करने में सभी की रुचि को काफी कम कर रहा है।

इसके अलावा, ऐसा करने की दिशा में आपके काम के लिए धन्यवाद!

इस मुद्दे के मूल लेखक के रूप में (ठीक है, मैं पहले से बंद "वोंटफिक्स" वाले को कॉपी/पेस्ट करने के लिए पर्याप्त बहादुर था) बड़े पैमाने पर +1 स्पैम और बिल्ली चित्रों के साथ कभी-कभी झगड़े के कारण मैंने पहले ही इस मुद्दे से सदस्यता समाप्त कर दी है (क्षमा करें) .

बस सूचना सेटिंग समायोजित करें ताकि आपको केवल तभी सूचनाएं प्राप्त हों जब यह समस्या बंद हो।

मैं केवल यह बताना चाहता हूं कि सीआई/सीडी से अलग, कुछ डेवलपर्स (देखें @LongLiveCHIEF), विकास के वातावरण को डॉकटराइज़ करना पसंद करते हैं, और चीजों को मूल रूप से स्थापित करना पसंद नहीं करते हैं, या आगामी संस्करण प्रबंधकों के साथ सौदा करना पसंद नहीं करते हैं। मूल भाषाएं उन क्ली टूल्स पर अनिवार्य रूप से भरोसा करती हैं।

मौजूदा इंस्टॉल चरणों की तुलना में docker pull aws-cli लिए यह आसान है ... उल्लेख नहीं है कि यदि आप एक पायथन डेवलपर नहीं हैं, तो आपके पास अपने उपयोगकर्ता के लिए एक अच्छा पायथन संस्करण और पर्यावरण स्थापित करने का ओवरहेड है, या शायद यहां तक ​​कि प्रत्येक परियोजना।

स्केल करें कि एक डेवलपर द्वारा उपयोग किए जाने वाले सभी अलग-अलग टूल (रूबी आधारित क्ली, नोड आधारित क्ली), और आपको उन भाषाओं के लिए पर्यावरण सेटअप सीखना होगा जिन्हें आप कभी भी कोड नहीं कर सकते हैं।

मैं यहां जो बिंदु बना रहा हूं वह यह है कि डॉकर रन सर्वव्यापी है, और किसी भी मूल भाषा सेटअप/कॉन्फ़िगरेशन से छुटकारा पाता है, और उपयोगकर्ताओं के लिए चीजों को आसान बनाता है।

यहां तक ​​​​कि अगर उपयोगकर्ता अपनी खुद की डॉकटर छवियां बनाते हैं, तब भी उन्हें उन सेटअप कार्यों के साथ संघर्ष करना पड़ता है।

मैं अजगर में कोड नहीं करता, लेकिन मुझे आभासी वातावरण के ins और बहिष्कार और अजगर के विभिन्न संस्करणों से उनकी सर्वोत्तम प्रथाओं को सीखने के लिए मजबूर किया गया है, विशुद्ध रूप से क्योंकि उपकरण प्रदाता इसे "तुच्छ" मानते हैं।

सभी डेवलपर्स की पृष्ठभूमि समान नहीं होती है, जिन्होंने टूल बनाया था, और डॉकर छवि प्रदान करना सम्मान का संकेत है। उपकरण प्रदाता बहुत जल्दी और आसानी से मूल भाषा विशिष्ट वातावरण के उपरिव्यय का सामना कर सकते हैं, जबकि अपनाने वालों को आपके उत्पाद के साथ विकास के विभिन्न जीवनचक्र चरणों के माध्यम से इस ओवरहेड को प्रबंधित करने के लिए अधिक समय व्यतीत करना पड़ता है।

हालांकि के लिए भोजन।

@jamesls यहां समुदाय की प्रतिक्रिया सुनने के लिए धन्यवाद। आधिकारिक होस्ट किए गए डॉकर छवियों की प्रतीक्षा करते समय, कुछ लोकप्रिय आधार डॉकर छवियों (जैसे नोड, अल्पाइन, उबंटू, अमेज़ॅन 2, पायथन) के लिए इंस्टॉल अनुशंसाएं पोस्ट करने के लिए एक सहायक मध्यवर्ती कदम हो सकता है। यह हमारे लिए तुरंत मूल्यवान होगा।

जैसा कि मैं बड़े गधे के उद्यम के लिए काम करता हूं, मुझे इसके साथ आपकी सेवा करने दें:
https://github.com/aws/aws-codebuild-docker-images
https://hub.docker.com/r/amazon/aws-codebuild-local

यह अच्छी तरह से रखरखाव की तरह नहीं दिखता है, लेकिन यहां एक और है

https://hub.docker.com/r/amazon/lambda-build-node10.x

मैंने इसे अभी जंगली में देखा है: https://hub.docker.com/r/amazon/aws-cli

ऐसा लगता है कि यह अंत में यहाँ है :)

@pablosjv यह आधिकारिक या प्रमाणित छवि नहीं है। इससे अवगत रहें।

@anjakammer ऐसा लगता है कि यह एक आधिकारिक अमेज़ॅन छवि है , भले ही यह डॉकर द्वारा प्रकाशित आधिकारिक छवि नहीं है।

मुझे नहीं पता कि क्या इसका उत्पादन कठिन है, क्योंकि उन्होंने इस मुद्दे पर अभी तक कुछ नहीं कहा है।

उत्सुक है कि यह एडब्ल्यूएस छवि 98.42 एमबी कैसे है जबकि अन्य (उदाहरण के लिए एटलसियन/पाइपलाइन-awscli ) बहुत छोटी हैं।

https://aws.amazon.com/blogs/developer/aws-cli-v2-docker-image/

यहां सीएलआई टीम के सदस्य। हां, मैं पुष्टि कर सकता हूं कि हमने आधिकारिक तौर पर AWS CLI v2 के लिए एक डॉकर छवि लॉन्च की है! मैं निम्नलिखित पढ़ने की सलाह देता हूं:

• ब्लॉग पोस्ट इसका परिचय: https://aws.amazon.com/blogs/developer/aws-cli-v2-docker-image/
• उपयोगकर्ता गाइड प्रविष्टि: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html
• डॉकरहब भंडार: https://hub.docker.com/r/amazon/aws-cli

मैं इस मुद्दे को खत्म करने जा रहा हूं। यदि आपके पास छवि के बारे में प्रतिक्रिया या प्रश्न हैं, तो कृपया इस रिपॉजिटरी में एक और गिटहब मुद्दा खोलें।

मूल अंक #3291 के उद्घाटनकर्ता के रूप में, कई साल पहले, मेरा दर्द ❤️ मेरी चिंताओं को अंततः सत्यापित करने के लिए इस तरह की खुशी से भर गया है, और अब एक आधिकारिक डॉकर छवि उपलब्ध है। इस छवि को एक तरफ बनाने में कितना समय लगा, इसके बारे में पॉट शॉट्स, मुझे यकीन है कि यह कहने की तुलना में बहुत आसान था, इसलिए ऐसा करने वाले अमेज़ॅन देवों के लिए एक बड़ा धन्यवाद। आप सभी बेहतरीन काम करते हैं। मैं

_ठीक है एलेक्सा, मैंने उन्हें धन्यवाद दिया, कृपया मेरे परिवार को अभी जाने दें।_

क्या Dockerfile कहीं भी उपलब्ध है?

@zerkms आह, इसे v2 शाखा में मिला:
https://github.com/aws/aws-cli/blob/v2/docker/Dockerfile

मुझे लगता है कि वे अंततः इसे कर रहे हैं, लेकिन मैं इसे Gitlab CI https://hub.docker.com/r/amazon/aws-cli पर नहीं चला सका

मैं इसके बजाय गिटलैब की एडब्ल्यूएस सीएलआई डॉकर छवि का उपयोग कर रहा हूं, और यह पूरी तरह से काम करता है। महज प्रयोग करें

image: registry.gitlab.com/gitlab-org/cloud-deploy:latest

अपडेट करें:

उपरोक्त छवि को हटा दिया गया है, इसके बजाय नए का उपयोग करें।

image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest

ध्यान दें कि GitLab CI पर छवि का उपयोग करने के लिए, आपको मैन्युअल रूप से एक खाली प्रविष्टि बिंदु सेट करना होगा, क्योंकि amazon/aws-cli छवि प्रवेश बिंदु को /usr/local/bin/aws सेट करती है। एक उदाहरण...

image:
    name: amazon/aws-cli
    entrypoint: [""]

@ mikesir87 ऐसा क्यों है?

@pSnehanshu मुझे लगता है कि ऐसा इसलिए है क्योंकि आप छवि को चलाने के रूप में अगर यह CLI ही है, की तरह था docker run --rm amazon/aws-cli <<command>> , जिसके साथ CLI चल करने के समान होगा aws <<command>> , के बजाय docker run --rm amazon/aws-cli aws <<command>> . प्रत्येक दृष्टिकोण के साथ पेशेवरों और विपक्ष हैं, जो आप पसंद करते हैं, और जिस तरह से आप छवि चलाते हैं, उसके आधार पर, लेकिन प्रवेश बिंदु को ओवरराइड करने से वैसे भी चाल चलनी चाहिए।

@lucasbasquerotto मैं वैसे भी Gitlab की छवि के लिए बस गया हूँ। वैसे भी, स्पष्टीकरण के लिए धन्यवाद।

यदि कोई अभी भी AWS CLI v2 को अल्पाइन लिनक्स पर काम करने में रुचि रखता है, तो यहाँ एक उदाहरण Dockerfile है:

FROM alpine:3.11 AS builder

ENV GLIBC_VER=2.31-r0

# install glibc compatibility for alpine
RUN apk add --no-cache --virtual .build-deps \
        binutils \
        curl
RUN curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub
RUN curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk
RUN curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk
RUN apk add --no-cache \
        glibc-${GLIBC_VER}.apk \
        glibc-bin-${GLIBC_VER}.apk

# install AWS CLI
RUN curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip
RUN unzip awscliv2.zip
RUN aws/install

FROM alpine:3.11
MAINTAINER Barry Lagerweij
RUN apk --update --no-cache --virtual .build-deps add \
    groff \
    && rm -rf /var/cache/apk/*
COPY --from=builder /usr/local/aws-cli/ /usr/local/aws-cli/
COPY --from=builder /usr/local/bin/ /usr/local/bin/
COPY --from=builder /usr/lib/ /usr/lib/
COPY --from=builder /lib64 /lib64
COPY --from=builder /usr/glibc-compat/ /usr/glibc-compat/
COPY --from=builder /lib/ld-linux-x86-64.so.2 /lib/

समस्या यह थी कि AWS CLI v2 GLIBC का उपयोग करता है, लेकिन अल्पाइन लिनक्स के पास GLIBC समर्थन सीमित है (यह एक हल्के वजन वाले विकल्प 'musl' का उपयोग करता है)। उपरोक्त Dockerfile लापता glibc लाइब्रेरी को स्थापित करता है, और अंतिम छवि को छोटा रखने के लिए एक बहु-चरण Dockerfile का उपयोग करता है। थोड़े से प्रयास से, हम संभवतः केवल /usr/lib की फाइलों को शामिल करके छवि के आकार को और भी कम कर सकते हैं जो वास्तव में आवश्यक हैं।

कुछ रिफैक्टरिंग के बाद, मैं छवि आकार को और भी कम करने में कामयाब रहा हूं:

FROM alpine:3.11

ENV GLIBC_VER=2.31-r0

# install glibc compatibility for alpine
RUN apk --no-cache add \
        binutils \
        curl \
    && curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub \
    && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk \
    && curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk \
    && apk add --no-cache \
        glibc-${GLIBC_VER}.apk \
        glibc-bin-${GLIBC_VER}.apk \
    && curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip \
    && unzip awscliv2.zip \
    && aws/install \
    && rm -rf \
        awscliv2.zip \
        aws \
        /usr/local/aws-cli/v2/*/dist/aws_completer \
        /usr/local/aws-cli/v2/*/dist/awscli/data/ac.index \
        /usr/local/aws-cli/v2/*/dist/awscli/examples \
    && apk --no-cache del \
        binutils \
        curl \
    && rm glibc-${GLIBC_VER}.apk \
    && rm glibc-bin-${GLIBC_VER}.apk \
    && rm -rf /var/cache/apk/*

स्वत: पूर्ण अनुक्रमणिका और उदाहरण फ़ाइलें हटा दी जाती हैं, और 'ग्रॉफ़' भी हटा दी जाती है (मुझे लगता है कि लोगों को उनकी डॉकर छवियों में सहायता पृष्ठों की आवश्यकता नहीं है)

यह बहुत आसान है, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile और काम करता है लेकिन मुझे मेरे जीथब मुद्दों के माध्यम से बताएं यदि छवि में कुछ और की आवश्यकता है (वैध उपयोग मामला)।

यह बहुत आसान है, https://github.com/flaccid/docker-awscli/blob/master/Dockerfile और काम करता है लेकिन मुझे मेरे जीथब मुद्दों के माध्यम से बताएं यदि छवि में कुछ और की आवश्यकता है (वैध उपयोग मामला)।

उपरोक्त एपीके एडब्ल्यूएस-सीएलआई 1.18 पर आधारित है, न कि वी2 सीएलआई पर।

किसी भी मौके पर अमेज़ॅन सीएलआई के संस्करण 1 के साथ एक छवि बनाने पर विचार करेगा?

@keeganwitt आपको उस अनुरोध के लिए एक नया अंक खोलना चाहिए। :+1: