SIOS Coati開発チームの清水です。
先日のアップデートで、SIOS Coatiで監視できるOSとして Windows Server 2016 に対応しました！
すでにSIOS Coatiをご利用の方は、特別な対応をしていただく必要はございません。
これまでと同様にセットアップしていただくことで、すぐに監視をはじめることができます。
まだSIOS Coatiを使ったことのないお客様で、Windows Server 2016をご利用の方は、是非この機会に無料トライアルでお試しください。
無料トライアルは こちらの製品ページ から申し込むことができます！
食欲の秋に(体重的な意味で)危機感を覚える Coati開発チーム 沼野井です。
でも秋の味覚を食べないという選択肢はないですよね!
ansibleで、
VPCと、それに紐づく サブネット、ルートテーブル、セキュリティグループを作ったCoatiだった・・・
というわけで、前回に続いて、ansibleでEC2・VPC環境を構築していこうと思います。
今回は、
します。
Coatiチームで使用している、環境デプロイ用のPlaybookのディレクトリ構成と、変数定義をしているall.ymlの内容をもう一回掲載します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
├── ansible.cfg ├── group_vars │ └── all.yml # 変数定義 ├── hosts ├── roles │ ├── VPC │ │ └── tasks │ │ ├── main.yml # VPC.ymlの本体 │ │ ├── setup_ec2.yml # VPC.ymlの本体 │ │ └── setup_vpc.yml # VPC.ymlの本体 │ └── vpc_peering │ └── tasks │ ├── main.yml # VPC.ymlの本体 │ └── vpc_peering.yml # create_vpc_peering.ymlの本体 ├── create_vpc_peering.yml # 実行するplaybook └── VPC.yml # 実行するplaybook |
group_vars/all.yml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
PEERING_VPC_ID: vpc-XXXXXXXX # お客様のVPC ID PEERING_VPC_CIDR: XXX.XXX.XXX.XXX/XX # お客様のVPC CIDR CUSTOMER: Coati Coffee.break.fun # お客様名 EMAIL: COATI@coati.coffee_break_fun.com # お客様のEメールアドレス PREFIX: "CoatiManager_{{ CUSTOMER }}" # VPC, Subnet, ルートテーブル, インスタンス名のprefix REGION: ap-northeast-1 # リージョン(東京) OFFICE_IP: ZZZ.ZZZ.ZZZ.ZZZ # SIOSのオペレーション端末のIPアドレス OFFICE_IP_CIDR: "{{ OFFICE_IP }}/32" # SIOSのオペレーション端末のIPアドレスのCIDR VPC_NAME: "{{ PREFIX }}_VPC" # VPC名称 VPC_CIDR_LEFT: YYY.YYY.YYY # Coati ManagerのCIDRの左部分 VPC_CIDR_BLOCK: "{{ VPC_CIDR_LEFT }}.0/23" # VPCのCIDR Block SUBNET1_NAME: "{{ PREFIX }}_SUBNET1" # Subnet名 SUBNET1_CIDR_BLOCK: "{{ VPC_CIDR_LEFT }}.0/24" # SubnetのCIDR Block ROUTETABLE1_NAME: "{{ PREFIX }}_RT1" # ルートテーブル名 KEY_PAIR: XXXXXXXXXXXXXXXXXXXXXXXXXXX # Coati Managerインスタンスにアクセスするためのキーペア INSTANCE_TYPE: t2.small # Coati Managerインスタンスのインスタンス・タイプ EC2_NAME: "{{ PREFIX }}" # Coati Managerインスタンス名 EC2_PRIVATE_IP: "{{ VPC_CIDR_LEFT }}.10" # Coati ManagerインスタンスのプライベートIPアドレス IAM_ROLE: XXXXXXXXXXXX # Coati Managerインスタンスに割り当てるIAMロール SIOS_ACCOUNT_ID: 987654321098 # サイオスのAWSアカウントID |
作成したVPC内にEC2インスタンスを作成するplaybook, setup_ec2.ymlの中身を見ていきます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
- ec2_remote_facts: region: "{{ REGION }}" filters: private-ip-address: "{{ EC2_PRIVATE_IP }}" subnet-id: "{{ SUBNET_ID }}" register: ec2 # Search for the AMI tagged "Role: CoatiManager" and "Version: Master" - ec2_ami_find: owner: self region: "{{ REGION }}" ami_tags: Role: CoatiManager Version: Master sort: creationDate sort_order: descending sort_end: 1 no_result_action: fail register: ami_find - name: Create AWS Instance ec2: key_name: "{{ KEY_PAIR }}" instance_type: "{{ INSTANCE_TYPE }}" image: "{{ ami_find.results[0].ami_id }}" region: "{{ REGION }}" vpc_subnet_id: "{{ SUBNET_ID }}" private_ip: "{{ EC2_PRIVATE_IP }}" instance_profile_name: "{{ IAM_ROLE }}" assign_public_ip: no wait: yes instance_tags: Name: "{{ EC2_NAME }}" Role: CoatiManager volumes: - device_name: /dev/sda1 volume_type: gp2 volume_size: 20 delete_on_termination: true when: not ec2.instances # refresh remote facts - ec2_remote_facts: region: "{{ REGION }}" filters: private-ip-address: "{{ EC2_PRIVATE_IP }}" subnet-id: "{{ SUBNET_ID }}" register: ec2 - name: Associate EIP for instance ec2_eip: region: "{{ REGION }}" device_id: "{{ ec2.instances[0].id }}" reuse_existing_ip_allowed: yes in_vpc: yes register: eip |
順にみていきます。
|
1 2 3 4 5 6 7 8 |
- ec2_remote_facts: region: "{{ REGION }}" filters: private-ip-address: "{{ EC2_PRIVATE_IP }}" subnet-id: "{{ SUBNET_ID }}" register: ec2 |
ec2_remote_factsはAWS内の(複数の)インスタンスの情報を集めるモジュールです。
IPアドレス・サブネット名など多種のFilterを設定して検索することができます。
今回は、SUBNET_IDのサブネット、EC2_PRIVATE_IPのIPアドレスのインスタンスが、環境内に既に存在しているかどうかをチェックしています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
なお、<span style="font-family: georgia, palatino, serif;"><strong>ec2_remote_facts</strong></span> は ansible 2.4 では<strong>非推奨</strong>モジュールとなっており、代わりに <strong><span style="font-family: georgia, palatino, serif;"><a href="http://docs.ansible.com/ansible/latest/ec2_instance_facts_module.html#ec2-instance-facts">ec2_instance_facts</a></span></strong> がリリースされています。 - ec2_ami_find: owner: self region: "{{ REGION }}" ami_tags: Role: CoatiManager Version: Master sort: creationDate sort_order: descending sort_end: 1 no_result_action: fail register: ami_find |
続いて、AMIの検索です。
Coati開発チームでは、Coati Manager用のAMIをあらかじめ用意していて、タグ Role=CoatiManager をつけています。ec2_ami_findモジュールを利用して、タグをキーにしてAMIのIDを取得します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
- name: Create AWS Instance ec2: key_name: "{{ KEY_PAIR }}" instance_type: "{{ INSTANCE_TYPE }}" image: "{{ ami_find.results[0].ami_id }}" region: "{{ REGION }}" vpc_subnet_id: "{{ SUBNET_ID }}" private_ip: "{{ EC2_PRIVATE_IP }}" instance_profile_name: "{{ IAM_ROLE }}" assign_public_ip: no wait: yes instance_tags: Name: "{{ EC2_NAME }}" Role: CoatiManager volumes: - device_name: /dev/sda1 volume_type: gp2 volume_size: 20 delete_on_termination: true when: not ec2.instances |
いよいよ、インスタンスの作成です。そのものズバリな ec2モジュールを使います。
パラメータはAWS Management ConsoleでEC2インスタンスを作成する際にお馴染みな面々を指定していきます。imageには、さきほど検索したAMIのIDを指定しています。
|
1 |
<span style="font-size: 12pt; font-family: arial, helvetica, sans-serif;"><code> image: "{{ ami_find.results[0].ami_id }}"</code></span> |
instance_tags: で Name=名前, Role=CoatiManager、というタグ付けもしています。
最後の
|
1 |
<span style="font-size: 12pt; font-family: arial, helvetica, sans-serif;"><code> when: not ec2.instances</code></span> |
は、ec2.instancesがある場合にはインスタンスの作成をしない、という条件判定です。
一番最初に ec2_remote_factモジュールで同じIPアドレスとサブネットのインスタンスを検索したときに、もし既に存在している場合には変数ec2.instancesなんらかの値が入っているはずですので、その場合にはインスタンスの作成は行わないようにしています。
VPCピアリングを行うplaybook, vpc_peering.ymlです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
--- - name: include vars include_vars: '/tmp/__temp_fact__.yml' - name: Setup VPC peering for customer ec2_vpc_peer: region: "{{ REGION }}" vpc_id: "{{ manager_vpc_id }}" peer_vpc_id: "{{ PEERING_VPC_ID }}" peer_owner_id: "{{ PEER_OWNER_ID }}" state: present tags: Name: Peering connection for "{{ CUSTOMER }}" register: vpc_peering_for_customer |
ec2_vpc_peerモジュールを使い、接続するVPCをそれぞれ指定して、VPCピアリング接続を行います。
このplaybookを実行したあと、お客様に接続を承認していただくと、晴れて両VPCがピアリング接続されることになります。
ついに、Coati環境が完成しました!
いかがでしたでしょうか?
今後も、役に立ちそうなplaybookを紹介していく予定ですので、よろしくお願いします。
皆様、こんにちは、SIOS Coatiのマーケティング担当をしております吉岡です。
先日ご案内しましたAWS Cloud Roadshow 2017 名古屋はブースに数多くの方にお越しいただき、大盛況のもと終わりました！
さて、ちょっと告知が遅くなってしまいましたが、
2017年10月31日（火）に、アマゾン ウェブ サービス ジャパン株式会社主催の無料クラウドカンファレンスであるAWS Cloud Roadshow 2017 福岡に出展いたします。
このイベントもここで最後となりますが、多くの方にSIOS Coatiを知っていただければと思います。
展示ブースでは、Amazon EC2上で稼働するアプリケーションを自動復旧するクラウドサービスSIOS Coatiをご紹介します。ぜひ、お立ち寄りください。
日時：2017年10月27日（水） 10：00～20：00（開場：9：30）
会場：ANA クラウンプラザホテル福岡
（〒812-0011 福岡県福岡市博多区博多駅前３丁目３−３）
本イベントの詳細、お申込みはこちらのサイトをご覧ください。
こんにちは、SIOS Coati開発チームの黒田です。
開発や検証などを目的とした環境では、不要なEC2インスタンスの停止や削除は、
システムのランニングコスト削減に対して小さくない効果があります。
特に前月からはEC2の課金単位が、時間単位から秒単位へ変更となっておりますので、
停止・削除によるコスト削減がより効果的なものとなっています。
このような停止・削除といった操作は、EC2インスタンスの数が少ないうちは手動で
行われても良いかも知れませんが、実は地味に面倒な作業でもあります。
うっかり止め忘れたために想定以上の費用がかかってしまうケースも…？
そこで今回は、AWS Lambdaのスケジュール機能を利用した、
シンプルなEC2インスタンスの自動起動・停止方法を紹介したいと思います。
基本動作としては、全てのリージョンで、以下の特定タグが設定されているEC2インスタンスを
スケジュールされた時間に自動起動・停止します。
EC2インスタンスタグの動作一覧
| key | value | 動作 |
|---|---|---|
| Ec2StartStop | Auto | 起動・停止を実行 |
| Ec2StartStop | Start | 起動のみ実行 |
| Ec2StartStop | Stop | 停止のみ実行 |
※タグのkeyやvalue名は、環境にあわせて設定してください。
1.AWS マネージドコンソールへログインしてからAWS Lamdbaサービスを選択し、関数の作成を選択します。
2.トリガーの設定をスキップし、次へを選択します。
3.Lamdba関数の「名前」を入力し、ランタイムは「Python3.6」を選択します。
4.コードをインラインで編集します。
コードのサンプルは、以下になります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
import boto3 def lambda_handler(event, context): awsRegions = boto3.client('ec2').describe_regions()['Regions'] for region in awsRegions: awsregion = region['RegionName'] ec2 = boto3.resource('ec2', region_name=awsregion) instances = ec2.instances.all() start_list = [] stop_list = [] action = event['Action'] for i in instances: if i.tags != None: for t in i.tags: if t['Key'] == 'Ec2StartStop': if t['Value'] == 'Auto' or t['Value'] == action: if action == 'Start' and i.state['Name'] == 'stopped': start_list.append(i.instance_id) elif action == 'Stop' and i.state['Name'] == 'running': stop_list.append(i.instance_id) if start_list: print('Starting', len(start_list), 'instances', start_list) ec2.instances.filter(InstanceIds=start_list).start() elif stop_list: print('Stopping', len(stop_list), 'instances', stop_list) ec2.instances.filter(InstanceIds=stop_list).stop() |
※必要に応じてコードを変更してください。
5.「Lambda 関数ハンドラおよびロール」の「ロール」で、「カスタムロールの作成」を選択します。
6.「ロール名」と「ポリシードキュメント」を入力してください。
ポリシードキュメントは、以下になります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:*:*" }, { "Effect": "Allow", "Action": [ "ec2:Describe*", "ec2:Start*", "ec2:Stop*" ], "Resource": "*" } ] } |
7.「詳細設定」の「タイムアウト」値の変更
デフォルト3秒から30秒へ
※タイムアウト値は、環境にあわせて変更してください。
8.まずは、起動のスケジュール設定をします。AWS CloudWatchサービス画面に移動し、「イベント」->「ルール作成」を選択してください。
9.「イベントソース」のスケジュールを選択し、「Cron式」を選択して、起動時間のcron式を入力してください。
cron式(UTC)
|
1 2 |
30 23 ? * MON-FRI * |
※環境にあわせて起動時間を変更してください。
10.「ターゲットの追加」を選択し、作成したLambda関数(Ec2StartStop)を選択します。「入力の設定」の「定数(JSONテキスト)」を選択し、以下を入力してください。
定数(JSONテキスト)
|
1 2 |
{"Action": "Start"} |
11.「名前」を入力と「状態」の「有効」をチェックし、「ルールの作成」を選択します。
12.停止スケジュールの設定をします。以下のようにcron式と定数(JSONテキスト)を入れ替え、8～11の手順を繰り返してください。
cron式(UTC)
|
1 2 |
00 13 ? * MON-FRI * |
※環境にあわせて停止時間を変更してください。
定数(JSONテキスト)
|
1 2 |
{"Action": "Stop"} |
13.動作確認を行います。EC2インスタンスにタグを設定し、スケジュールされた時間にEC2インスタンスが起動・停止されているかを確認してください。
以上、AWS Lambdaのスケジュール機能を利用したシンプルなEC2インスタンスの自動起動・停止方法の紹介でした。
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
を実行すれば良さそうです。いざやってみると…
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
[ec2-user@ip-172-16-0-38 ~]$ curl -s https://packagecloud.io/install/repositorie s/github/git-lfs/script.rpm.sh | sudo bash ... 略 ... The repository is setup! You can now install packages. [ec2-user@ip-172-16-0-38 ~]$ sudo yum install git-lfs Loaded plugins: amazon-id, rhui-lb, security Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package git-lfs.x86_64 0:2.3.0-1.el6 will be installed --> Processing Dependency: git >= 1.8.2 for package: git-lfs-2.3.0-1.el6.x86_64 .. 略 ... Error: Package: perl-Git-2.4.5-1.el6.noarch (github_git-lfs) Requires: perl(SVN::Ra) Error: Package: perl-Git-2.4.5-1.el6.noarch (github_git-lfs) Requires: perl(SVN::Delta) Error: Package: perl-Git-2.4.5-1.el6.noarch (github_git-lfs) Requires: perl(SVN::Core) Error: Package: perl-Git-2.4.5-1.el6.noarch (github_git-lfs) Requires: perl(YAML::Any) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [ec2-user@ip-172-16-0-38 ~]$ |
だめでした。どうやらいくつかのパッケージがみつからないようです。
結論から書くと、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
以上です！
無事インストールできました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
[ec2-user@ip-172-16-0-38 ~]$ sudo yum install git-lfs Loaded plugins: amazon-id, rhui-lb, security Setting up Install Process rhui-REGION-rhel-server-releases | 3.5 kB 00:00 rhui-REGION-rhel-server-releases-optional | 3.5 kB 00:00 rhui-REGION-rhel-server-releases-optional/primary_db | 5.5 MB 00:00 rhui-REGION-rhel-server-rh-common | 3.8 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package git-lfs.x86_64 0:2.3.0-1.el6 will be installed --> Processing Dependency: git >= 1.8.2 for package: git-lfs-2.3.0-1.el6.x86_64 ... 略 ... Installed: git-lfs.x86_64 0:2.3.0-1.el6 Dependency Installed: apr.x86_64 0:1.3.9-5.el6_2 apr-util.x86_64 0:1.3.9-3.el6_0.1 git.x86_64 0:2.4.5-1.el6 neon.x86_64 0:0.29.3-3.el6_4 pakchois.x86_64 0:0.4-3.2.el6 perl-Error.noarch 1:0.17015-4.el6 perl-Git.noarch 0:2.4.5-1.el6 perl-YAML.noarch 0:0.70-4.el6 subversion.x86_64 0:1.6.11-15.el6_7 subversion-perl.x86_64 0:1.6.11-15.el6_7 Complete! |
