このブログを検索

この記事の内容は、個人の見解、検証の範囲のものであり、誤りがある可能性があります。
個人の責任において情報活用をお願いします。


2023年8月31日木曜日

Rancherでkubernetesの管理をしてみる 第5回 RancharからPodとServiceを作って外部から接続してみる

今回は、RancherからPodやServiceを作って外部からのアクセスをできるようにしてみたいと思います。
事前準備として、KubernetesにはMetalLBを構築してServiceでタイプLoadBarancerを作成した際に、IPアドレスを払い出してくれるようにしてあります。

早速、今回の作業用として新しく名前空間demoを作成するところから開始していきたいところですが、Rancherではプロジェクトという単位で管理ができるのでこれから作成する名前空間を管理するプロジェクトを作成したいと思います。
『Create Project』から新しくプロジェクトを作っていきましょう
プロジェクト名demoを設定し、せっかくなので前に作ったユーザーもアクセスできるようにしてみます。
これは名前空間ではなく、Rancher上の設定になりますので実機の方ではまだ変化はありません。
(一応、新しいリソースでProjectとかないか確認しましたが、見当たらなかったのでRancher側だけのはず・・・)
表示が見づらくなるので、作成したProject:demoだけ表示するように上部のプルダウンから切り替えます。
ここから『Create Namespace』をクリックして名前空間の作成に入ります。
名前空間名にdemoを入力してCreateします。 特にリミットは設定しません。
名前空間demoが作成できたので、実機の方もsshでログインして確認してみます。
続いてPodの作成をしますが、Podから作るのではなくDeploymentを使用して作ってみましょう。
『Workload』を展開し、『Deployments』から『Create』をクリックします。
ここで使用するイメージはデモでよく使われているkuardをお借りします。
先ほど作成した名前空間を指定し、Deploymentsの名前を設定し、レプリカ数はとりあえず1にしておきます。
このアプリケーションはポート番号8080を使うので『Add Port』をクリックします。
ここで一緒に外部と接続するためのリソースのServiceを作成することができるようなので、コンテナが待ち受けるポート8080とプロトコル、外部から待ち受けるポート80を設定します。
PodとServiceを紐付けるためにラベルが必要なので『pod』に表示を切り替えてラベルの設定をしましょう。
手動で設定かなと思ったら自動で入ってましたのでこれを使ってみることにしました。
この辺は普段yamlを書いている人なら使いたい値だけ入れればいいのですが、何も知らない人が使ってもさっぱりわからないと思うのでKubernetesの経験者が扱うツールなのだなぁと実感しますね。
『Create』から作成します。
作成を実行すると以下のように、DeploymentsとPodにそれぞれリソースが作成されます。
作成したら実機を見てみましょう。
それぞれリソースが作成されていますね。
Podにはラベルが付与されています。
ServiceにはPodに付与されたラベルがSELECTORにセットされています。
では、ちゃんと接続できるかEXTERNAL-IPに表示されているIPへブラウザからアクセスしてみます。
ちゃんと動いていてくれていますね。
動くかどうか若干不安ではあったんですが問題がないようでほっとしました。
結構素直に動いてくれてありがたいです。
私は正直もうyamlを書くことの方に慣れてしまったのでyamlを書いたほうがしっくりくる体質になっているのですが、GUIで完結できそうなのはいろんな人が使う上ではいいのかなと思います。

今回は以上です。

参考情報
https://github.com/kubernetes-up-and-running/kuard

2023年8月4日金曜日

海外でのワーケーションを考える その7 Google CloudでChrome Remote Desktopを利用する


「海外でのワーケーションを考える」7回目の投稿です。

まとめはこちら

https://techblog-cidept.blogspot.com/2023/08/blog-post.html


前回は、Google Chrome Remote Desktopの通信について、調べてみました。

今回は、海外の旅行先の最寄りのGoogle Cloud リージョンにGoogle Chrome Remote Desktop用のVMインスタンスを作成してみます。Google Cloudは東南アジアのシンガポールとジャカルタにリージョンを展開しています。今回は、ジャカルタ リージョン(asia-southeast2)にインスタンスを作成します。


今回Google Cloudで構成するVMインスタンスは以下となります。

Google Cloud

 VM インスタンス

  • VMインスタンス名:crdhost
  • マシンタイプ:e2-medium
  • イメージ:debian-11-bullseye-v20230711
  • 他はデフォルトのまま
Google Cloud でGoogle Chrome Remote Desktopを利用するVMインスタンスの作成手順は以下のGoogle Cloudのドキュメントに記載されています。

Compute Engine での Linux 向け Chrome リモート デスクトップのセットアップ
https://cloud.google.com/architecture/chrome-desktop-remote-on-compute-engine?hl=ja

このドキュメントに沿って作成するとChrome Remote Desktop HostがインストールされたVMインスタンスを簡単に構築できます。

VMインスタンスを作成したあと、ドキュメントに準備されているChrome リモートデスクトップのインストール用スクリプトをコピー&ペーストしてインストールするだけです。ものすごく簡単です。


Google Cloud のコンピュートインスタンスの操作は、コンソールからSSHクライアントを起動して操作できます。コピー&ペーストまでできるのでとても便利です。


同様に用意されているX Windows System デスクトップ環境のスクリプトを利用してGUI環境をインストールします。低速なネットワーク経由のリモート接続には、Xfceが良いようなのでXfceを利用します。 好みに応じてDebianの日本語環境を整えます。今回は私の家族が使うことを想定していますので、日本語環境をインストールしました。Debian日本語環境のインストール方法はGoogle Cloud のドキュメントに記載されていないので、インターネット上に公開されているDebianの情報を参考に設定します。

X Windows System デスクトップ環境までインストールしたらChrome リモート デスクトップ サービスを構成してクライアントからジャカルタリージョンに構築したVMインスタンスへリモート接続できるように構成します。手順は前回の操作とそれほど変わりません。

構成が完了したら、クライアントから以下のURLにアクセスします。

https://remotedesktop.google.com/access

  

Google Chrome リモートデスクトップよりリモートアクセスを表示します。

作成したVMインスタンス「crdhost」が表示されオンラインになっています。


クリックしてリモート接続します。接続手順は前回と同じです。


ジャカルタリージョンのVMインスタンスにアクセスできました。


東京のクライアント → ジャカルタのVMインスタンス → 東京のホストへアクセスしてみました。若干のラグはありましたが、リモート操作も可能でした。この環境で家族に一度テストしてもらい、問題ないか確認してもらおうと思います。それでは。

海外でのワーケーションを考える


家族が海外旅行するときに自宅にある仕事用PCへアクセスする方法を検討しました。そのブログ記事のまとめです。






2023年8月3日木曜日

海外でのワーケーションを考える その6 Google Chrome Remote Desktopの通信詳細を調べる


前回はGoogle Chrome Remote Desktopクライアントからホストへ接続してみました。

今回はGoogle Chrome Remote Desktopの通信について、調べてみたいと思います。

Google Chrome Remote Desktopの通信で利用されるプロトコルやポートについて、以下のドキュメントに記載されています。

Chrome リモート デスクトップを使って他のパソコンにアクセスする

https://support.google.com/chrome/answer/1649523


上記リンクの中に「問題解決のヒント」が記載されており、以下の記載がされています。

以下、抜粋です。

  • インターネット接続が必要
  • アウトバウンド UDP トラフィック
  • インバウンド UDP 応答
  • TCP ポート 443(HTTPS)のトラフィック
  • TCP と UDP のポート 3478(STUN)のトラフィック

UDP、TCP443、そして、STUN (Session Traversal Utilities for NATs) という技術が使われています。STUN (Session Traversal Utilities for NATs) とは何でしょうか?


STUNとは、Web RTC (Web Real-Time Communication)で利用されるNAT越え通信を解消するための仕組みです。以下の記事に詳しく書かれています。

初心者必見!よくわかるWebRTCの仕組み

https://cloudapi.kddi-web.com/magazine/webrtc/understood-webrtc-mechanism


また、以下のnoteの記事にもChrome リモートデスクトップ通信について詳しく説明されています。

Chrome リモートデスクトップの安全性について
https://note.com/machii_kuro/n/n420f3c05ffb9

この仕組みによってルーターに公開サーバーの設定をせずにGoogle Chrome Remote Desktopクライアントとホストの間で通信ができているのですね。


今回の目的は、旅先の東南アジアの滞在先から自宅のPCへリモート接続できることです。接続先PCがWindows10 Homeのため、Google Chrome Remote Desktopの利用を前提に検討したいと思います。

東南アジアから日本のPCへのP2P接続をどのように構築するか。
Google Cloudに何かドキュメントが無いかと思い探していたら以下の記載を見つけました。

Compute Engine での Linux 向け Chrome リモート デスクトップのセットアップ

LinuxでもChrome リモートデスクトップを利用できるようです。Windows版のドキュメントもありますが、コスト面からLinuxで構築したほうがコストを安く抑えられそうです。
Google Cloudはシンガポールとジャカルタにリージョンを展開しているので、どちらかにインスタンスを展開して利用できそうです。
Google Cloud 
Cloud のロケーション

東南アジアの滞在先から日本の自宅へ直接Google Chrome Remote Desktopで接続することもできそうですが、現地の通信状況がわからないため、クラウドが提供する広帯域ネットワークインフラの利用も検討しておいた方が無難に思えます。

次回は、Google Cloud にインスタンスを構築してGoogle Chrome Remote Desktopの動作を確認してみたいと思います。それでは。