最近は話題のサーバ構成管理ツール Ansible を試したりしています。 Ansible 自体は Python 製ですが、使うに当たっては特に Python の知識は必要とされる事もなく、定義ファイル(Playbook)も YAML ファイルなので気軽に始める事ができました。 また、Capistrano などと同じく SSH で対象サーバに接続さえ出来ればいい、という仕様なので、サーバに余計なパッケージを入れずに済むのも嬉しいです。 その点も Chef や Puppet などより個人的には好みですね。 検証環境は CentOS 6.4 x86_64 になります。 インストール インストールには Python 2.6 以上が必要です。 CentOS 6 系であれば yum で普通に入れれば 2.6 系が入るはずなので問題ないかと思います。 # python -V Python 2.6.6 E

社内勉強会で Ansible の初歩的な発表をしたのでその資料を公開します。 間違い等あるとおもいますが、指摘して頂ければ幸いです。 Ansible とは？ 構成管理ツールです。Chef とか Puppet とかああいうののお仲間です。 Puppet は知りませんが、Chef は少し使って嫌気が差して止めました。 理由は 特殊なことをしようとすると Ruby の知識が必要になる 構成管理「される側」にも Chef が必要(エージェント) が主です。あとなんだかんだ言って結構複雑です。 その点 Ansible は下記の特徴があります。 標準入出力さえできればプラグインの言語は何でも構わない 一つ Ansible が入っているサーバと sshd が動いている対象サーバがあればそれでOK(要するに準備が要らない。もちろん自分自身だけでもOK) 標準(組込みモジュール？)で結構なんでもできる(ただ

この記事は投稿されてから１年以上経っています。内容が古くなっているかもしれませんので、ご注意ください。 まぁパーミッション変更すればいいという話だけど、最初はこんなところでも躓く。 ssh -i <pem flie> ec2-user@<EC2 Public DNS> 上記のようにEC2にSSHで（主に初めて）接続しようとすると以下の様なエラーが出て怒られることがある。 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for 'xxxxxxxxxxx.pem' are too ope

前回コマンド編を書きました。 iwamocchan11.hatenadiary.jp 実際はいくつもモジュールを組み合わせて 使用すると思いますので playbook を書いてみます。 実行環境は以下の通りになります。 # cat /etc/centos-release CentOS release 6.7 (Final) # yum list ansible ansible.noarch 1.9.2-1.el6 @epel playbook は YAML形式で書きます。 Rubyist Magazine - プログラマーのための YAML 入門 (初級編) YAML シンタックス — Ansible Documentation 何はともあれ、書いてみるのが一番。 前回コマンドで実行したものを playbook で書いてみます。 # ansible -i hosts all -m ping

まえがき Chef-soloをそれなりな感じで便利に使っていたのですが、いろいろあって最近Ansibleに乗り換えました。 プロビジョニング対象のサーバーにSSHとPythonさえ入っていればいいというのがすごく楽ですし、YAMLで書くPlaybookファイルも手に馴染む感じがあってお気に入りです。 Vagrantをよく使うので、最近はVagrantのプロビジョニングもAnsibleでやるようしています。 Ansibleを使ってプロビジョニングを行うフローは、 Inventoryファイルを作ってプロビジョニング対象を決める Playbookを書く ansible-playbookコマンドを実行してプロビジョニング というような感じになるかと思いますが、たまにInventoryファイルを書くのが面倒になるので、この記事ではansible-playbookコマンドをInventoryファイルな

Winscpでアップロードする際の接続です。 １．WINSCPを開き、ホスト名とユーザー名を入力し、鍵を選択する。 ２．鍵なんで何も考えずとりあえずAWSで作ったxxxxx.pemを設定して 接続すると、、 ３．こんな風に怒られます。 ４．AWSで作ったKeyPair（xxxxx.pem）をPuTTy秘密鍵（*.ppk）に コンバートする必要があります。 コンバートツールはputtygen.exeでこちらからダウンロードします。 http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ５．ダウンロードしたputtygen.exeを起動します。 ※警告出るけど、上げちゃってください。（何があっても保証はしませ んけど･･･） ６．メニューバーのconversionseからImport Keyをクリックし、 KeyPair

CentOS6での利用方法 CentOS(ホスト) -> CentOS(リモート側) 予備知識 AnsibleはSSHでリモート側にログインしてコマンド類を叩く設計になっています。 そのため、リモート側でSSHログインができるようにしておきましょう。 （念のため、ログインするユーザと、コマンドを実行するユーザを別にすることも可能です） インストール rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm yum install ansible -y 実行確認 アクセス先のホストは192.168.1.20、アクセスユーザはrasennとします。 鍵認証でアクセスするなら（パスワードなしsshができれば）--ask-pass --ask-sudo-passは必要なく、パスワード

OSやミドルウェアの機能検証を実施した場合など、オンデマンドで一時的な検証環境を構築できるのもクラウドサービスの醍醐味です。 検証対象のOSやミドルウェアは異なれど、検証に必要な環境はある程度共通であることが少なくなく、また費用節約のためにも検証が終わった後はきれいさっぱりとその環境を削除したいものです。 AWSでそんな使い捨ての環境を構築する場合の方法として、ファーストチョイスとなるのはAWS CloudFormationかと思います。検証環境をテンプレート化しておくことができ、またマネージメントコンソールやAWS CLIを使って簡単に環境の構築／削除ができる、使い捨て環境の構築にはぴったりのサービスです。あるいはAWS CLIやAWS SDKを使って自前の環境構築スクリプトを作成するのもよいかもしれません。 AWS公式のツールを使う以外では、Terraformが有力な選択肢の1つになる

IAM ( Identity and Access Management ) とは AWSの利用を開始する際、当然ながらAWSアカウントを作成するわけですが、このAWSアカウントはLinuxのルートユーザのようなもので、全てのユーザをこのアカウントでAWSにアクセスさせるのには問題があります。 例えば、経理部門が請求情報を確認するために、AWSにアクセスした場合に、誤ってEC2のインスタンスを停止してしまうといった事が（可能性は少なくとも）あり得ます。 通常、こういった問題に対処するには、個々のユーザ毎に異なるアカウントを作成し、そのユーザが必要となる権限を割り当てます。Active DirectoryやLinuxでのユーザ/グループを利用したアクセス管理等がこれにあたります。 AWSではIAM ( Identity and Access Management ) という、AWSサービスと

渡辺です。 2015年はAnsible盛り上がってますね。 大規模な構成管理ツールとしては疑問の声も聞こえてきたりしますが、弊社のAWS環境構築支援のように、ある程度お決まりの設定をサクっと８分組みしたいようなケースでは本当に便利です。 そんなAnsibleが手軽に使える最大の理由は、Ansibleがエージェントレスで、対象サーバにSSH接続が可能ならば利用できるという点であることは言うまでもありません。 この辺りもAWSの環境構築とAnsibleの親和性が高い理由のひとつです。 今回のエントリーでは、そんなAWSの環境構築を行う時に、ssh_confとAnsibleを組み合わせる方法を紹介します。 SSH接続と秘密鍵 Ansibleを実行するマシンから対象のサーバにはSSH接続を行う必要があります。 すなわち、秘密鍵が必要です（鍵認証無しでSSH可能な環境は論外で...）。 秘密鍵は、s

魔法の言葉、経費削減 開発環境にEC2使ってると、帰宅時のInstanceのShutdown忘れ起こりがち。 「塵も積もれば山となり」という言葉があるそうです。 多分どこも同じような事をやってる、EC2 Instanceの自動停止bot君をLambdaで作る。 (残業多めの会社だと存在を誰もが忘れた頃に悲劇のShutdownを容赦なく放ち、比較的存在嫌われがち) LambdaにScheduleEvent付いたし、毎日cron実行するだけのInstanceを殺すチャンス。 先人様の参考など RoleとかGUIの設定周りはこの辺で掴んでもらえると。 [クラスメソッドさん] LambdaのScheduleイベントでEC2を自動起動＆自動停止してみた EC2やRDS、ELBの停止忘れ、削除し忘れを防ぐ！LambdaScheduleイベント 今回やりたいこと 今までは始業時間に自動起動、夜少し遅めの

はじめに 本日がAdvent Calendarデビュー戦のhassaku_63です。普段は飯田橋にいます。 25日が最後とは知らず、うっかり同期につられて登録してしまい、今年のトリを飾ることとなってしまいました。 聖なる夜に私はひとり寂しくこの記事の執筆と格闘しております。。。 カレンダーのヘッドライン(?)にはバックアップの自動化、と書いていますがごめんなさい、嘘です。 今日はEC2のStart/Stopを自動化する実装の一例をご紹介します。 SlideShareにスライドをUpしています。こちらも併せてご参照あれ。 背景 今回のネタ、そもそもは「サーバーレスアーキテクチャ」「Cloud Automator」「re:Invent」の3つが発端です。 サーバーレスアーキテクチャ 話題になってますね。サーバーレスアーキテクチャ。 サーバーの運用から解放されるなんて、ステキですよね。 Clou

AWSインスタンスの数を負荷に応じて調節してくれるAuto Scalingは、高負荷に対応しながら運営コストを抑えたいなら必須の機能。今回は、そんなAuto Scalingの触りを解説する。 Auto Scalingの起動設定 起動設定を開く まずはAmazon EC2のコンソール画面を開き、Auto Scalingの起動設定を開こう。 Auto Scaling グループを作成する 起動設定に入ったら、『Auto Scaling グループの作成』をクリックする。 起動設定を作成する 次の画面で、右下の『起動設定の作成』を選ぶ。 AMIの選択 起動設定として、まずはAMIを選択する。既存のAMIをAuto Scalingで使用する場合は『マイ AMI』から選択しよう。※ここではAmazon Linux AMIを選択した インスタンスタイプの選択 次の画面でも、プロジェクトに合ったインスタンス

この記事は古いのでこちらを御覧ください！！ コンニチハ。千葉です。 突然ですが、開発環境などで使っているEC2やRDS、ELBを停止し忘れた、消し忘れた！という経験をお持ちの方へ。 私、よくパソコン抱っこしながら寝落ちするのですが、ELBを作成しっぱなし、課金発生してた！ということがあります。 無駄にお金を払わないように、インスタンス停止や不要なリソースの削除はコマメに行いたいところです。 そんな中、新しくLambdaScheduleイベントがリリースされました。これは使うしかない！ということで、リソースの状況を教えてくれるツールを作ってみました。 構成 Lambdaで１日１回スケジュールをトリガーに発火させます。 そこで、EC2、RDS、ELBの起動状況を取得、SNS経由からメールで通知してくれます。 リソースが起動している場合は、こんな感じでメールがきます。逆にリソースが起動していない