extensions/v1beta1 Ingress から networking.k8s.io/v1 Ingress に移行する
最近バージョンアップした Kubernetes クラスタで作業していると Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
というワーニングが表示された。メッセージに書いてあるとおりだけど Kubernetes v1.14 から extensions/v1beta1
の Ingress リソースは非推奨、 v1.22 で廃止になるようだ。
言われたとおり Ingress を定義する YAML ファイルで apiVersion: extensions/v1beta1
としているところを apiVersion: networking.k8s.io/v1
と書き換えれば完了...ではなく、 API の仕様が変わっているので最新の ドキュメント (2021年05月10日現在、日本語ドキュメントは未更新)に合わせて修正する必要があった。
下に例を示したが、ざっくりと pathType
が無いとバリデーションで失敗するようになったのと、 backend
下の要素の書き方が変わったの大きな違いか。 annotations
なども変わっているのかもしれないけど、現状困っていないので調べていない。
extensions/v1beta1
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: example spec: rules: - host: example.com http: paths: - path: / backend: serviceName: example servicePort: 80
networking.k8s.io/v1
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: example port: number: 80
廃止前に気がつくことができたし、ワーニングも出なくなってメデタシメデタシ。
ngx_mruby の Docker イメージを mainline と stable に分けた
昨年から nginx の オフィシャルな Docker イメージ に ngx_mruby を動的モジュールとして追加したDocker イメージを Docker Hub に公開している。
これまで nginx または ngx_mruby がリリースされるたびにバージョンを進めたイメージをビルドしていたが、今年に入って nginx の新たな stable バージョンである 1.18.x と mainline の最新バージョンである 1.19.x がリリースされたのを機に、このイメージも Dockerfile を stable と mainline に分けて管理するようにした。
Docker のタグとしては 1.19.0-ngx_mruby2.2.3
のように直接バージョンで指定する他、 nginx のオフィシャルイメージのタグに準じて stable
, latest
でそれぞれ nginx の stable, mainline の最新バージョンと ngx_mruby の最新バージョンを組み合わせたイメージを取得できる。
これで nginx は stable のまま ngx_mruby は最新にするといった使い方ができるようになった。
自宅のルーターをリプレイスしてインターネットを取り戻した
自宅のインターネット回線が激しく不調で、もろもろ検討の結果 Wi-Fi ルーターを IPv6 対応のもの(選んだのは NEC Aterm WG1200HS3)にリプレイスした。結果がこちら。
ルーターリプレイス後の自宅インターネット、この時間帯でもわりと安定して 90Mbps 前後出てている。 pic.twitter.com/T96bzvrj0R
— やのさん、 (@yano3) 2020年5月3日
マンションタイプで理論値最大 100Mbps のはずだから、これは驚き。
以前からたまに不調を感じていたものの放置してたけど、このご時世を反映してかここ2週間ほどは時間帯によっては一桁 Mbps しか出なくなったり、時には切断してしまったりという状態になっていた。 NTT のサポート窓口に相談してやはり混雑が原因だろうということになり、混雑が原因なら IPv6 接続に替えると改善が見込めるとのアドバイスを頂き、対応したルーターへのリプレイスとなった。
最初は IPv6 化で速くなるなんてまたまた...とか思ってたけど、調べてみると IPv6 化に伴って接続方式が PPPoE から IPoE に変わるのが効くってことなのかな?
これでまだまだ続きそうな在宅勤務体制も安心の環境になった。
ngx_mruby の動的モジュールをビルドするツール
Docker を使って ngx_mruby を動的モジュールとして手元で簡単にビルドできるようにした。
以下のようなユースケースを想定している。
- すでに別のモジュールを静的モジュールとしてビルドした nginx を使っている環境に新たに ngx_mruby を導入したい。
- ngx_mruby を運用する環境は Linux (CentOS) だが、ビルドは手元の Mac 等で行いたい。
ngx_mruby を組み込んだ nginx パッケージをビルドする類似のツールとして pepabo/ngx_mruby-package-builder があるけど、 1 のような他のモジュールも組み込む必要があるケースにはマッチしない。 2 のケースについては実行環境とビルド環境が揃っているならば、 ngx_mruby 付属のビルドスクリプトで十分。
使い方
- クローンしてきたら
make
コマンドを実行。 - ビルドにそれなりに時間がかかるので ☕ でも飲みながらしばし待つ。
dist
ディレクトリにngx_http_mruby_module.so
とndk_http_module.so
ができる。
お気持ち
ngx_mruby を静的モジュールとして導入すると、後から mrbgem を追加したくなったときや、他のモジュールとの共存する場合に nginx ごとビルドし直すことになる問題があった。 ngx_mruby を動的モジュールとして導入することで、これらを ngx_mruby モジュールに閉じた問題にできるメリットがある。
2017年振り返り(渋英編)
渋英は週1回までというレギュレーション上*1、今日が今年最後の渋英のラーメンとなったので、今年渋英に行った日まとめです。
- 01/05 木
- 01/12 木
- 01/19 木
- 01/27 金
- 02/09 木
- 02/16 木
- 02/23 木
- 03/02 木
- 03/09 木
- 03/16 木
- 03/23 木
- 03/30 木
- 04/06 木
- 04/13 木
- 04/27 木
- 05/18 木
- 05/25 木
- 06/01 木
- 06/08 木
- 06/16 金
- 06/22 木
- 06/29 木
- 07/06 木
- 07/20 木
- 08/03 木
- 08/24 木
- 09/07 木
- 09/21 木
- 10/05 木
- 10/12 木
- 11/08 水
- 12/25 月
というわけで、32回でした。後半ペースが落ちたせいか、同僚らからは去年よりだいぶ減ったのではないかと言われていましたが、結果は去年の31回より多くなりました*2。推測するな計測せよ!ですね!5回行ってる月が2度あるのは、やりすぎだと思います。
木曜日率は32回中28回の 87.5% で去年の 70% と比べると安定傾向でした。
今年の渋英は6月に食券が導入されたり、今日行ったら値上げしていたりと衝撃的な出来事もありましたが、来年はどうなることやら。
2018年も渋英のラーメン食べて健康生活。
エンドレスエイト
10日ほど前に購入した iPhone 8 のちょっとした不具合に気がついてしまったので、購入した Apple Store 表参道に出向いて相談。あっさり返品対応になった。
店員さんに確認したわけではないので推測だけど、初期不良交換の期限1週間以上、返品の期限14日間未満のタイミングだったので返品になったっぽい。 iPhone 本体と AppleCare 分が返金されるのは当然として、別の日に同じ Apple Store 表参道で貼ってもらったガラスフィルム分まで戻ってきたのは意外で、 Apple Store っぽい体験だなあと思った。
すぐにまったく同じ iPhone 8 を購入して、また何か問題あって返品になったらこれぞエンドレスエイト( iPhone 8 だけに)とか考えてたけど、2周で終わってもらいたいものである。
Elasticsearch 6.0.0 の Docker イメージで X-Pack 不要なときのアレ(追記あり)
Elasticsearch 6.0.0 がリリースされていました。
Elastic 社の Docker レジストリにも 6.0.0 のイメージが来ていたのでさっそくお試し。
analysis-kuromoji
が使いたいのと X-Pack は不要なので、おもむろに下記のような Dockerfile
でビルド。
FROM docker.elastic.co/elasticsearch/elasticsearch:6.0.0 RUN elasticsearch-plugin install analysis-kuromoji RUN elasticsearch-plugin remove x-pack
Elasticsearch 5.6.x のイメージではこれで問題なかったのですが、 6.0.0 のイメージでは以下のようなエラーで Elasticsearch が起動しません。
[2017-11-15T10:41:35,496][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] [] uncaught exception in thread [main] org.elasticsearch.bootstrap.StartupException: java.lang.IllegalArgumentException: unknown setting [xpack.license.self_generated.type] please check that any required plugins are installed, or check the breaking changes documentation for removed settings at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:134) ~[elasticsearch-6.0.0.jar:6.0.0] at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:121) ~[elasticsearch-6.0.0.jar:6.0.0] at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:69) ~[elasticsearch-6.0.0.jar:6.0.0] at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:134) ~[elasticsearch-6.0.0.jar:6.0.0] at org.elasticsearch.cli.Command.main(Command.java:90) ~[elasticsearch-6.0.0.jar:6.0.0] at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92) ~[elasticsearch-6.0.0.jar:6.0.0] at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:85) ~[elasticsearch-6.0.0.jar:6.0.0]
6.0.0 のイメージに含まれる elasticsearch.yml
に xpack.license.self_generated.type
という X-Pack の設定が入ったようです。
これを回避するには、 Dockerfile
に以下のような行を加えて、 X-Pack 関連の設定を含まない elasticsearch.yml
で上書きしてビルドしてしまうか...
COPY --chown=elasticsearch:elasticsearch elasticsearch.yml /usr/share/elasticsearch/config/
もしくは、 X-Pack はアンインストールせず、 docker run
時に -e "xpack.security.enabled=false"
のような感じで、 X-Pack の不要な機能をオフにするのが良さそう。設定で X-Pack の機能をオフにする方法で、 X-Pack の試用期間である30日経過した場合の挙動は謎(未検証)。
ここから追記
6からossってのが増えてるかと。https://t.co/bTs26iW9IN
— Jun Ohtani (@johtani) 2017年11月15日
Elastic の中の人からツッコミがありまして、 6.0.0 から X-Pack がインストールされていない oss
というフレーバのイメージが追加されたとのことでした。 docker.elastic.co/elasticsearch/elasticsearch-oss:6.0.0
という名前で使えるようです。 Docker レジストリのページには現時点では記載がないですが、(レジストリのページにも載ってました...)ドキュメントにしっかり書いてありましたね...
X-Pack 不要な場合は最初からこれを使えば良いですね。 Elastic 社最高!