Aws-cli: صورة Docker رسمية مع AWS CLI للاستخدام في سيناريوهات CI / CD

تم إنشاؤها على ٩ سبتمبر ٢٠١٨  ·  121تعليقات  ·  مصدر: aws/aws-cli

قرأت العدد # 3529 و # 3291 ورأيت أنهما مغلقان ، مع رد الفعل الوحيد الذي يلمح إلى أنه "ليس بهذا التعقيد". ومع ذلك ، أقر التعليق أيضًا أن القيام بذلك بنفسك قد يكون مخاطرة بأن يصبح قديمًا. بصرف النظر عن هذه النقطة بالضبط ، أود أيضًا أن أشير إلى أنه بالنسبة للمستخدمين التجاريين ، فإن الحصول على صورة رسمية من أمازون يعد تفضيلًا كبيرًا على "/ aws- cli : الأحدث ".

في حالتي ، سأستخدم هذا في Google Cloud Build لأنه أفضل بكثير من AWS CodeBuild.

feature-request

التعليق الأكثر فائدة

matti و nscavell ، شكرًا لك على المتابعة في هذا الموضوع. يبدو أن هناك اهتمامًا كافيًا بطلب الميزة هذا لإبقاء هذا مفتوحًا. سيتم استخدام هذه المشكلة لتتبع صورة Docker الرسمية لـ AWS CLI. الرجاء إجراء 1+ عليه لإظهار الاهتمام ومساعدتنا في تحديد أولويات ذلك.

شكرا.

ال 121 كومينتر

أنا هنا لأنني أيضًا أبحث عن صورة عامل إرساء AWS-cli رسمية لاستخدامها في بيئة CI / CD الخاصة بي. بدلاً من ذلك ، سأقوم الآن بإنشاء خط أنابيب آخر لبناء صورة عامل إرساء تتضمن aws cli عندما يمكنني فقط الإشارة إلى الصورة الرسمية في خط الأنابيب الأصلي الخاص بي.

أيضًا ... يحصل عليها شخص آخر أيضًا https://hub.docker.com/r/google/cloud-sdk.

matti و nscavell ، شكرًا لك على المتابعة في هذا الموضوع. يبدو أن هناك اهتمامًا كافيًا بطلب الميزة هذا لإبقاء هذا مفتوحًا. سيتم استخدام هذه المشكلة لتتبع صورة Docker الرسمية لـ AWS CLI. الرجاء إجراء 1+ عليه لإظهار الاهتمام ومساعدتنا في تحديد أولويات ذلك.

شكرا.

لا يعتبر +1 ضارًا ؛)

على أي حال ، هذه هي المشكلة الثالثة (؟) التي تم إنشاؤها حول هذا ...

👍 أضف +1 الخاص بي

لا بد لي من إنشاء صورة عامل الإرساء الخاص بي لتضمين awsCLI فقط في CI الخاص بي. أنا أفضل واحدة رسمية

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

إليك صورة جبال الألب (بعد الإصلاح) مع أحدث cli مثبت لأي شخص آخر يبحث عن إصدار حديث في الوقت نفسه.

justnance كافية؟

+1

+1

+1

+1

سبب آخر هو عند استخدام نظام تشغيل مثل coreOS الذي لا يحتوي على إدارة للحزم ، فإن الطريقة الاصطلاحية لتشغيل الأشياء هي عبر الحاوية. أنا مندهش من أن الحاجة إلى هذا قد يكون موضع تساؤل ، وهو إغفال واضح. 👍

+1

: +1:

+1

+1

+1

+1

+1

بصفتي الافتتاحية للرقم 3291 (أقدم الإصدارات الثلاثة المقتبسة لول) ، يسعدني أن أرى أن هذه المشكلة تكتسب زخمًا أخيرًا. لجميع المستجيبين في المستقبل ، عندما يقول justnance "الرجاء إجراء 1+ لإبداء الاهتمام" ، فهذا يعني إضافة فهذه هي الطريقة الصحيحة لإجراء 1+ للأشياء على GitHub حتى لا

+1 لإبقاء أصحاب الريبو على علم

+1

عندما يقولون لـ +1 مشكلة ، فإن ما يقصدونه هو النقر فوق الزر 👍. لا يفيد المطورين في الحصول على 100 تعليق يقول كل منهم "+1". كلما عرفت أكثر!

davidham - شكرًا

لقد قلت نفس الشيء منذ يومين لكننا جميعًا في نفس الجانب 🙃

+1

+1

+1

+1

+1

+1

+1

هل يمكنك التوقف عن +1؟ إذا كنت تريد إجراء 1+ ، فافعل ذلك في الأعلى.

أنت تضيع وقت المهندس الثمين. نحن عشرات المشتركين في هذا العدد ...

لقد ظللت أحافظ على صورة AWS-CLI لأكثر من عامين حتى الآن. لا تتردد في استخدامه إذا لزم الأمر (أستخدمه عدة مرات في اليوم). أتلقى تحديثات على إصدارات الإصدار الجديد (عبر IFTT) وأدفع التحديثات بسرعة إلى حد ما. على الرغم من شهرة ومجد إدارة صورتي الخاصة (ها!) ، سأؤجل وأدفع الناس لاستخدام صورة رسمية.

بعد استخدام صورتي لفترة طويلة ، سأقول أنه سيكون من المفيد جدًا أن تتضمن الصورة الرسمية jq (نظرًا لأن واجهة برمجة التطبيقات ثقيلة بتنسيق JSON). إنه يجعل من السهل جدًا القيام بأشياء مثل "الحصول على أحدث تعريف لمهمة ECS ، وإجراء تغيير ، ودفعه للخلف" كل ذلك في مرحلة خط أنابيب CI / CD واحدة.

حل بديل آخر للمشكلة: https://hub.docker.com/r/somedeveloper/aws-cli/

أسباب استخدام:

  • يبقيها بسيطة.
  • يستخدم تمدد python3.7 الرسمية كصورة أساسية.
  • يستخدم إستراتيجية AWS الموصى بها للتثبيت - python + pip. انظر هنا .
  • يتضمن aws-sam-cli لأولئك المهووسين الذين لا يحتاجون إلى خادم 8).
  • إنه عام ولا يتطلب تسجيل دخول.
  • رائعة لخطوط أنابيب CI / CD - لم تستخدمها لأي شيء آخر لذلك لم تزن الإيجابيات والسلبيات.

ما زلت آمل في الحصول على صورة رسمية. فكر في الناس الآن

https://hub.docker.com/r/google/cloud-sdk/ . آسف شباب. إنها مهمة صعبة بالنسبة لشركة عملاقة مثل AWS.

+1

لا يعتبر +1 ضارًا ؛)

على أي حال ، هذه هي المشكلة الثالثة (؟) التي تم إنشاؤها حول هذا ...

رابعًا ، إذا كنت تفكر في https://github.com/aws/amazon-linux-docker-images/issues/10.

ألا يمكننا وضعها في CircleCI وننتهي من ذلك؟ يسعدني مساعدتك في ملف Dockerfile أو خط الأنابيب.

أتساءل عما إذا كانت هناك أي قيود داخلية و / أو أعمال ورقية داخل أمازون تمنع المطورين من إنجاز هذا العمل الذي يبدو تافهاً ...

ك لول

هناك عدد قليل من المتغيرات التي قد يكون من الرائع وجودها في الصورة "الرسمية". على سبيل المثال ، أتطلع حاليًا إلى الاستيلاء على حاوية بها aws cli و curl (للتحقق من نقطة نهاية بيانات IAM الوصفية) وسيكون من السهل حقًا العثور على حاوية يمكنني الحصول عليها وتوصيلها بنشر k8s الخاص بي.

هناك أيضًا سبب أمني لتقديم الصور الرسمية.

إنه يجعل نموذج التهديد أبسط عن طريق إزالة الاعتماد على "شخص عشوائي على الإنترنت" يحافظ على الصورة المستخدمة في الأهداف عالية القيمة مثل خطوط أنابيب CI / CD التي عادةً ما توفر الكثير من الوصول إلى أنظمتك.

أرغب في الحصول على صورة رسمية لرسو السفن AWS-cli تستند إلى عامل الإرساء: صورة 18 (مستقرة حاليًا) (https://hub.docker.com/_/docker) - على سبيل المثال. aws-cli-docker-18 لأنني أرغب في إنشاء صورة عامل الإرساء الخاص بي في بيئة CI / CD التي تستخدم حاليًا صورة docker:18 ونشرها على AWS ECR.

+1

+1

سيكون من الرائع أن يمتنع الناس عن التعليق عندما لا يساهم تعليقهم في القضية المطروحة. التعليقات مثل "+1" تقدم فقط رسائل غير مرغوب فيها للمشتركين وتجعل المشكلة أطول من اللازم. بدلاً من ذلك ، أعطِ إعجابًا بالتعليق الأول على المشكلة.

سيكون من الرائع أن يمتنع الناس عن التعليق عندما لا يساهم تعليقهم في القضية المطروحة. التعليقات مثل "+1" تقدم فقط رسائل غير مرغوب فيها للمشتركين وتجعل المشكلة أطول من اللازم. بدلاً من ذلك ، أعطِ إعجابًا بالتعليق الأول على المشكلة.

هذا العدد مفتوح منذ سبتمبر من العام الماضي. أعتقد أننا بحاجة إلى مطالبة AWS بإلقاء نظرة على هذه المشكلة مرة أخرى ، حيث من الواضح أن هناك اهتمامًا بها. ينبغي إخبارنا بمدى الاهتمام "الكافي".

لأنه من الواضح أن هناك اهتمامًا به

ليس مجرد اهتمام ، بل هو القضية المفتوحة مع المزيد : +1: ردود الفعل :

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

تم فتح الإصدار الثاني الذي يحتوي على معظم ردود الفعل في عام 2014 والثالث في عام 2015 ، بينما تم فتح هذا الإصدار في سبتمبر 2018 (قبل أقل من عام ).

+1000

لدي على الجهاز المحلي الخاص بي دائمًا مشكلات تتعلق بإعداد التبعيات الصحيحة لعمل aws-cli. لذلك قررت التبديل إلى aws-cli داخل عامل الإرساء. لقد عثرت على العديد من الصور المتاحة للجمهور على docker-hub ولكن لأنها غير رسمية لا أثق بها افتراضيًا ، لذلك في كل مرة يتوفر فيها إصدار محدث ، يجب أن أبحث عن صورة يمكن الوثوق بها مرة أخرى. وهو آمن للاستخدام. يُرجى من AWS إنشاء صورة عامل إرساء AWS-cli آمنة وصيانتها وتوفيرها عبر محور عامل الإرساء. شكرا لك مقدما

هناك تجزئة كبيرة للمجتمع المقدم من صور aws-cli. ولكن ، كما ذكرنا سابقًا: يفضل الناس واحدًا يتم صيانته ودعمه رسميًا بواسطة Amazon. عدة أسباب لماذا:

1) لن تتلاشى - صور المجتمع سيئة السمعة لتتقادم في النهاية ؛
2) أكثر أمانًا - إنه مصدر موثوق به ، بغض النظر عن مدى ثقة أحد أعضاء المجتمع ، فهم لا يمثلون Amazon رسميًا ، وبالتالي "جميع الضمانات باطلة" ؛
3) يعني الدعم الرسمي الدعم الرسمي في حالة وجود أخطاء ، أو تعارضات في الإصدارات ، أو التوافق مع الإصدارات السابقة ، وما إلى ذلك.
4) يمكن لـ AWS تحديث صورتها لأنها تقوم بتحديث aws cli ، بما في ذلك العلامات التاريخية.

+1

+1 من المؤسف حقًا أن أمازون لا تقدم هذا

لقد أضفت منذ ذلك

dind-aws-cli

+1

في حين أن هناك الكثير من الصور غير الرسمية التي يتم صيانتها جيدًا ، ما الذي يمنعهم يومًا ما من قول "بفت ، ما الهدف من تحديث هذا بعد الآن. هذه وظيفة أمازون!"

+1

+1

عندما يتعلق الأمر بمساعدة الأشخاص على أتمتة عملهم مع AWS Amazon ، فإن هذا يفشل كثيرًا ، فهذا أحد الأسباب التي تجعلنا نفكر في تركهم.

هل هناك رد رسمي من المشرفين بشأن ما إذا كان هذا على خريطة الطريق أم لا؟ مثل كثيرين آخرين ، أفضل استخدام صورة رسمية أيضًا ...

+1

إذا كانت هناك صورة رسمية لـ AWS CLI ، فستكون ملفًا تنفيذيًا يجلس داخل حاوية خدش. لأن هذا لن يكون مفيدًا بشكل لا يصدق للأفراد ، فقد يكون الأفضل هو:

  • استخدم حاوية بيثون رسمية لبناء واجهة سطر الأوامر من المصدر
  • انسخ ملف AWS CLI الثنائي الناتج في صندوق Busybox أو حاوية التسويد

أي شيء أكثر من ذلك سيكون مبالغة في الهندسة على الرغم من أي نقاشات تحدث هنا.

تحب AWS عرض جميع خدمات ECR و CodeDeploy. لماذا لا يوجهون كل تلك القوة النارية إلى CLI الحاوية الخاصة بهم؟

لأن العرض المطروح على الطاولة يبدو أنه لشخص ما من المجتمع للحفاظ عليه.

balibebas قام شخص ما من المجتمع بذلك بالفعل. هناك عدد كبير من الصور - ولكن النقطة هنا هي أنه ستكون هناك واحدة من AWS ، لأنني لا أريد تشغيل randomguy/aws-cli:canbechangedanytime في بيئة CI الخاصة بي مع فتح كل الأسرار على مصراعيها.

ماذا ستقول عن F-Droid إذن؟

إنها ذات صلة بهذه المشكلة مثل هذه القطة:

تبدو وكأنك عميل يدفع.

حسنًا ، ربما يكون ذلك بسبب _I_ _am_

الكرازة للجوقة. على أي حال ، حظيت تركيبة المشروب بفرصة أفضل لأنه تم تصريفها لفترة أطول ، ولا تزال بدون حركة. لذلك تصبح صور القطط ذات نتائج عكسية على الفور عندما لا يكون هناك حالة استخدام عامة في الخارج ربما خدش أو حاوية BUSYBOX كما أشرت سابقًا. ما هو اقتراح التصميم الخاص بك؟

أنا والعديد من الآخرين يقومون حاليًا "بحاويات Busybox" على سبيل المثال لتشغيلها باستخدام عامل الإرساء للحصول على بيانات اعتماد مصادقة ECR. بالنظر إلى عدد عناصر الرصيف الموجودة في aws ، فليس من المنطقي عدم وجود عبوة رسمية.

ربما هم فقط في شيء آخر. ؛)

أنا سعيد لأننا حللنا هذا الأمر الآن. رجوع إلى 1+ التعليقات:

+1 لـ Dockerless

mattibalibebas نضع في اعتبارنا أنه اعتبارا من الآن هناك 64 شخصا في محادثة هذه المسألة وحدها، وكل استجابة مشغلات بريد إلكتروني غير مفيد والإعلام التي يتم إرسالها من المحتمل أن كل واحد من هؤلاء 64 شخصا وأكثر من الذين اشتركوا. هذه الرسالة ستفعل الشيء نفسه ، وأنا أعتذر عن ذلك.

لكن في الحقيقة ، من فضلك حافظ على الأمور احترافية. على الرغم من أن صور القطط لطيفة ، فكلما انحرف هذا الخيط عن القضبان ، شعرت أنه من غير المرجح أن يؤخذ على محمل الجد من قبل المشرفين. للأسف ، البريد العشوائي هو بريد عشوائي هو بريد عشوائي.

هذا ما يفعله زر إلغاء الاشتراك ، الزر الذي قمت بالنقر فوقه للتو.

سيكون من الجيد أن يكون لديك. أنا مندهش فقط من عدم اتخاذ أي إجراء أو الحفاظ على هذا الأمر (بما في ذلك قول لا).
على أي حال ، أشار الأشخاص أعلاه عن حق إلى أهمية صورة AWS cli الرسمية.
أعتقد أن الأشخاص يستخدمون بالفعل طرقهم الخاصة أو عبر مسار مديري الصور / الحزم التي أنشأها شخص آخر وما إلى ذلك.
بعد مثال آخر للنص للنفس

لكن المشكلة الأبسط والتي لا يمكن تجنبها تظل كما هي.

  • قائمة التبعيات والشكوك التي لا تنتهي أبدًا والتي تقفز إذا كانت تعتمد على المطورين لدمج الأشياء بمفردهم. سيؤدي في النهاية إلى المزيد من المشكلات في الريبو حيث سيبدأ الأشخاص بتثبيت شيء واحد ثم آخر ثم بضعة أشياء أخرى لإنجاز العمل الذي يلوث البيئة مما يتعارض مع الغرض من CI / CD أو الأعمال المماثلة المتمثلة في العزلة والبكر.
  • من الصعب الوثوق بتنفيذ وتتبع صورة عامل ميناء أي شخص آخر لعملك. يؤدي هذا إلى إنشاء خط أنابيب آخر وإضافة إدخال في سجل عامل الميناء للحصول على صورة awscli الجديدة ، ومستودع آخر ، أي شيء آخر يجب صيانته.
  • في CI / CD ، أفضّل فقط استخدام الصورة (الداخلية أو الرسمية) وتجنب خطوط البرمجة لإضافة أشياء قدر الإمكان.
  • مشكلة في build & libs حيث يمكن أن تكون الصورة الرسمية مبنية على الفور من إصدارات المصدر نفسها ولديها تبعيات أقل ديناميكية ومدير حزم wrt وما هو غير ذلك.

آخر
=> ينتهي الأمر بالجميع بصنع ما يناسبهم.

نفس الشيء هنا ، حاليًا أستخدم صورة ذاتية الإنشاء ، لكني أفضل صورة رسمية أسفل

مساحة الاسم. أستخدمه لإنشاء صور عامل إرساء أخرى ودفعها إلى ECR ، حيث يلزم الحصول على بيانات الاعتماد.

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/*

لا ينبغي أن تكون هذه صفقة كبيرة لإضافة هذا إلى خط أنابيب البناء الخاص بك ... :)

-

لقد قمت بتحديث ملف Dockerfile وفقًا لاقتراح @ mikesir87 ، وهذا سبب آخر للحصول على صورة قياسية مع مساهمات المجتمع للحصول على أصغر صورة)

آسف على إرسال رسائل غير مرغوب فيها إلى الجميع ، ولكن أردت الإشارة (في حالة رغبة أي شخص آخر في استخدام المقتطف من @ jens-meiss) أنه يجب عليك _really_ التفكير في ربط كشوفاتك الثلاثة RUN في بيان واحد. بخلاف ذلك ، ما زلت تشحن محتويات py-pip وتخزين apk مؤقت في الطبقات المتوسطة ، على الرغم من أن الحاوية النهائية الخاصة بك لا يمكنها الوصول إليها.

في ملاحظة أخرى ، يُظهر التعليق حالة استخدام أخرى صالحة ... عندما تستخدم aws-cli فقط للحصول على بيانات اعتماد لـ ECR لدفع الصور. يبدو هذا وكأنه حاجة إلى حزم مساعد بيانات اعتماد ECR في صورة أيضًا. من المؤكد أنه سيجعل من السهل إنشاء الصور ودفعها دون الحاجة إلى aws-cli الكامل.

مرحبا بالجميع ، المشرف هنا. أردت فقط التوضيح ، هذا يحدث ، نحن نفعل هذا.

نحن بصدد إنشاء بنية تحتية أفضل للإصدار داخليًا حتى نتمكن من بناء / اختبار / دعم المزيد من أنواع أدوات الإصدار ، خاصة وأننا سنقوم بشحن المزيد من عناصر الإصدار لـ cli v2.

ليس لدينا جدول زمني محدد في الوقت الحالي ، لكنه يحدث.

من السهل القيام بذلك وفقًا لمطوري أمازون والعديد من الآخرين ، ولكن لا يزالون ينتظرون بعد عامين وبدون ETA 😂

+1

البنية التحتية للإصدار الداخلي (الربع الرابع 2019)
تقييم الفريق القانوني (2020 الربع الأول)
إصدار تجريبي عام تحت AWS / cli-dev-test (2020 Q2)
الإصدار النهائي (2020 Q3)

في هذا الجدول الزمني المتفائل ، ستحصل على ما تريد في أقل من 10 أشهر. 🥇

في انتظار مشاركة مدونة جيف باررس

أنا أنتظر هذا لعنة.

هل يمكننا على الأقل الحصول على إعلان أو التزام رسمي. ربما الافراج عن الهدف؟

bhmckendrick هو التزام ليس بالضبط ما هذا التعليق ليس بعيدًا عن تعليقك؟

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

أكثر من عام ولا توجد تحديثات؟ صورة؟

يا jamesls ، هل تفكر في تأمين هذا الموضوع بشدة حتى يكون لديك شيء لمشاركته؟

إن عدد الأشخاص غير المستعدين تمامًا للقراءة ( تلميح تلميح ) وبدلاً من ذلك اختيار إرسال بريد غير مرغوب فيه لأكثر من 70 مراقبًا حول كيفية انزعاجهم _ على وجه التحديد _ هو ، أنا متأكد من أنه يقلل بشكل كبير من اهتمام الجميع باتباع هذا الموضوع.

أيضًا ، شكرًا على عملك لتحقيق ذلك!

بصفتي المؤلف الأصلي لهذه المشكلة (حسنًا ، لقد كنت شجاعًا بما يكفي لنسخ / لصق تلك "wontfix" التي تم إغلاقها سابقًا) لقد ألغيت بالفعل اشتراكي من هذه المشكلة بسبب +1 الهائل للبريد العشوائي والمعارك العرضية مع صور القطط (آسف) .

ما عليك سوى ضبط إعدادات الإشعارات بحيث لا تتلقى إشعارات إلا إذا تم إغلاق هذه المشكلة.

أود فقط أن أشير إلى أنه بصرف النظر عن CI / CD ، فإن بعض المطورين (راجعLongLiveCHIEF) ، يفضلون أن يكون لديهم بيئات تطوير ثابتة ، ولا يحبون تثبيت الأشياء محليًا ، أو الاضطرار إلى التعامل مع مديري الإصدارات التاليين لـ اللغات الأصلية التي تعتمد عليها أدوات cli حتمًا.

من الأسهل الحصول على docker pull aws-cli من أيًا كانت خطوات التثبيت الحالية ... ناهيك عما إذا لم تكن من مطوري Python ، فلديك عبء إعداد إصدار وبيئة جيدة من Python لمستخدمك ، أو ربما حتى كل مشروع.

قم بتوسيع نطاق ذلك لجميع الأدوات المختلفة التي قد يستخدمها المطور (cli's المستندة إلى روبي ، cli's المستندة إلى العقدة) ، وعليك أن تتعلم إعدادات البيئة للغات التي قد لا تكتب بها على الإطلاق.

النقطة التي أوضحها هنا هي أن تشغيل عامل الإرساء موجود في كل مكان ، ويتخلص من أي إعدادات / تكوينات للغة الأصلية ، ويسهل الأمور على المستخدمين.

حتى إذا قام المستخدمون ببناء صور عامل الإرساء الخاصة بهم ، فلا يزال يتعين عليهم الكفاح مع مهام الإعداد هذه.

لا أستخدم البرمجة بلغة Python ، لكنني أُجبرت على تعلم خصوصيات وعموميات البيئات الافتراضية وأفضل ممارساتها من إصدارات مختلفة من Python ، لمجرد أن موفري الأدوات يعتبرونها "تافهة".

لا يتمتع جميع المطورين بالخلفية نفسها التي يتمتع بها أولئك الذين صمموا الأداة ، كما أن توفير صورة عامل الإرساء يعد علامة على الاحترام. يمكن لموفري الأدوات تحمل عبء المراوغات الخاصة بالبيئة الخاصة باللغة الأصلية بسرعة كبيرة وسهولة ، في حين يتعين على المتبنين قضاء وقت أطول بكثير لإدارة هذه النفقات العامة خلال مراحل دورة الحياة المختلفة لتطوير منتجك.

على الرغم من الغذاء.

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 يبدو أنها صورة رسمية من أمازون ، على الرغم من أنها ليست صورة رسمية نشرتها Docker .

لا أعرف ما إذا كان الإنتاج جاهزًا صعبًا ، لأنهم لم يقلوا شيئًا في هذه المسألة حتى الآن.

من الغريب كيف أن صورة AWS هذه هي 98.42 ميجابايت في حين أن الصور الأخرى (على سبيل المثال atlassian / pipelines-awscli ) تكون أصغر بكثير.

عضو فريق CLI هنا. نعم يمكنني أن أؤكد أننا أطلقنا رسميًا صورة Docker لـ AWS CLI v2! أوصي بقراءة ما يلي:

سأقوم بإغلاق هذه القضية. إذا كانت لديك ملاحظات أو أسئلة حول الصورة ، فالرجاء فتح مشكلة GitHub أخرى في هذا المستودع.

بصفتي افتتاحية الإصدار الأصلي رقم 3291 ، تلك السنوات العديدة الماضية ، فإن مؤلمتي مليئة بالبهجة لرؤية مخاوفي قد تم التحقق منها أخيرًا ، وتتوفر الآن صورة Docker الرسمية. لقطات وعاء حول المدة التي استغرقها وضع هذه الصورة جانباً ، أنا متأكد من أن قول هذا كان أسهل بكثير من فعله ، لذا شكراً جزيلاً لمطوري أمازون الذين جعلوا هذا يحدث. أنتم جميعا تقومون بعمل ممتاز. 👏🎉👏

_حسنا أليكسا ، شكرتهم ، من فضلك أطلق سراح عائلتي الآن.

هل Dockerfile متوفر في أي مكان؟

zerkms Aha ، وجدها في الفرع v2 :
https://github.com/aws/aws-cli/blob/v2/docker/Dockerfile

أعتقد أنهم فعلوا ذلك أخيرًا ، لكنني لم أتمكن من تشغيله على Gitlab CI https://hub.docker.com/r/amazon/aws-cli

أنا بدلاً من ذلك أستخدم صورة عامل إرساء AWS CLI من Gitlab ، وهي تعمل بشكل مثالي. فقط استخدم

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 لقد استقرت على صورة جيتلاب على أي حال. على أي حال ، شكرا على الشرح.

إذا كان أي شخص لا يزال مهتمًا بالحصول على AWS CLI v2 للعمل على Alpine Linux ، فإليك مثالاً على 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 ، لكن Alpine Linux لديه دعم 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/*

تتم إزالة فهرس الإكمال التلقائي وملفات الأمثلة ، كما تتم إزالة "groff" (أفترض أن الأشخاص لا يحتاجون إلى صفحات مساعدة في صور Docker الخاصة بهم)

هذا بسيط للغاية ، https://github.com/flaccid/docker-awscli/blob/master/Dockerfile ويقوم بالمهمة ولكن أعلمني عبر مشكلات github إذا كانت هناك حاجة إلى أي شيء آخر في الصورة (حالة استخدام صالحة).

هذا بسيط للغاية ، https://github.com/flaccid/docker-awscli/blob/master/Dockerfile ويقوم بالمهمة ولكن أعلمني عبر مشكلات github إذا كانت هناك حاجة إلى أي شيء آخر في الصورة (حالة استخدام صالحة).

يعتمد ملف APK أعلاه على AWS-CLI 1.18 ، وليس على v2 CLI.

هل من المحتمل أن تفكر Amazon في إنشاء صورة بالإصدار 1 من CLI؟

keeganwitt يجب عليك فتح إصدار جديد لهذا الطلب. : +1:

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات