タグ

ブックマーク / blog.inductor.me (10)

  • KubeVirtの何が嬉しいのか - inductor's blog

    こちらのPublickeyの記事だけ見て中身がよくわかってなさそうな人がちらほらいたので、KubeVirtを使うことの意味についてちょっと書いてみようと思う。 www.publickey1.jp ただのちっちゃなVM基盤が欲しい場合は、ほぼ不要なもの 勉強目的などを除き、仮想マシンの数が10に到底届かないような仕組みでKubeVirtを動かす場合、かなり勿体無いので採用する意味はあまりないと思う。Kubernetesを動かすことによるオーバーヘッドがかなり大きいし、正直物理的な冗長性が十分無視できるくらいの規模と言わざるを得ないので仮想化基盤としてKubeVirtを採用するメリットは薄い。EC2とかESXiとかProxmoxとか既存の仕組みを使えばいいんじゃない?と思う。 採用に値するであろうメリット1: IaaSを作りたい場合 KubeVirtの質は、「KubernetesAPIを使

    KubeVirtの何が嬉しいのか - inductor's blog
  • CIOpsとGitOpsの話 - inductor's blog

    はじめに GitOpsという言葉が生まれたのが自分の知る限り2017年頃なのですが、世の中にあるCI/CDの仕組みはまだほとんどがCIOpsもしくは手動のオペレーションによって成り立っていると思っていて、かつては自分もそうだったのですが「Gitで管理されていればGitOpsなんでしょ?」という勘違いを払拭したくてこのエントリーを書いています。 GitOpsとCIOpsは全然違う まず前提としてGitOpsの明確な定義を知らないという場合、あなたの思う「Gitを契機とした自動デプロイの仕組み」は基的にはCIOpsです。GitOpsとCIOpsは思ったよりも大きな違いがあって、そもそもGitOpsの必要性が分かっていない場合、自動化によって成立しているデプロイはCIOpsが基です。 CIOpsとGitOpsの一番の違いは、Push型かPull型かである CIOpsの場合、例えばGitHub

    CIOpsとGitOpsの話 - inductor's blog
  • 軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 - inductor's blog

    はじめに やめろ、ではなく、やめたほうがいい。です。自分のユースケースに合ってるか今一度確認することを推奨します。基的にはAlpineは避けたほうが良い、というのが2021年時点での私の認識です。 なんで? libcに一般的な互換性が不足しているからです。RubyPython、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。 superuser.com あとは他のベースイメージの軽量化もそれなりに進んできていて、Alpineが定番軽量イメージと言う認識は2018年頃には消えつつあったかなという認識でいます。 どうすりゃええねん ※Debian Slimがあるやんってツッコミ結構もらったんですが、Slimは当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい

    軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話 - inductor's blog
  • Kubernetes 1.20からDockerが非推奨になる理由 - inductor's blog

    追記: 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. 影響範囲を知りたい場合

    Kubernetes 1.20からDockerが非推奨になる理由 - inductor's blog
  • DockerのデフォルトランタイムをrunCからKata containers + Firecrackerに変えるのが簡単すぎてビビった話 - inductor's blog

    はじめに これはコンテナランタイム好きのオタク記事です。DockerでrunC以外のランタイムを動かしてみようと思ってはいたもののずっとやれてなかったので、実際にやってみたら超簡単でした、という記事です。 ランタイムを変える意味について Dockerでは、コンテナを作成する機能をrunCという低レベルコンテナランタイムを用いて実現しています。 runCではLinuxカーネルの機能を呼び出すためにホストOSの特権を利用しますが、これはrunCの命令を実行する瞬間に悪意のあるコードを実行されると、ホストの特権を攻撃者に奪われてしまうリスクもあります。詳しくはrunCのこのへんとかを読んでみるとおもしろいかもしれません(?) ところで、runCというランタイムはOCIの標準仕様に基づいて作られています(厳密には、LXCを置き換えるために作られたrunCが持っている機能を標準化したものがOCIとい

    DockerのデフォルトランタイムをrunCからKata containers + Firecrackerに変えるのが簡単すぎてビビった話 - inductor's blog
  • 社内でインフラエンジニア向けに作ったFargate勉強会の資料を公開します - inductor's blog

    TL; DR 以前、社内向けにDocker/Kubernetes入門の勉強会を開催したのですが、今回はそれに引き続き、AWS Fargateに関する勉強会を開きました。 speakerdeck.com 資料の目的 前回の勉強会の資料についてはこちらをご覧ください。 inductor.hatenablog.com 今回の勉強会については、前回Kubernetesに入門してからそこそこ概要を理解した前提で、AWSのマネージドサービスであるECSやFargateの実態や、その特徴について理解してもらうために開きました。 ECS初心者がつまづきがちな、FargateとECSを比較してしまう問題や、そもそもECSというサービスの立ち位置などについて改めて解説した資料となっています。 インフラ向けではありますが、開発者が見てもわかりやすくなるよういくつか前提知識のスライドも含めていますので、もしよけれ

    社内でインフラエンジニア向けに作ったFargate勉強会の資料を公開します - inductor's blog
  • Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その2- - inductor's blog

    このエントリーについて このエントリーを書き始めた経緯は下記にあります。 inductor.hatenablog.com 今回は前回の続きでセクション3からです!前回のエントリーはこちらです。 inductor.hatenablog.com 3. Borgアーキテクチャ(Borg architecture) Borgセルは、マシンのセット、Borgmasterと呼ばれる論理的に集中化されたコントローラ、およびセル内の各マシン上で実行されるBorgletと呼ばれるエージェントプロセスで構成されます(図1参照)。 BorgのすべてのコンポーネントはC++で書かれています。 3.1 Borgmaster 各セルのBorgmasterは、メインBorgmasterプロセスと個別のスケジューラ(§3.2)の2つのプロセスで構成されています。 メインのBorgmasterプロセスは、ステートを変更(ジ

    Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その2- - inductor's blog
  • Docker社がエンタープライズ事業を譲渡した今、Dockerの父が思うこと - inductor's blog

    はじめに 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として公開したものがはじまりです。 公開当時は

    Docker社がエンタープライズ事業を譲渡した今、Dockerの父が思うこと - inductor's blog
  • Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その1- - inductor's blog

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

    Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その1- - inductor's blog
  • 社内勉強会で作ったDocker/Kubernetes入門の資料を公開しました - inductor's blog

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

    社内勉強会で作ったDocker/Kubernetes入門の資料を公開しました - inductor's blog
  • 1