はてなブックマーク

概要 先月、Google Cloud Platformに新サービスのCloud Runがリリースされましたね! そんなわけで、早速Cloud RunにFlaskアプリケーションを乗せて動かしてみようと思います。 Cloud Runとは GCPの管理下の環境に、コンテナを乗せて動かすことができるサーバーレス環境です。 AWSのFargateと似たような立ち位置っぽいです。 今までは、GKEはロードバランサーやサーバーなどのリソースは契約者側で管理する必要がありますが、これらの管理をGCPに任せる（フルマネージド）ことが出来るんですね。すごい。 GKEとGAEの良いとこどりをしたイメージな感じがします。 ちなみにCloud Run on GKEというのもあり、Cloud RunとGKEを組み合わせて使うこともできるみたいです。 複数のサービスを連携させるとなるとこちらの方が良いのでしょうか。後

こんにちは。@canon1kyです。 AWS Advent Calendar 2019 20日目を担当させていただきます。 はじめに 皆さんはRDSのインスタンスを立てた際、下記の情報はどこで管理していますか？ DBホスト名 DBユーザー名 DBパスワード などなど。 Laravelなど、Webフレームワークなどを使ったアプリケーションでこのような情報を使用するとき、DBパスワードなど機密情報の扱いに困る方は多いのではないでしょうか。 アプリケーションコード内に直接記述する？ .envファイルに環境変数として書いておく？ プラットフォーム側で外部から環境変数として注入する？ 様々な管理方法があるかと思います。 しかし、DBパスワードは秘匿情報であるため、gitに載せるなどのことはなるべく避けたいですよね。 今回は、業務でTerraformを使う中で知見として得た、「gitやドキュメントなど

「このアプリバージョンではこのAPIサーバーにアクセスさせる」というロジックを実現します。 上記の表の場合だと、バージョン0.0.1と0.0.2のアプリではhttps://api.xxx.jp、バージョン0.0.3のアプリではhttps://api.vrf.xxx.jpのAPI URLがゲーム内で使われます。 この仕組みがある理由は下記の通りです。 ストアに申請を出すアプリのAPIは本番環境でなければならない → アプリ内にAPIサーバーの向き先としてhttps://api.xxx.jpが設定されている → ストアに申請を出すタイミングでサーバー側のソースに更新をかけたい場合、ユーザーが触っている本番環境（https://api.xxx.jpのサーバー）に更新をかけるとアプリをアップデートするまで動かなくなるので、更新をかけられない → 申請時にはリリースするアプリの向き先を一時的に、リリ

概要 EKSで使用するワーカーノードのプロビジョニングおよび管理を、EKSのサポートとして対応されたことが2019年11月18日にAWSから発表されました。 つまり、自前でEC2を管理する必要がなくなります。これは超待望。 https://aws.amazon.com/jp/about-aws/whats-new/2019/11/amazon-eks-adds-support-for-provisioning-and-managing-kubernetes-worker-nodes/ 従来のワーカーノードの管理方法 ワーカーノード用EC2のプロビジョニングはオートスケーリンググループを用意するなどの方法で行う必要がありました。 つまり、EC2の管理とEKSの管理は別々でした。 さらに、オートスケーリンググループを使った場合は下記の設定をする必要がありました。 クラスターオートスケール用の設

やりたいこと 下記画像のように、1つのセキュリティグループに対して2つ以上のルールを設定する。 これをTerraformでやりたい。 例えば、Webサーバー用のセキュリティグループを作成し、80番ポートと443番ポートへのインバウンドを設定するなどといったことである。 Terraform実装 aws_security_groupを書く まずは1つのセキュリティグループに対し、80番ポートへのインバウンドルールを追加してみよう。 下記のように、 aws_security_group の中に ingress を指定することで、セキュリティグループとインバウンドルールを作成できる。 # web_serverというセキュリティグループを作成し、そこに80番ポートのインバウンドルールを追加する resource "aws_security_group" "web_server_sg" { name