Git タグと AWS タグの究極の対決へようこそ。これら2つの競技者は、”tag“という言葉への愛以外には何も共通点がありません。彼らがどれほど混乱と実用性の戦いで勝利するか、見てみましょう!
ラウンド1:彼らの正体
Git タグ
ソフトウェア界の歴史家たち。彼らは現在には興味を持たず、リリースなどの重要なイベントをブックマークして、過去に戻ることができるようにします。彼らはあなたのバージョン管理タイムマシンのような存在です — 過去のコーディングミスに遭遇するリスクはありませんが…あれ待て。v1.0.0-final-final-definitely-final-this-timeのデバッグ、頑張ってください!
AWS タグ
あらゆるものにラベルを貼りたがる過剰に整理された事務管理者。EC2 インスタンス、S3 バケット、月に$500かかる忘れられた Lambda 関数まで、すべてにラベルを貼りたがります。AWS タグは、人生全体をカラーコーディングするあの一友達のような存在ですが…忘れたときは、もう何も意味がわからなくなります。
ラウンド2:彼らの役割
Git タグ
- 重要なコミット(例:v1.0.0、本番リリース)をマークするのに役立ちます
- ソフトウェアリリースのバージョニングに使用されます
- 軽量なラベルまたは注釈付き(歴史的教訓付きのラベル)になります
- 一度プッシュされると、それは恥ずかしいツイートのようなもの — 削除が難しい!(後悔します)
AWS タグ
- キー・バリュー・ペアを AWSリソース に追加するのを手伝います(環境:プロダクション、オーナー:ラム)
- コスト追跡、組織、コンプライアンスのために使用されます
- 必須にすることもできます(上司がそう言ったら)し、オプションにすることもできます(怠けたい気分の場合)
- 毎月のAWS請求書のように変更が簡単です(それは金銭強盗のプロットツイストよりも予測不可能です)
ラウンド3:実生活の反応
Gitタグユーザー
“リリースにタグを付けたばかりです!あ、待って、名前を変更する必要があります。ああ、いや…ああ、いや…ああ、いや。”(ネタバレ:タグの名前を変更するのは、ペットの名前を3年後に変更するよりも難しいです。)
AWSタグユーザー
“このEC2インスタンスに’Delete Me’ってタグを付けたのは誰だ?!待って…私のEC2はどこに行ったの?!”(本当のホラー映画:AWSの請求書と accidental deletions。)
ラウンド4:無視したらどうなる?
Gitタグを無視する
- リリースは謎です。v1.2はfix-bug-final-final2の前ですか、それとも後ですか?
- プロダクションのデバッグはタイムトラベルの逆説になります。
- あなたのDevOps/リリースエンジニアリングチームは自分の人生の選択を疑問視し、インターネットのないゾーンに引っ越すことを検討します。
AWSタグを無視する
- あなたのFinOpsチームはAWSの請求書を見ると泣きます(あなたも泣きます)。
- どのインスタンスがテスト環境で、どれがプロダクションなのかわからなくなります。
- 思わずCIOのお気に入りのダッシュボードを終了させてしまいます。おっと!!!(履歴書を更新する時間です!)
ラウンド5:両方をタグ付けする方法
Gitタグ
git tag v1.0.0
を使用して軽量タグを作成します。git tag -a v1.0.0 -m "Version 1.0 release"
を使用して注釈付きタグを作成します。git push origin v1.0.0
でプッシュします。- 間違ったコミットにタグ付けしてしまいましたか?おめでとうございます、冒険が始まります!
git tag -d v1.0.0
(ローカルの場合)およびgit push --delete origin v1.0.0
(リモートの場合)を使用して混乱を解消します。
- 1000000のリポジトリからタグを削除していることにうんざりしていますか?その後、自動化を使用します(Jenkinsのシンプルなスクリプトを使用すると、多くの時間と精神的な安定を節約できます)
AWSタグ
AWS CLI:aws ec2 create-tags --resources i-1234567890abcdef0 --tags Key=Environment,Value=Production
を使用します。- AWSコンソールで、任意のリソース(EC2やS3など)に移動し、「Tags」タブの下にキーと値のペアを手動で追加します。
- AWS組織を使用してタグ付けポリシーを自動化し、タグ付けの支配者のように強制します。
- リソースにタグを付け忘れた場合、AWSの請求書が思い出させます。痛いです。
ラウンド6:高度なタグ付けテクニック
高度なGitタグ付け
- すべてのタグをリストアップ:
git tag -l
- 特定のコミットにタグを付ける:
git tag -a v2.0.0 <commit-hash> -m "Version 2.0 release"
- 署名されたタグを検証する:
git tag -v v1.0.0
- タグを別のコミットに移動する:
git tag -f v1.0.0 <new-commit-hash>
- すべてのタグをリモートと共有する:
git push --tags
AWSのタグ付けの高度な方法
- リソースのすべてのタグをリストする:
aws resourcegroupstaggingapi get-resources --tag-filters Key=Environment,Values=Production
- 複数のリソースに一度にタグを付ける:
aws ec2 create-tags --resources i-1234567890abcdef0 i-0987654321abcdef0 --tags Key=Project,Value=MyApp
- タグを削除する:
aws ec2 delete-tags --resources i-1234567890abcdef0 --tags Key=Environment
- AWSコンソールでの大量タグ付けのためにAWS Tag Editorを使用します。
- AWS Lambda関数を実装して、すべてのリソースにわたるタグ付けの遵守を強制します。
第7ラウンド:存在のタグ付け危機
- ある時点で、すべてのエンジニアが尋ねます:タグは重要ですか?答えははいです — 重要なときは。いつか、何年も前のGit履歴を掘り下げて、なぜ誰かがコミットを
final-final-v2-fix-thatworks-for-sure-this-time
としてタグ付けしたのか疑問に思うことがあるかもしれません。また、EC2インスタンスがProduction
とタグ付けされていることに気づき、実際にはその用途を誰も覚えていないことに気づくかもしれません。 - タギングは、オフィスの冷蔵庫に食べ物をラベリングするようなもので、組織化には不可欠ですが、完全に無視される可能性があります。古い展開物を探したり、高額なAWSの請求を正当化しようとしているとき、楽しいことがすべて終わります。
- ですので、慎重にタギングを受け入れてください。今日1つの追加のラベルが、明日の大きな危機からあなたを救うかもしれません。あるいは、少なくともあなたのマネージャーと非常に気まずい会話をすることになるでしょう。
裁定
では、誰が勝つのでしょうか?まあ、それらの間には、すでに述べたとおり、「love」という言葉以外に何も共通点のないものがあります。tag。
- 歴史的な正確さと十分に文書化されたコードリリースが好きなら、Gitタグが最高の味方です。
- お金の行方を追跡するのが好きなら(少なくともそうしているふりをするのが好きなら)、AWSタグは欠かせません。
いずれにせよ、タグは歌われないテックのヒーローです — それがそうでなくなるまで。ですので、次回何かをタグ付けするときは、1つの誤った動きがあれば、未来は非常に混乱します。
タギングを楽しんでください!
Source:
https://dzone.com/articles/git-tags-vs-aws-tags-a-tag-tastic-showdown