AWS CLI’yı CRON’dan çalıştıramıyor (kimlik bilgileri)

Basit bir AWS CLI yedekleme betiği çalıştırmaya çalışıyorum. Bir içerme dosyasındaki çizgiler arasında dolaşır, bu yolları S3'e kadar yedekler ve çıktıyı bir günlük dosyasına döker. Bu komutu doğrudan çalıştırdığımda, hatasız çalışıyor. CRON üzerinden çalıştırdığımda çıktı günlüğümde "Kimlik bilgileri bulunamıyor" hatası alıyorum.

Kabuk betiği:

AWS_CONFIG_FILE="~/.aws/config"

while read p; do
 /usr/local/bin/aws s3 cp $p s3://PATH/TO/BUCKET --recursive >> /PATH/TO/LOG 2>&1
done </PATH/TO/INCLUDE/include.txt

Satırı sadece config dosyasını görmeye başladım, hatayı görmeye başladım, düzeltebileceğimi düşünüyorum (AWS'nin varsayılan olarak göründüğü yer olmasına emin olduğum halde).

Shell betiği root olarak çalışıyor. AWS config dosyasını belirtilen yerde görebiliyorum. Ve hepsi bana iyi geliyor (dediğim gibi, CRON'un dışında iyi çalışıyor).

Doğrudan çalıştırdığınızda çalışır, ancak crondan değil, çevrede muhtemelen farklı bir şey vardır. Yaparak ortamınızı etkileşimli olarak kaydedebilirsiniz.

set | sort > env.interactive

Ve betiğinde de aynı şeyi yap.

set | sort > /tmp/env.cron

Ve sonra diff /tmp/env.cron env.interactiveönemli olan ne bakın. Gibi şeyler PATHen muhtemel suçlulardır.

Bir işi crontab'dan çalıştırdığınızda, $HOME ortam değişkeniniz/

Amazon istemcisi ya arar

~/.aws/config

veya

~/.aws/credentials

Eğer $HOME= ise /, müşteri bu dosyaları bulamaz

Çalışmasını sağlamak için, betiğinizi güncellemek için gerçek bir giriş dizini verecek şekilde güncelleyin. $HOME

export HOME=/root

ve sonra bir config veya kimlik bilgisi dosyalarını

/root/.aws/

Bu sorunu şu şekilde çözebildim :

export AWS_CONFIG_FILE="/root/.aws/config"
export AWS_ACCESS_KEY_ID=XXXX
export AWS_SECRET_ACCESS_KEY=YYYY

Bu kodu crontab -e içine çalıştırılacak komut satırından önce koyun

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Aws cli aracının ikili dosyaları altında kuruludur /usr/local/bin/aws.

Sahip olduğum hata cron kullanıcısının /usr/local/bin/awsçalışırken erişemeyeceği ; sadece erişebilir/usr/bin/

Yaptığım şey bir bağlantı oluşturmaktı. /usr/bin aşağıdaki komutu içeren aws için .

root@gateway:~# ln -s /usr/local/bin/aws /usr/bin/aws

Ayrıca betiğimde bazı değişiklikler de ekledim; İşte örnek bir fonksiyon:

starter () {
    echo "
    ==================================================

    Starting Instance

    ==================================================
    "

    /usr/bin/aws ec2 start-instances --instance-ids $instance --region us-east-1

    sleep 30

    echo "Assigning IP Address "

    /usr/bin/aws ec2 associate-address --instance-id $instance  --region us-east-1 --public-ip XX.XX.XX.XX

}

Ve cron girişi:

30 5 * * * sh /usr/local/cron/magentocron.sh

Bu yöntem benim için çalıştı.

.bashrcKullanıcının varsayılan dosyasındaki bu satır, etkileşimli olmayan kabukların tam kullanıcı ortamını almasını önler (PATH değişkeni dahil):

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

$HOME/.bashrcEtkileşimli olmayan bir bağlamda yürütülmesine izin vermek için satırı yorumlayın .

Ayrıca sourceortamın doğru şekilde kurulmasını sağlamak için kabuk komut dosyama açık bir komut eklemem gerekiyordu:

#!/bin/bash
source $HOME/.bashrc

Ek bilgi için bu cevaba bakınız .

Hepimiz biliyoruz ki $ PATH çevre yolu değişkeni ikilik konumlara sahiptir. $ Crontab of PATH, awscli konumunda olmayabilir.

Yapabileceğin şey, awscli binary yolunu bulmak.

# which aws
/usr/local/bin/aws

ve betiğinizin başına (shebang'dan sonra) aşağıdaki satırı ekleyerek crontab'ın $ PATH dizinine ekleyin.

PATH=$PATH:/usr/local/bin/

Bu benim için çalıştı !!!

Bunun mükemmel bir çözüm olmadığını biliyorum ama bu benim için işe yaradı:

export HOME=/home/user
export AWS_CONFIG_FILE="/home/user/.aws/config"
export AWS_ACCESS_KEY_ID=XXX
export AWS_SECRET_ACCESS_KEY=XXX

Sadece bazı katma değer eklemek için, awscliPIP üzerinden yüklenen aracı kullanırken yeni bash sürümüyle ilgili bir sorunum vardı , bu araçla hiçbir şey yeni bash sürümleriyle çalışmayacaktı.

Bunu yükleyerek çözebildim aws-apitools-ec2.

yum install -y aws-apitools-ec2 

Daha fazla başvuru için rehberini ekliyorum.

http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ec2-clt.pdf

Aynı sorunu yaşadım, ancak cder girişimden stderr yönlendirmesini çıkardıktan sonra ( 2>@1) aws: command not foundkayıt defterinde gördüm .

Bunun nedeni AWS cli'nin kullanıcının giriş klasörüne kurulmuş olması ve .bash_profileAWS cli yolunu eklemek için kullanıcıma bir satır eklemiş olmamdır $PATH. İşin garibi, bu aslında AWS cli kurulum belgelerinin size kurulumunu söyleme şekli . Ancak, kullanıcının .bash_profilecrontab'ı yürütüldüğünde kullanıcı alışmaz (en azından benim çevremde değil).

Bu yüzden bunu düzeltmek için tek yaptığım, crontab betiğimin de kendi yolunda aws cli'larının olmasını sağlamaktı. Yani senaryomun shebang altında, şimdi var PATH=~/.local/bin:$PATH.

Benim için bu hile yaptı:

#!/bin/bash

HOME=/home/ubuntu
AWS_CONFIG_FILE="/home/ubuntu/.aws/config"

aws ec2 describe-instances #or whatever command you need to use.

Bugünün EC2 örneklerinde varsayılan kullanıcı ubuntu'dur ve kök klasör bu kullanıcıların giriş klasörüdür. Aws cli'nin de var olduğu yer burası.

En iyisi değil, fakat AWS istemcisi komutlarından önce config kodunu doğrudan shell / bash betiğimde sağlamak zorunda kaldım. sevmek:

#!/bin/bash

export AWS_ACCESS_KEY_ID=<ZZZ>
export AWS_SECRET_ACCESS_KEY=<AAA>
export AWS_DEFAULT_REGION=<BBB>
aws s3 cp ....