『情報セキュリティの敗北史』を読んだ - chroju.dev
https://www.hakuyo-sha.co.jp/science/security/ 面白かった。タイトル通り歴史をつづった本であり、純粋な技術書というよりは読み物としての性格が強い。具体的なセキュリティインシデントも当然登場するが、その技術背景が詳しく掘り下げられるわけではない。「SQLインジェクション」「カーネル」など、専門家にとっては基本的な用語にも注釈がついているので、むしろ専門外の方でも広く読めるようにした文芸書に近いのかもしれない。ちょっと違う気はするが、『失敗の本質』情報セキュリティ版、みたいな趣だろうか。 歴史の範囲はENIACの誕生から2020年前後までであり、およそ現代における電子計算機の発展の歴史を概観する形になる。複数ユーザが1つのコンピュータを共有するタイムシェアリングシステムの確立、数多のコンピュータがネットワークで接続されたインターネットの誕生、急速に
Embedded SREとは何か - SREの組織類型についての覚書 - chroju.dev
先日の 6社合同 SRE勉強会 最後のディスカッションの中で、 Embedded SRE のようなSREの組織類型をどこで知ったのか、という話題が出ていた。これは僕も以前から感じていたことだ。SREの組織類型、特に「Embedded SRE」という単語は最近国内のテックブログでも見かけることが多いが、GoogleのSRE本各種などに直接言及があるわけではない。その場では海外のブログなどで、という程度の話にまとまり、厳密な結論には至らなかったし、僕も原典が何かと言われるとよくはわかっていない。 Embedded SREとは何か SREがプロダクトチーム内の職能横断の1つとして配置される体制をEmbedded SREと呼ぶ。これはプロダクトチーム、開発チームの外で中央集権的に組織され、各プロダクトを横断的に見るようなSREの組織体制と対置されている。プロダクトサイドとしては、チーム外にいるSR
CUEでTerraformを書いてみる - chroju.dev
最近 CUE の話題を少しずつだがよく見かけるようになってきた。 CUE を使用した Kubernetes マニフェスト管理 | メルカリエンジニアリング [DevOps プラットフォームの取り組み #4] CUE 言語の紹介 - NTT Communications Engineers' Blog CUE によるスキーマやバリデーションのポータビリティ | gihyo.jp CUE とは何か、レポジトリの README から引用すると以下のように書かれている。 CUE is an open source data constraint language which aims to simplify tasks involving defining and using data. It is a superset of JSON, allowing users familiar with
パスワード管理サービスを Bitwarden でセルフホストする - chroju.dev
パスワード管理と言えば 1Password や Lastpass あたりのクラウドサービスが人気だと思うのだが、どうにも第三者の運営するサービスに機密情報を預けるというのが苦手で、長らくオープンソースのファイル保存型パスワードマネージャーである KeePass を使ってきた。これは保存したパスワードなどはファイルに書き出されて暗号化されるという形を取るので、そのファイルを Dropbox に置くことでマルチデバイスでの同期を図っている（Dropbox に預けるのは OK で 1Password は NG というのは理屈に合わないというのはわかっている）。 そこに来て、最近始めた仕事でかなり BYOD というべきか、会社の PC からでも家の PC から（要するにリモートワーク）でも会社で使っているサービスにログインして仕事をする、というスタイルが求められる場合が増えた。従って会社と家の P
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
