tuna’s blog (original) (raw)
この広告は、90日以上更新していないブログに表示しています。
これなに
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 呼び出し |
認証情報の保存 | ローカル環境 | 環境変数またはファイル |
参考
なにこれ
Google Cloud の Artifact Registry と Cloud Run を利用して、静的ファイルをホスティングするまでの流れをまとめたドキュメントです。
用意したファイル
FROM nginx:1.25.3
COPY index.html /usr/share/nginx/html
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 とは
ディレクトリの移動をトリガーに、自動的に環境変数をセットしてくれるツールです。リポジトリはこちら。
使い方
こちらを参考に利用しているシェルにあわせて設定情報を追記し再起動します。
環境変数を設定したいディレクトリに移動し、.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
コマンドを実行すると、環境変数を無効化することもできます。
前提
今回は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 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
kind.Workflow
Submit
- ワークフローを実行する。
Terminate
- 0個以上のワークフローを今すぐ終了する。
- 終了ハンドラの実行も許可しない。
Stop
- 0個以上のワークフローを停止し、すべての終了ハンドラの実行を許可する。
- 終了ハンドラを指定するには、
spec.onExit
でテンプレートの名前を参照する。
Delete
- ワークフローを削除する。
Retry
- 0個以上のワークフローを再実行する。
Suspend
- 0個以上のワークフローを一時停止する。
- Resume の反対の挙動。
Resume
- 0個以上のワークフローを再開する。
- Suspend の反対の挙動。
きっかけ
自分が観測する範囲の中で、何か1つでも良いから誰にも負けない(誰よりも詳しいと言える)技術スキルを持っていたい。
1つあるだけで、人材という視点での価値になり、1人のエンジニアとしての自信にも繋がる。
今すぐクビになりそうとか、将来が不安というわけではないが、今のままでは良くないという漠然とした気持ちはずっと持っていた。
技術スキルを磨くにはインプット/アウトプットのバランスが大事。
自分はアウトプットの配分が少ないタイプなので、そこを補う手段として技術ブログを始めてみようと思う。
学ぶ対象
特に決めているわけではないが、まずは普段触っている技術を基礎からちゃんと理解していく。
何となくの理解で使っている技術が多ければ多いほど、障害や無駄なコストの発生に繋がる確率が高くなる。
これからもエンジニアをやっていく覚悟の上で学んでいく。
なんで個人ブログにしたのか
ブログはアウトプットをするための手段でもありつつ、自分の知識の保管庫としても使いたかった。
Qiita や Zenn を使うという選択肢もあったが、個人ブログの方がより"自分の知識の保管庫"というイメージを持てたのが大きい。
あとは、「他の人が既に書いてるから…」という遠慮も発生しないのもある。
さいごに
今までこういう"文章を書く"という行為を習慣化できたことがない。
何故なら文章を書くのが好きではないから。
今回もいつまで続くかはわからないけど、気張らずゆるく頑張ってみようと思う。