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/v1beta1Ingress リソースは非推奨、 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)にリプレイスした。結果がこちら。

マンションタイプで理論値最大 100Mbps のはずだから、これは驚き。

以前からたまに不調を感じていたものの放置してたけど、このご時世を反映してかここ2週間ほどは時間帯によっては一桁 Mbps しか出なくなったり、時には切断してしまったりという状態になっていた。 NTT のサポート窓口に相談してやはり混雑が原因だろうということになり、混雑が原因なら IPv6 接続に替えると改善が見込めるとのアドバイスを頂き、対応したルーターへのリプレイスとなった。

最初は IPv6 化で速くなるなんてまたまた...とか思ってたけど、調べてみると IPv6 化に伴って接続方式が PPPoE から IPoE に変わるのが効くってことなのかな?

これでまだまだ続きそうな在宅勤務体制も安心の環境になった。

ngx_mruby の動的モジュールをビルドするツール

Docker を使って ngx_mruby を動的モジュールとして手元で簡単にビルドできるようにした。

github.com

以下のようなユースケースを想定している。

  1. すでに別のモジュールを静的モジュールとしてビルドした nginx を使っている環境に新たに ngx_mruby を導入したい。
  2. ngx_mruby を運用する環境は Linux (CentOS) だが、ビルドは手元の Mac 等で行いたい。

ngx_mruby を組み込んだ nginx パッケージをビルドする類似のツールとして pepabo/ngx_mruby-package-builder があるけど、 1 のような他のモジュールも組み込む必要があるケースにはマッチしない。 2 のケースについては実行環境とビルド環境が揃っているならば、 ngx_mruby 付属のビルドスクリプトで十分。

使い方

  1. クローンしてきたら make コマンドを実行。
  2. ビルドにそれなりに時間がかかるので ☕ でも飲みながらしばし待つ。
  3. dist ディレクトリに ngx_http_mruby_module.sondk_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年も渋英のラーメン食べて健康生活。

*1:正確には 12/31 に更新できますが、東京にいない予定。

*2:系列店である渋三に行った分を足すと36回となる去年の方が多い。

エンドレスエイト

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.ymlxpack.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日経過した場合の挙動は謎(未検証)。

ここから追記

Elastic の中の人からツッコミがありまして、 6.0.0 から X-Pack がインストールされていない oss というフレーバのイメージが追加されたとのことでした。 docker.elastic.co/elasticsearch/elasticsearch-oss:6.0.0 という名前で使えるようです。 Docker レジストリのページには現時点では記載がないですが、レジストリのページにも載ってました...)ドキュメントにしっかり書いてありましたね...

www.elastic.co

X-Pack 不要な場合は最初からこれを使えば良いですね。 Elastic 社最高!