はじめに GoogleのマネージドKubernetesディストロであるGKEの新機能（厳密には新しい種類のクラスターといったほうがユーザーにとっては正しい説明になると思いますが）、GKE Autopilotが先週大きく話題になりました。 ノードがGoogle Cloudによるマネージド Podごとの課金体系 ノードへのSSHが使えない といった特徴が大きく取り上げられており、ぱっと見AWSのEKS Fargateと非常に似ているように見えます。が、(少なくとも、user facingな部分においては)技術的には全くやっていることが違うと思います。なぜならFargateはEC2とは全く異なるVM技術がベースになっているのに対して、Autopilotは通常のGCEを応用した機能として提供されているからです。 ※まあ、GCEは実はコンテナで動いてるみたいなちょっとした裏話もあったりするんで、本当

追記: Kubernetes側での公式のアナウンスが2本出ているのでこちらも合わせてご覧ください。 kubernetes.io kubernetes.io Kubernetesコミュニティを眺めていたら、やたらめったら色んな人達が1.20 RCのリリースノート引っ張り出して「Dockerが非推奨になるからちゃんと対策を検討してね！！！」とアナウンスをしていて、挙げ句SIG Contributexではその対策に追われてバタバタしている自体を観測しました。 CNCF Ambassador Slackでもだいぶ燃え上がっていて、見かねて dev.to に記事を投稿したのでそれをかんたんに日本語にまとめてみようと思います。英語のほうはこちらをご覧ください。 dev.to 追記2. 影響範囲を知りたい場合はまずこちらをお読みください blog.inductor.me 追記2. 影響範囲を知りたい場合

はじめに git checkoutの機能 既存のブランチに移動する 新しいブランチを作成してそれに移動する あるファイルを特定のコミットハッシュ/ブランチから取得 checkout vs switch & restore 対応表 はじめに gitのバージョン2.23からgit switch及びgit restoreコマンドが入り、git checkoutがこれらの2つに分離されるようになりました。これに伴い、git checkoutも将来的に廃止の方向に向かうでしょう。 ※switch/restoreはまだ実験的導入のため、今後文法などが変更になる場合があります。 git checkoutの機能 git checkoutには大きく分けて以下のような機能があります。 既存のブランチに移動する 例えば自分が作業ブランチbranch-aにいたとして、masterブランチに移動したい時に使います。

はじめに KubernetesではWebアプリケーションから業務用のワークフロー（バッチ処理とか）に至るまで様々なアプリケーションを動かすことができるが、現実世界において苦労するポイントの1つは、ワークロードに秘匿情報を渡すための方法である。 例えば、アプリケーションの上でデータベースに接続するために必要なエンドポイントの情報やパスワードなどの認証情報は、アプリケーションのソースコードに直接書くことはご法度だし、コンテナ化する際に内包することも原則タブーである。また環境変数として注入する場合でも、その情報が物理ディスクに残ってしまう場合などを考え最新の注意を払う必要がある。 ここではKubernetes上のワークロードに秘匿情報をできるだけ安全にわたすための方法を運用者・開発者の目線で考える。 Kubernetesが持つ外部情報注入の仕組み Kubernetesの場合、アプリケーションに情

はじめに こんにちは。inductorです。 今回は、社内のSRE技術共有会にて、MLOpsチームにおける監視の考え方や取り組みについて発表したので、その資料を展開します。 speakerdeck.com ご意見ご感想お待ちしております！

このエントリーについて このエントリーを書き始めた経緯は下記にあります。 blog.inductor.me 1. はじめに(Introduction) サーバーレスコンピューティングは、[4、16、50、51]などのパブリッククラウド環境と[11、41]などのオンプレミス環境の両方で、ソフトウェアやサービスをデプロイ、管理するためにますます一般的になっているモデルです。サーバーレスモデルは、サーバーの運用やキャパシティ管理、自動スケーリング、従量制の価格設定、イベントおよびストリーミングデータのソースとの統合など、いくつかの理由において魅力的です。コンテナは、Dockerによって最も一般的なかたちで具体化され、運用オーバーヘッドの削減や管理性の向上など、同様の理由で一般的になっています。コンテナとサーバーレスは、従来のサーバープロビジョニング処理に比べて明確な経済的利点を提供します。マルチ

このエントリーについて このエントリーを書き始めた経緯は下記にあります。 inductor.hatenablog.com 上記の理由の通り、目的は論文を翻訳することだけではなく、最終的にこれを踏まえて自分の見解をつらつらと書いていくところにもあります。 おそらく一番時間がかかるのはそれなので、一旦は翻訳を一通り終えた上で更に頑張っていきます。ゆっくりお待ちいただければと思います＞＜ 1. Introduction(まえがき) Borgが内部的に呼び出すクラスター管理システムは、Googleが実行するすべてのアプリケーションを許可、スケジュール、起動、再起動、および監視します。この論文ではその方法を説明します。 Borgには3つの主な利点があります。 リソース管理と障害処理の詳細を隠すため、ユーザーは代わりにアプリケーション開発に集中できます。 非常に高い信頼性と可用性で動作し、同じことを行

TL; DR Docker/Kubernetes初心者の方と一緒に仕事をすることになったので、はじめの一歩として勉強会を開いたときに作成した以下の資料を公開しました。 speakerdeck.com 資料の目的 ZOZOテクノロジーズではたくさんのプロジェクトがあり、技術的にも古いものから新しいものまでいろいろなものが使われています。その多くは歴史的経緯や開発者たちのレベル感、今まで経験した技術などをベースに選定されることが多いです。 弊社 岡がCNDT2019にて発表した以下の資料や、ZOZOTOWNの作り直しの真っ赤な広告にもあるように、古い技術を使い続けてグロースを続けてきた結果、社内のプロジェクトのいくつかはスケーラビリティとして飽和に近い状態のものもあります。 ZOZOTOWNのCloud Native Journey from Toru Makabe www.slideshar

はじめに タイトルは釣りです（テンプレ） はじめましての方ははじめまして。特にこの記事がバズるとも思ってないんですが、なんとなく新しく僕のことを知っていただいた方のために自己紹介しておきます。 ZOZOテクノロジーズ開発部に所属するインフラエンジニアのようなことをやっている者です。チーム的にはMLOpsチームという組織にいます。Dockerが好きです。 社内では本名の太田さん、pchan、いんだくたーさん、こうちゃんなどと呼ばれています (Ref: @sonots) 自分のことを知っている方はご存知だと思いますが、自分語り満載のエントリーになる予定です。だるいと思った方はスルーしてもらって大丈夫です！ 入社の経緯とか そもそもの入社のきっかけは、前職で働いていた頃に遡ります。前職では小さな(?)Web制作会社で受託案件のPHPを書いたりAndroidアプリ(Java)の保守などをメインに担