Amazon RDSにSSHトンネルでIntelliJ IDEAから接続した時のメモ

RDSのパブリックアクセスを「いいえ」にしている状況で、IntelliJ IDEAから接続したい。という状況での設定メモ。
RDSにかぎらず、踏み台サーバ使うときは同様の設定方法でいけるはず。

RDSにアクセス可能なEC2インスタンス1台にElastic IPでIPが振られている状態で、
sshクライアントからアクセス可能な状態を想定しています。

データ・ソースおよびドライバー

一般

ここはローカルのDBなど直接アクセスできるDBに接続するときと同じ設定です。

20171211_1.png

ホスト: AWSコンソールのRDSの[エンドポイント]
データベース: AWSコンソールの[DB名]
ユーザー: AWSコンソールの[ユーザ名]
パスワード: インスタンス生成時に入力したパスワード

SSH/SSL

SSHトンネルの設定をします。

20171211_2.png

プロキシー・ホスト: インスタンスに設定したElastic IP
ポート: 22 (sshdの設定を変更していればその値)
プロキシー・ユーザー: ubuntu (ubuntuでインスタンス生成したとき、AMIはec2-user)
認証タイプ: Key pair
プライベート・キー・ファイル: キーペアで設定した秘密鍵を設定

こんな感じで出来ました。

mysqlコマンドで接続したときは

$ ssh -N -L 3307:appname.aaaaaaa.ap-northeast-1.rds.amazonaws.com:3306 -i ~/.ssh/id_rsa -p 22 ubuntu@host

とした後に、

$ mysql -u username -p -h 127.0.0.1 --port=3307

で接続できました。

続きを読む

絶対的に使った方がいいLogstashのMultiple Pipelinesについて書いてみた

はじめに

おはです!
Logstashのフィルタの中でもGrokが好きなぼくが、Advent Calendar11日目を書かせていただきますー
あ、でも今回は、Grokについては書かないですよ!

じゃあ、何書くの?Grokしか脳のないお前が何を書くのさー
そりゃ、あれだよ!Logstash 6.0がGAされたので、待ちに待ったMultiple Pipelinesについて書くしかないでしょ!

てことで、LogstashのMultiple Pipelinesについて、ゆるーく書いていきます( ゚Д゚)ゞビシッ

構成について

今回テストするにあたって使用した構成は以下です。

  • Amazon Linux AMI 2017.09.1 (HVM)
  • Logstash 6.0
  • logstash-input-s3
  • Elasticsearch 6.0
  • Kibana 6.0
  • X-Pack 6.0

ちなみに、もろもろインストールされている前提で記載しています。
もし、インストールする場合は、以下のインストール手順を参考にして頂ければと思います。

Logstashについて

Logstashは、Elasticsearch社が提供するオープンソースのデータ収集管理ツールです。

LogstashのPipelineは、以下のような流れで処理されます。
例として、インプットデータをApacheのログファイルで、ログファイルに対してフィルタをかけ、Elasticsearchにストアするといった流れにしてます。1

logstash01.png

INPUT

様々なデータソースを取り込みたい!そんな要望に応えるべく用意されたのがLogstash。
Logstashは、様々なデータ形式に対応しています。
例えば、ソフトウェアのログ、サーバのメトリクス、Webアプリケーションのデータや、クラウドサービスなど。

FILTER

INPUTしたデータソースをフィルタで解析し、構造化します。
データソースの変換には、正規表現でデータをパースするためのGrokフィルタや、IPアドレスから地理情報を得るためのGeoIPフィルタなど様々なフィルタライブラリが用意されています。

OUTPUT

データを構造化したのち、任意の出力先にデータをストアします。
Elasticsearch以外の出力先も多数提供されているので、環境に合わせてデータをストアします。

Logastashのディレクトリ構成

上記までが処理の流れで、これらの処理を定義するファイルをLogstashでは準備する必要があります。

以下のようにLogstashのディレクトリは構成されており、conf.d配下に定義ファイル(hoge.confと記載)を配置します。

/etc/logstash
  ├ conf.d
  │ └ hoge.conf
  ├ jvm.options
  ├ log4j2.properties
  └ logstash.yml

hoge.confに様々なデータソースに対して定義します。
例えば、AWSのALBのアクセスログとApacheのアクセスログを定義すると以下のようになります。2

hoge.conf
input {
  s3 {
    tags => "alb"
    bucket => "hoge"
    region => "ap-northeast-1"
    prefix => "hoge/"
    interval => "60"
    sincedb_path => "/var/lib/logstash/sincedb_alb"
  }
  file {
    path => "/etc/logstash/log/httpd_access.log"
    tags => "httpd"
    start_position => "beginning"
    sincedb_path => "/var/lib/logstash/sincedb_httpd"
  }
}
filter {
  if "alb" in [tags] {
    grok {
      patterns_dir => ["/etc/logstash/patterns/cloudfront_patterns"]
      match => { "message" => "%{ALB_ACCESS}" }
      add_field => { "date" => "%{date01} %{time}" }
    }
    date {
      match => [ "date", "yy-MM-dd HH:mm:ss" ]
      locale => "en"
      target => "@timestamp"
    }
    geoip {
      source => "c_ip"
    }
    useragent {
      source => "User_Agent"
      target => "useragent"
    }
    mutate {
      convert => [ "time_taken", "float" ]
      remove_field => [ "message" ]
    }
  else if "httpd" in [tags] {
    grok {
      patterns_dir => ["/etc/logstash/patterns/httpd_patterns"]
      match => { "message" => "%{HTTPD_COMMON_LOG}" }
    }
    geoip {
      source => "clientip"
    }
    date {
      match => [ "date", "dd/MMM/YYYY:HH:mm:ss Z" ]
      locale => "en"
      target => "timestamp"
    }
    mutate {
      remove_field => [ "message", "path", "host", "date" ]
    }
  }
}
output {
  if "alb" in [tags] {
    elasticsearch {
      hosts => [ "localhost:9200" ]
      index => "elb-logs-%{+YYYYMMdd}"
    }
  }
  else if "httpd" in [tags] {
    elasticsearch {
      hosts => [ "localhost:9200" ]
      index => "httpd-logs-%{+YYYYMMdd}"
    }
  }
}

このようにデータソース毎にタグを付与し、if文で判定させるといったかたちになってます。
今回は、データソースが少ないからいいですが、更に増やしていくとなると可読性も悪くなるのと、リソースのハンドリングも難しくなってきます。
また、データソースが増えたり、フィルタ変更などの際には、一つの定義ファイルを更新するため、全体に影響を及ぼす可能性があります。。
なんてこった(´□`;)

Multiple Pipelinesになると何がいいのさ

そこで!Multiple Pipelinesの出番なのです!
hoge.confに対して複数のデータソースを組み込んでいたものを、分割することができちゃうのですー
また、リソースの割り当てとして、Worker数などもPipeline毎に割り当てることができるのです!歓喜!!

ここからは、Multiple Pipelinesをどのように使うのかを書いてきます。

Multiple Pipelinesを試してみる。

Logstashのディレクトリ構成は変わらないのですが、新しくpipelines.ymlという定義ファイルを作成します。
また、先ほどのhoge.confをデータソース毎にファイルを以下のように分けます。

  • alb.cfg
  • httpd.cfg

alb.cfgの定義は以下です。

alb.cfg
input {
  s3 {
    bucket => "hoge"
    region => "ap-northeast-1"
    prefix => "hoge/"
    interval => "60"
    sincedb_path => "/var/lib/logstash/sincedb_alb"
  }
}
filter {
  grok {
    patterns_dir => ["/etc/logstash/patterns/cloudfront_patterns"]
    match => { "message" => "%{ALB_ACCESS}" }
    add_field => { "date" => "%{date01} %{time}" }
  }
  date {
    match => [ "date", "yy-MM-dd HH:mm:ss" ]
    locale => "en"
    target => "@timestamp"
  }
  geoip {
    source => "c_ip"
  }
  useragent {
    source => "User_Agent"
    target => "useragent"
  }
  mutate {
    convert => [ "time_taken", "float" ]
    remove_field => [ "message" ]
  }
 }
output {
  elasticsearch {
    hosts => [ "localhost:9200" ]
    index => "elb-logs-%{+YYYYMMdd}"
  }
}

httpd.cfgの定義は以下です。

httpd.cfg
input {
  file {
    path => "/etc/logstash/log/httpd_access.log"
    start_position => "beginning"
    sincedb_path => "/var/lib/logstash/sincedb_httpd"
  }
}
filter {
  grok {
    patterns_dir => ["/etc/logstash/patterns/httpd_patterns"]
    match => { "message" => "%{HTTPD_COMMON_LOG}" }
  }
  geoip {
    source => "clientip"
  }
  date {
    match => [ "date", "dd/MMM/YYYY:HH:mm:ss Z" ]
    locale => "en"
    target => "timestamp"
  }
  mutate {
    remove_field => [ "message", "path", "host", "date" ]
  }
}
output {
  elasticsearch {
    hosts => [ "localhost:9200" ]
    index => "httpd-%{+YYYYMMdd}"
  }
}

ディレクトリ構成は以下になります。

/etc/logstash
  ├ logstash.yml
  ├ conf.d
  │ └ alb.cfg
  │ └ httpd.cfg
  ├ jvm.options
  ├ log4j2.properties
  └ pipelines.yml

ここでやっと登場するpipelines.ymlの定義は以下です。

pipelines.yml
- pipeline.id: alb
  pipeline.batch.size: 125
  path.config: "/etc/logstash/conf.d/alb.cfg"
  pipeline.workers: 1
- pipeline.id: httpd
  pipeline.batch.size: 125
  path.config: "/etc/logstash/conf.d/httpd.cfg"
  pipeline.workers: 1

めっちゃシンプルですね。
呼び出すファイルパスの指定とパラメータの定義を記載するだけです。
データソース単位でpipeline.workersを割り当てられることになったので、柔軟にコアの配分ができるようになりました。
詳細の設定については、settings fileを確認してもらえればと思います。

動かすよ!

今回、サービス起動を前提としているため、pipelines.ymlを読み込ませるには、logstash.confのpath.configをコメントアウトする必要があります。
(ここでハマりました。。公式サイトにサービス起動について書かれているところがみつからず。。)

logstash.conf
# path.config: /etc/logstash/conf.d/*.conf

てことで、起動しますー
これでデータソース単位で動かすことができます。

$ initctl start logstash
logstash start/running, process 3121

おまけ

今回説明していないですが、X-Packを導入することで、MonitoringでPipelineの状況をみることができます。
データの流れを把握したり、分岐などのロジックが有効に働いてるかなども確認することが可能です。

先ほど、alb.cfgを取り込んだ際のPipelineは以下の様に表示されます。

logstash03.png

さいごに

いかがでしたか?
Multiple Pipelinesは、常にデータを取り込んでいるLogstashを支えるための根幹たる機能ではないでしょうか?
ぜひぜひ、みなさんもMultiple Pipelinesを使って、よりよいLogstsah Lifeを送って頂ければとヽ(*゚д゚)ノ

それでは、Advent Calendar11日目を終わりますー
明日の12日目は、”Elasticsearch v1.7 -> v2.4 -> v5.5 と段階的にバージョンアップした話し”ですね!
楽しみだすー


  1. Elasticsearch社の公開されているグローバルIPを利用しています 

  2. 指定しているパスは、環境に合わせて指定してください 

続きを読む

AutoScalingGroupのインスタンス起動・停止をSlackに通知する

AutoScalingGroupの作成からSNSとLabmdaと連携してイベントをSlackに通知するところまで。

LaunchConfigurationの作成

AutoScalingGroupingを作るためにはLaunchTemplate, LaunchConfigurationNameまたはInstanceIdが必要なので今回はLaunchConfigurationを作成します。

$ aws autoscaling create-launch-configuration 
  --launch-configuration-name sample-auto-scale-launch-configration 
  --instance-type t2.micro 
  --image-id ami-bf4193c7
  --key-name xxxxx

AutoScalingGroupの作成

先ほど作成したLaunchConfigurationを指定してAutoScalingGroupを作成します。

$ aws autoscaling create-auto-scaling-group 
  --auto-scaling-group-name sample-auto-scale 
  --min-size 1 --max-size 5 
  --launch-configuration-name sample-auto-scale-launch-configration 
  --availability-zones us-west-2a us-west-2b

インスタンスの起動・停止を通知する

AutoScalingGroupからインスタンスのイベントを受け取る方法は LifeCycleHookでもできそうですが、今回はSNSを使った方法でやってみます。

SNSのトピックを作成する

AutoScalingGroupのイベントを通知するためのTopicを作成します。

$ aws sns create-topic --name sample-auto-scale-notification

AutoScalingGroupのイベントをSNSと紐付ける

NotificationConfigurationを追加します。
今回は以下の4つのイベントをSNSで通知するようにしました。

  • EC2_INSTANCE_LAUNCH
  • EC2_INSTANCE_LAUNCH_ERROR
  • EC2_INSTANCE_TERMINATE
  • EC2_INSTANCE_TERMINATE_ERROR
$ aws autoscaling put-notification-configuration 
  --auto-scaling-group-name sample-auto-scale 
  --topic-arn arn:aws:sns:us-west-2:999999999999:sample-auto-scale-notification 
  --notification-types "autoscaling:EC2_INSTANCE_LAUNCH" "autoscaling:EC2_INSTANCE_LAUNCH_ERROR" "autoscaling:EC2_INSTANCE_TERMINATE" "autoscaling:EC2_INSTANCE_TERMINATE_ERROR"

SNSからSlackに通知するLambdaを作成する

pythonでSlackへ通知するLambdaを作成していきます。

sns-to-slack-notificatioin-lambda.png

import urllib.request
import json

def lambda_handler(event, context):
    url = 'https://hooks.slack.com/services/AAAAAAAAA/BBBBBBBBB/CCCCCCCCCCCCCCCCCCCCCCCC'
    method = "POST"
    headers = {"Content-Type" : "application/json"}
    obj = {"text":json.dumps(event)}
    json_data = json.dumps(obj).encode("utf-8")
    request = urllib.request.Request(url, data=json_data, method=method, headers=headers)
    with urllib.request.urlopen(request) as response:
        response_body = response.read().decode("utf-8")

    return response_body

LambdaにSNSをsubscribeさせる

$ aws sns subscribe 
  --topic-arn arn:aws:sns:us-west-2:999999999999:sample-auto-scale-notification 
  --protocol lambda 
  --notification-endpoint arn:aws:lambda:us-west-2:999999999999:function:sns-to-slack-notification

SNSがLambdaを起動できるようにpermissionを与えます。

$ aws lambda add-permission 
  --function-name sns-to-slack-notification 
  --statement-id autoscaling-sns-to-lambda 
  --action "lambda:InvokeFunction" 
  --principal sns.amazonaws.com 
  --source-arn arn:aws:sns:us-west-2:999999999999:sample-auto-scale-notification

インスタンスを追加して通知を受け取る

AutoScalingGroup -> SNS -> Lambdaの設定ができたので実際にインスタンスを追加して通知を確認します。
desired-capacityを増やし、インスタンスを1つ起動します。

$ aws autoscaling set-desired-capacity 
  --auto-scaling-group-name sample-auto-scale 
  --desired-capacity 2

インスタンスが起動されSlackに通知がきました。

スクリーンショット 2017-12-10 14.50.32.png

続きを読む

TerraformでAWS AMIの最新を常に使うようにする

TerraformとAWSに同時入門する
の続きで、

最新のAMIが常に指定されるようなami設定にする

を行えるようにします。

確認環境

$ terraform version
Terraform v0.11.1
+ provider.aws v1.5.0

取得するAMIのスペック

今回は2017/12/10時点でのAmazon Linuxの下記スペックにおける最新AMI ID(ami-da9e2cbc)を取得します。
最新AMI IDはこちらで確認できます: Amazon Linux AMI ID

  • リージョン: アジアパシフィック東京
  • 仮想化タイプ: HVM
  • ルートデバイスタイプ: EBS-Backed
  • アーキテクチャ: x86_64
  • ボリュームタイプ: gp2

:warning: 注意点
AMI IDはリージョン毎に異なるようなので複数リージョンにまたがった環境の場合は注意が必要かもしれません

結論

簡易版

フィルタ条件はAMI Image名の条件のみ

aws_ami.tf
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn-ami-hvm-*-x86_64-gp2"]
  }
}

詳細版

フィルタ条件として今回の指定スペックをすべて指定

参考: Terraformでもいつでも最新AMIからEC2を起動したい

aws_ami.tf
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners = ["amazon"]

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }

  filter {
    name   = "name"
    values = ["amzn-ami-hvm-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  filter {
    name   = "block-device-mapping.volume-type"
    values = ["gp2"]
  }
}

EC2側の設定

ec2.tf
resource "aws_instance" "web-server" {
  ami                    = "${data.aws_ami.amazon_linux.id}"
  instance_type          = "t2.micro"
}

確認

$ terraform plan

  + aws_instance.web-server
      id:                           <computed>
      ami:                          "ami-da9e2cbc"
      ...

AWS CLIでAmazon Linux AMI image名を取得してみる

準備

AWS Command Line Interface のインストール

簡易版のフィルタ条件の説明

AWS CLIで最新のAmazon LinuxのAMI IDを取得する
上記でのシェルを参考に今回取得したい条件に変更します

get-aws-ec2-image.sh.sh
...

describe_images(){
    echo $timestamp > $timestamp_file
    aws ec2 describe-images 
-       --owners self amazon 
+       --owners amazon 
        --filters 
+         Name=name,Values="amzn-ami-hvm-*" 
          Name=virtualization-type,Values=hvm 
          Name=root-device-type,Values=ebs 
          Name=architecture,Values=x86_64 
-         Name=block-device-mapping.volume-type,Values=standard
+         Name=block-device-mapping.volume-type,Values=gp2
}

...

実行結果

$ zsh ./get-aws-ec2-image.sh

amzn-ami-hvm-2014.03.2.x86_64-gp2: ami-df470ede
amzn-ami-hvm-2014.09.0.x86_64-gp2: ami-45072844
amzn-ami-hvm-2014.09.1.x86_64-gp2: ami-4585b044
amzn-ami-hvm-2014.09.2.x86_64-gp2: ami-1e86981f
amzn-ami-hvm-2015.03.0.x86_64-gp2: ami-cbf90ecb
amzn-ami-hvm-2015.03.1.x86_64-gp2: ami-1c1b9f1c
amzn-ami-hvm-2015.09.0.x86_64-gp2: ami-9a2fb89a
amzn-ami-hvm-2015.09.1.x86_64-gp2: ami-383c1956
amzn-ami-hvm-2015.09.2.x86_64-gp2: ami-59bdb937
amzn-ami-hvm-2016.03.0.x86_64-gp2: ami-f80e0596
amzn-ami-hvm-2016.03.1.x86_64-gp2: ami-29160d47
amzn-ami-hvm-2016.03.2.x86_64-gp2: ami-6154bb00
amzn-ami-hvm-2016.03.3.x86_64-gp2: ami-374db956
amzn-ami-hvm-2016.09.0.20160923-x86_64-gp2: ami-1a15c77b
amzn-ami-hvm-2016.09.0.20161028-x86_64-gp2: ami-0c11b26d
amzn-ami-hvm-2016.09.1.20161221-x86_64-gp2: ami-9f0c67f8
amzn-ami-hvm-2016.09.1.20170119-x86_64-gp2: ami-56d4ad31
amzn-ami-hvm-2017.03.0.20170401-x86_64-gp2: ami-859bbfe2
amzn-ami-hvm-2017.03.0.20170417-x86_64-gp2: ami-923d12f5
amzn-ami-hvm-2017.03.1.20170617-x86_64-gp2: ami-bbf2f9dc
amzn-ami-hvm-2017.03.1.20170623-x86_64-gp2: ami-3bd3c45c
amzn-ami-hvm-2017.03.1.20170812-x86_64-gp2: ami-4af5022c
amzn-ami-hvm-2017.03.rc-0.20170320-x86_64-gp2: ami-be154bd9
amzn-ami-hvm-2017.03.rc-1.20170327-x86_64-gp2: ami-10207a77
amzn-ami-hvm-2017.09.0.20170930-x86_64-gp2: ami-2a69be4c
amzn-ami-hvm-2017.09.1.20171103-x86_64-gp2: ami-2803ac4e
amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2: ami-da9e2cbc
amzn-ami-hvm-2017.09.rc-0.20170913-x86_64-gp2: ami-d424e7b2

最新AMI ID(ami-da9e2cbc)が取得できているのがわかります。

amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2: ami-da9e2cbc

取得結果からわかるようにImage名にはスペック名も含まれていることがわかります。

よって今回のスペックのAMI IDはImage名でのフィルタ条件のみで取ることができるため、簡易版ではImage名の値が"amzn-ami-hvm-*-x86_64-gp2"とするフィルタ条件1つで最新のAMI IDを取得していました。

また、aws_ami.tfではmost_recent = trueという設定により取得した中で最新のAMI IDが取得されます。

:warning: Image名の命名規則が変更された場合に指定スペックの最新が取得できなくなるので注意ください

フィルタ条件をnameのみにしてAWS CLIでも確認

AWS CLI側でも一応確認

get-aws-ec2-image.sh
describe_images(){
    echo $timestamp > $timestamp_file
    aws ec2 describe-images 
        --owners amazon 
        --filters 
          Name=name,Values="amzn-ami-hvm-*-x86_64-gp2" 
-          Name=virtualization-type,Values=hvm 
-          Name=root-device-type,Values=ebs 
-          Name=architecture,Values=x86_64 
-          Name=block-device-mapping.volume-type,Values=gp2
}
$ zsh ./get-aws-ec2-image.sh | grep ami-da9e2cbc

amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2: ami-da9e2cbc

最新AMI ID(ami-da9e2cbc)が取得できているのがわかります。

その他の参考

続きを読む

AWSのインスタンスにLAMP環境を構築する際に使用したコマンドについて解説する

AWSにインスタンスを作成したあとに・・・

AWSにインスタンスを作成したあと、SSHのキーを使ってインスタンスに入るところから解説します。

使用するインスタンス

  • 無料枠のEC2
  • OSはAmazon Linux
  • セキュリティグループはSSH

インスタンスができたら

使用する端末がwinの場合はツールをインストールしてください。macの場合はターミナルを起動してください。
macのターミナルの場所:アプリケーション>ユーティリティ>ターミナル

1インスタンスに入る

①SSHのキーの設定

インスタンス作成の際にダウンロードしたキーを使用します。
chmod 600 ~/hoge/hoge.pem
⇨このキーの権限を設定するよ!
【入力内容】
:sunny:~/hoge/hoge.pem のところには
 ダウンロードしたキーのファイルパスを入力してください。

【コマンドの解説】
:cherry_blossom: chmod
チェンジモードchange modeの意味でアクセス権を変更するときに使用します。

:cherry_blossom: 600
3桁の数字はアクセス権を示します。

600:1桁目は所有者の権限です。
600:2桁目はグループの権限です。
600:3桁目はその他の権限です。

さらにそれぞれの数字に権限の意味があります。
6:読み込み権限と書き込み権限
0:権限なし

つまり600というのは、
所有者の権限には読み込みと書き込みの権限を与え、
グループの権限とその他の権限には権限を何も与えない
ということになります:astonished:

:cherry_blossom: キーのファイルパス
権限を与える対象のファイルを指定することになります。

【参考サイト】
chmodについて詳しく!
chmod? chown? よくわからんって人のための、ファイル権限系まとめ
権限の数字について詳しく!
【 chmod 】 ファイルやディレクトリのアクセス権を変更する
コマンド操作を楽ラクにしたい!
ブクマ必至!Linuxコマンド一覧表【全33種】 2.2 覚えておくと便利なショートカットキー

②SSHのキーを使用して入る

①で使用したキーをここでも使用します。
ssh ec2-user@hoge -i ~/hoge/hoge.pem
⇨このキーでインスタンスに入るよ!
【入力内容】
:sunny:ec2-user@hoge のhogeにはインスタンスのIPv4 パブリック IPを入力してください。
:sunny:~/hoge/hoge.pem のところには①同様、
 ダウンロードしたキーのファイルパスを入力してください。

【コマンドの解説】
:cherry_blossom: ssh
インスタンス作成時のセキュリティグループでタイプSSHを選択しました。
それです。

:cherry_blossom: ec2-user@hoge
アクセス先を指定する。

:cherry_blossom: -i
informationのiです。付加情報がある際にはこのあとに記述します。

:cherry_blossom: ~/hoge/hoge.pem
今回の付加情報です。
「このキーでインスタンスに入るよ!」の「このキー」というのが付加情報になります。

③質問されるので答える

②を実行すると以下の文章が表示されます。

Are you sure you want to continue connecting (yes/no)?

⇨接続することは同意ですか?

同意なので
yes
と入力してください。

④入れた!

以下のAAが表示されたらインスタンスに入れました!おめでとう:heart_eyes:

  __|  __|_  )
  _|  (     /   Amazon Linux AMI
 ___|___|___|

2環境を整える

①インスタンスを更新する

インスタンスを最新の状態にしたいので、アップロードするものがあればアップロードするようにします。
sudo yum update -y
⇨管理者権限でアップデートするよ!
これを実行するとズラズラ文章が流れていきます。

【コマンド解説】
:cherry_blossom: sudo
superuser do の略で、管理者権限で実行することを意味します。
これを入れ忘れると、データが保存されなかったり、
実行しても権限がないと言われてしまうので、入れ忘れに注意してください。
superuserはrootのことです。

:cherry_blossom: yum update
yumはパッケージを取得してそれをどうするかの指定です。
どうするかは今回はupdateなので更新します。
つまりupdateのところをinstallにすれば、パッケージのインストールができます。

:cherry_blossom: -y
何か質問されたらyesで答えるときに使用します。
毎回質問に対して返事するのが面倒なときに使うと便利です。

【参考サイト】
rootとは?
【完全初心者向け】Linuxのrootユーザとは?

②Apache,PHP,MySqlをインストールする

LAMP環境と言われるAMPの部分です。
ちなみにLは(Amazon) LinuxのLです。
sudo yum install -y httpd24 php70 mysql56-server php70-mysqlnd
⇨管理者権限でインストールするよ!
インストールするものは
・Apache
・PHP
・MySql
・PHPのMySql用ドライバー
だよ!

これを実行するとズラズラ文章が流れていきます。

Complete!

が表示すれば成功です。
【入力内容】
:sunny: 数字はバージョンを表しています。インストールするときによって
 使用するバージョンが異なるのでチェックしてください。

【コマンド解説】
:cherry_blossom: sudo yum install -y
詳細は前述済みです。
何をインストールするかの指定を-y以降に記述します。

:cherry_blossom: httpd24
Apache2.4をインストールします。
Apacheとはwebサーバーのことです。
webサーバーがないとPHPなどのプログラムが動かないので必要です。

:cherry_blossom: php70
今回の主役、PHPです。PHP7.0をインストールします。

:cherry_blossom: mysql56-server
今回使用するデータベースはMySqlです。MySql5.6のサーバーの方をインストールします。
サーバーの方と言うだけあって、クライアント(端末)の方もあります。
今回はインスタンス(サーバー)に入れたいので、サーバーの方のMySqlをインストールします。

:cherry_blossom: php70-mysqlnd
PHPでMySqlを使うためのドライバーをインストールします。
これがないとPHPでMySqlを使うことができないです。

サーバーを起動する

力尽きたので後日書きます。

続きを読む

AWS EC2上のUbuntu16.04にデスクトップ環境を構築してMacからつなぐ

はじめに

やりたいこと

AWS EC2上にUbuntu16.04のインスタンスをたてて、そのインスタンスにMacからリモートデスクトップが接続する

なんでこの記事を書いたか

ぐぐってみると、日本語、英語で色々なドキュメントが出てきた。それらを参考に色々試したがサクッとはいかなかった。「どれを参考にすればいいねん!」って人向けに「これを実行すればサクッと構築できるよ」という情報を提供したかったから書いた。
ちなみに、X Window System、ubuntu-desktop、xrdp、Xfce4、GNOME、KDE、Unity、vncなどなど、
用語がわからなすぎたのでハードルが高く感じた。

いまはただのメモ

とりあえずメモ代わりに投稿するかってくらいのモチベーションで投稿してます。
もしここの記述がようわからんとかあれば、コメントいただければ少しずつ細かく書いていきます。

想定している読者レベル

  • EC2インスタンスをたてたことがある
  • なんとなくlinuxコマンドがつかえる

用語

X Window System

ディスプレイにウィンドウを表示したり、マウスやキーボードを使ってやりとりするためのシステム。WindowsやMacではOSとこのソフトウェアが一体化しているが、Linuxでは一体化してないのでもし先述のことを行いたい(=GUI)場合はインストールする必要がある。MacのOS Xの「X」とWindowsの「Window」がまざった「X Window System」という名称で紛らわしい。単に「X」と呼ばれることもある。

Xfce, GNOME, KDE, Unity,

デスクトップ環境を実現するためのシステム。色々あってややこしいが、デスクトップ上のデザインや機能が微妙に違うだけ。今回はXfceを使った。

vnc

ネットワーク越しに、別のコンピューターのデスクトップ画面を表示してGUI操作することができるシステム。今回Ubuntuで環境を構築するにあたって参照した記事ではvnc4serverかTightVNCのどちらかを使っていることが多かった。

手順

EC2インスタンス作成

下記参照にEC2インスタンスを作成
– AMIはクイックスタートにあるUbuntu 16.04
– セキュリティグループのインバウンドにポート5901を追加
– とりあえずt2.microでいい

デスクトップ環境構築

この記事のとおりでOK

sudo apt update && sudo apt upgrade

sudo sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
sudo /etc/init.d/ssh restart

sudo passwd ubuntu

sudo apt install xrdp xfce4 xfce4-goodies tightvncserver

echo xfce4-session> /home/ubuntu/.xsession

sudo cp /home/ubuntu/.xsession /etc/skel

sudo sed -i '0,/-1/s//ask-1/' /etc/xrdp/xrdp.ini

sudo service xrdp restart

tightvncserver

つなぐ

Finder起動->移動->サーバへ接続で、vnc://XX.XX.XX.XX:5901に接続。
XX.XX.XX.XXは作成したEC2インスタンスのIPかパブリックDNSを指定。
ただしvncはそのままでは暗号化されてないので、セキュアなことをやりたい場合はご自身で対応をお願いします。

ついでに日本語化

chromeをインストールしたら、日本語が文字化けしてたので日本語化してみた。
“Language support” icon missing in System Settings
英語環境でセットアップしてしまったUbuntuで日本語を使えるようにする

補足

  • tightvncserverでなくてvnc4serverでもOKだと思います(試してない)
  • xrdpはaptからのインストールでOK

続きを読む

EMRクラスターを起動するシェルスクリプト

… test-cluster” aws emr create-cluster –name test-cluster –ami-version 3.4.0 –applications Name=Hive Name=Hue –instance-groups InstanceGroupType=MASTER,InstanceCount=1,InstanceType=c3.xlarge InstanceGroupType=CORE,InstanceCount=2,InstanceType=c3.xlarge –use-default-roles … 続きを読む

AWS上でredashを使ってデータを可視化しよう

データを可視化をするツールとして、いろいろありますが現在関わっているプロジェクトでみたいデータがRDSに溜まっていたので、それをうまく抽出し開発者以外にも簡単に見せるツールの一つとして今回redashを試してみました。

容易するもの

特になし。
サービスでRDSとかつかっているならば、すぐにredashで可視化ができます。

手順

  1. redashのamiを選択する。

    • 最新の対応するamiはここから探してください
    • 私が環境作成した時点での最新はami-fde8199bのAMIでした。
  2. EC2の立ち上げを行う
    • 接続するRDSが覗けるサブネット、セキュリティグループを適切に設定してください。
    • redashのインスタンスは80番をあけておいてください

1番で選択したamiであれば、Webサーバーの設定をせずにすぐに http://インスタンスのPublicIP/ にアクセスすればすぐに確認できます。

Redashの設定

管理者のID, Passwordは適当に設定して下さい。

スクリーンショット 2017-12-06 16.12.35.png

右上にあるデータベースのマークをクリックすると可視化したいデータ元の追加ができます。

データソースとしては、以下が選べるみたいです。
(自分が触ったのが2017/10頃なのでもっと増えているかもしれません)

スクリーンショット 2017-12-06 15.57.26.png

私はRDS(postgreSQL)をつかってたので、一番下のPostgreSQLを選択しました。

あとはHost(RDSのエンドポイント)やportを適切に設定すれば、可視化のデータソースの完成です。
あとは、クエリを書けば簡単に可視化できます。

スクリーンショット 2017-12-06 16.21.02.png

きになったこと&tips

  • redash上のSQLで{{}}という書き方をすると変数として取り扱えます。文字列で解釈したい場合は'{{}}'とシングルクォーテーションでかこってあげましょう。
  • 可視化したViewをiframeではめ込むことができます。ただ、変数ありきのSQLはバグなのか変数部分が欠落してしまうみたいなので、注意してください(改善してるかも?)
  • 設定でユーザーを追加できますが、権限の細かな設定はできませんでした。配布されたAMIに入っているredashがそういうものなのかもしれません。

続きを読む

GitLabのgitlab-runner autoscalingをaws上でdocker-machineしてみる

概要

GitLab Runner 1.1 with Autoscalingによると、gitlab-runner自身もスケールできるよ、と。

runnerの環境にいろいろ入れるのは嫌だし、runnnerの環境にDockerを入れてそこで動かすにしても、
メモリやCPUも常時そんなに必要なわけじゃないから、runnner自体は安いインスタンスにしたい。
そう思うのは人情です。

そこで、今回はgitlab-runnerはt2.microの小さいインスタンスで動かし、
実際のビルドは、そこからdocker-machineで作成された先のインスタンス内でやろうと考えたのです。

AmazonLinuxで1からgitlab-runnerを入れ、ビルドできるところまでをステップごとに紹介します。
公式ドキュメントをコピペしていると気づかないつまづきポイントつき!

やってみた結果、思ったこと

メリット

  • gitlab-runner自身は、ビルドを行わないので、t2.microレベルで良い。やすい。
  • 複数のリクエストがきても、EC2インスタンスが新規に生成されるので、スケールしやすい。

デメリット

  • EC2インスタンスの起動から行われるため、その分ビルドに時間がかかる

aws内にDockerのレジストリ(ECR)があったり、S3にビルド用の資材が一式入ってます!みたいな人には、aws上にgitlab-runnnerを入れるメリットがありそうです。

EC2インスタンスの作成

まず、gitlab-runnerを動かすインスタンスを作成します。t2.microにしておきます。
作成する際のイメージはAmazonLinux(2017/12/06時点で ami-da9e2cbc)を指定します。

 aws ec2 run-instances 
    --image-id ami-da9e2cbc 
    --count 1 
    --instance-type t2.micro 
    --key-name ${KEY_NAME} 
    --security-group-ids ${SECURITY_GROUP_ID} 
    --subnet-id ${SUBNET_ID}

key-nameやセキュリティグループID、サブネットのIDは作成する環境にあわせて設定しておきます。

docker-machineのインストール

docker-machineを先の手順でたてた環境にインストールします。

公式の手順は、https://docs.docker.com/machine/install-machine/#install-machine-directly にあります。

curl -L https://github.com/docker/machine/releases/download/v0.13.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine &&
chmod +x /tmp/docker-machine &&
sudo cp /tmp/docker-machine /usr/bin/docker-machine

つまづきポイント1

公式の手順では、docker-machineを/usr/local/bin/docker-machineにコピーしますが、
これだとインストールした自分は使えるけども、gitlab-runnerユーザには使えないことになるので、
/usr/bin/docker-machine とします。

もし、/usr/bin/local以下に入れてしまっていたら、ビルド実行時にこんなエラーになります。

ERROR: Preparation failed: exec: “docker-machine”: executable file not found in $PATH

build test failed.png

gitlab-runnerのインストール

公式の入れ方はhttps://docs.gitlab.com/runner/install/linux-repository.htmlにあります。

こんな感じでyumで入れてしまいます。

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
sudo yum install gitlab-runner -y

gitlab-runnnerの登録

GitLabにrunnerを登録します。
予めGitLabでトークンの確認と、docker-machineで使うオプション値を確認しておきましょう。

dockerを用いたビルドを想定する場合は、docker-privilegedオプションをつけておくのが良いです。

例はこちら。
docker-machineのオプションは、実際にビルドをするマシンとして過不足ないものを選ぶといいでしょう。

sudo gitlab-runner register --non-interactive 
  --url https://gitlab.com/ 
  --registration-token XXXXXXXXXXXXXXXXXXXXXXX 
  --executor "docker+machine" 
  --name "gitlab-ci-auto-scaling" 
  --docker-image "ubuntu" 
  --docker-privileged 
  --machine-machine-driver "amazonec2" 
  --machine-machine-name "gitlab-ci-%s" 
  --machine-machine-options "amazonec2-access-key=ACCESS_KEY" 
  --machine-machine-options "amazonec2-secret-key=SECRET_KEY" 
  --machine-machine-options "amazonec2-region=ap-northeast-1" 
  --machine-machine-options "amazonec2-root-size=30" 
  --machine-machine-options "amazonec2-instance-type=m4.large" 
  --machine-machine-options "amazonec2-vpc-id=vpc-0123456" 
  --machine-machine-options "amazonec2-subnet-id=subnet-1234567" 
  --tag-list "ec2-auto-scale,docker"

つまづきポイント2

machine-machine-optionsで指定する内容は、“KEY=VALUE”の形で、イコールでつなぐようにします。
“KEY VALUE”のようにしておくと、registerそのものは成功しますが、動作しないことになります。

つまづきポイント3

もし、docker-priviledgedがない状態(false)で、dockerコマンドを実行するようなビルドが走ったときは、こうなります。

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
ERROR: Job failed: exit code 1

a.png

あとはCIするだけ

あとは、gitlab-ci.ymlを用意してビルドするだけ!

image: docker:latest

services:
  - docker:dind

build-test:
  stage: build
  script:
    - echo sekai no yasuda and aoki.
    - docker version
  tags:
    - ec2-auto-scale

tagsには、忘れずに自分で登録したrunnnerのタグにしておきましょう。

インスタンスが作成され、ビルドが走り、そしてインスタンスが削除される。
terminatedがたくさんAWSのコンソールで見えても気にしない!
じゃんじゃんバリバリ、CIがまわせるようになりますね。

では、Happy GitLab Lifeを!!

続きを読む

tsort について

はじめに

Ruby Advent Calendar 2017 5日目の記事です。

この記事では、Ruby標準ライブラリにある tsort について、説明します。
tsort を使うことで、依存関係を解決して、順番に処理することなどが簡単にできます。

今回の内容は Meguro.rb #9 での発表資料をベースにしています。

トポロジカルソートとは

  • グラフ理論でのアルゴリズムの1つ
  • 依存関係を順に処理したいときに使える
  • Ruby 標準ライブラリの tsort でトポロジカルソートができる

トポロジカルソートの利用例

Set#divide

標準ライブラリの Set#divide は内部実装で tsort を使っています。

その前に Set#divide について説明しましょう。
以下、るりまでの説明です。

元の集合をブロックで定義される関係で分割し、その結果を集合として返します。

ブロックパラメータが 1 個の場合、block.call(o1) == block.call(o2) が真
ならば、o1 と o2 は同じ分割に属します。

ブロックパラメータが 2 個の場合、block.call(o1, o2) が真ならば、
o1 と o2 は同じ分割に属します。
この場合、block.call(o1, o2) == block.call(o2, o1)
が成立しないブロックを与えると期待通りの結果が得られません。

o1 と o2 が同じ分割に属し、 o2 と o3 が同じ分割に属する場合、 o1 と o3 がたとえブロックの評価結果が偽であっても、 o1 と o3 は同じ分割に属することになります。

下記の例をみると分かりやすいでしょう。

require 'set'
numbers = Set[1, 3, 4, 6, 9, 10, 11]
set = numbers.divide { |i,j| (i - j).abs == 1 }
p set     # => #<Set: {#<Set: {1}>,
          #            #<Set: {11, 9, 10}>,
          #            #<Set: {3, 4}>,
          #            #<Set: {6}>}>

9 と 11が同じ分割に属しています。

Rubygems

Rubygems は内部で依存関係を解決する処理があり、そのために tsort を利用しています。

Bundler

Bundler も Rubygems と同様に内部で依存関係を解決するため、tsort を使っています。

Ruby on Rails

Ruby on Rails の Railtie では tsort を使っています。

ドキュメント によると、

Railtie is the core of the Rails framework and provides several hooks to extend Rails and/or modify the initialization process.

すべての Rails のコンポーネント(Action Mailer, Action Controller, Action View and Active Record)は Railtie です。

Ruby on Rails の Initializer では、:before:after オプションを渡すことで、特定の Initializer の前後に順に実行するように指定することができます。

この Initializer の実行順を解決するために内部的に tsort が使われています。

tsort の適用例

今回、tsort が必要だった理由

  • AWS の運用費用を売上管理と同じ分類で管理したかった。
  • AWS では、リソースの費用をタグごとに分類して管理する機能がある
  • とはいえ、やってみたところ未分類のコストが多かった
    • 理由: タグがついていないリソースが多く、それらのコストが未分類として計上されていた
    •   EC2 にはタグがついていたが、EBS、スナップショット、AMI 等にはタグがなかった
  • EC2 に付与されたタグを自動的に関連するリソースにも付与するスクリプトを作ろうと思った

AWS のリソース間の関連

  • EC2 を起点として、リソース間の関連性は下図のようになっています。

    • それぞれのリソースの詳細については、今回の主題と異なるので説明を割愛します。

image.png

処理内容

詳細は、今回説明しませんが、下記の処理を作成しました。

  1. aws describe-instances コマンドで、EC2 と EBS と ENI の関係を取得・EC2 に付与されたタグをすべて取得
  2. aws describe-snapshots コマンドで、EBS と スナップショット ID の関係を取得
  3. aws describe-images コマンドで、AMI と スナップショットID の関係を取得
  4. ①~③の結果生成されたグラフ構造を元に、関連する EC2 に付与されたタグを EBS、ENI、スナップショット、AMI にも同様に付与する

有向グラフの構築

有向グラフを構築する処理の例です。

上記の図を Tree と見立てた場合、ハッシュ @edges の key が親ノード、 value が配列で子ノードとなっています。

@edges = Hash.new{|h, key| h[key] = []}
each_tag_ebs_eni do |instance_id, tags, ebs, eni|
  @edges[instance_id].push *ebs
  @edges[instance_id].push *eni
  
end
each_ebs_snapshot do |volume_id, snapshot_id|
  @edges[volume_id].push snapshot_id
end
each_snapshot_ami do |snapshot_id, ami_id|
  @edges[snapshot_id].push ami_id
end

TSort 利用のための準備

TSort モジュールを include する場合は、tsort_each_nodetsort_each_child メソッドを実装する必要があります。
tsort_each_node ではグラフのすべてのノードに順にアクセスする処理を実装します。
tsort_each_child では、引数で与えられたノードの直接の子のノードに順にアクセスする処理を実装します。
このように、使う側で必要なメソッドを実装するという仕様になっていることで、TSort モジュールは特定のデータ構造に依存しない、柔軟性が高い設計になっています。

class AwsTSort
  include TSort
  def tsort_each_node
    (snip)
  end

  def tsort_each_child(node)
    @edges.fetch(node, []).each do |child|
      yield child
    end
  end
  
end

今回の例では、tsort_each_node が必要なメソッドを利用していませんので、省略しています。

TSort のメソッドの呼び出し

TSort#each_strongly_connected_component_from という少々長い名前のメソッドを使うと、そのノードの子孫を順に処理することができます。
本稿の例では、EC2 に関連した EBS、ENI などのリソースを順に取得できます。

def resources_from(start)
  [].tap do |resources|
    each_strongly_connected_component_from(start) do |nodes|
      resources.push *nodes # nodes は Array
    end
    resources.delete(start) # start自身を除外
  end
end

後日談

TSort を使うことで、無事、各リソースにタグ付けする点については見事実現できました。
しかしながら、それでもなお未分類のコストが一定程度残っている状態です。
AWS的なベストプラクティスは、アカウントの分離だそうですが、今から取り組むのはハードルが高いと感じています。

詳しい人教えてください。

続きを読む