AWS CodeCommitを使ってAWS CloudShellのdotfilesを管理してみる

Takuya Shibata
2021.01.23
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
しばたです。
世の開発者の中にはいわゆるdotfilesと呼ばれる設定ファイル群をGitHubなどのSCMで管理している方がいらっしゃいます。この方式に倣いAWS CodeCommitをAWS CloudShellの構成管理に使えないかとなんとなく思ったので試してみることにしました。
ちなみにこのやり方がCloudShellの管理に最適かどうかはわかりません...

それを検証するためにまずは試してみようというのがこの記事の趣旨となります。
 Why CodeCommit?AWS CloudShellは$HOME配下は永続的に保持されるものの、120日アクセスが無いと自動で削除されるため永久保存ではありません。
https://dev.classmethod.jp/articles/about-aws-cloudshell-home-directory-retention/
このためCloudShellで使うデータに対して決して消えないことを求める場合は何らかの外部ストレージを必要とします。
単純に外部ストレージが必要なだけであればS3でも構いませんし、SCMを使うにしても最初に触れた様にGitHubなど他のサービスでも構わないと思います。
今回CodeCommitを選んだ理由としては
AWS謹製のサービスであり、原則AWS内部に閉じている点
これは悪い点にもなり得ますが私個人としてはメリットの方が大きいと考えています

CloudShellの認証情報でシームレスに連携できる点
GitHubなどの外部サービスだとどうしても認証情報の連携が面倒になってしまう

実質無料に近い利用料金
金銭的にお手軽なのは大事です

があり、CloudShellで一番楽に使えるだろうという見込みからの判断でもあります。
 余談 : CodeCommitの認証方式についてここで軽くCodeCommitの認証方式について触れておくと、CodeCommitではIAMユーザーなどの主体に対して
SSH認証
HTTPS Git認証
HTTPS GRC認証
の3種類の認証方式があり、前者2種(SSH認証、HTTPS Git認証)については別途キー情報を生成する必要があります。
残りのHTTPS GRC認証ではgit-remote-codecommitというヘルパープログラムを追加することでIAMユーザーやIAMロールの認証情報を使う方式になります。
https://dev.classmethod.jp/articles/introduce-git-remote-codecommit/
CloudShellではデフォルトでgit-remote-codecommitがインストール済みであり今回はこの方式一択の採用となります。
HTTPS GRC認証では以下の様なcodecommit::で始まる独自のURL指定でリポジトリをCloneしてやる必要があります。
# プロファイルを明示する場合
git clone codecommit::<region>://<your-profile>@<your-repository>

# プロファイルを明示しない場合 (インスタンスプロファイルの使用など)
git clone codecommit::<region>://<your-repository>
 やってみたそれでは早速やっていきます。
 今回の環境今回は東京リージョンのCloudShellで試していきます。

本日時点での各種ツールのバージョンは以下でした。
Git 2.23.3
git-remote-codecommit 1.15.1
AWS CLI 2.0.58
 1. リポジトリ作成はじめにAWS CLIを使いCodeCommitリポジトリを作ってやります。

今回は以下のコマンドでdotfiles-shibataという名前のリポジトリを作ります。
aws codecommit create-repository \
    --repository-name dotfiles-shibata \
    --repository-description "Repository for dot files on CloudShell."
エラー無くコマンドが完了していればOKで、マネジメントコンソールからもこんな感じで確認できます。
 2. リポジトリのClone、ファイルの管理作ったリポジトリをCloneしファイルを管理していきます。
今回はホームディレクトリにそのままリポジトリをCloneします。

前項で触れたとおりHTTPS GRC認証を使いcodecommit::で始まるURL指定でCloneします。
# Clone : HTTPS GRC認証
cd ~
git clone codecommit::ap-northeast-1://dotfiles-shibata

# git config は適当に
git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"
あとは好きに各種設定ファイルをGitで管理するだけです。
今回は単純に.bashrcをちょっとだけカスタマイズして保存することにします。
デフォルト設定の.bashrcにexport POWERSHELL_UPDATECHECK=offの設定を追加し保存、

(なお、この設定の意味ついてはこちらの記事をご覧ください)
~/.bashrc
# .bashrc

# ・・・中略・・・

# Add : PowerShell notification setting. (set disabled)
export POWERSHELL_UPDATECHECK=off
変更後のファイルをCloneしたローカルリポジトリに追加しCommitします。
# リポジトリに移動
cd ~/dotfiles-shibata/

# カスタマイズした.bashrcを持ってきて...
cp ~/.bashrc .

# 適当にCommitしてPush
git add .bashrc
git commit -m "First commit."
git branch -M main
git push -u origin main
あとは再セットアップ時に備えて以下の様なスクリプトも保存しておくと良いでしょう。

(追加手順は省略)
setup.sh
#!/usr/bin/env bash

# setup synbolic link
ln -svf "$(pwd)/.bashrc" ~/

# source
source ~/.bashrc
結果のリポジトリはこんな感じです。
今回は非常にシンプルな例を出していますが、実際には環境に応じて自由にリポジトリを管理すれば良いかと思います。
 再セットアップこれでファイルを保存できましたので、ホームディレクトリを削除してCloudShell環境を初期化し再セットアップしてみます。

やり方はシンプルでCodeCommitリポジトリをCloneし直して準備しておいたsetup.shを呼び出すだけです。
# 最初と同様にリポジトリをClone
cd ~
git clone codecommit::ap-northeast-1://dotfiles-shibata

# setup.shを流して復元
cd dotfiles-shibata/
. setup.sh
無事再セットアップできました。
 最後に以上となります。
非常に簡単な例を試しただけですが意外と悪くなさそうです。

もう少しいろいろな運用をしていき良し悪しを見つけていればなと思います。