Panasonicの電動自転車 ギュット・アニーズ・DX 買った
子連れ移動の機動力をあげたいので電動自転車を見に行った。Panasonic, YAMAHA, ブリヂストンがあって、それぞれかなり特徴が異なるようだ。
最初はタイヤが20インチより大きいものを試す予定だったけど、チャイルドシートの設置高をなるべく低くして安全性を高める20インチに市場がほぼ収束しており、メーカーショールームでも行かない限り20インチ以上のモデルの実車は見つけるの大変、また、インチ上げても長距離でしかあまり意味がないこと、電動自転車のトラブルで一番多いのがタイヤのスポーク折れ(子供の荷重だと耐え切れなくなって経年劣化も加わって折れる)なので、タイヤ大きくしても見た目以外にそれほど恩恵はなく、逆に安全性低下と故障率の高さ、交換部品の入手難易度があがるなどデメリットが多いということだった。さすがにこれを試乗なしで決め打ち発注はしたくないのでパスして20インチから選択。
最近のモデルはリアチャイルドシートの股部分を狭くして乗り心地をあげるために後部の荷台をスリムキャリアにしているものが多いそうだ。でもキャリアの換装は4000円くらいなので誤差。
お店にあったのはほぼ2018年モデルで、2019年モデルより1万円ほど値引きされているようだった。子乗せ電動自転車あまり値引きの効かない商品らしい。
ブリヂストンのbikke MOBも試したかったけど無いものは仕方無い、ということで特に問題点が見当たらなかったPanasonicのギュット・アニーズ・DX 2019年モデルをそのまま発注、フロントチャイルドシートやヘルメットなどのオプションも含めて18万円。たっかーい。
TicWatch Pro Wear OS by Google買った
ケータイはAndroidをずっと使っている。別にAppleが嫌いとかそういうこともなく、機会があればApple製品も使ってみたいとは思っているんだけど、Apple製品はそれなりなお値段なので軽い興味を満たすだけには手を出しづらいのと、Androidのほうがオープンで多様性があって好きなだけでたまたまそうなっている。
使用遍歴はGalaxy S2 (2011), Galaxy S4 (2013), Nexus 6 (2015), Moto G4 Plus (2016), Moto G5s Plus (2018)という感じ。Nexus 6とMoto G5s Plusは一回ずつ液晶バキバキにしてしまって修理している。タブレットはNexus 7 (1st gen), Amazon Fire Tablet (5th gen), ZenPad 3S 10 LTE (2017)。今使っているものはMoto G5s PlusとZenPad 3S 10の二つ。
Pure Androidが好きでプリインストールアプリがたんまり入っているようなやつは好きじゃない。NexusやPixelのラインを追うつもりだったけど、初代Pixel日本発売なかったし、Nexus/Pixelのような解像度の高いディスプレイを積んだハイエンド端末はどうしても8万円超え的な価格になってしまって、ディスプレイ破損やバッテリーがヘタったときなどのコストパフォーマンスが良くない。1年経った8万円のケータイより最新の3万円のケータイのほうがはるかに動作が軽快だったので、8万円とかのケータイを長く使う、というのはあまり良い戦略ではない、となってそのあとは3万円台ミドルクラスのケータイをメインにしている。MotoがNexus/Pixelの次にアップデートされるプリインストールアプリのほとんどないプロダクトだったのでMoto Gシリーズを長く使っている。
NexusからMotoに移行したとき、おおむね快適だったのだけどNexusに比べるとバイブレーションが弱かった。というかNexusのバイブレーションが強すぎてかなり大きいバイブレーション音がするのでマナーモードとは？ってなる感じだったんだけど、それにすっかり慣れてしまっていたのでMotoにしたときにバイブレーションに気付かない問題、というのがあった。
スマートウォッチを導入すれば解決するかなぁ、とずっと思っていたんだけどAndroid WearがいまいちこなれてなかったりWear OS by Googleにアップデートされても話題になるようなプロダクトがなかなか出てこなかったり、ケータイが3万円なのにウォッチが5万円超えてるものが多かったりして価格バランス的に微妙だった。
最近になってTicWatch ProというWear OS by Googleで3万円のスマートウォッチが発売された＆通知気付かなくてミーティング遅れたり電話逃したりした事件があったので、いい機会だと思って先月ポチっとした。
結論から言うととても快適である。
まず腕を見るだけで時間と通知が確認できる。素晴らしい。
お前は何を言ってるんだ、当然だろう、という感じだ。前はケータイで時間を確認できるから腕時計とかいらないじゃん？みたいに思ってたけど、実際は子連れで歩いてたりすると両手が塞がっていたりするので、この基本的なところが思った以上に便利だった。また、ケータイを出し入れする頻度がかなり減るので、ケータイの破損機会が半減する。通知があると腕時計がバイブレーションする。ケータイを身に着けてなくてもほとんどの通知が確認できるというのは家の中で特に有効だった。仕事柄週末の仕事もまれにあり、通知をちょこちょこ確認するというアクションがちょっと面倒だったんだけど、そのへんもほぼ解消した。腕時計でのバイブレーションはやはりケータイのバイブレーションよりは気付きやすいのだけど、ある程度運動している状態だと通知に気付かないこともある気がする。もうちょっと様子見。
TicWatch Proの商品説明とか同梱の説明書の日本語があやしいけど、英語でしか使ってないのでまったく問題なし。
ほぼデフォルト設定で特に困ることはない。心拍数センサーついてるのにデフォルトでは記録されない、というところだけが気になったので、Heart TraceというアプリをWatchとケータイの両方に入れて、ケータイでGoogle Fit連携した。10分おきに記録してくれるようになる。心拍数取得して役に立つかどうかはまだわかってないけど。
デメリットとしては、いま1才7ヵ月のこはるちゃんのだっことかお着替えだとか、子どもに時計ぶつけたりしないように気をつけないといけないところ、くらいかな。
Red HatのOpenJDKのサポート
更新: Red Hat Enterprise Linux 7.6でOpenJDK 11が追加されました。現在のサポート期間は2024/10までです。
【JDK 11 リリース直前】各ベンダーのJDKリリースモデル特集！というイベントがあってRed Hatさんもどうですか、ってお誘いが来たんですが予定が入っており参加できなかったのでエントリを書いておきます。
Red Hat Enterprise Linux (RHEL)には商用サポートされるOpenJDKパッケージが含まれています。RHELのサブスクリプション費用に含まれており、OpenJDKのサポートには追加の費用はかかりません。yum install java-1.8.0-openjdkのようにパッケージをインストールすれば使えます。
OpenJDKのサポート期間についてはOracle社の影響が大きいという側面があり、RHELのサポート期間とは異なるサポート期間が定められています。
サポート期間についてOpenJDK 6は開始時点が遅かったので短くなっていますが、7も8も実績として8年はサポートしています。6と7についてはOracle社による無償アップデート終了後、UpstreamをRed Hatがリードしています。8もそうなるかな？
- OpenJDK 6 (1.6)
- 2009/01 - 2016/12 (約7年)
- 2013年Oracleによる無償Java 6アップデートの終了時にRed HatがUpstream OpenJDK 6のmaintenance leadに https://jaxenter.com/rip-se-6-a-tribute-to-javas-longest-serving-edition-105714.html
- OpenJDK 7 (1.7)
- 2012/07 - 2020/06 (約8年)
- 2015年Red HatがUpstream OpenJDK 7のmaintenance leadに https://jaxenter.com/red-hat-takes-the-reigns-of-openjdk-7-118261.html
- OpenJDK 8 (1.8)
- 2014/10 - 2023/06 (約9年)
- OpenJDK 11
- Red Hatの商用サポートについてはサポート期間未定だが長期サポート予定、UpstreamのOpenJDK 11リリース(2018年9月予定)後に発表予定
新しいOpenJDKリリースモデルで非LTSリリースとなったOpenJDK 9, 10などはRed Hatでは商用サポート予定はありません。LTSリリースのみ商用サポート予定となっていくと思います。
サポート内容はプロダクションサポートと呼ばれるもので、利用中の障害、バグの調査、バグ修正やセキュリティ修正の提供などが含まれます。開発サポートではないので、APIの使い方がわからない、といったような質問はサポート範囲外となります。
RHEL 7.5以降のOpenJDK 8ではウルトラローポーズGCであるShenandoah GCがサポートされています。-XX:+UseShenandoahGCで有効化できます。Shenandoah GCについてはサイボウズさんのざっくりわかった気になるモダンGC入門を見ると良いと思います。OpenJDK 11にExperimentalとして含まれるZGCについても書かれています。
あとはWindowsで開発して本番はRHEL、という一般的なユーザ向けにWindows版開発用OpenJDKというのも配布しています。開発用途専用です。Mac版は現時点で残念ながらありません。
OpenJDKへのコントリビュートはOracle社が圧倒的ですが、Oracle社以外ではRed Hatが一位となっています。
Last year, 14% of all commits to #Java mainline came from external contributors. Which companies and institutions help Oracle shape the future of @OpenJDK #JDK10 #JDK11 and push to jdk/jdk?
— BellSoft (@bellsoftware) 2018年9月12日
Kudos to all the individual contributors as well! pic.twitter.com/yfXSNw88Q1
まとめ
- Red Hat Enterprise Linux (RHEL)には長期商用サポートされるOpenJDKが含まれているよ
- OpenJDK 11もOpenJDK 7, 8と同様にサポート予定だよ
- RHEL 7.5以降のOpenJDK 8でウルトラローポーズGCのShenandoah GC使えるよ
Red Hat OpenShift Service Meshをインストールしてみる
Red Hat OpenShift Service Meshがプレビューリリースしたのでインストールしてみます。OpenShift向け製品版のIstioです。
セットアップはこんな感じ。
# Enable admission webhooks in master MASTER_CONFIG_PATCH="admissionConfig: pluginConfig: MutatingAdmissionWebhook: configuration: apiVersion: v1 disable: false kind: DefaultAdmissionConfig ValidatingAdmissionWebhook: configuration: apiVersion: v1 disable: false kind: DefaultAdmissionConfig" sudo cp -a /etc/origin/master/master-config.yaml{,.prepatch} sudo oc ex config patch /etc/origin/master/master-config.yaml.prepatch -p "$MASTER_CONFIG_PATCH" | sudo tee /etc/origin/master/master-config.yaml sudo /usr/local/bin/master-restart api sudo /usr/local/bin/master-restart controllers # sysctl vm.max_map_count=262144 on each node echo "vm.max_map_count = 262144" | sudo tee -a /etc/sysctl.d/99-elasticsearch.conf sudo sysctl vm.max_map_count=262144 # Install istio curl -LO https://raw.githubusercontent.com/Maistra/openshift-ansible/maistra-0.1.0-ocp-3.1.0-istio-1.0.0/istio/istio_product_operator_template.yaml oc new-project istio-operator oc new-app -f istio_product_operator_template.yaml --param=OPENSHIFT_ISTIO_MASTER_PUBLIC_URL=https://s310.example.com:8443 cat <<EOF | oc create -n istio-operator -f - apiVersion: "istio.openshift.com/v1alpha1" kind: "Installation" metadata: name: "istio-installation" spec: jaeger: elasticsearch_memory: 1Gi EOF
セットアップ直後の状態はこうなります。
$ oc get all -n istio-operator NAME READY STATUS RESTARTS AGE pod/istio-operator-5df6cbf496-tlrfn 1/1 Running 0 18m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/istio-operator ClusterIP 172.30.186.9 <none> 60000/TCP 18m NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.apps/istio-operator 1 1 1 1 18m NAME DESIRED CURRENT READY AGE replicaset.apps/istio-operator-5df6cbf496 1 1 1 18m $ oc get all -n istio-system NAME READY STATUS RESTARTS AGE pod/openshift-ansible-istio-installer-job-j2c6m 0/1 ContainerCreating 0 58s NAME DESIRED SUCCESSFUL AGE job.batch/openshift-ansible-istio-installer-job 1 0 58s
openshift-ansible-istio-installer-job podはAnsibleを実行しているようです。この実行が終わったらセットアップ完了で以下の状態になります。
$ oc get all -n istio-system NAME READY STATUS RESTARTS AGE pod/elasticsearch-0 1/1 Running 0 8m pod/grafana-6d5c5477-rbskl 1/1 Running 0 19m pod/istio-citadel-6f9c778bb6-trf6k 1/1 Running 0 21m pod/istio-egressgateway-957857444-dx26j 1/1 Running 0 21m pod/istio-galley-c47f5dffc-dn25p 1/1 Running 0 21m pod/istio-ingressgateway-7db86747b7-l86zp 1/1 Running 0 21m pod/istio-pilot-5646d7786b-s29kv 2/2 Running 0 21m pod/istio-policy-7d694596c6-698v5 2/2 Running 0 21m pod/istio-sidecar-injector-57466d9bb-z6vdv 1/1 Running 0 21m pod/istio-statsd-prom-bridge-7f44bb5ddb-2d75m 1/1 Running 0 21m pod/istio-telemetry-7cf7b4b77c-6vxn4 2/2 Running 0 21m pod/jaeger-agent-9f4xz 1/1 Running 0 18m pod/jaeger-collector-9c9f8bc66-7278h 1/1 Running 7 18m pod/jaeger-query-fdc6dcd74-v9t5c 1/1 Running 7 18m pod/openshift-ansible-istio-installer-job-j2c6m 0/1 Completed 0 25m pod/prometheus-84bd4b9796-wwfms 1/1 Running 0 21m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/elasticsearch ClusterIP 172.30.38.243 <none> 9200/TCP 19m service/elasticsearch-cluster ClusterIP 172.30.117.160 <none> 9300/TCP 19m service/grafana ClusterIP 172.30.182.60 <none> 3000/TCP 19m service/istio-citadel ClusterIP 172.30.169.27 <none> 8060/TCP,9093/TCP 21m service/istio-egressgateway ClusterIP 172.30.177.77 <none> 80/TCP,443/TCP 21m service/istio-galley ClusterIP 172.30.22.227 <none> 443/TCP,9093/TCP 21m service/istio-ingressgateway LoadBalancer 172.30.253.232 172.29.93.241,172.29.93.241 80:31380/TCP,443:31390/TCP,31400:31400/TCP,15011:32718/TCP,8060:30594/TCP,15030:30606/TCP,15031:32105/TCP 21m service/istio-pilot ClusterIP 172.30.111.153 <none> 15010/TCP,15011/TCP,8080/TCP,9093/TCP 21m service/istio-policy ClusterIP 172.30.49.238 <none> 9091/TCP,15004/TCP,9093/TCP 21m service/istio-sidecar-injector ClusterIP 172.30.11.70 <none> 443/TCP 21m service/istio-statsd-prom-bridge ClusterIP 172.30.48.15 <none> 9102/TCP,9125/UDP 21m service/istio-telemetry ClusterIP 172.30.72.184 <none> 9091/TCP,15004/TCP,9093/TCP,42422/TCP 21m service/jaeger-collector ClusterIP 172.30.129.165 <none> 14267/TCP,14268/TCP,9411/TCP 18m service/jaeger-query LoadBalancer 172.30.244.29 172.29.154.76,172.29.154.76 80:32087/TCP 18m service/prometheus ClusterIP 172.30.49.188 <none> 9090/TCP 21m service/tracing LoadBalancer 172.30.115.191 172.29.75.1,172.29.75.1 80:30290/TCP 17m service/zipkin ClusterIP 172.30.202.148 <none> 9411/TCP 18m NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/jaeger-agent 1 1 1 1 1 <none> 18m NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.apps/grafana 1 1 1 1 19m deployment.apps/istio-citadel 1 1 1 1 21m deployment.apps/istio-egressgateway 1 1 1 1 21m deployment.apps/istio-galley 1 1 1 1 21m deployment.apps/istio-ingressgateway 1 1 1 1 21m deployment.apps/istio-pilot 1 1 1 1 21m deployment.apps/istio-policy 1 1 1 1 21m deployment.apps/istio-sidecar-injector 1 1 1 1 21m deployment.apps/istio-statsd-prom-bridge 1 1 1 1 21m deployment.apps/istio-telemetry 1 1 1 1 21m deployment.apps/jaeger-collector 1 1 1 1 18m deployment.apps/jaeger-query 1 1 1 1 18m deployment.apps/prometheus 1 1 1 1 21m NAME DESIRED CURRENT READY AGE replicaset.apps/grafana-6d5c5477 1 1 1 19m replicaset.apps/istio-citadel-6f9c778bb6 1 1 1 21m replicaset.apps/istio-egressgateway-957857444 1 1 1 21m replicaset.apps/istio-galley-c47f5dffc 1 1 1 21m replicaset.apps/istio-ingressgateway-7db86747b7 1 1 1 21m replicaset.apps/istio-pilot-5646d7786b 1 1 1 21m replicaset.apps/istio-policy-7d694596c6 1 1 1 21m replicaset.apps/istio-sidecar-injector-57466d9bb 1 1 1 21m replicaset.apps/istio-statsd-prom-bridge-7f44bb5ddb 1 1 1 21m replicaset.apps/istio-telemetry-7cf7b4b77c 1 1 1 21m replicaset.apps/jaeger-collector-9c9f8bc66 1 1 1 18m replicaset.apps/jaeger-query-fdc6dcd74 1 1 1 18m replicaset.apps/prometheus-84bd4b9796 1 1 1 21m NAME DESIRED CURRENT AGE statefulset.apps/elasticsearch 1 1 19m NAME DESIRED SUCCESSFUL AGE job.batch/openshift-ansible-istio-installer-job 1 1 25m NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD route.route.openshift.io/grafana grafana-istio-system.apps.s310.example.com grafana http None route.route.openshift.io/istio-ingressgateway istio-ingressgateway-istio-system.apps.s310.example.com istio-ingressgateway http2 None route.route.openshift.io/jaeger-query jaeger-query-istio-system.apps.s310.example.com jaeger-query jaeger-query edge None route.route.openshift.io/prometheus prometheus-istio-system.apps.s310.example.com prometheus http-prometheus None route.route.openshift.io/tracing tracing-istio-system.apps.s310.example.com tracing tracing edge None
アプリケーションを作ってみます。Istioではinit containerでiptablesを利用するのでprivilegedコンテナにする必要があるのですが、コミュニティ版IstioをOpenShiftで利用するときにinit containerをprivilegedとしてinjectionしてくれない、という問題がありました。OpenShift製品版のIstioはprivilegedとしてinjectionしてくれるようです。
oc new-project test-istio
oc adm policy add-scc-to-user privileged -z default
oc new-app https://github.com/nekop/hello-sinatra
oc patch dc/hello-sinatra -p 'spec:
template:
metadata:
annotations:
sidecar.istio.io/inject: "true"'
namespaceのlabel istio-injection=enabledでのinjectionも軽く試してみたのですが、そちらは動作していないように見えます。OpenShiftではbuild podにinjectionされると問題となる(ビルドに必要な通信がIstioで許可されていなくて失敗するなど)ので、その関係で無効化されていそうです。
再デプロイされたpodはinit containerとproxy sidecarがinjectionされています。
$ oc get pod NAME READY STATUS RESTARTS AGE hello-sinatra-1-build 0/1 Completed 0 9m hello-sinatra-2-9p6gx 2/2 Running 0 7m $ curl hello-sinatra.test-istio.svc:8080 hello
Prometheusを開いてhello_sinatraと入力したときに各種メトリクスが見えるようになっていれば問題なく動作しています。
子供にBluetooth trackerのTile Mateを持たせてみた
いま子供が6才と4才と1才なんだけど、幼児はショッピングモールなどの人混みやちょっと大きい公園に行ったりすると、大人ができる限り気を付けていてもちょくちょく居なくなってしまう。最近近隣で知り合いの迷子事例もいくつかあり、これは気をつけるというレベルでどうにかできる問題ではなさそうなので、技術的なアプローチをとってみることにした。
キャリアが提供しているGPSとSIM付きのキッズケータイが恐らく一番良いのだろうけど、幼児にはオーバースペックだ。ということでとりあえず一番ポピュラーなBluetooth trackerのTile Mateを持たせてみた。いわゆる忘れ物防止タグ。
Tileを持たせてみる、とはいっても幼児は基本的にモノをすぐ失くしてしまうので、生で持たせるのは問題外だ。カバンやケータイは動くのに邪魔になる大きさなので遊ぶのに外してしまう可能性がある。もっとぴたっと身につけるもの、腕時計タイプのものがベストかなぁ、と思っていたところで二の足を踏んでいたんだけど上の子が年長クラスになって移動ポケットをつけるようになり、下の子も欲しがったのでこれにトラッカー仕込めばいいじゃん、ということになり早速Tile Mate 3個パックを買ったのが二ヶ月ほど前。Tileを移動ポケットに入れて、基本的な機能を説明して大事なものだからお出かけするときはおやつを一個入れて必ず移動ポケット付けてね、と教えたところきちんと実践するようになった。おやつが多分ポイント。移動ポケットにはついでに連絡先カードも入れておこう。
Tile以外にはmamorioやTrackRも良さそうだったんだけど、現時点ではTileユーザのほうが多くてカバー範囲が広そうであることと、ケータイからTileの音を鳴らす機能がある、という2点でTileを選択。
Tileは音を鳴らして子供に合図を送れる、子供がTileをダブルクリックして親のケータイを鳴らせる(4才ちゃんは鳴らして遊んでしまうことが簡単に予想されるのでこの機能は教えていない)、という2点は使い勝手が良い。Tileから鳴る音は比較的小さめなケータイの着信音程度なので、大きな音が鳴って迷惑になったりはしなさそうだけど場合によっては鳴っていることには気付かないかもしれない。移動ポケットごとタンスの中に入っていたときに、音を鳴らしてもタンスにほぼ接触するくらい近づかないと音が聞こえなかった。
一方、Tileのアプリで子供の位置はなんとなくの範囲しかわからないので、精度の高い探索はあまりできなさそうだ。Tileアプリを開けば子供が居る方向くらいわかるかなー、と思ったけど自分のケータイを中心とした円が表示されてこの範囲に居ます、みたいな表示がほとんどなので多くの場合方向もわからない。たぶんTileのBluetoothを拾った自分のケータイのGPSの位置が報告されるだけかな。Bluetoothの情報は位置補正まではしていない雰囲気がある。距離取って円の範囲は調整してるかな。Tileが自分のケータイのBluetooth範囲にあるかどうかの確認と、ちょっと遠くに行った場合や一定距離はぐれた場合などに、他のTileユーザ網に引っかかってくれればOK、程度に思っておいたほうがよさそうだ。それでも安心度は格段に違う。
Tile Mateは通信距離30mで、Tile Pro SportとTile Pro Styleは約4000円と値段が倍になるけど通信距離60m、防水、音が大きいといった利点も揃っているので子供の迷子防止ならProでもいいかもしれないなー、と思っているところ。
 EC-06001-JC-3P](https://images-fe.ssl-images-amazon.com/images/I/31LP6TIKXRL._SL160_.jpg "【Amazon.co.jp限定】Tile Mate 3個パック 落としモノ/失くしモノ防止トラッカー 携帯GPS[日本正規代理店品](1年保証付) EC-06001-JC-3P")
【Amazon.co.jp限定】Tile Mate 3個パック 落としモノ/失くしモノ防止トラッカー 携帯GPS[日本正規代理店品](1年保証付) EC-06001-JC-3P
- 出版社/メーカー: タイル
- 発売日: 2018/02/02
- メディア: エレクトロニクス
- この商品を含むブログを見る
OpenShiftでコンテナの詳細を調べる
OpenShift Origin（OKD）に、Node.jsアプリケーションをデプロイしていろいろ試すというエントリで「コンテナに引数を設定してみる」でargsを利用しているところで「ですがまあ、これは不正解な気がします。」と書いていてソース方面を見にいくという方法を取っていますが、それをOpenShift上できちんと裏付け調査する方法について書いておきます。
アプリケーションは以下のサンプルを利用しています。手元の環境ではOCP 3.9を利用していますがokd 3.10でも一緒です。
oc new-app https://github.com/sclorg/nodejs-ex
現在のコンテナで何が実行されるかはコンテナイメージメタデータのEntrypointとCmdを見る必要があります。コンテナイメージメタデータはImageStreamに入っていてImageStreamTagというvirtual objectを通して参照できるようになっています。
$ oc get istag
NAME DOCKER REF UPDATED IMAGENAME
nodejs-ex:latest docker-registry.default.svc:5000/test-nodejs/nodejs-ex@sha256:7222ec78ef8e9f84a119fece9eeb49053718e4bd7fba6d203c23ea7fe30f99f5 36 minutes ago sha256:7222ec78ef8e9f84a119fece9eeb49053718e4bd7fba6d203c23ea7fe30f99f5
$ oc export istag nodejs-ex:latest
apiVersion: v1
generation: 1
image:
dockerImageLayers:
- (省略)
dockerImageMetadata:
Config:
Cmd:
- /usr/libexec/s2i/run
Entrypoint:
- container-entrypoint
Env:
(以下省略)
ちなみにistagはvirtual objectであるせいか、oc export istagやoc get istag -o yamlというようにオブジェクト名の指定を省略した場合はコンテナメタデータなどの詳細を表示しないという挙動となるようです。上のようにoc export istag nodejs-ex:latestと指定する必要があります。ちょっとはまりました。
OpenShiftではクライアントサイドにocコマンドさえあれば、dockerなどがインストールされていなくてもこういったコンテナの詳細が調査できるのが便利です。
次にcontainer-entrypointと/usr/libexec/s2i/runは何か、という話になりますが、これはコンテナイメージ内を調査する必要があります。コンテナイメージ内の調査は場合によって以下の3種類のどれかを利用します。
- 既存のPodに
oc rsh(Entrypint, Cmdが既に実行されている状態の調査)- 例:
oc rsh dc/node-ex
- 例:
- 既存のDeploymentConfigに
oc debug(Entrypint, Cmd実行前の状態の調査)- 例:
oc debug dc/node-ex
- 例:
oc run(s2iイメージなどDeploymentConfigなどが存在しないイメージの調査)- 例:
oc run foo --image=docker-registry.default.svc:5000/test-nodejs/nodejs-ex@sha256:7222ec78ef8e9f84a119fece9eeb49053718e4bd7fba6d203c23ea7fe30f99f5 --command -- tail -f /dev/null
- 例:
今回は直接rshで問題ありません。
oc rsh dc/nodejs-ex
コンテナに入ったら必要なファイルなどを調査します。
sh-4.2$ which container-entrypoint
/usr/bin/container-entrypoint
sh-4.2$ cat $(which container-entrypoint)
#!/bin/bash
exec "$@"
$ cat /usr/libexec/s2i/run
#!/bin/bash
# S2I run script for the 'nodejs' image.
# The run script executes the server that runs your application.
#
# For more information see the documentation:
# https://github.com/openshift/source-to-image/blob/master/docs/builder_image.md
#
set -e
if [ -e "/opt/app-root/etc/generate_container_user" ]; then
source /opt/app-root/etc/generate_container_user
fi
# Runs the nodejs application server. If the container is run in development mode,
# hot deploy and debugging are enabled.
run_node() {
echo -e "Environment: \n\tDEV_MODE=${DEV_MODE}\n\tNODE_ENV=${NODE_ENV}\n\tDEBUG_PORT=${DEBUG_PORT}"
if [ "$DEV_MODE" == true ]; then
echo "Launching via nodemon..."
exec nodemon --inspect="$DEBUG_PORT"
else
echo "Launching via npm..."
exec npm run -d $NPM_RUN
fi
}
#Set the debug port to 5858 by default.
if [ -z "$DEBUG_PORT" ]; then
export DEBUG_PORT=5858
fi
# Set the environment to development by default.
if [ -z "$DEV_MODE" ]; then
export DEV_MODE=false
fi
# If NODE_ENV is not set by the user, then NODE_ENV is determined by whether
# the container is run in development mode.
if [ -z "$NODE_ENV" ]; then
if [ "$DEV_MODE" == true ]; then
export NODE_ENV=development
else
export NODE_ENV=production
fi
fi
# If the official dockerhub node image is used, skip the SCL setup below
# and just run the nodejs server
if [ -d "/usr/src/app" ]; then
run_node
fi
# Allow users to inspect/debug the builder image itself, by using:
# $ docker run -i -t openshift/centos-nodejs-builder --debug
#
[ "$1" == "--debug" ] && exec /bin/bash
run_node
起動はNPM_RUN環境変数を引数にしているようなので、これを調整するのが正解だとわかります。デフォルトの定義を調べます。
$ oc export istag nodejs-ex:latest | grep NPM_RUN
- NPM_RUN=start
というわけで、 NPM_RUN='start arg1'と設定するのがこのイメージのお作法である、で正解です。
s2iに限らず、どのようなイメージでもoc import-imageとoc runしてしまえばImageStreamとDeploymentConfigが出来るのでOpenShift上でイメージの調査ができるようになります。
Kubernetes/OpenShiftのバージョンアップとクラスタをどのように分けるか問題
Kubernetes/OpenShiftのバージョンアップをどのようにするか、およびクラスタをどのように分けるかという問題はk8s関連のmeetupでよく出る話題です。昨日のレッドハット on Cloud Dayでも出たので、現時点での自分が知っている情報や考えを書いておきます。
現時点で自分が一番しっくりくるそれなりな規模の構成はdev, testing, staging, prodの4種類を2クラスタずつ用意、8クラスタの構成です。規模によってはtesting, stagingは一つにしてしまってもいいと思います。
各ステージのクラスタ、たとえばprod1, prod2はBlue-green deploymentのような形で利用します。たとえばprod1はk8s 1.7, prod2は一つ新しいk8s 1.8となっていて、新規のデプロイは全てバージョンの新しいほうであるprod2に行います。各アプリケーションへのトラフィックはLBでprod1, prod2へ振り分けを切り換えられるように構成します。また、アプリケーションがクラスタを移動する際にストレージのPVのデータの移行がストレートにできないので、その部分は何らかの仕組みを用意する必要があります。
移行期間を置いてprod1のアプリが全部prod2へ移行されたあと、prod1のアップグレードを行ったり、もしくはクリーンに作り直して再度利用可能にし(もちろん事前にprod3を作っておいてprod1を破棄でも良い)、新規のデプロイメントはこちらにデプロイするようにします。このような2クラスタに分ける構成では、片方のクラスタで障害があっても、もう片方のクラスタにすぐデプロイできる体制ができているはずなので、バックアップとしても機能します。また、k8sのアップグレードがアプリケーションに影響しない、もしくは常にクリーンインストールを行うことでアップグレードという作業自体をなくすことができる構成になります。ワークロードはクラスタを分けても分けなくても変わらない、デプロイされているアプリの総数は変わらないはずなので、コンピューティングノードのノード数のオーバヘッドはほどんどありません。
逆にdev, test, prodのワークロードをnode selectorで分けて全部ひとつのクラスタにするという構成もあります。リソース共有の効率化、集約度向上、運用負荷が非常に軽くなるなどの利点も多くありますが、いくつか懸念があります。
- masterやetcdのバグで環境がダウンするリスク
- masterやetcdのワークロードはdev, test, prodで共有することになるので、たとえばdevでk8s APIやネットワーク帯域を利用するアプリの負荷テストなどで環境ダウンのリスク
- バージョンアップで動作しなくなる
k8sはソフトウェアなので当然バグはあります。最近のものを挙げるとmaster APIへのLBの数秒のメンテを行ったらノードが全てNodeNotReadyになってPodも全部NotReadyになるというようなクラスタごと使えなくなるようなバグもやはりあります。そのような状況を許容できる、泣かないのであればクラスタを分けないという選択肢もアリだとは思います。
もちろんクラスタを分けて複数クラスタを運用するコストも小さくはないので、どの程度のAvailabilityやResiliencyが必要かによって構成を選択しましょう。
バージョンアップの問題はさまざまです。master/etcdが起動しなくなるものや、Podのvalidationのルールが変わって以前のバージョンでは動いてたものが動かなくなったり、それらを消そうとしても新しいバージョンのvalidationに引っかかって消えないPodやnamespaceができたり、それら消えない中途半端なオブジェクトが残っているとバージョンアップのプロセスがエラーになって進まなかったり、というような感じです。根本的な解決にはetcdのデータを直接修正したり消したりというような、それなりの知識が必要かつ危険度の高いアクションが必要になることがあります。アップグレードの前に少なくともスナップショット取得、バックアップリストアは必ずテストしましょう。
あとはどのk8sを選択すればいいか、どのような運用体制が必要かという話があったのでついでに。
- Non-managed k8s
- OpenShift
- Managed k8s (GKE, AKS, EKS, etc)
- インフラ専任いらない
なぜか小規模なのにオンプレNon-managed k8sを選択してしまって大変、という話をたまに聞きますが、Managed使った方がいいと思います。オンプレk8sは立ち上げのコストが高いので、安易に手を出すと時間が溶けやすいので注意しましょう。
また、Managedを使うにしてもGKE, AKS, EKS, etc.どれを使えばいいのですか、という話もありましたが、既にどれかクラウド環境を使っているような方はManagedなデータベースなど他の機能への連携もありますしとりあえずそのままそちらのサービスを使う、ということが多いのではないかと思います。そのような前提が無いのであれば、どれを利用しても良いんじゃないかと思います。
