はてなブックマーク

Gitを活用して宣言的にアプリケーションの構成管理をし、それぞれの環境へアプリケーションをデリバリを行うGitOpsスタイルは一定の支持を得て定着しつつあるスタイルになったと言ってよい。それでもGitOpsを実践する上で、議論を避けて通れない点が1つある。それはSecrets（機密情報）の管理にほかならない。 多くの開発者にSecrets管理の重要性は理解されていても、実際に継続的な管理・運用となると Secretsの管理は難しい。今でこそエンジニアの基本的な嗜みとして、各企業での基礎教育やオンボーディングも徐々に成熟しつつあるかもしれないが、それでもシークレットの外部への流出による個人情報の流出や、クラウド破産といった事故は絶えない。 GitOpsで管理するSecrets 宣言的なGitOpsスタイルにおいて、開発者はGitリポジトリを唯一の情報源（Single Source of Tr

この記事はOpenSaaS Studio Advent Calendar 2019の16日目の記事。 Kubernetesクラスタのバックアップ GitOpsとCI/CDの整備により、Kubernetesクラスタにデプロイされているアプリケーションやミドルウェアは、デリバリ用のリポジトリとニアリーイコールにできる運用が一般化した。これだけ見ると、運用やインシデントでKubernetesクラスタを新しく作り直してマイグレーションするということは簡単なように思えるが、実際にはそうでもない。 実際には我々が直接管理しているマニフェストは最も上位層のリソースなので、Deploymentが生成するReplicaSetおよび、ReplicaSetが生成するPodをそのまま別の環境で再現するには、動的に生成されたリソースのマニフェストも含めてバックアップを取る必要がある。他にもBitnamiのSeale

この記事はOpenSaaS Studio Advent Calendar 2019の8日目の記事。 オートスケーリングの現実 KubernetesにはHorizonal Pod Autoscaler(HPA)という便利な仕組みがあって、CPUやメモリ使用率やカスタムメトリクスによってPodの数を増減できる。とはいえPodだけ増えても増えた分のPodを配置できるだけのコンピューティングリソースが無いと意味がない。GKEであればPodを配置できるだけのリソースがなければ、Nodepoolのサイズを拡大してくれる（Quotaの確認も忘れるなよ！）。 しかし、弊社のプロダクトはメディアやゲーム、広告だったり色々あるわけで、そのほとんどがB・C問わず大規模なユーザーを抱えている。オートスケーリングは欠かせない仕組みだが、コンピューティングリソースが上昇してから発火するものなので、基本的に瞬間的なスパ

この記事はOpenSaaS Studio Advent Calendar 2019の4日目の記事。 複雑化したアプリケーションの整合性担保と統率の難しさ Kubernetesベースのアプリケーションを開発・運用において、GitOpsスタイルでCI/CDのパイプラインを組むみたいなことは普通になってきた感がある。とはいえ、いくらyamlファイルがある程度ヒューマンリーダブルなフォーマットであっても、PRのレビューにおいてその妥当性をチェックするというのは難しいし時間を必要とする。 レビュアーはPRのスコープ外の既に適用されているリソースにも気を配る必要があるし、conftestのようなマニフェストの静的解析も有用ではあるが、実際にマニフェストがクラスタに適用されてどのような影響が起こりうるか？みたいなとこまでチェックできる人というのは、Kubernetesに精通していてかつ、そのアプリケーシ

自分は今33歳なので、Webの世界においては完全に老害と言われてもおかしくない世代にさしかかっています。自分は老害には決してならないと強い意思を持っていたとしても、どうやら脳科学的には避けられないものだと聞いたことがあります。 というわけで、意思よりも明文化すべきだろうということで個人的にではありますが、老害エンジニアとしての行動指針を策定致しました。 若くないことを肯定し、世代の違いを認識する 親の世代に比べると例えば今の30代は過去の30代よりも若いし、40代は過去の40代よりも若い人が多くなったというイメージがあります。自分が子供の頃の30overって完全にオッサンオバハンのイメージでしたが、少なくとも見た目の面では変わってきている潮流にあるのでしょう。老化のスピードは緩まっているのではないかということですね。ジョジョでお馴染みの荒木飛呂彦先生は50代だそうですが、あのような50代の

ベストセラー作家です。「Docker/Kubernetes 実践コンテナ開発入門」の発売から半年。 非常に流れの早い領域なので、半年も経過すればトレンドも変化しているものです。というわけで、現時点で加筆するとしたら何をするかについて書く。 ちなみに全国ツアーと称したハンズオンみたいなものもやっていて、その中では書籍出版以降のトレンドを取り込んでやっているつもり。ご要望があれば遠方で行うのもやぶさかではない。 全国ツアー資料です / Kubernetes Handson Osaka - Speaker Deck https://t.co/Wvoa5k2R6X — す (@stormcat24) January 31, 2019 1章 Dockerの基礎 ナシ。 2章 Dockerコンテナのデプロイ ナシ。初刷と2刷ではJenkinsのバージョンの問題によって、あるタイミングからプラグイン

この記事はCyberAgent Developers Advent Calendar 2018の21日目の記事。 Docker/Kubernetes 実践コンテナ開発入門（技術評論社）が大ヒットした１年であるが、最近ではコンテナに関してはそれほど�興味もなく、モトブログばかり見ている@stormcat24です。著書においては付録で�Amazon Elastic Container Service(ECS)に�ついて軽く紹介しているが、当時はEKSが東京リージョン未サポートされてなかったためスルーした。 この度めでたく東京リージョン着弾ということでEKSについて雑な所感を書く。 クラスタ作成地味につらい とりあえずクラスタ作成はMangement Consoleからポチポチやっていく。現時点で、Kubernetesのバージョンは1.11までサポートしているのは良い。バージョンの追従は大変だと

この記事は CircleCI Advent Calendar 2015 - Qiita の10日目の記事です。 前回はpokrkamiさんによる「circle.ymlの書き方」でした。 circle.ymlの書き方 - 冷やしブログはじめました 今日はCircleCIで変更があった箇所だけに限定してビルドするテクニックについて書きます。 時間のかかるビルド 今のプロジェクトではMicroservices志向でやっててDockerをフル活用しているのですが、それゆえに運用しているDockerイメージの数はそれなりの数があります。 アプリ側ではAPIコンテナやReactでSSRするコンテナ、バッチコンテナ、その他インターナルなMicroserviceなコンテナ等色々あります。 それとは別に、nginxやtd-agentといったミドルウェアのコンテナがあり、これらも用途別に複数用意されています。

「Docker/Kubernetes 実践コンテナ開発入門」の発売からもうすぐ2週間となる。 Amazonでカテゴリのベストセラーになったり、書泉ブックタワーコンピュータ書ベストで1位になったり、著者としてはこんなに反響あると思ってもいなかったので驚きの日々を過ごしているところ。 おかげさまで発売一週間で増刷が決定ということで、この場を借りて御礼申し上げたい次第であります。 「Docker/Kubernetes 実践コンテナ開発入門」好評につき増刷が決定しました🎉https://t.co/Br0l3wdsgW — ْ (@stormcat24) August 31, 2018 さて、見どころについては前回のエントリで紹介しているので、今回は出版に至った経緯や、どのようにして作られたかを手記というか、チラシの裏として書いておきます。 執筆のイベントの発生 2017年6月末に弊社で開催されて

こんにちは、オジュウチョウサンです。既にTwitterでは告知してますが、8/25（土）に技術評論社から「Docker/Kubernetes 実践コンテナ開発入門」を出版します。 8/25発売「Docker/Kubernetes 実践コンテナ開発入門」の詳細でました！コンテナ未経験でも最速で本番活用できるようになる内容です💪#kubernetes はもちろん、ポータビリティある軽量イメージの作り方やスペシャルTIPSまで、コンテナライフを豊かにする一冊です🎉https://t.co/Br0l3wdsgW #docker pic.twitter.com/aYd00j2HH9 — ْ (@stormcat24) August 2, 2018 執筆の経緯とか、どのように進めていったかについては別のエントリを用意するつもりなので、本エントリでは本書の見どころを紹介しておきたい💪 本書の目的

諸事情で欲しかった。 動機 gooseというGoで書かれたcliのDBマイグレーションツールを使っているのだが、こいつのバイナリだけを持っているDockerイメージが欲しい GoにもAlpine Linuxベースの軽量なイメージがある。しかしそれでも240MBくらいある ベースイメージはGoでなくていいので、gooseのバイナリをシュッと実行ディレクトリに配置した軽いイメージが欲しい といったところ。ちなみにAlpine Linuxはもともと組込系用途で利用されていたディストリビューションで、最近ではDockerイメージのベースディストリビューションとして広く利用されてます。 index | Alpine Linux Alpine glibc問題 Alpine Linuxを駆使してDockerイメージのダイエットに腐心されてる人ならわかると思いますけど、GoのバイナリをビルドしてAlpin

SRE(Site Reliability Engineering)が叫ばれて久しいですが、Googleがこの度Site Reliability Engineeringに関する書籍をWeb上で無料で公開したので早速かいつまんで読んでみた。きっとそのうち日本語化されてオライリーのebook上に並ぶのでしょう。 とりあえずRelease Engineeringの章に目を惹かれて興味深かったので斜め読みしてみた。 リリースエンジニアの役割とは Googleではリリースエンジニアの役割について以下のように定義している。 Googleにはコードの変更を本番環境に反映する時間やビルドを構成するファイルの中で利用される機能に関する統計といった様々なメトリクスをレポートするツールがあり、これらのほとんどはリリースエンジニアによって考案され開発されたものだ。ベストプラクティスはリリースプロセスのすべての要素が

この記事はCyberAgent エンジニア Advent Calendar 2015の7日目の記事です。 CyberAgent エンジニア Advent Calendar 2015 - Adventar 6日目はkaelaelaさんの「なぜデザイナーとエンジニアは分業するのか」でした。 弊社のAdvent Calendarは2年連続の参戦です。思えば昨年も12月2週の月曜だった気がしますね。 普段何をしているかというと、業務中のTwitterだったり、プロジェクトメンバーを煽ったり、事業部長が連発する80年代の死語を矯正したり、競馬予想をしたり、新しくできた頭のおかしいエンジニア評価制度をボロクソに批判したりというのが主であります（完全にクズですね）。 とはいえたまには真面目に弊社エンジニアブログに寄稿したりもしているんですよ（＾ω＾） 『Flexible Blue Green Deplo

これは富士そば Advent Calendar 2017の15日目の記事。 Web業界におけるここ数年の富士そば熱の盛り上がりはすごいものがあり、各所で富士そばミートアップが開催されたり、クッ◯パ◯ドで富士そば風レシピがバズったり、人気企業ランキング2017的なやつでダイタンホールディングスが上位にランクインしたりで、まさに富士そばにとっては今年は大ブレイクの1年であったと言っても過言ではない。このAdvent Calendarもそんな富士そば熱の盛り上がりを受けて立ち上げられたものだ。 いかに安く、早く回転率を上げることが良いとされるファストフード界隈で、富士そばの経営哲学は完全に他と一線を画している。 “ホワイト経営”名代富士そば創業者の人生哲学「精神的な圧迫が人間には一番悪い」 「人は馬鹿じゃない、計算するよ。休みもなくて金もくれなきゃ働かない。ブラック企業と言われるような経営なんて

最近バックグラウンドで稼働する決済系のMicroservicesをKotlinで作ってめでたく運用開始したので、どんな感じでやったかを雑に共有。 Kotlin選択の理由 自分はScalaが好きなんですけど、周りに書ける人いないし、そんなに時間もないし、で素のJavaもダルいしってなって現実的な解となったのがKotlinだったに過ぎません。 Javaをバックグラウンドに持つ人が多い今のプロジェクトではなかなかよかった気がしてます。コンパイル速度もほどんど気にならなかったし満足（規模が大きくなったらどうなるだろうかというのはあるが）。 spring-boot-starter-web 手堅くSpring Bootを利用。もちろんKotlinでも利用できます。 これはヘルスチェック用のControllerですが、Kotlinではこんな風にかけます。個人的にはレスポンス用のdata classをCo

ちょっとの間Kotlinを書いていたら、その間にGo1.7.1まで行ってて昨日重い腰を上げてアップデートしました。それは良いとして、当方GolangはVisual Studio Codeで書いているんですが、アップデートの弊害かコード補完が効かなくなりました。 この画像のように、オートコンプリートの候補にPANICとしか出ないようになりますｗ もしかしたらハマる人もいるかもしれないので雑に回避方法を共有しときましょう。 回避方法 以下の手順で回避できます。gocodeをアップデートし、gocode closeするだけ。 $ go get -u github.com/nsf/gocode $ gocode close 自分の場合、結構古いgocodeがローカルに存在していたのでトラブったみたいです。

package io.stormcat import spark.Spark.* fun main(args: Array<String>) { get("/echo", { req, res -> "Hello, ${req.queryParams("name")}!" }) } GradleでJarをビルドする KotlinなのでもちろんGradleを使ってビルドします。重要なのは、作成したアプリケーションをSpringBootのように一つのJARファイルにしてしまう、javaコマンドに**-jar**を渡すだけで実行できるようにすることです。雑にベタッと貼りましょう。 group 'io.stormcat' buildscript { ext.kotlin_version = '1.0.4' repositories { mavenCentral

Helmをご存知だろうか？簡単に言うと、Kubernetesのパッケージマネージャと位置付けられているもの。最近はかなり開発が活発化していて、Kubernetes運用のためのエコシステムとしてメインストリームに出てきている（と言っても良いと思う）。 ロゴを見ればわかるとが、Helmは日本語に訳すと舵のこと。KubernetesではService、Deployment、ConfigMap等のKubernetesの様々なリソースを組み合わせることで初めてアプリケーションとして動作できるようにしているわけだが、HelmはKubernetesのリソース群をChartsという単位でパッケージングしてしまおうというもの。 プライベートリポジトリを立てたい 自分のプロジェクトでもKubernetesをHelm管理していこうと思っているので、さっそくプライベートリポジトリを立ててみた。 Helmはプラグイ

最初からKubernetesやGKEを使っているプロジェクトには無縁だと思うのだが、途中から部分的にKubernetes化を進めて、Kubernetesクラスタ外からServiceを利用できるようにしたいというケースもあるかと思う。 Nginx Ingress Controller このようなケースではserviceをKubernetesクラスタ外に公開する必要があるので、ingressを用意する必要がある。ingressから受けたリクエストをうまくルーティングする層が必要になるわけだが、その際に役に立つのがingress-nginxだ。 設定 kube-systemに配置しているが、別のnamespaceでingressを設定すればクロスネームスペースからでも利用できる。この辺は各自の環境に合わせて忖度してほしい。 default-backend default-backendはingr

Node.jsでgRPCを利用するアプリケーションを書いてるのだが、Alpine LinuxベースのDockerコンテナで運用する場合、ld-linux-x86-64.so.2 が無くて死ぬという備忘。 Error: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /nodeapp/node_modules/grpc/src/node/extension_binary/grpc_node.node) at Error (native) at Object.Module._extensions..node (module.js:597:18) at Module.load (module.js:487:32) at tryModuleLoad (module.js:

2月ですね。 さて、CircleCIにはcache_directoriesという機能があって、前回のビルドでダウンロードしたり生成したりするもので時間的コストのかかるものをキャッシュしておいて、次回以降のビルドでコンテナにリストアできます。 例えば、MavenでJarを大量にダウンロードしてきて出来上がったローカルリポジトリ等ですね。ちなみに.m2や.ivy等はデフォルトでキャッシュされます。 Dockerイメージのキャッシュ ライブラリの他に、時間的コストとなるものの代表というとやはりDockerイメージなんですけど、実はこれをcache_directoriesの機能を使ってイメージの場所を指定してもビルドの時間は短縮できません。 実はCircleCIの公式ドキュメントには、ひっそりと以下のように記述されています。 Docker images aren't cached automati

先月、GoogleがgRPCのバージョン1.0を発表しました。 GoogleがオープンソースのRPCフレームワーク「gRPC 1.0」を発表 | OSDN Magazine gRPCとはGoogleが公開しているHTTP2ベースのRPCフレームワークで、Protocol Buffersでサービスインタフェースやリクエストやレスポンスのデータ構造を定義します。特定の言語に依存しないメリットがあり、かつ型の恩恵も受けることができます。Protocol BuffersのIDLでデータ構造やインタフェースを定義すると、C++/C#/Java/Go/Ruby/Python/Objective-Cといった言語のクライアントプログラムを自動生成できるため、生産性でも強みが有ります。 最近ではMicroservices構成におけるサービス間通信によく利用されたり、iOSやAndroidといったモバイルアプ

長らくCIはJenkinsを利用して開発をしてきて、Hudson時代からご愛顧してきたのですが、この春から新しくスタートしたプロジェクトではJenkinsを利用しないという決断をしました。 Jenkinsとサヨナラした理由 複数プロジェクトで共有して利用するのがツライ うちの会社では共通で用意されたJenkinsがあって（それなりにスペック高くて、slaveもぶら下がってる）、色々なプロジェクトがそれを利用しています。 このケースの問題点は何よりもランタイムやSDKを共有してしまうことにあります。全てのビルドに副作用を与えることなく、ランタイムやSDKを追加・更新するのが簡単ではありません。それを滞りなくやるには事前にどのビルドが何を使っているかを把握したり、利用者にお伺いを立てたりとかの調整ごとも発生します。 じゃあプロジェクト1つで専有Jenkinsを立てれば解決かというと、影響範囲の

Maven Centralに辟易しているpom職人のみなさまこんにちは。 今日はJitPack.ioというサービスを紹介しますよ。 JitPack.ioとは JitPack.ioは一言で言うと、GitHub上のJavaプロジェクトをライブラリとして参照できるようにするサービスです。Maven Centralなどのリポジトリは無いけど、GitHubのあるプロジェクトをちょっと参照して試してみたいとかありますよね。そのリポジトリのJarを自力で作ったり、そのままソースをコピーして参照したりと色々と辛みのある作業になりますが、JitPack.ioはそれをシンプルに解決してくれます。 まあとりあえず実践して、方法と仕組みを理解してみましょう。 参照するリポジトリ ライブラリとして参照するリポジトリとして、jitpack-libraryというのを作ってみました。これで実験します。 jitpack-l