Open22

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

yu_s_1985yu_s_1985

Cloud9もCodeCommitも新規利用が不可になったということで、真面目に代替案を検証したい。

今のところ現実的にはざっくり以下が視野に入っている

  • Cloud9
    • CoderなどのOSSをEC2で立てる
      • 課題はユーザー管理とポリシーか
      • 使わなくなったら自動停止とかはデフォルトではない?
    • SageMaker Studio コードエディタ
    • GitHub Codespaces
      • GitHubやGitHab Enterpriseが使えるならそこそこ選択肢としてはアリ
      • GitLabのWeb IDEも似たような感じ?
    • CodeCatalyst
      • あまりまだわかってないので要検証
        • サービスの中でもIDEとしてCloud9の環境をCloud9のコンソール上とは別に立てられたが、それは今後または新規でも引き続き使えるのか?
  • CodeCommit
    • GitHub
      • ポリシー的に問題なく使えるならこれでよい。というか、そのケースはそもそもCodeCommitを使う必要がなさそう。
    • GitHub Enterprise ServerやGitLabなどをEC2で立てる
      • 自前で何らかのリポジトリ管理サービスの鯖を立てる
    • CodeCatalyst
      • あまりまだわかってないので要検証。開発環境に付随してGitリポジトリ管理サービスはありそうではあった
yu_s_1985yu_s_1985

検証のために新規AWSアカウントを作った。
念の為Control Towerではなく完全新規アカウント
新規に発行した、Cloud9が使えないアカウント

Cloud9のコンソールからはCloud9が起動できない。

yu_s_1985yu_s_1985

AWS BuilderIDでSpaceを作るとどうやらスペースを作成するリージョンが限られるようなのでIAM Identity Centerで作成する

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

yu_s_1985yu_s_1985

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

IAMロールもデフォルトで適当に作成した。

yu_s_1985yu_s_1985

CodeCatalystのテスト用環境を新しく作った
CodeCatalystのトップページ

適当にプロジェクトを作成してみる。

あらかじめ用意されているブループリントがある。多分自分で作成もできる。
プロジェクト作成画面-BluePrint

GitHub、BitBucket、GitLabと連携することもできる。この場合コード管理はそれぞれのリポジトリで行うことになるのかな?
プロジェクト作成画面-Bring your own code

画像は貼らないが、一番右のStart from Scratchはプロジェクトの名前だけ設定して全部一から作る感じになるっぽい。

今回はとりあえずブループリントを選択してみる。
個人的な理由によりSAMを使ったブループリントを選ぶ。

他のブループリントを適当に選んだり、一から作るのも後から試す。

yu_s_1985yu_s_1985

適当に名前をつける。
GitリポジトリはCodeCatalystのものも選べるが、GitHub、BitBucket、GitLabも選択肢にあった。
 プロジェクト詳細入力画面

リポジトリ選択ボックス

その他の設定は適当に行った。IAMロールはCodeCatalystのSpace作成時に作成したデフォルトの権限のもの。
その他詳細設定

yu_s_1985yu_s_1985

このように統合開発環境のような感じになっている。
作成したプロジェクトのトップ

Dev Environment(開発環境)を作成できるが、選択肢にCloud9がある。
プロジェクトの開発環境作成画面

Cloud9はとりあえずデフォルト設定で作成してみる
Cloud9 on CodeCatalyst作成画面

yu_s_1985yu_s_1985

環境を作成できてしまった。
Cloud9の環境のスペックを変えるならCodeCatalystのBilling Tierを変更する必要がありそう。
今回はFreeなので最低スペックのみ。

Open in AWS Cloud9(in browser)を選択すると見覚えのある以下の画面が。
Cloud9使える!
先に貼った通り、このアカウントではCloud9のコンソールからCloud9のインスタンスの作成はできません。
Cloud9を開く画面

CodeCatalystで作成したCloud9の画面

ただ、ここまでの道のりが面倒なので初学者がいきなり使えるものではなくなったかなあという印象

yu_s_1985yu_s_1985

作成したCloud9の環境にはいくつかの設定をすることでSSHで接続できる模様
SSHでの環境接続

おそらくは内部的にセッションマネージャーを使っている?

VSCodeやIntelliJなどで開発環境を作ることもできるが、多分それはローカルにCloneすることになるので、ポリシー上それが許されない環境ならVSCodeのRemote SSHでつなぐのに有用かも。

yu_s_1985yu_s_1985

開発環境はリポジトリに対して1つらしいので、Cloud9以外の検証をするために一旦Cloud9の環境を削除する

ちなみにプロジェクトにはリポジトリを複数作成できる
リポジトリ管理画面

yu_s_1985yu_s_1985

VSCodeでやってみた。
VSCodeで作成する開発環境

作成すると、VSCodeで開くと出てくる
VSCodeで開く

VSCodeで開くと、今度はまたブラウザでの認証を求められる
多分、あらかじめAWS Toolkitのインストールが必要。Remote SSHも必要かも?
ブラウザでの認証

これによりVSCodeのAWS ToolkitからCodeCatalystの環境への認証が行われた。

yu_s_1985yu_s_1985

認証済みの状態でToolkitのCodeCatalystのところを開くとこんな感じ
ToolkitのCodeCatalystの画面

Open Dev Environmentを選択すると、Remote SSHでの接続になる。
Remoteでの接続

これが可能なら必ずしもCloud9で環境を作らなくてもよいかも、というより恐らく内部的にはCloud9の環境ではないかと思う。

yu_s_1985yu_s_1985

この認証情報を使ってリポジトリをローカルクローンもできそうだが、CloneするときにGit Credential Managerの設定をしろと言われる。
ここに何を入れればいいかよくわからず、AWS ToolkitからのCloneはうまくいかなかったのだが、どうやらユーザーのアクセストークンをパスワードに使用することと、ユーザー名にアンダーバーを使っているとここで入力する名前ではアンダーバーからハイフンに勝手に修正されているということを知っている必要があった。

入力する内容については、CodeCatalystの画面からリポジトリを選択して、Clone Repositoryを選択した時にクローンのURLを確認できる。
https://<ユーザー名>@git.<リージョン>.codecatalyst.aws/v1/<CodeCatalystの環境名>/<プロジェクト名>/<リポジトリ名>
となっているので、このURLからユーザー名をコピーすると良い。
この画面でもパーソナルアクセストークンを発行できるが、この画面では発行しかできないので無駄にアクセストークンを作ってしまいかねない。
ユーザーを選択してユーザー画面からアクセストークンを発行するとよさそう。

yu_s_1985yu_s_1985

CodeCatalystのリポジトリのプルリクエストも試してみたが、CodeCommitに近い感じだった。
CodeCatalystのプルリクエスト1
CodeCatalystのプルリクエスト2

コメントつけたりとかはCodeCommitよりは使いやすいUIにはなっているかもしれない。

yu_s_1985yu_s_1985

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

yu_s_1985yu_s_1985

GitHubはEnterpriseでも連携できる模様
アカウント単位でも、リポジトリ単位でも連携できそう

CodeCatalyst上のIssueやPull RequestとGithub繋いだときのIssueやPull Requestはどういう扱いになるんだろうと思ったけれど、どうやらそれはGitHub上で行うようでCodeCatalystには入ってこないことを確認。

yu_s_1985yu_s_1985

スペースの設定一覧は以下
spaceの設定

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

yu_s_1985yu_s_1985

その他、WorkflowというGitHub Actionsっぽい機能もあります。
こちらについてはCodeCatalyst上のリポジトリではなくGitHubのリポジトリも連携が可能な模様。

前述のIssueなども、複数のリポジトリ横断で連携できそう。
ソースがCodeCatalyst、GitHub、GitLab、BitBucketなどに散らばってる場合には良さそう

一方、現状プラグインでJiraとも連携できそう

yu_s_1985yu_s_1985

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