GitHubへのpush時にCodeDeployを使ってEC2にアプリケーションをデプロイする - Qiita
EC2へのアプリケーションのデプロイを考えた時に色んな候補があるかと思います。以下にまとまっていました。 AWSでデプロイとスケーリングを自動化する方法まとめ 最初、OpsWorksを検討したのですが、オートスケーリングに対応していないという点でボツとなりました。。。また、Jenkinsなどを使えば可能だと思いますが、その場合にはJenkinsをSPOFにならないように気をつけたり、AWSと連携するためにごにょごにょするのが面倒かなと思いました。 で、まだtokyoリージョンにはきていませんが、CodeDeployはオートスケーリングが対応しており、どうだろうということで色々試してみたたのでメモ。 今回の例ではGitHubへのpush時にCodeDeployを利用してEC2にWordPressのデプロイを行ってみました。 CodeDeployとは アプリケーションのデプロイを行うためのサー
Amazon EC2(Linux)システム管理で知らないとハマる5つの環境設定 | DevelopersIO
ども、大瀧です。みなさん、EC2をバリバリ使ってますか?使いたいときにすぐ使える仮想マシンとして、開発・検証から本番まで幅広く活用されていると思います。 日頃EC2を業務で運用する中で、EC2インスタンスをコピーすると意図しない環境設定に変わってしまうというトラブルが度々あり、cloud-initというツールに拠ることがわかってきました。 「EC2インスタンスのコピーなんて、一旦インスタンスを作成したあとはあまりやらないのでは?」と思われがちですが、EC2独特の制限などもあり、実際の運用では思ったよりも頻繁にインスタンスのコピーが必要になります。インスタンスのバックアップ&リストアなどはイメージしやすいと思いますが、それ以外にも意外なケースとして以下があります *1。インスタンスのコピーは、AMI(Amazon Machine Image:インスタンスのバックアップ)を取得し、新規インスタ
Amazon EC2(Linux)のswap自動作成を行うRPMパッケージ ec2-swap を作ってみた | DevelopersIO
ども、大瀧です。 前回のブログエントリーで、「EC2のswap領域は起動時にインスタンスストア上に作るといいよ！ただしインスタンスストア既定のファイルシステムはオススメできなくて、その辺ごにょごにょ実装してね☆」という、微妙にイケてないベストプラクティスを提言してみました。「なんだよ、簡単にできるんじゃないのかよっ！」とご立腹の方もいるかもしれません。アンサーブログとまでは言いませんが、簡単にその辺りの機能を実装するRPMパッケージ ec2-swap を作ってみたので、使い方と仕組みをご紹介します。 動作確認環境 Amazon Linux AMI 2013.09.2 - ami-0d13700c (64-bit) ロードマップとしては、CentOSとRHEL AMIを近日中に動作確認、aptリポジトリの作り方がわかればUbuntu(debパッケージ)向けに対応していきたいです。(小声で)
Ephemeral Diskを贅沢にswapに使ってみる - サーバーワークスエンジニアブログ
こんにちは、サーバーワークスの三井です。 いよいよ寒くなってきて、物理サーバの温もりが恋しくなってきましたね。ラックの裏側は温かいし、常に一定のトーンで鳴り響くファン音があらゆる雑念を振り払ってくれるので集中するには持ってこいの場所ですよね（遠い目 さて閑話休題、今日はEC2インスタンスのEphemeral Diskをswap領域として贅沢に使う方法について簡単に紹介します。 Ephemeral Diskとは今更かもしれませんが確認です。 Ephemeral Diskとは、インスタンスストア(Instance Store)とも呼ばれる、揮発性のストレージです。揮発性なので、EC2インスタンスを停止するとデータは削除されます。 EC2インスタンスが稼働する物理ホストのディスクアレイの一部を切り出してアタッチするので、ネットワーク経由でアタッチされるEBSと比較して速度が早いという特徴がありま
CloudInit を使って Amazon EC2 をスマートに立ち上げる | はったりエンジニアの備忘録
仕事でもプライベートでもお世話になってる Amazon EC2。サーバ環境を気軽に構築できる反面、最初の設定がやや手間です。 CloudInit を使うと EC2 インスタンスを起動したときにお決まりの作業、たとえばパッケージのアップデートや環境設定の変更を自動化することができます。 CloudInit はもともと Ubuntu で開発されたツールですが Amazon Linux にも採用されています。 CloudInit - Community Ubuntu Documentation 今回は以下の 4 つを CloudInit で自動化してみます。 パッケージのアップデート ロケールの設定 タイムゾーンの設定 必須パッケージのインストール Cloud Config の準備 #cloud-config repo_upgrade: all packages: - ruby19 runcmd
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 メンテナンスで慌てないための 4 つの設計ポイント | はったりエンジニアの備忘録
公式ブログでもアナウンスがありましたが、月末にかけて EC2 のメンテナンスが行われます。 EC2 メンテナンスアップデートに関して EC2 のメンテナンスには、ゲスト OS を再起動するインスタンスリブートと、ホストの物理サーバを再起動するシステムリブートの 2 つがあります。どちらのメンテナンスが予定されているかは EC2 Management Console の Events ページで確認できます。詳しいことは Amazon EC2 のメンテナンスのヘルプページに書いてあります。 今回は Xen のセキュリティ対応ということでシステムリブートが必要になりますが、どちらのメンテナンスでもユーザーの都合に合わせて事前に実施することができます。 インスタンスリブート: ゲスト OS にログインして再起動させるか、EC2 Management Console で Reboot を選択 システ
EC2インスタンス(Amazon Linux)の初期設定 : アジャイル株式会社
文字コード設定 文字コードを日本語に設定しておきます。 $ sudo vi /etc/sysconfig/i18n 以下内容で設定します。 #LANG="en_US.UTF-8" LANG="ja_JP.UTF-8" タイムゾーン設定 デフォルトでは日本時間にはなっていないので必要に応じて適宜変更します。 $ sudo cp /usr/share/zoneinfo/Japan /etc/localtime 日本時間になったかどうかは以下で確認できます。 $ date 2014年 3月 6日 木曜日 13:20:47 JST 実は上のようにコピーしただけの場合、yum によるアップデート/再起動後にタイムゾーンがUTCに戻ってしまう場合がありました。 これに関しては、/etc/sysconfig/clock に以下の設定を行います。 $ sudo vi /etc/sysconfig/cloc
Amazon EC2 で SSH するなら ec2-ssh が便利 - m.igrs.jp
AWSを本格的に使い始めて約3ヶ月になる新参者です。 便利過ぎて今までの時間を返して欲しいくらいなのですが過ぎたものは仕方ないので前に進みましょう。 EC2 への SSH 接続 Amazon EC2 上のインスタンスにSSH接続するベーシックな方法は ですが、これでは何のサーバに接続しているのかさっぱり分からないのでこのまま運用している人はまずいないでしょう。 (AWS Management Console から毎回コピペでがんばっている人はいそう) ~/.ssh/config おそらく多くの人は ~/.ssh/config の設定にそれぞれ工夫を凝らしているのかと思われますが、 インスタンス数が増えてくると ~/.ssh/config の更新も煩わしくなります。 また Auto Scaling 等のダイナミックな運用になるととても追いつきません。 既存サポートツール ec2ssh その煩
Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。
Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。 鯖管のメモ帳: AWSのELBでHealthyHostCountが0になるという記事の中で ■AWSのELBとApacheを使う際の注意点 ・Timeoutは120以上が推奨 ・ApacheのKeepAliveは有効にすべし。ELBとの接続効率があがる。 という形ですでにやるべきことは書いてあるのが、なぜそうなるか。。(いそがしい人は後は読まなくてok！) 根本的な理由としては、ELBはTCPを単にリレーしているのではなくて、アプリケーションレイヤのプロキシであることによるものが大きい。ELBはバックエンドのEC2との間で無通信の場合でも60秒はセッションを維持する。 ELBはTCP Persistent Connectionを提供し、webサーバとの間のTCP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
