6

Google के कंटेनर इंजन या उनके 'कंटेनर-वीएम' पर चलाने के लिए कस्टम निर्मित सेंटोस डॉकर कंटेनर के अंदर Google सेवा खाता प्रमाण-पत्रों को तैनात करने का सबसे अच्छा तरीका क्या है? यह व्यवहार स्वचालित रूप से google/cloud-sdk कंटेनर पर होता है, जो डेबियन चलाता है और इसमें ऐसी चीजें शामिल होती हैं जिन्हें मैं ऐप-एनजी/जावा/php जैसे उपयोग नहीं कर रहा हूं। आदर्श रूप से मैं अपने प्रोजेक्ट के अंदर गैर-सार्वजनिक संसाधनों तक पहुंचने का प्रयास कर रहा हूं, उदाहरण के लिए, Google क्लाउड स्टोरेज बाल्टी ऑब्जेक्ट्स, लॉग इन किए बिना और इन्हें एक बार बड़ी संख्या में इन कंटेनर लॉन्च किए जाने के बाद अधिकृत किया जाता है।डॉकर कंटेनर के अंदर अनुशंसित जीसीई सेवा खाता प्रमाणीकरण?

उदाहरण के लिए, एक आधार Centos कंटेनर कस्टम कोड के साथ GCE पर चल रहा है पर और gcloud/gsutil, स्थापित है जब आप चलाएँ:

docker run --rm -ti custom-container gsutil ls 

आप संकेत दिया जाता है "gsutil config" चलाने के लिए, प्राधिकरण हासिल करने के लिए जो मैं उम्मीद करते हैं।

हालांकि, एक ही जीसीई पर Google/क्लाउड-एसडीके कंटेनर को खींचकर और उसी आदेश को निष्पादित करने के लिए, ऐसा लगता है कि यह क्रेडेंशियल्स (शायद होस्ट कंटेनर-वीएम के क्रेडेंशियल्स से) की चालाकी से कॉन्फ़िगर किया गया है। यह निजी संसाधनों तक पहुंचने के लिए जीसीई पर कंटेनर चलाते समय "gsutil config" चलाकर बाईपास लगता है।

मैं सामूहिक तैनाती के लिए न्यूनतम निर्माण केंद्र कंटेनर में उस व्यवहार को दोहराने के लिए देख रहा हूं।

+0

क्या आपका प्रश्न जीसीई से जीसीएस तक आसानी से प्रमाणीकृत करने के बारे में है, या कम से कम gcloud एसडीके कंटेनर, या कुछ और कैसे है? आप क्यों मानते हैं कि यह विकास के लिए अच्छा है लेकिन उत्पादन नहीं है? जब आप उनमें से कई कंटेनर होते हैं तो आप किन मुद्दों पर चल रहे हैं? साथ ही, पोस्ट के दूसरे भाग को एक अलग प्रश्न में विभाजित करने पर विचार करें। –

+0

प्रयास किए गए स्पष्टीकरण के लिए ऊपर संपादित किया गया। – GNN

उत्तर

2

अनुवर्ती।

मैंने /.config & /.gce निर्देशिकाओं का उपयोग करना समाप्त कर दिया और जीसीई एसडीके घटकों का एक बहुत ही कम सेट (कोई जेडीके/PHP/आदि) का उपयोग नहीं किया। wheezy-cloudtools Dockerfile मुझे सबसे अच्छा उदाहरण साबित हुआ।

4

अद्यतन: 15 दिसंबर 2016 तक, मौजूदा वीएम के दायरे को अद्यतन करने की क्षमता अब बीटा में है; अधिक जानकारी के लिए this SO answer देखें।


पुराना जवाब: एक दृष्टिकोण के साथ वी एम बनाने के लिए है appropriate scopes (जैसे, Google क्लाउड संग्रहण केवल पढ़ने के लिए या पढ़ने-लिखने की) और फिर वी एम पर सभी प्रक्रियाओं, कंटेनर सहित, के लिए उपयोग होगा प्रमाण पत्र जो वे OAuth 2.0 के माध्यम से उपयोग कर सकते हैं; Google Cloud Storage और Google Compute Engine के लिए दस्तावेज़ देखें।

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

+0

धन्यवाद। यह वास्तव में मैंने किया है हालांकि यह परियोजना के अंदर अनुमतियों की अपेक्षा के रूप में काम नहीं करता है। मैं जीएस स्टोरेज का उपयोग इसके मूल के बाद से एक उदाहरण के रूप में करूंगा। कंटेनर इंजन --scopes https://www.googleapis.com/auth/devstorage.read_write के साथ बनाया गया था। फिर मैं आधार उबंटू कंटेनर और गूगल/क्लाउड-एसडीके कंटेनर तैनात करता हूं। केवल google/cloud-sdk कंटेनर "gsutil ls" कर सकता है। उबंटू कंटेनर जो आप देखते हैं "आप एक ऐसा ऑपरेशन करने का प्रयास कर रहे हैं जिसके लिए एक प्रोजेक्ट आईडी की आवश्यकता है, कोई भी कॉन्फ़िगर नहीं किया गया है" – GNN

+0

क्या आपने डिफॉल्ट प्रोजेक्ट सेट करने के लिए 'gcloud config set प्रोजेक्ट प्रोजेक्ट' का उपयोग किया है, या स्पष्ट रूप से 'gsutil ls के माध्यम से प्रोजेक्ट निर्दिष्ट करें - पी परियोजना जीएस: // बाल्टी'? –

संबंधित मुद्दे