AutoScalingの新機能発表 AWS AutoScalingでは、負荷状況や時間に応じてEC2インスタンスを自動的に起動・停止することができます。AutoScalingに本日新しい機能が追加されました。「Protect Instances from Termination by Auto Scaling」というタイトルで発表されています。 AutoScalingを利用したことがある方なら心当たりあるかと思いますが、AWSのAuto Scalingでは、スケールイン時にEC2インスタンスが自動的に、そして強制的にTerminateされます。Terminate対象のインスタンスで何か処理が行われていたとしても、スケールインのタイミングでぶった切られて強制的にシャットダウンがかかってしまいます。 *1 今回のアップデートでは、AutoScaling Groupに対してスケールインを防ぐこと
github.com 引き続き Worker Tire で Cron っぽいやつをやってみます。 ひとまずは ECR に build して push リポジトリを作る $ aws --region us-east-1 ecr create-repository --repository-name oreno-sinatra-worker ECR にログインする $ aws ecr get-login --region us-east-1 $ docker login -u AWS -p xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx(ホントはもっと長い)xxxxxxxxxxxxxxxxxxxxx -e none https://xxxxxxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com build する $ docker build -
Railsでユーザ認証させる 鉄板のDevise + Omniauthの組み合わせですが、意外とomniauth-google-oauth2に関する記事は少なそうだったので、備忘録+写真で解説してみます。 Let's Try! まずはGoogle Developers Consoleで登録 https://console.developers.google.com/project プロジェクトを作成をクリックし、 よしなにプロジェクトを作成します。 使用するAPIの設定 今回はあくまで「ユーザ認証」を行いたいため、不要なAPIの利用は解除していきます。 サイドバーから、API Manager > 概要 を選択し、 Enable APIs (7) タブを選択、 Google+ APIを除いて無効にしておきます。(ムダなAPIは無効に!) 認証情報と同意画面の設定 再びサイドメニューから、今度
Amazon EC2 Container Registry(ECR)でECS/Elastic BeanstalkのDockerイメージをホストする(1/12アップデート) 2016/01/12 Elastic Beanstalkの部分をアップデートしました。 ども、大瀧です。 1週間ほど前に、Dockerレジストリサービス Amazon EC2 Container Registry (以下ECR)がリリースされました。今回は、AWSでDockerを扱う2サービス ECS(EC2 Container Service)とElastic BeanstalkでECRを利用する手順をご紹介します。 とりあえず動かしてみる ECSのFirst Run画面が更新され、サンプルのECSクラスタに加えてECRリポジトリがサクッと作成できるようになったので試してみます。ECRは現時点ではバージニアリージョンで
概念図 とりあえずECSに出てくるエンティティがそれぞれどんな多重度で関連しているのかをまとめてみました。ここからはそれぞれのエンティがどんな概念なのかを解きほぐしていきたいと思います。 図1 概念図 Serviceが中心 ECSは平たく言うと クラスター(=複数EC2インスタンスの集合)の上で Dockerコンテナを使って、 Serviceを動作させる ものです。 図2 例えばの構成 上図は、 Front Service (裏にいるAPIをCallしてWEB UIを提供するもの) API Service (ビジネスロジック、DBへの読み書きをRESTful APIで提供するもの) と言う2つのService で構成されるWEBアプリケーションの例です。 ECSで言うServiceは、Serviceは利用者から見た「サービス」よりも一段階か二段階細かいもので、APIサーバーとか、フロントサ
.ebextensions など ElasticBeanstalk で、Software Configuration などで設定した環境変数を参照したい場合のやり方メモ。 (最後に確認したのがかなり前なので、もしかしたら現在はこのままでは動作しないかもしれないです) 環境タイプ: Docker 現在の方法 以前は /opt/elasticbeanstalk/hooks/common.sh に書かれていた設定ファイルを参照して直接読み出していたけれど、最近 EB の AMI のバージョンをあげたところうまく動かなくなっていた(ami-4aedea4b で確認)。 デプロイ用のスクリプトが使っていたツールを発見したので、これを使わせてもらうことにします。 ちなみに環境変数が含まれた、コンテナのコンフィグファイルを直接参照したい場合はここにあります。
はじめに ソリューションアーキテクトの安川 (@thekentiest)です。AWS ElasticBeanstalkがDockerに対応したという発表がされて以来、実際に利用してくれるお客様や、ブログを書いてくれる方がたくさんいて、嬉しい限りです。 最近ではローンチ当初に比べてDeployの仕組みも改善され、Deploy時にはStagingコンテナが立ち上がり、その立ち上げが完了した後に旧コンテナとの切り替えが行われるようになり、よりダウンタイムが短くなったので、使い勝手も良くなってきたかと思っています。 ところで皆さん、Dockerを使ったDevOpsを行う際、コンテナイメージを置くレポジトリはどうされていますでしょうか?ベースイメージだけを公開レポジトリ等から取得して、毎回コンテナをBuildする場合にはそれほど悩まないかもしれませんが、構築済みのコンテナイメージをPullしてDep
tl;dr Elastic Beanstalk の Worker Tier と Worker Tier で Cron っぽいことを試してみたメモ。 参考 AWS Black Belt Tech シリーズ 2015 - AWS Elastic Beanstalk from Amazon Web Services Japan www.slideshare.net Worker Tier について その前に Elastic Beanstalk について 読み方的には「エラスティック・ビーン・ストーク」で「ビーンズ・トーク」では無い(重要) PaaS(アプリケーション以下の環境は AWS がマネジメントしてくれる) 各種言語に対応 ELB と AutoScaling や RDS だって利用可能 Web Tier(今回は触れない) と Worker Tier がある Worker Tier SQS
はじめに タダです。 AWS認定試験勉強のためにElastic Beanstalkのドキュメントを読んだ自分用メモになります。 ※違う内容書いているなどありましたらご指摘いただけると幸いです。 ※随時アップデートがあれば更新していきます。 サービスの概要 Elastic Beanstalkは、ソースコードをアップロードするだけで、ソースコードを実行する環境のプロビジョニング、ロードバランサー、スケーリング、モニタリングなどの細かい作業はサービスを管理するサービス サポートするのは、PHP、Java、Python、Ruby、Node.js、Docker 構成できるのは、ウェブサーバー環境とワーカー環境 ウェブサーバー環境は、ELB + AutoScalingでスケーラブルな環境を構成し、環境毎にDNS名を付与する ワーカー環境は、SQS + AutoScalingでスケーラブルなバッチ処理基
よく訓練されたアップル信者、都元です。先日、AWSでジョブWorkerを構成するベストプラクティス 〜 SQSの巻として、SQSを使ったスケーラブルなジョブWorkerアーキテクチャをご紹介しました。人間相手のHTTPリクエストの間に完了させるには長すぎるジョブを実行したい場合は、とりあえずSQSに投げて非同期に処理させよう、という仕組みです。 投げる側は、Javaであればこんな感じですね。キュー毎にURLがあるのでそれを指定して適当なメッセージ(本来はJSONなんかが良いんだと思います)を投げ込みます。 sqs.sendMessage(new SendMessageRequest(QUEUE_URL, "foobar")); Worker側としては、こんな感じでメッセージを受信しては処理して削除、というのを繰り返せばよいです。 while (true) { ReceiveMessageR
ElasticBeanstalkでPHPやるぞ!となると構成はhttpdになります。 が、nginx+php-fpmに変更したいという場合があると思います。 また、他のプログラム言語でもミドルウェアを変えたい場合もあると思います。 今であればDockerを使う、OpsWorksを使うという手も有ると思いますが、ElasticBeanstalkで普通にEC2上でのミドルウェアなどの設定変更を行ったことがなかったので調査がてらやってみたのでメモ。 やってみて構成変更はでき、実際に動いてもいるのですが、ElasticBeanstalkのヘルスチェックでEnhancedの設定では問題ありと表示されてしまいます。。。(basicならOK) 上記あたりの詳細をご存知の方、いらっしゃいましたら教えていただけると嬉しいです。 参照 Linux サーバーでのソフトウェアのカスタマイズ [AWSマイスターシリ
それでは前回宣言した通り、Elastic Beanstalkの設定ファイルを用いた環境構築の自動化をご紹介しようと思います。 はじめに 今回の大きなテーマは.ebextensionsを使った環境構築の自動化です。 そのための題材として、ナウいWebアプリのHTTPS対応をやってみたいと思います。 SSL証明書はACMに登録しているものを使う前提です。 なので今回の内容としては .ebextensionsの作成 Elastic Beanstalkへのデプロイ Route53での名前解決 となります。 ナウい環境って? こんなの 事前準備 ACMへの証明書の登録 まず、「そもそもドメイン持ってないよ」という方は、Route53のコンソールから適当なドメインを取得してください。 手順はこの記事がわかりやすいかと思います。 実践 では、色々と設定を.ebextensionsに追記して行きますが、
前回は素のFlaskアプリケーションをデプロイしました。 今回はDockerコンテナを動かしてみます。 ちょうどAzure Web App for Containersと同じようなものです。 Azure Web App for Containers EC2より自由度は下がりますが管理が楽になり、 EBに単純にアプリケーションをデプロイするよりは自由度が上がります。 それなりに学習コストも高くなりますが、かけただけの時間を将来削減できると信じて勉強します。 今回は単一コンテナのDocker環境構築を行います。 Elastic Beanstalkとは Elastic Beanstalkではユーザはアプリケーションをデプロイするだけです。 ソースコードを自動でEC2に配置し、ウェブサーバを設定し、さらにロードバランサーやオートスケーリングなどの面倒もElastic Beanstalkが管理してく
AWS Elastic Beanstalk (EB)ではアプリケーションをデプロイすれば Azure App ServiceのWeb Appと同じですね。 Azure Web App + Python Elastic Beanstalk cliのインストール 公式に沿ってやっていきます。 brew install aws-elasticbeanstalk 仮想環境の構築 virtualenvで環境を構築します。 これまでpyenvしか使ってきてなかったのでvirtualenvをインストールします。 pip install virtualenv 仮想環境を作成。ホーム下に作ってます。 pyenvを使用しているとカレントディレクトリに設定されているPythonバージョンが使用されます。 二重構造でややこしい。 virtualenv ~/YOUR_DIRECTORY ちょっと待って完了したらアク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く