Không thể chạy AWS CLI từ CRON (thông tin đăng nhập)

Đang cố gắng chạy tập lệnh sao lưu AWS CLI đơn giản. Nó lặp qua các dòng trong một tệp bao gồm, sao lưu các đường dẫn đó lên đến S3 và chuyển đầu ra thành tệp nhật ký. Khi tôi chạy lệnh này trực tiếp, nó chạy mà không có lỗi. Khi tôi chạy nó thông qua CRON, tôi gặp lỗi "Không thể xác định thông tin đăng nhập" trong nhật ký đầu ra của mình.

Kịch bản shell:

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

Tôi chỉ thêm dòng vào tệp cấu hình sau khi tôi bắt đầu thấy lỗi, nghĩ rằng điều này có thể khắc phục nó (mặc dù tôi khá chắc chắn đó là nơi AWS nhìn theo mặc định).

Shell script đang chạy như root. Tôi có thể thấy tệp cấu hình AWS tại vị trí đã chỉ định. Và tất cả có vẻ tốt với tôi (như tôi đã nói, nó chạy tốt bên ngoài CRON).

Nếu nó hoạt động khi bạn chạy nó trực tiếp nhưng không phải từ cron thì có lẽ có một cái gì đó khác trong môi trường. Bạn có thể cứu môi trường của bạn một cách tương tác bằng cách làm

set | sort > env.interactive

Và làm điều tương tự trong kịch bản của bạn

set | sort > /tmp/env.cron

Và sau đó diff /tmp/env.cron env.interactivevà xem những gì quan trọng. Những thứ như PATHlà thủ phạm có khả năng nhất.

Khi bạn điều hành một công việc từ crontab, $HOMEbiến môi trường của bạn là/

Ứng dụng khách Amazon tìm kiếm một trong hai

~/.aws/config

hoặc là

~/.aws/credentials

Nếu $HOME= /, thì máy khách sẽ không tìm thấy các tệp đó

Để làm cho nó hoạt động, hãy cập nhật tập lệnh của bạn để nó xuất một thư mục chính thực sự cho $HOME

export HOME=/root

và sau đó đặt một tập tin cấu hình hoặc thông tin đăng nhập

/root/.aws/

Tôi đã có thể giải quyết vấn đề này thông qua những điều sau đây :

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

Đặt mã này trước khi dòng lệnh của bạn được thực thi vào crontab -e

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

Các nhị phân của công cụ aws cli được cài đặt bên dưới /usr/local/bin/aws.

Lỗi tôi gặp phải là người dùng cron không thể truy cập /usr/local/bin/awstrong khi chạy; nó chỉ có thể truy cập/usr/bin/

Những gì tôi đã làm là tạo một liên kết trong /usr/binaws với lệnh dưới đây.

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

Tôi cũng đã thêm một số thay đổi trong kịch bản của mình; đây là một hàm mẫu:

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

}

Và mục cron:

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

Phương pháp này làm việc cho tôi.

Dòng này trong .bashrctệp mặc định cho người dùng sẽ ngăn các shell không tương tác nhận được môi trường người dùng đầy đủ (bao gồm cả biến PATH):

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

Nhận xét dòng ra để cho phép $HOME/.bashrcđược thực hiện từ bối cảnh không tương tác.

Tôi cũng đã phải thêm một sourcelệnh rõ ràng vào tập lệnh shell của mình để có được môi trường được thiết lập chính xác:

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

Xem câu trả lời này để biết thêm thông tin.

Chúng ta đều biết rằng biến đường dẫn môi trường $ PATH có vị trí nhị phân. $ PATH của Crontab có thể không có vị trí awscli.

Những gì bạn có thể làm là, tìm đường dẫn của nhị phân awscli.

# which aws
/usr/local/bin/aws

và thêm đường dẫn trong $ PATH của crontab bằng cách thêm dòng dưới đây vào đầu tập lệnh của bạn (sau shebang).

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

Điều này làm việc cho tôi !!!

Tôi biết đó không phải là giải pháp hoàn hảo nhưng nó hiệu quả với tôi:

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

Chỉ cần thêm một số giá trị gia tăng, tôi đã gặp vấn đề với phiên bản bash mới trong khi sử dụng awsclicông cụ được cài đặt qua PIP, tôi thấy rằng sẽ không có gì hoạt động với công cụ này với các phiên bản bash mới.

Tôi đã có thể giải quyết bằng cách cài đặt aws-apitools-ec2này có thể được cài đặt bằng

yum install -y aws-apitools-ec2 

Tôi đang đính kèm hướng dẫn của nó để tham khảo thêm.

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

Tôi đã có cùng một vấn đề, nhưng sau khi loại bỏ chuyển hướng stderr khỏi mục cron của tôi ( 2>@1), tôi đã thấy aws: command not foundtrong nhật ký.

Điều này là do cli AWS đã được cài đặt trong thư mục nhà của người dùng và tôi đã thêm một dòng vào người dùng của .bash_profilemình để thêm đường dẫn AWS cli vào $PATH. Thật kỳ lạ, đây thực tế là cách mà tài liệu cài đặt AWS cli bảo bạn cài đặt nó. Nhưng người dùng .bash_profilekhông được sử dụng khi crontab của người dùng được thực thi (ít nhất là không phải trong môi trường của tôi).

Vì vậy, tất cả những gì tôi đã làm để khắc phục điều này là đảm bảo tập lệnh crontab của tôi cũng có aws cli trong đường dẫn của nó. Vì vậy, dưới shebang của kịch bản của tôi, bây giờ tôi có PATH=~/.local/bin:$PATH.

Đối với tôi điều này đã lừa

#!/bin/bash

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

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

Người dùng mặc định trong các phiên bản EC2 ngày nay là ubfox và thư mục gốc là thư mục chính của người dùng. Đó là nơi cls aws tồn tại là tốt.

Không phải là tốt nhất, nhưng tôi phải cung cấp cấu hình trực tiếp trong tập lệnh shell / bash của mình trước các lệnh máy khách AWS. như:

#!/bin/bash

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