はじめに 最近はぼちぼちとCloudFormationを触り始めている、t.hondaです。CloudFormationと言えば、JSONのテンプレートです。このテンプレート、いろいろなサイト・記事でも言われていることですが、私としては以下ようなことが心に引っ掛かっていました。 コメントが書けない (ベタ書きのJSONのため)重複する記述を共通化できない もう少しプログラムチックに書きたい これらを解決するため、プログラムにてJSONのテンプレートを作成するようにしてみました。同時にテンプレートからStackを作成し、コマンド一発でJSONの作成・Stackの作成をするようにしてみました。 プログラムについて では、そのプログラムについてです。使用したプログラム言語はPython2.7で、S3にバケットを作成する簡単なテンプレートを記述してみました。 1.事前準備 pyenv、virtua

渡辺です。 AWS CodeDeployは、アプリケーションのデプロイを自動化するサービスです。 複数のEC2インスタンスなどにアプリケーションをデプロイする時に便利なサービスですが、真骨頂はAutoScalingに対応していることでしょう。 2016年2月17日にデプロイイベントのプッシュ通知機能が追加されました。 プッシュ通知がサポートされたことで、より自動化された運用を行えるようになります。 デプロイイベントのプッシュ通知 デプロイは何らかの理由で失敗する可能性があります。 デベロッパーやオペレータが意図したタイミングでCodeDeployによるデプロイをする場合には問題がありません。 なぜならば、デプロイ結果はその時に確認するため、失敗したならば対応するからです。 しかし、問題はAutoScalingなどで意図しないタイミングでデプロイが発生した場合です。 マネジメントコンソールで

2014/12/16更新 : lambchopがアップデートされ正常に実行できるようになったので、実行結果を更新 ども、大瀧です。 本記事はAWS Lambda Advent Calendar 2014の13日目です。昨日は@shot6さんのLambdaでのここまでの利用パターンまとめでした。これで「Lambda入門」と題して半日セミナーができそうなくらい、素晴らしいまとめだと思います！ さて、最近加わったAWSのデプロイサービスCodeDeployは、EC2インスタンスにアプリケーションをシンプルにデプロイすることができる便利なサービスです。弊社ブログでもいくつかのエントリーで紹介しているので、CodeDeployについて知りたい方は、以下のリンクを参照ください。 CodeDeploy ｜ 特集カテゴリー ｜ Developers.IO CodeDeployでのアプリケーションのデプロイ

渡辺です。 CodeDeployでは、リビジョン（デプロイするパッケージ）を作成するプロセスと、リビジョンを各サーバにデプロイするプロセスは独立しています。 したがって、リビジョン作成は開発チームさん、デプロイは運用チームさんと役割を分担できるようになっています。 また、デプロイプロセスが分離していることで、過去のバージョンへの再デプロイ（切り戻し）なども容易なのです。 とはいえ、本番環境や検証環境と異なり、開発環境では最新版をゴリゴリとデプロイできた方が便利ですね。 自動化するんよ というわけで、AWSCLIを利用してリビジョン作成とデプロイを連動させてみました。 BUILD_DIR=. REGION=ap-northeast-1 APP_NAME=app_development DEPLOYMENT_GROUP=development_server DEPLOYMENT_CONFIG=

渡辺です。 セキュリティを高めるなどの理由で対象インスタンスにEIPを付与しない場合、SSHは踏み台（Bastion）経由となります（参考： Amazon VPC環境にメンテナンス用の踏み台サーバを構築する）。 踏み台サーバのある構成でAnsibleを利用する場合、ansible.cnfのssh_connectionでssh_argsを設定しましょう。 ssh_configの準備 はじめにsshのconfigファイルを作成します。 これは、~/.ssh/configに設定するファイルの一部と考えて良いでしょう。 Ansibleのファイルと一緒にバージョン管理する方が良いと思うので、Ansibleのプロジェクトルートにおくことをおすすめします。 Host bastion HostName 52.52.xxx.xxx User ec2-user IdentityFile ~/.ssh/prd.

渡辺です。 待望のアップデートがきました！ AWS CodeDeployのELB対応です。 AWS CodeDeployは、ターゲットEC2インスタンスにエージェントを常駐させ、アプリケーションをデプロイするサービスです。 例えば、EC2インスタンスにJavaのSpringアプリケーションの実行環境を用意し、CodeDeployを利用してJAR（WAR）ファイルをデプロイすることができます。 しかし、システムがELB配下にある場合、ELBからのヘルスチェックを考慮する必要がありました。 デプロイが行われると、そのEC2インスタンスは一時的にヘルスチェックに失敗します。 したがって、ELBからのヘルスチェックに成功するまで待たなければ、一時的なサービス断が発生するのです。 これまでは、フックスクリプトでELBのヘルスチェックが成功するまでデプロイを完了させない方法で回避していました（Code

はじめに sshd が LISTEN するデフォルトポートは、Port#22 ですが 今回は、Port#2222 に変更してみたいと思います。 利用する AMI は、以下のとおりです。 Amazon Linux AMI 2017.03.0 (HVM), SSD Volume Type - ami-923d12f5 Ubuntu Server 16.04 LTS (HVM), SSD Volume Type - ami-afb09dc8 CoreOS-stable-1353.7.0-hvm - ami-8284aee5 では、それぞれの方法について見ていきます。 Amazon Linux 環境の場合 ユーザーデータ入力時に「テキストで」を選択し、以下のシェルスクリプトを入力します。 #!/bin/sh -ex /bin/sed -i -e 's/^#Port 22$/Port 2222/'

望月です。Ansibleの超小ネタです。 Ansibleの実行ユーザを変えたい Ansible PlaybookでOSのセットアップをする際、基本的にはsudoでの実行やrootユーザで接続することが多いです。 ですが一部のセットアップはアプリケーションの実行ユーザで行いたい、ということがあると思います。例えばアプリケーション用のディレクトリ作成や依存ライブラリのインストールなどですね。 そういう時は以下の様に書いておけばOKです。 - hosts: all - sudo: yes - tasks: - name: example executed by root privilege with sudo shell: "echo 'this is root user'" - name: example executed by general privilege shell: "echo '

Ansibleではinventoryに対象ホストを定義します。 適用したいインフラ構成が複数ある場合、playbook毎にグループ化してください。 グループ化した場合、変数はそれぞれのgroup varsに定義できます。 詳しくは、前回のエントリーを参照してください。 inventoryの構成方法には幾つかのパターンがあります。 対象とするシステムの規模や特徴にあわせて選択しましょう。 なお、パターンを整理するにあたって、Ansibleのインベントリファイルでステージを切り替えるを参考にしました。 ベーシックパターン 開発環境・検証環境・本番環境といった目的毎に環境を作る必要がなく、ひとつの環境（本番環境）のみの場合は、inventoryファイルもひとつで十分です。 hostsという名前のファイルを作成し、inventoryを定義しましょう。 構成は次のようになります。 . ├── gro

Ansibleは、定義されたインフラ設定を複数のサーバに対し、同時に適用することができます。 この時、どのサーバに対し設定を行うかを定義するのが inventory です。 例えば、hostsというファイルにinventoryを定義します。 基本的なinventory inventoryは、一言で言えば「対象サーバの一覧」です。 inventoryファイル（歴史的にhostsというファイル名にすることが多い）は、次のようにホスト名の列挙となります。 10.0.11.121 10.0.11.122 10.0.21.100 名前解決ができてSSHアクセス可能であれば、ホスト名、IPアドレスでもホスト名のどちらでもOKです。 group inventoryでは、次のようにホストをグループ化することができます。 [web] 10.0.11.121 10.0.11.122 [batch] 10.0.

渡辺です。 Ansibleを使っている皆様、テスト書いてますか？ え、書いてない？ 弊社では、社内共有しているAnsibleのRoleの検証にServerspecを利用しています。 今日はよく使うリソースタイプを紹介します。 テストの流れ テストのフレームワークとしてはTest Kitchenを利用しています（kitchen-ansiblepushを利用したAnsible roleのテスト環境構築）。 はじめに、Test KitchenのEC2 Driverを利用し、AWS環境にEC2インスタンスを作成します。 次に、ひとつのRoleを実行するAnsibleのPlaybookを流します。 続けて、サーバの状態が期待された状態になっているかをServerspecで検証します。 最後に、AWS環境にEC2インスタンスが破棄されます（検証失敗時は破棄されない）。 Ansibleでもテストの仕組み

こんにちは！おおはしりきたけです。今回も突撃！隣の開発環境というタイトルでイケてる開発会社さんの開発環境についてインタビューさせてもらいました。第2弾として、実名グルメサービスで今凄く勢いのあるRettyさんに訪問させてもらいました。インタビューに答えていただいたのはCTOの樽石さん、iOSエンジニアの櫻井さん、Androidエンジニアの新井さん、インフラエンジニアの梅田さんです。 突撃！隣の開発環境とは 前回も書きましたが、技術事例やノウハウなどは、ブログや勉強会などで共有されることが多いと思います。しかし、各社の開発環境や開発体制などは意外と共有されていないこと多いと思います。ノウハウの流出になるかもしれませんが、それ以上に、より良い開発を目指している会社さん同士で情報交換を行い、良いチーム、良いプロダクトを作っていくという志の会社さんの為の情報共有のための企画になります。開発環境や開

佐々木です。クラスメソッドも4月から新しい仲間が増えました。今日はWAF(Web Application Firewall)の基本的な知識を整理してみました。 基礎知識 WAFとは WAF(Web Application Firewall)とは、Webアプリケーションの脆弱性を狙う悪意ある通信(攻撃)から、Webアプリケーションを保護するものです。本来論で言えば、Webアプリケーションに脆弱性があるのであればWebアプリケーションを修正するのが正しい対応です。しかし未知の脆弱性があったり、修正コストが大きくWebアプリケーションでの対応が難しい場合や、緊急度が高くすぐに防御しなければならないが修正が間に合わない場合も、残念ながらあります。ユーザーとWebアプリケーションの間にWAFを入れることで、悪意ある通信を防ぐことが出来ます。 ファイアウォールとは ファイアウォールは、IPヘッダやTC

ども、大瀧です。 今朝かたAWS CLIがアップデートされ、WaitersというAWSのオペレーション完了を待ち合わせる機能が追加されました。簡単な使い方をレポートします。 要件 Waitersは、AWS CLIのバージョン1.6.0以降でサポートされます。AWS CLIのバージョンが古い場合は、以下のコマンドでアップデートしましょう。 $ pip install --upgrade awscli : $ aws --version aws-cli/1.6.0 Python/2.7.8 Darwin/14.0.0 $ 使い方 AWS CLIは、aws <サービス名> <サブコマンド>という形式でサービスごとのサブコマンドに分かれており、サービスによってWaitersのサポート状況が異なります。手元で確認したところ、以下でWaitersを実行するwaitサブコマンドが確認できました。 aws

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先週発表がされたアプリケーションロードバランサー（ALB）ですが、最初からCloudFormationに対応しています。いつもCloudFormation対応は後になるのですが、ALBはサービスの発表と同時に対応しているので試してみました。 リソースのおさらい 以下のようにリソースの種類が1種類から4種類へ分割されています。 標準ロードバランサー（旧ELB：Classic Load Balancer） AWS::ElasticLoadBalancing::LoadBalancer アプリケーションロードバランサー（ALB：Application Load Balancer） AWS::ElasticLoadBalancingV2::Listener AWS::ElasticLoadBalancingV2::ListenerRule AW

はじめに こんにちは、中山です。 2017年4月26日(水)、株式会社IDOM様の会場を利用して開催されたGitHubとクラスメソッドの勉強会！〜GitHub x AWSの最新DevOps事情〜で発表してきました。会場を提供いただいたIDOMのみなさま、GitHubのみなさま、参加者のみなさまありがとうございました。 発表資料 今回はGitHub EnterpriseをAWSで利用する場合、どういった方法を使えばいい感じに管理できるのかという内容でお話しました。AWSの各種サービスを利用することで、運用負荷を低減した形でGitHub Enterpriseを管理することができます。 資料は以下です。よろしければ参照ください。 GitHub Enterpriseは45日間のFree Trialが利用可能です。さらに、コマンド一発でAWS上にGitHub Enterpriseを構築することもでき

コンニチハ、千葉です。 AWS Premier Night #3 in TOKYOでお話した資料を公開します。 資料 Systems Managerは色々なサービスが複合的に動くので、この機会に整理できればと思いまとめました！！ [slideshare id=70941122&doc=premiernight3-devops-170112100415] 最後に 運用自動化に使えるサービスとなり、Run Commandから、かなり強化されました。OSでやっていた作業を外で管理できると、再利用性・実行制御ができ作業時間を圧縮できます。 規模が大きければ大きいほどメリットが多いサービスだと思います。

待望のカンバンが標準搭載された GitHub のカンファレンス「Universe 2016」にて、待望のカンバン機能が追加されることが発表されました！「Project」という機能名で、すべての GitHub リポジトリで利用できるようになっています。 A whole new GitHub Universe: announcing new tools, forums, and features 機能の概要は次の通りです。 Code, Issue, PullRequest をリストできる ワークフローに合わせたカラムを設定し、ソートすることができる カードはドラッグアンドドロップで自由に移動できる Waffle.io と ZenHub がパートナーとなって開発している GitHub のリポジトリベースのタスク管理といえば Waffle.io や ZenHub が有名ですが、これらのサービスの開

はじめに こんにちは、中山です。 最近Ansibleのplaybookをテストするための環境作りをしています。いろいろなツールを検証しているのですが、Test Kitchenを利用する機会がありました。Test Kitchenのprovisionerにはさまざまなプラグインがあるのですが、kitchen-ansiblepushというプラグインがとても便利なのに、あまりブログなどで解説されていないようなので今回ご紹介したいと思います。 Test KitchenでAnsibleを利用する従来の方法 kitchen-ansiblepushの紹介の前に、Test KitchenでAnsibleを利用する従来の一般的な方法について説明します。 今まで多くの方はkitchen-ansibleというprovisionerプラグインを利用されている方が多かったのではないでしょうか。「test kitche