2023年8月の振り返り

Laprasの技術スコアが3.5を超えたので学習履歴を振り返る

2023年7月の振り返り

週末振り返り 2023.07.10~16

## 導入

### 何について話すのか

開発環境を改善して、効率化することでアプリケーション開発に注力するため行った（行っている）取り組みについてお話します。

本記事はQmonus Value Streamの投稿キャンペーン記事です。

### 想定読者

- レガシーな環境を改善している（していきたい）人
- 開発環境改善のアイデアが欲しい人
- CI/CDやDevOpsよりな仕事に関わる人

### どんな人が書いているか(自己紹介)

- 3年目のエンジニアでバックエンドを中心に担当（最近インフラも担当するようになりました）
- メインで扱う技術はPHP・TypeScript・AWS
- アプリケーション開発とAWSインフラ構築を担当する
- 受託開発が中心の企業に従事

## 記事で触れる取り組み（取り組んだ順）

1. Dockerの導入
2. テスト・静的解析の導入
3. CI/CDの導入・整備による効率化
4. Gitフローの変更・整備・周知
5. フロントエンド側へTypeScript・Vueの導入
6. AWSサービスの活用

## Dockerの導入

### 背景

Docker導入前はwinscpというツールを利用してLinuxサーバに直接SFTPでファイルをアップロードし、Linuxサーバーに割り当てられたローカルIPアドレスをブラウザでたたいてアクセスして動作確認を行う環境でした。この環境は以下のような問題を抱えていました。

### 課題

- **開発環境構築の手間**：LinuxサーバーにPHPの実行環境を構築する手間が必要で、新メンバーのオンボーディングが遅延しました。
- **環境差異**：開発環境、検証環境、本番環境でPHPやミドルウェア等のバージョンが異なり、動作確認が一貫しないことが多々ありました。
- **再現性の低さ**：サーバ構築の再現性が低く、環境によって動かないコードが存在しました。
- **改善の難易度**：上記の要因によってアップデートの難易度・工数が跳ね上がり、改善に着手しにくい状況でした。

### Docker導入後のメリット

- **環境の統一と再現性の向上**：Dockerを用いることで、全員が同じ開発環境を利用できるようになり、環境差異による問題が解消されました。
- **スクラップ＆ビルドの容易化**：開発環境の作り直しがしやすくなり、検証作業等がスムーズに行えるようになりました。これにより、改善活動がやりやすくなりました。
- **開発サーバーの不要化**：開発用途のサーバーを立ち上げて共有する必要がなくなり、ファイルのアップロードの度に発生するほかの作業者への確認などの質問がなくなりました。
- **新メンバーのオンボーディングの迅速化**：新メンバーが迅速に開発環境を整備できるようになり、生産性が向上しました。

## テスト・静的解析の導入

### 背景

古めのPHPを利用していた背景もあり、コードの品質に課題がありました。これを解決するために、テストと静的解析を導入しました。

### 導入したツール

- **PHPStan(Larastan)**：静的解析ツールとして利用。コードの問題を早期に発見するのに役立ちました。
- **PHPcs**：コーディング規約に沿ったコードを書くためのツール。チーム全体のコード品質向上に貢献しました。
- **PHPmd**：メンテナンス性向上のためのコード解析ツール。
- **PHPUnit**：単体テストフレームワーク。自動テストの導入により、品質保証を強化。
- **ESLint・Prettier**：JavaScriptとTypeScriptのコード品質を保つためのツール。統一されたコードスタイルを保つことができました。

### 導入後の効果

- **早期発見と修正**：バグの早期発見と修正が可能になり、デバッグの手間が大幅に減少しました。
- **コードの可読性向上**：コードの可読性が向上し、他のメンバーがコードを理解しやすくなりました。
- **開発スピードの向上**：開発スピードが向上し、新機能の追加や改修がスムーズに行えるようになりました。
- **品質保証の強化**：自動テストにより、リリース前に問題を発見・修正できるようになり、品質保証が強化されました。

## CI/CDの導入・整備による効率化

### 背景

手動でのデプロイが主流で、ミスが発生しやすく、時間もかかっていました。これを解決するためにCI/CDを導入しました。

### 導入したツール

- **GitLab CI**：CI/CDパイプラインを構築し、コードの自動テストとデプロイを実現しました。
- **GitLab Runner**：テストコードが増えた段階で並列化するために導入しました。
- **AWS Codeシリーズ**：AWSの複数の環境へのデプロイを自動化しました。

### 導入後の効果

- **デプロイの安定化**：手動デプロイのミスがなくなり、デプロイ作業が安定しました。
- **品質保証の強化**：自動テストによる品質保証が強化され、デプロイ前の不安が軽減されました。
- **開発者の負担軽減**：デプロイ作業の自動化により、開発者がコア業務に集中できるようになりました。
- **迅速なフィードバック**：CI/CDパイプラインにより、迅速なフィードバックが得られるようになり、開発サイクルが短縮されました。

## Gitのブランチ戦略の変更・整備・周知

### 背景

AWS Codeシリーズを利用したCI/CDを整備するために、CI/CDに合わせたGitブランチ戦略を採用するように変更しました。

### 導入した施策

- **GitLabフローを参考にしたブランチ戦略を導入**：main, staging, productionに分割して環境別に分けたことで簡略化。
- **ドキュメントの整備**：Gitフローの手順書を作成し、新メンバーがすぐに参照できるようにしました。

### 導入後の効果

- **マージ作業の安定化**：マージ作業のミスが減少し、リリースが安定しました。
- **CI/CD構築の簡略化**：各ブランチの用途が明確になり、CI/CDの構築難易度が下がりました。

## フロントエンド側へTypeScript・Vueの導入

### 背景

従来は素のJavaScriptやjQueryで書かれていましたが、複雑化したり古くなってメンテナンスが困難になっていました。

### 導入した技術

- **TypeScript**：型を意識することで潜在的なバグの混入を防ぐ目的で導入。
- **Vue.js**：コンポーネントによってコードの再利用性に注目し、開発工数を削減するために導入しました。

### 導入後の効果

- **開発スピードの向上**：コンポーネントの活用によって開発スピードが向上し、機能の実装がスムーズになりました。

## AWSリソースの活用・効率化

### 背景

開発環境はDockerを入れていましたが、AWSで構築している検証環境・本番環境等はEC2に直接サーバー構築して運用を続けているため、スケーラビリティや運用コストに課題がありました。

今はこの課題の解決に以下の施策で取り組んでいます。

### 検証しているサービス

- **AWS CDK**：受託開発で複数のプロジェクトを立ち上げていますが、インフラ構成は似通ったものが多いため、再現性を高くし、AWSインフラ構築に対する工数を削減するためにIaCの導入を進めています。
- **Fargate/ECS**：EC2でホストしていたサービスを移行し、開発環境との差異を減らしたり、セキュリティ面や運用工数削減の観点から優位性があるためFargate/ECSの構成の導入を進めています。

### 期待している効果

- 運用コストの最適化
- 工数削減
- 工数の不足によって対応されにくい、セキュリティ面の脆弱性対応などへの着手

## メッセージ

Dockerの導入からレガシーな環境から脱却してコードを快適な環境で実装していけるようにするためにチームに提案を始めたのは1年半ほど前になります。
基本的にPHPとHTML/CSS/Javascriptが触れるくらいの技術レベルでしたが、提案していくために個人的な検証を重ねたり説明していくことである程度の技術力が身に付き、結果としてインフラ面にもかかわるようになりました。
もし、当時の自分のように技術力がなくても環境を改善していきたい気持ちのある方がこの記事を読んでいただいて、参考にしてくれていたらうれしいです。

## 結論

Dockerの導入が起点となり、複数の改善のための肝となりました。Dockerを導入することで、開発環境の一貫性と再現性が確保され、その結果、テストやCI/CDの導入、コード品質向上の取り組みがスムーズに行えるようになりました。また、Gitのブランチ戦略の整備やフロントエンドのモダナイズにより、チーム全体の開発効率が大幅に向上しました。最後に、AWSリソースの活用により、インフラのスケーラビリティと運用コストの削減が実現し、アプリケーション開発に注力できる環境が整いました。


<h2 data-sourcepos="1:1-1:9">
<a href="#%E5%B0%8E%E5%85%A5"></a>導入</h2>
<h3 data-sourcepos="3:1-3:31">
<a href="#%E4%BD%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E8%A9%B1%E3%81%99%E3%81%AE%E3%81%8B"></a>何について話すのか</h3>
開発環境を改善して、効率化することでアプリケーション開発に注力するため行った（行っている）取り組みについてお話します。
本記事はQmonus Value Streamの投稿キャンペーン記事です。
<h3 data-sourcepos="9:1-9:16">
<a href="#%E6%83%B3%E5%AE%9A%E8%AA%AD%E8%80%85"></a>想定読者</h3>
<ul data-sourcepos="11:1-14:0">
<li data-sourcepos="11:1-11:71">レガシーな環境を改善している（していきたい）人</li>
<li data-sourcepos="12:1-12:50">開発環境改善のアイデアが欲しい人</li>
<li data-sourcepos="13:1-14:0">CI/CDやDevOpsよりな仕事に関わる人</li>
</ul>
<h3 data-sourcepos="15:1-15:51">
<a href="#%E3%81%A9%E3%82%93%E3%81%AA%E4%BA%BA%E3%81%8C%E6%9B%B8%E3%81%84%E3%81%A6%E3%81%84%E3%82%8B%E3%81%8B%E8%87%AA%E5%B7%B1%E7%B4%B9%E4%BB%8B"></a>どんな人が書いているか(自己紹介)</h3>
<ul data-sourcepos="17:1-21:0">
<li data-sourcepos="17:1-17:129">3年目のエンジニアでバックエンドを中心に担当（最近インフラも担当するようになりました）</li>
<li data-sourcepos="18:1-18:51">メインで扱う技術はPHP・TypeScript・AWS</li>
<li data-sourcepos="19:1-19:71">アプリケーション開発とAWSインフラ構築を担当する</li>
<li data-sourcepos="20:1-21:0">受託開発が中心の企業に従事</li>
</ul>
<h2 data-sourcepos="22:1-22:57">
<a href="#%E8%A8%98%E4%BA%8B%E3%81%A7%E8%A7%A6%E3%82%8C%E3%82%8B%E5%8F%96%E3%82%8A%E7%B5%84%E3%81%BF%E5%8F%96%E3%82%8A%E7%B5%84%E3%82%93%E3%81%A0%E9%A0%86"></a>記事で触れる取り組み（取り組んだ順）</h2>
<ol data-sourcepos="24:1-30:0">
<li data-sourcepos="24:1-24:18">Dockerの導入</li>
<li data-sourcepos="25:1-25:36">テスト・静的解析の導入</li>
<li data-sourcepos="26:1-26:44">CI/CDの導入・整備による効率化</li>
<li data-sourcepos="27:1-27:42">Gitフローの変更・整備・周知</li>
<li data-sourcepos="28:1-28:55">フロントエンド側へTypeScript・Vueの導入</li>
<li data-sourcepos="29:1-30:0">AWSサービスの活用</li>
</ol>
<h2 data-sourcepos="31:1-31:18">
<a href="#docker%E3%81%AE%E5%B0%8E%E5%85%A5"></a>Dockerの導入</h2>
<h3 data-sourcepos="33:1-33:10">
<a href="#%E8%83%8C%E6%99%AF"></a>背景</h3>
Docker導入前はwinscpというツールを利用してLinuxサーバに直接SFTPでファイルをアップロードし、Linuxサーバーに割り当てられたローカルIPアドレスをブラウザでたたいてアクセスして動作確認を行う環境でした。この環境は以下のような問題を抱えていました。
<h3 data-sourcepos="37:1-37:10">
<a href="#%E8%AA%B2%E9%A1%8C"></a>課題</h3>
<ul data-sourcepos="39:1-43:0">
<li data-sourcepos="39:1-39:176">
開発環境構築の手間：LinuxサーバーにPHPの実行環境を構築する手間が必要で、新メンバーのオンボーディングが遅延しました。</li>
<li data-sourcepos="40:1-40:189">
環境差異：開発環境、検証環境、本番環境でPHPやミドルウェア等のバージョンが異なり、動作確認が一貫しないことが多々ありました。</li>
<li data-sourcepos="41:1-41:129">
再現性の低さ：サーバ構築の再現性が低く、環境によって動かないコードが存在しました。</li>
<li data-sourcepos="42:1-43:0">
改善の難易度：上記の要因によってアップデートの難易度・工数が跳ね上がり、改善に着手しにくい状況でした。</li>
</ul>
<h3 data-sourcepos="44:1-44:34">
<a href="#docker%E5%B0%8E%E5%85%A5%E5%BE%8C%E3%81%AE%E3%83%A1%E3%83%AA%E3%83%83%E3%83%88"></a>Docker導入後のメリット</h3>
<ul data-sourcepos="46:1-50:0">
<li data-sourcepos="46:1-46:192">
環境の統一と再現性の向上：Dockerを用いることで、全員が同じ開発環境を利用できるようになり、環境差異による問題が解消されました。</li>
<li data-sourcepos="47:1-47:234">
スクラップ＆ビルドの容易化：開発環境の作り直しがしやすくなり、検証作業等がスムーズに行えるようになりました。これにより、改善活動がやりやすくなりました。</li>
<li data-sourcepos="48:1-48:246">
開発サーバーの不要化：開発用途のサーバーを立ち上げて共有する必要がなくなり、ファイルのアップロードの度に発生するほかの作業者への確認などの質問がなくなりました。</li>
<li data-sourcepos="49:1-50:0">
新メンバーのオンボーディングの迅速化：新メンバーが迅速に開発環境を整備できるようになり、生産性が向上しました。</li>
</ul>
<h2 data-sourcepos="51:1-51:36">
<a href="#%E3%83%86%E3%82%B9%E3%83%88%E9%9D%99%E7%9A%84%E8%A7%A3%E6%9E%90%E3%81%AE%E5%B0%8E%E5%85%A5"></a>テスト・静的解析の導入</h2>
<h3 data-sourcepos="53:1-53:10">
<a href="#%E8%83%8C%E6%99%AF-1"></a>背景</h3>
古めのPHPを利用していた背景もあり、コードの品質に課題がありました。これを解決するために、テストと静的解析を導入しました。
<h3 data-sourcepos="57:1-57:25">
<a href="#%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%9F%E3%83%84%E3%83%BC%E3%83%AB"></a>導入したツール</h3>
<ul data-sourcepos="59:1-64:0">
<li data-sourcepos="59:1-59:134">
PHPStan(Larastan)：静的解析ツールとして利用。コードの問題を早期に発見するのに役立ちました。</li>
<li data-sourcepos="60:1-60:152">
PHPcs：コーディング規約に沿ったコードを書くためのツール。チーム全体のコード品質向上に貢献しました。</li>
<li data-sourcepos="61:1-61:80">
PHPmd：メンテナンス性向上のためのコード解析ツール。</li>
<li data-sourcepos="62:1-62:115">
PHPUnit：単体テストフレームワーク。自動テストの導入により、品質保証を強化。</li>
<li data-sourcepos="63:1-64:0">
ESLint・Prettier：JavaScriptとTypeScriptのコード品質を保つためのツール。統一されたコードスタイルを保つことができました。</li>
</ul>
<h3 data-sourcepos="65:1-65:22">
<a href="#%E5%B0%8E%E5%85%A5%E5%BE%8C%E3%81%AE%E5%8A%B9%E6%9E%9C"></a>導入後の効果</h3>
<ul data-sourcepos="67:1-71:0">
<li data-sourcepos="67:1-67:135">
早期発見と修正：バグの早期発見と修正が可能になり、デバッグの手間が大幅に減少しました。</li>
<li data-sourcepos="68:1-68:141">
コードの可読性向上：コードの可読性が向上し、他のメンバーがコードを理解しやすくなりました。</li>
<li data-sourcepos="69:1-69:150">
開発スピードの向上：開発スピードが向上し、新機能の追加や改修がスムーズに行えるようになりました。</li>
<li data-sourcepos="70:1-71:0">
品質保証の強化：自動テストにより、リリース前に問題を発見・修正できるようになり、品質保証が強化されました。</li>
</ul>
<h2 data-sourcepos="72:1-72:44">
<a href="#cicd%E3%81%AE%E5%B0%8E%E5%85%A5%E6%95%B4%E5%82%99%E3%81%AB%E3%82%88%E3%82%8B%E5%8A%B9%E7%8E%87%E5%8C%96"></a>CI/CDの導入・整備による効率化</h2>
<h3 data-sourcepos="74:1-74:10">
<a href="#%E8%83%8C%E6%99%AF-2"></a>背景</h3>
手動でのデプロイが主流で、ミスが発生しやすく、時間もかかっていました。これを解決するためにCI/CDを導入しました。
<h3 data-sourcepos="78:1-78:25">
<a href="#%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%9F%E3%83%84%E3%83%BC%E3%83%AB-1"></a>導入したツール</h3>
<ul data-sourcepos="80:1-83:0">
<li data-sourcepos="80:1-80:122">
GitLab CI：CI/CDパイプラインを構築し、コードの自動テストとデプロイを実現しました。</li>
<li data-sourcepos="81:1-81:106">
GitLab Runner：テストコードが増えた段階で並列化するために導入しました。</li>
<li data-sourcepos="82:1-83:0">
AWS Codeシリーズ：AWSの複数の環境へのデプロイを自動化しました。</li>
</ul>
<h3 data-sourcepos="84:1-84:22">
<a href="#%E5%B0%8E%E5%85%A5%E5%BE%8C%E3%81%AE%E5%8A%B9%E6%9E%9C-1"></a>導入後の効果</h3>
<ul data-sourcepos="86:1-90:0">
<li data-sourcepos="86:1-86:120">
デプロイの安定化：手動デプロイのミスがなくなり、デプロイ作業が安定しました。</li>
<li data-sourcepos="87:1-87:135">
品質保証の強化：自動テストによる品質保証が強化され、デプロイ前の不安が軽減されました。</li>
<li data-sourcepos="88:1-88:144">
開発者の負担軽減：デプロイ作業の自動化により、開発者がコア業務に集中できるようになりました。</li>
<li data-sourcepos="89:1-90:0">
迅速なフィードバック：CI/CDパイプラインにより、迅速なフィードバックが得られるようになり、開発サイクルが短縮されました。</li>
</ul>
<h2 data-sourcepos="91:1-91:54">
<a href="#git%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%88%A6%E7%95%A5%E3%81%AE%E5%A4%89%E6%9B%B4%E6%95%B4%E5%82%99%E5%91%A8%E7%9F%A5"></a>Gitのブランチ戦略の変更・整備・周知</h2>
<h3 data-sourcepos="93:1-93:10">
<a href="#%E8%83%8C%E6%99%AF-3"></a>背景</h3>
AWS Codeシリーズを利用したCI/CDを整備するために、CI/CDに合わせたGitブランチ戦略を採用するように変更しました。
<h3 data-sourcepos="97:1-97:22">
<a href="#%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%9F%E6%96%BD%E7%AD%96"></a>導入した施策</h3>
<ul data-sourcepos="99:1-101:0">
<li data-sourcepos="99:1-99:151">
GitLabフローを参考にしたブランチ戦略を導入：main, staging, productionに分割して環境別に分けたことで簡略化。</li>
<li data-sourcepos="100:1-101:0">
ドキュメントの整備：Gitフローの手順書を作成し、新メンバーがすぐに参照できるようにしました。</li>
</ul>
<h3 data-sourcepos="102:1-102:22">
<a href="#%E5%B0%8E%E5%85%A5%E5%BE%8C%E3%81%AE%E5%8A%B9%E6%9E%9C-2"></a>導入後の効果</h3>
<ul data-sourcepos="104:1-106:0">
<li data-sourcepos="104:1-104:111">
マージ作業の安定化：マージ作業のミスが減少し、リリースが安定しました。</li>
<li data-sourcepos="105:1-106:0">
CI/CD構築の簡略化：各ブランチの用途が明確になり、CI/CDの構築難易度が下がりました。</li>
</ul>
<h2 data-sourcepos="107:1-107:55">
<a href="#%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%82%A8%E3%83%B3%E3%83%89%E5%81%B4%E3%81%B8typescriptvue%E3%81%AE%E5%B0%8E%E5%85%A5"></a>フロントエンド側へTypeScript・Vueの導入</h2>
<h3 data-sourcepos="109:1-109:10">
<a href="#%E8%83%8C%E6%99%AF-4"></a>背景</h3>
従来は素のJavaScriptやjQueryで書かれていましたが、複雑化したり古くなってメンテナンスが困難になっていました。
<h3 data-sourcepos="113:1-113:22">
<a href="#%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%9F%E6%8A%80%E8%A1%93"></a>導入した技術</h3>
<ul data-sourcepos="115:1-117:0">
<li data-sourcepos="115:1-115:100">
TypeScript：型を意識することで潜在的なバグの混入を防ぐ目的で導入。</li>
<li data-sourcepos="116:1-117:0">
Vue.js：コンポーネントによってコードの再利用性に注目し、開発工数を削減するために導入しました。</li>
</ul>
<h3 data-sourcepos="118:1-118:22">
<a href="#%E5%B0%8E%E5%85%A5%E5%BE%8C%E3%81%AE%E5%8A%B9%E6%9E%9C-3"></a>導入後の効果</h3>
<ul data-sourcepos="120:1-121:0">
<li data-sourcepos="120:1-121:0">
開発スピードの向上：コンポーネントの活用によって開発スピードが向上し、機能の実装がスムーズになりました。</li>
</ul>
<h2 data-sourcepos="122:1-122:39">
<a href="#aws%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E6%B4%BB%E7%94%A8%E5%8A%B9%E7%8E%87%E5%8C%96"></a>AWSリソースの活用・効率化</h2>
<h3 data-sourcepos="124:1-124:10">
<a href="#%E8%83%8C%E6%99%AF-5"></a>背景</h3>
開発環境はDockerを入れていましたが、AWSで構築している検証環境・本番環境等はEC2に直接サーバー構築して運用を続けているため、スケーラビリティや運用コストに課題がありました。
今はこの課題の解決に以下の施策で取り組んでいます。
<h3 data-sourcepos="130:1-130:34">
<a href="#%E6%A4%9C%E8%A8%BC%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9"></a>検証しているサービス</h3>
<ul data-sourcepos="132:1-134:0">
<li data-sourcepos="132:1-132:271">
AWS CDK：受託開発で複数のプロジェクトを立ち上げていますが、インフラ構成は似通ったものが多いため、再現性を高くし、AWSインフラ構築に対する工数を削減するためにIaCの導入を進めています。</li>
<li data-sourcepos="133:1-134:0">
Fargate/ECS：EC2でホストしていたサービスを移行し、開発環境との差異を減らしたり、セキュリティ面や運用工数削減の観点から優位性があるためFargate/ECSの構成の導入を進めています。</li>
</ul>
<h3 data-sourcepos="135:1-135:28">
<a href="#%E6%9C%9F%E5%BE%85%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E5%8A%B9%E6%9E%9C"></a>期待している効果</h3>
<ul data-sourcepos="137:1-140:0">
<li data-sourcepos="137:1-137:29">運用コストの最適化</li>
<li data-sourcepos="138:1-138:14">工数削減</li>
<li data-sourcepos="139:1-140:0">工数の不足によって対応されにくい、セキュリティ面の脆弱性対応などへの着手</li>
</ul>
<h2 data-sourcepos="141:1-141:18">
<a href="#%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8"></a>メッセージ</h2>
Dockerの導入からレガシーな環境から脱却してコードを快適な環境で実装していけるようにするためにチームに提案を始めたのは1年半ほど前になります。 
基本的にPHPとHTML/CSS/Javascriptが触れるくらいの技術レベルでしたが、提案していくために個人的な検証を重ねたり説明していくことである程度の技術力が身に付き、結果としてインフラ面にもかかわるようになりました。 
もし、当時の自分のように技術力がなくても環境を改善していきたい気持ちのある方がこの記事を読んでいただいて、参考にしてくれていたらうれしいです。
<h2 data-sourcepos="147:1-147:9">
<a href="#%E7%B5%90%E8%AB%96"></a>結論</h2>
Dockerの導入が起点となり、複数の改善のための肝となりました。Dockerを導入することで、開発環境の一貫性と再現性が確保され、その結果、テストやCI/CDの導入、コード品質向上の取り組みがスムーズに行えるようになりました。また、Gitのブランチ戦略の整備やフロントエンドのモダナイズにより、チーム全体の開発効率が大幅に向上しました。最後に、AWSリソースの活用により、インフラのスケーラビリティと運用コストの削減が実現し、アプリケーション開発に注力できる環境が整いました。

開発環境を改善するためにチームに提案して実践したこと

ryosuke horie

## はじめに

S3＋CloudFrontでホスティングされているプロジェクトでCodePipelineでS3へのデプロイ後にCloudFrontのキャッシュを自動で削除するLambda関数を作成しました。

備忘録として残します。あくまでも簡易的な実装例の1つとして参照してください。

## 概要

HTML/CSS/JavaScriptで構成されている静的サイト。
S3でホスティングしCloudFrontから配信している。
CI/CDがCodePipelineで自動化されている。
CloudFrontのキャッシュの削除を手動でマネジメントコンソールから行っていた。

## 実装
### 1. キャッシュ削除を行うLambda関数を実装
今回、Lambda関数はPythonで実装する。

```bash
import boto3
import time
import os

# Lambdaのエントリーポイント
# HP本番環境のCloudFrontディストリビューションに対してキャッシュ削除を行う
def lambda_handler(event, context):
    client = boto3.client('cloudfront')
    pipeline = boto3.client('codepipeline')
    try:
        # HP本番環境のディストリビューションIDを指定してキャッシュ削除を実行
        invalidation = client.create_invalidation(DistributionId='【ここにCloudFrontのディストリビューションIDを記載】',
            InvalidationBatch={
                'Paths': {
                    'Quantity': 1,
                    'Items': ['/*']
            },
            # CallerReferenceは一意になるように設定する必要があるため、現在時刻を設定
            'CallerReference': str(time.time())
        })

         # CodePipeline ジョブIDを取得
        job_id = event['CodePipeline.job']['id']

        # CodePipeline に成功レスポンスを送信
        pipeline.put_job_success_result(jobId=job_id)

    except Exception as e:
        # CodePipelineのジョブIDを指定して失敗を通知
        pipeline.put_job_failure_result(
            jobId=job_id,
            failureDetails={
                "type": "JobFailed",
                "message": str(e),
            },
        )
```

要点を説明すると、
- CodePipelineから呼び出されることを前提にキャッシュを全削除する。
- キャッシュ削除をする際にCallerReferenceが一意である必要があるので現在時刻を設定
- CodePipelineのジョブIDを取得してキャッシュ削除が完了したことをCodePipelineへ通知する

### 2. Lambda関数用のIAMポリシーを編集

Lambda関数に関連付けしているIAMロールにアタッチされているIAMポリシーに必要な権限を追加する。
CodePipelineへ実行結果を通知するために
- “codepipeline:PutJobFailureResult"
- "codepipeline:PutJobSuccessResult"

Lambda関数がCloudFrontのキャッシュを削除するために
- "cloudfront:CreateInvalidation”
の権限を許可する。

### 3. CodePipelineを編集
S3へのデプロイが完了した後に新しくステージを追加し、アクションプロバイダーをAWS Lambdaに設定する。
2．で実装したLambda関数を呼び出す。
### 4. 動作確認

デプロイを実行し、CloudFrontの対象のディストリビューションのキャッシュ削除の履歴を確認し、実行されていることを確認する。


<h2 data-sourcepos="1:1-1:15">
<a href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB"></a>はじめに</h2>
S3＋CloudFrontでホスティングされているプロジェクトでCodePipelineでS3へのデプロイ後にCloudFrontのキャッシュを自動で削除するLambda関数を作成しました。
備忘録として残します。あくまでも簡易的な実装例の1つとして参照してください。
<h2 data-sourcepos="7:1-7:9">
<a href="#%E6%A6%82%E8%A6%81"></a>概要</h2>
HTML/CSS/JavaScriptで構成されている静的サイト。 
S3でホスティングしCloudFrontから配信している。 
CI/CDがCodePipelineで自動化されている。 
CloudFrontのキャッシュの削除を手動でマネジメントコンソールから行っていた。
<h2 data-sourcepos="14:1-14:9">
<a href="#%E5%AE%9F%E8%A3%85"></a>実装</h2>
<h3 data-sourcepos="15:1-15:58">
<a href="#1-%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E5%89%8A%E9%99%A4%E3%82%92%E8%A1%8C%E3%81%86lambda%E9%96%A2%E6%95%B0%E3%82%92%E5%AE%9F%E8%A3%85"></a>1. キャッシュ削除を行うLambda関数を実装</h3>
今回、Lambda関数はPythonで実装する。
<div class="code-frame" data-lang="bash" data-sourcepos="18:1-55:3"><div class="highlight"><pre><code>import boto3
import time
import os

# Lambdaのエントリーポイント
# HP本番環境のCloudFrontディストリビューションに対してキャッシュ削除を行う
def lambda_handler(event, context):
 client = boto3.client('cloudfront')
 pipeline = boto3.client('codepipeline')
 try:
 # HP本番環境のディストリビューションIDを指定してキャッシュ削除を実行
 invalidation = client.create_invalidation(DistributionId='【ここにCloudFrontのディストリビューションIDを記載】',
 InvalidationBatch={
 'Paths': {
 'Quantity': 1,
 'Items': ['/*']
 },
 # CallerReferenceは一意になるように設定する必要があるため、現在時刻を設定
 'CallerReference': str(time.time())
 })

 # CodePipeline ジョブIDを取得
 job_id = event['CodePipeline.job']['id']

 # CodePipeline に成功レスポンスを送信
 pipeline.put_job_success_result(jobId=job_id)

 except Exception as e:
 # CodePipelineのジョブIDを指定して失敗を通知
 pipeline.put_job_failure_result(
 jobId=job_id,
 failureDetails={
 "type": "JobFailed",
 "message": str(e),
 },
 )
</code></pre></div></div>
要点を説明すると、
<ul data-sourcepos="58:1-61:0">
<li data-sourcepos="58:1-58:92">CodePipelineから呼び出されることを前提にキャッシュを全削除する。</li>
<li data-sourcepos="59:1-59:113">キャッシュ削除をする際にCallerReferenceが一意である必要があるので現在時刻を設定</li>
<li data-sourcepos="60:1-61:0">CodePipelineのジョブIDを取得してキャッシュ削除が完了したことをCodePipelineへ通知する</li>
</ul>
<h3 data-sourcepos="62:1-62:49">
<a href="#2-lambda%E9%96%A2%E6%95%B0%E7%94%A8%E3%81%AEiam%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC%E3%82%92%E7%B7%A8%E9%9B%86"></a>2. Lambda関数用のIAMポリシーを編集</h3>
Lambda関数に関連付けしているIAMロールにアタッチされているIAMポリシーに必要な権限を追加する。 
CodePipelineへ実行結果を通知するために
<ul data-sourcepos="66:1-68:0">
<li data-sourcepos="66:1-66:38">“codepipeline:PutJobFailureResult"</li>
<li data-sourcepos="67:1-68:0">"codepipeline:PutJobSuccessResult"</li>
</ul>
Lambda関数がCloudFrontのキャッシュを削除するために
<ul data-sourcepos="70:1-72:0">
<li data-sourcepos="70:1-72:0">"cloudfront:CreateInvalidation” 
の権限を許可する。</li>
</ul>
<h3 data-sourcepos="73:1-73:28">
<a href="#3-codepipeline%E3%82%92%E7%B7%A8%E9%9B%86"></a>3. CodePipelineを編集</h3>
S3へのデプロイが完了した後に新しくステージを追加し、アクションプロバイダーをAWS Lambdaに設定する。 
2．で実装したLambda関数を呼び出す。
<h3 data-sourcepos="76:1-76:19">
<a href="#4-%E5%8B%95%E4%BD%9C%E7%A2%BA%E8%AA%8D"></a>4. 動作確認</h3>
デプロイを実行し、CloudFrontの対象のディストリビューションのキャッシュ削除の履歴を確認し、実行されていることを確認する。

デプロイ後にCloudFrontのキャッシュ削除をLambda関数で自動化する

## エラーの内容

Cloudfrontとs3を使用してVue製のSPAフロントエンドをホスティングしている時に、「https://example.com/login」のような、root直下以外のurlパスを指定したり、リロードするとCloudfrontのAccessDenyのエラーが表示されてしまった。

## 原因

Cloudfrontのエラーページの設定をしていなかったため。

「/login」のようにroot直下の「/」以外に直接アクセスされたり、リロードされるとCloudfrontはオリジンの対応するhtmlを探しに行ってしまう。

当然、「login.html」のようなページは用意しないのでファイルが存在せず、エラーとなる。

## 解決策

CloudFrontのカスタムエラーレスポンスで、403のときに/index.html（今回は「/」）へ転送するよう設定する。

今回、フロントエンドのインフラをTypeScript版aws cdkで構築しているため、以下のように記述しデプロイした。

```typescript
        // CloudFrontディストリビューションを作成する
		const distribution = new aws_cloudfront.Distribution(this, "Distribution", {
			domainNames: ["example.com"],
			certificate,
			comment: "example.com",
			defaultRootObject: "index.html",
			defaultBehavior: {
				allowedMethods: aws_cloudfront.AllowedMethods.ALLOW_GET_HEAD_OPTIONS,
				cachedMethods: aws_cloudfront.CachedMethods.CACHE_GET_HEAD_OPTIONS,
				cachePolicy: aws_cloudfront.CachePolicy.CACHING_OPTIMIZED,
				viewerProtocolPolicy:
					aws_cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
				origin: new aws_cloudfront_origins.S3Origin(websiteBucket, {
					originAccessIdentity,
				}),
			},
			// 403エラーの時に「/」に飛ばす(SPAのため、リロードや直アクセスに対策するため)
			errorResponses: [
				{
					httpStatus: 403,
					responseHttpStatus: 200,
					responsePagePath: "/",
				},
			],
			priceClass: aws_cloudfront.PriceClass.PRICE_CLASS_100,
		});
```

## 結果

Access Deniedのエラーが表示されることはなくなり、リロードされたり、URLで直接アクセスされても表示できるように修正できました。

## 参考文献

[https://dev.classmethod.jp/articles/s3-cloudfront-spa-angular-403-access-denied/](https://dev.classmethod.jp/articles/s3-cloudfront-spa-angular-403-access-denied/)


<h2 data-sourcepos="1:1-1:21">
<a href="#%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%AE%E5%86%85%E5%AE%B9"></a>エラーの内容</h2>
Cloudfrontとs3を使用してVue製のSPAフロントエンドをホスティングしている時に、「<a href="https://example.com/login%E3%80%8D%E3%81%AE%E3%82%88%E3%81%86%E3%81%AA%E3%80%81root%E7%9B%B4%E4%B8%8B%E4%BB%A5%E5%A4%96%E3%81%AEurl%E3%83%91%E3%82%B9%E3%82%92%E6%8C%87%E5%AE%9A%E3%81%97%E3%81%9F%E3%82%8A%E3%80%81%E3%83%AA%E3%83%AD%E3%83%BC%E3%83%89%E3%81%99%E3%82%8B%E3%81%A8Cloudfront%E3%81%AEAccessDeny%E3%81%AE%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%8C%E8%A1%A8%E7%A4%BA%E3%81%95%E3%82%8C%E3%81%A6%E3%81%97%E3%81%BE%E3%81%A3%E3%81%9F%E3%80%82" class="autolink" rel="nofollow noopener" target="_blank">https://example.com/login」のような、root直下以外のurlパスを指定したり、リロードするとCloudfrontのAccessDenyのエラーが表示されてしまった。</a>
<h2 data-sourcepos="5:1-5:9">
<a href="#%E5%8E%9F%E5%9B%A0"></a>原因</h2>
Cloudfrontのエラーページの設定をしていなかったため。
「/login」のようにroot直下の「/」以外に直接アクセスされたり、リロードされるとCloudfrontはオリジンの対応するhtmlを探しに行ってしまう。
当然、「login.html」のようなページは用意しないのでファイルが存在せず、エラーとなる。
<h2 data-sourcepos="13:1-13:12">
<a href="#%E8%A7%A3%E6%B1%BA%E7%AD%96"></a>解決策</h2>
CloudFrontのカスタムエラーレスポンスで、403のときに/index.html（今回は「/」）へ転送するよう設定する。
今回、フロントエンドのインフラをTypeScript版aws cdkで構築しているため、以下のように記述しデプロイした。
<div class="code-frame" data-lang="typescript" data-sourcepos="19:1-46:3"><div class="highlight"><pre><code> // CloudFrontディストリビューションを作成する
		const distribution = new aws_cloudfront.Distribution(this, "Distribution", {
			domainNames: ["example.com"],
			certificate,
			comment: "example.com",
			defaultRootObject: "index.html",
			defaultBehavior: {
				allowedMethods: aws_cloudfront.AllowedMethods.ALLOW_GET_HEAD_OPTIONS,
				cachedMethods: aws_cloudfront.CachedMethods.CACHE_GET_HEAD_OPTIONS,
				cachePolicy: aws_cloudfront.CachePolicy.CACHING_OPTIMIZED,
				viewerProtocolPolicy:
					aws_cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
				origin: new aws_cloudfront_origins.S3Origin(websiteBucket, {
					originAccessIdentity,
				}),
			},
			// 403エラーの時に「/」に飛ばす(SPAのため、リロードや直アクセスに対策するため)
			errorResponses: [
				{
					httpStatus: 403,
					responseHttpStatus: 200,
					responsePagePath: "/",
				},
			],
			priceClass: aws_cloudfront.PriceClass.PRICE_CLASS_100,
		});
</code></pre></div></div>
<h2 data-sourcepos="48:1-48:9">
<a href="#%E7%B5%90%E6%9E%9C"></a>結果</h2>
Access Deniedのエラーが表示されることはなくなり、リロードされたり、URLで直接アクセスされても表示できるように修正できました。
<h2 data-sourcepos="52:1-52:15">
<a href="#%E5%8F%82%E8%80%83%E6%96%87%E7%8C%AE"></a>参考文献</h2>
<a href="https://dev.classmethod.jp/articles/s3-cloudfront-spa-angular-403-access-denied/" rel="nofollow noopener" target="_blank">https://dev.classmethod.jp/articles/s3-cloudfront-spa-angular-403-access-denied/</a>

【Cloudfront】 SPAをホストする場合、「/」以外のアクセスでリダイレクトさせる

## 概要
諸事情によってRockey Linuxを利用してリモートに開発環境を作成し開発を行っています。

この開発用サーバーからセルフホストのGitLabサーバーへ通信する際にAWS SSMを立ち上げています。

```jsx
aws ssm start-session --target i-xxxxxxxxxxxxx --document-name AWS-StartPortForwardingSession --parameters portNumber="xxx",localPortNumber="xxxxx"
```

このようなコマンドを実行すると403エラーが発生していました。

```jsx
An error occurred (403) when calling the StartSession operation: Server authentication failed: <UnauthorizedRequest xmlns=""><message>Forbidden.</message></UnauthorizedRequest>
```

この解決にLinuxサーバーのローカルタイムゾーンの設定が原因だと判断するまでに時間がかかってしまったので備忘録として残します

## 環境

```bash
$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.3 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.3"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.3"
```

IAMユーザーの権限などには問題がない状態。

## 解決策

```bash
sudo yum update
sudo systemctl start chronyd
sudo reboot
```

Chronydが有効化されておらず、ローカルタイムゾーンが8時間以上ずれていた。

Chronydによって時間を同期させることでSSMのエラーを解決することができました。

## 参考

****【RHEL8/CentOS8】NTPは死んだ。時代はChrony。****

https://qiita.com/thzking/items/c2bcf7d60963b4dab7b6

**chrony の概要および設定**

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-understanding_chrony_and-its_configuration#doc-wrapper

<h2 data-sourcepos="1:1-1:9">
<a href="#%E6%A6%82%E8%A6%81"></a>概要</h2>
諸事情によってRockey Linuxを利用してリモートに開発環境を作成し開発を行っています。
この開発用サーバーからセルフホストのGitLabサーバーへ通信する際にAWS SSMを立ち上げています。
<div class="code-frame" data-lang="jsx" data-sourcepos="6:1-8:3"><div class="highlight"><pre><code>aws ssm start-session --target i-xxxxxxxxxxxxx --document-name AWS-StartPortForwardingSession --parameters portNumber="xxx",localPortNumber="xxxxx"
</code></pre></div></div>
このようなコマンドを実行すると403エラーが発生していました。
<div class="code-frame" data-lang="jsx" data-sourcepos="12:1-14:3"><div class="highlight"><pre><code>An error occurred (403) when calling the StartSession operation: Server authentication failed: &lt;UnauthorizedRequest xmlns=""&gt;&lt;message&gt;Forbidden.&lt;/message&gt;&lt;/UnauthorizedRequest&gt;
</code></pre></div></div>
この解決にLinuxサーバーのローカルタイムゾーンの設定が原因だと判断するまでに時間がかかってしまったので備忘録として残します
<h2 data-sourcepos="18:1-18:9">
<a href="#%E7%92%B0%E5%A2%83"></a>環境</h2>
<div class="code-frame" data-lang="bash" data-sourcepos="20:1-39:3"><div class="highlight"><pre><code>$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.3 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.3"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.3"
</code></pre></div></div>
IAMユーザーの権限などには問題がない状態。
<h2 data-sourcepos="43:1-43:12">
<a href="#%E8%A7%A3%E6%B1%BA%E7%AD%96"></a>解決策</h2>
<div class="code-frame" data-lang="bash" data-sourcepos="45:1-49:3"><div class="highlight"><pre><code>sudo yum update
sudo systemctl start chronyd
sudo reboot
</code></pre></div></div>
Chronydが有効化されておらず、ローカルタイムゾーンが8時間以上ずれていた。
Chronydによって時間を同期させることでSSMのエラーを解決することができました。
<h2 data-sourcepos="55:1-55:9">
<a href="#%E5%8F%82%E8%80%83"></a>参考</h2>
【RHEL8/CentOS8】NTPは死んだ。時代はChrony。
<iframe id="qiita-embed-content__0d1a7c0dad641b2a0d76ade626a550a2" src="https://qiita.com/embed-contents/link-card#qiita-embed-content__0d1a7c0dad641b2a0d76ade626a550a2" data-content="https%3A%2F%2Fqiita.com%2Fthzking%2Fitems%2Fc2bcf7d60963b4dab7b6" frameborder="0" scrolling="no" loading="lazy" style="width:100%;" height="29">
</iframe>

chrony の概要および設定
<iframe id="qiita-embed-content__d65e918344181433fbabe4e7c3428878" src="https://qiita.com/embed-contents/link-card#qiita-embed-content__d65e918344181433fbabe4e7c3428878" data-content="https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fja-jp%2Fred_hat_enterprise_linux%2F7%2Fhtml%2Fsystem_administrators_guide%2Fsect-understanding_chrony_and-its_configuration%23doc-wrapper" frameborder="0" scrolling="no" loading="lazy" style="width:100%;" height="29">
</iframe>

TECH

Recent Qiita Posts