tuna’s blog

でーたえんじにゃ

gcloud auth コマンドを理解したい

Google Cloud

これなに

Google Cloud を利用して環境構築を行う際に、何気なく実行しているgcloud authコマンドについて、理解を深めるためにあれこれ調べたことを残したドキュメントです。

そもそもgcloudコマンドとは

Google Cloud のリソースをコマンドラインから直接操作するためのツールです。

gcloud authコマンドとは

Google Cloud のプロジェクトにアクセスするための認証情報を管理するコマンドです。 プロジェクト内のリソースにアクセスしたり操作するには、事前に認証を行う必要があります。 この認証処理をコマンドラインから実行できるのが、gcloud authコマンドです。

gcloud auth loginとgcloud auth application-default loginの違い

gcloud auth loginは、ブラウザから権限を持つ Google アカウントにログインすることで、gcloud コマンドに認証情報を付与することができます。 複数の Google アカウントやプロジェクトを切り替えて利用したい場合に便利です。

gcloud auth application-default loginは、スクリプトやアプリケーションから Google Cloud の API を呼び出す際に、自動的に認証を行いたい場合に使用します。

項目 gcloud auth login gcloud auth application-default login
認証方法 ブラウザによる対話型 サービスアカウントの JSON キーファイルによる
利用シーン コマンドラインからの操作 アプリケーションからの API 呼び出し
認証情報の保存 ローカル環境 環境変数またはファイル

参考

blog.g-gen.co.jp

Artifact Registry x Cloud Run でホスティングする

Docker Google Cloud

なにこれ

Google Cloud の Artifact Registry と Cloud Run を利用して、静的ファイルをホスティングするまでの流れをまとめたドキュメントです。

用意したファイル

FROM nginx:1.25.3

COPY index.html /usr/share/nginx/html
hello world

Artifact Registry にコンテナイメージをプッシュする

Cloud Run のCPUアーキテクチャは"x86_64"であるのに対して、Apple Silicon 上でビルドしたイメージは"arm64"になるため、このまま Cloud Run でデプロイするとエラーになってしまうようです。 docker buildでコンテナイメージを作る際に、--platform linux/amd64オプションを追加することで回避しています。

$ docker build -t asia-northeast1-docker.pkg.dev/{ プロジェクト名 }/{ Cloud Run のサービス名 }/nginx-image:latest --platform linux/amd64 .
$ docker push asia-northeast1-docker.pkg.dev/{ プロジェクト名 }/{ Cloud Run のサービス名 }/nginx-image:latest

Cloud Run でサービスをデプロイする

先ほど作成した Artifact Registry のイメージを選択してデプロイします。 この際、ポートを80に指定しないとエラーになりました。(nginx のデフォルトポートが80なのかな？よくわかっていない)

direnv でディレクトリごとに環境変数を変更してみる

Shell

direnv とは

ディレクトリの移動をトリガーに、自動的に環境変数をセットしてくれるツールです。 リポジトリはこちら。

使い方

こちらを参考に利用しているシェルにあわせて設定情報を追記し再起動します。

環境変数を設定したいディレクトリに移動し、.envrcファイルを作成します。 例として、$HOGE という環境変数に"fuga"という値を持たせたい場合、.envrcに以下の内容を記載します。

export HOGE=fuga

なお、内容によっては機密情報に当たる可能性があるため、外部に漏らさないためにも.gitignore等に.envrcを追加しておきましょう。 保存したら、適用されているかを確認してみましょう。

$ echo $HOGE

もし、direnv: error .envrc is blocked. Run direnv allow to approve its contentというエラーが起きたら、メッセージの通りdirenv allowを実行することで解消できます。

また、direnv denyコマンドを実行すると、環境変数を無効化することもできます。

Lightdash 環境構築編

Lightdash BI Data

前提

今回はOSS版の Lightdash を利用していきます。 環境構築で必要なコマンド等は事前にインストールしている前提で記載しています。

Lightdash のインストール

$ git clone https://github.com/lightdash/lightdash
$ cd lightdash
$ ./scripts/install.sh

割と容量のあるリポジトリのため、ネット回線の速度によってはクローンに失敗することがあります。(ありました) 比較的回線が落ち着いたタイミングで再度クローンすることで解消できたのですが、クローンするデータ量を少なくする方法もあるようです。

セットアップ方法としてFast installとCustom installの2種類が用意されています。

Fast installは GitHub もしくは GitLab に存在する dbt プロジェクトに接続するパターンで、Custom installはローカル環境にある dbt プロジェクトに接続するパターンのようです。 今回はGitHub に適当に用意した dbt プロジェクトがあったので、Fast installを選びました。

++++++++++++++++++ SUCCESS ++++++++++++++++++++++

🟢 Your installation is complete!

🟢 Your frontend is running on http://localhost:8080

ℹ️  To restart Lightdash: docker compose -f docker-compose.yml start
ℹ️  To stop Lightdash: docker compose -f docker-compose.yml stop -v
ℹ️  To bring down Lightdash and clean volumes: docker compose -f docker-compose.yml down -v

+++++++++++++++++++++++++++++++++++++++++++++++++

が表示されたらインストール成功です。 http://localhost:8080 にアクセスすると、Lightdash のログインページが表示されるかと思います。

またその下の説明の通り、docker composeコマンドを通して再起動や停止等も行うことができます。

Lightdash プロジェクトのセットアップ

必要事項を入力して進めていきましょう。

DWH は BigQuery を選択しました。

セットアップ方法として CLI か手動かの2種類が用意されています。 今回は CLI の方法で進めていきます。

が、その前に node のバージョンが古いと({"node":"^18.17.0 || >=20.5.0"}) npm install でコケるため、nvm をインストールした上で node のバージョンを上げておきます。

$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
$ source ~/.zshrc
$ nvm ls-remote
$ nvm install 19.9.0
$ nvm current

Ligthdash CLI をインストールしてセットアップを進めていきます。

$ npm install -g @lightdash/cli@0.1295.3
$ lightdash login http://localhost:8080 --token {token}
$ cd {dbt_project.yml が存在するディレクトリ}
$ lightdash deploy --create

最後のコマンドを実行すると、いくつか質問が出てくるので答えていきます。 全て回答するとURLが表示されるのでアクセスしましょう。 以下の画面になればセットアップは完了です。

Gitでよく出てくる"origin"とは

Git 
$ git push origin main
$ git pull origin main

で出てくる"origin"というワード。 おまじないのように使っていたけど、ちゃんと理解したくなったので調べてみました。

結論

"origin"とは、接続しているリモートリポジトリの名前でした。(エイリアスみたいなもの？) 先程のコマンドを日本語にしてみると、

# リモートリポジトリ(origin)に"main"ブランチをプッシュする
$ git push origin main

# リモートリポジトリ(origin)の"main"ブランチの内容で、ローカルリポジトリの"main"ブランチを更新する
$ git pull origin main

となります。

どこで設定されているの？

例えば GitHub に"hoge/fuga"というリモートリポジトリを作成したとします。 最初に以下のようなコマンドの実行を推奨されるのですが、その中にあるgit remoteの実行によって"origin"という名前でリモートリポジトリの追加が行われます。

echo "# test" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin git@github.com:k-0120/test.git
git push -u origin main

Argo Workflows の操作ごとの挙動を理解する

Argo

kind.Workflow

Submit

argo-workflows.readthedocs.io

  • ワークフローを実行する。

Terminate

argo-workflows.readthedocs.io

  • 0個以上のワークフローを今すぐ終了する。
  • 終了ハンドラの実行も許可しない。

Stop

argo-workflows.readthedocs.io

  • 0個以上のワークフローを停止し、すべての終了ハンドラの実行を許可する。
  • 終了ハンドラを指定するには、spec.onExitでテンプレートの名前を参照する。

Delete

argo-workflows.readthedocs.io

  • ワークフローを削除する。

Retry

argo-workflows.readthedocs.io

  • 0個以上のワークフローを再実行する。

Suspend

argo-workflows.readthedocs.io

  • 0個以上のワークフローを一時停止する。
  • Resume の反対の挙動。

Resume

argo-workflows.readthedocs.io

  • 0個以上のワークフローを再開する。
  • Suspend の反対の挙動。

技術ブログをはじめてみる

日記

きっかけ

自分が観測する範囲の中で、何か1つでも良いから誰にも負けない(誰よりも詳しいと言える)技術スキルを持っていたい。

1つあるだけで、人材という視点での価値になり、1人のエンジニアとしての自信にも繋がる。

今すぐクビになりそうとか、将来が不安というわけではないが、今のままでは良くないという漠然とした気持ちはずっと持っていた。

技術スキルを磨くにはインプット/アウトプットのバランスが大事。

自分はアウトプットの配分が少ないタイプなので、そこを補う手段として技術ブログを始めてみようと思う。

学ぶ対象

特に決めているわけではないが、まずは普段触っている技術を基礎からちゃんと理解していく。

何となくの理解で使っている技術が多ければ多いほど、障害や無駄なコストの発生に繋がる確率が高くなる。

これからもエンジニアをやっていく覚悟の上で学んでいく。

なんで個人ブログにしたのか

ブログはアウトプットをするための手段でもありつつ、自分の知識の保管庫としても使いたかった。

Qiita や Zenn を使うという選択肢もあったが、個人ブログの方がより"自分の知識の保管庫"というイメージを持てたのが大きい。

あとは、「他の人が既に書いてるから…」という遠慮も発生しないのもある。

さいごに

今までこういう"文章を書く"という行為を習慣化できたことがない。

何故なら文章を書くのが好きではないから。

今回もいつまで続くかはわからないけど、気張らずゆるく頑張ってみようと思う。