sitateru tech blog

Node.jsを使っていれば永遠のテーマである(?)バージョン管理ですが、皆さんはどのようにしているでしょうか。

今更ながら、ローカル環境で使用するバージョン管理を原則としてVoltaに統一する運びになったので、その背景などを書いてみたいと思います。

今までは特にバージョン管理ツールを標準で決めておらず、個人やチームでそれぞれ好きなものを使っているような状態でした。
それはそれで大きく困るようなことはなかったのですが、先日多くのリポジトリにざっといくつかの設定・アップデートをして回るようなタスクがあって話が変わりました。

それぞれのリポジトリで使っているNodeのバージョンをどこからか見つけてきて切り替えする作業を1日に何度もやるのはやはり効率が悪いしストレスですね。
バージョン管理ツールを決めて全社標準で設定してもらわないことには、私が 😇 してしまう・・・

ということで何のツールをツールを使うか検討を始めました。
今回の悩みを解消するためには、要件はこんなところです。

• 設定しておけばカレントディレクトリに応じて自動でNodeのバージョンが切り替わる
• 設定したバージョンをVCSに記録できる
• npmのバージョンも記録して自動切換えできる

ちなみに最後の条件はnpmのバージョン7がもう一般リリースされているので出てきたものです。
npm 7 is now generally available! - The GitHub Blog
それまでのバージョン6とは機能面の破壊的変更とlockファイルの変更などがあるので、これも併せてバージョン管理しておきたくなったわけですね。

さて結論ですが、Voltaを使うことにしました。
Volta - The Hassle-Free JavaScript Tool Manager
ある程度メジャーなツールで上の要件を満たすものとなるとVoltaしかなかったためです。

使うのも簡単でいい感じですね。
Voltaの使い方については詳しい記事が各地にあるのでここではあまり書きませんが、例えばNode 14, npm 6を使うなら

$ volta install node@14 npm@6
$ volta pin node@14 npm@6

とすると package.json にバージョンが書き込まれます。

{
  ...
  "volta": {
    "node": "14.15.5",
    "npm": "6.14.11"
  }
}

これをgitにコミットしておけば、自動でこのバージョンのnodeとnpmが実行されるようになります。
全リポジトリで設定されればもうバージョンを気にしなくてよくなるわけですね🤗

Nodeはもちろん、npmやその他nodeツール類のバージョン管理をしっかりやりたいという方はVoltaを一度試してみてはいかがでしょうか💁‍♂️

寒い日が続きますね。

ところで皆さんはGitHubのdependabotは使っていますでしょうか？
リポジトリをスキャンして、使っているライブラリやパッケージの脆弱性をお知らせしてくれるサービスですね。

依存関係を自動的に更新する - GitHub Docs

そのdependabotでちょっとした問題を調べて解決したので記録しておこうと思います。
題して「特定のDockerタグを無視する設定の書き方」です。
dependabotの概要や初期設定などはこの記事ではちょっと飛ばしますのでご了承ください🙇‍

dependabotはDockerタグにも対応していて、脆弱性対応された新しいバージョンタグがある場合はそれを出すようになっています。
例えばリポジトリの docker/Dockerfile をスキャン対象にする場合、コミットしておく設定ファイル .github/dependabot.yml はこのようになります。

version: 2
updates:
  - package-ecosystem: "docker"
    directory: "/docker"

さて、基本的にはdependabotはメジャーバージョンアップも含めて最新バージョンにアップデートさせるように動作するようです。
そのため、Dokerfileで node:14.x.x イメージを使っている場合

このように node:15 系にアップデートしなよ！というPRが作成されるのです。

でもNode.jsはバージョン14はLTSで15はLTSじゃない・・・更新するなら14系の最新にしてほしい！
というわけで、「Dockerタグの特定バージョンを無視する設定」を調べて入れてみました。

依存関係の更新の設定オプション - GitHub Docs

こちらのドキュメントによると、あるバージョンへの更新を無視するためにはdependabot.ymlにそのバージョンを明記すればいいのですが、

範囲を定義する場合は、パッケージマネージャーの標準パターンを使用します

Dockerタグの標準パターンって何だ・・・？🤔

結局わからなかったのでソースを見てみたところ、判定しているのはおそらくこのあたり。

dependabot-core/update_checker.rb at main · dependabot/dependabot-core · GitHub

バージョンの取り扱いに使っているのは Gem::Versionクラス のようです。

class Gem::Version (Ruby 3.0.0 リファレンスマニュアル)

ということはGemfileでバージョンを指定するのと同じ記法で良さそうですね。
dependabot.ymlはこうなりました。

version: 2
updates:
  - package-ecosystem: "docker"
    directory: "/docker"
    ignore:
      - dependency-name: "node"
        versions: ["~>15.0"]
        # nodeイメージの 15.x 系は無視

これでnodeイメージは 15.x を対象外にして更新するようになりました。
新しく作られるPRは14系の範囲でバージョンアップするものになっていますね。

今回は軽く、AWS ECR (Elastic Container Registry) の小ネタです。

AWSでコンテナを使って何かする場合ECRにコンテナイメージを保存しておくことが多いと思いますが、日ごろからイメージをよくビルド＆プッシュしているとどんどんイメージが増えていきますね。

イメージサイズがものすごく大きいとかでなければそれほど料金を食うわけでもないのですが、まず使わない古いイメージをずっと保存しておくこともないよなーと思ったのでそのあたりを設定してみました。

ECRではライフサイクルポリシーという機能があり、いろいろな条件を定めてイメージを自動クリーンアップすることができるんですね。
Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ | Amazon Web Services ブログ

設定できる条件は

• タグ
• イメージ数
• プッシュされてからの経過日数

今回は、「タグが latest ではない」かつ「プッシュされて90日以上」の条件に合うイメージを削除するポリシーを設定してみました。

AWSコンソールで設定する場合は、ECRのコンソールでリポジトリを選択して左のメニューの Lifecycle Policy をクリックすると設定画面があります。

「テストルールの編集」ボタンを押すとポリシーを適用した結果が確認できる（実際に保存されているイメージには何もしない）テスト用ページに移動するので、まずはそこで試してみるのがいいですね。

さて、ライフサイクルポリシーは「ルール」を優先順位つきで好きな数設定することで構成します。ルール作成画面はこうなっていて、一致条件は「イメージをプッシュしてから」「次の数値を超えるイメージ数」が選べます。

今回作りたい条件は「タグが latest ではない」かつ「プッシュされて90日以上」ということで、

• タグ付け済("latest")、次の数値を超えるイメージ数(1)
• すべて、イメージをプッシュしてから(90日)

という2つのルールを作ってこのようになります。

ルールを作ればあとは自動でそれに従ってイメージが毎日掃除されるので、とても楽ですね😊

ここまではコンソールで操作してきましたが、リポジトリが多い場合やコンソール面倒だと言う場合はもちろんCLIが使えます。

put-lifecycle-policy — AWS CLI 2.1.0 Command Reference

まずは先ほどのルールをJSON化して policy.json とでもファイルを作ります。

{
    "rules": [
        {
            "rulePriority": 1,
            "description": "keep latest image",
            "selection": {
                "tagStatus": "tagged",
                "tagPrefixList": ["latest"],
                "countType": "imageCountMoreThan",
                "countNumber": 1
            },
            "action": {
                "type": "expire"
            }
        },
        {
            "rulePriority": 2,
            "description": "expire images older than 90 days",
            "selection": {
                "tagStatus": "any",
                "countType": "sinceImagePushed",
                "countUnit": "days",
                "countNumber": 90
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}

今回は全リポジトリに適用したかったのでシェルスクリプトを作りました。

#!/bin/sh
# ECRリポジトリにライフサイクルポリシーを設定する

for REPO in $(aws ecr describe-repositories --query "repositories[*].{name:repositoryName}" --output text)
do
  echo "repository: $REPO"
  aws ecr put-lifecycle-policy --lifecycle-policy-text "file://policy.json" --repository-name $REPO
done

これで一括適用ができますね💪

比較的簡単に設定ができるので、「うわっ…ECRのイメージ、多すぎ…？」と気づいた際には設定してみてはいかがでしょうか。

ちなみにterraformだとaws_ecr_lifecycle_policyリソースで設定できるようです。

aws_ecr_lifecycle_policy | Resources | hashicorp/aws | Terraform Registry

 AWSやGCPの料金、たまに気になりますよね。

そういえば今月どれくらい料金食ってるんだ？と思ったとき、もちろん各サービスのコンソールで課金管理のページを開けば確認できますね。
が、日常的にはお知らせが届くほうが簡単ですむよね、ということでslackに通知をさせてみました。

AWSは簡単だったのですがGCPはちょっと手間だったのでまとめておきたいと思います。

まあエンジニアとしては課金の具合を気にせず開発に集中できれば一番いいのですが、現実には会社の予算とかいろいろありますし私は課金周りの把握をする役回りもあるので、これはやっておきたいところです。

• svc.sh でサービスを実行する
• actions-runner/bin/actions.runner.service.template ファイルを編集して /etc/systemd/system/ あたりにうまいこと設置して systemctl でコントロールする

[Unit]
Description=GitHub Actions Runner
After=network.target

[Service]
ExecStart=/usr/local/actions-runner/runsvc.sh
User=dev
WorkingDirectory=/usr/local/actions-runner
KillMode=process
KillSignal=SIGTERM
TimeoutStopSec=5min

[Install]
WantedBy=multi-user.target

runs-on: [self-hosted, linux, x64]

Cypressのテストが止まったままになる？？

module.exports = (on, config) => {
  on('before:browser:launch', (browser, launchOptions) => {
    if (browser.name === 'chrome') {
      launchOptions.args.push('--disable-dev-shm-usage')
    }
    return launchOptions
  })
}

:hover

If cy.hover() is used, an error will display and redirect you to this page.

cy.get('.hidden').invoke('show').click()
cy.get('.hidden').click({ force: true })

XPath

require('cypress-xpath')

ESLint

{
  "plugins": [
    "cypress"
  ],
  "env": {
    "cypress/globals": true
  },
  "extends": [
    "plugin:cypress/recommended"
  ]
}

Cypressだけインストールする

pull_requestのclosedイベントの場合を除く、push及びpull_requestイベントで起動されたワークフロー内のキャッシュにのみアクセスできます。