GCP 公開の Terraform modules から module による効果的な抽象化を学ぶ - chroju.dev
Terraform はずっとほぼ AWS でしか使っていなくて、最近 GCP で使い始めたところ結構使い勝手が違って驚いている。その中でも公式提供されている Terraform modules がかなり良くて、 GCP 使わない人でも参考になるので紹介してみる。 Terraform modules for Google Cloud https://github.com/terraform-google-modules 上記 GitHub Organization にて、現時点で 64 の module が公開されている。 Organization のメンバーを見ると GCP に属している方が多いので、どうも Google 公認で提供されているものらしい。 AWS にも Terraform AWS modules という Organization があるが、こちらは見る限り AWS 関係者で
SRE になって3か月目に考える、 SRE とは何か、如何に実践すべきか - chroju.dev
パラレルワーカー兼大学生になることになった · the world as code というエントリーで SRE の立場でやっていくということを書いて、実際働き始めて3か月近くが経過した。インフラ系の運用専門のエンジニアから SRE という立場に変わって実際のところ何が変わったのか、今後何をするべきなのかということを、ここで改めてまとめておきたい。 改めて SRE を定義する SRE の職種で転職活動をしていたとき、カジュアル面接で「SREとはなんだと思うか？」と聞かれたことがあった。そのときには「ソフトウェアエンジニアリングを用いてシステム運用を行うこと」と応えているが、今から考えると「半分正解」ぐらいの応えだったように思っている。 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームposted with amazlet at 19.09.
Terraform で疲れないために - chroju.dev
追記（2019-02-27） : 一部表現等見直しました。論旨は変わっていないです。 Infrastructure-as-Code-is-very-tired - Speaker Deck こちらの記事を読みました。スライド内で触れられている Terraform Best Practices in 2017 - Qiita については私も読んだことがあり、以下の記事で言及させてもらっていたり。悩みますよね、 Terraform 運用。 Terraform moduleは何が嬉しいのか · the world as code 私もある程度ポリシーめいたものをもって、これはコード化するべき、これは手で作ってもいい、みたいな線を引いてはいるものの、あまりそれを言語化してみたことがなかったので、いい機会だしまとめてみます。疲れないようにするべき、コード化がすべてではない、という視点は先のスライドと
Terraform moduleは何が嬉しいのか - chroju.dev
Terraformの「module」を最近使うようになった。moduleは複数のクラウドリソースをまとめてテンプレート化して、呼び出すときに必要な引数だけ与えてあげれば発動可能になるというもので、要するにリソースの抽象化に使われる。Ansibleで言うところのRoleに近い。 Terraform自体は1年ぐらい前から使っていたので、結構長いことmoduleには触れていなかったんだけど、理由としては結構複雑化しそうというのがあった。今回改めて触れてみて、メリットは確かに感じられるがやっぱり複雑だなという気持ちが強くて、一旦まとめてみる。 宣言地獄 moduleはクラウドリソースの枠を作り、各種設定値は変数として空けておいて、呼び出されるときに変数を埋めてもらう、という形を取るので、変数宣言をそこここに書くことになる。これがあまりDRYではないというか、何度も同じものを書く必要があったりする。
Terraformドキュメントをコマンドで見るツールをGoで作る - chroju.dev
クラウドサービスのリソース管理をコード化できるTerraform、とても便利に使っているけれど、リソースの種類によって当然ながら書くべき内容が異なりなかなかスムーズに書くことができない。 Provider: AWS - Terraform by HashiCorp 例えば自分がよく使うAWSだけでも、このリンク先に書かれているだけのリソースの種類、書き方がある。そして機能やサービスが増えるごとに、リソースの書き方もどんどん多様化していく。今はこれをいちいちウェブ上で書き方を確認しながらTerraformを書いているんだけど、ちょっと手間が多いなという気がしてきた。 同様にInfrastructure as CodeのツールであるAnsibleには、ansible-docというコマンドがあって、ドキュメントをコマンドライン上で見ることができるようになっている。 $ ansible-doc f
CoreOSからECSへDockerを移行した · the world as code
CoreOS（現状Container Linuxですけど、キャッチーじゃないのであえて）上でプライベートのDockerコンテナを動かしていたのですが、それをAmazon ECS上へ移行した話です。 従来の環境 従来は以下のような環境を使っていました。 さくらクラウドでCoreOSを起動（イメージがデフォルトで用意されていて嬉しい） コンテナは個人的なログ用influxDB、Grafana、個人slack用hubotの3つ。 オーケストレーションツールは使っていない（docker composeで管理、systemdで自動起動） それ以外に運用っぽいことも特にしてない。 プライベートかつ、とりあえずDocker触って動かしたいという理由だけで作った環境だったので、正直扱いは雑でして、たまにコンテナ落ちてて、hubotに呼びかけてから気付くみたいなこともままありました。 それが地味にストレスだ
O'Reilly『Infrastructure as Code』読了 - chroju.dev
O'Reillyの『Infrastructure as Code』を読んだ。従来Ansibleの本、Chefの本といった各ツールの使い方にフォーカスした本はいくらか出ていたけれど、おそらく「Infrastructure as Code」の考え方や、システム運用への採用方法を包括してまとめた本は初めてということになるのかな。 ツールとプロセス 端的に内容を説明してしまうと、Infrastructure as Codeで使用するツールを ダイナミックインフラストラクチャプラットフォーム（AWS等パブリック、プライベート問わずプログラマブルな操作が可能なインフラプラットフォーム） インフラストラクチャ定義ツール（Terraformのような、構築するインフラ環境を定義するツール） サーバー構成ツール（Ansible、Chef等のサーバー内部の設定を定義するツール） インフラストラクチャサービス（モ
エンジニアの問題解決力とは何か - chroju.dev
今年度、特に下半期からいわゆる技術的負債の返済、特にDevOps方面におけるプロセス改善に深く携わるようになった。これまで依頼ベースの対応や、プロジェクトベースの仕事をすることが多く、要は「何をやるか」がある程度決まっていたわけだけど、改善系の業務は問題を見つけ、解決策、しかも場当たり的なものではなくてボトルネックを閉めるような策を講じていく必要があるということで、これまでと違う視点で仕事をする必要が出てきた。そこで何冊か「問題解決」にフォーカスした本を読んだ結果をまとめてみる。 問題とはなにか そもそも「問題」って何なのか。細谷功『問題解決のジレンマ』によれば、問題とは「事実と解釈の乖離」だという。 問題解決のジレンマ: イグノランスマネジメント:無知の力posted with amazlet at 16.12.17細谷 功 東洋経済新報社 売り上げランキング: 112,865 Amaz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
