Amazon EC2編～必ずしておくCentOS初期設定～
こんにちは、TKです。 今回はAWSでCentOS6を使用する場合、初期設定で一通り必要なものをまとめました。 AWSの標準OSのAmazon Linuxではコンソール上でできたことが反映されなかったりするので色々設定する必要があります。 今回のレシピは自分自身がCentOS6を触るにあたって必要だったことをまとめています。 今回使用しているAMIはCentOS6 with Update HVM 64bitになります。 容量の反映と一般ユーザの追加 作成したCentOS6のインスタンスにログインしてみます。 Amazon Linuxと異なり、デフォルトのユーザはrootしか存在しません。 ログインはrootユーザでログインを行います。 ログイン後ボリュームのサイズを確認します。
EC2編～PVインスタンスからHVMインスタンスに移行してみた～
こんにちは、TKです。 今回は仮想化方式の切替についてお話したいと思います。 現在AWSは、HVM方式のインスタンスが出てきたことによって、PV方式よりもメモリが多く、料金が安いので移行したいという方は多いと思います。 今回は、PV方式のインスタンスからHVM方式のインスタンスへの移行について検証を行いました。その際にわかったことについて書きたいと思います。 仮想化方式の違いについて PV方式は準仮想化で、HVMは全仮想化となっています。基本的にはHVM方式がパフォーマンスは高く、利用料金も安いといった特徴があります。 それでは実際に仮想化方式を変えるにはどのようなことを行うのでしょうか。 PVからHVMへの移行の方法はこの2つのサイトを見て行いました。 http://dev.classmethod.jp/etc/pv2hvm-rb/ http://www.agilegroup.co.jp
Auto Scaling を試してみた - Qiita
Auto Scaling の概要については ↓ Auto Scaling なお、起動に失敗した場合はエラーメッセージに従って、下記のリファレンスを参考にトラブルシュートをするとよい。 Amazon EC2 Auto Scaling のトラブルシューティング: EC2 インスタンスの起動失敗 ■事前準備 ELBは予め作成済のものとします。 1.起動設定 「起動設定」から「起動設定の作成」 1. AMI の選択 今回は作成済のAMIから起動するようにしました。 以下は通常のEC2インスタンスの起動と同じ設定なので、詳細は省略します。 2. インスタンスタイプの選択 3. 詳細設定 4. ストレージの追加 5. セキュリティグループの設定 6. 確認 2.Auto Scaling グループの作成 1. Auto Scaling グループの詳細設定 今回はMIN:2、MAX:4でAuto Scal
CentOS7の最新AMI IDをAWS CLIで取得する方法 | DevelopersIO
CentOS7の最新AMI IDを調べようと思っても意外と見つからない、という経験はありませんか？自分はあります。CentOSの最新AMI IDを取得する方法を調べたのでご紹介したいと思います。 最新AMI IDの取得方法 Cloud/AWS - CentOS Wiki 上記が公式のWikiですが、メンテされていないようで最新のAMI IDの記載がありませんでした。しかし、AWS CLIで検索する際にヒントとなる情報がありました。product-codeをfilter条件に入れることで公式のAMIだけを抽出できるようです。各OSのProduct Codeは下記になります。 OS Product Code Wikiで紹介されているのが、CentOS7のAMIを検索する方法です。 $ aws --region us-east-1 ec2 describe-images --owners aws
AWSのCentOS8 AMI - Qiita
公式イメージ CentOS 8でEC2インスタンスを作成しようと、AWS MarketplaceからCentOS 8で検索すると、ずらずらっといくつかAMIが表示されるものの、公式イメージが出てきませんでした。 まだ、公式イメージは提供されてへんのかいな…と途方に暮れかけていたところ以下のページを発見。 AMIの画面からインスタンスを作成したいリージョンのAMI IDを入力して検索すると出てきます。 例えば東京リージョンであれば、ap-northeast1なので、「ami-089a156ea4f52a0a3」で検索 出てきた。 ここから起動して、とりあえず使ってみよっと。
AWS EC2 の仮想化方式を paravirtual から hvm に変更する - Qiita
仮想化方式を変更することにしたきっかけ インスタンスの稼働枠に空きがない (キャパシティ不足) ために、インスタンスを起動できないことがたびたび発生した 後継のインスタンスタイプの方が、費用が安いうえにスペックが高い リザーブドインスタンスの期限が近づいてきていた から。 運用を継続するにあたって、1. のキャパシティ不足でインスタンスをたびたび起動できないことがあり、古いインスタンスタイプを運用し続けることに危機感があった。 AWS の FAQ に「Amazon Linux 準仮想化 AMI からハードウェア仮想マシン AMI にデータとアプリケーションを移行する方法を教えてください」があるので、わざわざ Qiita に残すことはないと思ったが、実際に自分が実行してみて、わかりにくいところやはまったところを備忘録として残しておこうと考えた。 PV インスタンスを HVM インスタンスに変
(レポート) DEV301: AWS CLIによる自動化 #reinvent | DevelopersIO
渡辺です。 みんな大好きAWS CLIのセッション資料「(DEV301) Automating AWS with the AWS CLI」を読んでみました。 [slideshare id=53748614&doc=dev301-151009173049-lva1-app6892] AWS CLI AWS CLI（Command Line Interface）は、Amazon Linuxでは標準でインストールされているAWSの各種サービスを操作することの出来るコマンドです（他のOSはインストーラなどが提供されている）。 コマンド単体ではインタラクティブにひとつの操作しかできませんが、シェルスクリプトを作成することでかなりの作業を自動化することができます。 シェルスクリプトと親和性が高いため、簡単なタスクであればシェルスクリプトとして作成し、cronなどで運用すると便利です。 良いシェルスクリ
RedmineをAWS無料枠に5分で用意して10分で自動バックアップできるようになる - Qiita
はじめに Redmineすごく便利です。やる気が出ないときでもチケットの一覧として並んでいて、それをこなして行くと段々とやる気がでてきます。 またここ最近になってAWSを使い始めたのですがそのお手軽さに感動しています。 ということで今までは自前のサーバでRedmineを運用していましたが、AWSでRedmineを立ててみました。 自分用のメモとしつつ、次回同じサーバを立てるときに5分で構築、10分でバックアップという目標を達成できる用にメモします。 BitnamiのAMIをつかってEC2にインストール 全体の流れは次の通りです。 EC2インスタンスの作成画面へ行く AMIからインスタンスを選択する 作成が完了するのを待つ 管理者用のパスワードを確認する IPアドレスを確認して接続する 完了！ 個人的にあまりAWSには慣れていないので順に追って説明します。 AWSコンソールからEC2を選び、
EC2起動後に、後からできること・できないこと - 続 カッコの付け方
EC2はインスタンス起動時に色々聞かれます。一度起動した後に変更できるもの、出来ないものをまとめてみました。間違いも有るかもしれませんので、そのつもりで。気づいたら直していきます。 Target RunningでOK StoppedでOK メモ AMI No No AMI変えるなら、もちろん作り直し Instance Type No Yes AMIが pvかhvn で移行可能な対象が変わります VPC No No Subnet No No Auto-assign Public IP No No こんな時はEIP使いましょう IAM Role Yes Yes 出来そうで出来ないその1 Dummyで良いので仕込んでおきましょう。2017/04/07現在で対応可能に！ Shutdown behavior Yes Yes 即時反映可能 termination protection Yes Yes
Amazon Web Services(AWS) のEC2でインスタンスをコピーする方法 - Qiita
AWS使い始めて 業務命令でAWSを使い始めて、3時間目ｗ。インスタンスのコピーどうやるんだろう？って調べてみた。 インスタンスのコピー 日本語でAWSマネジメントコンソールが利用可能(2015/04/22から)になっていたので自分備忘録ですｗ。ほんと最近すぐに物忘れするのでこういうメモは、必要だよねｗ kvm のようにちょっと面倒かと思ったらそうでもなく、インスタンス元をベースにして高パフォーマンスのインスタンスを生成するとか簡単にできるので、CPUによって処理コストがどれくらい違うとかとか色々遊べそう。 ちなみに、Elastic IP は当然引き継がれないので別途設定する必要があります。 AMI作成 EC2ダッシュボードをまずは選択します。で、左のメニュー「インスタンス」を選択し、コピーしたいインスタンスを選択します（インスタンスは、停止しておいたほうがよい）。 アクションのプルダウン
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がよい選択肢ではあったが、ホストする側のマシン
AWSに簡単に構築できるクラウドストレージ対応ファイルサーバ『MagFS』を試用してみた - サーバーワークスエンジニアブログ
MagFSは米Maginatics社が開発するクラウドストレージ対応広域共有ファイルサーバです。 ファイルサーバといってもハードはなく、仮想ソフトウェアアプライアンスで提供されています。 VMwareもしくはAmazon EC2に対応し、今回、Amazon EC2版を試用する機会を得ましたので、サーバ構築・導入から実際にファイルをMagFSに置いてみるまでをレポートいたします。 MagFSの特徴を以下に挙げます。 クラウドストレージで広域同期ファイル共有を実現 メタデータサーバと独自キャッシュ技術によりアクセスが高速 非同期に、各拠点やクライアント間でデータを共有できる AES256ビット暗号化処理でデータ保護はセキュア Active Directoryとも連携でき、アクセス制御の一元管理が可能 ストレージはAmazon S3に対応 クライアントは、Windows、Mac OSX、Linu
EC2のディスク容量(EBS)を拡張する - Qiita
口上 単純に snapshot をとってそこから大きくしたいサイズの volume を作って インスタンス に アタッチ しなおして resize2fs すればいーじゃんと思ってたら、"Nothing to do!" と出てしまいうまく行かなかったので、その時に対応した自分用メモ。Management Console の細かい操作については結構省いています。 対象インスタンスの環境 EC2 AMI : CentOS 6 (x86_64) - with Updates HVM ディスク容量 : 8G → 36G 手順 対象インスタンスの snapshot を取得する(出来るなら停止させてからがベスト) snapshot から volume を作成する。この際に拡張したいサイズで作成する(今回は36Gで) AmazonLinux(HVM) でSSHの可能な EC2 作業用インスタンスを適当にた
EC2の新インスタンスタイプ”C4″をベンチマークしてみた | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 re:Invent 2014でアナウンスされていた新しいEC2のインスタンスタイプ"C4"を使用できるようになりました。C3に比べて、どの程度早くなったのか計測してみました。 C4自体の説明はせーのがAmazon EC2の新インスタンス「C4ファミリー」を触ってみたという記事を書いておりますので、こちらを参照下さい。 2015/01/14 15:20 ディスクアクセスのパフォーマンスに関する箇所は、内容を取り下げます。 ベンチマーク インスタンス全体のパフォーマンスを計速します。 計測環境 計測ツールはいつも通りにUnixBenchを使用します。 計測内容は以下の通りです。 UnixBench 5.1.3 EC2インスタンス：c3.large(2並列)、c4.large(2並列)、c3.xlarge(4並列)、c4.xlarge(4並列
インスタンスの選択方法（最適なサイジング）と起動方法 | 超高速 WordPress AMI AMIMOTO
これから「網元AMI Masterへの道」と題し数回に分けて網元AMIを中心にWordPressの運用や効率的な管理をご紹介したいと思います。 第１回目は、数あるインスタンスの中でどれを選べばいいのか、そしてAWS Market Placeを利用したインスタンスの起動方法をご紹介します。 EC2のリージョンの選択 AWSは世界中の複数地域にリージョンと呼ばれるデータセンター群があります。 US East (Virginia) US West (Oregon) US West (Northern California) EU West (Ireland) Asia Pacific (Singapore) Asia Pacific (Sydney) Asia Pacific (Tokyo) South America (Sao Paulo) EC2でインスタンスを作成する時、どのリージョン（
AWS EC2インスタンスをPV形式からHVM形式に変換する（≒t1からt2に移行する） - Qiita
参考URL EC2のt1.microをt2.microへ移行する 手作業でPV -> HVMへの変換を行う方法 AWSで仮想化方式 PV(paravirtual) の既存 CentOS AMIを HVMにする 1の作業手順をベースに、少し改変を加えたもの シンボリックリンク追加のところが一番のミソ PV->HVM変換ツール pv2hvm.rbを試してみた ・Rubyスクリプトに変換作業を代行してもらう方法 ・2015-05現在では、sudo gem install aws-sdk --no-ri --no-rdocのところは、aws-sdkのv1を明示してインストールする必要があることに注意（参考：AWS SDK for Ruby V2） ・色々と問題が起きた（ルートデバイス名とブロックデバイス名を合わせないと動かない等）ため採用しなかった EC2編～PVインスタンスからHVMインスタンス
Amazon EC2(Linux)システム管理で知らないとハマる5つの環境設定 | DevelopersIO
ども、大瀧です。みなさん、EC2をバリバリ使ってますか?使いたいときにすぐ使える仮想マシンとして、開発・検証から本番まで幅広く活用されていると思います。 日頃EC2を業務で運用する中で、EC2インスタンスをコピーすると意図しない環境設定に変わってしまうというトラブルが度々あり、cloud-initというツールに拠ることがわかってきました。 「EC2インスタンスのコピーなんて、一旦インスタンスを作成したあとはあまりやらないのでは?」と思われがちですが、EC2独特の制限などもあり、実際の運用では思ったよりも頻繁にインスタンスのコピーが必要になります。インスタンスのバックアップ&リストアなどはイメージしやすいと思いますが、それ以外にも意外なケースとして以下があります *1。インスタンスのコピーは、AMI(Amazon Machine Image:インスタンスのバックアップ)を取得し、新規インスタ
Amazon LinuxにRuby on Rails環境構築(rbenv + ruby-build + Ruby 2.2.1 + Rails 4.2.1インストール) - Qiita
Amazon LinuxにRuby on Rails環境構築(rbenv + ruby-build + Ruby 2.2.1 + Rails 4.2.1インストール)RubyRailsAWSrbenvruby-build はじめに AWSのEC2インスタンス(Amazon Linux)上にRuby on Rails環境を構築する手順です。 Amazon Linuxにrbenv 0.4.0-146 + ruby-build + Ruby 2.2.1 + Rails 4.2.1をインストールします。 EC2インスタンス作成時に使用したAMI ・Amazon Linux AMI 2014.09.2 (HVM) - ami-18869819 Ruby on Railsをインストールする環境 ・Amazon Linux (3.14.35-28.38.amzn1.x86_64) 参考ページ Ruby
Amazon EC2でIDS(侵入検知システム)を導入する – AIDE – | DevelopersIO
IDS(侵入検知システム)とは IDS(Intrusion Detection System)は、不正な第三者からの侵入を検知して通知する仕組みです。主にネットワーク型とホスト型があり、前者の代表的なツールはsnort、後者はtripwireです。始めは、自前でセットアップしたsnortから試そうと思ったのですが、Amazon EC2はプロミスキャスモード(ネットワークに流れる全てのパケットを受信するモード)を禁止しているため使えません。解決方法として、商用snortを提供しているSourcefire社の専用AMIを使う必要がありそうです(プロミスキャスモードで動くのかな？)。よし、じゃぁこのAMIを使おうと思ったら、このAMIは東京リージョンには無いw。そこで、ネットワーク型のIDSは別の機会として、今回は、ホスト型IDSの動作確認をすることにしました。ホスト型IDSで、Amazon L
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon Elastic Compute Cloud