Author: softcompdev2

  • インフラ構築手順書の更新

    ECSを用いてサーバー構築のタスクを実施していただきました。クライアント企業に納品する設計資料として、インフラ構築手順書を作成してください。 開発タスク インフラ構築手順書 基本編で作成したインフラ構築手順書に、ECSを用いたサーバー構築手順を追記してください。 運営側で作成したインフラ構築手順書のテンプレートを掲載します。こちらを参考に作成にチャレンジしてみてください。 期待する成果 インフラ構築手順書上記、成果物が完成したら、レビュー依頼を行ってください。

  • ECSでコンテナを作成するには?

    今回はDockerを動かすための環境構築とコンテナ作成、そして作成したコンテナをECS上で動かし、動作を確認するまでの手順を解説していきます。 Dockerの環境構築とコンテナ作成 コンテナの作成環境 コンテナを作成するためにはDockerがインストールされた環境が必要になります。今回はAWSのEC2インスタンスにDockerをインストールし、コンテナの作成をしていきます。解説をするために作成したAWS環境はこのような形です。 リージョンはどこでも構いません。VPCを作りDocker構築用のEC2インスタンスを作成しています。SubnetはSSH用にグローバルIPを付与しているため、Public Subnetとして作成していますが、EC2 instance ConnectやAWS Session Manager(SSM)等を使う方法もありますので、接続方法はお好みの方法で構いません。インターネット経由でSSH接続をする場合には、Security Groupで接続元を制限しましょう。 では、EC2インスタンスに接続ができたら、Dockerの実行環境を作成していきます。・OS情報の確認 ・Dockerのインストールと実行yumコマンドを使ってDockerをインストールします。 インストールが終わりましたら、Dockerを起動します。 念のため、起動していることを確認しましょう。 ・Dockerのバージョンは以下の通りです。 コンテナの作成準備 Dockerではdockerfileというファイルでどんなコンテナを作成するかコンテナの中身を定義しています。今回は簡単なWebページを表示するためのコンテナを作成します。・作業用のディレクトリを作成します。 ・dockerfileを作成します。 Dockerではコンテナの元となるコンテナイメージを、Docker Hubなどのレジストリ(コンテナの置き場所)からダウンロードすることができます。今回はDockerの公式レジストリであるDocker hubを使用しています。(Docker hub:https://hub.docker.com/)dockerfile内のFROMでコンテナのイメージを指定しています。今回はApache HTTP サーバー用のイメージである「httpd:2.4」というイメージを使用します。COPYでカレントディレクトリにあるindex.htmlを、/usr/local/apache2/htdocs/index.htmlにコピーをしています。・簡単なWEBページ用のhtmlを作成します。 これでコンテナの作成準備が完了しました。少しだけ余談ですが、現時点ではまだコンテナのイメージを作成していません。コンテナの作成は次章で行いますが、事前に作成してみたいという方は下記のコマンドで作成・確認することが出来ます。・コンテナの作成dockerfile、index.htmlのあるディレクトリで下記のコマンドを実行してください。 ※ドットまでがコマンドです。http-testというコンテナを作成する場合は下記のようになります。 ・コンテナの確認 http-testとhttpdの2つのコンテナが作成されていることが分かります。httpdはdockerfileのFROMで指定した、http-testを作成した際に使用した元のコンテナイメージとなります。・コンテナを実行する。 ※-dオプションでバックグラウンド実行・コンテナの実行確認 STATUSがUpとなっているので、コンテナIDがfcf95ec68816として、実行されていることが分かります。・コンテナの中(shell)に入る 無事にコンテナの中に入り、Shell(bash)が表示されました。 作ったコンテナをECRにPush ECR(Elastic Container Registry)とはDockerのコンテナイメージを保存するためコンテナレジストリです。ECSでコンテナを扱うためにはレジストリと呼ばれるコンテナ置き場に、コンテナを配置する必要があります。AWSではコンテナレジストリとしてECRを用意していますが、他にDucker HubやGoogle CloudのContainer Registryなどにも対応しています。今回はECRのプライベートレジストリ(外部公開をしないレジストリ)を使用します。 ECRの作成 AWSマネジメントコンソールを使いECRを作成します。AWSマネジメントコンソールからECSを検索し、左側のメニューから「Amazon ECR」を選択します。 右側にあるレポジトリの作成にある、「使用方法」をクリックします。 「レポジトリを作成」画面が表示されます。①「プライベート」を選択します。※パブリックを選択すると外部に公開されますのでご注意下さい。②お好みのリポジトリ名を入力して下さい。※本ブログ記事では「bare_test」として作成します。 今回は「イメージスキャンの設定」、「暗号化設定」は設定しませんので、入力が終わりましたら「リポジトリを作成」を選択します。 ECRにDockerイメージをPush 作成されたECRにチェックを入れて、「プッシュコマンドの表示」をクリックします。 Mac/Linux用のコマンドと、Windows用のコマンドが表示されますので、環境に合わせてコマンドを実行します。基本的にはこの通りに実施すれば問題ありません。今回は用意したEC2インスタンスからPushしますので、Mac/Linux用のコマンドを実行していきます。 「Login Succeeded」と表示されれば、認証成功です。この時点でエラーが出る場合は、Linuxの実行権限、IAMロールなどの権限周りを確認して下さい。続いて、先程作成したdockerfileを使いイメージを構築(ビルド)します。コンテナを作成(build)します。 dockerイメージの構築に失敗する場合は、dockerfile中のスペルミスやファイル名が正しいかを確認してください。続いてイメージにタグを付けて、ECRにdockerイメージをプッシュします。 これでECRにイメージをプッシュすることが出来ました。この後、必要となりますので、URIをメモしておきましょう。 ECSでコンテナを動かしてみよう ここからはECSのクラスターとタスクを作成し、実際にコンテナを実行していきます。図の赤枠の部分となります。 実行準備…

  • AWS ECSとは?

    ECSとは、Amazon Elastic Container Service(Amazon ECS)の略で、AWSでDockerコンテナのデプロイや運用管理を行うための、フルマネージドなコンテナオーケストレーションサービスです。近年、アプリケーションやWeb開発において「コンテナ」や「ECS」という言葉をよく耳にしますが、実はよく知らない、実際に使ったことはないという方も多いのではないでしょうか? 今回は、コンテナやECSについて詳しく知らない方や、知ってはいるけど触ったことはない方に向けて、コンテナとは何か、ECSとはどういったサービスなのかを用語の意味など含め解説していきます。 コンテナとは コンテナの特長と概要 コンテナとは、「アプリケーションを動かすための環境を仮想化する技術」です。アプリケーションを動作させるには、アプリケーション本体やOSの他にミドルウェア、ライブラリなど必要な要素が複数あります。コンテナはそれらの要素をパッケージングして、1つにまとめる技術と考えれば分かりやすいかもしれません。 コンテナを動かすためのプラットフォームはいくつかありますが、本記事ではコンテナのデファクトスタンダードである「Docker」をベースに解説していきたいと思います。 仮想マシンとコンテナの違い 従来の仮想化技術は、「ハイパーバイザー型」と言われる方法が主流でした。これは、サーバ上でハイパーバイザーと呼ばれる仮想化ソフトウェアを起動させることで、仮想的にOSを動かすための環境を構築する方法です。例えばWindows OS上でLinux OSを動かしたり、MacOSでWindowsを動かしたりと、ホストOSの種類に縛られず仮想マシンごとにOSをインストールできるため、自由度の高いOS動作環境を構築することができます。 しかし、自由度が高い反面、ハイパーバイザー型の仮想環境では必要なものをOSから全てインストールする必要があります。そのため、使わない機能やソフトウェア、ミドルウェアなどもインストールされてしまい、結果として必要な動作スペックが上がってしまったり、ディスク容量が肥大化してしまったりといったデメリットがありました。 コンテナ型の仮想化技術では、カーネルや基本ソフトウェアと呼ばれるOSの基本的な役割をコンテナエンジン(Docker)が担うことにより、より少ない容量、より少ないリソースで稼働させることが可能になります。 カーネルとは、OSのコアとして、ハードウェアとソフトウェアの仲介など、OS機能の基本的な役割を担う部分です。シェルや、よく使うコマンドは基本ソフトウェアと呼ばれています。カーネルと基本ソフトウェアにOSとしての独自機能を持たせたものがUbuntuやCentOSと言ったLinux OSと呼ばれているものになります。 コンテナで使用するOSに当たる部分には、必要最低限のコマンド、ミドルウェアで構成されているのが一般的で、ハイパーバイザー型と比較して非常に小さいサイズとなっています。 ハイパーバイザー型ではOSのインストールディスクやISOイメージなどからOSをインストールして構築しますが、Dockerではコンテナの元となるイメージを、Docker Hubなどのリポジトリサービスからダウンロードします。Docker HubはDocker社が提供しているDockerの公式リポジトリで、誰でも使用できる公開リポジトリと、非公開のプライベートリポジトリがあり、公開リポジトリにはすぐに使用できる、様々なアプリケーションのDockerイメージが提供されています。 コンテナのメリットと課題 コンテナの概要や、既存の仮想環境との違いについて説明しました。次はコンテナを活用するメリットと、利用時の課題について解説します。 コンテナのメリット ・処理速度が早い 無駄なものを排除したコンテナは、非常に軽量で実行速度が早いことが特長の一つです。ほとんどの場合、コンテナの実行は数秒で完了します。 ・容量が少ない コンテナエンジンがカーネルの役割を担い、コンテナは不要なソフトウェアを省いているため、Docker Hubで公開されているコンテナのイメージは数MB~数百MB程度と非常に軽量です。 ・環境移行が容易 Dockerでは作成したコンテナを別の環境に移行することが簡単にできます。そのため、ホストのリソースが足りなくなったので、別のサーバにコンテナをコピーして実行したいという場合でも環境構築と移行の手間を軽減することが可能です。 ・自分のアプリ開発に集中できる 開発環境をコンテナの中に構築しておくことで、開発者はアプリ間の干渉を気にせず、自身の開発に集中できます。 ・サーバのリソースを有効活用できる 1台のサーバで複数のコンテナを実行できます。先程解説した通り「ハイパーバイザー型」と比較し必要なリソースが少なく済むため、より多くのコンテナを実行することが可能です。 コンテナが持つ課題 ・煩雑な運用管理 コンテナには「1コンテナに1プロセスだけを起動させる」というベストプラクティスがあります。ベストプラクティスに沿う形にした場合、Webサーバ用のコンテナ、データベース用のコンテナなど、必要に応じてコンテナを分ける必要があるため、結果として沢山のコンテナを運用・管理しなくてはいけないという課題があります。 ・対障害性 「ハイパーバイザー型」と同様に、ホストOSが何かしらの障害で起動しなくなってしまった場合、その中で動いているコンテナ全てに影響が出てしまい、対策をしていないとサービスの提供に影響が出てしまいます。 コンテナオーケストレーション コンテナの課題は「煩雑な運用管理」と「対障害性」であると解説しました。本番環境でコンテナを動かす場合、一部のコンテナが停止しても提供しているサービスが停止しないように、可用性や冗長性を考慮し、複数のコンテナを、複数のサーバに分散させておく方が安全です。 しかし、多数のコンテナを複数台のサーバで運用していると、どのサービスのどのコンテナがどのサーバで動いているのかを常に意識し、管理し続ける必要があり、運用負荷が高まってしまいます。そして運用の複雑化は、ヒューマンエラーを引き起こしかねません。これらの課題を解決するのがコンテナオーケストレーションと呼ばれる、コンテナの管理・運用を自動化するための技術です。コンテナオーケストレーションは複数台のサーバをクラスターとして構成し、クラスター上でコンテナを自動配置し、ロードバランシングする機能を有します。 次項ではコンテナオーケストレーションサービスとしてAWSのECSについて解説をしていきます。 ECSとは ECSの特長 ECSとは、Elastic Container Serviceの略で、AWS(Amazon Web Service)上でDockerコンテナを管理するための、フルマネージド型のコンテナオーケストレーターです。コンテナオーケストレーターはコンテナの実行環境ではないため、ECSを理解するには、ECS自体がコンテナの正常稼働をサポートするサービスであることを意識する必要があります。コンテナオーケストレーションは「データプレーン」と「コントロールプレーン」という2つの概念から成り立っています。 コントロールプレーン:コンテナを管理するためのサービスデータプレーン:コンテナを稼働させるためのサービス ECSはコンテナを管理するためのコントロールプレーンとなり、AWSではデータプレーンをとして、3つの起動タイプを提供しています。 ECSの起動タイプ…

  • デプロイ環境の構築(App Runner)

    先程、ドローンベンチャー企業の生産部品の在庫管理システムのAWS構成図を示しました。このアーキテクチャに従い、AWSにインフラを構築、App Runner を用いて Java マイクロサービスをデプロイしてください。 デプロイ手順 https://github.com/dotlife-dev/lxp-practical-project/tree/main/drone#%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4-app-runner-with-ecs のREADMEを参照して、AWSにインフラを構築、AWS App Runner を使用してJava マイクロサービスをデプロイしてください。 詳しくは 「Spring Boot アプリケーションをお手軽に本番運用」https://aws.amazon.com/jp/builders-flash/202303/spring-boot-app-with-apprunner-cdk/?awsf.filter-name=*all を参考にしてください。 https://zenn.dev/thirosue/books/b3fa0e1150f110/viewer/46a040 期待する成果 AWS App Runner を利用して Java マイクロサービスがデプロイできていること。

  • サーバー、データベース、ネットワークの構築、セキュリティの設定 (App Runner)

    開発タスク 先程、ドローンベンチャー企業の生産部品の在庫管理システムのAWS構成図を示しました。このアーキテクチャに従い、AWSにインフラを構築、App Runner を用いて Java マイクロサービスをデプロイしてください。 構築するAWSサービス ※ データベースとして、RDS / Aurora の PostgreSQL を用いますが、今回は運営側ですでに構築したAuroraに利用するため、このタスクで構築する必要はありません。https://github.com/dotlife-dev/lxp-practical-project/blob/main/drone/dev/src/main/resources/application.properties にアクセス情報を記載しています。 App Runner の構築手順 https://github.com/dotlife-dev/lxp-practical-project/tree/main/drone#%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4-app-runner-with-ecs のREADMEに概要を記載しています。 App Runner はフルマネージド型のコンテナアプリケーションサービスであり、簡単に ECS・Fargate で Web アプリを構築できます。 AppRunner 上ではビルドコマンドとスタートコマンドを設定します。 下記URL「Spring Boot アプリケーションをお手軽に本番運用」に詳しい手順が記載されていますので、ご参考ください。 https://aws.amazon.com/jp/builders-flash/202303/spring-boot-app-with-apprunner-cdk/?awsf.filter-name=*all https://zenn.dev/thirosue/books/b3fa0e1150f110/viewer/46a040 期待する成果 Java マイクロサービスをデプロイするために、App Runner が構築できていること。 VPCなど必要なネットワーク設定ができていること。

  • アーキテクチャ (App Runner)

    アーキテクチャ AWS構成図 ドローンベンチャー企業の生産部品の在庫管理システムのAWS構成図です。 Web アプリフルマネージドサービス AWS App Runner を用いて Java マイクロサービスをデプロイします。コンテナ管理にAmazon Elastic Container Registry (Amazon ECR) を使用します。 テクノロジースタック App Runner サーバーとして、App Runner を用います。AWS App Runner はフルマネージド型のコンテナアプリケーションサービスであり、インフラストラクチャやコンテナの経験がなくても、ウェブアプリケーションや API サービスを構築、デプロイ、実行できます。 https://aws.amazon.com/jp/apprunner/ RDS / Aurora データベースとして、RDS / Aurora の PostgreSQL を用います。 ※ 今回は運営側ですでに構築したAuroraに利用するため、このタスクで構築する必要はありません。 https://github.com/dotlife-dev/lxp-practical-project/blob/main/drone/dev/src/main/resources/application.properties にアクセス情報を記載しています。 ソーステクノロジースタック Java マイクロサービス (Spring Boot で実装されたもの) と Docker にデプロイされたものです。 参考 https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-java-microservices-on-amazon-ecs-using-amazon-ecr-and-aws-fargate.html

  • AWSアカウントの作成

    運営からの連絡 このコースを受講している皆様ひとりひとりにAWSアカウントを発行します。 Discord で、運営側に「AWSアカウントの発行」を依頼してください。運営側で、AWSアカウントを作成、アカウント情報をお渡しします。 受け取ったアカウントで、AWSにログインできるかご確認ください。 AWSのリンクは https://console.aws.amazon.com/console/home です。

  • セキュリティテスト実施報告書

    品質保証として、セキュリティテストを実施することになりました。Javaのアプリケーションに脆弱性が存在し対策がされているか検証します。 今回、セキュリティ診断ツール「OWASP ZAP(オワスプ・ザップ)」を用いて、Webアプリケーションの脆弱性をチェックします。 タスク内容 セキュリティテストOWASP ZAPの実施結果を実施報告書としてドキュメントにまとめてください。 期待される成果 セキュリティテスト実施報告書上記、成果物が完成したら、レビュー依頼を行ってください。

  • 開発環境構築

    前提知識 以下の前提知識が必要となります。わからない技術がある場合、事前に調べてから取り組んでください。 リポジトリ作成 https://github.com/dotlife-dev/lxp-practical-project/tree/main/drone-inventory-system を自身のprivateリポジトリに fork してください。 https://github.com/dotlife-dev/lxp-practical-project/tree/main/drone-inventory-system に対して commit や merge request などは絶対にしないでください。 リポジトリ作成後、下記のGitHubユーザーの招待を行ってください。 ローカル環境 README に記載されている方法でローカル環境を構築してください。 https://github.com/dotlife-dev/lxp-practical-project/blob/main/drone-inventory-system/README http://localhost:8080/admin/ をブラウザで立ち上げて、画面が表示されると環境構築完了です。 これから、このJavaのアプリケーションの開発を行っていただきます。

  • 運用報告書の作成

    システムをローンチしたあとは、運用保守フェーズに移行します。 月末に運用報告書をクライアント企業に提出、報告します。 タスク内容 運用報告書を作成してください。 システム運用報告書を書く際には、以下の手順やセクションを考慮してください。 テンプレート システム運用報告書のテンプレートを用意していますので、お使いください。 期待される成果 システム運用報告書上記、成果物が完成したら、レビュー依頼を行ってください。