Actionsモチベーションcapistrano-itamaeではインテグレーションテストのためにsshできるVMが必要だったのでVagrantとDigitalOceanを使ってました。下記のような理由でCIのDockerizeをしようと考えましたVM作成にはDigitalOceanのアカウントが必要なので、第三者がPRを送る時にローカルで手軽に動作確認できない。(CIでは僕のアカウントでDigitalOceanが使えるようにしてます)リモートにVMを作るのでローカルにVMを作る場合と比べてオーバーヘッドがある不慮の事故でリモートのVMが残り続けると課金が発生するので定期的にcronでチェックする必要があるCIで毎回Vagrantのインストールするのに時間かかる。deployするのは下記エントリが参考になりました。ssh_serverのような感じでコンテナを起動した時に、CircleCIだと10000番ポートに通信できなかったためボツになりました。Dockerはそれぞれ異なる隔離された環境内で実行されます。内で稼働しているコンテナと直接やりとりすることはできません。warningが出ます。2.4以下だとエラーになります。2.4以下のサポートを切ることにしました。CIでよさそうモチベーション一番大きかったのは並列数の問題です。CIが詰まるという問題がありました。修正してビルドが通ればマージするということをやってたのですが、このTravis待ちの関係で全リポジトリでバージョン上げ終わるのにだいたい半日くらいかかっていました。ちなみに全gemでCIの設定を編集する作業は年に2〜3回発生しています。Actionsに移行しました。前にブログでも書いたのですが1リポジトリ辺り20並列というのが大きかったです。Actions移行中に気づいたのですが、実際にはGitHubのプランによる並列数の上限もあるようでした。plan.の下りです。Actionsのメリットは感じてます。ActionsでgemのCIをするための設定gemでよくある、複数のrubyのバージョンでrspecを流す設定はこんな感じです。Rubyのバージョンで差異が出てくると思いますがほぼこのyamlコピペでいけると思います。Actionsでも実装しました。(Fri)CircleCIのscheduler同様UTC指定です。使ってたのですが、下記のような不満がありました1つ目は新しいRubyのバージョンへの対応が遅いことです。見れば一目瞭然ですが新しいバージョンへの対応があまり積極的でないように見えます。gemのようにマイナーバージョンくらいまで指定すればいい場合には気にしなくてもいいかもしれないですが、ウェブアプリケーションなどで本番環境とCIでパッチバージョンまで厳密に指定したい時には致命的です。2つ目の理由は古いバージョンが突然消えることです。2.3系が突然消えたことがあります。github.com2.3系はEOLを過ぎているので仕方ないかもしれないですが、外部要因で突然全てのCIがコケるのは割とつらいです。信頼度が自分の中でなくなったので別の手法を選びました。ActionsではDockerイメージが使えるのでこれが自分の中で結構有力だったのですが、下記のようにmatrixで使えなかったのでボツになりました。Actionsのyamlは変数が使える場所と使えない場所があるっぽいです。作ったというのを見ました。使ってれば古いRubyのバージョンも消えることはないし、matrixビルドでも使えたのでこれを本格採用しました。Rubyをビルドするのに4〜5分かかるのでキャッシュ必須です。キャッシュにしました。Actionsでどうするか悩みました。有効にするようにしました。2.3以下のビルドができません。Actionsのキャッシュは同名のキャッシュキーで上書きできません。これはCircleCIと同様の方式です。コミットしないので困ります。コミットするようになってますが、dependabotでバージョンアップするコストもあるので僕はgemだと常に依存gemの最新版を常にCIで使うようにしてます。ようにして取得するようにしています。上に書いていない不満点など。Actionsだとそれがないので空コミットをpushして全部ジョブを実行しなおす必要があります。Actionsだとそのよしながないので全部自分で書く必要があります。CIでいいのでは感はあります。進捗管理について30個もあると自分でどれを対応したのか分からなくなるのでTrelloで進捗管理していました。意識していなかったんですが今年に入って1~9月まで大小色んなところで毎月登壇していました。2019の登壇ですかね。inside.pixiv.bloginside.pixiv.blog特にRubyKaigi登壇の実績ができたことでRuby界隈でも認知度がそこそこ上がって自己紹介しやすくなったというのはあります。2020のCFPネタはまだ全くありません。使い分けているのですが*2、GitHubはほぼ毎日草が生えてますhttps://github.com/sue445https://gitlab.com/sue445OSSは新規に作ったものだけで9個。sue445.hatenablog.comsue445.hatenablog.comsue445.hatenablog.cominside.pixiv.blogsue445.hatenablog.comsue445.hatenablog.comsue445.hatenablog.comsue445.hatenablog.comsue445.hatenablog.com一番反響は大きかったのは最後のplant_erdかな。余談ですがOracle対応もだいたい終わってるもののもうちょいリリースに時間かかりそうです。*4など、「どんな仕事してるんですか?」って聞かれると困るくらいには手広く色々やってます。inside.pixiv.blog推し事プリキュアで2回(計3公演)、プリパラ&プリ☆チャンで4回(計7公演)ライブに行ってました。後者が多いのは単純にライブの数が多かったため。ガァルマゲドンは推せる。dic.pixiv.net今年一番の思い出です。ザ・ファースト・ジェネレーションイベント上映やオールナイト上映とかで一度に複数本見てたりするので単純な映画の本数は把握してないんだけど、劇場に行った回数だけなら22回。*7でちょいちょい見てるのが一番多いかな。いう時会社が代々木にあるとむっちゃ便利。(会社から徒歩20分くらいなので定時ダッシュすれば夕方割の回に間に合う)キンプリはいいぞ。縁あって執筆させてもらいました。ようにする」でやっていこうと思います。11:30ブコメレスid:otherworldライセンス気にしないのかな...id:codingaloneまずライセンスでは?コピーレフトだと最悪なこになるid:jacobyGPL汚染とか怖くないのかな?重箱の隅をつつくような細かい指摘ありがとうございます!そもそもの発端が「死なないOSSを見極めるの難しいっすよね〜(なので活発にメンテされてるOSSを選ぶべき)」っていう社内での会話から雑に書き殴っただけなので、適切なライセンスが設定されてるか見るのは当たり前すぎて意識していなかったので追記しました。紙面の都合で当初のアウトラインや原稿から削った箇所があるのでアドベントカレンダーとして供養しようと思います。Runnerを使うこれはコラムで載ってはいるのですが、紙面の都合でだいぶ削ったので完全版を書きます。Runnerを自由に登録できるというのがあります。Runnerを利用してCIを行うことができます。Runnerが用意されているため通常は自分でRunnerを用意する必要はないのですが、下記のような理由でGitLab.comでもRunnerを自分で用意するメリットがあります。Runnerの順番待ち回避のためです。RunnerはGitLab.com全体で共有のため時間帯によっては待たされることもあります。そのため自分でRunnerを用意することでこの順番待ちを回避できます。Runnerとの併用もできます。2つ目の理由はデプロイ用途です。CIは社外の環境で実行してもいいけど、デプロイだけはイントラネット内からの方が都合がいいことも多いでしょう。外部からイントラネットにアクセスするための踏み台サーバを用意してもいいのですが、イントラネット内にデプロイ専用のRunnerを用意した方がセキュアで踏み台サーバ自体のメンテナンスコストも不要になるというメリットがあります。下図のようにRunnerで指定したタグをジョブにも付与することで、指定したRunnerでのみそのジョブを実行することができます。deploy3つ目の理由はCIでの非Docker環境の利用のためです。Runnerは全てDockerコンテナ内での実行が前提です。通常のCIであればこれで問題ないのですが、WindowsやMacなどのマシンのハードウェアの機能をCIで利用したいということもあるでしょう。iOSアプリのビルドをXCodeがインストールされたMac上で行いたいというのが最たる例でしょう。CIで実現可能になります。Runnerを用意する理由になりますが、これらは自前のGitLabにおいても用途によってRunnerを使い分ける指針になると思います。付録B:公式Dockerイメージを使うこちらはアウトラインには書いたものの、原稿を書く前段階で分量が多くて紙面に入らない可能性が高かったため削った内容です。Swarmでクラスタが組める場合には個人的には公式のDockerイメージを使うのもありだと思います。hub.docker.comただしGitLabを動かしているホストマシンのgitユーザのみのsshをDockerコンテナに通す方法があまり資料がないのですが、下記を参考に設定してみてください。Swarmが候補として挙げられます。Chartが公開されているのでKubernetes派の人はこれを使うといいでしょう。Pagesが使えないことです。クラウドであればEKSやGKSなどのマネージドサービスが候補として挙げられます。注意点が1つあります。EKSを使う場合同じAWSのマネージドということでデータベースでRDSを使いたくなるかもしれませんが、RDSだとデッドロックが発生する事象があるためそこだけ注意してください。こちらは実際にピクシブ社内で使っていてその運用事例を下記にまとめているので興味がある人はどうぞ。9:45モチベーション既存プロダクトへの不満が一番大きいです。2本以内の距離のテーブルまでを出力」のように、出力するテーブルを指定できる。(後述)使い方SQLite3だとこんな感じ。users出力するテーブル数の制限について例えばこういう7つのテーブルがあるとしてます。Keyで隣接する距離1以内のテーブル(つまりarticlesテーブルと直接隣接するテーブル)のみ出力することができます。技術的に頑張ったことテストのことツールの性質上MySQLやPostgreSQLといった外部のミドルウェアがないとテストができないという問題があります。するだけでローカルでMySQLとPostgreSQLを使ったテストができるようにしています。(MySQLやPostgreSQLの環境変数がセットされていなければスキップしてSQLite3のテストしかしない)あとマトリクステストを頑張ったのでDockerHubにあったMySQLとPostgreSQLのイメージの主要バージョンは全部テストしています。大学の卒論でグラフ理論をやっていたのでその時の経験を生かしてgolangで無向グラフを実装しています。*1詳しくはこの辺のソースを見てください。(途中まで行列を書いて数学的に説明を書こうとしてたけどブログウケしなさそうなのでやめた)https://github.com/sue445/plant_erd/blob/v0.1.0/db/schema_explorer.gohttps://github.com/sue445/plant_erd/blob/v0.1.0/db/undirected_graph.go複数DB対応のつらみSQLのDDLやDMLなどはSQL99で仕様化されているので多少方言はあるものの各DB間でそんなに差異はありません。plant_umlで必要なテーブル情報やインデックス情報の取得方法は各DBの実装に大きく依存していたので実装するのはかなり苦労しました。この辺に僕の苦労が詰まっています。https://github.com/sue445/plant_erd/blob/v0.1.0/adapter/mysql/adapter.gohttps://github.com/sue445/plant_erd/blob/v0.1.0/adapter/postgresql/adapter.gohttps://github.com/sue445/plant_erd/blob/v0.1.0/adapter/sqlite3/adapter.goこの辺の実装はactiverecordのconnenction_adaptersの実装をむっちゃ参考にさせてもらいました。9:45id:tinsep19schemespyでテーブルのリンク辿ると、距離1,2の関連図があるけどね重箱の隅をつつくような細かい指摘ありがとうございます。上にも書いているようにここまでリッチじゃなくていい(cliで完結したい)ってのと、gitでコミットした時に履歴が読める形式のdiffがほしいという理由でUMLで出力したいという気持ちがありました。(schemespyはサンプル見た感じ画像かsvgでしか出力してなかった。認識違ってたらまた重箱の隅をつつきにきてください)あとPlantUMLは距離1,2に関わらず任意の距離の関連図を取れるのでそこだけは優位性がありますね。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。