0時に寝て3時に起きてそのまま眠れずにいたら6時になって7時過ぎから準備してオフィス行ってお仕事を始めた。

gitlab の ci/cd の調査⌗

初めて GitLab CI/CD を触っている。まだ触り始めたばかりだが、感覚的には github actions 相当の機能はあるようにみえる。ソースコードリポジトリやパッケージリポジトリ／コンテナレジストリと ci/cd がセットになっているととても便利だ。これはすごいことだと最近思うようになってきた。もはやソースコードリポジトリのみのホスティングビジネスは成り立たない。なぜなら github や gitlab のような ci/cd が当たり前になってしまうと、その機能がない場合、デメリットを上回るメリットがないとそんなソースコードリポジトリを選択しない。

docker image をビルドして push する仕組みは既にメンバーが作ってくれていたのでその後始末の処理を作った。Container Registry API を使うと、不要な docker image を削除できる。

削除向けに便利な api 設計になっている。こういう細かい配慮は嬉しい。keep_n で最低限残すイメージ数を指定して older_than で過去何日より古いイメージを削除対象とするといったよくある運用の設定ができる。

curl -s -H "PRIVATE-TOKEN: $PROJECT_ACCESS_TOKEN" -X DELETE "${endpoint}" \
  --data "name_regex_delete=.*" \
  --data "keep_n=${KEEP_N}" \
  --data "older_than=${OLDER_THAN}"

あとは認証のトークンを指定する方法として私が調べた限りだと2通りある。

  • (ci_job_token_scope の feature flag を有効にして) $CI_JOB_TOKEN を使う
    • こっちの方が一時トークンなのでよりセキュアなはず
    • この場合はヘッダーに JOB-TOKEN を指定する
  • プロジェクトレベルのアクセストークン を発行して ci/cd の variables に登録する
    • トークンが漏洩したときにプロジェクトレベルで被害が発生する
    • この場合はヘッダーに PRIVATE-TOKEN を指定する

使うトークンによってヘッダーが変わるというのがちょっと変な認証の設計にもみえるけど、まぁそれぐらいしか気にはならない。