TerraformでAWS WAFに複数（大量）のBlackListIPを登録する - サーバーワークスエンジニアブログ
全国のTerrafrom愛好家のみなさま、こんにちは。 技術4課岩本です。 まず、Terraformを使って、IPリストを登録する方法は以下になります。 CloudFront(Grobal)用の場合 resource "aws_waf_ipset" "ipset" { name = "tfIPSet" ip_set_descriptors { type = "IPV4" value = "192.0.7.0/24" } } 参考：aws_waf_ipset ALB用の場合 resource "aws_wafregional_ipset" "ipset" { name = "tfIPSet" ip_set_descriptor { type = "IPV4" value = "192.0.7.0/24" } } CloudFront(Grobal)の際はip_set_descriptors、
TerraformでAuroraを立てる - nisshieeのブログ
AWS Auroraを構築するにあたり、Terraformでコード化したのでそのメモ。 Auroraは従来のRDS上に構築するRDBから、より「AWS様がよしなにやってくれる」領域が広くなっていて、本当に重要な、構築者が決めなければいけないパラメータは、たったの2つだけとなっている。 クラスタを構築するインスタンス数 各ノードのインスタンスタイプ（AWSを使っていればおなじみの db.t2.small みたいなやつ） この2つのパラメータと、追加でいくつかの環境情報を入力に与えるだけで、まあまあ動くAuroraが立つようなTerraformコードを書いたので、メモしておく。 入力項目 L1-3の項目は各AWS resourceのnameやtagに入れるので、管理しやすい値を L5,6はDBに初期登録するユーザ情報 L8,9はシステム全体のアーキテクチャに合わせて適切なものを（本記事では省略
git pushでサーバを構築する - トレタ開発者ブログ
2018年あけましておめでとうございます。 新年早々ひどい肩こりに悩まされていましたが、最近ようやく回復してきましたインフラの山田です。 去年の振り返り さて、2017年の振り返りになりますが、おかげさまで昨年は99.996%のシステム稼働率を記録することが出来ました。 今年も飲食店様を支えるインフラとして、この稼働率をキープしていきます。 git push起点でインフラをつくる トレタではInfrastructure as Codeに積極的に取り組んでいます。 全てのインフラリソースをコード化出来ているわけではありませんが、 git pushでインフラができあがる の考えのもと仕組みを作っています。 さて、今回はサーバの構築に関して紹介します。 使っているツール 以前のブログでも紹介させて頂いていますが、サーバ周りを運用を回すのには以下のツールを使っています。 Circle CI Pak
Kubernetes活用に至るまで――リクルートテクノロジーズがコンテナを大規模システムの本番環境へ適用した事例
Kubernetes活用に至るまで――リクルートテクノロジーズがコンテナを大規模システムの本番環境へ適用した事例：先行事例に学ぶKubernetes企業活用の現実（2） 本連載では、サービスの開発、提供のアジリティ向上の一助となることを目的として、企業における「Kubernetes」の活用について解説する。今回は、リクルートテクノロジーズにおいて筆者が取り組んだ事例を基に、コンテナ仮想化技術を本番環境で利用する際の取り組み、成果と課題、「なぜ最終的にKubernetesを活用する決断に至ったか」を説明する。 コンテナ仮想化技術を本番環境で利用する際の3つのフェーズ 昨今、コンテナオーケストレーションツール「Kubernetes」に注目が集まっています。本連載「先行事例に学ぶKubernetes企業活用の現実」では、サービスの開発、提供のアジリティー向上の一助となることを目的として、企業にお
Terraform職人入門: 日々の運用で学んだ知見を淡々とまとめる - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2017 の8日目の記事です。 Terraform職人の @minamijoyo です。Infrastructure as Codeしてますか？ インフラのコード管理に Terraform を使い始めて2年ちょっと、本番環境で運用していると日々色んな学びがあるので、Terraformやってみた系の入門記事では語られない、現場の運用ノウハウ的なものを共有してみようかと思います。 Terraformを使い始めた or 使っている人が、こんなときどうするの？っていうときに参考になれば幸いです。 書き始めたら超長文になりました。概要は以下のとおりです。 公式ドキュメントを読もう tfファイルを書く技術 インデントを揃える 組み込み関数に親しむ lifecycleブロックを使う リソースの差分を無視する リソース再生成のとき
Terraform Best Practices in 2017 - Qiita
2019/12/23 更新 本記事はベストプラクティスかもしれないけど複雑だったので、2020年度版（0.12対応版)として Terraform 0.12 のコードを黒魔術にしないために心がけたこと ~ 自分への戒めを込めて ~ を書きました。こちらも参照ください。 Terraform Best Practices in 2017 以下のブログをベースにver0.10の新機能のworkspaceや、backend、remote stateを活用してベストプラクティスを考えた。 細かい話は以下のブログを参照いただき、ver0.10に対応した内容だけ記載します。 Terraformにおけるディレクトリ構造のベストプラクティス ｜ Developers.IO サンプルコード サンプルコードを置きましたので、イメージが付かない場合は以下を見てみて下さい。 （適当に作ったので間違えてたらプルリクくだ
TerraformでAWS環境の構築する時に良く使う書き方 - Qiita
data "aws_ami" "ecs_optimized" { most_recent = true owners = ["amazon"] filter { name = "architecture" values = ["x86_64"] } filter { name = "root-device-type" values = ["ebs"] } filter { name = "name" values = ["amzn-ami-*-amazon-ecs-optimized"] } filter { name = "virtualization-type" values = ["hvm"] } filter { name = "block-device-mapping.volume-type" values = ["gp2"] } } resource "aws_instance
Amazon ECSでRailsアプリケーションを運用するのに行ってること - Qiita
Terraform AWSのインフラ構成はTerraform管理してる. tfstateを分割する tfstateが1つのままだと、Terraformのresourceを増やしていったときに 頻繁に更新するresourceとそうでもないものがある 適応するのに時間が掛かる エラーの切り分けしずらくなる ということからtfstateを分割してる。 ただ分割しすぎると、適応漏れや適応順番が複雑になるので2つに分割してる。 . ├── environments │ ├── immutable │ │ ├── backend.tf │ │ ├── main.tf │ │ ├── provider.tf │ │ └── variable.tf │ └── mutable │ ├── backend.tf │ ├── main.tf │ ├── ou
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
