トレタO/X アーキテクチャ移行記 Next.js App Router化への道のり / TORETA TECH UPDATE 1
KubernetesをGoogleが開発し、オープンソース化し、成功した経緯。関係者らが肉声で語るドキュメンタリー映像「Kubernetes: The Documentary」YouTubeで公開 ITエンジニア向けの転職紹介などキャリアサービスを提供しているHoneypot社は、Google、Red Hat、Cloud Native Computing Foundationの協力の下、Kubernetesの誕生から現在までをドキュメンタリー映像としてまとめた「Kubernetes: The Documentary」をYouTubeで公開しています(Part 1、Part 2)。 Do you know the story of @kubernetesio? Hear the details of how the project came to be from those who live
どのようにコンポーネントを分類していくか 個々のコンポーネントがが単一の責任のみ負っている状態であれば、コードの見通しも良くなる上、後々のメンテナンスも容易です。 まずは「複数の関心ごとを1つにまとめない」という原則(単一責任の原則)から分類の指針を考えていきます。 フロントエンドにおける関心ごとですが、大別すると APIとの接続 View(表示とイベント実行) 状態管理 以上3つに集約されるのではないでしょうか。 では、これらの関心ごとをどの様に切り分けていけば良いのか考えていきます。 APIとの接続 まずはAPIとの通信ですが、こちらはコンポーネントの外で管理した方が良いと考えています。 各コンポーネントに通信に関わる処理がベタ書きされている状態だと、エンドポイントの変更等に弱くなり、通信処理の再利用も面倒です。 それに、「フロントの状態管理 / 表示」と「外部との接続」はそれぞれ別種
Preferred Networks エンジニアの坂田です。普段は社内向けの GPU サーバークラスタの運用管理の業務などをやっております。 先日、DevOpsDays Tokyo 2021 というイベントで、弊社 須田と一緒に PFN が Kubernetes を使って GPU クラスタを運用する中で経験してきた障害とその対応の自動化や、Kubernetes クラスタそのものの管理・アップグレードの自動化の取り組みについてご紹介しました。 SlideShare: PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021 本エントリでは、その中でご紹介した障害の事例の中から、コーナーケースとして対応に悩まされた Uninterruptible Sleep という状態に入ったプロセスの扱いについてご紹介します。 はじめに PFN のクラ
KubeCon EU 2021というイベントが先日行われ、その基調講演の中でRed Hatの人によるThe Hybrid Control Plane という短いセッションがあった。 内容をかいつまんで紹介すれば、①Kubernetesのコンテナ管理機能をコンテナに限らず汎用的に使えるように拡張したら、②リソースやクラスタの管理で生じる問題が解決できるのではないか?という問いかけだ。 ①Kubernetesのコンテナ管理機能とは、マニフェストファイルによる宣言的な設定や、状況に応じて自動的にコンテナが再配置されるリコンサイルループによる自動調整機能だ。説明はKubernetesがいかに自動化の考え方を変えたか?という記事が詳しい。 ②リソースやクラスタの管理で生じる問題とは、マルチテナントやマルチクラウドを考えると分かりやすい。複数の動作環境、複数のチームを横断的に監視、管理するための組織が
2021年に注目すべきCNCFの5つのテクノロジーを「Kubernetes Meetup Tokyo」のセッション記事から解説する はじめに Kubernetes Meetup Tokyoの懇親会用に話のネタとしてメモを残す。 2021年に注目すべきCNCFの5つのテクノロジーとは? KubeConNA(2020)最終日のkeynote session、Keynote: Predictions from the Technical Oversight Committee (TOC) - Liz Rice, CNCF TOC Chairで、CNCFのTOC(技術統括委員会)の委員長を務めるLiz Riceさんが、CNCFの2021年の技術的展望として紹介した5つの技術要素である。(順不同) カオスエンジニアリング エッジコンピューティングとしてのKubernetes サービスメッシュ Web
はじめに 今朝に書いたブログが思ったより反響が大きくて、「Dockerが死んだ」という勘違いをされている方も多かったので追加でエントリーを書きました。 blog.inductor.me 決してそんなことはないので、対応が必要なケースを見ていこうと思います。 はじめに 対応が必要ではないケース Kubernetesを使わない人たち 本番はKubernetesでも、開発にDocker Composeを使っているデベロッパーの開発環境 対応が必要なケース 開発環境でも手元でKubernetesを利用する人たち NVIDIA DockerをKubernetesで使っている人たち Kubernetesワークロードの中で「Docker in Docker」や「Docker APIに依存した処理」を動かしている場合 Dockerの機能を使ってこれまでやっていたことについて 対応が必要ではないケース Ku
Docker 公式ブログに「What developers need to know about Docker, Docker Engine, and Kubernetes v1.20 という投稿があり、何が書かれているのか要点を日本語でまとめました。 書かれているポイントは「Kubernetes で Docker が非推奨ではなく、これまで通り使い続けられる」であり「Docker イメージの話と、ランタイムの話は別」との内容です。 今回のDockerのブログ投稿を捕捉しますと、Kubernetes における docker-shim の話と、 Docker イメージの扱いは別だ、という内容でもあります。つまり、前提として「Docker Engineとcontainerd、Dockerコンテナとイメージの話」も分けて考えたり議論する必要があります。 Docker エンジンを構成する要素の1つ
今話題のこれ。 kubernetes.io これに関しての日本語情報として、 @inductor が相当詳細に記事を書いてくれている。 blog.inductor.me blog.inductor.me にも関わらず、未だに完全に間違った解釈をしている人が多く観測される。記事をちゃんと読めば理解できるはずなのだけど、たぶんタイトルしか読んでいない。 タイトルしか読まないのであれば、あえて強めのタイトルにしておけば目にはつくかなと思い、改めて書いてみることとした。 Dockerは非推奨じゃないし、これからもバンバン使え まず @inductorが解説しているとおり、k8sを使っていない人には全く関係のない話なので、今まで通りDockerを使って良い。 が、もう一つ誤解を解いておきたいのが 自分の環境でDockerを使ってイメージ作成し、Kubernetesにデプロイしている人にも、今回の件は
Kubernetes development is not one-size-fits-all. Maybe you’re learning Kubernetes with Minikube on your local machine; maybe you’re part of a large organization with many clusters; maybe your cluster is an on-prem lab, or lives in the cloud. But whether you’re a cluster operator managing policies, an app developer test-driving a new service, or a data scientist running Kubeflow, chances are you ar
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く