मैं अपने ईसी 2 इंस्टेंस बूट के हर बार क्लाउड-इनिट स्टार्टअप स्क्रिप्ट कैसे चला सकता हूं?

Question

मेरे पास एक ईसी 2 इंस्टेंस है जो अमेज़ॅन लिनक्स एएमआई पर आधारित एएमआई चला रहा है। ऐसे सभी एएमआई की तरह, यह प्रत्येक उदाहरण में पारित उपयोगकर्ता डेटा के आधार पर स्टार्टअप स्क्रिप्ट चलाने के लिए cloud-init सिस्टम का समर्थन करता है।

#include 
http://s3.amazonaws.com/path/to/script/1 
http://s3.amazonaws.com/path/to/script/2 

पहली बार मैं अपने उदाहरण बूट, क्लाउड-init स्टार्टअप स्क्रिप्ट सही ढंग से चलाता है: इस विशेष मामले में, मेरे उपयोगकर्ता डेटा इनपुट एक फ़ाइल है कि कई अन्य स्टार्टअप स्क्रिप्ट स्रोतों में शामिल होता है। हालांकि, अगर मैं उदाहरण के लिए सॉफ्ट रीबूट करता हूं (उदाहरण के लिए sudo shutdown -r now चलाकर), उदाहरण बिना के बिना दूसरी बार स्टार्टअप स्क्रिप्ट चला रहा है। अगर मैं सिस्टम लॉग में जाते हैं, मैं देख सकता हूँ:

Running cloud-init user-scripts 
user-scripts already ran once-per-instance 
[ OK ] 

यह नहीं है कि मैं क्या चाहता हूँ - मैं स्टार्टअप स्क्रिप्ट है कि केवल उदाहरण जीवनकाल में एक बार दिखाए जाने का उपयोगिता को देख सकते हैं, लेकिन मेरे मामले में इन होना चाहिए सामान्य स्टार्टअप स्क्रिप्ट की तरह इंस्टेंस शुरू होने पर हर बार चलाएं।

मुझे एहसास है कि पहली बार चलने के बाद मेरी स्क्रिप्ट मैन्युअल रूप से rc.local में डालने के लिए एक संभावित समाधान है। हालांकि, यह बोझिल लगता है, चूंकि क्लाउड-इनिट और आरसीडी वातावरण काफी अलग हैं और अब मुझे पहले लॉन्च पर स्क्रिप्ट को डिबग करना होगा और बाद में सभी लॉन्च अलग-अलग होंगे।

क्या कोई जानता है कि मैं हमेशा अपनी स्क्रिप्ट चलाने के लिए क्लाउड-इनिट कैसे बता सकता हूं? यह निश्चित रूप से कुछ ऐसा लगता है जैसे क्लाउड-इनिट के डिजाइनरों ने विचार किया होगा।

Answer 1

11.10, 12.04 और बाद में, आप 'स्क्रिप्ट-उपयोगकर्ता' रन 'हमेशा' बनाकर इसे प्राप्त कर सकते हैं। /etc/cloud/cloud.cfg आप की तरह कुछ देखेंगे में:

cloud_final_modules: 
- rightscale_userdata 
- scripts-per-once 
- scripts-per-boot 
- scripts-per-instance 
- scripts-user 
- keys-to-console 
- phone-home 
- final-message 

यह बूट के बाद संशोधित किया जा सकता है, या इस श्लोक अधिभावी बादल-config डेटा उपयोगकर्ता के डेटा के माध्यम से डाला जा सकता है। हां, उपयोगकर्ता डेटा में आप प्रदान कर सकते हैं:

#cloud-config 
cloud_final_modules: 
- rightscale_userdata 
- scripts-per-once 
- scripts-per-boot 
- scripts-per-instance 
- [scripts-user, always] 
- keys-to-console 
- phone-home 
- final-message 

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

वैकल्पिक रूप से http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt

पर बादल-config दस्तावेज़ में इस पर थोड़ा और अधिक जानकारी नहीं है, तो आप// var/lib/बादल/लिपियों में फ़ाइलों को रख सकते हैं प्रति-बूट, और वे हो जाएगा 'स्क्रिप्ट-प्रति-बूट' पथ से चलाएं।

Answer 2

एक संभावना, हालांकि कुछ हद तक हैक, लॉक फ़ाइल को हटाना है जो क्लाउड-इनिट का उपयोग यह निर्धारित करने के लिए करता है कि उपयोगकर्ता-स्क्रिप्ट पहले से चल चुकी है या नहीं। मेरे मामले में (अमेज़ॅन लिनक्स एएमआई), यह लॉक फ़ाइल /var/lib/cloud/sem/ में स्थित है और इसे user-scripts.i-7f3f1d11 नाम दिया गया है (अंत में हैश भाग प्रत्येक बूट को बदलता है)। इसलिए, निम्नलिखित उपयोगकर्ता के डेटा स्क्रिप्ट सम्मिलित फ़ाइल के अंत में जोड़ा चाल करना होगा:

#!/bin/sh 
rm /var/lib/cloud/sem/user-scripts.* 

मुझे यकीन है कि अगर यह कुछ और पर किसी भी प्रतिकूल प्रभाव हो जाएगा नहीं कर रहा हूँ, लेकिन यह में काम किया है मेरी प्रयोगों।

/usr/bin/cloud-init-run-module once-per-instance user-scripts execute run-parts ${SCRIPT_DIR} >/dev/null && success || failure 

को

/usr/bin/cloud-init-run-module always user-scripts execute run-parts ${SCRIPT_DIR} >/dev/null && success || failure 

गुड लक:

Answer 3

/etc/init.d/cloud-init-user-scripts में, इस लाइन को संपादित!

Answer 4

क्लाउड-init अब मूल रूप से इस का समर्थन करता है, बनाम दस्तावेज में bootcmd आदेश विवरण runcmd देखना (http://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot):

"runcmd":

#cloud-config 

# run commands 
# default: none 
# runcmd contains a list of either lists or a string 
# each item will be executed in order at rc.local like level with 
# output to the console 
# - runcmd only runs during the first boot 
# - if the item is a list, the items will be properly executed as if 
# passed to execve(3) (with the first arg as the command). 
# - if the item is a string, it will be simply written to the file and 
# will be interpreted by 'sh' 
# 
# Note, that the list has to be proper yaml, so you have to quote 
# any characters yaml would eat (':' can be problematic) 
runcmd: 
- [ ls, -l,/] 
- [ sh, -xc, "echo $(date) ': hello world!'" ] 
- [ sh, -c, echo "=========hello world'=========" ] 
- ls -l /root 
- [ wget, "http://slashdot.org", -O, /tmp/index.html ] 

"bootcmd":

#cloud-config 

# boot commands 
# default: none 
# this is very similar to runcmd, but commands run very early 
# in the boot process, only slightly after a 'boothook' would run. 
# bootcmd should really only be used for things that could not be 
# done later in the boot process. bootcmd is very much like 
# boothook, but possibly with more friendly. 
# - bootcmd will run on every boot 
# - the INSTANCE_ID variable will be set to the current instance id. 
# - you can use 'cloud-init-per' command to help only run once 
bootcmd: 
- echo 192.168.1.130 us.archive.ubuntu.com >> /etc/hosts 
- [ cloud-init-per, once, mymkfs, mkfs, /dev/vdb ] 

bootcmd में "क्लाउड-इनिट-प्रति" कमांड उदाहरण भी नोट करता है। यह की मदद से:

Usage: cloud-init-per frequency name cmd [ arg1 [ arg2 [ ... ] ] 
    run cmd with arguments provided. 

    This utility can make it easier to use boothooks or bootcmd 
    on a per "once" or "always" basis. 

    If frequency is: 
     * once: run only once (do not re-run for new instance-id) 
     * instance: run only the first boot for a given instance-id 
     * always: run every boot 

Answer 5

मैं लगभग दो दिनों के लिए इस मुद्दे के साथ संघर्ष किया, समाधान मुझे लगता है और अंत में कर सकता है के सभी की कोशिश की, कई दृष्टिकोण के संयोजन, निम्नलिखित के साथ आया था:

MyResource: 
    Type: AWS::EC2::Instance 
    Metadata: 
    AWS::CloudFormation::Init: 
     configSets: 
     setup_process: 
      - "prepare" 
      - "run_for_instance" 
     prepare: 
     commands: 
      01_apt_update: 
      command: "apt-get update" 
      02_clone_project: 
      command: "mkdir -p /replication && rm -rf /replication/* && git clone https://github.com/awslabs/dynamodb-cross-region-library.git /replication/dynamodb-cross-region-library/" 
      03_build_project: 
      command: "mvn install -DskipTests=true" 
      cwd: "/replication/dynamodb-cross-region-library" 
      04_prepare_for_west: 
      command: "mkdir -p /replication/replication-west && rm -rf /replication/replication-west/* && cp /replication/dynamodb-cross-region-library/target/dynamodb-cross-region-replication-1.2.1.jar /replication/replication-west/replication-runner.jar" 
     run_for_instance: 
     commands: 
      01_run: 
      command: !Sub "java -jar replication-runner.jar --sourceRegion us-east-1 --sourceTable ${TableName} --destinationRegion ap-southeast-1 --destinationTable ${TableName} --taskName -us-ap >/dev/null 2>&1 &" 
      cwd: "/replication/replication-west" 
    Properties: 
    UserData: 
     Fn::Base64: 
     !Sub | 
      #cloud-config 
      cloud_final_modules: 
      - [scripts-user, always] 
      runcmd: 
      - /usr/local/bin/cfn-init -v -c setup_process --stack ${AWS::StackName} --resource MyResource --region ${AWS::Region} 
      - /usr/local/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource MyResource --region ${AWS::Region} 

यह वह जगह है डायनेमो डीबी क्रॉस-क्षेत्र प्रतिकृति प्रक्रिया के लिए सेटअप।