クラウド的なアレ

あまり触っていないうちにRustのマイナーバージョンがグングンと上がっていた。 たまにしか使わないPCのバージョンを追いつかせるのはしんどい、という思いからついにリモートコンテナ環境を準備した。 構成などについては次のページがわかりやすい。 Developing inside a Container using Visual Studio Code Remote Development Developing inside a Container using Visual Studio Code Remote code.visualstudio.com Create a development container using Visual Studio Code Remote Development Create a development container using Visual Studio Code Remot code.visualstudio.com Rustの場合だと、Microsoft公式だとこの辺りがコンテナイメージのベースとして使うのに良さそうだった。 microsoft/vscode-remote-try-rust Rust sample project for trying out the VS Code Remote - Conta github.com microsoft/vscode-dev-containers A repository of development container definitions for the VS github.com まあただ、どういう便利なことをやってくれているのかが自分であまり理解できなかったので、ひとまずはrust:1.51のイメージを自分で指定して使ってみることに。 .devcontainerディレクトリ内にdevcontainer.jsonというリモートコンテナの設定や必要なプラグインの情報などを書くJSONファイルと、その中から読み込ませる実際のコンテナのイメージのためのDockerfileを置く必要がある。 あとはVS Codeで該当のディレクトリをひらけばDev Containerとして開くかを聞いてくれて、コンテナのビルドを実施する。 devcontainer.jsonやDocke

簡易的なアプリの検証の関係で、指定したホストで動かしたい、が会社のドメインに登録するような正式なレベルではまだやりたくない、という状況があった。 そこでアクセス元の/etc/hostsを書き換えるとともに、OpenShift上のRouteに登録する、という方法で対応することにしたが、/etc/hostsに記載するべきIPアドレスがわからなくて困った。 調べ方はいくつかあったので、どちらも記録しておく。 ちなみに確認した環境はIBM CloudのManagedのOpenShift環境。AzureやAWSだとまたちょっと事情が違うかもしれない。 Digで確認する まずは、比較的汎用性の高そうな方法から。 なんらかの方法でIngress Subdomainを調べる。例えば、デフォルトでアクセスできるインターネットアクセス向けのクラスターのURLのサブドメインなどがそれに該当。 IBM Cloudならクラスター一覧（  https://cloud.ibm.com/kubernetes/clusters?platformType=openshift  ）から辿れる該当のクラスターの "Ingress Subdomain"を確認する。 例えば xxxx.jp-tok.containers.appdomain.cloud のようなサブドメイン名が得られるので、これに対してdigコマンドをかける。 結果はこんな感じ。（一部置き換えている） $ dig xxxx.jp-tok.containers.appdomain.cloud ; << >> DiG 9.10 . 6 <<>> xxxx.jp-tok.containers.appdomain.cloud ;; global options: +cmd ;; Got answer: ;; - >> HEADER<<- opcode: QUERY, status: NOERROR, id: 26408 ;; flags: qr rd ra; QUERY: 1 , ANSWER: 1 , AUTHORITY: 0 , ADDITIONAL: 0 ;; QUESTION SECTION: ;xxxx.jp-tok.co

OpenShift外に構築したサーバーに接続しに行く必要があった。 アプリのコンテナ内は環境変数で接続先を差し込めるようにしてある。 例えば、 192.168.10.11:5432/mydb が接続先だったとする。 で、このIPアドレスの部分をOpenShiftのサービスとして登録して使えるはず、というにわか知識があった。 なので、次のようにexternal serviceを定義して、 oc create svc externalname ext-mydb --external-name 192 .168 .10 .11 その上で接続先を ext-mydb:5432/mydb とすれば、接続先の管理を個別のアプリ内ではなくてOpenShift上に移すことができる。 と思ったのだけど、この状態で接続をトライしてもまったくうまくいかなかった。 事情としてはこの辺。 Service externalName: IP? For those who still comes to this thread, here’s a link with discuss.kubernetes.io ServiceService An abstract way to expose an application running on a set of kubernetes.io  なので、対応案としては2つ。（だが自分で確認できたのは前者のみ） IPアドレスしかないのであれば、IPアドレスを含んだドメイン名で解決してくれるサービス、例えばxip.ioなどを使う。 言い換えると、192.168.10.11.xip.ioのようにexternal-nameを指定する。 xip.io: wildcard DNS for everyone xip.io もう一つはサービスとして書いた上で、Endpointリソースの定義でIPアドレスを指定する。 ただ、これはやり方が悪かったのかもしれないが、期待していた動きにはならなかった。まずそもそもこの方法の場合、Service定義でTypeとしてClusterIPが指定必須で、ExternalNameを指定できない。この時点でoc get svcした時に一目で外部サービスだとわかるポイントを失いつつあるので既に辛い。 その上、いざ指定してみても疎通が確