クラウド

シンプルなEC2インスタンスの自動起動・停止について

こんにちは、SIOS Coati開発チームの黒田です。

開発や検証などを目的とした環境では、不要なEC2インスタンスの停止や削除は、
システムのランニングコスト削減に対して小さくない効果があります。
特に前月からはEC2の課金単位が、時間単位から秒単位へ変更となっておりますので、
停止・削除によるコスト削減がより効果的なものとなっています。

このような停止・削除といった操作は、EC2インスタンスの数が少ないうちは手動で
行われても良いかも知れませんが、実は地味に面倒な作業でもあります。
うっかり止め忘れたために想定以上の費用がかかってしまうケースも…?

そこで今回は、AWS Lambdaのスケジュール機能を利用した、
シンプルなEC2インスタンスの自動起動・停止方法を紹介したいと思います。

基本動作としては、全てのリージョンで、以下の特定タグが設定されているEC2インスタンスを
スケジュールされた時間に自動起動・停止します。

EC2インスタンスタグの動作一覧

key value 動作
Ec2StartStop Auto 起動・停止を実行
Ec2StartStop Start 起動のみ実行
Ec2StartStop Stop 停止のみ実行

※タグのkeyやvalue名は、環境にあわせて設定してください。

設定するAWSサービス

  • Lambda
  • IAM Role
  • CloudWatch Event

設定方法

Lambda

1.AWS マネージドコンソールへログインしてからAWS Lamdbaサービスを選択し、関数の作成を選択します。


 

2.トリガーの設定をスキップし、次へを選択します。


 

3.Lamdba関数の「名前」を入力し、ランタイムは「Python3.6」を選択します。


 

4.コードをインラインで編集します。

コードのサンプルは、以下になります。

※必要に応じてコードを変更してください。

IAM Role

5.「Lambda 関数ハンドラおよびロール」の「ロール」で、「カスタムロールの作成」を選択します。


 

6.「ロール名」と「ポリシードキュメント」を入力してください。

ポリシードキュメントは、以下になります。


 

7.「詳細設定」の「タイムアウト」値の変更

デフォルト3秒から30秒へ
※タイムアウト値は、環境にあわせて変更してください。

CloudWatch Event

 

8.まずは、起動のスケジュール設定をします。AWS CloudWatchサービス画面に移動し、「イベント」->「ルール作成」を選択してください。


 

9.「イベントソース」のスケジュールを選択し、「Cron式」を選択して、起動時間のcron式を入力してください。

cron式(UTC)

※環境にあわせて起動時間を変更してください。


 

10.「ターゲットの追加」を選択し、作成したLambda関数(Ec2StartStop)を選択します。「入力の設定」の「定数(JSONテキスト)」を選択し、以下を入力してください。

定数(JSONテキスト)


 

11.「名前」を入力と「状態」の「有効」をチェックし、「ルールの作成」を選択します。


 

12.停止スケジュールの設定をします。以下のようにcron式と定数(JSONテキスト)を入れ替え、8~11の手順を繰り返してください。

cron式(UTC)

※環境にあわせて停止時間を変更してください。

定数(JSONテキスト)


 

13.動作確認を行います。EC2インスタンスにタグを設定し、スケジュールされた時間にEC2インスタンスが起動・停止されているかを確認してください。

以上、AWS Lambdaのスケジュール機能を利用したシンプルなEC2インスタンスの自動起動・停止方法の紹介でした。

EC2のRHEL6にgit-lfsをインストールする

SIOS Coati開発チームの清水です。

今回はSIOS Coatiのサービスとは関係なく、開発メンバーがハマった技術TIPSを共有したいと思います。


SIOS Coatiチームではコードの管理にgitを利用しており、そのgitのエクステンションに、サイズが大きいファイルも扱いやすくする git-lfs があります。

今回は git-lfs を EC2 の Red Hat Enterprise Linux 6.7_HVM_20160219 AMI から作成したインスタンスにインストールします。
公式の インストール手順 をみると

curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.rpm.sh | sudo bash
sudo yum install git-lfs

を実行すれば良さそうです。いざやってみると…

だめでした。どうやらいくつかのパッケージがみつからないようです。

解決策

結論から書くと、yumで「rhui-REGION-rhel-server-releases-optional」リポジトリを有効にすると、git-lfsに必要なパッケージがインストールできるようになります。
これは git-lfs に必要な perl-Git がRHEL6のデフォルトのリポジトリには入っていないためで、別途、他のリポジトリからインストールできるように設定を変更してあげる必要があります。

リポジトリを有効にするには /etc/yum.repos.d/redhat-rhui.repo をルート権限で編集します。

sudo vim /etc/yum.repos.d/redhat-rhui.repo

その中にある [rhui-REGION-rhel-server-releases-optional]セクション の 「enabled=0」を「enabled=1」に変更して保存します。

[rhui-REGION-rhel-server-releases-optional]
name=Red Hat Enterprise Linux Server 6 Optional (RPMs)
mirrorlist=https://rhui2-cds01.REGION.aws.ce.redhat.com/pulp/mirror/content/dist/rhel/rhui/server/6/$releasever/$basearch/optional/os
enabled=1 ← 0 から 1 に変更する
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify=1
sslclientkey=/etc/pki/rhui/content-rhel6.key
sslclientcert=/etc/pki/rhui/product/content-rhel6.crt
sslcacert=/etc/pki/rhui/cdn.redhat.com-chain.crt

以上です!

修正後

無事インストールできました。

AWS Cloud Roadshow大阪出展レポート

皆様、こんにちは、SIOS Coatiのマーケティング担当をしております吉岡です。

9/21に開催されましたアマゾンウェブサービスジャパン社が主催する「AWS Cloud Roadshow大阪」に出展しました。

今回もSIOS Coatiを皆様に知っていただくいい機会となり、様々な方々にブースにお越しいただきました。

今回も多くのCoatiグッズを配置し、ブースでお出迎え。

今回のイベントはかなり真剣にAWSの導入を考えている方々が多くいた感じですね。
ブースにはセッションとセッションの合間に予想以上にかなり多くの方が来場され、SIOS Coatiのサービスをご紹介させていただけました!

次回は9/27の名古屋で、こちらもとても楽しみです!
9/27(水)名古屋会場

ansibleによるEC2・VPC環境構築(その2)

シルバーウィークに遅い夏休みを満喫した沼野井です。

・・・本当はこれ書いてるの9/14なんですが、公開日の調整の結果↑にような挨拶となりました。
こんな笑点みたいな挨拶をする機会があるとは思ってもいませんでした。

 

前回までのあらすじ

 

この構成をansibleで作ろう、と思うCoatiだった・・・

 

というわけで、前回の続きで、ansibleによるEC2・VPC環境構築の、実際のplaybookの内容についてです。

 

Playbookの内容

あ、前回すっかり忘れていたのですが、使用しているansibleのバージョンは 2.3 です。ご承知おきください。

Coatiチームで使用している、環境デプロイ用のPlaybookのディレクトリ構成は以下のようになっています。

なんぞこれ? と目がハテナな方はこちら(英語ですが)
ansibleの標準的なディレクトリ構成と思っていただいてよいと思います。

個々に中身をご紹介していきます。

(1) group_vars/all.yml

全playbookで使う変数を定義しています。以下のような感じです。

冒頭の5行の、

はお客様のお申込み内容に従って入力しています。残りの項目は固定値または、↑の内容から自動的に作成されるという寸法です。

(2) VPC.yml

VPCを作成して、その中にCoati Managerインスタンスを作成するplaybookです。インスタンスも作るのにVPC.ymlってネーミングがイマイチです。すみません。

そのネーミングのイマイチなVPC.ymlの中身はこんな感じです。

こんだけ。

これは、「ロールVPCのタスクを実行しなさいね」と言ってるだけです。
ロールVPCのタスクとは

こいつらです。実際にはmain.ymlがまず呼ばれます。

main.ymlは

これもこんだけで、本体であるsetup_vpc.ymlとsetup_ec2.ymlをincludeしています。

本体の1つ、setup_vpc.ymlの中身を見ていきます。

一転して長くなりましたね。本体ですから、実際いろいろやってます。順にみていきますと、

ec2_factsは(playbookを実行している)ホストの情報を色々集めてくるモジュールです。今回は、パブリックIPアドレスを取得するため(だけ)に使っています。
registerは、集めたネタを変数(この場合 変数名もec2_facts)に格納します。
実際にec2_factsを使っているところは後ほど!

Coati Managerインスタンスを格納するVPCを作成しています。ec2_vpc_netモジュールを使います。

{{ VPC_NAME }} は group_vars/all.ymlで定義してあるものです(ansibleでは、”{{}}”で囲むと変数の値が取り出せます)
同様に{{VPC_CIDR_BLOCK}}, {{ REGION }}もgroup_vars/all.ymlで定義しています。
あと、tags:を利用して、 作成したVPCにRole=CoatiManager というタグをつけています。

ec2_vpc_netモジュールは、作成したVPCのIDなどを実行時の結果として戻しますので、実行結果をregisterで変数vpcに格納しておいて、あとで使うことができます。

作ったVPCにsubnetを作成します。今作ったVPC IDが必要です。ここで、さきほどregisterで保存した変数vpcを使います。VPC IDは、

のようにして参照できます。

同様に、作成したVPCにインターネットゲートウェイを作成しています。ec2_vpc_igwモジュールを使います。

ルートテーブルの作成です。ec2_vpc_route_tableモジュールを使います。ちょっとパラメータが増えましたが、基本は同じです。
なお、ここでは送信先を0.0.0.0/0にしていますが、適切に設定してくださいね!

セキュリティグループの作成です。ec2_groupモジュールを使います。以下のポートに穴をあけています。

ポート番号 ソース 備考
80 0.0.0.0/0(※)
22 手元のPCのIPアドレス 私がオフィスから直接ログインして操作するため
22 オペレーション端末のIPアドレス オペレーション端末からログインして色々設定するため
-1 手元のPCのIPアドレス ICMPです。ping用
-1 オペレーション端末のIPアドレス ICMPです。ping用

※ここでは0.0.0.0/0と書いてありますが、適切に設定してくださいね!

「オペレーション端末の(グローバル)IPアドレス」の指定に、最初の方で取っておいたec2_factsを使っています。
やっと伏線回収できました!

セキュリティグループ構築その2、です。同じセキュリティグループに割り当てられたインスタンスからのトラフィックを許可しています。

 

ここまでの結果

・・・いかがでしたでしょうか。ここまでで、

 

の構成ができました。

 

少し長くなってしまったので、Coati Managerインスタンスの作成とVPC Peeringの設定は次回にしようと思います!

ソニー様の「マネージドクラウド with AWS」のソリューションメニューとして提供が開始されます!

皆様、こんにちは、SIOS Coatiのマーケティング担当をしております吉岡です。

この度SIOS Coatiはソニーネットワークコミュニケーションズ社が提供する「マネージドクラウド with AWS」のソリューションパッケージとして
販売を開始していただくこととなりました!

詳細はこちらからご覧ください!

こちらのソリューションはAWS Roadshowでご覧いただけますので、ぜひお立ち寄りください!

9/21(木)大阪会場
9/27(水)名古屋会場