Aquaでuvを管理している状態でVscodeMCPサーバー管理からMCPサーバーを起動する

自分の環境の状態

uvはaquaで管理して、AQUA_GLOBAL_CONFIGを使ったいわゆるグローバルインストールをしている

NGなパターン

aquaがuvxを解決できずエラー

"mcp": {
    "servers": {
      "awslabs.aws-documentation-mcp-server": {
        "command": "uvx",
        "args": ["awslabs.aws-documentation-mcp-server@latest"],
        "env": {
          "FASTMCP_LOG_LEVEL": "ERROR",
        },
      }
    }

2025-04-08 13:07:55.300 [warning] [server stderr] time="2025-04-08T13:07:55+09:00" level=fatal msg="aqua failed" aqua_version=2.48.1 doc="https://aquaproj.github.io/docs/reference/codes/004" env=darwin/arm64 error="command is not found" exe_name=uvx program=aqua

OKなパターン

    "mcp": {
    "servers": {
      "awslabs.aws-documentation-mcp-server": {
        "command": "uvx",
        "args": ["awslabs.aws-documentation-mcp-server@latest"],
        "env": {
          "FASTMCP_LOG_LEVEL": "ERROR",
          "AQUA_GLOBAL_CONFIG": "/Users/<USER_NAME>/.config/aqua/aqua.yaml"
        },
      }
    }

起動時のプロセスに環境変数が渡せるので、AQUA_GLOBAL_CONFIG": "/Users/<USER_NAME>/.config/aqua/aqua.yamlを設定する

The env field allows you to specify environment variables that will be available to your MCP server process. This is particularly useful for managing API keys and other sensitive configuration.

MCPというより、aquaの設定ですね。

JavaScriptでUNIXTIME（UNIX時間）を元にDateオブジェクトを初期化する

JavaScript

注意点

  • JavaScriptのDateはミリ秒なので単位をそろえるため1000倍（1秒=1000ミリ秒）する必要がある
  • JavaScriptのDateオブジェクトは初期化にTZの引数を持たず、初期化時にシステムのTZが利用される点に注意
const unixTime = 1690862400 // 2023-08-01 13:00:00（JST）
const date = new Date(unixTime * 1000）

go install実行時の証明書エラーの対処 failed to verify certificat X509（nektos/act）

go nektos/act

シチュエーション

GitHubActionsをローカルで再現できるnektos/actを利用しているときにJobの処理でgo installを実施したときに遭遇

結論

actで実行されるubuntuコンテナにルート証明書がないのでインストールすることで対応可能 GitHub上で実行されるときは必要がないのであくまでローカル確認用

- name: Install ca-certificates
  run: |
    apt update && apt install -y ca-certificates
    update-ca-certificates

- name: Install govulncheck
  run: go install golang.org/x/vuln/cmd/govulncheck@latest

go製DBスキーマ管理ツールのgooseを検証した

go

goose（グース）と読む forkが多くあるが、今回検証しているのはpressly/goose（ガチョウのコスプレをしたGopherが可愛い

github.com

スキーマの管理方法はオーソドックスな管理テーブルにマイグレーションファイルの適用履歴を積み上げていくタイプ

主な特徴

  • Configファイル無し
  • ドライバ内包＆Go由来のシングルバイナリなので環境構築が用意
  • 本番運用に耐え得る基本的な機能はあり
  • 開発時はタイムスタンプで管理し、リリースverはインクリメンタルナンバーで管理するHybridVersioningを推している

使い勝手やGo製であるという点から競合としてsql-migrateになるか （最近利用されているのを見るsqldefは宣言的スキーマ管理というパラダイムが違うので除く）

利用方法はシンプルなので公式のREADMEなどを参照するのが一番良い

READMEになかったりする気づいた点、気になった点だけ書いていく

マイグレーションファイルを実行する以外に適用済みとすることができない

どういうことかというと、特定のマイグレーションファイルを管理対象にはしたいが色々な理由で実行はできないという場合（すでに運用されているDBのスキーマをベースラインとして登録したいなど） この場合にgooseだけでは解決できず管理テーブルに手動でマイグレーションファイルが適用済みであるというレコードをインサートする必要がある。 DjangoORMでいうfakeやflywayでいうskipExecutingMigrationsの機能といえばわかりやすい これが移行のときに非常に手間だった、ただこのシチュエーションは例外ではあるので目を瞑った

やっぱりConfigはファイルで設定できてもいいかも

自分の環境の場合殆どをMakeをタスクランナー化しCLI実行しているため、あまり問題にはならないがgooseのようにコマンドが豊富だとコマンドの数だけタスクを定義する必要があったりでやや面倒ではあった。 結果的には壊滅的な操作や細かいup/downは例外と判断し使うなら直接叩いての精神でタスク化しなかったが面倒ではある。オプションとしてConfigファイルが渡せても良いのではと思った

initのようなコマンドはなく、gooseでの初回接続時に管理テーブルが初期化される

statusコマンドなどを実行するとデフォルトではgoose_db_versionという名前で管理テーブルが作成される

version_idが0の予約されたレコードが追加されている

余談

現在gooseで検索すると上位にヒットするCyberAgentさんのブログは非常にわかりやすく有用であるが、未適用マイグレーションの扱いの挙動は現時点のverでは変わっており次の挙動となっている

  • 未適用のものがある場合マイグレーションは即座に失敗する
  • 未適用の状態はDBで管理されず、downを実行すると管理テーブルから削除される
  • --allow-migrationオプションをつけることで未適用のマイグレーションを実行することができる

管理テーブルから削除されている例 1つめのセレクトと2つめの間にdownを実行