はてなブックマーク

こんにちは、ちゃりおです。 「The CDK Book」読んでみました。 CDKは比較的新しいIaCツールのため、実践的な内容については他のツールに比べてノウハウが少ない印象でした。 本書では、CDKの使い方だけではなく、Configの管理やデプロイ戦略、テストなど業務で使う際に役立つ情報が盛り込まれています。 CDK WorkShopをやった後のステップアップに最適な一冊かと思います。 目次 1. What is the Cloud Development Kit? 2. What Are Constructs 3. Publishing Constructs 4. Leveraging your Integrated Development Environment 5. Project Layout 6. Custome Resources and CFN Providers 7. C

こんにちは、ちゃりおです。 ECSのデプロイ時のPullはNATGWを通すと通信量が高額になることがあると思います。 VPCエンドポイントを使うことで料金を節約できます。 CDKでECS用のVPCエンドポイント作ってみました。 インターフェースVPCエンドポイントとは まずは、インターフェースVPCエンドポイントの概要についてです。 VPCエンドポイント概要 VPCエンドポイントは、インターネットやNATGWを経由せずにAWSのサービスにアクセスできるサービスです。 例えば、プライベートサブネットにあるECSの場合、ECRからイメージをPullする際はNATGWを経由してインターネットに行きます。 VPCエンドポイントを使えばNATGWを経由せずにVPCエンドポイントを経由してECRにアクセスできます。 AWS PrivateLink は、データをインターネットに公開することなく、AWS

こんにちは、ちゃりおです。 みなさんは、踏み台サーバの鍵の管理どうしてますか。 ユーザごとにアカウント作ったり、秘密鍵を共有していたり、ssmで鍵を使わなかったり色々あると思います。 踏み台サーバでの鍵の管理について考えてみたので書いてみます。 思いつく限り鍵管理の方法を書いてみます。 手間とセキュリティの観点から、比較してみます。 踏み台サーバの秘密鍵を共有する 一つのユーザにそれぞれのユーザの公開鍵を追加する ユーザごとにアカウント作る ssmを使う(aws環境だったら) 1.踏み台サーバの秘密鍵を共有する 踏み台サーバの秘密鍵をユーザ全員で共有する方法です。 これは楽ではあるんですが、一番避けたい方法です。 鍵の流出のリスクが高いし、だれがアクセスできるのかわからなくなりがちです。 しかも、もし退職したとしても秘密鍵を持ち逃げしたら不正にアクセスされる可能性があります。 2.一つのユ

こんにちは、ちゃりおです。 サービスの外形監視いれていますか。 可用性のモニタリングやエンドポイント監視に外形監視サービスが便利です。 AWSで動いているサービス向けに、今回は外形監視サービスを比較してみます。 監視に関わる人は一度は読みたい「入門 監視」こんにちは、ちゃりおです。 半分ほど、読んで積読していたのですがやっと読み終わりました。 印象的だったところを、紹介します。 ... 比較対象の要件 今回3つのサービスをピックアップして比較しました。 Cloudwatch Synthetics NewRelic Synthetics Datadog Synthetics 各サービスが満たしている要件は以下です。 1分間隔のモニタリングが可能 可用性を%で表示できる ツールの拡張性・シェア 外形監視以外の監視もしたくなったときに 比較した項目 以下項目を比較しました。 監視できる項目 レス

こんにちは、ちゃりおです。 AWS 認定デベロッパー – アソシエイトの勉強法についてまとめてみます。 私は、普段インフラを主にやっており、業務でアプリケーション開発の経験がありません。 (個人レベルではありますが、浅いものです) 同じようにAWS認定3冠したいけど、アプリケーション詳しくない人の参考になればと思います。 対象 AWS 認定デベロッパー – アソシエイトの勉強法・概要を知りたい人 開発経験は少ないけど、AWS 認定デベロッパー – アソシエイト取りたい人 ネットで「デベロッパー アソシエイト簡単」とか見かけたけど、試験問題みたら「全然簡単じゃないよ」って人 AWS 認定デベロッパー – アソシエイトとは 概要 AWS 認定デベロッパー試験は、AWS ベースのアプリケーションの開発や保守における 1 年以上の実務経験がある開発担当者を対象としています。 この試験で評価する能力

Cloudformationのベストプラクティスに テンプレートを再利用して複数の環境にスタックを複製する というのがあります。 やり方わからなかったため、調べてみました。 今回は、「テンプレートを再利用する方法」をまとめてみます。 なぜ再利用できるようにしたいのか クロススタック参照でテンプレートを分けていると、テンプレートファイルはどうしても複数になってしまいます。 さらに、検証と本番でテンプレートファイルを分けてしまうとテンプレートファイルの数が倍になってしまいます。 テンプレートファイルの数が増えると、ファイルの管理が複雑になりミスが発生するかもしれません。 だからといって、本番と検証を同じテンプレートファイルにするとどちら片方削除したい・変更したい時に不便です。 そういった理由から、テンプレートは再利用できる形にするのがおすすめです。 再利用できないテンプレート まずは、再利用で

複数のユーザを作成して、それぞれ公開鍵を配置したい時がたまにあります。 sshして公開鍵を置くのは、面倒です。１台とかだったらいいかもしれませんが、１０台・２０台とかだとミスが怖いです。 今回はその作業を、Ansibleで自動化して楽に配布します。 今回のゴール hostsサーバからSlaveサーバのそれぞれのユーザに、公開鍵認証で接続できるようにします。 環境構築 Vagrant上にをサーバを２台立てます。 AnsibleはVagrantのサーバ(host)にインストールします。 Vagrant上でAnsibleの環境構築する方法はこちら 事前準備 公開鍵をフォルダに置いておく。 Ansibleを実行するユーザでアクセス可能であること それぞれのユーザの「.ssh」ディレクトリから公開鍵を指定できればいいのですが、rootでansibleを実行する必要がありそうでした。 今回は、vagr