EC-CUBE3をAWSでVPC、EC2の順に作ってインストール!無料枠テスト段階で約200円/月。

aws-eccube3名古屋のWEBサイト企画・設計・開発 インフォタウン(Info Town)を参照しながら、EC-CUBE3をAWSでVPC、EC2の順に作ってインストールしました。躓いた点を記載します。

1.AWS VPCでEC2へSSH接続するまで

2.AWSへEC-CUBE3をインストール : EC-CUBE3

EC-CUBE3をAWSで動かすまでの大まかな手順

  1. VPC(Virtual Private Cloud)を作って、サブネット内に仮想マシンインスタンスをEC2(Elastic Compute Cloud : 仮想サーバー)で構築し、SSH接続
  2. LAMP(Linux/Apache/mySQL/php)環境構築、EC-CUBE3インストール

※AWSから支給される長い初期ドメインではなく独自ドメインを利用したい場合、AWSのRoute53で Elastic IP をAレコードで繋いでください。テストサイトであればfreenomの無料ドメインで『Ruote53』を使うことが出来ますが、『Route53』は費用が発生します。お金をかけたくない人は気を付けてください。また、SSL( Let’s Encrypt )についても改めて記事を書く予定です。その他、静的サイトの場合はAWSのクラウドストレージ『S3』にバケットを作って、『Route53』で独自ドメインを設定して使う事になります。

金額

AWSを使い始めてこの記事で実行した『VPCを1つ、Amazon Linux AMIのEC2インスタンスを1つ、Elastic IPを1つ、Route53を1つ』の環境で最初の1年以内の無料枠で1ヶ月USD 2.05 程度でした。為替は最近106円くらいなので、約217円です。内訳として、90%以上がRoute53の料金で、残りは税金でした。テスト構築の為、ドメインはDotTK(Freenom)で無料調達しました。

1.AWSでVPC(Virtual Private Cloud)を作って、仮想マシンインスタンスをEC2(Elastic Compute Cloud : 仮想サーバー)で構築し、SSH接続

自宅サーバー(作った事は有りませんが)と違うのは、おそらく、『AWSで選択したリージョン(データセンターの立地の事)内にVPCクラウド空間の外枠の箱をAWS内で立ち上げて、その中にサブネット、セキュリティグループ(ファイヤーウォール)、EC2インスタンス(仮想サーバー)やらを立ち上げて、インターネットゲートウェイ(家庭用ルーターに近い)に通信プロトコル別の穴を開けて、インターネット(VPNの場合はVGW)などに対して通信プロトコルをセキュリティの事も考えながら繋ぐ』というあたりでしょうか。自宅サーバーよりもドメイン周りが楽、ネットワーク知識がより必要な感じ。

この段階で躓いた点はいくつかありますが、大前提としてリージョンを日本にしたい方は、コンソール右上のリージョンで『アジアパシフィック(東京)』になっているか?一番最初に確認しましょう。デフォルトはオレゴンだった様な気がします。初心者の方は、VPCやEC2を作っている途中の過程で日本ではないリージョンに気付いて振り出しに戻らざる負えなかったり、嵌まりやすそう。リージョン別に料金も異なります。少なからず、日本を選んだ方がレイテンシーは小さいと思います。

また、VPCダッシュボードの青いボタンの「VPCウィザードの開始」ではなく、VPC⇒青いボタンの「VPCの作成」から進めていったほうがいいです。「VPCウィザードの開始」からいくと、ググって進めていこうとしても色々と参照したいエントリーと違う記事が出てきて、最初は用語もよくわからない為、行き詰まり、時間をかなり無駄にしました・・・。

今回は1インスタンスだけ作りましたが、下記の2つの図を見ながら考えると速かったです。サブネットのNACL(Network Access Controll List)のインバウンド(受信)/アウトバウンド(送信)の設定などを確実に理解すると速いです。

AWSクラウドネットワーク例 インバウンドとアウトバウンドを理解する

上記の図説よりも解説が端折り気味になりますが、VPC(仮想ネットワーク)の箱の中にサブネットの箱が有って、その中でセキュリティグループがEC2インスタンスの外壁ファイヤーウォールとして番人してる感じ。セキュリティグループがウェルノウンポートなどの通信プロトコルの送受信の管理人をしていると考える。Azureとの違いは、EC2がサブネット指定できない事。リソース管理しにくくて厄介。AWSのファイヤーウォールはサブネットの外側がNetworkACL(通信プロトコルの送受信の管理人、ステートレス/ステートフル)、EC2インスタンスに対するファイヤーウォールがセキュリティグループ(通信プロトコルの送受信の管理人、ステートフル)となっている事も、Azureと違ってウザイ。AzureならNSG(ネットワークセキュリティグループ)は、サブネット、NIC(ネットワークインターフェイスカード)、クラシックの仮想マシンの3ヵ所共通。NICに対するNSGというAzureの方式は、個人的には非常にわかりやすくていいと思う。

きちんと機能しない時は、図を見ながらどこでどの通信プロトコルが途切れているか?http80番、SSH22番、https443番など・・・、1つずつ確認すると解決できます。

AWSの NetworkACL と セキュリティグループ の設置可能場所とステートレス/ステートフルなどの違いについて、把握する事は非常に大切なので、AWS帝王のクラスメソッドの記事などをしっかり見てください。マジでAWSとAzureでこういうところを統一してほしい。時間泥棒。特にBizsparkが無いAWS!無料範囲が認識しにくい!無理な話かもしれないけど、販売エージェントの学習中は金をとるな!負け犬ヘッポコおやじの遠吠えです(笑)。仮想化基盤を提供する王者側にならない限り、IT土方を抜け出す事は無理ですな・・・。Xenで作っている方と1人お会いさせてもらったけど、サービス化はどんだけ資金調達必要なんだろ?ホンマ怖い。勇気無い。

ELB(Elastic Load Balancer)を置く場合は、ELBサブネットを最前線に構築する場合が有る

igw-vgw-elb-aws-cloud-design

AWSサミット2017のネットワークのセッションで、IGW(InternetGateWay)のAvailability zone向けにELBをつないだ空っぽのElastic Subnet(唯一のパブリックサブネット)をWEBサーバーの前に配置して、VGW(VirtualGateWay)のAvailability zone向けにも同じように用意した中身が何もないElastic Subnet(プライベートサブネット)に繋がっています。こちらのElastic Subnet(プライベートサブネット)はVPC endpoint を介してS3と繋がっています。同一のVPC内でIGWとVGWでAvailability zoneに別けて構築する公開サービスのデザインパターンです。ELB用で空っぽな前衛的なElasticSubnetが特徴的。

2.LAMP(Linux/Apache/MySQL/php)環境構築、EC-CUBE3インストール

EC-CUBE3インストール

EC2でAmazon Linux AMIのインスタンス(仮想マシン)を選びました。インスタンスの再起動によってIPアドレスが変更されると面倒なので Elastic IP(固定グローバルIPアドレス) を発行し、EC2インスタンスと結び付けてPublic IPアドレスを固定します。尚、Elastic IPはIPアドレスの独占料金がインスタンスと結び付けられていない場合に発生しますのでご注意ください。TeraTerm等のSSH接続については、デフォルトユーザーでec2-userを入力し、EC2インスタンス設定の際に作った公開鍵を指定します。そしてLAMP(Linux/Apache/MySQL/php)環境の構築です。

LAMP環境構築は Clam AV の更新が出来ない事以外は順調に進みました。Linux向けの Anti Virus は他のものを模索した方がいいかも知れません。

WAF、IDS/IPSはどうする?

WAF、IDS/IPSは、もちろん付いて無いので別途お金必要です。オープンソースのWAFならModSecurityやIDS/IPSならSuricataやSnortなどあたりです。お金出すなら、WAFはAWS WAFやBarracudaやシマンテックのクラウド型WAFなど、そしてIDS/IPSはCheck Point Virtual Appliance for Amazon Web Servicesなど。個人的にはシグネチャ運用など無理なのでクラウド型WAFの攻撃遮断くんでWAFもIDS/IPSも一気にやっちゃうのが楽だと思いますが、想定PVやPV成長見込や予算やアーキテクトによってケースバイケースで導入製品などを考えなくてはいけません。TrendMicroのDeepSecurityなども全体カバー的に土俵に乗ってくると思われます。基本的に、セキュリティ商品は5分間のピークトラフィックで最も高い部分に対して従量課金だったり、もしくはURLのページ数に対して料金が比例するなど、大規模サービスにとって、かなり比較検討もやりにくい。VPSなどのホスティング会社が、どこかのWAFやIDS/IPSベンダーのFQDN無制限プランみたいなやつに入ってくれているケースで、あれば固定費化できるなど、クラウドで完全オリジナルという環境でセキュリティをがっつり担保する為には、それらの予算が必要。

その上に、PCI DSSもあり、Eコマースの取引量が多いケースでは、蔑ろにしていてはかなりまずい場合も存在する。

ついでに監視でzabbixというところでしょうか。DDosやSyn Floodについて、L3やL4(ネットワーク層・トランスポート層)でAzure DDoSと同じくAWS Shield Standardが守ってくれる。年3000ドルのAdvancedにするとDDOSのスケールアップ料金の払い戻しなどもある!これ、結構大事です。ネットワーク回線が弱いレンタル共有サーバーなどは、かなり不安定な場合も有り、知らぬ間に機会損失してしまっているケースは実在する。

EC2の仮想マシンApacheを起こす

Apacheをスタートするとブラウザで通信出来る様になります。

パーミッション変更関連については、EC-CUBE本家コミュニティでも色々と調べられます。htmlフォルダ と appフォルダ のパーミッションを何も考えずに777へ変更しましたが、本番環境でも、開発環境でも、せめて755だと思います。

Microsoft AzureのPaas、Azure App ServiceのEC-CUBEについて

Azure PaasのAzure App ServiceにはEC-CUBE3ではなく、EC-CUBE2しかありません。EC-CUBE3をAzure Paasで使う場合、自分でEC-CUBE3インストールになります。App ServiceをAzureのMarketプレイスで選ぶ際にEC-CUBEで検索すると2つ出てくるのですが、両方ともに2系です。

Azure Paas EC-CUBE2の場合、LAMPではなくWindows Serverです。IISです。Linuxマシンではないです。verコマンドで「Microsoft Windows [Version 6.2.9200]」だったのでWindows Server 2012あたりです。Azureポータルにコマンドコンソールが一体化していますが、Paasなので、サンドボックスで管理者権限は無いです。vimも使えません。見るだけ程度です。

そして、MySQLを使う場合、Clear DBかAzure Database for MySQLになります。

Clear DB

Azure外部のサービスです。Mercuryという20MBの無料プランがあります。有料プランを使う場合、Azureから離れてClearDBにクレジットカード登録が必要です。冗長、デプロイ、開発柔軟性などを考えると、SQL databaseを使ってAzure内で終始一貫したほうがいいですね。Clear DBなので、phpmyadminとかいじりたいとき、AzureからClearDBに飛んでログインして・・・、とかメンドクサイです。日本でこの方式を選択する人、存在するのかな?クラウドのメリットがかなりなくなる・・・。

Azure Database for MySQL

2017/6/15現在は、プレビュー版です。

おそらく、Basic ストレージ50GB/コンピューティング ユニット50 で2000円/月程度です。SQL databaseの最小値500円/月に比べると高い。

Azure App ServiceのFTP/SFTP接続に落とし穴がある

「デプロイ資格情報」でユーザー名とパスワードを入力後、「概要」でFTPホストをコピーしてもこれだけではFTPログインできない。最初は、仮想ネットワーク(サブネット)の設定を無視してプロヴィジョニングするとダメ?とか思ったけど、それは原因じゃない。「概要」⇒「発効プロファイルの取得」でアカウントをxml書式のファイルをダウンロードすると、その中に接続アカウントが書いてある。AzureのFTPは旧ポータルの時から非常にわかりにくかったので、かなり嫌な予感がしていました。Azureの公式ドキュメントサイトには「発効プロファイルの取得」の手順が別ページになっていてわかりにくい。ずっと見落としていました・・・。

デプロイメントスロットを使った本番環境と開発環境のスワップは超お手軽で便利。「高度なツール」でKudu、Visual Studioのお手軽利用、リソースエクスプローラーでサブスクリプション丸ごとディレクトリツリービュー、App Service Editor(オンラインソースコードエディタ、git可、コマンドコンソールもあり、Visual Studio Code的な感じ)。ここまでくると、SQL databaseとAzure App Serviceで何でもやってしまうべき。インフラの手間が一掃され、手元のホストのスペックにもあまり左右されず、アプリ開発に集中できる環境はかなり魅力的。

コメントを残す