GitLab CI/CDで研修業務を自動化した話（後編）〜AWSとTerraformによるcode-server環境の構築〜
こんにちは！
私はカサレアルでラーニング・サービスを担当している山本 薫と申します。
弊社の研修コースで使用している教材の開発や研修環境の準備作業をどのように自動化しているかについて紹介します。
前編では、Asciidoctor PDFとDockerによるテキストPDFのビルドについてお伝えしました。
前編記事へのリンク：『GitLab CI/CDで研修業務を自動化した話（前編）〜Asciidoctor PDFとDockerによるテキストPDFのビルド〜』
今回は後編として、AWSとTerraformによるcode-server環境の構築についてお伝えします。
code-serverによるリモート研修環境の提供
2020年春。
それは全世界を襲いました…。
そうです、COVID-19です。
それまで私たちは、教室に集まって研修を行う集合研修という形式で研修を実施していました。具体的には、アプリケーション開発系のコースでは、各種開発ツール類をインストールしたWindowsマシンを1人に対して1台ずつ用意し、演習課題に取り組んでもらいました。
ところが、このCOVID-19によりソーシャル・ディスタンスが徹底されるようになり、研修実施もままならなくなりました。狭い部屋で多人数が集まり、講師が長時間話し続ける環境は、新型コロナウイルスにとって最高の環境だからです。
私たちはすぐさまオンライン研修の提供方法を模索しました。
比較的早い段階で、Zoomを利用したリモート会議形式での実施スタイルが確立しました。
利用者が多く、抵抗なく利用していただけたからです。
問題は演習環境でした。
研修開催ごとにセットアップ済みのWindowsマシンを送付し、研修が終わったら返却してもらうことも案として挙がったのですが、弊社が提供するコースは1日間や2日間といった短期のものが多く、作業負荷の観点からもコストの観点からも現実的でなく、すぐさま却下されました。
そこでまず試したのがリモートデスクトップ環境でした。
AWS上に用意したWindowsのEC2インスタンスにRDP（Remote Desktop Protocol）で接続する方式です。
これにはいくつかの問題がありました。
まず、RDPが利用できない環境があることです。
弊社のお客様は企業に所属している方が大半を占めます。オフィスから接続する際、ファイアウォールやプロキシなどによりRDPがブロックされてしまうことがあり、すべてのお客様に利用していただくことができません。
次にコスト面です。
WindowsのEC2インスタンスは、オペレーティングシステムのライセンス料金がかかるため、一般的なLinuxインスタンスと比較して高くなります。
ほかにもWindowsには標準でRDPクライアントが付属しているのに対して、Macでは追加でインストールしていただく必要があります。初期のRDPクライアントは、Macからアクセスした際に一部のキーが入力できないといった問題もありました。
これらの点を踏まえ、別の方法を模索することとなりました。
そして、次に試したのがUbuntu DesktopのEC2インスタンスに対してApache Guacamole経由で接続する方式でした。
Apache Guacamoleは、Webブラウザーを利用したリモートデスクトップ接続を可能にするオープンソースソフトウェアです。WebブラウザーとApache Guacamoleサーバーの間はHTTP/HTTPSで接続するため、ファイアウォールやプロキシが設置されている環境からでもアクセス可能です。
しかし、これにも大きな落とし穴がありました…。
一番の問題はキーマッピングです。
WebブラウザーからのアクセスだとWindowsかMacかの識別ができず正しくマッピングできなかったり、Webブラウザーがショートカットキー操作を横取りしてしまったりと、RDP以上に問題が悪化しました。
さらに、1台のApache Guacamoleサーバーで複数セッションを扱うため遅延が発生したり、動作が不安定になったりもしました。
そのため、RDPが利用できる方にはApache Guacamoleを経由せずに、Ubuntu Desktopのインスタンスに直接RDP接続していただくよう案内するようにしました。
次に目をつけたのがcode-serverです。
code-serverは、簡単に説明すると、リモートコンピューター上で実行しているVisual Studio CodeにWebブラウザーでアクセスできるようになるソフトウェアです。なお、code-serverはMicrosoft社ではなく、Coder Technologies社が開発しています。
厳密には、Visual Studio Codeの中身（オープンソースソフトウェアとして公開されている）をカスタマイズして実現しているので、ユーザーインターフェースやプラグインなどは完全な互換性があるというわけではありませんが、ほぼVisual Studio Codeとして扱えます。
code-serverの採用により、ファイアウォールやプロキシ経由のアクセスも可能になり、ユーザビリティも格段に向上しました。
2026年現在、ほとんどの研修コースはcode-server環境に移行しました。
これでひと通りのパーツが出揃いましたので、あとはCI/CDパイプラインによる自動化を行うのみです。
GitLab CI/CDによるCDパイプラインの構築
すでにAsciiDocのソースからテキストPDFファイルを生成する部分についてはCIパイプラインが稼働しているので、あとは研修コース開催ごとに研修環境を構築・破棄するCDパイプラインを構築するだけです。
研修環境においては、研修の実施ごとに環境を構築し、研修が終わったら環境を破棄するという非常に短い一時的な環境を扱う必要があります。
そのため、ひとつのパイプラインの中に、プッシュやタグ作成で起動する教材ビルドのためのCIパイプラインと、研修の実施ごとに手動で起動する環境構築・破棄のためのCDパイプラインを定義しました。
パイプラインの定義にあたっては、GitLab CI/CDが提供するジョブ変数やルール、手動ジョブといった機能を活用しました。ワークフローに合わせて柔軟にパイプラインを定義できるのはGitLab CI/CDの一番の魅力だと感じています。
＜関連コース＞
TerraformによるAWSへのデプロイ
さて、ワークフローの大枠は紹介しましたので、あとは環境構築の具体的な方法について紹介します。
弊社では一部コースを除き、研修環境としてAWSのクラウドサービスを利用しています。
大まかな構成として、研修の実施ごとにVPCを作成し、その中にcode-serverや各種開発ツールがインストールされたEC2インスタンスを受講者の人数分配置します。
1回の実施につきさまざまなリソースを作成しなければならず、とても手作業では対応しきれないため、当然IaC（Infrastructure as Code）の導入が必要になりますが、使い勝手や柔軟性の観点からAWS CloudFormationではなく、Terraformを採用することにしました。
まず、タグを作成した時に実行する教材ビルドのパイプラインで、EC2 Image Builderを用いてcode-serverのイメージを作成します。このイメージの中にはcode-server以外にもコースごとに異なる開発ツールやサンプルコードも配置しておき、ホスト名やパスワードなどごく少数のパラメーターだけでインスタンス化できるようにしておきます。
一方、環境構築のパイプラインでは、Terraformのテンプレートに対してコース実施ごとのIDや受講者の人数などのパラメーターを代入し、VPC一式と受講者の人数分のEC2インスタンスをAWSにデプロイします。
デプロイが完了すると、code-server環境にアクセスするためのURLやパスワードが記載されたファイルが出力されるので、研修実施当日にはその情報を受講者の方々に配布して利用していただきます。
ちなみに、1つの研修コースを同時に開催しても大丈夫なように、Terraformのワークスペースの機能を利用して環境を分離しています。
＜関連コース＞
- 『Terraform、Ansible を使ったインフラストラクチャアズコード入門 -マルチクラウド実現に向けて-』
- 『アプリケーションエンジニアのためのAWS入門 -EC2,S3,VPC,CDK-』
- 『全体像から理解するクラウドネイティブ基礎 -VM⇔コンテナ、クラウドサービスの利用、プロセスの自動化-』
全体像
今まで紹介してきた内容を図にまとめると以下のようになります。
まとめ
今回は、弊社の研修サービスの裏側についてご紹介しました。
さまざまな製品・サービスを組みあわせ、時代の変化に対応しながら自動化の仕組みを構築してきたことをご理解いただけたかと思います。
なお、記事の途中に記載させていただきましたが、今回ご紹介した内容のいくつかは関連する研修コースをご用意しています。興味を持っていただけた方はぜひご受講ください。
