IT・ビッグデータ徒然ブログ

ビッグデータ界隈で、セールス、コンサル、ちょっとした開発等いろんなことに振り回されている人のブログです。

ブログ移住計画その4~WordPressをセキュアに~

前回の続き。

前にAnsibleで作ったものを入れて、WordPressをセキュアに設定しておきます。

DBのプレフィックスを変更

WordPressをインストールして、設定するとwp_から始まるテーブル名が自動で生成されるが、これだと攻撃の標的になるので、wp-config.phpの以下の行を変更する

##$table_prefix  = 'wp_'
 
$table_prefix  = 'wp_test_'
## プレフィックスは自由に

wp-config.phpパーミッションを変更

wp-config.phpは重要なファイルなのでパーミッションを400に設定しておく。 上のプレフィックスの変更もあるので、wp-config.phpのファイルを切り出してもっておき、配布するように設定

./roles/wordpress/tasks/main.ymlの一部

### wordpress/templatesディレクトリにwp-config.php.j2ファイルを仕込んでおく

- name: set wp-config.php
  template:
    src: wp-config.php.j2
    dest: /var/www/html/wordpress/wp-config.php
    owner: apache
    group: apache
    mode: 0400

.htaccessの設定変更

ファイルへのアクセスとか色々制御するために設定

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wordpress/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wordpress/index.php [L]
</IfModule>

<files wp-config.php>
order allow,deny
deny from all
</files>

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>  

<files wp-comments-post.php>
order allow,deny
deny from all
</files>      

DirectoryIndex index.html .ht

<Files wp-login.php>
AuthUserFile /var/www/.htpasswd
AuthGroupFile /dev/null
AuthName "Please enter your ID and password"
AuthType Basic
require valid-user
</Files>


<FilesMatch "wp-login.php|wp-admin">
Order deny, allow
Deny from all
Allow from xxx.xxx.xxx.xxx
</FilesMatch>

# END WordPress

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} rest_route=
RewriteRule ^$ /? [R=404,L]
</IfModule>

.htpasswdも合わせて設定

<wordpressのID>:<wordpressのパスワード>
#例:hogehoge:foobar1234

.htaccessと.htpasswdファイルをWordPressサーバに配布

インストール後に設定変更した分を配布するようにAnsibleを更新 (templateディレクトリに各ファイルをおいておく)

- name: set .htpasswd
  template:
    src: .htpasswd.j2
    dest: /var/www/html/wordpress/.htpasswd
    owner: apache
    group: apache
    mode: 0644

- name: set .htaccess
  template:
    src: .htaccess.j2
    dest: /var/www/html/wordpress/.htaccess
    owner: apache
    group: apache
    mode: 0644

他にも色々あるけど、ざっくりこんな感じ。

もうちょいいろいろ設定見ておく。

http://design-plus1.com/tcd-w/2015/09/security.html

ahalog.tdesignworks.net

viral-community.com

viral-community.com

memocarilog.info

viral-community.com

ブログ移住計画その3~ドメイン作成とサーバ証明書の契約まで~

naoyoshi.hatenablog.jp

続き。

今回はインストールとかじゃなくて、ドメインの設定とSSLの契約までやりました

ドメイン設定

WordPressを公開するからにはドメインがほしいと思い、早速契約

今回はムームードメインで契約した。

muumuu-domain.com

f:id:namusic701042:20180810192413j:plain

ここで自分が作りたいドメインを入力して、検索

アカウント作る。AmazonでSSOできるの便利 f:id:namusic701042:20180810192417j:plain

ユーザー情報とか、支払い情報を入力 f:id:namusic701042:20180810192420j:plain

ドメイン取得 f:id:namusic701042:20180810192424j:plain

EC2のインスタンスドメインを紐付ける

作ったドメインとEC2インスタンス(WordPressインスタンス)を紐付ける ドメイン系はAWSのRoute53を使ってマネージングする。

AWSのRoute 53から、

  • Hosted zonesに移動
  • Create Hosted Zoneを選択し以下の設定
    • Domain Name -> 作成したドメイン
    • Type -> Public Hosted Zone
  • Create Record setを選択し以下の設定

作成。

あと、Type=nsに入っているnsから始めるURLっぽいものをコピーしておく。

ドメインDNS紐付け

ムームードメインに戻る
ネームサーバ設定変更からさっき取得したドメインを選択

GMOペパボ以外 のネームサーバを使用するにチェックを入れて、さっきコピーしたnsから始めるURLを一つずつ入力

f:id:namusic701042:20180810192901j:plain

設定完了後、以下のコマンドを入力

dig <ドメイン名>

うまく表示されてた。

SSLサーバ証明書の契約

次にSSLサーバ証明書の契約。ほんとは設定まで行きたかったけど、AWS上にWordPressインストールしてないとできないから、ひとまず契約だけ。

今回はKingSSLで契約

www.kingssl.com

証明書用の鍵を作る

SSLの証明書用にopensslコマンドで秘密鍵を作る

mkdir  ./ssl
mkdir ./ssl/ssl.key
mkdir ./ssl/ssl.csr
mkdir ./ssl/ssl.crt
openssl genrsa -des3 -out ./ssl.key/hogehoge.com.2018.key 2048

次に秘密鍵を元にCSRを作成 csrファイルの中身をcatでコピペしておく

openssl req -new -key ./ssl.key/hogehoge.com.2018.key -out ./ssl.csr/hogehoge.com.2018.csr
cat ./ssl.csr/hogehoge.com.2018.csr

ちなみにCSR作成時に色々と聞かれるが、詳細はこちらから blog.bagooon.com

CSRファイルを使って証明書契約

KingSSLで契約

f:id:namusic701042:20180810192430j:plain

あとは、ユーザー情報とか支払い情報を入力したら契約成立

10分くらいすると指定したメールアドレス宛に証明書が届いた

f:id:namusic701042:20180810194159j:plain

次はWordPressのセキュアな設定をAnsibleに盛り込んでAWSにデプロイしたい

参考: お名前.comで取得したドメインをAmazon EC2に紐付ける

SSL証明書をインストールする(自分でやればこんなに激安!)

ConoHaVPSで動いているWordPressをSSL化しました。 | よだねっと

AWS EC2(Amazon Linux AMI 64-bit)のhttpdに無料SSL(Let’s Encrypt)を導入する | まろらぼ

ブログ移住計画その2~AnsibleでWordPressの構成管理~

インフラ部分は整ったので、
実際にインストールをしていくのですが、

ここではAnsibleを使ってインストールの構成管理をします。
で、いきなりAWS上でやるのはあれなので、一旦手元のPC(Mac)でVagrantを使ってテスト用に3台(プロビジョニング、WordPressMySQL)立てます

いろいろとインストールの記事(こことか)を読んでいくと、

がいるらしい。

で、今回はMySQLとそれ以外でインストール先を分けるのでそこも気にしながら進めていく。

Ansibleの構成

.
├── group_vars/
│   └── mysql.yml
├── inventory/
│   └── hosts
├── playbook.yml
├── roles/
│   ├── httpd/
│   │   ├── handlers/
│   │   │   └── main.yml
│   │   └── tasks/
│   │       └── main.yml
│   ├── mysql/
│   │   ├── handlers/
│   │   │   └── main.yml
│   │   └── tasks/
│   │       └── main.yml
│   ├── php/
│   │   └── tasks/
│   │       └── main.yml
│   └── wordpress/
│       └── tasks/
│           └── main.yml
└── templates/

※いらないとこ多々あり。今後スケール見越して一部ディレクトリ作ってます。

プロビジョニング先のIPの設定

Inventory/hostsファイルを作る

[wp]
192.168.33.90

[mysql]
192.168.33.91

## IPはその時による

MySQLのパスワードを変数化

group_vars/mysql.yml

mysql_root_password: "<rootパスワード>"
mysql_db_password: "<wordpress用ユーザのパスワード>"

httpd(Apache)のインストール他もろもろ

httpd/tasks/main.yml

- name: install apache
   yum:
     name: httpd

- name: start http server
   service:
     name: httpd
     state: started
     enabled: yes

頻繁にhttpdは再起動するので、再起動用のハンドラを作っておきます。 httpd/handlers/main.yml

- name: Restart httpd
    service:
    name: httpd
    state: restarted

PHPのインストール

php/tasks/main.yml

PHPを素直にインストール
php-develとphp-mbstringはいらないかも?
インストールあとにhttpdを再起動

- name: install php
   yum:
     name: "{{ item }}"
     state: latest
   with_items:
     - php
     - php-devel
     - php-mbstring
     - php-mysql
   notify: Restart httpd

WordPressをインストール

WordPressのみyumでインストールできないので、

  1. tar.gzでダウンロード
  2. ファイルを解凍

としています。

あとhtmlディレクトリに配置して、所有権もapacheにしています。

- name: download wordpress
   get_url:
     url="https://wordpress.org/latest.tar.gz"
     dest=/tmp/wordpress.tar.gz


- name: unarchive wordpress
   unarchive: src=/tmp/wordpress.tar.gz dest=/var/www/html/ copy=no

- name: change owner to apache
   file: path=/var/www/html/wordpress/ owner=apache group=apache recurse=yes


- name: restart httpd
   service:
     name: httpd
     state: restarted

MariaDBをインストール

MySQLと書いていましたけど、CentOS7はMariaDBが推奨らしいので、こっちをインストール

手順は以下の通り。

  1. MariaDBをインストール
  2. MariaDBを起動
  3. MariaDBのrootユーザを作成
  4. rootユーザでWordPress用のDB作成
  5. WordPressDB用のユーザ(wp)を作成
    5-1. IPはWordPressサーバに届くようにサブネット範囲設定
- name: install mariadb
   yum: name={{ item }} state=installed
   with_items:
     - MySQL-python
     - mariadb
     - mariadb-server
     - libselinux-python

- name: start mariadb
   service:
     name: mariadb
     state: started
     enabled: yes

- name: create root user
   mysql_user:
     name: root
     host: localhost
     password: "{{ mysql_root_password }}"
     login_user: root
     login_password: "{{ mysql_root_password }}"
     check_implicit_admin: yes

- name: create database for wordpress
   mysql_db:
     login_user: root
     login_password: "{{ mysql_root_password }}"
     name: wordpress
     state: present

- name: create user for wordpress database and attach previlage
   mysql_user:
     login_user: root
     login_password: "{{ mysql_root_password }}"
     name: wordpress
     password: "{{ mysql_db_password }}"
     priv: "wordpress.*:ALL"
     host:  192.168.0.0/255.255.0.0
     state: present

playbookの作成

各タスクを実行するplaybookを作成

- hosts: wp
   become: yes
   become_user: root
   tasks:
   roles:
     - httpd
     - php
     - wordpress

- hosts: mysql
   become: yes
   become_user: root
   tasks:
   roles:
     - mysql

Playbookの実行

ansible-playbook -i inventory/hosts playbook.yml

WordPressを入れたサーバにアクセス。

f:id:namusic701042:20180809175134j:plain

f:id:namusic701042:20180809175140j:plain

うまくいきました。
(初期設定の画像を取り忘れた・・・)

とりあえず、問題なさそう。
ただAWSに乗せるにはもうちょっと設定をカスタマイズしたいので、いろいろ触ってみます。

参考URL:

thinkit.co.jp

cflat-inc.hatenablog.com

walkingmask.hatenablog.com

ブログ移住計画その1~AWSでインストールの下準備~

前回の記事であげたように、この夏休み中にWordPressにブログを移行しようと考えています。
で、今日はその初回。
ただ単にWordPressをインストールするだけならどこかサーバを借りてデフォルトでインストールすれば問題ないのですが、
せっかくなので自称エンジニア(?)らしく技術的な部分も取り入れつつやってみます。

今回のWordPressインストールではAnsibleを使ってAWS(EC2)上に立てたいなと思います。

構成図はこんな感じ。

f:id:namusic701042:20180808104230j:plain

セキュリティにも考慮して、 踏み台経由でのSSHログインでWordPress用のDBにするMySQLサーバはPrivateのサブネット内に入れておきます。

AWS上でインストールの下準備

VPCの構築

まずは、VPCを作ります。

項目
名前 wordpress-vpc(仮名)
IPv4 CIDR 10.0.0.0/16

サブネットの構築

次にサブネットです。
今回は踏み台+wordpress用のサブネットとDB用のサブネットを作ります。

DMZサブネット

項目
名前 dmz(仮名)
VPC wordpress-vpc
アベイラビリティゾーン 自由に設定
IPv4 CIDR 10.0.1.0/24

設定後、自動割当IP設定の変更で

  • パブリックIPv4アドレスの自動割当を有効にする

にチェックをつけておく

Privateサブネット

項目
名前 private(仮名)
VPC wordpress-vpc
アベイラビリティゾーン 自由に設定
IPv4 CIDR 10.0.2.0/24

インターネットゲートウェイの作成

次にDMZ内のサーバ(インスタンスに)インターネットから直接アクセスさせるためのゲートウェイを作成

  1. インターネットゲートウェイの作成から名前をつけて作成
  2. 新規作成したゲートウェイを選択してアクション->VPCにアタッチ
  3. 最初に作ったVPCを設定

NATゲートウェイの作成

DMZ内のインスタンスとインターネットは接続できるのですが、
DB側インスタンスにはインターネットと接続できません。
セキュリティ的にはOKなんですけど、
これだとMySQLをインストールしたいときとかメンテナンス、アップデートするときにちょっとやっかい。
なので、

インターネット→プライベートサブネットは✕
プライベートサブネット→インターネットは○

みたいなことをうまいことしてくれるNATゲートウェイを作っておきます。
(これ結構金かかるんですよね・・・なので必要なときだけたてて、いらないときは削除予定)

NATゲートウェイの作成から、
1. サブネットでDMZサブネットのIDを指定 2. ElasticIPを設定

ルートテーブルを設定

NATゲートウェイ・インターネットゲートウェイとサブネットを紐付けるために、 ルートテーブルを作成

ルートテーブルの作成から、名前とVPCを指定して2つ作成

DMZサブネット

  1. サブネットの関連付けでDMZサブネットの関連付けにチェック
  2. ルートを編集し、以下を追加
送信先 ターゲット
0.0.0.0/0 インターネットゲートウェイID

Privateサブネット

  1. サブネットの関連付けでPrivateサブネットの関連付けにチェック
  2. ルートを編集し、以下を追加
送信先 ターゲット
0.0.0.0/0 NATゲートウェイのID

SSHの鍵を作成

サーバを立てる下準備の最後として公開鍵作ります。
というのも、基本的にAWS上のサーバにアクセスするときは公開鍵使うんですけど、AWSのサーバ立てるときに自動で落ちてくる鍵はパスフレーズなしなんですよね。。。
そんな鍵を使いたくないので、自作で作ってインポートさせます。

ssh-keygen -t rsa -b 4096 -f <鍵名>.pem

本当は、

ssh-keygen -t ed25519 -f <鍵名>.pem

ed25519暗号で生成した鍵を使いたかったけど、なぜかインポート時にエラーが出た

暗号はED25519は意識高すぎ、高杉くんらしい。
暗号鍵参考URL

AWSのEC2からキーペアに移動して、
キーペアインポートから作ったキーをインポート

インスタンス作成

これで心おきなくインスタンスを作成 ひとまず3台立てる

  • 共通項目
    • OSはCentOS7
    • SSH鍵はさっき作ったものを使用
  • 踏み台サーバ
    • t2.micro
    • SSD15GB
    • サブネットはDMZサブネット
    • セキュリティグループは22とSSH用の別ポートを一旦開けておく
  • Wordpressサーバ
    • t2.small
    • SSD20GB
    • サブネットはDMZサブネット
    • セキュリティグループは80,443を一旦開けておくsshは踏み台からのみアクセス可能に
  • MySQLサーバ
    • t2.small
    • SSD30GB
    • サブネットはPrivateサブネット
    • セキュリティグループはDMZサブネットに対して公開

これでサーバ建てられた

SSHログインの確認

3台のサーバにSSHでログインできるか確認します。 ただ、踏み台以外のサーバは直接SSHできないので、踏み台経由でログインするように設定します。

Macの場合:

# ~/.ssh/configファイルの中に記述
Host wp-bustion
    HostName <踏み台インスタンスのパブリックIP>
    User centos
    Port 22
    GatewayPorts yes
    IdentityFile ~/.ssh/<公開鍵のファイル>

Host wordpress
    HostName <WordPressインスタンスののプライベートIP>
    User centos
    Port 22
    GatewayPorts yes
    ProxyCommand ssh -CW %h:%p wp-bustion
    IdentityFile ~/.ssh/<公開鍵>

Host wp-mysql
    HostName <MySQLインスタンスのプライベートIP>
    User centos
    Port 22
    GatewayPorts yes
    ProxyCommand ssh -CW %h:%p wp-bustion
    IdentityFile ~/.ssh/<公開鍵ファイル>

ssh-addコマンドで毎回パスフレーズを入力しなくていいように設定

ssh-add ~/.ssh/<公開鍵ファイル>

実際にログインして確認

ssh wp-bustion
ssh wordpress
ssh wp-mysql

ログイン成功。

踏み台サーバのSSHポートを変更する

ここは賛否両論あるみたいなんですが、せっかくなのでポート変えておきます。

###踏み台インスタンスにログイン
### /etc/ssh/sshd_configを開いて以下を編集

###Port22
Port <新しいポート番号>

このあと

systemctl restart sshd

で再起動して、一旦ログアウト。

ローカルで~/.ssh/configのところで、

Host wp-bustion
    HostName <踏み台インスタンスのパブリックIP>
    User centos
    Port <新しいポート番号>
    GatewayPorts yes
    IdentityFile ~/.ssh/<公開鍵のファイル>

と編集。
再度SSHログイン。

うまくいった。

これで下準備完了

夏休みブログ移住計画

今日はあくまで宣言だけするよ。

そろそろお盆がきますね。
自分の会社も例にもれずお盆休みなるものがあります。

こういう長期的な休みの前になると、どこに遊びに行こうかとか、
誰とご飯食べにいこうかと考えるのもあるのですが、
その一方でなにか勉強しようかなーと考えるのも結構好きなんです。

で、普段はどちらかというとインプットよりでひたすら技術書含め本を読むことが多いのですが、
たまにはこれまでのアウトプットをやりたいなと思い、いろいろ考えた結果、このブログを移住させようと考えました。
(といってもそんなにこのブログであれこれ書いてないですけど・・・)

移住計画概要

  • 概要
  • 目的
    • 自分のもってるインフラ知識をアウトプットさせたい
    • アクセスログ等のデータをとって簡易的なデータ基盤の構築
    • データを使って分析やら機械学習やらやりたい
  • 目標
    • ひとまず夏休み中(19日まで)に移住完了させたい
    • 今年中にデータの基盤やら分析やらできたらいいな
  • 手順
    • AWS上にWordPress構築
      • VPCでセグメントを分けてEC2を立ててアプリとDBを入れる
      • ロードバランサとか冗長構成は後に回す
    • セキュア対応
      • SSLとかサーバの設定をいじる
    • ブログ公開
      • ドメイン発行
      • フロントエンドの知識は少ないけどちょっとくらいいじろうかな
    • データ基盤
      • 同じくAWSで立てる
      • せっかくなのでFluentdとかKafka使ってリアルタイムデータで持ってきたい
      • ストレージならびに処理基盤は考え中(勉強がてらBigQueryとかSparkやら使ってみたい)
    • データ分析

とこんな感じ。

ま、とりあえず書けば自分の重い腰もあがるやろうということで今日はあくまで宣言のみ。 明日からやってみる。

Ubuntu16にCDH6(Beta)をManagerなしでインストール

最近Clouderaの動向をウォッチしていなかったのですが、 知らぬ間にCDH6がリリースされていました。

https://www.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_cdh_6_release_notes.html

※まだベータ版らしいです。

CDH6はHadoop3.0.0やSparkも2系がデフォルトで入っているようで、 新しい機能を試してみるのにサクサク入れられるディストーションとしても使えそうです。

というわけで、ひとまずデフォルトでインストールしてみました。 CDH5版インストール方法はこちらの記事から

というより前記事とほとんどインストール方法は変わりません。

インストール参考URL

ちなみにCloudera Managerを使ったのインストールはこちらから(めっちゃ簡単)

環境

Javaのインストール

ひとまず、java8を先に入れて、PATHを通しておきます。

sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get -y install oracle-java8-installer
cat << EOF >> ~/.bashrc
JAVA_HOME=/usr/lib/jvm/java-8-oracle
PATH=$PATH:$JAVA_HOME/bin
export JAVA_HOME
export PATH
EOF
source ~/.bashrc

cdh.listファイルの作成

/etc/apt/sources.list.dの中にcdh.listというファイルを作成

cd /etc/apt/sources.list.d
sudo touch cdh.list

## vimやEmacsなどでcdh.listの中に以下のコマンドを入力
deb [arch=amd64] https://archive.cloudera.com/cdh6/6.0.0-beta1/ubuntu1604/apt xenial-cdh6.0.0-beta1 contrib
deb-src https://archive.cloudera.com/cdh6/6.0.0-beta1/ubuntu1604/apt xenial-cdh6.0.0-beta1 contrib

Hadoopリポジトリ登録

sudo wget https://archive.cloudera.com/cdh6/6.0.0-beta1/ubuntu1604/apt/archive.key
sudo apt-key add archive.key

Hadoopインストール&起動

あとは素直にHadoopを入れて動かすだけ。

sudo apt update
sudo apt-get install -y hadoop-conf-pseudo

sudo -u hdfs hdfs namenode -format

sudo systemctl start hadoop-hdfs-namenode hadoop-hdfs-datanode hadoop-hdfs-secondarynamenode

sudo /usr/lib/hadoop/libexec/init-hdfs.sh


sudo systemctl restart hadoop-hdfs-namenode hadoop-hdfs-datanode hadoop-hdfs-secondarynamenode

sudo systemctl start hadoop-yarn-resourcemanager hadoop-yarn-nodemanager

結論

やっぱりCloudera ManagerとCloudera Directorは正義。

なるべくお金をかけずにお手軽運用でサーバを扱う(検証、テスト用)

なるべくお金をかけずにお手軽運用でサーバを扱う(検証、テスト用)1,2年前にまとめていたけど、

下書きで残しっぱなしだったので、今更載せておきます。

前ふり

AWSクラウドでサーバを立てる時に気になるお金。
なるべく課金を減らすために必要なときだけ立てて、
いらなければ落とすなんてことをしますよね。

でも落とした後に起動するとやっかいなのがIPアドレスの変更。
毎回毎回アドレスが変わってしまうとssh config等の設定を変えないといけなかったりして面倒なんですよね。

かといってElasticなIPを使うとそれでもお金がかかってしまうので嫌だ。。。
というわけで、なるべくお金をかけずにかつ設定をなるべく変えないでサーバを扱う方法を自分なりに試行錯誤してみたやつです。

※今回の例はあくまで検証や遊びでサーバを立てて使う人用の方法です。本番システムでの利用は推奨しません。

やること

  • VPCを作成
  • パブリックサブネットとプライベートサブネットを立てる
  • インターネットからパブリックサブネットにアクセスさせる設定
  • パブリックサブネットに踏み台サーバを立てる
  • プライベートサブネットに検証サーバを立てる
  • ssh configで踏み台経由でサーバにアクセスする設定を行う
  • ssh <設定名>でいつでもアクセスできる やっていることのほとんどはAWSEC2のデザインパターンとかでよくみるやつです。

VPCの作成

まずは、VPCを作成します。
AWSのユーザーコンソールからVPCに移動

設定項目 設定値
名前タグ 適当な名前で
IPv4 CIDRブロック なんでもいいけどVPCにいっぱいサーバを立てるなら10.0.0.0/16が順当かと
IPv6 CIDRブロック ブロックはなしで
テナンシー デフォルトでOK

パブリックサブネットとプライベートサブネットを立てる

続いてサブネットを作ります。
ユーザーコンソールからVPC -> サブネットに移動。
サブネットではインターネット経由でアクセスできるパブリックサブネットとプライベートサブネットを設定します。

  • パブリックサブネット側
設定項目 設定値
名前タグ 適当な名前で
VPC さっき作成したVPC名を指定
アベイラビリティーゾーン 今回は特に指定なしでOK
IPv4 CIDRブロック VPCで設定したブロック内で範囲を指定。今回は10.0.1.0/24としておく。
  • プライベートサブネット側
設定項目 設定値
名前タグ 適当な名前で
VPC さっき作成したVPC名を指定
アベイラビリティーゾーン 今回は特に指定なしでOK
IPv4 CIDRブロック VPCで設定したブロック内で範囲を指定。今回は10.0.2.0/24としておく。

インターネットからパブリックサブネットにアクセスさせる設定

ここは大事なところ。 2つサブネットを作成した後に、パブリックサブネットのみ選択して、サブネットのアクション-> 自動割り当てIPの設定変更 に飛ぶ
そこで、 パブリックIPv4アドレスの自動割り当てを有効にする にチェック。
これをやっとかないと踏み台サーバ立てても外部からサーバにアクセスするための外部IPを発行してくれません。

次にやるのはインターネットとパブリックサブネットをつなぐゲートウェイ(窓口みたいなもの)の設定

  1. VPC -> インターネットゲートウェイに移動
  2. インターネットゲートウェイの作成を押して文字通り作成(名前は適当に)
  3. さっき作ったゲートウェイを選択して、 アクション->VPCのアタッチを選択
  4. VPCでさっき作ったVPCを選択してアタッチ
  5. VPC -> ルートテーブルに移動
  6. 作ったVPCに紐づくルートテーブルを選択。
  7. 下部にあるルートタブを選択して編集。
  8. 別のルートを追加を選択。以下のように設定
送信先 ターゲット
0.0.0.0/0 さっき作ったゲートウェイの名前

これでできました。

パブリックサブネットに踏み台サーバを立てる

ここから踏み台サーバを立てます。
サーバの立て方は基本的な方法と同じなので割愛。
一般的な立て方と違うのは以下の点。

  • インスタンスのタイプはt2.nano(踏み台用途なので and 24時間稼働を想定してなるべくお金がかからないように)
  • インスタンスの詳細の設定にて
    • ネットワーク -> 作ったVPCの名前
    • サブネット -> パブリックサブネットの名前

プライベートサブネットに検証サーバを立てる

今度はプライベート側に実際に使用するサーバを立てます。
こちらも基本的な立て方は同じ。
変更点は以下の点

  • インスタンスの詳細の設定にて
    • ネットワーク -> 作ったVPCの名前
    • サブネット -> プライベートサブネットの名前
  • セキュリティグループは基本的に全開放でも問題ないが、気にされる方は必要なポートをパブリックサブネットのIPに指定するとよし。

ssh configで踏み台経由でサーバにアクセスする設定を行う

サーバが立てられたので、sshでつなぐ設定をします。 今回はmacを想定し、macの.ssh/configに設定をします。

# ~/.ssh/config
Host humidai
        HostName <踏み台サーバのパブリックIP>
        User ubuntu #サーバによって変化
    Port 22 #sshポート
        GatewayPorts yes
        IdentityFile ローカルマシン内で踏み台サーバの公開鍵が置いてある場所

Host server
        HostName <10.0.2.xxとなるIP>
        User ec2-user #サーバによって変化
        Port 22
        GatewayPorts yes
        ProxyCommand ssh -CW %h:%p humidai #humidaiは上記設定したHostの名前を指定
        IdentityFile ローカルマシン内で検証サーバの公開鍵が置いてある場所

# ProxtCommandが踏み台サーバ経由でsshサクセスさせるためのコマンド

この設定をした後、

ssh server

とコマンドを入力すると、踏み台経由でアクセスできます。
しかも、検証サーバを一旦落として再度あげてもプライベートIPは変わらないので、そのままsshコマンドで入れます。
また、ポートフォワーディングしたい場合は、

# ~/.ssh/config

#踏み台側
   LocalForward 5432 localhost:5432
      LocalForward 8080 localhost:8080
#サーバ側
        LocalForward 5432 <サーバのプライベートIP>:5432
        LocalForward 8080 <サーバーのプライベートIP>:8080

と設定すればOK

懸念事項

1 この構成にすると、サーバ側からインターネットにつなぐことができないので、wgetとかでファイルを落としたりすることはできません。
これについては別途NATインスタンスとかNATゲートウェイが必要になるのですが、いずれにしてもお金がかかる。。。。
なので、しょっちゅうインターネットにアクセスしないのであれば、ローカルマシンに対象ファイルを落としてscpコマンドで移動がよいかなと。
実際scpコマンドで移動させる場合でも

scp <移動させるファイル> server:/home/ec2-user

みたいな感じで簡単に移動できます。

2 この構成は踏み台サーバは常時稼働を想定しています。踏み台サーバはt2.nanoの最小構成なので、
$0.0058 /1 時間 -> 500円くらい/1ヶ月
が必要経費になります。

ただ、毎回毎回IPアドレスを変える手間とか、めんどくさくてサーバをずっと起動させることによる課金等を考えると決して高い値段ではないかなと。

終わりに

今回は最近良くやるAWSでの検証サーバ構築用のシステムを紹介しました。
上述したように、この構成は本番構成でもやるような部分も含まれていますので、特にAWS初心者の方はぜひチャレンジしてみるといいかもしれません。

ホントの最後に

間違いとか、わからないとこがあればコメントとかしていただければ!!