タグ

2018年8月1日のブックマーク (9件)

  • 安全なVPC設計

    安全なVPC設計 Tweet VPCの構築はAWS を使って Web サービスを構築する上で避けて通れないものですが、デフォルトで作成済みの VPC はセキュアとは言い難いものです。 しかしながら、正しい VPC を構築するためにはネットワークに関する知識に加えて AWS 特有の事情も関わってくるため、Web アプリケーション開発者にとって容易なものではない場合が多いでしょう。 この記事では、私のおすすめする VPC の設定の紹介と、なぜそのような設定がよいのか、他の設定と比較します。 public と private サブネット public サブネットとは、インターネットにアクセス可能なサブネット、つまり、そのサブネットのルートテーブルに Internet Gateway が設定されているサブネットのことです。 一方で private サブネットとは、直接のインターネットアクセスのでき

    安全なVPC設計
  • cloudpackブログ - セキュリティグループの方針を3つのパターンに分けてみた

    今回は、今までの経験からセキュリティグループ(VPC)の設計方針の典型例を以下の3つにまとめてみました。 VPC内のリソースは、すべてお互いに通信可能 1番運用が楽 PublicやPrivateなサブネット内は、すべてお互いに通信可能 オンプレに多いパターンなのでオンプレからの移行によく利用 VPC内の必要な通信経路のみ許可 セキュリティ要件が高い場合は必然的にこちらになる 尚、VPC内やPublic/Privateセグメント内で、すべてのリソース(EC2/ELB/RDS)が お互いに通信できるようにするには、下記のように自分自信(セキュリティグループ)に対して すべての許可をするようにしておけば可能です。 該当リソース(EC2/ELB/RDS)に、このセキュリティグループを付与すると、お互いにすべての通信ができるように なります。 ○VPC内のリソースは、すべてお互いに通信可能 下記のよ

    cloudpackブログ - セキュリティグループの方針を3つのパターンに分けてみた
    fumikony
    fumikony 2018/08/01
    [aws][sg]
  • Amazon ECS CLI が、Docker Compose バージョン 3 をサポート

    Amazon Elastic Container Service のコマンドラインインターフェイス (Amazon ECS CLI) が、Amazon ECS への Docker コンテナのデプロイで Docker Compose バージョン 3 ファイル形式をサポートするようになりました。 Docker Compose は、複数のコンテナから成るアプリケーションの定義と実行のためのオープンソースの仕様です。Amazon ECS CLI は、Amazon ECS のコマンドラインインターフェイスであり、高度なコントロールを提供して、ローカル開発環境から Amazon ECS によって管理されるインフラストラクチャとアプリケーションを簡単に作成、更新、監視できるようにします。以前は、Amazon ECS CLI では Docker Compose v3 形式のファイルを使用できなかったので、

    Amazon ECS CLI が、Docker Compose バージョン 3 をサポート
  • Compose を 本番環境(production) で使う — Docker-docs-ja 24.0 ドキュメント

    開発環境で Compose を使ってアプリケーションを定義しておけば、その設定を使い、アプリケーションを CI 、ステージング、番環境のように異なる環境で実行できます。 アプリケーションをデプロイする最も簡単な方法は、単一サーバ上での実行です。これは開発環境で実行する方法と似ています。アプリケーションをスケールアップしたい場合には、Compose アプリを Swarm クラスタ上で実行できます。 Compose ファイルを番環境向けに書き換え¶ アプリケーションの設定を番環境に適用するには、おそらく書き換えが必要でしょう。以下のような変更が必要になるかもしれません: アプリケーションのコードに 結び付けている(bind) ボリュームを削除する。そのため、コードはコンテナ内に残り続けるため、外から変更できなくなる。 ホスト上では異なるポートに割り当てる コンテナのコードを外から変更でき

  • Mac(OS X)ではcronじゃなくてlaunchdでやる - Furudateのブログ

    こんにちは。 前にcrontabの書き方についてこちらの記事に書きましたが、Macの場合はlaunchdを使ったほうが良いみたいです。 今回はlaunchdについて書きたいと思います。 launchdとは? launchdはデーモン、アプリケーション、プロセス、スクリプトの起動・停止・管理を行う、オープンソースのサービス管理フレームワークです。(Wikipediaより) まぁ簡単に言えばUnix系のinitcrondの代わりをしてくれるものだと思います。 OS起動時に起動するものともいえると思います。 今回はこれをcronの代わりに使いたいと思います。 launchdのファイル構成 launchdの設定は、以下のディレクトリにlaunchd.plistを置き行います。 ~/Library/LaunchAgents 各ユーザが管理するユーザごとに実行するエージェントを設定する /Libra

    Mac(OS X)ではcronじゃなくてlaunchdでやる - Furudateのブログ
  • launchd/launchctl に困った時 - ばかもりだし

    launchctl で上手く動いてくれないなあ、に困った時、とりあえずやってみると良かったと思ったこと。 Launch Button -- SMASH Rocket Club 5-9-09 4 / stevendepolo kick する実行ファイルに、実行権限があるか、を確認する。 → 大概の問題はここ。 plist、StandardOutPath と StandardErrorPath key を挿し込んでみる。 →何やってるか、どこで躓いてるか、を覗くことができる。 launchctl のサブコマンド start を使う。 →好きなタイミングでテストできる。 まずは、こんなトコかなと。 3 つめは、そんなにアレですかね。...かもしれません。う、 背景 前々から何となく気になっていた radiko の録音周り。 とあるキッカケをもって腹を決め、改めて手を入れることに。それはもう、結構

    launchd/launchctl に困った時 - ばかもりだし
  • launchdで定期的にスクリプトを実行 - Qiita

    定期的にスクリプトを実行する場合、Mac OS Xではcrontabよりlaunchdを使うことが推奨されている。 launchdを用いてMac OS Xで定期的にスクリプトを実行する方法を記述。 特徴 設定が2種類ある: エージェントはユーザーがログイン中に実行できるプログラム。 デーモンはシステム共通で、誰もログインしていなくても実行できるプログラム。 前回の実行が終わらないと次の実行は始まらない。また、スリープ状態、シャットダウン状態では実行されない。1 標準でCPU時間、メモリ、ファイル等の使用の制限2が設けられている。必要に応じて設定ファイルで上限を上げないと、シグナルで届いてしまう。 設定ファイルを置く場所は次の通り。 場所 用途

    launchdで定期的にスクリプトを実行 - Qiita
  • エンジニアマネジメントの重要性を及川卓也氏が語る「リーダー不在のエンジニアチームは守りに入る」 | COMPASS by Globis Capital Partners

    経済産業省は2016年、「IT需要が拡大する一方で、国内の人材供給力が低下し、IT人材不足は今後より一層深刻化する可能性があります」とホームページ上で発表している。発表から2年以上が経過した現在も、採用担当者から「エンジニアの採用が喫緊の課題です」と聞くことが増えた。 また、エンジニアには“エンジニア独自の文化”があるとも言われており、仮に採用することができても、文化を理解しなければ円滑なマネジメントは難しい。特に人材不足が嘆かれる急成長中のスタートアップにとって、エンジニアの採用とマネジメントは成長を加速するための最重要課題といっても良いだろう。 そうした状況を受け、グロービス・キャピタル・パートナーズ(以下、GCP)では、投資先の企業に向けた「エンジニアの採用とマネジメント支援」を行っている。マネジメント支援を担当するのは、GCPが顧問契約を締結する及川卓也氏だ。 及川氏はマイクロソフ

    エンジニアマネジメントの重要性を及川卓也氏が語る「リーダー不在のエンジニアチームは守りに入る」 | COMPASS by Globis Capital Partners
  • 認証とアイデンティティの今 | SendGridブログ

    この記事は Modern Authentication and Identity: Where Are We Today? の抄訳です。 アプリケーションの認証といえば、多くの人はユーザ名(またはメールアドレス)とパスワードを入力する、例の「ログイン画面」を思い浮かべるでしょう。この方法はあまりにも多くのアプリケーションで利用されているため、「今さら認証について話すことなんてあるのか」と思われるかもしれませんが、認証について当に理解されているのでしょうか?もっと良い認証方法はないのでしょうか?そして、私たちが信頼を寄せるユーザ名とパスワード無しでは認証ができないのでしょうか?今どきの認証とアイデンティティの世界には、普段よく目にするものよりも優れた方法があります。今回は、「認証とアイデンティティの今」を見ていきます。 ユーザ名/パスワード方式をはるかに超える今どきの認証 ユーザ名/パスワ

    認証とアイデンティティの今 | SendGridブログ