Dockerからcontainerdへの移行
https://speakerdeck.com/ktock/dockerkaracontainerdhefalseyi-xing背景: Kubernetes 1.24は組み込み機能としてのDocker対応を打ち切る2014年に公開された初期のKubernetesはDockerにのみ対応していましたが、2016年のKubernetes 1.5では Container Runtime Interface (CRI) と呼ばれる共通インターフェースが導入され、 CRIに対応した任意のランタイムが利用可能になりました。以来、様々なランタイムが開発されてきましたが、2022年現在では containerd と CRI-O の 2つが主流です。 CRIが導入されてからも、Kubernetesに組み込まれているDocker対応機能(dockershim)が広く使われていましたが、2022年4月リリース予
Cloud Run の Always on CPU で Cloud Pub/Sub から Pull する worker を試してみた
TL; DRCloud Run の Always on CPU を使うと、Cloud Pub/Sub から Pull する Worker を Cloud Run で実行出来ます。ただし、スケーリング等にいくつか諸注意があります。 はじめにCloud Run の Always on CPU が Preview でリリースされて、バックグラウンド タスクや非同期処理で使えると Twitter で宣伝したところ、私の tweet 史上、一番の反響を頂きました。ありがとうございます。また同僚の Shingo-san が素敵な解説記事を書いてくれたり、同じく同僚の Pottava-san も素敵なサンプルコードを書いてくれてたり。「tweet してるだけでいいのかい？本当に？」という私のエンジニアとしての良心の呵責があったため、私もこうして記事を書いています。 試したこと以前、お客様から Cloud
完全マネージドな k8s ! GKE Autopilot を解説する
Kubernetes / GKE ファンの皆様こんにちわ。Google Cloud の Kazuu (かずー) です。GKE Autopilot が GA になりました。弊社公式ブログに続きまして、GKE Autopilot を日本語で解説していきたいと思います。 本記事は以下、3 部構成となります。 GKE Autopilot 概要GKE Autopilot を試してみるGKE Autopilot がハマりそうなユースケースは？ 1. GKE Autopilot 概要GKE Autopilot は GKE の新しいモードです。Control Plane に加えて、Node が完全マネージドになります。これまでの GKE では Node はユーザー自身が必要台数分作成し、以後の Day 2 オペレーション (e.g. アップグレード) 等も気に掛ける必要がありました。GKE Autopil
メディアにオススメ！Google 印の Transcoder API 爆誕！
はじめにこんにちは、Customer Engineer の Dan です。Google Cloud Japan Customer Engineer Advent Calendar 2020 の 11 日目の記事は 2020/11/18 に爆誕したばかりの Transcoder API について紹介します。凄く便利なのにグローバルで驚くほど使用レポート記事がないので（涙）、使い方や使い所がイメージしやすい形でまとめてみました。少しでも興味を持ってもらえる、もしくは皆さんの参考になれば幸いです。 TL;DRTranscoder API の概要と特徴Transcoder API の基本機能と特徴的な機能の紹介Transcoder API の使い方Transcoder API に期待すること Transcoder API logo なんかオシャレTranscoder API とはトランスコーディン
GCPにセキュアな踏み台サーバーを作成する
TL;DR GCPのIdentity-Aware Proxy(IAP)を利用すると、手軽かつセキュアに自宅などから踏み台サーバーへのアクセスを実現できます。加えてオンプレミスとGCPで拠点間VPNが構築できると、社外からGCPを経由してオンプレミスへセキュアにアクセス可能です。 昨今の状況を含め突発的な出来事により、社内にある環境に社外からアクセスする事が必要になるケースは無いでしょうか？ 今まではダイヤルアップ型のVPNを構築する、踏み台サーバー(要塞ホスト)を構築するといったやり方で解決が図られて来ましたがどちらのやり方もエンドポイント(VPN Gateway、踏み台サーバー)へのセキュリティ対策を綿密に行う必要があるため実装には多くのコストがかかります。 社外から社内へアクセスする際のイメージ今回はGCPを使ってセキュアかつ簡単に社内へアクセスできる環境を構築する方法をご紹介します。
「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を１年掛けて整理した
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
アンチパターンから学ぶ！Cloud Spanner あるあるクイズ
本記事では、Cloud Spanner を初めて使う場合にハマってしまいがちなポイントを、クイズ形式でまとめてみました。Cloud Spanner を適切に使うために、思わぬ落とし穴にはまらないように、参考資料などにも目を通してください。 Cloud Spanner とは？？Cloud Spanner は、スケーラビリティと強整合性を兼ね備えた、エンタープライズレディーなデータベースです。急峻なスパイクに対しても瞬時に DB の性能を変更できるため、API サーバに近い感覚で、DB をスケールアウト、スケールインさせることが可能です。 そんな Cloud Spanner ですが、うまく使いこなすためには、Cloud Spanner の特性を考慮した設計が必要になります。Cloud Spanner では、うまくデータを分散させつつデータローカリティもうまく使う必要があり、そのためには、スキー
Cloud Run が GA になったから改めて色々見てみる
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 7日目の記事です。 本記事で触れるのは Fully managed 版の Cloud Run のみです 🙇 みなさん、こんにちは。Google Cloud の Kazuu( かずー ) です。2019 年 4 月 9 日に Fully managed 版の Cloud Run が Beta としてリリースされてから半年以上経ち、去る 2019 年 11 月 14 日にとうとう GA となりました㊗️ 本記事では GA に至るまでにどんな機能が主に追加されてきたのかリリースノートの時系列で見ていきたいと思います。 Cloud Run の基本的なところを知りたいという方は Next Tokyo の動画や Cloud OnAir も併せてご覧ください。Cloud
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
Cloud Spannerの主キーの設計
Cloud Spanner は完全に管理されたミッションクリティカルなリレーショナル データベース サービスであり、グローバルなスケールでのトランザクション整合性、スキーマ、SQL（拡張機能を含む ANSI… ただドキュメントを見てもID生成器のことなどを理解していないと、いざ設計するとき苦労するかと思い記載しました。ドキュメントの補足資料として読んでいただけたら幸いです。 Cloud Spannerの特徴特徴を簡単に記載しますと ノード、スプリットで構成されている。レコードデータはスプリットに配置される。どこに配置するかはレコードの主キーに依存する。レコードの増減に応じてCloud Spanner側で自動で(1)どのレコードをどのスプリットに配置するか。(2)スプリットの数 をコントロールするレコードをどのスプリットの配置するかはレコードの主キーの値に依存する分散されたスプリットにアクセ
GAE 2nd-gen でのサービス間認証
TL;DRGAE 2nd-gen では X-Appengine-Inbound-Appid ヘッダの代わりに、ID Token + Identity-Aware Proxy を使った方式をサービス間認証に使えます。 はじめにGAE でマイクロサービスを構成する場合、各サービス同士を呼び合うときに同一 GAE アプリからのリクエストであるかを確認したい場面があります。シンプルな例だと、サービスがフロントエンドとバックエンドに別れていて、バックエンドはフロントエンドからしか呼び出せないようにしたい場合です。 GAE 1st-gen では X-Appengine-Inbound-Appid ヘッダという魔法のヘッダがありました。このヘッダは URLFetch を使用して別の GAE サービスにアクセスする時に、GCP が自動で呼び出し元の Project ID を入れてくれるヘッダです。そのため
Tekton ~ Kubernetes native pipeline resource ~
CI / CD してますか？ 2019年初頭、Tekton プロジェクトが公開されました。本投稿では、Tekton の基本的な概念と、簡単な使い方をご紹介します。 Tekton ?Tekton は、Kubernetes-native pipeline resource と表現される通り、k8s 上で CI/CD パイプラインを構築するためのフレームワークです。元々は、Knative プロジェクトの中で始まったプロジェクトで、現在は、Continuous Delivery Foundation でホストされています。 Tekton は “k8s-native” が表す通り、GKE は勿論、ローカルの k8s クラスターを含む、様々な k8s 環境で動作します。また、パイプラインをYAML形式で宣言的に記述でき、後述する Tekton の概念により、組み合わせ可能かつ再利用性が高いという特徴が
Docker 19.03新機能 (root権限不要化、GPU対応強化、CLIプラグイン…)
NTTの須田です。2019年7月23日に公開された、Docker 19.03の新機能をお伝えします。2018年11月8日にリリースされたDocker 18.09以来、8ヶ月ぶりのリリースです。 root権限不要化従来のDockerは、ホストのroot権限でデーモン(dockerd)を動作させる必要があったため、脆弱性や設定ミスを突かれると、ホストのroot権限を奪われる恐れがありました。 Docker 19.03では、非rootユーザでデーモンを実行できるようになりました(Rootlessモード)。 Rootlessモードを有効化することで、万一Dockerに脆弱性や設定ミスがあっても、攻撃者にホストのroot権限を奪取されることを防ぐことが出来ます。ただし、現時点ではcgroupを利用できないなどの制約があります。 RootlessモードのDockerは， curl -fsSL http
Google Apps Script は何が強くてどんなときに使うべきかプラクティスをまとめてみた
はじめにGoogle Apps Script は無料で色んなことが実現できるため、ついつい「全て GAS でやっちゃおう」みたいな話になりがちです。Google Apps Script も万能ではないので、強み・弱みを理解した上で他の選択肢と比較して使うのをお勧めします。 Google Apps Script のプロジェクトを 2–30 個作ってきた中で、自分なりのプラクティスをまとめてみます。 この内容は Cloud Next ’18 in Tokyo で登壇したときの内容を含んでいます。この登壇から半年以上経ったのでアップデート部分も以下にまとめています。 Google Apps Script の強み・弱みまず、強みと弱みについてまとめてみます。 強み 1. Google Apps の API を簡単に呼び出すことができる一番の強みはこれだと思います。Google Apps Scrip
Google Cloud Next 2019 in SF , DevOps関連発表まとめ
Google Cloud Next 2019 in San Francisco が 2019 年 4 月 9 ~11 日に開催されました。その中で、DevOps 関連の発表をまとめました。 Cloud Code for IDEsCloud Code を利用することで、クラウドネイティブアプリケーションを、より速く、より簡単に、開発・デプロイ・デバッグすることができます。Cloud Code for VS Code (Beta)、Cloud Code for IntelliJ (Alpha) で利用可能です。 コンテナを使ったアプリケーションを開発する場合、ソースコードを編集するたびに、コンテナのビルド・デプロイを繰り返す作業が頻繁に発生するため、開発以外の作業に多くの時間を取られてしまいます。 Cloud Code を利用することで、ソースコードの変更を自動的に検知し、本番環境へのデプロイ
Google Cloud Next 2019 in SF , サーバーレス関連発表まとめ
[18 分 20 秒 ~] Cloud Runの概要とデモ、特に [34 分 00 秒 ~] のオートスケーリングのデモはCloud Runの優位性が分かる内容ですさらに Cloud Run に全振りしたセッションとしては以下がオススメです。Cloud Run のリソースモデルや、またCloud Tasks や Cloud Scheduler との連携、さらに具体的なユーザー事例まで盛り沢山です。また、このセッションを見る限り東京でも Cloud Run がすぐに使えるようになりそうです。 [36 分 50秒 ~] VELOLIA 社の事例紹介現状は何に使えそう？Knative をベースにしているものの、今のところ Eventing は Cloud Run と Cloud Run on GKE 両方ともにサポートされておらず、当面は Web や API をホストする環境として使うことになる
GCP からの HTTP リクエストをセキュアに認証する
はじめにGCP にはあらかじめ HTTP のエンドポイントを登録しておくと、そこに対して HTTP リクエストが送られてくるようなプロダクトがいくつか存在します。 Cloud Pub/SubCloud TasksCloud Schedulerどれも非同期系の処理を行うプロダクトであり、非同期処理を行う Worker を HTTP の Web サーバとして記述できるのが大きなメリットになっています。 しかしそれらの Web サーバはパプリックなエンドポイントとして用意することも多いことから、送られてきた HTTP リクエストが本当に GCP の特定のプロダクトから送られてきたものなのか？という「認証」をどうやるかが長らく問題になっていました。 既存のやり方としては Web サーバの実装方式によっていくつかありますが、 App Engine (1st gen) を使う場合: “login: a
Cloud Run を最速で触ってみる
Cloud Run とはGoogle Cloud Next 18では serverless containers on the Google Cloud Functions infrastructure + GKE Serverless addonと説明されたものですね。 早速、こちらのQuickStartやってみましょう 事前に必要なことプロジェクトを作成する（既存のプロジェクトを利用することもできます。終了後の後片付けを考えると新しくプロジェクトを作っても良いです）プロジェクトのbillingを有効にするCloud Run APIを有効にするCloudSDKのインストール済み/設定済みであることcomponentsのupdateと、beta componentsのinstallが必要です。コンポーネントをupdateするgcloud components updatebetaコンポーネ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Auto-scaling from zero machine on Google Compute Engine
GStreamer ❤ Windows: A primer on the cool stuff you’ll find in the 1.20 release