コンニチハ、千葉です。 AWSのサービスを組み合わせれば、独自の認証基盤を構築できます。例えば、WordPressを限定的に公開する、Apache、 Nginx、カスタムWebアプリなどなど、簡単に認証をかけたい場合、ベーシック認証は昔から利用されてきました。ただし、これはスケーラビリティや運用面でどうしてもつらい場面がでてきます。 そこで、ALBに素敵すぎる組み込みの認証機能が追加されたのでこちらを利用し、コードを一切書かずに認証を導入します。また、OIDCなど認証プロトコルに対応していますが、今回はシンプルにCognitoのユーザープールを利用し、ユーザー管理自体もCognitoに任せます。 要件 今回の想定する要件です。 Nginxを社内ユーザーのみに公開 スタンドアローンのユーザープールを用意(AD、OICD、SAMLなどによる連携なしで、独自でユーザーを管理) ユーザーは管理者が

こんにちは、アプリケーションエンジニアの id:itchyny です。 6/23 (土) にGMOペパボ株式会社さんと共同で開催した技術イベント『はてな・ペパボ技術大会 #4 〜DevOps〜 @京都』のレポートをお届けします。 hatena.connpass.com 発表 弊社のid:hitode909よりCTO室の取り組みの一つとして、開発効率を上げるツールの開発について紹介していただきました。 開発を補助するためのツールを組織横断で導入してもらう手段として、各プロダクトのコードとは疎結合にツールを作ることが大事であるというお話でした。 確かにJenkinsfileにコピペするだけといっても、動かなくなったときに取られる工数を危惧したりツールを導入することの障壁を感じてしまうかもしれませんね。 blog.sushi.money ペパボのid:pyamaxさんより、DevOps化を推し進

2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベル Dockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。 Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で

ECSのインスタンスを入れ替える際にやることは 新しいAMIを作成する launch configurationを新しいAMIで入れ替える desired count増やして新しいインスタンスがecs clusterに入るまで待つ 入れ替え対象をdrainingしてタスクが0になるまで待つ desired countを戻してterminate を繰り返すを手動でやってました。そんなに頻繁に入れ替えないから後回しにしてましたが、時間ができたのでcloudformationを使って自動化してみました。 参考にしたのは下記awsブログの内容です。 前提 terraform cloudformation lambda https://github.com/aws/chalice sns ecs ec2 autoscaling の知識はあるものとして扱います。 概要 Auto Scaling Lif

テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。 2018年6月27日（水）に、電気通信大学の西 康晴さん（以下「にしさん」と表記）をお招きして、「

こんにちは、菊池です。 小ネタですがクロスアカウント環境でS3 syncを実行する際の権限設定を紹介します。 はじめに S3 sync コマンドではローカル環境とS3バケット、または異なる2つのS3バケットでオブジュエクトを同期することができます。 AWS CLIの場合には以下のようなコマンドで実行が可能です。 aws s3 sync {同期元のローカルパスまたは S3 URI} {同期先のローカルパスまたは S3 URI} このS3 syncですが、異なる2つのAWSアカウント（クロスアカウント）のS3 バケット間で同期する際にはアクセス権限の設定に少し手間がありましたのでご紹介します。 クロスアカウントでの S3 sync 例えば以下の図のように、アカウントAのS3バケットからアカウントBのS3バケットにsyncする場合を考えます。コマンドを実行するEC2にはIAM Roleを割り当て

2016/06/15に、トレジャーデータがオープンソースとして公開したワークフローエンジンDigdagのリンク集です。内容は随時更新します。またトレジャーデータではDigdagを自社でTreasure Workflowとして提供しています。こちらの情報も収集しています。 変更内容が気になる方は変更履歴をご覧ください。 1. 開催されるイベント 2. オフィシャルページ オフィシャルページ ソースリポジトリ 3. チュートリアル Getting started (英語) Treasure Data社のOSSワークフローエンジン『Digdag』を試してみた #digdag (日本語) Digdag 入門 Digdagのアーキテクチャとコンセプトを理解する Treasure Workflow for ビギナー 環境構築編 digファイル書き方編 Digdag公式ドキュメントからDigdagを学ぶ

AWS アカウントが分かれている (クロスアカウント) 環境で、S3 バケットを共有したいときってありますよね。 本番環境と開発環境で AWS アカウントが分かれている 自社のサービスを AWS 環境で提供していて、ユーザの AWS アカウントの S3 バケットを利用する などなど、企業内/企業間を問わず、利用する機会は少なくないように思います。しかしながら、「どうやって使うの？」とお悩みの方も同じように少なくないのではないでしょうか？私もついこの間まで、そう思っていた側の人です。今回、別アカウントの S3 バケットを使用する機会がありましたので、同じお悩みをお持ちの方に向けて、私が実施した手順についてシェアしたいと思います。 概要 今回の手順で最終的に出来上がる環境は、以下のとおりです。 アカウントA（アカウントID:111111111111） S3 バケットを所有しているアカウントです

概要 CloudFrontのバックエンドのElasticBeanstalkに構築したNginxを使い、そのNginxからproxy_passでprivateなS3を利用したときに、アクセス制御でハマったのでその解決方法について共有 構成 CloudFront -> ElasitcBeanstalk(nginx) -> S3(private) 詳細 S3がprivateなのでアクセスするには設定が必要で、以下の2つの方法を検討した。 VPC Endpointを使用 IAMでのアクセス制御 1の方法は今回利用したいアプリケーション以外にも同じVPCに属するインスタンスからのアクセスも許可してしまうデメリットがある。今回のケースではReadOnlyなアクセスなので、それでも副作用は特にないのだが、2の方がより適切なアクセス制御ができるので2を採用した。 nginx+luaでproxy_passす

※本ページはプロモーションが含まれています 作成:2014/10/15 スマートフォン用ブラウザのSafariなどには、アドレスバーに直接URLを入力すると自動的に「www」を付けてしまうブラウザがあります。 例えば、このブログのURL keikenchi.com と入力すると www.keikenchi.com にアクセスしてしまうのです。僕のブログでは「www」付きのアクセスの設定をしていなかったので、エラーが表示されていました。 ユーザビリティやアクセスアップのためにURL周りの間口はしっかりしておいたほうが良いので、Nginxで「www」がある場合、無い場合でもアクセスできるようにする方法を紹介します。 サブドメインの設定 まず、ドメイン管理会社のホームページで「www」付きでのアクセスをできるようにする。 ムームードメインの場合は「ムームードメインでサブドメインを設定する方法」の

nginxのデフォルトの動作ではクライアントから受け取ったリクエストボディをメモリにバッファリングするようになっています。 このメモリバッファのサイズはclient_body_buffer_sizeで変更することができ、リクエストボディのサイズがこのバッファのサイズを越えた場合はclient_body_temp_pathにファイルとして書き出されます。 ログレベルがwarn以上の場合はエラーログにa client request body is buffered ...という警告が出ます。 2015/03/29 14:02:20 [warn] 6965#0: *1 a client request body is buffered to a temporary file /etc/nginx/client_body_temp/0000000001, client: x.x.x.x, ser

前回に続いてまたAuroraです、Aurora。高い可用性なのはわかっていますが、じゃあ具体的にどのくらいやねん、となると良い情報がなかったので調べることにしました。 Auroraの公式情報は、一定以上の知識を前提とした内容になっていて、良いバランスで心地よい感じなのですが、まだ読んでて楽しいコンテンツが欠けている印象です。一般情報も、出ました、使ってみました、とかしか無くて寂しいので、ブルーオーシャンを泳いでいくとしましょう。 AuroraのEndpoint 公式読めばいい所なので軽く復習ですが、現在のAuroraのEndpointは３種類あります。 Cluster Endpoint … 常にWriterを指すFQDN。参照更新の両用 Reader Endpoint … ランダムでReaderを返すFQDN。参照用 (Instance) Endpoint … インスタンス毎に割り当てられ

JVM (Java 仮想マシン) には DNS の名前解決の結果をキャッシュする挙動が備わっている。キャッシュするだけならいいのだけれど、このキャッシュでは DNS の TTL を無視してキャッシュするため、名前解決の結果が変わっても JVM からの接続先が切り替わるまでに（TTL から想定される時間以上に）時間がかかる、あるいは全く切り替わらないということがある。この挙動やその制御について調べたので、その話をする。 （以下の話題では Oracle JDK および OpenJDK を対象にして論じるので、それ以外の JVM 実装でどうなってるかは調べていない。適用できる箇所もあればそうでない箇所もありそう） 背景・解説 これらのデフォルト値は名前解決成功時は セキュリティーマネージャーがインストールされている場合のデフォルト値は -1 (ずっと) で、セキュリティーマネージャーがインストー

Java プログラムでホスト名の名前解決ができなくなる原因。JVM の DNS キャッシュの仕組みと、キャッシュの有効期間を変更する方法Java JVM は ホスト名を解決すると IP アドレスをキャッシュします。 発生する問題 あるサーバのホスト名が変化しなくても、IP アドレスが変わると、 Java のプログラムからそのサーバにアクセスできなくなることがあります。 具体的には、 AWS の ELB はホスト名が変わらずに IP アドレスだけ勝手に変化することがあるので、そのような場合に、名前解決に失敗します。 もちろんサーバ側の管理者が DNS の A レコードを変更したときにも発生するので、 AWS のみならず一般的に起き得ます。 どのようにキャッシュしている？ キャッシュを保持してある場所 InetAddress クラスがキャッシュを保持しています。 キャッシュが存在する限り、名前

I want to configure an Amazon Elastic Compute Cloud (Amazon EC2) instance with static DNS server entries that persists during reboot. Short description By default, Amazon EC2 instances associated with an Amazon Virtual Private Cloud (Amazon VPC) request a DNS server address at startup. This request is sent using the Dynamic Host Configuration Protocol (DHCP). The DHCP response returns DNS server a