新着 – カーネルパニックをトリガーし、応答しない EC2 インスタンスを診断 | Amazon Web Services
Amazon Web Services ブログ 新着 – カーネルパニックをトリガーし、応答しない EC2 インスタンスを診断 オンプレミスのデータセンターにデプロイされたシステムで作業を行っていたころ、ときどき、応答しないサーバーのデバッグをしなければならないことがありました。その場合、通常は誰かに頼んで、フリーズしたサーバーでマスク不可能割り込み (NMI、non-maskable interrupt) ボタンを物理的に押してもらうか、あるいはシリアルインターフェイス (はい、シリアルです。RS-232 など) を介してコマンドコントローラーに信号を送信してもらう必要がありました。このコマンドによってシステムがトリガーされ、フリーズしたカーネルの状態がファイルにダンプされて、さらなる分析が行われます。このようなファイルは通常、コアダンプあるいはクラッシュダンプと呼ばれます。クラッシュダ
やりたいこと ディスクサイズを増やしたい！ EC2インスタンスを立ち上げて利用し始めたは良いものの、実際使ってみると保存しておきたいデータがいっぱいでディスクの空き容量が少なくなってきてしまった…ピンチ… あると思います。ディスクサイズを増やしたいところですね。 私は、ディスクサイズ拡張などEBSの設定に変更を加えたい場合、以下の作業が必要だと思っていました。 インスタンスを停止する EBSボリュームをデタッチする スナップショット作成 スナップショットを使って新しいサイズのEBSボリュームを作成 EBSボリュームアタッチ インスタンス再起動 2019年5月現在、これらの作業は 不要 になっていました。確かに昔はこのような作業が必要でしたが、今はインスタンスを起動したまま、ボリュームをアタッチしたまま、サイズ拡張が可能です。どうやら2017年2月のアップデートだったようですね。。AWSの進
はじめに こんにちは植木和樹です。Amazon Linux AMI 2014.09がリリースされて随分と経ちましたが、リリースノートにちょっと目を引いた記載がありました。 Amazon Linux AMI 2014.09 Release Notes New packages In addition to the features above, here are some other new packages added based on customer requests: ： stress-1.0.4 ： stressというのはCPUやメモリーの負荷を発生させるツールです。サーバーの高負荷状態でのアプリケーション挙動を確認する際に使用します。便利なツールなので使い方をおさらいしてみました。 stressの使い方 プロジェクトページ stressツールのプロジェクトページはこちらです。 s
はじめに ここ最近のDockerムーブメントの中で、キーワードとして良く取り上げられるようになったものの一つにCoreOSがあります。つい先日もGoogle Compute EngineがCoreOSを正式にサポートしたことが大きな話題となっていました。 CoreOSはLinuxディストリビューションの一つです。細かい説明については、外部サイトになりますがCoreOS 入門 - Qiitaという記事が非常に参考になりますのでご一読下さい。 ざっくり書くと、仮想化コンテナを大規模に運用することに特化したLinuxOSです。etcdという分散KVSとfleetという分散システムによるクラスタリング機能を標準的に持っています。 そこで今回は、Amazon EC2上でCoreOSを導入し、更にfleetを使ってDockerコンテナをクラスタリングして起動させる、ということをやってみました。 やった
capistrano-ec2_taggedというgemを作った。まだrubygems.orgには上げていない。 これはCapistranoで指定タグのEC2インスタンスにデプロイのようなことをやるためのもので、次のようにして使う: # Gemfile gem "capistrano-ec2_tagged", require: false, github: "a2ikm/capistrano-ec2_tagged" # Capfile require "capistrano/ec2_tagged" # deploy.rb set :access_key_id, "ACCESS KEY ID" set :secret_access_key, "SECRET ACCESS KEY" set :region, "ap-northeast-1" # production.rb role :app,
【AWS】CloudWatch入門／使っていないEC2を自動シャットダウンしよう | DevelopersIO
はじめに こんにちは植木和樹です。AWSで検証目的でEC2インスタンスを立てたままSTOPするのを忘れてしまうことが良くあります。使ってないインスタンスでも、起動していれば当然課金されてしまいますので、ちゃんと停止させてコスト削減しましょう。今回は「Use Amazon CloudWatch to Detect and Shut Down Unused Amazon EC2 Instances」（初出：2013/01/08）で紹介されている方法を翻訳しながら進めたいと思います。 使っていないEC2は自動でシャットダウンしよう 本日はAmazon CloudWatchのアラーム機能を使ったEC2の自動検知と自動シャットダウンの方法をご紹介します。あなたは時々EC2を使うだけの個人開発者かもしれませんし、複数開発者向けのEC2を管理するITプロフェッショナルかもしれませんが、そういう立場に関係
渡辺です。AWSチームにジョインしてから1ヶ月ほどになりますが、あまりAWSを活用していません。 これではイカンということで、JenkinsによるCI環境をEC2上に構築してみました。 構築の流れ こんな流れで構築します。 EC2インスタンスを作成し、ElasticIPを割り当てる 最新のJDKをインストールする Jenkinsを起動する Jenkinsのセキュリティを設定する EC2インスタンスを作成し、ElasticIPを割り当てる AWSを使い慣れている人にとっては簡単な作業ですが、使い慣れていないと戸惑う所も多いところです。折角なので丁寧に解説します。 予めAWSのアカウントは各自で作成しておき、AWSの管理コンソールにログインしてください。 EC2インスタンスの作成 はじめにEC2(Amazon Elastic Compute Cloud)のインスタンスを作成します。 EC2はA
ども、大瀧です。 EC2からEメールを送るという案件、たくさんありますよね。そして結構な確率でトラブるんですよね(涙目)。そんな苦い経験をベストプラクティスとしてまとめてみました。一応技術的なところは網羅したつもりですが、メールセキュリティの専門ではないので、不備や間違いがあればご指摘ください。 では、メール送信トラブルの元凶である、スパムメールとその対策からご紹介していきます。 スパムメールとの闘いダイジェスト Eメールの歴史は、スパムメールとの闘いの歴史と言えます。 不特定多数に送信されるスパムメール(未承諾の広告メール)は、メール受信者に不快な思いをさせるとともに、メールサーバーのメール流量を爆発的に増加させ、長らくメールサーバー管理者を泣かせてきました。 このスパムメールをなんとか撃退しようと、現在では主に以下のような対策が行われています。 1. 送信メールサーバー側のネットワーク
まつけんです。 今回は、とれたまのコーナーで有名なテレビ東京さんの番組「ワールドビジネスサテライト」(以下、WBS)で紹介されるにあたって、どういう負荷対策をしたのかを紹介します。 WBSに紹介されて直後にサーバーアクセス殺到して落ちました、というような話は結構聞いていたので、機会損失という意味でも落ちるのはなんとか避けたいね、ということで対策をしましょうという話になりました。 前提 今回の負荷対策の前提となる条件を挙げます。 まず、ありがたいことにCerevoは最近、WBSに2度紹介されています。 LiveShellの紹介（映像はこちら）とCerevo DASHの紹介（映像はこちら）の2回です。 Cerevo DASHでは現在、iConvexというiPhoneアプリと連動する電子巻き尺ガジェットの支援を募集しています。是非、ご覧ください。 ということで、それぞれでの紹介内容にあわせて、別
EC2編第3弾は『イメージ』に関してです。ちょっと準備を必要としたのでその辺もまとめて。 実践用のEC2準備 今回エントリの実践用に、適当なEC2を準備する事にします。まずはキーペアの作成。 $ export AWS_DEFAULT_REGION=ap-northeast-1 $ aws ec2 create-key-pair --key-name aws-study-key { "KeyPair": { "KeyMaterial": "-----BEGIN RSA PRIVATE KEY-----\nMII(中略)zWw+w==\n-----END RSA PRIVATE KEY-----", "KeyName": "aws-study-key", "KeyFingerprint": "XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:
IAM編の次はEC2編です。IAM編についてはまだ制覇して無いですがその辺は緩やかに色々なサービスをつまみ食いしながらと言う事で。 AWS Command Line Interface aws/aws-cli Amazon EC2 (仮想サーバー Amazon Elastic Compute Cloud) | アマゾン ウェブ サービス（AWS 日本語） EC2(Elastic Compute Cloud) awscliでec2のコマンドを見てみましょう。唯一、1サービスで『全部の候補を表示しますか？』と聞かれます。それもそのはず、利用可能な機能は何と149個！数の多さに思わず怯んでしまいますが(笑)、要素別に整理して少しずつ試してみようと思います。 $ aws ec2 Display all 149 possibilities? (y or n) activate-license del
volume(ボリューム)に関する操作 EBS関連コマンドは以下の9つ。 attach-volume create-volume delete-volume describe-volumes detach-volume import-volume describe-volume-attribute modify-volume-attribute describe-volume-status create-volume ボリュームを作成します。アベイラビリティゾーンが必須、容量(GB指定)、snapshot-id(volume-type, iops)についてはオプション指定が可能となっています。 $ aws ec2 create-volume --region ap-northeast-1 --availability-zone ap-northeast-1c --size 7 { "Ava
流行りのVagrantでEC2インスタンスを制御できるvagrant-awsプラグインを使ったときの小ネタ 環境は以下の通り * MacOSX * Vagrant 1.2.2 * vagrant-aws 0.2.2 * AmazonLinux(ami-173fbf16) 基本的な使い方はid:naoyaさんのブログとかGitHubを参考に。 Vagrantfileの書き方に関してはnaoyaさんが試した時点から、SSH関連の設定方法に変更があったのでGitHubのほうも参照したほうがいいです。 Vagrant 1.1 で EC2 を vagrant up - naoyaのはてなダイアリー mitchellh/vagrant-aws · GitHub で、起動してみると最後に↓こんなエラーがでます。 [default] Rsyncing folder: /Users/chiastolite/
AWSを本格的に使い始めて約3ヶ月になる新参者です。 便利過ぎて今までの時間を返して欲しいくらいなのですが過ぎたものは仕方ないので前に進みましょう。 EC2 への SSH 接続 Amazon EC2 上のインスタンスにSSH接続するベーシックな方法は ですが、これでは何のサーバに接続しているのかさっぱり分からないのでこのまま運用している人はまずいないでしょう。 (AWS Management Console から毎回コピペでがんばっている人はいそう) ~/.ssh/config おそらく多くの人は ~/.ssh/config の設定にそれぞれ工夫を凝らしているのかと思われますが、 インスタンス数が増えてくると ~/.ssh/config の更新も煩わしくなります。 また Auto Scaling 等のダイナミックな運用になるととても追いつきません。 既存サポートツール ec2ssh その煩
Vagrant 1.1 がリリースされました。 Vagrant は仮想サーバーのフロントエンドのツール、詳しくは Vagrant - naoyaのはてなダイアリー あたりを。 で、この 1.1 が 1.0 → 1.1 という割に結構大きなアップデートで新しく VM に VirtualBox 以外のものが選択できるようになった。すなわち「VirtualBox のフロントエンド = Vagrant」から「各種仮想マシンのフロントエンド = Vagrant」という風にアップデートされた。 今回の 1.1 からVMを操作するproviderがプラグイン構造となり、VirtualBoxだけならず、公式で操作できる対象が増えました。 VirtualBox VMware Fusion Amazon EC2 + VPC Rackspace Cloud VMware Fusion以外はオープンソースで公開さ
Vagrant 1.1リリース、VMware Fusion, EC2, Rackspace が新たに対応 リリース早かったなぁと思う@HIROCASTERでございませう。 Vagrant 1.1 がリリースされました。 今回の変更点はとても大きなものであると感じています。そして、開発者にとって、素晴らしい機能が追加されました。 Vagrant は VirtualBox のラッパーとして機能し、VMの立ち上げや管理からpuppetやchefで記述された内容に基づくプロビジョニングをおこなってくれます。 これは、Proxyサーバ、Appサーバ、DBサーバなど複数台構成の開発をおこなっている開発者のローカル環境で、複数台のVMを本番さながらの構成で稼働させるためには非常に重宝されるツールでした。プラグインの対応で、VirtualBoxだけならず、AmazonのEC2を操作することができました。
以前、ファーストサーバーで、サーバー上のファイル一式と、DBの情報が全部消去される障害がありました。僕はその被害者の一人です。結局のところ、削除されたデータは復旧されず、幸い、記事データは手元に手動で取得していたDBのdumpファイルがあったらから良かったのですが、問題は各種設定ファイルや画像データでした。これらについてはバックアップがなかった為、CMSを一から構築し直し、画像をローカルからかき集めて対応するといった地獄の日々が続いたのです。 それ以降、バックアップの取得の大切さに気付き、万が一何か起きたときの復旧手順書を作成することにしています。 今回はAWSで運用しているWordPressサイトを対象に、現在行っているバックアップ方法について紹介したいと思います。 ●前提条件 バックアップの考え方として、「サーバーがふっとんでも10分以内に復旧できること」です。1日1回、バックアップ
genies-ag.jp -
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
