タグ

ブックマーク / dev.classmethod.jp (28)

  • RI(リザーブドインスタンス)について出来るだけ簡単にまとめてみた | DevelopersIO

    こんにちは。池田です。札幌はすっかり雪景色ですすっかり寒くなってきました(投稿したあと外へ出ると見事に雪がとけていました...)。 *スタンダードRIの「結合」やコンバーティブルRIの「交換」に関わる記載に一部情報が不足していましたので追記しています。 先日友人事をしていたときにRI(リザーブドインスタンス)に関する話題になりました。 その場では下記の記事を参照しつつさらっと説明する感じで済ませたのですが、正しく理解したいと思ったので確かめつつ基的なことをまとめてみました。 【レポート】AWS のコスト最適化入門#AWSSummit Amazon EC2リザーブドインスタンス リージョン単位のインスタンスタイプが柔軟になりました [2016版] Amazon EC2 購入オプションを理解する [コストダウン] そもそもRIとは? リザーブドインスタンスという名称からRIもひとつのイン

    RI(リザーブドインスタンス)について出来るだけ簡単にまとめてみた | DevelopersIO
  • プロセッサの脆弱性「Meltdown」と「Spectre」についてまとめてみた | DevelopersIO

    森永です。 新年早々大変な脆弱性が出てきてセキュリティクラスタがざわついてます。 内容によって2つの脆弱性に分かれていて、「Meltdown」と「Spectre」と名前がつけられています。 現在使用されているほぼ全てのCPUにおいて対象となりうるという相当影響範囲が広い脆弱性です。 まだ詳細が公開されていない部分もありますが、パッチで対処できる脆弱性ですので落ち着いて対応し、続報を待ちましょう。 現在分かっている範囲の情報をまとめます。 Meltdown and Spectre 概要 今回の脆弱性は大きく3つに分けられます。 Variant 1: bounds check bypass (CVE-2017-5753) Variant 2: branch target injection (CVE-2017-5715) Variant 3: rogue data cache load (CV

    プロセッサの脆弱性「Meltdown」と「Spectre」についてまとめてみた | DevelopersIO
  • 【レポート】マルチアカウント戦略におけるセキュリティとガバナンスのアーキテクチャ設計 #reinvent #SID331 | DevelopersIO

    こんにちは、虎塚です。 re:Invent 2017のセッション「Architecting Security and Governance Across a Multi-Account Strategy」(マルチアカウント戦略におけるセキュリティとガバナンスのアーキテクチャ設計) についてレポートします。時間の都合で現地参加が叶いませんでしたので、動画を視聴しました。 発表は、AWSのSam ElmalakさんとThomson ReutersのBen Woodwardさんでした。 AWS re:Invent 2017: Architecting Security and Governance Across a Multi-Account Stra (SID331) - YouTube 個人が学習目的でAWSを使うならいざしらず、エンタープライズの組織が1個のAWSアカウントですべてのシステ

    【レポート】マルチアカウント戦略におけるセキュリティとガバナンスのアーキテクチャ設計 #reinvent #SID331 | DevelopersIO
    miya-jan
    miya-jan 2017/12/22
    AWSの複数アカウント戦略について。圧倒的知見だけど、この数のルートアカウントのcredentialsをどうやって管理してるのかが気になる。
  • Terraform v0.9→v0.11までの変更点をまとめてみた | DevelopersIO

    はじめに こんにちは、佐伯です。 私自身がTerraformのバージョンアップについていけてなかったので、キャッチアップすべくいっきにv0.9からv0.11までの大きな変更をざっくり追ってみたいと思います。v0.9からなのはこちらでv0.8の紹介をしているためです。なお、プロバイダーごとの変更などは省いており、Terraform体の機能についての変更を挙げています。 0.9.0 (March 15, 2017) Remote Backends v0.8では、Terraform管理対象リソースの状態を保存しているtfstateファイルをリモートに保存するためにterraform remote configでバックエンドの設定をしていました。v0.9からはremoteサブコマンドが廃止され、Terraformファイルで設定できるようになりました。 以下はS3にtfstateを保存する場合の例

    Terraform v0.9→v0.11までの変更点をまとめてみた | DevelopersIO
  • エンジニアがブログを書き続けるための5つのマインドセット | DevelopersIO

    はじめに こんぬづは、最近はパスピエというグループにハマっていて聞いていると開発とブログが捗る田中です。 今回はエンジニアがブログを書き続けるために必要だと私が考えているマインドセットの方法を紹介します。 もくじ 対象読者 この記事の説明 あなたが書いた記事は「必ず」誰かの役にたつ 目標設定は「あとづけ」する フィードバックを得る機会を持つ マサカリは怖くはないし役に立つ 数字を何気なく追う まとめ 対象読者 ブログを書こうと思っているが書けずに苦戦しているエンジニアの人 これからブログを書いてみようかなと思っているエンジニアの人 メインの対象読者はエンジニアを想定していますが、記事はブログ書きをする人に共通して必要なマインドセットとしても捉えられるため、エンジニアに限らずブログを書こうと思っている人、書く必要に迫られている人に読んでほしい内容にもなっています。 この記事の説明 最近私の

    エンジニアがブログを書き続けるための5つのマインドセット | DevelopersIO
  • KMSで認証情報を暗号化しLambda実行時に復号化する | Developers.IO

    データベースやAPIサーバーなど外部システムと連携する際には、往々にして認証情報が必要になります。 今回は AWS Key Management Service (以下 KMS) の共通鍵暗号の仕組みを使い、暗号化した認証情報を AWS Lambda 関数のコードに埋め込み、関数呼び出し時に認証情報を復号化する方法を紹介します。 基的なアイデアは次のブログで書かれており、KMS を使った暗号化処理だけを自分向けメモも兼ねて抜き出しました。 http://ijin.github.io/blog/2015/08/06/github-to-lambda-to-slack/ KMS ではマスターキーを使って暗号・復号する処理が API で切り出されているため、この API を使って認証情報を暗号化します。 KMS と Lambda の連携 以下の流れで動作確認します。 AWS KMSマスターキー

    KMSで認証情報を暗号化しLambda実行時に復号化する | Developers.IO
    miya-jan
    miya-jan 2016/08/18
    lambdaで認証情報などを乗せるときはKMSを使って暗号化・復号化するのがいいっぽい
  • Google Container Engine (GKE) を触ってみた | DevelopersIO

    この記事はこちらから転載したものです。 ども、大瀧です。 日未明、Google社のイベントGCP Liveで新サービスのGoogle Container Engine(GKE)が発表されました。 GKEは、Googleを中心に開発されているDockerコンテナの管理ソフトウェアKubernetesのクラスタを簡単にデプロイできるサービスです。Dockerコンテナの実行にはGCE(Google Compute Engine)を利用します。現在はAlpha Releaseです(リリースポリシーはこのブログエントリーが詳しいです)。 既に実際に動かせるようになっていたので、コンテナをデプロイするまでを試してみた感想をレポートします。 クラスタの作成 GKEのドキュメントでは、全てCLI(gcloudユーティリティー)で説明されていますが、クラスタ作成はDevelopers Console画面か

    Google Container Engine (GKE) を触ってみた | DevelopersIO
  • ユニットテストにまつわる10の勘違い | DevelopersIO

    渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード(または実行結果)を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。

    ユニットテストにまつわる10の勘違い | DevelopersIO
    miya-jan
    miya-jan 2013/09/17
    カバレッジよりレバレッジということですね