CI/CD自動化パイプラインの実現1構想編CI/CD自動化パイプラインの実現1構想編1.はじめに前回の記事によって、アプリケーションを包括的にウォッチする環境が概ね整ったことが分かります。そこから、メモリリークやDBのスペック調整を一通り行い、クラウドサービス上で動く現行環境のチューニングや細かいセキュリティ上の問題を一度解消することができる手がかりが得られると思います。・前回の記事(見える化を行ったら(APサーバ編))https://dev.to/mizuki04/devsecops-1hfしかし、監視基盤から得られる諸問題は各サービスの状況に依存したスペシフィックな問題である為、打ち手について今回は割愛します。今回取り上げるのは、一度上記のように環境をブラッシュアップした時にさらにもう一つ抜本的な改革を進める為にはという問いに対する一つの実行例を述べます。一般的にサービスをリリースして安定的にユーザを獲得できている場合、最も避けたいのはダウンタイムだと思います。そこで気になるポイントとして、本番環境のデプロイに時間がかかっている、だったり手動によるデプロイの為ヒューマンエラーに繋がる等の事象が見受けられます。できるならmasterブランチにマージを行ったら、そのあとはコーヒー☕️でも飲みながら一服をしたいと思うのは自然な発想です。それを実現するのが、CI/CD自動化パイプラインの実現です。日本語では継続的インティグレーション/継続的デリバリーといいます。CI/CDは1つの技術を指すものでなく、ソフトウェアの変更を常にテストして自動で本番環境にリリース可能な状態にしておく、ソフトウェア開発の手法を意味します。CI/CDを取り入れると、バグを素早く発見したり、変更を自動でリリースしたりできるようになります。modeパイプラインのポテンシャルを引き出して、ダウンタイムを最小にする為には、アプリケーションをDockerlizeし、コンテナベースの運用にすることがほぼ不可欠であるのでそちらも踏まえて今後記載していきます。2.ソース管理の環境と選定サービス上記を実現するにあたり、ソースを管理しているサービスによって実現の方法は異なります。概ね、Github/Gitlabどちらかになるかと思いますが、今回はGitlabのユースケースを用いてこのプロジェクトの解説を行います。Githubの場合はGithubActionsやCircleCIなどが一般的なように思え、Gitlabの場合は、CICDのサードパーティサービスに加え、Gitlab標準のGitlabCIという機能があります。AWS環境ならばCodepipelineなどのマネージドサービスが存在します。予算や規模感に応じて取れる選択肢は変わりますが、コスト・時間的なパフォーマンス・周辺機能の充実で選ぶと間違いないかと思います。従量課金制のサービスが多い中、今回のユースケースでは、コストが無料であるGitlabCIを選択致しました。3.クラウドサービスの環境とコンテナオーケストレーションツールAWS/GCP/Azureそれぞれの環境に合わせて、CI/CD周りの自動化を行うならばコンテナオーケストレーションツールの利用もほぼ必須だと言えるかと思います。今回は、AWS環境のEC2インスタンスベースで運用を行なっていたサービスを移行する為AWSフルマネージド型のコンテナオーケストレーションサービスであるECSを選定致しました。サービスであるEKSも登場しています。ECSを選定した理由としては、現在行っている運用作業を減らすとともに、可視化や拡張性を担保できるなど以下のメリットが考えられます。別のコンテナオーケストレーションとは異なり、仕組みがシンプルで、馴染みのあるEC2をそのまま利用することができる等です。パイプライン+コンテナオーケストレーションツールによって、デプロイの自動化・GUIベースでのアプリケーションの管理が可能となります。今回目標としていたのは、0.5~1時間程度のデプロイに手動で掛かっていた時間を完全に自動化することです。次回からは具体的なhowの話を行いたいと思います。