Cloud9、CodeCommitの代替手段について考える

Cloud9もCodeCommitも新規利用が不可になったということで、真面目に代替案を検証したい。
今のところ現実的にはざっくり以下が視野に入っている
- Cloud9
- CoderなどのOSSをEC2で立てる
- 課題はユーザー管理とポリシーか
- 使わなくなったら自動停止とかはデフォルトではない?
- SageMaker Studio コードエディタ
- https://qiita.com/minorun365/items/f5289163795d5d7b21e2
- やや用途が異なるが、手っ取り早い代替はこれかも
- GitHub Codespaces
- GitHubやGitHab Enterpriseが使えるならそこそこ選択肢としてはアリ
- GitLabのWeb IDEも似たような感じ?
- CodeCatalyst
- あまりまだわかってないので要検証
- サービスの中でもIDEとしてCloud9の環境をCloud9のコンソール上とは別に立てられたが、それは今後または新規でも引き続き使えるのか?
- あまりまだわかってないので要検証
- CoderなどのOSSをEC2で立てる
- CodeCommit
- GitHub
- ポリシー的に問題なく使えるならこれでよい。というか、そのケースはそもそもCodeCommitを使う必要がなさそう。
- GitHub Enterprise ServerやGitLabなどをEC2で立てる
- 自前で何らかのリポジトリ管理サービスの鯖を立てる
- CodeCatalyst
- あまりまだわかってないので要検証。開発環境に付随してGitリポジトリ管理サービスはありそうではあった
- GitHub

検証のために新規AWSアカウントを作った。
念の為Control Towerではなく完全新規アカウント
Cloud9のコンソールからはCloud9が起動できない。

AWS BuilderIDでSpaceを作るとどうやらスペースを作成するリージョンが限られるようなのでIAM Identity Centerで作成する
勘違いしていたが、IAM Identity Centerはアカウント単体でも作れるらしい。(Organizations必須だと思っていた…)
東京リージョンでIAM Identity Centerを作成。どうやらIAM Identity Centerを有効化したリージョンがCodeCatalystの環境を作る時に選べる模様
IAM Identity Centerを有効化できるのはデフォルトでは1リージョンのみっぽいので必要なら上限緩和申請する(多分できるはず)

CodeCatalyst自体はオレゴンかアイルランドでしか設定できないが、前述の通りIAM Identity Centerを有効化したリージョンにスペースが作成できる模様。
作成したIAM Identity Centerを選択してあとは画面に沿って設定。
IAMロールもデフォルトで適当に作成した。

CodeCatalystのテスト用環境を新しく作った
適当にプロジェクトを作成してみる。
あらかじめ用意されているブループリントがある。多分自分で作成もできる。
GitHub、BitBucket、GitLabと連携することもできる。この場合コード管理はそれぞれのリポジトリで行うことになるのかな?
画像は貼らないが、一番右のStart from Scratchはプロジェクトの名前だけ設定して全部一から作る感じになるっぽい。
今回はとりあえずブループリントを選択してみる。
個人的な理由によりSAMを使ったブループリントを選ぶ。
他のブループリントを適当に選んだり、一から作るのも後から試す。

適当に名前をつける。
GitリポジトリはCodeCatalystのものも選べるが、GitHub、BitBucket、GitLabも選択肢にあった。
その他の設定は適当に行った。IAMロールはCodeCatalystのSpace作成時に作成したデフォルトの権限のもの。

このように統合開発環境のような感じになっている。
Dev Environment(開発環境)を作成できるが、選択肢にCloud9がある。
Cloud9はとりあえずデフォルト設定で作成してみる

環境を作成できてしまった。
Cloud9の環境のスペックを変えるならCodeCatalystのBilling Tierを変更する必要がありそう。
今回はFreeなので最低スペックのみ。
Open in AWS Cloud9(in browser)を選択すると見覚えのある以下の画面が。
Cloud9使える!
先に貼った通り、このアカウントではCloud9のコンソールからCloud9のインスタンスの作成はできません。
ただ、ここまでの道のりが面倒なので初学者がいきなり使えるものではなくなったかなあという印象

作成したCloud9の環境にはいくつかの設定をすることでSSHで接続できる模様
おそらくは内部的にセッションマネージャーを使っている?
VSCodeやIntelliJなどで開発環境を作ることもできるが、多分それはローカルにCloneすることになるので、ポリシー上それが許されない環境ならVSCodeのRemote SSHでつなぐのに有用かも。

プロジェクト共通設定みたいなのはdevfile.yamlというファイルで定義する模様

開発環境はリポジトリに対して1つらしいので、Cloud9以外の検証をするために一旦Cloud9の環境を削除する
ちなみにプロジェクトにはリポジトリを複数作成できる

VSCodeでやってみた。
作成すると、VSCodeで開くと出てくる
VSCodeで開くと、今度はまたブラウザでの認証を求められる
多分、あらかじめAWS Toolkitのインストールが必要。Remote SSHも必要かも?
これによりVSCodeのAWS ToolkitからCodeCatalystの環境への認証が行われた。

認証済みの状態でToolkitのCodeCatalystのところを開くとこんな感じ
Open Dev Environmentを選択すると、Remote SSHでの接続になる。
これが可能なら必ずしもCloud9で環境を作らなくてもよいかも、というより恐らく内部的にはCloud9の環境ではないかと思う。

この認証情報を使ってリポジトリをローカルクローンもできそうだが、CloneするときにGit Credential Managerの設定をしろと言われる。
ここに何を入れればいいかよくわからず、AWS ToolkitからのCloneはうまくいかなかったのだが、どうやらユーザーのアクセストークンをパスワードに使用することと、ユーザー名にアンダーバーを使っているとここで入力する名前ではアンダーバーからハイフンに勝手に修正されているということを知っている必要があった。
入力する内容については、CodeCatalystの画面からリポジトリを選択して、Clone Repositoryを選択した時にクローンのURLを確認できる。
https://<ユーザー名>@git.<リージョン>.codecatalyst.aws/v1/<CodeCatalystの環境名>/<プロジェクト名>/<リポジトリ名>
となっているので、このURLからユーザー名をコピーすると良い。
この画面でもパーソナルアクセストークンを発行できるが、この画面では発行しかできないので無駄にアクセストークンを作ってしまいかねない。
ユーザーを選択してユーザー画面からアクセストークンを発行するとよさそう。

CodeCatalystのリポジトリのプルリクエストも試してみたが、CodeCommitに近い感じだった。
コメントつけたりとかはCodeCommitよりは使いやすいUIにはなっているかもしれない。

一旦ここまで。
GitHubと連携したときの挙動やCI/CD周りの設定も知りたい

CodeCatalystの検証続き

GitHubはEnterpriseでも連携できる模様
アカウント単位でも、リポジトリ単位でも連携できそう
CodeCatalyst上のIssueやPull RequestとGithub繋いだときのIssueやPull Requestはどういう扱いになるんだろうと思ったけれど、どうやらそれはGitHub上で行うようでCodeCatalystには入ってこないことを確認。

スペースの設定一覧は以下
VPC Connectionという項目があり、ここからVPCに連携できる…と思ったけど、連携可能なのはIAM Identity Centerがあるリージョンではなく、CodeCatalystの設定を行ったリージョンのようだった…。
これはそれなりにネックになりそう…

その他、WorkflowというGitHub Actionsっぽい機能もあります。
こちらについてはCodeCatalyst上のリポジトリではなくGitHubのリポジトリも連携が可能な模様。
前述のIssueなども、複数のリポジトリ横断で連携できそう。
ソースがCodeCatalyst、GitHub、GitLab、BitBucketなどに散らばってる場合には良さそう
一方、現状プラグインでJiraとも連携できそう

全部ではないけど、できることが見えてきたのでそれぞれのできることできないことを踏まえたうえでメリット・デメリットを整理していこうと思う

CodeSpacesからAWS Client VPNを使えるか、という検証をする
以下を参考にしたい