連続AWS弾性豆の茎展開

クラウド・コンピューティングは日々進化しており、ヴァーセルやNetlifyのようなサービスのおかげで、誰もが2つのクリックで無限のスケーリングをして、サーバー側のレンダリングされたブログを展開することができます.しかし、新しいベンダーの評価が6から12ヶ月かかる企業の世界で働くとき、あなたが使用しているコードリポジトリにAWSからのどんな通信も防ぐためにエンタープライズVPNをその上に加えて、エンタープライズVPNを加えてください、そして、あなたはあなたのプロジェクトのZIPアーカイブをそれぞれの新しいリリースのためにAWSポータルに落としています.
涼しくない.
私自身の健全性のために、私はVPNで保護されたコードリポジトリからAWSまで展開を自動化する方法を見つけなければなりませんでした、そして、いくつかのbashスクリプトを使用してCI/CDパイプラインより良い場所ですか?私が管理したAWS CLIを活用すると、スクリプトは5ブロックで作られています.
ファイルのクリーニング、書き込みの修正、および作成.ZIPアーカイブ
同じアーカイブが既に配備されているかどうかを確認する
アーカイブをS 3にアップロードする
エラスティック・ブランカを展開する
展開が成功したかどうかを調べる
以下はLALAVELプロジェクトの完全な例です.

#!/bin/bash

archive="archive.zip"
s3_bucket="elasticbeanstalk-eu-west-3-something"
application_name="myapp"
application_environment="myapp-env"
git_hash=$(git rev-parse --short HEAD)

if [ -f "$archive" ] ; then
    printf "Delete previously created archive\n"
    rm "$archive"
fi

# You might want to delete some files before creating the archive
printf "Delete storage files\n"
rm -rf storage/framework/cache/data/*
rm -rf storage/framework/views/*
rm -rf storage/framework/sessions/*

# Force restricted permission for all files and directories
printf "Apply restricted files and directories permissions\n"
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

# Give a bit more permissions where it's needed 
chmod -R ug+rwx storage bootstrap/cache

# Create the archive, exclude .env tests, and vendor dependencies that will be installed by EBS
printf "Create the code archive\n"  
zip -q -r $archive * -x .env -x tests\* -x vendor\*

# Check that the latest archive on s3 is not the same as the one we just created to avoid useless deployments
printf "Get the latest deployment checksum\n"
CURRENT_MD5=$(md5sum $archive | cut -d ' ' -f1)
LATEST_MD5=$(aws s3api head-object --bucket $s3_bucket --key $archive | jq -r '.Metadata.md5')

if [ "$CURRENT_MD5" = "$LATEST_MD5" ]; then
    # No deploy required
    printf "The Latest project version is already deployed\n"
else
    # Save the archive to S3 with the MD5 checksum in metadata to simplify checks in the next deployment
    printf "Upload the archive to AWS S3\n"
    aws s3 cp $archive s3://$s3_bucket/ --metadata md5="$CURRENT_MD5"

    # Create a new Elastic Beanstalk application version
    printf "Create EBS application version\n"
    aws elasticbeanstalk create-application-version \
        --application-name $application_name \
        --version-label $git_hash \
        --source-bundle S3Bucket="$s3_bucket",S3Key="$archive"

    # Trigger Elastic Beanstalk environment update, a.k.a, actually starting the deployment
    printf "Update EBS environment\n"
    aws elasticbeanstalk update-environment \
        --application-name $application_name \
        --environment-name $application_environment \
        --version-label $git_hash

    # Wait until environment is updated
    printf "Wait for EBS to update the environment\n"
    aws elasticbeanstalk wait environment-updated \
        --version-label $git_hash

    # Check if deploy is successful
    printf "Get EBS environment Health Status\n"
    HEALTH_STATUS=$(aws elasticbeanstalk describe-environment-health \
    --environment-name $application_environment \
     --attribute-names HealthStatus | jq -r '.HealthStatus') 

    if [ "$HEALTH_STATUS" = "Ok" ]; then
        printf "Deploy successful\n"
    else
        printf "Something went wrong during deploy [Status: $HEALTH_STATUS]\n"
    fi
fi

このスクリプトはAWS CLIへのすべての呼び出しが失敗しないと仮定します、それは偉大でありません、しかし、AWSが予想通りに働いているときの99.9 %のために、それは仕事をして、新しいプル要求が展開される必要があるAWSポータルに毎回、ZIPファイルを手でアップロードする耐えられない痛みを避けます.