サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
haws.haw.co.jp
HOME » テックブログ » AWS , CI , Docker » Jenkinsのジョブの実行環境にAmazon EC2 Container Service ( ECS ) を活用 CI環境の問題点 CI環境でよく起きる問題として以下のような問題がある。 SlowTest コードベースが肥大化していくと、それに合わせてテストコードも肥大化し、テストの実行にかかる時間がどんどん伸びていく。テストが全て完了するのに20,30分かかるようなことだと気軽にテストやデプロイなど行えない。 テストの実行環境 プロダクトによって、言語や実行環境が異なるとテスト環境もそれぞれ異なり、複数のプロダクトのCIを同じ環境で動作させようとすると、CI環境上に全てのプロダクトを動作させるのに必要なソフトウェアのインストールや管理が必要になり、CI環境のメンテナンスがカオスになる。 こういった問題を解消するのに
静的コンテンツと動的な機能を持つサイトをCloudFrontを前面に配置する以下のような構成で構築した際のハマりどころををピックアップしてみる。 構成 CMSにMovable Type(MT)を採用(EC2上で起動) サイトへのアクセスは全てSSL CloudFrontに独自証明書をアップロードし、適用。 CloudFrontで静的コンテンツと動的コンテンツを切り分け CloudFrontのマルチオリジン機能を使って静的なコンテンツはS3のオリジンへ、動的な機能はEC2のカスタムオリジンへ向くようオリジンとBehaviorsの設定を行う。 s3fsを使った公開バケットのマウントは避ける MTは登録されているコンテンツを静的コンテンツとして出力する機能があり、CDPなんかでも静的コンテンツの出力先をs3fsでマウントしたS3のバケットにする事例もある。 しかしs3fsといってもネットワークを
AWSのコンテナサービスであるECS(EC2 Container Service)を使ってWordPressを公開してみる。ECSは、EC2インスタンスからなるクラスタ上にDockerベースのコンテナをビルド、実行するプラットフォーム。 構成 今回はECSの1クラスタ上にWPのコンテナをデプロイする。DBもコンテナとして立ち上げるのもありだけど、今回はRDSを利用し、WPのコンテナからRDSを参照する形にした。 ECSのセットアップ Step1:ウィザードでCustomを選択 Step2:Task Definitionをの作成 続いてTask Definitionを作成する。 まずAdd Container DefinitionでContainer Definitionを作成。 Container name コンテナ名を設定。(同じTask Definition内のコンテナとリンクする際に
EC2のWindowsインスタンスは起動すると標準でリモートデスクトップ(RDP)接続できる環境が提供されます。そのため通常はRDPを使って設定・運用を行うのですが、誤ってWindows側のファイアウォールでRDP接続を切ってしまうと、(あたりまえですが)RDPで接続することができなくなってしまいます。 でも、あり得なさそうなそんなトラブルも起こってしまう時は起こってしまう訳で…。 今回はそんなトラブルが発生した場合の対応方法をまとめます。(※ルートデバイスがEBSのもののみこの方法が適用可能です。) 1.対象のWindowsインスタンスを停止する RDP接続ができなくなったインスタンスを停止し、インスタンスのルートボリュームをデタッチします。 まず、該当するインスタンスの情報からRootデバイスのEBSのIDを確認します。 EBS IDのリンクをクリックするとVolumesの画面に遷移す
EC2のインスタンスのポータビリティを考慮すると、インスタンス上に展開してるアプリケーションサーバやOSのログをどう確保しておくかというのは大事なポイントになります。よくある方法としては、 定期的にS3に保存する Fluentdのようなツールを使ってログを収集する といったアプローチが挙げられます。今回は別の方法として、少し前にAWSに追加されたCloudWatch Logsを使ったログの収集を行ってみました。(CloudWatch自体はAWSリソースのモニタリングを行うサービスですが、2014年7月にOS及びアプリケーションのカスタムログファイルを格納する機能と、ログのモニタリングを行う機能が追加されてます。) IAMのパーミッション設定 ログを収集する対象のインスタンスにCloudWatch Logs agentによるログ収集を許可するためのパーミッションを設定します。CloudWat
Amazon Linux上でfluentd + Elasticsearch + Kibanaな構成を導入するため、fluentdのインストールを行いました。fluentdのインストールはRubyのgemでもできるのですが、今回はTreasure Dataのパッケージであるtd-agentを導入してみます。 td-agentはRHEL / CentOS用にパッケージを用意しているので、↓を実行するとyumのパッケージリポジトリにtd-agentのリポジトリが追加されtd-agentのrpmがインストールされます。 $ sudo curl -L http://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh ただ、残念ながらAmazon Linuxで実行するとエラーになります。そのためインストールするにはTreasure
2014年7月にEC2のインスタンスファミリーにt2系のインスタンスが追加されました。一つ前の世代のインスタンスであるt1系のインスタンスの価格よりも安く、スペックは上がっているお得なインスタンスです。 こうなるとt1系のインスタンスを使い続ける理由は無いので、t1.micro → t2.micro へインスタンスをアップデートしたくなります。ただこのt2系のインスタンスを使用するには以下の制約があります。 EC2-VPCのみサポート EC2-Classicのプラットフォームはサポートしてないので、EC2-Classicの環境ではVPCを作成してそのVPCでインスタンスを起動する必要があります。 サポートしている仮想化方式はHVMのみ t2系のインスタンスはHVM AMIからしか起動できません。仮想化方式がPVのAMIからインスタンスを起動することはできません。 EC2-VPCの制約はVP
PrimeFacesを使うとJSFベースのリッチなUIをJavaScriptを一切記述することなく構築できて便利です。ただ、JSFを使用しているとブラウザとサーバ間でAjaxを使った通信が頻繁に発生します。その通信の際に、サーバ側のセッションが有効期間切れになると、通常の画面遷移であればログイン画面へリダイレクトをかけれるのですが、Ajaxで通信しているとそういった挙動をさせることができず、ぱっとみ画面に何の変化も起きず、ユーザから見るとボタンを操作したけど何の反応も無いという状況になります。 そんな状態を回避するため今回はPrimeFacesのExtensionを使った対処方法をまとめます。PrimeFacesのExtensionには、<pe:ajaxErrorHandler />というAjax通信中に例外が発生した場合に、処理をハンドリングするタグが用意されています。 レイアウト系のJ
AWS re:Invent 2014で発表された新サービスAWS Lambda。 先日Limited Previewの申請が通ったので早速Lambda使って何かできないかと思い、Webサイトの監視をLambdaを使って実現してみました。 5分間隔で指定したサイトを監視し、400、500系のレスポンスが帰ってきた場合は、SNSに異常状態である旨メッセージ通知をします。 LambdaはS3上のファイルの変更やKinesisに届いたメッセージ、DynamoDBへのデータの更新といったイベントに反応して任意のコードを実行できるプラットフォームです。Lambda自体に定時処理を行うような仕組みは用意されていないので、Lambda Function内部でS3にオブジェクトをPUTすることでLambda Functionの実行をループします。 処理は↓のステップで行います。 site-監視時刻ミリ秒(例
単体テスト実行時に任意のシステム日付でテストをしたいというケースで便利なのが、jmockitを使ったシステム時刻のモック化です。new Date()等で日付をセットしている箇所の日付を、jmockitを使ってテスト実行時に任意の日付に固定化するには以下のようなコードとテストケースで実現できます。 日付をモックするクラス System.currentTimeMillis()をモックします。 import mockit.Mock; import mockit.MockUp; import java.util.Date; public class CurrentTimeMock extends MockUp { Date mockTime; public CurrentTimeMock(Date mockTime) { this.mockTime = mockTime; } @Mock publ
s3fsでマウントできるバケットをIAMロールで制御します。 ロールの作成。 IAMの画面でRolesを選択し「Create New Role」。 ロールの名前を付けます。ここでは「role-test-bucket」とします。 Role Type は「Amazon EC2」を選択します。 テンプレートの中から「Amazone S3 Full Access」を選択します。 内容が表示されます。選択した通り、S3へのフルアクセスですが、ひとまずこのポリシーで続けます。 (後で編集します) { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } ] } 概要が表示されますます。問題がなければ「Create Role」。 新しいロールが出来ました。 次にEC
Railsアプリケーションを動かすサーバ作ろうとすると、 Rubyのセットアップ Rackサーバ(PassengerとかUnicornとか)のセットアップ Webサーバ(ApacheとかNingxとか)のセットアップ DBのセットアップ アプリケーションのデプロイ用設定ファイル作成(Capistranoとか) といった、アプリケーションの開発自体とは関係ない諸々の作業が必要な訳で、そんな作業しなくてもデプロイ以降の作業をお任せできるHerokuはとても便利。 そんなHerokuのようなPaaSをEC2上に立ててみようとdokkuを使ってオレオレHeroku環境作ってみる。(そんなの構築しなくてもAWSにはBeanstalkがあるじゃないか?というツッコミもあるけど) dokkuは内部でdockerを使用しており、docker自体は、LXC(Linux Container)というLinuxの
開発プロジェクトでは、よく以下のようなライフサイクルが回ってる。 テストの実装 プログラムコードの実装 テストの実行 テストが通ったらコードをリポジトリにPush 定期的にCIサーバがリポジトリをチェックし変更があったらCIサーバ上でテスト実行 テストが通った状態のアプリケーションを検証環境へリリース 検証環境でのテストが通ったら、本番環境へリリース ※実際は5~7の間にDBのバックアップやマイグレーションとかいろんなタスクが結構ある。 このうち実際に人がやらないといけない作業は大体1~4ぐらいで、5~7については人が作業する必要はなく、自動化できる対象作業。同じ作業といっても手順が複雑であればミスをする可能性もあるし、人がする必要が無い作業を何度も人がするのはムダだ!ということで、今回はJenkinsを使って5~6の作業を自動化してみた。 必要なプラグイン 以下のJenkinsのプラグイ
HOME » テックブログ » AWS , JavaScript » AWS Service Health Dashboardの障害時刻をブラウザのローカルタイムゾーンで表示するChrome extension作ってみた。 AWS Service Health Dashboardの障害時刻をブラウザのローカルタイムゾーンで表示するChrome extension作ってみた。 AWSのService Health Dashboardでは発生した障害情報が共有され、発生した障害情報は↓のように表示される。 ただ、アナウンスの時刻がPST(太平洋標準時)なので、毎回頭の中でJST(日本標準時)に変換が必要。UTC(協定世界時)ならまだ慣れ親しんでる分さっと変換できるけど、PSTは一瞬?てなる。 毎回時刻計算するのもメンドイので、Dashboardに表示されるPSTな時刻を、ブラウザを起動している
このページを最初にブックマークしてみませんか?
『HAWSクラウドサービス | HAWS(HAW+AWS)は、福岡・九州を中心にハウインターナショ...』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く