CodeBuildのbuildspec.ymlを別の名前にしたいときの手順

TL;DR

CodeBuildを使っていると、ビルドの成果物が違うからビルドスペックのファイル(buildspec.ymlというもの)の単位で成果物を分けたいということがあります。調べてみると、ドキュメントに1にやり方が載っていたのでやってみました。方向性としては、AWS CLIで変更操作をする手順です。2

(2017-10-13 22:00 追記。 今さっき見てみたら、Consoleでファイル名を指定できるようになっていました。ちょろっと直すならConsoleでいいですね。)

概要

nantoka-buildというプロジェクトのビルドスペックのファイルをnantoka-kantoka-buildspec.ymlに変えたいとします。windowsの例ですが、mac でも linuxでも概ね同じでしょう。

プロジェクトの名前を確認する

Consoleから確認することもできますが、CLIと同じものが見えているか確認する意味も込めてやってみましょう。

>aws codebuild list-projects
{
    "projects": [
        "nantoka-build",
        "kantoka-build-project",
        "test-test-project"
    ]
}

>

各環境とかリージョンとかで色々あると思いますが、Console 
https://ap-northeast-1.console.aws.amazon.com/codebuild/home?region=ap-northeast-1#/projects
で、見えるプロジェクトとおなじビルドプロジェクトが見えていればOKです。nantoka-build以外のプロジェクトも、存在するなら見えていることでしょう。

プロジェクト名を指定して、プロジェクト構造のJSONファイルを取得する

更新の操作はプロジェクト構造のJSONファイルをアップロードする形になります。アップロードするファイルを作るため、現状のファイルをダウンロードします。

>aws codebuild batch-get-projects --names nantoka-build
{
    "projectsNotFound": [],
    "projects": [
        {
            "name": "nantoka-build",
            "serviceRole": "arn:aws:iam::1234123412341234:role/service-role/nantokarole",
            "tags": [],
            "artifacts": {
                "packaging": "NONE",
                "type": "CODEPIPELINE",
                "name": "nantoka-artifact"
            },
            "lastModified": 1512341234.783,
            "timeoutInMinutes": 60,
            "created": 1512341234.68,
            "environment": {
                "computeType": "BUILD_GENERAL1_SMALL",
                "privilegedMode": false,
                "image": "aws/codebuild/java:openjdk-8",
                "type": "LINUX_CONTAINER",
                "environmentVariables": []
            },
            "source": {
                "type": "CODEPIPELINE"
            },
            "encryptionKey": "arn:aws:kms:ap-northeast-1:1234123412341234:alias/aws/s3",
            "arn": "arn:aws:codebuild:ap-northeast-1:1234123412341234:project/nantokanantoka"
        }
    ]
}

>

(arnなどは内容を適当にいじっています。表示される項目はあなたのプロジェクトの内容と同じはずです。)

プロジェクト構造のJSONファイルを

コマンドプロンプトに主力されたJSONをファイルに落として修正を入れます。

  • JSONのルートの"projects"の配下を取り出す。
  • "buildspec": "nantoka-kantoka-buildspec.yml"という1行を入れる。JSONなのでカンマ忘れずに。
  • "lastModified" "created" "arn" は消す。JSONの構造が違うというエラーになるので。無くても多分実害ないと想像する次第。本当は正しい書き方あると思いますが未確認です。
update.buildproject.json
{
    "name": "nantoka-build",
    "serviceRole": "arn:aws:iam::1234123412341234:role/service-role/nantokarole",
    "tags": [],
    "artifacts": {
        "packaging": "NONE",
        "type": "CODEPIPELINE",
        "name": "nantoka-artifact"
    },
    "timeoutInMinutes": 60,
    "environment": {
        "computeType": "BUILD_GENERAL1_SMALL",
        "privilegedMode": false,
        "image": "aws/codebuild/java:openjdk-8",
        "type": "LINUX_CONTAINER",
        "environmentVariables": []
    },
    "source": {
        "type": "CODEPIPELINE",
        "buildspec": "nantoka-kantoka-buildspec.yml"
    },
    "encryptionKey": "arn:aws:kms:ap-northeast-1:1234123412341234:alias/aws/s3"
}

修正をアップロード

update.buildproject.jsonをカレントディレクトリに置いて、下記コマンドを実行する。

>aws codebuild update-project --cli-input-json file://update.buildproject.json
{
    "project": {
        "name": "nantoka-build",
        "serviceRole": "arn:aws:iam::1234123412341234:role/service-role/nantokarole",
        "tags": [],
        "artifacts": {
            "packaging": "NONE",
            "type": "CODEPIPELINE",
            "name": "nantoka-artifact"
        },
        "timeoutInMinutes": 60,
        "environment": {
            "computeType": "BUILD_GENERAL1_SMALL",
            "privilegedMode": false,
            "image": "aws/codebuild/java:openjdk-8",
            "type": "LINUX_CONTAINER",
            "environmentVariables": []
        },
        "source": {
            "type": "CODEPIPELINE",
            "buildspec": "nantoka-kantoka-buildspec.yml"
        },
        "encryptionKey": "arn:aws:kms:ap-northeast-1:1234123412341234:alias/aws/s3"
    }
}

>

Consoleで確認する。

Consoleからプロジェクトを選択し、プロジェクト詳細 -> ビルド仕様の表示 とクリックして進むと、nantoka-kantoka-buildspec.yml と表示されます。


  1. http://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html#build-spec-ref-name-storage 今のところ日本語にはなってないようです。 

  2. ぶっちゃけた話、Consoleがすぐにでも対応しそうな気もしますが、今時点での手順を残します。 

続きを読む

AWSでServerlessの環境をCIするための選択肢を調べたメモ

利用するサービスはAWSに限定するとした場合に開発・テスト・デプロイを継続するための選択肢をいくつか調べてみました。

開発したいものは、「API Gateway – Lambda – DynamoDB」で構成されるWebサービスとします。

正直なところ、対象像を少し絞らないと選択肢が多すぎて好みの問題になりそうなので・・・

注意

調査用のメモです。

実際に全ての選択肢で開発をしてみたわけではなく、入門記事やドキュメントを少しみた程度で判断しています。

そのため正確性に欠ける内容となっている可能性が高いことをご了承ください。

共通点

開発ツールで対応していない部分についてのデプロイについては、AWS CLIで対応していくことになるでしょう。

LocalStack

モックサービスの対応数にまず驚いた。

https://github.com/localstack/localstack

LocalStack はローカルでAWSのサービスのモックを動かしてしまうというツールです。
DockerコンテナでAWS各種サービスを一気に立ち上げることができるので、ローカル環境で開発を完結させることが出来ます。

これ自体にはAWSを管理する機能はなく、Lambdaをローカル環境で開発してテストするときに、ローカルで同時にAPI Gateway + DynamoDBを動かしたいという場合に必要となりそうです。
DynamoDB自身はAmazonからDynamoDB Localが提供されているので、どちらを使うかは検証が必要でしょう。

起動コマンドも簡単で、一発で全て立ち上げることが出来ます。

docker-compose up

macの場合は、$TMPDIRにシンボリックリンクがある場合、少しコマンドを変える必要があるようです。

TMPDIR=/private$TMPDIR docker-compose up

DynamoDB Local

ローカル開発用のDynamoDB。
ほとんどのLambda開発ツールがAPI Gatewayもサポートしていることから、DynamoDBを接続するローカル環境ではLocalStackよりはこちらを使用することになるのではないかと。公式提供でもあるし。

ダウンロードとインストールガイドはこちら

aws-sam-local

SAM は Serverless Application Modelのことで、aws-sam-localはAmazon公式がサポートしているローカル開発環境です。今はまだbetaですが、近いうちに良くなりそうです。

https://github.com/awslabs/aws-sam-local

AWS Blogで利用例が紹介されていて、DynamoDB Localを使う場合についても少し触れられています。
https://aws.amazon.com/jp/blogs/news/new-aws-sam-local-beta-build-and-test-serverless-applications-locally/

作成したLambda FunctionをローカルDockerコンテナで実行したり、現時点ではPythonとNode.jsはデバッグ出来るようです。(自分で試したところ、上手くいかなかった)

また、Lambda関数を単純に実行するだけではなく、ローカルのAPI Gatewayを通して実行を確認できます。

PostManで簡単にAPIの動作検証が行えたり、実際のHTTPアクセスの形でLambda関数の検証がローカルで行えます。
また、実行時間やメモリ消費量が表示されるため、AWSにデプロイする前に関数の効率化が出来ます。

Serverless Framework

現状で一番正解に近いと思います。

https://github.com/serverless/serverless

こちらのQitta記事こっちのQiita記事が参考になりそうです。
DynamoDB Localと連携するためのプラグインが存在し、serverless.ymlファイルにAWS上での構成を記載していき、そのままAWSにデプロイ出来るようです。

Apex

Go言語でLambdaが書ける!!!

純粋にLambdaの開発だけで見ればとても良さそうです。
ただし、ローカル実行はサポートしておらず、AWSリソースの操作もLambdaに限定されています。
その辺りは、Terraformで補う考えのようです。

公式

https://github.com/apex/apex

chalice

Python用のマイクロサービスフレームワークです。

https://github.com/aws/chalice

次の様なコードで、APIを定義できます。

chalice
@app.route('/resource/{value}', methods=['PUT'])
def put_test(value):
    return {"value": value}

デプロイでAPI Gateway, Lambdaに反映されるため、コードの見通しが良くなりそうです。
IAM Rolesなどは自動生成される様なので、とにかく簡単にコードを書いて、すぐデプロイということが出来そうです。

インストールからコード記述、デプロイまでの操作がHelloworldならこんなに簡単に出来るようです。

$ pip install chalice
$ chalice new-project helloworld && cd helloworld
$ cat app.py

from chalice import Chalice

app = Chalice(app_name="helloworld")

@app.route("/")
def index():
    return {"hello": "world"}

$ chalice deploy
...
https://endpoint/dev

$ curl https://endpoint/api
{"hello": "world"}

Zappa

こちらも、とにかく簡単にPythonで作成した関数をAWSにデプロイ出来ることがウリのようです。

https://github.com/Miserlou/Zappa

gifアニメーションで実演が付いています。(README.mdから引用しました)
README.md

Zappa Demo Gif

REST APIを作成する以外にも、AWS Eventsに対応するものや、Asynchronous Task Executionといって、別のLamdba関数を非同期に呼び出すことが出来る機能を持っているようです。
というか、chaliceに比べると非常に多彩。

また、ZappaはWSGI(Web Server Gateway Interface)をサポートしているので、他のアプリケーションサーバーにデプロイすることも可能です。

chalice vs Zappa

こちらに比較記事がありました。

続きを読む

AWS CodeCommit の特定リポジトリへの専用ユーザーを作成してみる

0.はじめに

AWS CodeCommit の特定のリポジトリに対して、
Git の基本操作だけを行えるユーザーを作成してみました。

権限設定の主な条件は、以下。

  • Git の基本的なコマンドを実行出来る。
  • リポジトリの作成や削除は行えない。
  • ブランチの作成や削除は行えない。

1.AWS IAM ポリシーの作成

  1. AWS IAM のコンソールへアクセス。

  2. ダッシュボードの「ポリシーの作成」ボタンを押下。
    • FireShot Capture 189 - IAM Management Console_ - https___console.aws.amazon.com_iam_home.png

  3. 「Policy Generator」の「選択」ボタンを押下。
    • FireShot Capture 190 - IAM Management Console_ - https___console.aws.amazon.com_iam_home.png

  4. 以下の手順で項目を入力し、「次のステップ」ボタンを押下。
    • 効果 : 許可
    • AWS サービス : AWS CodeCommit
    • アクション :
      • codecommit:ListRepositories
    • Amazon リソースネーム(ARN) : *
    • ※「ステートメントを追加」ボタンを押下
    • 効果 : 許可
    • AWS サービス : AWS CodeCommit
    • アクション :
      • codecommit:BatchGetRepositories
      • codecommit:GetBlob
      • codecommit:GetBranch
      • codecommit:GetCommit
      • codecommit:GetDifferences
      • codecommit:GetObjectIdentifier
      • codecommit:GetReferences
      • codecommit:GetRepository
      • codecommit:GetRepositoryTriggers
      • codecommit:GetTree
      • codecommit:GitPull
      • codecommit:GitPush
      • codecommit:ListBranches
      • codecommit:ListRepositories
    • Amazon リソースネーム(ARN) : ※許可するリポジトリの ARN
      • arn:aws:codecommit:ap-northeast-1:xxxxxxxxxxxx:XXXXXXXX
    • ※「ステートメントを追加」ボタンを押下
    • FireShot Capture 192 - IAM Management Console_ - https___console.aws.amazon.com_iam_home.png

  5. 以下の項目を入力し、「ポリシーの作成」ボタンを押下。

    • ポリシー名 : GSCodeCommit_Sample_Developers_Access ※ 任意
    • 説明 : ※ 任意
    • ポリシードキュメント : ※ 以下の様な json データが表示されているはずです。
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "Stmt*************",
                "Effect": "Allow",
                "Action": [
                    "codecommit:ListRepositories"
                ],
                "Resource": [
                    "*"
                ]
            },
            {
                "Sid": "Stmt*************",
                "Effect": "Allow",
                "Action": [
                    "codecommit:BatchGetRepositories",
                    "codecommit:GetBlob",
                    "codecommit:GetBranch",
                    "codecommit:GetCommit",
                    "codecommit:GetDifferences",
                    "codecommit:GetObjectIdentifier",
                    "codecommit:GetReferences",
                    "codecommit:GetRepository",
                    "codecommit:GetRepositoryTriggers",
                    "codecommit:GetTree",
                    "codecommit:GitPull",
                    "codecommit:GitPush",
                    "codecommit:ListBranches",
                    "codecommit:ListRepositories"
                ],
                "Resource": [
                    "arn:aws:codecommit:ap-northeast-1:xxxxxxxxxxxx:XXXXXXXX"
                ]
            }
        ]
    }
    
    • FireShot Capture 194 - IAM Management Console_ - https___console.aws.amazon.com_iam_home.png

  6. IAM ポリシーの一覧で、作成されたポリシーを確認します。

    • FireShot Capture 195 - IAM Management Console_ - https___console.aws.amazon.com_iam_home.png

2.AWS IAM ユーザーへのポリシーの適用

  1. AWS IAM のコンソールへアクセス。

  2. 「ユーザーを追加」ボタンを押下。
    • FireShot Capture 196 - IAM Management Console_ - https___console.aws.amazon.com_iam_home.png

  3. 以下の項目を入力し、「次のステップ:アクセス権限」ボタンを押下。
    • ユーザー名 : ※ 任意
    • アクセスの種類 :
      • プログラムによるアクセス : ☑︎
      • AWS マネジメントコンソールへのアクセス : □
    • FireShot Capture 197 - IAM Management Console_ - https___console.aws.amazon.com_iam.png

  4. 「既存のポリシーを直接アタッチ」を選択後、作成した IAM ポリシーを選択し、「次のステップ:確認」ボタンを押下する。
    • FireShot Capture 199 - IAM Management Console_ - https___console.aws.amazon.com_iam.png

  5. 設定内容を確認し、「ユーザーの作成」ボタンを押下する。
    • FireShot Capture 202 - IAM Management Console_ - https___console.aws.amazon.com_iam.png

  6. 作成したユーザーの内容(アクセスキー ID、シークレットアクセスキー)を確認し、保存しておきます。
    • FireShot Capture 203 - IAM Management Console_ - https___console.aws.amazon.com_iam.png

3.AWS CodeCommit の HTTPS Git 認証情報のの作成

  1. 作成したユーザーの概要画面を開き、「認証情報」タブの「AWS CodeCommit の HTTPS Git 認証情報」の「生成」ボタンを押下。

    • FireShot Capture 063 - IAM Management Con_ - https___console.aws.amazon.com_iam_home#_users_y.uekama.png

  2. 「生成された Git 認証情報」ダイアログが表示されるので、「証明書のダウンロード」ボタンを押下し、「リポジトリのクローンを作成するステップ」の 1 の記載の通りに、コンピュータ上の安全な場所に保存。
    • FireShot Capture 067 - IAM Management Con_ - https___console.aws.amazon.com_iam_home#_users_y.uekama.png

  3. あとは、ターミナルを開き git clone などを行います。
    • git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/********

      • ※ユーザー名とパスワードを求められたら、保存した Git 認証情報を対応するフィールドに入力。

99.ハマりポイント

  • 特にありませんが、今回の IAM ポリシーには、AWS CodeCommit 全体のリソースへの権限と特定のリソースへの権限と設定しましたが、その方が後々便利かなと思いそうしました。不要であれば、特定のリポジトリへの権限だけでいいと思います。

  • あと、ユーザーに直接 IAM ポリシーをアタッチしていますが、グループにアタッチして、そのグループに所属させるというやり方の方が便利かもしれません。

XX.まとめ

外部の方とのコードのやり取りをどうしようかな、と思っていて、
今回、AWS CodeCommit を使ってみました。

CodeCommit も Git もあまり詳しくないので、
もしかしたら、権限設定に誤りがあるかもしれません…。

その際は、
遠慮なくコメント下さい。

よろしくお願いします。

こちら、
以前投稿した、AWS CodeCommit 絡みのものです。
ご参考までに。

続きを読む

CloudFrontキャッシュを削除するシェルスクリプトを書いてみた。

AWS CLI を使えば、 AWS Console へアクセスすることなく
CloudFrontキャッシュの削除も行えます。

削除対象が多い場合はその対象を記したjsonファイルを用意して、
AWS CLI からそのjsonファイルを利用して CloudFrontキャッシュ の削除を行うのですが、
毎回書き換えが必要な項目がjsonファイル内にあります。

手作業で毎回書き換えてましたがさすがに面倒になってきたので
シェルスクリプトを書きました。

Macユーザーなので Macでの作業想定で書きます。

概要

AWS Consoleアクセスすれば、
Cloud Frontのキャッシュ手動削除はできるのですが、
面倒なので AWS CLI を使ってシェルスクリプトから
削除できるようにしたものです。

必要な準備

AWS CLI のローカルインストール

詳しいインストール手順はこちら

macOSの場合は Python 2.6.3 以降が必要なので

$ curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
$ sudo python get-pip.py

で pip をインストールしてから

$ sudo pip install awscli

して

$ aws help

でヘルプが出ればOKです。

AWS CLI の設定

CLI利用するのに専用の configure 設定を一度行う必要があります。
これも上記URLに設定方法があるのですが、

  • AWS Access Key ID(以下 AKID)
  • AWS Secret Access Key(以下 SAK)
  • region name
  • output format

の4つが必要です。
この設定プロファイルは

~/.aws/credentials # AKID と SAK

~/.aws/config # region name と output format

に入ります。

プロファイル名を付ければ複数のプロファイルを格納できます。
この2ファイルは1回設定しちゃえばあとはいじらなくてOKです!

↓こんな感じ

~/.aws/credentials
[profile hogehoge]
aws_access_key_id=****************      # AKID
aws_secret_access_key=****************  # SAK
~/.aws/config
[profile hogehoge]
region=ap-northeast-1                   # region name
output=json                             # output format

invalidation-batch の準備

削除対象を指定するバッチファイル(json)を作成します。
↓こんな感じです。

invbatch.json
{
    "Paths"  : {
        "Quantity": 5,
        "Items"  : [
            "/",
            "/sp/",
            "/css/main.css",
            "/js/libs.js",
            "/js/main.js"
        ]
    },
    "CallerReference": "YYYYMMDD-HHNNSS"
}

Itemsに削除対象を DocumentRoot からのパスで指定します。
ワイルドカード()も使えます。
この指定方法は **AWS Console
* での指定方法と一緒です。

注意点

CallerReference は毎回ユニークな値を入れておかなければいけません。
これが意外と面倒なのでこの部分の書き換え込みでシェルスクリプト化しました。

Note:
削除対象が変われば ItemsQuantity も変えなきゃです、、

このファイルは削除対象の変更がなければ、1回設定しちゃえばあとはいじらなくてOKです!

キャッシュ削除用シェルスクリプト設定

シェルスクリプトに実行権限$ chmod a+x ***を与えておいて、実行します。
中身は↓こんな感じです。

clear_cache.sh
#!/bin/bash

# 設定用変数
dist_id="*******************"   # AWS CloudFrontのDistribution ID
batch_json="invbatch.json"      # nvalidation-batchファイル名
profile="hogehoge"              # プロファイル名
url="http://hogehoge.jp"        # サイトURL

# 実行部分
echo "Move directory ..."
cd `dirname $0`
echo "Invbalidation-batch json update"
echo `less $batch_json_base | jq '.CallerReference |= "'$profile'_'$time_stamp'"'` > $batch_json
echo "CloudFront cache clear ..."
echo `aws cloudfront create-invalidation --distribution-id $dist_id --invalidation-batch "file://$batch_json" --profile $profile`

※ jq使ってjsonの書き換えを行なっているのでjqのインストールが必要です。

jqのインストール方法
https://stedolan.github.io/jq/download/

コード内のコメントにありますが、

  • AWSのCloudFrontDistribution ID
  • nvalidation-batch ファイル名
  • プロファイル名
  • サイトURL

が必要です。

このファイルは1回設定しちゃえばあとはいじらなくてOKです!

キャッシュ削除シェルスクリプト実行

$ ./clear_cache_shupure.sh
Move directory ...
Invbalidation-batch json update
CloudFront cache clear ...
{ "Invalidation": { "Status": "InProgress", "InvalidationBatch": { "Paths": { "Items": [ "/images/girls/*.png", "/", "/images/sakabar/*.png", "/images/events/*.jpg", "/sp/gekijo/", "/sp/sakabar/", "/gekijo/", "/sp/", "/images/girls/0924.png", "/css/main.css", "/sakabar/" ], "Quantity": 11 }, "CallerReference": "shupure_1506515279" }, "Id": "I2N11BY0PH6UI9", "CreateTime": "2017-09-27T12:28:03.125Z" }, "Location": "https://cloudfront.amazonaws.com/2017-03-25/distribution/E1JZGHRP8PFLBD/invalidation/I2N11BY0PH6UI9" }
CURL check ...
 % Total  % Received % Xferd Average Speed  Time  Time   Time Current
                 Dload Upload  Total  Spent  Left Speed
 0 50672  0   0  0   0   0   0 --:--:-- --:--:-- --:--:--   0
 X-Amz-Cf-Id: eHRIZxCp2k5-aecSw1ABCI-OB7aPtK_EEs4y0elK8bucqB6e1B-zrA==

CloudFront キャッシュ削除のレスポンスjsonが改行されてないのが気持ち悪いですが、
InProgressが表示されていればキャッシュ削除スタートしてます。

キャッシュ削除されてるかはcurlなどでレスポンスヘッダを確認してください。

$ curl -I http://hogehoge.jp

続きを読む

ec2(amazon linux)にnode.jsを導入

前提
 ・EC2のインスタンスを作成済み(yumのupdateも完了)
 ・インスタンスのセキュリティーグループでsshを許可している
 ・インスタンスにSSHに繋げる
 ・Macでターミナルを使用

手順
 1. 依存パッケージのインストール
 2. node.js v6 をインストール(当時の安定版の最新版)
 3. node.jsのインストール

1. 依存パッケージのインストール

sudo yum install -y gcc-c++ make

2. node.js v6 をインストール(当時の安定版の最新版)

curl --silent --location https://rpm.nodesource.com/setup_6.x | sudo bash -

3. node.jsのインストール

sudo yum install -y nodejs

以上〜♪

続きを読む

ec2(amazon linux)にmysql5.7を導入

前提
 ・EC2のインスタンスを作成済み(yumのupdateも完了)
 ・インスタンスのセキュリティーグループでsshを許可している
 ・インスタンスにSSHに繋げる
 ・Macでターミナルを使用

手順
 1. リボジトリの追加
 2. mysqlインストール
 3. mysql起動
 4. ログイン
 5. パスワードの変更

1. リポジトリを追加 

sudo yum install http://dev.mysql.com/get/mysql57-community-release-el6-7.noarch.rpm

2. mysqlインストール

sudo yum install mysql-community-server mysql-community-devel.x86_64

 バージョンの確認

mysql --version

3. mysql起動

sudo service mysqld start

 mysql自動起動設定

sudo chkconfig mysqld on

4. ログイン

ログインできなかったorz
調べたら「/var/log/mysqld.log」に
[Note] A temporary password is generated for root@localhost: xxxxxxxxx
と初期パスワードが書いてあるのでそれを使用してログイン
※ historyに残るからpasswordはログインコマンドと一緒に書かない方が良いと思う。。。

mysql -u root -p

5. パスワードの変更

パスワードの変更をしないと処理を受け付けてくれない為、パスワードを変更
※ポリシー強め
ALTER USER root@localhost IDENTIFIED BY '新パスワード';
※下記でパスワードのポリシーを下げる事も可能
SET GLOBAL validate_password_length=4;
SET GLOBAL validate_password_policy=LOW;

新しいパスワードで再ログインして確認する!

完了♪

続きを読む

ec2(amazon linux)にphp7を導入(phpinfo()を表示するところまで)

前提
 ・EC2のインスタンスを作成済み(yumのupdateも完了)
 ・インスタンスのセキュリティーグループでsshとhttpを許可している
 ・インスタンスにSSHに繋げる
 ・nginxかapache導入済み(ここではnginx)
  ※ nginx導入手順
 ・Macでターミナルを使用

手順
 1. php7.1をインストール
 2. phpinfo()を表示させる
 3. 番外

1. php7.1をインストール

php7.1をインストール(下記php71以外は必要なものを選んでインストールしてください)

sudo yum install php71 php71-devel php71-fpm php71-mysql php71-mbstring php71-pdo php71-xml php71-zip

 バージョンの確認 

php -v

2. phpinfo()を表示させる

 DocumentRootの編集

sudo vi /etc/nginx/nginx.conf

 ※40行目付近にある「server」の中を下記の様に編集
修正前:root /usr/share/nginx/html;
修正後:root /var/www/html;

 ※40行目付近にある「server」の中に下記を追記

location ~ .php$ {
    root           html;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
    include        fastcgi_params;
}

 phpinfo()を表示するためのファイルを設置

sudo vi /var/www/html/phpinfo.php

 ファイル(phpinfo.php)の中身

<?php
    echo phpinfo();
?>

 nginxの再起動とphp-fpmの起動

sudo service nginx restart
sudo service php-fpm start

 ブラウザから確認

「http://IPアドレス/phpinfo.php」でブラウザから接続

3. 番外

php-fpmを自動起動する様に設定

sudo chkconfig php-fpm on

php.iniの基本的な設定をここで設定しておく

 自分はそんなに詳しくないのでとりあえず下記参考URL通り設定
 参考:http://affiwork.net/php-settings/
 ※参考URLで使用しているのはApacheなのでrestartはnginx
  ファイルはコピーを取っておいて下記コマンドで確認すると安心♪
 diff /etc/php.ini /etc/php.ini_def

 全部済んだらnginxとphp-fpmを再起動して確認する!

sudo service nginx restart
sudo service php-fpm restart

 ブラウザから確認して反映されていればOK!!!
 「http://IPアドレス/phpinfo.php」でブラウザから接続

続きを読む

ec2(amazon linux)にnginxを導入(デフォルトページの表示まで)

前提
 ・EC2のインスタンスを作成済み
 ・インスタンスのセキュリティーグループでsshとhttpを許可している
 ・インスタンスにSSHに繋げる
 ・作成したばっかりのインスタンスを想定
 ・Macでターミナルを使用

手順
 1.インスタンスにsshで入る
 2.yumのupdate
 3.nginxのインストール
 4.nginxのデフォルトページを表示

1. インスタンスにsshで入る

ssh -i 鍵のPATH ec2-user@IPアドレス

2. yumのupdate

sudo yum update

3. nginxのインストール

 最新版の確認(Stable versionが安定板)
 nginxインストール

sudo yum install nginx

 バージョンの確認

nginx -v

4. nginxのデフォルトページを表示

 nginxを起動

sudo service nginx start

 「http://IPアドレス」でブラウザから接続
 デフォルトページが表示されるはず♪

 めんどいので自動起動する様に設定

 sudo chkconfig nginx on

以上っす!

続きを読む

unisonでローカルとサーバをお手軽に同期する

はじめに

ローカルとサーバのディレクトリを同期する必要があったので、今回unisonを使ってみました。
予想以上にunisonのバージョンを揃えたりと面倒だったのでインストール手順を残しておきます。
基本的に上からコピペすれば動くと思います。

ローカル

unisonのインストール
$ brew install unison
# プロジェクトを作成
/Users/user.name/.unison/project.prf

下記参考に諸々書き換える(IPはhostでいける)
これがどこのサーバと同期するか、何を同期するかの設定ファイルとなります。

# リモートのディレクトリ
root = ssh://project.com//var/www/project
# ローカルのディレクトリ
root = /Users/user.name/Desktop/project


ignore = Path vendor
ignore = Name {tmp,log}
auto = true
times = true
prefer = newer

サーバ

結構長い
コケるけど無視

curl -kL https://raw.github.com/hcarty/ocamlbrew/master/ocamlbrew-install | bash

インストールが終わるとocamlbrewというディレクトリが出来ます。

.bashrcに下記をコピペ(ocamlbrewのバージョンは合わせてください)

.bashrc
__ocaml_path__="$HOME/ocamlbrew/ocaml-4.03.0" # ~/ocamlbrewをlsしてみて適切なバージョン番号に置き換えてください
PATH="$__ocaml_path__/bin:$PATH"
export OPAMROOT="$__ocaml_path__/.opam"
source "$OPAMROOT/opam-init/init.bash" > /dev/null 2> /dev/null || true

パスを通す

source ~/.bashrc

インストール

ここも少し長い

opam switch 4.03.0

インストール

opam install oasis utop Batteries ocamlscript
sudo yum install ocaml ocaml-camlp4-devel ctags ctags-etags

ファイルをダウンロード&移す

サーバにインストールするために、パッケージをダウンロードします。
ローカルとサーバのunisonのバージョンを合わせる必要があるので、ローカルにインストールしたバージョンをダウンロード
してください。

サイト http://www.seas.upenn.edu/~bcpierce/unison//download/releases/

macで解答

解凍したファイルをサーバにアップロード

scp -r /Users/shoichi/Downloads/src project.com:/home/webmaster

アップロードしたファイルに移動してビルド

make
# ビルドが終わったらこのコマンドをインストールしたら叩く
sudo cp -v unison /usr/bin/

これでセットアップが完了しました。
あとはローカルに戻って下記を実行して、同期していきましょう。

実行

unison project -repeat watch

以上です。

参考

http://qiita.com/yuya_presto/items/f35f556770196f964810
https://plus.google.com/103080563170453474101/posts/ZMBytWVkhTn
https://www.digitalocean.com/community/questions/install-unison-in-centos-7

続きを読む