カテゴリー: クラウド

Systems Manager セッションマネージャーを利用したEC2へのリモート接続

クラウド事業部の上野です。

AWSのプライベートなネットワーク(インターネット上から直接アクセスできないネットワーク)上に立てたEC2インスタンスへのsshアクセスはどのように行われていますでしょうか?よくある構成としてはパブリックなネットワーク(インターネット上からアクセスできるネットワーク)上にあるEC2インスタンスを経由してアクセスといったものがあります。俗に踏み台サーバやBastionサーバと呼ばれるものです。弊社でも踏み台サーバを用意することが多いですね。

ところがAWSにはEC2インスタンスへのアクセスをサポートするSystems Manager セッションマネージャーという機能があります。
これはEC2にインストールされているSSM エージェントを利用してリモート接続を行います。SSMエージェントを利用すればネットワーク的に接続できないEC2インスタンスへ接続することも可能ですし、sshを使わないのでsshdのサービスを停止してもアクセスすることができるという優れものです。長年サーバ管理者をやっていますが、sshdを止めれる日が来るなんて思いもしなかったです。

それでは試してみましょう。
プライベートネットワーク上にEC2インスタンスを起動し、セッションマネージャーを利用してアクセスするということをやってみたいと思います。

まず、AWSアカウント作成後に標準で準備されているVPCにプライベートネットワークを用意します。

f:id:seeds-std:20190917124214p:plain
ssm01

このプライベートネットワーク上にEC2インスタンスを立てます。このインスタンスはパブリックIPを持たないため外部から直接ssh接続することはできません。

f:id:seeds-std:20190917124322p:plain
ssm02

次にSystems Manager をEC2が利用できるようにIAMロールを作成してEC2インスタンスに設定します。
ロールに設定するポリシーは AmazonEC2RoleforSSM になります。

これで準備が整いました。では早速インスタンスに接続してみましょう。
AWSマネジメントコンソールより、Systems Manager -> セッションマネージャーを開きます。
セッションの開始というボタンを押すとインスタンスの一覧が表示されます。インスタンスを選択し、セッションの開始ボタンを押します。

f:id:seeds-std:20190917124836p:plain
ssm04

するとWebブラウザでコンソールの画面が開きます。
ユーザはssm-userというユーザで接続されているようですね。sudoコマンドを使ってroot権限得ることもできます。

f:id:seeds-std:20190917125109p:plain
ssm05

それでは試しにsshdのサービスを止めてみましょう。
リモートからsshdを止めるなんていう暴挙は初めてです。sshdを停止してもアクセスできていることが確認できます。

f:id:seeds-std:20190917125237p:plain
ssm09

セッションの履歴からどのIAMユーザで接続されたかを確認することができます。

f:id:seeds-std:20190917140113p:plain
ssm06

セッションの詳細な情報をログとして出力することも可能です。
CloudWatch Logsに出力するように設定するとこのようになります。実行されたコマンド一つ一つまで記録されていますね。

f:id:seeds-std:20190917135950p:plain
ssm007

S3にファイルとして保管させることも可能です。

f:id:seeds-std:20190917140412p:plain
ssm08

いかがでしたか。

比較的容易にセッションマネージャーを使ってアクセスすることができました。
セッションマネージャーのいいところは踏み台サーバが不要であるということだけではなく、EC2インスタンスへのアクセスをIAMユーザで管理できるということにあります。
ログもコマンドレベルで出力されていますので、いざという時の監査ログとしても利用できそうですね。
今後は踏み台サーバではなく、セッションマネージャーを使うことも考慮に入れていきたいと思います。

弊社コーポレートサイトリニューアルとその裏側

お久しぶりとなってしまいました。原口です。

10/1に弊社コーポレートサイトがリニューアルされました。

www.seeds-std.co.jp

今回、社長より「技術的な部分は自由にやっていいよ」という事でしたので自由にやらせていただきましたので、
このサイトにおける技術的な部分にフォーカスして紹介をしていきたいと思います。

システムコンセプト

通常コーポレートサイトといいますとwordpressなどのCMSの導入をする事がほとんどです。
弊社でもこれまではwordpressを利用していましたが運用するうちに気づいた事として管理が非常に面倒という点がありました。
サイトの更新よりもwordpressのアップグレード回数の方が多かった・・・となる月もザラにあり、
更新の簡単さと差し引いても目に見えにくい人的コストが高い状態は否めませんでした。

そのため、リニューアルにあたっては早いうちから、管理コストの少ない構成とする事は決めていました。
できる限り静的ファイルのみでの公開をし、お問い合わせフォームなどの、どうしてもプログラムの必要な部分は
サーバーレスアーキテクチャを採用するという方針を決定致しました。

バックエンド

インフラ構成は以下の通りです

f:id:cs_sonar:20181009211159p:plain

サイトの大部分はs3で公開されています。
デプロイは開発者のローカル環境より

npm run prod

といったビルドコマンドでs3に同期するような仕組みです。

大部分はs3で公開されている為、s3は静的ホスティングとしています。
前段にcloudfrontをかませていますが、これは独自ドメインにてSSLを使いたかったが為に使用しています。
そのためキャッシュ及びネガティブキャッシュのTTLは0です。
SSLはACMで取得しました。

唯一お問い合わせフォームがシステムに絡む部分となりますので
こちらはAPI gatewayとlambdaを利用しています。
この部分は一括して、リードプログラマの川勝さんに担当していただけました。

lambdaはvalidateと、SMTP-AUTHにて別のサーバーにメールリレーするだけの簡単なプログラムとなっています。
サーバレスといいつつ、唯一メールサーバーのみ弊社データセンタを利用していますが、
こちらも本来はAWS SESを利用しても問題はないかと思います。

この構成で約10日間ほど運用していますが現在で総額 $1.5ほどの費用となります。
TOPページに動画を使っている関係かこのうちの$1.2は転送量(cloudfront)です。
このままでおおよそ$5/monthほどのコストで運用できるのではないでしょうか。

この低コストに加えて、サーバー機の保守やOS、ミドルウェア、アプリケーションの脆弱性など、
まったく考えなくてもよいという見えない人的コストも大きく削減されています。

フロントエンド

フロントエンド側では弊社フロントチームに新卒で参加した寺澤さんがコーディングから実装までほぼすべてを行いました。
モバイルファーストを考え、スマフォの際はできるだけ転送量がかからないようjsやcssをminifyを行ったり、モバイル端末の際はTOP動画をgifアニメにするなどの変更を行っています。PC側の動画の圧縮なども作業いただきました。

静的ファイルを生成するという構成上、テンプレートエンジンの利用は当初より考えていてPugを使用しています。
ビルドはgulpを利用していて、ビルド時のコマンドで生成したhtml、css、画像、jsをs3へ持っていく形としています。

jsフレームワークはVue.jsです。スライダーやページの動きはこちらで実装し、一部ページ(newsや制作実績、お問い合わせページ)ではSPAっぽいもので構成しています。

1点、起こった問題として、s3静的サイトホスティングではmod_rewriteのようにURLの書き換えができない点がありました。
リダイレクトは可能なのですがリライトはできないのですね・・・。
前述の通り一部ページはSPAでの実装を行っていたのですが、
s3での運用に際し、この点はURLが少し不格好となってしまいますがクエリストリングで対応するようにしました。

デザイン

昨年、弊社に入社されたデザイナーの河野さんが全て取り仕切って行ってくれました。
モバイルファーストと呼ばれるこの時代・・・レスポンシブデザインをベースに
スマフォでいかに見やすいか、という点を注意してデザインいただけました。

TOPにて背景動画を流したり、遊び心のあるイラスト(河野さんの自作!)など、素敵なデザインになったと思います。
イラストの一部にシーズ社員数名が紛れ込んでいるので、是非探してみてください。

終わりに

今回の構成では今後できるだけ手間をかけない、可能な限り今後の運用が低コストとなるよう考えて制作しました。
通常CMSと考えるとwordpressやサーバー、そしてデータベースの準備などなど、、、様々な事がデファクトスタンダードとして存在しますが、
規模に対して過剰な設備であったり、本来注視すべきコンテンツ以上にこれらの対応で時間が取られる事もしばしばあります。
本当にそこまで必要なのか?本当にそれらを準備しないと目的が達成できないのか?
という観点は通常のシステム開発でもとても重要なものであると改めて思いました。

同様の事例でお困りの事があれば是非、ご相談下さい!

社内WindowsサーバーをAWSに移行する話1

経緯

シーズでは、見積書・請求書の発行などに社内にWindowsサーバーを立て弥生販売を使っていました。

複数拠点から複数人が同時に使うためネットワーク版5ライセンスです。

社内にサーバーを置くメリットとして、

*ギガビットLANでの高速アクセス

*社外との通信が発生しないためセキュリティーが高い

*売るほどサーバーラックがあるのでコストはあまり気にならない

といった利点がありましたが
サーバー筐体費用、Windowsサーバー、SQLライセンスなどの初期費用(トータル約40万※構築費用は自前のため無料)がかかるうえ
毎年のライセンス更新や筐体保守費用、また毎月の電気代・空調費用も馬鹿になりません。
さらに、場所も取るし、空調にも気を使うし、なにかとメンテも大変なのでクラウドに行きたいと考えておりました。

要件

*AWSで24時間365日稼働(ただし夜間は止めるかも)

*OSはWindowsサーバー2012

*弥生販売ネットワーク版5ライセンスを動かす

*シーズ社内とVPNでセキュアに常時接続

特に最後のVPNで社内とシームレスかつセキュアに接続が一番重要ですね。

これらの要件をAWSでこのように準備しました。

AWS構成

*ec2インスタンス(Windows2012) t2.small $36.60

*EBS45GB $5.40

*VPC VPN接続 $36

合計 約78ドル=約8,424円 (1ドル108円)

f:id:panmizser:20161121214003p:plain

EBSボリューム、転送量、EIP、IOなど少額の従量制がありますが、それらを含んだとして、約8,500円です。

移行してどうだったか

結論としては、最高でした。

まず費用としては

サーバー1台をデータセンターでハウジング(月50,000相当,OSライセンス諸々込)として、それが月8,500円ポッキリになりました。(83%DOWNです!)

また弥生を使わない夜間止めることで更にコストダウンも可能です。

次に、回線速度やアプリの使用感ですが、こちらも全く問題ありません。

インスタンスタイプは最初 large → medium と様子を見ていきましたが最終的にはsmallまで落としても操作感に問題ありませんでした。

(ただし弥生インストール時はlargeでやったほうが効率がいいです)

回線速度は、AWSの提供するVPNサービスを利用することで全くストレスを感じません。
(以前、WindowsインスタンスからPPTPで会社ルーターに繋げたりしたことがありましたが、その場合、一応つながりますが、結構遅かったです。)

次回は、これらAWSの設定、社内VPNルーターの設定を含め詳しく解説していきたいと思います。

EC2でCentOS6のEBS-Backed AMIをゼロから作る

はじめまして。サーバーインフラ担当の原口です。

64bitの完全クリーンなCentOS環境のEBS-Backed AMIを作成する手順です。
Amazon公式のAMIを使えよ!って話なんですがOSって基本なのでシーズでは完全にゼロからクリーンインストールを行ったCentOSを用意して使用しています。今回はその手順を公開したいと思います。

※2013/06/10 作成したEBSをAMI化する を編集しました
※2013/06/13 CentOSのいつからかのバージョン(kernel)からfstabにてLABELでの指定を行っていると以下のようなエラーが出た後にKernel Panicとなるようになっていたので、fstabとgrubの設定を修正しました。

dracut Warning: No root device "block:/dev/disk/by-label/_\x2f" found

この手順作成にあたり、以下のブログやサイトを参考にしました。

[Amazon EC2] AMI をゼロから作る CentOS 6.2 / S3-Backed 版
SUZ-LAB謹製 CentOS AMI 6.0.0″の作り方
Amazon EBS-Backed AMI の作成 (公式)
Amazon loopback S3-Backed の作成 (公式)
Sharing AMIs Safely

事前準備

https://portal.aws.amazon.com/gp/aws/securityCredentials
・X.509証明書
→AWSに登録したら新規作成が必要。作成した証明書や秘密鍵は大切に保存。
基本的に何個も作る必要はなくて1個あればOKです。
作成したOSイメージをAMIとして登録するのに必要です。

適当なPublic AMIでインスタンス作成

RightScaleのCentOSでインスタンス作成します。
AMI: RightImage_CentOS_6.3_x64_v5.8.8 (ami-7c9e237d)

Amazon EC2 AMI Tools のインストール

起動したインスタンスへログインしてAmazon EC2 AMI Toolsをインストールします。

rubyが必要なのでまずはrubyのインストール

yum install ruby

続いてec2-ami-toolsのインストール

cd /usr/local/src
wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm
rpm -ihv ec2-ami-tools.noarch.rpm

EBSを作成してアタッチ

20GBくらいで適当なEBSを作ってインスタンスにアタッチ。この作成した容量はそのままAMIの基本容量となるので、ここまで必要がなければ8GBくらいで作ってOKです。
/dev/sdfとして認識されるとかかれているけど実際は/dev/xvdf として認識されるので注意して下さい。

EBSをフォーマット&マウント

アタッチしたEBSをインスタンス上でフォーマットして適当なところにマウントします。

CentOS6からデフォルトでext4なのでext4でフォーマット

mkfs.ext4 /dev/xvdf

できたら適当なとこにマウント

mkdir /data
mount /dev/xvdf /data

dfでマウントできたか確認を行って下さい。

インストール用のファイルを作成

ここからはアタッチしたボリュームへのCentOSインストールの事前準備となります。

まずはデバイスファイルの作成。

cd /data
mkdir etc proc dev
vi etc/fstab

以下のように作成

/dev/xvde1 / ext4 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
mount -t proc none proc

インストール用の yum.conf を作成

今回はrikenさんのmirrorを使用したいと思います。
まずは鍵ファイルを入れておきます。

cd /data
wget -O ../RPM-GPG-KEY-CentOS-6 http://ftp.riken.jp/Linux/centos/RPM-GPG-KEY-CentOS-6

repos.confの作成

vi ../repos.conf

以下のように編集

[ami-base]
name=CentOS-6 - Base
mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os
gpgcheck=1
gpgkey=file://${PWD}/../RPM-GPG-KEY-CentOS-6
<h3>released updates</h3>
[ami-updates]
name=CentOS-6 - Updates
mirrorlist=http://mirrorlist.centos.org/?release=6&amp;arch=x86_64&amp;repo=updates
gpgcheck=1
gpgkey=file://${PWD}/../RPM-GPG-KEY-CentOS-6

CentOS6のインストール

準備が整ったのでCentOS6のインストールを行います。
ついでにec2-ami-toolsのインストールも行っています。
この作業は時間がかかります。

cd /data
setarch x86_64 yum -y -c ../repos.conf --installroot=$PWD --disablerepo=* --enablerepo=ami-base,ami-updates groupinstall Core
setarch x86_64 yum -y -c ../repos.conf --installroot=$PWD --disablerepo=* --enablerepo=ami-base,ami-updates install kernel
setarch x86_64 yum -y -c ../repos.conf --installroot=$PWD --disablerepo=* --enablerepo=ami-base,ami-updates install ruby rsync
rpm -Uvh --root=$PWD http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm
wget -O usr/bin/ec2-metadata http://s3.amazonaws.com/ec2metadata/ec2-metadata
chmod +x usr/bin/ec2-metadata

grubの設定

grubの設定
以下のようにgrubのmenu.lstを作成します

cat &gt; boot/grub/menu.lst &lt;&lt;EOS
default=0
timeout=0
hiddenmenu
title CentOS6.4
root (hd0)
kernel /boot/vmlinuz-$(rpm --root=$PWD -q --queryformat &quot;%{version}-%{release}.%{arch}\n&quot; kernel) ro root=/dev/xvde1
initrd /boot/initramfs-$(rpm --root=$PWD -q --queryformat &quot;%{version}-%{release}.%{arch}\n&quot; kernel).img
EOS

ネットワーク設定

ネットワーク設定ファイルを作成します。
初回のIP取得はDHCPを使って行われます。

vi /data/etc/sysconfig/network-scripts/ifcfg-eth0

以下のように編集。

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=yes
IPV6INIT=no
vi /data/etc/sysconfig/network

以下のように編集。

NETWORKING=yes
vi /data/etc/hosts

以下のように編集。

127.0.0.1 localhost.localdomain localhost

rc.local に ssh 公開鍵を取得する設定を追加

初回起動で公開鍵を設定できなければ、だれもログインできないインスタンスとなる為、必須作業です。
今回のスクリプトでは起動時にec2-ami-toolsの更新も行われるように作成されています。

vi /data/etc/rc.local

以下の文を追記。

#Update the Amazon EC2 AMI creation tools
rpm -Uvh http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm
#Update ec2-metadata
wget -O /usr/bin/ec2-metadata http://s3.amazonaws.com/ec2metadata/ec2-metadata
chmod 755 /usr/bin/ec2-metadata
if [ -f "/root/firstrun" ] ; then
dd if=/dev/urandom count=50|md5sum|passwd --stdin root
rm -f /root/firstrun
else
echo "* Firstrun *" &amp;&amp; touch /root/firstrun
fi
if [ ! -d /root/.ssh ] ; then
mkdir -p /root/.ssh
chmod 0700 /root/.ssh
fi
ATTEMPTS=5
FAILED=0
#Fetch public key using HTTP
while [ ! -f /root/.ssh/authorized_keys ]; do
curl -f http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key &gt; /tmp/aws-key 2&gt;/dev/null
if [ $? -eq 0 ]; then
cat /tmp/aws-key &gt;&gt; /root/.ssh/authorized_keys
chmod 0600 /root/.ssh/authorized_keys
rm -f /tmp/aws-key
echo "Successfully retrieved AWS public key from instance metadata"
else
FAILED=$(($FAILED + 1))
if [ $FAILED -ge $ATTEMPTS ]; then
echo "Failed to retrieve AWS public key after $FAILED attempts, quitting"
break
fi
echo "Could not retrieve AWS public key (attempt #$FAILED/$ATTEMPTS), retrying in 5 seconds..."
sleep 5
fi
done

各種設定

sshdの設定

perl -p -i -e 's,^#PermitRootLogin yes,PermitRootLogin without-password,' etc/ssh/sshd_config
perl -p -i -e 's,^#UseDNS yes,UseDNS no,' etc/ssh/sshd_config
perl -p -i -e 's,^PasswordAuthentication yes,PasswordAuthentication no,' etc/ssh/sshd_config

SELinuxの設定

vi /data/etc/sysconfig/selinux
SELINUX=enforcing
↓
SELINUX=disabled

作成したEBSをAMI化する

ここまででCentOSディスク(EBS)の作成は完了です。
ここからはこのEBSイメージをAMI化する作業です。

マウントしているEBSの不要ファイルを削除してアンマウント

cd /data
setarch x86_64 yum -y -c ../repos.conf --installroot=$PWD --disablerepo=* --enablerepo=ami-base,ami-updates clean all
cd ..
umount /data/proc
umount /data

アンマウントが完了したらAWSの管理画面より、このEBSのスナップショットを作成します。
EBSを選択し「Create SnapShot」を選択します。

スナップショット作成が完了したらいよいよAMIの登録作業です。

登録にはX.509証明書が必要です。
事前準備にて用意した[X.509の鍵] と [X.509の証明書]をインスタンスの任意の場所に保存します。
その後、以下のコマンドにてAMI登録を行います。
ec2-register -K [X.509の鍵] -C [X.509の証明書] –region [リージョン] -a [アーキテクチャ] -d [概要] -n [名前] -s [スナップショット名]
例えば、今回は東京リージョンで64bit版なので以下のようなコマンドとなります。
ec2-register -K pk-xxxxxxxxxxxxxxxxxxx.pem -C cert-xxxxxxxxxxxxxxxxx.pem –region ap-northeast-1 -a x86_64 -d “centos6 clean install ami 2012/xx/xx” -n centos6_clean_2012 -s snap-xxxxx

※2013/06/10 編集 (以下の方法の方が簡単なので編集しました)

スナップショット一覧から作成したスナップショットを選択し、右クリックメニューから
「Create Image from EBS Snapshot」を選択します。

出てくるウィンドウで以下の内容を編集します。

Architecture: x86_64
Kernel ID: aki-44992845

これでAMIが作成されます。

AMIの確認

AWSの管理画面から登録したAMIの存在を確認できると思います。
このAMIを右クリックしてインスタンスを作成してみましょう。
インスタンスが作成されログインができれば完成です。

今後のAMIの作成

クリーンなCentOS-AMIの作成が完了したら自分ごのみにカスタマイズする事となるでしょう。
その後、AMIを作成したい場合の方法ですが、すごく簡単です。

カスタマイズ済のインスタンスを右クリックで[Create Image (EBS AMI)]というメニューを選ぶ事でAMI登録する事が可能です。

終わり

以上で独自EBS-Backed AMIの作成方法は終了です。
サービスを開始して数年経ちましたが未だに複雑な作業だなぁ・・・と思ってしまいます。
コンソール機能やそこからISOイメージからOSインストールできる機能が今後できるととてもうれしいですね。

© SEEDS Co.,Ltd.