AmazonLinux2にPHP7.1を導入[cloudpack大阪ブログ]
AmazonLinux2にPHP7.1を導入する機会があったので備忘録です。
Amazon Linux2
AMIは下記を使用しました。
Amazon Linux 2 LTS Candidate AMI 2017.12.0 (HVM), SSD Volume Type - ami-c2680fa4
AmazonLinux2はデフォルトではamzn2-coreのリポジトリが設定されているため、
事前にepelとremiのリポジトリを入れておく
<epel>
<remi>
リポジトリを入れるとremiの7.1が格納されます。
[root@ip-xxx ~]# ll /etc/yum.repos.d/ | grep remi -rw-r--r-- 1 root root 456 Jan 16 07:06 remi-php54.repo -rw-r--r-- 1 root root 1314 Jan 16 07:06 remi-php70.repo -rw-r--r-- 1 root root 1314 Jan 16 07:06 remi-php71.repo -rw-r--r-- 1 root root 1314 Jan 16 07:06 remi-php72.repo -rw-r--r-- 1 root root 2605 Jan 16 07:06 remi.repo -rw-r--r-- 1 root root 750 Jan 16 07:06 remi-safe.repo
このままyum installしてもamzn2-coreのリポジトリが読み込まれてしまうので
一旦amzn2-core.repoを無効化してremi-php71.repoを有効化。
そしてphp7.1をインストールします。
これによりPHP7.1の導入ができました。
[root@ip-xxx ~]# php --version PHP 7.1.15 (cli) (built: Feb 28 2018 14:06:54) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
Ansibleを導入して使用してみました[cloudpack大阪ブログ]

参考資料
Ansibleとは
多数のサーバーや複数のクラウドインフラを統一的に制御できる構成管理ツール
→PuppetやChefもある
Ansibleインストール
サーバーの事をAnsibleに知らせる
・playbookディレクトリを作成
私は下記に作りました。
/etc/ansible/playbooks
・playbook配下にhostsファイルを作成
→インベントリファイル
AWS環境を使用したので下記内容にしました。
<エイリアス> ansible_ssh_host=<IPアドレス> ansible_ssh_port=22 ansible_ssh_user=<SSHユーザー名> ansible_ssh_private_key_file=<キーファイル格納場所>
実際に確認してみると下記のようになります。
<コマンド>

※動作が成功しなかった時は-vvvフラグを追加すると詳しくエラーが表示されます。
ansible.cfgによる簡略化
ansible.cfgでデフォルト値を設定する事でインベントリファイルやコマンドを簡略化できます。
例)
・下記場所にansible.cfgを作成
ファイル場所:/private/etc/ansible
内容
[defaults] hostfile = hosts remote_user = <ユーザー名> private_key_file = <ファイルキー格納場所> host_key_checking = False
・-i hostnameの引数を抜いてチェック

playbookを実行
playbookはネット上にアップされているymlを参考に動かしてみました。
ansible-playbook -i <ymlファイル>
まだ導入レベルなので理解度も初歩的な所ですが他のツールも使いながら学習していきます。
CloudFormationを使用してネットワーク部分の構築[cloudpack大阪ブログ]

自動デプロイのサービスとして以前Elastic Beanstalkを使用しましたが
今回CloudFormationを使用してネットワーク部分の構築をしましたので備忘録。
CloudFormationテンプレートの構造
テンプレートはJSONで記述
ネットワーク部分の構築
JSON記述について下記フォーマットを参考
<VPC>
"VPC": {
"Type": "AWS::EC2::VPC",
"Properties": {
"CidrBlock": "<IPアドレス>/16",
"InstanceTenancy": "default",
"EnableDnsSupport": "true",
"EnableDnsHostnames": "true",
"Tags": [
{
"Key": "Name",
"Value": "<VPC名>"
}
]
}
},
<サブネット>
"SubnetTrustAZa": {
"Type": "AWS::EC2::Subnet",
"Properties": {
"CidrBlock": "<IPアドレス>/24",
"AvailabilityZone": "ap-northeast-1a",
"VpcId": {
"Ref": "VPC"
},
"Tags": [
{
"Key": "Name",
"Value": "<サブネット名>"
}
]
}
},
<InternetGateway>
"InternetGateway": {
"Type": "AWS::EC2::InternetGateway",
"Properties": {
"Tags": [
{
"Key": "Name",
"Value": "<InternetGateway名>"
}
]
}
},
<DHCPオプションセット>
"DHCPOptions": {
"Type": "AWS::EC2::DHCPOptions",
"Properties": {
"DomainName": "ap-northeast-1.compute.internal",
"DomainNameServers": [
"AmazonProvidedDNS"
]
}
},
<NetworkAcl>
"NetworkAcl": {
"Type": "AWS::EC2::NetworkAcl",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
<RouteTable>
"RouteTable": {
"Type": "AWS::EC2::RouteTable",
"Properties": {
"VpcId": {
"Ref": "VPC"
}
}
},
S3のRedirection Rulesを使ってみる[cloudpack大阪ブログ]

ちょっとS3を最近さわっていないので忘れないように復習してた所、Redirection Rulesの設定を試してみたので設定方法の備忘録です。
今回は「foo/」にアクセスしたら「bar/」にリダイレクトするよう設定します。
前提条件
・S3よりBuketを作成しておく
・Webサイトのホスティングを有効にしておく
→インデックスドキュメントとエラードキュメントも設定
確認の流れ
まずはBuketよりプロパティを開いて静的ウェブサイトホスティングを選択

リダイレクトルールを編集するを選択してテキストエリアにルールを記載して保存する
<ルール内容>
<RoutingRule>
<Condition>
<KeyPrefixEquals>foo/</KeyPrefixEquals>
</Condition>
<Redirect>
<ReplaceKeyPrefixWith>bar/</ReplaceKeyPrefixWith>
</Redirect>
</RoutingRule>
</RoutingRules>

設定したら実際に試してみます。
curlコマンドにて「foo/」が「bar/」にリダイレクトされている事がわかります。

次に事前にエラー用のhtmlファイルも設定してましたが404エラーが発生した際のリダイレクト設定を行います。
→Buketに404用のhtmlファイルを追加しておきます
Redirection Rulesに下記を追加します。
<追加ルール>
<Condition>
<HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
</Condition>
<Redirect>
<ReplaceKeyWith>404.html</ReplaceKeyWith>
</Redirect>
</RoutingRule>
設定後にcurlコマンドで404エラーがリダイレクトされている事を確認します。
<変更前>

<変更後>

今回S3の環境を構築したのでDNS設定してCloudFrontと連携させてみようと思います。
Elastic Beanstalkを利用した構築[cloudpack大阪ブログ]
以前社内でElastic Beanstalkの話があったので実際に自分で試してみました。
イメージは下記の図になります。

事前にしておく事
・VPC環境を構築
→AZでA/CとPublic/Privateで4つ作成
・SGの作成
→RDS/EC2の分の作成
・WordPressをDLしておく
URL:https://ja.wordpress.org/
手順
1.マネジメントコンソール画面よりElastic Beanstalkを選択
2.新しいアプリケーションの作成を選択
3.アプリケーション情報は任意で入力
4.今回はWordPress環境の構築なのでWeb Serverを選択

5.環境タイプはWordPressなのでPHPにする
→今回はEC2一台の構成なので単一で構いません

6.事前に取得しておいたWordPressをアップロード

7.環境名/URLを入力して次へ選択

8.今回はRDSもVPCも作成するのでチェックを入れる

9.インスタンスの詳細情報を記載
10.RDSの詳細情報を記載
11.VPC設定を行う
→事前に作成したVPCを設定する事
12.後は確認画面を経て起動を選択すると完了
historyファイルの拡張方法について[cloudpack大阪ブログ]
過去のコマンド履歴が見れて便利なhistoryコマンドについて
ファイルの拡張方法を覚えたので記載しておきます。
→今回はAWSあまり関係ありません。。
<参考にさせて頂いたサイト>
http://mironal-memo.blogspot.jp/2012/07/linux-history.html
ファイル格納上限値を増やす
デフォルトは1000件ですが10000件に設定してみます。
まずは「.bashrc」を作成します。
→/home/<ユーザー名>/に入れました。
後は「.bashrc」に下記文言を入れる事で対応されます。
履歴に日時も表示させる
履歴は同じく「.bashrc」に下記文言を入れる事で対応されます。
対応させる事でhistoryコマンド入力すると日付も表示されます。
例)
すぐに反映する
すぐ反映するために下記コマンドを実行します。
便利な機能なのでこれから活用していこうと思います。
補足
home以下で実行しちゃうとアカウントに依存するので全体に反映させたいなら/etc/bashrcで反映させてください。
EC2 CloudwatchのAuto Recover設定方法[cloudpack大阪ブログ]

インスタンスが障害等で落ちた時に自動的に復旧してくれるAuto Recover設定についてです。
実行にするにあたり下記を参考にさせて頂きました。
手順は下記になります。
- 1.CloudWatchからAlarmsを洗濯してCreate Alarmを選択

2.EC2 MetricsよりPer-Instance Metricsを選択
3.該当するインスタンスよりStatusCheckFailed_System部分を選択
4.グラフ部分の設定より1分毎でMinimumを設定して画面右下のNextを選択

5.名前と説明は任意で、Whenever部分に対して下記はStatusCheckFailedが1上の時が1回でも出たらという設定です。
→一つでも失敗が出たら検知する設定です

6.Actionとして+EC2 Actionをで追加してRecover this instanceにチェックして復旧設定する

7.作成したら一覧に表示されます(現状はOKになっている)

正常に設定できていればインスタンス画面よりAlarm Statusで状況が見えます。

cloudpack大阪Blog



