AWSでデプロイとスケーリングを自動化する方法まとめ - Qiita
概要 AWSではアプリケーションのデプロイや、システムのスケーリングを自動化することができます。 しかしそれらを実現しようとすると、似たようなサービスの中から用途に合ったものを選ぶ事になると思います。 今回は選択肢となり得るサービスを挙げて、それぞれの出来る事、出来ない事をベースに比較していこうと思います。 比較の軸 以下のように、評価軸を設けました。 サービスの機構として提供されているものは◯とします。 機構として提供されているが、使い難いものは△とします。(例: AWS CLIを利用した場合のみ利用可能など) 機構としては提供されていないが、別の機構などを組み合わせることで容易に実現可能なら△とします。 別の機構などを組み合わせても辛い場合や、実現不可能なら×とします。 デプロイ自動化 まずはアプリケーションのデプロイを自動化するサービスの比較を行います。 以下の4つの選択肢があります
AWS SDK for Ruby でインスタンスのステータスを取得するメモ | cloudpack.media
コード #!/usr/bin/env ruby require 'aws-sdk' ec2 = AWS::EC2.new( :access_key_id => 'AKxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', :secret_access_key => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', :ec2_endpoint => 'ec2.ap-northeast-1.amazonaws.com', ).client # 0 (pending), 16 (running), 32 (shutting-down), 48 (terminated), 64 (stopping), and 80 (stopped) p ec2.describe_instances(:filters => [{ 'name
Docker Image Insecurity · Jonathan Rudenberg
December 23, 2014Recently while downloading an “official” container image with Docker I saw this line: ubuntu:14.04: The image you are pulling has been verified I assumed this referenced Docker’s heavily promoted image signing system and didn’t investigate further at the time. Later, while researching the cryptographic digest system that Docker tries to secure images with, I had the opportunity to
本気で使う Docker - Qiita
Docker Advent Calendar 2014 12/25 の記事、本気で使う Docker です。 ということで、実際に弊社で Docker を使った運用を開始した際にはまったところや、悩んだ所、どういう風に使っているのかについてぱらぱらっと書こうと思います。 "本気" なぜ Docker を使うのか、というと、僕の中では以下のような理由があります。 すべてのアプリケーションを(インフラ的に)同じ方法でデプロイ、管理したい 特定のサーバー / インスタンスの状況に依存することなく、アプリケーションの依存とインフラ都合の依存を別管理したい Docker なんかかっこいいっぽいし使ってみたい 上記のような都合から、どうやって作っていくかを考えていきます。基本的には1番目と2番目の理由が重要です。 Docker コンテナのいいところ とある Rails アプリケーションをデプロイするた
第1羽 ひと目で、尋常でない言語だと見抜いたよ
この投稿は ごちうさ住人 Advent Calendar 2014 の25日目の記事です。 ゴミ人間(@gomi_ningen)です！春からラビットハウスでエンジニアのお仕事をしています！同僚のJavaちゃんや可愛い妹のScalaちゃんと楽しく働いています♪[1] エンジニアのなかでも主にソフトウェアに関わるお仕事の見習いをしていて、日々良いサービスを提供できるように修行を積んでいる最中です。そんななか、ひとつ気付いてしまったことがあります。 私はこの春「ご注文はうさぎですか?」に出会って以来、その作品の素晴らしい魅力に引き込まれていて、気付いたら身の回り、そして心の中には常に「ごちうさ」がある状態になっていました。しかしながら、お仕事に集中している時間だけは同僚のJavaちゃんのことを考えているということに違和感を覚えました。 どうせなら常に「ごちうさ」とともにありたいものです。そこで「
MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する
メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！ というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。 前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。 GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
