ラベル aws の投稿を表示しています。 すべての投稿を表示
ラベル aws の投稿を表示しています。 すべての投稿を表示

2016年12月20日火曜日

クラウドN (cloudn)でのサーバ構築


クラウドといえばAWSしか使ったことがないので、主にAWSと比較しながら備忘録的にメモ。
FLATタイプでCentOS 7の場合。


AWSと同じようなところ

  • セキュリティグループの受信規則は、記述されていないものはDENYなので(デフォルトは設定なし=全て拒否)、許可するものを設定する。
  • セキュリティグループの送信規則は逆にデフォルトALLOWなので、禁止したい場合のみ設定する。
  • サーバ(Compute)を起動すると、サーバに対してグローバルIPが与えられる。
  • サーバにはデフォルトでPython 2.7が入っていた。


AWSと違うところ
(良いところ)

  • データ転送量についての課金が無い。
  • サービスが少ないので管理コンソールがシンプル。
  • 接続元IPアドレスによる管理コンソールのアクセス制限が簡単。
  • サーバ起動時に指定したhost名がサーバ内にも適用される。
  • 一番小さいインスタンスでもデフォルトでswapがある。
(悪いところ)
  • サーバ停止中でも課金される。(稼働中よりは安いが。)
  • サーバ削除のプロテクト設定が無いのがちょっと怖い。
  • 管理コンソール等のタイムゾーンがUTC。
  • 管理コンソールで意味不明な部分がある。(OpenStackの仕様をしらべればいいのか...?)
  • サーバ起動後にセキュリティグループを変更できない。
  • サーバはデフォルトでrootのSSHログインが可能。鍵ファイルではなくパスワード認証。
    ※パスワードはサーバ登録時に生成され、管理コンソール上で1度だけ表示される。管理コンソールからリセットもできる。リセットするとsshdの設定(SSHのrootログイン禁止、パスワード認証禁止、鍵ファイルによる認証の許可など)も初期化される。
  • サーバのテンプレート(AWSでいうところのAMI)を作る前に、手動でサーバを停止しないといけない。
(その他)
  • サーバのSELinuxはデフォルトで有効。
  • SMTPはpostfixが入っている。



本番用テンプレートを作る時にまずやることのメモ
CentOS 7のコマンドがCentOS 6から色々変わってるので慣れないと...。

  • タイムゾーンの設定(/root/tzconfigurator.shという対話形式の設定ツールが用意されているが、itamaeと相性が悪い?)
  • yum update
  • Linuxユーザーの追加(SSH用公開鍵のセットも)
  • rootのSSHログイン禁止
  • SSHのパスワード認証の禁止と、鍵認証の許可
  • メール送信先の変更(/etc/aliasesの編集)

以下は必要に応じて




参考



2016年11月19日土曜日

chalice お試しメモ

chalice (Python Serverless Microframework for AWS)をAmazon Linuxに入れてHello Worldしたのでメモ。


1. aws configure

Amazon Linuxならaws(AWS CLI)は最初からインストールされている。
configureで認証情報を登録する。

参考 【AWS】CLIの初期設定について(認証情報とコマンド補完) - TASK NOTES


2. chalice

参考 GitHub - awslabs/chalice: Python Serverless Microframework for AWS

必要に応じてrootで作業する。


マネジメントコンソールから確認したところ、下記が登録されていた。

  • API Gateway
  • CloudWatch(のメトリックス)
  • IAM(のロール)
  • Lambda(大きすぎてマネジメントコンソール上では参照・編集できない)

また、実行後にCloudWatchにログが登録された。


アクセス制限はAPI GatewayはAPIキー認証しかできないので、前にCloudFront+AWS WAFを置くか、アプリケーション側でやるか。(ちょっとめんどくさい。EC2くらい手軽にできるとよいのだが。)

不明点

  • API Gatewayのステージを指定してデプロイする方法(設定ファイルを書き換えるしか無い?deployコマンドの引数で指定したいが…)
  • LambdaのVersionかAliasを指定する方法。これができないと、API Gatewayでステージを分けても、みんなLATESTのLambdaに行ってしまってステージを分けた意味がない…


2016年7月16日土曜日

Amazon RDS Auroraの参考サイトメモ

参考記事
Amazon Aurora/MariaDB/MySQLの違いを整理してみる #reinvent | Developers.IO
エンタープライズワークロードにおけるAmazon Auroraの活用
Amazon Auroraについての簡単なメモ - Qiita
11/10 Amazon RDS for Aurora 東京ローンチ記念セミナーに行ってきました - 駆け出しアクアテラリストのIT奮闘記
ちょっと待って!Auroraを使う時にMulti-AZが本当に必要ですか? | Developers.IO


問題点
Amazon Auroraへの移行 - inFablic
AWS RDSのAuroraをパブリックから繋いだ時のパフォーマンス - イフブロ


メンテナンスウィンドウ
Amazon RDS のメンテナンス期間 - Amazon Relational Database Service


可用性
Amazon Web Services ブログ: 【AWS発表】Amazon Auroraをご利用頂けるようになりました!
Amazon Aurora東京ローンチ記念セミナー参加レポート - 其未来
Auroraの可用性は99.99% → 1年間で52.56分止まる計算になる
SLAは99.95%


料金
料金 - Amazon RDS | AWS
2016年現在、オンデマンドインスタンスで、$0.35/H~(最安のr3.large)→ ストレージやI/Oも含めて3万円弱/月~くらいか
Multi-AZにするなら倍だから6万円弱/月か

Itamaeセットアップメモ

EC2のAmazon LinuxにItamaeのサーバを構築し、リモートサーバもEC2のAmazon Linuxの場合


セットアップ
参考:Itamae on AWS - Itamae の EC2 へのインストールとレシピ適用 - - Qiita

sudo gem install itamae
sudo yum install ruby-devel gcc-c++
sudo gem install io-console


ローカルで実行する場合
sudo /usr/local/bin/itamae local path/to/recipe.rb
yamlのnodeを読み込む場合
sudo /usr/local/bin/itamae local --node-yaml path/to/node.yaml path/to/recipe.rb


リモートサーバに実行する場合
EC2へのSSHログインで使う秘密鍵をItamaeサーバ上にコピー(取り扱い注意?)
例:/home/ec2-user/.ssh/your-pair.pem
itamae ssh -h 対象のIP -i path/to/your-pair.pem path/to/recipe.rb

Ansibleや Itamaeで LAMP環境を作る

参考サイトのメモ。
Itamaeの方がいいかな。


Ansible

Ansibleのインストールと、ごく簡単なplaybook
VagrantとAnsibleでCentOSの環境を用意してみる - yk5656 diary

LAMP環境を作成
AnsibleでとりあえずのLAMP環境してみる - yk5656 diary

PHPをインストール
Ansible でインストール (php 5.6) - Qiita



Itamae

Itamaeのインストール、ごく簡単なレシピ、リモートサーバへの適用
Itamae on AWS - Itamae の EC2 へのインストールとレシピ適用 - - Qiita

レシピの書き方など
Chef脱落者が、Itamaeで快適インフラ生活する話 - Qiita
itamae 入門 - Qiita
Itamaeチートシート - Qiita
vagrantとitamaeによるLAMP環境構築 - Qiita
EC2 のインスタンスを Itamae でプロビジョニングした | mizoguche.info

設定値をJSONまたはYAMLに切り出す
第3回 ノード属性で汎用的なレシピを書く:Itamaeが構成管理を仕込みます! ~新進気鋭の国産・構成管理ツール~|gihyo.jp … 技術評論社

公式ドキュメント(英語。詳細は載ってない)
Home · itamae-kitchen/itamae Wiki · GitHub

公式ドキュメントが想像よりそっけないので、詳細は他のブログ等やQiitaで調べながら...。まあシェルコマンドが使えるから汚い書き方でいいならどうにでもなるけど。

2016年5月21日土曜日

certbot (Let's Encrypt)を Amazon Linuxにインストール


以前一度挫折した(古いAmazon Linuxをアップデートして使っているためだと思われる)が、certbotに改名後に試してみたら、できた。


前提

  • gitはインストール済み
  • WebサーバはApache



手順

  1. sudo easy_install pip
  2. sudo pip install --upgrade pip
  3. sudo /usr/local/bin/pip install --upgrade virtualenv
  4. (作業用ディレクトリで)
    git clone https://github.com/certbot/certbot
  5. cd certbot
  6. ./certbot-auto certonly --webroot -w /var/www/html -d ドメイン名 --agree-tos -m メールアドレス --debug
  7. /etc/httpd/conf.d/ssl.confの下記箇所を変更する。(Apache2.4.8より前のバージョン場合は微妙に違うので参考サイト参照。)
    SSLCertificateFile /etc/letsencrypt/live/ドメイン名/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/ドメイン名/privkey.pem
  8. httpdを再起動


証明書の自動更新
証明書の期限は90日なので、cronで定期更新させる。cronがメールを飛ばすように設定してあれば結果がメールで来る。

(例:月に1回更新する場合。日時は月初にすると混雑しそうなので、適当にずらした方がよいかも。)
45 3 12 * * ./certbot/certbot-auto renew && sudo service httpd reload

(2016/6/25 追記)
--debugも付けた方がよいかも?参考→Let's Encryptの cronによる実行が動かなくなった時の対策
(追記終わり)

期限まで30日以上ある場合は更新されない。それでも更新したい場合は--force-renewオプションを付ける。
上記例を試した時はまだ更新されなかったので、本当にこれでよいかはその日が来てから確認する。(--debug無しとか大丈夫か?タイミングによっては、月イチだと期限切れになるケースがあるかも?)


備考的な

  • Aapcheは停止しなくても大丈夫。(webrootオプションを使う場合はいいらしい。)
  • 証明書生成時にポート443は開いてなくても大丈夫。
  • /var/www/htmlに.well-knownディレクトリが残る。消してもいいのかな?



さよなら自己署名!さよならオレオレ証明書!


参考



2016年1月9日土曜日

EC2の MySQLを S3にバックアップする方法(世代管理付き)


S3への送信はaws-cliが良さそう。
参考:aws-cli - AWS CLIでS3を操作する - Qiita


aws-cliはAmazon Linuxなら最初から入っているが、手元のインスタンスはconfigure等をするにはバージョンアップが必要だった。
yumでもバージョンアップできるが、今回は諸事情により依存関係のある諸々をそっとしておきたかったので、下記を参考にyumを使わずにaws-cliをバージョンアップ。

参考:AWSCLIで運用検討中の人必見! AWSCLIを使用したS3へのファイルコピー | クラウド工房 Powered by Amazon Web Services

sudo easy_install pip
sudo pip install awscli -U


IAMでS3のみに権限を絞り込んだユーザーを作り、その認証情報をconfigure。(もう少し権限を絞っても良いかも。)

aws configure

AWS Access Key ID [None]: (アクセスキーを入力)
AWS Secret Access Key [None]: (シークレットアクセスキーを入力)
Default region name [None]:
Default output format [None]:


世代管理はS3の機能であるバージョニングとライフサイクルを使う。
S3でバケットを作成し、バージョニングを有効化。
ライフサイクルでルールを追加。(例「以前のバージョン」を30日後に削除)


後は適当にダンプとS3へのコピーのスクリプトを作ってcronに登録する。
分かりやすいようにディレクトリを作成し、そこにスクリプトを作った。

バックアップ用スクリプト作成。
vi backup.sh

#!/bin/sh
echo "START " `date +'%Y/%m/%d %H:%M:%S'`
MYSQL_PWD='MySQLのパスワード' mysqldump -u MySQLのユーザー 対象DB > data.dump
aws s3 cp data.dump s3://バケット名/
echo "E N D " `date +'%Y/%m/%d %H:%M:%S'
(パスワード直書きにしたが、きちんとやるならMySQLのパスワードは隠したい。)

スクリプトのファイルに実行権限を付ける。
chmod 700 backup.sh

cronに登録。
crontab -e

0 1 * * * cd /スクリプトのディレクトリ; ./backup.sh >> history.log


aws-cliを使うと、AWSのサービス間の通信はSSL(TLS?)で暗号化されるようだ。
参考
aws — AWS CLI 1.9.17 Command Reference
By default, the AWS CLI uses SSL when communicating with AWS services.

Amazon Web Service aws cliはデフォルトで暗号化通信されるのか? - なぜか数学者にはワイン好きが多い



S3を使わずにサーバ上で世代管理するだけなら、下記が一番分かりやすかった。
mysqldumpをcronで1日1回取得し、バックアップ用ファイルを保存する - サイト制作の豆知識

2015年3月8日日曜日

Linuxのセキュリティ対策


  • 基本
  • ファイアウォール
    • firewalld(RHEL7/CnetOS7以降)
    • iptalbes
    • Amazon EC2の場合は(EC2の)Security Groupsによる簡易ファイアウォールでも
  • WAF
    • ModSecurity
  • ウィルス対策
    • Clam AntiVirus
  • Rootkit検査
    • rkhunter
    • chkrootkit
  • 改鼠検知
    • AIDE
    • Tripwire
    • OSSEC (2015/4/4追記)
  • ログ報告
    • Logwatch

2012年10月22日月曜日

小さな会社のITインフラを低予算で揃える方法を妄想してみた

もし小さな会社のITインフラを最低予算で用意するなら...

  • メール、カレンダー共有、ファイル共有、ドキュメント共有 → Google Apps
    • ファイル共有は普通に考えたらファイルサーバを立てるんだけど、思い切ってクラウドで。Dropboxと迷うところこだけど、どうせGoogle Appsを使うなら挑戦的にGoogle Driveで。検索に強そうでしょ?(漢ならS3直で!というのも香しいが...)
    • ドキュメント共有はGoogle Docsを使い社内用のメモ程度のものを想定。社外とのやりとりは、結局ExcelやWordが中心になるだろうから。Goolgeスプレッドシートが使い物になればなあ...。
  • Webサイト → Blogger
    • 静的ページを組み合わせて「ホームページ」風にする。
    • ブログ部分は新着情報的に使う。
    • 会社所在地を載せるならGoogle Maps埋め込みで。
  • お問合せフォーム → Google App Engineでチャチャッと作る
    • 入力されたらメールを飛ばす。
    • Google App Engineはhttpsで使えるのが便利。
    • 本当に簡単に済ませるなら、お問合せ用メールアドレス載せとくだけという手もある。
  • ドメイン
    • Webサイトを www.xxxxx.com にして、 お問合せフォームを ssl.xxxxx.comにする感じかな。あるいはWebサイトを xxxxx.com にして、お問合せフォームを q.xxxxx.com とか?(人力検索っぽい!)
  • タスク管理 → Backlog
    • Redmineの方がいろいろカスタマイズはできるけど、非開発者にフレンドリーなBacklogが無難かな。
    • Backlogいつの間にかGitに対応してる!
    • Backlogにもファイル共有あるんだ...有料版使うならこっちのファイル共有を使うという手もあるか。
  • 何かでサーバが必要になったら → Amazon EC2
    • 定期的にS3にバックアップをとる。
 これなら社内にサーバが要らない。出先でも普通に仕事が出来る。外出が多いなら、いっそ事務所には固定回線無しで、イーモバイルのみというのもいいかもね。

他にも思いついたら足してく(かも)。

2011年3月18日金曜日

AWS CloudFormationで PHP Hello World Applicationを作成してみた

AWS(Amazon Web Services)のCloudFormationの「PHP Hello World Application」に関する情報があまりないので試してみた。


まずはAWS Management Consoleから「PHP Hello World Application + SSH enabled」のstackを作成。
場所はAsia/Pacific 東京リージョンを選択できた。
インスタンスタイプはMicroインスタンス、OperatorEmailには自分のメールアドレスを記入した。


しばらくすると、こんなのが作成された。

  • S3
    • 空のバケットが作成された(バックアップ用?)
  • EC2
    • Root Device Typeがebsのインスタンスが1つ作成された
    • EBSのCapacityは8GiB
    • Security Groupが1つ作成された
      • SSHとHTTP(ポート番号は8888)のポートで、ともにIPアドレス制限無し
    • Load Balancerが起動した
      • 80番ポートを待ち受けてインスタンスの8888番ポートに向ける
    • Elastic IPは作成されなかった
  • CloudWatch
    • Alarmが3つ作成された
      • RequestLatencyAlarmHigh
      • CPUAlarmHigh
      • TooManyUnhealthyHostsAlarm
    • 閾値に達したら登録したメールアドレスにメールで知らせてくれるようだ
  • CloudFormation
    • stackが1つ作成された(そりゃそうだ)
  • RDS
    • DB Instanceが1つ作成された
      • DB Engine Versionは5.1.50
      • DB Instance Classはdb.m1.small
      • DB Storageは5GiB
      • Backup Windowは15:00~15:30(日本時間?)
      • Maintenance Windowは日曜14:00~14:30(これも日本時間?)
    • DB Security Groupが1つ作成された
      • 上記のEC2 Security Groupが適用されている
    • DB Parameter Groupのcharacter_set関連は「engine-default」になっているが、UTF-8使えるのかな?
  • SNS
    • CloudWatchのメール通知用のTopicが1つ作成された


EC2のLoadBalancerのドメインにHTTPでアクセスすると、Wellcomeメッセージとともにphpinfoが表示された。
phpinfoによるとバージョンは下記の通り。
  • Apache : 2.2.16
  • PHP : 5.3.3

SSHでアクセス(SSHのログインユーザーはrootでなく"ec2-user"なので注意。"ec2-user"はsudoができる)してみると、/var/www/html の中には index.php しかなかった。
ユーザー"ec2-user"のviはPHPのソースがハイライトされて見やすい。(少し目がチカチカするが。)

PHP拡張については主なものは入っているが、mbstringが入っていない。
yumで入れたら普通にインストールできた。
sudo yum install php-mbstring

mbstringを有効にするためにApacheを再起動。
すると、アクセスできなくなった。EC2のLoadBalancerからインスタンスが外れている。
SNSからのアラートメールもいくつも送られてきてる。

調べてみると、httpd.confでポート番号が80になっていた
8888に変更して再起動。

これでアクセスできるようになった。mbstringも使えるようになった。


使い終わったら、AWS Management ConsoleでCloudFormationのstackを削除。
するとCloudFormationが作った一連のものをきれいに削除してくれた。
例外はS3で、S3だけはバケットが残っていた。


あとこれは今回の調査に直接関係ないが、AWS Management ConsoleのS3とEC2が重くなった気がする。(この前の改善の影響?)


結論
ささっとPHP実行環境を作りたいなら、これもありかもしれないと思った。
RDSを使いたいかどうかは状況によるけど、CloudWatchとかSNSの設定が楽なのは便利そう。

2011年3月7日月曜日

Amazon EC2 東京リージョンと他のリージョンの価格比較


AWSの東京データセンターが開業したので、主な価格を他のリージョンと比較してみる。


US West
Asia Pacific
シンガポール
Asia Pacific
東京
EC2 Micro$0.025/時$0.025/時$0.027/時
EC2 Small$0.095/時$0.095/時$0.10/時
EC2 Medium$0.19/時$0.19/時$0.20/時
EBS$0.11/GB/月$0.11/GB/月$0.12/GB/月
S3(1TB以下)$0.154/GB/月$0.140/GB/月$0.150/GB/月


EC2は5%くらい高め、逆にS3はUS Westより安い。

速度(レイテンシ)は間違いなく東京が速いみたい。(参考:Amazon Web Servicesが日本に上陸!というわけで早速レイテンシやスループットを測ってみた - RX-7乗りの適当な日々


参考:AWSが日本データセンターを運用開始、責任者に聞いた - @IT

ブログ アーカイブ

tags