EC2 メンテナンスで慌てないための 4 つの設計ポイント | はったりエンジニアの備忘録
公式ブログでもアナウンスがありましたが、月末にかけて EC2 のメンテナンスが行われます。 EC2 メンテナンスアップデートに関して EC2 のメンテナンスには、ゲスト OS を再起動するインスタンスリブートと、ホストの物理サーバを再起動するシステムリブートの 2 つがあります。どちらのメンテナンスが予定されているかは EC2 Management Console の Events ページで確認できます。詳しいことは Amazon EC2 のメンテナンスのヘルプページに書いてあります。 今回は Xen のセキュリティ対応ということでシステムリブートが必要になりますが、どちらのメンテナンスでもユーザーの都合に合わせて事前に実施することができます。 インスタンスリブート: ゲスト OS にログインして再起動させるか、EC2 Management Console で Reboot を選択 システ
PV->HVM変換ツール pv2hvm.rbを試してみた | DevelopersIO
はじめに こんばんは、たけかわです。 最近話題のt2.microインスタンスですが、仮想化方式がHVM(Xen Full virtualization)のものしか使えないため、既存のPV(Xen Para-virtulaization)のイメージがつかえません。そこで変換をしたいという要望をお客様より幾つか受けたので調べてみました。 PVとHVMについて PVとHVMはもともと歴史のあるXenから来ている話ですので多くのよい説明があります。というわけでリンクを示して少し話を端折らせてもらいます。 メモ: AMIの仮想化方式 hvm、paravirtualについて 仮想化方式(HVM と PV)についてまとめ AWS Virtualization : HVM vs Paravirtualization 自分の理解では、当初は性能的な利点のあるPVがよい選択肢ではあったが、ホストする側のマシン
Amazon EC2(Linux)のswap領域ベストプラクティス | DevelopersIO
ども、大瀧です。 Linuxのメモリ管理で欠かせないのがswapですよね。EC2のディスク管理には独特な仕様があるのでその辺りを踏まえつつ、EC2(Linux)でどのようにswap領域を用意するのが良いのかまとめてみたいと思います。 理屈をこねながらの解説になるので、先に本エントリーの結論を。 公式AMIにはswap領域が含まれない m1.small、c1.mediumには900MBのスワップ領域がおまけでついてくる(Amazon Linux AMIであれば、Cloud-initによって自動マウントされる) swap領域には、インスタンスストア(別名Ephemeral Disk)を使うべし では、それぞれ見ていきます。 公式Linux AMIの初期構成にはswapパーティションが無い Amazonから提供される公式のLinux AMIのブートディスクには、swapパーティションが含まれてい
EC2にJenkinsによるCI環境を作成する | DevelopersIO
渡辺です。AWSチームにジョインしてから1ヶ月ほどになりますが、あまりAWSを活用していません。 これではイカンということで、JenkinsによるCI環境をEC2上に構築してみました。 構築の流れ こんな流れで構築します。 EC2インスタンスを作成し、ElasticIPを割り当てる 最新のJDKをインストールする Jenkinsを起動する Jenkinsのセキュリティを設定する EC2インスタンスを作成し、ElasticIPを割り当てる AWSを使い慣れている人にとっては簡単な作業ですが、使い慣れていないと戸惑う所も多いところです。折角なので丁寧に解説します。 予めAWSのアカウントは各自で作成しておき、AWSの管理コンソールにログインしてください。 EC2インスタンスの作成 はじめにEC2(Amazon Elastic Compute Cloud)のインスタンスを作成します。 EC2はA
Packer by HashiCorp
Images as codePacker standardizes and automates the process of building system and container images. Multi-cloud image workflowCreate one workflow for images across multiple clouds and private infrastructure. Extend Packer with pluginsPlugins extend Packer’s functionality without modifying Packer's core by adding new builders, provisioners, post-processors, and data sources.
AWS, chef, Cinnamon等を使った無停止デプロイ(PrePAN carton 1.0化の裏側) - $shibayu36->blog;
最近PrePAN uses carton 1.0 now! - $shibayu36->blog;でも書いたとおり、PrePANのcarton 1.0化を進めていました。 通常であれば変更点をアプリケーションサーバにデプロイし、サーバを再起動すれば良いのですが、cartonを0.9から1.0に上げるというまあまあ大きな変更を加えるため、事前に動作確認を行い、無停止でデプロイしたいと考えました。そこでAWSを使って無停止デプロイを試してみたのでそれについて書こうと思います。 PrePANのサーバ構成やデプロイ手順の検討 無停止デプロイの説明の前にPrePANのサーバ構成を紹介しておきます。 現状はELB 1つに対し、EC2が2台ぶら下がっているという状態で運用しています。そしてEC2に対してはそれぞれapp-1, app-2という名前でタグがついています。 開発メモ#2 : AWS でのホス
EC2でvsftpdのpasv_addressをbootupのしかけでどうにかする - c/fe
AWSのEC2くそおそいね！（挨拶） LargeがさくらのVPS 4Gの4倍くらい遅い！値段何倍だよ！（挨拶） Groongaをビルドしたら30分かかった！（挨拶） ーー AWSを仕事で使う機会が最近また出てきました。 まあそれがどうしたって感じですけど、まあ今までとちょっと違う感じのお客さんなのです。 まあ、うまくぼかして言うと、FTPとかつかえないとダメなんですよね。びたいちぼかせてないけど。 「えーマジＦＴＰ？」「ＦＴＰが許されるのは・・・」 世の中にはＦＴＰがないと呼吸困難になって死ぬ人がいるらしいので、仕方がありません*1 オチ yum install vsftpd してvsftpを入れて、 AWSのセキュリティゾーンに Custom TPC rule Port range:60000-60010 Source:0.0.0.0/0 と Custom TPC rule Port r
Vagrant 1.1 で EC2 を vagrant up - naoyaのはてなダイアリー
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以外はオープンソースで公開さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
