AWS上で独自ドメイン+SSLを実現 - S3/ACM/CloudFront/Route 53( + お名前.com)

概要

AWSで独自のサイトを作る際に、申し込みフォームや会員サイトを作りたい場合、SSLが必要です。その手続をCloudFrontを用いて安めにやってしまいましょう。特にHTML等をS3に配備してそれをSSL化するなら、絶対必要です。本家に記載されているとおり、請求額は実際のCloudFrontの利用料金となります。非常にリーズナブルですね。ここではその設定方法を調査し、実際にやってみたのでまとめました。

前提

独自ドメイン名とそのサブドメイン名が共に決まっている前提ですすめます。

独自ドメイン取得

お名前.comやムームードメインで、これから制作するサイト用の独自ドメインを取得します。AWSで使うために必要です。

登録が完了したら、メールアドレス設定します。ここではお名前.comの例で説明します。

ドメインNaviにログイン(お名前IDはメールに記載)して、オプション設定から、左サイドメニューのレンタルサーバー→メール専用サーバーのお申込みからメールサーバ申し込みします。
その後サーバーNaviにログインし、画面左のサイドバーからご利用サービス確認を開きます。

すると共用サーバーの欄にコントロールパネルのリンクがあるのでログインします。

※コントロールパネルをブックマークして直接そこからログインしようとしても弾かれます。サーバーNaviにログインしてそこから移動しましょう。
コントロールパネルに移動したらメール設定→メールアカウントから

qiita.com

に記載されている5つのメールアドレスを登録します(黒塗りの部分が、申請した独自ドメイン)。

これでメールが届くようになりました。しかしいちいちここにログインしていたら面倒なので、gmailに転送するように設定しました。転送するにはメール設定→メール転送をクリック。↑で登録した5つのメールアドレスは転送状態が無効になっているので、アクションの変更ボタンをクリックして普段使っているメールアドレスを入力します。

転送出来ることを、実際に上記いずれかのメールアドレスにテストメールを送って自分に届くことでチェックすること。

ここまで問題なければACM申請に進みます。

SSL準備(ACM)

ACMの申請については事前に

qiita.com

ここを読み込んだ方がいいですね。証明書自体の料金は要らないらしい。

注意点として、この作業をrootアカウントでやってはいけません！CloudFrontで後で証明書を設定する時、選択できなくなります。予め、作る前に自分の権限がIAMで用意した権限になっていることを確認すること！

stackoverflow.com

確認できたら↓↓

申請はAWS Certificate Manager（簡単に SSL/TLS 証明書を作成、管理、配置） | AWSから。SSLをつける独自ドメインは事前取得が必要。

まだ発行済証明書がないので入力フォームが出るはずです。ドメイン名*に取得済みドメイン名を入力します。もし既存の証明書を利用するなら、証明書のインポートボタンをクリックします。ここでは新規で作ったドメインを利用する方向で進めます。

新たに取得したadmin@○○等のメールアドレスが有効になっていることが確認できているのなら、次へボタンを押して確定しちゃいましょう。

ここまでうまくいっていれば下画像の様なメールが来るはずです。

※ここでは5つのメルアドに届くメールすべて1つのgmailにまとめて転送させています。

メール(どれか1つで良い)に記載されているURLにアクセスして遷移先でI Approveをクリックすると下記画面が出て手続き完了です。

念のためCertificate Managerにアクセスしてみると、下記の通り証明書が発行されていることがわかります。

この証明書、画面からはダウンロードできないようです。

S3へバケット用意

今お名前.comで用意した独自ドメイン名をバケット名にして登録します。まだ実データは配備しなくて大丈夫です。ここの名前が間違っているとココから先の設定がうまくいきません。

CloudFrontへS3ドメインを設定

CloudFrontを開き、Webの方のGet Startedボタンをクリック。

Create Distributionの項目を下記の通り埋めていきます。

Origin Settings

Origin Domain Name：事前に作成したS3のバケット名(自動で出てくる)を選択します。

Origin ID：↑を入れれば自動で入力されます。

Restrict Bucket Access：Yes

今回はCloudFront以外からのS3へのアクセスを禁じるので、下記を参考にして設定しました。

qiita.com

dev.classmethod.jp

Origin Access Identity：Create a New Identity

Comment：何でもいいですが、ここではデフォルト入力例に従って「access-identity-バケット名」とでもしましょう。

Grant Read Permissions on Bucket：Yes, Update Bucket Policy

Alternate Domain Names：ここに独自ドメインを入れる。事前にACM申請の時設定したドメイン名がドロップダウンに表示されています。

Alternate Domain Names：サブドメインを含めた独自ドメイン

それ以外はデフォルトでOK

独自ドメインのための続きはRoute 53で設定します。

Default Cache Behavior Settings

ここは特段いじりません。

Distribution Settings

ここも特段いじりません。

オプションの項目にHTTP/2とかIPv6とか専門知識が出てきますが一応知識としてあったほうがいいので簡単に勉強を。

ＩＳＰのＩＰｖ６対応について

codezine.jp

入力が終わったらCreate Distributionボタンをクリック。

Behaviorsの設定もします。使うファイルはHTML/JS/CSS/画像(形式によって異なる)なので、それぞれ追加しましょう。HTTP to HTTPSのredirectを選択。

Route 53

tech.tanaka733.net

を参照して進めます。サービスからRoute53をクリックして、トップ画面からDNS managementをクリックし、Created Host Zoneをクリック。画面右側のフォームに下記の通り入力して、Createをクリック。

Domain Name：お名前.comで取得した独自ドメイン

comment：なんでもいいです。

Type：Public Hosted Zone

登録後の例↓

Route 53への登録が終わったら、今度はお名前.comのコントロールパネルまで移動して、NSレコード4つをDNS登録します。続きは↑の記事の通りで大丈夫です。

設定の反映に結構時間がかかるので、こういう設定は最初に一通り完了させておいたほうが気が楽です。

S3に配備したファイルのSSL化は以上となります。

念のため下記の通りになるかチェックを。

• S3に何かファイルを配備して、プロパティに出るURLをクリックしてみましょう。中身が表示出来たはずです。
• CloudFrontで設定した独自ドメイン/ファイル名のURLにアクセスしてみましょう。中身が表示出来たはずです。

API Gatewayを独自ドメイン化

S3の設定とは別にAPI Gatewayでも独自ドメイン利用の設定をする必要があります。どうせなら合わせましょう。

 ココは後で書きます（たぶん

番外編：S3の独自ドメイン設定(CloudFront利用なしの場合)

S3でのファイル公開～独自ドメインアクセスは

qiita.com

にまとまっていて分かりやすいのでココにそってやると良いでしょう。

こちらはACM, CloudFrontが不要で、S3とRoute53のみの設定で出来ます。

番外編：間違ってACMをroot権限で作ってしまったら

下画像の様にCustom SSL Certificateが選択できなくなります。

こうなると面倒。やることはACMで証明書を発行し直しになります。作成直後すぐ気づけたなら作り直せばいいのですが、Route 53の設定を終わった後だとやっかいです。

1. まずお名前.comのドメインNaviのネームサーバ変更で、最初にadmin@ドメイン名などのメールアドレスを登録したコントロールパネルのドメイン(dnsXX.gmoserver.jpの様な名前)に戻す必要があります。最大で24~72hかかります。
2. 次に再度メールがadmin@ドメイン名などのメールアドレスにメールを送って、メールが届くことを確認してください。問題なければ、ACMの申請をやり直します。
3. ACMで証明書を無事発行できたら、再度ドメインNaviでRoute 53で設定したNSレコードを使ってネームサーバ変更してください。
4. CloudFrontのEditからCustom SSL Certificateが選択可になっていることが確認できればOKです。

番外編：Route 53/CloudFront/ACMの設定をしたはずなのにエラーが出る

qiita.com

の原因を辿ってみてください。感覚的にこの中だとCloudFrontの設定ミスが一番起こりやすいです。

総括

今回はインフラ寄りの知識が多かったです(寧ろそれしかなかった)。そもそもAWS全体的にそんな感じっていうか。。ただ言われたとおりのプログラムを書くだけのザ・プログラマにはちと辛いサービスであることは間違いありません。

もっともこれはインフラに造詣が深い人間が書いた記事ではないので、無駄がありそうです。もっとうまい方法を見つけたら修正します。

他の記事を沢山参照しまくらないと作れないよ本当。トホホ┐(´д｀)┌

AWSでのサービス制作(テストアプリ)

概要

前回の記事

notwodaily.hatenablog.com

から、AWS Lambda + Amazon API Gatewayを用いたwebサービス制作について実際の制作の部分を抜き出しました。なるべく画像を使って説明します。今までに出た記事と比較すると、多少AWS側にUIの変更があるようです。そしてLambdaを見れば一目瞭然ですが、英語文章も出てきます。しかし文字の意味を捉えて行けば読み替えることは容易なので、焦らずにいきましょう(；´∀｀)

登録の先から順を追って説明していきます。

※この記事は画像のせいで縦に糞長いです（泣）

テストアプリ

AWS Lambda

ステップ 2.1: Hello World Lambda 関数を作成する - AWS Lambda

に沿って作ります。しかしここでの説明はところどころ端折られているように思えて不満なので、細かい解説も入れてメモします。

まずここから、テスト用のfunctionを作成します。

Get Started Nowをクリック

次の画面が出たら、言語はPython2.7を選択します。

brueprintはhello-world-pythonを選択。filterにhelloと入れて絞り込みます。

そうしたら、configure triggersで空欄はAmazon API Gatewayを選択。

その他の入力欄はデフォルトのままです。

次はfunctionを作成します。

Name: myTestFunction

Runtime: python 2.3(pythonのバージョンはこれしか選べませんでした)

Role Name: myTestRole

※テストアプリなので名前は適当です。

ほかはデフォルトの入力のままです。

Nextボタンで作成すると、次の画面に遷移します。所謂設定確認画面です。

設定内容が正しいか確認して、問題なければCreate functionボタンで次画面へ。

この後API Gatewayの編集ページへ遷移しました。そこでリソースを定義します。

/myTestFunctionにカーソルが合った状態で、画面右上のアクションボタン→メソッドの作成→GET→✔マークをクリック

オプション設定フォームが現れるので、下記のとおりに入力

統合タイプ: Lambda関数

Lambdaのリージョンは

docs.aws.amazon.com

で確認できます。どうやら東京リージョンが出来ているようですので、これを使いましょう。

ap-northeast-1を選択して保存。 

これでfunctionを1つ作成できました。作成後でもさっき決めた設定を変更できるので、安心ですね！

Codeでデプロイするコードを編集できます。今回はpythonを選んでいるので、pythonコードがデフォルトで記載されています。ここではテストアプリなのでデフォルトのコードを使います。

ではせっかく作ったのでテストまでやりましょうか。

真ん中のTestボタンをクリック

といった具合にLambda functionを定義、テストまで完了しました。通常であれば必要な関数をこのように定義して必要に応じて呼ぶことが可能になります。そしてこれがLambdaに関数を定義する流れとなります。ここではデプロイまではしません。

Amazon API Gateway

上記で合わせてやってしまったので、割愛。とくにここではやることはありません。

S3, DynamoDBはテストアプリでは不要なため、特に触れません。本命のアプリ(別記事)で実際に利用します。そして今回は認証しないのでCognito未使用です。

テストアプリ(micro service: 最低レベルの小さなサービス)

ここからは、pythonのコードをデプロイし、リクエストを受け付けてレスポンスを返す普通のwebサーバとしての機能をLambdaに持たせます。やっとwebサーバっぽくなってきます。

まずLambdaコンソールを開きます。

このページ。

Create Lambda functionボタンを押し、microservice-http-endpointをfilter欄に入れます。出てきたカセットのうち、pythonのついてる方を選択します。

今度もデフォルトのままNextを押します。

今度のfunction名は「myPythonFunction」にします。

DescriptionにA simple backend (read/write to DynamoDB) with a RESTful API endpoint using Amazon API Gateway.とあるとおり、DynamoDBを利用したテストアプリが出来上がります。

Role nameはそれとわかる適当な名前で大丈夫です。権限については、下のフォームにあるpolicy templateで選んだテンプレートについている権限に加えて、フォーム上の説明(英語)にある通り、必要な権限が自動で入力されます。だから今のところは権限について気張る必要はありません。

たとえば、ここではmyPythonAppliRoleとします。

それ以外の項目はデフォルト値でOK。そのままNextボタンをクリック。

下の画像のようになるはずです。

入力に問題なければCreate functionボタンをクリックして、関数を作成します。

こんな感じでしょう。

Actions→Configure test eventをクリック。コードを下記の様な感じに編集。

まだDynamoDBを設定していないので、下記画像の様に

ResourceNotFoundException

のエラーが出ます。

じゃあDynamoDBの登録しましょう。と言っても何を入れたらいいかわからないので、ここではチュートリアルに沿って進めます。画面右上の「チュートリアル」ボタンを押して、解説に沿って入力して行きましょう。

作成後は下記画像のようになります。

 今度はLambdaのページに戻りましょう。LambdaのチュートリアルではAPIを叩けと言ってますが、先にそもそもTestが通るかをチェック。DashboardでTestボタンをクリック。

status codeが200, bodyにjsonが返ってきているのがわかりますね。これでひとまず成功です。

しかしまだ肝心のAPI Gatewayが準備されていないのでこのまま外部からAPIを叩いても"Missing Authentication Token"とか返されてしまいます。今、TriggerタブのMethodがANYになっているので、ここにPOSTとGETを定義して、リクエストを受け付けられるようにします。ANYリンクをクリックして、前回の記事と同様に操作してそれぞれ用意します。

新しい APIからAPI名をpythontest, 説明は何でも構いませんので入れてAPIの作成ボタンをクリック

今、リソースが/(ルート)のままなので先にリソースを追加します。アクション→リソースの作成をクリック→新しい子リソースのリソース名をmusic, リソースパスをgetMusicにしてリソースの作成ボタンをクリック。

次に/getmusicをクリックしてGETメソッドを作成します。 

• 統合タイプ：Lambda関数
• Lambdaリージョン：ap-northeast-1
• Lambda関数：さっき作ったLambda関数名

このままだとエラーが出るので修正します。リクエストパラメータをいじってもいいんですが面倒なのでcodeをいじります。

operation = event['httpMethod']

以下をすべてコメントアウトして

respond(None, None)

に置き換えてSave and Testボタンをクリックしてエラーが出ない(responseはnull)になることをチェック。

更にAPI Gateway側でもテストを押してみて、エラーが出ない(responseはnull)になることをチェック。

ここまで問題なかったら更に少しコードを書き換えて、DynamoDBに実際にデータを入れてみます。

codeを開き、

respond(None, None)

を

dynamodb = boto3.resource('dynamodb', region_name='ap-northeast-1')
    table = dynamodb.Table('Music')

    Artist = "Artist Sample"
    songTitle = "songTitle Sample"

    response = table.put_item(
        Item={
            'Artist': Artist,
            'SongTitle': songTitle
        }
    )

に変えてAPI Gatewayからテストします。エラーなく完了するはず(responseはnull)。今度は読み込みも一応テストしておきます。

再度codeを開き、上記コードのdynamodb = 以下を下記の通りに修正します。

dynamodb = boto3.resource('dynamodb', region_name='ap-northeast-1')
    table = dynamodb.Table('Music')

    Artist = "Artist Sample"
    songTitle = "songTitle Sample"

    try:
        response = table.get_item(
            Key={
                'Artist': Artist,
                'SongTitle': songTitle
            }
        )

    except ClientError as e:
        print(e.response['Error']['Message'])
    else:
        print("getItem succeeded:")
        print(json.dumps(response, indent=4))
    

また、頭のfromの塊を

from __future__ import print_function
import boto3
import json
from boto3.dynamodb.conditions import Key, Attr
from botocore.exceptions import ClientError

と書き換えてSave and Testボタンをクリックしてください。

これでテストが成功して下画像の通りに出力されていればOK

関数自体の戻り値はnullですがlog出力結果に確かにさっき入れたばっかりのデータが見て取れます。これでDB出力も問題ないですね。

pythonからDynamoDBを叩く方法は

docs.aws.amazon.com

を参考にしました。

そしてデプロイ。つまりはAPIを公開します。

デプロイする時はステージを選ぶのですがここでは何でも良いのでstagingとでもしましょう。

デプロイしたいAPI名を選択してリソースをクリック→アクションからAPIのデプロイを選択。ダイアログが開くので、例えば下記のように入力して、デプロイ。

するとステージが選択されて今デプロイしたAPIの履歴やURLが見れるはずです。

ただし今回はルートリソース(/)の下にgetmusicをつけていますので、URLの後ろに/getmusicとつければアクセスできます。戻り値nullだけど。。

デプロイ後にAPIに修正が入ったなら再度デプロイすればいいです。

こんな感じでテストアプリとしては完了です。開発の大雑把な流れとしてはつかめてきたんじゃないかと思います。実際にwebアプリ開発する際にはcodeを書き換えたりIAM Roleを使いこなしていきますし、他にもS3やSESなどを組み合わせて本格的なアプリに仕上げていきます。

なんか無駄な操作をしているかもしれないので、この辺が詳しい人からしたらこうしたらいいのにっていうのがあるかもしれません。

【Python】【予約フォーム】AWS上でなるべく安くwebサービスを作ってみる

概要

AWS(Amazon Web Service)を始めようと思ったけど料金体系とサービスが複雑で分かりづらい！と思ったので、安く始めるために調べました。実際に筆者もまた新たにサービスを作るので、筆者の場合のプランについて説明します。

AWSについては

qiita.com

qiita.com

このあたりに分かりやすくまとまっています。

正直、公式HPを見ても情報が多すぎる上にあまりまとまりがないように見えて、そこだけですべて理解するのは難しいです。。せっかく分かりやすく解説してくれているサイトがあるのだから、実際に利用する前によく読み込んだほうが良いでしょう。

無料期間について

何と言ってもAWSの利用意欲を注ぐのがこれ。他は当然初月からしっかり請求されるので、月額の計算で萎えちゃったりします。

プラン的にも有料後も無理なく使えるものが揃っているので、無料期間終了後も長く使っていくのにも適していそう。

AWSのHPに載っていた無料期間については下記(16/11/13時点)。

無料期間は1年間も続くのでこの時点で破格なのですが、それでもやはり調子に乗って使っていると、有料期間ともなると馬鹿にならない請求が毎月来ます。シミュレーションで見れば一目瞭然...

制作物(予定)

とある予約フォームを制作します。

簡単な入力、確認、完了画面とメール送信機能だけしか作りません。

実際に利用する機能

たくさんの機能が有る中で、今回実際に利用するのは下記。

AWS Lambda

今回の記事の中で非常に重要。EC2ではなくこちらを使うのには大きな理由があります。

• 金銭的にリーズナブル
• 小規模な申込みフォームを作る程度なので、データ転送やストレージに大した規模を求めない(数百万数千万単位のアクセスが来ることがわかっていればこの限りではない)
• プライベートネットワークは不要

↑とは逆にすでに大規模サイトを運用している、という場合はそもそも収入が相当あるでしょうから、まともにEC2のインスタンスを立てて24時間稼働をしても問題なく運営出来るかもしれませんし、そもそもそれだけ金が使えるならAWSでなく自前で用意したっていいですよね。筆者はそうではありませんので...

Lambdaについては

AWSでAPI Gatewayから非同期でLambdaを起動してS3にファイルアップロードしようとしたらハマった話。 from Takehiro Suemitsu

www.slideshare.net

この説明も役立ちました。今回は非同期ではないしNode.jsは使いませんけどね。

Amazon S3

要するにストレージ。料金体系は公式サイトよりも

qiita.com

を見たほうが分かりやすいです。こういう時本当にQiitaは頼りになります。

Amazon API Gateway

これとLambdaの組み合わせによってサーバレスなアプリケーション制作が可能になっちゃいます！

今回、下記で詳しく書きますがpythonを使うので

qiita.com

dev.classmethod.jp

この辺を参考にすると良いでしょう。

DynamoDB

フォームの入力データを保存するために必要。

qiita.com

ここが分かりやすかったです。

NoSQLだかなんだかにビビる必要はありません。要するにデータの保持の仕方がMySQLとかとはちょっと違うだけ。

Amazon CloudFront

所謂Amazon版CDN。とは言え今回は主に独自ドメイン+SSL設定のときにお世話になります。

Amazon SES

ここが分かりやすくまとまってました。

qiita.com

これと別でSNSを利用してもいいのですがそちらはモバイル端末へのPush通知用だということに対して作ろうとしているシステムはPCでも受け付けていること、内容的にどちらかと言うとメールに記録として残したほうが良いと思ったのでSESにしました。

言語は？

Pythonを利用します。これは言語のシェア率が低くなく、Lambdaで使える言語の中では学習する価値が一番高いと感じたので。

Pythonを使ったことがない筆者が1からやるのはちょっと骨が折れるかと思いきやそうでもありません。確かに色んなライブラリに手を出すとしたらきついのですが、今回はやりたいことが明確なので使用するライブラリも限定します。

サーバレスなのでBottleやDjangoは使わず、Lambda functionとしての部分に記述するだけです。

そして忘れずに、契約後にはこれを絶対しましょう!

qiita.com

1年間ずっと残り期間を見るわけにもいかないでしょうから、期限切れのときに気づかずに使い続けて利用費が跳ね上がるという悲劇を防ぐために重要です。

開発の流れ

ここは少し規模が肥大化しそうなので別記事としてアップします。本記事には概要だけ載せます。

前提の知識をつけたところで、やっと製作開始。前置きが非常に長くなりましたが、早速やってみましょう。

ちなみにまだ何もない真っさらな状態から始めるので、バックアップは取りません。

登録

まだAWSのアカウントがない前提ですのでアカウントを作成します。Amazonのアカウントとは別扱いです。

登録完了後はこんな感じのページが出ます。

登録が終わったばかりであればまだ請求額が$０のはず。念のため確認しましょう。

IAM Role/User, Groupの作成

qiita.com

IAMってなんのこっちゃ、という人はサーバでいつも使うユーザとかroot権限を思い浮かべれば分かりやすいです。

最初、AWSアカウントを解説したばかりで何もRole設定しないうちはroot権限と同等になっています。

16/11/16時点では日本語ではサービス→セキュリティ・アイデンティティをクリック→アカウント設定から入ってください。

グループを作成、次にユーザー作成です。

日本語では左メニュー「ユーザー」をクリック。

どういう条件か知りませんが、時々Create UserするときにThe request is invalidと出るときがありますが、その場合は何度かF5してやり直してみるとうまくいきます。

無事作成できると上記画面になります。 

パスワードの管理へは下記のように辿ります。

次はログイン。そこまで無事にできたら、ひとまずサインアウトして今度は「ルートアカウント認証情報を使用してサインイン」からデフォルトのアカウント情報でサインインし直しましょう。

adminはRoleとして強すぎるのでpythonサービス制作用に最低限のアクセス権限を持ったRoleを別途用意します。

サービスの選択

AWSのサービス群から必要な物を選びます。今選べるのはこんな感じ。

制作

CloudFrontでのSSL証明書登録、S3へのコンテンツ配備、APIの作成からメール設定などやることは盛りだくさん。ココに書ききるには狭すぎるので、別記事でアップします。

テスト

本当はここも書きたいのですがAWSでのデプロイやテストの自動化について1からやる流れについては後ほどまとめて記事を出したいと思います。

リリース

所謂デプロイ。とは言ってもS3やDynamoDBへのデータ登録やSSL設定は先にやってしまうので、API Gatewayのデプロイのことを指します。

どちらかと言うと制作に含まれてしまうので、ここで単体で書くことはありません。

(少し長めですが)総括

webサービスは便利なツールですがそもそも自分がやりたいことが明確でないのにwebサービス作ろう、とはならないはずなので、後はそんな人に必要なのは頭を使うことだけだと思います。今や様々なサービスとかツールが出回っているから、どれを使ったら自分に合うのかを設計前の段階に洗い出す。そしてそれらツールのうち料金プランとスペック的に無理のないものを選んで、必要なら乗り換えたりプランを変更したり、後から柔軟にやりくりするだけ。言ってみれば単純ですがそのためにはたくさん情報を得る必要があって1から自分だけで勉強するのは大変なので、今度はそのために情報を分かりやすくまとめてくれているQiitaやDevelopers IO、企業の開発者ブログ、はてなブログの一部の記事あたりを探っていく感じですね(ググった結果たいてい良記事はこのあたりに落ちていることが多いです)。

逆に一番ナンセンスなのは、トレンドというか新しいから大丈夫だろう使っちゃえというパターン。最新の技術だとサポートが行き届いていなかったり、ドキュメントが不十分だったりもします。そして本当にそれが自分たちに合うのか考えもせず取り入れるのは甚だ疑問です。せっかく参考書やネットで調べ放題なんだからそういった財産をフル活用して本当に役立つものを限定的に使っていく。

かつ知識がないとそもそも選定しようがないので、最新情報には触れていく。役立つなら取り入れる。この繰り返しです。筆者もそうしていくし、きっと世の中の”出来る”エンジニアと言われている人はこんなスタンスで仕事しているに違いない。限られた時間内で目的を達成するためには必然的にそうなるから。

本記事はAWS学び始めの初心者が理解したこと、実際に使ってわかったことを自分用メモ&なるべくこれから触る人向けに分かりやすくまとめたつもりですが、間違いもあるかもしれません。作っていっておかしいな？と思ったら後から随時修正を入れていきます。

【ドメイン移管】初心者向けサイト移行例

どうも。

最近、とあるサイト移行とドメイン移管についてお手伝いしたので、せっかくなので実際にやる流れについてまとめました。

より簡単に一通りを済ませるために行ったので改善点はたくさんありそうです。

※これはあくまで移行例に過ぎませんし、そこまで小難しいサイトでもありません。ものによってはこれより遥かに面倒な手順が必要だったりするかもしれません。

---

やったこと

• サイトデザイン変更(実際にはWordPressで一新までしました)
• ドメイン移管

サイトの種類

会社のHP + お問い合わせフォーム

移行前

• HPビルダー(月額千数百円)で運営
• ビルダーインストールPCでのみ作成可能

移行後

• WordPress上で運営(サーバはロリポップのものです)
• ネットが使える全てのPCで作成可能

今回のキモ

DBを使わずJSなどのロジックもろくにないので、サイト構築自体は大して難しくありませんでした。修正したとしたらデザインも見た目を大幅に変えるわけでなくビルダーでどうしても解決できない表示崩れを直したり少し見やすくする程度です。

ただしドメインを変えずにサイトの見た目と稼働サーバを変えるので、前のサービスを終了するタイミング、切り替えるタイミングを間違えると大変です。順を追って説明していくと、

1. 新契約(ここでいうロリポップ)を完了させる
2. WordPressインストール、編集
3. ムームードメイン(お名前.comでもOK)でドメイン移管(この時点ではドメインはビルダー側のサーバを向いてる)
4. ネームサーバ変更(ここからドメインはロリポップを向いてる)
5. 前の契約(ここでいうビルダー)を解約←これはもうすぐ完了

※ネームサーバが完全にロリポップに変わるまで最大1日以上かかりました。。。

上記でいう3まではビルダーで作られたサイトが表示されています。4で徐々に新サイトに切り替わっていきます。5はすべて切り替わったあとで実施しましょう。詳しいやり方はビルダーなら購入したパッケージの説明書、レンサバなら運営HPを見れば必ず書いてありますので、そこを参照すればOK。

仕組みは下記の説明でわかるはず。

itpro.nikkeibp.co.jp

webのリテラシがない人がいきなり勉強するのは酷かもしれませんので、ある程度単語くらいは理解できるようになってから実施したほうがいいかもしれません。

！！ロリポップ仕様上の注意点！！

今回一度実は大きなミスをしていて、全く同じフォルダにEC-CUBEを入れてしまったことでURLがEC-CUBEのものに上書きされてしまう事件が発生しました。

そんなときは上書きされたファイルがどれかを特定しているうちにそもそもアクセスすら出来なくなっていることに気づき、結局全全消しして同じディレクトリ構成で入れ直しました。ファイルはバックアップをとっておいたので割と早く復活出来ましたが、入れる前の説明文はちゃんと読んでおきましょう。特にディレクトリ周りはミスすると危険です。

まとめ

サーバ選定、プラットフォーム選定は大事です。今回はロリポップを選んだわけですが、正直なんでも良かったので、試しにって感じですね。クラウドってテもあったし、さくらのレンサバでも良かった。しかしいろんな要件を満たす必要があるなら、それで一番安く済むのはどれか、必要な機能を満たしてくれるものがどれかを選びます。

そして、手順は書きはしましたが、ドメインを新たに取得する場合や自前でサーバ構築する場合など場合によって手順は変わってきますので、適宜本を買うなりQiitaを見るなりして調べる方が良いと思います。

今後の予定

• ネットショップ開通
• 予約フォーム作成
• Google Analytics導入

ということで順を追ってでき次第これらも記事にしていこうと思います。これで素人がサイトづくりをする一連の流れが見えてきますね。

wordpressでそれっぽい企業用サイトを作るために

WordPressを用いて1からサイト作りをしたので、企業用HPのサイト作りをするための流れを書きます。

初期状態

WordPressをインストールしたばかりの画面はこんな感じ。

※画面の背景がちょっと変わってますが気にしないでください。

ここから余計な項目を削って必要な項目を出し、更に修正を効率的にするためのアレンジも施します。

※テーマは標準のTwenty Sixteenを用いるものとします。

見た目の修正

コメント欄を消す

WordPress - コメント欄停止・コメント削除

の通りにやれば出来ます。

サイドバーを検索欄以外全て消す

www.nxworld.net

の通りにやるか、もしくは

この画面でサイドバーにある検索以外(検索が邪魔なら検索も)をクリック→削除とします。ここで自分でサイドバーをカスタムしたいなら、テキストを入れてそこにulタグを入れて作りましょう。

タイトルを消す

プラグインで消してもいいですが、CSSで消したほうがスマートです。

.entry-header h1.entry-title {
  display: none;
}

フッターを修正する

フッター部に「Proudly powered by WordPress」と出ているのが気になると思います。当然邪魔になるので、消しましょう。

wordpress999.info

ココの通りにやれば大丈夫です。そのままCopyrightを記載しても良いでしょう。

ナビゲーションバーの配置

固定ページの一覧をナビゲーションバーとして配置します。先に固定ページを作成します。まずはデフォルトの余計なページの削除から。

ダッシュボード→固定ページ→固定ページ一覧

を開き、

ここのサンプルページを削除します。ゴミ箱へ移動でOKです。

そのうえで、必要なページを追加します。

wordpressを入れ直してバックアップから戻す場合は、wp_postsにinsertすればOKです。事前にSQLは準備しておいたほうがいいですね。

すべてのページが用意できたなら、次は外観→メニューをクリック。

このような表示になっているはずです。

設定方法は

WordPressのナビゲーションメニューを設定する方法

を参考にどうぞ。 

お問い合わせフォーム

企業ならお問い合わせフォームは必須ってことで、手っ取り早く用意したいなら。

www.adminweb.jp

親切なことにデザインはデフォルトで当たっています。個人事業主の方であれば特段フォームもメール本文も修正要らずですぐに使えるのは嬉しいところ。

逆に金融関係などセキュリティにチョ～厳しいフォームであればプラグインでなく自分でしっかり作り込んだ方がいいです。その場合はそもそもWordPressよりサイト自体を自前にしたほうが合っているんですけどね...安く作ると、どうしてもセキュリティは甘くなりがちです。

デザインの追加(style.css)

ダッシュボードから外観→テーマの編集

独自のCSSを使う場合はフォローしません。やり方はググれば見つかるはずです。

WordPressでは見て分かる通り、normalize.cssをデフォルトで適用しているようです。その他WordPressのデフォルトのデザインがいくつか当たっているので、もしセレクタ書いても効いていないのであれば、デフォルトの記述を疑ってください。

画像フォルダ整理

wp.8jimeyo.info

ここで紹介されているプラグイン「Media File Manager」を入れましょう。

ちょっとしたレスポンシブデザインに。

このままだとブラウザのサイズが変わったりスマホから見たときに画面崩れが起こってしまいます。それを対策します。

まずプラグインでAdd Code To Headを入れて有効化します。

すると

このように設定欄にAdd Code To Head項目が追加されるのでクリックして、

<meta name="viewport" content="width=1000"> ※必要ならminimum-scaleも。

と入力して(上記widthはサイトのサイズに合わせて適宜変えること)、変更を保存。

スマホからアクセスした時に崩れてなければOK。PCで見たときと同様の画面になっているはずです。

それでも崩れる場合は

webcre8.jp

の他の項目も試してみると良さそうです。

設定の修正

自動brタグ挿入禁止

webkikaku.co.jp

のやり方が良いです。ただし、これをやるとビジュアルで修正するときにも改行を入れたはずなのに改行されない問題が発生しました。普段HTMLを書かない人にはあまり向かないかもしれません。

aタグのhref属性に記載するURLを相対パス化

www.will-hp.com

のやり方が良いです。毎回絶対パス書くのは手間と見づらさの点でスマートではありません。

imgタグのsrc属性に記載するURLを相対パス化

www.warna.info

のやり方が良いです。相対パスのほうが良いのは上項目と同様。

検索対策

Just another WordPress siteを消す

作ったばかりの自分のページをググると、↑の文言が検索結果についてます。これではWordPressで作ってますよーと公言してるみたいでちょっと格好悪いですね。なので消しましょう。

crowd-logic.com

が分かりやすいです。

付録1:設定をいじりすぎてわけがわからなくなった挙句、ダッシュボードにもアクセスできなくなった時

特にWordPress アドレス (URL)をミスって変えた時によく起こります。それだけならググれば対処法は出てきますが、誤って重要なファイルを消しちゃったりいじっちゃいけないファイルをいじくり回して結局復活できなくなるときも稀にあるでしょう。

そうなったら予めバックアップをとったうえで(ここ超重要)、おとなしく今使っているwordpressのディレクトリごとrm -rfしましょう。そして再インストールし、設定はダッシュボードから同様に行ったあと、下記の一部のファイルをまるまるコピペして動作確認しましょう。

wordpressをインストールしたディレクトリ/wp-content/themes/twentysixteen/functions.php

wordpressをインストールしたディレクトリ/wp-content/themes/twentysixteen/style.css

wordpressをインストールしたディレクトリ/wp-content/themes/twentysixteen/footer.css

ただし、固定ページだけはファイルでなくwp-postsというテーブルに保存されているため、その中身が生きていれば大丈夫です。間違っても、DBの中のデータは消さないように注意すること。

付録2:JSについて

企業HPにてJSを使うことは考えづらいですが、もし使うのであれば独自のJSを用意してそれをfunction.phpを編集して読み込めるようにするか、必要なページにだけscriptタグを書いてそこにべた書きするか、によります。後者がおすすめです。

付録3:SSLについて

お問い合わせフォームにSSL導入の話ですが、

問い合わせフォームのセキュリティ対策は不要か？実はSSL対応はほとんど意味が無い件 | affiliate.ks-product

にある通り、不要だと思います。入力内容によりますが普通は氏名とアドレスと問い合わせ内容のみ。

SSLやってるところはやってるけど、だから何？って感じ。

スパムメールはSSLありのところでしか入力してなくなって、来るときは来ます。というかSSLあり/なしで明確に差が現れた、と研究結果もしくは統計が出ているから完全にSSLなしはOUTだ！と言うソースでもない限り、SSLを必須だと言うに値しないでしょう。

携帯のアドレス、番号などを知らない誰かに教えているはずもないのにどこからか漏れていてスパムメールが大量に来る経験は多くの人が経験済みです。つまり、SSL化したから安全、ではないです。それならやる意味もないでしょう。もしDBで管理するよ、という場合は話が変わって来ますが...

これがカードの契約番号とかクリティカルな情報なら暗号化した上で保存、などSSLだけでなく更に強固にするべきですね。

長くなりましたが、WordPressの本を買わずにサイト1つを作れるくらいプラグインや情報がネットには充実しているので、まずは調べて、自分で色々試しましょう！

excelは保存用ドキュメントにしないほうがいい

概要

あくまで個人的な意見ですが、Excelが使いづらいと感じることが多いので、書きます。

一言で言うとExcelは糞です。

頻繁にロックされクラッシュし、大事な中身がおじゃんになることはざら。
重いし、いちいちカネを出して買う程のものでもないと感じます。今はもっと便利なツールが有りますし。
そもそも、大半のメモはテキストレベルで十分だし、企業に提出するレベルならPDFの方が良さそう。これはこれでAdobe Acrobatが必要ですけど...
スケジュールだってAtlassianのJIRAとかConfluenceを使えばいいです。今やexcelの出番ほとんどないはず。

テストケースやマトリクス形式のデータがほしい場合なら代替ツールを。

どうしてもexcel使うなら、共通ファイルを自分のローカルに持ってきて見れば共有とかしなくても良いので、見やすいです。Excelに固執する意味が全くないと思います。

代替ツールは？

殆どはテキストエディタで十分。

テストケースや表がほしいなら、OpenOfficeがあります。個人で何かドキュメント作成するなら、ローカルのhtmlにしたっていいし、googleのスプレッドシートを使うこともOKです。もしくはAWS等を用いてプライベートネットワークを構築してそこでドキュメントを共有し合うのも良いでしょう。

優れたツールもそのうち置き換わる

確かに一昔前はまともに資料作りをするとなったらOffice製品を使おうと思いましたが今はもっと便利なツールは間違いなくあるので、そっちに乗り換えればいいです。せっかく買ったんだからなどとお馬鹿なことを言わずに、効率を上げるツールを選ぶべきだと思います。

金銭的にも、PC1台ごとに必要なツールよりもネットに繋がっていればどこからでも触れるツールのほうが今時便利で結果的に安上がりにならないでしょうか。会社の規模にもよりますが。

そして筆者が前に味わった、共有フォルダが容量MAXでアクセスできない事態とも無関係です。その代わり、サービスが落ちれば何も見れなくなるリスクは有りますが。しかしデメリット以上にメリットが馬鹿でかいです。

まとめると

Excelについて書いたのですが、別にExcelに限ったことではなくて、使いづらいツールはもちろん、より使いやすく便利なツールが出たのならとっとと乗り換えたほうが仕事の効率が良くなります。

新しければ良いとは言えませんが、既存に使いづらい不満があるのであれば、一度試しに使ってみるくらいはしても良さそう。ネットでどんな感じかは調べることが出来るので、あまり評判が良くなければ乗り換えないでもよし。検討すらしないのは勿体無いです。

はてなブログを有料にするかどうかの判断について

概要

はてなブログを始める前に有料か無料かを選ぶことですが、筆者がはてなブログPro - はてなブログに載っている情報をもとに判断する時のポイントを書いてみました。

メリット

デメリットは、毎月数百円かかることだけ。なので、簡単にメリットとなる項目を書きます。

• 独自のブログを作れる(ブログの自由度が増す)
• 余計な表示を消せる
• 容量を気にしないで作れる

大きく分けてこのあたりでしょう。

判断材料

実際には上記リンクにあるような有料会員のみの特典というのは、全てが役立つするわけでもありません。特にこれは絶対有料じゃないとできない、というものを説明します。

独自ドメイン

これはさすがに有料じゃないとだめです。どうしてもURLのドメインにhttp://blog.hatena.ne.jp/をつけたくないなら、

キーワード自動リンクオフ

これも有料じゃないと消せませんね。しかし記事の文中、そこらじゅうの文字リンクがつくわけでもありませんし、初心者向けの記事を書くときは逆に自分でリンクを貼らなくても勝手にリンクが貼られることで逆に手間が省けるという考え方もできます。ということで、これはメリットとしては小さいですね。

記事URL引き継ぎ

これは、引き継ぎ元の記事数が多いときに有効です。1, 2記事程度であれば無料で始めてから文字をコピペするとかすれば対応できます。文字の装飾は面倒ですが...

逆に、以下は大してメリットと感じない程度の項目を書きます。

複数ブログ

これはあまり要らないかなと。。そもそも3つもブログを持ったところで更新が大変過ぎます。むしろ無料の3ついっぱいまでを書こうとしましたが、どう考えても多い..今2つを運営していますが、それでも手間です。よほど書くことが多すぎてしかもジャンルがあまりに別々になりすぎるなら、必要かもしれません。あとでそうなってから有料に切り替えたっていいです。

広告非表示

広告については、ブログを一切マネタイズしないんだ！という決意のある人には必要だと思います。しかし筆者のようにアドセンスを貼る、などどこかのアフィリエイトリンクを貼る、という人の場合には結局、広告で多少汚れることにはなります。そういう人は広告を表示しないことよりも、表示の仕方(位置、大きさ)を意識するほうが良いです。そこは課題です。

ブログメンバー

ブログを複数人で共有するのなら、その記事を書きたい人にアカウントを教えてあげればいいだけです。

ヘッダとフッタを非表示

デザインCSSで

#globalheader-container, #footer {
    display: none;
}

と入力すれば消せるので不要です。

消したあとの空白が気になる場合もCSSで調整すればいいです。

写真アップロード容量追加

これは全く気になりませんでした。毎日記事を書いてそこに複数の画像をアップしていくとしても、容量overすることはまずないでしょう。よほど容量の大きい画像を大量にアップし続けることでもない限り。

そしてそんなに画像だらけにするのであれば、外部のpinterestやinstagramを利用して外部リンクをつければ済む話。そっちにも文字は書けるし。文字が多すぎるなら、載せきれない画像だけ外部へ分けて文字だけはてぶの記事とするか、もしくはそもそも記事をシリーズ化して複数回に分ければいい話です。画像が多ければ質が高い、見やすいかというとそうでもないですし。工夫次第でどうとでもなります。

アクセス解析

Google Analyticsを入れましょう:)

まとめると

ということで、一通りの有料の項目について自分なりの考えをまとめました。どうしたらいいかは人によるとはいえ、この考え方は大抵の人に当てはまると考えています。もし有料にするのであれば先にアドセンスを貼ってある程度の収入が見込めるようになってから切り替えてもOK。

今までいくつかの質の高いなと思う記事を読んできましたが、これははてなブログっぽくないか？と思ってよくよくURLのドメインを見てみると、普通に無料会員のままだったりすることもあります。無料会員だから記事の質が下がることはありません。無料会員でもCSSの心得があれば自分で外観を整えることも出来ます。

なんにせよ調べて自分の頭で考えてどうするかを決めるのが一番大事ということですね。