Renovateの基本とソースコード内バージョンの更新
今回は、Renovateについて話していけたらなと思うんですけど、 この八百万のOSSでもRenovateって何回か過去の話にちょいちょい出てきたかなと思うんですけど、
改めてRenovateについてざっくりどんなものかって説明してもらってもいいですかね。 そうですね、Renovateは多分ほとんどの人はGitHubで使ってると思うんですけど、
Renovateを入れるとパッケージJSONとかGo.modとかを管理してくれて、 その使ってるライブラリーで新しいバージョンが出てきたらPRを送ってくれるっていう便利アプリケーションって思ってる人が
多いと思うし、
実際そうなんですけど、自分はなんかもっといろんな設定させてて結構便利に使ってるので、 その辺いろいろ話せればなぁと思ってます。
似たようなツールというかアプリケーションでDependabot、GitHubの公式なんですかね。 公式ですね。
Dependabotがあるけど、まあそんなようなものって考えれば似たようなものって感じですかね。基本的に同じことができるんですけど、Dependabotよりも圧倒的に設定できる機能多いと思います
ね、Renovateの方が。
じゃあRenovateの方が柔軟性が高い、設定の柔軟性が高いみたいな、ざっくりと。 そう思いますね、圧倒的に。
で、それを片杉さんはまあ普通にリゾーンパッケージとかの自動更新みたいないうのからちょっと外れて、もうちょっと便利なところでも使ってるみたいなことですかね。
そうですね、もうちょっといろんなことをやっちゃってますね。
すごい、じゃあちょっとずつそこらへんの話していけたらなぁと思うんですけど、まずどこからいきましょうか。
まあそうですね、なんかもうちょっと軽い話から入れればなと思うんですけど、まずRenovate、OSSなんで自分で入れることもできるんですけど、
GitHubの設定の問題でプリリクエスト作らせるには結構アプリケーション作らないといけなかったりとかして、結構設定するのめんどくさいんですよね。
なのでRenovate、一応無料のSaaSがあるので、そのGitHubのアプリケーション、SaaSのアプリケーションを入れてる人の方が多いかなと思ってます。
なるほど、じゃあRenovateのSaaSの、まあRenovateのサーバー側ですかね、そっちでいろいろ動いて、結果的にプリリクが作られてみたいな感じなんですね、Renovateの動きとしては。
そうですね、そうやって使ってる人が多いと思います。で、まず設定すると、設定ファイルを置くプリリクエストが作られて、それをマージするだけで、一応さっき言ったようなパッケージJSONとかGo.mod
とか、そういう言語のパッケージとか、そういうのは一応自動で管理し始めてくれますね。
便利、じゃあ結構最初から設定はデフォルトの設定でいい感じになってるっていうところなんですね。
そうですね、多くの人はここで満足する人もいっているかなと思うんですけど、例えば自分の場合、以前もエウォールズノイズセンターで紹介したEngineX Buildって言って、そのEngineXのコンパイル
をやってくれるGoのアプリケーションがあるんですけど、
このEngineX BuildはGoのソースコードの中にEngineXの最新のバージョンとか、あとEngineXっていろんなライブラリー依存してるので、その辺のバージョンとかが実はソースコードに直書
きされてるんですよ。
で、この辺が自動でバージョンアップされて欲しくて、というのも元々、EngineX Buildって自分の知り合いの人が作ったんですけど、この辺のバージョンアップを元々手動でやってたので、メンテナンスが届
こうってしまっていたんですよね。
そこで、EngineX Buildのメンテナンスを復活させたいと思った時に、この辺のバージョンアップを自動で更新してくれる仕組みができないかっていうので、リノベートを使っていろいろやった結果、基本的に
全部バージョンアップ自動でされるようになりましたよっていうところまで行ったんですよね。
なるほど。じゃあ、EngineX Buildの場合だと、パッケージ.jsonとかそういうパッケージ管理のファイルじゃなくて、ソースコード自体にバージョンの名前がハードコードされていて、そっちも更新した
かったって感じですね。リノベートを使って。
で、リノベート使えば、ソースコードの中にハードコードされたバージョンの方も追従してくれるって感じなんですね。
そうですね。結構頑張ればなんですけど。というのも、レジェックスで正規表現が設定ファイルで書けるので、正規表現で頑張って、このファイルのこういう正規表現でバージョンを引っ掛けるみたいなのを書けば、一応取
れるんですけど、まずどこからこの情報、最新バージョンの情報を取ってくるのかっていうのがまずあるんですよ。
例えばエンジンエックスビルドの場合、具体的に何ですかね。具体的な依存しているものとかあったりしますかね。
例えばGzip圧縮するためにZlibっていうのを使ってるんですけど、これは今だとGitHubのタグでできてますね。
GitHubで開発しているので、GitHubのタグでその新しいタグがついたら、その新しいタグからバージョンを取ってきて、で最新バージョンを取ってくる。
っていうのをリノベートの設定ファイルに書けるってことですね。
書けます。ただ結構ちゃんと一個一個書かないといけなくて、レポによってこの辺の規則で全然違くて。
タグをうつにしてもタグのバージョン名が違うとかそういうことですか。
そうですね。数字が2つしかないやつとあれば、数字3つ、セメバーって呼ばれてるやつもあれば、2つのバージョンしか書かれてないやつもあるし、
あとVで始まるか始まらないかとか、そういう細かい規則が言語によって微妙に違うので、その辺も全部書く必要があると。
それに関してはあれですよね。リノベート設定するときにちゃんと対象のリポジトリがどういう運用されてるのかをちゃんと見て、
このリポジトリはVってついてるし、設定語としてVってついてるし、3つのバージョンのドットが2つついてるよねみたいなところをちゃんと見ないといけないってことですね。
そうですね。そういうのを一個一個見ていく必要がありますと。
あとなんか面白い設定もいろいろ書けて、正規表現で本当にいろいろ書けるんで、例えばソースコード上にコメントでなんかそのこの1個下の行はこういう規則のバージョンですよとか、
そういうのを書けば正規表現で自動でその設定も取ってこれてで上書きできるみたいな、ちょっと口だと説明しにくいんだけど、コメントアウトでその辺のリノベートに設定渡すってこともできちゃう。
かなり自由度が高いというか、言ってしまえばなんかこの仕組みって何か対象の監視物があって、それに対する変更があったらそれをフックに何か変更させるみたいないう処理が書けるってことですよね。
そうですね。そんな感じですね。
一般的なことでちょっとまとめると。
そうですね。例えば言っちゃうと、結構GitHubのタグで取ってきてるところが多いんですけど、エンジンXビルドだと。例えばエンジンXだと、リリース-でバージョン名が来たりとか、さっき言ったZriver
Vから始まるんですけど、
PCRE2っていう正規表現のライブラリーだと、PCRE2-でバージョンが二桁だけ来るとか、本当にレポによってバラッバラなんですよ、この辺の規則が。で、そういうのを全部一個一個書いていくっていう感じの
やってますね。
これちょっと踏み込んで、もし知ってたら聞きたいんですけど、リノベート側ではこの最新があるかどうかのバージョンのチェックってもちろんしてるはずじゃないですか、サーバー側で。
何らかの定期的にサーバー側でフェッチしてでキャッシュしておいて、で最新版があるかどうかの差分を毎回見てるみたいないうイメージなんですかね、リノベート側がやってることとしては。
一応OSSの実装だと毎回見てるんですよね、毎回リクエスト飛ばして、今のバージョンをソースコードから取得してきて、で実際にフェッチしてきて、そのバージョンに差分があったらアプリリクエストを作る、で差分が
なかったら更新しなくていいって判断する。
なるほど、じゃあキャッシュとかではなくて、普通に現状の設定値と現状の最新値っていうのを見比べてっていうことをしていると。
そうですね、まあもしかしたらサーバー自社のSaaS版はなんかもうちょっとキャッシュの仕組みとかあんのかもしれないけど、OSSで単体で動かすんだったらそういう挙動しますね。
なるほど、今話してくれたのはGitHubで管理されているリポジトリの話だったじゃないですか、それ以外とかでもできたりするんですけど、例えばあるかどうかわかんないですけど、RSSとかでバージョンアップを
配信している何らかがあったらそれにも対応とかできたりするんですかね。
それで言うと、これだと多分ちょっと話すんですけど、どっかのタグとかそういうのは一応使えたりとかするし、あと多分いくつか、自分は使ってないけどいくつか使えるやつあると思いますね。
じゃあ割とそこのどうやって取ってくるかみたいないうところもある程度自由みたいなところなんですね。
そうですね、結構本当にいろんな設定あるので、自分も全然全体像を把握してないですね。
じゃあ本当に何か更新が何らかの更新があったらそれをフックに何かを処理するみたいな仕組みですね、すごい単純化すると。
かなりこの時点で自由度高そうだなというところなんですけど、それを使いつつっていうところなんですかね。
そうですね、それでじゃあ全部平和になったじゃんって思うかもしれないんですけど。
エンジンXビルドですよね。
nginxのstable版とOpenRestyの不安定なリリース
そうですね、これからいろいろ問題があって、エンジンXってメインラインとステーブルの2つのバージョンがあって、メインラインが開発版みたいな感じで、これは奇数なんですよ。
ステーブルが偶数で、これは安定版なんですね。
エンジンXビルドは安定版を指定するっていう規則になっていて、というのもメインライン版はすごい開発が激しくてバージョンもバンバン出てくる、新しいバージョンもバンバン出てくるから大変なんで更新が。
基本的にステーブル版をエンジンXビルドはデフォルトでは指定するっていう方針でやってるんですけど、こういう規則って最近は変わったのかな。
ノードジェイスも一昔前はそういう規則だったし、あとプログラミング言語のパールとかもこういう規則なんですよね。
なのでそんな珍しい規則ではないんですけど、普通にやっちゃうとメインラインの方がバージョン番号が大きいから、メインラインで来ちゃうんですよ、プレリクエストが。
新しいのがあるよっていう通知が、フックが来てしまうってことですよね。
来ちゃうけど、自分はいらないんですよね。
そこを省きたいってことですよね。
奇数だったら省きたい、偶数だったら取り込みたいってことですね。
そうですそうですそうです。それやりたくて、それってやる方法あんのかなーって考えたんですよ当時。
なんか正規表現で表現しきれるのかっていう。
そう正規表現計算式とか書けないんで、正規表現で表現できるのかなーって何分か考えたんですけど、予期を考えると偶数だから0,2,4,6,8しか来ないじゃないですか。
確かに。
そうだから正規表現で0,2,4,6,8って書けばいいのではと思って書いてみたんですよ。
そしたらなんと動いて偶数だけ来るようになりました。
だから一桁であるというルールがそこには存在するからですかね。
ラスト一桁ですね。だから1.30、今だとたぶん1.30とかかな、最新のステーブルが。
なのでその1.30だったら0だから来るっていう。1.31は更新されても1だから来ないっていう。
なるほどその一桁目ですね。一番最初の一桁目を。
一桁目だけ0,2,4,6,8って書いてそれ以外は全部0-9って書いちゃう。
頭良い解説じゃないですか。
そうこれで思いついたんですよ当時。
ちなみに当時あのチャットGPTあんま頭良くなかったのでチャットGPTにいくら聞いてもできませんって言われたんですけど、
自分が思いついてやったらできました。
まあちょっと力技解決みたいな感じですけどね。
たぶん自分がこれブログ書いたんで、たぶん今チャットGPTに聞いたら0,2,4,6,8って答えてきそうな気がするんですが、
当時はチャットGPTはわからなかったですね。
面白い。それで解決できてじゃあもうバンバン罪。
そうバンザイでエンジンXについてはなりました。
素晴らしい。
まあけどまだまだ色々問題はあって、
例えばそのオープンレスティってやつがあって、
オープンレスティはエンジンXのメインラインをベースに必要なソフトウェアを追加してリリースするっていうのがオープンレスティなんですよね。
なのでオープンレスティは、例えばなんかエンジンXの1.21.4になんか機能を足しましたってなったら、
1.21.4.1とか1.21.4.2ってやつをリリースするんですよ。
なんで最初の3つのバージョンはエンジンXのバージョンで、その後にオープンレスティのバージョンが来るんですよね。
なるほど。エンジンXとバージョンを揃えたもので、オープンレスティのバージョンが付与されてるっていうような。
そうですね。
絶対揃えないといけないっていうことですね。
このエンジンXを使ったオープンレスティですよってことを示したい。
なるほど。ってことは最新版が複数あるってことですかね。
オープンレスティ自体の最新版は基本複数はないと思うんだけど、
エンジンXの1.21.4を使ったオープンレスティを出す場合は1.21.4.1とか2とか、
そのエンジンXのバージョンの最後にまたドットなんとかって付与するんですよ、オープンレスティは。
なんでセムバーじゃないんですよね。
全部で4つ番号があるってこと?
全部で4つ番号があるオープンレスティは規則として。
そんな設定できるのかなーっていろいろ見ていったら、一応ビルドっていう設定があって、
ビルド。
4つ目、セムバーだとメジャーマイナーパッチか。
だけどパッチの後にビルドっていうのがあって、それを付与すれば一応4つ目の数字もできる。
のでオープンレスティはそのビルドってやつを使うことで対応できるようになりました。
ちなみにエンジンXのバージョンと絶対揃ってないといけないみたいな制約は付与してたりするんですかね。
そういう制約はなくて、オープンレスティがリリースしてないこともあるから、
だからそれはオープンレスティのリリースだけ見てればいいんですよ。
なるほど。
そういうルールはないですね。
じゃあ単純に最後のドットのビルドの部分だけが対応できていれば良さそう。
良さそうって思ったんですけど、これはオープンレスティ自体の問題なんですけど、
オープンレスティよくわかんなくて、リリースしたけど実はリリースされてないってことが結構あって。
それは先にバージョンだけ打つみたいな。
でも取り下げることもあるんですよ。
これやっちゃダメでしょって自分は思ってて、
何回かGitHub一周で何回か起こったんですけど、
でもあるんですよ。何でか知らないけど。
タグ打ったと思ったらしばらくしたら消えて、また別でタグ打ったりとか。
タグ打ってるけど、オープンレスティ公式サイト全然更新されなくて、バイナリーも来ないみたいな。
ってことは、同じタグのバージョンを打ってるけど、別のものが差し替えられているパターンとかも、もしかしたらあり得るかもしれない。
あり得るかもしれない。
なるほど。ちょっと不安定なんですね。リリースに関して。
これほんとやめてほしいんだけど、なぜかオープンレスティはあんま変わんないですね。
そういうオープンレスティみたいなリリースの対応みたいなことをされると、
リノベートの方では一回、例えば最新バージョンにプロリクエア上がってしまうと、
それでも固定されちゃいますもんね。ちょっとめんどくさいことになります。
一応タグ消えるとクローズされますね。
そこまでちゃんと検知してくれるんですね。
そうですね。今はCIやってるので、バージョンアップされたらそれでダウンロードして実行するので、
バイナリーが配布されてなかったらそれで気づけるんですけど、
単純にCIが落ちるだけってことですね。
そうですね。以前なんか消えたことあって、最初配ってたのに途中で消えたことあって、
最初CI通ったからマージしたのに、その後CI落ちるようになったみたいなのはありましたね。
それが困りますよね一番、そのパターン。
どういうことってなるんだけど。
それメインにリノベート使って、新しいバージョン出てオープンレステの新しいバージョン出たからメインにマージしましたってなった後に、
例えば10分後くらいにその最新版のオープンレステが消えましたと。
そしたらもうメインのブランチにマージしたんだけど、なんかCI落ちますけどみたいなことになっちゃうってことですよね。
そう、結構何回かあって、一周でやめてくれって話は何度かしたんですけど、
多分誰も見てないだろうって思ってると思うんですけど、彼らは。
だけど自分はリノベートでちゃんと自動更新してるから全部見てるんですよ。
監視してるぞと。
そう、なので自分はリノベートで自動化してるから全部見てるぞみたいな感じの主張を何回かしましたね。
なるほどね。ちなみにそれ具体的にどうやって、回避多分できないとは思うんですけど、
上の都合上消えちゃって、こっちとしてはリノベート使って監視してるけど、
もうメインにマージしてるものがもうなくなってしまってるっていうような状態になったら、
もう一回リバートして再実行するみたいなことをしないといけないってことですかね。
そうですね、手動でリバートしてますね、そういう場合は。
っていうことまでしないといけないのはしょうがないって感じですね、そこに関して。
そうですね、なのでミニマムリリースエッジっていう設定もあって、
便利設定が。
これは最近だとNPMとかでサプライチェーンアタック結構あったじゃないですか、
なのでその2日間は無視するというか、リリースされた瞬間にプレゲスト作っちゃうと、
それはサプライチェーンアタックされてるかもしれないから、
ちょっとクールダウン期間設けましょうっていうので、
今ミニマムリリースエッジ設定するっていうのが推奨されてるんですけど、
自分最初この設定使った理由はクールダウンじゃなくて、
オープンレスティがタグ打ったのにすぐ消すみたいなのが何回かあって、
それを見たくないからっていう理由で設定したんですよね。
現状の理由とは若干違うオープンレスティの特殊事情によって、
2日間ちょっと置かないと最新のやつが消える可能性あるから、
さすがに2日置いたら消えないだろうみたいな。
と思ったんだけど、消えたことはありますね。
2日後も消えるの。
2日後に来てマージしたのにその後また消えたみたいなのはありました。
厳しすぎるでしょ。
だからオープンレスティ正直何したいかよく分かんないんですけど、
今は普通にクールダウンのために入れてるんですけど、
最初に入れたときはそういう理由で入れちゃいましたね。
そういうこともあり得るよね。OSSだしねって言う。
そうですね。
ミニアムリリースエッジはクールダウンの設定なので、
これは基本今はみんな入れましょうって言われてるやつですね。
すぐに取り込まない方がいいことも絶対的にあるよねって言うと。
今サプライチェンアタックやっぱ怖いから、
基本的にすぐに取り込みたいケースの方が少ないんじゃないかな今は。
一応すぐ取り込みたい。
例えば脆弱性が出てすぐ取り込みたいとかあったら、
リノベートってギター部の一周作ってくれるんですよ。
その一周の中にそのステータスみたいなのが見れるようになってるので、
そこでポチってチェック入れれば、
ミニアムリリースエッジ無視して作ってくれる機能とかあったりするので、
このアップデートに関しては脆弱性の適用だからちょっと早めに入れるみたいなことが、
手動でできる。
一周のポチポチでできるってこと。
そうですね。
なのでミニアムリリースエッジはとりあえず設定するのがおすすめです。
入れといて例外があったらそれはちゃんと対応すればいいっていう。
そうですね。
いいですね。
なのでオープンレスティアはそういう感じで対応したって感じでしたね。
LibreSSLのstable判定を人手で承認する運用
ただね、まだあるんですよ。
HXビルドって本当にいろんなバージョン対応してるから、
LibreSSLっていう、自分が結構好きなやつって話を前にしたと思うんですが。
あれですね、Macで使われてる。
そうMacで使われてるオープンSSLですね。
このLibreSSLが厄介なのが、ステーブル版とデベロップだったかな、
開発版が区別できなくて、エンジンXみたいに偶数奇数で区別できればいいんだけど、
LibreSSLはそういうのじゃなくて、公式サイトに行ってステーブルって書いてあったらステーブルみたいな。
なるほど。バージョン番号から推測ができないですね。
ルールが存在しないんですね。
ルール存在しなくて、公式サイト行くとこれはステーブルですとかって書いてあるっていう。
なるほど。
これ困って、これはどうしようもなかったんですけど、一応ディペンデンシーダッシュボードアプローバルっていう設定があって、
この設定にしとくとさっき言ったGitHub Issueにバージョンが来たらチェックボックスが来るので、
それが来てたら公式サイトに行ってステーブルかどうか目で確認して、ステーブルだったらポチってやったらいける。
目で確認せよというようなことですね。
そうですね。その後パッチに関しては自動でアップデートするようになったので、そういう設定もできるんですよ。
1回入れたらパッチバージョンのアップデートはずっとステーブルだから、それは全部プレリクエスト自動で作ってくれると。
そのマイナーバージョンが上がるときにステーブルかどうかが変わる可能性があるので、そこだけ人間が目でやるっていうルールにしてます。
そこもできれば自動化できたら一番良かったけどもっていうところですね。リブレーションに関しては。
やりたかったんですけど、色々調べたんですけど、公式サイトにステーブルって書いてあるかどうか以外判断する方法がなさそうだったので。
機械的な判定がちょっと難しそうだったってところ。
そうですね。
やるとしたらですね、もう公式サイトスクレーピングするかぐらいしかないってことですよね。
たぶんそうですね。
その辺ちょっとまた別のやつで違うことやったので、その辺も後で紹介できればと思うんですが、リブレーションに関してはそんな感じでやりました。
private-isuの多言語リポジトリを分割更新
でね、次がですね、今度はまた別のレポで、プライベート椅子っていうレポを自分今メンテナンスしてるんですけど。
椅子コンを自分でできる。
そうですね。椅子コンの練習とかに使われているレポなんですけど、このレポもだいぶ特殊なレポで、
複数言語のウェブアプリケーションが中に入ってるんですよ。
具体的に言うと、RubyとGoとPHP、Python、Node.jsの5言語今入ってて、実装は基本的に同じアプリケーションなんですけど、
やっぱ同じアプリケーション実装が複数言語同じレポに全部入ってるみたいなレポって、まあ珍しいんですよね。
特殊すぎますよね。そんなことあり得ないですからね。
普通ないので、だいぶ特殊で、ロックファイル、Rubyだったらgemファイルロックとか、PHPのコンパザロックとか、そのロックファイルってあるじゃないですか、イズオン関係の。
その辺のロックファイルが更新されたらプレリクエスト送ってくれるんですけど、その辺が言語で混ざっちゃうと面倒くさいんですよね。
言語で混ざるというのは。
PHPとRubyで例えば一緒に来ちゃうプレリクエストが。
なるほど、同じプレリクエストでRubyの更新とPHPの更新が来てしまうみたいな。
そう来ちゃうっていうので、これプライベートイスの問題なんですけど、今CIが1言語ずつしか回らないようになっていて、
なのでその複数言語同時に更新しちゃうとCIがちゃんと回らないっていう制約があるんですよ、今のCIの問題で。
これは設定が面倒くさいからなんだけど、やっぱりちょっと特殊なレポなので、複数言語同時に更新したくないんですよね、そもそも。
なので、ちゃんと分けて言語ごとに分けた更新を適切にしたいってことですよね。
してほしいなっていうので、この辺もRenovateってほんと設定多くて、この辺もちょっと設定かけば、一応言語ごとに全部バラバラのプレリクエストにしてくれたりしますね。
一括のプレリクじゃなくて、その言語ごとにちゃんとプレリクエストを作ってよっていうような設定を切り分けるっていう感じができるんですかね。
そうですね。そういう設定もかける。そういう設定もかけたりとかするので、プライベートイスはそういうこともやってたりしますね。
便利。かなり特殊だけども。
かなりプライベートイスの特殊事業なんだけど、他のレポでこんな設定するかわかんないけど、でもRenovateはそういうのもちゃんとできる。
素晴らしい。
本当に設定がめちゃくちゃ多いんで、そういうこともできちゃうと。
自由度が高すぎる可能性は若干ありますけど。
本当に自由度高すぎて、全然、ドキュメント見ても設定多すぎてわけわかんないんですよ、正直。
なんかもうRenovateという言語なんじゃないかなみたいなぐらいの設定なんじゃないかな。
一応ね、Renovate、JSONファイルなんで設定自体は。JSONなんだけど、大変ですね。
あまりにも設定多いので、一昔前までAIが全くかけなかったんですよね。
設定が難しすぎて。
そう、設定が、ドキュメント多分AIが読み込んでなくて、全く設定昔はかけなかったんですよ。今はかけますね。
今のAIは結構Renovateの設定かけるんですけど、一昔前まで全然かけなかったですね。
そのぐらいドキュメントが長大ですね。
ルールが多いというか、自由度が高いが故にコンテキストが溢れてしまうか、ちゃんと読めてないかで、ちょっと前の、1年くらい前ですかね。
そうですね。
だったら結構難しかったって。
そう、難しかった。今はいけます。なので今はRenovateの設定ファイルはAIに書かせるのがおすすめです。
やっと追いついたというか、Renovateの時代が来ましたね、じゃあ。
そうですね。昔は結構設定書くの大変だったんですけど、今回紹介してるやつはだいたいAIがあんまり頭良くなかった時代に書いた設定が多いんですけど、今だったらだいぶAIで書かせやすくなりました。
いいですね。難しい設定も今だったらちょっとお願いすれば結構いけると。
そうですね。
で、ちょっと話を戻して、次の話ですかね。
Goの更新目的を分ける設定とRenovateの複雑さ
そうですね。これはNginx Buildだけじゃないんですけど、自分結構Goでいくつかアプリケーション作ってるんですけど、Goでやりたいこととして、複数2つあると思ってて、Goのバージョンの管理で2つ
あると思ってて、
普通にCIでGoテストとか回してるやつが新しいバージョン出たらどんどんどんどん上げて欲しいんですよ。
けど、セキュリティの設定、要はそのGoのバージョンに脆弱性がないかとか、そういうの調査したいとか、そういうCIも自分回したりするんですよ。
これって勝手にバージョンアップして欲しくなくて、勝手にバージョンアップされちゃうと、今使ってるGoのバージョンで脆弱性出た時に気付けないから。
だから、適当に上げて欲しいやつと上げて欲しくないやつ、2つ自分のGoのレポって大体あるんですね、Goのバージョンについて。
同じレポジトリの中にその2つの需要が存在してるってことですか。
そうですね。それもちょっと設定かけば分けることができて、Goセキュリティって自分はつけてるんですけど、
同じGoのバージョンなんだけど、ファイルによって2つに分けることができるようになってます。そういう設定もかけちゃいます。
なるほど、もうちょっと具体的に教えてほしいなとちょっと分かってないところがあって、同じGoのバージョンだけど複数バージョンを実行したい場合があるってことですかね。
管理を分けたい、プロリクエストを分けたいって感じですね。
なるほど、じゃあプロリクを分けて走るCIでちゃんとテストしたいっていうことですね。
GoのバージョンアップしてCI通ったら適当にマージしたいやつと、適当にマージしたくないというかリリースするタイミングでバージョンアップしたいってやつ。
2つがあるのでそれを分けたいっていうのもちょっと設定かけばできます。
便利ですね、やっぱ。自由度高いなっていう。
すごい自由度高くて本当にこういう設定もかけちゃうので、本当にすごいです。リノベートは設定かけすぎてすごいですね。
そんなリノベートですがちょっと困ったところとかもあったりするんですかね。
MySQLのLTSとInnovationリリースへの対応
困ったところは今ちょいちょい紹介したやつなんですけど、結構大きめの困ったやつだとマイスケールですね。
正直リノベートで困ったというより、自分がバージョンアップしたいソフトウェアのバージョニングが結構ルール全然バラバラなんですよ。
さっき言ってたオープンレシティでしたっけ。
オープンレシティとかもそうだし、本当にみんな思い思いのルールでやってくるので。
最近困ったのがやっぱマイスケールのバージョニングで、マイスケールがLTSっていう概念が出てきたんですよね。
あとイノベーションリリースかっていう概念も出てきたんですよ。
なので単純に、さっきのエンジンXは近いんだけど、単純にバージョンアップきたからマージしたいって感じじゃなくなったんですよね。
LTSじゃないバージョンである可能性がある。
破壊的変更である可能性があるってことですよね、そのバージョンアップが。
そういうのも来る可能性がある。
しかもバージョニングのルールがマイスケール最近変わって、以前は8.4とか、あと今だとLTS9.7もLTSなんですけど、
なんか2026年7月にリリースしたやつは26.7みたいな。
なるほど。
そのUbuntuと似たようなルールなんですけど。
年と年付きになったんですね。
急に年付きでやります、イノベーションリリースは年付きでやりますってなって。
そうすると26.7、8.4より26.7の方が大きいから26.7でプリリック届いちゃうんですよ。
LTSじゃないけど。
そうLTSじゃないけど26.7にしろってプリリック来ちゃって。
これは嫌なんですよね。
自分はLTSで指定したいっていうのがあるから来ないでほしいと。
それはそうですよね。
これすっごい困ったんですよね。
これだからさっきの話じゃないですけど公式サイトをちゃんと見るみたいな、
そういう話に近しいんじゃないのかなと思っちゃったんですけど。
そうですね。公式サイトを見るしかないのかなと思って。
例えばさっき言ったような、エンジンXの時は0,2,4,6,8って書けばいいたのししたんだけど、
これも同じで8.4系しかやりたくないんだったら8.4って書けば別に8.4系しか来ないんですよ。
現状だったらねってことですね。
そうですね。けど8.4が更新終わる可能性が当然あるわけじゃないですか。
はい、未来。
だからそれだと気づけないんですよね。
LTSの更新が止まりましたってなった時に気づく方法がない。
そうなんでこれ困ったんですよめちゃくちゃ。
このバージョニングのルールが変わる過渡期というかこの間すごく難しいですね。
そうめっちゃ難しくて。
しかも本当にソフトウェアによって本当にみんなバラバラのルールだから一個一個対応するしかないんですよ。
ちゃんと見てね。
そうこれ本当に悩んでマインスケールうまく更新できないかなって悩んで色々調べたんですけどAIも使って。
一応使えそうだのがDockerタグで26.7とかはイノベーションとかレイティストっていうタグがついていて、
今だと9.7系にはLTSってタグがついてるんですよね。
DockerHubで公開されてるマインスケールのDockerイメージのタグのところにLTSとかイノベーションとかついてるんですね。
ついていてこれ使えるんじゃないかなと思って。
一応Dockerタグもイノベーションと対応してるんですけど、
ただこの情報をDockerタグ経由で取るのはちょっと自分にはやり方わかんなかったですね。
LTSとか書いてあるところを引っ張ってくる方法が。
LTSがついてるタグが他に何のバージョン指定してるのかみたいな情報を取るのがちょっと方法が見つからなくて。
なるほど。LTSが指しているバージョンがわからなかったってことですね。解決が。
いろいろ調べたんですけど、一応DockerライブラリのGitHubにLTSとかDockerHubに設定されてるやつはテキストファイルで置かれてるんですよ。
じゃあソース元があるんですね。DockerHubの方のタグに指定しているものの。
それがあるのでそのファイルを読み込んで、
自分もこれ後で知ったんですけど、ソースコードっぽいロジック書く方法があって、
Transform Templatesっていう設定なんですけど、これ何て読むのかわかんないんだけど、JSONatorって読むのかな。
ちょっと読み方がわかんないんですけど、そういうJSONをいじる言語みたいなのを指定できるらしくて。
そこでLTSって指定されてる行のバージョンを取ってくるっていう指定ができるんですよ。
難しいことをしてますね。だからJSONの中でちょっとロジックかけるってことですよね。
ロジックかけるから、それでLTSって指定されているバージョンを取ることができると。
なのでこれまたすごいこと自分やったんだけど、とりあえず今のLTSは9.7なんですよ。
だからRenovateの設定に9.7で取ってきてくださいっていう設定をすると。
けどそのRenovateの9.7っていう設定自体が更新される可能性があるので、
Renovateの設定をRenovateで管理して、そのRenovateに書かれてる9.7っていうところをさっき言った方法で、
LTSって指定されてるやつが9.7に上に上がったら、そのRenovateの設定自身をRenovateに書き換えさせる。
なんかイバルジンしてるみたいな感じですよね。
そうですね。なんか堂々巡りしてる感じはあるんだけど。
いろいろ考えた結果、RenovateにRenovateの設定を更新させる。
そのLTSが変わったらRenovate自身にRenovateの設定を更新させることで、
2回Renovateの設定ファイルの更新がきて、それをマージしたら新しいバージョンをRenovateが取得するので、
それでMySQLのバージョンが更新できる。
なんか2回マージすればMySQLのLTSが更新できるっていう設定にできました。
なんかあれですよね。ちょっと具体的に言うと、MySQLのLTSが例えば9.8にアップデートしましたと。
そうなったら1回、このリポジトリはあれですかね。プライベートイスのやつでMySQLのやつを管理してるんですかね。
プライベートイスのプルリクエストで、一旦プライベートイスのRenovateのファイルを9.8にアップデートしたプルリクがきて、
9.8にRenovateの設定ファイルをアップデートしました。それをマージしました。
そしたらやっと9.8の更新がきますというような2段階方式ってことですね。
そうです。それで2段階で来る。
とても難しいね。
そうですね。すごい複雑なんですけど、これで一応管理できるようになりました。
だから永続的な管理ができるってことですよね。ちゃんと固定ではなくて。
Renovate自身の設定を更新するOpenSSL運用
これ全く同じ理由で、最近OpenSSLにもLTSって概念が出てきたんですよ。
今だと3.5っていうのがLTSで、最新だと4.0ってやつが出てるんだけど、これはLTSじゃないんですよ。
次4.2がLTSになるらしいんですけど、そういう感じで、一応MySQLと違って決まってはいるんだけど、
ただ4.2が本当にLTSになるかって保証なくて、こういうので突然変わったりするじゃないですか。
わかんないですよね。だからリリースされてLTSが打たれるまでわからないものですよね。
そう。なのでさっきのMySQLと似たような感じで、これもGitHubに、
この辺のこれがLTSだよみたいなのが書かれてるJSONファイルがあるので、さっきと同じような感じで、
Renovate自身を更新させることで、今は3.5系の更新しかRenovate拾ってこないんだけど、
3.5より上の4.2とかがLTSになったら、さっきと全く同じ、そのRenovate自身が4.2に書き換わって、
で、実際のソースコードでOpenSSLのバージョンが更新される、みたいなのが一応今動いてます。
とても大変なんですけど、あれですね、リリースのこのLTSの、今だったらさっきのMySQLだったら、
DockerHubって書かれているタグのソースになるGitHubのリポジトリが更新されたらわかる。
で、さっきのOpenSSL、今のOpenSSLのやつもGitHubのソースコードを見て、
で、そちらが更新されたらLTSがちゃんと写ってるっていうのがわかるっていうような、今の運用ルールだったらそうなってるけど、
これがそこの更新自体も変わる可能性ありますよね、もちろん。
そうですね、でもその辺やっぱり情報全部追えないので、自分も。ある程度自動化したかったのでこういうことやったって感じですね。
なるほど、嬉しいですね。
一応さっき言ったGitHubの一周作ってくれるので、何が今リノベート管理になっているかって簡単にわかるんですよ。
なので一応今リノベート管理にちゃんとなってるっていうことは確認できる。
ただまだこの設定してから新しいLTSがリリースされてないので、多分数年後とかになるんですけど、
本当に動くかは正直わからないけど、一応リノベート管理にはなっているので、理論上動かずみたいな感じですね。
ドキドキですね。やってきた時にLTSがアップデートされた時に、やっぱ動かなかったかみたいなそういうこともまあまああり得る。
エンジンXビルドは当時オープンSSL4.0はLTSじゃないって知らなくて、4.0マージしちゃったんだよね。
1回マージしちゃって、後で4.0LTSじゃないって気づいて3.5に戻したんだよね。
なのでそういうミスとかもあるので、基本的にエンジンXビルドはそのステーブル版をデフォルトで指定する。
一応そのオプションでバージョン指定できるから、ステーブルじゃないやつ使いたい人はそこにバージョン指定してもらうっていうポリシーなんですよね、基本的に。
だからLTSかそうじゃないかって結構重要なんですよね、特にエンジンXビルドだと。
なのでこの辺は結構悩んだ結果こうなったって感じですね。
とっても難しいことは分かっている承知で、ここら辺を聞くとやっぱりライブラリとかそういうバージョン管理、何らか大統一してほしいなって気持ちになりますね。
そうですね、例えばその5だとVってメジャーマイナーパッチか、セムバー。
Vから始めて必ずセムバーで作りましょうってルール完全に決まってるんですよね、5の場合。
みんなそのルールで作ってくれてればいいんだけど、やっぱりそれで統一されてるのって基本5だけなんだよね。
5のパッケージ、一応それは標準パッケージだけじゃなくて他の外部のサドパーティーも全部そう。
基本サドパーティーも5は基本的にVでセムバーで統一されてますね。
ただそれがノードとかでは同じノードの中でも絶対違うパッケージの命名規則もあったりするしっていうことですよね。
ノードって何ですか?
NPMでした、NPMパッケージとかね。
他の言語だと全然ルール違うこともあるし、あとNginxとかだと普通にあのCのプログラム、独立したプログラムに依存してるとかだから、本当にルールが全然バラバラなんだよね。
結構どうしようもない。自分は本当にこれやっててマジで統一してほしいなってずっと思ってたんだけど、
自動メンテナンスの効果とRenovateの限界
そういうこと言ったら自動化されないので、頑張ってイノベートで自動化できないかなって一個一個やってて、結局今Nginxビルドもプライベートイースも全部バージョンアップ勝手にされるようになったんですよ。
素晴らしい。
例えばそのプライベートイースだとアンシェブルの設定とかもあるので、アンシェブルの中にそのソースコードの最新版をバージョンで指定してダウンロードしてインストールとかもやってるんですよ。
そういうアンシェブルの中の設定とかも全部今リノベート管理になっているし、本当に全部徹底的に全自動でメンテナンスされるようにしたので、これやっぱりリノベートがなかったらそこまではできなかったですね。
素晴らしいですね。
なんかこれひるがえって、ひるがえってというか今の話だったらNginxビルドとかプライベートイースとか、実際にいろいろ使われているライブラリだったりとかリポジトリだったりするんですけど、仕事ではない
じゃないですか。
はいはい。
これは仕事とかの場合とかどうです?セキュリティ的な観点でリノベート使って、さっき言ってたクールダウン期間を置きつつもちゃんとアップデートをしていくみたいな言うのでも確実に使った方が良さそうな。
絶対使った方がいいと思ってて、そのクールダウンは絶対指定した方がいいんですけど、そのクールダウンを指定していればリノベート絶対に入れた方がいいと思ってるし、正直今特にあのフロントエンドのNPMとかって
めちゃくちゃ多いじゃないですか依存。
多い。
絶対リノベート使わないと管理できないと思うんですよ。
なんかあの忘れますよね。自動化しとかないと。
忘れる。絶対忘れるんで、だからリノベート使ってちゃんと自動でバージョンアップされるようにしておく。でもちろんクールダウンは指定しておく。これは絶対やった方がいいと思うんですよね仕事でも。
なんで自分はリノベートは結構お勧めしてるし、なんかあった時にリノベートだったら設定書けば、なんかこういう挙動させてほしいとかってあったら設定書けば多分できるのでリノベートであれば。
ぜひ使ってほしいなと思ってるし、さっき言ったそのNginx BuildとPrivateisの共通点って一時期メンテナンス放置されてたんですよ。
アップデートが滞ってた時がある。
アップデートがされなくてもう古いまま放置されてた時期があって、この2つのレポを要は放置されていたレポをどうやったらメンテナンス復活できるのかって考えた時にこのリノベートでソースコードのバージョンのア
ップデートを完全に自動でやる。
っていうのが必要だったんですよね。結局もう放置されてた実績があるからどうすればその放置されなくなるかってなるともうリノベートに全部プリリック出させるしかないってなったんですよね。
なのでそういうその放置されてたレポを復活させるって意味でもリノベートはすごく有用だったし、それってやっぱ仕事でも一緒だと思うんですよね。
リノベートのバージョンアップ放置されてたらやっぱりそれってまずライブラリのバージョンアップしましょうとかできるようにしましょうとかっていう話するじゃないですか。
とりあえず運用をちゃんとするためにね。
運用を始めましょうってなったら。なのでそういうところでもリノベート、最初にいきなり、本当にそういうケースは最初にいきなりリノベート入れるって大変だと思うんだけど、
やっぱある程度整ってきたらリノベート入れるべきだと思うし、やっぱりそういう健全なソフトウェア開発したいんだったらリノベートは第一項だと思うんですよね。
自動化する上で。
自動化してちゃんとメンテナンスし続けるんだっていうのがあればリノベートは真っ先に入れるべきだと思いますね。
ただ大前提、CEIとかでアップデートした後テストがちゃんと回るようにしておくみたいないうのはもちろん必須ですよね。
そうですね。それとプライベート椅子は昔CEIなくて、リノベートできたやつ手元で確認したりとかしたんですけど、やっぱり結構大変だったんで、やっぱりCEIがあると圧倒的に楽ですね。
なので、結構CEI作るの当時大変だったんですけど、今だとAIがあるので、もうCEI作ってリノベートが来たらちゃんとCEI実行して、それでチェックして大丈夫そうならマージっていうので運用回せるように整
えるといいんじゃないかなと思ってますね。
最低限壊れていないことを確認するテストなりビルドなりを実行するみたいなイメージですね。
最初はとりあえずビルドしてビルド通るかとかそのレベルでもいいと思うんですよね。それでも漕けるときは漕けるし、本当に簡単なところからでもいいんで、リノベート入れて簡単なCEI入れるってところからまずは始
めるといいんじゃないかなと思ってたりしますね。
いいですね。結構今回リノベートのことについて話せたかなと思うんですけど、なんか他にあったりします?
そうですね。とにかく面倒くさかったんですけど、本当に物によって違うし、しかもマイスケールは突然カルバーになりますとか言い出して、マジかよってちょっと思ったんですけど、本当にそのソフトウェアによって全然
バラバラだし、けどリノベートは設定頑張って書けば全部対応できるんですよね。
少なくともプライベートイーストやNGXビルドに関しては全部対応できた。設定は結構いろいろ書いてあるんで、興味あったらぜひ見てみてほしいんですけど、結構いろいろ書いてあるんで。でも結構頑張ればできる
んだよね、リノベート。
そんぐらい設定多いんで、大変だけど今AIで結構できるので、ぜひ興味あったらぜひ設定見てみて、こんなことできるんだって感じてほしいし、ぜひ自分たちのレポでもリノベートの設定いろいろ書いてみて、メンテナ
ンスできるようにしたらいいんじゃないかなって思ってたりしますね。
NGXビルドとプライベートイースト、今話聞いた限りでもかなり複雑な方だとは思うのでね。
そうですね。正直教えてほしくて、プライベートイースト、NGXビルドより面倒くさいことをリノベートでやってる人いたらぜひ教えてほしくて、正直見たことない、自分は見たことなくて、正直こんなにリノベートで
面倒くさいことやってるのは自分だけなんじゃないかって結構思ってたりするので、
ぜひなんか自分、我こそはもっと面倒くさいことしてるぞって人いたらぜひ教えてほしいです。いいですね。そういう事例がもしあれば、具体的な事例があれば教えてほしいですね。なんかコメントとかで、あとはIX
とかで教えていただけるとすごい嬉しいんで。
自分ずっとリノベートで頑張っていろいろこういうのやってきて、自分以外こんな面倒くさいことやってる人いるのかなって。実際結構話して思ったと思うんですけど、プライベートイースト、NGXビルドだいぶ特殊
じゃないですか。かなり特殊。
なのでリノベートないとメンテナンスできなかったし、これ以外にリノベートで面倒くさいことやらないといけないやつあんのか知りたいです。
そのぐらい面倒くさいことがもうすでにリノベートで現実できてるから、ほとんどのリポジトリというか、ほとんどのソフトウェアライブラリーに関してはもうだいたいできるから。
だいたいできるんじゃないかなと思ってて、それで言うとね唯一できないなってなったのが、ホームブリューってMacのインストールするやつだけど、ホームブリューってシャアにごろを指定しないといけないんです
よ、バイナリーの。
それ指定しないといけなくて、インストールしたいバイナリーのシャアにごろを指定しないといけなくて、それはできなかったですね。
まあ毎回ランダムで違いますもんね。
そうなんで、それは実際ダウンロードしてシャアにごろ取らないといけないんだけど、リノベートにそのシャアにごろを取るっていう指定はない。
さすがにできない。
それはできなくて、多分自分がこれまで唯一リノベートでできないって諦めたのはそこっすね。ホームブリューでシャアにごろを指定するところ。
バージョンアップできるんだけどシャアにごろ変えないと動かないのでホームブリューって。そこだけ圧倒的に持たないとダメなんですよね。
ちなみにそれはどうしたの?諦めたんですか?
それは諦めてアシェルスクリプトを一応作ったんですけど、そのリノベート単体ではできなかったですね。
まあそういうことはあるけどもっていうところですね。だから基本的にバージョニングされているものでシャアにごろみたいな形のバージョニングとかではなくて、ちゃんとバージョンでフェッチできるものというかダウ
ンロードできるものに関しては。
多分全部できる。自分が本当困ったのはそのホームブリューのシャアにごろだけっすね今のところ。それ以外に何かあればぜひ教えてほしい感じはありますね。
これめちゃくちゃ面倒くさかったぞっていう人これ聞いてる人の中にいるかどうかわかんないんですけど本当にいたら絶対に何かしらで教えてください。
自分以外にリノベートでこんな頑張ってる人いたら教えてほしいです。
もういたら仲間ですね。
じゃあ結構いい時間になってきたので今回はここまでにしたいなと思います。
ヤウヨルズのOSSでは毎回一つのOSSを取り上げてそれについて片付いてエンテコで技術的なところも深掘りしながら話をしていく番組です。
今後もその名の通りヤウヨルズのOSSを取り上げていけたらなと思ってますので、ぜひお聞きのプラットフォームでフォローと高評価の方をお願いします。
またこのOSSについても取り上げてほしいとか何かありましたらコメントやXなどで教えていただけると嬉しいです。
番組についての感想もお待ちしております。
Xなどでつぶやく際にはハッシュタグヤウヨルズのOSSをつけてくださると見つけやすくなるのでよろしくお願いします。
それでは今回もありがとうございました。