サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
blog.inductor.me
追記: 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. 影響範囲を知りたい場合
はじめに やめろ、ではなく、やめたほうがいい。です。自分のユースケースに合ってるか今一度確認することを推奨します。基本的にはAlpineは避けたほうが良い、というのが2021年時点での私の認識です。 なんで? libcに一般的な互換性が不足しているからです。Ruby、Python、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。 superuser.com あとは他のベースイメージの軽量化もそれなりに進んできていて、Alpineが定番軽量イメージと言う認識は2018年頃には消えつつあったかなという認識でいます。 どうすりゃええねん ※Debian Slimがあるやんってツッコミ結構もらったんですが、Slimは当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい
TL; DR Docker/Kubernetes初心者の方と一緒に仕事をすることになったので、はじめの一歩として勉強会を開いたときに作成した以下の資料を公開しました。 speakerdeck.com 資料の目的 ZOZOテクノロジーズではたくさんのプロジェクトがあり、技術的にも古いものから新しいものまでいろいろなものが使われています。その多くは歴史的経緯や開発者たちのレベル感、今まで経験した技術などをベースに選定されることが多いです。 弊社 岡がCNDT2019にて発表した以下の資料や、ZOZOTOWNの作り直しの真っ赤な広告にもあるように、古い技術を使い続けてグロースを続けてきた結果、社内のプロジェクトのいくつかはスケーラビリティとして飽和に近い状態のものもあります。 ZOZOTOWNのCloud Native Journey from Toru Makabe www.slideshar
これは何 以下記事のアンサーブログです。 qiita.com 以下のことはコメントに書いたんですが、書ききれなかった部分もあったり整理したほうがいいなと思い記事に起こしています。 現代のアプリケーションではC10K問題よりも先にDBやアプリケーションのボトルネックが先に来るため、C10K問題に遭遇するよりも先にやることがある ミドルウェアとしての成り立ちから設定ファイルの書き方に至るまで、それぞれのソフトウェアで思想が根本的に異なるので、単なるパフォーマンス比較をしてもあまり意味がない NginxとApacheの違いをC10K問題を中心に語るのは時代が違う この記事に限らず、多くの「Nginx vs Apache」系記事では「ApacheはC10K問題を抱えている」という論理をベースにそれぞれの違いを表現しています。 が、これは2022年においては(実際にはもっと前からですが)既に事実では
Docker一強の終焉にあたり、押さえるべきContainer事情 を読んで漠然とDockerが終わるって思った人、素直に手をあげてください。別にDockerは終わりません。なんかむしろWASMとかんばるぞって息巻いてて可愛いので頑張って欲しいと個人的には考えています。 その昔、Kubernetes 1.20からDockerが非推奨になる理由 - inductor's blog を書いたら炎上しました。最初の記事の書き方が良くなかったという反省はあるにせよ、世間一般で「Dockerは開発環境で使うやつ」という認識があまりにも広がりすぎているというのが良くわかる勉強の機会になりました。 逆を言うと、みなさんがこれらの記事を読む時には、Dockerという言葉に含まれる意味に注意して読んでいただきたいと思っています。Dockerには大きく分けて以下の意味が含まれると僕は考えています。 Docke
このエントリーについて このエントリーを書き始めた経緯は下記にあります。 inductor.hatenablog.com 上記の理由の通り、目的は論文を翻訳することだけではなく、最終的にこれを踏まえて自分の見解をつらつらと書いていくところにもあります。 おそらく一番時間がかかるのはそれなので、一旦は翻訳を一通り終えた上で更に頑張っていきます。ゆっくりお待ちいただければと思います>< 1. Introduction(まえがき) Borgが内部的に呼び出すクラスター管理システムは、Googleが実行するすべてのアプリケーションを許可、スケジュール、起動、再起動、および監視します。この論文ではその方法を説明します。 Borgには3つの主な利点があります。 リソース管理と障害処理の詳細を隠すため、ユーザーは代わりにアプリケーション開発に集中できます。 非常に高い信頼性と可用性で動作し、同じことを行
はじめに GitOpsという言葉が生まれたのが自分の知る限り2017年頃なのですが、世の中にあるCI/CDの仕組みはまだほとんどがCIOpsもしくは手動のオペレーションによって成り立っていると思っていて、かつては自分もそうだったのですが「Gitで管理されていればGitOpsなんでしょ?」という勘違いを払拭したくてこのエントリーを書いています。 GitOpsとCIOpsは全然違う まず前提としてGitOpsの明確な定義を知らないという場合、あなたの思う「Gitを契機とした自動デプロイの仕組み」は基本的にはCIOpsです。GitOpsとCIOpsは思ったよりも大きな違いがあって、そもそもGitOpsの必要性が分かっていない場合、自動化によって成立しているデプロイはCIOpsが基本です。 CIOpsとGitOpsの一番の違いは、Push型かPull型かである CIOpsの場合、例えばGitHub
インフラエンジニアの肩書きをSREに変えるタイプの組織変更は近いところから遠いところまでいろんなところで見かけてるんだけど、改めてそれって名前変えただけじゃないよね?って問いかけは個人が組織に、組織が個人にそれぞれ相互でした方がいいと思う。 インフラエンジニアって言葉もまあ定義が死ぬほど広くてどこからどこまで指すのってのは組織によって違うね大変だねって話ではあるんだけど、SRE(Site Reliability Engineering)やPE(Platform Engineering)はインフラと必ずしも対応関係にあるわけではないんだよな。 Platformってのは言ってしまえば会社のエンジニア組織の中で自分達に最適化された基盤を作る人たちの集合体とそのプロダクトそのものを指していて、Platform Engineering組織の中には当然フロントエンドエンジニアやデザイナー、プロダクトオ
社内のことは多くは書けないので、部署の雰囲気やチームでのやりとりについて、書ける範囲で書いてみる。お約束っぽくなってしまうが、これはあくまで個人としての経験・意見を書いたもので、会社の意見や思想を代表するようなものではないことに留意いただきたい。また、構造化した文章を書くつもりはないのでMarkdownは使わずにだらだら書いていく。 多くの人が中身や実態について知りたがっている一方で、ちょっとボロを出すとすぐブコメとかでネガキャンしてくる勢力がいて面倒なので書くか大いに迷ったのだが、純粋にその中身にポジティブな方向で興味がある人や、あるいは入社のハードルを少しでも下げたいといった気持ちで実験的に記事を書く。よって、書かないことは書かないし、それ以上追記をするつもりも特にない。ソーシャルのDMでも質問は基本的に受け付けていないので、どうしても知りたい人はカンファレンスなどで自分を捕まえて話し
はじめに 今朝に書いたブログが思ったより反響が大きくて、「Dockerが死んだ」という勘違いをされている方も多かったので追加でエントリーを書きました。 blog.inductor.me 決してそんなことはないので、対応が必要なケースを見ていこうと思います。 はじめに 対応が必要ではないケース Kubernetesを使わない人たち 本番はKubernetesでも、開発にDocker Composeを使っているデベロッパーの開発環境 対応が必要なケース 開発環境でも手元でKubernetesを利用する人たち NVIDIA DockerをKubernetesで使っている人たち Kubernetesワークロードの中で「Docker in Docker」や「Docker APIに依存した処理」を動かしている場合 Dockerの機能を使ってこれまでやっていたことについて 対応が必要ではないケース Ku
TL; DR 以前、社内向けにDocker/Kubernetes入門の勉強会を開催したのですが、今回はそれに引き続き、AWS Fargateに関する勉強会を開きました。 speakerdeck.com 資料の目的 前回の勉強会の資料についてはこちらをご覧ください。 inductor.hatenablog.com 今回の勉強会については、前回Kubernetesに入門してからそこそこ概要を理解した前提で、AWSのマネージドサービスであるECSやFargateの実態や、その特徴について理解してもらうために開きました。 ECS初心者がつまづきがちな、FargateとECSを比較してしまう問題や、そもそもECSというサービスの立ち位置などについて改めて解説した資料となっています。 インフラ向けではありますが、開発者が見てもわかりやすくなるよういくつか前提知識のスライドも含めていますので、もしよけれ
はじめに GoogleのマネージドKubernetesディストロであるGKEの新機能(厳密には新しい種類のクラスターといったほうがユーザーにとっては正しい説明になると思いますが)、GKE Autopilotが先週大きく話題になりました。 ノードがGoogle Cloudによるマネージド Podごとの課金体系 ノードへのSSHが使えない といった特徴が大きく取り上げられており、ぱっと見AWSのEKS Fargateと非常に似ているように見えます。が、(少なくとも、user facingな部分においては)技術的には全くやっていることが違うと思います。なぜならFargateはEC2とは全く異なるVM技術がベースになっているのに対して、Autopilotは通常のGCEを応用した機能として提供されているからです。 ※まあ、GCEは実はコンテナで動いてるみたいなちょっとした裏話もあったりするんで、本当
はじめに タイトルは釣りです(テンプレ) はじめましての方ははじめまして。特にこの記事がバズるとも思ってないんですが、なんとなく新しく僕のことを知っていただいた方のために自己紹介しておきます。 ZOZOテクノロジーズ開発部に所属するインフラエンジニアのようなことをやっている者です。チーム的にはMLOpsチームという組織にいます。Dockerが好きです。 社内では本名の太田さん、pchan、いんだくたーさん、こうちゃんなどと呼ばれています (Ref: @sonots) 自分のことを知っている方はご存知だと思いますが、自分語り満載のエントリーになる予定です。だるいと思った方はスルーしてもらって大丈夫です! 入社の経緯とか そもそもの入社のきっかけは、前職で働いていた頃に遡ります。前職では小さな(?)Web制作会社で受託案件のPHPを書いたりAndroidアプリ(Java)の保守などをメインに担
はじめに 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ブランチに移動したい時に使います。
sad記事の勉強と実践のボリュームがすごい https://blog.ojisan.io/server-architecture-2023/ を読んで、その前身とも言える https://blog.yuuk.io/entry/2015-webserver-architecture を含めてこれらのような記事を書く知識や経験が僕には無いから素直にすごいと思った。ただ、その一方でこの内容を普通に理解できる「Webエンジニア」はどのくらいいるんだろう?というのも同時に気になった。 ゆううきさんの記事は「序論」とあるがWebエンジニアとしてキャリアを積む人間が「序論」として読むには文量や背景知識が重すぎると正直思うし、システム・計算機工学を勉強した人間が背景に感じ取れる。事実、sadさん(おじさん)も昔は内容が分からなかったと本人記事内で言及しているため、僕の気のせいではないと思う。じゃあsad版
はじめに こんにちは。inductorです。 今回は、社内のSRE技術共有会にて、MLOpsチームにおける監視の考え方や取り組みについて発表したので、その資料を展開します。 speakerdeck.com ご意見ご感想お待ちしております!
はじめに これはいわゆる退職エントリーです。3月も終わりを迎え、ZOZOテクノロジーズ社員として活動する実質的な最後の日になりました。 誰?という方はツイッターやGitHub、本ブログの他の記事などをあわせて見ていただければ幸いです。QiitaやSpeakerdeckにもこれまでの活動の一部は記録してあります。 TL;DR 2020年3月末をもって株式会社ZOZOテクノロジーズを退職し、4月よりヒューレット・パッカード・エンタープライズ(所属は日本ヒューレット・パッカード株式会社)にお世話になります。 ZOZOでの在籍期間は2018年4月からのため、ちょうど2年でした。 入社後は、2018年4月より自社プライベートブランド用海外向けECサイト(既にクローズ済)の立ち上げにおけるインフラの構築に始まり、社内向けサービスのAWS環境構築やその監視導入などを勉強しながらおよそ年内まで担当しました
はじめに これはコンテナランタイム好きのオタク記事です。DockerでrunC以外のランタイムを動かしてみようと思ってはいたもののずっとやれてなかったので、実際にやってみたら超簡単でした、という記事です。 ランタイムを変える意味について Dockerでは、コンテナを作成する機能をrunCという低レベルコンテナランタイムを用いて実現しています。 runCではLinuxカーネルの機能を呼び出すためにホストOSの特権を利用しますが、これはrunCの命令を実行する瞬間に悪意のあるコードを実行されると、ホストの特権を攻撃者に奪われてしまうリスクもあります。詳しくはrunCのこのへんとかを読んでみるとおもしろいかもしれません(?) ところで、runCというランタイムはOCIの標準仕様に基づいて作られています(厳密には、LXCを置き換えるために作られたrunCが持っている機能を標準化したものがOCIとい
はじめに こんにちは。inductorです。 GCPのCloud Runはご存知でしょうか。世界一簡単に単一のコンテナをデプロイできるサービスだと私は考えています。 さて、以下のようなリリースノートの通知があって、Cloud RunがGitと連携して更新まで自動でできるようになったみたいです。 Continuous deployment from Git using Cloud Build まとめるとこんな感じのことが書いてあります Cloud Buildのトリガーを使用して新しいコミットがGitリポジトリの特定のブランチにプッシュされるたびにコードを自動的にビルドしてデプロイすることで、ビルドとCloud Runへのデプロイを自動化できます。 Cloud Buildトリガーを使用してコンテナをビルドすると、Cloud Runにデプロイした後、ソースリポジトリ情報がサービスのCloud C
こちらのPublickeyの記事だけ見て中身がよくわかってなさそうな人がちらほらいたので、KubeVirtを使うことの意味についてちょっと書いてみようと思う。 www.publickey1.jp ただのちっちゃなVM基盤が欲しい場合は、ほぼ不要なもの 勉強目的などを除き、仮想マシンの数が10に到底届かないような仕組みでKubeVirtを動かす場合、かなり勿体無いので採用する意味はあまりないと思う。Kubernetesを動かすことによるオーバーヘッドがかなり大きいし、正直物理的な冗長性が十分無視できるくらいの規模と言わざるを得ないので仮想化基盤としてKubeVirtを採用するメリットは薄い。EC2とかESXiとかProxmoxとか既存の仕組みを使えばいいんじゃない?と思う。 採用に値するであろうメリット1: IaaSを作りたい場合 KubeVirtの本質は、「KubernetesのAPIを使
はじめに KubernetesではWebアプリケーションから業務用のワークフロー(バッチ処理とか)に至るまで様々なアプリケーションを動かすことができるが、現実世界において苦労するポイントの1つは、ワークロードに秘匿情報を渡すための方法である。 例えば、アプリケーションの上でデータベースに接続するために必要なエンドポイントの情報やパスワードなどの認証情報は、アプリケーションのソースコードに直接書くことはご法度だし、コンテナ化する際に内包することも原則タブーである。また環境変数として注入する場合でも、その情報が物理ディスクに残ってしまう場合などを考え最新の注意を払う必要がある。 ここではKubernetes上のワークロードに秘匿情報をできるだけ安全にわたすための方法を運用者・開発者の目線で考える。 Kubernetesが持つ外部情報注入の仕組み Kubernetesの場合、アプリケーションに情
はじめに この記事ではAWSの公式ブログ「Amazon EKS adds native support for Bottlerocket in Managed Node Groups」で取り上げられている内容を、eksctlを使わずCloudFormationでimmutableに実現するための方法を解説します。 aws.amazon.com Bottlerocketとは Bottlerocketは、AWSが開発しているコンテナ実行専用OSです。Fedora/RHELのCoreOSやVMwareのPhoton OS、Rancher OSなどと似ていて、コンテナを実行するためのランタイム以外余計なパッケージが入らない軽量なOSとなっています。 aws.amazon.com Bottlerocketの開発状況についてはBottlerocket Roadmap · GitHubを合わせてみると良
はじめに この記事は、以下のlwn.netの記事を抄訳したものです。 lwn.net CPU Namespaceのご紹介 これはCPU namespaceのインターフェスとそのメカニズムを証明するための初期プロトタイプです。 現状におけるCPUリソースの制限方法 Linuxカーネルでは、タスクのCPUリソースを制御するために2つの方法を提供します。 cgroup cpuset: 該当のグループにアタッチされた単一または複数のタスクの集合に対し、CPUリソースを制限するためのメカニズムです。 syscall sched_setaffinity: CPUの集合に対して特定のタスクをピニングするためのシステムコールです(訳注: NUMA利用時の条件下などにおいてよく利用される手法)。 また、カーネルはシステムにおいて利用可能なCPUリソースを閲覧可能にするために3つの方法を提供します。 sys/
年の瀬なのでちょっとした思い出話を書き記しておく。 自分が高専を中退したとき、精神的にはかなりズタボロな状態で、この時期(年末年始にかけての冬休み)から既に登校が不可能な状態になっていた。お世話になっていた寮にも年始からは戻ることが難しく、単位ギリギリでなんとか大学受験の資格だけをもらえる「修了退学」というところにこぎつけられるかどうかだった(結果的にはそうなった)。 当時の担任(今はもう定年で学校を去ってしまったらしい、当時は本当にお世話になった)から、出席日数の関係で体育をあと1時限分受ける必要があるため、登校したほうがよいと告げられ、当時既に留年までしていたので1つ下の「同級生」たちに奇異の目で見られながら久々の登校をした。このとき既に退学をすることは心に決めていて、ついでなのでお世話になった先生にご挨拶に伺った。 このとき、ある数学の先生に言われた一言が今も心に残っていて、凹んだと
このエントリーについて このエントリーを書き始めた経緯は下記にあります。 blog.inductor.me 1. はじめに(Introduction) サーバーレスコンピューティングは、[4、16、50、51]などのパブリッククラウド環境と[11、41]などのオンプレミス環境の両方で、ソフトウェアやサービスをデプロイ、管理するためにますます一般的になっているモデルです。サーバーレスモデルは、サーバーの運用やキャパシティ管理、自動スケーリング、従量制の価格設定、イベントおよびストリーミングデータのソースとの統合など、いくつかの理由において魅力的です。コンテナは、Dockerによって最も一般的なかたちで具体化され、運用オーバーヘッドの削減や管理性の向上など、同様の理由で一般的になっています。コンテナとサーバーレスは、従来のサーバープロビジョニング処理に比べて明確な経済的利点を提供します。マルチ
はじめに これは手抜き記事です。動画見て面白かったのでそれを日本語に起こしただけ。個人的にあ、これはただの宣伝だな、と思ったところは省いてます。 元動画はこちら Life of a photon through global load balancing (Networking End to End) 字幕起こし 前置き 多くの人にとって、宇宙で最も大きな謎の1つは、Googleが世界で1秒未満で何十億もの猫の画像結果を返す方法です。そこで、私たちがどうやってそれを実現しているのかを説明するために、友人のユーリをここに連れてきました。 インターネットにはこうした検索を高速化するための最適化手法がたくさんありますが、Googleのグローバルアーキテクチャには独自の「秘伝のタレ」があり、それを使うことであなたが知る速度と精度を実現することができます。これにより、多くの顧客や企業は、そのパフォー
はじめに こんにちは。inductorです。 今日のエントリーはタイトルの通りです。 BorgはGoogleが持つアプリケーション実行基盤で、Google CloudにおいてはGKEのマスターノードやGoogle App Engineなどが実際に動くインフラとしても使われています。 また、話題のKubernetesの元になったGoogle Insideなプロジェクトとしても有名かとおもいます。 ツイッターで誰かが「Borgの論文を誰か日本語で解説してほしい」と言っていたのを見かけたのを見かけたので、論文を読んで実際に中身を紐解いてみたいなと思いました。 元論文はこちらです ai.google 何を書くのか 自分は実はBorgの論文をきちんと読み込んだことはないため、時間を掛けて何回かに分けてやってみようと思っています。 実は、Borgの解説自体は他の方々もやっているようで、僕が改めてやる意
はじめに これは転職エントリーです。この2年出社はしていませんが、一通り仕事を終えたので投稿ってことで自分のブログに自分語りをします。「お前誰」っていう人はツイッターや過去のブログ記事でも読んでからお読みください。 2020年3月に公開したこちらのエントリーでは、ZOZOを退職した話を書きました。その後これまで2年ちょっとの間はHPE(日本ヒューレット・パッカード合同会社)にてクラウドアーキテクトとして勤務していました。人によってはHPEよりもZOZOのイメージが強いかもしれませんが、実はHPEの方が若干在籍期間が長いです。 blog.inductor.me 在職中は国内外・大小問わずいろいろな案件に関わらせていただいて、事例紹介のページにもおもしろスーツぽっちゃり写真が出ています。気になる方は探してみてください。 転職します、という話 ※転職先については隠す必要は実はないのですが、最近ち
はじめに Dockerの開発元であるDocker社が、Docker EE(Enterprise Edition)に関するビジネスをMirantis社に売却しました。 Mirantis社はかつてはOpenStackをメインにビジネスを展開していましたが、ここ数年はマルチプラットフォームなKubernetesとしてMirantis KaaSを展開しています。 TL; DR Docker社は今後、Dockerのエコシステムを開発者体験、プラットフォームとしての親和性の向上に努めていく Moby projectをDockerの名前に戻そうという提案が出ている Dockerの父が、DockerとMobyの明確な違いについて語ってくれた Dockerのはじまり Dockerは、かつてdotCloud社が同じ名前でPaaSを提供していたときの「基盤」をOSSとして公開したものがはじまりです。 公開当時は
次のページ
このページを最初にブックマークしてみませんか?
『inductor's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く