4件の投稿件の投稿が「cli」タグ付き

概要​

最高のアプリを紹介した前回の記事に続いて、Command Line Interface（以下CLI）のおすすめツールを見ていきます。今回紹介するツールは全て、筆者が最低6ヶ月以上使用しており、新しい環境をセットアップする際に必ず導入しているものです。

zoxide​

GitHub - ajeetdsouza/zoxide: A smarter cd command. Supports all major shells.

一度でも訪れたディレクトリのパスを覚える必要がなくなるツールです。例えば以下のような場合です：

cd ~/.config/somewhere/longlong/path

# 次回からは以下のコマンドで直接アクセス可能
z path

これは非常に便利で、特定の設定ファイルがどこにあるかを覚えておく必要がなくなります。ziを使用すると優先順位リストが表示され、ファジー検索も可能です。

一度使うと、このツールを使用する前には戻れなくなるでしょう。

mise​

GitHub - jdx/mise: dev tools, env vars, task runner

各種環境変数や言語、パッケージのバージョンマネージャーです。構造的に非常に安定性が高く、Rustで実装されているため速度も速いです。直感的なコマンドにより、学習曲線が大幅に緩和されています。

既に本ブログで記事として紹介するほど、非常に愛用しているツールです。miseの役割を果たす類似ツールは他にもありますが、個人的にはその中で最もおすすめできると考えています。例えば、direnvはmiseで完全に代替可能で、nixは過度に複雑で汎用性が低いです。

様々な言語を扱うプログラミングマルチリンガルであれば、ぜひ試してみてください。

chezmoi​

chezmoi

複数のデバイスを使用している場合、開発環境の同期は非常に面倒です。特にCLIを頻繁に使用する開発者にとってはなおさらです。

完全に同期を諦めるつもりでなければ、どのように同期できるか悩んでいる場合はchezmoiを試してみてください。新しい機器を購入しても、初期設定に時間を費やす必要がなくなります。

miseと同様に、本ブログに使用方法に関する記事がありますので参考にしてください。

fzf​

GitHub - junegunn/fzf: :cherry_blossom: A command-line fuzzy finder

GitHubスター約70k、これ以上の説明が必要でしょうか（参考までに、spring-frameworkは57kです）。

韓国人開発者のjunegunn氏が管理するオープンソースのファジーファインダーで、標準入出力パイプラインを通じて驚異的な汎用性を誇ります。

**検索が必要な場合、種類に関係なくfzfを使えば良いです。**様々なパッケージが利用しているため、fzfの存在を知らなくても、既に間接的に使用していた可能性があります。

fd​

GitHub - sharkdp/fd: A simple, fast and user-friendly alternative to 'find'

findコマンドを代替します。

Rustで作成されており、findと比べて最大50%速いとされています。ハイライトも綺麗で、コマンドオプションもfindよりもはるかに直感的です。

ripgrep​

GitHub - BurntSushi/ripgrep: ripgrep recursively searches directories for a regex pattern while respecting your gitignore

grepコマンドを代替します。名前はripgrepですが、コマンドはrgを使用します。

fdと同様に、Rustで作成されています。grepと比べて、出力からより多様な情報を得ることができます。コマンドも直感的で使いやすく、速度も速いため、使わない理由がありません。

まさに'RIP, grep'です。

lsd​

GitHub - lsd-rs/lsd: The next gen ls command

lsコマンドを代替します。

lsコマンドは非常によく使用されるコマンドです。コマンド自体は古いものですが、出力から得られる情報は多くありません。lsdを使用すると、既存のlsを完全に代替することができます。

bat​

GitHub - sharkdp/bat: A cat(1) clone with wings.

catコマンドを代替します。

catコマンドは単純な出力ですが、batを使用するとコードハイライトを楽しむことができます。 ある程度目の利く開発者なら、行出力がシェルパイプラインを妨げるのではないかと心配するかもしれませんが、 全く妨げません。心配せずに新しい技術を楽しみましょう。

筆者はbatコマンドのエイリアスをcatに設定して使用しています。

HTTPie​

HTTPie – API testing client that flows with you

curlを代替します。

アプリ版もあるためどちらの記事に含めるべきか悩みましたが、個人的にはCLIでのみ使用しているため、こちらの記事に含めました。

なぜcurlの代わりにHTTPieを好むかというと、非常に直感的だからです。簡単なGETリクエストは以下のように送信できます：

https httpie.io/hello

レスポンスは以下のようにフォーマットされて返ってきます：

curlのレスポンスを思い出してみてください。開発者も綺麗なものが好きです。

Orbstack​

OrbStack · Fast, light, simple Docker & Linux

Docker Desktopを代替します。

Dockerコンテナを使用する際に少し速くなり、いくつかのバグも解消されます。しかし、本当の真価はVMを使用する際に発揮されます。従来VMの使用が難しかったMacでも、非常に軽量にVMを実行できます。UbuntuやKali Linuxなどのテストが必要な場合、orbstackを使用すると非常に高速で便利に管理できますので、試してみてください。個人的に非常に面白い経験でした。

atuin​

GitHub - atuinsh/atuin: ✨ Magical shell history

chezmoiを使用すると使用するツールの設定は同期できましたが、atuinを使用すると会社で使用したコマンド履歴を同期できます。もう会社で使用したコマンドが何だったか思い出そうと苦労する必要はありません。

atuin history list | fzf

trash-cli​

ターミナルに「ゴミ箱」機能を実装します。したがって、もうrm -rf /を恐れる必要はありません。いつでも復元が可能だからです。

開発者最大の敵であるrm -rf /から解放されるというのに、それ以上の理由が必要でしょうか？

まとめ​

ここまで、個人的に非常に気に入っている様々なツールを紹介してきました。

実際、これ以外にもおすすめできるツールはいくらでもありますが、誰かが何をおすすめしても、自分の手に馴染んだものが一番良いものです。残りは自分の環境に合わせて探して使ってみましょう。

状況​

• コードベースが成長するにつれて、Springアプリケーションを実行するために必要な設定値の数が増加しています。
• ほとんどの状況はテストコードで検証されますが、ローカルでbootRunを使用してテストする必要がある場合もあります。

問題点​

• 設定値を環境変数に分離して管理したい。
• .envファイルは通常Gitで無視されるため、バージョン管理が難しく、断片化しやすい。
  • 複数のマシン間でファイルを同期する方法が必要です。

質問​

• 開発者間の摩擦を最小限に抑え、簡単に適用できる便利な方法はありますか？
  • メンテナンスが容易な、馴染みのある方法が望ましいです。
• .envファイルのバージョン管理は可能ですか？
• 学習曲線は低いですか？
  • 解決策が問題よりも複雑になる状況は避けたいです。
• 本番環境に直接適用できますか？

回答​

AWS S3​

• AWS CLIを使用して.envファイルを更新するのは便利です。
• .envファイルのバージョン管理はスナップショットを通じて行えます。
• AWS S3は多くの開発者に馴染みがあり、学習曲線が低いです。
• AWS ECSの本番環境では、S3 ARNを使用してシステム変数を直接適用できます。

.

..

...

....

それだけですか？​

それだけだと、記事が少し退屈に見えるかもしれませんね？もちろん、まだいくつかの問題が残っています。

どのバケットにあるのか？​

S3を使用する際、ファイル構造の最適化やビジネス特有の分類のために多くのバケットが作成されることが一般的です。

aws s3 cp s3://something.service.com/enviroment/.env .env

もし.envファイルが見つからない場合、上記のようにAWS CLIを使用してダウンロードする必要があります。事前に誰かがバケットを共有してくれない限り、環境変数ファイルを見つけるためにすべてのバケットを検索する必要があり、不便です。共有を避けるつもりでしたが、再度共有するために何かを受け取るのは少し面倒に感じるかもしれません。

バケットが多すぎる。envはどこにあるのか？

S3内のバケットを探索して必要な.envファイルを見つけてダウンロードするプロセスを自動化すると、非常に便利です。これはfzfやgumのようなツールを使用してスクリプトを書くことで実現できます。

Spring Bootはシステム環境変数を必要とし、.envではない...​

一部の方はすでにお気づきかもしれませんが、Spring Bootはシステム環境変数を読み取ってYAMLファイルのプレースホルダーを埋めます。しかし、単に.envファイルを使用するだけではシステム環境変数が適用されず、Spring Bootの初期化プロセス中に拾われません。

簡単にその仕組みを見てみましょう。

# .env
HELLO=WORLD

# application.yml
something:
    hello: ${HELLO} # OSのHELLO環境変数から値を取得します。

@Slf4j
@Component
public class HelloWorld {

    @Value("${something.hello}")
    private String hello;

    @PostConstruct
    public void init() {
        log.info("Hello: {}", hello);
    }
}

SystemEnvironmentPropertySource.java

@Valueのプレースホルダーが解決されず、Beanの登録が失敗し、エラーが発生します。

単に.envファイルがあるだけでは、システム環境変数として登録されません。

.envファイルを適用するには、exportコマンドを実行するか、IntelliJの実行構成に.envファイルを登録する必要があります。しかし、exportコマンドを使用してローカルマシンに多くの変数をグローバルに登録すると、上書きなどの意図しない動作が発生する可能性があるため、IntelliJのGUIを通じて個別に管理することをお勧めします。

IntelliJはGUIを介して.envファイルの設定をサポートしています。

プレースホルダーが解決され、正しく適用されました。

最終回答 - 本当の最終回答​

ふう、問題の特定と範囲設定の長いプロセスが終わりました。もう一度ワークフローをまとめ、スクリプトを紹介しましょう。

1. 自動化スクリプトを使用して、S3から適切な.envファイルを見つけてダウンロードします。
2. .envをシステム環境変数として設定します。

シェルスクリプトはシンプルでありながら、gumを使用してスタイリッシュに書かれています。

フルコード

#!/bin/bash

S3_BUCKET=$(aws s3 ls | awk '{print $3}' | gum filter --reverse --placeholder "Select...") # 1.

# デプロイ環境を選択
TARGET=$(gum choose --header "Select a environment" "Elastic Container Service" "EC2")
if [ "$TARGET" = "Elastic Container Service" ]; then
    TARGET="ecs"
else
    TARGET="ec2"
fi

S3_BUCKET_PATH=s3://$S3_BUCKET/$TARGET/

# envファイルを検索
ENV_FILE=$(aws s3 ls "$S3_BUCKET_PATH" | grep env | awk '{print $4}' | gum filter --reverse --placeholder "Select...") # 2.

# 確認
if (gum confirm "Are you sure you want to use $ENV_FILE?"); then
    echo "You selected $ENV_FILE"
else
    die "Aborted."
fi

ENV_FILE_NAME=$(gum input --prompt.foreground "#04B575" --prompt "Enter the name of the env file: " --value ".env" --placeholder ".env")
gum spin -s meter --title "Copying env file..." -- aws s3 cp "$S3_BUCKET_PATH$ENV_FILE" "$ENV_FILE_NAME" # 3.

echo "Done."

1. gum filterを使用して、目的のS3バケットを選択します。
2. envという単語を含むアイテムを検索し、ENV_FILEという変数に割り当てます。
3. .envファイルのオブジェクトキーを最終決定し、ダウンロードを進めます。

実行プロセスのデモビデオを作成しました。

デモ

これが終わったら、先ほど述べたように、現在のディレクトリにコピーされた.envファイルをIntelliJに適用するだけです。

結論​

• スクリプトはシンプルであるため、メンテナンスが容易です。
• チームの反応は非常に良好です。
• 開発者は美学を評価しています。
• 機密性の高い資格情報については、AWS Secret Managerの使用を検討してください。

概要​

GoogleのCloud Shellを通じてウェブからどこでもkubectlを実行できるのは非常に便利ですが、簡単なクエリコマンドのためにウェブアクセスと認証を行う手間がかかるという欠点があります。この記事では、ローカルCLIを使ってGoogle Cloud Kubernetesを迅速に管理する方法を紹介します。

目次​

GCP CLIのインストール​

まず、GCP CLIをインストールする必要があります。適切なオペレーティングシステムを確認し、インストールするためにgcp-cliリンクを参照してください。

接続​

インストールが完了したら、以下のコマンドを使用して認証プロセスを進めます。

gcloud init

GCP Kubernetes Engineにアクセスし、クラスターの接続情報を取得する必要があります。

コマンドラインアクセス用のコマンドをコピーし、ターミナルで実行します。

gcloud container clusters get-credentials sv-dev-cluster --zone asia-northeast3-a --project {projectId}

Fetching cluster endpoint and auth data.
CRITICAL: ACTION REQUIRED: gke-gcloud-auth-plugin, which is needed for continued use of kubectl, was not found or is not executable. Install gke-gcloud-auth-plugin for use with kubectl by following https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke
kubeconfig entry generated for sv-dev-cluster.

プラグインのインストール​

現在使用しているKubernetesのバージョンがv1.26未満の場合、gke-gcloud-auth-pluginのインストールを要求するエラーが発生することがあります。以下のコマンドを使用してプラグインをインストールします。

gcloud components install gke-gcloud-auth-plugin

Your current Google Cloud CLI version is: 408.0.1
Installing components from version: 408.0.1

┌────────────────────────────────────────────┐
│    These components will be installed.     │
├────────────────────────┬─────────┬─────────┤
│          Name          │ Version │   Size  │
├────────────────────────┼─────────┼─────────┤
│ gke-gcloud-auth-plugin │   0.4.0 │ 7.1 MiB │
└────────────────────────┴─────────┴─────────┘

For the latest full release notes, please visit:
  https://cloud.google.com/sdk/release_notes

Do you want to continue (Y/n)?  y

╔════════════════════════════════════════════════════════════╗
╠═ Creating update staging area                             ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: gke-gcloud-auth-plugin                       ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Installing: gke-gcloud-auth-plugin                       ═╣
╠════════════════════════════════════════════════════════════╣
╠═ Creating backup and activating new installation          ═╣
╚════════════════════════════════════════════════════════════╝

Performing post processing steps...done.

Update done!

接続コマンドを再実行すると、エラーメッセージなしでクラスターが接続されることが確認できます。

gcloud container clusters get-credentials sv-dev-cluster --zone asia-northeast3-a --project {projectId}

Fetching cluster endpoint and auth data.
kubeconfig entry generated for sv-dev-cluster.

接続が成功すると、Docker Desktopにも変化が見られます。具体的には、Kubernetesタブに新しい情報が表示されます。

その後、kubectlを使用してローカルで直接GKEリソースを確認することもできます。

kubectl get deployments
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
my-application        1/1     1            1           20d

結論​

GKEリソースをローカルで効率的に管理する方法を簡単に紹介しました。ローカルでkubectlを使用することで、オートコンプリートなどの拡張機能が利用でき、Kubernetesの管理が非常に便利になります。GKEの使用が初めての方は、ぜひ試してみてください。

参考​

k8s-plugin

概要​

curlコマンドを置き換えることができるCLIツール

Linuxを頻繁に使用する開発者であれば、curlコマンドをよく使うでしょう。サーバーから外部APIリクエストを送信するための必須コマンドですが、出力の可読性が低いという欠点があります。HTTPieはこの欠点を解消できる興味深いツールなので、紹介しましょう。

インストール​

Macユーザーの場合、brewを使って簡単にインストールできます。

brew install httpie

CentOSの場合、yumを使ってインストールできます。

yum install epel-release
yum install httpie

使用方法​

まず、curlを使ってGETリクエストを送信する方法です。

curl https://httpie.io/hello

次に、HTTPieを使って比較してみましょう。

https httpie.io/hello

コマンドのあらゆる面で可読性が大幅に向上しています。レスポンスとヘッダーの値がデフォルトで含まれているため、別のコマンドを使用せずに一目でさまざまな情報を得ることができます。

コマンドではhttpsとhttpが区別されることに注意してください。

http localhost:8080

公式サイトに記載されているように、POSTリクエストを送信することもできます。

http -a USERNAME POST https://api.github.com/repos/httpie/httpie/issues/83/comments body='HTTPie is awesome! :heart:'

その他のさまざまな機能についてはGitHubで説明されているので、うまく活用すれば生産性を大幅に向上させることができます。

参考​

• httpie