こんにちは。 Mackerel SRE チームの id:heleeen です 先日、Terraform Registry に Mackerel 用の Terraform Provider を公開しました。 これによって Terraform で監視設定など各種設定を管理することができます。 mackerelio-labs/mackerel | Terraform Registry Terraform Provider Mackerel 公開にあたって Mackerel の Terraform Provider はこれまで公式に公開していなかったのですが、以前から作成、公開されていた @xcezx さん、 @kjm さんにご協力いただき公開することができました。 公開にあたりご対応いただきました @xcezx さん、 @kjm さんにはこの場で改めて感謝を申し上げます。 mackereilo-
TerraformのVersion 0.15がGAになって(2021/04/15)からだいぶ経ってしまいましたが、Webinarを視聴したり、実際に0.15を触ったりして何が変わったのか色々調べたのでレポートします。 (すべての変更点を網羅しているわけではないので悪しからず。) 0.14、1.0との互換性 Terraform Version 0.15は１つ前の0.14、そして今後リリースされる Version1.0と互換性があります。これはVersion 0.14の紹介でも説明されていましたね。Version間の移行（多くの場合Versionアップだと思いますが）が容易になります。 Remote State Data SourceのVersion間互換 ~> 0.15.0 ~> 0.14.0 ~> 0.13.6 ~> 0.12.30 上記Versionに当てはまるTerraformは、互い
※1 以下資料を参照（2020年12月4日現在） Cloud modules -- Ansible Documentation ※2 OS・ミドルウェア層の構成管理にはPythonの実行環境が必要 特に大きな違いになるのが、赤い線で囲っている「インフラ層の構成管理」と「OS・ミドルウェア層の構成管理」です。これらの機能が、両製品を組み合わせて使い分けるポイントです。具体的にどのような点が異なるのか説明していきます。 IaCモデルの違い IaCツールとして、Terraformは宣言モデル、Ansibleは命令実行モデルを採用しています。宣言モデルはインフラのあるべき状態をコードで表現します。対して、命令実行モデルはリソースを作成する手順をコードで表現します。では、実際にクラウドをIaCで管理する場合に、宣言モデルと命令実行モデルでどのような違いがでてくるのでしょうか？ 例えば、AWSにEC2
ミクシィでの仕事も気づいたら8年目を迎えていました。キャンプとクラフトビールが大好きです。普段はSREをやっている清水と申します。本記事は、ミクシィグループ Advent Calendar 2018 23日目の記事です。 私は、2018年2月から「家族アルバム みてね」というサービスでSREを担当しています。それまでは、約3年ほど「モンスターストライク」のSREを担当していましたが、みてねのSREに変わったことで本当に大きな変化がありました。SREというロール自体は変わりませんが、サービスの性質、規模、組織、インフラ、アーキテクチャ、トラフィックのパターンなどにおいて大きな違いがありました。それぞれの特性を理解、把握し、日々多くの課題解決に取り組んでいます。 9月のMeetupでは「みてねSREチームの取り組み」と、約半年間みてねのSREとしてやってきたことを発表しました。また、10月のA
LambdaをTerraformで管理してた辛みをApexに乗り換えて解決した〜Datadog Logsの例を添えて〜 大島 雅人 背景: LambdaのソースコードをTerraformで管理するのが辛くなってきた これまでAWS Lambdaのソースコードは、Terraformのarchive_fileを使ってzip化してS3にuploadする、という方式で管理していました。はじめのうちはこれで問題なかったのですが、Lambdaのソースコードに差分は無いのに、zipとしてはなぜか差分が発生しており、terraform applyするたびに差分が発生して辛いといったことが起きるようになってきました。 Terraformで管理してLambdaが実行されるまでを図で説明すると下図のようになります。 ローカル環境でLambdaのコードをS3にuploadするためにTerraformでzip化する
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
Open sourcing Terratest: a swiss army knife for testing infrastructure code Tools to test Terraform, Packer, Docker, AWS, and much moreInfrastructure as code (IaC) tools such as Terraform, Packer, and Docker offer a number of advantages: you can automate your entire provisioning and deployment process, you can store the state of your infrastructure in code (instead of a sysadmin’s head), you can u
Terraform職人の @minamijoyo です。 クラウドワークスではAWSのインフラ構成管理にHashiCorpの Terraform を利用しており、 日々Terraformの設定ファイルを書いてるわけですが、 コード書いてると、リソースタイプの名前がうろ覚えとか、属性値の名前のスペルに自信がないとか、この属性値って必須項目だっけ？ とか、なんだかんだで公式ドキュメントを見ながらコードを書いてることが多いです。 Vimのプラグインで補完してくれるやつがあるのは知ってるんだけど、 あらかじめリストファイルを持っているアプローチだと、バージョンに合わせてリストファイルの更新しないといけなくて、仕組み上の限界があるし、サポートされてない自作プロバイダとかだとそもそも使えない。 なんかもっといいかんじにできないかなぁと思って、趣味でTerraformのソースコードを読んでたら、最近入っ
Terraform Recommended Practices 推奨手順 「Terraformって何がいいんですか？」と訊かれる度に答えていた内容が、とても良い感じにまとまっていましたので、ここで紹介します。2017年11月28日現在の Terraform Recommended Practices の参考訳です。 自動化や運用に興味がある方にとって参考となるのは、HashiCorp の Terraform に興味が無くても、成熟度に応じた自動化の段階分けと、各々の段階からどのように発展すべきかという手順です。手動→半自動→インフラのコード化（Infrastructure as Code）への進歩と、最終的には協調的インフラのコード化（Collaborative Infrastructure as Code）を目指して、バージョン管理や構成管理ツールと連携するにはどうしたらよいのか。あるい
多くの企業が、今年中にWebサービスの暗号化を進めなくてはいけなくなったかと思います。 Webに接続するiOSアプリは2017年1月からHTTPSの使用が絶対条件になる、デベロッパーはご注意を | TechCrunch Japan ということで、基本的な内容ではありますが、AWSにおけるSSL証明書の扱いについて復習してみます。 AWSで扱う証明書の種類 ここでいう種類とは、EV SSL だの ワイルドカードだの、証明書の製品としての種類ではありません。 １つは AWS Certificate Manager（以下、ACM）の無償証明書、もう１つは従来のSSLサーバ証明書販売サイトで購入する有償証明書、の２種類となります。 それぞれの証明書を、AWSのリソースにどのように登録し、運用していくかについてまとめていきます。 ACMの証明書を利用する 2016年1月にリリースされ、5月にはTok
Packer / Terraform による構成管理 Packer による AMI の作成 Terraform でのインスタンス起動時の user-data の利用 Terraform でのサーバの入れ替えの為の設定 / 作業 Auto Scaling グループに対する ELB 付け外しの利用 autoscale.tf elb.tf codedeploy.tf variables.tfvars 実際のオペレーションの手順 1. green の設定変更 / 起動 2. green サーバ群を本番 ELB に設定 3. blue サーバを本番 ELB から切り離す 4. blue の台数を 0 に 実際に運用してみて 課題や今後 まとめ こんにちは、エンジニアの野本です。先日、door 賃貸をオンプレから AWS に移行した際、Terraform & Packer を中心に行ったという話を紹介
こんにちは！エンジニアの岩崎@yuma_iwasakiです。 今、UZOUというネイティブ広告の配信システムを作っています。 配信システムでは多くの種類のサーバーやAWSのサービスを使用するので、 その管理のためにTerraformを導入しました。 今回はTerraformというプロダクトはどういうものなのか、 なぜ導入したかにフォーカスしてみました。 トークテーマ AWSインフラ管理ツールとしてのTerraform キーワード 広告配信システム Terraform infrastructure as code 発表スライド 質疑応答 最終的にTerraformを選んだ決め手は？ 学習コストの低さとコードの読みやすさ。 あとは正直言うとTerraformを使ってみたかったため。 そもそもTerraformのDSLは読みやすいのですか? 読みやすい。 他のエンジニアもわかりやすいと言っている
複数の環境を持ってたり、それを複数人で管理してたりすると 作成したstateのバージョンだったり作業環境の Terraform のバージョンだったりを同じじゃないことってありますよね。 例えばAでは0.6.xしか実行してなかったけど、Bでは0.7.xで運用を開始したり それをMacで運用してるとAを更新する際に、0.7.xで実行することになっちゃって、フォーマットエラー….かなしい なので、ローカルインストールしたバージョンに依存する事なく、A,Bのように環境が違っても、実行者が違っても同じバージョンで運用出来るようになるととても幸せ ※でも、早めにバージョンはあげようよ！！ そんな時に便利なのが、実行環境を Docker コンテナ！！ Docker Hubには、terraform公式のイメージ（ hashicorp/terraform )が存在しています。 これを使うことで、0.6.xで
コンニチーハ、千葉です。 とある理由でVPCからVPCへ移行する機会がありました。セキュリティーグループは、piculet、Route53はroadworkerを利用しました。どちらのツールも、現在の構成をファイルにエクスポートでき、それを元にファイルを修正することで、かなりの工数削減 & 品質向上を行うことができました。 で、EC2はどうしようかなーと悩みましたが、terraformingで現在の構成をエクスポートし、Terraformでプロビジョニングすることにしました!!実践してみたのでブログを書いてみます。 そもそもTerraformとは？は、こちらの記事がとても分かりやすいです！AWSでTerraformに入門 インストール terraformingのインストール terraformingをインストールします。 ruby 2.1以上が必要です。私は、ruby 2.2で試しました。
はじめに こんにちは、中山です。 何番煎じか微妙なところではあるのですが、今回TerraformとCircleCIを連携させてみたので一本エントリを書きます。TerraformのコードをGitHubで管理しておき、プッシュしたらCircleCIでTerraform実行というパターンです。 構成図 今回のエントリには直接関係しないのですが、Terraformで作成されるシステムは以下の通りです。一般的なWebシステムによくある構成にしてみました。 コード GitHubに上げておきました。ご自由にお使いください。 knakayama/terraform-circleci-demo ディレクトリ構造 以下の通りです。 terraform-circleci-demo/ ├── Makefile ├── README.md ├── app.tf ├── bastion.tf ├── circle.y
インフラチームエンジニアの藤田 (@dtan4) です。Terraform でインフラをコードで管理するようになって1年が経ちました。 Wantedly のインフラは AWS + DNSimple 上で稼働していますが、そのリソースの殆どをおよそ1年前から Terraform のコードで管理しています。もちろん1年前の時点で既存のリソースは数多くあったわけですが、それらも Terraform のコードに落としこむため Terraforming という変換ツールを作りました。現在ではインフラ変更の際に GitHub 上で Pull Request によるレビュー + CI 上で自動適用を行う体制が整っております。 以前 Wantedly Advent Calendar '15 で Wantedly での Terraform 運用事情を一通り紹介しましたが (Terraform と CI で実
インフラエンジニアも、そうでないエンジニアも、程度の差こそあれAWS（パブリッククラウド）の知識は欠かせないものになりつつあります。しかしながら、食わず嫌いだけならまだしも、AWSにそこそこ取り組み続けているのに、しばしば嫌気がさすことすらあるのは、AWSの複雑さが原因の１つであるといっていいでしょう。 今回は、そんな複雑な仕組みの一つを、Terraform用にコード化することでココロのスキマ、お埋めします。 Infrastructure as Code の過程 Infrastructure as Code によって、手動管理をやめて自動化することのメリットは言うまでもないですが、今回は自動化する過程にこそ非常に大きなメリットがある、という視点にスポットを当てていきます。 AWSは多機能で便利であるがゆえに、複雑です。そして、複雑であるがゆえに、お客さんに簡単に扱ってもらえるよう、操作が簡
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
